Oopses with xen 1.2

Oopses with xen 1.2

[Oskar Pearson]

Hi Guys

I'm seeing oops messages on xen 1.2 on a system we have here. I
currently can't keep the box up for more than a couple of hours.

The box runs: apache, vsftpd, postfix, and ecartis (a mailing
list manager).

Hardware: Pentium III 500mhz, 192mb ram. At the moment it's only
running domain 0 (with 32mb ram) and then one other domain with
the remaining ram. I've run memtest86 on the box for multiple
passes, and the ram returns perfect results. The system runs
on IDE. It has a eepro1000 network card.

General setup: domain0 runs nfs, and domain1 runs with an
nfsroot environment. Both domains run iptables for protection
from the internet at large. Iptables is compiled in as series
of modules. I've used mac-address-limiting entries in the
iptables to ensure that spoofed packets can't hit the nfs
server. I don't know if this code has been tested.

Both domains have access to local disk for swap.

Reproducability: In general, I can make the system
oops with vsftpd on a fairly consistent basis, though not
always. Occasionally, though, it will oops with spamassasin. In
general, the process that oopsed will then sit in disk wait
until I restart the domain.

Often there is stuff in the oops that indicates nfs problems,
but I've tried compiling the kernel with nfs2 and nfs3 support,
and both oops.  The trace I have at the moment is not nfs
related. I'll send through other entries as they happen.

The oops below indicates vsftp problems. Every time I
perform oops analysis I get one or more oops warnings, such as
"Warning (Oops_read): Code line not seen, dumping what data is
available".  This may be because some module is not running when
I run ksymoops (after a reboot) or something. I'd appreciate
guidance on how to resolve this, if it's actually a problem.

As indicated in the version, I'm using gcc 3.2.2 for
compilation. Other oopses occur with gcc 2.95.

Should I try and run a "release" kernel that you have on an
ftp site somewhere for debugging this, that you guys know
works? I'm very keen to get the box stable - since right now
it crashes every few hours. It is a live server, though not
for a large user base.

Version:
Linux version 2.4.26-xeno (root@vm) (gcc version 3.2.2) #10 Sun May 16 20:02:54 SAST 2004

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

