Fwd: Re: [linux-usb-devel] USB Storage oops in 2.5.69-bk8

Fwd: Re: [linux-usb-devel] USB Storage oops in 2.5.69-bk8

[Florin Iucha]

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

----- Forwarded message from Alan Stern <stern@rowland.harvard.edu> -----

> Subject: Re: [linux-usb-devel] USB Storage oops in 2.5.69-bk8
> From: Alan Stern <stern@rowland.harvard.edu>
> To: Florin Iucha <florin@iucha.net>
> Cc: USB development list <linux-usb-devel@lists.sourceforge.net>
> Date: Fri, 16 May 2003 11:49:00 -0400 (EDT)
> 
> On Thu, 15 May 2003, Florin Iucha wrote:
> 
> > Hello,
> > 
> > I get the following oops in 2.5.69-bk8 when I try to mount a Compact
> > Flash card in a SanDisk adapter:
> > 
> > usb 2-1: USB disconnect, address 2
> > hub 2-0:0: debounce: port 1: delay 100ms stable 4 status 0x301
> > hub 2-0:0: new USB device on port 1, assigned address 3
> > input: USB HID v1.00 Mouse [Microsoft Microsoft IntelliMouse? Explorer] on usb-00:02.3-1
> > usb 2-1: USB disconnect, address 3
> > drivers/usb/input/hid-core.c: can't resubmit intr, 00:02.3-1/input0, status -19
> > hub 2-0:0: debounce: port 1: delay 100ms stable 4 status 0x301
> > hub 2-0:0: new USB device on port 1, assigned address 4
> > input: USB HID v1.00 Mouse [Microsoft Microsoft IntelliMouse? Explorer] on usb-00:02.3-1
> > SCSI device sda: 31232 512-byte hdwr sectors (16 MB)
> > sda: Write Protect is off
> > sda: Mode Sense: 02 00 00 00
> > drivers/usb/core/message.c: usb_control/bulk_msg: timeout
> > drivers/usb/core/message.c: usb_control/bulk_msg: timeout
> > drivers/usb/core/hub.c: USB device not accepting new address (error=-22)
> > scsi: Device offlined - not ready after error recovery: host 1 channel 0 id 0 lun 0
> > usb 5-2: USB disconnect, address 2
> > Unable to handle kernel paging request at virtual address 544150a8
> >  printing eip:
> > c02abc39
> > *pde = 00000000
> > Oops: 0000 [#1]
> > CPU:    0
> > EIP:    0060:[<c02abc39>]    Not tainted
> > EFLAGS: 00010286
> > EIP is at scsi_eh_finish_cmd+0x19/0x60
> > eax: ef19d000   ebx: eef28080   ecx: eef22140   edx: 54415056
> > esi: eef21fa8   edi: eef21fb0   ebp: eef21fa8   esp: eef21f60
> > ds: 007b   es: 007b   ss: 0068
> > Process scsi_eh_1 (pid: 118, threadinfo=eef20000 task=eef23340)
> > Stack: eef28080 eef28080 eef21fb0 c02ac418 eef28080 eef21fa8 00000000 00000000 
> >        00000000 ef62f428 eef20000 00000282 eef21fa8 c02ac8d6 eef21fb0 eef21fa8 
> >        eef21fa8 eef21fb0 eef21fa8 eef21fa8 eef28098 eef28098 ef62f400 eef21fd4 
> > Call Trace:
> >  [<c02ac418>] scsi_eh_offline_sdevs+0x68/0x80
> >  [<c02ac8d6>] scsi_unjam_host+0xc6/0xd0
> >  [<c02ac9b1>] scsi_error_handler+0xd1/0x120
> >  [<c02ac8e0>] scsi_error_handler+0x0/0x120
> >  [<c0108abd>] kernel_thread_helper+0x5/0x18
> > 
> > Code: 0f b7 42 52 48 66 89 42 52 c7 43 24 00 00 00 00 66 c7 43 08 
> > 
> > I cannot tell if it is a regression since I just got the CF and the
> > adapter.
> 
> This is a problem in the SCSI error handler.  You should post your 
> question to <linux-scsi@vger.kernel.org>.  Maybe also cc: to Mike Anderson 
> <andmike@us.ibm.com>.
> 
> Alan Stern

----- End forwarded message -----

florin

-- 

"NT is to UNIX what a doughnut is to a particle accelerator."

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: Fwd: Re: [linux-usb-devel] USB Storage oops in 2.5.69-bk8

[Mike Anderson]

This might be a case that the scsi_error handler never reclaimed or
canceled the command (i.e., this is a lost command) and probably should
not update the fields.

Could you get me a little more data on what the error handler actions
where by doing the following:
	1.) Ensure SCSI logging is enabled in your config.
	CONFIG_SCSI_LOGGING=y.

	2.) Prior to the mount of the Compact Flash card.
	echo "scsi log error 4" > /proc/scsi/scsi

	If this is getting set dmesg should give a line that scsi
	logging level set to ...

	3.) Mount the Compact Flash card and send me the output when it
	fails.

