I was using 2.4.20-r2 just fine, and I've upgraded to 2.4.20-r5, and I get a null pointer exception just after iptables initializes upon reboot. I would prefer not to test this bug out in 2.4.20-r3/r4 because doing so causes me to spend 3 hours resyncing my raid. Reproducible: Always Steps to Reproduce: 1. 2. 3. Portage 2.0.47-r10 (default-x86-1.4, gcc-3.2.2, glibc-2.3.1-r4) ================================================================= System uname: 2.4.20-gentoo-r2 i686 Celeron (Mendocino) GENTOO_MIRRORS="http://gentoo.oregonstate.edu/ http://distro.ibiblio.org/pub/Linux/distributions/gentoo" CONFIG_PROTECT="/etc /var/qmail/control /usr/share/config /usr/kde/2/share/config /usr/kde/3/share/config /var/bind:/usr/X11R6/lib/X11/xkb:/usr/kde/3.1/share/config:/usr/share/config" CONFIG_PROTECT_MASK="/etc/gconf /etc/env.d" PORTDIR="/usr/portage" DISTDIR="/usr/local/download/portage/distfiles" PKGDIR="/usr/local/download/portage/packages-pentium2" PORTAGE_TMPDIR="/var/tmp" PORTDIR_OVERLAY="/usr/local/download/portage" USE="x86 oss apm avi crypt cups encode gif jpeg kde gnome libg++ mikmod mmx mpeg ncurses nls pdflib png quicktime spell truetype xml2 xmms xv zlib gdbm berkdb slang readline arts nas svga tcltk java mysql postgres X sdl gpm tcpd pam libwww ssl perl python imlib oggvorbis gtk qt motif opengl aalib acl acpi alsa atlas bonobo cdr curl dga directfb doc dvb dvd emacs esd evo fbcon flash gb gd ggi gnomedb gphoto2 gps gtk2 gtkhtml guile imap innodb ipv6 jikes junit kerberos lcms ldam leim libgda mbox mozaccess mozcalendar mozilla mozinterfaceinfo mozsvg mozxmlterm mpi mule objc odbc pcmcia pda pic plotutils pnp ruby samba sasl scanner slp snmp socks5 sse tetex tiff trusted usb wmf Xaw3d xinerama xml -3dnow" COMPILER="gcc3" CHOST="i686-pc-linux-gnu" CFLAGS="-march=pentium3 -mcpu=pentium4 -O3 -pipe -fomit-frame-pointer -falign-functions=4 -falign-jumps=4 -falign-loops=4 " CXXFLAGS="-march=pentium3 -mcpu=pentium4 -O3 -pipe -fomit-frame-pointer -falign-functions=4 -falign-jumps=4 -falign-loops=4 " ACCEPT_KEYWORDS="x86 jer" MAKEOPTS="-j2" AUTOCLEAN="yes" SYNC="rsync://rsync.gentoo.org/gentoo-portage" FEATURES="ccache buildpkg sandbox userpriv usersandbox"
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.