May 16 22:04:23 tux kernel: invalid operand: 0000
May 16 22:04:23 tux kernel: CPU:    0
May 16 22:04:23 tux kernel: EIP:    0819:[__free_pages_ok+69/752]    Not tainted
May 16 22:04:23 tux kernel: EFLAGS: 00010282
May 16 22:04:23 tux kernel: eax: c0127e10   ebx: c1172e70   ecx: c797f734   edx: c0127c60
May 16 22:04:23 tux kernel: esi: 00000000   edi: 00000000   ebp: 00000000   esp: c49b1ec0
May 16 22:04:23 tux kernel: ds: 0821   es: 0821   ss: 0821
May 16 22:04:23 tux kernel: Process vsftpd (pid: 846, stackpage=c49b1000)<1>
May 16 22:04:23 tux kernel: Stack: c00b06a3 c0127de8 c86a5d60 c797f734 00000000 c6340050 c0019860 c797f680
May 16 22:04:23 tux kernel:        00000004 07a820e0 00000000 c6340050 00001000 c0017f15 c1172e70 00000000
May 16 22:04:23 tux kernel:        c48588e0 c49b1f6c 00000001 c4d83404 40414000 40015000 00000000 c0017d6f
May 16 22:04:23 tux kernel: Call Trace: [kfree_skbmem+19/48] [set_page_dirty+144/160] [zap_pte_range+389/459] [zap_pmd_range+79/112] [zap_page_range+79/176]
May 16 22:04:27 tux kernel:  invalid operand: 0000
May 16 22:04:27 tux kernel: CPU:    0
May 16 22:04:27 tux kernel: EIP:    0819:[__free_pages_ok+69/752]    Not tainted
May 16 22:04:27 tux kernel: EFLAGS: 00010286
May 16 22:04:27 tux kernel: eax: c0127e10   ebx: c115769c   ecx: c70866d4   edx: c0127c60
May 16 22:04:27 tux kernel: esi: 00000000   edi: 00000000   ebp: 00000000   esp: c49b1ec0
May 16 22:04:27 tux kernel: ds: 0821   es: 0821   ss: 0821
May 16 22:04:27 tux kernel: Process vsftpd (pid: 847, stackpage=c49b1000)<1>
May 16 22:04:27 tux kernel: Stack: c86d7c80 c0127de8 00000001 c70866d4 00001000 c0dc365c c0019860 c7086620
May 16 22:04:27 tux kernel:        00000004 070830e0 00001000 c0dc365c 00002000 c0017f15 c115769c 00000000
May 16 22:04:27 tux kernel:        c49b1f34 fbff9000 00000001 c4ed6404 40596000 40198000 00000000 c0017d6f
May 16 22:04:27 tux kernel: Call Trace: [set_page_dirty+144/160] [zap_pte_range+389/459] [zap_pmd_range+79/112] [zap_page_range+79/176] [exit_mmap+175/320]
May 16 22:04:27 tux kernel:  invalid operand: 0000
May 16 22:04:27 tux kernel: CPU:    0
May 16 22:04:27 tux kernel: EIP:    0819:[__free_pages_ok+69/752]    Not tainted
May 16 22:04:27 tux kernel: EFLAGS: 00010286
May 16 22:04:27 tux kernel: eax: c0127e10   ebx: c1118b34   ecx: c59b6914   edx: c0127c60
May 16 22:04:27 tux kernel: esi: 00000000   edi: 00000000   ebp: 00000000   esp: c375fec0
May 16 22:04:27 tux kernel: ds: 0821   es: 0821   ss: 0821
May 16 22:04:27 tux kernel: Process vsftpd (pid: 845, stackpage=c375f000)<1>
May 16 22:04:27 tux kernel: Stack: 0805386d c0127de8 00000002 00000580 ffffffff c0127d38 c104e018 ffffffff
May 16 22:04:27 tux kernel:        00001aa3 059b50e0 00000000 c6316050 00001000 c0017f15 c1118b34 00000000
May 16 22:04:27 tux kernel:        c30a7160 c375ff6c 00000001 c1453404 40414000 40015000 00000000 c0017d6f
May 16 22:04:27 tux kernel: Call Trace: [zap_pte_range+389/459] [zap_pmd_range+79/112] [zap_page_range+79/176] [exit_mmap+175/320] [mmput+83/336]
May 16 22:04:28 tux kernel:  <1>Unable to handle kernel NULL pointer dereference at virtual address 00000000
May 16 22:04:28 tux kernel: 00000000
May 16 22:04:28 tux kernel: Oops: 0000
May 16 22:04:28 tux kernel: CPU:    0
May 16 22:04:28 tux kernel: EIP:    0819:[xeno_con_fini+0/-1073741824]    Not tainted
May 16 22:04:28 tux kernel: EFLAGS: 00010203
May 16 22:04:28 tux kernel: eax: 00000010   ebx: c1118b34   ecx: c8773864   edx: c1118b34
May 16 22:04:28 tux kernel: esi: c59b6914   edi: c59b691c   ebp: c59b6924   esp: c8779ef4
May 16 22:04:28 tux kernel: ds: 0821   es: 0821   ss: 0821
May 16 22:04:28 tux kernel: Process kupdated (pid: 6, stackpage=c8779000)<1>
May 16 22:04:28 tux kernel: Stack: c0019fce c1118b34 00000000 00000000 00000004 c59b6860 c877385c c8773800
May 16 22:04:28 tux kernel:        c003f3c3 c59b6914 00000000 c8778000 c87784f0 0000001f c8779fd0 c002e858
May 16 22:04:28 tux kernel:        c8778000 c87784f0 c002ec06 00000000 00000000 00000000 c87784f0 00000000
May 16 22:04:28 tux kernel: Call Trace: [filemap_fdatasync+142/192] [sync_unlocked_inodes+163/320] [sync_old_buffers+8/96] [kupdate+342/464] [ret_from_fork+6/32]
Warning (Oops_read): Code line not seen, dumping what data is available


