Usb storage mounting was broken somewhere between 2.6.0-test5-bk10 and 2.6.0-test6-bk1

Usb storage mounting was broken somewhere between 2.6.0-test5-bk10 and 2.6.0-test6-bk1

[Nicolas Mailhot]

[-- Attachment #1: Type: text/plain, Size: 828 bytes --]

Hi,

	I'd like to bring to your attention bug #1310 :

http://bugzilla.kernel.org/show_bug.cgi?id=1310

Short summary (full info in the bugzilla page) :

1. my usb storage device stopped working (mounting) after
2.6.0-test5-bk10 

2. the usb storage maintainer says nothing changed at the usb level, so
it's probably the scsi layer that broke somehow

3. I won't test kernel snapshots between 2.6.0-test5-bk10 and
2.6.0-test6-bk1 since they also had a raid bug and I spent days
recovering from it (which is why I didn't push bug #1310 as I should
have - I took a kernel testing break afterwards)
 
I've just retested with 2.6.0-test8-bk1 and the bug is still there.

More patch tests, logs, etc available on demand (though the bugzilla
entry is already pretty complete)

Cheers,

-- 
Nicolas Mailhot

[-- Attachment #2: Ceci est une partie de message numériquement signée. --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: Usb storage mounting was broken somewhere between 2.6.0-test5-bk10 and 2.6.0-test6-bk1

[Patrick Mansfield]

On Wed, Oct 22, 2003 at 12:33:36AM +0200, Nicolas Mailhot wrote:

> 2. the usb storage maintainer says nothing changed at the usb level, so
> it's probably the scsi layer that broke somehow

In the bug, Matthew says:

	looks like someone may have broken usb_reset_configuration or some
	other code path outside of usb-storage.

> I've just retested with 2.6.0-test8-bk1 and the bug is still there.
> 
> More patch tests, logs, etc available on demand (though the bugzilla
> entry is already pretty complete)

Since the device functioned in an earlier 2.6 release, I doubt the MODE
SENSE page is causing a problem. 

It is a multi slot card reader, and SCSI sees these as multiple LUNs
(multiple sd's), though you say you can only use one at a time. So we see
INQUIRY's to LUN 0 and LUN 1, and LUN 1 shows up and is then mounted via
/dev/smartmedia, correct?

David - as replied to you by Nicolas in the bug, the dmesg you commented
on is the one that was working (the "2.6.0-test5-bk5 scenario"). SCSI is
not confused in that case (though I am somewhat confused by the various
dmesg and log files).

Where are the SCSI INQUIRY messages? The ones with Vendor and Model. And
sd attach messages?

If the SCSI INQUIRY messages are not output, SCSI is not seeing the device
at all and it is more likely a usb issue.

AFAICT the bad dmesg ends without a reset, where the good one shows an
INQUIRY being sent and returned back OK, followed by logs of the mount
command.

i.e. bad demsg/log has:

Oct  2 23:55:35 rousalka kernel: usb-storage: USB Mass Storage device detected
Oct  2 23:55:35 rousalka kernel: usb-storage: act_altsetting is 0, id_index is 16
Oct  2 23:55:35 rousalka kernel: usb-storage: -- associate_dev
Oct  2 23:55:35 rousalka kernel: usb-storage: Vendor: SCM Microsystems
Oct  2 23:55:35 rousalka kernel: usb-storage: Product: eUSB SmartMedia /
CompactFlash Adapter

And then nothing at all???

-- Patrick Mansfield

Re: Usb storage mounting was broken somewhere between 2.6.0-test5-bk10 and 2.6.0-test6-bk1

[David Brownell]

That is, http://bugme.osdl.org/show_bug.cgi?id=1310

I've been waiting for the followup from Nicolas:  dmesg logs,
with CONFIG_USB_DEBUG, showing this failure on a current kernel.
(And likely also usb-storage VERBOSE debug...)

If I don't see such information soon, I'll just reject that bug
for insufficient data; it's been missing for nearly two weeks,
clearly this bug was mis-prioritized.


Patrick Mansfield wrote:
> In the bug, Matthew says:
> 
> 	looks like someone may have broken usb_reset_configuration or some
> 	other code path outside of usb-storage.

I couldn't find any evidence of such a thing though.
If it existed, it never made it into bugtraq.


>>I've just retested with 2.6.0-test8-bk1 and the bug is still there.
>>
>>More patch tests, logs, etc available on demand (though the bugzilla
>>entry is already pretty complete)

The bugzilla entry is actually pretty useless.   Where's the
"scenario" data showing there even _is_ a failure case?
(Leaving aside "how/why does it happen"...)


> David - as replied to you by Nicolas in the bug, the dmesg you commented
> on is the one that was working (the "2.6.0-test5-bk5 scenario"). SCSI is
> not confused in that case (though I am somewhat confused by the various
> dmesg and log files).

The convention for bug reports is to describe the failure mode
in some detail.  What this one has is detail for success modes.
The logical conclusion is that there is no bug ...

- Dave

Re: Usb storage mounting was broken somewhere between 2.6.0-test5-bk10 and 2.6.0-test6-bk1

[Nicolas Mailhot]

[-- Attachment #1: Type: text/plain, Size: 2239 bytes --]

Le mer 22/10/2003 à 02:55, Patrick Mansfield a écrit :

> It is a multi slot card reader, and SCSI sees these as multiple LUNs
> (multiple sd's), though you say you can only use one at a time. So we see
> INQUIRY's to LUN 0 and LUN 1, and LUN 1 shows up and is then mounted via
> /dev/smartmedia, correct?

/mnt/smartmedia, yes.

The device is a dual CF/SM reader. CF is lun 0, SM lun 1.
A mechanical flap prevents use of more than one slot at once (so maybe
the chip/driver has no knowledge at all it's restricted)

Card presence is checked via polling. So with debug activated one sees a
lot of accesses to lun 0 before lun 1 is probed.

> David - as replied to you by Nicolas in the bug, the dmesg you commented
> on is the one that was working (the "2.6.0-test5-bk5 scenario"). SCSI is
> not confused in that case (though I am somewhat confused by the various
> dmesg and log files).

Well, I tried to provide all the data:(.

> Where are the SCSI INQUIRY messages? The ones with Vendor and Model. And
> sd attach messages?
> 
> If the SCSI INQUIRY messages are not output, SCSI is not seeing the device
> at all and it is more likely a usb issue.
> 
> AFAICT the bad dmesg ends without a reset, where the good one shows an
> INQUIRY being sent and returned back OK, followed by logs of the mount
> command.
> 
> i.e. bad demsg/log has:
> 
> Oct  2 23:55:35 rousalka kernel: usb-storage: USB Mass Storage device detected
> Oct  2 23:55:35 rousalka kernel: usb-storage: act_altsetting is 0, id_index is 16
> Oct  2 23:55:35 rousalka kernel: usb-storage: -- associate_dev
> Oct  2 23:55:35 rousalka kernel: usb-storage: Vendor: SCM Microsystems
> Oct  2 23:55:35 rousalka kernel: usb-storage: Product: eUSB SmartMedia /
> CompactFlash Adapter
> 
> And then nothing at all???

Nothing. The broken kernel outputs no further usb storage messages.
I'll re-test this evening with full usb-storage and usb debug, though
I'm pretty sure they were already activated in the test scenarii (on
both kernels - same .config after all).

And looking at the .configs that were uploaded at test time - yes they
were. I doubt -test8-bk1 will be different when tested.

Cheers,

-- 
Nicolas Mailhot

[-- Attachment #2: Ceci est une partie de message numériquement signée. --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: Usb storage mounting was broken somewhere between 2.6.0-test5-bk10 and 2.6.0-test6-bk1

[David Brownell]

> Well, I tried to provide all the data:(.

Not in your updates of last night you didn't ...

You've omitted any data that would identify a problem.
In fact there's no evidence you even connected such a
device to the test6 kernel.

So I closed that bug report.  If you come up with any
evidence to support a real bug report, file a new bug
report with it.  But having this one sitting around
in such a state does nobody any good.

- Dave

Re: Usb storage mounting was broken somewhere between 2.6.0-test5-bk10 and 2.6.0-test6-bk1

[Nicolas Mailhot]

[-- Attachment #1: Type: text/plain, Size: 831 bytes --]

Le mer 22/10/2003 à 17:11, David Brownell a écrit :
> > Well, I tried to provide all the data:(.
> 
> Not in your updates of last night you didn't ...
> 
> You've omitted any data that would identify a problem.
> In fact there's no evidence you even connected such a
> device to the test6 kernel.
> 
> So I closed that bug report.  If you come up with any
> evidence to support a real bug report, file a new bug
> report with it.  But having this one sitting around
> in such a state does nobody any good.

Rhaa. There is no evidence of a failure. The reader is plugged like in
previous kernels, logs show it's detected as a usb-storage device, then
*nothing*.

I can't give you any error because no error is outputed. If I could make
up an error message believe me I would .

Cheers,

-- 
Nicolas Mailhot

[-- Attachment #2: Ceci est une partie de message numériquement signée. --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: Usb storage mounting was broken somewhere between 2.6.0-test5-bk10 and 2.6.0-test6-bk1

[David Brownell]

Nicolas Mailhot wrote:

>>So I closed that bug report.  If you come up with any
>>evidence to support a real bug report, file a new bug
>>report with it.  But having this one sitting around
>>in such a state does nobody any good.
> 
> 
> Rhaa. There is no evidence of a failure. The reader is plugged like in
> previous kernels, logs show it's detected as a usb-storage device, then
> *nothing*.

Not according to any information you included in the bug report,
after several weeks of waiting for clarifications...

Maybe you thought you'd included that information, but it's
not there.  The only "logs show ..." information you included
was for cases where everything worked (test5).



> I can't give you any error because no error is outputed. If I could make
> up an error message believe me I would .

No, please don't make up error messages.

If you file a new bug report, just include dmesg output
demonstrating the problem you're describing -- on a
current kernel.

Re: Usb storage mounting was broken somewhere between 2.6.0-test5-bk10 and 2.6.0-test6-bk1

[Nicolas Mailhot]

[-- Attachment #1: Type: text/plain, Size: 1863 bytes --]

Le mer 22/10/2003 à 18:20, David Brownell a écrit :
> Nicolas Mailhot wrote:
> 
> >>So I closed that bug report.  If you come up with any
> >>evidence to support a real bug report, file a new bug
> >>report with it.  But having this one sitting around
> >>in such a state does nobody any good.
> > 
> > 
> > Rhaa. There is no evidence of a failure. The reader is plugged like in
> > previous kernels, logs show it's detected as a usb-storage device, then
> > *nothing*.
> 
> Not according to any information you included in the bug report,
> after several weeks of waiting for clarifications...
> 
> Maybe you thought you'd included that information, but it's
> not there.  The only "logs show ..." information you included
> was for cases where everything worked (test5).

The not-working case logs were put in comment #4 not in attachements
because there were very short (ie the device name showed up and the
kernel did nothing with it). The only reason the working case was put in
attachement is there were too many activity messages to include it
inline.

I've redone the tests with 2.6.0-test8-bk2-exec-shield-G4.
The results are exactly the same device name echoed by usb-storage then
nothing.

The only weird thing is some messages made it to /var/log/messages,
/var/log/kernel and show up with dmesg, but didn't end up in
/var/log/dmesg (which is what I used as attachement before, but the
other messages were extracted from /var/log/kernel and put in the bug
too). I suppose RedHat stops writing in /var/log/dmesg after the end of
the boot.

To make clear I didn't cut some messages after the device detection I
included the date at which the files were copied.

I'm sorry about the communication failure - you asked for info already
in the report and I didn't realise you didn't see it.

-- 
Nicolas Mailhot

[-- Attachment #2: Ceci est une partie de message numériquement signée. --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: Usb storage mounting was broken

[David Brownell]

> The only weird thing is some messages made it to /var/log/messages,
> /var/log/kernel and show up with dmesg, but didn't end up in
> /var/log/dmesg (which is what I used as attachement before, but the
> other messages were extracted from /var/log/kernel and put in the bug
> too). I suppose RedHat stops writing in /var/log/dmesg after the end of
> the boot.

As a rule, "dmesg output" means "output of dmesg command" ... :)
Boot messages (/var/log/dmesg) aren't a substitute.

OK, at this point what's needed is the more customary usb debug
information.  Contents of /proc/bus/usb/devices for starters.
And since this resembles an enumeration failure, it'd be good
to have the Alt-Sysrq-t output for "khubd".

And does this happen if you try this with, say, OHCI not EHCI?

- Dave

Re: Usb storage mounting was broken

[Nicolas Mailhot]

[-- Attachment #1: Type: text/plain, Size: 1508 bytes --]

Le mer 22/10/2003 à 20:44, David Brownell a écrit :
> > The only weird thing is some messages made it to /var/log/messages,
> > /var/log/kernel and show up with dmesg, but didn't end up in
> > /var/log/dmesg (which is what I used as attachement before, but the
> > other messages were extracted from /var/log/kernel and put in the bug
> > too). I suppose RedHat stops writing in /var/log/dmesg after the end of
> > the boot.
> 
> As a rule, "dmesg output" means "output of dmesg command" ... :)

Well, the acpi people for example need /var/log/dmesg since their stuff
happens early and the log buffer will often overflow:)

> Boot messages (/var/log/dmesg) aren't a substitute.
> 
> OK, at this point what's needed is the more customary usb debug
> information.  Contents of /proc/bus/usb/devices for starters.

In the bugzilla report

> And since this resembles an enumeration failure, it'd be good
> to have the Alt-Sysrq-t output for "khubd".

In the report too (took me some time to remember it ended up in
/var/log/messages, not only the current console)

> And does this happen if you try this with, say, OHCI not EHCI?

I haven't used OHCI for months - all my usb1 devices are plugged in an
external usb2 hub, so I don't even build OHCI as module in my own
kernels. Do you really want me to try it ? Because if it fails I won't
be able to tell you if it ever worked for me this year.

One less usb driver makes tester life easier:)

Cheers,

-- 
Nicolas Mailhot

[-- Attachment #2: Ceci est une partie de message numériquement signée. --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: Usb storage mounting was broken

[David Brownell]

[-- Attachment #1: Type: text/plain, Size: 478 bytes --]


>>And since this resembles an enumeration failure, it'd be good
>>to have the Alt-Sysrq-t output for "khubd".
> 
> In the report too (took me some time to remember it ended up in
> /var/log/messages, not only the current console)

That says to me "self-deadlock"; crept in recently.  It turns
out that routine already has all the locks it needs.  Try the
attached patch.

This is pretty far from being a mount problem ... no wonder I
kept expecting more info from you!

- Dave

[-- Attachment #2: Diff --]
[-- Type: text/plain, Size: 879 bytes --]

--- 1.37/drivers/usb/core/message.c	Tue Sep 23 11:18:09 2003
+++ edited/drivers/usb/core/message.c	Wed Oct 22 15:49:15 2003
@@ -1001,8 +1001,10 @@
 	int			i, retval;
 	struct usb_host_config	*config;
 
-	/* dev->serialize guards all config changes */
-	down(&dev->serialize);
+	/* caller must own dev->serialize (config won't change)
+	 * and the usb bus readlock (so driver bindings are stable);
+	 * so calls during probe() are fine
+	 */
 
 	for (i = 1; i < 16; ++i) {
 		usb_disable_endpoint(dev, i);
@@ -1016,7 +1018,7 @@
 			NULL, 0, HZ * USB_CTRL_SET_TIMEOUT);
 	if (retval < 0) {
 		dev->state = USB_STATE_ADDRESS;
-		goto done;
+		return retval;
 	}
 
 	dev->toggle[0] = dev->toggle[1] = 0;
@@ -1029,9 +1031,7 @@
 		intf->act_altsetting = 0;
 		usb_enable_interface(dev, intf);
 	}
-done:
-	up(&dev->serialize);
-	return (retval < 0) ? retval : 0;
+	return 0;
 }
 
 /**

Re: Usb storage mounting was broken

[Nicolas Mailhot]

[-- Attachment #1: Type: text/plain, Size: 883 bytes --]

Le jeu 23/10/2003 à 00:53, David Brownell a écrit :
> >>And since this resembles an enumeration failure, it'd be good
> >>to have the Alt-Sysrq-t output for "khubd".
> > 
> > In the report too (took me some time to remember it ended up in
> > /var/log/messages, not only the current console)
> 
> That says to me "self-deadlock"; crept in recently.  It turns
> out that routine already has all the locks it needs.  Try the
> attached patch.
> 
> This is pretty far from being a mount problem ... no wonder I
> kept expecting more info from you!

This patch sucessfully unlocks device detection and mount now works,
thanks ! However it seems another bug crept in usb-storage since a cp
from the SM card stalls forever (directories are created, so is the
first file but its size stays 0).

I'll open a new bug. (third in a row:()

Cheers,

-- 
Nicolas Mailhot

[-- Attachment #2: Ceci est une partie de message numériquement signée. --]
[-- Type: application/pgp-signature, Size: 189 bytes --]