From owner-freebsd-current@FreeBSD.ORG Sun Jul 17 01:22:03 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 10E9D106566C for ; Sun, 17 Jul 2011 01:22:03 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id D7F148FC0A for ; Sun, 17 Jul 2011 01:22:02 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 7031A46B29; Sat, 16 Jul 2011 21:22:02 -0400 (EDT) Received: from kavik.baldwin.cx (c-68-36-150-83.hsd1.nj.comcast.net [68.36.150.83]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id EFAB68A02E; Sat, 16 Jul 2011 21:22:01 -0400 (EDT) From: John Baldwin To: freebsd-current@freebsd.org, Ed Schouten Date: Sat, 16 Jul 2011 21:22:00 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-RELEASE-p2; KDE/4.5.5; i386; ; ) References: <200909191756.n8JHuQCq031719@svn.freebsd.org> <20090925123911.GP95398@hoeg.nl> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201107162122.00466.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Sat, 16 Jul 2011 21:22:02 -0400 (EDT) Cc: Kostik Belousov , Anonymous , Ben Kaduk Subject: Re: [Patch] [regression] libvgl and r197330 (kbd) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Jul 2011 01:22:03 -0000 On Friday, June 17, 2011 08:18:03 pm Ben Kaduk wrote: > On Fri, Sep 25, 2009 at 8:39 AM, Ed Schouten wrote: > > Hi all, > > > > * Kostik Belousov wrote: > >> > Ah, it seems SDL also calls GIO_KEYMAP. Just rebuilding SDL should fix > >> > this. I promised to add a message to UPDATING as well, so I'll also > >> > mention SDL should be rebuilt as well. > >> > >> I consider this as a very strong argument to keep the existing ioctl > >> as is, and provide new ioctl that takes new table. > > > > I've attached a patch that should restore binary compatibility. I first > > thought this wasn't really needed, because most applications would use > > K_RAW instead of K_XLATE anyway. > > > > Just breaking binary compatibility with kbdcontrol(1) wouldn't have been > > too bad, but it turns out things like SDL use this as well. I've > > attached a patch that should restore binary compatibility. Anyone > > interested in testing this before I commit it to SVN? > > Replying to ancient history, it looks like this patch never got > committed? The Debian kFreeBSD folks have run into a similar issue: > http://lists.debian.org/debian-bsd/2011/06/msg00238.html > proposing > =============== > Upstream could do it properly, without ABI breaking, i.e. by > > #define GIO_KEYMAP_OLD _IOR('k', 6, keymap_t) > #define PIO_KEYMAP_OLD _IOW('k', 7, keymap_t) > ... > #define GIO_KEYMAP _IO('k', 16) > #define PIO_KEYMAP _IO('k', 17) > =============== > > Something to keep the ABI between 8 and 9 is probably still useful, > even at this juncture. I just asked the kFreeBSD folks to test Ed's patch and it does restore the ABI. Ed, can you commit this patch as it's been successfully tested now? -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Sun Jul 17 02:02:41 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7D74F1065670; Sun, 17 Jul 2011 02:02:41 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-gy0-f182.google.com (mail-gy0-f182.google.com [209.85.160.182]) by mx1.freebsd.org (Postfix) with ESMTP id 0E38E8FC14; Sun, 17 Jul 2011 02:02:40 +0000 (UTC) Received: by gyf3 with SMTP id 3so1170001gyf.13 for ; Sat, 16 Jul 2011 19:02:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=SXA/cc5lNu08550RxoTMbiHvpikPuz8gqkLx04a46N8=; b=K7oL2wZmlB3nlKATvwbSprLQSB4Vw9rEb8LIrkqxWowr5zgL6JXLrNbkU4kpXRRnnp 6IpUsulY9mjOwb2bDH6qteCHSgRmfUiyDrTurnDW4XYhrVnf8/TST263dhKmjGhIrMCU pCLCYirtyYjSXtaFvUkOxwDK3Y14lFs1waDMI= MIME-Version: 1.0 Received: by 10.150.74.3 with SMTP id w3mr4529317yba.329.1310868158670; Sat, 16 Jul 2011 19:02:38 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.150.197.5 with HTTP; Sat, 16 Jul 2011 19:02:38 -0700 (PDT) In-Reply-To: References: <4E20FADE.6060103@missouri.edu> <4E21B051.5040502@missouri.edu> <4E21B6A0.6060908@missouri.edu> Date: Sun, 17 Jul 2011 10:02:38 +0800 X-Google-Sender-Auth: uMlc_Xe0tNdu-2ukcTZX1fuvvFg Message-ID: From: Adrian Chadd To: Chris Rees Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "freebsd@sopwith.solgatos.com" , Stephen Montgomery-Smith , "current@freebsd.org" , "bug-followup@freebsd.org" , Stefan Bethke Subject: Re: ports/158179: some packages do not fully honor -P dir option in pkg_add(1) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Jul 2011 02:02:41 -0000 Unless say, you're doing package installation outside of a chroot/jail, to populate something inside a chroot/jail before you start said chroot/jail. Adrian On 17 July 2011 00:13, Chris Rees wrote: > On 16 Jul 2011 17:04, "Stephen Montgomery-Smith" > wrote: >> >> On 07/16/2011 10:53 AM, Chris Rees wrote: >>> >>> >>> On 16 Jul 2011 16:38, "Stephen Montgomery-Smith" >> > wrote: >>> =A0> For example, suppose the C source code contains something like: >>> =A0> char applications_dir =3D "/usr/local/share/applications"; >>> =A0> and this is filled in by the ./configure script. >>> =A0> >>> =A0> How is that handled? >>> =A0> >>> >>> It's not. >>> >>> Remember what a package is, literally the files from the plist tarred >>> with some magic +FILEs and the pkg-*install files- if paths are >>> hardcoded in objects that's how it'll be installed. >> >> >> What if some of the installation programs are binaries, and "/usr/local" > is hard coded into installation binaries or scripts provided by the softw= are > itself. > > Sorry, poor wording on my part. > > If it was compiled as prefix=3D/usr/local, that's how it'll be installed, > regardless of your -p argument. > > Chris > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org= " > From owner-freebsd-current@FreeBSD.ORG Sun Jul 17 02:05:17 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 423A8106566B; Sun, 17 Jul 2011 02:05:17 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 0E6828FC17; Sun, 17 Jul 2011 02:05:16 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.4) with ESMTP id p6H25GTA030248; Sat, 16 Jul 2011 22:05:16 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.4/Submit) id p6H25F7J030225; Sun, 17 Jul 2011 02:05:15 GMT (envelope-from tinderbox@freebsd.org) Date: Sun, 17 Jul 2011 02:05:15 GMT Message-Id: <201107170205.p6H25F7J030225@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on i386/i386 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Jul 2011 02:05:17 -0000 TB --- 2011-07-16 23:00:00 - tinderbox 2.7 running on freebsd-current.sentex.ca TB --- 2011-07-16 23:00:00 - starting HEAD tinderbox run for i386/i386 TB --- 2011-07-16 23:00:00 - cleaning the object tree TB --- 2011-07-16 23:00:42 - cvsupping the source tree TB --- 2011-07-16 23:00:42 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/i386/i386/supfile TB --- 2011-07-16 23:00:56 - building world TB --- 2011-07-16 23:00:56 - MAKEOBJDIRPREFIX=/obj TB --- 2011-07-16 23:00:56 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-07-16 23:00:56 - TARGET=i386 TB --- 2011-07-16 23:00:56 - TARGET_ARCH=i386 TB --- 2011-07-16 23:00:56 - TZ=UTC TB --- 2011-07-16 23:00:56 - __MAKE_CONF=/dev/null TB --- 2011-07-16 23:00:56 - cd /src TB --- 2011-07-16 23:00:56 - /usr/bin/make -B buildworld >>> World build started on Sat Jul 16 23:00:57 UTC 2011 >>> 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 Sun Jul 17 00:57:22 UTC 2011 TB --- 2011-07-17 00:57:22 - generating LINT kernel config TB --- 2011-07-17 00:57:22 - cd /src/sys/i386/conf TB --- 2011-07-17 00:57:22 - /usr/bin/make -B LINT TB --- 2011-07-17 00:57:23 - building LINT kernel TB --- 2011-07-17 00:57:23 - MAKEOBJDIRPREFIX=/obj TB --- 2011-07-17 00:57:23 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-07-17 00:57:23 - TARGET=i386 TB --- 2011-07-17 00:57:23 - TARGET_ARCH=i386 TB --- 2011-07-17 00:57:23 - TZ=UTC TB --- 2011-07-17 00:57:23 - __MAKE_CONF=/dev/null TB --- 2011-07-17 00:57:23 - cd /src TB --- 2011-07-17 00:57:23 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sun Jul 17 00:57:23 UTC 2011 >>> 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 >>> Kernel build for LINT completed on Sun Jul 17 01:27:14 UTC 2011 TB --- 2011-07-17 01:27:14 - cd /src/sys/i386/conf TB --- 2011-07-17 01:27:14 - /usr/sbin/config -m GENERIC TB --- 2011-07-17 01:27:14 - building GENERIC kernel TB --- 2011-07-17 01:27:14 - MAKEOBJDIRPREFIX=/obj TB --- 2011-07-17 01:27:14 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-07-17 01:27:14 - TARGET=i386 TB --- 2011-07-17 01:27:14 - TARGET_ARCH=i386 TB --- 2011-07-17 01:27:14 - TZ=UTC TB --- 2011-07-17 01:27:14 - __MAKE_CONF=/dev/null TB --- 2011-07-17 01:27:14 - cd /src TB --- 2011-07-17 01:27:14 - /usr/bin/make -B buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Sun Jul 17 01:27:14 UTC 2011 >>> 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 >>> Kernel build for GENERIC completed on Sun Jul 17 01:50:48 UTC 2011 TB --- 2011-07-17 01:50:48 - cd /src/sys/i386/conf TB --- 2011-07-17 01:50:48 - /usr/sbin/config -m PAE TB --- 2011-07-17 01:50:48 - building PAE kernel TB --- 2011-07-17 01:50:48 - MAKEOBJDIRPREFIX=/obj TB --- 2011-07-17 01:50:48 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-07-17 01:50:48 - TARGET=i386 TB --- 2011-07-17 01:50:48 - TARGET_ARCH=i386 TB --- 2011-07-17 01:50:48 - TZ=UTC TB --- 2011-07-17 01:50:48 - __MAKE_CONF=/dev/null TB --- 2011-07-17 01:50:48 - cd /src TB --- 2011-07-17 01:50:48 - /usr/bin/make -B buildkernel KERNCONF=PAE >>> Kernel build for PAE started on Sun Jul 17 01:50:48 UTC 2011 >>> 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 >>> Kernel build for PAE completed on Sun Jul 17 01:56:54 UTC 2011 TB --- 2011-07-17 01:56:54 - cd /src/sys/i386/conf TB --- 2011-07-17 01:56:54 - /usr/sbin/config -m XBOX TB --- 2011-07-17 01:56:54 - building XBOX kernel TB --- 2011-07-17 01:56:54 - MAKEOBJDIRPREFIX=/obj TB --- 2011-07-17 01:56:54 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-07-17 01:56:54 - TARGET=i386 TB --- 2011-07-17 01:56:54 - TARGET_ARCH=i386 TB --- 2011-07-17 01:56:54 - TZ=UTC TB --- 2011-07-17 01:56:54 - __MAKE_CONF=/dev/null TB --- 2011-07-17 01:56:54 - cd /src TB --- 2011-07-17 01:56:54 - /usr/bin/make -B buildkernel KERNCONF=XBOX >>> Kernel build for XBOX started on Sun Jul 17 01:56:54 UTC 2011 >>> 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 >>> Kernel build for XBOX completed on Sun Jul 17 02:00:00 UTC 2011 TB --- 2011-07-17 02:00:00 - cd /src/sys/i386/conf TB --- 2011-07-17 02:00:00 - /usr/sbin/config -m XEN TB --- 2011-07-17 02:00:00 - building XEN kernel TB --- 2011-07-17 02:00:00 - MAKEOBJDIRPREFIX=/obj TB --- 2011-07-17 02:00:00 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-07-17 02:00:00 - TARGET=i386 TB --- 2011-07-17 02:00:00 - TARGET_ARCH=i386 TB --- 2011-07-17 02:00:00 - TZ=UTC TB --- 2011-07-17 02:00:00 - __MAKE_CONF=/dev/null TB --- 2011-07-17 02:00:00 - cd /src TB --- 2011-07-17 02:00:00 - /usr/bin/make -B buildkernel KERNCONF=XEN >>> Kernel build for XEN started on Sun Jul 17 02:00:00 UTC 2011 >>> 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 [...] :> hack.c cc -shared -nostdlib hack.c -o hack.So rm -f hack.c MAKE=/usr/bin/make sh /src/sys/conf/newvers.sh XEN 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 -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 -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-sse -mno-mmx -msoft-float -ffreestanding -fstack-protector -Werror vers.c linking kernel.debug mptable_pci.o: In function `mptable_hostb_attach': /src/sys/x86/x86/mptable_pci.c:73: undefined reference to `mptable_pci_host_res_init' *** Error code 1 Stop in /obj/i386.i386/src/sys/XEN. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-07-17 02:05:15 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-07-17 02:05:15 - ERROR: failed to build XEN kernel TB --- 2011-07-17 02:05:15 - 8719.88 user 1623.06 system 11115.27 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-i386-i386.full From owner-freebsd-current@FreeBSD.ORG Sun Jul 17 04:28:30 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B7403106566B for ; Sun, 17 Jul 2011 04:28:30 +0000 (UTC) (envelope-from alexvpetrov@gmail.com) Received: from mail-pz0-f49.google.com (mail-pz0-f49.google.com [209.85.210.49]) by mx1.freebsd.org (Postfix) with ESMTP id 948B88FC12 for ; Sun, 17 Jul 2011 04:28:30 +0000 (UTC) Received: by pzk33 with SMTP id 33so3958364pzk.8 for ; Sat, 16 Jul 2011 21:28:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:from:date:message-id:subject:to:content-type; bh=Smv3T6dE2QhncJCRXqdCf2zVbgilec3mq+QwPQ+/T24=; b=QzYJ6MVtY+ilRUSKwEts3dtlTRR7Pzb7ChhP9tDcIb82jXUy1BC1v+qSdgtGIERxxY INp4Nv5t3Ib3aQtIj6VnwvSmT36bpvAZjYexIPoA8+MTJw4zqtNthAGQ/fLrS3vyYkkg ODwZ5vuX41U/fGgibx6Av8BAbPrpv58Qgxp4Q= Received: by 10.68.51.68 with SMTP id i4mr4448404pbo.124.1310875520138; Sat, 16 Jul 2011 21:05:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.57.9 with HTTP; Sat, 16 Jul 2011 21:05:00 -0700 (PDT) From: "Alex V. Petrov" Date: Sun, 17 Jul 2011 12:05:00 +0800 Message-ID: To: current@freebsd.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: Help! stopped working ath0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Jul 2011 04:28:30 -0000 Hi ALL! Asus n10j some time (5-6 months) stopped working wi-fi. =D0=A1onstantly repeated (1-2 sec.): wlan0: link state changed to DOWN wlan0: link state changed to UP wlan0: link state changed to DOWN wlan0: link state changed to UP ifconfig: ath0: flags=3D8843 metric 0 mtu 229= 0 ether 00:22:43:2b:ff:90 nd6 options=3D29 media: IEEE 802.11 Wireless Ethernet autoselect mode 11g status: associated wlan0: flags=3D8843 metric 0 mtu 15= 00 ether 00:22:43:2b:ff:90 inet 0.0.0.0 netmask 0xff000000 broadcast 255.255.255.255 nd6 options=3D29 media: IEEE 802.11 Wireless Ethernet DS/1Mbps mode 11g status: associated ssid ssid-name channel 7 (2442 MHz 11g) bssid 00:17:9a:74:11:54 regdomain 96 indoor ecm authmode WPA2/802.11i privacy MIXED deftxkey 2 AES-CCM 2:128-bit txpower 20 bmiss 7 scanvalid 60 bgscan bgscanintvl 300 bgscanidle 250 roam:rssi 7 roam:rate 5 protmode CTS wme burst FreeBSD netbook.super 9.0-CURRENT FreeBSD 9.0-CURRENT #37: Sat Jul 16 05:17:55 KRAST 2011 alex@netbook.super:/usr/obj/usr/src/sys/GENERIC i386 dmesg: ath0: mem 0xfdff0000-0xfdffffff irq 17 at device 0.0 on pci2 ath0: AR2425 mac 14.2 RF5424 phy 7.0 pciconf: ath0@pci0:2:0:0: class=3D0x020000 card=3D0x10261a3b chip=3D0x001c168= c rev=3D0x01 hdr=3D0x00 vendor =3D 'Atheros Communications Inc.' device =3D 'AR5006 family 802.11abg Wireless NIC' class =3D network subclass =3D ethernet bar [10] =3D type Memory, range 64, base 0xfdff0000, size 65536, enab= led cap 01[40] =3D powerspec 2 supports D0 D3 current D0 cap 05[50] =3D MSI supports 1 message cap 10[60] =3D PCI-Express 1 legacy endpoint max data 128(128) link x1(= x1) cap 11[90] =3D MSI-X supports 1 message in map 0x10 ecap 0001[100] =3D AER 1 0 fatal 1 non-fatal 0 corrected ecap 0002[140] =3D VC 1 max VC0 --=20 ---------------------- Alex V. Petrov From owner-freebsd-current@FreeBSD.ORG Sun Jul 17 05:42:25 2011 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:4f8:fff6::35]) by hub.freebsd.org (Postfix) with ESMTP id 09D36106564A for ; Sun, 17 Jul 2011 05:42:25 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from 65-241-43-4.globalsuite.net (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id B35D314E04D; Sun, 17 Jul 2011 05:42:23 +0000 (UTC) Message-ID: <4E22763E.70201@FreeBSD.org> Date: Sat, 16 Jul 2011 22:42:22 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:5.0) Gecko/20110706 Thunderbird/5.0 MIME-Version: 1.0 To: Marius Strobl References: <20110707154958.GK14797@alchemy.franken.de> <20110708181102.GA95673@alchemy.franken.de> <20110708193236.GB95673@alchemy.franken.de> <20110714232126.GK95673@alchemy.franken.de> <4E1F8A75.5060304@FreeBSD.org> <20110715084039.GL95673@alchemy.franken.de> In-Reply-To: <20110715084039.GL95673@alchemy.franken.de> X-Enigmail-Version: 1.2pre OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: KOT MATPOCKuH , FreeBSD Current Subject: Re: named crashes on assertion in rbtdb.c on sparc64/SMP X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Jul 2011 05:42:25 -0000 On 07/15/2011 01:40, Marius Strobl wrote: > The generated config.h and platform.h for sparc64 are these: > http://people.freebsd.org/~marius/bind96_config.h > http://people.freebsd.org/~marius/bind96_platform.h Marius, Thanks again for all your help on this. During the work to upgrade to BIND 9.8 in HEAD I first tried your patch but I got some odd errors on some of the non-mainstream archs, so I ultimately went with something similar to what you sent but much more conservative. Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ From owner-freebsd-current@FreeBSD.ORG Sun Jul 17 08:20:28 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 05DF61065674; Sun, 17 Jul 2011 08:20:28 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: from mx0.hoeg.nl (mx0.hoeg.nl [IPv6:2a01:4f8:101:5343::aa]) by mx1.freebsd.org (Postfix) with ESMTP id 98A0D8FC18; Sun, 17 Jul 2011 08:20:27 +0000 (UTC) Received: by mx0.hoeg.nl (Postfix, from userid 1000) id CC2F32A2928A; Sun, 17 Jul 2011 10:20:26 +0200 (CEST) Date: Sun, 17 Jul 2011 10:20:26 +0200 From: Ed Schouten To: John Baldwin Message-ID: <20110717082026.GB47824@hoeg.nl> References: <201107162122.00466.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="CUfgB8w4ZwR/yMy5" Content-Disposition: inline In-Reply-To: <201107162122.00466.jhb@freebsd.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Kostik Belousov , Anonymous , freebsd-current@freebsd.org, Ben Kaduk Subject: Re: [Patch] [regression] libvgl and r197330 (kbd) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Jul 2011 08:20:28 -0000 --CUfgB8w4ZwR/yMy5 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable * John Baldwin , 20110717 03:22: > I just asked the kFreeBSD folks to test Ed's patch and it does restore th= e=20 > ABI. Ed, can you commit this patch as it's been successfully tested now? Sure. Done! --=20 Ed Schouten WWW: http://80386.nl/ --CUfgB8w4ZwR/yMy5 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (FreeBSD) iQIcBAEBAgAGBQJOIptKAAoJEG5e2P40kaK7Zf8P/jA5+arARGQBpkK69+HbU3QE 4p50I2e4A3QH/hzjQ7Q2SQKKjqYZcG611rwZD2JJYtgCuCbI6yP57Sv4H96kYfQg srwKvuGJoBvIgHOM4eCxtjL6qBl6D8lR5KZsTLfqurwdYsM1rSaNaOQ9Coj+CcB0 w9+/JAf6XTT6Y+K0sAZJcuJSx9vPpGMYQeLHj1SL47496hEPnFCjdeSePG4MndVv towo/GpU36WWa4Thh+Ob92wMtxMZE69WJ4vmQD2WAURbOBLD5zf09eD94M/G5pmK rx21fgaal/J5eRLNdftffU0Jqh+6tGscSXxlSBaVXdDL1ubM2QBPXjKwYadcinC+ RpOFAfX57k1HdRSUcZnPVbn1fiIsYn8gIUts4qS66vL0NcIaojDPemelSdrXyep0 EBxNhbDwRvRkkktXiLERWmYZi1uz33IvhPjBL4CGyl22O2b9tfVhikqIhRQyyMo5 BBm/4FBQxHyv1y55ZB3rmiFpn1xeK8W/r8rz3QSdxk73JuRaoNk1mJ89GXCpYUOs Q8TUPafu+9d1JcN03gGCyl6G53mL3nJ+0EK0+9FCaSDIrwAbNWNlxez7NUKUEOvm jnJIOJYSo9mw1eILwaVtm0LIHK0z+kazrGPwKkEqTqQBfJRU+yxvkHSIzCddwlDl 2TJQ+Vhps16WRKXtM6QE =1Lg0 -----END PGP SIGNATURE----- --CUfgB8w4ZwR/yMy5-- From owner-freebsd-current@FreeBSD.ORG Sun Jul 17 09:12:52 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5CF34106564A; Sun, 17 Jul 2011 09:12:52 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-gw0-f54.google.com (mail-gw0-f54.google.com [74.125.83.54]) by mx1.freebsd.org (Postfix) with ESMTP id C49248FC13; Sun, 17 Jul 2011 09:12:51 +0000 (UTC) Received: by gwb15 with SMTP id 15so1208457gwb.13 for ; Sun, 17 Jul 2011 02:12:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=CY/PqFCHpxe2zbd7DszkRJHD+ty9eLQJiiJaubD6v78=; b=PVwHoxqu5LNC2LYjIO5PArlkrNmOyX2VbL7BkIcpEO8Bhwb6oPUOpbGw80kLhWMU1y kEMdWvXJnjSvhS6fQsKChZ67g5bgC4x3BHZL91IWXSvfZz2Z0DACjn0+Tv/2Fm/29W9H f0Jwz+iAFkn7ZrzA7QItJzs5X1rVeWsUsDL2o= MIME-Version: 1.0 Received: by 10.150.74.3 with SMTP id w3mr4664972yba.329.1310893970567; Sun, 17 Jul 2011 02:12:50 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.150.197.5 with HTTP; Sun, 17 Jul 2011 02:12:50 -0700 (PDT) In-Reply-To: References: Date: Sun, 17 Jul 2011 17:12:50 +0800 X-Google-Sender-Auth: Z3Ldue1nbuNyccwGoFbhfYYW3OY Message-ID: From: Adrian Chadd To: "Alex V. Petrov" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-wireless@freebsd.org, current@freebsd.org Subject: Re: Help! stopped working ath0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Jul 2011 09:12:52 -0000 In order to debug this further, we need some further information from you. Can you please narrow down the date and/or -current revision which this particular issue occured? Eg, if you "revert" back to a -current kernel from 6 months ago, does your wifi work again? Thanks, Adrian On 17 July 2011 12:05, Alex V. Petrov wrote: > Hi ALL! > > Asus n10j > some time (5-6 months) stopped working wi-fi. > > =D0=A1onstantly repeated (1-2 sec.): > wlan0: link state changed to DOWN > wlan0: link state changed to UP > wlan0: link state changed to DOWN > wlan0: link state changed to UP > > > ifconfig: > > ath0: flags=3D8843 metric 0 mtu 2= 290 > =C2=A0 =C2=A0 =C2=A0 =C2=A0ether 00:22:43:2b:ff:90 > =C2=A0 =C2=A0 =C2=A0 =C2=A0nd6 options=3D29 > =C2=A0 =C2=A0 =C2=A0 =C2=A0media: IEEE 802.11 Wireless Ethernet autoselec= t mode 11g > =C2=A0 =C2=A0 =C2=A0 =C2=A0status: associated > > wlan0: flags=3D8843 metric 0 mtu = 1500 > =C2=A0 =C2=A0 =C2=A0 =C2=A0ether 00:22:43:2b:ff:90 > =C2=A0 =C2=A0 =C2=A0 =C2=A0inet 0.0.0.0 netmask 0xff000000 broadcast 255.= 255.255.255 > =C2=A0 =C2=A0 =C2=A0 =C2=A0nd6 options=3D29 > =C2=A0 =C2=A0 =C2=A0 =C2=A0media: IEEE 802.11 Wireless Ethernet DS/1Mbps = mode 11g > =C2=A0 =C2=A0 =C2=A0 =C2=A0status: associated > =C2=A0 =C2=A0 =C2=A0 =C2=A0ssid ssid-name channel 7 (2442 MHz 11g) bssid = 00:17:9a:74:11:54 > =C2=A0 =C2=A0 =C2=A0 =C2=A0regdomain 96 indoor ecm authmode WPA2/802.11i = privacy MIXED > =C2=A0 =C2=A0 =C2=A0 =C2=A0deftxkey 2 AES-CCM 2:128-bit txpower 20 bmiss = 7 scanvalid 60 bgscan > =C2=A0 =C2=A0 =C2=A0 =C2=A0bgscanintvl 300 bgscanidle 250 roam:rssi 7 roa= m:rate 5 protmode CTS > =C2=A0 =C2=A0 =C2=A0 =C2=A0wme burst > > > > FreeBSD netbook.super 9.0-CURRENT FreeBSD 9.0-CURRENT #37: Sat Jul 16 > 05:17:55 KRAST 2011 =C2=A0 =C2=A0 alex@netbook.super:/usr/obj/usr/src/sys= /GENERIC > i386 > > dmesg: > ath0: mem 0xfdff0000-0xfdffffff irq 17 at device 0.0 = on > pci2 > ath0: AR2425 mac 14.2 RF5424 phy 7.0 > > pciconf: > ath0@pci0:2:0:0: =C2=A0 =C2=A0 =C2=A0 =C2=A0class=3D0x020000 card=3D0x102= 61a3b chip=3D0x001c168c > rev=3D0x01 hdr=3D0x00 > =C2=A0 =C2=A0vendor =C2=A0 =C2=A0 =3D 'Atheros Communications Inc.' > =C2=A0 =C2=A0device =C2=A0 =C2=A0 =3D 'AR5006 family 802.11abg Wireless N= IC' > =C2=A0 =C2=A0class =C2=A0 =C2=A0 =C2=A0=3D network > =C2=A0 =C2=A0subclass =C2=A0 =3D ethernet > =C2=A0 =C2=A0bar =C2=A0 [10] =3D type Memory, range 64, base 0xfdff0000, = size 65536, enabled > =C2=A0 =C2=A0cap 01[40] =3D powerspec 2 =C2=A0supports D0 D3 =C2=A0curren= t D0 > =C2=A0 =C2=A0cap 05[50] =3D MSI supports 1 message > =C2=A0 =C2=A0cap 10[60] =3D PCI-Express 1 legacy endpoint max data 128(12= 8) link x1(x1) > =C2=A0 =C2=A0cap 11[90] =3D MSI-X supports 1 message in map 0x10 > ecap 0001[100] =3D AER 1 0 fatal 1 non-fatal 0 corrected > ecap 0002[140] =3D VC 1 max VC0 > > > -- > ---------------------- > Alex V. Petrov > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org= " > From owner-freebsd-current@FreeBSD.ORG Sun Jul 17 09:31:09 2011 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C4028106564A; Sun, 17 Jul 2011 09:31:09 +0000 (UTC) (envelope-from marius@alchemy.franken.de) Received: from alchemy.franken.de (alchemy.franken.de [194.94.249.214]) by mx1.freebsd.org (Postfix) with ESMTP id 580B18FC0A; Sun, 17 Jul 2011 09:31:09 +0000 (UTC) Received: from alchemy.franken.de (localhost [127.0.0.1]) by alchemy.franken.de (8.14.4/8.14.4/ALCHEMY.FRANKEN.DE) with ESMTP id p6H9V72v079360; Sun, 17 Jul 2011 11:31:08 +0200 (CEST) (envelope-from marius@alchemy.franken.de) Received: (from marius@localhost) by alchemy.franken.de (8.14.4/8.14.4/Submit) id p6H9V7rm079359; Sun, 17 Jul 2011 11:31:07 +0200 (CEST) (envelope-from marius) Date: Sun, 17 Jul 2011 11:31:07 +0200 From: Marius Strobl To: Doug Barton Message-ID: <20110717093107.GM95673@alchemy.franken.de> References: <20110708181102.GA95673@alchemy.franken.de> <20110708193236.GB95673@alchemy.franken.de> <20110714232126.GK95673@alchemy.franken.de> <4E1F8A75.5060304@FreeBSD.org> <20110715084039.GL95673@alchemy.franken.de> <4E22763E.70201@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4E22763E.70201@FreeBSD.org> User-Agent: Mutt/1.4.2.3i Cc: KOT MATPOCKuH , FreeBSD Current Subject: Re: named crashes on assertion in rbtdb.c on sparc64/SMP X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Jul 2011 09:31:09 -0000 On Sat, Jul 16, 2011 at 10:42:22PM -0700, Doug Barton wrote: > On 07/15/2011 01:40, Marius Strobl wrote: > > > The generated config.h and platform.h for sparc64 are these: > > http://people.freebsd.org/~marius/bind96_config.h > > http://people.freebsd.org/~marius/bind96_platform.h > > Marius, > > Thanks again for all your help on this. During the work to upgrade to > BIND 9.8 in HEAD I first tried your patch but I got some odd errors on > some of the non-mainstream archs, so I ultimately went with something > similar to what you sent but much more conservative. > Thanks! Marius From owner-freebsd-current@FreeBSD.ORG Sun Jul 17 10:11:45 2011 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:4f8:fff6::35]) by hub.freebsd.org (Postfix) with ESMTP id E5102106564A for ; Sun, 17 Jul 2011 10:11:44 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from 65-241-43-4.globalsuite.net (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id BBF9314E80A for ; Sun, 17 Jul 2011 10:11:44 +0000 (UTC) Message-ID: <4E22B560.4040401@FreeBSD.org> Date: Sun, 17 Jul 2011 03:11:44 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:5.0) Gecko/20110706 Thunderbird/5.0 MIME-Version: 1.0 To: FreeBSD Current X-Enigmail-Version: 1.2pre OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Subject: sys/boot/i386/boot2 build failure with clang X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Jul 2011 10:11:45 -0000 Howdy, Trying to build r224125 with clang, and got this (using no -j): ===> boot2 (all) objcopy -S -O binary boot1.out boot1 dd if=/dev/zero of=boot2.ldr bs=512 count=1 1+0 records in 1+0 records out 512 bytes transferred in 0.000040 secs (12782641 bytes/sec) clang -Os -fno-guess-branch-probability -fomit-frame-pointer -fno-unit-at-a-time -mno-align-long-strings -mrtd -mregparm=3 -DUSE_XREAD -DUFS1_AND_UFS2 -DFLAGS=0x80 -DSIOPRT=0x3f8 -DSIOFMT=0x3 -DSIOSPD=9600 -I/home/svn/head/sys/boot/i386/boot2/../../common -I/home/svn/head/sys/boot/i386/boot2/../btx/lib -I. -Wall -Waggregate-return -Wbad-function-cast -Wcast-align -Wmissing-declarations -Wmissing-prototypes -Wnested-externs -Wpointer-arith -Wshadow -Wstrict-prototypes -Wwrite-strings -Winline --param max-inline-insns-single=100 -mllvm -stack-alignment=8 -mllvm -inline-threshold=3 -mllvm -enable-load-pre=false -ffreestanding -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -msoft-float -m32 -march=i386 -g -std=gnu99 -S -o boot2.s.tmp /home/svn/head/sys/boot/i386/boot2/boot2.c clang: warning: the clang compiler does not support '-fno-unit-at-a-time' clang: warning: argument unused during compilation: '-fno-guess-branch-probability' clang: warning: argument unused during compilation: '-mno-align-long-strings' clang: warning: argument unused during compilation: '--param max-inline-insns-single=100' clang: warning: argument unused during compilation: '-mpreferred-stack-boundary=2' In file included from /home/svn/head/sys/boot/i386/boot2/boot2.c:172: /home/svn/head/sys/boot/i386/boot2/../../common/ufsread.c:232:17: warning: cast from 'char *' to 'struct ufs1_dinode *' increases required alignment from 1 to 4 [-Wcast-align] memcpy(&dp1, (struct ufs1_dinode *)blkbuf + n, ^~~~~~~~~~~~~~~~~~~~~~~~~~~~ /home/svn/head/sys/boot/i386/boot2/../../common/ufsread.c:235:17: warning: cast from 'char *' to 'struct ufs2_dinode *' increases required alignment from 1 to 4 [-Wcast-align] memcpy(&dp2, (struct ufs2_dinode *)blkbuf + n, ^~~~~~~~~~~~~~~~~~~~~~~~~~~~ /home/svn/head/sys/boot/i386/boot2/boot2.c:224:1: warning: no previous prototype for function 'main' [-Wmissing-prototypes] main(void) ^ /home/svn/head/sys/boot/i386/boot2/boot2.c:352:4: warning: cast from 'caddr_t' (aka 'char *') to 'Elf32_Word *' (aka 'unsigned int *') increases required alignment from 1 to 4 [-Wcast-align] *(Elf32_Word *)p = es[i].sh_size; ^~~~~~~~~~~~~~~ /home/svn/head/sys/boot/i386/boot2/boot2.c:611:8: warning: cast from 'caddr_t' (aka 'char *') to 'uint32_t *' (aka 'unsigned int *') increases required alignment from 1 to 4 [-Wcast-align] t1 = *(uint32_t *)PTOV(0x46c); ^~~~~~~~~~~~~~~~~~~~~~~ 5 warnings generated. sed -e '/align/d' -e '/nop/d' < boot2.s.tmp > boot2.s rm -f boot2.s.tmp as --32 -o boot2.o boot2.s boot2.s: Assembler messages: boot2.s:4073: Error: unknown pseudo-op: `.cfi_sections' *** Error code 1 -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ From owner-freebsd-current@FreeBSD.ORG Sun Jul 17 11:27:19 2011 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:4f8:fff6::35]) by hub.freebsd.org (Postfix) with ESMTP id 5F62A1065670 for ; Sun, 17 Jul 2011 11:27:19 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from 65-241-43-4.globalsuite.net (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id 1206014E697 for ; Sun, 17 Jul 2011 11:27:19 +0000 (UTC) Message-ID: <4E22C716.4000007@FreeBSD.org> Date: Sun, 17 Jul 2011 04:27:18 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:5.0) Gecko/20110706 Thunderbird/5.0 MIME-Version: 1.0 To: FreeBSD Current References: <4E22B560.4040401@FreeBSD.org> In-Reply-To: <4E22B560.4040401@FreeBSD.org> X-Enigmail-Version: 1.2pre OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Subject: Re: sys/boot/i386/boot2 build failure with clang X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Jul 2011 11:27:19 -0000 I have DEBUG_FLAGS+= -g in my /etc/make.conf. Commenting that out allows this to work. Doug On 07/17/2011 03:11, Doug Barton wrote: > Howdy, > > Trying to build r224125 with clang, and got this (using no -j): > > ===> boot2 (all) > objcopy -S -O binary boot1.out boot1 > dd if=/dev/zero of=boot2.ldr bs=512 count=1 > 1+0 records in > 1+0 records out > 512 bytes transferred in 0.000040 secs (12782641 bytes/sec) > clang -Os -fno-guess-branch-probability -fomit-frame-pointer > -fno-unit-at-a-time -mno-align-long-strings -mrtd -mregparm=3 > -DUSE_XREAD -DUFS1_AND_UFS2 -DFLAGS=0x80 -DSIOPRT=0x3f8 -DSIOFMT=0x3 > -DSIOSPD=9600 -I/home/svn/head/sys/boot/i386/boot2/../../common > -I/home/svn/head/sys/boot/i386/boot2/../btx/lib -I. -Wall > -Waggregate-return -Wbad-function-cast -Wcast-align > -Wmissing-declarations -Wmissing-prototypes -Wnested-externs > -Wpointer-arith -Wshadow -Wstrict-prototypes -Wwrite-strings -Winline > --param max-inline-insns-single=100 -mllvm -stack-alignment=8 -mllvm > -inline-threshold=3 -mllvm -enable-load-pre=false -ffreestanding > -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 > -mno-sse3 -msoft-float -m32 -march=i386 -g -std=gnu99 -S -o > boot2.s.tmp /home/svn/head/sys/boot/i386/boot2/boot2.c > clang: warning: the clang compiler does not support '-fno-unit-at-a-time' > clang: warning: argument unused during compilation: > '-fno-guess-branch-probability' > clang: warning: argument unused during compilation: > '-mno-align-long-strings' > clang: warning: argument unused during compilation: '--param > max-inline-insns-single=100' > clang: warning: argument unused during compilation: > '-mpreferred-stack-boundary=2' > In file included from /home/svn/head/sys/boot/i386/boot2/boot2.c:172: > /home/svn/head/sys/boot/i386/boot2/../../common/ufsread.c:232:17: > warning: cast > from 'char *' to 'struct ufs1_dinode *' increases required > alignment from > 1 to 4 [-Wcast-align] > memcpy(&dp1, (struct ufs1_dinode *)blkbuf + n, > ^~~~~~~~~~~~~~~~~~~~~~~~~~~~ > /home/svn/head/sys/boot/i386/boot2/../../common/ufsread.c:235:17: > warning: cast > from 'char *' to 'struct ufs2_dinode *' increases required > alignment from > 1 to 4 [-Wcast-align] > memcpy(&dp2, (struct ufs2_dinode *)blkbuf + n, > ^~~~~~~~~~~~~~~~~~~~~~~~~~~~ > /home/svn/head/sys/boot/i386/boot2/boot2.c:224:1: warning: no previous > prototype > for function 'main' [-Wmissing-prototypes] > main(void) > ^ > /home/svn/head/sys/boot/i386/boot2/boot2.c:352:4: warning: cast from > 'caddr_t' > (aka 'char *') to 'Elf32_Word *' (aka 'unsigned int *') increases > required > alignment from 1 to 4 [-Wcast-align] > *(Elf32_Word *)p = es[i].sh_size; > ^~~~~~~~~~~~~~~ > /home/svn/head/sys/boot/i386/boot2/boot2.c:611:8: warning: cast from > 'caddr_t' > (aka 'char *') to 'uint32_t *' (aka 'unsigned int *') increases > required > alignment from 1 to 4 [-Wcast-align] > t1 = *(uint32_t *)PTOV(0x46c); > ^~~~~~~~~~~~~~~~~~~~~~~ > 5 warnings generated. > sed -e '/align/d' -e '/nop/d' < boot2.s.tmp > boot2.s > rm -f boot2.s.tmp > as --32 -o boot2.o boot2.s > boot2.s: Assembler messages: > boot2.s:4073: Error: unknown pseudo-op: `.cfi_sections' > *** Error code 1 > > > > -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ From owner-freebsd-current@FreeBSD.ORG Sun Jul 17 11:54:57 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2D4791065746; Sun, 17 Jul 2011 11:54:57 +0000 (UTC) (envelope-from uqs@spoerlein.net) Received: from acme.spoerlein.net (acme.spoerlein.net [IPv6:2a01:4f8:131:23c2::1]) by mx1.freebsd.org (Postfix) with ESMTP id AA4648FC18; Sun, 17 Jul 2011 11:54:56 +0000 (UTC) Received: from localhost (acme.spoerlein.net [IPv6:2a01:4f8:131:23c2::1]) by acme.spoerlein.net (8.14.4/8.14.4) with ESMTP id p6HBstbl036448 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Sun, 17 Jul 2011 13:54:55 +0200 (CEST) (envelope-from uqs@spoerlein.net) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=spoerlein.net; s=dkim200908; t=1310903695; bh=741/M3Mg7vpn/oZV3PE7tPAypUPHoElfVhSLvnyKRW4=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:In-Reply-To; b=PCJarXtf/rF0gtGiLhO6Ht/fqXcRzJdyJt4bw9Dw/RbrXjyeRAbXqnJxKsFgPsrIb SiS3YpRWYjtyJyiYDLDnCktHAtV3xXj1B4BicqFWhfldSsX8kd48vdNHqY4X19gYqF i/ArEJE7Rpe1pP37XMZ8Dy7BrJf1WX+9RC6NcnCk= Date: Sun, 17 Jul 2011 13:54:54 +0200 From: Ulrich =?utf-8?B?U3DDtnJsZWlu?= To: Gleb Kurtsou Message-ID: <20110717115454.GG8485@acme.spoerlein.net> Mail-Followup-To: Gleb Kurtsou , mdf@freebsd.org, Ali Mashtizadeh , FreeBSD Current , Arnaud Lacombe References: <20110707015151.GB71966@troutmask.apl.washington.edu> <4E1B67C7.8040402@FreeBSD.org> <20110712214049.GA12290@tops> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110712214049.GA12290@tops> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: mdf@freebsd.org, Ali Mashtizadeh , FreeBSD Current , Arnaud Lacombe Subject: Re: Heavy I/O blocks FreeBSD box for several seconds X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Jul 2011 11:54:57 -0000 On Wed, 13.07.2011 at 00:40:49 +0300, Gleb Kurtsou wrote: > On (11/07/2011 16:36), mdf@FreeBSD.org wrote: > > On Mon, Jul 11, 2011 at 4:00 PM, Ali Mashtizadeh wrote: > > > Maybe someone can setup something like reviewboard [1] for developers > > > to use. This may also help folks who want to keep abreast of the > > > current work in a particular subsystem or get involved into the > > > development process more. At my company we use reviews and it seems to > > > help the catch some bugs and help new engineers ramp up faster. > > > > > > [1] http://www.reviewboard.org/ > > > > FreeBSD development is completely open; anyone can sign up for the > > svn-src-* mailing list they are interested in, including > > svn-src-head@. Code reviews are plenty as well; just check the list > > archives for discussion of bugs, poor design choices and unintended > > effects. But most reviews are silent and after-the-fact by looking at > > the list mail. It's a system that seems to be working just fine for > > the FreeBSD project so far. This isn't a job for most anyone; it's a > > volunteer project and so anything that raises the barrier to getting > > work done for the project should be looked at with skepticism. > > I agree with everything said above and think that it's not reviews > that's missing. By review I don't mean something like getting "ok to > commit" reply from N developers before committing. svn-src@ works > great for it, commits keep getting reverted :) Review is a time > consuming process that also requires certain level of expertise. > Volunteer project can hardly afford it. > > Having a project adopted way of sharing work in progress will be a step > forward. Yes, I'm aware of perforce, it's to hard to use and wasn't > designed to share and test ideas. I think guthub can be a very good > candidate (but AFAIK it won't allow hosting of FreeBSD repo for not paid > accounts). I'm not suggesting switching to git as VCS, but using github > UI for communication and tracking not yet commited or work in progress > changes. In ideal world developers will merge patches from each other > increasing chance of a good code to survive and get commited later. > Currently we have patches hosted at people.freebsd.org, as attachments > on maillists and PRs -- almost all stale or outdated. Key difference of > github is that original patch author will be aware of you using it, > potentially updating and improving it. Others can continue supporting > the patch if original author abandons it, etc. Sending patches is too > complicated and counterproductive comparing to github. Yes, I fully agree, that's why https://github.com/freebsd/freebsd-head exists today, but hasn't been advertised yet (I need to write documentation and can't force myself to do it :( Feel free to start using it! Together with the git-svn metadata that you can grab from repos.freebsd.your.org it makes a solid platform for working on FreeBSD code. Uli From owner-freebsd-current@FreeBSD.ORG Sun Jul 17 14:03:44 2011 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A6E80106566C for ; Sun, 17 Jul 2011 14:03:44 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (tensor.andric.com [87.251.56.140]) by mx1.freebsd.org (Postfix) with ESMTP id 5B47F8FC0A for ; Sun, 17 Jul 2011 14:03:44 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7:0:a425:41bf:691:801a] (unknown [IPv6:2001:7b8:3a7:0:a425:41bf:691:801a]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id C69CC5C37; Sun, 17 Jul 2011 16:03:40 +0200 (CEST) Message-ID: <4E22EBC2.4070802@FreeBSD.org> Date: Sun, 17 Jul 2011 16:03:46 +0200 From: Dimitry Andric Organization: The FreeBSD Project User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0a1) Gecko/20110716 Thunderbird/8.0a1 MIME-Version: 1.0 To: Doug Barton References: <4E22B560.4040401@FreeBSD.org> In-Reply-To: <4E22B560.4040401@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD Current Subject: Re: sys/boot/i386/boot2 build failure with clang X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Jul 2011 14:03:44 -0000 On 2011-07-17 12:11, Doug Barton wrote: > Trying to build r224125 with clang, and got this (using no -j): ... > as --32 -o boot2.o boot2.s > boot2.s: Assembler messages: > boot2.s:4073: Error: unknown pseudo-op: `.cfi_sections' When using -g, clang outputs directives that are simply too new for our binutils. The way that sys/boot/i386/boot2 and zfsboot are processed is special: 1) The boot2.c code is compiled with -S, to boot2.s.tmp 2) boot2.s.tmp is processed using sed, to remove any alignment directives and filler nops, to reduce the code size 3) The resulting boot2.s is assembled, using plain 'as' In step 3, GNU as chokes on the assembly produced by clang, when you use certain CFLAGS or DEBUG_FLAGS (-g being one of them). When compiling .c to .o files normally, this is never a problem, since clang uses its integrated assembler to output an object file. In any case, I have committed a fix in r224131, let me know how that works out for you. From owner-freebsd-current@FreeBSD.ORG Sun Jul 17 14:06:28 2011 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B8570106564A; Sun, 17 Jul 2011 14:06:28 +0000 (UTC) (envelope-from imb@protected-networks.net) Received: from sarah.protected-networks.net (sarah.protected-networks.net [IPv6:2001:470:1f07:4e1::1]) by mx1.freebsd.org (Postfix) with ESMTP id 82EEB8FC1B; Sun, 17 Jul 2011 14:06:28 +0000 (UTC) Received: from toshi.auburn.protected-networks.net (toshi.auburn.protected-networks.net [202.12.127.84]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "Iain Butler", Issuer "RSA Class 2 Personal CA" (verified OK)) (Authenticated sender: imb@protected-networks.net) by sarah.protected-networks.net (Postfix) with ESMTPSA id ABC7C60DB; Sun, 17 Jul 2011 10:06:26 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=protected-networks.net; s=200705; t=1310911586; bh=Wq2CseK2Ur45dkyUZQWkKcZ2+pZPOseKeIYmPUFY8Uk=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=DLtkgvhMsp1cyn4jeJV/vQfUxjFTCuJAnYg+qH7xYuwkmsXC4ReCy5VRy96V+D5qh YMj6Z7GIdlWtZmwxhPjb7RQxcurGsYqrej3SirN7eL/i4UJ+ZYnrHDdbsrciP63 DomainKey-Signature: a=rsa-sha1; s=200509; d=protected-networks.net; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:cc:subject: references:in-reply-to:x-enigmail-version:openpgp:content-type:content-transfer-encoding; b=pPle4RT3AvnMfaWPjGTcV9TQF4Qq7t+P/oZkGJErbipcxbVwFPIAaN0PMcr6xa5Eu V+DBE/b/opfbO4FXnEtIfqvWaDyHuFBouIBgCt/1p/YYkgYAM5DV1tDb/fOGgaT Message-ID: <4E22EC60.2050708@protected-networks.net> Date: Sun, 17 Jul 2011 10:06:24 -0400 From: Michael Butler User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:5.0) Gecko/20110713 Thunderbird/5.0 MIME-Version: 1.0 To: John Baldwin References: <4CE54A1B-B0EF-4907-88BE-124FC4FF236D@FreeBSD.org> In-Reply-To: <4CE54A1B-B0EF-4907-88BE-124FC4FF236D@FreeBSD.org> X-Enigmail-Version: 1.2pre OpenPGP: id=0442D492 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: current@FreeBSD.org Subject: Re: [PATCH] Make x86 Host-PCI bridge drivers honor decoded ranges X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Jul 2011 14:06:28 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 07/09/11 20:04, John Baldwin wrote: > This patch adds a new API (pcib_host_res_*) that Host-PCI bridge drivers can > use to restrict allocations for child devices to a known subset of address > ranges that the bridge decodes. One observation from what is now in 'HEAD' .. isa_probe_children: disabling PnP devices ichwd0: on isa0 isab0: found ICH7 or equivalent chipset: Intel ICH7M watchdog timer pcib0: allocated type 4 (0x1030-0x1037) for rid 0 of ichwd0 pcib0: allocated type 4 (0x1060-0x107f) for rid 1 of ichwd0 ichwd0: unable to reserve GCS registers device_attach: ichwd0 attach returned 6 pmtimer0 on isa0 atkbdc: atkbdc0 already exists; skipping it atrtc: atrtc0 already exists; skipping it attimer: attimer0 already exists; skipping it sc: sc0 already exists; skipping it isa_probe_children: probing non-PnP devices ichwd0: at port 0x1030-0x1037,0x1060-0x107f on isa0 isab0: found ICH7 or equivalent chipset: Intel ICH7M watchdog timer pcib0: allocated type 4 (0x1030-0x1037) for rid 0 of ichwd0 pcib0: allocated type 4 (0x1060-0x107f) for rid 1 of ichwd0 ichwd0: unable to reserve GCS registers device_attach: ichwd0 attach returned 6 .. where previous kernels would proceed as follows: isa_probe_children: disabling PnP devices ichwd0: on isa0 isab0: found ICH7 or equivalent chipset: Intel ICH7M watchdog timer ichwd0: Intel ICH7M watchdog timer (ICH7 or equivalent) ichwd0: timer disabled pmtimer0 on isa0 atkbdc: atkbdc0 already exists; skipping it atrtc: atrtc0 already exists; skipping it attimer: attimer0 already exists; skipping it sc: sc0 already exists; skipping it isa_probe_children: probing non-PnP devices imb -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEARECAAYFAk4i7F8ACgkQQv9rrgRC1JI4fwCfWPZRvt00u+SCrH9sOupc7eWa f5EAoLZFHjTWBX7ALCSj67G4agFIRItd =80Y7 -----END PGP SIGNATURE----- From owner-freebsd-current@FreeBSD.ORG Sun Jul 17 14:21:53 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from apollo.emma.line.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by hub.freebsd.org (Postfix) with ESMTP id 0B3B51065673; Sun, 17 Jul 2011 14:21:53 +0000 (UTC) (envelope-from mandree@FreeBSD.org) Received: from [127.0.0.1] (localhost.localdomain [127.0.0.1]) by apollo.emma.line.org (Postfix) with ESMTP id 05B4B23D34D; Sun, 17 Jul 2011 16:21:51 +0200 (CEST) Message-ID: <4E22EFFF.3050605@FreeBSD.org> Date: Sun, 17 Jul 2011 16:21:51 +0200 From: Matthias Andree User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.18) Gecko/20110617 Mnenhy/0.8.3 Thunderbird/3.1.11 MIME-Version: 1.0 To: bug-followup@FreeBSD.org, freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit Cc: re@freebsd.org, portmgr@freebsd.org Subject: Re: bin/147175: [kerberos] [patch] libhx509.so contains references to MD2_* but doesn't reference libcrypto.so, which has them X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Jul 2011 14:21:53 -0000 This (GSSAPI linker failure on 9-CURRENT because its libhx509 needs MD2 but libcrypto doesn't provide it) affects security/putty 0.6.1 as well now. There is now lots of stuff on the web on this incompatibility. *Someone needs to fix the GSSAPI-Kerberos/MD2 conflict before the 9-release cycle!* From owner-freebsd-current@FreeBSD.ORG Sun Jul 17 17:00:44 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 228A2106566B for ; Sun, 17 Jul 2011 17:00:44 +0000 (UTC) (envelope-from artemb@gmail.com) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 7DF7E8FC08 for ; Sun, 17 Jul 2011 17:00:43 +0000 (UTC) Received: by wyg24 with SMTP id 24so2227722wyg.13 for ; Sun, 17 Jul 2011 10:00:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type :content-transfer-encoding; bh=JrgtYKQK3oodDyGyesMD6Rwp6Y/X2o1nIa5oBHvYXgE=; b=FFuGljSKnt6NZtL9WaSbQFUBz9H1QPVEi2TQ1UlvnWykkU+QvqjYvUbN4HO4KOE/ZN QDBOKZB8Iv+40MEJW9q4T/hOo9jaKUwMfauXAnbJV1RcRgN0yRid6op4XpMmOGvDms+X /HNMyufRExEbh01lHTDOVPASEUNF/XePaeBCs= MIME-Version: 1.0 Received: by 10.216.144.100 with SMTP id m78mr4703405wej.55.1310922041663; Sun, 17 Jul 2011 10:00:41 -0700 (PDT) Sender: artemb@gmail.com Received: by 10.216.46.18 with HTTP; Sun, 17 Jul 2011 10:00:41 -0700 (PDT) In-Reply-To: <20110717115454.GG8485@acme.spoerlein.net> References: <20110707015151.GB71966@troutmask.apl.washington.edu> <4E1B67C7.8040402@FreeBSD.org> <20110712214049.GA12290@tops> <20110717115454.GG8485@acme.spoerlein.net> Date: Sun, 17 Jul 2011 10:00:41 -0700 X-Google-Sender-Auth: 4xu-oh3Nhn9-vImEf_RpwgZW7CA Message-ID: From: Artem Belevich To: Gleb Kurtsou , mdf@freebsd.org, Ali Mashtizadeh , FreeBSD Current , Arnaud Lacombe Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Subject: Re: Heavy I/O blocks FreeBSD box for several seconds X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Jul 2011 17:00:44 -0000 On Sun, Jul 17, 2011 at 4:54 AM, Ulrich Sp=F6rlein wrot= e: ... >> Having a project adopted way of sharing work in progress will be a step >> forward. Yes, I'm aware of perforce, it's to hard to use and wasn't >> designed to share and test ideas. I think guthub can be a very good >> candidate (but AFAIK it won't allow hosting of FreeBSD repo for not paid >> accounts). I'm not suggesting switching to git as VCS, but using github >> UI for communication and tracking not yet commited or work in progress >> changes. In ideal world developers will merge patches from each other >> increasing chance of a good code to survive and get commited later. >> Currently we have patches hosted at people.freebsd.org, as attachments >> on maillists and PRs -- almost all stale or outdated. Key difference of >> github is that original patch author will be aware of you using it, >> potentially updating and improving it. Others can continue supporting >> the patch if original author abandons it, etc. Sending patches is too >> complicated and counterproductive comparing to github. > > Yes, I fully agree, that's why https://github.com/freebsd/freebsd-head > exists today, but hasn't been advertised yet (I need to write > documentation and can't force myself to do it :( > > Feel free to start using it! Together with the git-svn metadata that you > can grab from repos.freebsd.your.org it makes a solid platform for > working on FreeBSD code. +1 for git. There's also git://gitorious.org/freebsd/freebsd.git which mirrors head and stable/releng/release branches. --Artem From owner-freebsd-current@FreeBSD.ORG Sun Jul 17 17:21:56 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C3C7D106566B for ; Sun, 17 Jul 2011 17:21:56 +0000 (UTC) (envelope-from alexvpetrov@gmail.com) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by mx1.freebsd.org (Postfix) with ESMTP id 216838FC0C for ; Sun, 17 Jul 2011 17:21:55 +0000 (UTC) Received: by fxe6 with SMTP id 6so4013195fxe.17 for ; Sun, 17 Jul 2011 10:21:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:to:cc:subject:date:message-id:user-agent:in-reply-to :references:mime-version:content-transfer-encoding:content-type; bh=3o9VEfp0s03GGAOitO7Kg8HJovms0L7cV5YpnyZCtW4=; b=MWPwFuUNfyr6EAFvP04JfGSf349gxZlkkkWYARfBooL/eRG30+yLP2L9DSpWQoFdbQ 2csYDXfnDuCnv7EdTTK/vXIiDkUGCadA1hG3B6rkXHBmGP+8l8W+AUrCleK7l46uItuF dVAOTJc/CPYyLmb3KJybB5ykeKk88oBsDJrrg= Received: by 10.204.128.213 with SMTP id l21mr1596612bks.288.1310923314679; Sun, 17 Jul 2011 10:21:54 -0700 (PDT) Received: from alex.super ([91.195.101.86]) by mx.google.com with ESMTPS id s16sm2120264fah.0.2011.07.17.10.21.50 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 17 Jul 2011 10:21:52 -0700 (PDT) From: "Alex V. Petrov" To: Adrian Chadd , Thor Ablestar Date: Mon, 18 Jul 2011 01:21:46 +0800 Message-ID: <1890860.U4gLoRy9a1@alex.super> User-Agent: KMail/4.6.0 (FreeBSD/8.2-STABLE; KDE/4.6.5; amd64; ; ) In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="utf-8" Cc: freebsd-wireless@freebsd.org, current@freebsd.org Subject: Re: Help! stopped working ath0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Jul 2011 17:21:56 -0000 Very sorry for my carelessness and panic Reason - hostapd_enable="YES" in /etc/rc.conf. :-( ---------------------- Alex V. Petrov From owner-freebsd-current@FreeBSD.ORG Mon Jul 18 07:42:25 2011 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:4f8:fff6::35]) by hub.freebsd.org (Postfix) with ESMTP id AC4971065670; Mon, 18 Jul 2011 07:42:25 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from 65-241-43-4.globalsuite.net (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id 271B814D899; Mon, 18 Jul 2011 07:42:25 +0000 (UTC) Message-ID: <4E23E3E0.2090209@FreeBSD.org> Date: Mon, 18 Jul 2011 00:42:24 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:5.0) Gecko/20110706 Thunderbird/5.0 MIME-Version: 1.0 To: Dimitry Andric References: <4E22B560.4040401@FreeBSD.org> <4E22EBC2.4070802@FreeBSD.org> In-Reply-To: <4E22EBC2.4070802@FreeBSD.org> X-Enigmail-Version: 1.2pre OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: FreeBSD Current Subject: Re: sys/boot/i386/boot2 build failure with clang X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jul 2011 07:42:25 -0000 On 07/17/2011 07:03, Dimitry Andric wrote: > In any case, I have committed a fix in r224131, let me know how that > works out for you. A clean /usr/obj got me all the way through buildworld to the point where it was building the 32-bit compat libs, and got this: clang -m32 -march=i686 -mmmx -msse -msse2 -mfancy-math-387 -DCOMPAT_32BIT -isystem /usr/obj/home/svn/head/lib32/usr/include/ -L/usr/obj/home/svn/head/lib32/usr/lib32 -B/usr/obj/home/svn/head/lib32/usr/lib32 -O2 -pipe -g -I/home/svn/head/lib/libc/include -I/home/svn/head/lib/libc/../../include -I/home/svn/head/lib/libc/i386 -DNLS -D__DBINTERFACE_PRIVATE -I/home/svn/head/lib/libc/../../contrib/gdtoa -DINET6 -I/usr/local/obj/lib32/home/svn/head/lib/libc -I/home/svn/head/lib/libc/resolv -D_ACL_PRIVATE -DPOSIX_MISTAKE -no-integrated-as -I/home/svn/head/lib/libc/../../contrib/tzcode/stdtime -I/home/svn/head/lib/libc/stdtime -I/home/svn/head/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/home/svn/head/lib/libc/rpc -DNS_CACHING -DSYMBOL_VERSIONING -g -std=gnu99 -fstack-protector -Wsystem-headers -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /home/svn/head/lib/libc/stdlib/malloc.c clang: warning: argument unused during compilation: '-mfancy-math-387' clang: warning: argument unused during compilation: '-L/usr/obj/home/svn/head/lib32/usr/lib32' /tmp/.root/cc-ysEysz.s: Assembler messages: /tmp/.root/cc-ysEysz.s:31589: Error: unknown pseudo-op: `.cfi_sections' clang: error: assembler command failed with exit code 1 (use -v to see invocation) *** Error code 1 Thanks, Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ From owner-freebsd-current@FreeBSD.ORG Mon Jul 18 08:26:50 2011 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:4f8:fff6::35]) by hub.freebsd.org (Postfix) with ESMTP id AF9EF1065674 for ; Mon, 18 Jul 2011 08:26:50 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from 65-241-43-4.globalsuite.net (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id 39AC514E6D1 for ; Mon, 18 Jul 2011 08:26:50 +0000 (UTC) Message-ID: <4E23EE49.5040801@FreeBSD.org> Date: Mon, 18 Jul 2011 01:26:49 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:5.0) Gecko/20110706 Thunderbird/5.0 MIME-Version: 1.0 To: FreeBSD Current X-Enigmail-Version: 1.2pre OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Subject: ichwd0: unable to reserve GCS registers X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jul 2011 08:26:50 -0000 I'm getting this with recent HEAD: isab0: found ICH7 or equivalent chipset: Intel ICH7M watchdog timer ichwd0: at port 0x1030-0x1037,0x1060-0x107f on isa0 isab0: found ICH7 or equivalent chipset: Intel ICH7M watchdog timer pcib0: allocated type 4 (0x1030-0x1037) for rid 0 of ichwd0 pcib0: allocated type 4 (0x1060-0x107f) for rid 1 of ichwd0 ichwd0: unable to reserve GCS registers device_attach: ichwd0 attach returned 6 pcib0: allocated type 4 (0x2f8-0x2ff) for rid 0 of uart1 -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ From owner-freebsd-current@FreeBSD.ORG Mon Jul 18 11:34:15 2011 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D91B5106564A; Mon, 18 Jul 2011 11:34:15 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id DCA518FC12; Mon, 18 Jul 2011 11:34:14 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id OAA21726; Mon, 18 Jul 2011 14:34:11 +0300 (EEST) (envelope-from avg@FreeBSD.org) Message-ID: <4E241A33.2000009@FreeBSD.org> Date: Mon, 18 Jul 2011 14:34:11 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:5.0) Gecko/20110705 Thunderbird/5.0 MIME-Version: 1.0 To: Max Laier , John Baldwin References: <4DCD357D.6000109@FreeBSD.org> <4DCFE8FA.6080005@FreeBSD.org> <4DCFEE33.5090808@FreeBSD.org> <201105151209.13846.max@love2party.net> <4DCFFE52.1090002@FreeBSD.org> In-Reply-To: <4DCFFE52.1090002@FreeBSD.org> X-Enigmail-Version: 1.2pre Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: FreeBSD current Subject: Re: proposed smp_rendezvous change X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jul 2011 11:34:15 -0000 on 15/05/2011 19:24 Andriy Gapon said the following: > on 15/05/2011 19:09 Max Laier said the following: >> >> I don't think we ever intended to synchronize the local teardown part, and I >> believe that is the correct behavior for this API. >> >> This version is sufficiently close to what I have, so I am resonably sure that >> it will work for us. It seems, however, that if we move to check to after >> picking up the lock anyway, the generation approach has even less impact and I >> am starting to prefer that solution. >> >> Andriy, is there any reason why you'd prefer your approach over the generation >> version? > > No reason. And I even haven't said that I prefer it :-) > I just wanted to show and explain it as apparently there was some > misunderstanding about it. I think that generation count approach could even > have a little bit better performance while perhaps being a tiny bit less obvious. Resurrecting this conversation. Here's a link to the thread on gmane for your convenience: http://article.gmane.org/gmane.os.freebsd.current/132682 It seems that we haven't fully accounted for the special case of master CPU behavior in neither my proposed fix that added a new wait count nor in the committed fix that has added a generation count. This has been pointed out by kib at the recent mini-DevSummit in Kyiv. The problem can be illustrated by the following example: - the teardown function is a "real" function; that is, not NULL and not smp_rendevous_no_ barrier (sic) - the arg parameter is a non-NULL pointer - the teardown function actually accesses memory pointed to by the arg - the master CPU deallocates memory pointed by the arg right after smp_rendezvous() call returns (either via free(9) or by stack management, etc) Quoting the code: MPASS(generation == smp_rv_generation); atomic_add_int(&smp_rv_waiters[2], 1); if (local_teardown_func != smp_no_rendevous_barrier) { while (smp_rv_waiters[2] < smp_rv_ncpus && generation == smp_rv_generation) cpu_spinwait(); if (local_teardown_func != NULL) local_teardown_func(local_func_arg); } Generation count helps slave CPUs to not get stuck at the while loop, but it doesn't prevent stale/different arg being passed to the teardown function. So here is a patch, which is a variation of my earlier proposal, that should fix this issue: http://people.freebsd.org/~avg/smp_rendezvous.diff The patch is not tested yet. The patch undoes the smp_rv_generation change and introduces a new smp_rv_waiters[] element. Perhaps the code could be optimized by making waiting on smp_rv_waiters[3] conditional on some combination of values for the teardown and the arg, but I decided to follow the KISS principle here to make the code a little bit more robust. -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Mon Jul 18 11:39:03 2011 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4433D1065670; Mon, 18 Jul 2011 11:39:03 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 5D5DC8FC1A; Mon, 18 Jul 2011 11:39:01 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id OAA21775; Mon, 18 Jul 2011 14:39:00 +0300 (EEST) (envelope-from avg@FreeBSD.org) Message-ID: <4E241B54.8080207@FreeBSD.org> Date: Mon, 18 Jul 2011 14:39:00 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:5.0) Gecko/20110705 Thunderbird/5.0 MIME-Version: 1.0 To: John Baldwin References: <4DCD357D.6000109@FreeBSD.org> <201105170958.16847.jhb@freebsd.org> <4DD28781.6050002@FreeBSD.org> <201105171151.18038.jhb@freebsd.org> In-Reply-To: <201105171151.18038.jhb@freebsd.org> X-Enigmail-Version: 1.2pre Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: Max Laier , FreeBSD current Subject: Re: proposed smp_rendezvous change X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jul 2011 11:39:03 -0000 on 17/05/2011 18:51 John Baldwin said the following: > On Tuesday, May 17, 2011 10:34:41 am Andriy Gapon wrote: >> on 17/05/2011 16:58 John Baldwin said the following: >>> No, it doesn't quite work that way. It wouldn't work on Alpha for example. >>> >>> All load_acq is a load with a memory barrier to order other loads after it. >>> It is still free to load stale data. Only a read-modify-write operation >>> would actually block until it could access an up-to-date value. >> >> Hmm, ok. >> How about atomic_add_acq_int(&smp_rv_waiters[0], 0) ? :-) >> Or an equivalent MI action that doesn't actually change smp_rv_waiters[0] value, >> if there could be any. >> Maybe explicit atomic_cmpset_acq_int(&smp_rv_waiters[0], 0, 0) ? >> >> You see at what I am getting? > > Yeah, either of those would work. At this point just leaving the > atomic_add_int() as-is would be the smallest diff. :) Yes, atomic_add_int() for smp_rv_waiters[0] is completely OK, it's the spinwait loop on it that is a bit wasteful. And probably the extra smp_rv_waiters[] element used only for this purpose. Do you agree? Convenience link to the gmane archive of this thread: http://article.gmane.org/gmane.os.freebsd.current/132730 -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Mon Jul 18 11:42:07 2011 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 01F3B106564A for ; Mon, 18 Jul 2011 11:42:07 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 539758FC1E for ; Mon, 18 Jul 2011 11:42:05 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id OAA21828 for ; Mon, 18 Jul 2011 14:42:04 +0300 (EEST) (envelope-from avg@FreeBSD.org) Message-ID: <4E241C0C.1000604@FreeBSD.org> Date: Mon, 18 Jul 2011 14:42:04 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:5.0) Gecko/20110705 Thunderbird/5.0 MIME-Version: 1.0 To: freebsd-current@FreeBSD.org References: <4E05F2A4.6060908@FreeBSD.org> In-Reply-To: <4E05F2A4.6060908@FreeBSD.org> X-Enigmail-Version: 1.2pre Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: Subject: Re: Fwd: stop scheduler in panic context X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jul 2011 11:42:07 -0000 This is a reminder that if you would like to see the code for sane panic(9) context in 9.0, then I still need at least one independent reviewer and tester for the code. Thank you. on 25/06/2011 17:37 Andriy Gapon said the following: > > I would like to ask for testing of the following patch. > Since the patch affects panic(9) context, then obviously its testing requires > getting some sort of panic, and preferably some sort of "post-panic" activity too: > doing something in kdb, dumping a core (via debugger command or in unattended > mode), resetting a machine finally. > > At minimum I hope that no regressions are introduced. > At maximum I hope that some things are improved like, e.g., crash dump succeeding > where it failed before (PR amd64/139614). > > The patch is for recent head/CURRENT. It mostly affects SMP systems, but also has > a smaller impact on UP systems. > I can try to adapt it to stable/8, if sufficient interest arises. > Please see the following message for the patch and some more details. > > -------- Original Message -------- > > I would like to present the following diff for review and discussion: > http://people.freebsd.org/~avg/stop_scheduler_on_panic.diff > > The idea is to stop scheduler in a panic context and to provide a special > environment for the only running thread, the one that called panic(9). > > I tried to make this diff as minimal as possible, it doesn't include changes that > I consider to be useful improvements and [even] bug fixes, but which generated > controversy in non-public discussions. > > If there is no negative feedback within next few days, then I plan to post the > patch to current@ to solicit some testing. I will definitely wait for positive > feedback before committing this change. I hope that I will be able to sneak it > into the 9 release (unless there are objections to this). > > Thank you! -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Mon Jul 18 13:27:45 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6AC3A106566C for ; Mon, 18 Jul 2011 13:27:45 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 4188C8FC16 for ; Mon, 18 Jul 2011 13:27:45 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id EADBB46B0A; Mon, 18 Jul 2011 09:27:44 -0400 (EDT) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 886C98A02F; Mon, 18 Jul 2011 09:27:44 -0400 (EDT) From: John Baldwin To: Michael Butler Date: Mon, 18 Jul 2011 09:24:56 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110617; KDE/4.5.5; amd64; ; ) References: <4CE54A1B-B0EF-4907-88BE-124FC4FF236D@FreeBSD.org> <4E22EC60.2050708@protected-networks.net> In-Reply-To: <4E22EC60.2050708@protected-networks.net> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201107180924.56616.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Mon, 18 Jul 2011 09:27:44 -0400 (EDT) Cc: current@freebsd.org Subject: Re: [PATCH] Make x86 Host-PCI bridge drivers honor decoded ranges X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jul 2011 13:27:45 -0000 On Sunday, July 17, 2011 10:06:24 am Michael Butler wrote: > On 07/09/11 20:04, John Baldwin wrote: > > This patch adds a new API (pcib_host_res_*) that Host-PCI bridge drivers can > > use to restrict allocations for child devices to a known subset of address > > ranges that the bridge decodes. > > One observation from what is now in 'HEAD' .. > > isa_probe_children: disabling PnP devices > ichwd0: on isa0 > isab0: found ICH7 or equivalent chipset: Intel ICH7M watchdog timer > pcib0: allocated type 4 (0x1030-0x1037) for rid 0 of ichwd0 > pcib0: allocated type 4 (0x1060-0x107f) for rid 1 of ichwd0 > ichwd0: unable to reserve GCS registers > device_attach: ichwd0 attach returned 6 > pmtimer0 on isa0 > atkbdc: atkbdc0 already exists; skipping it > atrtc: atrtc0 already exists; skipping it > attimer: attimer0 already exists; skipping it > sc: sc0 already exists; skipping it > isa_probe_children: probing non-PnP devices > ichwd0: at port 0x1030-0x1037,0x1060-0x107f > on isa0 > isab0: found ICH7 or equivalent chipset: Intel ICH7M watchdog timer > pcib0: allocated type 4 (0x1030-0x1037) for rid 0 of ichwd0 > pcib0: allocated type 4 (0x1060-0x107f) for rid 1 of ichwd0 > ichwd0: unable to reserve GCS registers > device_attach: ichwd0 attach returned 6 > > .. where previous kernels would proceed as follows: > > isa_probe_children: disabling PnP devices > ichwd0: on isa0 > isab0: found ICH7 or equivalent chipset: Intel ICH7M watchdog timer > ichwd0: Intel ICH7M watchdog timer (ICH7 or equivalent) > ichwd0: timer disabled > pmtimer0 on isa0 > atkbdc: atkbdc0 already exists; skipping it > atrtc: atrtc0 already exists; skipping it > attimer: attimer0 already exists; skipping it > sc: sc0 already exists; skipping it > isa_probe_children: probing non-PnP devices Hmm, can you get the output of 'devinfo -r' from an old kernel? -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Mon Jul 18 16:00:43 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1316E1065670; Mon, 18 Jul 2011 16:00:43 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id DC8468FC1B; Mon, 18 Jul 2011 16:00:42 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 5ECD946B09; Mon, 18 Jul 2011 12:00:42 -0400 (EDT) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id DAD0D8A02C; Mon, 18 Jul 2011 12:00:41 -0400 (EDT) From: John Baldwin To: Alexander Best Date: Mon, 18 Jul 2011 12:00:41 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110617; KDE/4.5.5; amd64; ; ) References: <201107151343.40065.jhb@freebsd.org> <864o2mfpbv.fsf@gmail.com> <20110716120458.GA30855@freebsd.org> In-Reply-To: <20110716120458.GA30855@freebsd.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201107181200.41402.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Mon, 18 Jul 2011 12:00:41 -0400 (EDT) Cc: current@freebsd.org, Pan Tsu Subject: Re: [PATCH] Export per-thread resource usage via sysctl X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jul 2011 16:00:43 -0000 On Saturday, July 16, 2011 8:04:58 am Alexander Best wrote: > On Sat Jul 16 11, Pan Tsu wrote: > > Alexander Best writes: > > > > > On Fri Jul 15 11, John Baldwin wrote: > > >> This change exports each individual thread's resource usage via sysctl when > > >> individual threads are requested via KERN_PROC_INC_THREAD. This generally > > >> works correctly with 'top -m io' after the previous change to revert top(1) > > >> back to using KERN_PROC_PROC when threads are not enabled. There is one issue > > >> in that top doesn't necessarily DTRT when disabling/enabling threads via 'H' > > >> at runtime while in io mode. I may do some further work to clean that up. > > >> However, for just top run it will now show per-thread stats instead of > > >> duplicating the per-process stats for each thread. > > > > > > i'm not sure, if i understand what the patch is supposed to do. however after > > > applying it, and recompiling/reinstalling the kernel, 'top -mio' displays the > > > same stats for each thread of a process. if i understood you correctly, each > > > thread should have individual stats. > > > > > > i'm running r224068 on amd64 and just reinstalled 'top'. anything i am missing? > > > > FWIW, I see different numbers for a few threads of firefox-bin with top-3.8b1. > > > > http://img233.imageshack.us/img233/1570/81482202.png > > > > Which is an improvement compared to how all threads showed same numbers > > before applying the patch. > > hmmm...not here. i did the following: 'top -mio -b -H -d2 999999' and had a > look at the second output, where if found these lines: Hmm, I never saw that. However, I do need this patch to top to get consistently sane numbers (otherwise top picks one thread as the old thread for all threads causing diffs): Index: machine.c =================================================================== --- machine.c (revision 224062) +++ machine.c (working copy) @@ -235,6 +235,7 @@ static int *pcpu_cpu_states; static int compare_jid(const void *a, const void *b); static int compare_pid(const void *a, const void *b); +static int compare_tid(const void *a, const void *b); static const char *format_nice(const struct kinfo_proc *pp); static void getsysctl(const char *name, void *ptr, size_t len); static int swapmode(int *retavail, int *retfree); @@ -557,7 +558,7 @@ get_old_proc(struct kinfo_proc *pp) * cache it. */ oldpp = bsearch(&pp, previous_pref, previous_proc_count, - sizeof(*previous_pref), compare_pid); + sizeof(*previous_pref), ps.thread ? compare_tid : compare_pid); if (oldpp == NULL) { pp->ki_udata = NOPROC; return (NULL); @@ -652,7 +653,7 @@ get_process_info(struct system_info *si, struct pr previous_pref[i] = &previous_procs[i]; bcopy(pbase, previous_procs, nproc * sizeof(*previous_procs)); qsort(previous_pref, nproc, sizeof(*previous_pref), - compare_pid); + ps.thread ? compare_tid : compare_pid); } previous_proc_count = nproc; @@ -1059,6 +1060,18 @@ compare_pid(const void *p1, const void *p2) return ((*pp1)->ki_pid - (*pp2)->ki_pid); } +static int +compare_tid(const void *p1, const void *p2) +{ + const struct kinfo_proc * const *pp1 = p1; + const struct kinfo_proc * const *pp2 = p2; + + if ((*pp2)->ki_tid < 0 || (*pp1)->ki_tid < 0) + abort(); + + return ((*pp1)->ki_tid - (*pp2)->ki_tid); +} + /* * proc_compare - comparison function for "qsort" * Compares the resource consumption of two processes using five However, using this test app: #include #include #include #include #include #include #define BUFFER_LEN 16384 #define FILE_LEN (BUFFER_LEN * 128) char buffer[BUFFER_LEN]; int fd; static void * work(void *arg) { int mode = (intptr_t)arg; ssize_t result; off_t offset; static const char* names[] = { "idle", "hog", "read", "write" }; pthread_set_name_np(pthread_self(), names[mode]); offset = 0; for (;;) { switch (mode) { case 0: sleep(60); break; case 1: pthread_yield(); break; case 2: case 3: if (mode == 2) result = pread(fd, buffer, sizeof(buffer), offset); else result = pwrite(fd, buffer, sizeof(buffer), offset); if (result < 0) warn("%s", mode == 2 ? "pread" : "pwrite"); offset += sizeof(buffer); if (offset >= FILE_LEN) offset = 0; usleep(1000 * 100); break; } } return (NULL); } int main(int ac, char **av) { pthread_t thread; char template[] = "/tmp/t.XXXXXXXX"; int error, flags; fd = mkstemp(template); if (fd < 0) err(1, "mkstemp"); if (unlink(template) < 0) err(1, "unlink(%s)", template); if (ftruncate(fd, FILE_LEN) < 0) err(1, "ftruncate"); flags = fcntl(fd, F_GETFL); if (flags < 0) err(1, "fcntl(F_GETFL)"); if (fcntl(fd, F_SETFL, flags | O_DIRECT) < 0) err(1, "fcntl(F_SETFL, O_DIRECT)"); printf("PID: %ld\n", (long)getpid()); error = pthread_create(&thread, NULL, work, (void *)0); if (error) errc(1, error, "pthread_create"); /* error = pthread_create(&thread, NULL, work, (void *)1); if (error) errc(1, error, "pthread_create"); */ error = pthread_create(&thread, NULL, work, (void *)2); if (error) errc(1, error, "pthread_create"); (void)work((void *)3); return (0); } I get top output like so with this patch and the above patch applied to the latest top: PID USERNAME VCSW IVCSW READ WRITE FAULT TOTAL PERCENT COMMAND 25003 jhb 20 0 0 6 0 6 75.00% {write} 25003 jhb 21 0 1 0 0 1 12.50% {read} 25003 jhb 0 0 0 0 0 0 0.00% {idle} Without the top patch I get bogus output like so: 25003 jhb 20 0 0 0 0 0 -0.00% {write} 25003 jhb 41 5 34 -75 0 -41 33.33% {read} 25003 jhb -2326 -1 -7 -75 0 -82 66.67% {idle} -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Mon Jul 18 16:20:34 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B79A9106566B; Mon, 18 Jul 2011 16:20:34 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 740A88FC19; Mon, 18 Jul 2011 16:20:34 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 0E9BF46B2A; Mon, 18 Jul 2011 12:20:34 -0400 (EDT) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 9D2348A02C; Mon, 18 Jul 2011 12:20:33 -0400 (EDT) From: John Baldwin To: Andriy Gapon Date: Mon, 18 Jul 2011 12:20:32 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110617; KDE/4.5.5; amd64; ; ) References: <4DCD357D.6000109@FreeBSD.org> <4DCFFE52.1090002@FreeBSD.org> <4E241A33.2000009@FreeBSD.org> In-Reply-To: <4E241A33.2000009@FreeBSD.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201107181220.33052.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Mon, 18 Jul 2011 12:20:33 -0400 (EDT) Cc: Max Laier , FreeBSD current , neel@freebsd.org Subject: Re: proposed smp_rendezvous change X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jul 2011 16:20:34 -0000 On Monday, July 18, 2011 7:34:11 am Andriy Gapon wrote: > on 15/05/2011 19:24 Andriy Gapon said the following: > > on 15/05/2011 19:09 Max Laier said the following: > >> > >> I don't think we ever intended to synchronize the local teardown part, and I > >> believe that is the correct behavior for this API. > >> > >> This version is sufficiently close to what I have, so I am resonably sure that > >> it will work for us. It seems, however, that if we move to check to after > >> picking up the lock anyway, the generation approach has even less impact and I > >> am starting to prefer that solution. > >> > >> Andriy, is there any reason why you'd prefer your approach over the generation > >> version? > > > > No reason. And I even haven't said that I prefer it :-) > > I just wanted to show and explain it as apparently there was some > > misunderstanding about it. I think that generation count approach could even > > have a little bit better performance while perhaps being a tiny bit less obvious. > > Resurrecting this conversation. > Here's a link to the thread on gmane for your convenience: > http://article.gmane.org/gmane.os.freebsd.current/132682 > > It seems that we haven't fully accounted for the special case of master CPU > behavior in neither my proposed fix that added a new wait count nor in the > committed fix that has added a generation count. > This has been pointed out by kib at the recent mini-DevSummit in Kyiv. > > The problem can be illustrated by the following example: > - the teardown function is a "real" function; that is, not NULL and not > smp_rendevous_no_ barrier (sic) > - the arg parameter is a non-NULL pointer > - the teardown function actually accesses memory pointed to by the arg > - the master CPU deallocates memory pointed by the arg right after > smp_rendezvous() call returns (either via free(9) or by stack management, etc) > > Quoting the code: > MPASS(generation == smp_rv_generation); > atomic_add_int(&smp_rv_waiters[2], 1); > if (local_teardown_func != smp_no_rendevous_barrier) { > while (smp_rv_waiters[2] < smp_rv_ncpus && > generation == smp_rv_generation) > cpu_spinwait(); > > if (local_teardown_func != NULL) > local_teardown_func(local_func_arg); > } > > Generation count helps slave CPUs to not get stuck at the while loop, but it > doesn't prevent stale/different arg being passed to the teardown function. > > So here is a patch, which is a variation of my earlier proposal, that should fix > this issue: > http://people.freebsd.org/~avg/smp_rendezvous.diff > The patch is not tested yet. > > The patch undoes the smp_rv_generation change and introduces a new > smp_rv_waiters[] element. Perhaps the code could be optimized by making waiting > on smp_rv_waiters[3] conditional on some combination of values for the teardown > and the arg, but I decided to follow the KISS principle here to make the code a > little bit more robust. Yes, I prefer the more robust case actually as it is clearer. This is fine with me. It would be good to get Max's feedback and possibly Neel's as well. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Mon Jul 18 17:15:47 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 877A7106566B; Mon, 18 Jul 2011 17:15:47 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 602798FC13; Mon, 18 Jul 2011 17:15:47 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 01F1846B03; Mon, 18 Jul 2011 13:15:47 -0400 (EDT) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 8E46C8A02C; Mon, 18 Jul 2011 13:15:46 -0400 (EDT) From: John Baldwin To: freebsd-current@freebsd.org Date: Mon, 18 Jul 2011 13:08:14 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110617; KDE/4.5.5; amd64; ; ) References: <4E23EE49.5040801@FreeBSD.org> In-Reply-To: <4E23EE49.5040801@FreeBSD.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201107181308.14624.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Mon, 18 Jul 2011 13:15:46 -0400 (EDT) Cc: Doug Barton Subject: Re: ichwd0: unable to reserve GCS registers X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jul 2011 17:15:47 -0000 On Monday, July 18, 2011 4:26:49 am Doug Barton wrote: > I'm getting this with recent HEAD: > > isab0: found ICH7 or equivalent chipset: Intel ICH7M watchdog timer > ichwd0: at port 0x1030-0x1037,0x1060-0x107f > on isa0 > isab0: found ICH7 or equivalent chipset: Intel ICH7M watchdog timer > pcib0: allocated type 4 (0x1030-0x1037) for rid 0 of ichwd0 > pcib0: allocated type 4 (0x1060-0x107f) for rid 1 of ichwd0 > ichwd0: unable to reserve GCS registers > device_attach: ichwd0 attach returned 6 > pcib0: allocated type 4 (0x2f8-0x2ff) for rid 0 of uart1 Can you get devinfo -r output while booting with 'debug.acpi.disabled=hostres'? -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Mon Jul 18 20:11:14 2011 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E21BD106566C; Mon, 18 Jul 2011 20:11:14 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (tensor.andric.com [87.251.56.140]) by mx1.freebsd.org (Postfix) with ESMTP id 858A48FC15; Mon, 18 Jul 2011 20:11:14 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7:0:ad26:bb30:2166:3809] (unknown [IPv6:2001:7b8:3a7:0:ad26:bb30:2166:3809]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 4FED55C37; Mon, 18 Jul 2011 22:11:10 +0200 (CEST) Message-ID: <4E249358.7030904@FreeBSD.org> Date: Mon, 18 Jul 2011 22:11:04 +0200 From: Dimitry Andric Organization: The FreeBSD Project User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: Doug Barton References: <4E22B560.4040401@FreeBSD.org> <4E22EBC2.4070802@FreeBSD.org> <4E23E3E0.2090209@FreeBSD.org> In-Reply-To: <4E23E3E0.2090209@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD Current Subject: Re: sys/boot/i386/boot2 build failure with clang X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jul 2011 20:11:15 -0000 On 2011-07-18 09:42, Doug Barton wrote: .. > A clean /usr/obj got me all the way through buildworld to the point > where it was building the 32-bit compat libs, and got this: ... > /tmp/.root/cc-ysEysz.s:31589: Error: unknown pseudo-op: `.cfi_sections' > clang: error: assembler command failed with exit code 1 (use -v to see This should now really be fixed with r224201. Can you please confirm? :) From owner-freebsd-current@FreeBSD.ORG Mon Jul 18 22:19:45 2011 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:4f8:fff6::35]) by hub.freebsd.org (Postfix) with ESMTP id A0B4B1065674; Mon, 18 Jul 2011 22:19:45 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from 65-241-43-4.globalsuite.net (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id 9CBF014DE2B; Mon, 18 Jul 2011 22:18:55 +0000 (UTC) Message-ID: <4E24B14E.8010604@FreeBSD.org> Date: Mon, 18 Jul 2011 15:18:54 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:5.0) Gecko/20110706 Thunderbird/5.0 MIME-Version: 1.0 To: Dimitry Andric References: <4E22B560.4040401@FreeBSD.org> <4E22EBC2.4070802@FreeBSD.org> <4E23E3E0.2090209@FreeBSD.org> <4E249358.7030904@FreeBSD.org> In-Reply-To: <4E249358.7030904@FreeBSD.org> X-Enigmail-Version: 1.2pre OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: FreeBSD Current Subject: Re: sys/boot/i386/boot2 build failure with clang X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jul 2011 22:19:45 -0000 On 07/18/2011 13:11, Dimitry Andric wrote: > On 2011-07-18 09:42, Doug Barton wrote: > .. >> A clean /usr/obj got me all the way through buildworld to the point >> where it was building the 32-bit compat libs, and got this: > ... >> /tmp/.root/cc-ysEysz.s:31589: Error: unknown pseudo-op: `.cfi_sections' >> clang: error: assembler command failed with exit code 1 (use -v to see > > This should now really be fixed with r224201. Can you please confirm? :) Confirmed! Thanks. :) -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ From owner-freebsd-current@FreeBSD.ORG Mon Jul 18 22:22:36 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:4f8:fff6::35]) by hub.freebsd.org (Postfix) with ESMTP id D67F11065672; Mon, 18 Jul 2011 22:22:36 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from 65-241-43-4.globalsuite.net (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id E8DFB158DA5; Mon, 18 Jul 2011 22:22:20 +0000 (UTC) Message-ID: <4E24B21C.3070402@FreeBSD.org> Date: Mon, 18 Jul 2011 15:22:20 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:5.0) Gecko/20110706 Thunderbird/5.0 MIME-Version: 1.0 To: John Baldwin References: <4E23EE49.5040801@FreeBSD.org> <201107181308.14624.jhb@freebsd.org> In-Reply-To: <201107181308.14624.jhb@freebsd.org> X-Enigmail-Version: 1.2pre OpenPGP: id=1A1ABC84 Content-Type: multipart/mixed; boundary="------------000404020205040005070300" Cc: freebsd-current@freebsd.org Subject: Re: ichwd0: unable to reserve GCS registers X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jul 2011 22:22:37 -0000 This is a multi-part message in MIME format. --------------000404020205040005070300 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 07/18/2011 10:08, John Baldwin wrote: > On Monday, July 18, 2011 4:26:49 am Doug Barton wrote: >> I'm getting this with recent HEAD: >> >> isab0: found ICH7 or equivalent chipset: Intel ICH7M watchdog timer >> ichwd0: at port 0x1030-0x1037,0x1060-0x107f >> on isa0 >> isab0: found ICH7 or equivalent chipset: Intel ICH7M watchdog timer >> pcib0: allocated type 4 (0x1030-0x1037) for rid 0 of ichwd0 >> pcib0: allocated type 4 (0x1060-0x107f) for rid 1 of ichwd0 >> ichwd0: unable to reserve GCS registers >> device_attach: ichwd0 attach returned 6 >> pcib0: allocated type 4 (0x2f8-0x2ff) for rid 0 of uart1 > > Can you get devinfo -r output while booting with > 'debug.acpi.disabled=hostres'? I escaped to the loader prompt and type 'set debug..' and then booted. The devinfo output is attached. Doing the kldload with debug.bootverbose I now get this: isab0: found ICH7 or equivalent chipset: Intel ICH7M watchdog timer ichwd0: detached ichwd0 failed to probe at port 0x1030-0x1037,0x1060-0x107f on isa0 isab0: found ICH7 or equivalent chipset: Intel ICH7M watchdog timer ichwd0: at port 0x1030-0x1037,0x1060-0x107f on isa0 isab0: found ICH7 or equivalent chipset: Intel ICH7M watchdog timer ichwd0: Intel ICH7M watchdog timer (ICH7 or equivalent) ichwd0: timer disabled ichwd0: timer enabled ichwd0: timeout set to 28 ticks ichwd0: timer reloaded (repeats infinitely) Thanks, Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ --------------000404020205040005070300 Content-Type: text/plain; name="devinfo.ichwd" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="devinfo.ichwd" nexus0 apic0 ram0 I/O memory addresses: 0x0-0x9efff 0x100000-0x7fe813ff acpi0 Interrupt request lines: 9 I/O ports: 0x20-0x21 0x2e-0x2f 0x4e-0x4f 0x86 0x92 0xa0-0xa1 0xb2 0xb3 0x4d0-0x4d1 0x809 0x910-0x91f 0x920-0x92f 0x930-0x97f 0xc80-0xcaf 0xcbc-0xcbf 0xcc0-0xcff 0x1000-0x1005 0x1006-0x1007 0x1008-0x1059 0x1060-0x107f 0x1080-0x10bf 0x10c0-0x10df 0xf400-0xf4fe I/O memory addresses: 0x9fc00-0x9ffff 0xc0000-0xcffff 0xe0000-0xfffff 0x7fe81400-0x7fefffff 0x7ff00000-0x7fffffff 0xf0000000-0xf3ffffff 0xf4000000-0xf4003fff 0xf4004000-0xf4004fff 0xf4005000-0xf4005fff 0xf4006000-0xf4006fff 0xf4008000-0xf400bfff 0xfec00000-0xfec0ffff 0xfed20000-0xfed3ffff 0xfed45000-0xfed9ffff 0xfee00000-0xfee0ffff 0xffa80000-0xffa83fff 0xffb00000-0xffffffff cpu0 ACPI I/O ports: 0x1014 0x1016 acpi_perf0 est0 cpufreq0 coretemp0 cpu1 ACPI I/O ports: 0x1014 0x1016 acpi_perf1 est1 cpufreq1 coretemp1 acpi_acad0 battery0 battery1 acpi_lid0 acpi_button0 acpi_button1 acpi_sysresource0 pcib0 pci0 hostb0 pcib1 I/O memory addresses: 0xd0000000-0xdfffffff 0xed000000-0xefefffff pci1 vgapci0 Interrupt request lines: 16 pcib1 memory window: 0xed000000-0xedffffff 0xee000000-0xeeffffff pcib1 prefetch window: 0xd0000000-0xdfffffff vgapm0 nvidia0 hdac0 Interrupt request lines: 256 I/O memory addresses: 0xefffc000-0xefffffff pcm0 pcib2 pci11 pcib3 I/O memory addresses: 0xecf00000-0xecffffff pci12 wpi0 Interrupt request lines: 17 pcib3 memory window: 0xecfff000-0xecffffff pcib4 I/O memory addresses: 0xece00000-0xecefffff pci9 uhci0 Interrupt request lines: 20 I/O ports: 0xbf80-0xbf9f usbus0 uhub0 uhci1 Interrupt request lines: 21 I/O ports: 0xbf60-0xbf7f usbus1 uhub1 uhci2 Interrupt request lines: 22 I/O ports: 0xbf40-0xbf5f usbus2 uhub2 ums0 uhci3 Interrupt request lines: 23 I/O ports: 0xbf20-0xbf3f usbus3 uhub3 ehci0 Interrupt request lines: 20 ACPI I/O memory addresses: 0xffa80000-0xffa803ff usbus4 uhub4 uhub5 uhub6 pcib5 I/O memory addresses: 0x80000000-0x800fffff pci3 cbb0 Interrupt request lines: 18 pcib5 memory window: 0x80000000-0x80000fff cardbus0 pccard0 isab0 isa0 sc0 vga0 I/O ports: 0x3c0-0x3df I/O memory addresses: 0xa0000-0xbffff orm0 ACPI I/O memory addresses: 0xc0000-0xcffff atapci0 I/O ports: 0x170-0x177 0x1f0-0x1f7 0x376 0x3f6 0xbfa0-0xbfaf ata0 Interrupt request lines: 14 ad0 atapicam0 ata1 Interrupt request lines: 15 acd0 atapicam1 acpi_sysresource1 acpi_sysresource2 psmcpnp0 atkbdc0 Interrupt request lines: 1 I/O ports: 0x60 0x62 0x64 0x66 atkbd0 psm0 Interrupt request lines: 12 atrtc0 Interrupt request lines: 8 I/O ports: 0x70-0x71 0x72-0x77 attimer0 Interrupt request lines: 0 I/O ports: 0x40-0x43 0x50-0x53 acpi_sysresource3 atdma0 DMA request lines: 4 I/O ports: 0x0-0xf 0x10-0x1f 0x80-0x85 0x87-0x8f 0x90-0x91 0x93-0x9f 0xc0-0xdf fpupnp0 I/O ports: 0xf0-0xff hpet0 Interrupt request lines: 20 I/O memory addresses: 0xfed00000-0xfed003ff uart0 Interrupt request lines: 4 I/O ports: 0x3f8-0x3ff pci_link0 pci_link1 pci_link2 pci_link3 pci_link4 pci_link5 pci_link6 pci_link7 acpi_tz0 acpi_timer0 ACPI I/O ports: 0x1008-0x100b --------------000404020205040005070300-- From owner-freebsd-current@FreeBSD.ORG Mon Jul 18 23:18:41 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BF9D5106564A for ; Mon, 18 Jul 2011 23:18:41 +0000 (UTC) (envelope-from jjacobson@panasas.com) Received: from natasha.panasas.com (natasha.panasas.com [67.152.220.90]) by mx1.freebsd.org (Postfix) with ESMTP id 718A18FC0A for ; Mon, 18 Jul 2011 23:18:41 +0000 (UTC) Received: from seabiscuit.panasas.com (seabisbuit.panasas.com [172.17.132.204] (may be forged)) by natasha.panasas.com (8.13.1/8.13.1) with ESMTP id p6IMFNox028689 for ; Mon, 18 Jul 2011 18:15:23 -0400 Received: from sahyadri.panasas.com (172.17.132.115) by seabiscuit.int.panasas.com (172.17.132.204) with Microsoft SMTP Server (TLS) id 14.1.289.1; Mon, 18 Jul 2011 15:15:22 -0700 From: Joel Jacobson Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 18 Jul 2011 15:15:22 -0700 Message-ID: <1A67697A-B3E1-495A-B008-73694E568AD9@panasas.com> To: MIME-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: sgl (or uio) in struct buf / bio X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jul 2011 23:18:41 -0000 a few years ago (2008), i asked about the prospect of getting an sgl = passed through struct buf / bio, and was referred to the jhb_bio branch. = i never did figure out how to view it, though, and it fell off my radar = for a while. did anything ever come of it, and if so/not, are there any plans for = switching to something like using a uio instead of a pointer/length = pair? - j= From owner-freebsd-current@FreeBSD.ORG Mon Jul 18 23:21:33 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BCE8C1065704 for ; Mon, 18 Jul 2011 23:21:33 +0000 (UTC) (envelope-from mdf356@gmail.com) Received: from mail-qy0-f182.google.com (mail-qy0-f182.google.com [209.85.216.182]) by mx1.freebsd.org (Postfix) with ESMTP id 78F8D8FC1C for ; Mon, 18 Jul 2011 23:21:33 +0000 (UTC) Received: by qyk38 with SMTP id 38so2446599qyk.13 for ; Mon, 18 Jul 2011 16:21:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=oYxrmUciGncImkhxpAoOaLl4cIfBfihNqcIkajrmtLQ=; b=LR7LanijD+lRzsNDlEW1tnYtiDgYBSSwTag7Z9kNMcraVI1sWRQIOHcEPxpm4Vt+21 OFZeL9q5s/Ph21T3E6kwZ6QXVR/VbtNnskeJw7o0UumLBvL1+HrF09TeOSVZxoh+8JDz sJE3f3tMqbvD/2QNVlhLJ5E0xQ1dqE9kG8Cyc= MIME-Version: 1.0 Received: by 10.229.190.83 with SMTP id dh19mr5361072qcb.175.1311031292588; Mon, 18 Jul 2011 16:21:32 -0700 (PDT) Sender: mdf356@gmail.com Received: by 10.229.11.40 with HTTP; Mon, 18 Jul 2011 16:21:32 -0700 (PDT) In-Reply-To: <1A67697A-B3E1-495A-B008-73694E568AD9@panasas.com> References: <1A67697A-B3E1-495A-B008-73694E568AD9@panasas.com> Date: Mon, 18 Jul 2011 16:21:32 -0700 X-Google-Sender-Auth: wPxzKzVbEkMMRpuk1TB3sJxYsgk Message-ID: From: mdf@FreeBSD.org To: Joel Jacobson Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org Subject: Re: sgl (or uio) in struct buf / bio X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jul 2011 23:21:33 -0000 On Mon, Jul 18, 2011 at 3:15 PM, Joel Jacobson wrot= e: > a few years ago (2008), i asked about the prospect of getting an sgl pass= ed through struct buf / bio, and was referred to the jhb_bio branch. =A0i n= ever did figure out how to view it, though, and it fell off my radar for a = while. > > did anything ever come of it, and if so/not, are there any plans for swit= ching to something like using a uio instead of a pointer/length pair? > To the best of my knowledge, this is still something many of us would like to see done, and no one has had any time to work on. Cheers, matthew From owner-freebsd-current@FreeBSD.ORG Tue Jul 19 15:16:09 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6907E1065675; Tue, 19 Jul 2011 15:16:09 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 4193D8FC15; Tue, 19 Jul 2011 15:16:09 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id EF3D646B46; Tue, 19 Jul 2011 11:16:08 -0400 (EDT) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 8A4238A02F; Tue, 19 Jul 2011 11:16:08 -0400 (EDT) From: John Baldwin To: Doug Barton Date: Tue, 19 Jul 2011 11:16:07 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110617; KDE/4.5.5; amd64; ; ) References: <4E23EE49.5040801@FreeBSD.org> <201107181308.14624.jhb@freebsd.org> <4E24B21C.3070402@FreeBSD.org> In-Reply-To: <4E24B21C.3070402@FreeBSD.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201107191116.07116.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Tue, 19 Jul 2011 11:16:08 -0400 (EDT) Cc: freebsd-current@freebsd.org Subject: Re: ichwd0: unable to reserve GCS registers X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2011 15:16:09 -0000 On Monday, July 18, 2011 6:22:20 pm Doug Barton wrote: > On 07/18/2011 10:08, John Baldwin wrote: > > On Monday, July 18, 2011 4:26:49 am Doug Barton wrote: > >> I'm getting this with recent HEAD: > >> > >> isab0: found ICH7 or equivalent chipset: Intel ICH7M watchdog timer > >> ichwd0: at port 0x1030-0x1037,0x1060-0x107f > >> on isa0 > >> isab0: found ICH7 or equivalent chipset: Intel ICH7M watchdog timer > >> pcib0: allocated type 4 (0x1030-0x1037) for rid 0 of ichwd0 > >> pcib0: allocated type 4 (0x1060-0x107f) for rid 1 of ichwd0 > >> ichwd0: unable to reserve GCS registers > >> device_attach: ichwd0 attach returned 6 > >> pcib0: allocated type 4 (0x2f8-0x2ff) for rid 0 of uart1 > > > > Can you get devinfo -r output while booting with > > 'debug.acpi.disabled=hostres'? > > I escaped to the loader prompt and type 'set debug..' and then booted. > The devinfo output is attached. > > Doing the kldload with debug.bootverbose I now get this: > > isab0: found ICH7 or equivalent chipset: Intel ICH7M watchdog timer > ichwd0: detached > ichwd0 failed to probe at port 0x1030-0x1037,0x1060-0x107f on isa0 > isab0: found ICH7 or equivalent chipset: Intel ICH7M watchdog timer > ichwd0: at port 0x1030-0x1037,0x1060-0x107f > on isa0 > isab0: found ICH7 or equivalent chipset: Intel ICH7M watchdog timer > ichwd0: Intel ICH7M watchdog timer (ICH7 or equivalent) > ichwd0: timer disabled > ichwd0: timer enabled > ichwd0: timeout set to 28 ticks > ichwd0: timer reloaded > (repeats infinitely) Hmm, can you get devinfo -r output from a working kernel with ichwd loaded? You might be able to just build the kernel with 'nooptions NEW_PCIB'. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Tue Jul 19 19:00:27 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B4C0A106564A for ; Tue, 19 Jul 2011 19:00:27 +0000 (UTC) (envelope-from ohartman@zedat.fu-berlin.de) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) by mx1.freebsd.org (Postfix) with ESMTP id 740978FC17 for ; Tue, 19 Jul 2011 19:00:27 +0000 (UTC) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost1.zedat.fu-berlin.de (Exim 4.69) for freebsd-current@freebsd.org with esmtp (envelope-from ) id <1QjFWs-0004R6-1X>; Tue, 19 Jul 2011 21:00:26 +0200 Received: from e178038004.adsl.alicedsl.de ([85.178.38.4] helo=thor.walstatt.dyndns.org) by inpost2.zedat.fu-berlin.de (Exim 4.69) for freebsd-current@freebsd.org with esmtpsa (envelope-from ) id <1QjFWr-0002yq-Ue>; Tue, 19 Jul 2011 21:00:26 +0200 Message-ID: <4E25D444.1030506@zedat.fu-berlin.de> Date: Tue, 19 Jul 2011 21:00:20 +0200 From: "Hartmann, O." User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:5.0) Gecko/20110712 Thunderbird/5.0 MIME-Version: 1.0 To: FreeBSD Current Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: 85.178.38.4 Subject: FreeBSD 9.0 CURRENT: /usr/src/sys/modules/wlan/../../net80211/ieee80211_proto.c:1541:16: error: use of undeclared identifier 'vap' X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2011 19:00:27 -0000 FreeBSD 9.0-CURRENT/amd64 stopps building kernel with the following error in module wlan: clang -O3 -mtune=native -fno-strict-aliasing -pipe -march=native -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include /usr/obj/usr/src/sys/THOR/opt_global.h -I. -I@ -I@/contrib/altq -fno-common -fno-omit-frame-pointer -I/usr/obj/usr/src/sys/THOR -mno-aes -mno-avx -mcmodel=kernel -mno-red-zone -mno-mmx -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -std=iso9899:1999 -fstack-protector -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 -c /usr/src/sys/modules/wlan/../../net80211/ieee80211_proto.c /usr/src/sys/modules/wlan/../../net80211/ieee80211_proto.c:1541:16: error: use of undeclared identifier 'vap' TAILQ_FOREACH(vap, &ic->ic_vaps, iv_next) ^ @/sys/queue.h:521:8: note: expanded from: for ((var) = TAILQ_FIRST((head)); \ ^ /usr/src/sys/modules/wlan/../../net80211/ieee80211_proto.c:1541:16: error: use of undeclared identifier 'vap' TAILQ_FOREACH(vap, &ic->ic_vaps, iv_next) ^ @/sys/queue.h:522:7: note: expanded from: (var); \ ^ /usr/src/sys/modules/wlan/../../net80211/ieee80211_proto.c:1541:16: error: use of undeclared identifier 'vap' TAILQ_FOREACH(vap, &ic->ic_vaps, iv_next) ^ @/sys/queue.h:523:7: note: expanded from: (var) = TAILQ_NEXT((var), field)) ^ /usr/src/sys/modules/wlan/../../net80211/ieee80211_proto.c:1541:16: error: use of undeclared identifier 'vap' TAILQ_FOREACH(vap, &ic->ic_vaps, iv_next) ^ @/sys/queue.h:523:26: note: expanded from: (var) = TAILQ_NEXT((var), field)) ^ @/sys/queue.h:597:34: note: expanded from: #define TAILQ_NEXT(elm, field) ((elm)->field.tqe_next) ^ /usr/src/sys/modules/wlan/../../net80211/ieee80211_proto.c:1542:7: error: use of undeclared identifier 'vap' if (vap->iv_state == IEEE80211_S_CSA) ^ /usr/src/sys/modules/wlan/../../net80211/ieee80211_proto.c:1543:4: error: use of undeclared identifier 'vap' vap->iv_bss->ni_chan = ic->ic_curchan; ^ 6 errors generated. *** Error code 1 Stop in /usr/src/sys/modules/wlan. Regards, Oliver From owner-freebsd-current@FreeBSD.ORG Tue Jul 19 19:55:31 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C4EF7106566B; Tue, 19 Jul 2011 19:55:31 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 963258FC16; Tue, 19 Jul 2011 19:55:31 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.4) with ESMTP id p6JJtUab024313; Tue, 19 Jul 2011 15:55:30 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.4/Submit) id p6JJtUqC024203; Tue, 19 Jul 2011 19:55:30 GMT (envelope-from tinderbox@freebsd.org) Date: Tue, 19 Jul 2011 19:55:30 GMT Message-Id: <201107191955.p6JJtUqC024203@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on ia64/ia64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2011 19:55:31 -0000 TB --- 2011-07-19 18:11:29 - tinderbox 2.7 running on freebsd-current.sentex.ca TB --- 2011-07-19 18:11:29 - starting HEAD tinderbox run for ia64/ia64 TB --- 2011-07-19 18:11:29 - cleaning the object tree TB --- 2011-07-19 18:11:51 - cvsupping the source tree TB --- 2011-07-19 18:11:51 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/ia64/ia64/supfile TB --- 2011-07-19 18:12:06 - building world TB --- 2011-07-19 18:12:06 - MAKEOBJDIRPREFIX=/obj TB --- 2011-07-19 18:12:06 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-07-19 18:12:06 - TARGET=ia64 TB --- 2011-07-19 18:12:06 - TARGET_ARCH=ia64 TB --- 2011-07-19 18:12:06 - TZ=UTC TB --- 2011-07-19 18:12:06 - __MAKE_CONF=/dev/null TB --- 2011-07-19 18:12:06 - cd /src TB --- 2011-07-19 18:12:06 - /usr/bin/make -B buildworld >>> World build started on Tue Jul 19 18:12:06 UTC 2011 >>> 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 Tue Jul 19 19:39:23 UTC 2011 TB --- 2011-07-19 19:39:23 - generating LINT kernel config TB --- 2011-07-19 19:39:23 - cd /src/sys/ia64/conf TB --- 2011-07-19 19:39:23 - /usr/bin/make -B LINT TB --- 2011-07-19 19:39:23 - building LINT kernel TB --- 2011-07-19 19:39:23 - MAKEOBJDIRPREFIX=/obj TB --- 2011-07-19 19:39:23 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-07-19 19:39:23 - TARGET=ia64 TB --- 2011-07-19 19:39:23 - TARGET_ARCH=ia64 TB --- 2011-07-19 19:39:23 - TZ=UTC TB --- 2011-07-19 19:39:23 - __MAKE_CONF=/dev/null TB --- 2011-07-19 19:39:23 - cd /src TB --- 2011-07-19 19:39:23 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Tue Jul 19 19:39:23 UTC 2011 >>> 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 -O2 -pipe -fno-strict-aliasing -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/ia64/libuwx/src -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 -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -Werror /src/sys/net80211/ieee80211_output.c cc -c -O2 -pipe -fno-strict-aliasing -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/ia64/libuwx/src -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 -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -Werror /src/sys/net80211/ieee80211_phy.c cc -c -O2 -pipe -fno-strict-aliasing -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/ia64/libuwx/src -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 -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -Werror /src/sys/net80211/ieee80211_power.c cc -c -O2 -pipe -fno-strict-aliasing -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/ia64/libuwx/src -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 -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -Werror /src/sys/net80211/ieee80211_proto.c /src/sys/net80211/ieee80211_proto.c: In function 'ieee80211_csa_completeswitch': /src/sys/net80211/ieee80211_proto.c:1541: error: 'vap' undeclared (first use in this function) /src/sys/net80211/ieee80211_proto.c:1541: error: (Each undeclared identifier is reported only once /src/sys/net80211/ieee80211_proto.c:1541: error: for each function it appears in.) *** Error code 1 Stop in /obj/ia64.ia64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-07-19 19:55:29 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-07-19 19:55:29 - ERROR: failed to build lint kernel TB --- 2011-07-19 19:55:29 - 4908.39 user 924.45 system 6240.56 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-ia64-ia64.full From owner-freebsd-current@FreeBSD.ORG Tue Jul 19 21:07:17 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B4617106564A; Tue, 19 Jul 2011 21:07:17 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 85A2B8FC15; Tue, 19 Jul 2011 21:07:17 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.4) with ESMTP id p6JL7GYB099075; Tue, 19 Jul 2011 17:07:16 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.4/Submit) id p6JL7Gij099050; Tue, 19 Jul 2011 21:07:16 GMT (envelope-from tinderbox@freebsd.org) Date: Tue, 19 Jul 2011 21:07:16 GMT Message-Id: <201107192107.p6JL7Gij099050@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on sparc64/sparc64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2011 21:07:17 -0000 TB --- 2011-07-19 19:57:47 - tinderbox 2.7 running on freebsd-current.sentex.ca TB --- 2011-07-19 19:57:47 - starting HEAD tinderbox run for sparc64/sparc64 TB --- 2011-07-19 19:57:47 - cleaning the object tree TB --- 2011-07-19 19:58:02 - cvsupping the source tree TB --- 2011-07-19 19:58:02 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/sparc64/sparc64/supfile TB --- 2011-07-19 19:58:15 - building world TB --- 2011-07-19 19:58:15 - MAKEOBJDIRPREFIX=/obj TB --- 2011-07-19 19:58:15 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-07-19 19:58:15 - TARGET=sparc64 TB --- 2011-07-19 19:58:15 - TARGET_ARCH=sparc64 TB --- 2011-07-19 19:58:15 - TZ=UTC TB --- 2011-07-19 19:58:15 - __MAKE_CONF=/dev/null TB --- 2011-07-19 19:58:15 - cd /src TB --- 2011-07-19 19:58:15 - /usr/bin/make -B buildworld >>> World build started on Tue Jul 19 19:58:15 UTC 2011 >>> 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 Tue Jul 19 20:56:33 UTC 2011 TB --- 2011-07-19 20:56:33 - generating LINT kernel config TB --- 2011-07-19 20:56:33 - cd /src/sys/sparc64/conf TB --- 2011-07-19 20:56:33 - /usr/bin/make -B LINT TB --- 2011-07-19 20:56:33 - building LINT kernel TB --- 2011-07-19 20:56:33 - MAKEOBJDIRPREFIX=/obj TB --- 2011-07-19 20:56:33 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-07-19 20:56:33 - TARGET=sparc64 TB --- 2011-07-19 20:56:33 - TARGET_ARCH=sparc64 TB --- 2011-07-19 20:56:33 - TZ=UTC TB --- 2011-07-19 20:56:33 - __MAKE_CONF=/dev/null TB --- 2011-07-19 20:56:33 - cd /src TB --- 2011-07-19 20:56:33 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Tue Jul 19 20:56:33 UTC 2011 >>> 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 -O2 -pipe -fno-strict-aliasing -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 -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 -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/net80211/ieee80211_output.c cc -c -O2 -pipe -fno-strict-aliasing -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 -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 -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/net80211/ieee80211_phy.c cc -c -O2 -pipe -fno-strict-aliasing -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 -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 -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/net80211/ieee80211_power.c cc -c -O2 -pipe -fno-strict-aliasing -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 -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 -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/net80211/ieee80211_proto.c /src/sys/net80211/ieee80211_proto.c: In function 'ieee80211_csa_completeswitch': /src/sys/net80211/ieee80211_proto.c:1541: error: 'vap' undeclared (first use in this function) /src/sys/net80211/ieee80211_proto.c:1541: error: (Each undeclared identifier is reported only once /src/sys/net80211/ieee80211_proto.c:1541: error: for each function it appears in.) *** Error code 1 Stop in /obj/sparc64.sparc64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-07-19 21:07:16 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-07-19 21:07:16 - ERROR: failed to build lint kernel TB --- 2011-07-19 21:07:16 - 3314.73 user 773.34 system 4169.20 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-sparc64-sparc64.full From owner-freebsd-current@FreeBSD.ORG Tue Jul 19 21:34:33 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 592A3106564A; Tue, 19 Jul 2011 21:34:33 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 2455C8FC14; Tue, 19 Jul 2011 21:34:32 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.4) with ESMTP id p6JLYWwv004192; Tue, 19 Jul 2011 17:34:32 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.4/Submit) id p6JLYW8E004191; Tue, 19 Jul 2011 21:34:32 GMT (envelope-from tinderbox@freebsd.org) Date: Tue, 19 Jul 2011 21:34:32 GMT Message-Id: <201107192134.p6JLYW8E004191@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on powerpc64/powerpc X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2011 21:34:33 -0000 TB --- 2011-07-19 19:55:30 - tinderbox 2.7 running on freebsd-current.sentex.ca TB --- 2011-07-19 19:55:30 - starting HEAD tinderbox run for powerpc64/powerpc TB --- 2011-07-19 19:55:30 - cleaning the object tree TB --- 2011-07-19 19:55:50 - cvsupping the source tree TB --- 2011-07-19 19:55:50 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/powerpc64/powerpc/supfile TB --- 2011-07-19 19:56:03 - building world TB --- 2011-07-19 19:56:03 - MAKEOBJDIRPREFIX=/obj TB --- 2011-07-19 19:56:03 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-07-19 19:56:03 - TARGET=powerpc TB --- 2011-07-19 19:56:03 - TARGET_ARCH=powerpc64 TB --- 2011-07-19 19:56:03 - TZ=UTC TB --- 2011-07-19 19:56:03 - __MAKE_CONF=/dev/null TB --- 2011-07-19 19:56:03 - cd /src TB --- 2011-07-19 19:56:03 - /usr/bin/make -B buildworld >>> World build started on Tue Jul 19 19:56:03 UTC 2011 >>> 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 >>> stage 5.1: building 32 bit shim libraries >>> World build completed on Tue Jul 19 21:24:15 UTC 2011 TB --- 2011-07-19 21:24:15 - generating LINT kernel config TB --- 2011-07-19 21:24:15 - cd /src/sys/powerpc/conf TB --- 2011-07-19 21:24:15 - /usr/bin/make -B LINT TB --- 2011-07-19 21:24:15 - building LINT kernel TB --- 2011-07-19 21:24:15 - MAKEOBJDIRPREFIX=/obj TB --- 2011-07-19 21:24:15 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-07-19 21:24:15 - TARGET=powerpc TB --- 2011-07-19 21:24:15 - TARGET_ARCH=powerpc64 TB --- 2011-07-19 21:24:15 - TZ=UTC TB --- 2011-07-19 21:24:15 - __MAKE_CONF=/dev/null TB --- 2011-07-19 21:24:15 - cd /src TB --- 2011-07-19 21:24:15 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Tue Jul 19 21:24:15 UTC 2011 >>> 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 -O2 -pipe -fno-strict-aliasing -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 -mcall-aixdesc -ffreestanding -fstack-protector -Werror /src/sys/net80211/ieee80211_output.c cc -c -O2 -pipe -fno-strict-aliasing -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 -mcall-aixdesc -ffreestanding -fstack-protector -Werror /src/sys/net80211/ieee80211_phy.c cc -c -O2 -pipe -fno-strict-aliasing -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 -mcall-aixdesc -ffreestanding -fstack-protector -Werror /src/sys/net80211/ieee80211_power.c cc -c -O2 -pipe -fno-strict-aliasing -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 -mcall-aixdesc -ffreestanding -fstack-protector -Werror /src/sys/net80211/ieee80211_proto.c /src/sys/net80211/ieee80211_proto.c: In function 'ieee80211_csa_completeswitch': /src/sys/net80211/ieee80211_proto.c:1541: error: 'vap' undeclared (first use in this function) /src/sys/net80211/ieee80211_proto.c:1541: error: (Each undeclared identifier is reported only once /src/sys/net80211/ieee80211_proto.c:1541: error: for each function it appears in.) *** Error code 1 Stop in /obj/powerpc.powerpc64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-07-19 21:34:32 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-07-19 21:34:32 - ERROR: failed to build lint kernel TB --- 2011-07-19 21:34:32 - 4788.19 user 1113.46 system 5941.40 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-powerpc64-powerpc.full From owner-freebsd-current@FreeBSD.ORG Tue Jul 19 21:44:49 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8C5891065670; Tue, 19 Jul 2011 21:44:49 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 572888FC1A; Tue, 19 Jul 2011 21:44:49 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.4) with ESMTP id p6JLimUF025358; Tue, 19 Jul 2011 17:44:48 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.4/Submit) id p6JLim99025357; Tue, 19 Jul 2011 21:44:48 GMT (envelope-from tinderbox@freebsd.org) Date: Tue, 19 Jul 2011 21:44:48 GMT Message-Id: <201107192144.p6JLim99025357@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on powerpc/powerpc X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2011 21:44:49 -0000 TB --- 2011-07-19 19:50:53 - tinderbox 2.7 running on freebsd-current.sentex.ca TB --- 2011-07-19 19:50:53 - starting HEAD tinderbox run for powerpc/powerpc TB --- 2011-07-19 19:50:53 - cleaning the object tree TB --- 2011-07-19 19:51:10 - cvsupping the source tree TB --- 2011-07-19 19:51:10 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/powerpc/powerpc/supfile TB --- 2011-07-19 19:51:23 - building world TB --- 2011-07-19 19:51:23 - MAKEOBJDIRPREFIX=/obj TB --- 2011-07-19 19:51:23 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-07-19 19:51:23 - TARGET=powerpc TB --- 2011-07-19 19:51:23 - TARGET_ARCH=powerpc TB --- 2011-07-19 19:51:23 - TZ=UTC TB --- 2011-07-19 19:51:23 - __MAKE_CONF=/dev/null TB --- 2011-07-19 19:51:23 - cd /src TB --- 2011-07-19 19:51:23 - /usr/bin/make -B buildworld >>> World build started on Tue Jul 19 19:51:24 UTC 2011 >>> 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 Tue Jul 19 21:34:50 UTC 2011 TB --- 2011-07-19 21:34:50 - generating LINT kernel config TB --- 2011-07-19 21:34:50 - cd /src/sys/powerpc/conf TB --- 2011-07-19 21:34:50 - /usr/bin/make -B LINT TB --- 2011-07-19 21:34:50 - building LINT kernel TB --- 2011-07-19 21:34:50 - MAKEOBJDIRPREFIX=/obj TB --- 2011-07-19 21:34:50 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-07-19 21:34:50 - TARGET=powerpc TB --- 2011-07-19 21:34:50 - TARGET_ARCH=powerpc TB --- 2011-07-19 21:34:50 - TZ=UTC TB --- 2011-07-19 21:34:50 - __MAKE_CONF=/dev/null TB --- 2011-07-19 21:34:50 - cd /src TB --- 2011-07-19 21:34:50 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Tue Jul 19 21:34:50 UTC 2011 >>> 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 -O2 -pipe -fno-strict-aliasing -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/net80211/ieee80211_output.c cc -c -O2 -pipe -fno-strict-aliasing -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/net80211/ieee80211_phy.c cc -c -O2 -pipe -fno-strict-aliasing -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/net80211/ieee80211_power.c cc -c -O2 -pipe -fno-strict-aliasing -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/net80211/ieee80211_proto.c /src/sys/net80211/ieee80211_proto.c: In function 'ieee80211_csa_completeswitch': /src/sys/net80211/ieee80211_proto.c:1541: error: 'vap' undeclared (first use in this function) /src/sys/net80211/ieee80211_proto.c:1541: error: (Each undeclared identifier is reported only once /src/sys/net80211/ieee80211_proto.c:1541: error: for each function it appears in.) *** Error code 1 Stop in /obj/powerpc.powerpc/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-07-19 21:44:48 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-07-19 21:44:48 - ERROR: failed to build lint kernel TB --- 2011-07-19 21:44:48 - 5757.12 user 1008.16 system 6834.87 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-powerpc-powerpc.full From owner-freebsd-current@FreeBSD.ORG Tue Jul 19 22:33:39 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BDA8D106564A for ; Tue, 19 Jul 2011 22:33:39 +0000 (UTC) (envelope-from fidaj@ukr.net) Received: from ffe6.ukr.net (ffe6.ukr.net [195.214.192.56]) by mx1.freebsd.org (Postfix) with ESMTP id 523B58FC13 for ; Tue, 19 Jul 2011 22:33:39 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=ukr.net; s=ffe; h=Date:Message-Id:From:To:References:In-Reply-To:Subject:Cc:Content-Type:Content-Transfer-Encoding:MIME-Version; bh=9JN0gGkasfjJ7GID64x6FMEe3F+BCILa4M1NOrfDrBk=; b=mZIsueMgPax5iCJUHVTuAjqxJpnr01At/3eNBfY0dSElpjDmv7GGIAfDEReK98jmOWLhwvZvYbitNNapK+kwMEAU0m9k9FthtZuqUTQDkMt09ysMPaT0WxZAGFc0wrYJOiy6OCsgTL0wP7VNDyJOmj7iHvmug+tyPRAk7gHZCh4=; Received: from mail by ffe6.ukr.net with local ID 1QjIYK-000828-I7 ; Wed, 20 Jul 2011 01:14:08 +0300 MIME-Version: 1.0 In-Reply-To: <4E25D444.1030506@zedat.fu-berlin.de> References: <4E25D444.1030506@zedat.fu-berlin.de> To: "Hartmann, O." From: "fidaj " X-Mailer: freemail.ukr.net 4.0 X-Originating-Ip: [178.137.139.144] X-Browser: Mozilla/5.0 (X11; FreeBSD amd64; rv:5.0) Gecko/20100101 Firefox/5.0 Message-Id: Date: Wed, 20 Jul 2011 01:14:08 +0300 Content-Type: text/plain; charset="windows-1251" Content-Transfer-Encoding: binary Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: FreeBSD Current Subject: Re: FreeBSD 9.0 CURRENT: /usr/src/sys/modules/wlan/../../net80211/ieee80211_proto.c:1541:16: error: use of undeclared identifier 'vap' X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2011 22:33:39 -0000 --- Îðèã³íàëüíå ïîâ³äîìëåííÿ --- ³ä êîãî: "Hartmann, O." Êîìó: "FreeBSD Current" Äàòà: 19 ëèïíÿ 2011, 22:00:20 Òåìà: Re: FreeBSD 9.0 CURRENT: /usr/src/sys/modules/wlan/../../net80211/ieee80211_proto.c:1541:16: error: use of undeclared identifier 'vap' FreeBSD 9.0-CURRENT/amd64 stopps building kernel with the following error in module wlan: clang -O3 -mtune=native -fno-strict-aliasing -pipe -march=native -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include /usr/obj/usr/src/sys/THOR/opt_global.h -I. -I@ -I@/contrib/altq -fno-common -fno-omit-frame-pointer -I/usr/obj/usr/src/sys/THOR -mno-aes -mno-avx -mcmodel=kernel -mno-red-zone -mno-mmx -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -std=iso9899:1999 -fstack-protector -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 -c /usr/src/sys/modules/wlan/../../net80211/ieee80211_proto.c /usr/src/sys/modules/wlan/../../net80211/ieee80211_proto.c:1541:16: error: use of undeclared identifier 'vap' TAILQ_FOREACH(vap, &ic->ic_vaps, iv_next) ^ @/sys/queue.h:521:8: note: expanded from: for ((var) = TAILQ_FIRST((head)); \ ^ /usr/src/sys/modules/wlan/../../net80211/ieee80211_proto.c:1541:16: error: use of undeclared identifier 'vap' TAILQ_FOREACH(vap, &ic->ic_vaps, iv_next) ^ @/sys/queue.h:522:7: note: expanded from: (var); \ ^ /usr/src/sys/modules/wlan/../../net80211/ieee80211_proto.c:1541:16: error: use of undeclared identifier 'vap' TAILQ_FOREACH(vap, &ic->ic_vaps, iv_next) ^ @/sys/queue.h:523:7: note: expanded from: (var) = TAILQ_NEXT((var), field)) ^ /usr/src/sys/modules/wlan/../../net80211/ieee80211_proto.c:1541:16: error: use of undeclared identifier 'vap' TAILQ_FOREACH(vap, &ic->ic_vaps, iv_next) ^ @/sys/queue.h:523:26: note: expanded from: (var) = TAILQ_NEXT((var), field)) ^ @/sys/queue.h:597:34: note: expanded from: #define TAILQ_NEXT(elm, field) ((elm)->field.tqe_next) ^ /usr/src/sys/modules/wlan/../../net80211/ieee80211_proto.c:1542:7: error: use of undeclared identifier 'vap' if (vap->iv_state == IEEE80211_S_CSA) ^ /usr/src/sys/modules/wlan/../../net80211/ieee80211_proto.c:1543:4: error: use of undeclared identifier 'vap' vap->iv_bss->ni_chan = ic->ic_curchan; ^ 6 errors generated. *** Error code 1 Stop in /usr/src/sys/modules/wlan. Regards, Oliver _______________________________________________ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to " freebsd-current-unsubscribe@freebsd.org " --- ieee80211_proto.c.orig 2011-07-20 01:06:17.000000000 +0300 +++ ieee80211_proto.c 2011-07-20 01:10:54.000000000 +0300 @@ -1533,6 +1533,8 @@ void ieee80211_csa_completeswitch(struct ieee80211com *ic) { + struct ieee80211vap *vap; + IEEE80211_LOCK_ASSERT(ic); KASSERT(ic->ic_flags & IEEE80211_F_CSAPENDING, ("csa not pending")); From owner-freebsd-current@FreeBSD.ORG Tue Jul 19 22:47:36 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6E09B106564A; Tue, 19 Jul 2011 22:47:36 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 395A28FC08; Tue, 19 Jul 2011 22:47:35 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.4) with ESMTP id p6JMlZP1015091; Tue, 19 Jul 2011 18:47:35 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.4/Submit) id p6JMlZoV015087; Tue, 19 Jul 2011 22:47:35 GMT (envelope-from tinderbox@freebsd.org) Date: Tue, 19 Jul 2011 22:47:35 GMT Message-Id: <201107192247.p6JMlZoV015087@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on arm/arm X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2011 22:47:36 -0000 TB --- 2011-07-19 21:50:00 - tinderbox 2.7 running on freebsd-current.sentex.ca TB --- 2011-07-19 21:50:00 - starting HEAD tinderbox run for arm/arm TB --- 2011-07-19 21:50:00 - cleaning the object tree TB --- 2011-07-19 21:50:37 - cvsupping the source tree TB --- 2011-07-19 21:50:38 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/arm/arm/supfile TB --- 2011-07-19 21:50:58 - building world TB --- 2011-07-19 21:50:58 - MAKEOBJDIRPREFIX=/obj TB --- 2011-07-19 21:50:58 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-07-19 21:50:58 - TARGET=arm TB --- 2011-07-19 21:50:58 - TARGET_ARCH=arm TB --- 2011-07-19 21:50:58 - TZ=UTC TB --- 2011-07-19 21:50:58 - __MAKE_CONF=/dev/null TB --- 2011-07-19 21:50:58 - cd /src TB --- 2011-07-19 21:50:58 - /usr/bin/make -B buildworld >>> World build started on Tue Jul 19 21:50:59 UTC 2011 >>> 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 Tue Jul 19 22:45:33 UTC 2011 TB --- 2011-07-19 22:45:33 - WARNING: no kernel config for LINT TB --- 2011-07-19 22:45:33 - cd /src/sys/arm/conf TB --- 2011-07-19 22:45:33 - /usr/sbin/config -m AVILA TB --- 2011-07-19 22:45:33 - building AVILA kernel TB --- 2011-07-19 22:45:33 - MAKEOBJDIRPREFIX=/obj TB --- 2011-07-19 22:45:33 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-07-19 22:45:33 - TARGET=arm TB --- 2011-07-19 22:45:33 - TARGET_ARCH=arm TB --- 2011-07-19 22:45:33 - TZ=UTC TB --- 2011-07-19 22:45:33 - __MAKE_CONF=/dev/null TB --- 2011-07-19 22:45:33 - cd /src TB --- 2011-07-19 22:45:33 - /usr/bin/make -B buildkernel KERNCONF=AVILA >>> Kernel build for AVILA started on Tue Jul 19 22:45:33 UTC 2011 >>> 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 -mbig-endian -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 -mcpu=xscale -ffreestanding -Werror /src/sys/net80211/ieee80211_output.c cc -mbig-endian -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 -mcpu=xscale -ffreestanding -Werror /src/sys/net80211/ieee80211_phy.c cc -mbig-endian -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 -mcpu=xscale -ffreestanding -Werror /src/sys/net80211/ieee80211_power.c cc -mbig-endian -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 -mcpu=xscale -ffreestanding -Werror /src/sys/net80211/ieee80211_proto.c /src/sys/net80211/ieee80211_proto.c: In function 'ieee80211_csa_completeswitch': /src/sys/net80211/ieee80211_proto.c:1541: error: 'vap' undeclared (first use in this function) /src/sys/net80211/ieee80211_proto.c:1541: error: (Each undeclared identifier is reported only once /src/sys/net80211/ieee80211_proto.c:1541: error: for each function it appears in.) *** Error code 1 Stop in /obj/arm.arm/src/sys/AVILA. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-07-19 22:47:34 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-07-19 22:47:34 - ERROR: failed to build AVILA kernel TB --- 2011-07-19 22:47:34 - 2434.17 user 732.32 system 3453.67 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-arm-arm.full From owner-freebsd-current@FreeBSD.ORG Wed Jul 20 00:03:42 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3AD56106564A; Wed, 20 Jul 2011 00:03:42 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id B484D8FC0A; Wed, 20 Jul 2011 00:03:41 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.4) with ESMTP id p6K03eEZ053423; Tue, 19 Jul 2011 20:03:40 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.4/Submit) id p6K03eof053389; Wed, 20 Jul 2011 00:03:40 GMT (envelope-from tinderbox@freebsd.org) Date: Wed, 20 Jul 2011 00:03:40 GMT Message-Id: <201107200003.p6K03eof053389@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on i386/pc98 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jul 2011 00:03:42 -0000 TB --- 2011-07-19 21:50:00 - tinderbox 2.7 running on freebsd-current.sentex.ca TB --- 2011-07-19 21:50:00 - starting HEAD tinderbox run for i386/pc98 TB --- 2011-07-19 21:50:00 - cleaning the object tree TB --- 2011-07-19 21:50:40 - cvsupping the source tree TB --- 2011-07-19 21:50:40 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/i386/pc98/supfile TB --- 2011-07-19 21:50:58 - building world TB --- 2011-07-19 21:50:58 - MAKEOBJDIRPREFIX=/obj TB --- 2011-07-19 21:50:58 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-07-19 21:50:58 - TARGET=pc98 TB --- 2011-07-19 21:50:58 - TARGET_ARCH=i386 TB --- 2011-07-19 21:50:58 - TZ=UTC TB --- 2011-07-19 21:50:58 - __MAKE_CONF=/dev/null TB --- 2011-07-19 21:50:58 - cd /src TB --- 2011-07-19 21:50:58 - /usr/bin/make -B buildworld >>> World build started on Tue Jul 19 21:50:59 UTC 2011 >>> 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 Tue Jul 19 23:52:01 UTC 2011 TB --- 2011-07-19 23:52:02 - generating LINT kernel config TB --- 2011-07-19 23:52:02 - cd /src/sys/pc98/conf TB --- 2011-07-19 23:52:02 - /usr/bin/make -B LINT TB --- 2011-07-19 23:52:02 - building LINT kernel TB --- 2011-07-19 23:52:02 - MAKEOBJDIRPREFIX=/obj TB --- 2011-07-19 23:52:02 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-07-19 23:52:02 - TARGET=pc98 TB --- 2011-07-19 23:52:02 - TARGET_ARCH=i386 TB --- 2011-07-19 23:52:02 - TZ=UTC TB --- 2011-07-19 23:52:02 - __MAKE_CONF=/dev/null TB --- 2011-07-19 23:52:02 - cd /src TB --- 2011-07-19 23:52:02 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Tue Jul 19 23:52:02 UTC 2011 >>> 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 -O2 -pipe -fno-strict-aliasing -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 -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 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-sse -mno-mmx -msoft-float -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/net80211/ieee80211_output.c cc -c -O2 -pipe -fno-strict-aliasing -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 -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 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-sse -mno-mmx -msoft-float -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/net80211/ieee80211_phy.c cc -c -O2 -pipe -fno-strict-aliasing -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 -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 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-sse -mno-mmx -msoft-float -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/net80211/ieee80211_power.c cc -c -O2 -pipe -fno-strict-aliasing -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 -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 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-sse -mno-mmx -msoft-float -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/net80211/ieee80211_proto.c /src/sys/net80211/ieee80211_proto.c: In function 'ieee80211_csa_completeswitch': /src/sys/net80211/ieee80211_proto.c:1541: error: 'vap' undeclared (first use in this function) /src/sys/net80211/ieee80211_proto.c:1541: error: (Each undeclared identifier is reported only once /src/sys/net80211/ieee80211_proto.c:1541: error: for each function it appears in.) *** Error code 1 Stop in /obj/pc98.i386/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-07-20 00:03:39 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-07-20 00:03:39 - ERROR: failed to build lint kernel TB --- 2011-07-20 00:03:40 - 6324.91 user 1163.61 system 8019.01 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-i386-pc98.full From owner-freebsd-current@FreeBSD.ORG Wed Jul 20 00:11:58 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E9262106564A; Wed, 20 Jul 2011 00:11:58 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id A34728FC0A; Wed, 20 Jul 2011 00:11:58 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.4) with ESMTP id p6K0Bv3j004277; Tue, 19 Jul 2011 20:11:57 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.4/Submit) id p6K0BvrT004276; Wed, 20 Jul 2011 00:11:57 GMT (envelope-from tinderbox@freebsd.org) Date: Wed, 20 Jul 2011 00:11:57 GMT Message-Id: <201107200011.p6K0BvrT004276@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on i386/i386 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jul 2011 00:11:59 -0000 TB --- 2011-07-19 21:50:00 - tinderbox 2.7 running on freebsd-current.sentex.ca TB --- 2011-07-19 21:50:00 - starting HEAD tinderbox run for i386/i386 TB --- 2011-07-19 21:50:00 - cleaning the object tree TB --- 2011-07-19 21:50:49 - cvsupping the source tree TB --- 2011-07-19 21:50:49 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/i386/i386/supfile TB --- 2011-07-19 21:56:14 - building world TB --- 2011-07-19 21:56:14 - MAKEOBJDIRPREFIX=/obj TB --- 2011-07-19 21:56:14 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-07-19 21:56:14 - TARGET=i386 TB --- 2011-07-19 21:56:14 - TARGET_ARCH=i386 TB --- 2011-07-19 21:56:14 - TZ=UTC TB --- 2011-07-19 21:56:14 - __MAKE_CONF=/dev/null TB --- 2011-07-19 21:56:14 - cd /src TB --- 2011-07-19 21:56:14 - /usr/bin/make -B buildworld >>> World build started on Tue Jul 19 21:56:14 UTC 2011 >>> 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 Tue Jul 19 23:58:10 UTC 2011 TB --- 2011-07-19 23:58:10 - generating LINT kernel config TB --- 2011-07-19 23:58:10 - cd /src/sys/i386/conf TB --- 2011-07-19 23:58:10 - /usr/bin/make -B LINT TB --- 2011-07-19 23:58:11 - building LINT kernel TB --- 2011-07-19 23:58:11 - MAKEOBJDIRPREFIX=/obj TB --- 2011-07-19 23:58:11 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-07-19 23:58:11 - TARGET=i386 TB --- 2011-07-19 23:58:11 - TARGET_ARCH=i386 TB --- 2011-07-19 23:58:11 - TZ=UTC TB --- 2011-07-19 23:58:11 - __MAKE_CONF=/dev/null TB --- 2011-07-19 23:58:11 - cd /src TB --- 2011-07-19 23:58:11 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Tue Jul 19 23:58:11 UTC 2011 >>> 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 -O2 -pipe -fno-strict-aliasing -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 -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 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-sse -mno-mmx -msoft-float -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/net80211/ieee80211_output.c cc -c -O2 -pipe -fno-strict-aliasing -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 -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 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-sse -mno-mmx -msoft-float -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/net80211/ieee80211_phy.c cc -c -O2 -pipe -fno-strict-aliasing -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 -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 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-sse -mno-mmx -msoft-float -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/net80211/ieee80211_power.c cc -c -O2 -pipe -fno-strict-aliasing -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 -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 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-sse -mno-mmx -msoft-float -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/net80211/ieee80211_proto.c /src/sys/net80211/ieee80211_proto.c: In function 'ieee80211_csa_completeswitch': /src/sys/net80211/ieee80211_proto.c:1541: error: 'vap' undeclared (first use in this function) /src/sys/net80211/ieee80211_proto.c:1541: error: (Each undeclared identifier is reported only once /src/sys/net80211/ieee80211_proto.c:1541: error: for each function it appears in.) *** Error code 1 Stop in /obj/i386.i386/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-07-20 00:11:57 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-07-20 00:11:57 - ERROR: failed to build lint kernel TB --- 2011-07-20 00:11:57 - 6472.74 user 1161.91 system 8516.41 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-i386-i386.full From owner-freebsd-current@FreeBSD.ORG Wed Jul 20 00:30:12 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A9E011065675; Wed, 20 Jul 2011 00:30:12 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 75FCA8FC13; Wed, 20 Jul 2011 00:30:12 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.4) with ESMTP id p6K0UBbt066237; Tue, 19 Jul 2011 20:30:11 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.4/Submit) id p6K0UB2j066224; Wed, 20 Jul 2011 00:30:11 GMT (envelope-from tinderbox@freebsd.org) Date: Wed, 20 Jul 2011 00:30:11 GMT Message-Id: <201107200030.p6K0UB2j066224@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on ia64/ia64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jul 2011 00:30:12 -0000 TB --- 2011-07-19 22:47:35 - tinderbox 2.7 running on freebsd-current.sentex.ca TB --- 2011-07-19 22:47:35 - starting HEAD tinderbox run for ia64/ia64 TB --- 2011-07-19 22:47:35 - cleaning the object tree TB --- 2011-07-19 22:47:48 - cvsupping the source tree TB --- 2011-07-19 22:47:48 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/ia64/ia64/supfile TB --- 2011-07-19 22:48:00 - building world TB --- 2011-07-19 22:48:00 - MAKEOBJDIRPREFIX=/obj TB --- 2011-07-19 22:48:00 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-07-19 22:48:00 - TARGET=ia64 TB --- 2011-07-19 22:48:00 - TARGET_ARCH=ia64 TB --- 2011-07-19 22:48:00 - TZ=UTC TB --- 2011-07-19 22:48:00 - __MAKE_CONF=/dev/null TB --- 2011-07-19 22:48:00 - cd /src TB --- 2011-07-19 22:48:00 - /usr/bin/make -B buildworld >>> World build started on Tue Jul 19 22:48:01 UTC 2011 >>> 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 Wed Jul 20 00:14:17 UTC 2011 TB --- 2011-07-20 00:14:17 - generating LINT kernel config TB --- 2011-07-20 00:14:17 - cd /src/sys/ia64/conf TB --- 2011-07-20 00:14:17 - /usr/bin/make -B LINT TB --- 2011-07-20 00:14:17 - building LINT kernel TB --- 2011-07-20 00:14:17 - MAKEOBJDIRPREFIX=/obj TB --- 2011-07-20 00:14:17 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-07-20 00:14:17 - TARGET=ia64 TB --- 2011-07-20 00:14:17 - TARGET_ARCH=ia64 TB --- 2011-07-20 00:14:17 - TZ=UTC TB --- 2011-07-20 00:14:17 - __MAKE_CONF=/dev/null TB --- 2011-07-20 00:14:17 - cd /src TB --- 2011-07-20 00:14:17 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Wed Jul 20 00:14:17 UTC 2011 >>> 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 -O2 -pipe -fno-strict-aliasing -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/ia64/libuwx/src -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 -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -Werror /src/sys/net80211/ieee80211_output.c cc -c -O2 -pipe -fno-strict-aliasing -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/ia64/libuwx/src -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 -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -Werror /src/sys/net80211/ieee80211_phy.c cc -c -O2 -pipe -fno-strict-aliasing -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/ia64/libuwx/src -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 -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -Werror /src/sys/net80211/ieee80211_power.c cc -c -O2 -pipe -fno-strict-aliasing -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/ia64/libuwx/src -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 -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -Werror /src/sys/net80211/ieee80211_proto.c /src/sys/net80211/ieee80211_proto.c: In function 'ieee80211_csa_completeswitch': /src/sys/net80211/ieee80211_proto.c:1541: error: 'vap' undeclared (first use in this function) /src/sys/net80211/ieee80211_proto.c:1541: error: (Each undeclared identifier is reported only once /src/sys/net80211/ieee80211_proto.c:1541: error: for each function it appears in.) *** Error code 1 Stop in /obj/ia64.ia64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-07-20 00:30:11 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-07-20 00:30:11 - ERROR: failed to build lint kernel TB --- 2011-07-20 00:30:11 - 4871.40 user 911.83 system 6155.70 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-ia64-ia64.full From owner-freebsd-current@FreeBSD.ORG Wed Jul 20 00:35:53 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0D5C5106566B; Wed, 20 Jul 2011 00:35:53 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id D44E68FC0C; Wed, 20 Jul 2011 00:35:52 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.4) with ESMTP id p6K0Zq3q030081; Tue, 19 Jul 2011 20:35:52 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.4/Submit) id p6K0Zqad030071; Wed, 20 Jul 2011 00:35:52 GMT (envelope-from tinderbox@freebsd.org) Date: Wed, 20 Jul 2011 00:35:52 GMT Message-Id: <201107200035.p6K0Zqad030071@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on amd64/amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jul 2011 00:35:53 -0000 TB --- 2011-07-19 21:50:00 - tinderbox 2.7 running on freebsd-current.sentex.ca TB --- 2011-07-19 21:50:00 - starting HEAD tinderbox run for amd64/amd64 TB --- 2011-07-19 21:50:00 - cleaning the object tree TB --- 2011-07-19 21:50:48 - cvsupping the source tree TB --- 2011-07-19 21:50:48 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/amd64/amd64/supfile TB --- 2011-07-19 21:51:01 - building world TB --- 2011-07-19 21:51:01 - MAKEOBJDIRPREFIX=/obj TB --- 2011-07-19 21:51:01 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-07-19 21:51:01 - TARGET=amd64 TB --- 2011-07-19 21:51:01 - TARGET_ARCH=amd64 TB --- 2011-07-19 21:51:01 - TZ=UTC TB --- 2011-07-19 21:51:01 - __MAKE_CONF=/dev/null TB --- 2011-07-19 21:51:01 - cd /src TB --- 2011-07-19 21:51:01 - /usr/bin/make -B buildworld >>> World build started on Tue Jul 19 21:51:02 UTC 2011 >>> 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 >>> stage 5.1: building 32 bit shim libraries >>> World build completed on Wed Jul 20 00:23:10 UTC 2011 TB --- 2011-07-20 00:23:10 - generating LINT kernel config TB --- 2011-07-20 00:23:10 - cd /src/sys/amd64/conf TB --- 2011-07-20 00:23:10 - /usr/bin/make -B LINT TB --- 2011-07-20 00:23:10 - building LINT kernel TB --- 2011-07-20 00:23:10 - MAKEOBJDIRPREFIX=/obj TB --- 2011-07-20 00:23:10 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-07-20 00:23:10 - TARGET=amd64 TB --- 2011-07-20 00:23:10 - TARGET_ARCH=amd64 TB --- 2011-07-20 00:23:10 - TZ=UTC TB --- 2011-07-20 00:23:10 - __MAKE_CONF=/dev/null TB --- 2011-07-20 00:23:10 - cd /src TB --- 2011-07-20 00:23:10 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Wed Jul 20 00:23:10 UTC 2011 >>> 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 -O2 -frename-registers -pipe -fno-strict-aliasing -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 -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 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mno-sse -mcmodel=kernel -mno-red-zone -mno-mmx -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/net80211/ieee80211_output.c cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -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 -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 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mno-sse -mcmodel=kernel -mno-red-zone -mno-mmx -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/net80211/ieee80211_phy.c cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -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 -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 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mno-sse -mcmodel=kernel -mno-red-zone -mno-mmx -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/net80211/ieee80211_power.c cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -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 -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 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mno-sse -mcmodel=kernel -mno-red-zone -mno-mmx -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/net80211/ieee80211_proto.c /src/sys/net80211/ieee80211_proto.c: In function 'ieee80211_csa_completeswitch': /src/sys/net80211/ieee80211_proto.c:1541: error: 'vap' undeclared (first use in this function) /src/sys/net80211/ieee80211_proto.c:1541: error: (Each undeclared identifier is reported only once /src/sys/net80211/ieee80211_proto.c:1541: error: for each function it appears in.) *** Error code 1 Stop in /obj/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-07-20 00:35:51 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-07-20 00:35:51 - ERROR: failed to build lint kernel TB --- 2011-07-20 00:35:51 - 7791.32 user 1519.26 system 9950.78 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-amd64-amd64.full From owner-freebsd-current@FreeBSD.ORG Wed Jul 20 00:48:41 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E03661065673 for ; Wed, 20 Jul 2011 00:48:41 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-gw0-f54.google.com (mail-gw0-f54.google.com [74.125.83.54]) by mx1.freebsd.org (Postfix) with ESMTP id 9D8078FC08 for ; Wed, 20 Jul 2011 00:48:41 +0000 (UTC) Received: by gwb15 with SMTP id 15so304716gwb.13 for ; Tue, 19 Jul 2011 17:48:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=2LXGJfyN/lGm5IJ0VCZqKZxUdkHkIs+39Of5GCe6doY=; b=if8wamCL8kYo1NyncplQQZ5bRCF3K39co42Wey2WOmLOxZXEhnMaHGNLUtL5QOFKTN pZbSlf5xuIDA+bLesXAeSHj55VgyEKUD14grBSFBk9bfcFCFDuAI0D4Y4IOpAADbT2ku NT2YekpQm/RSe9oQYppm1z24cLZPqVuyynLnU= MIME-Version: 1.0 Received: by 10.150.68.35 with SMTP id q35mr7270625yba.443.1311122919694; Tue, 19 Jul 2011 17:48:39 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.150.197.5 with HTTP; Tue, 19 Jul 2011 17:48:39 -0700 (PDT) In-Reply-To: References: <4E25D444.1030506@zedat.fu-berlin.de> Date: Wed, 20 Jul 2011 08:48:39 +0800 X-Google-Sender-Auth: TdTrU2hBNm11CjeNOJ1mtxBGgB0 Message-ID: From: Adrian Chadd To: fidaj Content-Type: text/plain; charset=KOI8-U Content-Transfer-Encoding: quoted-printable Cc: FreeBSD Current , "Hartmann, O." Subject: Re: FreeBSD 9.0 CURRENT: /usr/src/sys/modules/wlan/../../net80211/ieee80211_proto.c:1541:16: error: use of undeclared identifier 'vap' X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jul 2011 00:48:42 -0000 just committed that. Sorry, I thought that version of the patch had compiled right. Sorry ;( adrian 2011/7/20 fidaj : > =9A --- =EF=D2=C9=C7=A6=CE=C1=CC=D8=CE=C5 =D0=CF=D7=A6=C4=CF=CD=CC=C5=CE= =CE=D1 --- > =9A =F7=A6=C4 =CB=CF=C7=CF: "Hartmann, O." > =9A =EB=CF=CD=D5: "FreeBSD Current" > =9A =E4=C1=D4=C1: 19 =CC=C9=D0=CE=D1 2011, 22:00:20 > =9A =F4=C5=CD=C1: Re: FreeBSD 9.0 CURRENT: > =9A /usr/src/sys/modules/wlan/../../net80211/ieee80211_proto.c:1541:16: > =9A error: use of undeclared identifier 'vap' > > > > =9A =9A FreeBSD 9.0-CURRENT/amd64 stopps building kernel with the followi= ng > =9A =9A error in module wlan: > > > > =9A =9A clang -O3 -mtune=3Dnative -fno-strict-aliasing -pipe -march=3Dnat= ive > =9A =9A -D_KERNEL -DKLD_MODULE -nostdinc =9A -DHAVE_KERNEL_OPTION_HEADERS= -include > =9A =9A /usr/obj/usr/src/sys/THOR/opt_global.h -I. -I@ -I@/contrib/altq > =9A =9A -fno-common =9A-fno-omit-frame-pointer -I/usr/obj/usr/src/sys/THO= R > =9A =9A -mno-aes -mno-avx -mcmodel=3Dkernel -mno-red-zone -mno-mmx -msoft= -float > =9A =9A -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector > =9A =9A -std=3Diso9899:1999 -fstack-protector -Wall -Wredundant-decls > =9A =9A -Wnested-externs -Wstrict-prototypes =9A-Wmissing-prototypes > =9A =9A -Wpointer-arith -Winline -Wcast-qual =9A-Wundef -Wno-pointer-sign > =9A =9A -fformat-extensions =9A-Wmissing-include-dirs -fdiagnostics-show-= option -c > =9A =9A /usr/src/sys/modules/wlan/../../net80211/ieee80211_proto.c > =9A =9A /usr/src/sys/modules/wlan/../../net80211/ieee80211_proto.c:1541:1= 6: > =9A =9A error: use of undeclared identifier 'vap' > =9A =9A =9A =9A =9A =9A =9ATAILQ_FOREACH(vap, &ic->ic_vaps, iv_next) > =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A^ > =9A =9A @/sys/queue.h:521:8: note: expanded from: > =9A =9A =9A =9A =9A =9A =9Afor ((var) =3D TAILQ_FIRST((head)); =9A =9A = =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A \ > =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A^ > =9A =9A /usr/src/sys/modules/wlan/../../net80211/ieee80211_proto.c:1541:1= 6: > =9A =9A error: use of undeclared identifier 'vap' > =9A =9A =9A =9A =9A =9A =9ATAILQ_FOREACH(vap, &ic->ic_vaps, iv_next) > =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A^ > =9A =9A @/sys/queue.h:522:7: note: expanded from: > =9A =9A =9A =9A =9A =9A =9A =9A =9A(var); =9A =9A =9A =9A =9A =9A =9A =9A= =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A = =9A\ > =9A =9A =9A =9A =9A =9A =9A =9A =9A ^ > =9A =9A /usr/src/sys/modules/wlan/../../net80211/ieee80211_proto.c:1541:1= 6: > =9A =9A error: use of undeclared identifier 'vap' > =9A =9A =9A =9A =9A =9A =9ATAILQ_FOREACH(vap, &ic->ic_vaps, iv_next) > =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A^ > =9A =9A @/sys/queue.h:523:7: note: expanded from: > =9A =9A =9A =9A =9A =9A =9A =9A =9A(var) =3D TAILQ_NEXT((var), field)) > =9A =9A =9A =9A =9A =9A =9A =9A =9A ^ > =9A =9A /usr/src/sys/modules/wlan/../../net80211/ieee80211_proto.c:1541:1= 6: > =9A =9A error: use of undeclared identifier 'vap' > =9A =9A =9A =9A =9A =9A =9ATAILQ_FOREACH(vap, &ic->ic_vaps, iv_next) > =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A^ > =9A =9A @/sys/queue.h:523:26: note: expanded from: > =9A =9A =9A =9A =9A =9A =9A =9A =9A(var) =3D TAILQ_NEXT((var), field)) > =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A = =9A^ > =9A =9A @/sys/queue.h:597:34: note: expanded from: > =9A =9A #define TAILQ_NEXT(elm, field) ((elm)->field.tqe_next) > =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A = =9A ^ > =9A =9A /usr/src/sys/modules/wlan/../../net80211/ieee80211_proto.c:1542:7= : > =9A =9A error: use of undeclared identifier 'vap' > =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9Aif (vap->iv_state =3D=3D IEEE8= 0211_S_CSA) > =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A^ > =9A =9A /usr/src/sys/modules/wlan/../../net80211/ieee80211_proto.c:1543:4= : > =9A =9A error: use of undeclared identifier 'vap' > =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9Avap->iv_bss->n= i_chan =3D ic->ic_curchan; > =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A^ > =9A =9A 6 errors generated. > =9A =9A *** Error code 1 > > =9A =9A Stop in /usr/src/sys/modules/wlan. > > > > =9A =9A Regards, > =9A =9A Oliver > > =9A =9A _______________________________________________ =9A =9A freebsd-c= urrent@freebsd.org =9A =9A =9Amailing list =9A =9A http://lists.freebsd.org= /mailman/listinfo/freebsd-current =9A =9A To unsubscribe, send any mail to = " =9A =9A freebsd-current-unsubscribe@freebsd.org =9A =9A " > > > > =9A --- ieee80211_proto.c.orig =9A =9A2011-07-20 01:06:17.000000000 +0300 > =9A +++ ieee80211_proto.c =9A =9A2011-07-20 01:10:54.000000000 +0300 > =9A @@ -1533,6 +1533,8 @@ > =9A =9Avoid > =9A =9Aieee80211_csa_completeswitch(struct ieee80211com *ic) > =9A =9A{ > =9A + =9A =9Astruct ieee80211vap *vap; > =9A + > =9A IEEE80211_LOCK_ASSERT(ic); > > =9A KASSERT(ic->ic_flags & IEEE80211_F_CSAPENDING, ("csa not pending")); > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org= " > From owner-freebsd-current@FreeBSD.ORG Wed Jul 20 01:47:08 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 46253106566B; Wed, 20 Jul 2011 01:47:08 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 124248FC15; Wed, 20 Jul 2011 01:47:07 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.4) with ESMTP id p6K1l74T084780; Tue, 19 Jul 2011 21:47:07 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.4/Submit) id p6K1l7C6084747; Wed, 20 Jul 2011 01:47:07 GMT (envelope-from tinderbox@freebsd.org) Date: Wed, 20 Jul 2011 01:47:07 GMT Message-Id: <201107200147.p6K1l7C6084747@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on sparc64/sparc64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jul 2011 01:47:08 -0000 TB --- 2011-07-20 00:35:52 - tinderbox 2.7 running on freebsd-current.sentex.ca TB --- 2011-07-20 00:35:52 - starting HEAD tinderbox run for sparc64/sparc64 TB --- 2011-07-20 00:35:52 - cleaning the object tree TB --- 2011-07-20 00:36:04 - cvsupping the source tree TB --- 2011-07-20 00:36:04 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/sparc64/sparc64/supfile TB --- 2011-07-20 00:36:18 - building world TB --- 2011-07-20 00:36:18 - MAKEOBJDIRPREFIX=/obj TB --- 2011-07-20 00:36:18 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-07-20 00:36:18 - TARGET=sparc64 TB --- 2011-07-20 00:36:18 - TARGET_ARCH=sparc64 TB --- 2011-07-20 00:36:18 - TZ=UTC TB --- 2011-07-20 00:36:18 - __MAKE_CONF=/dev/null TB --- 2011-07-20 00:36:18 - cd /src TB --- 2011-07-20 00:36:18 - /usr/bin/make -B buildworld >>> World build started on Wed Jul 20 00:36:19 UTC 2011 >>> 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 Wed Jul 20 01:36:25 UTC 2011 TB --- 2011-07-20 01:36:25 - generating LINT kernel config TB --- 2011-07-20 01:36:25 - cd /src/sys/sparc64/conf TB --- 2011-07-20 01:36:25 - /usr/bin/make -B LINT TB --- 2011-07-20 01:36:25 - building LINT kernel TB --- 2011-07-20 01:36:25 - MAKEOBJDIRPREFIX=/obj TB --- 2011-07-20 01:36:25 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-07-20 01:36:25 - TARGET=sparc64 TB --- 2011-07-20 01:36:25 - TARGET_ARCH=sparc64 TB --- 2011-07-20 01:36:25 - TZ=UTC TB --- 2011-07-20 01:36:25 - __MAKE_CONF=/dev/null TB --- 2011-07-20 01:36:25 - cd /src TB --- 2011-07-20 01:36:25 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Wed Jul 20 01:36:25 UTC 2011 >>> 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 -O2 -pipe -fno-strict-aliasing -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 -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 -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/net80211/ieee80211_output.c cc -c -O2 -pipe -fno-strict-aliasing -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 -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 -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/net80211/ieee80211_phy.c cc -c -O2 -pipe -fno-strict-aliasing -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 -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 -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/net80211/ieee80211_power.c cc -c -O2 -pipe -fno-strict-aliasing -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 -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 -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/net80211/ieee80211_proto.c /src/sys/net80211/ieee80211_proto.c: In function 'ieee80211_csa_completeswitch': /src/sys/net80211/ieee80211_proto.c:1541: error: 'vap' undeclared (first use in this function) /src/sys/net80211/ieee80211_proto.c:1541: error: (Each undeclared identifier is reported only once /src/sys/net80211/ieee80211_proto.c:1541: error: for each function it appears in.) *** Error code 1 Stop in /obj/sparc64.sparc64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-07-20 01:47:06 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-07-20 01:47:06 - ERROR: failed to build lint kernel TB --- 2011-07-20 01:47:06 - 3346.69 user 770.04 system 4274.58 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-sparc64-sparc64.full From owner-freebsd-current@FreeBSD.ORG Wed Jul 20 02:09:21 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 112D0106564A; Wed, 20 Jul 2011 02:09:21 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id D41598FC15; Wed, 20 Jul 2011 02:09:20 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.4) with ESMTP id p6K29K0A077570; Tue, 19 Jul 2011 22:09:20 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.4/Submit) id p6K29Kn2077569; Wed, 20 Jul 2011 02:09:20 GMT (envelope-from tinderbox@freebsd.org) Date: Wed, 20 Jul 2011 02:09:20 GMT Message-Id: <201107200209.p6K29Kn2077569@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on powerpc/powerpc X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jul 2011 02:09:21 -0000 TB --- 2011-07-20 00:11:58 - tinderbox 2.7 running on freebsd-current.sentex.ca TB --- 2011-07-20 00:11:58 - starting HEAD tinderbox run for powerpc/powerpc TB --- 2011-07-20 00:11:58 - cleaning the object tree TB --- 2011-07-20 00:12:11 - cvsupping the source tree TB --- 2011-07-20 00:12:11 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/powerpc/powerpc/supfile TB --- 2011-07-20 00:12:23 - building world TB --- 2011-07-20 00:12:23 - MAKEOBJDIRPREFIX=/obj TB --- 2011-07-20 00:12:23 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-07-20 00:12:23 - TARGET=powerpc TB --- 2011-07-20 00:12:23 - TARGET_ARCH=powerpc TB --- 2011-07-20 00:12:23 - TZ=UTC TB --- 2011-07-20 00:12:23 - __MAKE_CONF=/dev/null TB --- 2011-07-20 00:12:23 - cd /src TB --- 2011-07-20 00:12:23 - /usr/bin/make -B buildworld >>> World build started on Wed Jul 20 00:12:24 UTC 2011 >>> 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 Wed Jul 20 01:59:34 UTC 2011 TB --- 2011-07-20 01:59:34 - generating LINT kernel config TB --- 2011-07-20 01:59:34 - cd /src/sys/powerpc/conf TB --- 2011-07-20 01:59:34 - /usr/bin/make -B LINT TB --- 2011-07-20 01:59:34 - building LINT kernel TB --- 2011-07-20 01:59:34 - MAKEOBJDIRPREFIX=/obj TB --- 2011-07-20 01:59:34 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-07-20 01:59:34 - TARGET=powerpc TB --- 2011-07-20 01:59:34 - TARGET_ARCH=powerpc TB --- 2011-07-20 01:59:34 - TZ=UTC TB --- 2011-07-20 01:59:34 - __MAKE_CONF=/dev/null TB --- 2011-07-20 01:59:34 - cd /src TB --- 2011-07-20 01:59:34 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Wed Jul 20 01:59:34 UTC 2011 >>> 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 -O2 -pipe -fno-strict-aliasing -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/net80211/ieee80211_output.c cc -c -O2 -pipe -fno-strict-aliasing -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/net80211/ieee80211_phy.c cc -c -O2 -pipe -fno-strict-aliasing -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/net80211/ieee80211_power.c cc -c -O2 -pipe -fno-strict-aliasing -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/net80211/ieee80211_proto.c /src/sys/net80211/ieee80211_proto.c: In function 'ieee80211_csa_completeswitch': /src/sys/net80211/ieee80211_proto.c:1541: error: 'vap' undeclared (first use in this function) /src/sys/net80211/ieee80211_proto.c:1541: error: (Each undeclared identifier is reported only once /src/sys/net80211/ieee80211_proto.c:1541: error: for each function it appears in.) *** Error code 1 Stop in /obj/powerpc.powerpc/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-07-20 02:09:19 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-07-20 02:09:19 - ERROR: failed to build lint kernel TB --- 2011-07-20 02:09:19 - 5821.73 user 1033.84 system 7041.79 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-powerpc-powerpc.full From owner-freebsd-current@FreeBSD.ORG Wed Jul 20 02:11:23 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 98E62106564A; Wed, 20 Jul 2011 02:11:23 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 6BDDA8FC16; Wed, 20 Jul 2011 02:11:23 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.4) with ESMTP id p6K2BMFR079532; Tue, 19 Jul 2011 22:11:22 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.4/Submit) id p6K2BMTP079531; Wed, 20 Jul 2011 02:11:22 GMT (envelope-from tinderbox@freebsd.org) Date: Wed, 20 Jul 2011 02:11:22 GMT Message-Id: <201107200211.p6K2BMTP079531@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on powerpc64/powerpc X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jul 2011 02:11:23 -0000 TB --- 2011-07-20 00:30:11 - tinderbox 2.7 running on freebsd-current.sentex.ca TB --- 2011-07-20 00:30:11 - starting HEAD tinderbox run for powerpc64/powerpc TB --- 2011-07-20 00:30:11 - cleaning the object tree TB --- 2011-07-20 00:30:29 - cvsupping the source tree TB --- 2011-07-20 00:30:29 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/powerpc64/powerpc/supfile TB --- 2011-07-20 00:30:42 - building world TB --- 2011-07-20 00:30:42 - MAKEOBJDIRPREFIX=/obj TB --- 2011-07-20 00:30:42 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-07-20 00:30:42 - TARGET=powerpc TB --- 2011-07-20 00:30:42 - TARGET_ARCH=powerpc64 TB --- 2011-07-20 00:30:42 - TZ=UTC TB --- 2011-07-20 00:30:42 - __MAKE_CONF=/dev/null TB --- 2011-07-20 00:30:42 - cd /src TB --- 2011-07-20 00:30:42 - /usr/bin/make -B buildworld >>> World build started on Wed Jul 20 00:30:43 UTC 2011 >>> 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 >>> stage 5.1: building 32 bit shim libraries >>> World build completed on Wed Jul 20 02:01:06 UTC 2011 TB --- 2011-07-20 02:01:06 - generating LINT kernel config TB --- 2011-07-20 02:01:06 - cd /src/sys/powerpc/conf TB --- 2011-07-20 02:01:06 - /usr/bin/make -B LINT TB --- 2011-07-20 02:01:06 - building LINT kernel TB --- 2011-07-20 02:01:06 - MAKEOBJDIRPREFIX=/obj TB --- 2011-07-20 02:01:06 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-07-20 02:01:06 - TARGET=powerpc TB --- 2011-07-20 02:01:06 - TARGET_ARCH=powerpc64 TB --- 2011-07-20 02:01:06 - TZ=UTC TB --- 2011-07-20 02:01:06 - __MAKE_CONF=/dev/null TB --- 2011-07-20 02:01:06 - cd /src TB --- 2011-07-20 02:01:06 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Wed Jul 20 02:01:06 UTC 2011 >>> 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 -O2 -pipe -fno-strict-aliasing -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 -mcall-aixdesc -ffreestanding -fstack-protector -Werror /src/sys/net80211/ieee80211_output.c cc -c -O2 -pipe -fno-strict-aliasing -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 -mcall-aixdesc -ffreestanding -fstack-protector -Werror /src/sys/net80211/ieee80211_phy.c cc -c -O2 -pipe -fno-strict-aliasing -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 -mcall-aixdesc -ffreestanding -fstack-protector -Werror /src/sys/net80211/ieee80211_power.c cc -c -O2 -pipe -fno-strict-aliasing -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 -mcall-aixdesc -ffreestanding -fstack-protector -Werror /src/sys/net80211/ieee80211_proto.c /src/sys/net80211/ieee80211_proto.c: In function 'ieee80211_csa_completeswitch': /src/sys/net80211/ieee80211_proto.c:1541: error: 'vap' undeclared (first use in this function) /src/sys/net80211/ieee80211_proto.c:1541: error: (Each undeclared identifier is reported only once /src/sys/net80211/ieee80211_proto.c:1541: error: for each function it appears in.) *** Error code 1 Stop in /obj/powerpc.powerpc64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-07-20 02:11:22 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-07-20 02:11:22 - ERROR: failed to build lint kernel TB --- 2011-07-20 02:11:22 - 4830.99 user 1105.61 system 6071.05 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-powerpc64-powerpc.full From owner-freebsd-current@FreeBSD.ORG Wed Jul 20 02:09:25 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 31DB1106566C; Wed, 20 Jul 2011 02:09:25 +0000 (UTC) (envelope-from grarpamp@gmail.com) Received: from mail-pz0-f49.google.com (mail-pz0-f49.google.com [209.85.210.49]) by mx1.freebsd.org (Postfix) with ESMTP id 0662A8FC12; Wed, 20 Jul 2011 02:09:24 +0000 (UTC) Received: by pzk33 with SMTP id 33so7340544pzk.8 for ; Tue, 19 Jul 2011 19:09:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=JCJQzPeto3MvLVj/X/mTMTk2hls4fFeaE69gfSjI75g=; b=rAEAYPTxZ7+ExxG2RqOrv33ibD5yY5vsntUo8FSoNquv8JOKtka6q6z2wnsylpw/nf ZgA3dq5mDoMYBwG8Haz4Iz0yqOpSOue4dkM6LAkeCj6Jw6o/9MSh7mcstSNJO4K5ryI2 t37o43T/pESiEkuHIEVBJs0IJ9RrWXfm11Bys= MIME-Version: 1.0 Received: by 10.143.97.26 with SMTP id z26mr3707178wfl.81.1311127764402; Tue, 19 Jul 2011 19:09:24 -0700 (PDT) Received: by 10.142.172.16 with HTTP; Tue, 19 Jul 2011 19:09:24 -0700 (PDT) In-Reply-To: <55627D64-E412-4D04-AA17-3D912EEE6589@bsdimp.com> References: <4E11ECE2.9050402@freebsd.org> <55627D64-E412-4D04-AA17-3D912EEE6589@bsdimp.com> Date: Tue, 19 Jul 2011 22:09:24 -0400 Message-ID: From: grarpamp To: Warner Losh Content-Type: text/plain; charset=UTF-8 X-Mailman-Approved-At: Wed, 20 Jul 2011 02:37:20 +0000 Cc: freebsd-hackers@freebsd.org, freebsd-current@freebsd.org Subject: Re: Jails: Setting different times in jails X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jul 2011 02:09:25 -0000 > Why on earth would you want this? Hi. Since your quote of my note was not to the original, I'll repost it here. Kurt Lidl also posted useful situations on these lists. Also, being able to have time tick backwards in jails could be interesting fuzzing too :-) Enjoy. Would be nice to be able to set different times in different jails. All jails would tick in step with the system. But each jail could have it's birthtime set specifically via jail(8), jail(2), etc. Either by specification of a specific time, or an offset from the current true system time. ie: jail(8): -t [-|+] Child jails would offset from their parent, not the system. Internally, gettimeofday, filesystem timestamps, and any other userland interfaces would be hooked and adjusted by referencing a table of jail ID's and their offsets. Similar to how setting TZ or /etc/localtime effects a timezone offset. But transparent and undetectable to the jail unless set as visible by the invoker. Useful for creating alternate histories, testing time dependant protocols and applications, forensics, pen testing, etc. From owner-freebsd-current@FreeBSD.ORG Wed Jul 20 02:53:09 2011 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 31EA61065672 for ; Wed, 20 Jul 2011 02:53:09 +0000 (UTC) (envelope-from swills@FreeBSD.org) Received: from mouf.net (mouf.net [204.109.58.86]) by mx1.freebsd.org (Postfix) with ESMTP id E41BC8FC17 for ; Wed, 20 Jul 2011 02:53:08 +0000 (UTC) Received: from meatwad.mouf.net (cpe-065-190-149-241.nc.res.rr.com [65.190.149.241]) (authenticated bits=0) by mouf.net (8.14.4/8.14.4) with ESMTP id p6K2ZgHn074708 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT) for ; Tue, 19 Jul 2011 22:35:44 -0400 (EDT) (envelope-from swills@FreeBSD.org) Message-ID: <4E263EFE.3040200@FreeBSD.org> Date: Tue, 19 Jul 2011 22:35:42 -0400 From: Steve Wills User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.17) Gecko/20110531 Thunderbird/3.1.10 MIME-Version: 1.0 To: current@FreeBSD.org X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (mouf.net [204.109.58.86]); Tue, 19 Jul 2011 22:35:44 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.96.2 at mouf.net X-Virus-Status: Clean Cc: Subject: em problem in virtualbox since the weekend X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jul 2011 02:53:09 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, While testing some other things, I found -CURRENT from yesterday doesn't work with the em0 in my VirtualBox 4.0.8 (a little out of date admittedly). It worked Friday or Saturday I think. Anyone else seen this or should I open a PR? Has the code changed or am I perhaps misremembering dates? The error reported is: em0: Unable to allocate bus resource: memory em0: Allocation of PCI resources failed Thanks, Steve -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (FreeBSD) iQEcBAEBAgAGBQJOJj7+AAoJEPXPYrMgexuhA0gIAIOevO4y79y+hvWkO/4ZvKJ2 bAMsaNbmp68vXkStLxm2nBa8UFUhjDtYu2qPh1Dj4PK/sx96swENkt4uJsyeBl12 5L6nLNR/A9LyWRhVKJE3QTcDOYKSCV93mjtm1sRTqrxYaZL05oE3isyRRj99c8AU 105wz+pO22h4CrJiNJQGb6G2CE4e4ghs6W5ToqxCdN5whZA6sjoeStzUnmnSKceS 05WzbGdoApbT4UknmDM9G4m8udHbCN2Lsk5rERug55F3eG6mrniJMd4EnrHC5FzW wRFvx3PWNbDkSYNh1uy/EVic9sJ4IoAzKLWtlaHpqS56LxKPYsTkv1X0u3s2mfA= =m0D7 -----END PGP SIGNATURE----- From owner-freebsd-current@FreeBSD.ORG Wed Jul 20 06:10:54 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3DFCC1065674; Wed, 20 Jul 2011 06:10:54 +0000 (UTC) (envelope-from ohartman@zedat.fu-berlin.de) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) by mx1.freebsd.org (Postfix) with ESMTP id DCA0E8FC1D; Wed, 20 Jul 2011 06:10:53 +0000 (UTC) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost1.zedat.fu-berlin.de (Exim 4.69) with esmtp (envelope-from ) id <1QjPzg-0001zT-S4>; Wed, 20 Jul 2011 08:10:52 +0200 Received: from e178000087.adsl.alicedsl.de ([85.178.0.87] helo=thor.walstatt.dyndns.org) by inpost2.zedat.fu-berlin.de (Exim 4.69) with esmtpsa (envelope-from ) id <1QjPzg-0001AR-OC>; Wed, 20 Jul 2011 08:10:52 +0200 Message-ID: <4E26716C.7090306@zedat.fu-berlin.de> Date: Wed, 20 Jul 2011 08:10:52 +0200 From: "Hartmann, O." User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:5.0) Gecko/20110712 Thunderbird/5.0 MIME-Version: 1.0 To: Adrian Chadd References: <4E25D444.1030506@zedat.fu-berlin.de> In-Reply-To: Content-Type: text/plain; charset=KOI8-U; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: 85.178.0.87 Cc: fidaj , FreeBSD Current Subject: Re: FreeBSD 9.0 CURRENT: /usr/src/sys/modules/wlan/../../net80211/ieee80211_proto.c:1541:16: error: use of undeclared identifier 'vap' X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jul 2011 06:10:54 -0000 No problem, I just mentioned it to make people aware ... Oliver On 07/20/11 02:48, Adrian Chadd wrote: > just committed that. > > Sorry, I thought that version of the patch had compiled right. Sorry ;( > > > adrian > > 2011/7/20 fidaj: >> --- ïÒÉǦÎÁÌØÎÅ ÐÏצÄÏÍÌÅÎÎÑ --- >> ÷¦Ä ËÏÇÏ: "Hartmann, O." >> ëÏÍÕ: "FreeBSD Current" >> äÁÔÁ: 19 ÌÉÐÎÑ 2011, 22:00:20 >> ôÅÍÁ: Re: FreeBSD 9.0 CURRENT: >> /usr/src/sys/modules/wlan/../../net80211/ieee80211_proto.c:1541:16: >> error: use of undeclared identifier 'vap' >> >> >> >> FreeBSD 9.0-CURRENT/amd64 stopps building kernel with the following >> error in module wlan: >> >> >> >> clang -O3 -mtune=native -fno-strict-aliasing -pipe -march=native >> -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include >> /usr/obj/usr/src/sys/THOR/opt_global.h -I. -I@ -I@/contrib/altq >> -fno-common -fno-omit-frame-pointer -I/usr/obj/usr/src/sys/THOR >> -mno-aes -mno-avx -mcmodel=kernel -mno-red-zone -mno-mmx -msoft-float >> -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector >> -std=iso9899:1999 -fstack-protector -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 -c >> /usr/src/sys/modules/wlan/../../net80211/ieee80211_proto.c >> /usr/src/sys/modules/wlan/../../net80211/ieee80211_proto.c:1541:16: >> error: use of undeclared identifier 'vap' >> TAILQ_FOREACH(vap,&ic->ic_vaps, iv_next) >> ^ >> @/sys/queue.h:521:8: note: expanded from: >> for ((var) = TAILQ_FIRST((head)); \ >> ^ >> /usr/src/sys/modules/wlan/../../net80211/ieee80211_proto.c:1541:16: >> error: use of undeclared identifier 'vap' >> TAILQ_FOREACH(vap,&ic->ic_vaps, iv_next) >> ^ >> @/sys/queue.h:522:7: note: expanded from: >> (var); \ >> ^ >> /usr/src/sys/modules/wlan/../../net80211/ieee80211_proto.c:1541:16: >> error: use of undeclared identifier 'vap' >> TAILQ_FOREACH(vap,&ic->ic_vaps, iv_next) >> ^ >> @/sys/queue.h:523:7: note: expanded from: >> (var) = TAILQ_NEXT((var), field)) >> ^ >> /usr/src/sys/modules/wlan/../../net80211/ieee80211_proto.c:1541:16: >> error: use of undeclared identifier 'vap' >> TAILQ_FOREACH(vap,&ic->ic_vaps, iv_next) >> ^ >> @/sys/queue.h:523:26: note: expanded from: >> (var) = TAILQ_NEXT((var), field)) >> ^ >> @/sys/queue.h:597:34: note: expanded from: >> #define TAILQ_NEXT(elm, field) ((elm)->field.tqe_next) >> ^ >> /usr/src/sys/modules/wlan/../../net80211/ieee80211_proto.c:1542:7: >> error: use of undeclared identifier 'vap' >> if (vap->iv_state == IEEE80211_S_CSA) >> ^ >> /usr/src/sys/modules/wlan/../../net80211/ieee80211_proto.c:1543:4: >> error: use of undeclared identifier 'vap' >> vap->iv_bss->ni_chan = ic->ic_curchan; >> ^ >> 6 errors generated. >> *** Error code 1 >> >> Stop in /usr/src/sys/modules/wlan. >> >> >> >> Regards, >> Oliver >> >> _______________________________________________ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to " freebsd-current-unsubscribe@freebsd.org " >> >> >> >> --- ieee80211_proto.c.orig 2011-07-20 01:06:17.000000000 +0300 >> +++ ieee80211_proto.c 2011-07-20 01:10:54.000000000 +0300 >> @@ -1533,6 +1533,8 @@ >> void >> ieee80211_csa_completeswitch(struct ieee80211com *ic) >> { >> + struct ieee80211vap *vap; >> + >> IEEE80211_LOCK_ASSERT(ic); >> >> KASSERT(ic->ic_flags& IEEE80211_F_CSAPENDING, ("csa not pending")); >> _______________________________________________ >> freebsd-current@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-current >> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" >> > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Wed Jul 20 08:59:32 2011 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DDC311065675 for ; Wed, 20 Jul 2011 08:59:32 +0000 (UTC) (envelope-from nvass@gmx.com) Received: from mailout-eu.gmx.com (mailout-eu.gmx.com [213.165.64.42]) by mx1.freebsd.org (Postfix) with SMTP id 38F118FC1C for ; Wed, 20 Jul 2011 08:59:32 +0000 (UTC) Received: (qmail invoked by alias); 20 Jul 2011 08:59:23 -0000 Received: from 77.49.6.107.dsl.dyn.forthnet.gr (EHLO [192.168.1.65]) [77.49.6.107] by mail.gmx.com (mp-eu004) with SMTP; 20 Jul 2011 10:59:23 +0200 X-Authenticated: #46156728 X-Provags-ID: V01U2FsdGVkX19Zk4EcBtpZa6FZWUy7ea+tGFC/Uku+H3K7VDTcbc eDrfVfykxgyY39 Message-ID: <4E2698D9.90106@gmx.com> Date: Wed, 20 Jul 2011 11:59:05 +0300 From: Nikos Vassiliadis User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: Steve Wills References: <4E263EFE.3040200@FreeBSD.org> In-Reply-To: <4E263EFE.3040200@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Mailman-Approved-At: Wed, 20 Jul 2011 11:13:03 +0000 Cc: current@FreeBSD.org Subject: Re: em problem in virtualbox since the weekend X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jul 2011 08:59:32 -0000 On 7/20/2011 5:35 AM, Steve Wills wrote: > While testing some other things, I found -CURRENT from yesterday doesn't > work with the em0 in my VirtualBox 4.0.8 (a little out of date > admittedly). It worked Friday or Saturday I think. Anyone else seen this I also see this on a 4.0.4something installation. > em0: Unable to allocate bus resource: memory > em0: Allocation of PCI resources failed So, you're not alone:) Nikos From owner-freebsd-current@FreeBSD.ORG Wed Jul 20 11:40:44 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 18DAF106564A; Wed, 20 Jul 2011 11:40:44 +0000 (UTC) (envelope-from dudu@dudu.ro) Received: from mail-qw0-f54.google.com (mail-qw0-f54.google.com [209.85.216.54]) by mx1.freebsd.org (Postfix) with ESMTP id BF4CD8FC13; Wed, 20 Jul 2011 11:40:42 +0000 (UTC) Received: by qwc9 with SMTP id 9so92164qwc.13 for ; Wed, 20 Jul 2011 04:40:42 -0700 (PDT) Received: by 10.229.43.231 with SMTP id x39mr6663217qce.198.1311160622113; Wed, 20 Jul 2011 04:17:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.90.195 with HTTP; Wed, 20 Jul 2011 04:16:22 -0700 (PDT) In-Reply-To: <4E2698D9.90106@gmx.com> References: <4E263EFE.3040200@FreeBSD.org> <4E2698D9.90106@gmx.com> From: Vlad Galu Date: Wed, 20 Jul 2011 13:16:22 +0200 Message-ID: To: Nikos Vassiliadis Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Steve Wills , current@freebsd.org Subject: Re: em problem in virtualbox since the weekend X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jul 2011 11:40:44 -0000 On Wed, Jul 20, 2011 at 10:59 AM, Nikos Vassiliadis wrote: > On 7/20/2011 5:35 AM, Steve Wills wrote: > >> While testing some other things, I found -CURRENT from yesterday doesn't >> work with the em0 in my VirtualBox 4.0.8 (a little out of date >> admittedly). It worked Friday or Saturday I think. Anyone else seen this >> > > I also see this on a 4.0.4something installation. > > > em0: Unable to allocate bus resource: memory >> em0: Allocation of PCI resources failed >> > > So, you're not alone:) > > Nikos > > Same here. I've tried all possible NIC emulations to no avail. -- Good, fast & cheap. Pick any two. From owner-freebsd-current@FreeBSD.ORG Wed Jul 20 11:41:27 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D55431065686; Wed, 20 Jul 2011 11:41:27 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id AE4398FC17; Wed, 20 Jul 2011 11:41:27 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 66AFF46B1A; Wed, 20 Jul 2011 07:41:27 -0400 (EDT) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id E82558A02C; Wed, 20 Jul 2011 07:41:26 -0400 (EDT) From: John Baldwin To: freebsd-current@freebsd.org Date: Wed, 20 Jul 2011 07:41:26 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110617; KDE/4.5.5; amd64; ; ) References: <4E263EFE.3040200@FreeBSD.org> In-Reply-To: <4E263EFE.3040200@FreeBSD.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201107200741.26362.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Wed, 20 Jul 2011 07:41:27 -0400 (EDT) Cc: Steve Wills Subject: Re: em problem in virtualbox since the weekend X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jul 2011 11:41:27 -0000 On Tuesday, July 19, 2011 10:35:42 pm Steve Wills wrote: > Hi, > > While testing some other things, I found -CURRENT from yesterday doesn't > work with the em0 in my VirtualBox 4.0.8 (a little out of date > admittedly). It worked Friday or Saturday I think. Anyone else seen this > or should I open a PR? Has the code changed or am I perhaps > misremembering dates? The error reported is: > > em0: Unable to allocate bus resource: memory > em0: Allocation of PCI resources failed This is due to a bug in VirtualBox's BIOS implementation. Someone should file a bug report with VirtualBox to ask them to fix their BIOS. The problem is that they claim that the Host-PCI bridge in their system only decodes addresses 0xa0000-0xbffff (i.e. the VGA window) via the "Producer" resources in the _CRS method of the Host-PCI bridge device. This tells the OS that all the existing PCI devices are using invalid memory address ranges but that there is also no available address space to allocate for PCI devices such as em0. You can workaround this by setting "debug.acpi.disabled=hostres" until VirtualBox fixes their code. I'm happy to provide further clarification to an existing VirtaulBox bug report if needed. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Wed Jul 20 12:33:08 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 744FE1065670 for ; Wed, 20 Jul 2011 12:33:08 +0000 (UTC) (envelope-from decke@FreeBSD.org) Received: from groupware.itac.at (groupware.itac.at [91.205.172.99]) by mx1.freebsd.org (Postfix) with ESMTP id 0CA278FC0A for ; Wed, 20 Jul 2011 12:33:07 +0000 (UTC) Received: from home.bluelife.at (93.104.210.95) by groupware.itac.at (Axigen) with (AES256-SHA encrypted) ESMTPSA id 1D5F9D; Wed, 20 Jul 2011 14:33:07 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Date: Wed, 20 Jul 2011 14:33:07 +0200 From: Bernhard Froehlich To: John Baldwin In-Reply-To: <201107200741.26362.jhb@freebsd.org> References: <4E263EFE.3040200@FreeBSD.org> <201107200741.26362.jhb@freebsd.org> Message-ID: <565082b8e8b3e358266054e58e591e12@bluelife.at> X-Sender: decke@FreeBSD.org User-Agent: Roundcube Webmail/0.5.3 X-AxigenSpam-Level: 1 X-CTCH-RefID: str=0001.0A0B0209.4E26CB02.0088,ss=1,fgs=0 X-CTCH-VOD: Unknown X-CTCH-Spam: Unknown Cc: Steve Wills , freebsd-current@freebsd.org Subject: Re: em problem in virtualbox since the weekend X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jul 2011 12:33:08 -0000 On Wed, 20 Jul 2011 07:41:26 -0400, John Baldwin wrote: > On Tuesday, July 19, 2011 10:35:42 pm Steve Wills wrote: >> Hi, >> >> While testing some other things, I found -CURRENT from yesterday doesn't >> work with the em0 in my VirtualBox 4.0.8 (a little out of date >> admittedly). It worked Friday or Saturday I think. Anyone else seen this >> or should I open a PR? Has the code changed or am I perhaps >> misremembering dates? The error reported is: >> >> em0: Unable to allocate bus resource: memory >> em0: Allocation of PCI resources failed > > This is due to a bug in VirtualBox's BIOS implementation. Someone > should file > a bug report with VirtualBox to ask them to fix their BIOS. The problem is > that they claim that the Host-PCI bridge in their system only decodes > addresses 0xa0000-0xbffff (i.e. the VGA window) via the "Producer" resources > in the _CRS method of the Host-PCI bridge device. This tells the OS > that all > the existing PCI devices are using invalid memory address ranges but that > there is also no available address space to allocate for PCI devices such as > em0. > > You can workaround this by setting "debug.acpi.disabled=hostres" until > VirtualBox fixes their code. I'm happy to provide further > clarification to an > existing VirtaulBox bug report if needed. Thanks a lot for the analysis! I've talked to one of the virtualbox developers about that but they are not aware of such problems with Linux or Windows guests yet. So they are currently unsure if it's a VirtualBox or FreeBSD fault and if it's their fault why it works fine with other guests. I'm also unsure because I haven't heard of that problem before and now multiple people complain. That looks more like a FreeBSD related problem on current or stable. I think it would be good if someone could try to reproduce that with emulators/virtualbox-ose-legacy which is 3.2.12 to get some vbox dev look into the problem again. -- Bernhard Froehlich http://www.bluelife.at/ From owner-freebsd-current@FreeBSD.ORG Wed Jul 20 14:33:55 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C229F106566B; Wed, 20 Jul 2011 14:33:55 +0000 (UTC) (envelope-from niclas.zeising@gmail.com) Received: from mail.lysator.liu.se (mail.lysator.liu.se [IPv6:2001:6b0:17:f0a0::3]) by mx1.freebsd.org (Postfix) with ESMTP id 22B648FC14; Wed, 20 Jul 2011 14:33:55 +0000 (UTC) Received: from mail.lysator.liu.se (localhost [127.0.0.1]) by mail.lysator.liu.se (Postfix) with ESMTP id 4EE8040005; Wed, 20 Jul 2011 16:33:53 +0200 (CEST) Received: by mail.lysator.liu.se (Postfix, from userid 1004) id 43E6F40014; Wed, 20 Jul 2011 16:33:53 +0200 (CEST) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on bernadotte.lysator.liu.se X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=AWL,FREEMAIL_FROM autolearn=disabled version=3.3.1 X-Spam-Score: 0.0 Received: from mx.daemonic.se (h-90-99.a163.priv.bahnhof.se [79.136.90.99]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.lysator.liu.se (Postfix) with ESMTPSA id DAA7540005; Wed, 20 Jul 2011 16:33:52 +0200 (CEST) Received: from mail.daemonic.se (mail.daemonic.se [IPv6:2001:470:dca9:0:1::4]) by mx.daemonic.se (Postfix) with ESMTPS id 71F89119C08; Wed, 20 Jul 2011 16:33:22 +0200 (CEST) Received: from [IPv6:2001:470:dca9:1::4] (vivi.daemonic.se [IPv6:2001:470:dca9:1::4]) by mail.daemonic.se (Postfix) with ESMTPSA id 2C57312B1E5; Wed, 20 Jul 2011 16:33:22 +0200 (CEST) Message-ID: <4E26E72F.9060703@gmail.com> Date: Wed, 20 Jul 2011 16:33:19 +0200 From: Niclas Zeising User-Agent: Mutt/1.5.21 MIME-Version: 1.0 To: Bernhard Froehlich References: <4E263EFE.3040200@FreeBSD.org> <201107200741.26362.jhb@freebsd.org> <565082b8e8b3e358266054e58e591e12@bluelife.at> In-Reply-To: <565082b8e8b3e358266054e58e591e12@bluelife.at> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP Cc: Steve Wills , freebsd-current@freebsd.org Subject: Re: em problem in virtualbox since the weekend X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jul 2011 14:33:55 -0000 On 2011-07-20 14:33, Bernhard Froehlich wrote: > On Wed, 20 Jul 2011 07:41:26 -0400, John Baldwin wrote: >> On Tuesday, July 19, 2011 10:35:42 pm Steve Wills wrote: >>> Hi, >>> >>> While testing some other things, I found -CURRENT from yesterday doesn't >>> work with the em0 in my VirtualBox 4.0.8 (a little out of date >>> admittedly). It worked Friday or Saturday I think. Anyone else seen this >>> or should I open a PR? Has the code changed or am I perhaps >>> misremembering dates? The error reported is: >>> >>> em0: Unable to allocate bus resource: memory >>> em0: Allocation of PCI resources failed >> >> This is due to a bug in VirtualBox's BIOS implementation. Someone >> should file >> a bug report with VirtualBox to ask them to fix their BIOS. The problem is >> that they claim that the Host-PCI bridge in their system only decodes >> addresses 0xa0000-0xbffff (i.e. the VGA window) via the "Producer" resources >> in the _CRS method of the Host-PCI bridge device. This tells the OS >> that all >> the existing PCI devices are using invalid memory address ranges but that >> there is also no available address space to allocate for PCI devices such as >> em0. >> >> You can workaround this by setting "debug.acpi.disabled=hostres" until >> VirtualBox fixes their code. I'm happy to provide further >> clarification to an >> existing VirtaulBox bug report if needed. > > Thanks a lot for the analysis! I've talked to one of the virtualbox > developers about that but they are not aware of such problems with Linux > or Windows guests yet. So they are currently unsure if it's a VirtualBox > or FreeBSD fault and if it's their fault why it works fine with other > guests. I'm also unsure because I haven't heard of that problem before > and now multiple people complain. That looks more like a FreeBSD related > problem on current or stable. > > I think it would be good if someone could try to reproduce that with > emulators/virtualbox-ose-legacy which is 3.2.12 to get some vbox dev > look into the problem again. > This may or may not be related, apologies if it is not. My FreeBSD VirtualBox guest, running inside vbox under Windows, is having trouble mounting it's root partition, mountroot dies with error 19 (which is ENODEV, I've come to understand). I can also see in the dmesg prior to this ahci, ehci and ohci not being able to allocate resources properly, or something similar. Rebuilding the kernel with nooptions NEW_PCIB solves the immediate issue (i.e. the machine boots and can find filesystems, etc.). It is probably so, that if there is a bug in vbox bios, the old pci code masks that bug, but the new version is more stringent and therefore dies on it. This can be the reason no one has seen this issue up until now. Why it works for Linux and Windows guests, I have no idea. I hope this helps someone, or at least can shed some light on the issue at hand. Regards! -- Niclas Zeising From owner-freebsd-current@FreeBSD.ORG Wed Jul 20 15:02:38 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EBC53106566B for ; Wed, 20 Jul 2011 15:02:38 +0000 (UTC) (envelope-from aboyer@averesystems.com) Received: from zimbra.averesystems.com (75-149-8-245-Pennsylvania.hfc.comcastbusiness.net [75.149.8.245]) by mx1.freebsd.org (Postfix) with ESMTP id 6E0E18FC12 for ; Wed, 20 Jul 2011 15:02:38 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zimbra.averesystems.com (Postfix) with ESMTP id DFA2F8BC023; Wed, 20 Jul 2011 10:47:21 -0400 (EDT) X-Virus-Scanned: amavisd-new at averesystems.com Received: from zimbra.averesystems.com ([127.0.0.1]) by localhost (zimbra.averesystems.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cTucudtWFQHR; Wed, 20 Jul 2011 10:47:15 -0400 (EDT) Received: from riven.arriad.com (fw.arriad.com [10.0.0.16]) by zimbra.averesystems.com (Postfix) with ESMTPSA id C2A988BC003; Wed, 20 Jul 2011 10:47:15 -0400 (EDT) From: Andrew Boyer Content-Type: multipart/mixed; boundary=Apple-Mail-10-5916955 Date: Wed, 20 Jul 2011 10:44:42 -0400 Message-Id: To: mav@freebsd.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Cc: freebsd-current@freebsd.org, Jack Vogel Subject: [patch] Intel SATA controller hiccups, locking X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jul 2011 15:02:39 -0000 --Apple-Mail-10-5916955 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hello Alexander, I am using the latest ata driver from stable/8 on a system with an Intel = ICH10 controller. ATA_CAM and ATA_STATIC_ID are both off. There is one = drive connected to port 3. SATA is set to Enhanced / IDE mode (not = AHCI) in the BIOS. > atapci0@pci0:0:31:2: class=3D0x01018f card=3D0x060d15d9 = chip=3D0x3a208086 rev=3D0x00 hdr=3D0x00 > atapci1@pci0:0:31:5: class=3D0x010185 card=3D0x060d15d9 = chip=3D0x3a268086 rev=3D0x00 hdr=3D0x00 > atapci0: port = 0xbff0-0xbff7,0xbf7c-0xbf7f,0xbfe0-0xbfe7,0xbef4-0xbef7,0xbfa0-0xbfaf,0xbf= 60-0xbf6f irq 19 at device 31.2 on pci0 > atapci0: Reserved 0x10 bytes for rid 0x20 type 4 at 0xbfa0 > atapci0: [MPSAFE] > atapci0: [ITHREAD] > atapci0: Reserved 0x10 bytes for rid 0x24 type 4 at 0xbf60 > ata2: on atapci0 > atapci0: Reserved 0x8 bytes for rid 0x10 type 4 at 0xbff0 > atapci0: Reserved 0x4 bytes for rid 0x14 type 4 at 0xbf7c > ata2: SATA reset: ports status=3D0x00 > ata2: p0: SATA connect timeout status=3D00000000 > ata2: p1: SATA connect timeout status=3D00000000 > ata2: [MPSAFE] > ata2: [ITHREAD] > ata3: on atapci0 > atapci0: Reserved 0x8 bytes for rid 0x18 type 4 at 0xbfe0 > atapci0: Reserved 0x4 bytes for rid 0x1c type 4 at 0xbef4 > ata3: SATA reset: ports status=3D0x08 > ata3: p0: SATA connect timeout status=3D00000000 > ata3: p1: SATA connect time=3D0ms status=3D00000123 > ata3: reset tp1 mask=3D03 ostat0=3D7f ostat1=3D50 > ata3: stat0=3D0x7f err=3D0x00 lsb=3D0xff msb=3D0xff > ata3: stat1=3D0x50 err=3D0x01 lsb=3D0x00 msb=3D0x00 > ata3: reset tp2 stat0=3D7f stat1=3D50 devices=3D0x2 > ata3: [MPSAFE] > ata3: [ITHREAD] When under heavy load, the 'atacontrol mode ad0' command sometimes fails = to determine the SATA speed; the drive appears to be missing. I think = the root cause is that chipsets/ata-intel.c does not do any locking on = the ata_intel_sata_sidpr_* routines. The (write address register) + = (access data register) model isn't safe without locking because two = channels share the registers. The ata_intel_sata_cscr_* routines have = the same problem. Adding a mutex to a structure stored in ctlr->chipset_data makes the = hiccups go away; see the attached patch. Please advise if this is = something you would like to fix. =20 Thank you, Andrew --Apple-Mail-10-5916955 Content-Disposition: attachment; filename=ata_intel_sata.diff Content-Type: application/octet-stream; x-unix-mode=0644; name="ata_intel_sata.diff" Content-Transfer-Encoding: 7bit --- sys/dev/ata/chipsets/ata-intel.c +++ sys/dev/ata/chipsets/ata-intel.c @@ -85,6 +85,18 @@ static void ata_intel_31244_reset(device_t dev); #define INTEL_6CH2 8 #define INTEL_ICH7 16 +struct ata_intel_data { + u_char smap[8]; /* was a void* */ + struct mtx lock; +}; + +#define ATA_INTEL_SMAP(_ctlr, _ch) \ + &((struct ata_intel_data *)(_ctlr->chipset_data))->smap[_ch->unit * 2] +#define ATA_INTEL_LOCK(_ctlr) \ + mtx_lock(&((struct ata_intel_data *)(_ctlr->chipset_data))->lock) +#define ATA_INTEL_UNLOCK(_ctlr) \ + mtx_unlock(&((struct ata_intel_data *)(_ctlr->chipset_data))->lock) + /* * Intel chipset support functions */ @@ -217,7 +229,10 @@ ata_intel_chipinit(device_t dev) if (ata_setup_interrupt(dev, ata_generic_intr)) return ENXIO; - ctlr->chipset_data = NULL; + struct ata_intel_data *data = malloc(sizeof(struct ata_intel_data), + M_DEVBUF, M_WAITOK | M_ZERO); + mtx_init(&data->lock, "Intel SATA lock", NULL, MTX_DEF); + ctlr->chipset_data = (void *)data; /* good old PIIX needs special treatment (not implemented) */ if (ctlr->chip->chipid == ATA_I82371FB) { @@ -329,7 +344,7 @@ ata_intel_ch_attach(device_t dev) ch->flags |= ATA_ALWAYS_DMASTAT; if (ctlr->chip->max_dma >= ATA_SA150) { - smap = (u_char *)&ctlr->chipset_data + ch->unit * 2; + smap = ATA_INTEL_SMAP(ctlr, ch); map = pci_read_config(device_get_parent(dev), 0x90, 1); if (ctlr->chip->cfg1 & INTEL_ICH5) { map &= 0x07; @@ -415,7 +430,7 @@ ata_intel_reset(device_t dev) return (ata_generic_reset(dev)); /* Do hard-reset on respective SATA ports. */ - smap = (u_char *)&ctlr->chipset_data + ch->unit * 2; + smap = ATA_INTEL_SMAP(ctlr, ch); mask = 1 << smap[0]; if ((ch->flags & ATA_NO_SLAVE) == 0) mask |= (1 << smap[1]); @@ -605,7 +620,7 @@ ata_intel_sata_ahci_read(device_t dev, int port, int reg, u_int32_t *result) ctlr = device_get_softc(parent); ch = device_get_softc(dev); port = (port == 1) ? 1 : 0; - smap = (u_char *)&ctlr->chipset_data + ch->unit * 2; + smap = ATA_INTEL_SMAP(ctlr, ch); offset = 0x100 + smap[port] * 0x80; switch (reg) { case ATA_SSTATUS: @@ -635,7 +650,7 @@ ata_intel_sata_cscr_read(device_t dev, int port, int reg, u_int32_t *result) parent = device_get_parent(dev); ctlr = device_get_softc(parent); ch = device_get_softc(dev); - smap = (u_char *)&ctlr->chipset_data + ch->unit * 2; + smap = ATA_INTEL_SMAP(ctlr, ch); port = (port == 1) ? 1 : 0; switch (reg) { case ATA_SSTATUS: @@ -650,9 +665,11 @@ ata_intel_sata_cscr_read(device_t dev, int port, int reg, u_int32_t *result) default: return (EINVAL); } + ATA_INTEL_LOCK(ctlr); pci_write_config(parent, 0xa0, 0x50 + smap[port] * 0x10 + reg * 4, 4); *result = pci_read_config(parent, 0xa4, 4); + ATA_INTEL_UNLOCK(ctlr); return (0); } @@ -680,8 +697,10 @@ ata_intel_sata_sidpr_read(device_t dev, int port, int reg, u_int32_t *result) default: return (EINVAL); } + ATA_INTEL_LOCK(ctlr); ATA_IDX_OUTL(ch, ATA_IDX_ADDR, ((ch->unit * 2 + port) << 8) + reg); *result = ATA_IDX_INL(ch, ATA_IDX_DATA); + ATA_INTEL_UNLOCK(ctlr); return (0); } @@ -698,7 +717,7 @@ ata_intel_sata_ahci_write(device_t dev, int port, int reg, u_int32_t value) ctlr = device_get_softc(parent); ch = device_get_softc(dev); port = (port == 1) ? 1 : 0; - smap = (u_char *)&ctlr->chipset_data + ch->unit * 2; + smap = ATA_INTEL_SMAP(ctlr, ch); offset = 0x100 + smap[port] * 0x80; switch (reg) { case ATA_SSTATUS: @@ -728,7 +747,7 @@ ata_intel_sata_cscr_write(device_t dev, int port, int reg, u_int32_t value) parent = device_get_parent(dev); ctlr = device_get_softc(parent); ch = device_get_softc(dev); - smap = (u_char *)&ctlr->chipset_data + ch->unit * 2; + smap = ATA_INTEL_SMAP(ctlr, ch); port = (port == 1) ? 1 : 0; switch (reg) { case ATA_SSTATUS: @@ -743,9 +762,11 @@ ata_intel_sata_cscr_write(device_t dev, int port, int reg, u_int32_t value) default: return (EINVAL); } + ATA_INTEL_LOCK(ctlr); pci_write_config(parent, 0xa0, 0x50 + smap[port] * 0x10 + reg * 4, 4); pci_write_config(parent, 0xa4, value, 4); + ATA_INTEL_UNLOCK(ctlr); return (0); } @@ -773,8 +794,10 @@ ata_intel_sata_sidpr_write(device_t dev, int port, int reg, u_int32_t value) default: return (EINVAL); } + ATA_INTEL_LOCK(ctlr); ATA_IDX_OUTL(ch, ATA_IDX_ADDR, ((ch->unit * 2 + port) << 8) + reg); ATA_IDX_OUTL(ch, ATA_IDX_DATA, value); + ATA_INTEL_UNLOCK(ctlr); return (0); } --Apple-Mail-10-5916955 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii -------------------------------------------------- Andrew Boyer aboyer@averesystems.com --Apple-Mail-10-5916955-- From owner-freebsd-current@FreeBSD.ORG Wed Jul 20 15:15:00 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D770D10656AA; Wed, 20 Jul 2011 15:15:00 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id A8E438FC13; Wed, 20 Jul 2011 15:15:00 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 539F246B2D; Wed, 20 Jul 2011 11:15:00 -0400 (EDT) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id DC5988A02C; Wed, 20 Jul 2011 11:14:59 -0400 (EDT) From: John Baldwin To: Bernhard Froehlich Date: Wed, 20 Jul 2011 09:04:45 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110617; KDE/4.5.5; amd64; ; ) References: <4E263EFE.3040200@FreeBSD.org> <201107200741.26362.jhb@freebsd.org> <565082b8e8b3e358266054e58e591e12@bluelife.at> In-Reply-To: <565082b8e8b3e358266054e58e591e12@bluelife.at> MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201107200904.45647.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Wed, 20 Jul 2011 11:15:00 -0400 (EDT) Cc: Steve Wills , freebsd-current@freebsd.org Subject: Re: em problem in virtualbox since the weekend X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jul 2011 15:15:01 -0000 On Wednesday, July 20, 2011 8:33:07 am Bernhard Froehlich wrote: > On Wed, 20 Jul 2011 07:41:26 -0400, John Baldwin wrote: > > On Tuesday, July 19, 2011 10:35:42 pm Steve Wills wrote: > >> Hi, > >> > >> While testing some other things, I found -CURRENT from yesterday doesn't > >> work with the em0 in my VirtualBox 4.0.8 (a little out of date > >> admittedly). It worked Friday or Saturday I think. Anyone else seen this > >> or should I open a PR? Has the code changed or am I perhaps > >> misremembering dates? The error reported is: > >> > >> em0: Unable to allocate bus resource: memory > >> em0: Allocation of PCI resources failed > > > > This is due to a bug in VirtualBox's BIOS implementation. Someone > > should file > > a bug report with VirtualBox to ask them to fix their BIOS. The problem is > > that they claim that the Host-PCI bridge in their system only decodes > > addresses 0xa0000-0xbffff (i.e. the VGA window) via the "Producer" resources > > in the _CRS method of the Host-PCI bridge device. This tells the OS > > that all > > the existing PCI devices are using invalid memory address ranges but that > > there is also no available address space to allocate for PCI devices such as > > em0. > > > > You can workaround this by setting "debug.acpi.disabled=hostres" until > > VirtualBox fixes their code. I'm happy to provide further > > clarification to an > > existing VirtaulBox bug report if needed. > > Thanks a lot for the analysis! I've talked to one of the virtualbox > developers about that but they are not aware of such problems with Linux > or Windows guests yet. So they are currently unsure if it's a VirtualBox > or FreeBSD fault and if it's their fault why it works fine with other > guests. I'm also unsure because I haven't heard of that problem before > and now multiple people complain. That looks more like a FreeBSD related > problem on current or stable. > > I think it would be good if someone could try to reproduce that with > emulators/virtualbox-ose-legacy which is 3.2.12 to get some vbox dev > look into the problem again. FreeBSD just started honoring this setting in the BIOS this week and ignored it previously. Can you get an acpidump from within VirtaulBox? I might be able to point to a bug in it directly if so. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Wed Jul 20 15:15:01 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AC9841065670; Wed, 20 Jul 2011 15:15:01 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 66A888FC16; Wed, 20 Jul 2011 15:15:01 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id E7ECE46B46; Wed, 20 Jul 2011 11:15:00 -0400 (EDT) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 836638A02F; Wed, 20 Jul 2011 11:15:00 -0400 (EDT) From: John Baldwin To: Niclas Zeising Date: Wed, 20 Jul 2011 11:14:59 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110617; KDE/4.5.5; amd64; ; ) References: <4E263EFE.3040200@FreeBSD.org> <565082b8e8b3e358266054e58e591e12@bluelife.at> <4E26E72F.9060703@gmail.com> In-Reply-To: <4E26E72F.9060703@gmail.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201107201114.59209.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Wed, 20 Jul 2011 11:15:00 -0400 (EDT) Cc: Steve Wills , freebsd-current@freebsd.org, Bernhard Froehlich Subject: Re: em problem in virtualbox since the weekend X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jul 2011 15:15:01 -0000 On Wednesday, July 20, 2011 10:33:19 am Niclas Zeising wrote: > On 2011-07-20 14:33, Bernhard Froehlich wrote: > > On Wed, 20 Jul 2011 07:41:26 -0400, John Baldwin wrote: > >> On Tuesday, July 19, 2011 10:35:42 pm Steve Wills wrote: > >>> Hi, > >>> > >>> While testing some other things, I found -CURRENT from yesterday doesn't > >>> work with the em0 in my VirtualBox 4.0.8 (a little out of date > >>> admittedly). It worked Friday or Saturday I think. Anyone else seen this > >>> or should I open a PR? Has the code changed or am I perhaps > >>> misremembering dates? The error reported is: > >>> > >>> em0: Unable to allocate bus resource: memory > >>> em0: Allocation of PCI resources failed > >> > >> This is due to a bug in VirtualBox's BIOS implementation. Someone > >> should file > >> a bug report with VirtualBox to ask them to fix their BIOS. The problem is > >> that they claim that the Host-PCI bridge in their system only decodes > >> addresses 0xa0000-0xbffff (i.e. the VGA window) via the "Producer" resources > >> in the _CRS method of the Host-PCI bridge device. This tells the OS > >> that all > >> the existing PCI devices are using invalid memory address ranges but that > >> there is also no available address space to allocate for PCI devices such as > >> em0. > >> > >> You can workaround this by setting "debug.acpi.disabled=hostres" until > >> VirtualBox fixes their code. I'm happy to provide further > >> clarification to an > >> existing VirtaulBox bug report if needed. > > > > Thanks a lot for the analysis! I've talked to one of the virtualbox > > developers about that but they are not aware of such problems with Linux > > or Windows guests yet. So they are currently unsure if it's a VirtualBox > > or FreeBSD fault and if it's their fault why it works fine with other > > guests. I'm also unsure because I haven't heard of that problem before > > and now multiple people complain. That looks more like a FreeBSD related > > problem on current or stable. > > > > I think it would be good if someone could try to reproduce that with > > emulators/virtualbox-ose-legacy which is 3.2.12 to get some vbox dev > > look into the problem again. > > > > This may or may not be related, apologies if it is not. > My FreeBSD VirtualBox guest, running inside vbox under Windows, is > having trouble mounting it's root partition, mountroot dies with error > 19 (which is ENODEV, I've come to understand). I can also see in the > dmesg prior to this ahci, ehci and ohci not being able to allocate > resources properly, or something similar. Rebuilding the kernel with > nooptions NEW_PCIB solves the immediate issue (i.e. the machine boots > and can find filesystems, etc.). > It is probably so, that if there is a bug in vbox bios, the old pci code > masks that bug, but the new version is more stringent and therefore dies > on it. This can be the reason no one has seen this issue up until now. > Why it works for Linux and Windows guests, I have no idea. > I hope this helps someone, or at least can shed some light on the issue > at hand. Yes, that is the same bug. The old PCI code is less stringent (but also less functional in other cases as a result). -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Wed Jul 20 19:46:58 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E2530106566B for ; Wed, 20 Jul 2011 19:46:58 +0000 (UTC) (envelope-from samspeed@mail.ru) Received: from f43.mail.ru (f43.mail.ru [217.69.128.200]) by mx1.freebsd.org (Postfix) with ESMTP id 333108FC1B for ; Wed, 20 Jul 2011 19:46:57 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=mail.ru; s=mail; h=Message-Id:Content-Transfer-Encoding:Content-Type:Reply-To:In-Reply-To:References:Date:Mime-Version:Subject:Cc:To:From; bh=IllF6fiteDfteYrFdPv6Sn8cmKu05NTnsMc1zGaXjkM=; b=oX+foZr13jwbMG5bIqbfgJ48ZhGjggWVFRWH41e7Pp0fW+UxoTS14EO+Atr278qMcURBxpzxLJrvDCY4wfc6qaT8XwxJIRmFJolqC8KYoFFj+0RPqQCAb54ITlfRdGoR; Received: from mail by f43.mail.ru with local id 1QjcjO-0000Ow-00; Wed, 20 Jul 2011 23:46:54 +0400 Received: from [217.25.236.249] by e.mail.ru with HTTP; Wed, 20 Jul 2011 23:46:54 +0400 From: Andrey Smagin To: YongHyeon PYUN Mime-Version: 1.0 X-Mailer: mPOP Web-Mail 2.19 X-Originating-IP: [217.25.236.249] Date: Wed, 20 Jul 2011 23:46:54 +0400 References: <20110630171914.GA12124@michelle.cdnetworks.com> <20110713000541.GC7564@michelle.cdnetworks.com> In-Reply-To: <20110713000541.GC7564@michelle.cdnetworks.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 Message-Id: X-Spam: Not detected X-Mras: Ok Cc: freebsd-current@freebsd.org Subject: Re[2]: AX88772A AX88772B chipset differences? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Andrey Smagin List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jul 2011 19:46:59 -0000 CjEzINC40Y7Qu9GPIDIwMTEsIDA0OjA3INC+0YIgWW9uZ0h5ZW9uIFBZVU4gPHB5dW55aEBnbWFp bC5jb20+Ogo+IE9uIFRodSwgSnVuIDMwLCAyMDExIGF0IDEwOjE5OjE0QU0gLTA3MDAsIFlvbmdI eWVvbiBQWVVOIHdyb3RlOgo+ID4gT24gVGh1LCBKdW4gMzAsIDIwMTEgYXQgMDI6NDQ6NDhQTSAr MDQwMCwgQW5kcmV5IFNtYWdpbiB3cm90ZToKPiA+ID4gSSBoYXZlIGNhcmQgYmFzZWQgb24gQVg4 ODc3MkIuIEkgdHJpZWQgcGF0Y2ggYXhlIGRyaXZlciBmb3IgdmVuZG9yIGFuZAo+IGRldmljZSBJ RHMuIGNhcmQgZGV0ZWN0ZWQsIHNldCB1cCBsaW5rLCBidXQgbm8gZGF0YSByZWNlaXZlZC4gV2hh dCBlbHNlIG5lZWQKPiBmb3IgcGF0Y2ggaW4gIHRoaXMgZHJpdmVyID8gQW55Ym9keSBoYXZlIGRh dGFzaGVldCA/Cj4gPiAKPiA+IEFTSVggcmVxdWlyZXMgYSBsb2dpbiBhY2NvdW50IHRvIGdldCB0 aGUgZGF0YSBzaGVldCBzbyBpdCdzIG5vdAo+ID4gcHVibGljbHkgYXZhaWxhYmxlIHRvIG9wZW4g c291cmNlIGRldmVsb3BlcnMuCj4gPiBBRkFJSyB0aGUgZGlmZmVyZW5jZSBiZXR3ZWVuIEFYODg3 NzJBIGFuZCBBWDg4NzcyQiBpcyBJUHY0L0lQdjYKPiA+IGNoZWNrc3VtIG9mZmxvYWRpbmcgc3Vw cG9ydCBvZiBBWDg4NzcyQi4gVGhlIGludHJvZHVjdGlvbiBvZgo+ID4gY2hlY2tzdW0gb2ZmbG9h ZGluZyBtZWFucyB0aGV5IG1pZ2h0IGhhdmUgY2hhbmdlZCBpdHMgUlggaGVhZGVyCj4gPiBmb3Jt YXQgd2hpY2ggaW4gdHVybiBtYWtlcyBjdXJyZW50IFJYIGhhbmRsZXIgdG8gbm90IHdvcmsuICBU aGUKPiA+IG90aGVyIGRpZmZlcmVuY2Ugd291bGQgYmUgbW9yZSBhZHZhbmNlZCBwb3dlciBzYXZp bmcgdXNlZCBpbgo+ID4gQVg4ODc3QiBidXQgaXQgd291bGRuJ3QgYmUgbXVjaCBkaWZmZXJlbmNl IHRvIGF4ZSg0KSBkcml2ZXIgb25jZQo+ID4gUEhZIGlzIGNvcnJlY3RseSB3b2tlbiBpbiBpbml0 aWFsaXphdGlvbiBwaGFzZS4KPiA+IENvdWxkIHlvdSBzaG93IG1lIHlvdXIgZGlmZiBhbmQgdmVy Ym9zZSBib290IG91dHB1dCB0byBrbm93IFBIWQo+ID4gbW9kZWwgYW5kIEVFUFJPTSBkYXRhPwo+ IAo+IEkgaGF2ZSBhIG1pbmltYWwgcGF0Y2ggZm9yIEFYODg3NzJCLiBJdCByZXF1aXJlcyBtb3Jl IHdvcmsgdG8KPiBzdXBwb3J0IFRYL1JYIGNoZWNrc3VtIG9mZmxvYWRpbmcsIGZsb3ctY29udHJv bCBhbmQgcG93ZXIgc2F2aW5nCj4gYnV0IGF0dGFjaGVkIHBhdGNoIHdvdWxkIGJlIGVub3VnaCBm b3IgbW9zdCBjYXNlcy4KPiBMZXQgbWUga25vdyB3aGV0aGVyIGl0IHdvcmtzIG9yIG5vdC4KIApH cmVhdCB0aGFueCAhISEgIEl0IHdvcmsgYnV0IEkgbm90IHRlc3RlZCB1bmRlciBoZWF2eSBsb2Fk LiBPbmx5IHBpbmcgYW5kIHNvbWUgTWJ5dGVzIHZpYSBuZnMuIAo= From owner-freebsd-current@FreeBSD.ORG Wed Jul 20 20:25:09 2011 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5C012106566C for ; Wed, 20 Jul 2011 20:25:09 +0000 (UTC) (envelope-from andreast@FreeBSD.org) Received: from smtp.fgznet.ch (mail.fgznet.ch [81.92.96.47]) by mx1.freebsd.org (Postfix) with ESMTP id A64628FC0A for ; Wed, 20 Jul 2011 20:25:08 +0000 (UTC) Received: from deuterium.andreas.nets (dhclient-91-190-8-131.flashcable.ch [91.190.8.131]) by smtp.fgznet.ch (8.13.8/8.13.8/Submit_SMTPAUTH) with ESMTP id p6KKP3qq083513 for ; Wed, 20 Jul 2011 22:25:05 +0200 (CEST) (envelope-from andreast@FreeBSD.org) Message-ID: <4E27399F.7020605@FreeBSD.org> Date: Wed, 20 Jul 2011 22:25:03 +0200 From: Andreas Tobler User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.15) Gecko/20110303 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 To: freebsd-current Content-Type: multipart/mixed; boundary="------------060402020806010608010809" X-Scanned-By: MIMEDefang 2.64 on 81.92.96.47 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: pcib1: failed to allocate initial memory window X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jul 2011 20:25:09 -0000 This is a multi-part message in MIME format. --------------060402020806010608010809 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi all, Built a fresh kernel today (-CURRENT) on my DELL workstation (amd64). The network card does not get detected. Booted the old kernel again. Are there any chances to get this fixed or is this a candidate for a buggy BIOS? Attached the devinfo -r from the running kernel. Also the acpidump -dt. Any help would be appreciated. TIA, Andreas kernel: pcib1: irq 16 at device 1.0 on pci0 kernel: pcib1: failed to allocate initial memory window: 0xe8000000-0xefefffff kernel: pcib1: failed to allocate initial prefetch window: 0xd8000000-0xdfffffff kernel: pci1: on pcib1 kernel: vgapci0: irq 16 at device 0.0 on pci1 kernel: hdac0: irq 16 at device 27.0 on pci0 kernel: pcib2: irq 16 at device 28.0 on pci0 kernel: pcib2: failed to allocate initial memory window: 0xe7f00000-0xe7ffffff kernel: pci2: on pcib2 kernel: pcib3: irq 16 at device 28.4 on pci0 kernel: pci3: on pcib3 kernel: pcib4: irq 17 at device 28.5 on pci0 kernel: pcib4: failed to allocate initial memory window: 0xe7e00000-0xe7efffff kernel: pci4: on pcib4 kernel: bge0: irq 17 at device 0.0 on pci4 kernel: bge0: 0x10000 bytes of rid 0x10 res 3 failed (0, 0xffffffffffffffff). kernel: bge0: couldn't map memory kernel: device_attach: bge0 attach returned 6 --------------060402020806010608010809-- From owner-freebsd-current@FreeBSD.ORG Wed Jul 20 20:25:09 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D4C0B106566B for ; Wed, 20 Jul 2011 20:25:09 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 9AB8B8FC26 for ; Wed, 20 Jul 2011 20:25:09 +0000 (UTC) Received: by iwr19 with SMTP id 19so751865iwr.13 for ; Wed, 20 Jul 2011 13:25:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:content-transfer-encoding :in-reply-to:user-agent; bh=R/iL+wCifKIeJAAG1SSMy9D/9cIh5lyOSPiEjWaXF48=; b=AQRL7IXlvYxXyG8VvLtf06vtTTSiEAI7lPN3oc6bleKj3HmEFgNz0Vmhxxxgh5x19v pSXLd/LKQ9+1X8Qu6jsFGymqi2TKEF1noDBL6B/hkYOnLhDnlnDmIl11DQKv/cFRDVGi AQZSsboH6ZchC50wl/1ErVAdxGPrGggp3O9Kc= Received: by 10.231.21.15 with SMTP id h15mr8460999ibb.76.1311193508704; Wed, 20 Jul 2011 13:25:08 -0700 (PDT) Received: from pyunyh@gmail.com ([174.35.1.224]) by mx.google.com with ESMTPS id y3sm363226iba.38.2011.07.20.13.25.06 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 20 Jul 2011 13:25:08 -0700 (PDT) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Wed, 20 Jul 2011 13:24:05 -0700 From: YongHyeon PYUN Date: Wed, 20 Jul 2011 13:24:05 -0700 To: Andrey Smagin Message-ID: <20110720202405.GB11521@michelle.cdnetworks.com> References: <20110630171914.GA12124@michelle.cdnetworks.com> <20110713000541.GC7564@michelle.cdnetworks.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: freebsd-current@freebsd.org Subject: Re: AX88772A AX88772B chipset differences? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jul 2011 20:25:09 -0000 On Wed, Jul 20, 2011 at 11:46:54PM +0400, Andrey Smagin wrote: > > 13 Ð¸ÑŽÐ»Ñ 2011, 04:07 от YongHyeon PYUN : > > On Thu, Jun 30, 2011 at 10:19:14AM -0700, YongHyeon PYUN wrote: > > > On Thu, Jun 30, 2011 at 02:44:48PM +0400, Andrey Smagin wrote: > > > > I have card based on AX88772B. I tried patch axe driver for vendor and > > device IDs. card detected, set up link, but no data received. What else need > > for patch in this driver ? Anybody have datasheet ? > > > > > > ASIX requires a login account to get the data sheet so it's not > > > publicly available to open source developers. > > > AFAIK the difference between AX88772A and AX88772B is IPv4/IPv6 > > > checksum offloading support of AX88772B. The introduction of > > > checksum offloading means they might have changed its RX header > > > format which in turn makes current RX handler to not work. The > > > other difference would be more advanced power saving used in > > > AX8877B but it wouldn't be much difference to axe(4) driver once > > > PHY is correctly woken in initialization phase. > > > Could you show me your diff and verbose boot output to know PHY > > > model and EEPROM data? > > > > I have a minimal patch for AX88772B. It requires more work to > > support TX/RX checksum offloading, flow-control and power saving > > but attached patch would be enough for most cases. > > Let me know whether it works or not. > > Great thanx !!! It work but I not tested under heavy load. Only ping and some Mbytes via nfs. > Thanks for testing. The patch was already committed to HEAD(r224020). I'm implementing TX/RX checksum offloading and flow-control and that feature would be available in near future. Thanks. From owner-freebsd-current@FreeBSD.ORG Wed Jul 20 20:32:44 2011 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 09D441065672; Wed, 20 Jul 2011 20:32:44 +0000 (UTC) (envelope-from andreast@FreeBSD.org) Received: from smtp.fgznet.ch (mail.fgznet.ch [81.92.96.47]) by mx1.freebsd.org (Postfix) with ESMTP id 91A2E8FC08; Wed, 20 Jul 2011 20:32:42 +0000 (UTC) Received: from deuterium.andreas.nets (dhclient-91-190-8-131.flashcable.ch [91.190.8.131]) by smtp.fgznet.ch (8.13.8/8.13.8/Submit_SMTPAUTH) with ESMTP id p6KKWeLR025903; Wed, 20 Jul 2011 22:32:41 +0200 (CEST) (envelope-from andreast@FreeBSD.org) Message-ID: <4E273B68.6020708@FreeBSD.org> Date: Wed, 20 Jul 2011 22:32:40 +0200 From: Andreas Tobler User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.15) Gecko/20110303 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 To: Andreas Tobler References: <4E27399F.7020605@FreeBSD.org> In-Reply-To: <4E27399F.7020605@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.64 on 81.92.96.47 Cc: freebsd-current Subject: Re: pcib1: failed to allocate initial memory window X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jul 2011 20:32:44 -0000 On 20.07.11 22:25, Andreas Tobler wrote: > Hi all, > > Built a fresh kernel today (-CURRENT) on my DELL workstation (amd64). > The network card does not get detected. Booted the old kernel again. > > Are there any chances to get this fixed or is this a candidate for a > buggy BIOS? > Attached the devinfo -r from the running kernel. Also the acpidump -dt. They got eaten .... Here they are: http://people.freebsd.org/~andreast/acpidump_optiplex.txt http://people.freebsd.org/~andreast/devinfo_optiplex.txt Thanks, Andreas From owner-freebsd-current@FreeBSD.ORG Wed Jul 20 20:36:21 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8ADAA10657AA; Wed, 20 Jul 2011 20:36:21 +0000 (UTC) (envelope-from aboyer@averesystems.com) Received: from zimbra.averesystems.com (75-149-8-245-Pennsylvania.hfc.comcastbusiness.net [75.149.8.245]) by mx1.freebsd.org (Postfix) with ESMTP id 468568FC0C; Wed, 20 Jul 2011 20:36:21 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zimbra.averesystems.com (Postfix) with ESMTP id E22D28BC020; Wed, 20 Jul 2011 16:38:53 -0400 (EDT) X-Virus-Scanned: amavisd-new at averesystems.com Received: from zimbra.averesystems.com ([127.0.0.1]) by localhost (zimbra.averesystems.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3mEYwwxTmSWw; Wed, 20 Jul 2011 16:38:47 -0400 (EDT) Received: from [10.0.128.215] (fw.arriad.com [10.0.0.16]) by zimbra.averesystems.com (Postfix) with ESMTPSA id 05E9F8BC003; Wed, 20 Jul 2011 16:38:46 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Andrew Boyer In-Reply-To: <1DB50624F8348F48840F2E2CF6040A9D019060D246@orsmsx508.amr.corp.intel.com> Date: Wed, 20 Jul 2011 16:36:13 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <1FCD1BDB-626E-41C7-BDC6-0FCAA56E7C76@averesystems.com> References: <1DB50624F8348F48840F2E2CF6040A9D019060D246@orsmsx508.amr.corp.intel.com> To: "Vogel, Jack" X-Mailer: Apple Mail (2.1084) Cc: "mav@freebsd.org" , "freebsd-current@freebsd.org" Subject: Re: [patch] Intel SATA controller hiccups, locking X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jul 2011 20:36:21 -0000 Thank you for looking into it! I would really like to get Alexander's = feedback before it gets committed. -Andrew On Jul 20, 2011, at 4:18 PM, Vogel, Jack wrote: > Ran it by the chipset contact internally and he said go for it, you = need me to check it in Andrew? >=20 > Jack >=20 >=20 > -----Original Message----- > From: Andrew Boyer [mailto:aboyer@averesystems.com]=20 > Sent: Wednesday, July 20, 2011 7:45 AM > To: mav@freebsd.org > Cc: freebsd-current@freebsd.org; Vogel, Jack > Subject: [patch] Intel SATA controller hiccups, locking >=20 > Hello Alexander, > I am using the latest ata driver from stable/8 on a system with an = Intel ICH10 controller. ATA_CAM and ATA_STATIC_ID are both off. There = is one drive connected to port 3. SATA is set to Enhanced / IDE mode = (not AHCI) in the BIOS. >> atapci0@pci0:0:31:2: class=3D0x01018f card=3D0x060d15d9 = chip=3D0x3a208086 rev=3D0x00 hdr=3D0x00 >> atapci1@pci0:0:31:5: class=3D0x010185 card=3D0x060d15d9 = chip=3D0x3a268086 rev=3D0x00 hdr=3D0x00 >=20 >> atapci0: port = 0xbff0-0xbff7,0xbf7c-0xbf7f,0xbfe0-0xbfe7,0xbef4-0xbef7,0xbfa0-0xbfaf,0xbf= 60-0xbf6f irq 19 at device 31.2 on pci0 >> atapci0: Reserved 0x10 bytes for rid 0x20 type 4 at 0xbfa0 >> atapci0: [MPSAFE] >> atapci0: [ITHREAD] >> atapci0: Reserved 0x10 bytes for rid 0x24 type 4 at 0xbf60 >> ata2: on atapci0 >> atapci0: Reserved 0x8 bytes for rid 0x10 type 4 at 0xbff0 >> atapci0: Reserved 0x4 bytes for rid 0x14 type 4 at 0xbf7c >> ata2: SATA reset: ports status=3D0x00 >> ata2: p0: SATA connect timeout status=3D00000000 >> ata2: p1: SATA connect timeout status=3D00000000 >> ata2: [MPSAFE] >> ata2: [ITHREAD] >> ata3: on atapci0 >> atapci0: Reserved 0x8 bytes for rid 0x18 type 4 at 0xbfe0 >> atapci0: Reserved 0x4 bytes for rid 0x1c type 4 at 0xbef4 >> ata3: SATA reset: ports status=3D0x08 >> ata3: p0: SATA connect timeout status=3D00000000 >> ata3: p1: SATA connect time=3D0ms status=3D00000123 >> ata3: reset tp1 mask=3D03 ostat0=3D7f ostat1=3D50 >> ata3: stat0=3D0x7f err=3D0x00 lsb=3D0xff msb=3D0xff >> ata3: stat1=3D0x50 err=3D0x01 lsb=3D0x00 msb=3D0x00 >> ata3: reset tp2 stat0=3D7f stat1=3D50 devices=3D0x2 >> ata3: [MPSAFE] >> ata3: [ITHREAD] >=20 >=20 > When under heavy load, the 'atacontrol mode ad0' command sometimes = fails to determine the SATA speed; the drive appears to be missing. I = think the root cause is that chipsets/ata-intel.c does not do any = locking on the ata_intel_sata_sidpr_* routines. The (write address = register) + (access data register) model isn't safe without locking = because two channels share the registers. The ata_intel_sata_cscr_* = routines have the same problem. >=20 > Adding a mutex to a structure stored in ctlr->chipset_data makes the = hiccups go away; see the attached patch. Please advise if this is = something you would like to fix. =20 >=20 > Thank you, > Andrew >=20 -------------------------------------------------- Andrew Boyer aboyer@averesystems.com From owner-freebsd-current@FreeBSD.ORG Wed Jul 20 20:45:11 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B5A88106566C for ; Wed, 20 Jul 2011 20:45:11 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-ew0-f54.google.com (mail-ew0-f54.google.com [209.85.215.54]) by mx1.freebsd.org (Postfix) with ESMTP id 3C80C8FC0C for ; Wed, 20 Jul 2011 20:45:10 +0000 (UTC) Received: by ewy1 with SMTP id 1so1135510ewy.13 for ; Wed, 20 Jul 2011 13:45:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=ABRP3gBuN8H9gDEQCAUm2wg1xQhQ+KSBH5VN8PydL4o=; b=SNbIJckbeeBLcfPCyEvmjXm4FuKzT1PnvWxV18V279TK8e8Q7nVSziWqgD/kFB5qSH CMupUeAn+JA/rvGTiuP8YQovtfySmg63S5f6t6yUPt5mASMkdZwAfNhe6DE1UjPL9Tww 7/1/xlJWVoophHMmV8c63TvwJaxwITAzOABx8= Received: by 10.204.7.201 with SMTP id e9mr2607544bke.126.1311194709921; Wed, 20 Jul 2011 13:45:09 -0700 (PDT) Received: from mavbook.mavhome.dp.ua (pc.mavhome.dp.ua [212.86.226.226]) by mx.google.com with ESMTPS id q1sm4063244faa.1.2011.07.20.13.45.08 (version=SSLv3 cipher=OTHER); Wed, 20 Jul 2011 13:45:08 -0700 (PDT) Sender: Alexander Motin Message-ID: <4E273E46.5070507@FreeBSD.org> Date: Wed, 20 Jul 2011 23:44:54 +0300 From: Alexander Motin User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.15) Gecko/20110310 Thunderbird/3.1.9 MIME-Version: 1.0 To: Andrew Boyer References: <1DB50624F8348F48840F2E2CF6040A9D019060D246@orsmsx508.amr.corp.intel.com> <1FCD1BDB-626E-41C7-BDC6-0FCAA56E7C76@averesystems.com> In-Reply-To: <1FCD1BDB-626E-41C7-BDC6-0FCAA56E7C76@averesystems.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "freebsd-current@freebsd.org" , "Vogel, Jack" Subject: Re: [patch] Intel SATA controller hiccups, locking X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jul 2011 20:45:11 -0000 On 20.07.2011 23:36, Andrew Boyer wrote: > Thank you for looking into it! I would really like to get Alexander's feedback before it gets committed. Generally it looks good, but I would tune few minor places. I'll look on it closer tomorrow. Thank you. > On Jul 20, 2011, at 4:18 PM, Vogel, Jack wrote: > >> Ran it by the chipset contact internally and he said go for it, you need me to check it in Andrew? >> >> -----Original Message----- >> From: Andrew Boyer [mailto:aboyer@averesystems.com] >> Sent: Wednesday, July 20, 2011 7:45 AM >> To: mav@freebsd.org >> Cc: freebsd-current@freebsd.org; Vogel, Jack >> Subject: [patch] Intel SATA controller hiccups, locking >> >> Hello Alexander, >> I am using the latest ata driver from stable/8 on a system with an Intel ICH10 controller. ATA_CAM and ATA_STATIC_ID are both off. There is one drive connected to port 3. SATA is set to Enhanced / IDE mode (not AHCI) in the BIOS. >>> atapci0@pci0:0:31:2: class=0x01018f card=0x060d15d9 chip=0x3a208086 rev=0x00 hdr=0x00 >>> atapci1@pci0:0:31:5: class=0x010185 card=0x060d15d9 chip=0x3a268086 rev=0x00 hdr=0x00 >> >>> atapci0: port 0xbff0-0xbff7,0xbf7c-0xbf7f,0xbfe0-0xbfe7,0xbef4-0xbef7,0xbfa0-0xbfaf,0xbf60-0xbf6f irq 19 at device 31.2 on pci0 >>> atapci0: Reserved 0x10 bytes for rid 0x20 type 4 at 0xbfa0 >>> atapci0: [MPSAFE] >>> atapci0: [ITHREAD] >>> atapci0: Reserved 0x10 bytes for rid 0x24 type 4 at 0xbf60 >>> ata2: on atapci0 >>> atapci0: Reserved 0x8 bytes for rid 0x10 type 4 at 0xbff0 >>> atapci0: Reserved 0x4 bytes for rid 0x14 type 4 at 0xbf7c >>> ata2: SATA reset: ports status=0x00 >>> ata2: p0: SATA connect timeout status=00000000 >>> ata2: p1: SATA connect timeout status=00000000 >>> ata2: [MPSAFE] >>> ata2: [ITHREAD] >>> ata3: on atapci0 >>> atapci0: Reserved 0x8 bytes for rid 0x18 type 4 at 0xbfe0 >>> atapci0: Reserved 0x4 bytes for rid 0x1c type 4 at 0xbef4 >>> ata3: SATA reset: ports status=0x08 >>> ata3: p0: SATA connect timeout status=00000000 >>> ata3: p1: SATA connect time=0ms status=00000123 >>> ata3: reset tp1 mask=03 ostat0=7f ostat1=50 >>> ata3: stat0=0x7f err=0x00 lsb=0xff msb=0xff >>> ata3: stat1=0x50 err=0x01 lsb=0x00 msb=0x00 >>> ata3: reset tp2 stat0=7f stat1=50 devices=0x2 >>> ata3: [MPSAFE] >>> ata3: [ITHREAD] >> >> >> When under heavy load, the 'atacontrol mode ad0' command sometimes fails to determine the SATA speed; the drive appears to be missing. I think the root cause is that chipsets/ata-intel.c does not do any locking on the ata_intel_sata_sidpr_* routines. The (write address register) + (access data register) model isn't safe without locking because two channels share the registers. The ata_intel_sata_cscr_* routines have the same problem. >> >> Adding a mutex to a structure stored in ctlr->chipset_data makes the hiccups go away; see the attached patch. Please advise if this is something you would like to fix. -- Alexander Motin From owner-freebsd-current@FreeBSD.ORG Wed Jul 20 22:53:11 2011 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1CF04106564A; Wed, 20 Jul 2011 22:53:11 +0000 (UTC) (envelope-from swills@FreeBSD.org) Received: from mouf.net (mouf.net [204.109.58.86]) by mx1.freebsd.org (Postfix) with ESMTP id 8070E8FC12; Wed, 20 Jul 2011 22:53:10 +0000 (UTC) Received: from meatwad.mouf.net (cpe-065-190-149-241.nc.res.rr.com [65.190.149.241]) (authenticated bits=0) by mouf.net (8.14.4/8.14.4) with ESMTP id p6KMMXkV081967 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Wed, 20 Jul 2011 18:22:34 -0400 (EDT) (envelope-from swills@FreeBSD.org) Message-ID: <4E275529.7050802@FreeBSD.org> Date: Wed, 20 Jul 2011 18:22:33 -0400 From: Steve Wills User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.17) Gecko/20110531 Thunderbird/3.1.10 MIME-Version: 1.0 To: John Baldwin References: <4E263EFE.3040200@FreeBSD.org> <201107200741.26362.jhb@freebsd.org> <565082b8e8b3e358266054e58e591e12@bluelife.at> <201107200904.45647.jhb@freebsd.org> In-Reply-To: <201107200904.45647.jhb@freebsd.org> X-Enigmail-Version: 1.1.2 Content-Type: multipart/mixed; boundary="------------010304030007080202090802" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (mouf.net [204.109.58.86]); Wed, 20 Jul 2011 18:22:34 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.96.2 at mouf.net X-Virus-Status: Clean X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-current@FreeBSD.org, Bernhard Froehlich Subject: Re: em problem in virtualbox since the weekend X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jul 2011 22:53:11 -0000 This is a multi-part message in MIME format. --------------010304030007080202090802 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 07/20/11 09:04, John Baldwin wrote: > On Wednesday, July 20, 2011 8:33:07 am Bernhard Froehlich wrote: >> On Wed, 20 Jul 2011 07:41:26 -0400, John Baldwin wrote: >>> On Tuesday, July 19, 2011 10:35:42 pm Steve Wills wrote: >>>> Hi, >>>> >>>> While testing some other things, I found -CURRENT from yesterday doesn't >>>> work with the em0 in my VirtualBox 4.0.8 (a little out of date >>>> admittedly). It worked Friday or Saturday I think. Anyone else seen this >>>> or should I open a PR? Has the code changed or am I perhaps >>>> misremembering dates? The error reported is: >>>> >>>> em0: Unable to allocate bus resource: memory >>>> em0: Allocation of PCI resources failed >>> >>> This is due to a bug in VirtualBox's BIOS implementation. Someone >>> should file >>> a bug report with VirtualBox to ask them to fix their BIOS. The problem is >>> that they claim that the Host-PCI bridge in their system only decodes >>> addresses 0xa0000-0xbffff (i.e. the VGA window) via the "Producer" resources >>> in the _CRS method of the Host-PCI bridge device. This tells the OS >>> that all >>> the existing PCI devices are using invalid memory address ranges but that >>> there is also no available address space to allocate for PCI devices such as >>> em0. >>> >>> You can workaround this by setting "debug.acpi.disabled=hostres" until >>> VirtualBox fixes their code. I'm happy to provide further >>> clarification to an >>> existing VirtaulBox bug report if needed. >> >> Thanks a lot for the analysis! I've talked to one of the virtualbox >> developers about that but they are not aware of such problems with Linux >> or Windows guests yet. So they are currently unsure if it's a VirtualBox >> or FreeBSD fault and if it's their fault why it works fine with other >> guests. I'm also unsure because I haven't heard of that problem before >> and now multiple people complain. That looks more like a FreeBSD related >> problem on current or stable. >> >> I think it would be good if someone could try to reproduce that with >> emulators/virtualbox-ose-legacy which is 3.2.12 to get some vbox dev >> look into the problem again. > > FreeBSD just started honoring this setting in the BIOS this week and ignored > it previously. Can you get an acpidump from within VirtaulBox? I might be > able to point to a bug in it directly if so. > Thanks for the info! I've attached the acpidump and also posted a copy here: http://people.freebsd.org/~swills/vbox-4.0.8.asl.gz in case the mailing list eats it. Steve -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (FreeBSD) iQEcBAEBAgAGBQJOJ1UoAAoJEPXPYrMgexuhhngIAJ/gyw1DMCciYDOw2Ek53dCb Cx2zFFm32THagLFIewKSL7RDKr6fNcNWuAdfFm/zpKq8nGUjA16p9A4eoOvdVc5u MhAu7oPZlnx9pX1o/JRjW0mtWglrHvKMapsptzlGOmS8PZMQz9s+L+IvGhsY8+qV avQ0V/w/AwG+T7x/vaCPpPdDPubuxT7vO+A5x9r4aUtFbKWIzF/1rsbq3cjIiGXw ExMpcdDBGRyLsPpB4fzhjb/drOQMJAkO2PnPPkWDociWCnC8Da/qCr6keD1lZPtD wx0UnMd/pyzJKVAuf4+VcifABIJIZeRqStIH7CB1fOKhcT+HDwatbKrEFGSvEMs= =COvj -----END PGP SIGNATURE----- --------------010304030007080202090802 Content-Type: application/octet-stream; name="vbox-4.0.8.asl.gz.sig" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="vbox-4.0.8.asl.gz.sig" iQEcBAABAgAGBQJOJ1UpAAoJEPXPYrMgexuhNxkIAK3HJ5Du4yQYivihQ87USagTHcTiytS2 PzPxTpVd+Rh1sHVAkn2UnNKowWh/7WhSdgWEqGp0ewBqtsko7aWSXsCyyuMcKubBdjTIPkIA vIMb+78iWjZN9VOvE6OLkIcQwhL4MIqHJoHHaH9Z3D99S67GCcC1IuDA4U5JXWyD12PKhMER KuwVwvRW35SI1M32hm1DSHIdeMt8U/r9Jz9qT5ECM6NsIxcmmPTFPD/VZXcZemfgrghKfVXZ lVg2y4scZd08GBsSeNwNkg0XsV1+JzNUk4JMXbefiXNke9Vzp2rohziDPWG5e3Wrvnr7uVaY ZbTao6re5G7W4OK7goZ7ipo= --------------010304030007080202090802-- From owner-freebsd-current@FreeBSD.ORG Wed Jul 20 23:19:40 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 158CB1065676; Wed, 20 Jul 2011 23:19:40 +0000 (UTC) (envelope-from rysto32@gmail.com) Received: from mail-ew0-f54.google.com (mail-ew0-f54.google.com [209.85.215.54]) by mx1.freebsd.org (Postfix) with ESMTP id 238628FC08; Wed, 20 Jul 2011 23:19:38 +0000 (UTC) Received: by ewy1 with SMTP id 1so1246441ewy.13 for ; Wed, 20 Jul 2011 16:19:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=z6ePna1RH0f8rxNEe0c9pQ6fjDCoS8lEEc/onlMBfH4=; b=nx2VKpZkj0cjy+meOQpJtfAyf0gbgW4QoFkMhm59TeP/1kxl5O9j9Czr3br5M0+H05 wMDmn7kNF/CzP9jB4C7+XgoMf+ZGWFyuS0YUHp4IG0WUMVAjQ0n2eETzfy2+BWsPJDeA rClPVAL0/hqBx66AoZDeJSCerEuEEAGgletNc= MIME-Version: 1.0 Received: by 10.213.29.196 with SMTP id r4mr1359444ebc.52.1311203977963; Wed, 20 Jul 2011 16:19:37 -0700 (PDT) Received: by 10.213.15.70 with HTTP; Wed, 20 Jul 2011 16:19:37 -0700 (PDT) In-Reply-To: <565082b8e8b3e358266054e58e591e12@bluelife.at> References: <4E263EFE.3040200@FreeBSD.org> <201107200741.26362.jhb@freebsd.org> <565082b8e8b3e358266054e58e591e12@bluelife.at> Date: Wed, 20 Jul 2011 19:19:37 -0400 Message-ID: From: Ryan Stone To: Bernhard Froehlich Content-Type: text/plain; charset=ISO-8859-1 Cc: Steve Wills , freebsd-current@freebsd.org Subject: Re: em problem in virtualbox since the weekend X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jul 2011 23:19:40 -0000 On Wed, Jul 20, 2011 at 8:33 AM, Bernhard Froehlich wrote: > I think it would be good if someone could try to reproduce that with > emulators/virtualbox-ose-legacy which is 3.2.12 to get some vbox dev > look into the problem again. I saw the problem this weekend on a Linux host running virtualbox 3.2.8. I can From owner-freebsd-current@FreeBSD.ORG Thu Jul 21 07:08:25 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1233) id EB4B3106566B; Thu, 21 Jul 2011 07:08:25 +0000 (UTC) Date: Thu, 21 Jul 2011 07:08:25 +0000 From: Alexander Best To: freebsd-current@freebsd.org Message-ID: <20110721070825.GA80840@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Subject: buildworld failing in lib/libc/db/btree X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jul 2011 07:08:26 -0000 hi there, for some reason buildworld always fails in lib/libc/db/btree :( clang: /usr/bin/clang -O2 -pipe -fno-strict-aliasing -fno-omit-frame-pointer -march=core2 -I/usr/git-freebsd-head/lib/libc/include -I/usr/git-freebsd-head/lib/libc/../../include -I/usr/git-freebsd-head/lib/libc/amd64 -DNLS -D__DBINTERFACE_PRIVATE -I/usr/git-freebsd-head/lib/libc/. /usr/git-freebsd-head/lib/libc/db/btree/bt_split.c:486:2: warning: implicit declaration of function '__PAST_END' is invalid in C99 [-Wimplicit-function-declaration] __PAST_END(h->linp, 1) = h->upper -= NRINTERNAL; ^ /usr/git-freebsd-head/lib/libc/db/btree/bt_split.c:486:25: error: expression is not assignable __PAST_END(h->linp, 1) = h->upper -= NRINTERNAL; ~~~~~~~~~~~~~~~~~~~~~~ ^ /usr/git-freebsd-head/lib/libc/db/btree/bt_split.c:538:26: error: expression is not assignable __PAST_END(h->linp, 1) = h->upper -= nbytes; ~~~~~~~~~~~~~~~~~~~~~~ ^ /usr/git-freebsd-head/lib/libc/db/btree/bt_split.c:554:26: error: expression is not assignable __PAST_END(h->linp, 1) = h->upper -= nbytes; ~~~~~~~~~~~~~~~~~~~~~~ ^ 1 warning and 3 errors generated. *** Error code 1 Stop in /usr/git-freebsd-head/lib/libc. *** Error code 1 Stop in /usr/git-freebsd-head. *** Error code 1 Stop in /usr/git-freebsd-head. *** Error code 1 Stop in /usr/git-freebsd-head. *** Error code 1 Stop in /usr/git-freebsd-head. gcc: /usr/bin/cc -O2 -pipe -fno-strict-aliasing -fno-omit-frame-pointer -frename-registers -march=core2 -I/usr/git-freebsd-head/lib/libc/include -I/usr/git-freebsd-head/lib/libc/../../include -I/usr/git-freebsd-head/lib/libc/amd64 -DNLS -D__DBINTERFACE_PRIVATE -I/usr/git-freebsd /usr/git-freebsd-head/lib/libc/db/btree/bt_split.c: In function 'bt_rroot': /usr/git-freebsd-head/lib/libc/db/btree/bt_split.c:486: warning: implicit declaration of function '__PAST_END' /usr/git-freebsd-head/lib/libc/db/btree/bt_split.c:486: error: lvalue required as left operand of assignment /usr/git-freebsd-head/lib/libc/db/btree/bt_split.c: In function 'bt_broot': /usr/git-freebsd-head/lib/libc/db/btree/bt_split.c:538: error: lvalue required as left operand of assignment /usr/git-freebsd-head/lib/libc/db/btree/bt_split.c:554: error: lvalue required as left operand of assignment *** Error code 1 Stop in /usr/git-freebsd-head/lib/libc. *** Error code 1 Stop in /usr/git-freebsd-head. *** Error code 1 Stop in /usr/git-freebsd-head. *** Error code 1 Stop in /usr/git-freebsd-head. *** Error code 1 Stop in /usr/git-freebsd-head. ...any recommendations how i can fix this? i'm tracking HEAD btw. cheers. alex From owner-freebsd-current@FreeBSD.ORG Thu Jul 21 07:17:22 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5658C106564A; Thu, 21 Jul 2011 07:17:22 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from anubis.delphij.net (anubis.delphij.net [IPv6:2001:470:1:117::25]) by mx1.freebsd.org (Postfix) with ESMTP id 3CFE08FC15; Thu, 21 Jul 2011 07:17:22 +0000 (UTC) Received: from delta.delphij.net (c-76-102-50-245.hsd1.ca.comcast.net [76.102.50.245]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by anubis.delphij.net (Postfix) with ESMTPSA id EEFC39664; Thu, 21 Jul 2011 00:17:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=delphij.net; s=anubis; t=1311232642; bh=t+Bw/UjG4f0j9yWVg+4c5GSaASlCyRnWRdPp9dXeQWs=; h=Message-ID:Date:From:Reply-To:MIME-Version:To:CC:Subject: References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=FJutSOE/VpMTd5bT7UpHx5Tkyp5LncOXU9EoF3wodzPyYR9iT4WmUD0WDnjpXFF3K SNHynKrWqCbPcRFLwJgwY3pDZUZpgh58rNTjhFhPnGg6fFYJRK6lfS9mSZTpAd1KVd 4P83njF5VFcFa4yhWHdNluNdHvbFEWvtE8wEfePo= Message-ID: <4E27D281.6010507@delphij.net> Date: Thu, 21 Jul 2011 00:17:21 -0700 From: Xin LI Organization: The FreeBSD Project MIME-Version: 1.0 To: Alexander Best References: <20110721070825.GA80840@freebsd.org> In-Reply-To: <20110721070825.GA80840@freebsd.org> OpenPGP: id=3FCA37C1; url=http://www.delphij.net/delphij.asc Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: buildworld failing in lib/libc/db/btree X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: d@delphij.net List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jul 2011 07:17:22 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 07/21/11 00:08, Alexander Best wrote: > hi there, > > for some reason buildworld always fails in lib/libc/db/btree :( > > clang: > > /usr/bin/clang -O2 -pipe -fno-strict-aliasing -fno-omit-frame-pointer > -march=core2 -I/usr/git-freebsd-head/lib/libc/include > -I/usr/git-freebsd-head/lib/libc/../../include > -I/usr/git-freebsd-head/lib/libc/amd64 -DNLS -D__DBINTERFACE_PRIVATE > -I/usr/git-freebsd-head/lib/libc/. > /usr/git-freebsd-head/lib/libc/db/btree/bt_split.c:486:2: warning: > implicit declaration of function '__PAST_END' is invalid in C99 > [-Wimplicit-function-declaration] __PAST_END(h->linp, 1) = h->upper > -= NRINTERNAL; This is quite weird, __PAST_END is defined in sys/param.h... And it compiled just fine here, what's your hosting system? Cheers, - -- Xin LI https://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (FreeBSD) iQEcBAEBCAAGBQJOJ9KBAAoJEATO+BI/yjfBnRQIAKGRJezmtmjmICp68nEIYmTR /VH/Y+ubIwCFBagwAKZ1qu+xQD+IG50cyAYujva/5loSejPMGQY4xFsV/iyptZhX g2XnTmO37TQl+gfQPE0Vj3pats22acsneb0UbABP2Ah2rzWN/sEV4B5RFbVYUpNq G5dFQR1Xdkx3qMkoZotFvVzvclMyxguJZDPy4HHIm8FqkjQE93m0x6KJQTj7a/80 nM6u7lyyD/8obhfb7ms1tc7hO3TLFqOv92IdYqTjl7RHTetj+Aa5MECUaQDJqeUP PoOBLpUWjDrFefrXtlCXhSK0mlLJcezLPGQP6ZqgYTUwNcug1zS69gsHpCaT+L0= =GRG2 -----END PGP SIGNATURE----- From owner-freebsd-current@FreeBSD.ORG Thu Jul 21 07:26:36 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1233) id 50C5B1065672; Thu, 21 Jul 2011 07:26:36 +0000 (UTC) Date: Thu, 21 Jul 2011 07:26:36 +0000 From: Alexander Best To: d@delphij.net Message-ID: <20110721072636.GA85496@freebsd.org> References: <20110721070825.GA80840@freebsd.org> <4E27D281.6010507@delphij.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4E27D281.6010507@delphij.net> Cc: freebsd-current@freebsd.org Subject: Re: buildworld failing in lib/libc/db/btree X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jul 2011 07:26:36 -0000 On Thu Jul 21 11, Xin LI wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > On 07/21/11 00:08, Alexander Best wrote: > > hi there, > > > > for some reason buildworld always fails in lib/libc/db/btree :( > > > > clang: > > > > /usr/bin/clang -O2 -pipe -fno-strict-aliasing -fno-omit-frame-pointer > > -march=core2 -I/usr/git-freebsd-head/lib/libc/include > > -I/usr/git-freebsd-head/lib/libc/../../include > > -I/usr/git-freebsd-head/lib/libc/amd64 -DNLS -D__DBINTERFACE_PRIVATE > > -I/usr/git-freebsd-head/lib/libc/. > > /usr/git-freebsd-head/lib/libc/db/btree/bt_split.c:486:2: warning: > > implicit declaration of function '__PAST_END' is invalid in C99 > > [-Wimplicit-function-declaration] __PAST_END(h->linp, 1) = h->upper > > -= NRINTERNAL; > > This is quite weird, __PAST_END is defined in sys/param.h... > > And it compiled just fine here, what's your hosting system? amd64. param.h might be the problem: otaku% grep PAST_END /usr/git-freebsd-head/sys/sys/param.h #define __PAST_END(array, offset) (((typeof(*(array)) *)(array))[offset]) otaku% grep PAST_END /usr/include/sys/param.h ...maybe copying /usr/git-freebsd-head/sys/sys/param.h to /usr/include/sys manually will solve the issue? cheers. alex > > Cheers, > - -- > Xin LI https://www.delphij.net/ > FreeBSD - The Power to Serve! Live free or die > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2.0.17 (FreeBSD) > > iQEcBAEBCAAGBQJOJ9KBAAoJEATO+BI/yjfBnRQIAKGRJezmtmjmICp68nEIYmTR > /VH/Y+ubIwCFBagwAKZ1qu+xQD+IG50cyAYujva/5loSejPMGQY4xFsV/iyptZhX > g2XnTmO37TQl+gfQPE0Vj3pats22acsneb0UbABP2Ah2rzWN/sEV4B5RFbVYUpNq > G5dFQR1Xdkx3qMkoZotFvVzvclMyxguJZDPy4HHIm8FqkjQE93m0x6KJQTj7a/80 > nM6u7lyyD/8obhfb7ms1tc7hO3TLFqOv92IdYqTjl7RHTetj+Aa5MECUaQDJqeUP > PoOBLpUWjDrFefrXtlCXhSK0mlLJcezLPGQP6ZqgYTUwNcug1zS69gsHpCaT+L0= > =GRG2 > -----END PGP SIGNATURE----- From owner-freebsd-current@FreeBSD.ORG Thu Jul 21 07:29:15 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0EF7A106566B for ; Thu, 21 Jul 2011 07:29:15 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from anubis.delphij.net (anubis.delphij.net [IPv6:2001:470:1:117::25]) by mx1.freebsd.org (Postfix) with ESMTP id E938D8FC08 for ; Thu, 21 Jul 2011 07:29:14 +0000 (UTC) Received: from delta.delphij.net (c-76-102-50-245.hsd1.ca.comcast.net [76.102.50.245]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by anubis.delphij.net (Postfix) with ESMTPSA id B965296D5; Thu, 21 Jul 2011 00:29:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=delphij.net; s=anubis; t=1311233354; bh=FVI5gxFKp30JmpKiPGhAuIG78d+ED1vZJOVH/MqvC7A=; h=Message-ID:Date:From:Reply-To:MIME-Version:To:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=ps992OiJ05E+6qroh7tLVEqvnq9YY3X8vmhARuEVjeO9xP32sBUEHs0XfyZOlneQd 4xHFmXIfNqD5pWvjbVJ63S1IMldU8Fps4hl8f+vHNxDfpsnFgKLTqHnQHVCwZLHS7d xp2Lv2nvIma4Iivl8utvAKCagufKxtoZuqnAsyF8= Message-ID: <4E27D54A.6090506@delphij.net> Date: Thu, 21 Jul 2011 00:29:14 -0700 From: Xin LI Organization: The FreeBSD Project MIME-Version: 1.0 To: freebsd-current@freebsd.org References: <20110721070825.GA80840@freebsd.org> <4E27D281.6010507@delphij.net> <20110721072636.GA85496@freebsd.org> In-Reply-To: <20110721072636.GA85496@freebsd.org> OpenPGP: id=3FCA37C1; url=http://www.delphij.net/delphij.asc Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: buildworld failing in lib/libc/db/btree X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: d@delphij.net List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jul 2011 07:29:15 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 07/21/11 00:26, Alexander Best wrote: > On Thu Jul 21 11, Xin LI wrote: On 07/21/11 00:08, Alexander Best > wrote: >>>> hi there, >>>> >>>> for some reason buildworld always fails in lib/libc/db/btree >>>> :( >>>> >>>> clang: >>>> >>>> /usr/bin/clang -O2 -pipe -fno-strict-aliasing >>>> -fno-omit-frame-pointer -march=core2 >>>> -I/usr/git-freebsd-head/lib/libc/include >>>> -I/usr/git-freebsd-head/lib/libc/../../include >>>> -I/usr/git-freebsd-head/lib/libc/amd64 -DNLS >>>> -D__DBINTERFACE_PRIVATE -I/usr/git-freebsd-head/lib/libc/. >>>> /usr/git-freebsd-head/lib/libc/db/btree/bt_split.c:486:2: >>>> warning: implicit declaration of function '__PAST_END' is >>>> invalid in C99 [-Wimplicit-function-declaration] >>>> __PAST_END(h->linp, 1) = h->upper -= NRINTERNAL; > > This is quite weird, __PAST_END is defined in sys/param.h... > > And it compiled just fine here, what's your hosting system? > >> amd64. param.h might be the problem: > >> otaku% grep PAST_END /usr/git-freebsd-head/sys/sys/param.h #define >> __PAST_END(array, offset) (((typeof(*(array)) *)(array))[offset]) >> otaku% grep PAST_END /usr/include/sys/param.h > >> ...maybe copying /usr/git-freebsd-head/sys/sys/param.h to >> /usr/include/sys manually will solve the issue? Likely, but, sys/param.h is MI, and, if you're buildworld'ing from an older world from a cleaned checkout source, it sounds like a bug to me... Cheers, - -- Xin LI https://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (FreeBSD) iQEcBAEBCAAGBQJOJ9VJAAoJEATO+BI/yjfB1MMH/RwsPaRQ0bi6PEbZXv67DcjQ wbAxgKrgFUdSYWuLy5IRgc99aAKmiQ3g4C3AVDHNRpe1/2g3oO5rvAVCTAVCaN5L Ndk0FaHVRC498OjJfvEqqWnXMOxV8XmPlOuMoECK0J9TpXtpIP4laZHpvjmSf/7j m6kCxEwQE0gO47F2tWj3Rf1NbOee9o9BTy8Q8rSw0hooH0VeMUGrfFQLxVIb/0GO 0rwCyjFcegLWL7xefya2a91fP7pYVuvqX/sgUqwjuvwspHoZWTBeT75X+DlwaIYV yuFjaZj5EjtR6mdGkdEq0IHlG3HbtgLnDqsICNk57nTNvrPctA6wOMueA/zhHB8= =6MJ8 -----END PGP SIGNATURE----- From owner-freebsd-current@FreeBSD.ORG Thu Jul 21 07:29:15 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1FEE31065672 for ; Thu, 21 Jul 2011 07:29:15 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from anubis.delphij.net (anubis.delphij.net [IPv6:2001:470:1:117::25]) by mx1.freebsd.org (Postfix) with ESMTP id 062F18FC0A for ; Thu, 21 Jul 2011 07:29:15 +0000 (UTC) Received: from delta.delphij.net (c-76-102-50-245.hsd1.ca.comcast.net [76.102.50.245]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by anubis.delphij.net (Postfix) with ESMTPSA id CCE6196D6; Thu, 21 Jul 2011 00:29:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=delphij.net; s=anubis; t=1311233354; bh=ef1srO/uxykRBCaaG05uWlf/4+HqH3ooaST83iGCVM8=; h=Message-ID:Date:From:Reply-To:MIME-Version:To:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=jUGlb+6BOi3FHqUd60BjVyNPNySp/GOutwAcB9oGYaKZ7ttMlg4WYJ9ZV9TTHiEYO 6PYko8JWVW6/vSzc7Udl4czUHFf9S3uGAFP2/himkCT/7+z0w0ejJz0aJFLmGN3G+E VwVzHKfXmVRUyI3TrZbEZaAkuGcPqsTyD8/3z8p0= Message-ID: <4E27D54A.5030109@delphij.net> Date: Thu, 21 Jul 2011 00:29:14 -0700 From: Xin LI Organization: The FreeBSD Project MIME-Version: 1.0 To: freebsd-current@freebsd.org References: <20110721070825.GA80840@freebsd.org> <4E27D281.6010507@delphij.net> <20110721072636.GA85496@freebsd.org> In-Reply-To: <20110721072636.GA85496@freebsd.org> OpenPGP: id=3FCA37C1; url=http://www.delphij.net/delphij.asc Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: buildworld failing in lib/libc/db/btree X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: d@delphij.net List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jul 2011 07:29:15 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 07/21/11 00:26, Alexander Best wrote: Likely, but, sys/param.h is MI, and, if you're buildworld'ing from an older world from a cleaned checkout source, it sounds like a bug to me... Cheers, - -- Xin LI https://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (FreeBSD) iQEcBAEBCAAGBQJOJ9VJAAoJEATO+BI/yjfB1MMH/RwsPaRQ0bi6PEbZXv67DcjQ wbAxgKrgFUdSYWuLy5IRgc99aAKmiQ3g4C3AVDHNRpe1/2g3oO5rvAVCTAVCaN5L Ndk0FaHVRC498OjJfvEqqWnXMOxV8XmPlOuMoECK0J9TpXtpIP4laZHpvjmSf/7j m6kCxEwQE0gO47F2tWj3Rf1NbOee9o9BTy8Q8rSw0hooH0VeMUGrfFQLxVIb/0GO 0rwCyjFcegLWL7xefya2a91fP7pYVuvqX/sgUqwjuvwspHoZWTBeT75X+DlwaIYV yuFjaZj5EjtR6mdGkdEq0IHlG3HbtgLnDqsICNk57nTNvrPctA6wOMueA/zhHB8= =6MJ8 -----END PGP SIGNATURE----- From owner-freebsd-current@FreeBSD.ORG Thu Jul 21 09:18:47 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 53090106564A; Thu, 21 Jul 2011 09:18:47 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (cl-327.ede-01.nl.sixxs.net [IPv6:2001:7b8:2ff:146::2]) by mx1.freebsd.org (Postfix) with ESMTP id 17E068FC18; Thu, 21 Jul 2011 09:18:47 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7:0:7469:953f:9d81:458a] (unknown [IPv6:2001:7b8:3a7:0:7469:953f:9d81:458a]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id E012A5C37; Thu, 21 Jul 2011 11:18:45 +0200 (CEST) Message-ID: <4E27EEF6.6060401@FreeBSD.org> Date: Thu, 21 Jul 2011 11:18:46 +0200 From: Dimitry Andric Organization: The FreeBSD Project User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: Alexander Best References: <20110721070825.GA80840@freebsd.org> In-Reply-To: <20110721070825.GA80840@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: buildworld failing in lib/libc/db/btree X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jul 2011 09:18:47 -0000 On 2011-07-21 09:08, Alexander Best wrote: > for some reason buildworld always fails in lib/libc/db/btree :( > > clang: > > /usr/bin/clang -O2 -pipe -fno-strict-aliasing -fno-omit-frame-pointer -march=core2 -I/usr/git-freebsd-head/lib/libc/include -I/usr/git-freebsd-head/lib/libc/../../include -I/usr/git-freebsd-head/lib/libc/amd64 -DNLS -D__DBINTERFACE_PRIVATE -I/usr/git-freebsd-head/lib/libc/. > /usr/git-freebsd-head/lib/libc/db/btree/bt_split.c:486:2: warning: implicit declaration of function '__PAST_END' is invalid in C99 [-Wimplicit-function-declaration] > __PAST_END(h->linp, 1) = h->upper -= NRINTERNAL; > ^ What have you set CC to (in e.g make.conf, src.conf, in the environment, or on the command line)? If you are including any path, e.g. CC=/usr/bin/clang, buildworld will not work. Remove the path and try again. From owner-freebsd-current@FreeBSD.ORG Thu Jul 21 13:45:08 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1233) id A57881065674; Thu, 21 Jul 2011 13:45:08 +0000 (UTC) Date: Thu, 21 Jul 2011 13:45:08 +0000 From: Alexander Best To: Dimitry Andric Message-ID: <20110721134508.GA39498@freebsd.org> References: <20110721070825.GA80840@freebsd.org> <4E27EEF6.6060401@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4E27EEF6.6060401@FreeBSD.org> Cc: freebsd-current@freebsd.org Subject: Re: buildworld failing in lib/libc/db/btree X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jul 2011 13:45:08 -0000 On Thu Jul 21 11, Dimitry Andric wrote: > On 2011-07-21 09:08, Alexander Best wrote: > >for some reason buildworld always fails in lib/libc/db/btree :( > > > >clang: > > > >/usr/bin/clang -O2 -pipe -fno-strict-aliasing -fno-omit-frame-pointer > >-march=core2 -I/usr/git-freebsd-head/lib/libc/include > >-I/usr/git-freebsd-head/lib/libc/../../include > >-I/usr/git-freebsd-head/lib/libc/amd64 -DNLS -D__DBINTERFACE_PRIVATE > >-I/usr/git-freebsd-head/lib/libc/. > >/usr/git-freebsd-head/lib/libc/db/btree/bt_split.c:486:2: warning: > >implicit declaration of function '__PAST_END' is invalid in C99 > >[-Wimplicit-function-declaration] > > __PAST_END(h->linp, 1) = h->upper -= NRINTERNAL; > > ^ > > What have you set CC to (in e.g make.conf, src.conf, in the environment, > or on the command line)? > > If you are including any path, e.g. CC=/usr/bin/clang, buildworld will > not work. Remove the path and try again. THANKS! ...exactly that was the problem. :) after changing CC/CXX so it doesn't contain a full path, buildworld succeeded! cheers. alex From owner-freebsd-current@FreeBSD.ORG Thu Jul 21 14:03:57 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C43A91065672; Thu, 21 Jul 2011 14:03:57 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (cl-327.ede-01.nl.sixxs.net [IPv6:2001:7b8:2ff:146::2]) by mx1.freebsd.org (Postfix) with ESMTP id 8868B8FC1A; Thu, 21 Jul 2011 14:03:57 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7:0:7469:953f:9d81:458a] (unknown [IPv6:2001:7b8:3a7:0:7469:953f:9d81:458a]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id B08415C37; Thu, 21 Jul 2011 16:03:56 +0200 (CEST) Message-ID: <4E2831CD.6040800@FreeBSD.org> Date: Thu, 21 Jul 2011 16:03:57 +0200 From: Dimitry Andric Organization: The FreeBSD Project User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: Alexander Best References: <20110721070825.GA80840@freebsd.org> <4E27EEF6.6060401@FreeBSD.org> <20110721134508.GA39498@freebsd.org> In-Reply-To: <20110721134508.GA39498@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: buildworld failing in lib/libc/db/btree X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jul 2011 14:03:57 -0000 On 2011-07-21 15:45, Alexander Best wrote: ... >> If you are including any path, e.g. CC=/usr/bin/clang, buildworld will >> not work. Remove the path and try again. > > THANKS! > > ...exactly that was the problem. :) after changing CC/CXX so it doesn't contain > a full path, buildworld succeeded! The problem here was that buildworld builds a bootstrap compiler under /usr/obj, but if you specify ${CC} with an absolute path, it fails to use it! (The bootstrap compiler has its search paths adjusted, so it only looks under /usr/obj for include files, libraries and so on.) This is actually a problem that needs solving, but it won't happen for 9.0, unfortunately... From owner-freebsd-current@FreeBSD.ORG Thu Jul 21 15:53:42 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 670D9106567A; Thu, 21 Jul 2011 15:53:42 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 253C98FC24; Thu, 21 Jul 2011 15:53:42 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id A085746B0D; Thu, 21 Jul 2011 11:53:41 -0400 (EDT) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 3662E8A03E; Thu, 21 Jul 2011 11:53:41 -0400 (EDT) From: John Baldwin To: Steve Wills Date: Thu, 21 Jul 2011 11:53:23 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110617; KDE/4.5.5; amd64; ; ) References: <4E263EFE.3040200@FreeBSD.org> <201107200904.45647.jhb@freebsd.org> <4E275529.7050802@FreeBSD.org> In-Reply-To: <4E275529.7050802@FreeBSD.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201107211153.23979.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Thu, 21 Jul 2011 11:53:41 -0400 (EDT) Cc: freebsd-current@freebsd.org, Bernhard Froehlich Subject: Re: em problem in virtualbox since the weekend X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jul 2011 15:53:42 -0000 On Wednesday, July 20, 2011 6:22:33 pm Steve Wills wrote: > On 07/20/11 09:04, John Baldwin wrote: > > On Wednesday, July 20, 2011 8:33:07 am Bernhard Froehlich wrote: > >> On Wed, 20 Jul 2011 07:41:26 -0400, John Baldwin wrote: > >>> On Tuesday, July 19, 2011 10:35:42 pm Steve Wills wrote: > >>>> Hi, > >>>> > >>>> While testing some other things, I found -CURRENT from yesterday doesn't > >>>> work with the em0 in my VirtualBox 4.0.8 (a little out of date > >>>> admittedly). It worked Friday or Saturday I think. Anyone else seen this > >>>> or should I open a PR? Has the code changed or am I perhaps > >>>> misremembering dates? The error reported is: > >>>> > >>>> em0: Unable to allocate bus resource: memory > >>>> em0: Allocation of PCI resources failed > >>> > >>> This is due to a bug in VirtualBox's BIOS implementation. Someone > >>> should file > >>> a bug report with VirtualBox to ask them to fix their BIOS. The problem is > >>> that they claim that the Host-PCI bridge in their system only decodes > >>> addresses 0xa0000-0xbffff (i.e. the VGA window) via the "Producer" resources > >>> in the _CRS method of the Host-PCI bridge device. This tells the OS > >>> that all > >>> the existing PCI devices are using invalid memory address ranges but that > >>> there is also no available address space to allocate for PCI devices such as > >>> em0. > >>> > >>> You can workaround this by setting "debug.acpi.disabled=hostres" until > >>> VirtualBox fixes their code. I'm happy to provide further > >>> clarification to an > >>> existing VirtaulBox bug report if needed. > >> > >> Thanks a lot for the analysis! I've talked to one of the virtualbox > >> developers about that but they are not aware of such problems with Linux > >> or Windows guests yet. So they are currently unsure if it's a VirtualBox > >> or FreeBSD fault and if it's their fault why it works fine with other > >> guests. I'm also unsure because I haven't heard of that problem before > >> and now multiple people complain. That looks more like a FreeBSD related > >> problem on current or stable. > >> > >> I think it would be good if someone could try to reproduce that with > >> emulators/virtualbox-ose-legacy which is 3.2.12 to get some vbox dev > >> look into the problem again. > > > > FreeBSD just started honoring this setting in the BIOS this week and ignored > > it previously. Can you get an acpidump from within VirtaulBox? I might be > > able to point to a bug in it directly if so. > > > > Thanks for the info! I've attached the acpidump and also posted a copy here: > > http://people.freebsd.org/~swills/vbox-4.0.8.asl.gz > > in case the mailing list eats it. Hmm, so there does look to be a reasonable _CRS method. Oh, I think I see what I don't like: DWordMemory (ResourceProducer, PosDecode, MinNotFixed, MaxFixed, Cacheable, ReadWrite, 0x00000000, // Granularity 0x00000000, // Range Minimum 0xFFDFFFFF, // Range Maximum 0x00000000, // Translation Offset 0x00000000, // Length ,, _Y01, AddressRangeMemory, TypeStatic) It should be using MinFixed, not MinNotFixed. Try this patch: Index: acpi_pcib_acpi.c =================================================================== --- acpi_pcib_acpi.c (revision 224217) +++ acpi_pcib_acpi.c (working copy) @@ -207,10 +207,12 @@ acpi_pcib_producer_handler(ACPI_RESOURCE *res, voi length = res->Data.ExtAddress64.AddressLength; break; } - if (length == 0 || - res->Data.Address.MinAddressFixed != ACPI_ADDRESS_FIXED || - res->Data.Address.MaxAddressFixed != ACPI_ADDRESS_FIXED) + if (length == 0) break; + if (min + length - 1 != max && + (res->Data.Address.MinAddressFixed != ACPI_ADDRESS_FIXED || + res->Data.Address.MaxAddressFixed != ACPI_ADDRESS_FIXED)) + break; flags = 0; switch (res->Data.Address.ResourceType) { case ACPI_MEMORY_RANGE: -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Thu Jul 21 15:53:42 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8C432106567D; Thu, 21 Jul 2011 15:53:42 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 658B48FC1B; Thu, 21 Jul 2011 15:53:42 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 1C1B046B24; Thu, 21 Jul 2011 11:53:42 -0400 (EDT) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 97F758A02E; Thu, 21 Jul 2011 11:53:41 -0400 (EDT) From: John Baldwin To: freebsd-current@freebsd.org Date: Thu, 21 Jul 2011 11:53:27 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110617; KDE/4.5.5; amd64; ; ) References: <4E27399F.7020605@FreeBSD.org> In-Reply-To: <4E27399F.7020605@FreeBSD.org> MIME-Version: 1.0 Message-Id: <201107211153.28148.jhb@freebsd.org> Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Thu, 21 Jul 2011 11:53:41 -0400 (EDT) Cc: Andreas Tobler Subject: Re: pcib1: failed to allocate initial memory window X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jul 2011 15:53:42 -0000 On Wednesday, July 20, 2011 4:25:03 pm Andreas Tobler wrote: > Hi all, > > Built a fresh kernel today (-CURRENT) on my DELL workstation (amd64). > The network card does not get detected. Booted the old kernel again. > > Are there any chances to get this fixed or is this a candidate for a > buggy BIOS? > Attached the devinfo -r from the running kernel. Also the acpidump -dt. > > Any help would be appreciated. Ah, this case is similar to the issue with VirtualBox. Try this patch: Index: acpi_pcib_acpi.c =================================================================== --- acpi_pcib_acpi.c (revision 224217) +++ acpi_pcib_acpi.c (working copy) @@ -207,10 +207,12 @@ acpi_pcib_producer_handler(ACPI_RESOURCE *res, voi length = res->Data.ExtAddress64.AddressLength; break; } - if (length == 0 || - res->Data.Address.MinAddressFixed != ACPI_ADDRESS_FIXED || - res->Data.Address.MaxAddressFixed != ACPI_ADDRESS_FIXED) + if (length == 0) break; + if (min + length - 1 != max && + (res->Data.Address.MinAddressFixed != ACPI_ADDRESS_FIXED || + res->Data.Address.MaxAddressFixed != ACPI_ADDRESS_FIXED)) + break; flags = 0; switch (res->Data.Address.ResourceType) { case ACPI_MEMORY_RANGE: -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Thu Jul 21 17:28:39 2011 Return-Path: Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E752A106566B; Thu, 21 Jul 2011 17:28:39 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id A2CC38FC08; Thu, 21 Jul 2011 17:28:39 +0000 (UTC) Received: from [10.30.101.53] ([209.117.142.2]) (authenticated bits=0) by harmony.bsdimp.com (8.14.4/8.14.3) with ESMTP id p6LHMS3S029739 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES128-SHA bits=128 verify=NO); Thu, 21 Jul 2011 11:22:31 -0600 (MDT) (envelope-from imp@bsdimp.com) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: <4E2831CD.6040800@FreeBSD.org> Date: Thu, 21 Jul 2011 11:22:08 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <96FD57E5-947D-41F6-B529-E06855A395EC@bsdimp.com> References: <20110721070825.GA80840@freebsd.org> <4E27EEF6.6060401@FreeBSD.org> <20110721134508.GA39498@freebsd.org> <4E2831CD.6040800@FreeBSD.org> To: Dimitry Andric X-Mailer: Apple Mail (2.1084) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (harmony.bsdimp.com [10.0.0.6]); Thu, 21 Jul 2011 11:22:31 -0600 (MDT) Cc: Alexander Best , freebsd-current@FreeBSD.ORG Subject: Re: buildworld failing in lib/libc/db/btree X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jul 2011 17:28:40 -0000 On Jul 21, 2011, at 8:03 AM, Dimitry Andric wrote: > On 2011-07-21 15:45, Alexander Best wrote: > ... >>> If you are including any path, e.g. CC=3D/usr/bin/clang, buildworld = will >>> not work. Remove the path and try again. >>=20 >> THANKS! >>=20 >> ...exactly that was the problem. :) after changing CC/CXX so it = doesn't contain >> a full path, buildworld succeeded! >=20 > The problem here was that buildworld builds a bootstrap compiler under > /usr/obj, but if you specify ${CC} with an absolute path, it fails to > use it! (The bootstrap compiler has its search paths adjusted, so it > only looks under /usr/obj for include files, libraries and so on.) >=20 > This is actually a problem that needs solving, but it won't happen for > 9.0, unfortunately... Yes. And we can't solve it by banning all CC settings with / in them, = since it is perfectly legitimate to build the whole tree with a = different compiler that lives outside the tree... Warner From owner-freebsd-current@FreeBSD.ORG Thu Jul 21 17:46:20 2011 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 69C45106564A for ; Thu, 21 Jul 2011 17:46:20 +0000 (UTC) (envelope-from andreast@FreeBSD.org) Received: from smtp.fgznet.ch (mail.fgznet.ch [81.92.96.47]) by mx1.freebsd.org (Postfix) with ESMTP id E8D588FC0A for ; Thu, 21 Jul 2011 17:46:19 +0000 (UTC) Received: from deuterium.andreas.nets (dhclient-91-190-8-131.flashcable.ch [91.190.8.131]) by smtp.fgznet.ch (8.13.8/8.13.8/Submit_SMTPAUTH) with ESMTP id p6LHkGGM070310; Thu, 21 Jul 2011 19:46:17 +0200 (CEST) (envelope-from andreast@FreeBSD.org) Message-ID: <4E2865E8.2070202@FreeBSD.org> Date: Thu, 21 Jul 2011 19:46:16 +0200 From: Andreas Tobler User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.15) Gecko/20110303 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 To: John Baldwin References: <4E27399F.7020605@FreeBSD.org> <201107211153.28148.jhb@freebsd.org> In-Reply-To: <201107211153.28148.jhb@freebsd.org> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.64 on 81.92.96.47 Cc: freebsd-current@FreeBSD.org Subject: Re: pcib1: failed to allocate initial memory window X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jul 2011 17:46:20 -0000 On 21.07.11 17:53, John Baldwin wrote: > On Wednesday, July 20, 2011 4:25:03 pm Andreas Tobler wrote: >> Hi all, >> >> Built a fresh kernel today (-CURRENT) on my DELL workstation (amd64). >> The network card does not get detected. Booted the old kernel again. >> >> Are there any chances to get this fixed or is this a candidate for a >> buggy BIOS? >> Attached the devinfo -r from the running kernel. Also the acpidump -dt. >> >> Any help would be appreciated. > > Ah, this case is similar to the issue with VirtualBox. Try this patch: John, thank you very much! http://people.freebsd.org/~andreast/dmesg_optiplex.txt Gruss, Andreas From owner-freebsd-current@FreeBSD.ORG Thu Jul 21 19:10:29 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 51C581065670 for ; Thu, 21 Jul 2011 19:10:29 +0000 (UTC) (envelope-from swhetzel@gmail.com) Received: from mail-ey0-f176.google.com (mail-ey0-f176.google.com [209.85.215.176]) by mx1.freebsd.org (Postfix) with ESMTP id 4CDD78FC0A for ; Thu, 21 Jul 2011 19:10:27 +0000 (UTC) Received: by eya28 with SMTP id 28so2146245eya.21 for ; Thu, 21 Jul 2011 12:10:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=HWxjt/dl1sAQ4r/+1upSeW1AnPW3VChVqOhwWS9dyM4=; b=fRyxZafJE2uJgCgbHKoG/kC3DIuTtnbku1JNue9ErLgQ29zoPfEPuRP9gZzPAxZXVw D2nGCQux8Ghfmj4mR5NdelTX2QRQ2vuQ2pWCs0f0woCMq8hRW1sPPsrqnJaf1D/mtLoK 2u+OOPxhTlCIOEo4PoFmZ9oxq4wCCZR1vBDOc= MIME-Version: 1.0 Received: by 10.213.14.17 with SMTP id e17mr494750eba.94.1311275426644; Thu, 21 Jul 2011 12:10:26 -0700 (PDT) Received: by 10.213.11.17 with HTTP; Thu, 21 Jul 2011 12:10:26 -0700 (PDT) In-Reply-To: <201107211153.23979.jhb@freebsd.org> References: <4E263EFE.3040200@FreeBSD.org> <201107200904.45647.jhb@freebsd.org> <4E275529.7050802@FreeBSD.org> <201107211153.23979.jhb@freebsd.org> Date: Thu, 21 Jul 2011 14:10:26 -0500 Message-ID: From: Scot Hetzel To: John Baldwin Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Steve Wills , freebsd-current@freebsd.org, Bernhard Froehlich Subject: Re: em problem in virtualbox since the weekend X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jul 2011 19:10:29 -0000 On Thu, Jul 21, 2011 at 10:53 AM, John Baldwin wrote: > Hmm, so there does look to be a reasonable _CRS method. =A0Oh, I think I = see > what I don't like: > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0DWordMemory (ResourceProducer, PosDecode, = MinNotFixed, MaxFixed, Cacheable, ReadWrite, > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A00x00000000, =A0 =A0 =A0 =A0 // Gra= nularity > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A00x00000000, =A0 =A0 =A0 =A0 // Ran= ge Minimum > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A00xFFDFFFFF, =A0 =A0 =A0 =A0 // Ran= ge Maximum > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A00x00000000, =A0 =A0 =A0 =A0 // Tra= nslation Offset > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A00x00000000, =A0 =A0 =A0 =A0 // Len= gth > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0,, _Y01, AddressRangeMemory, TypeS= tatic) > This patch fixed the problem with my recent install of FreeBSD 9.0 on VirtualBox. Thanks for the fix. Scot > It should be using MinFixed, not MinNotFixed. =A0Try this patch: > > Index: acpi_pcib_acpi.c > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- acpi_pcib_acpi.c =A0 =A0(revision 224217) > +++ acpi_pcib_acpi.c =A0 =A0(working copy) > @@ -207,10 +207,12 @@ acpi_pcib_producer_handler(ACPI_RESOURCE *res, voi > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0length =3D res->Data.ExtAd= dress64.AddressLength; > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0break; > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0} > - =A0 =A0 =A0 =A0 =A0 =A0 =A0 if (length =3D=3D 0 || > - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 res->Data.Address.MinAddressFixed != =3D ACPI_ADDRESS_FIXED || > - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 res->Data.Address.MaxAddressFixed != =3D ACPI_ADDRESS_FIXED) > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 if (length =3D=3D 0) > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0break; > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 if (min + length - 1 !=3D max && > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 (res->Data.Address.MinAddressFixed = !=3D ACPI_ADDRESS_FIXED || > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 res->Data.Address.MaxAddressFixed != =3D ACPI_ADDRESS_FIXED)) > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 break; > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0flags =3D 0; > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0switch (res->Data.Address.ResourceType) { > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0case ACPI_MEMORY_RANGE: > > -- > John Baldwin > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org= " > From owner-freebsd-current@FreeBSD.ORG Thu Jul 21 22:37:16 2011 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from [127.0.0.1] (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by hub.freebsd.org (Postfix) with ESMTP id B736D106566B; Thu, 21 Jul 2011 22:37:15 +0000 (UTC) (envelope-from jkim@FreeBSD.org) From: Jung-uk Kim To: freebsd-current@FreeBSD.org Date: Thu, 21 Jul 2011 18:37:05 -0400 User-Agent: KMail/1.6.2 References: <4E263EFE.3040200@FreeBSD.org> <4E275529.7050802@FreeBSD.org> <201107211153.23979.jhb@freebsd.org> In-Reply-To: <201107211153.23979.jhb@freebsd.org> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Message-Id: <201107211837.07442.jkim@FreeBSD.org> Cc: Steve Wills , Bernhard Froehlich Subject: Re: em problem in virtualbox since the weekend X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jul 2011 22:37:16 -0000 On Thursday 21 July 2011 11:53 am, John Baldwin wrote: > On Wednesday, July 20, 2011 6:22:33 pm Steve Wills wrote: > > On 07/20/11 09:04, John Baldwin wrote: > > > On Wednesday, July 20, 2011 8:33:07 am Bernhard Froehlich wrote: > > >> On Wed, 20 Jul 2011 07:41:26 -0400, John Baldwin wrote: > > >>> On Tuesday, July 19, 2011 10:35:42 pm Steve Wills wrote: > > >>>> Hi, > > >>>> > > >>>> While testing some other things, I found -CURRENT from > > >>>> yesterday doesn't work with the em0 in my VirtualBox 4.0.8 > > >>>> (a little out of date admittedly). It worked Friday or > > >>>> Saturday I think. Anyone else seen this or should I open a > > >>>> PR? Has the code changed or am I perhaps misremembering > > >>>> dates? The error reported is: > > >>>> > > >>>> em0: Unable to allocate bus resource: memory > > >>>> em0: Allocation of PCI resources failed > > >>> > > >>> This is due to a bug in VirtualBox's BIOS implementation. > > >>> Someone should file > > >>> a bug report with VirtualBox to ask them to fix their BIOS. > > >>> The problem is that they claim that the Host-PCI bridge in > > >>> their system only decodes addresses 0xa0000-0xbffff (i.e. the > > >>> VGA window) via the "Producer" resources in the _CRS method > > >>> of the Host-PCI bridge device. This tells the OS that all > > >>> the existing PCI devices are using invalid memory address > > >>> ranges but that there is also no available address space to > > >>> allocate for PCI devices such as em0. > > >>> > > >>> You can workaround this by setting > > >>> "debug.acpi.disabled=hostres" until VirtualBox fixes their > > >>> code. I'm happy to provide further clarification to an > > >>> existing VirtaulBox bug report if needed. > > >> > > >> Thanks a lot for the analysis! I've talked to one of the > > >> virtualbox developers about that but they are not aware of > > >> such problems with Linux or Windows guests yet. So they are > > >> currently unsure if it's a VirtualBox or FreeBSD fault and if > > >> it's their fault why it works fine with other guests. I'm also > > >> unsure because I haven't heard of that problem before and now > > >> multiple people complain. That looks more like a FreeBSD > > >> related problem on current or stable. > > >> > > >> I think it would be good if someone could try to reproduce > > >> that with emulators/virtualbox-ose-legacy which is 3.2.12 to > > >> get some vbox dev look into the problem again. > > > > > > FreeBSD just started honoring this setting in the BIOS this > > > week and ignored it previously. Can you get an acpidump from > > > within VirtaulBox? I might be able to point to a bug in it > > > directly if so. > > > > Thanks for the info! I've attached the acpidump and also posted a > > copy here: > > > > http://people.freebsd.org/~swills/vbox-4.0.8.asl.gz > > > > in case the mailing list eats it. > > Hmm, so there does look to be a reasonable _CRS method. Oh, I > think I see what I don't like: > > DWordMemory (ResourceProducer, PosDecode, > MinNotFixed, MaxFixed, Cacheable, ReadWrite, 0x00000000, // > Granularity > 0x00000000, // Range Minimum > 0xFFDFFFFF, // Range Maximum > 0x00000000, // Translation Offset > 0x00000000, // Length > ,, _Y01, AddressRangeMemory, TypeStatic) > It should be using MinFixed, not MinNotFixed. Actually, I am responsible for this: http://www.freebsd.org/cgi/cvsweb.cgi/ports/emulators/virtualbox-ose/files/Attic/patch-src-VBox-Devices-PC-vbox.dsl?rev=1.1;content-type=text%2Fplain I believe this patch was submitted upstream later. > Author: jhb > Date: Thu Jul 21 20:43:43 2011 > New Revision: 224254 > URL: http://svn.freebsd.org/changeset/base/224254 > > Log: >   Allow non-fixed endpoints for a producer address range if the >   length of the resource covers the entire range.  Some BIOSes >   appear to mark endpoints as non-fixed incorrectly (non-fixed >   endpoints are supposed to be used in _PRS when OSPM is allowed to >   allocate a certain chunk of address space within a larger range, I >   don't believe it is supposed to be used for _CRS). No, _CRS can use MinNotFixed (and MaxNotFixed). You can find similar examples from ACPI spec. Jung-uk Kim From owner-freebsd-current@FreeBSD.ORG Fri Jul 22 12:05:29 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 31853106566B; Fri, 22 Jul 2011 12:05:29 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 0720A8FC08; Fri, 22 Jul 2011 12:05:29 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id B316846B03; Fri, 22 Jul 2011 08:05:28 -0400 (EDT) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 4CD378A02C; Fri, 22 Jul 2011 08:05:28 -0400 (EDT) From: John Baldwin To: "Jung-uk Kim" Date: Fri, 22 Jul 2011 08:05:26 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110617; KDE/4.5.5; amd64; ; ) References: <4E263EFE.3040200@FreeBSD.org> <201107211153.23979.jhb@freebsd.org> <201107211837.07442.jkim@FreeBSD.org> In-Reply-To: <201107211837.07442.jkim@FreeBSD.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201107220805.27479.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Fri, 22 Jul 2011 08:05:28 -0400 (EDT) Cc: Steve Wills , freebsd-current@freebsd.org, Bernhard Froehlich Subject: Re: em problem in virtualbox since the weekend X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jul 2011 12:05:29 -0000 On Thursday, July 21, 2011 6:37:05 pm Jung-uk Kim wrote: > On Thursday 21 July 2011 11:53 am, John Baldwin wrote: > > On Wednesday, July 20, 2011 6:22:33 pm Steve Wills wrote: > > > On 07/20/11 09:04, John Baldwin wrote: > > > > On Wednesday, July 20, 2011 8:33:07 am Bernhard Froehlich wrote: > > > >> On Wed, 20 Jul 2011 07:41:26 -0400, John Baldwin wrote: > > > >>> On Tuesday, July 19, 2011 10:35:42 pm Steve Wills wrote: > > > >>>> Hi, > > > >>>> > > > >>>> While testing some other things, I found -CURRENT from > > > >>>> yesterday doesn't work with the em0 in my VirtualBox 4.0.8 > > > >>>> (a little out of date admittedly). It worked Friday or > > > >>>> Saturday I think. Anyone else seen this or should I open a > > > >>>> PR? Has the code changed or am I perhaps misremembering > > > >>>> dates? The error reported is: > > > >>>> > > > >>>> em0: Unable to allocate bus resource: memory > > > >>>> em0: Allocation of PCI resources failed > > > >>> > > > >>> This is due to a bug in VirtualBox's BIOS implementation. > > > >>> Someone should file > > > >>> a bug report with VirtualBox to ask them to fix their BIOS. > > > >>> The problem is that they claim that the Host-PCI bridge in > > > >>> their system only decodes addresses 0xa0000-0xbffff (i.e. the > > > >>> VGA window) via the "Producer" resources in the _CRS method > > > >>> of the Host-PCI bridge device. This tells the OS that all > > > >>> the existing PCI devices are using invalid memory address > > > >>> ranges but that there is also no available address space to > > > >>> allocate for PCI devices such as em0. > > > >>> > > > >>> You can workaround this by setting > > > >>> "debug.acpi.disabled=hostres" until VirtualBox fixes their > > > >>> code. I'm happy to provide further clarification to an > > > >>> existing VirtaulBox bug report if needed. > > > >> > > > >> Thanks a lot for the analysis! I've talked to one of the > > > >> virtualbox developers about that but they are not aware of > > > >> such problems with Linux or Windows guests yet. So they are > > > >> currently unsure if it's a VirtualBox or FreeBSD fault and if > > > >> it's their fault why it works fine with other guests. I'm also > > > >> unsure because I haven't heard of that problem before and now > > > >> multiple people complain. That looks more like a FreeBSD > > > >> related problem on current or stable. > > > >> > > > >> I think it would be good if someone could try to reproduce > > > >> that with emulators/virtualbox-ose-legacy which is 3.2.12 to > > > >> get some vbox dev look into the problem again. > > > > > > > > FreeBSD just started honoring this setting in the BIOS this > > > > week and ignored it previously. Can you get an acpidump from > > > > within VirtaulBox? I might be able to point to a bug in it > > > > directly if so. > > > > > > Thanks for the info! I've attached the acpidump and also posted a > > > copy here: > > > > > > http://people.freebsd.org/~swills/vbox-4.0.8.asl.gz > > > > > > in case the mailing list eats it. > > > > Hmm, so there does look to be a reasonable _CRS method. Oh, I > > think I see what I don't like: > > > > DWordMemory (ResourceProducer, PosDecode, > > MinNotFixed, MaxFixed, Cacheable, ReadWrite, 0x00000000, // > > Granularity > > 0x00000000, // Range Minimum > > 0xFFDFFFFF, // Range Maximum > > 0x00000000, // Translation Offset > > 0x00000000, // Length > > ,, _Y01, AddressRangeMemory, TypeStatic) > > It should be using MinFixed, not MinNotFixed. > > Actually, I am responsible for this: > > http://www.freebsd.org/cgi/cvsweb.cgi/ports/emulators/virtualbox- ose/files/Attic/patch-src-VBox-Devices-PC-vbox.dsl?rev=1.1;content- type=text%2Fplain > > I believe this patch was submitted upstream later. > > > Author: jhb > > Date: Thu Jul 21 20:43:43 2011 > > New Revision: 224254 > > URL: http://svn.freebsd.org/changeset/base/224254 > > > > Log: > > Allow non-fixed endpoints for a producer address range if the > > length of the resource covers the entire range. Some BIOSes > > appear to mark endpoints as non-fixed incorrectly (non-fixed > > endpoints are supposed to be used in _PRS when OSPM is allowed to > > allocate a certain chunk of address space within a larger range, I > > don't believe it is supposed to be used for _CRS). > > No, _CRS can use MinNotFixed (and MaxNotFixed). You can find similar > examples from ACPI spec. Err, this is clearly illegal. Consult Table 6-38 from ACPI Spec 3.0b (page 213, actual page 233 in the PDF). If the _LEN of an Address Space Descriptor is > 0, then _MIF (Min Fixed) must equal _MAF (Max Fixed). Having one fixed and not the other is explicitly marked "illegal". Furthermore, the case where _MIF == _MAF == 0 has this description: Fixed size, variable location resource descriptor for _PRS. _LEN must be a multiple of (_GRA + 1). OS can pick the resource range that satisfies following conditions: * Start address is a multiple of (_GRA + 1) and greater or equal to _MIN. * End address is (start_address + _LEN - 1) and less or equal to _MAX. That explicitly states that this is _only_ for _PRS. Thus, the only valid combination for _CRS for _MIF and _MAF with a length != 0 is to have both endpoints fixed. Further, note that for the case were _LEN is zero, all valid cases are described by a block starting thus: Variable size, variable location resource descriptor for _PRS. Given this, the _only_ valid combination for _CRS is Length != 0, and _MIF == _MAF == 1. All other resources in _CRS are illegal. BTW, this same table is reproduced verbatim in 4.0a (now table 6-40 on page 260). -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Fri Jul 22 16:19:36 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from [127.0.0.1] (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by hub.freebsd.org (Postfix) with ESMTP id AC464106566C; Fri, 22 Jul 2011 16:19:35 +0000 (UTC) (envelope-from jkim@FreeBSD.org) From: Jung-uk Kim To: John Baldwin Date: Fri, 22 Jul 2011 12:19:24 -0400 User-Agent: KMail/1.6.2 References: <4E263EFE.3040200@FreeBSD.org> <201107211837.07442.jkim@FreeBSD.org> <201107220805.27479.jhb@freebsd.org> In-Reply-To: <201107220805.27479.jhb@freebsd.org> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201107221219.27322.jkim@FreeBSD.org> Cc: Steve Wills , freebsd-current@freebsd.org, Bernhard Froehlich Subject: Re: em problem in virtualbox since the weekend X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jul 2011 16:19:36 -0000 On Friday 22 July 2011 08:05 am, John Baldwin wrote: > On Thursday, July 21, 2011 6:37:05 pm Jung-uk Kim wrote: > > On Thursday 21 July 2011 11:53 am, John Baldwin wrote: > > > On Wednesday, July 20, 2011 6:22:33 pm Steve Wills wrote: > > > > On 07/20/11 09:04, John Baldwin wrote: > > > > > On Wednesday, July 20, 2011 8:33:07 am Bernhard Froehlich wrote: > > > > >> On Wed, 20 Jul 2011 07:41:26 -0400, John Baldwin wrote: > > > > >>> On Tuesday, July 19, 2011 10:35:42 pm Steve Wills wrote: > > > > >>>> Hi, > > > > >>>> > > > > >>>> While testing some other things, I found -CURRENT from > > > > >>>> yesterday doesn't work with the em0 in my VirtualBox > > > > >>>> 4.0.8 (a little out of date admittedly). It worked > > > > >>>> Friday or Saturday I think. Anyone else seen this or > > > > >>>> should I open a PR? Has the code changed or am I perhaps > > > > >>>> misremembering dates? The error reported is: > > > > >>>> > > > > >>>> em0: Unable to allocate bus resource: memory > > > > >>>> em0: Allocation of PCI resources failed > > > > >>> > > > > >>> This is due to a bug in VirtualBox's BIOS implementation. > > > > >>> Someone should file > > > > >>> a bug report with VirtualBox to ask them to fix their > > > > >>> BIOS. The problem is that they claim that the Host-PCI > > > > >>> bridge in their system only decodes addresses > > > > >>> 0xa0000-0xbffff (i.e. the VGA window) via the "Producer" > > > > >>> resources in the _CRS method of the Host-PCI bridge > > > > >>> device. This tells the OS that all the existing PCI > > > > >>> devices are using invalid memory address ranges but that > > > > >>> there is also no available address space to allocate for > > > > >>> PCI devices such as em0. > > > > >>> > > > > >>> You can workaround this by setting > > > > >>> "debug.acpi.disabled=hostres" until VirtualBox fixes > > > > >>> their code. I'm happy to provide further clarification > > > > >>> to an existing VirtaulBox bug report if needed. > > > > >> > > > > >> Thanks a lot for the analysis! I've talked to one of the > > > > >> virtualbox developers about that but they are not aware of > > > > >> such problems with Linux or Windows guests yet. So they > > > > >> are currently unsure if it's a VirtualBox or FreeBSD fault > > > > >> and if it's their fault why it works fine with other > > > > >> guests. I'm also unsure because I haven't heard of that > > > > >> problem before and now multiple people complain. That > > > > >> looks more like a FreeBSD related problem on current or > > > > >> stable. > > > > >> > > > > >> I think it would be good if someone could try to reproduce > > > > >> that with emulators/virtualbox-ose-legacy which is 3.2.12 > > > > >> to get some vbox dev look into the problem again. > > > > > > > > > > FreeBSD just started honoring this setting in the BIOS this > > > > > week and ignored it previously. Can you get an acpidump > > > > > from within VirtaulBox? I might be able to point to a bug > > > > > in it directly if so. > > > > > > > > Thanks for the info! I've attached the acpidump and also > > > > posted a copy here: > > > > > > > > http://people.freebsd.org/~swills/vbox-4.0.8.asl.gz > > > > > > > > in case the mailing list eats it. > > > > > > Hmm, so there does look to be a reasonable _CRS method. Oh, I > > > think I see what I don't like: > > > > > > DWordMemory (ResourceProducer, PosDecode, > > > MinNotFixed, MaxFixed, Cacheable, ReadWrite, 0x00000000, > > > // Granularity > > > 0x00000000, // Range Minimum > > > 0xFFDFFFFF, // Range Maximum > > > 0x00000000, // Translation Offset > > > 0x00000000, // Length > > > ,, _Y01, AddressRangeMemory, TypeStatic) > > > It should be using MinFixed, not MinNotFixed. > > > > Actually, I am responsible for this: > > > > http://www.freebsd.org/cgi/cvsweb.cgi/ports/emulators/virtualbox- > > ose/files/Attic/patch-src-VBox-Devices-PC-vbox.dsl?rev=1.1;content- > type=text%2Fplain > > > I believe this patch was submitted upstream later. > > > > > Author: jhb > > > Date: Thu Jul 21 20:43:43 2011 > > > New Revision: 224254 > > > URL: http://svn.freebsd.org/changeset/base/224254 > > > > > > Log: > > > Allow non-fixed endpoints for a producer address range if the > > > length of the resource covers the entire range. Some BIOSes > > > appear to mark endpoints as non-fixed incorrectly (non-fixed > > > endpoints are supposed to be used in _PRS when OSPM is > > > allowed to allocate a certain chunk of address space within a > > > larger range, I don't believe it is supposed to be used for > > > _CRS). > > > > No, _CRS can use MinNotFixed (and MaxNotFixed). You can find > > similar examples from ACPI spec. > > Err, this is clearly illegal. Consult Table 6-38 from ACPI Spec > 3.0b (page 213, actual page 233 in the PDF). If the _LEN of an > Address Space Descriptor is > 0, then _MIF (Min Fixed) must equal > _MAF (Max Fixed). Having one fixed and not the other is explicitly > marked "illegal". > > Furthermore, the case where _MIF == _MAF == 0 has this description: > > Fixed size, variable location resource descriptor for _PRS. > _LEN must be a multiple of (_GRA + 1). > OS can pick the resource range that satisfies following > conditions: > > * Start address is a multiple of (_GRA + 1) and greater or > equal to _MIN. * End address is (start_address + _LEN - 1) and less > or equal to _MAX. > > That explicitly states that this is _only_ for _PRS. Thus, the > only valid combination for _CRS for _MIF and _MAF with a length != > 0 is to have both endpoints fixed. > > Further, note that for the case were _LEN is zero, all valid cases > are described by a block starting thus: > > Variable size, variable location resource descriptor for _PRS. > > Given this, the _only_ valid combination for _CRS is Length != 0, > and _MIF == _MAF == 1. All other resources in _CRS are illegal. I was sure that my patch is okay because I found an example in the 4.0a page 356 had a _CRS example where _MIF == _MAF == _LEN == 0. So, I thought it wasn't strictly for _PRS. I'll ask Intel guys for clarification. > BTW, this same table is reproduced verbatim in 4.0a (now table 6-40 > on page 260). Hmm... Maybe I mis-interpreted the table somehow. Note the original code was _MIF == _MAF == 1, and _LEN > 0 but _LEN != (_MAX - _MIN) + 1: -------------- DwordMemory( // Consumed-and-produced resource // (all of low memory space) ResourceProducer, // bit 0 of general flags is 0 PosDecode, // positive Decode MinFixed, // Range is not fixed MaxFixed, // Range is fixed Cacheable, ReadWrite, 0x00000000, // Granularity 0x00000000, // Min (calculated dynamically) 0xffdfffff, // Max = 4GB - 2MB 0x00000000, // Translation 0xdfdfffff, // Range Length (calculated // dynamically) , // Optional field left blank , // Optional field left blank MEM3 // Name declaration for this // descriptor ) -------------- Intel ACPI Component Architecture ASL Optimizing Compiler version 20110527-64 Copyright (c) 2000 - 2011 Intel Corporation vbox.dsl 1103: 0xdfdfffff, // Range Length (calculated Error 4118 - ^ Length is not equal to fixed Min/Max window ASL Input: vbox.dsl - 1425 lines, 52542 bytes, 338 keywords Compilation complete. 1 Errors, 0 Warnings, 0 Remarks, 416 Optimizations -------------- Both _MIN and _LEN are dynamically calculated, so I guess the simplest fix should have been: --- vbox.dsl.orig 2011-07-22 12:01:33.000000000 -0400 +++ vbox.dsl 2011-07-22 12:03:41.000000000 -0400 @@ -1100,7 +1100,7 @@ 0xffdfffff, // Max = 4GB - 2MB 0x00000000, // Translation - 0xdfdfffff, // Range Length (calculated + 0xffe00000, // Range Length (calculated // dynamically) , // Optional field left blank , // Optional field left blank This should have satisfied the table without breaking too much. :-( Jung-uk Kim From owner-freebsd-current@FreeBSD.ORG Fri Jul 22 16:38:40 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 284931065673 for ; Fri, 22 Jul 2011 16:38:40 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by mx1.freebsd.org (Postfix) with ESMTP id A39278FC19 for ; Fri, 22 Jul 2011 16:38:39 +0000 (UTC) Received: by fxe6 with SMTP id 6so4157127fxe.17 for ; Fri, 22 Jul 2011 09:38:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; bh=CLZSkWkaPtvjaq14hbJwULka2jqUtASm6lWLpmdTH44=; b=u32ecyjdsE9WRIb6fixlj/bcrXPzpYaCeJgjmokRKvgplng3nTxmcZB7DOqHrs9mCN i8FYcCT2avGYWrALXjZd8STOl14lxR2KLHb3RsDML340vYj9smSMgNI0f3FY4XtFBb+A v+3spV8aD8TJh8cU68swi6uXJEmEH6n6HWF7E= Received: by 10.223.159.2 with SMTP id h2mr2391597fax.5.1311352717145; Fri, 22 Jul 2011 09:38:37 -0700 (PDT) Received: from mavbook2.mavhome.dp.ua (pc.mavhome.dp.ua [212.86.226.226]) by mx.google.com with ESMTPS id w15sm2144056faj.23.2011.07.22.09.38.34 (version=SSLv3 cipher=OTHER); Fri, 22 Jul 2011 09:38:35 -0700 (PDT) Sender: Alexander Motin Message-ID: <4E29A786.60607@FreeBSD.org> Date: Fri, 22 Jul 2011 19:38:30 +0300 From: Alexander Motin User-Agent: Thunderbird 2.0.0.23 (X11/20091212) MIME-Version: 1.0 To: Andrew Boyer References: <1DB50624F8348F48840F2E2CF6040A9D019060D246@orsmsx508.amr.corp.intel.com> <1FCD1BDB-626E-41C7-BDC6-0FCAA56E7C76@averesystems.com> In-Reply-To: <1FCD1BDB-626E-41C7-BDC6-0FCAA56E7C76@averesystems.com> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "freebsd-current@freebsd.org" , "Vogel, Jack" Subject: Re: [patch] Intel SATA controller hiccups, locking X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jul 2011 16:38:40 -0000 Andrew Boyer wrote: > Thank you for looking into it! I would really like to get Alexander's feedback before it gets committed. Improved version committed at r224270. > On Jul 20, 2011, at 4:18 PM, Vogel, Jack wrote: > >> Ran it by the chipset contact internally and he said go for it, you need me to check it in Andrew? >> >> -----Original Message----- >> From: Andrew Boyer [mailto:aboyer@averesystems.com] >> Sent: Wednesday, July 20, 2011 7:45 AM >> To: mav@freebsd.org >> Cc: freebsd-current@freebsd.org; Vogel, Jack >> Subject: [patch] Intel SATA controller hiccups, locking >> >> Hello Alexander, >> I am using the latest ata driver from stable/8 on a system with an Intel ICH10 controller. ATA_CAM and ATA_STATIC_ID are both off. There is one drive connected to port 3. SATA is set to Enhanced / IDE mode (not AHCI) in the BIOS. >>> atapci0@pci0:0:31:2: class=0x01018f card=0x060d15d9 chip=0x3a208086 rev=0x00 hdr=0x00 >>> atapci1@pci0:0:31:5: class=0x010185 card=0x060d15d9 chip=0x3a268086 rev=0x00 hdr=0x00 >>> atapci0: port 0xbff0-0xbff7,0xbf7c-0xbf7f,0xbfe0-0xbfe7,0xbef4-0xbef7,0xbfa0-0xbfaf,0xbf60-0xbf6f irq 19 at device 31.2 on pci0 >>> atapci0: Reserved 0x10 bytes for rid 0x20 type 4 at 0xbfa0 >>> atapci0: [MPSAFE] >>> atapci0: [ITHREAD] >>> atapci0: Reserved 0x10 bytes for rid 0x24 type 4 at 0xbf60 >>> ata2: on atapci0 >>> atapci0: Reserved 0x8 bytes for rid 0x10 type 4 at 0xbff0 >>> atapci0: Reserved 0x4 bytes for rid 0x14 type 4 at 0xbf7c >>> ata2: SATA reset: ports status=0x00 >>> ata2: p0: SATA connect timeout status=00000000 >>> ata2: p1: SATA connect timeout status=00000000 >>> ata2: [MPSAFE] >>> ata2: [ITHREAD] >>> ata3: on atapci0 >>> atapci0: Reserved 0x8 bytes for rid 0x18 type 4 at 0xbfe0 >>> atapci0: Reserved 0x4 bytes for rid 0x1c type 4 at 0xbef4 >>> ata3: SATA reset: ports status=0x08 >>> ata3: p0: SATA connect timeout status=00000000 >>> ata3: p1: SATA connect time=0ms status=00000123 >>> ata3: reset tp1 mask=03 ostat0=7f ostat1=50 >>> ata3: stat0=0x7f err=0x00 lsb=0xff msb=0xff >>> ata3: stat1=0x50 err=0x01 lsb=0x00 msb=0x00 >>> ata3: reset tp2 stat0=7f stat1=50 devices=0x2 >>> ata3: [MPSAFE] >>> ata3: [ITHREAD] >> >> When under heavy load, the 'atacontrol mode ad0' command sometimes fails to determine the SATA speed; the drive appears to be missing. I think the root cause is that chipsets/ata-intel.c does not do any locking on the ata_intel_sata_sidpr_* routines. The (write address register) + (access data register) model isn't safe without locking because two channels share the registers. The ata_intel_sata_cscr_* routines have the same problem. >> >> Adding a mutex to a structure stored in ctlr->chipset_data makes the hiccups go away; see the attached patch. Please advise if this is something you would like to fix. -- Alexander Motin From owner-freebsd-current@FreeBSD.ORG Fri Jul 22 17:41:15 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6A52B106564A; Fri, 22 Jul 2011 17:41:15 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 3EB9C8FC15; Fri, 22 Jul 2011 17:41:15 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id CD4F346B23; Fri, 22 Jul 2011 13:41:14 -0400 (EDT) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 6618B8A02C; Fri, 22 Jul 2011 13:41:14 -0400 (EDT) From: John Baldwin To: "Jung-uk Kim" Date: Fri, 22 Jul 2011 13:41:13 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110617; KDE/4.5.5; amd64; ; ) References: <4E263EFE.3040200@FreeBSD.org> <201107220805.27479.jhb@freebsd.org> <201107221219.27322.jkim@FreeBSD.org> In-Reply-To: <201107221219.27322.jkim@FreeBSD.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201107221341.13767.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Fri, 22 Jul 2011 13:41:14 -0400 (EDT) Cc: Steve Wills , freebsd-current@freebsd.org, Bernhard Froehlich Subject: Re: em problem in virtualbox since the weekend X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jul 2011 17:41:15 -0000 On Friday, July 22, 2011 12:19:24 pm Jung-uk Kim wrote: > On Friday 22 July 2011 08:05 am, John Baldwin wrote: > > Err, this is clearly illegal. Consult Table 6-38 from ACPI Spec > > 3.0b (page 213, actual page 233 in the PDF). If the _LEN of an > > Address Space Descriptor is > 0, then _MIF (Min Fixed) must equal > > _MAF (Max Fixed). Having one fixed and not the other is explicitly > > marked "illegal". > > > > Furthermore, the case where _MIF == _MAF == 0 has this description: > > > > Fixed size, variable location resource descriptor for _PRS. > > _LEN must be a multiple of (_GRA + 1). > > OS can pick the resource range that satisfies following > > conditions: > > > > * Start address is a multiple of (_GRA + 1) and greater or > > equal to _MIN. * End address is (start_address + _LEN - 1) and less > > or equal to _MAX. > > > > That explicitly states that this is _only_ for _PRS. Thus, the > > only valid combination for _CRS for _MIF and _MAF with a length != > > 0 is to have both endpoints fixed. > > > > Further, note that for the case were _LEN is zero, all valid cases > > are described by a block starting thus: > > > > Variable size, variable location resource descriptor for _PRS. > > > > Given this, the _only_ valid combination for _CRS is Length != 0, > > and _MIF == _MAF == 1. All other resources in _CRS are illegal. > > I was sure that my patch is okay because I found an example in the > 4.0a page 356 had a _CRS example where _MIF == _MAF == _LEN == 0. > So, I thought it wasn't strictly for _PRS. I'll ask Intel guys for > clarification. Hmm, that does seem to contradict the earlier section. I wonder if that example is just broken? It is supposed to be an example talking about assigning PCI bus numbers. Note that both of those examples do use a length of 0, so perhaps they are expecting the OS to ignore them? > > BTW, this same table is reproduced verbatim in 4.0a (now table 6-40 > > on page 260). > > Hmm... Maybe I mis-interpreted the table somehow. Note the > original code was _MIF == _MAF == 1, and _LEN > 0 but _LEN != > (_MAX - _MIN) + 1: > > -------------- > DwordMemory( // Consumed-and-produced resource > // (all of low memory space) > ResourceProducer, // bit 0 of general flags is 0 > PosDecode, // positive Decode > MinFixed, // Range is not fixed > MaxFixed, // Range is fixed > Cacheable, > ReadWrite, > 0x00000000, // Granularity > 0x00000000, // Min (calculated dynamically) > 0xffdfffff, // Max = 4GB - 2MB > 0x00000000, // Translation > 0xdfdfffff, // Range Length (calculated > // dynamically) > , // Optional field left blank > , // Optional field left blank > MEM3 // Name declaration for this > // descriptor > ) > -------------- > Intel ACPI Component Architecture > ASL Optimizing Compiler version 20110527-64 > Copyright (c) 2000 - 2011 Intel Corporation > > vbox.dsl 1103: 0xdfdfffff, // Range Length (calculated > Error 4118 - ^ Length is not equal to fixed Min/Max window > > ASL Input: vbox.dsl - 1425 lines, 52542 bytes, 338 keywords > Compilation complete. 1 Errors, 0 Warnings, 0 Remarks, 416 Optimizations > -------------- > > Both _MIN and _LEN are dynamically calculated, so I guess the simplest > fix should have been: > > --- vbox.dsl.orig 2011-07-22 12:01:33.000000000 -0400 > +++ vbox.dsl 2011-07-22 12:03:41.000000000 -0400 > @@ -1100,7 +1100,7 @@ > > 0xffdfffff, // Max = 4GB - 2MB > 0x00000000, // Translation > - 0xdfdfffff, // Range Length (calculated > + 0xffe00000, // Range Length (calculated > // dynamically) > , // Optional field left blank > , // Optional field left blank > > This should have satisfied the table without breaking too much. :-( Well, perhaps the best fix would be to set the length to 0 instead. Maybe the compiler is possibly broken here. The Fixed vs NotFixed matters in terms of what is actually presented to the OS once the _CRS method has run, not how _CRS may choose to populate the buffers. _CRS may dynamically calculate what the _MAX and _LEN fields are (this is very common), but the finished buffer that the OS sees is for a fixed resource range, so it should use Fixed for both endpoints. So for example, this is what I see on a test system here for the main PCI memory window region: DWordMemory (ResourceProducer, PosDecode, MinFixed, MaxFixed, Cacheable, ReadWrite, 0x00000000, // Granularity 0x00000000, // Range Minimum 0x00000000, // Range Maximum 0x00000000, // Translation Offset 0x00000000, // Length 0x00,, _Y00, AddressRangeMemory, TypeStatic) ... Method (_CRS, 0, Serialized) { CreateDWordField (RSRC, \_SB.PCI0._Y00._MIN, BTMN) CreateDWordField (RSRC, \_SB.PCI0._Y00._MAX, BTMX) CreateDWordField (RSRC, \_SB.PCI0._Y00._LEN, BTLN) And (TOLM, 0xF000, Local0) ShiftLeft (Local0, 0x10, Local0) Store (Local0, BTMN) Subtract (0xFEC00000, Local0, BTLN) Subtract (Add (BTMN, BTLN), 0x01, BTMX) ... Here the resource when the OS sees it will have _LEN != 0 and _MINF == _MAXF == 1 even though _MIN and _MAX are computed dynamically in _CRS. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Fri Jul 22 18:30:44 2011 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from [127.0.0.1] (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by hub.freebsd.org (Postfix) with ESMTP id B06C41065670; Fri, 22 Jul 2011 18:30:42 +0000 (UTC) (envelope-from jkim@FreeBSD.org) From: Jung-uk Kim To: freebsd-current@FreeBSD.org Date: Fri, 22 Jul 2011 14:30:26 -0400 User-Agent: KMail/1.6.2 References: <4E263EFE.3040200@FreeBSD.org> <201107221219.27322.jkim@FreeBSD.org> <201107221341.13767.jhb@freebsd.org> In-Reply-To: <201107221341.13767.jhb@freebsd.org> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201107221430.29792.jkim@FreeBSD.org> Cc: Steve Wills , Bernhard Froehlich Subject: Re: em problem in virtualbox since the weekend X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jul 2011 18:30:44 -0000 On Friday 22 July 2011 01:41 pm, John Baldwin wrote: > On Friday, July 22, 2011 12:19:24 pm Jung-uk Kim wrote: > > On Friday 22 July 2011 08:05 am, John Baldwin wrote: > > > Err, this is clearly illegal. Consult Table 6-38 from ACPI > > > Spec 3.0b (page 213, actual page 233 in the PDF). If the _LEN > > > of an Address Space Descriptor is > 0, then _MIF (Min Fixed) > > > must equal _MAF (Max Fixed). Having one fixed and not the > > > other is explicitly marked "illegal". > > > > > > Furthermore, the case where _MIF == _MAF == 0 has this > > > description: > > > > > > Fixed size, variable location resource descriptor for _PRS. > > > _LEN must be a multiple of (_GRA + 1). > > > OS can pick the resource range that satisfies following > > > conditions: > > > > > > * Start address is a multiple of (_GRA + 1) and greater or > > > equal to _MIN. * End address is (start_address + _LEN - 1) and > > > less or equal to _MAX. > > > > > > That explicitly states that this is _only_ for _PRS. Thus, the > > > only valid combination for _CRS for _MIF and _MAF with a length > > > != 0 is to have both endpoints fixed. > > > > > > Further, note that for the case were _LEN is zero, all valid > > > cases are described by a block starting thus: > > > > > > Variable size, variable location resource descriptor for > > > _PRS. > > > > > > Given this, the _only_ valid combination for _CRS is Length != > > > 0, and _MIF == _MAF == 1. All other resources in _CRS are > > > illegal. > > > > I was sure that my patch is okay because I found an example in > > the 4.0a page 356 had a _CRS example where _MIF == _MAF == _LEN > > == 0. So, I thought it wasn't strictly for _PRS. I'll ask Intel > > guys for clarification. > > Hmm, that does seem to contradict the earlier section. I wonder if > that example is just broken? It is supposed to be an example > talking about assigning PCI bus numbers. Note that both of those > examples do use a length of 0, so perhaps they are expecting the OS > to ignore them? Now I think the example is broken. However, a lot of BIOS writers just copy and paste examples from the spec. without looking closely. In fact, I've seen many such cases. :-( > > > BTW, this same table is reproduced verbatim in 4.0a (now table > > > 6-40 on page 260). > > > > Hmm... Maybe I mis-interpreted the table somehow. Note the > > original code was _MIF == _MAF == 1, and _LEN > 0 but _LEN != > > (_MAX - _MIN) + 1: > > > > -------------- > > DwordMemory( // Consumed-and-produced resource > > // (all of low memory space) > > ResourceProducer, // bit 0 of general flags is 0 > > PosDecode, // positive Decode > > MinFixed, // Range is not fixed > > MaxFixed, // Range is fixed > > Cacheable, > > ReadWrite, > > 0x00000000, // Granularity > > 0x00000000, // Min (calculated dynamically) > > 0xffdfffff, // Max = 4GB - 2MB > > 0x00000000, // Translation > > 0xdfdfffff, // Range Length (calculated > > // dynamically) > > , // Optional field left blank > > , // Optional field left blank > > MEM3 // Name declaration for this > > // descriptor > > ) > > -------------- > > Intel ACPI Component Architecture > > ASL Optimizing Compiler version 20110527-64 > > Copyright (c) 2000 - 2011 Intel Corporation > > > > vbox.dsl 1103: 0xdfdfffff, // > > Range Length (calculated Error 4118 - > > ^ Length is not equal to fixed Min/Max window > > > > ASL Input: vbox.dsl - 1425 lines, 52542 bytes, 338 keywords > > Compilation complete. 1 Errors, 0 Warnings, 0 Remarks, 416 > > Optimizations -------------- > > > > Both _MIN and _LEN are dynamically calculated, so I guess the > > simplest fix should have been: > > > > --- vbox.dsl.orig 2011-07-22 12:01:33.000000000 -0400 > > +++ vbox.dsl 2011-07-22 12:03:41.000000000 -0400 > > @@ -1100,7 +1100,7 @@ > > > > 0xffdfffff, // Max = 4GB - 2MB > > 0x00000000, // Translation > > - 0xdfdfffff, // Range Length > > (calculated + 0xffe00000, // > > Range Length (calculated // dynamically) , > > // Optional field left blank , // Optional > > field left blank > > > > This should have satisfied the table without breaking too much. > > :-( > > Well, perhaps the best fix would be to set the length to 0 instead. > Maybe the compiler is possibly broken here. The Fixed vs NotFixed > matters in terms of what is actually presented to the OS once the > _CRS method has run, not how _CRS may choose to populate the > buffers. _CRS may dynamically calculate what the _MAX and _LEN > fields are (this is very common), but the finished buffer that the > OS sees is for a fixed resource range, so it should use Fixed for > both endpoints. > > So for example, this is what I see on a test system here for the > main PCI memory window region: > > DWordMemory (ResourceProducer, PosDecode, MinFixed, > MaxFixed, Cacheable, ReadWrite, 0x00000000, // Granularity > 0x00000000, // Range Minimum > 0x00000000, // Range Maximum > 0x00000000, // Translation Offset > 0x00000000, // Length > 0x00,, _Y00, AddressRangeMemory, TypeStatic) > ... > Method (_CRS, 0, Serialized) > { > CreateDWordField (RSRC, \_SB.PCI0._Y00._MIN, BTMN) > CreateDWordField (RSRC, \_SB.PCI0._Y00._MAX, BTMX) > CreateDWordField (RSRC, \_SB.PCI0._Y00._LEN, BTLN) > And (TOLM, 0xF000, Local0) > ShiftLeft (Local0, 0x10, Local0) > Store (Local0, BTMN) > Subtract (0xFEC00000, Local0, BTLN) > Subtract (Add (BTMN, BTLN), 0x01, BTMX) > ... > > Here the resource when the OS sees it will have _LEN != 0 and _MINF > == _MAXF == 1 even though _MIN and _MAX are computed dynamically in > _CRS. Now I believe ACPI-CA has to revert the sanity check, at least for _CRS. Jung-uk Kim From owner-freebsd-current@FreeBSD.ORG Fri Jul 22 23:12:05 2011 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CE47F106566B; Fri, 22 Jul 2011 23:12:05 +0000 (UTC) (envelope-from swills@FreeBSD.org) Received: from mouf.net (mouf.net [204.109.58.86]) by mx1.freebsd.org (Postfix) with ESMTP id 8573C8FC18; Fri, 22 Jul 2011 23:12:05 +0000 (UTC) Received: from meatwad.mouf.net (cpe-065-190-149-241.nc.res.rr.com [65.190.149.241]) (authenticated bits=0) by mouf.net (8.14.4/8.14.4) with ESMTP id p6MNC1ik097196 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Fri, 22 Jul 2011 19:12:02 -0400 (EDT) (envelope-from swills@FreeBSD.org) Message-ID: <4E2A03C1.1030501@FreeBSD.org> Date: Fri, 22 Jul 2011 19:12:01 -0400 From: Steve Wills User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.17) Gecko/20110531 Thunderbird/3.1.10 MIME-Version: 1.0 To: Scot Hetzel References: <4E263EFE.3040200@FreeBSD.org> <201107200904.45647.jhb@freebsd.org> <4E275529.7050802@FreeBSD.org> <201107211153.23979.jhb@freebsd.org> In-Reply-To: X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (mouf.net [204.109.58.86]); Fri, 22 Jul 2011 19:12:02 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.96.2 at mouf.net X-Virus-Status: Clean Cc: freebsd-current@FreeBSD.org, Bernhard Froehlich , John Baldwin Subject: Re: em problem in virtualbox since the weekend X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jul 2011 23:12:05 -0000 On 07/21/11 15:10, Scot Hetzel wrote: > On Thu, Jul 21, 2011 at 10:53 AM, John Baldwin wrote: >> Hmm, so there does look to be a reasonable _CRS method. Oh, I think I see >> what I don't like: >> >> DWordMemory (ResourceProducer, PosDecode, MinNotFixed, MaxFixed, Cacheable, ReadWrite, >> 0x00000000, // Granularity >> 0x00000000, // Range Minimum >> 0xFFDFFFFF, // Range Maximum >> 0x00000000, // Translation Offset >> 0x00000000, // Length >> ,, _Y01, AddressRangeMemory, TypeStatic) >> > > This patch fixed the problem with my recent install of FreeBSD 9.0 on > VirtualBox. > > Thanks for the fix. > Same here, thanks! Steve