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 st...@rowland.harvard.edu 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 wor...@alum.mit.edu wrote: From: Alan Stern st...@rowland.harvard.edu 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
: 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 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
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] 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 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_BUF);
- if (buflen srb-request_bufflen)
- srb-resid = srb-request_bufflen - buflen;
+
+ /* Check for overflow */
+ if (buflen scsi_bufflen(srb))
+ count = buflen;
+
+ scsi_set_resid(srb, scsi_bufflen(srb) - count);
}
--
1.5.3.3
--
Matthew Dharm Home: [EMAIL PROTECTED]
Maintainer, Linux USB Mass Storage Driver
M: No, Windows doesn't have any nag screens.
C: Then what are those blue and white screens I get every day
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: [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: [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 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: 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: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: 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: [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: [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: [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
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
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