Thanks,

Florin Iucha [florin@iucha.net] wrote:
> ----- Forwarded message from Alan Stern <stern@rowland.harvard.edu> -----
> 
> > Subject: Re: [linux-usb-devel] USB Storage oops in 2.5.69-bk8
> > From: Alan Stern <stern@rowland.harvard.edu>
> > To: Florin Iucha <florin@iucha.net>
> > Cc: USB development list <linux-usb-devel@lists.sourceforge.net>
> > Date: Fri, 16 May 2003 11:49:00 -0400 (EDT)
> > 
> > On Thu, 15 May 2003, Florin Iucha wrote:
> > 
> > > Hello,
> > > 
> > > I get the following oops in 2.5.69-bk8 when I try to mount a Compact
> > > Flash card in a SanDisk adapter:
> > > 
> > > usb 2-1: USB disconnect, address 2
> > > hub 2-0:0: debounce: port 1: delay 100ms stable 4 status 0x301
> > > hub 2-0:0: new USB device on port 1, assigned address 3
> > > input: USB HID v1.00 Mouse [Microsoft Microsoft IntelliMouse? Explorer] on usb-00:02.3-1
> > > usb 2-1: USB disconnect, address 3
> > > drivers/usb/input/hid-core.c: can't resubmit intr, 00:02.3-1/input0, status -19
> > > hub 2-0:0: debounce: port 1: delay 100ms stable 4 status 0x301
> > > hub 2-0:0: new USB device on port 1, assigned address 4
> > > input: USB HID v1.00 Mouse [Microsoft Microsoft IntelliMouse? Explorer] on usb-00:02.3-1
> > > SCSI device sda: 31232 512-byte hdwr sectors (16 MB)
> > > sda: Write Protect is off
> > > sda: Mode Sense: 02 00 00 00
> > > drivers/usb/core/message.c: usb_control/bulk_msg: timeout
> > > drivers/usb/core/message.c: usb_control/bulk_msg: timeout
> > > drivers/usb/core/hub.c: USB device not accepting new address (error=-22)
> > > scsi: Device offlined - not ready after error recovery: host 1 channel 0 id 0 lun 0
> > > usb 5-2: USB disconnect, address 2
> > > Unable to handle kernel paging request at virtual address 544150a8
> > >  printing eip:
> > > c02abc39
> > > *pde = 00000000
> > > Oops: 0000 [#1]
> > > CPU:    0
> > > EIP:    0060:[<c02abc39>]    Not tainted
> > > EFLAGS: 00010286
> > > EIP is at scsi_eh_finish_cmd+0x19/0x60
> > > eax: ef19d000   ebx: eef28080   ecx: eef22140   edx: 54415056
> > > esi: eef21fa8   edi: eef21fb0   ebp: eef21fa8   esp: eef21f60
> > > ds: 007b   es: 007b   ss: 0068
> > > Process scsi_eh_1 (pid: 118, threadinfo=eef20000 task=eef23340)
> > > Stack: eef28080 eef28080 eef21fb0 c02ac418 eef28080 eef21fa8 00000000 00000000 
> > >        00000000 ef62f428 eef20000 00000282 eef21fa8 c02ac8d6 eef21fb0 eef21fa8 
> > >        eef21fa8 eef21fb0 eef21fa8 eef21fa8 eef28098 eef28098 ef62f400 eef21fd4 
> > > Call Trace:
> > >  [<c02ac418>] scsi_eh_offline_sdevs+0x68/0x80
> > >  [<c02ac8d6>] scsi_unjam_host+0xc6/0xd0
> > >  [<c02ac9b1>] scsi_error_handler+0xd1/0x120
> > >  [<c02ac8e0>] scsi_error_handler+0x0/0x120
> > >  [<c0108abd>] kernel_thread_helper+0x5/0x18
> > > 
> > > Code: 0f b7 42 52 48 66 89 42 52 c7 43 24 00 00 00 00 66 c7 43 08 
> > > 
> > > I cannot tell if it is a regression since I just got the CF and the
> > > adapter.
> > 
> > This is a problem in the SCSI error handler.  You should post your 
> > question to <linux-scsi@vger.kernel.org>.  Maybe also cc: to Mike Anderson 
> > <andmike@us.ibm.com>.
> > 
> > Alan Stern
> 
> ----- End forwarded message -----
> 
> florin
> 
> -- 
> 
> "NT is to UNIX what a doughnut is to a particle accelerator."


-andmike
--
Michael Anderson
andmike@us.ibm.com

Re: [linux-usb-devel] USB Storage oops in 2.5.69-bk8

[Florin Iucha]

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

On Fri, May 16, 2003 at 09:22:50AM -0700, Mike Anderson wrote:
> This might be a case that the scsi_error handler never reclaimed or
> canceled the command (i.e., this is a lost command) and probably should
> not update the fields.
> 
> Could you get me a little more data on what the error handler actions
> where by doing the following:
> 	1.) Ensure SCSI logging is enabled in your config.
> 	CONFIG_SCSI_LOGGING=y.
> 
> 	2.) Prior to the mount of the Compact Flash card.
> 	echo "scsi log error 4" > /proc/scsi/scsi
> 
> 	If this is getting set dmesg should give a line that scsi
> 	logging level set to ...
> 
> 	3.) Mount the Compact Flash card and send me the output when it
> 	fails.

