I somewhat suspect the hardware, as I've seen similar looking oopses with a
wide range of 2.1.x kernels on the same machine. They are 100%
reproducible for a given kernel with a given set of IRQs and peripherals.
Oddly the machine seems very stable under 2.1.43. In my case ipv6 is *NOT*
enabled but IP aliasing is; I suspect ipv6 and IP aliasing are just serving
as scapegoats for a different problem. The traceback originally was:
net_alias_devsetup
dev_open
dev_ifsioc
dev_ioctl
inet_ioctl
sock_ioctl
sys_ioctl
system_call
When I added some printks the problems "moved" to net_alias_dev_get and
stayed there, but I really doubt that is where the problem is.
Are you really sure the hardware is stable? And are you using tulip? And
did you have IP aliasing enabled?
David
Michael L. Galbraith (mikeg@weiden.de) wrote:
>Whenever ipv6 is enabled in 2.1.x, I get the following oops after a couple
>of minutes max. After the oops, /proc/net/dev is corrupted. Sometimes it
>is still readable afterwards, but interfaces eth0 eth0:0 ippp0 ippp1 and
>ippp2 are gone. Any program which accesses an interface hangs, and
>doesn't respond to signals.
>
>This has been happening since very early in the 2.1.x tree.. reported
>once.
>
>Myopic one (moi) isn't making a lot (~0) of progress toward fixing this.
>
>-Mike
...
>Unable to handle kernel paging request at virtual address c582a66c
>current->tss.cr3 = 042bf000, `r3 = 042bf000
>*pde = 04ed0063
>*pte = 00000000
>Oops: 0000
>CPU: 0
>EIP: 0010:[<c015c0c9>]
>EFLAGS: 00010212
>eax: 00000000 ebx: c582a66c ecx: 00000000 edx: 0000002b
>esi: c445bf5c edi: c445bf5c ebp: 00000008 esp: c445bf08
>ds: 0018 es: 0018 ss: 0018
>Process routed (pid: 254, process nr: 24, stackpage=c445b000)
>Stack: bffff194 c4931140 bffff194 00008912 00000000 c445a000 00000020
>00000000
>c445bf3c 000003e0 bffff1dc 00000400 bffff1bc 00000000 00000000 00000000
>00000000 00000000 00000000 00000000 00000000 c015c7c2 bffff194 bffff194
>Call Trace: [<c015c7c2>] [<c0178206>] [<c0157111>] [<c012bdff>]
>[<c010959a>]
>Code: 8b 13 89 d6 8b 7c 24 20 fc ac aa 84 c0 75 fa 66 8b 53 46 66
>Using `/boot/2.1.44/System.map' to map addresses to symbols.
>
>>>EIP: c015c0c9 <dev_ifconf+c1/194>
>Trace: c015c7c2 <dev_ioctl+22/80>
>Trace: c0178206 <inet_ioctl+1d2/20c>
>Trace: c0157111 <sock_ioctl+1d/24>
>Trace: c012bdff <sys_ioctl+147/15c>
>Trace: c010959a <system_call+3a/40>
>
>Code: c015c0c9 <dev_ifconf+c1/194> movl (%ebx),%edx
>Code: c015c0cb <dev_ifconf+c3/194> movl %edx,%esi
>Code: c015c0cd <dev_ifconf+c5/194> movl 0x20(%esp,1),%edi
>Code: c015c0d1 <dev_ifconf+c9/194> cld
>Code: c015c0d2 <dev_ifconf+ca/194> lodsb %ds:(%esi),%al
>Code: c015c0d3 <dev_ifconf+cb/194> stosb %al,%es:(%edi)
>Code: c015c0d4 <dev_ifconf+cc/194> testb %al,%al
>Code: c015c0d6 <dev_ifconf+ce/194> jne c015c0d2 <dev_ifconf+ca/194>
>Code: c015c0d8 <dev_ifconf+d0/194> movw 0x46(%ebx),%dx
>Code: c015c0dc <dev_ifconf+d4/194>
...
David
Niemi@erols.com 703-810-5538 Reston, Virginia, USA
--- Most operating systems, sometimes even DOS, separate different
--- types of files into different directories. The Windows philosophy:
--- Throw everything into C:\WINDOWS and let God sort it out.