Re: Problem with USB-to-SATA adapters (was: AS2105-based enclosure size issues with >2TB HDDs)
On Sat, Aug 30, 2014 at 2:15 PM, Alan Stern wrote: > On Fri, 29 Aug 2014, Matthew Dharm wrote: > >> Is there an 'easy' way to override the detected size of a storage >> device from userspace? If we had that, someone could write a helper >> application which looked for this particular fubar and try to Do The >> Right Thing(tm), or at least offer the user some options. > > You mean, force a Media Change event and override the capacity reported > by the hardware? I'm not aware of any API for doing that, although it > probably wouldn't be too hard to add one. > > How would the user know what value to put in for the capacity? Unless > the drive had been hooked up to a different computer and the user > manually noted the correct capacity and typed it in, it would have to > be guesswork. I didn't say it would be easy to figure out the right value, but at least it would be possible. I was thinking of something that could notice a USB device which is formatted NTFS and has a partition table and filesystem that indicates a much bigger capacity than what the drive reports. Under this circumstances, you could do something like pop-up a dialog box saying "this drive is confused -- is it 2TB or 3TB?" Well, maybe that would say "Drive capacity is not consistent with partition table. This can happen with certain USB drives designed for use with Windows. Override drive capacity (emulating Windows)?" You could imagine increasing complex heuristics to try to detect this scenario. Even without an automated helper program to do it, if there was a sysfs interface then when we got the periodic e-mails reporting this same type of problem, we could offer a quick-and-clean solution. Matt -- Matthew Dharm Maintainer, USB Mass Storage driver for Linux -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Problem with USB-to-SATA adapters (was: AS2105-based enclosure size issues with >2TB HDDs)
Is there an 'easy' way to override the detected size of a storage device from userspace? If we had that, someone could write a helper application which looked for this particular fubar and try to Do The Right Thing(tm), or at least offer the user some options. Matt On Fri, Aug 29, 2014 at 2:07 PM, Dale R. Worley wrote: >> From: Alan Stern > >> If you try to repartition the drive under Windows using the deficient >> adapter, you'll see that the problem still exists. It just doesn't >> show up during normal use. > > So in summary, the Windows workaround is icky, but it allows any use > but repartitioning to be one on the attached disk. > > Dale > -- > To unsubscribe from this list: send the line "unsubscribe linux-usb" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- Matthew Dharm Maintainer, USB Mass Storage driver for Linux -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [usb-storage] Issue with mini-SaS to eSATA to USB 3.0 setup
s >> >> /var/log/messages >> >> Jan 27 18:00:28 localhost kernel: usb 7-1: New USB device found, >> idVendor=2109, idProduct=0810 >> Jan 27 18:00:28 localhost kernel: usb 7-1: New USB device strings: >> Mfr=1, Product=2, SerialNumber=0 >> Jan 27 18:00:28 localhost kernel: usb 7-1: Product: 4-Port USB 3.0 Hub >> Jan 27 18:00:28 localhost kernel: usb 7-1: Manufacturer: VIA Labs, Inc. >> Jan 27 18:00:28 localhost kernel: usb 7-1: configuration #1 chosen from 1 >> choice >> Jan 27 18:00:28 localhost kernel: hub 7-1:1.0: USB hub found >> Jan 27 18:00:28 localhost kernel: hub 7-1:1.0: 4 ports detected >> >> Jan 28 21:32:02 localhost kernel: usb 7-1.1: new SuperSpeed USB device >> number 9 using xhci_hcd >> Jan 28 21:32:56 localhost kernel: xhci_hcd :01:00.0: PCI INT A -> >> GSI 16 (level, low) -> IRQ 16 >> Jan 28 21:32:56 localhost kernel: xhci_hcd :01:00.0: xHCI Host Controller >> Jan 28 21:32:56 localhost kernel: xhci_hcd :01:00.0: new USB bus >> registered, assigned bus number 6 >> Jan 28 21:32:56 localhost kernel: xhci_hcd :01:00.0: irq 16, io >> mem 0xdfe0 >> Jan 28 21:32:56 localhost kernel: usb usb6: Manufacturer: Linux >> 2.6.32-279.19.1.el6.i686 xhci_hcd >> Jan 28 21:32:56 localhost kernel: xhci_hcd :01:00.0: xHCI Host Controller >> Jan 28 21:32:56 localhost kernel: xhci_hcd :01:00.0: new USB bus >> registered, assigned bus number 7 >> Jan 28 21:32:56 localhost kernel: usb usb7: Manufacturer: Linux >> 2.6.32-279.19.1.el6.i686 xhci_hcd >> Jan 28 21:32:56 localhost kernel: usb 7-1: new SuperSpeed USB device >> number 2 using xhci_hcd >> Jan 28 21:32:56 localhost kernel: usb 7-1.1: new SuperSpeed USB device >> number 3 using xhci_hcd >> Jan 28 21:32:56 localhost kernel: usb 7-1.2: new SuperSpeed USB device >> number 4 using xhci_hcd >> Jan 28 21:32:56 localhost kernel: usb 7-1.3: new SuperSpeed USB device >> number 5 using xhci_hcd >> Jan 28 21:32:56 localhost kernel: usb 7-1.4: new SuperSpeed USB device >> number 6 using xhci_hcd > > > -- > You received this message because you are subscribed to the Google Groups > "USB Mass Storage on Linux" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to usb-storage+unsubscr...@lists.one-eyed-alien.net. > To post to this group, send email to usb-stor...@lists.one-eyed-alien.net. > Visit this group at > http://groups.google.com/a/lists.one-eyed-alien.net/group/usb-storage/?hl=en. > For more options, visit > https://groups.google.com/a/lists.one-eyed-alien.net/groups/opt_out. > > -- Matthew Dharm Maintainer, USB Mass Storage driver for Linux -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] bugfix for an underflow condition in usb storage & isd200.c
On Wed, Feb 06, 2008 at 03:23:39PM -0500, Alan Stern wrote: > On Tue, 5 Feb 2008, Matthew Dharm wrote: > > > Six of one and a half-dozen of the other. All we're arguing over is the > > definition of "correct behavior" here. You want to change the API so that > > overrun is acceptable and handled; I prefer calling it a Bad Thing(tm). > > > > We both agree that the code shouldn't run off the end of the s-g list. > > > > Since you've already committed to updating the patch, then we can do it > > your way. Just make sure it's very very clear in the comments. > > Okay, here's my version. It makes some significant changes to the > interface for usb_stor_access_xfer_buf() -- in particular, the context > information is now stored in an opaque structure rather than in ad-hoc > local variables. All the callers are updated to use the new interface. Maybe this is a crazy question, but... Why is this not in the SCSI core? It's hardly USB-specific, and I'm willing to bet that there are other HCDs (at least spb2) which need to do this sort of thing... Matt -- Matthew Dharm Home: [EMAIL PROTECTED] Maintainer, Linux USB Mass Storage Driver YOU SEE!!?? It's like being born with only one nipple! -- Erwin User Friendly, 10/19/1998 pgpLv1iX6JiHu.pgp Description: PGP signature
Re: [PATCH] bugfix for an underflow condition in usb storage & isd200.c
On Mon, Feb 04, 2008 at 03:05:58PM -0500, Alan Stern wrote: > On Sun, 3 Feb 2008, Matthew Dharm wrote: > > I think the correct approach is to modify those routines so that they > will never overrun the s-g buffer (like Boaz has done), and _document_ > this behavior. Then the callers can feel free to try and transfer as > much as they want, knowing that an overrun can't occur. There won't > be any need for a WARN_ON or anything else. Six of one and a half-dozen of the other. All we're arguing over is the definition of "correct behavior" here. You want to change the API so that overrun is acceptable and handled; I prefer calling it a Bad Thing(tm). We both agree that the code shouldn't run off the end of the s-g list. Since you've already committed to updating the patch, then we can do it your way. Just make sure it's very very clear in the comments. Matt -- Matthew Dharm Home: [EMAIL PROTECTED] Maintainer, Linux USB Mass Storage Driver E: You run this ship with Windows?! YOU IDIOT! L: Give me a break, it came bundled with the computer! -- ESR and Lan Solaris User Friendly, 12/8/1998 pgpcpyc8SXPyv.pgp Description: PGP signature
Re: [PATCH] bugfix for an underflow condition in usb storage & isd200.c
One more comment on the patch...
On Sun, Feb 03, 2008 at 06:28:48PM +0200, Boaz Harrosh wrote:
> + /* Check for overflow */
> + if (buflen > scsi_bufflen(srb)) {
This really should have an unlikely() around it. This is an often-executed
code path, and we want to optimize it as much as possible.
Matt
--
Matthew Dharm Home: [EMAIL PROTECTED]
Maintainer, Linux USB Mass Storage Driver
Type "format c:" That should fix everything.
-- Greg
User Friendly, 12/18/1997
pgpmp71REWTJX.pgp
Description: PGP signature
Re: [PATCH] bugfix for an underflow condition in usb storage & isd200.c
On Sun, Feb 03, 2008 at 06:28:48PM +0200, Boaz Harrosh wrote: > >From 3610cfa93c990bbbafb296134ac01ef6d426eb8d Mon Sep 17 00:00:00 2001 > From: Boaz Harrosh <[EMAIL PROTECTED]> > Date: Thu, 31 Jan 2008 21:31:31 +0200 > Subject: [PATCH] bugfix for an overflow condition in usb storage & isd200.c > > scsi_scan is issuing a 36-byte INQUIRY request to llds. isd200 would > volunteer 96 bytes of INQUIRY. This caused an overflow condition in > protocol.c usb_stor_access_xfer_buf(). So first fix is to > usb_stor_access_xfer_buf() to properly handle overflow/underflow conditions. > Then usb_stor_set_xfer_buf() should report this condition as cmnd->result == > (DID_BAD_TARGET << 16). > > Then also isd200.c is fixed to only return the type of INQUIRY && SENSE > the upper layer asked for. > > Signed-off-by: Boaz Harrosh <[EMAIL PROTECTED]> > --- > drivers/usb/storage/isd200.c |7 +-- > drivers/usb/storage/protocol.c | 20 > 2 files changed, 21 insertions(+), 6 deletions(-) Looking at this again, I think I see Alan's point. The modifications to ISD200 code aren't really needed. Or, put another way, if you're going to modify the ISD200 code, you should fix up all the other users of usb_stor_access_xfer_buf() -- there are over a dozen or so, and it looks like none of them have sanity checks for length (but the happen to work right now). But, the modifications to usb_stor_access_xfer_buf() look good -- no request from a sub-driver should be allowed to scribble into memory. The current code does make the implicit assumption that there is enough storage, and will walk right off the end of the sg list if there isn't. I'm not sure I like the mods to usb_stor_set_xfer_buf(). Any place we set a status that we know is going to be thrown away is an invitation for a problem later if someone changes the code to preserve that status. It's a jack-in-the-box, waiting to spring open in our face later. The limit check (which mirrors the usb_stor_access_xfer_buf modification) and WARN_ON() are probably good. In a strictly technical sense, the change to protocol.c are sufficient. That is, they will prevent a serious error. There is a justification tho to fix all of the users of usb_stor_access_buf() to not attempt to use more SCSI buffer than exists. My opinion is this: Let's make the protocol.c mods (modulo my comments about setting useless status bits) now. Then, let's decide if we're going to patch all the other users of the usb_stor_*_xfer_buf() functions as a separate discussion. Matt -- Matthew Dharm Home: [EMAIL PROTECTED] Maintainer, Linux USB Mass Storage Driver C: They kicked your ass, didn't they? S: They were cheating! -- The Chief and Stef User Friendly, 11/19/1997 pgpxgKlffq0MR.pgp Description: PGP signature
Re: [PATCH 2.6.24] bugfix for an overflow condition in usb storage & isd200.c
On Thu, Jan 31, 2008 at 10:05:19PM +0200, Boaz Harrosh wrote: > On Thu, Jan 31 2008 at 21:49 +0200, Matthew Dharm <[EMAIL PROTECTED]> wrote: > > No. No no no. > > Please re-inspect the code again. > There is no device involved here. The code completely emulates this commands > with a driver made up information. the send_to_device is Zero. > (Nothing to bounce) Okay, I see what you're doing there, and I can live with that. > The negative resid is returned by iscsi for ages so I would say the scsi-ml > is fine with it. But if you want I can reset the resid and mark an overflow > condition in cmnd->status. I'd be fine if one of the SCSI guru's would comment on this as being acceptable. Matt -- Matthew Dharm Home: [EMAIL PROTECTED] Maintainer, Linux USB Mass Storage Driver Hey Chief. We've figured out how to save the technical department. We need to be committed. -- The Techs User Friendly, 1/22/1998 pgpCejgQ64dmT.pgp Description: PGP signature
Re: [PATCH 2.6.24] bugfix for an overflow condition in usb storage & isd200.c
No. No no no.
The ISD200 code was written by the ISD200 developers. I really don't want
to go mucking about changing what commands actually get send to the ISD200
parts. We have no idea if the will reliably accept a 36-byte INQUIRY.
Just because it happens to work for a couple of people doesn't mean it
works in the general case. Without guidance from In-System, this is a bad
idea.
The way to deal with this is to do this via bounce buffering. The two
commands affected (INQUIRY and MODE_SENSE) are low-performance items.
Discarding data from the end of them is also perfectly legal per spec.
Also, the entire idea of a negative resid makes my head hurt. That sort of
change is in the category of "likely to break something else" which only
expects positive resid values.
Matt
On Thu, Jan 31, 2008 at 09:37:13PM +0200, Boaz Harrosh wrote:
> Greg KH <[EMAIL PROTECTED]> rote:
> > As this is a regression and hits 2.6.24, can you send the final version
> > of this patch to the [EMAIL PROTECTED] address so we can get it into the
> > 2.6.24.y tree?
> >
> > thanks,
> >
> > greg k-h
>
> Mark - This is for you on top of vanila v2.6.24 kernel from Linus.
>
> ---
>
> scsi_scan is issuing a 36-byte INQUIRY request to llds. isd200 would
> volunteer 96 bytes of INQUIRY. This caused an overflow condition in
> protocol.c usb_stor_access_xfer_buf(). So first fix is to
> usb_stor_access_xfer_buf() to properly handle overflow/underflow conditions.
> Then usb_stor_set_xfer_buf() should report this condition as a negative
> resid. Should we also set cmnd->status in the overflow condition?
>
> Then also isd200.c is fixed to only return the type of INQUIRY && SENSE
> the upper layer asked for.
>
> Signed-off-by: Boaz Harrosh <[EMAIL PROTECTED]>
> ---
> drivers/usb/storage/isd200.c |7 +--
> drivers/usb/storage/protocol.c | 13 +
> 2 files changed, 14 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/usb/storage/isd200.c b/drivers/usb/storage/isd200.c
> index 49ba6c0..8186e93 100644
> --- a/drivers/usb/storage/isd200.c
> +++ b/drivers/usb/storage/isd200.c
> @@ -1238,6 +1238,7 @@ static int isd200_scsi_to_ata(struct scsi_cmnd *srb,
> struct us_data *us,
> unsigned long lba;
> unsigned long blockCount;
> unsigned char senseData[8] = { 0, 0, 0, 0, 0, 0, 0, 0 };
> + unsigned xfer_len;
>
> memset(ataCdb, 0, sizeof(union ata_cdb));
>
> @@ -1247,8 +1248,9 @@ static int isd200_scsi_to_ata(struct scsi_cmnd *srb,
> struct us_data *us,
> US_DEBUGP(" ATA OUT - INQUIRY\n");
>
> /* copy InquiryData */
> + xfer_len = min(sizeof(info->InquiryData), scsi_bufflen(srb));
> usb_stor_set_xfer_buf((unsigned char *) &info->InquiryData,
> - sizeof(info->InquiryData), srb);
> + xfer_len, srb);
> srb->result = SAM_STAT_GOOD;
> sendToTransport = 0;
> break;
> @@ -1257,7 +1259,8 @@ static int isd200_scsi_to_ata(struct scsi_cmnd *srb,
> struct us_data *us,
> US_DEBUGP(" ATA OUT - SCSIOP_MODE_SENSE\n");
>
> /* Initialize the return buffer */
> - usb_stor_set_xfer_buf(senseData, sizeof(senseData), srb);
> + xfer_len = min(sizeof(senseData), scsi_bufflen(srb));
> + usb_stor_set_xfer_buf(senseData, xfer_len, srb);
>
> if (info->DeviceFlags & DF_MEDIA_STATUS_ENABLED)
> {
> diff --git a/drivers/usb/storage/protocol.c b/drivers/usb/storage/protocol.c
> index 889622b..038a284 100644
> --- a/drivers/usb/storage/protocol.c
> +++ b/drivers/usb/storage/protocol.c
> @@ -194,7 +194,7 @@ unsigned int usb_stor_access_xfer_buf(unsigned char
> *buffer,
>* and the starting offset within the page, and update
>* the *offset and *index values for the next loop. */
> cnt = 0;
> - while (cnt < buflen) {
> + while (cnt < buflen && sg) {
> struct page *page = sg_page(sg) +
> ((sg->offset + *offset) >> PAGE_SHIFT);
> unsigned int poff =
> @@ -248,9 +248,14 @@ void usb_stor_set_xfer_buf(unsigned char *buffer,
> {
> unsigned int offset = 0;
> struct scatterlist *sg = NULL;
> + unsigned count;
>
> - usb_stor_access_xfer_buf(buffer, buflen, srb, &sg, &offset,
> + count = usb_stor_access_xfer_buf(buffer, buflen, srb, &sg, &offset,
> TO_XFER
Re: [BUG] 2.6.24-git usb reset problems
On Tue, Jan 29, 2008 at 08:15:04PM +0100, Jens Axboe wrote: > On Tue, Jan 29 2008, Matthew Dharm wrote: > > On Tue, Jan 29, 2008 at 07:39:11PM +0100, Jens Axboe wrote: > > > On Tue, Jan 29 2008, Jens Axboe wrote: > > > > On Tue, Jan 29 2008, Oliver Neukum wrote: > > > > > Am Dienstag, 29. Januar 2008 15:11:08 schrieb Jens Axboe: > > > > > > On Tue, Jan 29 2008, Boaz Harrosh wrote: > > > > > > > On Tue, Jan 29 2008 at 15:54 +0200, Jens Axboe <[EMAIL > > > > > > > PROTECTED]> wrote: > > > > > > > > On Tue, Jan 29 2008, Boaz Harrosh wrote: > > > > > > > >> Greg KH wrote: > > > > > > > > > > > > > No difference, still just a lot of resets. > > > > > > > > > > > > > > > Where you able to figure out which usb storage transport is used? > > > > > > > > > > > > > > in drivers/usb/storage/usb.c you have get_protocol() and > > > > > > > get_transport() > > > > > > > functions. I'm not sure if these get stored in sysfs perhaps. > > > > > > > This will > > > > > > > pinpoint better where to look. Let me research a bit. > > > > > > > > > > > > Did the quick'n easy and dumped it. Protocol is 'Transparent SCSI' > > > > > > and > > > > > > transport is 'Bulk' > > > > > > > > > > You can recompile your kernel with CONFIG_USB_DEBUG and > > > > > CONFIG_STORAGE_DEBUG > > > > > That should tell the reason for the resets. > > > > > > > > Sure, I'll do that. Will post the results tonight. > > > > > > OK, fresh boot with CONFIG_USB_DEBUG and CONFIG_STORAGE_DEBUG. Plugged > > > in the device, waited 10 seconds or so and pulled it out. These are the > > > messages. > > > > > > It all looks good until the MODE_SENSE command, where it only transfers > > > 4 of 192 bytes. > > > > No, that's not the problem. This is the problem: > > It's where the problem starts, otherwise there would not be a need to > sense :-) MODE_SENSE has nothing to do with it. A short MODE_SENSE response is perfectly valid, and the log shows it was handled correctly and subsequent commands worked just fine. It's not until the TUR fails that we get the problem. Matt -- Matthew Dharm Home: [EMAIL PROTECTED] Maintainer, Linux USB Mass Storage Driver P: Nine more messages in admin.policy. M: I know, I'm typing as fast as I can! -- Pitr and Mike User Friendly, 11/27/97 pgpffGBLDboVw.pgp Description: PGP signature
Re: [BUG] 2.6.24-git usb reset problems
On Tue, Jan 29, 2008 at 07:39:11PM +0100, Jens Axboe wrote: > On Tue, Jan 29 2008, Jens Axboe wrote: > > On Tue, Jan 29 2008, Oliver Neukum wrote: > > > Am Dienstag, 29. Januar 2008 15:11:08 schrieb Jens Axboe: > > > > On Tue, Jan 29 2008, Boaz Harrosh wrote: > > > > > On Tue, Jan 29 2008 at 15:54 +0200, Jens Axboe <[EMAIL PROTECTED]> > > > > > wrote: > > > > > > On Tue, Jan 29 2008, Boaz Harrosh wrote: > > > > > >> Greg KH wrote: > > > > > > > > > No difference, still just a lot of resets. > > > > > > > > > > > Where you able to figure out which usb storage transport is used? > > > > > > > > > > in drivers/usb/storage/usb.c you have get_protocol() and > > > > > get_transport() > > > > > functions. I'm not sure if these get stored in sysfs perhaps. This > > > > > will > > > > > pinpoint better where to look. Let me research a bit. > > > > > > > > Did the quick'n easy and dumped it. Protocol is 'Transparent SCSI' and > > > > transport is 'Bulk' > > > > > > You can recompile your kernel with CONFIG_USB_DEBUG and > > > CONFIG_STORAGE_DEBUG > > > That should tell the reason for the resets. > > > > Sure, I'll do that. Will post the results tonight. > > OK, fresh boot with CONFIG_USB_DEBUG and CONFIG_STORAGE_DEBUG. Plugged > in the device, waited 10 seconds or so and pulled it out. These are the > messages. > > It all looks good until the MODE_SENSE command, where it only transfers > 4 of 192 bytes. No, that's not the problem. This is the problem: > usb-storage: *** thread awakened. > usb-storage: Command TEST_UNIT_READY (6 bytes) > usb-storage: 00 00 00 00 00 00 > usb-storage: Bulk Command S 0x43425355 T 0xd L 0 F 0 Trg 0 LUN 1 CL 6 > usb-storage: usb_stor_bulk_transfer_buf: xfer 31 bytes > usb-storage: Status code 0; transferred 31/31 > usb-storage: -- transfer complete > usb-storage: Bulk command transfer result=0 > usb-storage: Attempting to get CSW... > usb-storage: usb_stor_bulk_transfer_buf: xfer 13 bytes > usb-storage: Status code 0; transferred 13/13 > usb-storage: -- transfer complete > usb-storage: Bulk status result = 0 > usb-storage: Bulk Status S 0x53425355 T 0xd R 0 Stat 0x1 > usb-storage: -- transport indicates command failure > usb-storage: Issuing auto-REQUEST_SENSE > usb-storage: Bulk Command S 0x43425355 T 0xe L 18 F 128 Trg 0 LUN 1 CL 6 > usb-storage: usb_stor_bulk_transfer_buf: xfer 31 bytes > usb-storage: Status code 0; transferred 31/31 > usb-storage: -- transfer complete > usb-storage: Bulk command transfer result=0 > usb-storage: usb_stor_bulk_transfer_sglist: xfer 18 bytes, 1 entries > usb-storage: usb_sg_init returned -22 > usb-storage: Bulk data transfer result 0x4 > usb-storage: -- auto-sense failure > usb-storage: storage_pre_reset > ehci_hcd :00:1d.7: port 1 high speed > ehci_hcd :00:1d.7: GetStatus port 1 status 001005 POWER sig=se0 PE CONNECT > usb 5-1: reset high speed USB device using ehci_hcd and address 2 > ehci_hcd :00:1d.7: port 1 high speed > ehci_hcd :00:1d.7: GetStatus port 1 status 001005 POWER sig=se0 PE CONNECT > usb-storage: storage_post_reset > usb-storage: usb_reset_composite_device returns 0 > usb-storage: scsi cmd done, result=0x7 > usb-storage: *** thread sleeping. For some reason, usb_sg_init is boned during auto-sense. Matt -- Matthew Dharm Home: [EMAIL PROTECTED] Maintainer, Linux USB Mass Storage Driver It was a new hope. -- Dust Puppy User Friendly, 12/25/1998 pgpv4xHNKnTsh.pgp Description: PGP signature
Re: [BUG] 2.6.24-git usb reset problems
On Tue, Jan 29, 2008 at 02:15:15PM +0200, Boaz Harrosh wrote: > Greg KH wrote: > > On Mon, Jan 28, 2008 at 09:49:35PM +0100, Jens Axboe wrote: > >> Hi, > >> > >> Running latest -git (head 91525300baf162e83e923b09ca286f9205e21522) and > >> connecting my cf usb storage device yields and endless stream of: > >> > >> Initializing USB Mass Storage driver... > >> scsi6 : SCSI emulation for USB Mass Storage devices > >> usb-storage: device found at 2 > >> usb-storage: waiting for device to settle before scanning > >> usbcore: registered new interface driver usb-storage > >> USB Mass Storage support registered. > >> scsi 6:0:0:0: Direct-Access Generic STORAGE DEVICE 0125 PQ: 0 > >> ANSI: 0 > >> sd 6:0:0:0: [sdb] 4001760 512-byte hardware sectors (2049 MB) > >> sd 6:0:0:0: [sdb] Write Protect is off > >> sd 6:0:0:0: [sdb] Mode Sense: 02 00 00 00 > >> sd 6:0:0:0: [sdb] Assuming drive cache: write through > >> sd 6:0:0:0: [sdb] 4001760 512-byte hardware sectors (2049 MB) > >> sd 6:0:0:0: [sdb] Write Protect is off > >> sd 6:0:0:0: [sdb] Mode Sense: 02 00 00 00 > >> sd 6:0:0:0: [sdb] Assuming drive cache: write through > >> sdb: sdb1 > >> sd 6:0:0:0: [sdb] Attached SCSI removable disk > >> sd 6:0:0:0: Attached scsi generic sg1 type 0 > >> scsi 6:0:0:1: Direct-Access Generic STORAGE DEVICE 0125 PQ: 0 > >> ANSI: 0 > >> usb 5-1: reset high speed USB device using ehci_hcd and address 2 > >> usb 5-1: reset high speed USB device using ehci_hcd and address 2 > >> usb 5-1: reset high speed USB device using ehci_hcd and address 2 > >> usb 5-1: reset high speed USB device using ehci_hcd and address 2 > >> usb 5-1: reset high speed USB device using ehci_hcd and address 2 > >> usb 5-1: reset high speed USB device using ehci_hcd and address 2 > >> usb 5-1: reset high speed USB device using ehci_hcd and address 2 > >> [...] > >> > >> until I disconnect it. The device doesn't work. Worked fine in 2.6.24. > >> I'm attaching boot messages and my .config. > > > > That's a bit wierd, as we haven't added any USB patches to the -git tree > > yet after 2.6.24 :) > > > > Could this be caused by some scsi changes perhaps? > > > > thanks, > > > > greg k-h > > - > Yes it is ;) > > Jens could you test the patch below? if it works I'll submit a proper > patch. Please forgive me for the bug. > > Matthew, Greg, Is there a way to extract from messages the usb storage > transport > used? I'm guessing it is freecom do to the fact that I find a bug there. The freecom transport is exceptionally rare these days. It's primary user was a device made by a company that went out of business. Matt -- Matthew Dharm Home: [EMAIL PROTECTED] Maintainer, Linux USB Mass Storage Driver Way to go, lava boy. -- Stef to Greg User Friendly, 3/26/1998 pgpeBHHebaraJ.pgp Description: PGP signature
Re: PATCH: usb-storage-set-last-sector-bug-flag.patch
ACKed-by: Matthew Dharm <[EMAIL PROTECTED]> Matt On Fri, Jan 25, 2008 at 11:12:21AM -0600, James Bottomley wrote: > On Thu, 2008-01-24 at 09:21 -0800, Greg KH wrote: > > On Thu, Jan 24, 2008 at 06:07:00PM +0100, Stefan Richter wrote: > > > Greg KH wrote: > > > > I just am worried that we are > > > > now suddenly keeping access from the last sector for devices that > > > > currently did work just fine. > > > > > > This new workaround doesn't prevent access to the last sector. It only > > > breaks up a multi-sector access which would also reach the last sector > > > into several (two? I'm too lazy to look back in the mail thread) > > > accesses, in order to access the last sector in a dedicated > > > single-sector access. > > > > > > So that's very differently to the fix-capacity workaround. The > > > fix-capacity workaround manipulates the READ CAPACITY parameter data. > > > Therefore the fix-capacity workaround is unsafe for non-buggy devices. > > > > > > The last-sector-(access-)bug workaround _only_ modifies the command > > > stream which is sent to the device. A dangerous command is replaced by > > > equivalent safe commands. These commands are luckily safe for _all_ > > > devices, buggy and non-buggy ones. The only cost of this workaround is > > > (1.) the code, (2.) the runtime/ bandwidth/ latency overhead for > > > accesses which reach the last sector. > > > > Ok, thanks for explaining it better. I have no objection to this change > > anymore. > > So, for forms sake to take this through the SCSI tree I need at least > one USB person to ack it ... > > James > -- Matthew Dharm Home: [EMAIL PROTECTED] Maintainer, Linux USB Mass Storage Driver It was a new hope. -- Dust Puppy User Friendly, 12/25/1998 pgpqFii90rEvw.pgp Description: PGP signature
Re: PATCH: usb-storage-psc1350-v4.patch (was Linux scsi / usb-mass-storage and HP printer cardreader bug + fix)
On Mon, Jan 14, 2008 at 10:33:08AM -0600, James Bottomley wrote: > > On Mon, 2008-01-14 at 08:03 -0800, Matthew Dharm wrote: > > We may be able to convince the SCSI people to enable it for all devices, > > regardless of HCD. > > No ... I'm not particularly keen to have enterprise vendors after my > blood ... Fair enough. Tho, we should probably just enable this blindly for all usb-storage devices. Otherwise, this is just going to become an unusual_devs.h nightmare. Matt -- Matthew Dharm Home: [EMAIL PROTECTED] Maintainer, Linux USB Mass Storage Driver What, are you one of those Microsoft-bashing Linux freaks? -- Customer to Greg User Friendly, 2/10/1999 pgpam87P3V9i0.pgp Description: PGP signature
Re: PATCH: usb-storage-psc1350-v4.patch (was Linux scsi / usb-mass-storage and HP printer cardreader bug + fix)
On Mon, Jan 14, 2008 at 10:46:56AM +0100, Hans de Goede wrote: > Guillaume Bedot wrote: > >But it fixes only two models. > >Do you think other devices (hp or not) can be impacted ? > >There are hundreds of models with card readers only for hp : > >http://hplip.sourceforge.net/supported_devices/combined.html > > > >Will this be possible to use "LAST_SECTOR_BUG" quirk for testing without > >recompiling a kernel ? > > > > This is not possible AFAIK, I've already wrote a blog post about this > asking for people to test this, but got no responses. Once the patches are accepted by the SCSI people, one of the things we can consider doing is enabling this quirk for all USB devices. It should be pretty harmless to all properly working devices, and the performance hit should be pretty minimal. We may be able to convince the SCSI people to enable it for all devices, regardless of HCD. Matt -- Matthew Dharm Home: [EMAIL PROTECTED] Maintainer, Linux USB Mass Storage Driver What the hell are you? -- Pitr to Dust Puppy User Friendly, 12/3/1997 pgpxaXUinOgMp.pgp Description: PGP signature
Re: [usb-storage] PATCH: usb-storage-psc1350-v4.patch (was Linux scsi / usb-mass-storage and HP printer cardreader bug + fix)
On Fri, Jan 11, 2008 at 09:14:00PM +0100, Hans de Goede wrote: > Boaz Harrosh wrote: > >Yes, you're right. in ULDs it is a much proper way to do this. > > > >So I guess you'll have to do that special host flag or device > >flag, and add a check for it in sd.c. You'll see that sd.c is > >already doing bufflen truncation at sd_prep_fn(), just add one > >more case. > > > > Done, thanks for the hint. Patch implementing my fix this way attached, > please apply. Well, I can't say that I'm really a big fan of matching a multi-interface device based on the interface class code, but I don't see a better solution that isn't a major coding project. This approach looks pretty reasonable to me. Matt -- Matthew Dharm Home: [EMAIL PROTECTED] Maintainer, Linux USB Mass Storage Driver SP: I sell software for Microsoft. Can you set me free? DP: Natural Selection says I shouldn't. -- MS Salesman and Dust Puppy User Friendly, 4/2/1998 pgpq398LhM1vO.pgp Description: PGP signature
Re: [linux-usb-devel] Linux scsi / usb-mass-storage and HP printer cardreader bug + fix
On Wed, Jan 09, 2008 at 10:44:49PM +0100, Hans de Goede wrote: > First of all sorry for the somewhat massive cross-posting, I've spend a > significant amount of time hunting down this bug, and so far the response > has been less the overwhelming. > The cardreader of the multi function printers will "crash" and from that > moment on no longer communicate in any sane way, if you try to read the > last sector of an sdcard* in a read that is more then 1 sector, so trying > to read 8 sectors starting at sector capicity-8 will crash it, as will > reading 2 sectors starting at sector capicity-2, however reading the last > sector in a one 1 sector read will succeed! (* xdcards seem to be fine). To continue the history on this we over in usb-storage land looked at this and think it belongs in the SCSI layer. We don't like changing commands in-flight; it has, historically, caused us all sorts of issues in the past. Furthermore, this seems like the likely sort of off-by-one bug that can affect many types of devices, not just USB. I'd really like to see this in sd_mod -- I have no objection to requiring an HCD to set a flag to indicate that it should be used, if really desired. But, it seems to me to be a much easier change to make where the command originated rather than in mid-flight. Matt -- Matthew Dharm Home: [EMAIL PROTECTED] Maintainer, Linux USB Mass Storage Driver P: Nine more messages in admin.policy. M: I know, I'm typing as fast as I can! -- Pitr and Mike User Friendly, 11/27/97 pgp7WbiNzH5gI.pgp Description: PGP signature
Re: [linux-usb-devel] NEXX NF-315: unusual_devs.h entry submission
(CC'ing linux-scsi on this) On Thu, Nov 08, 2007 at 01:28:53AM +0300, Serge (gentoosiast) Koksharov wrote: > On Wed, Nov 07, 2007 at 02:31:45PM -0500, Alan Stern wrote: > > This suggests that the device needs a longer timeout for the INQUIRY > > command. The default timeout is 5 seconds (the driver adds an extra > > 0.5 seconds for some reason), but it is a module parameter you can > > adjust. Try adding > > > > options sd_mod inq_timeout=10 > > > > to your /etc/modprobe.conf. This might fix the problem. > > Yes! Your suggestion solved my problem, thank you very much. What we have here is a device which takes a particularly long time to respond to an INQUIRY command (a little over 6 seconds, I think). Would there be any objections to permanently modifying sd_mod to change the default INQUIRY timeout to 10 seconds (currently 5)? Matt -- Matthew Dharm Home: [EMAIL PROTECTED] Maintainer, Linux USB Mass Storage Driver G: Baaap booop BAHHHP. Mir: 9600 Baud? Mik: No, no! 9600 goes baap booop, not booop bahhhp! -- Greg, Miranda and Mike User Friendly, 12/31/1998 pgpuV5SMUfqiG.pgp Description: PGP signature
Re: [PATCH 09/24] libata-scsi: convert to use the data buffer accessors
On Tue, Sep 11, 2007 at 08:09:51PM -0400, Jeff Garzik wrote: > I would much rather see the !use_sg cleanup in a separate patch series... Are we really sure this can all go? No requests, not even ones from SG_IO will ever use the non-sg paths? Matt -- Matthew Dharm Home: [EMAIL PROTECTED] Maintainer, Linux USB Mass Storage Driver I could always suspend a few hundred accounts and watch what happens. -- Tanya User Friendly, 7/31/1998 pgpgOsi3ElyJ1.pgp Description: PGP signature
Re: [PATCH ver2 2/5] scsi_error: Refactoring scsi_error to facilitate in synchronous REQUEST_SENSE
On Mon, Sep 10, 2007 at 10:35:25PM +0300, Boaz Harrosh wrote: > diff --git a/drivers/scsi/scsi_error.c b/drivers/scsi/scsi_error.c > index 20a72aa..a02400c 100644 > --- a/drivers/scsi/scsi_error.c > +++ b/drivers/scsi/scsi_error.c > @@ -590,42 +590,23 @@ static void scsi_abort_eh_cmnd(struct scsi_cmnd *scmd) > } > > /** > - * scsi_send_eh_cmnd - submit a scsi command as part of error recory > + * scsi_eh_prep_cmnd - Save a scsi command info as part of error recory > * @scmd: SCSI command structure to hijack > - * @cmnd: CDB to send > + * @ses:structure to save restore information > + * @cmnd: CDB to send. Can be NULL if no new cmnd is needed > * @cmnd_size: size in bytes of @cmnd > - * @timeout:timeout for this request > - * @copy_sense: request sense data if set to 1 > + * @copy_sense: size of sense data to copy. or 0 > * > - * This function is used to send a scsi command down to a target device > - * as part of the error recovery process. If @copy_sense is 0 the command > - * sent must be one that does not transfer any data. If @copy_sense is 1 > - * the command must be REQUEST_SENSE and this functions copies out the > - * sense buffer it got into @scmd->sense_buffer. > - * > - * Return value: > - *SUCCESS or FAILED or NEEDS_RETRY > + * This function is used to save a scsi command information before > re-execution > + * as part of an error recovery process. If @copy_sense is 0 the command > + * given must be one that does not transfer any data. If @copy_sense != 0 > + * the command should be NULL and this functions sets up the cmnd and > + * command buffers to be read into @scmd->sense_buffer. > **/ > -static int scsi_send_eh_cmnd(struct scsi_cmnd *scmd, unsigned char *cmnd, > - int cmnd_size, int timeout, unsigned copy_sense) > +void scsi_eh_prep_cmnd(struct scsi_cmnd *scmd, struct scsi_eh_save *ses, > + unsigned char *cmnd, int cmnd_size, unsigned copy_sense) I'm not terribly keen on the naming of copy_sense, tho I see what you're trying to do. A better name and better comments about what it means when != 0 would fix this. Matt -- Matthew Dharm Home: [EMAIL PROTECTED] Maintainer, Linux USB Mass Storage Driver My mother not mind to die for stoppink Windows NT! She is rememberink Stalin! -- Pitr User Friendly, 9/6/1998 pgpe8ZGDfkPEc.pgp Description: PGP signature
Re: [patchset 0/5] Refactoring scsi_error to facilitate in synchronous REQUEST_SENSE
On Mon, Sep 10, 2007 at 05:11:23PM +0300, Boaz Harrosh wrote: > > In motivation to abstract scsi_cmnd members and insulate > drivers/transports from scsi_cmnd internals. The last > place left was the REQUEST_SENSE sequence when done > synchronous, by drivers. This probably isn't serious, but I noticed one thing (beyond what Alan's analysis noted)... I've always assumed that the scatterlist structs passed to an HCD were, themselves, allocated from DMA-able memory. That is, not just the transfer buffers themselves, but the struct scatterlist also. In this implementation, the struct scatterlist used for the single-element transfer of the request sense buffer is part of the struct scsi_eh_save_cmnd_info, which is allocated on the stack (for at least usb-storage). And, stack isn't DMA-able on all arches. It is not a problem for usb-storage, since the struct scatterlists are processed in code into a series of URBs, so nobody actually does DMA the scatterlist structures. However, I don't know enough about the other HCDs to be certain about them. Matt -- Matthew Dharm Home: [EMAIL PROTECTED] Maintainer, Linux USB Mass Storage Driver Now payink attention, please. This is mouse. Click-click. Easy to use, da? Now you try... -- Pitr to Miranda User Friendly, 10/11/1998 pgpPGNEVQ5NsY.pgp Description: PGP signature
Re: Errors on USB-storage device are ignored.
Off the cuff, this really looks like something for the SCSI layer. I'll
bet there are SCSI devices that do something similar...
And, I'm generally reluctant to modify the data to/from a device unless
usb-storage *really* has to in order to make it work
Matt
On Thu, Aug 16, 2007 at 04:58:17PM +0200, Rogier Wolff wrote:
>
> Hi,
>
> I have an usb-storage enclosure that houses a normal desktop
> harddrive. I have been wondering why disks in that enclosure
> seemed to be having less errors than when connected to a
> normal IDE connector.
>
> The reason is: USB-storage is ignoring a hint that something is
> wrong. Probably my enclosure is also not completely following specs,
> but Linux is ignoring the hint as well
>
> On hitting a bad block, the disk reports error. The USB converter
> then reports "auto-sense-required", and this is carried out. However
> at this point, my USB enclosure returns all-zeroes. This is
> considered non-fatal by the kernel.
>
> I'm guessing not many people are testing these things with
> bad drives. So, I don't know wether or not other USB converters
> handle this situation more gracefully.
>
> As a patch, I've decided to set the sense key to "vendor specific"
> (9), and then no "additional sense" (0:0), if, and only if the device
> didn't return any valid sense info.
>
> The rest of the kernel then correctly interprets the situation
> as an IO error.
>
> Roger Wolff.
>
> --- linux-2.6.20.3.clean/drivers/usb/storage/transport.c 2007-03-13
> 19:27:08.0 +0100
> +++ linux-2.6.20.3.kostunrix/drivers/usb/storage/transport.c 2007-08-16
> 16:47:00.0 +0200
> @@ -629,6 +629,14 @@
>
> /* let's clean up right away */
> memcpy(srb->sense_buffer, us->sensebuf, US_SENSE_SIZE);
> + if (((srb->sense_buffer[2]&0xf) == 0) &&
> + (srb->sense_buffer[12] == 0) &&
> + (srb->sense_buffer[13] == 0)) {
> + /* Hm. The device requested sense, but then
> +declined to give us more info -- REW */
> + srb->sense_buffer[2] |= 0x09; /* Vendor specific */
> + }
> +
> srb->resid = old_resid;
> srb->request_buffer = old_request_buffer;
> srb->request_bufflen = old_request_bufflen;
>
>
>
> --
> ** [EMAIL PROTECTED] ** http://www.BitWizard.nl/ ** +31-15-2600998 **
> **Delftechpark 26 2628 XH Delft, The Netherlands. KVK: 27239233**
> *-- BitWizard writes Linux device drivers for any device you may have! --*
> Q: It doesn't work. A: Look buddy, doesn't work is an ambiguous statement.
> Does it sit on the couch all day? Is it unemployed? Please be specific!
> Define 'it' and what it isn't doing. - Adapted from lxrbot FAQ
--
Matthew Dharm Home: [EMAIL PROTECTED]
Maintainer, Linux USB Mass Storage Driver
G: Money isn't everything, A.J.
AJ: Who convinced you of that?
G: The Chief, at my last salary review.
-- Mike and Greg
User Friendly, 11/3/1998
pgpmflfuoAEDR.pgp
Description: PGP signature
Re: [usb-storage] [PATCH]indistinguishable devices with broken and unbroken firmware #2
On Fri, Feb 09, 2007 at 10:30:37AM -0500, Alan Stern wrote: > On Thu, 8 Feb 2007, Greg KH wrote: > > > On Thu, Feb 08, 2007 at 09:04:48AM +0100, Oliver Neukum wrote: > > > Hi, > > > > > > there's a USB mass storage device which exists in two version. One > > > reports the correct size and the other does not. Apart from that they > > > are identical and cannot be told apart. Here's a heuristic based on the > > > empirical finding that drives have even sizes. > > > > > > The requested changes have been made. > > > Greg, can this go through your tree? > > > > If the usb-storage people ACK it, I'll be glad to add it to my trees. > > It's okay with me. > > Acked-by: Alan Stern <[EMAIL PROTECTED]> Looks okay to me too. Acked-by: Matthew Dharm <[EMAIL PROTECTED]> Matt -- Matthew Dharm Home: [EMAIL PROTECTED] Maintainer, Linux USB Mass Storage Driver E: You run this ship with Windows?! YOU IDIOT! L: Give me a break, it came bundled with the computer! -- ESR and Lan Solaris User Friendly, 12/8/1998 pgp85ptVottNv.pgp Description: PGP signature
Re: [Linux-usb-users] Possible bug in usb storage (2.6.11 kernel)
On Thu, Sep 08, 2005 at 02:28:09PM -0600, Jim Ramsay wrote: > On 9/8/05, Jim Ramsay <[EMAIL PROTECTED]> wrote: > > On 9/8/05, Matthew Dharm <[EMAIL PROTECTED]> wrote: > > > On Thu, Sep 08, 2005 at 11:14:36AM -0600, Jim Ramsay wrote: > > > > I think I have found a possible bug: > > > > [...] > > > > I suppose the scsi code could be changed to guarantee that > > > > srb->request_buffer is page-aligned or cache-aligned, but that seems > > > > like the wrong solution for this bug. > > > > > > Fixing the SCSI layer is -exactly- the correct solution. The SCSI layer > > > is > > > supposed to guarantee us that those buffers are suitable for DMA'ing, and > > > apparently it's violating that promise. > > > > Thanks, I'll check on what buffer I'm actually getting, where it's > > allocated, and post back what I find, or how I fixed it. > > More information: > > The error only occurrs during device sensing when the > srb->request_buffer is assigned as follows, by usb/storage/transport.c > in the routine usb_stor_invoke_transport: > > old_request_buffer = srb->request_buffer; > srb->request_buffer = srb->sense_buffer; > > Now, this is a problem because srb->sense_buffer is defined as follows > in the struct scsi_cmnd: > > #define SCSI_SENSE_BUFFERSIZE 96 > unsigned char sense_buffer[SCSI_SENSE_BUFFERSIZE]; > > Since it is not allocated at runtime there is NO WAY the SCSI layer > can possibly guarantee it is page- or cache-aligned and ready for DMA. > > Any suggestions on best fix for this? Is it still a SCSI-layer issue? > Or should USB step up in this case and ensure this buffer is dma-safe > itself? Ah, that buffer doesn't come from SCSI (tho I've long thought they should provide us with a sense data buffer). So this is a real usb-storage bug. Matt -- Matthew Dharm Home: [EMAIL PROTECTED] Maintainer, Linux USB Mass Storage Driver What, are you one of those Microsoft-bashing Linux freaks? -- Customer to Greg User Friendly, 2/10/1999 pgp3WIy2GXvii.pgp Description: PGP signature
Re: [PATCH as470] Add a NOREPORTLUN blacklist flag
On Sun, Feb 20, 2005 at 10:44:21PM -0500, Alan Stern wrote:
> On Sun, 20 Feb 2005, Sergey Vlasov wrote:
>
> > On Thu, 17 Feb 2005 17:31:04 -0500 (EST) Alan Stern wrote:
> >
> > > James:
> > >
> > > This patch adds a NOREPORTLUN blacklist flag for a disk made by "WDC"
> > > (Winchester?). The drive's firmware crashes when it receives
> > > REPORT_LUNS, even though it claims to be SCSI rev 04.
> > >
> > > Alan Stern
> > >
> > >
> > >
> > > Signed-off-by: Alan Stern <[EMAIL PROTECTED]>
> > >
> > > = drivers/scsi/scsi_devinfo.c 1.14 vs edited =
> > > --- 1.14/drivers/scsi/scsi_devinfo.c 2004-12-10 11:54:56 -05:00
> > > +++ edited/drivers/scsi/scsi_devinfo.c2005-02-16 11:30:56 -05:00
> > > @@ -201,6 +201,7 @@
> > > {"WangDAT", "Model 2600", "01.7", BLIST_SELECT_NO_ATN},
> > > {"WangDAT", "Model 3200", "02.2", BLIST_SELECT_NO_ATN},
> > > {"WangDAT", "Model 1300", "02.4", BLIST_SELECT_NO_ATN},
> > > + {"WDC WD25", "00JB-00FUA0", NULL, BLIST_NOREPORTLUN},
> >
> > This does not look like a right solution. WD2500JB is an IDE disk made
> > by Western Digital:
> >
> > http://www.wdc.com/en/products/Products.asp?DriveID=42
> >
> > Therefore the problematic LaCie device is really an USB/Firewire-to-IDE
> > adapter with the WD2500JB drive in a box. And it is the USB-IDE part
> > which fails on the REPORT_LUNS command, not the IDE disk. Probably
> > there are other LaCie devices with the same adapter but different disks
> > inside; adding all such IDE disks to the SCSI blacklist does not seem
> > like a good solution. The usb-storage blacklist seems like a better
> > place for such entry.
>
> You are quite correct. In fact, another user with a different brand of
> USB-IDE converter just wrote in with exactly the same problem.
>
> James, please withdraw the patch above.
>
> Matt, it looks like the best way to solve this problem is to go back to
> the old strategy of always setting the SCSI revision to 2 (no matter what
> it might actually be), at least for Direct Access devices. That would
> suppress the REPORT_LUNS command. Would we lose anything by doing this?
Besides the use of REPORT_LUNS on devices which actually support it? I
don't think so...
I wonder if printing a warning if sdev->scsi_level > SCSI_2 would be
useful...
Matt
--
Matthew Dharm Home: [EMAIL PROTECTED]
Maintainer, Linux USB Mass Storage Driver
You are needink to look more evil. You likink very strong coffee?
-- Pitr to Dust Puppy
User Friendly, 10/16/1998
pgpmEVI8kSRky.pgp
Description: PGP signature
Re: mkfs problem
I've seen this error on several USB devices I'm working on, also. It appears that mkfs.msdos needs an actual drive geometery, not just a sector size and number of sectors. If anyone knows an easy way around this, I'd like to know it too. Matt On Mon, Jun 11, 2001 at 10:19:17PM -0600, Martin Lichtin wrote: > Anyone know what the problem could be here? > > root# mkfs.msdos -F 32 -I /dev/scd1 > mkfs.msdos: unable to get drive geometry for '/dev/scd1' > mkfs.msdos 2.2 (06 Jul 1999) > > scd1 is a DVD-RAM drive. What's weird is it doesn't happen > in all cases. Also, creating a ext2 fs on that device > works just fine. > > Thanks for a hint, > Martin > - > To unsubscribe from this list: send the line "unsubscribe linux-scsi" in > the body of a message to [EMAIL PROTECTED] -- Matthew Dharm Home: [EMAIL PROTECTED] Maintainer, Linux USB Mass Storage Driver But where are the THEMES?! How do you expect me to use an OS without themes?! -- Stef User Friendly, 10/9/1998 PGP signature
Re: Changing MAX_COMMAND_SIZE within the 2.4.x timeframe?
Eric -- Did you ever get a chance to work up these patches and test them? Matt On Fri, Feb 16, 2001 at 09:28:16AM -0500, Eric Youngdale wrote: > >rm... how about something like this: > > > >We add a field to the Scsi_Host structure which would indicate if they are > >SCSI-III able. By default, this field will be initialized to 0, indicating > >only 12-byte command readyness. The mid-level will reject cmd_len > 12 > >unless this byte is != 0. > > After reflection, my inclination is that the *correct* solution is to > fix the low-level drivers to reject the SCSI-III commands themselves. This > is more consistent with the devolution of authority from the mid-level to > the individual low-level drivers that has been going on. Unfortunately a > patch to implement this would be harder to implement. For 2.4, I would be > more tempted to go with what you describe above. > > The infrastructure support for this is quite trivial. Add a bit to the > bitfield saying that the thing is SCSI-III capable, initialize it :-), and > add some minor logic to reject 16-byte commands to hosts that are not marked > as SCSI-III. For that matter, it would be possible (and cleaner) for the > generics driver to simply reject the things outright and not even attempt to > queue them in the first place... > > I can work up the patches over the weekend, and send them out. I > haven't heard anyone raise any objections about either approach > > -Eric > > >Short, sweet, and to the point. The question is, can we get it in more > >sooner than later? I'd really like to get all this integrated for a later > >2.4.x kernel. > > - Original Message - > From: "Matthew Dharm" <[EMAIL PROTECTED]> > To: "Eric Youngdale" <[EMAIL PROTECTED]> > Cc: "Linux SCSI list" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> > Sent: Thursday, February 15, 2001 4:59 PM > Subject: Re: Changing MAX_COMMAND_SIZE within the 2.4.x timeframe? > > > > - > To unsubscribe from this list: send the line "unsubscribe linux-scsi" in > the body of a message to [EMAIL PROTECTED] -- Matthew Dharm Home: [EMAIL PROTECTED] Maintainer, Linux USB Mass Storage Driver I could always suspend a few hundred accounts and watch what happens. -- Tanya User Friendly, 7/31/1998 PGP signature
Re: Changing MAX_COMMAND_SIZE within the 2.4.x timeframe?
On Thu, Feb 15, 2001 at 04:40:35PM -0500, Eric Youngdale wrote: > My preference is that 16-byte commands not even reach low-level drivers > that are not prepared to deal with them. It would be a little more work to > get it set up, but on the whole it would be safer, esp if we are considering > this for 2.4. > > A cleaner solution would probably be to patch each and every driver to > reject SCSI-III commands, and then remove the patch for drivers that are > known to accept 16-byte commands. Yech - the low-level driver count is now > hovering around 80. > > Also keep in mind that we as of yet have no record in the Scsi_Host > structure to say whether a host is SCSI-III or not. Hrm... how about something like this: We add a field to the Scsi_Host structure which would indicate if they are SCSI-III able. By default, this field will be initialized to 0, indicating only 12-byte command readyness. The mid-level will reject cmd_len > 12 unless this byte is != 0. Short, sweet, and to the point. The question is, can we get it in more sooner than later? I'd really like to get all this integrated for a later 2.4.x kernel. Matt -- Matthew Dharm Home: [EMAIL PROTECTED] Maintainer, Linux USB Mass Storage Driver What, are you one of those Microsoft-bashing Linux freaks? -- Customer to Greg User Friendly, 2/10/1999 PGP signature
Re: Changing MAX_COMMAND_SIZE within the 2.4.x timeframe?
On Thu, Feb 15, 2001 at 03:57:46PM -0500, Eric Youngdale wrote: > It is a little more than just changing the define. I believe (and other > people have confirmed) that some of the older host adapters would be unable > to handle the larger command sizes. The limitations could be > hardware/firmware in some cases. To be really safe, we probably want to > limit 16-byte commands to host adapters that claim to be ready for them. > Thus I believe that such a change would involve first adding a field for a > maximum command size to the Scsi_Host structure, which gets initialized to > 12 by default. Hrm... are you saying that they couldn't handle the larger buffer, or the larger command? If it's the larger command, that's fine with me. Just don't send that command. Just because we have the larger buffer doesn't mean that everything will support the larger commands. I hardly expect a SCSI-I adapter to respect SCSI-III standards. If you're saying the larger buffer... I'm a bit stunned. How is that possible? So the array is too long... is someone trying to map Scsi_Request data structures directly onto some sort of adapter memory? Matt -- Matthew Dharm Home: [EMAIL PROTECTED] Maintainer, Linux USB Mass Storage Driver What, are you one of those Microsoft-bashing Linux freaks? -- Customer to Greg User Friendly, 2/10/1999 PGP signature
Changing MAX_COMMAND_SIZE within the 2.4.x timeframe?
Okay, this is partially political and partially technical. Linus, since you're the final arbiter of these issues, your input is greatly appreciated. I'm working on integrating support for some USB Mass Storage devices. Unfortunately, these devices are pretty much on the cutting edge, so they use 16 byte commands. One of the features of my driver is that I do an in-place manipulation of SCSI commands as they fly by, to translate them so they will be properly understood on the receiving end. For most devices, the 12 bytes allocated for a SCSI command provides an adequate buffer (even for ATAPI devices). However, for this device, a 16 byte buffer is necessary. Normally, I'd just go allocating my own buffer for this... but it occurs to me that there has been much talk of changing the MAX_COMMAND_SIZE from 12 to 16 to support SCSI-III devices. A quick grep of drivers/scsi shows that MAX_COMMAND_SIZE is only used to allocate arrays and fill them with 0, so it _looks_ like just changing the #define in scsi.h to 16 will work _just_fine_ with no other code modifications. The question is this: Could this actually happen for 2.4.2? We can solve the technical problems, so the only thing to overcome is the "should we be changing this in a 2.4.x kernel" question. There's been discussion in the past, which boiled down to "we'll do it when we need it". And it looks easily doable. And we need it. Comments? Matt -- Matthew Dharm Home: [EMAIL PROTECTED] Maintainer, Linux USB Mass Storage Driver P: How about "Web Designer"? DP: I'd like a name that people won't laugh at. -- Pitr and Dust Puppy User Friendly, 12/6/1997 PGP signature