Here it is:

scsi logging level set to 0x00000004
SCSI device sda: 31232 512-byte hdwr sectors (16 MB)
sda: Write Protect is off
sda: Mode Sense: 02 00 00 00
drivers/usb/core/message.c: usb_control/bulk_msg: timeout
Error handler scsi_eh_1 waking up
scsi_eh_prt_fail_stats: 1:0:0:0 cmds failed: 0, cancel: 1
Total of 1 commands on 1 devices require eh work
scsi_eh_1: aborting cmd:0xedac3080
scsi_eh_times_out: scmd:edac3080
scsi_send_eh_cmnd: scmd: edac3080, rtn:2003
scsi_eh_tur: scmd edac3080 rtn 2003
scsi_eh_1: Sending BDR sdev: 0xee133c00
drivers/usb/core/message.c: usb_control/bulk_msg: timeout
scsi_eh_1: BDR failed sdev:0xee133c00
scsi_eh_1: Sending BRST chan: 0
scsi_try_bus_reset: Snd Bus RST
drivers/usb/core/hub.c: USB device not accepting new address (error=-22)
scsi_eh_1: BRST failed chan: 0
scsi_eh_1: Sending HRST
scsi_try_host_reset: Snd Host RST
scsi_eh_1: HRST failed
scsi: Device offlined - not ready after error recovery: host 1 channel 0 id 0 lun 0
scsi_eh_1: flush finish cmd: edac3080
usb 5-2: USB disconnect, address 2
Unable to handle kernel paging request at virtual address 544150a6
 printing eip:
