From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9) Gecko/20020513 Description of problem: Experienced kernel panic. This happened when a process waas copying several thousand 40KB files to a single directory on an ext3 partition. Version-Release number of selected component (if applicable): How reproducible: Couldn't Reproduce Steps to Reproduce: 1.Executed the process that was running when the original panic occured. 2. 3. Actual Results: No issues. Expected Results: No issues. Additional info: ###Here is the error from /var/log/message Jun 11 22:39:12 Flanders kernel: Unable to handle kernel NULL pointer dereference at virtual address 00000008 Jun 11 22:39:12 Flanders kernel: printing eip: Jun 11 22:39:12 Flanders kernel: e0860d0c Jun 11 22:39:12 Flanders kernel: *pde = 00000000 Jun 11 22:39:12 Flanders kernel: Oops: 0000 Jun 11 22:39:12 Flanders kernel: ncpfs ipx autofs loop nfs lockd sunrpc nls_iso8859-1 nls_cp437 vfat fat sr_mod Jun 11 22:39:12 Flanders kernel: CPU: 2 Jun 11 22:39:12 Flanders kernel: EIP: 0010:[<e0860d0c>] Not tainted Jun 11 22:39:12 Flanders kernel: EFLAGS: 00010202 Jun 11 22:39:12 Flanders kernel: Jun 11 22:39:12 Flanders kernel: EIP is at ext3_new_block [ext3] 0x9c (2.4.18-4smp) Jun 11 22:39:12 Flanders kernel: eax: 00000000 ebx: 00001000 ecx: 0000000c edx: cb00c280 Jun 11 22:39:12 Flanders kernel: esi: 00000000 edi: df969000 ebp: cde48000 esp: cde49c8c Jun 11 22:39:12 Flanders automount[10936]: attempting to mount entry /opt/siarchive/pn2/servers/sipn222 Jun 11 22:39:13 Flanders kernel: ds: 0018 es: 0018 ss: 0018 Jun 11 22:39:13 Flanders kernel: Process cp (pid: 12680, stackpage=cde49000) Jun 11 22:39:13 Flanders kernel: Stack: cb00c280 00001000 00000000 00000000 c9b195c0 cde49d78 c0e5c384 c020f21e Jun 11 22:39:13 Flanders kernel: cde49d78 00000000 00000000 c0e5c374 c0e5c370 c0e5c374 c0e5c370 c9b195c 0 Jun 11 22:39:13 Flanders kernel: c01f4997 c9b195c0 00000040 00000000 e0b81000 c5e5b420 0000040a 0000040 a Jun 11 22:39:13 Flanders kernel: Call Trace: [<c020f21e>] udp_getfrag [kernel] 0x4e Jun 11 22:39:13 Flanders kernel: [<c01f4997>] ip_build_xmit [kernel] 0x2e7 Jun 11 22:39:13 Flanders kernel: [<c011a4f8>] ll_copy_to_user [kernel] 0x38 Jun 11 22:39:13 Flanders kernel: [<e086355d>] ext3_alloc_block [ext3] 0x1d Jun 11 22:39:13 Flanders kernel: [<e0863869>] ext3_alloc_branch [ext3] 0x49 Jun 11 22:39:13 Flanders kernel: [<c020f8db>] udp_recvmsg [kernel] 0xcb Jun 11 22:39:13 Flanders kernel: [<c020f997>] udp_recvmsg [kernel] 0x187 Jun 11 22:39:13 Flanders kernel: [<e0863ea7>] ext3_get_block_handle [ext3] 0x217 Jun 11 22:39:13 Flanders kernel: [<c01445f2>] create_buffers [kernel] 0x62 Jun 11 22:39:13 Flanders kernel: [<e0866341>] ext3_do_update_inode [ext3] 0x321 Jun 11 22:39:13 Flanders kernel: [<e0863fd7>] ext3_get_block [ext3] 0x67 Jun 11 22:39:13 Flanders kernel: [<c0144c0f>] __block_prepare_write [kernel] 0x12f Jun 11 22:39:13 Flanders kernel: [<e085acd0>] .rodata.str1.1 [jbd] 0x30 Jun 11 22:39:13 Flanders kernel: [<e08580c7>] __jbd_kmalloc [jbd] 0x27 Jun 11 22:39:13 Flanders kernel: [<c01455a2>] block_prepare_write [kernel] 0x22 Jun 11 22:39:13 Flanders kernel: [<e0863f70>] ext3_get_block [ext3] 0x0 Jun 11 22:39:13 Flanders kernel: [<e0864512>] ext3_prepare_write [ext3] 0xe2 Jun 11 22:39:13 Flanders kernel: [<e0863f70>] ext3_get_block [ext3] 0x0 Jun 11 22:39:13 Flanders kernel: [<c0139dc8>] __alloc_pages [kernel] 0xa8 Jun 11 22:39:13 Flanders kernel: [<c013285d>] generic_file_write [kernel] 0x4fd Jun 11 22:39:13 Flanders kernel: [<c0141bf6>] sys_write [kernel] 0x96 Jun 11 22:39:13 Flanders kernel: [<c0108c6b>] system_call [kernel] 0x33 Jun 11 22:39:13 Flanders kernel: Jun 11 22:39:13 Flanders kernel: Jun 11 22:39:13 Flanders kernel: Code: ff 50 08 83 c4 10 48 75 70 8b 45 1c 85 c0 79 13 6a 3e 68 e0
Kernel 2.4.18-4smp
have you try the kernel 2.4.18-5smp?
No, I have not tried the kernel 2.4.18-5smp. I have not been able to reproduce the panic under kernel 2.4.18-4smp.
We've seen this internally, several times, but only on one system and never under normal testing stress loads. What happens is that one of the filesystem's data structures becomes corrupt in a very predictable manner: the filesystem seems to get marked as having quotas, but there is no quota operations vector in the superblock and the filesystem OOPSes when it tries to indirect through the quota vector. It happens in several different places, and we have seen it affect both ext3 and NFS filesystems so we have, as yet, no evidence to narrow it down to any one filesystem being at fault. It would really help if you could give us as much background information on your system as you can: what workloads it serves, whether it uses software raid and/or LVM, what filesystems and device drivers it is using actively. Thanks.
I have had this on kernel 2.4.5 and it is reproducable by moving large files around the hard disk ie cdrom iso images. I have an Abit KR7A mb with an IBM deskstar 80gb ata 100 hdd. It makes no difference if I optimize with hdparm or not it will still happen. It does not happen with kernel 2.4.18-3 and I never saw as far as I can remember with 2.4.18-4, it does seem to be related to a kernel or other upgrade. Sometimes the system will be fine for 3 or 4 days sometimes it will happen frequently every few minutes. It does happen a lot when updatedb runs as a cron job. I have 896 mb ram and a 1.333gb amd athlon cpu. Video is NVidia, net card is intel eepro100, I have a wintv card initio scsi card with scsi cdwriter (HP 9200) ide cdrom. The NVidia is on its own irq as are both ide channels.
We can't reproduce this any more internally with the 2.4.18-10 errata kernel. Please reopen if you still have a problem with this version.