add and remove scsi device when I/O is going on is possible?
In kernel 2.6, I observed that A SCSI device can be echo-removed even if an I/O is going on or the device is mounted. In 2.4 kernels if a SCSI device was mounted or an I/O was going on,echo-remove was not possible. In the 2.6 kernels this is no longer true. Can one give details of the reason for this change Thanks and Regards Deepak - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] qla1280: remove qla1280_proc_info
Christoph == Christoph Hellwig [EMAIL PROTECTED] writes: Christoph reading the /proc/scsi/qla1280/* files can easily corrupt Christoph kernel memory. As the feature is deprecated, and the Christoph qla1280 implementation doesn't return very usefull Christoph implementation but is so buggy that any serious user would Christoph have noticed we just remove it. No objections here, /proc thing has been known to be broken for ages and I have seen few complaints over it. Jes - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/3] qla1280: user pci_map_single
Christoph, When pci_map_page was originally introduced it was meant to deprecate pci_map_single, at least thats what my memory tells me. If pci_map_single is suddenly recommended again we can change it back to that, but I don't really see the gain. Cheers, Jes - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: sym53c8xx driver hangs
Matthew Wilcox wrote: Yeah, I don't think any existing patch will help you. Actually I got it to work when I applied the patch frage schnell posted jan.20 (http://marc.theaimsgroup.com/?l=linux-scsim=110624183606642) Could you try this one? No luck, same errors as with the standard(2.1.18m) driver, and the driver gets stuck smime.p7s Description: S/MIME Cryptographic Signature
Re: [PATCH 2/3] qla1280: user pci_map_single
On Fri, Feb 18, 2005 at 04:48:00AM -0500, Jes Sorensen wrote: Christoph, When pci_map_page was originally introduced it was meant to deprecate pci_map_single, at least thats what my memory tells me. No, it's for rather different uses. pci_map_page would be nice to get rid of in favour of pci_map_sg OTOH.. If pci_map_single is suddenly recommended again we can change it back to that, but I don't really see the gain. it's a micro-speedup by avoiding totally useless address arithmetics. You first convert a buffer to page + offset and then it needs to be converted back, e.g. in include/asm-ia64/dma-mapping.h: #define dma_map_page(dev, pg, off, size, dir) \ dma_map_single(dev, page_address(pg) + (off), (size), (dir)) (pci_map_page is mapped to dma_map_page) - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: sym53c8xx driver hangs
On Fri, Feb 18, 2005 at 11:05:51AM +0100, Roger Håkansson wrote:
Matthew Wilcox wrote:
Yeah, I don't think any existing patch will help you.
Actually I got it to work when I applied the patch frage schnell posted
jan.20 (http://marc.theaimsgroup.com/?l=linux-scsim=110624183606642)
Oh. I think I'm confused as to which version of sym2 is in which version
of Linus' tree. The same line in my development tree reads:
if ((goal-options PPR_OPT_MASK) || (goal-period 0xa)) {
Does it still work if you use that? The problem with Frage Schnell's
patch is that it won't try to negotiate U160 speeds; it'll be capped
at U80.
--
Next the statesmen will invent cheap lies, putting the blame upon
the nation that is attacked, and every man will be glad of those
conscience-soothing falsities, and will diligently study them, and refuse
to examine any refutations of them; and thus he will by and by convince
himself that the war is just, and will thank God for the better sleep
he enjoys after this process of grotesque self-deception. -- Mark Twain
-
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: About ARECA RAID driver for Linux i386/x86-64
On Thu, Feb 17, 2005 at 04:02:25PM +0800, erich wrote: Hi,Andrew Morton I had clean up arcmsr for linux kernel 2.6.10. May be it looks more cleanly than old version. Sorry, but I don't see that much of a difference ;-) To get the driver into a shape where we can actually start a review, do run the shell script scripts/Lindent from the kernel tree over the driver, and please kill all your SHOUTING typedefs for kernel types. After that compare it with the file Documentation/CodingStyle, also in the kernel tree and try to fix up whatever seems to not match up. - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: sym53c8xx driver hangs
Matthew Wilcox wrote:
Oh. I think I'm confused as to which version of sym2 is in which version
of Linus' tree. The same line in my development tree reads:
if ((goal-options PPR_OPT_MASK) || (goal-period 0xa)) {
Does it still work if you use that? The problem with Frage Schnell's
patch is that it won't try to negotiate U160 speeds; it'll be capped
at U80.
Well, I guess that part of the driver is rewritten a bit, I get a
compile error if I put that in ;)
But yes, it works if I put in:
if ((tp-tinfo.goal.options PPR_OPT_MASK) ||
(tp-tinfo.goal.period 0xa)) {
smime.p7s
Description: S/MIME Cryptographic Signature
Re: [ANNOUNCE] hotplug-ng 001 release
[added linux-scsi] On Wed, Feb 16, 2005 at 11:32:51PM +, Willem Riede wrote: On 02/16/2005 06:17:41 PM, Roman Kagan wrote: I tried out Roman's patch, well at least simple loading of st via modprobe scsi-type-1, works nicely as expected. (modprobe -r sd is hanging on down() in device_unregister with 2.6.11-rc4 ... must be a ref count problem, have not figured anything out, and took me a while before trying st and sg instead.) On Wed, Feb 16, 2005 at 11:02:41PM +, Willem Riede wrote: On 02/16/2005 06:07:52 AM, Roman Kagan wrote: It handles only st, sd_mod and sr_mod cases (as hotplug-ng-001/module_scsi.c did). Are there any other? Not all tapes are supported by st - OnStream drives need osst instead. As an excuse I can say that I reproduced what was in hotplug-ng-001/module_scsi.c, no more, no less :) How do you suggest that is to be handled? AFAICS they coexist nicely, so, if you add the same thing to osst.c: MODULE_ALIAS(scsi-type-1);/* TYPE_TAPE */ both osst and st will be loaded (provided Greg convinces Rusty to make modprobe load _all_ matching modules as he suggested the other day). Then the one whose .probe succeeds will handle the device. Will that work? Yes. If we can get that load-all behaviour implemented, everything will be fine. You could also append the sdev-vendor and sdev-model, and use alias wild cards. So OSST would not be loaded for all tape devices found (not a big deal). st would still load for all tapes (likely the same as we have today, and not easy to *not* load it for osst devices). That is, add aliases to osst.c like: MODULE_ALIAS(scsi-type-1-onStream-SC-*); MODULE_ALIAS(scsi-type-1-onStream-DI-*); etc. The vendor (8 bytes) and model (16 bytes) can have spaces, and the values are not '\0' terminated. modprobe does not seem to handle spaces in an alias. And for st.c: MODULE_ALIAS(scsi-type-1-*); sd.c: MODULE_ALIAS(scsi-type-4-*); MODULE_ALIAS(scsi-type-5-*); Also, sg loading would want (along with modprobe load all feature): MODULE_ALIAS(scsi-type-*); -- Patrick Mansfield - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [ANNOUNCE] hotplug-ng 001 release
On Fri, Feb 18, 2005 at 09:17:37AM -0800, Patrick Mansfield wrote: You could also append the sdev-vendor and sdev-model, and use alias wild cards. String values haven't been used in the aliases so far, and I think for a reason: with all the unpredictable weird characters and string lengths they would make maintainance harder, not easier. That is, add aliases to osst.c like: MODULE_ALIAS(scsi-type-1-onStream-SC-*); MODULE_ALIAS(scsi-type-1-onStream-DI-*); I used dashes for the only reason of these aliases being static. If they are supposed to grow it may make sense to stick to the convention used everywhere else, i.e. bus:devspec. Also, sg loading would want (along with modprobe load all feature): MODULE_ALIAS(scsi-type-*); Is it certain that it can live together with s[dtr]? I thought these guys now handled all the ioctls sg was supposed to themselves... Roman. - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: About ARECA RAID driver for Linux i386/x86-64
Linux Christoph Hellwig [EMAIL PROTECTED] wrote: On Thu, Feb 17, 2005 at 04:02:25PM +0800, erich wrote: Hi,Andrew Morton I had clean up arcmsr for linux kernel 2.6.10. May be it looks more cleanly than old version. Sorry, but I don't see that much of a difference ;-) All the LINUX_VERSION_CODE tests went away. To get the driver into a shape where we can actually start a review, do run the shell script scripts/Lindent from the kernel tree over the driver, yup. three seconds work. and please kill all your SHOUTING typedefs for kernel types. Yes, these: +typedef int8_t CHAR, *PCHAR; +typedef int16_t SHORT, *PSHORT; +typedef int32_t LONG32, *PLONG32; +typedef int64_t LONG64, *PLONG64; +typedef uint8_t UCHAR, *PUCHAR; +typedef uint16_t USHORT, *PUSHORT; +typedef uint32_t ULONG32, *PULONG32; +typedef uint64_t ULONG64, *PULONG64; +typedef Scsi_Device SCSIDEV, *PSCSIDEV; +typedef Scsi_Cmnd SCSICMD, *PSCSICMD; +typedef void VOID, *PVOID; +typedef struct Scsi_Host SH, *PSH; +typedef struct scatterlist SGL, *PSGL; +typedef void (*DPCFUN) (void *); +typedef struct _MU MU, *PMU; +typedef struct _CCB CCB, *PCCB; +typedef struct _ACB ACB, *PACB; +typedef struct _HCBARC HCBARC, *PHCBARC; +typedef struct _DPC DPC, *PDPC; +typedef struct _EVENT EVENT, *PEVENT; +typedef struct _QBUFFER QBUFFER, *PQBUFFER; +typedef struct _SG32ENTRY SG32ENTRY, *PSG32ENTRY; +typedef struct _SG64ENTRY SG64ENTRY, *PSG64ENTRY; +typedef struct _SGENTRY_UNION SGENTRY_UNION, PSGENTRY_UNION; +typedef struct _SYSTEMTIME SYSTEMTIME, *PSYSTEMTIME; +typedef struct _TIMERECORD TIMERECORD, *PTIMERECORD; +typedef struct _SENSE_DATA SENSE_DATA, *PSENSE_DATA; +typedef struct _ARCMSR_PCIINFO ARCMSR_PCIINFO, *PARCMSR_PCIINFO; +typedef struct _ARCMSR_CDB ARCMSR_CDB, *PARCMSR_CDB; +typedef struct _CMD_IO_CONTROL CMD_IO_CONTROL, *PCMD_IO_CONTROL; +typedef struct _CMD_IOCTL_FIELD CMD_IOCTL_FIELD, *PCMD_IOCTL_FIELD; +#if defined(__x86_64__) +typedef uint64_t CPT2INT, *PCPT2INT; +#else +typedef uint32_t CPT2INT, *PCPT2INT; +#endif should be removed - just open-code the types within the .c code. - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: sym53c8xx driver hangs
On Fri, Feb 18, 2005 at 06:05:22PM +0100, Roger Håkansson wrote:
Matthew Wilcox wrote:
Oh. I think I'm confused as to which version of sym2 is in which version
of Linus' tree. The same line in my development tree reads:
Well, I guess that part of the driver is rewritten a bit, I get a
compile error if I put that in ;)
Oh, er, yes, looking at the diff from 2.6.10 shows I did ...
+ struct sym_trans *goal = tp-tinfo.goal;
+ struct sym_trans *curr = tp-tinfo.curr;
lalalla ;-)
But yes, it works if I put in:
if ((tp-tinfo.goal.options PPR_OPT_MASK) ||
(tp-tinfo.goal.period 0xa)) {
Excellent. Then 2.6.11 works for Ultrium tape drives. Yay! Tick another
annoying bug off the list ... just the strange not-working-on-Alpha bug
to investigate, I think.
--
Next the statesmen will invent cheap lies, putting the blame upon
the nation that is attacked, and every man will be glad of those
conscience-soothing falsities, and will diligently study them, and refuse
to examine any refutations of them; and thus he will by and by convince
himself that the war is just, and will thank God for the better sleep
he enjoys after this process of grotesque self-deception. -- Mark Twain
-
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [ANNOUNCE] hotplug-ng 001 release
On Fri, Feb 18, 2005 at 10:33:50AM -0800, Patrick Mansfield wrote: The block SG_IO handles the ioctls, but not devices without a SCSI upper level driver (i.e. not tape, disk or cdrom). Then it might make sense to explicitly list in sg.c the TYPE_* not matched by s[dtr]. In my experience, there are always applications that want to use the standard device driver (/dev/sda etc.) and others that want to use a generic driver. So these drivers can compete for the same device? Are there deterministic rules on which one is supposed to win? And is there a userspace interface to unbind one driver and bind another? Otherwise it may mean that automatic module loading is inappropriate here at all... Roman. - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [ANNOUNCE] hotplug-ng 001 release
On Fri, Feb 18, 2005 at 10:41:35PM +0300, Roman Kagan wrote: On Fri, Feb 18, 2005 at 10:33:50AM -0800, Patrick Mansfield wrote: The block SG_IO handles the ioctls, but not devices without a SCSI upper level driver (i.e. not tape, disk or cdrom). Then it might make sense to explicitly list in sg.c the TYPE_* not matched by s[dtr]. sg can be used even if another scsi upper level driver is loaded. fedora core tried something like that for a while, I'm not sure what happened (besides it being really hard to do), and haven't noticed anything different in recent (2.6.x) fc kernels. So these drivers can compete for the same device? Are there deterministic rules on which one is supposed to win? And is there a userspace interface to unbind one driver and bind another? Otherwise it may mean that automatic module loading is inappropriate here at all... No to all. It is OK to autoload sg, it has special handling. Even though greg probably hates it, it is much better than a /proc/bus/scsi ;-) -- Patrick Mansfield - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[Fwd: [patch libata-dev-2.6 5/5] libata: update ATA pass thru opcodes]
I thought the Command sets are supposed to be qualified paragraph was worth forwarding to linux-scsi. Jeff ---BeginMessage--- Update ATA pass thru opcodes to match what is specified in the current ATA pass thru spec (T10/04-262r7). Signed-off-by: John W. Linville [EMAIL PROTECTED] --- This part was controversial before, because these opcodes seemed to overlap with some existing opcodes. So I contacted the author of the spec, Curtis Stevens: (quoted without permision) The command values in 04-262r7 are correct. There was an erroneous value published in the minutes that subsequently got published in SPC. This has been corrected. Command sets are supposed to be qualified by the Inquiry Peripheral Device Type. I am a little concerned that some portions of linux depend on opcodes being the same for all PDTs. Using reusing opcodes will continue to happen more frequently as new applications emerge and new devices are created. The SCSI opcoded are already overloaded to the point that Service Actions have become necessary to extend the protocol. Honestly, I don't know if that clears things up or not. But, Curtis seems pretty adamant that the values in the patch below (which match rev 7 of the spec) are correct. IMHO, at worst these values are no more wrong than the ones already there. So, apply this now, or apply it later... :-) include/scsi/scsi.h |6 +++--- 1 files changed, 3 insertions(+), 3 deletions(-) --- sata-smart-2.6/include/scsi/scsi.h.orig 2005-02-01 16:22:12.390234346 -0500 +++ sata-smart-2.6/include/scsi/scsi.h 2005-02-01 16:23:02.828491161 -0500 @@ -113,9 +113,9 @@ extern const char *const scsi_device_typ /* values for service action in */ #defineSAI_READ_CAPACITY_16 0x10 -/* Temporary values for T10/04-262 until official values are allocated */ -#defineATA_160x85 /* 16-byte pass-thru [0x85 == unused]*/ -#defineATA_120xb3 /* 12-byte pass-thru [0xb3 == obsolete set limits command] */ +/* Values for T10/04-262r7 */ +#defineATA_160x85 /* 16-byte pass-thru */ +#defineATA_120xa1 /* 12-byte pass-thru */ /* * SCSI Architecture Model (SAM) Status codes. Taken from SAM-3 draft -- John W. Linville [EMAIL PROTECTED] ---End Message---
Re: sym53c8xx_2 hangs on 53c810 rev 02
On Mon, Nov 15, 2004 at 10:21:28PM +0100, Ingo Korb wrote: While trying to run 2.6.9 on my AlphaStation 200, I noticed that sym53c8xx_2 doesn't seem to like the onboard 53c810 rev. 02 (see bootlog below). Just going through my old bug reports ... sym0: 810 rev 0x2 at pci :00:06.0 irq 11 sym0: No NVRAM, ID 7, Fast-10, SE, parity checking sym0: SCSI BUS has been reset. scsi0 : sym-2.1.18j sym0:0:0: ABORT operation started. sym0:0:0: ABORT operation timed-out. sym0:0:0: DEVICE RESET operation started. sym0:0:0: DEVICE RESET operation timed-out. sym0:0:0: BUS RESET operation started. sym0:0:0: BUS RESET operation timed-out. sym0:0:0: HOST RESET operation started. sym0: SCSI BUS has been reset. To be honest, this looks like the sym2 driver never received any interrupts. Could you boot with sym53c8xx.debug=0x on the command line? That should report any interrupts that come in. -- Next the statesmen will invent cheap lies, putting the blame upon the nation that is attacked, and every man will be glad of those conscience-soothing falsities, and will diligently study them, and refuse to examine any refutations of them; and thus he will by and by convince himself that the war is just, and will thank God for the better sleep he enjoys after this process of grotesque self-deception. -- Mark Twain - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: cciss CSMI via sysfs for 2.6
On Fri, Feb 18, 2005 at 07:46:28PM +, Christoph Hellwig wrote:
/*
+ * sysfs stuff
+ * this should be moved to it's own file, maybe cciss_sysfs.h
+ */
+
+static ssize_t cciss_firmver_show(struct device *dev, char *buf)
+{
+ ctlr_info_t *h = dev-driver_data;
+return sprintf(buf,%c%c%c%c\n, h-firm_ver[0], h-firm_ver[1],
+h-firm_ver[2], h-firm_ver[3]);
+}
I really wish we had a common firmver release attribut in the driver
core, as mentioned in the fc transport class thread. Greg?
For a device? It seems a huge overkill to add this attribute for
_every_ device in the system, when only a small minority can actually
use it. Just put it as a default scsi or transport class attribute
instead.
thanks,
greg k-h
-
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2.4.30-pre1] aic7xxx: don't reset chip on pause
Patch below taken from RHEL3 Update 4 kernel 2.4.21-27.EL, fixes a bug in the aic79xx and aic7xxx drivers, where upon trying to pause the controller chip, it is accidentally hard-reset. This causes PCI Parity errors to appear on Dell PowerEdge 4600 servers as the inb() immediately after accidental reset receives corrupted data. Patch was submitted by Justin Gibbs many moons ago, but never applied to mainline 2.4. Marcelo, please apply. Signed-off-by: Matt Domsch [EMAIL PROTECTED] -- Matt Domsch Software Architect Dell Linux Solutions linux.dell.com www.dell.com/linux Linux on Dell mailing lists @ http://lists.us.dell.com diff -urNp --exclude-from=/home/mdomsch/excludes --minimal ./aic79xx_pci.c /home/mdomsch/kernels/linux-2.4.21-27.EL/drivers/scsi/aic7xxx/aic79xx_pci.c --- ./aic79xx_pci.c Fri Feb 18 14:38:22 2005 +++ linux/drivers/scsi/aic7xxx/aic79xx_pci.cWed Dec 1 20:49:28 2004 @@ -451,8 +457,10 @@ ahd_pci_test_register_access(struct ahd_ * or read prefetching could be initiated by the * CPU or host bridge. Our device does not support * either, so look for data corruption and/or flaged -* PCI errors. +* PCI errors. First pause without causing another +* chip reset. */ + hcntrl = ~CHIPRST; ahd_outb(ahd, HCNTRL, hcntrl|PAUSE); while (ahd_is_paused(ahd) == 0) ; diff -urNp --exclude-from=/home/mdomsch/excludes --minimal ./aic7xxx_pci.c /home/mdomsch/kernels/linux-2.4.21-27.EL/drivers/scsi/aic7xxx/aic7xxx_pci.c --- ./aic7xxx_pci.c Fri Feb 18 14:38:22 2005 +++ /home/mdomsch/kernels/linux-2.4.21-27.EL/drivers/scsi/aic7xxx/aic7xxx_pci.c Wed Dec 1 20:49:28 2004 @@ -1284,8 +1284,10 @@ ahc_pci_test_register_access(struct ahc_ * or read prefetching could be initiated by the * CPU or host bridge. Our device does not support * either, so look for data corruption and/or flagged -* PCI errors. +* PCI errors. First pause without causing another +* chip reset. */ + hcntrl = ~CHIPRST; ahc_outb(ahc, HCNTRL, hcntrl|PAUSE); while (ahc_is_paused(ahc) == 0) ; - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Question about SCSI Mid-Layer, getting list of scsi drives
Hello, In kernel 2.4, I have a driver that interfaces to the SCSI mid-layer using API - scsi_register_module. Through this API the (character) driver registers a struct scsi_Device_Template that would contain function pointers (specifically detect) that would be called for each SCSI device in the system. That way my driver would have a knowledge and pointer to all SCSI devices in the system. I don't see the API - scsi_register_module in 2.6 (or similar one) to which I an pass an object of the above type. Can someone please tell me how I can do the same thing in 2.6. I have looked into the function - scsi_host_alloc(), but from my reading of code, I don't think it does the same functionality as what I was doing in 2.4. Any pointer to any docs explaining the changes from 2.4 to 2.6, or how to accomplish what I am trying to do would be very appreciated. Thank you, A. __ Do you Yahoo!? Yahoo! Mail - now with 250MB free storage. Learn more. http://info.mail.yahoo.com/mail_250 - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: cciss CSMI via sysfs for 2.6
On Fri, 2005-02-18 at 12:05 -0800, Greg KH wrote: For a device? It seems a huge overkill to add this attribute for _every_ device in the system, when only a small minority can actually use it. Just put it as a default scsi or transport class attribute instead. Actually, we might be able to do this as a simple attribute container rather than a transport class, but I agree, it's not a generic property of every device. James - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Fwd: [patch libata-dev-2.6 5/5] libata: update ATA pass thru opcodes]
Jeff Garzik wrote: I thought the Command sets are supposed to be qualified paragraph was worth forwarding to linux-scsi. Jeff Subject: [patch libata-dev-2.6 5/5] libata: update ATA pass thru opcodes From: John W. Linville [EMAIL PROTECTED] Date: Fri, 18 Feb 2005 15:16:23 -0500 To: linux-ide@vger.kernel.org, linux-kernel@vger.kernel.org, [EMAIL PROTECTED] To: linux-ide@vger.kernel.org, linux-kernel@vger.kernel.org, [EMAIL PROTECTED] Update ATA pass thru opcodes to match what is specified in the current ATA pass thru spec (T10/04-262r7). Signed-off-by: John W. Linville [EMAIL PROTECTED] --- This part was controversial before, because these opcodes seemed to overlap with some existing opcodes. So I contacted the author of the spec, Curtis Stevens: (quoted without permision) The command values in 04-262r7 are correct. There was an erroneous value published in the minutes that subsequently got published in SPC. This has been corrected. Command sets are supposed to be qualified by the Inquiry Peripheral Device Type. I am a little concerned that some portions of linux depend on opcodes being the same for all PDTs. Using reusing opcodes will continue to happen more frequently as new applications emerge and new devices are created. The SCSI opcoded are already overloaded to the point that Service Actions have become necessary to extend the protocol. Honestly, I don't know if that clears things up or not. But, Curtis seems pretty adamant that the values in the patch below (which match rev 7 of the spec) are correct. IMHO, at worst these values are no more wrong than the ones already there. So, apply this now, or apply it later... :-) include/scsi/scsi.h |6 +++--- 1 files changed, 3 insertions(+), 3 deletions(-) --- sata-smart-2.6/include/scsi/scsi.h.orig 2005-02-01 16:22:12.390234346 -0500 +++ sata-smart-2.6/include/scsi/scsi.h 2005-02-01 16:23:02.828491161 -0500 @@ -113,9 +113,9 @@ extern const char *const scsi_device_typ /* values for service action in */ #define SAI_READ_CAPACITY_16 0x10 -/* Temporary values for T10/04-262 until official values are allocated */ -#define ATA_16 0x85 /* 16-byte pass-thru [0x85 == unused]*/ -#define ATA_12 0xb3 /* 12-byte pass-thru [0xb3 == obsolete set limits command] */ +/* Values for T10/04-262r7 */ +#define ATA_16 0x85 /* 16-byte pass-thru */ +#define ATA_12 0xa1 /* 12-byte pass-thru */ /* * SCSI Architecture Model (SAM) Status codes. Taken from SAM-3 draft Jeff, Maybe it has been decided since but this document: http://www.t10.org/ftp/t10/document.05/05-056r0.pdf which is the minutes of the MMC WG from 19 January 2005 where Curtis Stevens discussed SAT concludes (in New Business, item E): The MMC WG strongly recommends that op code A1h not be used by SAT. The reason is that A1h is the MMC BLANK command. t10 meets again in early March. As for the command sets are supposed to be qualified comment, I think the ULDs (sd, st, sr, mc and osst) handle that well. With the sg driver it is user beware! Many sg3_utils utilities issue an INQUIRY to find the PDT before issuing commands that are PDT specific and potentially dangerous (e.g. FORMAT UNIT for a disk). Doug Gilbert - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