>>eax; c0127e10 <contig_page_data+1b0/3c0>
>>ebx; c1172e70 <_end+1002294/8ad1424>
>>ecx; c797f734 <_end+780eb58/8ad1424>
>>edx; c0127c60 <contig_page_data+0/3c0>
>>esp; c49b1ec0 <_end+48412e4/8ad1424>
>>eax; c0127e10 <contig_page_data+1b0/3c0>
>>ebx; c115769c <_end+fe6ac0/8ad1424>
>>ecx; c70866d4 <_end+6f15af8/8ad1424>
>>edx; c0127c60 <contig_page_data+0/3c0>
>>esp; c49b1ec0 <_end+48412e4/8ad1424>
>>eax; c0127e10 <contig_page_data+1b0/3c0>
>>ebx; c1118b34 <_end+fa7f58/8ad1424>
>>ecx; c59b6914 <_end+5845d38/8ad1424>
>>edx; c0127c60 <contig_page_data+0/3c0>
>>esp; c375fec0 <_end+35ef2e4/8ad1424>
>>ebx; c1118b34 <_end+fa7f58/8ad1424>
>>ecx; c8773864 <_end+8602c88/8ad1424>
>>edx; c1118b34 <_end+fa7f58/8ad1424>
>>esi; c59b6914 <_end+5845d38/8ad1424>
>>edi; c59b691c <_end+5845d40/8ad1424>
>>ebp; c59b6924 <_end+5845d48/8ad1424>
>>esp; c8779ef4 <_end+8609318/8ad1424>


1 warning issued.  Results may not be reliable.

Thanks very much for the help. If you want, I can put the actual
kernel, system.map, modules, and so forth on a web site for you.

Cheers,

Oskar
--
Oskar Pearson <oskar@qualica.com>
Qualica Technologies (Pty) Ltd
web: http://www.qualica.com/


-------------------------------------------------------
This SF.Net email is sponsored by: SourceForge.net Broadband
Sign-up now for SourceForge Broadband and get the fastest
6.0/768 connection for only $19.95/mo for the first 3 months!
http://ads.osdn.com/?ad_id=2562&alloc_id=6184&op=click

Re: Oopses with xen 1.2

[Ian Pratt]

> I'm seeing oops messages on xen 1.2 on a system we have here. I
> currently can't keep the box up for more than a couple of hours.

Oskar,

I fixed a potential stack overflow in xenolinux in the
xeno-unstable tree. This should probably be back ported to 1.2
but I haven't had time.

The unstable tree (soon to be 2.0) is actually pretty stable
unless you enable the experimental features.

It would be useful to know whether you can reproduce using this
tree.

Ian



-------------------------------------------------------
This SF.Net email is sponsored by: SourceForge.net Broadband
Sign-up now for SourceForge Broadband and get the fastest
6.0/768 connection for only $19.95/mo for the first 3 months!
http://ads.osdn.com/?ad_id=2562&alloc_id=6184&op=click

Re: Oopses with xen 1.2

[Oskar Pearson]

Hi Ian

I'm greatful for the speedy reply.

> I fixed a potential stack overflow in xenolinux in the
> xeno-unstable tree. This should probably be back ported to 1.2
> but I haven't had time.

I'll try and get this going asap and let you know how things go.

Unfortunately, I'm only going to be able to get this going
when I next have some dedicted time. Since I'm not familiar
with that tree, I'd like sufficient time in case things start
going haywire.

> The unstable tree (soon to be 2.0) is actually pretty stable
> unless you enable the experimental features.

Ok, that's great to know.

Thanks again,

Oskar
--
Oskar Pearson <oskar@qualica.com>
Qualica Technologies (Pty) Ltd
web: http://www.qualica.com/


