Re: strange USB storage failure with 2.6.29-rc2

Re: strange USB storage failure with 2.6.29-rc2

[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_STOP to the device which really confuses it...

On Tue, 27 Jan 2009 15:56:11 -0500 (EST)
Alan Stern <stern-nwvwT67g6+6dFdvTe/nMLpVzexx5G7lz@public.gmane.org> wrote:

> On Tue, 27 Jan 2009, Dirk Hohndel wrote:
> 
> > 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.
> 
> 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...

> 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:

http://www.mail-archive.com/linux-usb-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org/msg09331.html

Maybe we need to bring such code back?

/D



-- 
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 majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: strange USB storage failure with 2.6.29-rc2

[Alan Stern]

On Tue, 27 Jan 2009, Dirk Hohndel wrote:

> 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...
> 
> On Tue, 27 Jan 2009 15:56:11 -0500 (EST)
> Alan Stern <stern-nwvwT67g6+6dFdvTe/nMLpVzexx5G7lz@public.gmane.org> wrote:
> 
> > On Tue, 27 Jan 2009, Dirk Hohndel wrote:
> > 
> > > 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.
> > 
> > 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.  :-)

> > 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!

> 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.

> 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:
> 
> http://www.mail-archive.com/linux-usb-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org/msg09331.html

Like I said, the SCSI stack was fixed so that it didn't send the wrong
commands.

> 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 majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: strange USB storage failure with 2.6.29-rc2

[Dirk Hohndel]

On Wed, 28 Jan 2009 11:54:39 -0500 (EST)
Alan Stern <stern@rowland.harvard.edu> wrote:

> > > 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!

I did some greping and couldn't find anything suspicious, either.

> > 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.

> > 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.
 
> 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.

That's why I copied the scsi list, hoping that they have some tools /
ideas how to do this.
 
> 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

-- 
Dirk Hohndel
Intel Open Source Technology Center

Re: strange USB storage failure with 2.6.29-rc2

[Alan Stern]

On Wed, 28 Jan 2009, Dirk Hohndel wrote:

> > > 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.

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:

> 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.

> > > 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.

Nope.  How would people feel when they triggered your WARN_ON every 
time they ejected a disc from their USB CD-ROM drive?

> > 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.

> 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

Re: strange USB storage failure with 2.6.29-rc2

[James Bottomley]

On Wed, 2009-01-28 at 09:14 -0800, Dirk Hohndel wrote:
> On Wed, 28 Jan 2009 11:54:39 -0500 (EST)
> Alan Stern <stern-nwvwT67g6+6dFdvTe/nMLpVzexx5G7lz@public.gmane.org> wrote:
> 
> > > > 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!
> 
> I did some greping and couldn't find anything suspicious, either.
> 
> > > 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.

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 majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: strange USB storage failure with 2.6.29-rc2

[Dirk Hohndel]

On Wed, 28 Jan 2009 12:47:45 -0500 (EST)
Alan Stern <stern@rowland.harvard.edu> wrote:

> On Wed, 28 Jan 2009, Dirk Hohndel wrote:
> 
> > > > 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.
> 
> 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:
> 
> > 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).

> > > > 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.
> 
> Nope.  How would people feel when they triggered your WARN_ON every 
> time they ejected a disc from their USB CD-ROM drive?

I agree - see above.
 
> > > 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

-- 
Dirk Hohndel
Intel Open Source Technology Center

Re: strange USB storage failure with 2.6.29-rc2

[Dirk Hohndel]

On Wed, 28 Jan 2009 17:59:11 +0000
James Bottomley <James.Bottomley@HansenPartnership.com> wrote:
> > > 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.
> 
> 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...

> 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.

Any recommendations how to best approach debugging this? Attaching
strace to some processes before inserting the usb stick?

/D

-- 
Dirk Hohndel
Intel Open Source Technology Center

Re: strange USB storage failure with 2.6.29-rc2

[Alan Stern]

On Wed, 28 Jan 2009, Dirk Hohndel wrote:

> 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

Re: strange USB storage failure with 2.6.29-rc2

[Pete Zaitcev]

On Tue, 27 Jan 2009 20:06:07 -0800, Dirk Hohndel <hohndel-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org> wrote:

> 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.

> > >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.

> 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 majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: strange USB storage failure with 2.6.29-rc2

[Pete Zaitcev]

On Wed, 28 Jan 2009 12:01:29 -0800, Dirk Hohndel <hohndel@infradead.org> wrote:

> 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

Re: strange USB storage failure with 2.6.29-rc2

[Alan Stern]

On Wed, 28 Jan 2009, Pete Zaitcev wrote:

> > > >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 majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: strange USB storage failure with 2.6.29-rc2

[Dirk Hohndel]

On Wed, 28 Jan 2009 14:10:35 -0700
Pete Zaitcev <zaitcev@redhat.com> wrote:

> On Tue, 27 Jan 2009 20:06:07 -0800, Dirk Hohndel <hohndel@infradead.org> wrote:
> 
> > 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...

> > > >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

> 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.

It's Fedora 10.

/D

-- 
Dirk Hohndel
Intel Open Source Technology Center

Re: strange USB storage failure with 2.6.29-rc2

[Alan Stern]

On Wed, 28 Jan 2009, Dirk Hohndel wrote:

> 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

Re: strange USB storage failure with 2.6.29-rc2

[Pete Zaitcev]

On Wed, 28 Jan 2009 13:22:28 -0800, Dirk Hohndel <hohndel-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org> wrote:

> > > 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.

> http://kerneltrap.org/mailarchive/linux-usb/2009/1/27/4830624

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 majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: strange USB storage failure with 2.6.29-rc2

[Pete Zaitcev]

On Wed, 28 Jan 2009 16:23:37 -0500 (EST), Alan Stern <stern@rowland.harvard.edu> wrote:

> > 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

Re: strange USB storage failure with 2.6.29-rc2

[Alan Stern]

On Wed, 28 Jan 2009, Pete Zaitcev wrote:

> On Wed, 28 Jan 2009 16:23:37 -0500 (EST), Alan Stern <stern-nwvwT67g6+6dFdvTe/nMLpVzexx5G7lz@public.gmane.org> wrote:
> 
> > > 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?

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 majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: strange USB storage failure with 2.6.29-rc2

[Oliver Neukum]

Am Wednesday 28 January 2009 22:29:15 schrieb Pete Zaitcev:
> On Wed, 28 Jan 2009 16:23:37 -0500 (EST), Alan Stern <stern-nwvwT67g6+6dFdvTe/nMLpVzexx5G7lz@public.gmane.org> wrote:
> 
> > > 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?

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 majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: strange USB storage failure with 2.6.29-rc2

[Dirk Hohndel]

On Wed, 28 Jan 2009 16:23:37 -0500 (EST)
Alan Stern <stern-nwvwT67g6+6dFdvTe/nMLpVzexx5G7lz@public.gmane.org> wrote:

> On Wed, 28 Jan 2009, Dirk Hohndel wrote:
> 
> > 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


-- 
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 majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html