| Summary: | gentoo-sources-2.4.20-r5 causes null pointer exception upon reboot | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Jeremy Huddleston (RETIRED) <eradicator> |
| Component: | [OLD] Core system | Assignee: | x86-kernel (DEPRECATED) <x86-kernel> |
| Status: | RESOLVED FIXED | ||
| Severity: | critical | CC: | driver, steel300 |
| Priority: | High | ||
| Version: | unspecified | ||
| Hardware: | x86 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Attachments: | my kernel's .config | ||
|
Description
Jeremy Huddleston (RETIRED)
2003-05-10 13:41:59 UTC
Created attachment 11762 [details]
my kernel's .config
This is my .config for 2.4.20-r5
k, i'll see what i can find. Thanks, Jay ok, i think i see the issue. getting something like this: Unable to handle kernel NULL pointer dereference at virtual address 00000010 or the like? can you compile without RPC match support (CONFIG_IP_NF_MATCH_RPC)? do not put it the kernel nor as a module. I'm tracing down a fix, but until then I think this will solve the null pointer. Let me know if removing it resolves while I work on a permanent solution. Thanks, Jay removing that option resolves the problem. *** Bug 21247 has been marked as a duplicate of this bug. *** Same "Kernel panic" with linux-2.4.20-gentoo-r7. Removing "rpc match support" works. Okay. I'd like to squash this, so does the OOPS provide you with a stack trace, or a back trace? If it takes three hours to resync your RAID array please do this when you get some time as this isn't that urgent. If it provides you with a stack trace, can you please carefully copy it down and type it into a text file [ or send me along a photo and I can do it for you ] and then please run: #> IMPORTANT! RUN THIS ON THE FAULTY KERNEL! $> emerge ksymoops $> ksymoops < file_with_OOPS > file_with_output ... where file_with_OOPS contains your stack trace and file_with_output is what you could please paste [ NOT attach ] into bugzilla? I will be able to get you this in about a week or so as those people who rely on this system will be away (school break) and I can take the system down for maintainance. --Jeremy I decided to do the debuging on another system I had lying around... I triggered the problem in 2.4.20-gentoo-r9 and ran the ksymoops in 2.4.22-gentoo-r1: (/usr/src/linux refers to 2.4.20-gentoo-r9)
ksymoops 2.4.9 on i686 2.4.22-gentoo-r1. Options used
-v /usr/src/linux/vmlinux (specified)
-K (specified)
-L (specified)
-O (specified)
-m /usr/src/linux/System.map (default)
Unable to handle kernel NULL pointer dereference at virtual address 00000010
c01a143b
*pde = 00000000
Oops: 0002
CPU: 0
EIP: 0010:[<c01a143b>] Not tainted
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00010286
eax: 00000000 ebx: c0188964 ecx: 00000000 edx: c0159a08
esi: c014bfa4 edi: c0151000 ebp: c2ee7fc8 esp: c2ee7fc0
ds: 0018 es: 0018 ss: 0018
Process swapper (pid: 1, stackpage=c2ee7000)
Stack: c014bfa4 c0188964 c2ee7fd4 c0189104 c2ee6000 c2ee7fec c01a228c 00000000
00010f00 c014bfa4 c0151000 c014bfac c01a29ef 00000000 c01a2265 00000000
Call Trace: [<c01a228c>] [<c01a29ef>] [<c01a2265>]
Code: ff 40 10 a1 4c 1a 14 c0 83 48 14 18 a1 34 1a 14 c0 ff 40 10
>>EIP; c01a143b <init+c/7e> <=====
>>ebx; c0188964 <__initcall_init+0/4>
>>edx; c0159a08 <irq_stat+8/80>
>>esi; c014bfa4 <init_task_union+1fa4/2000>
>>edi; c0151000 <__bss_start+0/0>
Trace; c01a228c <init+27/197>
Trace; c01a29ef <arch_kernel_thread+2e/40>
Trace; c01a2265 <init+0/197>
Code; c01a143b <init+c/7e>
00000000 <_EIP>:
Code; c01a143b <init+c/7e> <=====
0: ff 40 10 incl 0x10(%eax) <=====
Code; c01a143e <init+f/7e>
3: a1 4c 1a 14 c0 mov 0xc0141a4c,%eax
Code; c01a1443 <init+14/7e>
8: 83 48 14 18 orl $0x18,0x14(%eax)
Code; c01a1447 <init+18/7e>
c: a1 34 1a 14 c0 mov 0xc0141a34,%eax
Code; c01a144c <init+1d/7e>
11: ff 40 10 incl 0x10(%eax)
<0>Kernel panic: Attempted to kill init.
1) Can you try without CONFIG_IP_NF_TARGET_ROUTE, that may be causing the problem. 2) I assume that iptables is built straight into your kernel - that can occasionally cause problems if it initializes in the wrong place. What if you modularize it? Sorry... didn't notice you responded until just now when I was checking up on old bug reports... CONFIG_IP_NF_TARGET_ROUTE was disabled with that dump. I disabled everything except the RPC match support and its dependencies. The "relevant" portion of the kernel's .config is here: # # IP: Netfilter Configuration # CONFIG_IP_NF_CONNTRACK=y # CONFIG_IP_NF_FTP is not set # CONFIG_IP_NF_AMANDA is not set # CONFIG_IP_NF_TFTP is not set # CONFIG_IP_NF_TALK is not set # CONFIG_IP_NF_RSH is not set # CONFIG_IP_NF_H323 is not set # CONFIG_IP_NF_EGG is not set # CONFIG_IP_NF_CONNTRACK_MARK is not set # CONFIG_IP_NF_IRC is not set # CONFIG_IP_NF_QUAKE3 is not set # CONFIG_IP_NF_CT_PROTO_GRE is not set # CONFIG_IP_NF_PPTP is not set # CONFIG_IP_NF_MMS is not set # CONFIG_IP_NF_CUSEEME is not set # CONFIG_IP_NF_QUEUE is not set CONFIG_IP_NF_IPTABLES=y CONFIG_IP_NF_MATCH_RPC=y # CONFIG_IP_NF_MATCH_LIMIT is not set # CONFIG_IP_NF_MATCH_QUOTA is not set # CONFIG_IP_NF_POOL is not set # CONFIG_IP_NF_MATCH_IPRANGE is not set # CONFIG_IP_NF_MATCH_MAC is not set # CONFIG_IP_NF_MATCH_PKTTYPE is not set # CONFIG_IP_NF_MATCH_MARK is not set # CONFIG_IP_NF_MATCH_MULTIPORT is not set # CONFIG_IP_NF_MATCH_MPORT is not set # CONFIG_IP_NF_MATCH_TOS is not set # CONFIG_IP_NF_MATCH_RECENT is not set # CONFIG_IP_NF_MATCH_TIME is not set # CONFIG_IP_NF_MATCH_RANDOM is not set # CONFIG_IP_NF_MATCH_PSD is not set # CONFIG_IP_NF_MATCH_NTH is not set # CONFIG_IP_NF_MATCH_IPV4OPTIONS is not set # CONFIG_IP_NF_MATCH_FUZZY is not set # CONFIG_IP_NF_MATCH_CONDITION is not set # CONFIG_IP_NF_MATCH_ECN is not set # CONFIG_IP_NF_MATCH_DSCP is not set # CONFIG_IP_NF_MATCH_AH_ESP is not set # CONFIG_IP_NF_MATCH_LENGTH is not set # CONFIG_IP_NF_MATCH_TTL is not set # CONFIG_IP_NF_MATCH_TCPMSS is not set # CONFIG_IP_NF_MATCH_STEALTH is not set # CONFIG_IP_NF_MATCH_REALM is not set # CONFIG_IP_NF_MATCH_HELPER is not set # CONFIG_IP_NF_MATCH_STATE is not set # CONFIG_IP_NF_MATCH_CONNLIMIT is not set # CONFIG_IP_NF_MATCH_CONNTRACK is not set # CONFIG_IP_NF_MATCH_UNCLEAN is not set # CONFIG_IP_NF_MATCH_STRING is not set # CONFIG_IP_NF_MATCH_OWNER is not set # CONFIG_IP_NF_FILTER is not set # CONFIG_IP_NF_NAT is not set # CONFIG_IP_NF_MANGLE is not set # CONFIG_IP_NF_TARGET_LOG is not set # CONFIG_IP_NF_TARGET_ROUTE is not set # CONFIG_IP_NF_TARGET_TTL is not set # CONFIG_IP_NF_TARGET_ULOG is not set # CONFIG_IP_NF_TARGET_TCPMSS is not set # CONFIG_IP_NF_ARPTABLES is not set I get an oops everytime by "cat /proc/uptime".
I do not have CONFIG_IP_NF_MATCH_RPC configured at all.
This is the oops:
<1>Unable to handle kernel NULL pointer dereference at virtual address 00000108
printing eip:
c02193c3
*pde = 00000000
Oops: 0000
CPU: 0
EIP: 0010:[<c02193c3>] Not tainted
EFLAGS: 00010246
eax: 00000108 ebx: 00000000 ecx: 0001cde0 edx: 00000000
esi: 00000064 edi: 0000049e ebp: 00000400 esp: c4ff1f08
ds: 0018 es: 0018 ss: 0018
Process cat (pid: 2313, stackpage=c4ff1000)
Stack: 00000000 c0219671 00000108 c0163b54 ffffffeb c2c6cdc0 c4ff0000 00000001
c2c6cdc0 c01ebad3 00000028 c4ff1f7c 00000400 00000000 c4ff1f80 c4ff3000
c47ed8e0 00000400 c4ff3000 00000400 c0217111 c4ff3000 c4ff1f80 00000000
Call Trace: [<c0219671>] [<c01ebad3>] [<c0217111>] [<c01eab33>] [<c01b0e3f>]
Code: 8b 08 89 c8 c1 e8 1f 31 d0 83 e0 01 01 c2 89 d0 31 d2 0f a4
This is the oops after ksymoops:
ksymoops 2.4.9 on i686 2.4.22-gentoo-r5. Options used
-V (default)
-k /proc/ksyms (default)
-l /proc/modules (default)
-o /lib/modules/2.4.22-gentoo-r5/ (default)
-m /usr/src/linux/System.map (default)
Warning: You did not tell me where to find symbol information. I will
assume that the log matches the kernel and modules that are running
right now and I'll use the default options above for symbol resolution.
If the current kernel and/or modules do not match the log, you can get
more accurate output by telling me the kernel version and where to find
map, modules, ksyms etc. ksymoops -h explains the options.
<1>Unable to handle kernel NULL pointer dereference at virtual address 00000108
c02193c3
*pde = 00000000
Oops: 0000
CPU: 0
EIP: 0010:[<c02193c3>] Not tainted
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00010246
eax: 00000108 ebx: 00000000 ecx: 0001cde0 edx: 00000000
esi: 00000064 edi: 0000049e ebp: 00000400 esp: c4ff1f08
ds: 0018 es: 0018 ss: 0018
Process cat (pid: 2313, stackpage=c4ff1000)
Stack: 00000000 c0219671 00000108 c0163b54 ffffffeb c2c6cdc0 c4ff0000 00000001
c2c6cdc0 c01ebad3 00000028 c4ff1f7c 00000400 00000000 c4ff1f80 c4ff3000
c47ed8e0 00000400 c4ff3000 00000400 c0217111 c4ff3000 c4ff1f80 00000000
Call Trace: [<c0219671>] [<c01ebad3>] [<c0217111>] [<c01eab33>] [<c01b0e3f>]
Code: 8b 08 89 c8 c1 e8 1f 31 d0 83 e0 01 01 c2 89 d0 31 d2 0f a4
>>EIP; c02193c3 <get_64bits+13/40> <=====
>>esp; c4ff1f08 <_end+4b74fe0/38506158>
Trace; c0219671 <uptime_read_proc+81/150>
Trace; c01ebad3 <get_empty_filp+53/160>
Trace; c0217111 <proc_file_read+c1/1e0>
Trace; c01eab33 <sys_read+a3/170>
Trace; c01b0e3f <ret+0/5>
Code; c02193c3 <get_64bits+13/40>
00000000 <_EIP>:
Code; c02193c3 <get_64bits+13/40> <=====
0: 8b 08 mov (%eax),%ecx <=====
Code; c02193c5 <get_64bits+15/40>
2: 89 c8 mov %ecx,%eax
Code; c02193c7 <get_64bits+17/40>
4: c1 e8 1f shr $0x1f,%eax
Code; c02193ca <get_64bits+1a/40>
7: 31 d0 xor %edx,%eax
Code; c02193cc <get_64bits+1c/40>
9: 83 e0 01 and $0x1,%eax
Code; c02193cf <get_64bits+1f/40>
c: 01 c2 add %eax,%edx
Code; c02193d1 <get_64bits+21/40>
e: 89 d0 mov %edx,%eax
Code; c02193d3 <get_64bits+23/40>
10: 31 d2 xor %edx,%edx
Code; c02193d5 <get_64bits+25/40>
12: 0f a4 00 00 shld $0x0,%eax,(%eax)
1 warning issued. Results may not be reliable.
I can post my .config.
The kernel is completly useable besides ps and related /proc tools not working...
BTW, This is gentoo-sources-2.4.22-r5. Should open a new bugzilla bug? -Bryan The error you are getting with 2.4.22-gentoo-r5 is because of a slight problem with the initial patch. Can you please ``emerge sync'' and re-merge gentoo-sources: after this the error should go away. Hm, it seems that CONFIG_IP_NF_MATCH_RPC isn't designed to be compiled into the kernel; so it should work if you compile it as a module? Is this fixed? Have you tried upgrading kernels? This bug has gotten stale. No repsonse from the people experiencing the error in 3 months leads me to believe this is fixed. |