[linux-ext4 added to CC] Holger Eitzenberger napisał(a): > Hi, > > I am currently experiencing the same Kernel crash on several machines and > Kernel version 2.6.16.43. Attached are some dumps of one particular > machine which crashed several times because of this. Up until now I was > unable to reproduce this behaviour in the testlab, also putting some I/O > on the box helped not. > > All of them happened on UP kernels, but this may be just a coincidence. >>From the logs I see that at least in one case the machine didn't stop > immediately but worked for few our from that point on until it hit the > wall. > > Looking at the traces I can say that all of them follow a codepath from > the block I/O layer downward to ext3, e.g. here in page writeback path, > see: > > kernel: Unable to handle kernel NULL pointer dereference at virtual address 00000004 > kernel: printing eip: > kernel: c018e36a > kernel: *pde = 00000000 > kernel: Oops: 0000 [#1] > kernel: Modules linked in: nfnetlink_queue ip_nat_ftp ip_conntrack_ftp > edd sg sd_mod sr_mod scsi_mod ide_cd cdrom ipt_MASQUERADE ipt_hashlimit > xt_condition ipt_REDIRECT xt_limit xt_conntrack ipt_esp xt_tcpudp > ipt_psd ipt_addrtype ip_nat_mms ip_nat_pptp ip_nat_irc iptable_nat > ebtable_nat ebtables iptable_ips ip_conntrack_mms ip_conntrack_pptp > ip_conntrack_irc ppp_deflate zlib_deflate bsd_comp sha1 > arc4 ppp_mppe ppp_async crc_ccitt ppp_generic slhc crypto_null blowfish > cast5 serpent twofish ipsec af_packet ipt_logmark ipt_confirmed > ipt_owner ipt_REJECT ipt_CONFIRMED evdev ehci_hcd uhci_hcd ohci_hcd > parport_pc ppdev parport xt_state xt_NOTRACK iptable_raw iptable_filter > ip_conntrack_netlink ip_nat ipt_LOG ip_conntrack ip_tables x_tables > nfnetlink_log nfnetlink eepro100 mii e100 capability commoncap loop > kernel: CPU: 0 > kernel: EIP: 0060:[<c018e36a>] Not tainted VLI > kernel: EFLAGS: 00010286 (2.6.16.43-46-default #1) > kernel: EIP is at walk_page_buffers+0x1a/0x70 > kernel: eax: 00000000 ebx: 00000000 ecx: 00000000 edx: 00000000 > kernel: esi: 00000000 edi: d5f3cb74 ebp: 00000000 esp: c34a5d6c > kernel: ds: 007b es: 007b ss: 0068 > kernel: Process pdflush (pid: 22753, threadinfo=c34a4000 task=cd7cb070) > kernel: Stack: <0>d573c574 dbb7c720 00000000 dbb7c720 c1114540 dbb7c720 > d5f3cb74 dbb7c720 > kernel: c01919c3 00001000 00000000 c018e3c0 cb6e1710 00000246 c1114540 > 0000000a > kernel: c01918c0 c34a5f48 c0176979 c1114540 c34a5f48 c34a5e28 00000000 > 0000000e > kernel: Call Trace: > kernel: [<c01919c3>] ext3_ordered_writepage+0x103/0x1f0 > kernel: [<c018e3c0>] bget_one+0x0/0x10 > kernel: [<c01918c0>] ext3_ordered_writepage+0x0/0x1f0 > kernel: [<c0176979>] mpage_writepages+0x1c9/0x3e0 > kernel: [<c01918c0>] ext3_ordered_writepage+0x0/0x1f0 > kernel: [<c013aa79>] do_writepages+0x49/0x50 > kernel: [<c017504c>] __writeback_single_inode+0x8c/0x3c0 > kernel: [<c02fbafc>] schedule_timeout+0x4c/0xc0 > kernel: [<c01755a8>] sync_sb_inodes+0x178/0x230 > kernel: [<c0175b1f>] writeback_inodes+0x6f/0x89 > kernel: [<c013ac59>] wb_kupdate+0xf9/0x170 > kernel: [<c013b5ee>] pdflush+0x8e/0x180 > ... > > The disassembly of write_page_buffers() is at [1]. At least some of the > other crashes happen in the sys_write() path, I have attached some of > them ([2], [3] and [4]). > > Looking at the LKML archive I can say that > > http://lkml.org/lkml/2007/3/4/11 > > looks similar. > > Any help appreciated. > > Thanks. > > /holger > > > [1] > http://ftp.astaromail.com/people/heitzenberger/v7/kernel/6313/walk_page_buffers.s > [2] > http://ftp.astaromail.com/people/heitzenberger/v7/kernel/6313/kernel-2007-05-03.log.gz > [3] http://ftp.astaromail.com/people/heitzenberger/v7/kernel/6313/kernel-2007-05-10.log.gz > [4] http://ftp.astaromail.com/people/heitzenberger/v7/kernel/6313/kernel-2007-05-15.log.gz - To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
