Re: [PATCH v7 01/19] xen: add PV/PVH kernel entry point
Thank you for doing the split. On Thu, Dec 19, 2013 at 07:54:38PM +0100, Roger Pau Monne wrote: > Add the PV/PVH entry point and the low level functions for PVH > initialization. > --- > sys/amd64/amd64/locore.S | 53 +++ > sys/amd64/amd64/machdep.c| 72 > ++ > sys/amd64/include/asmacros.h | 26 +++ The changes to the three files above all protected by #ifdef XENHVM. IMO it is more logical to move the code into xen-specific files. The support would be localized and somewhat postpone morphing the sys/amd64 into the maze of #ifdefs, which is the sys/i386 already. pgpudXOUi42ba.pgp Description: PGP signature
Re: urtwn driver for Edimax EW-7811U WLAN nano USB Adapter
On Fri, Dec 20, 2013 at 01:35:37PM +0800, Kevin Lo wrote: > I'd like to port it after finishing RT5373 driver support. :-) Nice, looking forward to it. :) > Here's a site you could use for info about your wireless device: > http://wikidevi.com/wiki/TP-LINK_TL-WN723N_v3 Thank you Kevin. ./danfe ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
[head tinderbox] failure on powerpc/powerpc
TB --- 2013-12-20 04:12:42 - tinderbox 2.20 running on freebsd-current.sentex.ca TB --- 2013-12-20 04:12:42 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 d...@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-12-20 04:12:42 - starting HEAD tinderbox run for powerpc/powerpc TB --- 2013-12-20 04:12:42 - cleaning the object tree TB --- 2013-12-20 04:12:42 - /usr/local/bin/svn stat /src TB --- 2013-12-20 04:12:56 - At svn revision 259623 TB --- 2013-12-20 04:12:57 - building world TB --- 2013-12-20 04:12:57 - CROSS_BUILD_TESTING=YES TB --- 2013-12-20 04:12:57 - MAKEOBJDIRPREFIX=/obj TB --- 2013-12-20 04:12:57 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-12-20 04:12:57 - SRCCONF=/dev/null TB --- 2013-12-20 04:12:57 - TARGET=powerpc TB --- 2013-12-20 04:12:57 - TARGET_ARCH=powerpc TB --- 2013-12-20 04:12:57 - TZ=UTC TB --- 2013-12-20 04:12:57 - __MAKE_CONF=/dev/null TB --- 2013-12-20 04:12:57 - cd /src TB --- 2013-12-20 04:12:57 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Fri Dec 20 04:13:09 UTC 2013 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Fri Dec 20 06:48:12 UTC 2013 TB --- 2013-12-20 06:48:12 - generating LINT kernel config TB --- 2013-12-20 06:48:12 - cd /src/sys/powerpc/conf TB --- 2013-12-20 06:48:12 - /usr/bin/make -B LINT TB --- 2013-12-20 06:48:12 - cd /src/sys/powerpc/conf TB --- 2013-12-20 06:48:12 - /usr/sbin/config -m LINT TB --- 2013-12-20 06:48:12 - building LINT kernel TB --- 2013-12-20 06:48:12 - CROSS_BUILD_TESTING=YES TB --- 2013-12-20 06:48:12 - MAKEOBJDIRPREFIX=/obj TB --- 2013-12-20 06:48:12 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-12-20 06:48:12 - SRCCONF=/dev/null TB --- 2013-12-20 06:48:12 - TARGET=powerpc TB --- 2013-12-20 06:48:12 - TARGET_ARCH=powerpc TB --- 2013-12-20 06:48:12 - TZ=UTC TB --- 2013-12-20 06:48:12 - __MAKE_CONF=/dev/null TB --- 2013-12-20 06:48:12 - cd /src TB --- 2013-12-20 06:48:12 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Fri Dec 20 06:48:12 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O -pipe -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -Wa,-many -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -fstack-protector -Werror /src/sys/kern/kern_context.c cc -c -O -pipe -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -Wa,-many -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -fstack-protector -Werror /src/sys/kern/kern_descrip.c cc -c -O -pipe -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -Wa,-many -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -fstack-protector -Werror /src/sys/kern/kern_environment.c cc -c -O -pipe -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNE
Re: urtwn driver for Edimax EW-7811U WLAN nano USB Adapter
On 2013/12/19 17:51, Alexey Dokuchaev wrote: On Thu, Dec 19, 2013 at 09:56:31AM +0800, Kevin Lo wrote: Your usb wlan dongles use RTL8188EU chip which is currently not supported by any of drivers. I see; I guess I should not have believed when I was told that most likely all it would take is id-patch urtwn(4). ;-) Does anyone know if support is being worked on? Don't know either. I'd like to port it after finishing RT5373 driver support. :-) Given an increased popularity of these dongles, perhaps a wiki page would be nice for those of us who want to get an idea if some particular chip is supported before buying them (online). Here's a site you could use for info about your wireless device: http://wikidevi.com/wiki/TP-LINK_TL-WN723N_v3 ./danfe Kevin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
[head tinderbox] failure on mips/mips
TB --- 2013-12-20 03:09:31 - tinderbox 2.20 running on freebsd-current.sentex.ca TB --- 2013-12-20 03:09:31 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 d...@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-12-20 03:09:31 - starting HEAD tinderbox run for mips/mips TB --- 2013-12-20 03:09:31 - cleaning the object tree TB --- 2013-12-20 03:09:31 - /usr/local/bin/svn stat /src TB --- 2013-12-20 03:09:57 - At svn revision 259623 TB --- 2013-12-20 03:09:58 - building world TB --- 2013-12-20 03:09:58 - CROSS_BUILD_TESTING=YES TB --- 2013-12-20 03:09:58 - MAKEOBJDIRPREFIX=/obj TB --- 2013-12-20 03:09:58 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-12-20 03:09:58 - SRCCONF=/dev/null TB --- 2013-12-20 03:09:58 - TARGET=mips TB --- 2013-12-20 03:09:58 - TARGET_ARCH=mips TB --- 2013-12-20 03:09:58 - TZ=UTC TB --- 2013-12-20 03:09:58 - __MAKE_CONF=/dev/null TB --- 2013-12-20 03:09:58 - cd /src TB --- 2013-12-20 03:09:58 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Fri Dec 20 03:10:06 UTC 2013 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Fri Dec 20 04:11:20 UTC 2013 TB --- 2013-12-20 04:11:20 - cd /src/sys/mips/conf TB --- 2013-12-20 04:11:20 - /usr/sbin/config -m ADM5120 TB --- 2013-12-20 04:11:20 - skipping ADM5120 kernel TB --- 2013-12-20 04:11:20 - cd /src/sys/mips/conf TB --- 2013-12-20 04:11:20 - /usr/sbin/config -m ALCHEMY TB --- 2013-12-20 04:11:20 - skipping ALCHEMY kernel TB --- 2013-12-20 04:11:20 - cd /src/sys/mips/conf TB --- 2013-12-20 04:11:20 - /usr/sbin/config -m ALFA_HORNET_UB TB --- 2013-12-20 04:11:20 - building ALFA_HORNET_UB kernel TB --- 2013-12-20 04:11:20 - CROSS_BUILD_TESTING=YES TB --- 2013-12-20 04:11:20 - MAKEOBJDIRPREFIX=/obj TB --- 2013-12-20 04:11:20 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-12-20 04:11:20 - SRCCONF=/dev/null TB --- 2013-12-20 04:11:20 - TARGET=mips TB --- 2013-12-20 04:11:20 - TARGET_ARCH=mips TB --- 2013-12-20 04:11:20 - TZ=UTC TB --- 2013-12-20 04:11:20 - __MAKE_CONF=/dev/null TB --- 2013-12-20 04:11:20 - cd /src TB --- 2013-12-20 04:11:20 - /usr/bin/make -B buildkernel KERNCONF=ALFA_HORNET_UB >>> Kernel build for ALFA_HORNET_UB started on Fri Dec 20 04:11:20 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 --param max-inline-insns-single=1000 -fno-pic -mno-abicalls -G0 -DKERNLOADADDR=0x8005 -march=mips32 -msoft-float -ffreestanding -Werror /src/sys/kern/kern_context.c cc -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 --param max-inline-insns-single=1000 -fno-pic -mno-abicalls -G0 -DKERNLOADADDR=0x8005 -march=mips32 -msoft-float -ffreestanding -Werror /src/sys/kern/kern_descrip.c cc -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 --param max-inline-insns-single=1000 -fno-pic -mno-abicalls -G0 -DKERNLOADADDR=0x8005 -march=mips32 -msoft-float -ffreestanding -Werror /src/sys/kern/kern_environment.c cc -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototype
md2 on current and 10.
It would appear, neither nor are any longer available on FreeBSD current and 10.x This breaks the devel/tcl-trf port, which I maintain... Could someone, please, comment? Should I patch-up the port to disable the functionality? Or?.. Thank you! -mi ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: ral(4) panic. head, r257837
Well there's a null node pointer. Need to figure out why. Its totally legit
to have them too, so the code has to cope.
Grr.
Adrian
On Dec 19, 2013 2:07 AM, "Sergey V. Dyatko" wrote:
> On Wed, 18 Dec 2013 23:40:23 -0800
> Adrian Chadd wrote:
>
> > What's at frame 10?
> >
> > And list the IP, ie:
> >
> > list *0x817da911
> >
>
> (kgdb) f 10
> #10 0x817da911 in rt2860_tx (sc=0xfe9bd000,
> m=0xf80004c6dd00, ni=0x0)
> at /usr/src/sys/modules/ral/../../dev/ral/rt2860.c:1472 1472{
> Current language: auto; currently minimal
>
> (kgdb) list *0x817da911
> 0x817da911 is in rt2860_tx
> (/usr/src/sys/modules/ral/../../dev/ral/rt2860.c:1475). 1470static
> int 1471rt2860_tx(struct rt2860_softc *sc, struct mbuf *m, struct
> ieee80211_node *ni) 1472{
> 1473struct ifnet *ifp = sc->sc_ifp;
> 1474struct ieee80211com *ic = ifp->if_l2com;
> 1475struct ieee80211vap *vap = ni->ni_vap;
> 1476struct rt2860_tx_ring *ring;
> 1477struct rt2860_tx_data *data;
> 1478struct rt2860_txd *txd;
> 1479struct rt2860_txwi *txwi;
>
> > -a
> >
> > On 18 December 2013 23:04, Sergey V. Dyatko
> > wrote:
> > > Hi,
> > >
> > > I have following setup:
> > >
> > > wlans_ral0="wlan0"
> > > ifconfig_wlan0="WPA"
> > >
> > > cloned_interfaces="lagg0 bridge0 tap0"
> > > ifconfig_lagg0="laggproto failover laggport alc0 laggport wlan0
> > > DHCP" ifconfig_bridge0="addm tap0 addm lagg0"
> > >
> > > When system boot I have reproducible panic after messages
> > > Waiting 30s for the default route interface: .
> > > ral0: need multicast update callback
> > > ral0: need multicast update callback
> > > :
> > >
> > > Fatal trap 12: page fault while in kernel mode
> > > cpuid = 0; apic id = 00
> > > fault virtual address = 0x0
> > > fault code = supervisor read data, page not present
> > > instruction pointer = 0x20:0x817da911
> > > stack pointer = 0x28:0xfe011fe61da0
> > > frame pointer = 0x28:0xfe011fe62630
> > > <118>.
> > > code segment= base 0x0, limit 0xf, type 0x1b
> > > = DPL 0, pres 1, long 1, def32 0, gran 1
> > > processor eflags= interrupt enabled, resume, IOPL = 0
> > > current process = 1815 (dhclient)
> > >
> > > Reading symbols from /boot/kernel/zfs.ko.symbols...done.
> > > Loaded symbols for /boot/kernel/zfs.ko.symbols
> > > Reading symbols from /boot/kernel/opensolaris.ko.symbols...done.
> > > Loaded symbols for /boot/kernel/opensolaris.ko.symbols
> > > Reading symbols from /boot/kernel/linux.ko.symbols...done.
> > > Loaded symbols for /boot/kernel/linux.ko.symbols
> > > Reading symbols from /boot/kernel/if_alc.ko.symbols...done.
> > > Loaded symbols for /boot/kernel/if_alc.ko.symbols
> > > Reading symbols from /boot/kernel/if_ral.ko.symbols...done.
> > > Loaded symbols for /boot/kernel/if_ral.ko.symbols
> > > Reading symbols from /boot/kernel/snd_hda.ko.symbols...done.
> > > Loaded symbols for /boot/kernel/snd_hda.ko.symbols
> > > Reading symbols from /boot/kernel/sound.ko.symbols...done.
> > > Loaded symbols for /boot/kernel/sound.ko.symbols
> > > Reading symbols from /boot/kernel/acpi_video.ko.symbols...done.
> > > Loaded symbols for /boot/kernel/acpi_video.ko.symbols
> > > Reading symbols from /boot/modules/nvidia.ko...done.
> > > Loaded symbols for /boot/modules/nvidia.ko
> > > Reading symbols from /boot/modules/cuse4bsd.ko...done.
> > > Loaded symbols for /boot/modules/cuse4bsd.ko
> > > Reading symbols from /boot/kernel/sem.ko.symbols...done.
> > > Loaded symbols for /boot/kernel/sem.ko.symbols
> > > Reading symbols from /boot/kernel/linprocfs.ko.symbols...done.
> > > Loaded symbols for /boot/kernel/linprocfs.ko.symbols
> > > Reading symbols from /boot/kernel/if_lagg.ko.symbols...done.
> > > Loaded symbols for /boot/kernel/if_lagg.ko.symbols
> > > Reading symbols from /boot/kernel/if_bridge.ko.symbols...done.
> > > Loaded symbols for /boot/kernel/if_bridge.ko.symbols
> > > Reading symbols from /boot/kernel/bridgestp.ko.symbols...done.
> > > Loaded symbols for /boot/kernel/bridgestp.ko.symbols
> > > Reading symbols from /boot/kernel/if_tap.ko.symbols...done.
> > > Loaded symbols for /boot/kernel/if_tap.ko.symbols
> > >
> > > #0 doadump (textdump=0) at pcpu.h:219
> > > 219 pcpu.h: No such file or directory.
> > > in pcpu.h
> > > (kgdb) #0 doadump (textdump=0) at pcpu.h:219
> > > #1 0x803023ae in db_dump (dummy=,
> > > dummy2=0, dummy3=0, dummy4=0x0) at /usr/src/sys/ddb/db_command.c:543
> > > #2 0x80301e8d in db_command (cmd_table= > > out>) at /usr/src/sys/ddb/db_command.c:449
> > > #3 0x80301c04 in db_command_loop ()
> > > at /usr/src/sys/ddb/db_command.c:502
> > > #4 0x80304570 in db_trap (type=,
> > > code=0) at /usr/src/sys/ddb/db_main.c:231
> > > #5 0x8072e9d3 in kdb_trap (type=12, code=0, tf= > > optimized out
Re: FreeBSD 10 and zfsd
On Wed, Dec 18, 2013 at 2:40 PM, Outback Dingo wrote: > > > > On Wed, Dec 18, 2013 at 4:40 PM, Alan Somers wrote: >> >> On Wed, Dec 18, 2013 at 11:47 AM, Outback Dingo >> wrote: >> > >> > >> > On Wed, Dec 18, 2013 at 12:39 PM, Mark Felder wrote: >> >> >> >> On Thu, Oct 10, 2013, at 11:26, Alan Somers wrote: >> >> > >> >> > Due to popular demand, I have located a round toit. I'm currently >> >> > working on rebasing the zfsd project branch to head, after which I'll >> >> > push SpectraLogic's recent changes. >> >> > >> >> >> >> Just thought I'd ping the list about the situation here... would love >> >> to >> >> see this in HEAD soon :) >> > >> > >> > >> > Id love to see an updated patch from the zfsd tree against head itself >> > so we >> > could continue using and testing it >> >> Coming up ... >> > > Sweet..!!! Sorry, but I'm running into nontrivial merge conflicts. It's going to take a few more days. -Alan > > >> >> > >> >> >> >> ___ >> >> freebsd-current@freebsd.org mailing list >> >> http://lists.freebsd.org/mailman/listinfo/freebsd-current >> >> To unsubscribe, send any mail to >> >> "freebsd-current-unsubscr...@freebsd.org" >> > >> > > > ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: r259072 is not a happy camper...
On Wednesday, December 18, 2013 5:45:57 pm Poul-Henning Kamp wrote: > In message <201312181458.20649@freebsd.org>, John Baldwin writes: > > >> >Does it get a crashdump if you try? > >> > >> No :-( > >> > >> There may be a connection to unclean UFS filesystems (SU + TRIM, no J). > > > >Is this reproducible? > > Not really. > > It seems to happen at random, usually shortly after boot and as I > mentioned, there is some indications of it being related to munged > filesystems. > > Amongst these indications: > > Booting single-user and running fsck (without -p) almost always > prevents it from happening until after next crash, and I think all > the backtraces I've see have been UFS or maybe even WITNESS+UFS > related. > > If it is WITNESS related, the serial console is obviously a > prime suspect... > > But all that said, I havn't seen it for a couple of days... Humm. I'm kind of out of ideas then. -- John Baldwin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Strange coredumps with virtualized i386 FreeBSD 10
Larry, On Thu, Dec 19, 2013 at 10:33:32AM -0500, Larry Baird wrote: L> > On Thu, Dec 19, 2013 at 09:51:16AM -0500, Larry Baird wrote: L> > L> Does anybody else have issues with running i386 FreeBSD 10 under Virtual Box? L> > L> I have been running a number of different versions of FreeBSD under Virtual L> > L> Box for some time without any issues. Last week I installed amd64 FreeBSD L> > L> 10 rc1 without any issue. Yesterday I decided to try i386 FreeBSD 10 rc1. L> > L> Install seemed to go ok. After initial boot I tried to update ports using L> > L> portsnap. I got a message about corrupted zip file. I initially thought L> > L> something was wrong with portsnap. Nothing I tried seemed to fix the issue, L> > L> so I moved on. I tried to build subversion. I got coredumps from cc and was L> > L> unable to build any ports. I decided something must have gone wrong with the L> > L> install. I reinstalled and got the same results. I then downloaded and L> > L> installed i386 FreeBSD 10 rc2. I had the same issues. So I then installed L> > L> FreeBSD 10 rc1 amd64. No issues, everything seemed to behave as expected. L> > L> I then installed FreeBSD 9.2 i386. No issues. I then used subversion and L> > L> mergemaster to upgrade to FreeBSD 10 stable. After doing upgrade, I once L> > L> again get coredumps from cc. L> > L> L> > L> In case it matters Virtual box is version 4.3.4 running under Windows 7 64 bit. L> > L> L> > L> Anybody else having issues with i386 FreeBSD 10? L> > L> > Can you please set L> > L> > vfs.unmapped_buf_allowed=0 L> > L> > in boot loader and try to reproduce the problem? L> This seemed to fix the issue. I can now use portsnap and I have successfully L> compiled serveral ports. L> L> Is "unmapped_buf_allowed" a virtualization issue or an i386 issue? We do not yet sure diagnosis yet, but this looks like a bug in the VirtualBox. -- Totus tuus, Glebius. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
[PATCH v7 10/19] xen: add hook for AP bootstrap memory reservation
This hook will only be implemented for bare metal, Xen doesn't require
any bootstrap code since APs are started in long mode with paging
enabled.
---
sys/amd64/amd64/machdep.c |6 +-
sys/amd64/include/sysarch.h |3 +++
2 files changed, 8 insertions(+), 1 deletions(-)
diff --git a/sys/amd64/amd64/machdep.c b/sys/amd64/amd64/machdep.c
index 6bbfe5a..a811a9b 100644
--- a/sys/amd64/amd64/machdep.c
+++ b/sys/amd64/amd64/machdep.c
@@ -186,6 +186,9 @@ struct init_ops init_ops = {
.early_delay_init = i8254_init,
.early_delay = i8254_delay,
.parse_memmap = native_parse_memmap,
+#ifdef SMP
+ .mp_bootaddress = mp_bootaddress,
+#endif
};
/*
@@ -1507,7 +1510,8 @@ getmemsize(caddr_t kmdp, u_int64_t first)
#ifdef SMP
/* make hole for AP bootstrap code */
- physmap[1] = mp_bootaddress(physmap[1] / 1024);
+ if (init_ops.mp_bootaddress)
+ physmap[1] = init_ops.mp_bootaddress(physmap[1] / 1024);
#endif
/*
diff --git a/sys/amd64/include/sysarch.h b/sys/amd64/include/sysarch.h
index 084223e..77f4b29 100644
--- a/sys/amd64/include/sysarch.h
+++ b/sys/amd64/include/sysarch.h
@@ -16,6 +16,9 @@ struct init_ops {
void(*early_delay_init)(void);
void(*early_delay)(int);
void(*parse_memmap)(caddr_t, vm_paddr_t *, int *);
+#ifdef SMP
+ u_int (*mp_bootaddress)(u_int);
+#endif
};
extern struct init_ops init_ops;
--
1.7.7.5 (Apple Git-26)
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
[PATCH v7 19/19] isa: allow ISA bus to attach to the nexus
--- sys/x86/isa/isa.c |3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) diff --git a/sys/x86/isa/isa.c b/sys/x86/isa/isa.c index 1a57137..09d1ab7 100644 --- a/sys/x86/isa/isa.c +++ b/sys/x86/isa/isa.c @@ -241,3 +241,6 @@ isa_release_resource(device_t bus, device_t child, int type, int rid, * On this platform, isa can also attach to the legacy bus. */ DRIVER_MODULE(isa, legacy, isa_driver, isa_devclass, 0, 0); +#ifdef XENHVM +DRIVER_MODULE(isa, nexus, isa_driver, isa_devclass, 0, 0); +#endif -- 1.7.7.5 (Apple Git-26) ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
[PATCH v7 12/19] xen: add a hook to perform AP startup
AP startup on PVH follows the PV method, so we need to add a hook in
order to diverge from bare metal.
---
sys/amd64/amd64/mp_machdep.c | 16 ---
sys/amd64/include/cpu.h |1 +
sys/x86/xen/hvm.c| 17 +++-
sys/x86/xen/pv.c | 90 ++
sys/xen/pv.h |1 +
5 files changed, 117 insertions(+), 8 deletions(-)
diff --git a/sys/amd64/amd64/mp_machdep.c b/sys/amd64/amd64/mp_machdep.c
index 4ef4b3d..e302886 100644
--- a/sys/amd64/amd64/mp_machdep.c
+++ b/sys/amd64/amd64/mp_machdep.c
@@ -90,7 +90,7 @@ extern struct pcpu __pcpu[];
/* AP uses this during bootstrap. Do not staticize. */
char *bootSTK;
-static int bootAP;
+int bootAP;
/* Free these after use */
void *bootstacks[MAXCPU];
@@ -122,9 +122,12 @@ u_long *ipi_rendezvous_counts[MAXCPU];
static u_long *ipi_hardclock_counts[MAXCPU];
#endif
+int native_start_all_aps(void);
+
/* Default cpu_ops implementation. */
struct cpu_ops cpu_ops = {
- .ipi_vectored = lapic_ipi_vectored
+ .ipi_vectored = lapic_ipi_vectored,
+ .start_all_aps = native_start_all_aps,
};
extern inthand_t IDTVEC(fast_syscall), IDTVEC(fast_syscall32);
@@ -138,7 +141,7 @@ extern int pmap_pcid_enabled;
static volatile cpuset_t ipi_nmi_pending;
/* used to hold the AP's until we are ready to release them */
-static struct mtx ap_boot_mtx;
+struct mtx ap_boot_mtx;
/* Set to 1 once we're ready to let the APs out of the pen. */
static volatile int aps_ready = 0;
@@ -165,7 +168,6 @@ static int cpu_cores; /* cores per
package */
static voidassign_cpu_ids(void);
static voidset_interrupt_apic_ids(void);
-static int start_all_aps(void);
static int start_ap(int apic_id);
static voidrelease_aps(void *dummy);
@@ -569,7 +571,7 @@ cpu_mp_start(void)
assign_cpu_ids();
/* Start each Application Processor */
- start_all_aps();
+ cpu_ops.start_all_aps();
set_interrupt_apic_ids();
}
@@ -908,8 +910,8 @@ assign_cpu_ids(void)
/*
* start each AP in our list
*/
-static int
-start_all_aps(void)
+int
+native_start_all_aps(void)
{
vm_offset_t va = boot_address + KERNBASE;
u_int64_t *pt4, *pt3, *pt2;
diff --git a/sys/amd64/include/cpu.h b/sys/amd64/include/cpu.h
index 3d9ff531..ed9f1db 100644
--- a/sys/amd64/include/cpu.h
+++ b/sys/amd64/include/cpu.h
@@ -64,6 +64,7 @@ struct cpu_ops {
void (*cpu_init)(void);
void (*cpu_resume)(void);
void (*ipi_vectored)(u_int, int);
+ int (*start_all_aps)(void);
};
extern struct cpu_ops cpu_ops;
diff --git a/sys/x86/xen/hvm.c b/sys/x86/xen/hvm.c
index fb1ed79..5ec9f3a 100644
--- a/sys/x86/xen/hvm.c
+++ b/sys/x86/xen/hvm.c
@@ -53,6 +53,9 @@ __FBSDID("$FreeBSD$");
#include
#include
#include
+#ifdef __amd64__
+#include
+#endif
#include
#include
@@ -97,6 +100,11 @@ extern void pmap_lazyfix_action(void);
/* Variables used by mp_machdep to perform the bitmap IPI */
extern volatile u_int cpu_ipi_pending[MAXCPU];
+#ifdef __amd64__
+/* Native AP start used on PVHVM */
+extern int native_start_all_aps(void);
+#endif
+
/*-- Macros
--*/
#defineIPI_TO_IDX(ipi) ((ipi) - APIC_IPI_INTS)
@@ -119,7 +127,10 @@ enum xen_domain_type xen_domain_type = XEN_NATIVE;
struct cpu_ops xen_hvm_cpu_ops = {
.ipi_vectored = lapic_ipi_vectored,
.cpu_init = xen_hvm_cpu_init,
- .cpu_resume = xen_hvm_cpu_resume
+ .cpu_resume = xen_hvm_cpu_resume,
+#ifdef __amd64__
+ .start_all_aps = native_start_all_aps,
+#endif
};
static MALLOC_DEFINE(M_XENHVM, "xen_hvm", "Xen HVM PV Support");
@@ -698,6 +709,10 @@ xen_hvm_init(enum xen_hvm_init_type init_type)
setup_xen_features();
cpu_ops = xen_hvm_cpu_ops;
vm_guest = VM_GUEST_XEN;
+#ifdef __amd64__
+ if (xen_pv_domain())
+ cpu_ops.start_all_aps = xen_pv_start_all_aps;
+#endif
break;
case XEN_HVM_INIT_RESUME:
if (error != 0)
diff --git a/sys/x86/xen/pv.c b/sys/x86/xen/pv.c
index db576e0..7e45a83 100644
--- a/sys/x86/xen/pv.c
+++ b/sys/x86/xen/pv.c
@@ -34,21 +34,43 @@ __FBSDID("$FreeBSD$");
#include
#include
#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
#include
#include
#include
+#include
#include
#include
#include
+#include
+
#define MAX_E820_ENTRIES 128
/*--- Forward Declarations
---*/
static caddr_t xen_pv_parse_preload_data(u_int64_t);
static void xen_pv_parse_memmap(caddr_t, vm_paddr_t *, int *);
+/* Extern Declarations
---*/
+/* Variables used by amd64 mp_machdep to start APs */
+extern struct mtx ap_boot_mtx;
+extern void *bootstacks
[PATCH v7 16/19] xen: add shutdown hook for PVH
Add the PV shutdown hook to PVH.
---
sys/dev/xen/control/control.c | 37 ++---
1 files changed, 18 insertions(+), 19 deletions(-)
diff --git a/sys/dev/xen/control/control.c b/sys/dev/xen/control/control.c
index bc0609d..78894ba 100644
--- a/sys/dev/xen/control/control.c
+++ b/sys/dev/xen/control/control.c
@@ -316,21 +316,6 @@ xctrl_suspend()
EVENTHANDLER_INVOKE(power_resume);
}
-static void
-xen_pv_shutdown_final(void *arg, int howto)
-{
- /*
-* Inform the hypervisor that shutdown is complete.
-* This is not necessary in HVM domains since Xen
-* emulates ACPI in that mode and FreeBSD's ACPI
-* support will request this transition.
-*/
- if (howto & (RB_HALT | RB_POWEROFF))
- HYPERVISOR_shutdown(SHUTDOWN_poweroff);
- else
- HYPERVISOR_shutdown(SHUTDOWN_reboot);
-}
-
#else
/* HVM mode suspension. */
@@ -440,6 +425,21 @@ xctrl_crash()
panic("Xen directed crash");
}
+static void
+xen_pv_shutdown_final(void *arg, int howto)
+{
+ /*
+* Inform the hypervisor that shutdown is complete.
+* This is not necessary in HVM domains since Xen
+* emulates ACPI in that mode and FreeBSD's ACPI
+* support will request this transition.
+*/
+ if (howto & (RB_HALT | RB_POWEROFF))
+ HYPERVISOR_shutdown(SHUTDOWN_poweroff);
+ else
+ HYPERVISOR_shutdown(SHUTDOWN_reboot);
+}
+
/*-- Event Reception
-*/
static void
xctrl_on_watch_event(struct xs_watch *watch, const char **vec, unsigned int
len)
@@ -522,10 +522,9 @@ xctrl_attach(device_t dev)
xctrl->xctrl_watch.callback_data = (uintptr_t)xctrl;
xs_register_watch(&xctrl->xctrl_watch);
-#ifndef XENHVM
- EVENTHANDLER_REGISTER(shutdown_final, xen_pv_shutdown_final, NULL,
- SHUTDOWN_PRI_LAST);
-#endif
+ if (xen_pv_domain())
+ EVENTHANDLER_REGISTER(shutdown_final, xen_pv_shutdown_final,
NULL,
+ SHUTDOWN_PRI_LAST);
return (0);
}
--
1.7.7.5 (Apple Git-26)
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
[PATCH v7 13/19] xen: introduce flag to disable the local apic
PVH guests don't have an emulated lapic.
---
sys/amd64/amd64/mp_machdep.c | 10 ++
sys/amd64/include/apicvar.h |1 +
sys/i386/include/apicvar.h |1 +
sys/i386/xen/xen_machdep.c |2 ++
sys/x86/x86/local_apic.c |8 +---
sys/x86/xen/pv.c |3 +++
6 files changed, 18 insertions(+), 7 deletions(-)
diff --git a/sys/amd64/amd64/mp_machdep.c b/sys/amd64/amd64/mp_machdep.c
index e302886..0296a92 100644
--- a/sys/amd64/amd64/mp_machdep.c
+++ b/sys/amd64/amd64/mp_machdep.c
@@ -709,7 +709,8 @@ init_secondary(void)
wrmsr(MSR_SF_MASK, PSL_NT|PSL_T|PSL_I|PSL_C|PSL_D);
/* Disable local APIC just to be sure. */
- lapic_disable();
+ if (!lapic_disabled)
+ lapic_disable();
/* signal our startup to the BSP. */
mp_naps++;
@@ -735,7 +736,7 @@ init_secondary(void)
/* A quick check from sanity claus */
cpuid = PCPU_GET(cpuid);
- if (PCPU_GET(apic_id) != lapic_id()) {
+ if (!lapic_disabled && (PCPU_GET(apic_id) != lapic_id())) {
printf("SMP: cpuid = %d\n", cpuid);
printf("SMP: actual apic_id = %d\n", lapic_id());
printf("SMP: correct apic_id = %d\n", PCPU_GET(apic_id));
@@ -751,7 +752,8 @@ init_secondary(void)
mtx_lock_spin(&ap_boot_mtx);
/* Init local apic for irq's */
- lapic_setup(1);
+ if (!lapic_disabled)
+ lapic_setup(1);
/* Set memory range attributes for this CPU to match the BSP */
mem_range_AP_init();
@@ -766,7 +768,7 @@ init_secondary(void)
if (cpu_logical > 1 && PCPU_GET(apic_id) % cpu_logical != 0)
CPU_SET(cpuid, &logical_cpus_mask);
- if (bootverbose)
+ if (!lapic_disabled && bootverbose)
lapic_dump("AP");
if (smp_cpus == mp_ncpus) {
diff --git a/sys/amd64/include/apicvar.h b/sys/amd64/include/apicvar.h
index e7423a3..84e01d4 100644
--- a/sys/amd64/include/apicvar.h
+++ b/sys/amd64/include/apicvar.h
@@ -169,6 +169,7 @@ inthand_t
extern vm_paddr_t lapic_paddr;
extern int apic_cpuids[];
+extern bool lapic_disabled;
u_int apic_alloc_vector(u_int apic_id, u_int irq);
u_int apic_alloc_vectors(u_int apic_id, u_int *irqs, u_int count,
diff --git a/sys/i386/include/apicvar.h b/sys/i386/include/apicvar.h
index df99ebe..24c99f0 100644
--- a/sys/i386/include/apicvar.h
+++ b/sys/i386/include/apicvar.h
@@ -168,6 +168,7 @@ inthand_t
extern vm_paddr_t lapic_paddr;
extern int apic_cpuids[];
+extern bool lapic_disabled;
u_int apic_alloc_vector(u_int apic_id, u_int irq);
u_int apic_alloc_vectors(u_int apic_id, u_int *irqs, u_int count,
diff --git a/sys/i386/xen/xen_machdep.c b/sys/i386/xen/xen_machdep.c
index 09c01f1..7039b4a 100644
--- a/sys/i386/xen/xen_machdep.c
+++ b/sys/i386/xen/xen_machdep.c
@@ -59,6 +59,7 @@ __FBSDID("$FreeBSD$");
#include
#include
#include
+#include
@@ -912,6 +913,7 @@ initvalues(start_info_t *startinfo)
#endif
xen_start_info = startinfo;
HYPERVISOR_start_info = startinfo;
+ lapic_disabled = true;
xen_phys_machine = (xen_pfn_t *)startinfo->mfn_list;
IdlePTD = (pd_entry_t *)((uint8_t *)startinfo->pt_base + PAGE_SIZE);
diff --git a/sys/x86/x86/local_apic.c b/sys/x86/x86/local_apic.c
index 41bd602..85736c8 100644
--- a/sys/x86/x86/local_apic.c
+++ b/sys/x86/x86/local_apic.c
@@ -156,6 +156,7 @@ extern inthand_t IDTVEC(rsvd);
volatile lapic_t *lapic;
vm_paddr_t lapic_paddr;
+bool lapic_disabled;
static u_long lapic_timer_divisor;
static struct eventtimer lapic_et;
@@ -1367,9 +1368,10 @@ apic_setup_io(void *dummy __unused)
if (retval != 0)
printf("%s: Failed to setup I/O APICs: returned %d\n",
best_enum->apic_name, retval);
-#ifdef XEN
- return;
-#endif
+
+ if (lapic_disabled)
+ return;
+
/*
* Finish setting up the local APIC on the BSP once we know how to
* properly program the LINT pins.
diff --git a/sys/x86/xen/pv.c b/sys/x86/xen/pv.c
index 7e45a83..e783bb8 100644
--- a/sys/x86/xen/pv.c
+++ b/sys/x86/xen/pv.c
@@ -48,6 +48,7 @@ __FBSDID("$FreeBSD$");
#include
#include
#include
+#include
#include
#include
@@ -230,4 +231,6 @@ xen_pv_set_init_ops(void)
{
/* Init ops for Xen PV */
init_ops = xen_init_ops;
+ /* Disable lapic */
+ lapic_disabled = true;
}
--
1.7.7.5 (Apple Git-26)
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
[PATCH v7 15/19] xen: create a Xen nexus to use in PV/PVH
Introduce a Xen specific nexus that is going to be in charge for
attaching Xen specific devices. Remove the identify routine from Xen
devices and instead attach them from the nexus (PV/PVH) or xenpci
(HVM).
---
sys/conf/files.amd64|1 +
sys/conf/files.i386 |1 +
sys/dev/xen/timer/timer.c | 14 --
sys/dev/xen/xenpci/xenpci.c |5 ++
sys/x86/xen/xen_nexus.c | 99 +++
sys/xen/xenstore/xenstore.c |7 ---
6 files changed, 106 insertions(+), 21 deletions(-)
create mode 100644 sys/x86/xen/xen_nexus.c
diff --git a/sys/conf/files.amd64 b/sys/conf/files.amd64
index 4a3f612..8bb0b5c 100644
--- a/sys/conf/files.amd64
+++ b/sys/conf/files.amd64
@@ -570,3 +570,4 @@ x86/xen/xen_intr.c optionalxen | xenhvm
x86/xen/pv.c optionalxenhvm
x86/xen/mptable.c optionalxenhvm
x86/xen/pvcpu.coptionalxenhvm
+x86/xen/xen_nexus.coptionalxenhvm
diff --git a/sys/conf/files.i386 b/sys/conf/files.i386
index 790296d..751db32 100644
--- a/sys/conf/files.i386
+++ b/sys/conf/files.i386
@@ -603,3 +603,4 @@ x86/x86/tsc.c standard
x86/x86/delay.cstandard
x86/xen/hvm.c optional xenhvm
x86/xen/xen_intr.c optional xen | xenhvm
+x86/xen/xen_nexus.coptional xen | xenhvm
diff --git a/sys/dev/xen/timer/timer.c b/sys/dev/xen/timer/timer.c
index 96372ab..b047786 100644
--- a/sys/dev/xen/timer/timer.c
+++ b/sys/dev/xen/timer/timer.c
@@ -98,19 +98,6 @@ struct xentimer_softc {
/* Last time; this guarantees a monotonically increasing clock. */
volatile uint64_t xen_timer_last_time = 0;
-static void
-xentimer_identify(driver_t *driver, device_t parent)
-{
- if (!xen_domain())
- return;
-
- /* Handle all Xen PV timers in one device instance. */
- if (devclass_get_device(xentimer_devclass, 0))
- return;
-
- BUS_ADD_CHILD(parent, 0, "xen_et", 0);
-}
-
static int
xentimer_probe(device_t dev)
{
@@ -618,7 +605,6 @@ void xen_delay(int n)
}
static device_method_t xentimer_methods[] = {
- DEVMETHOD(device_identify, xentimer_identify),
DEVMETHOD(device_probe, xentimer_probe),
DEVMETHOD(device_attach, xentimer_attach),
DEVMETHOD(device_detach, xentimer_detach),
diff --git a/sys/dev/xen/xenpci/xenpci.c b/sys/dev/xen/xenpci/xenpci.c
index dd2ad92..cac8022 100644
--- a/sys/dev/xen/xenpci/xenpci.c
+++ b/sys/dev/xen/xenpci/xenpci.c
@@ -270,6 +270,11 @@ xenpci_attach(device_t dev)
goto errexit;
}
+ if (BUS_ADD_CHILD(dev, 0, "xenstore", 0) == NULL)
+ panic("xenpci: unable to add xenstore device");
+ if (BUS_ADD_CHILD(nexus, 0, "xen_et", 0) == NULL)
+ panic("xenpci: unable to add xen pv timer device");
+
return (bus_generic_attach(dev));
errexit:
diff --git a/sys/x86/xen/xen_nexus.c b/sys/x86/xen/xen_nexus.c
new file mode 100644
index 000..288e6b6
--- /dev/null
+++ b/sys/x86/xen/xen_nexus.c
@@ -0,0 +1,99 @@
+/*
+ * Copyright (c) 2013 Roger Pau Monné
+ * All rights reserved.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ * 1. Redistributions of source code must retain the above copyright
+ *notice, this list of conditions and the following disclaimer.
+ * 2. Redistributions in binary form must reproduce the above copyright
+ *notice, this list of conditions and the following disclaimer in the
+ *documentation and/or other materials provided with the distribution.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS AS IS'' AND
+ * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+ * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+ * ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
+ * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
+ * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
+ * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
+ * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
+ * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
+ * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
+ * SUCH DAMAGE.
+ */
+
+#include
+__FBSDID("$FreeBSD$");
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+
+#include
+
+static const char *xen_devices[] =
+{
+ "xenstore", /* XenStore bus */
+ "xen_et", /* Xen PV timer (provides: tc, et, clk) */
+ "xc", /* Xen PV console */
+ "isa", /* Dummy ISA bus for sc to attach */
+};
+
+/*
+ * Xen nexus(4) driver.
[PATCH v7 17/19] xen: xenstore changes to support PVH
---
sys/xen/xenstore/xenstore.c | 21 ++---
1 files changed, 10 insertions(+), 11 deletions(-)
diff --git a/sys/xen/xenstore/xenstore.c b/sys/xen/xenstore/xenstore.c
index bcf6357..2893c84 100644
--- a/sys/xen/xenstore/xenstore.c
+++ b/sys/xen/xenstore/xenstore.c
@@ -229,13 +229,11 @@ struct xs_softc {
*/
struct sx xenwatch_mutex;
-#ifdef XENHVM
/**
* The HVM guest pseudo-physical frame number. This is Xen's mapping
* of the true machine frame number into our "physical address space".
*/
unsigned long gpfn;
-#endif
/**
* The event channel for communicating with the
@@ -1141,13 +1139,15 @@ xs_attach(device_t dev)
/* Initialize the interface to xenstore. */
struct proc *p;
-#ifdef XENHVM
- xs.evtchn = hvm_get_parameter(HVM_PARAM_STORE_EVTCHN);
- xs.gpfn = hvm_get_parameter(HVM_PARAM_STORE_PFN);
- xen_store = pmap_mapdev(xs.gpfn * PAGE_SIZE, PAGE_SIZE);
-#else
- xs.evtchn = xen_start_info->store_evtchn;
-#endif
+ if (xen_hvm_domain()) {
+ xs.evtchn = hvm_get_parameter(HVM_PARAM_STORE_EVTCHN);
+ xs.gpfn = hvm_get_parameter(HVM_PARAM_STORE_PFN);
+ xen_store = pmap_mapdev(xs.gpfn * PAGE_SIZE, PAGE_SIZE);
+ } else if (xen_pv_domain()) {
+ xs.evtchn = HYPERVISOR_start_info->store_evtchn;
+ } else {
+ panic("Unknown domain type, cannot initialize xenstore\n");
+ }
TAILQ_INIT(&xs.reply_list);
TAILQ_INIT(&xs.watch_events);
@@ -1256,9 +1256,8 @@ static devclass_t xenstore_devclass;
#ifdef XENHVM
DRIVER_MODULE(xenstore, xenpci, xenstore_driver, xenstore_devclass, 0, 0);
-#else
-DRIVER_MODULE(xenstore, nexus, xenstore_driver, xenstore_devclass, 0, 0);
#endif
+DRIVER_MODULE(xenstore, nexus, xenstore_driver, xenstore_devclass, 0, 0);
/*--- Sysctl Data
*/
/* XXX Shouldn't the node be somewhere else? */
--
1.7.7.5 (Apple Git-26)
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
[PATCH v7 18/19] xen: changes to gnttab for PVH
---
sys/xen/gnttab.c | 26 +-
1 files changed, 21 insertions(+), 5 deletions(-)
diff --git a/sys/xen/gnttab.c b/sys/xen/gnttab.c
index 03c32b7..6949be5 100644
--- a/sys/xen/gnttab.c
+++ b/sys/xen/gnttab.c
@@ -25,6 +25,7 @@ __FBSDID("$FreeBSD$");
#include
#include
#include
+#include
#include
#include
@@ -607,6 +608,7 @@ gnttab_resume(void)
{
int error;
unsigned int max_nr_gframes, nr_gframes;
+ void *alloc_mem;
nr_gframes = nr_grant_frames;
max_nr_gframes = max_nr_grant_frames();
@@ -614,11 +616,25 @@ gnttab_resume(void)
return (ENOSYS);
if (!resume_frames) {
- error = xenpci_alloc_space(PAGE_SIZE * max_nr_gframes,
- &resume_frames);
- if (error) {
- printf("error mapping gnttab share frames\n");
- return (error);
+ if (xen_pv_domain()) {
+ /*
+* This is a waste of physical memory,
+* we should use ballooned pages instead,
+* but it will do for now.
+*/
+ alloc_mem = contigmalloc(max_nr_gframes * PAGE_SIZE,
+M_DEVBUF, M_NOWAIT, 0,
+ULONG_MAX, PAGE_SIZE, 0);
+ KASSERT((alloc_mem != NULL),
+ ("unable to alloc memory for gnttab"));
+ resume_frames = vtophys(alloc_mem);
+ } else {
+ error = xenpci_alloc_space(PAGE_SIZE * max_nr_gframes,
+ &resume_frames);
+ if (error) {
+ printf("error mapping gnttab share frames\n");
+ return (error);
+ }
}
}
--
1.7.7.5 (Apple Git-26)
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
[PATCH v7 14/19] xen: introduce a dummy pvcpu device
Since Xen PVH guests doesn't have ACPI, we need to create a dummy
pvcpu device that will be used to fill the pcpu->pc_device field.
---
sys/conf/files.amd64 |1 +
sys/x86/xen/pvcpu.c | 84 ++
2 files changed, 85 insertions(+), 0 deletions(-)
create mode 100644 sys/x86/xen/pvcpu.c
diff --git a/sys/conf/files.amd64 b/sys/conf/files.amd64
index 3bdc05e..4a3f612 100644
--- a/sys/conf/files.amd64
+++ b/sys/conf/files.amd64
@@ -569,3 +569,4 @@ x86/xen/hvm.c optionalxenhvm
x86/xen/xen_intr.c optionalxen | xenhvm
x86/xen/pv.c optionalxenhvm
x86/xen/mptable.c optionalxenhvm
+x86/xen/pvcpu.coptionalxenhvm
diff --git a/sys/x86/xen/pvcpu.c b/sys/x86/xen/pvcpu.c
new file mode 100644
index 000..8725e76
--- /dev/null
+++ b/sys/x86/xen/pvcpu.c
@@ -0,0 +1,84 @@
+/*
+ * Copyright (c) 2013 Roger Pau Monné
+ * All rights reserved.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ * 1. Redistributions of source code must retain the above copyright
+ *notice, this list of conditions and the following disclaimer.
+ * 2. Redistributions in binary form must reproduce the above copyright
+ *notice, this list of conditions and the following disclaimer in the
+ *documentation and/or other materials provided with the distribution.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS AS IS'' AND
+ * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+ * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+ * ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
+ * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
+ * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
+ * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
+ * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
+ * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
+ * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
+ * SUCH DAMAGE.
+ */
+
+#include
+__FBSDID("$FreeBSD$");
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+
+/*
+ * Dummy Xen cpu device
+ *
+ * Since there's no ACPI on PVH guests, we need to create a dummy
+ * CPU device in order to fill the pcpu->pc_device field.
+ */
+
+static int
+xenpvcpu_probe(device_t dev)
+{
+ if (!xen_pv_domain())
+ return (ENXIO);
+
+ device_set_desc(dev, "Xen PV CPU");
+ return (0);
+}
+
+static int
+xenpvcpu_attach(device_t dev)
+{
+ struct pcpu *pc;
+ int cpu;
+
+ cpu = device_get_unit(dev);
+ pc = pcpu_find(cpu);
+ pc->pc_device = dev;
+ return (0);
+}
+
+static device_method_t xenpvcpu_methods[] = {
+ DEVMETHOD(device_probe, xenpvcpu_probe),
+ DEVMETHOD(device_attach, xenpvcpu_attach),
+ DEVMETHOD_END
+};
+
+static driver_t xenpvcpu_driver = {
+ "pvcpu",
+ xenpvcpu_methods,
+ 0,
+};
+
+devclass_t xenpvcpu_devclass;
+
+DRIVER_MODULE(xenpvcpu, nexus, xenpvcpu_driver, xenpvcpu_devclass, 0, 0);
+MODULE_DEPEND(xenpvcpu, nexus, 1, 1, 1);
--
1.7.7.5 (Apple Git-26)
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
[PATCH v7 11/19] xen: changes to hvm code in order to support PVH guests
On PVH we don't need to init the shared info page, or disable emulated
devices. Also, make sure PV IPIs are set before starting the APs.
---
sys/x86/xen/hvm.c | 17 -
1 files changed, 12 insertions(+), 5 deletions(-)
diff --git a/sys/x86/xen/hvm.c b/sys/x86/xen/hvm.c
index 9a0411e..fb1ed79 100644
--- a/sys/x86/xen/hvm.c
+++ b/sys/x86/xen/hvm.c
@@ -523,7 +523,7 @@ xen_setup_cpus(void)
{
int i;
- if (!xen_hvm_domain() || !xen_vector_callback_enabled)
+ if (!xen_vector_callback_enabled)
return;
#ifdef __amd64__
@@ -712,10 +712,13 @@ xen_hvm_init(enum xen_hvm_init_type init_type)
}
xen_vector_callback_enabled = 0;
- xen_domain_type = XEN_HVM_DOMAIN;
- xen_hvm_init_shared_info_page();
xen_hvm_set_callback(NULL);
- xen_hvm_disable_emulated_devices();
+
+ if (!xen_pv_domain()) {
+ xen_domain_type = XEN_HVM_DOMAIN;
+ xen_hvm_init_shared_info_page();
+ xen_hvm_disable_emulated_devices();
+ }
}
void
@@ -746,6 +749,9 @@ xen_set_vcpu_id(void)
struct pcpu *pc;
int i;
+ if (!xen_hvm_domain())
+ return;
+
/* Set vcpu_id to acpi_id */
CPU_FOREACH(i) {
pc = pcpu_find(i);
@@ -789,7 +795,8 @@ xen_hvm_cpu_init(void)
SYSINIT(xen_hvm_init, SI_SUB_HYPERVISOR, SI_ORDER_FIRST, xen_hvm_sysinit,
NULL);
#ifdef SMP
-SYSINIT(xen_setup_cpus, SI_SUB_SMP, SI_ORDER_FIRST, xen_setup_cpus, NULL);
+/* We need to setup IPIs before APs are started */
+SYSINIT(xen_setup_cpus, SI_SUB_SMP-1, SI_ORDER_FIRST, xen_setup_cpus, NULL);
#endif
SYSINIT(xen_hvm_cpu_init, SI_SUB_INTR, SI_ORDER_FIRST, xen_hvm_cpu_init, NULL);
SYSINIT(xen_set_vcpu_id, SI_SUB_CPU, SI_ORDER_ANY, xen_set_vcpu_id, NULL);
--
1.7.7.5 (Apple Git-26)
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
[PATCH v7 07/19] xen: implement hook to fetch e820 memory map
---
sys/amd64/amd64/machdep.c | 50 ++
sys/amd64/include/pc/bios.h |2 +
sys/amd64/include/sysarch.h |1 +
sys/x86/xen/pv.c| 26 ++
4 files changed, 60 insertions(+), 19 deletions(-)
diff --git a/sys/amd64/amd64/machdep.c b/sys/amd64/amd64/machdep.c
index a2dcb90..6bbfe5a 100644
--- a/sys/amd64/amd64/machdep.c
+++ b/sys/amd64/amd64/machdep.c
@@ -177,11 +177,15 @@ SYSINIT(cpu, SI_SUB_CPU, SI_ORDER_FIRST, cpu_startup,
NULL);
/* Preload data parse function */
static caddr_t native_parse_preload_data(u_int64_t);
+/* Native function to fetch and parse the e820 map */
+static void native_parse_memmap(caddr_t, vm_paddr_t *, int *);
+
/* Default init_ops implementation. */
struct init_ops init_ops = {
.parse_preload_data = native_parse_preload_data,
.early_delay_init = i8254_init,
.early_delay = i8254_delay,
+ .parse_memmap = native_parse_memmap,
};
/*
@@ -1418,21 +1422,12 @@ add_physmap_entry(uint64_t base, uint64_t length,
vm_paddr_t *physmap,
return (1);
}
-static void
-add_smap_entries(struct bios_smap *smapbase, vm_paddr_t *physmap,
-int *physmap_idx)
+void
+bios_add_smap_entries(struct bios_smap *smapbase, u_int32_t smapsize,
+ vm_paddr_t *physmap, int *physmap_idx)
{
struct bios_smap *smap, *smapend;
- u_int32_t smapsize;
- /*
-* Memory map from INT 15:E820.
-*
-* subr_module.c says:
-* "Consumer may safely assume that size value precedes data."
-* ie: an int32_t immediately precedes smap.
-*/
- smapsize = *((u_int32_t *)smapbase - 1);
smapend = (struct bios_smap *)((uintptr_t)smapbase + smapsize);
for (smap = smapbase; smap < smapend; smap++) {
@@ -1449,6 +1444,29 @@ add_smap_entries(struct bios_smap *smapbase, vm_paddr_t
*physmap,
}
}
+static void
+native_parse_memmap(caddr_t kmdp, vm_paddr_t *physmap, int *physmap_idx)
+{
+ struct bios_smap *smap;
+ u_int32_t size;
+
+ /*
+* Memory map from INT 15:E820.
+*
+* subr_module.c says:
+* "Consumer may safely assume that size value precedes data."
+* ie: an int32_t immediately precedes smap.
+*/
+
+ smap = (struct bios_smap *)preload_search_info(kmdp,
+ MODINFO_METADATA | MODINFOMD_SMAP);
+ if (smap == NULL)
+ panic("No BIOS smap info from loader!");
+ size = *((u_int32_t *)smap - 1);
+
+ bios_add_smap_entries(smap, size, physmap, physmap_idx);
+}
+
/*
* Populate the (physmap) array with base/bound pairs describing the
* available physical memory in the system, then test this memory and
@@ -1466,19 +1484,13 @@ getmemsize(caddr_t kmdp, u_int64_t first)
vm_paddr_t pa, physmap[PHYSMAP_SIZE];
u_long physmem_start, physmem_tunable, memtest;
pt_entry_t *pte;
- struct bios_smap *smapbase;
quad_t dcons_addr, dcons_size;
bzero(physmap, sizeof(physmap));
basemem = 0;
physmap_idx = 0;
- smapbase = (struct bios_smap *)preload_search_info(kmdp,
- MODINFO_METADATA | MODINFOMD_SMAP);
- if (smapbase == NULL)
- panic("No BIOS smap info from loader!");
-
- add_smap_entries(smapbase, physmap, &physmap_idx);
+ init_ops.parse_memmap(kmdp, physmap, &physmap_idx);
/*
* Find the 'base memory' segment for SMP
diff --git a/sys/amd64/include/pc/bios.h b/sys/amd64/include/pc/bios.h
index e7d568e..92d4265 100644
--- a/sys/amd64/include/pc/bios.h
+++ b/sys/amd64/include/pc/bios.h
@@ -106,6 +106,8 @@ struct bios_oem {
intbios_oem_strings(struct bios_oem *oem, u_char *buffer, size_t maxlen);
uint32_t bios_sigsearch(uint32_t start, u_char *sig, int siglen, int paralen,
int sigofs);
+void bios_add_smap_entries(struct bios_smap *smapbase, u_int32_t smapsize,
+ vm_paddr_t *physmap, int *physmap_idx);
#endif
#endif /* _MACHINE_PC_BIOS_H_ */
diff --git a/sys/amd64/include/sysarch.h b/sys/amd64/include/sysarch.h
index 60fa635..084223e 100644
--- a/sys/amd64/include/sysarch.h
+++ b/sys/amd64/include/sysarch.h
@@ -15,6 +15,7 @@ struct init_ops {
caddr_t (*parse_preload_data)(u_int64_t);
void(*early_delay_init)(void);
void(*early_delay)(int);
+ void(*parse_memmap)(caddr_t, vm_paddr_t *, int *);
};
extern struct init_ops init_ops;
diff --git a/sys/x86/xen/pv.c b/sys/x86/xen/pv.c
index f8d8cfa..db576e0 100644
--- a/sys/x86/xen/pv.c
+++ b/sys/x86/xen/pv.c
@@ -37,12 +37,17 @@ __FBSDID("$FreeBSD$");
#include
#include
+#include
#include
#include
+#include
+
+#define MAX_E820_ENTRIES 128
/*--- Forward Declarations
---*/
static caddr_t xen_pv_parse_preload_data(u_int64_t);
+static void xen_pv_parse_memmap(cad
[PATCH v7 04/19] amd64: introduce hook for custom preload metadata parsers
---
sys/amd64/amd64/machdep.c | 45 +
sys/amd64/include/sysarch.h | 12 +
sys/conf/files.amd64|1 +
sys/x86/xen/pv.c| 114 +++
sys/xen/pv.h| 28 +++
5 files changed, 189 insertions(+), 11 deletions(-)
create mode 100644 sys/x86/xen/pv.c
create mode 100644 sys/xen/pv.h
diff --git a/sys/amd64/amd64/machdep.c b/sys/amd64/amd64/machdep.c
index 1880f23..09d9a1a 100644
--- a/sys/amd64/amd64/machdep.c
+++ b/sys/amd64/amd64/machdep.c
@@ -126,6 +126,7 @@ __FBSDID("$FreeBSD$");
#include
#include
#include
+#include
#ifdef PERFMON
#include
#endif
@@ -148,6 +149,7 @@ __FBSDID("$FreeBSD$");
#ifdef XENHVM
#include
+#include
#endif
/* Sanity check for __curthread() */
@@ -172,6 +174,14 @@ static int set_fpcontext(struct thread *td, const
mcontext_t *mcp,
char *xfpustate, size_t xfpustate_len);
SYSINIT(cpu, SI_SUB_CPU, SI_ORDER_FIRST, cpu_startup, NULL);
+/* Preload data parse function */
+static caddr_t native_parse_preload_data(u_int64_t);
+
+/* Default init_ops implementation. */
+struct init_ops init_ops = {
+ .parse_preload_data = native_parse_preload_data,
+};
+
/*
* The file "conf/ldscript.amd64" defines the symbol "kernphys". Its value is
* the physical address at which the kernel is loaded.
@@ -1690,6 +1700,26 @@ do_next:
msgbufp = (struct msgbuf *)PHYS_TO_DMAP(phys_avail[pa_indx]);
}
+static caddr_t
+native_parse_preload_data(u_int64_t modulep)
+{
+ caddr_t kmdp;
+
+ preload_metadata = (caddr_t)(uintptr_t)(modulep + KERNBASE);
+ preload_bootstrap_relocate(KERNBASE);
+ kmdp = preload_search_by_type("elf kernel");
+ if (kmdp == NULL)
+ kmdp = preload_search_by_type("elf64 kernel");
+ boothowto = MD_FETCH(kmdp, MODINFOMD_HOWTO, int);
+ kern_envp = MD_FETCH(kmdp, MODINFOMD_ENVP, char *) + KERNBASE;
+#ifdef DDB
+ ksym_start = MD_FETCH(kmdp, MODINFOMD_SSYM, uintptr_t);
+ ksym_end = MD_FETCH(kmdp, MODINFOMD_ESYM, uintptr_t);
+#endif
+
+ return (kmdp);
+}
+
#ifdef XENHVM
/*
* First function called by the Xen PVH boot sequence.
@@ -1754,6 +1784,9 @@ hammer_time_xen(start_info_t *si, u_int64_t xenstack)
}
load_cr3(((u_int64_t)&PT4[0]) - KERNBASE);
+ /* Set the hooks for early functions that diverge from bare metal */
+ xen_pv_set_init_ops();
+
/* Now we can jump into the native init function */
return (hammer_time(0, physfree));
}
@@ -1783,17 +1816,7 @@ hammer_time(u_int64_t modulep, u_int64_t physfree)
*/
proc_linkup0(&proc0, &thread0);
- preload_metadata = (caddr_t)(uintptr_t)(modulep + KERNBASE);
- preload_bootstrap_relocate(KERNBASE);
- kmdp = preload_search_by_type("elf kernel");
- if (kmdp == NULL)
- kmdp = preload_search_by_type("elf64 kernel");
- boothowto = MD_FETCH(kmdp, MODINFOMD_HOWTO, int);
- kern_envp = MD_FETCH(kmdp, MODINFOMD_ENVP, char *) + KERNBASE;
-#ifdef DDB
- ksym_start = MD_FETCH(kmdp, MODINFOMD_SSYM, uintptr_t);
- ksym_end = MD_FETCH(kmdp, MODINFOMD_ESYM, uintptr_t);
-#endif
+ kmdp = init_ops.parse_preload_data(modulep);
/* Init basic tunables, hz etc */
init_param1();
diff --git a/sys/amd64/include/sysarch.h b/sys/amd64/include/sysarch.h
index cd380d4..58ac8cd 100644
--- a/sys/amd64/include/sysarch.h
+++ b/sys/amd64/include/sysarch.h
@@ -4,3 +4,15 @@
/* $FreeBSD$ */
#include
+
+/*
+ * Struct containing pointers to init functions whose
+ * implementation is run time selectable. Selection can be made,
+ * for example, based on detection of a BIOS variant or
+ * hypervisor environment.
+ */
+struct init_ops {
+ caddr_t (*parse_preload_data)(u_int64_t);
+};
+
+extern struct init_ops init_ops;
diff --git a/sys/conf/files.amd64 b/sys/conf/files.amd64
index d1bdcd9..b3b1319 100644
--- a/sys/conf/files.amd64
+++ b/sys/conf/files.amd64
@@ -566,3 +566,4 @@ x86/x86/nexus.c standard
x86/x86/tsc.c standard
x86/xen/hvm.c optionalxenhvm
x86/xen/xen_intr.c optionalxen | xenhvm
+x86/xen/pv.c optionalxenhvm
diff --git a/sys/x86/xen/pv.c b/sys/x86/xen/pv.c
new file mode 100644
index 000..bbaca32
--- /dev/null
+++ b/sys/x86/xen/pv.c
@@ -0,0 +1,114 @@
+/*
+ * Copyright (c) 2004 Christian Limpach.
+ * Copyright (c) 2004-2006,2008 Kip Macy
+ * Copyright (c) 2013 Roger Pau Monné
+ * All rights reserved.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ * 1. Redistributions of source code must retain the above copyright
+ *notice, this list of conditions and the following disclaimer.
+ * 2. Redistributions in binary form must reproduce the above copyright
+ *notice, this list of co
[PATCH v7 03/19] xen: add and enable Xen console for PVH guests
This adds and enables the console used on XEN kernels.
---
sys/amd64/amd64/machdep.c |4 +++
sys/conf/files |4 +-
sys/dev/xen/console/console.c | 45 ++-
sys/dev/xen/console/xencons_ring.c | 15
sys/i386/include/xen/xen-os.h |1 -
sys/i386/xen/xen_machdep.c | 17 -
sys/xen/xen-os.h |4 +++
7 files changed, 48 insertions(+), 42 deletions(-)
diff --git a/sys/amd64/amd64/machdep.c b/sys/amd64/amd64/machdep.c
index a73e33e..1880f23 100644
--- a/sys/amd64/amd64/machdep.c
+++ b/sys/amd64/amd64/machdep.c
@@ -1709,6 +1709,8 @@ hammer_time_xen(start_info_t *si, u_int64_t xenstack)
KASSERT((si != NULL && xenstack != 0),
("invalid start_info or xenstack"));
+ xc_printf("FreeBSD PVH running on %s\n", si->magic);
+
/* We use 3 pages of xen stack for the boot pagetables */
physfree = xenstack + 3 * PAGE_SIZE - KERNBASE;
@@ -1726,6 +1728,8 @@ hammer_time_xen(start_info_t *si, u_int64_t xenstack)
*/
xen_store = (struct xenstore_domain_interface *)
(ptoa(si->store_mfn) + KERNBASE);
+ console_page =
+ (char *)(ptoa(si->console.domU.mfn) + KERNBASE);
xen_domain_type = XEN_PV_DOMAIN;
vm_guest = VM_GUEST_XEN;
diff --git a/sys/conf/files b/sys/conf/files
index a73d31e..f55479d 100644
--- a/sys/conf/files
+++ b/sys/conf/files
@@ -2523,8 +2523,8 @@ dev/xe/if_xe_pccard.c optional xe pccard
dev/xen/balloon/balloon.c optional xen | xenhvm
dev/xen/blkfront/blkfront.coptional xen | xenhvm
dev/xen/blkback/blkback.c optional xen | xenhvm
-dev/xen/console/console.c optional xen
-dev/xen/console/xencons_ring.c optional xen
+dev/xen/console/console.c optional xen | xenhvm
+dev/xen/console/xencons_ring.c optional xen | xenhvm
dev/xen/control/control.c optional xen | xenhvm
dev/xen/netback/netback.c optional xen | xenhvm
dev/xen/netfront/netfront.coptional xen | xenhvm
diff --git a/sys/dev/xen/console/console.c b/sys/dev/xen/console/console.c
index 23eaee2..e8079da 100644
--- a/sys/dev/xen/console/console.c
+++ b/sys/dev/xen/console/console.c
@@ -69,11 +69,14 @@ struct mtx cn_mtx;
static char wbuf[WBUF_SIZE];
static char rbuf[RBUF_SIZE];
static int rc, rp;
-static unsigned int cnsl_evt_reg;
+unsigned int cnsl_evt_reg;
static unsigned int wc, wp; /* write_cons, write_prod */
xen_intr_handle_t xen_intr_handle;
device_t xencons_dev;
+/* Virt address of the shared console page */
+char *console_page;
+
#ifdef KDB
static int xc_altbrk;
#endif
@@ -110,9 +113,28 @@ static struct ttydevsw xc_ttydevsw = {
.tsw_outwakeup = xcoutwakeup,
};
+/*- Debug function
---*/
+#define XC_PRINTF_BUFSIZE 1024
+void
+xc_printf(const char *fmt, ...)
+{
+__va_list ap;
+int retval;
+static char buf[XC_PRINTF_BUFSIZE];
+
+va_start(ap, fmt);
+retval = vsnprintf(buf, XC_PRINTF_BUFSIZE - 1, fmt, ap);
+va_end(ap);
+buf[retval] = 0;
+HYPERVISOR_console_write(buf, retval);
+}
+
static void
xc_cnprobe(struct consdev *cp)
{
+ if (!xen_pv_domain())
+ return;
+
cp->cn_pri = CN_REMOTE;
sprintf(cp->cn_name, "%s0", driver_name);
}
@@ -175,7 +197,7 @@ static void
xc_cnputc(struct consdev *dev, int c)
{
- if (xen_start_info->flags & SIF_INITDOMAIN)
+ if (xen_initial_domain())
xc_cnputc_dom0(dev, c);
else
xc_cnputc_domu(dev, c);
@@ -206,22 +228,12 @@ xcons_putc(int c)
xcons_force_flush();
#endif
}
- if (cnsl_evt_reg)
- __xencons_tx_flush();
+ __xencons_tx_flush();
/* inform start path that we're pretty full */
return ((wp - wc) >= WBUF_SIZE - 100) ? TRUE : FALSE;
}
-static void
-xc_identify(driver_t *driver, device_t parent)
-{
- device_t child;
- child = BUS_ADD_CHILD(parent, 0, driver_name, 0);
- device_set_driver(child, driver);
- device_set_desc(child, "Xen Console");
-}
-
static int
xc_probe(device_t dev)
{
@@ -245,7 +257,7 @@ xc_attach(device_t dev)
cnsl_evt_reg = 1;
callout_reset(&xc_callout, XC_POLLTIME, xc_timeout, xccons);
- if (xen_start_info->flags & SIF_INITDOMAIN) {
+ if (xen_initial_domain()) {
error = xen_intr_bind_virq(dev, VIRQ_CONSOLE, 0, NULL,
xencons_priv_interrupt, NULL,
INTR_TYPE_TTY, &xen_intr_handle);
@@ -309,7 +321,7 @@ __xencons_tx_flush(void)
sz = wp - wc;
if (sz > (WBUF_SIZE - WBUF_MASK(wc)))
sz = WBUF_SIZE - WBUF_MASK(wc);
- if (xen_start_info->flags & SIF_INITDOMAIN)
[PATCH v7 09/19] xen: add a apic_enumerator for PVH
---
sys/conf/files.amd64 |1 +
sys/x86/xen/mptable.c | 136 +
2 files changed, 137 insertions(+), 0 deletions(-)
create mode 100644 sys/x86/xen/mptable.c
diff --git a/sys/conf/files.amd64 b/sys/conf/files.amd64
index bdc1517..3bdc05e 100644
--- a/sys/conf/files.amd64
+++ b/sys/conf/files.amd64
@@ -568,3 +568,4 @@ x86/x86/delay.c standard
x86/xen/hvm.c optionalxenhvm
x86/xen/xen_intr.c optionalxen | xenhvm
x86/xen/pv.c optionalxenhvm
+x86/xen/mptable.c optionalxenhvm
diff --git a/sys/x86/xen/mptable.c b/sys/x86/xen/mptable.c
new file mode 100644
index 000..0384886
--- /dev/null
+++ b/sys/x86/xen/mptable.c
@@ -0,0 +1,136 @@
+/*-
+ * Copyright (c) 2003 John Baldwin
+ * Copyright (c) 2013 Roger Pau Monné
+ * All rights reserved.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ * 1. Redistributions of source code must retain the above copyright
+ *notice, this list of conditions and the following disclaimer.
+ * 2. Redistributions in binary form must reproduce the above copyright
+ *notice, this list of conditions and the following disclaimer in the
+ *documentation and/or other materials provided with the distribution.
+ * 3. Neither the name of the author nor the names of any co-contributors
+ *may be used to endorse or promote products derived from this software
+ *without specific prior written permission.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND
+ * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+ * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+ * ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
+ * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
+ * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
+ * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
+ * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
+ * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
+ * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
+ * SUCH DAMAGE.
+ */
+
+#include
+__FBSDID("$FreeBSD$");
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+
+#include
+#include
+
+#include
+#include
+
+#include
+
+static int xenpv_probe(void);
+static int xenpv_probe_cpus(void);
+static int xenpv_setup_local(void);
+static int xenpv_setup_io(void);
+
+static struct apic_enumerator xenpv_enumerator = {
+ "Xen PV",
+ xenpv_probe,
+ xenpv_probe_cpus,
+ xenpv_setup_local,
+ xenpv_setup_io
+};
+
+/*
+ * This enumerator will only be registered on PVH
+ */
+static int
+xenpv_probe(void)
+{
+ return (-100);
+}
+
+/*
+ * Test each possible vCPU in order to find the number of vCPUs
+ */
+static int
+xenpv_probe_cpus(void)
+{
+#ifdef SMP
+ int i, ret;
+
+ for (i = 0; i < MAXCPU; i++) {
+ ret = HYPERVISOR_vcpu_op(VCPUOP_is_up, i, NULL);
+ if (ret >= 0)
+ cpu_add((i * 2), (i == 0));
+ }
+#endif
+ return (0);
+}
+
+/*
+ * Initialize the vCPU id of the BSP
+ */
+static int
+xenpv_setup_local(void)
+{
+ PCPU_SET(vcpu_id, 0);
+ return (0);
+}
+
+/*
+ * On PVH guests there's no IO APIC
+ */
+static int
+xenpv_setup_io(void)
+{
+ return (0);
+}
+
+static void
+xenpv_register(void *dummy __unused)
+{
+ if (xen_pv_domain()) {
+ apic_register_enumerator(&xenpv_enumerator);
+ }
+}
+SYSINIT(xenpv_register, SI_SUB_TUNABLES - 1, SI_ORDER_FIRST, xenpv_register,
NULL);
+
+/*
+ * Setup per-CPU vCPU IDs
+ */
+static void
+xenpv_set_ids(void *dummy)
+{
+ struct pcpu *pc;
+ int i;
+
+ CPU_FOREACH(i) {
+ pc = pcpu_find(i);
+ pc->pc_vcpu_id = i;
+ }
+}
+SYSINIT(xenpv_set_ids, SI_SUB_CPU, SI_ORDER_MIDDLE, xenpv_set_ids, NULL);
--
1.7.7.5 (Apple Git-26)
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
[PATCH v7 01/19] xen: add PV/PVH kernel entry point
Add the PV/PVH entry point and the low level functions for PVH
initialization.
---
sys/amd64/amd64/locore.S | 53 +++
sys/amd64/amd64/machdep.c| 72 ++
sys/amd64/include/asmacros.h | 26 +++
sys/i386/xen/xen_machdep.c |2 +
sys/x86/xen/hvm.c|1 +
sys/xen/xen-os.h |4 ++
6 files changed, 158 insertions(+), 0 deletions(-)
diff --git a/sys/amd64/amd64/locore.S b/sys/amd64/amd64/locore.S
index 55cda3a..e04cc48 100644
--- a/sys/amd64/amd64/locore.S
+++ b/sys/amd64/amd64/locore.S
@@ -31,6 +31,12 @@
#include
#include
+#ifdef XENHVM
+#include
+#define __ASSEMBLY__
+#include
+#endif
+
#include "assym.s"
/*
@@ -86,3 +92,50 @@ NON_GPROF_ENTRY(btext)
ALIGN_DATA /* just to be sure */
.space 0x1000 /* space for bootstack - temporary
stack */
bootstack:
+
+#ifdef XENHVM
+/* Xen */
+.section __xen_guest
+ ELFNOTE(Xen, XEN_ELFNOTE_GUEST_OS, .asciz, "FreeBSD")
+ ELFNOTE(Xen, XEN_ELFNOTE_GUEST_VERSION, .asciz, "HEAD")
+ ELFNOTE(Xen, XEN_ELFNOTE_XEN_VERSION,.asciz, "xen-3.0")
+ ELFNOTE(Xen, XEN_ELFNOTE_VIRT_BASE, .quad, KERNBASE)
+ ELFNOTE(Xen, XEN_ELFNOTE_PADDR_OFFSET, .quad, KERNBASE) /* Xen
honours elf->p_paddr; compensate for this */
+ ELFNOTE(Xen, XEN_ELFNOTE_ENTRY, .quad, xen_start)
+ ELFNOTE(Xen, XEN_ELFNOTE_HYPERCALL_PAGE, .quad, hypercall_page)
+ ELFNOTE(Xen, XEN_ELFNOTE_HV_START_LOW, .quad, HYPERVISOR_VIRT_START)
+ ELFNOTE(Xen, XEN_ELFNOTE_FEATURES, .asciz,
"writable_descriptor_tables|auto_translated_physmap|supervisor_mode_kernel|hvm_callback_vector")
+ ELFNOTE(Xen, XEN_ELFNOTE_PAE_MODE, .asciz, "yes")
+ ELFNOTE(Xen, XEN_ELFNOTE_L1_MFN_VALID, .long, PG_V, PG_V)
+ ELFNOTE(Xen, XEN_ELFNOTE_LOADER, .asciz, "generic")
+ ELFNOTE(Xen, XEN_ELFNOTE_SUSPEND_CANCEL, .long, 0)
+ ELFNOTE(Xen, XEN_ELFNOTE_BSD_SYMTAB, .asciz, "yes")
+
+ .text
+.p2align PAGE_SHIFT, 0x90 /* Hypercall_page needs to be PAGE aligned */
+
+NON_GPROF_ENTRY(hypercall_page)
+ .skip 0x1000, 0x90/* Fill with "nop"s */
+
+NON_GPROF_ENTRY(xen_start)
+ /* Don't trust what the loader gives for rflags. */
+ pushq $PSL_KERNEL
+ popfq
+
+ /* Parameters for the xen init function */
+ movq%rsi, %rdi /* shared_info (arg 1) */
+ movq%rsp, %rsi /* xenstack(arg 2) */
+
+ /* Use our own stack */
+ movq$bootstack,%rsp
+ xorl%ebp, %ebp
+
+ /* u_int64_t hammer_time_xen(start_info_t *si, u_int64_t xenstack); */
+ callhammer_time_xen
+ movq%rax, %rsp /* set up kstack for mi_startup() */
+ callmi_startup /* autoconfiguration, mountroot etc */
+
+ /* NOTREACHED */
+0: hlt
+ jmp 0b
+#endif
diff --git a/sys/amd64/amd64/machdep.c b/sys/amd64/amd64/machdep.c
index eae657b..a73e33e 100644
--- a/sys/amd64/amd64/machdep.c
+++ b/sys/amd64/amd64/machdep.c
@@ -146,10 +146,17 @@ __FBSDID("$FreeBSD$");
#include
#include
+#ifdef XENHVM
+#include
+#endif
+
/* Sanity check for __curthread() */
CTASSERT(offsetof(struct pcpu, pc_curthread) == 0);
extern u_int64_t hammer_time(u_int64_t, u_int64_t);
+#ifdef XENHVM
+extern u_int64_t hammer_time_xen(start_info_t *, u_int64_t);
+#endif
extern void printcpuinfo(void);/* XXX header file */
extern void identify_cpu(void);
@@ -1683,6 +1690,71 @@ do_next:
msgbufp = (struct msgbuf *)PHYS_TO_DMAP(phys_avail[pa_indx]);
}
+#ifdef XENHVM
+/*
+ * First function called by the Xen PVH boot sequence.
+ *
+ * Set some Xen global variables and prepare the environment so it is
+ * as similar as possible to what native FreeBSD init function expects.
+ */
+u_int64_t
+hammer_time_xen(start_info_t *si, u_int64_t xenstack)
+{
+ u_int64_t physfree;
+ u_int64_t *PT4 = (u_int64_t *)xenstack;
+ u_int64_t *PT3 = (u_int64_t *)(xenstack + PAGE_SIZE);
+ u_int64_t *PT2 = (u_int64_t *)(xenstack + 2 * PAGE_SIZE);
+ int i;
+
+ KASSERT((si != NULL && xenstack != 0),
+ ("invalid start_info or xenstack"));
+
+ /* We use 3 pages of xen stack for the boot pagetables */
+ physfree = xenstack + 3 * PAGE_SIZE - KERNBASE;
+
+ /* Setup Xen global variables */
+ HYPERVISOR_start_info = si;
+ HYPERVISOR_shared_info =
+ (shared_info_t *)(si->shared_info + KERNBASE);
+
+ /*
+* Setup some misc global variables for Xen devices
+*
+* XXX: devices that need this specific variables should
+* be rewritten to fetch this info by themselves from the
+* start_info page.
+*/
+ xen_store = (struct xenstore_domain_interface *)
+ (ptoa(si->store_mfn
[PATCH v7 05/19] xen: rework xen timer so it can be used early in boot process
This should not introduce any functional change, and makes the
functions suitable to be called before we have actually mapped the
vcpu_info struct on a per-cpu basis.
---
sys/dev/xen/timer/timer.c | 29 -
1 files changed, 20 insertions(+), 9 deletions(-)
diff --git a/sys/dev/xen/timer/timer.c b/sys/dev/xen/timer/timer.c
index 354085b..b2f6bcd 100644
--- a/sys/dev/xen/timer/timer.c
+++ b/sys/dev/xen/timer/timer.c
@@ -230,22 +230,22 @@ xen_fetch_vcpu_tinfo(struct vcpu_time_info *dst, struct
vcpu_time_info *src)
/**
* \brief Get the current time, in nanoseconds, since the hypervisor booted.
*
+ * \param vcpu vcpu_info structure to fetch the time from.
+ *
* \note This function returns the current CPU's idea of this value, unless
* it happens to be less than another CPU's previously determined value.
*/
static uint64_t
-xen_fetch_vcpu_time(void)
+xen_fetch_vcpu_time(struct vcpu_info *vcpu)
{
struct vcpu_time_info dst;
struct vcpu_time_info *src;
uint32_t pre_version;
uint64_t now;
volatile uint64_t last;
- struct vcpu_info *vcpu = DPCPU_GET(vcpu_info);
src = &vcpu->time;
- critical_enter();
do {
pre_version = xen_fetch_vcpu_tinfo(&dst, src);
barrier();
@@ -266,16 +266,19 @@ xen_fetch_vcpu_time(void)
}
} while (!atomic_cmpset_64(&xen_timer_last_time, last, now));
- critical_exit();
-
return (now);
}
static uint32_t
xentimer_get_timecount(struct timecounter *tc)
{
+ uint32_t xen_time;
- return ((uint32_t)xen_fetch_vcpu_time() & UINT_MAX);
+ critical_enter();
+ xen_time = (uint32_t)xen_fetch_vcpu_time(DPCPU_GET(vcpu_info)) &
UINT_MAX;
+ critical_exit();
+
+ return (xen_time);
}
/**
@@ -305,7 +308,12 @@ xen_fetch_wallclock(struct timespec *ts)
static void
xen_fetch_uptime(struct timespec *ts)
{
- uint64_t uptime = xen_fetch_vcpu_time();
+ uint64_t uptime;
+
+ critical_enter();
+ uptime = xen_fetch_vcpu_time(DPCPU_GET(vcpu_info));
+ critical_exit();
+
ts->tv_sec = uptime / NSEC_IN_SEC;
ts->tv_nsec = uptime % NSEC_IN_SEC;
}
@@ -354,7 +362,7 @@ xentimer_intr(void *arg)
struct xentimer_softc *sc = (struct xentimer_softc *)arg;
struct xentimer_pcpu_data *pcpu = DPCPU_PTR(xentimer_pcpu);
- pcpu->last_processed = xen_fetch_vcpu_time();
+ pcpu->last_processed = xen_fetch_vcpu_time(DPCPU_GET(vcpu_info));
if (pcpu->timer != 0 && sc->et.et_active)
sc->et.et_event_cb(&sc->et, sc->et.et_arg);
@@ -415,7 +423,10 @@ xentimer_et_start(struct eventtimer *et,
do {
if (++i == 60)
panic("can't schedule timer");
- next_time = xen_fetch_vcpu_time() + first_in_ns;
+ critical_enter();
+ next_time = xen_fetch_vcpu_time(DPCPU_GET(vcpu_info)) +
+ first_in_ns;
+ critical_exit();
error = xentimer_vcpu_start_timer(cpu, next_time);
} while (error == -ETIME);
--
1.7.7.5 (Apple Git-26)
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
[PATCH v7 02/19] xen: add macro to detect if running as Dom0
---
sys/xen/xen-os.h |7 +++
1 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/sys/xen/xen-os.h b/sys/xen/xen-os.h
index c7474d8..e8a5a99 100644
--- a/sys/xen/xen-os.h
+++ b/sys/xen/xen-os.h
@@ -82,6 +82,13 @@ xen_hvm_domain(void)
return (xen_domain_type == XEN_HVM_DOMAIN);
}
+static inline int
+xen_initial_domain(void)
+{
+ return (xen_domain() && HYPERVISOR_start_info &&
+ HYPERVISOR_start_info->flags & SIF_INITDOMAIN);
+}
+
#ifndef xen_mb
#define xen_mb() mb()
#endif
--
1.7.7.5 (Apple Git-26)
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
[PATCH v7 00/19] FreeBSD PVH DomU support
This series is a split of the previous patch "Xen x86 DomU PVH
support", with the aim to make the review of the code easier.
The series can also be found on my git repo:
git://xenbits.xen.org/people/royger/freebsd.git pvh_v7
or
http://xenbits.xen.org/gitweb/?p=people/royger/freebsd.git;a=shortlog;h=refs/heads/pvh_v7
PVH mode is basically a PV guest inside an HVM container, and shares
a great amount of code with PVHVM. The main difference is the way the
guest is started, PVH uses the PV start sequence, jumping directly
into the kernel entry point in long mode and with page tables set.
The main work of this patch consists in setting the environment as
similar as possible to what native FreeBSD expects, and then adding
hooks to the PV ops when necessary.
sys/amd64/amd64/locore.S:
* Add PV entry point, hypervisor_page and the necessary elfnotes.
sys/amd64/amd64/machdep.c:
* Add hooks to replace bare metal operations that should use a PV
helper, this includes:
- Preload metadata
- i8254_init and i8254_delay
- Fetching the e820 memory map
- Reserve of the MP bootstrap region
* Create a DELAY function that uses the PV hooks.
* Introduce a new hammer_time_xen that sets the necessary stuff when
running in PVH mode.
sys/amd64/amd64/mp_machdep.c:
* Introduce a hook to replace start_all_aps.
* Use lapic_disabled variable to prevent polluting the code
with xen specific gates.
sys/amd64/include/asmacros.h:
* Copy the ELFNOTE macro from the i386 Xen PV port.
sys/amd64/include/clock.h:
sys/i386/include/clock.h:
* Prototypes for the xen early delay initialization and usage.
sys/amd64/include/cpu.h:
* Introduce a new cpu hook to init APs.
sys/amd64/include/sysarch.h:
* Declare the init_ops structure.
sys/amd64/include/xen/hypercall.h:
sys/i386/include/xen/hypercall.h
* Switch to the PV style hypercall mechanism for HVM also.
sys/conf/files:
* Make the PV console available on XENHVM also.
sys/conf/files.amd64:
* Include the new files for the PVH port.
sys/dev/xen/console/console.c:
sys/dev/xen/console/xencons_ring.c:
* Remove the identify method and instead add the device from
nexus_xen.
* Use HYPERVISOR_start_info instead of xen_start_info.
* Use HYPERVISOR_event_channel_op to kick the event channel before
xen interrupts are setup.
* Copy the xc_printf debug function from xen_machdep.c
sys/dev/xen/control/control.c:
* Use the PV shutdown on PVH.
sys/dev/xen/timer/timer.c:
* Pass a vcpu_info to xen_fetch_vcpu_time, this allows using this
function at very early init, before per-cpu vcpu_info is set.
* Remove critical_{enter/exit} from xen_fetch_vcpu_time so it can be
used at early boot, instead place them on the callers.
* Introduce two new functions, xen_delay_init and xen_delay that can
be used at early boot to implement the generic DELAY function.
* Remove the identify method that used to add the device, now it is
manually added from either xenpci (HVM) or nexus_xen (PV).
sys/i386/i386/locore.s:
* Reserve space for the hypercall page.
sys/i386/i386/machdep.c:
* Create a generic DELAY function.
sys/i386/xen/xen_machdep.c:
* Set HYPERVISOR_start_info.
* Move and rename xc_printf debug function to xen console.c
sys/x86/isa/clock.c:
* Rename the generic DELAY function to i8254_delay.
sys/x86/x86/delay.c:
* Put generic delay helpers here, get_tsc and delay_tc.
sys/x86/x86/local_apic.c:
* Prevent the local apic from attaching when running on PVH mode.
sys/x86/xen/hvm.c:
* Set the start_all_aps hook.
* Fix the setting of the hypercall page now that we are using the
same mechanism as the PV port.
* Initialize Xen CPU hooks for the PVH port.
* Initialize APs before SI_SUB_SMP (SI_SUB_SMP-1).
sys/x86/xen/mptable.c:
* Create a dummy PV CPU enumerator for the PVH port.
sys/x86/xen/pv.c:
* Implement the PV functions for the early boot hooks,
parse_preload_data and fetch_e820_map.
* Implement the PV function for the start_all_aps hook.
sys/x86/xen/pvcpu.c:
* Dummy Xen PV CPU device, that we use to set the per-cpu pc_device.
sys/xen/gnttab.c:
* Allocate resume_frames for the PVH port.
sys/xen/pv.h:
* Header that exports the specific PV functions.
sys/xen/xen-os.h:
* Declare prototypes for the newly added functions.
* Include new xen_initial_domain function.
sys/xen/xenstore/xenstore.c:
* Make the xenstore driver hang from both xenpci and the nexus when
running XENHVM, this is because we don't have a xenpci device on
the PVH port.
* Remove the identify routine that added the device, instead add it
from either xenpci (HVM) or nexus_xen (PV).
sys/dev/xen/xenpci/xenpci.c:
* Add the xenstore and xen_et devices on succesful attach.
sys/x86/xen/xen_nexus.c:
* Create a specific nexus for Xen PV guests that takes care of adding
the top level Xen PV devices.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubs
Re: SOLVED: Problem with -fno-strict-overflow (was: Re: RFC: (Unconditionally) enable -fno-strict-overflow for kernel builds)
On Thu, Dec 19, 2013 at 10:16:16AM +0100, Stefan Esser wrote: > Am 30.11.2013 14:56, schrieb Konstantin Belousov: > > I propose to unconditionally add the switch -fno-strict-overflow > > to the kernel compilation. See the patch at the end of message for > > exact change proposed. > > > > What does it do. It disallows useless and counter-intuitive > > behaviour of the compiler(s) for the signed overflow. Basically, > > the issue is that the C standard left signed overflow as undefined > > to allow for different hardware implementation of signess to be > > used for signed arithmetic. De-facto, all architectures where > > FreeBSD works or have a chance to be ported, use two-complement > > signed integer representation, and developers intuition is right > > about it. > > > > The compiler authors take the undefined part there as a blanket to > > perform optimizations which are assuming that signed overflow > > cannot happen. The problem with that approach is that typical > > checks for bounds are exactly the place where the overflow can > > happen. Instead of making some artificial example, I would just > > point to my own r258088 and r258397. > > > > What makes the things much worse is that the behaviour is highly > > depended on the optimization level of the exact version of > > compiler. > > > > What other projects did in this regard. They turned the same knob > > unconditionally. I can point at least to Linux kernel and > > Postgresql. Python uses -fwrapv, which is equivalent to the > > -fno-strict-overflow on the two-complement machines. Linux used > > -fwrapv before switched to -fno-strict-overflow. > > Hi Konstantin, > > you may put back -fno-strict-overflow after I found and fixed the > problem uncovered by enabling it in -CURRENT (SVN rev. 259609). > > The problem was an overflow in the conversion of timeout values to > sbintine, which lead to negative values being detected with > -fno-strict-overflow, while the compiler performed the signedness > test before the multiplication, without that option. > > I found that timeout values of more than 1000 years were requested > by some programs, which are now capped at 68 years (the maximum that > can be represented by sbintime, 2^31 seconds). > > So, -fno-strict-overflow has already proved itself to be useful > in uncovering a bug that would have been hard to find, otherwise. Feel free to restore the commit, I have no plans to do this. pgpjaTcm6YfbP.pgp Description: PGP signature
Re: RFC: less chatty system builds
On Thu, Dec 19, 2013 at 09:57:38AM +, David Chisnall wrote: > > On 19 Dec 2013, at 09:40, Luigi Rizzo wrote: ... > >> Oh, and when I do a build of LLVM/Clang on my laptop using Ninja, it takes > >> about 3-5 minutes, whereas when I do it with our build system it takes > >> about 15. When I do it on a 24-core server, it takes less than two > >> minutes with Ninja and with ours it takes about 15 (no speedup over my > >> laptop). I'd therefore suggest that there might be more pressing things > >> that need fixing with our antiquated build infrastructure than the > >> prettiness of the output... > >> > > these are orthogonal issues though, and so radically different in > > complexity that it does not seem a waste of energy to apply > > the patch i suggested while someone comes up with an improved build > > system. > > I disagree. These are the core issues. When the build works, everyone is > happy with the less-verbose output. When it fails, you want the most verbose > output. If a change is reducing the verbosity in the normal case, then > that's fine, but it should not reduce the verbosity in the case of error. > Ninja does this right. > > This is especially important with our build system, which can take several > minutes of doing nothing to get to the point where a build fails. It is a > serious productivity hit to have to wait that long to recompile a single file > and see whether it's fixed. By ensuring that, in the case of failure, we > have enough information in the terminal to reproduce the failing build step, > we can improve this a lot. Respecfully, i think this is a non constructive digression. I never suggested to change the default verbosity, or remove the option to use -s or -v. Surely what you suggest is closer to ideal output, but i am proposing to apply the minuscule patch that I have submitted, whereas your proposal probably requires some massive effort for which nobody seems to have volunteered. So by all means speak up if i am proposing something incorrect or that induces regressions or harms maintainability, but "we could change the entire build system" is not a relevant argument. Regarding Ninja and ways to improve the build system, you make an interesting comment: > If a command exits with a failure condition, then Ninja dumps the exact > command line that was used, along with all of the output, and then stops. > Another side benefit is that Ninja always uses absolute paths for invoking > the commands and for arguments, and so you can always just re-run that single > failing command. our build system currently relies on a ton of environment variables that modify the behaviour of the compiler/command. Putting all the relevant context in a one-liner might be challenging. Maybe we could instead write the environment and command to a temp file whose name is listed in the quiet output, and then run the file itself as the body of the rule ? cheers luigi anyone) a lot of effort compared to the minuscule patch i have posted, and there dp the question is that you (not that you can really re-run the command from the log, because there might be a ton of environment variables that modify > David > > ___ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Strange coredumps with virtualized i386 FreeBSD 10
Gleb, > On Thu, Dec 19, 2013 at 09:51:16AM -0500, Larry Baird wrote: > L> Does anybody else have issues with running i386 FreeBSD 10 under Virtual > Box? > L> I have been running a number of different versions of FreeBSD under Virtual > L> Box for some time without any issues. Last week I installed amd64 FreeBSD > L> 10 rc1 without any issue. Yesterday I decided to try i386 FreeBSD 10 rc1. > > L> Install seemed to go ok. After initial boot I tried to update ports using > L> portsnap. I got a message about corrupted zip file. I initially thought > L> something was wrong with portsnap. Nothing I tried seemed to fix the > issue, > L> so I moved on. I tried to build subversion. I got coredumps from cc and > was > L> unable to build any ports. I decided something must have gone wrong with > the > L> install. I reinstalled and got the same results. I then downloaded and > L> installed i386 FreeBSD 10 rc2. I had the same issues. So I then installed > L> FreeBSD 10 rc1 amd64. No issues, everything seemed to behave as expected. > > L> I then installed FreeBSD 9.2 i386. No issues. I then used subversion and > L> mergemaster to upgrade to FreeBSD 10 stable. After doing upgrade, I once > L> again get coredumps from cc. > L> > L> In case it matters Virtual box is version 4.3.4 running under Windows 7 64 > bit. > L> > L> Anybody else having issues with i386 FreeBSD 10? > > Can you please set > > vfs.unmapped_buf_allowed=0 > > in boot loader and try to reproduce the problem? This seemed to fix the issue. I can now use portsnap and I have successfully compiled serveral ports. Is "unmapped_buf_allowed" a virtualization issue or an i386 issue? Thank you for your help, Larry -- Larry Baird Global Technology Associates, Inc. 1992-2012| http://www.gta.com Celebrating Twenty Years of Software Innovation | Orlando, FL Email: l...@gta.com | TEL 407-380-0220 ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Strange coredumps with virtualized i386 FreeBSD 10
Larry, On Thu, Dec 19, 2013 at 09:51:16AM -0500, Larry Baird wrote: L> Does anybody else have issues with running i386 FreeBSD 10 under Virtual Box? L> I have been running a number of different versions of FreeBSD under Virtual L> Box for some time without any issues. Last week I installed amd64 FreeBSD L> 10 rc1 without any issue. Yesterday I decided to try i386 FreeBSD 10 rc1. L> Install seemed to go ok. After initial boot I tried to update ports using L> portsnap. I got a message about corrupted zip file. I initially thought L> something was wrong with portsnap. Nothing I tried seemed to fix the issue, L> so I moved on. I tried to build subversion. I got coredumps from cc and was L> unable to build any ports. I decided something must have gone wrong with the L> install. I reinstalled and got the same results. I then downloaded and L> installed i386 FreeBSD 10 rc2. I had the same issues. So I then installed L> FreeBSD 10 rc1 amd64. No issues, everything seemed to behave as expected. L> I then installed FreeBSD 9.2 i386. No issues. I then used subversion and L> mergemaster to upgrade to FreeBSD 10 stable. After doing upgrade, I once L> again get coredumps from cc. L> L> In case it matters Virtual box is version 4.3.4 running under Windows 7 64 bit. L> L> Anybody else having issues with i386 FreeBSD 10? Can you please set vfs.unmapped_buf_allowed=0 in boot loader and try to reproduce the problem? -- Totus tuus, Glebius. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Strange coredumps with virtualized i386 FreeBSD 10
Does anybody else have issues with running i386 FreeBSD 10 under Virtual Box? I have been running a number of different versions of FreeBSD under Virtual Box for some time without any issues. Last week I installed amd64 FreeBSD 10 rc1 without any issue. Yesterday I decided to try i386 FreeBSD 10 rc1. Install seemed to go ok. After initial boot I tried to update ports using portsnap. I got a message about corrupted zip file. I initially thought something was wrong with portsnap. Nothing I tried seemed to fix the issue, so I moved on. I tried to build subversion. I got coredumps from cc and was unable to build any ports. I decided something must have gone wrong with the install. I reinstalled and got the same results. I then downloaded and installed i386 FreeBSD 10 rc2. I had the same issues. So I then installed FreeBSD 10 rc1 amd64. No issues, everything seemed to behave as expected. I then installed FreeBSD 9.2 i386. No issues. I then used subversion and mergemaster to upgrade to FreeBSD 10 stable. After doing upgrade, I once again get coredumps from cc. In case it matters Virtual box is version 4.3.4 running under Windows 7 64 bit. Anybody else having issues with i386 FreeBSD 10? -- Larry Baird Global Technology Associates, Inc. 1992-2012| http://www.gta.com Celebrating Twenty Years of Software Innovation | Orlando, FL Email: l...@gta.com | TEL 407-380-0220 ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [HEADS UP] xorg version switch in CURRENT
On 12/17/13 17:28, Aleksandr Rybalko wrote: On 18.12.2013 01:27, Nathan Whitehorn wrote: On 12/17/13 15:32, Aleksandr Rybalko wrote: On Tue, 17 Dec 2013 14:12:05 -0600 Nathan Whitehorn wrote: On 12/17/13 14:07, Steve Kargl wrote: On Mon, Dec 16, 2013 at 12:20:53PM +0100, Niclas Zeising wrote: To get VT switching when using KMS drivers (ATI, Intel) please use newcons: https://wiki.freebsd.org/Newcons or if that is not possible, force the use of the vesa driver for xorg. It appears that newcons is unusable with a static kernel. Adding 'device drm2' and 'device i915kms' to my kernel config results in a quick death to 'make buldkernel'. You may not want it either. The radeon KMS driver, if loaded with newcons before X, replaces your console with snow (or at least it did the last time I tried it). Nathan, on which h/w you did that test? 3 different systems with Intel graphic works fine for me. This is on the following graphics card on amd64: vgapci0@pci0:3:0:0: class=0x03 card=0x10022f43 chip=0x95cc1002 rev=0x00 hdr=0x00 vendor = 'Advanced Micro Devices [AMD] nee ATI' device = 'RV620 [ATI FireGL V3700]' I'll run the test again today or tomorrow and see if it still happens. -Nathan Please do. Thanks! Still gives beautiful snow with r259418. I'll be traveling the next 3 weeks and won't be able to test for that period. -Nathan ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: urtwn driver for Edimax EW-7811U WLAN nano USB Adapter
On Thu, Dec 19, 2013 at 12:33 PM, Thomas Mueller wrote: > Better would be if manufacturers' and online vendors' websites would say what > chipset their Ethernet, Bluetooth adapter, USB wi-fi adapter, etc use. > I think manufacturers don't consider this relevant info, they sell features, not the underlying spec. This allows them to chop and change what chip is actually in a device depending on the vagaries of their supply chain. Eg, Rev A, Rev B might be precisely the same packaging but different chips underneath. Suck for non Windows users, I agree. Cheers Tom ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: urtwn driver for Edimax EW-7811U WLAN nano USB Adapter
> On Thu, Dec 19, 2013 at 09:56:31AM +0800, Kevin Lo wrote: > > Your usb wlan dongles use RTL8188EU chip which is currently not > > supported by any of drivers. > I see; I guess I should not have believed when I was told that most likely > all it would take is id-patch urtwn(4). ;-) > Does anyone know if support is being worked on? Given an increased > popularity of these dongles, perhaps a wiki page would be nice for > those of us who want to get an idea if some particular chip is supported > before buying them (online). > ./danfe Better would be if manufacturers' and online vendors' websites would say what chipset their Ethernet, Bluetooth adapter, USB wi-fi adapter, etc use. That would be useful for any prospective buyer, and would not require familiarity with any specific operating system. But I see this is quite unusual; sometimes, but infrequently, it may be in downloadable PDF. Tom ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: libz.so.6
On Thu, Dec 19, 2013 at 06:37:42AM -0500, Ajtim wrote: > Hello! > > My system: > FreeBSD 10.0-RC2 #0 r259404: Sun Dec 15 08:18:20 UTC 2013 > r...@snap.freebsd.org:/usr/obj/usr/src/sys/GENERIC amd64 > > I have a problem to install last.fm from FreeBSD 10.0-ALPHA: > > /usr/local/bin/ld: ../build/last.fm/release/AbstractBootstrapper.o: undefined > reference to symbol 'gzclose@@ZLIB_1.2.4.0' > //lib/libz.so.6: error adding symbols: DSO missing from command line > collect2: ld returned 1 exit status > *** [../bin/last.fm] Error code 1 > > make[2]: stopped in /usr/ports/audio/last.fm/work/last.fm-1.5.4.26862/src > 1 error > > make[2]: stopped in /usr/ports/audio/last.fm/work/last.fm-1.5.4.26862/src > *** [sub-src-all-ordered] Error code 2 > > make[1]: stopped in /usr/ports/audio/last.fm/work/last.fm-1.5.4.26862 > 1 error > > make[1]: stopped in /usr/ports/audio/last.fm/work/last.fm-1.5.4.26862 > ===> Compilation failed unexpectedly. > Try to set MAKE_JOBS_UNSAFE=yes and rebuild before reporting the failure to > the maintainer. > *** Error code 1 > > Stop. > make: stopped in /usr/ports/audio/last.fm > > ===>>> make failed for audio/last.fm > > > What can I do in this case because as I am informed it is not a "problem" of > maintainer but user. > > Thank you. In means that the build is missing a -lz regards, BApt pgpdpEUQ67lgO.pgp Description: PGP signature
Re: SOLVED: Problem with -fno-strict-overflow (was: Re: RFC: (Unconditionally) enable -fno-strict-overflow for kernel builds)
On 12/19/13, Stefan Esser wrote: > Am 30.11.2013 14:56, schrieb Konstantin Belousov: >> I propose to unconditionally add the switch -fno-strict-overflow >> to the kernel compilation. See the patch at the end of message for >> exact change proposed. >> >> What does it do. It disallows useless and counter-intuitive >> behaviour of the compiler(s) for the signed overflow. Basically, >> the issue is that the C standard left signed overflow as undefined >> to allow for different hardware implementation of signess to be >> used for signed arithmetic. De-facto, all architectures where >> FreeBSD works or have a chance to be ported, use two-complement >> signed integer representation, and developers intuition is right >> about it. >> >> The compiler authors take the undefined part there as a blanket to >> perform optimizations which are assuming that signed overflow >> cannot happen. The problem with that approach is that typical >> checks for bounds are exactly the place where the overflow can >> happen. Instead of making some artificial example, I would just >> point to my own r258088 and r258397. >> >> What makes the things much worse is that the behaviour is highly >> depended on the optimization level of the exact version of >> compiler. >> >> What other projects did in this regard. They turned the same knob >> unconditionally. I can point at least to Linux kernel and >> Postgresql. Python uses -fwrapv, which is equivalent to the >> -fno-strict-overflow on the two-complement machines. Linux used >> -fwrapv before switched to -fno-strict-overflow. > > Hi Konstantin, > > you may put back -fno-strict-overflow after I found and fixed the > problem uncovered by enabling it in -CURRENT (SVN rev. 259609). > > The problem was an overflow in the conversion of timeout values to > sbintine, which lead to negative values being detected with > -fno-strict-overflow, while the compiler performed the signedness > test before the multiplication, without that option. > > I found that timeout values of more than 1000 years were requested > by some programs, which are now capped at 68 years (the maximum that > can be represented by sbintime, 2^31 seconds). > > So, -fno-strict-overflow has already proved itself to be useful > in uncovering a bug that would have been hard to find, otherwise. > I have a plan, to port this or like this plugin to llvm/clang in the near future: http://www.grsecurity.net/~ephox/overflow_plugin/ > Regards, STefan > ___ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" > ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
libz.so.6
Hello! My system: FreeBSD 10.0-RC2 #0 r259404: Sun Dec 15 08:18:20 UTC 2013 r...@snap.freebsd.org:/usr/obj/usr/src/sys/GENERIC amd64 I have a problem to install last.fm from FreeBSD 10.0-ALPHA: /usr/local/bin/ld: ../build/last.fm/release/AbstractBootstrapper.o: undefined reference to symbol 'gzclose@@ZLIB_1.2.4.0' //lib/libz.so.6: error adding symbols: DSO missing from command line collect2: ld returned 1 exit status *** [../bin/last.fm] Error code 1 make[2]: stopped in /usr/ports/audio/last.fm/work/last.fm-1.5.4.26862/src 1 error make[2]: stopped in /usr/ports/audio/last.fm/work/last.fm-1.5.4.26862/src *** [sub-src-all-ordered] Error code 2 make[1]: stopped in /usr/ports/audio/last.fm/work/last.fm-1.5.4.26862 1 error make[1]: stopped in /usr/ports/audio/last.fm/work/last.fm-1.5.4.26862 ===> Compilation failed unexpectedly. Try to set MAKE_JOBS_UNSAFE=yes and rebuild before reporting the failure to the maintainer. *** Error code 1 Stop. make: stopped in /usr/ports/audio/last.fm ===>>> make failed for audio/last.fm What can I do in this case because as I am informed it is not a "problem" of maintainer but user. Thank you. -- Mitja --- http://www.redbubble.com/people/lumiwa ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: svn && ports, or the hen && egg
I had (still have) svn on a USB-stick installation of FreeBSD 9.2-STABLE. So I tried to use that to checkout the src tree for FreeBSD-HEAD; re(4) recognized my on-motherboard (MSI Z77 MPOWER) Ethernet but couldn't connect. So, after NetBSD 6.1_STABLE hung consistently on boot, NetBSD-current amd64 booted and connected the Ethernet through NetBSD's re(4). So I checked out (cvs) NetBSD src and pkgsrc trees, updated system and packages, subsequently built subversion from pkgsrc. Then I checked out FreeBSD src tree successfully, and was successful building the new FreeBSD from the USB-stick installation of 9.2-STABLE amd64, and I use that for src, doc and ports trees until I can build devel/subversion in FreeBSD, am having some troubles there, can try again without tests and tools options to see if I was overambitious in selecting build options. Now I have wi-fi working through Hiro H50191 USB-stick adapter, device rsu. Tom ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: RFC: less chatty system builds
On 19 Dec 2013, at 09:40, Luigi Rizzo wrote: > >> If a command produces warning output but exits with success, then that >> command's output is dumped to stdout (explicitly serialised by Ninja so that >> it's never interleaved with another command's output). >> >> If a command exits with a failure condition, then Ninja dumps the exact >> command line that was used, along with all of the output, and then stops. >> Another side benefit is that Ninja always uses absolute paths for invoking >> the commands and for arguments, and so you can always just re-run that >> single failing command. >> >> Oh, and when I do a build of LLVM/Clang on my laptop using Ninja, it takes >> about 3-5 minutes, whereas when I do it with our build system it takes about >> 15. When I do it on a 24-core server, it takes less than two minutes with >> Ninja and with ours it takes about 15 (no speedup over my laptop). I'd >> therefore suggest that there might be more pressing things that need fixing >> with our antiquated build infrastructure than the prettiness of the output... >> > these are orthogonal issues though, and so radically different in > complexity that it does not seem a waste of energy to apply > the patch i suggested while someone comes up with an improved build > system. I disagree. These are the core issues. When the build works, everyone is happy with the less-verbose output. When it fails, you want the most verbose output. If a change is reducing the verbosity in the normal case, then that's fine, but it should not reduce the verbosity in the case of error. Ninja does this right. This is especially important with our build system, which can take several minutes of doing nothing to get to the point where a build fails. It is a serious productivity hit to have to wait that long to recompile a single file and see whether it's fixed. By ensuring that, in the case of failure, we have enough information in the terminal to reproduce the failing build step, we can improve this a lot. David ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: urtwn driver for Edimax EW-7811U WLAN nano USB Adapter
On Thu, Dec 19, 2013 at 09:56:31AM +0800, Kevin Lo wrote: > Your usb wlan dongles use RTL8188EU chip which is currently not > supported by any of drivers. I see; I guess I should not have believed when I was told that most likely all it would take is id-patch urtwn(4). ;-) Does anyone know if support is being worked on? Given an increased popularity of these dongles, perhaps a wiki page would be nice for those of us who want to get an idea if some particular chip is supported before buying them (online). ./danfe ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: RFC: less chatty system builds
On Thu, Dec 19, 2013 at 1:18 AM, David Chisnall wrote: > On 16 Dec 2013, at 21:35, Dimitry Andric wrote: > > > In any case, if anything like this is implemented, I would really prefer > > something like CMake does, e.g. give you a percentage counter that > > provides some information about how 'far' the build is progressing. > > I haven't seen this for a while, because I now use ninja exclusively for > building any projects that use CMake. The output of Ninja is pretty close > to my ideal for a build system, and so I'd recommend that anyone hacking on > this look at it. It looks something like this while building: > > $ ninja > [1/22] Building CXX object > lib/Target/Mips/AsmParser/CMakeFiles/LLVMMipsAsmParser.dir/MipsAsmParser.cpp.o > > The [1/22] part is a counter of the number of build steps done and updates > in place. The 'Building CXX object ...' part tells you what the current > rule is and what it's being applied to. This is only approximate, as it > usually does parallel builds, but it gives you some idea of what's > happening. > > the "Building CXX ... " is basically the same type of output that I was proposing. I am still unclear on how one can implement useful counters (see my other email) since the times of "build step" vary by 2-3 orders of magnitude. Anyways, maybe just counting the number of targets in the first 2-3 levels of the tree can give an idea. If a command produces warning output but exits with success, then that > command's output is dumped to stdout (explicitly serialised by Ninja so > that it's never interleaved with another command's output). > > If a command exits with a failure condition, then Ninja dumps the exact > command line that was used, along with all of the output, and then stops. > Another side benefit is that Ninja always uses absolute paths for invoking > the commands and for arguments, and so you can always just re-run that > single failing command. > > Oh, and when I do a build of LLVM/Clang on my laptop using Ninja, it takes > about 3-5 minutes, whereas when I do it with our build system it takes > about 15. When I do it on a 24-core server, it takes less than two minutes > with Ninja and with ours it takes about 15 (no speedup over my laptop). > I'd therefore suggest that there might be more pressing things that need > fixing with our antiquated build infrastructure than the prettiness of the > output... > these are orthogonal issues though, and so radically different in complexity that it does not seem a waste of energy to apply the patch i suggested while someone comes up with an improved build system. cheers luigi ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: RFC: less chatty system builds
On 16 Dec 2013, at 21:35, Dimitry Andric wrote: > In any case, if anything like this is implemented, I would really prefer > something like CMake does, e.g. give you a percentage counter that > provides some information about how 'far' the build is progressing. I haven't seen this for a while, because I now use ninja exclusively for building any projects that use CMake. The output of Ninja is pretty close to my ideal for a build system, and so I'd recommend that anyone hacking on this look at it. It looks something like this while building: $ ninja [1/22] Building CXX object lib/Target/Mips/AsmParser/CMakeFiles/LLVMMipsAsmParser.dir/MipsAsmParser.cpp.o The [1/22] part is a counter of the number of build steps done and updates in place. The 'Building CXX object ...' part tells you what the current rule is and what it's being applied to. This is only approximate, as it usually does parallel builds, but it gives you some idea of what's happening. If a command produces warning output but exits with success, then that command's output is dumped to stdout (explicitly serialised by Ninja so that it's never interleaved with another command's output). If a command exits with a failure condition, then Ninja dumps the exact command line that was used, along with all of the output, and then stops. Another side benefit is that Ninja always uses absolute paths for invoking the commands and for arguments, and so you can always just re-run that single failing command. Oh, and when I do a build of LLVM/Clang on my laptop using Ninja, it takes about 3-5 minutes, whereas when I do it with our build system it takes about 15. When I do it on a 24-core server, it takes less than two minutes with Ninja and with ours it takes about 15 (no speedup over my laptop). I'd therefore suggest that there might be more pressing things that need fixing with our antiquated build infrastructure than the prettiness of the output... David ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
SOLVED: Problem with -fno-strict-overflow (was: Re: RFC: (Unconditionally) enable -fno-strict-overflow for kernel builds)
Am 30.11.2013 14:56, schrieb Konstantin Belousov: > I propose to unconditionally add the switch -fno-strict-overflow > to the kernel compilation. See the patch at the end of message for > exact change proposed. > > What does it do. It disallows useless and counter-intuitive > behaviour of the compiler(s) for the signed overflow. Basically, > the issue is that the C standard left signed overflow as undefined > to allow for different hardware implementation of signess to be > used for signed arithmetic. De-facto, all architectures where > FreeBSD works or have a chance to be ported, use two-complement > signed integer representation, and developers intuition is right > about it. > > The compiler authors take the undefined part there as a blanket to > perform optimizations which are assuming that signed overflow > cannot happen. The problem with that approach is that typical > checks for bounds are exactly the place where the overflow can > happen. Instead of making some artificial example, I would just > point to my own r258088 and r258397. > > What makes the things much worse is that the behaviour is highly > depended on the optimization level of the exact version of > compiler. > > What other projects did in this regard. They turned the same knob > unconditionally. I can point at least to Linux kernel and > Postgresql. Python uses -fwrapv, which is equivalent to the > -fno-strict-overflow on the two-complement machines. Linux used > -fwrapv before switched to -fno-strict-overflow. Hi Konstantin, you may put back -fno-strict-overflow after I found and fixed the problem uncovered by enabling it in -CURRENT (SVN rev. 259609). The problem was an overflow in the conversion of timeout values to sbintine, which lead to negative values being detected with -fno-strict-overflow, while the compiler performed the signedness test before the multiplication, without that option. I found that timeout values of more than 1000 years were requested by some programs, which are now capped at 68 years (the maximum that can be represented by sbintime, 2^31 seconds). So, -fno-strict-overflow has already proved itself to be useful in uncovering a bug that would have been hard to find, otherwise. Regards, STefan ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: svn && ports, or the hen && egg
On 19/12/2013 08:04, Freddie Cash wrote: > On Wed, Dec 18, 2013 at 1:09 PM, Matthias Apitz wrote: >> Ok, thanks; but see this: >> >> $ uname -a >> FreeBSD tiny-r255948 10.0-ALPHA4 FreeBSD 10.0-ALPHA4 #1: Fri Oct 18 >> 12:10:57 CEST 2013 g...@aurora.sisis.de:/usr/obj/usr/src/sys/GENERIC/i386 >> $ svnlite >> Type 'svn help' for usage. >> $ svn help >> svn: not found >> > > ​And ... if you type "svnlite help" what happens? The name of the command > is svnlite, not svn, so you may have to mentally swap the terms in terminal > messages. :)​ > > That would work once you know you need to use svnlite. Most people will try svn and after that fails look for a way to install it, rather than looking for a renamed substitute. Maybe a /bin/svn script could test if svn exists and exec it or svnlite or display a message that svnlite is available until svn is installed. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: ral(4) panic. head, r257837
On Wed, 18 Dec 2013 23:40:23 -0800
Adrian Chadd wrote:
> What's at frame 10?
>
> And list the IP, ie:
>
> list *0x817da911
>
(kgdb) f 10
#10 0x817da911 in rt2860_tx (sc=0xfe9bd000,
m=0xf80004c6dd00, ni=0x0)
at /usr/src/sys/modules/ral/../../dev/ral/rt2860.c:1472 1472{
Current language: auto; currently minimal
(kgdb) list *0x817da911
0x817da911 is in rt2860_tx
(/usr/src/sys/modules/ral/../../dev/ral/rt2860.c:1475). 1470static
int 1471rt2860_tx(struct rt2860_softc *sc, struct mbuf *m, struct
ieee80211_node *ni) 1472{
1473struct ifnet *ifp = sc->sc_ifp;
1474struct ieee80211com *ic = ifp->if_l2com;
1475struct ieee80211vap *vap = ni->ni_vap;
1476struct rt2860_tx_ring *ring;
1477struct rt2860_tx_data *data;
1478struct rt2860_txd *txd;
1479struct rt2860_txwi *txwi;
> -a
>
> On 18 December 2013 23:04, Sergey V. Dyatko
> wrote:
> > Hi,
> >
> > I have following setup:
> >
> > wlans_ral0="wlan0"
> > ifconfig_wlan0="WPA"
> >
> > cloned_interfaces="lagg0 bridge0 tap0"
> > ifconfig_lagg0="laggproto failover laggport alc0 laggport wlan0
> > DHCP" ifconfig_bridge0="addm tap0 addm lagg0"
> >
> > When system boot I have reproducible panic after messages
> > Waiting 30s for the default route interface: .
> > ral0: need multicast update callback
> > ral0: need multicast update callback
> > :
> >
> > Fatal trap 12: page fault while in kernel mode
> > cpuid = 0; apic id = 00
> > fault virtual address = 0x0
> > fault code = supervisor read data, page not present
> > instruction pointer = 0x20:0x817da911
> > stack pointer = 0x28:0xfe011fe61da0
> > frame pointer = 0x28:0xfe011fe62630
> > <118>.
> > code segment= base 0x0, limit 0xf, type 0x1b
> > = DPL 0, pres 1, long 1, def32 0, gran 1
> > processor eflags= interrupt enabled, resume, IOPL = 0
> > current process = 1815 (dhclient)
> >
> > Reading symbols from /boot/kernel/zfs.ko.symbols...done.
> > Loaded symbols for /boot/kernel/zfs.ko.symbols
> > Reading symbols from /boot/kernel/opensolaris.ko.symbols...done.
> > Loaded symbols for /boot/kernel/opensolaris.ko.symbols
> > Reading symbols from /boot/kernel/linux.ko.symbols...done.
> > Loaded symbols for /boot/kernel/linux.ko.symbols
> > Reading symbols from /boot/kernel/if_alc.ko.symbols...done.
> > Loaded symbols for /boot/kernel/if_alc.ko.symbols
> > Reading symbols from /boot/kernel/if_ral.ko.symbols...done.
> > Loaded symbols for /boot/kernel/if_ral.ko.symbols
> > Reading symbols from /boot/kernel/snd_hda.ko.symbols...done.
> > Loaded symbols for /boot/kernel/snd_hda.ko.symbols
> > Reading symbols from /boot/kernel/sound.ko.symbols...done.
> > Loaded symbols for /boot/kernel/sound.ko.symbols
> > Reading symbols from /boot/kernel/acpi_video.ko.symbols...done.
> > Loaded symbols for /boot/kernel/acpi_video.ko.symbols
> > Reading symbols from /boot/modules/nvidia.ko...done.
> > Loaded symbols for /boot/modules/nvidia.ko
> > Reading symbols from /boot/modules/cuse4bsd.ko...done.
> > Loaded symbols for /boot/modules/cuse4bsd.ko
> > Reading symbols from /boot/kernel/sem.ko.symbols...done.
> > Loaded symbols for /boot/kernel/sem.ko.symbols
> > Reading symbols from /boot/kernel/linprocfs.ko.symbols...done.
> > Loaded symbols for /boot/kernel/linprocfs.ko.symbols
> > Reading symbols from /boot/kernel/if_lagg.ko.symbols...done.
> > Loaded symbols for /boot/kernel/if_lagg.ko.symbols
> > Reading symbols from /boot/kernel/if_bridge.ko.symbols...done.
> > Loaded symbols for /boot/kernel/if_bridge.ko.symbols
> > Reading symbols from /boot/kernel/bridgestp.ko.symbols...done.
> > Loaded symbols for /boot/kernel/bridgestp.ko.symbols
> > Reading symbols from /boot/kernel/if_tap.ko.symbols...done.
> > Loaded symbols for /boot/kernel/if_tap.ko.symbols
> >
> > #0 doadump (textdump=0) at pcpu.h:219
> > 219 pcpu.h: No such file or directory.
> > in pcpu.h
> > (kgdb) #0 doadump (textdump=0) at pcpu.h:219
> > #1 0x803023ae in db_dump (dummy=,
> > dummy2=0, dummy3=0, dummy4=0x0) at /usr/src/sys/ddb/db_command.c:543
> > #2 0x80301e8d in db_command (cmd_table= > out>) at /usr/src/sys/ddb/db_command.c:449
> > #3 0x80301c04 in db_command_loop ()
> > at /usr/src/sys/ddb/db_command.c:502
> > #4 0x80304570 in db_trap (type=,
> > code=0) at /usr/src/sys/ddb/db_main.c:231
> > #5 0x8072e9d3 in kdb_trap (type=12, code=0, tf= > optimized out>) at /usr/src/sys/kern/subr_kdb.c:656
> > #6 0x80a81bb2 in trap_fatal (frame=0xfe011fe61cf0,
> > eva=)
> > at /usr/src/sys/amd64/amd64/trap.c:870 #7 0x80a81ec9 in
> > trap_pfault (frame=0xfe011fe61cf0, usermode=0)
> > at /usr/src/sys/amd64/amd64/trap.c:692 #8 0x80a8165b in
> > trap (frame=0xfe011fe61cf0)
> > at /usr/src/sys/amd64/amd64/trap.c:456 #9 0
