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@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xen-devel
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@lists.sourceforge.net > 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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xen-devel
On Jul 26, 2004, at 8:10 AM, Keir Fraser wrote:> > 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.It popped up when all I had done was start xend and a couple domains, realize I wanted to change something, shut down the domains and tried to stop xend, so I thought it would be easy, but I haven''t been able to reproduce it at all. In fact, the machine has been running all weekend doing "serious" work (compiling and such) in four VMs without a hiccup.> If you do a debug build of Xen then we may get useful info out as to > why the mmu_update is failing.hopefully it''s not a heisenbug that goes away when I turn on better debugging info... It looks like James is hitting the same "MMU update" thing though, so maybe I should go back to the "ping and md5sum" test and see if I can induce it that way. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- "I think that''s what they mean by | "nickels a day can feed a child." | http://www.eff.org/ I thought, "How can food be so | http://www.anti-dmca.org/ cheap over there?" It''s not, they |-------------------------- just eat the nickels." -- Peter Nguyen -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- "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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xen-devel
On Jul 26, 2004, at 12:01 PM, Derek Glidden wrote:> > On Jul 26, 2004, at 8:10 AM, Keir Fraser wrote: > >> >> 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.ok, it blew up again and this time I got slightly better debugging info. Again I had started and stopped a few VMs and did "xend stop" when it all went pear-shaped. Some time shortly before the crash, I noticed this amidst the multitide of "GPF (0004)" messages that Xen emits: (XEN) (file=traps.c, line=466) GPF (0004): fc528028 -> fc52a8f4 (XEN) (file=traps.c, line=352) Page fault: fc51c7c7 -> fc52a750 (XEN) (file=traps.c, line=466) GPF (0004): fc528028 -> fc52a8f4 I''ve never see a "Page fault" message before, so don''t know if it''s related. Here''s the first bit of the actual Oops with some Xen messages that might be of some use: (XEN) (file=/opt/src/xeno/xeno-unstable.bk/xen/include/asm/mm.h, line=215) Unexpected type (saw c0000000 != exp e0000000) for pfn 00003043 (XEN) DOM0: (file=memory.c, line=248) Bad page type for pfn 00003043 (d0000002) invalid operand: 0000 CPU: 0 EIP: 0819:[<c01e3755>] Not tainted EFLAGS: 00211282 eax: 00000022 ebx: c032c830 ecx: c10e4000 edx: fbff9000 esi: 00000000 edi: ffffffff ebp: c11eff28 esp: c11eff1c ds: 0821 es: 0821 ss: 0821 Process xfsbufd (pid: 7, stackpage=c11ef000)<1> Stack: c02a9db4 0038710c c0444000 c11eff44 c01dd9df c038710c 03043063 c12b6f5c c10e4000 00000000 c11eff58 c010852a c12b6f5c c12b6f5c c12b6f5c c11eff84 c0105de1 00000000 00000000 c12b6f5c c11ee000 00000000 c031b100 000a458b Call Trace: [<c01dd9df>] [<c010852a>] [<c0105de1>] [<c0105b28>] [<c0105ab0>] [<c01d2127>] [<c01d8c6e>] [<c01d2080>] Again it caused a "cascade" of xfsbufd Oopses until it rebooted itself. I''m not sure why ksymoops continues to insist "code line not seen." I''ve compiled on just about all the kernel-hacking options possible. If there''s something I''m not doing right, I''d be happy to make it go the right way so it would stop whining about that. # ksymoops -m /boot/System.map-2.4.26-xen0 oops.txt 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) SGI XFS with no debug enabled Kernel panic: Failed to execute MMU updates SGI XFS with no debug enabled invalid operand: 0000 CPU: 0 EIP: 0819:[<c01e3755>] Not tainted Using defaults from ksymoops -t elf32-i386 -a i386 EFLAGS: 00211282 eax: 00000022 ebx: c032c830 ecx: c10e4000 edx: fbff9000 esi: 00000000 edi: ffffffff ebp: c11eff28 esp: c11eff1c ds: 0821 es: 0821 ss: 0821 Process xfsbufd (pid: 7, stackpage=c11ef000)<1> Stack: c02a9db4 0038710c c0444000 c11eff44 c01dd9df c038710c 03043063 c12b6f5c c10e4000 00000000 c11eff58 c010852a c12b6f5c c12b6f5c c12b6f5c c11eff84 c0105de1 00000000 00000000 c12b6f5c c11ee000 00000000 c031b100 000a458b Call Trace: [<c01dd9df>] [<c010852a>] [<c0105de1>] [<c0105b28>] [<c0105ab0>] [<c01d2127>] [<c01d8c6e>] [<c01d2080>] Warning (Oops_read): Code line not seen, dumping what data is available >>EIP; c01e3755 <_flush_page_update_queue+75/80> <==== >>ebx; c032c830 <update_queue+10/4000> >>ecx; c10e4000 <_end+d6f15c/41071bc> >>ebp; c11eff28 <_end+e7b084/41071bc> >>esp; c11eff1c <_end+e7b078/41071bc> Trace; c01dd9df <destroy_context+17f/190> Trace; c010852a <__mmdrop+2a/50> Trace; c0105de1 <schedule+251/390> Trace; c0105b28 <schedule_timeout+58/b0> Trace; c0105ab0 <process_timeout+0/20> Trace; c01d2127 <pagebuf_daemon+a7/200> Trace; c01d8c6e <arch_kernel_thread+2e/40> Trace; c01d2080 <pagebuf_daemon+0/200> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- "I think that''s what they mean by | "nickels a day can feed a child." | http://www.eff.org/ I thought, "How can food be so | http://www.anti-dmca.org/ cheap over there?" It''s not, they |-------------------------- just eat the nickels." -- Peter Nguyen ------------------------------------------------------- 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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xen-devel
Can you point us at the vmlinux/xen-syms files? -- Keir> > On Jul 26, 2004, at 12:01 PM, Derek Glidden wrote: > > > > > On Jul 26, 2004, at 8:10 AM, Keir Fraser wrote: > > > >> > >> 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. > > ok, it blew up again and this time I got slightly better debugging > info. Again I had started and stopped a few VMs and did "xend stop" > when it all went pear-shaped. > > Some time shortly before the crash, I noticed this amidst the multitide > of "GPF (0004)" messages that Xen emits: > > (XEN) (file=traps.c, line=466) GPF (0004): fc528028 -> fc52a8f4 > (XEN) (file=traps.c, line=352) Page fault: fc51c7c7 -> fc52a750 > (XEN) (file=traps.c, line=466) GPF (0004): fc528028 -> fc52a8f4 > > I''ve never see a "Page fault" message before, so don''t know if it''s > related. > > Here''s the first bit of the actual Oops with some Xen messages that > might be of some use: > > (XEN) (file=/opt/src/xeno/xeno-unstable.bk/xen/include/asm/mm.h, > line=215) Unexpected type (saw c0000000 != exp e0000000) for pfn > 00003043 > (XEN) DOM0: (file=memory.c, line=248) Bad page type for pfn 00003043 > (d0000002) > invalid operand: 0000 > CPU: 0 > EIP: 0819:[<c01e3755>] Not tainted > EFLAGS: 00211282 > eax: 00000022 ebx: c032c830 ecx: c10e4000 edx: fbff9000 > esi: 00000000 edi: ffffffff ebp: c11eff28 esp: c11eff1c > ds: 0821 es: 0821 ss: 0821 > Process xfsbufd (pid: 7, stackpage=c11ef000)<1> > Stack: c02a9db4 0038710c c0444000 c11eff44 c01dd9df c038710c 03043063 > c12b6f5c > c10e4000 00000000 c11eff58 c010852a c12b6f5c c12b6f5c c12b6f5c > c11eff84 > c0105de1 00000000 00000000 c12b6f5c c11ee000 00000000 c031b100 > 000a458b > Call Trace: [<c01dd9df>] [<c010852a>] [<c0105de1>] [<c0105b28>] > [<c0105ab0>] > [<c01d2127>] [<c01d8c6e>] [<c01d2080>] > > > Again it caused a "cascade" of xfsbufd Oopses until it rebooted itself. > > I''m not sure why ksymoops continues to insist "code line not seen." > I''ve compiled on just about all the kernel-hacking options possible. > If there''s something I''m not doing right, I''d be happy to make it go > the right way so it would stop whining about that. > > > # ksymoops -m /boot/System.map-2.4.26-xen0 oops.txt > 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) > > SGI XFS with no debug enabled > Kernel panic: Failed to execute MMU updates > SGI XFS with no debug enabled > invalid operand: 0000 > CPU: 0 > EIP: 0819:[<c01e3755>] Not tainted > Using defaults from ksymoops -t elf32-i386 -a i386 > EFLAGS: 00211282 > eax: 00000022 ebx: c032c830 ecx: c10e4000 edx: fbff9000 > esi: 00000000 edi: ffffffff ebp: c11eff28 esp: c11eff1c > ds: 0821 es: 0821 ss: 0821 > Process xfsbufd (pid: 7, stackpage=c11ef000)<1> > Stack: c02a9db4 0038710c c0444000 c11eff44 c01dd9df c038710c 03043063 > c12b6f5c > c10e4000 00000000 c11eff58 c010852a c12b6f5c c12b6f5c c12b6f5c > c11eff84 > c0105de1 00000000 00000000 c12b6f5c c11ee000 00000000 c031b100 > 000a458b > Call Trace: [<c01dd9df>] [<c010852a>] [<c0105de1>] [<c0105b28>] > [<c0105ab0>] > [<c01d2127>] [<c01d8c6e>] [<c01d2080>] > Warning (Oops_read): Code line not seen, dumping what data is available > > > >>EIP; c01e3755 <_flush_page_update_queue+75/80> <====> > >>ebx; c032c830 <update_queue+10/4000> > >>ecx; c10e4000 <_end+d6f15c/41071bc> > >>ebp; c11eff28 <_end+e7b084/41071bc> > >>esp; c11eff1c <_end+e7b078/41071bc> > > Trace; c01dd9df <destroy_context+17f/190> > Trace; c010852a <__mmdrop+2a/50> > Trace; c0105de1 <schedule+251/390> > Trace; c0105b28 <schedule_timeout+58/b0> > Trace; c0105ab0 <process_timeout+0/20> > Trace; c01d2127 <pagebuf_daemon+a7/200> > Trace; c01d8c6e <arch_kernel_thread+2e/40> > Trace; c01d2080 <pagebuf_daemon+0/200> > > > > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > "I think that''s what they mean by | > "nickels a day can feed a child." | http://www.eff.org/ > I thought, "How can food be so | http://www.anti-dmca.org/ > cheap over there?" It''s not, they |-------------------------- > just eat the nickels." -- Peter Nguyen > > > > ------------------------------------------------------- > 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@lists.sourceforge.net > 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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xen-devel
On Jul 27, 2004, at 4:49 AM, Keir Fraser wrote:> > Can you point us at the vmlinux/xen-syms files?I can u/l the xen-syms no worries, but all I have is a bzImage, is that a problem? -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- "I think that''s what they mean by | "nickels a day can feed a child." | http://www.eff.org/ I thought, "How can food be so | http://www.anti-dmca.org/ cheap over there?" It''s not, they |-------------------------- just eat the nickels." -- Peter Nguyen ------------------------------------------------------- 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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xen-devel
> > On Jul 27, 2004, at 4:49 AM, Keir Fraser wrote: > > > > > Can you point us at the vmlinux/xen-syms files? > > I can u/l the xen-syms no worries, but all I have is a bzImage, is that > a problem?xen-syms aren''t much use as it was a Linux crash. I''m afraid you''ll need to repeat and keep the vmlinux file. You might find the ''install'' make target useful as it''s careful to keep both the config file and vmlinux files along with the stripped vmlinuz. Ian ------------------------------------------------------- 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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xen-devel