-current XEN build fails with WITNESS off

2009-06-06 Thread Edwin Shao
Hi all,

I am running Adrian's Xen image on a pygrub domU and am building the
kernel targeted towards production use. With that in mind, commenting
out the lines:
#optionsWITNESS # Enable checks to detect
deadlocks and cycles
#optionsWITNESS_SKIPSPIN# Don't run witness on
spinlocks for speed

Yields the error:
In file included from /usr/src/sys/dev/xen/netfront/netfront.c:33:
/usr/src/sys/sys/sx.h:211:2: error: #error LOCK_DEBUG not defined,
include sys/lock.h before sys/sx.h
mkdep: compile failed

This is reproducible, at the very least, between 20090520 and 20090606.

A very simple fix is:
diff netfront.c netfront.old.c
33d32
 #include sys/lock.h

Let me know if I am doing something stupidly wrong (as I've only been
running FreeBSD since yesterday) or if you need any more information.

Thanks,
Edwin

PS. If there is any interest, I can provide weekly or so kernel
builds. My config file is aimed towards use in a production
environment with jails use, and thus has debugging options off and
pf/vlan/NULLFS/FDESCFS enabled.


-- Error Log --


--
 Kernel build for XENNEKO started on Sat Jun  6 20:55:49 EDT 2009
--
=== XENNEKO
mkdir -p /usr/obj/usr/src/sys

--
 stage 1: configuring the kernel
--
cd /usr/src/sys/i386/conf;
PATH=/usr/obj/usr/src/tmp/legacy/usr/sbin:/usr/obj/usr/src/tmp/legacy/usr/bin:/usr/obj/usr/src/tmp/legacy/usr/games:/usr/obj/usr/src/tmp/usr/sbin:/usr/obj/usr/src/tmp/usr/bin:/usr/obj/usr/src/tmp/usr/games:/sbin:/bin:/usr/sbin:/usr/bin
 config  -d /usr/obj/usr/src/sys/XENNEKO
/usr/src/sys/i386/conf/XENNEKO
Kernel build directory is /usr/obj/usr/src/sys/XENNEKO
Don't forget to do ``make cleandepend  make depend''

--
 stage 2.1: cleaning up the object tree
--
cd /usr/obj/usr/src/sys/XENNEKO; MAKEOBJDIRPREFIX=/usr/obj
MACHINE_ARCH=i386  MACHINE=i386  CPUTYPE=pentiumpro
GROFF_BIN_PATH=/usr/obj/usr/src/tmp/legacy/usr/bin
GROFF_FONT_PATH=/usr/obj/usr/src/tmp/legacy/usr/share/groff_font
GROFF_TMAC_PATH=/usr/obj/usr/src/tmp/legacy/usr/share/tmac
_SHLIBDIRPREFIX=/usr/obj/usr/src/tmp  VERSION=FreeBSD 8.0-CURRENT
i386 800095  INSTALL=sh /usr/src/tools/install.sh
PATH=/usr/obj/usr/src/tmp/legacy/usr/sbin:/usr/obj/usr/src/tmp/legacy/usr/bin:/usr/obj/usr/src/tmp/legacy/usr/games:/usr/obj/usr/src/tmp/usr/sbin:/usr/obj/usr/src/tmp/usr/bin:/usr/obj/usr/src/tmp/usr/games:/sbin:/bin:/usr/sbin:/usr/bin
NO_CTF=1 make KERNEL=kernel cleandir
rm -f *.o *.so *.So *.ko *.s eddep errs  kernel.debug kernel
kernel.symbols  linterrs makelinks tags vers.c  vnode_if.c vnode_if.h
vnode_if_newproto.h vnode_if_typedef.h  eisa_if.c mmcbr_if.c
mmcbus_if.c card_if.c power_if.c pci_if.c pcib_if.c g_part_if.c
isa_if.c bus_if.c clock_if.c cpufreq_if.c device_if.c linker_if.c
serdev_if.c xenbus_if.c acpi_if.c eisa_if.h mmcbr_if.h mmcbus_if.h
card_if.h power_if.h pci_if.h pcib_if.h g_part_if.h isa_if.h bus_if.h
clock_if.h cpufreq_if.h device_if.h linker_if.h serdev_if.h
xenbus_if.h acpi_if.h  pccarddevs.h
rm -f .depend machine
cd /usr/src/sys/modules;
MAKEOBJDIRPREFIX=/usr/obj/usr/src/sys/XENNEKO/modules
KMODDIR=/boot/kernel MODULES_OVERRIDE= DEBUG_FLAGS=-g
MACHINE=i386 KERNBUILDDIR=/usr/obj/usr/src/sys/XENNEKO
SYSDIR=/usr/src/sys make  cleandir

