strange USB storage failure with 2.6.29-rc2
A message that is not in the archive (sent off-list or not yet received): [email protected]
A message that is not in the archive (sent off-list or not yet received): [email protected]
A message that is not in the archive (sent off-list or not yet received): Pine.LNX.4.44L0.0901271548370.2286-100000-IYeN2dnnYyZXsRXLowluHWD2FQJk+8+b@public.gmane.org
Copied to linux-scsi, so a bit context for folks there...
On a 64bit 2.6.29-rc2 system (and a few earlier kernels that I have tried) I can no longer use USB sticks. When I connect one it gets correctly identified, but then when I try to access it I get "Medium not present" error.
Turning on debugging in the USB storage subsystem indicates that we are sending START_STOP to the device which really confuses it...
Quoted 24 lines · On Tue, 27 Jan 2009 15:56:11 -0500 (EST) Alan Stern…
Quoted 13 lines · Dirk Hohndel
Here you go:
From the middle of the log (after the partition table has been read):
[ 32.056855] usb-storage: queuecommand called [ 32.056886] usb-storage: *** thread awakened. [ 32.056888] usb-storage: Command START_STOP (6 bytes) [ 32.056889] usb-storage: 1b 00 00 00 02 00 [ 32.056894] usb-storage: Bulk Command S 0x43425355 T 0x24 L 0 F 0 Trg 0 LUN 0 CL 6 [ 32.056896] usb-storage: usb_stor_bulk_transfer_buf: xfer 31 bytes [ 32.057328] usb-storage: Status code 0; transferred 31/31 [ 32.057329] usb-storage: -- transfer complete [ 32.057330] usb-storage: Bulk command transfer result=0Quoted 8 lines
[ 32.057332] usb-storage: Attempting to get CSW... [ 32.057333] usb-storage: usb_stor_bulk_transfer_buf: xfer 13 bytes [ 32.057430] usb-storage: Status code 0; transferred 13/13 [ 32.057432] usb-storage: -- transfer complete [ 32.057433] usb-storage: Bulk status result = 0 [ 32.057435] usb-storage: Bulk Status S 0x53425355 T 0x24 R 0 Stat 0x0 [ 32.057437] usb-storage: scsi cmd done, result=0x0 [ 32.057440] usb-storage: *** thread sleeping.
Quoted 3 lines
This command is basically an Eject. Even though the device doesn't have removable media, it apparently gets very confused when it receives this command.
Doing some googling around that seems to imply that this is not unusual for USB devices...
Quoted 4 lines
So the real question is: Who is responsible for sending that Eject command? It certainly isn't usb-storage or any other part of the USB stack. Maybe something in the SCSI disk driver or maybe a user program.
That's one valid question... maybe someone on the linux-scsi list can sched some light onto this? Are there SCSI specific debugging options I should turn on?
The other one is "why isn't the USB stack filtering that command when it comes down from SCSI?"
Way back when in 2002 Matt Dharm suggested doing just that and Greg applied it:
http://osdir.com/ml/usb.devel/2002-08/msg00357.html
http://osdir.com/ml/usb.devel/2002-08/msg00447.html
A few months later this code was removed again as we allegedly don't need it anymore:
Maybe we need to bring such code back?
/D
Signature · 6 lines
Dirk Hohndel Intel Open Source Technology Center -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
A message that is not in the archive (sent off-list or not yet received): [email protected]
Quoted 37 lines · Dirk Hohndel
Copied to linux-scsi, so a bit context for folks there...
On a 64bit 2.6.29-rc2 system (and a few earlier kernels that I have tried) I can no longer use USB sticks. When I connect one it gets correctly identified, but then when I try to access it I get "Medium not present" error.
Turning on debugging in the USB storage subsystem indicates that we are sending
START_STOPto the device which really confuses it...Quoted 24 lines · On Tue, 27 Jan 2009 15:56:11 -0500 (EST) Alan Stern…
Quoted 21 lines · Dirk Hohndel
Here you go:
From the middle of the log (after the partition table has been read):
[ 32.056855] usb-storage: queuecommand called [ 32.056886] usb-storage: *** thread awakened. [ 32.056888] usb-storage: Command START_STOP (6 bytes) [ 32.056889] usb-storage: 1b 00 00 00 02 00 [ 32.056894] usb-storage: Bulk Command S 0x43425355 T 0x24 L 0 F 0 Trg 0 LUN 0 CL 6 [ 32.056896] usb-storage: usb_stor_bulk_transfer_buf: xfer 31 bytes [ 32.057328] usb-storage: Status code 0; transferred 31/31 [ 32.057329] usb-storage: -- transfer complete [ 32.057330] usb-storage: Bulk command transfer result=0 [ 32.057332] usb-storage: Attempting to get CSW... [ 32.057333] usb-storage: usb_stor_bulk_transfer_buf: xfer 13 bytes [ 32.057430] usb-storage: Status code 0; transferred 13/13 [ 32.057432] usb-storage: -- transfer complete [ 32.057433] usb-storage: Bulk status result = 0 [ 32.057435] usb-storage: Bulk Status S 0x53425355 T 0x24 R 0 Stat 0x0 [ 32.057437] usb-storage: scsi cmd done, result=0x0 [ 32.057440] usb-storage: *** thread sleeping.
Quoted 6 lines
Quoted 3 lines
This command is basically an Eject. Even though the device doesn't have removable media, it apparently gets very confused when it receives this command.
Doing some googling around that seems to imply that this is not unusual for USB devices...
At least, it isn't unusual for devices that don't have removable media. Devices that do usually know how to interpret Eject commands. :-)
Quoted 8 lines
Quoted 4 lines
So the real question is: Who is responsible for sending that Eject command? It certainly isn't usb-storage or any other part of the USB stack. Maybe something in the SCSI disk driver or maybe a user program.
That's one valid question... maybe someone on the linux-scsi list can sched some light onto this? Are there SCSI specific debugging options I should turn on?
I don't see anything in the sd driver that could have done it. And I don't know where else in the kernel it would have come from -- which is not to say that I'm familiar with every part of the kernel!
Quoted 2 lines
The other one is "why isn't the USB stack filtering that command when it comes down from SCSI?"
The USB stack doesn't do any filtering. The SCSI stack is supposed to know what commands should and should not be sent.
Furthermore, it seems quite likely this command was sent by userspace, not by the SCSI stack -- in which case the program is supposed to know what commands it shouldn't send.
Quoted 10 lines
Way back when in 2002 Matt Dharm suggested doing just that and Greg applied it:
http://osdir.com/ml/usb.devel/2002-08/msg00357.html
http://osdir.com/ml/usb.devel/2002-08/msg00447.htmlA few months later this code was removed again as we allegedly don't need it anymore:
Like I said, the SCSI stack was fixed so that it didn't send the wrong commands.
Quoted 1 line
Maybe we need to bring such code back?
Definitely not! The correct approach to is to find the program responsible for sending that command and fix it.
Unfortunately, I don't know any easy way to identify programs as they send SCSI commands. I suppose you could add some debugging statements in block/scsi_ioctl.c and drivers/scsi/sg.c to monitor all those commands as they come in from userspace. There are several different pathways for this, and the command could come from any of them.
Or you could guess that the offending command is sent by a system/desktop utility, such as hal or udev. Have you added or changed any software in that area recently?
Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
Quoted 5 lines · On Wed, 28 Jan 2009 11:54:39 -0500 (EST) Alan Stern…
Quoted 5 lines
Quoted 4 lines
So the real question is: Who is responsible for sending that Eject command? It certainly isn't usb-storage or any other part of the USB stack. Maybe something in the SCSI disk driver or maybe a user program.
Quoted 7 lines
Quoted 3 lines
That's one valid question... maybe someone on the linux-scsi list can sched some light onto this? Are there SCSI specific debugging options I should turn on?
I don't see anything in the sd driver that could have done it. And I don't know where else in the kernel it would have come from -- which is not to say that I'm familiar with every part of the kernel!
I did some greping and couldn't find anything suspicious, either.
Quoted 9 lines
Quoted 2 lines
The other one is "why isn't the USB stack filtering that command when it comes down from SCSI?"
The USB stack doesn't do any filtering. The SCSI stack is supposed to know what commands should and should not be sent.
Furthermore, it seems quite likely this command was sent by userspace, not by the SCSI stack -- in which case the program is supposed to know what commands it shouldn't send.
Not sure I agree with that logic. If the USB stack KNOWS that non-removable devices get upset by this command, then it would be appropriate for it to filter those out - to protect from bugs as much as to protect from denial of service attacks.
Quoted 4 lines
Quoted 1 line
Maybe we need to bring such code back?
Definitely not! The correct approach to is to find the program responsible for sending that command and fix it.
That's definitely something we should do (and I will continue to hunt this down), but my logic above still applies. I think this should have a WARN_ON around it, but should still be filtered.
Quoted 5 lines
Unfortunately, I don't know any easy way to identify programs as they send SCSI commands. I suppose you could add some debugging statements in
block/scsi_ioctl.canddrivers/scsi/sg.cto monitor all those commands as they come in from userspace. There are several different pathways for this, and the command could come from any of them.
That's why I copied the scsi list, hoping that they have some tools / ideas how to do this.
Quoted 3 lines
Or you could guess that the offending command is sent by a system/desktop utility, such as hal or udev. Have you added or changed any software in that area recently?
As I mentioned, I tried this in runlevel 3 - no desktop running. And this is on an (as far as I can remember) unmodified F10 64bit... so I'm surprised that I appear to be the only one reporting this; which of course makes me challenge my own "unmodified" statement :-)
/D
Signature · 2 lines
Dirk Hohndel Intel Open Source Technology Center
Quoted 6 lines · Dirk Hohndel
Quoted 6 lines
Quoted 2 lines
The other one is "why isn't the USB stack filtering that command when it comes down from SCSI?"
The USB stack doesn't do any filtering. The SCSI stack is supposed to know what commands should and should not be sent.
Quoted 8 lines
Quoted 3 lines
Furthermore, it seems quite likely this command was sent by userspace, not by the SCSI stack -- in which case the program is supposed to know what commands it shouldn't send.
Not sure I agree with that logic. If the USB stack KNOWS that non-removable devices get upset by this command, then it would be appropriate for it to filter those out - to protect from bugs as much as to protect from denial of service attacks.
Part of the problem is that many devices claim to have removable media when in fact they don't. And going back to your first email message, I see that your device is one of them:
Quoted 2 lines
Jan 22 13:49:53 dhohndel-mobl4 kernel: [ 46.329437] sd 4:0:0:0: [sdb] Attached SCSI \
removable disk^^^^^^^^^
In any case, usb-storage is just a transport. It sends commands from higher up (the SCSI stack) to a USB device. It filters the commands as little as possible. In other words, don't blame the messenger for delivering a bad message.
Quoted 8 lines
Quoted 4 lines
Quoted 1 line
Maybe we need to bring such code back?
Definitely not! The correct approach to is to find the program responsible for sending that command and fix it.
That's definitely something we should do (and I will continue to hunt this down), but my logic above still applies. I think this should have a
WARN_ONaround it, but should still be filtered.
Nope. How would people feel when they triggered your WARN_ON every time they ejected a disc from their USB CD-ROM drive?
Quoted 5 lines
Quoted 3 lines
Or you could guess that the offending command is sent by a system/desktop utility, such as hal or udev. Have you added or changed any software in that area recently?
As I mentioned, I tried this in runlevel 3 - no desktop running.
Both hal and udev would still be running in level 3.
Quoted 4 lines
And
this is on an (as far as I can remember) unmodified F10 64bit... so I'm surprised that I appear to be the only one reporting this; which of course makes me challenge my own "unmodified" statement :-)
Alan Stern
Quoted 21 lines · On Wed, 28 Jan 2009 12:47:45 -0500 (EST) Alan Stern…
Quoted 6 lines · Dirk Hohndel
Quoted 6 lines
Quoted 2 lines
The other one is "why isn't the USB stack filtering that command when it comes down from SCSI?"
The USB stack doesn't do any filtering. The SCSI stack is supposed to know what commands should and should not be sent.
Quoted 8 lines
Quoted 3 lines
Furthermore, it seems quite likely this command was sent by userspace, not by the SCSI stack -- in which case the program is supposed to know what commands it shouldn't send.
Not sure I agree with that logic. If the USB stack KNOWS that non-removable devices get upset by this command, then it would be appropriate for it to filter those out - to protect from bugs as much as to protect from denial of service attacks.
Part of the problem is that many devices claim to have removable media when in fact they don't. And going back to your first email message, I see that your device is one of them:
Quoted 8 lines
Quoted 2 lines
Jan 22 13:49:53 dhohndel-mobl4 kernel: [ 46.329437] sd 4:0:0:0: [sdb] Attached SCSI \ removable disk^^^^^^^^^In any case, usb-storage is just a transport. It sends commands from higher up (the SCSI stack) to a USB device. It filters the commands as little as possible. In other words, don't blame the messenger for delivering a bad message.
I had missed that part that the stick claimed to be a removable device (it is, in a sense, but then it shouldn't balk at being ejected).
Quoted 11 lines
Quoted 8 lines
Quoted 4 lines
Quoted 1 line
Maybe we need to bring such code back?
Definitely not! The correct approach to is to find the program responsible for sending that command and fix it.
That's definitely something we should do (and I will continue to hunt this down), but my logic above still applies. I think this should have a
WARN_ONaround it, but should still be filtered.Nope. How would people feel when they triggered your
WARN_ONevery time they ejected a disc from their USB CD-ROM drive?
I agree - see above.
Quoted 7 lines
Quoted 5 lines
Quoted 3 lines
Or you could guess that the offending command is sent by a system/desktop utility, such as hal or udev. Have you added or changed any software in that area recently?
As I mentioned, I tried this in runlevel 3 - no desktop running.
Both hal and udev would still be running in level 3.
I'll poke at this some more.
/D
Signature · 2 lines
Dirk Hohndel Intel Open Source Technology Center
Quoted 2 lines · Dirk Hohndel
I had missed that part that the stick claimed to be a removable device (it is, in a sense, but then it shouldn't balk at being ejected).
No, no. This is a common misunderstanding, caused by poor choice of terminology. The stick is not "removable"; it is "hot-unpluggable".
"Removable" refers to the media. A CD drive, floppy drive, or card reader is removable storage. A USB stick isn't, unless you can somehow pry the flash memory chip out of it. :-)
Alan Stern
A message that is not in the archive (sent off-list or not yet received): [email protected]
Quoted 24 lines · Dirk Hohndel
Quoted 5 lines · On Wed, 28 Jan 2009 11:54:39 -0500 (EST) Alan Stern…
Quoted 5 lines
Quoted 4 lines
So the real question is: Who is responsible for sending that Eject command? It certainly isn't usb-storage or any other part of the USB stack. Maybe something in the SCSI disk driver or maybe a user program.
Quoted 7 lines
Quoted 3 lines
That's one valid question... maybe someone on the linux-scsi list can sched some light onto this? Are there SCSI specific debugging options I should turn on?
I don't see anything in the sd driver that could have done it. And I don't know where else in the kernel it would have come from -- which is not to say that I'm familiar with every part of the kernel!
I did some greping and couldn't find anything suspicious, either.
Quoted 6 lines
Quoted 2 lines
The other one is "why isn't the USB stack filtering that command when it comes down from SCSI?"
The USB stack doesn't do any filtering. The SCSI stack is supposed to know what commands should and should not be sent.
Quoted 8 lines
Quoted 3 lines
Furthermore, it seems quite likely this command was sent by userspace, not by the SCSI stack -- in which case the program is supposed to know what commands it shouldn't send.
Not sure I agree with that logic. If the USB stack KNOWS that non-removable devices get upset by this command, then it would be appropriate for it to filter those out - to protect from bugs as much as to protect from denial of service attacks.
Well, I really don't think we want to get into vetting SCSI commands over SG_IO ... that would just trip us up on the enterprise (and probably never work anyway).
The problem is that hal wants to send its own SCSI commands over SG_IO. We've spent years trying to persuade it to put the crackpipe down and back away from the window ledge on this (because SCSI in the kernel knows better how to handle problem devices). We have been having some limited success recently ... we keep enhancing what sysfs provides (safely) so that hal doesn't have to poke in with SG_IO unsafely.
If you can find out what the actual reason hal or whatever is doing this, we can have another go at them.
James
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
Quoted 7 lines · On Wed, 28 Jan 2009 17:59:11 +0000 James Bottomley…
Quoted 7 lines
Quoted 6 lines
The USB stack doesn't do any filtering. The SCSI stack is supposed to know what commands should and should not be sent.
Furthermore, it seems quite likely this command was sent by userspace, not by the SCSI stack -- in which case the program is supposed to know what commands it shouldn't send.
Quoted 8 lines
Quoted 4 lines
Not sure I agree with that logic. If the USB stack KNOWS that non-removable devices get upset by this command, then it would be appropriate for it to filter those out - to protect from bugs as much as to protect from denial of service attacks.
Well, I really don't think we want to get into vetting SCSI commands over
SG_IO... that would just trip us up on the enterprise (and probably never work anyway).
Yeah, I understand now and agree with you and Alan on that one...
Quoted 9 lines
The problem is that hal wants to send its own SCSI commands over
SG_IO. We've spent years trying to persuade it to put the crackpipe down and back away from the window ledge on this (because SCSI in the kernel knows better how to handle problem devices). We have been having some limited success recently ... we keep enhancing what sysfs provides (safely) so that hal doesn't have to poke in withSG_IOunsafely.If you can find out what the actual reason hal or whatever is doing this, we can have another go at them.
Any recommendations how to best approach debugging this? Attaching strace to some processes before inserting the usb stick?
/D
Signature · 2 lines
Dirk Hohndel Intel Open Source Technology Center
Quoted 2 lines · Dirk Hohndel
Any recommendations how to best approach debugging this? Attaching strace to some processes before inserting the usb stick?
I would try add some dump_stack() to ->queuecommand, to see if this is SG_IO or other source. Finding who sends the commands is the key. Another trick is to printk the completion handlers (w/ lookup_symbol).
-- Pete
Quoted 2 lines · Dirk Hohndel
Any recommendations how to best approach debugging this? Attaching strace to some processes before inserting the usb stick?
No really good recommendations. The guilty party is often hal, so you can try turning off the haldaemon service before plugging in your stick.
Alan Stern
Quoted 6 lines · Alan Stern
Quoted 2 lines
Any recommendations how to best approach debugging this? Attaching strace to some processes before inserting the usb stick?
No really good recommendations. The guilty party is often hal, so you can try turning off the haldaemon service before plugging in your stick.
printk current->comm in queuecommand maybe?
-- Pete
A message that is not in the archive (sent off-list or not yet received): 20090128142915.3b6f1949.zaitcev-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org
Quoted 10 lines · Pete Zaitcev
Quoted 6 lines · Alan Stern
Quoted 2 lines
Any recommendations how to best approach debugging this? Attaching strace to some processes before inserting the usb stick?
No really good recommendations. The guilty party is often hal, so you can try turning off the haldaemon service before plugging in your stick.
printk
current->commin queuecommand maybe?
Maybe. But queuecommand doesn't get called directly by the process making the request; it has to go through a block-layer queue first.
Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
Am Wednesday 28 January 2009 22:29:15 schrieb Pete Zaitcev:
Quoted 10 lines · Alan Stern
Quoted 7 lines
Quoted 3 lines
Any recommendations how to best approach debugging this? Attaching strace to some processes before inserting the usb stick?
No really good recommendations. The guilty party is often hal, so you can try turning off the haldaemon service before plugging in your stick.
printk
current->commin queuecommand maybe?
Code to do just that can be taken from the microtek driver.
HTH
Oliver
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
A message that is not in the archive (sent off-list or not yet received): Pine.LNX.4.44L0.0901281622210.2231-100000-IYeN2dnnYyZXsRXLowluHWD2FQJk+8+b@public.gmane.org
Quoted 8 lines · On Wed, 28 Jan 2009 16:23:37 -0500 (EST) Alan Stern…
Quoted 2 lines · Dirk Hohndel
Any recommendations how to best approach debugging this? Attaching strace to some processes before inserting the usb stick?
No really good recommendations. The guilty party is often hal, so you can try turning off the haldaemon service before plugging in your stick.
I ran with that and figured it out. I rebooted into runlevel 3 and stopped one daemon after another. udev was the culprit. As part of the installation of a 3G modem a broken udev script had been installed (unbeknownst to me). That issued an eject on anything that identified itself as being removable (it was supposed to only do that for the specific device but a syntax error in it made it eject any removable device).
So not a kernel issue at all.
Thanks for all the help tracking this down.
/D
Signature · 6 lines
Dirk Hohndel Intel Open Source Technology Center -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
Quoted 2 lines · Dirk Hohndel
On a 64bit 2.6.29-rc2 system (and a few earlier kernels that I have tried) I can no longer use USB sticks.
So how do you know that you "no longer" can use USB sticks if you did not find a kernel where it worked? It's either one or the other.
Quoted 5 lines
Quoted 5 lines
Quoted 5 lines
From the middle of the log (after the partition table has been read):
[ 32.056855] usb-storage: queuecommand called [ 32.056886] usb-storage: *** thread awakened. [ 32.056888] usb-storage: Command START_STOP (6 bytes)
Middle huh. I _really_ wish people stopped editing their logs. How am I supposed to determine if this was sent immediately after open (e.g. your HAL is screwing with you), or it happened after a time of inactivity?
In the latter case you might try to comment out sdev->allow_restart = 1 from scsiglue.c.
It was added there for a specific reason: Seagate FreeAgent. We can easily make it specific for Seagate, *IF* commenting it helps.
In the former case, well, complain to distro.
Quoted 2 lines
The other one is "why isn't the USB stack filtering that command when it comes down from SCSI?"
GOD, NO. We went down that road before.
-- Pete
P.S. If userland were sending these commands, ub would fail too. So it's not a heaven from this problem.
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
A message that is not in the archive (sent off-list or not yet received): 20090128141035.3a26ea60.zaitcev-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org
Quoted 10 lines · Pete Zaitcev
Quoted 5 lines
Quoted 5 lines
Quoted 5 lines
From the middle of the log (after the partition table has been read):
[ 32.056855] usb-storage: queuecommand called [ 32.056886] usb-storage: *** thread awakened. [ 32.056888] usb-storage: Command START_STOP (6 bytes)Middle huh. I _really_ wish people stopped editing their logs. How am I supposed to determine if this was sent immediately after open (e.g. your HAL is screwing with you), or it happened after a time of inactivity?
Don't blame this on Dirk; he was just quoting something I had sent, in which I extracted part of his log. The entire log is earlier in this thread. The timestamp shows that the START-STOP UNIT command was sent less than 0.5 seconds after usb-storage first probed the device.
Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
Quoted 7 lines · On Wed, 28 Jan 2009 14:10:35 -0700 Pete Zaitcev <[email protected]> wrote:
Quoted 2 lines · Dirk Hohndel
On a 64bit 2.6.29-rc2 system (and a few earlier kernels that I have tried) I can no longer use USB sticks.
So how do you know that you "no longer" can use USB sticks if you did not find a kernel where it worked? It's either one or the other.
Very good point.
I know that I had it working when I installed F10. It doesn't work right now, but there have been lots of updates to F10 since. Not sure how to get back to the old state except for reinstalling F10 from the original media...
Quoted 10 lines
Quoted 5 lines
Quoted 5 lines
Quoted 5 lines
From the middle of the log (after the partition table has been read):
[ 32.056855] usb-storage: queuecommand called [ 32.056886] usb-storage: *** thread awakened. [ 32.056888] usb-storage: Command START_STOP (6 bytes)Middle huh. I _really_ wish people stopped editing their logs. How am I supposed to determine if this was sent immediately after open (e.g. your HAL is screwing with you), or it happened after a time of inactivity?
I initially sent out the complete log - Alan cut it down. Here's the link to the relevant email in this thread:
http://kerneltrap.org/mailarchive/linux-usb/2009/1/27/4830624
Quoted 6 lines
In the latter case you might try to comment out
sdev->allow_restart= 1 fromscsiglue.c.
It was added there for a specific reason: Seagate FreeAgent. We can easily make it specific for Seagate, *IF* commenting it helps.In the former case, well, complain to distro.
It's Fedora 10.
/D
Signature · 2 lines
Dirk Hohndel Intel Open Source Technology Center
A message that is not in the archive (sent off-list or not yet received): [email protected]
Quoted 8 lines · Dirk Hohndel
Quoted 5 lines
Quoted 2 lines
On a 64bit 2.6.29-rc2 system (and a few earlier kernels that I have tried) I can no longer use USB sticks.
So how do you know that you "no longer" can use USB sticks if you did not find a kernel where it worked? It's either one or the other.
I know that I had it working when I installed F10. It doesn't work right now, but there have been lots of updates to F10 since.
Thanks, that's useful. I guess my idea about ->allow_restart cannot be relevant then, that code existed for a long time.
Got it, thanks.
I also have stock F10 boxes here to test.
-- Pete
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html