I have a diskless unpriveledged FreeBSD domain runnin gon 2.0.7 and FC-3. Periodically it becomes un-pingable. I can connect to the console however it is unresponsive. xm list shows the domain is continuing to consume CPU time. Is there a way to tell if I have a networking/bridging problem (which would be quite fatal for an nfs_root system) or the kernel is wedged in a loop somewhere? [root@localhost log]$ xm list Name Id Mem(MB) CPU State Time(s) Console Domain-0 0 59 0 r---- 12819.6 FreeBSD-1 12 50 1 r---- 2956.7 9612 FreeBSD-2 2 199 1 -b--- 533.1 9602 [root@localhost log]$ xm list Name Id Mem(MB) CPU State Time(s) Console Domain-0 0 59 0 r---- 12820.1 FreeBSD-1 12 50 1 r---- 2962.0 9612 FreeBSD-2 2 199 1 -b--- 533.3 9602 _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
I saw rather poor performance on the network driver - judging from the ping behaviour network interrupts only get serviced at the same time as clock interrupts. I haven't seen network hangs - but then again I never used it diskless. This is one issue I haven't really looked into. -Kip On 11/11/05, Geoff Buckingham <geoffb@chuggalug.clues.com> wrote:> > I have a diskless unpriveledged FreeBSD domain runnin gon 2.0.7 and FC-3. > > Periodically it becomes un-pingable. > > I can connect to the console however it is unresponsive. > > xm list shows the domain is continuing to consume CPU time. > > Is there a way to tell if I have a networking/bridging problem > (which would be quite fatal for an nfs_root system) or the kernel > is wedged in a loop somewhere? > > > > [root@localhost log]$ xm list > Name Id Mem(MB) CPU State Time(s) Console > Domain-0 0 59 0 r---- 12819.6 > FreeBSD-1 12 50 1 r---- 2956.7 9612 > FreeBSD-2 2 199 1 -b--- 533.1 9602 > [root@localhost log]$ xm list > Name Id Mem(MB) CPU State Time(s) Console > Domain-0 0 59 0 r---- 12820.1 > FreeBSD-1 12 50 1 r---- 2962.0 9612 > FreeBSD-2 2 199 1 -b--- 533.3 9602 > > _______________________________________________ > Xen-users mailing list > Xen-users@lists.xensource.com > http://lists.xensource.com/xen-users >_______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
Geoff Buckingham
2005-Nov-12 19:34 UTC
Re: [Xen-users] Has my FreeBSD DomU actually crashed?
On Fri, Nov 11, 2005 at 08:39:12AM -0800, Kip Macy wrote:> I saw rather poor performance on the network driver - judging from the ping > behaviour network interrupts only get serviced at the same time as clock > interrupts. I haven''t seen network hangs - but then again I never used it > diskless. > > This is one issue I haven''t really looked into. >Based on the above I thought I would try a kernel with option HZ=1000, and while configuring it I noticed the commented out witness code and enabled it. The resulting kernel panics imediatly: XENCONF WARNING: WITNESS option enabled, expect reduced performance. WARNING: DIAGNOSTIC option enabled, expect reduced performance. Timecounter "ixen" frequency 731071000 Hz quality 0 CPU: Intel Pentium III (731.07-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x683 Stepping = 3 Features=0x383fbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR,SSE> real memory = 49455104 (47 MB) avail memory = 44953600 (42 MB) WARNING: driver "evtchn" used unreserved major device number 140 cpu0 on motherboard Timecounters tick every 1.000 msec xc0: <Xen Console> on motherboard WARNING: driver "xc" used unreserved major device number 12 lpanic: blockable sleep lock (sleep mutex) taskqueue @ kern/subr_taskqueue.c:132Uptime: 1s Cannot dump. No dump device defined. Automatic reboot in 15 seconds - press a key on the console to abort --> Press a key on the console to reboot, --> or switch off the system now. Rebooting... This is obviously the documented behaviour of the witnes code, but is it a real problem or just a feature of the xen architecture? Is it actually relevent as that file is not one of those modifired? _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
It is hypothetically a problem. It isn't relevevant - it is actually a bit of brain-damagedness in the taskqueue API. I'll get around to removing its use at some point. -Kip> This is obviously the documented behaviour of the witnes code, but is it a > real > problem or just a feature of the xen architecture? > > Is it actually relevent as that file is not one of those modifired? >_______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users