From kmacy at freebsd.org  Tue Sep  1 01:35:48 2009
From: kmacy at freebsd.org (Kip Macy)
Date: Tue Sep  1 01:35:56 2009
Subject: Forwarding benchmark
In-Reply-To: <D0E9834C-59EB-48B2-A804-6947DA75C7D6@netasq.com>
References: <D0E9834C-59EB-48B2-A804-6947DA75C7D6@netasq.com>
Message-ID: <3c1674c90908311835i7f70e6d8mbfa8ce619e7ff911@mail.gmail.com>

We're not going to see much more 700kpps on forwarding workloads until
we do something about the rtentry locking. I had some interesting
ideas I was exploring, but I don't have the luxury of side projects
right now.

em(9)'s transmit performance has been substantially improved in 8 by
using a buf_ring instead of IFQ so I assume that you're entirely gated
by rx performance. Jeff did some work in that area to reduce the
per-packet overhead of dequeue and to do some NAPI-like opportunistic
polling using a variant of the taskqueue API.

It won't give you any idea about latency breakdown, but it would be
useful for a general time breakdown to look at unhalted core cycles in
PMC.

Good Luck,
Kip



On Fri, Aug 21, 2009 at 02:25, Fabien Thomas<fabien.thomas@netasq.com> wrote:
> ? ? ? ?Hi all,
>
> Just a quick benchmark on 8.0 Beta2+ (18/08) show no regression vs 7.2.
>
> Result in FPS for 64bytes frame using Breakingpoint Elite
>
> Breakingpoint P1 === DUT === Breakingpoint P2
>
> Stream1 : P1 -> P2
> Stream2: P2 -> P1
>
> GENERIC kernel + netisr.direct
>
> 4.11 : 236 (with 1 stream down for unknown reason)
> 6.3 ? : 248
> 7.2 ? : 350
> 8.0b : 352
>
> POLLING kernel + netisr.direct
>
> 4.11 : 526
> 6.3 ? : 246
> 7.2 ? : 230
> 8.0b : 330
>
> Note that the perf grow a little bit from version to version but 4.11 with
> polling is always a lot better.
>
> There is a lot a more in depth testing to do (HW flow tag, 10gb, lot of
> interface, latency ...) but it give a rough idea of the perf in the
> forwarding area.
>
> Regards,
> Fabien
>
> dmesg:
>
> CPU: Intel(R) Pentium(R) D CPU 2.80GHz (2793.02-MHz 686-class CPU)
> ?Origin = "GenuineIntel" ?Id = 0xf47 ?Stepping = 7
> ?Features=0xbfebfbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE>
> ?Features2=0x641d<SSE3,DTES64,MON,DS_CPL,CNXT-ID,CX16,xTPR>
> ?AMD Features=0x20100000<NX,LM>
> ?AMD Features2=0x1<LAHF>
> ?TSC: P-state invariant
> real memory ?= 1073741824 (1024 MB)
> avail memory = 1035210752 (987 MB)
> ACPI APIC Table: <PTLTD ? ? ? ? ?APIC ?>
> FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs
> FreeBSD/SMP: 1 package(s) x 2 core(s)
> ?cpu0 (BSP): APIC ID: ?0
> ?cpu1 (AP): APIC ID: ?1
> ...
> em8: <Intel(R) PRO/1000 Network Connection 6.9.14> port 0x7000-0x701f mem
> 0xed700000-0xed71ffff irq 18 at device 0.0 on pci6
> em8: Using MSI interrupt
> em8: [FILTER]
> em8: Ethernet address: 00:30:48:5c:40:82
> pcib7: <ACPI PCI-PCI bridge> irq 19 at device 28.3 on pci0
> pci8: <ACPI PCI bus> on pcib7
> em9: <Intel(R) PRO/1000 Network Connection 6.9.14> port 0x8000-0x801f mem
> 0xed800000-0xed81ffff irq 19 at device 0.0 on pci8
> em9: Using MSI interrupt
> em9: [FILTER]
> em9: Ethernet address: 00:30:48:5c:40:83
>
> _______________________________________________
> 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"
>



-- 
When harsh accusations depart too far from the truth, they leave
bitter consequences.
--Tacitus
From qing.li at bluecoat.com  Tue Sep  1 01:44:33 2009
From: qing.li at bluecoat.com (Li, Qing)
Date: Tue Sep  1 01:44:45 2009
Subject: IPv6 regression on 8.x
In-Reply-To: <20090830.024420.174808572.hrs@allbsd.org>
References: <B583FBF374231F4A89607B4D08578A43052776D0@bcs-mail03.internal.cacheflow.com>
	<20090830.024420.174808572.hrs@allbsd.org>
Message-ID: <B583FBF374231F4A89607B4D08578A43052EEDE6@bcs-mail03.internal.cacheflow.com>

Hi Hiroki,

>
>  2) Issue of subnet-router anycast address with a global address
> 
>  Thanks for the fixes!  With the two patches 1) and 3) are gone, but
>  2) still remains.  Is there something I can help to narrow down it?
> 

Hmm... I tried multiple test cases and all seem to work as expected.
I also tried the exact configuration sequence as you outlined in your
original bug report email, and that case worked, too.

The only difference I can see from the given information, is I have 
3 em interfaces, whereas you have 2 em interfaces and 1 re, but I 
don't see how that would make a difference.

Would it be possible for you to email me your system configuration 
produced from "ifconfig" and "netstat" privately ?

Thank you.

-- Qing




From ari at ish.com.au  Tue Sep  1 01:52:55 2009
From: ari at ish.com.au (Aristedes Maniatis)
Date: Tue Sep  1 01:53:02 2009
Subject: [beta3] ld-elf Undefined symbol
Message-ID: <4A9C7E73.4040004@ish.com.au>

Upgraded an amd64 FreeBSD machine from beta 2 to beta 3 via freebsd-update. When trying to use the bacula port (a backup tool), the application will die with the following error:

/libexec/ld-elf.so.1: /usr/local/sbin/bacula-dir: Undefined symbol "_ZN5BSOCK18set_source_addressEP5dlist"

Naturally we have rebuilt all ports and rebuilt (just to be sure) all ports that bacula depends on. Is this a bug in beta3 or something we are doing wrong?


Cheers
Ari Maniatis


-------------------------->
ish
http://www.ish.com.au
Level 1, 30 Wilson Street Newtown 2042 Australia
phone +61 2 9550 5001   fax +61 2 9550 4001
GPG fingerprint CBFB 84B4 738D 4E87 5E5C  5EFA EF6A 7D2E 3E49 102A
From lists at jnielsen.net  Tue Sep  1 04:13:00 2009
From: lists at jnielsen.net (John Nielsen)
Date: Tue Sep  1 04:13:06 2009
Subject: WEP on wi(4) [was: Re: LOR wlan0 wi0]
In-Reply-To: <4A7E5E2B.6060204@errno.com>
References: <20090807165850.3e8541f8@vaio> <20090808134101.44d7d210@vaio>
	<4A7E5E2B.6060204@errno.com>
Message-ID: <200908312358.51491.lists@jnielsen.net>

On Sunday 09 August 2009 01:27:07 am Sam Leffler wrote:
> > Sam Leffler <sam@errno.com> wrote:
> I can confirm WEP is broken on wi in sta mode (and probably ap mode). 
> I found at least two bugs but couldn't get it to work so am going to
> leave it as an errata for 8.0.  But what's truly odd is that WPA works
> fine despite a bug that should've caused it to not work.  I knew WPA
> worked which is probably why I ignored WEP (noone in their right mind 
> uses WEP when WPA is available :-)).

So for us wrong-minded people with wi(4) hardware that lacks WPA support 
is it better to stick with 7.x for now? Any patches available or a rough 
ETA? Is there a specific set of 8-CURRENT commits before which WEP is 
known (or strongly suspected) to work? Anything others can do to help 
besides ask annoying questions? (Sadly I'm not quite enough of a kernel 
hacker to adopt maintainership of wi.)

Thanks!

JN
From tinderbox at freebsd.org  Tue Sep  1 04:20:31 2009
From: tinderbox at freebsd.org (FreeBSD Tinderbox)
Date: Tue Sep  1 04:20:39 2009
Subject: [head tinderbox] failure on i386/i386
Message-ID: <200909010420.n814KU3p033582@freebsd-current.sentex.ca>

TB --- 2009-09-01 02:20:00 - tinderbox 2.6 running on freebsd-current.sentex.ca
TB --- 2009-09-01 02:20:00 - starting HEAD tinderbox run for i386/i386
TB --- 2009-09-01 02:20:00 - cleaning the object tree
TB --- 2009-09-01 02:20:43 - cvsupping the source tree
TB --- 2009-09-01 02:20:43 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/i386/i386/supfile
TB --- 2009-09-01 02:22:00 - building world
TB --- 2009-09-01 02:22:00 - MAKEOBJDIRPREFIX=/obj
TB --- 2009-09-01 02:22:00 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2009-09-01 02:22:00 - TARGET=i386
TB --- 2009-09-01 02:22:00 - TARGET_ARCH=i386
TB --- 2009-09-01 02:22:00 - TZ=UTC
TB --- 2009-09-01 02:22:00 - __MAKE_CONF=/dev/null
TB --- 2009-09-01 02:22:00 - cd /src
TB --- 2009-09-01 02:22:00 - /usr/bin/make -B buildworld
>>> World build started on Tue Sep  1 02:22:01 UTC 2009
>>> 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 Sep  1 03:27:03 UTC 2009
TB --- 2009-09-01 03:27:03 - generating LINT kernel config
TB --- 2009-09-01 03:27:03 - cd /src/sys/i386/conf
TB --- 2009-09-01 03:27:03 - /usr/bin/make -B LINT
TB --- 2009-09-01 03:27:03 - building LINT kernel
TB --- 2009-09-01 03:27:03 - MAKEOBJDIRPREFIX=/obj
TB --- 2009-09-01 03:27:03 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2009-09-01 03:27:03 - TARGET=i386
TB --- 2009-09-01 03:27:03 - TARGET_ARCH=i386
TB --- 2009-09-01 03:27:03 - TZ=UTC
TB --- 2009-09-01 03:27:03 - __MAKE_CONF=/dev/null
TB --- 2009-09-01 03:27:03 - cd /src
TB --- 2009-09-01 03:27:03 - /usr/bin/make -B buildkernel KERNCONF=LINT
>>> Kernel build for LINT started on Tue Sep  1 03:27:03 UTC 2009
>>> 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 Tue Sep  1 03:52:37 UTC 2009
TB --- 2009-09-01 03:52:37 - building GENERIC kernel
TB --- 2009-09-01 03:52:37 - MAKEOBJDIRPREFIX=/obj
TB --- 2009-09-01 03:52:37 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2009-09-01 03:52:37 - TARGET=i386
TB --- 2009-09-01 03:52:37 - TARGET_ARCH=i386
TB --- 2009-09-01 03:52:37 - TZ=UTC
TB --- 2009-09-01 03:52:37 - __MAKE_CONF=/dev/null
TB --- 2009-09-01 03:52:37 - cd /src
TB --- 2009-09-01 03:52:37 - /usr/bin/make -B buildkernel KERNCONF=GENERIC
>>> Kernel build for GENERIC started on Tue Sep  1 03:52:37 UTC 2009
>>> 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 Tue Sep  1 04:12:57 UTC 2009
TB --- 2009-09-01 04:12:57 - building PAE kernel
TB --- 2009-09-01 04:12:57 - MAKEOBJDIRPREFIX=/obj
TB --- 2009-09-01 04:12:57 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2009-09-01 04:12:57 - TARGET=i386
TB --- 2009-09-01 04:12:57 - TARGET_ARCH=i386
TB --- 2009-09-01 04:12:57 - TZ=UTC
TB --- 2009-09-01 04:12:57 - __MAKE_CONF=/dev/null
TB --- 2009-09-01 04:12:57 - cd /src
TB --- 2009-09-01 04:12:57 - /usr/bin/make -B buildkernel KERNCONF=PAE
>>> Kernel build for PAE started on Tue Sep  1 04:12:57 UTC 2009
>>> 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 Tue Sep  1 04:18:03 UTC 2009
TB --- 2009-09-01 04:18:03 - building XEN kernel
TB --- 2009-09-01 04:18:03 - MAKEOBJDIRPREFIX=/obj
TB --- 2009-09-01 04:18:03 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2009-09-01 04:18:03 - TARGET=i386
TB --- 2009-09-01 04:18:03 - TARGET_ARCH=i386
TB --- 2009-09-01 04:18:03 - TZ=UTC
TB --- 2009-09-01 04:18:03 - __MAKE_CONF=/dev/null
TB --- 2009-09-01 04:18:03 - cd /src
TB --- 2009-09-01 04:18:03 - /usr/bin/make -B buildkernel KERNCONF=XEN
>>> Kernel build for XEN started on Tue Sep  1 04:18:03 UTC 2009
>>> 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
[...]
cc1: warnings being treated as errors
/src/sys/i386/xen/pmap.c: In function 'pmap_pinit':
/src/sys/i386/xen/pmap.c:1546: warning: implicit declaration of function 'pagezero'
/src/sys/i386/xen/pmap.c:1546: warning: nested extern declaration of 'pagezero'
/src/sys/i386/xen/pmap.c: At top level:
/src/sys/i386/xen/pmap.c:3332: warning: conflicting types for 'pagezero'
/src/sys/i386/xen/pmap.c:3332: error: static declaration of 'pagezero' follows non-static declaration
/src/sys/i386/xen/pmap.c:1546: error: previous implicit declaration of 'pagezero' was here
*** Error code 1

Stop in /obj/i386/src/sys/XEN.
*** Error code 1

Stop in /src.
*** Error code 1

Stop in /src.
TB --- 2009-09-01 04:20:30 - WARNING: /usr/bin/make returned exit code  1 
TB --- 2009-09-01 04:20:30 - ERROR: failed to build XEN kernel
TB --- 2009-09-01 04:20:30 - 5088.27 user 709.88 system 7230.04 real


http://tinderbox.des.no/tinderbox-head-HEAD-i386-i386.full
From pluknet at gmail.com  Tue Sep  1 06:55:01 2009
From: pluknet at gmail.com (pluknet)
Date: Tue Sep  1 06:55:07 2009
Subject: [beta3] ld-elf Undefined symbol
In-Reply-To: <4A9C7E73.4040004@ish.com.au>
References: <4A9C7E73.4040004@ish.com.au>
Message-ID: <a31046fc0908312355t2e824d2eq2391d3522e7efe1d@mail.gmail.com>

2009/9/1 Aristedes Maniatis <ari@ish.com.au>:
> Upgraded an amd64 FreeBSD machine from beta 2 to beta 3 via freebsd-update.
> When trying to use the bacula port (a backup tool), the application will die
> with the following error:
>
> /libexec/ld-elf.so.1: /usr/local/sbin/bacula-dir: Undefined symbol
> "_ZN5BSOCK18set_source_addressEP5dlist"
>
> Naturally we have rebuilt all ports and rebuilt (just to be sure) all ports
> that bacula depends on. Is this a bug in beta3 or something we are doing
> wrong?
>

Hi. Quoting Ken Smith:

"There was a shared library version bump after BETA2 was
announced (bump was done July 19th with svn commit r195767) so
if you update a system that was last rebuilt earlier than that it would
be a good idea to rebuild all user-level applications including the
ports/packages."

You definitely need to rebuild all installed packages.

-- 
wbr,
pluknet
From hselasky at c2i.net  Tue Sep  1 06:56:17 2009
From: hselasky at c2i.net (Hans Petter Selasky)
Date: Tue Sep  1 06:56:25 2009
Subject: [PATCH] USB Harddrive not recognized (umass appears, da0 not)
In-Reply-To: <1251761217.1186.9.camel@localhost>
References: <1251570251.1238.21.camel@localhost>
	<11278_1251745674_4A9C1F89_11278_90_1_20090831190735.GF60240@cicely7.cicely.de>
	<1251761217.1186.9.camel@localhost>
Message-ID: <200909010856.23045.hselasky@c2i.net>

On Tuesday 01 September 2009 01:26:57 Tobias Grosser wrote:
> On Mon, 2009-08-31 at 21:07 +0200, Bernd Walter wrote:
> > On Mon, Aug 31, 2009 at 06:59:18PM +0200, Tobias Grosser wrote:
> > > On Mon, 2009-08-31 at 11:52 +0200, Bernd Walter wrote:
> > > > On Sun, Aug 30, 2009 at 07:09:29PM +0200, Hans Petter Selasky wrote:
> > > > > Hi,
> > > > >
> > > > > I looks like your device is hanging on SCSI command
> > > > > 0x12,00,00,00,4a,00
> > > >
> > > > 0x12 is an inquiry, which is bad if the device has problems with.
> > >
> > > I tried Linux on the same computer and the drive worked without any
> > > problems.
> >
> > If those are timestamps then there is a 5 second delay.
> > I wouldn't say that this is without problems.
> > Maybe Linux just has a different handling of the case.
> >
> > > ---------------------------------------
> > > linux_dmesg.log is attached.
> > > ---------------------------------------
> > >
> > > There was also another report where the drive did not work on FreeBSD.
> > > I mailed the user and he did not get it to run on FreeBSD, but his
> > > drive also works on Linux.
> > >
> > > http://lists.freebsd.org/pipermail/freebsd-stable/2006-September/028999
> > >.html
> > >
> > > As I have two of these drives, I am pretty sure my device is not
> > > completely broken, but WD has some uncommon/broken way to interact with
> > > FreeBSD.
> > >
> > > To narrow it down I run the usb.org compliance test utility.
> > >
> > > http://www.usb.org/developers/tools/ : USB20CV R1.3.5.5
> >
> > As Hans Petter said: this is not a USB problem, it is at SCSI.
> >
> > > The results for the generic device test and for the USB mass storage
> > > test are attached.
> >
> > If this is just are startup problem you won't see anything at all after
> > probing is over.
> > My assumption would be that the device missbehaves until it spun up.
> > But this is just an assumption.
>
> Thanks to all of you who pointed me in the right direction. It seems the
> way inquiries are handled was broken.
> I solved the problem by adding a new quirk for the WD MyPassword Series.
>
> Do you think this is the right approach? May this break anything else?
> And finally if everything is alright, can someone commit this patch?
>
> Thanks
>
> Tobi

Can you try this:

+       {USB_VENDOR_WESTERN, USB_PRODUCT_WESTERN_MYPASSWORD, RID_WILDCARD,
+               UMASS_PROTO_DEFAULT,
+               FORCE_SHORT_INQUIRY
+       },

--HPS
From nick at van-laarhoven.org  Tue Sep  1 07:31:25 2009
From: nick at van-laarhoven.org (Nick Hibma)
Date: Tue Sep  1 07:31:32 2009
Subject: Reducing noise in dmesg output
Message-ID: <200909010931.16880.nick@van-laarhoven.org>

Folks,

dmesg is getting cluttered with random bits of irrelevant information which 
either should be behind bootverbose or not at all present. Below two 
locations where I intend to remove that information. The fact that a module 
is loaded can be seen in the output of

	kldstat -v | grep netsmb

the amount of stolen memory and aperture size might be interesting when 
configuring your X server. Then again, most X servers nowadays HAVE no 
configuration file anymore because of auto-configuration.

Any objections?

Nick

Index: kern/kern_shutdown.c
===================================================================
--- kern/kern_shutdown.c	(revision 196710)
+++ kern/kern_shutdown.c	(working copy)
@@ -581,6 +581,10 @@
 
 /*
  * Support for poweroff delay.
+ *
+ * Please note that setting this delay too short might power off your 
machine
+ * before the write cache on your hard disk has been flushed, leading to
+ * soft-updates inconsistencies.
  */
 #ifndef POWEROFF_DELAY
 # define POWEROFF_DELAY 5000
Index: dev/agp/agp_i810.c
===================================================================
--- dev/agp/agp_i810.c	(revision 196589)
+++ dev/agp/agp_i810.c	(working copy)
@@ -474,12 +474,15 @@
 				agp_generic_detach(dev);
 				return EINVAL;
 		}
-		if (sc->stolen > 0) {
-			device_printf(dev, "detected %dk stolen memory\n",
-			    sc->stolen * 4);
+		if (bootverbose) {
+			if (sc->stolen > 0) {
+				device_printf(dev,
+				    "detected %dk stolen memory\n",
+				    sc->stolen * 4);
+			}
+			device_printf(dev, "aperture size is %dM\n",
+			    sc->initial_aperture / 1024 / 1024);
 		}
-		device_printf(dev, "aperture size is %dM\n",
-		    sc->initial_aperture / 1024 / 1024);
 
 		/* GATT address is already in there, make sure it's enabled */
 		pgtblctl = bus_read_4(sc->sc_res[0], AGP_I810_PGTBL_CTL);
@@ -664,9 +667,11 @@
 		gtt_size += 4;
 
 		sc->stolen = (stolen - gtt_size) * 1024 / 4096;
-		if (sc->stolen > 0)
-			device_printf(dev, "detected %dk stolen memory\n", sc->stolen * 4);
-		device_printf(dev, "aperture size is %dM\n", sc->initial_aperture / 1024 
/ 1024);
+		if (bootverbose) {
+			if (sc->stolen > 0)
+				device_printf(dev, "detected %dk stolen memory\n", sc->stolen * 4);
+			device_printf(dev, "aperture size is %dM\n", sc->initial_aperture / 1024 
/ 1024);
+		}
 
 		/* GATT address is already in there, make sure it's enabled */
 		pgtblctl = bus_read_4(sc->sc_res[0], AGP_I810_PGTBL_CTL);
Index: netsmb/smb_dev.c
===================================================================
--- netsmb/smb_dev.c	(revision 196589)
+++ netsmb/smb_dev.c	(working copy)
@@ -352,7 +352,6 @@
 		}
 		clone_setup(&nsmb_clones);
 		nsmb_dev_tag = EVENTHANDLER_REGISTER(dev_clone, nsmb_dev_clone, 0, 1000);
-		printf("netsmb_dev: loaded\n");
 		break;
 	    case MOD_UNLOAD:
 		smb_iod_done();
@@ -363,7 +362,6 @@
 		drain_dev_clone_events();
 		clone_cleanup(&nsmb_clones);
 		destroy_dev_drain(&nsmb_cdevsw);
-		printf("netsmb_dev: unloaded\n");
 		break;
 	    default:
 		error = EINVAL;

From rink at FreeBSD.org  Tue Sep  1 08:08:14 2009
From: rink at FreeBSD.org (Rink Springer)
Date: Tue Sep  1 08:08:20 2009
Subject: Reducing noise in dmesg output
In-Reply-To: <200909010931.16880.nick@van-laarhoven.org>
References: <200909010931.16880.nick@van-laarhoven.org>
Message-ID: <20090901080830.GA52168@rink.nu>

Hi Nick,

On Tue, Sep 01, 2009 at 09:31:16AM +0200, Nick Hibma wrote:
> dmesg is getting cluttered with random bits of irrelevant information which 
> either should be behind bootverbose or not at all present. Below two 
> locations where I intend to remove that information. The fact that a module 
> is loaded can be seen in the output of

I'd say this is an useful change; the netsmb messages seem just
leftovers from debugging and I never saw the need for the aperture size
either (granted, I don't know what it indicates...)

Regards,

-- 
Rink P.W. Springer                                - http://rink.nu
"Beauty often seduces us on the road to truth."
- Dr. Wilson
From grosser at fim.uni-passau.de  Tue Sep  1 08:08:37 2009
From: grosser at fim.uni-passau.de (Tobias Grosser)
Date: Tue Sep  1 08:08:45 2009
Subject: [PATCH] USB Harddrive not recognized (umass appears, da0 not)
In-Reply-To: <20490_1251788178_4A9CC592_20490_149_1_200909010856.23045.hselasky@c2i.net>
References: <1251570251.1238.21.camel@localhost>
	<11278_1251745674_4A9C1F89_11278_90_1_20090831190735.GF60240@cicely7.cicely.de>
	<1251761217.1186.9.camel@localhost>
	<20490_1251788178_4A9CC592_20490_149_1_200909010856.23045.hselasky@c2i.net>
Message-ID: <1251792510.1176.2.camel@localhost>

On Tue, 2009-09-01 at 08:56 +0200, Hans Petter Selasky wrote:
> On Tuesday 01 September 2009 01:26:57 Tobias Grosser wrote:
> > On Mon, 2009-08-31 at 21:07 +0200, Bernd Walter wrote:
> > > On Mon, Aug 31, 2009 at 06:59:18PM +0200, Tobias Grosser wrote:
> > > > On Mon, 2009-08-31 at 11:52 +0200, Bernd Walter wrote:
> > > > > On Sun, Aug 30, 2009 at 07:09:29PM +0200, Hans Petter Selasky wrote:
> > > > > > Hi,
> > > > > >
> > > > > > I looks like your device is hanging on SCSI command
> > > > > > 0x12,00,00,00,4a,00
> > > > >
> > > > > 0x12 is an inquiry, which is bad if the device has problems with.
> > > >
> > > > I tried Linux on the same computer and the drive worked without any
> > > > problems.
> > >
> > > If those are timestamps then there is a 5 second delay.
> > > I wouldn't say that this is without problems.
> > > Maybe Linux just has a different handling of the case.
> > >
> > > > ---------------------------------------
> > > > linux_dmesg.log is attached.
> > > > ---------------------------------------
> > > >
> > > > There was also another report where the drive did not work on FreeBSD.
> > > > I mailed the user and he did not get it to run on FreeBSD, but his
> > > > drive also works on Linux.
> > > >
> > > > http://lists.freebsd.org/pipermail/freebsd-stable/2006-September/028999
> > > >.html
> > > >
> > > > As I have two of these drives, I am pretty sure my device is not
> > > > completely broken, but WD has some uncommon/broken way to interact with
> > > > FreeBSD.
> > > >
> > > > To narrow it down I run the usb.org compliance test utility.
> > > >
> > > > http://www.usb.org/developers/tools/ : USB20CV R1.3.5.5
> > >
> > > As Hans Petter said: this is not a USB problem, it is at SCSI.
> > >
> > > > The results for the generic device test and for the USB mass storage
> > > > test are attached.
> > >
> > > If this is just are startup problem you won't see anything at all after
> > > probing is over.
> > > My assumption would be that the device missbehaves until it spun up.
> > > But this is just an assumption.
> >
> > Thanks to all of you who pointed me in the right direction. It seems the
> > way inquiries are handled was broken.
> > I solved the problem by adding a new quirk for the WD MyPassword Series.
> >
> > Do you think this is the right approach? May this break anything else?
> > And finally if everything is alright, can someone commit this patch?
> >
> > Thanks
> >
> > Tobi
> 
> Can you try this:
> 
> +       {USB_VENDOR_WESTERN, USB_PRODUCT_WESTERN_MYPASSWORD, RID_WILDCARD,
> +               UMASS_PROTO_DEFAULT,
> +               FORCE_SHORT_INQUIRY
> +       },

OK. I forgot to remove unnecessary quirks. I just tried your patch and
it also works.

Thanks

Tobi

From ohartman at zedat.fu-berlin.de  Tue Sep  1 10:30:44 2009
From: ohartman at zedat.fu-berlin.de (O. Hartmann)
Date: Tue Sep  1 10:30:51 2009
Subject: ports/devel/automake-wrapper: ln: /usr/local/bin/aclocal: File
	exists
Message-ID: <4A9CF7CF.1000608@zedat.fu-berlin.de>

I get permanently this error when doing portmaster -dvf lighttpd.

It is essentiel having build everything along the lighttpd server due to 
a /usr/local/lib corruption. ports/devl/autotools are already installed. 
Now I get stuck in this nasty error shown below, I can not circumvent. 
How to simply force the installation?

Please respond to my email address also since I'm not member of the 
ports-list.

Thanks in advance,

Oliver

===>  Installing for automake-wrapper-20071109
===>   Generating temporary packing list
ln: /usr/local/bin/aclocal: File exists
*** Error code 1

Stop in /usr/ports/devel/automake-wrapper.

From gary.jennejohn at freenet.de  Tue Sep  1 11:58:49 2009
From: gary.jennejohn at freenet.de (Gary Jennejohn)
Date: Tue Sep  1 11:58:55 2009
Subject: ports/devel/automake-wrapper: ln: /usr/local/bin/aclocal: File
 exists
In-Reply-To: <4A9CF7CF.1000608@zedat.fu-berlin.de>
References: <4A9CF7CF.1000608@zedat.fu-berlin.de>
Message-ID: <20090901135845.0901d4b8@ernst.jennejohn.org>

On Tue, 01 Sep 2009 10:30:39 +0000
"O. Hartmann" <ohartman@zedat.fu-berlin.de> wrote:

> I get permanently this error when doing portmaster -dvf lighttpd.
> 
> It is essentiel having build everything along the lighttpd server due to 
> a /usr/local/lib corruption. ports/devl/autotools are already installed. 
> Now I get stuck in this nasty error shown below, I can not circumvent. 
> How to simply force the installation?
> 
> Please respond to my email address also since I'm not member of the 
> ports-list.
> 
> Thanks in advance,
> 
> Oliver
> 
> ===>  Installing for automake-wrapper-20071109
> ===>   Generating temporary packing list
> ln: usr/local/bin/aclocal: File exists
> *** Error code 1
> 
> Stop in /usr/ports/devel/automake-wrapper.
> 

Try moving /usr/local/bin/aclocal away?

---
Gary Jennejohn
From gausus at gausus.net  Tue Sep  1 13:56:07 2009
From: gausus at gausus.net (Maciej Jan Broniarz)
Date: Tue Sep  1 13:56:14 2009
Subject: Problems with ZFS on AMD64
Message-ID: <a7454e2f0909010624yf652445y855047b83d046cc4@mail.gmail.com>

Hello,

I have installed Freebsd8-beta3 on a Phenom II Quad Core with 8 gb ram.
When I create a zfs volume all works fine. Still, when I reboot the system
it doesn't come up. It hangs with the following error:

http://img525.imageshack.us/img525/3832/freebsd8zfs.jpg

What might be the problem?

Best regards,
mjb


-- 
[ -----< Maciej Jan Broniarz || gausus@gausus.net >------ ]
| Siamo qui \ sotto la stessa luce \ sotto la sua croce \ |
| cantando ad una voce \ E l'Emmanuel Emmanuel, Emmanuel, |
[ ---------------< E l'Emmanuel, Emmanuel >-------------- ]
From jhb at freebsd.org  Tue Sep  1 14:16:36 2009
From: jhb at freebsd.org (John Baldwin)
Date: Tue Sep  1 14:16:54 2009
Subject: panic: apic_free_vector: Thread already bound.
In-Reply-To: <3bbf2fe10908311331k3e871898tc36a9846651cc53@mail.gmail.com>
References: <20090822115958.f93fcf29.ubm.freebsd@gmail.com>
	<20090831222650.45b6c806.ubm@u-boot-man.de>
	<3bbf2fe10908311331k3e871898tc36a9846651cc53@mail.gmail.com>
Message-ID: <200909010955.33747.jhb@freebsd.org>

On Monday 31 August 2009 4:31:50 pm Attilio Rao wrote:
> 2009/8/31 Marc UBM <ubm@u-boot-man.de>:
> > On Mon, 24 Aug 2009 16:31:05 -0400
> > John Baldwin <jhb@freebsd.org> wrote:
> >
> >> On Saturday 22 August 2009 5:59:58 am Marc UBM wrote:
> >> >
> >> > Hiho! :-)
> >> >
> >> > I'm seeing above panic in the final stages of the shutdown process.
> >> > Coredump is available, bt as follows, textdump attached.
> >> >
> >> >
> >> > FreeBSD hamstor 8.0-BETA2 FreeBSD 8.0-BETA2 #14: Wed Aug 19 22:43:17
> >> > CEST 2009     oni0@hamstor:/usr/obj/usr/src/sys/HAMSTOR  amd64
> >> >
> >> >
> >> > (kgdb) bt
> >> > #0  doadump () at pcpu.h:223
> >> > #1  0xffffffff801b561c in db_fncall (dummy1=Variable "dummy1" is not
> >> > #available.
> >> > ) at /usr/src/sys/ddb/db_command.c:548
> >> > #2  0xffffffff801b5951 in db_command (last_cmdp=0xffffffff808594a0,
> >> > #cmd_table=Variable "cmd_table" is not available.
> >> > ) at /usr/src/sys/ddb/db_command.c:445
> >> > #3  0xffffffff801b5ba0 in db_command_loop ()
> >> > #at /usr/src/sys/ddb/db_command.c:498 4  0xffffffff801b7b69 in
> >> > #db_trap (type=Variable "type" is not available.
> >> > ) at /usr/src/sys/ddb/db_main.c:229
> >> > #5  0xffffffff8038d775 in kdb_trap (type=3, code=0,
> >> > #tf=0xffffff8000017760) at /usr/src/sys/kern/subr_kdb.c:535 6
> >> > #0xffffffff8060e170 in trap (frame=0xffffff8000017760)
> >> > #at /usr/src/sys/amd64/amd64/trap.c:611 7  0xffffffff805f3b23 in
> >> > #calltrap () at /usr/src/sys/amd64/amd64/exception.S:224 8
> >> > #0xffffffff8038d94d in kdb_enter (why=0xffffffff80681954 "panic",
> >> > #msg=0xa <Address 0xa out of bounds>) at cpufunc.h:63 9
> >> > #0xffffffff8035e04b in panic (fmt=Variable "fmt" is not available.
> >> > ) at /usr/src/sys/kern/kern_shutdown.c:562
> >> > #10 0xffffffff805fafbb in apic_free_vector (apic_id=Variable
> >> > #"apic_id" is not available.
> >> > ) at /usr/src/sys/amd64/amd64/local_apic.c:995
> >> > #11 0xffffffff805f7560 in intr_remove_handler (cookie=Variable
> >> > #"cookie" is not available.
> >> > ) at /usr/src/sys/amd64/amd64/intr_machdep.c:203
> >> > #12 0xffffffff806250d4 in hpt_shutdown_vbus
> >> > #(vbus_ext=0xffffff8000254000, howto=Variable "howto" is not
> >> > #available.
> >> > ) at /usr/src/sys/dev/hptrr/hptrr_osm_bsd.c:361
> >> > #13 0xffffffff8035da8b in boot (howto=16392)
> >> > #at /usr/src/sys/kern/kern_shutdown.c:419 14 0xffffffff8035e126 in
> >> > #reboot (td=Variable "td" is not available.
> >> > ) at /usr/src/sys/kern/kern_shutdown.c:173
> >> > #15 0xffffffff8060dbba in syscall (frame=0xffffff8000017c80)
> >> > #at /usr/src/sys/amd64/amd64/trap.c:982 16 0xffffffff805f3e01 in
> >> > #Xfast_syscall () at /usr/src/sys/amd64/amd64/exception.S:373 17
> >> > #0x000000000040892c in ?? ()
> >> > Previous frame inner to this frame (corrupt stack?)
> >> >
> >> > frame #12 & #13 make me suspect the hptrr driver (again :-)), but
> >> > I'm not sure.
> >>
> >> Ah, any driver shutting off its interrupt handler during shutdown
> >> would actually trigger this.  The hptrr driver doesn't really need to
> >> do this during shutdown, but I think we don't want to panic in this
> >> case. Unfortunately we don't currently have a "in_shutdown" type of
> >> global flag that we can check in apic_free_vector() to not worry
> >> about the thread already being bound.
> >
> > Is there any chance this fix might make it into 8.0? It's not a real
> > problem for me since I can just power-off by force, but I imagine it
> > might be a real pita for people who only have remote access and want
> > to reboot, etc.
> 
> Maybe we can ship 8 with a printf() instrad than a panic()?

Actually, it looks like 'rebooting' is what we want.  Try this:

--- //depot/vendor/freebsd/src/sys/amd64/amd64/local_apic.c	2009/08/14 21:10:13
+++ //depot/user/jhb/acpipci/amd64/amd64/local_apic.c	2009/09/01 13:54:23
@@ -990,18 +990,21 @@
 	 * we don't lose an interrupt delivery race.
 	 */
 	td = curthread;
-	thread_lock(td);
-	if (sched_is_bound(td))
-		panic("apic_free_vector: Thread already bound.\n");
-	sched_bind(td, apic_cpuid(apic_id));
-	thread_unlock(td);
+	if (!rebooting) {
+		thread_lock(td);
+		if (sched_is_bound(td))
+			panic("apic_free_vector: Thread already bound.\n");
+		sched_bind(td, apic_cpuid(apic_id));
+		thread_unlock(td);
+	}
 	mtx_lock_spin(&icu_lock);
 	lapics[apic_id].la_ioint_irqs[vector - APIC_IO_INTS] = -1;
 	mtx_unlock_spin(&icu_lock);
-	thread_lock(td);
-	sched_unbind(td);
-	thread_unlock(td);
-
+	if (!rebooting) {
+		thread_lock(td);
+		sched_unbind(td);
+		thread_unlock(td);
+	}
 }
 
 /* Map an IDT vector (APIC) to an IRQ (interrupt source). */
--- //depot/vendor/freebsd/src/sys/i386/i386/local_apic.c	2009/08/14 21:10:13
+++ //depot/user/jhb/acpipci/i386/i386/local_apic.c	2009/09/01 13:53:14
@@ -994,18 +994,21 @@
 	 * we don't lose an interrupt delivery race.
 	 */
 	td = curthread;
-	thread_lock(td);
-	if (sched_is_bound(td))
-		panic("apic_free_vector: Thread already bound.\n");
-	sched_bind(td, apic_cpuid(apic_id));
-	thread_unlock(td);
+	if (!rebooting) {
+		thread_lock(td);
+		if (sched_is_bound(td))
+			panic("apic_free_vector: Thread already bound.\n");
+		sched_bind(td, apic_cpuid(apic_id));
+		thread_unlock(td);
+	}
 	mtx_lock_spin(&icu_lock);
 	lapics[apic_id].la_ioint_irqs[vector - APIC_IO_INTS] = -1;
 	mtx_unlock_spin(&icu_lock);
-	thread_lock(td);
-	sched_unbind(td);
-	thread_unlock(td);
-
+	if (!rebooting) {
+		thread_lock(td);
+		sched_unbind(td);
+		thread_unlock(td);
+	}
 }
 
 /* Map an IDT vector (APIC) to an IRQ (interrupt source). */

-- 
John Baldwin
From jhb at freebsd.org  Tue Sep  1 14:16:38 2009
From: jhb at freebsd.org (John Baldwin)
Date: Tue Sep  1 14:16:55 2009
Subject: 8.0-beta3 does not detect several ata channels
In-Reply-To: <4A9BF438.1000006@smeets.im>
References: <4A9BF23F.6070801@netability.ie> <4A9BF438.1000006@smeets.im>
Message-ID: <200909011002.59592.jhb@freebsd.org>

On Monday 31 August 2009 12:03:04 pm Florian Smeets wrote:
> On 8/31/09 5:54 PM, Nick Hilliard wrote:
> > Hi,
> > 
> > I have a hp proliant ML115 with 6 sata ports which run in ATA mode (bios
> > doesn't appear to give the option to use AHCI).  On freebsd 7.x, all
> > channels are detected.  On freebsd8.0-beta3, the disks attached to the
> > first two SATA ports are not detected, although it detects the ports
> > themselves.
> > 
> > I've attached a verbose dmesg from freebsd 7.1 and 8.0-beta3.
> > 
> > Any ideas on what's going on here?  This seems like a nasty regression.
> 
> There are 3 PRs about this problem: 128686, 132372, 137942.
> 
> i386 version should recognize the disks. amd64 does when you set
> hw.pci.mcfg=0 in loader.conf.

Hmm, so an idea I had just now.. can you grab a dump of the PCI config space 
for the disk controller in the MCFG vs non-MCFG cases?  That is, find the 
device's address using pciconf -lv (e.g. pci0:0:30:0 or some such) and then 
run this command under both configurations and save the output:

pciconf -r pci0:0:30:0 0:0xfc

-- 
John Baldwin
From jhb at freebsd.org  Tue Sep  1 14:16:40 2009
From: jhb at freebsd.org (John Baldwin)
Date: Tue Sep  1 14:16:55 2009
Subject: Problems with ZFS on AMD64
In-Reply-To: <a7454e2f0909010624yf652445y855047b83d046cc4@mail.gmail.com>
References: <a7454e2f0909010624yf652445y855047b83d046cc4@mail.gmail.com>
Message-ID: <200909011005.18200.jhb@freebsd.org>

On Tuesday 01 September 2009 9:24:24 am Maciej Jan Broniarz wrote:
> Hello,
> 
> I have installed Freebsd8-beta3 on a Phenom II Quad Core with 8 gb ram.
> When I create a zfs volume all works fine. Still, when I reboot the system
> it doesn't come up. It hangs with the following error:
> 
> http://img525.imageshack.us/img525/3832/freebsd8zfs.jpg
> 
> What might be the problem?

It's probably a NULL pointer dereference, but we would need a stack trace to 
investigate this further.

-- 
John Baldwin
From nick-lists at netability.ie  Tue Sep  1 14:31:18 2009
From: nick-lists at netability.ie (Nick Hilliard)
Date: Tue Sep  1 14:31:25 2009
Subject: 8.0-beta3 does not detect several ata channels
In-Reply-To: <200909011002.59592.jhb@freebsd.org>
References: <4A9BF23F.6070801@netability.ie> <4A9BF438.1000006@smeets.im>
	<200909011002.59592.jhb@freebsd.org>
Message-ID: <4A9D3030.9040500@netability.ie>

On 01/09/2009 15:02, John Baldwin wrote:
> Hmm, so an idea I had just now.. can you grab a dump of the PCI config space
> for the disk controller in the MCFG vs non-MCFG cases?  That is, find the
> device's address using pciconf -lv (e.g. pci0:0:30:0 or some such) and then
> run this command under both configurations and save the output:
>
> pciconf -r pci0:0:30:0 0:0xfc

7.1, 8.0-beta3, or does it matter?

Nick
From jamie at bishopston.net  Tue Sep  1 15:02:26 2009
From: jamie at bishopston.net (Jamie Landeg Jones)
Date: Tue Sep  1 15:02:34 2009
Subject: reproducable kernel panic: page fault - 8.0-beta
Message-ID: <200909011502.n81F2PUF033284@catflap.bishopston.net>

On Aug 30, 2009, at 7:58 PM, Bjoern A. Zeeb wrote:

> > On Sun, 30 Aug 2009, Jamie Landeg Jones wrote:
> >
> >> problem still exists. no response to PR raised over a month ago :-(
> >
> > Now it would be really good if you had more information here, at least
> > a PR number.  There have been lots of them the last month.
> That's what I thought, but the query PR form (by originator) worked
> great. ;)
> kern/137310: http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/137310

Thanks. Obviuously I mneat to paste the URL - I'd looked it up especially
to post in the email, but I must have forgotton! Sorry about that.

Jamie

From jhb at freebsd.org  Tue Sep  1 15:25:12 2009
From: jhb at freebsd.org (John Baldwin)
Date: Tue Sep  1 15:25:19 2009
Subject: 8.0-beta3 does not detect several ata channels
In-Reply-To: <4A9D3030.9040500@netability.ie>
References: <4A9BF23F.6070801@netability.ie>
	<200909011002.59592.jhb@freebsd.org>
	<4A9D3030.9040500@netability.ie>
Message-ID: <200909011123.04873.jhb@freebsd.org>

On Tuesday 01 September 2009 10:31:12 am Nick Hilliard wrote:
> On 01/09/2009 15:02, John Baldwin wrote:
> > Hmm, so an idea I had just now.. can you grab a dump of the PCI config space
> > for the disk controller in the MCFG vs non-MCFG cases?  That is, find the
> > device's address using pciconf -lv (e.g. pci0:0:30:0 or some such) and then
> > run this command under both configurations and save the output:
> >
> > pciconf -r pci0:0:30:0 0:0xfc
> 
> 7.1, 8.0-beta3, or does it matter?

Doesn't really matter, I just want to compare a working case to a non-working
case.

-- 
John Baldwin
From sam at errno.com  Tue Sep  1 15:29:55 2009
From: sam at errno.com (Sam Leffler)
Date: Tue Sep  1 15:30:02 2009
Subject: WEP on wi(4) [was: Re: LOR wlan0 wi0]
In-Reply-To: <200908312358.51491.lists@jnielsen.net>
References: <20090807165850.3e8541f8@vaio> <20090808134101.44d7d210@vaio>
	<4A7E5E2B.6060204@errno.com>
	<200908312358.51491.lists@jnielsen.net>
Message-ID: <4A9D3DF1.7000605@errno.com>

John Nielsen wrote:
> On Sunday 09 August 2009 01:27:07 am Sam Leffler wrote:
>>> Sam Leffler <sam@errno.com> wrote:
>> I can confirm WEP is broken on wi in sta mode (and probably ap mode). 
>> I found at least two bugs but couldn't get it to work so am going to
>> leave it as an errata for 8.0.  But what's truly odd is that WPA works
>> fine despite a bug that should've caused it to not work.  I knew WPA
>> worked which is probably why I ignored WEP (noone in their right mind 
>> uses WEP when WPA is available :-)).
> 
> So for us wrong-minded people with wi(4) hardware that lacks WPA support 
> is it better to stick with 7.x for now? Any patches available or a rough 
> ETA? Is there a specific set of 8-CURRENT commits before which WEP is 
> known (or strongly suspected) to work? Anything others can do to help 
> besides ask annoying questions? (Sadly I'm not quite enough of a kernel 
> hacker to adopt maintainership of wi.)

Attached is what I came up with when the problem was identified.  As you 
can see it's incomplete.  I have no time to work on it more so someone 
else will need to follow through.

Given the cost of a replacement wireless card is <US$20 I cannot imagine 
why anyone would not just replace it.

	Sam
-------------- next part --------------
An embedded message was scrubbed...
From: Sam Leffler <sam@errno.com>
Subject: wi wep patch
Date: Mon, 10 Aug 2009 09:05:39 -0700
Size: 5568
Url: http://lists.freebsd.org/pipermail/freebsd-current/attachments/20090901/c9ba49c3/AttachedMessage.eml
From rhurlin at gwdg.de  Tue Sep  1 16:48:01 2009
From: rhurlin at gwdg.de (Rainer Hurling)
Date: Tue Sep  1 16:48:08 2009
Subject: 8.0-beta3 does not detect several ata channels
In-Reply-To: <200909011002.59592.jhb@freebsd.org>
References: <4A9BF23F.6070801@netability.ie> <4A9BF438.1000006@smeets.im>
	<200909011002.59592.jhb@freebsd.org>
Message-ID: <4A9D5036.9000403@gwdg.de>

On 01.09.2009 16:02 (UTC+2), John Baldwin wrote:
> On Monday 31 August 2009 12:03:04 pm Florian Smeets wrote:
>> On 8/31/09 5:54 PM, Nick Hilliard wrote:
>>> Hi,
>>>
>>> I have a hp proliant ML115 with 6 sata ports which run in ATA mode (bios
>>> doesn't appear to give the option to use AHCI).  On freebsd 7.x, all
>>> channels are detected.  On freebsd8.0-beta3, the disks attached to the
>>> first two SATA ports are not detected, although it detects the ports
>>> themselves.
>>>
>>> I've attached a verbose dmesg from freebsd 7.1 and 8.0-beta3.
>>>
>>> Any ideas on what's going on here?  This seems like a nasty regression.
>> There are 3 PRs about this problem: 128686, 132372, 137942.
>>
>> i386 version should recognize the disks. amd64 does when you set
>> hw.pci.mcfg=0 in loader.conf.
> 
> Hmm, so an idea I had just now.. can you grab a dump of the PCI config space 
> for the disk controller in the MCFG vs non-MCFG cases?  That is, find the 
> device's address using pciconf -lv (e.g. pci0:0:30:0 or some such) and then 
> run this command under both configurations and save the output:
> 
> pciconf -r pci0:0:30:0 0:0xfc
> 

I am not sure if your idea has something to do with my (and some other 
users) problem. So excuse me, if this posting is wrong.

For some month now I am only able to boot CURRENT under amd64 with 
setting hw.pci.mcfg=0. Under i386 all works fine. Below I listed output 
under i386 and under amd64. Perhaps you are able to get a hint?

Tell me if I can help in any way.

Thanks in advance,
Rainer Hurling


#pciconf -lv
atapci1@pci0:0:5:0:     class=0x010185 card=0x72601462 chip=0x037f10de 
rev=0xa2 hdr=0x00
vendor     = 'Nvidia Corp'
     device     = 'MCP55 SATA/RAID Controller (MCP55S)'
     class      = mass storage
     subclass   = ATA
atapci2@pci0:0:5:1:     class=0x010185 card=0x72601462 chip=0x037f10de
rev=0xa2 hdr=0x00
     vendor     = 'Nvidia Corp'
     device     = 'MCP55 SATA/RAID Controller (MCP55S)'
     class      = mass storage
     subclass   = ATA


--- i386 Config  ----------------------------------------------------
#sysctl hw.pci.mcfg
hw.pci.mcfg: 1

#pciconf -r pci0:0:5:0 0:0xfc
037f10de 00b00007 010185a2 00800000
0000c481 0000c401 0000c081 0000c001
0000bc01 f9ef9000 00000000 72601462
00000000 00000044 00000000 01030117
72601462 0002b001 00000000 00000000
0008680f 00000000 00000000 00000000
00000000 00000c41 42060f00 00000000
40c4782c 00001001 00001001 00200020
c0000000 0f498000 a0200000 7c750000
a0100000 00000000 10060006 0101037f
19000a12 00000000 00000000 02003133
0084cc05 00000000 00000000 00000000
00000000 00000000 000a000a a8020008
0c02000a 00000042 00000000 e7c00001
0c02000a 00000042 00000000 e030000f
00000000 00000000 000c0010 00000000

#pciconf -r pci0:0:5:1 0:0xfc
037f10de 00b00007 010185a2 00800000
0000b881 0000b801 0000b481 0000b401
0000b081 f9ef8000 00000000 72601462
00000000 00000044 00000000 01030214
72601462 0002b001 00000000 00000000
0008680f 00000000 00000000 00000000
00000000 00000c41 42060f00 00000000
40c4782c 00001001 00001001 00200020
c0000000 ffefffff 0f1f0000 f7ff7f3b
3fb70000 00000000 10060006 0101037f
00000a12 00000000 00000000 02003133
0084cc05 00000000 00000000 00000000
00000000 00000000 000a000a a8020008
0602000a 00000042 00000000 0050000f
0602000a 00000042 00000000 0040000f
00000000 00000000 000c0010 00000000


--- amd64 Config  ---------------------------------------------------
#sysctl hw.pci.mcfg
hw.pci.mcfg: 0

#pciconf -r pci0:0:5:0 0:0xfc
037f10de 00b00007 010185a2 00800000
0000c481 0000c401 0000c081 0000c001
0000bc01 f9ef9000 00000000 72601462
00000000 00000044 00000000 01030117
72601462 0002b001 00000000 00000000
0008680f 00000000 00000000 00000000
00000000 00000c41 42060f00 00000000
40c4782c 00001001 00001001 00200020
c0000000 03562000 80080000 41403000
b0080000 00000000 10060006 0101037f
18000a12 00000000 00000000 02003133
0084cc05 00000000 00000000 00000000
00000000 00000000 000a000a a8020008
0c02000a 00000042 00000000 e7c00001
0c02000a 00000042 00000000 e030000f
00000000 00000000 000c0010 00000000

#pciconf -r pci0:0:5:1 0:0xfc
037f10de 00b00007 010185a2 00800000
0000b881 0000b801 0000b481 0000b401
0000b081 f9ef8000 00000000 72601462
00000000 00000044 00000000 01030214
72601462 0002b001 00000000 00000000
0008680f 00000000 00000000 00000000
00000000 00000c41 42060f00 00000000
40c4782c 00001001 00001001 00200020
00000000 ffefffff 0f1f0000 f7ff7f3b
3fb70000 00000000 10060006 0101037f
00000a12 00000000 00000000 02003133
0084cc05 00000000 00000000 00000000
00000000 00000000 000a000a a8020008
0602000a 00000042 00000000 0050000f
0602000a 00000042 00000000 0040000f
00000000 00000000 000c0010 00000000
From jamie at bishopston.net  Tue Sep  1 16:52:08 2009
From: jamie at bishopston.net (Jamie Landeg Jones)
Date: Tue Sep  1 16:52:19 2009
Subject: reproducable kernel panic: page fault - 8.0-beta
In-Reply-To: <20090830182951.GL1881@deviant.kiev.zoral.com.ua>
References: <200908301750.n7UHoOwr069011@catflap.bishopston.net>
	<20090830175755.J93661@maildrop.int.zabbadoz.net>
	<C92F31B1-1DF9-42E4-BBC4-7885F871A905@exscape.org>
	<20090830182951.GL1881@deviant.kiev.zoral.com.ua>
Message-ID: <200909011650.n81GoklK022216@catflap.bishopston.net>

Kostik Belousov wrote:

> I think this would fix the issue.
>
> diff --git a/sys/fs/pseudofs/pseudofs_vnops.c b/sys/fs/pseudofs/pseudofs_vnops.c
> index e03749b..34ca500 100644
> --- a/sys/fs/pseudofs/pseudofs_vnops.c
> +++ b/sys/fs/pseudofs/pseudofs_vnops.c
> @@ -339,7 +339,6 @@ pfs_getextattr(struct vop_getextattr_args *va)
>  	if (proc != NULL)
>  		PROC_UNLOCK(proc);
>  
> -	pfs_unlock(pn);
>  	PFS_RETURN (error);
>  }
  
Thanks. I just tried that on my machines, and it does fix this.

Cheers, Jamie

From jhb at freebsd.org  Tue Sep  1 17:41:33 2009
From: jhb at freebsd.org (John Baldwin)
Date: Tue Sep  1 17:41:40 2009
Subject: 8.0-beta3 does not detect several ata channels
In-Reply-To: <4A9D5036.9000403@gwdg.de>
References: <4A9BF23F.6070801@netability.ie>
	<200909011002.59592.jhb@freebsd.org> <4A9D5036.9000403@gwdg.de>
Message-ID: <200909011341.26192.jhb@freebsd.org>

On Tuesday 01 September 2009 12:47:50 pm Rainer Hurling wrote:
> On 01.09.2009 16:02 (UTC+2), John Baldwin wrote:
> > On Monday 31 August 2009 12:03:04 pm Florian Smeets wrote:
> >> On 8/31/09 5:54 PM, Nick Hilliard wrote:
> >>> Hi,
> >>>
> >>> I have a hp proliant ML115 with 6 sata ports which run in ATA mode (bios
> >>> doesn't appear to give the option to use AHCI).  On freebsd 7.x, all
> >>> channels are detected.  On freebsd8.0-beta3, the disks attached to the
> >>> first two SATA ports are not detected, although it detects the ports
> >>> themselves.
> >>>
> >>> I've attached a verbose dmesg from freebsd 7.1 and 8.0-beta3.
> >>>
> >>> Any ideas on what's going on here?  This seems like a nasty regression.
> >> There are 3 PRs about this problem: 128686, 132372, 137942.
> >>
> >> i386 version should recognize the disks. amd64 does when you set
> >> hw.pci.mcfg=0 in loader.conf.
> > 
> > Hmm, so an idea I had just now.. can you grab a dump of the PCI config 
space 
> > for the disk controller in the MCFG vs non-MCFG cases?  That is, find the 
> > device's address using pciconf -lv (e.g. pci0:0:30:0 or some such) and 
then 
> > run this command under both configurations and save the output:
> > 
> > pciconf -r pci0:0:30:0 0:0xfc
> > 
> 
> I am not sure if your idea has something to do with my (and some other 
> users) problem. So excuse me, if this posting is wrong.
> 
> For some month now I am only able to boot CURRENT under amd64 with 
> setting hw.pci.mcfg=0. Under i386 all works fine. Below I listed output 
> under i386 and under amd64. Perhaps you are able to get a hint?

Hmm, would you be able to boot with mcfg=1 on amd64 (perhaps using nfsroot or 
an mfsroot) and capture this output?  The mcfg thing only affects access to
PCI config space (what pciconf -r is displaying).  I want to be able to 
compare the "broken" case (amd64 mcfg=1) with a working case.

> Tell me if I can help in any way.
> 
> Thanks in advance,
> Rainer Hurling
> 
> 
> #pciconf -lv
> atapci1@pci0:0:5:0:     class=0x010185 card=0x72601462 chip=0x037f10de 
> rev=0xa2 hdr=0x00
> vendor     = 'Nvidia Corp'
>      device     = 'MCP55 SATA/RAID Controller (MCP55S)'
>      class      = mass storage
>      subclass   = ATA
> atapci2@pci0:0:5:1:     class=0x010185 card=0x72601462 chip=0x037f10de
> rev=0xa2 hdr=0x00
>      vendor     = 'Nvidia Corp'
>      device     = 'MCP55 SATA/RAID Controller (MCP55S)'
>      class      = mass storage
>      subclass   = ATA
> 
> 
> --- i386 Config  ----------------------------------------------------
> #sysctl hw.pci.mcfg
> hw.pci.mcfg: 1
> 
> #pciconf -r pci0:0:5:0 0:0xfc
> 037f10de 00b00007 010185a2 00800000
> 0000c481 0000c401 0000c081 0000c001
> 0000bc01 f9ef9000 00000000 72601462
> 00000000 00000044 00000000 01030117
> 72601462 0002b001 00000000 00000000
> 0008680f 00000000 00000000 00000000
> 00000000 00000c41 42060f00 00000000
> 40c4782c 00001001 00001001 00200020
> c0000000 0f498000 a0200000 7c750000
> a0100000 00000000 10060006 0101037f
> 19000a12 00000000 00000000 02003133
> 0084cc05 00000000 00000000 00000000
> 00000000 00000000 000a000a a8020008
> 0c02000a 00000042 00000000 e7c00001
> 0c02000a 00000042 00000000 e030000f
> 00000000 00000000 000c0010 00000000
> 
> #pciconf -r pci0:0:5:1 0:0xfc
> 037f10de 00b00007 010185a2 00800000
> 0000b881 0000b801 0000b481 0000b401
> 0000b081 f9ef8000 00000000 72601462
> 00000000 00000044 00000000 01030214
> 72601462 0002b001 00000000 00000000
> 0008680f 00000000 00000000 00000000
> 00000000 00000c41 42060f00 00000000
> 40c4782c 00001001 00001001 00200020
> c0000000 ffefffff 0f1f0000 f7ff7f3b
> 3fb70000 00000000 10060006 0101037f
> 00000a12 00000000 00000000 02003133
> 0084cc05 00000000 00000000 00000000
> 00000000 00000000 000a000a a8020008
> 0602000a 00000042 00000000 0050000f
> 0602000a 00000042 00000000 0040000f
> 00000000 00000000 000c0010 00000000
> 
> 
> --- amd64 Config  ---------------------------------------------------
> #sysctl hw.pci.mcfg
> hw.pci.mcfg: 0
> 
> #pciconf -r pci0:0:5:0 0:0xfc
> 037f10de 00b00007 010185a2 00800000
> 0000c481 0000c401 0000c081 0000c001
> 0000bc01 f9ef9000 00000000 72601462
> 00000000 00000044 00000000 01030117
> 72601462 0002b001 00000000 00000000
> 0008680f 00000000 00000000 00000000
> 00000000 00000c41 42060f00 00000000
> 40c4782c 00001001 00001001 00200020
> c0000000 03562000 80080000 41403000
> b0080000 00000000 10060006 0101037f
> 18000a12 00000000 00000000 02003133
> 0084cc05 00000000 00000000 00000000
> 00000000 00000000 000a000a a8020008
> 0c02000a 00000042 00000000 e7c00001
> 0c02000a 00000042 00000000 e030000f
> 00000000 00000000 000c0010 00000000
> 
> #pciconf -r pci0:0:5:1 0:0xfc
> 037f10de 00b00007 010185a2 00800000
> 0000b881 0000b801 0000b481 0000b401
> 0000b081 f9ef8000 00000000 72601462
> 00000000 00000044 00000000 01030214
> 72601462 0002b001 00000000 00000000
> 0008680f 00000000 00000000 00000000
> 00000000 00000c41 42060f00 00000000
> 40c4782c 00001001 00001001 00200020
> 00000000 ffefffff 0f1f0000 f7ff7f3b
> 3fb70000 00000000 10060006 0101037f
> 00000a12 00000000 00000000 02003133
> 0084cc05 00000000 00000000 00000000
> 00000000 00000000 000a000a a8020008
> 0602000a 00000042 00000000 0050000f
> 0602000a 00000042 00000000 0040000f
> 00000000 00000000 000c0010 00000000
> 



-- 
John Baldwin
From rhurlin at gwdg.de  Tue Sep  1 18:49:18 2009
From: rhurlin at gwdg.de (Rainer Hurling)
Date: Tue Sep  1 18:49:25 2009
Subject: 8.0-beta3 does not detect several ata channels
In-Reply-To: <200909011341.26192.jhb@freebsd.org>
References: <4A9BF23F.6070801@netability.ie>
	<200909011002.59592.jhb@freebsd.org> <4A9D5036.9000403@gwdg.de>
	<200909011341.26192.jhb@freebsd.org>
Message-ID: <4A9D6CA5.1040409@gwdg.de>

On 01.09.2009 19:41 (UTC+2), John Baldwin wrote:
> On Tuesday 01 September 2009 12:47:50 pm Rainer Hurling wrote:
>> On 01.09.2009 16:02 (UTC+2), John Baldwin wrote:
>>> On Monday 31 August 2009 12:03:04 pm Florian Smeets wrote:
>>>> On 8/31/09 5:54 PM, Nick Hilliard wrote:
>>>>> Hi,
>>>>>
>>>>> I have a hp proliant ML115 with 6 sata ports which run in ATA mode (bios
>>>>> doesn't appear to give the option to use AHCI).  On freebsd 7.x, all
>>>>> channels are detected.  On freebsd8.0-beta3, the disks attached to the
>>>>> first two SATA ports are not detected, although it detects the ports
>>>>> themselves.
>>>>>
>>>>> I've attached a verbose dmesg from freebsd 7.1 and 8.0-beta3.
>>>>>
>>>>> Any ideas on what's going on here?  This seems like a nasty regression.
>>>> There are 3 PRs about this problem: 128686, 132372, 137942.
>>>>
>>>> i386 version should recognize the disks. amd64 does when you set
>>>> hw.pci.mcfg=0 in loader.conf.
>>> Hmm, so an idea I had just now.. can you grab a dump of the PCI config 
> space 
>>> for the disk controller in the MCFG vs non-MCFG cases?  That is, find the 
>>> device's address using pciconf -lv (e.g. pci0:0:30:0 or some such) and 
> then 
>>> run this command under both configurations and save the output:
>>>
>>> pciconf -r pci0:0:30:0 0:0xfc
>>>
>> I am not sure if your idea has something to do with my (and some other 
>> users) problem. So excuse me, if this posting is wrong.
>>
>> For some month now I am only able to boot CURRENT under amd64 with 
>> setting hw.pci.mcfg=0. Under i386 all works fine. Below I listed output 
>> under i386 and under amd64. Perhaps you are able to get a hint?
> 
> Hmm, would you be able to boot with mcfg=1 on amd64 (perhaps using nfsroot or 
> an mfsroot) and capture this output?  The mcfg thing only affects access to
> PCI config space (what pciconf -r is displaying).  I want to be able to 
> compare the "broken" case (amd64 mcfg=1) with a working case.

My only amd64 system is at home. Sorry, but I have no idea how to start 
this system using nfsroot oder mfsroot.

>> Tell me if I can help in any way.
>>
>> Thanks in advance,
>> Rainer Hurling
>>
>>
>> #pciconf -lv
>> atapci1@pci0:0:5:0:     class=0x010185 card=0x72601462 chip=0x037f10de 
>> rev=0xa2 hdr=0x00
>> vendor     = 'Nvidia Corp'
>>      device     = 'MCP55 SATA/RAID Controller (MCP55S)'
>>      class      = mass storage
>>      subclass   = ATA
>> atapci2@pci0:0:5:1:     class=0x010185 card=0x72601462 chip=0x037f10de
>> rev=0xa2 hdr=0x00
>>      vendor     = 'Nvidia Corp'
>>      device     = 'MCP55 SATA/RAID Controller (MCP55S)'
>>      class      = mass storage
>>      subclass   = ATA
>>
>>
>> --- i386 Config  ----------------------------------------------------
>> #sysctl hw.pci.mcfg
>> hw.pci.mcfg: 1
>>
>> #pciconf -r pci0:0:5:0 0:0xfc
>> 037f10de 00b00007 010185a2 00800000
>> 0000c481 0000c401 0000c081 0000c001
>> 0000bc01 f9ef9000 00000000 72601462
>> 00000000 00000044 00000000 01030117
>> 72601462 0002b001 00000000 00000000
>> 0008680f 00000000 00000000 00000000
>> 00000000 00000c41 42060f00 00000000
>> 40c4782c 00001001 00001001 00200020
>> c0000000 0f498000 a0200000 7c750000
>> a0100000 00000000 10060006 0101037f
>> 19000a12 00000000 00000000 02003133
>> 0084cc05 00000000 00000000 00000000
>> 00000000 00000000 000a000a a8020008
>> 0c02000a 00000042 00000000 e7c00001
>> 0c02000a 00000042 00000000 e030000f
>> 00000000 00000000 000c0010 00000000
>>
>> #pciconf -r pci0:0:5:1 0:0xfc
>> 037f10de 00b00007 010185a2 00800000
>> 0000b881 0000b801 0000b481 0000b401
>> 0000b081 f9ef8000 00000000 72601462
>> 00000000 00000044 00000000 01030214
>> 72601462 0002b001 00000000 00000000
>> 0008680f 00000000 00000000 00000000
>> 00000000 00000c41 42060f00 00000000
>> 40c4782c 00001001 00001001 00200020
>> c0000000 ffefffff 0f1f0000 f7ff7f3b
>> 3fb70000 00000000 10060006 0101037f
>> 00000a12 00000000 00000000 02003133
>> 0084cc05 00000000 00000000 00000000
>> 00000000 00000000 000a000a a8020008
>> 0602000a 00000042 00000000 0050000f
>> 0602000a 00000042 00000000 0040000f
>> 00000000 00000000 000c0010 00000000
>>
>>
>> --- amd64 Config  ---------------------------------------------------
>> #sysctl hw.pci.mcfg
>> hw.pci.mcfg: 0
>>
>> #pciconf -r pci0:0:5:0 0:0xfc
>> 037f10de 00b00007 010185a2 00800000
>> 0000c481 0000c401 0000c081 0000c001
>> 0000bc01 f9ef9000 00000000 72601462
>> 00000000 00000044 00000000 01030117
>> 72601462 0002b001 00000000 00000000
>> 0008680f 00000000 00000000 00000000
>> 00000000 00000c41 42060f00 00000000
>> 40c4782c 00001001 00001001 00200020
>> c0000000 03562000 80080000 41403000
>> b0080000 00000000 10060006 0101037f
>> 18000a12 00000000 00000000 02003133
>> 0084cc05 00000000 00000000 00000000
>> 00000000 00000000 000a000a a8020008
>> 0c02000a 00000042 00000000 e7c00001
>> 0c02000a 00000042 00000000 e030000f
>> 00000000 00000000 000c0010 00000000
>>
>> #pciconf -r pci0:0:5:1 0:0xfc
>> 037f10de 00b00007 010185a2 00800000
>> 0000b881 0000b801 0000b481 0000b401
>> 0000b081 f9ef8000 00000000 72601462
>> 00000000 00000044 00000000 01030214
>> 72601462 0002b001 00000000 00000000
>> 0008680f 00000000 00000000 00000000
>> 00000000 00000c41 42060f00 00000000
>> 40c4782c 00001001 00001001 00200020
>> 00000000 ffefffff 0f1f0000 f7ff7f3b
>> 3fb70000 00000000 10060006 0101037f
>> 00000a12 00000000 00000000 02003133
>> 0084cc05 00000000 00000000 00000000
>> 00000000 00000000 000a000a a8020008
>> 0602000a 00000042 00000000 0050000f
>> 0602000a 00000042 00000000 0040000f
>> 00000000 00000000 000c0010 00000000


From jhb at freebsd.org  Tue Sep  1 19:17:29 2009
From: jhb at freebsd.org (John Baldwin)
Date: Tue Sep  1 19:17:36 2009
Subject: 8.0-beta3 does not detect several ata channels
In-Reply-To: <4A9D6CA5.1040409@gwdg.de>
References: <4A9BF23F.6070801@netability.ie>
	<200909011341.26192.jhb@freebsd.org> <4A9D6CA5.1040409@gwdg.de>
Message-ID: <200909011505.32243.jhb@freebsd.org>

On Tuesday 01 September 2009 2:49:09 pm Rainer Hurling wrote:
> On 01.09.2009 19:41 (UTC+2), John Baldwin wrote:
> > On Tuesday 01 September 2009 12:47:50 pm Rainer Hurling wrote:
> >> On 01.09.2009 16:02 (UTC+2), John Baldwin wrote:
> >>> On Monday 31 August 2009 12:03:04 pm Florian Smeets wrote:
> >>>> On 8/31/09 5:54 PM, Nick Hilliard wrote:
> >>>>> Hi,
> >>>>>
> >>>>> I have a hp proliant ML115 with 6 sata ports which run in ATA mode 
(bios
> >>>>> doesn't appear to give the option to use AHCI).  On freebsd 7.x, all
> >>>>> channels are detected.  On freebsd8.0-beta3, the disks attached to the
> >>>>> first two SATA ports are not detected, although it detects the ports
> >>>>> themselves.
> >>>>>
> >>>>> I've attached a verbose dmesg from freebsd 7.1 and 8.0-beta3.
> >>>>>
> >>>>> Any ideas on what's going on here?  This seems like a nasty 
regression.
> >>>> There are 3 PRs about this problem: 128686, 132372, 137942.
> >>>>
> >>>> i386 version should recognize the disks. amd64 does when you set
> >>>> hw.pci.mcfg=0 in loader.conf.
> >>> Hmm, so an idea I had just now.. can you grab a dump of the PCI config 
> > space 
> >>> for the disk controller in the MCFG vs non-MCFG cases?  That is, find 
the 
> >>> device's address using pciconf -lv (e.g. pci0:0:30:0 or some such) and 
> > then 
> >>> run this command under both configurations and save the output:
> >>>
> >>> pciconf -r pci0:0:30:0 0:0xfc
> >>>
> >> I am not sure if your idea has something to do with my (and some other 
> >> users) problem. So excuse me, if this posting is wrong.
> >>
> >> For some month now I am only able to boot CURRENT under amd64 with 
> >> setting hw.pci.mcfg=0. Under i386 all works fine. Below I listed output 
> >> under i386 and under amd64. Perhaps you are able to get a hint?
> > 
> > Hmm, would you be able to boot with mcfg=1 on amd64 (perhaps using nfsroot 
or 
> > an mfsroot) and capture this output?  The mcfg thing only affects access 
to
> > PCI config space (what pciconf -r is displaying).  I want to be able to 
> > compare the "broken" case (amd64 mcfg=1) with a working case.
> 
> My only amd64 system is at home. Sorry, but I have no idea how to start 
> this system using nfsroot oder mfsroot.

Ok, I believe some of the other folks reporting an issue with this ATA 
controller had other disk controllers in the system so they may be able to do 
this.

-- 
John Baldwin
From kostikbel at gmail.com  Tue Sep  1 19:21:28 2009
From: kostikbel at gmail.com (Kostik Belousov)
Date: Tue Sep  1 19:21:35 2009
Subject: 8.0-beta3 does not detect several ata channels
In-Reply-To: <200909011505.32243.jhb@freebsd.org>
References: <4A9BF23F.6070801@netability.ie>
	<200909011341.26192.jhb@freebsd.org> <4A9D6CA5.1040409@gwdg.de>
	<200909011505.32243.jhb@freebsd.org>
Message-ID: <20090901192122.GS1881@deviant.kiev.zoral.com.ua>

On Tue, Sep 01, 2009 at 03:05:31PM -0400, John Baldwin wrote:
> On Tuesday 01 September 2009 2:49:09 pm Rainer Hurling wrote:
> > On 01.09.2009 19:41 (UTC+2), John Baldwin wrote:
> > > Hmm, would you be able to boot with mcfg=1 on amd64 (perhaps using nfsroot 
> or 
> > > an mfsroot) and capture this output?  The mcfg thing only affects access 
> to
> > > PCI config space (what pciconf -r is displaying).  I want to be able to 
> > > compare the "broken" case (amd64 mcfg=1) with a working case.
> > 
> > My only amd64 system is at home. Sorry, but I have no idea how to start 
> > this system using nfsroot oder mfsroot.
> 
> Ok, I believe some of the other folks reporting an issue with this ATA 
> controller had other disk controllers in the system so they may be able to do 
> this.

 Might be, LiveCD would help ?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20090901/42b31641/attachment.pgp
From hselasky at c2i.net  Tue Sep  1 19:50:55 2009
From: hselasky at c2i.net (Hans Petter Selasky)
Date: Tue Sep  1 19:51:02 2009
Subject: [PATCH] USB Harddrive not recognized (umass appears, da0 not)
In-Reply-To: <1251792510.1176.2.camel@localhost>
References: <1251570251.1238.21.camel@localhost>
	<20490_1251788178_4A9CC592_20490_149_1_200909010856.23045.hselasky@c2i.net>
	<1251792510.1176.2.camel@localhost>
Message-ID: <200909012151.09283.hselasky@c2i.net>

Hi,

Here is the commit:

http://perforce.freebsd.org/chv.cgi?CH=168039

--HPS

From grosser at fim.uni-passau.de  Tue Sep  1 20:19:56 2009
From: grosser at fim.uni-passau.de (Tobias Grosser)
Date: Tue Sep  1 20:20:03 2009
Subject: [PATCH] USB Harddrive not recognized (umass appears, da0 not)
In-Reply-To: <200909012151.09283.hselasky@c2i.net>
References: <1251570251.1238.21.camel@localhost>
	<20490_1251788178_4A9CC592_20490_149_1_200909010856.23045.hselasky@c2i.net>
	<1251792510.1176.2.camel@localhost>
	<200909012151.09283.hselasky@c2i.net>
Message-ID: <1251836380.6790.66.camel@localhost>

On Tue, 2009-09-01 at 21:51 +0200, Hans Petter Selasky wrote:
> Hi,
> 
> Here is the commit:
> 
> http://perforce.freebsd.org/chv.cgi?CH=168039
> 
> --HPS

Thanks a lot.

Hope to see this in 8.0 or at least soon in RELENG_8.

Tobias

From billsf at cuba.calyx.nl  Tue Sep  1 20:31:07 2009
From: billsf at cuba.calyx.nl (Bill Squire {billsf})
Date: Tue Sep  1 20:31:15 2009
Subject: The only problems with v8.0 are: 
Message-ID: <20090901201346.GA2432@cuba.calyx.nl>


These 'bug' me:

There are always going to be the bugs we never see, but the following three
seem to be real. (Note I'm using yesterday's rpc/xdr.h to get the cddl stuff
to build which provides zfs.)  

8.0 is ready. The '/boot/loader' has been a long time problem. If I'm the 
only one that knows Forth (my first computer language) I probably can fix it.
However, a loader from v7 should do fine.

There appears to be a typo in one of the cddl 32bit Makefiles. It doesn't get 
a certain header file into */obj/. That file is: '/usr/include/rpc/xdr.h'.

The other problem is an annoyance. I believe snd_uaudio is not expecting HID.
Plugging in the driver in with hardware attached causes instant (but harmless)
freezing and no dump. Tests are with the C-Media CM106 and CM108. They can be
had for as little as 5 Euros. They sound excellent through my Genelecs. If
you do electronics take out the descriptors for HID. Alternately the snd_hda
driver is a masterpiece. The old snd_es137x cards were the last of the great 
'soundblasters' and sound excellent. (Forget the new cards.) While not every-
one is a 'practical audiophile' like me, I'm sure most have at least an extra
soundcard. I like USB because it puts the analogue circuitry away from the 
digital. I can live with hda at last. :)

BillSF

I'm running an SMP amd64 K9 (quickly the name was realised) with 8GB RAM, a
typical developer system. Believe the BSD speed -- not the BIOS and adjust
to assure you are not over-clocking. Note an Athlon 3000MHz is an Opteron
2800MHz and AMD advises 2800MHzfor this part. A stack of dual 2800's makes 
for a killer system. Professionally, I prefer multiple singles running in NUMA
mode. (Call it SMP for the kernel, but its more like clustered computers.)
I'll be standing by if I can verify any bug reports not mentioned. The worst
thing is bad hardware -- 100 buck motherboards in particular. Asus makes a
few good ones and the "M3A78 PRO" is a 'best value'. Otherwise spend 300
bucks for a real motherboard. I keep several previous builds just in case. 
I'm over to v9.0 -- the easiest transition so far. 

B. 
From swell.k at gmail.com  Tue Sep  1 20:31:46 2009
From: swell.k at gmail.com (Anonymous)
Date: Tue Sep  1 20:31:52 2009
Subject: Reducing noise in dmesg output
In-Reply-To: <200909010931.16880.nick@van-laarhoven.org> (Nick Hibma's message
	of "Tue, 1 Sep 2009 09:31:16 +0200")
References: <200909010931.16880.nick@van-laarhoven.org>
Message-ID: <86d46ao190.fsf@gmail.com>

Nick Hibma <nick@van-laarhoven.org> writes:

> Folks,
>
> dmesg is getting cluttered with random bits of irrelevant information which 
> either should be behind bootverbose or not at all present. Below two 
> locations where I intend to remove that information. The fact that a module 
> is loaded can be seen in the output of
>
> 	kldstat -v | grep netsmb
[...]

Can you remove similar noise from ichwd(4), too?
From hselasky at c2i.net  Tue Sep  1 20:35:34 2009
From: hselasky at c2i.net (Hans Petter Selasky)
Date: Tue Sep  1 20:35:44 2009
Subject: The only problems with v8.0 are:
In-Reply-To: <20090901201346.GA2432@cuba.calyx.nl>
References: <20090901201346.GA2432@cuba.calyx.nl>
Message-ID: <200909012235.51707.hselasky@c2i.net>

On Tuesday 01 September 2009 22:13:46 Bill Squire {billsf} wrote:
> I believe snd_uaudio is not expecting HID.
> Plugging in the driver in with hardware attached causes instant (but
> harmless) freezing and no dump.

Hi,

Could you provide more debugging in the form of:

usbconfig -u XXX -a YYY dump_device_desc dump_curr_config_desc

uname -a

for your device. You can build a kernel without snd_uaudio.

Also try to enable Uaudio debugging before plugging the device.

sysctl hw.usb.uaudio.debug=15

--HPS
From rhurlin at gwdg.de  Tue Sep  1 20:40:49 2009
From: rhurlin at gwdg.de (Rainer Hurling)
Date: Tue Sep  1 20:40:56 2009
Subject: 8.0-beta3 does not detect several ata channels
In-Reply-To: <200909011505.32243.jhb@freebsd.org>
References: <4A9BF23F.6070801@netability.ie>
	<200909011341.26192.jhb@freebsd.org> <4A9D6CA5.1040409@gwdg.de>
	<200909011505.32243.jhb@freebsd.org>
Message-ID: <4A9D86C9.1020603@gwdg.de>

On 01.09.2009 21:05 (UTC+2), John Baldwin wrote:
> On Tuesday 01 September 2009 2:49:09 pm Rainer Hurling wrote:
>> On 01.09.2009 19:41 (UTC+2), John Baldwin wrote:
>>> On Tuesday 01 September 2009 12:47:50 pm Rainer Hurling wrote:
>>>> On 01.09.2009 16:02 (UTC+2), John Baldwin wrote:
>>>>> On Monday 31 August 2009 12:03:04 pm Florian Smeets wrote:
>>>>>> On 8/31/09 5:54 PM, Nick Hilliard wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>> I have a hp proliant ML115 with 6 sata ports which run in ATA mode 
> (bios
>>>>>>> doesn't appear to give the option to use AHCI).  On freebsd 7.x, all
>>>>>>> channels are detected.  On freebsd8.0-beta3, the disks attached to the
>>>>>>> first two SATA ports are not detected, although it detects the ports
>>>>>>> themselves.
>>>>>>>
>>>>>>> I've attached a verbose dmesg from freebsd 7.1 and 8.0-beta3.
>>>>>>>
>>>>>>> Any ideas on what's going on here?  This seems like a nasty 
> regression.
>>>>>> There are 3 PRs about this problem: 128686, 132372, 137942.
>>>>>>
>>>>>> i386 version should recognize the disks. amd64 does when you set
>>>>>> hw.pci.mcfg=0 in loader.conf.
>>>>> Hmm, so an idea I had just now.. can you grab a dump of the PCI config 
>>> space 
>>>>> for the disk controller in the MCFG vs non-MCFG cases?  That is, find 
> the 
>>>>> device's address using pciconf -lv (e.g. pci0:0:30:0 or some such) and 
>>> then 
>>>>> run this command under both configurations and save the output:
>>>>>
>>>>> pciconf -r pci0:0:30:0 0:0xfc
>>>>>
>>>> I am not sure if your idea has something to do with my (and some other 
>>>> users) problem. So excuse me, if this posting is wrong.
>>>>
>>>> For some month now I am only able to boot CURRENT under amd64 with 
>>>> setting hw.pci.mcfg=0. Under i386 all works fine. Below I listed output 
>>>> under i386 and under amd64. Perhaps you are able to get a hint?
>>> Hmm, would you be able to boot with mcfg=1 on amd64 (perhaps using nfsroot 
> or 
>>> an mfsroot) and capture this output?  The mcfg thing only affects access 
> to
>>> PCI config space (what pciconf -r is displaying).  I want to be able to 
>>> compare the "broken" case (amd64 mcfg=1) with a working case.
>> My only amd64 system is at home. Sorry, but I have no idea how to start 
>> this system using nfsroot oder mfsroot.
> 
> Ok, I believe some of the other folks reporting an issue with this ATA 
> controller had other disk controllers in the system so they may be able to do 
> this.

Thanks to Kostik Belousov, I tried his hint with live CD. Here it is, 
only for amd64, with snapshot from todays CURRENT:

#systctl hw.pci.mcfg
hw.pci.mcfg: 1

#pciconf -lv
atapci1@pci0:0:5:0:     class=0x010185 card=0x72601462 chip=0x037f10de 
rev=0xa2 hdr=0x00
     class      = mass storage
     subclass   = ATA
atapci2@pci0:0:5:1:     class=0x010185 card=0x72601462 chip=0x037f10de 
rev=0xa2 hdr=0x00
     class      = mass storage
     subclass   = ATA

#pciconf -r pci0:0:5:0 0:0xfc
037f10de 00b00007 010185a2 00800000
0000c481 0000c401 0000c081 0000c001
0000bc01 f9ef9000 00000000 72601462
00000000 00000044 00000000 01030117
72601462 0002b001 00000000 00000000
0008680f 00000000 00000000 00000000
00000000 00000c41 42060f00 00000000
40c4782c 00001001 00001001 00200020
c0000000 00061000 bd280000 00061000
bd280000 00000000 10060006 0101037f
18000a12 00000000 00000000 02003133
0084cc05 00000000 00000000 00000000
00000000 00000000 000a000a a8020008
0c02000a 00000042 00000000 e7c00001
0c02000a 00000042 00000000 e030000f
00000000 00000000 000c0010 00000000

#pciconf -r pci0:0:5:1 0:0xfc
037f10de 00b00007 010185a2 00800000
0000b881 0000b801 0000b481 0000b401
0000b081 f9ef8000 00000000 72601462
00000000 00000044 00000000 01030214
72601462 0002b001 00000000 00000000
0008680f 00000000 00000000 00000000
00000000 00000c41 42060f00 00000000
40c4782c 00001001 00001001 00200020
00000000 ffefffff 0f1f0000 f7ff7f3b
3fb70000 00000000 10060006 0101037f
00000a12 00000000 00000000 02003133
0084cc05 00000000 00000000 00000000
00000000 00000000 000a000a a8020008
0602000a 00000042 00000000 0050000f
0602000a 00000042 00000000 0040000f
00000000 00000000 000c0010 00000000

From stb at lassitu.de  Tue Sep  1 20:45:19 2009
From: stb at lassitu.de (Stefan Bethke)
Date: Tue Sep  1 20:45:26 2009
Subject: Elsa MicroLink 56k USB is not picked up by umodem
Message-ID: <15577E21-9A9B-45CA-BC56-D1AB1FF6A5A9@lassitu.de>

Just dug out my sturdy old Elsa modem, and the new USB stack does not  
recognize it anymore. Is that intentional, or did the device IDs just  
dropped between the cracks on the conversion to the new USB stack?


# dmesg
...
ugen0.3: <vendor 0x05cc> at usbus0
# usbconfig list
ugen0.1: <UHCI root HUB Intel> at usbus0, cfg=0 md=HOST spd=FULL  
(12Mbps) pwr=ON
ugen1.1: <EHCI root HUB (0x15ad)> at usbus1, cfg=0 md=HOST spd=HIGH  
(480Mbps) pwr=ON
ugen0.2: <product 0x0002 vendor 0x0e0f> at usbus0, cfg=0 md=HOST  
spd=FULL (12Mbps) pwr=SAVE
ugen0.3: <product 0x2265 vendor 0x05cc> at usbus0, cfg=0 md=HOST  
spd=FULL (12Mbps) pwr=ON


7-stable sees this:
# usbdevs -v
Controller /dev/usb0:
addr 1: full speed, self powered, config 1, UHCI root hub(0x0000),  
Intel(0x0000), rev 1.00
  port 1 addr 3: full speed, power 400 mA, config 2, ELSA Modem  
Board(0x2265), Lucent Technologies, Inc.(0x05cc), rev 1.00
...
# dmesg
...
ucom0: <Lucent Technologies, Inc. ELSA Modem Board, class 2/0, rev  
1.00/1.00, addr 3> on uhub0
ucom0: iclass 2/2
ucom0: data interface 1, has CM over data, has break
ucom0: status change notification available


Stefan

-- 
Stefan Bethke <stb@lassitu.de>   Fon +49 151 14070811




From hselasky at c2i.net  Tue Sep  1 20:50:29 2009
From: hselasky at c2i.net (Hans Petter Selasky)
Date: Tue Sep  1 20:50:35 2009
Subject: Elsa MicroLink 56k USB is not picked up by umodem
In-Reply-To: <15577E21-9A9B-45CA-BC56-D1AB1FF6A5A9@lassitu.de>
References: <15577E21-9A9B-45CA-BC56-D1AB1FF6A5A9@lassitu.de>
Message-ID: <200909012250.48439.hselasky@c2i.net>

On Tuesday 01 September 2009 22:45:15 Stefan Bethke wrote:
> Just dug out my sturdy old Elsa modem, and the new USB stack does not
> recognize it anymore. Is that intentional, or did the device IDs just
> dropped between the cracks on the conversion to the new USB stack?
>
>
> # dmesg
> ...
> ugen0.3: <vendor 0x05cc> at usbus0
> # usbconfig list
> ugen0.1: <UHCI root HUB Intel> at usbus0, cfg=0 md=HOST spd=FULL
> (12Mbps) pwr=ON
> ugen1.1: <EHCI root HUB (0x15ad)> at usbus1, cfg=0 md=HOST spd=HIGH
> (480Mbps) pwr=ON
> ugen0.2: <product 0x0002 vendor 0x0e0f> at usbus0, cfg=0 md=HOST
> spd=FULL (12Mbps) pwr=SAVE
> ugen0.3: <product 0x2265 vendor 0x05cc> at usbus0, cfg=0 md=HOST
> spd=FULL (12Mbps) pwr=ON
>
>
> 7-stable sees this:
> # usbdevs -v
> Controller /dev/usb0:
> addr 1: full speed, self powered, config 1, UHCI root hub(0x0000),
> Intel(0x0000), rev 1.00
>   port 1 addr 3: full speed, power 400 mA, config 2, ELSA Modem
> Board(0x2265), Lucent Technologies, Inc.(0x05cc), rev 1.00
> ...
> # dmesg
> ...
> ucom0: <Lucent Technologies, Inc. ELSA Modem Board, class 2/0, rev
> 1.00/1.00, addr 3> on uhub0
> ucom0: iclass 2/2
> ucom0: data interface 1, has CM over data, has break
> ucom0: status change notification available
>
>
> Stefan

Did you load umodem ??

kldstat ?

Also check if your modem has multiple configurations. Maybe you have to set a 
configuration different from config index = 0.

usbconfig -u XXX -a YYY set_config 1

--HPS

From hselasky at c2i.net  Tue Sep  1 21:00:19 2009
From: hselasky at c2i.net (Hans Petter Selasky)
Date: Tue Sep  1 21:00:26 2009
Subject: The only problems with v8.0 are:
Message-ID: <200909012300.37344.hselasky@c2i.net>

On Tuesday 01 September 2009 22:13:46 Bill Squire {billsf} wrote:
> I believe snd_uaudio is not expecting HID.
> Plugging in the driver in with hardware attached causes instant (but
> harmless) freezing and no dump.

Hi,

Test proposal:

Try to reduce:

#define	UAUDIO_RECURSE_LIMIT   24	/* rounds */

Into:

#define	UAUDIO_RECURSE_LIMIT   10 /* rounds */

In: /usr/src/sys/dev/sound/usb/uaudio.c

Maybe the current descriptor parsing code is too CPU hungry if the descriptor 
is bad :-)

--HPS

From nick at van-laarhoven.org  Tue Sep  1 21:00:51 2009
From: nick at van-laarhoven.org (Nick Hibma)
Date: Tue Sep  1 21:01:06 2009
Subject: Reducing noise in dmesg output
In-Reply-To: <86d46ao190.fsf@gmail.com>
References: <200909010931.16880.nick@van-laarhoven.org>
	<86d46ao190.fsf@gmail.com>
Message-ID: <200909012300.42231.nick@van-laarhoven.org>

I'll have a look.

Cheers,

Nick

> Nick Hibma <nick@van-laarhoven.org> writes:
> > Folks,
> >
> > dmesg is getting cluttered with random bits of irrelevant information
> > which either should be behind bootverbose or not at all present. Below
> > two locations where I intend to remove that information. The fact that
> > a module is loaded can be seen in the output of
> >
> > 	kldstat -v | grep netsmb
>
> [...]
>
> Can you remove similar noise from ichwd(4), too?

From ed at 80386.nl  Tue Sep  1 21:08:04 2009
From: ed at 80386.nl (Ed Schouten)
Date: Tue Sep  1 21:08:11 2009
Subject: man and UTF-8 locales
In-Reply-To: <01895862@bb.ipt.ru>
References: <01895862@bb.ipt.ru>
Message-ID: <20090901210803.GF2829@hoeg.nl>

Hi,

I'm also a bit puzzled by the nm(1) manpage. It uses U+23AA (CURLY
BRACKET EXTENSION) for the |-characters in the SYNOPSIS section. Is this
character really meant to be used this way?

-- 
 Ed Schouten <ed@80386.nl>
 WWW: http://80386.nl/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20090901/96c42e45/attachment.pgp
From rnoland at FreeBSD.org  Tue Sep  1 21:43:45 2009
From: rnoland at FreeBSD.org (Robert Noland)
Date: Tue Sep  1 21:43:59 2009
Subject: Reducing noise in dmesg output
In-Reply-To: <200909010931.16880.nick@van-laarhoven.org>
References: <200909010931.16880.nick@van-laarhoven.org>
Message-ID: <1251841416.1689.4458.camel@balrog.2hip.net>

On Tue, 2009-09-01 at 09:31 +0200, Nick Hibma wrote:
> Folks,
> 
> dmesg is getting cluttered with random bits of irrelevant information which 
> either should be behind bootverbose or not at all present. Below two 
> locations where I intend to remove that information. The fact that a module 
> is loaded can be seen in the output of

What is irrelevant is subjective...  I mean does the average user really
need to see anything in dmesg?  Please don't change agp_i810.c.  A
verbose boot is incredibly noisy and rarely needed for debugging
anything except the most deep rooted of issues.

robert.

> 	kldstat -v | grep netsmb
> 
> the amount of stolen memory and aperture size might be interesting when 
> configuring your X server. Then again, most X servers nowadays HAVE no 
> configuration file anymore because of auto-configuration.
> 
> Any objections?
> 
> Nick
> 
> Index: kern/kern_shutdown.c
> ===================================================================
> --- kern/kern_shutdown.c	(revision 196710)
> +++ kern/kern_shutdown.c	(working copy)
> @@ -581,6 +581,10 @@
>  
>  /*
>   * Support for poweroff delay.
> + *
> + * Please note that setting this delay too short might power off your 
> machine
> + * before the write cache on your hard disk has been flushed, leading to
> + * soft-updates inconsistencies.
>   */
>  #ifndef POWEROFF_DELAY
>  # define POWEROFF_DELAY 5000
> Index: dev/agp/agp_i810.c
> ===================================================================
> --- dev/agp/agp_i810.c	(revision 196589)
> +++ dev/agp/agp_i810.c	(working copy)
> @@ -474,12 +474,15 @@
>  				agp_generic_detach(dev);
>  				return EINVAL;
>  		}
> -		if (sc->stolen > 0) {
> -			device_printf(dev, "detected %dk stolen memory\n",
> -			    sc->stolen * 4);
> +		if (bootverbose) {
> +			if (sc->stolen > 0) {
> +				device_printf(dev,
> +				    "detected %dk stolen memory\n",
> +				    sc->stolen * 4);
> +			}
> +			device_printf(dev, "aperture size is %dM\n",
> +			    sc->initial_aperture / 1024 / 1024);
>  		}
> -		device_printf(dev, "aperture size is %dM\n",
> -		    sc->initial_aperture / 1024 / 1024);
>  
>  		/* GATT address is already in there, make sure it's enabled */
>  		pgtblctl = bus_read_4(sc->sc_res[0], AGP_I810_PGTBL_CTL);
> @@ -664,9 +667,11 @@
>  		gtt_size += 4;
>  
>  		sc->stolen = (stolen - gtt_size) * 1024 / 4096;
> -		if (sc->stolen > 0)
> -			device_printf(dev, "detected %dk stolen memory\n", sc->stolen * 4);
> -		device_printf(dev, "aperture size is %dM\n", sc->initial_aperture / 1024 
> / 1024);
> +		if (bootverbose) {
> +			if (sc->stolen > 0)
> +				device_printf(dev, "detected %dk stolen memory\n", sc->stolen * 4);
> +			device_printf(dev, "aperture size is %dM\n", sc->initial_aperture / 1024 
> / 1024);
> +		}
>  
>  		/* GATT address is already in there, make sure it's enabled */
>  		pgtblctl = bus_read_4(sc->sc_res[0], AGP_I810_PGTBL_CTL);
> Index: netsmb/smb_dev.c
> ===================================================================
> --- netsmb/smb_dev.c	(revision 196589)
> +++ netsmb/smb_dev.c	(working copy)
> @@ -352,7 +352,6 @@
>  		}
>  		clone_setup(&nsmb_clones);
>  		nsmb_dev_tag = EVENTHANDLER_REGISTER(dev_clone, nsmb_dev_clone, 0, 1000);
> -		printf("netsmb_dev: loaded\n");
>  		break;
>  	    case MOD_UNLOAD:
>  		smb_iod_done();
> @@ -363,7 +362,6 @@
>  		drain_dev_clone_events();
>  		clone_cleanup(&nsmb_clones);
>  		destroy_dev_drain(&nsmb_cdevsw);
> -		printf("netsmb_dev: unloaded\n");
>  		break;
>  	    default:
>  		error = EINVAL;
> 
> _______________________________________________
> 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"
-- 
Robert Noland <rnoland@FreeBSD.org>
FreeBSD

From stb at lassitu.de  Tue Sep  1 21:48:57 2009
From: stb at lassitu.de (Stefan Bethke)
Date: Tue Sep  1 21:49:04 2009
Subject: Elsa MicroLink 56k USB is not picked up by umodem
In-Reply-To: <200909012250.48439.hselasky@c2i.net>
References: <15577E21-9A9B-45CA-BC56-D1AB1FF6A5A9@lassitu.de>
	<200909012250.48439.hselasky@c2i.net>
Message-ID: <CCD5E96B-30A7-4CE6-84B7-0DC1C364C674@lassitu.de>

Am 01.09.2009 um 22:50 schrieb Hans Petter Selasky:

> On Tuesday 01 September 2009 22:45:15 Stefan Bethke wrote:
>> # dmesg
>> ...
>> ugen0.3: <vendor 0x05cc> at usbus0
>
> Did you load umodem ??
>
> kldstat ?

Double checked, it's loaded.

> Also check if your modem has multiple configurations. Maybe you have  
> to set a
> configuration different from config index = 0.
>
> usbconfig -u XXX -a YYY set_config 1

Aha! That does seem to do the trick.  How would this get added into  
umodem or the quirks, or do I have to do some devd magic?

# usbconfig -u 0 -a 3 set_config 1
umodem0: <vendor 0x05cc product 0x2265, class 2/0, rev 1.00/1.00, addr  
3> on usbus0
umodem0: data interface 1, has CM over data, has break

Checking quickly with cu, I can make it dial out.


Thanks
Stefan

-- 
Stefan Bethke <stb@lassitu.de>   Fon +49 151 14070811




From hselasky at c2i.net  Tue Sep  1 21:57:29 2009
From: hselasky at c2i.net (Hans Petter Selasky)
Date: Tue Sep  1 21:57:36 2009
Subject: Elsa MicroLink 56k USB is not picked up by umodem
In-Reply-To: <CCD5E96B-30A7-4CE6-84B7-0DC1C364C674@lassitu.de>
References: <15577E21-9A9B-45CA-BC56-D1AB1FF6A5A9@lassitu.de>
	<200909012250.48439.hselasky@c2i.net>
	<CCD5E96B-30A7-4CE6-84B7-0DC1C364C674@lassitu.de>
Message-ID: <200909012357.42238.hselasky@c2i.net>

On Tuesday 01 September 2009 23:48:54 Stefan Bethke wrote:
> Am 01.09.2009 um 22:50 schrieb Hans Petter Selasky:
> > On Tuesday 01 September 2009 22:45:15 Stefan Bethke wrote:
> >> # dmesg
> >> ...
> >> ugen0.3: <vendor 0x05cc> at usbus0
> >
> > Did you load umodem ??
> >
> > kldstat ?
>
> Double checked, it's loaded.
>
> > Also check if your modem has multiple configurations. Maybe you have
> > to set a
> > configuration different from config index = 0.
> >
> > usbconfig -u XXX -a YYY set_config 1
>
> Aha! That does seem to do the trick.  How would this get added into
> umodem or the quirks, or do I have to do some devd magic?
>
> # usbconfig -u 0 -a 3 set_config 1
> umodem0: <vendor 0x05cc product 0x2265, class 2/0, rev 1.00/1.00, addr
> 3> on usbus0
> umodem0: data interface 1, has CM over data, has break
>
> Checking quickly with cu, I can make it dial out.

kldload usb_quirk

usbconfig dump_quirk_names

And then run something like:

usbconfig add_dev_quirk_vplh 0x??? 0x??? 0x0000 0xFFFF UQ_CFG_INDEX_1

Will make the quirk permanent.

If you make a patch for usbdevs and the usb_quirk.c in /sys/dev/usb/quirk/ 
then I can commit that.

--HPS

From skip at menantico.com  Wed Sep  2 01:57:08 2009
From: skip at menantico.com (Skip Ford)
Date: Wed Sep  2 01:57:14 2009
Subject: First keypresses after boot being discarded
In-Reply-To: <20090831094627.L24691@ury.york.ac.uk>
References: <4A9571EB.7090209@fsu.edu> <20090826195407.GW2829@hoeg.nl>
	<20090831094627.L24691@ury.york.ac.uk>
Message-ID: <20090902005944.GA1108@menantico.com>

Gavin Atkinson wrote:
> On Wed, 26 Aug 2009, Ed Schouten wrote:
> >People also reported issues to me where the first keypresses after the
> >system has booted are discarded. I have yet to be convinced this is a
> >TTY issue, not the keyboard code, interrupt handling, etc.
> 
> I've seen this, and might be able to offer some more information.  I 
> booted 8.0-BETA2 from the same hard drive install on about 15 machines, 
> and saw this problem on four of them, all identical motherboards.

I've run into a very similar-sounding problem, but not since 7.0-RELEASE.
One machine would appear to hang at the initial login prompt, nothing
typed is echoed.  However, a soft reset would then cause whatever was
typed at the prompt to finally be displayed before the shutdown messages
would be displayed.

This would happen possibly 4 out of 10 times on one machine only
whenever it included both SCHED_ULE and kbdmux(4).  It never happened
with SCHED_4BSD and kbdmux(4), as 7.0 shipped, and it never happened with
SCHED_ULE only.

So, I had to remove kbdmux(4) to use SCHED_ULE instead of SCHED_4BSD in
7.0 to avoid that intermittent problem just on that one machine.

-- 
Skip
From grarpamp at gmail.com  Wed Sep  2 03:04:54 2009
From: grarpamp at gmail.com (grarpamp)
Date: Wed Sep  2 03:45:29 2009
Subject: LOR RELENG_8 umount
Message-ID: <d2e731a10909012004n3deca615yffb62a54666eb385@mail.gmail.com>

FYI... seems to happen now and then, haven't narrowed further.

lock order reversal:
 1st 0xc51036a0 ufs (ufs) @ /.../src/sys/kern/vfs_mount.c:1200
 2nd 0xc6104ad0 devfs (devfs) @ /.../src/sys/ufs/ffs/ffs_vfsops.c:1194
KDB: stack backtrace:
db_trace_self_wrapper(c0c75d72,e6f109ec,c08c1375,c08b20fb,c0c78d15,...)
at db_trace_self_wrapper+0x26
kdb_backtrace(c08b20fb,c0c78d15,c452f638,c452f568,e6f10a48,...) at
kdb_backtrace+0x29
_witness_debugger(c0c78d15,c6104ad0,c0c674f6,c452f568,c0c99f1f,...) at
_witness_debugger+0x25
witness_checkorder(c6104ad0,9,c0c99f1f,4aa,c6104aec,...) at
witness_checkorder+0x839
__lockmgr_args(c6104ad0,80400,c6104aec,0,0,...) at __lockmgr_args+0x7a7
vop_stdlock(e6f10b50,556,e6f10b48,80400,c6104a78,...) at vop_stdlock+0x62
VOP_LOCK1_APV(c0d55960,e6f10b50,c6104b84,c0d92fe0,c6104a78,...) at
VOP_LOCK1_APV+0xb5
_vn_lock(c6104a78,80400,c0c99f1f,4aa,c592a000,...) at _vn_lock+0x5e
ffs_flushfiles(c6112a10,0,c5dbe900,556,3,...) at ffs_flushfiles+0xa7
softdep_flushfiles(c6112a10,0,c5dbe900,c0911420,c60feb84,...) at
softdep_flushfiles+0x2e
ffs_unmount(c6112a10,8000000,c0c7fa06,4f5,80,...) at ffs_unmount+0x149
dounmount(c6112a10,8000000,c5dbe900,47a,398190a5,...) at dounmount+0x46d
unmount(c5dbe900,e6f10cf8,8,c5dbe900,c0d58f08,...) at unmount+0x2ff
syscall(e6f10d38) at syscall+0x2a3
Xint0x80_syscall() at Xint0x80_syscall+0x20
--- syscall (22, FreeBSD ELF32, unmount), eip = 0x280d9c2f, esp =
0xbfbfe58c, ebp = 0xbfbfe658 ---
From grarpamp at gmail.com  Wed Sep  2 04:26:59 2009
From: grarpamp at gmail.com (grarpamp)
Date: Wed Sep  2 04:34:00 2009
Subject: LOR RELENG_8 unlink/dirhash
Message-ID: <d2e731a10909012126w6491160dhb7875b7e6c110c3c@mail.gmail.com>

Two more...

lock order reversal:
 1st 0xd85c60e0 bufwait (bufwait) @ /.../src/sys/kern/vfs_bio.c:2559
 2nd 0xc8553800 dirhash (dirhash) @ /.../src/sys/ufs/ufs/ufs_dirhash.c:285
KDB: stack backtrace:
db_trace_self_wrapper(c0c75d72,e6f59a74,c08c1375,c08b20fb,c0c78d15,...)
at db_trace_self_wrapper+0x26
kdb_backtrace(c08b20fb,c0c78d15,c452bfc8,c452f6a0,e6f59ad0,...) at
kdb_backtrace+0x29
_witness_debugger(c0c78d15,c8553800,c0c9aa71,c452f6a0,c0c9a6fa,...) at
_witness_debugger+0x25
witness_checkorder(c8553800,9,c0c9a6fa,11d,0,...) at witness_checkorder+0x839
_sx_xlock(c8553800,0,c0c9a6fa,11d,db205018,...) at _sx_xlock+0x85
ufsdirhash_acquire(0,e,c4756800,d85c6080,db205018,...) at
ufsdirhash_acquire+0x35
ufsdirhash_remove(c6ef7a6c,db205018,18,e6f59b60,e6f59b5c,...) at
ufsdirhash_remove+0x14
ufs_dirremove(ccbb0324,c6ef7bc8,500800c,0,ccbb0324,...) at ufs_dirremove+0xe5
ufs_remove(e6f59c34,0,0,0,cb198218,...) at ufs_remove+0x6e
VOP_REMOVE_APV(c0d7a580,e6f59c34,cb198218,e6f59c0c,28216238,...) at
VOP_REMOVE_APV+0xa5
kern_unlinkat(c636db40,ffffff9c,28216238,0,e6f59c80,...) at kern_unlinkat+0x181
kern_unlink(c636db40,28216238,0,e6f59d2c,c0bb0a63,...) at kern_unlink+0x27
unlink(c636db40,e6f59cf8,4,c0c94eac,c0d58db8,...) at unlink+0x22
syscall(e6f59d38) at syscall+0x2a3
Xint0x80_syscall() at Xint0x80_syscall+0x20
--- syscall (10, FreeBSD ELF32, unlink), eip = 0x28168e7f, esp =
0xbfbfea4c, ebp = 0xbfbfea78 ---

lock order reversal:
 1st 0xd84e6460 bufwait (bufwait) @ /.../src/sys/kern/vfs_bio.c:2559
 2nd 0xc4a4f200 dirhash (dirhash) @ /.../src/sys/ufs/ufs/ufs_dirhash.c:285
KDB: stack backtrace:
db_trace_self_wrapper(c0c75d72,e6f13a74,c08c1365,c08b20eb,c0c78d15,...)
at db_trace_self_wrapper+0x26
kdb_backtrace(c08b20eb,c0c78d15,c452bfc8,c452f6a0,e6f13ad0,...) at
kdb_backtrace+0x29
_witness_debugger(c0c78d15,c4a4f200,c0c9aa71,c452f6a0,c0c9a6fa,...) at
_witness_debugger+0x25
witness_checkorder(c4a4f200,9,c0c9a6fa,11d,0,...) at witness_checkorder+0x839
_sx_xlock(c4a4f200,0,c0c9a6fa,11d,d874d6ec,...) at _sx_xlock+0x85
ufsdirhash_acquire(0,e,c4756800,d84e6400,d874d6ec,...) at
ufsdirhash_acquire+0x35
ufsdirhash_remove(c4aacd24,d874d6ec,6ec,e6f13b60,e6f13b5c,...) at
ufsdirhash_remove+0x14
ufs_dirremove(c483e648,c4ae9910,500800c,0,c483e648,...) at ufs_dirremove+0xe5
ufs_remove(e6f13c34,0,0,0,c4ae1b84,...) at ufs_remove+0x6e
VOP_REMOVE_APV(c0d7a580,e6f13c34,c4ae1b84,e6f13c0c,804c2e8,...) at
VOP_REMOVE_APV+0xa5
kern_unlinkat(c5fc76c0,ffffff9c,804c2e8,0,e6f13c80,...) at kern_unlinkat+0x181
kern_unlink(c5fc76c0,804c2e8,0,e6f13d2c,c0bb0a53,...) at kern_unlink+0x27
unlink(c5fc76c0,e6f13cf8,4,c0c599ce,c0d58db8,...) at unlink+0x22
syscall(e6f13d38) at syscall+0x2a3
Xint0x80_syscall() at Xint0x80_syscall+0x20
--- syscall (10, FreeBSD ELF32, unlink), eip = 0x28169dbf, esp =
0xbfbfe64c, ebp = 0xbfbfe6b8 ---
From ache at nagual.pp.ru  Wed Sep  2 05:01:03 2009
From: ache at nagual.pp.ru (Andrey Chernov)
Date: Wed Sep  2 05:01:11 2009
Subject: ee(1): blinking characters
In-Reply-To: <20090825032223.4a788a61@baby-jane.lamaiziere.net>
References: <20090825032223.4a788a61@baby-jane.lamaiziere.net>
Message-ID: <20090902044630.GA14940@nagual.pp.ru>

On Tue, Aug 25, 2009 at 03:22:23AM +0200, Patrick Lamaiziere wrote:
> Hi,
> 
> I've just noticed that ee displays some french characters (like
> '?','?',...) in reverse video into xterm. And on the console theses
> characters are blinking. No problem on the command line or with nvi.

Fixed in r196750

-- 
http://ache.pp.ru/
From kientzle at freebsd.org  Wed Sep  2 05:11:16 2009
From: kientzle at freebsd.org (Tim Kientzle)
Date: Wed Sep  2 05:11:23 2009
Subject: man and UTF-8 locales
In-Reply-To: <20090901210803.GF2829@hoeg.nl>
References: <01895862@bb.ipt.ru> <20090901210803.GF2829@hoeg.nl>
Message-ID: <4A9DF600.5090008@freebsd.org>

Ed Schouten wrote:
> 
> I'm also a bit puzzled by the nm(1) manpage. It uses U+23AA (CURLY
> BRACKET EXTENSION) for the |-characters in the SYNOPSIS section. Is this
> character really meant to be used this way?

That's just wrong.  The bracket extension characters are
meant to be used in building large-sized brackets and should
never be used by themselves.

Personally, I would stick with U+007C here.

Tim

From spambox at haruhiism.net  Wed Sep  2 05:58:38 2009
From: spambox at haruhiism.net (Kamigishi Rei)
Date: Wed Sep  2 05:58:46 2009
Subject: LOR RELENG_8 unlink/dirhash
In-Reply-To: <d2e731a10909012126w6491160dhb7875b7e6c110c3c@mail.gmail.com>
References: <d2e731a10909012126w6491160dhb7875b7e6c110c3c@mail.gmail.com>
Message-ID: <4A9E099B.50602@haruhiism.net>

grarpamp wrote:
> Two more...
>
> lock order reversal:
>  1st 0xd85c60e0 bufwait (bufwait) @ /.../src/sys/kern/vfs_bio.c:2559
>  2nd 0xc8553800 dirhash (dirhash) @ /.../src/sys/ufs/ufs/ufs_dirhash.c:285
>
> lock order reversal:
>  1st 0xd84e6460 bufwait (bufwait) @ /.../src/sys/kern/vfs_bio.c:2559
>  2nd 0xc4a4f200 dirhash (dirhash) @ /.../src/sys/ufs/ufs/ufs_dirhash.c:28
http://sources.zabbadoz.net/freebsd/lor/261.html

--
Kamigishi Rei
KREI-RIPE
From spambox at haruhiism.net  Wed Sep  2 06:00:35 2009
From: spambox at haruhiism.net (Kamigishi Rei)
Date: Wed Sep  2 06:00:42 2009
Subject: LOR RELENG_8 umount
In-Reply-To: <d2e731a10909012004n3deca615yffb62a54666eb385@mail.gmail.com>
References: <d2e731a10909012004n3deca615yffb62a54666eb385@mail.gmail.com>
Message-ID: <4A9E0A16.8070706@haruhiism.net>

grarpamp wrote:
> FYI... seems to happen now and then, haven't narrowed further.
>
> lock order reversal:
>  1st 0xc51036a0 ufs (ufs) @ /.../src/sys/kern/vfs_mount.c:1200
>  2nd 0xc6104ad0 devfs (devfs) @ /.../src/sys/ufs/ffs/ffs_vfsops.c:119
This is a known LOR. http://sources.zabbadoz.net/freebsd/lor/276.html

--
Kamigishi Rei
KREI-RIPE
From hselasky at c2i.net  Wed Sep  2 06:42:08 2009
From: hselasky at c2i.net (Hans Petter Selasky)
Date: Wed Sep  2 06:42:15 2009
Subject: My USB audio test setups and about FreeBSD and me
In-Reply-To: <20090902013536.GA44206@cuba.calyx.nl>
References: <20090901201346.GA2432@cuba.calyx.nl>
	<200909012341.08458.hselasky@c2i.net>
	<20090902013536.GA44206@cuba.calyx.nl>
Message-ID: <200909020842.27496.hselasky@c2i.net>

Hi,

On Wednesday 02 September 2009 03:35:36 Bill Squire 
{billsf} wrote:

>Litterly I've made millions of Euros with 'free' software. 
Every
>bit gets committed except for unimportant parts.

You know that the new USB stack in FreeBSD-8+9 also 
supports device side mode? So you could implement a 
complete USB audio device using a DAC+ADC+CPU and FreeBSD 
only. And if you want to have paid support transforming the 
USB stack into the kilobytes for small CPUs you can get 
that aswell.

> Nice to have decent music again. So many thanks.
>

Sure.

> Bill Squire
>
> The attachment is as labeled. If you use Windows you may 
still be taking a
> chance as the camera is msdosfs based and there are 
'chippers' out there.

Looks fine over here ... Interesting project.

--HPS

From hrs at FreeBSD.org  Wed Sep  2 07:00:51 2009
From: hrs at FreeBSD.org (Hiroki Sato)
Date: Wed Sep  2 07:01:05 2009
Subject: IPv6 regression on 8.x
In-Reply-To: <B583FBF374231F4A89607B4D08578A43052EEDE6@bcs-mail03.internal.cacheflow.com>
References: <B583FBF374231F4A89607B4D08578A43052776D0@bcs-mail03.internal.cacheflow.com>
	<20090830.024420.174808572.hrs@allbsd.org>
	<B583FBF374231F4A89607B4D08578A43052EEDE6@bcs-mail03.internal.cacheflow.com>
Message-ID: <20090902.155958.08019398.hrs@allbsd.org>

"Li, Qing" <qing.li@bluecoat.com> wrote
  in <B583FBF374231F4A89607B4D08578A43052EEDE6@bcs-mail03.internal.cacheflow.com>:

qi> Hi Hiroki,
qi>
qi> >
qi> >  2) Issue of subnet-router anycast address with a global address
qi> >
qi> >  Thanks for the fixes!  With the two patches 1) and 3) are gone, but
qi> >  2) still remains.  Is there something I can help to narrow down it?
qi> >
qi>
qi> Hmm... I tried multiple test cases and all seem to work as expected.
qi> I also tried the exact configuration sequence as you outlined in your
qi> original bug report email, and that case worked, too.
qi>
qi> The only difference I can see from the given information, is I have
qi> 3 em interfaces, whereas you have 2 em interfaces and 1 re, but I
qi> don't see how that would make a difference.

 I think reproduction of the case 2) needs two boxes.  One has two
 NICs and another has one NIC, and the three NICs are connected with a
 subnet independent from each other.

 Anyway, I will try the a-box-with-three-NICs case when I return home
 today.  I didn't try it.

qi> Would it be possible for you to email me your system configuration
qi> produced from "ifconfig" and "netstat" privately ?

 Sure.  I will send them to you later.

-- Hiroki
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20090902/b7ea69ce/attachment.pgp
From marck at rinet.ru  Wed Sep  2 07:54:49 2009
From: marck at rinet.ru (Dmitry Morozovsky)
Date: Wed Sep  2 07:54:57 2009
Subject: Dumb SVN question: update between branches
Message-ID: <alpine.BSF.2.00.0909021134080.10335@woozle.rinet.ru>

Dear colleagues,

I've found myself bumping against the wall with very stupid thing, quick 
googling did not help:

what is SVN's analog of 'cvs update -r BRANCH' (in FreeBSD repo's case)?


Example: in CVS case

--
marck@revamp:/usr/src> cvs -R st Makefile
===================================================================
File: Makefile         	Status: Up-to-date

   Working revision:	1.341.2.7	Thu Mar 19 20:48:18 2009
   Repository revision:	1.341.2.7	/home/ncvs/src/Makefile,v
   Sticky Tag:		RELENG_7 (branch: 1.341.2)
   Sticky Date:		(none)
   Sticky Options:	(none)

marck@revamp:/usr/src> cvs -R up -r RELENG_8
[snip]
marck@revamp:/usr/src> cvs -R st Makefile
===================================================================
File: Makefile         	Status: Up-to-date

   Working revision:	1.358.2.1	Wed Sep  2 07:37:32 2009
   Repository revision:	1.358.2.1	/home/ncvs/src/Makefile,v
   Sticky Tag:		RELENG_8 (branch: 1.358.2)
   Sticky Date:		(none)
   Sticky Options:	(none)

--

In SVN case I have:

marck@hamster:/usr/src> svn info
Path: .
URL: file:///FreeBSD/svn/base/head
Repository Root: file:///FreeBSD/svn/base
Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f
Revision: 196740
Node Kind: directory
Schedule: normal
Last Changed Author: trasz
Last Changed Rev: 196740
Last Changed Date: 2009-09-01 22:30:17 +0400 (Tue, 01 Sep 2009)

what in this case I should do to have stable/8 (retaining my local changes, 
otherwise I'd just blow the whole tree up and re-checkout it). Sure I can store 
`svn diff' output, checkout fresh tree and try to apply diff there, but this 
way does not seem natural to me.

Any hints? Thanks!


-- 
Sincerely,
D.Marck                                     [DM5020, MCK-RIPE, DM3-RIPN]
[ FreeBSD committer:                                 marck@FreeBSD.org ]
------------------------------------------------------------------------
*** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- marck@rinet.ru ***
------------------------------------------------------------------------
From ari at ish.com.au  Wed Sep  2 08:23:06 2009
From: ari at ish.com.au (Aristedes Maniatis)
Date: Wed Sep  2 08:23:14 2009
Subject: Dumb SVN question: update between branches
In-Reply-To: <alpine.BSF.2.00.0909021134080.10335@woozle.rinet.ru>
References: <alpine.BSF.2.00.0909021134080.10335@woozle.rinet.ru>
Message-ID: <4A9E28BF.7080007@ish.com.au>

On 2/09/09 5:41 PM, Dmitry Morozovsky wrote:
> what in this case I should do to have stable/8 (retaining my local changes,
> otherwise I'd just blow the whole tree up and re-checkout it). Sure I can store
> `svn diff' output, checkout fresh tree and try to apply diff there, but this
> way does not seem natural to me.

"svn switch" will do what you want. I find it helpful to create a patch as backup first just in case something goes wrong.

Ari


-------------------------->
ish
http://www.ish.com.au
Level 1, 30 Wilson Street Newtown 2042 Australia
phone +61 2 9550 5001   fax +61 2 9550 4001
GPG fingerprint CBFB 84B4 738D 4E87 5E5C  5EFA EF6A 7D2E 3E49 102A
From marck at rinet.ru  Wed Sep  2 08:41:23 2009
From: marck at rinet.ru (Dmitry Morozovsky)
Date: Wed Sep  2 08:41:30 2009
Subject: Dumb SVN question: update between branches
In-Reply-To: <4A9E28BF.7080007@ish.com.au>
References: <alpine.BSF.2.00.0909021134080.10335@woozle.rinet.ru>
	<4A9E28BF.7080007@ish.com.au>
Message-ID: <alpine.BSF.2.00.0909021240340.10335@woozle.rinet.ru>

On Wed, 2 Sep 2009, Aristedes Maniatis wrote:

AM> On 2/09/09 5:41 PM, Dmitry Morozovsky wrote:
AM> > what in this case I should do to have stable/8 (retaining my local
AM> > changes,
AM> > otherwise I'd just blow the whole tree up and re-checkout it). Sure I can
AM> > store
AM> > `svn diff' output, checkout fresh tree and try to apply diff there, but
AM> > this
AM> > way does not seem natural to me.
AM> 
AM> "svn switch" will do what you want. I find it helpful to create a patch as
AM> backup first just in case something goes wrong.

Ah thanks a lot.  I somehow overlooked this simple and straightforward way 
;-)

-- 
Sincerely,
D.Marck                                     [DM5020, MCK-RIPE, DM3-RIPN]
[ FreeBSD committer:                                 marck@FreeBSD.org ]
------------------------------------------------------------------------
*** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- marck@rinet.ru ***
------------------------------------------------------------------------
From ubm.freebsd at googlemail.com  Wed Sep  2 05:47:06 2009
From: ubm.freebsd at googlemail.com (Marc UBM Bocklet)
Date: Wed Sep  2 11:05:46 2009
Subject: panic: apic_free_vector: Thread already bound.
In-Reply-To: <200909010955.33747.jhb@freebsd.org>
References: <20090822115958.f93fcf29.ubm.freebsd@gmail.com>
	<20090831222650.45b6c806.ubm@u-boot-man.de>
	<3bbf2fe10908311331k3e871898tc36a9846651cc53@mail.gmail.com>
	<200909010955.33747.jhb@freebsd.org>
Message-ID: <20090902074701.9a063349.ubm.freebsd@gmail.com>

On Tue, 1 Sep 2009 09:55:33 -0400
John Baldwin <jhb@freebsd.org> wrote:


> > Maybe we can ship 8 with a printf() instrad than a panic()?
> 
> Actually, it looks like 'rebooting' is what we want.  Try this:
> 
> --- //depot/vendor/freebsd/src/sys/amd64/amd64/local_apic.c
> 2009/08/14 21:10:13 ++
> + //depot/user/jhb/acpipci/amd64/amd64/local_apic.c	2009/09/01
> 13:54:23 @@ -990,18 +990,21 @@
>  	 * we don't lose an interrupt delivery race.
>  	 */
>  	td = curthread;
> -	thread_lock(td);
> -	if (sched_is_bound(td))
> -		panic("apic_free_vector: Thread already bound.\n");
> -	sched_bind(td, apic_cpuid(apic_id));
> -	thread_unlock(td);
> +	if (!rebooting) {
> +		thread_lock(td);
> +		if (sched_is_bound(td))
> +			panic("apic_free_vector: Thread already
> bound.\n");
> +		sched_bind(td, apic_cpuid(apic_id));
> +		thread_unlock(td);
> +	}
>  	mtx_lock_spin(&icu_lock);
>  	lapics[apic_id].la_ioint_irqs[vector - APIC_IO_INTS] = -1;
>  	mtx_unlock_spin(&icu_lock);
> -	thread_lock(td);
> -	sched_unbind(td);
> -	thread_unlock(td);
> -
> +	if (!rebooting) {
> +		thread_lock(td);
> +		sched_unbind(td);
> +		thread_unlock(td);
> +	}
>  }
>  
>  /* Map an IDT vector (APIC) to an IRQ (interrupt source). */
> --- //depot/vendor/freebsd/src/sys/i386/i386/local_apic.c
> 2009/08/14 21:10:13 ++
> + //depot/user/jhb/acpipci/i386/i386/local_apic.c	2009/09/01
> 13:53:14 @@ -994,18 +994,21 @@
>  	 * we don't lose an interrupt delivery race.
>  	 */
>  	td = curthread;
> -	thread_lock(td);
> -	if (sched_is_bound(td))
> -		panic("apic_free_vector: Thread already bound.\n");
> -	sched_bind(td, apic_cpuid(apic_id));
> -	thread_unlock(td);
> +	if (!rebooting) {
> +		thread_lock(td);
> +		if (sched_is_bound(td))
> +			panic("apic_free_vector: Thread already
> bound.\n");
> +		sched_bind(td, apic_cpuid(apic_id));
> +		thread_unlock(td);
> +	}
>  	mtx_lock_spin(&icu_lock);
>  	lapics[apic_id].la_ioint_irqs[vector - APIC_IO_INTS] = -1;
>  	mtx_unlock_spin(&icu_lock);
> -	thread_lock(td);
> -	sched_unbind(td);
> -	thread_unlock(td);
> -
> +	if (!rebooting) {
> +		thread_lock(td);
> +		sched_unbind(td);
> +		thread_unlock(td);
> +	}
>  }
>  
>  /* Map an IDT vector (APIC) to an IRQ (interrupt source). */

I can confirm that this fixes the issue for me.

Thanks a lot! :-)

Bye
Marc
From nick-lists at netability.ie  Wed Sep  2 11:56:07 2009
From: nick-lists at netability.ie (Nick Hilliard)
Date: Wed Sep  2 11:56:15 2009
Subject: 8.0-beta3 does not detect several ata channels
In-Reply-To: <200909011002.59592.jhb@freebsd.org>
References: <4A9BF23F.6070801@netability.ie> <4A9BF438.1000006@smeets.im>
	<200909011002.59592.jhb@freebsd.org>
Message-ID: <4A9E5D4B.1020801@netability.ie>

On 01/09/2009 15:02, John Baldwin wrote:
> Hmm, so an idea I had just now.. can you grab a dump of the PCI config space
> for the disk controller in the MCFG vs non-MCFG cases?  That is, find the
> device's address using pciconf -lv (e.g. pci0:0:30:0 or some such) and then
> run this command under both configurations and save the output:

hmmm, the box won't boot when i use mcfg=1.  I'll take a look at the 
console message tomorrow or friday.

Nick
From 482254ac at razorfever.net  Wed Sep  2 12:03:41 2009
From: 482254ac at razorfever.net (Derek (freebsd lists))
Date: Wed Sep  2 12:03:48 2009
Subject: siis/atacam/ata/gmirror 8.0-BETA3 disk performance
Message-ID: <4A9E5F34.2090700@razorfever.net>

Hi,

I've been testing the new siis driver, and I have found no
appreciable performance change, using dd as a measure of "raw"
performance.

I get about 40MB/s read, and 30MB/s write.  See attached
bench-*.txt files.

Am I expecting too much, or do I have something else going on
here?  (e.g. dd being a terrible benchmark of disk i/o)

Is anyone else seeing better/worse/same numbers?

Also I find it surprising that my gmirror read is only 40MB/s,
and not 60-80MB/s, any thoughts on this?

Thanks!
- Derek




-------------- next part --------------
dd if=/dev/zero of=/dev/null bs=1M count=128
128+0 records in
128+0 records out
134217728 bytes transferred in 0.437049 secs (307099849 bytes/sec)

dd if=/dev/zero of=/dev/ad4p2 bs=1M count=128
128+0 records in
128+0 records out
134217728 bytes transferred in 4.410338 secs (30432527 bytes/sec)

dd if=/dev/zero of=/dev/ad6p2 bs=1M count=128
128+0 records in
128+0 records out
134217728 bytes transferred in 4.401181 secs (30495844 bytes/sec)

dd if=/dev/ad6p2 of=/dev/null bs=1M count=128
128+0 records in
128+0 records out
134217728 bytes transferred in 3.234643 secs (41493831 bytes/sec)

dd if=/dev/ad4p2 of=/dev/null bs=1M count=128
128+0 records in
128+0 records out
134217728 bytes transferred in 3.689668 secs (41385739 bytes/sec)

gmirror label gm0p2 ad4p2 ad6p2
dd if=/dev/mirror/gm0p2 of=/dev/null bs=1M count=128
128+0 records in
128+0 records out
134217728 bytes transferred in 3.331307 secs (40289811 bytes/sec)

dd if=/dev/zero of=/dev/mirror/gm0p2 bs=1M count=128
128+0 records in
128+0 records out
134217728 bytes transferred in 8.167607 secs (16432932 bytes/sec)

-------------- next part --------------
dd if=/dev/zero of=/dev/null bs=1M count=128
128+0 records in
128+0 records out
134217728 bytes transferred in 0.434279 secs (309058782 bytes/sec)

dd if=/dev/zero of=/dev/ada0p2 bs=1M count=128
128+0 records in
128+0 records out
134217728 bytes transferred in 4.604623 secs (29148472 bytes/sec)

dd if=/dev/zero of=/dev/ada1p2 bs=1M count=128
128+0 records in
128+0 records out
134217728 bytes transferred in 4.402896 secs (30483966 bytes/sec)

dd if=/dev/ada1p2 of=/dev/null bs=1M count=128
128+0 records in
128+0 records out
134217728 bytes transferred in 3.203470 secs (41897607 bytes/sec)

dd if=/dev/ada0p2 of=/dev/null bs=1M count=128
128+0 records in
128+0 records out
134217728 bytes transferred in 3.211751 secs (41789581 bytes/sec)

gmirror label gm0p2 ada0p2 ada1p2
dd if=/dev/mirror/gm0p2 of=/dev/null bs=1M count=128
128+0 records in
128+0 records out
134217728 bytes transferred in 3.349089 secs (40075890 bytes/sec)

dd if=/dev/zero of=/dev/mirror/gm0p2 bs=1M count=128
128+0 records in
128+0 records out
134217728 bytes transferred in 8.121042 secs (16527156 bytes/sec)

-------------- next part --------------
Copyright (c) 1992-2009 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
	The Regents of the University of California. All rights reserved.
FreeBSD is a registered trademark of The FreeBSD Foundation.
FreeBSD 8.0-BETA3 #1: Tue Sep  1 15:24:09 EDT 2009
    root@porter.razorfever.net:/usr/obj/usr/src/sys/ZFS-PROD
Timecounter "i8254" frequency 1193182 Hz quality 0
CPU: Intel(R) Pentium(R) III CPU family      1400MHz (1399.54-MHz 686-class CPU)
  Origin = "GenuineIntel"  Id = 0x6b1  Stepping = 1
  Features=0x383fbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR,SSE>
real memory  = 2147483648 (2048 MB)
avail memory = 2083577856 (1987 MB)
ACPI APIC Table: <VIA694 AWRDACPI>
FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs
FreeBSD/SMP: 2 package(s) x 1 core(s)
 cpu0 (BSP): APIC ID:  0
 cpu1 (AP): APIC ID:  1
ioapic0 <Version 1.1> irqs 0-23 on motherboard
kbd1 at kbdmux0
acpi0: <VIA694 AWRDACPI> on motherboard
acpi0: [ITHREAD]
acpi0: Power Button (fixed)
acpi0: reservation of 0, a0000 (3) failed
acpi0: reservation of 100000, 7fef0000 (3) failed
Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000
acpi_timer0: <24-bit timer at 3.579545MHz> port 0x4008-0x400b on acpi0
acpi_button0: <Power Button> on acpi0
pcib0: <ACPI Host-PCI bridge> port 0xcf8-0xcff,0x4000-0x407f,0x4080-0x40ff,0x5000-0x500f,0x6000-0x607f on acpi0
pci0: <ACPI PCI bus> on pcib0
agp0: <VIA 82C691 (Apollo Pro) host to PCI bridge> on hostb0
agp0: aperture size is 228M
pcib1: <PCI-PCI bridge> at device 1.0 on pci0
pci1: <PCI bus> on pcib1
vgapci0: <VGA-compatible display> port 0x9000-0x90ff mem 0xfa000000-0xfaffffff,0xf9000000-0xf9000fff at device 0.0 on pci1
isab0: <PCI-ISA bridge> at device 7.0 on pci0
isa0: <ISA bus> on isab0
atapci0: <VIA 82C686B UDMA100 controller> port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xa000-0xa00f at device 7.1 on pci0
ata0: <ATA channel 0> on atapci0
ata0: [ITHREAD]
ata1: <ATA channel 1> on atapci0
ata1: [ITHREAD]
uhci0: <VIA 83C572 USB controller> port 0xa400-0xa41f irq 5 at device 7.2 on pci0
uhci0: [ITHREAD]
usbus0: <VIA 83C572 USB controller> on uhci0
uhci1: <VIA 83C572 USB controller> port 0xa800-0xa81f irq 5 at device 7.3 on pci0
uhci1: [ITHREAD]
usbus1: <VIA 83C572 USB controller> on uhci1
pci0: <bridge> at device 7.4 (no driver attached)
siis0: <SiI3124 SATA2 controller> port 0xb800-0xb80f mem 0xfc448000-0xfc44807f,0xfc440000-0xfc447fff irq 17 at device 8.0 on pci0
siis0: [ITHREAD]
siisch0: <SIIS channel> at channel 0 on siis0
siisch0: [ITHREAD]
siisch1: <SIIS channel> at channel 1 on siis0
siisch1: [ITHREAD]
siisch2: <SIIS channel> at channel 2 on siis0
siisch2: [ITHREAD]
siisch3: <SIIS channel> at channel 3 on siis0
siisch3: [ITHREAD]
fxp0: <Intel 82550 Pro/100 Ethernet> port 0xbc00-0xbc3f mem 0xfc44a000-0xfc44afff,0xfc400000-0xfc41ffff irq 19 at device 10.0 on pci0
miibus0: <MII bus> on fxp0
inphy0: <i82555 10/100 media interface> PHY 1 on miibus0
inphy0:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
fxp0: Ethernet address: 00:02:b3:31:f2:ec
fxp0: [ITHREAD]
fxp1: <Intel 82550 Pro/100 Ethernet> port 0xc000-0xc03f mem 0xfc449000-0xfc449fff,0xfc420000-0xfc43ffff irq 16 at device 11.0 on pci0
miibus1: <MII bus> on fxp1
inphy1: <i82555 10/100 media interface> PHY 1 on miibus1
inphy1:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
fxp1: Ethernet address: 00:02:b3:22:a9:ca
fxp1: [ITHREAD]
uhci2: <VIA 83C572 USB controller> port 0xc400-0xc41f irq 17 at device 12.0 on pci0
uhci2: [ITHREAD]
usbus2: <VIA 83C572 USB controller> on uhci2
uhci3: <VIA 83C572 USB controller> port 0xc800-0xc81f irq 18 at device 12.1 on pci0
uhci3: [ITHREAD]
usbus3: <VIA 83C572 USB controller> on uhci3
ehci0: <VIA VT6202 USB 2.0 controller> mem 0xfc44b000-0xfc44b0ff irq 19 at device 12.2 on pci0
ehci0: [ITHREAD]
usbus4: EHCI version 1.0
usbus4: <VIA VT6202 USB 2.0 controller> on ehci0
fwohci0: <VIA Fire II (VT6306)> port 0xcc00-0xcc7f mem 0xfc44c000-0xfc44c7ff irq 17 at device 12.3 on pci0
fwohci0: [ITHREAD]
fwohci0: OHCI version 1.0 (ROM=1)
fwohci0: No. of Isochronous channels is 4.
fwohci0: EUI64 00:11:06:00:00:00:e3:32
fwohci0: Phy 1394a available S400, 3 ports.
fwohci0: Link S100, max_rec 2 bytes.
fwohci0: max_rec 2 -> 2048
firewire0: <IEEE1394(FireWire) bus> on fwohci0
dcons_crom0: <dcons configuration ROM> on firewire0
dcons_crom0: bus_addr 0x157c000
fwe0: <Ethernet over FireWire> on firewire0
if_fwe0: Fake Ethernet address: 02:11:06:00:e3:32
fwe0: Ethernet address: 02:11:06:00:e3:32
fwip0: <IP over FireWire> on firewire0
fwip0: Firewire address: 00:11:06:00:00:00:e3:32 @ 0xfffe00000000, S400, maxrec 2048
sbp0: <SBP-2/SCSI over FireWire> on firewire0
fwohci0: Initiate bus reset
fwohci0: fwohci_intr_core: BUS reset
fwohci0: fwohci_intr_core: node_id=0x00000000, SelfID Count=1, CYCLEMASTER mode
atrtc0: <AT realtime clock> port 0x70-0x73 irq 8 on acpi0
fdc0: <floppy drive controller> port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on acpi0
fdc0: [FILTER]
uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0
uart0: [FILTER]
uart1: <16550 or compatible> port 0x2f8-0x2ff irq 3 on acpi0
uart1: [FILTER]
ppc0: <Parallel port> port 0x378-0x37f irq 7 on acpi0
ppc0: Generic chipset (EPP/NIBBLE) in COMPATIBLE mode
ppc0: [ITHREAD]
ppbus0: <Parallel port bus> on ppc0
plip0: <PLIP network interface> on ppbus0
plip0: [ITHREAD]
lpt0: <Printer> on ppbus0
lpt0: [ITHREAD]
lpt0: Interrupt-driven port
ppi0: <Parallel I/O> on ppbus0
atkbdc0: <Keyboard controller (i8042)> port 0x60,0x64 irq 1 on acpi0
atkbd0: <AT Keyboard> irq 1 on atkbdc0
kbd0 at atkbd0
atkbd0: [GIANT-LOCKED]
atkbd0: [ITHREAD]
psm0: <PS/2 Mouse> irq 12 on atkbdc0
psm0: [GIANT-LOCKED]
psm0: [ITHREAD]
psm0: model IntelliMouse Explorer, device ID 4
cpu0: <ACPI CPU> on acpi0
cpu1: <ACPI CPU> on acpi0
pmtimer0 on isa0
orm0: <ISA Option ROMs> at iomem 0xc0000-0xc7fff,0xc8000-0xcc7ff,0xcd000-0xce7ff,0xcf000-0xd07ff pnpid ORM0000 on isa0
sc0: <System console> at flags 0x100 on isa0
sc0: VGA <16 virtual consoles, flags=0x300>
vga0: <Generic ISA VGA> at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0
WARNING: ZFS is considered to be an experimental feature in FreeBSD.
ZFS NOTICE: prefetch is disabled by default on i386 - add enable to tunable to change.
ZFS filesystem version 13
ZFS storage pool version 13
Timecounters tick every 1.000 msec
firewire0: 1 nodes, maxhop <= 0 cable IRM irm(0)  (me) 
firewire0: bus manager 0 
Waiting 5 seconds for SCSI devices to settle
usbus0: 12Mbps Full Speed USB v1.0
usbus1: 12Mbps Full Speed USB v1.0
usbus2: 12Mbps Full Speed USB v1.0
usbus3: 12Mbps Full Speed USB v1.0
usbus4: 480Mbps High Speed USB v2.0
ugen0.1: <VIA> at usbus0
uhub0: <VIA UHCI root HUB, class 9/0, rev 1.00/1.00, addr 1> on usbus0
ugen1.1: <VIA> at usbus1
uhub1: <VIA UHCI root HUB, class 9/0, rev 1.00/1.00, addr 1> on usbus1
ugen2.1: <VIA> at usbus2
uhub2: <VIA UHCI root HUB, class 9/0, rev 1.00/1.00, addr 1> on usbus2
ugen3.1: <VIA> at usbus3
uhub3: <VIA UHCI root HUB, class 9/0, rev 1.00/1.00, addr 1> on usbus3
ugen4.1: <VIA> at usbus4
uhub4: <VIA EHCI root HUB, class 9/0, rev 2.00/1.00, addr 1> on usbus4
uhub0: 2 ports with 2 removable, self powered
uhub1: 2 ports with 2 removable, self powered
uhub2: 2 ports with 2 removable, self powered
uhub3: 2 ports with 2 removable, self powered
uhub4: 4 ports with 4 removable, self powered
(aprobe0:siisch0:0:15:0): SIGNATURE: 0000
(aprobe0:siisch0:0:0:0): SIGNATURE: 0000
(aprobe1:siisch1:0:15:0): SIGNATURE: 0000
(aprobe0:siisch1:0:0:0): SIGNATURE: 0000
ada0 at siisch0 bus 0 target 0 lun 0
ada0: <ST31500341AS CC1H> ATA/ATAPI-8 SATA 2.x device
ada0: 300.000MB/s transfers
ada0: 1430799MB (2930277168 512 byte sectors: 16H 63S/T 16383C)
ada0: Native Command Queueing enabled
ada1 at siisch1 bus 0 target 0 lun 0
ada1: <ST31500341AS CC1H> ATA/ATAPI-8 SATA 2.x device
ada1: 300.000MB/s transfers
ada1: 1430799MB (2930277168 512 byte sectors: 16H 63S/T 16383C)
ada1: Native Command Queueing enabled
SMP: AP CPU #1 Launched!
GEOM_MIRROR: Device mirror/gm0p2 launched (2/2).
Trying to mount root from zfs:tank


-------------- next part --------------
ostb0@pci0:0:0:0:	class=0x060000 card=0x00000000 chip=0x06911106 rev=0xc4 hdr=0x00
pcib1@pci0:0:1:0:	class=0x060400 card=0x00000000 chip=0x85981106 rev=0x00 hdr=0x01
isab0@pci0:0:7:0:	class=0x060100 card=0x000010f1 chip=0x06861106 rev=0x40 hdr=0x00
atapci0@pci0:0:7:1:	class=0x01018a card=0x05711106 chip=0x05711106 rev=0x06 hdr=0x00
uhci0@pci0:0:7:2:	class=0x0c0300 card=0x12340925 chip=0x30381106 rev=0x1a hdr=0x00
uhci1@pci0:0:7:3:	class=0x0c0300 card=0x12340925 chip=0x30381106 rev=0x1a hdr=0x00
none0@pci0:0:7:4:	class=0x068000 card=0x30571106 chip=0x30571106 rev=0x40 hdr=0x00
siis0@pci0:0:8:0:	class=0x018000 card=0x31241095 chip=0x31241095 rev=0x02 hdr=0x00
fxp0@pci0:0:10:0:	class=0x020000 card=0x00408086 chip=0x12298086 rev=0x0c hdr=0x00
fxp1@pci0:0:11:0:	class=0x020000 card=0x00408086 chip=0x12298086 rev=0x0c hdr=0x00
uhci2@pci0:0:12:0:	class=0x0c0300 card=0x30381106 chip=0x30381106 rev=0x61 hdr=0x00
uhci3@pci0:0:12:1:	class=0x0c0300 card=0x30381106 chip=0x30381106 rev=0x61 hdr=0x00
ehci0@pci0:0:12:2:	class=0x0c0320 card=0x31041106 chip=0x31041106 rev=0x63 hdr=0x00
fwohci0@pci0:0:12:3:	class=0x0c0010 card=0x30441106 chip=0x30441106 rev=0x46 hdr=0x00
vgapci0@pci0:1:0:0:	class=0x030000 card=0x00840000 chip=0x47441002 rev=0x5c hdr=0x00

From jhb at freebsd.org  Wed Sep  2 12:16:56 2009
From: jhb at freebsd.org (John Baldwin)
Date: Wed Sep  2 12:17:04 2009
Subject: 8.0-beta3 does not detect several ata channels
In-Reply-To: <4A9D86C9.1020603@gwdg.de>
References: <4A9BF23F.6070801@netability.ie>
	<200909011505.32243.jhb@freebsd.org> <4A9D86C9.1020603@gwdg.de>
Message-ID: <200909011717.57386.jhb@freebsd.org>

On Tuesday 01 September 2009 4:40:41 pm Rainer Hurling wrote:
> On 01.09.2009 21:05 (UTC+2), John Baldwin wrote:
> > On Tuesday 01 September 2009 2:49:09 pm Rainer Hurling wrote:
> >> On 01.09.2009 19:41 (UTC+2), John Baldwin wrote:
> >>> On Tuesday 01 September 2009 12:47:50 pm Rainer Hurling wrote:
> >>>> On 01.09.2009 16:02 (UTC+2), John Baldwin wrote:
> >>>>> On Monday 31 August 2009 12:03:04 pm Florian Smeets wrote:
> >>>>>> On 8/31/09 5:54 PM, Nick Hilliard wrote:
> >>>>>>> Hi,
> >>>>>>>
> >>>>>>> I have a hp proliant ML115 with 6 sata ports which run in ATA mode 
> > (bios
> >>>>>>> doesn't appear to give the option to use AHCI).  On freebsd 7.x, all
> >>>>>>> channels are detected.  On freebsd8.0-beta3, the disks attached to 
the
> >>>>>>> first two SATA ports are not detected, although it detects the ports
> >>>>>>> themselves.
> >>>>>>>
> >>>>>>> I've attached a verbose dmesg from freebsd 7.1 and 8.0-beta3.
> >>>>>>>
> >>>>>>> Any ideas on what's going on here?  This seems like a nasty 
> > regression.
> >>>>>> There are 3 PRs about this problem: 128686, 132372, 137942.
> >>>>>>
> >>>>>> i386 version should recognize the disks. amd64 does when you set
> >>>>>> hw.pci.mcfg=0 in loader.conf.
> >>>>> Hmm, so an idea I had just now.. can you grab a dump of the PCI config 
> >>> space 
> >>>>> for the disk controller in the MCFG vs non-MCFG cases?  That is, find 
> > the 
> >>>>> device's address using pciconf -lv (e.g. pci0:0:30:0 or some such) and 
> >>> then 
> >>>>> run this command under both configurations and save the output:
> >>>>>
> >>>>> pciconf -r pci0:0:30:0 0:0xfc
> >>>>>
> >>>> I am not sure if your idea has something to do with my (and some other 
> >>>> users) problem. So excuse me, if this posting is wrong.
> >>>>
> >>>> For some month now I am only able to boot CURRENT under amd64 with 
> >>>> setting hw.pci.mcfg=0. Under i386 all works fine. Below I listed output 
> >>>> under i386 and under amd64. Perhaps you are able to get a hint?
> >>> Hmm, would you be able to boot with mcfg=1 on amd64 (perhaps using 
nfsroot 
> > or 
> >>> an mfsroot) and capture this output?  The mcfg thing only affects access 
> > to
> >>> PCI config space (what pciconf -r is displaying).  I want to be able to 
> >>> compare the "broken" case (amd64 mcfg=1) with a working case.
> >> My only amd64 system is at home. Sorry, but I have no idea how to start 
> >> this system using nfsroot oder mfsroot.
> > 
> > Ok, I believe some of the other folks reporting an issue with this ATA 
> > controller had other disk controllers in the system so they may be able to 
do 
> > this.
> 
> Thanks to Kostik Belousov, I tried his hint with live CD. Here it is, 
> only for amd64, with snapshot from todays CURRENT:
> 
> #systctl hw.pci.mcfg
> hw.pci.mcfg: 1

Hmm, this one is identical to the mcfg=0 one on amd64 (except for a few values 
that also differ between the working i386 and working amd64).  So it doesn't 
seem that PCI config access is horribly broken. :(  Perhaps someone can spend 
some time comparing what the driver does in the two cases with some printfs 
to see when it starts behaving differently during its attach routine to help 
narrow this down.

-- 
John Baldwin
From mike at sentex.net  Wed Sep  2 12:25:32 2009
From: mike at sentex.net (Mike Tancsa)
Date: Wed Sep  2 12:25:43 2009
Subject: siis/atacam/ata/gmirror 8.0-BETA3 disk performance
In-Reply-To: <4A9E5F34.2090700@razorfever.net>
References: <4A9E5F34.2090700@razorfever.net>
Message-ID: <200909021222.n82CM8Q3020822@lava.sentex.ca>

At 08:04 AM 9/2/2009, Derek (freebsd lists) wrote:
>Hi,
>
>I've been testing the new siis driver, and I have found no
>appreciable performance change, using dd as a measure of "raw"
>performance.

Dont know about raw, but I found some cases where it was faster, 
especially with random I/O.  Havent tried with the recent commits however

         ---Mike

>I get about 40MB/s read, and 30MB/s write.  See attached
>bench-*.txt files.
>
>Am I expecting too much, or do I have something else going on
>here?  (e.g. dd being a terrible benchmark of disk i/o)
>
>Is anyone else seeing better/worse/same numbers?
>
>Also I find it surprising that my gmirror read is only 40MB/s,
>and not 60-80MB/s, any thoughts on this?
>
>Thanks!
>- Derek
>
>
>
>
>
>
>dd if=/dev/zero of=/dev/null bs=1M count=128
>128+0 records in
>128+0 records out
>134217728 bytes transferred in 0.437049 secs (307099849 bytes/sec)
>
>dd if=/dev/zero of=/dev/ad4p2 bs=1M count=128
>128+0 records in
>128+0 records out
>134217728 bytes transferred in 4.410338 secs (30432527 bytes/sec)
>
>dd if=/dev/zero of=/dev/ad6p2 bs=1M count=128
>128+0 records in
>128+0 records out
>134217728 bytes transferred in 4.401181 secs (30495844 bytes/sec)
>
>dd if=/dev/ad6p2 of=/dev/null bs=1M count=128
>128+0 records in
>128+0 records out
>134217728 bytes transferred in 3.234643 secs (41493831 bytes/sec)
>
>dd if=/dev/ad4p2 of=/dev/null bs=1M count=128
>128+0 records in
>128+0 records out
>134217728 bytes transferred in 3.689668 secs (41385739 bytes/sec)
>
>gmirror label gm0p2 ad4p2 ad6p2
>dd if=/dev/mirror/gm0p2 of=/dev/null bs=1M count=128
>128+0 records in
>128+0 records out
>134217728 bytes transferred in 3.331307 secs (40289811 bytes/sec)
>
>dd if=/dev/zero of=/dev/mirror/gm0p2 bs=1M count=128
>128+0 records in
>128+0 records out
>134217728 bytes transferred in 8.167607 secs (16432932 bytes/sec)
>
>
>dd if=/dev/zero of=/dev/null bs=1M count=128
>128+0 records in
>128+0 records out
>134217728 bytes transferred in 0.434279 secs (309058782 bytes/sec)
>
>dd if=/dev/zero of=/dev/ada0p2 bs=1M count=128
>128+0 records in
>128+0 records out
>134217728 bytes transferred in 4.604623 secs (29148472 bytes/sec)
>
>dd if=/dev/zero of=/dev/ada1p2 bs=1M count=128
>128+0 records in
>128+0 records out
>134217728 bytes transferred in 4.402896 secs (30483966 bytes/sec)
>
>dd if=/dev/ada1p2 of=/dev/null bs=1M count=128
>128+0 records in
>128+0 records out
>134217728 bytes transferred in 3.203470 secs (41897607 bytes/sec)
>
>dd if=/dev/ada0p2 of=/dev/null bs=1M count=128
>128+0 records in
>128+0 records out
>134217728 bytes transferred in 3.211751 secs (41789581 bytes/sec)
>
>gmirror label gm0p2 ada0p2 ada1p2
>dd if=/dev/mirror/gm0p2 of=/dev/null bs=1M count=128
>128+0 records in
>128+0 records out
>134217728 bytes transferred in 3.349089 secs (40075890 bytes/sec)
>
>dd if=/dev/zero of=/dev/mirror/gm0p2 bs=1M count=128
>128+0 records in
>128+0 records out
>134217728 bytes transferred in 8.121042 secs (16527156 bytes/sec)
>
>
>Copyright (c) 1992-2009 The FreeBSD Project.
>Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
>         The Regents of the University of California. All rights reserved.
>FreeBSD is a registered trademark of The FreeBSD Foundation.
>FreeBSD 8.0-BETA3 #1: Tue Sep  1 15:24:09 EDT 2009
>     root@porter.razorfever.net:/usr/obj/usr/src/sys/ZFS-PROD
>Timecounter "i8254" frequency 1193182 Hz quality 0
>CPU: Intel(R) Pentium(R) III CPU family      1400MHz (1399.54-MHz 
>686-class CPU)
>   Origin = "GenuineIntel"  Id = 0x6b1  Stepping = 1
> 
>Features=0x383fbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR,SSE>
>real memory  = 2147483648 (2048 MB)
>avail memory = 2083577856 (1987 MB)
>ACPI APIC Table: <VIA694 AWRDACPI>
>FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs
>FreeBSD/SMP: 2 package(s) x 1 core(s)
>  cpu0 (BSP): APIC ID:  0
>  cpu1 (AP): APIC ID:  1
>ioapic0 <Version 1.1> irqs 0-23 on motherboard
>kbd1 at kbdmux0
>acpi0: <VIA694 AWRDACPI> on motherboard
>acpi0: [ITHREAD]
>acpi0: Power Button (fixed)
>acpi0: reservation of 0, a0000 (3) failed
>acpi0: reservation of 100000, 7fef0000 (3) failed
>Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000
>acpi_timer0: <24-bit timer at 3.579545MHz> port 0x4008-0x400b on acpi0
>acpi_button0: <Power Button> on acpi0
>pcib0: <ACPI Host-PCI bridge> port 
>0xcf8-0xcff,0x4000-0x407f,0x4080-0x40ff,0x5000-0x500f,0x6000-0x607f on acpi0
>pci0: <ACPI PCI bus> on pcib0
>agp0: <VIA 82C691 (Apollo Pro) host to PCI bridge> on hostb0
>agp0: aperture size is 228M
>pcib1: <PCI-PCI bridge> at device 1.0 on pci0
>pci1: <PCI bus> on pcib1
>vgapci0: <VGA-compatible display> port 0x9000-0x90ff mem 
>0xfa000000-0xfaffffff,0xf9000000-0xf9000fff at device 0.0 on pci1
>isab0: <PCI-ISA bridge> at device 7.0 on pci0
>isa0: <ISA bus> on isab0
>atapci0: <VIA 82C686B UDMA100 controller> port 
>0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xa000-0xa00f at device 7.1 on pci0
>ata0: <ATA channel 0> on atapci0
>ata0: [ITHREAD]
>ata1: <ATA channel 1> on atapci0
>ata1: [ITHREAD]
>uhci0: <VIA 83C572 USB controller> port 0xa400-0xa41f irq 5 at 
>device 7.2 on pci0
>uhci0: [ITHREAD]
>usbus0: <VIA 83C572 USB controller> on uhci0
>uhci1: <VIA 83C572 USB controller> port 0xa800-0xa81f irq 5 at 
>device 7.3 on pci0
>uhci1: [ITHREAD]
>usbus1: <VIA 83C572 USB controller> on uhci1
>pci0: <bridge> at device 7.4 (no driver attached)
>siis0: <SiI3124 SATA2 controller> port 0xb800-0xb80f mem 
>0xfc448000-0xfc44807f,0xfc440000-0xfc447fff irq 17 at device 8.0 on pci0
>siis0: [ITHREAD]
>siisch0: <SIIS channel> at channel 0 on siis0
>siisch0: [ITHREAD]
>siisch1: <SIIS channel> at channel 1 on siis0
>siisch1: [ITHREAD]
>siisch2: <SIIS channel> at channel 2 on siis0
>siisch2: [ITHREAD]
>siisch3: <SIIS channel> at channel 3 on siis0
>siisch3: [ITHREAD]
>fxp0: <Intel 82550 Pro/100 Ethernet> port 0xbc00-0xbc3f mem 
>0xfc44a000-0xfc44afff,0xfc400000-0xfc41ffff irq 19 at device 10.0 on pci0
>miibus0: <MII bus> on fxp0
>inphy0: <i82555 10/100 media interface> PHY 1 on miibus0
>inphy0:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
>fxp0: Ethernet address: 00:02:b3:31:f2:ec
>fxp0: [ITHREAD]
>fxp1: <Intel 82550 Pro/100 Ethernet> port 0xc000-0xc03f mem 
>0xfc449000-0xfc449fff,0xfc420000-0xfc43ffff irq 16 at device 11.0 on pci0
>miibus1: <MII bus> on fxp1
>inphy1: <i82555 10/100 media interface> PHY 1 on miibus1
>inphy1:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
>fxp1: Ethernet address: 00:02:b3:22:a9:ca
>fxp1: [ITHREAD]
>uhci2: <VIA 83C572 USB controller> port 0xc400-0xc41f irq 17 at 
>device 12.0 on pci0
>uhci2: [ITHREAD]
>usbus2: <VIA 83C572 USB controller> on uhci2
>uhci3: <VIA 83C572 USB controller> port 0xc800-0xc81f irq 18 at 
>device 12.1 on pci0
>uhci3: [ITHREAD]
>usbus3: <VIA 83C572 USB controller> on uhci3
>ehci0: <VIA VT6202 USB 2.0 controller> mem 0xfc44b000-0xfc44b0ff irq 
>19 at device 12.2 on pci0
>ehci0: [ITHREAD]
>usbus4: EHCI version 1.0
>usbus4: <VIA VT6202 USB 2.0 controller> on ehci0
>fwohci0: <VIA Fire II (VT6306)> port 0xcc00-0xcc7f mem 
>0xfc44c000-0xfc44c7ff irq 17 at device 12.3 on pci0
>fwohci0: [ITHREAD]
>fwohci0: OHCI version 1.0 (ROM=1)
>fwohci0: No. of Isochronous channels is 4.
>fwohci0: EUI64 00:11:06:00:00:00:e3:32
>fwohci0: Phy 1394a available S400, 3 ports.
>fwohci0: Link S100, max_rec 2 bytes.
>fwohci0: max_rec 2 -> 2048
>firewire0: <IEEE1394(FireWire) bus> on fwohci0
>dcons_crom0: <dcons configuration ROM> on firewire0
>dcons_crom0: bus_addr 0x157c000
>fwe0: <Ethernet over FireWire> on firewire0
>if_fwe0: Fake Ethernet address: 02:11:06:00:e3:32
>fwe0: Ethernet address: 02:11:06:00:e3:32
>fwip0: <IP over FireWire> on firewire0
>fwip0: Firewire address: 00:11:06:00:00:00:e3:32 @ 0xfffe00000000, 
>S400, maxrec 2048
>sbp0: <SBP-2/SCSI over FireWire> on firewire0
>fwohci0: Initiate bus reset
>fwohci0: fwohci_intr_core: BUS reset
>fwohci0: fwohci_intr_core: node_id=0x00000000, SelfID Count=1, 
>CYCLEMASTER mode
>atrtc0: <AT realtime clock> port 0x70-0x73 irq 8 on acpi0
>fdc0: <floppy drive controller> port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on acpi0
>fdc0: [FILTER]
>uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0
>uart0: [FILTER]
>uart1: <16550 or compatible> port 0x2f8-0x2ff irq 3 on acpi0
>uart1: [FILTER]
>ppc0: <Parallel port> port 0x378-0x37f irq 7 on acpi0
>ppc0: Generic chipset (EPP/NIBBLE) in COMPATIBLE mode
>ppc0: [ITHREAD]
>ppbus0: <Parallel port bus> on ppc0
>plip0: <PLIP network interface> on ppbus0
>plip0: [ITHREAD]
>lpt0: <Printer> on ppbus0
>lpt0: [ITHREAD]
>lpt0: Interrupt-driven port
>ppi0: <Parallel I/O> on ppbus0
>atkbdc0: <Keyboard controller (i8042)> port 0x60,0x64 irq 1 on acpi0
>atkbd0: <AT Keyboard> irq 1 on atkbdc0
>kbd0 at atkbd0
>atkbd0: [GIANT-LOCKED]
>atkbd0: [ITHREAD]
>psm0: <PS/2 Mouse> irq 12 on atkbdc0
>psm0: [GIANT-LOCKED]
>psm0: [ITHREAD]
>psm0: model IntelliMouse Explorer, device ID 4
>cpu0: <ACPI CPU> on acpi0
>cpu1: <ACPI CPU> on acpi0
>pmtimer0 on isa0
>orm0: <ISA Option ROMs> at iomem 
>0xc0000-0xc7fff,0xc8000-0xcc7ff,0xcd000-0xce7ff,0xcf000-0xd07ff 
>pnpid ORM0000 on isa0
>sc0: <System console> at flags 0x100 on isa0
>sc0: VGA <16 virtual consoles, flags=0x300>
>vga0: <Generic ISA VGA> at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0
>WARNING: ZFS is considered to be an experimental feature in FreeBSD.
>ZFS NOTICE: prefetch is disabled by default on i386 - add enable to 
>tunable to change.
>ZFS filesystem version 13
>ZFS storage pool version 13
>Timecounters tick every 1.000 msec
>firewire0: 1 nodes, maxhop <= 0 cable IRM irm(0)  (me)
>firewire0: bus manager 0
>Waiting 5 seconds for SCSI devices to settle
>usbus0: 12Mbps Full Speed USB v1.0
>usbus1: 12Mbps Full Speed USB v1.0
>usbus2: 12Mbps Full Speed USB v1.0
>usbus3: 12Mbps Full Speed USB v1.0
>usbus4: 480Mbps High Speed USB v2.0
>ugen0.1: <VIA> at usbus0
>uhub0: <VIA UHCI root HUB, class 9/0, rev 1.00/1.00, addr 1> on usbus0
>ugen1.1: <VIA> at usbus1
>uhub1: <VIA UHCI root HUB, class 9/0, rev 1.00/1.00, addr 1> on usbus1
>ugen2.1: <VIA> at usbus2
>uhub2: <VIA UHCI root HUB, class 9/0, rev 1.00/1.00, addr 1> on usbus2
>ugen3.1: <VIA> at usbus3
>uhub3: <VIA UHCI root HUB, class 9/0, rev 1.00/1.00, addr 1> on usbus3
>ugen4.1: <VIA> at usbus4
>uhub4: <VIA EHCI root HUB, class 9/0, rev 2.00/1.00, addr 1> on usbus4
>uhub0: 2 ports with 2 removable, self powered
>uhub1: 2 ports with 2 removable, self powered
>uhub2: 2 ports with 2 removable, self powered
>uhub3: 2 ports with 2 removable, self powered
>uhub4: 4 ports with 4 removable, self powered
>(aprobe0:siisch0:0:15:0): SIGNATURE: 0000
>(aprobe0:siisch0:0:0:0): SIGNATURE: 0000
>(aprobe1:siisch1:0:15:0): SIGNATURE: 0000
>(aprobe0:siisch1:0:0:0): SIGNATURE: 0000
>ada0 at siisch0 bus 0 target 0 lun 0
>ada0: <ST31500341AS CC1H> ATA/ATAPI-8 SATA 2.x device
>ada0: 300.000MB/s transfers
>ada0: 1430799MB (2930277168 512 byte sectors: 16H 63S/T 16383C)
>ada0: Native Command Queueing enabled
>ada1 at siisch1 bus 0 target 0 lun 0
>ada1: <ST31500341AS CC1H> ATA/ATAPI-8 SATA 2.x device
>ada1: 300.000MB/s transfers
>ada1: 1430799MB (2930277168 512 byte sectors: 16H 63S/T 16383C)
>ada1: Native Command Queueing enabled
>SMP: AP CPU #1 Launched!
>GEOM_MIRROR: Device mirror/gm0p2 launched (2/2).
>Trying to mount root from zfs:tank
>
>
>
>ostb0@pci0:0:0:0:       class=0x060000 card=0x00000000 
>chip=0x06911106 rev=0xc4 hdr=0x00
>pcib1@pci0:0:1:0:       class=0x060400 card=0x00000000 
>chip=0x85981106 rev=0x00 hdr=0x01
>isab0@pci0:0:7:0:       class=0x060100 card=0x000010f1 
>chip=0x06861106 rev=0x40 hdr=0x00
>atapci0@pci0:0:7:1:     class=0x01018a card=0x05711106 
>chip=0x05711106 rev=0x06 hdr=0x00
>uhci0@pci0:0:7:2:       class=0x0c0300 card=0x12340925 
>chip=0x30381106 rev=0x1a hdr=0x00
>uhci1@pci0:0:7:3:       class=0x0c0300 card=0x12340925 
>chip=0x30381106 rev=0x1a hdr=0x00
>none0@pci0:0:7:4:       class=0x068000 card=0x30571106 
>chip=0x30571106 rev=0x40 hdr=0x00
>siis0@pci0:0:8:0:       class=0x018000 card=0x31241095 
>chip=0x31241095 rev=0x02 hdr=0x00
>fxp0@pci0:0:10:0:       class=0x020000 card=0x00408086 
>chip=0x12298086 rev=0x0c hdr=0x00
>fxp1@pci0:0:11:0:       class=0x020000 card=0x00408086 
>chip=0x12298086 rev=0x0c hdr=0x00
>uhci2@pci0:0:12:0:      class=0x0c0300 card=0x30381106 
>chip=0x30381106 rev=0x61 hdr=0x00
>uhci3@pci0:0:12:1:      class=0x0c0300 card=0x30381106 
>chip=0x30381106 rev=0x61 hdr=0x00
>ehci0@pci0:0:12:2:      class=0x0c0320 card=0x31041106 
>chip=0x31041106 rev=0x63 hdr=0x00
>fwohci0@pci0:0:12:3:    class=0x0c0010 card=0x30441106 
>chip=0x30441106 rev=0x46 hdr=0x00
>vgapci0@pci0:1:0:0:     class=0x030000 card=0x00840000 
>chip=0x47441002 rev=0x5c hdr=0x00
>
>
>_______________________________________________
>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"

--------------------------------------------------------------------
Mike Tancsa,                                      tel +1 519 651 3400
Sentex Communications,                            mike@sentex.net
Providing Internet since 1994                    www.sentex.net
Cambridge, Ontario Canada                         www.sentex.net/mike

From james-freebsd-current at jrv.org  Wed Sep  2 12:38:53 2009
From: james-freebsd-current at jrv.org (James R. Van Artsdalen)
Date: Wed Sep  2 12:38:59 2009
Subject: siis/atacam/ata/gmirror 8.0-BETA3 disk performance
In-Reply-To: <4A9E5F34.2090700@razorfever.net>
References: <4A9E5F34.2090700@razorfever.net>
Message-ID: <4A9E6759.7090700@jrv.org>

Derek (freebsd lists) wrote:
> I get about 40MB/s read, and 30MB/s write.  See attached
> bench-*.txt files.

That's too slow.  As I posted on July 31 I got sustained read rates of
875 MB/s across ten disks, through two 3124 cards and four port multipliers.

The system I tested was a dual processor Opteron 244 (1.8 GHz) running
amd64.  Perhaps more important, my disk controllers were on two
different PCI-X buses with ample bandwidth (100 MHz 64-bit and 133 MHz
64-bit).

Is your disk controller on a PCI bus, and is there any other PCI traffic
at the time?
From jhb at freebsd.org  Wed Sep  2 12:44:45 2009
From: jhb at freebsd.org (John Baldwin)
Date: Wed Sep  2 12:44:57 2009
Subject: The only problems with v8.0 are:
In-Reply-To: <20090901201346.GA2432@cuba.calyx.nl>
References: <20090901201346.GA2432@cuba.calyx.nl>
Message-ID: <200909020842.25447.jhb@freebsd.org>

On Tuesday 01 September 2009 4:13:46 pm Bill Squire {billsf} wrote:
> 
> These 'bug' me:
> 
> 8.0 is ready. The '/boot/loader' has been a long time problem. If I'm the 
> only one that knows Forth (my first computer language) I probably can fix it.
> However, a loader from v7 should do fine.

What specifically is broken about /boot/loader in 8.0?

> There appears to be a typo in one of the cddl 32bit Makefiles. It doesn't get 
> a certain header file into */obj/. That file is: '/usr/include/rpc/xdr.h'.

Are you seeing a build failure?  The tinderboxes are not broken so I believe
world is building fine.  If you are having problems building something else
besides world can you provide more details?

-- 
John Baldwin
From 482254ac at razorfever.net  Wed Sep  2 12:58:56 2009
From: 482254ac at razorfever.net (Derek (freebsd lists))
Date: Wed Sep  2 12:59:05 2009
Subject: siis/atacam/ata/gmirror 8.0-BETA3 disk performance
In-Reply-To: <4A9E6759.7090700@jrv.org>
References: <4A9E5F34.2090700@razorfever.net> <4A9E6759.7090700@jrv.org>
Message-ID: <4A9E6C2A.7090305@razorfever.net>

James R. Van Artsdalen wrote:
> Derek (freebsd lists) wrote:
>> I get about 40MB/s read, and 30MB/s write.  See attached
>> bench-*.txt files.
> 
> That's too slow.  As I posted on July 31 I got sustained read rates of
> 875 MB/s across ten disks, through two 3124 cards and four port multipliers.
> 

Right, so directly to a single disks I see 40/30MB/s read/write 
respectively. "Benchmarks" on the Internet peg the i/o to be 
around 100/80MB/s average read on these disks.

> The system I tested was a dual processor Opteron 244 (1.8 GHz) running
> amd64.  Perhaps more important, my disk controllers were on two
> different PCI-X buses with ample bandwidth (100 MHz 64-bit and 133 MHz
> 64-bit).

 From the dmesg, this is a dual 1.4Ghz P3, and the controller is 
standard 32-bit/33Mhz PCI.  Mind you, I think even 80MB/s should 
not saturate the PCI bus, if there's nothing else going on.

> Is your disk controller on a PCI bus, and is there any other PCI traffic
> at the time?

The only traffic would be a little ssh traffic on fxp0, but 
otherwise, I can't think of any other traffic that would be 
occurring.

- Derek
From avg at icyb.net.ua  Wed Sep  2 14:03:51 2009
From: avg at icyb.net.ua (Andriy Gapon)
Date: Wed Sep  2 14:03:58 2009
Subject: DRI initialiazation fails on 8.0-BETAx/M54
In-Reply-To: <1251840705.1689.4440.camel@balrog.2hip.net>
References: <4A9D7560.7060902@freebsd.org>
	<1251840705.1689.4440.camel@balrog.2hip.net>
Message-ID: <4A9E7B42.9070608@icyb.net.ua>

on 02/09/2009 00:31 Robert Noland said the following:
> On Tue, 2009-09-01 at 21:26 +0200, Rene Ladan wrote:
>> Hi,
>>
>> it looks like DRI initalization sometimes fails on my 8.0-BETA3/amd64
>> (official freebsd-update) laptop which has a ATI M54 card (radeonhd
>> driver), reverting to software rendering for everything. The ports are
>> up-to-date.
>>
>>  From Xorg.0.log:
>> (EE) RADEONHD(0): rhdAtomGetDDCIndex: GPIO_DDC Index 6 exceeds maximum 5
>> ..
>> (EE) RADEONHD(0): [pci] Out of memory (-12)
>> (EE) RADEONHD(0): [pci] PCI failed to initialize. Disabling the DRI.
>> ..
>> (II) RADEONHD(0): Using MMIO Command Submission for aceleration.
>> ...
>>
>> Full xorg.conf and Xorg.0.log(.old) are at ftp://rene-ladan/pub/freebsd/
>>
>> Any clues?  Could it be related to hald giving timeouts on acd0 after which
>> I just kill that hald subprocess and starting X after that?
> 
> Is this happening when you start X after the system has been up for a
> bit?  I suspect that what is happening is that memory has become
> fragmented and since bus_dma tries to allocate large chunks of
> contiguous memory for drm, it has a tendency to fail after the system
> has been running for a bit.  This ultimately needs to be fixed in
> bus_dma, but that hasn't happened yet.

BTW, I have a different but potentially related problem - after running a
head/current system for a while I am losing an ability to start VirtualBox. It
complains about something "no memory" too.
The system is amd64 with 4G of RAM with only a handful of processes started.
Maybe we got some regression in memory area (e.g. pmap)?

-- 
Andriy Gapon
From emikulic at gmail.com  Wed Sep  2 14:11:42 2009
From: emikulic at gmail.com (Emil Mikulic)
Date: Wed Sep  2 14:11:49 2009
Subject: siis/atacam/ata/gmirror 8.0-BETA3 disk performance
In-Reply-To: <4A9E5F34.2090700@razorfever.net>
References: <4A9E5F34.2090700@razorfever.net>
Message-ID: <20090902141138.GA15045@dmr.ath.cx>

On Wed, Sep 02, 2009 at 08:04:04AM -0400, Derek (freebsd lists) wrote:
> Hi,
> 
> I've been testing the new siis driver, and I have found no
> appreciable performance change, using dd as a measure of "raw"
> performance.
> 
> I get about 40MB/s read, and 30MB/s write.  See attached
> bench-*.txt files.

[...]

> ada0: <ST31500341AS CC1H> ATA/ATAPI-8 SATA 2.x device
> ada0: 1430799MB (2930277168 512 byte sectors: 16H 63S/T 16383C)

Huh, I have the same disk:

# dmesg | grep ad4
ad4: 1430799MB <Seagate ST31500341AS CC1H> at ata2-master SATA300

Sequential read on a disk this size should be around 120MB/sec at the
outer tracks:

# dd if=/dev/ad4 of=/dev/null bs=128k count=5000
655360000 bytes transferred in 5.171389 secs (126728039 bytes/sec)

> Also I find it surprising that my gmirror read is only 40MB/s,
> and not 60-80MB/s, any thoughts on this?

Stripe will give you higher throughput.
Mirror will give you more random seeks per second.

--Emil
From avg at freebsd.org  Wed Sep  2 14:28:50 2009
From: avg at freebsd.org (Andriy Gapon)
Date: Wed Sep  2 14:28:58 2009
Subject: Problems with mouse
In-Reply-To: <200908311526.26074.hselasky@c2i.net>
References: <20090826080554.GA2664@beastie.smeiknet>
	<200908271913.13206.hselasky@c2i.net>
	<4A9BC919.1070305@freebsd.org>
	<200908311526.26074.hselasky@c2i.net>
Message-ID: <4A9E811E.7040107@freebsd.org>

on 31/08/2009 16:26 Hans Petter Selasky said the following:
> On Monday 31 August 2009 14:59:05 Andriy Gapon wrote:
[snip]
>>
>> It's cf=255 that is different from all other hubs.
> 
> Then:
> 
> usbconfig -u 0 -a 1 set_config 0

OK, did this, the hub re-initialized and tried to attach the mouse, but failed again.

BTW, I obtained some logs with hw.usb.debug=1.
This is what I get when I plug the mouse and it doesn't get attached:

Sep  2 11:51:57 trant kernel: usb_alloc_device:1449:
parent_dev=0xffffff0004e64900, bus=0xffffff80002c4320,
parent_hub=0xffffff00040d5800, depth=1, port_index=1, port_no=2, speed=1, usb_mode=0
Sep  2 11:51:57 trant kernel: usb_set_device_state:2444: udev 0xffffff00464fb800
state DETACHED -> POWERED
Sep  2 11:51:57 trant kernel: usbd_do_request_callback:95: st=0
Sep  2 11:51:57 trant kernel: usbd_transfer_submit:1397: xfer=0xffffff800882e148,
endpoint=0xffffff00464fb8d8, nframes=1, dir=write
Sep  2 11:51:57 trant kernel: usb_dump_endpoint: endpoint=0xffffff00464fb8d8
edesc=0xffffff00464fbde4 isoc_next=0 toggle_next=0 bEndpointAddress=0x00
Sep  2 11:51:57 trant kernel: usb_dump_queue: endpoint=0xffffff00464fb8d8 xfer:
Sep  2 11:51:57 trant kernel: usbd_transfer_submit:1416: open
Sep  2 11:51:57 trant kernel: usbd_pipe_enter:1584: enter
Sep  2 11:51:57 trant kernel: usbd_pipe_start:2416: start
Sep  2 11:51:58 trant kernel: usbd_do_request_flags:327: Handle Request function
is set
Sep  2 11:51:58 trant last message repeated 11 times
Sep  2 11:51:58 trant kernel: usbd_transfer_done:2185: err=USB_ERR_TIMEOUT
Sep  2 11:51:58 trant kernel: usbd_transfer_done:2185: err=USB_ERR_NORMAL_COMPLETION
Sep  2 11:51:58 trant kernel: usbd_callback_wrapper_sub:2550:
xfer=0xffffff800882e148 endpoint=0xffffff00464fb8d8 sts=20 alen=0, slen=8, afrm=0,
nfrm=1
Sep  2 11:51:58 trant kernel: usbd_do_request_callback:95: st=2
Sep  2 11:51:58 trant kernel: usbd_transfer_stop:1691: close
Sep  2 11:51:58 trant kernel: usbd_transfer_done:2185: err=USB_ERR_CANCELLED
Sep  2 11:51:58 trant kernel: usbd_transfer_done:2192: not transferring
Sep  2 11:51:58 trant kernel: usb_alloc_device:1586: set address 2 failed
(USB_ERR_TIMEOUT, ignored)
Sep  2 11:51:58 trant kernel: usb_set_device_state:2444: udev 0xffffff00464fb800
state POWERED -> ADDRESSED
Sep  2 11:51:58 trant kernel: usbd_do_request_callback:95: st=0
Sep  2 11:51:58 trant kernel: usbd_transfer_submit:1397: xfer=0xffffff800882e148,
endpoint=0xffffff00464fb8d8, nframes=2, dir=write
Sep  2 11:51:58 trant kernel: usb_dump_endpoint: endpoint=0xffffff00464fb8d8
edesc=0xffffff00464fbde4 isoc_next=0 toggle_next=1 bEndpointAddress=0x00
Sep  2 11:51:58 trant kernel: usb_dump_queue: endpoint=0xffffff00464fb8d8 xfer:
Sep  2 11:51:58 trant kernel: usbd_transfer_submit:1416: open
Sep  2 11:51:58 trant kernel: usbd_pipe_enter:1584: enter
Sep  2 11:51:58 trant kernel: usbd_pipe_start:2416: start
Sep  2 11:51:59 trant kernel: usbd_do_reuqusebsdt__dfol_argesq:uest_flag3s2:7:
Handl3e2 7R:e qHuaensdtl ef uRnecqtuieosn ti sf usnetction is set
Sep  2 11:51:59 trant kernel: usbd_do_request_flags:327: Handle Request function
is set
Sep  2 11:51:59 trant last message repeated 7 times
Sep  2 11:51:59 trant kernel:
Sep  2 11:51:59 trant kernel: usbd_do_request_flags:327: Handle Request function
is set
Sep  2 11:51:59 trant kernel: usbd_transfer_done:2185: err=USB_ERR_TIMEOUT
Sep  2 11:51:59 trant kernel: usbd_transfer_done:2185: err=USB_ERR_NORMAL_COMPLETION
Sep  2 11:51:59 trant kernel: usbd_callback_wrapper_sub:2550:
xfer=0xffffff800882e148 endpoint=0xffffff00464fb8d8 sts=20 alen=0, slen=16,
afrm=0, nfrm=2
Sep  2 11:51:59 trant kernel: usbd_do_request_callback:95: st=2
Sep  2 11:51:59 trant kernel: usbd_transfer_stop:1691: close
Sep  2 11:51:59 trant kernel: usbd_transfer_done:2185: err=USB_ERR_CANCELLED
Sep  2 11:51:59 trant kernel: usbd_transfer_done:2192: not transferring
Sep  2 11:51:59 trant kernel: usb_alloc_device:1624: getting device descriptor at
addr 2 failed, USB_ERR_TIMEOUT!
Sep  2 11:51:59 trant kernel: usbd_do_request_flags:327: Handle Request function
is set
Sep  2 11:51:59 trant last message repeated 2 times
Sep  2 11:51:59 trant kernel: usbd_do_request_callback:95: st=0
Sep  2 11:51:59 trant kernel: usbd_transfer_submit:1397: xfer=0xffffff800882e148,
endpoint=0xffffff00464fb8d8, nframes=1, dir=write
Sep  2 11:51:59 trant kernel: usb_dump_endpoint: endpoint=0xffffff00464fb8d8
edesc=0xffffff00464fbde4 isoc_next=0 toggle_next=1 bEndpointAddress=0x00
Sep  2 11:51:59 trant kernel: usb_dump_queue: endpoint=0xffffff00464fb8d8 xfer:
Sep  2 11:51:59 trant kernel: usbd_transfer_submit:1416: open
Sep  2 11:51:59 trant kernel: usbd_pipe_enter:1584: enter
Sep  2 11:51:59 trant kernel: usbd_pipe_start:2416: start
Sep  2 11:52:00 trant kernel: usbd_transfer_done:2185: err=USB_ERR_TIMEOUT
Sep  2 11:52:00 trant kernel: usbd_transfer_done:2185: err=USB_ERR_NORMAL_COMPLETION
Sep  2 11:52:00 trant kernel: usbd_callback_wrapper_sub:2550:
xfer=0xffffff800882e148 endpoint=0xffffff00464fb8d8 sts=20 alen=0, slen=8, afrm=0,
nfrm=1
Sep  2 11:52:00 trant kernel: usbd_do_request_callback:95: st=2
Sep  2 11:52:00 trant kernel: usbd_transfer_stop:1691: close
Sep  2 11:52:00 trant kernel: usbd_transfer_done:2185: err=USB_ERR_CANCELLED
Sep  2 11:52:00 trant kernel: usbd_transfer_done:2192: not transferring
Sep  2 11:52:00 trant kernel: usbd_req_re_enumerate:1539: addr=2, set address
failed! (USB_ERR_TIMEOUT, ignored)
Sep  2 11:52:00 trant kernel: usbd_do_request_callback:95: st=0
Sep  2 11:52:00 trant kernel: usbd_transfer_submit:1397: xfer=0xffffff800882e148,
endpoint=0xffffff00464fb8d8, nframes=2, dir=write
Sep  2 11:52:00 trant kernel: usb_dump_endpoint: endpoint=0xffffff00464fb8d8
edesc=0xffffff00464fbde4 isoc_next=0 toggle_next=1 bEndpointAddress=0x00
Sep  2 11:52:00 trant kernel: usb_dump_queue: endpoint=0xffffff00464fb8d8 xfer:
Sep  2 11:52:00 trant kernel: usbd_transfer_submit:1416: open
Sep  2 11:52:00 trant kernel: usbd_pipe_enter:1584: enter
Sep  2 11:52:00 trant kernel: usbd_pipe_start:2416: start
Sep  2 11:52:01 trant kernel: usbd_transfer_done:2185: err=USB_ERR_TIMEOUT
Sep  2 11:52:01 trant kernel: usbd_transfer_done:2185: err=USB_ERR_NORMAL_COMPLETION
Sep  2 11:52:01 trant kernel: usbd_callback_wrapper_sub:2550:
xfer=0xffffff800882e148 endpoint=0xffffff00464fb8d8 sts=20 alen=0, slen=16,
afrm=0, nfrm=2
Sep  2 11:52:01 trant kernel: usbd_do_request_callback:95: st=2
Sep  2 11:52:01 trant kernel: usbd_transfer_stop:1691: close
Sep  2 11:52:01 trant kernel: usbd_transfer_done:2185: err=USB_ERR_CANCELLED
Sep  2 11:52:01 trant kernel: usbd_transfer_done:2192: not transferring
Sep  2 11:52:01 trant kernel: usbd_req_re_enumerate:1553: getting device
descriptor at addr 2 failed, USB_ERR_TIMEOUT!
Sep  2 11:52:02 trant kernel: usbd_do_request_flags:327: Handle Request function
is set
Sep  2 11:52:02 trant last message repeated 9 times
Sep  2 11:52:02 trant kernel:
Sep  2 11:52:02 trant kernel: usbd_do_request_flags:327: Handle Request function
is set
Sep  2 11:52:02 trant last message repeated 4 times
Sep  2 11:52:02 trant kernel: usbd_do_request_callback:95: st=0
Sep  2 11:52:02 trant kernel: usbd_transfer_submit:1397: xfer=0xffffff800882e148,
endpoint=0xffffff00464fb8d8, nframes=1, dir=write
Sep  2 11:52:02 trant kernel: usb_dump_endpoint: endpoint=0xffffff00464fb8d8
edesc=0xffffff00464fbde4 isoc_next=0 toggle_next=1 bEndpointAddress=0x00
Sep  2 11:52:02 trant kernel: usb_dump_queue: endpoint=0xffffff00464fb8d8 xfer:
Sep  2 11:52:02 trant kernel: usbd_transfer_submit:1416: open
Sep  2 11:52:02 trant kernel: usbd_pipe_enter:1584: enter
Sep  2 11:52:02 trant kernel: usbd_pipe_start:2416: start
Sep  2 11:52:03 trant kernel: usbd_do_request_flags:327: Handle Request
fuunscbtdi_odno _irse qsueetst_flags:327: Handle Request function is set
Sep  2 11:52:03 trant kernel: usbd_do_request_flags:327: Handle Request function
is set
Sep  2 11:52:03 trant last message repeated 7 times
Sep  2 11:52:03 trant kernel:
Sep  2 11:52:03 trant kernel: usbd_do_request_flags:327: Handle Request function
is set
Sep  2 11:52:03 trant kernel: usbd_transfer_done:2185: err=USB_ERR_TIMEOUT
Sep  2 11:52:03 trant kernel: usbd_transfer_done:2185: err=USB_ERR_NORMAL_COMPLETION
Sep  2 11:52:03 trant kernel: usbd_callback_wrapper_sub:2550:
xfer=0xffffff800882e148 endpoint=0xffffff00464fb8d8 sts=20 alen=0, slen=8, afrm=0,
nfrm=1
Sep  2 11:52:03 trant kernel: usbd_do_request_callback:95: st=2
Sep  2 11:52:03 trant kernel: usbd_transfer_stop:1691: close
Sep  2 11:52:03 trant kernel: usbd_transfer_done:2185: err=USB_ERR_CANCELLED
Sep  2 11:52:03 trant kernel: usbd_transfer_done:2192: not transferring
Sep  2 11:52:03 trant kernel: usbd_req_re_enumerate:1539: addr=2, set address
failed! (USB_ERR_TIMEOUT, ignored)
Sep  2 11:52:03 trant kernel: usbd_do_request_callback:95: st=0
Sep  2 11:52:03 trant kernel: usbd_transfer_submit:1397: xfer=0xffffff800882e148,
endpoint=0xffffff00464fb8d8, nframes=2, dir=write
Sep  2 11:52:03 trant kernel: usb_dump_endpoint: endpoint=0xffffff00464fb8d8
edesc=0xffffff00464fbde4 isoc_next=0 toggle_next=1 bEndpointAddress=0x00
Sep  2 11:52:03 trant kernel: usb_dump_queue: endpoint=0xffffff00464fb8d8 xfer:
Sep  2 11:52:03 trant kernel: usbd_transfer_submit:1416: open
Sep  2 11:52:03 trant kernel: usbd_pipe_enter:1584: enter
Sep  2 11:52:03 trant kernel: usbd_pipe_start:2416: start
Sep  2 11:52:04 trant kernel: usbd_transfer_done:2185: err=USB_ERR_TIMEOUT
Sep  2 11:52:04 trant kernel: usbd_transfer_done:2185: err=USB_ERR_NORMAL_COMPLETION
Sep  2 11:52:04 trant kernel: usbd_callback_wrapper_sub:2550:
xfer=0xffffff800882e148 endpoint=0xffffff00464fb8d8 sts=20 alen=0, slen=16,
afrm=0, nfrm=2
Sep  2 11:52:04 trant kernel: usbd_do_request_callback:95: st=2
Sep  2 11:52:04 trant kernel: usbd_transfer_stop:1691: close
Sep  2 11:52:04 trant kernel: usbd_transfer_done:2185: err=USB_ERR_CANCELLED
Sep  2 11:52:04 trant kernel: usbd_transfer_done:2192: not transferring
Sep  2 11:52:04 trant kernel: usbd_req_re_enumerate:1553: getting device
descriptor at addr 2 failed, USB_ERR_TIMEOUT!
Sep  2 11:52:04 trant kernel: usb_set_device_state:2444: udev 0xffffff00464fb800
state ADDRESSED -> DETACHED
Sep  2 11:52:04 trant kernel: ugen0.2: <(null)> at usbus0 (disconnected)
Sep  2 11:52:04 trant kernel: uhub_reattach_port:435: could not allocate new device!
Sep  2 11:52:04 trant kernel: usbd_do_request_flags:327: Handle Request function
is set
Sep  2 11:52:06 trant last message repeated 19 times


-- 
Andriy Gapon
From olivier at gid0.org  Wed Sep  2 14:36:31 2009
From: olivier at gid0.org (Olivier Smedts)
Date: Wed Sep  2 14:36:38 2009
Subject: siis/atacam/ata/gmirror 8.0-BETA3 disk performance
In-Reply-To: <20090902141138.GA15045@dmr.ath.cx>
References: <4A9E5F34.2090700@razorfever.net>
	<20090902141138.GA15045@dmr.ath.cx>
Message-ID: <367b2c980909020736i60b64563xc4fec6d11e3dae2b@mail.gmail.com>

2009/9/2 Emil Mikulic <emikulic@gmail.com>:
> On Wed, Sep 02, 2009 at 08:04:04AM -0400, Derek (freebsd lists) wrote:
>> Hi,
>>
>> I've been testing the new siis driver, and I have found no
>> appreciable performance change, using dd as a measure of "raw"
>> performance.
>>
>> I get about 40MB/s read, and 30MB/s write. ?See attached
>> bench-*.txt files.
>
> [...]
>
>> ada0: <ST31500341AS CC1H> ATA/ATAPI-8 SATA 2.x device
>> ada0: 1430799MB (2930277168 512 byte sectors: 16H 63S/T 16383C)
>
> Huh, I have the same disk:
>
> # dmesg | grep ad4
> ad4: 1430799MB <Seagate ST31500341AS CC1H> at ata2-master SATA300
>
> Sequential read on a disk this size should be around 120MB/sec at the
> outer tracks:
>
> # dd if=/dev/ad4 of=/dev/null bs=128k count=5000
> 655360000 bytes transferred in 5.171389 secs (126728039 bytes/sec)
>
>> Also I find it surprising that my gmirror read is only 40MB/s,
>> and not 60-80MB/s, any thoughts on this?
>
> Stripe will give you higher throughput.
> Mirror will give you more random seeks per second.

And higher read throughput.

>
> --Emil
> _______________________________________________
> 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"
>


-- 
Olivier Smedts                                                 _
                                        ASCII ribbon campaign ( )
e-mail: olivier@gid0.org        - against HTML email & vCards  X
www: http://www.gid0.org    - against proprietary attachments / \

  "Il y a seulement 10 sortes de gens dans le monde :
  ceux qui comprennent le binaire,
  et ceux qui ne le comprennent pas."
From hselasky at c2i.net  Wed Sep  2 14:38:08 2009
From: hselasky at c2i.net (Hans Petter Selasky)
Date: Wed Sep  2 14:38:19 2009
Subject: Problems with mouse
In-Reply-To: <4A9E811E.7040107@freebsd.org>
References: <20090826080554.GA2664@beastie.smeiknet>
	<200908311526.26074.hselasky@c2i.net>
	<4A9E811E.7040107@freebsd.org>
Message-ID: <200909021638.25183.hselasky@c2i.net>

On Wednesday 02 September 2009 16:28:46 Andriy Gapon wrote:
> Sep  2 11:51:58 trant kernel: usbd_transfer_done:2185: 
err=USB_ERR_TIMEOUT

If your mouse hardware just times out like that, then its 
more likely that your USB device is bad :-( Have you tried 
other USB mice?

--HPS
From avg at freebsd.org  Wed Sep  2 14:40:21 2009
From: avg at freebsd.org (Andriy Gapon)
Date: Wed Sep  2 14:40:27 2009
Subject: Problems with mouse
In-Reply-To: <200909021638.25183.hselasky@c2i.net>
References: <20090826080554.GA2664@beastie.smeiknet>
	<200908311526.26074.hselasky@c2i.net>
	<4A9E811E.7040107@freebsd.org>
	<200909021638.25183.hselasky@c2i.net>
Message-ID: <4A9E83D1.900@freebsd.org>

on 02/09/2009 17:38 Hans Petter Selasky said the following:
> On Wednesday 02 September 2009 16:28:46 Andriy Gapon wrote:
>> Sep  2 11:51:58 trant kernel: usbd_transfer_done:2185: 
> err=USB_ERR_TIMEOUT
> 
> If your mouse hardware just times out like that, then its 
> more likely that your USB device is bad :-( Have you tried 
> other USB mice?

Can it be sometimes bad, sometimes good?
Maybe timeout is too small for this particular mouse (or right on the edge)?
I could try playing with it.

-- 
Andriy Gapon
From mav at FreeBSD.org  Wed Sep  2 14:51:46 2009
From: mav at FreeBSD.org (Alexander Motin)
Date: Wed Sep  2 14:51:52 2009
Subject: siis/atacam/ata/gmirror 8.0-BETA3 disk performance
In-Reply-To: <h7lmvl$ebq$1@FreeBSD.cs.nctu.edu.tw>
References: <h7lmvl$ebq$1@FreeBSD.cs.nctu.edu.tw>
Message-ID: <4A9E8677.1020208@FreeBSD.org>

Derek (freebsd lists) wrote:
> I've been testing the new siis driver, and I have found no
> appreciable performance change, using dd as a measure of "raw"
> performance.

On linear read/write, without port multipliers used, performance of siis 
driver is not so much differs from legacy driver. The most of it's 
benefits are NCQ, FIS-based switching and command queuing affect mostly 
highly parallel random workload.

> I get about 40MB/s read, and 30MB/s write.  See attached
> bench-*.txt files.

It's too small, indeed. Actually, there are two different kinds of siis 
compatible devices: SiI3124 and SiI3132/SiI3531. SiI3124 is more 
expensive PCI-X card, sometimes it goes with built-in PCIe x4 bridge. To 
operate effectively it needs effective bus. Inserting it to usual PCI or 
PCIe x1 slot kills any hope. SiI3132/SiI3531 same time are cheap PCIe x1 
cards. Nobody have ever seen them giving more 130-150MB/s, even looking 
that PCIe x1 should give 2.5Gb/s.

> Am I expecting too much, or do I have something else going on
> here?  (e.g. dd being a terrible benchmark of disk i/o)
> 
> Is anyone else seeing better/worse/same numbers?

I have posted my micro benchmarks here:
http://docs.freebsd.org/cgi/mid.cgi?4A95A3CA.3060306

> Also I find it surprising that my gmirror read is only 40MB/s,
> and not 60-80MB/s, any thoughts on this?

To completely load gmirror on read operations, you may need to run two 
dd's same time. Also make sure, that your gmirror runs in round-robin 
mode. Default split mode, which should help with linear read, is IMHO 
ineffective, at least with default MAXPHYS and slice values.

For maximum linear I/O performance you may want to build kernel with
options 	MAXPHYS=(1024*1024)

If you are doing many linear reads from file system, increase 
vfs.read_max sysctl.

-- 
Alexander Motin
From rene at freebsd.org  Wed Sep  2 14:54:29 2009
From: rene at freebsd.org (Rene Ladan)
Date: Wed Sep  2 14:54:36 2009
Subject: DRI initialiazation fails on 8.0-BETAx/M54
In-Reply-To: <4A9E7B42.9070608@icyb.net.ua>
References: <4A9D7560.7060902@freebsd.org>
	<1251840705.1689.4440.camel@balrog.2hip.net>
	<4A9E7B42.9070608@icyb.net.ua>
Message-ID: <e890cae60909020724j17d970d7x2e0db533b0c1eef5@mail.gmail.com>

2009/9/2 Andriy Gapon <avg@icyb.net.ua>:
> on 02/09/2009 00:31 Robert Noland said the following:
>> On Tue, 2009-09-01 at 21:26 +0200, Rene Ladan wrote:
>>> Hi,
>>>
>>> it looks like DRI initalization sometimes fails on my 8.0-BETA3/amd64
>>> (official freebsd-update) laptop which has a ATI M54 card (radeonhd
>>> driver), reverting to software rendering for everything. The ports are
>>> up-to-date.
>>>
>>> ?From Xorg.0.log:
>>> (EE) RADEONHD(0): rhdAtomGetDDCIndex: GPIO_DDC Index 6 exceeds maximum 5
>>> ..
>>> (EE) RADEONHD(0): [pci] Out of memory (-12)
>>> (EE) RADEONHD(0): [pci] PCI failed to initialize. Disabling the DRI.
>>> ..
>>> (II) RADEONHD(0): Using MMIO Command Submission for aceleration.
>>> ...
>>>
>>> Full xorg.conf and Xorg.0.log(.old) are at ftp://rene-ladan/pub/freebsd/
>>>
>>> Any clues? ?Could it be related to hald giving timeouts on acd0 after which
>>> I just kill that hald subprocess and starting X after that?
>>
>> Is this happening when you start X after the system has been up for a
>> bit? ?I suspect that what is happening is that memory has become
>> fragmented and since bus_dma tries to allocate large chunks of
>> contiguous memory for drm, it has a tendency to fail after the system
>> has been running for a bit. ?This ultimately needs to be fixed in
>> bus_dma, but that hasn't happened yet.
>
> BTW, I have a different but potentially related problem - after running a
> head/current system for a while I am losing an ability to start VirtualBox. It
> complains about something "no memory" too.
> The system is amd64 with 4G of RAM with only a handful of processes started.
> Maybe we got some regression in memory area (e.g. pmap)?
>
FWIW, my main memory size is 2GB.  I haven't tried vbox (yet).
More information at ftp://rene-ladan.nl/pub/freebsd/dmesg-80b3.txt

Ren?
From ticso at cicely7.cicely.de  Wed Sep  2 15:00:25 2009
From: ticso at cicely7.cicely.de (Bernd Walter)
Date: Wed Sep  2 15:00:34 2009
Subject: siis/atacam/ata/gmirror 8.0-BETA3 disk performance
In-Reply-To: <367b2c980909020736i60b64563xc4fec6d11e3dae2b@mail.gmail.com>
References: <4A9E5F34.2090700@razorfever.net>
	<20090902141138.GA15045@dmr.ath.cx>
	<367b2c980909020736i60b64563xc4fec6d11e3dae2b@mail.gmail.com>
Message-ID: <20090902150017.GU60240@cicely7.cicely.de>

On Wed, Sep 02, 2009 at 04:36:29PM +0200, Olivier Smedts wrote:
> 2009/9/2 Emil Mikulic <emikulic@gmail.com>:
> > On Wed, Sep 02, 2009 at 08:04:04AM -0400, Derek (freebsd lists) wrote:
> >> Hi,
> >>
> >> I've been testing the new siis driver, and I have found no
> >> appreciable performance change, using dd as a measure of "raw"
> >> performance.
> >>
> >> I get about 40MB/s read, and 30MB/s write. ?See attached
> >> bench-*.txt files.
> >
> > [...]
> >
> >> ada0: <ST31500341AS CC1H> ATA/ATAPI-8 SATA 2.x device
> >> ada0: 1430799MB (2930277168 512 byte sectors: 16H 63S/T 16383C)
> >
> > Huh, I have the same disk:
> >
> > # dmesg | grep ad4
> > ad4: 1430799MB <Seagate ST31500341AS CC1H> at ata2-master SATA300
> >
> > Sequential read on a disk this size should be around 120MB/sec at the
> > outer tracks:
> >
> > # dd if=/dev/ad4 of=/dev/null bs=128k count=5000
> > 655360000 bytes transferred in 5.171389 secs (126728039 bytes/sec)
> >
> >> Also I find it surprising that my gmirror read is only 40MB/s,
> >> and not 60-80MB/s, any thoughts on this?
> >
> > Stripe will give you higher throughput.
> > Mirror will give you more random seeks per second.
> 
> And higher read throughput.

This is a myth and not true for linear access in the general case.
A disk usually lays the track reversed order to increase read throughput.
Once the head is positioned it reads data into cache until the
asked block is reached, so it already has more or less of the following
blocks in cache.
If you need the following block you better ask the same disk, because
at average it already has the half track in cache.
If you ask another disk it has to do a physical read first.
To really increase linear throughput you need to preread data at a large
offset (knowing the physical layout of the drive), but since in real
world this is usually data of a completely different file it doesn't
make much sense.
For short range switches you just ask two disks for different blocks,
but require them to issue the same physical reads.
Of course you can double the read throughput, but only tuned for
contructed cases.

Striping is different, because say first strip is accessed from disk 1
and second stripe from disk 2.
This reduces performance, because unlike disk 1 disk 2 has the following
block not in cache, but for upcoming blocks you win from the cummulative
preread cache.
But real world filesystem access rarely is that linear, so even then it
mmight be better to increase the stripe size large enough to not take
the linear win, but also not have the disk switch loss.

In real world you usually can win performance from random access in
both cases and random access is what you almost always really want to
increase.

-- 
B.Walter <bernd@bwct.de> http://www.bwct.de
Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm.
From 482254ac at razorfever.net  Wed Sep  2 15:25:32 2009
From: 482254ac at razorfever.net (Derek (freebsd lists))
Date: Wed Sep  2 15:25:59 2009
Subject: siis/atacam/ata/gmirror 8.0-BETA3 disk performance
In-Reply-To: <4A9E8677.1020208@FreeBSD.org>
References: <h7lmvl$ebq$1@FreeBSD.cs.nctu.edu.tw>
	<4A9E8677.1020208@FreeBSD.org>
Message-ID: <4A9E8E82.9050708@razorfever.net>

Thank you for your informative response.

Alexander Motin wrote:
> Derek (freebsd lists) wrote:
>> I've been testing the new siis driver, and I have found no
>> appreciable performance change, using dd as a measure of "raw"
>> performance.
> 
> On linear read/write, without port multipliers used, performance of siis 
> driver is not so much differs from legacy driver. The most of it's 
> benefits are NCQ, FIS-based switching and command queuing affect mostly 
> highly parallel random workload.
> 

That's good news, in that the behaviour is expected.

>> I get about 40MB/s read, and 30MB/s write.  See attached
>> bench-*.txt files.
> 
> It's too small, indeed. Actually, there are two different kinds of siis 
> compatible devices: SiI3124 and SiI3132/SiI3531. SiI3124 is more 
> expensive PCI-X card, sometimes it goes with built-in PCIe x4 bridge. To 
> operate effectively it needs effective bus. Inserting it to usual PCI or 
> PCIe x1 slot kills any hope. SiI3132/SiI3531 same time are cheap PCIe x1 
> cards. Nobody have ever seen them giving more 130-150MB/s, even looking 
> that PCIe x1 should give 2.5Gb/s.
> 

I've got the SiI3124, plugged into a PCI bus.  While I know PCI 
is really slow by today's standards, I was hoping to see 
performance closer to the bus limits.

My rates are 30% of the maximum "theoretical" bus utilization 
(33Mhz*32-bits).  The figures you give for PCIe x1 are around 40% 
of maximum (on the low end of the figures) utilization, so we're 
in the same neighbourhood.

> To completely load gmirror on read operations, you may need to run two 
> dd's same time. Also make sure, that your gmirror runs in round-robin 
> mode. Default split mode, which should help with linear read, is IMHO 
> ineffective, at least with default MAXPHYS and slice values.
> ...

I'll play around with this as well, I'm not too interested in 
tweaking stuff much in production, but it would be interesting to 
see just how this performs.

In production, I plan to use the gmirror for swap, and zfs for 
everything else.  It seems that for swap usage, linear read isn't 
a great model.

Thanks again!
- Derek


From mel.flynn+fbsd.current at mailing.thruhere.net  Wed Sep  2 15:28:25 2009
From: mel.flynn+fbsd.current at mailing.thruhere.net (Mel Flynn)
Date: Wed Sep  2 15:28:32 2009
Subject: MAXPHYS and physical memory (Was: Re: siis/atacam/ata/gmirror
	8.0-BETA3 disk performance)
In-Reply-To: <4A9E8677.1020208@FreeBSD.org>
References: <h7lmvl$ebq$1@FreeBSD.cs.nctu.edu.tw>
	<4A9E8677.1020208@FreeBSD.org>
Message-ID: <200909021728.21566.mel.flynn+fbsd.current@mailing.thruhere.net>

On Wednesday 02 September 2009 16:51:35 Alexander Motin wrote:

> For maximum linear I/O performance you may want to build kernel with
> options 	MAXPHYS=(1024*1024)

I've found that just doubling the default MAXPHYS already panics-on-boot a 
1.5GB i386 system. Is there any reasonable conversion table for MAXPHYS to 
physical memory, since various memory related kernel setups are derived from 
or calculated with MAXPHYS?
-- 
Mel
From 482254ac at razorfever.net  Wed Sep  2 15:28:48 2009
From: 482254ac at razorfever.net (Derek (freebsd lists))
Date: Wed Sep  2 15:28:55 2009
Subject: siis/atacam/ata/gmirror 8.0-BETA3 disk performance
In-Reply-To: <20090902141138.GA15045@dmr.ath.cx>
References: <4A9E5F34.2090700@razorfever.net>
	<20090902141138.GA15045@dmr.ath.cx>
Message-ID: <4A9E8F4A.7080409@razorfever.net>

Emil Mikulic wrote:
> Huh, I have the same disk:
> 
> # dmesg | grep ad4
> ad4: 1430799MB <Seagate ST31500341AS CC1H> at ata2-master SATA300
> 
> Sequential read on a disk this size should be around 120MB/sec at the
> outer tracks:
> 
> # dd if=/dev/ad4 of=/dev/null bs=128k count=5000
> 655360000 bytes transferred in 5.171389 secs (126728039 bytes/sec)
> 

Would you mind describing the controller/bus that you are using 
to get these speeds?

Thanks!
- Derek
From avg at icyb.net.ua  Wed Sep  2 15:30:21 2009
From: avg at icyb.net.ua (Andriy Gapon)
Date: Wed Sep  2 15:30:28 2009
Subject: ahci cd0 issue
Message-ID: <4A9E8F8A.1010004@icyb.net.ua>


k3b did "something" to my cd0 while tasting it and after that IDE activity LED was
constantly on and I got a never-ending stream of messages like the following:

ahcich5: Timeout on slot 25
ahcich5: Timeout on slot 26
ahcich5: Timeout on slot 29
ahcich5: Timeout on slot 30
ahcich5: Timeout on slot 1
ahcich5: Timeout on slot 2
ahcich5: Timeout on slot 5
ahcich5: Timeout on slot 6
ahcich5: Timeout on slot 9
ahcich5: Timeout on slot 10
...
and so on.
cd0 is on ahcich5.

This is head r196558.

-- 
Andriy Gapon
From mav at FreeBSD.org  Wed Sep  2 15:47:03 2009
From: mav at FreeBSD.org (Alexander Motin)
Date: Wed Sep  2 15:47:10 2009
Subject: MAXPHYS and physical memory (Was: Re: siis/atacam/ata/gmirror
 8.0-BETA3 disk performance)
In-Reply-To: <200909021728.21566.mel.flynn+fbsd.current@mailing.thruhere.net>
References: <h7lmvl$ebq$1@FreeBSD.cs.nctu.edu.tw>
	<4A9E8677.1020208@FreeBSD.org>
	<200909021728.21566.mel.flynn+fbsd.current@mailing.thruhere.net>
Message-ID: <4A9E9366.9050601@FreeBSD.org>

Mel Flynn wrote:
> On Wednesday 02 September 2009 16:51:35 Alexander Motin wrote:
> 
>> For maximum linear I/O performance you may want to build kernel with
>> options 	MAXPHYS=(1024*1024)
> 
> I've found that just doubling the default MAXPHYS already panics-on-boot a 
> 1.5GB i386 system. Is there any reasonable conversion table for MAXPHYS to 
> physical memory, since various memory related kernel setups are derived from 
> or calculated with MAXPHYS?

What especially your panic was about? It could be bug in ATA(4) or some 
other code, that does not handle MAXPHYS correctly. I don't think that 
you could reach memory limit during simple system boot because of that. 
I am successfully running my testing Pentium-75 with 64MB RAM with 1MB 
MAXPHYS.

Could you show your panic message?

-- 
Alexander Motin
From mav at FreeBSD.org  Wed Sep  2 16:47:07 2009
From: mav at FreeBSD.org (Alexander Motin)
Date: Wed Sep  2 16:47:14 2009
Subject: ahci cd0 issue
In-Reply-To: <4A9E8F8A.1010004@icyb.net.ua>
References: <4A9E8F8A.1010004@icyb.net.ua>
Message-ID: <4A9EA17C.2020204@FreeBSD.org>

Andriy Gapon wrote:
> k3b did "something" to my cd0 while tasting it and after that IDE activity LED was
> constantly on and I got a never-ending stream of messages like the following:
> 
> ahcich5: Timeout on slot 25
> ahcich5: Timeout on slot 26
> ahcich5: Timeout on slot 29
> ahcich5: Timeout on slot 30
> ahcich5: Timeout on slot 1
> ahcich5: Timeout on slot 2
> ahcich5: Timeout on slot 5
> ahcich5: Timeout on slot 6
> ahcich5: Timeout on slot 9
> ahcich5: Timeout on slot 10
> ...
> and so on.
> cd0 is on ahcich5.
> 
> This is head r196558.

I don't know what initially caused the problem, but new ATA-CAM 
infrastructure is still lacks of proper timeout error recovery. It is 
not easy part, but I am working on it.

-- 
Alexander Motin
From hrs at FreeBSD.org  Wed Sep  2 19:41:05 2009
From: hrs at FreeBSD.org (Hiroki Sato)
Date: Wed Sep  2 19:41:13 2009
Subject: IPv6 regression on 8.x
In-Reply-To: <20090902.155958.08019398.hrs@allbsd.org>
References: <20090830.024420.174808572.hrs@allbsd.org>
	<B583FBF374231F4A89607B4D08578A43052EEDE6@bcs-mail03.internal.cacheflow.com>
	<20090902.155958.08019398.hrs@allbsd.org>
Message-ID: <20090903.043840.213910223.hrs@allbsd.org>

Hiroki Sato <hrs@freebsd.org> wrote
  in <20090902.155958.08019398.hrs@allbsd.org>:

hr>  Anyway, I will try the a-box-with-three-NICs case when I return home
hr>  today.  I didn't try it.

 Okay, I tried the case of all of NICs on a host and confirmed it
 works fine.

hr>
hr> qi> Would it be possible for you to email me your system configuration
hr> qi> produced from "ifconfig" and "netstat" privately ?
hr>
hr>  Sure.  I will send them to you later.

The results of ifconfig and netstat are the following.  These are by
another configuration from one I sent in the previous email, but the
symptom is still reproducible:

box-A (RELENG_7):

re0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
        ether 00:26:18:41:64:1a
        inet6 fe80::226:18ff:fe41:641a%re0 prefixlen 64 scopeid 0x2
        inet6 2001:db8:1::6 prefixlen 64

Destination                       Gateway                       Flags      Netif Expire
::/96                             ::1                           UGRS        lo0 =>
default                           fe80::21a:6dff:feb9:fd1b%ng1  UGS         ng1
::1                               ::1                           UHL         lo0
::ffff:0.0.0.0/96                 ::1                           UGRS        lo0
2001:db8:1::                      00:13:a9:ff:63:e6             UHLW        re0 =>
2001:db8:1::/64                   link#2                        UC          re0
2001:db8:1::1                     00:13:a9:ff:63:e6             UHLW        re0
2001:db8:1::6                     00:26:18:41:64:1a             UHL         lo0

box-B (CURRENT):

msk0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
        ether 00:13:a9:ff:63:e6
        inet6 fe80::213:a9ff:feff:63e6%msk0 prefixlen 64 scopeid 0x1
        inet6 2001:db8:1:: prefixlen 64 anycast

gif0: flags=8011<UP,POINTOPOINT,MULTICAST> metric 0 mtu 1280
        inet6 2001:db8:2::1 prefixlen 64
        inet6 fe80::213:a9ff:feff:63e6%gif0 prefixlen 64 scopeid 0x7

Destination                       Gateway                       Flags      Netif Expire
::/96                             ::1                           UGRS        lo0 =>
default                           fe80::214:1bff:fe39:281a%msk0 UG         msk0
::1                               ::1                           UH          lo0
::ffff:0.0.0.0/96                 ::1                           UGRS        lo0
2001:db8:1::                      link#5                        UHS         lo0 =>
2001:db8:1::/64                   link#1                        U          msk0
2001:db8:2::/64                   link#7                        U          gif0
2001:db8:2::1                     link#5                        UHS         lo0
fe80::/10                         ::1                           UGRS        lo0
fe80::%msk0/64                    link#1                        U          msk0
fe80::213:a9ff:feff:63e6%msk0     link#5                        UHS         lo0
fe80::%lo0/64                     link#5                        U           lo0
fe80::%gif0/64                    link#7                        U          gif0
fe80::213:a9ff:feff:63e6%gif0     link#5                        UHS         lo0
ff01:1::/32                       fe80::213:a9ff:feff:63e6%msk0 U          msk0
ff01:5::/32                       ::1                           U           lo0
ff01:7::/32                       2001:db8:2::1                 U          gif0
ff02::/16                         ::1                           UGRS        lo0
ff02::%msk0/32                    fe80::213:a9ff:feff:63e6%msk0 U          msk0
ff02::%lo0/32                     ::1                           U           lo0
ff02::%gif0/32                    2001:db8:2::1                 U          gif0

 When doing "ping6 2001:db8:1::" from box-A, the source address becomes
 2001:db8:1::6 (this is correct) and a link-local address on msk0 on
 box-B replies.

-- Hiroki
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20090902/4ba77330/attachment.pgp
From nick at van-laarhoven.org  Wed Sep  2 20:22:24 2009
From: nick at van-laarhoven.org (Nick Hibma)
Date: Wed Sep  2 20:22:31 2009
Subject: Reducing noise in dmesg output
In-Reply-To: <1251841416.1689.4458.camel@balrog.2hip.net>
References: <200909010931.16880.nick@van-laarhoven.org>
	<1251841416.1689.4458.camel@balrog.2hip.net>
Message-ID: <200909021656.15747.nick@van-laarhoven.org>

> What is irrelevant is subjective...  I mean does the average user really
> need to see anything in dmesg?  Please don't change agp_i810.c.  A
> verbose boot is incredibly noisy and rarely needed for debugging
> anything except the most deep rooted of issues.

Please state arguments instead of this 'I think it is useful'. That's not 
going to cut it. If you feel strongly about the info that is being produced, 
an option would be to produce a (tested!) patch that combines more 
information on one line as a compromise.

FreeBSD has historically been producing very limited output on dmesg. Linux 
is very noisy (ever noticed the copyright notices right in the middle of 
your list of PCI devices?). Even they have decided that they should hide 
this behind coloured 'ok/failed' texts in some distributions.

FreeBSD has slowly been producing more and more output (most notably the USB 
subsystem up to 7.x) and I am intending to remove that clutter again, or at 
least compress it.

Being swamped with information reduces its value rather than increase it.

Nick
From mel.flynn+fbsd.current at mailing.thruhere.net  Wed Sep  2 21:01:07 2009
From: mel.flynn+fbsd.current at mailing.thruhere.net (Mel Flynn)
Date: Wed Sep  2 21:01:14 2009
Subject: MAXPHYS and physical memory (Was: Re: siis/atacam/ata/gmirror
	8.0-BETA3 disk performance)
In-Reply-To: <4A9E9366.9050601@FreeBSD.org>
References: <h7lmvl$ebq$1@FreeBSD.cs.nctu.edu.tw>
	<200909021728.21566.mel.flynn+fbsd.current@mailing.thruhere.net>
	<4A9E9366.9050601@FreeBSD.org>
Message-ID: <200909022301.03825.mel.flynn+fbsd.current@mailing.thruhere.net>

On Wednesday 02 September 2009 17:46:46 Alexander Motin wrote:
> Mel Flynn wrote:
> > On Wednesday 02 September 2009 16:51:35 Alexander Motin wrote:
> >> For maximum linear I/O performance you may want to build kernel with
> >> options 	MAXPHYS=(1024*1024)
> >
> > I've found that just doubling the default MAXPHYS already panics-on-boot
> > a 1.5GB i386 system. Is there any reasonable conversion table for MAXPHYS
> > to physical memory, since various memory related kernel setups are
> > derived from or calculated with MAXPHYS?
>
> What especially your panic was about? It could be bug in ATA(4) or some
> other code, that does not handle MAXPHYS correctly. I don't think that
> you could reach memory limit during simple system boot because of that.
> I am successfully running my testing Pentium-75 with 64MB RAM with 1MB
> MAXPHYS.
>
> Could you show your panic message?

It's been a while since I last tried, during 7.1-STABLE. Two different 
machines wouldn't boot, both 1.5G; loading kernel.old, then commenting the 
MAXPHYS change, rebuilding kernel made things work, so I stopped pursuing this 
at the time.
I remember the panic message quite early page fault, one of the first drivers 
loaded (ahci or acpi). Since this is supposed to work, I'm going to pursue it 
further and see if I can still reproduce it.
-- 
Mel
From mav at FreeBSD.org  Wed Sep  2 21:20:53 2009
From: mav at FreeBSD.org (Alexander Motin)
Date: Wed Sep  2 21:21:01 2009
Subject: MAXPHYS and physical memory (Was: Re: siis/atacam/ata/gmirror
 8.0-BETA3 disk performance)
In-Reply-To: <200909022301.03825.mel.flynn+fbsd.current@mailing.thruhere.net>
References: <h7lmvl$ebq$1@FreeBSD.cs.nctu.edu.tw>
	<200909021728.21566.mel.flynn+fbsd.current@mailing.thruhere.net>
	<4A9E9366.9050601@FreeBSD.org>
	<200909022301.03825.mel.flynn+fbsd.current@mailing.thruhere.net>
Message-ID: <4A9EE1AB.3040307@FreeBSD.org>

Mel Flynn wrote:
> On Wednesday 02 September 2009 17:46:46 Alexander Motin wrote:
>> Mel Flynn wrote:
>>> On Wednesday 02 September 2009 16:51:35 Alexander Motin wrote:
>>>> For maximum linear I/O performance you may want to build kernel with
>>>> options 	MAXPHYS=(1024*1024)
>>> I've found that just doubling the default MAXPHYS already panics-on-boot
>>> a 1.5GB i386 system. Is there any reasonable conversion table for MAXPHYS
>>> to physical memory, since various memory related kernel setups are
>>> derived from or calculated with MAXPHYS?
>> What especially your panic was about? It could be bug in ATA(4) or some
>> other code, that does not handle MAXPHYS correctly. I don't think that
>> you could reach memory limit during simple system boot because of that.
>> I am successfully running my testing Pentium-75 with 64MB RAM with 1MB
>> MAXPHYS.
>>
>> Could you show your panic message?
> 
> It's been a while since I last tried, during 7.1-STABLE. Two different 
> machines wouldn't boot, both 1.5G; loading kernel.old, then commenting the 
> MAXPHYS change, rebuilding kernel made things work, so I stopped pursuing this 
> at the time.
> I remember the panic message quite early page fault, one of the first drivers 
> loaded (ahci or acpi). Since this is supposed to work, I'm going to pursue it 
> further and see if I can still reproduce it.

I have fixed MAXPHYS issue in ata-ahci in RELENG_8, but I haven't merged 
it lower as code is quite different. So it would be nice if you can 
check it on 8.x.

-- 
Alexander Motin
From jakub_lach at mailplus.pl  Wed Sep  2 21:24:04 2009
From: jakub_lach at mailplus.pl (Jakub Lach)
Date: Wed Sep  2 21:24:12 2009
Subject: ahci cd0 issue
In-Reply-To: <4A9EA17C.2020204@FreeBSD.org>
References: <4A9E8F8A.1010004@icyb.net.ua> <4A9EA17C.2020204@FreeBSD.org>
Message-ID: <25265998.post@talk.nabble.com>



Alexander Motin-3 wrote:
> 
> Andriy Gapon wrote:
>> k3b did "something" to my cd0 while tasting it and after that IDE
>> activity LED was
>> constantly on and I got a never-ending stream of messages like the
>> following:
>> 
>> ahcich5: Timeout on slot 25
>> ahcich5: Timeout on slot 26
>> ahcich5: Timeout on slot 29
>> ahcich5: Timeout on slot 30
>> ahcich5: Timeout on slot 1
>> ahcich5: Timeout on slot 2
>> ahcich5: Timeout on slot 5
>> ahcich5: Timeout on slot 6
>> ahcich5: Timeout on slot 9
>> ahcich5: Timeout on slot 10
>> ...
>> and so on.
>> cd0 is on ahcich5.
>> 
>> This is head r196558.
> 
> I don't know what initially caused the problem, but new ATA-CAM 
> infrastructure is still lacks of proper timeout error recovery. It is 
> not easy part, but I am working on it.
> 
> -- 
> Alexander Motin
> _______________________________________________
> 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"
> 
> 

Hello.

More or less, I've lost my sata dvd drive ;)

(cd0: <HL-DT-ST DVDRAM GSA-U20N HX11>)

Although I can mount CDs, cdparanoia is not working, 

003: CDROM reporting illegal number of tracks

cdda2wav as well..

cdda2wav: Error 0. inquiry: scsi sendcmd: fatal error
CDB:  12 E0 00 00 24 00
cmd finished after 0.000s timeout 60s
Inquiry command failed. Aborting...

cdcontrol play produces no sound..
(but it probably wasn't working with atacontrol either)

mplayer stubbornly wants to play dvd:// as /dev/acd0 ,
using "mplayer /dev/cd0" plays first track of dvd, 
trying to play cd with this command leads to:

Playing /dev/cd0.
Seek failed

I think that If mplayer would interpret dvd://(track) as
/dev/cd0(track) original functionality should be restored.

For now NCQ has stripped me of ability to watch DVDs
and rip audiocds ;) Well, trade-off. 

-best regards, 
Jakub Lach


-- 
View this message in context: http://www.nabble.com/ahci-cd0-issue-tp25259873p25265998.html
Sent from the freebsd-current mailing list archive at Nabble.com.

From emikulic at gmail.com  Thu Sep  3 00:11:26 2009
From: emikulic at gmail.com (Emil Mikulic)
Date: Thu Sep  3 00:11:34 2009
Subject: siis/atacam/ata/gmirror 8.0-BETA3 disk performance
In-Reply-To: <4A9E8F4A.7080409@razorfever.net>
References: <4A9E5F34.2090700@razorfever.net>
	<20090902141138.GA15045@dmr.ath.cx>
	<4A9E8F4A.7080409@razorfever.net>
Message-ID: <20090903001123.GA17538@dmr.ath.cx>

On Wed, Sep 02, 2009 at 11:29:14AM -0400, Derek (freebsd lists) wrote:
> Would you mind describing the controller/bus that you are using to
> get these speeds?

Bits of dmesg:

atapci1: <nVidia AHCI controller> port 0xd480-0xd487,0xd400-0xd403,0xd080-0xd087,0xd000-0xd003,0xcc00-0xcc0f mem 0xfae7a000-0xfae7bfff irq 22 at device 9.0 on pci0
atapci1: [ITHREAD]
atapci1: AHCI v1.20 controller with 6 3Gbps ports, PM supported
ata2: <ATA channel 0> on atapci1
ata2: [ITHREAD]
ad4: 1430799MB <Seagate ST31500341AS CC1H> at ata2-master SATA300

Also kenv:
smbios.planar.product="M4N78 PRO"

This system has a newer CPU than the one you were timing:

CPU: AMD Athlon(tm) 64 X2 Dual Core Processor 5200+ (2700.02-MHz K8-class CPU)

Are you seeing a lot of system and/or interrupt time when you do your
benchmarks?

--Emil
From astrodog at gmail.com  Thu Sep  3 00:17:35 2009
From: astrodog at gmail.com (Astrodog)
Date: Thu Sep  3 00:17:41 2009
Subject: Reducing noise in dmesg output
In-Reply-To: <200909021656.15747.nick@van-laarhoven.org>
References: <200909010931.16880.nick@van-laarhoven.org>
	<1251841416.1689.4458.camel@balrog.2hip.net>
	<200909021656.15747.nick@van-laarhoven.org>
Message-ID: <2fd864e0909021645p735e22b8id7d41f4b5a0ee89e@mail.gmail.com>

On Wed, Sep 2, 2009 at 9:56 AM, Nick Hibma<nick@van-laarhoven.org> wrote:
>> What is irrelevant is subjective... ?I mean does the average user really
>> need to see anything in dmesg? ?Please don't change agp_i810.c. ?A
>> verbose boot is incredibly noisy and rarely needed for debugging
>> anything except the most deep rooted of issues.
>
> Please state arguments instead of this 'I think it is useful'. That's not
> going to cut it. If you feel strongly about the info that is being produced,
> an option would be to produce a (tested!) patch that combines more
> information on one line as a compromise.
>
> FreeBSD has historically been producing very limited output on dmesg. Linux
> is very noisy (ever noticed the copyright notices right in the middle of
> your list of PCI devices?). Even they have decided that they should hide
> this behind coloured 'ok/failed' texts in some distributions.
>
> FreeBSD has slowly been producing more and more output (most notably the USB
> subsystem up to 7.x) and I am intending to remove that clutter again, or at
> least compress it.
>
> Being swamped with information reduces its value rather than increase it.
>
> Nick

I think this speaks more towards needing something between "Very
Quiet" and "Give me everything every developer has ever wanted to know
enough to include a print for it."

--- Harrison
From emikulic at gmail.com  Thu Sep  3 00:21:10 2009
From: emikulic at gmail.com (Emil Mikulic)
Date: Thu Sep  3 00:21:17 2009
Subject: siis/atacam/ata/gmirror 8.0-BETA3 disk performance
In-Reply-To: <4A9E8677.1020208@FreeBSD.org>
References: <h7lmvl$ebq$1@FreeBSD.cs.nctu.edu.tw>
	<4A9E8677.1020208@FreeBSD.org>
Message-ID: <20090903002106.GB17538@dmr.ath.cx>

On Wed, Sep 02, 2009 at 05:51:35PM +0300, Alexander Motin wrote:
> To completely load gmirror on read operations, you may need to run
> two dd's same time. Also make sure, that your gmirror runs in
> round-robin mode. Default split mode, which should help with linear
> read, is IMHO ineffective, at least with default MAXPHYS and slice
> values.

On that note, there is an excellent patch in this PR which improves
the way gmirror schedules read requests to different disks:

http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/113885

Could someone please commit this?

With this patch and a two-way mirror, I can run two linear scans of
different files in parallel and get almost perfect scaling.  (result:
this approximately halves the wall-clock time it takes to do a backup of
some fat VM images)

IIRC, without the patch it's faster to run them sequentially.  :(

--Emil
From emikulic at gmail.com  Thu Sep  3 00:28:59 2009
From: emikulic at gmail.com (Emil Mikulic)
Date: Thu Sep  3 00:29:08 2009
Subject: siis/atacam/ata/gmirror 8.0-BETA3 disk performance
In-Reply-To: <367b2c980909020736i60b64563xc4fec6d11e3dae2b@mail.gmail.com>
References: <4A9E5F34.2090700@razorfever.net>
	<20090902141138.GA15045@dmr.ath.cx>
	<367b2c980909020736i60b64563xc4fec6d11e3dae2b@mail.gmail.com>
Message-ID: <20090903002856.GC17538@dmr.ath.cx>

On Wed, Sep 02, 2009 at 04:36:29PM +0200, Olivier Smedts wrote:
> 2009/9/2 Emil Mikulic <emikulic@gmail.com>:
> > Stripe will give you higher throughput.
> > Mirror will give you more random seeks per second.
> 
> And higher read throughput.

If you've got two streaming reads in parallel, and get lucky with disk
scheduling, you can get higher aggregate throughput.

But for the single linear scan that Derek and I have been benchmarking,
I don't see how mirror would give a higher read throughput.  Both disks
are spinning at the same speed and their heads are in the same
positions.

--Emil
From sweetnavelorange at gmail.com  Thu Sep  3 01:03:17 2009
From: sweetnavelorange at gmail.com (James Butler)
Date: Thu Sep  3 01:03:24 2009
Subject: Reducing noise in dmesg output
In-Reply-To: <200909021656.15747.nick@van-laarhoven.org>
References: <200909010931.16880.nick@van-laarhoven.org>
	<1251841416.1689.4458.camel@balrog.2hip.net>
	<200909021656.15747.nick@van-laarhoven.org>
Message-ID: <f0dd9eb90909021739o4d31c88l5be6638f7998dae6@mail.gmail.com>

2009/9/3 Nick Hibma <nick@van-laarhoven.org>:
>> What is irrelevant is subjective... ?I mean does the average user really
>> need to see anything in dmesg? ?Please don't change agp_i810.c. ?A
>> verbose boot is incredibly noisy and rarely needed for debugging
>> anything except the most deep rooted of issues.
>
> Please state arguments instead of this 'I think it is useful'. That's not
> going to cut it. If you feel strongly about the info that is being produced,
> an option would be to produce a (tested!) patch that combines more
> information on one line as a compromise.
>
> FreeBSD has historically been producing very limited output on dmesg. Linux
> is very noisy (ever noticed the copyright notices right in the middle of
> your list of PCI devices?). Even they have decided that they should hide
> this behind coloured 'ok/failed' texts in some distributions.

This seems like an important distinction - the information which needs
to be available with dmesg and the information best shown to the user
at startup are not necessarily the same. The hypothetical "average
user" probably wouldn't care if there were *no* kernel messages shown
on startup. The Xubuntu box I'm writing this from shows only GRUB
messages before the login prompt on tty1, and only service startup
messages on tty8 (not to suggest that FreeBSD ought to be more like
Ubuntu...).

IOW, why bother painting it at all? Plain galvanized steel is very
durable, and quite attractive when kept clean ;-)

-James Butler
From jrh29 at alumni.cwru.edu  Thu Sep  3 01:14:33 2009
From: jrh29 at alumni.cwru.edu (Justin Hibbits)
Date: Thu Sep  3 01:14:40 2009
Subject: Reducing noise in dmesg output
In-Reply-To: <f0dd9eb90909021739o4d31c88l5be6638f7998dae6@mail.gmail.com>
References: <200909010931.16880.nick@van-laarhoven.org>
	<1251841416.1689.4458.camel@balrog.2hip.net>
	<200909021656.15747.nick@van-laarhoven.org>
	<f0dd9eb90909021739o4d31c88l5be6638f7998dae6@mail.gmail.com>
Message-ID: <fd9cd3450909021814i41dec476v42c8f23b1d5684e@mail.gmail.com>

On Wed, Sep 2, 2009 at 8:39 PM, James Butler <sweetnavelorange@gmail.com>wrote:

> 2009/9/3 Nick Hibma <nick@van-laarhoven.org>:
> >> What is irrelevant is subjective...  I mean does the average user really
> >> need to see anything in dmesg?  Please don't change agp_i810.c.  A
> >> verbose boot is incredibly noisy and rarely needed for debugging
> >> anything except the most deep rooted of issues.
> >
> > Please state arguments instead of this 'I think it is useful'. That's not
> > going to cut it. If you feel strongly about the info that is being
> produced,
> > an option would be to produce a (tested!) patch that combines more
> > information on one line as a compromise.
> >
> > FreeBSD has historically been producing very limited output on dmesg.
> Linux
> > is very noisy (ever noticed the copyright notices right in the middle of
> > your list of PCI devices?). Even they have decided that they should hide
> > this behind coloured 'ok/failed' texts in some distributions.
>
> This seems like an important distinction - the information which needs
> to be available with dmesg and the information best shown to the user
> at startup are not necessarily the same. The hypothetical "average
> user" probably wouldn't care if there were *no* kernel messages shown
> on startup. The Xubuntu box I'm writing this from shows only GRUB
> messages before the login prompt on tty1, and only service startup
> messages on tty8 (not to suggest that FreeBSD ought to be more like
> Ubuntu...).
>
> IOW, why bother painting it at all? Plain galvanized steel is very
> durable, and quite attractive when kept clean ;-)
>
> -James Butler
>

Doesn't the 'boot_mute' (loader) environment variable do just that?

>From the man page:

     boot_mute
               All console output is suppressed when console is muted.  In a
               running system, the state of console muting can be
manipulated
               by the conscontrol(8) utility.

- Justin
From kientzle at freebsd.org  Thu Sep  3 05:01:54 2009
From: kientzle at freebsd.org (Tim Kientzle)
Date: Thu Sep  3 05:02:01 2009
Subject: Reducing noise in dmesg output
In-Reply-To: <2fd864e0909021645p735e22b8id7d41f4b5a0ee89e@mail.gmail.com>
References: <200909010931.16880.nick@van-laarhoven.org>	<1251841416.1689.4458.camel@balrog.2hip.net>	<200909021656.15747.nick@van-laarhoven.org>
	<2fd864e0909021645p735e22b8id7d41f4b5a0ee89e@mail.gmail.com>
Message-ID: <4A9F4DC1.4010002@freebsd.org>

>> FreeBSD has historically been producing very limited output on dmesg. Linux
>> is very noisy (ever noticed the copyright notices right in the middle of
>> your list of PCI devices?). Even they have decided that they should hide
>> this behind coloured 'ok/failed' texts in some distributions.
> 
> I think this speaks more towards needing something between "Very
> Quiet" and "Give me everything every developer has ever wanted to know
> enough to include a print for it."

Other possibilities:

  * Provide a per-driver control to determine verbosity.  That would 
make it easier for developers who really do want to see "everything 
there is to know in my part of the world".

  * Put more information into the kernel buffers (and from there into 
dmesg) and less on the screen.  That would reduce visible boot verbosity 
while retaining the post-hoc debugging value of dmesg(1).

Cheers,

Tim

From jakub_lach at mailplus.pl  Thu Sep  3 07:56:44 2009
From: jakub_lach at mailplus.pl (Jakub Lach)
Date: Thu Sep  3 07:56:51 2009
Subject: ahci cd0 issue
In-Reply-To: <4A9EA17C.2020204@FreeBSD.org>
References: <4A9E8F8A.1010004@icyb.net.ua> <4A9EA17C.2020204@FreeBSD.org>
Message-ID: <25271366.post@talk.nabble.com>




Alexander Motin-3 wrote:
> 
> Andriy Gapon wrote:
>> k3b did "something" to my cd0 while tasting it and after that IDE
>> activity LED was
>> constantly on and I got a never-ending stream of messages like the
>> following:
>> 
>> ahcich5: Timeout on slot 25
>> ahcich5: Timeout on slot 26
>> ahcich5: Timeout on slot 29
>> ahcich5: Timeout on slot 30
>> ahcich5: Timeout on slot 1
>> ahcich5: Timeout on slot 2
>> ahcich5: Timeout on slot 5
>> ahcich5: Timeout on slot 6
>> ahcich5: Timeout on slot 9
>> ahcich5: Timeout on slot 10
>> ...
>> and so on.
>> cd0 is on ahcich5.
>> 
>> This is head r196558.
> 
> I don't know what initially caused the problem, but new ATA-CAM 
> infrastructure is still lacks of proper timeout error recovery. It is 
> not easy part, but I am working on it.
> 
> -- 
> Alexander Motin
> _______________________________________________
> 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"
> 
> 

Hello.

One more thing, smartmontools also refuse to work.

(non ATA/ATAPI device)

All ports I mentioned were rebuilt.

As it's WIP, I understand that this should be expected.

-best regards, 
Jakub Lach
-- 
View this message in context: http://www.nabble.com/ahci-cd0-issue-tp25259873p25271366.html
Sent from the freebsd-current mailing list archive at Nabble.com.

From jakub_lach at mailplus.pl  Thu Sep  3 09:03:53 2009
From: jakub_lach at mailplus.pl (Jakub Lach)
Date: Thu Sep  3 09:04:00 2009
Subject: ahci cd0 issue
In-Reply-To: <25265998.post@talk.nabble.com>
References: <4A9E8F8A.1010004@icyb.net.ua> <4A9EA17C.2020204@FreeBSD.org>
	<25265998.post@talk.nabble.com>
Message-ID: <25272244.post@talk.nabble.com>




Jakub Lach wrote:
> 
> 
> cdda2wav as well..
> 
> cdda2wav: Error 0. inquiry: scsi sendcmd: fatal error
> CDB:  12 E0 00 00 24 00
> cmd finished after 0.000s timeout 60s
> Inquiry command failed. Aborting...
> 

My fault, cooked icotl is not working, with -D 1,0,0
cdda2wav works.

-best regards, 
Jakub Lach

-- 
View this message in context: http://www.nabble.com/ahci-cd0-issue-tp25259873p25272244.html
Sent from the freebsd-current mailing list archive at Nabble.com.

From nick-lists at netability.ie  Thu Sep  3 09:30:52 2009
From: nick-lists at netability.ie (Nick Hilliard)
Date: Thu Sep  3 09:30:59 2009
Subject: 8.0-beta3 does not detect several ata channels
In-Reply-To: <4A9E5D4B.1020801@netability.ie>
References: <4A9BF23F.6070801@netability.ie> <4A9BF438.1000006@smeets.im>
	<200909011002.59592.jhb@freebsd.org>
	<4A9E5D4B.1020801@netability.ie>
Message-ID: <4A9F8CC7.7020907@netability.ie>

On 02/09/2009 12:55, Nick Hilliard wrote:
> hmmm, the box won't boot when i use mcfg=1. I'll take a look at the
> console message tomorrow or friday.

meh, setting hw.pci.mcfg=1 on 7-stable changes the disk labels so that the 
machine crashes out into mountroot>.  However it also kills the keyboard, 
meaning I can't manually mount the root fs.

Nick
From rwatson at FreeBSD.org  Thu Sep  3 09:38:21 2009
From: rwatson at FreeBSD.org (Robert Watson)
Date: Thu Sep  3 09:38:31 2009
Subject: Reducing noise in dmesg output
In-Reply-To: <4A9F4DC1.4010002@freebsd.org>
References: <200909010931.16880.nick@van-laarhoven.org>
	<1251841416.1689.4458.camel@balrog.2hip.net>
	<200909021656.15747.nick@van-laarhoven.org>
	<2fd864e0909021645p735e22b8id7d41f4b5a0ee89e@mail.gmail.com>
	<4A9F4DC1.4010002@freebsd.org>
Message-ID: <alpine.BSF.2.00.0909031035260.36214@fledge.watson.org>

On Wed, 2 Sep 2009, Tim Kientzle wrote:

>>> FreeBSD has historically been producing very limited output on dmesg. 
>>> Linux is very noisy (ever noticed the copyright notices right in the 
>>> middle of your list of PCI devices?). Even they have decided that they 
>>> should hide this behind coloured 'ok/failed' texts in some distributions.
>> 
>> I think this speaks more towards needing something between "Very Quiet" and 
>> "Give me everything every developer has ever wanted to know enough to 
>> include a print for it."
>
> Other possibilities:
>
> * Provide a per-driver control to determine verbosity.  That would make it 
> easier for developers who really do want to see "everything there is to know 
> in my part of the world".
>
> * Put more information into the kernel buffers (and from there into dmesg) 
> and less on the screen.  That would reduce visible boot verbosity while 
> retaining the post-hoc debugging value of dmesg(1).

It's clear that part of the problem we're dealing with here is that dmesg 
remains the authoritative source for certain kinds of data that really should 
be in a machine-readable/reportable format.  devinfo(8) captures some of this, 
but can't, for example, cleanly represent an IRQ being shared by multiple 
devices, and doesn't capture a lot of the device-driver specific data that 
appears in dmesg.

dmesg is a useful log of events, and I'm not saying we should omit information 
there, but when inspecting the current state of the system, the kernel has a 
lot of information and it would be nice if more of it were accessible in 
userspace.

To my mind, the main reason to look at dmesg should be to find out about 
*failed* device attaches, where there most likely won't be persisting state in 
the kernel, but the debugging information is invaluable.

Robert N M Watson
Computer Laboratory
University of Cambridge
From unixwind at gmail.com  Thu Sep  3 15:11:24 2009
From: unixwind at gmail.com (Felix Feng)
Date: Thu Sep  3 15:11:30 2009
Subject: WEP can not work on mwl driver
Message-ID: <260f7f810909030748q7cb0878bq6f1b3fb3fbae307a@mail.gmail.com>

Hi,

I'm trying mwl driver on FreeBSD current. But its WEP encryption does not
work well. When I connect to a WEP AP, the driver can not get IP under DHCP
and static IP does not work. Does anyone has the same issue as me?

------
Regards,
Felix
From avg at icyb.net.ua  Thu Sep  3 15:25:14 2009
From: avg at icyb.net.ua (Andriy Gapon)
Date: Thu Sep  3 15:25:23 2009
Subject: Reducing noise in dmesg output
In-Reply-To: <alpine.BSF.2.00.0909031035260.36214@fledge.watson.org>
References: <200909010931.16880.nick@van-laarhoven.org>	<1251841416.1689.4458.camel@balrog.2hip.net>	<200909021656.15747.nick@van-laarhoven.org>	<2fd864e0909021645p735e22b8id7d41f4b5a0ee89e@mail.gmail.com>	<4A9F4DC1.4010002@freebsd.org>
	<alpine.BSF.2.00.0909031035260.36214@fledge.watson.org>
Message-ID: <4A9FDFD6.2090305@icyb.net.ua>

on 03/09/2009 12:38 Robert Watson said the following:
[snip]
> devinfo(8)
> captures some of this, but can't, for example, cleanly represent an IRQ
> being shared by multiple devices
[snip]

Minor technical nit - devinfo can actually do it (since r192379).

-- 
Andriy Gapon
From rwatson at FreeBSD.org  Thu Sep  3 15:46:59 2009
From: rwatson at FreeBSD.org (Robert Watson)
Date: Thu Sep  3 15:47:23 2009
Subject: Reducing noise in dmesg output
In-Reply-To: <4A9FDFD6.2090305@icyb.net.ua>
References: <200909010931.16880.nick@van-laarhoven.org>
	<1251841416.1689.4458.camel@balrog.2hip.net>
	<200909021656.15747.nick@van-laarhoven.org>
	<2fd864e0909021645p735e22b8id7d41f4b5a0ee89e@mail.gmail.com>
	<4A9F4DC1.4010002@freebsd.org>
	<alpine.BSF.2.00.0909031035260.36214@fledge.watson.org>
	<4A9FDFD6.2090305@icyb.net.ua>
Message-ID: <alpine.BSF.2.00.0909031645560.81808@fledge.watson.org>

University of Cambridge

On Thu, 3 Sep 2009, Andriy Gapon wrote:

> on 03/09/2009 12:38 Robert Watson said the following: [snip]
>> devinfo(8) captures some of this, but can't, for example, cleanly represent 
>> an IRQ being shared by multiple devices
> [snip]
>
> Minor technical nit - devinfo can actually do it (since r192379).

I stand pleasantly corrected :-).  However, I think the point holds: we're 
relying on dmesg as the authoritative source of hardware discovery/probe 
information, and really, we should be using some more structured way of 
delivering that information, generic or device-specific.

Robert N M Watson
Computer Laboratory
University of Cambridge
From avg at icyb.net.ua  Thu Sep  3 15:54:21 2009
From: avg at icyb.net.ua (Andriy Gapon)
Date: Thu Sep  3 15:54:27 2009
Subject: Reducing noise in dmesg output
In-Reply-To: <alpine.BSF.2.00.0909031645560.81808@fledge.watson.org>
References: <200909010931.16880.nick@van-laarhoven.org>
	<1251841416.1689.4458.camel@balrog.2hip.net>
	<200909021656.15747.nick@van-laarhoven.org>
	<2fd864e0909021645p735e22b8id7d41f4b5a0ee89e@mail.gmail.com>
	<4A9F4DC1.4010002@freebsd.org>
	<alpine.BSF.2.00.0909031035260.36214@fledge.watson.org>
	<4A9FDFD6.2090305@icyb.net.ua>
	<alpine.BSF.2.00.0909031645560.81808@fledge.watson.org>
Message-ID: <4A9FE6A9.2070009@icyb.net.ua>

on 03/09/2009 18:46 Robert Watson said the following:
> I stand pleasantly corrected :-).  However, I think the point holds:
> we're relying on dmesg as the authoritative source of hardware
> discovery/probe information, and really, we should be using some more
> structured way of delivering that information, generic or device-specific.

Yes, I do agree.
And - I can't explain why - this conversation reminded me of the sensors framework
project. I expect a long discussion on the structure and access mechanism for such
information.

-- 
Andriy Gapon
From sam at errno.com  Thu Sep  3 17:36:50 2009
From: sam at errno.com (Sam Leffler)
Date: Thu Sep  3 17:36:56 2009
Subject: WEP can not work on mwl driver
In-Reply-To: <260f7f810909030748q7cb0878bq6f1b3fb3fbae307a@mail.gmail.com>
References: <260f7f810909030748q7cb0878bq6f1b3fb3fbae307a@mail.gmail.com>
Message-ID: <4A9FFEB0.4000201@errno.com>

Felix Feng wrote:
> Hi,
> 
> I'm trying mwl driver on FreeBSD current. But its WEP encryption does not
> work well. When I connect to a WEP AP, the driver can not get IP under DHCP
> and static IP does not work. Does anyone has the same issue as me?

I doubt anyone else has a card.  Please contact me off-line w/ the steps 
to reproduce the problem.  There's also some tools in tools/tools/mwl 
that you might find useful in debugging.

	Sam
From rhurlin at gwdg.de  Thu Sep  3 17:37:59 2009
From: rhurlin at gwdg.de (Rainer Hurling)
Date: Thu Sep  3 17:39:45 2009
Subject: 8.0-beta3 does not detect several ata channels
In-Reply-To: <200909011717.57386.jhb@freebsd.org>
References: <4A9BF23F.6070801@netability.ie>
	<200909011505.32243.jhb@freebsd.org> <4A9D86C9.1020603@gwdg.de>
	<200909011717.57386.jhb@freebsd.org>
Message-ID: <4A9FFEF0.1000502@gwdg.de>

On 01.09.2009 23:17 (UTC+2), John Baldwin wrote:
> On Tuesday 01 September 2009 4:40:41 pm Rainer Hurling wrote:
>> On 01.09.2009 21:05 (UTC+2), John Baldwin wrote:
>>> On Tuesday 01 September 2009 2:49:09 pm Rainer Hurling wrote:
>>>> On 01.09.2009 19:41 (UTC+2), John Baldwin wrote:
>>>>> On Tuesday 01 September 2009 12:47:50 pm Rainer Hurling wrote:
>>>>>> On 01.09.2009 16:02 (UTC+2), John Baldwin wrote:
>>>>>>> On Monday 31 August 2009 12:03:04 pm Florian Smeets wrote:
>>>>>>>> On 8/31/09 5:54 PM, Nick Hilliard wrote:
>>>>>>>>> Hi,
>>>>>>>>>
>>>>>>>>> I have a hp proliant ML115 with 6 sata ports which run in ATA mode 
>>> (bios
>>>>>>>>> doesn't appear to give the option to use AHCI).  On freebsd 7.x, all
>>>>>>>>> channels are detected.  On freebsd8.0-beta3, the disks attached to 
> the
>>>>>>>>> first two SATA ports are not detected, although it detects the ports
>>>>>>>>> themselves.
>>>>>>>>>
>>>>>>>>> I've attached a verbose dmesg from freebsd 7.1 and 8.0-beta3.
>>>>>>>>>
>>>>>>>>> Any ideas on what's going on here?  This seems like a nasty 
>>> regression.
>>>>>>>> There are 3 PRs about this problem: 128686, 132372, 137942.
>>>>>>>>
>>>>>>>> i386 version should recognize the disks. amd64 does when you set
>>>>>>>> hw.pci.mcfg=0 in loader.conf.
>>>>>>> Hmm, so an idea I had just now.. can you grab a dump of the PCI config 
>>>>> space 
>>>>>>> for the disk controller in the MCFG vs non-MCFG cases?  That is, find 
>>> the 
>>>>>>> device's address using pciconf -lv (e.g. pci0:0:30:0 or some such) and 
>>>>> then 
>>>>>>> run this command under both configurations and save the output:
>>>>>>>
>>>>>>> pciconf -r pci0:0:30:0 0:0xfc
>>>>>>>
>>>>>> I am not sure if your idea has something to do with my (and some other 
>>>>>> users) problem. So excuse me, if this posting is wrong.
>>>>>>
>>>>>> For some month now I am only able to boot CURRENT under amd64 with 
>>>>>> setting hw.pci.mcfg=0. Under i386 all works fine. Below I listed output 
>>>>>> under i386 and under amd64. Perhaps you are able to get a hint?
>>>>> Hmm, would you be able to boot with mcfg=1 on amd64 (perhaps using 
> nfsroot 
>>> or 
>>>>> an mfsroot) and capture this output?  The mcfg thing only affects access 
>>> to
>>>>> PCI config space (what pciconf -r is displaying).  I want to be able to 
>>>>> compare the "broken" case (amd64 mcfg=1) with a working case.
>>>> My only amd64 system is at home. Sorry, but I have no idea how to start 
>>>> this system using nfsroot oder mfsroot.
>>> Ok, I believe some of the other folks reporting an issue with this ATA 
>>> controller had other disk controllers in the system so they may be able to 
> do 
>>> this.
>> Thanks to Kostik Belousov, I tried his hint with live CD. Here it is, 
>> only for amd64, with snapshot from todays CURRENT:
>>
>> #systctl hw.pci.mcfg
>> hw.pci.mcfg: 1
> 
> Hmm, this one is identical to the mcfg=0 one on amd64 (except for a few values 
> that also differ between the working i386 and working amd64).  So it doesn't 
> seem that PCI config access is horribly broken. :(  Perhaps someone can spend 
> some time comparing what the driver does in the two cases with some printfs 
> to see when it starts behaving differently during its attach routine to help 
> narrow this down.
> 

Is there any meaning in the differences of pciconf -lv output of i386 
and amd64 (already shown in older postings)?

-------------------------------------------
i386:
atapci1@pci0:0:5:0:     class=0x010185 card=0x72601462 chip=0x037f10de 
rev=0xa2 hdr=0x00
     vendor     = 'Nvidia Corp'
     device     = 'MCP55 SATA/RAID Controller (MCP55S)'
     class      = mass storage
     subclass   = ATA
atapci2@pci0:0:5:1:     class=0x010185 card=0x72601462 chip=0x037f10de
rev=0xa2 hdr=0x00
     vendor     = 'Nvidia Corp'
     device     = 'MCP55 SATA/RAID Controller (MCP55S)'
     class      = mass storage
     subclass   = ATA
-------------------------------------------
amd64:
atapci1@pci0:0:5:0:     class=0x010185 card=0x72601462 chip=0x037f10de 
rev=0xa2 hdr=0x00
     class      = mass storage
     subclass   = ATA
atapci2@pci0:0:5:1:     class=0x010185 card=0x72601462 chip=0x037f10de 
rev=0xa2 hdr=0x00
     class      = mass storage
     subclass   = ATA
-------------------------------------------

In the amd64 version there is no vendor and device string. Perhaps a 
problem of reading or interpreting?

Rainer Hurling
From webmaster at doghouserepair.com  Thu Sep  3 18:01:13 2009
From: webmaster at doghouserepair.com (Ryan Rogers)
Date: Thu Sep  3 18:01:20 2009
Subject: non aligned DMA transfer attempted
Message-ID: <4AA00128.5030008@doghouserepair.com>

I'm having a bit of a problem getting my DVD drive(s) to work correctly. 
  I'm trying to transfer my DVD collection to my media server, but 
whenever I run vobcopy, /var/log/messages gets spammed with:

acd0: FAILURE - non aligned DMA transfer attempted
acd0: setting up DMA failed

I added a bit more information to the first message to see if I could 
figure out what was actually going on.  request->data was 0xd40e0c37, 
ch->dma.alignment was 2, and request->bytecount was 2048.

My first guess was that my DVD drive was starting to flake out, so I 
bought another one in the hopes that it would fix it, but that wasn't 
the problem.  The drives that I've tried are:

DVDR <NEC DVD RW ND-3500AG/2.FD> at ata0-slave UDMA33
DVDR <TSSTcorp CDDVDW SH-S223L/SB02> at ata6-master SATA150

The ata controllers are detected as:

atapci0: <nVidia nForce MCP55 UDMA133 controller> port 
0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xec00-0xec0f at device 13.0 on pci0
ata0: <ATA channel 0> on atapci0
ata0: [ITHREAD]
ata1: <ATA channel 1> on atapci0
ata1: [ITHREAD]
atapci1: <nVidia nForce MCP55 SATA300 controller> port 
0x9f0-0x9f7,0xbf0-0xbf3,0x970-0x977,0xb70-0xb73,0xd800-0xd80f mem 
0xcfffd000-0xcfffdfff irq 20 at device 14.0 on pci0
atapci1: [ITHREAD]
ata2: <ATA channel 0> on atapci1
ata2: [ITHREAD]
ata3: <ATA channel 1> on atapci1
ata3: [ITHREAD]
atapci2: <nVidia nForce MCP55 SATA300 controller> port 
0x9e0-0x9e7,0xbe0-0xbe3,0x960-0x967,0xb60-0xb63,0xc400-0xc40f mem 
0xcfffc000-0xcfffcfff irq 21 at device 14.1 on pci0
atapci2: [ITHREAD]
ata4: <ATA channel 0> on atapci2
ata4: [ITHREAD]
ata5: <ATA channel 1> on atapci2
ata5: [ITHREAD]
atapci3: <nVidia nForce MCP55 SATA300 controller> port 
0xc000-0xc007,0xbc00-0xbc03,0xb800-0xb807,0xb400-0xb403,0xb000-0xb00f 
mem 0xcfffb000-0xcfffbfff irq 20 at device 14.2 on pci0
atapci3: [ITHREAD]
ata6: <ATA channel 0> on atapci3
ata6: [ITHREAD]
ata7: <ATA channel 1> on atapci3
ata7: [ITHREAD]

Setting hw.ata.ata_dma and hw.ata.atapi_dma to 0 doesn't help any. 
General drive usage (browsing through the contents of the DVD, watching 
a movie with VLC) doesn't give the DMA errors.  I'm currently using 
8.0-BETA3 r196774 i386.  Any suggestions?

Ryan

From mav at FreeBSD.org  Thu Sep  3 18:13:58 2009
From: mav at FreeBSD.org (Alexander Motin)
Date: Thu Sep  3 18:14:11 2009
Subject: gmirror 'load' algorithm (Was: Re: siis/atacam/ata/gmirror 8.0-BETA3
 disk performance)
In-Reply-To: <20090903002106.GB17538@dmr.ath.cx>
References: <h7lmvl$ebq$1@FreeBSD.cs.nctu.edu.tw>
	<4A9E8677.1020208@FreeBSD.org> <20090903002106.GB17538@dmr.ath.cx>
Message-ID: <4AA0075A.5010109@FreeBSD.org>

Emil Mikulic wrote:
> On Wed, Sep 02, 2009 at 05:51:35PM +0300, Alexander Motin wrote:
>> To completely load gmirror on read operations, you may need to run
>> two dd's same time. Also make sure, that your gmirror runs in
>> round-robin mode. Default split mode, which should help with linear
>> read, is IMHO ineffective, at least with default MAXPHYS and slice
>> values.
> 
> On that note, there is an excellent patch in this PR which improves
> the way gmirror schedules read requests to different disks:
> 
> http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/113885
> 
> Could someone please commit this?
> 
> With this patch and a two-way mirror, I can run two linear scans of
> different files in parallel and get almost perfect scaling.  (result:
> this approximately halves the wall-clock time it takes to do a backup of
> some fat VM images)
> 
> IIRC, without the patch it's faster to run them sequentially.  :(

I have played a bit with this patch on 4-disk mirror. It works better 
then original algorithm, but still not perfect.

1. I have managed situation with 4 read streams when 3 drives were busy, 
while forth one was completely idle. gmirror prefer constantly seek one 
of drives on short distances, but not to use idle drive, because it's 
heads were few gigabytes away from that point.

IMHO request locality priority should be made almost equal for any 
nonzero distances. As we can see with split mode, even small gaps 
between requests can significantly reduce drive performance. So I think 
it is not so important if data are 100MB or 500GB away from current head 
position. It is perfect case when requests are completely sequential. 
But everything beyond few megabytes from current position just won't fit 
drive cache.

2. IMHO it would be much better to use averaged request queue depth as 
load measure, instead of last request submit time. Request submit time 
works fine only for equal requests, equal drives and serialized load, 
but it is actually the case where complicated load balancing is just not 
needed. The fact that some drive just got request does not mean 
anything, if some another one got 50 requests one second ago and still 
processes them.

-- 
Alexander Motin
From jhb at freebsd.org  Thu Sep  3 18:38:42 2009
From: jhb at freebsd.org (John Baldwin)
Date: Thu Sep  3 18:38:59 2009
Subject: 8.0-beta3 does not detect several ata channels
In-Reply-To: <4A9FFEF0.1000502@gwdg.de>
References: <4A9BF23F.6070801@netability.ie>
	<200909011717.57386.jhb@freebsd.org> <4A9FFEF0.1000502@gwdg.de>
Message-ID: <200909031401.08825.jhb@freebsd.org>

On Thursday 03 September 2009 1:37:52 pm Rainer Hurling wrote:
> On 01.09.2009 23:17 (UTC+2), John Baldwin wrote:
> > On Tuesday 01 September 2009 4:40:41 pm Rainer Hurling wrote:
> >> On 01.09.2009 21:05 (UTC+2), John Baldwin wrote:
> >>> On Tuesday 01 September 2009 2:49:09 pm Rainer Hurling wrote:
> >>>> On 01.09.2009 19:41 (UTC+2), John Baldwin wrote:
> >>>>> On Tuesday 01 September 2009 12:47:50 pm Rainer Hurling wrote:
> >>>>>> On 01.09.2009 16:02 (UTC+2), John Baldwin wrote:
> >>>>>>> On Monday 31 August 2009 12:03:04 pm Florian Smeets wrote:
> >>>>>>>> On 8/31/09 5:54 PM, Nick Hilliard wrote:
> >>>>>>>>> Hi,
> >>>>>>>>>
> >>>>>>>>> I have a hp proliant ML115 with 6 sata ports which run in ATA mode 
> >>> (bios
> >>>>>>>>> doesn't appear to give the option to use AHCI).  On freebsd 7.x, 
all
> >>>>>>>>> channels are detected.  On freebsd8.0-beta3, the disks attached to 
> > the
> >>>>>>>>> first two SATA ports are not detected, although it detects the 
ports
> >>>>>>>>> themselves.
> >>>>>>>>>
> >>>>>>>>> I've attached a verbose dmesg from freebsd 7.1 and 8.0-beta3.
> >>>>>>>>>
> >>>>>>>>> Any ideas on what's going on here?  This seems like a nasty 
> >>> regression.
> >>>>>>>> There are 3 PRs about this problem: 128686, 132372, 137942.
> >>>>>>>>
> >>>>>>>> i386 version should recognize the disks. amd64 does when you set
> >>>>>>>> hw.pci.mcfg=0 in loader.conf.
> >>>>>>> Hmm, so an idea I had just now.. can you grab a dump of the PCI 
config 
> >>>>> space 
> >>>>>>> for the disk controller in the MCFG vs non-MCFG cases?  That is, 
find 
> >>> the 
> >>>>>>> device's address using pciconf -lv (e.g. pci0:0:30:0 or some such) 
and 
> >>>>> then 
> >>>>>>> run this command under both configurations and save the output:
> >>>>>>>
> >>>>>>> pciconf -r pci0:0:30:0 0:0xfc
> >>>>>>>
> >>>>>> I am not sure if your idea has something to do with my (and some 
other 
> >>>>>> users) problem. So excuse me, if this posting is wrong.
> >>>>>>
> >>>>>> For some month now I am only able to boot CURRENT under amd64 with 
> >>>>>> setting hw.pci.mcfg=0. Under i386 all works fine. Below I listed 
output 
> >>>>>> under i386 and under amd64. Perhaps you are able to get a hint?
> >>>>> Hmm, would you be able to boot with mcfg=1 on amd64 (perhaps using 
> > nfsroot 
> >>> or 
> >>>>> an mfsroot) and capture this output?  The mcfg thing only affects 
access 
> >>> to
> >>>>> PCI config space (what pciconf -r is displaying).  I want to be able 
to 
> >>>>> compare the "broken" case (amd64 mcfg=1) with a working case.
> >>>> My only amd64 system is at home. Sorry, but I have no idea how to start 
> >>>> this system using nfsroot oder mfsroot.
> >>> Ok, I believe some of the other folks reporting an issue with this ATA 
> >>> controller had other disk controllers in the system so they may be able 
to 
> > do 
> >>> this.
> >> Thanks to Kostik Belousov, I tried his hint with live CD. Here it is, 
> >> only for amd64, with snapshot from todays CURRENT:
> >>
> >> #systctl hw.pci.mcfg
> >> hw.pci.mcfg: 1
> > 
> > Hmm, this one is identical to the mcfg=0 one on amd64 (except for a few 
values 
> > that also differ between the working i386 and working amd64).  So it 
doesn't 
> > seem that PCI config access is horribly broken. :(  Perhaps someone can 
spend 
> > some time comparing what the driver does in the two cases with some 
printfs 
> > to see when it starts behaving differently during its attach routine to 
help 
> > narrow this down.
> > 
> 
> Is there any meaning in the differences of pciconf -lv output of i386 
> and amd64 (already shown in older postings)?
> 
> -------------------------------------------
> i386:
> atapci1@pci0:0:5:0:     class=0x010185 card=0x72601462 chip=0x037f10de 
> rev=0xa2 hdr=0x00
>      vendor     = 'Nvidia Corp'
>      device     = 'MCP55 SATA/RAID Controller (MCP55S)'
>      class      = mass storage
>      subclass   = ATA
> atapci2@pci0:0:5:1:     class=0x010185 card=0x72601462 chip=0x037f10de
> rev=0xa2 hdr=0x00
>      vendor     = 'Nvidia Corp'
>      device     = 'MCP55 SATA/RAID Controller (MCP55S)'
>      class      = mass storage
>      subclass   = ATA
> -------------------------------------------
> amd64:
> atapci1@pci0:0:5:0:     class=0x010185 card=0x72601462 chip=0x037f10de 
> rev=0xa2 hdr=0x00
>      class      = mass storage
>      subclass   = ATA
> atapci2@pci0:0:5:1:     class=0x010185 card=0x72601462 chip=0x037f10de 
> rev=0xa2 hdr=0x00
>      class      = mass storage
>      subclass   = ATA
> -------------------------------------------
> 
> In the amd64 version there is no vendor and device string. Perhaps a 
> problem of reading or interpreting?

No, the strings are pulled out of /usr/share/misc/pci_vendors based on the 
value in 'chip='.  Since the 'chip=' values are identical it's probably just 
a matter of having different versions of the pci_vendors file.  The only 
thing MCFG affects is how you read the 'chip=' number which are identical in 
the two cases.

-- 
John Baldwin
From lapo at lapo.it  Thu Sep  3 19:37:21 2009
From: lapo at lapo.it (Lapo Luchini)
Date: Thu Sep  3 19:37:28 2009
Subject: [Call For Testing] VirtualBox for FreeBSD! take 4
In-Reply-To: <20090527163952.GI1104@bsdcrew.de>
References: <20090527134343.GB1104@bsdcrew.de>	<85d001330905270909jde4d723s65e8708a8b498c29@mail.gmail.com>
	<20090527163952.GI1104@bsdcrew.de>
Message-ID: <4AA0149E.30209@lapo.it>

Martin Wilke wrote:
>> /usr/ports/devel/kBuild/work/kBuild-0.1.5-p1/kBuild/footer.kmk:2304: ***
>> target file `virtualbox' has both : and :: entries.
>> Stop                                                 .
>> kmk: Leaving directory `/usr/ports/devel/kBuild/work/kBuild-0.1.5-p1'
>> gmake: ***
>> [/usr/ports/devel/kBuild/work/kBuild-0.1.5-p1/out/freebsd.amd64/release/bootstrap/ts-stage2-build]
>> Error 2
>> ./kBuild/env.sh: info: rc=2: gmake -f bootstrap.gmk
>> *** Error code 2
> 
>> Stop in /usr/ports/devel/kBuild.
>> "
>
> Please update to 7.2 or higher

Errr, and what if I have that in a FreeBSD 7.2-STABLE?
Any other ideas? (both on my i386 laptop and amd64 home-server)

Strangely I can find nothing on Google for that, which seems to indicate
very little people is trying VirtualBox on FreeBSD or both my unrelated
and different boxes have got a "rare" bug =)

(but of course they got more or less the same mix of ports installed, so
they're not really unrelated one another)

-- 
Lapo Luchini - http://lapo.it/

??one of the main causes of the fall of the Roman Empire was that,
lacking zero, they had no way to indicate successful termination of
their C programs.? (Robert Firth)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 896 bytes
Desc: OpenPGP digital signature
Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20090903/8db22d63/signature.pgp
From rhurlin at gwdg.de  Thu Sep  3 19:40:12 2009
From: rhurlin at gwdg.de (Rainer Hurling)
Date: Thu Sep  3 19:40:20 2009
Subject: 8.0-beta3 does not detect several ata channels
In-Reply-To: <200909031401.08825.jhb@freebsd.org>
References: <4A9BF23F.6070801@netability.ie>
	<200909011717.57386.jhb@freebsd.org> <4A9FFEF0.1000502@gwdg.de>
	<200909031401.08825.jhb@freebsd.org>
Message-ID: <4AA01B94.8000309@gwdg.de>

On 03.09.2009 20:01 (UTC+2), John Baldwin wrote:
> On Thursday 03 September 2009 1:37:52 pm Rainer Hurling wrote:
>> On 01.09.2009 23:17 (UTC+2), John Baldwin wrote:
>>> On Tuesday 01 September 2009 4:40:41 pm Rainer Hurling wrote:
>>>> On 01.09.2009 21:05 (UTC+2), John Baldwin wrote:
>>>>> On Tuesday 01 September 2009 2:49:09 pm Rainer Hurling wrote:
>>>>>> On 01.09.2009 19:41 (UTC+2), John Baldwin wrote:
>>>>>>> On Tuesday 01 September 2009 12:47:50 pm Rainer Hurling wrote:
>>>>>>>> On 01.09.2009 16:02 (UTC+2), John Baldwin wrote:
>>>>>>>>> On Monday 31 August 2009 12:03:04 pm Florian Smeets wrote:
>>>>>>>>>> On 8/31/09 5:54 PM, Nick Hilliard wrote:
>>>>>>>>>>> Hi,
>>>>>>>>>>>
>>>>>>>>>>> I have a hp proliant ML115 with 6 sata ports which run in ATA mode 
>>>>> (bios
>>>>>>>>>>> doesn't appear to give the option to use AHCI).  On freebsd 7.x, 
> all
>>>>>>>>>>> channels are detected.  On freebsd8.0-beta3, the disks attached to 
>>> the
>>>>>>>>>>> first two SATA ports are not detected, although it detects the 
> ports
>>>>>>>>>>> themselves.
>>>>>>>>>>>
>>>>>>>>>>> I've attached a verbose dmesg from freebsd 7.1 and 8.0-beta3.
>>>>>>>>>>>
>>>>>>>>>>> Any ideas on what's going on here?  This seems like a nasty 
>>>>> regression.
>>>>>>>>>> There are 3 PRs about this problem: 128686, 132372, 137942.
>>>>>>>>>>
>>>>>>>>>> i386 version should recognize the disks. amd64 does when you set
>>>>>>>>>> hw.pci.mcfg=0 in loader.conf.
>>>>>>>>> Hmm, so an idea I had just now.. can you grab a dump of the PCI 
> config 
>>>>>>> space 
>>>>>>>>> for the disk controller in the MCFG vs non-MCFG cases?  That is, 
> find 
>>>>> the 
>>>>>>>>> device's address using pciconf -lv (e.g. pci0:0:30:0 or some such) 
> and 
>>>>>>> then 
>>>>>>>>> run this command under both configurations and save the output:
>>>>>>>>>
>>>>>>>>> pciconf -r pci0:0:30:0 0:0xfc
>>>>>>>>>
>>>>>>>> I am not sure if your idea has something to do with my (and some 
> other 
>>>>>>>> users) problem. So excuse me, if this posting is wrong.
>>>>>>>>
>>>>>>>> For some month now I am only able to boot CURRENT under amd64 with 
>>>>>>>> setting hw.pci.mcfg=0. Under i386 all works fine. Below I listed 
> output 
>>>>>>>> under i386 and under amd64. Perhaps you are able to get a hint?
>>>>>>> Hmm, would you be able to boot with mcfg=1 on amd64 (perhaps using 
>>> nfsroot 
>>>>> or 
>>>>>>> an mfsroot) and capture this output?  The mcfg thing only affects 
> access 
>>>>> to
>>>>>>> PCI config space (what pciconf -r is displaying).  I want to be able 
> to 
>>>>>>> compare the "broken" case (amd64 mcfg=1) with a working case.
>>>>>> My only amd64 system is at home. Sorry, but I have no idea how to start 
>>>>>> this system using nfsroot oder mfsroot.
>>>>> Ok, I believe some of the other folks reporting an issue with this ATA 
>>>>> controller had other disk controllers in the system so they may be able 
> to 
>>> do 
>>>>> this.
>>>> Thanks to Kostik Belousov, I tried his hint with live CD. Here it is, 
>>>> only for amd64, with snapshot from todays CURRENT:
>>>>
>>>> #systctl hw.pci.mcfg
>>>> hw.pci.mcfg: 1
>>> Hmm, this one is identical to the mcfg=0 one on amd64 (except for a few 
> values 
>>> that also differ between the working i386 and working amd64).  So it 
> doesn't 
>>> seem that PCI config access is horribly broken. :(  Perhaps someone can 
> spend 
>>> some time comparing what the driver does in the two cases with some 
> printfs 
>>> to see when it starts behaving differently during its attach routine to 
> help 
>>> narrow this down.
>>>
>> Is there any meaning in the differences of pciconf -lv output of i386 
>> and amd64 (already shown in older postings)?
>>
>> -------------------------------------------
>> i386:
>> atapci1@pci0:0:5:0:     class=0x010185 card=0x72601462 chip=0x037f10de 
>> rev=0xa2 hdr=0x00
>>      vendor     = 'Nvidia Corp'
>>      device     = 'MCP55 SATA/RAID Controller (MCP55S)'
>>      class      = mass storage
>>      subclass   = ATA
>> atapci2@pci0:0:5:1:     class=0x010185 card=0x72601462 chip=0x037f10de
>> rev=0xa2 hdr=0x00
>>      vendor     = 'Nvidia Corp'
>>      device     = 'MCP55 SATA/RAID Controller (MCP55S)'
>>      class      = mass storage
>>      subclass   = ATA
>> -------------------------------------------
>> amd64:
>> atapci1@pci0:0:5:0:     class=0x010185 card=0x72601462 chip=0x037f10de 
>> rev=0xa2 hdr=0x00
>>      class      = mass storage
>>      subclass   = ATA
>> atapci2@pci0:0:5:1:     class=0x010185 card=0x72601462 chip=0x037f10de 
>> rev=0xa2 hdr=0x00
>>      class      = mass storage
>>      subclass   = ATA
>> -------------------------------------------
>>
>> In the amd64 version there is no vendor and device string. Perhaps a 
>> problem of reading or interpreting?
> 
> No, the strings are pulled out of /usr/share/misc/pci_vendors based on the 
> value in 'chip='.  Since the 'chip=' values are identical it's probably just 
> a matter of having different versions of the pci_vendors file.  The only 
> thing MCFG affects is how you read the 'chip=' number which are identical in 
> the two cases.
> 
OK, I see. But on my system there are absolutely no differences between 
/usr/share/misc/pci_vendors of i386 and amd64.

From amvandemore at gmail.com  Thu Sep  3 20:14:48 2009
From: amvandemore at gmail.com (Adam Vande More)
Date: Thu Sep  3 20:15:00 2009
Subject: [Call For Testing] VirtualBox for FreeBSD! take 4
In-Reply-To: <4AA0149E.30209@lapo.it>
References: <20090527134343.GB1104@bsdcrew.de>
	<85d001330905270909jde4d723s65e8708a8b498c29@mail.gmail.com>
	<20090527163952.GI1104@bsdcrew.de> <4AA0149E.30209@lapo.it>
Message-ID: <6201873e0909031252r41bced2eqe1784a17214f1cd1@mail.gmail.com>

On Thu, Sep 3, 2009 at 2:10 PM, Lapo Luchini <lapo@lapo.it> wrote:

> Martin Wilke wrote:
> >> /usr/ports/devel/kBuild/work/kBuild-0.1.5-p1/kBuild/footer.kmk:2304: ***
> >> target file `virtualbox' has both : and :: entries.
> >> Stop                                                 .
> >> kmk: Leaving directory `/usr/ports/devel/kBuild/work/kBuild-0.1.5-p1'
> >> gmake: ***
> >>
> [/usr/ports/devel/kBuild/work/kBuild-0.1.5-p1/out/freebsd.amd64/release/bootstrap/ts-stage2-build]
> >> Error 2
> >> ./kBuild/env.sh: info: rc=2: gmake -f bootstrap.gmk
> >> *** Error code 2
> >
> >> Stop in /usr/ports/devel/kBuild.
> >> "
> >
> > Please update to 7.2 or higher
>
> Errr, and what if I have that in a FreeBSD 7.2-STABLE?
> Any other ideas? (both on my i386 laptop and amd64 home-server)
>
> Strangely I can find nothing on Google for that, which seems to indicate
> very little people is trying VirtualBox on FreeBSD or both my unrelated
> and different boxes have got a "rare" bug =)
>
> (but of course they got more or less the same mix of ports installed, so
> they're not really unrelated one another)
>
> --
> Lapo Luchini - http://lapo.it/
>
> ??one of the main causes of the fall of the Roman Empire was that,
> lacking zero, they had no way to indicate successful termination of
> their C programs.? (Robert Firth)
>
> Are you using portmaster to build virtualbox?


-- 
Adam Vande More
From mav at FreeBSD.org  Thu Sep  3 21:21:20 2009
From: mav at FreeBSD.org (Alexander Motin)
Date: Thu Sep  3 21:21:27 2009
Subject: non aligned DMA transfer attempted
In-Reply-To: <h7p0a3$k3m$1@FreeBSD.cs.nctu.edu.tw>
References: <h7p0a3$k3m$1@FreeBSD.cs.nctu.edu.tw>
Message-ID: <4AA03346.5010608@FreeBSD.org>

Ryan Rogers wrote:
> I'm having a bit of a problem getting my DVD drive(s) to work correctly. 
>   I'm trying to transfer my DVD collection to my media server, but 
> whenever I run vobcopy, /var/log/messages gets spammed with:
> 
> acd0: FAILURE - non aligned DMA transfer attempted
> acd0: setting up DMA failed
> 
> I added a bit more information to the first message to see if I could 
> figure out what was actually going on.  request->data was 0xd40e0c37, 
> ch->dma.alignment was 2, and request->bytecount was 2048.

Actually I don't understand what for this check was made there. It is 
busdma infrastructure business to implement buffer bouncing to manage 
requested alignment. But this check enforces application level to bother 
with this. Usually it works fine, as memory often allocated aligned. But 
probably here is some specifics in your application. Could you try to 
just to comment-out that request->data check?

-- 
Alexander Motin
From dillon at apollo.backplane.com  Thu Sep  3 22:20:46 2009
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Thu Sep  3 22:20:53 2009
Subject: non aligned DMA transfer attempted
References: <h7p0a3$k3m$1@FreeBSD.cs.nctu.edu.tw>
	<4AA03346.5010608@FreeBSD.org>
Message-ID: <200909032210.n83MA67F059073@apollo.backplane.com>

    This is a known problem with physio and/or the ATA driver, depending
    on your viewpoint.  See kern/kern_physio.c.

    The physio code directly maps the userland buffer via vmapbuf() and
    supplies it as a BIO to the device.  The ATA driver does not use
    BUSDMA (and never has)... it assumes BIOs are minimally aligned.

    But BIOs generated from kern_physio.c use user addresses directly and
    thus might only be byte-aligned.

    The CAM pass-through device has the same problem.

    The problem occurs most often when running a cd/dvd player or burner
    which declares operational structures it intends to read() or write()
    on the stack, sometimes even with char[] arrays.

    The solution I came up for with DFly was to implement bounce buffers
    manually in kern_physio.c and the CAM pass-through device for any
    user data that was not 16-byte aligned.  I considered implementing
    bounce buffers in all the disk drivers that were missing it but 
    there are other serious problems trying to bounce dma buffers that deep
    in the device hierarchy... you can hit low-memory deadlocks if the
    driver isn't written carefully enough (and most aren't).  The BUSDMA
    API has never been easy to work with for anyone trying to use the
    async data buffer bouncing load feature... most drivers just force it
    to run synchronously and thus hit the deadlock issues.

    I seem to recall that the same issue popped up a few months ago on
    these lists, too.

						-Matt
From mel.flynn+fbsd.current at mailing.thruhere.net  Thu Sep  3 22:35:45 2009
From: mel.flynn+fbsd.current at mailing.thruhere.net (Mel Flynn)
Date: Thu Sep  3 22:35:52 2009
Subject: non aligned DMA transfer attempted
In-Reply-To: <4AA03346.5010608@FreeBSD.org>
References: <h7p0a3$k3m$1@FreeBSD.cs.nctu.edu.tw>
	<4AA03346.5010608@FreeBSD.org>
Message-ID: <200909040035.41840.mel.flynn+fbsd.current@mailing.thruhere.net>

On Thursday 03 September 2009 23:21:10 Alexander Motin wrote:
> Ryan Rogers wrote:
> > I'm having a bit of a problem getting my DVD drive(s) to work correctly.
> >   I'm trying to transfer my DVD collection to my media server, but
> > whenever I run vobcopy, /var/log/messages gets spammed with:
> >
> > acd0: FAILURE - non aligned DMA transfer attempted
> > acd0: setting up DMA failed
> >
> > I added a bit more information to the first message to see if I could
> > figure out what was actually going on.  request->data was 0xd40e0c37,
> > ch->dma.alignment was 2, and request->bytecount was 2048.
>
> Actually I don't understand what for this check was made there. It is
> busdma infrastructure business to implement buffer bouncing to manage
> requested alignment. But this check enforces application level to bother
> with this. Usually it works fine, as memory often allocated aligned. But
> probably here is some specifics in your application. Could you try to
> just to comment-out that request->data check?

+1 on 7.2-STABLE machine, using cam layer. multimedia/handbrake is the 
offending app, that then keeps going into a loop requesting "title one of 8". 
If suspended, the app is not killable and reboot does not shut down the 
machine. Hard power off is needed.
Preceding the spam is:
kernel: (cd0:ata1:0:0:0): Media region code is mismatched to logical
 unit region

I've been assured there's no media region code mismatch (US DVD with US DVD-
ROM). Just reproduced with mplayer:

$ mplayer -vo null dvd://1
MPlayer 1.0rc2-4.2.1 (C) 2000-2007 MPlayer Team
CPU: AMD Athlon(tm) XP 3000+ (Family: 6, Model: 10, Stepping: 0)
CPUflags:  MMX: 1 MMX2: 1 3DNow: 1 3DNow2: 1 SSE: 1 SSE2: 0
Compiled with runtime CPU detection.

Playing dvd://1.
There are 8 titles on this DVD.
There are 31 chapters in this DVD title.
There are 1 angles in this DVD title.
audio stream: 0 format: ac3 (5.1) language: en aid: 128.
audio stream: 1 format: ac3 (5.1) language: fr aid: 129.
audio stream: 2 format: ac3 (5.1) language: es aid: 130.
number of audio channels on disk: 3.
subtitle ( sid ): 0 language: en
subtitle ( sid ): 1 language: fr
subtitle ( sid ): 2 language: es
subtitle ( sid ): 3 language: en
subtitle ( sid ): 4 language: fr
subtitle ( sid ): 5 language: es
number of subtitles on disk: 6

kernel: unknown: FAILURE - REPORT_KEY ILLEGAL REQUEST asc=0x6f ascq=0x04
kernel: (cd0:ata1:0:0:0): REPORT KEY. CDB: a4 0 0 0 12 ac 0 0 0 c 4 0
kernel: (cd0:ata1:0:0:0): CAM Status: SCSI Status Error
kernel: (cd0:ata1:0:0:0): SCSI Status: Check Condition
kernel: (cd0:ata1:0:0:0): ILLEGAL REQUEST asc:6f,4
kernel: (cd0:ata1:0:0:0): Media region code is mismatched to logical unit 
region
kernel: (cd0:ata1:0:0:0): Retrying Command (per Sense Data)
kernel: unknown: FAILURE - REPORT_KEY ILLEGAL REQUEST asc=0x6f ascq=0x04
kernel: (cd0:ata1:0:0:0): REPORT KEY. CDB: a4 0 0 0 12 ac 0 0 0 c 4 0
kernel: (cd0:ata1:0:0:0): CAM Status: SCSI Status Error
kernel: (cd0:ata1:0:0:0): SCSI Status: Check Condition
kernel: (cd0:ata1:0:0:0): ILLEGAL REQUEST asc:6f,4
kernel: (cd0:ata1:0:0:0): Media region code is mismatched to logical unit 
region
kernel: (cd0:ata1:0:0:0): Retries Exhausted
kernel: ata1: FAILURE - non aligned DMA transfer attempted
kernel: unknown: setting up DMA failed

The above system is a desktop with:
<HL-DT-ST DVD-ROM GDR8162B 0019>   at scbus3 target 0 lun 0 (probe0,pass4,cd0)

If needed, I can upgrade this system to stable/8, rather not upgrade it to 
head.
-- 
Mel
From roberthuff at rcn.com  Fri Sep  4 01:00:39 2009
From: roberthuff at rcn.com (Robert Huff)
Date: Fri Sep  4 01:00:46 2009
Subject: FIXED: HEAD newfs/sysinstall issues
In-Reply-To: <4A9C2A0E.4010203@rcn.com>
References: <4A9C2A0E.4010203@rcn.com>
Message-ID: <19104.26293.468518.603685@jerusalem.litteratus.org>


Me:

> About two weeks ago we had a discussion about my inability to
> complete an install because the partition/label part of sysinstall
> was getting confused.

	I found a work-around:

	when down with the label phase, instead of hotting 'q', hit 'w'
(which isn't listed as an option).  This will create the slices and
partitions, and further steps will work fine.


				Robert Huff

From lapo at lapo.it  Fri Sep  4 04:14:22 2009
From: lapo at lapo.it (Lapo Luchini)
Date: Fri Sep  4 04:14:35 2009
Subject: [Call For Testing] VirtualBox for FreeBSD! take 4
In-Reply-To: <6201873e0909031252r41bced2eqe1784a17214f1cd1@mail.gmail.com>
References: <20090527134343.GB1104@bsdcrew.de>	
	<85d001330905270909jde4d723s65e8708a8b498c29@mail.gmail.com>	
	<20090527163952.GI1104@bsdcrew.de> <4AA0149E.30209@lapo.it>
	<6201873e0909031252r41bced2eqe1784a17214f1cd1@mail.gmail.com>
Message-ID: <4AA09410.8020302@lapo.it>

Adam Vande More wrote:
>>>/usr/ports/devel/kBuild/work/kBuild-0.1.5-p1/kBuild/footer.kmk:2304: ***
>>> target file `virtualbox' has both : and :: entries.
>>>
>>> Please update to 7.2 or higher
>> 
>> Errr, and what if I have that in a FreeBSD 7.2-STABLE?
> 
> Are you using portmaster to build virtualbox?

Yes indeed... and now that you say it, I tried a simple
"cd emulators/virtualbox ; make install"
and it worked!

I wonder what does portmaster different to break only that specific port...

-- 
Lapo Luchini - http://lapo.it/

?Any sufficiently advanced technology is indistinguishable from magic.?
(Arthur C. Clarke)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 896 bytes
Desc: OpenPGP digital signature
Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20090904/e19b8583/signature.pgp
From webmaster at doghouserepair.com  Fri Sep  4 05:04:34 2009
From: webmaster at doghouserepair.com (Ryan Rogers)
Date: Fri Sep  4 05:04:40 2009
Subject: non aligned DMA transfer attempted
In-Reply-To: <4AA03346.5010608@FreeBSD.org>
References: <h7p0a3$k3m$1@FreeBSD.cs.nctu.edu.tw>
	<4AA03346.5010608@FreeBSD.org>
Message-ID: <4AA09FDF.2010307@doghouserepair.com>

Alexander Motin wrote:
> Ryan Rogers wrote:
>> I'm having a bit of a problem getting my DVD drive(s) to work 
>> correctly.   I'm trying to transfer my DVD collection to my media 
>> server, but whenever I run vobcopy, /var/log/messages gets spammed with:
>>
>> acd0: FAILURE - non aligned DMA transfer attempted
>> acd0: setting up DMA failed
>>
>> I added a bit more information to the first message to see if I could 
>> figure out what was actually going on.  request->data was 0xd40e0c37, 
>> ch->dma.alignment was 2, and request->bytecount was 2048.
> 
> Actually I don't understand what for this check was made there. It is 
> busdma infrastructure business to implement buffer bouncing to manage 
> requested alignment. But this check enforces application level to bother 
> with this. Usually it works fine, as memory often allocated aligned. But 
> probably here is some specifics in your application. Could you try to 
> just to comment-out that request->data check?
> 

I commented out that part of the check, and it worked in the sense that 
it didn't spit out any errors at me, but I'm not 100% certain that the 
data isn't getting corrupted.  I tried ripping two discs.  The first is 
completely corrupted, the second appears to be fine on first glance. 
I'm going to try a couple more discs to see if maybe the first one was 
just bad.

Also, one other thing that I noticed that seems odd is this:

acd0: DVDR <TSSTcorp CDDVDW SH-S223L/SB02> at ata6-master SATA150
....
cd0: <TSSTcorp CDDVDW SH-S223L SB02> Removable CD-ROM SCSI-0 device
cd0: 3.300MB/s transfers

I timed how long the first disc took to rip, and it seems to match that 
reported speed.  "Working but slow" is certainly better than "not 
working", but my speeds in Windows using DVD Decrypter on the same disk 
are at least 3 times faster, bursting up to about 5 times faster.

Ryan

From scottl at samsco.org  Fri Sep  4 05:31:19 2009
From: scottl at samsco.org (Scott Long)
Date: Fri Sep  4 05:31:25 2009
Subject: non aligned DMA transfer attempted
In-Reply-To: <200909032210.n83MA67F059073@apollo.backplane.com>
References: <h7p0a3$k3m$1@FreeBSD.cs.nctu.edu.tw>
	<4AA03346.5010608@FreeBSD.org>
	<200909032210.n83MA67F059073@apollo.backplane.com>
Message-ID: <A1B223C6-7291-4F86-B8AC-4EB5EF12F409@samsco.org>


On Sep 3, 2009, at 4:10 PM, Matthew Dillon wrote:

>    This is a known problem with physio and/or the ATA driver,  
> depending
>    on your viewpoint.  See kern/kern_physio.c.
>
>    The physio code directly maps the userland buffer via vmapbuf() and
>    supplies it as a BIO to the device.  The ATA driver does not use
>    BUSDMA (and never has)... it assumes BIOs are minimally aligned.
>

Wrong.

>    But BIOs generated from kern_physio.c use user addresses directly  
> and
>    thus might only be byte-aligned.
>
>    The CAM pass-through device has the same problem.
>

Huh?  Are you confused by the physaddr interface of CAM?

>    The problem occurs most often when running a cd/dvd player or  
> burner
>    which declares operational structures it intends to read() or  
> write()
>    on the stack, sometimes even with char[] arrays.
>
>    The solution I came up for with DFly was to implement bounce  
> buffers
>    manually in kern_physio.c and the CAM pass-through device for any
>    user data that was not 16-byte aligned.  I considered implementing
>    bounce buffers in all the disk drivers that were missing it but
>    there are other serious problems trying to bounce dma buffers  
> that deep
>    in the device hierarchy... you can hit low-memory deadlocks if the
>    driver isn't written carefully enough (and most aren't).  The  
> BUSDMA
>    API has never been easy to work with for anyone trying to use the
>    async data buffer bouncing load feature... most drivers just  
> force it
>    to run synchronously and thus hit the deadlock issues.
>

Wrong.

Scott

From ache at nagual.pp.ru  Fri Sep  4 05:56:13 2009
From: ache at nagual.pp.ru (Andrey Chernov)
Date: Fri Sep  4 05:56:20 2009
Subject: 'svn add' does not add 'svn:keywords', but 'svn ci' ask for it
Message-ID: <20090904055607.GA89117@nagual.pp.ru>

1) svn add some_file
2) svn ci some_file
svn: Commit blocked by pre-commit hook (exit code 1) with output:
Path ".../some_file" is missing the 
svn:keywords property (or an fbsd:nokeywords override)

I manage it adding by hand:
3) svn propset svn:keywords 'FreeBSD:%H' some_file

It isn't convenient. Why 'svn add' can't do it automatically for 
me using the same detection method as 'svn ci'? 
P.S. I use subversion-freebsd-1.6.5 port.

-- 
http://ache.pp.ru/
From ache at nagual.pp.ru  Fri Sep  4 06:28:55 2009
From: ache at nagual.pp.ru (Andrey Chernov)
Date: Fri Sep  4 06:29:01 2009
Subject: 'svn add' does not add 'svn:keywords', but 'svn ci' ask for it
In-Reply-To: <20090904055607.GA89117@nagual.pp.ru>
References: <20090904055607.GA89117@nagual.pp.ru>
Message-ID: <20090904062851.GA89703@nagual.pp.ru>

On Fri, Sep 04, 2009 at 09:56:07AM +0400, Andrey Chernov wrote:
> I manage it adding by hand:
> 3) svn propset svn:keywords 'FreeBSD:%H' some_file

Typo, 'FreeBSD=%H'

-- 
http://ache.pp.ru/
From devin at spamcop.net  Fri Sep  4 06:29:29 2009
From: devin at spamcop.net (Tod McQuillin)
Date: Fri Sep  4 06:29:36 2009
Subject: 'svn add' does not add 'svn:keywords', but 'svn ci' ask for it
In-Reply-To: <20090904055607.GA89117@nagual.pp.ru>
References: <20090904055607.GA89117@nagual.pp.ru>
Message-ID: <20090904150520.L1222@plexi.pun-pun.prv>

On Fri, 4 Sep 2009, Andrey Chernov wrote:

> 1) svn add some_file
> 2) svn ci some_file
> svn: Commit blocked by pre-commit hook (exit code 1) with output:
> Path ".../some_file" is missing the
> svn:keywords property (or an fbsd:nokeywords override)
>
> I manage it adding by hand:
> 3) svn propset svn:keywords 'FreeBSD:%H' some_file

Have a look at http://people.freebsd.org/~peter/auto-props.txt
-- 
Tod

From ache at nagual.pp.ru  Fri Sep  4 06:40:32 2009
From: ache at nagual.pp.ru (Andrey Chernov)
Date: Fri Sep  4 06:40:39 2009
Subject: 'svn add' does not add 'svn:keywords', but 'svn ci' ask for it
In-Reply-To: <20090904150520.L1222@plexi.pun-pun.prv>
References: <20090904055607.GA89117@nagual.pp.ru>
	<20090904150520.L1222@plexi.pun-pun.prv>
Message-ID: <20090904064028.GA89820@nagual.pp.ru>

On Fri, Sep 04, 2009 at 03:05:58PM +0900, Tod McQuillin wrote:
> On Fri, 4 Sep 2009, Andrey Chernov wrote:
> 
> > 1) svn add some_file
> > 2) svn ci some_file
> > svn: Commit blocked by pre-commit hook (exit code 1) with output:
> > Path ".../some_file" is missing the
> > svn:keywords property (or an fbsd:nokeywords override)
> >
> > I manage it adding by hand:
> > 3) svn propset svn:keywords 'FreeBSD:%H' some_file
> 
> Have a look at http://people.freebsd.org/~peter/auto-props.txt

Thanx, I already have ~/.subversion/config, but .src extention I use not 
listed there. Strange I don't hit this problem before.

-- 
http://ache.pp.ru/
From mav at FreeBSD.org  Fri Sep  4 06:50:51 2009
From: mav at FreeBSD.org (Alexander Motin)
Date: Fri Sep  4 06:50:58 2009
Subject: non aligned DMA transfer attempted
In-Reply-To: <4AA09FDF.2010307@doghouserepair.com>
References: <h7p0a3$k3m$1@FreeBSD.cs.nctu.edu.tw>
	<4AA03346.5010608@FreeBSD.org>
	<4AA09FDF.2010307@doghouserepair.com>
Message-ID: <4AA0B8C0.90604@FreeBSD.org>

Ryan Rogers wrote:
> Alexander Motin wrote:
>> Ryan Rogers wrote:
>>> I'm having a bit of a problem getting my DVD drive(s) to work 
>>> correctly.   I'm trying to transfer my DVD collection to my media 
>>> server, but whenever I run vobcopy, /var/log/messages gets spammed with:
>>>
>>> acd0: FAILURE - non aligned DMA transfer attempted
>>> acd0: setting up DMA failed
>>>
>>> I added a bit more information to the first message to see if I could 
>>> figure out what was actually going on.  request->data was 0xd40e0c37, 
>>> ch->dma.alignment was 2, and request->bytecount was 2048.
>>
>> Actually I don't understand what for this check was made there. It is 
>> busdma infrastructure business to implement buffer bouncing to manage 
>> requested alignment. But this check enforces application level to 
>> bother with this. Usually it works fine, as memory often allocated 
>> aligned. But probably here is some specifics in your application. 
>> Could you try to just to comment-out that request->data check?
> 
> I commented out that part of the check, and it worked in the sense that 
> it didn't spit out any errors at me, but I'm not 100% certain that the 
> data isn't getting corrupted.  I tried ripping two discs.  The first is 
> completely corrupted, the second appears to be fine on first glance. I'm 
> going to try a couple more discs to see if maybe the first one was just 
> bad.

Please.

> Also, one other thing that I noticed that seems odd is this:
> 
> acd0: DVDR <TSSTcorp CDDVDW SH-S223L/SB02> at ata6-master SATA150
> ....
> cd0: <TSSTcorp CDDVDW SH-S223L SB02> Removable CD-ROM SCSI-0 device
> cd0: 3.300MB/s transfers
> 
> I timed how long the first disc took to rip, and it seems to match that 
> reported speed.  "Working but slow" is certainly better than "not 
> working", but my speeds in Windows using DVD Decrypter on the same disk 
> are at least 3 times faster, bursting up to about 5 times faster.

It's just a small atapicam misfeature. It doesn't translates SATA modes 
to CAM speeds. It's only cosmetics, it shouldn't be important.

-- 
Alexander Motin
From peterjeremy at acm.org  Fri Sep  4 10:08:50 2009
From: peterjeremy at acm.org (peterjeremy@acm.org)
Date: Fri Sep  4 10:08:57 2009
Subject: Reducing noise in dmesg output
In-Reply-To: <f0dd9eb90909021739o4d31c88l5be6638f7998dae6@mail.gmail.com>
References: <200909010931.16880.nick@van-laarhoven.org>
	<1251841416.1689.4458.camel@balrog.2hip.net>
	<200909021656.15747.nick@van-laarhoven.org>
	<f0dd9eb90909021739o4d31c88l5be6638f7998dae6@mail.gmail.com>
Message-ID: <20090904100847.GA13167@server.vk2pj.dyndns.org>

On 2009-Sep-03 12:39:04 +1200, James Butler <sweetnavelorange@gmail.com> wrote:
>This seems like an important distinction - the information which needs
>to be available with dmesg and the information best shown to the user
>at startup are not necessarily the same.

Agreed.  And some rc.d scripts are also overly verbose - starting a
system with 150 virtual interfaces takes a significant amount of time
via a serial console.

> The hypothetical "average
>user" probably wouldn't care if there were *no* kernel messages shown
>on startup.

Whilst they mightn't care about the current probe/attach messages, it
is very reassuring for the kernel to show that it is actually doing
something.

> The Xubuntu box I'm writing this from shows only GRUB
>messages before the login prompt on tty1, and only service startup
>messages on tty8

Solaris is similar - leading to some nailchewing when rebooting after
a change: Does nothing being reported on the console for 2 minutes
mean that the kernel has gone off into limbo or it is just slowly
grinding through *something*?

Whilst SIGINFO helps once userland starts, I would not be comfortable
with a system that reported nothing between the boot loader and login
prompts.

-- 
Peter Jeremy
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20090904/51f1da66/attachment.pgp
From akm at theinternet.com.au  Fri Sep  4 10:16:39 2009
From: akm at theinternet.com.au (Andrew Milton)
Date: Fri Sep  4 10:16:46 2009
Subject: Reducing noise in dmesg output
In-Reply-To: <20090904100847.GA13167@server.vk2pj.dyndns.org>
References: <200909010931.16880.nick@van-laarhoven.org>
	<1251841416.1689.4458.camel@balrog.2hip.net>
	<200909021656.15747.nick@van-laarhoven.org>
	<f0dd9eb90909021739o4d31c88l5be6638f7998dae6@mail.gmail.com>
	<20090904100847.GA13167@server.vk2pj.dyndns.org>
Message-ID: <20090904101630.GA17207@camelot.theinternet.com.au>

+-------[ peterjeremy@acm.org ]----------------------
|
| Whilst SIGINFO helps once userland starts, I would not be comfortable
| with a system that reported nothing between the boot loader and login
| prompts.

Agreed.

Especially after installs on new hardware, or after an upgrade / kernel
rebuild.

We already have -m and -q bootflags...


-- 
Andrew Milton
akm@theinternet.com.au
From h.schmalzbauer at omnilan.de  Fri Sep  4 11:24:50 2009
From: h.schmalzbauer at omnilan.de (Harald Schmalzbauer)
Date: Fri Sep  4 11:24:57 2009
Subject: xorg running > 48h starts consuming CPU cycles with BETA3
Message-ID: <4AA0F8FE.6050908@omnilan.de>

Hello,

I have one problem with xorg running on BETA3.
Repeatably, after more than 48hour uptime, my workstation showes 
increased load. The longer the uptime, the more cpu cycles xorg consumes.
It's absolutely application independent. After 3 or 4 days, almost one 
complete CPU is occupied by xorg, but I have no idea what xorg is doing.
Is there any way to "look inside" xorg to see where the CPU cycles vanish?
With uptimes shorter than 2 days I can't see xorg consuming any 
remarkable CPU cycles.
Xorg is 1.6.1, compiled on BETA3:
1157 root          1  53    0   828M   234M select  1  40:04 15.38% Xorg

Thanks,

-Harry

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 196 bytes
Desc: OpenPGP digital signature
Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20090904/fa1da6ee/signature.pgp
From amvandemore at gmail.com  Fri Sep  4 12:36:50 2009
From: amvandemore at gmail.com (Adam Vande More)
Date: Fri Sep  4 12:38:33 2009
Subject: [Call For Testing] VirtualBox for FreeBSD! take 4
In-Reply-To: <4AA09410.8020302@lapo.it>
References: <20090527134343.GB1104@bsdcrew.de>
	<85d001330905270909jde4d723s65e8708a8b498c29@mail.gmail.com>
	<20090527163952.GI1104@bsdcrew.de> <4AA0149E.30209@lapo.it>
	<6201873e0909031252r41bced2eqe1784a17214f1cd1@mail.gmail.com>
	<4AA09410.8020302@lapo.it>
Message-ID: <6201873e0909040536y2a2c7a22t30247d61adc26318@mail.gmail.com>

On Thu, Sep 3, 2009 at 11:14 PM, Lapo Luchini <lapo@lapo.it> wrote:

> Adam Vande More wrote:
> >>>/usr/ports/devel/kBuild/work/kBuild-0.1.5-p1/kBuild/footer.kmk:2304: ***
> >>> target file `virtualbox' has both : and :: entries.
> >>>
> >>> Please update to 7.2 or higher
> >>
> >> Errr, and what if I have that in a FreeBSD 7.2-STABLE?
> >
> > Are you using portmaster to build virtualbox?
>
> Yes indeed... and now that you say it, I tried a simple
> "cd emulators/virtualbox ; make install"
> and it worked!
>
> I wonder what does portmaster different to break only that specific port...
>
> --
> Lapo Luchini - http://lapo.it/
>
> ?Any sufficiently advanced technology is indistinguishable from magic.?
> (Arthur C. Clarke)
>
>
I believe portmaster uses a lot environmental variables, and kBuild does
something funky with them.  So technically, the issue lies w/ kBuild, not
portmaster.  At least that's what I read.

-- 
Adam Vande More
From tinderbox at freebsd.org  Fri Sep  4 14:26:01 2009
From: tinderbox at freebsd.org (FreeBSD Tinderbox)
Date: Fri Sep  4 14:26:08 2009
Subject: [head tinderbox] failure on i386/i386
Message-ID: <200909041425.n84EPx4P018005@freebsd-current.sentex.ca>

TB --- 2009-09-04 12:25:00 - tinderbox 2.6 running on freebsd-current.sentex.ca
TB --- 2009-09-04 12:25:00 - starting HEAD tinderbox run for i386/i386
TB --- 2009-09-04 12:25:00 - cleaning the object tree
TB --- 2009-09-04 12:25:56 - cvsupping the source tree
TB --- 2009-09-04 12:25:56 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/i386/i386/supfile
TB --- 2009-09-04 12:27:17 - building world
TB --- 2009-09-04 12:27:17 - MAKEOBJDIRPREFIX=/obj
TB --- 2009-09-04 12:27:17 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2009-09-04 12:27:17 - TARGET=i386
TB --- 2009-09-04 12:27:17 - TARGET_ARCH=i386
TB --- 2009-09-04 12:27:17 - TZ=UTC
TB --- 2009-09-04 12:27:17 - __MAKE_CONF=/dev/null
TB --- 2009-09-04 12:27:17 - cd /src
TB --- 2009-09-04 12:27:17 - /usr/bin/make -B buildworld
>>> World build started on Fri Sep  4 12:27:17 UTC 2009
>>> Rebuilding the temporary build tree
>>> stage 1.1: legacy release compatibility shims
>>> stage 1.2: bootstrap tools
>>> stage 2.1: cleaning up the object tree
>>> stage 2.2: rebuilding the object tree
>>> stage 2.3: build tools
>>> stage 3: cross tools
>>> stage 4.1: building includes
>>> stage 4.2: building libraries
>>> stage 4.3: make dependencies
>>> stage 4.4: building everything
>>> World build completed on Fri Sep  4 13:32:29 UTC 2009
TB --- 2009-09-04 13:32:29 - generating LINT kernel config
TB --- 2009-09-04 13:32:29 - cd /src/sys/i386/conf
TB --- 2009-09-04 13:32:29 - /usr/bin/make -B LINT
TB --- 2009-09-04 13:32:29 - building LINT kernel
TB --- 2009-09-04 13:32:29 - MAKEOBJDIRPREFIX=/obj
TB --- 2009-09-04 13:32:29 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2009-09-04 13:32:29 - TARGET=i386
TB --- 2009-09-04 13:32:29 - TARGET_ARCH=i386
TB --- 2009-09-04 13:32:29 - TZ=UTC
TB --- 2009-09-04 13:32:29 - __MAKE_CONF=/dev/null
TB --- 2009-09-04 13:32:29 - cd /src
TB --- 2009-09-04 13:32:29 - /usr/bin/make -B buildkernel KERNCONF=LINT
>>> Kernel build for LINT started on Fri Sep  4 13:32:30 UTC 2009
>>> 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 Fri Sep  4 13:58:08 UTC 2009
TB --- 2009-09-04 13:58:08 - building GENERIC kernel
TB --- 2009-09-04 13:58:08 - MAKEOBJDIRPREFIX=/obj
TB --- 2009-09-04 13:58:08 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2009-09-04 13:58:08 - TARGET=i386
TB --- 2009-09-04 13:58:08 - TARGET_ARCH=i386
TB --- 2009-09-04 13:58:08 - TZ=UTC
TB --- 2009-09-04 13:58:08 - __MAKE_CONF=/dev/null
TB --- 2009-09-04 13:58:08 - cd /src
TB --- 2009-09-04 13:58:08 - /usr/bin/make -B buildkernel KERNCONF=GENERIC
>>> Kernel build for GENERIC started on Fri Sep  4 13:58:08 UTC 2009
>>> 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 Fri Sep  4 14:18:31 UTC 2009
TB --- 2009-09-04 14:18:31 - building PAE kernel
TB --- 2009-09-04 14:18:31 - MAKEOBJDIRPREFIX=/obj
TB --- 2009-09-04 14:18:31 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2009-09-04 14:18:31 - TARGET=i386
TB --- 2009-09-04 14:18:31 - TARGET_ARCH=i386
TB --- 2009-09-04 14:18:31 - TZ=UTC
TB --- 2009-09-04 14:18:31 - __MAKE_CONF=/dev/null
TB --- 2009-09-04 14:18:31 - cd /src
TB --- 2009-09-04 14:18:31 - /usr/bin/make -B buildkernel KERNCONF=PAE
>>> Kernel build for PAE started on Fri Sep  4 14:18:31 UTC 2009
>>> 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 Fri Sep  4 14:23:35 UTC 2009
TB --- 2009-09-04 14:23:35 - building XEN kernel
TB --- 2009-09-04 14:23:35 - MAKEOBJDIRPREFIX=/obj
TB --- 2009-09-04 14:23:35 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2009-09-04 14:23:35 - TARGET=i386
TB --- 2009-09-04 14:23:35 - TARGET_ARCH=i386
TB --- 2009-09-04 14:23:35 - TZ=UTC
TB --- 2009-09-04 14:23:35 - __MAKE_CONF=/dev/null
TB --- 2009-09-04 14:23:35 - cd /src
TB --- 2009-09-04 14:23:35 - /usr/bin/make -B buildkernel KERNCONF=XEN
>>> Kernel build for XEN started on Fri Sep  4 14:23:35 UTC 2009
>>> stage 1: configuring the kernel
>>> stage 2.1: cleaning up the object tree
>>> stage 2.2: rebuilding the object tree
>>> stage 2.3: build tools
>>> stage 3.1: making dependencies
>>> stage 3.2: building everything
[...]
cc -c -O -pipe  -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes  -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual  -Wundef -Wno-pointer-sign -fformat-extensions -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-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -Werror  /src/sys/i386/i386/intr_machdep.c
cc -c -O -pipe  -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes  -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual  -Wundef -Wno-pointer-sign -fformat-extensions -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-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -Werror  /src/sys/i386/i386/io.c
cc -c -O -pipe  -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes  -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual  -Wundef -Wno-pointer-sign -fformat-extensions -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-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -Werror  /src/sys/i386/i386/io_apic.c
cc -c -O -pipe  -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes  -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual  -Wundef -Wno-pointer-sign -fformat-extensions -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-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -Werror  /src/sys/i386/i386/k6_mem.c
cc -c -O -pipe  -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes  -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual  -Wundef -Wno-pointer-sign -fformat-extensions -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-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -Werror  /src/sys/i386/i386/local_apic.c
cc -c -O -pipe  -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes  -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual  -Wundef -Wno-pointer-sign -fformat-extensions -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-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -Werror  /src/sys/i386/i386/machdep.c
/src/sys/i386/i386/machdep.c: In function 'init386':
/src/sys/i386/i386/machdep.c:2574: error: expected ';' before 'do'
*** Error code 1

Stop in /obj/i386/src/sys/XEN.
*** Error code 1

Stop in /src.
*** Error code 1

Stop in /src.
TB --- 2009-09-04 14:25:59 - WARNING: /usr/bin/make returned exit code  1 
TB --- 2009-09-04 14:25:59 - ERROR: failed to build XEN kernel
TB --- 2009-09-04 14:25:59 - 5086.95 user 704.03 system 7259.30 real


http://tinderbox.des.no/tinderbox-head-HEAD-i386-i386.full
From linimon at lonesome.com  Fri Sep  4 13:52:53 2009
From: linimon at lonesome.com (Mark Linimon)
Date: Fri Sep  4 15:25:07 2009
Subject: Reducing noise in dmesg output
In-Reply-To: <20090904101630.GA17207@camelot.theinternet.com.au>
References: <200909010931.16880.nick@van-laarhoven.org>
	<1251841416.1689.4458.camel@balrog.2hip.net>
	<200909021656.15747.nick@van-laarhoven.org>
	<f0dd9eb90909021739o4d31c88l5be6638f7998dae6@mail.gmail.com>
	<20090904100847.GA13167@server.vk2pj.dyndns.org>
	<20090904101630.GA17207@camelot.theinternet.com.au>
Message-ID: <20090904135252.GA23438@lonesome.com>

No one has mentioned the other reason to leave in verbosity: so that users
who are having problems can file more useful PRs.  This is particularly
true of video cards (which, as one might recall, is where this thread
started.)

In some cases it can save a whole round-trip of "please reboot with
another flag set and provide the following information ..."

mcl
From onemda at gmail.com  Fri Sep  4 15:34:54 2009
From: onemda at gmail.com (Paul B. Mahol)
Date: Fri Sep  4 15:35:00 2009
Subject: xorg running > 48h starts consuming CPU cycles with BETA3
In-Reply-To: <4AA0F8FE.6050908@omnilan.de>
References: <4AA0F8FE.6050908@omnilan.de>
Message-ID: <3a142e750909040834g2465d932t4b65ff02727761bf@mail.gmail.com>

On 9/4/09, Harald Schmalzbauer <h.schmalzbauer@omnilan.de> wrote:
> Hello,
>
> I have one problem with xorg running on BETA3.
> Repeatably, after more than 48hour uptime, my workstation showes
> increased load. The longer the uptime, the more cpu cycles xorg consumes.
> It's absolutely application independent. After 3 or 4 days, almost one
> complete CPU is occupied by xorg, but I have no idea what xorg is doing.
> Is there any way to "look inside" xorg to see where the CPU cycles vanish?
> With uptimes shorter than 2 days I can't see xorg consuming any
> remarkable CPU cycles.
> Xorg is 1.6.1, compiled on BETA3:
> 1157 root          1  53    0   828M   234M select  1  40:04 15.38% Xorg

What video driver Xorg is using?


-- 
Paul
From lists at rhavenn.net  Fri Sep  4 17:16:49 2009
From: lists at rhavenn.net (Henrik Hudson)
Date: Fri Sep  4 17:16:55 2009
Subject: PF rules not loading
Message-ID: <20090904165930.GA4160@alucard.int.rhavenn.net>

Hey List,

I just finishing supping to 8-BETA3 and after a reboot I noticed
that my PF rules weren't loading and hence NAT wasn't working for
internal clients, not to mention no firewall :)

This might not be specific to BETA3, but it's the first time I
noticed it concretely. I did have a power outage last week where
after a poweron I had to run pfctl -f /etc/pf.conf to get NAT working
again. This was under BETA2.

uname: FreeBSD cerberus.domain.local 8.0-BETA3 FreeBSD 8.0-BETA3
#1: Fri Sep  4 02:35:38 AKDT 2009
root@cerberus.domain.local:/usr/obj/usr/src/sys/CERBERUS  amd64

The kernel is 99% stock with the only changes being the IDENT and
adding PF and ALTQ specific items.

rc.conf:
#firewall -pf
pf_enable="YES"                  # Set to YES to enable packet
filter (pf)   
pf_rules="/etc/pf.conf"         # rules definition file for pf
pf_program="/sbin/pfctl"        # where the pfctl program lives
pf_flags=""                     # additional flags for pfctl
pflog_enable="YES"               # Set to YES to enable packet
filter logging
pflog_logfile="/var/log/pflog"  # where pflogd should store the
logfile
pflog_program="/sbin/pflogd"    # where the pflogd program lives
pflog_flags=""                  # additional flags for pflogd
pfsync_enable="NO"              # Expose pf state to other hosts for
syncing
pfsync_syncdev=""               # Interface for pfsync to work
through
pfsync_ifconfig=""              # Additional options to ifconfig(8)
for pfsync


Manually running /etc/rc.d/pf start   works fine and doesn't show
any errors.

Any further steps to troubleshoot this / check this?

hardware is a atom based mobo with the onboad re0 and then a xl0 PCI
card. re0 is internal facing and the xl0 is a DHCP external from my
ISP.

Henrik
-- 
Henrik Hudson
lists@rhavenn.net
-----------------------------------------
"God, root, what is difference?" Pitr; UF 

From xcllnt at mac.com  Fri Sep  4 17:34:29 2009
From: xcllnt at mac.com (Marcel Moolenaar)
Date: Fri Sep  4 17:34:36 2009
Subject: Reducing noise in dmesg output
In-Reply-To: <20090904135252.GA23438@lonesome.com>
References: <200909010931.16880.nick@van-laarhoven.org>
	<1251841416.1689.4458.camel@balrog.2hip.net>
	<200909021656.15747.nick@van-laarhoven.org>
	<f0dd9eb90909021739o4d31c88l5be6638f7998dae6@mail.gmail.com>
	<20090904100847.GA13167@server.vk2pj.dyndns.org>
	<20090904101630.GA17207@camelot.theinternet.com.au>
	<20090904135252.GA23438@lonesome.com>
Message-ID: <642B63E0-0F75-45FD-9E8D-58D990F7C8EB@mac.com>


On Sep 4, 2009, at 6:52 AM, Mark Linimon wrote:

> No one has mentioned the other reason to leave in verbosity: so that  
> users
> who are having problems can file more useful PRs.  This is  
> particularly
> true of video cards (which, as one might recall, is where this thread
> started.)

This has always been an interesting fault-line.

Yes, if you print or log "everything" then there's bound to
be useful information somewhere that can be used to analyze
problems. Approaching this from the glass half-empty angle,
I can see why people value verbosity. It's an easy case to
state: without it we don't know what went wrong.

There's a flip-side and it's one that's much harder to argue
for. Arguments against verbosity include such things as:
1.  The signal/noise ratio is worse which means that it's
     easier to miss the information that is truly important.
2.  You present the user with output that's not even directed
     towards the user -- it's an aesthetic bug.
3.  It introduces performance problems, especially on slow
     consoles.
4.  If it works, it works and the verbosity is unnecessary.

Much more subjective...

As long as we depend on verbosity to provide us with the
information we need to solve a problem, it's really hard to
convince people that we should make it more user-oriented
and print only things that are of value to the user. Which
means that unless developers value the user perspective and
are willing to put in the effort to allow for another way
of obtaining the information, verbosity is hard to reduce.
It's not in the developer's interest. That is, unless the
problem reporting is actually much better if done differently.

-- 
Marcel Moolenaar
xcllnt@mac.com



From qing.li at bluecoat.com  Fri Sep  4 18:15:54 2009
From: qing.li at bluecoat.com (Li, Qing)
Date: Fri Sep  4 18:16:07 2009
Subject: 8.0-BETA3/IPv6: route: bad keyword: cloning
In-Reply-To: <20090904173716.GA2278@mr-happy.com>
References: <20090904173716.GA2278@mr-happy.com>
Message-ID: <B583FBF374231F4A89607B4D08578A4305361EBE@bcs-mail03.internal.cacheflow.com>

> 
> Upon booting an 8.0-BETA3 system with IPv6 enabled, I saw this in the
> console boot output:
> 
> route: bad keyword: cloning
> usage: route [-dnqtv] command [[modifiers] args]
> 
> This looks like it's from line 1062/1063 of /etc/network.subr
> v1.195.2.4.
> 
> This system is not an IPv6 router, so do I particularly need
> $ipv6_default_interface set in rc.conf?
> 
> Is there a situation where -cloning (still referenced in the man page)
> is a valid option to route (in inet6 context at least)?  If no, should
> I file a PR?  (I searched GNATS but didn't find anything matching
> this.)
> 

	Route cloning is obsolete. Please report issues concerning
	8.0 to freebsd-current@freebsd.org.

	Thanks,

	-- Qing

From h.schmalzbauer at omnilan.de  Fri Sep  4 18:41:52 2009
From: h.schmalzbauer at omnilan.de (Harald Schmalzbauer)
Date: Fri Sep  4 18:41:59 2009
Subject: xorg running > 48h starts consuming CPU cycles with BETA3
In-Reply-To: <3a142e750909040834g2465d932t4b65ff02727761bf@mail.gmail.com>
References: <4AA0F8FE.6050908@omnilan.de>
	<3a142e750909040834g2465d932t4b65ff02727761bf@mail.gmail.com>
Message-ID: <4AA15F66.9070907@omnilan.de>

Paul B. Mahol schrieb am 04.09.2009 17:34 (localtime):
> On 9/4/09, Harald Schmalzbauer <h.schmalzbauer@omnilan.de> wrote:
>> Hello,
>>
>> I have one problem with xorg running on BETA3.
>> Repeatably, after more than 48hour uptime, my workstation showes
>> increased load. The longer the uptime, the more cpu cycles xorg consumes.
>> It's absolutely application independent. After 3 or 4 days, almost one
>> complete CPU is occupied by xorg, but I have no idea what xorg is doing.
>> Is there any way to "look inside" xorg to see where the CPU cycles vanish?
>> With uptimes shorter than 2 days I can't see xorg consuming any
>> remarkable CPU cycles.
>> Xorg is 1.6.1, compiled on BETA3:
>> 1157 root          1  53    0   828M   234M select  1  40:04 15.38% Xorg
> 
> What video driver Xorg is using?

nvidia (not nv)

Thanks,

-Harry

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 196 bytes
Desc: OpenPGP digital signature
Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20090904/8e924c65/signature.pgp
From qing.li at bluecoat.com  Fri Sep  4 18:57:20 2009
From: qing.li at bluecoat.com (Li, Qing)
Date: Fri Sep  4 18:57:31 2009
Subject: 8.0-BETA3/IPv6: route: bad keyword: cloning
In-Reply-To: <B583FBF374231F4A89607B4D08578A4305361EBE@bcs-mail03.internal.cacheflow.com>
References: <20090904173716.GA2278@mr-happy.com>
	<B583FBF374231F4A89607B4D08578A4305361EBE@bcs-mail03.internal.cacheflow.com>
Message-ID: <B583FBF374231F4A89607B4D08578A4305361F0D@bcs-mail03.internal.cacheflow.com>

	Regarding the man page issue, after a quick investigation, and
to 
	make a long story short, Kip Macy and I spent a bunch of time
testing 
	and fixing a few last minute bugs before my big commit last
December. 

	Kip actually took care of this man page and one other issue in
"ndp"
	command. 

	Somehow these two last minute changes fell through the cracks
	and did not make it into r186119. Kip will fix it again.

	Thank you for catching the bug.

	-- Qing

	

> -----Original Message-----
> From: owner-freebsd-stable@freebsd.org [mailto:owner-freebsd-
> stable@freebsd.org] On Behalf Of Li, Qing
> Sent: Friday, September 04, 2009 11:15 AM
> To: Jeff Blank; freebsd-stable@freebsd.org
> Cc: FreeBSD Current
> Subject: RE: 8.0-BETA3/IPv6: route: bad keyword: cloning
> 
> >
> > Upon booting an 8.0-BETA3 system with IPv6 enabled, I saw this in
the
> > console boot output:
> >
> > route: bad keyword: cloning
> > usage: route [-dnqtv] command [[modifiers] args]
> >
> > This looks like it's from line 1062/1063 of /etc/network.subr
> > v1.195.2.4.
> >
> > This system is not an IPv6 router, so do I particularly need
> > $ipv6_default_interface set in rc.conf?
> >
> > Is there a situation where -cloning (still referenced in the man
page)
> > is a valid option to route (in inet6 context at least)?  If no,
> should
> > I file a PR?  (I searched GNATS but didn't find anything matching
> > this.)
> >
> 
> 	Route cloning is obsolete. Please report issues concerning
> 	8.0 to freebsd-current@freebsd.org.
> 
> 	Thanks,
> 
> 	-- Qing
> 
> _______________________________________________
> freebsd-stable@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to "freebsd-stable-
> unsubscribe@freebsd.org"
From webmaster at doghouserepair.com  Fri Sep  4 19:04:29 2009
From: webmaster at doghouserepair.com (Ryan Rogers)
Date: Fri Sep  4 19:04:36 2009
Subject: non aligned DMA transfer attempted
In-Reply-To: <4AA0B8C0.90604@FreeBSD.org>
References: <h7p0a3$k3m$1@FreeBSD.cs.nctu.edu.tw>
	<4AA03346.5010608@FreeBSD.org>
	<4AA09FDF.2010307@doghouserepair.com> <4AA0B8C0.90604@FreeBSD.org>
Message-ID: <4AA164B9.6030806@doghouserepair.com>

Alexander Motin wrote:
> Ryan Rogers wrote:
>> Alexander Motin wrote:
>>> Ryan Rogers wrote:
>>>> I'm having a bit of a problem getting my DVD drive(s) to work 
>>>> correctly.   I'm trying to transfer my DVD collection to my media 
>>>> server, but whenever I run vobcopy, /var/log/messages gets spammed 
>>>> with:
>>>>
>>>> acd0: FAILURE - non aligned DMA transfer attempted
>>>> acd0: setting up DMA failed
>>>>
>>>> I added a bit more information to the first message to see if I 
>>>> could figure out what was actually going on.  request->data was 
>>>> 0xd40e0c37, ch->dma.alignment was 2, and request->bytecount was 2048.
>>>
>>> Actually I don't understand what for this check was made there. It is 
>>> busdma infrastructure business to implement buffer bouncing to manage 
>>> requested alignment. But this check enforces application level to 
>>> bother with this. Usually it works fine, as memory often allocated 
>>> aligned. But probably here is some specifics in your application. 
>>> Could you try to just to comment-out that request->data check?
>>
>> I commented out that part of the check, and it worked in the sense 
>> that it didn't spit out any errors at me, but I'm not 100% certain 
>> that the data isn't getting corrupted.  I tried ripping two discs.  
>> The first is completely corrupted, the second appears to be fine on 
>> first glance. I'm going to try a couple more discs to see if maybe the 
>> first one was just bad.
> 
> Please.
> 
>> Also, one other thing that I noticed that seems odd is this:
>>
>> acd0: DVDR <TSSTcorp CDDVDW SH-S223L/SB02> at ata6-master SATA150
>> ....
>> cd0: <TSSTcorp CDDVDW SH-S223L SB02> Removable CD-ROM SCSI-0 device
>> cd0: 3.300MB/s transfers
>>
>> I timed how long the first disc took to rip, and it seems to match 
>> that reported speed.  "Working but slow" is certainly better than "not 
>> working", but my speeds in Windows using DVD Decrypter on the same 
>> disk are at least 3 times faster, bursting up to about 5 times faster.
> 
> It's just a small atapicam misfeature. It doesn't translates SATA modes 
> to CAM speeds. It's only cosmetics, it shouldn't be important.
> 

I've ripped a handful of DVDs since my last post, and I haven't had any 
error messages, and the output appears to be correct.  I even re-ripped 
the one that had originally been corrupted, and it appears to be fine as 
well.  So, it appears removing that part of the check fixed the issue 
for me.

Ryan
From rizzo at iet.unipi.it  Fri Sep  4 20:08:56 2009
From: rizzo at iet.unipi.it (Luigi Rizzo)
Date: Fri Sep  4 20:09:03 2009
Subject: what clock is used by select()/HZ ?
Message-ID: <20090904195718.GA69566@onelab2.iet.unipi.it>

Hi,
I am running a kernel (8.0) with HZ=5000 trying to generate
packets which are apart from each other by something that is
not an exact multiple of 1ms . I have a modified ping version
which essentially accepts a microsecond spec, loops around
select() and tries to send a packet at precise intervals
(taking care not to accumulate errors).

running it with
	./ping -i 0.050200 some.host
and looking at the tcpdump output captured on the same host, i see
that packets get out of the system at intervals that (according to
the tcpdump timestamps are .050121 (60% of them) or .050322 (40%
of them) seconds apart (values are scattered within 10us of each
of the two values).

Overall the average delta is correct, but individual samples are not.
The system reports the following values:

kern.timecounter.choice: TSC(-100) HPET(900) ACPI-safe(850) i8254(0) dummy(-1000000)
kern.timecounter.hardware: HPET
kern.timecounter.tc.i8254.frequency: 1193182
kern.timecounter.tc.HPET.frequency: 25000000
kern.timecounter.tc.ACPI-safe.frequency: 3579545
kern.timecounter.tc.TSC.frequency: 2314976129
kern.timecounter.tick: 5 # (not sure what this means)

The only way i can explain the differences in the delays is that
the internal value of HZ is slightly different than the correct
value (50121/50200 or 50322/50200 times 5000) due to some approximation
in the divider used to generate the peridic interrupt, whereas
gettimeofday() is reasonably correct and prevents the accumulation
of errors.

However, HPET (which seems to be the one used) is a multiple of 5000
so the divider should be correct, and i cannot figure out what other
clock source could cause, due to a rounding error in the divisor,
such a large difference (50121/50200 or 50322/50200)

Any ideas ?

	cheers
	luigi

From cjk at home.kreklow.us  Fri Sep  4 20:11:33 2009
From: cjk at home.kreklow.us (Collin Kreklow)
Date: Fri Sep  4 20:11:40 2009
Subject: PF rules not loading
In-Reply-To: <20090904165930.GA4160@alucard.int.rhavenn.net>
References: <20090904165930.GA4160@alucard.int.rhavenn.net>
Message-ID: <20090904201132.GA17378@srv.home.kreklow.us>

On Fri, Sep 04, 2009 at 08:59:30AM -0800, Henrik Hudson wrote:
> Hey List,
> 
> I just finishing supping to 8-BETA3 and after a reboot I noticed
> that my PF rules weren't loading and hence NAT wasn't working for
> internal clients, not to mention no firewall :)
> 
> This might not be specific to BETA3, but it's the first time I
> noticed it concretely. I did have a power outage last week where
> after a poweron I had to run pfctl -f /etc/pf.conf to get NAT working
> again. This was under BETA2.

At the time when the pf script runs during boot, all the network
interfaces may not be fully configured.  It is likely that your pf.conf
includes rules that pf can't calculate because one or more network
interfaces are not yet configured.  I had to change my pf.conf to
hard-code the IP ranges instead of using :network to get my rules to
load on boot.  Also make sure your script is using (xl0) where
appropriate.

- Collin

From lists at rhavenn.net  Fri Sep  4 20:34:47 2009
From: lists at rhavenn.net (Henrik Hudson)
Date: Fri Sep  4 20:34:53 2009
Subject: PF rules not loading
In-Reply-To: <20090904201132.GA17378@srv.home.kreklow.us>
References: <20090904165930.GA4160@alucard.int.rhavenn.net>
	<20090904201132.GA17378@srv.home.kreklow.us>
Message-ID: <20090904203439.GA6431@alucard.int.rhavenn.net>

On Fri, 04 Sep 2009, Collin Kreklow wrote:

> On Fri, Sep 04, 2009 at 08:59:30AM -0800, Henrik Hudson wrote:
> > Hey List,
> > 
> > I just finishing supping to 8-BETA3 and after a reboot I noticed
> > that my PF rules weren't loading and hence NAT wasn't working for
> > internal clients, not to mention no firewall :)
> > 
> > This might not be specific to BETA3, but it's the first time I
> > noticed it concretely. I did have a power outage last week where
> > after a poweron I had to run pfctl -f /etc/pf.conf to get NAT working
> > again. This was under BETA2.
> 
> At the time when the pf script runs during boot, all the network
> interfaces may not be fully configured.  It is likely that your pf.conf
> includes rules that pf can't calculate because one or more network
> interfaces are not yet configured.  I had to change my pf.conf to
> hard-code the IP ranges instead of using :network to get my rules to
> load on boot.  Also make sure your script is using (xl0) where
> appropriate.

It's possible. However, I'm pretty sure the ruleset worked correctly
on the initial install and it's a ruleset I've used on plenty of
different gateway servers with a similar hardware setup.

However, I did just finish building another 8-BETA3 x64 box and it
works fine, so maybe something fluky is going on with the server
crash due to the power outage. 

I will investiage further. Thanks.

Henrik
-- 
Henrik Hudson
lists@rhavenn.net
-----------------------------------------
"God, root, what is difference?" Pitr; UF 

From lists at rhavenn.net  Fri Sep  4 20:52:22 2009
From: lists at rhavenn.net (Henrik Hudson)
Date: Fri Sep  4 20:52:29 2009
Subject: PF rules not loading
In-Reply-To: <20090904203439.GA6431@alucard.int.rhavenn.net>
References: <20090904165930.GA4160@alucard.int.rhavenn.net>
	<20090904201132.GA17378@srv.home.kreklow.us>
	<20090904203439.GA6431@alucard.int.rhavenn.net>
Message-ID: <20090904205220.GA6647@alucard.int.rhavenn.net>

On Fri, 04 Sep 2009, Henrik Hudson wrote:

> On Fri, 04 Sep 2009, Collin Kreklow wrote:
> 
> > On Fri, Sep 04, 2009 at 08:59:30AM -0800, Henrik Hudson wrote:
> > > Hey List,
> > > 
> > > I just finishing supping to 8-BETA3 and after a reboot I noticed
> > > that my PF rules weren't loading and hence NAT wasn't working for
> > > internal clients, not to mention no firewall :)
> > > 
> > > This might not be specific to BETA3, but it's the first time I
> > > noticed it concretely. I did have a power outage last week where
> > > after a poweron I had to run pfctl -f /etc/pf.conf to get NAT working
> > > again. This was under BETA2.
> > 
> > At the time when the pf script runs during boot, all the network
> > interfaces may not be fully configured.  It is likely that your pf.conf
> > includes rules that pf can't calculate because one or more network
> > interfaces are not yet configured.  I had to change my pf.conf to
> > hard-code the IP ranges instead of using :network to get my rules to
> > load on boot.  Also make sure your script is using (xl0) where
> > appropriate.
> 
> It's possible. However, I'm pretty sure the ruleset worked correctly
> on the initial install and it's a ruleset I've used on plenty of
> different gateway servers with a similar hardware setup.
> 
> However, I did just finish building another 8-BETA3 x64 box and it
> works fine, so maybe something fluky is going on with the server
> crash due to the power outage. 
> 
> I will investiage further. Thanks.

*ding* *ding* we have a winner. I had added a rule which required a
DNS lookup for port forwarding in torrent traffic to an internal
host.

Thanks.

Henrik
-- 
Henrik Hudson
lists@rhavenn.net
-----------------------------------------
"God, root, what is difference?" Pitr; UF 

From boris.hollas at gmx.de  Fri Sep  4 21:57:53 2009
From: boris.hollas at gmx.de (Boris Hollas)
Date: Fri Sep  4 21:57:59 2009
Subject: 8.0-BETA3: ACPI resume fails
Message-ID: <op.uzq4plt2k2i85h@lifebook>

I've installed 8.0-BETA3 without X on a Fuji-Siemens Lifebook E8110.

I observed the following while testing sleep mode:

1) Test 1
- I invoked
   # zzz
- Screen and HD were switched off.
- I pressed "On".
- HD was switched on, but screen remained blank. The system didn't react  
to typing "reboot".

2) Test 2
I loaded acpi_fujitsu and repeated test 1 with the same result.

3) Test 3
I compiled a kernel without firewire support and excluded many unnecessary  
drivers. I repeated test 1 with the same result.

4) Test 4
With the kernel from 3), I entered
# sysctrl acpi.hw.reset_video=1
and repeated test 1 with the same result.


Sleep mode works with Debian Lenny.

Resume also failed with both 7.2-R and 8.0-BETA3 on an old Thinkpad A30p.
From onemda at gmail.com  Fri Sep  4 23:10:43 2009
From: onemda at gmail.com (Paul B. Mahol)
Date: Fri Sep  4 23:10:49 2009
Subject: 8.0-BETA3: ACPI resume fails
In-Reply-To: <op.uzq4plt2k2i85h@lifebook>
References: <op.uzq4plt2k2i85h@lifebook>
Message-ID: <3a142e750909041610w6d1249cch6eb8164e7230b749@mail.gmail.com>

On 9/4/09, Boris Hollas <boris.hollas@gmx.de> wrote:
> I've installed 8.0-BETA3 without X on a Fuji-Siemens Lifebook E8110.
>
> I observed the following while testing sleep mode:
>
> 1) Test 1
> - I invoked
>    # zzz
> - Screen and HD were switched off.
> - I pressed "On".
> - HD was switched on, but screen remained blank. The system didn't react
> to typing "reboot".
>
> 2) Test 2
> I loaded acpi_fujitsu and repeated test 1 with the same result.
>
> 3) Test 3
> I compiled a kernel without firewire support and excluded many unnecessary
> drivers. I repeated test 1 with the same result.
>
> 4) Test 4
> With the kernel from 3), I entered
> # sysctrl acpi.hw.reset_video=1
> and repeated test 1 with the same result.
>
>
> Sleep mode works with Debian Lenny.
>
> Resume also failed with both 7.2-R and 8.0-BETA3 on an old Thinkpad A30p.

Resume in general currently doesnt work with SMP kernel on SMP systems
on i386, (missing some code)
amd64 should work.

-- 
Paul
From dillon at apollo.backplane.com  Fri Sep  4 23:14:28 2009
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Fri Sep  4 23:14:35 2009
Subject: non aligned DMA transfer attempted
References: <h7p0a3$k3m$1@FreeBSD.cs.nctu.edu.tw>
	<4AA03346.5010608@FreeBSD.org>
	<200909032210.n83MA67F059073@apollo.backplane.com>
	<A1B223C6-7291-4F86-B8AC-4EB5EF12F409@samsco.org>
Message-ID: <200909042314.n84NEMAS072077@apollo.backplane.com>


:>    The physio code directly maps the userland buffer via vmapbuf() and
:>    supplies it as a BIO to the device.  The ATA driver does not use
:>    BUSDMA (and never has)... it assumes BIOs are minimally aligned.
:>
:
:Wrong.

    By the way Scott, do you honestly believe that idiotic one-line
    answers just as a means to try to screw over my postings are
    appropriate for someone of your standing in the FreeBSD community?

    In anycase, this is what was causing the problem in DragonFly
    and the code is nearly identicial to FreeBSD.  Adding the bounce
    buffers in physio and cam's pass-through fixed the problem in
    DragonFly... that is, the programs that we got bug reports about
    non-aligned DMA transfers started working again after I made
    those changes.

    Yes, removing the check might work in some cases, particularly
    with newer chipsets, since even BUSDMA alignment tends to be
    conservative for reverse-engineered chipsets, but I've seen
    userland pass byte-aligned buffers through CAM and physio on
    numerous occassions and if you actually want it to work reliably
    you have to enforce at least a base alignment... which BUSDMA can
    do if the driver uses BUSDMA (except it does it way too deep in
    the driver stack IMHO).  All my points stand.  Bounce buffers have
    created issues both positive and negative from the day they were
    introduced to this very day.  I was very happy to be able to
    wash my hands of the majority of those problems by enforcing
    a base alignment closer to the userland boundary, and I would
    heartily recommend the same approach to any OS project.

    So, again, if you have a more detailed response that gets at the
    heart of the problem, I'm sure the original posters are eagerly
    waiting your next posting.

    But hey, if you think your type of answer is completely
    appropriate then maybe I should start following your lead and
    not bother to supply any detail in my own.  Hey, you're wrong!
    Oh, by the way, I'm not going to bother to say why.  Sheesh.
    You guys are just too full of yourselves these days.

					-Matt

From jamesbrandongooch at gmail.com  Fri Sep  4 23:15:53 2009
From: jamesbrandongooch at gmail.com (Brandon Gooch)
Date: Fri Sep  4 23:16:00 2009
Subject: 8.0-BETA3: ACPI resume fails
In-Reply-To: <op.uzq4plt2k2i85h@lifebook>
References: <op.uzq4plt2k2i85h@lifebook>
Message-ID: <179b97fb0909041615qa3f4a80ld669663769df5b62@mail.gmail.com>

On Fri, Sep 4, 2009 at 4:30 PM, Boris Hollas<boris.hollas@gmx.de> wrote:
> I've installed 8.0-BETA3 without X on a Fuji-Siemens Lifebook E8110.
>
> I observed the following while testing sleep mode:
>
> 1) Test 1
> - I invoked
> ?# zzz
> - Screen and HD were switched off.
> - I pressed "On".
> - HD was switched on, but screen remained blank. The system didn't react to
> typing "reboot".
>
> 2) Test 2
> I loaded acpi_fujitsu and repeated test 1 with the same result.
>
> 3) Test 3
> I compiled a kernel without firewire support and excluded many unnecessary
> drivers. I repeated test 1 with the same result.
>
> 4) Test 4
> With the kernel from 3), I entered
> # sysctrl acpi.hw.reset_video=1
> and repeated test 1 with the same result.
>
>
> Sleep mode works with Debian Lenny.
>
> Resume also failed with both 7.2-R and 8.0-BETA3 on an old Thinkpad A30p.
> _______________________________________________
> 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"
>

On my ThinkPad X300 (with Intel GM965 SVGA Controller), I have to load
i915.ko from /boot/loader.conf or via kldload(8) to suspend/resume
from console. Otherwise, I run X.org and use the /etc/rc.suspend and
/etc/rc.resume scripts to invoke vidcontrol(1), switching to ttyv1
before suspend, and switching back to ttyv9 (X.org) after resume. This
is the only way I can "reliably" use suspend/resume.

>From /etc/rc.suspend:
...
/usr/sbin/vidcontrol -s 1 < /dev/console
...

>From /etc/rc.resume:
...
/usr/sbin/vidcontrol -s 9 < /dev/console

-Brandon
From kientzle at freebsd.org  Sat Sep  5 00:45:51 2009
From: kientzle at freebsd.org (Tim Kientzle)
Date: Sat Sep  5 00:46:02 2009
Subject: 'svn add' does not add 'svn:keywords', but 'svn ci' ask for it
In-Reply-To: <20090904055607.GA89117@nagual.pp.ru>
References: <20090904055607.GA89117@nagual.pp.ru>
Message-ID: <4AA1B4BC.2080306@freebsd.org>

Andrey Chernov wrote:
> 1) svn add some_file
> 2) svn ci some_file
> svn: Commit blocked by pre-commit hook (exit code 1) with output:
> Path ".../some_file" is missing the 
> svn:keywords property (or an fbsd:nokeywords override)
> 
> I manage it adding by hand:
> 3) svn propset svn:keywords 'FreeBSD:%H' some_file
> 
> It isn't convenient. Why 'svn add' can't do it automatically for 
> me using the same detection method as 'svn ci'? 

The "svn ci" check is done on the server, and subversion
does not allow the server checks to change the commit
in any way.  The server-side hooks can only inspect
the commit and choose whether or not to permit it.

The "svn add" command doesn't talk to the server at all;
it only modifies the pending update on the local client.

As I think others have pointed out, the standard
"svn" command-line tool does have an option to
automatically set certain properties depending
on the file type.  I believe this check is only
done for "svn add."

Tim
From mav at FreeBSD.org  Sat Sep  5 05:42:41 2009
From: mav at FreeBSD.org (Alexander Motin)
Date: Sat Sep  5 05:42:47 2009
Subject: non aligned DMA transfer attempted
In-Reply-To: <200909042314.n84NEMAS072077@apollo.backplane.com>
References: <h7p0a3$k3m$1@FreeBSD.cs.nctu.edu.tw>
	<4AA03346.5010608@FreeBSD.org>
	<200909032210.n83MA67F059073@apollo.backplane.com>
	<A1B223C6-7291-4F86-B8AC-4EB5EF12F409@samsco.org>
	<200909042314.n84NEMAS072077@apollo.backplane.com>
Message-ID: <4AA1FA41.1030804@FreeBSD.org>

Matthew Dillon wrote:
> :>    The physio code directly maps the userland buffer via vmapbuf() and
> :>    supplies it as a BIO to the device.  The ATA driver does not use
> :>    BUSDMA (and never has)... it assumes BIOs are minimally aligned.
> :
> :Wrong.
> 
>     By the way Scott, do you honestly believe that idiotic one-line
>     answers just as a means to try to screw over my postings are
>     appropriate for someone of your standing in the FreeBSD community?

His answer is short, but correct, because all ATA drivers do use BUSDMA.
And as I have already said, BUSDMA manages proper alignment there, by
implementing bounce buffers.

-- 
Alexander Motin
From dillon at apollo.backplane.com  Sat Sep  5 07:12:00 2009
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Sat Sep  5 07:12:07 2009
Subject: non aligned DMA transfer attempted
References: <h7p0a3$k3m$1@FreeBSD.cs.nctu.edu.tw>
	<4AA03346.5010608@FreeBSD.org>
	<200909032210.n83MA67F059073@apollo.backplane.com>
	<A1B223C6-7291-4F86-B8AC-4EB5EF12F409@samsco.org>
	<200909042314.n84NEMAS072077@apollo.backplane.com>
	<4AA1FA41.1030804@FreeBSD.org>
Message-ID: <200909050711.n857Btwx076830@apollo.backplane.com>


:> 
:>     By the way Scott, do you honestly believe that idiotic one-line
:>     answers just as a means to try to screw over my postings are
:>     appropriate for someone of your standing in the FreeBSD community?
:
:His answer is short, but correct, because all ATA drivers do use BUSDMA.
:And as I have already said, BUSDMA manages proper alignment there, by
:implementing bounce buffers.
:
:-- 
:Alexander Motin

    Perhaps, but it is hardly a civilized conversation.  If he is going to
    act like an asshole on the lists, then he can stew in his own juices
    for all I care, or not post at all.  But acting in such an infantile
    manner is something I will not tolerate.  I really don't care if he
    maps me out of his mail server or not, but playing the 'last word'
    game is something only a 5-year-old would do and he's a lot older
    then 5 years old.

    I do see the FBsd ATA driver is using busdma, so I was incorrect there.
    It is also preallocating bounce buffers on a per-slot basis, so
    you shouldn't get allocation failures later on at load-time (though
    it's a bit unclear if the bounce zone limitations can cause a later
    bus dma load to fail if insufficient bounce buffers are available,
    and allocating bounce buffers per slot can lead to a large multiplication
    of wired memory reserved).  I guess it will work even if it isn't pretty.

    I think there was another issue with ATAPI transfers... something
    related to the DMA having to be in multiples of 16 bytes (on older
    chipsets anyway), but SCSI has no such restriction so pass-through
    commands would not always be properly encapsulated into an ATAPI
    transfer.  I can't find a code reference for it but I remember
    there being some sort of related issue.

    In anycase, the bounce zone mess was why I eventually started doing
    at least a minimal alignment closer to the user<->kernel interface,
    where the kernel could safely allocated memory M_WAITOK.

					-Matt
					Matthew Dillon 
					<dillon@backplane.com>

From michel.junger at gmail.com  Sat Sep  5 08:34:13 2009
From: michel.junger at gmail.com (michel Junger)
Date: Sat Sep  5 08:34:21 2009
Subject: 8.0BETA3 on eee1005ha-h, hardware & acpi issues.
Message-ID: <20090905071250.GA9367@mua.local>

Hello,

I'm trying to install freebsd on an asus eee1005ha-h.
I made the installation using 8.0BETA3 with an usb stick.

Some things don't work as expected or don't work at all.
And more disturbing, some things work but I don't understand why !?

Here is a list of what is already done with questions
for points that are unclear to me.

== things ok without doing anything ==

- The ethernet network adapter use the alc driver, no problem.
- Function keys : backlight control buttons ( fn + f5, f6 ) .
- The sleep button ( fn+f1 ) works too, but you need to
  make some configuration to have a working sleep mode.

== Trouble with ACPI & S3 mode ==

  It was more difficult to get S3 mode working correctly,
  apparently freebsd and acpi on this machine don't work well together.

- In /boot/loader.conf, the line with hint.apic.0.disabled is the
  most important.

- I put hw.pci.do_power_nodriver and kern.hz because I read about those
  variables in the eee wiki page but I don't know why are they usefull.

  It seems that several values are possible for do_power_nodriver,
  maybe 2 or 3 unfortunately I don't know which one is the best ?

  The same for kern.hz, why 100 ? Maybe there's a better value than 100 ?
  it would be nice if someone can give me some clue.

hint.apic.0.disabled="1"
hw.pci.do_power_nodriver=1
kern.hz=100

- The handbook explains how to disassemble the acpi instructions.
  In the generated code several window versions are listed,
  linux is also present but no *bsd ... What a surprise!
  As said in the handbook I put an osname compatible with the acpi code.

hw.acpi.osname="Windows 2001"

- I also had this line. It's necessary to still have the mouse
  when resuming from S3 mode.

hint.psm.0.flags="0x3000"

When S3 sleep is ok ( tested with sync & acpiconf -s S3, be prepare
to violent reboot ), I put the following two lines in /etc/sysctl.conf.
This done,  typing fn+f1 or closing the lid is equivalent
to "Enter S3 mode now".

hw.acpi.sleep_button_state=S3
hw.acpi.lid_switch_state=S3

== Things that don't work correctly ==

- I put hw.acpi.reset_video=1 in /etc/sysctl.conf but during
  few seconds after waking up from S3 sleep the display
  is full of "garbage".

- Sound works with snd_hda.ko module. But if you go in S3 mode,
  even if you have unload snd_hda before, when the system
  wake up and you reload the snd_hda module, the sound card
  is well recognized but it doesn't work (no sound) at all.
  Is there a "trick" to completely re-init sound card ?

- xorg works ( Driver "intel"), but when you're under X11
  if  you decide to return to a text console, the screen is
  suddenly filled with horizontal green and black stripes.
  After that you're just able to properly reboot with ctrl+alt+suppr.
  It looks like the operating system is running with a video console broken.
  On the other hand switching to S3 mode while in X11 works fine.

Things I didn't try to setup : bluetooth / webcam / wifi .

Now I need to setup powerd, build a custom kernel, any url, advice is welcome.
For example I don't which CPUTYPE to use for Atom N280 processor ?

I was helped by the freebsd eee wiki page and the handbook.
The acpi chapter in the handbook is a must-read.

As explained by the handbook I've put result of "boot -v",
"acpidump -dt" and "sysctl hw.acpi." in files donwloaded at :
http://mjunger.atspace.com/fbsd/
If some "acpi guru" can see obvious mistakes, it'll be great.


Michel.



From shoesoft at gmx.net  Sat Sep  5 14:59:42 2009
From: shoesoft at gmx.net (Stefan Ehmann)
Date: Sat Sep  5 14:59:49 2009
Subject: ukbd: short freeze when activating LEDs
Message-ID: <200909051632.55580.shoesoft@gmx.net>

I recently switched from a PS/2 keyboard to USB.

Whenever I press capslock/numlock, the system shortly (< 0.5 ms) freezes. The 
LEDs are switched on/off after that short delay. This also happens when I 
switch between virtual consoles using ALT+F[0-9].

Using a USB->PS/2 adapter, the keyboard doesn't show that behavior.

Otherwise it is working fine.

ukbd0: <vendor 0x046a product 0x0001, class 0/0, rev 2.00/0.26, addr 3> on 
usbus0
kbd2 at ukbd0

This is on 8.0-BETA4/i386.
From billsf at cuba.calyx.nl  Sat Sep  5 15:05:39 2009
From: billsf at cuba.calyx.nl (Bill Squire {billsf})
Date: Sat Sep  5 15:05:46 2009
Subject: v9.0 treating me very well
Message-ID: <20090905150537.GA78983@cuba.calyx.nl>


Hi current-users,

Surely we want v8.0 to work right, but many of the complaints I see have 
already been fixed in v9.0 Its not my call (no way will use a Generic kernel)
but please consider your configurations carefully. If you want to do both you
need a separate base install and a /var. I put multiple base-installs on 
flash ROM drives. Be sure they don't 'require MSDOSFS' to work, but be prepared
to put it back and take it back. (see the ports or emulate, also in the ports)
Hint: 2GiB drives made by a manufacturer I've taken many larger ones back so
I refuse to advertise then, particularly since they have discontinued that
model. Hint: Its a place close to namesake of this server I'm using.

PS: The low-cost (and best sounding) USB chips work out of the box, now on
v9.0 so if you have these try it out. I use balanced audio and have really 
decent speakers -- You know if you read my previous posts.    

Bill Squire  

 
 
From dillon at apollo.backplane.com  Sat Sep  5 15:56:59 2009
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Sat Sep  5 15:57:05 2009
Subject: non aligned DMA transfer attempted
References: <h7p0a3$k3m$1@FreeBSD.cs.nctu.edu.tw>
	<4AA03346.5010608@FreeBSD.org>
	<200909032210.n83MA67F059073@apollo.backplane.com>
	<A1B223C6-7291-4F86-B8AC-4EB5EF12F409@samsco.org>
	<200909042314.n84NEMAS072077@apollo.backplane.com>
	<4AA1FA41.1030804@FreeBSD.org> 
Message-ID: <200909051556.n85Futap080958@apollo.backplane.com>

    Ah, I found the code reference.  This is something I had to throw
    into DFly's version of the ATA driver:

        /*
         * Don't allow DMA for requests with length not multiple of 16 bytes.
         * Some ATAPI devices don't like it.
         */
        if ((softc->atadev[tid]->mode >= ATA_DMA) && len > 0 && !(len & 15))
                request_flags |= ATA_R_DMA;

    It turns out that for non-SATA (older) chipsets ATAPI command DMA is
    speced to only run in multiples of 16 bytes.  If an ATAPI request
    buffer is not a multiple of 16 bytes the two choices are to
    either (1) PAD the request buffer to 16 bytes or (2) Not use a DMA
    transfer mode.  I eventually chose (2).

    The issue with (1) is that the busdma subsystem doesn't really have
    a way to specify a length alignment requirement, only a base offset
    alignment requirement, and buffer passed from userland might be
    declared on the stack so unlike buffers passed by the kernel there may
    not be any extra play in the buffer which allows one to simply DMA a
    little bit more into it.

    I'm fairly sure that SATA chipsets don't care, this seems to be an
    issue with pre-SATA chipsets.

						-Matt

From hselasky at c2i.net  Sat Sep  5 16:02:15 2009
From: hselasky at c2i.net (Hans Petter Selasky)
Date: Sat Sep  5 16:02:22 2009
Subject: ukbd: short freeze when activating LEDs
In-Reply-To: <200909051632.55580.shoesoft@gmx.net>
References: <200909051632.55580.shoesoft@gmx.net>
Message-ID: <200909051802.37902.hselasky@c2i.net>

On Saturday 05 September 2009 16:32:55 Stefan Ehmann wrote:
> Whenever I press capslock/numlock, the system shortly (< 0.5 ms) freezes.

How did you measure this?

Are you able to figure out why it is hanging?

Has this got anything to do with BIOS or microcode running on the CPU?

USB keyboard LEDs are set asynchronously. It should not block like you 
explain.

--HPS

From hselasky at c2i.net  Sat Sep  5 16:05:44 2009
From: hselasky at c2i.net (Hans Petter Selasky)
Date: Sat Sep  5 16:05:50 2009
Subject: ukbd: short freeze when activating LEDs
Message-ID: <200909051806.07692.hselasky@c2i.net>

On Saturday 05 September 2009 16:32:55 Stefan Ehmann wrote:
> Whenever I press capslock/numlock, the system shortly (< 0.5 ms) freezes.

It might also be because the USB keyboard driver is using Giant, which can be 
congested.

--HPS

From shoesoft at gmx.net  Sat Sep  5 16:47:38 2009
From: shoesoft at gmx.net (Stefan Ehmann)
Date: Sat Sep  5 16:47:45 2009
Subject: ukbd: short freeze when activating LEDs
In-Reply-To: <200909051802.37902.hselasky@c2i.net>
References: <200909051632.55580.shoesoft@gmx.net>
	<200909051802.37902.hselasky@c2i.net>
Message-ID: <200909051847.32946.shoesoft@gmx.net>

On Saturday 05 September 2009 18:02:37 you wrote:
> On Saturday 05 September 2009 16:32:55 Stefan Ehmann wrote:
> > Whenever I press capslock/numlock, the system shortly (< 0.5 ms) freezes.
> 
> How did you measure this?
The mouse is not responding and sound also stops during that period.
It's probably much shorter, more likely 0.1-0.2ms. 

> Are you able to figure out why it is hanging?
> 
> Has this got anything to do with BIOS or microcode running on the CPU?
No idea. top shows > 95% interrupt if I'm on the console, in xorg the cpu goes 
to system. Interestingly, the number of interrupts displayed by systat is very 
moderate (if I just move the mouse, it's much higher)

> USB keyboard LEDs are set asynchronously. It should not block like you
> explain.

The keyboard works fine on my notebook. I think the problem is the USB 
controller on my PC, not the keyboard driver. dmesg reports it as
uhci0: <VIA 83C572 USB controller> port 0xb400-0xb41f at device 16.0 on pci0
uhci0: [ITHREAD]
uhci0: LegSup = 0x003a
usbus0: <VIA 83C572 USB controller> on uhci0

Historically, I've always had lots of trouble with USB on this particular PC.
With the old USB code, I've got lots of issues. scanner didn't work at all, 
sometimes even problems with basic things like umass.

With new USB things are much better, but not always perfect.

If there's no easy way to debug, it's probably not worth the hassle. The PC is 
nearing the end of its life-time anyway.

-- 
Thanks,
Stefan
From ben at desync.com  Sat Sep  5 17:17:58 2009
From: ben at desync.com (ben wilber)
Date: Sat Sep  5 17:18:06 2009
Subject: ipv6 addresses on loopback broken
Message-ID: <20090905171756.GA2827@exodus.desync.com>

Hello,

It looks like IPv6 addresses bound to loopback interfaces no longer
work.

% ifconfig lo0
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> metric 0 mtu 16384
        options=3<RXCSUM,TXCSUM>
        inet 127.0.0.1 netmask 0xff000000 
        inet6 ::1 prefixlen 128 
        inet6 fe80::1%lo0 prefixlen 64 scopeid 0x5 
        inet6 2607:f178:0:3::12 prefixlen 128 

% route -n get -inet6 2607:f178:0:3::12
   route to: 2607:f178:0:3::12
destination: ::
       mask: default
    gateway: 2607:f178::1
  interface: mxge0
      flags: <UP,GATEWAY,DONE,STATIC>
 recvpipe  sendpipe  ssthresh  rtt,msec    mtu        weight    expire
       0         0         0         0      1500         1         0 

% uname -a
FreeBSD exodus 9.0-CURRENT FreeBSD 9.0-CURRENT #8: Sat Sep  5 10:23:33 EDT 2009
    bw@exodus:/usr/obj/usr/src/sys/COMRADE  amd64

bw.
From hselasky at c2i.net  Sat Sep  5 17:40:42 2009
From: hselasky at c2i.net (Hans Petter Selasky)
Date: Sat Sep  5 17:40:50 2009
Subject: ukbd: short freeze when activating LEDs
In-Reply-To: <200909051847.32946.shoesoft@gmx.net>
References: <200909051632.55580.shoesoft@gmx.net>
	<200909051802.37902.hselasky@c2i.net>
	<200909051847.32946.shoesoft@gmx.net>
Message-ID: <200909051941.03766.hselasky@c2i.net>

On Saturday 05 September 2009 18:47:32 Stefan Ehmann wrote:
> On Saturday 05 September 2009 18:02:37 you wrote:
> > On Saturday 05 September 2009 16:32:55 Stefan Ehmann wrote:
> > > Whenever I press capslock/numlock, the system shortly (< 0.5 ms)
> > > freezes.
> >
> > How did you measure this?
>
> The mouse is not responding and sound also stops during that period.
> It's probably much shorter, more likely 0.1-0.2ms.
>
> > Are you able to figure out why it is hanging?
> >
> > Has this got anything to do with BIOS or microcode running on the CPU?
>
> No idea. top shows > 95% interrupt if I'm on the console, in xorg the cpu
> goes to system. Interestingly, the number of interrupts displayed by systat
> is very moderate (if I just move the mouse, it's much higher)
>
> > USB keyboard LEDs are set asynchronously. It should not block like you
> > explain.
>
> The keyboard works fine on my notebook. I think the problem is the USB
> controller on my PC, not the keyboard driver. dmesg reports it as
> uhci0: <VIA 83C572 USB controller> port 0xb400-0xb41f at device 16.0 on
> pci0 uhci0: [ITHREAD]
> uhci0: LegSup = 0x003a
> usbus0: <VIA 83C572 USB controller> on uhci0
>
> Historically, I've always had lots of trouble with USB on this particular
> PC. With the old USB code, I've got lots of issues. scanner didn't work at
> all, sometimes even problems with basic things like umass.
>
> With new USB things are much better, but not always perfect.
>
> If there's no easy way to debug, it's probably not worth the hassle. The PC
> is nearing the end of its life-time anyway.

I see. Your observation is interesting and valuable. It might look like some 
piece of hardware is excessively using the RAM. Maybe an USB recording off the 
USB cable will give the final answer. There are some relatively cheap USB 
analyzers from Beagle which you can buy.

--HPS
From qing.li at bluecoat.com  Sat Sep  5 18:20:34 2009
From: qing.li at bluecoat.com (Li, Qing)
Date: Sat Sep  5 18:20:49 2009
Subject: ipv6 addresses on loopback broken
References: <20090905171756.GA2827@exodus.desync.com>
Message-ID: <B583FBF374231F4A89607B4D08578A4304673698@bcs-mail03.internal.cacheflow.com>


>
> It looks like IPv6 addresses bound to loopback interfaces no longer
> work.
>

  Please apply patch

     http://people.freebsd.org/~qingli/qing-ipv6-patch-9-5-1100.diff

  and let me how it works. In the meantime, I will do more testing
  on it.

  Thanks,

  -- Qing
From ed at 80386.nl  Sat Sep  5 18:29:30 2009
From: ed at 80386.nl (Ed Schouten)
Date: Sat Sep  5 18:29:38 2009
Subject: ukbd: short freeze when activating LEDs
In-Reply-To: <200909051806.07692.hselasky@c2i.net>
References: <200909051806.07692.hselasky@c2i.net>
Message-ID: <20090905182929.GB2829@hoeg.nl>

* Hans Petter Selasky <hselasky@c2i.net> wrote:
> On Saturday 05 September 2009 16:32:55 Stefan Ehmann wrote:
> > Whenever I press capslock/numlock, the system shortly (< 0.5 ms) freezes.
> 
> It might also be because the USB keyboard driver is using Giant, which can be 
> congested.

For half a second? I experience the same issue. I also have the same
issue with the Syscons VGA driver when switching windows. Some time ago
I talked about this with some other people and it may be possible it has
something to do with SMIs. Not sure...

-- 
 Ed Schouten <ed@80386.nl>
 WWW: http://80386.nl/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20090905/a22e7761/attachment.pgp
From bruce at cran.org.uk  Sat Sep  5 18:59:18 2009
From: bruce at cran.org.uk (Bruce Cran)
Date: Sat Sep  5 18:59:25 2009
Subject: LOR: kern_exec.c and vfs_cache.c
Message-ID: <20090905195913.0000358e@unknown>

I got this LOR on 8.0-BETA3 when running pmcstat:

lock order reversal:
 1st 0xc55716a0 ufs (ufs) @ /usr/src/sys/kern/kern_exec.c:570
 2nd 0xc98f5a2c filedesc structure (filedesc structure)
@ /usr/src/sys/kern/vfs_cache.c:999 KDB: stack backtrace:
db_trace_self_wrapper(c0c6be4a,e6b5494c,c08bd7f5,c08ae67b,c0c6ed1d,...)
at db_trace_self_wrapper+0x26
kdb_backtrace(c08ae67b,c0c6ed1d,c452f500,c452c1d0,e6b549a8,...) at
kdb_backtrace+0x29
_witness_debugger(c0c6ed1d,c98f5a2c,c0c638c6,c452c1d0,c0c74e88,...) at
_witness_debugger+0x25
witness_checkorder(c98f5a2c,1,c0c74e88,3e7,0,...) at
witness_checkorder+0x839
_sx_slock(c98f5a2c,0,c0c74e88,3e7,c497a6c0,...) at _sx_slock+0x85
vn_fullpath(c497a6c0,c5571648,e6b54aa4,e6b54aa0,0,...) at
vn_fullpath+0x74 pmc_getfilename(c0c60fc0,3,c497a6c0,e6b54a60,246,...)
at pmc_getfilename+0x2e
pmc_hook_handler(c497a6c0,1,e6b54c1c,318,c0c90edb,...) at
pmc_hook_handler+0x279
kern_execve(c497a6c0,e6b54c58,0,283052a8,28305348,e164d000,e164d000,e164d020,e164d485,e168d000,3fb7b,3,24,0)
at kern_execve+0xe1c execve(c497a6c0,e6b54cfc,c,c497a6c0,c0d4e474,...)
at execve+0x4c syscall(e6b54d38) at syscall+0x2a3 Xint0x80_syscall() at
Xint0x80_syscall+0x20 --- syscall (59, FreeBSD ELF32, execve), eip =
0x28173eaf, esp = 0xbfbfe34c, ebp = 0xbfbfe378 ---


-- 
Bruce Cran
From bruce at cran.org.uk  Sat Sep  5 19:06:47 2009
From: bruce at cran.org.uk (Bruce Cran)
Date: Sat Sep  5 19:06:54 2009
Subject: ukbd: short freeze when activating LEDs
In-Reply-To: <20090905182929.GB2829@hoeg.nl>
References: <200909051806.07692.hselasky@c2i.net>
	<20090905182929.GB2829@hoeg.nl>
Message-ID: <20090905200653.000057c8@unknown>

On Sat, 5 Sep 2009 20:29:29 +0200
Ed Schouten <ed@80386.nl> wrote:

> * Hans Petter Selasky <hselasky@c2i.net> wrote:
> > On Saturday 05 September 2009 16:32:55 Stefan Ehmann wrote:
> > > Whenever I press capslock/numlock, the system shortly (< 0.5 ms)
> > > freezes.
> > 
> > It might also be because the USB keyboard driver is using Giant,
> > which can be congested.
> 
> For half a second? I experience the same issue. I also have the same
> issue with the Syscons VGA driver when switching windows. Some time
> ago I talked about this with some other people and it may be possible
> it has something to do with SMIs. Not sure...
> 

Half a millisecond or, as reported in another message, 100us :)
I suspect the OP probably did mean 0.5s, a pause which someone can both
see and hear.

-- 
Bruce Cran
From scottl at samsco.org  Sat Sep  5 19:33:18 2009
From: scottl at samsco.org (Scott Long)
Date: Sat Sep  5 19:33:25 2009
Subject: non aligned DMA transfer attempted
In-Reply-To: <4AA1FA41.1030804@FreeBSD.org>
References: <h7p0a3$k3m$1@FreeBSD.cs.nctu.edu.tw>
	<4AA03346.5010608@FreeBSD.org>
	<200909032210.n83MA67F059073@apollo.backplane.com>
	<A1B223C6-7291-4F86-B8AC-4EB5EF12F409@samsco.org>
	<200909042314.n84NEMAS072077@apollo.backplane.com>
	<4AA1FA41.1030804@FreeBSD.org>
Message-ID: <E26273AF-E19A-404E-9EA0-BAACE448CA76@samsco.org>


On Sep 4, 2009, at 11:42 PM, Alexander Motin wrote:

> Matthew Dillon wrote:
>> :>    The physio code directly maps the userland buffer via vmapbuf 
>> () and
>> :>    supplies it as a BIO to the device.  The ATA driver does not  
>> use
>> :>    BUSDMA (and never has)... it assumes BIOs are minimally  
>> aligned.
>> :
>> :Wrong.
>>
>>    By the way Scott, do you honestly believe that idiotic one-line
>>    answers just as a means to try to screw over my postings are
>>    appropriate for someone of your standing in the FreeBSD community?
>
> His answer is short, but correct, because all ATA drivers do use  
> BUSDMA.
> And as I have already said, BUSDMA manages proper alignment there, by
> implementing bounce buffers.
>

Matt typically doesn't listen to what others have to say in  
disagreement anyways, so I didn't see a whole lot of value in wasting  
my time with long answers with him.  However, others have asked me for  
more thorough explanations in private, and I'll attempt to provide  
them here:

1.  Alexander is correct, ata has used busdma for many years.  This  
may be different in DillonBSD, but we're talking about FreeBSD here.  
As such, it was hard to engage further in the conversation given the  
basic disconnect in understanding.

2. The CAM passthrough doesn't care a whole lot about alignment  
because alignment is the concern of the SIMs in conjunction with  
busdma, not the periph and transport layers of CAM.  There is one  
exception to this, which is the physaddr data transfer mode in CAM.   
busdma doesn't understand this mode.  However, nothing in FreeBSD uses  
this mode; it's a legacy remnant from many years ago.  Most SIMs  
choose to ignore this interface anyways (recall that SIMs are  
responsible for alignment, not the rest of CAM), so it's not an issue  
except on a small selection of hardware, using custom software (i.e.  
close source large appliance software not found in the ports tree)  
that deliberately selects the interface.

3. Adding alignment bouncing logic to every driver in the tree is  
silly when it already exists in busdma.  Granted, I didn't implement  
this feature very well originally, so there were bugs that made it  
less useful.  However, I think that most of those bugs have been  
fixed, and any that remain can and should be fixed.

4. The vast majority of the storage drivers in the tree use busdma and  
use it correctly for deferred loads.  This wasn't the case many years  
ago, and may not be the case in DillonBSD, but again, we're talking  
about FreeBSD here.  There might be a few drivers left that don't  
fully conform to the API (ATA was a big one, which is one of the many  
reasons that the new generation of SATA drivers was written), and I'm  
happy to help others fix any drivers that remain and are causing  
problems.

Again, I'm happy to discuss this further.  I apologize for the terse  
answers to the community, and I hope this has cleared up the problem.

Scott

From kostikbel at gmail.com  Sat Sep  5 19:41:51 2009
From: kostikbel at gmail.com (Kostik Belousov)
Date: Sat Sep  5 19:41:58 2009
Subject: LOR: kern_exec.c and vfs_cache.c
In-Reply-To: <20090905195913.0000358e@unknown>
References: <20090905195913.0000358e@unknown>
Message-ID: <20090905194142.GE47688@deviant.kiev.zoral.com.ua>

On Sat, Sep 05, 2009 at 07:59:13PM +0100, Bruce Cran wrote:
> I got this LOR on 8.0-BETA3 when running pmcstat:
> 
> lock order reversal:
>  1st 0xc55716a0 ufs (ufs) @ /usr/src/sys/kern/kern_exec.c:570
>  2nd 0xc98f5a2c filedesc structure (filedesc structure)
> @ /usr/src/sys/kern/vfs_cache.c:999 KDB: stack backtrace:
> db_trace_self_wrapper(c0c6be4a,e6b5494c,c08bd7f5,c08ae67b,c0c6ed1d,...)
> at db_trace_self_wrapper+0x26
> kdb_backtrace(c08ae67b,c0c6ed1d,c452f500,c452c1d0,e6b549a8,...) at
> kdb_backtrace+0x29
> _witness_debugger(c0c6ed1d,c98f5a2c,c0c638c6,c452c1d0,c0c74e88,...) at
> _witness_debugger+0x25
> witness_checkorder(c98f5a2c,1,c0c74e88,3e7,0,...) at
> witness_checkorder+0x839
> _sx_slock(c98f5a2c,0,c0c74e88,3e7,c497a6c0,...) at _sx_slock+0x85
> vn_fullpath(c497a6c0,c5571648,e6b54aa4,e6b54aa0,0,...) at
> vn_fullpath+0x74 pmc_getfilename(c0c60fc0,3,c497a6c0,e6b54a60,246,...)
> at pmc_getfilename+0x2e
> pmc_hook_handler(c497a6c0,1,e6b54c1c,318,c0c90edb,...) at
> pmc_hook_handler+0x279
> kern_execve(c497a6c0,e6b54c58,0,283052a8,28305348,e164d000,e164d000,e164d020,e164d485,e168d000,3fb7b,3,24,0)
> at kern_execve+0xe1c execve(c497a6c0,e6b54cfc,c,c497a6c0,c0d4e474,...)
> at execve+0x4c syscall(e6b54d38) at syscall+0x2a3 Xint0x80_syscall() at
> Xint0x80_syscall+0x20 --- syscall (59, FreeBSD ELF32, execve), eip =
> 0x28173eaf, esp = 0xbfbfe34c, ebp = 0xbfbfe378 ---

The following should fix the LOR and make vfs_mark_atime more resistent
to the supplied doomed vnode.

diff --git a/sys/kern/kern_exec.c b/sys/kern/kern_exec.c
index e770d07..a90968f 100644
--- a/sys/kern/kern_exec.c
+++ b/sys/kern/kern_exec.c
@@ -786,10 +786,12 @@ interpret:
 	 */
 	if (PMC_SYSTEM_SAMPLING_ACTIVE() || PMC_PROC_IS_USING_PMCS(p)) {
 		PROC_UNLOCK(p);
+		VOP_UNLOCK(imgp->vp, 0);
 		pe.pm_credentialschanged = credential_changing;
 		pe.pm_entryaddr = imgp->entry_addr;
 
 		PMC_CALL_HOOK_X(td, PMC_FN_PROCESS_EXEC, (void *) &pe);
+		vn_lock(imgp->vp, LK_EXCLUSIVE | LK_RETRY);
 	} else
 		PROC_UNLOCK(p);
 #else  /* !HWPMC_HOOKS */
diff --git a/sys/kern/vfs_subr.c b/sys/kern/vfs_subr.c
index 3beb881..f3ec565 100644
--- a/sys/kern/vfs_subr.c
+++ b/sys/kern/vfs_subr.c
@@ -4269,8 +4269,12 @@ vfs_read_dirent(struct vop_readdir_args *ap, struct dirent *dp, off_t off)
 void
 vfs_mark_atime(struct vnode *vp, struct ucred *cred)
 {
+	struct mount *mp;
 
-	if ((vp->v_mount->mnt_flag & (MNT_NOATIME | MNT_RDONLY)) == 0)
+	mp = vp->v_mount;
+	VFS_ASSERT_GIANT(mp);
+	ASSERT_VOP_LOCKED(vp, "vfs_mark_atime");
+	if (mp != NULL && (mp->mnt_flag & (MNT_NOATIME | MNT_RDONLY)) == 0)
 		(void)VOP_MARKATIME(vp);
 }
 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20090905/98164192/attachment.pgp
From ben at desync.com  Sat Sep  5 19:57:59 2009
From: ben at desync.com (ben wilber)
Date: Sat Sep  5 19:58:05 2009
Subject: ipv6 addresses on loopback broken
In-Reply-To: <B583FBF374231F4A89607B4D08578A4304673698@bcs-mail03.internal.cacheflow.com>
References: <20090905171756.GA2827@exodus.desync.com>
	<B583FBF374231F4A89607B4D08578A4304673698@bcs-mail03.internal.cacheflow.com>
Message-ID: <20090905195753.GA2581@exodus.desync.com>

On Sat, Sep 05, 2009 at 11:11:08AM -0700, Li, Qing wrote:
> >
> > It looks like IPv6 addresses bound to loopback interfaces no longer
> > work.
> >
> 
>   Please apply patch
> 
>      http://people.freebsd.org/~qingli/qing-ipv6-patch-9-5-1100.diff
> 
>   and let me how it works. In the meantime, I will do more testing
>   on it.

Applied to r196870, problem gone.

Thanks,
bw.
From dillon at apollo.backplane.com  Sat Sep  5 20:04:54 2009
From: dillon at apollo.backplane.com (Matthew Dillon)
Date: Sat Sep  5 20:05:01 2009
Subject: non aligned DMA transfer attempted
References: <h7p0a3$k3m$1@FreeBSD.cs.nctu.edu.tw>
	<4AA03346.5010608@FreeBSD.org>
	<200909032210.n83MA67F059073@apollo.backplane.com>
	<A1B223C6-7291-4F86-B8AC-4EB5EF12F409@samsco.org>
	<200909042314.n84NEMAS072077@apollo.backplane.com>
	<4AA1FA41.1030804@FreeBSD.org>
	<E26273AF-E19A-404E-9EA0-BAACE448CA76@samsco.org>
Message-ID: <200909052004.n85K4pvP083476@apollo.backplane.com>

    It's really unfortunate that after all these years you don't seem
    to know the name of our project.

    Insofar as listening to people go... I certainly do, as long as they
    are courteous.  But, unfortunately, numerous FreeBSD people, some all
    the way back to the very day I first became a committer all those years
    ago, seem to have severe problems interacting with their peers on
    any level.  I guess those people are all running the show now.

    If this was an attempt at diplomacy, Scott, you could have removed
    the veiled insults... and it probably would have worked.

						-Matt

From dougb at FreeBSD.org  Sat Sep  5 20:13:27 2009
From: dougb at FreeBSD.org (Doug Barton)
Date: Sat Sep  5 20:13:34 2009
Subject: [Call For Testing] VirtualBox for FreeBSD! take 4
In-Reply-To: <6201873e0909040536y2a2c7a22t30247d61adc26318@mail.gmail.com>
References: <20090527134343.GB1104@bsdcrew.de>	<85d001330905270909jde4d723s65e8708a8b498c29@mail.gmail.com>	<20090527163952.GI1104@bsdcrew.de>
	<4AA0149E.30209@lapo.it>	<6201873e0909031252r41bced2eqe1784a17214f1cd1@mail.gmail.com>	<4AA09410.8020302@lapo.it>
	<6201873e0909040536y2a2c7a22t30247d61adc26318@mail.gmail.com>
Message-ID: <4AA2C659.8050800@FreeBSD.org>

Adam Vande More wrote:

> I believe portmaster uses a lot environmental variables, and kBuild does
> something funky with them.  So technically, the issue lies w/ kBuild, not
> portmaster.  At least that's what I read.

Yes, that's correct.


Doug
From stb at lassitu.de  Sat Sep  5 20:20:59 2009
From: stb at lassitu.de (Stefan Bethke)
Date: Sat Sep  5 20:21:06 2009
Subject: Elsa MicroLink 56k USB is not picked up by umodem
In-Reply-To: <200909012357.42238.hselasky@c2i.net>
References: <15577E21-9A9B-45CA-BC56-D1AB1FF6A5A9@lassitu.de>
	<200909012250.48439.hselasky@c2i.net>
	<CCD5E96B-30A7-4CE6-84B7-0DC1C364C674@lassitu.de>
	<200909012357.42238.hselasky@c2i.net>
Message-ID: <C0A7294C-F239-4AA1-B4F7-A62F1AEBD967@lassitu.de>

Am 01.09.2009 um 23:57 schrieb Hans Petter Selasky:

>> # usbconfig -u 0 -a 3 set_config 1
>> umodem0: <vendor 0x05cc product 0x2265, class 2/0, rev 1.00/1.00,  
>> addr
>> 3> on usbus0
>> umodem0: data interface 1, has CM over data, has break
>>
>> Checking quickly with cu, I can make it dial out.
>
> kldload usb_quirk
>
> usbconfig dump_quirk_names
>
> And then run something like:
>
> usbconfig add_dev_quirk_vplh 0x??? 0x??? 0x0000 0xFFFF UQ_CFG_INDEX_1
>
> Will make the quirk permanent.
>
> If you make a patch for usbdevs and the usb_quirk.c in /sys/dev/usb/ 
> quirk/
> then I can commit that.

Index: usb_quirk.c
===================================================================
--- usb_quirk.c	(revision 196650)
+++ usb_quirk.c	(working copy)
@@ -94,6 +94,7 @@
  	{USB_QUIRK_ENTRY(USB_VENDOR_TELEX, USB_PRODUCT_TELEX_MIC1, 0x009,  
0x009, UQ_AU_NO_FRAC, UQ_NONE)},
  	{USB_QUIRK_ENTRY(USB_VENDOR_SILICONPORTALS,  
USB_PRODUCT_SILICONPORTALS_YAPPHONE, 0x100, 0x100, UQ_AU_INP_ASYNC,  
UQ_NONE)},
  	{USB_QUIRK_ENTRY(USB_VENDOR_LOGITECH, USB_PRODUCT_LOGITECH_UN53B,  
0x0000, 0xFFFF, UQ_NO_STRINGS, UQ_NONE)},
+	{USB_QUIRK_ENTRY(USB_VENDOR_ELSA, USB_PRODUCT_ELSA_MODEM1, 0x0000,  
0xFFFF, UQ_CFG_INDEX_1, UQ_NONE)},

  	/*
  	 * XXX The following quirks should have a more specific revision


Thanks,
Stefan

-- 
Stefan Bethke <stb@lassitu.de>   Fon +49 151 14070811




From shoesoft at gmx.net  Sun Sep  6 00:07:11 2009
From: shoesoft at gmx.net (Stefan Ehmann)
Date: Sun Sep  6 00:07:18 2009
Subject: ukbd: short freeze when activating LEDs
In-Reply-To: <20090905200653.000057c8@unknown>
References: <200909051806.07692.hselasky@c2i.net>
	<20090905182929.GB2829@hoeg.nl> <20090905200653.000057c8@unknown>
Message-ID: <200909060207.06700.shoesoft@gmx.net>

On Saturday 05 September 2009 21:06:53 Bruce Cran wrote:
> On Sat, 5 Sep 2009 20:29:29 +0200
> 
> Ed Schouten <ed@80386.nl> wrote:
> > * Hans Petter Selasky <hselasky@c2i.net> wrote:
> > > On Saturday 05 September 2009 16:32:55 Stefan Ehmann wrote:
> > > > Whenever I press capslock/numlock, the system shortly (< 0.5 ms)
> > > > freezes.
> > >
> > > It might also be because the USB keyboard driver is using Giant,
> > > which can be congested.
> >
> > For half a second? I experience the same issue. I also have the same
> > issue with the Syscons VGA driver when switching windows. Some time
> > ago I talked about this with some other people and it may be possible
> > it has something to do with SMIs. Not sure...
> 
> Half a millisecond or, as reported in another message, 100us :)
> I suspect the OP probably did mean 0.5s, a pause which someone can both
> see and hear.
> 
Oops. Of course you're right. For some reason I consistently wrote ms instead 
of seconds. It's a noticable delay for humans :)
From h.schmalzbauer at omnilan.de  Sun Sep  6 03:32:18 2009
From: h.schmalzbauer at omnilan.de (Harald Schmalzbauer)
Date: Sun Sep  6 03:32:24 2009
Subject: acd timeouts
Message-ID: <4AA32D35.5090204@omnilan.de>

Hello,

trying to rip audio from my - especially for this purpose reactivated - 
ATAPI CD-rom results in:

acd0: WARNING - READ_CD read data overrun 2352>0
acd0: WARNING - READ_CD read data overrun 2352>0
acd0: WARNING - READ_CD read data overrun 2352>0
acd0: MODE_SELECT_BIG trying to write on read buffer
acd0: timeout waiting for ATAPI ready
acd0: error issuing ATA PACKET command
acd0: timeout waiting for ATAPI ready
acd0: error issuing ATA PACKET command

System is BETA4, ahci.ko loaded, but this doesn't matter on IDE devices, 
right?
Any hints?

Thanks,

-Harry

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 196 bytes
Desc: OpenPGP digital signature
Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20090906/45bcfd67/signature.pgp
From h.schmalzbauer at omnilan.de  Sun Sep  6 04:43:49 2009
From: h.schmalzbauer at omnilan.de (Harald Schmalzbauer)
Date: Sun Sep  6 04:43:56 2009
Subject: Funding ODD support
Message-ID: <4AA33DF9.6070803@omnilan.de>

Hello,

I'm looking for somebody who has time and knowledge to fix ODD support 
in FreeBSD.
I'm willing to sponsor a decent ammount.
My problem is that I can't use FreeBSD for any task in which CD or DVD 
is involved.
What I want is read/write support for any ATAPI/S-ATA ODD regarding 
ISO9660 and audio. Of course I'd love to have UDF support also, but for 
the beginning I'd be glad if FreeBSD could boot with an inserted audio 
CD. This has been a problem for more than two years now, and disabling 
DMA support for ata devices isn't a satisfying solution.

So if you think ypu can fix this and make growisofs and cdrtools working 
with ATAPI and SATA devices, please contact me.
If we have working ODD support in 8.0-release I'll donate 100 extra bucks.

Thanks,

-Harry

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 196 bytes
Desc: OpenPGP digital signature
Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20090906/99ce4617/signature.pgp
From admin at lissyara.su  Sun Sep  6 09:46:24 2009
From: admin at lissyara.su (Alex Keda)
Date: Sun Sep  6 09:46:31 2009
Subject: Fatal trap 12: page fault while in kernel mode
Message-ID: <4AA384EC.3060003@lissyara.su>

hi!
I have fatal trap with today (and yesterday) current.
Machine boot, I see:
Timecounters tick every 1.000 msec
then, it freese ~30 seconds and go to kernel debugger - fatal trap 12
stopped at _mtx_lock_spin_failed+0x2f: movl 0x78(%r12),%r8d
From danny at cs.huji.ac.il  Sun Sep  6 10:40:38 2009
From: danny at cs.huji.ac.il (Danny Braniss)
Date: Sun Sep  6 10:40:46 2009
Subject: [Call For Testing] VirtualBox for FreeBSD! take 6 
In-Reply-To: <20090611194557.GC98175@bsdcrew.de> 
References: <20090611194557.GC98175@bsdcrew.de>
Message-ID: <E1MkFAi-0005OD-K0@kabab.cs.huji.ac.il>

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Huhu,
> 
> Yes we life and that's good :-).
> Changes:
> 
>   - Fix build error when compiling in debug mode on FreeBSD HEAD
>   - SemEvent?-r0drv/FreeBSD: Don't use tvtohz for an infinite timeout. 
>   - Some FreeBSD relate typos
>   - Enable shared OpenGL service. Completely untested due to lack of
>     appropriate hardware but it compiles at least 
>   - Add support for shared clipboards. Requires libXt
>   - FreeBSD: Implement preemption API for guest SMP and enable
>     it (slightly tested). Add neccessary RTMP* methods in userspace
>     for the frontends to detect the number of CPUs
>   - Runtime/semevent-r0drv-freebsd: Use a sleeping mutex
>     instead of a spinlock to fix the problems users are seeing
>     (assertions with debugging enabled) while still being able
>     to run on 100Hz hosts. No problems detected so far and Solaris
>     doesn't use a spin mutex in this code too so it shouldn't do
>     any harm (keeping fingers crossed)space for the frontends to
>     detect the number of CPUs
>   - Add support for curl
>   - Add VBoxSharedClipboard
> 
> Ports Changes;
>   - Force guestadditions version to 2.2.4
>   - Removed Qt3 include replacements (already upstream)
>   - Removed cosmetic X11 include path patch
> 
> Please make SURE, your world and kernel is in sync and you've read
> the pkg-messages. Also please unload the kernel module before
> you update the port ;-).
> 
> Many thx to all Vbox Devs, All supporters, my nice team! :-)
> 
>    http://people.freebsd.org/~miwi/vbox/virtualbox_6.tgz
> 
>  Happy Testing!
> 
ok, so some time has passed, but virtualbox-2.2.51r20457.tar.gz is no
longer available, there is a  ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/distfiles/virtualbox-2.2.51r20457.tar.bz2
then again in ports/emulatores/virtualbox the version is 3.0.51r22226,

can someone please explain?

	danny


From admin at lissyara.su  Sun Sep  6 14:58:05 2009
From: admin at lissyara.su (Alex Keda)
Date: Sun Sep  6 14:58:12 2009
Subject: Fatal trap 12: page fault while in kernel mode
In-Reply-To: <4AA384EC.3060003@lissyara.su>
References: <4AA384EC.3060003@lissyara.su>
Message-ID: <4AA3CDFA.4040008@lissyara.su>

Alex Keda ?????:
> hi!
> I have fatal trap with today (and yesterday) current.
> Machine boot, I see:
> Timecounters tick every 1.000 msec
> then, it freese ~30 seconds and go to kernel debugger - fatal trap 12
> stopped at _mtx_lock_spin_failed+0x2f: movl 0x78(%r12),%r8d
it's amd64.
From aman.jassal at esigetel.fr  Sun Sep  6 15:11:51 2009
From: aman.jassal at esigetel.fr (Aman Jassal)
Date: Sun Sep  6 15:11:58 2009
Subject: Problems with IPSec during kernel compilation with sources from
	CURRENT 9.0
Message-ID: <9FFF3C23C8EB4ED2A0445B064991E774@PCdeKimKas>

Dear all,

I performed an upgrade of my kernel sources this morning using CVSup, and successfully retrieved all the sources from HEAD (CURRENT 9.0).

I then performed a kernel compilation to upgrade it, and since I wanted to test out IPSec, I added the following lines in my kernel configuration file :

Options        IPSEC
Options        IPSEC_DEBUG

But the kernel compilation doesn't go through and I get errors. Here are the errors I got (it's a bit long) :


xform_ah.o(.text+0x13): In function `ah_algorithm_lookup':
/usr/src/sys/netipsec/xform_ah.c:116: undefined reference to `auth_hash_hmac_sha2_512'
xform_ah.o(.text+0x26):/usr/src/sys/netipsec/xform_ah.c:120: undefined reference to `auth_hash_hmac_sha1'
xform_ah.o(.text+0x43):/usr/src/sys/netipsec/xform_ah.c:128: undefined reference to `auth_hash_hmac_sha2_256'
xform_ah.o(.text+0x55):/usr/src/sys/netipsec/xform_ah.c:124: undefined reference to `auth_hash_key_md5'
xform_ah.o(.text+0x73):/usr/src/sys/netipsec/xform_ah.c:126: undefined reference to `auth_hash_key_sha1'
xform_ah.o(.text+0x80):/usr/src/sys/netipsec/xform_ah.c:116: undefined reference to `auth_hash_null'
xform_ah.o(.text+0x8f):/usr/src/sys/netipsec/xform_ah.c:118: undefined reference to `auth_hash_hmac_md5'
xform_ah.o(.text+0x96):/usr/src/sys/netipsec/xform_ah.c:122: undefined reference to `auth_hash_hmac_ripemd_160'
xform_ah.o(.text+0x9d):/usr/src/sys/netipsec/xform_ah.c:130: undefined reference to `auth_hash_hmac_sha2_384'
xform_ah.o(.text+0x540): In function `ah_massage_headers':
/usr/src/sys/netipsec/xform_ah.c:432: undefined reference to `M_XDATA'
xform_ah.o(.text+0x623):/usr/src/sys/netipsec/xform_ah.c:485: undefined reference to `M_XDATA'
xform_ah.o(.text+0x688):/usr/src/sys/netipsec/xform_ah.c:505: undefined reference to `M_XDATA'
xform_ah.o(.text+0x705):/usr/src/sys/netipsec/xform_ah.c:529: undefined reference to `M_XDATA'
xform_ah.o(.text+0x756):/usr/src/sys/netipsec/xform_ah.c:538: undefined reference to `M_XDATA'
xform_ah.o(.text+0x8dc): In function `ah_output_cb':
/usr/src/sys/netipsec/xform_ah.c:1146: undefined reference to `crypto_dispatch'
xform_ah.o(.text+0x986):/usr/src/sys/netipsec/xform_ah.c:1172: undefined reference to `M_XDATA'
xform_ah.o(.text+0x996):/usr/src/sys/netipsec/xform_ah.c:1173: undefined reference to `crypto_freereq'
xform_ah.o(.text+0xa49):/usr/src/sys/netipsec/xform_ah.c:1200: undefined reference to `M_XDATA'
xform_ah.o(.text+0xa59):/usr/src/sys/netipsec/xform_ah.c:1201: undefined reference to `crypto_freereq'
xform_ah.o(.text+0xb79): In function `ah_input_cb':
/usr/src/sys/netipsec/xform_ah.c:768: undefined reference to `crypto_dispatch'
xform_ah.o(.text+0xbd0):/usr/src/sys/netipsec/xform_ah.c:778: undefined reference to `crypto_freereq'
xform_ah.o(.text+0xd32):/usr/src/sys/netipsec/xform_ah.c:825: undefined reference to `M_XDATA'
xform_ah.o(.text+0xebc):/usr/src/sys/netipsec/xform_ah.c:869: undefined reference to `M_XDATA'
xform_ah.o(.text+0xed0):/usr/src/sys/netipsec/xform_ah.c:871: undefined reference to `crypto_freereq'
xform_ah.o(.text+0x10e7): In function `ah_init':
/usr/src/sys/netipsec/xform_ah.c:221: undefined reference to `crypto_newsession'
xform_ah.o(.text+0x1148): In function `ah_zeroize':
/usr/src/sys/netipsec/xform_ah.c:238: undefined reference to `crypto_freesession'
xform_ah.o(.text+0x1469): In function `ah_output':
/usr/src/sys/netipsec/xform_ah.c:1003: undefined reference to `crypto_getreq'
xform_ah.o(.text+0x14e3):/usr/src/sys/netipsec/xform_ah.c:1024: undefined reference to `M_XDATA'
xform_ah.o(.text+0x1500):/usr/src/sys/netipsec/xform_ah.c:1027: undefined reference to `crypto_freereq'
xform_ah.o(.text+0x1676):/usr/src/sys/netipsec/xform_ah.c:1078: undefined reference to `M_XDATA'
xform_ah.o(.text+0x168c):/usr/src/sys/netipsec/xform_ah.c:1079: undefined reference to `crypto_freereq'
xform_ah.o(.text+0x171f):/usr/src/sys/netipsec/xform_ah.c:1099: undefined reference to `crypto_dispatch'
xform_ah.o(.text+0x1971): In function `ah_input':
/usr/src/sys/netipsec/xform_ah.c:608: undefined reference to `crypto_getreq'
xform_ah.o(.text+0x1ab4):/usr/src/sys/netipsec/xform_ah.c:646: undefined reference to `M_XDATA'
xform_ah.o(.text+0x1af8):/usr/src/sys/netipsec/xform_ah.c:652: undefined reference to `crypto_freereq'
xform_ah.o(.text+0x1b93):/usr/src/sys/netipsec/xform_ah.c:676: undefined reference to `M_XDATA'
xform_ah.o(.text+0x1ba9):/usr/src/sys/netipsec/xform_ah.c:677: undefined reference to `crypto_freereq'
xform_ah.o(.text+0x1c4d):/usr/src/sys/netipsec/xform_ah.c:700: undefined reference to `crypto_dispatch'
xform_ah.o(.text+0x1c77):/usr/src/sys/netipsec/xform_ah.c:642: undefined reference to `M_XDATA'
xform_esp.o(.text+0xf): In function `esp_algorithm_lookup':
/usr/src/sys/netipsec/xform_esp.c:110: undefined reference to `enc_xform_blf'
xform_esp.o(.text+0x1e):/usr/src/sys/netipsec/xform_esp.c:106: undefined reference to `enc_xform_3des'
xform_esp.o(.text+0x28):/usr/src/sys/netipsec/xform_esp.c:112: undefined reference to `enc_xform_cast5'
xform_esp.o(.text+0x39):/usr/src/sys/netipsec/xform_esp.c:108: undefined reference to `enc_xform_rijndael128'
xform_esp.o(.text+0x53):/usr/src/sys/netipsec/xform_esp.c:104: undefined reference to `enc_xform_camellia'
xform_esp.o(.text+0x67):/usr/src/sys/netipsec/xform_esp.c:104: undefined reference to `enc_xform_des'
xform_esp.o(.text+0x6e):/usr/src/sys/netipsec/xform_esp.c:114: undefined reference to `enc_xform_skipjack'
xform_esp.o(.text+0x75):/usr/src/sys/netipsec/xform_esp.c:116: undefined reference to `enc_xform_null'
xform_esp.o(.text+0x99): In function `esp_attach':
/usr/src/sys/netipsec/xform_esp.c:992: undefined reference to `enc_xform_des'
xform_esp.o(.text+0xad):/usr/src/sys/netipsec/xform_esp.c:993: undefined reference to `enc_xform_3des'
xform_esp.o(.text+0xc1):/usr/src/sys/netipsec/xform_esp.c:994: undefined reference to `enc_xform_rijndael128'
xform_esp.o(.text+0xd5):/usr/src/sys/netipsec/xform_esp.c:995: undefined reference to `enc_xform_blf'
xform_esp.o(.text+0xe9):/usr/src/sys/netipsec/xform_esp.c:996: undefined reference to `enc_xform_cast5'
xform_esp.o(.text+0xfd):/usr/src/sys/netipsec/xform_esp.c:997: undefined reference to `enc_xform_skipjack'
xform_esp.o(.text+0x111):/usr/src/sys/netipsec/xform_esp.c:998: undefined reference to `enc_xform_null'
xform_esp.o(.text+0x125):/usr/src/sys/netipsec/xform_esp.c:999: undefined reference to `enc_xform_camellia'
xform_esp.o(.text+0x2bb): In function `esp_input_cb':
/usr/src/sys/netipsec/xform_esp.c:502: undefined reference to `crypto_dispatch'
xform_esp.o(.text+0x417):/usr/src/sys/netipsec/xform_esp.c:554: undefined reference to `M_XDATA'
xform_esp.o(.text+0x427):/usr/src/sys/netipsec/xform_esp.c:555: undefined reference to `crypto_freereq'
xform_esp.o(.text+0x762):/usr/src/sys/netipsec/xform_esp.c:639: undefined reference to `M_XDATA'
xform_esp.o(.text+0x776):/usr/src/sys/netipsec/xform_esp.c:641: undefined reference to `crypto_freereq'
xform_esp.o(.text+0x7e0): In function `esp_zeroize':
/usr/src/sys/netipsec/xform_esp.c:258: undefined reference to `M_XDATA'
xform_esp.o(.text+0x946): In function `esp_init':
/usr/src/sys/netipsec/xform_esp.c:198: undefined reference to `enc_xform_null'
xform_esp.o(.text+0x95f):/usr/src/sys/netipsec/xform_esp.c:199: undefined reference to `M_XDATA'
xform_esp.o(.text+0xa2b):/usr/src/sys/netipsec/xform_esp.c:229: undefined reference to `crypto_newsession'
xform_esp.o(.text+0xa4e):/usr/src/sys/netipsec/xform_esp.c:232: undefined reference to `crypto_newsession'
xform_esp.o(.text+0xa9e):/usr/src/sys/netipsec/xform_esp.c:235: undefined reference to `crypto_newsession'
xform_esp.o(.text+0xcb2): In function `esp_output_cb':
/usr/src/sys/netipsec/xform_esp.c:920: undefined reference to `crypto_dispatch'
xform_esp.o(.text+0xd5d):/usr/src/sys/netipsec/xform_esp.c:942: undefined reference to `M_XDATA'
xform_esp.o(.text+0xd70):/usr/src/sys/netipsec/xform_esp.c:943: undefined reference to `crypto_freereq'
xform_esp.o(.text+0xe1e):/usr/src/sys/netipsec/xform_esp.c:974: undefined reference to `M_XDATA'
xform_esp.o(.text+0xe31):/usr/src/sys/netipsec/xform_esp.c:975: undefined reference to `crypto_freereq'
xform_esp.o(.text+0x1235): In function `esp_output':
/usr/src/sys/netipsec/xform_esp.c:810: undefined reference to `crypto_getreq'
xform_esp.o(.text+0x12ba):/usr/src/sys/netipsec/xform_esp.c:838: undefined reference to `M_XDATA'
xform_esp.o(.text+0x12d4):/usr/src/sys/netipsec/xform_esp.c:841: undefined reference to `crypto_freereq'
xform_esp.o(.text+0x13b0):/usr/src/sys/netipsec/xform_esp.c:874: undefined reference to `crypto_dispatch'
xform_esp.o(.text+0x16af): In function `esp_input':
/usr/src/sys/netipsec/xform_esp.c:350: undefined reference to `crypto_getreq'
xform_esp.o(.text+0x1706):/usr/src/sys/netipsec/xform_esp.c:361: undefined reference to `M_XDATA'
xform_esp.o(.text+0x1727):/usr/src/sys/netipsec/xform_esp.c:364: undefined reference to `M_XDATA'
xform_esp.o(.text+0x1746):/usr/src/sys/netipsec/xform_esp.c:367: undefined reference to `crypto_freereq'
xform_esp.o(.text+0x18fe):/usr/src/sys/netipsec/xform_esp.c:430: undefined reference to `crypto_dispatch'
xform_ipcomp.o(.text+0xa): In function `ipcomp_algorithm_lookup':
/usr/src/sys/netipsec/xform_ipcomp.c:88: undefined reference to `comp_algo_deflate'
xform_ipcomp.o(.text+0x5a): In function `ipcomp_input':
/usr/src/sys/netipsec/xform_ipcomp.c:147: undefined reference to `crypto_getreq'
xform_ipcomp.o(.text+0xad):/usr/src/sys/netipsec/xform_ipcomp.c:155: undefined reference to `M_XDATA'
xform_ipcomp.o(.text+0xcf):/usr/src/sys/netipsec/xform_ipcomp.c:158: undefined reference to `crypto_freereq'
xform_ipcomp.o(.text+0x1a4):/usr/src/sys/netipsec/xform_ipcomp.c:189: undefined reference to `crypto_dispatch'
xform_ipcomp.o(.text+0x1d8): In function `ipcomp_zeroize':
/usr/src/sys/netipsec/xform_ipcomp.c:130: undefined reference to `crypto_freesession'
xform_ipcomp.o(.text+0x288): In function `ipcomp_init':
/usr/src/sys/netipsec/xform_ipcomp.c:119: undefined reference to `crypto_newsession'
xform_ipcomp.o(.text+0x3f7): In function `ipcomp_output_cb':
/usr/src/sys/netipsec/xform_ipcomp.c:521: undefined reference to `crypto_dispatch'
xform_ipcomp.o(.text+0x534):/usr/src/sys/netipsec/xform_ipcomp.c:568: undefined reference to `M_XDATA'
xform_ipcomp.o(.text+0x544):/usr/src/sys/netipsec/xform_ipcomp.c:569: undefined reference to `crypto_freereq'
xform_ipcomp.o(.text+0x5f9):/usr/src/sys/netipsec/xform_ipcomp.c:582: undefined reference to `M_XDATA'
xform_ipcomp.o(.text+0x609):/usr/src/sys/netipsec/xform_ipcomp.c:583: undefined reference to `crypto_freereq'
xform_ipcomp.o(.text+0x733): In function `ipcomp_input_cb':
/usr/src/sys/netipsec/xform_ipcomp.c:252: undefined reference to `crypto_dispatch'
xform_ipcomp.o(.text+0x7d3):/usr/src/sys/netipsec/xform_ipcomp.c:273: undefined reference to `M_XDATA'
xform_ipcomp.o(.text+0x7e3):/usr/src/sys/netipsec/xform_ipcomp.c:274: undefined reference to `crypto_freereq'
xform_ipcomp.o(.text+0x9c0):/usr/src/sys/netipsec/xform_ipcomp.c:313: undefined reference to `M_XDATA'
xform_ipcomp.o(.text+0x9d4):/usr/src/sys/netipsec/xform_ipcomp.c:315: undefined reference to `crypto_freereq'
xform_ipcomp.o(.text+0xc81): In function `ipcomp_output':
/usr/src/sys/netipsec/xform_ipcomp.c:433: undefined reference to `crypto_getreq'
xform_ipcomp.o(.text+0xcea):/usr/src/sys/netipsec/xform_ipcomp.c:452: undefined reference to `M_XDATA'
xform_ipcomp.o(.text+0xd28):/usr/src/sys/netipsec/xform_ipcomp.c:457: undefined reference to `crypto_freereq'
xform_ipcomp.o(.text+0xda6):/usr/src/sys/netipsec/xform_ipcomp.c:476: undefined reference to `crypto_dispatch'
*** Error code 1
Stop in /usr/obj/usr/src/sys/MYKERNEL.
*** Error code 1
Stop in /usr/src.
*** Error code 1
Stop in /usr/src.
#


I must have made something silly or forgotten something important, but all I did was getting my kernel sources up to date via cvsup and recompiling it (the classic way : "# make buildkernel KERNCONF=MYKERNEL" ; MYKERNEL being my kernel configuration file) ... Do I have to recompile world too before recompiling the kernel ? Has someone even encountered this before ?
I removed these options from my kernel configuration file for the while and use the same file as GENERIC, expect that I added SCTP_DEBUG in it. Compilation was performed successfully and my laptop booted finely on it. But the fact that IPSec couldn't be compiled startled me a bit.

Thanks in advance for your help.


Aman Jassal
From odhiambo at gmail.com  Sun Sep  6 15:35:08 2009
From: odhiambo at gmail.com (Odhiambo Washington)
Date: Sun Sep  6 15:35:22 2009
Subject: [Call For Testing] VirtualBox for FreeBSD! take 6
In-Reply-To: <E1MkFAi-0005OD-K0@kabab.cs.huji.ac.il>
References: <20090611194557.GC98175@bsdcrew.de>
	<E1MkFAi-0005OD-K0@kabab.cs.huji.ac.il>
Message-ID: <991123400909060811u9bea4d9rdbf453dfaae7c185@mail.gmail.com>

On Sun, Sep 6, 2009 at 1:40 PM, Danny Braniss <danny@cs.huji.ac.il> wrote:

> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> > Huhu,
> >
> > Yes we life and that's good :-).
> > Changes:
> >
> >   - Fix build error when compiling in debug mode on FreeBSD HEAD
> >   - SemEvent?-r0drv/FreeBSD: Don't use tvtohz for an infinite timeout.
> >   - Some FreeBSD relate typos
> >   - Enable shared OpenGL service. Completely untested due to lack of
> >     appropriate hardware but it compiles at least
> >   - Add support for shared clipboards. Requires libXt
> >   - FreeBSD: Implement preemption API for guest SMP and enable
> >     it (slightly tested). Add neccessary RTMP* methods in userspace
> >     for the frontends to detect the number of CPUs
> >   - Runtime/semevent-r0drv-freebsd: Use a sleeping mutex
> >     instead of a spinlock to fix the problems users are seeing
> >     (assertions with debugging enabled) while still being able
> >     to run on 100Hz hosts. No problems detected so far and Solaris
> >     doesn't use a spin mutex in this code too so it shouldn't do
> >     any harm (keeping fingers crossed)space for the frontends to
> >     detect the number of CPUs
> >   - Add support for curl
> >   - Add VBoxSharedClipboard
> >
> > Ports Changes;
> >   - Force guestadditions version to 2.2.4
> >   - Removed Qt3 include replacements (already upstream)
> >   - Removed cosmetic X11 include path patch
> >
> > Please make SURE, your world and kernel is in sync and you've read
> > the pkg-messages. Also please unload the kernel module before
> > you update the port ;-).
> >
> > Many thx to all Vbox Devs, All supporters, my nice team! :-)
> >
> >    http://people.freebsd.org/~miwi/vbox/virtualbox_6.tgz<http://people.freebsd.org/%7Emiwi/vbox/virtualbox_6.tgz>
> >
> >  Happy Testing!
> >
> ok, so some time has passed, but virtualbox-2.2.51r20457.tar.gz is no
> longer available, there is a
> ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/distfiles/virtualbox-2.2.51r20457.tar.bz2
> then again in ports/emulatores/virtualbox the version is 3.0.51r22226,
>
> can someone please explain?
>
>


And on my FreeBSD 7.2-STABLE, compiling virtualbox fails as follows:



kBuild: Linking VBoxREM64
kBuild: Installing VBoxREM64 =>
/usr/ports/emulators/virtualbox/work/virtualbox-3.0.51r22226/out/freebsd.x86/release/bin/VBox
REM64.so
kmk[2]: Leaving directory
`/usr/ports/emulators/virtualbox/work/virtualbox-3.0.51r22226'
kmk[1]: Leaving directory
`/usr/ports/emulators/virtualbox/work/virtualbox-3.0.51r22226'
kBuild: Pass - Programs
kmk[1]: Entering directory
`/usr/ports/emulators/virtualbox/work/virtualbox-3.0.51r22226'
kmk[2]: Entering directory
`/usr/ports/emulators/virtualbox/work/virtualbox-3.0.51r22226'
kBuild: Compiling tstAPI -
/usr/ports/emulators/virtualbox/work/virtualbox-3.0.51r22226/src/VBox/Main/testcase/tstAPI.cpp
kBuild: Linking tstAPI
/usr/local/lib/libssl.so.5: undefined reference to `d2i_X509_EXTENSIONS'
/usr/local/lib/libssl.so.5: undefined reference to
`ENGINE_get_ssl_client_cert_function'
/usr/local/lib/libssl.so.5: undefined reference to `HMAC_CTX_set_flags'
/usr/local/lib/libssl.so.5: undefined reference to `i2d_X509_EXTENSIONS'
/usr/local/lib/libssl.so.5: undefined reference to
`ENGINE_load_ssl_client_cert'
/usr/local/lib/libssl.so.5: undefined reference to `pqueue_size'
/usr/local/lib/libssl.so.5: undefined reference to `EVP_idea_cbc'
kmk[2]: ***
[/usr/ports/emulators/virtualbox/work/virtualbox-3.0.51r22226/out/freebsd.x86/release/obj/tstAPI/tstAPI]
Error 1
The failing command:
@g++               '-Wl,-rpath,/usr/local/lib/virtualbox'   -m32   -o
/usr/ports/emulators/virtualbox/work/virtualbox-3.0.51r
22226/out/freebsd.x86/release/obj/tstAPI/tstAPI
/usr/ports/emulators/virtualbox/work/virtualbox-3.0.51r22226/out/freebsd.x86/
release/obj/tstAPI/tstAPI.o   -L/usr/lib  -L/usr/X11R6/lib
-L/usr/local/lib
/usr/ports/emulators/virtualbox/work/virtualbo
x-3.0.51r22226/out/freebsd.x86/release/bin/VBoxRT.so
/usr/ports/emulators/virtualbox/work/virtualbox-3.0.51r22226/out/freeb
sd.x86/release/lib/VBoxCOM.a
/usr/ports/emulators/virtualbox/work/virtualbox-3.0.51r22226/out/freebsd.x86/release/bin/VBoxX
PCOM.so
kmk[2]: Leaving directory
`/usr/ports/emulators/virtualbox/work/virtualbox-3.0.51r22226'
kmk[1]: *** [pass_binaries_this] Error 2
kmk[1]: Leaving directory
`/usr/ports/emulators/virtualbox/work/virtualbox-3.0.51r22226'
kmk: *** [pass_binaries_order] Error 2
*** Error code 2

Stop in /usr/ports/emulators/virtualbox.


I hope someone can advise on what is needed.


-- 
Best regards,
Odhiambo WASHINGTON,
Nairobi,KE
+254733744121/+254722743223
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
"If you have nothing good to say about someone, just shut up!."
              -- Lucky Dube
From aman.jassal at esigetel.fr  Sun Sep  6 15:56:53 2009
From: aman.jassal at esigetel.fr (Aman Jassal)
Date: Sun Sep  6 15:57:00 2009
Subject: Problems with IPSec during kernel compilation with sources from
	CURRENT 9.0
Message-ID: <A7D7836BA2F14A43AB23091972495394@PCdeKimKas>

Dear all,

I performed an upgrade of my kernel sources this morning using CVSup, and successfully retrieved all the sources from HEAD (CURRENT 9.0).

I then performed a kernel compilation to upgrade it, and since I wanted to test out IPSec, I added the following lines in my kernel configuration file :

Options        IPSEC
Options        IPSEC_DEBUG

But the kernel compilation doesn't go through and I get errors. Here are the errors I got (it's a bit long) :


xform_ah.o(.text+0x13): In function `ah_algorithm_lookup':
/usr/src/sys/netipsec/xform_ah.c:116: undefined reference to `auth_hash_hmac_sha2_512'
xform_ah.o(.text+0x26):/usr/src/sys/netipsec/xform_ah.c:120: undefined reference to `auth_hash_hmac_sha1'
xform_ah.o(.text+0x43):/usr/src/sys/netipsec/xform_ah.c:128: undefined reference to `auth_hash_hmac_sha2_256'
xform_ah.o(.text+0x55):/usr/src/sys/netipsec/xform_ah.c:124: undefined reference to `auth_hash_key_md5'
xform_ah.o(.text+0x73):/usr/src/sys/netipsec/xform_ah.c:126: undefined reference to `auth_hash_key_sha1'
xform_ah.o(.text+0x80):/usr/src/sys/netipsec/xform_ah.c:116: undefined reference to `auth_hash_null'
xform_ah.o(.text+0x8f):/usr/src/sys/netipsec/xform_ah.c:118: undefined reference to `auth_hash_hmac_md5'
xform_ah.o(.text+0x96):/usr/src/sys/netipsec/xform_ah.c:122: undefined reference to `auth_hash_hmac_ripemd_160'
xform_ah.o(.text+0x9d):/usr/src/sys/netipsec/xform_ah.c:130: undefined reference to `auth_hash_hmac_sha2_384'
xform_ah.o(.text+0x540): In function `ah_massage_headers':
/usr/src/sys/netipsec/xform_ah.c:432: undefined reference to `M_XDATA'
xform_ah.o(.text+0x623):/usr/src/sys/netipsec/xform_ah.c:485: undefined reference to `M_XDATA'
xform_ah.o(.text+0x688):/usr/src/sys/netipsec/xform_ah.c:505: undefined reference to `M_XDATA'
xform_ah.o(.text+0x705):/usr/src/sys/netipsec/xform_ah.c:529: undefined reference to `M_XDATA'
xform_ah.o(.text+0x756):/usr/src/sys/netipsec/xform_ah.c:538: undefined reference to `M_XDATA'
xform_ah.o(.text+0x8dc): In function `ah_output_cb':
/usr/src/sys/netipsec/xform_ah.c:1146: undefined reference to `crypto_dispatch'
xform_ah.o(.text+0x986):/usr/src/sys/netipsec/xform_ah.c:1172: undefined reference to `M_XDATA'
xform_ah.o(.text+0x996):/usr/src/sys/netipsec/xform_ah.c:1173: undefined reference to `crypto_freereq'
xform_ah.o(.text+0xa49):/usr/src/sys/netipsec/xform_ah.c:1200: undefined reference to `M_XDATA'
xform_ah.o(.text+0xa59):/usr/src/sys/netipsec/xform_ah.c:1201: undefined reference to `crypto_freereq'
xform_ah.o(.text+0xb79): In function `ah_input_cb':
/usr/src/sys/netipsec/xform_ah.c:768: undefined reference to `crypto_dispatch'
xform_ah.o(.text+0xbd0):/usr/src/sys/netipsec/xform_ah.c:778: undefined reference to `crypto_freereq'
xform_ah.o(.text+0xd32):/usr/src/sys/netipsec/xform_ah.c:825: undefined reference to `M_XDATA'
xform_ah.o(.text+0xebc):/usr/src/sys/netipsec/xform_ah.c:869: undefined reference to `M_XDATA'
xform_ah.o(.text+0xed0):/usr/src/sys/netipsec/xform_ah.c:871: undefined reference to `crypto_freereq'
xform_ah.o(.text+0x10e7): In function `ah_init':
/usr/src/sys/netipsec/xform_ah.c:221: undefined reference to `crypto_newsession'
xform_ah.o(.text+0x1148): In function `ah_zeroize':
/usr/src/sys/netipsec/xform_ah.c:238: undefined reference to `crypto_freesession'
xform_ah.o(.text+0x1469): In function `ah_output':
/usr/src/sys/netipsec/xform_ah.c:1003: undefined reference to `crypto_getreq'
xform_ah.o(.text+0x14e3):/usr/src/sys/netipsec/xform_ah.c:1024: undefined reference to `M_XDATA'
xform_ah.o(.text+0x1500):/usr/src/sys/netipsec/xform_ah.c:1027: undefined reference to `crypto_freereq'
xform_ah.o(.text+0x1676):/usr/src/sys/netipsec/xform_ah.c:1078: undefined reference to `M_XDATA'
xform_ah.o(.text+0x168c):/usr/src/sys/netipsec/xform_ah.c:1079: undefined reference to `crypto_freereq'
xform_ah.o(.text+0x171f):/usr/src/sys/netipsec/xform_ah.c:1099: undefined reference to `crypto_dispatch'
xform_ah.o(.text+0x1971): In function `ah_input':
/usr/src/sys/netipsec/xform_ah.c:608: undefined reference to `crypto_getreq'
xform_ah.o(.text+0x1ab4):/usr/src/sys/netipsec/xform_ah.c:646: undefined reference to `M_XDATA'
xform_ah.o(.text+0x1af8):/usr/src/sys/netipsec/xform_ah.c:652: undefined reference to `crypto_freereq'
xform_ah.o(.text+0x1b93):/usr/src/sys/netipsec/xform_ah.c:676: undefined reference to `M_XDATA'
xform_ah.o(.text+0x1ba9):/usr/src/sys/netipsec/xform_ah.c:677: undefined reference to `crypto_freereq'
xform_ah.o(.text+0x1c4d):/usr/src/sys/netipsec/xform_ah.c:700: undefined reference to `crypto_dispatch'
xform_ah.o(.text+0x1c77):/usr/src/sys/netipsec/xform_ah.c:642: undefined reference to `M_XDATA'
xform_esp.o(.text+0xf): In function `esp_algorithm_lookup':
/usr/src/sys/netipsec/xform_esp.c:110: undefined reference to `enc_xform_blf'
xform_esp.o(.text+0x1e):/usr/src/sys/netipsec/xform_esp.c:106: undefined reference to `enc_xform_3des'
xform_esp.o(.text+0x28):/usr/src/sys/netipsec/xform_esp.c:112: undefined reference to `enc_xform_cast5'
xform_esp.o(.text+0x39):/usr/src/sys/netipsec/xform_esp.c:108: undefined reference to `enc_xform_rijndael128'
xform_esp.o(.text+0x53):/usr/src/sys/netipsec/xform_esp.c:104: undefined reference to `enc_xform_camellia'
xform_esp.o(.text+0x67):/usr/src/sys/netipsec/xform_esp.c:104: undefined reference to `enc_xform_des'
xform_esp.o(.text+0x6e):/usr/src/sys/netipsec/xform_esp.c:114: undefined reference to `enc_xform_skipjack'
xform_esp.o(.text+0x75):/usr/src/sys/netipsec/xform_esp.c:116: undefined reference to `enc_xform_null'
xform_esp.o(.text+0x99): In function `esp_attach':
/usr/src/sys/netipsec/xform_esp.c:992: undefined reference to `enc_xform_des'
xform_esp.o(.text+0xad):/usr/src/sys/netipsec/xform_esp.c:993: undefined reference to `enc_xform_3des'
xform_esp.o(.text+0xc1):/usr/src/sys/netipsec/xform_esp.c:994: undefined reference to `enc_xform_rijndael128'
xform_esp.o(.text+0xd5):/usr/src/sys/netipsec/xform_esp.c:995: undefined reference to `enc_xform_blf'
xform_esp.o(.text+0xe9):/usr/src/sys/netipsec/xform_esp.c:996: undefined reference to `enc_xform_cast5'
xform_esp.o(.text+0xfd):/usr/src/sys/netipsec/xform_esp.c:997: undefined reference to `enc_xform_skipjack'
xform_esp.o(.text+0x111):/usr/src/sys/netipsec/xform_esp.c:998: undefined reference to `enc_xform_null'
xform_esp.o(.text+0x125):/usr/src/sys/netipsec/xform_esp.c:999: undefined reference to `enc_xform_camellia'
xform_esp.o(.text+0x2bb): In function `esp_input_cb':
/usr/src/sys/netipsec/xform_esp.c:502: undefined reference to `crypto_dispatch'
xform_esp.o(.text+0x417):/usr/src/sys/netipsec/xform_esp.c:554: undefined reference to `M_XDATA'
xform_esp.o(.text+0x427):/usr/src/sys/netipsec/xform_esp.c:555: undefined reference to `crypto_freereq'
xform_esp.o(.text+0x762):/usr/src/sys/netipsec/xform_esp.c:639: undefined reference to `M_XDATA'
xform_esp.o(.text+0x776):/usr/src/sys/netipsec/xform_esp.c:641: undefined reference to `crypto_freereq'
xform_esp.o(.text+0x7e0): In function `esp_zeroize':
/usr/src/sys/netipsec/xform_esp.c:258: undefined reference to `M_XDATA'
xform_esp.o(.text+0x946): In function `esp_init':
/usr/src/sys/netipsec/xform_esp.c:198: undefined reference to `enc_xform_null'
xform_esp.o(.text+0x95f):/usr/src/sys/netipsec/xform_esp.c:199: undefined reference to `M_XDATA'
xform_esp.o(.text+0xa2b):/usr/src/sys/netipsec/xform_esp.c:229: undefined reference to `crypto_newsession'
xform_esp.o(.text+0xa4e):/usr/src/sys/netipsec/xform_esp.c:232: undefined reference to `crypto_newsession'
xform_esp.o(.text+0xa9e):/usr/src/sys/netipsec/xform_esp.c:235: undefined reference to `crypto_newsession'
xform_esp.o(.text+0xcb2): In function `esp_output_cb':
/usr/src/sys/netipsec/xform_esp.c:920: undefined reference to `crypto_dispatch'
xform_esp.o(.text+0xd5d):/usr/src/sys/netipsec/xform_esp.c:942: undefined reference to `M_XDATA'
xform_esp.o(.text+0xd70):/usr/src/sys/netipsec/xform_esp.c:943: undefined reference to `crypto_freereq'
xform_esp.o(.text+0xe1e):/usr/src/sys/netipsec/xform_esp.c:974: undefined reference to `M_XDATA'
xform_esp.o(.text+0xe31):/usr/src/sys/netipsec/xform_esp.c:975: undefined reference to `crypto_freereq'
xform_esp.o(.text+0x1235): In function `esp_output':
/usr/src/sys/netipsec/xform_esp.c:810: undefined reference to `crypto_getreq'
xform_esp.o(.text+0x12ba):/usr/src/sys/netipsec/xform_esp.c:838: undefined reference to `M_XDATA'
xform_esp.o(.text+0x12d4):/usr/src/sys/netipsec/xform_esp.c:841: undefined reference to `crypto_freereq'
xform_esp.o(.text+0x13b0):/usr/src/sys/netipsec/xform_esp.c:874: undefined reference to `crypto_dispatch'
xform_esp.o(.text+0x16af): In function `esp_input':
/usr/src/sys/netipsec/xform_esp.c:350: undefined reference to `crypto_getreq'
xform_esp.o(.text+0x1706):/usr/src/sys/netipsec/xform_esp.c:361: undefined reference to `M_XDATA'
xform_esp.o(.text+0x1727):/usr/src/sys/netipsec/xform_esp.c:364: undefined reference to `M_XDATA'
xform_esp.o(.text+0x1746):/usr/src/sys/netipsec/xform_esp.c:367: undefined reference to `crypto_freereq'
xform_esp.o(.text+0x18fe):/usr/src/sys/netipsec/xform_esp.c:430: undefined reference to `crypto_dispatch'
xform_ipcomp.o(.text+0xa): In function `ipcomp_algorithm_lookup':
/usr/src/sys/netipsec/xform_ipcomp.c:88: undefined reference to `comp_algo_deflate'
xform_ipcomp.o(.text+0x5a): In function `ipcomp_input':
/usr/src/sys/netipsec/xform_ipcomp.c:147: undefined reference to `crypto_getreq'
xform_ipcomp.o(.text+0xad):/usr/src/sys/netipsec/xform_ipcomp.c:155: undefined reference to `M_XDATA'
xform_ipcomp.o(.text+0xcf):/usr/src/sys/netipsec/xform_ipcomp.c:158: undefined reference to `crypto_freereq'
xform_ipcomp.o(.text+0x1a4):/usr/src/sys/netipsec/xform_ipcomp.c:189: undefined reference to `crypto_dispatch'
xform_ipcomp.o(.text+0x1d8): In function `ipcomp_zeroize':
/usr/src/sys/netipsec/xform_ipcomp.c:130: undefined reference to `crypto_freesession'
xform_ipcomp.o(.text+0x288): In function `ipcomp_init':
/usr/src/sys/netipsec/xform_ipcomp.c:119: undefined reference to `crypto_newsession'
xform_ipcomp.o(.text+0x3f7): In function `ipcomp_output_cb':
/usr/src/sys/netipsec/xform_ipcomp.c:521: undefined reference to `crypto_dispatch'
xform_ipcomp.o(.text+0x534):/usr/src/sys/netipsec/xform_ipcomp.c:568: undefined reference to `M_XDATA'
xform_ipcomp.o(.text+0x544):/usr/src/sys/netipsec/xform_ipcomp.c:569: undefined reference to `crypto_freereq'
xform_ipcomp.o(.text+0x5f9):/usr/src/sys/netipsec/xform_ipcomp.c:582: undefined reference to `M_XDATA'
xform_ipcomp.o(.text+0x609):/usr/src/sys/netipsec/xform_ipcomp.c:583: undefined reference to `crypto_freereq'
xform_ipcomp.o(.text+0x733): In function `ipcomp_input_cb':
/usr/src/sys/netipsec/xform_ipcomp.c:252: undefined reference to `crypto_dispatch'
xform_ipcomp.o(.text+0x7d3):/usr/src/sys/netipsec/xform_ipcomp.c:273: undefined reference to `M_XDATA'
xform_ipcomp.o(.text+0x7e3):/usr/src/sys/netipsec/xform_ipcomp.c:274: undefined reference to `crypto_freereq'
xform_ipcomp.o(.text+0x9c0):/usr/src/sys/netipsec/xform_ipcomp.c:313: undefined reference to `M_XDATA'
xform_ipcomp.o(.text+0x9d4):/usr/src/sys/netipsec/xform_ipcomp.c:315: undefined reference to `crypto_freereq'
xform_ipcomp.o(.text+0xc81): In function `ipcomp_output':
/usr/src/sys/netipsec/xform_ipcomp.c:433: undefined reference to `crypto_getreq'
xform_ipcomp.o(.text+0xcea):/usr/src/sys/netipsec/xform_ipcomp.c:452: undefined reference to `M_XDATA'
xform_ipcomp.o(.text+0xd28):/usr/src/sys/netipsec/xform_ipcomp.c:457: undefined reference to `crypto_freereq'
xform_ipcomp.o(.text+0xda6):/usr/src/sys/netipsec/xform_ipcomp.c:476: undefined reference to `crypto_dispatch'
*** Error code 1
Stop in /usr/obj/usr/src/sys/MYKERNEL.
*** Error code 1
Stop in /usr/src.
*** Error code 1
Stop in /usr/src.
#


I must have made something silly or forgotten something important, but all I did was getting my kernel sources up to date via cvsup and recompiling it (the classic way : "# make buildkernel KERNCONF=MYKERNEL" ; MYKERNEL being my kernel configuration file) ... Do I have to recompile world too before recompiling the kernel ? Has someone even encountered this before ?
I removed these options from my kernel configuration file for the while and use the same file as GENERIC, expect that I added SCTP_DEBUG in it. Compilation was performed successfully and my laptop booted finely on it. But the fact that IPSec couldn't be compiled startled me a bit.

Thanks in advance for your help.


Aman Jassal
From miwi at FreeBSD.org  Sun Sep  6 16:25:49 2009
From: miwi at FreeBSD.org (Martin Wilke)
Date: Sun Sep  6 16:25:57 2009
Subject: [Call For Testing] VirtualBox for FreeBSD! take 6
In-Reply-To: <991123400909060811u9bea4d9rdbf453dfaae7c185@mail.gmail.com>
References: <20090611194557.GC98175@bsdcrew.de>
	<E1MkFAi-0005OD-K0@kabab.cs.huji.ac.il>
	<991123400909060811u9bea4d9rdbf453dfaae7c185@mail.gmail.com>
Message-ID: <20090906162544.GA39448@bsdcrew.de>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Sun, Sep 06, 2009 at 06:11:48PM +0300, Odhiambo Washington wrote:
> On Sun, Sep 6, 2009 at 1:40 PM, Danny Braniss <danny@cs.huji.ac.il> wrote:
> 
> > > -----BEGIN PGP SIGNED MESSAGE-----
> > > Hash: SHA1
> > >
> > > Huhu,
> > >
> > > Yes we life and that's good :-).
> > > Changes:
> > >
> > >   - Fix build error when compiling in debug mode on FreeBSD HEAD
> > >   - SemEvent?-r0drv/FreeBSD: Don't use tvtohz for an infinite timeout.
> > >   - Some FreeBSD relate typos
> > >   - Enable shared OpenGL service. Completely untested due to lack of
> > >     appropriate hardware but it compiles at least
> > >   - Add support for shared clipboards. Requires libXt
> > >   - FreeBSD: Implement preemption API for guest SMP and enable
> > >     it (slightly tested). Add neccessary RTMP* methods in userspace
> > >     for the frontends to detect the number of CPUs
> > >   - Runtime/semevent-r0drv-freebsd: Use a sleeping mutex
> > >     instead of a spinlock to fix the problems users are seeing
> > >     (assertions with debugging enabled) while still being able
> > >     to run on 100Hz hosts. No problems detected so far and Solaris
> > >     doesn't use a spin mutex in this code too so it shouldn't do
> > >     any harm (keeping fingers crossed)space for the frontends to
> > >     detect the number of CPUs
> > >   - Add support for curl
> > >   - Add VBoxSharedClipboard
> > >
> > > Ports Changes;
> > >   - Force guestadditions version to 2.2.4
> > >   - Removed Qt3 include replacements (already upstream)
> > >   - Removed cosmetic X11 include path patch
> > >
> > > Please make SURE, your world and kernel is in sync and you've read
> > > the pkg-messages. Also please unload the kernel module before
> > > you update the port ;-).
> > >
> > > Many thx to all Vbox Devs, All supporters, my nice team! :-)
> > >
> > >    http://people.freebsd.org/~miwi/vbox/virtualbox_6.tgz<http://people.freebsd.org/%7Emiwi/vbox/virtualbox_6.tgz>
> > >
> > >  Happy Testing!
> > >
> > ok, so some time has passed, but virtualbox-2.2.51r20457.tar.gz is no
> > longer available, there is a
> > ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/distfiles/virtualbox-2.2.51r20457.tar.bz2
> > then again in ports/emulatores/virtualbox the version is 3.0.51r22226,
> >
> > can someone please explain?
> >
> >
> 
> 
> And on my FreeBSD 7.2-STABLE, compiling virtualbox fails as follows:
> 
> 
> 
> kBuild: Linking VBoxREM64
> kBuild: Installing VBoxREM64 =>
> /usr/ports/emulators/virtualbox/work/virtualbox-3.0.51r22226/out/freebsd.x86/release/bin/VBox
> REM64.so
> kmk[2]: Leaving directory
> `/usr/ports/emulators/virtualbox/work/virtualbox-3.0.51r22226'
> kmk[1]: Leaving directory
> `/usr/ports/emulators/virtualbox/work/virtualbox-3.0.51r22226'
> kBuild: Pass - Programs
> kmk[1]: Entering directory
> `/usr/ports/emulators/virtualbox/work/virtualbox-3.0.51r22226'
> kmk[2]: Entering directory
> `/usr/ports/emulators/virtualbox/work/virtualbox-3.0.51r22226'
> kBuild: Compiling tstAPI -
> /usr/ports/emulators/virtualbox/work/virtualbox-3.0.51r22226/src/VBox/Main/testcase/tstAPI.cpp
> kBuild: Linking tstAPI
> /usr/local/lib/libssl.so.5: undefined reference to `d2i_X509_EXTENSIONS'
> /usr/local/lib/libssl.so.5: undefined reference to
> `ENGINE_get_ssl_client_cert_function'
> /usr/local/lib/libssl.so.5: undefined reference to `HMAC_CTX_set_flags'
> /usr/local/lib/libssl.so.5: undefined reference to `i2d_X509_EXTENSIONS'
> /usr/local/lib/libssl.so.5: undefined reference to
> `ENGINE_load_ssl_client_cert'
> /usr/local/lib/libssl.so.5: undefined reference to `pqueue_size'
> /usr/local/lib/libssl.so.5: undefined reference to `EVP_idea_cbc'
> kmk[2]: ***
> [/usr/ports/emulators/virtualbox/work/virtualbox-3.0.51r22226/out/freebsd.x86/release/obj/tstAPI/tstAPI]
> Error 1
> The failing command:
> @g++               '-Wl,-rpath,/usr/local/lib/virtualbox'   -m32   -o
> /usr/ports/emulators/virtualbox/work/virtualbox-3.0.51r
> 22226/out/freebsd.x86/release/obj/tstAPI/tstAPI
> /usr/ports/emulators/virtualbox/work/virtualbox-3.0.51r22226/out/freebsd.x86/
> release/obj/tstAPI/tstAPI.o   -L/usr/lib  -L/usr/X11R6/lib
> -L/usr/local/lib
> /usr/ports/emulators/virtualbox/work/virtualbo
> x-3.0.51r22226/out/freebsd.x86/release/bin/VBoxRT.so
> /usr/ports/emulators/virtualbox/work/virtualbox-3.0.51r22226/out/freeb
> sd.x86/release/lib/VBoxCOM.a
> /usr/ports/emulators/virtualbox/work/virtualbox-3.0.51r22226/out/freebsd.x86/release/bin/VBoxX
> PCOM.so
> kmk[2]: Leaving directory
> `/usr/ports/emulators/virtualbox/work/virtualbox-3.0.51r22226'
> kmk[1]: *** [pass_binaries_this] Error 2
> kmk[1]: Leaving directory
> `/usr/ports/emulators/virtualbox/work/virtualbox-3.0.51r22226'
> kmk: *** [pass_binaries_order] Error 2
> *** Error code 2
> 
> Stop in /usr/ports/emulators/virtualbox.
> 
> 
> I hope someone can advise on what is needed.
> 

deinstall openssl from ports and try again :)

> 
> -- 
> Best regards,
> Odhiambo WASHINGTON,
> Nairobi,KE
> +254733744121/+254722743223
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> "If you have nothing good to say about someone, just shut up!."
>               -- Lucky Dube

- -- 

+-----------------------+-------------------------------+
|  PGP    : 0xB1E6FCE9  |  Jabber : miwi(at)BSDCrew.de  |
|  Skype  : splash_111  |  Mail   : miwi(at)FreeBSD.org |
+-----------------------+-------------------------------+
|	Mess with the Best, Die like the Rest!		|
+-----------------------+-------------------------------+
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.12 (FreeBSD)

iEYEARECAAYFAkqj4ogACgkQdLJIhLHm/OlShwCeJRqpqaBYbehqpKKfugxWD0PD
OdEAmQFSfdfWNXvO/vTRLj5vxIsD5EwP
=gbCY
-----END PGP SIGNATURE-----
From mike at sentex.net  Sun Sep  6 16:29:32 2009
From: mike at sentex.net (Mike Tancsa)
Date: Sun Sep  6 16:29:40 2009
Subject: Problems with IPSec during kernel compilation with sources
 from CURRENT 9.0
In-Reply-To: <A7D7836BA2F14A43AB23091972495394@PCdeKimKas>
References: <A7D7836BA2F14A43AB23091972495394@PCdeKimKas>
Message-ID: <200909061625.n86GPp9l055756@lava.sentex.ca>

At 10:52 AM 9/6/2009, Aman Jassal wrote:
>I then performed a kernel compilation to upgrade it, and since I 
>wanted to test out IPSec, I added the following lines in my kernel 
>configuration file :
>
>Options        IPSEC
>Options        IPSEC_DEBUG

Hi,
         You need to add

device crypto

to the kernel as well

         ---Mike



--------------------------------------------------------------------
Mike Tancsa,                                      tel +1 519 651 3400
Sentex Communications,                            mike@sentex.net
Providing Internet since 1994                    www.sentex.net
Cambridge, Ontario Canada                         www.sentex.net/mike

From aman.jassal at esigetel.fr  Sun Sep  6 16:45:52 2009
From: aman.jassal at esigetel.fr (Aman Jassal)
Date: Sun Sep  6 16:46:00 2009
Subject: Problems with IPSec during kernel compilation with sources from
	CURRENT 9.0
In-Reply-To: <200909061625.n86GPp9l055756@lava.sentex.ca>
References: <A7D7836BA2F14A43AB23091972495394@PCdeKimKas>
	<200909061625.n86GPp9l055756@lava.sentex.ca>
Message-ID: <F1F3E8FC663C4D229C930882EA1DE3C8@PCdeKimKas>

Hello Mike,

Oh ok... I knew I was missing something really obvious but I just couldn't 
put my finger on it >_<.
Thank you for enlightning me :)

Aman Jassal


----- Original Message ----- 
From: "Mike Tancsa" <mike@sentex.net>
To: "Aman Jassal" <aman.jassal@esigetel.fr>; <freebsd-current@freebsd.org>
Sent: Sunday, September 06, 2009 6:29 PM
Subject: Re: Problems with IPSec during kernel compilation with sources from 
CURRENT 9.0


> At 10:52 AM 9/6/2009, Aman Jassal wrote:
>>I then performed a kernel compilation to upgrade it, and since I wanted to 
>>test out IPSec, I added the following lines in my kernel configuration 
>>file :
>>
>>Options        IPSEC
>>Options        IPSEC_DEBUG
>
> Hi,
>         You need to add
>
> device crypto
>
> to the kernel as well
>
>         ---Mike
>
>
>
> --------------------------------------------------------------------
> Mike Tancsa,                                      tel +1 519 651 3400
> Sentex Communications,                            mike@sentex.net
> Providing Internet since 1994                    www.sentex.net
> Cambridge, Ontario Canada                         www.sentex.net/mike
>
> 



From odhiambo at gmail.com  Sun Sep  6 18:50:45 2009
From: odhiambo at gmail.com (Odhiambo Washington)
Date: Sun Sep  6 18:51:04 2009
Subject: [Call For Testing] VirtualBox for FreeBSD! take 6
In-Reply-To: <20090906162544.GA39448@bsdcrew.de>
References: <20090611194557.GC98175@bsdcrew.de>
	<E1MkFAi-0005OD-K0@kabab.cs.huji.ac.il> 
	<991123400909060811u9bea4d9rdbf453dfaae7c185@mail.gmail.com> 
	<20090906162544.GA39448@bsdcrew.de>
Message-ID: <991123400909061150h56dc6e07uf8d8e721f6c923bf@mail.gmail.com>

On Sun, Sep 6, 2009 at 7:25 PM, Martin Wilke <miwi@freebsd.org> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On Sun, Sep 06, 2009 at 06:11:48PM +0300, Odhiambo Washington wrote:
> > On Sun, Sep 6, 2009 at 1:40 PM, Danny Braniss <danny@cs.huji.ac.il>
> wrote:
> >
> > > > -----BEGIN PGP SIGNED MESSAGE-----
> > > > Hash: SHA1
> > > >
> > > > Huhu,
> > > >
> > > > Yes we life and that's good :-).
> > > > Changes:
> > > >
> > > >   - Fix build error when compiling in debug mode on FreeBSD HEAD
> > > >   - SemEvent?-r0drv/FreeBSD: Don't use tvtohz for an infinite
> timeout.
> > > >   - Some FreeBSD relate typos
> > > >   - Enable shared OpenGL service. Completely untested due to lack of
> > > >     appropriate hardware but it compiles at least
> > > >   - Add support for shared clipboards. Requires libXt
> > > >   - FreeBSD: Implement preemption API for guest SMP and enable
> > > >     it (slightly tested). Add neccessary RTMP* methods in userspace
> > > >     for the frontends to detect the number of CPUs
> > > >   - Runtime/semevent-r0drv-freebsd: Use a sleeping mutex
> > > >     instead of a spinlock to fix the problems users are seeing
> > > >     (assertions with debugging enabled) while still being able
> > > >     to run on 100Hz hosts. No problems detected so far and Solaris
> > > >     doesn't use a spin mutex in this code too so it shouldn't do
> > > >     any harm (keeping fingers crossed)space for the frontends to
> > > >     detect the number of CPUs
> > > >   - Add support for curl
> > > >   - Add VBoxSharedClipboard
> > > >
> > > > Ports Changes;
> > > >   - Force guestadditions version to 2.2.4
> > > >   - Removed Qt3 include replacements (already upstream)
> > > >   - Removed cosmetic X11 include path patch
> > > >
> > > > Please make SURE, your world and kernel is in sync and you've read
> > > > the pkg-messages. Also please unload the kernel module before
> > > > you update the port ;-).
> > > >
> > > > Many thx to all Vbox Devs, All supporters, my nice team! :-)
> > > >
> > > >    http://people.freebsd.org/~miwi/vbox/virtualbox_6.tgz<http://people.freebsd.org/%7Emiwi/vbox/virtualbox_6.tgz>
> <http://people.freebsd.org/%7Emiwi/vbox/virtualbox_6.tgz>
> > > >
> > > >  Happy Testing!
> > > >
> > > ok, so some time has passed, but virtualbox-2.2.51r20457.tar.gz is no
> > > longer available, there is a
> > >
> ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/distfiles/virtualbox-2.2.51r20457.tar.bz2
> > > then again in ports/emulatores/virtualbox the version is 3.0.51r22226,
> > >
> > > can someone please explain?
> > >
> > >
> >
> >
> > And on my FreeBSD 7.2-STABLE, compiling virtualbox fails as follows:
> >
> >
> >
> > kBuild: Linking VBoxREM64
> > kBuild: Installing VBoxREM64 =>
> >
> /usr/ports/emulators/virtualbox/work/virtualbox-3.0.51r22226/out/freebsd.x86/release/bin/VBox
> > REM64.so
> > kmk[2]: Leaving directory
> > `/usr/ports/emulators/virtualbox/work/virtualbox-3.0.51r22226'
> > kmk[1]: Leaving directory
> > `/usr/ports/emulators/virtualbox/work/virtualbox-3.0.51r22226'
> > kBuild: Pass - Programs
> > kmk[1]: Entering directory
> > `/usr/ports/emulators/virtualbox/work/virtualbox-3.0.51r22226'
> > kmk[2]: Entering directory
> > `/usr/ports/emulators/virtualbox/work/virtualbox-3.0.51r22226'
> > kBuild: Compiling tstAPI -
> >
> /usr/ports/emulators/virtualbox/work/virtualbox-3.0.51r22226/src/VBox/Main/testcase/tstAPI.cpp
> > kBuild: Linking tstAPI
> > /usr/local/lib/libssl.so.5: undefined reference to `d2i_X509_EXTENSIONS'
> > /usr/local/lib/libssl.so.5: undefined reference to
> > `ENGINE_get_ssl_client_cert_function'
> > /usr/local/lib/libssl.so.5: undefined reference to `HMAC_CTX_set_flags'
> > /usr/local/lib/libssl.so.5: undefined reference to `i2d_X509_EXTENSIONS'
> > /usr/local/lib/libssl.so.5: undefined reference to
> > `ENGINE_load_ssl_client_cert'
> > /usr/local/lib/libssl.so.5: undefined reference to `pqueue_size'
> > /usr/local/lib/libssl.so.5: undefined reference to `EVP_idea_cbc'
> > kmk[2]: ***
> >
> [/usr/ports/emulators/virtualbox/work/virtualbox-3.0.51r22226/out/freebsd.x86/release/obj/tstAPI/tstAPI]
> > Error 1
> > The failing command:
> > @g++               '-Wl,-rpath,/usr/local/lib/virtualbox'   -m32   -o
> > /usr/ports/emulators/virtualbox/work/virtualbox-3.0.51r
> > 22226/out/freebsd.x86/release/obj/tstAPI/tstAPI
> >
> /usr/ports/emulators/virtualbox/work/virtualbox-3.0.51r22226/out/freebsd.x86/
> > release/obj/tstAPI/tstAPI.o   -L/usr/lib  -L/usr/X11R6/lib
> > -L/usr/local/lib
> > /usr/ports/emulators/virtualbox/work/virtualbo
> > x-3.0.51r22226/out/freebsd.x86/release/bin/VBoxRT.so
> > /usr/ports/emulators/virtualbox/work/virtualbox-3.0.51r22226/out/freeb
> > sd.x86/release/lib/VBoxCOM.a
> >
> /usr/ports/emulators/virtualbox/work/virtualbox-3.0.51r22226/out/freebsd.x86/release/bin/VBoxX
> > PCOM.so
> > kmk[2]: Leaving directory
> > `/usr/ports/emulators/virtualbox/work/virtualbox-3.0.51r22226'
> > kmk[1]: *** [pass_binaries_this] Error 2
> > kmk[1]: Leaving directory
> > `/usr/ports/emulators/virtualbox/work/virtualbox-3.0.51r22226'
> > kmk: *** [pass_binaries_order] Error 2
> > *** Error code 2
> >
> > Stop in /usr/ports/emulators/virtualbox.
> >
> >
> > I hope someone can advise on what is needed.
> >
>
> deinstall openssl from ports and try again :)
>
>
I remember we had this suggestion before, and either you (or someone else)
was going to look into the use of openssl from the ports:-)
Looks like I will have to recompile most apps that have linked against
openssl, no?


-- 
Best regards,
Odhiambo WASHINGTON,
Nairobi,KE
+254733744121/+254722743223
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
"If you have nothing good to say about someone, just shut up!."
              -- Lucky Dube
From kris at FreeBSD.org  Sun Sep  6 19:32:01 2009
From: kris at FreeBSD.org (Kris Kennaway)
Date: Sun Sep  6 19:32:17 2009
Subject: panic: sx_xlock() of destroyed sx @
	/zoo/kris/src8/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_rlock.c:535
Message-ID: <4AA40E30.50109@FreeBSD.org>

9.0 doing I/O to a zfs:

panic: sx_xlock() of destroyed sx @ 
/zoo/kris/src8/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_rlock.c:535
db> wh
Tracing pid 14 tid 100047 td 0xffffff000357c720
kdb_enter() at kdb_enter+0x3d
panic() at panic+0x17b
_sx_xlock() at _sx_xlock+0xe9
zfs_range_unlock() at zfs_range_unlock+0x38
zfs_get_data() at zfs_get_data+0xd7
zil_commit() at zil_commit+0x532
zfs_sync() at zfs_sync+0xa6
sync_fsync() at sync_fsync+0x13a
VOP_FSYNC_APV() at VOP_FSYNC_APV+0xb7
sync_vnode() at sync_vnode+0x157
sched_sync() at sched_sync+0x1d1
fork_exit() at fork_exit+0x12a
fork_trampoline() at fork_trampoline+0xe
--- trap 0, rip = 0, rsp = 0xffffff8125da0d30, rbp = 0 ---

This was essentially just doing make world + cvs update + tar creation 
in a loop and failed after about a week.

Kris
From ziggi at yandex.ru  Sun Sep  6 19:43:22 2009
From: ziggi at yandex.ru (Borodin Oleg)
Date: Sun Sep  6 19:44:15 2009
Subject: wpa_supplicant not found AP without SSID in beacon packet
Message-ID: <4AA40E17.5010906@yandex.ru>


Hi!

wpa_supplicant "not found" AP without SSID in beacon packets. With same 
device and configuration, but FreeBSD7.2 - work without problems.

uname:
FreeBSD flashbsd.home 8.0-BETA3 FreeBSD 8.0-BETA3 #4 r196775: Thu Sep  3 
13:12:37 EEST 2009
    ziggi@eee.home:/usr/obj/usr/src/sys/EEE04  i386

wireless device:
ath0: <Atheros 5424/2424> mem 0xfbef0000-0xfbefffff irq 18 at device 0.0 
on pci1
ath0@pci0:1:0:0:        class=0x020000 card=0x10261a3b chip=0x001c168c 
rev=0x01 hdr=0x00
    vendor     = 'Atheros Communications Inc.'
    device     = 'AR5006 family 802.11abg Wireless NIC'
    class      = network
    subclass   = ethernet

Access point - Cisco 877w, IOS 12.4T8

----------- Variant 1. SSID not send in beacon packets from Cisco access 
point -
Cisco conf fragment :
!
dot11 mbssid
!
dot11 ssid WNET1
   vlan 1
   authentication open.
   authentication key-management wpa
   wpa-psk ascii 7 10682F4857474B2D2A
!
dot11 ssid WNET2
   vlan 2
   authentication open.
   authentication key-management wpa
   wpa-psk ascii 7 15342D5D567A72020E
!
dot11 ssid WNET3
   vlan 3
   authentication open.
   authentication key-management wpa
   wpa-psk ascii 7 0220220A595656076A
!

Result FreeBSD8Beta3 wpa_suplicant & wlandebug:

Starting AP scan (broadcast SSID)
wlan0: ieee80211_ioctl_scanreq: flags 0x52 duration 0x7fffffff mindwell 
0 maxdwe
ll 0 nssid 0
wlan0: ieee80211_check_scan: active scan, append, nojoin, once
wlan0: sta_pick_bss: no scan candidate
wlan0: start_scan_locked: active scan, duration 2147483647 mindwell 0 
maxdwell 0
, desired mode auto, append, nojoin, once
wlan0: scan set 1g, 6g, 11g, 7g, 13g, 2g, 3g, 4g, 5g, 8g, 9g, 10g, 12g, 
14b dwel
l min 20ms max 200ms
wlan0: scan_task: chan   3g ->   1g [active, dwell min 20ms max 200ms]
wlan0: send probe req on channel 1 bssid ff:ff:ff:ff:ff:ff ssid ""
wlan0: received beacon from 00:23:5e:75:f7:c0 rssi 45
wlan0: [00:23:5e:75:f7:c0] discard unhandled information element, id 
133, len 30 <-------- ????

wlan0: [00:23:5e:75:f7:c0] discard beacon frame, for off-channel 3
wlan0: received beacon from 00:23:5e:75:f7:c2 rssi 44
wlan0: [00:23:5e:75:f7:c2] discard unhandled information element, id 
133, len 30

wlan0: [00:23:5e:75:f7:c0] discard beacon frame, for off-channel 3
wlan0: received beacon from 00:23:5e:75:f7:c2 rssi 46
wlan0: [00:23:5e:75:f7:c2] discard unhandled information element, id 
133, len 30

wlan0: [00:23:5e:75:f7:c2] discard beacon frame, for off-channel 3
wlan0: scan_task: chan   1g ->   6g [active, dwell min 20ms max 200ms]
wlan0: send probe req on channel 6 bssid ff:ff:ff:ff:ff:ff ssid ""
wlan0: scan_task: chan   6g ->  11g [active, dwell min 20ms max 200ms]
wlan0: send probe req on channel 11 bssid ff:ff:ff:ff:ff:ff ssid ""
wlan0: scan_task: chan  11g ->   7g [active, dwell min 20ms max 200ms]
wlan0: send probe req on channel 7 bssid ff:ff:ff:ff:ff:ff ssid ""
wlan0: scan_task: chan   7g ->  13g [passive, dwell min 20ms max 200ms]
EAPOL: disable timer tick
wlan0: scan_task: chan  13g ->   2g [active, dwell min 20ms max 200ms]
wlan0: send probe req on channel 2 bssid ff:ff:ff:ff:ff:ff ssid ""
wlan0: received beacon from 00:23:5e:75:f7:c1 rssi 56
wlan0: [00:23:5e:75:f7:c1] discard unhandled information element, id 
133, len 30
...
[00:23:5e:75:f7:c1] new beacon on chan 3 (bss chan 3) 0x00 rssi 55
[00:23:5e:75:f7:c1] caps 0x431 bintval 100 erp 0x100
wlan0: received beacon from 00:23:5e:75:f7:c2 rssi 53
wlan0: [00:23:5e:75:f7:c2] discard unhandled information element, id 
133, len 30

[00:23:5e:75:f7:c2] new beacon on chan 3 (bss chan 3) 0x00 rssi 53
[00:23:5e:75:f7:c2] caps 0x431 bintval 100 erp 0x100
wlan0: scan_task: chan   3g ->   4g [active, dwell min 20ms max 200ms]
wlan0: send probe req on channel 4 bssid ff:ff:ff:ff:ff:ff ssid ""
wlan0: received beacon from 00:23:5e:75:f7:c2 rssi 52
wlan0: [00:23:5e:75:f7:c2] discard unhandled information element, id 
133, len 30
...
Scan results: 3
CTRL-EVENT-SCAN-RESULTS
Selecting BSS from priority group 0
Try to find WPA-enabled AP
0: 00:23:5e:75:f7:c1 ssid='' wpa_ie_len=24 rsn_ie_len=0 caps=0x31
   skip - SSID mismatch
1: 00:23:5e:75:f7:c2 ssid='' wpa_ie_len=24 rsn_ie_len=0 caps=0x31
   skip - SSID mismatch
2: 00:23:5e:75:f7:c0 ssid='' wpa_ie_len=24 rsn_ie_len=0 caps=0x31
   skip - SSID mismatch
Try to find non-WPA AP
0: 00:23:5e:75:f7:c1 ssid='' wpa_ie_len=24 rsn_ie_len=0 caps=0x31
   skip - SSID mismatch
1: 00:23:5e:75:f7:c2 ssid='' wpa_ie_len=24 rsn_ie_len=0 caps=0x31
   skip - SSID mismatch
2: 00:23:5e:75:f7:c0 ssid='' wpa_ie_len=24 rsn_ie_len=0 caps=0x31
   skip - SSID mismatch
No suitable AP found. <---------------------
Setting scan request: 5 sec 0 usec

---------------- 2 On _any_ SSID in beacon packet:

dot11 ssid WNET1
   vlan 1
   authentication open
   authentication key-management wpa
   mbssid guest-mode  <--------------------------- On SSID sending
   wpa-psk ascii 7 10682F4857474B2D2A
!
dot11 ssid WNET2
   vlan 2
   authentication open
   authentication key-management wpa
   wpa-psk ascii 7 15342D5D567A72020E
!
dot11 ssid WNET3
   vlan 3
   authentication open
   authentication key-management wpa
   wpa-psk ascii 7 0220220A595656076A
!

Result wpa_supplicant:

Received 0 bytes of scan results (3 BSSes)
Scan results: 3
CTRL-EVENT-SCAN-RESULTS
Selecting BSS from priority group 0
Try to find WPA-enabled AP
0: 00:23:5e:75:f7:c1 ssid='' wpa_ie_len=24 rsn_ie_len=0 caps=0x31
   skip - SSID mismatch
1: 00:23:5e:75:f7:c2 ssid='' wpa_ie_len=24 rsn_ie_len=0 caps=0x31
   skip - SSID mismatch
2: 00:23:5e:75:f7:c0 ssid='WNET1' wpa_ie_len=24 rsn_ie_len=0 caps=0x31
   selected based on WPA IE
   selected WPA AP 00:23:5e:75:f7:c0 ssid='WNET1' 
<----------------------------------------
Trying to associate with 00:23:5e:75:f7:c0 (SSID='WNET1' freq=2422 MHz)
Cancelling scan request



/etc/wpa_upplicant.conf:
# $Id$
ctrl_interface=/var/run/wpa_supplicant
ctrl_interface_group=wheel
#eapol_version=1
#ap_scan=1
fast_reauth=1
network={
  ssid="WNET1"
#  scan_ssid=1
  proto=RSN WPA
  key_mgmt=WPA-PSK
  pairwise=CCMP TKIP
  group=CCMP TKIP
  psk=8c23bb58a1a94b3b56b90d8f7422a29b18f495b517f33fc6728ff2a3ad4aae1f
}
#EOF

--

Best regards,

Borodin Oleg
Kaliningrad,Russia
ziggi@inbox.ru




From ziggi at yandex.ru  Sun Sep  6 19:46:05 2009
From: ziggi at yandex.ru (Borodin Oleg)
Date: Sun Sep  6 19:46:13 2009
Subject: wpa_supplicant not found AP without SSID in beacon packet
Message-ID: <4AA41025.5080908@yandex.ru>


Hi!

wpa_supplicant "not found" AP without SSID in beacon packets. With same
device and configuration, but FreeBSD7.2 - work without problems.

uname:
FreeBSD flashbsd.home 8.0-BETA3 FreeBSD 8.0-BETA3 #4 r196775: Thu Sep  3
13:12:37 EEST 2009
    ziggi@eee.home:/usr/obj/usr/src/sys/EEE04  i386

wireless device:
ath0: <Atheros 5424/2424> mem 0xfbef0000-0xfbefffff irq 18 at device 0.0
on pci1
ath0@pci0:1:0:0:        class=0x020000 card=0x10261a3b chip=0x001c168c
rev=0x01 hdr=0x00
    vendor     = 'Atheros Communications Inc.'
    device     = 'AR5006 family 802.11abg Wireless NIC'
    class      = network
    subclass   = ethernet

Access point - Cisco 877w, IOS 12.4T8

----------- Variant 1. SSID not send in beacon packets from Cisco access
point -
Cisco conf fragment :
!
dot11 mbssid
!
dot11 ssid WNET1
   vlan 1
   authentication open.
   authentication key-management wpa
   wpa-psk ascii 7 10682F4857474B2D2A
!
dot11 ssid WNET2
   vlan 2
   authentication open.
   authentication key-management wpa
   wpa-psk ascii 7 15342D5D567A72020E
!
dot11 ssid WNET3
   vlan 3
   authentication open.
   authentication key-management wpa
   wpa-psk ascii 7 0220220A595656076A
!

Result FreeBSD8Beta3 wpa_suplicant & wlandebug:

Starting AP scan (broadcast SSID)
wlan0: ieee80211_ioctl_scanreq: flags 0x52 duration 0x7fffffff mindwell
0 maxdwe
ll 0 nssid 0
wlan0: ieee80211_check_scan: active scan, append, nojoin, once
wlan0: sta_pick_bss: no scan candidate
wlan0: start_scan_locked: active scan, duration 2147483647 mindwell 0
maxdwell 0
, desired mode auto, append, nojoin, once
wlan0: scan set 1g, 6g, 11g, 7g, 13g, 2g, 3g, 4g, 5g, 8g, 9g, 10g, 12g,
14b dwel
l min 20ms max 200ms
wlan0: scan_task: chan   3g ->   1g [active, dwell min 20ms max 200ms]
wlan0: send probe req on channel 1 bssid ff:ff:ff:ff:ff:ff ssid ""
wlan0: received beacon from 00:23:5e:75:f7:c0 rssi 45
wlan0: [00:23:5e:75:f7:c0] discard unhandled information element, id
133, len 30 <-------- ????

wlan0: [00:23:5e:75:f7:c0] discard beacon frame, for off-channel 3
wlan0: received beacon from 00:23:5e:75:f7:c2 rssi 44
wlan0: [00:23:5e:75:f7:c2] discard unhandled information element, id
133, len 30

wlan0: [00:23:5e:75:f7:c0] discard beacon frame, for off-channel 3
wlan0: received beacon from 00:23:5e:75:f7:c2 rssi 46
wlan0: [00:23:5e:75:f7:c2] discard unhandled information element, id
133, len 30

wlan0: [00:23:5e:75:f7:c2] discard beacon frame, for off-channel 3
wlan0: scan_task: chan   1g ->   6g [active, dwell min 20ms max 200ms]
wlan0: send probe req on channel 6 bssid ff:ff:ff:ff:ff:ff ssid ""
wlan0: scan_task: chan   6g ->  11g [active, dwell min 20ms max 200ms]
wlan0: send probe req on channel 11 bssid ff:ff:ff:ff:ff:ff ssid ""
wlan0: scan_task: chan  11g ->   7g [active, dwell min 20ms max 200ms]
wlan0: send probe req on channel 7 bssid ff:ff:ff:ff:ff:ff ssid ""
wlan0: scan_task: chan   7g ->  13g [passive, dwell min 20ms max 200ms]
EAPOL: disable timer tick
wlan0: scan_task: chan  13g ->   2g [active, dwell min 20ms max 200ms]
wlan0: send probe req on channel 2 bssid ff:ff:ff:ff:ff:ff ssid ""
wlan0: received beacon from 00:23:5e:75:f7:c1 rssi 56
wlan0: [00:23:5e:75:f7:c1] discard unhandled information element, id
133, len 30
...
[00:23:5e:75:f7:c1] new beacon on chan 3 (bss chan 3) 0x00 rssi 55
[00:23:5e:75:f7:c1] caps 0x431 bintval 100 erp 0x100
wlan0: received beacon from 00:23:5e:75:f7:c2 rssi 53
wlan0: [00:23:5e:75:f7:c2] discard unhandled information element, id
133, len 30

[00:23:5e:75:f7:c2] new beacon on chan 3 (bss chan 3) 0x00 rssi 53
[00:23:5e:75:f7:c2] caps 0x431 bintval 100 erp 0x100
wlan0: scan_task: chan   3g ->   4g [active, dwell min 20ms max 200ms]
wlan0: send probe req on channel 4 bssid ff:ff:ff:ff:ff:ff ssid ""
wlan0: received beacon from 00:23:5e:75:f7:c2 rssi 52
wlan0: [00:23:5e:75:f7:c2] discard unhandled information element, id
133, len 30
...
Scan results: 3
CTRL-EVENT-SCAN-RESULTS
Selecting BSS from priority group 0
Try to find WPA-enabled AP
0: 00:23:5e:75:f7:c1 ssid='' wpa_ie_len=24 rsn_ie_len=0 caps=0x31
   skip - SSID mismatch
1: 00:23:5e:75:f7:c2 ssid='' wpa_ie_len=24 rsn_ie_len=0 caps=0x31
   skip - SSID mismatch
2: 00:23:5e:75:f7:c0 ssid='' wpa_ie_len=24 rsn_ie_len=0 caps=0x31
   skip - SSID mismatch
Try to find non-WPA AP
0: 00:23:5e:75:f7:c1 ssid='' wpa_ie_len=24 rsn_ie_len=0 caps=0x31
   skip - SSID mismatch
1: 00:23:5e:75:f7:c2 ssid='' wpa_ie_len=24 rsn_ie_len=0 caps=0x31
   skip - SSID mismatch
2: 00:23:5e:75:f7:c0 ssid='' wpa_ie_len=24 rsn_ie_len=0 caps=0x31
   skip - SSID mismatch
No suitable AP found. <---------------------
Setting scan request: 5 sec 0 usec

---------------- 2 On _any_ SSID in beacon packet:

dot11 ssid WNET1
   vlan 1
   authentication open
   authentication key-management wpa
   mbssid guest-mode  <--------------------------- On SSID sending
   wpa-psk ascii 7 10682F4857474B2D2A
!
dot11 ssid WNET2
   vlan 2
   authentication open
   authentication key-management wpa
   wpa-psk ascii 7 15342D5D567A72020E
!
dot11 ssid WNET3
   vlan 3
   authentication open
   authentication key-management wpa
   wpa-psk ascii 7 0220220A595656076A
!

Result wpa_supplicant:

Received 0 bytes of scan results (3 BSSes)
Scan results: 3
CTRL-EVENT-SCAN-RESULTS
Selecting BSS from priority group 0
Try to find WPA-enabled AP
0: 00:23:5e:75:f7:c1 ssid='' wpa_ie_len=24 rsn_ie_len=0 caps=0x31
   skip - SSID mismatch
1: 00:23:5e:75:f7:c2 ssid='' wpa_ie_len=24 rsn_ie_len=0 caps=0x31
   skip - SSID mismatch
2: 00:23:5e:75:f7:c0 ssid='WNET1' wpa_ie_len=24 rsn_ie_len=0 caps=0x31
   selected based on WPA IE
   selected WPA AP 00:23:5e:75:f7:c0 ssid='WNET1'
<----------------------------------------
Trying to associate with 00:23:5e:75:f7:c0 (SSID='WNET1' freq=2422 MHz)
Cancelling scan request



/etc/wpa_upplicant.conf:
# $Id$
ctrl_interface=/var/run/wpa_supplicant
ctrl_interface_group=wheel
#eapol_version=1
#ap_scan=1
fast_reauth=1
network={
  ssid="WNET1"
#  scan_ssid=1
  proto=RSN WPA
  key_mgmt=WPA-PSK
  pairwise=CCMP TKIP
  group=CCMP TKIP
  psk=8c23bb58a1a94b3b56b90d8f7422a29b18f495b517f33fc6728ff2a3ad4aae1f
}
#EOF

--

Best regards,

Borodin Oleg
Kaliningrad,Russia
ziggi@inbox.ru





From oliver at namp.de  Sun Sep  6 20:08:56 2009
From: oliver at namp.de (Oliver Fakler)
Date: Sun Sep  6 22:05:45 2009
Subject: boot from raidz
Message-ID: <60533.1252266359@namp.de>

 

	Hi all,

	i installed a 8.0 beta 3 amd64 based testsystem.

	i tried with a root on a raidz, but i have a problem after the first
reboot, there is a error message:

	can't load kernel
	I found something that boot root from raidz is not supported, but
maybe there is a solution??
	Hope some can help me
	Greets
	Oliver
From sam at errno.com  Sun Sep  6 23:53:02 2009
From: sam at errno.com (Sam Leffler)
Date: Sun Sep  6 23:53:09 2009
Subject: wpa_supplicant not found AP without SSID in beacon packet
In-Reply-To: <4AA41025.5080908@yandex.ru>
References: <4AA41025.5080908@yandex.ru>
Message-ID: <4AA44B53.8060702@errno.com>

Borodin Oleg wrote:
> 
> Hi!
> 
> wpa_supplicant "not found" AP without SSID in beacon packets. With same
> device and configuration, but FreeBSD7.2 - work without problems.
> 
> uname:
> FreeBSD flashbsd.home 8.0-BETA3 FreeBSD 8.0-BETA3 #4 r196775: Thu Sep  3
> 13:12:37 EEST 2009
>    ziggi@eee.home:/usr/obj/usr/src/sys/EEE04  i386
> 
> wireless device:
> ath0: <Atheros 5424/2424> mem 0xfbef0000-0xfbefffff irq 18 at device 0.0
> on pci1
> ath0@pci0:1:0:0:        class=0x020000 card=0x10261a3b chip=0x001c168c
> rev=0x01 hdr=0x00
>    vendor     = 'Atheros Communications Inc.'
>    device     = 'AR5006 family 802.11abg Wireless NIC'
>    class      = network
>    subclass   = ethernet
> 
> Access point - Cisco 877w, IOS 12.4T8
> 
> ----------- Variant 1. SSID not send in beacon packets from Cisco access
> point -
> Cisco conf fragment :
> !
> dot11 mbssid
> !
> dot11 ssid WNET1
>   vlan 1
>   authentication open.
>   authentication key-management wpa
>   wpa-psk ascii 7 10682F4857474B2D2A
> !
> dot11 ssid WNET2
>   vlan 2
>   authentication open.
>   authentication key-management wpa
>   wpa-psk ascii 7 15342D5D567A72020E
> !
> dot11 ssid WNET3
>   vlan 3
>   authentication open.
>   authentication key-management wpa
>   wpa-psk ascii 7 0220220A595656076A
> !
> 
> Result FreeBSD8Beta3 wpa_suplicant & wlandebug:
> 
> Starting AP scan (broadcast SSID)
> wlan0: ieee80211_ioctl_scanreq: flags 0x52 duration 0x7fffffff mindwell
> 0 maxdwe
> ll 0 nssid 0
> wlan0: ieee80211_check_scan: active scan, append, nojoin, once
> wlan0: sta_pick_bss: no scan candidate
> wlan0: start_scan_locked: active scan, duration 2147483647 mindwell 0
> maxdwell 0
> , desired mode auto, append, nojoin, once
> wlan0: scan set 1g, 6g, 11g, 7g, 13g, 2g, 3g, 4g, 5g, 8g, 9g, 10g, 12g,
> 14b dwel
> l min 20ms max 200ms
> wlan0: scan_task: chan   3g ->   1g [active, dwell min 20ms max 200ms]
> wlan0: send probe req on channel 1 bssid ff:ff:ff:ff:ff:ff ssid ""
> wlan0: received beacon from 00:23:5e:75:f7:c0 rssi 45
> wlan0: [00:23:5e:75:f7:c0] discard unhandled information element, id
> 133, len 30 <-------- ????
> 
> wlan0: [00:23:5e:75:f7:c0] discard beacon frame, for off-channel 3
> wlan0: received beacon from 00:23:5e:75:f7:c2 rssi 44
> wlan0: [00:23:5e:75:f7:c2] discard unhandled information element, id
> 133, len 30
> 
> wlan0: [00:23:5e:75:f7:c0] discard beacon frame, for off-channel 3
> wlan0: received beacon from 00:23:5e:75:f7:c2 rssi 46
> wlan0: [00:23:5e:75:f7:c2] discard unhandled information element, id
> 133, len 30
> 
> wlan0: [00:23:5e:75:f7:c2] discard beacon frame, for off-channel 3
> wlan0: scan_task: chan   1g ->   6g [active, dwell min 20ms max 200ms]
> wlan0: send probe req on channel 6 bssid ff:ff:ff:ff:ff:ff ssid ""
> wlan0: scan_task: chan   6g ->  11g [active, dwell min 20ms max 200ms]
> wlan0: send probe req on channel 11 bssid ff:ff:ff:ff:ff:ff ssid ""
> wlan0: scan_task: chan  11g ->   7g [active, dwell min 20ms max 200ms]
> wlan0: send probe req on channel 7 bssid ff:ff:ff:ff:ff:ff ssid ""
> wlan0: scan_task: chan   7g ->  13g [passive, dwell min 20ms max 200ms]
> EAPOL: disable timer tick
> wlan0: scan_task: chan  13g ->   2g [active, dwell min 20ms max 200ms]
> wlan0: send probe req on channel 2 bssid ff:ff:ff:ff:ff:ff ssid ""
> wlan0: received beacon from 00:23:5e:75:f7:c1 rssi 56
> wlan0: [00:23:5e:75:f7:c1] discard unhandled information element, id
> 133, len 30
> ...
> [00:23:5e:75:f7:c1] new beacon on chan 3 (bss chan 3) 0x00 rssi 55
> [00:23:5e:75:f7:c1] caps 0x431 bintval 100 erp 0x100
> wlan0: received beacon from 00:23:5e:75:f7:c2 rssi 53
> wlan0: [00:23:5e:75:f7:c2] discard unhandled information element, id
> 133, len 30
> 
> [00:23:5e:75:f7:c2] new beacon on chan 3 (bss chan 3) 0x00 rssi 53
> [00:23:5e:75:f7:c2] caps 0x431 bintval 100 erp 0x100
> wlan0: scan_task: chan   3g ->   4g [active, dwell min 20ms max 200ms]
> wlan0: send probe req on channel 4 bssid ff:ff:ff:ff:ff:ff ssid ""
> wlan0: received beacon from 00:23:5e:75:f7:c2 rssi 52
> wlan0: [00:23:5e:75:f7:c2] discard unhandled information element, id
> 133, len 30
> ...
> Scan results: 3
> CTRL-EVENT-SCAN-RESULTS
> Selecting BSS from priority group 0
> Try to find WPA-enabled AP
> 0: 00:23:5e:75:f7:c1 ssid='' wpa_ie_len=24 rsn_ie_len=0 caps=0x31
>   skip - SSID mismatch
> 1: 00:23:5e:75:f7:c2 ssid='' wpa_ie_len=24 rsn_ie_len=0 caps=0x31
>   skip - SSID mismatch
> 2: 00:23:5e:75:f7:c0 ssid='' wpa_ie_len=24 rsn_ie_len=0 caps=0x31
>   skip - SSID mismatch
> Try to find non-WPA AP
> 0: 00:23:5e:75:f7:c1 ssid='' wpa_ie_len=24 rsn_ie_len=0 caps=0x31
>   skip - SSID mismatch
> 1: 00:23:5e:75:f7:c2 ssid='' wpa_ie_len=24 rsn_ie_len=0 caps=0x31
>   skip - SSID mismatch
> 2: 00:23:5e:75:f7:c0 ssid='' wpa_ie_len=24 rsn_ie_len=0 caps=0x31
>   skip - SSID mismatch
> No suitable AP found. <---------------------
> Setting scan request: 5 sec 0 usec
> 
> ---------------- 2 On _any_ SSID in beacon packet:
> 
> dot11 ssid WNET1
>   vlan 1
>   authentication open
>   authentication key-management wpa
>   mbssid guest-mode  <--------------------------- On SSID sending
>   wpa-psk ascii 7 10682F4857474B2D2A
> !
> dot11 ssid WNET2
>   vlan 2
>   authentication open
>   authentication key-management wpa
>   wpa-psk ascii 7 15342D5D567A72020E
> !
> dot11 ssid WNET3
>   vlan 3
>   authentication open
>   authentication key-management wpa
>   wpa-psk ascii 7 0220220A595656076A
> !
> 
> Result wpa_supplicant:
> 
> Received 0 bytes of scan results (3 BSSes)
> Scan results: 3
> CTRL-EVENT-SCAN-RESULTS
> Selecting BSS from priority group 0
> Try to find WPA-enabled AP
> 0: 00:23:5e:75:f7:c1 ssid='' wpa_ie_len=24 rsn_ie_len=0 caps=0x31
>   skip - SSID mismatch
> 1: 00:23:5e:75:f7:c2 ssid='' wpa_ie_len=24 rsn_ie_len=0 caps=0x31
>   skip - SSID mismatch
> 2: 00:23:5e:75:f7:c0 ssid='WNET1' wpa_ie_len=24 rsn_ie_len=0 caps=0x31
>   selected based on WPA IE
>   selected WPA AP 00:23:5e:75:f7:c0 ssid='WNET1'
> <----------------------------------------
> Trying to associate with 00:23:5e:75:f7:c0 (SSID='WNET1' freq=2422 MHz)
> Cancelling scan request
> 
> 
> 
> /etc/wpa_upplicant.conf:
> # $Id$
> ctrl_interface=/var/run/wpa_supplicant
> ctrl_interface_group=wheel
> #eapol_version=1
> #ap_scan=1
> fast_reauth=1
> network={
>  ssid="WNET1"
> #  scan_ssid=1
>  proto=RSN WPA
>  key_mgmt=WPA-PSK
>  pairwise=CCMP TKIP
>  group=CCMP TKIP
>  psk=8c23bb58a1a94b3b56b90d8f7422a29b18f495b517f33fc6728ff2a3ad4aae1f
> }
> #EOF

You seem to have disabled scan_ssid in your wpa_supplicant.conf file. 
It appears this causes wpa_supplicant to not supply the ssid when 
scanning so the net80211 layer never sends directed ProbeRequest frames 
and then ap does not respond.  Try enabling scan_ssid for WNET1 and 
verify the directed probe request frames are sent.

	Sam
From danny at cs.huji.ac.il  Mon Sep  7 05:41:38 2009
From: danny at cs.huji.ac.il (Danny Braniss)
Date: Mon Sep  7 05:41:46 2009
Subject: [Call For Testing] VirtualBox for FreeBSD! take 6 
In-Reply-To: <20090906162544.GA39448@bsdcrew.de> 
References: <20090611194557.GC98175@bsdcrew.de>
	<E1MkFAi-0005OD-K0@kabab.cs.huji.ac.il>
	<991123400909060811u9bea4d9rdbf453dfaae7c185@mail.gmail.com>
	<20090906162544.GA39448@bsdcrew.de>
Message-ID: <E1MkWyt-000Eoi-1c@kabab.cs.huji.ac.il>


[...]
> > > >
> > > ok, so some time has passed, but virtualbox-2.2.51r20457.tar.gz is no
> > > longer available, there is a
> > > ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/distfiles/virtualbox-2.2.51r20457.tar.bz2
> > > then again in ports/emulatores/virtualbox the version is 3.0.51r22226,
> > >
> > > can someone please explain?

hi, the above was my question, which was totally ignored, not nice.
I will try and refrase it:
the call for testing is for a version (2.2.51r20457) which is not available, while
the ports is 3.0.51r22226, so while I managed to compile it, it complains that COM
is not running, all this under 8BETA-3, both under 32 and 64 bit.
thnaks,
	danny


From bschmidt at techwires.net  Mon Sep  7 10:40:08 2009
From: bschmidt at techwires.net (Bernhard Schmidt)
Date: Mon Sep  7 10:40:15 2009
Subject: boot from raidz
In-Reply-To: <27537.1252314818@namp.de>
References: <27537.1252314818@namp.de>
Message-ID: <168D71B8-F31B-43A8-9110-9C273EA8F97A@techwires.net>


Am 07.09.2009 um 11:13 schrieb Oliver Fakler:

>
> BODY { font-family:Arial, Helvetica, sans-serif;font-size:12px; }
>
> On Mon 07/09/09 10:07 , Bernhard Schmidt <bschmidt@techwires.net>  
> wrote:
>
>
> Am 06.09.2009 um 21:45 schrieb Oliver Fakler:
>
> >
> >
> > Hi all,
> >
> > i installed a 8.0 beta 3 amd64 based testsystem.
> >
> > i tried with a root on a raidz, but i have a problem after the first
> > reboot, there is a error message:
> >
> > can't load kernel
> > I found something that boot root from raidz is not supported, but
> > maybe there is a solution??
> > Hope some can help me
>
>
> There are patches from Doug Rabson which add support for booting from
> raidz/raidz2.
>
> http://lists.freebsd.org/pipermail/freebsd-fs/2008-December/005498.html 
> " target="_blank">http://lists.freebsd.org/pipermail/freebsd-fs/2008-December/005498.html



Seems that patch made it already into the tree (r192194).



>
>
> I tried it, but after a make obj && make depend the make failed with  
> different errors like undeclared and has no member named.
>
> I used patch raidzboot-14052009.diff started patching from /usr/src/ 
> sys/ , i'm not sure if this was the right way.
>
> I'm also not sure if the way of installation was the right one,  
> here's the way i go:
>
>
> gpart create -s GPT da0
> gpart add -b 34 -s 128 -t freebsd-boot da0
> gpart add -b 162 -s 5242880 -t freebsd-swap da0
> gpart add -b 5243042 -s 11534141 -t freebsd-zfs da0
> gpart bootcode -b /mnt2/boot/pmbr -p /mnt2/boot/gptzfsboot -i 1 da0
> gpart bootcode -b /mnt2/boot/pmbr -p /mnt2/boot/gptzfsboot -i 1 da1
> gpart bootcode -b /mnt2/boot/pmbr -p /mnt2/boot/gptzfsboot -i 1 da2
>


Can you try zfsboot instead of gptzfsboot?
http://unix.derkeiler.com/Mailing-Lists/FreeBSD/stable/2009-05/msg00689.html 
  at the end of the mail.


>
>
> kldload /mnt2/boot/kernel/opensolaris.ko
> kldload /mnt2/boot/kernel/zfs.ko
>
> zpool create tank raidz da0p3 da1p1 d2p1
>
> zfs create tank/tmp
> zfs create tank/usr
> zfs create tank/var
>
> cd /dist/8.0-BETA3/base
> export DESTDIR=/tank
> ./install.sh
> You are about to extract the base distribution into /tank - are you  
> SURE
> you want to do this over your installed system (y/n)? y
> cd ../kernels
> ./install.sh generic
> cd /tank/boot
> cp -Rp GENERIC/* kernel/
>
> cd /dist/8.0-BETA3/src
> ./install.sh all
> Extracting sources into /usr/src...
>   Extracting source component: base
>   Extracting source component: bin
>   Extracting source component: cddl
>   Extracting source component: contrib
>   Extracting source component: crypto
>   Extracting source component: etc
>   Extracting source component: games
>   Extracting source component: gnu
>   Extracting source component: include
>   Extracting source component: krb5
>   Extracting source component: lib
>   Extracting source component: libexec
>   Extracting source component: release
>   Extracting source component: rescue
>   Extracting source component: sbin
>   Extracting source component: secure
>   Extracting source component: share
>   Extracting source component: sys
>   Extracting source component: tools
>   Extracting source component: ubin
>   Extracting source component: usbin
> Done extracting sources.
> Done extracting sources.
> cd ../manpages
> ./install.sh
>
> echo 'zfs_enable="YES"' > /tank/etc/rc.conf
> echo 'LOADER_ZFS_SUPPORT="YES"' > /tank/etc/src.conf
> echo 'zfs_load="YES"' > /tank/boot/loader.conf
> echo 'vfs.root.mountfrom="zfs:tank"' >> /tank/boot/loader.conf
> echo ?/dev/da0p2 none swap sw 0 0?>> /tank/etc/fstab
>
> mkdir /boot/zfs
> zpool export tank && zpool import tank
> cp /boot/zfs/zpool.cache /tank/boot/zfs/
>
> chroot /tank
> mount -t devfs devfs /dev
> unset DESTDIR
> cd /usr/src/sys/boot/
> make obj
> make depend
> make
> cd i386/loader
> make install
> umount /dev
> touch /etc/fstab
> exit
>
> export LD_LIBRARY_PATH=/mnt2/lib
> zfs set mountpoint=legacy tank
> zfs set mountpoint=/tmp tank/tmp
> zfs set mountpoint=/var tank/var
> zfs set mountpoint=/usr tank/usr
> zpool set bootfs=tank tank
>


Seems correct at first glance.


--
Bernhard
From mad at madpilot.net  Mon Sep  7 12:34:26 2009
From: mad at madpilot.net (Guido Falsi)
Date: Mon Sep  7 12:34:35 2009
Subject: boot from raidz
In-Reply-To: <168D71B8-F31B-43A8-9110-9C273EA8F97A@techwires.net>
References: <27537.1252314818@namp.de>
	<168D71B8-F31B-43A8-9110-9C273EA8F97A@techwires.net>
Message-ID: <20090907123423.GB57582@megatron.madpilot.net>

On Mon, Sep 07, 2009 at 12:40:05PM +0200, Bernhard Schmidt wrote:
> >
> >echo 'zfs_enable="YES"' > /tank/etc/rc.conf
> >echo 'LOADER_ZFS_SUPPORT="YES"' > /tank/etc/src.conf
> >echo 'zfs_load="YES"' > /tank/boot/loader.conf
> >echo 'vfs.root.mountfrom="zfs:tank"' >> /tank/boot/loader.conf
[...]
> 
> 
> Seems correct at first glance.

two things come to my mind: are we sure the loader you have installed(the
ones from the distribution CD I think) was compiled with
LOADER_ZFS_SUPPORT="YES" set? I don't think this is the case. Usually I
have to compile one on another machine(or just grab the one from a
similar machine) and overwrite the distribution one.

Another thing I notice; have you populated /boot/zfs/zpool.cache ??

-- 
Guido Falsi <mad@madpilot.net>
From reuf_m at hotmail.com  Mon Sep  7 12:58:11 2009
From: reuf_m at hotmail.com (Mustabasic Reuf)
Date: Mon Sep  7 12:58:18 2009
Subject: FreeBSD-8.0BETA[1,2,3,4] hang at boot on iMac
Message-ID: <BLU0-SMTP5E91D640F761A06BD5B70F9EB0@phx.gbl>

Hi all !

I tried with all BETAs, the resulat is the same
(see screenshot : http://i30.tinypic.com/mkhflh.jpg )

iMac is last generation (iMac 9, apr. 2009), 7.2 worked flawlessly.

If any additional info is required (ACPI debug output, dmesg...) just make  
a sign.
From hselasky at c2i.net  Mon Sep  7 13:32:38 2009
From: hselasky at c2i.net (Hans Petter Selasky)
Date: Mon Sep  7 13:32:46 2009
Subject: FreeBSD-8.0BETA[1,2,3,4] hang at boot on iMac
In-Reply-To: <BLU0-SMTP5E91D640F761A06BD5B70F9EB0@phx.gbl>
References: <BLU0-SMTP5E91D640F761A06BD5B70F9EB0@phx.gbl>
Message-ID: <200909071533.02121.hselasky@c2i.net>

On Monday 07 September 2009 16:46:08 Mustabasic Reuf wrote:
> Hi all !
>
> I tried with all BETAs, the resulat is the same
> (see screenshot : http://i30.tinypic.com/mkhflh.jpg )
>
> iMac is last generation (iMac 9, apr. 2009), 7.2 worked flawlessly.
>
> If any additional info is required (ACPI debug output, dmesg...) just make
> a sign.

Hi,

This is likely a known issue related to some recent PAT changes which makes 
the CPU microcode hang when enabling ACPI.

--HPS
From gavin at FreeBSD.org  Mon Sep  7 14:10:16 2009
From: gavin at FreeBSD.org (Gavin Atkinson)
Date: Mon Sep  7 14:10:25 2009
Subject: Fatal trap 12: page fault while in kernel mode
In-Reply-To: <4AA384EC.3060003@lissyara.su>
References: <4AA384EC.3060003@lissyara.su>
Message-ID: <1252332612.55883.10.camel@buffy.york.ac.uk>

On Sun, 2009-09-06 at 13:46 +0400, Alex Keda wrote:
> hi!
> I have fatal trap with today (and yesterday) current.
> Machine boot, I see:
> Timecounters tick every 1.000 msec
> then, it freese ~30 seconds and go to kernel debugger - fatal trap 12
> stopped at _mtx_lock_spin_failed+0x2f: movl 0x78(%r12),%r8d

At the debugger prompt, can you give the "bt" command, and show us what
the output is please?

Gavin
From kensmith at buffalo.edu  Mon Sep  7 14:44:30 2009
From: kensmith at buffalo.edu (Ken Smith)
Date: Mon Sep  7 14:44:37 2009
Subject: 8.0-BETA4 Available
Message-ID: <1252333598.56240.23.camel@bauer.cse.buffalo.edu>


The fourth and most likely final BETA build for the FreeBSD 8.0 release
cycle is now available.  We expect the next test build to be the first
if the Release Candidates, RC1.  Since BETA3 many bugs that were
identified from testing done so far were addressed.  Some of the bigger
issues were an mbuf leak along with work done in the general IPv6, jail,
and usb subsystems.  Issues in other areas have been addressed as well.

Due to the issues identified in this early phase of testing the schedule
for release has been pushed back.  The current target for the release
itself is September 29th, with two RC builds between now and then.
Details about the current target schedule along with much more detail
about the current status of the release is available here:

	http://wiki.freebsd.org/8.0TODO

If you notice problems you can report them through the normal Gnats PR
system or on the freebsd-current mailing list.  I do cross-post
announcements to freebsd-stable because this particular release is
"about to become a stable branch" but when it comes to watching for
issues related to the release most of the developers pay more attention
to the freebsd-current list.

ISO images for all supported architectures are available on the FTP
sites, (sparc64 was uploaded a short time ago and may not be available
on some sites yet) and a "memory stick" image is available for
amd64/i386 architectures.  For amd64/i386 architectures the cdrom and
memstick images include the documentation packages this time but no
other packages.  The DVD image includes a first rough pass at what
packages will be available but the list will certainly change between
now and release.  None of the other images include packages.

If you are using csup/cvsup methods to update an older system the branch
tag to use is RELENG_8.

The freebsd-update(8) utility supports binary upgrades of i386 and amd64
systems running earlier FreeBSD releases. Systems running 7.0-RELEASE,
7.1-RELEASE, 7.2-RELEASE, 8.0-BETA1, 8.0-BETA2, or 8.0-BETA3 can upgrade
as follows:
  
# freebsd-update upgrade -r 8.0-BETA4
  
During this process, FreeBSD Update may ask the user to help by merging
some configuration files or by confirming that the automatically
performed merging was done correctly.  Systems running 8.0-BETA3 may
print the warning

	INDEX-OLD.all: Invalid arguments

when downloading updates; this warning is a harmless bug (fixed in
8.0-BETA4) and can be safely ignored.

# freebsd-update install
  
The system must be rebooted with the newly installed kernel before continuing.
  
# shutdown -r now
   
After rebooting, freebsd-update needs to be run again to install the new
userland components:

# freebsd-update install
   
At this point, users of systems being upgraded from FreeBSD 7.x will be
prompted by freebsd-update to rebuild all third-party applications
(e.g., ports installed from the ports tree) due to updates in system
libraries.  See:

http://www.daemonology.net/blog/2009-07-11-freebsd-update-to-8.0-beta1.html

for mode details.  After updating installed third-party applications
(and again, only if freebsd-update printed a message indicating that
this was necessary), run freebsd-update again so that it can delete the
old (no longer used) system libraries:

# freebsd-update install
   
Finally, reboot into 8.0-BETA4:
   
# shutdown -r now

MD5/SHA256 checksums for the image files:

MD5 (8.0-BETA4-amd64-bootonly.iso) = 4215023f0492e959be3c643fef44d448
MD5 (8.0-BETA4-amd64-disc1.iso) = f767d33bbaa0af665e33992c1f43cc39
MD5 (8.0-BETA4-amd64-dvd1.iso) = ac66ea49d75908607c0fe984f88b7a50
MD5 (8.0-BETA4-amd64-livefs.iso) = ead1d6a75cce81a24d3d3b8f0cbc8faf
MD5 (8.0-BETA4-amd64-memstick.img) = 69629e60befe708b4373871af23d61a3

MD5 (8.0-BETA4-i386-bootonly.iso) = db2e16a1a807d124a693743ca7a75992
MD5 (8.0-BETA4-i386-disc1.iso) = 30508ce737aa29d0fe2baf2f450ddc83
MD5 (8.0-BETA4-i386-dvd1.iso) = 307b28a35bcfbb547ce3afbbad051e89
MD5 (8.0-BETA4-i386-livefs.iso) = d65f152bfbd62ea5e3c2e1858bbb89ee
MD5 (8.0-BETA4-i386-memstick.img) = 5d262034175abd24b27ec7110ebd88a7

MD5 (8.0-BETA4-ia64-bootonly.iso) = 5147bd2c2dba2a72ec7f36eb8af0ccb6
MD5 (8.0-BETA4-ia64-disc1.iso) = 4da8a10c19c6642175a13aacf5fbf996
MD5 (8.0-BETA4-ia64-disc2.iso) = 895fca6034ecec7afb99878dbc93ded9
MD5 (8.0-BETA4-ia64-disc3.iso) = 49e440ad63251033bc154b35a48b379e
MD5 (8.0-BETA4-ia64-dvd1.iso) = 52350dd2bd330fa58271819cb82c5e79
MD5 (8.0-BETA4-ia64-livefs.iso) = 93018d3777f360780272188a4473dda5

MD5 (8.0-BETA4-pc98-bootonly.iso) = 3c1340312e19f5a14c46fbce001fbafa
MD5 (8.0-BETA4-pc98-disc1.iso) = 495674329c64d6d60b0d41f0922ac20a
MD5 (8.0-BETA4-pc98-livefs.iso) = ede97f44cbf9c0205ca0b50b0b7900b9

MD5 (8.0-BETA4-powerpc-bootonly.iso) = 71deda0e81c1bfa1c232e85aec7b5852
MD5 (8.0-BETA4-powerpc-disc1.iso) = cb437fe6c588035492d30a4c9a4ec7f9
MD5 (8.0-BETA4-powerpc-disc2.iso) = 2c59a9fcf633c64fe9462967bbd14a93
MD5 (8.0-BETA4-powerpc-disc3.iso) = fb2d9d5a59518d30c28c8454bdf66ed4

MD5 (8.0-BETA4-sparc64-bootonly.iso) = e2cc9393e0b596acdb36a8b07fbc480e
MD5 (8.0-BETA4-sparc64-disc1.iso) = 706f2e57ff1502ccaac37dd4571d898a
MD5 (8.0-BETA4-sparc64-dvd1.iso) = 9ac3509c8731874ae20009f170daf0e7

SHA256 (8.0-BETA4-amd64-bootonly.iso) = 3b4a1b964f64e68609f8010e43145c7a757c352e62b2b8128dff3947f08c330b
SHA256 (8.0-BETA4-amd64-disc1.iso) = e42cb6a4d46fcc924615949fe9da4217f9c824e4c30fb6371787e28d5ec50ff8
SHA256 (8.0-BETA4-amd64-dvd1.iso) = 61bb39599c2b2b76de0643d677702683c4274901dbaaa3944b3a419402046dcf
SHA256 (8.0-BETA4-amd64-livefs.iso) = f6b9fc2bfe74bb7bc730fa6786af09e4cca8d92a812ee1968283dff3eb6adc48
SHA256 (8.0-BETA4-amd64-memstick.img) = a930e419bed019114ddcf5833b3af1950f4ef32444bb02b1b84e84d91c754bda

SHA256 (8.0-BETA4-i386-bootonly.iso) = c2adde76995cbc25ac16afb2c4cb46686df54435f64e98ae4701908f024a0102
SHA256 (8.0-BETA4-i386-disc1.iso) = 0bbee2a9ffd4c00070cae001652037c8b194502dfc1a35c3ac0da1172c26bfdd
SHA256 (8.0-BETA4-i386-dvd1.iso) = 4dcd81040e977ff2f6c30aae04497416c2aec9eb8d4a5ac0dab6f2cd965bfaee
SHA256 (8.0-BETA4-i386-livefs.iso) = fac4c8c08698c30801f4555d5127c8bb5d786d6bebe164fd27e66bea737526bf
SHA256 (8.0-BETA4-i386-memstick.img) = 4a39d259b18f8d900a7bfc1878ed6ac4fda82812e13999da0265976eb1ba15e8

SHA256 (8.0-BETA4-ia64-bootonly.iso) = 5688b9c8bf13337835b2dce2fa7d6fb0ea17d397e927ef770d097a6728c8db23
SHA256 (8.0-BETA4-ia64-disc1.iso) = 33ddac157f6529bb31388d8c4ffdfb4824c989c0c0d843ecec071eb67ea36786
SHA256 (8.0-BETA4-ia64-disc2.iso) = ae71fd5d8d29666fa15689ddd8ffd45e3b6d354af9e1cb96b5a62280b452cbe5
SHA256 (8.0-BETA4-ia64-disc3.iso) = 330b43e5f81887de948257db46ed407a5c5a94c09e6d41155159e0617c0be53e
SHA256 (8.0-BETA4-ia64-dvd1.iso) = 4324c3c08d625b92942424a1c6e14085593ee62237ddd4f2eac2f35d7fb0f27b
SHA256 (8.0-BETA4-ia64-livefs.iso) = 860cad096ef74efa534bae3642dff5ec545ed47faa21a6cd65b197b12827885d

SHA256 (8.0-BETA4-pc98-bootonly.iso) = 0ce882dd48863f2f4180cbdf5f17ff595d7942bf7ac84029adef27a65b1b5481
SHA256 (8.0-BETA4-pc98-disc1.iso) = 4815a84ef0e834d3d57f7420c1f25ff93d0e3b698cc6eecee8b587f9896edd01
SHA256 (8.0-BETA4-pc98-livefs.iso) = cb6ea4a931551c2220c739d66f05c120926a7c2650373fc72770a25ea5e10a3d

SHA256 (8.0-BETA4-powerpc-bootonly.iso) = 6f97a8c061065661996e6efdad45bbbaaafc2e8f80717fa845b2bc3ae14d7212
SHA256 (8.0-BETA4-powerpc-disc1.iso) = 9b1fb4af1a9a53e5723fdfd897d8a57a4e815ada22637285b7360d24f512290c
SHA256 (8.0-BETA4-powerpc-disc2.iso) = 8e82ccaca6673cb3177870748ffdcb891fb16904eacd98822cca31f9888656ae
SHA256 (8.0-BETA4-powerpc-disc3.iso) = 651561d9021d5c68f266f21d6df31c87fec1368a428492274177810ea1333c3c

SHA256 (8.0-BETA4-sparc64-bootonly.iso) = 35dd8a303df41cb7ca744c37aee104e18f441967a14a3c9eb36bc4bcaf78c01b
SHA256 (8.0-BETA4-sparc64-disc1.iso) = 1d5ab4e67225a8640c9200424a140fff003203ab5edb855172d7030130974529
SHA256 (8.0-BETA4-sparc64-dvd1.iso) = 59ab2cca0fa637e9ef5007117f1005570c102cf4665009c6021992dd1b8bd77b

-- 
                                                Ken Smith
- From there to here, from here to      |       kensmith@buffalo.edu
  there, funny things are everywhere.   |
                      - Theodore Geisel |

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 195 bytes
Desc: This is a digitally signed message part
Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20090907/eba45a1b/attachment.pgp
From oliver at namp.de  Mon Sep  7 09:09:54 2009
From: oliver at namp.de (Oliver Fakler)
Date: Mon Sep  7 14:51:17 2009
Subject: boot from raidz
Message-ID: <27537.1252314818@namp.de>



On Mon 07/09/09 10:07 , Bernhard Schmidt  wrote:
 Am 06.09.2009 um 21:45 schrieb Oliver Fakler:
 >
 >
 > Hi all,
 >
 > i installed a 8.0 beta 3 amd64 based testsystem.
 >
 > i tried with a root on a raidz, but i have a problem after the
first
 > reboot, there is a error message:
 >
 > can't load kernel
 > I found something that boot root from raidz is not supported, but
 > maybe there is a solution??
 > Hope some can help me
 There are patches from Doug Rabson which add support for booting
from  
 raidz/raidz2.

http://lists.freebsd.org/pipermail/freebsd-fs/2008-December/005498.html
[1]"
target="_blank">http://lists.freebsd.org/pipermail/freebsd-fs/2008-December/005498.html
 --
 Bernhard
	I tried it, but after a make obj && make depend the make failed with
different errors like undeclared and has no member named.

	I used patch raidzboot-14052009.diff started patching from
/usr/src/sys/ , i'm not sure if this was the right way.

	I'm also not sure if the way of installation was the right one,
here's the way i go:
	gpart create -s GPT da0
gpart add -b 34 -s 128 -t freebsd-boot da0
gpart add -b 162 -s 5242880 -t freebsd-swap da0
gpart add -b 5243042 -s 11534141 -t freebsd-zfs da0
gpart bootcode -b /mnt2/boot/pmbr -p /mnt2/boot/gptzfsboot -i 1 da0
gpart bootcode -b /mnt2/boot/pmbr -p /mnt2/boot/gptzfsboot -i 1 da1
gpart bootcode -b /mnt2/boot/pmbr -p /mnt2/boot/gptzfsboot -i 1 da2
kldload /mnt2/boot/kernel/opensolaris.ko
kldload /mnt2/boot/kernel/zfs.ko

zpool create tank raidz da0p3 da1p1 d2p1

zfs create tank/tmp
zfs create tank/usr
zfs create tank/var

cd /dist/8.0-BETA3/base
export DESTDIR=/tank
./install.sh
You are about to extract the base distribution into /tank - are you
SURE
you want to do this over your installed system (y/n)? y
cd ../kernels
./install.sh generic
cd /tank/boot
cp -Rp GENERIC/* kernel/

cd /dist/8.0-BETA3/src
./install.sh all
Extracting sources into /usr/src...
  Extracting source component: base
  Extracting source component: bin
  Extracting source component: cddl
  Extracting source component: contrib
  Extracting source component: crypto
  Extracting source component: etc
  Extracting source component: games
  Extracting source component: gnu
  Extracting source component: include
  Extracting source component: krb5
  Extracting source component: lib
  Extracting source component: libexec
  Extracting source component: release
  Extracting source component: rescue
  Extracting source component: sbin
  Extracting source component: secure
  Extracting source component: share
  Extracting source component: sys
  Extracting source component: tools
  Extracting source component: ubin
  Extracting source component: usbin
Done extracting sources.
Done extracting sources.
cd ../manpages
./install.sh

echo 'zfs_enable="YES"' > /tank/etc/rc.conf
echo 'LOADER_ZFS_SUPPORT="YES"' > /tank/etc/src.conf
echo 'zfs_load="YES"' > /tank/boot/loader.conf
echo 'vfs.root.mountfrom="zfs:tank"' >> /tank/boot/loader.conf
echo &acute;/dev/da0p2 none swap sw 0 0&acute;>> /tank/etc/fstab

mkdir /boot/zfs
zpool export tank && zpool import tank
cp /boot/zfs/zpool.cache /tank/boot/zfs/

chroot /tank
mount -t devfs devfs /dev
unset DESTDIR
cd /usr/src/sys/boot/
make obj
make depend
make
cd i386/loader
make install
umount /dev
touch /etc/fstab
exit

export LD_LIBRARY_PATH=/mnt2/lib
zfs set mountpoint=legacy tank
zfs set mountpoint=/tmp tank/tmp
zfs set mountpoint=/var tank/var
zfs set mountpoint=/usr tank/usr
zpool set bootfs=tank tank
	Cheers
	Oliver

Links:
------
[1] http://mail.kuehlbox.de/parse.php?redirect=<a href=
From oliver at namp.de  Mon Sep  7 14:22:41 2009
From: oliver at namp.de (Oliver Fakler)
Date: Mon Sep  7 14:51:58 2009
Subject: boot from raidz
Message-ID: <36922.1252333586@namp.de>



On Mon 07/09/09 15:34 , Guido Falsi  wrote:On Mon, Sep 07, 2009 at
12:40:05PM +0200, Bernhard Schmidt wrote:
 > >
 > >echo 'zfs_enable="YES"' > /tank/etc/rc.conf
 > >echo 'LOADER_ZFS_SUPPORT="YES"' > /tank/etc/src.conf
 > >echo 'zfs_load="YES"' > /tank/boot/loader.conf
 > >echo 'vfs.root.mountfrom="zfs:tank"' >> /tank/boot/loader.conf
 [...]
 > 
 > 
 > Seems correct at first glance.
 two things come to my mind: are we sure the loader you have
installed(the
 ones from the distribution CD I think) was compiled with
 LOADER_ZFS_SUPPORT="YES" set? I don't think this is the case.
Usually I
 have to compile one on another machine(or just grab the one from a
 similar machine) and overwrite the distribution one.
 Another thing I notice; have you populated /boot/zfs/zpool.cache ??
 -- 
 Guido Falsi 
	i testet it with loader_zfs_support=yes in make.conf

	and i copied the zpool.cache to/tank/boot/zfs
	the same howto works wirh a single zfs pool, so i don't think that
the problem is located in zpool.cache
	Cheers
	Oliver
From oliver at namp.de  Mon Sep  7 14:29:15 2009
From: oliver at namp.de (Oliver Fakler)
Date: Mon Sep  7 14:52:45 2009
Subject: boot from raidz
Message-ID: <19600.1252333979@namp.de>



On Mon 07/09/09 13:40 , Bernhard Schmidt  wrote:
 Am 07.09.2009 um 11:13 schrieb Oliver Fakler:
 >
 > BODY { font-family:Arial, Helvetica, sans-serif;font-size:12px; }
 >
 > On Mon 07/09/09 10:07 , Bernhard Schmidt   
 > wrote:
 >
 >
 > Am 06.09.2009 um 21:45 schrieb Oliver Fakler:
 >
 > >
 > >
 > > Hi all,
 > >
 > > i installed a 8.0 beta 3 amd64 based testsystem.
 > >
 > > i tried with a root on a raidz, but i have a problem after the
first
 > > reboot, there is a error message:
 > >
 > > can't load kernel
 > > I found something that boot root from raidz is not supported,
but
 > > maybe there is a solution??
 > > Hope some can help me
 >
 >
 > There are patches from Doug Rabson which add support for booting
from
 > raidz/raidz2.
 >
 >
http://lists.freebsd.org/pipermail/freebsd-fs/2008-December/005498.html
[2]"
target="_blank">http://lists.freebsd.org/pipermail/freebsd-fs/2008-December/005498.html

 > "
target="_blank">http://lists.freebsd.org/pipermail/freebsd-fs/2008-December/005498.html
[3]"
target="_blank">http://lists.freebsd.org/pipermail/freebsd-fs/2008-December/005498.html
 Seems that patch made it already into the tree (r192194).
 >
 >
 > I tried it, but after a make obj && make depend the make failed
with  
 > different errors like undeclared and has no member named.
 >
 > I used patch raidzboot-14052009.diff started patching from
/usr/src/ 
 > sys/ , i'm not sure if this was the right way.
 >
 > I'm also not sure if the way of installation was the right one,  
 > here's the way i go:
 >
 >
 > gpart create -s GPT da0
 > gpart add -b 34 -s 128 -t freebsd-boot da0
 > gpart add -b 162 -s 5242880 -t freebsd-swap da0
 > gpart add -b 5243042 -s 11534141 -t freebsd-zfs da0
 > gpart bootcode -b /mnt2/boot/pmbr -p /mnt2/boot/gptzfsboot -i 1
da0
 > gpart bootcode -b /mnt2/boot/pmbr -p /mnt2/boot/gptzfsboot -i 1
da1
 > gpart bootcode -b /mnt2/boot/pmbr -p /mnt2/boot/gptzfsboot -i 1
da2
 >
 Can you try zfsboot instead of gptzfsboot?

http://unix.derkeiler.com/Mailing-Lists/FreeBSD/stable/2009-05/msg00689.html
[4]"
target="_blank">http://unix.derkeiler.com/Mailing-Lists/FreeBSD/stable/2009-05/msg00689.html

   at the end of the mail.
 >
 >
 > kldload /mnt2/boot/kernel/opensolaris.ko
 > kldload /mnt2/boot/kernel/zfs.ko
 >
 > zpool create tank raidz da0p3 da1p1 d2p1
 >
 > zfs create tank/tmp
 > zfs create tank/usr
 > zfs create tank/var
 >
 > cd /dist/8.0-BETA3/base
 > export DESTDIR=/tank
 > ./install.sh
 > You are about to extract the base distribution into /tank - are
you  
 > SURE
 > you want to do this over your installed system (y/n)? y
 > cd ../kernels
 > ./install.sh generic
 > cd /tank/boot
 > cp -Rp GENERIC/* kernel/
 >
 > cd /dist/8.0-BETA3/src
 > ./install.sh all
 > Extracting sources into /usr/src...
 >   Extracting source component: base
 >   Extracting source component: bin
 >   Extracting source component: cddl
 >   Extracting source component: contrib
 >   Extracting source component: crypto
 >   Extracting source component: etc
 >   Extracting source component: games
 >   Extracting source component: gnu
 >   Extracting source component: include
 >   Extracting source component: krb5
 >   Extracting source component: lib
 >   Extracting source component: libexec
 >   Extracting source component: release
 >   Extracting source component: rescue
 >   Extracting source component: sbin
 >   Extracting source component: secure
 >   Extracting source component: share
 >   Extracting source component: sys
 >   Extracting source component: tools
 >   Extracting source component: ubin
 >   Extracting source component: usbin
 > Done extracting sources.
 > Done extracting sources.
 > cd ../manpages
 > ./install.sh
 >
 > echo 'zfs_enable="YES"' > /tank/etc/rc.conf
 > echo 'LOADER_ZFS_SUPPORT="YES"' > /tank/etc/src.conf
 > echo 'zfs_load="YES"' > /tank/boot/loader.conf
 > echo 'vfs.root.mountfrom="zfs:tank"' >> /tank/boot/loader.conf
 > echo &acute;/dev/da0p2 none swap sw 0 0&acute;>> /tank/etc/fstab
 >
 > mkdir /boot/zfs
 > zpool export tank && zpool import tank
 > cp /boot/zfs/zpool.cache /tank/boot/zfs/
 >
 > chroot /tank
 > mount -t devfs devfs /dev
 > unset DESTDIR
 > cd /usr/src/sys/boot/
 > make obj
 > make depend
 > make
 > cd i386/loader
 > make install
 > umount /dev
 > touch /etc/fstab
 > exit
 >
 > export LD_LIBRARY_PATH=/mnt2/lib
 > zfs set mountpoint=legacy tank
 > zfs set mountpoint=/tmp tank/tmp
 > zfs set mountpoint=/var tank/var
 > zfs set mountpoint=/usr tank/usr
 > zpool set bootfs=tank tank
 >
 Seems correct at first glance.
 --
 Bernhard
	testet with zfsboot instead of gptzfsboot but it was not successfull
:-(

Links:
------
[2] http://mail.kuehlbox.de/parse.php?redirect=<a href=
[3] http://mail.kuehlbox.de/parse.php?redirect=<a href=
[4] http://mail.kuehlbox.de/parse.php?redirect=<a href=
From unixmania at gmail.com  Mon Sep  7 14:56:06 2009
From: unixmania at gmail.com (Carlos A. M. dos Santos)
Date: Mon Sep  7 14:56:12 2009
Subject: Funding ODD support
In-Reply-To: <4AA33DF9.6070803@omnilan.de>
References: <4AA33DF9.6070803@omnilan.de>
Message-ID: <e71790db0909070732v51baf3a8i574107ab6387bfba@mail.gmail.com>

On Sun, Sep 6, 2009 at 1:43 AM, Harald
Schmalzbauer<h.schmalzbauer@omnilan.de> wrote:
> Hello,
>
> I'm looking for somebody who has time and knowledge to fix ODD support in
> FreeBSD.
[...]

I'm not sure if such work should be funded by a separate bounty or by
the FreeBSD foundation. Anyway, I would happily donate some money for
improvements on the CD/DVD writing support. I'd like to see either an
improved version of burncd or some new tool provided by the base
system.

-- 
My preferred quotation of Robert Louis Stevenson is "You cannot
make an omelette without breaking eggs". Not because I like the
omelettes, but because I like the sound of eggs being broken.
From admin at lissyara.su  Mon Sep  7 15:36:17 2009
From: admin at lissyara.su (Alex Keda)
Date: Mon Sep  7 15:36:24 2009
Subject: Fatal trap 12: page fault while in kernel mode
In-Reply-To: <1252332612.55883.10.camel@buffy.york.ac.uk>
References: <4AA384EC.3060003@lissyara.su>
	<1252332612.55883.10.camel@buffy.york.ac.uk>
Message-ID: <4AA5286D.7040400@lissyara.su>

Gavin Atkinson ?????:
> On Sun, 2009-09-06 at 13:46 +0400, Alex Keda wrote:
>> hi!
>> I have fatal trap with today (and yesterday) current.
>> Machine boot, I see:
>> Timecounters tick every 1.000 msec
>> then, it freese ~30 seconds and go to kernel debugger - fatal trap 12
>> stopped at _mtx_lock_spin_failed+0x2f: movl 0x78(%r12),%r8d
> 
> At the debugger prompt, can you give the "bt" command, and show us what
> the output is please?
It:
 >> stopped at _mtx_lock_spin_failed+0x2f: movl 0x78(%r12),%r8d
from bt, last string.
or need all output?
From nick-lists at netability.ie  Mon Sep  7 15:51:06 2009
From: nick-lists at netability.ie (Nick Hilliard)
Date: Mon Sep  7 15:52:34 2009
Subject: 8.0-beta3 does not detect several ata channels
In-Reply-To: <200909011002.59592.jhb@freebsd.org>
References: <4A9BF23F.6070801@netability.ie> <4A9BF438.1000006@smeets.im>
	<200909011002.59592.jhb@freebsd.org>
Message-ID: <4AA52BE4.3070708@netability.ie>

On 01/09/2009 15:02, John Baldwin wrote:
> Hmm, so an idea I had just now.. can you grab a dump of the PCI config space
> for the disk controller in the MCFG vs non-MCFG cases?  That is, find the
> device's address using pciconf -lv (e.g. pci0:0:30:0 or some such) and then
> run this command under both configurations and save the output:
>
> pciconf -r pci0:0:30:0 0:0xfc

Ok, got this working on the beta4 livefs.  If hw.pci.mcfg=0, then all disks 
are detected correctly.

I've attached the pciconf output for each case.

Nick
-------------- next part --------------
037f10de 00b00007 010185a3 00800000
0000dd81 0000dd01 0000dc01 0000db81 
0000db01 fcebd000 00000000 1714103c
00000000 00000044 00000000 01030115 
1714103c 0002b001 00000000 00000000
8008680f 00000000 00000000 00000000 
00000000 00000c41 42060f00 00000000
40c4782c 00001001 00001001 00200020 
c0000000 02df8800 b0080000 02de8c00
90080000 00000000 10060006 0101037f 
18000a12 00000000 00000000 02003133
0084cc05 00000000 00000000 00000000 
00000000 00000000 000a000a a8020008
0302000a 00000042 00000000 e000482a 
0302000a 00000042 00000000 e7f0000f
00000000 00000000 000c0010 00000000 
-------------- next part --------------
037f10de 00b00007 010185a3 00800000
0000da81 0000da01 0000d981 0000d901 
0000d881 fcebc000 00000000 1714103c
00000000 00000044 00000000 01030216 
1714103c 0002b001 00000000 00000000
8008680f 00000000 00000000 00000000 
00000000 00000c41 42060f00 00000000
40c4782c 00001001 00001001 00200020 
c0000000 02df8800 b0080000 02df9000
90080000 00000000 10060006 0101037f 
18000a12 00000000 00000000 02003133
0084cc05 00000000 00000000 00000000 
00000000 00000000 000a000a a8020008
0302000a 00000042 00000000 e7d00001 
0302000a 00000042 00000000 e000000f
00000000 00000000 000c0010 00000000 
-------------- next part --------------
037f10de 00b00007 010185a3 00800000
0000d801 0000d781 0000d701 0000d681 
0000d601 fcebb000 00000000 1714103c
00000000 00000044 00000000 01030317 
1714103c 0002b001 00000000 00000000
8008680f 00000000 00000000 00000000 
00000000 00000c41 42060f00 00000000
40c4782c 00001001 00001001 00200020 
c0000000 02e5b800 b0080000 0d04f000
80080000 00000000 10060006 0101037f 
17000a12 00000000 00000000 02003133
0084cc05 00000000 00000000 00000000 
00000000 00000000 000a000a a8020008
0302000a 00000042 00000000 81001000 
0302000a 00000042 00000000 87f00001
00000000 00000000 000c0010 00000000 
-------------- next part --------------
037f10de 00b00007 010185a3 00800000
0000dd81 0000dd01 0000dc01 0000db81 
0000db01 fcebd000 00000000 1714103c
00000000 00000044 00000000 01030115 
1714103c 0002b001 00000000 00000000
8008680f 00000000 00000000 00000000 
00000000 00000c41 42060f00 00000000
40c4782c 00001001 00001001 00200020 
c0000000 78b69800 00080000 78762000
00080000 00000000 10060006 0101037f 
18000a12 00000000 00000000 02003133
0084cc05 00000000 00000000 00000000 
00000000 00000000 000a000a a8020008
0302000a 00000042 00000000 e000482a 
0302000a 00000042 00000000 e7f0000f
00000000 00000000 000c0010 00000000 
-------------- next part --------------
037f10de 00b00007 010185a3 00800000
0000da81 0000da01 0000d981 0000d901 
0000d881 fcebc000 00000000 1714103c
00000000 00000044 00000000 01030216 
1714103c 0002b001 00000000 00000000
8008680f 00000000 00000000 00000000 
00000000 00000c41 42060f00 00000000
40c4782c 00001001 00001001 00200020 
c0000000 02de8c00 b0080000 02de8800
90080000 00000000 10060006 0101037f 
18000a12 00000000 00000000 02003133
0084cc05 00000000 00000000 00000000 
00000000 00000000 000a000a a8020008
0302000a 00000042 00000000 e7d00001 
0302000a 00000042 00000000 e000000f
00000000 00000000 000c0010 00000000 
-------------- next part --------------
037f10de 00b00007 010185a3 00800000
0000d801 0000d781 0000d701 0000d681 
0000d601 fcebb000 00000000 1714103c
00000000 00000044 00000000 01030317 
1714103c 0002b001 00000000 00000000
8008680f 00000000 00000000 00000000 
00000000 00000c41 42060f00 00000000
40c4782c 00001001 00001001 00200020 
c0000000 02e6b400 b0080000 cfed0800
80080000 00000000 10060006 0101037f 
17000a12 00000000 00000000 02003133
0084cc05 00000000 00000000 00000000 
00000000 00000000 000a000a a8020008
0302000a 00000042 00000000 81001000 
0302000a 00000042 00000000 87f00001
00000000 00000000 000c0010 00000000 
-------------- next part --------------
none0@pci0:0:0:0:	class=0x050000 card=0x1714103c chip=0x036910de rev=0xa2 hdr=0x00
    class      = memory
    subclass   = RAM
isab0@pci0:0:1:0:	class=0x060100 card=0x1714103c chip=0x036010de rev=0xa3 hdr=0x00
    class      = bridge
    subclass   = PCI-ISA
none1@pci0:0:1:1:	class=0x0c0500 card=0x1714103c chip=0x036810de rev=0xa3 hdr=0x00
    class      = serial bus
    subclass   = SMBus
ohci0@pci0:0:2:0:	class=0x0c0310 card=0x1714103c chip=0x036c10de rev=0xa1 hdr=0x00
    class      = serial bus
    subclass   = USB
ehci0@pci0:0:2:1:	class=0x0c0320 card=0x1714103c chip=0x036d10de rev=0xa2 hdr=0x00
    class      = serial bus
    subclass   = USB
atapci0@pci0:0:5:0:	class=0x010185 card=0x1714103c chip=0x037f10de rev=0xa3 hdr=0x00
    class      = mass storage
    subclass   = ATA
atapci1@pci0:0:5:1:	class=0x010185 card=0x1714103c chip=0x037f10de rev=0xa3 hdr=0x00
    class      = mass storage
    subclass   = ATA
atapci2@pci0:0:5:2:	class=0x010185 card=0x1714103c chip=0x037f10de rev=0xa3 hdr=0x00
    class      = mass storage
    subclass   = ATA
pcib1@pci0:0:6:0:	class=0x060401 card=0x1714103c chip=0x037010de rev=0xa2 hdr=0x01
    class      = bridge
    subclass   = PCI-PCI
pcib2@pci0:0:10:0:	class=0x060400 card=0x000010de chip=0x037610de rev=0xa3 hdr=0x01
    class      = bridge
    subclass   = PCI-PCI
pcib3@pci0:0:11:0:	class=0x060400 card=0x000010de chip=0x037410de rev=0xa3 hdr=0x01
    class      = bridge
    subclass   = PCI-PCI
pcib4@pci0:0:12:0:	class=0x060400 card=0x000010de chip=0x037410de rev=0xa3 hdr=0x01
    class      = bridge
    subclass   = PCI-PCI
pcib5@pci0:0:13:0:	class=0x060400 card=0x000010de chip=0x037810de rev=0xa3 hdr=0x01
    class      = bridge
    subclass   = PCI-PCI
pcib6@pci0:0:14:0:	class=0x060400 card=0x000010de chip=0x037510de rev=0xa3 hdr=0x01
    class      = bridge
    subclass   = PCI-PCI
pcib7@pci0:0:15:0:	class=0x060400 card=0x000010de chip=0x037710de rev=0xa3 hdr=0x01
    class      = bridge
    subclass   = PCI-PCI
hostb0@pci0:0:24:0:	class=0x060000 card=0x00000000 chip=0x12001022 rev=0x00 hdr=0x00
    class      = bridge
    subclass   = HOST-PCI
hostb1@pci0:0:24:1:	class=0x060000 card=0x00000000 chip=0x12011022 rev=0x00 hdr=0x00
    class      = bridge
    subclass   = HOST-PCI
hostb2@pci0:0:24:2:	class=0x060000 card=0x00000000 chip=0x12021022 rev=0x00 hdr=0x00
    class      = bridge
    subclass   = HOST-PCI
hostb3@pci0:0:24:3:	class=0x060000 card=0x00000000 chip=0x12031022 rev=0x00 hdr=0x00
    class      = bridge
    subclass   = HOST-PCI
hostb4@pci0:0:24:4:	class=0x060000 card=0x00000000 chip=0x12041022 rev=0x00 hdr=0x00
    class      = bridge
    subclass   = HOST-PCI
em0@pci0:4:0:0:	class=0x020000 card=0x704a103c chip=0x10b98086 rev=0x06 hdr=0x00
    class      = network
    subclass   = ethernet
vgapci0@pci0:16:0:0:	class=0x030000 card=0x31fa103c chip=0x0522102b rev=0x02 hdr=0x00
    class      = display
    subclass   = VGA
bge0@pci0:17:0:0:	class=0x020000 card=0x7051103c chip=0x165a14e4 rev=0x00 hdr=0x00
    class      = network
    subclass   = ethernet
From hselasky at c2i.net  Mon Sep  7 16:17:26 2009
From: hselasky at c2i.net (Hans Petter Selasky)
Date: Mon Sep  7 16:17:33 2009
Subject: Elsa MicroLink 56k USB is not picked up by umodem
In-Reply-To: <C0A7294C-F239-4AA1-B4F7-A62F1AEBD967@lassitu.de>
References: <15577E21-9A9B-45CA-BC56-D1AB1FF6A5A9@lassitu.de>
	<200909012357.42238.hselasky@c2i.net>
	<C0A7294C-F239-4AA1-B4F7-A62F1AEBD967@lassitu.de>
Message-ID: <200909071817.43090.hselasky@c2i.net>

On Saturday 05 September 2009 22:20:55 Stefan Bethke 
wrote:
> Stefan Bethke <stb@lassitu.de>

Your quirk has been committed:

http://perforce.freebsd.org/chv.cgi?CH=168284

--HPS
From gavin at FreeBSD.org  Mon Sep  7 16:20:25 2009
From: gavin at FreeBSD.org (Gavin Atkinson)
Date: Mon Sep  7 16:20:32 2009
Subject: Fatal trap 12: page fault while in kernel mode
In-Reply-To: <4AA5286D.7040400@lissyara.su>
References: <4AA384EC.3060003@lissyara.su>
	<1252332612.55883.10.camel@buffy.york.ac.uk>
	<4AA5286D.7040400@lissyara.su>
Message-ID: <1252340419.55883.26.camel@buffy.york.ac.uk>

On Mon, 2009-09-07 at 19:36 +0400, Alex Keda wrote:
> Gavin Atkinson ?????:
> > On Sun, 2009-09-06 at 13:46 +0400, Alex Keda wrote:
> >> hi!
> >> I have fatal trap with today (and yesterday) current.
> >> Machine boot, I see:
> >> Timecounters tick every 1.000 msec
> >> then, it freese ~30 seconds and go to kernel debugger - fatal trap 12
> >> stopped at _mtx_lock_spin_failed+0x2f: movl 0x78(%r12),%r8d
> > 
> > At the debugger prompt, can you give the "bt" command, and show us what
> > the output is please?
> It:
>  >> stopped at _mtx_lock_spin_failed+0x2f: movl 0x78(%r12),%r8d
> from bt, last string.
> or need all output?

All output, please.

Gavin
From paul at fletchermoorland.co.uk  Mon Sep  7 16:23:35 2009
From: paul at fletchermoorland.co.uk (Paul Wootton)
Date: Mon Sep  7 16:23:43 2009
Subject: boot from raidz
In-Reply-To: <19600.1252333979@namp.de>
References: <19600.1252333979@namp.de>
Message-ID: <4AA5415E.3070203@fletchermoorland.co.uk>

Oliver Fakler wrote:
> On Mon 07/09/09 13:40 , Bernhard Schmidt  wrote:
>  Am 07.09.2009 um 11:13 schrieb Oliver Fakler:
>  >
>  > BODY { font-family:Arial, Helvetica, sans-serif;font-size:12px; }
>  >
>  > On Mon 07/09/09 10:07 , Bernhard Schmidt   
>  > wrote:
>  >
>  >
>  > Am 06.09.2009 um 21:45 schrieb Oliver Fakler:
>  >
>  > >
>  > >
>  > > Hi all,
>  > >
>  > > i installed a 8.0 beta 3 amd64 based testsystem.
>  > >
>  > > i tried with a root on a raidz, but i have a problem after the
> first
>  > > reboot, there is a error message:
>  > >
>  > > can't load kernel
>  > > I found something that boot root from raidz is not supported,
> but
>  > > maybe there is a solution??
>  > > Hope some can help me
>  >
>  >
>  > There are patches from Doug Rabson which add support for booting
> from
>  > raidz/raidz2.
>  >
>  >
> http://lists.freebsd.org/pipermail/freebsd-fs/2008-December/005498.html
> [2]"
> target="_blank">http://lists.freebsd.org/pipermail/freebsd-fs/2008-December/005498.html
>
>  > "
> target="_blank">http://lists.freebsd.org/pipermail/freebsd-fs/2008-December/005498.html
> [3]"
> target="_blank">http://lists.freebsd.org/pipermail/freebsd-fs/2008-December/005498.html
>  Seems that patch made it already into the tree (r192194).
>  >
>  >
>  > I tried it, but after a make obj && make depend the make failed
> with  
>  > different errors like undeclared and has no member named.
>  >
>  > I used patch raidzboot-14052009.diff started patching from
> /usr/src/ 
>  > sys/ , i'm not sure if this was the right way.
>  >
>  > I'm also not sure if the way of installation was the right one,  
>  > here's the way i go:
>  >
>  >
>  > gpart create -s GPT da0
>  > gpart add -b 34 -s 128 -t freebsd-boot da0
>  > gpart add -b 162 -s 5242880 -t freebsd-swap da0
>  > gpart add -b 5243042 -s 11534141 -t freebsd-zfs da0
>  > gpart bootcode -b /mnt2/boot/pmbr -p /mnt2/boot/gptzfsboot -i 1
> da0
>  > gpart bootcode -b /mnt2/boot/pmbr -p /mnt2/boot/gptzfsboot -i 1
> da1
>  > gpart bootcode -b /mnt2/boot/pmbr -p /mnt2/boot/gptzfsboot -i 1
> da2
>  >
>  Can you try zfsboot instead of gptzfsboot?
>
> http://unix.derkeiler.com/Mailing-Lists/FreeBSD/stable/2009-05/msg00689.html
> [4]"
> target="_blank">http://unix.derkeiler.com/Mailing-Lists/FreeBSD/stable/2009-05/msg00689.html
>
>    at the end of the mail.
>  >
>  >
>  > kldload /mnt2/boot/kernel/opensolaris.ko
>  > kldload /mnt2/boot/kernel/zfs.ko
>  >
>  > zpool create tank raidz da0p3 da1p1 d2p1
>  >
>  > zfs create tank/tmp
>  > zfs create tank/usr
>  > zfs create tank/var
>  >
>  > cd /dist/8.0-BETA3/base
>  > export DESTDIR=/tank
>  > ./install.sh
>  > You are about to extract the base distribution into /tank - are
> you  
>  > SURE
>  > you want to do this over your installed system (y/n)? y
>  > cd ../kernels
>  > ./install.sh generic
>  > cd /tank/boot
>  > cp -Rp GENERIC/* kernel/
>  >
>  > cd /dist/8.0-BETA3/src
>  > ./install.sh all
>  > Extracting sources into /usr/src...
>  >   Extracting source component: base
>  >   Extracting source component: bin
>  >   Extracting source component: cddl
>  >   Extracting source component: contrib
>  >   Extracting source component: crypto
>  >   Extracting source component: etc
>  >   Extracting source component: games
>  >   Extracting source component: gnu
>  >   Extracting source component: include
>  >   Extracting source component: krb5
>  >   Extracting source component: lib
>  >   Extracting source component: libexec
>  >   Extracting source component: release
>  >   Extracting source component: rescue
>  >   Extracting source component: sbin
>  >   Extracting source component: secure
>  >   Extracting source component: share
>  >   Extracting source component: sys
>  >   Extracting source component: tools
>  >   Extracting source component: ubin
>  >   Extracting source component: usbin
>  > Done extracting sources.
>  > Done extracting sources.
>  > cd ../manpages
>  > ./install.sh
>  >
>  > echo 'zfs_enable="YES"' > /tank/etc/rc.conf
>  > echo 'LOADER_ZFS_SUPPORT="YES"' > /tank/etc/src.conf
>  > echo 'zfs_load="YES"' > /tank/boot/loader.conf
>  > echo 'vfs.root.mountfrom="zfs:tank"' >> /tank/boot/loader.conf
>  > echo &acute;/dev/da0p2 none swap sw 0 0&acute;>> /tank/etc/fstab
>  >
>  > mkdir /boot/zfs
>  > zpool export tank && zpool import tank
>  > cp /boot/zfs/zpool.cache /tank/boot/zfs/
>  >
>  > chroot /tank
>  > mount -t devfs devfs /dev
>  > unset DESTDIR
>  > cd /usr/src/sys/boot/
>  > make obj
>  > make depend
>  > make
>  > cd i386/loader
>  > make install
>  > umount /dev
>  > touch /etc/fstab
>  > exit
>  >
>  > export LD_LIBRARY_PATH=/mnt2/lib
>  > zfs set mountpoint=legacy tank
>  > zfs set mountpoint=/tmp tank/tmp
>  > zfs set mountpoint=/var tank/var
>  > zfs set mountpoint=/usr tank/usr
>  > zpool set bootfs=tank tank
>  >
>  Seems correct at first glance.
>  --
>  Bernhard
> 	testet with zfsboot instead of gptzfsboot but it was not successfull
> :-(
>
> Links:
> ------
> [2] http://mail.kuehlbox.de/parse.php?redirect=<a href=
> [3] http://mail.kuehlbox.de/parse.php?redirect=<a href=
> [4] http://mail.kuehlbox.de/parse.php?redirect=<a href=
> _______________________________________________
> 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

I have a fully running GPT ZFS RaidZ setup using what was at the time 8-HEAD


I cant remember the exact steps I took, but one thing I have different 
is I have a root filesystem within my zpool


[paul@demophon /usr/home/paul]$ gpart show
=>       34  976773101  ada1  GPT  (466G)
         34        256     1  freebsd-boot  (128K)
        290    8388608     2  freebsd-swap  (4.0G)
    8388898  147912557     3  freebsd-zfs  (71G)
  156301455  820471680        - free -  (391G)

=>       34  488394988  ada2  GPT  (233G)
         34        256     1  freebsd-boot  (128K)
        290    8388608     2  freebsd-swap  (4.0G)
    8388898  147912557     3  freebsd-zfs  (71G)
  156301455  332093567        - free -  (158G)

=>       34  156301421  ada3  GPT  (75G)
         34        256     1  freebsd-boot  (128K)
        290    8388608     2  freebsd-swap  (4.0G)
    8388898  147912557     3  freebsd-zfs  (71G)


[paul@demophon /usr/home/paul]$ zpool status
  pool: zboot
 state: ONLINE
 scrub: none requested
config:

        NAME        STATE     READ WRITE CKSUM
        zboot       ONLINE       0     0     0
          ada1p3    ONLINE       0     0     0
          ada2p3    ONLINE       0     0     0
          ada3p3    ONLINE       0     0     0

errors: No known data errors


[paul@demophon /usr/home/paul]$ zfs list
NAME           USED  AVAIL  REFER  MOUNTPOINT
zboot         33.5G   175G    18K  none
zboot/root    12.4G   175G  12.2G  none
zboot/tmp     82.9M   175G  82.6M  none
zboot/usr     20.8G   175G  16.5G  none
zboot/var      216M   175G   123M  none


Im also using fstabs to mount my ZFS filesystems

[paul@demophon /usr/home/paul]$ more /etc/fstab
# Device        Mountpoint      FStype          Options         Dump    
Pass#
zboot/root      /               zfs             rw              0       0
zboot/usr       /usr            zfs             rw              0       0
zboot/var       /var            zfs             rw              0       0
zboot/tmp       /tmp            zfs             rw,noatime      0       0
proc            /proc           procfs          rw              0       0


I remember speak to someone a while back, and I *think* we came to the 
conclusion that using the zpool as your root will not work correctly and 
you should really create a root filesystem inside the zpool

Lets me know how this works out for you

Paul


-----------------------------------------------------------------------------------
Fletcher Moorland Limited is a company registered in England and Wales. 
Registration number: 2984467. 
Registered office: Elenora Street, Stoke on Trent, Staffordshire, ST4 1QG. 
VAT Registration number: 478730606 
Telephone: 01782 411021 | Fax: 01782 744470 | http://www.fletchermoorland.co.uk 

From admin at lissyara.su  Mon Sep  7 16:39:43 2009
From: admin at lissyara.su (Alex Keda)
Date: Mon Sep  7 16:39:49 2009
Subject: Fatal trap 12: page fault while in kernel mode
In-Reply-To: <1252340419.55883.26.camel@buffy.york.ac.uk>
References: <4AA384EC.3060003@lissyara.su>	<1252332612.55883.10.camel@buffy.york.ac.uk>	<4AA5286D.7040400@lissyara.su>
	<1252340419.55883.26.camel@buffy.york.ac.uk>
Message-ID: <4AA5374C.1090509@lissyara.su>

Gavin Atkinson ?????:
> On Mon, 2009-09-07 at 19:36 +0400, Alex Keda wrote:
>> Gavin Atkinson ?????:
>>> On Sun, 2009-09-06 at 13:46 +0400, Alex Keda wrote:
>>>> hi!
>>>> I have fatal trap with today (and yesterday) current.
>>>> Machine boot, I see:
>>>> Timecounters tick every 1.000 msec
>>>> then, it freese ~30 seconds and go to kernel debugger - fatal trap 12
>>>> stopped at _mtx_lock_spin_failed+0x2f: movl 0x78(%r12),%r8d
>>> At the debugger prompt, can you give the "bt" command, and show us what
>>> the output is please?
>> It:
>>  >> stopped at _mtx_lock_spin_failed+0x2f: movl 0x78(%r12),%r8d
>> from bt, last string.
>> or need all output?
> 
> All output, please.
it boot OK without options if_bwi_load="YES" in /boot/loader.conf

FreeBSD HP.lissyara.su 9.0-CURRENT FreeBSD 9.0-CURRENT #0 r196869: Sat 
Sep  5 23:27:07 MSD 2009 
lissyara@HP.lissyara.su:/usr/obj/usr/src/sys/GENERIC  amd64







> 
> Gavin
> _______________________________________________
> 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 nakaji at jp.freebsd.org  Mon Sep  7 17:21:50 2009
From: nakaji at jp.freebsd.org (NAKAJI Hiroyuki)
Date: Mon Sep  7 17:21:57 2009
Subject: ELF interpreter /libexec/ld-elf.so.1 not found
In-Reply-To: <20090829182437.GV37252@cicely7.cicely.de> (Bernd Walter's
	message of "Sat, 29 Aug 2009 20:24:37 +0200")
References: <20090829182437.GV37252@cicely7.cicely.de>
Message-ID: <86ljkqk6vw.fsf@ra333.heimat.gr.jp>

I hit the same error on RELENG_7/amd64 with another 32bit binary.
Some new feature MFCed?

>>>>> In <20090829182437.GV37252@cicely7.cicely.de> 
>>>>>	Bernd Walter <ticso@cicely7.cicely.de> wrote:
> I've recently updated one of my amd64 machines.
> Now I notice that (at least some) 32bit binaries won't run anymore.
-- 
NAKAJI Hiroyuki
From ticso at cicely7.cicely.de  Mon Sep  7 17:31:46 2009
From: ticso at cicely7.cicely.de (Bernd Walter)
Date: Mon Sep  7 17:32:24 2009
Subject: ELF interpreter /libexec/ld-elf.so.1 not found
In-Reply-To: <86ljkqk6vw.fsf@ra333.heimat.gr.jp>
References: <20090829182437.GV37252@cicely7.cicely.de>
	<86ljkqk6vw.fsf@ra333.heimat.gr.jp>
Message-ID: <20090907173139.GG15218@cicely7.cicely.de>

On Tue, Sep 08, 2009 at 02:21:39AM +0900, NAKAJI Hiroyuki wrote:
> I hit the same error on RELENG_7/amd64 with another 32bit binary.
> Some new feature MFCed?

Bjoern A. Zeeb send me a patch, which at least worked with my binary.
Don't know if it was commmited.

> >>>>> In <20090829182437.GV37252@cicely7.cicely.de> 
> >>>>>	Bernd Walter <ticso@cicely7.cicely.de> wrote:
> > I've recently updated one of my amd64 machines.
> > Now I notice that (at least some) 32bit binaries won't run anymore.

-- 
B.Walter <bernd@bwct.de> http://www.bwct.de
Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm.
From olivier at gid0.org  Mon Sep  7 17:48:32 2009
From: olivier at gid0.org (Olivier Smedts)
Date: Mon Sep  7 17:48:39 2009
Subject: [Call For Testing] VirtualBox for FreeBSD! take 6
In-Reply-To: <50e4b96fb035ba5eaf5e30fbf12bf9f2.squirrel@webmail.itac.at>
References: <20090611194557.GC98175@bsdcrew.de>
	<E1MkFAi-0005OD-K0@kabab.cs.huji.ac.il>
	<991123400909060811u9bea4d9rdbf453dfaae7c185@mail.gmail.com>
	<20090906162544.GA39448@bsdcrew.de>
	<E1MkWyt-000Eoi-1c@kabab.cs.huji.ac.il>
	<50e4b96fb035ba5eaf5e30fbf12bf9f2.squirrel@webmail.itac.at>
Message-ID: <367b2c980909071048j79b28babwcc9d59488d1de3ef@mail.gmail.com>

2009/9/7 Bernhard Fr?hlich <decke@bluelife.at>:
> On Mon, September 7, 2009 7:41 am, Danny Braniss wrote:
>>
>> [...]
>>> > > >
>>> > > ok, so some time has passed, but virtualbox-2.2.51r20457.tar.gz is
>>> no
>>> > > longer available, there is a
>>> > > ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/distfiles/virtualbox-2.2.51r20457.tar.bz2
>>> > > then again in ports/emulatores/virtualbox the version is
>>> 3.0.51r22226,
>>> > >
>>> > > can someone please explain?
>>
>> hi, the above was my question, which was totally ignored, not nice.
>> I will try and refrase it:
>> the call for testing is for a version (2.2.51r20457) which is not
>> available, while
>> the ports is 3.0.51r22226, so while I managed to compile it, it complains
>> that COM
>> is not running, all this under 8BETA-3, both under 32 and 64 bit.
>
> I'll try to be nice but it is still unclear to me what you want. The file
> is available on all 4 master sites that are listed in the ports Makefile.
>
> The virtualbox port is still in heavy development so it is strongly
> recommended that you use the latest version that is in the ports. If that
> also does not work you could give our svn version a try but be careful
> with it because it can break in strange ways or destroy your virtual
> machines.
>
> svn co
> http://svn.bluelife.at/projects/packages/blueports/emulators/virtualbox/

Wow... the SVN version works great for me with VT extensions ! I just
tried a 64 bits 2 processors guest :)

Thanks !

>
> --
> Bernhard Fr?hlich
> http://www.bluelife.at/
>
> _______________________________________________
> freebsd-ports@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-ports
> To unsubscribe, send any mail to "freebsd-ports-unsubscribe@freebsd.org"
>



-- 
Olivier Smedts                                                 _
                                        ASCII ribbon campaign ( )
e-mail: olivier@gid0.org        - against HTML email & vCards  X
www: http://www.gid0.org    - against proprietary attachments / \

  "Il y a seulement 10 sortes de gens dans le monde :
  ceux qui comprennent le binaire,
  et ceux qui ne le comprennent pas."
From bzeeb-lists at lists.zabbadoz.net  Mon Sep  7 18:05:09 2009
From: bzeeb-lists at lists.zabbadoz.net (Bjoern A. Zeeb)
Date: Mon Sep  7 18:05:21 2009
Subject: ELF interpreter /libexec/ld-elf.so.1 not found
In-Reply-To: <20090907173139.GG15218@cicely7.cicely.de>
References: <20090829182437.GV37252@cicely7.cicely.de>
	<86ljkqk6vw.fsf@ra333.heimat.gr.jp>
	<20090907173139.GG15218@cicely7.cicely.de>
Message-ID: <20090907175855.W68375@maildrop.int.zabbadoz.net>

On Mon, 7 Sep 2009, Bernd Walter wrote:

Hi,

> On Tue, Sep 08, 2009 at 02:21:39AM +0900, NAKAJI Hiroyuki wrote:
>> I hit the same error on RELENG_7/amd64 with another 32bit binary.
>> Some new feature MFCed?
>
> Bjoern A. Zeeb send me a patch, which at least worked with my binary.
> Don't know if it was commmited.

It was comitted to HEAD, MFCed to stable/8 a few days ago and MFCed
to stable/7 earlier today.

/bz

-- 
Bjoern A. Zeeb           What was I talking about and who are you again?
From pluknet at gmail.com  Mon Sep  7 18:15:55 2009
From: pluknet at gmail.com (pluknet)
Date: Mon Sep  7 18:16:01 2009
Subject: acquiring duplicate lock of same type: "ftlk"
In-Reply-To: <a31046fc0908270158l63b103a7v6c9fd1b7be54d3ed@mail.gmail.com>
References: <a31046fc0908270158l63b103a7v6c9fd1b7be54d3ed@mail.gmail.com>
Message-ID: <a31046fc0909071115td2d5309na5738a44402feaa9@mail.gmail.com>

2009/8/27 pluknet <pluknet@gmail.com>:
> Hi.
>
> Got it on FreeBSD 9.0-CURRENT while been running in Xorg, don't know
> where exactly.
>
> Acquiring duplicate lock of same type: "ftlk"
> ?1st ftlk @ /usr/src/sys/modules/linux/../../compat/linux/linux_futex.c:177
> ?2nd ftlk @ /usr/src/sys/modules/linux/../../compat/linux/linux_futex.c:203
> KDB: stack backtrace:
> db_trace_self_wrapper(c07fd8ea,ea393b58,c060a145,c05fac1b,c08007b2,...)
> at db_trace_self_wrapper+0x26
> kdb_backtrace(c05fac1b,c08007b2,c0b49757,c58ead20,ea393bb4,...) at
> kdb_backtrace+0x29
> _witness_debugger(c08007b2,c0b49793,c0b49757,cb,0,...) at _witness_debugger+0x25
> witness_checkorder(c9bba780,9,c0b49757,cb,0,...) at witness_checkorder+0x469
> _sx_xlock(c9bba780,0,c0b49757,cb,0,...) at _sx_xlock+0x85
> futex_get0(c0609f8c,c09cc7a8,c9ac7764,c09cc7a8,c084df3c,...) at futex_get0+0x116
> linux_sys_futex(c9ac76c0,ea393cf8,ea393d18,ea393d1c,c0b4cf40,...) at
> linux_sys_futex+0x6f
> syscall(ea393d38) at syscall+0x2b4
> Xint0x80_syscall() at Xint0x80_syscall+0x20
> --- syscall (240, Linux ELF, linux_sys_futex), eip = 0x28799533, esp =
> 0xbfbfc0cc, ebp = 0x4000001 ---
>
>

This time seeing this LOR again but with another one just before.
lock order reversal:
 1st 0xc75365b8 pseudofs (pseudofs) @ /usr/src/sys/kern/vfs_lookup.c:497
 2nd 0xc088ea3c allproc (allproc) @ /usr/src/sys/kern/kern_proc.c:292
KDB: stack backtrace:
db_trace_self_wrapper(c07fd8ea,e82148e4,c060a145,c05fac1b,c08008bf,...)
at db_trace_self_wrapper+0x26
kdb_backtrace(c05fac1b,c08008bf,c58eabe8,c58e30d0,e8214940,...) at
kdb_backtrace+0x29
_witness_debugger(c08008bf,c088ea3c,c07f981d,c58e30d0,c07f96f0,...) at
_witness_debugger+0x25
witness_checkorder(c088ea3c,1,c07f96f0,124,0,...) at witness_checkorder+0x839
_sx_slock(c088ea3c,0,c07f96f0,124,c73c4980,...) at _sx_slock+0x85
pfind(514,c72ba1a0,4,c07f8d78,c5fe1b40,...) at pfind+0x2f
pfs_visible(0,0,c07f042d,7c,c7536560,...) at pfs_visible+0x3a
pfs_lookup(e8214a40,c082715e,c7536560,c7536560,e8214bf8,...) at pfs_lookup+0x3dd
VOP_CACHEDLOOKUP_APV(c0843960,e8214a40,e8214bf8,e8214be4,c73c4e80,...)
at VOP_CACHEDLOOKUP_APV+0xc5
vfs_cache_lookup(e8214acc,c08087d0,c0875a00,200000,e8214bcc,...) at
vfs_cache_lookup+0xd6
VOP_LOOKUP_APV(c0843960,e8214acc,e8214bf8,1f1,e8214be4,...) at
VOP_LOOKUP_APV+0xe5
lookup(e8214bcc,c5fd1800,0,c5,c5ef77f8,...) at lookup+0x63b
namei(e8214bcc,c5c1500d,3f3,e8214c20,c5c1500d,...) at namei+0x57f
kern_alternate_path(c5fe1b40,c0b4921c,2879f478,0,e8214c74,...) at kern_alternate
_path+0x1cd
linux_emul_convpath(c5fe1b40,2879f478,0,e8214c74,0,...) at
linux_emul_convpath+0x3c
linux_open(c5fe1b40,e8214cf8,e8214d18,e8214d1c,c0b4b58c,...) at linux_open+0x41
syscall(e8214d38) at syscall+0x2b4
Xint0x80_syscall() at Xint0x80_syscall+0x20
--- syscall (5, Linux ELF, linux_open), eip = 0x2889115e, esp =
0xbfbfbd1c, ebp = 0xbfbfbd6c ---
acquiring duplicate lock of same type: "ftlk"
[...]

I'm running head from 08/26.
There were recent changes in pseudofs. Could it be fixed?
Looks like it's connected to running firefox3 with linprocfs (for adobe flash).

-- 
wbr,
pluknet
From odhiambo at gmail.com  Mon Sep  7 19:18:23 2009
From: odhiambo at gmail.com (Odhiambo Washington)
Date: Mon Sep  7 19:18:42 2009
Subject: [Call For Testing] VirtualBox for FreeBSD! take 6
In-Reply-To: <alpine.BSF.2.00.0909071241570.7031@qvzrafvba.5c.ybpny>
References: <20090611194557.GC98175@bsdcrew.de>
	<E1MkFAi-0005OD-K0@kabab.cs.huji.ac.il> 
	<991123400909060811u9bea4d9rdbf453dfaae7c185@mail.gmail.com> 
	<20090906162544.GA39448@bsdcrew.de>
	<991123400909061150h56dc6e07uf8d8e721f6c923bf@mail.gmail.com> 
	<alpine.BSF.2.00.0909071241570.7031@qvzrafvba.5c.ybpny>
Message-ID: <991123400909071218s2af7a76ybcac8702d697362f@mail.gmail.com>

On Mon, Sep 7, 2009 at 7:45 PM, CmdLnKid <cmdlnkid@gmail.com> wrote:

> On Sun, 6 Sep 2009 14:50 -0000, odhiambo wrote:
>
>  On Sun, Sep 6, 2009 at 7:25 PM, Martin Wilke <miwi@freebsd.org> wrote:
>>
>>  -----BEGIN PGP SIGNED MESSAGE-----
>>> Hash: SHA1
>>>
>>> On Sun, Sep 06, 2009 at 06:11:48PM +0300, Odhiambo Washington wrote:
>>>
>>>> On Sun, Sep 6, 2009 at 1:40 PM, Danny Braniss <danny@cs.huji.ac.il>
>>>>
>>> wrote:
>>>
>>>>
>>>>  -----BEGIN PGP SIGNED MESSAGE-----
>>>>>> Hash: SHA1
>>>>>>
>>>>>> Huhu,
>>>>>>
>>>>>> Yes we life and that's good :-).
>>>>>> Changes:
>>>>>>
>>>>>>  - Fix build error when compiling in debug mode on FreeBSD HEAD
>>>>>>  - SemEvent?-r0drv/FreeBSD: Don't use tvtohz for an infinite
>>>>>>
>>>>> timeout.
>>>
>>>>   - Some FreeBSD relate typos
>>>>>>  - Enable shared OpenGL service. Completely untested due to lack of
>>>>>>    appropriate hardware but it compiles at least
>>>>>>  - Add support for shared clipboards. Requires libXt
>>>>>>  - FreeBSD: Implement preemption API for guest SMP and enable
>>>>>>    it (slightly tested). Add neccessary RTMP* methods in userspace
>>>>>>    for the frontends to detect the number of CPUs
>>>>>>  - Runtime/semevent-r0drv-freebsd: Use a sleeping mutex
>>>>>>    instead of a spinlock to fix the problems users are seeing
>>>>>>    (assertions with debugging enabled) while still being able
>>>>>>    to run on 100Hz hosts. No problems detected so far and Solaris
>>>>>>    doesn't use a spin mutex in this code too so it shouldn't do
>>>>>>    any harm (keeping fingers crossed)space for the frontends to
>>>>>>    detect the number of CPUs
>>>>>>  - Add support for curl
>>>>>>  - Add VBoxSharedClipboard
>>>>>>
>>>>>> Ports Changes;
>>>>>>  - Force guestadditions version to 2.2.4
>>>>>>  - Removed Qt3 include replacements (already upstream)
>>>>>>  - Removed cosmetic X11 include path patch
>>>>>>
>>>>>> Please make SURE, your world and kernel is in sync and you've read
>>>>>> the pkg-messages. Also please unload the kernel module before
>>>>>> you update the port ;-).
>>>>>>
>>>>>> Many thx to all Vbox Devs, All supporters, my nice team! :-)
>>>>>>
>>>>>>   http://people.freebsd.org/~miwi/vbox/virtualbox_6.tgz<http://people.freebsd.org/%7Emiwi/vbox/virtualbox_6.tgz>
>>>>>> <http://people.freebsd.org/%7Emiwi/vbox/virtualbox_6.tgz>
>>>>>>
>>>>> <http://people.freebsd.org/%7Emiwi/vbox/virtualbox_6.tgz>
>>>
>>>>
>>>>>>  Happy Testing!
>>>>>>
>>>>>>  ok, so some time has passed, but virtualbox-2.2.51r20457.tar.gz is no
>>>>> longer available, there is a
>>>>>
>>>>>
>>> ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/distfiles/virtualbox-2.2.51r20457.tar.bz2
>>>
>>>> then again in ports/emulatores/virtualbox the version is 3.0.51r22226,
>>>>>
>>>>> can someone please explain?
>>>>>
>>>>>
>>>>>
>>>>
>>>> And on my FreeBSD 7.2-STABLE, compiling virtualbox fails as follows:
>>>>
>>>>
>>>>
>>>> kBuild: Linking VBoxREM64
>>>> kBuild: Installing VBoxREM64 =>
>>>>
>>>> /usr/ports/emulators/virtualbox/work/virtualbox-3.0.51r22226/out/freebsd.x86/release/bin/VBox
>>>
>>>> REM64.so
>>>> kmk[2]: Leaving directory
>>>> `/usr/ports/emulators/virtualbox/work/virtualbox-3.0.51r22226'
>>>> kmk[1]: Leaving directory
>>>> `/usr/ports/emulators/virtualbox/work/virtualbox-3.0.51r22226'
>>>> kBuild: Pass - Programs
>>>> kmk[1]: Entering directory
>>>> `/usr/ports/emulators/virtualbox/work/virtualbox-3.0.51r22226'
>>>> kmk[2]: Entering directory
>>>> `/usr/ports/emulators/virtualbox/work/virtualbox-3.0.51r22226'
>>>> kBuild: Compiling tstAPI -
>>>>
>>>> /usr/ports/emulators/virtualbox/work/virtualbox-3.0.51r22226/src/VBox/Main/testcase/tstAPI.cpp
>>>
>>>> kBuild: Linking tstAPI
>>>> /usr/local/lib/libssl.so.5: undefined reference to `d2i_X509_EXTENSIONS'
>>>> /usr/local/lib/libssl.so.5: undefined reference to
>>>> `ENGINE_get_ssl_client_cert_function'
>>>> /usr/local/lib/libssl.so.5: undefined reference to `HMAC_CTX_set_flags'
>>>> /usr/local/lib/libssl.so.5: undefined reference to `i2d_X509_EXTENSIONS'
>>>> /usr/local/lib/libssl.so.5: undefined reference to
>>>> `ENGINE_load_ssl_client_cert'
>>>> /usr/local/lib/libssl.so.5: undefined reference to `pqueue_size'
>>>> /usr/local/lib/libssl.so.5: undefined reference to `EVP_idea_cbc'
>>>> kmk[2]: ***
>>>>
>>>> [/usr/ports/emulators/virtualbox/work/virtualbox-3.0.51r22226/out/freebsd.x86/release/obj/tstAPI/tstAPI]
>>>
>>>> Error 1
>>>> The failing command:
>>>> @g++               '-Wl,-rpath,/usr/local/lib/virtualbox'   -m32   -o
>>>> /usr/ports/emulators/virtualbox/work/virtualbox-3.0.51r
>>>> 22226/out/freebsd.x86/release/obj/tstAPI/tstAPI
>>>>
>>>> /usr/ports/emulators/virtualbox/work/virtualbox-3.0.51r22226/out/freebsd.x86/
>>>
>>>> release/obj/tstAPI/tstAPI.o   -L/usr/lib  -L/usr/X11R6/lib
>>>> -L/usr/local/lib
>>>> /usr/ports/emulators/virtualbox/work/virtualbo
>>>> x-3.0.51r22226/out/freebsd.x86/release/bin/VBoxRT.so
>>>> /usr/ports/emulators/virtualbox/work/virtualbox-3.0.51r22226/out/freeb
>>>> sd.x86/release/lib/VBoxCOM.a
>>>>
>>>> /usr/ports/emulators/virtualbox/work/virtualbox-3.0.51r22226/out/freebsd.x86/release/bin/VBoxX
>>>
>>>> PCOM.so
>>>> kmk[2]: Leaving directory
>>>> `/usr/ports/emulators/virtualbox/work/virtualbox-3.0.51r22226'
>>>> kmk[1]: *** [pass_binaries_this] Error 2
>>>> kmk[1]: Leaving directory
>>>> `/usr/ports/emulators/virtualbox/work/virtualbox-3.0.51r22226'
>>>> kmk: *** [pass_binaries_order] Error 2
>>>> *** Error code 2
>>>>
>>>> Stop in /usr/ports/emulators/virtualbox.
>>>>
>>>>
>>>> I hope someone can advise on what is needed.
>>>>
>>>>
>>> deinstall openssl from ports and try again :)
>>>
>>>
>>>  I remember we had this suggestion before, and either you (or someone
>> else)
>> was going to look into the use of openssl from the ports:-)
>> Looks like I will have to recompile most apps that have linked against
>> openssl, no?
>>
>>
> Just create a backup package of your openssl port with ( pkg_create -b )
> then uninstall the port, rebuild the port in question and ( pkg_add ) the
> openssl port again. This will at least get the port out of the way for you
> to complete the build and will let you determine further action.
>
>
It's not such a critical box. It's a testbed nyway so I did not bother
backing up anything since I will be able to fix any broken packages.
Let me see how it goes. So far so good.... the build process is running...



-- 
Best regards,
Odhiambo WASHINGTON,
Nairobi,KE
+254733744121/+254722743223
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
"If you have nothing good to say about someone, just shut up!."
              -- Lucky Dube
From h.schmalzbauer at omnilan.de  Mon Sep  7 20:21:48 2009
From: h.schmalzbauer at omnilan.de (Harald Schmalzbauer)
Date: Mon Sep  7 20:21:55 2009
Subject: Funding ODD support
In-Reply-To: <e71790db0909070732v51baf3a8i574107ab6387bfba@mail.gmail.com>
References: <4AA33DF9.6070803@omnilan.de>
	<e71790db0909070732v51baf3a8i574107ab6387bfba@mail.gmail.com>
Message-ID: <4AA56B59.1060702@omnilan.de>

Carlos A. M. dos Santos schrieb am 07.09.2009 16:32 (localtime):
> On Sun, Sep 6, 2009 at 1:43 AM, Harald
> Schmalzbauer<h.schmalzbauer@omnilan.de> wrote:
>> Hello,
>>
>> I'm looking for somebody who has time and knowledge to fix ODD support in
>> FreeBSD.
> [...]
> 
> I'm not sure if such work should be funded by a separate bounty or by
> the FreeBSD foundation. Anyway, I would happily donate some money for
> improvements on the CD/DVD writing support. I'd like to see either an
> improved version of burncd or some new tool provided by the base
> system.

I haven't done any "official application" because of my felt severity yet.
For a long term project the FreeBSD foundation was the better way, I think.
But I hoped somebody would be able to fix it before 8.0-RELEASE, which 
is not too far away.
I just got one more reply from another fellow willing to donate for 
fixing ODD support, but no reply from any coder yet...

All in all, not much response.
It seems the ones using ODDs are considering the problems as quiet 
severe, but it also seems there are not many fellows missing working ODD 
support.
Is the media itself really outdated? I haven't done any blu-ray 
experiments under FreeBSD yet, but I can't imagine things are working 
better with that media.

So for now the pot is about 500 bucks.
Anyone to pick up?

Regards,

-Harry

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 196 bytes
Desc: OpenPGP digital signature
Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20090907/17c91810/signature.pgp
From cmdlnkid at gmail.com  Mon Sep  7 17:08:44 2009
From: cmdlnkid at gmail.com (CmdLnKid)
Date: Mon Sep  7 20:48:32 2009
Subject: [Call For Testing] VirtualBox for FreeBSD! take 6
In-Reply-To: <991123400909061150h56dc6e07uf8d8e721f6c923bf@mail.gmail.com>
References: <20090611194557.GC98175@bsdcrew.de>
	<E1MkFAi-0005OD-K0@kabab.cs.huji.ac.il>
	<991123400909060811u9bea4d9rdbf453dfaae7c185@mail.gmail.com>
	<20090906162544.GA39448@bsdcrew.de>
	<991123400909061150h56dc6e07uf8d8e721f6c923bf@mail.gmail.com>
Message-ID: <alpine.BSF.2.00.0909071241570.7031@qvzrafvba.5c.ybpny>

On Sun, 6 Sep 2009 14:50 -0000, odhiambo wrote:

> On Sun, Sep 6, 2009 at 7:25 PM, Martin Wilke <miwi@freebsd.org> wrote:
>
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> On Sun, Sep 06, 2009 at 06:11:48PM +0300, Odhiambo Washington wrote:
>>> On Sun, Sep 6, 2009 at 1:40 PM, Danny Braniss <danny@cs.huji.ac.il>
>> wrote:
>>>
>>>>> -----BEGIN PGP SIGNED MESSAGE-----
>>>>> Hash: SHA1
>>>>>
>>>>> Huhu,
>>>>>
>>>>> Yes we life and that's good :-).
>>>>> Changes:
>>>>>
>>>>>   - Fix build error when compiling in debug mode on FreeBSD HEAD
>>>>>   - SemEvent?-r0drv/FreeBSD: Don't use tvtohz for an infinite
>> timeout.
>>>>>   - Some FreeBSD relate typos
>>>>>   - Enable shared OpenGL service. Completely untested due to lack of
>>>>>     appropriate hardware but it compiles at least
>>>>>   - Add support for shared clipboards. Requires libXt
>>>>>   - FreeBSD: Implement preemption API for guest SMP and enable
>>>>>     it (slightly tested). Add neccessary RTMP* methods in userspace
>>>>>     for the frontends to detect the number of CPUs
>>>>>   - Runtime/semevent-r0drv-freebsd: Use a sleeping mutex
>>>>>     instead of a spinlock to fix the problems users are seeing
>>>>>     (assertions with debugging enabled) while still being able
>>>>>     to run on 100Hz hosts. No problems detected so far and Solaris
>>>>>     doesn't use a spin mutex in this code too so it shouldn't do
>>>>>     any harm (keeping fingers crossed)space for the frontends to
>>>>>     detect the number of CPUs
>>>>>   - Add support for curl
>>>>>   - Add VBoxSharedClipboard
>>>>>
>>>>> Ports Changes;
>>>>>   - Force guestadditions version to 2.2.4
>>>>>   - Removed Qt3 include replacements (already upstream)
>>>>>   - Removed cosmetic X11 include path patch
>>>>>
>>>>> Please make SURE, your world and kernel is in sync and you've read
>>>>> the pkg-messages. Also please unload the kernel module before
>>>>> you update the port ;-).
>>>>>
>>>>> Many thx to all Vbox Devs, All supporters, my nice team! :-)
>>>>>
>>>>>    http://people.freebsd.org/~miwi/vbox/virtualbox_6.tgz<http://people.freebsd.org/%7Emiwi/vbox/virtualbox_6.tgz>
>> <http://people.freebsd.org/%7Emiwi/vbox/virtualbox_6.tgz>
>>>>>
>>>>>  Happy Testing!
>>>>>
>>>> ok, so some time has passed, but virtualbox-2.2.51r20457.tar.gz is no
>>>> longer available, there is a
>>>>
>> ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/distfiles/virtualbox-2.2.51r20457.tar.bz2
>>>> then again in ports/emulatores/virtualbox the version is 3.0.51r22226,
>>>>
>>>> can someone please explain?
>>>>
>>>>
>>>
>>>
>>> And on my FreeBSD 7.2-STABLE, compiling virtualbox fails as follows:
>>>
>>>
>>>
>>> kBuild: Linking VBoxREM64
>>> kBuild: Installing VBoxREM64 =>
>>>
>> /usr/ports/emulators/virtualbox/work/virtualbox-3.0.51r22226/out/freebsd.x86/release/bin/VBox
>>> REM64.so
>>> kmk[2]: Leaving directory
>>> `/usr/ports/emulators/virtualbox/work/virtualbox-3.0.51r22226'
>>> kmk[1]: Leaving directory
>>> `/usr/ports/emulators/virtualbox/work/virtualbox-3.0.51r22226'
>>> kBuild: Pass - Programs
>>> kmk[1]: Entering directory
>>> `/usr/ports/emulators/virtualbox/work/virtualbox-3.0.51r22226'
>>> kmk[2]: Entering directory
>>> `/usr/ports/emulators/virtualbox/work/virtualbox-3.0.51r22226'
>>> kBuild: Compiling tstAPI -
>>>
>> /usr/ports/emulators/virtualbox/work/virtualbox-3.0.51r22226/src/VBox/Main/testcase/tstAPI.cpp
>>> kBuild: Linking tstAPI
>>> /usr/local/lib/libssl.so.5: undefined reference to `d2i_X509_EXTENSIONS'
>>> /usr/local/lib/libssl.so.5: undefined reference to
>>> `ENGINE_get_ssl_client_cert_function'
>>> /usr/local/lib/libssl.so.5: undefined reference to `HMAC_CTX_set_flags'
>>> /usr/local/lib/libssl.so.5: undefined reference to `i2d_X509_EXTENSIONS'
>>> /usr/local/lib/libssl.so.5: undefined reference to
>>> `ENGINE_load_ssl_client_cert'
>>> /usr/local/lib/libssl.so.5: undefined reference to `pqueue_size'
>>> /usr/local/lib/libssl.so.5: undefined reference to `EVP_idea_cbc'
>>> kmk[2]: ***
>>>
>> [/usr/ports/emulators/virtualbox/work/virtualbox-3.0.51r22226/out/freebsd.x86/release/obj/tstAPI/tstAPI]
>>> Error 1
>>> The failing command:
>>> @g++               '-Wl,-rpath,/usr/local/lib/virtualbox'   -m32   -o
>>> /usr/ports/emulators/virtualbox/work/virtualbox-3.0.51r
>>> 22226/out/freebsd.x86/release/obj/tstAPI/tstAPI
>>>
>> /usr/ports/emulators/virtualbox/work/virtualbox-3.0.51r22226/out/freebsd.x86/
>>> release/obj/tstAPI/tstAPI.o   -L/usr/lib  -L/usr/X11R6/lib
>>> -L/usr/local/lib
>>> /usr/ports/emulators/virtualbox/work/virtualbo
>>> x-3.0.51r22226/out/freebsd.x86/release/bin/VBoxRT.so
>>> /usr/ports/emulators/virtualbox/work/virtualbox-3.0.51r22226/out/freeb
>>> sd.x86/release/lib/VBoxCOM.a
>>>
>> /usr/ports/emulators/virtualbox/work/virtualbox-3.0.51r22226/out/freebsd.x86/release/bin/VBoxX
>>> PCOM.so
>>> kmk[2]: Leaving directory
>>> `/usr/ports/emulators/virtualbox/work/virtualbox-3.0.51r22226'
>>> kmk[1]: *** [pass_binaries_this] Error 2
>>> kmk[1]: Leaving directory
>>> `/usr/ports/emulators/virtualbox/work/virtualbox-3.0.51r22226'
>>> kmk: *** [pass_binaries_order] Error 2
>>> *** Error code 2
>>>
>>> Stop in /usr/ports/emulators/virtualbox.
>>>
>>>
>>> I hope someone can advise on what is needed.
>>>
>>
>> deinstall openssl from ports and try again :)
>>
>>
> I remember we had this suggestion before, and either you (or someone else)
> was going to look into the use of openssl from the ports:-)
> Looks like I will have to recompile most apps that have linked against
> openssl, no?
>

Just create a backup package of your openssl port with ( pkg_create -b ) 
then uninstall the port, rebuild the port in question and ( pkg_add ) 
the openssl port again. This will at least get the port out of the way 
for you to complete the build and will let you determine further action.

Best regards.

-- 

  - (2^(N-1))
From nox at jelal.kn-bremen.de  Mon Sep  7 21:06:19 2009
From: nox at jelal.kn-bremen.de (Juergen Lock)
Date: Mon Sep  7 21:06:27 2009
Subject: FreeBSD timing issues and qemu (was: Re: [Qemu-devel] Re: Breakage
 with local APIC routing)
In-Reply-To: <20090901201248.GA60123@triton8.kn-bremen.de>
References: <4A93AFF9.1060201@web.de>
	<52d4a3890908250316l4de68725xa9d780e7d5b37205@mail.gmail.com>
	<52d4a3890908250321u746e5757u136030bcbc19208d@mail.gmail.com>
	<4A93BF0C.8040601@web.de>
	<20090826221001.GA1070@triton8.kn-bremen.de>
	<4A96C8D9.6070804@web.de>
	<20090829211848.GA59305@triton8.kn-bremen.de>
	<4A9B800F.1040209@web.de>
	<20090831212723.GA32448@triton8.kn-bremen.de>
	<20090901201248.GA60123@triton8.kn-bremen.de>
Message-ID: <20090907205955.GA91866@triton8.kn-bremen.de>

[I'm copying freebsd-current@FreeBSD.org because ppl there might know
more about this...]

 qemu on FreeBSD hosts used to be able to run a (FreeBSD at least) guest
with the same HZ as the host (like, 1000) with (mostly) proper timing
once, but no longer. :(  It seems there are two problems involved:

 a) use of apic seems to cause the clock irq rate to be doubled to 2 * HZ
(can anyone explain why?), i.e. a FreeBSD 7 guest on a FreeBSD 7 host
only gets proper timing after setting hint.apic.0.disabled=1 via the
loader.  (as can be verified by `vmstat -i' and `time sleep 2' in an
installed guest or via the fixit->cdrom/dvd shell on a FreeBSD livefs
or dvd1 iso.)

 b) qemu running on FreeBSD 8 hosts (and most likely head) has the
additional problem of running its timers only at HZ/2 when using
setitimer(2) (called `-clock unix' in qemu), as seen below.  (as also
seen below, timer_settime(2) aka `-clock dynticks' in qemu behaves
even worse, but that is similarly true on FreeBSD 7 which is why
I removed the patch that enabled that from our qemu port(s) a few
days ago.)  And the only reason FreeBSD 8 guests are usually less
affected by these problems is they now reduce their HZ to 100 when
they detect being run in a VM.  (which makes sense for other reasons
as well, don't get me wrong...  but of course doesn't help when the
host is running with HZ=100 too.)

On Tue, Sep 01, 2009 at 10:12:48PM +0200, Juergen Lock wrote:
> On Mon, Aug 31, 2009 at 11:27:23PM +0200, Juergen Lock wrote:
> > On Mon, Aug 31, 2009 at 09:47:27AM +0200, Jan Kiszka wrote:
> > > Juergen Lock wrote:
> > > > On Thu, Aug 27, 2009 at 07:56:41PM +0200, Jan Kiszka wrote:
> > > >> Juergen Lock wrote:
> > > >>> On Tue, Aug 25, 2009 at 12:38:04PM +0200, Jan Kiszka wrote:
> > > >>>> Mohammed Gamal wrote:
> > > >>>>> On Tue, Aug 25, 2009 at 1:16 PM, Mohammed Gamal<m.gamal005@gmail.com> wrote:
> > > >>>>>> On Tue, Aug 25, 2009 at 12:33 PM, Jan Kiszka<jan.kiszka@web.de> wrote:
> > > >>>>>>> Mohammed Gamal wrote:
> > > >>>>>>>> qemu-system-x86_64 -hda /dev/null -cdrom <path_to_ubuntu_iso_image>
> > > >>>>>>>>
> > > >>>>>>> I only have kubuntu-9.04-alternate-amd64.iso at hand ATM, and with that
> > > >>>>>>> image I'm unable to reproduce. Will download and check standard ubuntu
> > > >>>>>>> later today.
> > > >>>>>>>
> > > >>>>>>>> I was using qemu-kvm, but I assume that using -no-kvm would be
> > > >>>>>>>> equivalent to using plain qemu, no?
> > > >>>>>>> Generally yes, but not necessarily (e.g. the BIOSes are different). So
> > > >>>>>>> it's better to check such issues also against "clean" qemu, specifically
> > > >>>>>>> as we are on qemu-devel here.
> > > >>>>>>>
> > > >>>>>>> Jan
> > > >>>>>>>
> > > >>>>>>>
> > > >>>>>> Just tested this now on a vanilla qemu, I am still able to reproduce
> > > >>>>>> the same issue.
> > > >>>>>>
> > > >>>>> This bug might be related to the same problem
> > > >>>>> https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/379000
> > > >>>> I think at least those issues should be solved with recent qemu and
> > > >>>> bioses. Note that this report refers to a fairly old qemu version
> > > >>>> (0.10.0-derived).
> > > >>> Btw I had reported the same symptom as in that ubuntu ticket for FreeBSD 8
> > > >>> hosts both with 0.10.6 and 0.11.0rc1 before:
> > > >>> 	http://lists.gnu.org/archive/html/qemu-devel/2009-08/msg00396.html
> > > >>> As mentioned in that post I was able to work around the issue by passig
> > > >>> the linux guest kernels `no_timer_check' after which they seemed to boot up
> > > >>> just fine, so I suspect in that case its not actually an apic routing
> > > >>> problem but just guest timer irqs arriving late/irregularly which cause
> > > >>> the guest kernel timer checks to time out and fail.
> > > >> Does this happen with git head and its corresponding bios, too? I cannot
> > > >> imagine that the FreeBSD platform is so irregularly generating timer
> > > >> events for qemu that Linux gets unhappy during this test loop (I think
> > > >> to remember it needs 3 out of 10 ticks or so to be satisfied).
> > > > 
> > > > Alright so I testwise updated the FreeBSD qemu-devel port to git head
> > > > (db3c9e08e0d6eaf83f9d7a2c87dc45af3ac8f4dd, update at
> > > > 	http://people.freebsd.org/~nox/qemu/qemu-devel-20090829.patch
> > > 
> > > You will have to help me isolating the reason as I don't have any BSD
> > > host. And running recent qemu/-kvm on Linux hosts does not trigger
> > > problems around booting ubuntu here.
> > 
> > Well I don't quite know where to start looking, of course I'd be
> > happy to test patches... :)
> 
> Ok I now found the #if 0 in vl.c:host_alarm_handler(), enabled it and got
> this with a FreeBSD 7.2 iso (which defaults to HZ=1000) and -clock dynticks:
> 
..and this was on a FreeBSD 8 host:

> timer: min=2555 us max=32004 us avg=5150 us avg_freq=194.149 Hz
> timer: min=2451 us max=7205 us avg=3012 us avg_freq=331.960 Hz
> timer: min=2855 us max=7994 us avg=3019 us avg_freq=331.191 Hz
> timer: min=2099 us max=20003 us avg=3057 us avg_freq=327.073 Hz
> timer: min=2143 us max=11897 us avg=3081 us avg_freq=324.527 Hz
> timer: min=2110 us max=80014 us avg=3165 us avg_freq=315.913 Hz
> timer: min=2088 us max=51999 us avg=3206 us avg_freq=311.873 Hz
> 
> and this with the same guest and -clock unix:
> 
> timer: min=1614 us max=7121 us avg=2009 us avg_freq=497.692 Hz
> timer: min=876 us max=11134 us avg=2016 us avg_freq=495.967 Hz
> timer: min=753 us max=9245 us avg=2014 us avg_freq=496.455 Hz
> timer: min=1798 us max=6211 us avg=2008 us avg_freq=497.941 Hz
> timer: min=1772 us max=6142 us avg=2008 us avg_freq=497.943 Hz
> timer: min=1767 us max=6157 us avg=2008 us avg_freq=497.942 Hz
> timer: min=14 us max=6139 us avg=2008 us avg_freq=497.939 Hz
> timer: min=736 us max=9969 us avg=2016 us avg_freq=495.962 Hz
> timer: min=176 us max=11427 us avg=2076 us avg_freq=481.631 Hz
> timer: min=229 us max=9827 us avg=2030 us avg_freq=492.546 Hz
> timer: min=430 us max=11082 us avg=2078 us avg_freq=481.166 Hz
> timer: min=226 us max=9871 us avg=2026 us avg_freq=493.517 Hz
> timer: min=605 us max=10829 us avg=2082 us avg_freq=480.243 Hz
> timer: min=57 us max=10976 us avg=2028 us avg_freq=493.031 Hz
> timer: min=398 us max=11036 us avg=2080 us avg_freq=480.704 Hz
> 
>  `vmstat -i' in the guest (available e.g. from the fixit->cdrom/dvd shell
> on a livefs or dvd1 iso) gives similar values as avg_freq above for the
> `cpu0: timer' irq rate.  (Btw, FreeBSD 8 reduces its HZ to 100 when
> running in a vm so the `vmstat -i' values will be a little lower if you
> try that as a guest.)
> 
>  And `vmstat -i' on the host (also running with HZ=1000) reports a
> rate of 1999 for each cpu's timer irq, so there are clearly quite a few
> irqs missing there...
> 
>  (Btw I'm wondering if the poor usb performance I reported a long time
> ago already could be related to this also...)

 And here is the same guest with -clock unix on a FreeBSD 7 host:
(same with and without apic, except of course that only without apic
timing in the guest is ok.)

timer: min=847 us max=6146 us avg=1005 us avg_freq=994.950 Hz
timer: min=866 us max=6130 us avg=1005 us avg_freq=994.960 Hz
timer: min=868 us max=6133 us avg=1005 us avg_freq=994.958 Hz
timer: min=287 us max=35199 us avg=1089 us avg_freq=918.216 Hz
timer: min=201 us max=13551 us avg=1029 us avg_freq=971.757 Hz
timer: min=792 us max=6211 us avg=1005 us avg_freq=994.961 Hz
timer: min=145 us max=6185 us avg=1007 us avg_freq=992.984 Hz
timer: min=852 us max=6152 us avg=1005 us avg_freq=994.961 Hz
timer: min=820 us max=6175 us avg=1005 us avg_freq=994.960 Hz
timer: min=654 us max=6242 us avg=1005 us avg_freq=994.966 Hz
timer: min=675 us max=6196 us avg=1005 us avg_freq=994.952 Hz
timer: min=829 us max=6162 us avg=1005 us avg_freq=994.960 Hz
timer: min=503 us max=6136 us avg=1005 us avg_freq=994.960 Hz
timer: min=859 us max=6138 us avg=1005 us avg_freq=994.960 Hz
timer: min=856 us max=6149 us avg=1005 us avg_freq=994.960 Hz
timer: min=832 us max=6164 us avg=1005 us avg_freq=994.961 Hz
timer: min=829 us max=6174 us avg=1005 us avg_freq=994.958 Hz
timer: min=826 us max=6173 us avg=1005 us avg_freq=994.960 Hz
timer: min=828 us max=6168 us avg=1005 us avg_freq=994.961 Hz
timer: min=841 us max=6160 us avg=1005 us avg_freq=994.960 Hz
timer: min=857 us max=6135 us avg=1005 us avg_freq=994.959 Hz
timer: min=857 us max=6139 us avg=1005 us avg_freq=994.959 Hz
timer: min=845 us max=6147 us avg=1005 us avg_freq=994.960 Hz
timer: min=854 us max=6143 us avg=1005 us avg_freq=994.960 Hz
timer: min=854 us max=6142 us avg=1005 us avg_freq=994.960 Hz
timer: min=857 us max=6142 us avg=1005 us avg_freq=994.960 Hz
timer: min=859 us max=6141 us avg=1005 us avg_freq=994.961 Hz
timer: min=849 us max=6141 us avg=1005 us avg_freq=994.962 Hz
timer: min=857 us max=6143 us avg=1005 us avg_freq=994.962 Hz
timer: min=864 us max=6138 us avg=1005 us avg_freq=994.958 Hz
timer: min=863 us max=6139 us avg=1005 us avg_freq=994.961 Hz
timer: min=869 us max=6136 us avg=1005 us avg_freq=994.960 Hz
timer: min=857 us max=6143 us avg=1005 us avg_freq=994.959 Hz
timer: min=865 us max=6133 us avg=1005 us avg_freq=994.960 Hz

 And the same guest/host with -clock dynticks:

timer: min=1657 us max=32164 us avg=6732 us avg_freq=148.534 Hz
timer: min=1675 us max=7158 us avg=2010 us avg_freq=497.480 Hz
timer: min=1773 us max=7200 us avg=2010 us avg_freq=497.480 Hz
timer: min=1798 us max=7148 us avg=2010 us avg_freq=497.480 Hz
timer: min=1851 us max=7144 us avg=2013 us avg_freq=496.739 Hz
timer: min=1821 us max=7136 us avg=2020 us avg_freq=495.017 Hz
timer: min=1823 us max=7173 us avg=2010 us avg_freq=497.480 Hz
timer: min=1825 us max=39002 us avg=2076 us avg_freq=481.664 Hz
timer: min=1851 us max=7145 us avg=2012 us avg_freq=496.985 Hz
timer: min=1855 us max=16998 us avg=2106 us avg_freq=474.803 Hz
timer: min=1855 us max=7138 us avg=2010 us avg_freq=497.480 Hz
timer: min=1858 us max=7136 us avg=2010 us avg_freq=497.480 Hz
timer: min=1856 us max=7138 us avg=2010 us avg_freq=497.480 Hz
timer: min=1855 us max=7138 us avg=2017 us avg_freq=495.754 Hz
timer: min=1818 us max=7143 us avg=2009 us avg_freq=497.728 Hz
timer: min=1851 us max=7141 us avg=2010 us avg_freq=497.480 Hz
timer: min=1859 us max=7140 us avg=2010 us avg_freq=497.480 Hz
timer: min=1851 us max=7138 us avg=2010 us avg_freq=497.480 Hz

 For people wanting to experiment, you can escape to the loader prompt
from the FreeBSD boot menu and then type:
	set hint.apic.0.disabled=1
and optionally:
	set kern.hz="1000"
and then:
	boot -v
(for verbose dmesg, otherwise `boot' without the -v.)

 Any enlightnig comments appreciated... :)
	Juergen
From nakaji at jp.freebsd.org  Mon Sep  7 23:40:48 2009
From: nakaji at jp.freebsd.org (NAKAJI Hiroyuki)
Date: Mon Sep  7 23:40:55 2009
Subject: ELF interpreter /libexec/ld-elf.so.1 not found
In-Reply-To: <20090907175855.W68375@maildrop.int.zabbadoz.net> (Bjoern
	A. Zeeb's message of "Mon, 7 Sep 2009 18:00:20 +0000 (UTC)")
References: <20090829182437.GV37252@cicely7.cicely.de>
	<86ljkqk6vw.fsf@ra333.heimat.gr.jp>
	<20090907173139.GG15218@cicely7.cicely.de>
	<20090907175855.W68375@maildrop.int.zabbadoz.net>
Message-ID: <86eiqijpd2.fsf@ra333.heimat.gr.jp>

>>>>> In <20090907175855.W68375@maildrop.int.zabbadoz.net> 
>>>>>	"Bjoern A. Zeeb" <bzeeb-lists@lists.zabbadoz.net> wrote:

> > On Tue, Sep 08, 2009 at 02:21:39AM +0900, NAKAJI Hiroyuki wrote:
> >> I hit the same error on RELENG_7/amd64 with another 32bit binary.
> >> Some new feature MFCed?
> >
> > Bjoern A. Zeeb send me a patch, which at least worked with my binary.
> > Don't know if it was commmited.

> It was comitted to HEAD, MFCed to stable/8 a few days ago and MFCed
> to stable/7 earlier today.

Thanks. Is it r196924?
http://lists.freebsd.org/pipermail/svn-src-stable-7/2009-September/001900.html
-- 
NAKAJI Hiroyuki
From rysto32 at gmail.com  Tue Sep  8 02:17:26 2009
From: rysto32 at gmail.com (Ryan Stone)
Date: Tue Sep  8 02:17:32 2009
Subject: FreeBSD timing issues and qemu (was: Re: [Qemu-devel] Re: 
	Breakage with local APIC routing)
In-Reply-To: <20090907205955.GA91866@triton8.kn-bremen.de>
References: <4A93AFF9.1060201@web.de>
	<52d4a3890908250321u746e5757u136030bcbc19208d@mail.gmail.com>
	<4A93BF0C.8040601@web.de> <20090826221001.GA1070@triton8.kn-bremen.de>
	<4A96C8D9.6070804@web.de>
	<20090829211848.GA59305@triton8.kn-bremen.de>
	<4A9B800F.1040209@web.de>
	<20090831212723.GA32448@triton8.kn-bremen.de>
	<20090901201248.GA60123@triton8.kn-bremen.de>
	<20090907205955.GA91866@triton8.kn-bremen.de>
Message-ID: <bc2d970909071917n12256d9ucee24327aec3d527@mail.gmail.com>

I'm not entirely clear on why it's done this way, but the timer is run at
twice hz for statistics-gathering purposes*.  CPU usage statistics gathering
is driven off of the timer interrupt.  Running the timer at twice hz may be
an attempt to eliminate clock-aliasing problems; if so, it's a poor way of
doing so.  In any case, seeing interrupts come in at twice hz is expected
behaviour.  This means that the guest will be requesting a timer interrupt
rate of twice the granularity that the host's scheduler can support; this
may be the cause of your other timing problems(although I have a hard time
imagining how).

This timer is twice hz behaviour has existed at least since FreeBSD 6.1, so
I can't explain why you see the new behaviour between 7 and 8.  You do have
hz set to 1000 on both the guest and host when running 7?

* Actually, from looking at the code the behaviour is dynamic.  If hz >=
1500, the timer interrupt rate is set to hz.  If 750 <= hz < 1500, the timer
interrupt rate is set to 2 * hz.  If hz < 750, the timer interrupt rate is
set to 4 * hz.
From bz at FreeBSD.org  Tue Sep  8 05:55:08 2009
From: bz at FreeBSD.org (Bjoern A. Zeeb)
Date: Tue Sep  8 05:55:15 2009
Subject: ELF interpreter /libexec/ld-elf.so.1 not found
In-Reply-To: <86eiqijpd2.fsf@ra333.heimat.gr.jp>
References: <20090829182437.GV37252@cicely7.cicely.de>
	<86ljkqk6vw.fsf@ra333.heimat.gr.jp>
	<20090907173139.GG15218@cicely7.cicely.de>
	<20090907175855.W68375@maildrop.int.zabbadoz.net>
	<86eiqijpd2.fsf@ra333.heimat.gr.jp>
Message-ID: <20090908055055.C68375@maildrop.int.zabbadoz.net>

On Tue, 8 Sep 2009, NAKAJI Hiroyuki wrote:

Good morning,

>>>>>> In <20090907175855.W68375@maildrop.int.zabbadoz.net>
>>>>>> 	"Bjoern A. Zeeb" <bzeeb-lists@lists.zabbadoz.net> wrote:
>
>>> On Tue, Sep 08, 2009 at 02:21:39AM +0900, NAKAJI Hiroyuki wrote:
>>>> I hit the same error on RELENG_7/amd64 with another 32bit binary.
>>>> Some new feature MFCed?
>>>
>>> Bjoern A. Zeeb send me a patch, which at least worked with my binary.
>>> Don't know if it was commmited.
>
>> It was comitted to HEAD, MFCed to stable/8 a few days ago and MFCed
>> to stable/7 earlier today.
>
> Thanks. Is it r196924?
> http://lists.freebsd.org/pipermail/svn-src-stable-7/2009-September/001900.html

Yes, exactly.

/bz

-- 
Bjoern A. Zeeb           What was I talking about and who are you again?
From jakub_lach at mailplus.pl  Tue Sep  8 07:26:51 2009
From: jakub_lach at mailplus.pl (Jakub Lach)
Date: Tue Sep  8 07:27:58 2009
Subject: Funding ODD support
In-Reply-To: <4AA56B59.1060702@omnilan.de>
References: <4AA33DF9.6070803@omnilan.de>
	<e71790db0909070732v51baf3a8i574107ab6387bfba@mail.gmail.com>
	<4AA56B59.1060702@omnilan.de>
Message-ID: <25341094.post@talk.nabble.com>




Harald Schmalzbauer-7 wrote:
> 
> Carlos A. M. dos Santos schrieb am 07.09.2009 16:32 (localtime):
>> On Sun, Sep 6, 2009 at 1:43 AM, Harald
>> Schmalzbauer<h.schmalzbauer@omnilan.de> wrote:
>>> Hello,
>>>
>>> I'm looking for somebody who has time and knowledge to fix ODD support
>>> in
>>> FreeBSD.
>> [...]
>> 
>> I'm not sure if such work should be funded by a separate bounty or by
>> the FreeBSD foundation. Anyway, I would happily donate some money for
>> improvements on the CD/DVD writing support. I'd like to see either an
>> improved version of burncd or some new tool provided by the base
>> system.
> 
> I haven't done any "official application" because of my felt severity yet.
> For a long term project the FreeBSD foundation was the better way, I
> think.
> But I hoped somebody would be able to fix it before 8.0-RELEASE, which 
> is not too far away.
> I just got one more reply from another fellow willing to donate for 
> fixing ODD support, but no reply from any coder yet...
> 
> All in all, not much response.
> It seems the ones using ODDs are considering the problems as quiet 
> severe, but it also seems there are not many fellows missing working ODD 
> support.
> Is the media itself really outdated? I haven't done any blu-ray 
> experiments under FreeBSD yet, but I can't imagine things are working 
> better with that media.
> 
> So for now the pot is about 500 bucks.
> Anyone to pick up?
> 
> Regards,
> 
> -Harry
> 
> 
>  
> 

Hello.

I think you should be more specific about your problems, 
for most people present ODD support is working.

For the record, I just rebooted with audio cd inserted, 
without problem. (some cam errors, I'm using ahci)

http://pastebin.com/m1359b95d

and ripped track from that cd.

http://pastebin.com/m187d2d17

-best regards, 
Jakub Lach

-- 
View this message in context: http://www.nabble.com/Funding-ODD-support-tp25314648p25341094.html
Sent from the freebsd-current mailing list archive at Nabble.com.

From kris at FreeBSD.org  Tue Sep  8 08:33:36 2009
From: kris at FreeBSD.org (Kris Kennaway)
Date: Tue Sep  8 08:33:43 2009
Subject: xorg running > 48h starts consuming CPU cycles with BETA3
In-Reply-To: <4AA15F66.9070907@omnilan.de>
References: <4AA0F8FE.6050908@omnilan.de>	<3a142e750909040834g2465d932t4b65ff02727761bf@mail.gmail.com>
	<4AA15F66.9070907@omnilan.de>
Message-ID: <4AA616E1.1020503@FreeBSD.org>

Harald Schmalzbauer wrote:
> Paul B. Mahol schrieb am 04.09.2009 17:34 (localtime):
>> On 9/4/09, Harald Schmalzbauer <h.schmalzbauer@omnilan.de> wrote:
>>> Hello,
>>>
>>> I have one problem with xorg running on BETA3.
>>> Repeatably, after more than 48hour uptime, my workstation showes
>>> increased load. The longer the uptime, the more cpu cycles xorg 
>>> consumes.
>>> It's absolutely application independent. After 3 or 4 days, almost one
>>> complete CPU is occupied by xorg, but I have no idea what xorg is doing.
>>> Is there any way to "look inside" xorg to see where the CPU cycles 
>>> vanish?

Apart from ktrace/gdb/etc, dunno.

>>> With uptimes shorter than 2 days I can't see xorg consuming any
>>> remarkable CPU cycles.
>>> Xorg is 1.6.1, compiled on BETA3:
>>> 1157 root          1  53    0   828M   234M select  1  40:04 15.38% Xorg
>>
>> What video driver Xorg is using?
> 
> nvidia (not nv)

Does it happen with nv?  If not, it's likely to be a driver issue.

Kris
From kostikbel at gmail.com  Tue Sep  8 09:11:20 2009
From: kostikbel at gmail.com (Kostik Belousov)
Date: Tue Sep  8 09:11:27 2009
Subject: acquiring duplicate lock of same type: "ftlk"
In-Reply-To: <a31046fc0909071115td2d5309na5738a44402feaa9@mail.gmail.com>
References: <a31046fc0908270158l63b103a7v6c9fd1b7be54d3ed@mail.gmail.com>
	<a31046fc0909071115td2d5309na5738a44402feaa9@mail.gmail.com>
Message-ID: <20090908091114.GH47688@deviant.kiev.zoral.com.ua>

On Mon, Sep 07, 2009 at 10:15:48PM +0400, pluknet wrote:
> 2009/8/27 pluknet <pluknet@gmail.com>:
> > Hi.
> >
> > Got it on FreeBSD 9.0-CURRENT while been running in Xorg, don't know
> > where exactly.
> >
> > Acquiring duplicate lock of same type: "ftlk"
> > ?1st ftlk @ /usr/src/sys/modules/linux/../../compat/linux/linux_futex.c:177
> > ?2nd ftlk @ /usr/src/sys/modules/linux/../../compat/linux/linux_futex.c:203
> > KDB: stack backtrace:
> > db_trace_self_wrapper(c07fd8ea,ea393b58,c060a145,c05fac1b,c08007b2,...)
> > at db_trace_self_wrapper+0x26
> > kdb_backtrace(c05fac1b,c08007b2,c0b49757,c58ead20,ea393bb4,...) at
> > kdb_backtrace+0x29
> > _witness_debugger(c08007b2,c0b49793,c0b49757,cb,0,...) at _witness_debugger+0x25
> > witness_checkorder(c9bba780,9,c0b49757,cb,0,...) at witness_checkorder+0x469
> > _sx_xlock(c9bba780,0,c0b49757,cb,0,...) at _sx_xlock+0x85
> > futex_get0(c0609f8c,c09cc7a8,c9ac7764,c09cc7a8,c084df3c,...) at futex_get0+0x116
> > linux_sys_futex(c9ac76c0,ea393cf8,ea393d18,ea393d1c,c0b4cf40,...) at
> > linux_sys_futex+0x6f
> > syscall(ea393d38) at syscall+0x2b4
> > Xint0x80_syscall() at Xint0x80_syscall+0x20
> > --- syscall (240, Linux ELF, linux_sys_futex), eip = 0x28799533, esp =
> > 0xbfbfc0cc, ebp = 0x4000001 ---
> >
> >
From what dchagin@ told me, the LOR is unavoidable since he has to
acquire two sx locks of the same name. On the other hand, second sx lock
is not visible to any thread except the current one, so the LOR should
be innocent.

> 
> This time seeing this LOR again but with another one just before.
> lock order reversal:
>  1st 0xc75365b8 pseudofs (pseudofs) @ /usr/src/sys/kern/vfs_lookup.c:497
>  2nd 0xc088ea3c allproc (allproc) @ /usr/src/sys/kern/kern_proc.c:292
> KDB: stack backtrace:
> db_trace_self_wrapper(c07fd8ea,e82148e4,c060a145,c05fac1b,c08008bf,...)
> at db_trace_self_wrapper+0x26
> kdb_backtrace(c05fac1b,c08008bf,c58eabe8,c58e30d0,e8214940,...) at
> kdb_backtrace+0x29
> _witness_debugger(c08008bf,c088ea3c,c07f981d,c58e30d0,c07f96f0,...) at
> _witness_debugger+0x25
> witness_checkorder(c088ea3c,1,c07f96f0,124,0,...) at witness_checkorder+0x839
> _sx_slock(c088ea3c,0,c07f96f0,124,c73c4980,...) at _sx_slock+0x85
> pfind(514,c72ba1a0,4,c07f8d78,c5fe1b40,...) at pfind+0x2f
> pfs_visible(0,0,c07f042d,7c,c7536560,...) at pfs_visible+0x3a
> pfs_lookup(e8214a40,c082715e,c7536560,c7536560,e8214bf8,...) at pfs_lookup+0x3dd
> VOP_CACHEDLOOKUP_APV(c0843960,e8214a40,e8214bf8,e8214be4,c73c4e80,...)
> at VOP_CACHEDLOOKUP_APV+0xc5
> vfs_cache_lookup(e8214acc,c08087d0,c0875a00,200000,e8214bcc,...) at
> vfs_cache_lookup+0xd6
> VOP_LOOKUP_APV(c0843960,e8214acc,e8214bf8,1f1,e8214be4,...) at
> VOP_LOOKUP_APV+0xe5
> lookup(e8214bcc,c5fd1800,0,c5,c5ef77f8,...) at lookup+0x63b
> namei(e8214bcc,c5c1500d,3f3,e8214c20,c5c1500d,...) at namei+0x57f
> kern_alternate_path(c5fe1b40,c0b4921c,2879f478,0,e8214c74,...) at kern_alternate
> _path+0x1cd
> linux_emul_convpath(c5fe1b40,2879f478,0,e8214c74,0,...) at
> linux_emul_convpath+0x3c
> linux_open(c5fe1b40,e8214cf8,e8214d18,e8214d1c,c0b4b58c,...) at linux_open+0x41
> syscall(e8214d38) at syscall+0x2b4
> Xint0x80_syscall() at Xint0x80_syscall+0x20
> --- syscall (5, Linux ELF, linux_open), eip = 0x2889115e, esp =
> 0xbfbfbd1c, ebp = 0xbfbfbd6c ---
> acquiring duplicate lock of same type: "ftlk"
> [...]
> 
> I'm running head from 08/26.
> There were recent changes in pseudofs. Could it be fixed?
> Looks like it's connected to running firefox3 with linprocfs (for adobe flash).

The second LOR actually exposes the right order. It would be interesting
to look up the point where the other order is established.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20090908/6946fce0/attachment.pgp
From attilio at freebsd.org  Tue Sep  8 09:13:04 2009
From: attilio at freebsd.org (Attilio Rao)
Date: Tue Sep  8 09:13:11 2009
Subject: acquiring duplicate lock of same type: "ftlk"
In-Reply-To: <20090908091114.GH47688@deviant.kiev.zoral.com.ua>
References: <a31046fc0908270158l63b103a7v6c9fd1b7be54d3ed@mail.gmail.com>
	<a31046fc0909071115td2d5309na5738a44402feaa9@mail.gmail.com>
	<20090908091114.GH47688@deviant.kiev.zoral.com.ua>
Message-ID: <3bbf2fe10909080213i588493darf8dd1e1ff768cb0a@mail.gmail.com>

2009/9/8 Kostik Belousov <kostikbel@gmail.com>:
> On Mon, Sep 07, 2009 at 10:15:48PM +0400, pluknet wrote:
>> 2009/8/27 pluknet <pluknet@gmail.com>:
>> > Hi.
>> >
>> > Got it on FreeBSD 9.0-CURRENT while been running in Xorg, don't know
>> > where exactly.
>> >
>> > Acquiring duplicate lock of same type: "ftlk"
>> >  1st ftlk @ /usr/src/sys/modules/linux/../../compat/linux/linux_futex.c:177
>> >  2nd ftlk @ /usr/src/sys/modules/linux/../../compat/linux/linux_futex.c:203
>> > KDB: stack backtrace:
>> > db_trace_self_wrapper(c07fd8ea,ea393b58,c060a145,c05fac1b,c08007b2,...)
>> > at db_trace_self_wrapper+0x26
>> > kdb_backtrace(c05fac1b,c08007b2,c0b49757,c58ead20,ea393bb4,...) at
>> > kdb_backtrace+0x29
>> > _witness_debugger(c08007b2,c0b49793,c0b49757,cb,0,...) at _witness_debugger+0x25
>> > witness_checkorder(c9bba780,9,c0b49757,cb,0,...) at witness_checkorder+0x469
>> > _sx_xlock(c9bba780,0,c0b49757,cb,0,...) at _sx_xlock+0x85
>> > futex_get0(c0609f8c,c09cc7a8,c9ac7764,c09cc7a8,c084df3c,...) at futex_get0+0x116
>> > linux_sys_futex(c9ac76c0,ea393cf8,ea393d18,ea393d1c,c0b4cf40,...) at
>> > linux_sys_futex+0x6f
>> > syscall(ea393d38) at syscall+0x2b4
>> > Xint0x80_syscall() at Xint0x80_syscall+0x20
>> > --- syscall (240, Linux ELF, linux_sys_futex), eip = 0x28799533, esp =
>> > 0xbfbfc0cc, ebp = 0x4000001 ---
>> >
>> >
> From what dchagin@ told me, the LOR is unavoidable since he has to
> acquire two sx locks of the same name. On the other hand, second sx lock
> is not visible to any thread except the current one, so the LOR should
> be innocent.
>
>>
>> This time seeing this LOR again but with another one just before.
>> lock order reversal:
>>  1st 0xc75365b8 pseudofs (pseudofs) @ /usr/src/sys/kern/vfs_lookup.c:497
>>  2nd 0xc088ea3c allproc (allproc) @ /usr/src/sys/kern/kern_proc.c:292
>> KDB: stack backtrace:
>> db_trace_self_wrapper(c07fd8ea,e82148e4,c060a145,c05fac1b,c08008bf,...)
>> at db_trace_self_wrapper+0x26
>> kdb_backtrace(c05fac1b,c08008bf,c58eabe8,c58e30d0,e8214940,...) at
>> kdb_backtrace+0x29
>> _witness_debugger(c08008bf,c088ea3c,c07f981d,c58e30d0,c07f96f0,...) at
>> _witness_debugger+0x25
>> witness_checkorder(c088ea3c,1,c07f96f0,124,0,...) at witness_checkorder+0x839
>> _sx_slock(c088ea3c,0,c07f96f0,124,c73c4980,...) at _sx_slock+0x85
>> pfind(514,c72ba1a0,4,c07f8d78,c5fe1b40,...) at pfind+0x2f
>> pfs_visible(0,0,c07f042d,7c,c7536560,...) at pfs_visible+0x3a
>> pfs_lookup(e8214a40,c082715e,c7536560,c7536560,e8214bf8,...) at pfs_lookup+0x3dd
>> VOP_CACHEDLOOKUP_APV(c0843960,e8214a40,e8214bf8,e8214be4,c73c4e80,...)
>> at VOP_CACHEDLOOKUP_APV+0xc5
>> vfs_cache_lookup(e8214acc,c08087d0,c0875a00,200000,e8214bcc,...) at
>> vfs_cache_lookup+0xd6
>> VOP_LOOKUP_APV(c0843960,e8214acc,e8214bf8,1f1,e8214be4,...) at
>> VOP_LOOKUP_APV+0xe5
>> lookup(e8214bcc,c5fd1800,0,c5,c5ef77f8,...) at lookup+0x63b
>> namei(e8214bcc,c5c1500d,3f3,e8214c20,c5c1500d,...) at namei+0x57f
>> kern_alternate_path(c5fe1b40,c0b4921c,2879f478,0,e8214c74,...) at kern_alternate
>> _path+0x1cd
>> linux_emul_convpath(c5fe1b40,2879f478,0,e8214c74,0,...) at
>> linux_emul_convpath+0x3c
>> linux_open(c5fe1b40,e8214cf8,e8214d18,e8214d1c,c0b4b58c,...) at linux_open+0x41
>> syscall(e8214d38) at syscall+0x2b4
>> Xint0x80_syscall() at Xint0x80_syscall+0x20
>> --- syscall (5, Linux ELF, linux_open), eip = 0x2889115e, esp =
>> 0xbfbfbd1c, ebp = 0xbfbfbd6c ---
>> acquiring duplicate lock of same type: "ftlk"
>> [...]
>>
>> I'm running head from 08/26.
>> There were recent changes in pseudofs. Could it be fixed?
>> Looks like it's connected to running firefox3 with linprocfs (for adobe flash).
>
> The second LOR actually exposes the right order. It would be interesting
> to look up the point where the other order is established.

You would manually patch the witness static table with this order and
the opposite will show, when happening.

Attilio


-- 
Peace can only be achieved by understanding - A. Einstein
From sweetnavelorange at gmail.com  Tue Sep  8 11:02:50 2009
From: sweetnavelorange at gmail.com (James Butler)
Date: Tue Sep  8 11:02:57 2009
Subject: Can't boot 8.0-BETA4 from USB stick
Message-ID: <f0dd9eb90909080402m27558850g6aaa2a5e4c477758@mail.gmail.com>

Greetings all,

I have an amd64 system (Asus A8V-MX) which boots 7.2 from a USB flash
drive. Trying an 8-STABLE kernel from Saturday (identifies as
8.0-BETA4), the system can't boot - here is the last bit of the kernel
messages (typed, with comments):

[witness performance blah blah blah]
root mount waiting for: usbus2 usbus1 usbus0
uhub0: 2 ports with 2 removable, self powered
uhub1: 2 ports with 2 removable, self powered
root mount waiting for: usbus2
uhub2: 2 ports with 2 removable, self powered
root mount waiting for: usbus2
ugen2.2: <TOSHIBA> at usbus2
umass0: <Toshiba TransMemory, class 0/0, rev 2.00/1.00, addr 2> on usbus2
umass0:  SCSI over Bulk-Only; quirks = 0x0000
root mount waiting for: usbus2
umass0:0:0:-1: Attached to scbus0
Trying to mount root from ufs:/dev/da0s1a
ROOT MOUNT ERROR:
If you have invalid mount options, reboot, and da0 at umass-sim0 bus 0
target 0 lun 0  <---- This is suspicious
da0: <TOSHIBA TransMemory PMAP> Removable Direct Access SCSI-0 device
da0: 40.000MB/s transfers
da0: 3875MB (7936000 512 byte sectors: 255H 63S/T 493C)
first try the following from  <---- The rest of the message that was
cut off above
the loader prompt:

etc. etc. until the mountroot> prompt, and after that even specifying
the device doesn't work (and ? doesn't list it). It seems to my
non-hacker eyes that the device is not attaching until after it should
be.

Any help would be appreciated, and I can provide further information as needed.

Thanks,
James Butler
From hselasky at c2i.net  Tue Sep  8 11:50:11 2009
From: hselasky at c2i.net (Hans Petter Selasky)
Date: Tue Sep  8 11:50:17 2009
Subject: Can't boot 8.0-BETA4 from USB stick
In-Reply-To: <f0dd9eb90909080402m27558850g6aaa2a5e4c477758@mail.gmail.com>
References: <f0dd9eb90909080402m27558850g6aaa2a5e4c477758@mail.gmail.com>
Message-ID: <200909081350.34461.hselasky@c2i.net>

On Tuesday 08 September 2009 13:02:48 James Butler wrote:
> Greetings all,
>
> I have an amd64 system (Asus A8V-MX) which boots 7.2 
from a USB flash
> drive. Trying an 8-STABLE kernel from Saturday 
(identifies as
> 8.0-BETA4), the system can't boot - here is the last 
bit of the kernel
> messages (typed, with comments):
>
> [witness performance blah blah blah]
> root mount waiting for: usbus2 usbus1 usbus0
> uhub0: 2 ports with 2 removable, self powered
> uhub1: 2 ports with 2 removable, self powered
> root mount waiting for: usbus2
> uhub2: 2 ports with 2 removable, self powered
> root mount waiting for: usbus2
> ugen2.2: <TOSHIBA> at usbus2
> umass0: <Toshiba TransMemory, class 0/0, rev 2.00/1.00, 
addr 2> on usbus2
> umass0:  SCSI over Bulk-Only; quirks = 0x0000
> root mount waiting for: usbus2
> umass0:0:0:-1: Attached to scbus0
> Trying to mount root from ufs:/dev/da0s1a
> ROOT MOUNT ERROR:
> If you have invalid mount options, reboot, and da0 at 
umass-sim0 bus 0
> target 0 lun 0  <---- This is suspicious
> da0: <TOSHIBA TransMemory PMAP> Removable Direct Access 
SCSI-0 device
> da0: 40.000MB/s transfers
> da0: 3875MB (7936000 512 byte sectors: 255H 63S/T 493C)
> first try the following from  <---- The rest of the 
message that was
> cut off above
> the loader prompt:
>
> etc. etc. until the mountroot> prompt, and after that 
even specifying
> the device doesn't work (and ? doesn't list it). It 
seems to my
> non-hacker eyes that the device is not attaching until 
after it should
> be.
>
> Any help would be appreciated, and I can provide 
further information as
> needed.

Hi,

It looks like your device is detected too late. Have you 
tried another USB port? Or plugging in another dummy USB 
device?

--HPS

From mail25 at bzerk.org  Tue Sep  8 11:55:05 2009
From: mail25 at bzerk.org (Ruben de Groot)
Date: Tue Sep  8 11:55:17 2009
Subject: 8.0-BETA2 on soekris discarding packets?
Message-ID: <20090908115459.GA30570@ei.bzerk.org>


Hi,

I'm trying 8.0-BETA2 on a 4511 soekris board, but found a problem.

Outgoing networking is fine, but it looks like incoming connections are
silently discarded. No firewall is configured. Here's a tcpdump of normal
outgoing DNS traffic (IP address of the soekris is 192.168.179.15):

listening on sis0, link-type EN10MB (Ethernet), capture size 96 bytes
10:33:50.053875 IP 192.168.179.15.23093 > ei.lan.domain: 45893+ PTR? 255.179.168.192.in-addr.arpa. (46)
10:33:50.055038 IP ei.lan.domain > 192.168.179.15.23093: 45893 NXDomain* 0/1/0 (109)
10:33:50.066917 IP 192.168.179.15.13890 > ei.lan.domain: 45894+ PTR? 9.179.168.192.in-addr.arpa. (44)
10:33:50.067834 IP ei.lan.domain > 192.168.179.15.13890: 45894* 1/1/1 (113)

And here's a dump of an incoming ssh connection:

listening on sis0, link-type EN10MB (Ethernet), capture size 96 bytes
10:26:40.176756 IP ei.lan.55742 > 192.168.179.15.ssh: Flags [S], seq 1547228218, win 65535, options [mss 1460,nop,wscale 3,nop,nop,TS val 1961056657 ecr 0,sackOK,eol], length 0
10:26:43.175176 IP ei.lan.55742 > 192.168.179.15.ssh: Flags [S], seq 1547228218, win 65535, options [mss 1460,nop,wscale 3,nop,nop,TS val 1961059657 ecr 0,sackOK,eol], length 0
10:26:46.374688 IP ei.lan.55742 > 192.168.179.15.ssh: Flags [S], seq 1547228218, win 65535, options [mss 1460,nop,wscale 3,nop,nop,TS val 1961062857 ecr 0,sackOK,eol], length 0
10:26:49.574197 IP ei.lan.55742 > 192.168.179.15.ssh: Flags [S], seq 1547228218, win 65535, options [mss 1460,sackOK,eol], length 0
10:26:52.773759 IP ei.lan.55742 > 192.168.179.15.ssh: Flags [S], seq 1547228218, win 65535, options [mss 1460,sackOK,eol], length 0

Et cetera. No replies. This goes for all tcp ports, but ping works. nmap from another host says:

# nmap soekris

Starting Nmap 4.85BETA7 ( http://nmap.org ) at 2009-09-08 13:31 CEST
All 1000 scanned ports on 192.168.179.15 are filtered
MAC Address: 00:00:24:CB:93:28 (Connect AS)

Nmap done: 1 IP address (1 host up) scanned in 21.67 seconds

Anyone else seeing this?

Ruben

kernel config is below.


include GENERIC

cpu             I486_CPU
cpu             I586_CPU
ident           SOEKRIS

machine i386

options CPU_ELAN
options CPU_SOEKRIS
options HZ=150
#options CPU_ELAN_XTAL
options CPU_GEODE


From vince at unsane.co.uk  Tue Sep  8 12:03:51 2009
From: vince at unsane.co.uk (Vincent Hoffman)
Date: Tue Sep  8 12:04:09 2009
Subject: [Call For Testing] VirtualBox for FreeBSD! take 6
In-Reply-To: <E1MkWyt-000Eoi-1c@kabab.cs.huji.ac.il>
References: <20090611194557.GC98175@bsdcrew.de>	<E1MkFAi-0005OD-K0@kabab.cs.huji.ac.il>	<991123400909060811u9bea4d9rdbf453dfaae7c185@mail.gmail.com>	<20090906162544.GA39448@bsdcrew.de>
	<E1MkWyt-000Eoi-1c@kabab.cs.huji.ac.il>
Message-ID: <4AA64808.4030105@unsane.co.uk>

Danny Braniss wrote:
> [...]
>   
>>>> ok, so some time has passed, but virtualbox-2.2.51r20457.tar.gz is no
>>>> longer available, there is a
>>>> ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/distfiles/virtualbox-2.2.51r20457.tar.bz2
>>>> then again in ports/emulatores/virtualbox the version is 3.0.51r22226,
>>>>
>>>> can someone please explain?
>>>>         
>
> hi, the above was my question, which was totally ignored, not nice.
> I will try and refrase it:
> the call for testing is for a version (2.2.51r20457) which is not available, while
> the ports is 3.0.51r22226, so while I managed to compile it, it complains that COM
> is not running, all this under 8BETA-3, both under 32 and 64 bit.
> thnaks,
> 	danny
>
>   
The call for testing went out on 11th june
(http://lists.freebsd.org/pipermail/freebsd-current/2009-June/008061.html)  
I can only assume it was considered tested and working as the port was
committed on 15th june
(http://www.freebsd.org/cgi/cvsweb.cgi/ports/emulators/virtualbox/Makefile?rev=1.1;content-type=text%2Fplain)

Since then there have been 4 updates to the port. The last of which
updated it to 3.0.51r22226 on august 14th.

I would say the call for testing is no longer valid, please use the
version in ports.


Vince

> _______________________________________________
> 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 oliver at namp.de  Tue Sep  8 12:41:35 2009
From: oliver at namp.de (Oliver Fakler)
Date: Tue Sep  8 12:41:43 2009
Subject: boot from raidz
Message-ID: <24905.1252413921@namp.de>



On Mon 07/09/09 20:22 , Paul Wootton  wrote:Oliver Fakler wrote:
 > On Mon 07/09/09 13:40 , Bernhard Schmidt  wrote:
 >  Am 07.09.2009 um 11:13 schrieb Oliver Fakler:
 >  >
 >  > BODY { font-family:Arial, Helvetica, sans-serif;font-size:12px;
}
 >  >
 >  > On Mon 07/09/09 10:07 , Bernhard Schmidt   
 >  > wrote:
 >  >
 >  >
 >  > Am 06.09.2009 um 21:45 schrieb Oliver Fakler:
 >  >
 >  > >
 >  > >
 >  > > Hi all,
 >  > >
 >  > > i installed a 8.0 beta 3 amd64 based testsystem.
 >  > >
 >  > > i tried with a root on a raidz, but i have a problem after
the
 > first
 >  > > reboot, there is a error message:
 >  > >
 >  > > can't load kernel
 >  > > I found something that boot root from raidz is not supported,
 > but
 >  > > maybe there is a solution??
 >  > > Hope some can help me
 >  >
 >  >
 >  > There are patches from Doug Rabson which add support for
booting
 > from
 >  > raidz/raidz2.
 >  >
 >  >
 >
http://lists.freebsd.org/pipermail/freebsd-fs/2008-December/005498.html
[1]"
target="_blank">http://lists.freebsd.org/pipermail/freebsd-fs/2008-December/005498.html
 > [2]"
 >
target="_blank">http://lists.freebsd.org/pipermail/freebsd-fs/2008-December/005498.html
[2]"
target="_blank">http://lists.freebsd.org/pipermail/freebsd-fs/2008-December/005498.html
 >
 >  > "
 >
target="_blank">http://lists.freebsd.org/pipermail/freebsd-fs/2008-December/005498.html
[3]"
target="_blank">http://lists.freebsd.org/pipermail/freebsd-fs/2008-December/005498.html
 > [3]"
 >
target="_blank">http://lists.freebsd.org/pipermail/freebsd-fs/2008-December/005498.html
[4]"
target="_blank">http://lists.freebsd.org/pipermail/freebsd-fs/2008-December/005498.html
 >  Seems that patch made it already into the tree (r192194).
 >  >
 >  >
 >  > I tried it, but after a make obj && make depend the make failed
 > with  
 >  > different errors like undeclared and has no member named.
 >  >
 >  > I used patch raidzboot-14052009.diff started patching from
 > /usr/src/ 
 >  > sys/ , i'm not sure if this was the right way.
 >  >
 >  > I'm also not sure if the way of installation was the right one,
 
 >  > here's the way i go:
 >  >
 >  >
 >  > gpart create -s GPT da0
 >  > gpart add -b 34 -s 128 -t freebsd-boot da0
 >  > gpart add -b 162 -s 5242880 -t freebsd-swap da0
 >  > gpart add -b 5243042 -s 11534141 -t freebsd-zfs da0
 >  > gpart bootcode -b /mnt2/boot/pmbr -p /mnt2/boot/gptzfsboot -i 1
 > da0
 >  > gpart bootcode -b /mnt2/boot/pmbr -p /mnt2/boot/gptzfsboot -i 1
 > da1
 >  > gpart bootcode -b /mnt2/boot/pmbr -p /mnt2/boot/gptzfsboot -i 1
 > da2
 >  >
 >  Can you try zfsboot instead of gptzfsboot?
 >
 >
http://unix.derkeiler.com/Mailing-Lists/FreeBSD/stable/2009-05/msg00689.html
[5]"
target="_blank">http://unix.derkeiler.com/Mailing-Lists/FreeBSD/stable/2009-05/msg00689.html
 > [4]"
 >
target="_blank">http://unix.derkeiler.com/Mailing-Lists/FreeBSD/stable/2009-05/msg00689.html
[6]"
target="_blank">http://unix.derkeiler.com/Mailing-Lists/FreeBSD/stable/2009-05/msg00689.html
 >
 >    at the end of the mail.
 >  >
 >  >
 >  > kldload /mnt2/boot/kernel/opensolaris.ko
 >  > kldload /mnt2/boot/kernel/zfs.ko
 >  >
 >  > zpool create tank raidz da0p3 da1p1 d2p1
 >  >
 >  > zfs create tank/tmp
 >  > zfs create tank/usr
 >  > zfs create tank/var
 >  >
 >  > cd /dist/8.0-BETA3/base
 >  > export DESTDIR=/tank
 >  > ./install.sh
 >  > You are about to extract the base distribution into /tank - are
 > you  
 >  > SURE
 >  > you want to do this over your installed system (y/n)? y
 >  > cd ../kernels
 >  > ./install.sh generic
 >  > cd /tank/boot
 >  > cp -Rp GENERIC/* kernel/
 >  >
 >  > cd /dist/8.0-BETA3/src
 >  > ./install.sh all
 >  > Extracting sources into /usr/src...
 >  >   Extracting source component: base
 >  >   Extracting source component: bin
 >  >   Extracting source component: cddl
 >  >   Extracting source component: contrib
 >  >   Extracting source component: crypto
 >  >   Extracting source component: etc
 >  >   Extracting source component: games
 >  >   Extracting source component: gnu
 >  >   Extracting source component: include
 >  >   Extracting source component: krb5
 >  >   Extracting source component: lib
 >  >   Extracting source component: libexec
 >  >   Extracting source component: release
 >  >   Extracting source component: rescue
 >  >   Extracting source component: sbin
 >  >   Extracting source component: secure
 >  >   Extracting source component: share
 >  >   Extracting source component: sys
 >  >   Extracting source component: tools
 >  >   Extracting source component: ubin
 >  >   Extracting source component: usbin
 >  > Done extracting sources.
 >  > Done extracting sources.
 >  > cd ../manpages
 >  > ./install.sh
 >  >
 >  > echo 'zfs_enable="YES"' > /tank/etc/rc.conf
 >  > echo 'LOADER_ZFS_SUPPORT="YES"' > /tank/etc/src.conf
 >  > echo 'zfs_load="YES"' > /tank/boot/loader.conf
 >  > echo 'vfs.root.mountfrom="zfs:tank"' >> /tank/boot/loader.conf
 >  > echo &acute;/dev/da0p2 none swap sw 0 0&acute;>>
/tank/etc/fstab
 >  >
 >  > mkdir /boot/zfs
 >  > zpool export tank && zpool import tank
 >  > cp /boot/zfs/zpool.cache /tank/boot/zfs/
 >  >
 >  > chroot /tank
 >  > mount -t devfs devfs /dev
 >  > unset DESTDIR
 >  > cd /usr/src/sys/boot/
 >  > make obj
 >  > make depend
 >  > make
 >  > cd i386/loader
 >  > make install
 >  > umount /dev
 >  > touch /etc/fstab
 >  > exit
 >  >
 >  > export LD_LIBRARY_PATH=/mnt2/lib
 >  > zfs set mountpoint=legacy tank
 >  > zfs set mountpoint=/tmp tank/tmp
 >  > zfs set mountpoint=/var tank/var
 >  > zfs set mountpoint=/usr tank/usr
 >  > zpool set bootfs=tank tank
 >  >
 >  Seems correct at first glance.
 >  --
 >  Bernhard
 > testet with zfsboot instead of gptzfsboot but it was not
successfull
 > :-(
 >
 > Links:
 > ------
 > [2] http://mail.kuehlbox.de/parse.php%3Fredirect%3D%26lt%3Ba [7]"
target="_blank">http://mail.kuehlbox.de/parse.php?redirect= [3]
http://mail.kuehlbox.de/parse.php%3Fredirect%3D%26lt%3Ba [8]"
target="_blank">http://mail.kuehlbox.de/parse.php?redirect= [4]
http://mail.kuehlbox.de/parse.php%3Fredirect%3D%26lt%3Ba [9]"
target="_blank">http://mail.kuehlbox.de/parse.php?redirect=
_______________________________________________
 >  mailing list
 > http://lists.freebsd.org/mailman/listinfo/freebsd-current [11]"
target="_blank">http://lists.freebsd.org/mailman/listinfo/freebsd-current
 > To unsubscribe, send any mail to "
 I have a fully running GPT ZFS RaidZ setup using what was at the
time 8-HEAD
 I cant remember the exact steps I took, but one thing I have
different 
 is I have a root filesystem within my zpool
 [ /usr/home/paul]$ gpart show
 =>       34  976773101  ada1  GPT  (466G)
          34        256     1  freebsd-boot  (128K)
         290    8388608     2  freebsd-swap  (4.0G)
     8388898  147912557     3  freebsd-zfs  (71G)
   156301455  820471680        - free -  (391G)
 =>       34  488394988  ada2  GPT  (233G)
          34        256     1  freebsd-boot  (128K)
         290    8388608     2  freebsd-swap  (4.0G)
     8388898  147912557     3  freebsd-zfs  (71G)
   156301455  332093567        - free -  (158G)
 =>       34  156301421  ada3  GPT  (75G)
          34        256     1  freebsd-boot  (128K)
         290    8388608     2  freebsd-swap  (4.0G)
     8388898  147912557     3  freebsd-zfs  (71G)
 [ /usr/home/paul]$ zpool status
   pool: zboot
  state: ONLINE
  scrub: none requested
 config:
         NAME        STATE     READ WRITE CKSUM
         zboot       ONLINE       0     0     0
           ada1p3    ONLINE       0     0     0
           ada2p3    ONLINE       0     0     0
           ada3p3    ONLINE       0     0     0
 errors: No known data errors
 [ /usr/home/paul]$ zfs list
 NAME           USED  AVAIL  REFER  MOUNTPOINT
 zboot         33.5G   175G    18K  none
 zboot/root    12.4G   175G  12.2G  none
 zboot/tmp     82.9M   175G  82.6M  none
 zboot/usr     20.8G   175G  16.5G  none
 zboot/var      216M   175G   123M  none
 Im also using fstabs to mount my ZFS filesystems
 [ /usr/home/paul]$ more /etc/fstab
 # Device        Mountpoint      FStype          Options         Dump
   
 Pass#
 zboot/root      /               zfs             rw              0   
   0
 zboot/usr       /usr            zfs             rw              0   
   0
 zboot/var       /var            zfs             rw              0   
   0
 zboot/tmp       /tmp            zfs             rw,noatime      0   
   0
 proc            /proc           procfs          rw              0   
   0
 I remember speak to someone a while back, and I *think* we came to
the 
 conclusion that using the zpool as your root will not work correctly
and 
 you should really create a root filesystem inside the zpool
 Lets me know how this works out for you
 Paul

-----------------------------------------------------------------------------------
 Fletcher Moorland Limited is a company registered in England and
Wales. 
 Registration number: 2984467. 
 Registered office: Elenora Street, Stoke on Trent, Staffordshire,
ST4 1QG. 
 VAT Registration number: 478730606 
 Telephone: 01782 411021 | Fax: 01782 744470 |
http://www.fletchermoorland.co.uk [17]"
target="_blank">http://www.fletchermoorland.co.uk 
 _______________________________________________
  mailing list
 http://lists.freebsd.org/mailman/listinfo/freebsd-current [19]"
target="_blank">http://lists.freebsd.org/mailman/listinfo/freebsd-current
 To unsubscribe, send any mail to ""
	your pool is just a stripe, no raidz

	i testet it with striping, and it was successfull, but i need a
raidz

	there are some new errors on Beta4

	can'tfind root filesystem

	maybe you're right with your idea of an extra root folder, but i
think if he can't find root filesystem, he also can't read fstab.
	maybe more ideas? :-)
	cheers 
	Oliver

Links:
------
[1] http://mail.kuehlbox.de/parse.php?redirect=<a href=
[2] http://mail.kuehlbox.de/parse.php?redirect=<a href=
[3] http://mail.kuehlbox.de/parse.php?redirect=<a href=
[4] http://mail.kuehlbox.de/parse.php?redirect=<a href=
[5] http://mail.kuehlbox.de/parse.php?redirect=<a href=
[6] http://mail.kuehlbox.de/parse.php?redirect=<a href=
[7] http://mail.kuehlbox.de/parse.php?redirect=<a href=
[8] http://mail.kuehlbox.de/parse.php?redirect=<a href=
[9] http://mail.kuehlbox.de/parse.php?redirect=<a href=
[11] http://mail.kuehlbox.de/parse.php?redirect=<a href=
[17] http://mail.kuehlbox.de/parse.php?redirect=<a href=
[19] http://mail.kuehlbox.de/parse.php?redirect=<a href=
From boogie at lazybytes.org  Tue Sep  8 13:40:18 2009
From: boogie at lazybytes.org (Sergey Vinogradov)
Date: Tue Sep  8 13:40:25 2009
Subject: ath(4) Atheros AR9285 support
Message-ID: <4AA65ABE.4000207@lazybytes.org>

Hi,
Just wanted to know, if there will be any Atheros AR9285 support in
ath(4) driver in nearest future? I've got my ASUS Eee 1005HA with one of
these wireless adapters, and it doesn't seem to be working.

-- 
wbr,
Boo

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 259 bytes
Desc: OpenPGP digital signature
Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20090908/f48981ad/signature.pgp
From wollman at hergotha.csail.mit.edu  Tue Sep  8 05:43:16 2009
From: wollman at hergotha.csail.mit.edu (Garrett Wollman)
Date: Tue Sep  8 13:43:05 2009
Subject: FreeBSD timing issues and qemu (was: Re: [Qemu-devel] Re: 
	Breakage with local APIC routing)
In-Reply-To: <bc2d970909071917n12256d9ucee24327aec3d527@mail.gmail.com>
References: <4A93AFF9.1060201@web.de>
	<52d4a3890908250321u746e5757u136030bcbc19208d@mail.gmail.com>
	<4A93BF0C.8040601@web.de>
	<20090826221001.GA1070@triton8.kn-bremen.de>
	<4A96C8D9.6070804@web.de>
	<20090829211848.GA59305@triton8.kn-bremen.de>
	<4A9B800F.1040209@web.de>
	<20090831212723.GA32448@triton8.kn-bremen.de>
	<20090901201248.GA60123@triton8.kn-bremen.de>
	<20090907205955.GA91866@triton8.kn-bremen.de>
Message-ID: <200909080516.n885Gba0065213@hergotha.csail.mit.edu>

In article <bc2d970909071917n12256d9ucee24327aec3d527@mail.gmail.com>,
Ryan Stone  <rysto32@gmail.com> wrote:
>I'm not entirely clear on why it's done this way, but the timer is run at
>twice hz for statistics-gathering purposes*.  CPU usage statistics gathering
>is driven off of the timer interrupt.  Running the timer at twice hz may be
>an attempt to eliminate clock-aliasing problems; if so, it's a poor way of
>doing so.

The statistics timer is supposed to be jittered with an exponential
distribution, so that applications cannot avoid being charged for CPU
time by running synchronously (and out-of-phase) with the timer.  This
was historically broken on PC hardware, and is probably still broken
on SMP PC hardware, because there are insufficient programmable timer
interrupts.  Ideally, you'd like a distinct statistics timers on each
CPU, with a sufficiently (quickly) programmable period.

-GAWollman

From grarpamp at gmail.com  Tue Sep  8 05:50:11 2009
From: grarpamp at gmail.com (grarpamp)
Date: Tue Sep  8 14:05:57 2009
Subject: LOR RELENG_8 fd/zfs (close)
Message-ID: <d2e731a10909072250r7e4906fp87d37e570a607ad3@mail.gmail.com>

Didn't see the 1st/2nd "a (b) @ src_file" on the big page of LOR's.
Put here for anyone interested.

lock order reversal:
 1st 0xc8f1d42c filedesc structure (filedesc structure) @
/.../src/sys/kern/kern_descrip.c:1088
 2nd 0xc4af38b8 ufs (ufs) @ /.../src/sys/kern/vfs_subr.c:4091
KDB: stack backtrace:
db_trace_self_wrapper(c0c75d72,e6f4ca2c,c08c1365,c08b20eb,c0c78d15,...)
at db_trace_self_wrapper+0x26
kdb_backtrace(c08b20eb,c0c78d15,c452c2a0,c452f638,e6f4ca88,...) at
kdb_backtrace+0x29
_witness_debugger(c0c78d15,c4af38b8,c0c6b44b,c452f638,c0c801f7,...) at
_witness_debugger+0x25
witness_checkorder(c4af38b8,9,c0c801f7,ffb,c4af38d4,...) at
witness_checkorder+0x839
__lockmgr_args(c4af38b8,80400,c4af38d4,0,0,...) at __lockmgr_args+0x7a7
ffs_lock(e6f4cb98,4,0,80400,c4af3860,...) at ffs_lock+0x8a
VOP_LOCK1_APV(c0d7a580,e6f4cb98,c0c6d72e,c0d92fe0,c4af3860,...) at
VOP_LOCK1_APV+0xb5
_vn_lock(c4af3860,80400,c0c801f7,ffb,e6f4cbf4,...) at _vn_lock+0x5e
vfs_knllock(c4af3860,0,c0c6d72e,696,c4c22e9c,...) at vfs_knllock+0x29
knlist_remove_kq(0,e6f4cc14,c090c9a9,c7fcaea4,c4c22e9c,...) at
knlist_remove_kq+0x85
knlist_remove(c7fcaea4,c4c22e9c,0,e6f4cc40,c084fe85,...) at knlist_remove+0x1b
filt_vfsdetach(c4c22e9c,0,c0c6d72e,777,9,...) at filt_vfsdetach+0x39
knote_fdclose(c632d6c0,9,c0c6d256,440,c8f1d42c,...) at knote_fdclose+0xf5
kern_close(c632d6c0,9,e6f4cd2c,c0bb0a53,c632d6c0,...) at kern_close+0xd2
close(c632d6c0,e6f4ccf8,4,c0c795e6,c0d58d48,...) at close+0x1a
syscall(e6f4cd38) at syscall+0x2a3
Xint0x80_syscall() at Xint0x80_syscall+0x20
--- syscall (6, FreeBSD ELF32, close), eip = 0x2837b2a3, esp =
0xbfbfe45c, ebp = 0xbfbfe478 ---

lock order reversal:
 1st 0xc8f1d42c filedesc structure (filedesc structure) @
/.../src/sys/kern/kern_descrip.c:1088
 2nd 0xc8c7e37c zfs (zfs) @ /.../src/sys/kern/vfs_subr.c:4091
KDB: stack backtrace:
db_trace_self_wrapper(c0c75d72,e6f4ca34,c08c1365,c08b20eb,c0c78d15,...)
at db_trace_self_wrapper+0x26
kdb_backtrace(c08b20eb,c0c78d15,c452c2a0,c452fd20,e6f4ca90,...) at
kdb_backtrace+0x29
_witness_debugger(c0c78d15,c8c7e37c,c1218129,c452fd20,c0c801f7,...) at
_witness_debugger+0x25
witness_checkorder(c8c7e37c,9,c0c801f7,ffb,c8c7e398,...) at
witness_checkorder+0x839
__lockmgr_args(c8c7e37c,80400,c8c7e398,0,0,...) at __lockmgr_args+0x7a7
vop_stdlock(e6f4cb98,4,0,80400,c8c7e324,...) at vop_stdlock+0x62
VOP_LOCK1_APV(c121d560,e6f4cb98,c0c6d72e,c0d92fe0,c8c7e324,...) at
VOP_LOCK1_APV+0xb5
_vn_lock(c8c7e324,80400,c0c801f7,ffb,e6f4cbf4,...) at _vn_lock+0x5e
vfs_knllock(c8c7e324,0,c0c6d72e,696,c82bc908,...) at vfs_knllock+0x29
knlist_remove_kq(0,e6f4cc14,c090c9a9,c82eed78,c82bc908,...) at
knlist_remove_kq+0x85
knlist_remove(c82eed78,c82bc908,0,e6f4cc40,c084fe85,...) at knlist_remove+0x1b
filt_vfsdetach(c82bc908,0,c0c6d72e,777,17,...) at filt_vfsdetach+0x39
knote_fdclose(c632d6c0,1d7,c0c6d256,440,c8f1d42c,...) at knote_fdclose+0xf5
kern_close(c632d6c0,1d7,e6f4cd2c,c0bb0a53,c632d6c0,...) at kern_close+0xd2
close(c632d6c0,e6f4ccf8,4,c0dcb8c0,c0d58d48,...) at close+0x1a
syscall(e6f4cd38) at syscall+0x2a3
Xint0x80_syscall() at Xint0x80_syscall+0x20
--- syscall (6, FreeBSD ELF32, close), eip = 0x2837b2a3, esp =
0xbfbfe48c, ebp = 0xbfbfe4a8 ---
From danny at cs.huji.ac.il  Tue Sep  8 14:09:07 2009
From: danny at cs.huji.ac.il (Danny Braniss)
Date: Tue Sep  8 14:09:24 2009
Subject: [Call For Testing] VirtualBox for FreeBSD! take 6 
In-Reply-To: <4AA64808.4030105@unsane.co.uk> 
References: <20090611194557.GC98175@bsdcrew.de>
	<E1MkFAi-0005OD-K0@kabab.cs.huji.ac.il>
	<991123400909060811u9bea4d9rdbf453dfaae7c185@mail.gmail.com>
	<20090906162544.GA39448@bsdcrew.de>
	<E1MkWyt-000Eoi-1c@kabab.cs.huji.ac.il>
	<4AA64808.4030105@unsane.co.uk>
Message-ID: <E1Ml1NY-000CZ0-Kl@kabab.cs.huji.ac.il>

> Danny Braniss wrote:
> > [...]
> >   
> >>>> ok, so some time has passed, but virtualbox-2.2.51r20457.tar.gz is no
> >>>> longer available, there is a
> >>>> ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/distfiles/virtualbox-2.2.51r20457.tar.bz2
> >>>> then again in ports/emulatores/virtualbox the version is 3.0.51r22226,
> >>>>
> >>>> can someone please explain?
> >>>>         
> >
> > hi, the above was my question, which was totally ignored, not nice.
> > I will try and refrase it:
> > the call for testing is for a version (2.2.51r20457) which is not available, while
> > the ports is 3.0.51r22226, so while I managed to compile it, it complains that COM
> > is not running, all this under 8BETA-3, both under 32 and 64 bit.
> > thnaks,
> > 	danny
> >
> >   
> The call for testing went out on 11th june
> (http://lists.freebsd.org/pipermail/freebsd-current/2009-June/008061.html)  
> I can only assume it was considered tested and working as the port was
> committed on 15th june
> (http://www.freebsd.org/cgi/cvsweb.cgi/ports/emulators/virtualbox/Makefile?rev=1.1;content-type=text%2Fplain)
> 
> Since then there have been 4 updates to the port. The last of which
> updated it to 3.0.51r22226 on august 14th.
> 
> I would say the call for testing is no longer valid, please use the
> version in ports.

thank you, and all those involved!
	danny


From grarpamp at gmail.com  Tue Sep  8 07:24:32 2009
From: grarpamp at gmail.com (grarpamp)
Date: Tue Sep  8 14:32:19 2009
Subject: tzsetup and EST5EDT
Message-ID: <d2e731a10909080024p7f2f456bi2794a122e5333d6a@mail.gmail.com>

Can't seem to set EST5EDT using the menus:
 wall: yes
 region: america
 country: united states
 zone: all eastern time choices, 1~10, come up with EST.
Almost certain this is wrong.
info google: EST EST5EDT
Use
'cp /usr/share/zoneinfo/EST5EDT /etc/localtime'
 or
'echo y | tzsetup -s /usr/share/zoneinfo/EST5EDT'
instead.
RELENG_8
From ale at FreeBSD.org  Tue Sep  8 14:50:14 2009
From: ale at FreeBSD.org (Alex Dupre)
Date: Tue Sep  8 14:50:21 2009
Subject: ath(4) Atheros AR9285 support
In-Reply-To: <4AA65ABE.4000207@lazybytes.org>
References: <4AA65ABE.4000207@lazybytes.org>
Message-ID: <4AA668E0.1010305@FreeBSD.org>

Sergey Vinogradov ha scritto:
> Just wanted to know, if there will be any Atheros AR9285 support in
> ath(4) driver in nearest future? I've got my ASUS Eee 1005HA with one of
> these wireless adapters, and it doesn't seem to be working.

I think it should work with FreeBSD 8.0.

-- 
Alex Dupre
From paul at fletchermoorland.co.uk  Tue Sep  8 15:00:39 2009
From: paul at fletchermoorland.co.uk (Paul Wootton)
Date: Tue Sep  8 15:00:47 2009
Subject: boot from raidz
In-Reply-To: <24905.1252413921@namp.de>
References: <24905.1252413921@namp.de>
Message-ID: <4AA67F6B.20800@fletchermoorland.co.uk>

Oliver Fakler wrote:
> On Mon 07/09/09 20:22 , Paul Wootton  wrote:Oliver Fakler wrote:
>  > On Mon 07/09/09 13:40 , Bernhard Schmidt  wrote:
>  >  Am 07.09.2009 um 11:13 schrieb Oliver Fakler:
>  >  >
>  >  > BODY { font-family:Arial, Helvetica, sans-serif;font-size:12px;
> }
>  >  >
>  >  > On Mon 07/09/09 10:07 , Bernhard Schmidt   
>  >  > wrote:
>  >  >
>  >  >
>  >  > Am 06.09.2009 um 21:45 schrieb Oliver Fakler:
>  >  >
>  >  > >
>  >  > >
>  >  > > Hi all,
>  >  > >
>  >  > > i installed a 8.0 beta 3 amd64 based testsystem.
>  >  > >
>  >  > > i tried with a root on a raidz, but i have a problem after
> the
>  > first
>  >  > > reboot, there is a error message:
>  >  > >
>  >  > > can't load kernel
>  >  > > I found something that boot root from raidz is not supported,
>  > but
>  >  > > maybe there is a solution??
>  >  > > Hope some can help me
>  >  >
>  >  >
>  >  > There are patches from Doug Rabson which add support for
> booting
>  > from
>  >  > raidz/raidz2.
>  >  >
>  >  >
>  >
> http://lists.freebsd.org/pipermail/freebsd-fs/2008-December/005498.html
> [1]"
> target="_blank">http://lists.freebsd.org/pipermail/freebsd-fs/2008-December/005498.html
>  > [2]"
>  >
> target="_blank">http://lists.freebsd.org/pipermail/freebsd-fs/2008-December/005498.html
> [2]"
> target="_blank">http://lists.freebsd.org/pipermail/freebsd-fs/2008-December/005498.html
>  >
>  >  > "
>  >
> target="_blank">http://lists.freebsd.org/pipermail/freebsd-fs/2008-December/005498.html
> [3]"
> target="_blank">http://lists.freebsd.org/pipermail/freebsd-fs/2008-December/005498.html
>  > [3]"
>  >
> target="_blank">http://lists.freebsd.org/pipermail/freebsd-fs/2008-December/005498.html
> [4]"
> target="_blank">http://lists.freebsd.org/pipermail/freebsd-fs/2008-December/005498.html
>  >  Seems that patch made it already into the tree (r192194).
>  >  >
>  >  >
>  >  > I tried it, but after a make obj && make depend the make failed
>  > with  
>  >  > different errors like undeclared and has no member named.
>  >  >
>  >  > I used patch raidzboot-14052009.diff started patching from
>  > /usr/src/ 
>  >  > sys/ , i'm not sure if this was the right way.
>  >  >
>  >  > I'm also not sure if the way of installation was the right one,
>  
>  >  > here's the way i go:
>  >  >
>  >  >
>  >  > gpart create -s GPT da0
>  >  > gpart add -b 34 -s 128 -t freebsd-boot da0
>  >  > gpart add -b 162 -s 5242880 -t freebsd-swap da0
>  >  > gpart add -b 5243042 -s 11534141 -t freebsd-zfs da0
>  >  > gpart bootcode -b /mnt2/boot/pmbr -p /mnt2/boot/gptzfsboot -i 1
>  > da0
>  >  > gpart bootcode -b /mnt2/boot/pmbr -p /mnt2/boot/gptzfsboot -i 1
>  > da1
>  >  > gpart bootcode -b /mnt2/boot/pmbr -p /mnt2/boot/gptzfsboot -i 1
>  > da2
>  >  >
>  >  Can you try zfsboot instead of gptzfsboot?
>  >
>  >
> http://unix.derkeiler.com/Mailing-Lists/FreeBSD/stable/2009-05/msg00689.html
> [5]"
> target="_blank">http://unix.derkeiler.com/Mailing-Lists/FreeBSD/stable/2009-05/msg00689.html
>  > [4]"
>  >
> target="_blank">http://unix.derkeiler.com/Mailing-Lists/FreeBSD/stable/2009-05/msg00689.html
> [6]"
> target="_blank">http://unix.derkeiler.com/Mailing-Lists/FreeBSD/stable/2009-05/msg00689.html
>  >
>  >    at the end of the mail.
>  >  >
>  >  >
>  >  > kldload /mnt2/boot/kernel/opensolaris.ko
>  >  > kldload /mnt2/boot/kernel/zfs.ko
>  >  >
>  >  > zpool create tank raidz da0p3 da1p1 d2p1
>  >  >
>  >  > zfs create tank/tmp
>  >  > zfs create tank/usr
>  >  > zfs create tank/var
>  >  >
>  >  > cd /dist/8.0-BETA3/base
>  >  > export DESTDIR=/tank
>  >  > ./install.sh
>  >  > You are about to extract the base distribution into /tank - are
>  > you  
>  >  > SURE
>  >  > you want to do this over your installed system (y/n)? y
>  >  > cd ../kernels
>  >  > ./install.sh generic
>  >  > cd /tank/boot
>  >  > cp -Rp GENERIC/* kernel/
>  >  >
>  >  > cd /dist/8.0-BETA3/src
>  >  > ./install.sh all
>  >  > Extracting sources into /usr/src...
>  >  >   Extracting source component: base
>  >  >   Extracting source component: bin
>  >  >   Extracting source component: cddl
>  >  >   Extracting source component: contrib
>  >  >   Extracting source component: crypto
>  >  >   Extracting source component: etc
>  >  >   Extracting source component: games
>  >  >   Extracting source component: gnu
>  >  >   Extracting source component: include
>  >  >   Extracting source component: krb5
>  >  >   Extracting source component: lib
>  >  >   Extracting source component: libexec
>  >  >   Extracting source component: release
>  >  >   Extracting source component: rescue
>  >  >   Extracting source component: sbin
>  >  >   Extracting source component: secure
>  >  >   Extracting source component: share
>  >  >   Extracting source component: sys
>  >  >   Extracting source component: tools
>  >  >   Extracting source component: ubin
>  >  >   Extracting source component: usbin
>  >  > Done extracting sources.
>  >  > Done extracting sources.
>  >  > cd ../manpages
>  >  > ./install.sh
>  >  >
>  >  > echo 'zfs_enable="YES"' > /tank/etc/rc.conf
>  >  > echo 'LOADER_ZFS_SUPPORT="YES"' > /tank/etc/src.conf
>  >  > echo 'zfs_load="YES"' > /tank/boot/loader.conf
>  >  > echo 'vfs.root.mountfrom="zfs:tank"' >> /tank/boot/loader.conf
>  >  > echo &acute;/dev/da0p2 none swap sw 0 0&acute;>>
> /tank/etc/fstab
>  >  >
>  >  > mkdir /boot/zfs
>  >  > zpool export tank && zpool import tank
>  >  > cp /boot/zfs/zpool.cache /tank/boot/zfs/
>  >  >
>  >  > chroot /tank
>  >  > mount -t devfs devfs /dev
>  >  > unset DESTDIR
>  >  > cd /usr/src/sys/boot/
>  >  > make obj
>  >  > make depend
>  >  > make
>  >  > cd i386/loader
>  >  > make install
>  >  > umount /dev
>  >  > touch /etc/fstab
>  >  > exit
>  >  >
>  >  > export LD_LIBRARY_PATH=/mnt2/lib
>  >  > zfs set mountpoint=legacy tank
>  >  > zfs set mountpoint=/tmp tank/tmp
>  >  > zfs set mountpoint=/var tank/var
>  >  > zfs set mountpoint=/usr tank/usr
>  >  > zpool set bootfs=tank tank
>  >  >
>  >  Seems correct at first glance.
>  >  --
>  >  Bernhard
>  > testet with zfsboot instead of gptzfsboot but it was not
> successfull
>  > :-(
>  >
>  > Links:
>  > ------
>  > [2] http://mail.kuehlbox.de/parse.php%3Fredirect%3D%26lt%3Ba [7]"
> target="_blank">http://mail.kuehlbox.de/parse.php?redirect= [3]
> http://mail.kuehlbox.de/parse.php%3Fredirect%3D%26lt%3Ba [8]"
> target="_blank">http://mail.kuehlbox.de/parse.php?redirect= [4]
> http://mail.kuehlbox.de/parse.php%3Fredirect%3D%26lt%3Ba [9]"
> target="_blank">http://mail.kuehlbox.de/parse.php?redirect=
> _______________________________________________
>  >  mailing list
>  > http://lists.freebsd.org/mailman/listinfo/freebsd-current [11]"
> target="_blank">http://lists.freebsd.org/mailman/listinfo/freebsd-current
>  > To unsubscribe, send any mail to "
>  I have a fully running GPT ZFS RaidZ setup using what was at the
> time 8-HEAD
>  I cant remember the exact steps I took, but one thing I have
> different 
>  is I have a root filesystem within my zpool
>  [ /usr/home/paul]$ gpart show
>  =>       34  976773101  ada1  GPT  (466G)
>           34        256     1  freebsd-boot  (128K)
>          290    8388608     2  freebsd-swap  (4.0G)
>      8388898  147912557     3  freebsd-zfs  (71G)
>    156301455  820471680        - free -  (391G)
>  =>       34  488394988  ada2  GPT  (233G)
>           34        256     1  freebsd-boot  (128K)
>          290    8388608     2  freebsd-swap  (4.0G)
>      8388898  147912557     3  freebsd-zfs  (71G)
>    156301455  332093567        - free -  (158G)
>  =>       34  156301421  ada3  GPT  (75G)
>           34        256     1  freebsd-boot  (128K)
>          290    8388608     2  freebsd-swap  (4.0G)
>      8388898  147912557     3  freebsd-zfs  (71G)
>  [ /usr/home/paul]$ zpool status
>    pool: zboot
>   state: ONLINE
>   scrub: none requested
>  config:
>          NAME        STATE     READ WRITE CKSUM
>          zboot       ONLINE       0     0     0
>            ada1p3    ONLINE       0     0     0
>            ada2p3    ONLINE       0     0     0
>            ada3p3    ONLINE       0     0     0
>  errors: No known data errors
>  [ /usr/home/paul]$ zfs list
>  NAME           USED  AVAIL  REFER  MOUNTPOINT
>  zboot         33.5G   175G    18K  none
>  zboot/root    12.4G   175G  12.2G  none
>  zboot/tmp     82.9M   175G  82.6M  none
>  zboot/usr     20.8G   175G  16.5G  none
>  zboot/var      216M   175G   123M  none
>  Im also using fstabs to mount my ZFS filesystems
>  [ /usr/home/paul]$ more /etc/fstab
>  # Device        Mountpoint      FStype          Options         Dump
>    
>  Pass#
>  zboot/root      /               zfs             rw              0   
>    0
>  zboot/usr       /usr            zfs             rw              0   
>    0
>  zboot/var       /var            zfs             rw              0   
>    0
>  zboot/tmp       /tmp            zfs             rw,noatime      0   
>    0
>  proc            /proc           procfs          rw              0   
>    0
>  I remember speak to someone a while back, and I *think* we came to
> the 
>  conclusion that using the zpool as your root will not work correctly
> and 
>  you should really create a root filesystem inside the zpool
>  Lets me know how this works out for you
>  Paul
>
> -----------------------------------------------------------------------------------
>  Fletcher Moorland Limited is a company registered in England and
> Wales. 
>  Registration number: 2984467. 
>  Registered office: Elenora Street, Stoke on Trent, Staffordshire,
> ST4 1QG. 
>  VAT Registration number: 478730606 
>  Telephone: 01782 411021 | Fax: 01782 744470 |
> http://www.fletchermoorland.co.uk [17]"
> target="_blank">http://www.fletchermoorland.co.uk 
>  _______________________________________________
>   mailing list
>  http://lists.freebsd.org/mailman/listinfo/freebsd-current [19]"
> target="_blank">http://lists.freebsd.org/mailman/listinfo/freebsd-current
>  To unsubscribe, send any mail to ""
> 	your pool is just a stripe, no raidz
>
> 	i testet it with striping, and it was successfull, but i need a
> raidz
>
> 	there are some new errors on Beta4
>
> 	can'tfind root filesystem
>
> 	maybe you're right with your idea of an extra root folder, but i
> think if he can't find root filesystem, he also can't read fstab.
> 	maybe more ideas? :-)
> 	cheers 
> 	Oliver
>
> Links:
> ------
> [1] http://mail.kuehlbox.de/parse.php?redirect=<a href=
> [2] http://mail.kuehlbox.de/parse.php?redirect=<a href=
> [3] http://mail.kuehlbox.de/parse.php?redirect=<a href=
> [4] http://mail.kuehlbox.de/parse.php?redirect=<a href=
> [5] http://mail.kuehlbox.de/parse.php?redirect=<a href=
> [6] http://mail.kuehlbox.de/parse.php?redirect=<a href=
> [7] http://mail.kuehlbox.de/parse.php?redirect=<a href=
> [8] http://mail.kuehlbox.de/parse.php?redirect=<a href=
> [9] http://mail.kuehlbox.de/parse.php?redirect=<a href=
> [11] http://mail.kuehlbox.de/parse.php?redirect=<a href=
> [17] http://mail.kuehlbox.de/parse.php?redirect=<a href=
> [19] http://mail.kuehlbox.de/parse.php?redirect=<a href=
> _______________________________________________
> 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"
>   

Ok, so now I feel like a fool...
You're right... It's not a raidz, but it *should* have been one. I had 
tried MANY things and it was getting late (or early depending onm how 
you look at it) that night when I finally got the system up...

So, i'll take my system off line in the next few days and try rebuilding 
with a raidz...

I thought it was too good to be true

Paul


-----------------------------------------------------------------------------------
Fletcher Moorland Limited is a company registered in England and Wales. 
Registration number: 2984467. 
Registered office: Elenora Street, Stoke on Trent, Staffordshire, ST4 1QG. 
VAT Registration number: 478730606 
Telephone: 01782 411021 | Fax: 01782 744470 | http://www.fletchermoorland.co.uk 

From tinderbox at freebsd.org  Tue Sep  8 15:43:54 2009
From: tinderbox at freebsd.org (FreeBSD Tinderbox)
Date: Tue Sep  8 15:44:12 2009
Subject: [head tinderbox] failure on amd64/amd64
Message-ID: <200909081543.n88Fhrge095909@freebsd-current.sentex.ca>

TB --- 2009-09-08 15:25:00 - tinderbox 2.6 running on freebsd-current.sentex.ca
TB --- 2009-09-08 15:25:00 - starting HEAD tinderbox run for amd64/amd64
TB --- 2009-09-08 15:25:00 - cleaning the object tree
TB --- 2009-09-08 15:26:11 - cvsupping the source tree
TB --- 2009-09-08 15:26:11 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/amd64/amd64/supfile
TB --- 2009-09-08 15:31:55 - building world
TB --- 2009-09-08 15:31:55 - MAKEOBJDIRPREFIX=/obj
TB --- 2009-09-08 15:31:55 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2009-09-08 15:31:55 - TARGET=amd64
TB --- 2009-09-08 15:31:55 - TARGET_ARCH=amd64
TB --- 2009-09-08 15:31:55 - TZ=UTC
TB --- 2009-09-08 15:31:55 - __MAKE_CONF=/dev/null
TB --- 2009-09-08 15:31:55 - cd /src
TB --- 2009-09-08 15:31:55 - /usr/bin/make -B buildworld
>>> World build started on Tue Sep  8 15:31:56 UTC 2009
>>> 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
[...]
cc -O2 -pipe  -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/amd64 -DNLS -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/src/lib/libc -I/src/lib/libc/resolv -D_ACL_PRIVATE -DPOSIX_MISTAKE -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -DSYMBOL_VERSIONING -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/lib/libc/net/gethostbyht.c
cc -O2 -pipe  -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/amd64 -DNLS -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/src/lib/libc -I/src/lib/libc/resolv -D_ACL_PRIVATE -DPOSIX_MISTAKE -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -DSYMBOL_VERSIONING -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/lib/libc/net/gethostbynis.c
cc -O2 -pipe  -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/amd64 -DNLS -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/src/lib/libc -I/src/lib/libc/resolv -D_ACL_PRIVATE -DPOSIX_MISTAKE -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -DSYMBOL_VERSIONING -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/lib/libc/net/gethostnamadr.c
cc -O2 -pipe  -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/amd64 -DNLS -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/src/lib/libc -I/src/lib/libc/resolv -D_ACL_PRIVATE -DPOSIX_MISTAKE -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -DSYMBOL_VERSIONING -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/lib/libc/net/getifaddrs.c
/src/lib/libc/net/getifaddrs.c: In function 'getifaddrs':
/src/lib/libc/net/getifaddrs.c:168: error: 'XXX' undeclared (first use in this function)
/src/lib/libc/net/getifaddrs.c:168: error: (Each undeclared identifier is reported only once
/src/lib/libc/net/getifaddrs.c:168: error: for each function it appears in.)
*** Error code 1

Stop in /src/lib/libc.
*** Error code 1

Stop in /src.
*** Error code 1

Stop in /src.
*** Error code 1

Stop in /src.
*** Error code 1

Stop in /src.
TB --- 2009-09-08 15:43:53 - WARNING: /usr/bin/make returned exit code  1 
TB --- 2009-09-08 15:43:53 - ERROR: failed to build world
TB --- 2009-09-08 15:43:53 - 509.45 user 74.31 system 1133.00 real


http://tinderbox.des.no/tinderbox-head-HEAD-amd64-amd64.full
From stb at lassitu.de  Tue Sep  8 15:54:11 2009
From: stb at lassitu.de (Stefan Bethke)
Date: Tue Sep  8 15:54:18 2009
Subject: tzsetup and EST5EDT
In-Reply-To: <d2e731a10909080024p7f2f456bi2794a122e5333d6a@mail.gmail.com>
References: <d2e731a10909080024p7f2f456bi2794a122e5333d6a@mail.gmail.com>
Message-ID: <107BC6AC-0CF6-423F-8AD9-843DA1370035@lassitu.de>

Am 08.09.2009 um 09:24 schrieb grarpamp:

> Can't seem to set EST5EDT using the menus:
> wall: yes
> region: america
> country: united states
> zone: all eastern time choices, 1~10, come up with EST.
> Almost certain this is wrong.
> info google: EST EST5EDT
> Use
> 'cp /usr/share/zoneinfo/EST5EDT /etc/localtime'
> or
> 'echo y | tzsetup -s /usr/share/zoneinfo/EST5EDT'
> instead.
> RELENG_8

I get EDT for "1 - Eastern Time" when running sysinstall on an  
installed system.  Is your local clock on the right day?

If you think sysinstall should produce "EST5EDT", you're expecting the  
wrong thing.  For quite some time, it's given the time zone  
abbreviation appropriate to the chosen location for the current date  
and time.  I don't remember if that was ever different.


Stefan

-- 
Stefan Bethke <stb@lassitu.de>   Fon +49 151 14070811

From phk at phk.freebsd.dk  Tue Sep  8 16:16:53 2009
From: phk at phk.freebsd.dk (Poul-Henning Kamp)
Date: Tue Sep  8 16:17:06 2009
Subject: [head tinderbox] failure on amd64/amd64 
In-Reply-To: Your message of "Tue, 08 Sep 2009 15:43:53 GMT."
	<200909081543.n88Fhrge095909@freebsd-current.sentex.ca> 
Message-ID: <61228.1252425654@critter.freebsd.dk>


This ones mine.  I'm working on the proper fix to replace the
_NO_NAMESPACE_POLLUTION  hack.

I should have it cleared later tonight.

Poul-Henning

In message <200909081543.n88Fhrge095909@freebsd-current.sentex.ca>, FreeBSD Tin
derbox writes:
>TB --- 2009-09-08 15:25:00 - tinderbox 2.6 running on freebsd-current.sentex.ca
>TB --- 2009-09-08 15:25:00 - starting HEAD tinderbox run for amd64/amd64
>TB --- 2009-09-08 15:25:00 - cleaning the object tree
>TB --- 2009-09-08 15:26:11 - cvsupping the source tree
>TB --- 2009-09-08 15:26:11 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/amd64/amd64/supfile
>TB --- 2009-09-08 15:31:55 - building world
>TB --- 2009-09-08 15:31:55 - MAKEOBJDIRPREFIX=/obj
>TB --- 2009-09-08 15:31:55 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
>TB --- 2009-09-08 15:31:55 - TARGET=amd64
>TB --- 2009-09-08 15:31:55 - TARGET_ARCH=amd64
>TB --- 2009-09-08 15:31:55 - TZ=UTC
>TB --- 2009-09-08 15:31:55 - __MAKE_CONF=/dev/null
>TB --- 2009-09-08 15:31:55 - cd /src
>TB --- 2009-09-08 15:31:55 - /usr/bin/make -B buildworld
>>>> World build started on Tue Sep  8 15:31:56 UTC 2009
>>>> 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
>[...]
>cc -O2 -pipe  -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/amd64 -DNLS -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/src/lib/libc -I/src/lib/libc/resolv -D_ACL_PRIVATE -DPOSIX_MISTAKE -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN 
>-I/src/lib/libc/rpc -DYP -DNS_CACHING -DSYMBOL_VERSIONING -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/lib/libc/net/gethostbyht.c
>cc -O2 -pipe  -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/amd64 -DNLS -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/src/lib/libc -I/src/lib/libc/resolv -D_ACL_PRIVATE -DPOSIX_MISTAKE -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN 
>-I/src/lib/libc/rpc -DYP -DNS_CACHING -DSYMBOL_VERSIONING -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/lib/libc/net/gethostbynis.c
>cc -O2 -pipe  -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/amd64 -DNLS -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/src/lib/libc -I/src/lib/libc/resolv -D_ACL_PRIVATE -DPOSIX_MISTAKE -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN 
>-I/src/lib/libc/rpc -DYP -DNS_CACHING -DSYMBOL_VERSIONING -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/lib/libc/net/gethostnamadr.c
>cc -O2 -pipe  -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/amd64 -DNLS -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/src/lib/libc -I/src/lib/libc/resolv -D_ACL_PRIVATE -DPOSIX_MISTAKE -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN 
>-I/src/lib/libc/rpc -DYP -DNS_CACHING -DSYMBOL_VERSIONING -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/lib/libc/net/getifaddrs.c
>/src/lib/libc/net/getifaddrs.c: In function 'getifaddrs':
>/src/lib/libc/net/getifaddrs.c:168: error: 'XXX' undeclared (first use in this function)
>/src/lib/libc/net/getifaddrs.c:168: error: (Each undeclared identifier is reported only once
>/src/lib/libc/net/getifaddrs.c:168: error: for each function it appears in.)
>*** Error code 1
>
>Stop in /src/lib/libc.
>*** Error code 1
>
>Stop in /src.
>*** Error code 1
>
>Stop in /src.
>*** Error code 1
>
>Stop in /src.
>*** Error code 1
>
>Stop in /src.
>TB --- 2009-09-08 15:43:53 - WARNING: /usr/bin/make returned exit code  1 
>TB --- 2009-09-08 15:43:53 - ERROR: failed to build world
>TB --- 2009-09-08 15:43:53 - 509.45 user 74.31 system 1133.00 real
>
>
>http://tinderbox.des.no/tinderbox-head-HEAD-amd64-amd64.full
>_______________________________________________
>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"
>

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk@FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.
From mav at FreeBSD.org  Tue Sep  8 16:55:48 2009
From: mav at FreeBSD.org (Alexander Motin)
Date: Tue Sep  8 16:55:58 2009
Subject: Funding ODD support
In-Reply-To: <1252225381.00160049.1252212601@10.7.7.3>
References: <1252225381.00160049.1252212601@10.7.7.3>
Message-ID: <4AA68C8A.4060405@FreeBSD.org>

Harald Schmalzbauer wrote:
> I'm looking for somebody who has time and knowledge to fix ODD support
> in FreeBSD.
> I'm willing to sponsor a decent ammount.
> My problem is that I can't use FreeBSD for any task in which CD or DVD
> is involved.
> What I want is read/write support for any ATAPI/S-ATA ODD regarding
> ISO9660 and audio. Of course I'd love to have UDF support also, but for
> the beginning I'd be glad if FreeBSD could boot with an inserted audio
> CD. This has been a problem for more than two years now, and disabling
> DMA support for ata devices isn't a satisfying solution.
> 
> So if you think ypu can fix this and make growisofs and cdrtools working
> with ATAPI and SATA devices, please contact me.
> If we have working ODD support in 8.0-release I'll donate 100 extra bucks.

Funding is good, but could you first once more repeat what is your
problem? Which controller do you use? Which drive? Which disks and which
applications? Have you tried to use different controllers, drives,
disks, applications? I am asking because there quite a lot of people
successfully using ODD on FreeBSD.

-- 
Alexander Motin
From nevtic at area51.capnet.state.tx.us  Tue Sep  8 17:01:00 2009
From: nevtic at area51.capnet.state.tx.us (stuart cur)
Date: Tue Sep  8 17:01:08 2009
Subject: 8.0-B4, Broadcom bge0 not working, HP Proliant DL385, amd64
Message-ID: <alpine.BSF.2.00.0909081113220.98111@area51.capnet.state.tx.us>

In 8.0-B4 for amd64, bge does not recognize that there is an active 
ethernet connection on bge0.  Switching the cable to bge1 works correctly.

This seems to be the same issue as reported on July 21 by Oyvind Rakvag, 
but I saw no response to that report.

Attached are the dmesg.boot, /var/log/messages, and output of pciconf -lv 
from the very first boot.

stu
-------------- next part --------------
Sep  8 15:51:17  newsyslog[775]: logfile first created
Sep  8 15:51:17  syslogd: kernel boot file is /boot/kernel/kernel
Sep  8 15:51:17  kernel: Copyright (c) 1992-2009 The FreeBSD Project.
Sep  8 15:51:17  kernel: Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
Sep  8 15:51:17  kernel: The Regents of the University of California. All rights reserved.
Sep  8 15:51:17  kernel: FreeBSD is a registered trademark of The FreeBSD Foundation.
Sep  8 15:51:17  kernel: FreeBSD 8.0-BETA4 #0: Sun Sep  6 04:44:31 UTC 2009
Sep  8 15:51:17  kernel: root@mason.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC
Sep  8 15:51:17  kernel: WARNING: WITNESS option enabled, expect reduced performance.
Sep  8 15:51:17  kernel: Timecounter "i8254" frequency 1193182 Hz quality 0
Sep  8 15:51:17  kernel: CPU: AMD Opteron(tm) Processor 270 (2004.55-MHz K8-class CPU)
Sep  8 15:51:17  kernel: Origin = "AuthenticAMD"  Id = 0x20f12  Stepping = 2
Sep  8 15:51:17  kernel: Features=0x178bfbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,MMX,FXSR,SSE,SSE2,HTT>
Sep  8 15:51:17  kernel: Features2=0x1<SSE3>
Sep  8 15:51:17  kernel: AMD Features=0xe2500800<SYSCALL,NX,MMX+,FFXSR,LM,3DNow!+,3DNow!>
Sep  8 15:51:17  kernel: AMD Features2=0x2<CMP>
Sep  8 15:51:17  kernel: real memory  = 2147483648 (2048 MB)
Sep  8 15:51:17  kernel: avail memory = 2054406144 (1959 MB)
Sep  8 15:51:17  kernel: ACPI APIC Table: <HP     00000083>
Sep  8 15:51:17  kernel: FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs
Sep  8 15:51:17  kernel: FreeBSD/SMP: 1 package(s) x 2 core(s)
Sep  8 15:51:17  kernel: cpu0 (BSP): APIC ID:  0
Sep  8 15:51:17  kernel: cpu1 (AP): APIC ID:  1
Sep  8 15:51:17  kernel: ACPI Warning: Invalid length for Pm1aControlBlock: 32, using default 16 20090521 tbfadt-707
Sep  8 15:51:17  kernel: ACPI Warning: Invalid length for Pm1bControlBlock: 32, using default 16 20090521 tbfadt-707
Sep  8 15:51:17  kernel: MADT: Forcing active-low polarity and level trigger for SCI
Sep  8 15:51:17  kernel: ioapic0 <Version 1.1> irqs 0-23 on motherboard
Sep  8 15:51:17  kernel: ioapic1 <Version 1.1> irqs 24-27 on motherboard
Sep  8 15:51:17  kernel: ioapic2 <Version 1.1> irqs 28-31 on motherboard
Sep  8 15:51:17  kernel: ioapic3 <Version 1.1> irqs 32-35 on motherboard
Sep  8 15:51:17  kernel: ioapic4 <Version 1.1> irqs 36-39 on motherboard
Sep  8 15:51:17  kernel: kbd1 at kbdmux0
Sep  8 15:51:17  kernel: acpi0: <HP A05> on motherboard
Sep  8 15:51:17  kernel: acpi0: [ITHREAD]
Sep  8 15:51:17  kernel: acpi0: Power Button (fixed)
Sep  8 15:51:17  kernel: Timecounter "ACPI-safe" frequency 3579545 Hz quality 850
Sep  8 15:51:17  kernel: acpi_timer0: <32-bit timer at 3.579545MHz> port 0x908-0x90b on acpi0
Sep  8 15:51:17  kernel: pcib0: <ACPI Host-PCI bridge> on acpi0
Sep  8 15:51:17  kernel: pci0: <ACPI PCI bus> on pcib0
Sep  8 15:51:17  kernel: pcib1: <ACPI PCI-PCI bridge> at device 3.0 on pci0
Sep  8 15:51:17  kernel: pci1: <ACPI PCI bus> on pcib1
Sep  8 15:51:17  kernel: ohci0: <OHCI (generic) USB controller> mem 0xf7cf0000-0xf7cf0fff irq 19 at device 0.0 on pci1
Sep  8 15:51:17  kernel: ohci0: [ITHREAD]
Sep  8 15:51:17  kernel: usbus0: <OHCI (generic) USB controller> on ohci0
Sep  8 15:51:17  kernel: ohci1: <OHCI (generic) USB controller> mem 0xf7ce0000-0xf7ce0fff irq 19 at device 0.1 on pci1
Sep  8 15:51:17  kernel: ohci1: [ITHREAD]
Sep  8 15:51:17  kernel: usbus1: <OHCI (generic) USB controller> on ohci1
Sep  8 15:51:17  kernel: pci1: <base peripheral> at device 2.0 (no driver attached)
Sep  8 15:51:17  kernel: pci1: <base peripheral> at device 2.2 (no driver attached)
Sep  8 15:51:17  kernel: vgapci0: <VGA-compatible display> port 0x4400-0x44ff mem 0xf6000000-0xf6ffffff,0xf5ff0000-0xf5ff0fff at device 3.0 on pci1
Sep  8 15:51:17  kernel: isab0: <PCI-ISA bridge> at device 4.0 on pci0
Sep  8 15:51:17  kernel: isa0: <ISA bus> on isab0
Sep  8 15:51:17  kernel: atapci0: <AMD 8111 UDMA133 controller> port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x2000-0x200f at device 4.1 on pci0
Sep  8 15:51:17  kernel: ata0: <ATA channel 0> on atapci0
Sep  8 15:51:17  kernel: ata0: [ITHREAD]
Sep  8 15:51:17  kernel: ata1: <ATA channel 1> on atapci0
Sep  8 15:51:17  kernel: ata1: [ITHREAD]
Sep  8 15:51:17  kernel: pci0: <bridge> at device 4.3 (no driver attached)
Sep  8 15:51:17  kernel: pcib2: <ACPI PCI-PCI bridge> at device 7.0 on pci0
Sep  8 15:51:17  kernel: pci2: <ACPI PCI bus> on pcib2
Sep  8 15:51:17  kernel: ciss0: <HP Smart Array 6i> port 0x5000-0x50ff mem 0xf7df0000-0xf7df1fff,0xf7d80000-0xf7dbffff irq 24 at device 4.0 on pci2
Sep  8 15:51:17  kernel: ciss0: PERFORMANT Transport
Sep  8 15:51:17  kernel: ciss0: [ITHREAD]
Sep  8 15:51:17  kernel: pcib3: <ACPI PCI-PCI bridge> at device 8.0 on pci0
Sep  8 15:51:17  kernel: pci3: <ACPI PCI bus> on pcib3
Sep  8 15:51:17  kernel: bge0: <HP NC7782 Gigabit Server Adapter, ASIC rev. 0x2100> mem 0xf7ef0000-0xf7efffff irq 28 at device 6.0 on pci3
Sep  8 15:51:17  kernel: miibus0: <MII bus> on bge0
Sep  8 15:51:17  kernel: brgphy0: <BCM5704 10/100/1000baseTX PHY> PHY 1 on miibus0
Sep  8 15:51:17  kernel: brgphy0:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto
Sep  8 15:51:17  kernel: bge0: Ethernet address: 00:17:a4:a7:eb:e4
Sep  8 15:51:17  kernel: bge0: [ITHREAD]
Sep  8 15:51:17  kernel: bge1: <HP NC7782 Gigabit Server Adapter, ASIC rev. 0x2100> mem 0xf7ee0000-0xf7eeffff irq 29 at device 6.1 on pci3
Sep  8 15:51:17  kernel: miibus1: <MII bus> on bge1
Sep  8 15:51:17  kernel: brgphy1: <BCM5704 10/100/1000baseTX PHY> PHY 1 on miibus1
Sep  8 15:51:17  kernel: brgphy1:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto
Sep  8 15:51:17  kernel: bge1: Ethernet address: 00:17:a4:a7:eb:e3
Sep  8 15:51:17  kernel: bge1: [ITHREAD]
Sep  8 15:51:17  kernel: pcib4: <ACPI Host-PCI bridge> on acpi0
Sep  8 15:51:17  kernel: pci4: <ACPI PCI bus> on pcib4
Sep  8 15:51:17  kernel: pcib5: <ACPI PCI-PCI bridge> at device 9.0 on pci4
Sep  8 15:51:17  kernel: pci5: <ACPI PCI bus> on pcib5
Sep  8 15:51:17  kernel: rl0: <RealTek 8139 10/100BaseTX> port 0x6000-0x60ff mem 0xf7ff0000-0xf7ff00ff irq 32 at device 8.0 on pci5
Sep  8 15:51:17  kernel: miibus2: <MII bus> on rl0
Sep  8 15:51:17  kernel: rlphy0: <RealTek internal media interface> PHY 0 on miibus2
Sep  8 15:51:17  kernel: rlphy0:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
Sep  8 15:51:17  kernel: rl0: Ethernet address: 00:40:f4:ed:99:ec
Sep  8 15:51:17  kernel: rl0: [ITHREAD]
Sep  8 15:51:17  kernel: pcib6: <ACPI PCI-PCI bridge> at device 10.0 on pci4
Sep  8 15:51:17  kernel: pci6: <ACPI PCI bus> on pcib6
Sep  8 15:51:17  kernel: atkbdc0: <Keyboard controller (i8042)> port 0x60,0x64 irq 1 on acpi0
Sep  8 15:51:17  kernel: atkbd0: <AT Keyboard> irq 1 on atkbdc0
Sep  8 15:51:17  kernel: kbd0 at atkbd0
Sep  8 15:51:17  kernel: atkbd0: [GIANT-LOCKED]
Sep  8 15:51:17  kernel: atkbd0: [ITHREAD]
Sep  8 15:51:17  kernel: psm0: <PS/2 Mouse> irq 12 on atkbdc0
Sep  8 15:51:17  kernel: psm0: [GIANT-LOCKED]
Sep  8 15:51:17  kernel: psm0: [ITHREAD]
Sep  8 15:51:17  kernel: psm0: model Generic PS/2 mouse, device ID 0
Sep  8 15:51:17  kernel: uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0
Sep  8 15:51:17  kernel: uart0: [FILTER]
Sep  8 15:51:17  kernel: fdc0: <floppy drive controller (FDE)> port 0x3f2-0x3f5 irq 6 drq 2 on acpi0
Sep  8 15:51:17  kernel: fdc0: [FILTER]
Sep  8 15:51:17  kernel: cpu0: <ACPI CPU> on acpi0
Sep  8 15:51:17  kernel: powernow0: <Cool`n'Quiet K8> on cpu0
Sep  8 15:51:17  kernel: cpu1: <ACPI CPU> on acpi0
Sep  8 15:51:17  kernel: powernow1: <Cool`n'Quiet K8> on cpu1
Sep  8 15:51:17  kernel: orm0: <ISA Option ROMs> at iomem 0xc0000-0xc7fff,0xc8000-0xcbfff,0xee000-0xeffff on isa0
Sep  8 15:51:17  kernel: sc0: <System console> at flags 0x100 on isa0
Sep  8 15:51:17  kernel: sc0: VGA <16 virtual consoles, flags=0x300>
Sep  8 15:51:17  kernel: vga0: <Generic ISA VGA> at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0
Sep  8 15:51:17  kernel: atrtc0: <AT Real Time Clock> at port 0x70 irq 8 on isa0
Sep  8 15:51:17  kernel: ppc0: cannot reserve I/O port range
Sep  8 15:51:17  kernel: uart1: <Non-standard ns8250 class UART with FIFOs> at port 0x2f8-0x2ff irq 3 on isa0
Sep  8 15:51:17  kernel: uart1: [FILTER]
Sep  8 15:51:17  kernel: Timecounters tick every 1.000 msec
Sep  8 15:51:17  kernel: usbus0: 12Mbps Full Speed USB v1.0
Sep  8 15:51:17  kernel: usbus1: 12Mbps Full Speed USB v1.0
Sep  8 15:51:17  kernel: ugen0.1: <AMD> at usbus0
Sep  8 15:51:17  kernel: uhub0: <AMD OHCI root HUB, class 9/0, rev 1.00/1.00, addr 1> on usbus0
Sep  8 15:51:17  kernel: ugen1.1: <AMD> at usbus1
Sep  8 15:51:17  kernel: uhub1: <AMD OHCI root HUB, class 9/0, rev 1.00/1.00, addr 1> on usbus1
Sep  8 15:51:17  kernel: acd0: CDRW <DW-224E-R/C.AB> at ata0-master UDMA33
Sep  8 15:51:17  kernel: uhub0: 3 ports with 3 removable, self powered
Sep  8 15:51:17  kernel: uhub1: 3 ports with 3 removable, self powered
Sep  8 15:51:17  kernel: da0 at ciss0 bus 0 target 0 lun 0
Sep  8 15:51:17  kernel: da0: <COMPAQ RAID 1  VOLUME OK> Fixed Direct Access SCSI-4 device 
Sep  8 15:51:17  kernel: da0: 135.168MB/s transfers
Sep  8 15:51:17  kernel: da0: Command Queueing enabled
Sep  8 15:51:17  kernel: da0: 70001MB (143363040 512 byte sectors: 255H 32S/T 17569C)
Sep  8 15:51:17  kernel: da1 at ciss0 bus 0 target 1 lun 0
Sep  8 15:51:17  kernel: da1: <COMPAQ RAID 1  VOLUME OK> Fixed Direct Access SCSI-4 device 
Sep  8 15:51:17  kernel: da1: 135.168MB/s transfers
Sep  8 15:51:17  kernel: da1: Command Queueing enabled
Sep  8 15:51:17  kernel: da1: 286097MB (585928220 512 byte sectors: 255H 32S/T 65535C)
Sep  8 15:51:17  kernel: SMP: AP CPU #1 Launched!
Sep  8 15:51:17  kernel: WARNING: WITNESS option enabled, expect reduced performance.
Sep  8 15:51:17  kernel: GEOM: da0: partition 1 does not start on a track boundary.
Sep  8 15:51:17  kernel: GEOM: da0: partition 1 does not end on a track boundary.
Sep  8 15:51:17  kernel: GEOM: da0s1: geometry does not match label (255h,63s != 255h,32s).
Sep  8 15:51:17  kernel: GEOM: da1: partition 1 does not start on a track boundary.
Sep  8 15:51:17  kernel: GEOM: da1: partition 1 does not end on a track boundary.
Sep  8 15:51:17  kernel: GEOM: da1s1: geometry does not match label (255h,63s != 255h,32s).
Sep  8 15:51:17  kernel: Trying to mount root from ufs:/dev/da0s1a
Sep  8 15:51:28  login: ROOT LOGIN (root) ON ttyv1
Sep  8 15:52:12  kernel: bge1: link state changed to UP
Sep  8 15:52:51  kernel: bge1: link state changed to DOWN
Sep  8 15:52:53  kernel: bge1: link state changed to UP
Sep  8 15:53:49  kernel: bge1: promiscuous mode enabled
Sep  8 15:54:12  kernel: bge1: promiscuous mode disabled
Sep  8 15:59:19  root: Unknown USB device: vendor 0x13fe product 0x1a21 bus uhub1
Sep  8 15:59:19  kernel: ugen1.2: <vendor 0x13fe> at usbus1
Sep  8 15:59:19  kernel: umass0: <vendor 0x13fe USB DISK Pro, class 0/0, rev 2.00/1.00, addr 2> on usbus1
Sep  8 15:59:19  kernel: umass0:  SCSI over Bulk-Only; quirks = 0x0000
Sep  8 15:59:20  kernel: umass0:3:0:-1: Attached to scbus3
Sep  8 15:59:21  kernel: (probe0:umass-sim0:0:0:0): TEST UNIT READY. CDB: 0 0 0 0 0 0 
Sep  8 15:59:21  kernel: (probe0:umass-sim0:0:0:0): CAM Status: SCSI Status Error
Sep  8 15:59:21  kernel: (probe0:umass-sim0:0:0:0): SCSI Status: Check Condition
Sep  8 15:59:21  kernel: (probe0:umass-sim0:0:0:0): UNIT ATTENTION asc:28,0
Sep  8 15:59:21  kernel: (probe0:umass-sim0:0:0:0): Not ready to ready change, medium may have changed
Sep  8 15:59:21  kernel: (probe0:umass-sim0:0:0:0): Retrying Command (per Sense Data)
Sep  8 15:59:21  kernel: da2 at umass-sim0 bus 0 target 0 lun 0
Sep  8 15:59:21  kernel: da2: < USB DISK Pro PMAP> Removable Direct Access SCSI-0 device 
Sep  8 15:59:21  kernel: da2: 1.000MB/s transfers
Sep  8 15:59:21  kernel: da2: 1941MB (3976192 512 byte sectors: 255H 63S/T 247C)
Sep  8 15:59:21  kernel: (probe0:umass-sim0:0:0:1): TEST UNIT READY. CDB: 0 20 0 0 0 0 
Sep  8 15:59:21  kernel: (probe0:umass-sim0:0:0:1): CAM Status: SCSI Status Error
Sep  8 15:59:21  kernel: (probe0:umass-sim0:0:0:1): SCSI Status: Check Condition
Sep  8 15:59:21  kernel: (probe0:umass-sim0:0:0:1): UNIT ATTENTION asc:28,0
Sep  8 15:59:21  kernel: (probe0:umass-sim0:0:0:1): Not ready to ready change, medium may have changed
Sep  8 15:59:21  kernel: (probe0:umass-sim0:0:0:1): Retrying Command (per Sense Data)
Sep  8 15:59:21  kernel: da3 at umass-sim0 bus 0 target 0 lun 1
Sep  8 15:59:21  kernel: da3: < USB DISK Pro PMAP> Removable Direct Access SCSI-0 device 
Sep  8 15:59:21  kernel: da3: 1.000MB/s transfers
Sep  8 15:59:21  kernel: da3: 24MB (50176 512 byte sectors: 64H 32S/T 24C)
Sep  8 15:59:22  kernel: GEOM: da2: partition 1 does not start on a track boundary.
Sep  8 15:59:22  kernel: GEOM: da2: partition 1 does not end on a track boundary.
-------------- next part --------------
Copyright (c) 1992-2009 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
	The Regents of the University of California. All rights reserved.
FreeBSD is a registered trademark of The FreeBSD Foundation.
FreeBSD 8.0-BETA4 #0: Sun Sep  6 04:44:31 UTC 2009
    root@mason.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC
WARNING: WITNESS option enabled, expect reduced performance.
Timecounter "i8254" frequency 1193182 Hz quality 0
CPU: AMD Opteron(tm) Processor 270 (2004.55-MHz K8-class CPU)
  Origin = "AuthenticAMD"  Id = 0x20f12  Stepping = 2
  Features=0x178bfbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,MMX,FXSR,SSE,SSE2,HTT>
  Features2=0x1<SSE3>
  AMD Features=0xe2500800<SYSCALL,NX,MMX+,FFXSR,LM,3DNow!+,3DNow!>
  AMD Features2=0x2<CMP>
real memory  = 2147483648 (2048 MB)
avail memory = 2054406144 (1959 MB)
ACPI APIC Table: <HP     00000083>
FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs
FreeBSD/SMP: 1 package(s) x 2 core(s)
 cpu0 (BSP): APIC ID:  0
 cpu1 (AP): APIC ID:  1
ACPI Warning: Invalid length for Pm1aControlBlock: 32, using default 16 20090521 tbfadt-707
ACPI Warning: Invalid length for Pm1bControlBlock: 32, using default 16 20090521 tbfadt-707
MADT: Forcing active-low polarity and level trigger for SCI
ioapic0 <Version 1.1> irqs 0-23 on motherboard
ioapic1 <Version 1.1> irqs 24-27 on motherboard
ioapic2 <Version 1.1> irqs 28-31 on motherboard
ioapic3 <Version 1.1> irqs 32-35 on motherboard
ioapic4 <Version 1.1> irqs 36-39 on motherboard
kbd1 at kbdmux0
acpi0: <HP A05> on motherboard
acpi0: [ITHREAD]
acpi0: Power Button (fixed)
Timecounter "ACPI-safe" frequency 3579545 Hz quality 850
acpi_timer0: <32-bit timer at 3.579545MHz> port 0x908-0x90b on acpi0
pcib0: <ACPI Host-PCI bridge> on acpi0
pci0: <ACPI PCI bus> on pcib0
pcib1: <ACPI PCI-PCI bridge> at device 3.0 on pci0
pci1: <ACPI PCI bus> on pcib1
ohci0: <OHCI (generic) USB controller> mem 0xf7cf0000-0xf7cf0fff irq 19 at device 0.0 on pci1
ohci0: [ITHREAD]
usbus0: <OHCI (generic) USB controller> on ohci0
ohci1: <OHCI (generic) USB controller> mem 0xf7ce0000-0xf7ce0fff irq 19 at device 0.1 on pci1
ohci1: [ITHREAD]
usbus1: <OHCI (generic) USB controller> on ohci1
pci1: <base peripheral> at device 2.0 (no driver attached)
pci1: <base peripheral> at device 2.2 (no driver attached)
vgapci0: <VGA-compatible display> port 0x4400-0x44ff mem 0xf6000000-0xf6ffffff,0xf5ff0000-0xf5ff0fff at device 3.0 on pci1
isab0: <PCI-ISA bridge> at device 4.0 on pci0
isa0: <ISA bus> on isab0
atapci0: <AMD 8111 UDMA133 controller> port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x2000-0x200f at device 4.1 on pci0
ata0: <ATA channel 0> on atapci0
ata0: [ITHREAD]
ata1: <ATA channel 1> on atapci0
ata1: [ITHREAD]
pci0: <bridge> at device 4.3 (no driver attached)
pcib2: <ACPI PCI-PCI bridge> at device 7.0 on pci0
pci2: <ACPI PCI bus> on pcib2
ciss0: <HP Smart Array 6i> port 0x5000-0x50ff mem 0xf7df0000-0xf7df1fff,0xf7d80000-0xf7dbffff irq 24 at device 4.0 on pci2
ciss0: PERFORMANT Transport
ciss0: [ITHREAD]
pcib3: <ACPI PCI-PCI bridge> at device 8.0 on pci0
pci3: <ACPI PCI bus> on pcib3
bge0: <HP NC7782 Gigabit Server Adapter, ASIC rev. 0x2100> mem 0xf7ef0000-0xf7efffff irq 28 at device 6.0 on pci3
miibus0: <MII bus> on bge0
brgphy0: <BCM5704 10/100/1000baseTX PHY> PHY 1 on miibus0
brgphy0:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto
bge0: Ethernet address: 00:17:a4:a7:eb:e4
bge0: [ITHREAD]
bge1: <HP NC7782 Gigabit Server Adapter, ASIC rev. 0x2100> mem 0xf7ee0000-0xf7eeffff irq 29 at device 6.1 on pci3
miibus1: <MII bus> on bge1
brgphy1: <BCM5704 10/100/1000baseTX PHY> PHY 1 on miibus1
brgphy1:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto
bge1: Ethernet address: 00:17:a4:a7:eb:e3
bge1: [ITHREAD]
pcib4: <ACPI Host-PCI bridge> on acpi0
pci4: <ACPI PCI bus> on pcib4
pcib5: <ACPI PCI-PCI bridge> at device 9.0 on pci4
pci5: <ACPI PCI bus> on pcib5
rl0: <RealTek 8139 10/100BaseTX> port 0x6000-0x60ff mem 0xf7ff0000-0xf7ff00ff irq 32 at device 8.0 on pci5
miibus2: <MII bus> on rl0
rlphy0: <RealTek internal media interface> PHY 0 on miibus2
rlphy0:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
rl0: Ethernet address: 00:40:f4:ed:99:ec
rl0: [ITHREAD]
pcib6: <ACPI PCI-PCI bridge> at device 10.0 on pci4
pci6: <ACPI PCI bus> on pcib6
atkbdc0: <Keyboard controller (i8042)> port 0x60,0x64 irq 1 on acpi0
atkbd0: <AT Keyboard> irq 1 on atkbdc0
kbd0 at atkbd0
atkbd0: [GIANT-LOCKED]
atkbd0: [ITHREAD]
psm0: <PS/2 Mouse> irq 12 on atkbdc0
psm0: [GIANT-LOCKED]
psm0: [ITHREAD]
psm0: model Generic PS/2 mouse, device ID 0
uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0
uart0: [FILTER]
fdc0: <floppy drive controller (FDE)> port 0x3f2-0x3f5 irq 6 drq 2 on acpi0
fdc0: [FILTER]
cpu0: <ACPI CPU> on acpi0
powernow0: <Cool`n'Quiet K8> on cpu0
cpu1: <ACPI CPU> on acpi0
powernow1: <Cool`n'Quiet K8> on cpu1
orm0: <ISA Option ROMs> at iomem 0xc0000-0xc7fff,0xc8000-0xcbfff,0xee000-0xeffff on isa0
sc0: <System console> at flags 0x100 on isa0
sc0: VGA <16 virtual consoles, flags=0x300>
vga0: <Generic ISA VGA> at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0
atrtc0: <AT Real Time Clock> at port 0x70 irq 8 on isa0
ppc0: cannot reserve I/O port range
uart1: <Non-standard ns8250 class UART with FIFOs> at port 0x2f8-0x2ff irq 3 on isa0
uart1: [FILTER]
Timecounters tick every 1.000 msec
usbus0: 12Mbps Full Speed USB v1.0
usbus1: 12Mbps Full Speed USB v1.0
ugen0.1: <AMD> at usbus0
uhub0: <AMD OHCI root HUB, class 9/0, rev 1.00/1.00, addr 1> on usbus0
ugen1.1: <AMD> at usbus1
uhub1: <AMD OHCI root HUB, class 9/0, rev 1.00/1.00, addr 1> on usbus1
acd0: CDRW <DW-224E-R/C.AB> at ata0-master UDMA33
uhub0: 3 ports with 3 removable, self powered
uhub1: 3 ports with 3 removable, self powered
da0 at ciss0 bus 0 target 0 lun 0
da0: <COMPAQ RAID 1  VOLUME OK> Fixed Direct Access SCSI-4 device 
da0: 135.168MB/s transfers
da0: Command Queueing enabled
da0: 70001MB (143363040 512 byte sectors: 255H 32S/T 17569C)
da1 at ciss0 bus 0 target 1 lun 0
da1: <COMPAQ RAID 1  VOLUME OK> Fixed Direct Access SCSI-4 device 
da1: 135.168MB/s transfers
da1: Command Queueing enabled
da1: 286097MB (585928220 512 byte sectors: 255H 32S/T 65535C)
SMP: AP CPU #1 Launched!
WARNING: WITNESS option enabled, expect reduced performance.
GEOM: da0: partition 1 does not start on a track boundary.
GEOM: da0: partition 1 does not end on a track boundary.
GEOM: da0s1: geometry does not match label (255h,63s != 255h,32s).
GEOM: da1: partition 1 does not start on a track boundary.
GEOM: da1: partition 1 does not end on a track boundary.
GEOM: da1s1: geometry does not match label (255h,63s != 255h,32s).
Trying to mount root from ufs:/dev/da0s1a
-------------- next part --------------
pcib1@pci0:0:3:0:	class=0x060400 card=0x00000000 chip=0x74601022 rev=0x07 hdr=0x01
    vendor     = 'Advanced Micro Devices (AMD)'
    device     = 'PCI Bridge (AMD-8111)'
    class      = bridge
    subclass   = PCI-PCI
isab0@pci0:0:4:0:	class=0x060100 card=0x32030e11 chip=0x74681022 rev=0x05 hdr=0x00
    vendor     = 'Advanced Micro Devices (AMD)'
    device     = 'LPC Bridge (AMD-8111)'
    class      = bridge
    subclass   = PCI-ISA
atapci0@pci0:0:4:1:	class=0x01018a card=0x32040e11 chip=0x74691022 rev=0x03 hdr=0x00
    vendor     = 'Advanced Micro Devices (AMD)'
    device     = 'UltraATA/133 Controller (AMD-8111)'
    class      = mass storage
    subclass   = ATA
none0@pci0:0:4:3:	class=0x068000 card=0x32050e11 chip=0x746b1022 rev=0x05 hdr=0x00
    vendor     = 'Advanced Micro Devices (AMD)'
    device     = 'AMD-8111 ACPI System Management Controller'
    class      = bridge
pcib2@pci0:0:7:0:	class=0x060400 card=0x00000000 chip=0x74501022 rev=0x12 hdr=0x01
    vendor     = 'Advanced Micro Devices (AMD)'
    device     = 'PCI-X Bridge (AMD-8131)'
    class      = bridge
    subclass   = PCI-PCI
ioapic0@pci0:0:7:1:	class=0x080010 card=0x00000000 chip=0x74511022 rev=0x01 hdr=0x00
    vendor     = 'Advanced Micro Devices (AMD)'
    device     = 'PCI-X IOAPIC (AMD-8131)'
    class      = base peripheral
    subclass   = interrupt controller
pcib3@pci0:0:8:0:	class=0x060400 card=0x00000000 chip=0x74501022 rev=0x12 hdr=0x01
    vendor     = 'Advanced Micro Devices (AMD)'
    device     = 'PCI-X Bridge (AMD-8131)'
    class      = bridge
    subclass   = PCI-PCI
ioapic1@pci0:0:8:1:	class=0x080010 card=0x00000000 chip=0x74511022 rev=0x01 hdr=0x00
    vendor     = 'Advanced Micro Devices (AMD)'
    device     = 'PCI-X IOAPIC (AMD-8131)'
    class      = base peripheral
    subclass   = interrupt controller
hostb0@pci0:0:24:0:	class=0x060000 card=0x00000000 chip=0x11001022 rev=0x00 hdr=0x00
    vendor     = 'Advanced Micro Devices (AMD)'
    device     = 'Athlon64/Opteron/Sempron (K8 Family) HyperTransport Technology Configuration'
    class      = bridge
    subclass   = HOST-PCI
hostb1@pci0:0:24:1:	class=0x060000 card=0x00000000 chip=0x11011022 rev=0x00 hdr=0x00
    vendor     = 'Advanced Micro Devices (AMD)'
    device     = 'Athlon64/Opteron/Sempron (K8 Family) Address Map'
    class      = bridge
    subclass   = HOST-PCI
hostb2@pci0:0:24:2:	class=0x060000 card=0x00000000 chip=0x11021022 rev=0x00 hdr=0x00
    vendor     = 'Advanced Micro Devices (AMD)'
    device     = 'Athlon64/Opteron/Sempron (K8 Family) DRAM Controller'
    class      = bridge
    subclass   = HOST-PCI
hostb3@pci0:0:24:3:	class=0x060000 card=0x00000000 chip=0x11031022 rev=0x00 hdr=0x00
    vendor     = 'Advanced Micro Devices (AMD)'
    device     = 'Athlon64/Opteron/Sempron (K8 Family) Miscellaneous Control'
    class      = bridge
    subclass   = HOST-PCI
ohci0@pci0:1:0:0:	class=0x0c0310 card=0x32020e11 chip=0x74641022 rev=0x0b hdr=0x00
    vendor     = 'Advanced Micro Devices (AMD)'
    device     = 'USB OpenHCI Host Controller (AMD-8111)'
    class      = serial bus
    subclass   = USB
ohci1@pci0:1:0:1:	class=0x0c0310 card=0x32020e11 chip=0x74641022 rev=0x0b hdr=0x00
    vendor     = 'Advanced Micro Devices (AMD)'
    device     = 'USB OpenHCI Host Controller (AMD-8111)'
    class      = serial bus
    subclass   = USB
none1@pci0:1:2:0:	class=0x088000 card=0xb2060e11 chip=0xb2030e11 rev=0x01 hdr=0x00
    vendor     = 'Compaq Computer Corp (Now owned by Hewlett-Packard)'
    device     = 'Integrated Lights Out Processor (iLo)'
    class      = base peripheral
none2@pci0:1:2:2:	class=0x088000 card=0xb2060e11 chip=0xb2040e11 rev=0x01 hdr=0x00
    vendor     = 'Compaq Computer Corp (Now owned by Hewlett-Packard)'
    device     = 'Integrated Lights Out Processor (iLo)'
    class      = base peripheral
vgapci0@pci0:1:3:0:	class=0x030000 card=0x001e0e11 chip=0x47521002 rev=0x27 hdr=0x00
    vendor     = 'ATI Technologies Inc. / Advanced Micro Devices, Inc.'
    device     = 'ATI On-Board VGA for HP Proliant 350 G3 (Rage XL PCI)'
    class      = display
    subclass   = VGA
ciss0@pci0:2:4:0:	class=0x010400 card=0x40910e11 chip=0x00460e11 rev=0x01 hdr=0x00
    vendor     = 'Compaq Computer Corp (Now owned by Hewlett-Packard)'
    device     = 'Smart Array 64xx/6i Controller'
    class      = mass storage
    subclass   = RAID
bge0@pci0:3:6:0:	class=0x020000 card=0x00d00e11 chip=0x164814e4 rev=0x10 hdr=0x00
    vendor     = 'Broadcom Corporation'
    device     = 'NetXtreme Dual Gigabit Adapter (BCM5704)'
    class      = network
    subclass   = ethernet
bge1@pci0:3:6:1:	class=0x020000 card=0x00d00e11 chip=0x164814e4 rev=0x10 hdr=0x00
    vendor     = 'Broadcom Corporation'
    device     = 'NetXtreme Dual Gigabit Adapter (BCM5704)'
    class      = network
    subclass   = ethernet
pcib5@pci0:4:9:0:	class=0x060400 card=0x00000000 chip=0x74501022 rev=0x12 hdr=0x01
    vendor     = 'Advanced Micro Devices (AMD)'
    device     = 'PCI-X Bridge (AMD-8131)'
    class      = bridge
    subclass   = PCI-PCI
ioapic2@pci0:4:9:1:	class=0x080010 card=0x00000000 chip=0x74511022 rev=0x01 hdr=0x00
    vendor     = 'Advanced Micro Devices (AMD)'
    device     = 'PCI-X IOAPIC (AMD-8131)'
    class      = base peripheral
    subclass   = interrupt controller
pcib6@pci0:4:10:0:	class=0x060400 card=0x00000000 chip=0x74501022 rev=0x12 hdr=0x01
    vendor     = 'Advanced Micro Devices (AMD)'
    device     = 'PCI-X Bridge (AMD-8131)'
    class      = bridge
    subclass   = PCI-PCI
ioapic3@pci0:4:10:1:	class=0x080010 card=0x00000000 chip=0x74511022 rev=0x01 hdr=0x00
    vendor     = 'Advanced Micro Devices (AMD)'
    device     = 'PCI-X IOAPIC (AMD-8131)'
    class      = base peripheral
    subclass   = interrupt controller
rl0@pci0:5:8:0:	class=0x020000 card=0xc10f1259 chip=0x813910ec rev=0x10 hdr=0x00
    vendor     = 'Realtek Semiconductor'
    device     = 'Realtek RTL8139 Family PCI Fast Ethernet NIC (RTL-8139/8139C/8139C)'
    class      = network
    subclass   = ethernet
From killing at multiplay.co.uk  Tue Sep  8 17:23:50 2009
From: killing at multiplay.co.uk (Steven Hartland)
Date: Tue Sep  8 17:23:56 2009
Subject: 8.0-B4, Broadcom bge0 not working, HP Proliant DL385, amd64
References: <alpine.BSF.2.00.0909081113220.98111@area51.capnet.state.tx.us>
Message-ID: <7147C6D9FE26411197548D67E5025D75@multiplay.co.uk>

I suspect its the same reason for issues with had with the subjects:
FreeBSD 7.0-RELEASE amd64 on Dell M600 Blade
kern/134658: [bce] bce driver fails on PowerEdge m610 blade.
Quote: "David Christensen" <davidch@broadcom.com>

I've enquired about this recently but havent seen a response as
yet.

    Regards
    Steve

> Sorry, this is the 5709S and I haven't had an opportunity to
> implement this PHY yet.  Unfortunately it's more than just a
> change to miidevs since the SerDes is actually an IEEE clause
> 45 compliant device (instead of the more common Clause 22 
> devices found in 1GbE controllers).  The registers are 
> diffrerent so the effort is more substantial.  No estimate
> yet on when I can get to it.  

----- Original Message ----- 
From: "stuart cur" <nevtic@area51.capnet.state.tx.us>
To: <freebsd-current@freebsd.org>
Sent: Tuesday, September 08, 2009 5:32 PM
Subject: 8.0-B4, Broadcom bge0 not working, HP Proliant DL385, amd64


> In 8.0-B4 for amd64, bge does not recognize that there is an active 
> ethernet connection on bge0.  Switching the cable to bge1 works correctly.
> 
> This seems to be the same issue as reported on July 21 by Oyvind Rakvag, 
> but I saw no response to that report.
> 
> Attached are the dmesg.boot, /var/log/messages, and output of pciconf -lv 
> from the very first boot.
> 
> stu



> _______________________________________________
> 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"

================================================
This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. 

In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337
or return the E.mail to postmaster@multiplay.co.uk.

From jakub_lach at mailplus.pl  Tue Sep  8 17:52:20 2009
From: jakub_lach at mailplus.pl (Jakub Lach)
Date: Tue Sep  8 17:52:26 2009
Subject: v9.0 treating me very well
In-Reply-To: <20090905150537.GA78983@cuba.calyx.nl>
References: <20090905150537.GA78983@cuba.calyx.nl>
Message-ID: <25351048.post@talk.nabble.com>




Bill Squire {billsf} wrote:
> 
> 
> Hi current-users,
> 
> Surely we want v8.0 to work right, but many of the complaints I see have 
> already been fixed in v9.0 Its not my call (no way will use a Generic
> kernel)
> but please consider your configurations carefully. If you want to do both
> you
> need a separate base install and a /var. I put multiple base-installs on 
> flash ROM drives. Be sure they don't 'require MSDOSFS' to work, but be
> prepared
> to put it back and take it back. (see the ports or emulate, also in the
> ports)
> Hint: 2GiB drives made by a manufacturer I've taken many larger ones back
> so
> I refuse to advertise then, particularly since they have discontinued that
> model. Hint: Its a place close to namesake of this server I'm using.
> 
> PS: The low-cost (and best sounding) USB chips work out of the box, now on
> v9.0 so if you have these try it out. I use balanced audio and have really 
> decent speakers -- You know if you read my previous posts.    
> 
> Bill Squire  
> 
>  
>  
> _______________________________________________
> 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"
> 
> 

Hello..

Maybe I should not reply, but curiosity got the better of me...

What were you trying to communicate? What is the main thought 
beneath phrasing?

>Surely we want v8.0 to work right, but many of the complaints I see have 
>already been fixed in v9.0 

This is why we have MFC, and CURRENT in managed in somehow close state
to STABLE prior to RELEASE.

>Its not my call (no way will use a Generic kernel)

? (I fail to see connection.)

>I put multiple base-installs on 
>flash ROM drives. 

You see flash drives as  EEPROM, ok but I again
fail to see connection.

>PS: The low-cost (and best sounding) USB chips work out of the box, now on
>v9.0 so if you have these try it out. 

Something changed after branching 8-STABLE from 8-CURRENT? I doubt it.
Ariff work is nonetheless excellent.

>I refuse to advertise then, particularly since they have discontinued that
>model. Hint: Its a place close to namesake of this server I'm using.

Why such choose of words? You want to recommend something
or rather not?

>I use balanced audio and have really 
>decent speakers -- You know if you read my previous posts

It's nice to have nice speakers.

-best regards, 
Jakub Lach
-- 
View this message in context: http://www.nabble.com/v9.0-treating-me-very-well-tp25309347p25351048.html
Sent from the freebsd-current mailing list archive at Nabble.com.

From jhb at freebsd.org  Tue Sep  8 18:00:15 2009
From: jhb at freebsd.org (John Baldwin)
Date: Tue Sep  8 18:00:36 2009
Subject: 8.0-beta3 does not detect several ata channels
In-Reply-To: <4AA52BE4.3070708@netability.ie>
References: <4A9BF23F.6070801@netability.ie>
	<200909011002.59592.jhb@freebsd.org>
	<4AA52BE4.3070708@netability.ie>
Message-ID: <200909081325.13149.jhb@freebsd.org>

On Monday 07 September 2009 11:51:00 am Nick Hilliard wrote:
> On 01/09/2009 15:02, John Baldwin wrote:
> > Hmm, so an idea I had just now.. can you grab a dump of the PCI config 
space
> > for the disk controller in the MCFG vs non-MCFG cases?  That is, find the
> > device's address using pciconf -lv (e.g. pci0:0:30:0 or some such) and 
then
> > run this command under both configurations and save the output:
> >
> > pciconf -r pci0:0:30:0 0:0xfc
> 
> Ok, got this working on the beta4 livefs.  If hw.pci.mcfg=0, then all disks 
> are detected correctly.
> 
> I've attached the pciconf output for each case.

So as with the other pciconf output I got, it seems that it is reading the 
registers ok in both cases.  Can you add some printfs to the ata driver to 
figure out when it starts behaving differently (e.g. reading a value from a 
register) between the mcfg=0 and mcfg=1 cases on 8?

-- 
John Baldwin
From billsf at cuba.calyx.nl  Tue Sep  8 18:45:52 2009
From: billsf at cuba.calyx.nl (Bill Squire {billsf})
Date: Tue Sep  8 18:46:00 2009
Subject: v9.0 treating me very well
In-Reply-To: <25351048.post@talk.nabble.com>
References: <20090905150537.GA78983@cuba.calyx.nl>
	<25351048.post@talk.nabble.com>
Message-ID: <20090908184550.GA64091@cuba.calyx.nl>

On Tue, Sep 08, 2009 at 10:52:18AM -0700, Jakub Lach wrote:
> 
> 
> 
> Bill Squire {billsf} wrote:
> > 
> > 
> > Hi current-users,
> > 
> > Surely we want v8.0 to work right, but many of the complaints I see have 

> > v9.0 so if you have these try it out. I use balanced audio and have really 
> > decent speakers -- You know if you read my previous posts.    
> > 
> > Bill Squire  
> > 
> >  
> >  
> > _______________________________________________
> > 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"
> > 
> > 
> 
> Hello..
> 
> Maybe I should not reply, but curiosity got the better of me...
> 
> What were you trying to communicate? What is the main thought 
> beneath phrasing?

Except for a stop in /cddl/ which involves a 'removed from source header file'
9.0 builds. Using this list I know how to move on. As far as the stop -- ignore
it! Everything else seems to __build__ and all that I can test seems to work.

> >Surely we want v8.0 to work right, but many of the complaints I see have 
> >already been fixed in v9.0 
 
> This is why we have MFC, and CURRENT in managed in somehow close state
> to STABLE prior to RELEASE.

Its not mine either but a release is important but I prefer the 'bleading
edge'. Yes, I have some gripes but not a big deal. Silly obvious little
things. If you have ports -- rebuild as many as you care about -- Sometimes,
usually that is, you can cheat by putting a new .so. in /usr/lib/compat and
call it the old lib. I said usually works and ignore conflict warnings.

BTW: How do I use the 'new' loader. I use last week's and it works fine. Also
almost all modules needed are loaded automatically by acript that used kldload
since I believe the kernel would otherwise panic. (It does on 7.2) when you
build a minimal kernel and pre-load all the modules. Let /etc/rc automatically
load as many as you can.  
 
> >Its not my call (no way will use a Generic kernel)
 
> ? (I fail to see connection.)
> 
> >I put multiple base-installs on 
> >flash ROM drives. 

That is so I can allways go back. I test the rebuilding every week and "don't
trust" a loader with a "buffer overflow" bug. Also I've grown tolike my way
of 'loading'and have received no complaints from "commercial users". Its just
easier because I knowmy own way better. Yes, the last update broke many ports.
Updating helps in most cases. Ports aren't really my thing because people will
say I have a bad Makefile nomatter how good it is.  
 
> You see flash drives as  EEPROM, ok but I again
> fail to see connection.
 
> >PS: The low-cost (and best sounding) USB chips work out of the box, now on
> >v9.0 so if you have these try it out. 

Yes, but get the datasheet of the chip and use the proper values. If you have
professional audio you should build a single ended to differential output
stage. If you don't understand this, just try one,particularly if it is a 
C-Media device. They work __better__ than any "HiFi" solution I've spent 
money on only to get a Windows driver and have to get the specs and build my
own driver only to find out it won't handle even 16bits worth of audio. The
hda chips aren't bad for motion pictures. (Hint: Dolby doesn't enhance your
music anymore -- It does make violence much more realistic -- (warning).)  
 
> Something changed after branching 8-STABLE from 8-CURRENT? I doubt it.
> Ariff work is nonetheless excellent.
> 
> >I refuse to advertise then, particularly since they have discontinued that
> >model. Hint: Its a place close to namesake of this server I'm using.
> 
> Why such choose of words? You want to recommend something
> or rather not? The only reccomentation is C-Media blows Intel/Realtech out 
of the water if music is important for you. PC speakers work with any sound
card. 
 
> >I use balanced audio and have really 
> >decent speakers -- You know if you read my previous posts
> 
> It's nice to have nice speakers.

That's the secret for the most part, but I'll never use commercial software
for audio again. This USB stuff sounds great.  
> 
> -best regards, 
> Jakub Lach

Good luck with your sound and use of FreeBSD to acheive it. Don't use "windows"
(stolen from X-Windows) can I not reccomend some system?

> -- 
> View this message in context: http://www.nabble.com/v9.0-treating-me-very-well-tp25309347p25351048.html
> Sent from the freebsd-current mailing list archive at Nabble.com.

If its audiophile, that's not proven -- IN fact disproved scientificaly. Its
like arguing someone's religion -- You get nowhere. True 'HiFi' on "windows"
is with a HEAVILY buffered device -- still screws up your base.  

Bill

PS: If someone wants it spelt out how-to is this the right forum?


From boogie at lazybytes.org  Tue Sep  8 19:14:03 2009
From: boogie at lazybytes.org (Sergey Vinogradov)
Date: Tue Sep  8 19:14:09 2009
Subject: ath(4) Atheros AR9285 support
In-Reply-To: <4AA668E0.1010305@FreeBSD.org>
References: <4AA65ABE.4000207@lazybytes.org> <4AA668E0.1010305@FreeBSD.org>
Message-ID: <4AA6ACF1.3040501@lazybytes.org>

Alex Dupre wrote:
> Sergey Vinogradov ha scritto:
>> Just wanted to know, if there will be any Atheros AR9285 support in
>> ath(4) driver in nearest future? I've got my ASUS Eee 1005HA with one of
>> these wireless adapters, and it doesn't seem to be working.
> 
> I think it should work with FreeBSD 8.0.
> 
Well, despite the fact that "device ath", and all related stuff are
included in GENERIC kernel in 8.0-BETA4, I have no ath0 interface.
"dmesg | grep -i ath" gives nothing (well, as a matter of fact it gives
"alc0: <Atheros AR8132 PCIe Fast Ethernet> ... ", but alc0 doesn't work
either, link handling is broken as I understand). Is there something I'm
doing wrong, or something I can do to help the development? :)

-- 
wbr,
Boo

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 259 bytes
Desc: OpenPGP digital signature
Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20090908/7cd0d773/signature.pgp
From pluknet at gmail.com  Tue Sep  8 19:42:15 2009
From: pluknet at gmail.com (pluknet)
Date: Tue Sep  8 19:42:22 2009
Subject: acquiring duplicate lock of same type: "ftlk"
In-Reply-To: <3bbf2fe10909080213i588493darf8dd1e1ff768cb0a@mail.gmail.com>
References: <a31046fc0908270158l63b103a7v6c9fd1b7be54d3ed@mail.gmail.com>
	<a31046fc0909071115td2d5309na5738a44402feaa9@mail.gmail.com>
	<20090908091114.GH47688@deviant.kiev.zoral.com.ua>
	<3bbf2fe10909080213i588493darf8dd1e1ff768cb0a@mail.gmail.com>
Message-ID: <a31046fc0909081242v7e1b8f98t72a6df8b9d37a960@mail.gmail.com>

2009/9/8 Attilio Rao <attilio@freebsd.org>:
> 2009/9/8 Kostik Belousov <kostikbel@gmail.com>:
>> On Mon, Sep 07, 2009 at 10:15:48PM +0400, pluknet wrote:
>>> lock order reversal:
>>> ?1st 0xc75365b8 pseudofs (pseudofs) @ /usr/src/sys/kern/vfs_lookup.c:497
>>> ?2nd 0xc088ea3c allproc (allproc) @ /usr/src/sys/kern/kern_proc.c:292
>>> KDB: stack backtrace:
>>> db_trace_self_wrapper(c07fd8ea,e82148e4,c060a145,c05fac1b,c08008bf,...)
>>> at db_trace_self_wrapper+0x26
>>> kdb_backtrace(c05fac1b,c08008bf,c58eabe8,c58e30d0,e8214940,...) at
>>> kdb_backtrace+0x29
>>> _witness_debugger(c08008bf,c088ea3c,c07f981d,c58e30d0,c07f96f0,...) at
>>> _witness_debugger+0x25
>>> witness_checkorder(c088ea3c,1,c07f96f0,124,0,...) at witness_checkorder+0x839
>>> _sx_slock(c088ea3c,0,c07f96f0,124,c73c4980,...) at _sx_slock+0x85
>>> pfind(514,c72ba1a0,4,c07f8d78,c5fe1b40,...) at pfind+0x2f
>>> pfs_visible(0,0,c07f042d,7c,c7536560,...) at pfs_visible+0x3a
>>> pfs_lookup(e8214a40,c082715e,c7536560,c7536560,e8214bf8,...) at pfs_lookup+0x3dd
>>> VOP_CACHEDLOOKUP_APV(c0843960,e8214a40,e8214bf8,e8214be4,c73c4e80,...)
>>> at VOP_CACHEDLOOKUP_APV+0xc5
>>> vfs_cache_lookup(e8214acc,c08087d0,c0875a00,200000,e8214bcc,...) at
>>> vfs_cache_lookup+0xd6
>>> VOP_LOOKUP_APV(c0843960,e8214acc,e8214bf8,1f1,e8214be4,...) at
>>> VOP_LOOKUP_APV+0xe5
>>> lookup(e8214bcc,c5fd1800,0,c5,c5ef77f8,...) at lookup+0x63b
>>> namei(e8214bcc,c5c1500d,3f3,e8214c20,c5c1500d,...) at namei+0x57f
>>> kern_alternate_path(c5fe1b40,c0b4921c,2879f478,0,e8214c74,...) at kern_alternate
>>> _path+0x1cd
>>> linux_emul_convpath(c5fe1b40,2879f478,0,e8214c74,0,...) at
>>> linux_emul_convpath+0x3c
>>> linux_open(c5fe1b40,e8214cf8,e8214d18,e8214d1c,c0b4b58c,...) at linux_open+0x41
>>> syscall(e8214d38) at syscall+0x2b4
>>> Xint0x80_syscall() at Xint0x80_syscall+0x20
>>> --- syscall (5, Linux ELF, linux_open), eip = 0x2889115e, esp =
>>> 0xbfbfbd1c, ebp = 0xbfbfbd6c ---
>>> acquiring duplicate lock of same type: "ftlk"
>>> [...]
>>
>> The second LOR actually exposes the right order. It would be interesting
>> to look up the point where the other order is established.
>
> You would manually patch the witness static table with this order and
> the opposite will show, when happening.
>

I've patched witness order table, and still no opposite case,
nor any pseudofs related LORs at all.
        { "pseudofs", &lock_class_lockmgr },
        { "allproc", &lock_class_sx },
        { NULL, NULL },

Seen orders with pseudofs:
"ufs","pseudofs"
"pseudofs","allproc"
"pseudofs","process lock"
"pseudofs","vnode interlock"
"pseudofs","struct mount mtx"
"pseudofs","UMA zone"
"pseudofs","sleep mtxpool"
"pseudofs","Name Cache"
"pseudofs","vnode_free_list"
"pseudofs","pfs_node"
"pseudofs","pfs_vncache"

Something else?

-- 
wbr,
pluknet
From attilio at freebsd.org  Tue Sep  8 19:48:39 2009
From: attilio at freebsd.org (Attilio Rao)
Date: Tue Sep  8 19:48:46 2009
Subject: acquiring duplicate lock of same type: "ftlk"
In-Reply-To: <a31046fc0909081242v7e1b8f98t72a6df8b9d37a960@mail.gmail.com>
References: <a31046fc0908270158l63b103a7v6c9fd1b7be54d3ed@mail.gmail.com>
	<a31046fc0909071115td2d5309na5738a44402feaa9@mail.gmail.com>
	<20090908091114.GH47688@deviant.kiev.zoral.com.ua>
	<3bbf2fe10909080213i588493darf8dd1e1ff768cb0a@mail.gmail.com>
	<a31046fc0909081242v7e1b8f98t72a6df8b9d37a960@mail.gmail.com>
Message-ID: <3bbf2fe10909081248w3a09c9a8ge3b6fa9de8b2d3e9@mail.gmail.com>

2009/9/8 pluknet <pluknet@gmail.com>:
> 2009/9/8 Attilio Rao <attilio@freebsd.org>:
>> 2009/9/8 Kostik Belousov <kostikbel@gmail.com>:
>>> On Mon, Sep 07, 2009 at 10:15:48PM +0400, pluknet wrote:
>>>> lock order reversal:
>>>>  1st 0xc75365b8 pseudofs (pseudofs) @ /usr/src/sys/kern/vfs_lookup.c:497
>>>>  2nd 0xc088ea3c allproc (allproc) @ /usr/src/sys/kern/kern_proc.c:292
>>>> KDB: stack backtrace:
>>>> db_trace_self_wrapper(c07fd8ea,e82148e4,c060a145,c05fac1b,c08008bf,...)
>>>> at db_trace_self_wrapper+0x26
>>>> kdb_backtrace(c05fac1b,c08008bf,c58eabe8,c58e30d0,e8214940,...) at
>>>> kdb_backtrace+0x29
>>>> _witness_debugger(c08008bf,c088ea3c,c07f981d,c58e30d0,c07f96f0,...) at
>>>> _witness_debugger+0x25
>>>> witness_checkorder(c088ea3c,1,c07f96f0,124,0,...) at witness_checkorder+0x839
>>>> _sx_slock(c088ea3c,0,c07f96f0,124,c73c4980,...) at _sx_slock+0x85
>>>> pfind(514,c72ba1a0,4,c07f8d78,c5fe1b40,...) at pfind+0x2f
>>>> pfs_visible(0,0,c07f042d,7c,c7536560,...) at pfs_visible+0x3a
>>>> pfs_lookup(e8214a40,c082715e,c7536560,c7536560,e8214bf8,...) at pfs_lookup+0x3dd
>>>> VOP_CACHEDLOOKUP_APV(c0843960,e8214a40,e8214bf8,e8214be4,c73c4e80,...)
>>>> at VOP_CACHEDLOOKUP_APV+0xc5
>>>> vfs_cache_lookup(e8214acc,c08087d0,c0875a00,200000,e8214bcc,...) at
>>>> vfs_cache_lookup+0xd6
>>>> VOP_LOOKUP_APV(c0843960,e8214acc,e8214bf8,1f1,e8214be4,...) at
>>>> VOP_LOOKUP_APV+0xe5
>>>> lookup(e8214bcc,c5fd1800,0,c5,c5ef77f8,...) at lookup+0x63b
>>>> namei(e8214bcc,c5c1500d,3f3,e8214c20,c5c1500d,...) at namei+0x57f
>>>> kern_alternate_path(c5fe1b40,c0b4921c,2879f478,0,e8214c74,...) at kern_alternate
>>>> _path+0x1cd
>>>> linux_emul_convpath(c5fe1b40,2879f478,0,e8214c74,0,...) at
>>>> linux_emul_convpath+0x3c
>>>> linux_open(c5fe1b40,e8214cf8,e8214d18,e8214d1c,c0b4b58c,...) at linux_open+0x41
>>>> syscall(e8214d38) at syscall+0x2b4
>>>> Xint0x80_syscall() at Xint0x80_syscall+0x20
>>>> --- syscall (5, Linux ELF, linux_open), eip = 0x2889115e, esp =
>>>> 0xbfbfbd1c, ebp = 0xbfbfbd6c ---
>>>> acquiring duplicate lock of same type: "ftlk"
>>>> [...]
>>>
>>> The second LOR actually exposes the right order. It would be interesting
>>> to look up the point where the other order is established.
>>
>> You would manually patch the witness static table with this order and
>> the opposite will show, when happening.
>>
>
> I've patched witness order table, and still no opposite case,
> nor any pseudofs related LORs at all.
>        { "pseudofs", &lock_class_lockmgr },
>        { "allproc", &lock_class_sx },
>        { NULL, NULL },
>
> Seen orders with pseudofs:
> "ufs","pseudofs"
> "pseudofs","allproc"
> "pseudofs","process lock"
> "pseudofs","vnode interlock"
> "pseudofs","struct mount mtx"
> "pseudofs","UMA zone"
> "pseudofs","sleep mtxpool"
> "pseudofs","Name Cache"
> "pseudofs","vnode_free_list"
> "pseudofs","pfs_node"
> "pseudofs","pfs_vncache"
>
> Something else?

Probabilly it just takes time.
You should try to recreate conditions you did before to get this LOR.

Attilio


-- 
Peace can only be achieved by understanding - A. Einstein
From tlott at gamesnet.de  Tue Sep  8 19:54:48 2009
From: tlott at gamesnet.de (Tobias Lott)
Date: Tue Sep  8 19:55:06 2009
Subject: Problems with ZFS on AMD64
In-Reply-To: <200909011005.18200.jhb@freebsd.org>
References: <a7454e2f0909010624yf652445y855047b83d046cc4@mail.gmail.com>
	<200909011005.18200.jhb@freebsd.org>
Message-ID: <20090908214402.43009577@sub.han.vpn.gamesnet.de>



On Tue, 1 Sep 2009 10:05:17 -0400
John Baldwin <jhb@freebsd.org> wrote:

> On Tuesday 01 September 2009 9:24:24 am Maciej Jan Broniarz wrote:
> > Hello,
> > 
> > I have installed Freebsd8-beta3 on a Phenom II Quad Core with 8 gb
> > ram. When I create a zfs volume all works fine. Still, when I
> > reboot the system it doesn't come up. It hangs with the following
> > error:
> > 
> > http://img525.imageshack.us/img525/3832/freebsd8zfs.jpg
> > 
> > What might be the problem?
> 
> It's probably a NULL pointer dereference, but we would need a stack
> trace to investigate this further.
>
My Problem seems to be related.

Updating a Machine to 8.0-BETA4 #3 caused same, its a i386 System using
gpt with zfs-only volumes beside swap.

http://i25.tinypic.com/343p0s0.jpg

I'll try to see if I can get a stack trace

-- 
Tobias Lott
From rnoland at FreeBSD.org  Tue Sep  8 20:01:59 2009
From: rnoland at FreeBSD.org (Robert Noland)
Date: Tue Sep  8 20:02:06 2009
Subject: Funding ODD support
In-Reply-To: <4AA68C8A.4060405@FreeBSD.org>
References: <1252225381.00160049.1252212601@10.7.7.3>
	<4AA68C8A.4060405@FreeBSD.org>
Message-ID: <1252440109.85394.2430.camel@balrog.2hip.net>

On Tue, 2009-09-08 at 19:55 +0300, Alexander Motin wrote:
> Harald Schmalzbauer wrote:
> > I'm looking for somebody who has time and knowledge to fix ODD support
> > in FreeBSD.
> > I'm willing to sponsor a decent ammount.
> > My problem is that I can't use FreeBSD for any task in which CD or DVD
> > is involved.
> > What I want is read/write support for any ATAPI/S-ATA ODD regarding
> > ISO9660 and audio. Of course I'd love to have UDF support also, but for
> > the beginning I'd be glad if FreeBSD could boot with an inserted audio
> > CD. This has been a problem for more than two years now, and disabling
> > DMA support for ata devices isn't a satisfying solution.
> > 
> > So if you think ypu can fix this and make growisofs and cdrtools working
> > with ATAPI and SATA devices, please contact me.
> > If we have working ODD support in 8.0-release I'll donate 100 extra bucks.
> 
> Funding is good, but could you first once more repeat what is your
> problem? Which controller do you use? Which drive? Which disks and which
> applications? Have you tried to use different controllers, drives,
> disks, applications? I am asking because there quite a lot of people
> successfully using ODD on FreeBSD.

FWIW, some of the recent changes do seem to have broken things a bit for
me... But I can't quite put my finger on where the breakage is.  Some
apps seem to work, depending on media, while other don't (that used to).
For example I can burn a data DVD using tkdvd, but not brasero.  brasero
does seem to be able to burn data cds, though I'm getting horrible
throughput which I don't understand.  (I seem to max at about 4x writing
cds on a 48x cd burner, IIRC).  I haven't found any tool that is able to
write a DL dvd, currently.

robert.

-- 
Robert Noland <rnoland@FreeBSD.org>
FreeBSD

From boogie at lazybytes.org  Tue Sep  8 20:03:40 2009
From: boogie at lazybytes.org (Sergey Vinogradov)
Date: Tue Sep  8 20:03:47 2009
Subject: ath(4) Atheros AR9285 support
In-Reply-To: <20090908195516.GA8398@greencat.langhans.com.pl>
References: <4AA65ABE.4000207@lazybytes.org>
	<20090908195516.GA8398@greencat.langhans.com.pl>
Message-ID: <4AA6B894.5090904@lazybytes.org>

herbs wrote:
> I had serious problems using the port hal in combination with an Atheros
> WiFi card. Maybe disable hal and try again?
> 
> Cheers
> herb langhans
>  
> On Tue, Sep 08, 2009 at 05:23:10PM +0400, Sergey Vinogradov wrote:
>> Hi,
>> Just wanted to know, if there will be any Atheros AR9285 support in
>> ath(4) driver in nearest future? I've got my ASUS Eee 1005HA with one of
>> these wireless adapters, and it doesn't seem to be working.
>>
>> -- 
>> wbr,
>> Boo
>>
> 
> 
> 
It's a fresh install, nothing but base system and GENERIC kernel installed.

-- 
wbr,
Boo

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 259 bytes
Desc: OpenPGP digital signature
Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20090908/2ed401d7/signature.pgp
From herbert.raimund at gmx.net  Tue Sep  8 20:08:59 2009
From: herbert.raimund at gmx.net (herbs)
Date: Tue Sep  8 20:09:07 2009
Subject: ath(4) Atheros AR9285 support
In-Reply-To: <4AA65ABE.4000207@lazybytes.org>
References: <4AA65ABE.4000207@lazybytes.org>
Message-ID: <20090908195516.GA8398@greencat.langhans.com.pl>

I had serious problems using the port hal in combination with an Atheros
WiFi card. Maybe disable hal and try again?

Cheers
herb langhans
 
On Tue, Sep 08, 2009 at 05:23:10PM +0400, Sergey Vinogradov wrote:
> Hi,
> Just wanted to know, if there will be any Atheros AR9285 support in
> ath(4) driver in nearest future? I've got my ASUS Eee 1005HA with one of
> these wireless adapters, and it doesn't seem to be working.
> 
> -- 
> wbr,
> Boo
> 



-- 
******* Herbert Langhans, Warschau
******* Sprachtraining Langhans
******* http://www.langhans.com.pl
******* herbert at langhans.com.pl
******* NIP 526-229-61-51
******* Regon  014911759
******* Tel. 603 341 441
From jfb at mr-happy.com  Tue Sep  8 20:25:55 2009
From: jfb at mr-happy.com (Jeff Blank)
Date: Tue Sep  8 20:26:02 2009
Subject: 8.0-BETA4 panic: ffs_sync: rofs mod
Message-ID: <20090908202553.GA1368@mr-happy.com>

Hi,

My 8.0-BETA4/amd64 installation panicked when I attempted to create a
file on zvol-backed UFS.  This installation is otherwise UFS-free, ZFS
v13 w/gptzfsboot method linked from wiki, single zpool mirror
(ad{4,6}p3).

# zfs create -V 18G z0/ufs0
# newfs -U -L oldbender /dev/zvol/z0/ufs0
# mount /dev/ufs/oldbender /old
# touch /old/foo

The system usually panics immediately, but once it waited a few
seconds to do so, and I saw the file had been created.  The file was
not there upon reboot in all cases, and the filesystem was considered
clean by fsck.

Should I expect this to work?  And/or is it a known issue?  (Didn't
find any similar-looking problems by googling or browsing list
archives.)

Please let me know if I need to provide more details.

Jeff

-------------- next part --------------
console output:

fs = /old
panic: ffs_sync: rofs mod
cpuid = 1
KDB: enter: panic
[thread pid 19 tid 100049 ]
Stopped at      kdb_enter+0x3d: movq    $0,0x68d1e0(%rip)
db> bt
Tracing pid 19 tid 100049 td 0xffffff0002ad7000
kdb_enter() at kdb_enter+0x3d
panic() at panic+0x17b
ffs_sync() at ffs_sync+0x544
sync_fsync() at sync_fsync+0x13a
sync_vnode() at sync_vnode+0x157
sched_sync() at sched_sync+0x1d1
fork_exit() at fork_exit+0x12a
fork_trampoline() at fork_trampoline+0xe
--- trap 0, rip = 0, rsp = 0xffffff8074cd7d30, rbp = 0 ---
db> 


kgdb upon reboot:

# kgdb /boot/kernel/kernel /var/crash/vmcore.1
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "amd64-marcel-freebsd"...

Unread portion of the kernel message buffer:
fs = /old
panic: ffs_sync: rofs mod
cpuid = 1
KDB: enter: panic
Physical memory: 4076 MB
Dumping 1396 MB: 1381 1365 1349 1333 1317 1301 1285 1269 1253 1237 1221 1205 1189 1173 1157 1141 1125 1109 1093 1077 1061 1045 1029 1013 997 981 965 949 933 917 901 885 869 853 837 821 805 789 773 757 741 725 709 693 677 661 645 629 613 597 581 565 549 533 517 501 485 469 453 437 421 405 389 373 357 341 325 309 293 277 261 245 229 213 197 181 165 149 133 117 101 85 69 53 37 21 5

Reading symbols from /boot/kernel/zfs.ko...Reading symbols from /boot/kernel/zfs.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/zfs.ko
Reading symbols from /boot/kernel/opensolaris.ko...Reading symbols from /boot/kernel/opensolaris.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/opensolaris.ko
Reading symbols from /boot/kernel/geom_mirror.ko...Reading symbols from /boot/kernel/geom_mirror.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/geom_mirror.ko
Reading symbols from /boot/kernel/linux.ko...Reading symbols from /boot/kernel/linux.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/linux.ko
Reading symbols from /boot/kernel/snd_hda.ko...Reading symbols from /boot/kernel/snd_hda.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/snd_hda.ko
Reading symbols from /boot/kernel/sound.ko...Reading symbols from /boot/kernel/sound.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/sound.ko
Reading symbols from /boot/kernel/atapicam.ko...Reading symbols from /boot/kernel/atapicam.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/atapicam.ko
Reading symbols from /boot/kernel/linprocfs.ko...Reading symbols from /boot/kernel/linprocfs.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/linprocfs.ko
Reading symbols from /boot/kernel/radeon.ko...Reading symbols from /boot/kernel/radeon.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/radeon.ko
Reading symbols from /boot/kernel/drm.ko...Reading symbols from /boot/kernel/drm.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/drm.ko
#0  doadump () at pcpu.h:223
223     pcpu.h: No such file or directory.
        in pcpu.h
(kgdb) bt
#0  doadump () at pcpu.h:223
#1  0xffffffff801d90fc in db_fncall (dummy1=Variable "dummy1" is not available.
)
    at /usr/src/sys/ddb/db_command.c:548
#2  0xffffffff801d9431 in db_command (last_cmdp=0xffffffff80be9720, cmd_table=Variable "cmd_table" is not available.
)
    at /usr/src/sys/ddb/db_command.c:445
#3  0xffffffff801d9680 in db_command_loop ()
    at /usr/src/sys/ddb/db_command.c:498
#4  0xffffffff801db659 in db_trap (type=Variable "type" is not available.
) at /usr/src/sys/ddb/db_main.c:229
#5  0xffffffff805b2025 in kdb_trap (type=3, code=0, tf=0xffffff8074cd7880)
    at /usr/src/sys/kern/subr_kdb.c:535
#6  0xffffffff80864af1 in trap (frame=0xffffff8074cd7880)
    at /usr/src/sys/amd64/amd64/trap.c:613
#7  0xffffffff8084a7d3 in calltrap ()
    at /usr/src/sys/amd64/amd64/exception.S:224
#8  0xffffffff805b21fd in kdb_enter (why=0xffffffff8095cf97 "panic", 
    msg=0xa <Address 0xa out of bounds>) at cpufunc.h:63
#9  0xffffffff8058298b in panic (fmt=Variable "fmt" is not available.
) at /usr/src/sys/kern/kern_shutdown.c:562
#10 0xffffffff807a8cc4 in ffs_sync (mp=Variable "mp" is not available.
)
    at /usr/src/sys/ufs/ffs/ffs_vfsops.c:1261
#11 0xffffffff80615cda in sync_fsync (ap=Variable "ap" is not available.
) at /usr/src/sys/kern/vfs_subr.c:3433
#12 0xffffffff80614197 in sync_vnode (slp=0xffffff00029f14a8, 
    bo=0xffffff8074cd7bf0, td=0xffffff0002ad7000) at vnode_if.h:549
#13 0xffffffff80614401 in sched_sync () at /usr/src/sys/kern/vfs_subr.c:1799
#14 0xffffffff8055a73a in fork_exit (callout=0xffffffff80614230 <sched_sync>, 
    arg=0x0, frame=0xffffff8074cd7c80) at /usr/src/sys/kern/kern_fork.c:838
#15 0xffffffff8084acae in fork_trampoline ()
    at /usr/src/sys/amd64/amd64/exception.S:561
#16 0x0000000000000000 in ?? ()
#17 0x0000000000000000 in ?? ()
#18 0x0000000000000001 in ?? ()
#19 0x0000000000000000 in ?? ()
#20 0x0000000000000000 in ?? ()
#21 0x0000000000000000 in ?? ()
#22 0x0000000000000000 in ?? ()
#23 0x0000000000000000 in ?? ()
#24 0x0000000000000000 in ?? ()
#25 0x0000000000000000 in ?? ()
#26 0x0000000000000000 in ?? ()
#27 0x0000000000000000 in ?? ()
#28 0x0000000000000000 in ?? ()
#29 0x0000000000000000 in ?? ()
#30 0x0000000000000000 in ?? ()
#31 0x0000000000000000 in ?? ()
#32 0x0000000000000000 in ?? ()
#33 0x0000000000000000 in ?? ()
#34 0x0000000000000000 in ?? ()
#35 0x0000000000000000 in ?? ()
#36 0x0000000000000000 in ?? ()
#37 0x0000000000000000 in ?? ()
#38 0x0000000000000000 in ?? ()
#39 0x0000000000000000 in ?? ()
#40 0x00000000012d7000 in ?? ()
#41 0x0000000000000000 in ?? ()
#42 0xffffffff80c25840 in affinity ()
#43 0xffffffff80c25840 in affinity ()
#44 0xffffff0002802390 in ?? ()
#45 0xffffff8074cd74e0 in ?? ()
#46 0xffffff8074cd7498 in ?? ()
#47 0xffffff0002ad7000 in ?? ()
#48 0xffffffff805a57e0 in sched_switch (td=0x0, newtd=0xffffffff80614230, 
    flags=Variable "flags" is not available.
) at /usr/src/sys/kern/sched_ule.c:1858
Previous frame inner to this frame (corrupt stack?)
(kgdb) 
From lars.engels at 0x20.net  Tue Sep  8 20:37:09 2009
From: lars.engels at 0x20.net (Lars Engels)
Date: Tue Sep  8 20:37:16 2009
Subject: CFH: fix multimedia/pwcbsd with usb2
Message-ID: <20090908201713.GD41185@e.0x20.net>

Hi all,

could someone with some more USB and C knowledge than me take a look at
multimedia/pwcbsd?
I'd really like to get the port fixed before the ports freeze starts.
Here is the compile output:

In file included from pwc.c:27:
pwc.h:47:31: error: dev/usb/usb_mfunc.h: No such file or directory
pwc.h:48:31: error: dev/usb/usb_error.h: No such file or directory
In file included from pwc.h:50,
                 from pwc.c:27:
@/dev/usb/usb_core.h:121: error: field 'timeout_handle' has incomplete type
@/dev/usb/usb_core.h:140: error: expected specifier-qualifier-list before 'usb_callback_t'
pwc.h:52:32: error: dev/usb/usb_lookup.h: No such file or directory
In file included from pwc.h:55,
                 from pwc.c:27:
@/dev/usb/usb_request.h:32: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'usbd_req_clear_hub_feature'
@/dev/usb/usb_request.h:34: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'usbd_req_clear_port_feature'
@/dev/usb/usb_request.h:36: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'usbd_req_get_alt_interface_no'
@/dev/usb/usb_request.h:39: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'usbd_req_get_config'
@/dev/usb/usb_request.h:41: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'usbd_req_get_descriptor_ptr'
@/dev/usb/usb_request.h:43: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'usbd_req_get_config_desc'
@/dev/usb/usb_request.h:45: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'usbd_req_get_config_desc_full'
@/dev/usb/usb_request.h:48: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'usbd_req_get_desc'
@/dev/usb/usb_request.h:52: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'usbd_req_get_device_desc'
@/dev/usb/usb_request.h:54: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'usbd_req_get_device_status'
@/dev/usb/usb_request.h:56: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'usbd_req_get_hub_descriptor'
@/dev/usb/usb_request.h:59: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'usbd_req_get_hub_status'
@/dev/usb/usb_request.h:61: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'usbd_req_get_port_status'
@/dev/usb/usb_request.h:63: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'usbd_req_reset_port'
@/dev/usb/usb_request.h:65: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'usbd_req_set_address'
@/dev/usb/usb_request.h:67: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'usbd_req_set_hub_feature'
@/dev/usb/usb_request.h:69: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'usbd_req_set_port_feature'
@/dev/usb/usb_request.h:71: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'usbd_req_re_enumerate'
@/dev/usb/usb_request.h:72: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'usbd_req_clear_device_feature'
@/dev/usb/usb_request.h:73: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'usbd_req_set_device_feature'
pwc.c:62: error: array type has incomplete element type
pwc.c:63: error: array index in non-array initializer
pwc.c:63: error: (near initialization for 'pwc_config')
pwc.c:64: error: field name not in record or union initializer
pwc.c:64: error: (near initialization for 'pwc_config')
pwc.c:65: error: field name not in record or union initializer
pwc.c:65: error: (near initialization for 'pwc_config')
pwc.c:66: error: field name not in record or union initializer
pwc.c:66: error: (near initialization for 'pwc_config')
pwc.c:67: error: field name not in record or union initializer
pwc.c:67: error: (near initialization for 'pwc_config')
pwc.c:68: error: field name not in record or union initializer
pwc.c:68: error: (near initialization for 'pwc_config')
pwc.c:69: error: field name not in record or union initializer
pwc.c:69: error: (near initialization for 'pwc_config')
pwc.c:69: error: field name not in record or union initializer
pwc.c:69: error: (near initialization for 'pwc_config')
pwc.c:70: error: field name not in record or union initializer
pwc.c:70: error: (near initialization for 'pwc_config')
pwc.c:73: error: array index in non-array initializer
pwc.c:73: error: (near initialization for 'pwc_config')
pwc.c:74: error: field name not in record or union initializer
pwc.c:74: error: (near initialization for 'pwc_config')
pwc.c:75: error: field name not in record or union initializer
pwc.c:75: error: (near initialization for 'pwc_config')
pwc.c:76: error: field name not in record or union initializer
pwc.c:76: error: (near initialization for 'pwc_config')
pwc.c:77: error: field name not in record or union initializer
pwc.c:77: error: (near initialization for 'pwc_config')
pwc.c:78: error: field name not in record or union initializer
pwc.c:78: error: (near initialization for 'pwc_config')
pwc.c:79: error: field name not in record or union initializer
pwc.c:79: error: (near initialization for 'pwc_config')
pwc.c:79: error: field name not in record or union initializer
pwc.c:79: error: (near initialization for 'pwc_config')
pwc.c:80: error: field name not in record or union initializer
pwc.c:80: error: (near initialization for 'pwc_config')
pwc.c:84: error: array type has incomplete element type
cc1: warnings being treated as errors
pwc.c:85: warning: implicit declaration of function 'USB_VPI'
pwc.c: In function 'pwc_probe':
pwc.c:145: error: dereferencing pointer to incomplete type
pwc.c:152: error: dereferencing pointer to incomplete type
pwc.c:155: warning: implicit declaration of function 'usb2_lookup_id_by_uaa'
pwc.c:155: warning: nested extern declaration of 'usb2_lookup_id_by_uaa'
pwc.c: In function 'pwc_attach':
pwc.c:169: warning: implicit declaration of function 'device_set_usb2_desc'
pwc.c:169: warning: nested extern declaration of 'device_set_usb2_desc'
pwc.c:173: error: dereferencing pointer to incomplete type
pwc.c:174: warning: implicit declaration of function 'USB_GET_DRIVER_INFO'
pwc.c:174: warning: nested extern declaration of 'USB_GET_DRIVER_INFO'
pwc.c:175: error: dereferencing pointer to incomplete type
pwc.c:180: error: dereferencing pointer to incomplete type
pwc.c:181: error: dereferencing pointer to incomplete type
pwc.c:184: error: dereferencing pointer to incomplete type
pwc.c: In function 'pwc_detach':
pwc.c:296: warning: implicit declaration of function 'usb2_transfer_unsetup'
pwc.c:296: warning: nested extern declaration of 'usb2_transfer_unsetup'
pwc.c: In function 'pwc_close':
pwc.c:460: warning: implicit declaration of function 'usb2_set_alt_interface_index'
pwc.c:460: warning: nested extern declaration of 'usb2_set_alt_interface_index'
pwc.c: In function 'pwc_try_video_mode':
pwc.c:619: error: 'USB_ERR_NORMAL_COMPLETION' undeclared (first use in this function)
pwc.c:619: error: (Each undeclared identifier is reported only once
pwc.c:619: error: for each function it appears in.)
pwc.c:625: warning: implicit declaration of function 'usb2_transfer_setup'
pwc.c:625: warning: nested extern declaration of 'usb2_transfer_setup'
pwc.c:632: warning: implicit declaration of function 'usb2_transfer_start'
pwc.c:632: warning: nested extern declaration of 'usb2_transfer_start'
pwc.c: In function 'pwc_isoc_rx_callback':
pwc.c:680: warning: implicit declaration of function 'USB_GET_STATE'
pwc.c:680: warning: nested extern declaration of 'USB_GET_STATE'
pwc.c:681: error: 'USB_ST_TRANSFERRED' undeclared (first use in this function)
pwc.c:682: error: dereferencing pointer to incomplete type
pwc.c:686: error: 'USB_ST_SETUP' undeclared (first use in this function)
pwc.c:688: error: dereferencing pointer to incomplete type
pwc.c:689: error: dereferencing pointer to incomplete type
pwc.c:689: error: dereferencing pointer to incomplete type
pwc.c:691: error: dereferencing pointer to incomplete type
pwc.c:691: error: dereferencing pointer to incomplete type
pwc.c:692: warning: implicit declaration of function 'usb2_start_hardware'
pwc.c:692: warning: nested extern declaration of 'usb2_start_hardware'
pwc.c:695: error: dereferencing pointer to incomplete type
pwc.c:695: error: 'USB_ERR_CANCELLED' undeclared (first use in this function)
pwc.c: In function 'pwc_isoc_handler':
pwc.c:710: error: dereferencing pointer to incomplete type
pwc.c:729: error: dereferencing pointer to incomplete type
pwc.c:730: error: dereferencing pointer to incomplete type
pwc.c:743: warning: implicit declaration of function 'usb2_copy_out'
pwc.c:743: warning: nested extern declaration of 'usb2_copy_out'
pwc.c:743: error: dereferencing pointer to incomplete type
*** Error code 1

Stop in /usr/ports/multimedia/pwcbsd/work/pwcbsd.

Thanks a lot in advance!

Lars

-- 
Lars Engels
E-Mail: lars.engels@0x20.net 	
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20090908/e0654260/attachment.pgp
From pyunyh at gmail.com  Tue Sep  8 20:47:00 2009
From: pyunyh at gmail.com (Pyun YongHyeon)
Date: Tue Sep  8 20:47:07 2009
Subject: ath(4) Atheros AR9285 support
In-Reply-To: <4AA6ACF1.3040501@lazybytes.org>
References: <4AA65ABE.4000207@lazybytes.org> <4AA668E0.1010305@FreeBSD.org>
	<4AA6ACF1.3040501@lazybytes.org>
Message-ID: <20090908204520.GC1520@michelle.cdnetworks.com>

On Tue, Sep 08, 2009 at 11:13:53PM +0400, Sergey Vinogradov wrote:
> Alex Dupre wrote:
> > Sergey Vinogradov ha scritto:
> >> Just wanted to know, if there will be any Atheros AR9285 support in
> >> ath(4) driver in nearest future? I've got my ASUS Eee 1005HA with one of
> >> these wireless adapters, and it doesn't seem to be working.
> > 
> > I think it should work with FreeBSD 8.0.
> > 
> Well, despite the fact that "device ath", and all related stuff are
> included in GENERIC kernel in 8.0-BETA4, I have no ath0 interface.
> "dmesg | grep -i ath" gives nothing (well, as a matter of fact it gives
> "alc0: <Atheros AR8132 PCIe Fast Ethernet> ... ", but alc0 doesn't work

Would you give more details on this? Showing me demsg(8) output
related with alc(4) and atphy(4) would be good help.
When I tried AR8132 sample board it had no such problems on my box.
AR8132 uses F1 PHY even if it support only 10/100Mbps link so this
might cause problems on your box, I guess. Does your link partner
support only 10/100Mbps?

> either, link handling is broken as I understand). Is there something I'm
> doing wrong, or something I can do to help the development? :)
> 
> -- 
> wbr,
> Boo
> 
From sweetnavelorange at gmail.com  Tue Sep  8 21:45:02 2009
From: sweetnavelorange at gmail.com (James Butler)
Date: Tue Sep  8 21:45:09 2009
Subject: Fwd: Can't boot 8.0-BETA4 from USB stick
In-Reply-To: <f0dd9eb90909081444pa5cdbf2jd9ee8573c3d4594@mail.gmail.com>
References: <f0dd9eb90909080402m27558850g6aaa2a5e4c477758@mail.gmail.com>
	<200909081350.34461.hselasky@c2i.net>
	<f0dd9eb90909081444pa5cdbf2jd9ee8573c3d4594@mail.gmail.com>
Message-ID: <f0dd9eb90909081445i4e286e6apb3ad84691c0ef2d0@mail.gmail.com>

2009/9/8 Hans Petter Selasky <hselasky@c2i.net>:
> On Tuesday 08 September 2009 13:02:48 James Butler wrote:
>> Greetings all,
>>
>> I have an amd64 system (Asus A8V-MX) which boots 7.2
> from a USB flash
>> drive. Trying an 8-STABLE kernel from Saturday
> (identifies as
>> 8.0-BETA4), the system can't boot - here is the last
> bit of the kernel
>> messages (typed, with comments):
>>
>> [witness performance blah blah blah]
>> root mount waiting for: usbus2 usbus1 usbus0
>> uhub0: 2 ports with 2 removable, self powered
>> uhub1: 2 ports with 2 removable, self powered
>> root mount waiting for: usbus2
>> uhub2: 2 ports with 2 removable, self powered
>> root mount waiting for: usbus2
>> ugen2.2: <TOSHIBA> at usbus2
>> umass0: <Toshiba TransMemory, class 0/0, rev 2.00/1.00,
> addr 2> on usbus2
>> umass0: ?SCSI over Bulk-Only; quirks = 0x0000
>> root mount waiting for: usbus2
>> umass0:0:0:-1: Attached to scbus0
>> Trying to mount root from ufs:/dev/da0s1a
>> ROOT MOUNT ERROR:
>> If you have invalid mount options, reboot, and da0 at
> umass-sim0 bus 0
>> target 0 lun 0 ?<---- This is suspicious
>> da0: <TOSHIBA TransMemory PMAP> Removable Direct Access
> SCSI-0 device
>> da0: 40.000MB/s transfers
>> da0: 3875MB (7936000 512 byte sectors: 255H 63S/T 493C)
>> first try the following from ?<---- The rest of the
> message that was
>> cut off above
>> the loader prompt:
>>
>> etc. etc. until the mountroot> prompt, and after that
> even specifying
>> the device doesn't work (and ? doesn't list it). It
> seems to my
>> non-hacker eyes that the device is not attaching until
> after it should
>> be.
>>
>> Any help would be appreciated, and I can provide
> further information as
>> needed.
>
> Hi,
>
> It looks like your device is detected too late. Have you
> tried another USB port? Or plugging in another dummy USB
> device?

I have tried on all the ports at the back of the box, but I just
remembered there's another at the front which I will try this evening.
What do you mean by "dummy USB device"? Just having something else
plugged in at boot? I will also try another USB drive tonight.

Thanks,
James
From tlott at gamesnet.de  Tue Sep  8 22:20:32 2009
From: tlott at gamesnet.de (Tobias Lott)
Date: Tue Sep  8 22:20:39 2009
Subject: Problems with ZFS on AMD64 (and i386 now)
In-Reply-To: <20090908214402.43009577@sub.han.vpn.gamesnet.de>
References: <a7454e2f0909010624yf652445y855047b83d046cc4@mail.gmail.com>
	<200909011005.18200.jhb@freebsd.org>
	<20090908214402.43009577@sub.han.vpn.gamesnet.de>
Message-ID: <20090909001942.0affc96c@sub.han.vpn.gamesnet.de>



On Tue, 8 Sep 2009 21:44:02 +0200
Tobias Lott <tlott@gamesnet.de> wrote:

> 
> 
> On Tue, 1 Sep 2009 10:05:17 -0400
> John Baldwin <jhb@freebsd.org> wrote:
> 
> > On Tuesday 01 September 2009 9:24:24 am Maciej Jan Broniarz wrote:
> > > Hello,
> > > 
> > > I have installed Freebsd8-beta3 on a Phenom II Quad Core with 8 gb
> > > ram. When I create a zfs volume all works fine. Still, when I
> > > reboot the system it doesn't come up. It hangs with the following
> > > error:
> > > 
> > > http://img525.imageshack.us/img525/3832/freebsd8zfs.jpg
> > > 
> > > What might be the problem?
> > 
> > It's probably a NULL pointer dereference, but we would need a stack
> > trace to investigate this further.
> >
> My Problem seems to be related.
> 
> Updating a Machine to 8.0-BETA4 #3 caused same, its a i386 System
> using gpt with zfs-only volumes beside swap.
> 
> http://i25.tinypic.com/343p0s0.jpg
> 
> I'll try to see if I can get a stack trace
> 

Hey Everyone

I've managed to get some Output for this, using BETA2 LiveCD (gonna try
using BETA4 CD Tomorrow).

'zfs import -f poolname' triggered this, Booting kernel.old (BETA3)
and today built BETA4 Kernel Panic mounting zfs Volumes.
Booting single user mode I get output of zfs list and so on but
mounting whatever volume also Panics.



Stack output, if there's more you need I'll gladly help
http://i27.tinypic.com/2d78qpd.jpg
http://i31.tinypic.com/oqhv2w.jpg
http://i28.tinypic.com/oktsag.jpg

-- 
Tobias Lott
From pjd at FreeBSD.org  Tue Sep  8 23:57:36 2009
From: pjd at FreeBSD.org (Pawel Jakub Dawidek)
Date: Tue Sep  8 23:57:43 2009
Subject: 8.0-BETA4 panic: ffs_sync: rofs mod
In-Reply-To: <20090908202553.GA1368@mr-happy.com>
References: <20090908202553.GA1368@mr-happy.com>
Message-ID: <20090908235731.GG1539@garage.freebsd.pl>

On Tue, Sep 08, 2009 at 04:25:53PM -0400, Jeff Blank wrote:
> Hi,
> 
> My 8.0-BETA4/amd64 installation panicked when I attempted to create a
> file on zvol-backed UFS.  This installation is otherwise UFS-free, ZFS
> v13 w/gptzfsboot method linked from wiki, single zpool mirror
> (ad{4,6}p3).
> 
> # zfs create -V 18G z0/ufs0
> # newfs -U -L oldbender /dev/zvol/z0/ufs0
> # mount /dev/ufs/oldbender /old
> # touch /old/foo
> 
> The system usually panics immediately, but once it waited a few
> seconds to do so, and I saw the file had been created.  The file was
> not there upon reboot in all cases, and the filesystem was considered
> clean by fsck.
> 
> Should I expect this to work?  And/or is it a known issue?  (Didn't
> find any similar-looking problems by googling or browsing list
> archives.)
> 
> Please let me know if I need to provide more details.
[...]
> fs = /old
> panic: ffs_sync: rofs mod

I have no idea why UFS thinks file system is read-only.

I'm not able to reproduce your problem. Doing some stress tests on UFS
on top of ZVOL seems to work for me.

Is there anything unusual in your setup?

Maybe you could mail:

	# zpool status
	# zpool list
	# zfs get -r all

-- 
Pawel Jakub Dawidek                       http://www.wheel.pl
pjd@FreeBSD.org                           http://www.FreeBSD.org
FreeBSD committer                         Am I Evil? Yes, I Am!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20090908/ea8fda18/attachment.pgp
From grarpamp at gmail.com  Tue Sep  8 23:49:38 2009
From: grarpamp at gmail.com (grarpamp)
Date: Wed Sep  9 00:18:09 2009
Subject: tzsetup and EST5EDT
In-Reply-To: <107BC6AC-0CF6-423F-8AD9-843DA1370035@lassitu.de>
References: <d2e731a10909080024p7f2f456bi2794a122e5333d6a@mail.gmail.com>
	<107BC6AC-0CF6-423F-8AD9-843DA1370035@lassitu.de>
Message-ID: <d2e731a10909081649p2ad933aaod9c888cb9f9f1a7@mail.gmail.com>

>  I get EDT for "1 - Eastern Time" when running sysinstall on an installed
> system.  Is your local clock on the right day?

Sorry, must've been seeing things when I wrote EST. Complicated by
the 'EDT' displayed by tzsetup not[?], afaik, being an actual formal timezone
but just a marker as to the current state of the actual EST5EDT timezone.

I use NTP, UTC CMOS (no /etc/wall_cmos_clock), and /etc/localtime copied in.

1) EST - is UTC-5 all year round, and is in use in only a few
geographical places.
2) EST5EDT - is EST (UTC-5) in the 'winter', and 'EDT' (UTC-4) in the
'summer' (now, daylight savings time).

>  If you think sysinstall should produce "EST5EDT", you're expecting the
> wrong thing.

It might be a useful idea, with the current state alongside for
daylight savings zones.

> For quite some time, it's given the time zone abbreviation
> appropriate to the chosen location for the current date and time.

I don't know what the difference is between the 'New_York' and 'EST5EDT'
files. I suppose I could look at the zone compiler for that.
The more formal 'EST5EDT' seems to work fine for me.

87a75432ef636782207fa06d603585c0 /etc/localtime
3cf0ccc7d6b240390188367933c9cd90 /usr/share/zoneinfo/posixrules
3cf0ccc7d6b240390188367933c9cd90 /usr/share/zoneinfo/America/New_York
6fac20ee52a95b38ad0e1657f77aa4c4 /usr/share/zoneinfo/EST
87a75432ef636782207fa06d603585c0 /usr/share/zoneinfo/EST5EDT
From jfb at mr-happy.com  Wed Sep  9 00:55:07 2009
From: jfb at mr-happy.com (Jeff Blank)
Date: Wed Sep  9 00:55:14 2009
Subject: 8.0-BETA4 panic: ffs_sync: rofs mod
In-Reply-To: <20090908235731.GG1539@garage.freebsd.pl>
References: <20090908202553.GA1368@mr-happy.com>
	<20090908235731.GG1539@garage.freebsd.pl>
Message-ID: <20090909005504.GA12660@mr-happy.com>

On Wed, Sep 09, 2009 at 01:57:31AM +0200, Pawel Jakub Dawidek wrote:
> On Tue, Sep 08, 2009 at 04:25:53PM -0400, Jeff Blank wrote:
> > Please let me know if I need to provide more details.
> [...]
> > fs = /old
> > panic: ffs_sync: rofs mod
> 
> I have no idea why UFS thinks file system is read-only.

hmm, I do have it marked as read-only in /etc/fstab, but I'd been
mounting it with '-o rw'.  I just now commented out the fstab entry
and mounted it 'mount /dev/oldbender /old' and created files, and that
worked fine.

> I'm not able to reproduce your problem. Doing some stress tests on UFS
> on top of ZVOL seems to work for me.
> Is there anything unusual in your setup?

I don't think so.  maybe swapping to gmirror, but that's probably it.

> Maybe you could mail:
> 
> 	# zpool status
> 	# zpool list
> 	# zfs get -r all

attached.

Jeff
-------------- next part --------------
# zpool status
  pool: z0
 state: ONLINE
 scrub: none requested
config:

        NAME        STATE     READ WRITE CKSUM
        z0          ONLINE       0     0     0
          mirror    ONLINE       0     0     0
            ad4p3   ONLINE       0     0     0
            ad6p3   ONLINE       0     0     0

errors: No known data errors
# zpool list
NAME   SIZE   USED  AVAIL    CAP  HEALTH  ALTROOT
z0     141G  27.6G   113G    19%  ONLINE  -
# zfs get -r all
NAME          PROPERTY              VALUE                  SOURCE
z0            type                  filesystem             -
z0            creation              Thu Sep  3 23:16 2009  -
z0            used                  45.8G                  -
z0            available             93.0G                  -
z0            referenced            1.68G                  -
z0            compressratio         1.02x                  -
z0            mounted               yes                    -
z0            quota                 none                   default
z0            reservation           none                   default
z0            recordsize            128K                   default
z0            mountpoint            legacy                 local
z0            sharenfs              off                    default
z0            checksum              on                     default
z0            compression           off                    default
z0            atime                 on                     default
z0            devices               on                     default
z0            exec                  on                     default
z0            setuid                on                     default
z0            readonly              off                    local
z0            jailed                off                    default
z0            snapdir               hidden                 default
z0            aclmode               groupmask              default
z0            aclinherit            restricted             default
z0            canmount              on                     default
z0            shareiscsi            off                    default
z0            xattr                 off                    temporary
z0            copies                1                      default
z0            version               3                      -
z0            utf8only              off                    -
z0            normalization         none                   -
z0            casesensitivity       sensitive              -
z0            vscan                 off                    default
z0            nbmand                off                    default
z0            sharesmb              off                    default
z0            refquota              none                   default
z0            refreservation        none                   default
z0            primarycache          all                    default
z0            secondarycache        all                    default
z0            usedbysnapshots       0                      -
z0            usedbydataset         1.68G                  -
z0            usedbychildren        44.2G                  -
z0            usedbyrefreservation  0                      -
z0/crash      type                  filesystem             -
z0/crash      creation              Thu Sep  3 23:18 2009  -
z0/crash      used                  342M                   -
z0/crash      available             9.67G                  -
z0/crash      referenced            342M                   -
z0/crash      compressratio         2.88x                  -
z0/crash      mounted               yes                    -
z0/crash      quota                 10G                    local
z0/crash      reservation           none                   default
z0/crash      recordsize            128K                   default
z0/crash      mountpoint            /var/crash             local
z0/crash      sharenfs              off                    default
z0/crash      checksum              on                     default
z0/crash      compression           on                     local
z0/crash      atime                 on                     default
z0/crash      devices               on                     default
z0/crash      exec                  off                    local
z0/crash      setuid                off                    local
z0/crash      readonly              off                    inherited from z0
z0/crash      jailed                off                    default
z0/crash      snapdir               hidden                 default
z0/crash      aclmode               groupmask              default
z0/crash      aclinherit            restricted             default
z0/crash      canmount              on                     default
z0/crash      shareiscsi            off                    default
z0/crash      xattr                 off                    temporary
z0/crash      copies                1                      default
z0/crash      version               3                      -
z0/crash      utf8only              off                    -
z0/crash      normalization         none                   -
z0/crash      casesensitivity       sensitive              -
z0/crash      vscan                 off                    default
z0/crash      nbmand                off                    default
z0/crash      sharesmb              off                    default
z0/crash      refquota              none                   default
z0/crash      refreservation        none                   default
z0/crash      primarycache          all                    default
z0/crash      secondarycache        all                    default
z0/crash      usedbysnapshots       0                      -
z0/crash      usedbydataset         342M                   -
z0/crash      usedbychildren        0                      -
z0/crash      usedbyrefreservation  0                      -
z0/distfiles  type                  filesystem             -
z0/distfiles  creation              Thu Sep  3 23:19 2009  -
z0/distfiles  used                  4.93G                  -
z0/distfiles  available             93.0G                  -
z0/distfiles  referenced            4.93G                  -
z0/distfiles  compressratio         1.00x                  -
z0/distfiles  mounted               yes                    -
z0/distfiles  quota                 none                   default
z0/distfiles  reservation           none                   default
z0/distfiles  recordsize            128K                   default
z0/distfiles  mountpoint            /usr/local/distfiles   local
z0/distfiles  sharenfs              off                    default
z0/distfiles  checksum              on                     default
z0/distfiles  compression           off                    default
z0/distfiles  atime                 on                     default
z0/distfiles  devices               on                     default
z0/distfiles  exec                  on                     default
z0/distfiles  setuid                on                     default
z0/distfiles  readonly              off                    inherited from z0
z0/distfiles  jailed                off                    default
z0/distfiles  snapdir               hidden                 default
z0/distfiles  aclmode               groupmask              default
z0/distfiles  aclinherit            restricted             default
z0/distfiles  canmount              on                     default
z0/distfiles  shareiscsi            off                    default
z0/distfiles  xattr                 off                    temporary
z0/distfiles  copies                1                      default
z0/distfiles  version               3                      -
z0/distfiles  utf8only              off                    -
z0/distfiles  normalization         none                   -
z0/distfiles  casesensitivity       sensitive              -
z0/distfiles  vscan                 off                    default
z0/distfiles  nbmand                off                    default
z0/distfiles  sharesmb              off                    default
z0/distfiles  refquota              none                   default
z0/distfiles  refreservation        none                   default
z0/distfiles  primarycache          all                    default
z0/distfiles  secondarycache        all                    default
z0/distfiles  usedbysnapshots       0                      -
z0/distfiles  usedbydataset         4.93G                  -
z0/distfiles  usedbychildren        0                      -
z0/distfiles  usedbyrefreservation  0                      -
z0/homes      type                  filesystem             -
z0/homes      creation              Thu Sep  3 23:19 2009  -
z0/homes      used                  7.24G                  -
z0/homes      available             93.0G                  -
z0/homes      referenced            7.24G                  -
z0/homes      compressratio         1.00x                  -
z0/homes      mounted               yes                    -
z0/homes      quota                 none                   default
z0/homes      reservation           none                   default
z0/homes      recordsize            128K                   default
z0/homes      mountpoint            /usr/local/homes       local
z0/homes      sharenfs              off                    default
z0/homes      checksum              on                     default
z0/homes      compression           off                    default
z0/homes      atime                 on                     default
z0/homes      devices               on                     default
z0/homes      exec                  on                     default
z0/homes      setuid                on                     default
z0/homes      readonly              off                    inherited from z0
z0/homes      jailed                off                    default
z0/homes      snapdir               hidden                 default
z0/homes      aclmode               groupmask              default
z0/homes      aclinherit            restricted             default
z0/homes      canmount              on                     default
z0/homes      shareiscsi            off                    default
z0/homes      xattr                 off                    temporary
z0/homes      copies                1                      default
z0/homes      version               3                      -
z0/homes      utf8only              off                    -
z0/homes      normalization         none                   -
z0/homes      casesensitivity       sensitive              -
z0/homes      vscan                 off                    default
z0/homes      nbmand                off                    default
z0/homes      sharesmb              off                    default
z0/homes      refquota              none                   default
z0/homes      refreservation        none                   default
z0/homes      primarycache          all                    default
z0/homes      secondarycache        all                    default
z0/homes      usedbysnapshots       0                      -
z0/homes      usedbydataset         7.24G                  -
z0/homes      usedbychildren        0                      -
z0/homes      usedbyrefreservation  0                      -
z0/mp3        type                  filesystem             -
z0/mp3        creation              Thu Sep  3 23:19 2009  -
z0/mp3        used                  6.49G                  -
z0/mp3        available             93.0G                  -
z0/mp3        referenced            6.49G                  -
z0/mp3        compressratio         1.00x                  -
z0/mp3        mounted               yes                    -
z0/mp3        quota                 none                   default
z0/mp3        reservation           none                   default
z0/mp3        recordsize            128K                   default
z0/mp3        mountpoint            /usr/local/mp3         local
z0/mp3        sharenfs              off                    default
z0/mp3        checksum              on                     default
z0/mp3        compression           off                    default
z0/mp3        atime                 on                     default
z0/mp3        devices               on                     default
z0/mp3        exec                  on                     default
z0/mp3        setuid                on                     default
z0/mp3        readonly              off                    inherited from z0
z0/mp3        jailed                off                    default
z0/mp3        snapdir               hidden                 default
z0/mp3        aclmode               groupmask              default
z0/mp3        aclinherit            restricted             default
z0/mp3        canmount              on                     default
z0/mp3        shareiscsi            off                    default
z0/mp3        xattr                 off                    temporary
z0/mp3        copies                1                      default
z0/mp3        version               3                      -
z0/mp3        utf8only              off                    -
z0/mp3        normalization         none                   -
z0/mp3        casesensitivity       sensitive              -
z0/mp3        vscan                 off                    default
z0/mp3        nbmand                off                    default
z0/mp3        sharesmb              off                    default
z0/mp3        refquota              none                   default
z0/mp3        refreservation        none                   default
z0/mp3        primarycache          all                    default
z0/mp3        secondarycache        all                    default
z0/mp3        usedbysnapshots       0                      -
z0/mp3        usedbydataset         6.49G                  -
z0/mp3        usedbychildren        0                      -
z0/mp3        usedbyrefreservation  0                      -
z0/obj        type                  filesystem             -
z0/obj        creation              Thu Sep  3 23:20 2009  -
z0/obj        used                  3.15G                  -
z0/obj        available             93.0G                  -
z0/obj        referenced            3.15G                  -
z0/obj        compressratio         1.00x                  -
z0/obj        mounted               yes                    -
z0/obj        quota                 none                   default
z0/obj        reservation           none                   default
z0/obj        recordsize            128K                   default
z0/obj        mountpoint            /usr/obj               local
z0/obj        sharenfs              off                    default
z0/obj        checksum              on                     default
z0/obj        compression           off                    default
z0/obj        atime                 on                     default
z0/obj        devices               on                     default
z0/obj        exec                  on                     default
z0/obj        setuid                on                     default
z0/obj        readonly              off                    inherited from z0
z0/obj        jailed                off                    default
z0/obj        snapdir               hidden                 default
z0/obj        aclmode               groupmask              default
z0/obj        aclinherit            restricted             default
z0/obj        canmount              on                     default
z0/obj        shareiscsi            off                    default
z0/obj        xattr                 off                    temporary
z0/obj        copies                1                      default
z0/obj        version               3                      -
z0/obj        utf8only              off                    -
z0/obj        normalization         none                   -
z0/obj        casesensitivity       sensitive              -
z0/obj        vscan                 off                    default
z0/obj        nbmand                off                    default
z0/obj        sharesmb              off                    default
z0/obj        refquota              none                   default
z0/obj        refreservation        none                   default
z0/obj        primarycache          all                    default
z0/obj        secondarycache        all                    default
z0/obj        usedbysnapshots       0                      -
z0/obj        usedbydataset         3.15G                  -
z0/obj        usedbychildren        0                      -
z0/obj        usedbyrefreservation  0                      -
z0/ports      type                  filesystem             -
z0/ports      creation              Thu Sep  3 23:20 2009  -
z0/ports      used                  325M                   -
z0/ports      available             93.0G                  -
z0/ports      referenced            325M                   -
z0/ports      compressratio         1.20x                  -
z0/ports      mounted               yes                    -
z0/ports      quota                 none                   default
z0/ports      reservation           none                   default
z0/ports      recordsize            128K                   default
z0/ports      mountpoint            /usr/ports             local
z0/ports      sharenfs              off                    default
z0/ports      checksum              on                     default
z0/ports      compression           on                     local
z0/ports      atime                 on                     default
z0/ports      devices               on                     default
z0/ports      exec                  off                    local
z0/ports      setuid                off                    local
z0/ports      readonly              off                    inherited from z0
z0/ports      jailed                off                    default
z0/ports      snapdir               hidden                 default
z0/ports      aclmode               groupmask              default
z0/ports      aclinherit            restricted             default
z0/ports      canmount              on                     default
z0/ports      shareiscsi            off                    default
z0/ports      xattr                 off                    temporary
z0/ports      copies                1                      default
z0/ports      version               3                      -
z0/ports      utf8only              off                    -
z0/ports      normalization         none                   -
z0/ports      casesensitivity       sensitive              -
z0/ports      vscan                 off                    default
z0/ports      nbmand                off                    default
z0/ports      sharesmb              off                    default
z0/ports      refquota              none                   default
z0/ports      refreservation        none                   default
z0/ports      primarycache          all                    default
z0/ports      secondarycache        all                    default
z0/ports      usedbysnapshots       0                      -
z0/ports      usedbydataset         325M                   -
z0/ports      usedbychildren        0                      -
z0/ports      usedbyrefreservation  0                      -
z0/tmp        type                  filesystem             -
z0/tmp        creation              Thu Sep  3 23:17 2009  -
z0/tmp        used                  7.56M                  -
z0/tmp        available             5.99G                  -
z0/tmp        referenced            7.56M                  -
z0/tmp        compressratio         3.33x                  -
z0/tmp        mounted               yes                    -
z0/tmp        quota                 6G                     local
z0/tmp        reservation           none                   default
z0/tmp        recordsize            128K                   default
z0/tmp        mountpoint            /tmp                   local
z0/tmp        sharenfs              off                    default
z0/tmp        checksum              on                     default
z0/tmp        compression           on                     local
z0/tmp        atime                 on                     default
z0/tmp        devices               on                     default
z0/tmp        exec                  on                     default
z0/tmp        setuid                off                    local
z0/tmp        readonly              off                    inherited from z0
z0/tmp        jailed                off                    default
z0/tmp        snapdir               hidden                 default
z0/tmp        aclmode               groupmask              default
z0/tmp        aclinherit            restricted             default
z0/tmp        canmount              on                     default
z0/tmp        shareiscsi            off                    default
z0/tmp        xattr                 off                    temporary
z0/tmp        copies                1                      default
z0/tmp        version               3                      -
z0/tmp        utf8only              off                    -
z0/tmp        normalization         none                   -
z0/tmp        casesensitivity       sensitive              -
z0/tmp        vscan                 off                    default
z0/tmp        nbmand                off                    default
z0/tmp        sharesmb              off                    default
z0/tmp        refquota              none                   default
z0/tmp        refreservation        none                   default
z0/tmp        primarycache          all                    default
z0/tmp        secondarycache        all                    default
z0/tmp        usedbysnapshots       0                      -
z0/tmp        usedbydataset         7.56M                  -
z0/tmp        usedbychildren        0                      -
z0/tmp        usedbyrefreservation  0                      -
z0/ufs0       type                  volume                 -
z0/ufs0       creation              Tue Sep  8 20:47 2009  -
z0/ufs0       used                  18G                    -
z0/ufs0       available             111G                   -
z0/ufs0       referenced            6.79M                  -
z0/ufs0       compressratio         1.00x                  -
z0/ufs0       reservation           none                   default
z0/ufs0       volsize               18G                    -
z0/ufs0       volblocksize          8K                     -
z0/ufs0       checksum              on                     default
z0/ufs0       compression           off                    default
z0/ufs0       readonly              off                    inherited from z0
z0/ufs0       shareiscsi            off                    default
z0/ufs0       copies                1                      default
z0/ufs0       refreservation        18G                    local
z0/ufs0       primarycache          all                    default
z0/ufs0       secondarycache        all                    default
z0/ufs0       usedbysnapshots       0                      -
z0/ufs0       usedbydataset         6.79M                  -
z0/ufs0       usedbychildren        0                      -
z0/ufs0       usedbyrefreservation  18.0G                  -
z0/usr        type                  filesystem             -
z0/usr        creation              Thu Sep  3 23:17 2009  -
z0/usr        used                  259M                   -
z0/usr        available             93.0G                  -
z0/usr        referenced            259M                   -
z0/usr        compressratio         1.00x                  -
z0/usr        mounted               yes                    -
z0/usr        quota                 none                   default
z0/usr        reservation           none                   default
z0/usr        recordsize            128K                   default
z0/usr        mountpoint            /usr                   local
z0/usr        sharenfs              off                    default
z0/usr        checksum              on                     default
z0/usr        compression           off                    default
z0/usr        atime                 on                     default
z0/usr        devices               on                     default
z0/usr        exec                  on                     default
z0/usr        setuid                on                     default
z0/usr        readonly              off                    inherited from z0
z0/usr        jailed                off                    default
z0/usr        snapdir               hidden                 default
z0/usr        aclmode               groupmask              default
z0/usr        aclinherit            restricted             default
z0/usr        canmount              on                     default
z0/usr        shareiscsi            off                    default
z0/usr        xattr                 off                    temporary
z0/usr        copies                1                      default
z0/usr        version               3                      -
z0/usr        utf8only              off                    -
z0/usr        normalization         none                   -
z0/usr        casesensitivity       sensitive              -
z0/usr        vscan                 off                    default
z0/usr        nbmand                off                    default
z0/usr        sharesmb              off                    default
z0/usr        refquota              none                   default
z0/usr        refreservation        none                   default
z0/usr        primarycache          all                    default
z0/usr        secondarycache        all                    default
z0/usr        usedbysnapshots       0                      -
z0/usr        usedbydataset         259M                   -
z0/usr        usedbychildren        0                      -
z0/usr        usedbyrefreservation  0                      -
z0/usrlocal   type                  filesystem             -
z0/usrlocal   creation              Thu Sep  3 23:19 2009  -
z0/usrlocal   used                  3.08G                  -
z0/usrlocal   available             93.0G                  -
z0/usrlocal   referenced            3.08G                  -
z0/usrlocal   compressratio         1.00x                  -
z0/usrlocal   mounted               yes                    -
z0/usrlocal   quota                 none                   default
z0/usrlocal   reservation           none                   default
z0/usrlocal   recordsize            128K                   default
z0/usrlocal   mountpoint            /usr/local             local
z0/usrlocal   sharenfs              off                    default
z0/usrlocal   checksum              on                     default
z0/usrlocal   compression           off                    default
z0/usrlocal   atime                 on                     default
z0/usrlocal   devices               on                     default
z0/usrlocal   exec                  on                     default
z0/usrlocal   setuid                on                     default
z0/usrlocal   readonly              off                    inherited from z0
z0/usrlocal   jailed                off                    default
z0/usrlocal   snapdir               hidden                 default
z0/usrlocal   aclmode               groupmask              default
z0/usrlocal   aclinherit            restricted             default
z0/usrlocal   canmount              on                     default
z0/usrlocal   shareiscsi            off                    default
z0/usrlocal   xattr                 off                    temporary
z0/usrlocal   copies                1                      default
z0/usrlocal   version               3                      -
z0/usrlocal   utf8only              off                    -
z0/usrlocal   normalization         none                   -
z0/usrlocal   casesensitivity       sensitive              -
z0/usrlocal   vscan                 off                    default
z0/usrlocal   nbmand                off                    default
z0/usrlocal   sharesmb              off                    default
z0/usrlocal   refquota              none                   default
z0/usrlocal   refreservation        none                   default
z0/usrlocal   primarycache          all                    default
z0/usrlocal   secondarycache        all                    default
z0/usrlocal   usedbysnapshots       0                      -
z0/usrlocal   usedbydataset         3.08G                  -
z0/usrlocal   usedbychildren        0                      -
z0/usrlocal   usedbyrefreservation  0                      -
z0/var        type                  filesystem             -
z0/var        creation              Thu Sep  3 23:18 2009  -
z0/var        used                  110M                   -
z0/var        available             93.0G                  -
z0/var        referenced            110M                   -
z0/var        compressratio         1.00x                  -
z0/var        mounted               yes                    -
z0/var        quota                 none                   default
z0/var        reservation           none                   default
z0/var        recordsize            128K                   default
z0/var        mountpoint            /var                   local
z0/var        sharenfs              off                    default
z0/var        checksum              on                     default
z0/var        compression           off                    default
z0/var        atime                 on                     default
z0/var        devices               on                     default
z0/var        exec                  on                     default
z0/var        setuid                on                     default
z0/var        readonly              off                    inherited from z0
z0/var        jailed                off                    default
z0/var        snapdir               hidden                 default
z0/var        aclmode               groupmask              default
z0/var        aclinherit            restricted             default
z0/var        canmount              on                     default
z0/var        shareiscsi            off                    default
z0/var        xattr                 off                    temporary
z0/var        copies                1                      default
z0/var        version               3                      -
z0/var        utf8only              off                    -
z0/var        normalization         none                   -
z0/var        casesensitivity       sensitive              -
z0/var        vscan                 off                    default
z0/var        nbmand                off                    default
z0/var        sharesmb              off                    default
z0/var        refquota              none                   default
z0/var        refreservation        none                   default
z0/var        primarycache          all                    default
z0/var        secondarycache        all                    default
z0/var        usedbysnapshots       0                      -
z0/var        usedbydataset         110M                   -
z0/var        usedbychildren        0                      -
z0/var        usedbyrefreservation  0                      -
z0/vartmp     type                  filesystem             -
z0/vartmp     creation              Thu Sep  3 23:20 2009  -
z0/vartmp     used                  77K                    -
z0/vartmp     available             6.00G                  -
z0/vartmp     referenced            77K                    -
z0/vartmp     compressratio         1.33x                  -
z0/vartmp     mounted               yes                    -
z0/vartmp     quota                 6G                     local
z0/vartmp     reservation           256M                   local
z0/vartmp     recordsize            128K                   default
z0/vartmp     mountpoint            /var/tmp               local
z0/vartmp     sharenfs              off                    default
z0/vartmp     checksum              on                     default
z0/vartmp     compression           on                     local
z0/vartmp     atime                 on                     default
z0/vartmp     devices               on                     default
z0/vartmp     exec                  on                     default
z0/vartmp     setuid                off                    local
z0/vartmp     readonly              off                    inherited from z0
z0/vartmp     jailed                off                    default
z0/vartmp     snapdir               hidden                 default
z0/vartmp     aclmode               groupmask              default
z0/vartmp     aclinherit            restricted             default
z0/vartmp     canmount              on                     default
z0/vartmp     shareiscsi            off                    default
z0/vartmp     xattr                 off                    temporary
z0/vartmp     copies                1                      default
z0/vartmp     version               3                      -
z0/vartmp     utf8only              off                    -
z0/vartmp     normalization         none                   -
z0/vartmp     casesensitivity       sensitive              -
z0/vartmp     vscan                 off                    default
z0/vartmp     nbmand                off                    default
z0/vartmp     sharesmb              off                    default
z0/vartmp     refquota              none                   default
z0/vartmp     refreservation        none                   default
z0/vartmp     primarycache          all                    default
z0/vartmp     secondarycache        all                    default
z0/vartmp     usedbysnapshots       0                      -
z0/vartmp     usedbydataset         77K                    -
z0/vartmp     usedbychildren        0                      -
z0/vartmp     usedbyrefreservation  0                      -
From rizzo at iet.unipi.it  Wed Sep  9 00:55:43 2009
From: rizzo at iet.unipi.it (Luigi Rizzo)
Date: Wed Sep  9 00:55:50 2009
Subject: clock error: callouts are run one tick late
Message-ID: <20090909010137.GA74897@onelab2.iet.unipi.it>

RELENG_8/amd64 (can not try on i386) has the following problem:

	callout_reset(..., t, ...)

processes the callout after t+1 ticks instead of the t ticks
that one sees on RELENG_7 and earlier.

I found it by pure chance, noticing that dummynet on RELENG_8
has a jitter that is two ticks instead of one tick.
Other systems with rely on frequent callouts might see
problems as well.

An indirect way to see the problem is the following:

	kldload dummynet

	sysctl net.inet.ip.dummynet.tick_adjustment; \
	sleep 1; sysctl net.inet.ip.dummynet.tick_adjustment

on a working system, the variable should remain mostly unchanged;
on a non-working system you see it growing at a rate HZ/2

I suspect the bug is introduced by the change in kern_timeout.c rev. 1.114

http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/kern/kern_timeout.c.diff?r1=1.113;r2=1.114

which changes softclock() to stop before the current 'ticks'
so processes everything one tick late.

I understand the race described in the cvs log, but this does
not seem a proper fix -- it violates POLA by changing the semantics
of callout_reset(), and does not really fix the race, but just adds
an extra uncertainty of 1 tick on when a given callout will be run

If the problem is a race between hardclock() which updates 'ticks',
and the various hardclock_cpu() instances which might arrive early,
I would suggest two alternative options:

1. create a per-cpu 'ticks' (say a field cc_ticks in struct callout_cpu),
   increment it at the start of hardclock_cpu, and use cc->ticks
   instead of 'ticks' in the various callout functions involved
   with manipulation of the callwheel
   callout_tick(), softclock(), callout_reset_on()

2. start softclock() at cc->cc_softticks -1, i.e.

	...
	CC_LOCK(cc)
   -	while (cc->cc_softticks != ticks) {
   +	while (cc->cc_softticks-1 != ticks) {
 	...

   so we can catch up any work leftover due to the race.

I think option #1 is preferable as it should completely remove
the race condition, though #2 might be reasonable as a quick
fix should we decide to add it to 8.0

	cheers
	luigi
From nakaji at jp.freebsd.org  Wed Sep  9 00:59:47 2009
From: nakaji at jp.freebsd.org (NAKAJI Hiroyuki)
Date: Wed Sep  9 01:01:07 2009
Subject: ELF interpreter /libexec/ld-elf.so.1 not found
In-Reply-To: <20090908055055.C68375@maildrop.int.zabbadoz.net> (Bjoern
	A. Zeeb's message of "Tue, 8 Sep 2009 05:51:27 +0000 (UTC)")
References: <20090829182437.GV37252@cicely7.cicely.de>
	<86ljkqk6vw.fsf@ra333.heimat.gr.jp>
	<20090907173139.GG15218@cicely7.cicely.de>
	<20090907175855.W68375@maildrop.int.zabbadoz.net>
	<86eiqijpd2.fsf@ra333.heimat.gr.jp>
	<20090908055055.C68375@maildrop.int.zabbadoz.net>
Message-ID: <86tyzdhr11.fsf@ra333.heimat.gr.jp>

>>>>> In <20090908055055.C68375@maildrop.int.zabbadoz.net> 
>>>>>	"Bjoern A. Zeeb" <bz@FreeBSD.org> wrote:

> Good morning,

Good morning from Japan,

> >> It was comitted to HEAD, MFCed to stable/8 a few days ago and MFCed
> >> to stable/7 earlier today.
> >
> > Thanks. Is it r196924?
> > http://lists.freebsd.org/pipermail/svn-src-stable-7/2009-September/001900.html

> Yes, exactly.

I see. I'll test again. If I find a problem, I will post it to
-stable. :)

Thanks.
-- 
NAKAJI Hiroyuki
From rizzo at iet.unipi.it  Wed Sep  9 01:10:11 2009
From: rizzo at iet.unipi.it (Luigi Rizzo)
Date: Wed Sep  9 01:10:17 2009
Subject: clock error: callouts are run one tick late
In-Reply-To: <20090909010137.GA74897@onelab2.iet.unipi.it>
References: <20090909010137.GA74897@onelab2.iet.unipi.it>
Message-ID: <20090909011606.GA77031@onelab2.iet.unipi.it>

On Wed, Sep 09, 2009 at 03:01:37AM +0200, Luigi Rizzo wrote:
> RELENG_8/amd64 (can not try on i386) has the following problem:
> 
> 	callout_reset(..., t, ...)
> 
> processes the callout after t+1 ticks instead of the t ticks
> that one sees on RELENG_7 and earlier.
> 
> I found it by pure chance, noticing that dummynet on RELENG_8
> has a jitter that is two ticks instead of one tick.
> Other systems with rely on frequent callouts might see
> problems as well.
> 
> An indirect way to see the problem is the following:
> 
> 	kldload dummynet
> 
> 	sysctl net.inet.ip.dummynet.tick_adjustment; \
> 	sleep 1; sysctl net.inet.ip.dummynet.tick_adjustment
> 
> on a working system, the variable should remain mostly unchanged;
> on a non-working system you see it growing at a rate HZ/2
> 
> I suspect the bug is introduced by the change in kern_timeout.c rev. 1.114
> 
> http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/kern/kern_timeout.c.diff?r1=1.113;r2=1.114
> 
> which changes softclock() to stop before the current 'ticks'
> so processes everything one tick late.
> 
> I understand the race described in the cvs log, but this does
> not seem a proper fix -- it violates POLA by changing the semantics
> of callout_reset(), and does not really fix the race, but just adds
> an extra uncertainty of 1 tick on when a given callout will be run
> 
> If the problem is a race between hardclock() which updates 'ticks',
> and the various hardclock_cpu() instances which might arrive early,
> I would suggest two alternative options:
> 
> 1. create a per-cpu 'ticks' (say a field cc_ticks in struct callout_cpu),
>    increment it at the start of hardclock_cpu, and use cc->ticks
>    instead of 'ticks' in the various callout functions involved
>    with manipulation of the callwheel
>    callout_tick(), softclock(), callout_reset_on()
> 
> 2. start softclock() at cc->cc_softticks -1, i.e.
> 
> 	...
> 	CC_LOCK(cc)
>    -	while (cc->cc_softticks != ticks) {
>    +	while (cc->cc_softticks-1 != ticks) {
>  	...

#2 also need this change in callout_tick()

        mtx_lock_spin_flags(&cc->cc_lock, MTX_QUIET);
     -  for (; (cc->cc_softticks - ticks) < 0; cc->cc_softticks++) {
     +  for (; (cc->cc_softticks - ticks) <= 0; cc->cc_softticks++) {
                bucket = cc->cc_softticks & callwheelmask;

Just tested it, it seems to fix the problem.

cheers
luigi
From sam at errno.com  Wed Sep  9 01:50:31 2009
From: sam at errno.com (Sam Leffler)
Date: Wed Sep  9 01:50:38 2009
Subject: ath(4) Atheros AR9285 support
In-Reply-To: <4AA65ABE.4000207@lazybytes.org>
References: <4AA65ABE.4000207@lazybytes.org>
Message-ID: <4AA709E5.2000607@errno.com>

Sergey Vinogradov wrote:
> Hi,
> Just wanted to know, if there will be any Atheros AR9285 support in
> ath(4) driver in nearest future? I've got my ASUS Eee 1005HA with one of
> these wireless adapters, and it doesn't seem to be working.
> 

I have no plans to do anything.  I asked for a card for a long time but 
never got one.  Now I've got zero time.

	Sam

From pjd at FreeBSD.org  Wed Sep  9 05:42:58 2009
From: pjd at FreeBSD.org (Pawel Jakub Dawidek)
Date: Wed Sep  9 05:43:07 2009
Subject: Problems with ZFS on AMD64 (and i386 now)
In-Reply-To: <20090909001942.0affc96c@sub.han.vpn.gamesnet.de>
References: <a7454e2f0909010624yf652445y855047b83d046cc4@mail.gmail.com>
	<200909011005.18200.jhb@freebsd.org>
	<20090908214402.43009577@sub.han.vpn.gamesnet.de>
	<20090909001942.0affc96c@sub.han.vpn.gamesnet.de>
Message-ID: <20090909054249.GH1539@garage.freebsd.pl>

On Wed, Sep 09, 2009 at 12:19:42AM +0200, Tobias Lott wrote:
> Hey Everyone
> 
> I've managed to get some Output for this, using BETA2 LiveCD (gonna try
> using BETA4 CD Tomorrow).
> 
> 'zfs import -f poolname' triggered this, Booting kernel.old (BETA3)
> and today built BETA4 Kernel Panic mounting zfs Volumes.
> Booting single user mode I get output of zfs list and so on but
> mounting whatever volume also Panics.

Why -f? Were there a poblem in importing pool?

> Stack output, if there's more you need I'll gladly help
> http://i27.tinypic.com/2d78qpd.jpg
> http://i31.tinypic.com/oqhv2w.jpg
> http://i28.tinypic.com/oktsag.jpg

Could you also provide top part of the backtrace?

-- 
Pawel Jakub Dawidek                       http://www.wheel.pl
pjd@FreeBSD.org                           http://www.FreeBSD.org
FreeBSD committer                         Am I Evil? Yes, I Am!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20090909/856255f4/attachment-0001.pgp
From mel.flynn+fbsd.current at mailing.thruhere.net  Wed Sep  9 07:02:37 2009
From: mel.flynn+fbsd.current at mailing.thruhere.net (Mel Flynn)
Date: Wed Sep  9 07:02:44 2009
Subject: 8.0-BETA4 panic: ffs_sync: rofs mod
In-Reply-To: <20090909005504.GA12660@mr-happy.com>
References: <20090908202553.GA1368@mr-happy.com>
	<20090908235731.GG1539@garage.freebsd.pl>
	<20090909005504.GA12660@mr-happy.com>
Message-ID: <200909090902.34055.mel.flynn+fbsd.current@mailing.thruhere.net>

On Wednesday 09 September 2009 02:55:04 Jeff Blank wrote:
> On Wed, Sep 09, 2009 at 01:57:31AM +0200, Pawel Jakub Dawidek wrote:
> > On Tue, Sep 08, 2009 at 04:25:53PM -0400, Jeff Blank wrote:
> > > Please let me know if I need to provide more details.
> >
> > [...]
> >
> > > fs = /old
> > > panic: ffs_sync: rofs mod
> >
> > I have no idea why UFS thinks file system is read-only.
>
> hmm, I do have it marked as read-only in /etc/fstab, but I'd been
> mounting it with '-o rw'.

This problem has also been seen on -questions [1] and I forgot to follow
up after time issues. According to the poster it's easy to reproduce:
- have a mountpoint in /etc/fstab with ro options
- unmount the mountpoint
- remount using -o rw

The behavior does not occur if one uses mount -u -o rw without unmounting. I
think this is a too easy way to panic the kernel.

[1] <http://www.freebsd.org/cgi/getmsg.cgi?fetch=407379+0+/usr/local/www/db/text/2009/freebsd-questions/20090823.freebsd-questions>
-- 
Mel
From koleman at gmail.com  Wed Sep  9 05:31:56 2009
From: koleman at gmail.com (=?ISO-8859-1?B?QW50dGkgS29sZWhtYWluZW4=?=)
Date: Wed Sep  9 07:02:47 2009
Subject: problems with usb if  you unload and reload kernel modules
Message-ID: <1252477908753@koleman_gmail.com>


From hselasky at c2i.net  Wed Sep  9 07:48:17 2009
From: hselasky at c2i.net (Hans Petter Selasky)
Date: Wed Sep  9 07:48:24 2009
Subject: problems with usb if  you unload and reload kernel modules
In-Reply-To: <1252477908753@koleman_gmail.com>
References: <1252477908753@koleman_gmail.com>
Message-ID: <200909090948.40826.hselasky@c2i.net>

On Wednesday 09 September 2009 08:31:48 Antti Kolehmainen wrote:

Please be more specific.

--HPS
From tlott at gamesnet.de  Wed Sep  9 08:13:51 2009
From: tlott at gamesnet.de (Tobias Lott)
Date: Wed Sep  9 08:14:04 2009
Subject: Problems with ZFS on AMD64 (and i386 now)
In-Reply-To: <20090909054249.GH1539@garage.freebsd.pl>
References: <a7454e2f0909010624yf652445y855047b83d046cc4@mail.gmail.com>
	<200909011005.18200.jhb@freebsd.org>
	<20090908214402.43009577@sub.han.vpn.gamesnet.de>
	<20090909001942.0affc96c@sub.han.vpn.gamesnet.de>
	<20090909054249.GH1539@garage.freebsd.pl>
Message-ID: <20090909101346.01887a02@sub.han.vpn.gamesnet.de>



On Wed, 9 Sep 2009 07:42:49 +0200
Pawel Jakub Dawidek <pjd@FreeBSD.org> wrote:

> On Wed, Sep 09, 2009 at 12:19:42AM +0200, Tobias Lott wrote:
> > Hey Everyone
> > 
> > I've managed to get some Output for this, using BETA2 LiveCD (gonna
> > try using BETA4 CD Tomorrow).
> > 
> > 'zfs import -f poolname' triggered this, Booting kernel.old (BETA3)
> > and today built BETA4 Kernel Panic mounting zfs Volumes.
> > Booting single user mode I get output of zfs list and so on but
> > mounting whatever volume also Panics.
> 
> Why -f? Were there a poblem in importing pool?
> 
> > Stack output, if there's more you need I'll gladly help
> > http://i27.tinypic.com/2d78qpd.jpg
> > http://i31.tinypic.com/oqhv2w.jpg
> > http://i28.tinypic.com/oktsag.jpg
> 
> Could you also provide top part of the backtrace?
> 
Oh yeah my bad

http://i29.tinypic.com/nqwxo2.jpg
http://i26.tinypic.com/209hanm.jpg

-- 
Tobias Lott
From ale at FreeBSD.org  Wed Sep  9 08:26:31 2009
From: ale at FreeBSD.org (Alex Dupre)
Date: Wed Sep  9 08:26:38 2009
Subject: ath(4) Atheros AR9285 support
In-Reply-To: <4AA6ACF1.3040501@lazybytes.org>
References: <4AA65ABE.4000207@lazybytes.org> <4AA668E0.1010305@FreeBSD.org>
	<4AA6ACF1.3040501@lazybytes.org>
Message-ID: <4AA766B4.4080500@FreeBSD.org>

Sergey Vinogradov ha scritto:
> Well, despite the fact that "device ath", and all related stuff are
> included in GENERIC kernel in 8.0-BETA4, I have no ath0 interface.
> "dmesg | grep -i ath" gives nothing (well, as a matter of fact it gives
> "alc0: <Atheros AR8132 PCIe Fast Ethernet> ... ", but alc0 doesn't work
> either, link handling is broken as I understand). Is there something I'm
> doing wrong, or something I can do to help the development? :)

Well, I have a board with an AR9280 (0x002a) and works fine OOTB. I had
no experience with AR9285 (0x002b).

#define AR9280_DEVID_PCIE	0x002a         /* AR9280 PCI-E Merlin */
#define AR9285_DEVID_PCIE	0x002b         /* AR9285 PCI-E Kite */

-- 
Alex Dupre
From gary.jennejohn at freenet.de  Wed Sep  9 08:45:32 2009
From: gary.jennejohn at freenet.de (Gary Jennejohn)
Date: Wed Sep  9 08:45:39 2009
Subject: CFH: fix multimedia/pwcbsd with usb2
In-Reply-To: <20090908201713.GD41185@e.0x20.net>
References: <20090908201713.GD41185@e.0x20.net>
Message-ID: <20090909104528.20b28e65@ernst.jennejohn.org>

On Tue, 8 Sep 2009 22:17:13 +0200
Lars Engels <lars.engels@0x20.net> wrote:

> could someone with some more USB and C knowledge than me take a look at
> multimedia/pwcbsd?
> I'd really like to get the port fixed before the ports freeze starts.
> Here is the compile output:
> 

The patches under ~gj/work on freefall at least allow it to compile.  I
can't test whether it works, however.

Let me know when you have them so I can delete them.

---
Gary Jennejohn
From ziggi at yandex.ru  Wed Sep  9 10:07:10 2009
From: ziggi at yandex.ru (Borodin Oleg)
Date: Wed Sep  9 10:07:17 2009
Subject: wpa_supplicant not found AP without SSID in beacon packet
In-Reply-To: <4AA44B53.8060702@errno.com>
References: <4AA41025.5080908@yandex.ru> <4AA44B53.8060702@errno.com>
Message-ID: <4AA77E4B.5060006@yandex.ru>

Sam Leffler ?????:
> Borodin Oleg wrote:
>>
>> Hi!
>>
>> wpa_supplicant "not found" AP without SSID in beacon packets. With same
>> device and configuration, but FreeBSD7.2 - work without problems.
>>
>>
>
> You seem to have disabled scan_ssid in your wpa_supplicant.conf file. 
> It appears this causes wpa_supplicant to not supply the ssid when 
> scanning so the net80211 layer never sends directed ProbeRequest 
> frames and then ap does not respond.  Try enabling scan_ssid for WNET1 
> and verify the directed probe request frames are sent.
>
>     Sam
> _______________________________________________
>
Of course, I tried to turn on and off scan_ssid. No results.
I do not know much logic WiFI, perhaps the problem with disassembly 
beacon packet of access point?

Or, more likely to parse the answer to the AP on ProbeRequest from FBSD?

What is?...
wlan0: [00:23:5e:75:f7:c2] discard unhandled information element, id 
133, len 30

---
Best regards,

Borodin Oleg
Kaliningrad,Russia
ziggi@inbox.ru


From raul at pop.isdefe.es  Wed Sep  9 11:56:03 2009
From: raul at pop.isdefe.es (Raul)
Date: Wed Sep  9 11:56:10 2009
Subject: Boot-time hang with the CISS driver on HP 385
In-Reply-To: <4A5EFFF7.4060708@pop.isdefe.es>
References: <54854a7a0907150322n52a3595el5352a3987d2c75ac@mail.gmail.com>	<58c737d70907151035ya9a829eyf4945d1fadc4ce0e@mail.gmail.com>
	<4A5EFFF7.4060708@pop.isdefe.es>
Message-ID: <4AA797D1.9050409@pop.isdefe.es>

I haven't had too much spare time to put on it so no idea how this boot 
hangs have been evolved. I've tried once again with yesterday's RELENG_8 
sources with the same results except for the message from the kernel 
(safe boot):

....
ciss0: PERFORMANT Transport
ciss0: can't allocate interrupt
panic: mtx_unlock() of spin mutex (null) @ /usr/src/sys/dev/ciss/ciss.c:1903
cpuid = 0
KBD: enter: panic
....

Looking at bios, ciss has irq 7 and that interrupt is shared with iLO 
and bge0 ???. Trying to disable them, from bios, doesn't help. 
RELENG_7_2 run like a charm on that boxes.

I've two of that boxes ready to test whatever you ask :).

Regards,
Raul
From rnoland at FreeBSD.org  Wed Sep  9 13:24:25 2009
From: rnoland at FreeBSD.org (Robert Noland)
Date: Wed Sep  9 13:24:32 2009
Subject: Funding ODD support
In-Reply-To: <1252440109.85394.2430.camel@balrog.2hip.net>
References: <1252225381.00160049.1252212601@10.7.7.3>
	<4AA68C8A.4060405@FreeBSD.org>
	<1252440109.85394.2430.camel@balrog.2hip.net>
Message-ID: <1252502657.85394.3498.camel@balrog.2hip.net>

On Tue, 2009-09-08 at 15:01 -0500, Robert Noland wrote:
> On Tue, 2009-09-08 at 19:55 +0300, Alexander Motin wrote:
> > Harald Schmalzbauer wrote:
> > > I'm looking for somebody who has time and knowledge to fix ODD support
> > > in FreeBSD.
> > > I'm willing to sponsor a decent ammount.
> > > My problem is that I can't use FreeBSD for any task in which CD or DVD
> > > is involved.
> > > What I want is read/write support for any ATAPI/S-ATA ODD regarding
> > > ISO9660 and audio. Of course I'd love to have UDF support also, but for
> > > the beginning I'd be glad if FreeBSD could boot with an inserted audio
> > > CD. This has been a problem for more than two years now, and disabling
> > > DMA support for ata devices isn't a satisfying solution.
> > > 
> > > So if you think ypu can fix this and make growisofs and cdrtools working
> > > with ATAPI and SATA devices, please contact me.
> > > If we have working ODD support in 8.0-release I'll donate 100 extra bucks.
> > 
> > Funding is good, but could you first once more repeat what is your
> > problem? Which controller do you use? Which drive? Which disks and which
> > applications? Have you tried to use different controllers, drives,
> > disks, applications? I am asking because there quite a lot of people
> > successfully using ODD on FreeBSD.
> 
> FWIW, some of the recent changes do seem to have broken things a bit for
> me... But I can't quite put my finger on where the breakage is.  Some
> apps seem to work, depending on media, while other don't (that used to).
> For example I can burn a data DVD using tkdvd, but not brasero.  brasero
> does seem to be able to burn data cds, though I'm getting horrible
> throughput which I don't understand.  (I seem to max at about 4x writing
> cds on a 48x cd burner, IIRC).  I haven't found any tool that is able to
> write a DL dvd, currently.

Ok, update... After some prodding, I installed k3b which did
successfully burn a DL DVD.  It uses growisofs on the backend, which I
did try a week or so ago and it wasn't working.  Tkdvd also uses
growisofs, so I presume that it would work now as well.  brasero still
wasn't working yesterday, at least for DL, but I have been trying to
periodically rebuild it with and without libburn, so it might be a bit
confused now.  At any rate I assume that the cam/ata fixes in my latest
kernel got growisofs working correctly again.

robert.

> robert.

-- 
Robert Noland <rnoland@FreeBSD.org>
FreeBSD

From hselasky at c2i.net  Wed Sep  9 14:30:47 2009
From: hselasky at c2i.net (Hans Petter Selasky)
Date: Wed Sep  9 14:30:54 2009
Subject: Fwd: Can't boot 8.0-BETA4 from USB stick
In-Reply-To: <f0dd9eb90909081445i4e286e6apb3ad84691c0ef2d0@mail.gmail.com>
References: <f0dd9eb90909080402m27558850g6aaa2a5e4c477758@mail.gmail.com>
	<f0dd9eb90909081444pa5cdbf2jd9ee8573c3d4594@mail.gmail.com>
	<f0dd9eb90909081445i4e286e6apb3ad84691c0ef2d0@mail.gmail.com>
Message-ID: <200909091631.01446.hselasky@c2i.net>

On Tuesday 08 September 2009 23:45:00 James Butler wrote:
> I have tried on all the ports at the back of the box, but I just
> remembered there's another at the front which I will try this evening.
> What do you mean by "dummy USB device"? Just having something else
> plugged in at boot? I will also try another USB drive tonight.

Yes.

--HPS
From universite at ukr.net  Wed Sep  9 14:44:02 2009
From: universite at ukr.net (Vladislav V. Prodan)
Date: Wed Sep  9 14:44:10 2009
Subject: kern/138666: Do not working multicast through igmpproxy
Message-ID: <4AA7BF29.9050801@ukr.net>

>Number:         138666
>Category:       kern
>Synopsis:       Do not working multicast through igmpproxy
>Confidential:   no
>Severity:       critical
>Priority:       high
>Responsible:    freebsd-bugs
>State:          open
>Quarter:        
>Keywords:       
>Date-Required:
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Wed Sep 09 14:40:01 UTC 2009
>Closed-Date:
>Last-Modified:
>Originator:     Vladislav V. Prodan
>Release:        FreeBSD 8.0-BETA4 #0: Wed Sep  9 00:53:41 EEST 2009 amd64
>Organization:
>Environment:
FreeBSD mary-teresa.otrada.od.ua 8.0-BETA4 FreeBSD 8.0-BETA4 #0: Wed Sep 
  9 00:53:41 EEST 2009 
vlad11@mary-teresa.otrada.od.ua:/usr/obj/usr/src/sys/mary-teresa.17  amd64

>Description:
Fatal trap 9: general protection fault while in kernel mode
cpuid = 0; apic id = 00
instruction pointer     = 0x20:0xffffffff803fbed5
stack pointer           = 0x28:0xffffff8000041ab0
frame pointer           = 0x28:0xffffff8000041ad0
code segment            = base 0x0, limit 0xfffff, type 0x1b
                         = DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags        = interrupt enabled, resume, IOPL = 0
current process         = 12 (swi4: clock)
trap number             = 9
panic: general protection fault
cpuid = 0
Uptime: 2h38m8s
Physical memory: 6098 MB
Dumping 1653 MB: 1638 1622 1606 1590 1574 1558 1542 1526 1510 1494 1478 
1462 1446 1430 1414 1398 1382 1366 1350 1334 1318 1302 1286 1270 1254 
1238 1222 1206 1190 1174 1158 1142 1126 1110 1094 1078 1062 1046 1030 
1014 998 982 966 950 934 918 902 886 870 854 838 822 806 790 774 758 742 
726 710 694 678 662 646 630 614 598 582 566 550 534 518 502 486 470 454 
438 422 406 390 374 358 342 326 310 294 278 262 246 230 214 198 182 166 
150 134 118 102 86 70 54 38 22 6

Reading symbols from /boot/kernel/zfs.ko...Reading symbols from 
/boot/kernel/zfs.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/zfs.ko
Reading symbols from /boot/kernel/opensolaris.ko...Reading symbols from 
/boot/kernel/opensolaris.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/opensolaris.ko
Reading symbols from /boot/kernel/linux.ko...Reading symbols from 
/boot/kernel/linux.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/linux.ko
Reading symbols from /boot/kernel/accf_http.ko...Reading symbols from 
/boot/kernel/accf_http.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/accf_http.ko
#0  doadump () at pcpu.h:223
223             __asm __volatile("movq %%gs:0,%0" : "=r" (td));
(kgdb) bt
#0  doadump () at pcpu.h:223
#1  0xffffffff803a5219 in boot (howto=260) at 
/usr/src/sys/kern/kern_shutdown.c:416
#2  0xffffffff803a566c in panic (fmt=Variable "fmt" is not available.
) at /usr/src/sys/kern/kern_shutdown.c:579
#3  0xffffffff8065e30d in trap_fatal (frame=0x9, eva=Variable "eva" is 
not available.
) at /usr/src/sys/amd64/amd64/trap.c:852
#4  0xffffffff8065ee4a in trap (frame=0xffffff8000041a00) at 
/usr/src/sys/amd64/amd64/trap.c:639
#5  0xffffffff80645463 in calltrap () at 
/usr/src/sys/amd64/amd64/exception.S:224
#6  0xffffffff803fbed5 in m_freem (mb=0xc9e5894807b70f55) at 
/usr/src/sys/kern/uipc_mbuf.c:160
#7  0xffffffff804d9e92 in expire_mfc (rt=0xffffff01420d4b00) at 
/usr/src/sys/netinet/ip_mroute.c:1031
#8  0xffffffff804db344 in expire_upcalls (unused=Variable "unused" is 
not available.
) at /usr/src/sys/netinet/ip_mroute.c:1457
#9  0xffffffff803b7dc1 in softclock (arg=Variable "arg" is not available.
) at /usr/src/sys/kern/kern_timeout.c:411
#10 0xffffffff8037f380 in intr_event_execute_handlers (p=Variable "p" is 
not available.
) at /usr/src/sys/kern/kern_intr.c:1165
#11 0xffffffff803808fe in ithread_loop (arg=0xffffff0001392660) at 
/usr/src/sys/kern/kern_intr.c:1178
#12 0xffffffff8037d387 in fork_exit (callout=0xffffffff80380870 
<ithread_loop>, arg=0xffffff0001392660,
     frame=0xffffff8000041c80) at /usr/src/sys/kern/kern_fork.c:843
#13 0xffffffff8064593e in fork_trampoline () at 
/usr/src/sys/amd64/amd64/exception.S:561
#14 0x0000000000000000 in ?? ()
#15 0x0000000000000000 in ?? ()
#16 0x0000000000000001 in ?? ()
#17 0x0000000000000000 in ?? ()
#18 0x0000000000000000 in ?? ()
#19 0x0000000000000000 in ?? ()
#20 0x0000000000000000 in ?? ()
#21 0x0000000000000000 in ?? ()
#22 0x0000000000000000 in ?? ()
#23 0x0000000000000000 in ?? ()
#24 0x0000000000000000 in ?? ()
#25 0x0000000000000000 in ?? ()
#26 0x0000000000000000 in ?? ()
#27 0x0000000000000000 in ?? ()
#28 0x0000000000000000 in ?? ()
#29 0x0000000000000000 in ?? ()
---Type <return> to continue, or q <return> to quit---
#30 0x0000000000000000 in ?? ()
#31 0x0000000000000000 in ?? ()
#32 0x0000000000000000 in ?? ()
#33 0x0000000000000000 in ?? ()
#34 0x0000000000000000 in ?? ()
#35 0x0000000000000000 in ?? ()
#36 0x0000000000000000 in ?? ()
#37 0x0000000000000000 in ?? ()
#38 0x0000000000c6d000 in ?? ()
#39 0x000000000000000b in ?? ()
#40 0xffffffff808cf500 in affinity ()
#41 0xffffffff808cf500 in affinity ()
#42 0xffffff000150d720 in ?? ()
#43 0xffffff8000041240 in ?? ()
#44 0xffffff80000411f8 in ?? ()
#45 0xffffff00013a7390 in ?? ()
#46 0xffffffff803c8159 in sched_switch (td=0xffffff0001392660, 
newtd=0xffffffff80380870, flags=Variable "flags" is not available.
)
     at /usr/src/sys/kern/sched_ule.c:1858
Previous frame inner to this frame (corrupt stack?)


Igmpproxy (/usr/ports/net/igmpproxy) logs:

Sep  9 16:56:18 mary-teresa igmpproxy: Debu: Packet from 10.0.0.1: 
proto: 2 hdrlen: 24 iplen: 8 or 2048
Sep  9 16:56:18 mary-teresa igmpproxy: Note: RECV V2 member report 
from 10.0.0.1        to 224.0.0.2 (ip_hl 24, data 8)
Sep  9 16:56:18 mary-teresa igmpproxy: Note: The IGMP message was from 
myself. Ignoring.
Sep  9 16:56:19 mary-teresa igmpproxy: Debu: Packet from 10.0.0.10: 
proto: 2 hdrlen: 24 iplen: 8 or 2048
Sep  9 16:56:19 mary-teresa igmpproxy: Note: RECV Leave message 
from 10.0.0.10       to 224.0.0.2 (ip_hl 24, data 8)
Sep  9 16:56:19 mary-teresa igmpproxy: Debu: Got leave message from 
10.0.0.10 to 239.0.1.41. Starting last member detection.
Sep  9 16:56:19 mary-teresa igmpproxy: Debu: SENT Membership query 
from 10.0.0.1        to 239.0.1.41
Sep  9 16:56:19 mary-teresa igmpproxy: Debu: Sent membership query from 
10.0.0.1 to 239.0.1.41. Delay: 10
Sep  9 16:56:19 mary-teresa igmpproxy: Debu: Created timeout 14 (#1) - 
delay 4 secs
Sep  9 16:56:19 mary-teresa igmpproxy: Debu: (Id:12, Time:6)
Sep  9 16:56:19 mary-teresa igmpproxy: Debu: (Id:14, Time:4)
Sep  9 16:56:19 mary-teresa igmpproxy: Debu: (Id:13, Time:111)
Sep  9 16:56:24 mary-teresa igmpproxy: Debu: About to call timeout 12 (#0)
Sep  9 16:56:24 mary-teresa igmpproxy: Debu: Aging routes in table.
Sep  9 16:56:24 mary-teresa igmpproxy: Debu:  Current routing table (Age 
active routes); -----------------------------------------------------
Sep  9 16:56:24 mary-teresa igmpproxy: Debu: No routes in table...
Sep  9 16:56:24 mary-teresa igmpproxy: Debu: 
-----------------------------------------------------
Sep  9 16:56:28 mary-teresa igmpproxy: Debu: About to call timeout 14 (#0)
Sep  9 16:56:32 mary-teresa igmpproxy: Debu: Route activate request from 
10.0.0.10 to 239.192.152.143, downIf -1
Sep  9 16:56:32 mary-teresa igmpproxy: Debu: No table entry for 
239.192.152.143 [From: 10.0.0.10]. Inserting route.
Sep  9 16:56:32 mary-teresa igmpproxy: Debu: No existing route for 
239.192.152.143. Create new.
Sep  9 16:56:32 mary-teresa igmpproxy: Debu: No routes in table. Insert 
at beginning.
Sep  9 16:56:32 mary-teresa igmpproxy: Info: Inserted route table entry 
for 239.192.152.143 on VIF #-1
Sep  9 16:56:32 mary-teresa igmpproxy: Debu: No downstream listeners for 
group 239.192.152.143. No join sent.
Sep  9 16:56:32 mary-teresa igmpproxy: Debu:  Current routing table 
(Insert Route); -----------------------------------------------------
Sep  9 16:56:32 mary-teresa igmpproxy: Debu: #0: Dst: 239.192.152.143, 
Age:2, St: I, OutVifs: 0x00000000
Sep  9 16:56:32 mary-teresa igmpproxy: Debu: 
-----------------------------------------------------
Sep  9 16:56:32 mary-teresa igmpproxy: Note: New origin for route 
239.192.152.143 is 10.0.0.10, flood -1
Sep  9 16:56:32 mary-teresa igmpproxy: Debu:  Current routing table 
(Activate Route); -----------------------------------------------------
Sep  9 16:56:32 mary-teresa igmpproxy: Debu: #0: Dst: 239.192.152.143, 
Age:2, St: A, OutVifs: 0x00000000
Sep  9 16:56:32 mary-teresa igmpproxy: Debu: #0: Origin: 10.0.0.10 
floodIf -1 pktcnt 0
Sep  9 16:56:32 mary-teresa igmpproxy: Debu: 
-----------------------------------------------------

239.192.152.143 - multicast TV
10.0.0.1 - freebsd, local network interface
10.0.0.10 - windows XP, running TV-player

kernel mrouting included:
options         MROUTING                # Multicast routing


>How-To-Repeat:

1\ install Igmpproxy (/usr/ports/net/igmpproxy)
2\ run Igmpproxy
3\ a couple of times to switch channels
4\ after 5 minutes will be a stable kernel panic

I suspect the problem in the routes, both for work with local 
interfaces, and for multicast.
>Fix:


>Release-Note:
>Audit-Trail:
>Unformatted:




From tinderbox at freebsd.org  Wed Sep  9 14:44:37 2009
From: tinderbox at freebsd.org (FreeBSD Tinderbox)
Date: Wed Sep  9 14:44:44 2009
Subject: [head tinderbox] failure on i386/i386
Message-ID: <200909091444.n89EiaTE004165@freebsd-current.sentex.ca>

TB --- 2009-09-09 13:45:00 - tinderbox 2.6 running on freebsd-current.sentex.ca
TB --- 2009-09-09 13:45:00 - starting HEAD tinderbox run for i386/i386
TB --- 2009-09-09 13:45:00 - cleaning the object tree
TB --- 2009-09-09 13:45:50 - cvsupping the source tree
TB --- 2009-09-09 13:45:50 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/i386/i386/supfile
TB --- 2009-09-09 13:47:09 - building world
TB --- 2009-09-09 13:47:09 - MAKEOBJDIRPREFIX=/obj
TB --- 2009-09-09 13:47:09 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2009-09-09 13:47:09 - TARGET=i386
TB --- 2009-09-09 13:47:09 - TARGET_ARCH=i386
TB --- 2009-09-09 13:47:09 - TZ=UTC
TB --- 2009-09-09 13:47:09 - __MAKE_CONF=/dev/null
TB --- 2009-09-09 13:47:09 - cd /src
TB --- 2009-09-09 13:47:09 - /usr/bin/make -B buildworld
>>> World build started on Wed Sep  9 13:47:10 UTC 2009
>>> 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
[...]
gzip -cn /src/share/man/man4/man4.i386/apm.4 > apm.4.gz
gzip -cn /src/share/man/man4/man4.i386/ce.4 > ce.4.gz
gzip -cn /src/share/man/man4/man4.i386/cp.4 > cp.4.gz
gzip -cn /src/share/man/man4/man4.i386/CPU_ELAN.4 > CPU_ELAN.4.gz
gzip -cn /src/share/man/man4/man4.i386/cs.4 > cs.4.gz
gzip -cn /src/share/man/man4/man4.i386/ct.4 > ct.4.gz
gzip -cn /src/share/man/man4/man4.i386/ctau.4 > ctau.4.gz
make: don't know how to make dpms.4. Stop
*** Error code 2

Stop in /src/share/man/man4.
*** Error code 1

Stop in /src/share/man.
*** Error code 1

Stop in /src/share.
*** Error code 1

Stop in /src.
*** Error code 1

Stop in /src.
*** Error code 1

Stop in /src.
TB --- 2009-09-09 14:44:36 - WARNING: /usr/bin/make returned exit code  1 
TB --- 2009-09-09 14:44:36 - ERROR: failed to build world
TB --- 2009-09-09 14:44:36 - 2365.28 user 377.45 system 3575.71 real


http://tinderbox.des.no/tinderbox-head-HEAD-i386-i386.full
From tinderbox at freebsd.org  Wed Sep  9 14:51:12 2009
From: tinderbox at freebsd.org (FreeBSD Tinderbox)
Date: Wed Sep  9 14:51:18 2009
Subject: [head tinderbox] failure on i386/pc98
Message-ID: <200909091451.n89EpBUd048609@freebsd-current.sentex.ca>

TB --- 2009-09-09 13:45:00 - tinderbox 2.6 running on freebsd-current.sentex.ca
TB --- 2009-09-09 13:45:00 - starting HEAD tinderbox run for i386/pc98
TB --- 2009-09-09 13:45:00 - cleaning the object tree
TB --- 2009-09-09 13:46:10 - cvsupping the source tree
TB --- 2009-09-09 13:46:10 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/i386/pc98/supfile
TB --- 2009-09-09 13:51:57 - building world
TB --- 2009-09-09 13:51:57 - MAKEOBJDIRPREFIX=/obj
TB --- 2009-09-09 13:51:57 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2009-09-09 13:51:57 - TARGET=pc98
TB --- 2009-09-09 13:51:57 - TARGET_ARCH=i386
TB --- 2009-09-09 13:51:57 - TZ=UTC
TB --- 2009-09-09 13:51:57 - __MAKE_CONF=/dev/null
TB --- 2009-09-09 13:51:57 - cd /src
TB --- 2009-09-09 13:51:57 - /usr/bin/make -B buildworld
>>> World build started on Wed Sep  9 13:51:58 UTC 2009
>>> 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
[...]
gzip -cn /src/share/man/man4/man4.i386/apm.4 > apm.4.gz
gzip -cn /src/share/man/man4/man4.i386/ce.4 > ce.4.gz
gzip -cn /src/share/man/man4/man4.i386/cp.4 > cp.4.gz
gzip -cn /src/share/man/man4/man4.i386/CPU_ELAN.4 > CPU_ELAN.4.gz
gzip -cn /src/share/man/man4/man4.i386/cs.4 > cs.4.gz
gzip -cn /src/share/man/man4/man4.i386/ct.4 > ct.4.gz
gzip -cn /src/share/man/man4/man4.i386/ctau.4 > ctau.4.gz
make: don't know how to make dpms.4. Stop
*** Error code 2

Stop in /src/share/man/man4.
*** Error code 1

Stop in /src/share/man.
*** Error code 1

Stop in /src/share.
*** Error code 1

Stop in /src.
*** Error code 1

Stop in /src.
*** Error code 1

Stop in /src.
TB --- 2009-09-09 14:51:11 - WARNING: /usr/bin/make returned exit code  1 
TB --- 2009-09-09 14:51:11 - ERROR: failed to build world
TB --- 2009-09-09 14:51:11 - 2369.03 user 390.11 system 3970.46 real


http://tinderbox.des.no/tinderbox-head-HEAD-i386-pc98.full
From lists at c0mplx.org  Wed Sep  9 15:28:59 2009
From: lists at c0mplx.org (Kurt Jaeger)
Date: Wed Sep  9 15:29:05 2009
Subject: Funding ODD support
In-Reply-To: <4AA68C8A.4060405@FreeBSD.org>
References: <1252225381.00160049.1252212601@10.7.7.3>
	<4AA68C8A.4060405@FreeBSD.org>
Message-ID: <20090909152857.GD48206@home.opsec.eu>

Hi!

> Funding is good, but could you first once more repeat what is your
> problem?

Example:

Yesterday, I burned 

FreeNAS-amd64-embedded-0.7RC1.4735.img

using

burncd -f /dev/acd0 data FreeNAS-amd64-embedded-0.7RC1.4735.img fixate

on a FreeBSD amd64 7.2-RELEASE to a CD. Guess what happened ? My
computer crashed during/after fixate 8-(

More details available on request.

Reason (probably): That file is no ISO-File. Fine, but this should
not kill my computer.

Yes, I'm willing to fund a part of this effort (100-200 EUR).

-- 
pi@opsec.eu            +49 171 3101372                        11 years to go !
From jacques.fourie at gmail.com  Wed Sep  9 15:36:21 2009
From: jacques.fourie at gmail.com (Jacques Fourie)
Date: Wed Sep  9 15:36:29 2009
Subject: 8.0-B4, Broadcom bge0 not working, HP Proliant DL385, amd64
In-Reply-To: <7147C6D9FE26411197548D67E5025D75@multiplay.co.uk>
References: <alpine.BSF.2.00.0909081113220.98111@area51.capnet.state.tx.us>
	<7147C6D9FE26411197548D67E5025D75@multiplay.co.uk>
Message-ID: <be2f52430909090807t7cacb687x788c22bc27214b2d@mail.gmail.com>

On Tue, Sep 8, 2009 at 7:13 PM, Steven Hartland<killing@multiplay.co.uk> wrote:
> I suspect its the same reason for issues with had with the subjects:
> FreeBSD 7.0-RELEASE amd64 on Dell M600 Blade
> kern/134658: [bce] bce driver fails on PowerEdge m610 blade.
> Quote: "David Christensen" <davidch@broadcom.com>
>
> I've enquired about this recently but havent seen a response as
> yet.
>
> ? Regards
> ? Steve
>
>> Sorry, this is the 5709S and I haven't had an opportunity to
>> implement this PHY yet. ?Unfortunately it's more than just a
>> change to miidevs since the SerDes is actually an IEEE clause
>> 45 compliant device (instead of the more common Clause 22 devices found in
>> 1GbE controllers). ?The registers are diffrerent so the effort is more
>> substantial. ?No estimate
>> yet on when I can get to it.
>
> ----- Original Message ----- From: "stuart cur"
> <nevtic@area51.capnet.state.tx.us>
> To: <freebsd-current@freebsd.org>
> Sent: Tuesday, September 08, 2009 5:32 PM
> Subject: 8.0-B4, Broadcom bge0 not working, HP Proliant DL385, amd64
>
>
>> In 8.0-B4 for amd64, bge does not recognize that there is an active
>> ethernet connection on bge0. ?Switching the cable to bge1 works correctly.
>>
>> This seems to be the same issue as reported on July 21 by Oyvind Rakvag,
>> but I saw no response to that report.
>>
>> Attached are the dmesg.boot, /var/log/messages, and output of pciconf -lv
>> from the very first boot.
>>
>> stu
>
>
>
>> _______________________________________________
>> 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"
>
> ================================================
> This e.mail is private and confidential between Multiplay (UK) Ltd. and the
> person or entity to whom it is addressed. In the event of misdirection, the
> recipient is prohibited from using, copying, printing or otherwise
> disseminating it or any information contained in it.
> In the event of misdirection, illegible or incomplete transmission please
> telephone +44 845 868 1337
> or return the E.mail to postmaster@multiplay.co.uk.
>
> _______________________________________________
> 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"
>

I experienced a similar issue with two 5787M based devices. If I
disable gigabit advertisements for auto negotiation everything worked
OK. With gigabit advertisements enabled, the auto negotiation got
stuck in the next-page-wait state. The problem only occurs on the bge0
device. The bge1 device works with the gigabit advertisements enabled
but ifconfig reports that the link is up at 100baseTX while it seems
to be 1000baseT.

Regards,
Jacques
From avg at icyb.net.ua  Wed Sep  9 15:46:24 2009
From: avg at icyb.net.ua (Andriy Gapon)
Date: Wed Sep  9 15:46:31 2009
Subject: Funding ODD support
In-Reply-To: <20090909152857.GD48206@home.opsec.eu>
References: <1252225381.00160049.1252212601@10.7.7.3>	<4AA68C8A.4060405@FreeBSD.org>
	<20090909152857.GD48206@home.opsec.eu>
Message-ID: <4AA7CDC8.1060806@icyb.net.ua>

on 09/09/2009 18:28 Kurt Jaeger said the following:
[snip]
> on a FreeBSD amd64 7.2-RELEASE to a CD. Guess what happened ? My
> computer crashed during/after fixate 8-(
> 
> More details available on request.

Hmm, I'd think that if one is interested in having a problem fixed the he'd be
pro-active in providing details about the problem.
Of course, I mean useful details like stack trace and other crash dump info.

-- 
Andriy Gapon
From nkoch at demig.de  Wed Sep  9 16:32:12 2009
From: nkoch at demig.de (Norbert Koch)
Date: Wed Sep  9 16:32:22 2009
Subject: lock order reversal etc.
Message-ID: <4AA7D4BA.40002@demig.de>

Hello.

Is this the right mailing list to post
kernel stack traces from Freebsd-8-BETA4?
If yes, see below, otherwise just ignore this message.



Copyright (c) 1992-2009 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
    The Regents of the University of California. All rights reserved.
FreeBSD is a registered trademark of The FreeBSD Foundation.
FreeBSD 8.0-BETA4 #0: Wed Sep  9 09:07:30 CEST 2009
    root@entw-pr2.demig.intra:/usr/obj/usr/src/sys/ENTW-PR2
WARNING: WITNESS option enabled, expect reduced performance.
Timecounter "i8254" frequency 1193182 Hz quality 0
CPU: Intel(R) Core(TM)2 Duo CPU     E4600  @ 2.40GHz (2407.32-MHz
686-class CPU)
  Origin = "GenuineIntel"  Id = 0x6fd  Stepping = 13
 
Features=0xbfebfbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE>
  Features2=0xe39d<SSE3,DTES64,MON,DS_CPL,EST,TM2,SSSE3,CX16,xTPR,PDCM>
  AMD Features=0x20100000<NX,LM>
  AMD Features2=0x1<LAHF>
  TSC: P-state invariant
real memory  = 1073741824 (1024 MB)
avail memory = 1035853824 (987 MB)
ACPI APIC Table: <MSTEST OEMAPIC >
FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs
FreeBSD/SMP: 1 package(s) x 2 core(s)
 cpu0 (BSP): APIC ID:  0
 cpu1 (AP): APIC ID:  1
ioapic0 <Version 2.0> irqs 0-23 on motherboard
kbd1 at kbdmux0
acpi0: <MSTEST TESTONLY> on motherboard
acpi0: [ITHREAD]
acpi0: Power Button (fixed)
acpi0: reservation of 0, a0000 (3) failed
acpi0: reservation of 100000, 3ff00000 (3) failed
Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000
acpi_timer0: <24-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0
acpi_hpet0: <High Precision Event Timer> iomem 0xfed00000-0xfed003ff on
acpi0
Timecounter "HPET" frequency 14318180 Hz quality 900
pcib0: <ACPI Host-PCI bridge> port 0xcf8-0xcff on acpi0
pci0: <ACPI PCI bus> on pcib0
pcib1: <ACPI PCI-PCI bridge> irq 16 at device 1.0 on pci0
pci1: <ACPI PCI bus> on pcib1
vgapci0: <VGA-compatible display> mem
0xfd000000-0xfdffffff,0xc0000000-0xcfffffff,0xfc000000-0xfcffffff irq 16
at device 0.0 on pci1
uhci0: <Intel 82801H (ICH8) USB controller USB-D> port 0xdc00-0xdc1f irq
16 at device 26.0 on pci0
uhci0: [ITHREAD]
uhci0: LegSup = 0x0f00
usbus0: <Intel 82801H (ICH8) USB controller USB-D> on uhci0
uhci1: <Intel 82801H (ICH8) USB controller USB-E> port 0xe000-0xe01f irq
17 at device 26.1 on pci0
uhci1: [ITHREAD]
uhci1: LegSup = 0x0f00
usbus1: <Intel 82801H (ICH8) USB controller USB-E> on uhci1
ehci0: <Intel 82801H (ICH8) USB 2.0 controller USB2-B> mem
0xfebffc00-0xfebfffff irq 18 at device 26.7 on pci0
ehci0: [ITHREAD]
usbus2: EHCI version 1.0
usbus2: <Intel 82801H (ICH8) USB 2.0 controller USB2-B> on ehci0
pci0: <multimedia, HDA> at device 27.0 (no driver attached)
pcib2: <ACPI PCI-PCI bridge> irq 16 at device 28.0 on pci0
pci4: <ACPI PCI bus> on pcib2
pcib3: <ACPI PCI-PCI bridge> irq 19 at device 28.3 on pci0
pci3: <ACPI PCI bus> on pcib3
re0: <RealTek
8168/8168B/8168C/8168CP/8168D/8168DP/8111B/8111C/8111CP/8111DP PCIe
Gigabit Ethernet> port 0xa800-0xa8ff mem 0xfe9ff000-0xfe9fffff irq 19 at
device 0.0 on pci3
re0: Using 1 MSI messages
re0: Chip rev. 0x38000000
re0: MAC rev. 0x00000000
miibus0: <MII bus> on re0
rgephy0: <RTL8169S/8110S/8211B media interface> PHY 1 on miibus0
rgephy0:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT,
1000baseT-FDX, auto
re0: Ethernet address: 00:1d:60:76:0d:a3
re0: [FILTER]
pcib4: <ACPI PCI-PCI bridge> irq 16 at device 28.4 on pci0
pci2: <ACPI PCI bus> on pcib4
atapci0: <JMicron JMB363 SATA300 controller> port
0x9c00-0x9c07,0x9880-0x9883,0x9800-0x9807,0x9480-0x9483,0x9400-0x940f
mem 0xfe8fe000-0xfe8fffff irq 16 at device 0.0 on pci2
atapci0: [ITHREAD]
atapci0: AHCI called from vendor specific driver
atapci0: AHCI v1.00 controller with 2 3Gbps ports, PM supported
ata2: <ATA channel 0> on atapci0
ata2: [ITHREAD]
ata3: <ATA channel 1> on atapci0
ata3: [ITHREAD]
ata4: <ATA channel 2> on atapci0
ata4: [ITHREAD]
uhci2: <Intel 82801H (ICH8) USB controller USB-A> port 0xd480-0xd49f irq
23 at device 29.0 on pci0
uhci2: [ITHREAD]
uhci2: LegSup = 0x0f00
usbus3: <Intel 82801H (ICH8) USB controller USB-A> on uhci2
uhci3: <Intel 82801H (ICH8) USB controller USB-B> port 0xd800-0xd81f irq
19 at device 29.1 on pci0
uhci3: [ITHREAD]
uhci3: LegSup = 0x0f00
usbus4: <Intel 82801H (ICH8) USB controller USB-B> on uhci3
uhci4: <Intel 82801H (ICH8) USB controller USB-C> port 0xd880-0xd89f irq
18 at device 29.2 on pci0
uhci4: [ITHREAD]
uhci4: LegSup = 0x0f00
usbus5: <Intel 82801H (ICH8) USB controller USB-C> on uhci4
ehci1: <Intel 82801H (ICH8) USB 2.0 controller USB2-A> mem
0xfebff800-0xfebffbff irq 23 at device 29.7 on pci0
ehci1: [ITHREAD]
usbus6: EHCI version 1.0
usbus6: <Intel 82801H (ICH8) USB 2.0 controller USB2-A> on ehci1
pcib5: <ACPI PCI-PCI bridge> at device 30.0 on pci0
pci5: <ACPI PCI bus> on pcib5
xl0: <3Com 3c905C-TX Fast Etherlink XL> port 0xbc00-0xbc7f mem
0xfeaffc00-0xfeaffc7f irq 21 at device 0.0 on pci5
miibus1: <MII bus> on xl0
ukphy0: <Generic IEEE 802.3u media interface> PHY 24 on miibus1
ukphy0:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
xl0: Ethernet address: 00:0a:5e:04:dc:62
xl0: [ITHREAD]
atapci1: <Promise PDC20268 UDMA100 controller> port
0xb880-0xb887,0xb800-0xb803,0xb480-0xb487,0xb400-0xb403,0xb080-0xb08f
mem 0xfeaf8000-0xfeafbfff irq 22 at device 1.0 on pci5
atapci1: [ITHREAD]
ata5: <ATA channel 0> on atapci1
ata5: [ITHREAD]
ata6: <ATA channel 1> on atapci1
ata6: [ITHREAD]
isab0: <PCI-ISA bridge> at device 31.0 on pci0
isa0: <ISA bus> on isab0
atapci2: <Intel ICH8 SATA300 controller> port
0xec00-0xec07,0xe880-0xe883,0xe800-0xe807,0xe480-0xe483,0xe400-0xe40f,0xe080-0xe08f
irq 19 at device 31.2 on pci0
atapci2: [ITHREAD]
ata7: <ATA channel 0> on atapci2
ata7: [ITHREAD]
ata8: <ATA channel 1> on atapci2
ata8: [ITHREAD]
pci0: <serial bus, SMBus> at device 31.3 (no driver attached)
atapci3: <Intel ICH8 SATA300 controller> port
0xd400-0xd407,0xd080-0xd083,0xd000-0xd007,0xcc00-0xcc03,0xc880-0xc88f,0xc800-0xc80f
irq 19 at device 31.5 on pci0
atapci3: [ITHREAD]
ata9: <ATA channel 0> on atapci3
ata9: [ITHREAD]
ata10: <ATA channel 1> on atapci3
ata10: [ITHREAD]
acpi_button0: <Power Button> on acpi0
atrtc0: <AT realtime clock> port 0x70-0x71 irq 8 on acpi0
uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0
uart0: [FILTER]
ACPI Warning: \\_SB_.PCI0.SBRG.FDC_._FDE: Return type mismatch - found
Package, expected Buffer 20090521 nspredef-1051
fdc0: <floppy drive controller (FDE)> port 0x3f0-0x3f5,0x3f7 irq 6 drq 2
on acpi0
fdc0: [FILTER]
fd0: <1440-KB 3.5" drive> on fdc0 drive 0
ppc0: <Parallel port> port 0x378-0x37f,0x778-0x77f irq 7 drq 3 on acpi0
ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode
ppc0: FIFO with 16/16/9 bytes threshold
ppc0: [ITHREAD]
ppbus0: <Parallel port bus> on ppc0
lpt0: <Printer> on ppbus0
lpt0: [ITHREAD]
lpt0: Interrupt-driven port
ppi0: <Parallel I/O> on ppbus0
atkbdc0: <Keyboard controller (i8042)> port 0x60,0x64 irq 1 on acpi0
atkbd0: <AT Keyboard> irq 1 on atkbdc0
kbd0 at atkbd0
atkbd0: [GIANT-LOCKED]
atkbd0: [ITHREAD]
psm0: <PS/2 Mouse> irq 12 on atkbdc0
psm0: [GIANT-LOCKED]
psm0: [ITHREAD]
psm0: model Generic PS/2 mouse, device ID 0
cpu0: <ACPI CPU> on acpi0
ACPI Warning: Incorrect checksum in table [OEMB] - 27, should be 1A
20090521 tbutils-275
est0: <Enhanced SpeedStep Frequency Control> on cpu0
p4tcc0: <CPU Frequency Thermal Control> on cpu0
cpu1: <ACPI CPU> on acpi0
est1: <Enhanced SpeedStep Frequency Control> on cpu1
p4tcc1: <CPU Frequency Thermal Control> on cpu1
pmtimer0 on isa0
orm0: <ISA Option ROMs> at iomem 0xd2000-0xd27ff,0xd2800-0xd4fff pnpid
ORM0000 on isa0
sc0: <System console> at flags 0x100 on isa0
sc0: VGA <16 virtual consoles, flags=0x300>
vga0: <Generic ISA VGA> at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0
ata0 at port 0x1f0-0x1f7,0x3f6 irq 14 on isa0
ata0: [ITHREAD]
ata1 at port 0x170-0x177,0x376 irq 15 on isa0
ata1: [ITHREAD]
Timecounters tick every 1.000 msec
usbus0: 12Mbps Full Speed USB v1.0
usbus1: 12Mbps Full Speed USB v1.0
usbus2: 480Mbps High Speed USB v2.0
usbus3: 12Mbps Full Speed USB v1.0
usbus4: 12Mbps Full Speed USB v1.0
usbus5: 12Mbps Full Speed USB v1.0
usbus6: 480Mbps High Speed USB v2.0
ugen0.1: <Intel> at usbus0
uhub0: <Intel UHCI root HUB, class 9/0, rev 1.00/1.00, addr 1> on usbus0
ugen1.1: <Intel> at usbus1
uhub1: <Intel UHCI root HUB, class 9/0, rev 1.00/1.00, addr 1> on usbus1
ugen2.1: <Intel> at usbus2
uhub2: <Intel EHCI root HUB, class 9/0, rev 2.00/1.00, addr 1> on usbus2
ugen3.1: <Intel> at usbus3
uhub3: <Intel UHCI root HUB, class 9/0, rev 1.00/1.00, addr 1> on usbus3
ugen4.1: <Intel> at usbus4
uhub4: <Intel UHCI root HUB, class 9/0, rev 1.00/1.00, addr 1> on usbus4
ugen5.1: <Intel> at usbus5
uhub5: <Intel UHCI root HUB, class 9/0, rev 1.00/1.00, addr 1> on usbus5
ugen6.1: <Intel> at usbus6
uhub6: <Intel EHCI root HUB, class 9/0, rev 2.00/1.00, addr 1> on usbus6
acd0: DVDROM <TOSHIBA DVD-ROM SD-M1612/J806> at ata4-master PIO4
ad10: 239372MB <WDC WD2500SB-01RFA0 20.00K20> at ata5-master UDMA100
ad12: 239372MB <WDC WD2500SB-01RFA0 20.00K20> at ata6-master UDMA100
ar0: 239372MB <Promise Fasttrak RAID1> status: READY
ar0: disk0 READY (master) using ad10 at ata5-master
ar0: disk1 READY (mirror) using ad12 at ata6-master
SMP: AP CPU #1 Launched!
WARNING: WITNESS option enabled, expect reduced performance.
uhub0: 2 ports with 2 removable, self powered
uhub1: 2 ports with 2 removable, self powered
uhub3: 2 ports with 2 removable, self powered
uhub4: 2 ports with 2 removable, self powered
uhub5: 2 ports with 2 removable, self powered
GEOM: ad10: geometry does not match label (255h,63s != 16h,63s).
GEOM: ad10: media size does not match label.
GEOM: ad12: geometry does not match label (255h,63s != 16h,63s).
GEOM: ad12: media size does not match label.
Root mount waiting for: usbus6 usbus2
uhub2: 4 ports with 4 removable, self powered
uhub6: 6 ports with 6 removable, self powered
Trying to mount root from ufs:/dev/ar0a
uma_zalloc_arg: zone "64" with the following non-sleepable locks held:
exclusive sleep mutex jail mutex (jail mutex) r = 0 (0xc0b91328) locked
@
/usr/src/sys/modules/syscons/daemon/../../../dev/syscons/daemon/daemon_saver.c:355
KDB: stack backtrace:
db_trace_self_wrapper(c0abf50f,e69b391c,c07ab3b5,c4a0580a,163,...) at
db_trace_self_wrapper+0x26
kdb_backtrace(c4a0580a,163,ffffffff,c0d261c4,e69b3954,...) at
kdb_backtrace+0x29
_witness_debugger(c0ac198e,e69b3968,4,1,0,...) at _witness_debugger+0x25
witness_warn(5,0,c0ae4b92,c0add27b,e69b3984,...) at witness_warn+0x1fd
uma_zalloc_arg(c148b000,0,2,2,14,...) at uma_zalloc_arg+0x34
malloc(29,c0b92dd0,2,163,c46562e4,...) at malloc+0xe4
daemon_init(c0d61940,c0aba83e,e69b3a28,c46f5600,c4a06cc0,...) at
daemon_init+0x7b
splash_test(7b,c46f5600,c4a06cc0,c46f5600,e69b3a50,...) at splash_test+0x91
splash_register(c4a06c40,0,0,76,0,...) at splash_register+0x48
module_register_init(c4a06cc0,0,c0ab8be2,e4,0,...) at
module_register_init+0xa7
linker_load_module(0,e69b3c48,c0ab8be2,3f7,0,...) at
linker_load_module+0x9fa
kern_kldload(c4656240,c43d9c00,e69b3c70,0,33d,...) at kern_kldload+0xca
kldload(c4656240,e69b3cf8,4,c,c0b8eb80,...) at kldload+0x74
syscall(e69b3d38) at syscall+0x2a3
Xint0x80_syscall() at Xint0x80_syscall+0x20
--- syscall (304, FreeBSD ELF32, kldload), eip = 0x280d6ddb, esp =
0xbfbfe94c, ebp = 0xbfbfee38 ---
IPv4 address: "192.168.1.191" is not on the network
pid 1275 (xfce4-settings-help), uid 1000: exited on signal 11 (core dumped)
lock order reversal:
 1st 0xc4afca2c filedesc structure (filedesc structure) @
/usr/src/sys/kern/kern_descrip.c:1088
 2nd 0xc4be3488 ufs (ufs) @ /usr/src/sys/kern/vfs_subr.c:4091
KDB: stack backtrace:
db_trace_self_wrapper(c0abf50f,e6975a2c,c07ab3b5,c079c13b,c0ac23e2,...)
at db_trace_self_wrapper+0x26
kdb_backtrace(c079c13b,c0ac23e2,c4123168,c4126290,e6975a88,...) at
kdb_backtrace+0x29
_witness_debugger(c0ac23e2,c4be3488,c0ab4f66,c4126290,c0ac96be,...) at
_witness_debugger+0x25
witness_checkorder(c4be3488,9,c0ac96be,ffb,c4be34a4,...) at
witness_checkorder+0x839
__lockmgr_args(c4be3488,80400,c4be34a4,0,0,...) at __lockmgr_args+0x7a7
ffs_lock(e6975b98,4,0,80400,c4be3430,...) at ffs_lock+0x8a
VOP_LOCK1_APV(c0bae360,e6975b98,c0ab7180,c0bc5660,c4be3430,...) at
VOP_LOCK1_APV+0xb5
_vn_lock(c4be3430,80400,c0ac96be,ffb,e6975bf4,...) at _vn_lock+0x5e
vfs_knllock(c4be3430,0,c0ab7180,696,c4e7d110,...) at vfs_knllock+0x29
knlist_remove_kq(0,e6975c14,c07f69f9,c4dcdd78,c4e7d110,...) at
knlist_remove_kq+0x85
knlist_remove(c4dcdd78,c4e7d110,0,e6975c40,c0739c35,...) at
knlist_remove+0x1b
filt_vfsdetach(c4e7d110,0,c0ab7180,777,d,...) at filt_vfsdetach+0x39
knote_fdclose(c4686b40,4cd,c0ab6cc3,440,c4afca2c,...) at knote_fdclose+0xf5
kern_close(c4686b40,4cd,e6975d2c,c0a2e883,c4686b40,...) at kern_close+0xd2
close(c4686b40,e6975cf8,4,c0ac2cbd,c0b8cae8,...) at close+0x1a
syscall(e6975d38) at syscall+0x2a3
Xint0x80_syscall() at Xint0x80_syscall+0x20
--- syscall (6, FreeBSD ELF32, close), eip = 0x2837b3d3, esp =
0xbfbfe5bc, ebp = 0xbfbfe5d8 ---
IPv4 address: "192.168.1.191" is not on the network
IPv4 address: "192.168.1.191" is not on the network
lock order reversal:
 1st 0xd82d03f0 bufwait (bufwait) @ /usr/src/sys/kern/vfs_bio.c:2559
 2nd 0xc4f64800 dirhash (dirhash) @ /usr/src/sys/ufs/ufs/ufs_dirhash.c:285
KDB: stack backtrace:
db_trace_self_wrapper(c0abf50f,e6a5b850,c07ab3b5,c079c13b,c0ac23e2,...)
at db_trace_self_wrapper+0x26
kdb_backtrace(c079c13b,c0ac23e2,c4122e90,c41262f8,e6a5b8ac,...) at
kdb_backtrace+0x29
_witness_debugger(c0ac23e2,c4f64800,c0ae35e8,c41262f8,c0ae3281,...) at
_witness_debugger+0x25
witness_checkorder(c4f64800,9,c0ae3281,11d,0,...) at
witness_checkorder+0x839
_sx_xlock(c4f64800,0,c0ae3281,11d,c512fb54,...) at _sx_xlock+0x85
ufsdirhash_acquire(d82d0390,de0b7800,200,de0b783c,e6a5b97c,...) at
ufsdirhash_acquire+0x35
ufsdirhash_add(c512fb54,e6a5ba0c,83c,e6a5b968,e6a5b96c,...) at
ufsdirhash_add+0x13
ufs_direnter(c5167218,0,e6a5ba0c,e6a5bba0,0,...) at ufs_direnter+0x729
ufs_rename(e6a5bc1c,0,c51b7b84,e6a5bbc8,0,...) at ufs_rename+0x717
VOP_RENAME_APV(c0bae360,e6a5bc1c,0,1,e6a5bba0,...) at VOP_RENAME_APV+0xa5
kern_renameat(c4a2f900,ffffff9c,2992b3a0,ffffff9c,29922880,...) at
kern_renameat+0x307
kern_rename(c4a2f900,2992b3a0,29922880,0,e6a5bd2c,...) at kern_rename+0x36
rename(c4a2f900,e6a5bcf8,8,c0addc93,c0b8d840,...) at rename+0x29
syscall(e6a5bd38) at syscall+0x2a3
Xint0x80_syscall() at Xint0x80_syscall+0x20
--- syscall (128, FreeBSD ELF32, rename), eip = 0x2954475b, esp =
0xbfbf98dc, ebp = 0xbfbf9988 ---
IPv4 address: "192.168.1.191" is not on the network
lock order reversal:
 1st 0xc464337c ufs (ufs) @ /usr/src/sys/kern/vfs_subr.c:2083
 2nd 0xd81d14b0 bufwait (bufwait) @ /usr/src/sys/ufs/ffs/ffs_softdep.c:6177
 3rd 0xc673a7ac ufs (ufs) @ /usr/src/sys/kern/vfs_subr.c:2083
KDB: stack backtrace:
db_trace_self_wrapper(c0abf50f,e6b103cc,c07ab3b5,c079c13b,c0ac23fb,...)
at db_trace_self_wrapper+0x26
kdb_backtrace(c079c13b,c0ac23fb,c4122e90,c4126290,e6b10428,...) at
kdb_backtrace+0x29
_witness_debugger(c0ac23fb,c673a7ac,c0ab4f66,c4126290,c0ac96be,...) at
_witness_debugger+0x25
witness_checkorder(c673a7ac,9,c0ac96be,823,0,...) at
witness_checkorder+0x839
__lockmgr_args(c673a7ac,80100,c673a7c8,0,0,...) at __lockmgr_args+0x7a7
ffs_lock(e6b10538,c07ab15b,c0ac8bb1,80100,c673a754,...) at ffs_lock+0x8a
VOP_LOCK1_APV(c0bae360,e6b10538,c4c08524,c0bc5660,c673a754,...) at
VOP_LOCK1_APV+0xb5
_vn_lock(c673a754,80100,c0ac96be,823,4,...) at _vn_lock+0x5e
vget(c673a754,80100,c4c08480,50,0,...) at vget+0xb9
vfs_hash_get(c46e1508,18ef074,80000,c4c08480,e6b10694,...) at
vfs_hash_get+0xe6
ffs_vgetf(c46e1508,18ef074,80000,e6b10694,1,...) at ffs_vgetf+0x49
softdep_sync_metadata(c4643324,0,c0ae2efa,146,0,...) at
softdep_sync_metadata+0x5ba
ffs_syncvnode(c4643324,1,c0abaa2c,c0ab45da,3,...) at ffs_syncvnode+0x3e2
ffs_truncate(c4643324,600,0,880,c465d280,...) at ffs_truncate+0x66a
ufs_direnter(c4643324,c673a754,e6b10a1c,e6b10c00,d82ec1d0,...) at
ufs_direnter+0x8f6
ufs_mkdir(e6b10c28,e6b10c3c,0,0,e6b10b6c,...) at ufs_mkdir+0x8a7
VOP_MKDIR_APV(c0bae360,e6b10c28,e6b10c00,e6b10b6c,0,...) at
VOP_MKDIR_APV+0xa5
kern_mkdirat(c4c08480,ffffff9c,804c2e8,0,41fd,...) at kern_mkdirat+0x22b
kern_mkdir(c4c08480,804c2e8,0,41fd,e6b10d2c,...) at kern_mkdir+0x2e
mkdir(c4c08480,e6b10cf8,8,c0ac2cbd,c0b8d920,...) at mkdir+0x29
syscall(e6b10d38) at syscall+0x2a3
Xint0x80_syscall() at Xint0x80_syscall+0x20
--- syscall (136, FreeBSD ELF32, mkdir), eip = 0x2816c973, esp =
0xbfbfe5cc, ebp = 0xbfbfe748 ---



-- 
***********************************************************************
*    demig Prozessautomatisierung GmbH  *  demig Anlagentechnik GmbH  *
*                                       *                             *
* Anschrift:          Haardtstrasse 40  *  Haardtstrasse 40           *
*                       D-57076 Siegen  *  D-57076 Siegen             *
* Registergericht:     Siegen HRB 2819  *  Siegen HRB 5532            *
* Geschaeftsfuehrer:   Joachim Herbst,  *  Joachim Herbst,            *
*                        Winfried Held  *  Winfried Held              *
* Telefon:              +49 271 772020  *  +49 271 772020             *
* Telefax:              +49 271 74704   *  +49 271 74704              *
* E-Mail:                info@demig.de  *  at@demig.de                *
*                  http://www.demig.de  *  http://www.demig.de        *
***********************************************************************

From pilists at c0mplx.org  Wed Sep  9 15:58:14 2009
From: pilists at c0mplx.org (Kurt Jaeger)
Date: Wed Sep  9 17:38:11 2009
Subject: Funding ODD support
In-Reply-To: <4AA7CDC8.1060806@icyb.net.ua>
References: <1252225381.00160049.1252212601@10.7.7.3>
	<4AA68C8A.4060405@FreeBSD.org>
	<20090909152857.GD48206@home.opsec.eu>
	<4AA7CDC8.1060806@icyb.net.ua>
Message-ID: <20090909155813.GF48206@home.opsec.eu>

Hi!

> on 09/09/2009 18:28 Kurt Jaeger said the following:
> [snip]
> > on a FreeBSD amd64 7.2-RELEASE to a CD. Guess what happened ? My
> > computer crashed during/after fixate 8-(
> > 
> > More details available on request.
> 
> Hmm, I'd think that if one is interested in having a problem fixed the he'd be
> pro-active in providing details about the problem.
> Of course, I mean useful details like stack trace and other crash dump info.

This is my desktop machine @work (running X11), so if it crashes,
I need it to boot because the next customer who calls wants me to help
him 8-)

Right now, it's hanging again in disk-IO, and it's not the IMG vrs.
ISO problem 8-(

I can still type as I'm logged in on my home machine.

What can I type on the problem host to provide you or send-pr with
that data ?

It's a hang:

# burncd -f /dev/acd0 data FreeNAS-amd64-LiveCD-0.7RC1.4735.iso fixate
next writeable LBA 0
writing from file FreeNAS-amd64-LiveCD-0.7RC1.4735.iso size 74482 KB
written this track 74482 KB (100%) total 74482 KB
fixating CD, please wait..
load: 0.08  cmd: burncd 22142 [g_waitidle] 0.00u 0.06s 0% 920k
load: 0.08  cmd: burncd 22142 [g_waitidle] 0.00u 0.06s 0% 920k
[...]

For very short times, writes are going through (from time to time).

Here's what ps ax told me:

22142  p3  T+     0:00.07 burncd -f /dev/acd0 data FreeNAS-amd64-LiveCD-0.7RC1.

A kill -9 is still @work 8-(

-- 
pi@opsec.eu            +49 171 3101372                        11 years to go !
From lars.engels at 0x20.net  Wed Sep  9 18:16:22 2009
From: lars.engels at 0x20.net (Lars Engels)
Date: Wed Sep  9 18:16:28 2009
Subject: CFH: fix multimedia/pwcbsd with usb2
In-Reply-To: <20090909104528.20b28e65@ernst.jennejohn.org>
References: <20090908201713.GD41185@e.0x20.net>
	<20090909104528.20b28e65@ernst.jennejohn.org>
Message-ID: <20090909181620.GA19090@e.0x20.net>

On Wed, Sep 09, 2009 at 10:45:28AM +0200, Gary Jennejohn wrote:
> On Tue, 8 Sep 2009 22:17:13 +0200
> Lars Engels <lars.engels@0x20.net> wrote:
> 
> > could someone with some more USB and C knowledge than me take a look at
> > multimedia/pwcbsd?
> > I'd really like to get the port fixed before the ports freeze starts.
> > Here is the compile output:
> > 
> 
> The patches under ~gj/work on freefall at least allow it to compile.  I
> can't test whether it works, however.
> 
> Let me know when you have them so I can delete them.

Gary,

thanks a lot for the patches! pwcbsd compiles and my cam is showing
wonderful pictures (as long as I am not in front of it ;-) ).
I just commited the new port version, so have fun with your cams,
everbody!

Lars
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20090909/a25681b8/attachment.pgp
From alleepsilonkleinereins at gmail.com  Wed Sep  9 18:20:58 2009
From: alleepsilonkleinereins at gmail.com (Felix Stolba)
Date: Wed Sep  9 18:21:10 2009
Subject: LOR acpi_ibm module
In-Reply-To: <179b97fb0905301355n2a422e05j665fc3a551ce06f1@mail.gmail.com>
References: <179b97fb0905301355n2a422e05j665fc3a551ce06f1@mail.gmail.com>
Message-ID: <4AA7EAB2.5040403@googlemail.com>

Brandon Gooch schrieb:
> lock order reversal:
>  1st 0xffffffff807cf200 sysctl lock (sysctl lock) @
> /usr/src/sys/kern/kern_sysctl.c:1608
>  2nd 0xffffffff80bf1de0 ACPI IBM extras (ACPI IBM extras) @
> /usr/src/sys/modules/acpi/acpi_ibm/../../../dev/acpi_support/acpi_ibm.c:481
> KDB: stack backtrace:
> db_trace_self_wrapper() at db_trace_self_wrapper+0x2a
> _witness_debugger() at _witness_debugger+0x2e
> witness_checkorder() at witness_checkorder+0x81e
> _sx_xlock() at _sx_xlock+0x54
> acpi_ibm_sysctl() at acpi_ibm_sysctl+0x4f
> sysctl_root() at sysctl_root+0xe3
> userland_sysctl() at userland_sysctl+0x158
> __sysctl() at __sysctl+0xaa
> syscall() at syscall+0x1dd
> Xfast_syscall() at Xfast_syscall+0xd0
> --- syscall (202, FreeBSD ELF64, __sysctl), rip = 0x80073769c, rsp =
> 0x7fffffffda58, rbp = 0x4 ---
> _______________________________________________
> 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"
>
>   
I'm getting the same LOR at boot in 9.0-current (source from 7th of
september).

From jkim at FreeBSD.org  Wed Sep  9 18:25:22 2009
From: jkim at FreeBSD.org (Jung-uk Kim)
Date: Wed Sep  9 18:25:31 2009
Subject: LOR acpi_ibm module
In-Reply-To: <4AA7EAB2.5040403@googlemail.com>
References: <179b97fb0905301355n2a422e05j665fc3a551ce06f1@mail.gmail.com>
	<4AA7EAB2.5040403@googlemail.com>
Message-ID: <200909091425.15003.jkim@FreeBSD.org>

On Wednesday 09 September 2009 01:49 pm, Felix Stolba wrote:
> Brandon Gooch schrieb:
> > lock order reversal:
> >  1st 0xffffffff807cf200 sysctl lock (sysctl lock) @
> > /usr/src/sys/kern/kern_sysctl.c:1608
> >  2nd 0xffffffff80bf1de0 ACPI IBM extras (ACPI IBM extras) @
> > /usr/src/sys/modules/acpi/acpi_ibm/../../../dev/acpi_support/acpi
> >_ibm.c:481 KDB: stack backtrace:
> > db_trace_self_wrapper() at db_trace_self_wrapper+0x2a
> > _witness_debugger() at _witness_debugger+0x2e
> > witness_checkorder() at witness_checkorder+0x81e
> > _sx_xlock() at _sx_xlock+0x54
> > acpi_ibm_sysctl() at acpi_ibm_sysctl+0x4f
> > sysctl_root() at sysctl_root+0xe3
> > userland_sysctl() at userland_sysctl+0x158
> > __sysctl() at __sysctl+0xaa
> > syscall() at syscall+0x1dd
> > Xfast_syscall() at Xfast_syscall+0xd0
> > --- syscall (202, FreeBSD ELF64, __sysctl), rip = 0x80073769c,
> > rsp = 0x7fffffffda58, rbp = 0x4 ---
>
> I'm getting the same LOR at boot in 9.0-current (source from 7th of
> september).

It is generally harmless but really annoying.

Jung-uk Kim
From jamesbrandongooch at gmail.com  Wed Sep  9 18:51:19 2009
From: jamesbrandongooch at gmail.com (Brandon Gooch)
Date: Wed Sep  9 18:51:25 2009
Subject: LOR acpi_ibm module
In-Reply-To: <200909091425.15003.jkim@FreeBSD.org>
References: <179b97fb0905301355n2a422e05j665fc3a551ce06f1@mail.gmail.com>
	<4AA7EAB2.5040403@googlemail.com>
	<200909091425.15003.jkim@FreeBSD.org>
Message-ID: <179b97fb0909091151g502c846fq5070f84381f9efa5@mail.gmail.com>

On Wed, Sep 9, 2009 at 1:25 PM, Jung-uk Kim<jkim@freebsd.org> wrote:
> On Wednesday 09 September 2009 01:49 pm, Felix Stolba wrote:
>> Brandon Gooch schrieb:
>> > lock order reversal:
>> > ?1st 0xffffffff807cf200 sysctl lock (sysctl lock) @
>> > /usr/src/sys/kern/kern_sysctl.c:1608
>> > ?2nd 0xffffffff80bf1de0 ACPI IBM extras (ACPI IBM extras) @
>> > /usr/src/sys/modules/acpi/acpi_ibm/../../../dev/acpi_support/acpi
>> >_ibm.c:481 KDB: stack backtrace:
>> > db_trace_self_wrapper() at db_trace_self_wrapper+0x2a
>> > _witness_debugger() at _witness_debugger+0x2e
>> > witness_checkorder() at witness_checkorder+0x81e
>> > _sx_xlock() at _sx_xlock+0x54
>> > acpi_ibm_sysctl() at acpi_ibm_sysctl+0x4f
>> > sysctl_root() at sysctl_root+0xe3
>> > userland_sysctl() at userland_sysctl+0x158
>> > __sysctl() at __sysctl+0xaa
>> > syscall() at syscall+0x1dd
>> > Xfast_syscall() at Xfast_syscall+0xd0
>> > --- syscall (202, FreeBSD ELF64, __sysctl), rip = 0x80073769c,
>> > rsp = 0x7fffffffda58, rbp = 0x4 ---
>>
>> I'm getting the same LOR at boot in 9.0-current (source from 7th of
>> september).
>
> It is generally harmless but really annoying.
>
> Jung-uk Kim
>

I haven't been running a kernel with WITNESS (or any debugging) for a
couple of weeks, so I forgot about it.

Originally, I wondered if this locking problem(?) was causing a
strange issue when I invoked a script via devd (a call to a script to
handle ACPI events through acpi_ibm.ko), in this case, an ACPI screen
brightness function: Occasionally, the screen brightness would not
adjust when I used the Fn keys, only to eventually, "pop" all of the
requests I sent off of the devd command table, usually with a long
delay.

If I started devd in foreground mode and watched the command output in
the terminal, commands were "pushed" and "popped" immediately; all was
well.

I was never able to put it all together, and it was only a minor
annoyance, after all.

-Brandon
From universite at ukr.net  Wed Sep  9 19:04:54 2009
From: universite at ukr.net (Vladislav V. Prodan)
Date: Wed Sep  9 19:05:00 2009
Subject: misc/138676: after buildworld not work local routes
Message-ID: <4AA7FC4B.6090601@ukr.net>

>Number:         138676
>Category:       misc
>Synopsis:       after buildworld not work local routes
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    freebsd-bugs
>State:          open
>Quarter:        
>Keywords:       
>Date-Required:
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Wed Sep 09 19:00:04 UTC 2009
>Closed-Date:
>Last-Modified:
>Originator:     Vladislav V. Prodan
>Release:        FreeBSD 8.0-BETA4 #0: Wed Sep  9 00:53:41 EEST 2009 amd64
>Organization:
>Environment:
FreeBSD mary-teresa.otrada.od.ua 8.0-BETA4 FreeBSD 8.0-BETA4 #0: Wed Sep 
  9 00:53:41 EEST 2009 
vlad11@mary-teresa.otrada.od.ua:/usr/obj/usr/src/sys/mary-teresa.17  amd64

>Description:
home PC --> FreeBSD [ squid --> apache ]

These url are on the external interface of the server.
http://otrada.od.ua/blog/
http://otrada.od.ua/phpmyadmin/
http://otrada.od.ua/cacti/

After upgrade the system now gives the squid:
     (51) Network is unreachable

In logs:
sep  9 18:39:10 128 10.0.0.10 TCP_MISS/503 1317 GET 
http://otrada.od.ua/blog/ - DIRECT/otrada.od.ua text/html
sep  9 18:39:18 126 10.0.0.10 TCP_MISS/503 1329 GET 
http://otrada.od.ua/phpmyadmin/ - DIRECT/otrada.od.ua text/html
sep  9 18:39:39 117 10.0.0.10 TCP_MISS/503 1319 GET 
http://otrada.od.ua/cacti/ - DIRECT/otrada.od.ua text/html

Out all three url normally give details.
At queries from outside, all url are working properly.

similar problem was previously:
http://lists.freebsd.org/pipermail/freebsd-current/2008-December/001581.html
>How-To-Repeat:

>Fix:


>Release-Note:
>Audit-Trail:
>Unformatted:





From jhb at freebsd.org  Wed Sep  9 19:08:55 2009
From: jhb at freebsd.org (John Baldwin)
Date: Wed Sep  9 19:09:07 2009
Subject: LOR acpi_ibm module
In-Reply-To: <200909091425.15003.jkim@FreeBSD.org>
References: <179b97fb0905301355n2a422e05j665fc3a551ce06f1@mail.gmail.com>
	<4AA7EAB2.5040403@googlemail.com>
	<200909091425.15003.jkim@FreeBSD.org>
Message-ID: <200909091453.50771.jhb@freebsd.org>

On Wednesday 09 September 2009 2:25:13 pm Jung-uk Kim wrote:
> On Wednesday 09 September 2009 01:49 pm, Felix Stolba wrote:
> > Brandon Gooch schrieb:
> > > lock order reversal:
> > >  1st 0xffffffff807cf200 sysctl lock (sysctl lock) @
> > > /usr/src/sys/kern/kern_sysctl.c:1608
> > >  2nd 0xffffffff80bf1de0 ACPI IBM extras (ACPI IBM extras) @
> > > /usr/src/sys/modules/acpi/acpi_ibm/../../../dev/acpi_support/acpi
> > >_ibm.c:481 KDB: stack backtrace:
> > > db_trace_self_wrapper() at db_trace_self_wrapper+0x2a
> > > _witness_debugger() at _witness_debugger+0x2e
> > > witness_checkorder() at witness_checkorder+0x81e
> > > _sx_xlock() at _sx_xlock+0x54
> > > acpi_ibm_sysctl() at acpi_ibm_sysctl+0x4f
> > > sysctl_root() at sysctl_root+0xe3
> > > userland_sysctl() at userland_sysctl+0x158
> > > __sysctl() at __sysctl+0xaa
> > > syscall() at syscall+0x1dd
> > > Xfast_syscall() at Xfast_syscall+0xd0
> > > --- syscall (202, FreeBSD ELF64, __sysctl), rip = 0x80073769c,
> > > rsp = 0x7fffffffda58, rbp = 0x4 ---
> >
> > I'm getting the same LOR at boot in 9.0-current (source from 7th of
> > september).
> 
> It is generally harmless but really annoying.

Actually, we can just remove the pointless locking from attach to fix this I 
think.  You don't need locking in attach while you are adding the sysctls, 
etc. since no other threads can "get" to the acpi_ibm data yet.  This patch 
should fix the LOR:

Index: acpi_ibm.c
===================================================================
--- acpi_ibm.c	(revision 196974)
+++ acpi_ibm.c	(working copy)
@@ -356,8 +356,6 @@
 	}
 	sc->ec_handle = acpi_get_handle(sc->ec_dev);
 
-	ACPI_SERIAL_BEGIN(ibm);
-
 	/* Get the sysctl tree */
 	sc->sysctl_ctx = device_get_sysctl_ctx(dev);
 	sc->sysctl_tree = device_get_sysctl_tree(dev);
@@ -404,8 +402,6 @@
 		    "Thermal zones");
 	}
 
-	ACPI_SERIAL_END(ibm);
-
 	/* Handle notifies */
 	AcpiInstallNotifyHandler(sc->handle, ACPI_DEVICE_NOTIFY,
 	    acpi_ibm_notify, dev);


-- 
John Baldwin
From jhb at freebsd.org  Wed Sep  9 19:08:57 2009
From: jhb at freebsd.org (John Baldwin)
Date: Wed Sep  9 19:09:08 2009
Subject: acquiring duplicate lock of same type: "ftlk"
In-Reply-To: <a31046fc0909081242v7e1b8f98t72a6df8b9d37a960@mail.gmail.com>
References: <a31046fc0908270158l63b103a7v6c9fd1b7be54d3ed@mail.gmail.com>
	<3bbf2fe10909080213i588493darf8dd1e1ff768cb0a@mail.gmail.com>
	<a31046fc0909081242v7e1b8f98t72a6df8b9d37a960@mail.gmail.com>
Message-ID: <200909091455.42039.jhb@freebsd.org>

On Tuesday 08 September 2009 3:42:13 pm pluknet wrote:
> 2009/9/8 Attilio Rao <attilio@freebsd.org>:
> > 2009/9/8 Kostik Belousov <kostikbel@gmail.com>:
> >> On Mon, Sep 07, 2009 at 10:15:48PM +0400, pluknet wrote:
> >>> lock order reversal:
> >>> ?1st 0xc75365b8 pseudofs (pseudofs) @ /usr/src/sys/kern/vfs_lookup.c:497
> >>> ?2nd 0xc088ea3c allproc (allproc) @ /usr/src/sys/kern/kern_proc.c:292
> >>> KDB: stack backtrace:
> >>> db_trace_self_wrapper(c07fd8ea,e82148e4,c060a145,c05fac1b,c08008bf,...)
> >>> at db_trace_self_wrapper+0x26
> >>> kdb_backtrace(c05fac1b,c08008bf,c58eabe8,c58e30d0,e8214940,...) at
> >>> kdb_backtrace+0x29
> >>> _witness_debugger(c08008bf,c088ea3c,c07f981d,c58e30d0,c07f96f0,...) at
> >>> _witness_debugger+0x25
> >>> witness_checkorder(c088ea3c,1,c07f96f0,124,0,...) at 
witness_checkorder+0x839
> >>> _sx_slock(c088ea3c,0,c07f96f0,124,c73c4980,...) at _sx_slock+0x85
> >>> pfind(514,c72ba1a0,4,c07f8d78,c5fe1b40,...) at pfind+0x2f
> >>> pfs_visible(0,0,c07f042d,7c,c7536560,...) at pfs_visible+0x3a
> >>> pfs_lookup(e8214a40,c082715e,c7536560,c7536560,e8214bf8,...) at 
pfs_lookup+0x3dd
> >>> VOP_CACHEDLOOKUP_APV(c0843960,e8214a40,e8214bf8,e8214be4,c73c4e80,...)
> >>> at VOP_CACHEDLOOKUP_APV+0xc5
> >>> vfs_cache_lookup(e8214acc,c08087d0,c0875a00,200000,e8214bcc,...) at
> >>> vfs_cache_lookup+0xd6
> >>> VOP_LOOKUP_APV(c0843960,e8214acc,e8214bf8,1f1,e8214be4,...) at
> >>> VOP_LOOKUP_APV+0xe5
> >>> lookup(e8214bcc,c5fd1800,0,c5,c5ef77f8,...) at lookup+0x63b
> >>> namei(e8214bcc,c5c1500d,3f3,e8214c20,c5c1500d,...) at namei+0x57f
> >>> kern_alternate_path(c5fe1b40,c0b4921c,2879f478,0,e8214c74,...) at 
kern_alternate
> >>> _path+0x1cd
> >>> linux_emul_convpath(c5fe1b40,2879f478,0,e8214c74,0,...) at
> >>> linux_emul_convpath+0x3c
> >>> linux_open(c5fe1b40,e8214cf8,e8214d18,e8214d1c,c0b4b58c,...) at 
linux_open+0x41
> >>> syscall(e8214d38) at syscall+0x2b4
> >>> Xint0x80_syscall() at Xint0x80_syscall+0x20
> >>> --- syscall (5, Linux ELF, linux_open), eip = 0x2889115e, esp =
> >>> 0xbfbfbd1c, ebp = 0xbfbfbd6c ---
> >>> acquiring duplicate lock of same type: "ftlk"
> >>> [...]
> >>
> >> The second LOR actually exposes the right order. It would be interesting
> >> to look up the point where the other order is established.
> >
> > You would manually patch the witness static table with this order and
> > the opposite will show, when happening.
> >
> 
> I've patched witness order table, and still no opposite case,
> nor any pseudofs related LORs at all.
>         { "pseudofs", &lock_class_lockmgr },
>         { "allproc", &lock_class_sx },
>         { NULL, NULL },
> 
> Seen orders with pseudofs:
> "ufs","pseudofs"
> "pseudofs","allproc"
> "pseudofs","process lock"
> "pseudofs","vnode interlock"
> "pseudofs","struct mount mtx"
> "pseudofs","UMA zone"
> "pseudofs","sleep mtxpool"
> "pseudofs","Name Cache"
> "pseudofs","vnode_free_list"
> "pseudofs","pfs_node"
> "pseudofs","pfs_vncache"
> 
> Something else?

What are the seen orders with "allproc"?

-- 
John Baldwin
From jhb at freebsd.org  Wed Sep  9 19:08:58 2009
From: jhb at freebsd.org (John Baldwin)
Date: Wed Sep  9 19:09:18 2009
Subject: lock order reversal etc.
In-Reply-To: <4AA7D4BA.40002@demig.de>
References: <4AA7D4BA.40002@demig.de>
Message-ID: <200909091507.32600.jhb@freebsd.org>

On Wednesday 09 September 2009 12:15:54 pm Norbert Koch wrote:
> Hello.
> 
> Is this the right mailing list to post
> kernel stack traces from Freebsd-8-BETA4?
> If yes, see below, otherwise just ignore this message.
> 
> uma_zalloc_arg: zone "64" with the following non-sleepable locks held:
> exclusive sleep mutex jail mutex (jail mutex) r = 0 (0xc0b91328) locked
> @
> /usr/src/sys/modules/syscons/daemon/../../../dev/syscons/daemon/daemon_saver.c:355
> KDB: stack backtrace:
> db_trace_self_wrapper(c0abf50f,e69b391c,c07ab3b5,c4a0580a,163,...) at
> db_trace_self_wrapper+0x26
> kdb_backtrace(c4a0580a,163,ffffffff,c0d261c4,e69b3954,...) at
> kdb_backtrace+0x29
> _witness_debugger(c0ac198e,e69b3968,4,1,0,...) at _witness_debugger+0x25
> witness_warn(5,0,c0ae4b92,c0add27b,e69b3984,...) at witness_warn+0x1fd
> uma_zalloc_arg(c148b000,0,2,2,14,...) at uma_zalloc_arg+0x34
> malloc(29,c0b92dd0,2,163,c46562e4,...) at malloc+0xe4
> daemon_init(c0d61940,c0aba83e,e69b3a28,c46f5600,c4a06cc0,...) at
> daemon_init+0x7b
> splash_test(7b,c46f5600,c4a06cc0,c46f5600,e69b3a50,...) at splash_test+0x91
> splash_register(c4a06c40,0,0,76,0,...) at splash_register+0x48

Try this patch for this one:

Index: daemon_saver.c
===================================================================
--- daemon_saver.c	(revision 196974)
+++ daemon_saver.c	(working copy)
@@ -351,11 +351,23 @@
 static int
 daemon_init(video_adapter_t *adp)
 {
+	size_t hostlen;
 
 	mtx_lock(&prison0.pr_mtx);
-	messagelen = strlen(prison0.pr_hostname) + 3 + strlen(ostype) + 1 + 
-	    strlen(osrelease);
-	message = malloc(messagelen + 1, M_DEVBUF, M_WAITOK);
+	for (;;) {
+		hostlen = strlen(prison0.pr_hostname);
+		mtx_unlock(&prison0.pr_mtx);
+	
+		messagelen = hostlen + 3 + strlen(ostype) + 1 +
+		    strlen(osrelease);
+		message = malloc(messagelen + 1, M_DEVBUF, M_WAITOK);
+		mtx_lock(&prison0.pr_mtx);
+		if (hostlen < strlen(prison0.pr_hostname)) {
+			free(message, M_DEVBUF);
+			continue;
+		}
+		break;
+	}
 	sprintf(message, "%s - %s %s", prison0.pr_hostname, ostype, osrelease);
 	mtx_unlock(&prison0.pr_mtx);
 	blanked = 0;

> lock order reversal:
>  1st 0xc4afca2c filedesc structure (filedesc structure) @
> /usr/src/sys/kern/kern_descrip.c:1088
>  2nd 0xc4be3488 ufs (ufs) @ /usr/src/sys/kern/vfs_subr.c:4091
> KDB: stack backtrace:

This is the right order.  I think several of these have been fixed, but there 
still might be some place that uses UFS -> filedesc.  You can try hardcoding 
that order into witness to find it.

> lock order reversal:
>  1st 0xd82d03f0 bufwait (bufwait) @ /usr/src/sys/kern/vfs_bio.c:2559
>  2nd 0xc4f64800 dirhash (dirhash) @ /usr/src/sys/ufs/ufs/ufs_dirhash.c:285

This is known to be harmless.

> lock order reversal:
>  1st 0xc464337c ufs (ufs) @ /usr/src/sys/kern/vfs_subr.c:2083
>  2nd 0xd81d14b0 bufwait (bufwait) @ /usr/src/sys/ufs/ffs/ffs_softdep.c:6177
>  3rd 0xc673a7ac ufs (ufs) @ /usr/src/sys/kern/vfs_subr.c:2083
> KDB: stack backtrace:
> db_trace_self_wrapper(c0abf50f,e6b103cc,c07ab3b5,c079c13b,c0ac23fb,...)
> at db_trace_self_wrapper+0x26
> kdb_backtrace(c079c13b,c0ac23fb,c4122e90,c4126290,e6b10428,...) at
> kdb_backtrace+0x29
> _witness_debugger(c0ac23fb,c673a7ac,c0ab4f66,c4126290,c0ac96be,...) at
> _witness_debugger+0x25
> witness_checkorder(c673a7ac,9,c0ac96be,823,0,...) at
> witness_checkorder+0x839
> __lockmgr_args(c673a7ac,80100,c673a7c8,0,0,...) at __lockmgr_args+0x7a7
> ffs_lock(e6b10538,c07ab15b,c0ac8bb1,80100,c673a754,...) at ffs_lock+0x8a
> VOP_LOCK1_APV(c0bae360,e6b10538,c4c08524,c0bc5660,c673a754,...) at
> VOP_LOCK1_APV+0xb5
> _vn_lock(c673a754,80100,c0ac96be,823,4,...) at _vn_lock+0x5e
> vget(c673a754,80100,c4c08480,50,0,...) at vget+0xb9
> vfs_hash_get(c46e1508,18ef074,80000,c4c08480,e6b10694,...) at
> vfs_hash_get+0xe6
> ffs_vgetf(c46e1508,18ef074,80000,e6b10694,1,...) at ffs_vgetf+0x49
> softdep_sync_metadata(c4643324,0,c0ae2efa,146,0,...) at
> softdep_sync_metadata+0x5ba
> ffs_syncvnode(c4643324,1,c0abaa2c,c0ab45da,3,...) at ffs_syncvnode+0x3e2
> ffs_truncate(c4643324,600,0,880,c465d280,...) at ffs_truncate+0x66a
> ufs_direnter(c4643324,c673a754,e6b10a1c,e6b10c00,d82ec1d0,...) at
> ufs_direnter+0x8f6
> ufs_mkdir(e6b10c28,e6b10c3c,0,0,e6b10b6c,...) at ufs_mkdir+0x8a7
> VOP_MKDIR_APV(c0bae360,e6b10c28,e6b10c00,e6b10b6c,0,...) at
> VOP_MKDIR_APV+0xa5
> kern_mkdirat(c4c08480,ffffff9c,804c2e8,0,41fd,...) at kern_mkdirat+0x22b
> kern_mkdir(c4c08480,804c2e8,0,41fd,e6b10d2c,...) at kern_mkdir+0x2e
> mkdir(c4c08480,e6b10cf8,8,c0ac2cbd,c0b8d920,...) at mkdir+0x29
> syscall(e6b10d38) at syscall+0x2a3
> Xint0x80_syscall() at Xint0x80_syscall+0x20

This is probably harmless.

-- 
John Baldwin
From qing.li at bluecoat.com  Wed Sep  9 19:14:47 2009
From: qing.li at bluecoat.com (Li, Qing)
Date: Wed Sep  9 19:14:59 2009
Subject: misc/138676: after buildworld not work local routes
In-Reply-To: <4AA7FC4B.6090601@ukr.net>
References: <4AA7FC4B.6090601@ukr.net>
Message-ID: <B583FBF374231F4A89607B4D08578A43053CEBA7@bcs-mail03.internal.cacheflow.com>

Thanks for the report. I will work you off list for now.

-- Qing


> -----Original Message-----
> From: Vladislav V. Prodan [mailto:universite@ukr.net]
> Sent: Wednesday, September 09, 2009 12:05 PM
> To: freebsd-current@freebsd.org; freebsd-net@freebsd.org
> Cc: Li, Qing
> Subject: misc/138676: after buildworld not work local routes
> 
> >Number:         138676
> >Category:       misc
> >Synopsis:       after buildworld not work local routes
> >Confidential:   no
> >Severity:       serious
> >Priority:       medium
> >Responsible:    freebsd-bugs
> >State:          open
> >Quarter:
> >Keywords:
> >Date-Required:
> >Class:          sw-bug
> >Submitter-Id:   current-users
> >Arrival-Date:   Wed Sep 09 19:00:04 UTC 2009
> >Closed-Date:
> >Last-Modified:
> >Originator:     Vladislav V. Prodan
> >Release:        FreeBSD 8.0-BETA4 #0: Wed Sep  9 00:53:41 EEST 2009
> amd64
> >Organization:
> >Environment:
> FreeBSD mary-teresa.otrada.od.ua 8.0-BETA4 FreeBSD 8.0-BETA4 #0: Wed
> Sep
>   9 00:53:41 EEST 2009
> vlad11@mary-teresa.otrada.od.ua:/usr/obj/usr/src/sys/mary-teresa.17
> amd64
> 
> >Description:
> home PC --> FreeBSD [ squid --> apache ]
> 
> These url are on the external interface of the server.
> http://otrada.od.ua/blog/
> http://otrada.od.ua/phpmyadmin/
> http://otrada.od.ua/cacti/
> 
> After upgrade the system now gives the squid:
>      (51) Network is unreachable
> 
> In logs:
> sep  9 18:39:10 128 10.0.0.10 TCP_MISS/503 1317 GET
> http://otrada.od.ua/blog/ - DIRECT/otrada.od.ua text/html
> sep  9 18:39:18 126 10.0.0.10 TCP_MISS/503 1329 GET
> http://otrada.od.ua/phpmyadmin/ - DIRECT/otrada.od.ua text/html
> sep  9 18:39:39 117 10.0.0.10 TCP_MISS/503 1319 GET
> http://otrada.od.ua/cacti/ - DIRECT/otrada.od.ua text/html
> 
> Out all three url normally give details.
> At queries from outside, all url are working properly.
> 
> similar problem was previously:
> http://lists.freebsd.org/pipermail/freebsd-current/2008-
> December/001581.html
> >How-To-Repeat:
> 
> >Fix:
> 
> 
> >Release-Note:
> >Audit-Trail:
> >Unformatted:
> 
> 
> 
> 

From pluknet at gmail.com  Wed Sep  9 19:25:52 2009
From: pluknet at gmail.com (pluknet)
Date: Wed Sep  9 19:26:47 2009
Subject: acquiring duplicate lock of same type: "ftlk"
In-Reply-To: <200909091455.42039.jhb@freebsd.org>
References: <a31046fc0908270158l63b103a7v6c9fd1b7be54d3ed@mail.gmail.com>
	<3bbf2fe10909080213i588493darf8dd1e1ff768cb0a@mail.gmail.com>
	<a31046fc0909081242v7e1b8f98t72a6df8b9d37a960@mail.gmail.com>
	<200909091455.42039.jhb@freebsd.org>
Message-ID: <a31046fc0909091225n2fe7e921m93071937004f08b8@mail.gmail.com>

2009/9/9 John Baldwin <jhb@freebsd.org>:
> On Tuesday 08 September 2009 3:42:13 pm pluknet wrote:
>> 2009/9/8 Attilio Rao <attilio@freebsd.org>:
>> > 2009/9/8 Kostik Belousov <kostikbel@gmail.com>:
>> >> On Mon, Sep 07, 2009 at 10:15:48PM +0400, pluknet wrote:
>> >>> lock order reversal:
>> >>> ?1st 0xc75365b8 pseudofs (pseudofs) @ /usr/src/sys/kern/vfs_lookup.c:497
>> >>> ?2nd 0xc088ea3c allproc (allproc) @ /usr/src/sys/kern/kern_proc.c:292
>> >>> KDB: stack backtrace:
>> >>> db_trace_self_wrapper(c07fd8ea,e82148e4,c060a145,c05fac1b,c08008bf,...)
>> >>> at db_trace_self_wrapper+0x26
>> >>> kdb_backtrace(c05fac1b,c08008bf,c58eabe8,c58e30d0,e8214940,...) at
>> >>> kdb_backtrace+0x29
>> >>> _witness_debugger(c08008bf,c088ea3c,c07f981d,c58e30d0,c07f96f0,...) at
>> >>> _witness_debugger+0x25
>> >>> witness_checkorder(c088ea3c,1,c07f96f0,124,0,...) at
> witness_checkorder+0x839
>> >>> _sx_slock(c088ea3c,0,c07f96f0,124,c73c4980,...) at _sx_slock+0x85
>> >>> pfind(514,c72ba1a0,4,c07f8d78,c5fe1b40,...) at pfind+0x2f
>> >>> pfs_visible(0,0,c07f042d,7c,c7536560,...) at pfs_visible+0x3a
>> >>> pfs_lookup(e8214a40,c082715e,c7536560,c7536560,e8214bf8,...) at
> pfs_lookup+0x3dd
>> >>> VOP_CACHEDLOOKUP_APV(c0843960,e8214a40,e8214bf8,e8214be4,c73c4e80,...)
>> >>> at VOP_CACHEDLOOKUP_APV+0xc5
>> >>> vfs_cache_lookup(e8214acc,c08087d0,c0875a00,200000,e8214bcc,...) at
>> >>> vfs_cache_lookup+0xd6
>> >>> VOP_LOOKUP_APV(c0843960,e8214acc,e8214bf8,1f1,e8214be4,...) at
>> >>> VOP_LOOKUP_APV+0xe5
>> >>> lookup(e8214bcc,c5fd1800,0,c5,c5ef77f8,...) at lookup+0x63b
>> >>> namei(e8214bcc,c5c1500d,3f3,e8214c20,c5c1500d,...) at namei+0x57f
>> >>> kern_alternate_path(c5fe1b40,c0b4921c,2879f478,0,e8214c74,...) at
> kern_alternate
>> >>> _path+0x1cd
>> >>> linux_emul_convpath(c5fe1b40,2879f478,0,e8214c74,0,...) at
>> >>> linux_emul_convpath+0x3c
>> >>> linux_open(c5fe1b40,e8214cf8,e8214d18,e8214d1c,c0b4b58c,...) at
> linux_open+0x41
>> >>> syscall(e8214d38) at syscall+0x2b4
>> >>> Xint0x80_syscall() at Xint0x80_syscall+0x20
>> >>> --- syscall (5, Linux ELF, linux_open), eip = 0x2889115e, esp =
>> >>> 0xbfbfbd1c, ebp = 0xbfbfbd6c ---
>> >>> acquiring duplicate lock of same type: "ftlk"
>> >>> [...]
>> >>
>> >> The second LOR actually exposes the right order. It would be interesting
>> >> to look up the point where the other order is established.
>> >
>> > You would manually patch the witness static table with this order and
>> > the opposite will show, when happening.
>> >
>>
>> I've patched witness order table, and still no opposite case,
>> nor any pseudofs related LORs at all.
>> ? ? ? ? { "pseudofs", &lock_class_lockmgr },
>> ? ? ? ? { "allproc", &lock_class_sx },
>> ? ? ? ? { NULL, NULL },
>>
>> Seen orders with pseudofs:
>> "ufs","pseudofs"
>> "pseudofs","allproc"
>> "pseudofs","process lock"
>> "pseudofs","vnode interlock"
>> "pseudofs","struct mount mtx"
>> "pseudofs","UMA zone"
>> "pseudofs","sleep mtxpool"
>> "pseudofs","Name Cache"
>> "pseudofs","vnode_free_list"
>> "pseudofs","pfs_node"
>> "pseudofs","pfs_vncache"
>>
>> Something else?
>
> What are the seen orders with "allproc"?
>

sysctl debug.witness.fullgraph | grep allproc
"proctree","allproc"
"allproc","allprison"
"allproc","process lock"
"allproc","user map"
"allproc","fdesc"
"allproc","filedesc structure"
"sysctl lock","allproc"
"pseudofs","allproc"

Also, if it matters, I saw this LOR today:

lock order reversal:
 1st 0xc7f01164 ufs (ufs) @ /usr/RELENG_8/src/sys/kern/vfs_mount.c:1054
 2nd 0xc7fb5058 pseudofs (pseudofs) @
/usr/RELENG_8/src/sys/fs/pseudofs/pseudofs_vncache.c:193
KDB: stack backtrace:
db_trace_self_wrapper(c0c7545b,eab2c850,c08c0f75,c08b1cfb,c0c783a3,...)
at db_trace_self_wrapper+0x26
kdb_backtrace(c08b1cfb,c0c783a3,c612fbe8,c61281a0,eab2c8ac,...) at
kdb_backtrace+0x29
_witness_debugger(c0c783a3,c7fb5058,c0c679b8,c61281a0,c0c6803f,...) at
_witness_debugger+0x25
witness_checkorder(c7fb5058,9,c0c6803f,c1,c7fb5074,...) at
witness_checkorder+0x839
__lockmgr_args(c7fb5058,80400,c7fb5074,0,0,...) at __lockmgr_args+0x7a7
vop_stdlock(eab2c9b4,c087030a,c7fb50a8,80400,c7fb5000,...) at vop_stdlock+0x62
VOP_LOCK1_APV(c0d55580,eab2c9b4,c0911dcf,c0d92080,c7fb5000,...) at
VOP_LOCK1_APV+0xb5
_vn_lock(c7fb5000,80400,c0c6803f,c1,c0f3339c,...) at _vn_lock+0x5e
pfs_vncache_alloc(c6764c94,eab2cc30,c7d1cb00,186a0,eab2cc60,...) at
pfs_vncache_alloc+0x232
pfs_root(c6764c94,80000,eab2cc30,42c,0,...) at pfs_root+0x2d
vfs_donmount(c7ba76c0,0,c6b66500,c6b66500,bfbfdc89,...) at vfs_donmount+0x14c2
nmount(c7ba76c0,eab2ccf8,c,c7ba76c0,c0d5a638,...) at nmount+0x75
syscall(eab2cd38) at syscall+0x2a3
Xint0x80_syscall() at Xint0x80_syscall+0x20
--- syscall (378, FreeBSD ELF32, nmount), eip = 0x280e876b, esp =
0xbfbfdc5c, ebp = 0xbfbfe1b8 ---


-- 
wbr,
pluknet
From jhb at freebsd.org  Wed Sep  9 19:41:04 2009
From: jhb at freebsd.org (John Baldwin)
Date: Wed Sep  9 19:41:28 2009
Subject: acquiring duplicate lock of same type: "ftlk"
In-Reply-To: <a31046fc0909091225n2fe7e921m93071937004f08b8@mail.gmail.com>
References: <a31046fc0908270158l63b103a7v6c9fd1b7be54d3ed@mail.gmail.com>
	<200909091455.42039.jhb@freebsd.org>
	<a31046fc0909091225n2fe7e921m93071937004f08b8@mail.gmail.com>
Message-ID: <200909091540.57890.jhb@freebsd.org>

On Wednesday 09 September 2009 3:25:50 pm pluknet wrote:
> 2009/9/9 John Baldwin <jhb@freebsd.org>:
> > On Tuesday 08 September 2009 3:42:13 pm pluknet wrote:
> >> 2009/9/8 Attilio Rao <attilio@freebsd.org>:
> >> > 2009/9/8 Kostik Belousov <kostikbel@gmail.com>:
> >> >> On Mon, Sep 07, 2009 at 10:15:48PM +0400, pluknet wrote:
> >> >>> lock order reversal:
> >> >>> ?1st 0xc75365b8 pseudofs (pseudofs) @ /usr/src/sys/kern/vfs_lookup.c:497
> >> >>> ?2nd 0xc088ea3c allproc (allproc) @ /usr/src/sys/kern/kern_proc.c:292
> >> >>> KDB: stack backtrace:
> >> >>> db_trace_self_wrapper(c07fd8ea,e82148e4,c060a145,c05fac1b,c08008bf,...)
> >> >>> at db_trace_self_wrapper+0x26
> >> >>> kdb_backtrace(c05fac1b,c08008bf,c58eabe8,c58e30d0,e8214940,...) at
> >> >>> kdb_backtrace+0x29
> >> >>> _witness_debugger(c08008bf,c088ea3c,c07f981d,c58e30d0,c07f96f0,...) at
> >> >>> _witness_debugger+0x25
> >> >>> witness_checkorder(c088ea3c,1,c07f96f0,124,0,...) at
> > witness_checkorder+0x839
> >> >>> _sx_slock(c088ea3c,0,c07f96f0,124,c73c4980,...) at _sx_slock+0x85
> >> >>> pfind(514,c72ba1a0,4,c07f8d78,c5fe1b40,...) at pfind+0x2f
> >> >>> pfs_visible(0,0,c07f042d,7c,c7536560,...) at pfs_visible+0x3a
> >> >>> pfs_lookup(e8214a40,c082715e,c7536560,c7536560,e8214bf8,...) at
> > pfs_lookup+0x3dd
> >> >>> VOP_CACHEDLOOKUP_APV(c0843960,e8214a40,e8214bf8,e8214be4,c73c4e80,...)
> >> >>> at VOP_CACHEDLOOKUP_APV+0xc5
> >> >>> vfs_cache_lookup(e8214acc,c08087d0,c0875a00,200000,e8214bcc,...) at
> >> >>> vfs_cache_lookup+0xd6
> >> >>> VOP_LOOKUP_APV(c0843960,e8214acc,e8214bf8,1f1,e8214be4,...) at
> >> >>> VOP_LOOKUP_APV+0xe5
> >> >>> lookup(e8214bcc,c5fd1800,0,c5,c5ef77f8,...) at lookup+0x63b
> >> >>> namei(e8214bcc,c5c1500d,3f3,e8214c20,c5c1500d,...) at namei+0x57f
> >> >>> kern_alternate_path(c5fe1b40,c0b4921c,2879f478,0,e8214c74,...) at
> > kern_alternate
> >> >>> _path+0x1cd
> >> >>> linux_emul_convpath(c5fe1b40,2879f478,0,e8214c74,0,...) at
> >> >>> linux_emul_convpath+0x3c
> >> >>> linux_open(c5fe1b40,e8214cf8,e8214d18,e8214d1c,c0b4b58c,...) at
> > linux_open+0x41
> >> >>> syscall(e8214d38) at syscall+0x2b4
> >> >>> Xint0x80_syscall() at Xint0x80_syscall+0x20
> >> >>> --- syscall (5, Linux ELF, linux_open), eip = 0x2889115e, esp =
> >> >>> 0xbfbfbd1c, ebp = 0xbfbfbd6c ---
> >> >>> acquiring duplicate lock of same type: "ftlk"
> >> >>> [...]
> >> >>
> >> >> The second LOR actually exposes the right order. It would be interesting
> >> >> to look up the point where the other order is established.
> >> >
> >> > You would manually patch the witness static table with this order and
> >> > the opposite will show, when happening.
> >> >
> >>
> >> I've patched witness order table, and still no opposite case,
> >> nor any pseudofs related LORs at all.
> >> ? ? ? ? { "pseudofs", &lock_class_lockmgr },
> >> ? ? ? ? { "allproc", &lock_class_sx },
> >> ? ? ? ? { NULL, NULL },
> >>
> >> Seen orders with pseudofs:
> >> "ufs","pseudofs"
> >> "pseudofs","allproc"
> >> "pseudofs","process lock"
> >> "pseudofs","vnode interlock"
> >> "pseudofs","struct mount mtx"
> >> "pseudofs","UMA zone"
> >> "pseudofs","sleep mtxpool"
> >> "pseudofs","Name Cache"
> >> "pseudofs","vnode_free_list"
> >> "pseudofs","pfs_node"
> >> "pseudofs","pfs_vncache"
> >>
> >> Something else?
> >
> > What are the seen orders with "allproc"?
> >
> 
> sysctl debug.witness.fullgraph | grep allproc
> "proctree","allproc"
> "allproc","allprison"
> "allproc","process lock"
> "allproc","user map"
> "allproc","fdesc"
> "allproc","filedesc structure"
> "sysctl lock","allproc"
> "pseudofs","allproc"

Ok, there is probably an order of "allproc" -> "filedesc" -> "ufs" ->
"psuedofs".  There might even be a "filedesc" -> "psuedofs" that could
cause this.

> Also, if it matters, I saw this LOR today:
> 
> lock order reversal:
>  1st 0xc7f01164 ufs (ufs) @ /usr/RELENG_8/src/sys/kern/vfs_mount.c:1054
>  2nd 0xc7fb5058 pseudofs (pseudofs) @
> /usr/RELENG_8/src/sys/fs/pseudofs/pseudofs_vncache.c:193

I think this backs up my theory.  I think the LOR is probably harmless,
but there's not an easy way to shut it up I believe.

-- 
John Baldwin
From universite at ukr.net  Wed Sep  9 20:18:45 2009
From: universite at ukr.net (Vladislav V. Prodan)
Date: Wed Sep  9 20:18:52 2009
Subject: misc/138676: after buildworld not work local routes
In-Reply-To: <B583FBF374231F4A89607B4D08578A43053CEC1F@bcs-mail03.internal.cacheflow.com>
References: <4AA7FC4B.6090601@ukr.net>
	<B583FBF374231F4A89607B4D08578A43053CEBBA@bcs-mail03.internal.cacheflow.com>
	<4AA802EF.6090402@ukr.net>
	<B583FBF374231F4A89607B4D08578A43053CEBD6@bcs-mail03.internal.cacheflow.com>
	<4AA809BF.9050506@ukr.net>
	<B583FBF374231F4A89607B4D08578A43053CEC1F@bcs-mail03.internal.cacheflow.com>
Message-ID: <4AA80D9A.2000609@ukr.net>

Li, Qing ?????:
> Okay, perhaps I didn't understand your issue correctly. In

> http://lists.freebsd.org/pipermail/freebsd-current/2008-December/001581.html

> the errors are route insertion related. Those routes are not
> visible inside the kernel. Now these routes show up in the
> table but Squid reports

> " After upgrade the system now gives the squid:
>      (51) Network is unreachable"

> Which IP address is not reachable?

Do not operate sites on IP 89.209.81.54, when you walk through the squid.
If you go to the sites, bypassing squid, then everything works.

It seems, squid does not "see" the table of the form:
Destination        Gateway            Flags    Refs      Use  Netif Expire
89.209.81.54       link#4             UHS         0    30161    lo0
From nox at jelal.kn-bremen.de  Wed Sep  9 20:18:55 2009
From: nox at jelal.kn-bremen.de (Juergen Lock)
Date: Wed Sep  9 20:19:02 2009
Subject: FreeBSD timing issues and qemu (was: Re: [Qemu-devel] Re:
 Breakage with local APIC routing)
In-Reply-To: <bc2d970909071917n12256d9ucee24327aec3d527@mail.gmail.com>
References: <52d4a3890908250321u746e5757u136030bcbc19208d@mail.gmail.com>
	<4A93BF0C.8040601@web.de>
	<20090826221001.GA1070@triton8.kn-bremen.de>
	<4A96C8D9.6070804@web.de>
	<20090829211848.GA59305@triton8.kn-bremen.de>
	<4A9B800F.1040209@web.de>
	<20090831212723.GA32448@triton8.kn-bremen.de>
	<20090901201248.GA60123@triton8.kn-bremen.de>
	<20090907205955.GA91866@triton8.kn-bremen.de>
	<bc2d970909071917n12256d9ucee24327aec3d527@mail.gmail.com>
Message-ID: <20090909201556.GA95426@triton8.kn-bremen.de>

On Mon, Sep 07, 2009 at 10:17:23PM -0400, Ryan Stone wrote:
> I'm not entirely clear on why it's done this way, but the timer is run at
> twice hz for statistics-gathering purposes*.  CPU usage statistics gathering
> is driven off of the timer interrupt.  Running the timer at twice hz may be
> an attempt to eliminate clock-aliasing problems; if so, it's a poor way of
> doing so.  In any case, seeing interrupts come in at twice hz is expected
> behaviour.  This means that the guest will be requesting a timer interrupt
> rate of twice the granularity that the host's scheduler can support; this
> may be the cause of your other timing problems(although I have a hard time
> imagining how).
> 
Yes, this is the first issue I reported, and it causes e.g. a FreeBSD 7
guest on a 7 host to sleep ~4s on a `time sleep 2'.  (unless when I
disable apic as I said.)

> This timer is twice hz behaviour has existed at least since FreeBSD 6.1, so
> I can't explain why you see the new behaviour between 7 and 8.  You do have
> hz set to 1000 on both the guest and host when running 7?
> 
 Yes, and the behaviour on 8 is in addition to the guest expecting
clock irqs at 2000 Hz, i.e. on 8 the guest gets only around 500 Hz
with -clock unix instead of ~1000 Hz on a 7 host, and `time sleep 2'
then consequently sleeps ~8s.

> * Actually, from looking at the code the behaviour is dynamic.  If hz >=
> 1500, the timer interrupt rate is set to hz.  If 750 <= hz < 1500, the timer
> interrupt rate is set to 2 * hz.  If hz < 750, the timer interrupt rate is
> set to 4 * hz.

 Aha, so another way to get around the first issue would be to run at
least the host with HZ=2000...  Worth a try, tho I suspect it won't help
the additional rate halving on 8, unless maybe to use even HZ=4000.
Oh well...

	Juergen
From peterjeremy at acm.org  Wed Sep  9 20:20:32 2009
From: peterjeremy at acm.org (Peter Jeremy)
Date: Wed Sep  9 20:20:38 2009
Subject: sshd failing in jail
In-Reply-To: <20090830144452.GK1881@deviant.kiev.zoral.com.ua>
References: <20090824193344.GA34949@server.vk2pj.dyndns.org>
	<20090829233454.GA13036@server.vk2pj.dyndns.org>
	<20090830144452.GK1881@deviant.kiev.zoral.com.ua>
Message-ID: <20090909202028.GA61633@server.vk2pj.dyndns.org>

My apologies for the delay.  Without warning, my ISP decided to
disable the domain I was using for email and I have been busy
repairing the damage.
 
On 2009-Aug-30 17:44:52 +0300, Kostik Belousov <kostikbel@gmail.com> wrote:
>On Sun, Aug 30, 2009 at 09:34:54AM +1000, Peter Jeremy wrote:
>> Turns out this is a bug in the 32-bit select(2) wrapper on 64-bit
>> kernels.  The userland fd_set arguments are not wrapped but passed
>> directly to kern_select().  Unfortunately, fd_set is (effectively) an
>> array of longs which means kern_select() assumes fd_set is a multiple
>> of 8-bytes whilst userland assumes it is a multiple of 4 bytes.  As a
>> result, the kernel can over-write an extra 4 bytes of user memory.  In
>> the case of sshd, this causes part of the RSA host key to be trashed
>> when privilege separation mode is enabled.
>> 
>> This bug also affects linux emulation on amd64 and potentially affects
>> any other 64-bit kernels with 32-bit emulation modes.  I have raised
>> amd64/138318 to cover it.
>
>I do not think that we can go the proposed route, since changing the
>type of __fd_mask changes the type of fd_set. The later would not
>affect the kernel ABI, but definitely changes the ABI of any code that
>passes fd_sets.

I agree it was something of a hack.

>Also, looking closely at the issue you found, I think that copyin
>is the same problematic as copyout, since we can end up reading
>one more word then userspace supplied. This is not a problem only
>because most user code keeps fd_sets on stack.

Agreed.  I was aware that copyin() could read an extra 4 bytes but
did not work through the full implications of this - it is possible
that select(2) could unexpectedly return EFAULT.

>Could you test that the patch below fixes real sshd issue. At least,
>it passes your select test from the PR.

It works OK for me.  Please feel free to commit it.

-- 
Peter Jeremy
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20090909/07d529b2/attachment.pgp
From rysto32 at gmail.com  Wed Sep  9 20:39:06 2009
From: rysto32 at gmail.com (Ryan Stone)
Date: Wed Sep  9 20:39:12 2009
Subject: FreeBSD timing issues and qemu (was: Re: [Qemu-devel] Re: 
	Breakage with local APIC routing)
In-Reply-To: <20090909201556.GA95426@triton8.kn-bremen.de>
References: <52d4a3890908250321u746e5757u136030bcbc19208d@mail.gmail.com>
	<20090826221001.GA1070@triton8.kn-bremen.de> <4A96C8D9.6070804@web.de>
	<20090829211848.GA59305@triton8.kn-bremen.de>
	<4A9B800F.1040209@web.de>
	<20090831212723.GA32448@triton8.kn-bremen.de>
	<20090901201248.GA60123@triton8.kn-bremen.de>
	<20090907205955.GA91866@triton8.kn-bremen.de>
	<bc2d970909071917n12256d9ucee24327aec3d527@mail.gmail.com>
	<20090909201556.GA95426@triton8.kn-bremen.de>
Message-ID: <bc2d970909091339n71d28839qf685c33ab5ae9253@mail.gmail.com>

Luigi Rizzo recently posted a thread to current (
http://lists.freebsd.org/pipermail/freebsd-current/2009-September/011393.html)
that would explain the new problem on FreeBSD 8.  He posted a patch
that
you can try.
From rizzo at iet.unipi.it  Wed Sep  9 20:58:51 2009
From: rizzo at iet.unipi.it (Luigi Rizzo)
Date: Wed Sep  9 20:58:59 2009
Subject: FreeBSD timing issues and qemu (was: Re: [Qemu-devel] Re:
	Breakage with local APIC routing)
In-Reply-To: <20090907205955.GA91866@triton8.kn-bremen.de>
References: <52d4a3890908250316l4de68725xa9d780e7d5b37205@mail.gmail.com>
	<52d4a3890908250321u746e5757u136030bcbc19208d@mail.gmail.com>
	<4A93BF0C.8040601@web.de>
	<20090826221001.GA1070@triton8.kn-bremen.de>
	<4A96C8D9.6070804@web.de>
	<20090829211848.GA59305@triton8.kn-bremen.de>
	<4A9B800F.1040209@web.de>
	<20090831212723.GA32448@triton8.kn-bremen.de>
	<20090901201248.GA60123@triton8.kn-bremen.de>
	<20090907205955.GA91866@triton8.kn-bremen.de>
Message-ID: <20090909204616.GB93761@onelab2.iet.unipi.it>

On Mon, Sep 07, 2009 at 10:59:55PM +0200, Juergen Lock wrote:
> [I'm copying freebsd-current@FreeBSD.org because ppl there might know
> more about this...]
> 
>  qemu on FreeBSD hosts used to be able to run a (FreeBSD at least) guest
> with the same HZ as the host (like, 1000) with (mostly) proper timing
> once, but no longer. :(  It seems there are two problems involved:
> 
>  a) use of apic seems to cause the clock irq rate to be doubled to 2 * HZ
> (can anyone explain why?), i.e. a FreeBSD 7 guest on a FreeBSD 7 host
> only gets proper timing after setting hint.apic.0.disabled=1 via the
> loader.  (as can be verified by `vmstat -i' and `time sleep 2' in an
> installed guest or via the fixit->cdrom/dvd shell on a FreeBSD livefs
> or dvd1 iso.)
> 
>  b) qemu running on FreeBSD 8 hosts (and most likely head) has the
> additional problem of running its timers only at HZ/2 when using
> setitimer(2) (called `-clock unix' in qemu), as seen below.  (as also

this problem in 8.x is caused by the bug i described here yesterday:

http://lists.freebsd.org/pipermail/freebsd-current/2009-September/011393.html

In qeumu, the setitimer call (in file vl.c) has a timeout of 1 tick
which maps to callout_reset(..., 1, ...) and because (due to the bug)
8.x processes callouts 1 tick late, this effectively halves the clock rate.

> seen below, timer_settime(2) aka `-clock dynticks' in qemu behaves
> even worse, but that is similarly true on FreeBSD 7 which is why
> I removed the patch that enabled that from our qemu port(s) a few
> days ago.)  And the only reason FreeBSD 8 guests are usually less
> affected by these problems is they now reduce their HZ to 100 when
> they detect being run in a VM.  (which makes sense for other reasons
> as well, don't get me wrong...  but of course doesn't help when the
> host is running with HZ=100 too.)

cheers
luigi
From sam at errno.com  Thu Sep 10 03:44:21 2009
From: sam at errno.com (Sam Leffler)
Date: Thu Sep 10 03:44:49 2009
Subject: wpa_supplicant not found AP without SSID in beacon packet
In-Reply-To: <4AA77E4B.5060006@yandex.ru>
References: <4AA41025.5080908@yandex.ru> <4AA44B53.8060702@errno.com>
	<4AA77E4B.5060006@yandex.ru>
Message-ID: <4AA87613.9040600@errno.com>

Borodin Oleg wrote:
> Sam Leffler ?????:
>> Borodin Oleg wrote:
>>>
>>> Hi!
>>>
>>> wpa_supplicant "not found" AP without SSID in beacon packets. With same
>>> device and configuration, but FreeBSD7.2 - work without problems.
>>>
>>>
>>
>> You seem to have disabled scan_ssid in your wpa_supplicant.conf file. 
>> It appears this causes wpa_supplicant to not supply the ssid when 
>> scanning so the net80211 layer never sends directed ProbeRequest 
>> frames and then ap does not respond.  Try enabling scan_ssid for WNET1 
>> and verify the directed probe request frames are sent.
>>
>>     Sam
>> _______________________________________________
>>
> Of course, I tried to turn on and off scan_ssid. No results.

If you don't show what you do then I cannot tell.  You don't include the 
wlan debug msgs that show the directed ProbeRequest frames so I cannot 
be sure they are going out.  If they are not sent then the ap will not 
respond.  If you set scan_ssid and you're not seeing the ProbeRequest 
frames then you'll need to figure out why.

> I do not know much logic WiFI, perhaps the problem with disassembly 
> beacon packet of access point?
> 
> Or, more likely to parse the answer to the AP on ProbeRequest from FBSD?
> 
> What is?...
> wlan0: [00:23:5e:75:f7:c2] discard unhandled information element, id 
> 133, len 30

This just means the beacon frame included an IE that was not handled. 
You appear to have to have enabled "elemid" debug msgs.

	Sam
From sweetnavelorange at gmail.com  Thu Sep 10 04:37:15 2009
From: sweetnavelorange at gmail.com (James Butler)
Date: Thu Sep 10 04:37:48 2009
Subject: Fwd: Can't boot 8.0-BETA4 from USB stick
In-Reply-To: <200909091631.01446.hselasky@c2i.net>
References: <f0dd9eb90909080402m27558850g6aaa2a5e4c477758@mail.gmail.com>
	<f0dd9eb90909081444pa5cdbf2jd9ee8573c3d4594@mail.gmail.com>
	<f0dd9eb90909081445i4e286e6apb3ad84691c0ef2d0@mail.gmail.com>
	<200909091631.01446.hselasky@c2i.net>
Message-ID: <f0dd9eb90909092137o25d00f3l8bfba581a9d1aab8@mail.gmail.com>

2009/9/10 Hans Petter Selasky <hselasky@c2i.net>:
> On Tuesday 08 September 2009 23:45:00 James Butler wrote:
>> I have tried on all the ports at the back of the box, but I just
>> remembered there's another at the front which I will try this evening.
>> What do you mean by "dummy USB device"? Just having something else
>> plugged in at boot? I will also try another USB drive tonight.
>
> Yes.
>

OK, I tried all the available ports and various combinations of flash
drives, all with the same result. I sometimes get this message from
one drive:

probe0:umass-sim0:0:0:0): TEST UNIT READY. CDB: 0 0 0 0 0 0
probe0:umass-sim0:0:0:0): CAM Status: SCSI Status Error
probe0:umass-sim0:0:0:0): SCS Status: Check Condition
probe0:umass-sim0:0:0:0): UNIT ATTENTION asc:28,0
probe0:umass-sim0:0:0:0): Not ready to ready change, medium may have changed
probe0:umass-sim0:0:0:0): Retrying Command (per Sense Data)

Is there anything else worth trying?

Thanks,
James
From hselasky at c2i.net  Thu Sep 10 07:10:43 2009
From: hselasky at c2i.net (Hans Petter Selasky)
Date: Thu Sep 10 07:10:49 2009
Subject: Fwd: Can't boot 8.0-BETA4 from USB stick
In-Reply-To: <f0dd9eb90909092137o25d00f3l8bfba581a9d1aab8@mail.gmail.com>
References: <f0dd9eb90909080402m27558850g6aaa2a5e4c477758@mail.gmail.com>
	<200909091631.01446.hselasky@c2i.net>
	<f0dd9eb90909092137o25d00f3l8bfba581a9d1aab8@mail.gmail.com>
Message-ID: <200909100911.10237.hselasky@c2i.net>

On Thursday 10 September 2009 06:37:13 James Butler wrote:
> Is there anything else worth trying?

Another brand of memory sticks?

--HPS
From nkoch at demig.de  Thu Sep 10 07:45:34 2009
From: nkoch at demig.de (Norbert Koch)
Date: Thu Sep 10 07:45:40 2009
Subject: lock order reversal etc.
In-Reply-To: <200909091507.32600.jhb@freebsd.org>
References: <4AA7D4BA.40002@demig.de> <200909091507.32600.jhb@freebsd.org>
Message-ID: <4AA8AE8D.7080307@demig.de>

John Baldwin schrieb:
> Try this patch for this one:
>
> Index: daemon_saver.c
> ===================================================================
> --- daemon_saver.c	(revision 196974)
> +++ daemon_saver.c	(working copy)
> @@ -351,11 +351,23 @@
>  static int
>  daemon_init(video_adapter_t *adp)
>  {
> +	size_t hostlen;
>  
>  	mtx_lock(&prison0.pr_mtx);
> -	messagelen = strlen(prison0.pr_hostname) + 3 + strlen(ostype) + 1 + 
> -	    strlen(osrelease);
> -	message = malloc(messagelen + 1, M_DEVBUF, M_WAITOK);
> +	for (;;) {
> +		hostlen = strlen(prison0.pr_hostname);
> +		mtx_unlock(&prison0.pr_mtx);
> +	
> +		messagelen = hostlen + 3 + strlen(ostype) + 1 +
> +		    strlen(osrelease);
> +		message = malloc(messagelen + 1, M_DEVBUF, M_WAITOK);
> +		mtx_lock(&prison0.pr_mtx);
> +		if (hostlen < strlen(prison0.pr_hostname)) {
> +			free(message, M_DEVBUF);
> +			continue;
> +		}
> +		break;
> +	}
>  	sprintf(message, "%s - %s %s", prison0.pr_hostname, ostype, osrelease);
>  	mtx_unlock(&prison0.pr_mtx);
>  	blanked = 0;
>   


That works for me. Thank you.
From jh at saunalahti.fi  Thu Sep 10 09:13:36 2009
From: jh at saunalahti.fi (Jaakko Heinonen)
Date: Thu Sep 10 09:13:43 2009
Subject: 8.0-BETA4 panic: ffs_sync: rofs mod
In-Reply-To: <200909090902.34055.mel.flynn+fbsd.current@mailing.thruhere.net>
References: <20090908202553.GA1368@mr-happy.com>
	<20090908235731.GG1539@garage.freebsd.pl>
	<20090909005504.GA12660@mr-happy.com>
	<200909090902.34055.mel.flynn+fbsd.current@mailing.thruhere.net>
Message-ID: <20090910091329.GA2726@a91-153-125-115.elisa-laajakaista.fi>

On 2009-09-09, Mel Flynn wrote:
> This problem has also been seen on -questions [1] and I forgot to follow
> up after time issues. According to the poster it's easy to reproduce:
> - have a mountpoint in /etc/fstab with ro options
> - unmount the mountpoint
> - remount using -o rw

This has been also reported as PR kern/133614. I have tried to reproduce
the problem earlier but I didn't succeed until now. Here's how to
reproduce it:

1. Have mountd(8) running
2. # mdconfig -a -t vnode -f ufsimg
3. # mount -o ro,rw /dev/md0 /mnt
4. # touch /mnt/foo && sync

This is what's going on:

Initial nmount() is done with "ro" and "rw" options. The mount point
will have "ro", "rw" and "noro" string mount options after nmount().
MNT_RDONLY flag is not set.

Then mountd(8) calls nmount() with "update" and "export" string options.
This results FFS code to re-mount the file system as read-only because
the "ro" string option is active for the mount point. ffs_mount() sets
MNT_RDONLY and FFS fs_ronly flags. MNT_RDONLY gets later cleared in
vfs_domount() because vfs_export() fails with ENOENT but the fs_ronly
flag stays enabled.

The most obvious problem seems to be that both "ro" and "rw" options are
allowed to enter to mount point options concurrently.

I don't have yet a fix to propose.

-- 
Jaakko
From jamesbrandongooch at gmail.com  Thu Sep 10 14:09:55 2009
From: jamesbrandongooch at gmail.com (Brandon Gooch)
Date: Thu Sep 10 14:10:03 2009
Subject: regression in atkbd?
In-Reply-To: <25cb30907080133l656fb10s6221607f00b3d193@mail.gmail.com>
References: <25cb30907080133l656fb10s6221607f00b3d193@mail.gmail.com>
Message-ID: <179b97fb0909100709t33d372dfre14d00e93a935bcb@mail.gmail.com>

On Wed, Jul 8, 2009 at 3:33 AM, Kevin Foo<chflags@gmail.com> wrote:
> Hi hackers,
>
> Did anyone experience issue with atkbd on 8.0? I encountered issue with
> keyboard and touchpad on HP presario V3400 when trying to upgrade from
> 7.2-RELEASE to 8.0 prior to and on BETA1.The keyboard and touchpad are
> working fine on 7.2. On 8.0 prior to BETA1, I managed to obtain dmesg via
> ssh despite having a non-operational keyboard. The laptop was totally
> inaccessible on 8.0 BETA1 as it freezed after the line atkbdc0. No
> information could be obtained.
>
> Any ideas? Thanks.
>
> /boot/device.hints (default, no changes made)
> hint.atkbdc.0.at="isa"
> hint.atkbdc.0.port="0x060"
> hint.atkbd.0.at="atkbdc"
> hint.atkbd.0.irq="1"
> hint.psm.0.at="atkbdc"
> hint.psm.0.irq="12"
>
> 1) FreeBSD 8.0-BETA1 amd64 as of today with GENERIC kernel:-
> <---snip---<
> atkbdc0: <Keyboard controller (i8042)> port 0x60,0x64 irq 1 on acpi0
> system hangs......
>
>
> 2) FreeBSD 8.0-CURRENT amd64 prior to BETA1 custom kernel without
> debug/invariant/witness:-
> <---snip---<
> atkbdc0: <Keyboard controller (i8042)> port 0x60,0x64 irq 1 on acpi0
> atkbd0: <AT Keyboard> irq 1 on atkbdc0
> atkbd: the current kbd controller command byte 0047
> atkbd: unable to set the command byte.
> kbd0 at atkbd0
> kbd0: atkbd0, generic (0), config:0x0, flags:0x3d0000
> ioapic0: routing intpin 1 (ISA IRQ 1) to lapic 0 vector 55
> atkbd0: [GIANT-LOCKED]
> atkbd0: [ITHREAD]
> psm0: unable to allocate IRQ
> psmcpnp0: <PS/2 mouse port> irq 12 on acpi0
> psm0: current command byte:0047
> psm0: unable to set the command byte.
> <---snip---<
> Full verbosed dmesg at http://ms.shit.la/FreeBSD/dmesg.8.txt
>
>
> 3) FreeBSD 7.2-RELEASE-p2 amd64:-
> <---snip---<
> atkbdc0: <Keyboard controller (i8042)> port 0x60,0x64 irq 1 on acpi0
> atkbd0: <AT Keyboard> irq 1 on atkbdc0
> atkbd: the current kbd controller command byte 0047
> atkbd: keyboard ID 0x41ab (2)
> kbd0 at atkbd0
> kbd0: atkbd0, AT 101/102 (2), config:0x0, flags:0x3d0000
> ioapic0: routing intpin 1 (ISA IRQ 1) to vector 57
> atkbd0: [GIANT-LOCKED]
> atkbd0: [ITHREAD]
> psm0: unable to allocate IRQ
> psmcpnp0: <PS/2 mouse port> irq 12 on acpi0
> psm0: current command byte:0047
> psm0: <PS/2 Mouse> irq 12 on atkbdc0
> ioapic0: routing intpin 12 (ISA IRQ 12) to vector 58
> psm0: [GIANT-LOCKED]
> psm0: [ITHREAD]
> psm0: model IntelliMouse, device ID 3-00, 3 buttons
> psm0: config:00000000, flags:00000008, packet size:4
> psm0: syncmask:08, syncbits:00
> <---snip---<
> Full verbosed dmesg at http://ms.shit.la/FreeBSD/dmesg.7.txt
>
> --
> Regards
> Kevin Foo
> _______________________________________________
> 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"
>

What does your /boot/loader.conf look like?

I had a similar issue when:

1. booting GENERIC kernel but without debugging and WITNESS compiled in

and

2. my /boot/loader.conf contained the leftover entry 'ukbd_load="YES"'
from when I was using my custom, modular kernel

If either one of those or both was not true, I was able to boot as
usual. Strange. I never investigated any further...

-Brandon
From luckrill at gmail.com  Thu Sep 10 12:48:02 2009
From: luckrill at gmail.com (Rill)
Date: Thu Sep 10 15:12:40 2009
Subject: 8.0-BETA4 bug
Message-ID: <c67161190909100547k24cb86b3tc27d477930080dc6@mail.gmail.com>

today meet two bugs:

1, Install gnome2 filed from packages

I install freebsd with 8.0-BETA4-i386-dvd1.iso
Then I install kde4 and gnome2 from packages.
My step is:
First: I install kde4 from packages, It's succeed.
Second: I install gnome2 from packages, It's failed and meet following message:

screensaver-gnome-hacks-5.08_1
Loading of dependent package xscreensaver-gnome-hacks-5.08_1 failed
Loading of dependent package gnome-screensaver-2.26.1_1 failed

But, if I install gnome2 first, then install kde4, this time all will
be succeed.
This bug I have also meet on FreeBSD7.2 and FreeBSD8.0-BETA.

2, compile /usr/ports/textproc/docbook-utils filed:
the following is bug message:
jade:../../doc/refentry/jw.sgml:79:88:E: element "SBR" undefined
jade:../../doc/refentry/jw.sgml:81:25:E: element "GROUP" undefined
jade:../../doc/refentry/jw.sgml:82:12:E: element "ARG" undefined
jade:../../doc/refentry/jw.sgml:82:20:E: element "OPTION" undefined
jade:I: maximum number of errors (200) reached; change with -E option
gmake[2]: *** [api.html] Error 1
gmake[2]: Leaving directory
`/usr/ports/textproc/docbook-utils/work/docbook-utils-0.6.14/doc/HTML'
gmake[1]: *** [all-recursive] Error 1
gmake[1]: Leaving directory
`/usr/ports/textproc/docbook-utils/work/docbook-utils-0.6.14/doc'
gmake: *** [all-recursive] Error 1
*** Error code 1

Stop in /usr/ports/textproc/docbook-utils.

My system is: WinXP + VMware6.0 + FreeBSD8.0-BETA4

-- 
jiang zhixiang
From nox at jelal.kn-bremen.de  Thu Sep 10 17:50:19 2009
From: nox at jelal.kn-bremen.de (Juergen Lock)
Date: Thu Sep 10 17:50:32 2009
Subject: FreeBSD timing issues and qemu (was: Re: [Qemu-devel] Re:
 Breakage with local APIC routing)
In-Reply-To: <20090909204616.GB93761@onelab2.iet.unipi.it>
References: <52d4a3890908250321u746e5757u136030bcbc19208d@mail.gmail.com>
	<4A93BF0C.8040601@web.de>
	<20090826221001.GA1070@triton8.kn-bremen.de>
	<4A96C8D9.6070804@web.de>
	<20090829211848.GA59305@triton8.kn-bremen.de>
	<4A9B800F.1040209@web.de>
	<20090831212723.GA32448@triton8.kn-bremen.de>
	<20090901201248.GA60123@triton8.kn-bremen.de>
	<20090907205955.GA91866@triton8.kn-bremen.de>
	<20090909204616.GB93761@onelab2.iet.unipi.it>
Message-ID: <20090910174640.GA30706@triton8.kn-bremen.de>

On Wed, Sep 09, 2009 at 10:46:16PM +0200, Luigi Rizzo wrote:
> On Mon, Sep 07, 2009 at 10:59:55PM +0200, Juergen Lock wrote:
> > [I'm copying freebsd-current@FreeBSD.org because ppl there might know
> > more about this...]
> > 
> >  qemu on FreeBSD hosts used to be able to run a (FreeBSD at least) guest
> > with the same HZ as the host (like, 1000) with (mostly) proper timing
> > once, but no longer. :(  It seems there are two problems involved:
> > 
> >  a) use of apic seems to cause the clock irq rate to be doubled to 2 * HZ
> > (can anyone explain why?), i.e. a FreeBSD 7 guest on a FreeBSD 7 host
> > only gets proper timing after setting hint.apic.0.disabled=1 via the
> > loader.  (as can be verified by `vmstat -i' and `time sleep 2' in an
> > installed guest or via the fixit->cdrom/dvd shell on a FreeBSD livefs
> > or dvd1 iso.)
> > 
> >  b) qemu running on FreeBSD 8 hosts (and most likely head) has the
> > additional problem of running its timers only at HZ/2 when using
> > setitimer(2) (called `-clock unix' in qemu), as seen below.  (as also
> 
> this problem in 8.x is caused by the bug i described here yesterday:
> 
> http://lists.freebsd.org/pipermail/freebsd-current/2009-September/011393.html
> 
> In qeumu, the setitimer call (in file vl.c) has a timeout of 1 tick
> which maps to callout_reset(..., 1, ...) and because (due to the bug)
> 8.x processes callouts 1 tick late, this effectively halves the clock rate.
> 
Thanx for the pointer!

 The proposed patch in that post didn't make a different here tho,
guest still sees only half host HZ clock irq rate. (i.e. ~500 Hz.)

 Here is the patch I used, to make sure I patched what you meant...

Index: sys/kern/kern_timeout.c
@@ -323,7 +323,7 @@ softclock(void *arg)
 	steps = 0;
 	cc = (struct callout_cpu *)arg;
 	CC_LOCK(cc);
-	while (cc->cc_softticks != ticks) {
+	while (cc->cc_softticks-1 != ticks) {
 		/*
 		 * cc_softticks may be modified by hard clock, so cache
 		 * it while we work on a given bucket.

> > seen below, timer_settime(2) aka `-clock dynticks' in qemu behaves
> > even worse, but that is similarly true on FreeBSD 7 which is why
> > I removed the patch that enabled that from our qemu port(s) a few
> > days ago.)  And the only reason FreeBSD 8 guests are usually less
> > affected by these problems is they now reduce their HZ to 100 when
> > they detect being run in a VM.  (which makes sense for other reasons
> > as well, don't get me wrong...  but of course doesn't help when the
> > host is running with HZ=100 too.)
> 
> cheers
> luigi

 Cheers,
	Juergen
From randi at freebsd.org  Thu Sep 10 17:50:22 2009
From: randi at freebsd.org (Randi Harper)
Date: Thu Sep 10 17:50:33 2009
Subject: Fwd: Can't boot 8.0-BETA4 from USB stick
In-Reply-To: <f0dd9eb90909092137o25d00f3l8bfba581a9d1aab8@mail.gmail.com>
References: <f0dd9eb90909080402m27558850g6aaa2a5e4c477758@mail.gmail.com>
	<f0dd9eb90909081444pa5cdbf2jd9ee8573c3d4594@mail.gmail.com>
	<f0dd9eb90909081445i4e286e6apb3ad84691c0ef2d0@mail.gmail.com>
	<200909091631.01446.hselasky@c2i.net>
	<f0dd9eb90909092137o25d00f3l8bfba581a9d1aab8@mail.gmail.com>
Message-ID: <e277d6c80909101050v4c1b3774q357e61dc817eb4fe@mail.gmail.com>

On Wed, Sep 9, 2009 at 9:37 PM, James Butler <sweetnavelorange@gmail.com>wrote:

> 2009/9/10 Hans Petter Selasky <hselasky@c2i.net>:
> > On Tuesday 08 September 2009 23:45:00 James Butler wrote:
> >> I have tried on all the ports at the back of the box, but I just
> >> remembered there's another at the front which I will try this evening.
> >> What do you mean by "dummy USB device"? Just having something else
> >> plugged in at boot? I will also try another USB drive tonight.
> >
> > Yes.
> >
>
> OK, I tried all the available ports and various combinations of flash
> drives, all with the same result. I sometimes get this message from
> one drive:
>
> probe0:umass-sim0:0:0:0): TEST UNIT READY. CDB: 0 0 0 0 0 0
> probe0:umass-sim0:0:0:0): CAM Status: SCSI Status Error
> probe0:umass-sim0:0:0:0): SCS Status: Check Condition
> probe0:umass-sim0:0:0:0): UNIT ATTENTION asc:28,0
> probe0:umass-sim0:0:0:0): Not ready to ready change, medium may have
> changed
> probe0:umass-sim0:0:0:0): Retrying Command (per Sense Data)
>
> Is there anything else worth trying?
>
> Thanks,
> James
> _______________________________________________
> 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"
>

It's worth noting that some USB flash drives (particularly old or
low-quality ones) take longer to detect than others, as was found with
sysinstall/USB installs. I don't really know of a way around this other than
using a different USB flash drive.

-- randi
From rizzo at iet.unipi.it  Thu Sep 10 19:02:01 2009
From: rizzo at iet.unipi.it (Luigi Rizzo)
Date: Thu Sep 10 19:02:10 2009
Subject: FreeBSD timing issues and qemu (was: Re: [Qemu-devel] Re:
	Breakage with local APIC routing)
In-Reply-To: <20090910174640.GA30706@triton8.kn-bremen.de>
References: <4A93BF0C.8040601@web.de>
	<20090826221001.GA1070@triton8.kn-bremen.de>
	<4A96C8D9.6070804@web.de>
	<20090829211848.GA59305@triton8.kn-bremen.de>
	<4A9B800F.1040209@web.de>
	<20090831212723.GA32448@triton8.kn-bremen.de>
	<20090901201248.GA60123@triton8.kn-bremen.de>
	<20090907205955.GA91866@triton8.kn-bremen.de>
	<20090909204616.GB93761@onelab2.iet.unipi.it>
	<20090910174640.GA30706@triton8.kn-bremen.de>
Message-ID: <20090910190800.GA14191@onelab2.iet.unipi.it>

On Thu, Sep 10, 2009 at 07:46:40PM +0200, Juergen Lock wrote:
> On Wed, Sep 09, 2009 at 10:46:16PM +0200, Luigi Rizzo wrote:
> > On Mon, Sep 07, 2009 at 10:59:55PM +0200, Juergen Lock wrote:
> > > [I'm copying freebsd-current@FreeBSD.org because ppl there might know
> > > more about this...]
> > > 
> > >  qemu on FreeBSD hosts used to be able to run a (FreeBSD at least) guest
> > > with the same HZ as the host (like, 1000) with (mostly) proper timing
> > > once, but no longer. :(  It seems there are two problems involved:
> > > 
> > >  a) use of apic seems to cause the clock irq rate to be doubled to 2 * HZ
> > > (can anyone explain why?), i.e. a FreeBSD 7 guest on a FreeBSD 7 host
> > > only gets proper timing after setting hint.apic.0.disabled=1 via the
> > > loader.  (as can be verified by `vmstat -i' and `time sleep 2' in an
> > > installed guest or via the fixit->cdrom/dvd shell on a FreeBSD livefs
> > > or dvd1 iso.)
> > > 
> > >  b) qemu running on FreeBSD 8 hosts (and most likely head) has the
> > > additional problem of running its timers only at HZ/2 when using
> > > setitimer(2) (called `-clock unix' in qemu), as seen below.  (as also
> > 
> > this problem in 8.x is caused by the bug i described here yesterday:
> > 
> > http://lists.freebsd.org/pipermail/freebsd-current/2009-September/011393.html
> > 
> > In qeumu, the setitimer call (in file vl.c) has a timeout of 1 tick
> > which maps to callout_reset(..., 1, ...) and because (due to the bug)
> > 8.x processes callouts 1 tick late, this effectively halves the clock rate.
> > 
> Thanx for the pointer!
> 
>  The proposed patch in that post didn't make a different here tho,
> guest still sees only half host HZ clock irq rate. (i.e. ~500 Hz.)
> 
>  Here is the patch I used, to make sure I patched what you meant...
> 
> Index: sys/kern/kern_timeout.c
> @@ -323,7 +323,7 @@ softclock(void *arg)
>  	steps = 0;
>  	cc = (struct callout_cpu *)arg;
>  	CC_LOCK(cc);
> -	while (cc->cc_softticks != ticks) {
> +	while (cc->cc_softticks-1 != ticks) {
>  		/*
>  		 * cc_softticks may be modified by hard clock, so cache
>  		 * it while we work on a given bucket.
> 

as mentioned in the followup message in that thread,
you also need this change in callout_tick()

        mtx_lock_spin_flags(&cc->cc_lock, MTX_QUIET);
     -  for (; (cc->cc_softticks - ticks) < 0; cc->cc_softticks++) {
     +  for (; (cc->cc_softticks - ticks) <= 0; cc->cc_softticks++) {
                bucket = cc->cc_softticks & callwheelmask;

cheers
luigi
From nox at jelal.kn-bremen.de  Thu Sep 10 20:45:48 2009
From: nox at jelal.kn-bremen.de (Juergen Lock)
Date: Thu Sep 10 20:45:54 2009
Subject: FreeBSD timing issues and qemu (was: Re: [Qemu-devel] Re:
 Breakage with local APIC routing)
In-Reply-To: <20090910190800.GA14191@onelab2.iet.unipi.it>
References: <20090826221001.GA1070@triton8.kn-bremen.de>
	<4A96C8D9.6070804@web.de>
	<20090829211848.GA59305@triton8.kn-bremen.de>
	<4A9B800F.1040209@web.de>
	<20090831212723.GA32448@triton8.kn-bremen.de>
	<20090901201248.GA60123@triton8.kn-bremen.de>
	<20090907205955.GA91866@triton8.kn-bremen.de>
	<20090909204616.GB93761@onelab2.iet.unipi.it>
	<20090910174640.GA30706@triton8.kn-bremen.de>
	<20090910190800.GA14191@onelab2.iet.unipi.it>
Message-ID: <20090910204431.GA2102@triton8.kn-bremen.de>

On Thu, Sep 10, 2009 at 09:08:00PM +0200, Luigi Rizzo wrote:
> On Thu, Sep 10, 2009 at 07:46:40PM +0200, Juergen Lock wrote:
> > On Wed, Sep 09, 2009 at 10:46:16PM +0200, Luigi Rizzo wrote:
> > > On Mon, Sep 07, 2009 at 10:59:55PM +0200, Juergen Lock wrote:
> > > > [I'm copying freebsd-current@FreeBSD.org because ppl there might know
> > > > more about this...]
> > > > 
> > > >  qemu on FreeBSD hosts used to be able to run a (FreeBSD at least) guest
> > > > with the same HZ as the host (like, 1000) with (mostly) proper timing
> > > > once, but no longer. :(  It seems there are two problems involved:
> > > > 
> > > >  a) use of apic seems to cause the clock irq rate to be doubled to 2 * HZ
> > > > (can anyone explain why?), i.e. a FreeBSD 7 guest on a FreeBSD 7 host
> > > > only gets proper timing after setting hint.apic.0.disabled=1 via the
> > > > loader.  (as can be verified by `vmstat -i' and `time sleep 2' in an
> > > > installed guest or via the fixit->cdrom/dvd shell on a FreeBSD livefs
> > > > or dvd1 iso.)
> > > > 
> > > >  b) qemu running on FreeBSD 8 hosts (and most likely head) has the
> > > > additional problem of running its timers only at HZ/2 when using
> > > > setitimer(2) (called `-clock unix' in qemu), as seen below.  (as also
> > > 
> > > this problem in 8.x is caused by the bug i described here yesterday:
> > > 
> > > http://lists.freebsd.org/pipermail/freebsd-current/2009-September/011393.html
> > > 
> > > In qeumu, the setitimer call (in file vl.c) has a timeout of 1 tick
> > > which maps to callout_reset(..., 1, ...) and because (due to the bug)
> > > 8.x processes callouts 1 tick late, this effectively halves the clock rate.
> > > 
> > Thanx for the pointer!
> > 
> >  The proposed patch in that post didn't make a different here tho,
> > guest still sees only half host HZ clock irq rate. (i.e. ~500 Hz.)
> > 
> >  Here is the patch I used, to make sure I patched what you meant...
> > 
> > Index: sys/kern/kern_timeout.c
> > @@ -323,7 +323,7 @@ softclock(void *arg)
> >  	steps = 0;
> >  	cc = (struct callout_cpu *)arg;
> >  	CC_LOCK(cc);
> > -	while (cc->cc_softticks != ticks) {
> > +	while (cc->cc_softticks-1 != ticks) {
> >  		/*
> >  		 * cc_softticks may be modified by hard clock, so cache
> >  		 * it while we work on a given bucket.
> > 
> 
> as mentioned in the followup message in that thread,
> you also need this change in callout_tick()
> 
>         mtx_lock_spin_flags(&cc->cc_lock, MTX_QUIET);
>      -  for (; (cc->cc_softticks - ticks) < 0; cc->cc_softticks++) {
>      +  for (; (cc->cc_softticks - ticks) <= 0; cc->cc_softticks++) {
>                 bucket = cc->cc_softticks & callwheelmask;
> 
Ah I missed that, now guest clock irqs are back to HZ indeed.

 Thanx, :)
	Juergen
From tinderbox at freebsd.org  Thu Sep 10 20:58:22 2009
From: tinderbox at freebsd.org (FreeBSD Tinderbox)
Date: Thu Sep 10 20:58:32 2009
Subject: [head tinderbox] failure on i386/pc98
Message-ID: <200909102058.n8AKwLeT010348@freebsd-current.sentex.ca>

TB --- 2009-09-10 19:45:00 - tinderbox 2.6 running on freebsd-current.sentex.ca
TB --- 2009-09-10 19:45:00 - starting HEAD tinderbox run for i386/pc98
TB --- 2009-09-10 19:45:00 - cleaning the object tree
TB --- 2009-09-10 19:45:42 - cvsupping the source tree
TB --- 2009-09-10 19:45:42 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/i386/pc98/supfile
TB --- 2009-09-10 19:46:55 - building world
TB --- 2009-09-10 19:46:55 - MAKEOBJDIRPREFIX=/obj
TB --- 2009-09-10 19:46:55 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2009-09-10 19:46:55 - TARGET=pc98
TB --- 2009-09-10 19:46:55 - TARGET_ARCH=i386
TB --- 2009-09-10 19:46:55 - TZ=UTC
TB --- 2009-09-10 19:46:55 - __MAKE_CONF=/dev/null
TB --- 2009-09-10 19:46:55 - cd /src
TB --- 2009-09-10 19:46:55 - /usr/bin/make -B buildworld
>>> World build started on Thu Sep 10 19:46:56 UTC 2009
>>> 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 Thu Sep 10 20:53:02 UTC 2009
TB --- 2009-09-10 20:53:02 - generating LINT kernel config
TB --- 2009-09-10 20:53:02 - cd /src/sys/pc98/conf
TB --- 2009-09-10 20:53:02 - /usr/bin/make -B LINT
TB --- 2009-09-10 20:53:02 - building LINT kernel
TB --- 2009-09-10 20:53:02 - MAKEOBJDIRPREFIX=/obj
TB --- 2009-09-10 20:53:02 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2009-09-10 20:53:02 - TARGET=pc98
TB --- 2009-09-10 20:53:02 - TARGET_ARCH=i386
TB --- 2009-09-10 20:53:02 - TZ=UTC
TB --- 2009-09-10 20:53:02 - __MAKE_CONF=/dev/null
TB --- 2009-09-10 20:53:02 - cd /src
TB --- 2009-09-10 20:53:02 - /usr/bin/make -B buildkernel KERNCONF=LINT
>>> Kernel build for LINT started on Thu Sep 10 20:53:02 UTC 2009
>>> 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 -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-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/ed/if_ed_pccard.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 -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-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/ed/if_ed_pci.c
awk -f /src/sys/tools/makeobjops.awk /src/sys/dev/eisa/eisa_if.m -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 -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-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue eisa_if.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 -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-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/e1000/if_em.c -I/src/sys/dev/e1000
cc1: warnings being treated as errors
/src/sys/dev/e1000/if_em.c: In function 'em_mq_start_locked':
/src/sys/dev/e1000/if_em.c:1037: warning: suggest parentheses around assignment used as truth value
/src/sys/dev/e1000/if_em.c:1067: warning: suggest parentheses around assignment used as truth value
*** Error code 1

Stop in /obj/pc98/src/sys/LINT.
*** Error code 1

Stop in /src.
*** Error code 1

Stop in /src.
TB --- 2009-09-10 20:58:21 - WARNING: /usr/bin/make returned exit code  1 
TB --- 2009-09-10 20:58:21 - ERROR: failed to build lint kernel
TB --- 2009-09-10 20:58:21 - 2844.02 user 469.02 system 4400.22 real


http://tinderbox.des.no/tinderbox-head-HEAD-i386-pc98.full
From tinderbox at freebsd.org  Thu Sep 10 21:05:59 2009
From: tinderbox at freebsd.org (FreeBSD Tinderbox)
Date: Thu Sep 10 21:06:17 2009
Subject: [head tinderbox] failure on i386/i386
Message-ID: <200909102105.n8AL5wNn080259@freebsd-current.sentex.ca>

TB --- 2009-09-10 19:45:00 - tinderbox 2.6 running on freebsd-current.sentex.ca
TB --- 2009-09-10 19:45:00 - starting HEAD tinderbox run for i386/i386
TB --- 2009-09-10 19:45:00 - cleaning the object tree
TB --- 2009-09-10 19:46:00 - cvsupping the source tree
TB --- 2009-09-10 19:46:00 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/i386/i386/supfile
TB --- 2009-09-10 19:51:47 - building world
TB --- 2009-09-10 19:51:47 - MAKEOBJDIRPREFIX=/obj
TB --- 2009-09-10 19:51:47 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2009-09-10 19:51:47 - TARGET=i386
TB --- 2009-09-10 19:51:47 - TARGET_ARCH=i386
TB --- 2009-09-10 19:51:47 - TZ=UTC
TB --- 2009-09-10 19:51:47 - __MAKE_CONF=/dev/null
TB --- 2009-09-10 19:51:47 - cd /src
TB --- 2009-09-10 19:51:47 - /usr/bin/make -B buildworld
>>> World build started on Thu Sep 10 19:51:48 UTC 2009
>>> 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 Thu Sep 10 20:59:20 UTC 2009
TB --- 2009-09-10 20:59:20 - generating LINT kernel config
TB --- 2009-09-10 20:59:20 - cd /src/sys/i386/conf
TB --- 2009-09-10 20:59:20 - /usr/bin/make -B LINT
TB --- 2009-09-10 20:59:20 - building LINT kernel
TB --- 2009-09-10 20:59:20 - MAKEOBJDIRPREFIX=/obj
TB --- 2009-09-10 20:59:20 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2009-09-10 20:59:20 - TARGET=i386
TB --- 2009-09-10 20:59:20 - TARGET_ARCH=i386
TB --- 2009-09-10 20:59:20 - TZ=UTC
TB --- 2009-09-10 20:59:20 - __MAKE_CONF=/dev/null
TB --- 2009-09-10 20:59:20 - cd /src
TB --- 2009-09-10 20:59:20 - /usr/bin/make -B buildkernel KERNCONF=LINT
>>> Kernel build for LINT started on Thu Sep 10 20:59:20 UTC 2009
>>> 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 -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-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/ed/if_ed_pci.c
awk -f /src/sys/tools/makeobjops.awk /src/sys/dev/eisa/eisa_if.m -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 -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-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue eisa_if.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 -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-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/eisa/eisaconf.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 -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-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/e1000/if_em.c -I/src/sys/dev/e1000
cc1: warnings being treated as errors
/src/sys/dev/e1000/if_em.c: In function 'em_mq_start_locked':
/src/sys/dev/e1000/if_em.c:1037: warning: suggest parentheses around assignment used as truth value
/src/sys/dev/e1000/if_em.c:1067: warning: suggest parentheses around assignment used as truth value
*** Error code 1

Stop in /obj/i386/src/sys/LINT.
*** Error code 1

Stop in /src.
*** Error code 1

Stop in /src.
TB --- 2009-09-10 21:05:58 - WARNING: /usr/bin/make returned exit code  1 
TB --- 2009-09-10 21:05:58 - ERROR: failed to build lint kernel
TB --- 2009-09-10 21:05:58 - 2930.05 user 474.92 system 4857.75 real


http://tinderbox.des.no/tinderbox-head-HEAD-i386-i386.full
From daniel at toomuchdata.se  Thu Sep 10 21:26:15 2009
From: daniel at toomuchdata.se (Daniel Eriksson)
Date: Thu Sep 10 21:26:22 2009
Subject: Fwd: Can't boot 8.0-BETA4 from USB stick
In-Reply-To: <200909100911.10237.hselasky@c2i.net>
References: <f0dd9eb90909080402m27558850g6aaa2a5e4c477758@mail.gmail.com>	<200909091631.01446.hselasky@c2i.net>	<f0dd9eb90909092137o25d00f3l8bfba581a9d1aab8@mail.gmail.com>
	<200909100911.10237.hselasky@c2i.net>
Message-ID: <4AA968C6.6000405@toomuchdata.se>

On 2009-09-10 09:11, Hans Petter Selasky wrote:
> Another brand of memory sticks?
I had the same problem trying to boot 8.0-BETA2 from an USB stick. The 
da0 device showed up too late, causing the boot to fail. Manually 
entering the boot device allowed the boot to continue.

/Daniel Eriksson

From tinderbox at freebsd.org  Thu Sep 10 21:33:39 2009
From: tinderbox at freebsd.org (FreeBSD Tinderbox)
Date: Thu Sep 10 21:33:49 2009
Subject: [head tinderbox] failure on amd64/amd64
Message-ID: <200909102133.n8ALXdTj007130@freebsd-current.sentex.ca>

TB --- 2009-09-10 19:45:00 - tinderbox 2.6 running on freebsd-current.sentex.ca
TB --- 2009-09-10 19:45:00 - starting HEAD tinderbox run for amd64/amd64
TB --- 2009-09-10 19:45:00 - cleaning the object tree
TB --- 2009-09-10 19:46:07 - cvsupping the source tree
TB --- 2009-09-10 19:46:07 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/amd64/amd64/supfile
TB --- 2009-09-10 19:51:51 - building world
TB --- 2009-09-10 19:51:51 - MAKEOBJDIRPREFIX=/obj
TB --- 2009-09-10 19:51:51 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2009-09-10 19:51:51 - TARGET=amd64
TB --- 2009-09-10 19:51:51 - TARGET_ARCH=amd64
TB --- 2009-09-10 19:51:51 - TZ=UTC
TB --- 2009-09-10 19:51:51 - __MAKE_CONF=/dev/null
TB --- 2009-09-10 19:51:51 - cd /src
TB --- 2009-09-10 19:51:51 - /usr/bin/make -B buildworld
>>> World build started on Thu Sep 10 19:51:51 UTC 2009
>>> 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 Thu Sep 10 21:27:35 UTC 2009
TB --- 2009-09-10 21:27:35 - generating LINT kernel config
TB --- 2009-09-10 21:27:35 - cd /src/sys/amd64/conf
TB --- 2009-09-10 21:27:35 - /usr/bin/make -B LINT
TB --- 2009-09-10 21:27:36 - building LINT kernel
TB --- 2009-09-10 21:27:36 - MAKEOBJDIRPREFIX=/obj
TB --- 2009-09-10 21:27:36 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2009-09-10 21:27:36 - TARGET=amd64
TB --- 2009-09-10 21:27:36 - TARGET_ARCH=amd64
TB --- 2009-09-10 21:27:36 - TZ=UTC
TB --- 2009-09-10 21:27:36 - __MAKE_CONF=/dev/null
TB --- 2009-09-10 21:27:36 - cd /src
TB --- 2009-09-10 21:27:36 - /usr/bin/make -B buildkernel KERNCONF=LINT
>>> Kernel build for LINT started on Thu Sep 10 21:27:36 UTC 2009
>>> 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 -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 -mcmodel=kernel -mno-red-zone  -mfpmath=387 -mno-sse -mno-sse2 -mno-sse3 -mno-mmx -mno-3dnow  -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/ed/if_ed_pccard.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 -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 -mcmodel=kernel -mno-red-zone  -mfpmath=387 -mno-sse -mno-sse2 -mno-sse3 -mno-mmx -mno-3dnow  -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/ed/if_ed_pci.c
awk -f /src/sys/tools/makeobjops.awk /src/sys/dev/eisa/eisa_if.m -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 -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 -mcmodel=kernel -mno-red-zone  -mfpmath=387 -mno-sse -mno-sse2 -mno-sse3 -mno-mmx -mno-3dnow  -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue eisa_if.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 -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 -mcmodel=kernel -mno-red-zone  -mfpmath=387 -mno-sse -mno-sse2 -mno-sse3 -mno-mmx -mno-3dnow  -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/e1000/if_em.c -I/src/sys/dev/e1000
cc1: warnings being treated as errors
/src/sys/dev/e1000/if_em.c: In function 'em_mq_start_locked':
/src/sys/dev/e1000/if_em.c:1037: warning: suggest parentheses around assignment used as truth value
/src/sys/dev/e1000/if_em.c:1067: warning: suggest parentheses around assignment used as truth value
*** Error code 1

Stop in /obj/src/sys/LINT.
*** Error code 1

Stop in /src.
*** Error code 1

Stop in /src.
TB --- 2009-09-10 21:33:38 - WARNING: /usr/bin/make returned exit code  1 
TB --- 2009-09-10 21:33:38 - ERROR: failed to build lint kernel
TB --- 2009-09-10 21:33:38 - 4089.37 user 694.49 system 6518.01 real


http://tinderbox.des.no/tinderbox-head-HEAD-amd64-amd64.full
From sweetnavelorange at gmail.com  Thu Sep 10 21:48:19 2009
From: sweetnavelorange at gmail.com (James Butler)
Date: Thu Sep 10 21:48:26 2009
Subject: Fwd: Can't boot 8.0-BETA4 from USB stick
In-Reply-To: <200909100911.10237.hselasky@c2i.net>
References: <f0dd9eb90909080402m27558850g6aaa2a5e4c477758@mail.gmail.com>
	<200909091631.01446.hselasky@c2i.net>
	<f0dd9eb90909092137o25d00f3l8bfba581a9d1aab8@mail.gmail.com>
	<200909100911.10237.hselasky@c2i.net>
Message-ID: <f0dd9eb90909101448r5ad0c375r47cc253038aaa5f9@mail.gmail.com>

2009/9/10 Hans Petter Selasky <hselasky@c2i.net>:
> On Thursday 10 September 2009 06:37:13 James Butler wrote:
>> Is there anything else worth trying?
>
> Another brand of memory sticks?

I have only the three different brands that I tried (Toshiba and two
different no-names). Is there really nothing like an adjustable delay
at boot? Perhaps it's time to spend NZD$30 on a CF card and IDE
adapter, but that will be of limited use for troubleshooting or
installation.

-James
From pjd at FreeBSD.org  Thu Sep 10 21:53:00 2009
From: pjd at FreeBSD.org (Pawel Jakub Dawidek)
Date: Thu Sep 10 21:53:22 2009
Subject: Problems with ZFS on AMD64 (and i386 now)
In-Reply-To: <20090909101346.01887a02@sub.han.vpn.gamesnet.de>
References: <a7454e2f0909010624yf652445y855047b83d046cc4@mail.gmail.com>
	<200909011005.18200.jhb@freebsd.org>
	<20090908214402.43009577@sub.han.vpn.gamesnet.de>
	<20090909001942.0affc96c@sub.han.vpn.gamesnet.de>
	<20090909054249.GH1539@garage.freebsd.pl>
	<20090909101346.01887a02@sub.han.vpn.gamesnet.de>
Message-ID: <20090910215254.GD2718@garage.freebsd.pl>

On Wed, Sep 09, 2009 at 10:13:46AM +0200, Tobias Lott wrote:
> 
> 
> On Wed, 9 Sep 2009 07:42:49 +0200
> Pawel Jakub Dawidek <pjd@FreeBSD.org> wrote:
> 
> > On Wed, Sep 09, 2009 at 12:19:42AM +0200, Tobias Lott wrote:
> > > Hey Everyone
> > > 
> > > I've managed to get some Output for this, using BETA2 LiveCD (gonna
> > > try using BETA4 CD Tomorrow).
> > > 
> > > 'zfs import -f poolname' triggered this, Booting kernel.old (BETA3)
> > > and today built BETA4 Kernel Panic mounting zfs Volumes.
> > > Booting single user mode I get output of zfs list and so on but
> > > mounting whatever volume also Panics.
> > 
> > Why -f? Were there a poblem in importing pool?
> > 
> > > Stack output, if there's more you need I'll gladly help
> > > http://i27.tinypic.com/2d78qpd.jpg
> > > http://i31.tinypic.com/oqhv2w.jpg
> > > http://i28.tinypic.com/oktsag.jpg
> > 
> > Could you also provide top part of the backtrace?
> > 
> Oh yeah my bad
> 
> http://i29.tinypic.com/nqwxo2.jpg
> http://i26.tinypic.com/209hanm.jpg

Seems that one of the vdevs is NULL. Could you tell me why you decided
to use -f option for importing the pool?

-- 
Pawel Jakub Dawidek                       http://www.wheel.pl
pjd@FreeBSD.org                           http://www.FreeBSD.org
FreeBSD committer                         Am I Evil? Yes, I Am!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20090910/9d1a2291/attachment.pgp
From randi at freebsd.org  Thu Sep 10 22:07:43 2009
From: randi at freebsd.org (Randi Harper)
Date: Thu Sep 10 22:07:59 2009
Subject: Fwd: Can't boot 8.0-BETA4 from USB stick
In-Reply-To: <f0dd9eb90909101448r5ad0c375r47cc253038aaa5f9@mail.gmail.com>
References: <f0dd9eb90909080402m27558850g6aaa2a5e4c477758@mail.gmail.com>
	<200909091631.01446.hselasky@c2i.net>
	<f0dd9eb90909092137o25d00f3l8bfba581a9d1aab8@mail.gmail.com>
	<200909100911.10237.hselasky@c2i.net>
	<f0dd9eb90909101448r5ad0c375r47cc253038aaa5f9@mail.gmail.com>
Message-ID: <e277d6c80909101505t1932472bo22d41ded69c58dd8@mail.gmail.com>

On Thu, Sep 10, 2009 at 2:48 PM, James Butler <sweetnavelorange@gmail.com>wrote:

> 2009/9/10 Hans Petter Selasky <hselasky@c2i.net>:
> > On Thursday 10 September 2009 06:37:13 James Butler wrote:
> >> Is there anything else worth trying?
> >
> > Another brand of memory sticks?
>
> I have only the three different brands that I tried (Toshiba and two
> different no-names). Is there really nothing like an adjustable delay
> at boot? Perhaps it's time to spend NZD$30 on a CF card and IDE
> adapter, but that will be of limited use for troubleshooting or
> installation.
>
> -James
> _______________________________________________
> 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"
>

I've been asking around about an option to delay before mounting root as
well. I don't know of anything off the top of my head, but it sounds to me
like a bug (or at least a reasonable feature request). Send a PR?

Have you only tried this on the one computer? It seems suspicious that all
the cards are having this problem when I've only heard of two cases of USB
flash-slowness causing problems so far. I'm curious to see if you have the
same problem using that flash disk with a different computer.

-- randi
From tinderbox at freebsd.org  Thu Sep 10 22:10:55 2009
From: tinderbox at freebsd.org (FreeBSD Tinderbox)
Date: Thu Sep 10 22:11:14 2009
Subject: [head tinderbox] failure on ia64/ia64
Message-ID: <200909102210.n8AMAspr066541@freebsd-current.sentex.ca>

TB --- 2009-09-10 20:40:12 - tinderbox 2.6 running on freebsd-current.sentex.ca
TB --- 2009-09-10 20:40:12 - starting HEAD tinderbox run for ia64/ia64
TB --- 2009-09-10 20:40:12 - cleaning the object tree
TB --- 2009-09-10 20:40:38 - cvsupping the source tree
TB --- 2009-09-10 20:40:38 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/ia64/ia64/supfile
TB --- 2009-09-10 20:41:38 - building world
TB --- 2009-09-10 20:41:38 - MAKEOBJDIRPREFIX=/obj
TB --- 2009-09-10 20:41:38 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2009-09-10 20:41:38 - TARGET=ia64
TB --- 2009-09-10 20:41:38 - TARGET_ARCH=ia64
TB --- 2009-09-10 20:41:38 - TZ=UTC
TB --- 2009-09-10 20:41:38 - __MAKE_CONF=/dev/null
TB --- 2009-09-10 20:41:38 - cd /src
TB --- 2009-09-10 20:41:38 - /usr/bin/make -B buildworld
>>> World build started on Thu Sep 10 20:41:39 UTC 2009
>>> 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 Thu Sep 10 22:05:10 UTC 2009
TB --- 2009-09-10 22:05:10 - generating LINT kernel config
TB --- 2009-09-10 22:05:10 - cd /src/sys/ia64/conf
TB --- 2009-09-10 22:05:10 - /usr/bin/make -B LINT
TB --- 2009-09-10 22:05:11 - building LINT kernel
TB --- 2009-09-10 22:05:11 - MAKEOBJDIRPREFIX=/obj
TB --- 2009-09-10 22:05:11 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2009-09-10 22:05:11 - TARGET=ia64
TB --- 2009-09-10 22:05:11 - TARGET_ARCH=ia64
TB --- 2009-09-10 22:05:11 - TZ=UTC
TB --- 2009-09-10 22:05:11 - __MAKE_CONF=/dev/null
TB --- 2009-09-10 22:05:11 - cd /src
TB --- 2009-09-10 22:05:11 - /usr/bin/make -B buildkernel KERNCONF=LINT
>>> Kernel build for LINT started on Thu Sep 10 22:05:11 UTC 2009
>>> 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 -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/dev/dpt/dpt_pci.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 -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/dev/dpt/dpt_scsi.c
awk -f /src/sys/tools/makeobjops.awk /src/sys/dev/eisa/eisa_if.m -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 -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  eisa_if.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 -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/dev/e1000/if_em.c -I/src/sys/dev/e1000
cc1: warnings being treated as errors
/src/sys/dev/e1000/if_em.c: In function 'em_mq_start_locked':
/src/sys/dev/e1000/if_em.c:1037: warning: suggest parentheses around assignment used as truth value
/src/sys/dev/e1000/if_em.c:1067: warning: suggest parentheses around assignment used as truth value
*** Error code 1

Stop in /obj/ia64/src/sys/LINT.
*** Error code 1

Stop in /src.
*** Error code 1

Stop in /src.
TB --- 2009-09-10 22:10:54 - WARNING: /usr/bin/make returned exit code  1 
TB --- 2009-09-10 22:10:54 - ERROR: failed to build lint kernel
TB --- 2009-09-10 22:10:54 - 3921.92 user 489.71 system 5441.45 real


http://tinderbox.des.no/tinderbox-head-HEAD-ia64-ia64.full
From tinderbox at freebsd.org  Thu Sep 10 22:15:51 2009
From: tinderbox at freebsd.org (FreeBSD Tinderbox)
Date: Thu Sep 10 22:16:04 2009
Subject: [head tinderbox] failure on powerpc/powerpc
Message-ID: <200909102215.n8AMFoqF093583@freebsd-current.sentex.ca>

TB --- 2009-09-10 21:05:58 - tinderbox 2.6 running on freebsd-current.sentex.ca
TB --- 2009-09-10 21:05:58 - starting HEAD tinderbox run for powerpc/powerpc
TB --- 2009-09-10 21:05:58 - cleaning the object tree
TB --- 2009-09-10 21:06:07 - cvsupping the source tree
TB --- 2009-09-10 21:06:07 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/powerpc/powerpc/supfile
TB --- 2009-09-10 21:06:40 - building world
TB --- 2009-09-10 21:06:40 - MAKEOBJDIRPREFIX=/obj
TB --- 2009-09-10 21:06:40 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2009-09-10 21:06:40 - TARGET=powerpc
TB --- 2009-09-10 21:06:40 - TARGET_ARCH=powerpc
TB --- 2009-09-10 21:06:40 - TZ=UTC
TB --- 2009-09-10 21:06:40 - __MAKE_CONF=/dev/null
TB --- 2009-09-10 21:06:40 - cd /src
TB --- 2009-09-10 21:06:40 - /usr/bin/make -B buildworld
>>> World build started on Thu Sep 10 21:06:40 UTC 2009
>>> 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 Thu Sep 10 22:12:16 UTC 2009
TB --- 2009-09-10 22:12:16 - generating LINT kernel config
TB --- 2009-09-10 22:12:16 - cd /src/sys/powerpc/conf
TB --- 2009-09-10 22:12:16 - /usr/bin/make -B LINT
TB --- 2009-09-10 22:12:16 - building LINT kernel
TB --- 2009-09-10 22:12:16 - MAKEOBJDIRPREFIX=/obj
TB --- 2009-09-10 22:12:16 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2009-09-10 22:12:16 - TARGET=powerpc
TB --- 2009-09-10 22:12:16 - TARGET_ARCH=powerpc
TB --- 2009-09-10 22:12:16 - TZ=UTC
TB --- 2009-09-10 22:12:16 - __MAKE_CONF=/dev/null
TB --- 2009-09-10 22:12:16 - cd /src
TB --- 2009-09-10 22:12:16 - /usr/bin/make -B buildkernel KERNCONF=LINT
>>> Kernel build for LINT started on Thu Sep 10 22:12:16 UTC 2009
>>> 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 -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 -msoft-float -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -fstack-protector -Werror  /src/sys/dev/dpt/dpt_pci.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 -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 -msoft-float -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -fstack-protector -Werror  /src/sys/dev/dpt/dpt_scsi.c
awk -f /src/sys/tools/makeobjops.awk /src/sys/dev/eisa/eisa_if.m -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 -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 -msoft-float -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -fstack-protector -Werror  eisa_if.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 -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 -msoft-float -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -fstack-protector -Werror  /src/sys/dev/e1000/if_em.c -I/src/sys/dev/e1000
cc1: warnings being treated as errors
/src/sys/dev/e1000/if_em.c: In function 'em_mq_start_locked':
/src/sys/dev/e1000/if_em.c:1037: warning: suggest parentheses around assignment used as truth value
/src/sys/dev/e1000/if_em.c:1067: warning: suggest parentheses around assignment used as truth value
*** Error code 1

Stop in /obj/powerpc/src/sys/LINT.
*** Error code 1

Stop in /src.
*** Error code 1

Stop in /src.
TB --- 2009-09-10 22:15:50 - WARNING: /usr/bin/make returned exit code  1 
TB --- 2009-09-10 22:15:50 - ERROR: failed to build lint kernel
TB --- 2009-09-10 22:15:50 - 2926.18 user 446.68 system 4191.55 real


http://tinderbox.des.no/tinderbox-head-HEAD-powerpc-powerpc.full
From sweetnavelorange at gmail.com  Thu Sep 10 22:22:37 2009
From: sweetnavelorange at gmail.com (James Butler)
Date: Thu Sep 10 22:22:43 2009
Subject: Fwd: Can't boot 8.0-BETA4 from USB stick
In-Reply-To: <e277d6c80909101505t1932472bo22d41ded69c58dd8@mail.gmail.com>
References: <f0dd9eb90909080402m27558850g6aaa2a5e4c477758@mail.gmail.com>
	<200909091631.01446.hselasky@c2i.net>
	<f0dd9eb90909092137o25d00f3l8bfba581a9d1aab8@mail.gmail.com>
	<200909100911.10237.hselasky@c2i.net>
	<f0dd9eb90909101448r5ad0c375r47cc253038aaa5f9@mail.gmail.com>
	<e277d6c80909101505t1932472bo22d41ded69c58dd8@mail.gmail.com>
Message-ID: <f0dd9eb90909101522l2e56f8dardae165976d6c00c0@mail.gmail.com>

2009/9/11 Randi Harper <randi@freebsd.org>:
> On Thu, Sep 10, 2009 at 2:48 PM, James Butler <sweetnavelorange@gmail.com>
> wrote:
>>
>> 2009/9/10 Hans Petter Selasky <hselasky@c2i.net>:
>> > On Thursday 10 September 2009 06:37:13 James Butler wrote:
>> >> Is there anything else worth trying?
>> >
>> > Another brand of memory sticks?
>>
>> I have only the three different brands that I tried (Toshiba and two
>> different no-names). Is there really nothing like an adjustable delay
>> at boot? Perhaps it's time to spend NZD$30 on a CF card and IDE
>> adapter, but that will be of limited use for troubleshooting or
>> installation.
>>
>> -James
>> _______________________________________________
>> 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"
>
> I've been asking around about an option to delay before mounting root as
> well. I don't know of anything off the top of my head, but it sounds to me
> like a bug (or at least a reasonable feature request). Send a PR?

I probably will now, I just wanted to exhaust the existing options. It
seems to me that a "wait for the configured root device to appear"
timeout could be arbitrarily long (eg. 10+ secs) by default without
adversely affecting the normal use case, but I don't claim to know how
the boot process works.

> Have you only tried this on the one computer? It seems suspicious that all
> the cards are having this problem when I've only heard of two cases of USB
> flash-slowness causing problems so far. I'm curious to see if you have the
> same problem using that flash disk with a different computer.

I think I used the same drive to test-install 8.0-BETA1 on my old
Thinkpad X31, which seemed to work OK. This Asus motherboard is a but
useless in other ways; still, 7.2 runs fine.

-James
From tinderbox at freebsd.org  Thu Sep 10 22:36:47 2009
From: tinderbox at freebsd.org (FreeBSD Tinderbox)
Date: Thu Sep 10 22:36:59 2009
Subject: [head tinderbox] failure on sparc64/sparc64
Message-ID: <200909102236.n8AMakN9080233@freebsd-current.sentex.ca>

TB --- 2009-09-10 21:33:39 - tinderbox 2.6 running on freebsd-current.sentex.ca
TB --- 2009-09-10 21:33:39 - starting HEAD tinderbox run for sparc64/sparc64
TB --- 2009-09-10 21:33:39 - cleaning the object tree
TB --- 2009-09-10 21:33:53 - cvsupping the source tree
TB --- 2009-09-10 21:33:53 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/sparc64/sparc64/supfile
TB --- 2009-09-10 21:34:43 - building world
TB --- 2009-09-10 21:34:43 - MAKEOBJDIRPREFIX=/obj
TB --- 2009-09-10 21:34:43 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2009-09-10 21:34:43 - TARGET=sparc64
TB --- 2009-09-10 21:34:43 - TARGET_ARCH=sparc64
TB --- 2009-09-10 21:34:43 - TZ=UTC
TB --- 2009-09-10 21:34:43 - __MAKE_CONF=/dev/null
TB --- 2009-09-10 21:34:43 - cd /src
TB --- 2009-09-10 21:34:43 - /usr/bin/make -B buildworld
>>> World build started on Thu Sep 10 21:34:44 UTC 2009
>>> 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 Thu Sep 10 22:33:12 UTC 2009
TB --- 2009-09-10 22:33:12 - generating LINT kernel config
TB --- 2009-09-10 22:33:12 - cd /src/sys/sparc64/conf
TB --- 2009-09-10 22:33:12 - /usr/bin/make -B LINT
TB --- 2009-09-10 22:33:12 - building LINT kernel
TB --- 2009-09-10 22:33:12 - MAKEOBJDIRPREFIX=/obj
TB --- 2009-09-10 22:33:12 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2009-09-10 22:33:12 - TARGET=sparc64
TB --- 2009-09-10 22:33:12 - TARGET_ARCH=sparc64
TB --- 2009-09-10 22:33:12 - TZ=UTC
TB --- 2009-09-10 22:33:12 - __MAKE_CONF=/dev/null
TB --- 2009-09-10 22:33:12 - cd /src
TB --- 2009-09-10 22:33:12 - /usr/bin/make -B buildkernel KERNCONF=LINT
>>> Kernel build for LINT started on Thu Sep 10 22:33:12 UTC 2009
>>> 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 -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/dev/dpt/dpt_pci.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 -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/dev/dpt/dpt_scsi.c
awk -f /src/sys/tools/makeobjops.awk /src/sys/dev/eisa/eisa_if.m -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 -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  eisa_if.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 -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/dev/e1000/if_em.c -I/src/sys/dev/e1000
cc1: warnings being treated as errors
/src/sys/dev/e1000/if_em.c: In function 'em_mq_start_locked':
/src/sys/dev/e1000/if_em.c:1037: warning: suggest parentheses around assignment used as truth value
/src/sys/dev/e1000/if_em.c:1067: warning: suggest parentheses around assignment used as truth value
*** Error code 1

Stop in /obj/sparc64/src/sys/LINT.
*** Error code 1

Stop in /src.
*** Error code 1

Stop in /src.
TB --- 2009-09-10 22:36:46 - WARNING: /usr/bin/make returned exit code  1 
TB --- 2009-09-10 22:36:46 - ERROR: failed to build lint kernel
TB --- 2009-09-10 22:36:46 - 2750.22 user 421.67 system 3786.79 real


http://tinderbox.des.no/tinderbox-head-HEAD-sparc64-sparc64.full
From tinderbox at freebsd.org  Thu Sep 10 22:49:49 2009
From: tinderbox at freebsd.org (FreeBSD Tinderbox)
Date: Thu Sep 10 22:50:02 2009
Subject: [head tinderbox] failure on sparc64/sun4v
Message-ID: <200909102249.n8AMnnTp013334@freebsd-current.sentex.ca>

TB --- 2009-09-10 21:51:06 - tinderbox 2.6 running on freebsd-current.sentex.ca
TB --- 2009-09-10 21:51:06 - starting HEAD tinderbox run for sparc64/sun4v
TB --- 2009-09-10 21:51:06 - cleaning the object tree
TB --- 2009-09-10 21:51:16 - cvsupping the source tree
TB --- 2009-09-10 21:51:16 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/sparc64/sun4v/supfile
TB --- 2009-09-10 21:51:56 - building world
TB --- 2009-09-10 21:51:56 - MAKEOBJDIRPREFIX=/obj
TB --- 2009-09-10 21:51:56 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2009-09-10 21:51:56 - TARGET=sun4v
TB --- 2009-09-10 21:51:56 - TARGET_ARCH=sparc64
TB --- 2009-09-10 21:51:56 - TZ=UTC
TB --- 2009-09-10 21:51:56 - __MAKE_CONF=/dev/null
TB --- 2009-09-10 21:51:56 - cd /src
TB --- 2009-09-10 21:51:56 - /usr/bin/make -B buildworld
>>> World build started on Thu Sep 10 21:51:57 UTC 2009
>>> 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 Thu Sep 10 22:46:18 UTC 2009
TB --- 2009-09-10 22:46:18 - generating LINT kernel config
TB --- 2009-09-10 22:46:18 - cd /src/sys/sun4v/conf
TB --- 2009-09-10 22:46:18 - /usr/bin/make -B LINT
TB --- 2009-09-10 22:46:18 - building LINT kernel
TB --- 2009-09-10 22:46:18 - MAKEOBJDIRPREFIX=/obj
TB --- 2009-09-10 22:46:18 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2009-09-10 22:46:18 - TARGET=sun4v
TB --- 2009-09-10 22:46:18 - TARGET_ARCH=sparc64
TB --- 2009-09-10 22:46:18 - TZ=UTC
TB --- 2009-09-10 22:46:18 - __MAKE_CONF=/dev/null
TB --- 2009-09-10 22:46:18 - cd /src
TB --- 2009-09-10 22:46:18 - /usr/bin/make -B buildkernel KERNCONF=LINT
>>> Kernel build for LINT started on Thu Sep 10 22:46:18 UTC 2009
>>> 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 -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/dev/dcons/dcons_os.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 -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/dev/de/if_de.c
awk -f /src/sys/tools/makeobjops.awk /src/sys/dev/eisa/eisa_if.m -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 -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  eisa_if.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 -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/dev/e1000/if_em.c -I/src/sys/dev/e1000
cc1: warnings being treated as errors
/src/sys/dev/e1000/if_em.c: In function 'em_mq_start_locked':
/src/sys/dev/e1000/if_em.c:1037: warning: suggest parentheses around assignment used as truth value
/src/sys/dev/e1000/if_em.c:1067: warning: suggest parentheses around assignment used as truth value
*** Error code 1

Stop in /obj/sun4v/src/sys/LINT.
*** Error code 1

Stop in /src.
*** Error code 1

Stop in /src.
TB --- 2009-09-10 22:49:48 - WARNING: /usr/bin/make returned exit code  1 
TB --- 2009-09-10 22:49:48 - ERROR: failed to build lint kernel
TB --- 2009-09-10 22:49:48 - 2762.37 user 408.05 system 3522.10 real


http://tinderbox.des.no/tinderbox-head-HEAD-sparc64-sun4v.full
From randi at freebsd.org  Thu Sep 10 22:52:18 2009
From: randi at freebsd.org (Randi Harper)
Date: Thu Sep 10 22:52:25 2009
Subject: Fwd: Can't boot 8.0-BETA4 from USB stick
In-Reply-To: <f0dd9eb90909101522l2e56f8dardae165976d6c00c0@mail.gmail.com>
References: <f0dd9eb90909080402m27558850g6aaa2a5e4c477758@mail.gmail.com>
	<200909091631.01446.hselasky@c2i.net>
	<f0dd9eb90909092137o25d00f3l8bfba581a9d1aab8@mail.gmail.com>
	<200909100911.10237.hselasky@c2i.net>
	<f0dd9eb90909101448r5ad0c375r47cc253038aaa5f9@mail.gmail.com>
	<e277d6c80909101505t1932472bo22d41ded69c58dd8@mail.gmail.com>
	<f0dd9eb90909101522l2e56f8dardae165976d6c00c0@mail.gmail.com>
Message-ID: <e277d6c80909101552s6e2eaf70ja87ccfc69e788292@mail.gmail.com>

On Thu, Sep 10, 2009 at 3:22 PM, James Butler <sweetnavelorange@gmail.com>wrote:

> 2009/9/11 Randi Harper <randi@freebsd.org>:
> > On Thu, Sep 10, 2009 at 2:48 PM, James Butler <
> sweetnavelorange@gmail.com>
> > wrote:
> >>
> >> 2009/9/10 Hans Petter Selasky <hselasky@c2i.net>:
> >> > On Thursday 10 September 2009 06:37:13 James Butler wrote:
> >> >> Is there anything else worth trying?
> >> >
> >> > Another brand of memory sticks?
> >>
> >> I have only the three different brands that I tried (Toshiba and two
> >> different no-names). Is there really nothing like an adjustable delay
> >> at boot? Perhaps it's time to spend NZD$30 on a CF card and IDE
> >> adapter, but that will be of limited use for troubleshooting or
> >> installation.
> >>
> >> -James
> >> _______________________________________________
> >> 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"
> >
> > I've been asking around about an option to delay before mounting root as
> > well. I don't know of anything off the top of my head, but it sounds to
> me
> > like a bug (or at least a reasonable feature request). Send a PR?
>
> I probably will now, I just wanted to exhaust the existing options. It
> seems to me that a "wait for the configured root device to appear"
> timeout could be arbitrarily long (eg. 10+ secs) by default without
> adversely affecting the normal use case, but I don't claim to know how
> the boot process works.
>
> > Have you only tried this on the one computer? It seems suspicious that
> all
> > the cards are having this problem when I've only heard of two cases of
> USB
> > flash-slowness causing problems so far. I'm curious to see if you have
> the
> > same problem using that flash disk with a different computer.
>
> I think I used the same drive to test-install 8.0-BETA1 on my old
> Thinkpad X31, which seemed to work OK. This Asus motherboard is a but
> useless in other ways; still, 7.2 runs fine.
>
> -James
> _______________________________________________
> 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"
>

To avoid adversely affecting the normal use case, a tunable could specify
the option of having the mount wait until the device appears, or possibly
for how long to delay the mount. This really isn't my area of expertise,
though, so take what I say with a grain of salt.

Not sure if you've seen these, but this is a problem other people are
reporting as well:

Relevant but not enlightening:
http://lists.freebsd.org/pipermail/freebsd-current/2009-May/007457.html
Slightly more helpful:
http://lists.freebsd.org/pipermail/freebsd-current/2009-August/010562.html

Not all that relevant, but interesting anyways:
http://lists.freebsd.org/pipermail/freebsd-current/2009-July/009912.html

-- randi
From duncan.young at pobox.com  Thu Sep 10 23:05:56 2009
From: duncan.young at pobox.com (Duncan Young)
Date: Thu Sep 10 23:06:05 2009
Subject: zfs woes
Message-ID: <4AA981F4.3090607@pobox.com>

Hi all,

Again its happened (my need to restore my main zpool from backups).

I have been having regular crashes (only recently been getting crash
dumps though), and in the the process
of upgrading to 7.1-STABLE, upgrading zpools (now 13) and zfs (now 3), I
now have a problem with
my main data zpool.

I was having these problems before the upgrade.

After zpool status saying that I had corrupted files (actually a zfs
filesystem), I tried destroying it (the zfs filesystem), in the hope
that this
may make my problems go away).  The machine hung.

zpool scrub works, reporting 16 errors.
zpool status -v crashes.
starting multiuser hangs (probably on mounting the dud fs).
I can start single user, and I am currently additional backups of the
filesytems I can access (most off the corrupted zpool).
Any accessing the corrupted zfs filesystem crashes the machine.

Now I think it's fair enough that the filesystem is corrupted (I still
see a need for some type of fsck), but I don't see that the
machine should crash because of it. Any sugestions?

Script started on Fri Sep 11 17:22:23 2009
# uname -a
FreeBSD  7.2-STABLE FreeBSD 7.2-STABLE #8: Fri Sep 11 04:14:39 EST
2009     root@:/usr/obj/usr/src/sys/TRIPLE0  amd64
# cd /usr/src/sys/TRIPLE0
# kgdb ./kernel.debug /var/crash/vmcore/.25
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "amd64-marcel-freebsd"...

Unread portion of the kernel message buffer:
Copyright (c) 1992-2009 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
    The Regents of the University of California. All rights reserved.
FreeBSD is a registered trademark of The FreeBSD Foundation.
FreeBSD 7.2-STABLE #8: Fri Sep 11 04:14:39 EST 2009
    root@:/usr/obj/usr/src/sys/TRIPLE0
module_register: module g_label already exists!
Module g_label failed to register: 17
Timecounter "i8254" frequency 1193182 Hz quality 0
CPU: AMD Phenom(tm) II X4 810 Processor (2608.81-MHz K8-class CPU)
  Origin = "AuthenticAMD"  Id = 0x100f42  Stepping = 2

Features=0x178bfbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,MMX,FXSR,SSE,SSE2,HTT>
  Features2=0x802009<SSE3,MON,CX16,POPCNT>
  AMD
Features=0xee500800<SYSCALL,NX,MMX+,FFXSR,Page1GB,RDTSCP,LM,3DNow!+,3DNow!>
  AMD
Features2=0x37ff<LAHF,CMP,SVM,ExtAPIC,CR8,ABM,SSE4A,MAS,Prefetch,OSVW,IBS,SKINIT,WDT>
  TSC: P-state invariant
  Cores per package: 4
usable memory = 8441266176 (8050 MB)
avail memory  = 8131702784 (7754 MB)
ACPI APIC Table: <072709 APIC1045>
FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs
cpu0 (BSP): APIC ID:  0
cpu1 (AP): APIC ID:  1
cpu2 (AP): APIC ID:  2
cpu3 (AP): APIC ID:  3
This module (opensolaris) contains code covered by the
Common Development and Distribution License (CDDL)
see http://opensolaris.org/os/licensing/opensolaris_license/
ACPI Warning (tbfadt-0505): Optional field "Pm2ControlBlock" has zero
address or length:        0       0/1 [20070320]
ioapic0 <Version 2.1> irqs 0-23 on motherboard
kbd1 at kbdmux0
acpi0: <072709 XSDT1045> on motherboard
acpi0: [ITHREAD]
acpi0: Power Button (fixed)
acpi0: reservation of fee00000, 1000 (3) failed
acpi0: reservation of ffb80000, 80000 (3) failed
acpi0: reservation of fec10000, 20 (3) failed
acpi0: reservation of 0, a0000 (3) failed
acpi0: reservation of 100000, dff00000 (3) failed
ACPI HPET table warning: Sequence is non-zero (2)
Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000
acpi_timer0: <32-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0
acpi_hpet0: <High Precision Event Timer> iomem 0xfed00000-0xfed003ff on
acpi0
Timecounter "HPET" frequency 14318180 Hz quality 900
pcib0: <ACPI Host-PCI bridge> port 0xcf8-0xcff on acpi0
pci0: <ACPI PCI bus> on pcib0
pcib1: <ACPI PCI-PCI bridge> at device 1.0 on pci0
pci1: <ACPI PCI bus> on pcib1
vgapci0: <VGA-compatible display> port 0xc000-0xc0ff mem
0xf0000000-0xf7ffffff,0xfbce0000-0xfbceffff,0xfbb00000-0xfbbfffff irq 18
at device 5.0 on pci1
hdac0: <ATI RS780 High Definition Audio Controller> mem
0xfbcfc000-0xfbcfffff irq 19 at device 5.1 on pci1
hdac0: HDA Driver Revision: 20090624_0136
hdac0: [ITHREAD]
pcib2: <ACPI PCI-PCI bridge> irq 16 at device 4.0 on pci0
pci2: <ACPI PCI bus> on pcib2
hptrr0: <sx508x> port 0xd800-0xd8ff mem 0xfbe00000-0xfbefffff irq 16 at
device 0.0 on pci2
hptrr: adapter at PCI 2:0:0, IRQ 16
pcib3: <ACPI PCI-PCI bridge> irq 17 at device 5.0 on pci0
pci3: <ACPI PCI bus> on pcib3
em0: <Intel(R) PRO/1000 Network Connection 6.9.6> port 0xec00-0xec1f mem
0xfbfe0000-0xfbffffff,0xfbf00000-0xfbf7ffff,0xfbfdc000-0xfbfdffff irq 17
at device 0.0 on pci3
em0: Using MSIX interrupts
em0: [ITHREAD]
em0: [ITHREAD]
em0: [ITHREAD]
em0: Ethernet address: 00:1b:21:3d:eb:e7
atapci0: <ATI AHCI controller> port
0xb000-0xb007,0xa000-0xa003,0x9000-0x9007,0x8000-0x8003,0x7000-0x700f
mem 0xfbaffc00-0xfbafffff irq 22 at device 17.0 on pci0
atapci0: [ITHREAD]
atapci0: AHCI Version 01.10 controller with 6 ports detected
ata2: <ATA channel 0> on atapci0
ata2: [ITHREAD]
ata3: <ATA channel 1> on atapci0
ata3: [ITHREAD]
ata4: <ATA channel 2> on atapci0
ata4: [ITHREAD]
ata5: <ATA channel 3> on atapci0
ata5: [ITHREAD]
ata6: <ATA channel 4> on atapci0
ata6: [ITHREAD]
ata7: <ATA channel 5> on atapci0
ata7: [ITHREAD]
ohci0: <OHCI (generic) USB controller> mem 0xfbafd000-0xfbafdfff irq 16
at device 18.0 on pci0
ohci0: [GIANT-LOCKED]
ohci0: [ITHREAD]
usb0: OHCI version 1.0, legacy support
usb0: <OHCI (generic) USB controller> on ohci0
usb0: USB revision 1.0
uhub0: <ATI OHCI root hub, class 9/0, rev 1.00/1.00, addr 1> on usb0
uhub0: 3 ports with 3 removable, self powered
ohci1: <OHCI (generic) USB controller> mem 0xfbafe000-0xfbafefff irq 16
at device 18.1 on pci0
ohci1: [GIANT-LOCKED]
ohci1: [ITHREAD]
usb1: OHCI version 1.0, legacy support
usb1: <OHCI (generic) USB controller> on ohci1
usb1: USB revision 1.0
uhub1: <ATI OHCI root hub, class 9/0, rev 1.00/1.00, addr 1> on usb1
uhub1: 3 ports with 3 removable, self powered
ehci0: <EHCI (generic) USB 2.0 controller> mem 0xfbaff800-0xfbaff8ff irq
17 at device 18.2 on pci0
ehci0: [GIANT-LOCKED]
ehci0: [ITHREAD]
usb2: EHCI version 1.0
usb2: companion controllers, 3 ports each: usb0 usb1
usb2: <EHCI (generic) USB 2.0 controller> on ehci0
usb2: USB revision 2.0
uhub2: <ATI EHCI root hub, class 9/0, rev 2.00/1.00, addr 1> on usb2
uhub2: 6 ports with 6 removable, self powered
ohci2: <OHCI (generic) USB controller> mem 0xfbafb000-0xfbafbfff irq 18
at device 19.0 on pci0
ohci2: [GIANT-LOCKED]
ohci2: [ITHREAD]
usb3: OHCI version 1.0, legacy support
usb3: <OHCI (generic) USB controller> on ohci2
usb3: USB revision 1.0
uhub3: <ATI OHCI root hub, class 9/0, rev 1.00/1.00, addr 1> on usb3
uhub3: 3 ports with 3 removable, self powered
ohci3: <OHCI (generic) USB controller> mem 0xfbafc000-0xfbafcfff irq 18
at device 19.1 on pci0
ohci3: [GIANT-LOCKED]
ohci3: [ITHREAD]
usb4: OHCI version 1.0, legacy support
usb4: <OHCI (generic) USB controller> on ohci3
usb4: USB revision 1.0
uhub4: <ATI OHCI root hub, class 9/0, rev 1.00/1.00, addr 1> on usb4
uhub4: 3 ports with 3 removable, self powered
ehci1: <EHCI (generic) USB 2.0 controller> mem 0xfbaff400-0xfbaff4ff irq
19 at device 19.2 on pci0
ehci1: [GIANT-LOCKED]
ehci1: [ITHREAD]
usb5: EHCI version 1.0
usb5: companion controllers, 3 ports each: usb3 usb4
usb5: <EHCI (generic) USB 2.0 controller> on ehci1
usb5: USB revision 2.0
uhub5: <ATI EHCI root hub, class 9/0, rev 2.00/1.00, addr 1> on usb5
uhub5: 6 ports with 6 removable, self powered
pci0: <serial bus, SMBus> at device 20.0 (no driver attached)
atapci1: <ATI IXP700 UDMA133 controller> port
0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xff00-0xff0f at device 20.1 on pci0
ata0: <ATA channel 0> on atapci1
ata0: [ITHREAD]
hdac1: <ATI SB600 High Definition Audio Controller> mem
0xfbaf4000-0xfbaf7fff irq 16 at device 20.2 on pci0
hdac1: HDA Driver Revision: 20090624_0136
hdac1: [ITHREAD]
isab0: <PCI-ISA bridge> at device 20.3 on pci0
isa0: <ISA bus> on isab0
pcib4: <ACPI PCI-PCI bridge> at device 20.4 on pci0
pci4: <ACPI PCI bus> on pcib4
ohci4: <OHCI (generic) USB controller> mem 0xfbafa000-0xfbafafff irq 18
at device 20.5 on pci0
ohci4: [GIANT-LOCKED]
ohci4: [ITHREAD]
usb6: OHCI version 1.0, legacy support
usb6: <OHCI (generic) USB controller> on ohci4
usb6: USB revision 1.0
uhub6: <ATI OHCI root hub, class 9/0, rev 1.00/1.00, addr 1> on usb6
uhub6: 2 ports with 2 removable, self powered
acpi_button0: <Power Button> on acpi0
atkbdc0: <Keyboard controller (i8042)> port 0x60,0x64 irq 1 on acpi0
atkbd0: <AT Keyboard> irq 1 on atkbdc0
kbd0 at atkbd0
atkbd0: [GIANT-LOCKED]
atkbd0: [ITHREAD]
psm0: <PS/2 Mouse> irq 12 on atkbdc0
psm0: [GIANT-LOCKED]
psm0: [ITHREAD]
psm0: model MouseMan+, device ID 0
acpi_aiboost0: <ASUStek AIBOOSTER> on acpi0
sio0: configured irq 4 not in bitmap of probed irqs 0
sio0: port may not be enabled
sio0: configured irq 4 not in bitmap of probed irqs 0
sio0: port may not be enabled
sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on
acpi0
sio0: type 16550A
sio0: [FILTER]
fdc0: <floppy drive controller (FDE)> port 0x3f0-0x3f5,0x3f7 irq 6 drq 2
on acpi0
fdc0: [FILTER]
cpu0: <ACPI CPU> on acpi0
acpi_throttle0: <ACPI CPU Throttling> on cpu0
cpu1: <ACPI CPU> on acpi0
cpu2: <ACPI CPU> on acpi0
cpu3: <ACPI CPU> on acpi0
cryptosoft0: <software crypto> on motherboard
orm0: <ISA Option ROM> at iomem 0xd7800-0xd87ff on isa0
sc0: <System console> at flags 0x100 on isa0
sc0: VGA <16 virtual consoles, flags=0x300>
vga0: <Generic ISA VGA> at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0
ppc0: cannot reserve I/O port range
sio1: configured irq 3 not in bitmap of probed irqs 0
sio1: port may not be enabled
ulpt0: <Samsung Electronics Co., Ltd. Samsung Laser Printer ML-1200
Series, class 0/0, rev 1.10/1.00, addr 2> on uhub0
ulpt0: using bi-directional mode
WARNING: ZFS is considered to be an experimental feature in FreeBSD.
Timecounters tick every 1.000 msec
vboxdrv: fAsync=0 offMin=0x12c offMax=0x219
hptrr: start channel [0,0]
hptrr: start channel [0,1]
hptrr: start channel [0,2]
hptrr: start channel [0,3]
hptrr: [0 0] Start channel soft reset.
hptrr: [0 2] Start channel soft reset.
hptrr: [0 3] Start channel soft reset.
hptrr: channel [0,0] started successfully
hptrr: channel [0,2] started successfully
hptrr: channel [0,3] started successfully
hptrr: [0 1] Failed to perform channel hard reset.
hptrr0: [GIANT-LOCKED]
hptrr0: [ITHREAD]
The GEOM class LABEL is already loaded.
ZFS filesystem version 13
ZFS storage pool version 13
da0 at hptrr0 bus 0 target 0 lun 0
da0: <HPT DISK 0_0 4.00> Fixed Direct Access SCSI-0 device
da1 at hptrr0 bus 0 target 1 lun 0
da1: <HPT DISK 0_1 4.00> Fixed Direct Access SCSI-0 device
da2 at hptrr0 bus 0 target 2 lun 0
da2: <HPT DISK 0_2 4.00> Fixed Direct Access SCSI-0 device
acd0: DVDR <HL-DT-ST DVDRAM GSA-4163B/A104> at ata0-master PIO4
ad4: 476940MB <WDC WD5000AAKS-00C8A0 12.01C02> at ata2-master SATA300
acd0: FAILURE - INQUIRY ILLEGAL REQUEST asc=0x24 ascq=0x00 sks=0x40 0x00
0x01
(probe0:ata0:0:0:0): TEST UNIT READY. CDB: 0 0 0 0 0 0
(probe0:ata0:0:0:0): CAM Status: SCSI Status Error
(probe0:ata0:0:0:0): SCSI Status: Check Condition
(probe0:ata0:0:0:0): NOT READY csi:0,0,bb,0 asc:3a,0
(probe0:ata0:0:0:0): Medium not present
(probe0:ata0:0:0:0): Unretryable error
cd0 at ata0 bus 0 target 0 lun 0
cd0: <HL-DT-ST DVDRAM GSA-4163B A104> Removable CD-ROM SCSI-0 device
cd0: 16.000MB/s transfers
cd0: Attempt to query device size failed: NOT READY, Medium not present
ad6: 953869MB <WDC WD10EADS-00L5B1 01.01A01> at ata3-master SATA300
ad10: 953869MB <WDC WD10EACS-00D6B0 01.01A01> at ata5-master SATA300
ad12: 476940MB <WDC WD5000AACS-00ZUB0 01.01B01> at ata6-master SATA300
ad14: 953869MB <Seagate ST31000528AS CC44> at ata7-master SATA300
hdac0: HDA Codec #0: ATI RS690/780 HDMI
pcm0: <HDA ATI RS690/780 HDMI PCM #0 Digital> at cad 0 nid 1 on hdac0
hdac1: HDA Codec #0: VIA VT1708S_0
pcm1: <HDA VIA VT1708S_0 PCM #0 Analog> at cad 0 nid 1 on hdac1
pcm2: <HDA VIA VT1708S_0 PCM #1 Digital> at cad 0 nid 1 on hdac1
pcm3: <HDA VIA VT1708S_0 PCM #2 Digital> at cad 0 nid 1 on hdac1
SMP: AP CPU #2 Launched!
SMP: AP CPU #3 Launched!
SMP: AP CPU #1 Launched!
Trying to mount root from zfs:rootzfs
<118>Loading configuration files.
<118>kernel dumps on /dev/ad4s1b
<118>Entropy harvesting:
<118> interrupts
<118> ethernet
<118> point_to_point
<118> kickstart
<118>.
GEOM_ELI: Device label/swapB.eli created.
GEOM_ELI: Encryption: AES-CBC 256
GEOM_ELI:     Crypto: software
<118>swapon: adding /dev/label/swapB.eli as swap device
<118>/etc/rc: WARNING: Use of the early.sh script is deprecated
<118>/etc/rc: WARNING: Please use a new-style rc.d script instead
<118>/etc/rc: WARNING: See rc(8) for more information
<118>gmirror:
<118>No such device: swap_AB.
<118>
<118>Starting file system checks:
<118>/dev/label/bstrapA: FILE SYSTEM CLEAN; SKIPPING CHECKS
<118>/dev/label/bstrapA: clean, 303581 free (261 frags, 37915 blocks,
0.1% fragmentation)
<118>/dev/label/bstrapB: FILE SYSTEM CLEAN; SKIPPING CHECKS
<118>/dev/label/bstrapB: clean, 303502 free (318 frags, 37898 blocks,
0.1% fragmentation)
<118>Setting hostuuid: e039c626-5f54-da11-8e5a-e6b6a8a23cf0.
<118>Setting hostid: 0xd449202f.
<118>Mounting local file systems:
<118>.


Fatal trap 12: page fault while in kernel mode
cpuid = 1; apic id = 01
fault virtual address    = 0x50
fault code        = supervisor read data, page not present
instruction pointer    = 0x8:0xffffffff80ad7a5e
stack pointer            = 0x10:0xffffff80a5b2f620
frame pointer            = 0x10:0xffffff80a5b2f6a0
code segment        = base 0x0, limit 0xfffff, type 0x1b
            = DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags    = interrupt enabled, resume, IOPL = 0
current process        = 314 (txg_thread_enter)
trap number        = 12
panic: page fault
cpuid = 1
Uptime: 2m11s
Physical memory: 8050 MB
Dumping 1553 MB: 1538 1522 1506 1490 1474 1458 1442 1426 1410 1394 1378
1362 1346 1330 1314 1298 1282 1266 1250 1234 1218 1202 1186 1170 1154
1138 1122 1106 1090 1074 1058 1042 1026 1010 994 978 962 946 930 914 898
882 866 850 834 818 802 786 770 754 738 722 706 690 674 658 642 626 610
594 578 562 546 530 514 498 482 466 450 434 418 402 386 370 354 338 322
306 290 274 258 242 226 210 194 178 162 146 130 114 98 82 66 50 34 18 2

Reading symbols from /boot/kernel/zfs.ko...Reading symbols from
/bootdirA/boot/kernel/zfs.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/zfs.ko
Reading symbols from /boot/kernel/opensolaris.ko...Reading symbols from
/bootdirA/boot/kernel/opensolaris.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/opensolaris.ko
Reading symbols from /boot/kernel/geom_eli.ko...Reading symbols from
/bootdirA/boot/kernel/geom_eli.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/geom_eli.ko
Reading symbols from /boot/kernel/crypto.ko...Reading symbols from
/bootdirA/boot/kernel/crypto.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/crypto.ko
Reading symbols from /boot/kernel/zlib.ko...Reading symbols from
/bootdirA/boot/kernel/zlib.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/zlib.ko
Reading symbols from /boot/kernel/geom_label.ko...Reading symbols from
/bootdirA/boot/kernel/geom_label.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/geom_label.ko
Reading symbols from /boot/kernel/geom_mirror.ko...Reading symbols from
/bootdirA/boot/kernel/geom_mirror.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/geom_mirror.ko
Reading symbols from /boot/kernel/snd_hda.ko...Reading symbols from
/bootdirA/boot/kernel/snd_hda.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/snd_hda.ko
Reading symbols from /boot/kernel/sound.ko...Reading symbols from
/bootdirA/boot/kernel/sound.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/sound.ko
Reading symbols from /boot/kernel/cd9660_iconv.ko...Reading symbols from
/bootdirA/boot/kernel/cd9660_iconv.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/cd9660_iconv.ko
Reading symbols from /boot/kernel/libiconv.ko...Reading symbols from
/bootdirA/boot/kernel/libiconv.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/libiconv.ko
Reading symbols from /boot/kernel/aio.ko...Reading symbols from
/bootdirA/boot/kernel/aio.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/aio.ko
Reading symbols from /boot/modules/vboxdrv.ko...done.
Loaded symbols for /boot/modules/vboxdrv.ko
Reading symbols from /boot/kernel/sem.ko...Reading symbols from
/bootdirA/boot/kernel/sem.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/sem.ko
#0  doadump () at pcpu.h:195
195        __asm __volatile("movq %%gs:0,%0" : "=r" (td));
(kgdb) backtrace
#0  doadump () at pcpu.h:195
#1  0x0000000000000004 in ?? ()
#2  0xffffffff803aab90 in boot (howto=260)
    at /usr/src/sys/kern/kern_shutdown.c:418
#3  0xffffffff803aafb2 in panic (fmt=0x104 <Address 0x104 out of bounds>)
    at /usr/src/sys/kern/kern_shutdown.c:574
#4  0xffffffff80651d03 in trap_fatal (frame=0xffffff0009572390,
eva=Variable "eva" is not available.
)
    at /usr/src/sys/amd64/amd64/trap.c:770
#5  0xffffffff806520d5 in trap_pfault (frame=0xffffff80a5b2f570, usermode=0)
    at /usr/src/sys/amd64/amd64/trap.c:686
#6  0xffffffff80652a63 in trap (frame=0xffffff80a5b2f570)
    at /usr/src/sys/amd64/amd64/trap.c:457
#7  0xffffffff8063cb4e in calltrap ()
    at /usr/src/sys/amd64/amd64/exception.S:218
#8  0xffffffff80ad7a5e in find_block (th=0xffffff8006930000,
    zseg=0xffffff000dafc580, dnp=0xffffff8006d35600, depth=Variable
"depth" is not available.
)
    at
/usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/dmu_traverse.c:400
#9  0xffffffff80ad81a3 in traverse_more (th=0xffffff8006930000)
    at
/usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/dmu_traverse.c:672
#10 0xffffffff80ad8368 in traverse_dsl_dataset (ds=0x23, txg_start=1,
advance=Variable "advance" is not available.

)
    at
/usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/d---Type 

<return> to continue, or q <return> to quit---
mu_traverse.c:731
#11 0xffffffff80ae41c9 in dsl_dataset_destroy_sync () from
/boot/kernel/zfs.ko
#12 0xffffffff80ae6d2a in dsl_sync_task_group_sync
(dstg=0xffffff000d256600,
    tx=0xffffff000d1fca80)
    at
/usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/dsl_synctask.c:186
#13 0xffffffff80ae6873 in dsl_pool_sync (dp=0xffffff000d521000, txg=3430336)
    at
/usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/dsl_pool.c:316
#14 0xffffffff80af59c3 in spa_sync (spa=0xffffff0006d08000, txg=3430336)
    at
/usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/spa.c:3988
#15 0xffffffff80afd772 in txg_sync_thread (arg=Variable "arg" is not
available.
)
    at
/usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/txg.c:352
#16 0xffffffff80385452 in fork_exit (
    callout=0xffffffff80afd490 <txg_sync_thread>, arg=0xffffff000d521000,
    frame=0xffffff80a5b2fc80) at /usr/src/sys/kern/kern_fork.c:811
#17 0xffffffff8063cf2e in fork_trampoline ()
    at /usr/src/sys/amd64/amd64/exception.S:554
#18 0x0000000000000000 in ?? ()
#19 0x0000000000000000 in ?? ()
#20 0x0000000000000001 in ?? ()
#21 0x0000000000000000 in ?? ()
#22 0x0000000000000000 in ?? ()
#23 0x0000000000000000 in ?? ()
#24 0x0000000000000000 in ?? ()
#25 0x0000000000000000 in ?? ()
#26 0x0000000000000000 in ?? ()
#27 0x0000000000000000 in ?? ()
#28 0x0000000000000000 in ?? ()
#29 0x0000000000000000 in ?? ()
#30 0x0000000000000000 in ?? ()
#31 0x0000000000000000 in ?? ()
#32 0x0000000000000000 in ?? ()
#33 0x0000000000000000 in ?? ()
#34 0x0000000000000000 in ?? ()
#35 0x0000000000000000 in ?? ()
#36 0x0000000000000000 in ?? ()
#37 0x0000000000000000 in ?? ()
#38 0x0000000000000000 in ?? ()
#39 0x0000000000000000 in ?? ()
#40 0x0000000000000000 in ?? ()
#41 0x0000000000000000 in ?? ()
#42 0x0000000000dde000 in ?? ()
#43 0xffffffff80950d40 in tdq_cpu ()
#44 0xffffffff8095c940 in tdq_groups ()
#45 0xffffffff8095c8c0 in tdq_cpu ()
#46 0xffffff0009572390 in ?? ()
#47 0x0000000000000000 in ?? ()
#48 0xffffff80a5b2f1e8 in ?? ()
#49 0xffffff0009572390 in ?? ()
#50 0xffffffff803ce154 in sched_switch (td=0xffffffff80afd490, newtd=0x0,
    flags=0) at /usr/src/sys/kern/sched_ule.c:1938
#51 0x0000000000000000 in ?? ()
#52 0x0000000000000000 in ?? ()
#53 0x0000000000000000 in ?? ()
#54 0x0000000000000000 in ?? ()
#55 0x0000000000000000 in ?? ()
#56 0x0000000000000000 in ?? ()
#57 0x0000000000000000 in ?? ()
#58 0x0000000000000000 in ?? ()
#59 0x0000000000000000 in ?? ()
#60 0x0000000000000000 in ?? ()
#61 0x0000000000000000 in ?? ()
#62 0x0000000000000000 in ?? ()
#63 0x0000000000000000 in ?? ()
#64 0x0000000000000000 in ?? ()
#65 0x0000000000000000 in ?? ()
#66 0x0000000000000000 in ?? ()
#67 0x0000000000000000 in ?? ()
#68 0x0000000000000000 in ?? ()
#69 0x0000000000000000 in ?? ()
#70 0x0000000000000000 in ?? ()
#71 0x0000000000000000 in ?? ()
#72 0x0000000000000000 in ?? ()
#73 0x0000000000000000 in ?? ()
#74 0x0000000000000000 in ?? ()
#75 0x0000000000000000 in ?? ()
#76 0x0000000000000000 in ?? ()
#77 0x0000000000000000 in ?? ()
#78 0x0000000000000000 in ?? ()
#79 0x0000000000000000 in ?? ()
#80 0x0000000000000000 in ?? ()
#81 0x0000000000000000 in ?? ()
#82 0x0000000000000000 in ?? ()
#83 0x0000000000000000 in ?? ()
#84 0x0000000000000000 in ?? ()
#85 0x0000000000000000 in ?? ()
#86 0x0000000000000000 in ?? ()
#87 0x0000000000000000 in ?? ()
#88 0x0000000000000000 in ?? ()
#89 0x0000000000000000 in ?? ()
#90 0x0000000000000000 in ?? ()
#91 0x0000000000000000 in ?? ()
#92 0x0000000000000000 in ?? ()
#93 0x0000000000000000 in ?? ()
#94 0x0000000000000000 in ?? ()
#95 0x0000000000000000 in ?? ()
#96 0x0000000000000000 in ?? ()
#97 0x0000000000000000 in ?? ()
#98 0x0000000000000000 in ?? ()
#99 0x0000000000000000 in ?? ()
#100 0x0000000000000000 in ?? ()
#101 0x0000000000000000 in ?? ()
#102 0x0000000000000000 in ?? ()
#103 0x0000000000000000 in ?? ()
#104 0x0000000000000000 in ?? ()
#105 0x0000000000000000 in ?? ()
#106 0x0000000000000000 in ?? ()
#107 0x0000000000000000 in ?? ()
#108 0x0000000000000000 in ?? ()
#109 0x0000000000000000 in ?? ()
#110 0x0000000000000000 in ?? ()
#111 0x0000000000000000 in ?? ()
#112 0x0000000000000000 in ?? ()
#113 0x0000000000000000 in ?? ()
#114 0x0000000000000000 in ?? ()
#115 0x0000000000000000 in ?? ()
#116 0x0000000000000000 in ?? ()
#117 0x0000000000000000 in ?? ()
#118 0x0000000000000000 in ?? ()
Cannot access memory at address 0xffffff80a5b30000
(kgdb) q
# ^D
Script done on Fri Sep 11 17:26:02 2009

From spawk at acm.poly.edu  Thu Sep 10 23:46:31 2009
From: spawk at acm.poly.edu (Boris Kochergin)
Date: Thu Sep 10 23:46:39 2009
Subject: zfs woes
In-Reply-To: <4AA981F4.3090607@pobox.com>
References: <4AA981F4.3090607@pobox.com>
Message-ID: <4AA98FCA.9090506@acm.poly.edu>

Duncan Young wrote:
> Hi all,
>
> Again its happened (my need to restore my main zpool from backups).
>
> I have been having regular crashes (only recently been getting crash
> dumps though), and in the the process
> of upgrading to 7.1-STABLE, upgrading zpools (now 13) and zfs (now 3), I
> now have a problem with
> my main data zpool.
>
> I was having these problems before the upgrade.
>
> After zpool status saying that I had corrupted files (actually a zfs
> filesystem), I tried destroying it (the zfs filesystem), in the hope
> that this
> may make my problems go away).  The machine hung.
>
> zpool scrub works, reporting 16 errors.
> zpool status -v crashes.
> starting multiuser hangs (probably on mounting the dud fs).
> I can start single user, and I am currently additional backups of the
> filesytems I can access (most off the corrupted zpool).
> Any accessing the corrupted zfs filesystem crashes the machine.
>
> Now I think it's fair enough that the filesystem is corrupted (I still
> see a need for some type of fsck), but I don't see that the
> machine should crash because of it. Any sugestions?
>
> Script started on Fri Sep 11 17:22:23 2009
> # uname -a
> FreeBSD  7.2-STABLE FreeBSD 7.2-STABLE #8: Fri Sep 11 04:14:39 EST
> 2009     root@:/usr/obj/usr/src/sys/TRIPLE0  amd64
> # cd /usr/src/sys/TRIPLE0
> # kgdb ./kernel.debug /var/crash/vmcore/.25
> GNU gdb 6.1.1 [FreeBSD]
> Copyright 2004 Free Software Foundation, Inc.
> GDB is free software, covered by the GNU General Public License, and 
> you are
> welcome to change it and/or distribute copies of it under certain
> conditions.
> Type "show copying" to see the conditions.
> There is absolutely no warranty for GDB.  Type "show warranty" for 
> details.
> This GDB was configured as "amd64-marcel-freebsd"...
>
> Unread portion of the kernel message buffer:
> Copyright (c) 1992-2009 The FreeBSD Project.
> Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
>    The Regents of the University of California. All rights reserved.
> FreeBSD is a registered trademark of The FreeBSD Foundation.
> FreeBSD 7.2-STABLE #8: Fri Sep 11 04:14:39 EST 2009
>    root@:/usr/obj/usr/src/sys/TRIPLE0
> module_register: module g_label already exists!
> Module g_label failed to register: 17
> Timecounter "i8254" frequency 1193182 Hz quality 0
> CPU: AMD Phenom(tm) II X4 810 Processor (2608.81-MHz K8-class CPU)
>  Origin = "AuthenticAMD"  Id = 0x100f42  Stepping = 2
>
> Features=0x178bfbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,MMX,FXSR,SSE,SSE2,HTT> 
>
>  Features2=0x802009<SSE3,MON,CX16,POPCNT>
>  AMD
> Features=0xee500800<SYSCALL,NX,MMX+,FFXSR,Page1GB,RDTSCP,LM,3DNow!+,3DNow!> 
>
>  AMD
> Features2=0x37ff<LAHF,CMP,SVM,ExtAPIC,CR8,ABM,SSE4A,MAS,Prefetch,OSVW,IBS,SKINIT,WDT> 
>
>  TSC: P-state invariant
>  Cores per package: 4
> usable memory = 8441266176 (8050 MB)
> avail memory  = 8131702784 (7754 MB)
> ACPI APIC Table: <072709 APIC1045>
> FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs
> cpu0 (BSP): APIC ID:  0
> cpu1 (AP): APIC ID:  1
> cpu2 (AP): APIC ID:  2
> cpu3 (AP): APIC ID:  3
> This module (opensolaris) contains code covered by the
> Common Development and Distribution License (CDDL)
> see http://opensolaris.org/os/licensing/opensolaris_license/
> ACPI Warning (tbfadt-0505): Optional field "Pm2ControlBlock" has zero
> address or length:        0       0/1 [20070320]
> ioapic0 <Version 2.1> irqs 0-23 on motherboard
> kbd1 at kbdmux0
> acpi0: <072709 XSDT1045> on motherboard
> acpi0: [ITHREAD]
> acpi0: Power Button (fixed)
> acpi0: reservation of fee00000, 1000 (3) failed
> acpi0: reservation of ffb80000, 80000 (3) failed
> acpi0: reservation of fec10000, 20 (3) failed
> acpi0: reservation of 0, a0000 (3) failed
> acpi0: reservation of 100000, dff00000 (3) failed
> ACPI HPET table warning: Sequence is non-zero (2)
> Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000
> acpi_timer0: <32-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0
> acpi_hpet0: <High Precision Event Timer> iomem 0xfed00000-0xfed003ff on
> acpi0
> Timecounter "HPET" frequency 14318180 Hz quality 900
> pcib0: <ACPI Host-PCI bridge> port 0xcf8-0xcff on acpi0
> pci0: <ACPI PCI bus> on pcib0
> pcib1: <ACPI PCI-PCI bridge> at device 1.0 on pci0
> pci1: <ACPI PCI bus> on pcib1
> vgapci0: <VGA-compatible display> port 0xc000-0xc0ff mem
> 0xf0000000-0xf7ffffff,0xfbce0000-0xfbceffff,0xfbb00000-0xfbbfffff irq 18
> at device 5.0 on pci1
> hdac0: <ATI RS780 High Definition Audio Controller> mem
> 0xfbcfc000-0xfbcfffff irq 19 at device 5.1 on pci1
> hdac0: HDA Driver Revision: 20090624_0136
> hdac0: [ITHREAD]
> pcib2: <ACPI PCI-PCI bridge> irq 16 at device 4.0 on pci0
> pci2: <ACPI PCI bus> on pcib2
> hptrr0: <sx508x> port 0xd800-0xd8ff mem 0xfbe00000-0xfbefffff irq 16 at
> device 0.0 on pci2
> hptrr: adapter at PCI 2:0:0, IRQ 16
> pcib3: <ACPI PCI-PCI bridge> irq 17 at device 5.0 on pci0
> pci3: <ACPI PCI bus> on pcib3
> em0: <Intel(R) PRO/1000 Network Connection 6.9.6> port 0xec00-0xec1f mem
> 0xfbfe0000-0xfbffffff,0xfbf00000-0xfbf7ffff,0xfbfdc000-0xfbfdffff irq 17
> at device 0.0 on pci3
> em0: Using MSIX interrupts
> em0: [ITHREAD]
> em0: [ITHREAD]
> em0: [ITHREAD]
> em0: Ethernet address: 00:1b:21:3d:eb:e7
> atapci0: <ATI AHCI controller> port
> 0xb000-0xb007,0xa000-0xa003,0x9000-0x9007,0x8000-0x8003,0x7000-0x700f
> mem 0xfbaffc00-0xfbafffff irq 22 at device 17.0 on pci0
> atapci0: [ITHREAD]
> atapci0: AHCI Version 01.10 controller with 6 ports detected
> ata2: <ATA channel 0> on atapci0
> ata2: [ITHREAD]
> ata3: <ATA channel 1> on atapci0
> ata3: [ITHREAD]
> ata4: <ATA channel 2> on atapci0
> ata4: [ITHREAD]
> ata5: <ATA channel 3> on atapci0
> ata5: [ITHREAD]
> ata6: <ATA channel 4> on atapci0
> ata6: [ITHREAD]
> ata7: <ATA channel 5> on atapci0
> ata7: [ITHREAD]
> ohci0: <OHCI (generic) USB controller> mem 0xfbafd000-0xfbafdfff irq 16
> at device 18.0 on pci0
> ohci0: [GIANT-LOCKED]
> ohci0: [ITHREAD]
> usb0: OHCI version 1.0, legacy support
> usb0: <OHCI (generic) USB controller> on ohci0
> usb0: USB revision 1.0
> uhub0: <ATI OHCI root hub, class 9/0, rev 1.00/1.00, addr 1> on usb0
> uhub0: 3 ports with 3 removable, self powered
> ohci1: <OHCI (generic) USB controller> mem 0xfbafe000-0xfbafefff irq 16
> at device 18.1 on pci0
> ohci1: [GIANT-LOCKED]
> ohci1: [ITHREAD]
> usb1: OHCI version 1.0, legacy support
> usb1: <OHCI (generic) USB controller> on ohci1
> usb1: USB revision 1.0
> uhub1: <ATI OHCI root hub, class 9/0, rev 1.00/1.00, addr 1> on usb1
> uhub1: 3 ports with 3 removable, self powered
> ehci0: <EHCI (generic) USB 2.0 controller> mem 0xfbaff800-0xfbaff8ff irq
> 17 at device 18.2 on pci0
> ehci0: [GIANT-LOCKED]
> ehci0: [ITHREAD]
> usb2: EHCI version 1.0
> usb2: companion controllers, 3 ports each: usb0 usb1
> usb2: <EHCI (generic) USB 2.0 controller> on ehci0
> usb2: USB revision 2.0
> uhub2: <ATI EHCI root hub, class 9/0, rev 2.00/1.00, addr 1> on usb2
> uhub2: 6 ports with 6 removable, self powered
> ohci2: <OHCI (generic) USB controller> mem 0xfbafb000-0xfbafbfff irq 18
> at device 19.0 on pci0
> ohci2: [GIANT-LOCKED]
> ohci2: [ITHREAD]
> usb3: OHCI version 1.0, legacy support
> usb3: <OHCI (generic) USB controller> on ohci2
> usb3: USB revision 1.0
> uhub3: <ATI OHCI root hub, class 9/0, rev 1.00/1.00, addr 1> on usb3
> uhub3: 3 ports with 3 removable, self powered
> ohci3: <OHCI (generic) USB controller> mem 0xfbafc000-0xfbafcfff irq 18
> at device 19.1 on pci0
> ohci3: [GIANT-LOCKED]
> ohci3: [ITHREAD]
> usb4: OHCI version 1.0, legacy support
> usb4: <OHCI (generic) USB controller> on ohci3
> usb4: USB revision 1.0
> uhub4: <ATI OHCI root hub, class 9/0, rev 1.00/1.00, addr 1> on usb4
> uhub4: 3 ports with 3 removable, self powered
> ehci1: <EHCI (generic) USB 2.0 controller> mem 0xfbaff400-0xfbaff4ff irq
> 19 at device 19.2 on pci0
> ehci1: [GIANT-LOCKED]
> ehci1: [ITHREAD]
> usb5: EHCI version 1.0
> usb5: companion controllers, 3 ports each: usb3 usb4
> usb5: <EHCI (generic) USB 2.0 controller> on ehci1
> usb5: USB revision 2.0
> uhub5: <ATI EHCI root hub, class 9/0, rev 2.00/1.00, addr 1> on usb5
> uhub5: 6 ports with 6 removable, self powered
> pci0: <serial bus, SMBus> at device 20.0 (no driver attached)
> atapci1: <ATI IXP700 UDMA133 controller> port
> 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xff00-0xff0f at device 20.1 on pci0
> ata0: <ATA channel 0> on atapci1
> ata0: [ITHREAD]
> hdac1: <ATI SB600 High Definition Audio Controller> mem
> 0xfbaf4000-0xfbaf7fff irq 16 at device 20.2 on pci0
> hdac1: HDA Driver Revision: 20090624_0136
> hdac1: [ITHREAD]
> isab0: <PCI-ISA bridge> at device 20.3 on pci0
> isa0: <ISA bus> on isab0
> pcib4: <ACPI PCI-PCI bridge> at device 20.4 on pci0
> pci4: <ACPI PCI bus> on pcib4
> ohci4: <OHCI (generic) USB controller> mem 0xfbafa000-0xfbafafff irq 18
> at device 20.5 on pci0
> ohci4: [GIANT-LOCKED]
> ohci4: [ITHREAD]
> usb6: OHCI version 1.0, legacy support
> usb6: <OHCI (generic) USB controller> on ohci4
> usb6: USB revision 1.0
> uhub6: <ATI OHCI root hub, class 9/0, rev 1.00/1.00, addr 1> on usb6
> uhub6: 2 ports with 2 removable, self powered
> acpi_button0: <Power Button> on acpi0
> atkbdc0: <Keyboard controller (i8042)> port 0x60,0x64 irq 1 on acpi0
> atkbd0: <AT Keyboard> irq 1 on atkbdc0
> kbd0 at atkbd0
> atkbd0: [GIANT-LOCKED]
> atkbd0: [ITHREAD]
> psm0: <PS/2 Mouse> irq 12 on atkbdc0
> psm0: [GIANT-LOCKED]
> psm0: [ITHREAD]
> psm0: model MouseMan+, device ID 0
> acpi_aiboost0: <ASUStek AIBOOSTER> on acpi0
> sio0: configured irq 4 not in bitmap of probed irqs 0
> sio0: port may not be enabled
> sio0: configured irq 4 not in bitmap of probed irqs 0
> sio0: port may not be enabled
> sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on
> acpi0
> sio0: type 16550A
> sio0: [FILTER]
> fdc0: <floppy drive controller (FDE)> port 0x3f0-0x3f5,0x3f7 irq 6 drq 2
> on acpi0
> fdc0: [FILTER]
> cpu0: <ACPI CPU> on acpi0
> acpi_throttle0: <ACPI CPU Throttling> on cpu0
> cpu1: <ACPI CPU> on acpi0
> cpu2: <ACPI CPU> on acpi0
> cpu3: <ACPI CPU> on acpi0
> cryptosoft0: <software crypto> on motherboard
> orm0: <ISA Option ROM> at iomem 0xd7800-0xd87ff on isa0
> sc0: <System console> at flags 0x100 on isa0
> sc0: VGA <16 virtual consoles, flags=0x300>
> vga0: <Generic ISA VGA> at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0
> ppc0: cannot reserve I/O port range
> sio1: configured irq 3 not in bitmap of probed irqs 0
> sio1: port may not be enabled
> ulpt0: <Samsung Electronics Co., Ltd. Samsung Laser Printer ML-1200
> Series, class 0/0, rev 1.10/1.00, addr 2> on uhub0
> ulpt0: using bi-directional mode
> WARNING: ZFS is considered to be an experimental feature in FreeBSD.
> Timecounters tick every 1.000 msec
> vboxdrv: fAsync=0 offMin=0x12c offMax=0x219
> hptrr: start channel [0,0]
> hptrr: start channel [0,1]
> hptrr: start channel [0,2]
> hptrr: start channel [0,3]
> hptrr: [0 0] Start channel soft reset.
> hptrr: [0 2] Start channel soft reset.
> hptrr: [0 3] Start channel soft reset.
> hptrr: channel [0,0] started successfully
> hptrr: channel [0,2] started successfully
> hptrr: channel [0,3] started successfully
> hptrr: [0 1] Failed to perform channel hard reset.
> hptrr0: [GIANT-LOCKED]
> hptrr0: [ITHREAD]
> The GEOM class LABEL is already loaded.
> ZFS filesystem version 13
> ZFS storage pool version 13
> da0 at hptrr0 bus 0 target 0 lun 0
> da0: <HPT DISK 0_0 4.00> Fixed Direct Access SCSI-0 device
> da1 at hptrr0 bus 0 target 1 lun 0
> da1: <HPT DISK 0_1 4.00> Fixed Direct Access SCSI-0 device
> da2 at hptrr0 bus 0 target 2 lun 0
> da2: <HPT DISK 0_2 4.00> Fixed Direct Access SCSI-0 device
> acd0: DVDR <HL-DT-ST DVDRAM GSA-4163B/A104> at ata0-master PIO4
> ad4: 476940MB <WDC WD5000AAKS-00C8A0 12.01C02> at ata2-master SATA300
> acd0: FAILURE - INQUIRY ILLEGAL REQUEST asc=0x24 ascq=0x00 sks=0x40 0x00
> 0x01
> (probe0:ata0:0:0:0): TEST UNIT READY. CDB: 0 0 0 0 0 0
> (probe0:ata0:0:0:0): CAM Status: SCSI Status Error
> (probe0:ata0:0:0:0): SCSI Status: Check Condition
> (probe0:ata0:0:0:0): NOT READY csi:0,0,bb,0 asc:3a,0
> (probe0:ata0:0:0:0): Medium not present
> (probe0:ata0:0:0:0): Unretryable error
> cd0 at ata0 bus 0 target 0 lun 0
> cd0: <HL-DT-ST DVDRAM GSA-4163B A104> Removable CD-ROM SCSI-0 device
> cd0: 16.000MB/s transfers
> cd0: Attempt to query device size failed: NOT READY, Medium not present
> ad6: 953869MB <WDC WD10EADS-00L5B1 01.01A01> at ata3-master SATA300
> ad10: 953869MB <WDC WD10EACS-00D6B0 01.01A01> at ata5-master SATA300
> ad12: 476940MB <WDC WD5000AACS-00ZUB0 01.01B01> at ata6-master SATA300
> ad14: 953869MB <Seagate ST31000528AS CC44> at ata7-master SATA300
> hdac0: HDA Codec #0: ATI RS690/780 HDMI
> pcm0: <HDA ATI RS690/780 HDMI PCM #0 Digital> at cad 0 nid 1 on hdac0
> hdac1: HDA Codec #0: VIA VT1708S_0
> pcm1: <HDA VIA VT1708S_0 PCM #0 Analog> at cad 0 nid 1 on hdac1
> pcm2: <HDA VIA VT1708S_0 PCM #1 Digital> at cad 0 nid 1 on hdac1
> pcm3: <HDA VIA VT1708S_0 PCM #2 Digital> at cad 0 nid 1 on hdac1
> SMP: AP CPU #2 Launched!
> SMP: AP CPU #3 Launched!
> SMP: AP CPU #1 Launched!
> Trying to mount root from zfs:rootzfs
> <118>Loading configuration files.
> <118>kernel dumps on /dev/ad4s1b
> <118>Entropy harvesting:
> <118> interrupts
> <118> ethernet
> <118> point_to_point
> <118> kickstart
> <118>.
> GEOM_ELI: Device label/swapB.eli created.
> GEOM_ELI: Encryption: AES-CBC 256
> GEOM_ELI:     Crypto: software
> <118>swapon: adding /dev/label/swapB.eli as swap device
> <118>/etc/rc: WARNING: Use of the early.sh script is deprecated
> <118>/etc/rc: WARNING: Please use a new-style rc.d script instead
> <118>/etc/rc: WARNING: See rc(8) for more information
> <118>gmirror:
> <118>No such device: swap_AB.
> <118>
> <118>Starting file system checks:
> <118>/dev/label/bstrapA: FILE SYSTEM CLEAN; SKIPPING CHECKS
> <118>/dev/label/bstrapA: clean, 303581 free (261 frags, 37915 blocks,
> 0.1% fragmentation)
> <118>/dev/label/bstrapB: FILE SYSTEM CLEAN; SKIPPING CHECKS
> <118>/dev/label/bstrapB: clean, 303502 free (318 frags, 37898 blocks,
> 0.1% fragmentation)
> <118>Setting hostuuid: e039c626-5f54-da11-8e5a-e6b6a8a23cf0.
> <118>Setting hostid: 0xd449202f.
> <118>Mounting local file systems:
> <118>.
>
>
> Fatal trap 12: page fault while in kernel mode
> cpuid = 1; apic id = 01
> fault virtual address    = 0x50
> fault code        = supervisor read data, page not present
> instruction pointer    = 0x8:0xffffffff80ad7a5e
> stack pointer            = 0x10:0xffffff80a5b2f620
> frame pointer            = 0x10:0xffffff80a5b2f6a0
> code segment        = base 0x0, limit 0xfffff, type 0x1b
>            = DPL 0, pres 1, long 1, def32 0, gran 1
> processor eflags    = interrupt enabled, resume, IOPL = 0
> current process        = 314 (txg_thread_enter)
> trap number        = 12
> panic: page fault
> cpuid = 1
> Uptime: 2m11s
> Physical memory: 8050 MB
> Dumping 1553 MB: 1538 1522 1506 1490 1474 1458 1442 1426 1410 1394 1378
> 1362 1346 1330 1314 1298 1282 1266 1250 1234 1218 1202 1186 1170 1154
> 1138 1122 1106 1090 1074 1058 1042 1026 1010 994 978 962 946 930 914 898
> 882 866 850 834 818 802 786 770 754 738 722 706 690 674 658 642 626 610
> 594 578 562 546 530 514 498 482 466 450 434 418 402 386 370 354 338 322
> 306 290 274 258 242 226 210 194 178 162 146 130 114 98 82 66 50 34 18 2
>
> Reading symbols from /boot/kernel/zfs.ko...Reading symbols from
> /bootdirA/boot/kernel/zfs.ko.symbols...done.
> done.
> Loaded symbols for /boot/kernel/zfs.ko
> Reading symbols from /boot/kernel/opensolaris.ko...Reading symbols from
> /bootdirA/boot/kernel/opensolaris.ko.symbols...done.
> done.
> Loaded symbols for /boot/kernel/opensolaris.ko
> Reading symbols from /boot/kernel/geom_eli.ko...Reading symbols from
> /bootdirA/boot/kernel/geom_eli.ko.symbols...done.
> done.
> Loaded symbols for /boot/kernel/geom_eli.ko
> Reading symbols from /boot/kernel/crypto.ko...Reading symbols from
> /bootdirA/boot/kernel/crypto.ko.symbols...done.
> done.
> Loaded symbols for /boot/kernel/crypto.ko
> Reading symbols from /boot/kernel/zlib.ko...Reading symbols from
> /bootdirA/boot/kernel/zlib.ko.symbols...done.
> done.
> Loaded symbols for /boot/kernel/zlib.ko
> Reading symbols from /boot/kernel/geom_label.ko...Reading symbols from
> /bootdirA/boot/kernel/geom_label.ko.symbols...done.
> done.
> Loaded symbols for /boot/kernel/geom_label.ko
> Reading symbols from /boot/kernel/geom_mirror.ko...Reading symbols from
> /bootdirA/boot/kernel/geom_mirror.ko.symbols...done.
> done.
> Loaded symbols for /boot/kernel/geom_mirror.ko
> Reading symbols from /boot/kernel/snd_hda.ko...Reading symbols from
> /bootdirA/boot/kernel/snd_hda.ko.symbols...done.
> done.
> Loaded symbols for /boot/kernel/snd_hda.ko
> Reading symbols from /boot/kernel/sound.ko...Reading symbols from
> /bootdirA/boot/kernel/sound.ko.symbols...done.
> done.
> Loaded symbols for /boot/kernel/sound.ko
> Reading symbols from /boot/kernel/cd9660_iconv.ko...Reading symbols from
> /bootdirA/boot/kernel/cd9660_iconv.ko.symbols...done.
> done.
> Loaded symbols for /boot/kernel/cd9660_iconv.ko
> Reading symbols from /boot/kernel/libiconv.ko...Reading symbols from
> /bootdirA/boot/kernel/libiconv.ko.symbols...done.
> done.
> Loaded symbols for /boot/kernel/libiconv.ko
> Reading symbols from /boot/kernel/aio.ko...Reading symbols from
> /bootdirA/boot/kernel/aio.ko.symbols...done.
> done.
> Loaded symbols for /boot/kernel/aio.ko
> Reading symbols from /boot/modules/vboxdrv.ko...done.
> Loaded symbols for /boot/modules/vboxdrv.ko
> Reading symbols from /boot/kernel/sem.ko...Reading symbols from
> /bootdirA/boot/kernel/sem.ko.symbols...done.
> done.
> Loaded symbols for /boot/kernel/sem.ko
> #0  doadump () at pcpu.h:195
> 195        __asm __volatile("movq %%gs:0,%0" : "=r" (td));
> (kgdb) backtrace
> #0  doadump () at pcpu.h:195
> #1  0x0000000000000004 in ?? ()
> #2  0xffffffff803aab90 in boot (howto=260)
>    at /usr/src/sys/kern/kern_shutdown.c:418
> #3  0xffffffff803aafb2 in panic (fmt=0x104 <Address 0x104 out of bounds>)
>    at /usr/src/sys/kern/kern_shutdown.c:574
> #4  0xffffffff80651d03 in trap_fatal (frame=0xffffff0009572390,
> eva=Variable "eva" is not available.
> )
>    at /usr/src/sys/amd64/amd64/trap.c:770
> #5  0xffffffff806520d5 in trap_pfault (frame=0xffffff80a5b2f570, 
> usermode=0)
>    at /usr/src/sys/amd64/amd64/trap.c:686
> #6  0xffffffff80652a63 in trap (frame=0xffffff80a5b2f570)
>    at /usr/src/sys/amd64/amd64/trap.c:457
> #7  0xffffffff8063cb4e in calltrap ()
>    at /usr/src/sys/amd64/amd64/exception.S:218
> #8  0xffffffff80ad7a5e in find_block (th=0xffffff8006930000,
>    zseg=0xffffff000dafc580, dnp=0xffffff8006d35600, depth=Variable
> "depth" is not available.
> )
>    at
> /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/dmu_traverse.c:400 
>
> #9  0xffffffff80ad81a3 in traverse_more (th=0xffffff8006930000)
>    at
> /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/dmu_traverse.c:672 
>
> #10 0xffffffff80ad8368 in traverse_dsl_dataset (ds=0x23, txg_start=1,
> advance=Variable "advance" is not available.
>
> )
>    at
> /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/d---Type 
>
> <return> to continue, or q <return> to quit---
> mu_traverse.c:731
> #11 0xffffffff80ae41c9 in dsl_dataset_destroy_sync () from
> /boot/kernel/zfs.ko
> #12 0xffffffff80ae6d2a in dsl_sync_task_group_sync
> (dstg=0xffffff000d256600,
>    tx=0xffffff000d1fca80)
>    at
> /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/dsl_synctask.c:186 
>
> #13 0xffffffff80ae6873 in dsl_pool_sync (dp=0xffffff000d521000, 
> txg=3430336)
>    at
> /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/dsl_pool.c:316 
>
> #14 0xffffffff80af59c3 in spa_sync (spa=0xffffff0006d08000, txg=3430336)
>    at
> /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/spa.c:3988 
>
> #15 0xffffffff80afd772 in txg_sync_thread (arg=Variable "arg" is not
> available.
> )
>    at
> /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/txg.c:352 
>
> #16 0xffffffff80385452 in fork_exit (
>    callout=0xffffffff80afd490 <txg_sync_thread>, arg=0xffffff000d521000,
>    frame=0xffffff80a5b2fc80) at /usr/src/sys/kern/kern_fork.c:811
> #17 0xffffffff8063cf2e in fork_trampoline ()
>    at /usr/src/sys/amd64/amd64/exception.S:554
> #18 0x0000000000000000 in ?? ()
> #19 0x0000000000000000 in ?? ()
> #20 0x0000000000000001 in ?? ()
> #21 0x0000000000000000 in ?? ()
> #22 0x0000000000000000 in ?? ()
> #23 0x0000000000000000 in ?? ()
> #24 0x0000000000000000 in ?? ()
> #25 0x0000000000000000 in ?? ()
> #26 0x0000000000000000 in ?? ()
> #27 0x0000000000000000 in ?? ()
> #28 0x0000000000000000 in ?? ()
> #29 0x0000000000000000 in ?? ()
> #30 0x0000000000000000 in ?? ()
> #31 0x0000000000000000 in ?? ()
> #32 0x0000000000000000 in ?? ()
> #33 0x0000000000000000 in ?? ()
> #34 0x0000000000000000 in ?? ()
> #35 0x0000000000000000 in ?? ()
> #36 0x0000000000000000 in ?? ()
> #37 0x0000000000000000 in ?? ()
> #38 0x0000000000000000 in ?? ()
> #39 0x0000000000000000 in ?? ()
> #40 0x0000000000000000 in ?? ()
> #41 0x0000000000000000 in ?? ()
> #42 0x0000000000dde000 in ?? ()
> #43 0xffffffff80950d40 in tdq_cpu ()
> #44 0xffffffff8095c940 in tdq_groups ()
> #45 0xffffffff8095c8c0 in tdq_cpu ()
> #46 0xffffff0009572390 in ?? ()
> #47 0x0000000000000000 in ?? ()
> #48 0xffffff80a5b2f1e8 in ?? ()
> #49 0xffffff0009572390 in ?? ()
> #50 0xffffffff803ce154 in sched_switch (td=0xffffffff80afd490, newtd=0x0,
>    flags=0) at /usr/src/sys/kern/sched_ule.c:1938
> #51 0x0000000000000000 in ?? ()
> #52 0x0000000000000000 in ?? ()
> #53 0x0000000000000000 in ?? ()
> #54 0x0000000000000000 in ?? ()
> #55 0x0000000000000000 in ?? ()
> #56 0x0000000000000000 in ?? ()
> #57 0x0000000000000000 in ?? ()
> #58 0x0000000000000000 in ?? ()
> #59 0x0000000000000000 in ?? ()
> #60 0x0000000000000000 in ?? ()
> #61 0x0000000000000000 in ?? ()
> #62 0x0000000000000000 in ?? ()
> #63 0x0000000000000000 in ?? ()
> #64 0x0000000000000000 in ?? ()
> #65 0x0000000000000000 in ?? ()
> #66 0x0000000000000000 in ?? ()
> #67 0x0000000000000000 in ?? ()
> #68 0x0000000000000000 in ?? ()
> #69 0x0000000000000000 in ?? ()
> #70 0x0000000000000000 in ?? ()
> #71 0x0000000000000000 in ?? ()
> #72 0x0000000000000000 in ?? ()
> #73 0x0000000000000000 in ?? ()
> #74 0x0000000000000000 in ?? ()
> #75 0x0000000000000000 in ?? ()
> #76 0x0000000000000000 in ?? ()
> #77 0x0000000000000000 in ?? ()
> #78 0x0000000000000000 in ?? ()
> #79 0x0000000000000000 in ?? ()
> #80 0x0000000000000000 in ?? ()
> #81 0x0000000000000000 in ?? ()
> #82 0x0000000000000000 in ?? ()
> #83 0x0000000000000000 in ?? ()
> #84 0x0000000000000000 in ?? ()
> #85 0x0000000000000000 in ?? ()
> #86 0x0000000000000000 in ?? ()
> #87 0x0000000000000000 in ?? ()
> #88 0x0000000000000000 in ?? ()
> #89 0x0000000000000000 in ?? ()
> #90 0x0000000000000000 in ?? ()
> #91 0x0000000000000000 in ?? ()
> #92 0x0000000000000000 in ?? ()
> #93 0x0000000000000000 in ?? ()
> #94 0x0000000000000000 in ?? ()
> #95 0x0000000000000000 in ?? ()
> #96 0x0000000000000000 in ?? ()
> #97 0x0000000000000000 in ?? ()
> #98 0x0000000000000000 in ?? ()
> #99 0x0000000000000000 in ?? ()
> #100 0x0000000000000000 in ?? ()
> #101 0x0000000000000000 in ?? ()
> #102 0x0000000000000000 in ?? ()
> #103 0x0000000000000000 in ?? ()
> #104 0x0000000000000000 in ?? ()
> #105 0x0000000000000000 in ?? ()
> #106 0x0000000000000000 in ?? ()
> #107 0x0000000000000000 in ?? ()
> #108 0x0000000000000000 in ?? ()
> #109 0x0000000000000000 in ?? ()
> #110 0x0000000000000000 in ?? ()
> #111 0x0000000000000000 in ?? ()
> #112 0x0000000000000000 in ?? ()
> #113 0x0000000000000000 in ?? ()
> #114 0x0000000000000000 in ?? ()
> #115 0x0000000000000000 in ?? ()
> #116 0x0000000000000000 in ?? ()
> #117 0x0000000000000000 in ?? ()
> #118 0x0000000000000000 in ?? ()
> Cannot access memory at address 0xffffff80a5b30000
> (kgdb) q
> # ^D
> Script done on Fri Sep 11 17:26:02 2009
>
> _______________________________________________
> 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"
Is the hardware in the machine (CPU, motherboard, and memory) confirmed 
to be solid? I ran into a similar situation last month 
(http://lists.freebsd.org/pipermail/freebsd-fs/2009-August/006606.html), 
the root cause of which turned out to be bad memory. ZFS tends to make 
the problem show up more frequently since it uses a lot of memory.

-Boris
From duncan.young at pobox.com  Fri Sep 11 01:56:55 2009
From: duncan.young at pobox.com (Duncan Young)
Date: Fri Sep 11 01:57:04 2009
Subject: zfs woes
In-Reply-To: <4AA98FCA.9090506@acm.poly.edu>
References: <4AA981F4.3090607@pobox.com> <4AA98FCA.9090506@acm.poly.edu>
Message-ID: <4AA9AE61.7060601@pobox.com>

Boris Kochergin wrote:
> Duncan Young wrote:
>> Hi all,
>>
>> Again its happened (my need to restore my main zpool from backups).
>>
>> I have been having regular crashes (only recently been getting crash
>> dumps though), and in the the process
>> of upgrading to 7.1-STABLE, upgrading zpools (now 13) and zfs (now 3), I
>> now have a problem with
>> my main data zpool.
>>
>> I was having these problems before the upgrade.
>>
>> After zpool status saying that I had corrupted files (actually a zfs
>> filesystem), I tried destroying it (the zfs filesystem), in the hope
>> that this
>> may make my problems go away).  The machine hung.
>>
>> zpool scrub works, reporting 16 errors.
>> zpool status -v crashes.
>> starting multiuser hangs (probably on mounting the dud fs).
>> I can start single user, and I am currently additional backups of the
>> filesytems I can access (most off the corrupted zpool).
>> Any accessing the corrupted zfs filesystem crashes the machine.
>>
>> Now I think it's fair enough that the filesystem is corrupted (I still
>> see a need for some type of fsck), but I don't see that the
>> machine should crash because of it. Any sugestions?
>>
>> Script started on Fri Sep 11 17:22:23 2009
>> # uname -a
>> FreeBSD  7.2-STABLE FreeBSD 7.2-STABLE #8: Fri Sep 11 04:14:39 EST
>> 2009     root@:/usr/obj/usr/src/sys/TRIPLE0  amd64
>> # cd /usr/src/sys/TRIPLE0
>> # kgdb ./kernel.debug /var/crash/vmcore/.25
>> GNU gdb 6.1.1 [FreeBSD]
>> Copyright 2004 Free Software Foundation, Inc.
>> GDB is free software, covered by the GNU General Public License, and 
>> you are
>> welcome to change it and/or distribute copies of it under certain
>> conditions.
>> Type "show copying" to see the conditions.
>> There is absolutely no warranty for GDB.  Type "show warranty" for 
>> details.
>> This GDB was configured as "amd64-marcel-freebsd"...
>>
>> Unread portion of the kernel message buffer:
>> Copyright (c) 1992-2009 The FreeBSD Project.
>> Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
>>    The Regents of the University of California. All rights reserved.
>> FreeBSD is a registered trademark of The FreeBSD Foundation.
>> FreeBSD 7.2-STABLE #8: Fri Sep 11 04:14:39 EST 2009
>>    root@:/usr/obj/usr/src/sys/TRIPLE0
>> module_register: module g_label already exists!
>> Module g_label failed to register: 17
>> Timecounter "i8254" frequency 1193182 Hz quality 0
>> CPU: AMD Phenom(tm) II X4 810 Processor (2608.81-MHz K8-class CPU)
>>  Origin = "AuthenticAMD"  Id = 0x100f42  Stepping = 2
>>
>> Features=0x178bfbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,MMX,FXSR,SSE,SSE2,HTT> 
>>
>>  Features2=0x802009<SSE3,MON,CX16,POPCNT>
>>  AMD
>> Features=0xee500800<SYSCALL,NX,MMX+,FFXSR,Page1GB,RDTSCP,LM,3DNow!+,3DNow!> 
>>
>>  AMD
>> Features2=0x37ff<LAHF,CMP,SVM,ExtAPIC,CR8,ABM,SSE4A,MAS,Prefetch,OSVW,IBS,SKINIT,WDT> 
>>
>>  TSC: P-state invariant
>>  Cores per package: 4
>> usable memory = 8441266176 (8050 MB)
>> avail memory  = 8131702784 (7754 MB)
>> ACPI APIC Table: <072709 APIC1045>
>> FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs
>> cpu0 (BSP): APIC ID:  0
>> cpu1 (AP): APIC ID:  1
>> cpu2 (AP): APIC ID:  2
>> cpu3 (AP): APIC ID:  3
>> This module (opensolaris) contains code covered by the
>> Common Development and Distribution License (CDDL)
>> see http://opensolaris.org/os/licensing/opensolaris_license/
>> ACPI Warning (tbfadt-0505): Optional field "Pm2ControlBlock" has zero
>> address or length:        0       0/1 [20070320]
>> ioapic0 <Version 2.1> irqs 0-23 on motherboard
>> kbd1 at kbdmux0
>> acpi0: <072709 XSDT1045> on motherboard
>> acpi0: [ITHREAD]
>> acpi0: Power Button (fixed)
>> acpi0: reservation of fee00000, 1000 (3) failed
>> acpi0: reservation of ffb80000, 80000 (3) failed
>> acpi0: reservation of fec10000, 20 (3) failed
>> acpi0: reservation of 0, a0000 (3) failed
>> acpi0: reservation of 100000, dff00000 (3) failed
>> ACPI HPET table warning: Sequence is non-zero (2)
>> Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000
>> acpi_timer0: <32-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0
>> acpi_hpet0: <High Precision Event Timer> iomem 0xfed00000-0xfed003ff on
>> acpi0
>> Timecounter "HPET" frequency 14318180 Hz quality 900
>> pcib0: <ACPI Host-PCI bridge> port 0xcf8-0xcff on acpi0
>> pci0: <ACPI PCI bus> on pcib0
>> pcib1: <ACPI PCI-PCI bridge> at device 1.0 on pci0
>> pci1: <ACPI PCI bus> on pcib1
>> vgapci0: <VGA-compatible display> port 0xc000-0xc0ff mem
>> 0xf0000000-0xf7ffffff,0xfbce0000-0xfbceffff,0xfbb00000-0xfbbfffff irq 18
>> at device 5.0 on pci1
>> hdac0: <ATI RS780 High Definition Audio Controller> mem
>> 0xfbcfc000-0xfbcfffff irq 19 at device 5.1 on pci1
>> hdac0: HDA Driver Revision: 20090624_0136
>> hdac0: [ITHREAD]
>> pcib2: <ACPI PCI-PCI bridge> irq 16 at device 4.0 on pci0
>> pci2: <ACPI PCI bus> on pcib2
>> hptrr0: <sx508x> port 0xd800-0xd8ff mem 0xfbe00000-0xfbefffff irq 16 at
>> device 0.0 on pci2
>> hptrr: adapter at PCI 2:0:0, IRQ 16
>> pcib3: <ACPI PCI-PCI bridge> irq 17 at device 5.0 on pci0
>> pci3: <ACPI PCI bus> on pcib3
>> em0: <Intel(R) PRO/1000 Network Connection 6.9.6> port 0xec00-0xec1f mem
>> 0xfbfe0000-0xfbffffff,0xfbf00000-0xfbf7ffff,0xfbfdc000-0xfbfdffff irq 17
>> at device 0.0 on pci3
>> em0: Using MSIX interrupts
>> em0: [ITHREAD]
>> em0: [ITHREAD]
>> em0: [ITHREAD]
>> em0: Ethernet address: 00:1b:21:3d:eb:e7
>> atapci0: <ATI AHCI controller> port
>> 0xb000-0xb007,0xa000-0xa003,0x9000-0x9007,0x8000-0x8003,0x7000-0x700f
>> mem 0xfbaffc00-0xfbafffff irq 22 at device 17.0 on pci0
>> atapci0: [ITHREAD]
>> atapci0: AHCI Version 01.10 controller with 6 ports detected
>> ata2: <ATA channel 0> on atapci0
>> ata2: [ITHREAD]
>> ata3: <ATA channel 1> on atapci0
>> ata3: [ITHREAD]
>> ata4: <ATA channel 2> on atapci0
>> ata4: [ITHREAD]
>> ata5: <ATA channel 3> on atapci0
>> ata5: [ITHREAD]
>> ata6: <ATA channel 4> on atapci0
>> ata6: [ITHREAD]
>> ata7: <ATA channel 5> on atapci0
>> ata7: [ITHREAD]
>> ohci0: <OHCI (generic) USB controller> mem 0xfbafd000-0xfbafdfff irq 16
>> at device 18.0 on pci0
>> ohci0: [GIANT-LOCKED]
>> ohci0: [ITHREAD]
>> usb0: OHCI version 1.0, legacy support
>> usb0: <OHCI (generic) USB controller> on ohci0
>> usb0: USB revision 1.0
>> uhub0: <ATI OHCI root hub, class 9/0, rev 1.00/1.00, addr 1> on usb0
>> uhub0: 3 ports with 3 removable, self powered
>> ohci1: <OHCI (generic) USB controller> mem 0xfbafe000-0xfbafefff irq 16
>> at device 18.1 on pci0
>> ohci1: [GIANT-LOCKED]
>> ohci1: [ITHREAD]
>> usb1: OHCI version 1.0, legacy support
>> usb1: <OHCI (generic) USB controller> on ohci1
>> usb1: USB revision 1.0
>> uhub1: <ATI OHCI root hub, class 9/0, rev 1.00/1.00, addr 1> on usb1
>> uhub1: 3 ports with 3 removable, self powered
>> ehci0: <EHCI (generic) USB 2.0 controller> mem 0xfbaff800-0xfbaff8ff irq
>> 17 at device 18.2 on pci0
>> ehci0: [GIANT-LOCKED]
>> ehci0: [ITHREAD]
>> usb2: EHCI version 1.0
>> usb2: companion controllers, 3 ports each: usb0 usb1
>> usb2: <EHCI (generic) USB 2.0 controller> on ehci0
>> usb2: USB revision 2.0
>> uhub2: <ATI EHCI root hub, class 9/0, rev 2.00/1.00, addr 1> on usb2
>> uhub2: 6 ports with 6 removable, self powered
>> ohci2: <OHCI (generic) USB controller> mem 0xfbafb000-0xfbafbfff irq 18
>> at device 19.0 on pci0
>> ohci2: [GIANT-LOCKED]
>> ohci2: [ITHREAD]
>> usb3: OHCI version 1.0, legacy support
>> usb3: <OHCI (generic) USB controller> on ohci2
>> usb3: USB revision 1.0
>> uhub3: <ATI OHCI root hub, class 9/0, rev 1.00/1.00, addr 1> on usb3
>> uhub3: 3 ports with 3 removable, self powered
>> ohci3: <OHCI (generic) USB controller> mem 0xfbafc000-0xfbafcfff irq 18
>> at device 19.1 on pci0
>> ohci3: [GIANT-LOCKED]
>> ohci3: [ITHREAD]
>> usb4: OHCI version 1.0, legacy support
>> usb4: <OHCI (generic) USB controller> on ohci3
>> usb4: USB revision 1.0
>> uhub4: <ATI OHCI root hub, class 9/0, rev 1.00/1.00, addr 1> on usb4
>> uhub4: 3 ports with 3 removable, self powered
>> ehci1: <EHCI (generic) USB 2.0 controller> mem 0xfbaff400-0xfbaff4ff irq
>> 19 at device 19.2 on pci0
>> ehci1: [GIANT-LOCKED]
>> ehci1: [ITHREAD]
>> usb5: EHCI version 1.0
>> usb5: companion controllers, 3 ports each: usb3 usb4
>> usb5: <EHCI (generic) USB 2.0 controller> on ehci1
>> usb5: USB revision 2.0
>> uhub5: <ATI EHCI root hub, class 9/0, rev 2.00/1.00, addr 1> on usb5
>> uhub5: 6 ports with 6 removable, self powered
>> pci0: <serial bus, SMBus> at device 20.0 (no driver attached)
>> atapci1: <ATI IXP700 UDMA133 controller> port
>> 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xff00-0xff0f at device 20.1 on pci0
>> ata0: <ATA channel 0> on atapci1
>> ata0: [ITHREAD]
>> hdac1: <ATI SB600 High Definition Audio Controller> mem
>> 0xfbaf4000-0xfbaf7fff irq 16 at device 20.2 on pci0
>> hdac1: HDA Driver Revision: 20090624_0136
>> hdac1: [ITHREAD]
>> isab0: <PCI-ISA bridge> at device 20.3 on pci0
>> isa0: <ISA bus> on isab0
>> pcib4: <ACPI PCI-PCI bridge> at device 20.4 on pci0
>> pci4: <ACPI PCI bus> on pcib4
>> ohci4: <OHCI (generic) USB controller> mem 0xfbafa000-0xfbafafff irq 18
>> at device 20.5 on pci0
>> ohci4: [GIANT-LOCKED]
>> ohci4: [ITHREAD]
>> usb6: OHCI version 1.0, legacy support
>> usb6: <OHCI (generic) USB controller> on ohci4
>> usb6: USB revision 1.0
>> uhub6: <ATI OHCI root hub, class 9/0, rev 1.00/1.00, addr 1> on usb6
>> uhub6: 2 ports with 2 removable, self powered
>> acpi_button0: <Power Button> on acpi0
>> atkbdc0: <Keyboard controller (i8042)> port 0x60,0x64 irq 1 on acpi0
>> atkbd0: <AT Keyboard> irq 1 on atkbdc0
>> kbd0 at atkbd0
>> atkbd0: [GIANT-LOCKED]
>> atkbd0: [ITHREAD]
>> psm0: <PS/2 Mouse> irq 12 on atkbdc0
>> psm0: [GIANT-LOCKED]
>> psm0: [ITHREAD]
>> psm0: model MouseMan+, device ID 0
>> acpi_aiboost0: <ASUStek AIBOOSTER> on acpi0
>> sio0: configured irq 4 not in bitmap of probed irqs 0
>> sio0: port may not be enabled
>> sio0: configured irq 4 not in bitmap of probed irqs 0
>> sio0: port may not be enabled
>> sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on
>> acpi0
>> sio0: type 16550A
>> sio0: [FILTER]
>> fdc0: <floppy drive controller (FDE)> port 0x3f0-0x3f5,0x3f7 irq 6 drq 2
>> on acpi0
>> fdc0: [FILTER]
>> cpu0: <ACPI CPU> on acpi0
>> acpi_throttle0: <ACPI CPU Throttling> on cpu0
>> cpu1: <ACPI CPU> on acpi0
>> cpu2: <ACPI CPU> on acpi0
>> cpu3: <ACPI CPU> on acpi0
>> cryptosoft0: <software crypto> on motherboard
>> orm0: <ISA Option ROM> at iomem 0xd7800-0xd87ff on isa0
>> sc0: <System console> at flags 0x100 on isa0
>> sc0: VGA <16 virtual consoles, flags=0x300>
>> vga0: <Generic ISA VGA> at port 0x3c0-0x3df iomem 0xa0000-0xbffff on 
>> isa0
>> ppc0: cannot reserve I/O port range
>> sio1: configured irq 3 not in bitmap of probed irqs 0
>> sio1: port may not be enabled
>> ulpt0: <Samsung Electronics Co., Ltd. Samsung Laser Printer ML-1200
>> Series, class 0/0, rev 1.10/1.00, addr 2> on uhub0
>> ulpt0: using bi-directional mode
>> WARNING: ZFS is considered to be an experimental feature in FreeBSD.
>> Timecounters tick every 1.000 msec
>> vboxdrv: fAsync=0 offMin=0x12c offMax=0x219
>> hptrr: start channel [0,0]
>> hptrr: start channel [0,1]
>> hptrr: start channel [0,2]
>> hptrr: start channel [0,3]
>> hptrr: [0 0] Start channel soft reset.
>> hptrr: [0 2] Start channel soft reset.
>> hptrr: [0 3] Start channel soft reset.
>> hptrr: channel [0,0] started successfully
>> hptrr: channel [0,2] started successfully
>> hptrr: channel [0,3] started successfully
>> hptrr: [0 1] Failed to perform channel hard reset.
>> hptrr0: [GIANT-LOCKED]
>> hptrr0: [ITHREAD]
>> The GEOM class LABEL is already loaded.
>> ZFS filesystem version 13
>> ZFS storage pool version 13
>> da0 at hptrr0 bus 0 target 0 lun 0
>> da0: <HPT DISK 0_0 4.00> Fixed Direct Access SCSI-0 device
>> da1 at hptrr0 bus 0 target 1 lun 0
>> da1: <HPT DISK 0_1 4.00> Fixed Direct Access SCSI-0 device
>> da2 at hptrr0 bus 0 target 2 lun 0
>> da2: <HPT DISK 0_2 4.00> Fixed Direct Access SCSI-0 device
>> acd0: DVDR <HL-DT-ST DVDRAM GSA-4163B/A104> at ata0-master PIO4
>> ad4: 476940MB <WDC WD5000AAKS-00C8A0 12.01C02> at ata2-master SATA300
>> acd0: FAILURE - INQUIRY ILLEGAL REQUEST asc=0x24 ascq=0x00 sks=0x40 0x00
>> 0x01
>> (probe0:ata0:0:0:0): TEST UNIT READY. CDB: 0 0 0 0 0 0
>> (probe0:ata0:0:0:0): CAM Status: SCSI Status Error
>> (probe0:ata0:0:0:0): SCSI Status: Check Condition
>> (probe0:ata0:0:0:0): NOT READY csi:0,0,bb,0 asc:3a,0
>> (probe0:ata0:0:0:0): Medium not present
>> (probe0:ata0:0:0:0): Unretryable error
>> cd0 at ata0 bus 0 target 0 lun 0
>> cd0: <HL-DT-ST DVDRAM GSA-4163B A104> Removable CD-ROM SCSI-0 device
>> cd0: 16.000MB/s transfers
>> cd0: Attempt to query device size failed: NOT READY, Medium not present
>> ad6: 953869MB <WDC WD10EADS-00L5B1 01.01A01> at ata3-master SATA300
>> ad10: 953869MB <WDC WD10EACS-00D6B0 01.01A01> at ata5-master SATA300
>> ad12: 476940MB <WDC WD5000AACS-00ZUB0 01.01B01> at ata6-master SATA300
>> ad14: 953869MB <Seagate ST31000528AS CC44> at ata7-master SATA300
>> hdac0: HDA Codec #0: ATI RS690/780 HDMI
>> pcm0: <HDA ATI RS690/780 HDMI PCM #0 Digital> at cad 0 nid 1 on hdac0
>> hdac1: HDA Codec #0: VIA VT1708S_0
>> pcm1: <HDA VIA VT1708S_0 PCM #0 Analog> at cad 0 nid 1 on hdac1
>> pcm2: <HDA VIA VT1708S_0 PCM #1 Digital> at cad 0 nid 1 on hdac1
>> pcm3: <HDA VIA VT1708S_0 PCM #2 Digital> at cad 0 nid 1 on hdac1
>> SMP: AP CPU #2 Launched!
>> SMP: AP CPU #3 Launched!
>> SMP: AP CPU #1 Launched!
>> Trying to mount root from zfs:rootzfs
>> <118>Loading configuration files.
>> <118>kernel dumps on /dev/ad4s1b
>> <118>Entropy harvesting:
>> <118> interrupts
>> <118> ethernet
>> <118> point_to_point
>> <118> kickstart
>> <118>.
>> GEOM_ELI: Device label/swapB.eli created.
>> GEOM_ELI: Encryption: AES-CBC 256
>> GEOM_ELI:     Crypto: software
>> <118>swapon: adding /dev/label/swapB.eli as swap device
>> <118>/etc/rc: WARNING: Use of the early.sh script is deprecated
>> <118>/etc/rc: WARNING: Please use a new-style rc.d script instead
>> <118>/etc/rc: WARNING: See rc(8) for more information
>> <118>gmirror:
>> <118>No such device: swap_AB.
>> <118>
>> <118>Starting file system checks:
>> <118>/dev/label/bstrapA: FILE SYSTEM CLEAN; SKIPPING CHECKS
>> <118>/dev/label/bstrapA: clean, 303581 free (261 frags, 37915 blocks,
>> 0.1% fragmentation)
>> <118>/dev/label/bstrapB: FILE SYSTEM CLEAN; SKIPPING CHECKS
>> <118>/dev/label/bstrapB: clean, 303502 free (318 frags, 37898 blocks,
>> 0.1% fragmentation)
>> <118>Setting hostuuid: e039c626-5f54-da11-8e5a-e6b6a8a23cf0.
>> <118>Setting hostid: 0xd449202f.
>> <118>Mounting local file systems:
>> <118>.
>>
>>
>> Fatal trap 12: page fault while in kernel mode
>> cpuid = 1; apic id = 01
>> fault virtual address    = 0x50
>> fault code        = supervisor read data, page not present
>> instruction pointer    = 0x8:0xffffffff80ad7a5e
>> stack pointer            = 0x10:0xffffff80a5b2f620
>> frame pointer            = 0x10:0xffffff80a5b2f6a0
>> code segment        = base 0x0, limit 0xfffff, type 0x1b
>>            = DPL 0, pres 1, long 1, def32 0, gran 1
>> processor eflags    = interrupt enabled, resume, IOPL = 0
>> current process        = 314 (txg_thread_enter)
>> trap number        = 12
>> panic: page fault
>> cpuid = 1
>> Uptime: 2m11s
>> Physical memory: 8050 MB
>> Dumping 1553 MB: 1538 1522 1506 1490 1474 1458 1442 1426 1410 1394 1378
>> 1362 1346 1330 1314 1298 1282 1266 1250 1234 1218 1202 1186 1170 1154
>> 1138 1122 1106 1090 1074 1058 1042 1026 1010 994 978 962 946 930 914 898
>> 882 866 850 834 818 802 786 770 754 738 722 706 690 674 658 642 626 610
>> 594 578 562 546 530 514 498 482 466 450 434 418 402 386 370 354 338 322
>> 306 290 274 258 242 226 210 194 178 162 146 130 114 98 82 66 50 34 18 2
>>
>> Reading symbols from /boot/kernel/zfs.ko...Reading symbols from
>> /bootdirA/boot/kernel/zfs.ko.symbols...done.
>> done.
>> Loaded symbols for /boot/kernel/zfs.ko
>> Reading symbols from /boot/kernel/opensolaris.ko...Reading symbols from
>> /bootdirA/boot/kernel/opensolaris.ko.symbols...done.
>> done.
>> Loaded symbols for /boot/kernel/opensolaris.ko
>> Reading symbols from /boot/kernel/geom_eli.ko...Reading symbols from
>> /bootdirA/boot/kernel/geom_eli.ko.symbols...done.
>> done.
>> Loaded symbols for /boot/kernel/geom_eli.ko
>> Reading symbols from /boot/kernel/crypto.ko...Reading symbols from
>> /bootdirA/boot/kernel/crypto.ko.symbols...done.
>> done.
>> Loaded symbols for /boot/kernel/crypto.ko
>> Reading symbols from /boot/kernel/zlib.ko...Reading symbols from
>> /bootdirA/boot/kernel/zlib.ko.symbols...done.
>> done.
>> Loaded symbols for /boot/kernel/zlib.ko
>> Reading symbols from /boot/kernel/geom_label.ko...Reading symbols from
>> /bootdirA/boot/kernel/geom_label.ko.symbols...done.
>> done.
>> Loaded symbols for /boot/kernel/geom_label.ko
>> Reading symbols from /boot/kernel/geom_mirror.ko...Reading symbols from
>> /bootdirA/boot/kernel/geom_mirror.ko.symbols...done.
>> done.
>> Loaded symbols for /boot/kernel/geom_mirror.ko
>> Reading symbols from /boot/kernel/snd_hda.ko...Reading symbols from
>> /bootdirA/boot/kernel/snd_hda.ko.symbols...done.
>> done.
>> Loaded symbols for /boot/kernel/snd_hda.ko
>> Reading symbols from /boot/kernel/sound.ko...Reading symbols from
>> /bootdirA/boot/kernel/sound.ko.symbols...done.
>> done.
>> Loaded symbols for /boot/kernel/sound.ko
>> Reading symbols from /boot/kernel/cd9660_iconv.ko...Reading symbols from
>> /bootdirA/boot/kernel/cd9660_iconv.ko.symbols...done.
>> done.
>> Loaded symbols for /boot/kernel/cd9660_iconv.ko
>> Reading symbols from /boot/kernel/libiconv.ko...Reading symbols from
>> /bootdirA/boot/kernel/libiconv.ko.symbols...done.
>> done.
>> Loaded symbols for /boot/kernel/libiconv.ko
>> Reading symbols from /boot/kernel/aio.ko...Reading symbols from
>> /bootdirA/boot/kernel/aio.ko.symbols...done.
>> done.
>> Loaded symbols for /boot/kernel/aio.ko
>> Reading symbols from /boot/modules/vboxdrv.ko...done.
>> Loaded symbols for /boot/modules/vboxdrv.ko
>> Reading symbols from /boot/kernel/sem.ko...Reading symbols from
>> /bootdirA/boot/kernel/sem.ko.symbols...done.
>> done.
>> Loaded symbols for /boot/kernel/sem.ko
>> #0  doadump () at pcpu.h:195
>> 195        __asm __volatile("movq %%gs:0,%0" : "=r" (td));
>> (kgdb) backtrace
>> #0  doadump () at pcpu.h:195
>> #1  0x0000000000000004 in ?? ()
>> #2  0xffffffff803aab90 in boot (howto=260)
>>    at /usr/src/sys/kern/kern_shutdown.c:418
>> #3  0xffffffff803aafb2 in panic (fmt=0x104 <Address 0x104 out of 
>> bounds>)
>>    at /usr/src/sys/kern/kern_shutdown.c:574
>> #4  0xffffffff80651d03 in trap_fatal (frame=0xffffff0009572390,
>> eva=Variable "eva" is not available.
>> )
>>    at /usr/src/sys/amd64/amd64/trap.c:770
>> #5  0xffffffff806520d5 in trap_pfault (frame=0xffffff80a5b2f570, 
>> usermode=0)
>>    at /usr/src/sys/amd64/amd64/trap.c:686
>> #6  0xffffffff80652a63 in trap (frame=0xffffff80a5b2f570)
>>    at /usr/src/sys/amd64/amd64/trap.c:457
>> #7  0xffffffff8063cb4e in calltrap ()
>>    at /usr/src/sys/amd64/amd64/exception.S:218
>> #8  0xffffffff80ad7a5e in find_block (th=0xffffff8006930000,
>>    zseg=0xffffff000dafc580, dnp=0xffffff8006d35600, depth=Variable
>> "depth" is not available.
>> )
>>    at
>> /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/dmu_traverse.c:400 
>>
>> #9  0xffffffff80ad81a3 in traverse_more (th=0xffffff8006930000)
>>    at
>> /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/dmu_traverse.c:672 
>>
>> #10 0xffffffff80ad8368 in traverse_dsl_dataset (ds=0x23, txg_start=1,
>> advance=Variable "advance" is not available.
>>
>> )
>>    at
>> /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/d---Type 
>>
>> <return> to continue, or q <return> to quit---
>> mu_traverse.c:731
>> #11 0xffffffff80ae41c9 in dsl_dataset_destroy_sync () from
>> /boot/kernel/zfs.ko
>> #12 0xffffffff80ae6d2a in dsl_sync_task_group_sync
>> (dstg=0xffffff000d256600,
>>    tx=0xffffff000d1fca80)
>>    at
>> /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/dsl_synctask.c:186 
>>
>> #13 0xffffffff80ae6873 in dsl_pool_sync (dp=0xffffff000d521000, 
>> txg=3430336)
>>    at
>> /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/dsl_pool.c:316 
>>
>> #14 0xffffffff80af59c3 in spa_sync (spa=0xffffff0006d08000, txg=3430336)
>>    at
>> /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/spa.c:3988 
>>
>> #15 0xffffffff80afd772 in txg_sync_thread (arg=Variable "arg" is not
>> available.
>> )
>>    at
>> /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/txg.c:352 
>>
>> #16 0xffffffff80385452 in fork_exit (
>>    callout=0xffffffff80afd490 <txg_sync_thread>, arg=0xffffff000d521000,
>>    frame=0xffffff80a5b2fc80) at /usr/src/sys/kern/kern_fork.c:811
>> #17 0xffffffff8063cf2e in fork_trampoline ()
>>    at /usr/src/sys/amd64/amd64/exception.S:554
>> #18 0x0000000000000000 in ?? ()
>> #19 0x0000000000000000 in ?? ()
>> #20 0x0000000000000001 in ?? ()
>> #21 0x0000000000000000 in ?? ()
>> #22 0x0000000000000000 in ?? ()
>> #23 0x0000000000000000 in ?? ()
>> #24 0x0000000000000000 in ?? ()
>> #25 0x0000000000000000 in ?? ()
>> #26 0x0000000000000000 in ?? ()
>> #27 0x0000000000000000 in ?? ()
>> #28 0x0000000000000000 in ?? ()
>> #29 0x0000000000000000 in ?? ()
>> #30 0x0000000000000000 in ?? ()
>> #31 0x0000000000000000 in ?? ()
>> #32 0x0000000000000000 in ?? ()
>> #33 0x0000000000000000 in ?? ()
>> #34 0x0000000000000000 in ?? ()
>> #35 0x0000000000000000 in ?? ()
>> #36 0x0000000000000000 in ?? ()
>> #37 0x0000000000000000 in ?? ()
>> #38 0x0000000000000000 in ?? ()
>> #39 0x0000000000000000 in ?? ()
>> #40 0x0000000000000000 in ?? ()
>> #41 0x0000000000000000 in ?? ()
>> #42 0x0000000000dde000 in ?? ()
>> #43 0xffffffff80950d40 in tdq_cpu ()
>> #44 0xffffffff8095c940 in tdq_groups ()
>> #45 0xffffffff8095c8c0 in tdq_cpu ()
>> #46 0xffffff0009572390 in ?? ()
>> #47 0x0000000000000000 in ?? ()
>> #48 0xffffff80a5b2f1e8 in ?? ()
>> #49 0xffffff0009572390 in ?? ()
>> #50 0xffffffff803ce154 in sched_switch (td=0xffffffff80afd490, 
>> newtd=0x0,
>>    flags=0) at /usr/src/sys/kern/sched_ule.c:1938
>> #51 0x0000000000000000 in ?? ()
>> #52 0x0000000000000000 in ?? ()
>> #53 0x0000000000000000 in ?? ()
>> #54 0x0000000000000000 in ?? ()
>> #55 0x0000000000000000 in ?? ()
>> #56 0x0000000000000000 in ?? ()
>> #57 0x0000000000000000 in ?? ()
>> #58 0x0000000000000000 in ?? ()
>> #59 0x0000000000000000 in ?? ()
>> #60 0x0000000000000000 in ?? ()
>> #61 0x0000000000000000 in ?? ()
>> #62 0x0000000000000000 in ?? ()
>> #63 0x0000000000000000 in ?? ()
>> #64 0x0000000000000000 in ?? ()
>> #65 0x0000000000000000 in ?? ()
>> #66 0x0000000000000000 in ?? ()
>> #67 0x0000000000000000 in ?? ()
>> #68 0x0000000000000000 in ?? ()
>> #69 0x0000000000000000 in ?? ()
>> #70 0x0000000000000000 in ?? ()
>> #71 0x0000000000000000 in ?? ()
>> #72 0x0000000000000000 in ?? ()
>> #73 0x0000000000000000 in ?? ()
>> #74 0x0000000000000000 in ?? ()
>> #75 0x0000000000000000 in ?? ()
>> #76 0x0000000000000000 in ?? ()
>> #77 0x0000000000000000 in ?? ()
>> #78 0x0000000000000000 in ?? ()
>> #79 0x0000000000000000 in ?? ()
>> #80 0x0000000000000000 in ?? ()
>> #81 0x0000000000000000 in ?? ()
>> #82 0x0000000000000000 in ?? ()
>> #83 0x0000000000000000 in ?? ()
>> #84 0x0000000000000000 in ?? ()
>> #85 0x0000000000000000 in ?? ()
>> #86 0x0000000000000000 in ?? ()
>> #87 0x0000000000000000 in ?? ()
>> #88 0x0000000000000000 in ?? ()
>> #89 0x0000000000000000 in ?? ()
>> #90 0x0000000000000000 in ?? ()
>> #91 0x0000000000000000 in ?? ()
>> #92 0x0000000000000000 in ?? ()
>> #93 0x0000000000000000 in ?? ()
>> #94 0x0000000000000000 in ?? ()
>> #95 0x0000000000000000 in ?? ()
>> #96 0x0000000000000000 in ?? ()
>> #97 0x0000000000000000 in ?? ()
>> #98 0x0000000000000000 in ?? ()
>> #99 0x0000000000000000 in ?? ()
>> #100 0x0000000000000000 in ?? ()
>> #101 0x0000000000000000 in ?? ()
>> #102 0x0000000000000000 in ?? ()
>> #103 0x0000000000000000 in ?? ()
>> #104 0x0000000000000000 in ?? ()
>> #105 0x0000000000000000 in ?? ()
>> #106 0x0000000000000000 in ?? ()
>> #107 0x0000000000000000 in ?? ()
>> #108 0x0000000000000000 in ?? ()
>> #109 0x0000000000000000 in ?? ()
>> #110 0x0000000000000000 in ?? ()
>> #111 0x0000000000000000 in ?? ()
>> #112 0x0000000000000000 in ?? ()
>> #113 0x0000000000000000 in ?? ()
>> #114 0x0000000000000000 in ?? ()
>> #115 0x0000000000000000 in ?? ()
>> #116 0x0000000000000000 in ?? ()
>> #117 0x0000000000000000 in ?? ()
>> #118 0x0000000000000000 in ?? ()
>> Cannot access memory at address 0xffffff80a5b30000
>> (kgdb) q
>> # ^D
>> Script done on Fri Sep 11 17:26:02 2009
>>
>> _______________________________________________
>> 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"
> Is the hardware in the machine (CPU, motherboard, and memory) 
> confirmed to be solid? I ran into a similar situation last month 
> (http://lists.freebsd.org/pipermail/freebsd-fs/2009-August/006606.html), 
> the root cause of which turned out to be bad memory. ZFS tends to make 
> the problem show up more frequently since it uses a lot of memory.
>
> -Boris
I believe the memory to be fine.  I ran memtest across it and found no 
errors.  Its also ECC memory (which I have switched on), so much less 
likely to have errors showing up.

Duncan
From fulanpeng at gmail.com  Fri Sep 11 04:58:26 2009
From: fulanpeng at gmail.com (fulan Peng)
Date: Fri Sep 11 04:58:32 2009
Subject: How to make sysctl.conf effect?
Message-ID: <bf0f1bc90909102158j4356206cqbdccc03a69986fe2@mail.gmail.com>

I am sorry if this is not the right place to ask this question.
I am using freebsd amd64 7.2.
I cannot make more than 32768 directories in a folder. So I edited
/etc/sysctl.conf and added a line
vfs_ufs_dirhash_maxmem=67108864
when I do sysctl -a |grep mem, I saw the setting was correct.
But when I went into a directory and try to make more than 32768
subdirectories, it always was told me too many links. I have rebooted
many, many times. I even powered of the computer several times. I have
6G memory in the computer. And I even recompiled the kernel once. All
failed.
Could you please help me to give me some hints to activate the
/etc/sysctl.conf file.
Thanks a lot!

Fulan Peng
From dnelson at allantgroup.com  Fri Sep 11 06:30:58 2009
From: dnelson at allantgroup.com (Dan Nelson)
Date: Fri Sep 11 06:31:05 2009
Subject: How to make sysctl.conf effect?
In-Reply-To: <bf0f1bc90909102158j4356206cqbdccc03a69986fe2@mail.gmail.com>
References: <bf0f1bc90909102158j4356206cqbdccc03a69986fe2@mail.gmail.com>
Message-ID: <20090911063055.GC37884@dan.emsphone.com>

In the last episode (Sep 11), fulan Peng said:
> I am sorry if this is not the right place to ask this question.
> I am using freebsd amd64 7.2.
> I cannot make more than 32768 directories in a folder. So I edited
> /etc/sysctl.conf and added a line
> vfs_ufs_dirhash_maxmem=67108864
> when I do sysctl -a |grep mem, I saw the setting was correct.
> But when I went into a directory and try to make more than 32768
> subdirectories, it always was told me too many links. I have rebooted
> many, many times. I even powered of the computer several times. I have
> 6G memory in the computer. And I even recompiled the kernel once. All
> failed.

dirhash is simply a speed optimization for large directories.  It doesn't
set a hard limit of any sort.  

Your problem is that you are using the UFS filesystem, which does not allow
more than 32768 subdirectories.  The "number of links" counter in UFS
filesystems is a signed short type, and each subdirectory has to create a
".." link back to the parent directory, so if you try to create more than
32768 subdirectories, it fails because the parent directory would exceed the
maximum link count.

You'll need to either create multiple levels of directories (i.e.  make
directories called 345/678/ instead of 345678/ ), or switch to the zfs
filesystem, which has a much higher limit.  I was able to create 1 million
subdirs as a test, using zsh's brace expansion syntax to generate the
directory names:

(dan@dan) / # zfs create -o mountpoint=/tmp/zz local/zz
(dan@dan) / # cd /tmp/zz
(dan@dan) /tmp/zz/ # for i in {00..99} ; do echo ${i}0000 ; mkdir ${i}{0000..9999} ; done
000000
[..]
990000
(dan@dan) /tmp/zz/ # echo * | wc -w
1000000


-- 
	Dan Nelson
	dnelson@allantgroup.com
From avg at icyb.net.ua  Fri Sep 11 07:02:00 2009
From: avg at icyb.net.ua (Andriy Gapon)
Date: Fri Sep 11 07:02:07 2009
Subject: vesa(4) and amd64
Message-ID: <4AA9F5E4.6020305@icyb.net.ua>


I am trying x86emu-enabled vesa (from head) on amd64.
First of all, thank you very much for doing this!
It works almost perfectly. 'Almost', because I have one minor issue.

If I set non-default mode in a console, then switch to X, then switch back, the
colors in the console get shuffled. If I switch to another virtual console with
default mode and then back, the colors get restored to normal.

This is with radeon hardware and driver:
vgapci0: <VGA-compatible display> port 0xee00-0xeeff mem
0xd0000000-0xdfffffff,0xfdfe0000-0xfdfeffff,0xfde00000-0xfdefffff irq 18 at device
5.0 on pci1
drm0: <ATI Radeon HD 3200 Graphics> on vgapci0
info: [drm] MSI enabled 1 message(s)
vgapci0: child drm0 requested pci_enable_busmaster
info: [drm] Initialized radeon 1.31.0 20080613
vga0: <Generic ISA VGA> at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0
info: [drm] Setting GART location based on new memory map

I can provide any addition info and debugging.

-- 
Andriy Gapon
From lars.engels at 0x20.net  Fri Sep 11 07:45:52 2009
From: lars.engels at 0x20.net (Lars Engels)
Date: Fri Sep 11 07:45:59 2009
Subject: "wpi0: fatal firmware error" in BETA4
Message-ID: <20090911074550.GF19090@e.0x20.net>

Hi all,

after upgrading from BETA1 to BETA4 my wpi0 device stops working after a
few minutes.

The kernel shows: wpi0: fatal firmware error

dmesg says this about the device:
wpi0: <Intel(R) PRO/Wireless 3945ABG> mem 0xd4000000-0xd4000fff irq 16 at device
 0.0 on pci2
wpi0: Driver Revision 20071127
wpi0: Hardware Revision (0x1)
adding chan 1 (2412MHz) flags=0x2b maxpwr=15 passive=0, offset 2
[...]
adding chan 140 (5700MHz) flags=0xb1 maxpwr=16 passive=1, offset 49
power group 0: chan=1 maxpwr=46 temp=-190
        sample 0: index=13 power=43
        sample 1: index=29 power=31
        sample 2: index=47 power=11
        sample 3: index=58 power=0
        sample 4: index=77 power=-18
[...]
wpi0: Regulatory Domain: MoW2
wpi0: Hardware Type: B
wpi0: Hardware Revision: ?
wpi0: SKU does support 802.11a
wpi0: [ITHREAD]


Lars


-- 
Lars Engels
E-Mail: lars.engels@0x20.net 	
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20090911/45e11c50/attachment.pgp
From tlott at gamesnet.de  Fri Sep 11 09:58:12 2009
From: tlott at gamesnet.de (tlott@gamesnet.de)
Date: Fri Sep 11 09:58:19 2009
Subject: Problems with ZFS on AMD64 (and i386 now)
In-Reply-To: <20090910215254.GD2718@garage.freebsd.pl>
References: <a7454e2f0909010624yf652445y855047b83d046cc4@mail.gmail.com>
	<200909011005.18200.jhb@freebsd.org>
	<20090908214402.43009577@sub.han.vpn.gamesnet.de>
	<20090909001942.0affc96c@sub.han.vpn.gamesnet.de>
	<20090909054249.GH1539@garage.freebsd.pl>
	<20090909101346.01887a02@sub.han.vpn.gamesnet.de>
	<20090910215254.GD2718@garage.freebsd.pl>
Message-ID: <102295df02d347c97bd098dc89ccb534.squirrel@mail.gamesnet.de>

> On Wed, Sep 09, 2009 at 10:13:46AM +0200, Tobias Lott wrote:
>>
>>
>> On Wed, 9 Sep 2009 07:42:49 +0200
>> Pawel Jakub Dawidek <pjd@FreeBSD.org> wrote:
>>
>> > On Wed, Sep 09, 2009 at 12:19:42AM +0200, Tobias Lott wrote:
>> > > Hey Everyone
>> > >
>> > > I've managed to get some Output for this, using BETA2 LiveCD (gonna
>> > > try using BETA4 CD Tomorrow).
>> > >
>> > > 'zfs import -f poolname' triggered this, Booting kernel.old (BETA3)
>> > > and today built BETA4 Kernel Panic mounting zfs Volumes.
>> > > Booting single user mode I get output of zfs list and so on but
>> > > mounting whatever volume also Panics.
>> >
>> > Why -f? Were there a poblem in importing pool?
>> >
>> > > Stack output, if there's more you need I'll gladly help
>> > > http://i27.tinypic.com/2d78qpd.jpg
>> > > http://i31.tinypic.com/oqhv2w.jpg
>> > > http://i28.tinypic.com/oktsag.jpg
>> >
>> > Could you also provide top part of the backtrace?
>> >
>> Oh yeah my bad
>>
>> http://i29.tinypic.com/nqwxo2.jpg
>> http://i26.tinypic.com/209hanm.jpg
>
> Seems that one of the vdevs is NULL. Could you tell me why you decided
> to use -f option for importing the pool?
>
> --
> Pawel Jakub Dawidek                       http://www.wheel.pl
> pjd@FreeBSD.org                           http://www.FreeBSD.org
> FreeBSD committer                         Am I Evil? Yes, I Am!
>

Because zpool import tank says:
cannot import 'tank': pool may be in use from other system
use '-f' to import anyway

From swell.k at gmail.com  Fri Sep 11 10:29:16 2009
From: swell.k at gmail.com (Anonymous)
Date: Fri Sep 11 10:29:24 2009
Subject: vesa(4) and amd64
In-Reply-To: <4AA9F5E4.6020305@icyb.net.ua> (Andriy Gapon's message of "Fri,
	11 Sep 2009 10:01:56 +0300")
References: <4AA9F5E4.6020305@icyb.net.ua>
Message-ID: <863a6tbwqx.fsf@gmail.com>

Andriy Gapon <avg@icyb.net.ua> writes:

> I am trying x86emu-enabled vesa (from head) on amd64.
> First of all, thank you very much for doing this!
> It works almost perfectly. 'Almost', because I have one minor issue.
>
> If I set non-default mode in a console, then switch to X, then switch
> back, the colors in the console get shuffled.

By non-default do you mean 8bit mode? Have you tried 32bit and 16bit modes?

> If I switch to another virtual console with default mode and then
> back, the colors get restored to normal.
>
> This is with radeon hardware and driver:
> vgapci0: <VGA-compatible display> port 0xee00-0xeeff mem
> 0xd0000000-0xdfffffff,0xfdfe0000-0xfdfeffff,0xfde00000-0xfdefffff irq 18 at device
> 5.0 on pci1
> drm0: <ATI Radeon HD 3200 Graphics> on vgapci0
> info: [drm] MSI enabled 1 message(s)
> vgapci0: child drm0 requested pci_enable_busmaster
> info: [drm] Initialized radeon 1.31.0 20080613
> vga0: <Generic ISA VGA> at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0
> info: [drm] Setting GART location based on new memory map
>
> I can provide any addition info and debugging.
From avg at icyb.net.ua  Fri Sep 11 10:34:12 2009
From: avg at icyb.net.ua (Andriy Gapon)
Date: Fri Sep 11 10:34:22 2009
Subject: vesa(4) and amd64
In-Reply-To: <863a6tbwqx.fsf@gmail.com>
References: <4AA9F5E4.6020305@icyb.net.ua> <863a6tbwqx.fsf@gmail.com>
Message-ID: <4AAA279F.1060703@icyb.net.ua>

on 11/09/2009 13:29 Anonymous said the following:
> Andriy Gapon <avg@icyb.net.ua> writes:
> 
>> I am trying x86emu-enabled vesa (from head) on amd64.
>> First of all, thank you very much for doing this!
>> It works almost perfectly. 'Almost', because I have one minor issue.
>>
>> If I set non-default mode in a console, then switch to X, then switch
>> back, the colors in the console get shuffled.
> 
> By non-default do you mean 8bit mode? Have you tried 32bit and 16bit modes?

Non-default is anything that is not the default 80x25.
I actually tried a 16-bit one, I will try a 32-bit one for test coverage.


-- 
Andriy Gapon
From avg at icyb.net.ua  Fri Sep 11 10:36:26 2009
From: avg at icyb.net.ua (Andriy Gapon)
Date: Fri Sep 11 10:36:32 2009
Subject: vesa(4) and amd64
In-Reply-To: <4AAA279F.1060703@icyb.net.ua>
References: <4AA9F5E4.6020305@icyb.net.ua> <863a6tbwqx.fsf@gmail.com>
	<4AAA279F.1060703@icyb.net.ua>
Message-ID: <4AAA2825.8050906@icyb.net.ua>

on 11/09/2009 13:34 Andriy Gapon said the following:
> on 11/09/2009 13:29 Anonymous said the following:
>> Andriy Gapon <avg@icyb.net.ua> writes:
>>
>>> I am trying x86emu-enabled vesa (from head) on amd64.
>>> First of all, thank you very much for doing this!
>>> It works almost perfectly. 'Almost', because I have one minor issue.
>>>
>>> If I set non-default mode in a console, then switch to X, then switch
>>> back, the colors in the console get shuffled.
>> By non-default do you mean 8bit mode? Have you tried 32bit and 16bit modes?
> 
> Non-default is anything that is not the default 80x25.
> I actually tried a 16-bit one, I will try a 32-bit one for test coverage.

Yes, the problem is still there with 32-bit mode too.


-- 
Andriy Gapon
From ddkprog at yahoo.com  Fri Sep 11 10:50:07 2009
From: ddkprog at yahoo.com (ddk ddk)
Date: Fri Sep 11 11:28:40 2009
Subject: vesa(4) and amd64
In-Reply-To: <4AA9F5E4.6020305@icyb.net.ua>
Message-ID: <85911.11390.qm@web59108.mail.re1.yahoo.com>

> 
> I am trying x86emu-enabled vesa (from head) on amd64.
> First of all, thank you very much for doing this!
> It works almost perfectly. 'Almost', because I have one
> minor issue.
> 
> If I set non-default mode in a console, then switch to X,
> then switch back, the
> colors in the console get shuffled. If I switch to another
> virtual console with
> default mode and then back, the colors get restored to
> normal.
> 
> This is with radeon hardware and driver:
> vgapci0: <VGA-compatible display> port 0xee00-0xeeff
> mem
> 0xd0000000-0xdfffffff,0xfdfe0000-0xfdfeffff,0xfde00000-0xfdefffff
> irq 18 at device
> 5.0 on pci1
> drm0: <ATI Radeon HD 3200 Graphics> on vgapci0
> info: [drm] MSI enabled 1 message(s)
> vgapci0: child drm0 requested pci_enable_busmaster
> info: [drm] Initialized radeon 1.31.0 20080613
> vga0: <Generic ISA VGA> at port 0x3c0-0x3df iomem
> 0xa0000-0xbffff on isa0
> info: [drm] Setting GART location based on new memory map
> 
> I can provide any addition info and debugging.
> 
> -- 
> Andriy Gapon
> 

 I think I can repeat this bug on my hardware
 but now there is a more serious bug 
 impossible to lower the resolution of the console 
 can only improve 
 ie 80x25 -> 800x600 -> 1024x768 
 when is lowered to 800x600 -> 80x25 or
 1024x768->800x600 the system freezy 
 is not a problem driver vesa 
 I think this is a problem that has added a new terminal
 teken by ed@
 
 becouse there is no problem on freebsd 7 where is no teken
 where I can switch to any low mode 


      
From nick-lists at netability.ie  Fri Sep 11 11:36:25 2009
From: nick-lists at netability.ie (Nick Hilliard)
Date: Fri Sep 11 11:36:31 2009
Subject: Problems with ZFS on AMD64 (and i386 now)
In-Reply-To: <102295df02d347c97bd098dc89ccb534.squirrel@mail.gamesnet.de>
References: <a7454e2f0909010624yf652445y855047b83d046cc4@mail.gmail.com>	<200909011005.18200.jhb@freebsd.org>	<20090908214402.43009577@sub.han.vpn.gamesnet.de>	<20090909001942.0affc96c@sub.han.vpn.gamesnet.de>	<20090909054249.GH1539@garage.freebsd.pl>	<20090909101346.01887a02@sub.han.vpn.gamesnet.de>	<20090910215254.GD2718@garage.freebsd.pl>
	<102295df02d347c97bd098dc89ccb534.squirrel@mail.gamesnet.de>
Message-ID: <4AAA3633.1040004@netability.ie>

On 11/09/2009 10:51, tlott@gamesnet.de wrote:
> Because zpool import tank says:
> cannot import 'tank': pool may be in use from other system
> use '-f' to import anyway

Eh, yah, when messing around with zfs from single-user boot, it's a good 
idea to run "/etc/rc.d/hostid start" first.  Otherwise you end up writing 
0000000 as the host id of the last system to mount your zfs pool, and this 
is one of the means used to determine whether the pool is mounted by any 
other system.

Nick
From nick-lists at netability.ie  Fri Sep 11 11:40:57 2009
From: nick-lists at netability.ie (Nick Hilliard)
Date: Fri Sep 11 11:41:04 2009
Subject: 8.0-beta3 does not detect several ata channels
In-Reply-To: <200909081325.13149.jhb@freebsd.org>
References: <4A9BF23F.6070801@netability.ie>
	<200909011002.59592.jhb@freebsd.org>
	<4AA52BE4.3070708@netability.ie>
	<200909081325.13149.jhb@freebsd.org>
Message-ID: <4AAA3744.5020604@netability.ie>

On 08/09/2009 18:25, John Baldwin wrote:
> So as with the other pciconf output I got, it seems that it is reading the
> registers ok in both cases.  Can you add some printfs to the ata driver to
> figure out when it starts behaving differently (e.g. reading a value from a
> register) between the mcfg=0 and mcfg=1 cases on 8?

oh my, this is causing sadness.

I've installed 8.0 on a usb key and am running into the mountroot problem 
that others are seeing:

> http://lists.freebsd.org/pipermail/freebsd-current/2009-September/011445.html

The usb key is a 2yo Kingston unit.

> umass0: <Kingston DataTraveler 2.0, class 0/0, rev 2.00/1.10, addr 2> on usbus1
> umass0:  SCSI over Bulk-Only; quirks = 0x0000
> umass0:0:0:-1: Attached to scbus0
> da0 at umass-sim0 bus 0 target 0 lun 0
> da0: <Kingston DataTraveler 2.0 PMAP> Removable Direct Access SCSI-0 device
> da0: 40.000MB/s transfers
> da0: 3936MB (8060928 512 byte sectors: 255H 63S/T 501C)

/ is mounted on /dev/da0s1a, and when I type "ufs:/dev/da0s1a" at the 
mountroot> prompt, it usually continues bootup, but not always.

However, if I use a PS/2 keyboard when it boots up, the console keeps on 
scrolling up as if the cat were sitting on the return key, and it refuses 
to accept any input from the keyboard after mountroot>.  A USB keyboard 
usually works better, but not always.  And it only works if I plug in the 
keyboard before turning the machine on.  Frustrating :-(

Anyway, at this stage, I have a bootable usb key with an 8.0-beta4 kernel 
built on it, and reboots mostly work.

You'll have to excuse me but my ata driver clue is epsilon away from zero. 
  If you can tell me what sort of stuff to put where, I can build a kernel 
with local mods and report on what it's doing.  But being inventive with 
this is beyond my understanding of what's going on in the pcie subsystem. 
Sorry :-(

Nick
From lists at c0mplx.org  Fri Sep 11 12:06:53 2009
From: lists at c0mplx.org (Kurt Jaeger)
Date: Fri Sep 11 12:07:00 2009
Subject: 8.0-BETA4 sysinstaller and install on LSI MegaRAID (mfid0)
In-Reply-To: <4AA52BE4.3070708@netability.ie>
References: <4A9BF23F.6070801@netability.ie> <4A9BF438.1000006@smeets.im>
	<200909011002.59592.jhb@freebsd.org>
	<4AA52BE4.3070708@netability.ie>
Message-ID: <20090911120652.GI48206@home.opsec.eu>

Hi!

I used the 8.0-BETA4 amd64 bootonly CD to boot a FSC RX330 S1 server
which has a built-in LSI megaraid.

I sucessfully installed 7.2-i386 on that same hardware before.
The resulting dmesg.boot can be found at
http://www.nepustil.net/support/tmp/dmesg.boot-7.2-i386

The error in the FreeBSD Disklabel Editor (when I used "w" to
trigger the necessary newfs calls) was:

  Unable to find device node for /dev/mfid0s1b in /dev
  The Creation of filesystems will be aborted.

Using an emergency shell, I typed:

cd /dev
echo *

and found only the following device nodes:

  mfi0
  mfid0
  mfid0s1
  mfid0s2

but no mfid0s1a, 1b, ...

Something is going wrong, any ideas ?

Thanks!

-- 
pi@opsec.eu            +49 171 3101372                        11 years to go !
From raul at pop.isdefe.es  Fri Sep 11 13:01:12 2009
From: raul at pop.isdefe.es (Raul)
Date: Fri Sep 11 13:01:18 2009
Subject: Boot-time hang with the CISS driver on HP 385
In-Reply-To: <4AA797D1.9050409@pop.isdefe.es>
References: <54854a7a0907150322n52a3595el5352a3987d2c75ac@mail.gmail.com>	<58c737d70907151035ya9a829eyf4945d1fadc4ce0e@mail.gmail.com>	<4A5EFFF7.4060708@pop.isdefe.es>
	<4AA797D1.9050409@pop.isdefe.es>
Message-ID: <4AAA4A16.4060709@pop.isdefe.es>

Raul escribi?:

[....]
> ciss0: PERFORMANT Transport
> ciss0: can't allocate interrupt
> panic: mtx_unlock() of spin mutex (null) @ 
> /usr/src/sys/dev/ciss/ciss.c:1903
> cpuid = 0
> KBD: enter: panic
> ....
[....]

After (some) re-reading and comparing dmesg's of other colleagues with 
this hardware (hp dl 385) something wrong was happening with the irq 
mapping on my boxes (acpi?). Several upgrades of bios, other OS running 
on them before ... whatever. As a quick and dirty try i've erased nvram 
leaving behind all previous settings. As a result, boot process goes 
further ... and stop setting something about ipv6. I'll see more tomorrow.

Maybe this can also help on other systems with similar ciss controllers.

Regars,
Raul.


From avg at icyb.net.ua  Fri Sep 11 13:47:46 2009
From: avg at icyb.net.ua (Andriy Gapon)
Date: Fri Sep 11 13:47:54 2009
Subject: crashinfo issue in HEAD
Message-ID: <4AAA54FF.9080701@icyb.net.ua>


I had a panic (provoked via sw watchdog, nothing exciting) and after reboot I
noticed that couple of processes dumped core, apparently while running as part of
crashinfo procedure.

savecore: reboot after panic: watchdog timeout
savecore: writing core to vmcore.0
kernel: pid 725 (ps), uid 0: exited on signal 11 (core dumped)
kernel: pid 742 (fstat), uid 0: exited on signal 11

core.0.txt accordingly has:
------------------------------------------------------------------------
ps -axl
Segmentation fault (core dumped)
------------------------------------------------------------------------
fstat
Segmentation fault
------------------------------------------------------------------------

The world doesn't have debug symbols, so gdb doesn't produce much.
Still, it  gives some insights:
ps:
#0  0x0000000800959df6 in bcopy () from /lib/libc.so.7
#1  0x000000080076f11c in _kvm_freeprocs () from /lib/libkvm.so.5
#2  0x000000080076f830 in kvm_getprocs () from /lib/libkvm.so.5
#3  0x0000000000405273 in uname ()

core size is about 1G.

I couldn't find fstat core file.

-- 
Andriy Gapon
From andrew at flarn.com  Fri Sep 11 13:54:18 2009
From: andrew at flarn.com (Andrew Tulloch)
Date: Fri Sep 11 13:56:39 2009
Subject: Boot-time hang with the CISS driver on HP 385
In-Reply-To: <4AAA4A16.4060709@pop.isdefe.es>
References: <54854a7a0907150322n52a3595el5352a3987d2c75ac@mail.gmail.com>
	<58c737d70907151035ya9a829eyf4945d1fadc4ce0e@mail.gmail.com>
	<4A5EFFF7.4060708@pop.isdefe.es> <4AA797D1.9050409@pop.isdefe.es>
	<4AAA4A16.4060709@pop.isdefe.es>
Message-ID: <54854a7a0909110654g4dadea54p9e01bf908fc0c850@mail.gmail.com>

2009/9/11 Raul <raul@pop.isdefe.es>:
> Raul escribi?:
>
> [....]
>>
>> ciss0: PERFORMANT Transport
>> ciss0: can't allocate interrupt
>> panic: mtx_unlock() of spin mutex (null) @
>> /usr/src/sys/dev/ciss/ciss.c:1903
>> cpuid = 0
>> KBD: enter: panic
>> ....
>
> [....]
>
> After (some) re-reading and comparing dmesg's of other colleagues with this
> hardware (hp dl 385) something wrong was happening with the irq mapping on
> my boxes (acpi?). Several upgrades of bios, other OS running on them before
> ... whatever. As a quick and dirty try i've erased nvram leaving behind all
> previous settings. As a result, boot process goes further ... and stop
> setting something about ipv6. I'll see more tomorrow.
>
> Maybe this can also help on other systems with similar ciss controllers.
>
> Regars,
> Raul.

Raul,
I found my issues seemed to be related to the bge controller in the
machine and setting the tunable:
hw.bge.allow_asf=0

resolved the problem for me and the machine would reliably boot and
has worked flawlessly since, have you tried that at all?

I've seen other people mentioning similar issues with bge0 in HP
machines not working with 8.0
This tunable defaults to 0 on RELENG_7, but 1 on RELENG_8 might be
worth changing it back if it makes a lot of machine unbootable?

Regards,
Andrew
From bu7cher at yandex.ru  Fri Sep 11 14:23:38 2009
From: bu7cher at yandex.ru (Andrey V. Elsukov)
Date: Fri Sep 11 14:23:46 2009
Subject: 9.0-CURRENT - panic on detaching USB flash (not mounted)
Message-ID: <4AAA5D61.6020900@yandex.ru>

Hi, All.


My system is fresh CURRENT:
FreeBSD btr.properlan.net 9.0-CURRENT FreeBSD 9.0-CURRENT #9 r197070: 
Thu Sep 10 21:40:35 MSD 2009 
butcher@btr.properlan.net:/usr/obj/usr/src/sys/GENERIC  amd64

I successful unmount my USB flash and got fatal trap when i removed it.

This portion from dmesg:

--- syscall (10, FreeBSD ELF64, unlink), rip = 0x8007316fc, rsp = 
0x7fffffffe218, rbp = 0x800803d28 ---
lock order reversal:
  1st 0xffffff0005a609d0 zfs (zfs) @ /usr/src/sys/kern/vfs_mount.c:1200
  2nd 0xffffff00059d0270 devfs (devfs) @ 
/usr/src/sys/ufs/ffs/ffs_vfsops.c:1345
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2a
_witness_debugger() at _witness_debugger+0x2e
witness_checkorder() at witness_checkorder+0x81e
__lockmgr_args() at __lockmgr_args+0xcf3
vop_stdlock() at vop_stdlock+0x39
VOP_LOCK1_APV() at VOP_LOCK1_APV+0x9b
_vn_lock() at _vn_lock+0x47
ffs_sync() at ffs_sync+0x2d7
dounmount() at dounmount+0x2ca
unmount() at unmount+0x27e
syscall() at syscall+0x1af
Xfast_syscall() at Xfast_syscall+0xe1
--- syscall (22, FreeBSD ELF64, unmount), rip = 0x8006a09dc, rsp = 
0x7fffffffe308, rbp = 0 ---
ugen3.2: <Prolific Technology Inc.> at usbus3 (disconnected)
uhub8: at uhub3, port 3, addr 2 (disconnected)
ugen3.3: <Prolific Technology Inc.> at usbus3 (disconnected)


Fatal trap 9: general protection fault while in kernel mode
cpuid = 0; apic id = 00
instruction pointer     = 0x20:0xffffffff804c3b10
stack pointer           = 0x28:0xffffff80752399a0
frame pointer           = 0x28:0xffffff80752399c0
code segment            = base 0x0, limit 0xfffff, type 0x1b
                         = DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags        = interrupt enabled, resume, IOPL = 0
current process         = 14 (usbus3)
panic: from debugger
cpuid = 0
Uptime: 21m50s
Physical memory: 4077 MB

This from kgdb:

#0  doadump () at pcpu.h:223
#1  0xffffffff805826a3 in boot (howto=260)
     at /usr/src/sys/kern/kern_shutdown.c:416
#2  0xffffffff80582b2c in panic (fmt=)
     at /usr/src/sys/kern/kern_shutdown.c:579
#3  0xffffffff801d9057 in db_panic (addr=)
     at /usr/src/sys/ddb/db_command.c:478
#4  0xffffffff801d9501 in db_command (last_cmdp=0xffffffff80be9aa0, 
cmd_table=
) at /usr/src/sys/ddb/db_command.c:445
#5  0xffffffff801d9750 in db_command_loop ()
     at /usr/src/sys/ddb/db_command.c:498
#6  0xffffffff801db719 in db_trap (type=) at /usr/src/sys/ddb/db_main.c:229
#7  0xffffffff805b2295 in kdb_trap (type=9, code=0, tf=0xffffff80752398f0)
     at /usr/src/sys/kern/subr_kdb.c:535
#8  0xffffffff80866afd in trap_fatal (frame=0xffffff80752398f0, eva=)
     at /usr/src/sys/amd64/amd64/trap.c:847
#9  0xffffffff808675a6 in trap (frame=0xffffff80752398f0)
     at /usr/src/sys/amd64/amd64/trap.c:639
#10 0xffffffff8084d253 in calltrap ()
     at /usr/src/sys/amd64/amd64/exception.S:224
#11 0xffffffff804c3b10 in usbd_transfer_stop (xfer=0xffffff8000e6aa90)
     at /usr/src/sys/dev/usb/usb_transfer.c:1694
#12 0xffffffff804c4547 in usbd_transfer_drain (xfer=0xffffff8000e6aa90)
     at /usr/src/sys/dev/usb/usb_transfer.c:1786
#13 0xffffffff804c5065 in usbd_transfer_unsetup (pxfer=0xffffff0003a214b8,
     n_setup=) at /usr/src/sys/dev/usb/usb_transfer.c:1166
#14 0xffffffff804aadc7 in umass_detach (dev=)
     at /usr/src/sys/dev/usb/storage/umass.c:1662
#15 0xffffffff805ac29b in device_detach (dev=0xffffff0003a18400)
     at device_if.h:212
#16 0xffffffff805ac4e1 in device_delete_child (dev=0xffffff0003a18600,
     child=0xffffff0003a18400) at /usr/src/sys/kern/subr_bus.c:1820
#17 0xffffffff805ac4c4 in device_delete_child (dev=0xffffff000391ec00,
     child=0xffffff0003a18600) at /usr/src/sys/kern/subr_bus.c:1815
#18 0xffffffff804b6f88 in usb_unconfigure (udev=0xffffff00039a6000, flag=)
     at /usr/src/sys/dev/usb/usb_device.c:1022
#19 0xffffffff804b72cd in usb_free_device (udev=0xffffff00039a6000, flag=)
     at /usr/src/sys/dev/usb/usb_device.c:1985
#20 0xffffffff804bea38 in uhub_explore (udev=0xffffff0003974000)
     at /usr/src/sys/dev/usb/usb_hub.c:322
#21 0xffffffff804aab41 in usb_bus_explore (pm=)
     at /usr/src/sys/dev/usb/controller/usb_controller.c:239
#22 0xffffffff804c1290 in usb_process (arg=)
     at /usr/src/sys/dev/usb/usb_process.c:164
#23 0xffffffff8055a92a in fork_exit (
     callout=0xffffffff804c11d0 <usb_process>, arg=0xffffff80002f0d68,
     frame=0xffffff8075239c80) at /usr/src/sys/kern/kern_fork.c:843
#24 0xffffffff8084d72e in fork_trampoline ()
     at /usr/src/sys/amd64/amd64/exception.S:561
#25 0x0000000000000000 in ?? ()

-- 
WBR, Andrey V. Elsukov
From gavin at FreeBSD.org  Fri Sep 11 14:26:55 2009
From: gavin at FreeBSD.org (Gavin Atkinson)
Date: Fri Sep 11 14:27:03 2009
Subject: crashinfo issue in HEAD
In-Reply-To: <4AAA54FF.9080701@icyb.net.ua>
References: <4AAA54FF.9080701@icyb.net.ua>
Message-ID: <1252679211.31066.43.camel@buffy.york.ac.uk>

On Fri, 2009-09-11 at 16:47 +0300, Andriy Gapon wrote:
> I had a panic (provoked via sw watchdog, nothing exciting) and after reboot I
> noticed that couple of processes dumped core, apparently while running as part of
> crashinfo procedure.
> 
> savecore: reboot after panic: watchdog timeout
> savecore: writing core to vmcore.0
> kernel: pid 725 (ps), uid 0: exited on signal 11 (core dumped)
> kernel: pid 742 (fstat), uid 0: exited on signal 11
> 
> core.0.txt accordingly has:
> ------------------------------------------------------------------------
> ps -axl
> Segmentation fault (core dumped)

You need at least r196990 (which has not yet been MFC'd) and
http://people.freebsd.org/~gavin/PRs/137890.2.diff .  Hopefully both of
these will appear in 8.x.

> ------------------------------------------------------------------------
> fstat
> Segmentation fault
> ------------------------------------------------------------------------

I suspect this will be also fixed by the above patches.

Gavin
From avg at icyb.net.ua  Fri Sep 11 14:41:39 2009
From: avg at icyb.net.ua (Andriy Gapon)
Date: Fri Sep 11 14:41:46 2009
Subject: crashinfo issue in HEAD
In-Reply-To: <1252679211.31066.43.camel@buffy.york.ac.uk>
References: <4AAA54FF.9080701@icyb.net.ua>
	<1252679211.31066.43.camel@buffy.york.ac.uk>
Message-ID: <4AAA61A0.2040600@icyb.net.ua>

on 11/09/2009 17:26 Gavin Atkinson said the following:
> On Fri, 2009-09-11 at 16:47 +0300, Andriy Gapon wrote:
>> I had a panic (provoked via sw watchdog, nothing exciting) and after reboot I
>> noticed that couple of processes dumped core, apparently while running as part of
>> crashinfo procedure.
>>
>> savecore: reboot after panic: watchdog timeout
>> savecore: writing core to vmcore.0
>> kernel: pid 725 (ps), uid 0: exited on signal 11 (core dumped)
>> kernel: pid 742 (fstat), uid 0: exited on signal 11
>>
>> core.0.txt accordingly has:
>> ------------------------------------------------------------------------
>> ps -axl
>> Segmentation fault (core dumped)
> 
> You need at least r196990 (which has not yet been MFC'd) and
> http://people.freebsd.org/~gavin/PRs/137890.2.diff .  Hopefully both of
> these will appear in 8.x.

I mentioned HEAD in the subject, but didn't say specifically that this is very
recent HEAD - r197046. And amd64. Sorry for withholding such important details.
So that patch is not in HEAD yet? I will try it then, thanks!

>> ------------------------------------------------------------------------
>> fstat
>> Segmentation fault
>> ------------------------------------------------------------------------
> 
> I suspect this will be also fixed by the above patches.
> 
> Gavin


-- 
Andriy Gapon
From jfb at mr-happy.com  Fri Sep 11 15:00:29 2009
From: jfb at mr-happy.com (Jeff Blank)
Date: Fri Sep 11 15:00:36 2009
Subject: 8.0-BETA4 LOR vfs(syncer)/zfs
Message-ID: <20090911150027.GA4187@mr-happy.com>

this didn't seem to cause me any problems, but I thought I'd mention
it anyway, since I didn't find anything that looked similar in the
list archives, at the sources.zabbadoz.net LOR list, or with a quick
google.  happened with 8.0-BETA4/amd64 from around 0200 UTC Sep 10,
GENERIC kernel.

Jeff


lock order reversal:
 1st 0xffffff0005feb620 syncer (syncer) @ /usr/src/sys/kern/vfs_subr.c:1693
 2nd 0xffffff014651f270 zfs (zfs) @ /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_znode.c:152
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2a
_witness_debugger() at _witness_debugger+0x2e
witness_checkorder() at witness_checkorder+0x81e
__lockmgr_args() at __lockmgr_args+0xcf3
vop_stdlock() at vop_stdlock+0x39
VOP_LOCK1_APV() at VOP_LOCK1_APV+0x9b
_vn_lock() at _vn_lock+0x47
zfs_znode_cache_constructor() at zfs_znode_cache_constructor+0x4e
zfs_znode_alloc() at zfs_znode_alloc+0x39
zfs_zget() at zfs_zget+0x25d
zfs_get_data() at zfs_get_data+0x4d
zil_commit() at zil_commit+0x532
zfs_sync() at zfs_sync+0xa6
sync_fsync() at sync_fsync+0x13a
sync_vnode() at sync_vnode+0x157
sched_sync() at sched_sync+0x1d1
fork_exit() at fork_exit+0x12a
fork_trampoline() at fork_trampoline+0xe
--- trap 0, rip = 0, rsp = 0xffffff82531dfd30, rbp = 0 ---
From jhb at freebsd.org  Fri Sep 11 15:20:02 2009
From: jhb at freebsd.org (John Baldwin)
Date: Fri Sep 11 15:20:09 2009
Subject: 8.0-beta3 does not detect several ata channels
In-Reply-To: <4AAA3744.5020604@netability.ie>
References: <4A9BF23F.6070801@netability.ie>
	<200909081325.13149.jhb@freebsd.org>
	<4AAA3744.5020604@netability.ie>
Message-ID: <200909111119.04511.jhb@freebsd.org>

On Friday 11 September 2009 7:40:52 am Nick Hilliard wrote:
> On 08/09/2009 18:25, John Baldwin wrote:
> > So as with the other pciconf output I got, it seems that it is reading the
> > registers ok in both cases.  Can you add some printfs to the ata driver to
> > figure out when it starts behaving differently (e.g. reading a value from 
a
> > register) between the mcfg=0 and mcfg=1 cases on 8?
> 
> oh my, this is causing sadness.
> 
> I've installed 8.0 on a usb key and am running into the mountroot problem 
> that others are seeing:
 
Hmm, I figured you could just install 8.0 onto the system with mcfg disabled 
and set mcfg=1 when booting a test kernel so you didn't have to go the 
full-blown USB key route.

> You'll have to excuse me but my ata driver clue is epsilon away from zero. 
>   If you can tell me what sort of stuff to put where, I can build a kernel 
> with local mods and report on what it's doing.  But being inventive with 
> this is beyond my understanding of what's going on in the pcie subsystem. 
> Sorry :-(

Ah, I would probably start with adding printfs to the various routines in 
sys/dev/ata/chipsets/ata-nvidia.c.

-- 
John Baldwin
From jhb at freebsd.org  Fri Sep 11 15:26:25 2009
From: jhb at freebsd.org (John Baldwin)
Date: Fri Sep 11 15:26:38 2009
Subject: FreeBSD timing issues and qemu (was: Re: [Qemu-devel] Re:
	Breakage with local APIC routing)
In-Reply-To: <20090910190800.GA14191@onelab2.iet.unipi.it>
References: <4A93BF0C.8040601@web.de>
	<20090910174640.GA30706@triton8.kn-bremen.de>
	<20090910190800.GA14191@onelab2.iet.unipi.it>
Message-ID: <200909111123.00257.jhb@freebsd.org>

On Thursday 10 September 2009 3:08:00 pm Luigi Rizzo wrote:
> On Thu, Sep 10, 2009 at 07:46:40PM +0200, Juergen Lock wrote:
> > On Wed, Sep 09, 2009 at 10:46:16PM +0200, Luigi Rizzo wrote:
> > > On Mon, Sep 07, 2009 at 10:59:55PM +0200, Juergen Lock wrote:
> > > > [I'm copying freebsd-current@FreeBSD.org because ppl there might know
> > > > more about this...]
> > > > 
> > > >  qemu on FreeBSD hosts used to be able to run a (FreeBSD at least) 
guest
> > > > with the same HZ as the host (like, 1000) with (mostly) proper timing
> > > > once, but no longer. :(  It seems there are two problems involved:
> > > > 
> > > >  a) use of apic seems to cause the clock irq rate to be doubled to 2 * 
HZ
> > > > (can anyone explain why?), i.e. a FreeBSD 7 guest on a FreeBSD 7 host
> > > > only gets proper timing after setting hint.apic.0.disabled=1 via the
> > > > loader.  (as can be verified by `vmstat -i' and `time sleep 2' in an
> > > > installed guest or via the fixit->cdrom/dvd shell on a FreeBSD livefs
> > > > or dvd1 iso.)
> > > > 
> > > >  b) qemu running on FreeBSD 8 hosts (and most likely head) has the
> > > > additional problem of running its timers only at HZ/2 when using
> > > > setitimer(2) (called `-clock unix' in qemu), as seen below.  (as also
> > > 
> > > this problem in 8.x is caused by the bug i described here yesterday:
> > > 
> > > 
http://lists.freebsd.org/pipermail/freebsd-current/2009-September/011393.html
> > > 
> > > In qeumu, the setitimer call (in file vl.c) has a timeout of 1 tick
> > > which maps to callout_reset(..., 1, ...) and because (due to the bug)
> > > 8.x processes callouts 1 tick late, this effectively halves the clock 
rate.
> > > 
> > Thanx for the pointer!
> > 
> >  The proposed patch in that post didn't make a different here tho,
> > guest still sees only half host HZ clock irq rate. (i.e. ~500 Hz.)
> > 
> >  Here is the patch I used, to make sure I patched what you meant...
> > 
> > Index: sys/kern/kern_timeout.c
> > @@ -323,7 +323,7 @@ softclock(void *arg)
> >  	steps = 0;
> >  	cc = (struct callout_cpu *)arg;
> >  	CC_LOCK(cc);
> > -	while (cc->cc_softticks != ticks) {
> > +	while (cc->cc_softticks-1 != ticks) {
> >  		/*
> >  		 * cc_softticks may be modified by hard clock, so cache
> >  		 * it while we work on a given bucket.
> > 
> 
> as mentioned in the followup message in that thread,
> you also need this change in callout_tick()
> 
>         mtx_lock_spin_flags(&cc->cc_lock, MTX_QUIET);
>      -  for (; (cc->cc_softticks - ticks) < 0; cc->cc_softticks++) {
>      +  for (; (cc->cc_softticks - ticks) <= 0; cc->cc_softticks++) {
>                 bucket = cc->cc_softticks & callwheelmask;

I would fix the style in the first hunk (spaces around '-') but I think you 
should commit this and get it into 8.0.  I think a per-CPU ticks might prove 
very problematic as 'ticks' is rather widely used (though I would find that 
cleaner perhaps).

-- 
John Baldwin
From jhb at freebsd.org  Fri Sep 11 15:26:26 2009
From: jhb at freebsd.org (John Baldwin)
Date: Fri Sep 11 15:26:39 2009
Subject: crashinfo issue in HEAD
In-Reply-To: <1252679211.31066.43.camel@buffy.york.ac.uk>
References: <4AAA54FF.9080701@icyb.net.ua>
	<1252679211.31066.43.camel@buffy.york.ac.uk>
Message-ID: <200909111126.13209.jhb@freebsd.org>

On Friday 11 September 2009 10:26:51 am Gavin Atkinson wrote:
> On Fri, 2009-09-11 at 16:47 +0300, Andriy Gapon wrote:
> > I had a panic (provoked via sw watchdog, nothing exciting) and after 
reboot I
> > noticed that couple of processes dumped core, apparently while running as 
part of
> > crashinfo procedure.
> > 
> > savecore: reboot after panic: watchdog timeout
> > savecore: writing core to vmcore.0
> > kernel: pid 725 (ps), uid 0: exited on signal 11 (core dumped)
> > kernel: pid 742 (fstat), uid 0: exited on signal 11
> > 
> > core.0.txt accordingly has:
> > ------------------------------------------------------------------------
> > ps -axl
> > Segmentation fault (core dumped)
> 
> You need at least r196990 (which has not yet been MFC'd) and
> http://people.freebsd.org/~gavin/PRs/137890.2.diff .  Hopefully both of
> these will appear in 8.x.

I think that patch looks ok to go in FWIW.

-- 
John Baldwin
From nick-lists at netability.ie  Fri Sep 11 15:33:44 2009
From: nick-lists at netability.ie (Nick Hilliard)
Date: Fri Sep 11 15:33:52 2009
Subject: 8.0-beta3 does not detect several ata channels
In-Reply-To: <200909111119.04511.jhb@freebsd.org>
References: <4A9BF23F.6070801@netability.ie>
	<200909081325.13149.jhb@freebsd.org>
	<4AAA3744.5020604@netability.ie>
	<200909111119.04511.jhb@freebsd.org>
Message-ID: <4AAA6DD3.7030902@netability.ie>

On 11/09/2009 16:19, John Baldwin wrote:
> Hmm, I figured you could just install 8.0 onto the system with mcfg disabled
> and set mcfg=1 when booting a test kernel so you didn't have to go the
> full-blown USB key route.

I don't have a spare disk handy for that - i use the machine for backups, 
so it's used at night mostly.

> Ah, I would probably start with adding printfs to the various routines in
> sys/dev/ata/chipsets/ata-nvidia.c.

John - seriously, you're not hearing me.  I don't know squat about what to 
look for here.  I need instructions at the level of "print out variable X 
at line Y in file Z and reboot with configuration W in loader.conf. 
Really.  I'm not trying to be unhelpful or dumbass or anything; it's just 
that any freebsd-fu I might have is right at the far end of the call stack 
to this.

If you want, I can give you login access to the box.

Nick


From hselasky at c2i.net  Fri Sep 11 15:45:06 2009
From: hselasky at c2i.net (Hans Petter Selasky)
Date: Fri Sep 11 15:45:13 2009
Subject: 9.0-CURRENT - panic on detaching USB flash (not mounted)
In-Reply-To: <4AAA5D61.6020900@yandex.ru>
References: <4AAA5D61.6020900@yandex.ru>
Message-ID: <200909111745.29780.hselasky@c2i.net>

On Friday 11 September 2009 16:23:29 Andrey V. Elsukov wrote:
> Hi, All.
>
>
> My system is fresh CURRENT:
> FreeBSD btr.properlan.net 9.0-CURRENT FreeBSD 9.0-CURRENT #9 r197070:
> Thu Sep 10 21:40:35 MSD 2009
> butcher@btr.properlan.net:/usr/obj/usr/src/sys/GENERIC  amd64
>
> I successful unmount my USB flash and got fatal trap when i removed it.
>
> This portion from dmesg:

Known issue:

http://perforce.freebsd.org/chv.cgi?CH=168387

Download files using download link and build new kernel.

--HPS
From ed at 80386.nl  Fri Sep 11 15:50:03 2009
From: ed at 80386.nl (Ed Schouten)
Date: Fri Sep 11 15:50:14 2009
Subject: vesa(4) and amd64
In-Reply-To: <85911.11390.qm@web59108.mail.re1.yahoo.com>
References: <4AA9F5E4.6020305@icyb.net.ua>
	<85911.11390.qm@web59108.mail.re1.yahoo.com>
Message-ID: <20090911155001.GU2829@hoeg.nl>

Skipped content of type multipart/mixed-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20090911/a93e5fce/attachment.pgp
From gavin at FreeBSD.org  Fri Sep 11 16:04:12 2009
From: gavin at FreeBSD.org (Gavin Atkinson)
Date: Fri Sep 11 16:04:19 2009
Subject: crashinfo issue in HEAD
In-Reply-To: <4AAA61A0.2040600@icyb.net.ua>
References: <4AAA54FF.9080701@icyb.net.ua>
	<1252679211.31066.43.camel@buffy.york.ac.uk>
	<4AAA61A0.2040600@icyb.net.ua>
Message-ID: <1252685048.31066.55.camel@buffy.york.ac.uk>

On Fri, 2009-09-11 at 17:41 +0300, Andriy Gapon wrote:
> on 11/09/2009 17:26 Gavin Atkinson said the following:
> > On Fri, 2009-09-11 at 16:47 +0300, Andriy Gapon wrote:
> >> I had a panic (provoked via sw watchdog, nothing exciting) and after reboot I
> >> noticed that couple of processes dumped core, apparently while running as part of
> >> crashinfo procedure.
> >>
> >> savecore: reboot after panic: watchdog timeout
> >> savecore: writing core to vmcore.0
> >> kernel: pid 725 (ps), uid 0: exited on signal 11 (core dumped)
> >> kernel: pid 742 (fstat), uid 0: exited on signal 11
> >>
> >> core.0.txt accordingly has:
> >> ------------------------------------------------------------------------
> >> ps -axl
> >> Segmentation fault (core dumped)
> > 
> > You need at least r196990 (which has not yet been MFC'd) and
> > http://people.freebsd.org/~gavin/PRs/137890.2.diff .  Hopefully both of
> > these will appear in 8.x.
> 
> I mentioned HEAD in the subject, but didn't say specifically that this is very
> recent HEAD - r197046. And amd64. Sorry for withholding such important details.
> So that patch is not in HEAD yet? I will try it then, thanks!

Hmm, in that case this is probably a different bug to the ones already
found, and that patch won't help.  Can you recompile ps and libkvm with
debugging symbols, run it under gdb and get a backtrace?  Your original
stack trace shows kvm_getprocs() calling _kvm_freeprocs(), however the
code doesn't appear to ever do this: indeed, nothing in libkvm calls
_kvm_freeprocs() directly.

Gavin
From roberthuff at rcn.com  Fri Sep 11 16:05:53 2009
From: roberthuff at rcn.com (Robert Huff)
Date: Fri Sep 11 16:06:02 2009
Subject: custom kernel freezes when using KVM
Message-ID: <19114.30046.373632.669034@jerusalem.litteratus.org>


	1) About two weeks ago I installed 8.0beta3/amd64 on new
hardware.  Except for one problem, now solved, everything went
smoothly and I was a happy camper.
	2) Several days later I hooked it up to a (USB-) KVM; I also
connected a Windows XP box and was able to switch back and forth
between them with no problems.
	3) Three days ago, I updated the system source and did the
per-handbook system upgrade using the appended kernel config file.
	4) Since then, using the KVM - whether or not the Windows
machine is running - causes the FreeBSD box to freeze hard (requires
hardware reset).
	While I have updated installed ports (list available on
request), it seems reasonable to believe this is a OS failure and
the new kernel is responsible.
	Is there anything I left out, or put in, that would cause this
breakage?  Has snyone seen this kind of thing before?

	Respectfully,


				Robert Huff


#
# JERUSALEM --  kernel configuration file for FreeBSD/amd64
#
# For more information on this file, please read the config(5) manual page,
# and/or the handbook section on Kernel Configuration Files:
#
#    http://www.FreeBSD.org/doc/en_US.ISO8859-1/books/handbook/kernelconfig-config.html
#
# The handbook is also available locally in /usr/share/doc/handbook
# if you've installed the doc distribution, otherwise always see the
# FreeBSD World Wide Web server (http://www.FreeBSD.org/) for the
# latest information.
#
# An exhaustive list of options and more detailed explanations of the
# device lines is also present in the ../../conf/NOTES and NOTES files.
# If you are in doubt as to the purpose or necessity of a line, check first
# in NOTES.
#
# $FreeBSD: src/sys/amd64/conf/GENERIC,v 1.531.2.2 2009/08/13 17:54:11 attilio Exp $

cpu			HAMMER
ident		JERUSALEM

# To statically compile in device wiring instead of /boot/device.hints
#hints		"GENERIC.hints"		# Default places to look for devices.

# Use the following to compile in values accessible to the kernel
# through getenv() (or kenv(1) in userland). The format of the file
# is 'variable=value', see kenv(1)
#
# env		"GENERIC.env"

makeoptions	DEBUG=-g		# Build kernel with gdb(1) debug symbols

options 	SCHED_ULE		# ULE scheduler
options 	PREEMPTION		# Enable kernel thread preemption
options 	INET			# InterNETworking
options 	INET6			# IPv6 communications protocols
options 	SCTP			# Stream Control Transmission Protocol
options 	FFS			# Berkeley Fast Filesystem
options 	SOFTUPDATES		# Enable FFS soft updates support
options 	UFS_ACL			# Support for access control lists
options 	UFS_DIRHASH		# Improve performance on big directories
options 	UFS_GJOURNAL		# Enable gjournal-based UFS journaling
options 	MD_ROOT			# MD is a potential root device
options 	NFSCLIENT		# Network Filesystem Client
options 	NFSSERVER		# Network Filesystem Server
options 	NFSLOCKD		# Network Lock Manager
options 	NFS_ROOT		# NFS usable as /, requires NFSCLIENT
options 	MSDOSFS			# MSDOS Filesystem
options 	CD9660			# ISO 9660 Filesystem
options 	PROCFS			# Process filesystem (requires PSEUDOFS)
options 	PSEUDOFS		# Pseudo-filesystem framework
options 	GEOM_PART_GPT		# GUID Partition Tables.
options 	GEOM_LABEL		# Provides labelization
options 	GEOM_PART_BSD
options 	GEOM_PART_EBR
options 	GEOM_PART_EBR_COMPAT
options 	GEOM_PART_MBR
options 	COMPAT_43TTY		# BSD 4.3 TTY compat (sgtty)
options 	COMPAT_IA32		# Compatible with i386 binaries
options 	COMPAT_FREEBSD4		# Compatible with FreeBSD4
options 	COMPAT_FREEBSD5		# Compatible with FreeBSD5
options 	COMPAT_FREEBSD6		# Compatible with FreeBSD6
options 	COMPAT_FREEBSD7		# Compatible with FreeBSD7
options 	SCSI_DELAY=1000		# Delay (in ms) before probing SCSI
options 	STACK			# stack(9) support
options 	SYSVSHM			# SYSV-style shared memory
options 	SYSVMSG			# SYSV-style message queues
options 	SYSVSEM			# SYSV-style semaphores
options 	P1003_1B_SEMAPHORES	# POSIX-style semaphores
options 	_KPOSIX_PRIORITY_SCHEDULING # POSIX P1003_1B real-time extensions
options 	PRINTF_BUFR_SIZE=128	# Prevent printf output being interspersed.
options 	KBD_INSTALL_CDEV	# install a CDEV entry in /dev
options 	HWPMC_HOOKS		# Necessary kernel hooks for hwpmc(4)
options 	AUDIT			# Security event auditing
options 	MAC			# TrustedBSD MAC Framework
options	FLOWTABLE		# per-cpu routing cache

#

options   IPFIREWALL              #firewall
options   IPFIREWALL_VERBOSE      #enable logging to syslogd(8)
options   IPFIREWALL_VERBOSE_LIMIT=100    #limit verbosity
options   IPFIREWALL_DEFAULT_TO_ACCEPT    #allow everything by default
options   IPFIREWALL_NAT          #ipfw kernel nat support
options	LIBALIAS				# required for NAT

# Debugging for use in -current
options 	KDB			# Enable kernel debugger support.
options 	DDB			# Support DDB.
options 	GDB			# Support remote GDB.
options 	INVARIANTS		# Enable calls of extra sanity checking
options 	INVARIANT_SUPPORT	# Extra sanity checks of internal structures, required by INVARIANTS
options 	WITNESS			# Enable checks to detect deadlocks and cycles
options 	WITNESS_SKIPSPIN	# Don't run witness on spinlocks for speed

# Make an SMP-capable kernel by default
options 	SMP			# Symmetric MultiProcessor Kernel

# CPU frequency control
device		cpufreq

# Bus support.
device		acpi
device		pci

device		drm		# DRM core module required by DRM drivers
device		radeondrm	# ATI Radeon

# Floppy drives

# ATA and ATAPI devices
device		ata
device		atadisk		# ATA disk drives
device		ataraid		# ATA RAID drives
device		atapicd		# ATAPI CDROM drives
device		atapifd		# ATAPI floppy drives
device		atapist		# ATAPI tape drives
options 	ATA_STATIC_ID	# Static device numbering

# SCSI Controllers
					# output.  Adds ~128k to driver.
					# output.  Adds ~215k to driver.


# SCSI peripherals
device		scbus		# SCSI bus (required for SCSI)
device		ch		# SCSI media changers
device		da		# Direct Access (disks)
device		sa		# Sequential Access (tape etc)
device		cd		# CD
device		pass		# Passthrough device (direct SCSI access)
device		ses		# SCSI Environmental Services (and SAF-TE)

# RAID controllers interfaced to the SCSI subsystem
#XXX it is not 64-bit clean, -scottl

# RAID controllers
#XXX pointer/int warnings

# atkbdc0 controls both the keyboard and the PS/2 mouse

device		kbdmux		# keyboard multiplexer

device		vga		# VGA video card driver

device		splash		# Splash screen and screen saver support

# syscons is the default console driver, resembling an SCO console
device		sc

device		agp		# support several AGP chipsets

# PCCARD (PCMCIA) support
# PCMCIA and cardbus bridge support

# Serial (COM) ports
device		uart		# Generic UART driver

# Parallel port
device		ppc
device		ppbus		# Parallel port bus (required)
device		lpt		# Printer
device		plip		# TCP/IP over parallel
device		ppi		# Parallel port interface device

# If you've got a "dumb" serial or parallel PCI card that is
# supported by the puc(4) glue driver, uncomment the following
# line to enable it (connects to sio, uart and/or ppc drivers):

# PCI Ethernet NICs.

# PCI Ethernet NICs that use the common MII bus controller code.
# NOTE: Be sure to keep the 'device miibus' line in order to use these NICs!
device		miibus		# MII bus support

# ISA Ethernet NICs.  pccard NICs included.
# 'device ed' requires 'device miibus'

# Wireless NIC cards

# Pseudo devices.
device		loop		# Network loopback
device		random		# Entropy device
device		ether		# Ethernet support
device		tun		# Packet tunnel.
device		pty		# BSD-style compatibility pseudo ttys
device		md		# Memory "disks"
device		gif		# IPv6 and IPv4 tunneling
device		faith		# IPv6-to-IPv4 relaying (translation)
device		firmware	# firmware assist module

# The `bpf' device enables the Berkeley Packet Filter.
# Be aware of the administrative consequences of enabling this!
# Note that 'bpf' is required for DHCP.
device		bpf		# Berkeley packet filter

# USB support
device		uhci		# UHCI PCI->USB interface
device		ohci		# OHCI PCI->USB interface
device		ehci		# EHCI PCI->USB interface (USB 2.0)
device		usb		# USB Bus (required)
device		uhid		# "Human Interface Devices"
device		ukbd		# Keyboard
device		ulpt		# Printer
device		umass		# Disks/Mass storage - Requires scbus and da
device		ums		# Mouse
# USB Serial devices
device		uark		# Technologies ARK3116 based serial adapters
device		ubsa		# Belkin F5U103 and compatible serial adapters
device		uftdi		# For FTDI usb serial adapters
device		uipaq		# Some WinCE based devices
device		uplcom		# Prolific PL-2303 serial adapters
device		uslcom		# SI Labs CP2101/CP2102 serial adapters
device		uvisor		# Visor and Palm devices
device		uvscom		# USB serial support for DDI pocket's PHS
# USB Ethernet, requires miibus

# FireWire support

From avg at icyb.net.ua  Fri Sep 11 16:40:02 2009
From: avg at icyb.net.ua (Andriy Gapon)
Date: Fri Sep 11 16:40:08 2009
Subject: crashinfo issue in HEAD
In-Reply-To: <1252685048.31066.55.camel@buffy.york.ac.uk>
References: <4AAA54FF.9080701@icyb.net.ua>	
	<1252679211.31066.43.camel@buffy.york.ac.uk>
	<4AAA61A0.2040600@icyb.net.ua>
	<1252685048.31066.55.camel@buffy.york.ac.uk>
Message-ID: <4AAA7D5E.5050604@icyb.net.ua>

on 11/09/2009 19:04 Gavin Atkinson said the following:
> 
> Hmm, in that case this is probably a different bug to the ones already
> found, and that patch won't help.  Can you recompile ps and libkvm with
> debugging symbols, run it under gdb and get a backtrace?  Your original
> stack trace shows kvm_getprocs() calling _kvm_freeprocs(), however the
> code doesn't appear to ever do this: indeed, nothing in libkvm calls
> _kvm_freeprocs() directly.

I tried debugging this and figured out that I am stupid - my world is at older
revision than my kernel and it is couple revisions before r196990 that fixed the
problem.
So, sorry for the noise and big thanks!

-- 
Andriy Gapon
From rizzo at iet.unipi.it  Fri Sep 11 16:57:17 2009
From: rizzo at iet.unipi.it (Luigi Rizzo)
Date: Fri Sep 11 16:57:26 2009
Subject: FreeBSD timing issues and qemu (was: Re: [Qemu-devel] Re:
	Breakage with local APIC routing)
In-Reply-To: <200909111123.00257.jhb@freebsd.org>
References: <4A93BF0C.8040601@web.de>
	<20090910174640.GA30706@triton8.kn-bremen.de>
	<20090910190800.GA14191@onelab2.iet.unipi.it>
	<200909111123.00257.jhb@freebsd.org>
Message-ID: <20090911170317.GA33232@onelab2.iet.unipi.it>

On Fri, Sep 11, 2009 at 11:22:59AM -0400, John Baldwin wrote:
> On Thursday 10 September 2009 3:08:00 pm Luigi Rizzo wrote:
...
> > > Index: sys/kern/kern_timeout.c
> > > @@ -323,7 +323,7 @@ softclock(void *arg)
> > >  	steps = 0;
> > >  	cc = (struct callout_cpu *)arg;
> > >  	CC_LOCK(cc);
> > > -	while (cc->cc_softticks != ticks) {
> > > +	while (cc->cc_softticks-1 != ticks) {
> > >  		/*
> > >  		 * cc_softticks may be modified by hard clock, so cache
> > >  		 * it while we work on a given bucket.
> > > 
> > 
> > as mentioned in the followup message in that thread,
> > you also need this change in callout_tick()
> > 
> >         mtx_lock_spin_flags(&cc->cc_lock, MTX_QUIET);
> >      -  for (; (cc->cc_softticks - ticks) < 0; cc->cc_softticks++) {
> >      +  for (; (cc->cc_softticks - ticks) <= 0; cc->cc_softticks++) {
> >                 bucket = cc->cc_softticks & callwheelmask;
> 
> I would fix the style in the first hunk (spaces around '-') but I think you 
> should commit this and get it into 8.0.  I think a per-CPU ticks might prove 
> very problematic as 'ticks' is rather widely used (though I would find that 
> cleaner perhaps).

i will ask permission to re -- i was hoping to get some feedback
on the thread on -current but no response so far :(

Note that the per-cpu ticks i was proposing were only visible to the
timing wheels, which don't use absolute timeouts anyways.
So i think the mechanism would be quite safe: right now, when you
request a callout after x ticks, the code first picks a CPU
(with some criteria), then puts the request in the timer wheel for
that CPU using (now) the global 'ticks'. Replacing ticks with cc->cc_ticks,
would completely remove the races in insertion and removal.

I actually find the per-cpu ticks even less intrusive than this change.

	cheers
	luigi
From pieter at degoeje.nl  Fri Sep 11 17:25:29 2009
From: pieter at degoeje.nl (Pieter de Goeje)
Date: Fri Sep 11 17:25:52 2009
Subject: BETA3: network processes hang in keglimit (unkillable)
Message-ID: <200909111924.10927.pieter@degoeje.nl>

I just experienced a complete loss of network, where every network related 
process would sleep on "keglimit". I was unable to recover from this 
situation. I tried killing the processes with SIGKILL, but it didn't work, 
and I tried to bring the network interface (em) down and up again, which also 
didn't work. A reboot "solved" the problem. The machine was handling some 
major traffic, both TCP and UDP.

Apparently the system was waiting on some resource to free up, but what could 
it be? How can this situation be avoided in the future?

uname: 8.0-BETA3 FreeBSD 8.0-BETA3 #1: Sun Aug 30 01:23:36 CEST 2009 amd64

-- 
Pieter de Goeje
From bu7cher at yandex.ru  Fri Sep 11 17:32:43 2009
From: bu7cher at yandex.ru (Andrey V. Elsukov)
Date: Fri Sep 11 17:32:50 2009
Subject: 9.0-CURRENT - panic on detaching USB flash (not mounted)
In-Reply-To: <200909111745.29780.hselasky@c2i.net>
References: <4AAA5D61.6020900@yandex.ru> <200909111745.29780.hselasky@c2i.net>
Message-ID: <4AAA89B1.7050802@yandex.ru>

Hans Petter Selasky wrote:
> http://perforce.freebsd.org/chv.cgi?CH=168387
> 
> Download files using download link and build new kernel.

Yes, it works with this patch. Thanks.

-- 
WBR, Andrey V. Elsukov
From pyunyh at gmail.com  Fri Sep 11 17:38:51 2009
From: pyunyh at gmail.com (Pyun YongHyeon)
Date: Fri Sep 11 17:38:58 2009
Subject: BETA3: network processes hang in keglimit (unkillable)
In-Reply-To: <200909111924.10927.pieter@degoeje.nl>
References: <200909111924.10927.pieter@degoeje.nl>
Message-ID: <20090911173756.GA1100@michelle.cdnetworks.com>

On Fri, Sep 11, 2009 at 07:24:10PM +0200, Pieter de Goeje wrote:
> I just experienced a complete loss of network, where every network related 
> process would sleep on "keglimit". I was unable to recover from this 
> situation. I tried killing the processes with SIGKILL, but it didn't work, 
> and I tried to bring the network interface (em) down and up again, which also 
> didn't work. A reboot "solved" the problem. The machine was handling some 
> major traffic, both TCP and UDP.
> 
> Apparently the system was waiting on some resource to free up, but what could 
> it be? How can this situation be avoided in the future?
> 
> uname: 8.0-BETA3 FreeBSD 8.0-BETA3 #1: Sun Aug 30 01:23:36 CEST 2009 amd64
> 

Both em(4) and igb(4) had mbuf leak bug which was recently fixed by
Jack. Check mbuf statistics with "netstat -m" and see whether
you've reached mbuf resource limit(see 4K jumbo cluster counter).
The leak can be easily seen on UDP traffic, especially NFS over UDP.
From qing.li at bluecoat.com  Fri Sep 11 18:01:37 2009
From: qing.li at bluecoat.com (Li, Qing)
Date: Fri Sep 11 18:01:50 2009
Subject: NFS issues on 8.0-BETA4
In-Reply-To: <9ef3bf09fa0e081eca3965e3f0e84f82.squirrel@email.polands.org>
References: <9ef3bf09fa0e081eca3965e3f0e84f82.squirrel@email.polands.org>
Message-ID: <B583FBF374231F4A89607B4D08578A4305454467@bcs-mail03.internal.cacheflow.com>

> 
> I cannot sucessfully mount exports from the NFSv3 server on the
> 8.0-BETA4 client.  All works well with 7.2 clients.
> 
> The strange thing is, the directory in which I mount the nfs
> filesystem disappears, and I get an error when I attempt to access the
> directory.
> 

	This may be a known issue that a couple of us have been
	working on yesterday. Would you be willing to try out a 
	temporary patch?

	-- Qing

From kris at FreeBSD.org  Fri Sep 11 18:05:57 2009
From: kris at FreeBSD.org (Kris Kennaway)
Date: Fri Sep 11 18:07:02 2009
Subject: panic: sx_xlock() of destroyed sx
	@	/zoo/kris/src8/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_rlock.c:535
In-Reply-To: <4AA40E30.50109@FreeBSD.org>
References: <4AA40E30.50109@FreeBSD.org>
Message-ID: <4AAA9187.2020907@FreeBSD.org>

Kris Kennaway wrote:
> 9.0 doing I/O to a zfs:
> 
> panic: sx_xlock() of destroyed sx @ 
> /zoo/kris/src8/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_rlock.c:535 
> 
> db> wh
> Tracing pid 14 tid 100047 td 0xffffff000357c720
> kdb_enter() at kdb_enter+0x3d
> panic() at panic+0x17b
> _sx_xlock() at _sx_xlock+0xe9
> zfs_range_unlock() at zfs_range_unlock+0x38
> zfs_get_data() at zfs_get_data+0xd7
> zil_commit() at zil_commit+0x532
> zfs_sync() at zfs_sync+0xa6
> sync_fsync() at sync_fsync+0x13a
> VOP_FSYNC_APV() at VOP_FSYNC_APV+0xb7
> sync_vnode() at sync_vnode+0x157
> sched_sync() at sched_sync+0x1d1
> fork_exit() at fork_exit+0x12a
> fork_trampoline() at fork_trampoline+0xe
> --- trap 0, rip = 0, rsp = 0xffffff8125da0d30, rbp = 0 ---
> 
> This was essentially just doing make world + cvs update + tar creation 
> in a loop and failed after about a week.
> 
> Kris
> _______________________________________________
> 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"
> 
> 

Any ideas?  Machine is still in DDB.

Kris
From doug at polands.org  Fri Sep 11 19:09:24 2009
From: doug at polands.org (Doug Poland)
Date: Fri Sep 11 19:09:30 2009
Subject: NFS issues on 8.0-BETA4
In-Reply-To: <B583FBF374231F4A89607B4D08578A4305454467@bcs-mail03.internal.cacheflow.co
	m>
References: <9ef3bf09fa0e081eca3965e3f0e84f82.squirrel@email.polands.org>
	<B583FBF374231F4A89607B4D08578A4305454467@bcs-mail03.internal.cacheflow.com>
Message-ID: <e1816e4c5ee2f3cb6241424b09681a44.squirrel@email.polands.org>


On Fri, September 11, 2009 13:00, Li, Qing wrote:
>>
>> I cannot successfully mount exports from the NFSv3 server on the
>> 8.0-BETA4 client.  All works well with 7.2 clients.
>>
>> The strange thing is, the directory in which I mount the nfs
>> filesystem disappears, and I get an error when I attempt to access
>> the directory.
>>
>
> 	This may be a known issue that a couple of us have been
> 	working on yesterday. Would you be willing to try out a
> 	temporary patch?
>
> 	-- Qing
>
I'd be happy to assist anyway I can.


-- 
Regards,
Doug

From jhb at freebsd.org  Fri Sep 11 19:14:47 2009
From: jhb at freebsd.org (John Baldwin)
Date: Fri Sep 11 19:14:58 2009
Subject: FreeBSD timing issues and qemu (was: Re: [Qemu-devel] Re:
	Breakage with local APIC routing)
In-Reply-To: <20090911170317.GA33232@onelab2.iet.unipi.it>
References: <4A93BF0C.8040601@web.de> <200909111123.00257.jhb@freebsd.org>
	<20090911170317.GA33232@onelab2.iet.unipi.it>
Message-ID: <200909111301.55692.jhb@freebsd.org>

On Friday 11 September 2009 1:03:17 pm Luigi Rizzo wrote:
> On Fri, Sep 11, 2009 at 11:22:59AM -0400, John Baldwin wrote:
> > On Thursday 10 September 2009 3:08:00 pm Luigi Rizzo wrote:
> ...
> > > > Index: sys/kern/kern_timeout.c
> > > > @@ -323,7 +323,7 @@ softclock(void *arg)
> > > >  	steps = 0;
> > > >  	cc = (struct callout_cpu *)arg;
> > > >  	CC_LOCK(cc);
> > > > -	while (cc->cc_softticks != ticks) {
> > > > +	while (cc->cc_softticks-1 != ticks) {
> > > >  		/*
> > > >  		 * cc_softticks may be modified by hard clock, so cache
> > > >  		 * it while we work on a given bucket.
> > > > 
> > > 
> > > as mentioned in the followup message in that thread,
> > > you also need this change in callout_tick()
> > > 
> > >         mtx_lock_spin_flags(&cc->cc_lock, MTX_QUIET);
> > >      -  for (; (cc->cc_softticks - ticks) < 0; cc->cc_softticks++) {
> > >      +  for (; (cc->cc_softticks - ticks) <= 0; cc->cc_softticks++) {
> > >                 bucket = cc->cc_softticks & callwheelmask;
> > 
> > I would fix the style in the first hunk (spaces around '-') but I think 
you 
> > should commit this and get it into 8.0.  I think a per-CPU ticks might 
prove 
> > very problematic as 'ticks' is rather widely used (though I would find 
that 
> > cleaner perhaps).
> 
> i will ask permission to re -- i was hoping to get some feedback
> on the thread on -current but no response so far :(
> 
> Note that the per-cpu ticks i was proposing were only visible to the
> timing wheels, which don't use absolute timeouts anyways.
> So i think the mechanism would be quite safe: right now, when you
> request a callout after x ticks, the code first picks a CPU
> (with some criteria), then puts the request in the timer wheel for
> that CPU using (now) the global 'ticks'. Replacing ticks with cc->cc_ticks,
> would completely remove the races in insertion and removal.
> 
> I actually find the per-cpu ticks even less intrusive than this change.

Well, it depends.  If TCP ever started using per-CPU callouts (i.e. 
callout_reset_on()) it would probably need to start using the per-CPU ticks 
instead of the global ticks, etc.  You could have 'ticks' just be == to CPU 
0's ticks perhaps.

-- 
John Baldwin
From pieter at degoeje.nl  Fri Sep 11 19:28:24 2009
From: pieter at degoeje.nl (Pieter de Goeje)
Date: Fri Sep 11 19:28:31 2009
Subject: BETA3: network processes hang in keglimit (unkillable)
In-Reply-To: <20090911173756.GA1100@michelle.cdnetworks.com>
References: <200909111924.10927.pieter@degoeje.nl>
	<20090911173756.GA1100@michelle.cdnetworks.com>
Message-ID: <200909112128.15645.pieter@degoeje.nl>

On Friday 11 September 2009, Pyun YongHyeon wrote:
> On Fri, Sep 11, 2009 at 07:24:10PM +0200, Pieter de Goeje wrote:
> > I just experienced a complete loss of network, where every network
> > related process would sleep on "keglimit". I was unable to recover from
> > this situation. I tried killing the processes with SIGKILL, but it didn't
> > work, and I tried to bring the network interface (em) down and up again,
> > which also didn't work. A reboot "solved" the problem. The machine was
> > handling some major traffic, both TCP and UDP.
> >
> > Apparently the system was waiting on some resource to free up, but what
> > could it be? How can this situation be avoided in the future?
> >
> > uname: 8.0-BETA3 FreeBSD 8.0-BETA3 #1: Sun Aug 30 01:23:36 CEST 2009
> > amd64
>
> Both em(4) and igb(4) had mbuf leak bug which was recently fixed by
> Jack. Check mbuf statistics with "netstat -m" and see whether
> you've reached mbuf resource limit(see 4K jumbo cluster counter).
> The leak can be easily seen on UDP traffic, especially NFS over UDP.

Ok, that matches my usage (NFS over UDP), so I will monitor mbuf usage and 
test Jack's fixes when they're MFCed (or sooner if I can reproduce this).

Thank you for your reply,

Pieter de Goeje
From bf1783 at googlemail.com  Fri Sep 11 20:03:28 2009
From: bf1783 at googlemail.com (b. f.)
Date: Fri Sep 11 20:03:35 2009
Subject: vesa(4) and amd64
Message-ID: <d873d5be0909111303m3ea6d166k3f4d44025faadd77@mail.gmail.com>

After the recent x86emu/vesa/dpms commits, I'm now able to use some
more graphics modes with syscons on amd64. That's good.  Not so good
is the fact that my HP Pavilion desktop running 9-CURRENT i386 r197085
with

devic sc
options SC_PIXEL_MODE
device vga
options VGA_WIDTH90

in the kernel and agp, dpms, x86emu, and vesa loaded as kernel modules
can no longer use the 132x60 mode that had been my default syscons
mode, and now yields a blank screen.  Even worse is the fact that my
Toshiba laptop, with nearly the same configuration, locks up with a
screen full of zeroes every time I load the new vesa kernel module,
when formerly it had no such problem.  Other than simplifying the
organization of the code, is there any advantage to be gained from
forcing those platforms that are capable of native vesa to use x86emu?
 Because up to this point there are serious disadvantages to doing so.

Regards,
                b.
From rmacklem at uoguelph.ca  Fri Sep 11 20:32:39 2009
From: rmacklem at uoguelph.ca (Rick Macklem)
Date: Fri Sep 11 20:32:47 2009
Subject: NFS issues on 8.0-BETA4
In-Reply-To: <B583FBF374231F4A89607B4D08578A4305454467@bcs-mail03.internal.cacheflow.com>
References: <9ef3bf09fa0e081eca3965e3f0e84f82.squirrel@email.polands.org>
	<B583FBF374231F4A89607B4D08578A4305454467@bcs-mail03.internal.cacheflow.com>
Message-ID: <Pine.GSO.4.63.0909111621420.6191@muncher.cs.uoguelph.ca>



>>
>> I cannot sucessfully mount exports from the NFSv3 server on the
>> 8.0-BETA4 client.  All works well with 7.2 clients.
>>
>> The strange thing is, the directory in which I mount the nfs
>> filesystem disappears, and I get an error when I attempt to access the
>> directory.
>>

I went and looked at the message over in stable@ (I guess I have to join
that mailing list, too:-).

I think that the second mount attempt, which failed with errno==64
EHOSTDOWN probably gives you a better indication of what is broken
and hints at a networking problem, which hopefully others can help
with?

mount_nfs currently has the quirk that, if you don't specify either
"udp" or "tcp", it will use UDP for the mount protocol and then
switch to TCP for NFS. (I didn't make it that way, but noticed it
when I was adding changes for the experimental client.)
So, you might want to try adding "udp" or "tcp" to the mount
options for your "simplified mount" and see what happens? (I suggest
this, since it seems to have been able to talk to mountd on the server,
but not NFS on the server and the only explanation I can think of is
the switch to TCP for that.)

I think the first case failed after the retrycnt, due to the "soft"
option, but hadn't succeeded in doing any NFS Getattr, so the mount
point's type wasn't VDIR--> returning errno==1 EPERM for the "ls -l".

If the mount attempts with "udp" or "tcp" specified give you the same
behaviour, you could try using wireshark to capture the traffic.
(Wireshark is pretty good at decoding NFS traffic.) If you don't have
wireshark, you can use "tcpdump -w <file> -s 0 <host>" to capture the
traffic in a file that can be fed to wireshark later. (I'd be happy to
look at the traffic, if you were to email me the above <file>.)

Good luck with it, rick
ps: I'll assume that the client can talk to the server for other
     stuff ok.
pss: A big change between 7 and 8 is use of a new kernel RPC layer
     that handles the RPC transport (again, I wasn't the author, but
     am somewhat familiar with it).

From rmacklem at uoguelph.ca  Fri Sep 11 20:43:09 2009
From: rmacklem at uoguelph.ca (Rick Macklem)
Date: Fri Sep 11 20:43:22 2009
Subject: NFS issues on 8.0-BETA4
In-Reply-To: <Pine.GSO.4.63.0909111621420.6191@muncher.cs.uoguelph.ca>
References: <9ef3bf09fa0e081eca3965e3f0e84f82.squirrel@email.polands.org>
	<B583FBF374231F4A89607B4D08578A4305454467@bcs-mail03.internal.cacheflow.com>
	<Pine.GSO.4.63.0909111621420.6191@muncher.cs.uoguelph.ca>
Message-ID: <Pine.GSO.4.63.0909111641240.10263@muncher.cs.uoguelph.ca>



On Fri, 11 Sep 2009, Rick Macklem wrote:

>
>
>>> 
>>> I cannot sucessfully mount exports from the NFSv3 server on the
>>> 8.0-BETA4 client.  All works well with 7.2 clients.
>>> 
>>> The strange thing is, the directory in which I mount the nfs
>>> filesystem disappears, and I get an error when I attempt to access the
>>> directory.
>>> 
I just took another glance at your email and see you have your server
configured for UDP only, so that explains it.

As noted in the last posting, the current mount_nfs.c switches to
TCP for NFS by default, so...
- add "udp" to your mount options
OR
- add "-t" to your nfs_server_flags

and I think things will work better.

I vaguely recall posting w.r.t. this uses UDP for the mount protocol
and then TCP for NFS by default and didn't really get any responses.
(I'm new to this and probably posted to freebsd-fs or freebsd-arch.)
At that time, I didn't realize the change was post FreeBSD7, so I
didn't do anything more about it.

Good luck with it and let us know how it goes, rick

From oberman at es.net  Fri Sep 11 20:52:13 2009
From: oberman at es.net (Kevin Oberman)
Date: Fri Sep 11 20:52:20 2009
Subject: wpa_supplicant not found AP without SSID in beacon packet 
In-Reply-To: Your message of "Sun, 06 Sep 2009 22:40:21 +0300."
	<4AA41025.5080908@yandex.ru> 
Message-ID: <20090911205210.45DC41CC39@ptavv.es.net>

I seem to be seeing the same thing with my ath 5212. As long as the SSID
is announced, it works like a champ, but my home system does not do so
and the wpa_supplicant does not work with it on V8.

My config file:
ctrl_interface=/var/run/wpa_supplicant
ctrl_interface_group=wheel
ap_scan=1
network={
	ssid="babcom"
	scan_ssid=1
	key_mgmt=NONE
	wep_key0=01234567890...
	wep_tx_keyidx=0
}

Yes, I know I REALLY, REALLY, REALLY need to switch over to WPA. As soon
as I get some time.

I added ap_scan since the V8.0 upgrade, but it is otherwise the
configuration that worked on V7.2.

When the supplicant runs, I see the key and key index set on the
interface, fur the SSID remains blank. If I issue the command 'ifconfig
wlan0 ssid babcom', the card associates almost immediately.
-- 
R. Kevin Oberman, Network Engineer
Energy Sciences Network (ESnet)
Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab)
E-mail: oberman@es.net			Phone: +1 510 486-8634
Key fingerprint:059B 2DDF 031C 9BA3 14A4  EADA 927D EBB3 987B 3751

> Date: Sun, 06 Sep 2009 22:40:21 +0300
> From: Borodin Oleg <ziggi@yandex.ru>
> Sender: owner-freebsd-current@freebsd.org
> 
> 
> Hi!
> 
> wpa_supplicant "not found" AP without SSID in beacon packets. With same
> device and configuration, but FreeBSD7.2 - work without problems.
> 
> uname:
> FreeBSD flashbsd.home 8.0-BETA3 FreeBSD 8.0-BETA3 #4 r196775: Thu Sep  3
> 13:12:37 EEST 2009
>     ziggi@eee.home:/usr/obj/usr/src/sys/EEE04  i386
> 
> wireless device:
> ath0: <Atheros 5424/2424> mem 0xfbef0000-0xfbefffff irq 18 at device 0.0
> on pci1
> ath0@pci0:1:0:0:        class=0x020000 card=0x10261a3b chip=0x001c168c
> rev=0x01 hdr=0x00
>     vendor     = 'Atheros Communications Inc.'
>     device     = 'AR5006 family 802.11abg Wireless NIC'
>     class      = network
>     subclass   = ethernet
> 
> Access point - Cisco 877w, IOS 12.4T8
> 
> ----------- Variant 1. SSID not send in beacon packets from Cisco access
> point -
> Cisco conf fragment :
> !
> dot11 mbssid
> !
> dot11 ssid WNET1
>    vlan 1
>    authentication open.
>    authentication key-management wpa
>    wpa-psk ascii 7 10682F4857474B2D2A
> !
> dot11 ssid WNET2
>    vlan 2
>    authentication open.
>    authentication key-management wpa
>    wpa-psk ascii 7 15342D5D567A72020E
> !
> dot11 ssid WNET3
>    vlan 3
>    authentication open.
>    authentication key-management wpa
>    wpa-psk ascii 7 0220220A595656076A
> !
> 
> Result FreeBSD8Beta3 wpa_suplicant & wlandebug:
> 
> Starting AP scan (broadcast SSID)
> wlan0: ieee80211_ioctl_scanreq: flags 0x52 duration 0x7fffffff mindwell
> 0 maxdwe
> ll 0 nssid 0
> wlan0: ieee80211_check_scan: active scan, append, nojoin, once
> wlan0: sta_pick_bss: no scan candidate
> wlan0: start_scan_locked: active scan, duration 2147483647 mindwell 0
> maxdwell 0
> , desired mode auto, append, nojoin, once
> wlan0: scan set 1g, 6g, 11g, 7g, 13g, 2g, 3g, 4g, 5g, 8g, 9g, 10g, 12g,
> 14b dwel
> l min 20ms max 200ms
> wlan0: scan_task: chan   3g ->   1g [active, dwell min 20ms max 200ms]
> wlan0: send probe req on channel 1 bssid ff:ff:ff:ff:ff:ff ssid ""
> wlan0: received beacon from 00:23:5e:75:f7:c0 rssi 45
> wlan0: [00:23:5e:75:f7:c0] discard unhandled information element, id
> 133, len 30 <-------- ????
> 
> wlan0: [00:23:5e:75:f7:c0] discard beacon frame, for off-channel 3
> wlan0: received beacon from 00:23:5e:75:f7:c2 rssi 44
> wlan0: [00:23:5e:75:f7:c2] discard unhandled information element, id
> 133, len 30
> 
> wlan0: [00:23:5e:75:f7:c0] discard beacon frame, for off-channel 3
> wlan0: received beacon from 00:23:5e:75:f7:c2 rssi 46
> wlan0: [00:23:5e:75:f7:c2] discard unhandled information element, id
> 133, len 30
> 
> wlan0: [00:23:5e:75:f7:c2] discard beacon frame, for off-channel 3
> wlan0: scan_task: chan   1g ->   6g [active, dwell min 20ms max 200ms]
> wlan0: send probe req on channel 6 bssid ff:ff:ff:ff:ff:ff ssid ""
> wlan0: scan_task: chan   6g ->  11g [active, dwell min 20ms max 200ms]
> wlan0: send probe req on channel 11 bssid ff:ff:ff:ff:ff:ff ssid ""
> wlan0: scan_task: chan  11g ->   7g [active, dwell min 20ms max 200ms]
> wlan0: send probe req on channel 7 bssid ff:ff:ff:ff:ff:ff ssid ""
> wlan0: scan_task: chan   7g ->  13g [passive, dwell min 20ms max 200ms]
> EAPOL: disable timer tick
> wlan0: scan_task: chan  13g ->   2g [active, dwell min 20ms max 200ms]
> wlan0: send probe req on channel 2 bssid ff:ff:ff:ff:ff:ff ssid ""
> wlan0: received beacon from 00:23:5e:75:f7:c1 rssi 56
> wlan0: [00:23:5e:75:f7:c1] discard unhandled information element, id
> 133, len 30
> ...
> [00:23:5e:75:f7:c1] new beacon on chan 3 (bss chan 3) 0x00 rssi 55
> [00:23:5e:75:f7:c1] caps 0x431 bintval 100 erp 0x100
> wlan0: received beacon from 00:23:5e:75:f7:c2 rssi 53
> wlan0: [00:23:5e:75:f7:c2] discard unhandled information element, id
> 133, len 30
> 
> [00:23:5e:75:f7:c2] new beacon on chan 3 (bss chan 3) 0x00 rssi 53
> [00:23:5e:75:f7:c2] caps 0x431 bintval 100 erp 0x100
> wlan0: scan_task: chan   3g ->   4g [active, dwell min 20ms max 200ms]
> wlan0: send probe req on channel 4 bssid ff:ff:ff:ff:ff:ff ssid ""
> wlan0: received beacon from 00:23:5e:75:f7:c2 rssi 52
> wlan0: [00:23:5e:75:f7:c2] discard unhandled information element, id
> 133, len 30
> ...
> Scan results: 3
> CTRL-EVENT-SCAN-RESULTS
> Selecting BSS from priority group 0
> Try to find WPA-enabled AP
> 0: 00:23:5e:75:f7:c1 ssid='' wpa_ie_len=24 rsn_ie_len=0 caps=0x31
>    skip - SSID mismatch
> 1: 00:23:5e:75:f7:c2 ssid='' wpa_ie_len=24 rsn_ie_len=0 caps=0x31
>    skip - SSID mismatch
> 2: 00:23:5e:75:f7:c0 ssid='' wpa_ie_len=24 rsn_ie_len=0 caps=0x31
>    skip - SSID mismatch
> Try to find non-WPA AP
> 0: 00:23:5e:75:f7:c1 ssid='' wpa_ie_len=24 rsn_ie_len=0 caps=0x31
>    skip - SSID mismatch
> 1: 00:23:5e:75:f7:c2 ssid='' wpa_ie_len=24 rsn_ie_len=0 caps=0x31
>    skip - SSID mismatch
> 2: 00:23:5e:75:f7:c0 ssid='' wpa_ie_len=24 rsn_ie_len=0 caps=0x31
>    skip - SSID mismatch
> No suitable AP found. <---------------------
> Setting scan request: 5 sec 0 usec
> 
> ---------------- 2 On _any_ SSID in beacon packet:
> 
> dot11 ssid WNET1
>    vlan 1
>    authentication open
>    authentication key-management wpa
>    mbssid guest-mode  <--------------------------- On SSID sending
>    wpa-psk ascii 7 10682F4857474B2D2A
> !
> dot11 ssid WNET2
>    vlan 2
>    authentication open
>    authentication key-management wpa
>    wpa-psk ascii 7 15342D5D567A72020E
> !
> dot11 ssid WNET3
>    vlan 3
>    authentication open
>    authentication key-management wpa
>    wpa-psk ascii 7 0220220A595656076A
> !
> 
> Result wpa_supplicant:
> 
> Received 0 bytes of scan results (3 BSSes)
> Scan results: 3
> CTRL-EVENT-SCAN-RESULTS
> Selecting BSS from priority group 0
> Try to find WPA-enabled AP
> 0: 00:23:5e:75:f7:c1 ssid='' wpa_ie_len=24 rsn_ie_len=0 caps=0x31
>    skip - SSID mismatch
> 1: 00:23:5e:75:f7:c2 ssid='' wpa_ie_len=24 rsn_ie_len=0 caps=0x31
>    skip - SSID mismatch
> 2: 00:23:5e:75:f7:c0 ssid='WNET1' wpa_ie_len=24 rsn_ie_len=0 caps=0x31
>    selected based on WPA IE
>    selected WPA AP 00:23:5e:75:f7:c0 ssid='WNET1'
> <----------------------------------------
> Trying to associate with 00:23:5e:75:f7:c0 (SSID='WNET1' freq=2422 MHz)
> Cancelling scan request
> 
> 
> 
> /etc/wpa_upplicant.conf:
> # $Id$
> ctrl_interface=/var/run/wpa_supplicant
> ctrl_interface_group=wheel
> #eapol_version=1
> #ap_scan=1
> fast_reauth=1
> network={
>   ssid="WNET1"
> #  scan_ssid=1
>   proto=RSN WPA
>   key_mgmt=WPA-PSK
>   pairwise=CCMP TKIP
>   group=CCMP TKIP
>   psk=8c23bb58a1a94b3b56b90d8f7422a29b18f495b517f33fc6728ff2a3ad4aae1f
> }
> #EOF
> 
> --
> 
> Best regards,
> 
> Borodin Oleg
> Kaliningrad,Russia
> ziggi@inbox.ru
From oberman at es.net  Fri Sep 11 20:57:49 2009
From: oberman at es.net (Kevin Oberman)
Date: Fri Sep 11 20:58:22 2009
Subject: wpa_supplicant not found AP without SSID in beacon packet 
In-Reply-To: Your message of "Fri, 11 Sep 2009 13:52:10 PDT."
	<20090911205210.45DC41CC39@ptavv.es.net> 
Message-ID: <20090911205744.4819E1CC37@ptavv.es.net>

My sincere apologies for the top post. When I looked at it, I couldn't
believe I had done it.
-- 
R. Kevin Oberman, Network Engineer
Energy Sciences Network (ESnet)
Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab)
E-mail: oberman@es.net			Phone: +1 510 486-8634
Key fingerprint:059B 2DDF 031C 9BA3 14A4  EADA 927D EBB3 987B 3751

> Date: Fri, 11 Sep 2009 13:52:10 -0700
> From: "Kevin Oberman" <oberman@es.net>
> Sender: owner-freebsd-current@freebsd.org
> 
> I seem to be seeing the same thing with my ath 5212. As long as the SSID
> is announced, it works like a champ, but my home system does not do so
> and the wpa_supplicant does not work with it on V8.
> 
> My config file:
> ctrl_interface=/var/run/wpa_supplicant
> ctrl_interface_group=wheel
> ap_scan=1
> network={
> 	ssid="babcom"
> 	scan_ssid=1
> 	key_mgmt=NONE
> 	wep_key0=01234567890...
> 	wep_tx_keyidx=0
> }
> 
> Yes, I know I REALLY, REALLY, REALLY need to switch over to WPA. As soon
> as I get some time.
> 
> I added ap_scan since the V8.0 upgrade, but it is otherwise the
> configuration that worked on V7.2.
> 
> When the supplicant runs, I see the key and key index set on the
> interface, fur the SSID remains blank. If I issue the command 'ifconfig
> wlan0 ssid babcom', the card associates almost immediately.
> -- 
> R. Kevin Oberman, Network Engineer
> Energy Sciences Network (ESnet)
> Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab)
> E-mail: oberman@es.net			Phone: +1 510 486-8634
> Key fingerprint:059B 2DDF 031C 9BA3 14A4  EADA 927D EBB3 987B 3751
> 
> > Date: Sun, 06 Sep 2009 22:40:21 +0300
> > From: Borodin Oleg <ziggi@yandex.ru>
> > Sender: owner-freebsd-current@freebsd.org
> > 
> > 
> > Hi!
> > 
> > wpa_supplicant "not found" AP without SSID in beacon packets. With same
> > device and configuration, but FreeBSD7.2 - work without problems.
> > 
> > uname:
> > FreeBSD flashbsd.home 8.0-BETA3 FreeBSD 8.0-BETA3 #4 r196775: Thu Sep  3
> > 13:12:37 EEST 2009
> >     ziggi@eee.home:/usr/obj/usr/src/sys/EEE04  i386
> > 
> > wireless device:
> > ath0: <Atheros 5424/2424> mem 0xfbef0000-0xfbefffff irq 18 at device 0.0
> > on pci1
> > ath0@pci0:1:0:0:        class=0x020000 card=0x10261a3b chip=0x001c168c
> > rev=0x01 hdr=0x00
> >     vendor     = 'Atheros Communications Inc.'
> >     device     = 'AR5006 family 802.11abg Wireless NIC'
> >     class      = network
> >     subclass   = ethernet
> > 
> > Access point - Cisco 877w, IOS 12.4T8
> > 
> > ----------- Variant 1. SSID not send in beacon packets from Cisco access
> > point -
> > Cisco conf fragment :
> > !
> > dot11 mbssid
> > !
> > dot11 ssid WNET1
> >    vlan 1
> >    authentication open.
> >    authentication key-management wpa
> >    wpa-psk ascii 7 10682F4857474B2D2A
> > !
> > dot11 ssid WNET2
> >    vlan 2
> >    authentication open.
> >    authentication key-management wpa
> >    wpa-psk ascii 7 15342D5D567A72020E
> > !
> > dot11 ssid WNET3
> >    vlan 3
> >    authentication open.
> >    authentication key-management wpa
> >    wpa-psk ascii 7 0220220A595656076A
> > !
> > 
> > Result FreeBSD8Beta3 wpa_suplicant & wlandebug:
> > 
> > Starting AP scan (broadcast SSID)
> > wlan0: ieee80211_ioctl_scanreq: flags 0x52 duration 0x7fffffff mindwell
> > 0 maxdwe
> > ll 0 nssid 0
> > wlan0: ieee80211_check_scan: active scan, append, nojoin, once
> > wlan0: sta_pick_bss: no scan candidate
> > wlan0: start_scan_locked: active scan, duration 2147483647 mindwell 0
> > maxdwell 0
> > , desired mode auto, append, nojoin, once
> > wlan0: scan set 1g, 6g, 11g, 7g, 13g, 2g, 3g, 4g, 5g, 8g, 9g, 10g, 12g,
> > 14b dwel
> > l min 20ms max 200ms
> > wlan0: scan_task: chan   3g ->   1g [active, dwell min 20ms max 200ms]
> > wlan0: send probe req on channel 1 bssid ff:ff:ff:ff:ff:ff ssid ""
> > wlan0: received beacon from 00:23:5e:75:f7:c0 rssi 45
> > wlan0: [00:23:5e:75:f7:c0] discard unhandled information element, id
> > 133, len 30 <-------- ????
> > 
> > wlan0: [00:23:5e:75:f7:c0] discard beacon frame, for off-channel 3
> > wlan0: received beacon from 00:23:5e:75:f7:c2 rssi 44
> > wlan0: [00:23:5e:75:f7:c2] discard unhandled information element, id
> > 133, len 30
> > 
> > wlan0: [00:23:5e:75:f7:c0] discard beacon frame, for off-channel 3
> > wlan0: received beacon from 00:23:5e:75:f7:c2 rssi 46
> > wlan0: [00:23:5e:75:f7:c2] discard unhandled information element, id
> > 133, len 30
> > 
> > wlan0: [00:23:5e:75:f7:c2] discard beacon frame, for off-channel 3
> > wlan0: scan_task: chan   1g ->   6g [active, dwell min 20ms max 200ms]
> > wlan0: send probe req on channel 6 bssid ff:ff:ff:ff:ff:ff ssid ""
> > wlan0: scan_task: chan   6g ->  11g [active, dwell min 20ms max 200ms]
> > wlan0: send probe req on channel 11 bssid ff:ff:ff:ff:ff:ff ssid ""
> > wlan0: scan_task: chan  11g ->   7g [active, dwell min 20ms max 200ms]
> > wlan0: send probe req on channel 7 bssid ff:ff:ff:ff:ff:ff ssid ""
> > wlan0: scan_task: chan   7g ->  13g [passive, dwell min 20ms max 200ms]
> > EAPOL: disable timer tick
> > wlan0: scan_task: chan  13g ->   2g [active, dwell min 20ms max 200ms]
> > wlan0: send probe req on channel 2 bssid ff:ff:ff:ff:ff:ff ssid ""
> > wlan0: received beacon from 00:23:5e:75:f7:c1 rssi 56
> > wlan0: [00:23:5e:75:f7:c1] discard unhandled information element, id
> > 133, len 30
> > ...
> > [00:23:5e:75:f7:c1] new beacon on chan 3 (bss chan 3) 0x00 rssi 55
> > [00:23:5e:75:f7:c1] caps 0x431 bintval 100 erp 0x100
> > wlan0: received beacon from 00:23:5e:75:f7:c2 rssi 53
> > wlan0: [00:23:5e:75:f7:c2] discard unhandled information element, id
> > 133, len 30
> > 
> > [00:23:5e:75:f7:c2] new beacon on chan 3 (bss chan 3) 0x00 rssi 53
> > [00:23:5e:75:f7:c2] caps 0x431 bintval 100 erp 0x100
> > wlan0: scan_task: chan   3g ->   4g [active, dwell min 20ms max 200ms]
> > wlan0: send probe req on channel 4 bssid ff:ff:ff:ff:ff:ff ssid ""
> > wlan0: received beacon from 00:23:5e:75:f7:c2 rssi 52
> > wlan0: [00:23:5e:75:f7:c2] discard unhandled information element, id
> > 133, len 30
> > ...
> > Scan results: 3
> > CTRL-EVENT-SCAN-RESULTS
> > Selecting BSS from priority group 0
> > Try to find WPA-enabled AP
> > 0: 00:23:5e:75:f7:c1 ssid='' wpa_ie_len=24 rsn_ie_len=0 caps=0x31
> >    skip - SSID mismatch
> > 1: 00:23:5e:75:f7:c2 ssid='' wpa_ie_len=24 rsn_ie_len=0 caps=0x31
> >    skip - SSID mismatch
> > 2: 00:23:5e:75:f7:c0 ssid='' wpa_ie_len=24 rsn_ie_len=0 caps=0x31
> >    skip - SSID mismatch
> > Try to find non-WPA AP
> > 0: 00:23:5e:75:f7:c1 ssid='' wpa_ie_len=24 rsn_ie_len=0 caps=0x31
> >    skip - SSID mismatch
> > 1: 00:23:5e:75:f7:c2 ssid='' wpa_ie_len=24 rsn_ie_len=0 caps=0x31
> >    skip - SSID mismatch
> > 2: 00:23:5e:75:f7:c0 ssid='' wpa_ie_len=24 rsn_ie_len=0 caps=0x31
> >    skip - SSID mismatch
> > No suitable AP found. <---------------------
> > Setting scan request: 5 sec 0 usec
> > 
> > ---------------- 2 On _any_ SSID in beacon packet:
> > 
> > dot11 ssid WNET1
> >    vlan 1
> >    authentication open
> >    authentication key-management wpa
> >    mbssid guest-mode  <--------------------------- On SSID sending
> >    wpa-psk ascii 7 10682F4857474B2D2A
> > !
> > dot11 ssid WNET2
> >    vlan 2
> >    authentication open
> >    authentication key-management wpa
> >    wpa-psk ascii 7 15342D5D567A72020E
> > !
> > dot11 ssid WNET3
> >    vlan 3
> >    authentication open
> >    authentication key-management wpa
> >    wpa-psk ascii 7 0220220A595656076A
> > !
> > 
> > Result wpa_supplicant:
> > 
> > Received 0 bytes of scan results (3 BSSes)
> > Scan results: 3
> > CTRL-EVENT-SCAN-RESULTS
> > Selecting BSS from priority group 0
> > Try to find WPA-enabled AP
> > 0: 00:23:5e:75:f7:c1 ssid='' wpa_ie_len=24 rsn_ie_len=0 caps=0x31
> >    skip - SSID mismatch
> > 1: 00:23:5e:75:f7:c2 ssid='' wpa_ie_len=24 rsn_ie_len=0 caps=0x31
> >    skip - SSID mismatch
> > 2: 00:23:5e:75:f7:c0 ssid='WNET1' wpa_ie_len=24 rsn_ie_len=0 caps=0x31
> >    selected based on WPA IE
> >    selected WPA AP 00:23:5e:75:f7:c0 ssid='WNET1'
> > <----------------------------------------
> > Trying to associate with 00:23:5e:75:f7:c0 (SSID='WNET1' freq=2422 MHz)
> > Cancelling scan request
> > 
> > 
> > 
> > /etc/wpa_upplicant.conf:
> > # $Id$
> > ctrl_interface=/var/run/wpa_supplicant
> > ctrl_interface_group=wheel
> > #eapol_version=1
> > #ap_scan=1
> > fast_reauth=1
> > network={
> >   ssid="WNET1"
> > #  scan_ssid=1
> >   proto=RSN WPA
> >   key_mgmt=WPA-PSK
> >   pairwise=CCMP TKIP
> >   group=CCMP TKIP
> >   psk=8c23bb58a1a94b3b56b90d8f7422a29b18f495b517f33fc6728ff2a3ad4aae1f
> > }
> > #EOF
> > 
> > --
> > 
> > Best regards,
> > 
> > Borodin Oleg
> > Kaliningrad,Russia
> > ziggi@inbox.ru
> _______________________________________________
> 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 pjd at FreeBSD.org  Fri Sep 11 21:00:59 2009
From: pjd at FreeBSD.org (Pawel Jakub Dawidek)
Date: Fri Sep 11 21:01:10 2009
Subject: panic: sx_xlock() of destroyed sx
	@	/zoo/kris/src8/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_rlock.c:535
In-Reply-To: <4AAA9187.2020907@FreeBSD.org>
References: <4AA40E30.50109@FreeBSD.org> <4AAA9187.2020907@FreeBSD.org>
Message-ID: <20090911210053.GA2090@garage.freebsd.pl>

On Fri, Sep 11, 2009 at 07:05:59PM +0100, Kris Kennaway wrote:
> Kris Kennaway wrote:
> >9.0 doing I/O to a zfs:
> >
> >panic: sx_xlock() of destroyed sx @ 
> >/zoo/kris/src8/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_rlock.c:535 
> >
> >db> wh
> >Tracing pid 14 tid 100047 td 0xffffff000357c720
> >kdb_enter() at kdb_enter+0x3d
> >panic() at panic+0x17b
> >_sx_xlock() at _sx_xlock+0xe9
> >zfs_range_unlock() at zfs_range_unlock+0x38
> >zfs_get_data() at zfs_get_data+0xd7
> >zil_commit() at zil_commit+0x532
> >zfs_sync() at zfs_sync+0xa6
> >sync_fsync() at sync_fsync+0x13a
> >VOP_FSYNC_APV() at VOP_FSYNC_APV+0xb7
> >sync_vnode() at sync_vnode+0x157
> >sched_sync() at sched_sync+0x1d1
> >fork_exit() at fork_exit+0x12a
> >fork_trampoline() at fork_trampoline+0xe
> >--- trap 0, rip = 0, rsp = 0xffffff8125da0d30, rbp = 0 ---
> >
> >This was essentially just doing make world + cvs update + tar creation 
> >in a loop and failed after about a week.
> 
> Any ideas?  Machine is still in DDB.

I was trying to reproduce it by doing much more frequent syncs and
lowering vnodes limit, so they are inactivated more often, but I wasn't
able to reproduce it.

The problem here is that we lock a range for the given znode, but before
we unlock the range, znode is destroyed.

If you compile ZFS with debug (you have to uncomment CFLAGS+=-DDEBUG=1
in sys/modules/zfs/Makefile and recompile), we should be able to catch
who is killing the znode, because then, avl_destroy(&zp->z_range_avl)
should trigger a panic that tree isn't empty.

-- 
Pawel Jakub Dawidek                       http://www.wheel.pl
pjd@FreeBSD.org                           http://www.FreeBSD.org
FreeBSD committer                         Am I Evil? Yes, I Am!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20090911/0fceac64/attachment.pgp
From nox at jelal.kn-bremen.de  Fri Sep 11 21:37:28 2009
From: nox at jelal.kn-bremen.de (Juergen Lock)
Date: Fri Sep 11 21:37:34 2009
Subject: qemu serial: lost tx irqs (affectig FreeBSD's new uart(4) driver)
Message-ID: <20090911213508.GA97446@triton8.kn-bremen.de>

Hi!

 I got a report of FreeBSD guest's new uart(4) driver misbehaving in
qemu again(?) (output stopping for no apparent reason), and now found
out the problem is tx irqs (UART_IIR_THRI) are getting lost because
serial_update_irq() checks for the rx condtion,
	... if ((s->ier & UART_IER_RDI) && (s->lsr & UART_LSR_DR))
first before checking for the tx irq condition,
	... if ((s->ier & UART_IER_THRI) && s->thr_ipending)
which at least in this case (FreeBSD 8 guest after doing
	set console="comconsole"
at the loader prompt or when simply echo'ing text to /dev/ttyu0
or typing to the serial port from cu(1) on a `regular' vga console)
causes the second condition (.. && s->thr_ipending) to be never
reached anymore, or only after a very long delay.  Moving that
condition up so it is checked first like this,

Index: qemu/hw/serial.c
@@ -189,7 +188,9 @@ static void serial_update_irq(SerialStat
 {
     uint8_t tmp_iir = UART_IIR_NO_INT;
 
-    if ((s->ier & UART_IER_RLSI) && (s->lsr & UART_LSR_INT_ANY)) {
+    if ((s->ier & UART_IER_THRI) && s->thr_ipending) {
+        tmp_iir = UART_IIR_THRI;
+    } else if ((s->ier & UART_IER_RLSI) && (s->lsr & UART_LSR_INT_ANY)) {
         tmp_iir = UART_IIR_RLSI;
     } else if ((s->ier & UART_IER_RDI) && s->timeout_ipending) {
         /* Note that(s->ier & UART_IER_RDI) can mask this interrupt,
@@ -202,8 +203,6 @@ static void serial_update_irq(SerialStat
         } else if (s->recv_fifo.count >= s->recv_fifo.itl) {
            tmp_iir = UART_IIR_RDI;
         }
-    } else if ((s->ier & UART_IER_THRI) && s->thr_ipending) {
-        tmp_iir = UART_IIR_THRI;
     } else if ((s->ier & UART_IER_MSI) && (s->msr & UART_MSR_ANY_DELTA)) {
         tmp_iir = UART_IIR_MSI;
     }

...fixes the issue for me, but I'm not 100% sure if this might cause
rx irqs to come (too?) late when a guest keeps sending while its
receiving at the same time.  Anyone care to comment? :)

 Thanx,
	Juergen
From roberthuff at rcn.com  Fri Sep 11 22:33:52 2009
From: roberthuff at rcn.com (Robert Huff)
Date: Fri Sep 11 22:34:01 2009
Subject: custom kernel freezes when using KVM
Message-ID: <19114.53291.368699.66866@jerusalem.litteratus.org>


	1) About two weeks ago I installed 8.0beta3/amd64 on new
hardware.  Except for one problem, now solved, everything went
smoothly and I was a happy camper.
	2) Several days later I hooked it up to a (USB-) KVM; I also
connected a Windows XP box and was able to switch back and forth
between them with no problems.
	3) Three days ago, I updated the system source and did the
per-handbook system upgrade using the appended kernel config file.
	4) Since then, using the KVM - whether or not the Windows
machine is running - causes the FreeBSD box to freeze hard (requires
hardware reset).
	While I have updated installed ports (list available on
request), it seems reasonable to believe this is a OS failure and
the new kernel is responsible.
	Is there anything I left out, or put in, that would cause this
breakage?  Has snyone seen this kind of thing before?

	Respectfully,


				Robert Huff


#
# JERUSALEM --  kernel configuration file for FreeBSD/amd64
#
# For more information on this file, please read the config(5) manual page,
# and/or the handbook section on Kernel Configuration Files:
#
#    http://www.FreeBSD.org/doc/en_US.ISO8859-1/books/handbook/kernelconfig-config.html
#
# The handbook is also available locally in /usr/share/doc/handbook
# if you've installed the doc distribution, otherwise always see the
# FreeBSD World Wide Web server (http://www.FreeBSD.org/) for the
# latest information.
#
# An exhaustive list of options and more detailed explanations of the
# device lines is also present in the ../../conf/NOTES and NOTES files.
# If you are in doubt as to the purpose or necessity of a line, check first
# in NOTES.
#
# $FreeBSD: src/sys/amd64/conf/GENERIC,v 1.531.2.2 2009/08/13 17:54:11 attilio Exp $

cpu			HAMMER
ident		JERUSALEM

# To statically compile in device wiring instead of /boot/device.hints
#hints		"GENERIC.hints"		# Default places to look for devices.

# Use the following to compile in values accessible to the kernel
# through getenv() (or kenv(1) in userland). The format of the file
# is 'variable=value', see kenv(1)
#
# env		"GENERIC.env"

makeoptions	DEBUG=-g		# Build kernel with gdb(1) debug symbols

options 	SCHED_ULE		# ULE scheduler
options 	PREEMPTION		# Enable kernel thread preemption
options 	INET			# InterNETworking
options 	INET6			# IPv6 communications protocols
options 	SCTP			# Stream Control Transmission Protocol
options 	FFS			# Berkeley Fast Filesystem
options 	SOFTUPDATES		# Enable FFS soft updates support
options 	UFS_ACL			# Support for access control lists
options 	UFS_DIRHASH		# Improve performance on big directories
options 	UFS_GJOURNAL		# Enable gjournal-based UFS journaling
options 	MD_ROOT			# MD is a potential root device
options 	NFSCLIENT		# Network Filesystem Client
options 	NFSSERVER		# Network Filesystem Server
options 	NFSLOCKD		# Network Lock Manager
options 	NFS_ROOT		# NFS usable as /, requires NFSCLIENT
options 	MSDOSFS			# MSDOS Filesystem
options 	CD9660			# ISO 9660 Filesystem
options 	PROCFS			# Process filesystem (requires PSEUDOFS)
options 	PSEUDOFS		# Pseudo-filesystem framework
options 	GEOM_PART_GPT		# GUID Partition Tables.
options 	GEOM_LABEL		# Provides labelization
options 	GEOM_PART_BSD
options 	GEOM_PART_EBR
options 	GEOM_PART_EBR_COMPAT
options 	GEOM_PART_MBR
options 	COMPAT_43TTY		# BSD 4.3 TTY compat (sgtty)
options 	COMPAT_IA32		# Compatible with i386 binaries
options 	COMPAT_FREEBSD4		# Compatible with FreeBSD4
options 	COMPAT_FREEBSD5		# Compatible with FreeBSD5
options 	COMPAT_FREEBSD6		# Compatible with FreeBSD6
options 	COMPAT_FREEBSD7		# Compatible with FreeBSD7
options 	SCSI_DELAY=1000		# Delay (in ms) before probing SCSI
options 	STACK			# stack(9) support
options 	SYSVSHM			# SYSV-style shared memory
options 	SYSVMSG			# SYSV-style message queues
options 	SYSVSEM			# SYSV-style semaphores
options 	P1003_1B_SEMAPHORES	# POSIX-style semaphores
options 	_KPOSIX_PRIORITY_SCHEDULING # POSIX P1003_1B real-time extensions
options 	PRINTF_BUFR_SIZE=128	# Prevent printf output being interspersed.
options 	KBD_INSTALL_CDEV	# install a CDEV entry in /dev
options 	HWPMC_HOOKS		# Necessary kernel hooks for hwpmc(4)
options 	AUDIT			# Security event auditing
options 	MAC			# TrustedBSD MAC Framework
options	FLOWTABLE		# per-cpu routing cache

#

options   IPFIREWALL              #firewall
options   IPFIREWALL_VERBOSE      #enable logging to syslogd(8)
options   IPFIREWALL_VERBOSE_LIMIT=100    #limit verbosity
options   IPFIREWALL_DEFAULT_TO_ACCEPT    #allow everything by default
options   IPFIREWALL_NAT          #ipfw kernel nat support
options	LIBALIAS				# required for NAT

# Debugging for use in -current
options 	KDB			# Enable kernel debugger support.
options 	DDB			# Support DDB.
options 	GDB			# Support remote GDB.
options 	INVARIANTS		# Enable calls of extra sanity checking
options 	INVARIANT_SUPPORT	# Extra sanity checks of internal structures, required by INVARIANTS
options 	WITNESS			# Enable checks to detect deadlocks and cycles
options 	WITNESS_SKIPSPIN	# Don't run witness on spinlocks for speed

# Make an SMP-capable kernel by default
options 	SMP			# Symmetric MultiProcessor Kernel

# CPU frequency control
device		cpufreq

# Bus support.
device		acpi
device		pci

device		drm		# DRM core module required by DRM drivers
device		radeondrm	# ATI Radeon

# Floppy drives

# ATA and ATAPI devices
device		ata
device		atadisk		# ATA disk drives
device		ataraid		# ATA RAID drives
device		atapicd		# ATAPI CDROM drives
device		atapifd		# ATAPI floppy drives
device		atapist		# ATAPI tape drives
options 	ATA_STATIC_ID	# Static device numbering

# SCSI Controllers
					# output.  Adds ~128k to driver.
					# output.  Adds ~215k to driver.


# SCSI peripherals
device		scbus		# SCSI bus (required for SCSI)
device		ch		# SCSI media changers
device		da		# Direct Access (disks)
device		sa		# Sequential Access (tape etc)
device		cd		# CD
device		pass		# Passthrough device (direct SCSI access)
device		ses		# SCSI Environmental Services (and SAF-TE)

# RAID controllers interfaced to the SCSI subsystem
#XXX it is not 64-bit clean, -scottl

# RAID controllers
#XXX pointer/int warnings

# atkbdc0 controls both the keyboard and the PS/2 mouse

device		kbdmux		# keyboard multiplexer

device		vga		# VGA video card driver

device		splash		# Splash screen and screen saver support

# syscons is the default console driver, resembling an SCO console
device		sc

device		agp		# support several AGP chipsets

# PCCARD (PCMCIA) support
# PCMCIA and cardbus bridge support

# Serial (COM) ports
device		uart		# Generic UART driver

# Parallel port
device		ppc
device		ppbus		# Parallel port bus (required)
device		lpt		# Printer
device		plip		# TCP/IP over parallel
device		ppi		# Parallel port interface device

# If you've got a "dumb" serial or parallel PCI card that is
# supported by the puc(4) glue driver, uncomment the following
# line to enable it (connects to sio, uart and/or ppc drivers):

# PCI Ethernet NICs.

# PCI Ethernet NICs that use the common MII bus controller code.
# NOTE: Be sure to keep the 'device miibus' line in order to use these NICs!
device		miibus		# MII bus support

# ISA Ethernet NICs.  pccard NICs included.
# 'device ed' requires 'device miibus'

# Wireless NIC cards

# Pseudo devices.
device		loop		# Network loopback
device		random		# Entropy device
device		ether		# Ethernet support
device		tun		# Packet tunnel.
device		pty		# BSD-style compatibility pseudo ttys
device		md		# Memory "disks"
device		gif		# IPv6 and IPv4 tunneling
device		faith		# IPv6-to-IPv4 relaying (translation)
device		firmware	# firmware assist module

# The `bpf' device enables the Berkeley Packet Filter.
# Be aware of the administrative consequences of enabling this!
# Note that 'bpf' is required for DHCP.
device		bpf		# Berkeley packet filter

# USB support
device		uhci		# UHCI PCI->USB interface
device		ohci		# OHCI PCI->USB interface
device		ehci		# EHCI PCI->USB interface (USB 2.0)
device		usb		# USB Bus (required)
device		uhid		# "Human Interface Devices"
device		ukbd		# Keyboard
device		ulpt		# Printer
device		umass		# Disks/Mass storage - Requires scbus and da
device		ums		# Mouse
# USB Serial devices
device		uark		# Technologies ARK3116 based serial adapters
device		ubsa		# Belkin F5U103 and compatible serial adapters
device		uftdi		# For FTDI usb serial adapters
device		uipaq		# Some WinCE based devices
device		uplcom		# Prolific PL-2303 serial adapters
device		uslcom		# SI Labs CP2101/CP2102 serial adapters
device		uvisor		# Visor and Palm devices
device		uvscom		# USB serial support for DDI pocket's PHS
# USB Ethernet, requires miibus

# FireWire support

From oberman at es.net  Fri Sep 11 23:03:16 2009
From: oberman at es.net (Kevin Oberman)
Date: Fri Sep 11 23:03:22 2009
Subject: Fix for /usr/src/Makefile.inc1 in 8.0? (pr conf/137483)
Message-ID: <20090911230311.21FB21CC37@ptavv.es.net>

Some time ago it was noticed (by both myself and others) that the
conditional code to implement some of the system build options in
src.conf(5) was badly broken. Several options with broke the build or
just didn't work correctly. Mostly incorrect nesting of if statements
in the file.

b.f. has made a patch for this and submitted it some time ago to re, but
I suspect that it fell through the cracks with all of the critical
issues to be attended to before 8.0 is ready.

The PR is conf/137483.

The breakage to buildworld is unquestionable and will bite a lot of
systems when 8.0 is released. The patch is pretty straight-forward. I
have been using it since I started running 8.0 a couple of months ago.

I know RE has a lot to do in a very short time, but I would really hope
that this can be addressed. And, if it can't be done for 8.0, can
someone at least commit this to HEAD so it can be MFCed to make it
easier for those who hit this problem in 8.0-RELEASE?
-- 
R. Kevin Oberman, Network Engineer
Energy Sciences Network (ESnet)
Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab)
E-mail: oberman@es.net			Phone: +1 510 486-8634
Key fingerprint:059B 2DDF 031C 9BA3 14A4  EADA 927D EBB3 987B 3751
From ddkprog at yahoo.com  Fri Sep 11 17:50:14 2009
From: ddkprog at yahoo.com (ddk ddk)
Date: Fri Sep 11 23:43:53 2009
Subject: vesa(4) and amd64
In-Reply-To: <20090911155001.GU2829@hoeg.nl>
Message-ID: <898308.64226.qm@web59103.mail.re1.yahoo.com>

> > ddk ddk wrote:
> >? I think this is a problem that has added a new
> terminal
> >? teken by ed@
> >? 
> >? becouse there is no problem on freebsd 7 where
> is no teken
> >? where I can switch to any low mode 
> 
> Hmmm... As far as I know, syscons reinitializes the
> terminal completely
> when switching resolutions. Does it crash? If so, are you
> capable of
> obtainining a backtrace?
> 
> In my newcons branch I do have a very small patch for
> libteken that
> changes the resizing behaviour. In my new vt console driver
> I do resize
> the terminal emulator without reinitializing it completely,
> so I had to
> make set_winsize() a bit more robust.
> 
> I think it's very unlikely that this patch fixes the issue
> you are
> seeing, but please do try.
> 

the problem was localized 
No more problems with switching to decrease the screen resolution in graphics modes 
(I just updated to tag =. 
I used to use its working version of freebsd consisting of many patches) 

but exists problem in switching graphic screen back to text mode on ttyv0
but only on ttyv0

I can not provide backtrace because the system is fully freezes

sequence that leads to the problem 
1) boot freebsd 
2) stay only on ttyv0
3) kldload vesa 
4) vidcontrol MODE_277 (800x600x32)
5) vidcontrol MODE_24  (80x24 text mode)

The system immediately freezes
switch to any of the consoles is an infinite beeeeeep

if you do the same but on another ttyvX (/dev/ttyv1 .../dev/ttyv9)
then there is no problem


> -- 
>  Ed Schouten <ed@80386.nl>
>  WWW: http://80386.nl/
> 


      
From ed at 80386.nl  Fri Sep 11 23:48:24 2009
From: ed at 80386.nl (Ed Schouten)
Date: Fri Sep 11 23:48:31 2009
Subject: vesa(4) and amd64
In-Reply-To: <898308.64226.qm@web59103.mail.re1.yahoo.com>
References: <20090911155001.GU2829@hoeg.nl>
	<898308.64226.qm@web59103.mail.re1.yahoo.com>
Message-ID: <20090911234823.GW2829@hoeg.nl>

Hi,

* ddk ddk <ddkprog@yahoo.com> wrote:
> if you do the same but on another ttyvX (/dev/ttyv1 .../dev/ttyv9)
> then there is no problem

I suspect this has something to do with the fact that the screen buffer
for window 0 is differently allocated than the other ones, because it
has to be statically allocated to work very early on...

-- 
 Ed Schouten <ed@80386.nl>
 WWW: http://80386.nl/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20090911/51c9ab4d/attachment.pgp
From ddkprog at yahoo.com  Sat Sep 12 00:29:24 2009
From: ddkprog at yahoo.com (ddk ddk)
Date: Sat Sep 12 00:39:19 2009
Subject: vesa(4) and amd64
In-Reply-To: <20090911234823.GW2829@hoeg.nl>
Message-ID: <904348.4868.qm@web59104.mail.re1.yahoo.com>


> * ddk
> wrote:
> > if you do the same but on another ttyvX (/dev/ttyv1
> .../dev/ttyv9)
> > then there is no problem
> 
> I suspect this has something to do with the fact that the
> screen buffer
> for window 0 is differently allocated than the other ones,
> because it
> has to be statically allocated to work very early on...
> 

I surprised 
even without the driver vesa
using only

options SC_PIXEL_MODE 
options VGA_WIDTH90 

I got the same freezing 
but on the other consoles 

I will update the 9-current on my laptop with i386 arch and trying to duplicate these bugs 

quite possible that arch amd64 bug

> -- 
>  Ed Schouten <ed@80386.nl>
>  WWW: http://80386.nl/
> 


      
From delphij at delphij.net  Sat Sep 12 02:03:55 2009
From: delphij at delphij.net (Xin LI)
Date: Sat Sep 12 02:04:03 2009
Subject: vesa(4) and amd64
In-Reply-To: <d873d5be0909111303m3ea6d166k3f4d44025faadd77@mail.gmail.com>
References: <d873d5be0909111303m3ea6d166k3f4d44025faadd77@mail.gmail.com>
Message-ID: <4AAB017D.7090909@delphij.net>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,

b. f. wrote:
> After the recent x86emu/vesa/dpms commits, I'm now able to use some
> more graphics modes with syscons on amd64. That's good.  Not so good
> is the fact that my HP Pavilion desktop running 9-CURRENT i386 r197085
> with
> 
> devic sc
> options SC_PIXEL_MODE
> device vga
> options VGA_WIDTH90
> 
> in the kernel and agp, dpms, x86emu, and vesa loaded as kernel modules
> can no longer use the 132x60 mode that had been my default syscons
> mode, and now yields a blank screen.  Even worse is the fact that my
> Toshiba laptop, with nearly the same configuration, locks up with a
> screen full of zeroes every time I load the new vesa kernel module,
> when formerly it had no such problem.  Other than simplifying the
> organization of the code, is there any advantage to be gained from
> forcing those platforms that are capable of native vesa to use x86emu?
>  Because up to this point there are serious disadvantages to doing so.

I think it was caused by some unrelated change.  ddkprog@ has proposed a
change, here is a slightly modified one, could you please give it a try?
 I'll try to see if I can have some clue myself tonight.

Cheers,
- --
Xin LI <delphij@delphij.net>	http://www.delphij.net/
FreeBSD - The Power to Serve!
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.12 (FreeBSD)

iEYEARECAAYFAkqrAXwACgkQi+vbBBjt66AK3wCgj9fnz60SWIIa7OUAdF/4x8aR
evsAoJ3A8QObHWMYXsOXwKbuCBR0pxKe
=Sr3u
-----END PGP SIGNATURE-----
-------------- next part --------------
Index: sys/dev/fb/vesa.c
===================================================================
--- sys/dev/fb/vesa.c	(revision 197050)
+++ sys/dev/fb/vesa.c	(working copy)
@@ -1126,7 +1126,7 @@
 	} else {
 		vesa_adp->va_buffer = 0;
 		vesa_adp->va_buffer_size = info.vi_buffer_size;
-		vesa_adp->va_window = (vm_offset_t)(emumem+L_ADD(info.vi_window));
+		vesa_adp->va_window = info.vi_window + KERNBASE;
 		vesa_adp->va_window_size = info.vi_window_size;
 		vesa_adp->va_window_gran = info.vi_window_gran;
 	}
From pj at smo.de  Sat Sep 12 02:46:32 2009
From: pj at smo.de (Philipp Ost)
Date: Sat Sep 12 02:46:39 2009
Subject: [BETA2] Floppy drive no longer accessible
Message-ID: <4AAABBCB.8050302@smo.de>

Hi guys,

I'm running 8.0-BETA2 (i386) and have some problems concerning my floppy 
drive -- it's no longer accessible because there's no entry in /dev:

$ find /dev -name \*fd\*
/dev/fd
$

dmesg reports:
$ dmesg | grep fd
fdc1: <floppy drive controller> port 0x3f2-0x3f5,0x3f7 irq 6 drq 2 on acpi0
fdc1: [FILTER]
fdc0: No FDOUT register!
kern_openat(c44a7240,ffffff9c,bfbfd81b,0,a02,...) at kern_openat+0x11f
kern_open(c44a7240,bfbfd81b,0,a01,180,...) at kern_open+0x35
--- syscall (5, FreeBSD ELF32, open), eip = 0x33f8f203, esp = 
0xbfbfd3ec, ebp = 0xbfbfdc88 ---
$

Asking Google for help on this, I did only find threads dating back to 
2004. It used to work perfectly fine with 7.2-STABLE, but that's not 
much help now I guess ;-)

Any hints on this?
I think I'm going to upgrade to BETA4 -- it can only get better...

I'm happy to provide more information if needed.


Thanks for your help,
Philipp
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 4974 bytes
Desc: S/MIME Cryptographic Signature
Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20090912/48669667/smime.bin
From bruce at cran.org.uk  Sat Sep 12 03:34:04 2009
From: bruce at cran.org.uk (Bruce Cran)
Date: Sat Sep 12 03:34:10 2009
Subject: [BETA2] Floppy drive no longer accessible
In-Reply-To: <4AAABBCB.8050302@smo.de>
References: <4AAABBCB.8050302@smo.de>
Message-ID: <20090912043408.00000f6d@unknown>

On Fri, 11 Sep 2009 23:06:19 +0200
Philipp Ost <pj@smo.de> wrote:

> Hi guys,
> 
> I'm running 8.0-BETA2 (i386) and have some problems concerning my
> floppy drive -- it's no longer accessible because there's no entry
> in /dev:
> 
> $ find /dev -name \*fd\*
> /dev/fd
> $

There was a regression in the ACPI code that was fixed after 8.0-BETA2
- see the thread "fdc(4) regression: fdc0 fails to probe" for details.

-- 
Bruce Cran
From jh at saunalahti.fi  Sat Sep 12 09:03:59 2009
From: jh at saunalahti.fi (Jaakko Heinonen)
Date: Sat Sep 12 09:04:07 2009
Subject: panic: sx_xlock() of destroyed sx @
	/zoo/kris/src8/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/co
	mmon/fs/zfs/zfs_rlock.c:535
In-Reply-To: <20090911210053.GA2090@garage.freebsd.pl>
References: <4AA40E30.50109@FreeBSD.org> <4AAA9187.2020907@FreeBSD.org>
	<20090911210053.GA2090@garage.freebsd.pl>
Message-ID: <20090912090353.GA806@a91-153-125-115.elisa-laajakaista.fi>

On 2009-09-11, Pawel Jakub Dawidek wrote:
> > >panic: sx_xlock() of destroyed sx @ 
> > >/zoo/kris/src8/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_rlock.c:535 
> 
> I was trying to reproduce it by doing much more frequent syncs and
> lowering vnodes limit, so they are inactivated more often, but I wasn't
> able to reproduce it.
> 
> The problem here is that we lock a range for the given znode, but before
> we unlock the range, znode is destroyed.

I wonder if this could be related to PR kern/132068 (i.e. zfs_zget() can
return reclaimed vnodes).

If you can reproduce the panic you could try this patch:

http://www.saunalahti.fi/~jh3/patches/zfs_zget-vnode-reclaim-race.diff

-- 
Jaakko
From olivier at cochard.me  Sat Sep 12 11:21:07 2009
From: olivier at cochard.me (=?ISO-8859-1?Q?Olivier_Cochard=2DLabb=E9?=)
Date: Sat Sep 12 11:33:07 2009
Subject: qemu serial: lost tx irqs (affectig FreeBSD's new uart(4)
	driver)
In-Reply-To: <20090911213508.GA97446@triton8.kn-bremen.de>
References: <20090911213508.GA97446@triton8.kn-bremen.de>
Message-ID: <3131aa530909120420ge13c7arfd1eb6e9224d6581@mail.gmail.com>

Hi,

On Fri, Sep 11, 2009 at 11:35 PM, Juergen Lock <nox@jelal.kn-bremen.de> wrote:

> ...fixes the issue for me, but I'm not 100% sure if this might cause
> rx irqs to come (too?) late when a guest keeps sending while its
> receiving at the same time. ?Anyone care to comment? :)
>

Your patch fix the issue for me too.

Thanks a lot's Juergen !

Regards,

Olivier
From doug at polands.org  Sat Sep 12 14:41:15 2009
From: doug at polands.org (Doug Poland)
Date: Sat Sep 12 14:41:30 2009
Subject: NFS issues on 8.0-BETA4
In-Reply-To: <Pine.GSO.4.63.0909111621420.6191@muncher.cs.uoguelph.ca>
References: <9ef3bf09fa0e081eca3965e3f0e84f82.squirrel@email.polands.org>
	<B583FBF374231F4A89607B4D08578A4305454467@bcs-mail03.internal.cacheflow.com>
	<Pine.GSO.4.63.0909111621420.6191@muncher.cs.uoguelph.ca>
Message-ID: <19c32ef4263ed3c2ab1624a43ae86c78.squirrel@email.polands.org>

On Fri, September 11, 2009 15:37, Rick Macklem wrote:
>
>>>
>>> I cannot sucessfully mount exports from the NFSv3 server on the
>>> 8.0-BETA4 client.  All works well with 7.2 clients.
>>>
>>> The strange thing is, the directory in which I mount the nfs
>>> filesystem disappears, and I get an error when I attempt to
>>> access the directory.
>>>
>
> I went and looked at the message over in stable@ (I guess I have to
> join that mailing list, too:-).
>
> I think that the second mount attempt, which failed with errno==64
> EHOSTDOWN probably gives you a better indication of what is broken
> and hints at a networking problem, which hopefully others can help
> with?
>
> mount_nfs currently has the quirk that, if you don't specify either
> "udp" or "tcp", it will use UDP for the mount protocol and then
> switch to TCP for NFS. (I didn't make it that way, but noticed it
> when I was adding changes for the experimental client.) So, you might
> want to try adding "udp" or "tcp" to the mount options for your
> "simplified mount" and see what happens? (I suggest this, since it
> seems to have been able to talk to mountd on the server, but not NFS
> on the server and the only explanation I can think of is the switch
> to TCP for that.)
>
> I think the first case failed after the retrycnt, due to the "soft"
> option, but hadn't succeeded in doing any NFS Getattr, so the mount
> point's type wasn't VDIR--> returning errno==1 EPERM for the "ls -l".
>
>
> If the mount attempts with "udp" or "tcp" specified give you the same
>  behaviour, you could try using wireshark to capture the traffic.
> (Wireshark is pretty good at decoding NFS traffic.) If you don't have
>  wireshark, you can use "tcpdump -w <file> -s 0 <host>" to capture
> the traffic in a file that can be fed to wireshark later. (I'd be
> happy to look at the traffic, if you were to email me the above
> <file>.)
>
> Good luck with it, rick ps: I'll assume that the client can talk to
> the server for other stuff ok. pss: A big change between 7 and 8 is
> use of a new kernel RPC layer that handles the RPC transport (again,
> I wasn't the author, but am somewhat familiar with it).
>
>
Simply adding -o udp to my mount command made the NFS mount work
correctly.  Qing, would it be beneficial to attempt the patch in light
of these findings?

Thanks all for the help, sorry for the noise.


-- 
Regards,
Doug

From pjd at FreeBSD.org  Sat Sep 12 15:32:41 2009
From: pjd at FreeBSD.org (Pawel Jakub Dawidek)
Date: Sat Sep 12 15:32:48 2009
Subject: panic: sx_xlock() of destroyed sx @
	/zoo/kris/src8/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/co
	mmon/fs/zfs/zfs_rlock.c:535
In-Reply-To: <20090912090353.GA806@a91-153-125-115.elisa-laajakaista.fi>
References: <4AA40E30.50109@FreeBSD.org> <4AAA9187.2020907@FreeBSD.org>
	<20090911210053.GA2090@garage.freebsd.pl>
	<20090912090353.GA806@a91-153-125-115.elisa-laajakaista.fi>
Message-ID: <20090912153230.GA5522@garage.freebsd.pl>

On Sat, Sep 12, 2009 at 12:03:53PM +0300, Jaakko Heinonen wrote:
> On 2009-09-11, Pawel Jakub Dawidek wrote:
> > > >panic: sx_xlock() of destroyed sx @ 
> > > >/zoo/kris/src8/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_rlock.c:535 
> > 
> > I was trying to reproduce it by doing much more frequent syncs and
> > lowering vnodes limit, so they are inactivated more often, but I wasn't
> > able to reproduce it.
> > 
> > The problem here is that we lock a range for the given znode, but before
> > we unlock the range, znode is destroyed.
> 
> I wonder if this could be related to PR kern/132068 (i.e. zfs_zget() can
> return reclaimed vnodes).
> 
> If you can reproduce the panic you could try this patch:
> 
> http://www.saunalahti.fi/~jh3/patches/zfs_zget-vnode-reclaim-race.diff

Good catch. I modifed the kernel to reclaim all vnodes on every
getnewvnode() and also slowed down zfs_reclaim_complete() and I was able
to reproduce this race. I also found another problem - when we defer
znode destruction there is a race where file system unmount or rollback
can be called between zfs_freebsd_reclaim() and zfs_reclaim_complete(),
which can case various problems. I almost have a patch ready, but it
needs some more work. I'll post it ASAP.

-- 
Pawel Jakub Dawidek                       http://www.wheel.pl
pjd@FreeBSD.org                           http://www.FreeBSD.org
FreeBSD committer                         Am I Evil? Yes, I Am!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20090912/623b311c/attachment.pgp
From rizzo at iet.unipi.it  Sat Sep 12 15:42:36 2009
From: rizzo at iet.unipi.it (Luigi Rizzo)
Date: Sat Sep 12 15:42:43 2009
Subject: FreeBSD timing issues and qemu (was: Re: [Qemu-devel] Re:
	Breakage with local APIC routing)
In-Reply-To: <200909111301.55692.jhb@freebsd.org>
References: <4A93BF0C.8040601@web.de> <200909111123.00257.jhb@freebsd.org>
	<20090911170317.GA33232@onelab2.iet.unipi.it>
	<200909111301.55692.jhb@freebsd.org>
Message-ID: <20090912154836.GA47410@onelab2.iet.unipi.it>

On Fri, Sep 11, 2009 at 01:01:54PM -0400, John Baldwin wrote:
> On Friday 11 September 2009 1:03:17 pm Luigi Rizzo wrote:
...
> > Note that the per-cpu ticks i was proposing were only visible to the
> > timing wheels, which don't use absolute timeouts anyways.
> > So i think the mechanism would be quite safe: right now, when you
> > request a callout after x ticks, the code first picks a CPU
> > (with some criteria), then puts the request in the timer wheel for
> > that CPU using (now) the global 'ticks'. Replacing ticks with cc->cc_ticks,
> > would completely remove the races in insertion and removal.
> > 
> > I actually find the per-cpu ticks even less intrusive than this change.
> 
> Well, it depends.  If TCP ever started using per-CPU callouts (i.e. 
> callout_reset_on())

It seems that this is already the case in practice.

callout_reset() is just #defined to callout_reset_on(c, ... c->cc_cpu)
so all calls end up there.
c->cc_cpu is initialized in callout_init as c->c_cpu = timeout_cpu;
(which is a static int variable; i still don't understand what is
the final value it gets, because the comment says that
kern_timeout_callwheel_alloc() can be called multiple times
and here is where timeout_cpu is initialized.)

cheers
luigi
From nox at jelal.kn-bremen.de  Sat Sep 12 16:53:56 2009
From: nox at jelal.kn-bremen.de (Juergen Lock)
Date: Sat Sep 12 16:54:03 2009
Subject: qemu serial: lost tx irqs (affectig FreeBSD's new uart(4)
 driver)
In-Reply-To: <4AAB938B.9080004@web.de>
References: <20090911213508.GA97446@triton8.kn-bremen.de>
	<4AAB938B.9080004@web.de>
Message-ID: <20090912165222.GA38048@triton8.kn-bremen.de>

On Sat, Sep 12, 2009 at 02:26:51PM +0200, Jan Kiszka wrote:
> Juergen Lock wrote:
> > Hi!
> > 
> >  I got a report of FreeBSD guest's new uart(4) driver misbehaving in
> > qemu again(?) (output stopping for no apparent reason), and now found
> > out the problem is tx irqs (UART_IIR_THRI) are getting lost because
> > serial_update_irq() checks for the rx condtion,
> > 	... if ((s->ier & UART_IER_RDI) && (s->lsr & UART_LSR_DR))
> > first before checking for the tx irq condition,
> > 	... if ((s->ier & UART_IER_THRI) && s->thr_ipending)
> > which at least in this case (FreeBSD 8 guest after doing
> > 	set console="comconsole"
> > at the loader prompt or when simply echo'ing text to /dev/ttyu0
> > or typing to the serial port from cu(1) on a `regular' vga console)
> > causes the second condition (.. && s->thr_ipending) to be never
> > reached anymore, or only after a very long delay.  Moving that
> > condition up so it is checked first like this,
> > 
> > Index: qemu/hw/serial.c
> > @@ -189,7 +188,9 @@ static void serial_update_irq(SerialStat
> >  {
> >      uint8_t tmp_iir = UART_IIR_NO_INT;
> >  
> > -    if ((s->ier & UART_IER_RLSI) && (s->lsr & UART_LSR_INT_ANY)) {
> > +    if ((s->ier & UART_IER_THRI) && s->thr_ipending) {
> > +        tmp_iir = UART_IIR_THRI;
> > +    } else if ((s->ier & UART_IER_RLSI) && (s->lsr & UART_LSR_INT_ANY)) {
> >          tmp_iir = UART_IIR_RLSI;
> >      } else if ((s->ier & UART_IER_RDI) && s->timeout_ipending) {
> >          /* Note that(s->ier & UART_IER_RDI) can mask this interrupt,
> > @@ -202,8 +203,6 @@ static void serial_update_irq(SerialStat
> >          } else if (s->recv_fifo.count >= s->recv_fifo.itl) {
> >             tmp_iir = UART_IIR_RDI;
> >          }
> > -    } else if ((s->ier & UART_IER_THRI) && s->thr_ipending) {
> > -        tmp_iir = UART_IIR_THRI;
> >      } else if ((s->ier & UART_IER_MSI) && (s->msr & UART_MSR_ANY_DELTA)) {
> >          tmp_iir = UART_IIR_MSI;
> >      }
> > 
> > ...fixes the issue for me, but I'm not 100% sure if this might cause
> > rx irqs to come (too?) late when a guest keeps sending while its
> > receiving at the same time.  Anyone care to comment? :)
> 
> The reordering violates the 16550A spec in that RX event overrules TX in
> the IRQ status register. Maybe something else is wrong but it's not the
> ordering in serial_update_irq.

Well one problem seems to be the rx condition,
 	... if ((s->ier & UART_IER_RDI) && (s->lsr & UART_LSR_DR))
is not enough to trigger an irq, yet still causes the following
conditions not to be checked anymore at all.  And ideed, fixing that
seems to get my FreeBSD 8 guest back to working order as well:

Index: qemu/hw/serial.c
@@ -196,12 +195,10 @@ static void serial_update_irq(SerialStat
          * this is not in the specification but is observed on existing
          * hardware.  */
         tmp_iir = UART_IIR_CTI;
-    } else if ((s->ier & UART_IER_RDI) && (s->lsr & UART_LSR_DR)) {
-        if (!(s->fcr & UART_FCR_FE)) {
-           tmp_iir = UART_IIR_RDI;
-        } else if (s->recv_fifo.count >= s->recv_fifo.itl) {
-           tmp_iir = UART_IIR_RDI;
-        }
+    } else if ((s->ier & UART_IER_RDI) && (s->lsr & UART_LSR_DR) &&
+               (!(s->fcr & UART_FCR_FE) ||
+                s->recv_fifo.count >= s->recv_fifo.itl)) {
+        tmp_iir = UART_IIR_RDI;
     } else if ((s->ier & UART_IER_THRI) && s->thr_ipending) {
         tmp_iir = UART_IIR_THRI;
     } else if ((s->ier & UART_IER_MSI) && (s->msr & UART_MSR_ANY_DELTA)) {

 Signed-off-by: Juergen Lock <nox@jelal.kn-bremen.de>
From admin at lissyara.su  Sat Sep 12 18:01:13 2009
From: admin at lissyara.su (Alex Keda)
Date: Sat Sep 12 18:01:20 2009
Subject: make installworld failure
Message-ID: <4AABD9E2.4030704@lissyara.su>

I have problem, some as 
http://lists.freebsd.org/pipermail/freebsd-current/2009-June/007604.html
if I install as:
make -d A installworld
I have
...........
Searching for 
be_BY.UTF-8.msg.../usr/src/lib/libc.../usr/src/lib/libc/db/btree.../usr/src/lib/libc/db/db.../usr/src/lib/libc/db/hash.../usr/src/lib/libc/db/man.../usr/src/lib/libc/db/mpool.../usr/src/lib/libc/db/recno.../usr/src/lib/libc/compat-43.../usr/src/lib/libc/gdtoa.../usr/src/lib/libc/i386/gen.../usr/src/lib/libc/gen.../usr/src/lib/libc/gmon.../usr/src/lib/libc/inet.../usr/src/lib/libc/isc.../usr/src/lib/libc/locale.../usr/src/lib/libc/nameser.../usr/src/lib/libc/net.../usr/src/lib/libc/nls...here...returning 
/usr/src/lib/libc/nls/be_BY.UTF-8.msg
be_BY.UTF-8.msg:@ = /usr/src/lib/libc/nls/be_BY.UTF-8.msg
be_BY.UTF-8.msg:* = be_BY.UTF-8
be_BY.UTF-8.cat:< = /usr/src/lib/libc/nls/be_BY.UTF-8.msg
Examining be_BY.UTF-8.msg...modified 19:48:32 Jul 03, 2009...up-to-date.
Examining be_BY.UTF-8.cat...modified 21:21:15 Feb 27, 2009...modified 
before source (/usr/src/lib/libc/nls/be_BY.UTF-8.msg)...out-of-date.
be_BY.UTF-8.cat:> = /usr/src/lib/libc/nls/be_BY.UTF-8.msg
be_BY.UTF-8.cat:? = /usr/src/lib/libc/nls/be_BY.UTF-8.msg
gencat be_BY.UTF-8.cat /usr/src/lib/libc/nls/be_BY.UTF-8.msg
gencat:No such file or directory
*** Error code 1

Stop in /usr/src/lib/libc.
*** Error code 1

Stop in /usr/src/lib.
*** Error code 1

Stop in /usr/src.
*** Error code 1

Stop in /usr/src.
*** Error code 1

Stop in /usr/src.
*** Error code 1

Stop in /usr/src.
HP2133#
From admin at lissyara.su  Sat Sep 12 18:15:58 2009
From: admin at lissyara.su (Alex Keda)
Date: Sat Sep 12 18:16:05 2009
Subject: make installworld failure
In-Reply-To: <4AABD9E2.4030704@lissyara.su>
References: <4AABD9E2.4030704@lissyara.su>
Message-ID: <4AABE559.1030609@lissyara.su>

Alex Keda ?????:
> I have problem, some as 
> http://lists.freebsd.org/pipermail/freebsd-current/2009-June/007604.html
> if I install as:
> make -d A installworld
> I have
> ...........
> Searching for 
> be_BY.UTF-8.msg.../usr/src/lib/libc.../usr/src/lib/libc/db/btree.../usr/src/lib/libc/db/db.../usr/src/lib/libc/db/hash.../usr/src/lib/libc/db/man.../usr/src/lib/libc/db/mpool.../usr/src/lib/libc/db/recno.../usr/src/lib/libc/compat-43.../usr/src/lib/libc/gdtoa.../usr/src/lib/libc/i386/gen.../usr/src/lib/libc/gen.../usr/src/lib/libc/gmon.../usr/src/lib/libc/inet.../usr/src/lib/libc/isc.../usr/src/lib/libc/locale.../usr/src/lib/libc/nameser.../usr/src/lib/libc/net.../usr/src/lib/libc/nls...here...returning 
> /usr/src/lib/libc/nls/be_BY.UTF-8.msg
> be_BY.UTF-8.msg:@ = /usr/src/lib/libc/nls/be_BY.UTF-8.msg
> be