WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

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

To: Derek Glidden <dglidden@xxxxxxxxxxxxxxx>
Subject: Re: [Xen-devel] new(?) big ugly crash
From: Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>
Date: Mon, 26 Jul 2004 13:10:01 +0100
Cc: xen-devel@xxxxxxxxxxxxxxxxxxxxx
Delivery-date: Mon, 26 Jul 2004 13:19:28 +0100
Envelope-to: steven.hand@xxxxxxxxxxxx
In-reply-to: Your message of "Fri, 23 Jul 2004 21:56:11 EDT." <A2F4CEA6-DD14-11D8-B4A6-000A95DBAEDE@xxxxxxxxxxxxxxx>
List-archive: <http://sourceforge.net/mailarchive/forum.php?forum=xen-devel>
List-help: <mailto:xen-devel-request@lists.sourceforge.net?subject=help>
List-id: List for Xen developers <xen-devel.lists.sourceforge.net>
List-post: <mailto:xen-devel@lists.sourceforge.net>
List-subscribe: <https://lists.sourceforge.net/lists/listinfo/xen-devel>, <mailto:xen-devel-request@lists.sourceforge.net?subject=subscribe>
List-unsubscribe: <https://lists.sourceforge.net/lists/listinfo/xen-devel>, <mailto:xen-devel-request@lists.sourceforge.net?subject=unsubscribe>
Sender: xen-devel-admin@xxxxxxxxxxxxxxxxxxxxx
Can you easily reproduce this? All the subsequent oopses are because
our panic() when the mmu updates fail ought to be a BUG() [BUG doesn't
try to sync disks; panic does] ---- it's nothing to do with XFS.

If you do a debug build of Xen then we may get useful info out as to
why the mmu_update is failing.

 -- Keir

> 
> 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



-------------------------------------------------------
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