On Friday 19 December 2003 22:36, Alan Stern wrote:
> On Fri, 19 Dec 2003 [EMAIL PROTECTED] wrote:
> > On Friday 19 December 2003 18:35, you wrote:
> > > Matt Dharm uses 240. Max, please try 240 first, it's consistent
> > > with the 2.6. Let us know the result.
> > >
> > > -- Pete
> >
> > Thanks for your replies. I am confused.- 240? What do you mean? The patch
> > I got was against 2.4.23, which is the kernel version I use.
>
> Pete means that where I told you to put
>
> max_sectors: 128,
>
> he wants you to put instead
>
> max_sectors: 240,
>
> It's a reasonable thing to try. In fact, try each and see how they
> behave.
>
> > I have a suspicion that this problem may somehow be related to funny
> > hardware. I could not reproduce the problem on another system running the
> > same kernel version. However that system has USB 2.0 and this a different
> > UHC... Anyway, the kernel should not Oops, even with shoddy hardware, or
> > am I mistaken here? Can somebody please explain what was going on when
> > this crash happened? Somehow you must have a suspicion.
>
> This could be a result of funny hardware. Sometimes it doesn't work right
> when it receives too much data all at once. Putting that max_sectors line
> in there will reduce the amount of data in each message that gets sent to
> your device. A sector is 512 bytes, so setting max_sectors to 240 will
> limit the messages to 120 KB and setting it to 128 will limit the messages
> to 64 KB. No telling if that was really your problem, but if it was then
> this should help.
>
> You're right that the kernel shouldn't oops, regardless. But that's a
> deeper and more complicated problem. Solving it would be much harder than
> just preventing the situation from occurring in the first place. Linux
> 2.6 is (or soon will be) much better behaved in this respect.
>
> Alan Stern
Thanks for all your explanations. I have now tried both 128 and 240, same
problem. Copy lots of stuff over to the stick - Oops. Below are two examples.
The tainting of the kernel is from NVIDIA module which I swapped in for the
nv driver. The problem seems to be unrelated to the evil NVIDIA module,
happens with untainted as well.
Furthermore I have swapped out the mainboard (P3) for an Athlon board and an
AMD Prozessor. Compiled an Athlon kernel. Same thing! So the funny hardware
effect can be ruled out. Seems to work on Windows as well, on the same
hardware it crashes with Linux on.
At work, however, as I said the stick works on a USB 2.0 UHC.
Strange. It's late, I better go to bed now. Two snips from messages below. I
rebooted in between. There is always the usb_control/bulk_msg: timeout before
the Oops.
Thanks for your input, please let me know if you have more ideas.
Happy Christmas everybody!
Max
usb_control/bulk_msg: timeout
usb-uhci.c: interrupt, status 2, frame# 1632
usb.c: USB disconnect on device 00:07.2-2 address 3
Unable to handle kernel paging request at virtual address 0180001f
printing eip:
c02522ac
*pde = 00000000
Oops: 0000
CPU: 0
EIP: 0010:[<c02522ac>] Tainted: P
EFLAGS: 00013206
eax: 01800003 ebx: 000001f4 ecx: e1d5dea8 edx: efdaa640
esi: e1d5c000 edi: e1d5dea0 ebp: e1d5de90 esp: e1d5de68
ds: 0018 es: 0018 ss: 0018
Process scsi_eh_2 (pid: 2608, stackpage=e1d5d000)
Stack: e1d5c000 c02523a0 efdaa640 00000001 00000000 00000000 e1d5c000 00000000
00000000 00000000 e1d5dea8 e1d5dea8 00000000 00000000 00000000 e1d5c000
e1d5de90 e1d5de90 00000000 e4e98600 00000000 c034a140 c0252513 efdaa640
Call Trace: [<c02523a0>] [<c0252513>] [<c02525c1>] [<c0253521>]
[<c0256715>]
[<f0a04313>] [<c022ed9d>] [<c022f782>] [<c022faa6>] [<c01073bb>]
[<c022f9d0>]
Code: 8b 40 1c 85 c0 75 09 b8 ed ff ff ff 83 c4 04 c3 89 14 24 ff
usb_control/bulk_msg: timeout
usb-uhci.c: interrupt, status 2, frame# 937
usb.c: USB disconnect on device 00:07.2-2 address 3
Unable to handle kernel paging request at virtual address 0180001e
printing eip:
c02522ac
*pde = 00000000
Oops: 0000
CPU: 0
EIP: 0010:[<c02522ac>] Tainted: P
EFLAGS: 00013202
eax: 01800002 ebx: 000001f4 ecx: d76e9ea8 edx: eeba4c40
esi: d76e8000 edi: d76e9ea0 ebp: d76e9e90 esp: d76e9e68
ds: 0018 es: 0018 ss: 0018
Process scsi_eh_2 (pid: 1684, stackpage=d76e9000)
Stack: d76e8000 c02523a0 eeba4c40 00000001 00000000 00000000 d76e8000 00000000
00000000 00000000 d76e9ea8 d76e9ea8 00000000 00000000 00000000 d76e8000
d76e9e90 d76e9e90 00000000 eed21840 00000000 c034a140 c0252513 eeba4c40
Call Trace: [<c02523a0>] [<c0252513>] [<c02525c1>] [<c0253521>]
[<c0256715>]
[<f0a04313>] [<c022ed9d>] [<c022f782>] [<c022faa6>] [<c01073bb>]
[<c022f9d0>]
Code: 8b 40 1c 85 c0 75 09 b8 ed ff ff ff 83 c4 04 c3 89 14 24 ff
-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills. Sign up for IBM's
Free Linux Tutorials. Learn everything from the bash shell to sys admin.
Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