c02aa5e8
*pde = 00000000
Oops: 0000 [#1]
CPU:    0
EIP:    0060:[<c02aa5e8>]    Not tainted
EFLAGS: 00010002
EIP is at scsi_host_busy_dec_and_test+0x18/0x8a
eax: ed9f8000   ebx: 00000286   ecx: 54415056   edx: ed9f8000
esi: edac3080   edi: 54415056   ebp: ed9f8000   esp: ed9f9f24
ds: 007b   es: 007b   ss: 0068
Process scsi_eh_1 (pid: 604, threadinfo=ed9f8000 task=ee15d840)
Stack: c036db3b ee133c00 c02a93fc 54415056 ee133c00 edac3080 edac3080 ed9f9fa8 
       ed9f9fa8 c02ad2bb edac3080 ee15db26 edac3080 ed9f8000 edac3098 ee8a0008 
       ee133c00 ed9f9fb0 c02ad49c ed9f9fa8 ed9f9fa8 ed9f9fa8 00000000 00000000 
Call Trace:
 [<c02a93fc>] scsi_finish_command+0x1c/0x110
 [<c02ad2bb>] scsi_eh_flush_done_q+0x5b/0xe0
 [<c02ad49c>] scsi_unjam_host+0x15c/0x230
 [<c02ad6af>] scsi_error_handler+0x13f/0x1b0
 [<c02ad570>] scsi_error_handler+0x0/0x1b0
 [<c0108abd>] kernel_thread_helper+0x5/0x18

Code: 0f b7 41 50 48 f6 81 92 00 00 00 01 66 89 41 50 74 16 0f b7 
 <6>note: scsi_eh_1[604] exited with preempt_count 1

Thank you,
florin

PS: this trace was obtained on 2.5.69-bk11.

-- 

"NT is to UNIX what a doughnut is to a particle accelerator."

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [linux-usb-devel] USB Storage oops in 2.5.69-bk8

[Alan Stern]

On Fri, 16 May 2003, Florin Iucha wrote:

> On Fri, May 16, 2003 at 02:54:00PM -0400, Alan Stern wrote:
> > 
> > The logs you posted did not include the usb-storage debugging output.  
> > Either you didn't configure it in your kernel, or you had the console 
> > logging level set too low to capture debug-priority messages.
> > 
> > Maybe David Brownell will be able to learn something from the ehci log
> > messages.
> 
> D'oh! I have attached the respective kern.log. 

Good.  This clearly shows the problem.  It's an error in the SCSI driver.  
It has shown up before and been discussed at length a few weeks ago.  The
problem is that a MODE-SENSE(6) command is requesting a transfer of 3
bytes, which is smaller than the minimum of 4 bytes for that command.  
The device doesn't like it and crashes.

The SCSI people are supposed to be working on this.  First, we should be 
using MODE-SENSE(10) by default rather than MODE-SENSE(6).  Second, we 
should never request a transfer smaller than the minimum allowed size.  
When these changes are ready you shouldn't have any more trouble.

The OOPS you got originally was caused by the lack of proper 
hot-unplugging cooperation between usb-storage and the SCSI driver.

Alan Stern

Re: [linux-usb-devel] USB Storage oops in 2.5.69-bk8

[Florin Iucha]

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

On Fri, May 16, 2003 at 05:23:59PM -0400, Alan Stern wrote:
> Good.  This clearly shows the problem.  It's an error in the SCSI driver.  
> It has shown up before and been discussed at length a few weeks ago.  The
> problem is that a MODE-SENSE(6) command is requesting a transfer of 3
> bytes, which is smaller than the minimum of 4 bytes for that command.  
> The device doesn't like it and crashes.
> 
> The SCSI people are supposed to be working on this.  First, we should be 
> using MODE-SENSE(10) by default rather than MODE-SENSE(6).  Second, we 
> should never request a transfer smaller than the minimum allowed size.  
> When these changes are ready you shouldn't have any more trouble.
> 
> The OOPS you got originally was caused by the lack of proper 
> hot-unplugging cooperation between usb-storage and the SCSI driver.

At GregKH's suggestion I have opened a bug in 'zilla:
   http://bugme.osdl.org/show_bug.cgi?id=724
You might want to update it or close it.

Thank you,
florin

-- 

"NT is to UNIX what a doughnut is to a particle accelerator."

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [linux-usb-devel] USB Storage oops in 2.5.69-bk8

[Mike Anderson]

Alan Stern [stern@rowland.harvard.edu] wrote:
> Good.  This clearly shows the problem.  It's an error in the SCSI driver.  
> It has shown up before and been discussed at length a few weeks ago.  The
> problem is that a MODE-SENSE(6) command is requesting a transfer of 3
> bytes, which is smaller than the minimum of 4 bytes for that command.  
> The device doesn't like it and crashes.
> 
> The SCSI people are supposed to be working on this.  First, we should be 
> using MODE-SENSE(10) by default rather than MODE-SENSE(6).  Second, we 
> should never request a transfer smaller than the minimum allowed size.  
> When these changes are ready you shouldn't have any more trouble.
> 
> The OOPS you got originally was caused by the lack of proper 
> hot-unplugging cooperation between usb-storage and the SCSI driver.

I remember the previous conversation on the MODE-SENSE, but I think
there might be more here.

I do not believe the oops is related to the lack of proper hot-plugging
support (unless this is another way it will manifest itself). The issue
is more the interaction of the error handler and the usb storage driver.

The sequence:
"drivers/usb/core/message.c: usb_control/bulk_msg: timeout
Error handler scsi_eh_1 waking up
scsi_eh_prt_fail_stats: 1:0:0:0 cmds failed: 0, cancel: 1"

would lead one two believe that a timeout was detected both in the usb
core and in the mid layer. This would not be a good thing to have two
timeout recovery actions happening. I am not familiar with the usb
storage code so this may be incorrect. 

-andmike
--
Michael Anderson
andmike@us.ibm.com

Re: [linux-usb-devel] USB Storage oops in 2.5.69-bk8

[Alan Stern]

On Fri, 16 May 2003, Mike Anderson wrote:

> I remember the previous conversation on the MODE-SENSE, but I think
> there might be more here.
> 
> I do not believe the oops is related to the lack of proper hot-plugging
> support (unless this is another way it will manifest itself). The issue
> is more the interaction of the error handler and the usb storage driver.
> 
> The sequence:
> "drivers/usb/core/message.c: usb_control/bulk_msg: timeout
> Error handler scsi_eh_1 waking up
> scsi_eh_prt_fail_stats: 1:0:0:0 cmds failed: 0, cancel: 1"
> 
> would lead one two believe that a timeout was detected both in the usb
> core and in the mid layer. This would not be a good thing to have two
> timeout recovery actions happening. I am not familiar with the usb
> storage code so this may be incorrect. 

I think this is a red herring, and the sequence of log messages above is
not especially pertinent.  I don't have my copy of the original system log
with me here, so this is relying on memory and might be wrong -- end
disclaimer.

What happens is that the device crashes because of the 3-byte 
MODE-SENSE(6) request.  The scsi error handler tries various levels of 
fault recovery, all the way up to a bus reset.  Usb-storage implements the 
bus reset as a USB port reset, which requires usbcore to re-enumerate 
the device.  The line

   drivers/usb/core/message.c: usb_control/bulk_msg: timeout

refers to a failure during the re-enumeration.  Apparently even the port
reset was not enough to revive the device.  I don't know the reason for
the line

   Error handler scsi_eh_1 waking up

since the error handler is already running -- maybe it's related to the 
hot-unplug sequence that usb-storage goes through.  That sequence is 
pretty much guaranteed to cause an OOPS if the device is busy at the time, 
since it hasn't yet been updated properly.  (I think Matt Dharm is waiting 
to hear from someone -- like you, Mike -- that the SCSI core is ready for 
hot-unplugging.)

