Re: r8169 driver crashes in 2.6.32.43

[Kasper Dupont <kasperd@cpvhh.24.jul.2011.kasperd.net>]

On 05/08/11 16.08, Kasper Dupont wrote:
> At that point it did not itterate through the loop again
> and it did not leave the interrupt handler either. I'll
> power cycle the machine and take a closer look on the
> source to see what could possible be happening at that
> point.

I looked at the source around the place where that lockup
happened. There was absolutely no I/O or loops happening
between the two printk calls. It seemed the only real
candidate for a culprit responsible for that lockup was
the printk calls themselves.

Is it plausible that in 2.6.32.43 it is not safe to call
printk from within an interrupt handler?

I added some more printk statements in an attempt to find
out how it was possible for the code to lock up between
the end of the loop and the exit from the interrupt handler.

I wasn't able to reproduce the lockup in the same spot, but
instead I saw a lockup inside the loop in the branch where
it does netif_stop_queue.

Right now I suspect those builds where I added printk
statements lockup due to the printk statements. But does
the plain 2.6.32.43 kernel then also lockup due to printk
statements in the interrupt handler, or is it something
else?

-- 
Kasper Dupont -- Rigtige mænd skriver deres egne backupprogrammer
#define _(_)"d.%.4s%."_"2s" /* This is my email address */
char*_="@2kaspner"_()"%03"_("4s%.")"t\n";printf(_+11,_+6,_,11,_+2,_+7,_+6);