--
 stage 2.2: rebuilding the object tree
--
cd /usr/obj/usr/src/sys/XENNEKO; MAKEOBJDIRPREFIX=/usr/obj
MACHINE_ARCH=i386  MACHINE=i386  CPUTYPE=pentiumpro
GROFF_BIN_PATH=/usr/obj/usr/src/tmp/legacy/usr/bin
GROFF_FONT_PATH=/usr/obj/usr/src/tmp/legacy/usr/share/groff_font
GROFF_TMAC_PATH=/usr/obj/usr/src/tmp/legacy/usr/share/tmac
_SHLIBDIRPREFIX=/usr/obj/usr/src/tmp  VERSION=FreeBSD 8.0-CURRENT
i386 800095  INSTALL=sh /usr/src/tools/install.sh
PATH=/usr/obj/usr/src/tmp/legacy/usr/sbin:/usr/obj/usr/src/tmp/legacy/usr/bin:/usr/obj/usr/src/tmp/legacy/usr/games:/usr/obj/usr/src/tmp/usr/sbin:/usr/obj/usr/src/tmp/usr/bin:/usr/obj/usr/src/tmp/usr/games:/sbin:/bin:/usr/sbin:/usr/bin
NO_CTF=1 make KERNEL=kernel obj
cd /usr/src/sys/modules;
MAKEOBJDIRPREFIX=/usr/obj/usr/src/sys/XENNEKO/modules
KMODDIR=/boot/kernel MODULES_OVERRIDE= DEBUG_FLAGS=-g
MACHINE=i386 KERNBUILDDIR=/usr/obj/usr/src/sys/XENNEKO
SYSDIR=/usr/src/sys make  obj

--
 stage 2.3: build tools
--
cd /usr/obj/usr/src/sys/XENNEKO;
MAKESRCPATH=/usr/src/sys/dev/aic7xxx/aicasm  make SSP_CFLAGS=
-DNO_CPU_CFLAGS -DNO_CTF  -f /usr/src/sys/dev/aic7xxx/aicasm/Makefile
Warning: Object directory

Re: freebsd on opensolaris dom0

2009-06-06 Thread Adrian Chadd
2009/6/7 Bruno Damour ll...@ruomad.net:

   Fatal trap 12: page fault while in kernel mode
   cpuid = 0; apic id = 00
   fault virtual address    = 0x2
   fault code        = supervisor read, page not present
   instruction pointer    = 0x21:0xc02f719b
   stack pointer            = 0x29:0xc3527bc8
   frame pointer            = 0x29:0xc3527bf8
   code segment        = base 0x0, limit 0xf9800, type 0x1b
               = DPL 1, pres 1, def32 1, gran 1
   processor eflags    = interrupt enabled, resume, IOPL = 0
   current process        = 12 (irq135: xn)
   [thread pid 12 tid 100024 ]
   Stopped at      xlvbd_add+0x204b:       cmpl    $0,0(%edx)

That seems to be dereferencing a mbuf pointer. I'll look into it.

What are you doing to trigger this condition again?


Adrian
___
freebsd-xen@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-xen
To unsubscribe, send any mail to freebsd-xen-unsubscr...@freebsd.org


Re: freebsd on opensolaris dom0

