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

[Derek Glidden <dglidden@xxxxxxxxxxxxxxx>]

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.
http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/xen-devel