-------------------------------------------------------
This SF.Net email is sponsored by: SourceForge.net Broadband
Sign-up now for SourceForge Broadband and get the fastest
6.0/768 connection for only $19.95/mo for the first 3 months!
http://ads.osdn.com/?ad_id=2562&alloc_id=6184&op=click

Re: Oopses with xen 1.2

[Oskar Pearson]

Hi Everyone

> I'm seeing oops messages on xen 1.2 on a system we have here. I
> currently can't keep the box up for more than a couple of hours.
>
> The box runs: apache, vsftpd, postfix, and ecartis (a mailing
> list manager).
> 
> Hardware: Pentium III 500mhz, 192mb ram. At the moment it's only
> running domain 0 (with 32mb ram) and then one other domain with
> the remaining ram. I've run memtest86 on the box for multiple
> passes, and the ram returns perfect results. The system runs
> on IDE. It has a eepro1000 network card.

I want to provide some feedback related to the below.

Firstly, I'm still running 1.2 on that box, successfully,
given that it used to crash every few hours. It's now been
up just less than 2 days without problems - and seems to give
every indication that it's not having problems. I'll send more
details if this isn't the case.

I don't have any need to run the vsftp daemon on the machine,
and recently disabled it, as it seemed to be mentioned in a
lot of the oops messages. Since then, the machine has been
stable. One thought I have is that if someone was trying an
exploit on the machine, it might never have done anything on
the normal kernel, but does on xen.

I'm running the standard debian woody vsftpd. The details are
below. As mentioned in the description, it uses sendfile, which
I thought might have something to do with this, as it's not
a common function call, and might have less testing than most
other calls. The other option is it might have something to do
with the ftp-firewalling modules, which I run on that machine
to ensure my packet filters can handle established/related
tcp filters.

I will spend some time when I can trying to replicate this
exactly.

Package: vsftpd
Priority: extra
Section: net
Installed-Size: 180
Maintainer: Daniel Jacobowitz <dan@debian.org>
Architecture: i386
Version: 1.0.0-2
Provides: ftp-server
Depends: libc6 (>= 2.2.4-4), libcap1, libpam0g (>= 0.72-1)
Recommends: logrotate
Filename: pool/main/v/vsftpd/vsftpd_1.0.0-2_i386.deb
Size: 60082
MD5sum: 6b1faf046ee1203833f6ad7b2a542e71
Description: The Very Secure FTP Daemon
 A lightweight, efficient FTP server written from the ground up with
 security in mind.
 .
 vsftpd supports both anonymous and non-anonymous FTP, PAM authentication,
 bandwidth limiting, and the Linux sendfile() facility.

For your information, here's the rest of my description:

