I'm posting this bug here on behalf of a friend of mine. I'm posting here because the kernel guys don't want bug reports for patched kernels in their bugzilla, and so far we haven't tried this with vanilla sources. The symptom was a system freeze during boot with caps lock and scroll lock blinking. Booting into single user mode worked fine, stepwise booting from there on localized the problem in the net.eth1 startup for an Intel PRO/Wireless 2200 WLAN controller causing a kernel panic. He took a picture of the screen using his digicam and copied the message from there, so there might be typos. The message started with "kernel BUG at net/core/skbuff.c:94!", I will attach it in full later on. It is remarkable that the issue only occurred after compiling some additional modules for iptables, none of which were loaded when this error occurred. Strange coincidence or some weird interconnection between modules? The problem went away when switching to the previous kernel. It might be related with some other issue that caused the keyboard to lock up occasionally when the WLAN radio was switched on using a switch in the hardware. However in these situations the system did not freeze but stayed usable with mouse input only, and no blinking keyboard LEDs either.
Created attachment 117757 [details] Kernel panic screen This is the kernel panic message, copied manually from a photo.
Please add your friends' emerge --info. Try cleaning the kernel tree and creating the same config. If the problem persists, try disabling/enabling options in the kernel config.
(In reply to comment #0) > It is remarkable that the issue only occurred after compiling some additional > modules for iptables, none of which were loaded when this error occurred. > Strange coincidence or some weird interconnection between modules? Could you detail what you mean by this? Is it recompiling with changed config and booting with updated kernel, or just make modules_install but not refreshing kernel image used for boot? You should check if it still happens starting from a clean kernel source: make clean make make modules_install copy kernel and upate bootloader Question: which ipw2200 driver is being used, in-kernel version or ebuild?
(In reply to comment #3) > (In reply to comment #0) > > It is remarkable that the issue only occurred after compiling some additional > > modules for iptables, none of which were loaded when this error occurred. > > Strange coincidence or some weird interconnection between modules? > > Could you detail what you mean by this? > > Is it recompiling with changed config and booting with updated kernel, or just > make modules_install but not refreshing kernel image used for boot? What we were doing was this: Trying to get --status matches for iptables to work properly, we compiled the generic and IPv4 specific conntrac module as well as LOG and ULOG modules. We installed them using make modules_install, without touching the kernel image used for boot. That's why it seems so weird to me. For your other questions I'm waiting for my friend to comment here himself.
Created attachment 117763 [details] emerge --info
Created attachment 117765 [details] lspci And here the lspci if needed
(In reply to comment #3) > Question: which ipw2200 driver is being used, in-kernel version or ebuild? the in-kernel with the ipw2200-firmware as ebuild.
(In reply to comment #3) > You should check if it still happens starting from a clean kernel source: > make clean > make > make modules_install > copy kernel and upate bootloader This seems to have solved it. Strange! Thanks anyway!
I assume the reason is incompatibility between "new" modules and "old" kernel due to built-in code that comes with the iptables modules you added. In nearly all cases (to be on the safe side assume all cases) a reboot with new kernel image is required when recompiling to add/remove modules. Often modules include some generic code inside of kernal image that does auto-loading of module or even add some fields to a few kernel memory structures (can cause corruption as meaning of bits change and there is risk of overflow)
