Re: SMP HT + USB2.0 crash

["davor emard" <davoremard@gmail.com>]

I tested it with kernel 2.6.15.7 with nvidia
7174 drivers from which syslog's this oops capture
probably came from but the same thing but less frequently
happens with kernel 2.6.16.19 without nvidia drivers
(nvidia 7174 can't be compiled for 2.6.16.19).

For 2.6.15.7 it takes 2-10 minutes to crash, while for 2.6.16.19
it takes 1-2 days to crash. Yes it is more stable.
Usually it reports the similar oops like I supplied, but sometimes
also 2.6.16.19 reports SMP type crash - sorry I didn't have serial
console connected and didn't write it down - it looks different than
usual oops, contains less registers and no call traces showing
where in the source it crashed (I have never seen such oops before).

2.6.16.19 was running in console only mode and only with
drivers shipped in kernel. No external binary for nvidia, no
external source for ethernet. As the crash location report was
not indicatve to which module caused it, I was removing
one by one suspect module (dvb, firewire ethernet etc) and
reinserting them again until I narrowed it down to the
combination of SMP and EHCI that caused the crash.
Removing either of them makes the machine stable


On 6/4/06, davor emard <davoremard@gmail.com> wrote:
> I tested this _A_LOT_ and it doesn't matter if I
> use "nvidia" binary drivers or x.org's free "nv" or
> have just a text console with no X at all.
> It happens on a production machine :(
>
> Most easily to trigger this bug is to use USB2.0 epson
> scanner over and have scanbuttond running - it will poll
> scan buttons via usb2.0 and crash
>
> On 6/4/06, Con Kolivas <kernel@kolivas.org> wrote:
> > On Sunday 04 June 2006 20:22, davor emard wrote:
> > > Usually SMP + EHCI crashes like this
> >
> > Unless you can reproduce your crash without binary only drivers such as
> the
> > nvidia one your bug report cannot be acted upon.
> >
> > --
> > -ck
> >
>