> General setup: domain0 runs nfs, and domain1 runs with an
> nfsroot environment. Both domains run iptables for protection
> from the internet at large. Iptables is compiled in as series
> of modules. I've used mac-address-limiting entries in the
> iptables to ensure that spoofed packets can't hit the nfs
> server. I don't know if this code has been tested.
> 
> Both domains have access to local disk for swap.
> 
> Reproducability: In general, I can make the system
> oops with vsftpd on a fairly consistent basis, though not
> always. Occasionally, though, it will oops with spamassasin. In
> general, the process that oopsed will then sit in disk wait
> until I restart the domain.
> 
> Often there is stuff in the oops that indicates nfs problems,
> but I've tried compiling the kernel with nfs2 and nfs3 support,
> and both oops.  The trace I have at the moment is not nfs
> related. I'll send through other entries as they happen.
> 
> The oops below indicates vsftp problems. Every time I
> perform oops analysis I get one or more oops warnings, such as
> "Warning (Oops_read): Code line not seen, dumping what data is
> available".  This may be because some module is not running when
> I run ksymoops (after a reboot) or something. I'd appreciate
> guidance on how to resolve this, if it's actually a problem.
> 
> As indicated in the version, I'm using gcc 3.2.2 for
> compilation. Other oopses occur with gcc 2.95.
> 
> Should I try and run a "release" kernel that you have on an
> ftp site somewhere for debugging this, that you guys know
> works? I'm very keen to get the box stable - since right now
> it crashes every few hours. It is a live server, though not
> for a large user base.
> 
> Version:
> Linux version 2.4.26-xeno (root@vm) (gcc version 3.2.2) #10 Sun May 16 20:02:54 SAST 2004
> 
> ksymoops 2.4.5 on i686 2.4.26-xeno.  Options used
>      -V (default)
>      -k /proc/ksyms (specified)
>      -l /proc/modules (specified)
>      -o /lib/modules/2.4.26-xeno/ (specified)
>      -m /boot/System.map-2.4.26-xeno (specified)
> 
> May 16 22:04:23 tux kernel: invalid operand: 0000
> May 16 22:04:23 tux kernel: CPU:    0
> May 16 22:04:23 tux kernel: EIP:    0819:[__free_pages_ok+69/752]    Not tainted
> May 16 22:04:23 tux kernel: EFLAGS: 00010282
> May 16 22:04:23 tux kernel: eax: c0127e10   ebx: c1172e70   ecx: c797f734   edx: c0127c60
> May 16 22:04:23 tux kernel: esi: 00000000   edi: 00000000   ebp: 00000000   esp: c49b1ec0
> May 16 22:04:23 tux kernel: ds: 0821   es: 0821   ss: 0821
> May 16 22:04:23 tux kernel: Process vsftpd (pid: 846, stackpage=c49b1000)<1>
> May 16 22:04:23 tux kernel: Stack: c00b06a3 c0127de8 c86a5d60 c797f734 00000000 c6340050 c0019860 c797f680
> May 16 22:04:23 tux kernel:        00000004 07a820e0 00000000 c6340050 00001000 c0017f15 c1172e70 00000000
> May 16 22:04:23 tux kernel:        c48588e0 c49b1f6c 00000001 c4d83404 40414000 40015000 00000000 c0017d6f
> May 16 22:04:23 tux kernel: Call Trace: [kfree_skbmem+19/48] [set_page_dirty+144/160] [zap_pte_range+389/459] [zap_pmd_range+79/112] [zap_page_range+79/176]
> May 16 22:04:27 tux kernel:  invalid operand: 0000
> May 16 22:04:27 tux kernel: CPU:    0
> May 16 22:04:27 tux kernel: EIP:    0819:[__free_pages_ok+69/752]    Not tainted
> May 16 22:04:27 tux kernel: EFLAGS: 00010286
> May 16 22:04:27 tux kernel: eax: c0127e10   ebx: c115769c   ecx: c70866d4   edx: c0127c60
> May 16 22:04:27 tux kernel: esi: 00000000   edi: 00000000   ebp: 00000000   esp: c49b1ec0
> May 16 22:04:27 tux kernel: ds: 0821   es: 0821   ss: 0821
> May 16 22:04:27 tux kernel: Process vsftpd (pid: 847, stackpage=c49b1000)<1>
> May 16 22:04:27 tux kernel: Stack: c86d7c80 c0127de8 00000001 c70866d4 00001000 c0dc365c c0019860 c7086620
> May 16 22:04:27 tux kernel:        00000004 070830e0 00001000 c0dc365c 00002000 c0017f15 c115769c 00000000
> May 16 22:04:27 tux kernel:        c49b1f34 fbff9000 00000001 c4ed6404 40596000 40198000 00000000 c0017d6f
> May 16 22:04:27 tux kernel: Call Trace: [set_page_dirty+144/160] [zap_pte_range+389/459] [zap_pmd_range+79/112] [zap_page_range+79/176] [exit_mmap+175/320]
> May 16 22:04:27 tux kernel:  invalid operand: 0000
> May 16 22:04:27 tux kernel: CPU:    0
> May 16 22:04:27 tux kernel: EIP:    0819:[__free_pages_ok+69/752]    Not tainted
> May 16 22:04:27 tux kernel: EFLAGS: 00010286
> May 16 22:04:27 tux kernel: eax: c0127e10   ebx: c1118b34   ecx: c59b6914   edx: c0127c60
> May 16 22:04:27 tux kernel: esi: 00000000   edi: 00000000   ebp: 00000000   esp: c375fec0
> May 16 22:04:27 tux kernel: ds: 0821   es: 0821   ss: 0821
> May 16 22:04:27 tux kernel: Process vsftpd (pid: 845, stackpage=c375f000)<1>
> May 16 22:04:27 tux kernel: Stack: 0805386d c0127de8 00000002 00000580 ffffffff c0127d38 c104e018 ffffffff
> May 16 22:04:27 tux kernel:        00001aa3 059b50e0 00000000 c6316050 00001000 c0017f15 c1118b34 00000000
> May 16 22:04:27 tux kernel:        c30a7160 c375ff6c 00000001 c1453404 40414000 40015000 00000000 c0017d6f
> May 16 22:04:27 tux kernel: Call Trace: [zap_pte_range+389/459] [zap_pmd_range+79/112] [zap_page_range+79/176] [exit_mmap+175/320] [mmput+83/336]
> May 16 22:04:28 tux kernel:  <1>Unable to handle kernel NULL pointer dereference at virtual address 00000000
> May 16 22:04:28 tux kernel: 00000000
> May 16 22:04:28 tux kernel: Oops: 0000
> May 16 22:04:28 tux kernel: CPU:    0
> May 16 22:04:28 tux kernel: EIP:    0819:[xeno_con_fini+0/-1073741824]    Not tainted
> May 16 22:04:28 tux kernel: EFLAGS: 00010203
> May 16 22:04:28 tux kernel: eax: 00000010   ebx: c1118b34   ecx: c8773864   edx: c1118b34
> May 16 22:04:28 tux kernel: esi: c59b6914   edi: c59b691c   ebp: c59b6924   esp: c8779ef4
> May 16 22:04:28 tux kernel: ds: 0821   es: 0821   ss: 0821
> May 16 22:04:28 tux kernel: Process kupdated (pid: 6, stackpage=c8779000)<1>
> May 16 22:04:28 tux kernel: Stack: c0019fce c1118b34 00000000 00000000 00000004 c59b6860 c877385c c8773800
> May 16 22:04:28 tux kernel:        c003f3c3 c59b6914 00000000 c8778000 c87784f0 0000001f c8779fd0 c002e858
> May 16 22:04:28 tux kernel:        c8778000 c87784f0 c002ec06 00000000 00000000 00000000 c87784f0 00000000
> May 16 22:04:28 tux kernel: Call Trace: [filemap_fdatasync+142/192] [sync_unlocked_inodes+163/320] [sync_old_buffers+8/96] [kupdate+342/464] [ret_from_fork+6/32]
> Warning (Oops_read): Code line not seen, dumping what data is available
> 
> 
> >>eax; c0127e10 <contig_page_data+1b0/3c0>
> >>ebx; c1172e70 <_end+1002294/8ad1424>
> >>ecx; c797f734 <_end+780eb58/8ad1424>
> >>edx; c0127c60 <contig_page_data+0/3c0>
> >>esp; c49b1ec0 <_end+48412e4/8ad1424>
> >>eax; c0127e10 <contig_page_data+1b0/3c0>
> >>ebx; c115769c <_end+fe6ac0/8ad1424>
> >>ecx; c70866d4 <_end+6f15af8/8ad1424>
> >>edx; c0127c60 <contig_page_data+0/3c0>
> >>esp; c49b1ec0 <_end+48412e4/8ad1424>
> >>eax; c0127e10 <contig_page_data+1b0/3c0>
> >>ebx; c1118b34 <_end+fa7f58/8ad1424>
> >>ecx; c59b6914 <_end+5845d38/8ad1424>
> >>edx; c0127c60 <contig_page_data+0/3c0>
> >>esp; c375fec0 <_end+35ef2e4/8ad1424>
> >>ebx; c1118b34 <_end+fa7f58/8ad1424>
> >>ecx; c8773864 <_end+8602c88/8ad1424>
> >>edx; c1118b34 <_end+fa7f58/8ad1424>
> >>esi; c59b6914 <_end+5845d38/8ad1424>
> >>edi; c59b691c <_end+5845d40/8ad1424>
> >>ebp; c59b6924 <_end+5845d48/8ad1424>
> >>esp; c8779ef4 <_end+8609318/8ad1424>
> 
> 
> 1 warning issued.  Results may not be reliable.
> 
> Thanks very much for the help. If you want, I can put the actual
> kernel, system.map, modules, and so forth on a web site for you.
> 
> Cheers,
> 
> Oskar
> --
> Oskar Pearson <oskar@qualica.com>
> Qualica Technologies (Pty) Ltd
> web: http://www.qualica.com/