When the USB port reset fails as it did here, it automatically causes a 
hot-unplug event.  Usb-storage currently handles the SCSI part of that as 
follows:

	// Lock the host
	for each device on the host: sdev->online = 0;
	// Unlock the host
	scsi_remove_host(host);
	scsi_unregister_host(host);

My guess is that this sequence provokes that error handler message and 
causes the crash.

At any rate, the two timeout messages are referring to two different 
things.  One is the failure of the MODE-SENSE and the other is the failure 
of the re-enumeration.  They do not in themselves indicate a problem.

Alan Stern

Re: [linux-usb-devel] USB Storage oops in 2.5.69-bk8

[David Brownell]

> What happens is that the device crashes because of the 3-byte 
> MODE-SENSE(6) request.  The scsi error handler tries various levels of 
> fault recovery, all the way up to a bus reset.  Usb-storage implements the 
> bus reset as a USB port reset, which requires usbcore to re-enumerate 
> the device.  The line
> 
>    drivers/usb/core/message.c: usb_control/bulk_msg: timeout
> 
> refers to a failure during the re-enumeration.  Apparently even the port
> reset was not enough to revive the device.  

That reset couldn't re-assign the address, so of course it failed.

In hub.c, usb_physical_reset_device() is leaving dev->state as
USB_STATE_CONFIGURED after resetting the port, and of course it's
not legal to set the address of a device in that state.

- Dave

Re: [linux-usb-devel] USB Storage oops in 2.5.69-bk8

