Created attachment 34492 [details] crashlog While trying to backtrack a different bug with this, I discovered that unloading the mv643xx_eth module triggers a kernel panic on the GuruPlug Server Plus. This is with the ArmedSlack (Slackware for ARM) -current installer, but it also occurs on the real system -- I'm only able to get a trace from the installer though, for whatever reason. I'm going to file a different bug for it, but the original issue leading to this is a regression from 2.6.35 and earlier (I know 2.6.35 was fine), no traffic leaves on the ethernet ports, even though they configure correctly and /sys/class/net/<if>/carrier shows '1'. More on that in the correct bug report though :)
This doesn't seem like a mv643xx_eth-specific issue at first sight. Does your distro apply any patches to mv643xx_eth? Also, which staging driver have you loaded?
Crap, I didn't notice the taint -- it's the xgifb driver. Re patches, none to 2.6.36 - it's vanilla. I'll make sure this can be repro'd without that driver loaded, and if so, I'll post a new trace (assuming I can get one again).
Created attachment 34852 [details] New trace Well, the xgifb driver is included in the initramfs, so blacklisting it will require a bit more than I thought. Here's another trace with more lines (attached).
Oh, and the kernel now includes one patch to fix the network issue I was originally having when I discovered this bug - here's the git commit: http://git.kernel.org/?p=linux/kernel/git/next/linux-next.git;a=commit;h=be8c648051048bc66fbca590d00f3e8543ec32af
On Sun, Oct 24, 2010 at 10:04:10PM +0000, bugzilla-daemon@bugzilla.kernel.org wrote: > Well, the xgifb driver is included in the initramfs, so blacklisting > it will require a bit more than I thought. Here's another trace with > more lines (attached). It looks like there might be a timer that is getting freed without being deleted first. (If I'm reading the log right.) mv643xx_eth uses two timers (the MIB counter one and the RX OOM one), but both are deleted by mv643xx_eth_stop. Is there any chance you could build a custom kernel with a load of memory debugging options enabled? I'm sure that there are many smart people that can diagnose the problem from just this trace, but I am not one of them. :-|