Oskar
--
Oskar Pearson <oskar@qualica.com>
Qualica Technologies (Pty) Ltd
web: http://www.qualica.com/


-------------------------------------------------------
This SF.Net email is sponsored by the new InstallShield X.
>From Windows to Linux, servers to mobile, InstallShield X is the one
installation-authoring solution that does it all. Learn more and
evaluate today! http://www.installshield.com/Dev2Dev/0504

Re: Re: Oopses with xen 1.2

[Ian Pratt]

 
> > I'm seeing oops messages on xen 1.2 on a system we have here. I
> > currently can't keep the box up for more than a couple of hours.
> >
> > The box runs: apache, vsftpd, postfix, and ecartis (a mailing
> > list manager).
> > 
> > Hardware: Pentium III 500mhz, 192mb ram. At the moment it's only
> > running domain 0 (with 32mb ram) and then one other domain with
> > the remaining ram. I've run memtest86 on the box for multiple
> > passes, and the ram returns perfect results. The system runs
> > on IDE. It has a eepro1000 network card.
> 
> I want to provide some feedback related to the below.
> 
> Firstly, I'm still running 1.2 on that box, successfully,
> given that it used to crash every few hours. It's now been
> up just less than 2 days without problems - and seems to give
> every indication that it's not having problems. I'll send more
> details if this isn't the case.