[Patrick Mansfield]

On Sat, May 17, 2003 at 11:29:30AM -0400, Alan Stern wrote:
> On Fri, 16 May 2003, Mike Anderson wrote:

> What happens is that the device crashes because of the 3-byte 
> MODE-SENSE(6) request.  The scsi error handler tries various levels of 
> fault recovery, all the way up to a bus reset.  Usb-storage implements the 
> bus reset as a USB port reset, which requires usbcore to re-enumerate 
> the device.  The line
> 
>    drivers/usb/core/message.c: usb_control/bulk_msg: timeout
> 
> refers to a failure during the re-enumeration.  Apparently even the port
> reset was not enough to revive the device.  I don't know the reason for
> the line
> 
>    Error handler scsi_eh_1 waking up

The above is the first thing output when the eh wakes up, so the
re-enumeration could not have started yet (at least it could not have been
initiated via scsi eh calling the bus reset or other abort/reset related
functions), and the USB timeout message could not be part of the scsi eh,
though we did not see the scsi_times_out log message (since it's wrapped
in SCSI_LOG_TIMEOUT, not SCSI_LOG_ERROR_RECOVERY).

Turning on timeout (or even all) logging might give a bit more data:

	echo "scsi log timeout 4" > /proc/scsi/scsi

Or (warning - logs the logging messages if logging to a scsi disk):

	echo "scsi log all" > /proc/scsi/scsi

-- Patrick Mansfield

Re: [linux-usb-devel] USB Storage oops in 2.5.69-bk8

[Alan Stern]

On Sat, 17 May 2003, David Brownell wrote:

> That reset couldn't re-assign the address, so of course it failed.
> 
> In hub.c, usb_physical_reset_device() is leaving dev->state as
> USB_STATE_CONFIGURED after resetting the port, and of course it's
> not legal to set the address of a device in that state.

Do you mean to say that this is a bug in usb_reset_device()?  Isn't it 
always going to be true that after a port reset a device will need to be 
assigned an address?

Alan Stern

Re: [linux-usb-devel] USB Storage oops in 2.5.69-bk8

[David Brownell]

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

Alan Stern wrote:
> On Sat, 17 May 2003, David Brownell wrote:
> 
> 
>>That reset couldn't re-assign the address, so of course it failed.
>>
>>In hub.c, usb_physical_reset_device() is leaving dev->state as
>>USB_STATE_CONFIGURED after resetting the port, and of course it's
>>not legal to set the address of a device in that state.
> 
> 
> Do you mean to say that this is a bug in usb_reset_device()?  Isn't it 
> always going to be true that after a port reset a device will need to be 
> assigned an address?

No; yes.  What I mean is that something like this patch
would seem to be needed, so USB_STATE_DEFAULT ("needs an
address") is set when the reset completes.  Untested, but
it compiles.

The enumeration logic still relies on hidden side effects.

- Dave



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

--- 1.99/drivers/usb/core/hub.c	Mon Apr 21 10:47:47 2003
+++ edited/drivers/usb/core/hub.c	Sun May 18 16:31:02 2003
@@ -737,6 +737,9 @@
 		if (status != -1) {
 			usb_clear_port_feature(hub,
 				port + 1, USB_PORT_FEAT_C_RESET);
+			dev->state = status
+					? USB_STATE_NOTATTACHED
+					: USB_STATE_DEFAULT;
 			return status;
 		}
 
--- 1.204/drivers/usb/core/usb.c	Sun May  4 23:49:53 2003
+++ edited/drivers/usb/core/usb.c	Sun May 18 16:32:19 2003
@@ -1018,7 +1018,6 @@
 	dev->dev.dma_mask = parent->dma_mask;
 
 	/* it's not usable yet */
-	dev->state = USB_STATE_DEFAULT;
 
 	/* USB 2.0 section 5.5.3 talks about ep0 maxpacket ...
 	 * it's fixed size except for full speed devices.

Re: [linux-usb-devel] USB Storage oops in 2.5.69-bk8

[Florin Iucha]

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

The problem is fixed in 2.5.70-bk5. I have closed the bug [1] in
bugzilla.

Thank you,
florin

   1. http://bugme.osdl.org/show_bug.cgi?id=724

-- 

"NT is to UNIX what a doughnut is to a particle accelerator."

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]