2009-06-06 Thread Bruno Damour

Adrian Chadd wrote:

That seems to be dereferencing a mbuf pointer. I'll look into it.

What are you doing to trigger this condition again?


Adrian
  

Hello,
Well it is consistently reproductible : each time I issue a cvsup command.
The interesting point is that I can _download_ without any problem with 
ftp (that is why sysinstall works) but if I start a ftpd on my host I 
get (consistently) a similar crash :


   # Kernel page fault with the following non-sleepable locks held:
   exclusive sleep mutex xennetif_tx (network transmit lock) r = 0
   (0xc39400a0) locked @
   /home/adrian/work/freebsd/xen/svn/head/sys/dev/xen/netfront/netfront.c:1118
   KDB: stack backtrace:
   X_db_sym_numargs(c0360308,c3524ab8,c0111ac5,c0383ef6,45e,...) at
   X_db_sym_numargs+0x146
   kdb_backtrace(c0383ef6,45e,,c0511c8c,c3524af0,...) at
   kdb_backtrace+0x29
   witness_display_spinlock(c036278d,c3524b04,4,1,0,...) at
   witness_display_spinlock+0x75
   witness_warn(5,0,c038c634,c3524b60,c,...) at witness_warn+0x1fd
   trap(c3524b8c) at trap+0x13e
   alltraps(c39400a0,0,c0383ef6,45e,d2cc5800,...) at alltraps+0x1b
   xlvbd_add(c394,c3524cc8,c00c3814,c03d5d00,c3783638,...) at
   xlvbd_add+0x32d0
   intr_event_execute_handlers(c37097ec,c3783600,c0358a72,4e9,c3783670,...)
   at intr_event_execute_handlers+0x125
   intr_event_add_handler(c378a440,c3524d38,c03587a5,336,c37097ec,...)
   at intr_event_add_handler+0x41f
   fork_exit(c00afcd0,c378a440,c3524d38) at fork_exit+0xb8
   fork_trampoline() at fork_trampoline+0x8
   --- trap 0, eip = 0, esp = 0xc3524d70, ebp = 0 ---


   Fatal trap 12: page fault while in kernel mode
   cpuid = 0; apic id = 00
   fault virtual address   = 0x2
   fault code  = supervisor read, page not present
   instruction pointer = 0x21:0xc0300ad9
   stack pointer   = 0x29:0xc3524bcc
   frame pointer   = 0x29:0xc3524bfc
   code segment= base 0x0, limit 0xf9800, type 0x1b
   = DPL 1, pres 1, def32 1, gran 1
   processor eflags= interrupt enabled, resume, IOPL = 0
   current process = 12 (irq134: xn)
   [thread pid 12 tid 100023 ]
   Stopped at  xlvbd_add+0x2039:   cmpl$0,0(%edi)
   db bt
   Tracing pid 12 tid 100023 td 0xc3784000
   xlvbd_add(c39400a0,0,c0383ef6,45e,d2cc5800,...) at xlvbd_add+0x2039
   xlvbd_add(c394,c3524cc8,c00c3814,c03d5d00,c3783638,...) at
   xlvbd_add+0x32d0
   intr_event_execute_handlers(c37097ec,c3783600,c0358a72,4e9,c3783670,...)
   at intr_event_execute_handlers+0x125
   intr_event_add_handler(c378a440,c3524d38,c03587a5,336,c37097ec,...)
   at intr_event_add_handler+0x41f
   fork_exit(c00afcd0,c378a440,c3524d38) at fork_exit+0xb8
   fork_trampoline() at fork_trampoline+0x8
   --- trap 0, eip = 0, esp = 0xc3524d70, ebp = 0 ---
   db

so the problem seems to come more from upload traffic than download ?

Hope it gives you some clues (I'm totally unable to help on this type of 
problems, sorry, but will  gladly  issue any command you want and report 
back).


Bruno
___
freebsd-xen@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-xen
To unsubscribe, send any mail to freebsd-xen-unsubscr...@freebsd.org