Hello,
I've got a P5B motherboard with a Core 2 Duo E6600 processor running Edgy Eft AMD64 (with all updates done).
The card has a Realtek RTL 8168/8111 Ethernet Network Adaptater, and I'm using SATA hard drives on the Intel ICH8 controller (I'm not using the JMicron's one). I'm using the normal generic kernel 2.6.17-11 (but the bug was already there with the 2.6.17-10 kernel). The only modification that I've done is installing the nvidia driver from their website, but I think it is not loaded when my bug happens.
From times to times I'm experiencing a Kernel Panic. I've checked my RAM with memtest without problem. Here is the Kernel output (I've copied a part of it as I've got no camera, and no log is written to the disk) :
"..." stands for hexadecimal output that I assume being of no interest.
Realtek RTL 8168/8111 Family PCI-E Gigabit Ethernet Network Adaptater
Driver version: 1.02
Release date: 2006/02/23
I/O Base: 0xB800 (I/O port)
IRQ: 177
Then there is the initialisation of the SD drives (I suppose that it is my hard drives), and then :
skb_over_panic: text: fff... len: -4 put: -4 head: ff... data: ff... tail: ff... end: ff... dev: eth0
------[cut here]------[please bite here]------
Kernel BUG at net/core/skbuff.c:94
invalid opcode: 0000 [1] SMP
CPU 0
Module linked in: [here lie a long list of module, I suppose it's juste the default ones as I have not touched to my kernel]]
Pid: 4056, comm: ifconfig Not tainted 2.6.17-11-generic #2
Rip: 0010:[<...>] <...> {skb_over_panic+92}
Then there is the machine state, I'm not sure that it is useful except for the call trace, I'm listing only the function name and not the hexadecimal adress :
Call trace: <IRQ> {r1000:r1000_interupt+459}
handle_IRQ_event+44 __do_IRQ+188
__do_IRQ+66 ret_from_intr+0 <EOI>
cache_grow+779 kmem_cahce_alloc+131
__alloc_skb+75 r1000:r1000_open+436
dev_open+47 dev_change_flags+104
devinet_ioctl+741 sock_ioctl+540
do_ioctl+47 vfs_ioctl+659
sys_ioctl+108 system_call+126
Code ...
Rip <...> {skb_over_panic+92} RSP <...>
<0> Kernel panic - not syncing: Aiee, killing interrupt handler!
If there is not enough information let me now and i'll try to find a camera or something.
I've got the impression that the bug appen when the eth0 driver is loaded before the SD drives, but I'm not sure that it is the real reason. The interesting point is that when this bug happens, if I just reboot the computer by pressing the reboot button, the bug re-happens nearly always. I need to completely shut it down for a while before rebooting it, in order for the system to boot properly. So I suppose that it is maybe one of the component (the Ethernet adaptater I suppose) that is left in an improper state and that is causing the problem.
Thanks for taking the time to report this bug. Unfortunately we can't fix it, because your description didn't include enough information.
Please include the following additional information, if you have not already done so (please pay attention to lspci's additional options), as required by the Ubuntu Kernel Team:
1. Please include the output of the command "uname -a" in your next response. It should be one, long line of text which includes the exact kernel version you're running, as well as the CPU architecture.
2. Please run the command "dmesg > dmesg.log" and attach the resulting file "dmesg.log" to this bug report.
3. Please run the command "lspci -vvnn > lspci-vvnn.log" and attach the resulting file "lspci-vvnn.log" to this bug report.
For your reference, the full description of procedures for kernel-related bug reports is available here: <http://