[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Xen-devel] new(?) big ugly crash

fresh pull and build tonight. doing "/etc/init.d/xend stop" caused a lot of havoc starting with:

Kernel panic: Failed to execute MMU updates

from the dom0 kerne and then a ton of consecutive Oopses and the machine immediately rebooted. This is but the first of a series of Oopses from xfslogd. (Which probably tried to sync disks when it Oopsed to save data, which caused another Oops, making XFS try to sync, etc...)

I'm rebuilding the dom-0 kernel with more debugging options turned on (which I thought I had done) so if this happens again, maybe I'll have better data.

I notice that the Oops stack passes through some IDE writing routines, and I'm wondering if the recent crash-fix might not mess up XFS's pagebufs somewhere. XFS has its own set of filesystem cache structure type things (I wish I had a more accurate explanation...) that it manages itself to keep in sync with filesystem data and what it's buffered in memory. Is it possible that the recent fixes might interfere with/bypass this and cause corruption/desynchronization of filesystem cache and XFS pagebufs? I assume from the missing #include when I first started playing with Xen not too long ago that none of the developers are using XFS and so would not have ever looked at this data path through XFS?

ksymoops 2.4.9 on i686 2.4.26-xeno-xen0.  Options used
     -V (default)
     -k /proc/ksyms (default)
     -l /proc/modules (default)
     -o /lib/modules/2.4.26-xeno-xen0/ (default)
     -m /boot/System.map-2.4.26-xen0 (specified)

invalid operand: 0000
CPU:    0
EIP:    0819:[<c0105d2c>]    Not tainted
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00211246
eax: c11ec000   ebx: c1173080   ecx: 00000000   edx: fbff9000
esi: c11ec000   edi: c1173088   ebp: c11eda80   esp: c11eda5c
ds: 0821   es: 0821   ss: 0821
Process xfslogd/0 (pid: 8, stackpage=c11ed000)<1>
Stack: 00000000 c01e547f 00000082 00000000 00000000 00000000 c1173080 c11ec000 c1173088 c11eda8c c01ddee7 00000000 00000001 c11ec000 c1173088 c1173088 c1173080 c1176400 c27270f0 00000000 c01de0ec c1173080 c11edc70 00000000 Call Trace: [<c01e547f>] [<c01ddee7>] [<c01de0ec>] [<c01d720f>] [<c01bae08>] [<c01bf749>] [<c01bdf22>] [<c01be7c8>] [<c01af95f>] [<c01acc69>] [<c01a5b4e>] [<c01abeeb>] [<c01cc10f>] [<c01ccfb5>] [<c01f4088>] [<c022307d>] [<c021af2f>] [<c021b613>] [<c0220730>] [<c01cd676>] [<c012d441>] [<c0105dbe>] [<c0205071>] [<c01091c2>] [<c01092b5>] [<c012d4b8>] [<c012d5aa>] [<c012d6fa>] [<c012d7af>] [<c0108c2a>] [<c01e8256>] [<c01e24f6>] [<c0108348>] [<c0105c01>] [<c01d68f8>]
   [<c01d69b3>] [<c01dd6ee>] [<c01d6980>]
Warning (Oops_read): Code line not seen, dumping what data is available

>>EIP; c0105d2c <schedule+37c/390>   <=====

>>eax; c11ec000 <_end+e7315c/41031bc>
>>ebx; c1173080 <_end+dfa1dc/41031bc>
>>esi; c11ec000 <_end+e7315c/41031bc>
>>edi; c1173088 <_end+dfa1e4/41031bc>
>>ebp; c11eda80 <_end+e74bdc/41031bc>
>>esp; c11eda5c <_end+e74bb8/41031bc>

Trace; c01e547f <evtchn_do_upcall+af/110>
Trace; c01ddee7 <__down+77/f0>
Trace; c01de0ec <__down_failed+8/c>
Trace; c01d720f <.text.lock.xfs_buf+23/54>
Trace; c01bae08 <xfs_getsb+48/50>
Trace; c01bf749 <xfs_trans_getsb+39/b0>
Trace; c01bdf22 <xfs_trans_apply_sb_deltas+22/4b0>
Trace; c01be7c8 <xfs_trans_commit+298/370>
Trace; c01af95f <xfs_log_reserve+bf/d0>
Trace; c01acc69 <xfs_iomap_write_allocate+2f9/4d0>
Trace; c01a5b4e <xfs_iunlock+3e/80>
Trace; c01abeeb <xfs_iomap+3db/540>
Trace; c01cc10f <xfs_map_blocks+5f/e0>
Trace; c01ccfb5 <xfs_page_state_convert+435/5c0>
Trace; c01f4088 <add_timer_randomness+d8/f0>
Trace; c022307d <idedisk_end_request+bd/f0>
Trace; c021af2f <ide_do_request+3f/1d0>
Trace; c021b613 <ide_intr+133/1b0>
Trace; c0220730 <ide_dma_intr+0/c0>
Trace; c01cd676 <linvfs_writepage+86/130>
Trace; c012d441 <write_some_buffers+c1/120>
Trace; c0105dbe <__wake_up+7e/90>
Trace; c0205071 <serial_console_write+121/220>
Trace; c01091c2 <__call_console_drivers+62/70>
Trace; c01092b5 <call_console_drivers+65/120>
Trace; c012d4b8 <write_unlocked_buffers+18/20>
Trace; c012d5aa <sync_buffers+1a/70>
Trace; c012d6fa <fsync_dev+1a/50>
Trace; c012d7af <sys_sync+f/20>
Trace; c0108c2a <panic+11a/130>
Trace; c01e8256 <_flush_page_update_queue+76/80>
Trace; c01e24f6 <destroy_context+166/170>
Trace; c0108348 <__mmdrop+28/50>
Trace; c0105c01 <schedule+251/390>
Trace; c01d68f8 <pagebuf_iodone_daemon+108/170>
Trace; c01d69b3 <pagebuf_logiodone_daemon+33/40>
Trace; c01dd6ee <arch_kernel_thread+2e/40>
Trace; c01d6980 <pagebuf_logiodone_daemon+0/40>

"We all enter this world in the    | Support Electronic Freedom
same way: naked; screaming; soaked |        http://www.eff.org/
in blood. But if you live your     |  http://www.anti-dmca.org/
life right, that kind of thing     |---------------------------
doesn't have to stop there." -- Dana Gould

This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.