Interesting. Which version of 1.2?

If you still get problems, please can you try moving to
xeno-unstable. I know of at least one bug that's fixed in
xeno-unstable that is a pain to back port to 1.2 so hasn't been
done yet (and may never be done with the forthcoming 2.0 release)
 
> I don't have any need to run the vsftp daemon on the machine,
> and recently disabled it, as it seemed to be mentioned in a
> lot of the oops messages. Since then, the machine has been
> stable. One thought I have is that if someone was trying an
> exploit on the machine, it might never have done anything on
> the normal kernel, but does on xen.

That's certainly a possibility. There'll certainly be some
exploits that will fail due to differences in the kernel.

> I'm running the standard debian woody vsftpd. The details are
> below. As mentioned in the description, it uses sendfile, which
> I thought might have something to do with this, as it's not
> a common function call, and might have less testing than most
> other calls.

We've exercised Apache very heavily, but I'm not sure whether it
uses sendfile.

The oops message is interesting. It's deep in the bowels of mm
code, so its the sort of thing you might expect to see if there
was a problem with arch xen. 

> The other option is it might have something to do
> with the ftp-firewalling modules, which I run on that machine
> to ensure my packet filters can handle established/related
> tcp filters.

Unlikely that this would lead to a xen-specific crash.
 
> I will spend some time when I can trying to replicate this
> exactly.

If you can find a way to reproduce it reliably on xeno-unstable
we'd be very interested in fixing it.

Cheers,
Ian


-------------------------------------------------------
This SF.Net email is sponsored by the new InstallShield X.
>From Windows to Linux, servers to mobile, InstallShield X is the one
installation-authoring solution that does it all. Learn more and
evaluate today! http://www.installshield.com/Dev2Dev/0504