From grafan at gmail.com  Sun Feb  1 00:24:27 2009
From: grafan at gmail.com (Rong-en Fan)
Date: Sun Feb  1 00:24:33 2009
Subject: process hang in zfs->io_ ?
Message-ID: <6eb82e0902010024o4094b3a6q3186f2109029a67a@mail.gmail.com>

I'm running current as of 20080130 on an amd64 box. I can make
processes stuck in zfs->io_ (output truncated in ddb and top) when I
make some packages via ports tinderbox. The ports tinderbox access
local disk via nfs (I also tried nullfs).

ddb output of ps and alltrace can be found at

http://www.rafan.org/FreeBSD/zfs/textdump.zfs.20090130.txt

Any ideas?

Thanks,
Rong-En Fan
From stefan at fafoe.narf.at  Sun Feb  1 01:20:41 2009
From: stefan at fafoe.narf.at (Stefan Farfeleder)
Date: Sun Feb  1 01:20:48 2009
Subject: Fwd: Alternatives to gcc (was Re: gcc 4.3: when will it
	becomestandard compiler?)
In-Reply-To: <f0dd9eb90901311555u4c5e4d4fv515f5ceb3d075b77@mail.gmail.com>
References: <779523.80455.qm@web32706.mail.mud.yahoo.com>
	<20090131221236.GA27303@soaustin.net>
	<f0dd9eb90901311553u9eaf5c2h508146ca227ef8e6@mail.gmail.com>
	<f0dd9eb90901311555u4c5e4d4fv515f5ceb3d075b77@mail.gmail.com>
Message-ID: <20090201090143.GA1429@lizard.fafoe.narf.at>

On Sun, Feb 01, 2009 at 12:55:20PM +1300, James Butler wrote:
> 2009/2/1 Mark Linimon <linimon@lonesome.com>:
> > On Sat, Jan 31, 2009 at 01:08:54PM -0800, Pedro F. Giffuni wrote:
> >> The effort didn't go far enough. Why haven't we removed GNU readline ?
> >
> > Probably either because someone hasn't written a BSD-licensed one, or
> > someone hasn't done the work to test-compile src and ports on all the
> > appropriate architectures.
> 
> This might be off topic, but NetBSD has (limited) readline
> compatibility in their libedit (which FreeBSD has in ports I think) -
> this also gives them tab-completion in /bin/sh :-)

I once posted a patch which ports it to FreeBSD.  It would need a lot of
work to fix all ports though.
From lme at FreeBSD.org  Sun Feb  1 01:57:24 2009
From: lme at FreeBSD.org (Lars Engels)
Date: Sun Feb  1 01:57:32 2009
Subject: ath cannot find my wireless network any more
In-Reply-To: <49853423.9050208@freebsd.org>
References: <20090129192241.GZ60948@e.0x20.net>
	<20090129192830.GE73709@citylink.fud.org.nz>
	<20090129194826.GA60948@e.0x20.net> <49820EAC.5090400@freebsd.org>
	<20090129204323.GB60948@e.0x20.net>
	<3a142e750901291328w537b2070t216e393a0fd5b8ba@mail.gmail.com>
	<20090129215424.GC60948@e.0x20.net> <49853423.9050208@freebsd.org>
Message-ID: <20090201095721.GE60948@e.0x20.net>

On Sat, Jan 31, 2009 at 09:33:23PM -0800, Sam Leffler wrote:
> Lars Engels wrote:
> > 
> > Ahhh, thanks for the hint. There's a lot of scanning going on in
> > /var/log/messages but no sign of my own network.
> 
> 
> Unfortunately you haven't shown what this output is.  I asked you to do
> it to be sure the scan visited the channel w/ your ap and/or whether it
> sent a probe request frame or saw a beacon from the ap.  The hal changes
> should not have altered anything for you because your eeprom setup
> appears to have default settings.  I've been running these changes for a
> while but I'm likely testing different things than you.
> 
> If you can send me the debug output it might help (feel free to send it
> directly).  Otherwise you might try reverting the change.  Since you
> still haven't sent me the mac+phy revs for your card I can't try to
> reproduce your setup.

Sorry, I thought you wanted to see the scan results only when my network shows up.
Here are two rounds of scanning:

Feb  1 10:48:19 maggie kernel: ath0: <Atheros 5212> mem 0x88000000-0x8800ffff irq 20 at device 0.0 on cardbus0
Feb  1 10:48:19 maggie kernel: ath0: [ITHREAD]
Feb  1 10:48:19 maggie kernel: ath0: WARNING: using obsoleted if_watchdog interface
Feb  1 10:48:19 maggie kernel: ath0: mac 5.9 phy 4.3 radio 3.6
Feb  1 10:48:19 maggie kernel: wlan0: Ethernet address: 00:0f:b5:9a:47:47
Feb  1 10:49:23 maggie kernel: wlan0: scan_next: chan  36a ->  40a [active, dwell min 20 max 200]
Feb  1 10:49:24 maggie kernel: wlan0: scan_next: chan  40a ->  44a [active, dwell min 20 max 200]
Feb  1 10:49:24 maggie kernel: wlan0: scan_next: chan  44a ->  48a [active, dwell min 20 max 200]
Feb  1 10:49:24 maggie kernel: wlan0: scan_next: chan  48a ->   2g [active, dwell min 20 max 200]
Feb  1 10:49:24 maggie kernel: wlan0: scan_next: chan   2g ->   3g [active, dwell min 20 max 200]
Feb  1 10:49:24 maggie kernel: wlan0: scan_next: chan   3g ->   4g [active, dwell min 20 max 200]
Feb  1 10:49:25 maggie kernel: wlan0: scan_next: chan   4g ->   5g [active, dwell min 20 max 200]
Feb  1 10:49:25 maggie kernel: wlan0: scan_next: chan   5g ->   8g [active, dwell min 20 max 200]
Feb  1 10:49:25 maggie kernel: wlan0: scan_next: chan   8g ->   9g [active, dwell min 20 max 200]
Feb  1 10:49:25 maggie kernel: wlan0: scan_next: chan   9g ->  10g [active, dwell min 20 max 200]
Feb  1 10:49:26 maggie kernel: wlan0: scan_next: chan  10g -> 149a [active, dwell min 20 max 200]
Feb  1 10:49:26 maggie kernel: wlan0: scan_next: chan 149a -> 153a [active, dwell min 20 max 200]
Feb  1 10:49:26 maggie kernel: wlan0: scan_next: chan 153a -> 157a [active, dwell min 20 max 200]
Feb  1 10:49:26 maggie kernel: wlan0: scan_next: chan 157a -> 161a [active, dwell min 20 max 200]
Feb  1 10:49:26 maggie kernel: wlan0: scan_next: chan 161a -> 165a [active, dwell min 20 max 200]
Feb  1 10:49:27 maggie kernel: wlan0: scan_next: chan 165a ->  50S [active, dwell min 20 max 200]
Feb  1 10:49:27 maggie kernel: wlan0: scan_next: chan  50S ->  58S [active, dwell min 20 max 200]
Feb  1 10:49:27 maggie kernel: wlan0: scan_next: chan  58S -> 152S [active, dwell min 20 max 200]
Feb  1 10:49:27 maggie kernel: wlan0: scan_next: chan 152S -> 160S [active, dwell min 20 max 200]
Feb  1 10:49:27 maggie kernel: wlan0:  macaddr          bssid         chan  rssi  rate flag  wep  essid
Feb  1 10:49:27 maggie kernel: - 00:03:c9:54:18:bb 00:03:c9:54:18:bb    8     3! 54M   ess  wep  0x000000000000
Feb  1 10:49:27 maggie kernel: - 00:1a:2a:c6:de:56 00:1a:2a:c6:de:56    9     4! 54M   ess  wep  "Arcor-C6DE58"
Feb  1 10:49:27 maggie kernel: wlan0: scan_next: done, [ticks 284189, dwell min 20 scanend 2147762094]
Feb  1 10:49:27 maggie kernel: wlan0: notify scan done
Feb  1 10:49:32 maggie kernel: wlan0: ieee80211_ioctl_scanreq: flags 0x20052 duration 0x7fffffff mindwell 0 maxdwell 0 nssid 1
Feb  1 10:49:32 maggie kernel: wlan0: ieee80211_check_scan: active scan, append, nojoin, once
Feb  1 10:49:32 maggie kernel: wlan0:  macaddr          bssid         chan  rssi  rate flag  wep  essid


And here is the output of sysctl:

lars@pts/6 > sysctl dev.ath.0
dev.ath.0.%desc: Atheros 5212
dev.ath.0.%driver: ath
dev.ath.0.%location: slot=0 function=0
dev.ath.0.%pnpinfo: vendor=0x168c device=0x0013 subvendor=0x1385 subdevice=0x4610 class=0x020000
dev.ath.0.%parent: cardbus0
dev.ath.0.smoothing_rate: 95
dev.ath.0.sample_rate: 10
dev.ath.0.sample_stats: 0
dev.ath.0.countrycode: 0
dev.ath.0.regdomain: 0
dev.ath.0.slottime: 9
dev.ath.0.acktimeout: 22
dev.ath.0.ctstimeout: 22
dev.ath.0.softled: 0
dev.ath.0.ledpin: 0
dev.ath.0.ledon: 0
dev.ath.0.ledidle: 2700
dev.ath.0.txantenna: 0
dev.ath.0.rxantenna: 1
dev.ath.0.diversity: 1
dev.ath.0.txintrperiod: 5
dev.ath.0.diag: 0
dev.ath.0.tpscale: 0
dev.ath.0.tpc: 0
dev.ath.0.tpack: 63
dev.ath.0.tpcts: 63
dev.ath.0.fftxqmin: 2
dev.ath.0.fftxqmax: 50
dev.ath.0.intmit: 1
dev.ath.0.monpass: 24

Feb  1 10:49:32 maggie kernel: - 00:03:c9:54:18:bb 00:03:c9:54:18:bb    8     3! 54M   ess  wep  0x000000000000!
Feb  1 10:49:32 maggie kernel: - 00:1a:2a:c6:de:56 00:1a:2a:c6:de:56    9     4! 54M   ess  wep  "Arcor-C6DE58"!
Feb  1 10:49:32 maggie kernel: wlan0: start_scan_locked: active scan, duration 2147483647 mindwell 0 maxdwell 0, desired mode auto, append, nojoin, once
Feb  1 10:49:32 maggie kernel: wlan0: scan set 1g, 6G, 11g, 7g, 52a, 56a, 60a, 64a, 36a, 40a, 44a, 48a, 2g, 3g, 4g, 5g, 8g, 9g, 10g, 149a, 153a, 157a, 161a, 165a, 50S, 58S, 152S, 160S dwell min 20 max 200
Feb  1 10:49:32 maggie kernel: wlan0: scan_next: chan 160S ->   1g [active, dwell min 20 max 200]
Feb  1 10:49:33 maggie kernel: wlan0: scan_next: chan   1g ->   6G [active, dwell min 20 max 200]
Feb  1 10:49:33 maggie kernel: wlan0: scan_next: chan   6G ->  11g [active, dwell min 20 max 200]
Feb  1 10:49:33 maggie kernel: wlan0: scan_next: chan  11g ->   7g [active, dwell min 20 max 200]
Feb  1 10:49:33 maggie kernel: wlan0: scan_next: chan   7g ->  52a [active, dwell min 20 max 200]
Feb  1 10:49:33 maggie kernel: wlan0: scan_next: chan  52a ->  56a [active, dwell min 20 max 200]
Feb  1 10:49:34 maggie kernel: wlan0: scan_next: chan  56a ->  60a [active, dwell min 20 max 200]
Feb  1 10:49:34 maggie kernel: wlan0: scan_next: chan  60a ->  64a [active, dwell min 20 max 200]
Feb  1 10:49:34 maggie kernel: wlan0: scan_next: chan  64a ->  36a [active, dwell min 20 max 200]
Feb  1 10:49:34 maggie kernel: wlan0: scan_next: chan  36a ->  40a [active, dwell min 20 max 200]
Feb  1 10:49:34 maggie kernel: wlan0: scan_next: chan  40a ->  44a [active, dwell min 20 max 200]
Feb  1 10:49:35 maggie kernel: wlan0: scan_next: chan  44a ->  48a [active, dwell min 20 max 200]
Feb  1 10:49:35 maggie kernel: wlan0: scan_next: chan  48a ->   2g [active, dwell min 20 max 200]
Feb  1 10:49:35 maggie kernel: wlan0: scan_next: chan   2g ->   3g [active, dwell min 20 max 200]
Feb  1 10:49:35 maggie kernel: wlan0: scan_next: chan   3g ->   4g [active, dwell min 20 max 200]
Feb  1 10:49:35 maggie kernel: wlan0: scan_next: chan   4g ->   5g [active, dwell min 20 max 200]
Feb  1 10:49:36 maggie kernel: wlan0: scan_next: chan   5g ->   8g [active, dwell min 20 max 200]
Feb  1 10:49:36 maggie kernel: [00:03:c9:54:18:bb] new beacon on chan 8 (bss chan 8) 0x000000000000 rssi 3
Feb  1 10:49:36 maggie kernel: [00:03:c9:54:18:bb] caps 0x411 bintval 100 erp 0x100
Feb  1 10:49:36 maggie kernel: wlan0: ieee80211_add_scan: chan   8g min dwell met (292559 > 292497)
Feb  1 10:49:36 maggie kernel: wlan0: scan_next: chan   8g ->   9g [active, dwell min 20 max 200]
Feb  1 10:49:36 maggie kernel: [00:1a:2a:c6:de:56] new beacon on chan 9 (bss chan 9) "Arcor-C6DE58" rssi 4
Feb  1 10:49:36 maggie kernel: [00:1a:2a:c6:de:56] caps 0x431 bintval 100 erp 0x100
Feb  1 10:49:36 maggie kernel: wlan0: ieee80211_add_scan: chan   9g min dwell met (292590 > 292585)
Feb  1 10:49:36 maggie kernel: wlan0: scan_next: chan   9g ->  10g [active, dwell min 20 max 200]
Feb  1 10:49:36 maggie kernel: wlan0: scan_next: chan  10g -> 149a [active, dwell min 20 max 200]
Feb  1 10:49:36 maggie kernel: wlan0: scan_next: chan 149a -> 153a [active, dwell min 20 max 200]
Feb  1 10:49:36 maggie kernel: wlan0: scan_next: chan 153a -> 157a [active, dwell min 20 max 200]
Feb  1 10:49:37 maggie kernel: wlan0: scan_next: chan 157a -> 161a [active, dwell min 20 max 200]
Feb  1 10:49:37 maggie kernel: wlan0: scan_next: chan 161a -> 165a [active, dwell min 20 max 200]
Feb  1 10:49:37 maggie kernel: wlan0: scan_next: chan 165a ->  50S [active, dwell min 20 max 200]
Feb  1 10:49:37 maggie kernel: wlan0: scan_next: chan  50S ->  58S [active, dwell min 20 max 200]
Feb  1 10:49:37 maggie kernel: wlan0: scan_next: chan  58S -> 152S [active, dwell min 20 max 200]
Feb  1 10:49:38 maggie kernel: wlan0: scan_next: chan 152S -> 160S [active, dwell min 20 max 200]
Feb  1 10:49:38 maggie kernel: wlan0:  macaddr          bssid         chan  rssi  rate flag  wep  essid
Feb  1 10:49:38 maggie kernel: - 00:03:c9:54:18:bb 00:03:c9:54:18:bb    8     3! 54M   ess  wep  0x000000000000!
Feb  1 10:49:38 maggie kernel: - 00:1a:2a:c6:de:56 00:1a:2a:c6:de:56    9     4! 54M   ess  wep  "Arcor-C6DE58"!
Feb  1 10:49:38 maggie kernel: wlan0: scan_next: done, [ticks 294642, dwell min 20 scanend 2147772838]
Feb  1 10:49:38 maggie kernel: wlan0: notify scan done


Thanks for your help.

  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/20090201/2dbde615/attachment-0001.pgp
From peter.schuller at infidyne.com  Sun Feb  1 02:58:18 2009
From: peter.schuller at infidyne.com (Peter Schuller)
Date: Sun Feb  1 02:58:24 2009
Subject: process hang in zfs->io_ ?
In-Reply-To: <6eb82e0902010024o4094b3a6q3186f2109029a67a@mail.gmail.com>
References: <6eb82e0902010024o4094b3a6q3186f2109029a67a@mail.gmail.com>
Message-ID: <20090201105815.GA73985@hyperion.scode.org>

> I'm running current as of 20080130 on an amd64 box. I can make
> processes stuck in zfs->io_ (output truncated in ddb and top) when I
> make some packages via ports tinderbox. The ports tinderbox access
> local disk via nfs (I also tried nullfs).
> 
> ddb output of ps and alltrace can be found at
> 
> http://www.rafan.org/FreeBSD/zfs/textdump.zfs.20090130.txt
> 
> Any ideas?

A workaround is to disable the ZIL (vfs.zfs.zil_disable="1"), if you
can afford that on the system in question. It will break the
durability of fsync(), but retain it's write barrier semantics.

Btw, does anyone have a good grasp of the status of this bug? I have
seen vague referenced to it being a memory related deadlock for
example, but that's about it. Is the cause known but difficult to fix,
or just unknown?

-- 
/ Peter Schuller

PGP userID: 0xE9758B7D or 'Peter Schuller <peter.schuller@infidyne.com>'
Key retrieval: Send an E-Mail to getpgpkey@scode.org
E-Mail: peter.schuller@infidyne.com Web: http://www.scode.org

-------------- 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/20090201/8fbdaab9/attachment.pgp
From pj at smo.de  Sun Feb  1 04:11:00 2009
From: pj at smo.de (Philipp Ost)
Date: Sun Feb  1 04:11:07 2009
Subject: Alternatives to gcc (was Re: gcc 4.3: when will it
 becomestandard compiler?)
In-Reply-To: <763068.66528.qm@web39104.mail.mud.yahoo.com>
References: <763068.66528.qm@web39104.mail.mud.yahoo.com>
Message-ID: <49859187.2030407@smo.de>

bf wrote:
>>>The issue is a lot of open source applications that it can run are
>>>GPL licensed. I know there was an effort to replace the core OS apps
>>>that were GPL with 100% BSD licensed equivalents.
> 
> 
>>The effort didn't go far enough. Why haven't we removed GNU readline ?
> 
> 
>>Pedro.
> 
> 
> I think you know very well why we haven't removed that, and other
> pieces of software with the GPL from the tree: no one has written and
> submitted suitable replacements with more permissive licenses. [...]

What about the editline library <http://thrysoee.dk/editline/>?
I have to admit I don't know how well it works, but I haven't used 
readline either...

Philipp
From ohartman at mail.zedat.fu-berlin.de  Sun Feb  1 03:07:33 2009
From: ohartman at mail.zedat.fu-berlin.de (O. Hartmann)
Date: Sun Feb  1 04:14:30 2009
Subject: Xorg upgrade desaster: Xlib: extension "Generic Event	Extension"
 missing on display ":0.0".
In-Reply-To: <E1LTU5c-000Jiu-PI@daland.home>
References: <49837CFD.4080603@mail.zedat.fu-berlin.de>	<200901301430.07087.fbsd.questions@rachie.is-a-geek.net>	<4984EF27.2050405@mail.zedat.fu-berlin.de>
	<E1LTU5c-000Jiu-PI@daland.home>
Message-ID: <49858274.6090807@mail.zedat.fu-berlin.de>

Alex Goncharov wrote:
> ,--- You/O. (Sun, 01 Feb 2009 01:39:03 +0100) ----*
> | I did a 'ldd' on the Firefox3 binary
> | and  I got the attached dump of the linked shared objects.
> | Interestingly, the first three entries show up something missing -
>
> LD_LIBRARY_PATH=/usr/local/lib/firefox3 ldd /usr/local/lib/firefox3/firefox-bin | head -n 5
> /usr/local/lib/firefox3/firefox-bin:
>         libxul.so => /usr/local/lib/firefox3/libxul.so (0x28087000)
>         libmozjs.so => /usr/local/lib/firefox3/libmozjs.so (0x28e8f000)
>         libxpcom.so => /usr/local/lib/firefox3/libxpcom.so (0x28f1f000)
>
> firefox3 sets LD_LIBRARY_PATH for you :-)
>   
It does not!

... on all of my boxes (amd64), it does not ... even on those machines
where Firefox3 is running, these libs are empty. But I realized that those
boxes are capable running firefox3 after the 'great
Xorg-update-catastrophy' have still installed firefox2 ... I will check
tomorrow at the lab if
this do have an influence of the proper work abilities of firefox3 when
removing the old firefox2.

When setting LD_LIBRARY_PATH manually, adding /usr/lib/firefox3/, it
doesn't change the bad situation on the failing CURRENT amd64 box.
> | thor# ldd firefox-bin
> | firefox-bin:
> |         libxul.so => not found (0x0)
> |         libmozjs.so => not found (0x0)
> |         libxpcom.so => not found (0x0)
> |         libplds4.so.1 => /usr/local/lib/libplds4.so.1 (0x80063e000)
>
> -- Alex -- alex-goncharov@comcast.net --
>
>   

From ohartman at mail.zedat.fu-berlin.de  Sun Feb  1 03:29:01 2009
From: ohartman at mail.zedat.fu-berlin.de (O. Hartmann)
Date: Sun Feb  1 04:29:33 2009
Subject: Xorg upgrade desaster: Xlib: extension "Generic Event Extension"
 missing on display ":0.0".
In-Reply-To: <790a9fff0901312008x71fa025na58856bde4c7a5be@mail.gmail.com>
References: <49837CFD.4080603@mail.zedat.fu-berlin.de>	
	<200901301430.07087.fbsd.questions@rachie.is-a-geek.net>	
	<4984EF27.2050405@mail.zedat.fu-berlin.de>
	<790a9fff0901312008x71fa025na58856bde4c7a5be@mail.gmail.com>
Message-ID: <4985877B.8080502@mail.zedat.fu-berlin.de>

Scot Hetzel wrote:
> On Sat, Jan 31, 2009 at 6:39 PM, O. Hartmann
> <ohartman@mail.zedat.fu-berlin.de> wrote:
>   
>> build-process, but I doubt this. I did a 'ldd' on the Firefox3 binary
>> and  I got the attached dump of the linked shared objects.
>> Interestingly, the first three entries show up something missing -
>> therefore I deinstalled Firefox and rebuild the browser after an
>> additional rebuild of libxcb (via portupgrade -rf). Previously, all Xorg
>>     
>
>   
>> thor# ldd firefox-bin
>> firefox-bin:
>>        libxul.so => not found (0x0)
>>        libmozjs.so => not found (0x0)
>>        libxpcom.so => not found (0x0)
>>        libplds4.so.1 => /usr/local/lib/libplds4.so.1 (0x80063e000)
>>        libplc4.so.1 => /usr/local/lib/libplc4.so.1 (0x80076f000)
>>     
>
> When firefox3 was first added to the ports collection, I had noticed
> this problem with firefox3 (after using sysutils/libchk), but I didn't
> have this problem with the firefox 2.  A look at the difference
> between the www/firefox and www/firefox3 Makefiles showed that
> firefox3 was missing this:
>
> LDFLAGS+= -Wl,-rpath,${PREFIX}/lib/${MOZ_RPATH}
>
> After adding this line to the ports Makefile, and rebuilding the port,
> these libraries are now showing as found in the ldd output.
>
> Scot
>   
Isn't that worth a PR?

From alex-goncharov at comcast.net  Sun Feb  1 04:56:43 2009
From: alex-goncharov at comcast.net (Alex Goncharov)
Date: Sun Feb  1 04:56:50 2009
Subject: Xorg upgrade desaster: Xlib: extension "Generic Event	Extension"
 missing on display ":0.0".
In-Reply-To: <49858274.6090807@mail.zedat.fu-berlin.de>
	(ohartman@mail.zedat.fu-berlin.de)
References: <49837CFD.4080603@mail.zedat.fu-berlin.de>	<200901301430.07087.fbsd.questions@rachie.is-a-geek.net>	<4984EF27.2050405@mail.zedat.fu-berlin.de>
	<E1LTU5c-000Jiu-PI@daland.home>
	<49858274.6090807@mail.zedat.fu-berlin.de>
Message-ID: <E1LTbsO-000OYb-BL@daland.home>

,--- You/O. (Sun, 01 Feb 2009 12:07:32 +0100) ----*
| Alex Goncharov wrote:
| > ,--- You/O. (Sun, 01 Feb 2009 01:39:03 +0100) ----*
| > | I did a 'ldd' on the Firefox3 binary
| > | and  I got the attached dump of the linked shared objects.
| > | Interestingly, the first three entries show up something missing -
| >
| > LD_LIBRARY_PATH=/usr/local/lib/firefox3 ldd /usr/local/lib/firefox3/firefox-bin | head -n 5
| > /usr/local/lib/firefox3/firefox-bin:
| >         libxul.so => /usr/local/lib/firefox3/libxul.so (0x28087000)
| >         libmozjs.so => /usr/local/lib/firefox3/libmozjs.so (0x28e8f000)
| >         libxpcom.so => /usr/local/lib/firefox3/libxpcom.so (0x28f1f000)
| >
| > firefox3 sets LD_LIBRARY_PATH for you :-)
| >   
| It does not!

----------------------------------------------------------------------

$ grep run-mozilla.sh  /usr/local/bin/firefox3 
# Use run-mozilla.sh in the current dir if it exists
# If not, then start resolving symlinks until we find run-mozilla.sh
run_moz="$curdir/run-mozilla.sh"
    run_moz="$curdir/run-mozilla.sh"
      run_moz="$dist_bin/run-mozilla.sh"
  if [ -x "$moz_libdir/run-mozilla.sh" ]; then
  echo $dist_bin/run-mozilla.sh $script_args $dist_bin/$MOZILLA_BIN "$@"
"$dist_bin/run-mozilla.sh" $script_args "$dist_bin/$MOZILLA_BIN" "$@"


$ grep  LD_LIBRARY_PATH /usr/local/lib/firefox3/run-mozilla.sh
## Set LD_LIBRARY_PATH
## On Solaris we use $ORIGIN (set in RUNPATH) instead of LD_LIBRARY_PATH 
## under dist/bin. To solve the problem, we should rely on LD_LIBRARY_PATH
        LD_LIBRARY_PATH=${MOZ_DIST_BIN}:${MOZ_DIST_BIN}/plugins:${MRE_HOME}${LD_LIBRARY_PATH+":$LD_LIBRARY_PATH"}
if [ -n "$LD_LIBRARY_PATH_64" ]; then
        LD_LIBRARY_PATH_64=${MOZ_DIST_BIN}:${MOZ_DIST_BIN}/plugins:${MRE_HOME}${LD_LIBRARY_PATH_64+":$LD_LIBRARY_PATH_64"}
## Set DYLD_LIBRARY_PATH for Mac OS X (Darwin)
DYLD_LIBRARY_PATH=${MOZ_DIST_BIN}:${MRE_HOME}${DYLD_LIBRARY_PATH+":$DYLD_LIBRARY_PATH"}
  echo "  LD_LIBRARY_PATH=$LD_LIBRARY_PATH"
  if [ -n "$LD_LIBRARY_PATH_64" ]; then
        echo "LD_LIBRARY_PATH_64=$LD_LIBRARY_PATH_64"
  echo "DYLD_LIBRARY_PATH=$DYLD_LIBRARY_PATH"
export MOZILLA_FIVE_HOME LD_LIBRARY_PATH
export SHLIB_PATH LIBPATH LIBRARY_PATH ADDON_PATH DYLD_LIBRARY_PATH

----------------------------------------------------------------------

No, it doesn't?

| ... on all of my boxes (amd64), it does not ... even on those
| machines where Firefox3 is running, these libs are empty. But I
| realized that those boxes are capable running firefox3 after the
| 'great Xorg-update-catastrophy' have still installed firefox2 ... I
| will check tomorrow at the lab if this do have an influence of the
| proper work abilities of firefox3 when removing the old firefox2.
| 
| When setting LD_LIBRARY_PATH manually, adding /usr/lib/firefox3/, it
| doesn't change the bad situation on the failing CURRENT amd64 box.

All I was saying was that your ldd experiment was... hmm... not
correct (if you agree with mine, of course). 

-- Alex -- alex-goncharov@comcast.net --

From alex-goncharov at comcast.net  Sun Feb  1 04:59:24 2009
From: alex-goncharov at comcast.net (Alex Goncharov)
Date: Sun Feb  1 04:59:30 2009
Subject: Xorg upgrade desaster: Xlib: extension "Generic Event	Extension
	" missing on display ":0.0".
In-Reply-To: <200901312005.51125.fbsd.questions@rachie.is-a-geek.net> (message
	from Mel on Sat, 31 Jan 2009 20:05:50 -0900)
References: <49837CFD.4080603@mail.zedat.fu-berlin.de>
	<200901301430.07087.fbsd.questions@rachie.is-a-geek.net>
	<4984EF27.2050405@mail.zedat.fu-berlin.de>
	<200901312005.51125.fbsd.questions@rachie.is-a-geek.net>
Message-ID: <E1LTbv0-000Oa8-4A@daland.home>

,--- You/Mel (Sat, 31 Jan 2009 20:05:50 -0900) ----*
| As a sidenote, it would be nice if xorg-server14 port would be created till 
| the dust has settled.

Very, very nice.

Almost as nice as xorg-server being the old, working xorg-server and
xorg-server-devel the new, broken one.

-- Alex -- alex-goncharov@comcast.net --
From alex-goncharov at comcast.net  Sun Feb  1 06:02:46 2009
From: alex-goncharov at comcast.net (Alex Goncharov)
Date: Sun Feb  1 06:02:54 2009
Subject: Xorg upgrade desaster: Xlib: extension "Generic Event	Extension"
 missing on display ":0.0".
In-Reply-To: <4985A8B7.2040307@mail.zedat.fu-berlin.de>
	(ohartman@mail.zedat.fu-berlin.de)
References: <49837CFD.4080603@mail.zedat.fu-berlin.de>	<200901301430.07087.fbsd.questions@rachie.is-a-geek.net>	<4984EF27.2050405@mail.zedat.fu-berlin.de>
	<E1LTU5c-000Jiu-PI@daland.home>
	<49858274.6090807@mail.zedat.fu-berlin.de>
	<E1LTbsO-000OYb-BL@daland.home>
	<4985A8B7.2040307@mail.zedat.fu-berlin.de>
Message-ID: <E1LTcuK-000PAn-2f@daland.home>

,--- I/Alex (Sun, 01 Feb 2009 07:56:40 -0500) ----*
| All I was saying was that your ldd experiment was... hmm... not
| correct (if you agree with mine, of course). 
,--- You/O. (Sun, 01 Feb 2009 14:50:47 +0100) ----*
| Saying, it was stupid? You're correct. It was stupid and, of course, it
| doesn't matter if the libs show up or not.

Not stupid -- you tried various things in desperation and hurry, and
reported your observations and thoughts.  It's normal :-)

| I thought, at the first shot, firefox3 binary needs to have a
| complete reference to all of its libraries, but thinking so leads
| the advantage of having dynamical loadable objects ad absurdum.

Glad this is cleared now!

-- Alex -- alex-goncharov@comcast.net --

From yanefbsd at gmail.com  Sun Feb  1 06:07:47 2009
From: yanefbsd at gmail.com (Garrett Cooper)
Date: Sun Feb  1 06:07:59 2009
Subject: Xorg upgrade desaster: Xlib: extension "Generic Event	Extension
	" missing on display ":0.0".
In-Reply-To: <200901312005.51125.fbsd.questions@rachie.is-a-geek.net>
References: <49837CFD.4080603@mail.zedat.fu-berlin.de>
	<200901301430.07087.fbsd.questions@rachie.is-a-geek.net>
	<4984EF27.2050405@mail.zedat.fu-berlin.de>
	<200901312005.51125.fbsd.questions@rachie.is-a-geek.net>
Message-ID: <F6999A5F-0465-4F83-BAF0-975D0CC6BFAB@gmail.com>

On Jan 31, 2009, at 9:05 PM, Mel wrote:

> On Saturday 31 January 2009 15:39:03 O. Hartmann wrote:
>> Mel wrote:
>>> On Friday 30 January 2009 13:19:41 O. Hartmann wrote:
>>>> After upgrading one of my FreeBSD 8.0-CUR/amd64 boxes to new  
>>>> xorg-7.4
>>>> and having done hurting recompiling nearly everything/package  
>>>> twice now
>>>> firefox3 still doesn't work properly and hits me when starting  
>>>> with this
>>>> error message:
>>>>
>>>> Xlib:  extension "Generic Event Extension" missing on display ": 
>>>> 0.0".
>>>>
>>>> Then firefox3 freezes forever, showing something like the  
>>>> background or
>>>> pixel remnants of windows/picograms moving over its window.
>>>
>>> http://lists.freedesktop.org/archives/xorg/2008-October/039134.html
>>
>> Well, that doesn't help very much. As R. Noland wrote, the error  
>> coming
>> up isn't of any harm.
>>
>> I still have Firefox3 not working on a FreeBSD 8.0-CURRENT/AMD64 UP  
>> box,
>> running the most recent FreeBSD 8.0-CURRENT and having now recompiled
>> three time EVERYTHING, Firefox3 inclusive. Firefox3 is still stuck  
>> when
>> it comes to pulldown menus or requester for download destination,  
>> eating
>> up 100% CPU time and slowing down the box incredible. I pretty sure I
>> have all the stuff of the X11 suite in the right place and the right
>> revision number, as I said, I recompiled everything three times and I
>> did several attempts upgrading the whole Xorg since sunday last week.
>
> You have 2 choices:
> - revert to known working xorg-server-1.4 (xorg 7.3)
> - try to debug this using the send-pr system, given the ammount of  
> problems
> people are posting with this xorg-server, more datapoints are not a  
> bad
> thing.
>
> As a sidenote, it would be nice if xorg-server14 port would be  
> created till
> the dust has settled.

	I don't have an issue with any cairo related ports after upgrading to  
xorg 7.4. Of course I had to rebuild everything dependent on libxcb,  
but that took no more than one iteration to complete (apart from  
xchat2, which took 4 iterations to finish because of some wonky  
library mucking up the works). Yay for statically linked library code - 
_-...
-Garrett
From yanefbsd at gmail.com  Sun Feb  1 06:11:21 2009
From: yanefbsd at gmail.com (Garrett Cooper)
Date: Sun Feb  1 06:11:28 2009
Subject: Much ado about libedit [Re: Alternatives to gcc (was Re: gcc 4.3:
	when will it becomestandard compiler?)]
In-Reply-To: <20090201090143.GA1429@lizard.fafoe.narf.at>
References: <779523.80455.qm@web32706.mail.mud.yahoo.com>
	<20090131221236.GA27303@soaustin.net>
	<f0dd9eb90901311553u9eaf5c2h508146ca227ef8e6@mail.gmail.com>
	<f0dd9eb90901311555u4c5e4d4fv515f5ceb3d075b77@mail.gmail.com>
	<20090201090143.GA1429@lizard.fafoe.narf.at>
Message-ID: <F5F65516-ED99-4055-90B9-E062196CBC07@gmail.com>

On Feb 1, 2009, at 1:01 AM, Stefan Farfeleder wrote:

> On Sun, Feb 01, 2009 at 12:55:20PM +1300, James Butler wrote:
>> 2009/2/1 Mark Linimon <linimon@lonesome.com>:
>>> On Sat, Jan 31, 2009 at 01:08:54PM -0800, Pedro F. Giffuni wrote:
>>>> The effort didn't go far enough. Why haven't we removed GNU  
>>>> readline ?
>>>
>>> Probably either because someone hasn't written a BSD-licensed one,  
>>> or
>>> someone hasn't done the work to test-compile src and ports on all  
>>> the
>>> appropriate architectures.
>>
>> This might be off topic, but NetBSD has (limited) readline
>> compatibility in their libedit (which FreeBSD has in ports I think) -
>> this also gives them tab-completion in /bin/sh :-)
>
> I once posted a patch which ports it to FreeBSD.  It would need a  
> lot of
> work to fix all ports though.

	libedit isn't feature complete with GNU readline and many things will  
fail to compile with NetBSD's rip on readline. Believe me -- I tried  
with python -_-...
	Then again at least you can make GNU readline into a port for things  
that need it (like Python's readline module).
	And yes, we do already have libedit in the base source tree under lib/ 
libedit -- it's just extremely outdated (hence libreadline isn't  
available after compiling libedit).
Cheers,
-Garrett
From yanefbsd at gmail.com  Sun Feb  1 06:13:12 2009
From: yanefbsd at gmail.com (Garrett Cooper)
Date: Sun Feb  1 06:13:19 2009
Subject: Alternatives to gcc (was Re: gcc 4.3: when will it
	becomestandard compiler?)
In-Reply-To: <49859187.2030407@smo.de>
References: <763068.66528.qm@web39104.mail.mud.yahoo.com>
	<49859187.2030407@smo.de>
Message-ID: <C1E35D3D-9CFF-4E60-A3E4-F89F69860F6D@gmail.com>

On Feb 1, 2009, at 4:11 AM, Philipp Ost wrote:

> bf wrote:
>>>> The issue is a lot of open source applications that it can run are
>>>> GPL licensed. I know there was an effort to replace the core OS  
>>>> apps
>>>> that were GPL with 100% BSD licensed equivalents.
>>> The effort didn't go far enough. Why haven't we removed GNU  
>>> readline ?
>>> Pedro.
>> I think you know very well why we haven't removed that, and other
>> pieces of software with the GPL from the tree: no one has written and
>> submitted suitable replacements with more permissive licenses. [...]
>
> What about the editline library <http://thrysoee.dk/editline/>?
> I have to admit I don't know how well it works, but I haven't used  
> readline either...
>
> Philipp

Same thing as NetBSD's libedit, just rehashed with GNU makefiles and  
other Linuxy patches.
-Garrett
From Thomas.Sparrevohn at btinternet.com  Sun Feb  1 06:37:24 2009
From: Thomas.Sparrevohn at btinternet.com (Thomas Sparrevohn)
Date: Sun Feb  1 06:37:31 2009
Subject: process hang in zfs->io_ ?
In-Reply-To: <6eb82e0902010024o4094b3a6q3186f2109029a67a@mail.gmail.com>
References: <6eb82e0902010024o4094b3a6q3186f2109029a67a@mail.gmail.com>
Message-ID: <007b01c9847a$983ad9c0$c8b08d40$@Sparrevohn@btinternet.com>

I have noticed the same error - However I am not actually sure that ZFS is the culprit - I tried to remotely log in from my laptop and the system unfroze 
 

-----Original Message-----
From: owner-freebsd-current@freebsd.org [mailto:owner-freebsd-current@freebsd.org] On Behalf Of Rong-en Fan
Sent: 01 February 2009 08:24
To: FreeBSD Current
Subject: process hang in zfs->io_ ?

I'm running current as of 20080130 on an amd64 box. I can make
processes stuck in zfs->io_ (output truncated in ddb and top) when I
make some packages via ports tinderbox. The ports tinderbox access
local disk via nfs (I also tried nullfs).

ddb output of ps and alltrace can be found at

http://www.rafan.org/FreeBSD/zfs/textdump.zfs.20090130.txt

Any ideas?

Thanks,
Rong-En Fan
_______________________________________________
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 barney_cordoba at yahoo.com  Sun Feb  1 08:07:53 2009
From: barney_cordoba at yahoo.com (Barney Cordoba)
Date: Sun Feb  1 08:07:59 2009
Subject: Possible bug in ip_input()
Message-ID: <16190.90052.qm@web63904.mail.re1.yahoo.com>

I've noticed the following possible inconsistency.

1) ip_input() is called with M_FASTFWD_OUR set
2) ip_off is not "adjusted" to host representation
3) ip reassembly is erroneously called.

I don't have an actual case that can test this, but it seems like an issue.

Barney


      
From ohartman at mail.zedat.fu-berlin.de  Sun Feb  1 05:50:49 2009
From: ohartman at mail.zedat.fu-berlin.de (O. Hartmann)
Date: Sun Feb  1 08:09:39 2009
Subject: Xorg upgrade desaster: Xlib: extension "Generic Event	Extension"
 missing on display ":0.0".
In-Reply-To: <E1LTbsO-000OYb-BL@daland.home>
References: <49837CFD.4080603@mail.zedat.fu-berlin.de>	<200901301430.07087.fbsd.questions@rachie.is-a-geek.net>	<4984EF27.2050405@mail.zedat.fu-berlin.de>
	<E1LTU5c-000Jiu-PI@daland.home>
	<49858274.6090807@mail.zedat.fu-berlin.de>
	<E1LTbsO-000OYb-BL@daland.home>
Message-ID: <4985A8B7.2040307@mail.zedat.fu-berlin.de>

Alex Goncharov wrote:
> ,--- You/O. (Sun, 01 Feb 2009 12:07:32 +0100) ----*
> | Alex Goncharov wrote:
> | > ,--- You/O. (Sun, 01 Feb 2009 01:39:03 +0100) ----*
> | > | I did a 'ldd' on the Firefox3 binary
> | > | and  I got the attached dump of the linked shared objects.
> | > | Interestingly, the first three entries show up something missing -
> | >
> | > LD_LIBRARY_PATH=/usr/local/lib/firefox3 ldd /usr/local/lib/firefox3/firefox-bin | head -n 5
> | > /usr/local/lib/firefox3/firefox-bin:
> | >         libxul.so => /usr/local/lib/firefox3/libxul.so (0x28087000)
> | >         libmozjs.so => /usr/local/lib/firefox3/libmozjs.so (0x28e8f000)
> | >         libxpcom.so => /usr/local/lib/firefox3/libxpcom.so (0x28f1f000)
> | >
> | > firefox3 sets LD_LIBRARY_PATH for you :-)
> | >   
> | It does not!
>
> ----------------------------------------------------------------------
>
> $ grep run-mozilla.sh  /usr/local/bin/firefox3 
> # Use run-mozilla.sh in the current dir if it exists
> # If not, then start resolving symlinks until we find run-mozilla.sh
> run_moz="$curdir/run-mozilla.sh"
>     run_moz="$curdir/run-mozilla.sh"
>       run_moz="$dist_bin/run-mozilla.sh"
>   if [ -x "$moz_libdir/run-mozilla.sh" ]; then
>   echo $dist_bin/run-mozilla.sh $script_args $dist_bin/$MOZILLA_BIN "$@"
> "$dist_bin/run-mozilla.sh" $script_args "$dist_bin/$MOZILLA_BIN" "$@"
>
>
> $ grep  LD_LIBRARY_PATH /usr/local/lib/firefox3/run-mozilla.sh
> ## Set LD_LIBRARY_PATH
> ## On Solaris we use $ORIGIN (set in RUNPATH) instead of LD_LIBRARY_PATH 
> ## under dist/bin. To solve the problem, we should rely on LD_LIBRARY_PATH
>         LD_LIBRARY_PATH=${MOZ_DIST_BIN}:${MOZ_DIST_BIN}/plugins:${MRE_HOME}${LD_LIBRARY_PATH+":$LD_LIBRARY_PATH"}
> if [ -n "$LD_LIBRARY_PATH_64" ]; then
>         LD_LIBRARY_PATH_64=${MOZ_DIST_BIN}:${MOZ_DIST_BIN}/plugins:${MRE_HOME}${LD_LIBRARY_PATH_64+":$LD_LIBRARY_PATH_64"}
> ## Set DYLD_LIBRARY_PATH for Mac OS X (Darwin)
> DYLD_LIBRARY_PATH=${MOZ_DIST_BIN}:${MRE_HOME}${DYLD_LIBRARY_PATH+":$DYLD_LIBRARY_PATH"}
>   echo "  LD_LIBRARY_PATH=$LD_LIBRARY_PATH"
>   if [ -n "$LD_LIBRARY_PATH_64" ]; then
>         echo "LD_LIBRARY_PATH_64=$LD_LIBRARY_PATH_64"
>   echo "DYLD_LIBRARY_PATH=$DYLD_LIBRARY_PATH"
> export MOZILLA_FIVE_HOME LD_LIBRARY_PATH
> export SHLIB_PATH LIBPATH LIBRARY_PATH ADDON_PATH DYLD_LIBRARY_PATH
>
> ----------------------------------------------------------------------
>
> No, it doesn't?
>
> | ... on all of my boxes (amd64), it does not ... even on those
> | machines where Firefox3 is running, these libs are empty. But I
> | realized that those boxes are capable running firefox3 after the
> | 'great Xorg-update-catastrophy' have still installed firefox2 ... I
> | will check tomorrow at the lab if this do have an influence of the
> | proper work abilities of firefox3 when removing the old firefox2.
> | 
> | When setting LD_LIBRARY_PATH manually, adding /usr/lib/firefox3/, it
> | doesn't change the bad situation on the failing CURRENT amd64 box.
>
> All I was saying was that your ldd experiment was... hmm... not
> correct (if you agree with mine, of course). 
>   

Saying, it was stupid? You're correct. It was stupid and, of course, it
doesn't matter if the libs show up or not.
 I thought, at the first shot, firefox3 binary needs to have a complete
reference to all of its
libraries, but thinking so leads  the advantage of having dynamical
loadable objects ad absurdum.

Greetings,
Oliver
From gavin at FreeBSD.org  Sun Feb  1 09:13:16 2009
From: gavin at FreeBSD.org (Gavin Atkinson)
Date: Sun Feb  1 09:13:23 2009
Subject: Alternatives to gcc (was Re: gcc 4.3: when will it
 becomestandard compiler?)
In-Reply-To: <87223.61659.qm@web32707.mail.mud.yahoo.com>
References: <87223.61659.qm@web32707.mail.mud.yahoo.com>
Message-ID: <20090201164154.V97967@ury.york.ac.uk>

On Sat, 31 Jan 2009, Pedro F. Giffuni wrote:
> --- On Sat, 1/31/09, Mark Linimon <linimon@lonesome.com> wrote:
>
> On Sat, Jan 31, 2009 at 01:08:54PM -0800, Pedro F. Giffuni wrote:
>>> The effort didn't go far enough. Why haven't we removed GNU readline ?
>>
>> Probably either because someone hasn't written a BSD-licensed one, or
>> someone hasn't done the work to test-compile src and ports on all the
>> appropriate architectures.
>
> Wrong on both:
>
> - libedit has a readline compatibility mode that has replaced GNU readline in the other BSDs.
> - If you look in the archives you will find patches.
>
> If there really was any effort to remove GPL'd stuff from the tree it 
> missed this big time: GNU readline is a library under the GPL (not 
> LGPL), it should be dead long ago.

As far as I can see, in the base system, there are five things linked 
against readline which would not otherwise be under the GPL:

kadmin, ktutil, gvinum, ntpq, ntpdc

Of these, gvinum is a surprise.  I'm not sure what it needs readline for, 
and cannot see why this isn't able to use the copy of libedit in the base 
system.  ntpq and ntpdc are being built with the option to use libreadline 
commented out, so I'm not sure why they are being linked with it.  I don't 
know about the Kerberos programs, but given they are contrib I suspect 
that may be a reaon why they are still using libedit rather than readline.

I may be wrong (feel free to correct me) but I can't see what the real 
issue is with having readline in the base, if only code that is already 
GPL is linking against it.  Obviously it would be good if the five 
utilities above could be linked against libedit rather than readline.

Gavin
From mezz7 at cox.net  Sun Feb  1 09:21:04 2009
From: mezz7 at cox.net (Jeremy Messenger)
Date: Sun Feb  1 09:21:13 2009
Subject: Alternatives to gcc
In-Reply-To: <20090201060549.GE83330@dragon.NUXI.org>
References: <61484.71762.qm@web32708.mail.mud.yahoo.com>
	<86skniyp60.fsf@ds4.des.no> <20090201060549.GE83330@dragon.NUXI.org>
Message-ID: <op.uoomb4u79aq2h7@localhost>

On Sun, 01 Feb 2009 00:05:49 -0600, David O'Brien <obrien@freebsd.org>
wrote:

> "Pedro F. Giffuni" <giffunip@tutopia.com> writes:
>> - Replacing groff with something less restricted that doesn't require
>> C++: Heirloom-doctools may be an option.
>
> You're proposing replacing GPLv2 stuff with CDDL'ed stuff?
>
>     $ cd heirloom-doctools-080407> grep -l -R CDDL * | wc -l
>          217
>
> The last time I asked $WORK's lawyers, GPLv2 was acceptable to
> *carefully* ship with our product.  CDDL was forbidden (as is GPLv3).

Interesting... I thought, CDDL is more flexible than GPLv2? Or do I  
misunderstand something with CDDL?

Cheers,
Mezz


-- 
mezz7@cox.net  -  mezz@FreeBSD.org
FreeBSD GNOME Team
http://www.FreeBSD.org/gnome/  -  gnome@FreeBSD.org
From gavin at FreeBSD.org  Sun Feb  1 09:22:19 2009
From: gavin at FreeBSD.org (Gavin Atkinson)
Date: Sun Feb  1 09:22:26 2009
Subject: SATA drive device moving on 8.0 current
In-Reply-To: <20490.74948.qm@web63901.mail.re1.yahoo.com>
References: <20490.74948.qm@web63901.mail.re1.yahoo.com>
Message-ID: <20090201171938.H97967@ury.york.ac.uk>

On Wed, 28 Jan 2009, Barney Cordoba wrote:

> I booted 8.0-current on a machine that was running 7 and the SATA drive
> came up as ad4 instead of ad8 (as it is detected in 7). This is the case
> was loading GENERIC.
>
> This is going to present a serious problem doing field upgrades as its
> expected that fstab will be the same. What is the reason for the change and
> is there any way to make it compatible with device detection in 7?

I suspect the problem is caused by some changes made in -CURRENT a few 
months ago, which had the potential to change the order that some devices 
may be detected.

Can you post online a dmesg from both 7.x and 8.0 somewhere?

Gavin
From barney_cordoba at yahoo.com  Sun Feb  1 09:46:23 2009
From: barney_cordoba at yahoo.com (Barney Cordoba)
Date: Sun Feb  1 09:46:31 2009
Subject: SATA drive device moving on 8.0 current
In-Reply-To: <20090201171938.H97967@ury.york.ac.uk>
Message-ID: <152543.56415.qm@web63908.mail.re1.yahoo.com>




--- On Sun, 2/1/09, Gavin Atkinson <gavin@FreeBSD.org> wrote:

> From: Gavin Atkinson <gavin@FreeBSD.org>
> Subject: Re: SATA drive device moving on 8.0 current
> To: "Barney Cordoba" <barney_cordoba@yahoo.com>
> Cc: current@FreeBSD.org
> Date: Sunday, February 1, 2009, 12:22 PM
> On Wed, 28 Jan 2009, Barney Cordoba wrote:
> 
> > I booted 8.0-current on a machine that was running 7
> and the SATA drive
> > came up as ad4 instead of ad8 (as it is detected in
> 7). This is the case
> > was loading GENERIC.
> > 
> > This is going to present a serious problem doing field
> upgrades as its
> > expected that fstab will be the same. What is the
> reason for the change and
> > is there any way to make it compatible with device
> detection in 7?
> 
> I suspect the problem is caused by some changes made in
> -CURRENT a few months ago, which had the potential to change
> the order that some devices may be detected.
> 
> Can you post online a dmesg from both 7.x and 8.0
> somewhere?
> 
> Gavin

Yes. The machine is indisposed at the moment, but I'll post it next
time I fire up 8.0

Barney


      
From max at love2party.net  Sun Feb  1 10:21:25 2009
From: max at love2party.net (Max Laier)
Date: Sun Feb  1 10:21:32 2009
Subject: Possible bug in ip_input()
In-Reply-To: <16190.90052.qm@web63904.mail.re1.yahoo.com>
References: <16190.90052.qm@web63904.mail.re1.yahoo.com>
Message-ID: <200902011921.22305.max@love2party.net>

On Sunday 01 February 2009 17:07:51 Barney Cordoba wrote:
> I've noticed the following possible inconsistency.
>
> 1) ip_input() is called with M_FASTFWD_OUR set
> 2) ip_off is not "adjusted" to host representation

That's because ip_off should already be in host byte order at that point.  
M_FASTFWD_OUR indicates that the packet is relooped from within the ip 
processing path which uses host byte order for ip_off and ip_len throughout.

> 3) ip reassembly is erroneously called.
>
> I don't have an actual case that can test this, but it seems like an issue.

-- 
/"\  Best regards,                      | mlaier@freebsd.org
\ /  Max Laier                          | ICQ #67774661
 X   http://pf4freebsd.love2party.net/  | mlaier@EFnet
/ \  ASCII Ribbon Campaign              | Against HTML Mail and News
From ken at mthelicon.com  Sun Feb  1 10:51:27 2009
From: ken at mthelicon.com (Pegasus Mc Cleaft)
Date: Sun Feb  1 10:51:34 2009
Subject: Alternatives to gcc (was Re: gcc 4.3: when will it become
	standard compiler?)
In-Reply-To: <20090201025939.GD83330@dragon.NUXI.org>
References: <de2964020901141507m5a30c466ta1e05694d220ce0b@mail.gmail.com>
	<B37B6C09E4B94843AC71CECE3B32CB1E@PegaPegII>
	<20090201025939.GD83330@dragon.NUXI.org>
Message-ID: <200902011850.33754.ken@mthelicon.com>

On Sunday 01 February 2009 02:59:39 David O'Brien wrote:
> > gcc43 is fairly painless through the ports, but this is of limited use as
> > it will use the base assembler, linker, et al. Even if you install, as I
> > have, the latest binutils from GNU, it will locate /usr/bin/as before
> > /usr/local/bin/as. If you set all the enviroment varables (AR, AS, NM,
> > ...) before you do the build, you run into other problems with finding
> > the bootstrap files later due to the naming problems between
> > "x86_64-obrien-freebsd" and the auto-generated
> > "x86_64-unknown-freebsd8.0" from the GNU configure. In short, I found
> > upgrading the dev-chain a real nightmare.
>
> Its not that bad.  I've created several cross toolchains in the past.
> For those you specify which 'as' and 'ld' to use - how else do you think
> they work.  I don't think you configured your GCC properly if you cannot
> get it to use some binutils from /usr/ports.
>
> In fact when installing GCC on Solaris GCC strongly prefers (or use to)
> gas and gld to Sun's as and ld.  Just tweak that configure logic.

Your probably right... 

What I found is that the port of gcc43 uses the target name of *-portbld-* and 
the default from binutils uses *-unknown-*.. When the configure script runs, 
it misses that you may have a matched tool chain, so uses the /usr/bin/* 
tools. 

I created a port for binutils-2.19 that uses the same target string as the 
gcc43 version does. With that installed, the gcc43 tools pick up on it and 
everything seems happy. Hopefully it will be accepted.. Just waiting 
<chuckles>  

~Peg
From ralph at imada.sdu.dk  Sun Feb  1 12:10:50 2009
From: ralph at imada.sdu.dk (Ralph Zitz)
Date: Sun Feb  1 12:11:23 2009
Subject: patch r187693 breaks HAL on amd64-current
Message-ID: <4985FA10.5080604@imada.sdu.dk>

I'm not a HAL expert, but it seems that the patch makes HAL create a
zombie process when watching /dev/cd0. Reversing the patch makes HAL
work again.

Link to patch message:
http://lists.freebsd.org/pipermail/svn-src-all/2009-January/004073.html

Regards
Ralph Zitz.
From sepotvin at videotron.ca  Sun Feb  1 12:46:47 2009
From: sepotvin at videotron.ca (Stephane E. Potvin)
Date: Sun Feb  1 12:46:54 2009
Subject: patch r187693 breaks HAL on amd64-current
In-Reply-To: <4985FA10.5080604@imada.sdu.dk>
References: <4985FA10.5080604@imada.sdu.dk>
Message-ID: <498607D7.7090507@videotron.ca>

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

Ralph Zitz wrote:
> I'm not a HAL expert, but it seems that the patch makes HAL create a
> zombie process when watching /dev/cd0. Reversing the patch makes HAL
> work again.
> 
> Link to patch message:
> http://lists.freebsd.org/pipermail/svn-src-all/2009-January/004073.html
> 
Hi Ralph

Try the following patch, it should fix your problem with hal.

Regards

Steph
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.10 (FreeBSD)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkmGB9YACgkQmdOXtTCX/nt8tACgj5IzDaHDEsKIJbZPefOwzkiW
Ne4AoMV4GzfMLeVeBAWIRbmG08R7Lpj3
=K7Cu
-----END PGP SIGNATURE-----
-------------- next part --------------
Index: kern/sys_generic.c
===================================================================
--- kern/sys_generic.c	(revision 187983)
+++ kern/sys_generic.c	(working copy)
@@ -903,7 +903,7 @@
  * bit position in the fd_mask array.
  */
 static __inline int
-selflags(fd_mask **ibits, int idx, int bit)
+selflags(fd_mask **ibits, int idx, fd_mask bit)
 {
 	int flags;
 	int msk;
@@ -912,7 +912,7 @@
 	for (msk = 0; msk < 3; msk++) {
 		if (ibits[msk] == NULL)
 			continue;
-		if ((ibits[msk][idx] & (fd_mask)bit) == 0)
+		if ((ibits[msk][idx] & bit) == 0)
 			continue;
 		flags |= select_flags[msk];
 	}
-------------- next part --------------
A non-text attachment was scrubbed...
Name: lp64_select_fix.diff.sig
Type: application/octet-stream
Size: 72 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20090201/569c95d8/lp64_select_fix.diff.obj
From saper at system.pl  Sun Feb  1 12:49:15 2009
From: saper at system.pl (Marcin Cieslak)
Date: Sun Feb  1 12:49:22 2009
Subject: Xorg upgrade disaster: Xlib: extension "Generic Event Extension"
 missing on display ":0.0".
In-Reply-To: <49837CFD.4080603@mail.zedat.fu-berlin.de>
References: <49837CFD.4080603@mail.zedat.fu-berlin.de>
Message-ID: <49860ABC.1030205@system.pl>

O. Hartmann wrote:
> After upgrading one of my FreeBSD 8.0-CUR/amd64 boxes to new xorg-7.4
> and having done hurting recompiling nearly everything/package twice now
> firefox3 still doesn't work properly and hits me when starting with this
> error message:
> 
> Xlib:  extension "Generic Event Extension" missing on display ":0.0".


Looks like libraries (Xext among others) already support the XGE extension:

http://thread.gmane.org/gmane.comp.freedesktop.xorg/36483

but the current the 1.5 Xorg server does not support and the 1.6 release 
is behind schedule a bit:

http://www.phoronix.com/scan.php?page=news_item&px=Njg4OA

I keep getting this error after upgrade of X today but everything works 
as usual.

> Then firefox3 freezes forever, showing something like the background or
> pixel remnants of windows/picograms moving over its window.

The firefox problem is unrelated I think to the message above (as 
demonstrated later in the thred)

--Marcin

From need4spam at bk.ru  Sun Feb  1 12:57:51 2009
From: need4spam at bk.ru (Alexey Ivanov)
Date: Sun Feb  1 12:58:01 2009
Subject: powernow0: set freq failed, err 6
Message-ID: <E1LTjO0-000OdA-00.need4spam-bk-ru@f59.mail.ru>

I have repeating errors in /var/log/messages 

[PH34R] ~> tail -f /var/log/messages
Feb  1 23:34:34 PH34R kernel: powernow0: set freq failed, err 6
Feb  1 23:34:34 PH34R kernel: powernow1: set freq failed, err 6
Feb  1 23:34:34 PH34R kernel: powernow0: set freq failed, err 6
Feb  1 23:34:34 PH34R kernel: powernow1: set freq failed, err 6
Feb  1 23:34:34 PH34R kernel: powernow0: set freq failed, err 6
Feb  1 23:34:41 PH34R last message repeated 17 times

Now freq on my notebook is cut by about a half
dev.cpu.0.freq: 1194

I don't know is it connected, but it first strted when i installed linux 2.6.28 and rebooted from it.

Similiar problem here
   http://lists.freebsd.org/pipermail/freebsd-current/2008-December/001401.html
as i know Keda is using same hardware: notebook HP 6715s

dmesg attached

-------------- next part --------------
A non-text attachment was scrubbed...
Name: dmesg.boot
Type: application/octet-stream
Size: 9357 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20090201/5f6e24a4/dmesg.obj
From swhetzel at gmail.com  Sun Feb  1 12:58:24 2009
From: swhetzel at gmail.com (Scot Hetzel)
Date: Sun Feb  1 12:58:31 2009
Subject: Xorg upgrade desaster: Xlib: extension "Generic Event
	Extension" missing on display ":0.0".
In-Reply-To: <4985877B.8080502@mail.zedat.fu-berlin.de>
References: <49837CFD.4080603@mail.zedat.fu-berlin.de>
	<200901301430.07087.fbsd.questions@rachie.is-a-geek.net>
	<4984EF27.2050405@mail.zedat.fu-berlin.de>
	<790a9fff0901312008x71fa025na58856bde4c7a5be@mail.gmail.com>
	<4985877B.8080502@mail.zedat.fu-berlin.de>
Message-ID: <790a9fff0902011258j5f954ea9s2c9665c3bd8a5c61@mail.gmail.com>

On Sun, Feb 1, 2009 at 5:28 AM, O. Hartmann
<ohartman@mail.zedat.fu-berlin.de> wrote:
> Scot Hetzel wrote:
>> On Sat, Jan 31, 2009 at 6:39 PM, O. Hartmann
>> <ohartman@mail.zedat.fu-berlin.de> wrote:
>>
>>> build-process, but I doubt this. I did a 'ldd' on the Firefox3 binary
>>> and  I got the attached dump of the linked shared objects.
>>> Interestingly, the first three entries show up something missing -
>>> therefore I deinstalled Firefox and rebuild the browser after an
>>> additional rebuild of libxcb (via portupgrade -rf). Previously, all Xorg
>>>
>>
>>
>>> thor# ldd firefox-bin
>>> firefox-bin:
>>>        libxul.so => not found (0x0)
>>>        libmozjs.so => not found (0x0)
>>>        libxpcom.so => not found (0x0)
>>>        libplds4.so.1 => /usr/local/lib/libplds4.so.1 (0x80063e000)
>>>        libplc4.so.1 => /usr/local/lib/libplc4.so.1 (0x80076f000)
>>>
>>
>> When firefox3 was first added to the ports collection, I had noticed
>> this problem with firefox3 (after using sysutils/libchk), but I didn't
>> have this problem with the firefox 2.  A look at the difference
>> between the www/firefox and www/firefox3 Makefiles showed that
>> firefox3 was missing this:
>>
>> LDFLAGS+= -Wl,-rpath,${PREFIX}/lib/${MOZ_RPATH}
>>
>> After adding this line to the ports Makefile, and rebuilding the port,
>> these libraries are now showing as found in the ldd output.
>>
>> Scot
>>
> Isn't that worth a PR?
>
>
Submitted and rejected:

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

As it doesn't affect the operation of Firefox3's firefox-bin program.

Scot
From admin at lissyara.su  Sun Feb  1 13:24:53 2009
From: admin at lissyara.su (Alex Keda)
Date: Sun Feb  1 13:25:00 2009
Subject: powernow0: set freq failed, err 6
In-Reply-To: <E1LTjO0-000OdA-00.need4spam-bk-ru@f59.mail.ru>
References: <E1LTjO0-000OdA-00.need4spam-bk-ru@f59.mail.ru>
Message-ID: <49861321.7010207@lissyara.su>

Alexey Ivanov ?????:
> I have repeating errors in /var/log/messages 
> 
> [PH34R] ~> tail -f /var/log/messages
> Feb  1 23:34:34 PH34R kernel: powernow0: set freq failed, err 6
> Feb  1 23:34:34 PH34R kernel: powernow1: set freq failed, err 6
> Feb  1 23:34:34 PH34R kernel: powernow0: set freq failed, err 6
> Feb  1 23:34:34 PH34R kernel: powernow1: set freq failed, err 6
> Feb  1 23:34:34 PH34R kernel: powernow0: set freq failed, err 6
> Feb  1 23:34:41 PH34R last message repeated 17 times
> 
> Now freq on my notebook is cut by about a half
> dev.cpu.0.freq: 1194
> 
> I don't know is it connected, but it first strted when i installed linux 2.6.28 and rebooted from it.
> 
> Similiar problem here
>    http://lists.freebsd.org/pipermail/freebsd-current/2008-December/001401.html
> as i know Keda is using same hardware: notebook HP 6715s
Confirm. I have some problem.
http://lists.freebsd.org/pipermail/freebsd-current/2009-January/002658.html
http://lists.freebsd.org/pipermail/freebsd-current/2008-December/001401.html
	
Occasionally, not constantly, the problem happens to me.
If the kernel without debug information - less frequently with her - 
more often
From sam at freebsd.org  Sun Feb  1 14:26:24 2009
From: sam at freebsd.org (Sam Leffler)
Date: Sun Feb  1 14:26:31 2009
Subject: ath cannot find my wireless network any more
In-Reply-To: <20090201095721.GE60948@e.0x20.net>
References: <20090129192241.GZ60948@e.0x20.net>	<20090129192830.GE73709@citylink.fud.org.nz>	<20090129194826.GA60948@e.0x20.net>
	<49820EAC.5090400@freebsd.org>	<20090129204323.GB60948@e.0x20.net>	<3a142e750901291328w537b2070t216e393a0fd5b8ba@mail.gmail.com>	<20090129215424.GC60948@e.0x20.net>
	<49853423.9050208@freebsd.org> <20090201095721.GE60948@e.0x20.net>
Message-ID: <4986218F.5060408@freebsd.org>

Lars Engels wrote:
> On Sat, Jan 31, 2009 at 09:33:23PM -0800, Sam Leffler wrote:
>   
>> Lars Engels wrote:
>>     
>>> Ahhh, thanks for the hint. There's a lot of scanning going on in
>>> /var/log/messages but no sign of my own network.
>>>       
>> Unfortunately you haven't shown what this output is.  I asked you to do
>> it to be sure the scan visited the channel w/ your ap and/or whether it
>> sent a probe request frame or saw a beacon from the ap.  The hal changes
>> should not have altered anything for you because your eeprom setup
>> appears to have default settings.  I've been running these changes for a
>> while but I'm likely testing different things than you.
>>
>> If you can send me the debug output it might help (feel free to send it
>> directly).  Otherwise you might try reverting the change.  Since you
>> still haven't sent me the mac+phy revs for your card I can't try to
>> reproduce your setup.
>>     
>
> Sorry, I thought you wanted to see the scan results only when my network shows up.
> Here are two rounds of scanning:
>
> Feb  1 10:48:19 maggie kernel: ath0: <Atheros 5212> mem 0x88000000-0x8800ffff irq 20 at device 0.0 on cardbus0
> Feb  1 10:48:19 maggie kernel: ath0: [ITHREAD]
> Feb  1 10:48:19 maggie kernel: ath0: WARNING: using obsoleted if_watchdog interface
> Feb  1 10:48:19 maggie kernel: ath0: mac 5.9 phy 4.3 radio 3.6
> Feb  1 10:48:19 maggie kernel: wlan0: Ethernet address: 00:0f:b5:9a:47:47
> Feb  1 10:49:23 maggie kernel: wlan0: scan_next: chan  36a ->  40a [active, dwell min 20 max 200]
> Feb  1 10:49:24 maggie kernel: wlan0: scan_next: chan  40a ->  44a [active, dwell min 20 max 200]
> Feb  1 10:49:24 maggie kernel: wlan0: scan_next: chan  44a ->  48a [active, dwell min 20 max 200]
> Feb  1 10:49:24 maggie kernel: wlan0: scan_next: chan  48a ->   2g [active, dwell min 20 max 200]
> Feb  1 10:49:24 maggie kernel: wlan0: scan_next: chan   2g ->   3g [active, dwell min 20 max 200]
> Feb  1 10:49:24 maggie kernel: wlan0: scan_next: chan   3g ->   4g [active, dwell min 20 max 200]
> Feb  1 10:49:25 maggie kernel: wlan0: scan_next: chan   4g ->   5g [active, dwell min 20 max 200]
> Feb  1 10:49:25 maggie kernel: wlan0: scan_next: chan   5g ->   8g [active, dwell min 20 max 200]
> Feb  1 10:49:25 maggie kernel: wlan0: scan_next: chan   8g ->   9g [active, dwell min 20 max 200]
> Feb  1 10:49:25 maggie kernel: wlan0: scan_next: chan   9g ->  10g [active, dwell min 20 max 200]
> Feb  1 10:49:26 maggie kernel: wlan0: scan_next: chan  10g -> 149a [active, dwell min 20 max 200]
> Feb  1 10:49:26 maggie kernel: wlan0: scan_next: chan 149a -> 153a [active, dwell min 20 max 200]
> Feb  1 10:49:26 maggie kernel: wlan0: scan_next: chan 153a -> 157a [active, dwell min 20 max 200]
> Feb  1 10:49:26 maggie kernel: wlan0: scan_next: chan 157a -> 161a [active, dwell min 20 max 200]
> Feb  1 10:49:26 maggie kernel: wlan0: scan_next: chan 161a -> 165a [active, dwell min 20 max 200]
> Feb  1 10:49:27 maggie kernel: wlan0: scan_next: chan 165a ->  50S [active, dwell min 20 max 200]
> Feb  1 10:49:27 maggie kernel: wlan0: scan_next: chan  50S ->  58S [active, dwell min 20 max 200]
> Feb  1 10:49:27 maggie kernel: wlan0: scan_next: chan  58S -> 152S [active, dwell min 20 max 200]
> Feb  1 10:49:27 maggie kernel: wlan0: scan_next: chan 152S -> 160S [active, dwell min 20 max 200]
> Feb  1 10:49:27 maggie kernel: wlan0:  macaddr          bssid         chan  rssi  rate flag  wep  essid
> Feb  1 10:49:27 maggie kernel: - 00:03:c9:54:18:bb 00:03:c9:54:18:bb    8     3! 54M   ess  wep  0x000000000000
> Feb  1 10:49:27 maggie kernel: - 00:1a:2a:c6:de:56 00:1a:2a:c6:de:56    9     4! 54M   ess  wep  "Arcor-C6DE58"
> Feb  1 10:49:27 maggie kernel: wlan0: scan_next: done, [ticks 284189, dwell min 20 scanend 2147762094]
> Feb  1 10:49:27 maggie kernel: wlan0: notify scan done
> Feb  1 10:49:32 maggie kernel: wlan0: ieee80211_ioctl_scanreq: flags 0x20052 duration 0x7fffffff mindwell 0 maxdwell 0 nssid 1
> Feb  1 10:49:32 maggie kernel: wlan0: ieee80211_check_scan: active scan, append, nojoin, once
> Feb  1 10:49:32 maggie kernel: wlan0:  macaddr          bssid         chan  rssi  rate flag  wep  essid
>
>
> And here is the output of sysctl:
>
> lars@pts/6 > sysctl dev.ath.0
> dev.ath.0.%desc: Atheros 5212
> dev.ath.0.%driver: ath
> dev.ath.0.%location: slot=0 function=0
> dev.ath.0.%pnpinfo: vendor=0x168c device=0x0013 subvendor=0x1385 subdevice=0x4610 class=0x020000
> dev.ath.0.%parent: cardbus0
> dev.ath.0.smoothing_rate: 95
> dev.ath.0.sample_rate: 10
> dev.ath.0.sample_stats: 0
> dev.ath.0.countrycode: 0
> dev.ath.0.regdomain: 0
> dev.ath.0.slottime: 9
> dev.ath.0.acktimeout: 22
> dev.ath.0.ctstimeout: 22
> dev.ath.0.softled: 0
> dev.ath.0.ledpin: 0
> dev.ath.0.ledon: 0
> dev.ath.0.ledidle: 2700
> dev.ath.0.txantenna: 0
> dev.ath.0.rxantenna: 1
> dev.ath.0.diversity: 1
> dev.ath.0.txintrperiod: 5
> dev.ath.0.diag: 0
> dev.ath.0.tpscale: 0
> dev.ath.0.tpc: 0
> dev.ath.0.tpack: 63
> dev.ath.0.tpcts: 63
> dev.ath.0.fftxqmin: 2
> dev.ath.0.fftxqmax: 50
> dev.ath.0.intmit: 1
> dev.ath.0.monpass: 24
>
> Feb  1 10:49:32 maggie kernel: - 00:03:c9:54:18:bb 00:03:c9:54:18:bb    8     3! 54M   ess  wep  0x000000000000!
> Feb  1 10:49:32 maggie kernel: - 00:1a:2a:c6:de:56 00:1a:2a:c6:de:56    9     4! 54M   ess  wep  "Arcor-C6DE58"!
> Feb  1 10:49:32 maggie kernel: wlan0: start_scan_locked: active scan, duration 2147483647 mindwell 0 maxdwell 0, desired mode auto, append, nojoin, once
> Feb  1 10:49:32 maggie kernel: wlan0: scan set 1g, 6G, 11g, 7g, 52a, 56a, 60a, 64a, 36a, 40a, 44a, 48a, 2g, 3g, 4g, 5g, 8g, 9g, 10g, 149a, 153a, 157a, 161a, 165a, 50S, 58S, 152S, 160S dwell min 20 max 200
>   

The scan list used 6G (Dynamic Turbo G aka 108G) for channel 6; this was 
why you never saw ap's operating on channel 6.

> Feb  1 10:49:32 maggie kernel: wlan0: scan_next: chan 160S ->   1g [active, dwell min 20 max 200]
> Feb  1 10:49:33 maggie kernel: wlan0: scan_next: chan   1g ->   6G [active, dwell min 20 max 200]
> Feb  1 10:49:33 maggie kernel: wlan0: scan_next: chan   6G ->  11g [active, dwell min 20 max 200]
> Feb  1 10:49:33 maggie kernel: wlan0: scan_next: chan  11g ->   7g [active, dwell min 20 max 200]
> Feb  1 10:49:33 maggie kernel: wlan0: scan_next: chan   7g ->  52a [active, dwell min 20 max 200]
> Feb  1 10:49:33 maggie kernel: wlan0: scan_next: chan  52a ->  56a [active, dwell min 20 max 200]
> Feb  1 10:49:34 maggie kernel: wlan0: scan_next: chan  56a ->  60a [active, dwell min 20 max 200]
> Feb  1 10:49:34 maggie kernel: wlan0: scan_next: chan  60a ->  64a [active, dwell min 20 max 200]
> Feb  1 10:49:34 maggie kernel: wlan0: scan_next: chan  64a ->  36a [active, dwell min 20 max 200]
> Feb  1 10:49:34 maggie kernel: wlan0: scan_next: chan  36a ->  40a [active, dwell min 20 max 200]
> Feb  1 10:49:34 maggie kernel: wlan0: scan_next: chan  40a ->  44a [active, dwell min 20 max 200]
> Feb  1 10:49:35 maggie kernel: wlan0: scan_next: chan  44a ->  48a [active, dwell min 20 max 200]
> Feb  1 10:49:35 maggie kernel: wlan0: scan_next: chan  48a ->   2g [active, dwell min 20 max 200]
> Feb  1 10:49:35 maggie kernel: wlan0: scan_next: chan   2g ->   3g [active, dwell min 20 max 200]
> Feb  1 10:49:35 maggie kernel: wlan0: scan_next: chan   3g ->   4g [active, dwell min 20 max 200]
> Feb  1 10:49:35 maggie kernel: wlan0: scan_next: chan   4g ->   5g [active, dwell min 20 max 200]
> Feb  1 10:49:36 maggie kernel: wlan0: scan_next: chan   5g ->   8g [active, dwell min 20 max 200]
> Feb  1 10:49:36 maggie kernel: [00:03:c9:54:18:bb] new beacon on chan 8 (bss chan 8) 0x000000000000 rssi 3
> Feb  1 10:49:36 maggie kernel: [00:03:c9:54:18:bb] caps 0x411 bintval 100 erp 0x100
> Feb  1 10:49:36 maggie kernel: wlan0: ieee80211_add_scan: chan   8g min dwell met (292559 > 292497)
> Feb  1 10:49:36 maggie kernel: wlan0: scan_next: chan   8g ->   9g [active, dwell min 20 max 200]
> Feb  1 10:49:36 maggie kernel: [00:1a:2a:c6:de:56] new beacon on chan 9 (bss chan 9) "Arcor-C6DE58" rssi 4
> Feb  1 10:49:36 maggie kernel: [00:1a:2a:c6:de:56] caps 0x431 bintval 100 erp 0x100
> Feb  1 10:49:36 maggie kernel: wlan0: ieee80211_add_scan: chan   9g min dwell met (292590 > 292585)
> Feb  1 10:49:36 maggie kernel: wlan0: scan_next: chan   9g ->  10g [active, dwell min 20 max 200]
> Feb  1 10:49:36 maggie kernel: wlan0: scan_next: chan  10g -> 149a [active, dwell min 20 max 200]
> Feb  1 10:49:36 maggie kernel: wlan0: scan_next: chan 149a -> 153a [active, dwell min 20 max 200]
> Feb  1 10:49:36 maggie kernel: wlan0: scan_next: chan 153a -> 157a [active, dwell min 20 max 200]
> Feb  1 10:49:37 maggie kernel: wlan0: scan_next: chan 157a -> 161a [active, dwell min 20 max 200]
> Feb  1 10:49:37 maggie kernel: wlan0: scan_next: chan 161a -> 165a [active, dwell min 20 max 200]
> Feb  1 10:49:37 maggie kernel: wlan0: scan_next: chan 165a ->  50S [active, dwell min 20 max 200]
> Feb  1 10:49:37 maggie kernel: wlan0: scan_next: chan  50S ->  58S [active, dwell min 20 max 200]
> Feb  1 10:49:37 maggie kernel: wlan0: scan_next: chan  58S -> 152S [active, dwell min 20 max 200]
> Feb  1 10:49:38 maggie kernel: wlan0: scan_next: chan 152S -> 160S [active, dwell min 20 max 200]
> Feb  1 10:49:38 maggie kernel: wlan0:  macaddr          bssid         chan  rssi  rate flag  wep  essid
> Feb  1 10:49:38 maggie kernel: - 00:03:c9:54:18:bb 00:03:c9:54:18:bb    8     3! 54M   ess  wep  0x000000000000!
> Feb  1 10:49:38 maggie kernel: - 00:1a:2a:c6:de:56 00:1a:2a:c6:de:56    9     4! 54M   ess  wep  "Arcor-C6DE58"!
> Feb  1 10:49:38 maggie kernel: wlan0: scan_next: done, [ticks 294642, dwell min 20 scanend 2147772838]
> Feb  1 10:49:38 maggie kernel: wlan0: notify scan done
>   
Should be fixed by r187991.

    Sam

From brooks at freebsd.org  Sun Feb  1 14:58:39 2009
From: brooks at freebsd.org (Brooks Davis)
Date: Sun Feb  1 14:58:46 2009
Subject: Alternatives to gcc
In-Reply-To: <op.uoomb4u79aq2h7@localhost>
References: <61484.71762.qm@web32708.mail.mud.yahoo.com>
	<86skniyp60.fsf@ds4.des.no>
	<20090201060549.GE83330@dragon.NUXI.org>
	<op.uoomb4u79aq2h7@localhost>
Message-ID: <20090201225720.GA16332@lor.one-eyed-alien.net>

On Sun, Feb 01, 2009 at 10:48:42AM -0600, Jeremy Messenger wrote:
> On Sun, 01 Feb 2009 00:05:49 -0600, David O'Brien <obrien@freebsd.org>
> wrote:
> 
>> "Pedro F. Giffuni" <giffunip@tutopia.com> writes:
>>> - Replacing groff with something less restricted that doesn't require
>>> C++: Heirloom-doctools may be an option.
>> 
>> You're proposing replacing GPLv2 stuff with CDDL'ed stuff?
>> 
>>     $ cd heirloom-doctools-080407> grep -l -R CDDL * | wc -l
>>          217
>> 
>> The last time I asked $WORK's lawyers, GPLv2 was acceptable to
>> *carefully* ship with our product.  CDDL was forbidden (as is GPLv3).
> 
> Interesting... I thought, CDDL is more flexible than GPLv2? Or do I 
> misunderstand something with CDDL?

Some provisions of CDDL make lawyers uncomfortable, the patent
provisions in particular.

-- Brooks
-------------- 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/20090201/5c7d99eb/attachment.pgp
From obrien at freebsd.org  Sun Feb  1 17:00:16 2009
From: obrien at freebsd.org (David O'Brien)
Date: Sun Feb  1 17:00:25 2009
Subject: Alternatives to gcc
In-Reply-To: <20090201225720.GA16332@lor.one-eyed-alien.net>
References: <61484.71762.qm@web32708.mail.mud.yahoo.com>
	<86skniyp60.fsf@ds4.des.no>
	<20090201060549.GE83330@dragon.NUXI.org>
	<op.uoomb4u79aq2h7@localhost>
	<20090201225720.GA16332@lor.one-eyed-alien.net>
Message-ID: <20090202010008.GB14332@dragon.NUXI.org>

On Sun, Feb 01, 2009 at 04:57:20PM -0600, Brooks Davis wrote:
> On Sun, Feb 01, 2009 at 10:48:42AM -0600, Jeremy Messenger wrote:
> > On Sun, 01 Feb 2009 00:05:49 -0600, David O'Brien <obrien@freebsd.org>
> > wrote:
> > 
> >> "Pedro F. Giffuni" <giffunip@tutopia.com> writes:
> >>> - Replacing groff with something less restricted that doesn't require
> >>> C++: Heirloom-doctools may be an option.
> >> 
> >> You're proposing replacing GPLv2 stuff with CDDL'ed stuff?
> >> 
> >>     $ cd heirloom-doctools-080407> grep -l -R CDDL * | wc -l
> >>          217
> >> 
> >> The last time I asked $WORK's lawyers, GPLv2 was acceptable to
> >> *carefully* ship with our product.  CDDL was forbidden (as is GPLv3).
> > 
> > Interesting... I thought, CDDL is more flexible than GPLv2? Or do I 
> > misunderstand something with CDDL?
> 
> Some provisions of CDDL make lawyers uncomfortable, the patent
> provisions in particular.

In fact, if you can constrain the viralness of GPLv3 within your product,
some lawyers are more comfortable with GPLv3 than CDDL.

The patent provisions are way too widely scoped in the CDDL - they are
not restricted to the technologies the software uses.

-- 
-- David  (obrien@FreeBSD.org)
From yanefbsd at gmail.com  Sun Feb  1 17:51:29 2009
From: yanefbsd at gmail.com (Garrett Cooper)
Date: Sun Feb  1 17:51:36 2009
Subject: Alternatives to gcc (was Re: gcc 4.3: when will it
	becomestandard compiler?)
In-Reply-To: <20090201164154.V97967@ury.york.ac.uk>
References: <87223.61659.qm@web32707.mail.mud.yahoo.com>
	<20090201164154.V97967@ury.york.ac.uk>
Message-ID: <D6D7D65D-C09A-4815-9328-930612FDC523@gmail.com>

On Feb 1, 2009, at 9:13 AM, Gavin Atkinson wrote:

> On Sat, 31 Jan 2009, Pedro F. Giffuni wrote:
>> --- On Sat, 1/31/09, Mark Linimon <linimon@lonesome.com> wrote:
>>
>> On Sat, Jan 31, 2009 at 01:08:54PM -0800, Pedro F. Giffuni wrote:
>>>> The effort didn't go far enough. Why haven't we removed GNU  
>>>> readline ?
>>>
>>> Probably either because someone hasn't written a BSD-licensed one,  
>>> or
>>> someone hasn't done the work to test-compile src and ports on all  
>>> the
>>> appropriate architectures.
>>
>> Wrong on both:
>>
>> - libedit has a readline compatibility mode that has replaced GNU  
>> readline in the other BSDs.
>> - If you look in the archives you will find patches.
>>
>> If there really was any effort to remove GPL'd stuff from the tree  
>> it missed this big time: GNU readline is a library under the GPL  
>> (not LGPL), it should be dead long ago.
>
> As far as I can see, in the base system, there are five things  
> linked against readline which would not otherwise be under the GPL:
>
> kadmin, ktutil, gvinum, ntpq, ntpdc
>
> Of these, gvinum is a surprise.  I'm not sure what it needs readline  
> for, and cannot see why this isn't able to use the copy of libedit  
> in the base system.  ntpq and ntpdc are being built with the option  
> to use libreadline commented out, so I'm not sure why they are being  
> linked with it.  I don't know about the Kerberos programs, but given  
> they are contrib I suspect that may be a reaon why they are still  
> using libedit rather than readline.
>
> I may be wrong (feel free to correct me) but I can't see what the  
> real issue is with having readline in the base, if only code that is  
> already GPL is linking against it.  Obviously it would be good if  
> the five utilities above could be linked against libedit rather than  
> readline.
>
> Gavin

	readline is also GPLv2, not LGPLv2.1, so AFAICT any changes that  
vendors make to any sources with readline support linked in would  
potentially force them to expose their proprietary secrets IF the  
copyright owner sued for GPLv2 infringement.
	Welcome to the wonderful world of FSF...
-Garrett
From subscr1024 at mail.ru  Sun Feb  1 18:36:14 2009
From: subscr1024 at mail.ru (Subscriber)
Date: Sun Feb  1 18:36:30 2009
Subject: ath driver (?) lock system after last update
Message-ID: <498652D2.7030906@mail.ru>

I updated my 8-CURRENT and now system freeze shortly after boot (~0.5-3
minutes). I see following messages in console:

Jan 31 02:18:03 cache kernel: ath0: bad series0 hwrate 0x0, tries 4 ts_status 0x0
Jan 31 02:18:03 cache kernel: ath0: bad series1 hwrate 0x0, tries 3 ts_status 0x0
Jan 31 02:18:03 cache kernel: ath0: bad series2 hwrate 0x0, tries 4 ts_status 0x0
Jan 31 02:18:03 cache kernel: ath0: bad series0 hwrate 0x0, tries 4 ts_status 0x0
Jan 31 02:18:03 cache kernel: ath0: bad series1 hwrate 0x0, tries 3 ts_status 0x0
Jan 31 02:18:03 cache kernel: ath0: bad series2 hwrate 0x0, tries 4 ts_status 0x0
Jan 31 02:18:03 cache kernel: ath0: bad series0 hwrate 0x0, tries 4 ts_status 0x0
Jan 31 02:18:03 cache kernel: ath0: bad series1 hwrate 0x0, tries 3 ts_status 0x0
Jan 31 02:18:03 cache kernel: ath0: bad series2 hwrate 0x0, tries 4 ts_status 0x0
...

much time, then system freeze. Before last update I was never see those messages.
Now I rolled back to HEAD sources with date=2009.01.01, and all seems OK.

###################################### "uname -a" output:

FreeBSD user 8.0-CURRENT FreeBSD 8.0-CURRENT #0: Sun Feb  1 13:53:48 MSK 2009
     user@user:/usr/obj/usr/src/sys/GX710  amd64

###################################### "dmesg" output:
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-CURRENT #0: Sun Feb  1 13:53:48 MSK 2009
     cache@cache:/usr/obj/usr/src/sys/GX710.8
Timecounter "i8254" frequency 1193182 Hz quality 0
CPU: AMD Turion(tm) 64 X2 Mobile Technology TL-64 (798.01-MHz K8-class CPU)
   Origin = "AuthenticAMD"  Id = 0x60f81  Stepping = 1
 
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=0x2001<SSE3,CX16>
   AMD Features=0xea500800<SYSCALL,NX,MMX+,FFXSR,RDTSCP,LM,3DNow!+,3DNow!>
   AMD Features2=0x11f<LAHF,CMP,SVM,ExtAPIC,CR8,Prefetch>
   Cores per package: 2
usable memory = 4284284928 (4085 MB)
avail memory  = 4120625152 (3929 MB)
ACPI APIC Table: <MSI_NB MEGABOOK>
FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs
  cpu0 (BSP): APIC ID:  0
  cpu1 (AP): APIC ID:  1
ioapic0 <Version 2.1> irqs 0-23 on motherboard
wlan: mac acl policy registered
kbd1 at kbdmux0
kqemu version 0x00010400
kqemu: KQEMU installed, max_locked_mem=2091936kB.
acpi0: <MSI_NB MEGABOOK> on motherboard
acpi0: [ITHREAD]
acpi0: Power Button (fixed)
ACPI Error (evregion-0427): No handler for Region [EC__] (0xffffff0001678800) 
[EmbeddedControl] [20070320]
ACPI Error (exfldio-0390): Region EmbeddedControl(3) has no handler [20070320]

**** Exception AE_NOT_EXIST during execution of method 
[\\_SB_.PCI0.SBRG.EC__.BAT1._STA] (Node 0xffffff000167b880)

Method Execution Stack:
     Method [_STA] executing: MBTS

Local Variables for method [_STA]:
     Local0: 0 <Null Object>
     Local1: 0 <Null Object>
     Local2: 0 <Null Object>
     Local3: 0 <Null Object>
     Local4: 0 <Null Object>
     Local5: 0 <Null Object>
     Local6: 0 <Null Object>
     Local7: 0 <Null Object>

Arguments for Method [_STA]:  (0 arguments defined, max concurrency = 0)
     Arg0:   0 <Null Object>
     Arg1:   0 <Null Object>
     Arg2:   0 <Null Object>
     Arg3:   0 <Null Object>
     Arg4:   0 <Null Object>
     Arg5:   0 <Null Object>
     Arg6:   0 <Null Object>

ACPI Error (psparse-0626): Method parse/execution failed 
[\\_SB_.PCI0.SBRG.EC__.BAT1._STA] (Node 0xffffff000167b880), AE_NOT_EXIST
ACPI Error (uteval-0309): Method execution failed 
[\\_SB_.PCI0.SBRG.EC__.BAT1._STA] (Node 0xffffff000167b880), AE_NOT_EXIST
ACPI Error (evregion-0427): No handler for Region [EC__] (0xffffff0001678800) 
[EmbeddedControl] [20070320]
ACPI Error (exfldio-0390): Region EmbeddedControl(3) has no handler [20070320]

**** Exception AE_NOT_EXIST during execution of method 
[\\_SB_.PCI0.SBRG.EC__.BAT1._STA] (Node 0xffffff000167b880)

Method Execution Stack:
     Method [_STA] executing: MBTS

Local Variables for method [_STA]:
     Local0: 0 <Null Object>
     Local1: 0 <Null Object>
     Local2: 0 <Null Object>
     Local3: 0 <Null Object>
     Local4: 0 <Null Object>
     Local5: 0 <Null Object>
     Local6: 0 <Null Object>
     Local7: 0 <Null Object>

Arguments for Method [_STA]:  (0 arguments defined, max concurrency = 0)
     Arg0:   0 <Null Object>
     Arg1:   0 <Null Object>
     Arg2:   0 <Null Object>
     Arg3:   0 <Null Object>
     Arg4:   0 <Null Object>
     Arg5:   0 <Null Object>
     Arg6:   0 <Null Object>

ACPI Error (psparse-0626): Method parse/execution failed 
[\\_SB_.PCI0.SBRG.EC__.BAT1._STA] (Node 0xffffff000167b880), AE_NOT_EXIST
ACPI Error (uteval-0309): Method execution failed 
[\\_SB_.PCI0.SBRG.EC__.BAT1._STA] (Node 0xffffff000167b880), AE_NOT_EXIST
ACPI Error (evregion-0427): No handler for Region [EC__] (0xffffff0001678800) 
[EmbeddedControl] [20070320]
ACPI Error (exfldio-0390): Region EmbeddedControl(3) has no handler [20070320]

**** Exception AE_NOT_EXIST during execution of method 
[\\_SB_.PCI0.SBRG.EC__.BAT1._STA] (Node 0xffffff000167b880)

Method Execution Stack:
     Method [_STA] executing: MBTS

Local Variables for method [_STA]:
     Local0: 0 <Null Object>
     Local1: 0 <Null Object>
     Local2: 0 <Null Object>
     Local3: 0 <Null Object>
     Local4: 0 <Null Object>
     Local5: 0 <Null Object>
     Local6: 0 <Null Object>
     Local7: 0 <Null Object>

Arguments for Method [_STA]:  (0 arguments defined, max concurrency = 0)
     Arg0:   0 <Null Object>
     Arg1:   0 <Null Object>
     Arg2:   0 <Null Object>
     Arg3:   0 <Null Object>
     Arg4:   0 <Null Object>
     Arg5:   0 <Null Object>
     Arg6:   0 <Null Object>

ACPI Error (psparse-0626): Method parse/execution failed 
[\\_SB_.PCI0.SBRG.EC__.BAT1._STA] (Node 0xffffff000167b880), AE_NOT_EXIST
ACPI Error (uteval-0309): Method execution failed 
[\\_SB_.PCI0.SBRG.EC__.BAT1._STA] (Node 0xffffff000167b880), AE_NOT_EXIST
ACPI Error (evregion-0427): No handler for Region [EC__] (0xffffff0001678800) 
[EmbeddedControl] [20070320]
ACPI Error (exfldio-0390): Region EmbeddedControl(3) has no handler [20070320]

**** Exception AE_NOT_EXIST during execution of method 
[\\_SB_.PCI0.SBRG.EC__.BAT1._STA] (Node 0xffffff000167b880)

Method Execution Stack:
     Method [_STA] executing: MBTS

Local Variables for method [_STA]:
     Local0: 0 <Null Object>
     Local1: 0 <Null Object>
     Local2: 0 <Null Object>
     Local3: 0 <Null Object>
     Local4: 0 <Null Object>
     Local5: 0 <Null Object>
     Local6: 0 <Null Object>
     Local7: 0 <Null Object>

Arguments for Method [_STA]:  (0 arguments defined, max concurrency = 0)
     Arg0:   0 <Null Object>
     Arg1:   0 <Null Object>
     Arg2:   0 <Null Object>
     Arg3:   0 <Null Object>
     Arg4:   0 <Null Object>
     Arg5:   0 <Null Object>
     Arg6:   0 <Null Object>

ACPI Error (psparse-0626): Method parse/execution failed 
[\\_SB_.PCI0.SBRG.EC__.BAT1._STA] (Node 0xffffff000167b880), AE_NOT_EXIST
ACPI Error (uteval-0309): Method execution failed 
[\\_SB_.PCI0.SBRG.EC__.BAT1._STA] (Node 0xffffff000167b880), AE_NOT_EXIST
ACPI Error (evregion-0427): No handler for Region [EC__] (0xffffff0001678800) 
[EmbeddedControl] [20070320]
ACPI Error (exfldio-0390): Region EmbeddedControl(3) has no handler [20070320]

**** Exception AE_NOT_EXIST during execution of method 
[\\_SB_.PCI0.SBRG.EC__.BAT1._STA] (Node 0xffffff000167b880)

Method Execution Stack:
     Method [_STA] executing: MBTS

Local Variables for method [_STA]:
     Local0: 0 <Null Object>
     Local1: 0 <Null Object>
     Local2: 0 <Null Object>
     Local3: 0 <Null Object>
     Local4: 0 <Null Object>
     Local5: 0 <Null Object>
     Local6: 0 <Null Object>
     Local7: 0 <Null Object>

Arguments for Method [_STA]:  (0 arguments defined, max concurrency = 0)
     Arg0:   0 <Null Object>
     Arg1:   0 <Null Object>
     Arg2:   0 <Null Object>
     Arg3:   0 <Null Object>
     Arg4:   0 <Null Object>
     Arg5:   0 <Null Object>
     Arg6:   0 <Null Object>

ACPI Error (psparse-0626): Method parse/execution failed 
[\\_SB_.PCI0.SBRG.EC__.BAT1._STA] (Node 0xffffff000167b880), AE_NOT_EXIST
ACPI Error (uteval-0309): Method execution failed 
[\\_SB_.PCI0.SBRG.EC__.BAT1._STA] (Node 0xffffff000167b880), AE_NOT_EXIST
ACPI Error (evregion-0427): No handler for Region [EC__] (0xffffff0001678800) 
[EmbeddedControl] [20070320]
ACPI Error (exfldio-0390): Region EmbeddedControl(3) has no handler [20070320]

**** Exception AE_NOT_EXIST during execution of method 
[\\_SB_.PCI0.SBRG.EC__.BAT1._STA] (Node 0xffffff000167b880)

Method Execution Stack:
     Method [_STA] executing: MBTS

Local Variables for method [_STA]:
     Local0: 0 <Null Object>
     Local1: 0 <Null Object>
     Local2: 0 <Null Object>
     Local3: 0 <Null Object>
     Local4: 0 <Null Object>
     Local5: 0 <Null Object>
     Local6: 0 <Null Object>
     Local7: 0 <Null Object>

Arguments for Method [_STA]:  (0 arguments defined, max concurrency = 0)
     Arg0:   0 <Null Object>
     Arg1:   0 <Null Object>
     Arg2:   0 <Null Object>
     Arg3:   0 <Null Object>
     Arg4:   0 <Null Object>
     Arg5:   0 <Null Object>
     Arg6:   0 <Null Object>

ACPI Error (psparse-0626): Method parse/execution failed 
[\\_SB_.PCI0.SBRG.EC__.BAT1._STA] (Node 0xffffff000167b880), AE_NOT_EXIST
ACPI Error (uteval-0309): Method execution failed 
[\\_SB_.PCI0.SBRG.EC__.BAT1._STA] (Node 0xffffff000167b880), AE_NOT_EXIST
ACPI Error (evregion-0427): No handler for Region [EC__] (0xffffff0001678800) 
[EmbeddedControl] [20070320]
ACPI Error (exfldio-0390): Region EmbeddedControl(3) has no handler [20070320]

**** Exception AE_NOT_EXIST during execution of method 
[\\_SB_.PCI0.SBRG.EC__.BAT1._STA] (Node 0xffffff000167b880)

Method Execution Stack:
     Method [_STA] executing: MBTS

Local Variables for method [_STA]:
     Local0: 0 <Null Object>
     Local1: 0 <Null Object>
     Local2: 0 <Null Object>
     Local3: 0 <Null Object>
     Local4: 0 <Null Object>
     Local5: 0 <Null Object>
     Local6: 0 <Null Object>
     Local7: 0 <Null Object>

Arguments for Method [_STA]:  (0 arguments defined, max concurrency = 0)
     Arg0:   0 <Null Object>
     Arg1:   0 <Null Object>
     Arg2:   0 <Null Object>
     Arg3:   0 <Null Object>
     Arg4:   0 <Null Object>
     Arg5:   0 <Null Object>
     Arg6:   0 <Null Object>

ACPI Error (psparse-0626): Method parse/execution failed 
[\\_SB_.PCI0.SBRG.EC__.BAT1._STA] (Node 0xffffff000167b880), AE_NOT_EXIST
ACPI Error (uteval-0309): Method execution failed 
[\\_SB_.PCI0.SBRG.EC__.BAT1._STA] (Node 0xffffff000167b880), AE_NOT_EXIST
acpi0: reservation of 0, a0000 (3) failed
acpi0: reservation of 100000, cff00000 (3) failed
ACPI HPET table warning: Sequence is non-zero (2)
Timecounter "ACPI-safe" frequency 3579545 Hz quality 850
acpi_timer0: <32-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0
acpi_ec0: <Embedded Controller: GPE 0x6> port 0x62,0x66 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 2.0 on pci0
pci1: <ACPI PCI bus> on pcib1
vgapci0: <VGA-compatible display> port 0xb000-0xb0ff mem 
0xd0000000-0xdfffffff,0xfd6f0000-0xfd6fffff irq 18 at device 0.0 on pci1
acpi_video0: <ACPI video extension> on vgapci0
hdac0: <ATI (Unknown) High Definition Audio Controller> mem 
0xfd6ec000-0xfd6effff irq 19 at device 0.1 on pci1
hdac0: HDA Driver Revision: 20081226_0122
hdac0: [ITHREAD]
pcib2: <ACPI PCI-PCI bridge> at device 4.0 on pci0
pci2: <ACPI PCI bus> on pcib2
ath0: <Atheros 5424/2424> mem 0xfd7f0000-0xfd7fffff irq 16 at device 0.0 on pci2
ath0: [ITHREAD]
ath0: WARNING: using obsoleted if_watchdog interface
ath0: mac 14.2 phy 7.0 radio 10.2
pcib3: <ACPI PCI-PCI bridge> at device 6.0 on pci0
pci3: <ACPI PCI bus> on pcib3
pcib4: <ACPI PCI-PCI bridge> at device 7.0 on pci0
pci5: <ACPI PCI bus> on pcib4
re0: <RealTek 8168/8168B/8168C/8168CP/8168D/8111B/8111C/8111CP PCIe Gigabit 
Ethernet> port 0xc800-0xc8ff mem 0xfe2ff000-0xfe2fffff irq 19 at device 0.0 on 
pci5
re0: turning off MSI enable bit.
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:92:4b:18:11
re0: [FILTER]
atapci0: <ATI IXP600 SATA300 controller> port 
0xa000-0xa007,0x9000-0x9003,0x8000-0x8007,0x7000-0x7003,0x6000-0x600f mem 
0xfd5ff800-0xfd5ffbff irq 22 at device 18.0 on pci0
atapci0: [ITHREAD]
atapci0: AHCI Version 01.10 controller with 4 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]
ata5: <ATA channel 3> on atapci0
ata5: [ITHREAD]
ohci0: <OHCI (generic) USB controller> mem 0xfd5fe000-0xfd5fefff irq 16 at 
device 19.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: 2 ports with 2 removable, self powered
ohci1: <OHCI (generic) USB controller> mem 0xfd5fd000-0xfd5fdfff irq 17 at 
device 19.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: 2 ports with 2 removable, self powered
ohci2: <OHCI (generic) USB controller> mem 0xfd5fc000-0xfd5fcfff irq 18 at 
device 19.2 on pci0
ohci2: [GIANT-LOCKED]
ohci2: [ITHREAD]
usb2: OHCI version 1.0, legacy support
usb2: <OHCI (generic) USB controller> on ohci2
usb2: USB revision 1.0
uhub2: <ATI OHCI root hub, class 9/0, rev 1.00/1.00, addr 1> on usb2
uhub2: 2 ports with 2 removable, self powered
ohci3: <OHCI (generic) USB controller> mem 0xfd5fb000-0xfd5fbfff irq 17 at 
device 19.3 on pci0
ohci3: [GIANT-LOCKED]
ohci3: [ITHREAD]
usb3: OHCI version 1.0, legacy support
usb3: <OHCI (generic) USB controller> on ohci3
usb3: USB revision 1.0
uhub3: <ATI OHCI root hub, class 9/0, rev 1.00/1.00, addr 1> on usb3
uhub3: 2 ports with 2 removable, self powered
ohci4: <OHCI (generic) USB controller> mem 0xfd5fa000-0xfd5fafff irq 18 at 
device 19.4 on pci0
ohci4: [GIANT-LOCKED]
ohci4: [ITHREAD]
usb4: OHCI version 1.0, legacy support
usb4: <OHCI (generic) USB controller> on ohci4
usb4: USB revision 1.0
uhub4: <ATI OHCI root hub, class 9/0, rev 1.00/1.00, addr 1> on usb4
uhub4: 2 ports with 2 removable, self powered
ehci0: <EHCI (generic) USB 2.0 controller> mem 0xfd5ff000-0xfd5ff0ff irq 19 at 
device 19.5 on pci0
ehci0: [GIANT-LOCKED]
ehci0: [ITHREAD]
usb5: EHCI version 1.0
usb5: companion controllers, 2 ports each: usb0 usb1 usb2 usb3 usb4
usb5: <EHCI (generic) USB 2.0 controller> on ehci0
usb5: USB revision 2.0
uhub5: <ATI EHCI root hub, class 9/0, rev 2.00/1.00, addr 1> on usb5
uhub5: 10 ports with 10 removable, self powered
ugen0: <vendor 0x0402 USB2.0 Camera, class 0/0, rev 2.00/1.00, addr 2> on uhub5
pci0: <serial bus, SMBus> at device 20.0 (no driver attached)
atapci1: <ATI IXP600 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 0xfd5f4000-0xfd5f7fff 
irq 16 at device 20.2 on pci0
hdac1: HDA Driver Revision: 20081226_0122
hdac1: [ITHREAD]
isab0: <PCI-ISA bridge> at device 20.3 on pci0
isa0: <ISA bus> on isab0
pcib5: <ACPI PCI-PCI bridge> at device 20.4 on pci0
pci6: <ACPI PCI bus> on pcib5
cbb0: <PCI-CardBus Bridge> irq 20 at device 4.0 on pci6
cardbus0: <CardBus bus> on cbb0
pccard0: <16-bit PCCard bus> on cbb0
cbb0: [FILTER]
pci6: <base peripheral, SD host controller> at device 4.2 (no driver attached)
pci6: <bridge> at device 4.3 (no driver attached)
fwohci0: <1394 Open Host Controller Interface> mem 
0xfe3fd000-0xfe3fdfff,0xfe3ff000-0xfe3ff7ff irq 20 at device 4.4 on pci6
fwohci0: [FILTER]
fwohci0: OHCI version 1.10 (ROM=0)
fwohci0: No. of Isochronous channels is 8.
fwohci0: EUI64 00:dc:10:00:af:43:34:01
fwohci0: Phy 1394a available S400, 2 ports.
fwohci0: Link S400, max_rec 2048 bytes.
firewire0: <IEEE1394(FireWire) bus> on fwohci0
dcons_crom0: <dcons configuration ROM> on firewire0
dcons_crom0: bus_addr 0xc7a08000
fwe0: <Ethernet over FireWire> on firewire0
if_fwe0: Fake Ethernet address: 02:dc:10:43:34:01
fwe0: Ethernet address: 02:dc:10:43:34:01
fwip0: <IP over FireWire> on firewire0
fwip0: Firewire address: 00:dc:10:00:af:43:34:01 @ 0xfffe00000000, S400, 
maxrec 2048
sbp0: <SBP-2/SCSI over FireWire> on firewire0
fwohci0: Initiate bus reset
fwohci0: BUS reset
fwohci0: node_id=0xc000ffc0, gen=1, CYCLEMASTER mode
k8temp0: <AMD K8 Thermal Sensors> on hostb4
acpi_button0: <Power Button> on acpi0
acpi_tz0: <Thermal Zone> on acpi0
atrtc0: <AT realtime clock> port 0x70-0x71 irq 8 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 IntelliMouse, device ID 3
acpi_acad0: <AC Adapter> on acpi0
battery0: <ACPI Control Method Battery> on acpi0
acpi_lid0: <Control Method Lid Switch> on acpi0
cpu0: <ACPI CPU> on acpi0
acpi_throttle0: <ACPI CPU Throttling> on cpu0
acpi_throttle0: CLK_VAL field overlaps THT_EN bit
device_attach: acpi_throttle0 attach returned 6
powernow0: <PowerNow! K8> on cpu0
cpu1: <ACPI CPU> on acpi0
powernow1: <PowerNow! K8> on cpu1
orm0: <ISA Option ROM> at iomem 0xcf000-0xcffff 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
ugen1: <Formosa21 SnowflakeEmulation, class 0/0, rev 2.00/1.30, addr 2> on uhub3
ubt0: <vendor 0x0db0 product 0xa97a, class 224/1, rev 2.00/31.64, addr 3> on uhub3
ubt0: Interface 0 endpoints: interrupt=0x81, bulk-in=0x82, bulk-out=0x2
ubt0: Interface 1 (alt.config 5) endpoints: isoc-in=0x83, isoc-out=0x3; 
wMaxPacketSize=49; nframes=10, buffer size=490
Timecounters tick every 1.000 msec
firewire0: 1 nodes, maxhop <= 0, cable IRM = 0 (me)
firewire0: bus manager 0 (me)
acd0: DVDR <Optiarc DVD RW AD-7530B/NX02> at ata0-master UDMA33
ad4: 238475MB <WDC WD2500BEVS-00UST0 01.01A01> at ata2-master SATA150
hdac0: HDA Codec #0: ATI R6xx HDMI
pcm0: <HDA ATI R6xx HDMI PCM #0 Digital> at cad 0 nid 1 on hdac0
hdac1: HDA Codec #0: Realtek ALC888
hdac1: HDA Codec #1: Lucent/Agere Systems (Unknown)
pcm1: <HDA Realtek ALC888 PCM #0 Analog> at cad 0 nid 1 on hdac1
pcm2: <HDA Realtek ALC888 PCM #1 Digital> at cad 0 nid 1 on hdac1
GEOM: ad4s1: geometry does not match label (255h,63s != 16h,63s).
acd0: FAILURE - INQUIRY ILLEGAL REQUEST asc=0x24 ascq=0x00
acd0: FAILURE - INQUIRY ILLEGAL REQUEST asc=0x24 ascq=0x00
SMP: AP CPU #1 Launched!
cd0 at ata0 bus 0 target 0 lun 0
cd0: <Optiarc DVD RW AD-7530B NX02> Removable CD-ROM SCSI-0 device
cd0: 33.000MB/s transfers
cd0: Attempt to query device size failed: NOT READY, Medium not present
Trying to mount root from ufs:/dev/ad4s1a
This module (opensolaris) contains code covered by the
Common Development and Distribution License (CDDL)
see http://opensolaris.org/os/licensing/opensolaris_license/
WARNING: ZFS is considered to be an experimental feature in FreeBSD.
ZFS filesystem version 13
ZFS storage pool version 13
wlan0: Ethernet address: 00:15:af:54:f6:25
wlan0: link state changed to UP
ng_hci_process_command_timeout: ubt0hci - unable to complete HCI command 
OGF=0x1, OCF=0x5. Timeout
ubt_request_complete2: ubt0 - Control request failed. TIMEOUT (15)
acpi_ec0: wait timed out (response), forcing polled mode

###################################### "pciconf -lv" output:

hostb0@pci0:0:0:0:      class=0x060000 card=0x42cd1462 chip=0x79101002
rev=0x00 hdr=0x00
     vendor     = 'ATI Technologies Inc'
     class      = bridge
     subclass   = HOST-PCI
pcib1@pci0:0:2:0:       class=0x060400 card=0x42cd1462 chip=0x79131002
rev=0x00 hdr=0x01
     vendor     = 'ATI Technologies Inc'
     class      = bridge
     subclass   = PCI-PCI
pcib2@pci0:0:4:0:       class=0x060400 card=0x42cd1462 chip=0x79141002
rev=0x00 hdr=0x01
     vendor     = 'ATI Technologies Inc'
     class      = bridge
     subclass   = PCI-PCI
pcib3@pci0:0:6:0:       class=0x060400 card=0x42cd1462 chip=0x79161002
rev=0x00 hdr=0x01
     vendor     = 'ATI Technologies Inc'
     class      = bridge
     subclass   = PCI-PCI
pcib4@pci0:0:7:0:       class=0x060400 card=0x42cd1462 chip=0x79171002
rev=0x00 hdr=0x01
     vendor     = 'ATI Technologies Inc'
     class      = bridge
     subclass   = PCI-PCI
atapci0@pci0:0:18:0:    class=0x01018f card=0x42cd1462 chip=0x43801002
rev=0x00 hdr=0x00
     vendor     = 'ATI Technologies Inc'
     device     = 'IXP SB600 Serial ATA Controller'
     class      = mass storage
     subclass   = ATA
ohci0@pci0:0:19:0:      class=0x0c0310 card=0x42cd1462 chip=0x43871002
rev=0x00 hdr=0x00
     vendor     = 'ATI Technologies Inc'
     device     = 'IXP SB600 USB Controller (OHCI0)'
     class      = serial bus
     subclass   = USB
ohci1@pci0:0:19:1:      class=0x0c0310 card=0x42cd1462 chip=0x43881002
rev=0x00 hdr=0x00
     vendor     = 'ATI Technologies Inc'
     device     = 'IXP SB600 USB Controller (OHCI1)'
     class      = serial bus
     subclass   = USB
ohci2@pci0:0:19:2:      class=0x0c0310 card=0x42cd1462 chip=0x43891002
rev=0x00 hdr=0x00
     vendor     = 'ATI Technologies Inc'
     device     = 'IXP SB600 USB Controller (OHCI2)'
     class      = serial bus
     subclass   = USB
ohci3@pci0:0:19:3:      class=0x0c0310 card=0x42cd1462 chip=0x438a1002
rev=0x00 hdr=0x00
     vendor     = 'ATI Technologies Inc'
     device     = 'IXP SB600 USB Controller (OHCI3)'
     class      = serial bus
     subclass   = USB
ohci4@pci0:0:19:4:      class=0x0c0310 card=0x42cd1462 chip=0x438b1002
rev=0x00 hdr=0x00
     vendor     = 'ATI Technologies Inc'
     device     = 'IXP SB600 USB Controller (OHCI4)'
     class      = serial bus
     subclass   = USB
ehci0@pci0:0:19:5:      class=0x0c0320 card=0x42cd1462 chip=0x43861002
rev=0x00 hdr=0x00
     vendor     = 'ATI Technologies Inc'
     device     = 'IXP SB600 USB Controller (EHCI)'
     class      = serial bus
     subclass   = USB
none0@pci0:0:20:0:      class=0x0c0500 card=0x42cd1462 chip=0x43851002
rev=0x14 hdr=0x00
     vendor     = 'ATI Technologies Inc'
     device     = 'IXP SB600 SMBUS Controller'
     class      = serial bus
     subclass   = SMBus
atapci1@pci0:0:20:1:    class=0x01018a card=0x42cd1462 chip=0x438c1002
rev=0x00 hdr=0x00
     vendor     = 'ATI Technologies Inc'
     device     = 'IXP SB600 ATA Controller'
     class      = mass storage
     subclass   = ATA
hdac1@pci0:0:20:2:      class=0x040300 card=0x42cd1462 chip=0x43831002
rev=0x00 hdr=0x00
     vendor     = 'ATI Technologies Inc'
     device     = 'IXP SB600 High Definition Audio Controller'
     class      = multimedia
     subclass   = HDA
isab0@pci0:0:20:3:      class=0x060100 card=0x42cd1462 chip=0x438d1002
rev=0x00 hdr=0x00
     vendor     = 'ATI Technologies Inc'
     device     = 'IXP SB600 PCI to LPC Bridge'
     class      = bridge
     subclass   = PCI-ISA
pcib5@pci0:0:20:4:      class=0x060401 card=0x00000000 chip=0x43841002
rev=0x00 hdr=0x01
     vendor     = 'ATI Technologies Inc'
     device     = 'IXP SB600 PCI to PCI Bridge'
     class      = bridge
     subclass   = PCI-PCI
hostb1@pci0:0:24:0:     class=0x060000 card=0x00000000 chip=0x11001022
rev=0x00 hdr=0x00
     vendor     = 'Advanced Micro Devices (AMD)'
     device     = '(K8) Athlon 64/Opteron HyperTransport Technology Configuration'
     class      = bridge
     subclass   = HOST-PCI
hostb2@pci0:0:24:1:     class=0x060000 card=0x00000000 chip=0x11011022
rev=0x00 hdr=0x00
     vendor     = 'Advanced Micro Devices (AMD)'
     device     = '(K8) Athlon 64/Opteron Address Map'
     class      = bridge
     subclass   = HOST-PCI
hostb3@pci0:0:24:2:     class=0x060000 card=0x00000000 chip=0x11021022
rev=0x00 hdr=0x00
     vendor     = 'Advanced Micro Devices (AMD)'
     device     = '(K8) Athlon 64/Opteron DRAM Controller'
     class      = bridge
     subclass   = HOST-PCI
hostb4@pci0:0:24:3:     class=0x060000 card=0x00000000 chip=0x11031022
rev=0x00 hdr=0x00
     vendor     = 'Advanced Micro Devices (AMD)'
     device     = '(K8) Athlon 64/Opteron Miscellaneous Control'
     class      = bridge
     subclass   = HOST-PCI
vgapci0@pci0:1:0:0:     class=0x030000 card=0x42cd1462 chip=0x95811002
rev=0x00 hdr=0x00
     vendor     = 'ATI Technologies Inc'
     class      = display
     subclass   = VGA
hdac0@pci0:1:0:1:       class=0x040300 card=0xaa081462 chip=0xaa081002
rev=0x00 hdr=0x00
     vendor     = 'ATI Technologies Inc'
     class      = multimedia
     subclass   = HDA
ath0@pci0:2: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
re0@pci0:5:0:0: class=0x020000 card=0x42cd1462 chip=0x816810ec rev=0x01 hdr=0x00
     vendor     = 'Realtek Semiconductor'
     device     = 'RTL8168/8111 PCI-E Gigabit Ethernet NIC'
     class      = network
     subclass   = ethernet
cbb0@pci0:6:4:0:        class=0x060700 card=0x42cd1462 chip=0x71341217
rev=0x21 hdr=0x02
     vendor     = 'O2 Micro Inc'
     device     = 'OZ711MP1/MS1 MemoryCardBus Controller 6-in-1'
     class      = bridge
     subclass   = PCI-CardBus
none1@pci0:6:4:2:       class=0x080500 card=0x42cd1462 chip=0x71201217
rev=0x01 hdr=0x00
     vendor     = 'O2 Micro Inc'
     device     = 'Unknown device O2Micro Integrated MMC/SD controller'
     class      = base peripheral
     subclass   = SD host controller
none2@pci0:6:4:3:       class=0x068000 card=0x42cd1462 chip=0x71301217
rev=0x01 hdr=0x00
     vendor     = 'O2 Micro Inc'
     device     = 'OZ711M3 Integrated MMC/SD/MS/xD/SM Controller'
     class      = bridge
fwohci0@pci0:6:4:4:     class=0x0c0010 card=0x42cd1462 chip=0x00f71217
rev=0x02 hdr=0x00
     vendor     = 'O2 Micro Inc'
     device     = '0x00f71217 1394 Open Host Controller Interface'
     class      = serial bus
     subclass   = FireWire

From tinderbox at freebsd.org  Sun Feb  1 20:40:51 2009
From: tinderbox at freebsd.org (FreeBSD Tinderbox)
Date: Sun Feb  1 20:40:58 2009
Subject: [head tinderbox] failure on arm/arm
Message-ID: <20090202044044.482EF7302F@freebsd-current.sentex.ca>

TB --- 2009-02-02 03:40:00 - tinderbox 2.6 running on freebsd-current.sentex.ca
TB --- 2009-02-02 03:40:00 - starting HEAD tinderbox run for arm/arm
TB --- 2009-02-02 03:40:00 - cleaning the object tree
TB --- 2009-02-02 03:40:34 - cvsupping the source tree
TB --- 2009-02-02 03:40:34 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/arm/arm/supfile
TB --- 2009-02-02 03:40:44 - building world
TB --- 2009-02-02 03:40:44 - MAKEOBJDIRPREFIX=/obj
TB --- 2009-02-02 03:40:44 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2009-02-02 03:40:44 - TARGET=arm
TB --- 2009-02-02 03:40:44 - TARGET_ARCH=arm
TB --- 2009-02-02 03:40:44 - TZ=UTC
TB --- 2009-02-02 03:40:44 - __MAKE_CONF=/dev/null
TB --- 2009-02-02 03:40:44 - cd /src
TB --- 2009-02-02 03:40:44 - /usr/bin/make -B buildworld
>>> World build started on Mon Feb  2 03:40:47 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
[...]
cc -O -pipe  -I/src/usr.bin/make -DMAKE_VERSION=\"5200408120\" -DDEFSHELLNAME=\"sh\" -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wno-pointer-sign -c /src/usr.bin/make/for.c
cc -O -pipe  -I/src/usr.bin/make -DMAKE_VERSION=\"5200408120\" -DDEFSHELLNAME=\"sh\" -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wno-pointer-sign -c /src/usr.bin/make/hash.c
cc -O -pipe  -I/src/usr.bin/make -DMAKE_VERSION=\"5200408120\" -DDEFSHELLNAME=\"sh\" -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wno-pointer-sign -c /src/usr.bin/make/hash_tables.c
cc -O -pipe  -I/src/usr.bin/make -DMAKE_VERSION=\"5200408120\" -DDEFSHELLNAME=\"sh\" -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wno-pointer-sign -c /src/usr.bin/make/job.c
cc -O -pipe  -I/src/usr.bin/make -DMAKE_VERSION=\"5200408120\" -DDEFSHELLNAME=\"sh\" -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wno-pointer-sign -c /src/usr.bin/make/lst.c
cc -O -pipe  -I/src/usr.bin/make -DMAKE_VERSION=\"5200408120\" -DDEFSHELLNAME=\"sh\" -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wno-pointer-sign -c /src/usr.bin/make/main.c
/src/usr.bin/make/main.c:375:1: error: "OPTFLAGS" redefined
/src/usr.bin/make/main.c:374:1: error: this is the location of the previous definition
*** Error code 1

Stop in /src/usr.bin/make.
*** Error code 1

Stop in /src/usr.bin.
*** Error code 1

Stop in /src.
*** Error code 1

Stop in /src.
*** Error code 1

Stop in /src.
TB --- 2009-02-02 04:40:44 - WARNING: /usr/bin/make returned exit code  1 
TB --- 2009-02-02 04:40:44 - ERROR: failed to build world
TB --- 2009-02-02 04:40:44 - 2834.77 user 344.06 system 3643.30 real


http://tinderbox.des.no/tinderbox-head-HEAD-arm-arm.full
From sam at freebsd.org  Sun Feb  1 20:41:15 2009
From: sam at freebsd.org (Sam Leffler)
Date: Sun Feb  1 20:41:23 2009
Subject: ath driver (?) lock system after last update
In-Reply-To: <498652D2.7030906@mail.ru>
References: <498652D2.7030906@mail.ru>
Message-ID: <49867969.3020406@freebsd.org>

Subscriber wrote:
> I updated my 8-CURRENT and now system freeze shortly after boot (~0.5-3
> minutes). I see following messages in console:
>
> Jan 31 02:18:03 cache kernel: ath0: bad series0 hwrate 0x0, tries 4 
> ts_status 0x0
> Jan 31 02:18:03 cache kernel: ath0: bad series1 hwrate 0x0, tries 3 
> ts_status 0x0
> Jan 31 02:18:03 cache kernel: ath0: bad series2 hwrate 0x0, tries 4 
> ts_status 0x0
> Jan 31 02:18:03 cache kernel: ath0: bad series0 hwrate 0x0, tries 4 
> ts_status 0x0
> Jan 31 02:18:03 cache kernel: ath0: bad series1 hwrate 0x0, tries 3 
> ts_status 0x0
> Jan 31 02:18:03 cache kernel: ath0: bad series2 hwrate 0x0, tries 4 
> ts_status 0x0
> Jan 31 02:18:03 cache kernel: ath0: bad series0 hwrate 0x0, tries 4 
> ts_status 0x0
> Jan 31 02:18:03 cache kernel: ath0: bad series1 hwrate 0x0, tries 3 
> ts_status 0x0
> Jan 31 02:18:03 cache kernel: ath0: bad series2 hwrate 0x0, tries 4 
> ts_status 0x0
> ...
>
> much time, then system freeze. Before last update I was never see 
> those messages.
> Now I rolled back to HEAD sources with date=2009.01.01, and all seems OK.


> ath0: <Atheros 5424/2424> mem 0xfd7f0000-0xfd7fffff irq 16 at device 
> 0.0 on pci2
> ath0: [ITHREAD]
> ath0: WARNING: using obsoleted if_watchdog interface
> ath0: mac 14.2 phy 7.0 radio 10.2

I need to see the output of sysctl dev.ath.0 and how your card is 
configured.

    Sam

From tinderbox at freebsd.org  Sun Feb  1 20:57:14 2009
From: tinderbox at freebsd.org (FreeBSD Tinderbox)
Date: Sun Feb  1 20:57:37 2009
Subject: [head tinderbox] failure on amd64/amd64
Message-ID: <20090202045711.237847302F@freebsd-current.sentex.ca>

TB --- 2009-02-02 03:40:00 - tinderbox 2.6 running on freebsd-current.sentex.ca
TB --- 2009-02-02 03:40:00 - starting HEAD tinderbox run for amd64/amd64
TB --- 2009-02-02 03:40:00 - cleaning the object tree
TB --- 2009-02-02 03:40:57 - cvsupping the source tree
TB --- 2009-02-02 03:40:57 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/amd64/amd64/supfile
TB --- 2009-02-02 03:41:04 - building world
TB --- 2009-02-02 03:41:04 - MAKEOBJDIRPREFIX=/obj
TB --- 2009-02-02 03:41:04 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2009-02-02 03:41:04 - TARGET=amd64
TB --- 2009-02-02 03:41:04 - TARGET_ARCH=amd64
TB --- 2009-02-02 03:41:04 - TZ=UTC
TB --- 2009-02-02 03:41:04 - __MAKE_CONF=/dev/null
TB --- 2009-02-02 03:41:04 - cd /src
TB --- 2009-02-02 03:41:04 - /usr/bin/make -B buildworld
>>> World build started on Mon Feb  2 03:41:07 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
[...]
cc -O2 -pipe  -I/src/usr.bin/make -DMAKE_VERSION=\"5200408120\" -DDEFSHELLNAME=\"sh\" -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wno-pointer-sign -c /src/usr.bin/make/for.c
cc -O2 -pipe  -I/src/usr.bin/make -DMAKE_VERSION=\"5200408120\" -DDEFSHELLNAME=\"sh\" -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wno-pointer-sign -c /src/usr.bin/make/hash.c
cc -O2 -pipe  -I/src/usr.bin/make -DMAKE_VERSION=\"5200408120\" -DDEFSHELLNAME=\"sh\" -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wno-pointer-sign -c /src/usr.bin/make/hash_tables.c
cc -O2 -pipe  -I/src/usr.bin/make -DMAKE_VERSION=\"5200408120\" -DDEFSHELLNAME=\"sh\" -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wno-pointer-sign -c /src/usr.bin/make/job.c
cc -O2 -pipe  -I/src/usr.bin/make -DMAKE_VERSION=\"5200408120\" -DDEFSHELLNAME=\"sh\" -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wno-pointer-sign -c /src/usr.bin/make/lst.c
cc -O2 -pipe  -I/src/usr.bin/make -DMAKE_VERSION=\"5200408120\" -DDEFSHELLNAME=\"sh\" -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wno-pointer-sign -c /src/usr.bin/make/main.c
/src/usr.bin/make/main.c:375:1: error: "OPTFLAGS" redefined
/src/usr.bin/make/main.c:374:1: error: this is the location of the previous definition
*** Error code 1

Stop in /src/usr.bin/make.
*** Error code 1

Stop in /src/usr.bin.
*** Error code 1

Stop in /src.
*** Error code 1

Stop in /src.
*** Error code 1

Stop in /src.
TB --- 2009-02-02 04:57:11 - WARNING: /usr/bin/make returned exit code  1 
TB --- 2009-02-02 04:57:11 - ERROR: failed to build world
TB --- 2009-02-02 04:57:11 - 3590.66 user 355.06 system 4630.34 real


http://tinderbox.des.no/tinderbox-head-HEAD-amd64-amd64.full
From drosih at rpi.edu  Sun Feb  1 21:28:50 2009
From: drosih at rpi.edu (Garance A Drosihn)
Date: Sun Feb  1 21:28:58 2009
Subject: Alternatives to gcc (was Re: gcc 4.3: when will it 
 becomestandard compiler?)
In-Reply-To: <87223.61659.qm@web32707.mail.mud.yahoo.com>
References: <87223.61659.qm@web32707.mail.mud.yahoo.com>
Message-ID: <p06240803c5ac33499e88@[128.113.24.47]>

At 3:22 PM -0800 1/31/09, Pedro F. Giffuni wrote:
>--- On Sat, 1/31/09, Mark Linimon <linimon@lonesome.com> wrote:
>
>On Sat, Jan 31, 2009 at 01:08:54PM -0800, Pedro F. Giffuni wrote:
>  > > The effort didn't go far enough. Why haven't we removed GNU
>  > > readline ?
>  >
>  > Probably either because someone hasn't written a BSD-licensed
>  > one, or someone hasn't done the work to test-compile src and
>  > ports on all the appropriate architectures.
>
>Wrong on both:
>
>- libedit has a readline compatibility mode that has replaced
>   GNU readline in the other BSDs.

One minor datapoint:  I use readline in some program that is used
by several people on several platforms.  One of those users was on
MacOS 10 (iirc), and used the libedit which was on that platform.
While it could be made compile-time compatible with readline, it
wasn't a completely adequate replacement for this program of ours.

The guy who tried this said it was because our program takes
advantage of knowing some of the internals of what readline is
doing, so it can implement a few extra features.  Now, that can
easily be said to be "the fault" of our program, but who's to say
that other programs don't do the same thing?  As such, libedit is
not necessarily a drop-in replacement for libreadline.  Someone
would have to do the legwork, and certainly I don't feel like
doing that legwork.  I don't even feel like fixing that one program
of my own.

-- 
Garance Alistair Drosehn            =   gad@gilead.netel.rpi.edu
Senior Systems Programmer           or  gad@freebsd.org
Rensselaer Polytechnic Institute    or  drosih@rpi.edu
From tinderbox at freebsd.org  Sun Feb  1 21:54:57 2009
From: tinderbox at freebsd.org (FreeBSD Tinderbox)
Date: Sun Feb  1 21:55:17 2009
Subject: [head tinderbox] failure on i386/i386
Message-ID: <20090202055454.49E797302F@freebsd-current.sentex.ca>

TB --- 2009-02-02 04:40:44 - tinderbox 2.6 running on freebsd-current.sentex.ca
TB --- 2009-02-02 04:40:44 - starting HEAD tinderbox run for i386/i386
TB --- 2009-02-02 04:40:44 - cleaning the object tree
TB --- 2009-02-02 04:41:18 - cvsupping the source tree
TB --- 2009-02-02 04:41:18 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/i386/i386/supfile
TB --- 2009-02-02 04:41:28 - building world
TB --- 2009-02-02 04:41:28 - MAKEOBJDIRPREFIX=/obj
TB --- 2009-02-02 04:41:28 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2009-02-02 04:41:28 - TARGET=i386
TB --- 2009-02-02 04:41:28 - TARGET_ARCH=i386
TB --- 2009-02-02 04:41:28 - TZ=UTC
TB --- 2009-02-02 04:41:28 - __MAKE_CONF=/dev/null
TB --- 2009-02-02 04:41:28 - cd /src
TB --- 2009-02-02 04:41:28 - /usr/bin/make -B buildworld
>>> World build started on Mon Feb  2 04:41:30 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
[...]
cc -O2 -pipe  -I/src/usr.bin/make -DMAKE_VERSION=\"5200408120\" -DDEFSHELLNAME=\"sh\" -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wno-pointer-sign -c /src/usr.bin/make/for.c
cc -O2 -pipe  -I/src/usr.bin/make -DMAKE_VERSION=\"5200408120\" -DDEFSHELLNAME=\"sh\" -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wno-pointer-sign -c /src/usr.bin/make/hash.c
cc -O2 -pipe  -I/src/usr.bin/make -DMAKE_VERSION=\"5200408120\" -DDEFSHELLNAME=\"sh\" -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wno-pointer-sign -c /src/usr.bin/make/hash_tables.c
cc -O2 -pipe  -I/src/usr.bin/make -DMAKE_VERSION=\"5200408120\" -DDEFSHELLNAME=\"sh\" -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wno-pointer-sign -c /src/usr.bin/make/job.c
cc -O2 -pipe  -I/src/usr.bin/make -DMAKE_VERSION=\"5200408120\" -DDEFSHELLNAME=\"sh\" -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wno-pointer-sign -c /src/usr.bin/make/lst.c
cc -O2 -pipe  -I/src/usr.bin/make -DMAKE_VERSION=\"5200408120\" -DDEFSHELLNAME=\"sh\" -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wno-pointer-sign -c /src/usr.bin/make/main.c
/src/usr.bin/make/main.c:375:1: error: "OPTFLAGS" redefined
/src/usr.bin/make/main.c:374:1: error: this is the location of the previous definition
*** Error code 1

Stop in /src/usr.bin/make.
*** Error code 1

Stop in /src/usr.bin.
*** Error code 1

Stop in /src.
*** Error code 1

Stop in /src.
*** Error code 1

Stop in /src.
TB --- 2009-02-02 05:54:54 - WARNING: /usr/bin/make returned exit code  1 
TB --- 2009-02-02 05:54:54 - ERROR: failed to build world
TB --- 2009-02-02 05:54:54 - 3529.71 user 336.48 system 4449.73 real


http://tinderbox.des.no/tinderbox-head-HEAD-i386-i386.full
From tinderbox at freebsd.org  Sun Feb  1 22:10:35 2009
From: tinderbox at freebsd.org (FreeBSD Tinderbox)
Date: Sun Feb  1 22:10:41 2009
Subject: [head tinderbox] failure on i386/pc98
Message-ID: <20090202061031.6C12A7302F@freebsd-current.sentex.ca>

TB --- 2009-02-02 04:57:11 - tinderbox 2.6 running on freebsd-current.sentex.ca
TB --- 2009-02-02 04:57:11 - starting HEAD tinderbox run for i386/pc98
TB --- 2009-02-02 04:57:11 - cleaning the object tree
TB --- 2009-02-02 04:57:40 - cvsupping the source tree
TB --- 2009-02-02 04:57:40 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/i386/pc98/supfile
TB --- 2009-02-02 04:57:50 - building world
TB --- 2009-02-02 04:57:50 - MAKEOBJDIRPREFIX=/obj
TB --- 2009-02-02 04:57:50 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2009-02-02 04:57:50 - TARGET=pc98
TB --- 2009-02-02 04:57:50 - TARGET_ARCH=i386
TB --- 2009-02-02 04:57:50 - TZ=UTC
TB --- 2009-02-02 04:57:50 - __MAKE_CONF=/dev/null
TB --- 2009-02-02 04:57:50 - cd /src
TB --- 2009-02-02 04:57:50 - /usr/bin/make -B buildworld
>>> World build started on Mon Feb  2 04:57:52 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
[...]
cc -O2 -pipe  -I/src/usr.bin/make -DMAKE_VERSION=\"5200408120\" -DDEFSHELLNAME=\"sh\" -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wno-pointer-sign -c /src/usr.bin/make/for.c
cc -O2 -pipe  -I/src/usr.bin/make -DMAKE_VERSION=\"5200408120\" -DDEFSHELLNAME=\"sh\" -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wno-pointer-sign -c /src/usr.bin/make/hash.c
cc -O2 -pipe  -I/src/usr.bin/make -DMAKE_VERSION=\"5200408120\" -DDEFSHELLNAME=\"sh\" -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wno-pointer-sign -c /src/usr.bin/make/hash_tables.c
cc -O2 -pipe  -I/src/usr.bin/make -DMAKE_VERSION=\"5200408120\" -DDEFSHELLNAME=\"sh\" -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wno-pointer-sign -c /src/usr.bin/make/job.c
cc -O2 -pipe  -I/src/usr.bin/make -DMAKE_VERSION=\"5200408120\" -DDEFSHELLNAME=\"sh\" -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wno-pointer-sign -c /src/usr.bin/make/lst.c
cc -O2 -pipe  -I/src/usr.bin/make -DMAKE_VERSION=\"5200408120\" -DDEFSHELLNAME=\"sh\" -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wno-pointer-sign -c /src/usr.bin/make/main.c
/src/usr.bin/make/main.c:375:1: error: "OPTFLAGS" redefined
/src/usr.bin/make/main.c:374:1: error: this is the location of the previous definition
*** Error code 1

Stop in /src/usr.bin/make.
*** Error code 1

Stop in /src/usr.bin.
*** Error code 1

Stop in /src.
*** Error code 1

Stop in /src.
*** Error code 1

Stop in /src.
TB --- 2009-02-02 06:10:31 - WARNING: /usr/bin/make returned exit code  1 
TB --- 2009-02-02 06:10:31 - ERROR: failed to build world
TB --- 2009-02-02 06:10:31 - 3519.40 user 352.95 system 4400.12 real


http://tinderbox.des.no/tinderbox-head-HEAD-i386-pc98.full
From tinderbox at freebsd.org  Sun Feb  1 23:26:07 2009
From: tinderbox at freebsd.org (FreeBSD Tinderbox)
Date: Sun Feb  1 23:26:14 2009
Subject: [head tinderbox] failure on powerpc/powerpc
Message-ID: <20090202072603.C07F37302F@freebsd-current.sentex.ca>

TB --- 2009-02-02 06:10:31 - tinderbox 2.6 running on freebsd-current.sentex.ca
TB --- 2009-02-02 06:10:31 - starting HEAD tinderbox run for powerpc/powerpc
TB --- 2009-02-02 06:10:31 - cleaning the object tree
TB --- 2009-02-02 06:11:04 - cvsupping the source tree
TB --- 2009-02-02 06:11:04 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/powerpc/powerpc/supfile
TB --- 2009-02-02 06:11:12 - building world
TB --- 2009-02-02 06:11:12 - MAKEOBJDIRPREFIX=/obj
TB --- 2009-02-02 06:11:12 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2009-02-02 06:11:12 - TARGET=powerpc
TB --- 2009-02-02 06:11:12 - TARGET_ARCH=powerpc
TB --- 2009-02-02 06:11:12 - TZ=UTC
TB --- 2009-02-02 06:11:12 - __MAKE_CONF=/dev/null
TB --- 2009-02-02 06:11:12 - cd /src
TB --- 2009-02-02 06:11:12 - /usr/bin/make -B buildworld
>>> World build started on Mon Feb  2 06:11:13 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
[...]
cc -O2 -pipe  -I/src/usr.bin/make -DMAKE_VERSION=\"5200408120\" -DDEFSHELLNAME=\"sh\" -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wno-pointer-sign -c /src/usr.bin/make/for.c
cc -O2 -pipe  -I/src/usr.bin/make -DMAKE_VERSION=\"5200408120\" -DDEFSHELLNAME=\"sh\" -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wno-pointer-sign -c /src/usr.bin/make/hash.c
cc -O2 -pipe  -I/src/usr.bin/make -DMAKE_VERSION=\"5200408120\" -DDEFSHELLNAME=\"sh\" -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wno-pointer-sign -c /src/usr.bin/make/hash_tables.c
cc -O2 -pipe  -I/src/usr.bin/make -DMAKE_VERSION=\"5200408120\" -DDEFSHELLNAME=\"sh\" -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wno-pointer-sign -c /src/usr.bin/make/job.c
cc -O2 -pipe  -I/src/usr.bin/make -DMAKE_VERSION=\"5200408120\" -DDEFSHELLNAME=\"sh\" -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wno-pointer-sign -c /src/usr.bin/make/lst.c
cc -O2 -pipe  -I/src/usr.bin/make -DMAKE_VERSION=\"5200408120\" -DDEFSHELLNAME=\"sh\" -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wno-pointer-sign -c /src/usr.bin/make/main.c
/src/usr.bin/make/main.c:375:1: error: "OPTFLAGS" redefined
/src/usr.bin/make/main.c:374:1: error: this is the location of the previous definition
*** Error code 1

Stop in /src/usr.bin/make.
*** Error code 1

Stop in /src/usr.bin.
*** Error code 1

Stop in /src.
*** Error code 1

Stop in /src.
*** Error code 1

Stop in /src.
TB --- 2009-02-02 07:26:02 - WARNING: /usr/bin/make returned exit code  1 
TB --- 2009-02-02 07:26:02 - ERROR: failed to build world
TB --- 2009-02-02 07:26:02 - 3666.84 user 334.37 system 4530.73 real


http://tinderbox.des.no/tinderbox-head-HEAD-powerpc-powerpc.full
From tinderbox at freebsd.org  Sun Feb  1 23:28:47 2009
From: tinderbox at freebsd.org (FreeBSD Tinderbox)
Date: Sun Feb  1 23:29:05 2009
Subject: [head tinderbox] failure on ia64/ia64
Message-ID: <20090202072844.A3EC87302F@freebsd-current.sentex.ca>

TB --- 2009-02-02 05:54:54 - tinderbox 2.6 running on freebsd-current.sentex.ca
TB --- 2009-02-02 05:54:54 - starting HEAD tinderbox run for ia64/ia64
TB --- 2009-02-02 05:54:54 - cleaning the object tree
TB --- 2009-02-02 05:55:34 - cvsupping the source tree
TB --- 2009-02-02 05:55:34 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/ia64/ia64/supfile
TB --- 2009-02-02 05:55:43 - building world
TB --- 2009-02-02 05:55:43 - MAKEOBJDIRPREFIX=/obj
TB --- 2009-02-02 05:55:43 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2009-02-02 05:55:43 - TARGET=ia64
TB --- 2009-02-02 05:55:43 - TARGET_ARCH=ia64
TB --- 2009-02-02 05:55:43 - TZ=UTC
TB --- 2009-02-02 05:55:43 - __MAKE_CONF=/dev/null
TB --- 2009-02-02 05:55:43 - cd /src
TB --- 2009-02-02 05:55:43 - /usr/bin/make -B buildworld
>>> World build started on Mon Feb  2 05:55:45 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
[...]
cc -O2 -pipe  -I/src/usr.bin/make -DMAKE_VERSION=\"5200408120\" -DDEFSHELLNAME=\"sh\" -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wno-pointer-sign -c /src/usr.bin/make/for.c
cc -O2 -pipe  -I/src/usr.bin/make -DMAKE_VERSION=\"5200408120\" -DDEFSHELLNAME=\"sh\" -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wno-pointer-sign -c /src/usr.bin/make/hash.c
cc -O2 -pipe  -I/src/usr.bin/make -DMAKE_VERSION=\"5200408120\" -DDEFSHELLNAME=\"sh\" -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wno-pointer-sign -c /src/usr.bin/make/hash_tables.c
cc -O2 -pipe  -I/src/usr.bin/make -DMAKE_VERSION=\"5200408120\" -DDEFSHELLNAME=\"sh\" -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wno-pointer-sign -c /src/usr.bin/make/job.c
cc -O2 -pipe  -I/src/usr.bin/make -DMAKE_VERSION=\"5200408120\" -DDEFSHELLNAME=\"sh\" -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wno-pointer-sign -c /src/usr.bin/make/lst.c
cc -O2 -pipe  -I/src/usr.bin/make -DMAKE_VERSION=\"5200408120\" -DDEFSHELLNAME=\"sh\" -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wno-pointer-sign -c /src/usr.bin/make/main.c
/src/usr.bin/make/main.c:375:1: error: "OPTFLAGS" redefined
/src/usr.bin/make/main.c:374:1: error: this is the location of the previous definition
*** Error code 1

Stop in /src/usr.bin/make.
*** Error code 1

Stop in /src/usr.bin.
*** Error code 1

Stop in /src.
*** Error code 1

Stop in /src.
*** Error code 1

Stop in /src.
TB --- 2009-02-02 07:28:44 - WARNING: /usr/bin/make returned exit code  1 
TB --- 2009-02-02 07:28:44 - ERROR: failed to build world
TB --- 2009-02-02 07:28:44 - 4672.14 user 351.03 system 5630.22 real


http://tinderbox.des.no/tinderbox-head-HEAD-ia64-ia64.full
From yanefbsd at gmail.com  Mon Feb  2 00:20:19 2009
From: yanefbsd at gmail.com (Garrett Cooper)
Date: Mon Feb  2 00:20:26 2009
Subject: Alternatives to gcc (was Re: gcc 4.3: when will it
	becomestandard compiler?)
In-Reply-To: <p06240803c5ac33499e88@128.113.24.47>
References: <87223.61659.qm@web32707.mail.mud.yahoo.com>
	<p06240803c5ac33499e88@128.113.24.47>
Message-ID: <7d6fde3d0902020020n3d5aac5cu4f3381a195d6fdcf@mail.gmail.com>

On Sun, Feb 1, 2009 at 9:28 PM, Garance A Drosihn <drosih@rpi.edu> wrote:
> At 3:22 PM -0800 1/31/09, Pedro F. Giffuni wrote:
>>
>> --- On Sat, 1/31/09, Mark Linimon <linimon@lonesome.com> wrote:
>>
>> On Sat, Jan 31, 2009 at 01:08:54PM -0800, Pedro F. Giffuni wrote:
>>  > > The effort didn't go far enough. Why haven't we removed GNU
>>  > > readline ?
>>  >
>>  > Probably either because someone hasn't written a BSD-licensed
>>  > one, or someone hasn't done the work to test-compile src and
>>  > ports on all the appropriate architectures.
>>
>> Wrong on both:
>>
>> - libedit has a readline compatibility mode that has replaced
>>  GNU readline in the other BSDs.
>
> One minor datapoint:  I use readline in some program that is used
> by several people on several platforms.  One of those users was on
> MacOS 10 (iirc), and used the libedit which was on that platform.
> While it could be made compile-time compatible with readline, it
> wasn't a completely adequate replacement for this program of ours.
>
> The guy who tried this said it was because our program takes
> advantage of knowing some of the internals of what readline is
> doing, so it can implement a few extra features.  Now, that can
> easily be said to be "the fault" of our program, but who's to say
> that other programs don't do the same thing?  As such, libedit is
> not necessarily a drop-in replacement for libreadline.  Someone
> would have to do the legwork, and certainly I don't feel like
> doing that legwork.  I don't even feel like fixing that one program
> of my own.

It's *mostly* feature complete. The only thing that's really missing
is libhistory, which is required for some things like python's
readline support. Other programs like MySQL happily used libedit
embedded into their source without issues.

It all depends on what features people choose to use in GNU's readline
that makes it compatible or not with libedit.

-Garrett
From ralph at imada.sdu.dk  Mon Feb  2 00:30:59 2009
From: ralph at imada.sdu.dk (Ralph Zitz)
Date: Mon Feb  2 00:31:08 2009
Subject: patch r187693 breaks HAL on amd64-current
In-Reply-To: <498607D7.7090507@videotron.ca>
References: <4985FA10.5080604@imada.sdu.dk> <498607D7.7090507@videotron.ca>
Message-ID: <20137.80.160.75.130.1233563452.squirrel@test.imada.sdu.dk>

Thanks!

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Ralph Zitz wrote:
>> I'm not a HAL expert, but it seems that the patch makes HAL create a
>> zombie process when watching /dev/cd0. Reversing the patch makes HAL
>> work again.
>>
>> Link to patch message:
>> http://lists.freebsd.org/pipermail/svn-src-all/2009-January/004073.html
>>
> Hi Ralph
>
> Try the following patch, it should fix your problem with hal.
>
> Regards
>
> Steph
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.10 (FreeBSD)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iEYEARECAAYFAkmGB9YACgkQmdOXtTCX/nt8tACgj5IzDaHDEsKIJbZPefOwzkiW
> Ne4AoMV4GzfMLeVeBAWIRbmG08R7Lpj3
> =K7Cu
> -----END PGP SIGNATURE-----
> Index: kern/sys_generic.c
> ===================================================================
> --- kern/sys_generic.c	(revision 187983)
> +++ kern/sys_generic.c	(working copy)
> @@ -903,7 +903,7 @@
>   * bit position in the fd_mask array.
>   */
>  static __inline int
> -selflags(fd_mask **ibits, int idx, int bit)
> +selflags(fd_mask **ibits, int idx, fd_mask bit)
>  {
>  	int flags;
>  	int msk;
> @@ -912,7 +912,7 @@
>  	for (msk = 0; msk < 3; msk++) {
>  		if (ibits[msk] == NULL)
>  			continue;
> -		if ((ibits[msk][idx] & (fd_mask)bit) == 0)
> +		if ((ibits[msk][idx] & bit) == 0)
>  			continue;
>  		flags |= select_flags[msk];
>  	}
>

From drosih at rpi.edu  Mon Feb  2 00:56:50 2009
From: drosih at rpi.edu (Garance A Drosihn)
Date: Mon Feb  2 00:56:56 2009
Subject: Alternatives to gcc (was Re: gcc 4.3: when will it
 becomestandard  	compiler?)
In-Reply-To: <7d6fde3d0902020020n3d5aac5cu4f3381a195d6fdcf@mail.gmail.com>
References: <87223.61659.qm@web32707.mail.mud.yahoo.com>	
	<p06240803c5ac33499e88@128.113.24.47>
	<7d6fde3d0902020020n3d5aac5cu4f3381a195d6fdcf@mail.gmail.com>
Message-ID: <p06240804c5ac650b47be@[128.113.24.47]>

At 12:20 AM -0800 2/2/09, Garrett Cooper wrote:
>On Sun, Feb 1, 2009, Garance A Drosihn <drosih@rpi.edu> wrote:
>  > While it could be made compile-time compatible with readline, it
>>  wasn't a completely adequate replacement for this program of ours.
>>
>>  The guy who tried this said it was because our program takes
>>  advantage of knowing some of the internals of what readline is
>  > doing, so it can implement a few extra features.

>It's *mostly* feature complete. The only thing that's really missing
>is libhistory, which is required for some things like python's
>readline support. Other programs like MySQL happily used libedit
>embedded into their source without issues.

Well, our program does include history, so that's probably where
we ran into trouble with libedit.  (I should add that I really do
mean to fix the program so libedit can be used as an option, it's
just that I've got too many other projects ahead of it in my list
of projects to-do).

-- 
Garance Alistair Drosehn            =   gad@gilead.netel.rpi.edu
Senior Systems Programmer           or  gad@freebsd.org
Rensselaer Polytechnic Institute    or  drosih@rpi.edu
From admin at lissyara.su  Mon Feb  2 01:19:33 2009
From: admin at lissyara.su (Alex Keda)
Date: Mon Feb  2 01:19:40 2009
Subject: powernow0: set freq failed, err 6
In-Reply-To: <E1LTjO0-000OdA-00.need4spam-bk-ru@f59.mail.ru>
References: <E1LTjO0-000OdA-00.need4spam-bk-ru@f59.mail.ru>
Message-ID: <4986BAA3.4010505@lissyara.su>

Alexey Ivanov ?????:
> I have repeating errors in /var/log/messages 
>
> [PH34R] ~> tail -f /var/log/messages
> Feb  1 23:34:34 PH34R kernel: powernow0: set freq failed, err 6
> Feb  1 23:34:34 PH34R kernel: powernow1: set freq failed, err 6
> Feb  1 23:34:34 PH34R kernel: powernow0: set freq failed, err 6
> Feb  1 23:34:34 PH34R kernel: powernow1: set freq failed, err 6
> Feb  1 23:34:34 PH34R kernel: powernow0: set freq failed, err 6
> Feb  1 23:34:41 PH34R last message repeated 17 times
>
> Now freq on my notebook is cut by about a half
> dev.cpu.0.freq: 1194
>
> I don't know is it connected, but it first strted when i installed linux 2.6.28 and rebooted from it.
>
> Similiar problem here
>    http://lists.freebsd.org/pipermail/freebsd-current/2008-December/001401.html
> as i know Keda is using same hardware: notebook HP 6715s
 From another machine:
lissyara# sysctl dev.cpu.0.freq_levels
dev.cpu.0.freq_levels: 2786/103000 2587/88689 2388/75690 2189/63943 
1990/53387 1791/48048 1567/42042 1343/36036 1119/30030 995/24422 
870/21369 746/18316 621/15263 497/12211 373/9158 248/6105 124/3052
lissyara# sysctl dev.cpu.0.freq
dev.cpu.0.freq: 1343
lissyara# sysctl dev.cpu.0.freq=2786
dev.cpu.0.freq: 1343
sysctl: dev.cpu.0.freq: Device not configured
lissyara# uname -a
FreeBSD lissyara.moskb.local 8.0-CURRENT FreeBSD 8.0-CURRENT #0: Fri Jan 
23 19:14:54 MSK 2009     
lissyara@lissyara.moskb.local:/usr/obj/mnt/jabber/DISTR/FreeBSD/src/CURRENT/sys/USB2  
amd64
lissyara#   
===============
1343 MHz - set by powerd, after start. but, after 3-5 seconds work, I 
have in log

powernow0: set freq failed, err 6
powernow1: set freq failed, err 6
powernow0: set freq failed, err 6
powernow1: set freq failed, err 6
powernow0: set freq failed, err 6

And cannot change frequency

From bunke at hbxt.org  Mon Feb  2 01:36:54 2009
From: bunke at hbxt.org (Hendrik Bunke)
Date: Mon Feb  2 01:37:01 2009
Subject: SATA drive device moving on 8.0 current
In-Reply-To: <20090201171938.H97967@ury.york.ac.uk>
References: <20490.74948.qm@web63901.mail.re1.yahoo.com>
	<20090201171938.H97967@ury.york.ac.uk>
Message-ID: <alpine.BSF.2.00.0902021008160.22208@sisko.hbxt.de>

--On Sun, 1 Feb 2009 17:22, Gavin Atkinson wrote:

> On Wed, 28 Jan 2009, Barney Cordoba wrote:
> 
> > I booted 8.0-current on a machine that was running 7 and the SATA drive
> > came up as ad4 instead of ad8 (as it is detected in 7). This is the case
> > was loading GENERIC.
> > 
> > This is going to present a serious problem doing field upgrades as its
> > expected that fstab will be the same. What is the reason for the change and
> > is there any way to make it compatible with device detection in 7?
> 
> I suspect the problem is caused by some changes made in -CURRENT a few months
> ago, which had the potential to change the order that some devices may be
> detected.

I've had the same problem recently after upgrading from
7.1-RELEASE to -stable. The only difference being obvious to me
was the modified driver for the Intel ICH10 SATA controller. 

regards
hendrik

-- 
Dr. Hendrik Bunke
blog: http://hbxt.org/
com:  http://hbxt.de/
From subscr1024 at mail.ru  Mon Feb  2 03:19:14 2009
From: subscr1024 at mail.ru (Subscriber)
Date: Mon Feb  2 03:19:31 2009
Subject: ath driver (?) lock system after last update
In-Reply-To: <49867969.3020406@freebsd.org>
References: <498652D2.7030906@mail.ru> <49867969.3020406@freebsd.org>
Message-ID: <4986D59A.9080906@mail.ru>

Output of 'sysctl dev.ath':

dev.ath.0.%desc: Atheros 5424/2424
dev.ath.0.%driver: ath
dev.ath.0.%location: slot=0 function=0
dev.ath.0.%pnpinfo: vendor=0x168c device=0x001c subvendor=0x1a3b 
subdevice=0x1026 class=0x020000
dev.ath.0.%parent: pci2
dev.ath.0.smoothing_rate: 95
dev.ath.0.sample_rate: 10
dev.ath.0.sample_stats: 0
dev.ath.0.countrycode: 0
dev.ath.0.regdomain: 96
dev.ath.0.slottime: 20
dev.ath.0.acktimeout: 48
dev.ath.0.ctstimeout: 48
dev.ath.0.softled: 0
dev.ath.0.ledpin: 0
dev.ath.0.ledon: 0
dev.ath.0.ledidle: 2700
dev.ath.0.txantenna: 0
dev.ath.0.rxantenna: 2
dev.ath.0.diversity: 1
dev.ath.0.txintrperiod: 5
dev.ath.0.diag: 0
dev.ath.0.tpscale: 0
dev.ath.0.tpc: 0
dev.ath.0.tpack: 63
dev.ath.0.tpcts: 63
dev.ath.0.rfsilent: 1
dev.ath.0.rfkill: 1
dev.ath.0.intmit: 1
dev.ath.0.monpass: 24

I not changed sysctl setting for ath0 because of fine forking with default 
settings on early drivers.

 > and how your card is configured.
What it means? Wireless network related rc.conf settings?
if_up_delay="1"
wlans_ath0=wlan0
ifconfig_wlan0="WPA DHCP"

I use FreeBSD 7.1 box with Atheros wi-fi card (don't remember exact model, can 
see later if it need) as wireless AP (bridge).


Sam Leffler ?????:
> Subscriber wrote:
>> I updated my 8-CURRENT and now system freeze shortly after boot (~0.5-3
>> minutes). I see following messages in console:
>>
>> Jan 31 02:18:03 cache kernel: ath0: bad series0 hwrate 0x0, tries 4 
>> ts_status 0x0
>> Jan 31 02:18:03 cache kernel: ath0: bad series1 hwrate 0x0, tries 3 
>> ts_status 0x0
>> Jan 31 02:18:03 cache kernel: ath0: bad series2 hwrate 0x0, tries 4 
>> ts_status 0x0
>> Jan 31 02:18:03 cache kernel: ath0: bad series0 hwrate 0x0, tries 4 
>> ts_status 0x0
>> Jan 31 02:18:03 cache kernel: ath0: bad series1 hwrate 0x0, tries 3 
>> ts_status 0x0
>> Jan 31 02:18:03 cache kernel: ath0: bad series2 hwrate 0x0, tries 4 
>> ts_status 0x0
>> Jan 31 02:18:03 cache kernel: ath0: bad series0 hwrate 0x0, tries 4 
>> ts_status 0x0
>> Jan 31 02:18:03 cache kernel: ath0: bad series1 hwrate 0x0, tries 3 
>> ts_status 0x0
>> Jan 31 02:18:03 cache kernel: ath0: bad series2 hwrate 0x0, tries 4 
>> ts_status 0x0
>> ...
>>
>> much time, then system freeze. Before last update I was never see 
>> those messages.
>> Now I rolled back to HEAD sources with date=2009.01.01, and all seems OK.
> 
> 
>> ath0: <Atheros 5424/2424> mem 0xfd7f0000-0xfd7fffff irq 16 at device 
>> 0.0 on pci2
>> ath0: [ITHREAD]
>> ath0: WARNING: using obsoleted if_watchdog interface
>> ath0: mac 14.2 phy 7.0 radio 10.2
> 
> I need to see the output of sysctl dev.ath.0 and how your card is 
> configured.
> 
>    Sam
> 
> _______________________________________________
> 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 mexas at bristol.ac.uk  Mon Feb  2 04:24:36 2009
From: mexas at bristol.ac.uk (Anton Shterenlikht)
Date: Mon Feb  2 04:24:45 2009
Subject: X fails on i845 board -  errors found in hardware state
Message-ID: <20090202122408.GA97807@mech-cluster238.men.bris.ac.uk>

X fails on i845G (or is it i845M ?) board with 

[skip]
(WW) intel(0): PRB0_CTL (0x0001f001) indicates ring buffer enabled
(WW) intel(0): PRB0_HEAD (0x00000024) and PRB0_TAIL (0x00000068) indicate ring b
uffer not flushed
(WW) intel(0): Existing errors found in hardware state.
Error in I830WaitLpRing(), timeout for 2 seconds
pgetbl_ctl: 0x1ffe0001 getbl_err: 0x00000000
ipeir: 0x00000000 iphdr: 0x05000000
LP ring tail: 0x00000068 head: 0x00000024 len: 0x0001f001 start 0x00000000
eir: 0x0000 esr: 0x0000 emr: 0xff7b
instdone: 0xffc1 instpm: 0x0000
memmode: 0x00000000 instps: 0x00000040
hwstam: 0xffff ier: 0x0000 imr: 0xffff iir: 0x0000
Ring at virtual 0x28c00000 head 0x24 tail 0x68 count 17 acthd 0x311a8
Ring at virtual 0x28c00000 head 0x24 tail 0x68 count 17
[skip]

Fatal server error:
lockup


The details are below. Note that it fails with or without drm.
I wonder if I should submit a pr.

many thanks
anton

# uname -srm
FreeBSD 8.0-CURRENT i386

dmesg fragments

# dmesg | grep agp
agp0: <Intel 82845M (845M GMCH) SVGA controller> on vgapci0
agp0: detected 8060k stolen memory
agp0: aperture size is 128M

# dmesg | grep drm
drm0: <Intel i845G GMCH> on vgapci0
vgapci0: child drm0 requested pci_enable_busmaster
info: [drm] AGP at 0xf0000000 128MB
info: [drm] Initialized i915 1.6.0 20080730
drm0: [ITHREAD]

full dmesg

# dmesg
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-CURRENT #0: Mon Feb  2 10:39:04 GMT 2009
    mexas@mech-Anton240.men.bris.ac.uk:/usr/obj/usr/src/sys/EDGE
WARNING: WITNESS option enabled, expect reduced performance.
Timecounter "i8254" frequency 1193182 Hz quality 0
CPU: Intel(R) Pentium(R) 4 CPU 2.40GHz (2400.10-MHz 686-class CPU)
  Origin = "GenuineIntel"  Id = 0xf27  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=0x400<CNXT-ID>
real memory  = 527695872 (503 MB)
avail memory = 507289600 (483 MB)
acpi0: <INTEL D845GRG2> on motherboard
acpi0: [ITHREAD]
acpi0: Power Button (fixed)
acpi0: reservation of 0, a0000 (3) failed
acpi0: reservation of 100000, 1f700000 (3) failed
Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000
acpi_timer0: <24-bit timer at 3.579545MHz> port 0x408-0x40b on acpi0
pcib0: <ACPI Host-PCI bridge> port 0xcf8-0xcff on acpi0
pci0: <ACPI PCI bus> on pcib0
vgapci0: <VGA-compatible display> mem 0xf0000000-0xf7ffffff,0xffa80000-0xffafffff irq 11 at device 2.0 on pci0
agp0: <Intel 82845M (845M GMCH) SVGA controller> on vgapci0
agp0: detected 8060k stolen memory
agp0: aperture size is 128M
drm0: <Intel i845G GMCH> on vgapci0
vgapci0: child drm0 requested pci_enable_busmaster
info: [drm] AGP at 0xf0000000 128MB
info: [drm] Initialized i915 1.6.0 20080730
uhci0: <Intel 82801DB (ICH4) USB controller USB-A> port 0xe800-0xe81f irq 11 at device 29.0 on pci0
uhci0: [GIANT-LOCKED]
uhci0: [ITHREAD]
usb0: <Intel 82801DB (ICH4) USB controller USB-A> on uhci0
usb0: USB revision 1.0
uhub0: <Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1> on usb0
uhub0: 2 ports with 2 removable, self powered
uhci1: <Intel 82801DB (ICH4) USB controller USB-B> port 0xe880-0xe89f irq 3 at device 29.1 on pci0
uhci1: [GIANT-LOCKED]
uhci1: [ITHREAD]
usb1: <Intel 82801DB (ICH4) USB controller USB-B> on uhci1
usb1: USB revision 1.0
uhub1: <Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1> on usb1
uhub1: 2 ports with 2 removable, self powered
uhci2: <Intel 82801DB (ICH4) USB controller USB-C> port 0xec00-0xec1f irq 5 at device 29.2 on pci0
uhci2: [GIANT-LOCKED]
uhci2: [ITHREAD]
usb2: <Intel 82801DB (ICH4) USB controller USB-C> on uhci2
usb2: USB revision 1.0
uhub2: <Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1> on usb2
uhub2: 2 ports with 2 removable, self powered
ehci0: <Intel 82801DB/L/M (ICH4) USB 2.0 controller> mem 0xffa7fc00-0xffa7ffff irq 9 at device 29.7 on pci0
ehci0: [GIANT-LOCKED]
ehci0: [ITHREAD]
usb3: EHCI version 1.0
usb3: companion controllers, 2 ports each: usb0 usb1 usb2
usb3: <Intel 82801DB/L/M (ICH4) USB 2.0 controller> on ehci0
usb3: USB revision 2.0
uhub3: <Intel EHCI root hub, class 9/0, rev 2.00/1.00, addr 1> on usb3
uhub3: 6 ports with 6 removable, self powered
pcib1: <ACPI PCI-PCI bridge> at device 30.0 on pci0
pci1: <ACPI PCI bus> on pcib1
ahc0: <Adaptec 2940 Ultra SCSI adapter> port 0xd800-0xd8ff mem 0xff8ff000-0xff8fffff irq 10 at device 0.0 on pci1
ahc0: [ITHREAD]
aic7880: Ultra Wide Channel A, SCSI Id=7, 16/253 SCBs
fxp0: <Intel 82801DB (ICH4) Pro/100 VE Ethernet> port 0xdc00-0xdc3f mem 0xff8fe000-0xff8fefff irq 11 at device 8.0 on pci1
miibus0: <MII bus> on fxp0
inphy0: <i82562ET 10/100 media interface> PHY 1 on miibus0
inphy0:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
fxp0: Ethernet address: 00:07:e9:e7:41:dc
fxp0: [ITHREAD]
isab0: <PCI-ISA bridge> at device 31.0 on pci0
isa0: <ISA bus> on isab0
atapci0: <Intel ICH4 UDMA100 controller> port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xffa0-0xffaf at device 31.1 on pci0
ata0: <ATA channel 0> on atapci0
ata0: [ITHREAD]
ata1: <ATA channel 1> on atapci0
ata1: [ITHREAD]
pci0: <serial bus, SMBus> at device 31.3 (no driver attached)
pci0: <multimedia, audio> at device 31.5 (no driver attached)
acpi_button0: <Sleep Button> on acpi0
atrtc0: <AT realtime clock> port 0x70-0x71 irq 8 on acpi0
fdc0: <floppy drive controller> port 0x3f0-0x3f1,0x3f2-0x3f3,0x3f4-0x3f5,0x3f7 irq 6 drq 2 on acpi0
fdc0: [FILTER]
fd0: <1440-KB 3.5" drive> on fdc0 drive 0
uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0
uart0: [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, device ID 3
cpu0: <ACPI CPU> on acpi0
p4tcc0: <CPU Frequency Thermal Control> on cpu0
pmtimer0 on isa0
orm0: <ISA Option ROM> at iomem 0xcb800-0xcbfff 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
Timecounter "TSC" frequency 2400099084 Hz quality 800
Timecounters tick every 1.000 msec
ahc0: Someone reset channel A
ad0: 76319MB <WDC WD800BB-00CAA1 17.07W17> at ata0-master UDMA100
acd0: DVDROM <DVD-ROM DDU1621/VER S2.9> at ata1-master UDMA33
acd1: CDRW <SONY CD-RW CRX210E1/2YS2> at ata1-slave UDMA33
Waiting 5 seconds for SCSI devices to settle
(probe0:ahc0:0:0:0): INQUIRY. CDB: 12 0 0 0 24 0 
(probe1:ahc0:0:1:0): INQUIRY. CDB: 12 0 0 0 24 0 
(probe2:ahc0:0:2:0): INQUIRY. CDB: 12 0 0 0 24 0 
(probe3:ahc0:0:3:0): INQUIRY. CDB: 12 0 0 0 24 0 
(probe4:ahc0:0:4:0): INQUIRY. CDB: 12 0 0 0 24 0 
(probe5:ahc0:0:5:0): INQUIRY. CDB: 12 0 0 0 24 0 
(probe6:ahc0:0:6:0): INQUIRY. CDB: 12 0 0 0 24 0 
(probe7:ahc0:0:8:0): INQUIRY. CDB: 12 0 0 0 24 0 
(probe8:ahc0:0:9:0): INQUIRY. CDB: 12 0 0 0 24 0 
(probe9:ahc0:0:10:0): INQUIRY. CDB: 12 0 0 0 24 0 
(probe10:ahc0:0:11:0): INQUIRY. CDB: 12 0 0 0 24 0 
(probe11:ahc0:0:12:0): INQUIRY. CDB: 12 0 0 0 24 0 
(probe12:ahc0:0:13:0): INQUIRY. CDB: 12 0 0 0 24 0 
(probe13:ahc0:0:14:0): INQUIRY. CDB: 12 0 0 0 24 0 
(probe14:ahc0:0:15:0): INQUIRY. CDB: 12 0 0 0 24 0 
GEOM: ad0s1: geometry does not match label (255h,63s != 16h,63s).
WARNING: WITNESS option enabled, expect reduced performance.
Trying to mount root from ufs:/dev/ad0s1a
lock order reversal:
 1st 0xc2c6d044 user map (user map) @ /usr/src/sys/vm/vm_map.c:3198
 2nd 0xc2e757ac ufs (ufs) @ /usr/src/sys/kern/vfs_subr.c:2071
KDB: stack backtrace:
db_trace_self_wrapper(c081229e,c2a11914,c0608e59,4,c080db0b,...) at db_trace_self_wrapper+0x26
kdb_backtrace(4,c080db0b,c081bb43,c2c2f0b0,c2a1196c,...) at kdb_backtrace+0x29
_witness_debugger(c0814ddf,c2e757ac,c0808b46,c2c2f0b0,c081bb43,...) at _witness_debugger+0x21
witness_checkorder(c2e757ac,1,c081bb43,817,0,...) at witness_checkorder+0x811
__lockmgr_args(c2e757ac,200501,c2e757c8,0,0,...) at __lockmgr_args+0x226
ffs_lock(c2a11a7c,c0608c35,c082ecbb,200501,c2e75754,...) at ffs_lock+0x7d
VOP_LOCK1_APV(c087ae20,c2a11a7c,c2c6ae24,c088b3a0,c2e75754,...) at VOP_LOCK1_APV+0xaf
_vn_lock(c2e75754,200501,c081bb43,817,4,...) at _vn_lock+0x5e
vget(c2e75754,200501,c2c6ad80,4b4,0,...) at vget+0xc1
vnode_pager_lock(c10432e8,0,c082c298,127,c2a11c18,...) at vnode_pager_lock+0x1d3
vm_fault(c2c6d000,80d6000,2,8,80d6000,...) at vm_fault+0x1e8
trap_pfault(5,0,c0837eec,2e7,c,...) at trap_pfault+0xf9
trap(c2a11d38) at trap+0x264
calltrap() at calltrap+0x6
--- trap 0xc, eip = 0x80480e5, esp = 0xbfbfeef0, ebp = 0xbfbfef10 ---
drm0: [ITHREAD]
pid 1150 (Xorg), uid 0: exited on signal 6 (core dumped)
pid 1155 (Xorg), uid 0: exited on signal 6 (core dumped)

Xorg log

#cat /var/log/Xorg.0.log
X.Org X Server 1.5.3
Release Date: 5 November 2008
X Protocol Version 11, Revision 0
Build Operating System: FreeBSD 8.0-CURRENT i386 
Current Operating System: FreeBSD mech-Anton240.men.bris.ac.uk 8.0-CURRENT FreeBSD 8.0-CURRENT #0: Mon Feb  2 10:39:04 GMT 2009     mexas@mech-Anton240.men.bris.ac.uk:/usr/obj/usr/src/sys/EDGE i386
Build Date: 27 January 2009  05:40:24PM
 
	Before reporting problems, check http://wiki.x.org
	to make sure that you have the latest version.
Markers: (--) probed, (**) from config file, (==) default setting,
	(++) from command line, (!!) notice, (II) informational,
	(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
(==) Log file: "/var/log/Xorg.0.log", Time: Mon Feb  2 11:58:09 2009
(++) Using config file: "/root/xorg.conf.new"
(==) ServerLayout "X.org Configured"
(**) |-->Screen "Screen0" (0)
(**) |   |-->Monitor "Monitor0"
(**) |   |-->Device "Card0"
(**) |-->Input Device "Mouse0"
(**) |-->Input Device "Keyboard0"
(==) Automatically adding devices
(==) Automatically enabling devices
(WW) `fonts.dir' not found (or not valid) in "/usr/local/lib/X11/fonts/100dpi/".
	Entry deleted from font path.
	(Run 'mkfontdir' on "/usr/local/lib/X11/fonts/100dpi/").
(==) Including the default font path /usr/local/lib/X11/fonts/misc/,/usr/local/lib/X11/fonts/TTF/,/usr/local/lib/X11/fonts/OTF,/usr/local/lib/X11/fonts/Type1/,/usr/local/lib/X11/fonts/100dpi/,/usr/local/lib/X11/fonts/75dpi/.
(**) FontPath set to:
	/usr/local/lib/X11/fonts/misc/,
	/usr/local/lib/X11/fonts/TTF/,
	/usr/local/lib/X11/fonts/OTF,
	/usr/local/lib/X11/fonts/Type1/,
	/usr/local/lib/X11/fonts/75dpi/,
	/usr/local/lib/X11/fonts/misc/,
	/usr/local/lib/X11/fonts/TTF/,
	/usr/local/lib/X11/fonts/OTF,
	/usr/local/lib/X11/fonts/Type1/,
	/usr/local/lib/X11/fonts/100dpi/,
	/usr/local/lib/X11/fonts/75dpi/
(**) ModulePath set to "/usr/local/lib/xorg/modules"
(WW) AllowEmptyInput is on, devices using drivers 'kbd' or 'mouse' will be disabled.
(WW) Disabling Mouse0
(WW) Disabling Keyboard0
(II) Loader magic: 0x81b1de0
(II) Module ABI versions:
	X.Org ANSI C Emulation: 0.4
	X.Org Video Driver: 4.1
	X.Org XInput driver : 2.1
	X.Org Server Extension : 1.1
	X.Org Font Renderer : 0.6
(II) Loader running on freebsd
(--) Using syscons driver with X support (version 2.0)
(--) using VT number 9

(--) PCI:*(0@0:2:0) Intel Corporation 82845G/GL[Brookdale-G]/GE Chipset Integrated Graphics Device rev 3, Mem @ 0xf0000000/0, 0xffa80000/0, BIOS @ 0x????????/65536
(II) System resource ranges:
	[0] -1	0	0x00100000 - 0x3fffffff (0x3ff00000) MX[B]E(B)
	[1] -1	0	0x000f0000 - 0x000fffff (0x10000) MX[B]
	[2] -1	0	0x000c0000 - 0x000effff (0x30000) MX[B]
	[3] -1	0	0x00000000 - 0x0009ffff (0xa0000) MX[B]
	[4] -1	0	0x0000ffff - 0x0000ffff (0x1) IX[B]
	[5] -1	0	0x00000000 - 0x000000ff (0x100) IX[B]
(II) "extmod" will be loaded. This was enabled by default and also specified in the config file.
(II) "dbe" will be loaded. This was enabled by default and also specified in the config file.
(II) "glx" will be loaded. This was enabled by default and also specified in the config file.
(II) "freetype" will be loaded. This was enabled by default and also specified in the config file.
(II) "record" will be loaded. This was enabled by default and also specified in the config file.
(II) "dri" will be loaded. This was enabled by default and also specified in the config file.
(II) LoadModule: "extmod"

(II) Loading /usr/local/lib/xorg/modules/extensions//libextmod.so
(II) Module extmod: vendor="X.Org Foundation"
	compiled for 1.5.3, module version = 1.0.0
	Module class: X.Org Server Extension
	ABI class: X.Org Server Extension, version 1.1
(II) Loading extension SHAPE
(II) Loading extension MIT-SUNDRY-NONSTANDARD
(II) Loading extension BIG-REQUESTS
(II) Loading extension SYNC
(II) Loading extension MIT-SCREEN-SAVER
(II) Loading extension XC-MISC
(II) Loading extension XFree86-VidModeExtension
(II) Loading extension XFree86-Misc
(II) Loading extension XFree86-DGA
(II) Loading extension DPMS
(II) Loading extension TOG-CUP
(II) Loading extension Extended-Visual-Information
(II) Loading extension XVideo
(II) Loading extension XVideo-MotionCompensation
(II) Loading extension X-Resource
(II) LoadModule: "record"

(II) Loading /usr/local/lib/xorg/modules/extensions//librecord.so
(II) Module record: vendor="X.Org Foundation"
	compiled for 1.5.3, module version = 1.13.0
	Module class: X.Org Server Extension
	ABI class: X.Org Server Extension, version 1.1
(II) Loading extension RECORD
(II) LoadModule: "dbe"

(II) Loading /usr/local/lib/xorg/modules/extensions//libdbe.so
(II) Module dbe: vendor="X.Org Foundation"
	compiled for 1.5.3, module version = 1.0.0
	Module class: X.Org Server Extension
	ABI class: X.Org Server Extension, version 1.1
(II) Loading extension DOUBLE-BUFFER
(II) LoadModule: "glx"

(II) Loading /usr/local/lib/xorg/modules/extensions//libglx.so
(II) Module glx: vendor="X.Org Foundation"
	compiled for 1.5.3, module version = 1.0.0
	ABI class: X.Org Server Extension, version 1.1
(==) AIGLX disabled
(==) Exporting typical set of GLX visuals
(II) Loading extension GLX
(II) LoadModule: "xtrap"

(II) Loading /usr/local/lib/xorg/modules/extensions//libxtrap.so
(II) Module xtrap: vendor="X.Org Foundation"
	compiled for 1.5.3, module version = 1.0.0
	Module class: X.Org Server Extension
	ABI class: X.Org Server Extension, version 1.1
(II) Loading extension DEC-XTRAP
(II) LoadModule: "dri"

(II) Loading /usr/local/lib/xorg/modules/extensions//libdri.so
(II) Module dri: vendor="X.Org Foundation"
	compiled for 1.5.3, module version = 1.0.0
	ABI class: X.Org Server Extension, version 1.1
(II) Loading extension XFree86-DRI
(II) LoadModule: "freetype"

(II) Loading /usr/local/lib/xorg/modules/fonts//libfreetype.so
(II) Module freetype: vendor="X.Org Foundation & the After X-TT Project"
	compiled for 1.5.3, module version = 2.1.0
	Module class: X.Org Font Renderer
	ABI class: X.Org Font Renderer, version 0.6
(II) Loading font FreeType
(II) LoadModule: "intel"

(II) Loading /usr/local/lib/xorg/modules/drivers//intel_drv.so
(II) Module intel: vendor="X.Org Foundation"
	compiled for 1.5.3, module version = 2.5.1
	Module class: X.Org Video Driver
	ABI class: X.Org Video Driver, version 4.1
(II) intel: Driver for Intel Integrated Graphics Chipsets: i810,
	i810-dc100, i810e, i815, i830M, 845G, 852GM/855GM, 865G, 915G,
	E7221 (i915), 915GM, 945G, 945GM, 945GME, 965G, G35, 965Q, 946GZ,
	965GM, 965GME/GLE, G33, Q35, Q33,
	Mobile Intel?? GM45 Express Chipset,
	Intel Integrated Graphics Device, G45/G43, Q45/Q43, G41
(II) Primary Device is: PCI 00@00:02:0
(II) resource ranges after xf86ClaimFixedResources() call:
	[0] -1	0	0x00100000 - 0x3fffffff (0x3ff00000) MX[B]E(B)
	[1] -1	0	0x000f0000 - 0x000fffff (0x10000) MX[B]
	[2] -1	0	0x000c0000 - 0x000effff (0x30000) MX[B]
	[3] -1	0	0x00000000 - 0x0009ffff (0xa0000) MX[B]
	[4] -1	0	0x0000ffff - 0x0000ffff (0x1) IX[B]
	[5] -1	0	0x00000000 - 0x000000ff (0x100) IX[B]
(II) resource ranges after probing:
	[0] -1	0	0x00100000 - 0x3fffffff (0x3ff00000) MX[B]E(B)
	[1] -1	0	0x000f0000 - 0x000fffff (0x10000) MX[B]
	[2] -1	0	0x000c0000 - 0x000effff (0x30000) MX[B]
	[3] -1	0	0x00000000 - 0x0009ffff (0xa0000) MX[B]
	[4] 0	0	0x000a0000 - 0x000affff (0x10000) MS[B]
	[5] 0	0	0x000b0000 - 0x000b7fff (0x8000) MS[B]
	[6] 0	0	0x000b8000 - 0x000bffff (0x8000) MS[B]
	[7] -1	0	0x0000ffff - 0x0000ffff (0x1) IX[B]
	[8] -1	0	0x00000000 - 0x000000ff (0x100) IX[B]
	[9] 0	0	0x000003b0 - 0x000003bb (0xc) IS[B]
	[10] 0	0	0x000003c0 - 0x000003df (0x20) IS[B]
(II) Loading sub module "vgahw"
(II) LoadModule: "vgahw"

(II) Loading /usr/local/lib/xorg/modules//libvgahw.so
(II) Module vgahw: vendor="X.Org Foundation"
	compiled for 1.5.3, module version = 0.1.0
	ABI class: X.Org Video Driver, version 4.1
(==) intel(0): Depth 24, (==) framebuffer bpp 32
(==) intel(0): RGB weight 888
(==) intel(0): Default visual is TrueColor
(II) intel(0): Integrated Graphics Chipset: Intel(R) 845G
(--) intel(0): Chipset: "845G"
(--) intel(0): Linear framebuffer at 0xF0000000
(--) intel(0): IO registers at addr 0xFFA80000
(==) intel(0): Using EXA for acceleration
(II) intel(0): 1 display pipe available.
(II) Loading sub module "ddc"
(II) LoadModule: "ddc"
(II) Module "ddc" already built-in
(II) Loading sub module "i2c"
(II) LoadModule: "i2c"
(II) Module "i2c" already built-in
(II) intel(0): Output VGA using monitor section Monitor0
(II) intel(0): I2C bus "DVODDC_D" initialized.
(II) Loading sub module "sil164"
(II) LoadModule: "sil164"

(II) Loading /usr/local/lib/xorg/modules/drivers//sil164.so
(II) Module sil164: vendor="X.Org Foundation"
	compiled for 1.5.3, module version = 1.0.0
	ABI class: X.Org Video Driver, version 4.1
(II) intel(0): I2C bus "DVOI2C_E" initialized.
(II) Loading sub module "ch7xxx"
(II) LoadModule: "ch7xxx"

(II) Loading /usr/local/lib/xorg/modules/drivers//ch7xxx.so
(II) Module ch7xxx: vendor="X.Org Foundation"
	compiled for 1.5.3, module version = 1.0.0
	ABI class: X.Org Video Driver, version 4.1
(II) intel(0): I2C bus "DVOI2C_E" removed.
(II) intel(0): I2C bus "DVOI2C_E" initialized.
(II) Loading sub module "ivch"
(II) LoadModule: "ivch"

(II) Loading /usr/local/lib/xorg/modules/drivers//ivch.so
(II) Module ivch: vendor="X.Org Foundation"
	compiled for 1.5.3, module version = 1.0.0
	ABI class: X.Org Video Driver, version 4.1
(II) intel(0): I2C bus "DVOI2C_E" removed.
(II) intel(0): I2C bus "DVOI2C_B" initialized.
(II) Loading sub module "tfp410"
(II) LoadModule: "tfp410"

(II) Loading /usr/local/lib/xorg/modules/drivers//tfp410.so
(II) Module tfp410: vendor="X.Org Foundation"
	compiled for 1.5.3, module version = 1.0.0
	ABI class: X.Org Video Driver, version 4.1
(II) intel(0): I2C bus "DVOI2C_B" removed.
(II) intel(0): I2C bus "DVOI2C_E" initialized.
(II) Loading sub module "ch7017"
(II) LoadModule: "ch7017"

(II) Loading /usr/local/lib/xorg/modules/drivers//ch7017.so
(II) Module ch7017: vendor="X.Org Foundation"
	compiled for 1.5.3, module version = 1.0.0
	ABI class: X.Org Video Driver, version 4.1
(II) intel(0): I2C bus "DVOI2C_E" removed.
(II) intel(0): I2C bus "DVOI2C_E" initialized.
(II) intel(0): I2C bus "DVOI2C_E" removed.
(II) intel(0): I2C bus "DVODDC_D" removed.
(==) intel(0): Write-combining range (0xa0000,0x10000) was already clear
(II) intel(0): I2C bus "CRTDDC_A" initialized.
(II) intel(0): I2C bus "CRTDDC_A" removed.
(II) intel(0): I2C bus "CRTDDC_A" initialized.
(II) intel(0): I2C device "CRTDDC_A:ddc2" registered at address 0xA0.
(II) intel(0): I2C device "CRTDDC_A:ddc2" removed.
(II) intel(0): I2C bus "CRTDDC_A" removed.
(II) intel(0): EDID vendor "@@@", prod id 0
(II) intel(0): Printing DDC gathered Modelines:
(II) intel(0): Modeline "800x600"x0.0   40.00  800 840 968 1056  600 601 605 628 +hsync +vsync (37.9 kHz)
(II) intel(0): Modeline "800x600"x0.0   36.00  800 824 896 1024  600 601 603 625 +hsync +vsync (35.2 kHz)
(II) intel(0): Modeline "640x480"x0.0   31.50  640 656 720 840  480 481 484 500 -hsync -vsync (37.5 kHz)
(II) intel(0): Modeline "640x480"x0.0   31.50  640 664 704 832  480 489 491 520 -hsync -vsync (37.9 kHz)
(II) intel(0): Modeline "640x480"x0.0   30.24  640 704 768 864  480 483 486 525 -hsync -vsync (35.0 kHz)
(II) intel(0): Modeline "640x480"x0.0   25.20  640 656 752 800  480 490 492 525 -hsync -vsync (31.5 kHz)
(II) intel(0): Modeline "720x400"x0.0   28.32  720 738 846 900  400 412 414 449 -hsync +vsync (31.5 kHz)
(II) intel(0): Modeline "1024x768"x0.0   78.80  1024 1040 1136 1312  768 769 772 800 +hsync +vsync (60.1 kHz)
(II) intel(0): Modeline "1024x768"x0.0   75.00  1024 1048 1184 1328  768 771 777 806 -hsync -vsync (56.5 kHz)
(II) intel(0): Modeline "1024x768"x0.0   65.00  1024 1048 1184 1344  768 771 777 806 -hsync -vsync (48.4 kHz)
(II) intel(0): Modeline "832x624"x0.0   57.28  832 864 928 1152  624 625 628 667 -hsync -vsync (49.7 kHz)
(II) intel(0): Modeline "800x600"x0.0   49.50  800 816 896 1056  600 601 604 625 +hsync +vsync (46.9 kHz)
(II) intel(0): Modeline "800x600"x0.0   50.00  800 856 976 1040  600 637 643 666 +hsync +vsync (48.1 kHz)
(II) intel(0): EDID vendor "@@@", prod id 0
(II) intel(0): Output VGA connected
(II) intel(0): Using fuzzy aspect match for initial modes
(II) intel(0): Output VGA using initial mode 1280x960
(==) intel(0): Write-combining range (0xa0000,0x10000) was already clear
(II) intel(0): detected 128 kB GTT.
(II) intel(0): detected 8060 kB stolen memory.
(==) intel(0): video overlay key set to 0x101fe
(==) intel(0): Intel XvMC decoder disabled
(==) intel(0): Will not try to enable page flipping
(==) intel(0): Triple buffering disabled
(==) intel(0): Using gamma correction (1.0, 1.0, 1.0)
(**) intel(0): Display dimensions: (300, 230) mm
(**) intel(0): DPI set to (108, 141)
(II) Loading sub module "fb"
(II) LoadModule: "fb"

(II) Loading /usr/local/lib/xorg/modules//libfb.so
(II) Module fb: vendor="X.Org Foundation"
	compiled for 1.5.3, module version = 1.0.0
	ABI class: X.Org ANSI C Emulation, version 0.4
(II) Loading sub module "exa"
(II) LoadModule: "exa"

(II) Loading /usr/local/lib/xorg/modules//libexa.so
(II) Module exa: vendor="X.Org Foundation"
	compiled for 1.5.3, module version = 2.4.0
	ABI class: X.Org Video Driver, version 4.1
(II) Loading sub module "ramdac"
(II) LoadModule: "ramdac"
(II) Module "ramdac" already built-in
(II) intel(0): Comparing regs from server start up to After PreInit
(==) Depth 24 pixmap format is 32 bpp
(II) do I need RAC?  No, I don't.
(II) resource ranges after preInit:
	[0] -1	0	0x00100000 - 0x3fffffff (0x3ff00000) MX[B]E(B)
	[1] -1	0	0x000f0000 - 0x000fffff (0x10000) MX[B]
	[2] -1	0	0x000c0000 - 0x000effff (0x30000) MX[B]
	[3] -1	0	0x00000000 - 0x0009ffff (0xa0000) MX[B]
	[4] 0	0	0x000a0000 - 0x000affff (0x10000) MS[B](OprD)
	[5] 0	0	0x000b0000 - 0x000b7fff (0x8000) MS[B](OprD)
	[6] 0	0	0x000b8000 - 0x000bffff (0x8000) MS[B](OprD)
	[7] -1	0	0x0000ffff - 0x0000ffff (0x1) IX[B]
	[8] -1	0	0x00000000 - 0x000000ff (0x100) IX[B]
	[9] 0	0	0x000003b0 - 0x000003bb (0xc) IS[B](OprU)
	[10] 0	0	0x000003c0 - 0x000003df (0x20) IS[B](OprU)
(II) intel(0): Kernel reported 112640 total, 0 used
(II) intel(0): I830CheckAvailableMemory: 450560 kB available
drmOpenDevice: node name is /dev/dri/card0
drmOpenDevice: open result is 11, (OK)
drmOpenDevice: node name is /dev/dri/card0
drmOpenDevice: open result is 11, (OK)
drmOpenByBusid: Searching for BusID pci:0000:00:02.0
drmOpenDevice: node name is /dev/dri/card0
drmOpenDevice: open result is 11, (OK)
drmOpenByBusid: drmOpenMinor returns 11
drmOpenByBusid: drmGetBusid reports pci:0000:00:02.0
(II) [drm] DRM interface version 1.2
(II) [drm] DRM open master succeeded.
(II) intel(0): [drm] Using the DRM lock SAREA also for drawables.
(II) intel(0): [drm] framebuffer mapped by ddx driver
(II) intel(0): [drm] added 1 reserved context for kernel
(II) intel(0): X context handle = 0x2
(II) intel(0): [drm] installed DRM signal handler
(**) intel(0): Framebuffer compression disabled
(**) intel(0): Tiling enabled
(==) intel(0): VideoRam: 131072 KB
(II) intel(0): Attempting memory allocation with tiled buffers.
(II) intel(0): Tiled allocation successful.
(II) intel(0): [drm] Registers = 0xffa80000
(II) intel(0): [drm] ring buffer = 0xf0000000
(II) intel(0): [drm] mapped front buffer at 0xf1000000, handle = 0xf1000000
(II) intel(0): [drm] mapped back buffer at 0xf4000000, handle = 0xf4000000
(II) intel(0): [drm] mapped depth buffer at 0xf5000000, handle = 0xf5000000
(II) intel(0): [drm] mapped classic textures at 0xf6000000, handle = 0xf6000000
(II) intel(0): [drm] Initialized kernel agp heap manager, 33554432
(II) intel(0): [dri] visual configs initialized
(II) intel(0): Page Flipping disabled
(II) intel(0): vgaHWGetIOBase: hwp->IOBase is 0x03d0, hwp->PIOOffset is 0x0000
(==) intel(0): Write-combining range (0xa0000,0x10000) was already clear
(II) EXA(0): Offscreen pixmap area of 31457280 bytes
(II) EXA(0): Driver registered support for the following operations:
(II)         Solid
(II)         Copy
(II)         Composite (RENDER acceleration)
(==) intel(0): Backing store disabled
(==) intel(0): Silken mouse enabled
(II) intel(0): Initializing HW Cursor
(II) intel(0): [DRI] installation complete
(II) intel(0): xf86BindGARTMemory: bind key 13 at 0x007df000 (pgoffset 2015)
(II) intel(0): xf86BindGARTMemory: bind key 14 at 0x01000000 (pgoffset 4096)
(II) intel(0): xf86BindGARTMemory: bind key 15 at 0x02000000 (pgoffset 8192)
(II) intel(0): xf86BindGARTMemory: bind key 16 at 0x04000000 (pgoffset 16384)
(II) intel(0): xf86BindGARTMemory: bind key 17 at 0x05000000 (pgoffset 20480)
(II) intel(0): xf86BindGARTMemory: bind key 18 at 0x06000000 (pgoffset 24576)
(II) intel(0): Fixed memory allocation layout:
(II) intel(0): 0x00000000-0x0001ffff: ring buffer (128 kB)
(II) intel(0): 0x00020000-0x00024fff: HW cursors (20 kB)
(II) intel(0): 0x00025000-0x0002cfff: logical 3D context (32 kB)
(II) intel(0): 0x0002d000-0x0012cfff: fake bufmgr (1024 kB)
(II) intel(0): 0x007df000:            end of stolen memory
(II) intel(0): 0x007df000-0x007dffff: overlay registers (4 kB, 0x00000000107c6000 physical
)
(II) intel(0): 0x01000000-0x01ffffff: front buffer (10240 kB) X tiled
(II) intel(0): 0x02000000-0x03dfffff: exa offscreen (30720 kB)
(II) intel(0): 0x04000000-0x04ffffff: back buffer (10240 kB) X tiled
(II) intel(0): 0x05000000-0x05ffffff: depth buffer (10240 kB) X tiled
(II) intel(0): 0x06000000-0x07ffffff: classic textures (32768 kB)
(II) intel(0): 0x08000000:            end of aperture
(WW) intel(0): PRB0_CTL (0x0001f001) indicates ring buffer enabled
(WW) intel(0): PRB0_HEAD (0x00000024) and PRB0_TAIL (0x00000068) indicate ring buffer not flushed
(WW) intel(0): Existing errors found in hardware state.
Error in I830WaitLpRing(), timeout for 2 seconds
pgetbl_ctl: 0x1ffe0001 getbl_err: 0x00000000
ipeir: 0x00000000 iphdr: 0x05000000
LP ring tail: 0x00000068 head: 0x00000024 len: 0x0001f001 start 0x00000000
eir: 0x0000 esr: 0x0000 emr: 0xff7b
instdone: 0xffc1 instpm: 0x0000
memmode: 0x00000000 instps: 0x00000040
hwstam: 0xffff ier: 0x0000 imr: 0xffff iir: 0x0000
Ring at virtual 0x28c00000 head 0x24 tail 0x68 count 17 acthd 0x311a8
Ring at virtual 0x28c00000 head 0x24 tail 0x68 count 17
Ring at virtual 0x28c00000 head 0x24 tail 0x68 count 17
Ring at virtual 0x28c00000 head 0x24 tail 0x68 count 17
Ring at virtual 0x28c00000 head 0x24 tail 0x68 count 17
Ring at virtual 0x28c00000 head 0x24 tail 0x68 count 17
Ring at virtual 0x28c00000 head 0x24 tail 0x68 count 17
Ring at virtual 0x28c00000 head 0x24 tail 0x68 count 17
Ring at virtual 0x28c00000 head 0x24 tail 0x68 count 17
Ring at virtual 0x28c00000 head 0x24 tail 0x68 count 17
Ring at virtual 0x28c00000 head 0x24 tail 0x68 count 17
Ring at virtual 0x28c00000 head 0x24 tail 0x68 count 17
Ring at virtual 0x28c00000 head 0x24 tail 0x68 count 17
Ring at virtual 0x28c00000 head 0x24 tail 0x68 count 17
Ring at virtual 0x28c00000 head 0x24 tail 0x68 count 17
Ring at virtual 0x28c00000 head 0x24 tail 0x68 count 17
Ring at virtual 0x28c00000 head 0x24 tail 0x68 count 17
Ring at virtual 0x28c00000 head 0x24 tail 0x68 count 17
Ring at virtual 0x28c00000 head 0x24 tail 0x68 count 17
Ring at virtual 0x28c00000 head 0x24 tail 0x68 count 17
Ring at virtual 0x28c00000 head 0x24 tail 0x68 count 17
Ring at virtual 0x28c00000 head 0x24 tail 0x68 count 17
Ring at virtual 0x28c00000 head 0x24 tail 0x68 count 17
Ring at virtual 0x28c00000 head 0x24 tail 0x68 count 17
Ring at virtual 0x28c00000 head 0x24 tail 0x68 count 17
Ring at virtual 0x28c00000 head 0x24 tail 0x68 count 17
Ring at virtual 0x28c00000 head 0x24 tail 0x68 count 17
Ring at virtual 0x28c00000 head 0x24 tail 0x68 count 17
Ring at virtual 0x28c00000 head 0x24 tail 0x68 count 17
Ring at virtual 0x28c00000 head 0x24 tail 0x68 count 17
Ring at virtual 0x28c00000 head 0x24 tail 0x68 count 17
Ring at virtual 0x28c00000 head 0x24 tail 0x68 count 17
Ring at virtual 0x28c00000 head 0x24 tail 0x68 count 17
Ring at virtual 0x28c00000 head 0x24 tail 0x68 count 17
Ring at virtual 0x28c00000 head 0x24 tail 0x68 count 17
Ring at virtual 0x28c00000 head 0x24 tail 0x68 count 17
Ring at virtual 0x28c00000 head 0x24 tail 0x68 count 17
Ring at virtual 0x28c00000 head 0x24 tail 0x68 count 17
Ring at virtual 0x28c00000 head 0x24 tail 0x68 count 17
Ring at virtual 0x28c00000 head 0x24 tail 0x68 count 17
Ring at virtual 0x28c00000 head 0x24 tail 0x68 count 17
Ring at virtual 0x28c00000 head 0x24 tail 0x68 count 17
Ring at virtual 0x28c00000 head 0x24 tail 0x68 count 17
Ring at virtual 0x28c00000 head 0x24 tail 0x68 count 17
Ring at virtual 0x28c00000 head 0x24 tail 0x68 count 17
Ring at virtual 0x28c00000 head 0x24 tail 0x68 count 17
Ring at virtual 0x28c00000 head 0x24 tail 0x68 count 17
Ring at virtual 0x28c00000 head 0x24 tail 0x68 count 17
Ring at virtual 0x28c00000 head 0x24 tail 0x68 count 17
Ring at virtual 0x28c00000 head 0x24 tail 0x68 count 17
Ring at virtual 0x28c00000 head 0x24 tail 0x68 count 17
Ring at virtual 0x28c00000 head 0x24 tail 0x68 count 17
Ring at virtual 0x28c00000 head 0x24 tail 0x68 count 17
Ring at virtual 0x28c00000 head 0x24 tail 0x68 count 17
Ring at virtual 0x28c00000 head 0x24 tail 0x68 count 17
Ring at virtual 0x28c00000 head 0x24 tail 0x68 count 17
Ring at virtual 0x28c00000 head 0x24 tail 0x68 count 17
Ring at virtual 0x28c00000 head 0x24 tail 0x68 count 17
Ring at virtual 0x28c00000 head 0x24 tail 0x68 count 17
Ring at virtual 0x28c00000 head 0x24 tail 0x68 count 17
Ring at virtual 0x28c00000 head 0x24 tail 0x68 count 17
Ring at virtual 0x28c00000 head 0x24 tail 0x68 count 17
Ring at virtual 0x28c00000 head 0x24 tail 0x68 count 17
Ring at virtual 0x28c00000 head 0x24 tail 0x68 count 17
Ring at virtual 0x28c00000 head 0x24 tail 0x68 count 17
Ring end
space: 130996 wanted 131064
(II) intel(0): [drm] removed 1 reserved context for kernel
(II) intel(0): [drm] unmapping 8192 bytes of SAREA 0xc325a000 at 0x286e0000
(II) intel(0): [drm] Closed DRM master.

Fatal server error:
lockup

_fence_emit_internal: drm_i915_irq_emit: -9

-- 
Anton Shterenlikht
Room 2.6, Queen's Building
Mech Eng Dept
Bristol University
University Walk, Bristol BS8 1TR, UK
Tel: +44 (0)117 928 8233 
Fax: +44 (0)117 929 4423
From ianf at clue.co.za  Mon Feb  2 06:23:39 2009
From: ianf at clue.co.za (Ian FREISLICH)
Date: Mon Feb  2 06:23:47 2009
Subject: Jemalloc SEGV for 1MB chunk 
In-Reply-To: <515c64960901280425y642a190ka31409cfc2a2fd8f@mail.gmail.com> 
References: <515c64960901280425y642a190ka31409cfc2a2fd8f@mail.gmail.com>
	<515c64960901280339m17fa9309v2e1bc3f55454ab@mail.gmail.com>
	<49804597.6040303@gmx.de>
	<515c64960901280401w1e1d08bfx29adc124bc749c4a@mail.gmail.com>
	<E1LS9Pa-000NBW-Ct@kabab.cs.huji.ac.il> 
Message-ID: <E1LTzA5-0005zc-OH@clue.co.za>

Channa wrote:
> Thanks for the reply.
> 
> I understand , after terminating the string with NULL character no
> SEGV is seen.
>
> But if i change the request size to a value less than 1MB for eg: 4096
> Bytes,
>
> I dont see any issues, without terminating the string with NULL
> character the test code works fine. The issue is seen only for size
> 1MB exactly.
>
> Can anyone explain this behaviour?

It's probably caused because although you asked for 4096 bytes of
memory a larger chunk was allocated so that a subsequent malloc calls
need not make a system call but can allocate from unallocated
allocated memory.  It's also likely that the memory was zeroed by
malloc so the string was NULL terminated "by accident".

Ian

--
Ian Freislich
From admin at lissyara.su  Mon Feb  2 06:30:34 2009
From: admin at lissyara.su (Alex Keda)
Date: Mon Feb  2 06:30:46 2009
Subject: 'make distribution' errors
Message-ID: <4987037C.5060201@lissyara.su>

lissyara# pwd
/mnt/jabber/DISTR/FreeBSD/src/CURRENT
lissyara# make distribution DESTDIR=/mnt/da4
........ skipped .........
cd /mnt/jabber/DISTR/FreeBSD/src/CURRENT/etc/sendmail; make distribution
install -o root -g wheel -m 644  
/mnt/jabber/DISTR/FreeBSD/src/CURRENT/etc/sendmail/freebsd.mc freebsd.cf 
/mnt/da4/etc/mail
install: freebsd.cf: No such file or directory
*** Error code 71

Stop in /mnt/jabber/DISTR/FreeBSD/src/CURRENT/etc/sendmail.
*** Error code 1

Stop in /mnt/jabber/DISTR/FreeBSD/src/CURRENT/etc.
*** Error code 1

Stop in /mnt/jabber/DISTR/FreeBSD/src/CURRENT.
*** Error code 1

Stop in /mnt/jabber/DISTR/FreeBSD/src/CURRENT.
================
lissyara# uname -a
FreeBSD lissyara.moskb.local 8.0-CURRENT FreeBSD 8.0-CURRENT #0: Mon 
Feb  2 14:16:02 MSK 2009     
lissyara@lissyara.moskb.local:/usr/obj/mnt/jabber/DISTR/FreeBSD/src/CURRENT/sys/USB2  
amd64
=================
but, if I type:
lissyara# make distribution DESTDIR=/mnt/da4 TARGET_ARCH=i386  
all OK...
From c47g at gmx.at  Mon Feb  2 07:43:25 2009
From: c47g at gmx.at (Christian Gusenbauer)
Date: Mon Feb  2 07:43:32 2009
Subject: lpt stopped working
Message-ID: <200902021643.39862.c47g@gmx.at>

Hi!

Since the recent update (svn r187576) to the ppbus/ppc code my printer stopped 
working. Every request seems to hang forever in ppb_request_bus waiting for 
ppb->ppc_lock (at least 'top' tells me that it's hanging in state 'ppbreq').

Any clues?

Many thanks,
Christian.
From imb at protected-networks.net  Mon Feb  2 07:47:18 2009
From: imb at protected-networks.net (Michael Butler)
Date: Mon Feb  2 07:47:24 2009
Subject: lpt stopped working
In-Reply-To: <200902021643.39862.c47g@gmx.at>
References: <200902021643.39862.c47g@gmx.at>
Message-ID: <4987157E.9080605@protected-networks.net>

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

Christian Gusenbauer wrote:
> Since the recent update (svn r187576) to the ppbus/ppc code my printer stopped 
> working. Every request seems to hang forever in ppb_request_bus waiting for 
> ppb->ppc_lock (at least 'top' tells me that it's hanging in state 'ppbreq').
> 
> Any clues?

Further to this: sane-backends and qemu now refuse to compile :-(

	Michael
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (FreeBSD)

iEYEARECAAYFAkmHFX4ACgkQQv9rrgRC1JIxlwCfeTPOLmmLAAH/ZBPTnKdABWWi
81wAnR93qTZtlcePAHn2ztqWUGlCa0uZ
=mG4u
-----END PGP SIGNATURE-----
From chet.ramey at case.edu  Mon Feb  2 08:52:47 2009
From: chet.ramey at case.edu (Chet Ramey)
Date: Mon Feb  2 08:57:27 2009
Subject: Alternatives to gcc (was Re: gcc 4.3: when will
	it	becomestandard compiler?)
In-Reply-To: Message from yanefbsd@gmail.com of Mon,
	02 Feb 2009 00:20:16 -0800 (id
	<7d6fde3d0902020020n3d5aac5cu4f3381a195d6fdcf@mail.gmail.com>)
References: <87223.61659.qm@web32707.mail.mud.yahoo.com>
	<p06240803c5ac33499e88@128.113.24.47>
	<7d6fde3d0902020020n3d5aac5cu4f3381a195d6fdcf@mail.gmail.com>
Message-ID: <090202163851.AA93299.SM@caleb.INS.CWRU.Edu>

> It all depends on what features people choose to use in GNU's readline
> that makes it compatible or not with libedit.

...which means that it's not a drop-in readline replacement.  And here we
are -- back where we started.


-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer

Chet Ramey, ITS, CWRU    chet@case.edu    http://tiswww.tis.case.edu/~chet/
From sam at freebsd.org  Mon Feb  2 08:58:00 2009
From: sam at freebsd.org (Sam Leffler)
Date: Mon Feb  2 08:58:07 2009
Subject: ath driver (?) lock system after last update
In-Reply-To: <4986D59A.9080906@mail.ru>
References: <498652D2.7030906@mail.ru> <49867969.3020406@freebsd.org>
	<4986D59A.9080906@mail.ru>
Message-ID: <49872615.1040002@freebsd.org>

Should be fixed by r188011.

Sam

Subscriber wrote:
> Output of 'sysctl dev.ath':
>
> dev.ath.0.%desc: Atheros 5424/2424
> dev.ath.0.%driver: ath
> dev.ath.0.%location: slot=0 function=0
> dev.ath.0.%pnpinfo: vendor=0x168c device=0x001c subvendor=0x1a3b 
> subdevice=0x1026 class=0x020000
> dev.ath.0.%parent: pci2
> dev.ath.0.smoothing_rate: 95
> dev.ath.0.sample_rate: 10
> dev.ath.0.sample_stats: 0
> dev.ath.0.countrycode: 0
> dev.ath.0.regdomain: 96
> dev.ath.0.slottime: 20
> dev.ath.0.acktimeout: 48
> dev.ath.0.ctstimeout: 48
> dev.ath.0.softled: 0
> dev.ath.0.ledpin: 0
> dev.ath.0.ledon: 0
> dev.ath.0.ledidle: 2700
> dev.ath.0.txantenna: 0
> dev.ath.0.rxantenna: 2
> dev.ath.0.diversity: 1
> dev.ath.0.txintrperiod: 5
> dev.ath.0.diag: 0
> dev.ath.0.tpscale: 0
> dev.ath.0.tpc: 0
> dev.ath.0.tpack: 63
> dev.ath.0.tpcts: 63
> dev.ath.0.rfsilent: 1
> dev.ath.0.rfkill: 1
> dev.ath.0.intmit: 1
> dev.ath.0.monpass: 24
>
> I not changed sysctl setting for ath0 because of fine forking with 
> default settings on early drivers.
>
> > and how your card is configured.
> What it means? Wireless network related rc.conf settings?
> if_up_delay="1"
> wlans_ath0=wlan0
> ifconfig_wlan0="WPA DHCP"
>
> I use FreeBSD 7.1 box with Atheros wi-fi card (don't remember exact 
> model, can see later if it need) as wireless AP (bridge).
>
>
> Sam Leffler ??????????:
>> Subscriber wrote:
>>> I updated my 8-CURRENT and now system freeze shortly after boot (~0.5-3
>>> minutes). I see following messages in console:
>>>
>>> Jan 31 02:18:03 cache kernel: ath0: bad series0 hwrate 0x0, tries 4 
>>> ts_status 0x0
>>> Jan 31 02:18:03 cache kernel: ath0: bad series1 hwrate 0x0, tries 3 
>>> ts_status 0x0
>>> Jan 31 02:18:03 cache kernel: ath0: bad series2 hwrate 0x0, tries 4 
>>> ts_status 0x0
>>> Jan 31 02:18:03 cache kernel: ath0: bad series0 hwrate 0x0, tries 4 
>>> ts_status 0x0
>>> Jan 31 02:18:03 cache kernel: ath0: bad series1 hwrate 0x0, tries 3 
>>> ts_status 0x0
>>> Jan 31 02:18:03 cache kernel: ath0: bad series2 hwrate 0x0, tries 4 
>>> ts_status 0x0
>>> Jan 31 02:18:03 cache kernel: ath0: bad series0 hwrate 0x0, tries 4 
>>> ts_status 0x0
>>> Jan 31 02:18:03 cache kernel: ath0: bad series1 hwrate 0x0, tries 3 
>>> ts_status 0x0
>>> Jan 31 02:18:03 cache kernel: ath0: bad series2 hwrate 0x0, tries 4 
>>> ts_status 0x0
>>> ...
>>>
>>> much time, then system freeze. Before last update I was never see 
>>> those messages.
>>> Now I rolled back to HEAD sources with date=2009.01.01, and all 
>>> seems OK.
>>
>>
>>> ath0: <Atheros 5424/2424> mem 0xfd7f0000-0xfd7fffff irq 16 at device 
>>> 0.0 on pci2
>>> ath0: [ITHREAD]
>>> ath0: WARNING: using obsoleted if_watchdog interface
>>> ath0: mac 14.2 phy 7.0 radio 10.2
>>
>> I need to see the output of sysctl dev.ath.0 and how your card is 
>> configured.
>>
>> Sam
>>
>> _______________________________________________
>> freebsd-current@freebsd.org mailing list
>> http://lists.freebsd.org/mailman/listinfo/freebsd-current
>> To unsubscribe, send any mail to 
>> "freebsd-current-unsubscribe@freebsd.org"
>>
>>
>
> _______________________________________________
> freebsd-current@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to 
> "freebsd-current-unsubscribe@freebsd.org"
>
>

From pluknet at gmail.com  Mon Feb  2 09:26:47 2009
From: pluknet at gmail.com (pluknet)
Date: Mon Feb  2 09:26:53 2009
Subject: 'make distribution' errors
In-Reply-To: <4987037C.5060201@lissyara.su>
References: <4987037C.5060201@lissyara.su>
Message-ID: <a31046fc0902020926t6a5d9863m853cbccbc3647234@mail.gmail.com>

2009/2/2 Alex Keda <admin@lissyara.su>:
> lissyara# pwd
> /mnt/jabber/DISTR/FreeBSD/src/CURRENT
> lissyara# make distribution DESTDIR=/mnt/da4
> ........ skipped .........
> cd /mnt/jabber/DISTR/FreeBSD/src/CURRENT/etc/sendmail; make distribution
> install -o root -g wheel -m 644
>  /mnt/jabber/DISTR/FreeBSD/src/CURRENT/etc/sendmail/freebsd.mc freebsd.cf
> /mnt/da4/etc/mail
> install: freebsd.cf: No such file or directory
> *** Error code 71

You have somehow missed `make world` phase for your arch, or more
precisely - `make` in etc/sendmail ..

-- 
wbr,
pluknet
From oz at nixil.net  Mon Feb  2 10:04:49 2009
From: oz at nixil.net (Phil Oleson)
Date: Mon Feb  2 10:04:56 2009
Subject: Much ado about libedit [Re: Alternatives to gcc (was Re: gcc
 4.3:	when will it becomestandard compiler?)]
In-Reply-To: <F5F65516-ED99-4055-90B9-E062196CBC07@gmail.com>
References: <779523.80455.qm@web32706.mail.mud.yahoo.com>	<20090131221236.GA27303@soaustin.net>	<f0dd9eb90901311553u9eaf5c2h508146ca227ef8e6@mail.gmail.com>	<f0dd9eb90901311555u4c5e4d4fv515f5ceb3d075b77@mail.gmail.com>	<20090201090143.GA1429@lizard.fafoe.narf.at>
	<F5F65516-ED99-4055-90B9-E062196CBC07@gmail.com>
Message-ID: <49872EE5.9070205@nixil.net>

Garrett Cooper wrote:
> On Feb 1, 2009, at 1:01 AM, Stefan Farfeleder wrote:
> 
>> On Sun, Feb 01, 2009 at 12:55:20PM +1300, James Butler wrote:
>>> 2009/2/1 Mark Linimon <linimon@lonesome.com>:
>>>> On Sat, Jan 31, 2009 at 01:08:54PM -0800, Pedro F. Giffuni wrote:
>>>>> The effort didn't go far enough. Why haven't we removed GNU readline ?
>>>>
>>>> Probably either because someone hasn't written a BSD-licensed one, or
>>>> someone hasn't done the work to test-compile src and ports on all the
>>>> appropriate architectures.
>>>
>>> This might be off topic, but NetBSD has (limited) readline
>>> compatibility in their libedit (which FreeBSD has in ports I think) -
>>> this also gives them tab-completion in /bin/sh :-)
>>
>> I once posted a patch which ports it to FreeBSD.  It would need a lot of
>> work to fix all ports though.
> 
>     libedit isn't feature complete with GNU readline and many things 
> will fail to compile with NetBSD's rip on readline. Believe me -- I 
> tried with python -_-...
>     Then again at least you can make GNU readline into a port for things 
> that need it (like Python's readline module).
>     And yes, we do already have libedit in the base source tree under 
> lib/libedit -- it's just extremely outdated (hence libreadline isn't 
> available after compiling libedit).
> Cheers,
> -Garrett

Actually your a bit wrong here.  I submitted a patch to current around 2005
to get libedit upgraded to the latest NetBSD version.  The version in the
FreeBSD 4.x tree was an ancient version that was incompatible with most programs
that attempted to use it (ie.. ssh).   Stefan Farfeleder was kind enough to 
port those patches into something usable in the base system.  The 6.x tree
contains those updates.  This porting from NetBSD happens periodically as
bugs and or an itch needing to be scratched happens to prompt it.  As to why
the readline compatibility shims are removed from the base libedit..  well
I suspect that it's that way to prevent the readline in base and or ports
from being ignored and misconfigured, AND those programs that can use
libedit's native API are configured to use it and not readline.  

	-Phil.
From giffunip at tutopia.com  Mon Feb  2 09:47:29 2009
From: giffunip at tutopia.com (Pedro F. Giffuni)
Date: Mon Feb  2 10:14:16 2009
Subject: GNU readline (was Re: Alternatives to gcc)
Message-ID: <160891.1210.qm@web32701.mail.mud.yahoo.com>

(sorry that my mailer gives so much trouble)

--- On Mon, 2/2/09, Chet Ramey <chet.ramey@case.edu> wrote:

> > It all depends on what features people choose to use in GNU's
> > readline that makes it compatible or not with libedit.
>
> ...which means that it's not a drop-in readline replacement.? And
> here we are -- back where we started.

We don't need a drop in replacement, we need a replacement that works well enough for the base system. 

Like in the other BSDs the ports/packaging system can continue carrying GNU readline.

Why go into all this trouble? GNU readline is part of an evil plot:

http://www.gnu.org/licenses/why-not-lgpl.html

Pedro.


      
From xcllnt at mac.com  Mon Feb  2 11:16:58 2009
From: xcllnt at mac.com (Marcel Moolenaar)
Date: Mon Feb  2 11:17:51 2009
Subject: GEOM_PART: a quick update on logical partitions
Message-ID: <FCA8C5E4-BC41-4711-9EBC-CD692144F6B8@mac.com>

All,

In case people are wondering: I'm working on proper support for
logical partitions. This should also allow us to create and
modify them. Of course when you add or remove a partition, the
index changes and consequently the device name. I still need
to find a good solution for that. Currently I'm thinking that
we should create the device special file that contains the
sector offset (which is the one constant) and create compatibility
symlinks. For example:

	/dev/da0s2.00000000
	/dev/da0s2.0834F7A0
	/dev/da0s5 -> /dev/da0s2.00000000
	/dev/da0s6 -> /dev/da0s2.0834F7A0

The idea is that the logical name (i.e. the symlink) change when
you add or remove a partition, but that all references (i.e. mount
information) are against the fixed name.

In any case: I hope to have something in a few weeks. If you know
of a good way to deal with adding/removing partitions, let me know.

FYI,

-- 
Marcel Moolenaar
xcllnt@mac.com



From rnoland at FreeBSD.org  Mon Feb  2 11:23:12 2009
From: rnoland at FreeBSD.org (Robert Noland)
Date: Mon Feb  2 11:23:21 2009
Subject: X fails on i845 board -  errors found in hardware state
In-Reply-To: <20090202122408.GA97807@mech-cluster238.men.bris.ac.uk>
References: <20090202122408.GA97807@mech-cluster238.men.bris.ac.uk>
Message-ID: <1233602464.1492.21.camel@ferret.2hip.net>

On Mon, 2009-02-02 at 12:24 +0000, Anton Shterenlikht wrote:
> X fails on i845G (or is it i845M ?) board with 
> 
> [skip]
> (WW) intel(0): PRB0_CTL (0x0001f001) indicates ring buffer enabled
> (WW) intel(0): PRB0_HEAD (0x00000024) and PRB0_TAIL (0x00000068) indicate ring b
> uffer not flushed
> (WW) intel(0): Existing errors found in hardware state.
> Error in I830WaitLpRing(), timeout for 2 seconds
> pgetbl_ctl: 0x1ffe0001 getbl_err: 0x00000000
> ipeir: 0x00000000 iphdr: 0x05000000
> LP ring tail: 0x00000068 head: 0x00000024 len: 0x0001f001 start 0x00000000
> eir: 0x0000 esr: 0x0000 emr: 0xff7b
> instdone: 0xffc1 instpm: 0x0000
> memmode: 0x00000000 instps: 0x00000040
> hwstam: 0xffff ier: 0x0000 imr: 0xffff iir: 0x0000
> Ring at virtual 0x28c00000 head 0x24 tail 0x68 count 17 acthd 0x311a8
> Ring at virtual 0x28c00000 head 0x24 tail 0x68 count 17
> [skip]

Does this happen on a fresh boot, or only after X is restarted?

robert.

> Fatal server error:
> lockup
> 
> 
> The details are below. Note that it fails with or without drm.
> I wonder if I should submit a pr.
> 
> many thanks
> anton
> 
> # uname -srm
> FreeBSD 8.0-CURRENT i386
> 
> dmesg fragments
> 
> # dmesg | grep agp
> agp0: <Intel 82845M (845M GMCH) SVGA controller> on vgapci0
> agp0: detected 8060k stolen memory
> agp0: aperture size is 128M
> 
> # dmesg | grep drm
> drm0: <Intel i845G GMCH> on vgapci0
> vgapci0: child drm0 requested pci_enable_busmaster
> info: [drm] AGP at 0xf0000000 128MB
> info: [drm] Initialized i915 1.6.0 20080730
> drm0: [ITHREAD]
> 
> full dmesg
> 
> # dmesg
> 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-CURRENT #0: Mon Feb  2 10:39:04 GMT 2009
>     mexas@mech-Anton240.men.bris.ac.uk:/usr/obj/usr/src/sys/EDGE
> WARNING: WITNESS option enabled, expect reduced performance.
> Timecounter "i8254" frequency 1193182 Hz quality 0
> CPU: Intel(R) Pentium(R) 4 CPU 2.40GHz (2400.10-MHz 686-class CPU)
>   Origin = "GenuineIntel"  Id = 0xf27  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=0x400<CNXT-ID>
> real memory  = 527695872 (503 MB)
> avail memory = 507289600 (483 MB)
> acpi0: <INTEL D845GRG2> on motherboard
> acpi0: [ITHREAD]
> acpi0: Power Button (fixed)
> acpi0: reservation of 0, a0000 (3) failed
> acpi0: reservation of 100000, 1f700000 (3) failed
> Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000
> acpi_timer0: <24-bit timer at 3.579545MHz> port 0x408-0x40b on acpi0
> pcib0: <ACPI Host-PCI bridge> port 0xcf8-0xcff on acpi0
> pci0: <ACPI PCI bus> on pcib0
> vgapci0: <VGA-compatible display> mem 0xf0000000-0xf7ffffff,0xffa80000-0xffafffff irq 11 at device 2.0 on pci0
> agp0: <Intel 82845M (845M GMCH) SVGA controller> on vgapci0
> agp0: detected 8060k stolen memory
> agp0: aperture size is 128M
> drm0: <Intel i845G GMCH> on vgapci0
> vgapci0: child drm0 requested pci_enable_busmaster
> info: [drm] AGP at 0xf0000000 128MB
> info: [drm] Initialized i915 1.6.0 20080730
> uhci0: <Intel 82801DB (ICH4) USB controller USB-A> port 0xe800-0xe81f irq 11 at device 29.0 on pci0
> uhci0: [GIANT-LOCKED]
> uhci0: [ITHREAD]
> usb0: <Intel 82801DB (ICH4) USB controller USB-A> on uhci0
> usb0: USB revision 1.0
> uhub0: <Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1> on usb0
> uhub0: 2 ports with 2 removable, self powered
> uhci1: <Intel 82801DB (ICH4) USB controller USB-B> port 0xe880-0xe89f irq 3 at device 29.1 on pci0
> uhci1: [GIANT-LOCKED]
> uhci1: [ITHREAD]
> usb1: <Intel 82801DB (ICH4) USB controller USB-B> on uhci1
> usb1: USB revision 1.0
> uhub1: <Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1> on usb1
> uhub1: 2 ports with 2 removable, self powered
> uhci2: <Intel 82801DB (ICH4) USB controller USB-C> port 0xec00-0xec1f irq 5 at device 29.2 on pci0
> uhci2: [GIANT-LOCKED]
> uhci2: [ITHREAD]
> usb2: <Intel 82801DB (ICH4) USB controller USB-C> on uhci2
> usb2: USB revision 1.0
> uhub2: <Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1> on usb2
> uhub2: 2 ports with 2 removable, self powered
> ehci0: <Intel 82801DB/L/M (ICH4) USB 2.0 controller> mem 0xffa7fc00-0xffa7ffff irq 9 at device 29.7 on pci0
> ehci0: [GIANT-LOCKED]
> ehci0: [ITHREAD]
> usb3: EHCI version 1.0
> usb3: companion controllers, 2 ports each: usb0 usb1 usb2
> usb3: <Intel 82801DB/L/M (ICH4) USB 2.0 controller> on ehci0
> usb3: USB revision 2.0
> uhub3: <Intel EHCI root hub, class 9/0, rev 2.00/1.00, addr 1> on usb3
> uhub3: 6 ports with 6 removable, self powered
> pcib1: <ACPI PCI-PCI bridge> at device 30.0 on pci0
> pci1: <ACPI PCI bus> on pcib1
> ahc0: <Adaptec 2940 Ultra SCSI adapter> port 0xd800-0xd8ff mem 0xff8ff000-0xff8fffff irq 10 at device 0.0 on pci1
> ahc0: [ITHREAD]
> aic7880: Ultra Wide Channel A, SCSI Id=7, 16/253 SCBs
> fxp0: <Intel 82801DB (ICH4) Pro/100 VE Ethernet> port 0xdc00-0xdc3f mem 0xff8fe000-0xff8fefff irq 11 at device 8.0 on pci1
> miibus0: <MII bus> on fxp0
> inphy0: <i82562ET 10/100 media interface> PHY 1 on miibus0
> inphy0:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
> fxp0: Ethernet address: 00:07:e9:e7:41:dc
> fxp0: [ITHREAD]
> isab0: <PCI-ISA bridge> at device 31.0 on pci0
> isa0: <ISA bus> on isab0
> atapci0: <Intel ICH4 UDMA100 controller> port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xffa0-0xffaf at device 31.1 on pci0
> ata0: <ATA channel 0> on atapci0
> ata0: [ITHREAD]
> ata1: <ATA channel 1> on atapci0
> ata1: [ITHREAD]
> pci0: <serial bus, SMBus> at device 31.3 (no driver attached)
> pci0: <multimedia, audio> at device 31.5 (no driver attached)
> acpi_button0: <Sleep Button> on acpi0
> atrtc0: <AT realtime clock> port 0x70-0x71 irq 8 on acpi0
> fdc0: <floppy drive controller> port 0x3f0-0x3f1,0x3f2-0x3f3,0x3f4-0x3f5,0x3f7 irq 6 drq 2 on acpi0
> fdc0: [FILTER]
> fd0: <1440-KB 3.5" drive> on fdc0 drive 0
> uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0
> uart0: [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, device ID 3
> cpu0: <ACPI CPU> on acpi0
> p4tcc0: <CPU Frequency Thermal Control> on cpu0
> pmtimer0 on isa0
> orm0: <ISA Option ROM> at iomem 0xcb800-0xcbfff 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
> Timecounter "TSC" frequency 2400099084 Hz quality 800
> Timecounters tick every 1.000 msec
> ahc0: Someone reset channel A
> ad0: 76319MB <WDC WD800BB-00CAA1 17.07W17> at ata0-master UDMA100
> acd0: DVDROM <DVD-ROM DDU1621/VER S2.9> at ata1-master UDMA33
> acd1: CDRW <SONY CD-RW CRX210E1/2YS2> at ata1-slave UDMA33
> Waiting 5 seconds for SCSI devices to settle
> (probe0:ahc0:0:0:0): INQUIRY. CDB: 12 0 0 0 24 0 
> (probe1:ahc0:0:1:0): INQUIRY. CDB: 12 0 0 0 24 0 
> (probe2:ahc0:0:2:0): INQUIRY. CDB: 12 0 0 0 24 0 
> (probe3:ahc0:0:3:0): INQUIRY. CDB: 12 0 0 0 24 0 
> (probe4:ahc0:0:4:0): INQUIRY. CDB: 12 0 0 0 24 0 
> (probe5:ahc0:0:5:0): INQUIRY. CDB: 12 0 0 0 24 0 
> (probe6:ahc0:0:6:0): INQUIRY. CDB: 12 0 0 0 24 0 
> (probe7:ahc0:0:8:0): INQUIRY. CDB: 12 0 0 0 24 0 
> (probe8:ahc0:0:9:0): INQUIRY. CDB: 12 0 0 0 24 0 
> (probe9:ahc0:0:10:0): INQUIRY. CDB: 12 0 0 0 24 0 
> (probe10:ahc0:0:11:0): INQUIRY. CDB: 12 0 0 0 24 0 
> (probe11:ahc0:0:12:0): INQUIRY. CDB: 12 0 0 0 24 0 
> (probe12:ahc0:0:13:0): INQUIRY. CDB: 12 0 0 0 24 0 
> (probe13:ahc0:0:14:0): INQUIRY. CDB: 12 0 0 0 24 0 
> (probe14:ahc0:0:15:0): INQUIRY. CDB: 12 0 0 0 24 0 
> GEOM: ad0s1: geometry does not match label (255h,63s != 16h,63s).
> WARNING: WITNESS option enabled, expect reduced performance.
> Trying to mount root from ufs:/dev/ad0s1a
> lock order reversal:
>  1st 0xc2c6d044 user map (user map) @ /usr/src/sys/vm/vm_map.c:3198
>  2nd 0xc2e757ac ufs (ufs) @ /usr/src/sys/kern/vfs_subr.c:2071
> KDB: stack backtrace:
> db_trace_self_wrapper(c081229e,c2a11914,c0608e59,4,c080db0b,...) at db_trace_self_wrapper+0x26
> kdb_backtrace(4,c080db0b,c081bb43,c2c2f0b0,c2a1196c,...) at kdb_backtrace+0x29
> _witness_debugger(c0814ddf,c2e757ac,c0808b46,c2c2f0b0,c081bb43,...) at _witness_debugger+0x21
> witness_checkorder(c2e757ac,1,c081bb43,817,0,...) at witness_checkorder+0x811
> __lockmgr_args(c2e757ac,200501,c2e757c8,0,0,...) at __lockmgr_args+0x226
> ffs_lock(c2a11a7c,c0608c35,c082ecbb,200501,c2e75754,...) at ffs_lock+0x7d
> VOP_LOCK1_APV(c087ae20,c2a11a7c,c2c6ae24,c088b3a0,c2e75754,...) at VOP_LOCK1_APV+0xaf
> _vn_lock(c2e75754,200501,c081bb43,817,4,...) at _vn_lock+0x5e
> vget(c2e75754,200501,c2c6ad80,4b4,0,...) at vget+0xc1
> vnode_pager_lock(c10432e8,0,c082c298,127,c2a11c18,...) at vnode_pager_lock+0x1d3
> vm_fault(c2c6d000,80d6000,2,8,80d6000,...) at vm_fault+0x1e8
> trap_pfault(5,0,c0837eec,2e7,c,...) at trap_pfault+0xf9
> trap(c2a11d38) at trap+0x264
> calltrap() at calltrap+0x6
> --- trap 0xc, eip = 0x80480e5, esp = 0xbfbfeef0, ebp = 0xbfbfef10 ---
> drm0: [ITHREAD]
> pid 1150 (Xorg), uid 0: exited on signal 6 (core dumped)
> pid 1155 (Xorg), uid 0: exited on signal 6 (core dumped)
> 
> Xorg log
> 
> #cat /var/log/Xorg.0.log
> X.Org X Server 1.5.3
> Release Date: 5 November 2008
> X Protocol Version 11, Revision 0
> Build Operating System: FreeBSD 8.0-CURRENT i386 
> Current Operating System: FreeBSD mech-Anton240.men.bris.ac.uk 8.0-CURRENT FreeBSD 8.0-CURRENT #0: Mon Feb  2 10:39:04 GMT 2009     mexas@mech-Anton240.men.bris.ac.uk:/usr/obj/usr/src/sys/EDGE i386
> Build Date: 27 January 2009  05:40:24PM
>  
> 	Before reporting problems, check http://wiki.x.org
> 	to make sure that you have the latest version.
> Markers: (--) probed, (**) from config file, (==) default setting,
> 	(++) from command line, (!!) notice, (II) informational,
> 	(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
> (==) Log file: "/var/log/Xorg.0.log", Time: Mon Feb  2 11:58:09 2009
> (++) Using config file: "/root/xorg.conf.new"
> (==) ServerLayout "X.org Configured"
> (**) |-->Screen "Screen0" (0)
> (**) |   |-->Monitor "Monitor0"
> (**) |   |-->Device "Card0"
> (**) |-->Input Device "Mouse0"
> (**) |-->Input Device "Keyboard0"
> (==) Automatically adding devices
> (==) Automatically enabling devices
> (WW) `fonts.dir' not found (or not valid) in "/usr/local/lib/X11/fonts/100dpi/".
> 	Entry deleted from font path.
> 	(Run 'mkfontdir' on "/usr/local/lib/X11/fonts/100dpi/").
> (==) Including the default font path /usr/local/lib/X11/fonts/misc/,/usr/local/lib/X11/fonts/TTF/,/usr/local/lib/X11/fonts/OTF,/usr/local/lib/X11/fonts/Type1/,/usr/local/lib/X11/fonts/100dpi/,/usr/local/lib/X11/fonts/75dpi/.
> (**) FontPath set to:
> 	/usr/local/lib/X11/fonts/misc/,
> 	/usr/local/lib/X11/fonts/TTF/,
> 	/usr/local/lib/X11/fonts/OTF,
> 	/usr/local/lib/X11/fonts/Type1/,
> 	/usr/local/lib/X11/fonts/75dpi/,
> 	/usr/local/lib/X11/fonts/misc/,
> 	/usr/local/lib/X11/fonts/TTF/,
> 	/usr/local/lib/X11/fonts/OTF,
> 	/usr/local/lib/X11/fonts/Type1/,
> 	/usr/local/lib/X11/fonts/100dpi/,
> 	/usr/local/lib/X11/fonts/75dpi/
> (**) ModulePath set to "/usr/local/lib/xorg/modules"
> (WW) AllowEmptyInput is on, devices using drivers 'kbd' or 'mouse' will be disabled.
> (WW) Disabling Mouse0
> (WW) Disabling Keyboard0
> (II) Loader magic: 0x81b1de0
> (II) Module ABI versions:
> 	X.Org ANSI C Emulation: 0.4
> 	X.Org Video Driver: 4.1
> 	X.Org XInput driver : 2.1
> 	X.Org Server Extension : 1.1
> 	X.Org Font Renderer : 0.6
> (II) Loader running on freebsd
> (--) Using syscons driver with X support (version 2.0)
> (--) using VT number 9
> 
> (--) PCI:*(0@0:2:0) Intel Corporation 82845G/GL[Brookdale-G]/GE Chipset Integrated Graphics Device rev 3, Mem @ 0xf0000000/0, 0xffa80000/0, BIOS @ 0x????????/65536
> (II) System resource ranges:
> 	[0] -1	0	0x00100000 - 0x3fffffff (0x3ff00000) MX[B]E(B)
> 	[1] -1	0	0x000f0000 - 0x000fffff (0x10000) MX[B]
> 	[2] -1	0	0x000c0000 - 0x000effff (0x30000) MX[B]
> 	[3] -1	0	0x00000000 - 0x0009ffff (0xa0000) MX[B]
> 	[4] -1	0	0x0000ffff - 0x0000ffff (0x1) IX[B]
> 	[5] -1	0	0x00000000 - 0x000000ff (0x100) IX[B]
> (II) "extmod" will be loaded. This was enabled by default and also specified in the config file.
> (II) "dbe" will be loaded. This was enabled by default and also specified in the config file.
> (II) "glx" will be loaded. This was enabled by default and also specified in the config file.
> (II) "freetype" will be loaded. This was enabled by default and also specified in the config file.
> (II) "record" will be loaded. This was enabled by default and also specified in the config file.
> (II) "dri" will be loaded. This was enabled by default and also specified in the config file.
> (II) LoadModule: "extmod"
> 
> (II) Loading /usr/local/lib/xorg/modules/extensions//libextmod.so
> (II) Module extmod: vendor="X.Org Foundation"
> 	compiled for 1.5.3, module version = 1.0.0
> 	Module class: X.Org Server Extension
> 	ABI class: X.Org Server Extension, version 1.1
> (II) Loading extension SHAPE
> (II) Loading extension MIT-SUNDRY-NONSTANDARD
> (II) Loading extension BIG-REQUESTS
> (II) Loading extension SYNC
> (II) Loading extension MIT-SCREEN-SAVER
> (II) Loading extension XC-MISC
> (II) Loading extension XFree86-VidModeExtension
> (II) Loading extension XFree86-Misc
> (II) Loading extension XFree86-DGA
> (II) Loading extension DPMS
> (II) Loading extension TOG-CUP
> (II) Loading extension Extended-Visual-Information
> (II) Loading extension XVideo
> (II) Loading extension XVideo-MotionCompensation
> (II) Loading extension X-Resource
> (II) LoadModule: "record"
> 
> (II) Loading /usr/local/lib/xorg/modules/extensions//librecord.so
> (II) Module record: vendor="X.Org Foundation"
> 	compiled for 1.5.3, module version = 1.13.0
> 	Module class: X.Org Server Extension
> 	ABI class: X.Org Server Extension, version 1.1
> (II) Loading extension RECORD
> (II) LoadModule: "dbe"
> 
> (II) Loading /usr/local/lib/xorg/modules/extensions//libdbe.so
> (II) Module dbe: vendor="X.Org Foundation"
> 	compiled for 1.5.3, module version = 1.0.0
> 	Module class: X.Org Server Extension
> 	ABI class: X.Org Server Extension, version 1.1
> (II) Loading extension DOUBLE-BUFFER
> (II) LoadModule: "glx"
> 
> (II) Loading /usr/local/lib/xorg/modules/extensions//libglx.so
> (II) Module glx: vendor="X.Org Foundation"
> 	compiled for 1.5.3, module version = 1.0.0
> 	ABI class: X.Org Server Extension, version 1.1
> (==) AIGLX disabled
> (==) Exporting typical set of GLX visuals
> (II) Loading extension GLX
> (II) LoadModule: "xtrap"
> 
> (II) Loading /usr/local/lib/xorg/modules/extensions//libxtrap.so
> (II) Module xtrap: vendor="X.Org Foundation"
> 	compiled for 1.5.3, module version = 1.0.0
> 	Module class: X.Org Server Extension
> 	ABI class: X.Org Server Extension, version 1.1
> (II) Loading extension DEC-XTRAP
> (II) LoadModule: "dri"
> 
> (II) Loading /usr/local/lib/xorg/modules/extensions//libdri.so
> (II) Module dri: vendor="X.Org Foundation"
> 	compiled for 1.5.3, module version = 1.0.0
> 	ABI class: X.Org Server Extension, version 1.1
> (II) Loading extension XFree86-DRI
> (II) LoadModule: "freetype"
> 
> (II) Loading /usr/local/lib/xorg/modules/fonts//libfreetype.so
> (II) Module freetype: vendor="X.Org Foundation & the After X-TT Project"
> 	compiled for 1.5.3, module version = 2.1.0
> 	Module class: X.Org Font Renderer
> 	ABI class: X.Org Font Renderer, version 0.6
> (II) Loading font FreeType
> (II) LoadModule: "intel"
> 
> (II) Loading /usr/local/lib/xorg/modules/drivers//intel_drv.so
> (II) Module intel: vendor="X.Org Foundation"
> 	compiled for 1.5.3, module version = 2.5.1
> 	Module class: X.Org Video Driver
> 	ABI class: X.Org Video Driver, version 4.1
> (II) intel: Driver for Intel Integrated Graphics Chipsets: i810,
> 	i810-dc100, i810e, i815, i830M, 845G, 852GM/855GM, 865G, 915G,
> 	E7221 (i915), 915GM, 945G, 945GM, 945GME, 965G, G35, 965Q, 946GZ,
> 	965GM, 965GME/GLE, G33, Q35, Q33,
> 	Mobile Intel?? GM45 Express Chipset,
> 	Intel Integrated Graphics Device, G45/G43, Q45/Q43, G41
> (II) Primary Device is: PCI 00@00:02:0
> (II) resource ranges after xf86ClaimFixedResources() call:
> 	[0] -1	0	0x00100000 - 0x3fffffff (0x3ff00000) MX[B]E(B)
> 	[1] -1	0	0x000f0000 - 0x000fffff (0x10000) MX[B]
> 	[2] -1	0	0x000c0000 - 0x000effff (0x30000) MX[B]
> 	[3] -1	0	0x00000000 - 0x0009ffff (0xa0000) MX[B]
> 	[4] -1	0	0x0000ffff - 0x0000ffff (0x1) IX[B]
> 	[5] -1	0	0x00000000 - 0x000000ff (0x100) IX[B]
> (II) resource ranges after probing:
> 	[0] -1	0	0x00100000 - 0x3fffffff (0x3ff00000) MX[B]E(B)
> 	[1] -1	0	0x000f0000 - 0x000fffff (0x10000) MX[B]
> 	[2] -1	0	0x000c0000 - 0x000effff (0x30000) MX[B]
> 	[3] -1	0	0x00000000 - 0x0009ffff (0xa0000) MX[B]
> 	[4] 0	0	0x000a0000 - 0x000affff (0x10000) MS[B]
> 	[5] 0	0	0x000b0000 - 0x000b7fff (0x8000) MS[B]
> 	[6] 0	0	0x000b8000 - 0x000bffff (0x8000) MS[B]
> 	[7] -1	0	0x0000ffff - 0x0000ffff (0x1) IX[B]
> 	[8] -1	0	0x00000000 - 0x000000ff (0x100) IX[B]
> 	[9] 0	0	0x000003b0 - 0x000003bb (0xc) IS[B]
> 	[10] 0	0	0x000003c0 - 0x000003df (0x20) IS[B]
> (II) Loading sub module "vgahw"
> (II) LoadModule: "vgahw"
> 
> (II) Loading /usr/local/lib/xorg/modules//libvgahw.so
> (II) Module vgahw: vendor="X.Org Foundation"
> 	compiled for 1.5.3, module version = 0.1.0
> 	ABI class: X.Org Video Driver, version 4.1
> (==) intel(0): Depth 24, (==) framebuffer bpp 32
> (==) intel(0): RGB weight 888
> (==) intel(0): Default visual is TrueColor
> (II) intel(0): Integrated Graphics Chipset: Intel(R) 845G
> (--) intel(0): Chipset: "845G"
> (--) intel(0): Linear framebuffer at 0xF0000000
> (--) intel(0): IO registers at addr 0xFFA80000
> (==) intel(0): Using EXA for acceleration
> (II) intel(0): 1 display pipe available.
> (II) Loading sub module "ddc"
> (II) LoadModule: "ddc"
> (II) Module "ddc" already built-in
> (II) Loading sub module "i2c"
> (II) LoadModule: "i2c"
> (II) Module "i2c" already built-in
> (II) intel(0): Output VGA using monitor section Monitor0
> (II) intel(0): I2C bus "DVODDC_D" initialized.
> (II) Loading sub module "sil164"
> (II) LoadModule: "sil164"
> 
> (II) Loading /usr/local/lib/xorg/modules/drivers//sil164.so
> (II) Module sil164: vendor="X.Org Foundation"
> 	compiled for 1.5.3, module version = 1.0.0
> 	ABI class: X.Org Video Driver, version 4.1
> (II) intel(0): I2C bus "DVOI2C_E" initialized.
> (II) Loading sub module "ch7xxx"
> (II) LoadModule: "ch7xxx"
> 
> (II) Loading /usr/local/lib/xorg/modules/drivers//ch7xxx.so
> (II) Module ch7xxx: vendor="X.Org Foundation"
> 	compiled for 1.5.3, module version = 1.0.0
> 	ABI class: X.Org Video Driver, version 4.1
> (II) intel(0): I2C bus "DVOI2C_E" removed.
> (II) intel(0): I2C bus "DVOI2C_E" initialized.
> (II) Loading sub module "ivch"
> (II) LoadModule: "ivch"
> 
> (II) Loading /usr/local/lib/xorg/modules/drivers//ivch.so
> (II) Module ivch: vendor="X.Org Foundation"
> 	compiled for 1.5.3, module version = 1.0.0
> 	ABI class: X.Org Video Driver, version 4.1
> (II) intel(0): I2C bus "DVOI2C_E" removed.
> (II) intel(0): I2C bus "DVOI2C_B" initialized.
> (II) Loading sub module "tfp410"
> (II) LoadModule: "tfp410"
> 
> (II) Loading /usr/local/lib/xorg/modules/drivers//tfp410.so
> (II) Module tfp410: vendor="X.Org Foundation"
> 	compiled for 1.5.3, module version = 1.0.0
> 	ABI class: X.Org Video Driver, version 4.1
> (II) intel(0): I2C bus "DVOI2C_B" removed.
> (II) intel(0): I2C bus "DVOI2C_E" initialized.
> (II) Loading sub module "ch7017"
> (II) LoadModule: "ch7017"
> 
> (II) Loading /usr/local/lib/xorg/modules/drivers//ch7017.so
> (II) Module ch7017: vendor="X.Org Foundation"
> 	compiled for 1.5.3, module version = 1.0.0
> 	ABI class: X.Org Video Driver, version 4.1
> (II) intel(0): I2C bus "DVOI2C_E" removed.
> (II) intel(0): I2C bus "DVOI2C_E" initialized.
> (II) intel(0): I2C bus "DVOI2C_E" removed.
> (II) intel(0): I2C bus "DVODDC_D" removed.
> (==) intel(0): Write-combining range (0xa0000,0x10000) was already clear
> (II) intel(0): I2C bus "CRTDDC_A" initialized.
> (II) intel(0): I2C bus "CRTDDC_A" removed.
> (II) intel(0): I2C bus "CRTDDC_A" initialized.
> (II) intel(0): I2C device "CRTDDC_A:ddc2" registered at address 0xA0.
> (II) intel(0): I2C device "CRTDDC_A:ddc2" removed.
> (II) intel(0): I2C bus "CRTDDC_A" removed.
> (II) intel(0): EDID vendor "@@@", prod id 0
> (II) intel(0): Printing DDC gathered Modelines:
> (II) intel(0): Modeline "800x600"x0.0   40.00  800 840 968 1056  600 601 605 628 +hsync +vsync (37.9 kHz)
> (II) intel(0): Modeline "800x600"x0.0   36.00  800 824 896 1024  600 601 603 625 +hsync +vsync (35.2 kHz)
> (II) intel(0): Modeline "640x480"x0.0   31.50  640 656 720 840  480 481 484 500 -hsync -vsync (37.5 kHz)
> (II) intel(0): Modeline "640x480"x0.0   31.50  640 664 704 832  480 489 491 520 -hsync -vsync (37.9 kHz)
> (II) intel(0): Modeline "640x480"x0.0   30.24  640 704 768 864  480 483 486 525 -hsync -vsync (35.0 kHz)
> (II) intel(0): Modeline "640x480"x0.0   25.20  640 656 752 800  480 490 492 525 -hsync -vsync (31.5 kHz)
> (II) intel(0): Modeline "720x400"x0.0   28.32  720 738 846 900  400 412 414 449 -hsync +vsync (31.5 kHz)
> (II) intel(0): Modeline "1024x768"x0.0   78.80  1024 1040 1136 1312  768 769 772 800 +hsync +vsync (60.1 kHz)
> (II) intel(0): Modeline "1024x768"x0.0   75.00  1024 1048 1184 1328  768 771 777 806 -hsync -vsync (56.5 kHz)
> (II) intel(0): Modeline "1024x768"x0.0   65.00  1024 1048 1184 1344  768 771 777 806 -hsync -vsync (48.4 kHz)
> (II) intel(0): Modeline "832x624"x0.0   57.28  832 864 928 1152  624 625 628 667 -hsync -vsync (49.7 kHz)
> (II) intel(0): Modeline "800x600"x0.0   49.50  800 816 896 1056  600 601 604 625 +hsync +vsync (46.9 kHz)
> (II) intel(0): Modeline "800x600"x0.0   50.00  800 856 976 1040  600 637 643 666 +hsync +vsync (48.1 kHz)
> (II) intel(0): EDID vendor "@@@", prod id 0
> (II) intel(0): Output VGA connected
> (II) intel(0): Using fuzzy aspect match for initial modes
> (II) intel(0): Output VGA using initial mode 1280x960
> (==) intel(0): Write-combining range (0xa0000,0x10000) was already clear
> (II) intel(0): detected 128 kB GTT.
> (II) intel(0): detected 8060 kB stolen memory.
> (==) intel(0): video overlay key set to 0x101fe
> (==) intel(0): Intel XvMC decoder disabled
> (==) intel(0): Will not try to enable page flipping
> (==) intel(0): Triple buffering disabled
> (==) intel(0): Using gamma correction (1.0, 1.0, 1.0)
> (**) intel(0): Display dimensions: (300, 230) mm
> (**) intel(0): DPI set to (108, 141)
> (II) Loading sub module "fb"
> (II) LoadModule: "fb"
> 
> (II) Loading /usr/local/lib/xorg/modules//libfb.so
> (II) Module fb: vendor="X.Org Foundation"
> 	compiled for 1.5.3, module version = 1.0.0
> 	ABI class: X.Org ANSI C Emulation, version 0.4
> (II) Loading sub module "exa"
> (II) LoadModule: "exa"
> 
> (II) Loading /usr/local/lib/xorg/modules//libexa.so
> (II) Module exa: vendor="X.Org Foundation"
> 	compiled for 1.5.3, module version = 2.4.0
> 	ABI class: X.Org Video Driver, version 4.1
> (II) Loading sub module "ramdac"
> (II) LoadModule: "ramdac"
> (II) Module "ramdac" already built-in
> (II) intel(0): Comparing regs from server start up to After PreInit
> (==) Depth 24 pixmap format is 32 bpp
> (II) do I need RAC?  No, I don't.
> (II) resource ranges after preInit:
> 	[0] -1	0	0x00100000 - 0x3fffffff (0x3ff00000) MX[B]E(B)
> 	[1] -1	0	0x000f0000 - 0x000fffff (0x10000) MX[B]
> 	[2] -1	0	0x000c0000 - 0x000effff (0x30000) MX[B]
> 	[3] -1	0	0x00000000 - 0x0009ffff (0xa0000) MX[B]
> 	[4] 0	0	0x000a0000 - 0x000affff (0x10000) MS[B](OprD)
> 	[5] 0	0	0x000b0000 - 0x000b7fff (0x8000) MS[B](OprD)
> 	[6] 0	0	0x000b8000 - 0x000bffff (0x8000) MS[B](OprD)
> 	[7] -1	0	0x0000ffff - 0x0000ffff (0x1) IX[B]
> 	[8] -1	0	0x00000000 - 0x000000ff (0x100) IX[B]
> 	[9] 0	0	0x000003b0 - 0x000003bb (0xc) IS[B](OprU)
> 	[10] 0	0	0x000003c0 - 0x000003df (0x20) IS[B](OprU)
> (II) intel(0): Kernel reported 112640 total, 0 used
> (II) intel(0): I830CheckAvailableMemory: 450560 kB available
> drmOpenDevice: node name is /dev/dri/card0
> drmOpenDevice: open result is 11, (OK)
> drmOpenDevice: node name is /dev/dri/card0
> drmOpenDevice: open result is 11, (OK)
> drmOpenByBusid: Searching for BusID pci:0000:00:02.0
> drmOpenDevice: node name is /dev/dri/card0
> drmOpenDevice: open result is 11, (OK)
> drmOpenByBusid: drmOpenMinor returns 11
> drmOpenByBusid: drmGetBusid reports pci:0000:00:02.0
> (II) [drm] DRM interface version 1.2
> (II) [drm] DRM open master succeeded.
> (II) intel(0): [drm] Using the DRM lock SAREA also for drawables.
> (II) intel(0): [drm] framebuffer mapped by ddx driver
> (II) intel(0): [drm] added 1 reserved context for kernel
> (II) intel(0): X context handle = 0x2
> (II) intel(0): [drm] installed DRM signal handler
> (**) intel(0): Framebuffer compression disabled
> (**) intel(0): Tiling enabled
> (==) intel(0): VideoRam: 131072 KB
> (II) intel(0): Attempting memory allocation with tiled buffers.
> (II) intel(0): Tiled allocation successful.
> (II) intel(0): [drm] Registers = 0xffa80000
> (II) intel(0): [drm] ring buffer = 0xf0000000
> (II) intel(0): [drm] mapped front buffer at 0xf1000000, handle = 0xf1000000
> (II) intel(0): [drm] mapped back buffer at 0xf4000000, handle = 0xf4000000
> (II) intel(0): [drm] mapped depth buffer at 0xf5000000, handle = 0xf5000000
> (II) intel(0): [drm] mapped classic textures at 0xf6000000, handle = 0xf6000000
> (II) intel(0): [drm] Initialized kernel agp heap manager, 33554432
> (II) intel(0): [dri] visual configs initialized
> (II) intel(0): Page Flipping disabled
> (II) intel(0): vgaHWGetIOBase: hwp->IOBase is 0x03d0, hwp->PIOOffset is 0x0000
> (==) intel(0): Write-combining range (0xa0000,0x10000) was already clear
> (II) EXA(0): Offscreen pixmap area of 31457280 bytes
> (II) EXA(0): Driver registered support for the following operations:
> (II)         Solid
> (II)         Copy
> (II)         Composite (RENDER acceleration)
> (==) intel(0): Backing store disabled
> (==) intel(0): Silken mouse enabled
> (II) intel(0): Initializing HW Cursor
> (II) intel(0): [DRI] installation complete
> (II) intel(0): xf86BindGARTMemory: bind key 13 at 0x007df000 (pgoffset 2015)
> (II) intel(0): xf86BindGARTMemory: bind key 14 at 0x01000000 (pgoffset 4096)
> (II) intel(0): xf86BindGARTMemory: bind key 15 at 0x02000000 (pgoffset 8192)
> (II) intel(0): xf86BindGARTMemory: bind key 16 at 0x04000000 (pgoffset 16384)
> (II) intel(0): xf86BindGARTMemory: bind key 17 at 0x05000000 (pgoffset 20480)
> (II) intel(0): xf86BindGARTMemory: bind key 18 at 0x06000000 (pgoffset 24576)
> (II) intel(0): Fixed memory allocation layout:
> (II) intel(0): 0x00000000-0x0001ffff: ring buffer (128 kB)
> (II) intel(0): 0x00020000-0x00024fff: HW cursors (20 kB)
> (II) intel(0): 0x00025000-0x0002cfff: logical 3D context (32 kB)
> (II) intel(0): 0x0002d000-0x0012cfff: fake bufmgr (1024 kB)
> (II) intel(0): 0x007df000:            end of stolen memory
> (II) intel(0): 0x007df000-0x007dffff: overlay registers (4 kB, 0x00000000107c6000 physical
> )
> (II) intel(0): 0x01000000-0x01ffffff: front buffer (10240 kB) X tiled
> (II) intel(0): 0x02000000-0x03dfffff: exa offscreen (30720 kB)
> (II) intel(0): 0x04000000-0x04ffffff: back buffer (10240 kB) X tiled
> (II) intel(0): 0x05000000-0x05ffffff: depth buffer (10240 kB) X tiled
> (II) intel(0): 0x06000000-0x07ffffff: classic textures (32768 kB)
> (II) intel(0): 0x08000000:            end of aperture
> (WW) intel(0): PRB0_CTL (0x0001f001) indicates ring buffer enabled
> (WW) intel(0): PRB0_HEAD (0x00000024) and PRB0_TAIL (0x00000068) indicate ring buffer not flushed
> (WW) intel(0): Existing errors found in hardware state.
> Error in I830WaitLpRing(), timeout for 2 seconds
> pgetbl_ctl: 0x1ffe0001 getbl_err: 0x00000000
> ipeir: 0x00000000 iphdr: 0x05000000
> LP ring tail: 0x00000068 head: 0x00000024 len: 0x0001f001 start 0x00000000
> eir: 0x0000 esr: 0x0000 emr: 0xff7b
> instdone: 0xffc1 instpm: 0x0000
> memmode: 0x00000000 instps: 0x00000040
> hwstam: 0xffff ier: 0x0000 imr: 0xffff iir: 0x0000
> Ring at virtual 0x28c00000 head 0x24 tail 0x68 count 17 acthd 0x311a8
> Ring at virtual 0x28c00000 head 0x24 tail 0x68 count 17
> Ring at virtual 0x28c00000 head 0x24 tail 0x68 count 17
> Ring at virtual 0x28c00000 head 0x24 tail 0x68 count 17
> Ring at virtual 0x28c00000 head 0x24 tail 0x68 count 17
> Ring at virtual 0x28c00000 head 0x24 tail 0x68 count 17
> Ring at virtual 0x28c00000 head 0x24 tail 0x68 count 17
> Ring at virtual 0x28c00000 head 0x24 tail 0x68 count 17
> Ring at virtual 0x28c00000 head 0x24 tail 0x68 count 17
> Ring at virtual 0x28c00000 head 0x24 tail 0x68 count 17
> Ring at virtual 0x28c00000 head 0x24 tail 0x68 count 17
> Ring at virtual 0x28c00000 head 0x24 tail 0x68 count 17
> Ring at virtual 0x28c00000 head 0x24 tail 0x68 count 17
> Ring at virtual 0x28c00000 head 0x24 tail 0x68 count 17
> Ring at virtual 0x28c00000 head 0x24 tail 0x68 count 17
> Ring at virtual 0x28c00000 head 0x24 tail 0x68 count 17
> Ring at virtual 0x28c00000 head 0x24 tail 0x68 count 17
> Ring at virtual 0x28c00000 head 0x24 tail 0x68 count 17
> Ring at virtual 0x28c00000 head 0x24 tail 0x68 count 17
> Ring at virtual 0x28c00000 head 0x24 tail 0x68 count 17
> Ring at virtual 0x28c00000 head 0x24 tail 0x68 count 17
> Ring at virtual 0x28c00000 head 0x24 tail 0x68 count 17
> Ring at virtual 0x28c00000 head 0x24 tail 0x68 count 17
> Ring at virtual 0x28c00000 head 0x24 tail 0x68 count 17
> Ring at virtual 0x28c00000 head 0x24 tail 0x68 count 17
> Ring at virtual 0x28c00000 head 0x24 tail 0x68 count 17
> Ring at virtual 0x28c00000 head 0x24 tail 0x68 count 17
> Ring at virtual 0x28c00000 head 0x24 tail 0x68 count 17
> Ring at virtual 0x28c00000 head 0x24 tail 0x68 count 17
> Ring at virtual 0x28c00000 head 0x24 tail 0x68 count 17
> Ring at virtual 0x28c00000 head 0x24 tail 0x68 count 17
> Ring at virtual 0x28c00000 head 0x24 tail 0x68 count 17
> Ring at virtual 0x28c00000 head 0x24 tail 0x68 count 17
> Ring at virtual 0x28c00000 head 0x24 tail 0x68 count 17
> Ring at virtual 0x28c00000 head 0x24 tail 0x68 count 17
> Ring at virtual 0x28c00000 head 0x24 tail 0x68 count 17
> Ring at virtual 0x28c00000 head 0x24 tail 0x68 count 17
> Ring at virtual 0x28c00000 head 0x24 tail 0x68 count 17
> Ring at virtual 0x28c00000 head 0x24 tail 0x68 count 17
> Ring at virtual 0x28c00000 head 0x24 tail 0x68 count 17
> Ring at virtual 0x28c00000 head 0x24 tail 0x68 count 17
> Ring at virtual 0x28c00000 head 0x24 tail 0x68 count 17
> Ring at virtual 0x28c00000 head 0x24 tail 0x68 count 17
> Ring at virtual 0x28c00000 head 0x24 tail 0x68 count 17
> Ring at virtual 0x28c00000 head 0x24 tail 0x68 count 17
> Ring at virtual 0x28c00000 head 0x24 tail 0x68 count 17
> Ring at virtual 0x28c00000 head 0x24 tail 0x68 count 17
> Ring at virtual 0x28c00000 head 0x24 tail 0x68 count 17
> Ring at virtual 0x28c00000 head 0x24 tail 0x68 count 17
> Ring at virtual 0x28c00000 head 0x24 tail 0x68 count 17
> Ring at virtual 0x28c00000 head 0x24 tail 0x68 count 17
> Ring at virtual 0x28c00000 head 0x24 tail 0x68 count 17
> Ring at virtual 0x28c00000 head 0x24 tail 0x68 count 17
> Ring at virtual 0x28c00000 head 0x24 tail 0x68 count 17
> Ring at virtual 0x28c00000 head 0x24 tail 0x68 count 17
> Ring at virtual 0x28c00000 head 0x24 tail 0x68 count 17
> Ring at virtual 0x28c00000 head 0x24 tail 0x68 count 17
> Ring at virtual 0x28c00000 head 0x24 tail 0x68 count 17
> Ring at virtual 0x28c00000 head 0x24 tail 0x68 count 17
> Ring at virtual 0x28c00000 head 0x24 tail 0x68 count 17
> Ring at virtual 0x28c00000 head 0x24 tail 0x68 count 17
> Ring at virtual 0x28c00000 head 0x24 tail 0x68 count 17
> Ring at virtual 0x28c00000 head 0x24 tail 0x68 count 17
> Ring at virtual 0x28c00000 head 0x24 tail 0x68 count 17
> Ring at virtual 0x28c00000 head 0x24 tail 0x68 count 17
> Ring end
> space: 130996 wanted 131064
> (II) intel(0): [drm] removed 1 reserved context for kernel
> (II) intel(0): [drm] unmapping 8192 bytes of SAREA 0xc325a000 at 0x286e0000
> (II) intel(0): [drm] Closed DRM master.
> 
> Fatal server error:
> lockup
> 
> _fence_emit_internal: drm_i915_irq_emit: -9

-- 
Robert Noland <rnoland@FreeBSD.org>
FreeBSD
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: This is a digitally signed message part
Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20090202/bad5e5a9/attachment.pgp
From christoph.mallon at gmx.de  Mon Feb  2 11:42:43 2009
From: christoph.mallon at gmx.de (Christoph Mallon)
Date: Mon Feb  2 11:42:55 2009
Subject: write-only variables in src/sys/ - possible bugs
Message-ID: <49874CA8.5090605@gmx.de>

Hi,

I compiled a list of all local variables in src/sys/ (r188000), which 
are only written to, but never read. This is more than the GCC warning, 
which only complains about variables, which are only declared (and maybe 
initialised) and not used otherwise. In contrast this list contains 
variables with the following usage pattern:

int w = 42; // GCC warns about this ...
int x;      // ... but not this
x = 23;
x++;
return 0;

The list contains about 700 entries. About three dozen concern variables 
named 'error'. Here's one *example* from the list:

	sys/dev/kbdmux/kbdmux.c:1304

In the function kbdmux_modevent() the variable 'error' is assigned 
values eight times, but at the end of the function there is just a 
return 0; and the variable is never read. Probably the value should be 
returned.

You can find the list here:
	http://tron.homeunix.org/unread_variables.log

The list was generated by cparser, a C99 compiler, which uses libFIRM 
for optimisation and code generation (lang/cparser in the ports).


A small disclaimer: There might be some false positives due to errors
which are caused by HEAD sources in combination with my installed 7.x
headers plus a hacked up build process. Also some warnings are the 
result from variables, which are only used in debug macros, so td = 
curthread; KASSERT(td != NULL); provokes a warning (I consider this bad 
style). Nonetheless the number of false positives should be low. If 
there is interest, then I can compile a "proper" list.
From dimitry at andric.com  Mon Feb  2 11:46:22 2009
From: dimitry at andric.com (Dimitry Andric)
Date: Mon Feb  2 11:46:30 2009
Subject: GEOM_PART: a quick update on logical partitions
In-Reply-To: <FCA8C5E4-BC41-4711-9EBC-CD692144F6B8@mac.com>
References: <FCA8C5E4-BC41-4711-9EBC-CD692144F6B8@mac.com>
Message-ID: <49874922.5050309@andric.com>

On 2009-02-02 20:16, Marcel Moolenaar wrote:
> In case people are wondering: I'm working on proper support for
> logical partitions. This should also allow us to create and
> modify them. Of course when you add or remove a partition, the
> index changes and consequently the device name. I still need
> to find a good solution for that. Currently I'm thinking that
> we should create the device special file that contains the
> sector offset (which is the one constant) and create compatibility
> symlinks. For example:
> 
> 	/dev/da0s2.00000000
> 	/dev/da0s2.0834F7A0
> 	/dev/da0s5 -> /dev/da0s2.00000000
> 	/dev/da0s6 -> /dev/da0s2.0834F7A0
> 
> The idea is that the logical name (i.e. the symlink) change when
> you add or remove a partition, but that all references (i.e. mount
> information) are against the fixed name.

This sector-based ID is a creative approach. :)  In Linux, they just
assign a GUID to each unique partition (or actually, filesystem), and
you can use that to mount it.  It doesn't matter anymore whether you
shift partitions around then...

OTOH, this gives ugly fstabs like:

UUID=cf3de368-9729-4399-b612-2b62f4e98930  /  ext3  relatime,errors=remount-ro  0  1

Also, you need a place to put the GUID, and there may not be room for
this in the filesystem and/or partition.
From freebsd at abv.bg  Mon Feb  2 11:55:13 2009
From: freebsd at abv.bg (Mario Pavlov)
Date: Mon Feb  2 11:55:23 2009
Subject: panic caused by mpd5
Message-ID: <596910996.25499.1233604506708.JavaMail.apache@mail54.abv.bg>

Hi,
my system panics if I use mpd5...
here's what I got:

----------------------------------------------------------------------------------------
FreeBSD mydomain.org 8.0-CURRENT FreeBSD 8.0-CURRENT #6: Mon Feb 2 19:08:09 EET 2009 myuser@mydomain.org:/usr/obj/usr/src/sys/Ss-CURRENT amd64

mpd-5.2 Multi-link PPP daemon based on netgraph(4)
----------------------------------------------------------------------------------------

my mpd.conf is very simple

=========================================================================================
startup:

default:
load pptp_server

pptp_server:

set ippool add pool1 192.168.10.50 192.168.10.99

create bundle template B
set iface enable proxy-arp
set iface idle 1800
set iface enable tcpmssfix
set ipcp yes vjcomp
set ipcp ranges 192.168.10.1/32 ippool pool1
set ipcp dns 192.168.10.1
set bundle enable compression
set ccp yes mppc
set mppc yes e40
set mppc yes e128
set mppc yes stateless

create link template L pptp
set link action bundle B
set link enable multilink
set link yes acfcomp protocomp
set link no pap chap
set link enable chap
set link keep-alive 10 60
set link mtu 1460
set pptp self my.external.ip.address
set link enable incoming
=========================================================================================

the idea behind this setup is my machine to work as a simple VPN server
I'm able to start mpd and everything seems to work...but as soon as I connect with a VPN client the system panics

please find attached screenshots of the panic and the trace

I'll be grateful if someone can help...I kind of need that working

thank you

regards
MGP
From thompsa at FreeBSD.org  Mon Feb  2 11:58:16 2009
From: thompsa at FreeBSD.org (Andrew Thompson)
Date: Mon Feb  2 11:58:23 2009
Subject: write-only variables in src/sys/ - possible bugs
In-Reply-To: <49874CA8.5090605@gmx.de>
References: <49874CA8.5090605@gmx.de>
Message-ID: <20090202195809.GA54528@citylink.fud.org.nz>

On Mon, Feb 02, 2009 at 08:42:32PM +0100, Christoph Mallon wrote:
> Hi,
> 
> I compiled a list of all local variables in src/sys/ (r188000), which are 
> only written to, but never read. This is more than the GCC warning, which 
> only complains about variables, which are only declared (and maybe 
> initialised) and not used otherwise. In contrast this list contains 
> variables with the following usage pattern:
> 
> int w = 42; // GCC warns about this ...
> int x;      // ... but not this
> x = 23;
> x++;
> return 0;
> 
> The list contains about 700 entries. About three dozen concern variables 
> named 'error'. Here's one *example* from the list:
> 
> 	sys/dev/kbdmux/kbdmux.c:1304
> 
> In the function kbdmux_modevent() the variable 'error' is assigned values 
> eight times, but at the end of the function there is just a return 0; and 
> the variable is never read. Probably the value should be returned.
> 
> You can find the list here:
> 	http://tron.homeunix.org/unread_variables.log
> 
> The list was generated by cparser, a C99 compiler, which uses libFIRM for 
> optimisation and code generation (lang/cparser in the ports).

This is helpful, my only nit would be to run it through sort. :)

Andrew
From christoph.mallon at gmx.de  Mon Feb  2 12:07:51 2009
From: christoph.mallon at gmx.de (Christoph Mallon)
Date: Mon Feb  2 12:08:00 2009
Subject: write-only variables in src/sys/ - possible bugs
In-Reply-To: <20090202195809.GA54528@citylink.fud.org.nz>
References: <49874CA8.5090605@gmx.de>
	<20090202195809.GA54528@citylink.fud.org.nz>
Message-ID: <49875293.4050909@gmx.de>

Andrew Thompson schrieb:
> This is helpful, my only nit would be to run it through sort. :)

Fixed (:
From freebsd at abv.bg  Mon Feb  2 12:09:23 2009
From: freebsd at abv.bg (Mario Pavlov)
Date: Mon Feb  2 12:09:35 2009
Subject: panic caused by mpd5
Message-ID: <256773966.25793.1233605357802.JavaMail.apache@mail54.abv.bg>




I'm sorry, looks like that attachments got lost somewhere...
here are links to them:
http://e-soul.org/~mgp/tmp/panic.gif
http://e-soul.org/~mgp/tmp/trace.gif

 >Hi,
 >my system panics if I use mpd5...
 >here's what I got:
 >
 >----------------------------------------------------------------------------------------
 >FreeBSD mydomain.org 8.0-CURRENT FreeBSD 8.0-CURRENT #6: Mon Feb 2 19:08:09 EET 2009 myuser@mydomain.org:/usr/obj/usr/src/sys/Ss-CURRENT amd64
 >
 >mpd-5.2 Multi-link PPP daemon based on netgraph(4)
 >----------------------------------------------------------------------------------------
 >
 >my mpd.conf is very simple
 >
 >=========================================================================================
 >startup:
 >
 >default:
 >load pptp_server
 >
 >pptp_server:
 >
 >set ippool add pool1 192.168.10.50 192.168.10.99
 >
 >create bundle template B
 >set iface enable proxy-arp
 >set iface idle 1800
 >set iface enable tcpmssfix
 >set ipcp yes vjcomp
 >set ipcp ranges 192.168.10.1/32 ippool pool1
 >set ipcp dns 192.168.10.1
 >set bundle enable compression
 >set ccp yes mppc
 >set mppc yes e40
 >set mppc yes e128
 >set mppc yes stateless
 >
 >create link template L pptp
 >set link action bundle B
 >set link enable multilink
 >set link yes acfcomp protocomp
 >set link no pap chap
 >set link enable chap
 >set link keep-alive 10 60
 >set link mtu 1460
 >set pptp self my.external.ip.address
 >set link enable incoming
 >=========================================================================================
 >
 >the idea behind this setup is my machine to work as a simple VPN server
 >I'm able to start mpd and everything seems to work...but as soon as I connect with a VPN client the system panics
 >
 >please find attached screenshots of the panic and the trace
 >
 >I'll be grateful if someone can help...I kind of need that working
 >
 >thank you
 >
 >regards
 >MGP
 >
From lme at FreeBSD.org  Mon Feb  2 12:21:16 2009
From: lme at FreeBSD.org (Lars Engels)
Date: Mon Feb  2 12:21:23 2009
Subject: ath cannot find my wireless network any more
In-Reply-To: <4986218F.5060408@freebsd.org>
References: <20090129192241.GZ60948@e.0x20.net>
	<20090129192830.GE73709@citylink.fud.org.nz>
	<20090129194826.GA60948@e.0x20.net> <49820EAC.5090400@freebsd.org>
	<20090129204323.GB60948@e.0x20.net>
	<3a142e750901291328w537b2070t216e393a0fd5b8ba@mail.gmail.com>
	<20090129215424.GC60948@e.0x20.net> <49853423.9050208@freebsd.org>
	<20090201095721.GE60948@e.0x20.net> <4986218F.5060408@freebsd.org>
Message-ID: <20090202202114.GA30761@e.0x20.net>

On Sun, Feb 01, 2009 at 02:26:23PM -0800, Sam Leffler wrote:

> Should be fixed by r187991.

Yes, the device can now find my network again.

Thank you, Sam!

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/20090202/0bd7a39b/attachment.pgp
From max at love2party.net  Mon Feb  2 12:47:32 2009
From: max at love2party.net (Max Laier)
Date: Mon Feb  2 12:47:46 2009
Subject: write-only variables in src/sys/ - possible bugs
In-Reply-To: <49874CA8.5090605@gmx.de>
References: <49874CA8.5090605@gmx.de>
Message-ID: <200902022147.22862.max@love2party.net>

On Monday 02 February 2009 20:42:32 Christoph Mallon wrote:
> Hi,
>
> I compiled a list of all local variables in src/sys/ (r188000), which
> are only written to, but never read. This is more than the GCC warning,
> which only complains about variables, which are only declared (and maybe
> initialised) and not used otherwise. In contrast this list contains
> variables with the following usage pattern:
>
> int w = 42; // GCC warns about this ...
> int x;      // ... but not this
> x = 23;
> x++;
> return 0;
>
> The list contains about 700 entries. About three dozen concern variables
> named 'error'. Here's one *example* from the list:
>
> 	sys/dev/kbdmux/kbdmux.c:1304
>
> In the function kbdmux_modevent() the variable 'error' is assigned
> values eight times, but at the end of the function there is just a
> return 0; and the variable is never read. Probably the value should be
> returned.
>
> You can find the list here:
> 	http://tron.homeunix.org/unread_variables.log
>
> The list was generated by cparser, a C99 compiler, which uses libFIRM
> for optimisation and code generation (lang/cparser in the ports).
>
>
> A small disclaimer: There might be some false positives due to errors
> which are caused by HEAD sources in combination with my installed 7.x
> headers plus a hacked up build process. Also some warnings are the
> result from variables, which are only used in debug macros, so td =
> curthread; KASSERT(td != NULL); provokes a warning (I consider this bad
> style). Nonetheless the number of false positives should be low. If
> there is interest, then I can compile a "proper" list.

Are you interested in false positive reports?  If so, I think 
sys/contrib/pf/net/pf.c:2931 is one.  Seems cparser is confused by the union 
in struct assignment, maybe?  Or it suffers from the similar issue with 
switch/case-statements as gcc.  saddr is read from in all but the default 
case.

-- 
/"\  Best regards,                      | mlaier@freebsd.org
\ /  Max Laier                          | ICQ #67774661
 X   http://pf4freebsd.love2party.net/  | mlaier@EFnet
/ \  ASCII Ribbon Campaign              | Against HTML Mail and News
From bzeeb-lists at lists.zabbadoz.net  Mon Feb  2 12:50:32 2009
From: bzeeb-lists at lists.zabbadoz.net (Bjoern A. Zeeb)
Date: Mon Feb  2 12:50:41 2009
Subject: panic caused by mpd5
In-Reply-To: <256773966.25793.1233605357802.JavaMail.apache@mail54.abv.bg>
References: <256773966.25793.1233605357802.JavaMail.apache@mail54.abv.bg>
Message-ID: <20090202204630.M93725@maildrop.int.zabbadoz.net>

On Mon, 2 Feb 2009, Mario Pavlov wrote:

> I'm sorry, looks like that attachments got lost somewhere...
> here are links to them:
> http://e-soul.org/~mgp/tmp/panic.gif

Not much information but I assume that this should have been fixed
with r187946.

/bz

-- 
Bjoern A. Zeeb                      The greatest risk is not taking one.
From christoph.mallon at gmx.de  Mon Feb  2 12:56:56 2009
From: christoph.mallon at gmx.de (Christoph Mallon)
Date: Mon Feb  2 12:57:07 2009
Subject: write-only variables in src/sys/ - possible bugs
In-Reply-To: <200902022147.22862.max@love2party.net>
References: <49874CA8.5090605@gmx.de> <200902022147.22862.max@love2party.net>
Message-ID: <49875E0A.5070209@gmx.de>

Max Laier schrieb:
> On Monday 02 February 2009 20:42:32 Christoph Mallon wrote:
>> A small disclaimer: There might be some false positives due to errors
>> which are caused by HEAD sources in combination with my installed 7.x
>> headers plus a hacked up build process. Also some warnings are the
>> result from variables, which are only used in debug macros, so td =
>> curthread; KASSERT(td != NULL); provokes a warning (I consider this bad
>> style). Nonetheless the number of false positives should be low. If
>> there is interest, then I can compile a "proper" list.
> 
> Are you interested in false positive reports?  If so, I think 
> sys/contrib/pf/net/pf.c:2931 is one.  Seems cparser is confused by the union 
> in struct assignment, maybe?  Or it suffers from the similar issue with 
> switch/case-statements as gcc.  saddr is read from in all but the default 
> case.

When neither INET nor INET6 is set, daddr and saddr are only written to. 
  So this part should be enclosed in #if defined INET || defined INET6. 
Probably this file is not compiled at all, when neither INET nor INET6 
are set, so this is certainly the result of the "hacked up build 
process"-part, sorry.
From rizzo at iet.unipi.it  Mon Feb  2 13:14:42 2009
From: rizzo at iet.unipi.it (Luigi Rizzo)
Date: Mon Feb  2 13:14:55 2009
Subject: write-only variables in src/sys/ - possible bugs
In-Reply-To: <49874CA8.5090605@gmx.de>
References: <49874CA8.5090605@gmx.de>
Message-ID: <20090202210345.GD20288@onelab2.iet.unipi.it>

On Mon, Feb 02, 2009 at 08:42:32PM +0100, Christoph Mallon wrote:
> Hi,
> 
> I compiled a list of all local variables in src/sys/ (r188000), which 
> are only written to, but never read. This is more than the GCC warning, 

interesting list, thanks.
Also, 700 entries is not a bad result considering the size
of the codebase and the age of parts of it (i am pretty sure
there is a lot of code 15+ years old which received little
if any mainteinance or use in the past decade).
(and i have nothing against old code except that compilers,
coding practices and the amount of peer review have improved
a lot over time, and so -- with some exceptions -- it is
easier to prevent some of these issues with more recent code).

cheers
luigi
From joao.barros at gmail.com  Mon Feb  2 13:34:03 2009
From: joao.barros at gmail.com (=?ISO-8859-1?Q?Jo=E3o_Barros?=)
Date: Mon Feb  2 13:34:10 2009
Subject: GEOM_PART: a quick update on logical partitions
In-Reply-To: <49874922.5050309@andric.com>
References: <FCA8C5E4-BC41-4711-9EBC-CD692144F6B8@mac.com>
	<49874922.5050309@andric.com>
Message-ID: <70e8236f0902021323h5ceb50c8m58f32b655e8c57b5@mail.gmail.com>

On Mon, Feb 2, 2009 at 7:27 PM, Dimitry Andric <dimitry@andric.com> wrote:
> On 2009-02-02 20:16, Marcel Moolenaar wrote:
>> In case people are wondering: I'm working on proper support for
>> logical partitions. This should also allow us to create and
>> modify them. Of course when you add or remove a partition, the
>> index changes and consequently the device name. I still need
>> to find a good solution for that. Currently I'm thinking that
>> we should create the device special file that contains the
>> sector offset (which is the one constant) and create compatibility

This approach assumes you'll only add/remove partitions, not move
and/or resize them.
Let's go big and assume all possibilities.

>> symlinks. For example:
>>
>>       /dev/da0s2.00000000
>>       /dev/da0s2.0834F7A0
>>       /dev/da0s5 -> /dev/da0s2.00000000
>>       /dev/da0s6 -> /dev/da0s2.0834F7A0
>>
>> The idea is that the logical name (i.e. the symlink) change when
>> you add or remove a partition, but that all references (i.e. mount
>> information) are against the fixed name.
>
> This sector-based ID is a creative approach. :)  In Linux, they just
> assign a GUID to each unique partition (or actually, filesystem), and
> you can use that to mount it.  It doesn't matter anymore whether you
> shift partitions around then...

...shift partitions or controllers. Being controller agnostic is the
way to go. Being able to duplicate my OSX partition from the internal
sata to an external usb or firewire disk and booting from it on my mac
without any modifications whatsoever to the system: priceless. This
would be a step closer in that direction.
I'd go UUID :)

>
> OTOH, this gives ugly fstabs like:

I can live with an ugly fstab, but can't live with an unbootable system ;)

>
> UUID=cf3de368-9729-4399-b612-2b62f4e98930  /  ext3  relatime,errors=remount-ro  0  1
>
> Also, you need a place to put the GUID, and there may not be room for
> this in the filesystem and/or partition.



-- 
Joao Barros
From maksim.yevmenkin at gmail.com  Mon Feb  2 13:35:46 2009
From: maksim.yevmenkin at gmail.com (Maksim Yevmenkin)
Date: Mon Feb  2 13:35:52 2009
Subject: write-only variables in src/sys/ - possible bugs
In-Reply-To: <49874CA8.5090605@gmx.de>
References: <49874CA8.5090605@gmx.de>
Message-ID: <bb4a86c70902021335i4b3741a0h212fd64d47506f32@mail.gmail.com>

On Mon, Feb 2, 2009 at 11:42 AM, Christoph Mallon
<christoph.mallon@gmx.de> wrote:
> Hi,
>
> I compiled a list of all local variables in src/sys/ (r188000), which are
> only written to, but never read. This is more than the GCC warning, which
> only complains about variables, which are only declared (and maybe
> initialised) and not used otherwise. In contrast this list contains
> variables with the following usage pattern:
>
> int w = 42; // GCC warns about this ...
> int x;      // ... but not this
> x = 23;
> x++;
> return 0;
>
> The list contains about 700 entries. About three dozen concern variables
> named 'error'. Here's one *example* from the list:
>
>        sys/dev/kbdmux/kbdmux.c:1304
>
> In the function kbdmux_modevent() the variable 'error' is assigned values
> eight times, but at the end of the function there is just a return 0; and
> the variable is never read. Probably the value should be returned.

fixed. thanks for reporting!

thanks,
max
From xcllnt at mac.com  Mon Feb  2 13:50:41 2009
From: xcllnt at mac.com (Marcel Moolenaar)
Date: Mon Feb  2 13:50:48 2009
Subject: GEOM_PART: a quick update on logical partitions
In-Reply-To: <70e8236f0902021323h5ceb50c8m58f32b655e8c57b5@mail.gmail.com>
References: <FCA8C5E4-BC41-4711-9EBC-CD692144F6B8@mac.com>
	<49874922.5050309@andric.com>
	<70e8236f0902021323h5ceb50c8m58f32b655e8c57b5@mail.gmail.com>
Message-ID: <949A33EE-8F97-47A4-8D66-656CC502730C@mac.com>


On Feb 2, 2009, at 1:23 PM, Jo?o Barros wrote:

> On Mon, Feb 2, 2009 at 7:27 PM, Dimitry Andric <dimitry@andric.com>  
> wrote:
>> On 2009-02-02 20:16, Marcel Moolenaar wrote:
>>> In case people are wondering: I'm working on proper support for
>>> logical partitions. This should also allow us to create and
>>> modify them. Of course when you add or remove a partition, the
>>> index changes and consequently the device name. I still need
>>> to find a good solution for that. Currently I'm thinking that
>>> we should create the device special file that contains the
>>> sector offset (which is the one constant) and create compatibility
>
> This approach assumes you'll only add/remove partitions, not move
> and/or resize them.
> Let's go big and assume all possibilities.

Resizing is no problem but moving is, yes.

With logical partitions you won't be able to move while
the partition is mounted, something that you can support
for other partitioning schemes. The question is:
Is it acceptable to have limited support for moving
logical partitions?

I think it is. They're a kluge to begin with...

-- 
Marcel Moolenaar
xcllnt@mac.com



From phk at phk.freebsd.dk  Mon Feb  2 14:26:06 2009
From: phk at phk.freebsd.dk (Poul-Henning Kamp)
Date: Mon Feb  2 14:26:13 2009
Subject: write-only variables in src/sys/ - possible bugs 
In-Reply-To: Your message of "Mon, 02 Feb 2009 20:42:32 +0100."
	<49874CA8.5090605@gmx.de> 
Message-ID: <7342.1233613563@critter.freebsd.dk>

In message <49874CA8.5090605@gmx.de>, Christoph Mallon writes:

>I compiled a list of all local variables in src/sys/ (r188000), which 
>are only written to, but never read.

Bravo!

-- 
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 beech at freebsd.org  Mon Feb  2 14:27:28 2009
From: beech at freebsd.org (Beech Rintoul)
Date: Mon Feb  2 14:27:34 2009
Subject: lpt stopped working
In-Reply-To: <200902021643.39862.c47g@gmx.at>
References: <200902021643.39862.c47g@gmx.at>
Message-ID: <200902021307.56403.beech@freebsd.org>

On Monday 02 February 2009 06:43:39 Christian Gusenbauer wrote:
> Hi!
>
> Since the recent update (svn r187576) to the ppbus/ppc code my printer
> stopped working. Every request seems to hang forever in ppb_request_bus
> waiting for ppb->ppc_lock (at least 'top' tells me that it's hanging in
> state 'ppbreq').
>
> Any clues?
>
> Many thanks,
> Christian.

I wonder if this is the same issue I reported on questions that lpt0 now just 
reports "device busy"?

Beech
-- 
---------------------------------------------------------------------------------------
Beech Rintoul - FreeBSD Developer - beech@FreeBSD.org
/"\   ASCII Ribbon Campaign  | FreeBSD Since 4.x
\ / - NO HTML/RTF in e-mail   | http://people.freebsd.org/~beech
 X  - NO Word docs in e-mail | Skype: akbeech
/ \  - http://www.FreeBSD.org/releases/7.1R/announce.html
---------------------------------------------------------------------------------------




From chet.ramey at case.edu  Mon Feb  2 14:06:54 2009
From: chet.ramey at case.edu (Chet Ramey)
Date: Mon Feb  2 14:30:57 2009
Subject: GNU readline (was Re: Alternatives to gcc)
In-Reply-To: Message from giffunip@tutopia.com of Mon,
	02 Feb 2009 09:47:28 -0800 (PST) (id
	<160891.1210.qm@web32701.mail.mud.yahoo.com>)
References: <160891.1210.qm@web32701.mail.mud.yahoo.com>
Message-ID: <090202220611.AA95416.SM@caleb.INS.CWRU.Edu>

> Why go into all this trouble? GNU readline is part of an evil plot:

Yes, I've often thought so.

-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer

Chet Ramey, ITS, CWRU    chet@case.edu    http://tiswww.tis.case.edu/~chet/
From tinderbox at freebsd.org  Mon Feb  2 14:51:03 2009
From: tinderbox at freebsd.org (FreeBSD Tinderbox)
Date: Mon Feb  2 14:51:16 2009
Subject: [head tinderbox] failure on i386/pc98
Message-ID: <20090202225058.C57507302F@freebsd-current.sentex.ca>

TB --- 2009-02-02 21:31:51 - tinderbox 2.6 running on freebsd-current.sentex.ca
TB --- 2009-02-02 21:31:51 - starting HEAD tinderbox run for i386/pc98
TB --- 2009-02-02 21:31:51 - cleaning the object tree
TB --- 2009-02-02 21:32:22 - cvsupping the source tree
TB --- 2009-02-02 21:32:22 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/i386/pc98/supfile
TB --- 2009-02-02 21:32:30 - building world
TB --- 2009-02-02 21:32:30 - MAKEOBJDIRPREFIX=/obj
TB --- 2009-02-02 21:32:30 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2009-02-02 21:32:30 - TARGET=pc98
TB --- 2009-02-02 21:32:30 - TARGET_ARCH=i386
TB --- 2009-02-02 21:32:30 - TZ=UTC
TB --- 2009-02-02 21:32:30 - __MAKE_CONF=/dev/null
TB --- 2009-02-02 21:32:30 - cd /src
TB --- 2009-02-02 21:32:30 - /usr/bin/make -B buildworld
>>> World build started on Mon Feb  2 21:32:32 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/usr.sbin/ntp/doc/ntptrace.8 > ntptrace.8.gz
===> usr.sbin/pciconf (all)
cc -O2 -pipe  -I/src/usr.sbin/pciconf/../../sys -fstack-protector  -c /src/usr.sbin/pciconf/pciconf.c
/src/usr.sbin/pciconf/pciconf.c: In function 'list_bars':
/src/usr.sbin/pciconf/pciconf.c:236: error: storage size of 'bar' isn't known
/src/usr.sbin/pciconf/pciconf.c:258: error: 'PCIOCGETBAR' undeclared (first use in this function)
/src/usr.sbin/pciconf/pciconf.c:258: error: (Each undeclared identifier is reported only once
/src/usr.sbin/pciconf/pciconf.c:258: error: for each function it appears in.)
*** Error code 1

Stop in /src/usr.sbin/pciconf.
*** Error code 1

Stop in /src/usr.sbin.
*** Error code 1

Stop in /src.
*** Error code 1

Stop in /src.
*** Error code 1

Stop in /src.
TB --- 2009-02-02 22:50:58 - WARNING: /usr/bin/make returned exit code  1 
TB --- 2009-02-02 22:50:58 - ERROR: failed to build world
TB --- 2009-02-02 22:50:58 - 3736.81 user 363.91 system 4746.79 real


http://tinderbox.des.no/tinderbox-head-HEAD-i386-pc98.full
From rohit.x.tripathi at jpmchase.com  Mon Feb  2 15:31:13 2009
From: rohit.x.tripathi at jpmchase.com (rohit.x.tripathi@jpmchase.com)
Date: Mon Feb  2 15:31:22 2009
Subject: GEOM_PART: a quick update on logical partitions
In-Reply-To: <949A33EE-8F97-47A4-8D66-656CC502730C@mac.com>
Message-ID: <OF1D4864D5.DFCBD22E-ON85257551.007B5B99-85257551.007C00DC@jpmchase.com>

> Is it acceptable to have limited support for moving
> logical partitions?

> I think it is. They're a kluge to begin with...

My 0.02% of 0.02, successful evolution is usually short-sighted (an 
excellent example is the human eye...)

>Let's go big and assume all possibilities.

A great idea, but keep in mind that the best design isn't always the most 
successful.


------------
p.s. please forgive the disclaimer this email is infected with

-----------------------------------------
This communication is for informational purposes only. It is not
intended as an offer or solicitation for the purchase or sale of
any financial instrument or as an official confirmation of any
transaction. All market prices, data and other information are not
warranted as to completeness or accuracy and are subject to change
without notice. Any comments or statements made herein do not
necessarily reflect those of JPMorgan Chase & Co., its subsidiaries
and affiliates.

This transmission may contain information that is privileged,
confidential, legally privileged, and/or exempt from disclosure
under applicable law. If you are not the intended recipient, you
are hereby notified that any disclosure, copying, distribution, or
use of the information contained herein (including any reliance
thereon) is STRICTLY PROHIBITED. Although this transmission and any
attachments are believed to be free of any virus or other defect
that might affect any computer system into which it is received and
opened, it is the responsibility of the recipient to ensure that it
is virus free and no responsibility is accepted by JPMorgan Chase &
Co., its subsidiaries and affiliates, as applicable, for any loss
or damage arising in any way from its use. If you received this
transmission in error, please immediately contact the sender and
destroy the material in its entirety, whether in electronic or hard
copy format. Thank you.

Please refer to http://www.jpmorgan.com/pages/disclosures for
disclosures relating to UK legal entities.
From tinderbox at freebsd.org  Mon Feb  2 15:54:18 2009
From: tinderbox at freebsd.org (FreeBSD Tinderbox)
Date: Mon Feb  2 15:54:36 2009
Subject: [head tinderbox] failure on ia64/ia64
Message-ID: <20090202235414.78F6E7302F@freebsd-current.sentex.ca>

TB --- 2009-02-02 22:11:25 - tinderbox 2.6 running on freebsd-current.sentex.ca
TB --- 2009-02-02 22:11:25 - starting HEAD tinderbox run for ia64/ia64
TB --- 2009-02-02 22:11:25 - cleaning the object tree
TB --- 2009-02-02 22:12:00 - cvsupping the source tree
TB --- 2009-02-02 22:12:00 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/ia64/ia64/supfile
TB --- 2009-02-02 22:12:08 - building world
TB --- 2009-02-02 22:12:08 - MAKEOBJDIRPREFIX=/obj
TB --- 2009-02-02 22:12:08 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2009-02-02 22:12:08 - TARGET=ia64
TB --- 2009-02-02 22:12:08 - TARGET_ARCH=ia64
TB --- 2009-02-02 22:12:08 - TZ=UTC
TB --- 2009-02-02 22:12:08 - __MAKE_CONF=/dev/null
TB --- 2009-02-02 22:12:08 - cd /src
TB --- 2009-02-02 22:12:08 - /usr/bin/make -B buildworld
>>> World build started on Mon Feb  2 22:12: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/usr.sbin/ntp/doc/ntptrace.8 > ntptrace.8.gz
===> usr.sbin/pciconf (all)
cc -O2 -pipe  -I/src/usr.sbin/pciconf/../../sys  -c /src/usr.sbin/pciconf/pciconf.c
/src/usr.sbin/pciconf/pciconf.c: In function 'list_bars':
/src/usr.sbin/pciconf/pciconf.c:236: error: storage size of 'bar' isn't known
/src/usr.sbin/pciconf/pciconf.c:258: error: 'PCIOCGETBAR' undeclared (first use in this function)
/src/usr.sbin/pciconf/pciconf.c:258: error: (Each undeclared identifier is reported only once
/src/usr.sbin/pciconf/pciconf.c:258: error: for each function it appears in.)
*** Error code 1

Stop in /src/usr.sbin/pciconf.
*** Error code 1

Stop in /src/usr.sbin.
*** Error code 1

Stop in /src.
*** Error code 1

Stop in /src.
*** Error code 1

Stop in /src.
TB --- 2009-02-02 23:54:14 - WARNING: /usr/bin/make returned exit code  1 
TB --- 2009-02-02 23:54:14 - ERROR: failed to build world
TB --- 2009-02-02 23:54:14 - 5118.23 user 371.18 system 6169.21 real


http://tinderbox.des.no/tinderbox-head-HEAD-ia64-ia64.full
From daichi at ongs.co.jp  Mon Feb  2 17:26:03 2009
From: daichi at ongs.co.jp (Daichi GOTO)
Date: Mon Feb  2 17:26:10 2009
Subject: patch r187693 breaks HAL on amd64-current
In-Reply-To: <20137.80.160.75.130.1233563452.squirrel@test.imada.sdu.dk>
References: <4985FA10.5080604@imada.sdu.dk> <498607D7.7090507@videotron.ca>
	<20137.80.160.75.130.1233563452.squirrel@test.imada.sdu.dk>
Message-ID: <49879D28.8050100@ongs.co.jp>

I have checked follow patch. After rebuild kernel with that,
hald works well and issues around hald have gone away on
FreeBSD 8-current/amd64.

I guess recent amd64 X.Org odd issues depends on
this change. ASAP quick merging is important.

Thanks

Ralph Zitz wrote:
> Thanks!
> 
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> Ralph Zitz wrote:
>>> I'm not a HAL expert, but it seems that the patch makes HAL create a
>>> zombie process when watching /dev/cd0. Reversing the patch makes HAL
>>> work again.
>>>
>>> Link to patch message:
>>> http://lists.freebsd.org/pipermail/svn-src-all/2009-January/004073.html
>>>
>> Hi Ralph
>>
>> Try the following patch, it should fix your problem with hal.
>>
>> Regards
>>
>> Steph
>> -----BEGIN PGP SIGNATURE-----
>> Version: GnuPG v2.0.10 (FreeBSD)
>> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>>
>> iEYEARECAAYFAkmGB9YACgkQmdOXtTCX/nt8tACgj5IzDaHDEsKIJbZPefOwzkiW
>> Ne4AoMV4GzfMLeVeBAWIRbmG08R7Lpj3
>> =K7Cu
>> -----END PGP SIGNATURE-----
>> Index: kern/sys_generic.c
>> ===================================================================
>> --- kern/sys_generic.c	(revision 187983)
>> +++ kern/sys_generic.c	(working copy)
>> @@ -903,7 +903,7 @@
>>   * bit position in the fd_mask array.
>>   */
>>  static __inline int
>> -selflags(fd_mask **ibits, int idx, int bit)
>> +selflags(fd_mask **ibits, int idx, fd_mask bit)
>>  {
>>  	int flags;
>>  	int msk;
>> @@ -912,7 +912,7 @@
>>  	for (msk = 0; msk < 3; msk++) {
>>  		if (ibits[msk] == NULL)
>>  			continue;
>> -		if ((ibits[msk][idx] & (fd_mask)bit) == 0)
>> +		if ((ibits[msk][idx] & bit) == 0)
>>  			continue;
>>  		flags |= select_flags[msk];
>>  	}
>>
> 
> _______________________________________________
> 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"

-- 
   Daichi GOTO, http://people.freebsd.org/~daichi
From sepotvin at videotron.ca  Mon Feb  2 19:08:04 2009
From: sepotvin at videotron.ca (Stephane E. Potvin)
Date: Mon Feb  2 19:08:53 2009
Subject: patch r187693 breaks HAL on amd64-current
In-Reply-To: <49879D28.8050100@ongs.co.jp>
References: <4985FA10.5080604@imada.sdu.dk> <498607D7.7090507@videotron.ca>
	<20137.80.160.75.130.1233563452.squirrel@test.imada.sdu.dk>
	<49879D28.8050100@ongs.co.jp>
Message-ID: <4987A6DE.6040007@videotron.ca>

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

Daichi GOTO wrote:
> I have checked follow patch. After rebuild kernel with that,
> hald works well and issues around hald have gone away on
> FreeBSD 8-current/amd64.
> 
> I guess recent amd64 X.Org odd issues depends on
> this change. ASAP quick merging is important.
> 
Hi,

The patch was committed as

> r187996 | sepotvin | 2009-02-01 22:34:40 -0500 (Sun, 01 Feb 2009) | 5 lines
> 
> Fix select on platforms where sizeof(long) != sizeof(int). This used
> to work by accident before the cleanup done in revision 187693.

Regards,

Steph
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.10 (FreeBSD)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkmHpt4ACgkQmdOXtTCX/ntJ+QCg/qR458j0aTYhIywV+PZEvPu0
2McAnAuznCItpNQUpXOe+WpBZD4f4JoR
=0wp+
-----END PGP SIGNATURE-----
From freebsd at abv.bg  Mon Feb  2 21:45:23 2009
From: freebsd at abv.bg (Mario Pavlov)
Date: Mon Feb  2 21:45:30 2009
Subject: panic caused by mpd5
Message-ID: <1868132185.26927.1233639921805.JavaMail.apache@mail51.abv.bg>

Hi,
I don't know what else could be useful
just tell me what you need and I'll provide it

btw what is r187946 ?

thank you

regards
MGP


 >On Mon, 2 Feb 2009, Mario Pavlov wrote:
 >
 >> I'm sorry, looks like that attachments got lost somewhere...
 >> here are links to them:
 >> http://e-soul.org/~mgp/tmp/panic.gif
 >
 >Not much information but I assume that this should have been fixed
 >with r187946.
 >
 >/bz
 >
 >-- 
 >Bjoern A. Zeeb                      The greatest risk is not taking one.
 >_______________________________________________
 >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 nakal at web.de  Mon Feb  2 23:21:58 2009
From: nakal at web.de (Martin)
Date: Mon Feb  2 23:22:06 2009
Subject: GEOM_PART: a quick update on logical partitions
In-Reply-To: <FCA8C5E4-BC41-4711-9EBC-CD692144F6B8@mac.com>
References: <FCA8C5E4-BC41-4711-9EBC-CD692144F6B8@mac.com>
Message-ID: <20090203082153.565746e2@zelda.local>

Am Mon, 02 Feb 2009 11:16:53 -0800
schrieb Marcel Moolenaar <xcllnt@mac.com>:

> 	/dev/da0s2.00000000
> 	/dev/da0s2.0834F7A0
> 	/dev/da0s5 -> /dev/da0s2.00000000
> 	/dev/da0s6 -> /dev/da0s2.0834F7A0

Hi.

As far as I remember, the old MS-DOS scheme for partitioning
(we have GPT now ;) that I am happy with) implements these logical
partitions as a linked list. Why not have a simple index pointing to
the list entry?

Something like this:

/dev/da0s2.1
/dev/da0s2.2

Might be starting with 1 or perhaps 0.


Second thing is, why do you need something like "s5"? I don't like
these symlinks, because I don't see how you want to support something
like ".eli" oder ".eli.journal" etc.

--
Martin
From tinderbox at freebsd.org  Tue Feb  3 00:55:27 2009
From: tinderbox at freebsd.org (FreeBSD Tinderbox)
Date: Tue Feb  3 00:55:39 2009
Subject: [head tinderbox] failure on ia64/ia64
Message-ID: <20090203085523.802FC7302F@freebsd-current.sentex.ca>

TB --- 2009-02-03 06:31:15 - tinderbox 2.6 running on freebsd-current.sentex.ca
TB --- 2009-02-03 06:31:15 - starting HEAD tinderbox run for ia64/ia64
TB --- 2009-02-03 06:31:15 - cleaning the object tree
TB --- 2009-02-03 06:31:35 - cvsupping the source tree
TB --- 2009-02-03 06:31:35 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/ia64/ia64/supfile
TB --- 2009-02-03 06:31:45 - building world
TB --- 2009-02-03 06:31:45 - MAKEOBJDIRPREFIX=/obj
TB --- 2009-02-03 06:31:45 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2009-02-03 06:31:45 - TARGET=ia64
TB --- 2009-02-03 06:31:45 - TARGET_ARCH=ia64
TB --- 2009-02-03 06:31:45 - TZ=UTC
TB --- 2009-02-03 06:31:45 - __MAKE_CONF=/dev/null
TB --- 2009-02-03 06:31:45 - cd /src
TB --- 2009-02-03 06:31:45 - /usr/bin/make -B buildworld
>>> World build started on Tue Feb  3 06:31:46 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 Feb  3 08:20:42 UTC 2009
TB --- 2009-02-03 08:20:42 - generating LINT kernel config
TB --- 2009-02-03 08:20:42 - cd /src/sys/ia64/conf
TB --- 2009-02-03 08:20:42 - /usr/bin/make -B LINT
TB --- 2009-02-03 08:20:42 - building LINT kernel
TB --- 2009-02-03 08:20:42 - MAKEOBJDIRPREFIX=/obj
TB --- 2009-02-03 08:20:42 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2009-02-03 08:20:42 - TARGET=ia64
TB --- 2009-02-03 08:20:42 - TARGET_ARCH=ia64
TB --- 2009-02-03 08:20:42 - TZ=UTC
TB --- 2009-02-03 08:20:42 - __MAKE_CONF=/dev/null
TB --- 2009-02-03 08:20:42 - cd /src
TB --- 2009-02-03 08:20:42 - /usr/bin/make -B buildkernel KERNCONF=LINT
>>> Kernel build for LINT started on Tue Feb  3 08:20:42 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/modules/usb2/quirk/../../../dev/usb2/quirk/usb2_quirk.c:115: warning: data definition has no type or storage class
/src/sys/modules/usb2/quirk/../../../dev/usb2/quirk/usb2_quirk.c:115: warning: type defaults to 'int' in declaration of 'USB_MAKE_DEBUG_TABLE'
/src/sys/modules/usb2/quirk/../../../dev/usb2/quirk/usb2_quirk.c:115: warning: parameter names (without types) in function declaration
/src/sys/modules/usb2/quirk/../../../dev/usb2/quirk/usb2_quirk.c: In function 'usb2_quirkstr':
/src/sys/modules/usb2/quirk/../../../dev/usb2/quirk/usb2_quirk.c:126: error: 'USB_QUIRK' undeclared (first use in this function)
/src/sys/modules/usb2/quirk/../../../dev/usb2/quirk/usb2_quirk.c:126: error: (Each undeclared identifier is reported only once
/src/sys/modules/usb2/quirk/../../../dev/usb2/quirk/usb2_quirk.c:126: error: for each function it appears in.)
*** Error code 1

Stop in /src/sys/modules/usb2/quirk.
*** Error code 1

Stop in /src/sys/modules/usb2.
*** Error code 1

Stop in /src/sys/modules.
*** Error code 1

Stop in /obj/ia64/src/sys/LINT.
*** Error code 1

Stop in /src.
*** Error code 1

Stop in /src.
TB --- 2009-02-03 08:55:23 - WARNING: /usr/bin/make returned exit code  1 
TB --- 2009-02-03 08:55:23 - ERROR: failed to build lint kernel
TB --- 2009-02-03 08:55:23 - 7158.29 user 467.13 system 8648.29 real


http://tinderbox.des.no/tinderbox-head-HEAD-ia64-ia64.full
From mexas at bristol.ac.uk  Tue Feb  3 01:42:39 2009
From: mexas at bristol.ac.uk (Anton Shterenlikht)
Date: Tue Feb  3 01:42:47 2009
Subject: X fails on i845 board -  errors found in hardware state
In-Reply-To: <1233602464.1492.21.camel@ferret.2hip.net>
References: <20090202122408.GA97807@mech-cluster238.men.bris.ac.uk>
	<1233602464.1492.21.camel@ferret.2hip.net>
Message-ID: <20090203094202.GA52293@mech-cluster238.men.bris.ac.uk>

On Mon, Feb 02, 2009 at 02:21:03PM -0500, Robert Noland wrote:
> On Mon, 2009-02-02 at 12:24 +0000, Anton Shterenlikht wrote:
> > X fails on i845G (or is it i845M ?) board with 
> > 
> > [skip]
> > (WW) intel(0): PRB0_CTL (0x0001f001) indicates ring buffer enabled
> > (WW) intel(0): PRB0_HEAD (0x00000024) and PRB0_TAIL (0x00000068) indicate ring b
> > uffer not flushed
> > (WW) intel(0): Existing errors found in hardware state.
> > Error in I830WaitLpRing(), timeout for 2 seconds
> > pgetbl_ctl: 0x1ffe0001 getbl_err: 0x00000000
> > ipeir: 0x00000000 iphdr: 0x05000000
> > LP ring tail: 0x00000068 head: 0x00000024 len: 0x0001f001 start 0x00000000
> > eir: 0x0000 esr: 0x0000 emr: 0xff7b
> > instdone: 0xffc1 instpm: 0x0000
> > memmode: 0x00000000 instps: 0x00000040
> > hwstam: 0xffff ier: 0x0000 imr: 0xffff iir: 0x0000
> > Ring at virtual 0x28c00000 head 0x24 tail 0x68 count 17 acthd 0x311a8
> > Ring at virtual 0x28c00000 head 0x24 tail 0x68 count 17
> > [skip]
> 
> Does this happen on a fresh boot, or only after X is restarted?

each time since the recent massive ports upgrade.
Since then I haven't been able to run X server at all.

anton

> 
> > Fatal server error:
> > lockup
> > 
> > 
> > The details are below. Note that it fails with or without drm.
> > I wonder if I should submit a pr.
> > 
> > many thanks
> > anton
> > 
> > # uname -srm
> > FreeBSD 8.0-CURRENT i386
> > 
> > dmesg fragments
> > 
> > # dmesg | grep agp
> > agp0: <Intel 82845M (845M GMCH) SVGA controller> on vgapci0
> > agp0: detected 8060k stolen memory
> > agp0: aperture size is 128M
> > 
> > # dmesg | grep drm
> > drm0: <Intel i845G GMCH> on vgapci0
> > vgapci0: child drm0 requested pci_enable_busmaster
> > info: [drm] AGP at 0xf0000000 128MB
> > info: [drm] Initialized i915 1.6.0 20080730
> > drm0: [ITHREAD]
> > 
> > full dmesg
> > 
> > # dmesg
> > 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-CURRENT #0: Mon Feb  2 10:39:04 GMT 2009
> >     mexas@mech-Anton240.men.bris.ac.uk:/usr/obj/usr/src/sys/EDGE
> > WARNING: WITNESS option enabled, expect reduced performance.
> > Timecounter "i8254" frequency 1193182 Hz quality 0
> > CPU: Intel(R) Pentium(R) 4 CPU 2.40GHz (2400.10-MHz 686-class CPU)
> >   Origin = "GenuineIntel"  Id = 0xf27  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=0x400<CNXT-ID>
> > real memory  = 527695872 (503 MB)
> > avail memory = 507289600 (483 MB)
> > acpi0: <INTEL D845GRG2> on motherboard
> > acpi0: [ITHREAD]
> > acpi0: Power Button (fixed)
> > acpi0: reservation of 0, a0000 (3) failed
> > acpi0: reservation of 100000, 1f700000 (3) failed
> > Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000
> > acpi_timer0: <24-bit timer at 3.579545MHz> port 0x408-0x40b on acpi0
> > pcib0: <ACPI Host-PCI bridge> port 0xcf8-0xcff on acpi0
> > pci0: <ACPI PCI bus> on pcib0
> > vgapci0: <VGA-compatible display> mem 0xf0000000-0xf7ffffff,0xffa80000-0xffafffff irq 11 at device 2.0 on pci0
> > agp0: <Intel 82845M (845M GMCH) SVGA controller> on vgapci0
> > agp0: detected 8060k stolen memory
> > agp0: aperture size is 128M
> > drm0: <Intel i845G GMCH> on vgapci0
> > vgapci0: child drm0 requested pci_enable_busmaster
> > info: [drm] AGP at 0xf0000000 128MB
> > info: [drm] Initialized i915 1.6.0 20080730
> > uhci0: <Intel 82801DB (ICH4) USB controller USB-A> port 0xe800-0xe81f irq 11 at device 29.0 on pci0
> > uhci0: [GIANT-LOCKED]
> > uhci0: [ITHREAD]
> > usb0: <Intel 82801DB (ICH4) USB controller USB-A> on uhci0
> > usb0: USB revision 1.0
> > uhub0: <Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1> on usb0
> > uhub0: 2 ports with 2 removable, self powered
> > uhci1: <Intel 82801DB (ICH4) USB controller USB-B> port 0xe880-0xe89f irq 3 at device 29.1 on pci0
> > uhci1: [GIANT-LOCKED]
> > uhci1: [ITHREAD]
> > usb1: <Intel 82801DB (ICH4) USB controller USB-B> on uhci1
> > usb1: USB revision 1.0
> > uhub1: <Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1> on usb1
> > uhub1: 2 ports with 2 removable, self powered
> > uhci2: <Intel 82801DB (ICH4) USB controller USB-C> port 0xec00-0xec1f irq 5 at device 29.2 on pci0
> > uhci2: [GIANT-LOCKED]
> > uhci2: [ITHREAD]
> > usb2: <Intel 82801DB (ICH4) USB controller USB-C> on uhci2
> > usb2: USB revision 1.0
> > uhub2: <Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1> on usb2
> > uhub2: 2 ports with 2 removable, self powered
> > ehci0: <Intel 82801DB/L/M (ICH4) USB 2.0 controller> mem 0xffa7fc00-0xffa7ffff irq 9 at device 29.7 on pci0
> > ehci0: [GIANT-LOCKED]
> > ehci0: [ITHREAD]
> > usb3: EHCI version 1.0
> > usb3: companion controllers, 2 ports each: usb0 usb1 usb2
> > usb3: <Intel 82801DB/L/M (ICH4) USB 2.0 controller> on ehci0
> > usb3: USB revision 2.0
> > uhub3: <Intel EHCI root hub, class 9/0, rev 2.00/1.00, addr 1> on usb3
> > uhub3: 6 ports with 6 removable, self powered
> > pcib1: <ACPI PCI-PCI bridge> at device 30.0 on pci0
> > pci1: <ACPI PCI bus> on pcib1
> > ahc0: <Adaptec 2940 Ultra SCSI adapter> port 0xd800-0xd8ff mem 0xff8ff000-0xff8fffff irq 10 at device 0.0 on pci1
> > ahc0: [ITHREAD]
> > aic7880: Ultra Wide Channel A, SCSI Id=7, 16/253 SCBs
> > fxp0: <Intel 82801DB (ICH4) Pro/100 VE Ethernet> port 0xdc00-0xdc3f mem 0xff8fe000-0xff8fefff irq 11 at device 8.0 on pci1
> > miibus0: <MII bus> on fxp0
> > inphy0: <i82562ET 10/100 media interface> PHY 1 on miibus0
> > inphy0:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
> > fxp0: Ethernet address: 00:07:e9:e7:41:dc
> > fxp0: [ITHREAD]
> > isab0: <PCI-ISA bridge> at device 31.0 on pci0
> > isa0: <ISA bus> on isab0
> > atapci0: <Intel ICH4 UDMA100 controller> port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xffa0-0xffaf at device 31.1 on pci0
> > ata0: <ATA channel 0> on atapci0
> > ata0: [ITHREAD]
> > ata1: <ATA channel 1> on atapci0
> > ata1: [ITHREAD]
> > pci0: <serial bus, SMBus> at device 31.3 (no driver attached)
> > pci0: <multimedia, audio> at device 31.5 (no driver attached)
> > acpi_button0: <Sleep Button> on acpi0
> > atrtc0: <AT realtime clock> port 0x70-0x71 irq 8 on acpi0
> > fdc0: <floppy drive controller> port 0x3f0-0x3f1,0x3f2-0x3f3,0x3f4-0x3f5,0x3f7 irq 6 drq 2 on acpi0
> > fdc0: [FILTER]
> > fd0: <1440-KB 3.5" drive> on fdc0 drive 0
> > uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0
> > uart0: [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, device ID 3
> > cpu0: <ACPI CPU> on acpi0
> > p4tcc0: <CPU Frequency Thermal Control> on cpu0
> > pmtimer0 on isa0
> > orm0: <ISA Option ROM> at iomem 0xcb800-0xcbfff 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
> > Timecounter "TSC" frequency 2400099084 Hz quality 800
> > Timecounters tick every 1.000 msec
> > ahc0: Someone reset channel A
> > ad0: 76319MB <WDC WD800BB-00CAA1 17.07W17> at ata0-master UDMA100
> > acd0: DVDROM <DVD-ROM DDU1621/VER S2.9> at ata1-master UDMA33
> > acd1: CDRW <SONY CD-RW CRX210E1/2YS2> at ata1-slave UDMA33
> > Waiting 5 seconds for SCSI devices to settle
> > (probe0:ahc0:0:0:0): INQUIRY. CDB: 12 0 0 0 24 0 
> > (probe1:ahc0:0:1:0): INQUIRY. CDB: 12 0 0 0 24 0 
> > (probe2:ahc0:0:2:0): INQUIRY. CDB: 12 0 0 0 24 0 
> > (probe3:ahc0:0:3:0): INQUIRY. CDB: 12 0 0 0 24 0 
> > (probe4:ahc0:0:4:0): INQUIRY. CDB: 12 0 0 0 24 0 
> > (probe5:ahc0:0:5:0): INQUIRY. CDB: 12 0 0 0 24 0 
> > (probe6:ahc0:0:6:0): INQUIRY. CDB: 12 0 0 0 24 0 
> > (probe7:ahc0:0:8:0): INQUIRY. CDB: 12 0 0 0 24 0 
> > (probe8:ahc0:0:9:0): INQUIRY. CDB: 12 0 0 0 24 0 
> > (probe9:ahc0:0:10:0): INQUIRY. CDB: 12 0 0 0 24 0 
> > (probe10:ahc0:0:11:0): INQUIRY. CDB: 12 0 0 0 24 0 
> > (probe11:ahc0:0:12:0): INQUIRY. CDB: 12 0 0 0 24 0 
> > (probe12:ahc0:0:13:0): INQUIRY. CDB: 12 0 0 0 24 0 
> > (probe13:ahc0:0:14:0): INQUIRY. CDB: 12 0 0 0 24 0 
> > (probe14:ahc0:0:15:0): INQUIRY. CDB: 12 0 0 0 24 0 
> > GEOM: ad0s1: geometry does not match label (255h,63s != 16h,63s).
> > WARNING: WITNESS option enabled, expect reduced performance.
> > Trying to mount root from ufs:/dev/ad0s1a
> > lock order reversal:
> >  1st 0xc2c6d044 user map (user map) @ /usr/src/sys/vm/vm_map.c:3198
> >  2nd 0xc2e757ac ufs (ufs) @ /usr/src/sys/kern/vfs_subr.c:2071
> > KDB: stack backtrace:
> > db_trace_self_wrapper(c081229e,c2a11914,c0608e59,4,c080db0b,...) at db_trace_self_wrapper+0x26
> > kdb_backtrace(4,c080db0b,c081bb43,c2c2f0b0,c2a1196c,...) at kdb_backtrace+0x29
> > _witness_debugger(c0814ddf,c2e757ac,c0808b46,c2c2f0b0,c081bb43,...) at _witness_debugger+0x21
> > witness_checkorder(c2e757ac,1,c081bb43,817,0,...) at witness_checkorder+0x811
> > __lockmgr_args(c2e757ac,200501,c2e757c8,0,0,...) at __lockmgr_args+0x226
> > ffs_lock(c2a11a7c,c0608c35,c082ecbb,200501,c2e75754,...) at ffs_lock+0x7d
> > VOP_LOCK1_APV(c087ae20,c2a11a7c,c2c6ae24,c088b3a0,c2e75754,...) at VOP_LOCK1_APV+0xaf
> > _vn_lock(c2e75754,200501,c081bb43,817,4,...) at _vn_lock+0x5e
> > vget(c2e75754,200501,c2c6ad80,4b4,0,...) at vget+0xc1
> > vnode_pager_lock(c10432e8,0,c082c298,127,c2a11c18,...) at vnode_pager_lock+0x1d3
> > vm_fault(c2c6d000,80d6000,2,8,80d6000,...) at vm_fault+0x1e8
> > trap_pfault(5,0,c0837eec,2e7,c,...) at trap_pfault+0xf9
> > trap(c2a11d38) at trap+0x264
> > calltrap() at calltrap+0x6
> > --- trap 0xc, eip = 0x80480e5, esp = 0xbfbfeef0, ebp = 0xbfbfef10 ---
> > drm0: [ITHREAD]
> > pid 1150 (Xorg), uid 0: exited on signal 6 (core dumped)
> > pid 1155 (Xorg), uid 0: exited on signal 6 (core dumped)
> > 
> > Xorg log
> > 
> > #cat /var/log/Xorg.0.log
> > X.Org X Server 1.5.3
> > Release Date: 5 November 2008
> > X Protocol Version 11, Revision 0
> > Build Operating System: FreeBSD 8.0-CURRENT i386 
> > Current Operating System: FreeBSD mech-Anton240.men.bris.ac.uk 8.0-CURRENT FreeBSD 8.0-CURRENT #0: Mon Feb  2 10:39:04 GMT 2009     mexas@mech-Anton240.men.bris.ac.uk:/usr/obj/usr/src/sys/EDGE i386
> > Build Date: 27 January 2009  05:40:24PM
> >  
> > 	Before reporting problems, check http://wiki.x.org
> > 	to make sure that you have the latest version.
> > Markers: (--) probed, (**) from config file, (==) default setting,
> > 	(++) from command line, (!!) notice, (II) informational,
> > 	(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
> > (==) Log file: "/var/log/Xorg.0.log", Time: Mon Feb  2 11:58:09 2009
> > (++) Using config file: "/root/xorg.conf.new"
> > (==) ServerLayout "X.org Configured"
> > (**) |-->Screen "Screen0" (0)
> > (**) |   |-->Monitor "Monitor0"
> > (**) |   |-->Device "Card0"
> > (**) |-->Input Device "Mouse0"
> > (**) |-->Input Device "Keyboard0"
> > (==) Automatically adding devices
> > (==) Automatically enabling devices
> > (WW) `fonts.dir' not found (or not valid) in "/usr/local/lib/X11/fonts/100dpi/".
> > 	Entry deleted from font path.
> > 	(Run 'mkfontdir' on "/usr/local/lib/X11/fonts/100dpi/").
> > (==) Including the default font path /usr/local/lib/X11/fonts/misc/,/usr/local/lib/X11/fonts/TTF/,/usr/local/lib/X11/fonts/OTF,/usr/local/lib/X11/fonts/Type1/,/usr/local/lib/X11/fonts/100dpi/,/usr/local/lib/X11/fonts/75dpi/.
> > (**) FontPath set to:
> > 	/usr/local/lib/X11/fonts/misc/,
> > 	/usr/local/lib/X11/fonts/TTF/,
> > 	/usr/local/lib/X11/fonts/OTF,
> > 	/usr/local/lib/X11/fonts/Type1/,
> > 	/usr/local/lib/X11/fonts/75dpi/,
> > 	/usr/local/lib/X11/fonts/misc/,
> > 	/usr/local/lib/X11/fonts/TTF/,
> > 	/usr/local/lib/X11/fonts/OTF,
> > 	/usr/local/lib/X11/fonts/Type1/,
> > 	/usr/local/lib/X11/fonts/100dpi/,
> > 	/usr/local/lib/X11/fonts/75dpi/
> > (**) ModulePath set to "/usr/local/lib/xorg/modules"
> > (WW) AllowEmptyInput is on, devices using drivers 'kbd' or 'mouse' will be disabled.
> > (WW) Disabling Mouse0
> > (WW) Disabling Keyboard0
> > (II) Loader magic: 0x81b1de0
> > (II) Module ABI versions:
> > 	X.Org ANSI C Emulation: 0.4
> > 	X.Org Video Driver: 4.1
> > 	X.Org XInput driver : 2.1
> > 	X.Org Server Extension : 1.1
> > 	X.Org Font Renderer : 0.6
> > (II) Loader running on freebsd
> > (--) Using syscons driver with X support (version 2.0)
> > (--) using VT number 9
> > 
> > (--) PCI:*(0@0:2:0) Intel Corporation 82845G/GL[Brookdale-G]/GE Chipset Integrated Graphics Device rev 3, Mem @ 0xf0000000/0, 0xffa80000/0, BIOS @ 0x????????/65536
> > (II) System resource ranges:
> > 	[0] -1	0	0x00100000 - 0x3fffffff (0x3ff00000) MX[B]E(B)
> > 	[1] -1	0	0x000f0000 - 0x000fffff (0x10000) MX[B]
> > 	[2] -1	0	0x000c0000 - 0x000effff (0x30000) MX[B]
> > 	[3] -1	0	0x00000000 - 0x0009ffff (0xa0000) MX[B]
> > 	[4] -1	0	0x0000ffff - 0x0000ffff (0x1) IX[B]
> > 	[5] -1	0	0x00000000 - 0x000000ff (0x100) IX[B]
> > (II) "extmod" will be loaded. This was enabled by default and also specified in the config file.
> > (II) "dbe" will be loaded. This was enabled by default and also specified in the config file.
> > (II) "glx" will be loaded. This was enabled by default and also specified in the config file.
> > (II) "freetype" will be loaded. This was enabled by default and also specified in the config file.
> > (II) "record" will be loaded. This was enabled by default and also specified in the config file.
> > (II) "dri" will be loaded. This was enabled by default and also specified in the config file.
> > (II) LoadModule: "extmod"
> > 
> > (II) Loading /usr/local/lib/xorg/modules/extensions//libextmod.so
> > (II) Module extmod: vendor="X.Org Foundation"
> > 	compiled for 1.5.3, module version = 1.0.0
> > 	Module class: X.Org Server Extension
> > 	ABI class: X.Org Server Extension, version 1.1
> > (II) Loading extension SHAPE
> > (II) Loading extension MIT-SUNDRY-NONSTANDARD
> > (II) Loading extension BIG-REQUESTS
> > (II) Loading extension SYNC
> > (II) Loading extension MIT-SCREEN-SAVER
> > (II) Loading extension XC-MISC
> > (II) Loading extension XFree86-VidModeExtension
> > (II) Loading extension XFree86-Misc
> > (II) Loading extension XFree86-DGA
> > (II) Loading extension DPMS
> > (II) Loading extension TOG-CUP
> > (II) Loading extension Extended-Visual-Information
> > (II) Loading extension XVideo
> > (II) Loading extension XVideo-MotionCompensation
> > (II) Loading extension X-Resource
> > (II) LoadModule: "record"
> > 
> > (II) Loading /usr/local/lib/xorg/modules/extensions//librecord.so
> > (II) Module record: vendor="X.Org Foundation"
> > 	compiled for 1.5.3, module version = 1.13.0
> > 	Module class: X.Org Server Extension
> > 	ABI class: X.Org Server Extension, version 1.1
> > (II) Loading extension RECORD
> > (II) LoadModule: "dbe"
> > 
> > (II) Loading /usr/local/lib/xorg/modules/extensions//libdbe.so
> > (II) Module dbe: vendor="X.Org Foundation"
> > 	compiled for 1.5.3, module version = 1.0.0
> > 	Module class: X.Org Server Extension
> > 	ABI class: X.Org Server Extension, version 1.1
> > (II) Loading extension DOUBLE-BUFFER
> > (II) LoadModule: "glx"
> > 
> > (II) Loading /usr/local/lib/xorg/modules/extensions//libglx.so
> > (II) Module glx: vendor="X.Org Foundation"
> > 	compiled for 1.5.3, module version = 1.0.0
> > 	ABI class: X.Org Server Extension, version 1.1
> > (==) AIGLX disabled
> > (==) Exporting typical set of GLX visuals
> > (II) Loading extension GLX
> > (II) LoadModule: "xtrap"
> > 
> > (II) Loading /usr/local/lib/xorg/modules/extensions//libxtrap.so
> > (II) Module xtrap: vendor="X.Org Foundation"
> > 	compiled for 1.5.3, module version = 1.0.0
> > 	Module class: X.Org Server Extension
> > 	ABI class: X.Org Server Extension, version 1.1
> > (II) Loading extension DEC-XTRAP
> > (II) LoadModule: "dri"
> > 
> > (II) Loading /usr/local/lib/xorg/modules/extensions//libdri.so
> > (II) Module dri: vendor="X.Org Foundation"
> > 	compiled for 1.5.3, module version = 1.0.0
> > 	ABI class: X.Org Server Extension, version 1.1
> > (II) Loading extension XFree86-DRI
> > (II) LoadModule: "freetype"
> > 
> > (II) Loading /usr/local/lib/xorg/modules/fonts//libfreetype.so
> > (II) Module freetype: vendor="X.Org Foundation & the After X-TT Project"
> > 	compiled for 1.5.3, module version = 2.1.0
> > 	Module class: X.Org Font Renderer
> > 	ABI class: X.Org Font Renderer, version 0.6
> > (II) Loading font FreeType
> > (II) LoadModule: "intel"
> > 
> > (II) Loading /usr/local/lib/xorg/modules/drivers//intel_drv.so
> > (II) Module intel: vendor="X.Org Foundation"
> > 	compiled for 1.5.3, module version = 2.5.1
> > 	Module class: X.Org Video Driver
> > 	ABI class: X.Org Video Driver, version 4.1
> > (II) intel: Driver for Intel Integrated Graphics Chipsets: i810,
> > 	i810-dc100, i810e, i815, i830M, 845G, 852GM/855GM, 865G, 915G,
> > 	E7221 (i915), 915GM, 945G, 945GM, 945GME, 965G, G35, 965Q, 946GZ,
> > 	965GM, 965GME/GLE, G33, Q35, Q33,
> > 	Mobile Intel?? GM45 Express Chipset,
> > 	Intel Integrated Graphics Device, G45/G43, Q45/Q43, G41
> > (II) Primary Device is: PCI 00@00:02:0
> > (II) resource ranges after xf86ClaimFixedResources() call:
> > 	[0] -1	0	0x00100000 - 0x3fffffff (0x3ff00000) MX[B]E(B)
> > 	[1] -1	0	0x000f0000 - 0x000fffff (0x10000) MX[B]
> > 	[2] -1	0	0x000c0000 - 0x000effff (0x30000) MX[B]
> > 	[3] -1	0	0x00000000 - 0x0009ffff (0xa0000) MX[B]
> > 	[4] -1	0	0x0000ffff - 0x0000ffff (0x1) IX[B]
> > 	[5] -1	0	0x00000000 - 0x000000ff (0x100) IX[B]
> > (II) resource ranges after probing:
> > 	[0] -1	0	0x00100000 - 0x3fffffff (0x3ff00000) MX[B]E(B)
> > 	[1] -1	0	0x000f0000 - 0x000fffff (0x10000) MX[B]
> > 	[2] -1	0	0x000c0000 - 0x000effff (0x30000) MX[B]
> > 	[3] -1	0	0x00000000 - 0x0009ffff (0xa0000) MX[B]
> > 	[4] 0	0	0x000a0000 - 0x000affff (0x10000) MS[B]
> > 	[5] 0	0	0x000b0000 - 0x000b7fff (0x8000) MS[B]
> > 	[6] 0	0	0x000b8000 - 0x000bffff (0x8000) MS[B]
> > 	[7] -1	0	0x0000ffff - 0x0000ffff (0x1) IX[B]
> > 	[8] -1	0	0x00000000 - 0x000000ff (0x100) IX[B]
> > 	[9] 0	0	0x000003b0 - 0x000003bb (0xc) IS[B]
> > 	[10] 0	0	0x000003c0 - 0x000003df (0x20) IS[B]
> > (II) Loading sub module "vgahw"
> > (II) LoadModule: "vgahw"
> > 
> > (II) Loading /usr/local/lib/xorg/modules//libvgahw.so
> > (II) Module vgahw: vendor="X.Org Foundation"
> > 	compiled for 1.5.3, module version = 0.1.0
> > 	ABI class: X.Org Video Driver, version 4.1
> > (==) intel(0): Depth 24, (==) framebuffer bpp 32
> > (==) intel(0): RGB weight 888
> > (==) intel(0): Default visual is TrueColor
> > (II) intel(0): Integrated Graphics Chipset: Intel(R) 845G
> > (--) intel(0): Chipset: "845G"
> > (--) intel(0): Linear framebuffer at 0xF0000000
> > (--) intel(0): IO registers at addr 0xFFA80000
> > (==) intel(0): Using EXA for acceleration
> > (II) intel(0): 1 display pipe available.
> > (II) Loading sub module "ddc"
> > (II) LoadModule: "ddc"
> > (II) Module "ddc" already built-in
> > (II) Loading sub module "i2c"
> > (II) LoadModule: "i2c"
> > (II) Module "i2c" already built-in
> > (II) intel(0): Output VGA using monitor section Monitor0
> > (II) intel(0): I2C bus "DVODDC_D" initialized.
> > (II) Loading sub module "sil164"
> > (II) LoadModule: "sil164"
> > 
> > (II) Loading /usr/local/lib/xorg/modules/drivers//sil164.so
> > (II) Module sil164: vendor="X.Org Foundation"
> > 	compiled for 1.5.3, module version = 1.0.0
> > 	ABI class: X.Org Video Driver, version 4.1
> > (II) intel(0): I2C bus "DVOI2C_E" initialized.
> > (II) Loading sub module "ch7xxx"
> > (II) LoadModule: "ch7xxx"
> > 
> > (II) Loading /usr/local/lib/xorg/modules/drivers//ch7xxx.so
> > (II) Module ch7xxx: vendor="X.Org Foundation"
> > 	compiled for 1.5.3, module version = 1.0.0
> > 	ABI class: X.Org Video Driver, version 4.1
> > (II) intel(0): I2C bus "DVOI2C_E" removed.
> > (II) intel(0): I2C bus "DVOI2C_E" initialized.
> > (II) Loading sub module "ivch"
> > (II) LoadModule: "ivch"
> > 
> > (II) Loading /usr/local/lib/xorg/modules/drivers//ivch.so
> > (II) Module ivch: vendor="X.Org Foundation"
> > 	compiled for 1.5.3, module version = 1.0.0
> > 	ABI class: X.Org Video Driver, version 4.1
> > (II) intel(0): I2C bus "DVOI2C_E" removed.
> > (II) intel(0): I2C bus "DVOI2C_B" initialized.
> > (II) Loading sub module "tfp410"
> > (II) LoadModule: "tfp410"
> > 
> > (II) Loading /usr/local/lib/xorg/modules/drivers//tfp410.so
> > (II) Module tfp410: vendor="X.Org Foundation"
> > 	compiled for 1.5.3, module version = 1.0.0
> > 	ABI class: X.Org Video Driver, version 4.1
> > (II) intel(0): I2C bus "DVOI2C_B" removed.
> > (II) intel(0): I2C bus "DVOI2C_E" initialized.
> > (II) Loading sub module "ch7017"
> > (II) LoadModule: "ch7017"
> > 
> > (II) Loading /usr/local/lib/xorg/modules/drivers//ch7017.so
> > (II) Module ch7017: vendor="X.Org Foundation"
> > 	compiled for 1.5.3, module version = 1.0.0
> > 	ABI class: X.Org Video Driver, version 4.1
> > (II) intel(0): I2C bus "DVOI2C_E" removed.
> > (II) intel(0): I2C bus "DVOI2C_E" initialized.
> > (II) intel(0): I2C bus "DVOI2C_E" removed.
> > (II) intel(0): I2C bus "DVODDC_D" removed.
> > (==) intel(0): Write-combining range (0xa0000,0x10000) was already clear
> > (II) intel(0): I2C bus "CRTDDC_A" initialized.
> > (II) intel(0): I2C bus "CRTDDC_A" removed.
> > (II) intel(0): I2C bus "CRTDDC_A" initialized.
> > (II) intel(0): I2C device "CRTDDC_A:ddc2" registered at address 0xA0.
> > (II) intel(0): I2C device "CRTDDC_A:ddc2" removed.
> > (II) intel(0): I2C bus "CRTDDC_A" removed.
> > (II) intel(0): EDID vendor "@@@", prod id 0
> > (II) intel(0): Printing DDC gathered Modelines:
> > (II) intel(0): Modeline "800x600"x0.0   40.00  800 840 968 1056  600 601 605 628 +hsync +vsync (37.9 kHz)
> > (II) intel(0): Modeline "800x600"x0.0   36.00  800 824 896 1024  600 601 603 625 +hsync +vsync (35.2 kHz)
> > (II) intel(0): Modeline "640x480"x0.0   31.50  640 656 720 840  480 481 484 500 -hsync -vsync (37.5 kHz)
> > (II) intel(0): Modeline "640x480"x0.0   31.50  640 664 704 832  480 489 491 520 -hsync -vsync (37.9 kHz)
> > (II) intel(0): Modeline "640x480"x0.0   30.24  640 704 768 864  480 483 486 525 -hsync -vsync (35.0 kHz)
> > (II) intel(0): Modeline "640x480"x0.0   25.20  640 656 752 800  480 490 492 525 -hsync -vsync (31.5 kHz)
> > (II) intel(0): Modeline "720x400"x0.0   28.32  720 738 846 900  400 412 414 449 -hsync +vsync (31.5 kHz)
> > (II) intel(0): Modeline "1024x768"x0.0   78.80  1024 1040 1136 1312  768 769 772 800 +hsync +vsync (60.1 kHz)
> > (II) intel(0): Modeline "1024x768"x0.0   75.00  1024 1048 1184 1328  768 771 777 806 -hsync -vsync (56.5 kHz)
> > (II) intel(0): Modeline "1024x768"x0.0   65.00  1024 1048 1184 1344  768 771 777 806 -hsync -vsync (48.4 kHz)
> > (II) intel(0): Modeline "832x624"x0.0   57.28  832 864 928 1152  624 625 628 667 -hsync -vsync (49.7 kHz)
> > (II) intel(0): Modeline "800x600"x0.0   49.50  800 816 896 1056  600 601 604 625 +hsync +vsync (46.9 kHz)
> > (II) intel(0): Modeline "800x600"x0.0   50.00  800 856 976 1040  600 637 643 666 +hsync +vsync (48.1 kHz)
> > (II) intel(0): EDID vendor "@@@", prod id 0
> > (II) intel(0): Output VGA connected
> > (II) intel(0): Using fuzzy aspect match for initial modes
> > (II) intel(0): Output VGA using initial mode 1280x960
> > (==) intel(0): Write-combining range (0xa0000,0x10000) was already clear
> > (II) intel(0): detected 128 kB GTT.
> > (II) intel(0): detected 8060 kB stolen memory.
> > (==) intel(0): video overlay key set to 0x101fe
> > (==) intel(0): Intel XvMC decoder disabled
> > (==) intel(0): Will not try to enable page flipping
> > (==) intel(0): Triple buffering disabled
> > (==) intel(0): Using gamma correction (1.0, 1.0, 1.0)
> > (**) intel(0): Display dimensions: (300, 230) mm
> > (**) intel(0): DPI set to (108, 141)
> > (II) Loading sub module "fb"
> > (II) LoadModule: "fb"
> > 
> > (II) Loading /usr/local/lib/xorg/modules//libfb.so
> > (II) Module fb: vendor="X.Org Foundation"
> > 	compiled for 1.5.3, module version = 1.0.0
> > 	ABI class: X.Org ANSI C Emulation, version 0.4
> > (II) Loading sub module "exa"
> > (II) LoadModule: "exa"
> > 
> > (II) Loading /usr/local/lib/xorg/modules//libexa.so
> > (II) Module exa: vendor="X.Org Foundation"
> > 	compiled for 1.5.3, module version = 2.4.0
> > 	ABI class: X.Org Video Driver, version 4.1
> > (II) Loading sub module "ramdac"
> > (II) LoadModule: "ramdac"
> > (II) Module "ramdac" already built-in
> > (II) intel(0): Comparing regs from server start up to After PreInit
> > (==) Depth 24 pixmap format is 32 bpp
> > (II) do I need RAC?  No, I don't.
> > (II) resource ranges after preInit:
> > 	[0] -1	0	0x00100000 - 0x3fffffff (0x3ff00000) MX[B]E(B)
> > 	[1] -1	0	0x000f0000 - 0x000fffff (0x10000) MX[B]
> > 	[2] -1	0	0x000c0000 - 0x000effff (0x30000) MX[B]
> > 	[3] -1	0	0x00000000 - 0x0009ffff (0xa0000) MX[B]
> > 	[4] 0	0	0x000a0000 - 0x000affff (0x10000) MS[B](OprD)
> > 	[5] 0	0	0x000b0000 - 0x000b7fff (0x8000) MS[B](OprD)
> > 	[6] 0	0	0x000b8000 - 0x000bffff (0x8000) MS[B](OprD)
> > 	[7] -1	0	0x0000ffff - 0x0000ffff (0x1) IX[B]
> > 	[8] -1	0	0x00000000 - 0x000000ff (0x100) IX[B]
> > 	[9] 0	0	0x000003b0 - 0x000003bb (0xc) IS[B](OprU)
> > 	[10] 0	0	0x000003c0 - 0x000003df (0x20) IS[B](OprU)
> > (II) intel(0): Kernel reported 112640 total, 0 used
> > (II) intel(0): I830CheckAvailableMemory: 450560 kB available
> > drmOpenDevice: node name is /dev/dri/card0
> > drmOpenDevice: open result is 11, (OK)
> > drmOpenDevice: node name is /dev/dri/card0
> > drmOpenDevice: open result is 11, (OK)
> > drmOpenByBusid: Searching for BusID pci:0000:00:02.0
> > drmOpenDevice: node name is /dev/dri/card0
> > drmOpenDevice: open result is 11, (OK)
> > drmOpenByBusid: drmOpenMinor returns 11
> > drmOpenByBusid: drmGetBusid reports pci:0000:00:02.0
> > (II) [drm] DRM interface version 1.2
> > (II) [drm] DRM open master succeeded.
> > (II) intel(0): [drm] Using the DRM lock SAREA also for drawables.
> > (II) intel(0): [drm] framebuffer mapped by ddx driver
> > (II) intel(0): [drm] added 1 reserved context for kernel
> > (II) intel(0): X context handle = 0x2
> > (II) intel(0): [drm] installed DRM signal handler
> > (**) intel(0): Framebuffer compression disabled
> > (**) intel(0): Tiling enabled
> > (==) intel(0): VideoRam: 131072 KB
> > (II) intel(0): Attempting memory allocation with tiled buffers.
> > (II) intel(0): Tiled allocation successful.
> > (II) intel(0): [drm] Registers = 0xffa80000
> > (II) intel(0): [drm] ring buffer = 0xf0000000
> > (II) intel(0): [drm] mapped front buffer at 0xf1000000, handle = 0xf1000000
> > (II) intel(0): [drm] mapped back buffer at 0xf4000000, handle = 0xf4000000
> > (II) intel(0): [drm] mapped depth buffer at 0xf5000000, handle = 0xf5000000
> > (II) intel(0): [drm] mapped classic textures at 0xf6000000, handle = 0xf6000000
> > (II) intel(0): [drm] Initialized kernel agp heap manager, 33554432
> > (II) intel(0): [dri] visual configs initialized
> > (II) intel(0): Page Flipping disabled
> > (II) intel(0): vgaHWGetIOBase: hwp->IOBase is 0x03d0, hwp->PIOOffset is 0x0000
> > (==) intel(0): Write-combining range (0xa0000,0x10000) was already clear
> > (II) EXA(0): Offscreen pixmap area of 31457280 bytes
> > (II) EXA(0): Driver registered support for the following operations:
> > (II)         Solid
> > (II)         Copy
> > (II)         Composite (RENDER acceleration)
> > (==) intel(0): Backing store disabled
> > (==) intel(0): Silken mouse enabled
> > (II) intel(0): Initializing HW Cursor
> > (II) intel(0): [DRI] installation complete
> > (II) intel(0): xf86BindGARTMemory: bind key 13 at 0x007df000 (pgoffset 2015)
> > (II) intel(0): xf86BindGARTMemory: bind key 14 at 0x01000000 (pgoffset 4096)
> > (II) intel(0): xf86BindGARTMemory: bind key 15 at 0x02000000 (pgoffset 8192)
> > (II) intel(0): xf86BindGARTMemory: bind key 16 at 0x04000000 (pgoffset 16384)
> > (II) intel(0): xf86BindGARTMemory: bind key 17 at 0x05000000 (pgoffset 20480)
> > (II) intel(0): xf86BindGARTMemory: bind key 18 at 0x06000000 (pgoffset 24576)
> > (II) intel(0): Fixed memory allocation layout:
> > (II) intel(0): 0x00000000-0x0001ffff: ring buffer (128 kB)
> > (II) intel(0): 0x00020000-0x00024fff: HW cursors (20 kB)
> > (II) intel(0): 0x00025000-0x0002cfff: logical 3D context (32 kB)
> > (II) intel(0): 0x0002d000-0x0012cfff: fake bufmgr (1024 kB)
> > (II) intel(0): 0x007df000:            end of stolen memory
> > (II) intel(0): 0x007df000-0x007dffff: overlay registers (4 kB, 0x00000000107c6000 physical
> > )
> > (II) intel(0): 0x01000000-0x01ffffff: front buffer (10240 kB) X tiled
> > (II) intel(0): 0x02000000-0x03dfffff: exa offscreen (30720 kB)
> > (II) intel(0): 0x04000000-0x04ffffff: back buffer (10240 kB) X tiled
> > (II) intel(0): 0x05000000-0x05ffffff: depth buffer (10240 kB) X tiled
> > (II) intel(0): 0x06000000-0x07ffffff: classic textures (32768 kB)
> > (II) intel(0): 0x08000000:            end of aperture
> > (WW) intel(0): PRB0_CTL (0x0001f001) indicates ring buffer enabled
> > (WW) intel(0): PRB0_HEAD (0x00000024) and PRB0_TAIL (0x00000068) indicate ring buffer not flushed
> > (WW) intel(0): Existing errors found in hardware state.
> > Error in I830WaitLpRing(), timeout for 2 seconds
> > pgetbl_ctl: 0x1ffe0001 getbl_err: 0x00000000
> > ipeir: 0x00000000 iphdr: 0x05000000
> > LP ring tail: 0x00000068 head: 0x00000024 len: 0x0001f001 start 0x00000000
> > eir: 0x0000 esr: 0x0000 emr: 0xff7b
> > instdone: 0xffc1 instpm: 0x0000
> > memmode: 0x00000000 instps: 0x00000040
> > hwstam: 0xffff ier: 0x0000 imr: 0xffff iir: 0x0000
> > Ring at virtual 0x28c00000 head 0x24 tail 0x68 count 17 acthd 0x311a8
> > Ring at virtual 0x28c00000 head 0x24 tail 0x68 count 17
> > Ring at virtual 0x28c00000 head 0x24 tail 0x68 count 17
> > Ring at virtual 0x28c00000 head 0x24 tail 0x68 count 17
> > Ring at virtual 0x28c00000 head 0x24 tail 0x68 count 17
> > Ring at virtual 0x28c00000 head 0x24 tail 0x68 count 17
> > Ring at virtual 0x28c00000 head 0x24 tail 0x68 count 17
> > Ring at virtual 0x28c00000 head 0x24 tail 0x68 count 17
> > Ring at virtual 0x28c00000 head 0x24 tail 0x68 count 17
> > Ring at virtual 0x28c00000 head 0x24 tail 0x68 count 17
> > Ring at virtual 0x28c00000 head 0x24 tail 0x68 count 17
> > Ring at virtual 0x28c00000 head 0x24 tail 0x68 count 17
> > Ring at virtual 0x28c00000 head 0x24 tail 0x68 count 17
> > Ring at virtual 0x28c00000 head 0x24 tail 0x68 count 17
> > Ring at virtual 0x28c00000 head 0x24 tail 0x68 count 17
> > Ring at virtual 0x28c00000 head 0x24 tail 0x68 count 17
> > Ring at virtual 0x28c00000 head 0x24 tail 0x68 count 17
> > Ring at virtual 0x28c00000 head 0x24 tail 0x68 count 17
> > Ring at virtual 0x28c00000 head 0x24 tail 0x68 count 17
> > Ring at virtual 0x28c00000 head 0x24 tail 0x68 count 17
> > Ring at virtual 0x28c00000 head 0x24 tail 0x68 count 17
> > Ring at virtual 0x28c00000 head 0x24 tail 0x68 count 17
> > Ring at virtual 0x28c00000 head 0x24 tail 0x68 count 17
> > Ring at virtual 0x28c00000 head 0x24 tail 0x68 count 17
> > Ring at virtual 0x28c00000 head 0x24 tail 0x68 count 17
> > Ring at virtual 0x28c00000 head 0x24 tail 0x68 count 17
> > Ring at virtual 0x28c00000 head 0x24 tail 0x68 count 17
> > Ring at virtual 0x28c00000 head 0x24 tail 0x68 count 17
> > Ring at virtual 0x28c00000 head 0x24 tail 0x68 count 17
> > Ring at virtual 0x28c00000 head 0x24 tail 0x68 count 17
> > Ring at virtual 0x28c00000 head 0x24 tail 0x68 count 17
> > Ring at virtual 0x28c00000 head 0x24 tail 0x68 count 17
> > Ring at virtual 0x28c00000 head 0x24 tail 0x68 count 17
> > Ring at virtual 0x28c00000 head 0x24 tail 0x68 count 17
> > Ring at virtual 0x28c00000 head 0x24 tail 0x68 count 17
> > Ring at virtual 0x28c00000 head 0x24 tail 0x68 count 17
> > Ring at virtual 0x28c00000 head 0x24 tail 0x68 count 17
> > Ring at virtual 0x28c00000 head 0x24 tail 0x68 count 17
> > Ring at virtual 0x28c00000 head 0x24 tail 0x68 count 17
> > Ring at virtual 0x28c00000 head 0x24 tail 0x68 count 17
> > Ring at virtual 0x28c00000 head 0x24 tail 0x68 count 17
> > Ring at virtual 0x28c00000 head 0x24 tail 0x68 count 17
> > Ring at virtual 0x28c00000 head 0x24 tail 0x68 count 17
> > Ring at virtual 0x28c00000 head 0x24 tail 0x68 count 17
> > Ring at virtual 0x28c00000 head 0x24 tail 0x68 count 17
> > Ring at virtual 0x28c00000 head 0x24 tail 0x68 count 17
> > Ring at virtual 0x28c00000 head 0x24 tail 0x68 count 17
> > Ring at virtual 0x28c00000 head 0x24 tail 0x68 count 17
> > Ring at virtual 0x28c00000 head 0x24 tail 0x68 count 17
> > Ring at virtual 0x28c00000 head 0x24 tail 0x68 count 17
> > Ring at virtual 0x28c00000 head 0x24 tail 0x68 count 17
> > Ring at virtual 0x28c00000 head 0x24 tail 0x68 count 17
> > Ring at virtual 0x28c00000 head 0x24 tail 0x68 count 17
> > Ring at virtual 0x28c00000 head 0x24 tail 0x68 count 17
> > Ring at virtual 0x28c00000 head 0x24 tail 0x68 count 17
> > Ring at virtual 0x28c00000 head 0x24 tail 0x68 count 17
> > Ring at virtual 0x28c00000 head 0x24 tail 0x68 count 17
> > Ring at virtual 0x28c00000 head 0x24 tail 0x68 count 17
> > Ring at virtual 0x28c00000 head 0x24 tail 0x68 count 17
> > Ring at virtual 0x28c00000 head 0x24 tail 0x68 count 17
> > Ring at virtual 0x28c00000 head 0x24 tail 0x68 count 17
> > Ring at virtual 0x28c00000 head 0x24 tail 0x68 count 17
> > Ring at virtual 0x28c00000 head 0x24 tail 0x68 count 17
> > Ring at virtual 0x28c00000 head 0x24 tail 0x68 count 17
> > Ring at virtual 0x28c00000 head 0x24 tail 0x68 count 17
> > Ring end
> > space: 130996 wanted 131064
> > (II) intel(0): [drm] removed 1 reserved context for kernel
> > (II) intel(0): [drm] unmapping 8192 bytes of SAREA 0xc325a000 at 0x286e0000
> > (II) intel(0): [drm] Closed DRM master.
> > 
> > Fatal server error:
> > lockup
> > 
> > _fence_emit_internal: drm_i915_irq_emit: -9
> 
> -- 
> Robert Noland <rnoland@FreeBSD.org>
> FreeBSD



-- 
Anton Shterenlikht
Room 2.6, Queen's Building
Mech Eng Dept
Bristol University
University Walk, Bristol BS8 1TR, UK
Tel: +44 (0)117 928 8233 
Fax: +44 (0)117 929 4423
From tinderbox at freebsd.org  Tue Feb  3 01:50:28 2009
From: tinderbox at freebsd.org (FreeBSD Tinderbox)
Date: Tue Feb  3 01:50:35 2009
Subject: [head tinderbox] failure on powerpc/powerpc
Message-ID: <20090203095022.8F01C7302F@freebsd-current.sentex.ca>

TB --- 2009-02-03 08:00:35 - tinderbox 2.6 running on freebsd-current.sentex.ca
TB --- 2009-02-03 08:00:35 - starting HEAD tinderbox run for powerpc/powerpc
TB --- 2009-02-03 08:00:35 - cleaning the object tree
TB --- 2009-02-03 08:01:03 - cvsupping the source tree
TB --- 2009-02-03 08:01:03 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/powerpc/powerpc/supfile
TB --- 2009-02-03 08:01:11 - building world
TB --- 2009-02-03 08:01:11 - MAKEOBJDIRPREFIX=/obj
TB --- 2009-02-03 08:01:11 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2009-02-03 08:01:11 - TARGET=powerpc
TB --- 2009-02-03 08:01:11 - TARGET_ARCH=powerpc
TB --- 2009-02-03 08:01:11 - TZ=UTC
TB --- 2009-02-03 08:01:11 - __MAKE_CONF=/dev/null
TB --- 2009-02-03 08:01:11 - cd /src
TB --- 2009-02-03 08:01:11 - /usr/bin/make -B buildworld
>>> World build started on Tue Feb  3 08:01:13 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 Feb  3 09:26:51 UTC 2009
TB --- 2009-02-03 09:26:51 - generating LINT kernel config
TB --- 2009-02-03 09:26:51 - cd /src/sys/powerpc/conf
TB --- 2009-02-03 09:26:51 - /usr/bin/make -B LINT
TB --- 2009-02-03 09:26:51 - building LINT kernel
TB --- 2009-02-03 09:26:51 - MAKEOBJDIRPREFIX=/obj
TB --- 2009-02-03 09:26:51 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2009-02-03 09:26:51 - TARGET=powerpc
TB --- 2009-02-03 09:26:51 - TARGET_ARCH=powerpc
TB --- 2009-02-03 09:26:51 - TZ=UTC
TB --- 2009-02-03 09:26:51 - __MAKE_CONF=/dev/null
TB --- 2009-02-03 09:26:51 - cd /src
TB --- 2009-02-03 09:26:51 - /usr/bin/make -B buildkernel KERNCONF=LINT
>>> Kernel build for LINT started on Tue Feb  3 09:26:51 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/modules/usb2/quirk/../../../dev/usb2/quirk/usb2_quirk.c:115: warning: data definition has no type or storage class
/src/sys/modules/usb2/quirk/../../../dev/usb2/quirk/usb2_quirk.c:115: warning: type defaults to 'int' in declaration of 'USB_MAKE_DEBUG_TABLE'
/src/sys/modules/usb2/quirk/../../../dev/usb2/quirk/usb2_quirk.c:115: warning: parameter names (without types) in function declaration
/src/sys/modules/usb2/quirk/../../../dev/usb2/quirk/usb2_quirk.c: In function 'usb2_quirkstr':
/src/sys/modules/usb2/quirk/../../../dev/usb2/quirk/usb2_quirk.c:126: error: 'USB_QUIRK' undeclared (first use in this function)
/src/sys/modules/usb2/quirk/../../../dev/usb2/quirk/usb2_quirk.c:126: error: (Each undeclared identifier is reported only once
/src/sys/modules/usb2/quirk/../../../dev/usb2/quirk/usb2_quirk.c:126: error: for each function it appears in.)
*** Error code 1

Stop in /src/sys/modules/usb2/quirk.
*** Error code 1

Stop in /src/sys/modules/usb2.
*** Error code 1

Stop in /src/sys/modules.
*** Error code 1

Stop in /obj/powerpc/src/sys/LINT.
*** Error code 1

Stop in /src.
*** Error code 1

Stop in /src.
TB --- 2009-02-03 09:50:22 - WARNING: /usr/bin/make returned exit code  1 
TB --- 2009-02-03 09:50:22 - ERROR: failed to build lint kernel
TB --- 2009-02-03 09:50:22 - 5241.75 user 430.15 system 6587.04 real


http://tinderbox.des.no/tinderbox-head-HEAD-powerpc-powerpc.full
From daichi at ongs.co.jp  Tue Feb  3 02:04:40 2009
From: daichi at ongs.co.jp (Daichi GOTO)
Date: Tue Feb  3 02:04:46 2009
Subject: FreeBSD 8-current/amd64 very slowly loader(8) issue
Message-ID: <498816B6.6020404@ongs.co.jp>

I have moved my main work pc from i386 FreeBSD to amd64
to get more memory use and ZFS checking.

I'm wondering why loader loads kernel and kernel modules
very slowly.

   [M/B and CPU info]
   # dmidecode
   (snip)
   Base Board Information
          Manufacturer: Gigabyte Technology Co., Ltd.
           Product Name: EP45-UD3LR
           Version: x.x
           Serial Number:
   (snip)
           Version: Intel(R) Core(TM)2 Quad CPU
           Voltage: 1.0 V
           External Clock: 333 MHz
           Max Speed: 4000 MHz
           Current Speed: 2500 MHz
           Status: Populated, Enabled
           Upgrade: Socket 478
   (snip)
           Maximum Memory Module Size: 1024 MB
           Maximum Total Memory Size: 4096 MB
   (snip)
   #

FreeBSD amd64 on the other work pc (E6600, DP965LT, 2GB mem),
loader works incredible slow, but after I changed BIOS CMOS
config turning AHCI off, it works very well.

So I am doubting AHCI works well, but turing off AHCI feature of
EP45-UD3LR M/B, amd64 loader still remains in very slow working.

Anyone has any ideas?
Thanks

-- 
   Daichi GOTO, http://people.freebsd.org/~daichi
From hselasky at c2i.net  Tue Feb  3 02:28:09 2009
From: hselasky at c2i.net (Hans Petter Selasky)
Date: Tue Feb  3 02:28:22 2009
Subject: [head tinderbox] failure on powerpc/powerpc
In-Reply-To: <20090203095022.8F01C7302F@freebsd-current.sentex.ca>
References: <20090203095022.8F01C7302F@freebsd-current.sentex.ca>
Message-ID: <200902031130.31244.hselasky@c2i.net>

On Tuesday 03 February 2009, FreeBSD Tinderbox wrote:

> [...]
> cc1: warnings being treated as errors
> /src/sys/modules/usb2/quirk/../../../dev/usb2/quirk/usb2_quirk.c:115:
> warning: data definition has no type or storage class
> /src/sys/modules/usb2/quirk/../../../dev/usb2/quirk/usb2_quirk.c:115:
> warning: type defaults to 'int' in declaration of 'USB_MAKE_DEBUG_TABLE'
> /src/sys/modules/usb2/quirk/../../../dev/usb2/quirk/usb2_quirk.c:115:
> warning: parameter names (without types) in function declaration
> /src/sys/modules/usb2/quirk/../../../dev/usb2/quirk/usb2_quirk.c: In
> function 'usb2_quirkstr':
> /src/sys/modules/usb2/quirk/../../../dev/usb2/quirk/usb2_quirk.c:126:
> error: 'USB_QUIRK' undeclared (first use in this function)
> /src/sys/modules/usb2/quirk/../../../dev/usb2/quirk/usb2_quirk.c:126:
> error: (Each undeclared identifier is reported only once
> /src/sys/modules/usb2/quirk/../../../dev/usb2/quirk/usb2_quirk.c:126:
> error: for each function it appears in.) *** Error code 1
>

Hi,

I don't know who is fixing this issue. If noone is, then here is what needs to 
be reverted:

==== //depot/vendor/freebsd/src/sys/dev/usb2/include/usb2_error.h#2 
(text+ko) - //depot/projects/usb/src/sys/dev/usb2/include/usb2_error.h#4 
(text+ko) ==== content
@@ -1,4 +1,4 @@
-/* $FreeBSD: src/sys/dev/usb2/include/usb2_error.h,v 1.2 2009/02/03 05:50:36 
thompsa Exp $ */
+/* $FreeBSD: src/sys/dev/usb2/include/usb2_error.h,v 1.1 2008/11/04 02:31:03 
alfred Exp $ */
 /*-
  * Copyright (c) 2008 Hans Petter Selasky. All rights reserved.
  *

==== //depot/vendor/freebsd/src/sys/dev/usb2/include/usb2_mfunc.h#2 
(text+ko) - //depot/projects/usb/src/sys/dev/usb2/include/usb2_mfunc.h#4 
(text+ko) ==== content
@@ -1,4 +1,4 @@
-/* $FreeBSD: src/sys/dev/usb2/include/usb2_mfunc.h,v 1.2 2009/02/03 05:50:36 
thompsa Exp $ */
+/* $FreeBSD: src/sys/dev/usb2/include/usb2_mfunc.h,v 1.1 2008/11/04 02:31:03 
alfred Exp $ */

==== //depot/vendor/freebsd/src/sys/dev/usb2/include/usb2_revision.h#2 
(text+ko) - //depot/projects/usb/src/sys/dev/usb2/include/usb2_revision.h#6 
(text+ko) ==== content
@@ -1,4 +1,4 @@
-/* $FreeBSD: src/sys/dev/usb2/include/usb2_revision.h,v 1.2 2009/02/03 
05:50:36 thompsa Exp $ */
+/* $FreeBSD: src/sys/dev/usb2/include/usb2_revision.h,v 1.1 2008/11/04 
02:31:03 alfred Exp $ */

==== //depot/vendor/freebsd/src/sys/dev/usb2/quirk/usb2_quirk.h#2 
(text+ko) - //depot/projects/usb/src/sys/dev/usb2/quirk/usb2_quirk.h#6 
(text+ko) ==== content
@@ -1,4 +1,4 @@
-/* $FreeBSD: src/sys/dev/usb2/quirk/usb2_quirk.h,v 1.2 2009/02/03 05:50:36 
thompsa Exp $ */
+/* $FreeBSD: src/sys/dev/usb2/quirk/usb2_quirk.h,v 1.1 2008/11/04 02:31:03 
alfred Exp $ */

==== //depot/vendor/freebsd/src/sys/dev/usb2/core/usb2_error.c#3 
(text+ko) - //depot/projects/usb/src/sys/dev/usb2/core/usb2_error.c#5 
(text+ko) ==== content
@@ -1,4 +1,4 @@
-/* $FreeBSD: src/sys/dev/usb2/core/usb2_error.c,v 1.3 2009/02/03 05:50:36 
thompsa Exp $ */
+/* $FreeBSD: src/sys/dev/usb2/core/usb2_error.c,v 1.2 2008/12/11 23:13:02 
thompsa Exp $ */


--HPS
From hselasky at c2i.net  Tue Feb  3 02:28:09 2009
From: hselasky at c2i.net (Hans Petter Selasky)
Date: Tue Feb  3 02:28:23 2009
Subject: [head tinderbox] failure on powerpc/powerpc
In-Reply-To: <20090203095022.8F01C7302F@freebsd-current.sentex.ca>
References: <20090203095022.8F01C7302F@freebsd-current.sentex.ca>
Message-ID: <200902031130.31244.hselasky@c2i.net>

On Tuesday 03 February 2009, FreeBSD Tinderbox wrote:

> [...]
> cc1: warnings being treated as errors
> /src/sys/modules/usb2/quirk/../../../dev/usb2/quirk/usb2_quirk.c:115:
> warning: data definition has no type or storage class
> /src/sys/modules/usb2/quirk/../../../dev/usb2/quirk/usb2_quirk.c:115:
> warning: type defaults to 'int' in declaration of 'USB_MAKE_DEBUG_TABLE'
> /src/sys/modules/usb2/quirk/../../../dev/usb2/quirk/usb2_quirk.c:115:
> warning: parameter names (without types) in function declaration
> /src/sys/modules/usb2/quirk/../../../dev/usb2/quirk/usb2_quirk.c: In
> function 'usb2_quirkstr':
> /src/sys/modules/usb2/quirk/../../../dev/usb2/quirk/usb2_quirk.c:126:
> error: 'USB_QUIRK' undeclared (first use in this function)
> /src/sys/modules/usb2/quirk/../../../dev/usb2/quirk/usb2_quirk.c:126:
> error: (Each undeclared identifier is reported only once
> /src/sys/modules/usb2/quirk/../../../dev/usb2/quirk/usb2_quirk.c:126:
> error: for each function it appears in.) *** Error code 1
>

Hi,

I don't know who is fixing this issue. If noone is, then here is what needs to 
be reverted:

==== //depot/vendor/freebsd/src/sys/dev/usb2/include/usb2_error.h#2 
(text+ko) - //depot/projects/usb/src/sys/dev/usb2/include/usb2_error.h#4 
(text+ko) ==== content
@@ -1,4 +1,4 @@
-/* $FreeBSD: src/sys/dev/usb2/include/usb2_error.h,v 1.2 2009/02/03 05:50:36 
thompsa Exp $ */
+/* $FreeBSD: src/sys/dev/usb2/include/usb2_error.h,v 1.1 2008/11/04 02:31:03 
alfred Exp $ */
 /*-
  * Copyright (c) 2008 Hans Petter Selasky. All rights reserved.
  *

==== //depot/vendor/freebsd/src/sys/dev/usb2/include/usb2_mfunc.h#2 
(text+ko) - //depot/projects/usb/src/sys/dev/usb2/include/usb2_mfunc.h#4 
(text+ko) ==== content
@@ -1,4 +1,4 @@
-/* $FreeBSD: src/sys/dev/usb2/include/usb2_mfunc.h,v 1.2 2009/02/03 05:50:36 
thompsa Exp $ */
+/* $FreeBSD: src/sys/dev/usb2/include/usb2_mfunc.h,v 1.1 2008/11/04 02:31:03 
alfred Exp $ */

==== //depot/vendor/freebsd/src/sys/dev/usb2/include/usb2_revision.h#2 
(text+ko) - //depot/projects/usb/src/sys/dev/usb2/include/usb2_revision.h#6 
(text+ko) ==== content
@@ -1,4 +1,4 @@
-/* $FreeBSD: src/sys/dev/usb2/include/usb2_revision.h,v 1.2 2009/02/03 
05:50:36 thompsa Exp $ */
+/* $FreeBSD: src/sys/dev/usb2/include/usb2_revision.h,v 1.1 2008/11/04 
02:31:03 alfred Exp $ */

==== //depot/vendor/freebsd/src/sys/dev/usb2/quirk/usb2_quirk.h#2 
(text+ko) - //depot/projects/usb/src/sys/dev/usb2/quirk/usb2_quirk.h#6 
(text+ko) ==== content
@@ -1,4 +1,4 @@
-/* $FreeBSD: src/sys/dev/usb2/quirk/usb2_quirk.h,v 1.2 2009/02/03 05:50:36 
thompsa Exp $ */
+/* $FreeBSD: src/sys/dev/usb2/quirk/usb2_quirk.h,v 1.1 2008/11/04 02:31:03 
alfred Exp $ */

==== //depot/vendor/freebsd/src/sys/dev/usb2/core/usb2_error.c#3 
(text+ko) - //depot/projects/usb/src/sys/dev/usb2/core/usb2_error.c#5 
(text+ko) ==== content
@@ -1,4 +1,4 @@
-/* $FreeBSD: src/sys/dev/usb2/core/usb2_error.c,v 1.3 2009/02/03 05:50:36 
thompsa Exp $ */
+/* $FreeBSD: src/sys/dev/usb2/core/usb2_error.c,v 1.2 2008/12/11 23:13:02 
thompsa Exp $ */


--HPS
From tinderbox at freebsd.org  Tue Feb  3 02:39:35 2009
From: tinderbox at freebsd.org (FreeBSD Tinderbox)
Date: Tue Feb  3 02:39:49 2009
Subject: [head tinderbox] failure on sparc64/sparc64
Message-ID: <20090203103931.D84687302F@freebsd-current.sentex.ca>

TB --- 2009-02-03 08:55:23 - tinderbox 2.6 running on freebsd-current.sentex.ca
TB --- 2009-02-03 08:55:23 - starting HEAD tinderbox run for sparc64/sparc64
TB --- 2009-02-03 08:55:23 - cleaning the object tree
TB --- 2009-02-03 08:55:53 - cvsupping the source tree
TB --- 2009-02-03 08:55:53 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/sparc64/sparc64/supfile
TB --- 2009-02-03 08:56:00 - building world
TB --- 2009-02-03 08:56:00 - MAKEOBJDIRPREFIX=/obj
TB --- 2009-02-03 08:56:00 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2009-02-03 08:56:00 - TARGET=sparc64
TB --- 2009-02-03 08:56:00 - TARGET_ARCH=sparc64
TB --- 2009-02-03 08:56:00 - TZ=UTC
TB --- 2009-02-03 08:56:00 - __MAKE_CONF=/dev/null
TB --- 2009-02-03 08:56:00 - cd /src
TB --- 2009-02-03 08:56:00 - /usr/bin/make -B buildworld
>>> World build started on Tue Feb  3 08:56:02 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 Feb  3 10:14:08 UTC 2009
TB --- 2009-02-03 10:14:08 - generating LINT kernel config
TB --- 2009-02-03 10:14:08 - cd /src/sys/sparc64/conf
TB --- 2009-02-03 10:14:08 - /usr/bin/make -B LINT
TB --- 2009-02-03 10:14:08 - building LINT kernel
TB --- 2009-02-03 10:14:08 - MAKEOBJDIRPREFIX=/obj
TB --- 2009-02-03 10:14:08 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2009-02-03 10:14:08 - TARGET=sparc64
TB --- 2009-02-03 10:14:08 - TARGET_ARCH=sparc64
TB --- 2009-02-03 10:14:08 - TZ=UTC
TB --- 2009-02-03 10:14:08 - __MAKE_CONF=/dev/null
TB --- 2009-02-03 10:14:08 - cd /src
TB --- 2009-02-03 10:14:08 - /usr/bin/make -B buildkernel KERNCONF=LINT
>>> Kernel build for LINT started on Tue Feb  3 10:14: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
[...]
cc1: warnings being treated as errors
/src/sys/modules/usb2/quirk/../../../dev/usb2/quirk/usb2_quirk.c:115: warning: data definition has no type or storage class
/src/sys/modules/usb2/quirk/../../../dev/usb2/quirk/usb2_quirk.c:115: warning: type defaults to 'int' in declaration of 'USB_MAKE_DEBUG_TABLE'
/src/sys/modules/usb2/quirk/../../../dev/usb2/quirk/usb2_quirk.c:115: warning: parameter names (without types) in function declaration
/src/sys/modules/usb2/quirk/../../../dev/usb2/quirk/usb2_quirk.c: In function 'usb2_quirkstr':
/src/sys/modules/usb2/quirk/../../../dev/usb2/quirk/usb2_quirk.c:126: error: 'USB_QUIRK' undeclared (first use in this function)
/src/sys/modules/usb2/quirk/../../../dev/usb2/quirk/usb2_quirk.c:126: error: (Each undeclared identifier is reported only once
/src/sys/modules/usb2/quirk/../../../dev/usb2/quirk/usb2_quirk.c:126: error: for each function it appears in.)
*** Error code 1

Stop in /src/sys/modules/usb2/quirk.
*** Error code 1

Stop in /src/sys/modules/usb2.
*** Error code 1

Stop in /src/sys/modules.
*** Error code 1

Stop in /obj/sparc64/src/sys/LINT.
*** Error code 1

Stop in /src.
*** Error code 1

Stop in /src.
TB --- 2009-02-03 10:39:31 - WARNING: /usr/bin/make returned exit code  1 
TB --- 2009-02-03 10:39:31 - ERROR: failed to build lint kernel
TB --- 2009-02-03 10:39:31 - 5103.84 user 433.73 system 6248.11 real


http://tinderbox.des.no/tinderbox-head-HEAD-sparc64-sparc64.full
From tinderbox at freebsd.org  Tue Feb  3 03:29:06 2009
From: tinderbox at freebsd.org (FreeBSD Tinderbox)
Date: Tue Feb  3 03:29:12 2009
Subject: [head tinderbox] failure on sparc64/sun4v
Message-ID: <20090203112903.15F027302F@freebsd-current.sentex.ca>

TB --- 2009-02-03 09:50:22 - tinderbox 2.6 running on freebsd-current.sentex.ca
TB --- 2009-02-03 09:50:22 - starting HEAD tinderbox run for sparc64/sun4v
TB --- 2009-02-03 09:50:22 - cleaning the object tree
TB --- 2009-02-03 09:50:50 - cvsupping the source tree
TB --- 2009-02-03 09:50:50 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/sparc64/sun4v/supfile
TB --- 2009-02-03 09:50:58 - building world
TB --- 2009-02-03 09:50:58 - MAKEOBJDIRPREFIX=/obj
TB --- 2009-02-03 09:50:58 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2009-02-03 09:50:58 - TARGET=sun4v
TB --- 2009-02-03 09:50:58 - TARGET_ARCH=sparc64
TB --- 2009-02-03 09:50:58 - TZ=UTC
TB --- 2009-02-03 09:50:58 - __MAKE_CONF=/dev/null
TB --- 2009-02-03 09:50:58 - cd /src
TB --- 2009-02-03 09:50:58 - /usr/bin/make -B buildworld
>>> World build started on Tue Feb  3 09:50:59 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 Feb  3 11:06:03 UTC 2009
TB --- 2009-02-03 11:06:03 - generating LINT kernel config
TB --- 2009-02-03 11:06:03 - cd /src/sys/sun4v/conf
TB --- 2009-02-03 11:06:03 - /usr/bin/make -B LINT
TB --- 2009-02-03 11:06:03 - building LINT kernel
TB --- 2009-02-03 11:06:03 - MAKEOBJDIRPREFIX=/obj
TB --- 2009-02-03 11:06:03 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2009-02-03 11:06:03 - TARGET=sun4v
TB --- 2009-02-03 11:06:03 - TARGET_ARCH=sparc64
TB --- 2009-02-03 11:06:03 - TZ=UTC
TB --- 2009-02-03 11:06:03 - __MAKE_CONF=/dev/null
TB --- 2009-02-03 11:06:03 - cd /src
TB --- 2009-02-03 11:06:03 - /usr/bin/make -B buildkernel KERNCONF=LINT
>>> Kernel build for LINT started on Tue Feb  3 11:06: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/modules/usb2/quirk/../../../dev/usb2/quirk/usb2_quirk.c:115: warning: data definition has no type or storage class
/src/sys/modules/usb2/quirk/../../../dev/usb2/quirk/usb2_quirk.c:115: warning: type defaults to 'int' in declaration of 'USB_MAKE_DEBUG_TABLE'
/src/sys/modules/usb2/quirk/../../../dev/usb2/quirk/usb2_quirk.c:115: warning: parameter names (without types) in function declaration
/src/sys/modules/usb2/quirk/../../../dev/usb2/quirk/usb2_quirk.c: In function 'usb2_quirkstr':
/src/sys/modules/usb2/quirk/../../../dev/usb2/quirk/usb2_quirk.c:126: error: 'USB_QUIRK' undeclared (first use in this function)
/src/sys/modules/usb2/quirk/../../../dev/usb2/quirk/usb2_quirk.c:126: error: (Each undeclared identifier is reported only once
/src/sys/modules/usb2/quirk/../../../dev/usb2/quirk/usb2_quirk.c:126: error: for each function it appears in.)
*** Error code 1

Stop in /src/sys/modules/usb2/quirk.
*** Error code 1

Stop in /src/sys/modules/usb2.
*** Error code 1

Stop in /src/sys/modules.
*** Error code 1

Stop in /obj/sun4v/src/sys/LINT.
*** Error code 1

Stop in /src.
*** Error code 1

Stop in /src.
TB --- 2009-02-03 11:29:03 - WARNING: /usr/bin/make returned exit code  1 
TB --- 2009-02-03 11:29:03 - ERROR: failed to build lint kernel
TB --- 2009-02-03 11:29:03 - 5079.16 user 430.36 system 5920.31 real


http://tinderbox.des.no/tinderbox-head-HEAD-sparc64-sun4v.full
From marius at nuenneri.ch  Tue Feb  3 04:22:56 2009
From: marius at nuenneri.ch (=?ISO-8859-1?Q?Marius_N=FCnnerich?=)
Date: Tue Feb  3 04:23:28 2009
Subject: GEOM_PART: a quick update on logical partitions
In-Reply-To: <20090203082153.565746e2@zelda.local>
References: <FCA8C5E4-BC41-4711-9EBC-CD692144F6B8@mac.com>
	<20090203082153.565746e2@zelda.local>
Message-ID: <b649e5e0902030357k7508b4e7kc69c31a354b3e077@mail.gmail.com>

On Tue, Feb 3, 2009 at 8:21 AM, Martin <nakal@web.de> wrote:
> Am Mon, 02 Feb 2009 11:16:53 -0800
> schrieb Marcel Moolenaar <xcllnt@mac.com>:
>
>>       /dev/da0s2.00000000
>>       /dev/da0s2.0834F7A0
>>       /dev/da0s5 -> /dev/da0s2.00000000
>>       /dev/da0s6 -> /dev/da0s2.0834F7A0
>
> Hi.
>
> As far as I remember, the old MS-DOS scheme for partitioning
> (we have GPT now ;) that I am happy with) implements these logical
> partitions as a linked list. Why not have a simple index pointing to
> the list entry?
>
> Something like this:
>
> /dev/da0s2.1
> /dev/da0s2.2
>
> Might be starting with 1 or perhaps 0.
>
>
> Second thing is, why do you need something like "s5"? I don't like
> these symlinks, because I don't see how you want to support something
> like ".eli" oder ".eli.journal" etc.

I'm not happy with the symlinks either. When someone is manipulating a
partition table she should be able to live with the consequences. I
would rather go for the UUID in UFS header approach if there is enough
room. BTW I implemented GPT UUID glabels a while ago please see:
http://www.freebsd.org/cgi/query-pr.cgi?pr=128398
From bzeeb-lists at lists.zabbadoz.net  Tue Feb  3 05:00:09 2009
From: bzeeb-lists at lists.zabbadoz.net (Bjoern A. Zeeb)
Date: Tue Feb  3 05:00:18 2009
Subject: panic caused by mpd5
In-Reply-To: <1868132185.26927.1233639921805.JavaMail.apache@mail51.abv.bg>
References: <1868132185.26927.1233639921805.JavaMail.apache@mail51.abv.bg>
Message-ID: <20090203125341.Y93725@maildrop.int.zabbadoz.net>

On Tue, 3 Feb 2009, Mario Pavlov wrote:

Hi,

> I don't know what else could be useful
> just tell me what you need and I'll provide it

you could have at least typed "bt" or resolved the line number to the
right piece of code as you seem to run HEAD which can change
frequently.

http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/kerneldebug.html
has some info on how to debug things.


> btw what is r187946 ?

The SVN revision number of a commit:
http://svn.freebsd.org/viewvc/base?view=revision&revision=187946


If you want to run HEAD, try to update your source, rebuild the kernel
and see if you can still reproduce it. If you can, start debugging along
the above information.


/bz

-- 
Bjoern A. Zeeb                      The greatest risk is not taking one.
From ivoras at freebsd.org  Tue Feb  3 05:06:52 2009
From: ivoras at freebsd.org (Ivan Voras)
Date: Tue Feb  3 05:07:00 2009
Subject: GEOM_PART: a quick update on logical partitions
In-Reply-To: <b649e5e0902030357k7508b4e7kc69c31a354b3e077@mail.gmail.com>
References: <FCA8C5E4-BC41-4711-9EBC-CD692144F6B8@mac.com>	<20090203082153.565746e2@zelda.local>
	<b649e5e0902030357k7508b4e7kc69c31a354b3e077@mail.gmail.com>
Message-ID: <gm9fh1$4el$1@ger.gmane.org>

Marius N?nnerich wrote:

> I'm not happy with the symlinks either. When someone is manipulating a
> partition table she should be able to live with the consequences. I
> would rather go for the UUID in UFS header approach if there is enough
> room. BTW I implemented GPT UUID glabels a while ago please see:
> http://www.freebsd.org/cgi/query-pr.cgi?pr=128398

I have a patch for UFS "GUID" labels (not exactly GUIDs, but every UFS
file system has a reasonably unique ID associated with it) but have
encountered what seems a bug in GEOM slicers - two dev entries pointing
to the same device don't work well with orphaning/tasting. Have you
encountered something similar perhaps?

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 252 bytes
Desc: OpenPGP digital signature
Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20090203/824b9b2b/signature.pgp
From tinderbox at freebsd.org  Tue Feb  3 06:05:32 2009
From: tinderbox at freebsd.org (FreeBSD Tinderbox)
Date: Tue Feb  3 06:05:46 2009
Subject: [head tinderbox] failure on amd64/amd64
Message-ID: <20090203140527.E07027302F@freebsd-current.sentex.ca>

TB --- 2009-02-03 11:40:00 - tinderbox 2.6 running on freebsd-current.sentex.ca
TB --- 2009-02-03 11:40:00 - starting HEAD tinderbox run for amd64/amd64
TB --- 2009-02-03 11:40:00 - cleaning the object tree
TB --- 2009-02-03 11:40:52 - cvsupping the source tree
TB --- 2009-02-03 11:40:52 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/amd64/amd64/supfile
TB --- 2009-02-03 11:41:01 - building world
TB --- 2009-02-03 11:41:01 - MAKEOBJDIRPREFIX=/obj
TB --- 2009-02-03 11:41:01 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2009-02-03 11:41:01 - TARGET=amd64
TB --- 2009-02-03 11:41:01 - TARGET_ARCH=amd64
TB --- 2009-02-03 11:41:01 - TZ=UTC
TB --- 2009-02-03 11:41:01 - __MAKE_CONF=/dev/null
TB --- 2009-02-03 11:41:01 - cd /src
TB --- 2009-02-03 11:41:01 - /usr/bin/make -B buildworld
>>> World build started on Tue Feb  3 11:41:02 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 Tue Feb  3 13:37:31 UTC 2009
TB --- 2009-02-03 13:37:31 - generating LINT kernel config
TB --- 2009-02-03 13:37:31 - cd /src/sys/amd64/conf
TB --- 2009-02-03 13:37:31 - /usr/bin/make -B LINT
TB --- 2009-02-03 13:37:31 - building LINT kernel
TB --- 2009-02-03 13:37:31 - MAKEOBJDIRPREFIX=/obj
TB --- 2009-02-03 13:37:31 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2009-02-03 13:37:31 - TARGET=amd64
TB --- 2009-02-03 13:37:31 - TARGET_ARCH=amd64
TB --- 2009-02-03 13:37:31 - TZ=UTC
TB --- 2009-02-03 13:37:31 - __MAKE_CONF=/dev/null
TB --- 2009-02-03 13:37:31 - cd /src
TB --- 2009-02-03 13:37:31 - /usr/bin/make -B buildkernel KERNCONF=LINT
>>> Kernel build for LINT started on Tue Feb  3 13:37: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
[...]
cc1: warnings being treated as errors
/src/sys/modules/usb2/quirk/../../../dev/usb2/quirk/usb2_quirk.c:115: warning: data definition has no type or storage class
/src/sys/modules/usb2/quirk/../../../dev/usb2/quirk/usb2_quirk.c:115: warning: type defaults to 'int' in declaration of 'USB_MAKE_DEBUG_TABLE'
/src/sys/modules/usb2/quirk/../../../dev/usb2/quirk/usb2_quirk.c:115: warning: parameter names (without types) in function declaration
/src/sys/modules/usb2/quirk/../../../dev/usb2/quirk/usb2_quirk.c: In function 'usb2_quirkstr':
/src/sys/modules/usb2/quirk/../../../dev/usb2/quirk/usb2_quirk.c:126: error: 'USB_QUIRK' undeclared (first use in this function)
/src/sys/modules/usb2/quirk/../../../dev/usb2/quirk/usb2_quirk.c:126: error: (Each undeclared identifier is reported only once
/src/sys/modules/usb2/quirk/../../../dev/usb2/quirk/usb2_quirk.c:126: error: for each function it appears in.)
*** Error code 1

Stop in /src/sys/modules/usb2/quirk.
*** Error code 1

Stop in /src/sys/modules/usb2.
*** Error code 1

Stop in /src/sys/modules.
*** Error code 1

Stop in /obj/amd64/src/sys/LINT.
*** Error code 1

Stop in /src.
*** Error code 1

Stop in /src.
TB --- 2009-02-03 14:05:27 - WARNING: /usr/bin/make returned exit code  1 
TB --- 2009-02-03 14:05:27 - ERROR: failed to build lint kernel
TB --- 2009-02-03 14:05:27 - 6972.12 user 664.45 system 8727.40 real


http://tinderbox.des.no/tinderbox-head-HEAD-amd64-amd64.full
From ganbold at micom.mng.net  Tue Feb  3 06:16:04 2009
From: ganbold at micom.mng.net (Ganbold)
Date: Tue Feb  3 06:16:11 2009
Subject: process hang in zfs->io_ ?
In-Reply-To: <20090201105815.GA73985@hyperion.scode.org>
References: <6eb82e0902010024o4094b3a6q3186f2109029a67a@mail.gmail.com>
	<20090201105815.GA73985@hyperion.scode.org>
Message-ID: <4988519E.2070103@micom.mng.net>

Peter Schuller wrote:
>> I'm running current as of 20080130 on an amd64 box. I can make
>> processes stuck in zfs->io_ (output truncated in ddb and top) when I
>> make some packages via ports tinderbox. The ports tinderbox access
>> local disk via nfs (I also tried nullfs).
>>
>> ddb output of ps and alltrace can be found at
>>
>> http://www.rafan.org/FreeBSD/zfs/textdump.zfs.20090130.txt
>>
>> Any ideas?
>>     
>
> A workaround is to disable the ZIL (vfs.zfs.zil_disable="1"), if you
> can afford that on the system in question. It will break the
> durability of fsync(), but retain it's write barrier semantics.
>
> Btw, does anyone have a good grasp of the status of this bug? I have
> seen vague referenced to it being a memory related deadlock for
> example, but that's about it. Is the cause known but difficult to fix,
> or just unknown?
>   

I've observed similar system hang when I tried to run svn update on
FreeBSD head repo
from 2 local directories simultaneously. I might be doing something
wrong and as
I remember I reproduced it a couple of times.

It is i386 CURRENT (r187663M) machine and loader.conf settings are:
vm.kmem_size="1024M"
vm.kmem_size_max="1024M"
vfs.zfs.arc_max="100M"

thanks,

Ganbold

From tinderbox at freebsd.org  Tue Feb  3 06:37:33 2009
From: tinderbox at freebsd.org (FreeBSD Tinderbox)
Date: Tue Feb  3 06:37:41 2009
Subject: [head tinderbox] failure on i386/i386
Message-ID: <20090203143730.2CC3C7302F@freebsd-current.sentex.ca>

TB --- 2009-02-03 12:46:19 - tinderbox 2.6 running on freebsd-current.sentex.ca
TB --- 2009-02-03 12:46:19 - starting HEAD tinderbox run for i386/i386
TB --- 2009-02-03 12:46:19 - cleaning the object tree
TB --- 2009-02-03 12:46:52 - cvsupping the source tree
TB --- 2009-02-03 12:46:52 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/i386/i386/supfile
TB --- 2009-02-03 12:47:01 - building world
TB --- 2009-02-03 12:47:01 - MAKEOBJDIRPREFIX=/obj
TB --- 2009-02-03 12:47:01 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2009-02-03 12:47:01 - TARGET=i386
TB --- 2009-02-03 12:47:01 - TARGET_ARCH=i386
TB --- 2009-02-03 12:47:01 - TZ=UTC
TB --- 2009-02-03 12:47:01 - __MAKE_CONF=/dev/null
TB --- 2009-02-03 12:47:01 - cd /src
TB --- 2009-02-03 12:47:01 - /usr/bin/make -B buildworld
>>> World build started on Tue Feb  3 12:47:05 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 Feb  3 14:07:10 UTC 2009
TB --- 2009-02-03 14:07:10 - generating LINT kernel config
TB --- 2009-02-03 14:07:10 - cd /src/sys/i386/conf
TB --- 2009-02-03 14:07:10 - /usr/bin/make -B LINT
TB --- 2009-02-03 14:07:11 - building LINT kernel
TB --- 2009-02-03 14:07:11 - MAKEOBJDIRPREFIX=/obj
TB --- 2009-02-03 14:07:11 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2009-02-03 14:07:11 - TARGET=i386
TB --- 2009-02-03 14:07:11 - TARGET_ARCH=i386
TB --- 2009-02-03 14:07:11 - TZ=UTC
TB --- 2009-02-03 14:07:11 - __MAKE_CONF=/dev/null
TB --- 2009-02-03 14:07:11 - cd /src
TB --- 2009-02-03 14:07:11 - /usr/bin/make -B buildkernel KERNCONF=LINT
>>> Kernel build for LINT started on Tue Feb  3 14:07: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
[...]
cc1: warnings being treated as errors
/src/sys/modules/usb2/quirk/../../../dev/usb2/quirk/usb2_quirk.c:115: warning: data definition has no type or storage class
/src/sys/modules/usb2/quirk/../../../dev/usb2/quirk/usb2_quirk.c:115: warning: type defaults to 'int' in declaration of 'USB_MAKE_DEBUG_TABLE'
/src/sys/modules/usb2/quirk/../../../dev/usb2/quirk/usb2_quirk.c:115: warning: parameter names (without types) in function declaration
/src/sys/modules/usb2/quirk/../../../dev/usb2/quirk/usb2_quirk.c: In function 'usb2_quirkstr':
/src/sys/modules/usb2/quirk/../../../dev/usb2/quirk/usb2_quirk.c:126: error: 'USB_QUIRK' undeclared (first use in this function)
/src/sys/modules/usb2/quirk/../../../dev/usb2/quirk/usb2_quirk.c:126: error: (Each undeclared identifier is reported only once
/src/sys/modules/usb2/quirk/../../../dev/usb2/quirk/usb2_quirk.c:126: error: for each function it appears in.)
*** Error code 1

Stop in /src/sys/modules/usb2/quirk.
*** Error code 1

Stop in /src/sys/modules/usb2.
*** Error code 1

Stop in /src/sys/modules.
*** Error code 1

Stop in /obj/src/sys/LINT.
*** Error code 1

Stop in /src.
*** Error code 1

Stop in /src.
TB --- 2009-02-03 14:37:30 - WARNING: /usr/bin/make returned exit code  1 
TB --- 2009-02-03 14:37:30 - ERROR: failed to build lint kernel
TB --- 2009-02-03 14:37:30 - 5458.37 user 466.36 system 6670.40 real


http://tinderbox.des.no/tinderbox-head-HEAD-i386-i386.full
From rrs at lakerest.net  Tue Feb  3 07:08:54 2009
From: rrs at lakerest.net (Randall Stewart)
Date: Tue Feb  3 07:09:01 2009
Subject: [head tinderbox] failure on i386/i386
In-Reply-To: <20090203143730.2CC3C7302F@freebsd-current.sentex.ca>
References: <20090203143730.2CC3C7302F@freebsd-current.sentex.ca>
Message-ID: <BACD2281-C8EA-411C-80CD-BAAAAAEA33F7@lakerest.net>

Hmm:

I hit this early this AM.. and did a quick hack patch
that will get around this. The function USB_MAKE_DEBUG.. is obviously
not making the array of strings... a quick comment out and a building
of the strings will get you through until the owner fixes this :-)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: usb_quirk.patch
Type: application/octet-stream
Size: 1960 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20090203/7e7dd0e1/usb_quirk.obj
-------------- next part --------------



R


On Feb 3, 2009, at 9:37 AM, FreeBSD Tinderbox wrote:

> TB --- 2009-02-03 12:46:19 - tinderbox 2.6 running on freebsd- 
> current.sentex.ca
> TB --- 2009-02-03 12:46:19 - starting HEAD tinderbox run for i386/i386
> TB --- 2009-02-03 12:46:19 - cleaning the object tree
> TB --- 2009-02-03 12:46:52 - cvsupping the source tree
> TB --- 2009-02-03 12:46:52 - /usr/bin/csup -z -r 3 -g -L 1 -h  
> localhost -s /tinderbox/HEAD/i386/i386/supfile
> TB --- 2009-02-03 12:47:01 - building world
> TB --- 2009-02-03 12:47:01 - MAKEOBJDIRPREFIX=/obj
> TB --- 2009-02-03 12:47:01 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
> TB --- 2009-02-03 12:47:01 - TARGET=i386
> TB --- 2009-02-03 12:47:01 - TARGET_ARCH=i386
> TB --- 2009-02-03 12:47:01 - TZ=UTC
> TB --- 2009-02-03 12:47:01 - __MAKE_CONF=/dev/null
> TB --- 2009-02-03 12:47:01 - cd /src
> TB --- 2009-02-03 12:47:01 - /usr/bin/make -B buildworld
>>>> World build started on Tue Feb  3 12:47:05 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 Feb  3 14:07:10 UTC 2009
> TB --- 2009-02-03 14:07:10 - generating LINT kernel config
> TB --- 2009-02-03 14:07:10 - cd /src/sys/i386/conf
> TB --- 2009-02-03 14:07:10 - /usr/bin/make -B LINT
> TB --- 2009-02-03 14:07:11 - building LINT kernel
> TB --- 2009-02-03 14:07:11 - MAKEOBJDIRPREFIX=/obj
> TB --- 2009-02-03 14:07:11 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
> TB --- 2009-02-03 14:07:11 - TARGET=i386
> TB --- 2009-02-03 14:07:11 - TARGET_ARCH=i386
> TB --- 2009-02-03 14:07:11 - TZ=UTC
> TB --- 2009-02-03 14:07:11 - __MAKE_CONF=/dev/null
> TB --- 2009-02-03 14:07:11 - cd /src
> TB --- 2009-02-03 14:07:11 - /usr/bin/make -B buildkernel  
> KERNCONF=LINT
>>>> Kernel build for LINT started on Tue Feb  3 14:07: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
> [...]
> cc1: warnings being treated as errors
> /src/sys/modules/usb2/quirk/../../../dev/usb2/quirk/usb2_quirk.c: 
> 115: warning: data definition has no type or storage class
> /src/sys/modules/usb2/quirk/../../../dev/usb2/quirk/usb2_quirk.c: 
> 115: warning: type defaults to 'int' in declaration of  
> 'USB_MAKE_DEBUG_TABLE'
> /src/sys/modules/usb2/quirk/../../../dev/usb2/quirk/usb2_quirk.c: 
> 115: warning: parameter names (without types) in function declaration
> /src/sys/modules/usb2/quirk/../../../dev/usb2/quirk/usb2_quirk.c: In  
> function 'usb2_quirkstr':
> /src/sys/modules/usb2/quirk/../../../dev/usb2/quirk/usb2_quirk.c: 
> 126: error: 'USB_QUIRK' undeclared (first use in this function)
> /src/sys/modules/usb2/quirk/../../../dev/usb2/quirk/usb2_quirk.c: 
> 126: error: (Each undeclared identifier is reported only once
> /src/sys/modules/usb2/quirk/../../../dev/usb2/quirk/usb2_quirk.c: 
> 126: error: for each function it appears in.)
> *** Error code 1
>
> Stop in /src/sys/modules/usb2/quirk.
> *** Error code 1
>
> Stop in /src/sys/modules/usb2.
> *** Error code 1
>
> Stop in /src/sys/modules.
> *** Error code 1
>
> Stop in /obj/src/sys/LINT.
> *** Error code 1
>
> Stop in /src.
> *** Error code 1
>
> Stop in /src.
> TB --- 2009-02-03 14:37:30 - WARNING: /usr/bin/make returned exit  
> code  1
> TB --- 2009-02-03 14:37:30 - ERROR: failed to build lint kernel
> TB --- 2009-02-03 14:37:30 - 5458.37 user 466.36 system 6670.40 real
>
>
> http://tinderbox.des.no/tinderbox-head-HEAD-i386-i386.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 
> "
>

------------------------------
Randall Stewart
803-317-4952 (cell)
803-345-0391(direct)

From thompsa at FreeBSD.org  Tue Feb  3 07:25:20 2009
From: thompsa at FreeBSD.org (Andrew Thompson)
Date: Tue Feb  3 07:25:27 2009
Subject: [head tinderbox] failure on i386/i386
In-Reply-To: <BACD2281-C8EA-411C-80CD-BAAAAAEA33F7@lakerest.net>
References: <20090203143730.2CC3C7302F@freebsd-current.sentex.ca>
	<BACD2281-C8EA-411C-80CD-BAAAAAEA33F7@lakerest.net>
Message-ID: <20090203152510.GA64026@citylink.fud.org.nz>

On Tue, Feb 03, 2009 at 10:08:52AM -0500, Randall Stewart wrote:
> Hmm:
> 
> I hit this early this AM.. and did a quick hack patch
> that will get around this. The function USB_MAKE_DEBUG.. is obviously
> not making the array of strings... a quick comment out and a building
> of the strings will get you through until the owner fixes this :-)
> 


My mistake, thanks for the patch.

> 
> 
> 
> R
> 
> 
> On Feb 3, 2009, at 9:37 AM, FreeBSD Tinderbox wrote:
> 
>> TB --- 2009-02-03 12:46:19 - tinderbox 2.6 running on 
>> freebsd-current.sentex.ca
>> TB --- 2009-02-03 12:46:19 - starting HEAD tinderbox run for i386/i386
>> TB --- 2009-02-03 12:46:19 - cleaning the object tree
>> TB --- 2009-02-03 12:46:52 - cvsupping the source tree
>> TB --- 2009-02-03 12:46:52 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s 
>> /tinderbox/HEAD/i386/i386/supfile
>> TB --- 2009-02-03 12:47:01 - building world
>> TB --- 2009-02-03 12:47:01 - MAKEOBJDIRPREFIX=/obj
>> TB --- 2009-02-03 12:47:01 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
>> TB --- 2009-02-03 12:47:01 - TARGET=i386
>> TB --- 2009-02-03 12:47:01 - TARGET_ARCH=i386
>> TB --- 2009-02-03 12:47:01 - TZ=UTC
>> TB --- 2009-02-03 12:47:01 - __MAKE_CONF=/dev/null
>> TB --- 2009-02-03 12:47:01 - cd /src
>> TB --- 2009-02-03 12:47:01 - /usr/bin/make -B buildworld
>>>>> World build started on Tue Feb  3 12:47:05 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 Feb  3 14:07:10 UTC 2009
>> TB --- 2009-02-03 14:07:10 - generating LINT kernel config
>> TB --- 2009-02-03 14:07:10 - cd /src/sys/i386/conf
>> TB --- 2009-02-03 14:07:10 - /usr/bin/make -B LINT
>> TB --- 2009-02-03 14:07:11 - building LINT kernel
>> TB --- 2009-02-03 14:07:11 - MAKEOBJDIRPREFIX=/obj
>> TB --- 2009-02-03 14:07:11 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
>> TB --- 2009-02-03 14:07:11 - TARGET=i386
>> TB --- 2009-02-03 14:07:11 - TARGET_ARCH=i386
>> TB --- 2009-02-03 14:07:11 - TZ=UTC
>> TB --- 2009-02-03 14:07:11 - __MAKE_CONF=/dev/null
>> TB --- 2009-02-03 14:07:11 - cd /src
>> TB --- 2009-02-03 14:07:11 - /usr/bin/make -B buildkernel KERNCONF=LINT
>>>>> Kernel build for LINT started on Tue Feb  3 14:07: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
>> [...]
>> cc1: warnings being treated as errors
>> /src/sys/modules/usb2/quirk/../../../dev/usb2/quirk/usb2_quirk.c:115: 
>> warning: data definition has no type or storage class
>> /src/sys/modules/usb2/quirk/../../../dev/usb2/quirk/usb2_quirk.c:115: 
>> warning: type defaults to 'int' in declaration of 'USB_MAKE_DEBUG_TABLE'
>> /src/sys/modules/usb2/quirk/../../../dev/usb2/quirk/usb2_quirk.c:115: 
>> warning: parameter names (without types) in function declaration
>> /src/sys/modules/usb2/quirk/../../../dev/usb2/quirk/usb2_quirk.c: In 
>> function 'usb2_quirkstr':
>> /src/sys/modules/usb2/quirk/../../../dev/usb2/quirk/usb2_quirk.c:126: 
>> error: 'USB_QUIRK' undeclared (first use in this function)
>> /src/sys/modules/usb2/quirk/../../../dev/usb2/quirk/usb2_quirk.c:126: 
>> error: (Each undeclared identifier is reported only once
>> /src/sys/modules/usb2/quirk/../../../dev/usb2/quirk/usb2_quirk.c:126: 
>> error: for each function it appears in.)
>> *** Error code 1
>> 
>> Stop in /src/sys/modules/usb2/quirk.
>> *** Error code 1
>> 
>> Stop in /src/sys/modules/usb2.
>> *** Error code 1
>> 
>> Stop in /src/sys/modules.
>> *** Error code 1
>> 
>> Stop in /obj/src/sys/LINT.
>> *** Error code 1
>> 
>> Stop in /src.
>> *** Error code 1
>> 
>> Stop in /src.
>> TB --- 2009-02-03 14:37:30 - WARNING: /usr/bin/make returned exit code  1
>> TB --- 2009-02-03 14:37:30 - ERROR: failed to build lint kernel
>> TB --- 2009-02-03 14:37:30 - 5458.37 user 466.36 system 6670.40 real
>> 
>> 
>> http://tinderbox.des.no/tinderbox-head-HEAD-i386-i386.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"
>> 
> 
> ------------------------------
> Randall Stewart
> 803-317-4952 (cell)
> 803-345-0391(direct)
> 

> _______________________________________________
> 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 tinderbox at freebsd.org  Tue Feb  3 07:52:53 2009
From: tinderbox at freebsd.org (FreeBSD Tinderbox)
Date: Tue Feb  3 07:53:04 2009
Subject: [head tinderbox] failure on i386/pc98
Message-ID: <20090203155249.670637302F@freebsd-current.sentex.ca>

TB --- 2009-02-03 14:05:28 - tinderbox 2.6 running on freebsd-current.sentex.ca
TB --- 2009-02-03 14:05:28 - starting HEAD tinderbox run for i386/pc98
TB --- 2009-02-03 14:05:28 - cleaning the object tree
TB --- 2009-02-03 14:05:56 - cvsupping the source tree
TB --- 2009-02-03 14:05:56 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/i386/pc98/supfile
TB --- 2009-02-03 14:06:05 - building world
TB --- 2009-02-03 14:06:05 - MAKEOBJDIRPREFIX=/obj
TB --- 2009-02-03 14:06:05 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2009-02-03 14:06:05 - TARGET=pc98
TB --- 2009-02-03 14:06:05 - TARGET_ARCH=i386
TB --- 2009-02-03 14:06:05 - TZ=UTC
TB --- 2009-02-03 14:06:05 - __MAKE_CONF=/dev/null
TB --- 2009-02-03 14:06:05 - cd /src
TB --- 2009-02-03 14:06:05 - /usr/bin/make -B buildworld
>>> World build started on Tue Feb  3 14:06:07 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 Feb  3 15:25:57 UTC 2009
TB --- 2009-02-03 15:25:57 - generating LINT kernel config
TB --- 2009-02-03 15:25:57 - cd /src/sys/pc98/conf
TB --- 2009-02-03 15:25:57 - /usr/bin/make -B LINT
TB --- 2009-02-03 15:25:57 - building LINT kernel
TB --- 2009-02-03 15:25:57 - MAKEOBJDIRPREFIX=/obj
TB --- 2009-02-03 15:25:57 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2009-02-03 15:25:57 - TARGET=pc98
TB --- 2009-02-03 15:25:57 - TARGET_ARCH=i386
TB --- 2009-02-03 15:25:57 - TZ=UTC
TB --- 2009-02-03 15:25:57 - __MAKE_CONF=/dev/null
TB --- 2009-02-03 15:25:57 - cd /src
TB --- 2009-02-03 15:25:57 - /usr/bin/make -B buildkernel KERNCONF=LINT
>>> Kernel build for LINT started on Tue Feb  3 15:25: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
[...]
cc1: warnings being treated as errors
/src/sys/modules/usb2/quirk/../../../dev/usb2/quirk/usb2_quirk.c:115: warning: data definition has no type or storage class
/src/sys/modules/usb2/quirk/../../../dev/usb2/quirk/usb2_quirk.c:115: warning: type defaults to 'int' in declaration of 'USB_MAKE_DEBUG_TABLE'
/src/sys/modules/usb2/quirk/../../../dev/usb2/quirk/usb2_quirk.c:115: warning: parameter names (without types) in function declaration
/src/sys/modules/usb2/quirk/../../../dev/usb2/quirk/usb2_quirk.c: In function 'usb2_quirkstr':
/src/sys/modules/usb2/quirk/../../../dev/usb2/quirk/usb2_quirk.c:126: error: 'USB_QUIRK' undeclared (first use in this function)
/src/sys/modules/usb2/quirk/../../../dev/usb2/quirk/usb2_quirk.c:126: error: (Each undeclared identifier is reported only once
/src/sys/modules/usb2/quirk/../../../dev/usb2/quirk/usb2_quirk.c:126: error: for each function it appears in.)
*** Error code 1

Stop in /src/sys/modules/usb2/quirk.
*** Error code 1

Stop in /src/sys/modules/usb2.
*** Error code 1

Stop in /src/sys/modules.
*** Error code 1

Stop in /obj/pc98/src/sys/LINT.
*** Error code 1

Stop in /src.
*** Error code 1

Stop in /src.
TB --- 2009-02-03 15:52:49 - WARNING: /usr/bin/make returned exit code  1 
TB --- 2009-02-03 15:52:49 - ERROR: failed to build lint kernel
TB --- 2009-02-03 15:52:49 - 5186.05 user 469.09 system 6441.23 real


http://tinderbox.des.no/tinderbox-head-HEAD-i386-pc98.full
From tinderbox at freebsd.org  Tue Feb  3 08:59:05 2009
From: tinderbox at freebsd.org (FreeBSD Tinderbox)
Date: Tue Feb  3 08:59:12 2009
Subject: [head tinderbox] failure on ia64/ia64
Message-ID: <20090203165902.A1BB97302F@freebsd-current.sentex.ca>

TB --- 2009-02-03 14:37:30 - tinderbox 2.6 running on freebsd-current.sentex.ca
TB --- 2009-02-03 14:37:30 - starting HEAD tinderbox run for ia64/ia64
TB --- 2009-02-03 14:37:30 - cleaning the object tree
TB --- 2009-02-03 14:37:52 - cvsupping the source tree
TB --- 2009-02-03 14:37:52 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/ia64/ia64/supfile
TB --- 2009-02-03 14:38:01 - building world
TB --- 2009-02-03 14:38:01 - MAKEOBJDIRPREFIX=/obj
TB --- 2009-02-03 14:38:01 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2009-02-03 14:38:01 - TARGET=ia64
TB --- 2009-02-03 14:38:01 - TARGET_ARCH=ia64
TB --- 2009-02-03 14:38:01 - TZ=UTC
TB --- 2009-02-03 14:38:01 - __MAKE_CONF=/dev/null
TB --- 2009-02-03 14:38:01 - cd /src
TB --- 2009-02-03 14:38:01 - /usr/bin/make -B buildworld
>>> World build started on Tue Feb  3 14:38:03 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 Feb  3 16:24:06 UTC 2009
TB --- 2009-02-03 16:24:06 - generating LINT kernel config
TB --- 2009-02-03 16:24:06 - cd /src/sys/ia64/conf
TB --- 2009-02-03 16:24:06 - /usr/bin/make -B LINT
TB --- 2009-02-03 16:24:06 - building LINT kernel
TB --- 2009-02-03 16:24:06 - MAKEOBJDIRPREFIX=/obj
TB --- 2009-02-03 16:24:06 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2009-02-03 16:24:06 - TARGET=ia64
TB --- 2009-02-03 16:24:06 - TARGET_ARCH=ia64
TB --- 2009-02-03 16:24:06 - TZ=UTC
TB --- 2009-02-03 16:24:06 - __MAKE_CONF=/dev/null
TB --- 2009-02-03 16:24:06 - cd /src
TB --- 2009-02-03 16:24:06 - /usr/bin/make -B buildkernel KERNCONF=LINT
>>> Kernel build for LINT started on Tue Feb  3 16:24:06 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/modules/usb2/quirk/../../../dev/usb2/quirk/usb2_quirk.c:115: warning: data definition has no type or storage class
/src/sys/modules/usb2/quirk/../../../dev/usb2/quirk/usb2_quirk.c:115: warning: type defaults to 'int' in declaration of 'USB_MAKE_DEBUG_TABLE'
/src/sys/modules/usb2/quirk/../../../dev/usb2/quirk/usb2_quirk.c:115: warning: parameter names (without types) in function declaration
/src/sys/modules/usb2/quirk/../../../dev/usb2/quirk/usb2_quirk.c: In function 'usb2_quirkstr':
/src/sys/modules/usb2/quirk/../../../dev/usb2/quirk/usb2_quirk.c:126: error: 'USB_QUIRK' undeclared (first use in this function)
/src/sys/modules/usb2/quirk/../../../dev/usb2/quirk/usb2_quirk.c:126: error: (Each undeclared identifier is reported only once
/src/sys/modules/usb2/quirk/../../../dev/usb2/quirk/usb2_quirk.c:126: error: for each function it appears in.)
*** Error code 1

Stop in /src/sys/modules/usb2/quirk.
*** Error code 1

Stop in /src/sys/modules/usb2.
*** Error code 1

Stop in /src/sys/modules.
*** Error code 1

Stop in /obj/ia64/src/sys/LINT.
*** Error code 1

Stop in /src.
*** Error code 1

Stop in /src.
TB --- 2009-02-03 16:59:02 - WARNING: /usr/bin/make returned exit code  1 
TB --- 2009-02-03 16:59:02 - ERROR: failed to build lint kernel
TB --- 2009-02-03 16:59:02 - 7158.58 user 462.13 system 8492.19 real


http://tinderbox.des.no/tinderbox-head-HEAD-ia64-ia64.full
From freebsd at abv.bg  Tue Feb  3 09:19:09 2009
From: freebsd at abv.bg (Mario Pavlov)
Date: Tue Feb  3 09:19:17 2009
Subject: panic caused by mpd5
Message-ID: <1221544143.12881.1233681546489.JavaMail.apache@mail51.abv.bg>

Hi,
I'll first update the code and try that patch (r187946) out
then I'll let you know if the problem is still there
thank you

Regards
MGP

 >On Tue, 3 Feb 2009, Mario Pavlov wrote:
 >
 >Hi,
 >
 >> I don't know what else could be useful
 >> just tell me what you need and I'll provide it
 >
 >you could have at least typed "bt" or resolved the line number to the
 >right piece of code as you seem to run HEAD which can change
 >frequently.
 >
 >http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/kerneldebug.html
 >has some info on how to debug things.
 >
 >
 >> btw what is r187946 ?
 >
 >The SVN revision number of a commit:
 >http://svn.freebsd.org/viewvc/base?view=revision&revision=187946
 >
 >
 >If you want to run HEAD, try to update your source, rebuild the kernel
 >and see if you can still reproduce it. If you can, start debugging along
 >the above information.
 >
 >
 >/bz
 >
 >-- 
 >Bjoern A. Zeeb                      The greatest risk is not taking one.
 >_______________________________________________
 >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 xcllnt at mac.com  Tue Feb  3 10:15:55 2009
From: xcllnt at mac.com (Marcel Moolenaar)
Date: Tue Feb  3 10:16:02 2009
Subject: GEOM_PART: a quick update on logical partitions
In-Reply-To: <20090203082153.565746e2@zelda.local>
References: <FCA8C5E4-BC41-4711-9EBC-CD692144F6B8@mac.com>
	<20090203082153.565746e2@zelda.local>
Message-ID: <D35C93DE-CB3F-4631-AC38-4CCCE3877C23@mac.com>


On Feb 2, 2009, at 11:21 PM, Martin wrote:

> Am Mon, 02 Feb 2009 11:16:53 -0800
> schrieb Marcel Moolenaar <xcllnt@mac.com>:
>
>> 	/dev/da0s2.00000000
>> 	/dev/da0s2.0834F7A0
>> 	/dev/da0s5 -> /dev/da0s2.00000000
>> 	/dev/da0s6 -> /dev/da0s2.0834F7A0
>
> Hi.
>
> As far as I remember, the old MS-DOS scheme for partitioning
> (we have GPT now ;) that I am happy with) implements these logical
> partitions as a linked list. Why not have a simple index pointing to
> the list entry?
>
> Something like this:
>
> /dev/da0s2.1
> /dev/da0s2.2
>
> Might be starting with 1 or perhaps 0.

What happens if you add a partition to the head of the list?

> Second thing is, why do you need something like "s5"?

That's the how logical partitions are named in 7.x

-- 
Marcel Moolenaar
xcllnt@mac.com



From mwlucas at blackhelicopters.org  Tue Feb  3 11:56:29 2009
From: mwlucas at blackhelicopters.org (Michael W. Lucas)
Date: Tue Feb  3 11:56:37 2009
Subject: nanobsd dies in newfs
Message-ID: <20090203194017.GA58565@bewilderbeast.blackhelicopters.org>


Hi,

This is on i386 -current as of Feb 1, 2009.

Obviously, things have changed in the year since I've built nanoBSD.
I'm trying to build a very tiny sniffer box, and the build dies in
newfs(8).  The error and my nanobsd config follow.

Any suggestions, folks?

...
===> sbin/newfs (all)
cc -O2 -pipe  -DNDEBUG -fstack-protector -Wsystem-headers -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /usr/src/sbin/newfs/newfs.c
cc -O2 -pipe  -DNDEBUG -fstack-protector -Wsystem-headers -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /usr/src/sbin/newfs/mkfs.c
cc -O2 -pipe  -DNDEBUG -fstack-protector -Wsystem-headers -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /usr/src/sbin/newfs/../../sys/geom/geom_bsd_enc.c
cc -O2 -pipe  -DNDEBUG -fstack-protector -Wsystem-headers -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign  -static -o newfs newfs.o mkfs.o geom_bsd_enc.o -lufs
/usr/obj/nanobsd.SoekrisSoftflowd//usr/src/tmp/usr/lib/libufs.a(block.o)(.text+0xc0): In function `bwrite':
: multiple definition of `bwrite'
newfs.o(.text+0x490): first defined here
/usr/obj/nanobsd.SoekrisSoftflowd//usr/src/tmp/usr/bin/ld: Warning: size of symbol `bwrite' changed from 109 in newfs.o to 492 in /usr/obj/nanobsd.SoekrisSoftflowd//usr/src/tmp/usr/lib/libufs.a(block.o)
*** Error code 1


NANO_NAME=SoekrisSoftflowd
NANO_IMAGES=2
NANO_KERNEL=SOEKRIS
NANO_PMAKE="make"

FlashDevice samsung 128

customize_cmd cust_comconsole
customize_cmd cust_allow_ssh_root

CONF_INSTALL='
WITHOUT_TOOLCHAIN=YES
'

CONF_WORLD='
NO_MODULES=YES
WITHOUT_ACCT=YES
WITHOUT_ACPI=YES
WITHOUT_AMD=YES
WITHOUT_APM=YES
WITHOUT_ASSERT_DEBUG=YES
WITHOUT_AT=YES
WITHOUT_ATM=YES
WITHOUT_AUDIT=YES
WITHOUT_AUTHPF=YES
WITHOUT_BIND=YES
WITHOUT_BLUETOOTH=YES
WITHOUT_BSD_CPIO=YES
WITHOUT_BSNMP=YES
WITHOUT_CALENDAR=YES
WITHOUT_CDDL=YES
WITHOUT_CPP=YES
WITHOUT_CTM=YES
WITHOUT_CVS=YES
WITHOUT_CXX=YES
WITHOUT_DICT=YES
WITHOUT_DYNAMICROOT=YES
WITHOUT_EXAMPLES=YES
WITHOUT_FLOPPY=YES
WITHOUT_FORTRAN=YES
WITHOUT_FREEBSD_UPDATE=YES
WITHOUT_GAMES=YES
WITHOUT_GCOV=YES
WITHOUT_GPIB=YES
WITHOUT_GROFF=YES
WITHOUT_GSSAPI=YES
WITHOUT_HTML=YES
WITHOUT_I4B=YES
WITHOUT_INET6=YES
WITHOUT_INFO=YES
WITHOUT_INSTALLIB=YES
WITHOUT_IPFILTER=YES
WITHOUT_IPFW=YES
WITHOUT_IPX=YES
WITHOUT_JAIL=YES
WITHOUT_KERBEROS=YES
WITHOUT_LEGACY_CONSOLE=YES
WITHOUT_LIBC_R=YES
#WITHOUT_LIBPTHREAD=YES
#WITHOUT_LIBTHR=YES
WITHOUT_LOCALES=YES
WITHOUT_LOCATE=YES
WITHOUT_LPR=YES
WITHOUT_MAIL=YES
WITHOUT_MAKE=YES
WITHOUT_MAN=YES
WITHOUT_NDIS=YES
WITHOUT_NETCAT=YES
WITHOUT_NETGRAPH=YES
WITHOUT_NIS=YES
WITHOUT_NLS=YES
WITHOUT_NLS_CATALOGS=YES
WITHOUT_NS_CACHING=YES
WITHOUT_OBJC=YES
WITHOUT_P1003_1B=YES
WITHOUT_PF=YES
WITHOUT_PKGTOOLS=YES
WITHOUT_PMCCONTROL=YES
WITHOUT_PORTSNAP=YES
WITHOUT_PPP=YES
WITHOUT_PROFILE=YES
WITHOUT_QUOTAS=YES
WITHOUT_RCMDS=YES
WITHOUT_RCS=YES
WITHOUT_RESCUE=YES
WITHOUT_ROUTED=YES
WITHOUT_SHAREDOCS=YES
WITHOUT-SLIP=YES
WITHOUT_SPP=YES
WITHOUT_SYSCONS=YES
WITHOUT_SYSINSTALL=YES
WITHOUT_TEXTPROC=YES
WITHOUT_USB=YES
WITHOUT_WIRELESS=YES
WITHOUT_SENDMAIL=YES
WITHOUT_SHAREDOCS=YES
WITHOUT_PPP=YES
WITHOUT_WPA_SUPPLICANT_EAPOL=YES
WITHOUT_ZFS=YES
WITHOUT_ZONEINFO=YES
'




-- 
Michael W. Lucas 	mwlucas@BlackHelicopters.org, mwlucas@FreeBSD.org
		http://www.BlackHelicopters.org/~mwlucas/
"My pessimism extends to the point of even suspecting the sincerity of
  the pessimists." -- Jean Rostand, French biologist and philosopher
From tinderbox at freebsd.org  Tue Feb  3 12:14:46 2009
From: tinderbox at freebsd.org (FreeBSD Tinderbox)
Date: Tue Feb  3 12:15:03 2009
Subject: [head tinderbox] failure on arm/arm
Message-ID: <20090203201441.7C9A57302F@freebsd-current.sentex.ca>

TB --- 2009-02-03 20:00:00 - tinderbox 2.6 running on freebsd-current.sentex.ca
TB --- 2009-02-03 20:00:00 - starting HEAD tinderbox run for arm/arm
TB --- 2009-02-03 20:00:00 - cleaning the object tree
TB --- 2009-02-03 20:00:32 - cvsupping the source tree
TB --- 2009-02-03 20:00:32 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/arm/arm/supfile
TB --- 2009-02-03 20:00:40 - building world
TB --- 2009-02-03 20:00:40 - MAKEOBJDIRPREFIX=/obj
TB --- 2009-02-03 20:00:40 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2009-02-03 20:00:40 - TARGET=arm
TB --- 2009-02-03 20:00:40 - TARGET_ARCH=arm
TB --- 2009-02-03 20:00:40 - TZ=UTC
TB --- 2009-02-03 20:00:40 - __MAKE_CONF=/dev/null
TB --- 2009-02-03 20:00:40 - cd /src
TB --- 2009-02-03 20:00:40 - /usr/bin/make -B buildworld
>>> World build started on Tue Feb  3 20:00:42 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 -O -pipe  -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/arm -DSOFTFLOAT -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/arm/src/lib/libc -I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -I/src/lib/libc/arm/softfloat -I/src/lib/libc/softfloat -DSOFTFLOAT_FOR_GCC -DYP -DNS_CACHING -DSYMBOL_VERSIONING -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/lib/libc/string/bcmp.c
cc -O -pipe  -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/arm -DSOFTFLOAT -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/arm/src/lib/libc -I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -I/src/lib/libc/arm/softfloat -I/src/lib/libc/softfloat -DSOFTFLOAT_FOR_GCC -DYP -DNS_CACHING -DSYMBOL_VERSIONING -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/lib/libc/arm/string/bcopy.S
cc -O -pipe  -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/arm -DSOFTFLOAT -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/arm/src/lib/libc -I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -I/src/lib/libc/arm/softfloat -I/src/lib/libc/softfloat -DSOFTFLOAT_FOR_GCC -DYP -DNS_CACHING -DSYMBOL_VERSIONING -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/lib/libc/arm/string/bzero.S
cc -O -pipe  -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/arm -DSOFTFLOAT -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/arm/src/lib/libc -I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -I/src/lib/libc/arm/softfloat -I/src/lib/libc/softfloat -DSOFTFLOAT_FOR_GCC -DYP -DNS_CACHING -DSYMBOL_VERSIONING -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/lib/libc/arm/string/ffs.S
cc -O -pipe  -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/arm -DSOFTFLOAT -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/arm/src/lib/libc -I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -I/src/lib/libc/arm/softfloat -I/src/lib/libc/softfloat -DSOFTFLOAT_FOR_GCC -DYP -DNS_CACHING -DSYMBOL_VERSIONING -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/lib/libc/string/index.c
cc -O -pipe  -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/arm -DSOFTFLOAT -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/arm/src/lib/libc -I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -I/src/lib/libc/arm/softfloat -I/src/lib/libc/softfloat -DSOFTFLOAT_FOR_GCC -DYP -DNS_CACHING -DSYMBOL_VERSIONING -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/lib/libc/string/memchr.c
/src/lib/libc/string/memchr.c:43: error: conflicting types for 'memchr'
/src/lib/libc/../../include/string.h:61: error: previous declaration of 'memchr' was here
*** 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-02-03 20:14:40 - WARNING: /usr/bin/make returned exit code  1 
TB --- 2009-02-03 20:14:40 - ERROR: failed to build world
TB --- 2009-02-03 20:14:40 - 650.20 user 65.42 system 879.97 real


http://tinderbox.des.no/tinderbox-head-HEAD-arm-arm.full
From tinderbox at freebsd.org  Tue Feb  3 12:18:15 2009
From: tinderbox at freebsd.org (FreeBSD Tinderbox)
Date: Tue Feb  3 12:18:21 2009
Subject: [head tinderbox] failure on amd64/amd64
Message-ID: <20090203201811.CE15E7302F@freebsd-current.sentex.ca>

TB --- 2009-02-03 20:00:00 - tinderbox 2.6 running on freebsd-current.sentex.ca
TB --- 2009-02-03 20:00:00 - starting HEAD tinderbox run for amd64/amd64
TB --- 2009-02-03 20:00:00 - cleaning the object tree
TB --- 2009-02-03 20:00:47 - cvsupping the source tree
TB --- 2009-02-03 20:00:47 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/amd64/amd64/supfile
TB --- 2009-02-03 20:00:55 - building world
TB --- 2009-02-03 20:00:55 - MAKEOBJDIRPREFIX=/obj
TB --- 2009-02-03 20:00:55 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2009-02-03 20:00:55 - TARGET=amd64
TB --- 2009-02-03 20:00:55 - TARGET_ARCH=amd64
TB --- 2009-02-03 20:00:55 - TZ=UTC
TB --- 2009-02-03 20:00:55 - __MAKE_CONF=/dev/null
TB --- 2009-02-03 20:00:55 - cd /src
TB --- 2009-02-03 20:00:55 - /usr/bin/make -B buildworld
>>> World build started on Tue Feb  3 20:00: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
[...]
cc -O2 -pipe  -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/amd64 -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/amd64/src/lib/libc -I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -DSYMBOL_VERSIONING -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/lib/libc/string/fls.c
cc -O2 -pipe  -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/amd64 -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/amd64/src/lib/libc -I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -DSYMBOL_VERSIONING -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/lib/libc/string/flsl.c
cc -O2 -pipe  -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/amd64 -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/amd64/src/lib/libc -I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -DSYMBOL_VERSIONING -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/lib/libc/string/flsll.c
cc -O2 -pipe  -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/amd64 -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/amd64/src/lib/libc -I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -DSYMBOL_VERSIONING -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/lib/libc/string/index.c
cc -O2 -pipe  -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/amd64 -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/amd64/src/lib/libc -I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -DSYMBOL_VERSIONING -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/lib/libc/string/memccpy.c
cc -O2 -pipe  -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/amd64 -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/amd64/src/lib/libc -I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -DSYMBOL_VERSIONING -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/lib/libc/string/memchr.c
/src/lib/libc/string/memchr.c:43: error: conflicting types for 'memchr'
/src/lib/libc/../../include/string.h:61: error: previous declaration of 'memchr' was here
*** 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-02-03 20:18:11 - WARNING: /usr/bin/make returned exit code  1 
TB --- 2009-02-03 20:18:11 - ERROR: failed to build world
TB --- 2009-02-03 20:18:11 - 804.62 user 78.65 system 1090.94 real


http://tinderbox.des.no/tinderbox-head-HEAD-amd64-amd64.full
From freebsd at abv.bg  Tue Feb  3 12:25:18 2009
From: freebsd at abv.bg (Mario Pavlov)
Date: Tue Feb  3 12:25:25 2009
Subject: panic caused by mpd5
Message-ID: <378345101.17713.1233692714695.JavaMail.apache@mail52.abv.bg>

Hi again
I've updated the code and guess what...it doesn't panic any more :)
thanks to all of you

Regards
MGP


 >Hi,
 >I'll first update the code and try that patch (r187946) out
 >then I'll let you know if the problem is still there
 >thank you
 >
 >Regards
 >MGP
 >
 > >On Tue, 3 Feb 2009, Mario Pavlov wrote:
 > >
 > >Hi,
 > >
 > >> I don't know what else could be useful
 > >> just tell me what you need and I'll provide it
 > >
 > >you could have at least typed "bt" or resolved the line number to the
 > >right piece of code as you seem to run HEAD which can change
 > >frequently.
 > >
 > >http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/kerneldebug.html
 > >has some info on how to debug things.
 > >
 > >
 > >> btw what is r187946 ?
 > >
 > >The SVN revision number of a commit:
 > >http://svn.freebsd.org/viewvc/base?view=revision&revision=187946
 > >
 > >
 > >If you want to run HEAD, try to update your source, rebuild the kernel
 > >and see if you can still reproduce it. If you can, start debugging along
 > >the above information.
 > >
 > >
 > >/bz
 > >
 > >-- 
 > >Bjoern A. Zeeb                      The greatest risk is not taking one.
 > >_______________________________________________
 > >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 tinderbox at freebsd.org  Tue Feb  3 12:31:05 2009
From: tinderbox at freebsd.org (FreeBSD Tinderbox)
Date: Tue Feb  3 12:31:12 2009
Subject: [head tinderbox] failure on i386/i386
Message-ID: <20090203203102.125D57302F@freebsd-current.sentex.ca>

TB --- 2009-02-03 20:14:41 - tinderbox 2.6 running on freebsd-current.sentex.ca
TB --- 2009-02-03 20:14:41 - starting HEAD tinderbox run for i386/i386
TB --- 2009-02-03 20:14:41 - cleaning the object tree
TB --- 2009-02-03 20:15:13 - cvsupping the source tree
TB --- 2009-02-03 20:15:13 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/i386/i386/supfile
TB --- 2009-02-03 20:15:20 - building world
TB --- 2009-02-03 20:15:20 - MAKEOBJDIRPREFIX=/obj
TB --- 2009-02-03 20:15:20 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2009-02-03 20:15:20 - TARGET=i386
TB --- 2009-02-03 20:15:20 - TARGET_ARCH=i386
TB --- 2009-02-03 20:15:20 - TZ=UTC
TB --- 2009-02-03 20:15:20 - __MAKE_CONF=/dev/null
TB --- 2009-02-03 20:15:20 - cd /src
TB --- 2009-02-03 20:15:20 - /usr/bin/make -B buildworld
>>> World build started on Tue Feb  3 20:15:21 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/i386 -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/src/lib/libc -I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -DSYMBOL_VERSIONING -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/lib/libc/string/strcspn.c
cc -O2 -pipe  -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/i386 -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/src/lib/libc -I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -DSYMBOL_VERSIONING -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/lib/libc/string/strdup.c
cc -O2 -pipe  -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/i386 -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/src/lib/libc -I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -DSYMBOL_VERSIONING -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/lib/libc/string/strerror.c
cc -O2 -pipe  -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/i386 -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/src/lib/libc -I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -DSYMBOL_VERSIONING -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/lib/libc/string/strlcat.c
cc -O2 -pipe  -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/i386 -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/src/lib/libc -I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -DSYMBOL_VERSIONING -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/lib/libc/string/strlcpy.c
cc -O2 -pipe  -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/i386 -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/src/lib/libc -I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -DSYMBOL_VERSIONING -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/lib/libc/string/strmode.c
/src/lib/libc/string/strmode.c:42: error: conflicting types for 'strmode'
/src/lib/libc/../../include/string.h:93: error: previous declaration of 'strmode' was here
*** 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-02-03 20:31:02 - WARNING: /usr/bin/make returned exit code  1 
TB --- 2009-02-03 20:31:02 - ERROR: failed to build world
TB --- 2009-02-03 20:31:02 - 741.88 user 67.12 system 980.48 real


http://tinderbox.des.no/tinderbox-head-HEAD-i386-i386.full
From tinderbox at freebsd.org  Tue Feb  3 12:34:37 2009
From: tinderbox at freebsd.org (FreeBSD Tinderbox)
Date: Tue Feb  3 12:34:54 2009
Subject: [head tinderbox] failure on i386/pc98
Message-ID: <20090203203434.779D37302F@freebsd-current.sentex.ca>

TB --- 2009-02-03 20:18:11 - tinderbox 2.6 running on freebsd-current.sentex.ca
TB --- 2009-02-03 20:18:11 - starting HEAD tinderbox run for i386/pc98
TB --- 2009-02-03 20:18:11 - cleaning the object tree
TB --- 2009-02-03 20:18:40 - cvsupping the source tree
TB --- 2009-02-03 20:18:40 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/i386/pc98/supfile
TB --- 2009-02-03 20:18:47 - building world
TB --- 2009-02-03 20:18:47 - MAKEOBJDIRPREFIX=/obj
TB --- 2009-02-03 20:18:47 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2009-02-03 20:18:47 - TARGET=pc98
TB --- 2009-02-03 20:18:47 - TARGET_ARCH=i386
TB --- 2009-02-03 20:18:47 - TZ=UTC
TB --- 2009-02-03 20:18:47 - __MAKE_CONF=/dev/null
TB --- 2009-02-03 20:18:47 - cd /src
TB --- 2009-02-03 20:18:47 - /usr/bin/make -B buildworld
>>> World build started on Tue Feb  3 20:18:50 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/i386 -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/pc98/src/lib/libc -I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -DSYMBOL_VERSIONING -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/lib/libc/string/strcspn.c
cc -O2 -pipe  -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/i386 -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/pc98/src/lib/libc -I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -DSYMBOL_VERSIONING -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/lib/libc/string/strdup.c
cc -O2 -pipe  -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/i386 -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/pc98/src/lib/libc -I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -DSYMBOL_VERSIONING -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/lib/libc/string/strerror.c
cc -O2 -pipe  -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/i386 -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/pc98/src/lib/libc -I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -DSYMBOL_VERSIONING -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/lib/libc/string/strlcat.c
cc -O2 -pipe  -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/i386 -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/pc98/src/lib/libc -I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -DSYMBOL_VERSIONING -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/lib/libc/string/strlcpy.c
cc -O2 -pipe  -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/i386 -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/pc98/src/lib/libc -I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -DSYMBOL_VERSIONING -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/lib/libc/string/strmode.c
/src/lib/libc/string/strmode.c:42: error: conflicting types for 'strmode'
/src/lib/libc/../../include/string.h:93: error: previous declaration of 'strmode' was here
*** 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-02-03 20:34:34 - WARNING: /usr/bin/make returned exit code  1 
TB --- 2009-02-03 20:34:34 - ERROR: failed to build world
TB --- 2009-02-03 20:34:34 - 740.60 user 69.53 system 982.48 real


http://tinderbox.des.no/tinderbox-head-HEAD-i386-pc98.full
From rizzo at iet.unipi.it  Tue Feb  3 12:47:03 2009
From: rizzo at iet.unipi.it (Luigi Rizzo)
Date: Tue Feb  3 12:47:10 2009
Subject: nanobsd dies in newfs
In-Reply-To: <20090203194017.GA58565@bewilderbeast.blackhelicopters.org>
References: <20090203194017.GA58565@bewilderbeast.blackhelicopters.org>
Message-ID: <20090203205245.GA77162@onelab2.iet.unipi.it>

On Tue, Feb 03, 2009 at 02:40:17PM -0500, Michael W. Lucas wrote:
> 
> Hi,
> 
> This is on i386 -current as of Feb 1, 2009.
> 
> Obviously, things have changed in the year since I've built nanoBSD.
> I'm trying to build a very tiny sniffer box, and the build dies in
> newfs(8).  The error and my nanobsd config follow.
> 
> Any suggestions, folks?

this is related to a recent commit i made to newfs.c which works with
dynamic build but not with static build.
See the commit log to see the details.

I am sorry I don't have a good solution short of changing the
function in libufs -- which may be the way to go.

For a quick workaround you can try to revert the change,
or build newfs as dynamically linked.

cheers
luigi
From danger at FreeBSD.org  Tue Feb  3 12:47:26 2009
From: danger at FreeBSD.org (Daniel Gerzo)
Date: Tue Feb  3 12:47:49 2009
Subject: [head tinderbox] failure on arm/arm
In-Reply-To: <20090203201441.7C9A57302F@freebsd-current.sentex.ca>
References: <20090203201441.7C9A57302F@freebsd-current.sentex.ca>
Message-ID: <1924472521.20090203212920@rulez.sk>

Hello,

Tuesday, February 3, 2009, 9:14:41 PM, you wrote:

> TB --- 2009-02-03 20:00:00 - tinderbox 2.6 running on freebsd-current.sentex.ca

> -Wno-pointer-sign -c /src/lib/libc/string/memchr.c
> /src/lib/libc/string/memchr.c:43: error: conflicting types for 'memchr'
> /src/lib/libc/../../include/string.h:61: error: previous declaration of 'memchr' was here
> *** Error code 1

My fault, we are working with Warner on fix. Should be committed soon.

-- 
Best regards,
 Daniel                            mailto:danger@FreeBSD.org

From tinderbox at freebsd.org  Tue Feb  3 12:47:30 2009
From: tinderbox at freebsd.org (FreeBSD Tinderbox)
Date: Tue Feb  3 12:47:50 2009
Subject: [head tinderbox] failure on ia64/ia64
Message-ID: <20090203204726.C48337302F@freebsd-current.sentex.ca>

TB --- 2009-02-03 20:31:02 - tinderbox 2.6 running on freebsd-current.sentex.ca
TB --- 2009-02-03 20:31:02 - starting HEAD tinderbox run for ia64/ia64
TB --- 2009-02-03 20:31:02 - cleaning the object tree
TB --- 2009-02-03 20:31:29 - cvsupping the source tree
TB --- 2009-02-03 20:31:29 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/ia64/ia64/supfile
TB --- 2009-02-03 20:31:37 - building world
TB --- 2009-02-03 20:31:37 - MAKEOBJDIRPREFIX=/obj
TB --- 2009-02-03 20:31:37 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2009-02-03 20:31:37 - TARGET=ia64
TB --- 2009-02-03 20:31:37 - TARGET_ARCH=ia64
TB --- 2009-02-03 20:31:37 - TZ=UTC
TB --- 2009-02-03 20:31:37 - __MAKE_CONF=/dev/null
TB --- 2009-02-03 20:31:37 - cd /src
TB --- 2009-02-03 20:31:37 - /usr/bin/make -B buildworld
>>> World build started on Tue Feb  3 20:31: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
[...]
cc -O2 -pipe  -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/ia64 -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/ia64/src/lib/libc -I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -DSYMBOL_VERSIONING -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/lib/libc/string/fls.c
cc -O2 -pipe  -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/ia64 -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/ia64/src/lib/libc -I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -DSYMBOL_VERSIONING -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/lib/libc/string/flsl.c
cc -O2 -pipe  -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/ia64 -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/ia64/src/lib/libc -I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -DSYMBOL_VERSIONING -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/lib/libc/string/flsll.c
cc -O2 -pipe  -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/ia64 -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/ia64/src/lib/libc -I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -DSYMBOL_VERSIONING -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/lib/libc/string/index.c
cc -O2 -pipe  -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/ia64 -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/ia64/src/lib/libc -I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -DSYMBOL_VERSIONING -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/lib/libc/string/memccpy.c
cc -O2 -pipe  -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/ia64 -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/ia64/src/lib/libc -I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -DSYMBOL_VERSIONING -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/lib/libc/string/memchr.c
/src/lib/libc/string/memchr.c:43: error: conflicting types for 'memchr'
/src/lib/libc/../../include/string.h:61: error: previous declaration of 'memchr' was here
*** 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-02-03 20:47:26 - WARNING: /usr/bin/make returned exit code  1 
TB --- 2009-02-03 20:47:26 - ERROR: failed to build world
TB --- 2009-02-03 20:47:26 - 729.07 user 66.55 system 984.54 real


http://tinderbox.des.no/tinderbox-head-HEAD-ia64-ia64.full
From tinderbox at freebsd.org  Tue Feb  3 12:51:13 2009
From: tinderbox at freebsd.org (FreeBSD Tinderbox)
Date: Tue Feb  3 12:51:32 2009
Subject: [head tinderbox] failure on powerpc/powerpc
Message-ID: <20090203205106.BBDAE7302F@freebsd-current.sentex.ca>

TB --- 2009-02-03 20:34:34 - tinderbox 2.6 running on freebsd-current.sentex.ca
TB --- 2009-02-03 20:34:34 - starting HEAD tinderbox run for powerpc/powerpc
TB --- 2009-02-03 20:34:34 - cleaning the object tree
TB --- 2009-02-03 20:35:01 - cvsupping the source tree
TB --- 2009-02-03 20:35:01 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/powerpc/powerpc/supfile
TB --- 2009-02-03 20:35:08 - building world
TB --- 2009-02-03 20:35:08 - MAKEOBJDIRPREFIX=/obj
TB --- 2009-02-03 20:35:08 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2009-02-03 20:35:08 - TARGET=powerpc
TB --- 2009-02-03 20:35:08 - TARGET_ARCH=powerpc
TB --- 2009-02-03 20:35:08 - TZ=UTC
TB --- 2009-02-03 20:35:08 - __MAKE_CONF=/dev/null
TB --- 2009-02-03 20:35:08 - cd /src
TB --- 2009-02-03 20:35:08 - /usr/bin/make -B buildworld
>>> World build started on Tue Feb  3 20:35:09 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/powerpc -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/powerpc/src/lib/libc -I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -DSYMBOL_VERSIONING -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/lib/libc/string/fls.c
cc -O2 -pipe  -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/powerpc -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/powerpc/src/lib/libc -I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -DSYMBOL_VERSIONING -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/lib/libc/string/flsl.c
cc -O2 -pipe  -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/powerpc -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/powerpc/src/lib/libc -I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -DSYMBOL_VERSIONING -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/lib/libc/string/flsll.c
cc -O2 -pipe  -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/powerpc -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/powerpc/src/lib/libc -I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -DSYMBOL_VERSIONING -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/lib/libc/string/index.c
cc -O2 -pipe  -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/powerpc -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/powerpc/src/lib/libc -I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -DSYMBOL_VERSIONING -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/lib/libc/string/memccpy.c
cc -O2 -pipe  -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/powerpc -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/powerpc/src/lib/libc -I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -DSYMBOL_VERSIONING -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/lib/libc/string/memchr.c
/src/lib/libc/string/memchr.c:43: error: conflicting types for 'memchr'
/src/lib/libc/../../include/string.h:61: error: previous declaration of 'memchr' was here
*** 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-02-03 20:51:06 - WARNING: /usr/bin/make returned exit code  1 
TB --- 2009-02-03 20:51:06 - ERROR: failed to build world
TB --- 2009-02-03 20:51:06 - 741.51 user 67.82 system 992.09 real


http://tinderbox.des.no/tinderbox-head-HEAD-powerpc-powerpc.full
From vova at fbsd.ru  Tue Feb  3 14:07:14 2009
From: vova at fbsd.ru (Vladimir Grebenschikov)
Date: Tue Feb  3 14:07:22 2009
Subject: Usb2 and hal issue (fix to previous)
In-Reply-To: <1226688529.19638.9.camel@localhost>
References: <83e5fb980811051638n5f9a1a5dr60160ed7e2ed7a1c@mail.gmail.com>
	<1226687528.19638.4.camel@localhost>
	<1226688529.19638.9.camel@localhost>
Message-ID: <1233697339.2314.3.camel@localhost>

On Fri, 2008-11-14 at 13:48 -0500, Coleman Kane wrote:

> > Additionally, I think it is a bug that hald busy-loops trying (and
> > failing) to open "/dev/usb". Ideally, I think that hald should put a
> > sleep in there of some sort, to give up CPU to something else.

Is there any progress regarding to the issue ?
Just tried usb2 today (recent 8-CURRENT and recent gnome) and gain see
100% CPU by hald, patch helps, but probably it worth to commit it ?

-- 
Vladimir B. Grebenschikov
vova@fbsd.ru
From marcus at marcuscom.com  Tue Feb  3 14:11:23 2009
From: marcus at marcuscom.com (Joe Marcus Clarke)
Date: Tue Feb  3 14:11:30 2009
Subject: Usb2 and hal issue (fix to previous)
In-Reply-To: <1233697339.2314.3.camel@localhost>
References: <83e5fb980811051638n5f9a1a5dr60160ed7e2ed7a1c@mail.gmail.com>
	<1226687528.19638.4.camel@localhost>
	<1226688529.19638.9.camel@localhost>
	<1233697339.2314.3.camel@localhost>
Message-ID: <1233699080.24228.51.camel@shumai.marcuscom.com>

On Wed, 2009-02-04 at 00:42 +0300, Vladimir Grebenschikov wrote:
> On Fri, 2008-11-14 at 13:48 -0500, Coleman Kane wrote:
> 
> > > Additionally, I think it is a bug that hald busy-loops trying (and
> > > failing) to open "/dev/usb". Ideally, I think that hald should put a
> > > sleep in there of some sort, to give up CPU to something else.
> 
> Is there any progress regarding to the issue ?
> Just tried usb2 today (recent 8-CURRENT and recent gnome) and gain see
> 100% CPU by hald, patch helps, but probably it worth to commit it ?

No progress yet.  I've been very busy with work and getting hal to play
nicely with X.

Joe

-- 
PGP Key : http://www.marcuscom.com/pgp.asc
-------------- 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/20090203/9091aa39/attachment-0001.pgp
From spikey.it at gmail.com  Tue Feb  3 14:28:44 2009
From: spikey.it at gmail.com (Andrea Di Pasquale)
Date: Tue Feb  3 14:28:51 2009
Subject: Boot panic on macbook alluminium
Message-ID: <A1C3B1D2-8E6C-4BEA-99C9-22CDAC50C507@gmail.com>

Hi guys! In my boot freebsd install, i have panic:

pci0: <ACPI PCI bus> on pcib0
Memory modified after free 0xc5b026a0(12) val=c0dedead @ 0xc5b026a
panic: Most recently used by (null)

cpuid = 0
KDB: enter: panic
[Thread pid 0 tid 100000]
Stopped at kdb_enter+0x3a: movl $0,kdb_why

I can use ddb because the macbook keyboard is usb device,
so i think that before the panic, the kernel doesn't load the
usb keyboard driver.

Thank you,
cheers

Andrea
From sobomax at FreeBSD.org  Tue Feb  3 14:45:47 2009
From: sobomax at FreeBSD.org (Maxim Sobolev)
Date: Tue Feb  3 14:45:54 2009
Subject: GEOM_PART: a quick update on logical partitions
In-Reply-To: <gm9fh1$4el$1@ger.gmane.org>
References: <FCA8C5E4-BC41-4711-9EBC-CD692144F6B8@mac.com>	<20090203082153.565746e2@zelda.local>	<b649e5e0902030357k7508b4e7kc69c31a354b3e077@mail.gmail.com>
	<gm9fh1$4el$1@ger.gmane.org>
Message-ID: <4988C908.1030002@FreeBSD.org>

Ivan Voras wrote:
> Marius N?nnerich wrote:
> 
>> I'm not happy with the symlinks either. When someone is manipulating a
>> partition table she should be able to live with the consequences. I
>> would rather go for the UUID in UFS header approach if there is enough
>> room. BTW I implemented GPT UUID glabels a while ago please see:
>> http://www.freebsd.org/cgi/query-pr.cgi?pr=128398
> 
> I have a patch for UFS "GUID" labels (not exactly GUIDs, but every UFS
> file system has a reasonably unique ID associated with it) but have
> encountered what seems a bug in GEOM slicers - two dev entries pointing
> to the same device don't work well with orphaning/tasting. Have you
> encountered something similar perhaps?

Why exactly do we need UFS "GUID" labels, when we already have 
GEOM_LABEL, which works just fine with UFS.

-Maxim
From csjp at freebsd.org  Tue Feb  3 15:32:44 2009
From: csjp at freebsd.org (Christian Peron)
Date: Tue Feb  3 15:32:51 2009
Subject: write-only variables in src/sys/ - possible bugs
In-Reply-To: <49874CA8.5090605@gmx.de>
References: <49874CA8.5090605@gmx.de>
Message-ID: <20090203231155.GA69101@jnz.sqrt.ca>

I started following up on this and ran into an issue for these:

sys/net/bpf_buffer.c:133: warning: variable 'dst' is never read
sys/net/bpf_buffer.c:134: warning: variable 'count' is never read
sys/net/bpf_buffer.c:142: warning: variable 'dst' is never read


/*
 * Scatter-gather data copy from an mbuf chain to the current kernel buffer.
 */
void
bpf_buffer_append_mbuf(struct bpf_d *d, caddr_t buf, u_int offset, void *src,
    u_int len)
{
        const struct mbuf *m;
        u_char *dst;
        u_int count;
 
        m = (struct mbuf *)src;
        dst = (u_char *)buf + offset;
        while (len > 0) {
                if (m == NULL)
                        panic("bpf_mcopy");
                count = min(m->m_len, len);
                bcopy(mtod(m, void *), dst, count);
                m = m->m_next;
[..]

Does it not consider being passed as an argument to a function as
being read?

Cheers
From nakal at web.de  Tue Feb  3 15:45:39 2009
From: nakal at web.de (Martin)
Date: Tue Feb  3 15:45:47 2009
Subject: GEOM_PART: a quick update on logical partitions
In-Reply-To: <D35C93DE-CB3F-4631-AC38-4CCCE3877C23@mac.com>
References: <FCA8C5E4-BC41-4711-9EBC-CD692144F6B8@mac.com>
	<20090203082153.565746e2@zelda.local>
	<D35C93DE-CB3F-4631-AC38-4CCCE3877C23@mac.com>
Message-ID: <20090204004534.11ccca19@zelda.local>

Am Tue, 03 Feb 2009 10:15:50 -0800
schrieb Marcel Moolenaar <xcllnt@mac.com>:

> What happens if you add a partition to the head of the list?

Well, I would never do this, because usually this creates mess with
drive letters on MS-DOS and MS-Windows.

Then, it is quite unusual to insert a new logical partition and copy
all entries in the list one place down. First because people usually
allocate the logical partitions from the start of the "extended
partition" container and move on till it's fully allocated.

Btw, the entries should be sorted to avoid problems with older systems.
I remember that win95-fdisk will destroy your whole partition table, if
you don't sort it. But this is perhaps not that important here.

> > Second thing is, why do you need something like "s5"?
> 
> That's the how logical partitions are named in 7.x

I understand it is for compatibility, but the softlinks may introduce
new issues, mostly with all the nice geom features. That's why I tried
to ask about how you would support the suffixes that geom modules
automatically create? Would it still work?

--
Martin
From ivoras at freebsd.org  Tue Feb  3 15:57:41 2009
From: ivoras at freebsd.org (Ivan Voras)
Date: Tue Feb  3 15:57:48 2009
Subject: GEOM_PART: a quick update on logical partitions
In-Reply-To: <4988C908.1030002@FreeBSD.org>
References: <FCA8C5E4-BC41-4711-9EBC-CD692144F6B8@mac.com>
	<20090203082153.565746e2@zelda.local>
	<b649e5e0902030357k7508b4e7kc69c31a354b3e077@mail.gmail.com>
	<gm9fh1$4el$1@ger.gmane.org> <4988C908.1030002@FreeBSD.org>
Message-ID: <9bbcef730902031536h5ec406b3h5e375cfdf9f4abc7@mail.gmail.com>

2009/2/3 Maxim Sobolev <sobomax@freebsd.org>:
> Ivan Voras wrote:
>>
>> Marius N?nnerich wrote:
>>
>>> I'm not happy with the symlinks either. When someone is manipulating a
>>> partition table she should be able to live with the consequences. I
>>> would rather go for the UUID in UFS header approach if there is enough
>>> room. BTW I implemented GPT UUID glabels a while ago please see:
>>> http://www.freebsd.org/cgi/query-pr.cgi?pr=128398
>>
>> I have a patch for UFS "GUID" labels (not exactly GUIDs, but every UFS
>> file system has a reasonably unique ID associated with it) but have
>> encountered what seems a bug in GEOM slicers - two dev entries pointing
>> to the same device don't work well with orphaning/tasting. Have you
>> encountered something similar perhaps?
>
> Why exactly do we need UFS "GUID" labels, when we already have GEOM_LABEL,
> which works just fine with UFS.

So people don't need to make up dummy labels for dozens of file systems :)

Also, "UFS GUIDs" are always present, even in root file systems
created by sysinstall by default. It's a good idea.
From xcllnt at mac.com  Tue Feb  3 16:30:20 2009
From: xcllnt at mac.com (Marcel Moolenaar)
Date: Tue Feb  3 16:30:27 2009
Subject: GEOM_PART: a quick update on logical partitions
In-Reply-To: <20090204004534.11ccca19@zelda.local>
References: <FCA8C5E4-BC41-4711-9EBC-CD692144F6B8@mac.com>
	<20090203082153.565746e2@zelda.local>
	<D35C93DE-CB3F-4631-AC38-4CCCE3877C23@mac.com>
	<20090204004534.11ccca19@zelda.local>
Message-ID: <EF0E3768-DF76-4AF5-9CDF-646DF44E69B3@mac.com>


On Feb 3, 2009, at 3:45 PM, Martin wrote:

> Am Tue, 03 Feb 2009 10:15:50 -0800
> schrieb Marcel Moolenaar <xcllnt@mac.com>:
>
>> What happens if you add a partition to the head of the list?
>
> Well, I would never do this, because usually this creates mess with
> drive letters on MS-DOS and MS-Windows.

I don't see a mess with XP. I can easily remove the first logical
partition and then fill the space again...

> Then, it is quite unusual to insert a new logical partition and copy
> all entries in the list one place down.

What do you mean copy?

> First because people usually
> allocate the logical partitions from the start of the "extended
> partition" container and move on till it's fully allocated.

Sure, but you can remove any logical partition in any
order, which means that subsequent adds can also be
in any order...

> Btw, the entries should be sorted to avoid problems with older  
> systems.
> I remember that win95-fdisk will destroy your whole partition table,  
> if
> you don't sort it. But this is perhaps not that important here.
>
>>> Second thing is, why do you need something like "s5"?
>>
>> That's the how logical partitions are named in 7.x
>
> I understand it is for compatibility, but the softlinks may introduce
> new issues, mostly with all the nice geom features. That's why I tried
> to ask about how you would support the suffixes that geom modules
> automatically create? Would it still work?

Yes, but those will be using the "fixed" names, not the
softlinks.

-- 
Marcel Moolenaar
xcllnt@mac.com



From sobomax at FreeBSD.org  Tue Feb  3 17:33:26 2009
From: sobomax at FreeBSD.org (Maxim Sobolev)
Date: Tue Feb  3 17:33:32 2009
Subject: GEOM_PART: a quick update on logical partitions
In-Reply-To: <9bbcef730902031536h5ec406b3h5e375cfdf9f4abc7@mail.gmail.com>
References: <FCA8C5E4-BC41-4711-9EBC-CD692144F6B8@mac.com>	
	<20090203082153.565746e2@zelda.local>	
	<b649e5e0902030357k7508b4e7kc69c31a354b3e077@mail.gmail.com>	
	<gm9fh1$4el$1@ger.gmane.org> <4988C908.1030002@FreeBSD.org>
	<9bbcef730902031536h5ec406b3h5e375cfdf9f4abc7@mail.gmail.com>
Message-ID: <4988F053.3060709@FreeBSD.org>

Ivan Voras wrote:
> 2009/2/3 Maxim Sobolev <sobomax@freebsd.org>:
>> Ivan Voras wrote:
>>> Marius N?nnerich wrote:
>>>
>>>> I'm not happy with the symlinks either. When someone is manipulating a
>>>> partition table she should be able to live with the consequences. I
>>>> would rather go for the UUID in UFS header approach if there is enough
>>>> room. BTW I implemented GPT UUID glabels a while ago please see:
>>>> http://www.freebsd.org/cgi/query-pr.cgi?pr=128398
>>> I have a patch for UFS "GUID" labels (not exactly GUIDs, but every UFS
>>> file system has a reasonably unique ID associated with it) but have
>>> encountered what seems a bug in GEOM slicers - two dev entries pointing
>>> to the same device don't work well with orphaning/tasting. Have you
>>> encountered something similar perhaps?
>> Why exactly do we need UFS "GUID" labels, when we already have GEOM_LABEL,
>> which works just fine with UFS.
> 
> So people don't need to make up dummy labels for dozens of file systems :)
> 
> Also, "UFS GUIDs" are always present, even in root file systems
> created by sysinstall by default. It's a good idea.

sysinstall can auto-generate labels and use them to generate fstab, 
right now it leaves UFS label empty anyway. This should cover 99.99% of 
all cases. I just worried that instead of one labeling scheme we would 
end up with 10, neither of which is really well supported.

-Maxim
From nakal at web.de  Tue Feb  3 23:27:25 2009
From: nakal at web.de (Martin)
Date: Tue Feb  3 23:27:32 2009
Subject: GEOM_PART: a quick update on logical partitions
In-Reply-To: <EF0E3768-DF76-4AF5-9CDF-646DF44E69B3@mac.com>
References: <FCA8C5E4-BC41-4711-9EBC-CD692144F6B8@mac.com>
	<20090203082153.565746e2@zelda.local>
	<D35C93DE-CB3F-4631-AC38-4CCCE3877C23@mac.com>
	<20090204004534.11ccca19@zelda.local>
	<EF0E3768-DF76-4AF5-9CDF-646DF44E69B3@mac.com>
Message-ID: <20090204082718.0f217b1a@zelda.local>

Am Tue, 03 Feb 2009 16:30:14 -0800
schrieb Marcel Moolenaar <xcllnt@mac.com>:

> > Then, it is quite unusual to insert a new logical partition and copy
> > all entries in the list one place down.
> 
> What do you mean copy?

I try to figure out why you think that the device names will change,
when you simply use the offset in the partition list. When you want to
insert a new partition at the beginning and you already have one at
list offset 0 then you have to copy it one place down to 1. I thought
that you want to offer a special solution for this problem.

> Sure, but you can remove any logical partition in any
> order, which means that subsequent adds can also be
> in any order...

Ok, so when you have logical partition 0, 1 and 2.

/dev/ad0s1.0
/dev/ad0s1.1
/dev/ad0s1.2

you can remove partitions 0 and 1, and you get:

/dev/ad0s1.2

now you can insert 0 again and you get:

/dev/ad0s1.0
/dev/ad0s1.2

You can still use softlinks here. In the last situation you would get
ad0s5 and ad0s7. Do I forget about something?

> Yes, but those will be using the "fixed" names, not the
> softlinks.

I see. But you have to be aware that you create a special case here.
Someone who starts "geli journal ad0s5" won't get "ad0s5.journal".

And is it really a good idea to have the partition block number
for the suffix? Imagine you use gpart or partition magic to move all
partitions 1GB down, for example to enlarge the file system on the first
primary partition. You would need to figure out each logical partition
block number of the extended partition to fix the situation, if you use
geom_eli/geom_journal before mounting. You would have to edit it in
rc.conf for geli devices that appear on boot and fstab for for both,
journal and eli.

When you don't touch the logical layout itself, it shouldn't change the
device names, in my opinion.

-- 
Martin
From randy at psg.com  Tue Feb  3 23:33:42 2009
From: randy at psg.com (Randy Bush)
Date: Tue Feb  3 23:33:49 2009
Subject: GEOM and moving to CURRENT from 7.1
In-Reply-To: <6D9C4D7C-88BD-4345-B281-26915601F4BF@mac.com>
References: <FC3D3CF7-091B-4ECF-BE38-6C7751C20994@neville-neil.com>
	<alpine.BSF.2.00.0901112002080.3696@ibyngvyr.purzvxnyf.bet>
	<496D0364.2060505@psg.com>
	<47d0403c0901131335h46e7b151p3768de9a3e2c2027@mail.gmail.com>
	<EC370904A7B74B93887C79E120CA2835@adnote989>
	<085BEE07-BAE5-4A45-A14D-9587987FAA5C@mac.com>
	<496F44FA.1070004@andric.com>
	<48C1C477-B7BE-43B0-AC57-9DEB7BF9AA88@mac.com>
	<496F7347.4060007@andric.com>
	<A8E47805-888E-4282-8623-72A65B593D47@mac.com>
	<496F8D8A.1060508@andric.com>
	<BC6ACB2A-CBC5-428B-8749-999B48B2D1C8@mac.com>
	<496F928F.6010807@andric.com>
	<DBB310AB-75BF-4BF7-AA35-63ADBD0B66B6@mac.com>
	<496FE791.7000709@psg.com> <497A31F7.1070005@psg.com>
	<6D9C4D7C-88BD-4345-B281-26915601F4BF@mac.com>
Message-ID: <m23aeuodv0.wl%randy@psg.com>

>> what ever happened here.  we still have a system with gmirror that  
>> we have suspended work on until we know what we should be doing.
> Wipe out the second sector on the disk.

well, that kinda works.  i decided i would back off and install
current from iso.  but the latest snapshot i find is

ftp://ftp.freebsd.org/pub/FreeBSD/snapshots/200812/8.0-CURRENT-200812-amd64-disc1.iso

which is before any fix, i believe.

clue bat, please?

randy
From vova at fbsd.ru  Tue Feb  3 23:59:16 2009
From: vova at fbsd.ru (Vladimir Grebenschikov)
Date: Tue Feb  3 23:59:24 2009
Subject: USB2 - umass problem
Message-ID: <1233734352.1767.55.camel@localhost>

 Hi

USB2 team, thank you for really big effort on improving FreeBSD usb
stack.

I've tried it and found that ums, ubt, ukbd just work.

u3g card was detected
ohci0: <NEC uPD 9210 USB controller> mem 0x88000000-0x88000fff irq 16 at
device 0.0 on cardbus0
ohci0: [ITHREAD]
usbus5: <NEC uPD 9210 USB controller> on ohci0
usbus5: 12Mbps Full Speed USB v1.0
ohci1: <NEC uPD 9210 USB controller> mem 0x88001000-0x88001fff irq 16 at
device 0.1 on cardbus0
ohci1: [ITHREAD]
ugen5.1: <NEC> at usbus5
ushub6: <NEC OHCI root HUB, class 9/0, rev 1.00/1.00, addr 1> on usbus5
usbus6: <NEC uPD 9210 USB controller> on ohci1
usbus6: 12Mbps Full Speed USB v1.0
ugen6.1: <NEC> at usbus6
ushub7: <NEC OHCI root HUB, class 9/0, rev 1.00/1.00, addr 1> on usbus6
ushub6: 1 port with 1 removable, self powered
ushub7: 1 port with 1 removable, self powered
ugen5.2: <Huawei Technologies> at usbus5
u3g0: <Data Interface> on usbus5
u3g1: <Data Interface> on usbus5
u3g2: <Data Interface> on usbus5

By some reason devfs semantic was changed:
Instead of /dev/cuaU0.[0-2] and /dev/ttyU0.[0-2], I've get 
/dev/cuaU[0-2] /dev/ttyU[0-2] and! /dev/cuau1 /dev/ttyu1
What is reason for such change (additional port with lowercase 'u' and
U[0-2] instead of more logical U0.[0-2]) ?

Excellent news is that I've successfully removed PCMCI card with u3g USB
controller from notebook and have no panic as it was with old USB
stack. 

By some reason connection was failed but chat with modem was ok. Will
try again.

Simple umass device (WD external disk) works fine, but 
integrated to doc-station card-reader failed:

First time card insertion, two umass devices appeared, both just do not
work:

ugen4.4: <SMSC> at usbus4
umass0: <SMSC 2228, class 0/0, rev 2.00/3.95, addr 4> on usbus4
umass0:  SCSI over Bulk-Only; quirks = 0x0000
umass0:5:0:-1: Attached to scbus5
(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): SCSI Status: Check Condition
(probe0:umass-sim0:0:0:0): NOT READY asc:3a,0
(probe0:umass-sim0:0:0:0): Medium not present
(probe0:umass-sim0:0:0:0): Unretryable error
da0 at umass-sim0 bus 0 target 0 lun 0
da0: <SMSC 2228  HS-COMBO 3.95> Removable Direct Access SCSI-0 device 
da0: 40.000MB/s transfers
da0: Attempt to query device size failed: NOT READY, Medium not present
(probe0:umass-sim0:0:0:1): TEST UNIT READY. CDB: 0 20 0 0 0 0 
(probe0:umass-sim0:0:0:1): CAM Status: SCSI Status Error
(probe0:umass-sim0:0:0:1): SCSI Status: Check Condition
(probe0:umass-sim0:0:0:1): NOT READY asc:3a,0
(probe0:umass-sim0:0:0:1): Medium not present
(probe0:umass-sim0:0:0:1): Unretryable error
da1 at umass-sim0 bus 0 target 0 lun 1
da1: <SMSC 2228  HS-CF 3.95> Removable Direct Access SCSI-0 device 
da1: 40.000MB/s transfers
da1: Attempt to query device size failed: NOT READY, Medium not present

Second time - a bit better, second device read correct card label, but
still failed on mount:

ugen4.4: <SMSC> at usbus4
umass0: <SMSC 2228, class 0/0, rev 2.00/3.95, addr 4> on usbus4
umass0:  SCSI over Bulk-Only; quirks = 0x0000
umass0:5:0:-1: Attached to scbus5
(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): SCSI 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)
da0 at umass-sim0 bus 0 target 0 lun 0
da0: <SMSC 2228  HS-COMBO 3.95> Removable Direct Access SCSI-0 device 
da0: 40.000MB/s transfers
da0: 980MB (2007040 512 byte sectors: 64H 32S/T 980C)
(probe0:umass-sim0:0:0:1): TEST UNIT READY. CDB: 0 20 0 0 0 0 
(probe0:umass-sim0:0:0:1): CAM Status: SCSI Status Error
(probe0:umass-sim0:0:0:1): SCSI Status: Check Condition
(probe0:umass-sim0:0:0:1): NOT READY asc:3a,0
(probe0:umass-sim0:0:0:1): Medium not present
(probe0:umass-sim0:0:0:1): Unretryable error
da1 at umass-sim0 bus 0 target 0 lun 1
da1: <SMSC 2228  HS-CF 3.95> Removable Direct Access SCSI-0 device 
da1: 40.000MB/s transfers
da1: Attempt to query device size failed: NOT READY, Medium not present
GEOM_LABEL: Label for provider da0s1 is label/e60mmc.

# /sbin/mount -t msdosfs /dev/da0s1 /mnt
mount_msdosfs: /dev/da0s1: Input/output error
#

and dmesg has lots of:
(da0:umass-sim0:0:0:0): MEDIUM ERROR asc:11,0
(da0:umass-sim0:0:0:0): Unrecovered read error
(da0:umass-sim0:0:0:0): Retrying Command (per Sense Data)
(da0:umass-sim0:0:0:0): READ(10). CDB: 28 0 0 0 8 80 0 0 10 0 
(da0:umass-sim0:0:0:0): CAM Status: SCSI Status Error
(da0:umass-sim0:0:0:0): SCSI Status: Check Condition
(da0:umass-sim0:0:0:0): MEDIUM ERROR asc:11,0
(da0:umass-sim0:0:0:0): Unrecovered read error
(da0:umass-sim0:0:0:0): Retrying Command (per Sense Data)
(da0:umass-sim0:0:0:0): READ(10). CDB: 28 0 0 0 8 80 0 0 10 0 
(da0:umass-sim0:0:0:0): CAM Status: SCSI Status Error
(da0:umass-sim0:0:0:0): SCSI Status: Check Condition
(da0:umass-sim0:0:0:0): MEDIUM ERROR asc:11,0
(da0:umass-sim0:0:0:0): Unrecovered read error
(da0:umass-sim0:0:0:0): Retrying Command (per Sense Data)
(da0:umass-sim0:0:0:0): READ(10). CDB: 28 0 0 0 8 80 0 0 10 0 
(da0:umass-sim0:0:0:0): CAM Status: SCSI Status Error
(da0:umass-sim0:0:0:0): SCSI Status: Check Condition


# usbconfig 
ugen0.1: <UHCI root HUB Intel> at usbus0, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON
ugen1.1: <UHCI root HUB Intel> at usbus1, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON
ugen2.1: <UHCI root HUB Intel> at usbus2, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON
ugen3.1: <UHCI root HUB Intel> at usbus3, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON
ugen4.1: <EHCI root HUB Intel> at usbus4, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=ON
ugen4.2: <product 0x4486 IBM> at usbus4, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=SAVE
ugen4.3: <Microsoft 5-Button Mouse with IntelliEye(TM) Microsoft> at usbus4, cfg=0 md=HOST spd=LOW (1.5Mbps) pwr=ON
ugen3.2: <BCM2045B Broadcom Corp> at usbus3, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON
ugen3.3: <Biometric Coprocessor STMicroelectronics> at usbus3, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON
ugen4.4: <2228 SMSC> at usbus4, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=ON
# 

With u3gcard:
...
ugen5.1: <OHCI root HUB NEC> at usbus5, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON
ugen6.1: <OHCI root HUB NEC> at usbus6, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON
ugen5.2: <Huawei Mobile Huawei Technologies> at usbus5, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON


Any hints regarding issues above ?

Side question, is there any way to ask usbconfig driver that attached to
every device (as it was with usbdevs -d) ?

# uname -a
FreeBSD vbook.fbsd.ru 8.0-CURRENT FreeBSD 8.0-CURRENT #2: Mon Feb  2 16:46:22 MSK 2009     root@vbook.fbsd.ru:/usr/obj/usr/src/sys/VBOOK  i386

-- 
Vladimir B. Grebenschikov
vova@fbsd.ru
From xcllnt at mac.com  Wed Feb  4 00:06:16 2009
From: xcllnt at mac.com (Marcel Moolenaar)
Date: Wed Feb  4 00:06:22 2009
Subject: GEOM_PART: a quick update on logical partitions
In-Reply-To: <20090204082718.0f217b1a@zelda.local>
References: <FCA8C5E4-BC41-4711-9EBC-CD692144F6B8@mac.com>
	<20090203082153.565746e2@zelda.local>
	<D35C93DE-CB3F-4631-AC38-4CCCE3877C23@mac.com>
	<20090204004534.11ccca19@zelda.local>
	<EF0E3768-DF76-4AF5-9CDF-646DF44E69B3@mac.com>
	<20090204082718.0f217b1a@zelda.local>
Message-ID: <9D6C9DA2-7BBB-42C6-9F3E-4B8EF2078969@mac.com>


On Feb 3, 2009, at 11:27 PM, Martin wrote:

> Am Tue, 03 Feb 2009 16:30:14 -0800
> schrieb Marcel Moolenaar <xcllnt@mac.com>:
>
>>> Then, it is quite unusual to insert a new logical partition and copy
>>> all entries in the list one place down.
>>
>> What do you mean copy?
>
> I try to figure out why you think that the device names will change,
> when you simply use the offset in the partition list.

Please read:
	http://en.wikipedia.org/wiki/Extended_partition

and then explain what you mean.

> Ok, so when you have logical partition 0, 1 and 2.
>
> /dev/ad0s1.0
> /dev/ad0s1.1
> /dev/ad0s1.2
>
> you can remove partitions 0 and 1, and you get:
>
> /dev/ad0s1.2

No, you have 0.

> now you can insert 0 again and you get:
>
> /dev/ad0s1.0
> /dev/ad0s1.2

You'll have 0 and 1.

> You can still use softlinks here. In the last situation you would get
> ad0s5 and ad0s7. Do I forget about something?

Yes. Consider adding 4 logical partitions in the
space freed up by removing the first 2. What was
the third partition in your example then becomes
the 5th. How do you want to deal with that if
you use "the offset".

> I see. But you have to be aware that you create a special case here.
> Someone who starts "geli journal ad0s5" won't get "ad0s5.journal".

True.

>
>
> And is it really a good idea to have the partition block number
> for the suffix?

Seems the best so far.

> Imagine you use gpart or partition magic to move all
> partitions 1GB down, for example to enlarge the file system on the  
> first
> primary partition. You would need to figure out each logical partition
> block number of the extended partition to fix the situation,

No, they are relative.

-- 
Marcel Moolenaar
xcllnt@mac.com



From vova at fbsd.ru  Wed Feb  4 00:06:30 2009
From: vova at fbsd.ru (Vladimir Grebenschikov)
Date: Wed Feb  4 00:06:36 2009
Subject: USB2 - libusb20 vs devel/libusb
Message-ID: <1233732660.1767.30.camel@localhost>

Hi

I've tried libusb, looks like it works more or less.

What is the right policy about libusb* libraries ?

I have security/libfprint (finger-print reader that uses ugen device)
that stop working after upgrade. 

Following entry in /etc/libmap.conf make it works somehow
libusb-0.1.so		libusb20.so
libusb-0.1.so.8		libusb20.so.1

It allows library to access usb device, but pam authentication with it
still does not work ( looks like it reads fingerprint correctly, but
fails later ).

What is right way to handle that situation ?
Is there universal library, that will work for both stacks ?

PS. I didn't try yet libgphoto2 (it also uses ugen directly).



-- 
Vladimir B. Grebenschikov
vova@fbsd.ru
From admin at lissyara.su  Wed Feb  4 01:36:06 2009
From: admin at lissyara.su (Alex Keda)
Date: Wed Feb  4 01:36:13 2009
Subject: USB2 problems when boot from usb mass storage
Message-ID: <49896183.2050705@lissyara.su>

When I boot from USB hdd with USB2 kernel - system cannot mount root 
partition - mass storage device detect after attempt mount /
When I boot with old-USB kernel (GENERIC) - all OK - mount / correct - 
device detect before mount attempt...

From hselasky at c2i.net  Wed Feb  4 01:42:09 2009
From: hselasky at c2i.net (Hans Petter Selasky)
Date: Wed Feb  4 01:42:16 2009
Subject: USB2 - umass problem
In-Reply-To: <1233734352.1767.55.camel@localhost>
References: <1233734352.1767.55.camel@localhost>
Message-ID: <200902041044.27663.hselasky@c2i.net>

Hi,

On Wednesday 04 February 2009, Vladimir Grebenschikov wrote:
>  Hi
>
>
> By some reason devfs semantic was changed:
> Instead of /dev/cuaU0.[0-2] and /dev/ttyU0.[0-2], I've get
> /dev/cuaU[0-2] /dev/ttyU[0-2] and! /dev/cuau1 /dev/ttyu1
> What is reason for such change (additional port with lowercase 'u' and
> U[0-2] instead of more logical U0.[0-2]) ?

It is because we are attaching drivers per interface instead of per device. A 
new modem unit is allocated every time we find a modem, simply put. If the 
modem has multiple instances in an interface, /dev/cuaU0.[0...] will be 
created. Else /dev/cuaU... .

>
> Excellent news is that I've successfully removed PCMCI card with u3g USB
> controller from notebook and have no panic as it was with old USB
> stack.

Great!

>
> By some reason connection was failed but chat with modem was ok. Will
> try again.
>
> Simple umass device (WD external disk) works fine, but
> integrated to doc-station card-reader failed:
>
> First time card insertion, two umass devices appeared, both just do not
> work:
>
> ugen4.4: <SMSC> at usbus4
> umass0: <SMSC 2228, class 0/0, rev 2.00/3.95, addr 4> on usbus4
> umass0:  SCSI over Bulk-Only; quirks = 0x0000
> umass0:5:0:-1: Attached to scbus5
> (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): SCSI Status: Check Condition
> (probe0:umass-sim0:0:0:0): NOT READY asc:3a,0
> (probe0:umass-sim0:0:0:0): Medium not present
> (probe0:umass-sim0:0:0:0): Unretryable error
> da0 at umass-sim0 bus 0 target 0 lun 0
> da0: <SMSC 2228  HS-COMBO 3.95> Removable Direct Access SCSI-0 device
> da0: 40.000MB/s transfers
> da0: Attempt to query device size failed: NOT READY, Medium not present

Have you tried "cat /dev/null > /dev/da0", to refresh the label on the disk?
NOTE: /dev/null is not /dev/zero

> da1 at umass-sim0 bus 0 target 0 lun 1
> da1: <SMSC 2228  HS-CF 3.95> Removable Direct Access SCSI-0 device
> da1: 40.000MB/s transfers
> da1: Attempt to query device size failed: NOT READY, Medium not present

Same with "da1"

>
> Second time - a bit better, second device read correct card label, but
> still failed on mount:

Maybe your device needs a quirk, because it hangs on one of the issues SCSI 
commands. Have you looked at:

http://wiki.freebsd.org/USB

>
> # usbconfig
> ugen0.1: <UHCI root HUB Intel> at usbus0, cfg=0 md=HOST spd=FULL (12Mbps)
> pwr=ON ugen1.1: <UHCI root HUB Intel> at usbus1, cfg=0 md=HOST spd=FULL
> (12Mbps) pwr=ON ugen2.1: <UHCI root HUB Intel> at usbus2, cfg=0 md=HOST
> spd=FULL (12Mbps) pwr=ON ugen3.1: <UHCI root HUB Intel> at usbus3, cfg=0
> md=HOST spd=FULL (12Mbps) pwr=ON ugen4.1: <EHCI root HUB Intel> at usbus4,
> cfg=0 md=HOST spd=HIGH (480Mbps) pwr=ON ugen4.2: <product 0x4486 IBM> at
> usbus4, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=SAVE ugen4.3: <Microsoft
> 5-Button Mouse with IntelliEye(TM) Microsoft> at usbus4, cfg=0 md=HOST
> spd=LOW (1.5Mbps) pwr=ON ugen3.2: <BCM2045B Broadcom Corp> at usbus3, cfg=0
> md=HOST spd=FULL (12Mbps) pwr=ON ugen3.3: <Biometric Coprocessor
> STMicroelectronics> at usbus3, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON
> ugen4.4: <2228 SMSC> at usbus4, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=ON #
>
> With u3gcard:
> ...
> ugen5.1: <OHCI root HUB NEC> at usbus5, cfg=0 md=HOST spd=FULL (12Mbps)
> pwr=ON ugen6.1: <OHCI root HUB NEC> at usbus6, cfg=0 md=HOST spd=FULL
> (12Mbps) pwr=ON ugen5.2: <Huawei Mobile Huawei Technologies> at usbus5,
> cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON
>
>
> Any hints regarding issues above ?
>
> Side question, is there any way to ask usbconfig driver that attached to
> every device (as it was with usbdevs -d) ?

No, but you can try the following command which gives a nice overview:

devinfo

>
> # uname -a
> FreeBSD vbook.fbsd.ru 8.0-CURRENT FreeBSD 8.0-CURRENT #2: Mon Feb  2
> 16:46:22 MSK 2009     root@vbook.fbsd.ru:/usr/obj/usr/src/sys/VBOOK  i386

--HPS
From olivier at gid0.org  Wed Feb  4 01:45:23 2009
From: olivier at gid0.org (Olivier SMEDTS)
Date: Wed Feb  4 01:45:32 2009
Subject: USB2 problems when boot from usb mass storage
In-Reply-To: <49896183.2050705@lissyara.su>
References: <49896183.2050705@lissyara.su>
Message-ID: <367b2c980902040145g534b38e2h9f4d785957192164@mail.gmail.com>

Hello,

2009/2/4 Alex Keda <admin@lissyara.su>:
> When I boot from USB hdd with USB2 kernel - system cannot mount root
> partition - mass storage device detect after attempt mount /

Are you trying a recent CURRENT ? I think this behaviour has been
corrected recently.

> When I boot with old-USB kernel (GENERIC) - all OK - mount / correct -
> device detect before mount attempt...
>
> _______________________________________________
> 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 Feb  4 01:47:03 2009
From: hselasky at c2i.net (Hans Petter Selasky)
Date: Wed Feb  4 01:47:10 2009
Subject: USB2 - libusb20 vs devel/libusb
In-Reply-To: <1233732660.1767.30.camel@localhost>
References: <1233732660.1767.30.camel@localhost>
Message-ID: <200902041049.27444.hselasky@c2i.net>

On Wednesday 04 February 2009, Vladimir Grebenschikov wrote:
> Hi
>
> I've tried libusb, looks like it works more or less.
>
> What is the right policy about libusb* libraries ?
>
> I have security/libfprint (finger-print reader that uses ugen device)
> that stop working after upgrade.
>
> Following entry in /etc/libmap.conf make it works somehow
> libusb-0.1.so		libusb20.so
> libusb-0.1.so.8		libusb20.so.1
>
> It allows library to access usb device, but pam authentication with it
> still does not work ( looks like it reads fingerprint correctly, but
> fails later ).

Have you checked the permissions of your device?

usbconfig dump_access

>
> What is right way to handle that situation ?
> Is there universal library, that will work for both stacks ?

I was thinking about doing some detection inside libusb in ports, but 
currently you have to switch manually. On problem is that the libusb code in 
ports is not BSD licensed, so we cannot just copy in the old UGEN support :-(

/*
 * (Free|Open|Net)BSD USB support
 *
 * Derived from Linux version by Richard Tobin.
 *
 * $Id: bsd.c,v 1.33 2006/03/04 01:16:10 jerdfelt Exp $
 * $Name:  $
 *
 * This library is covered by the LGPL, read LICENSE for details.
 */

On the other hand, libusbhid, automatically detects USB stack and switches 
everything accordingly.

> PS. I didn't try yet libgphoto2 (it also uses ugen directly).

--HPS
From admin at lissyara.su  Wed Feb  4 01:47:41 2009
From: admin at lissyara.su (Alex Keda)
Date: Wed Feb  4 01:47:48 2009
Subject: USB2 problems when boot from usb mass storage
In-Reply-To: <367b2c980902040145g534b38e2h9f4d785957192164@mail.gmail.com>
References: <49896183.2050705@lissyara.su>
	<367b2c980902040145g534b38e2h9f4d785957192164@mail.gmail.com>
Message-ID: <4989643A.7050509@lissyara.su>

Olivier SMEDTS ?????:
> Hello,
>
> 2009/2/4 Alex Keda <admin@lissyara.su>:
>   
>> When I boot from USB hdd with USB2 kernel - system cannot mount root
>> partition - mass storage device detect after attempt mount /
>>     
>
> Are you trying a recent CURRENT ? I think this behaviour has been
> corrected recently
>   
I update sources yesterday. (~ 20 hours ago)
>   
>> When I boot with old-USB kernel (GENERIC) - all OK - mount / correct -
>> device detect before mount attempt...

From hselasky at c2i.net  Wed Feb  4 01:52:49 2009
From: hselasky at c2i.net (Hans Petter Selasky)
Date: Wed Feb  4 01:52:57 2009
Subject: USB2 problems when boot from usb mass storage
In-Reply-To: <4989643A.7050509@lissyara.su>
References: <49896183.2050705@lissyara.su>
	<367b2c980902040145g534b38e2h9f4d785957192164@mail.gmail.com>
	<4989643A.7050509@lissyara.su>
Message-ID: <200902041055.14318.hselasky@c2i.net>

On Wednesday 04 February 2009, Alex Keda wrote:
> Olivier SMEDTS ?????:
> > Hello,
> >
> > 2009/2/4 Alex Keda <admin@lissyara.su>:
> >> When I boot from USB hdd with USB2 kernel - system cannot mount root
> >> partition - mass storage device detect after attempt mount /
> >
> > Are you trying a recent CURRENT ? I think this behaviour has been
> > corrected recently
>
> I update sources yesterday. (~ 20 hours ago)
>
> >> When I boot with old-USB kernel (GENERIC) - all OK - mount / correct -
> >> device detect before mount attempt...

There is a temporary solution at:

http://wiki.freebsd.org/USB

--HPS
From vova at fbsd.ru  Wed Feb  4 01:58:09 2009
From: vova at fbsd.ru (Vladimir Grebenschikov)
Date: Wed Feb  4 01:58:27 2009
Subject: USB2 - umass problem
In-Reply-To: <200902041044.27663.hselasky@c2i.net>
References: <1233734352.1767.55.camel@localhost>
	<200902041044.27663.hselasky@c2i.net>
Message-ID: <1233741482.1767.120.camel@localhost>

On Wed, 2009-02-04 at 10:44 +0100, Hans Petter Selasky wrote:

> > By some reason devfs semantic was changed:
> > Instead of /dev/cuaU0.[0-2] and /dev/ttyU0.[0-2], I've get
> > /dev/cuaU[0-2] /dev/ttyU[0-2] and! /dev/cuau1 /dev/ttyu1
> > What is reason for such change (additional port with lowercase 'u' and
> > U[0-2] instead of more logical U0.[0-2]) ?
> 
> It is because we are attaching drivers per interface instead of per device. A 
> new modem unit is allocated every time we find a modem, simply put. If the 
> modem has multiple instances in an interface, /dev/cuaU0.[0...] will be 
> created. Else /dev/cuaU... .

What about /dev/cuau1 /dev/ttyu1 ?

-- 
Vladimir B. Grebenschikov
vova@fbsd.ru
From admin at lissyara.su  Wed Feb  4 02:02:27 2009
From: admin at lissyara.su (Alex Keda)
Date: Wed Feb  4 02:02:33 2009
Subject: USB2 problems when boot from usb mass storage
In-Reply-To: <200902041055.14318.hselasky@c2i.net>
References: <49896183.2050705@lissyara.su>
	<367b2c980902040145g534b38e2h9f4d785957192164@mail.gmail.com>
	<4989643A.7050509@lissyara.su>
	<200902041055.14318.hselasky@c2i.net>
Message-ID: <498967B0.3050507@lissyara.su>

Hans Petter Selasky ?????:
> On Wednesday 04 February 2009, Alex Keda wrote:
>   
>> Olivier SMEDTS ?????:
>>     
>>> Hello,
>>>
>>> 2009/2/4 Alex Keda <admin@lissyara.su>:
>>>       
>>>> When I boot from USB hdd with USB2 kernel - system cannot mount root
>>>> partition - mass storage device detect after attempt mount /
>>>>         
>>> Are you trying a recent CURRENT ? I think this behaviour has been
>>> corrected recently
>>>       
>> I update sources yesterday. (~ 20 hours ago)
>>
>>     
>>>> When I boot with old-USB kernel (GENERIC) - all OK - mount / correct -
>>>> device detect before mount attempt...
>>>>         
>
> There is a temporary solution at:
>
> http://wiki.freebsd.org/USB
>   
OK.
I will wait for a permanent solution, and wait with my transition to the 
new stack.
From vova at fbsd.ru  Wed Feb  4 02:04:09 2009
From: vova at fbsd.ru (Vladimir Grebenschikov)
Date: Wed Feb  4 02:04:16 2009
Subject: USB2 - libusb20 vs devel/libusb
In-Reply-To: <200902041049.27444.hselasky@c2i.net>
References: <1233732660.1767.30.camel@localhost>
	<200902041049.27444.hselasky@c2i.net>
Message-ID: <1233741844.1767.133.camel@localhost>

On Wed, 2009-02-04 at 10:49 +0100, Hans Petter Selasky wrote:

> > I have security/libfprint (finger-print reader that uses ugen device)
> > that stop working after upgrade.
> >
> > Following entry in /etc/libmap.conf make it works somehow
> > libusb-0.1.so		libusb20.so
> > libusb-0.1.so.8	libusb20.so.1
> >
> > It allows library to access usb device, but pam authentication with it
> > still does not work ( looks like it reads fingerprint correctly, but
> > fails later ).
> 
> Have you checked the permissions of your device?
> 
> usbconfig dump_access

I guess problem is not in access, it reads device
$ sudo -s
Scan right ring finger on UPEK TouchStrip
>>> it founds chip
Scan didn't quite work. Please try again.
>>> wrong scan
Scan right ring finger on UPEK TouchStrip
>>> good scan, and some kind of failure here
Password:
sudo: pam_authenticate: conversation failure
$ 

# usbconfig -u 3 -a 3 dump_access
Global Access: root:operator 0660
ugen3.3: <Biometric Coprocessor STMicroelectronics> at usbus3, cfg=0
md=HOST spd=FULL (12Mbps) pwr=ON

  Device Access: operator:operator 0660
    Interface 0 Access: <not set>
#
(I am in operator group) 

> >
> > What is right way to handle that situation ?
> > Is there universal library, that will work for both stacks ?
> 
> I was thinking about doing some detection inside libusb in ports, but 
> currently you have to switch manually. On problem is that the libusb code in 
> ports is not BSD licensed, so we cannot just copy in the old UGEN support :-(

Probably we may provide patch against devel/libusb to depend it on
libusb20 ?
So devel/libusb will stay LGPLed but libusb20 will be BSD licensed ?

-- 
Vladimir B. Grebenschikov
vova@fbsd.ru
From vova at fbsd.ru  Wed Feb  4 02:11:31 2009
From: vova at fbsd.ru (Vladimir Grebenschikov)
Date: Wed Feb  4 02:11:38 2009
Subject: USB2 - umass problem
In-Reply-To: <200902041044.27663.hselasky@c2i.net>
References: <1233734352.1767.55.camel@localhost>
	<200902041044.27663.hselasky@c2i.net>
Message-ID: <1233742285.1767.142.camel@localhost>

On Wed, 2009-02-04 at 10:44 +0100, Hans Petter Selasky wrote:

> > Simple umass device (WD external disk) works fine, but
> > integrated to doc-station card-reader failed:
> >
> > First time card insertion, two umass devices appeared, both just do not
> > work:
> >
> > ugen4.4: <SMSC> at usbus4
> > umass0: <SMSC 2228, class 0/0, rev 2.00/3.95, addr 4> on usbus4
> > umass0:  SCSI over Bulk-Only; quirks = 0x0000
> > umass0:5:0:-1: Attached to scbus5
> > (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): SCSI Status: Check Condition
> > (probe0:umass-sim0:0:0:0): NOT READY asc:3a,0
> > (probe0:umass-sim0:0:0:0): Medium not present
> > (probe0:umass-sim0:0:0:0): Unretryable error
> > da0 at umass-sim0 bus 0 target 0 lun 0
> > da0: <SMSC 2228  HS-COMBO 3.95> Removable Direct Access SCSI-0 device
> > da0: 40.000MB/s transfers
> > da0: Attempt to query device size failed: NOT READY, Medium not present
> 
> Have you tried "cat /dev/null > /dev/da0", to refresh the label on the disk?
> NOTE: /dev/null is not /dev/zero
> 
> > da1 at umass-sim0 bus 0 target 0 lun 1
> > da1: <SMSC 2228  HS-CF 3.95> Removable Direct Access SCSI-0 device
> > da1: 40.000MB/s transfers
> > da1: Attempt to query device size failed: NOT READY, Medium not present
> 
> Same with "da1"
> 
> >
> > Second time - a bit better, second device read correct card label, but
> > still failed on mount:
> 
> Maybe your device needs a quirk, because it hangs on one of the issues SCSI 
> commands. Have you looked at:
> 
> http://wiki.freebsd.org/USB

Probably, did not tried yet, 
but old usb stack works as expected, did all usb1 quircks imported to
usb2 ? 

-- 
Vladimir B. Grebenschikov
vova@fbsd.ru
From hselasky at c2i.net  Wed Feb  4 02:18:17 2009
From: hselasky at c2i.net (Hans Petter Selasky)
Date: Wed Feb  4 02:18:29 2009
Subject: USB2 - umass problem
In-Reply-To: <1233742285.1767.142.camel@localhost>
References: <1233734352.1767.55.camel@localhost>
	<200902041044.27663.hselasky@c2i.net>
	<1233742285.1767.142.camel@localhost>
Message-ID: <200902041120.40833.hselasky@c2i.net>

On Wednesday 04 February 2009, Vladimir Grebenschikov wrote:
>
> Probably, did not tried yet,
> but old usb stack works as expected, did all usb1 quircks imported to
> usb2 ?

Yes, all UMASS quirks should have been imported.

--HPS

From hselasky at c2i.net  Wed Feb  4 02:21:26 2009
From: hselasky at c2i.net (Hans Petter Selasky)
Date: Wed Feb  4 02:21:34 2009
Subject: USB2 - libusb20 vs devel/libusb
In-Reply-To: <1233741844.1767.133.camel@localhost>
References: <1233732660.1767.30.camel@localhost>
	<200902041049.27444.hselasky@c2i.net>
	<1233741844.1767.133.camel@localhost>
Message-ID: <200902041123.51301.hselasky@c2i.net>

On Wednesday 04 February 2009, Vladimir Grebenschikov wrote:
> On Wed, 2009-02-04 at 10:49 +0100, Hans Petter Selasky wrote:

Hi,

>
> Probably we may provide patch against devel/libusb to depend it on
> libusb20 ?

Yes. I don't know about such a patch yet, but this is something that needs to 
be done for -current .

> So devel/libusb will stay LGPLed but libusb20 will be BSD licensed ?

I think that is the case.

--HPS


From hselasky at c2i.net  Wed Feb  4 02:24:56 2009
From: hselasky at c2i.net (Hans Petter Selasky)
Date: Wed Feb  4 02:25:03 2009
Subject: USB2 - umass problem
In-Reply-To: <1233741482.1767.120.camel@localhost>
References: <1233734352.1767.55.camel@localhost>
	<200902041044.27663.hselasky@c2i.net>
	<1233741482.1767.120.camel@localhost>
Message-ID: <200902041127.20424.hselasky@c2i.net>

On Wednesday 04 February 2009, Vladimir Grebenschikov wrote:
> On Wed, 2009-02-04 at 10:44 +0100, Hans Petter Selasky wrote:
> > > By some reason devfs semantic was changed:
> > > Instead of /dev/cuaU0.[0-2] and /dev/ttyU0.[0-2], I've get
> > > /dev/cuaU[0-2] /dev/ttyU[0-2] and! /dev/cuau1 /dev/ttyu1
> > > What is reason for such change (additional port with lowercase 'u' and
> > > U[0-2] instead of more logical U0.[0-2]) ?
> >
> > It is because we are attaching drivers per interface instead of per
> > device. A new modem unit is allocated every time we find a modem, simply
> > put. If the modem has multiple instances in an interface,
> > /dev/cuaU0.[0...] will be created. Else /dev/cuaU... .
>
> What about /dev/cuau1 /dev/ttyu1 ?

TTYs follow the same naming convention like the cuaUxx .

If the modem has got one modem in each interface and three interfaces:

/dev/cuaU0 /dev/ttyU0
/dev/cuaU1 /dev/ttyU1
/dev/cuaU2 /dev/ttyU2

If the modem has got three modems in one interface:

/dev/cuaU0.0 /dev/ttyU0.0
/dev/cuaU0.1 /dev/ttyU0.1
/dev/cuaU0.2 /dev/ttyU0.2

How this is configured is decided by the USB device manufacturer.

--HPS
From bst2006 at dva.dyndns.org  Wed Feb  4 05:31:48 2009
From: bst2006 at dva.dyndns.org (Boris S.)
Date: Wed Feb  4 05:31:55 2009
Subject: GEOM and moving to CURRENT from 7.1
In-Reply-To: <6D9C4D7C-88BD-4345-B281-26915601F4BF@mac.com>
References: <FC3D3CF7-091B-4ECF-BE38-6C7751C20994@neville-neil.com>	<alpine.BSF.2.00.0901112002080.3696@ibyngvyr.purzvxnyf.bet>	<496D0364.2060505@psg.com>	<47d0403c0901131335h46e7b151p3768de9a3e2c2027@mail.gmail.com>	<EC370904A7B74B93887C79E120CA2835@adnote989>	<085BEE07-BAE5-4A45-A14D-9587987FAA5C@mac.com>	<496F44FA.1070004@andric.com>	<48C1C477-B7BE-43B0-AC57-9DEB7BF9AA88@mac.com>	<496F7347.4060007@andric.com>	<A8E47805-888E-4282-8623-72A65B593D47@mac.com>	<496F8D8A.1060508@andric.com>	<BC6ACB2A-CBC5-428B-8749-999B48B2D1C8@mac.com>	<496F928F.6010807@andric.com>	<DBB310AB-75BF-4BF7-AA35-63ADBD0B66B6@mac.com>	<496FE791.7000709@psg.com>
	<497A31F7.1070005@psg.com>
	<6D9C4D7C-88BD-4345-B281-26915601F4BF@mac.com>
Message-ID: <49899456.9050505@dva.dyndns.org>

Marcel Moolenaar wrote:
> Wipe out the second sector on the disk.

That didn't work for me. That ended with a not accessible partiton.
Luckily i backed up the first sectors of the disk.

In the end i backed up my data, wiped the disk and installed all 
partitions as GPT (i would move to GPT anyway).

After that i was able to move to 8-current.




From bst2006 at dva.dyndns.org  Wed Feb  4 05:43:01 2009
From: bst2006 at dva.dyndns.org (Boris S.)
Date: Wed Feb  4 05:43:10 2009
Subject: Can't install mpd5
Message-ID: <49899B63.4070703@dva.dyndns.org>


I can't install net/mpd5 as the dependency devel/libpdel is marked as 
broken due to the arp-v2 import.
Will that be fixed soon or is there a quick hack to get it compiled again?




From marius at nuenneri.ch  Wed Feb  4 06:23:41 2009
From: marius at nuenneri.ch (=?ISO-8859-1?Q?Marius_N=FCnnerich?=)
Date: Wed Feb  4 06:23:48 2009
Subject: GEOM_PART: a quick update on logical partitions
In-Reply-To: <gm9fh1$4el$1@ger.gmane.org>
References: <FCA8C5E4-BC41-4711-9EBC-CD692144F6B8@mac.com>
	<20090203082153.565746e2@zelda.local>
	<b649e5e0902030357k7508b4e7kc69c31a354b3e077@mail.gmail.com>
	<gm9fh1$4el$1@ger.gmane.org>
Message-ID: <b649e5e0902040623g2ff69efevda99db6818db345c@mail.gmail.com>

On Tue, Feb 3, 2009 at 2:06 PM, Ivan Voras <ivoras@freebsd.org> wrote:
> Marius N?nnerich wrote:
>
>> I'm not happy with the symlinks either. When someone is manipulating a
>> partition table she should be able to live with the consequences. I
>> would rather go for the UUID in UFS header approach if there is enough
>> room. BTW I implemented GPT UUID glabels a while ago please see:
>> http://www.freebsd.org/cgi/query-pr.cgi?pr=128398
>
> I have a patch for UFS "GUID" labels (not exactly GUIDs, but every UFS
> file system has a reasonably unique ID associated with it) but have
> encountered what seems a bug in GEOM slicers - two dev entries pointing
> to the same device don't work well with orphaning/tasting. Have you
> encountered something similar perhaps?

I haven't encountered strange behaviour there but I will test it again.
From jhb at freebsd.org  Wed Feb  4 06:26:35 2009
From: jhb at freebsd.org (John Baldwin)
Date: Wed Feb  4 06:26:42 2009
Subject: lpt stopped working
In-Reply-To: <200902021643.39862.c47g@gmx.at>
References: <200902021643.39862.c47g@gmx.at>
Message-ID: <200902040914.10330.jhb@freebsd.org>

On Monday 02 February 2009 10:43:39 am Christian Gusenbauer wrote:
> Hi!
> 
> Since the recent update (svn r187576) to the ppbus/ppc code my printer 
stopped 
> working. Every request seems to hang forever in ppb_request_bus waiting for 
> ppb->ppc_lock (at least 'top' tells me that it's hanging in state 'ppbreq').

Can you use procstat to get a stack trace of the hung thread?

-- 
John Baldwin
From jhb at freebsd.org  Wed Feb  4 06:26:41 2009
From: jhb at freebsd.org (John Baldwin)
Date: Wed Feb  4 06:26:50 2009
Subject: lpt stopped working
In-Reply-To: <4987157E.9080605@protected-networks.net>
References: <200902021643.39862.c47g@gmx.at>
	<4987157E.9080605@protected-networks.net>
Message-ID: <200902040919.10647.jhb@freebsd.org>

On Monday 02 February 2009 10:47:10 am Michael Butler wrote:
> Christian Gusenbauer wrote:
> > Since the recent update (svn r187576) to the ppbus/ppc code my printer 
stopped
> > working. Every request seems to hang forever in ppb_request_bus waiting 
for
> > ppb->ppc_lock (at least 'top' tells me that it's hanging in 
state 'ppbreq').
> >
> > Any clues?
> 
> Further to this: sane-backends and qemu now refuse to compile :-(

Can you check if the recent commit to ppbconf.h fixed this?

-- 
John Baldwin
From jhb at freebsd.org  Wed Feb  4 06:26:49 2009
From: jhb at freebsd.org (John Baldwin)
Date: Wed Feb  4 06:27:01 2009
Subject: USB2 - umass problem
In-Reply-To: <1233741482.1767.120.camel@localhost>
References: <1233734352.1767.55.camel@localhost>
	<200902041044.27663.hselasky@c2i.net>
	<1233741482.1767.120.camel@localhost>
Message-ID: <200902040922.16882.jhb@freebsd.org>

On Wednesday 04 February 2009 4:58:02 am Vladimir Grebenschikov wrote:
> On Wed, 2009-02-04 at 10:44 +0100, Hans Petter Selasky wrote:
> 
> > > By some reason devfs semantic was changed:
> > > Instead of /dev/cuaU0.[0-2] and /dev/ttyU0.[0-2], I've get
> > > /dev/cuaU[0-2] /dev/ttyU[0-2] and! /dev/cuau1 /dev/ttyu1
> > > What is reason for such change (additional port with lowercase 'u' and
> > > U[0-2] instead of more logical U0.[0-2]) ?
> > 
> > It is because we are attaching drivers per interface instead of per 
device. A 
> > new modem unit is allocated every time we find a modem, simply put. If the 
> > modem has multiple instances in an interface, /dev/cuaU0.[0...] will be 
> > created. Else /dev/cuaU... .
> 
> What about /dev/cuau1 /dev/ttyu1 ?

You have a uart1 device.

-- 
John Baldwin
From vova at fbsd.ru  Wed Feb  4 06:45:27 2009
From: vova at fbsd.ru (Vladimir Grebenschikov)
Date: Wed Feb  4 06:45:40 2009
Subject: USB2 - umass problem
In-Reply-To: <200902040922.16882.jhb@freebsd.org>
References: <1233734352.1767.55.camel@localhost>
	<200902041044.27663.hselasky@c2i.net>
	<1233741482.1767.120.camel@localhost>
	<200902040922.16882.jhb@freebsd.org>
Message-ID: <1233758721.1811.148.camel@localhost>

On Wed, 2009-02-04 at 09:22 -0500, John Baldwin wrote:
> On Wednesday 04 February 2009 4:58:02 am Vladimir Grebenschikov wrote:
> > On Wed, 2009-02-04 at 10:44 +0100, Hans Petter Selasky wrote:
> > 
> > > > By some reason devfs semantic was changed:
> > > > Instead of /dev/cuaU0.[0-2] and /dev/ttyU0.[0-2], I've get
> > > > /dev/cuaU[0-2] /dev/ttyU[0-2] and! /dev/cuau1 /dev/ttyu1
> > > > What is reason for such change (additional port with lowercase 'u' and
> > > > U[0-2] instead of more logical U0.[0-2]) ?
> > > 
> > > It is because we are attaching drivers per interface instead of per 
> device. A 
> > > new modem unit is allocated every time we find a modem, simply put. If the 
> > > modem has multiple instances in an interface, /dev/cuaU0.[0...] will be 
> > > created. Else /dev/cuaU... .
> > 
> > What about /dev/cuau1 /dev/ttyu1 ?
> 
> You have a uart1 device.

Ahh, ok, now I understand, thanks.

-- 
Vladimir B. Grebenschikov
vova@fbsd.ru
From christoph.mallon at gmx.de  Wed Feb  4 06:54:44 2009
From: christoph.mallon at gmx.de (Christoph Mallon)
Date: Wed Feb  4 06:55:01 2009
Subject: write-only variables in src/sys/ - possible bugs
In-Reply-To: <20090203231155.GA69101@jnz.sqrt.ca>
References: <49874CA8.5090605@gmx.de> <20090203231155.GA69101@jnz.sqrt.ca>
Message-ID: <4989AC31.6000904@gmx.de>

Christian Peron schrieb:
> I started following up on this and ran into an issue for these:
> 
> sys/net/bpf_buffer.c:133: warning: variable 'dst' is never read
> sys/net/bpf_buffer.c:134: warning: variable 'count' is never read
> sys/net/bpf_buffer.c:142: warning: variable 'dst' is never read
> 
> 
> /*
>  * Scatter-gather data copy from an mbuf chain to the current kernel buffer.
>  */
> void
> bpf_buffer_append_mbuf(struct bpf_d *d, caddr_t buf, u_int offset, void *src,
>     u_int len)
> {
>         const struct mbuf *m;
>         u_char *dst;
>         u_int count;
>  
>         m = (struct mbuf *)src;
>         dst = (u_char *)buf + offset;
>         while (len > 0) {
>                 if (m == NULL)
>                         panic("bpf_mcopy");
>                 count = min(m->m_len, len);
>                 bcopy(mtod(m, void *), dst, count);
>                 m = m->m_next;
> [..]
> 
> Does it not consider being passed as an argument to a function as
> being read?

Yes, function arguments are considered being read. The problem is 
different here: mtod() should be a macro, but the macro declaration was 
missing (*cough* hacked build process *cough*). So the parser tried to 
parse this as function call. Then it hit the "void *", which confused it 
- it got a type while parsing an expression. I improved the error 
correction, resolved a few other problems, too, and generated a new list:

http://tron.homeunix.org/unread_variables.log
(The list has a date at the top, if it is missing, you see the old list 
in your browser cache)

The false positives, which you mentioned, are gone now - thanks for 
reporting this. The list now contains about 1.000 entries and about 60 
concern variables named 'error'.
From bms at FreeBSD.org  Wed Feb  4 06:55:10 2009
From: bms at FreeBSD.org (Bruce M. Simpson)
Date: Wed Feb  4 06:55:18 2009
Subject: lpt stopped working
In-Reply-To: <200902021307.56403.beech@freebsd.org>
References: <200902021643.39862.c47g@gmx.at>
	<200902021307.56403.beech@freebsd.org>
Message-ID: <4989AC4A.3010802@FreeBSD.org>

Beech Rintoul wrote:
>> Since the recent update (svn r187576) to the ppbus/ppc code my printer
>> stopped working. Every request seems to hang forever in ppb_request_bus
>> waiting for ppb->ppc_lock (at least 'top' tells me that it's hanging in
>> state 'ppbreq').
>>     
> I wonder if this is the same issue I reported on questions that lpt0 now just 
> reports "device busy"?
>   

FYI: I saw very similar issues to this with lpt0 in the backport of this 
patch to 7-STABLE, please see summary elsewhere on lists from last ~2 weeks.

cheers,
BMS
From freebsd at abv.bg  Wed Feb  4 07:04:18 2009
From: freebsd at abv.bg (Mario Pavlov)
Date: Wed Feb  4 07:04:26 2009
Subject: Can't install mpd5
Message-ID: <1440699871.39087.1233759856450.JavaMail.apache@mail54.abv.bg>

Hi,
you could just do

# pkg_add -r libpdel

and then install net/mpd5

good luck

Regards,
MGP


 >I can't install net/mpd5 as the dependency devel/libpdel is marked as 
 >broken due to the arp-v2 import.
 >Will that be fixed soon or is there a quick hack to get it compiled again?
 >
 >
 >
 >
 >_______________________________________________
 >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 freebsd at abv.bg  Wed Feb  4 07:22:26 2009
From: freebsd at abv.bg (Mario Pavlov)
Date: Wed Feb  4 07:22:33 2009
Subject: Can't install mpd5
Message-ID: <1440699871.39087.1233759856450.JavaMail.apache@mail54.abv.bg>

Hi,
you could just do

# pkg_add -r libpdel

and then install net/mpd5

good luck

Regards,
MGP


 >I can't install net/mpd5 as the dependency devel/libpdel is marked as 
 >broken due to the arp-v2 import.
 >Will that be fixed soon or is there a quick hack to get it compiled again?
 >
 >
 >
 >
 >_______________________________________________
 >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 ivoras at freebsd.org  Wed Feb  4 07:29:21 2009
From: ivoras at freebsd.org (Ivan Voras)
Date: Wed Feb  4 07:29:29 2009
Subject: GEOM_PART: a quick update on logical partitions
In-Reply-To: <b649e5e0902040623g2ff69efevda99db6818db345c@mail.gmail.com>
References: <FCA8C5E4-BC41-4711-9EBC-CD692144F6B8@mac.com>	<20090203082153.565746e2@zelda.local>	<b649e5e0902030357k7508b4e7kc69c31a354b3e077@mail.gmail.com>	<gm9fh1$4el$1@ger.gmane.org>
	<b649e5e0902040623g2ff69efevda99db6818db345c@mail.gmail.com>
Message-ID: <gmcc86$1o0$1@ger.gmane.org>

Marius N?nnerich wrote:
> On Tue, Feb 3, 2009 at 2:06 PM, Ivan Voras <ivoras@freebsd.org> wrote:
>> Marius N?nnerich wrote:
>>
>>> I'm not happy with the symlinks either. When someone is manipulating a
>>> partition table she should be able to live with the consequences. I
>>> would rather go for the UUID in UFS header approach if there is enough
>>> room. BTW I implemented GPT UUID glabels a while ago please see:
>>> http://www.freebsd.org/cgi/query-pr.cgi?pr=128398
>> I have a patch for UFS "GUID" labels (not exactly GUIDs, but every UFS
>> file system has a reasonably unique ID associated with it) but have
>> encountered what seems a bug in GEOM slicers - two dev entries pointing
>> to the same device don't work well with orphaning/tasting. Have you
>> encountered something similar perhaps?
> 
> I haven't encountered strange behaviour there but I will test it again.

I've read the code in the referenced PR and I see you've taken a
different way to implement it than I did, but the problem might still be
present; try the following sequence of operations:

* create a geom (GPT slice in your case) that has two /dev entries on it
- one from the GPT label and one from GPT GUID
* mount one of those /dev entries (i.e. open it for exclusive access) -
the other one should disappear
* unmount it
* see if the labels are correctly created (tasted) again.
* repeat with the base device (on which GPT is created) - both labels
should be spoiled and detected again

If you see what I'm seeing (labels not correctly tasted) then it could
be a problem. If not, it's my problem :)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 252 bytes
Desc: OpenPGP digital signature
Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20090204/fba88ee3/signature.pgp
From ttw+bsd at cobbled.net  Wed Feb  4 07:48:30 2009
From: ttw+bsd at cobbled.net (ttw+bsd@cobbled.net)
Date: Wed Feb  4 07:48:37 2009
Subject: MK_CDDL cause user build to fail
Message-ID: <20090204154827.GB11244@holyman.cobbled.net>

trying to build as a user utilising the MAKEOBJDIRPREFIX environment
causes 'buildworld' to fail somewhere in the CDDL code (looks like
it's in the dtrace stuff).
From imp at bsdimp.com  Wed Feb  4 07:59:52 2009
From: imp at bsdimp.com (M. Warner Losh)
Date: Wed Feb  4 08:00:04 2009
Subject: USB2 - umass problem
In-Reply-To: <200902041044.27663.hselasky@c2i.net>
References: <1233734352.1767.55.camel@localhost>
	<200902041044.27663.hselasky@c2i.net>
Message-ID: <20090204.085606.1630229139.imp@bsdimp.com>

In message: <200902041044.27663.hselasky@c2i.net>
            Hans Petter Selasky <hselasky@c2i.net> writes:
: Hi,
: 
: On Wednesday 04 February 2009, Vladimir Grebenschikov wrote:
: >  Hi
: >
: >
: > By some reason devfs semantic was changed:
: > Instead of /dev/cuaU0.[0-2] and /dev/ttyU0.[0-2], I've get
: > /dev/cuaU[0-2] /dev/ttyU[0-2] and! /dev/cuau1 /dev/ttyu1
: > What is reason for such change (additional port with lowercase 'u' and
: > U[0-2] instead of more logical U0.[0-2]) ?
: 
: It is because we are attaching drivers per interface instead of per device. A 
: new modem unit is allocated every time we find a modem, simply put. If the 
: modem has multiple instances in an interface, /dev/cuaU0.[0...] will be 
: created. Else /dev/cuaU... .

Generally, we try not to change the details of how a device attaches
/dev entries from release to release.  Why the change?

Also to Vladimir, Are you sure that the 'u' devices are created with
the USB modem?  They should only be created for uart devices...

Warner
From hselasky at c2i.net  Wed Feb  4 08:31:01 2009
From: hselasky at c2i.net (Hans Petter Selasky)
Date: Wed Feb  4 08:31:07 2009
Subject: [was: USB2 - umass problem] U3G modem unit number changes
In-Reply-To: <20090204.085606.1630229139.imp@bsdimp.com>
References: <1233734352.1767.55.camel@localhost>
	<200902041044.27663.hselasky@c2i.net>
	<20090204.085606.1630229139.imp@bsdimp.com>
Message-ID: <200902041733.23389.hselasky@c2i.net>

Hi,

On Wednesday 04 February 2009, M. Warner Losh wrote:

> Why the change? 

Because u3g2.c is attaching to an USB interface and not the whole USB device. 
This is to allow other drivers to hook on the other interfaces.

If you want to have exactly the same numbering like before, then the U3G 
interface driver instances on the same USB device need to peek at eachother 
to figure out the correct unit and sub-unit number.

>
> Also to Vladimir, Are you sure that the 'u' devices are created with
> the USB modem?  They should only be created for uart devices...

--HPS
From thompsa at FreeBSD.org  Wed Feb  4 08:43:12 2009
From: thompsa at FreeBSD.org (Andrew Thompson)
Date: Wed Feb  4 08:43:18 2009
Subject: [was: USB2 - umass problem] U3G modem unit number changes
In-Reply-To: <200902041733.23389.hselasky@c2i.net>
References: <1233734352.1767.55.camel@localhost>
	<200902041044.27663.hselasky@c2i.net>
	<20090204.085606.1630229139.imp@bsdimp.com>
	<200902041733.23389.hselasky@c2i.net>
Message-ID: <20090204164305.GA77912@citylink.fud.org.nz>

On Wed, Feb 04, 2009 at 05:33:22PM +0100, Hans Petter Selasky wrote:
> Hi,
> 
> On Wednesday 04 February 2009, M. Warner Losh wrote:
> 
> > Why the change? 
> 
> Because u3g2.c is attaching to an USB interface and not the whole USB device. 
> This is to allow other drivers to hook on the other interfaces.

u3g2 should claim the other interfaces in the one attachment and use the
same tty semantics as oldusb u3g.


Andrew
From imb at protected-networks.net  Wed Feb  4 09:20:09 2009
From: imb at protected-networks.net (Michael Butler)
Date: Wed Feb  4 09:20:16 2009
Subject: lpt stopped working
In-Reply-To: <200902040919.10647.jhb@freebsd.org>
References: <200902021643.39862.c47g@gmx.at>
	<4987157E.9080605@protected-networks.net>
	<200902040919.10647.jhb@freebsd.org>
Message-ID: <4989CE44.7010209@protected-networks.net>

John Baldwin wrote:
> On Monday 02 February 2009 10:47:10 am Michael Butler wrote:

>> Further to this: sane-backends and qemu now refuse to compile :-(

> Can you check if the recent commit to ppbconf.h fixed this?

sane-backends and qemu[-devel] all now compile.

kqemu[-devel] compiles but fails when attempting to kldload it with:

	kernel: link_elf: symbol unit2minor undefined

 .. which is a different issue and seems to need a similar patch to that
applied to fuse-kmod for -current since unit2minor has 'gone away',

	Michael

From hselasky at c2i.net  Wed Feb  4 09:30:14 2009
From: hselasky at c2i.net (Hans Petter Selasky)
Date: Wed Feb  4 09:30:21 2009
Subject: [was: USB2 - umass problem] U3G modem unit number changes
In-Reply-To: <200902041733.23389.hselasky@c2i.net>
References: <1233734352.1767.55.camel@localhost>
	<20090204.085606.1630229139.imp@bsdimp.com>
	<200902041733.23389.hselasky@c2i.net>
Message-ID: <200902041832.36833.hselasky@c2i.net>

Hi Vladimir,

You can try the following patch if you want:

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

You probably need to apply by hand, but if you can wait a couple of days, this 
will be in -current .

--HPS
From imb at protected-networks.net  Wed Feb  4 10:04:50 2009
From: imb at protected-networks.net (Michael Butler)
Date: Wed Feb  4 10:04:57 2009
Subject: lpt stopped working
In-Reply-To: <4989CE44.7010209@protected-networks.net>
References: <200902021643.39862.c47g@gmx.at>	<4987157E.9080605@protected-networks.net>	<200902040919.10647.jhb@freebsd.org>
	<4989CE44.7010209@protected-networks.net>
Message-ID: <4989D8BF.6010301@protected-networks.net>

I wrote:
> kqemu[-devel] compiles but fails when attempting to kldload it with:
> 
> 	kernel: link_elf: symbol unit2minor undefined
> 
>  .. which is a different issue and seems to need a similar patch to that
> applied to fuse-kmod for -current since unit2minor has 'gone away',

Something trivial like this seems to make it load and run again ..

*** kqemu-freebsd.c~    Wed Feb  4 12:34:54 2009
--- kqemu-freebsd.c     Wed Feb  4 12:36:09 2009
***************
*** 381,387 ****

      r = clone_create(&kqemuclones, &kqemu_cdevsw, &unit, dev, 0);
      if (r) {
!       *dev = make_dev(&kqemu_cdevsw, unit2minor(unit),
            UID_ROOT, GID_WHEEL, 0660, "kqemu%d", unit);
        if (*dev != NULL) {
            dev_ref(*dev);
--- 381,392 ----

      r = clone_create(&kqemuclones, &kqemu_cdevsw, &unit, dev, 0);
      if (r) {
!       *dev = make_dev(&kqemu_cdevsw,
! #if __FreeBSD_version < 800062
!             unit2minor(unit),
! #else /* __FreeBSD_version >= 800062 */
!             unit,
! #endif /* __FreeBSD_version < 800062 */
            UID_ROOT, GID_WHEEL, 0660, "kqemu%d", unit);
        if (*dev != NULL) {
            dev_ref(*dev);

	Michael
From csjp at freebsd.org  Wed Feb  4 10:27:18 2009
From: csjp at freebsd.org (Christian Peron)
Date: Wed Feb  4 10:27:26 2009
Subject: write-only variables in src/sys/ - possible bugs
In-Reply-To: <4989AC31.6000904@gmx.de>
References: <49874CA8.5090605@gmx.de> <20090203231155.GA69101@jnz.sqrt.ca>
	<4989AC31.6000904@gmx.de>
Message-ID: <20090204182715.GA75911@jnz.sqrt.ca>

On Wed, Feb 04, 2009 at 03:54:41PM +0100, Christoph Mallon wrote:
[..]
> 
> Yes, function arguments are considered being read. The problem is 
> different here: mtod() should be a macro, but the macro declaration was 
> missing (*cough* hacked build process *cough*). So the parser tried to 
> parse this as function call. Then it hit the "void *", which confused it 
> - it got a type while parsing an expression. I improved the error 
> correction, resolved a few other problems, too, and generated a new list:
> 
> http://tron.homeunix.org/unread_variables.log
> (The list has a date at the top, if it is missing, you see the old list 
> in your browser cache)
> 
> The false positives, which you mentioned, are gone now - thanks for 
> reporting this. The list now contains about 1.000 entries and about 60 
> concern variables named 'error'.

Also.. one other thing I noticed:

void
bpf_buffer_append_mbuf(struct bpf_d *d, caddr_t buf, u_int offset, void *src,
    u_int len)
{               
        const struct mbuf *m;
        u_char *dst;
        u_int count;
                
        m = (struct mbuf *)src;
        dst = (u_char *)buf + offset;
        while (len > 0) {
                if (m == NULL)
                        panic("bpf_mcopy");
                count = min(m->m_len, len);
                bcopy(mtod(m, void *), dst, count);
                m = m->m_next;
                dst += count;
                len -= count;
        }
}

  dst += count

In this expression, both dst and count are read since this is the
same thing as:

  dst = dst + count;
From christoph.mallon at gmx.de  Wed Feb  4 10:36:35 2009
From: christoph.mallon at gmx.de (Christoph Mallon)
Date: Wed Feb  4 10:36:43 2009
Subject: write-only variables in src/sys/ - possible bugs
In-Reply-To: <20090204182715.GA75911@jnz.sqrt.ca>
References: <49874CA8.5090605@gmx.de> <20090203231155.GA69101@jnz.sqrt.ca>
	<4989AC31.6000904@gmx.de> <20090204182715.GA75911@jnz.sqrt.ca>
Message-ID: <4989E030.20609@gmx.de>

Christian Peron schrieb:
> On Wed, Feb 04, 2009 at 03:54:41PM +0100, Christoph Mallon wrote:
> [..]
>> Yes, function arguments are considered being read. The problem is 
>> different here: mtod() should be a macro, but the macro declaration was 
>> missing (*cough* hacked build process *cough*). So the parser tried to 
>> parse this as function call. Then it hit the "void *", which confused it 
>> - it got a type while parsing an expression. I improved the error 
>> correction, resolved a few other problems, too, and generated a new list:
>>
>> http://tron.homeunix.org/unread_variables.log
>> (The list has a date at the top, if it is missing, you see the old list 
>> in your browser cache)
>>
>> The false positives, which you mentioned, are gone now - thanks for 
>> reporting this. The list now contains about 1.000 entries and about 60 
>> concern variables named 'error'.
> 
> Also.. one other thing I noticed:
> 
> void
> bpf_buffer_append_mbuf(struct bpf_d *d, caddr_t buf, u_int offset, void *src,
>     u_int len)
> {               
>         const struct mbuf *m;
>         u_char *dst;
>         u_int count;
>                 
>         m = (struct mbuf *)src;
>         dst = (u_char *)buf + offset;
>         while (len > 0) {
>                 if (m == NULL)
>                         panic("bpf_mcopy");
>                 count = min(m->m_len, len);
>                 bcopy(mtod(m, void *), dst, count);
>                 m = m->m_next;
>                 dst += count;
>                 len -= count;
>         }
> }
> 
>   dst += count
> 
> In this expression, both dst and count are read since this is the
> same thing as:
> 
>   dst = dst + count;

No, the analysis *explicitly* marks "x" in neither "x += 1" nor "x = x + 
1" as read. The value of the variable in these expressions is only read 
to calculate its own new value. Therefore it will complain about

int x = 23;
x++;
x += 1;
x = x + 1;
return 0;

This is not a bug, it is a feature. (:
The problem here solely was the insufficient error recovery in the 
bcopy() line, which caused the only "real" user of "dst" to disappear. I 
corrected this problem and as you can see the false positives are no 
longer on the list.
From atkin901 at yahoo.com  Wed Feb  4 10:59:00 2009
From: atkin901 at yahoo.com (Mark Atkinson)
Date: Wed Feb  4 10:59:08 2009
Subject: problems dropping to single user from multi in recent -current?
Message-ID: <gmcoh8$fmc$1@ger.gmane.org>

I've updated several boxes over the last few days -- these are all
serial console units; and everytime I issue 'shutdown now' to 
drop to single user, it hangs at the pathname prompt.  Is anyone 
else seeing this?

example:
# shutdown now
Shutdown NOW!
shutdown: [pid 1021]
*** FINAL System shutdown message from root@dl385g5.pdsea.f5net.com ***
System going down IMMEDIATELY


Feb  4 10:34:48 <auth.notice> dl385g5 shutdown: shutdown by root:

System shutdown time has arrived
Stopping inetd.
Stopping cron.
Stopping sshd.
Waiting for PIDS: 913.
Stopping ntpd.
Waiting for PIDS: 877.
Stopping devd.
Writing entropy file:.
.
Feb  4 10:34:55 <syslog.err> dl385g5 syslogd: exiting on signal 15
Enter full pathname of shell or RETURN for /bin/sh: 


From avg at icyb.net.ua  Wed Feb  4 11:31:09 2009
From: avg at icyb.net.ua (Andriy Gapon)
Date: Wed Feb  4 11:31:17 2009
Subject: kobj methods (DEVMETHOD) that have differing signatures (in src/sys)
Message-ID: <4989E87B.5010000@icyb.net.ua>


This based on the (much) earlier proposal described here:
http://lists.freebsd.org/pipermail/freebsd-arch/2008-April/007982.html

The patch was applied to the recent current sources and LINT kernels for
all architectures that have LINT/NOTES (i.e. arm excluded) were built.

Here's a link to the list of files and line numbers where KOBJ methods
are set with functions that have differing signatures:
http://www.icyb.net.ua/~avg/kobj_method_sigs.txt

List of the most common issues can be found at the first link.

Hope this is useful.

-- 
Andriy Gapon
From imp at bsdimp.com  Wed Feb  4 12:12:31 2009
From: imp at bsdimp.com (M. Warner Losh)
Date: Wed Feb  4 12:12:38 2009
Subject: kobj methods (DEVMETHOD) that have differing signatures (in
 src/sys)
In-Reply-To: <4989E87B.5010000@icyb.net.ua>
References: <4989E87B.5010000@icyb.net.ua>
Message-ID: <20090204.131104.2064955776.imp@bsdimp.com>

In message: <4989E87B.5010000@icyb.net.ua>
            Andriy Gapon <avg@icyb.net.ua> writes:
: 
: This based on the (much) earlier proposal described here:
: http://lists.freebsd.org/pipermail/freebsd-arch/2008-April/007982.html
: 
: The patch was applied to the recent current sources and LINT kernels for
: all architectures that have LINT/NOTES (i.e. arm excluded) were built.
: 
: Here's a link to the list of files and line numbers where KOBJ methods
: are set with functions that have differing signatures:
: http://www.icyb.net.ua/~avg/kobj_method_sigs.txt
: 
: List of the most common issues can be found at the first link.
: 
: Hope this is useful.

This is very helpful.  I'll work through the low-hanging fruit.  If
others want to work as well, please ping me.

Warner
From sepotvin at FreeBSD.org  Wed Feb  4 12:34:20 2009
From: sepotvin at FreeBSD.org (Stephane E. Potvin)
Date: Wed Feb  4 12:34:52 2009
Subject: problems dropping to single user from multi in recent -current?
In-Reply-To: <gmcoh8$fmc$1@ger.gmane.org>
References: <gmcoh8$fmc$1@ger.gmane.org>
Message-ID: <4989EDB9.3010808@FreeBSD.org>

Mark Atkinson wrote:
> I've updated several boxes over the last few days -- these are all
> serial console units; and everytime I issue 'shutdown now' to 
> drop to single user, it hangs at the pathname prompt.  Is anyone 
> else seeing this?
> 
> example:
> # shutdown now
> Shutdown NOW!
> shutdown: [pid 1021]
> *** FINAL System shutdown message from root@dl385g5.pdsea.f5net.com ***
> System going down IMMEDIATELY
> 
> 
> Feb  4 10:34:48 <auth.notice> dl385g5 shutdown: shutdown by root:
> 
> System shutdown time has arrived
> Stopping inetd.
> Stopping cron.
> Stopping sshd.
> Waiting for PIDS: 913.
> Stopping ntpd.
> Waiting for PIDS: 877.
> Stopping devd.
> Writing entropy file:.
> .
> Feb  4 10:34:55 <syslog.err> dl385g5 syslogd: exiting on signal 15
> Enter full pathname of shell or RETURN for /bin/sh: 

Try typing blind... I have the same symptoms on one of my systems when I 
drop to single user mode (it's the only one with a USB keyboard, dunno 
if it's coincidence or not). keypresses are not echoed anymore but 
command output is. Going back multi-user fix the console. I've not had 
time yet to track it down.

Steph
From nakal at web.de  Wed Feb  4 12:53:50 2009
From: nakal at web.de (Martin)
Date: Wed Feb  4 12:55:12 2009
Subject: GEOM_PART: a quick update on logical partitions
In-Reply-To: <9D6C9DA2-7BBB-42C6-9F3E-4B8EF2078969@mac.com>
References: <FCA8C5E4-BC41-4711-9EBC-CD692144F6B8@mac.com>
	<20090203082153.565746e2@zelda.local>
	<D35C93DE-CB3F-4631-AC38-4CCCE3877C23@mac.com>
	<20090204004534.11ccca19@zelda.local>
	<EF0E3768-DF76-4AF5-9CDF-646DF44E69B3@mac.com>
	<20090204082718.0f217b1a@zelda.local>
	<9D6C9DA2-7BBB-42C6-9F3E-4B8EF2078969@mac.com>
Message-ID: <20090204215350.0bc7a307@zelda.local>

Am Wed, 04 Feb 2009 00:06:13 -0800
schrieb Marcel Moolenaar <xcllnt@mac.com>:

> Please read:
> 	http://en.wikipedia.org/wiki/Extended_partition
> 
> and then explain what you mean.
> 
> > /dev/ad0s1.2
> 
> No, you have 0.
> 
> > now you can insert 0 again and you get:
> >
> > /dev/ad0s1.0
> > /dev/ad0s1.2
> 
> You'll have 0 and 1.

I see your point. This works different from what I thought. Sorry for
the confusion. The wikipedia article made it clear to me.

--
Martin
From shuvaev at physik.uni-wuerzburg.de  Wed Feb  4 13:07:02 2009
From: shuvaev at physik.uni-wuerzburg.de (Alexey Shuvaev)
Date: Wed Feb  4 13:07:09 2009
Subject: GEOM_PART: a quick update on logical partitions
In-Reply-To: <20090204215350.0bc7a307@zelda.local>
References: <FCA8C5E4-BC41-4711-9EBC-CD692144F6B8@mac.com>
	<20090203082153.565746e2@zelda.local>
	<D35C93DE-CB3F-4631-AC38-4CCCE3877C23@mac.com>
	<20090204004534.11ccca19@zelda.local>
	<EF0E3768-DF76-4AF5-9CDF-646DF44E69B3@mac.com>
	<20090204082718.0f217b1a@zelda.local>
	<9D6C9DA2-7BBB-42C6-9F3E-4B8EF2078969@mac.com>
	<20090204215350.0bc7a307@zelda.local>
Message-ID: <20090204210700.GA44684@wep4035.physik.uni-wuerzburg.de>

On Wed, Feb 04, 2009 at 09:53:50PM +0100, Martin wrote:
> Am Wed, 04 Feb 2009 00:06:13 -0800
> schrieb Marcel Moolenaar <xcllnt@mac.com>:
> 
> > Please read:
> > 	http://en.wikipedia.org/wiki/Extended_partition
> > 
> > and then explain what you mean.
> > 
> > > /dev/ad0s1.2
> > 
> > No, you have 0.
> > 
> > > now you can insert 0 again and you get:
> > >
> > > /dev/ad0s1.0
> > > /dev/ad0s1.2
> > 
> > You'll have 0 and 1.
> 
> I see your point. This works different from what I thought. Sorry for
> the confusion. The wikipedia article made it clear to me.
> 
Just curious how important is it to support this extended partitioning
scheme? Why could not gpt be used instead?
I am using it quite happy for some time (this is amd64 CURRENT):

~> geom part show
=>       34  976773101  ad6  GPT  (466G)
         34    1571840    1  freebsd-ufs  (768M)
    1571874    8388608    2  freebsd-swap  (4.0G)
    9960482       1024    3  freebsd-boot  (512K)
    9961506    8388608    4  freebsd-ufs  (4.0G)
   18350114     524288    5  freebsd-ufs  (256M)
   18874402  134217728    6  freebsd-ufs  (64G)
  153092130   33554432    7  freebsd-ufs  (16G)
  186646562   33554432    8  freebsd-ufs  (16G)
  220200994  756572141       - free -  (361G)

Alexey.
From atkin901 at yahoo.com  Wed Feb  4 13:08:05 2009
From: atkin901 at yahoo.com (Mark Atkinson)
Date: Wed Feb  4 13:08:12 2009
Subject: problems dropping to single user from multi in recent -current?
References: <gmcoh8$fmc$1@ger.gmane.org> <4989EDB9.3010808@FreeBSD.org>
Message-ID: <gmd034$bno$1@ger.gmane.org>

Stephane E. Potvin wrote:

> Mark Atkinson wrote:
>> I've updated several boxes over the last few days -- these are all
>> serial console units; and everytime I issue 'shutdown now' to
>> drop to single user, it hangs at the pathname prompt.  Is anyone
>> else seeing this?
 
> Try typing blind... I have the same symptoms on one of my systems when I
> drop to single user mode (it's the only one with a USB keyboard, dunno
> if it's coincidence or not). keypresses are not echoed anymore but
> command output is. Going back multi-user fix the console. I've not had
> time yet to track it down.

Thanks, I tried this on a box, but it doesn't seem to work.

(blindly typing '<enter>', then wait and then 'exit')

booting to single user works fine from the loader.

The kernel is still 'up' since it responds to icmp, but without any
console output, it's hard to say what state it's in.

-- 
Mark Atkinson
atkin901@yahoo.com
(!wired)?(coffee++):(wired);

From trebestie at gmail.com  Wed Feb  4 13:29:48 2009
From: trebestie at gmail.com (Diego Depaoli)
Date: Wed Feb  4 13:29:56 2009
Subject: problems dropping to single user from multi in recent -current?
In-Reply-To: <4989EDB9.3010808@FreeBSD.org>
References: <gmcoh8$fmc$1@ger.gmane.org> <4989EDB9.3010808@FreeBSD.org>
Message-ID: <83e5fb980902041300k324cef73od2cf2a9b5ec553d5@mail.gmail.com>

On Wed, Feb 4, 2009 at 8:34 PM, Stephane E. Potvin <sepotvin@freebsd.org> wrote:
> Mark Atkinson wrote:
>>
>> I've updated several boxes over the last few days -- these are all
>> serial console units; and everytime I issue 'shutdown now' to drop to
>> single user, it hangs at the pathname prompt.  Is anyone else seeing this?
Same here
>
> Try typing blind... I have the same symptoms on one of my systems when I
> drop to single user mode (it's the only one with a USB keyboard, dunno if
> it's coincidence or not).
It's a coincidence, I do not have USB keyboard

Regards

-- 
Diego Depaoli
From vova at fbsd.ru  Wed Feb  4 14:32:10 2009
From: vova at fbsd.ru (Vladimir Grebenschikov)
Date: Wed Feb  4 14:32:17 2009
Subject: USB2 - umass problem
In-Reply-To: <20090204.085606.1630229139.imp@bsdimp.com>
References: <1233734352.1767.55.camel@localhost>
	<200902041044.27663.hselasky@c2i.net>
	<20090204.085606.1630229139.imp@bsdimp.com>
Message-ID: <1233786661.2821.5.camel@localhost>

On Wed, 2009-02-04 at 08:56 -0700, M. Warner Losh wrote:
> In message: <200902041044.27663.hselasky@c2i.net>
>             Hans Petter Selasky <hselasky@c2i.net> writes:
> : Hi,
> : 
> : On Wednesday 04 February 2009, Vladimir Grebenschikov wrote:
> : >  Hi
> : >
> : >
> : > By some reason devfs semantic was changed:
> : > Instead of /dev/cuaU0.[0-2] and /dev/ttyU0.[0-2], I've get
> : > /dev/cuaU[0-2] /dev/ttyU[0-2] and! /dev/cuau1 /dev/ttyu1
> : > What is reason for such change (additional port with lowercase 'u' and
> : > U[0-2] instead of more logical U0.[0-2]) ?
> : 
> : It is because we are attaching drivers per interface instead of per device. A 
> : new modem unit is allocated every time we find a modem, simply put. If the 
> : modem has multiple instances in an interface, /dev/cuaU0.[0...] will be 
> : created. Else /dev/cuaU... .
> 
> Generally, we try not to change the details of how a device attaches
> /dev entries from release to release.  Why the change?
> 
> Also to Vladimir, Are you sure that the 'u' devices are created with
> the USB modem?  They should only be created for uart devices...

Yes, it is uart.

> Warner
-- 
Vladimir B. Grebenschikov
vova@fbsd.ru
From trebestie at gmail.com  Wed Feb  4 15:40:17 2009
From: trebestie at gmail.com (Diego Depaoli)
Date: Wed Feb  4 15:40:24 2009
Subject: problems dropping to single user from multi in recent -current?
In-Reply-To: <gmd034$bno$1@ger.gmane.org>
References: <gmcoh8$fmc$1@ger.gmane.org> <4989EDB9.3010808@FreeBSD.org>
	<gmd034$bno$1@ger.gmane.org>
Message-ID: <83e5fb980902041540vef87a92p825f25ac23b04dd@mail.gmail.com>

On Wed, Feb 4, 2009 at 10:07 PM, Mark Atkinson <atkin901@yahoo.com> wrote:
> Thanks, I tried this on a box, but it doesn't seem to work.
>
> (blindly typing '<enter>', then wait and then 'exit')
try ctrl+enter

-- 
Diego Depaoli
From atkin901 at yahoo.com  Wed Feb  4 16:19:38 2009
From: atkin901 at yahoo.com (Mark Atkinson)
Date: Wed Feb  4 16:19:45 2009
Subject: problems dropping to single user from multi in recent -current?
References: <gmcoh8$fmc$1@ger.gmane.org> <4989EDB9.3010808@FreeBSD.org>
	<gmd034$bno$1@ger.gmane.org>
	<83e5fb980902041540vef87a92p825f25ac23b04dd@mail.gmail.com>
Message-ID: <gmdbai$gee$1@ger.gmane.org>

Diego Depaoli wrote:

> On Wed, Feb 4, 2009 at 10:07 PM, Mark Atkinson <atkin901@yahoo.com> wrote:
>> Thanks, I tried this on a box, but it doesn't seem to work.
>>
>> (blindly typing '<enter>', then wait and then 'exit')
> try ctrl+enter
> 

well that got me to a prompt, but I can't type anything,  even 'exit', then
ctrl+enter



 for single user: No such file or directory
#


-- 
Mark Atkinson
atkin901@yahoo.com
(!wired)?(coffee++):(wired);

From pyunyh at gmail.com  Wed Feb  4 17:05:11 2009
From: pyunyh at gmail.com (Pyun YongHyeon)
Date: Wed Feb  4 17:05:17 2009
Subject: CFT: txp(4) new firmware image
Message-ID: <20090205010613.GA77461@michelle.cdnetworks.co.kr>


Hi,

It seems that 3CR990 controller with latest NV firmware 03.001.008
does not work with txp(4)(I accidently flashed 3CR990 controller
with latest NVfirmware). I guess latest NVfirmware does not like
runtime image in txp(4). Latest runtime image from 3Com seemed to
fix the issue to me. I'd like to know whether controllers with old
NVfrimware can work with the following patch.

http://people.freebsd.org/~yongari/txp/txp.firmware.diff.gz

If you're txp(4) user or suffering from firmware loading issue
please give it try and let me know.

P.S. I know txp(4) requires a lot of fixes for bus_dma(9) and
    endianness as well as TSO/WOL support. That will be handled in
    near future.
From imb at protected-networks.net  Wed Feb  4 17:35:50 2009
From: imb at protected-networks.net (Michael Butler)
Date: Wed Feb  4 17:35:56 2009
Subject: Silicon Labs bridge on USB2?
Message-ID: <498A426F.6030502@protected-networks.net>

I have a GPS receiver which uses a USB->serial bridge. At present, I can
use it with the uslcom driver but I don't see a USB-2 equivalent - is
this supported?

dmesg offers:

ucom0: <Silicon Labs CP2102 USB to UART Bridge Controller, class 0/0,
rev 1.10/1.00, addr 3> on uhub2

	Michael
From thompsa at FreeBSD.org  Wed Feb  4 17:39:59 2009
From: thompsa at FreeBSD.org (Andrew Thompson)
Date: Wed Feb  4 17:40:06 2009
Subject: Silicon Labs bridge on USB2?
In-Reply-To: <498A426F.6030502@protected-networks.net>
References: <498A426F.6030502@protected-networks.net>
Message-ID: <20090205013951.GA80528@citylink.fud.org.nz>

On Wed, Feb 04, 2009 at 08:35:43PM -0500, Michael Butler wrote:
> I have a GPS receiver which uses a USB->serial bridge. At present, I can
> use it with the uslcom driver but I don't see a USB-2 equivalent - is
> this supported?
> 
> dmesg offers:
> 
> ucom0: <Silicon Labs CP2102 USB to UART Bridge Controller, class 0/0,
> rev 1.10/1.00, addr 3> on uhub2

Hans has ported it over today, it may need other usb serial changes not in
current quite yet but the code is here.

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


Andrew
From andy at siliconlandmark.com  Wed Feb  4 19:04:49 2009
From: andy at siliconlandmark.com (Andre Guibert de Bruet)
Date: Wed Feb  4 19:04:56 2009
Subject: USB2 - libusb20 vs devel/libusb
In-Reply-To: <200902041123.51301.hselasky@c2i.net>
References: <1233732660.1767.30.camel@localhost>
	<200902041049.27444.hselasky@c2i.net>
	<1233741844.1767.133.camel@localhost>
	<200902041123.51301.hselasky@c2i.net>
Message-ID: <F6F4194B-C4CD-4034-AC38-704508D8E06F@siliconlandmark.com>

On Feb 4, 2009, at 5:23 AM, Hans Petter Selasky wrote:

> On Wednesday 04 February 2009, Vladimir Grebenschikov wrote:
>> On Wed, 2009-02-04 at 10:49 +0100, Hans Petter Selasky wrote:
>>
>> Probably we may provide patch against devel/libusb to depend it on
>> libusb20 ?
>
> Yes. I don't know about such a patch yet, but this is something that  
> needs to
> be done for -current.

Could we get a pkg-config definition file for libusb20 in the base  
system or in the libusb port? I have come up with my own for my  
systems (See below). There's a plethora of configure scripts that  
depend on pkg-config to do the right thing WRT libusb...

# -- 8< --
# Package Information for pkg-config

prefix=/usr/
exec_prefix=${prefix}
libdir=${exec_prefix}/lib
includedir=${prefix}/include

Name: libusb
Description: libusb 2.0
Version: 2.0
Libs: -L${libdir} -lusb20
Cflags: -I${includedir}
# -- 8< --

Cheers,
Andy

/*  Andre Guibert de Bruet  * 436f 6465 2070 6f65 742e 2042 6974 206a */
/*     Managing Partner     * 6f63 6b65 792e 2053 7973 4164 6d69 6e2e */
/*   GSM: +1 734 846 8758   * 2055 4e49 5820 736c 6575 7468 2e00 0000 */
/* WWW: siliconlandmark.com * C/C++, Java, Perl, PHP, SQL, XHTML, XML */

From uspoerlein at gmail.com  Wed Feb  4 23:36:35 2009
From: uspoerlein at gmail.com (Ulrich =?utf-8?B?U3DDtnJsZWlu?=)
Date: Wed Feb  4 23:36:48 2009
Subject: Xorg upgrade desaster: Xlib:  extension "Generic Event
	Extension" missing on display ":0.0".
In-Reply-To: <49837CFD.4080603@mail.zedat.fu-berlin.de>
References: <49837CFD.4080603@mail.zedat.fu-berlin.de>
Message-ID: <20090205073631.GI93090@acme.spoerlein.net>

On Fri, 30.01.2009 at 23:19:41 +0100, O. Hartmann wrote:
> After upgrading one of my FreeBSD 8.0-CUR/amd64 boxes to new xorg-7.4
> and having done hurting recompiling nearly everything/package twice now
> firefox3 still doesn't work properly and hits me when starting with this
> error message:
> 
> Xlib:  extension "Generic Event Extension" missing on display ":0.0".
> 
> Then firefox3 freezes forever, showing something like the background or
> pixel remnants of windows/picograms moving over its window.

This should be unrelated to Xorg 7.4, as it happens to my 7.1 box,
running Xorg 7.3 and the latest firefox3. Please try backing down
firefox3 or some other related libraries that were updated in the last
month (when this started to show up)

Cheers,
Ulrich Sp?rlein
-- 
None are more hopelessly enslaved than those who falsely believe they are free
-- Johann Wolfgang von Goethe
From ohartman at zedat.fu-berlin.de  Thu Feb  5 02:07:03 2009
From: ohartman at zedat.fu-berlin.de (O. Hartmann)
Date: Thu Feb  5 02:07:18 2009
Subject: Xorg upgrade desaster: Xlib: extension "Generic Event	Extension"
 missing on display ":0.0".
In-Reply-To: <20090205073631.GI93090@acme.spoerlein.net>
References: <49837CFD.4080603@mail.zedat.fu-berlin.de>
	<20090205073631.GI93090@acme.spoerlein.net>
Message-ID: <498AB9CA.6080907@zedat.fu-berlin.de>

Ulrich Sp?rlein wrote:
> On Fri, 30.01.2009 at 23:19:41 +0100, O. Hartmann wrote:
>> After upgrading one of my FreeBSD 8.0-CUR/amd64 boxes to new xorg-7.4
>> and having done hurting recompiling nearly everything/package twice now
>> firefox3 still doesn't work properly and hits me when starting with this
>> error message:
>>
>> Xlib:  extension "Generic Event Extension" missing on display ":0.0".
>>
>> Then firefox3 freezes forever, showing something like the background or
>> pixel remnants of windows/picograms moving over its window.
> 
> This should be unrelated to Xorg 7.4, as it happens to my 7.1 box,
> running Xorg 7.3 and the latest firefox3. Please try backing down
> firefox3 or some other related libraries that were updated in the last
> month (when this started to show up)
> 
> Cheers,
> Ulrich Sp??rlein

Hello.
As I reported earlier in this thread, I recompiled everything/package on 
my boxes at least three times and the specified problem still remained. 
But after the update of libGL/libGLUT the last three days everything 
seems to run all right now. Weird ...

Greetings,
Oliver

From michael.gusek at web.de  Thu Feb  5 03:42:06 2009
From: michael.gusek at web.de (Michael Gusek)
Date: Thu Feb  5 03:42:14 2009
Subject: zfs: allocating allocated segment
Message-ID: <200902051224.34442.michael.gusek@web.de>

Hello,

this is my first mail on this list, please excuse my bad English :)

I'm running a File server with zfs, 64 Bit, 4 GB Ram and RELENG_7. Two days 
ago i uploaded a file via ftp to the server and the server is crashing. After 
reboot FreeBSD can't import the zfs-pool. There is a kernel-message:

panic: Solaris(panic): zfs: allocating allocated 
segment(offset=123456... size=74)

cpuid = 0
Uptime: 14m22s
panic: bufwrite: buffer is not busy???

Now i try to import the zfs-pool with a recent 8.0-current but with the same 
result. It's very important to me to access the pool, so did you have some 
idea's ?

Greetings,
Michael
From marshc187 at gmail.com  Thu Feb  5 00:46:12 2009
From: marshc187 at gmail.com (cwt)
Date: Thu Feb  5 04:20:20 2009
Subject: Xorg upgrade desaster: Xlib: extension "Generic Event	Extension"
 missing on display ":0.0".
In-Reply-To: <20090205073631.GI93090@acme.spoerlein.net>
References: <49837CFD.4080603@mail.zedat.fu-berlin.de>
	<20090205073631.GI93090@acme.spoerlein.net>
Message-ID: <498AADA0.7050107@gmail.com>

Ulrich Sp?rlein wrote:
> On Fri, 30.01.2009 at 23:19:41 +0100, O. Hartmann wrote:
>   
>> After upgrading one of my FreeBSD 8.0-CUR/amd64 boxes to new xorg-7.4
>> and having done hurting recompiling nearly everything/package twice now
>> firefox3 still doesn't work properly and hits me when starting with this
>> error message:
>>
>> Xlib:  extension "Generic Event Extension" missing on display ":0.0".
>>
>> Then firefox3 freezes forever, showing something like the background or
>> pixel remnants of windows/picograms moving over its window.
>>     
>
> This should be unrelated to Xorg 7.4, as it happens to my 7.1 box,
> running Xorg 7.3 and the latest firefox3. Please try backing down
> firefox3 or some other related libraries that were updated in the last
> month (when this started to show up)
>
> Cheers,
> Ulrich Sp?rlein
>   
hey, sorry to barge in, but have you ppl by any chance seen a related 
post about this?
i saw this (am still getting it) after 7.4 upgrade, but when someone 
else reported it, the person who i think committed xorg updates i 
believe said this warning is harmless and only showing because some new 
functionality in the lib is not yet being used, something to that effect?

i think he explained that he just overlooked disabling the warning.

are you aware of this or are you having stability problems still? my 
system spits this warning, but just noise, and all working ok otherwise.
if you are aware of the post, but still having problems, then disregard 
this, and sorry if i missed something
From avg at icyb.net.ua  Thu Feb  5 04:21:32 2009
From: avg at icyb.net.ua (Andriy Gapon)
Date: Thu Feb  5 04:21:40 2009
Subject: kobj methods (DEVMETHOD) that have differing signatures (in
	src/sys)
In-Reply-To: <20090204.131104.2064955776.imp@bsdimp.com>
References: <4989E87B.5010000@icyb.net.ua>
	<20090204.131104.2064955776.imp@bsdimp.com>
Message-ID: <498AD9BF.20503@icyb.net.ua>

on 04/02/2009 22:11 M. Warner Losh said the following:
> In message: <4989E87B.5010000@icyb.net.ua>
>             Andriy Gapon <avg@icyb.net.ua> writes:
> : 
> : This based on the (much) earlier proposal described here:
> : http://lists.freebsd.org/pipermail/freebsd-arch/2008-April/007982.html
> : 
> : The patch was applied to the recent current sources and LINT kernels for
> : all architectures that have LINT/NOTES (i.e. arm excluded) were built.
> : 
> : Here's a link to the list of files and line numbers where KOBJ methods
> : are set with functions that have differing signatures:
> : http://www.icyb.net.ua/~avg/kobj_method_sigs.txt
> : 
> : List of the most common issues can be found at the first link.
> : 
> : Hope this is useful.
> 
> This is very helpful.  I'll work through the low-hanging fruit.  If
> others want to work as well, please ping me.

Warner,

thanks a lot for your attention!
I've updated the list to include actual source lines in addition to file
names and line numbers - I think this should be useful since current is
a moving target.
http://www.icyb.net.ua/~avg/kobj_method_sigs.txt

-- 
Andriy Gapon
From sepotvin at FreeBSD.org  Thu Feb  5 05:43:38 2009
From: sepotvin at FreeBSD.org (Stephane E. Potvin)
Date: Thu Feb  5 05:43:46 2009
Subject: problems dropping to single user from multi in recent -current?
In-Reply-To: <83e5fb980902041300k324cef73od2cf2a9b5ec553d5@mail.gmail.com>
References: <gmcoh8$fmc$1@ger.gmane.org> <4989EDB9.3010808@FreeBSD.org>
	<83e5fb980902041300k324cef73od2cf2a9b5ec553d5@mail.gmail.com>
Message-ID: <498AEAAA.8060607@FreeBSD.org>

Diego Depaoli wrote:
> On Wed, Feb 4, 2009 at 8:34 PM, Stephane E. Potvin <sepotvin@freebsd.org> wrote:
>> Mark Atkinson wrote:
>>> I've updated several boxes over the last few days -- these are all
>>> serial console units; and everytime I issue 'shutdown now' to drop to
>>> single user, it hangs at the pathname prompt.  Is anyone else seeing this?
> Same here
>> Try typing blind... I have the same symptoms on one of my systems when I
>> drop to single user mode (it's the only one with a USB keyboard, dunno if
>> it's coincidence or not).
> It's a coincidence, I do not have USB keyboard

You're right, I could have sworn that I experienced this only on my
system with a USB keyboard but after trying yesterday, I have the issue
on all my systems. Can you drop into DDB when this happens?

Steph

From ed at 80386.nl  Thu Feb  5 05:55:54 2009
From: ed at 80386.nl (Ed Schouten)
Date: Thu Feb  5 05:56:01 2009
Subject: [Patch] problems dropping to single user from multi in recent
	-current?
In-Reply-To: <gmcoh8$fmc$1@ger.gmane.org>
References: <gmcoh8$fmc$1@ger.gmane.org>
Message-ID: <20090205135552.GC1230@hoeg.nl>

Hi all,

I sent a patch to Mark, but it's better to send it to the lists as well.
It's a bug in the /dev/console that's available in -CURRENT. The
following patch should fix it. It also fixes the `staircase effect' some
people were experiencing:

	http://80386.nl/pub/dev-console.diff

I'll commit it after I get confirmation from Mark.

-- 
 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/20090205/8d36efed/attachment.pgp
From sepotvin at FreeBSD.org  Thu Feb  5 06:09:59 2009
From: sepotvin at FreeBSD.org (Stephane E. Potvin)
Date: Thu Feb  5 06:10:20 2009
Subject: [Patch] problems dropping to single user from multi in recent
 -current?
In-Reply-To: <20090205135552.GC1230@hoeg.nl>
References: <gmcoh8$fmc$1@ger.gmane.org> <20090205135552.GC1230@hoeg.nl>
Message-ID: <498AF334.3090906@FreeBSD.org>

Ed Schouten wrote:
> Hi all,
> 
> I sent a patch to Mark, but it's better to send it to the lists as well.
> It's a bug in the /dev/console that's available in -CURRENT. The
> following patch should fix it. It also fixes the `staircase effect' some
> people were experiencing:
> 
> 	http://80386.nl/pub/dev-console.diff
> 
> I'll commit it after I get confirmation from Mark.
> 

Hi Ed,

I can confirm that it fixes the console problem that I had. I now can
see what I type on the console after going down to single-user mode from
multi-user.

Thanks!

Steph

From ed at 80386.nl  Thu Feb  5 06:21:39 2009
From: ed at 80386.nl (Ed Schouten)
Date: Thu Feb  5 06:21:46 2009
Subject: [Patch] problems dropping to single user from multi in recent
	-current?
In-Reply-To: <498AF334.3090906@FreeBSD.org>
References: <gmcoh8$fmc$1@ger.gmane.org> <20090205135552.GC1230@hoeg.nl>
	<498AF334.3090906@FreeBSD.org>
Message-ID: <20090205142137.GD1230@hoeg.nl>

* Stephane E. Potvin <sepotvin@FreeBSD.org> wrote:
> Ed Schouten wrote:
> > I'll commit it after I get confirmation from Mark.
> > 
> 
> Hi Ed,
> 
> I can confirm that it fixes the console problem that I had. I now can
> see what I type on the console after going down to single-user mode from
> multi-user.

Ah, another tester, good enough. I've committed it to SVN (r188147).
Thanks for reporting/testing!

-- 
 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/20090205/ed8f1f1f/attachment.pgp
From atkin901 at yahoo.com  Thu Feb  5 08:10:03 2009
From: atkin901 at yahoo.com (Mark Atkinson)
Date: Thu Feb  5 08:10:10 2009
Subject: [Patch] problems dropping to single user from multi in recent
	-current?
References: <gmcoh8$fmc$1@ger.gmane.org> <20090205135552.GC1230@hoeg.nl>
Message-ID: <gmf30c$c57$1@ger.gmane.org>

Ed Schouten wrote:

> Hi all,
> 
> I sent a patch to Mark, but it's better to send it to the lists as well.
> It's a bug in the /dev/console that's available in -CURRENT. The
> following patch should fix it. It also fixes the `staircase effect' some
> people were experiencing:
> 
> http://80386.nl/pub/dev-console.diff
> 
> I'll commit it after I get confirmation from Mark.

Thanks for the quick fix, it appears to work!

-- 
Mark Atkinson
atkin901@yahoo.com
(!wired)?(coffee++):(wired);

From ptice at aldridge.com  Thu Feb  5 09:00:58 2009
From: ptice at aldridge.com (Paul Tice)
Date: Thu Feb  5 09:01:06 2009
Subject: process hang in zfs->io_ ?
References: <6eb82e0902010024o4094b3a6q3186f2109029a67a@mail.gmail.com>
	<007b01c9847a$983ad9c0$c8b08d40$@Sparrevohn@btinternet.com>
Message-ID: <E8FEAE26C87DED4EB49EFF99D1C7A51DFF6939@ald-mail02.corporate.aldridge.com>

Given time, the ZIL seems to 'catch up'. The more processes running to ZFS, the faster it seems to hang. The actual amount of data seems to matter less than the number of streams.

Putting the ZIL on a seperate disk/controller has kept the hangs from happening for me.

Thanks
Paul


-----Original Message-----
From: owner-freebsd-current@freebsd.org on behalf of Thomas Sparrevohn
Sent: Sun 2/1/2009 8:37 AM
To: 'Rong-en Fan'; 'FreeBSD Current'
Subject: RE: process hang in zfs->io_ ?
 
I have noticed the same error - However I am not actually sure that ZFS is the culprit - I tried to remotely log in from my laptop and the system unfroze 
 

-----Original Message-----
From: owner-freebsd-current@freebsd.org [mailto:owner-freebsd-current@freebsd.org] On Behalf Of Rong-en Fan
Sent: 01 February 2009 08:24
To: FreeBSD Current
Subject: process hang in zfs->io_ ?

I'm running current as of 20080130 on an amd64 box. I can make
processes stuck in zfs->io_ (output truncated in ddb and top) when I
make some packages via ports tinderbox. The ports tinderbox access
local disk via nfs (I also tried nullfs).

ddb output of ps and alltrace can be found at

http://www.rafan.org/FreeBSD/zfs/textdump.zfs.20090130.txt

Any ideas?

Thanks,
Rong-En Fan
_______________________________________________
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"










































































































































































_______________________________________________
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"

From klapperzhu at gmail.com  Thu Feb  5 09:04:17 2009
From: klapperzhu at gmail.com (Klapper Zhu)
Date: Thu Feb  5 09:04:24 2009
Subject: To John Birrell: weird behaviors of DTrace on amd64
Message-ID: <a29c138b0902050831q13844f7bm3aa3bdebdcb9733e@mail.gmail.com>

Hi John Birrell,

I am exploring DTrace on "7.1-STABLE FreeBSD amd64" and I found several
weird behaviors:

1) Not all kernel functions show up in fbt provider. Take isp(4) as example:
    "dtrace -l" shows
        static void isp_freeze_loopdown(ispsoftc_t *, int, char *);
___but not___
        static void isp_handle_platform_atio2(ispsoftc_t *, at2_entry_t *);

    Both are static functions. But one shows up in fbt, another not.
    What's the rational behind it ? Any way to fix it ?

2) The symptom described below only shows in 64-bit platform (amd64).

 Here is the D Code:

 fbt::isp_handle_platform_atio2:entry
{
  self->cdb =args[1]->at_cmnd.cdb_dl.sf.fcp_cmnd_cdb[0];
  printf("%s(%x, %x, cdb_cmd %x)\n", probefunc, arg0, arg1, self->cdb);
}

It will never fire.

I have to add another 2 probes on top of it, then it
(fbt::isp_handle_platform_atio2:entry) will trace.
Even the 2 probes on top of it never fire.
---------------
dtrace:::BEGIN
{
tr = 0;
}
fbt:::entry
/tr == 1/
{
        @a[probefunc] = count();
}
fbt::isp_handle_platform_atio2:entry
{
  self->cdb =args[1]->at_cmnd.cdb_dl.sf.fcp_cmnd_cdb[0];
  printf("%s(%x, %x, cdb_cmd %x)\n", probefunc, arg0, arg1, self->cdb);
}

Thanks,

Z. Zhu
From bruce at cran.org.uk  Thu Feb  5 10:14:14 2009
From: bruce at cran.org.uk (Bruce Cran)
Date: Thu Feb  5 10:14:23 2009
Subject: IPv6 autoconfiguration fails
Message-ID: <20090205181353.25aeea1c@tau.draftnet>

I recently reinstalled -current on my laptop and have started seeing
IPv6 autoconfiguration start failing.  I have two interfaces re0 and
ath0: re0 is plugged in and gets an address via DHCP while I'm not
using wireless at the moment so ath0 remains unconfigured.  However it
seems the IPv6 autoconfiguration tries to use ath0 instead of re0.
During boot I see:

re0: link state changed to UP
Starting Network: lo0 re0.
No ALTQ support in kernel
ALTQ related functions disabled
No ALTQ support in kernel
ALTQ related functions disabled
No ALTQ support in kernel
ALTQ related functions disabled
pf enabled
add net ::ffff:0.0.0.0: gateway ::1
add net ::0.0.0.0: gateway ::1
net.inet6.ip6.forwarding: 0 -> 0
net.inet6.ip6.accept_rtadv: 0 -> 1
get_llflag() failed, anyway I'll try
sendmsg on ath0: Can't assign requested address
sendmsg on ath0: Can't assign requested address
sendmsg on ath0: Can't assign requested address
add net fe80::: gateway ::1
add net ff02::: gateway ::1
IPv4 mapped IPv6 address support=NO
Waiting 30s for an interface to come up: ...........(re0)

ifconfig shows re0 having IPv4 and IPv6 link-local
addresses but no autoconfigured address, while I'm running rtadvd on
the router which is connected via re0.

-- 
Bruce Cran
From gleb.kurtsou at gmail.com  Thu Feb  5 10:19:14 2009
From: gleb.kurtsou at gmail.com (Gleb Kurtsou)
Date: Thu Feb  5 10:19:22 2009
Subject: process hang in zfs->io_ ?
In-Reply-To: <4988519E.2070103@micom.mng.net>
References: <6eb82e0902010024o4094b3a6q3186f2109029a67a@mail.gmail.com>
	<20090201105815.GA73985@hyperion.scode.org>
	<4988519E.2070103@micom.mng.net>
Message-ID: <20090205174955.GA1309@tops>

On (03/02/2009 22:15), Ganbold wrote:
> I've observed similar system hang when I tried to run svn update on
> FreeBSD head repo
> from 2 local directories simultaneously. I might be doing something
> wrong and as
> I remember I reproduced it a couple of times.
> 
> It is i386 CURRENT (r187663M) machine and loader.conf settings are:
> vm.kmem_size="1024M"
> vm.kmem_size_max="1024M"
> vfs.zfs.arc_max="100M"
I have no idea why, but vm.kmem_size{,_max}="1024M" slows things down a
lot. I'm running with 
vm.kmem_size="999M"
vm.kmem_size_max="999M"
and system seems to be much more responsive.

From mister.olli at googlemail.com  Thu Feb  5 11:50:51 2009
From: mister.olli at googlemail.com (Mister Olli)
Date: Thu Feb  5 11:50:58 2009
Subject: [Patch] problems dropping to single user from multi in recent
	-current?
In-Reply-To: <20090205142137.GD1230@hoeg.nl>
References: <gmcoh8$fmc$1@ger.gmane.org> <20090205135552.GC1230@hoeg.nl>
	<498AF334.3090906@FreeBSD.org>  <20090205142137.GD1230@hoeg.nl>
Message-ID: <1233863403.22204.40.camel@phoenix.blechhirn.net>

Hi,

I had the same problem, now it works like a charm.

Thanks for the great work

--
Mr. Olli


Am Donnerstag, den 05.02.2009, 15:21 +0100 schrieb Ed Schouten:
> * Stephane E. Potvin <sepotvin@FreeBSD.org> wrote:
> > Ed Schouten wrote:
> > > I'll commit it after I get confirmation from Mark.
> > > 
> > 
> > Hi Ed,
> > 
> > I can confirm that it fixes the console problem that I had. I now can
> > see what I type on the console after going down to single-user mode from
> > multi-user.
> 
> Ah, another tester, good enough. I've committed it to SVN (r188147).
> Thanks for reporting/testing!
> 

From jhb at freebsd.org  Thu Feb  5 13:46:59 2009
From: jhb at freebsd.org (John Baldwin)
Date: Thu Feb  5 13:47:06 2009
Subject: To John Birrell: weird behaviors of DTrace on amd64
In-Reply-To: <a29c138b0902050831q13844f7bm3aa3bdebdcb9733e@mail.gmail.com>
References: <a29c138b0902050831q13844f7bm3aa3bdebdcb9733e@mail.gmail.com>
Message-ID: <200902051311.00091.jhb@freebsd.org>

On Thursday 05 February 2009 11:31:52 am Klapper Zhu wrote:
> Hi John Birrell,
> 
> I am exploring DTrace on "7.1-STABLE FreeBSD amd64" and I found several
> weird behaviors:
> 
> 1) Not all kernel functions show up in fbt provider. Take isp(4) as example:
>     "dtrace -l" shows
>         static void isp_freeze_loopdown(ispsoftc_t *, int, char *);
> ___but not___
>         static void isp_handle_platform_atio2(ispsoftc_t *, at2_entry_t *);
> 
>     Both are static functions. But one shows up in fbt, another not.
>     What's the rational behind it ? Any way to fix it ?

Perhaps gcc inlined it?  Try using -fno-inline perhaps.

-- 
John Baldwin
From olli at lurza.secnetix.de  Thu Feb  5 14:18:40 2009
From: olli at lurza.secnetix.de (Oliver Fromme)
Date: Thu Feb  5 14:18:47 2009
Subject: CFT: Graphics support for /boot/loader
Message-ID: <200902052218.n15MIaEa026891@lurza.secnetix.de>

Hello fellow hackers,

Some of you might remember that I'm working on graphics
support for our /boot/loader.  Unfortunately, progress has
been rather slow because of non-FreeBSD-related activity.

Anyway, I have now prepared a tarball containing a loader
binary for public testing.  If you are eager to give it a
try, please feel free to do so.  It should work with any
FreeBSD version on i386 and amd64 platforms.

I have posted detailed instructions on the FreeBSD wiki:

http://wiki.freebsd.org/OliverFromme/BootLoaderTest

Any kind of feedback is welcome.

Best regards
   Oliver

-- 
Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M.
Handelsregister: Registergericht Muenchen, HRA 74606,  Gesch?ftsfuehrung:
secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht M?n-
chen, HRB 125758,  Gesch?ftsf?hrer: Maik Bachmann, Olaf Erb, Ralf Gebhart

FreeBSD-Dienstleistungen, -Produkte und mehr:  http://www.secnetix.de/bsd

"If Java had true garbage collection, most programs
would delete themselves upon execution."
        -- Robert Sewell
From tinderbox at freebsd.org  Thu Feb  5 14:36:07 2009
From: tinderbox at freebsd.org (FreeBSD Tinderbox)
Date: Thu Feb  5 14:36:30 2009
Subject: [head tinderbox] failure on i386/i386
Message-ID: <20090205223603.764E97302F@freebsd-current.sentex.ca>

TB --- 2009-02-05 21:06:05 - tinderbox 2.6 running on freebsd-current.sentex.ca
TB --- 2009-02-05 21:06:05 - starting HEAD tinderbox run for i386/i386
TB --- 2009-02-05 21:06:05 - cleaning the object tree
TB --- 2009-02-05 21:06:38 - cvsupping the source tree
TB --- 2009-02-05 21:06:38 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/i386/i386/supfile
TB --- 2009-02-05 21:06:49 - building world
TB --- 2009-02-05 21:06:49 - MAKEOBJDIRPREFIX=/obj
TB --- 2009-02-05 21:06:49 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2009-02-05 21:06:49 - TARGET=i386
TB --- 2009-02-05 21:06:49 - TARGET_ARCH=i386
TB --- 2009-02-05 21:06:49 - TZ=UTC
TB --- 2009-02-05 21:06:49 - __MAKE_CONF=/dev/null
TB --- 2009-02-05 21:06:49 - cd /src
TB --- 2009-02-05 21:06:49 - /usr/bin/make -B buildworld
>>> World build started on Thu Feb  5 21:06: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
>>> World build completed on Thu Feb  5 22:27:30 UTC 2009
TB --- 2009-02-05 22:27:30 - generating LINT kernel config
TB --- 2009-02-05 22:27:30 - cd /src/sys/i386/conf
TB --- 2009-02-05 22:27:30 - /usr/bin/make -B LINT
TB --- 2009-02-05 22:27:30 - building LINT kernel
TB --- 2009-02-05 22:27:30 - MAKEOBJDIRPREFIX=/obj
TB --- 2009-02-05 22:27:30 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2009-02-05 22:27:30 - TARGET=i386
TB --- 2009-02-05 22:27:30 - TARGET_ARCH=i386
TB --- 2009-02-05 22:27:30 - TZ=UTC
TB --- 2009-02-05 22:27:30 - __MAKE_CONF=/dev/null
TB --- 2009-02-05 22:27:30 - cd /src
TB --- 2009-02-05 22:27:30 - /usr/bin/make -B buildkernel KERNCONF=LINT
>>> Kernel build for LINT started on Thu Feb  5 22:27: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
[...]
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/esp/ncr53c9x.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/ex/if_ex.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/ex/if_ex_isa.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/ex/if_ex_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/exca/exca.c
cc1: warnings being treated as errors
/src/sys/dev/exca/exca.c: In function 'exca_mem_map':
/src/sys/dev/exca/exca.c:260: warning: right shift count >= width of type
*** Error code 1

Stop in /obj/src/sys/LINT.
*** Error code 1

Stop in /src.
*** Error code 1

Stop in /src.
TB --- 2009-02-05 22:36:03 - WARNING: /usr/bin/make returned exit code  1 
TB --- 2009-02-05 22:36:03 - ERROR: failed to build lint kernel
TB --- 2009-02-05 22:36:03 - 4291.66 user 419.23 system 5397.49 real


http://tinderbox.des.no/tinderbox-head-HEAD-i386-i386.full
From thompsa at FreeBSD.org  Thu Feb  5 14:37:03 2009
From: thompsa at FreeBSD.org (Andrew Thompson)
Date: Thu Feb  5 14:37:12 2009
Subject: CFT: Graphics support for /boot/loader
In-Reply-To: <200902052218.n15MIaEa026891@lurza.secnetix.de>
References: <200902052218.n15MIaEa026891@lurza.secnetix.de>
Message-ID: <20090205223657.GC88414@citylink.fud.org.nz>

On Thu, Feb 05, 2009 at 11:18:36PM +0100, Oliver Fromme wrote:
> Hello fellow hackers,
> 
> Some of you might remember that I'm working on graphics
> support for our /boot/loader.  Unfortunately, progress has
> been rather slow because of non-FreeBSD-related activity.
> 
> Anyway, I have now prepared a tarball containing a loader
> binary for public testing.  If you are eager to give it a
> try, please feel free to do so.  It should work with any
> FreeBSD version on i386 and amd64 platforms.
> 
> I have posted detailed instructions on the FreeBSD wiki:
> 
> http://wiki.freebsd.org/OliverFromme/BootLoaderTest
> 
> Any kind of feedback is welcome.

Works well here, tried various combinations of the options. This is very
cool.


Andrew
From bomberboy at gmail.com  Thu Feb  5 14:54:29 2009
From: bomberboy at gmail.com (Bruno Van Den Bossche)
Date: Thu Feb  5 14:54:36 2009
Subject: CFT: Graphics support for /boot/loader
In-Reply-To: <200902052218.n15MIaEa026891@lurza.secnetix.de>
References: <200902052218.n15MIaEa026891@lurza.secnetix.de>
Message-ID: <6e77fe4e0902051432n25e68edes341495f994c64bca@mail.gmail.com>

On Thu, Feb 5, 2009 at 11:18 PM, Oliver Fromme <olli@lurza.secnetix.de> wrote:

[graphical bootloader]

> I have posted detailed instructions on the FreeBSD wiki:
>
> http://wiki.freebsd.org/OliverFromme/BootLoaderTest
>
> Any kind of feedback is welcome.

I've just tested it on my laptop (Fujitsu T4220) with current and it
works very well, Can select/unselect any options and everything seems
to work as it is supposed.

And I love the look :)


Regards,
Bruno
From max at love2party.net  Thu Feb  5 15:21:34 2009
From: max at love2party.net (Max Laier)
Date: Thu Feb  5 15:21:48 2009
Subject: CFT: Graphics support for /boot/loader
In-Reply-To: <200902052218.n15MIaEa026891@lurza.secnetix.de>
References: <200902052218.n15MIaEa026891@lurza.secnetix.de>
Message-ID: <200902060021.30883.max@love2party.net>

On Thursday 05 February 2009 23:18:36 Oliver Fromme wrote:
> I have posted detailed instructions on the FreeBSD wiki:
>
> http://wiki.freebsd.org/OliverFromme/BootLoaderTest
>
> Any kind of feedback is welcome.

quick test in qemu - works well.  Very cool!

-- 
/"\  Best regards,                      | mlaier@freebsd.org
\ /  Max Laier                          | ICQ #67774661
 X   http://pf4freebsd.love2party.net/  | mlaier@EFnet
/ \  ASCII Ribbon Campaign              | Against HTML Mail and News
From gonzo at bluezbox.com  Thu Feb  5 15:50:03 2009
From: gonzo at bluezbox.com (Oleksandr Tymoshenko)
Date: Thu Feb  5 15:50:09 2009
Subject: CFT: Graphics support for /boot/loader
In-Reply-To: <200902052218.n15MIaEa026891@lurza.secnetix.de>
References: <200902052218.n15MIaEa026891@lurza.secnetix.de>
Message-ID: <498B754B.1050901@bluezbox.com>

Oliver Fromme wrote:
> http://wiki.freebsd.org/OliverFromme/BootLoaderTest
> 
> Any kind of feedback is welcome.
     Works fine on Thinkpad T400 (CURRENT/i386).
From smrad01 at gmail.com  Thu Feb  5 16:02:48 2009
From: smrad01 at gmail.com (blah)
Date: Thu Feb  5 16:02:55 2009
Subject: CFT: Graphics support for /boot/loader
In-Reply-To: <200902052218.n15MIaEa026891@lurza.secnetix.de>
References: <200902052218.n15MIaEa026891@lurza.secnetix.de>
Message-ID: <498B7970.701@gmail.com>

Oliver Fromme wrote:
> Hello fellow hackers,
>
> Some of you might remember that I'm working on graphics
> support for our /boot/loader.  Unfortunately, progress has
> been rather slow because of non-FreeBSD-related activity.
>
> Anyway, I have now prepared a tarball containing a loader
> binary for public testing.  If you are eager to give it a
> try, please feel free to do so.  It should work with any
> FreeBSD version on i386 and amd64 platforms.
>
> I have posted detailed instructions on the FreeBSD wiki:
>
> http://wiki.freebsd.org/OliverFromme/BootLoaderTest
>
> Any kind of feedback is welcome.
>
> Best regards
>    Oliver
>
>   
 test in vmware with 7.0 - very nice


From pphajek at lbl.gov  Thu Feb  5 16:06:11 2009
From: pphajek at lbl.gov (Patrick Hajek)
Date: Thu Feb  5 16:06:18 2009
Subject: CFT: Graphics support for /boot/loader
Message-ID: <20090205235040.GG90914@lbl.gov>


On Thu, Feb 05, 2009 at 11:18:36PM +0100, Oliver Fromme wrote:
> Hello fellow hackers,
> 
> Some of you might remember that I'm working on graphics
> support for our /boot/loader.  Unfortunately, progress has
> been rather slow because of non-FreeBSD-related activity.
> 
> Anyway, I have now prepared a tarball containing a loader
> binary for public testing.  If you are eager to give it a
> try, please feel free to do so.  It should work with any
> FreeBSD version on i386 and amd64 platforms.
> 
> I have posted detailed instructions on the FreeBSD wiki:
> 
> http://wiki.freebsd.org/OliverFromme/BootLoaderTest
> 
> Any kind of feedback is welcome.

Works on my Toshiba Satellite M60 Laptop
noe# uname -a
FreeBSD noe 7.1-STABLE FreeBSD 7.1-STABLE #27: Tue Jan 20 12:56:40 PST 2009  
i386

Great Job.

-Patrick

-- 
Patrick Hajek		
				
PGP Fingerprint 688E B579 3449 28B1 DB14  E15A 76BB C1CA A745 9DAB
From julian at elischer.org  Thu Feb  5 16:44:05 2009
From: julian at elischer.org (Julian Elischer)
Date: Thu Feb  5 16:44:18 2009
Subject: CFT: Graphics support for /boot/loader
In-Reply-To: <200902060021.30883.max@love2party.net>
References: <200902052218.n15MIaEa026891@lurza.secnetix.de>
	<200902060021.30883.max@love2party.net>
Message-ID: <498B811D.50405@elischer.org>

Max Laier wrote:
> On Thursday 05 February 2009 23:18:36 Oliver Fromme wrote:
>> I have posted detailed instructions on the FreeBSD wiki:
>>
>> http://wiki.freebsd.org/OliverFromme/BootLoaderTest
>>
>> Any kind of feedback is welcome.
> 
> quick test in qemu - works well.  Very cool!
> 

can you send a screenshot for those of us who can't test it now?
From scottl at samsco.org  Thu Feb  5 17:01:05 2009
From: scottl at samsco.org (Scott Long)
Date: Thu Feb  5 17:01:18 2009
Subject: CFT: Graphics support for /boot/loader
In-Reply-To: <498B811D.50405@elischer.org>
References: <200902052218.n15MIaEa026891@lurza.secnetix.de>	<200902060021.30883.max@love2party.net>
	<498B811D.50405@elischer.org>
Message-ID: <498B88CC.9030903@samsco.org>

Julian Elischer wrote:
> Max Laier wrote:
>> On Thursday 05 February 2009 23:18:36 Oliver Fromme wrote:
>>> I have posted detailed instructions on the FreeBSD wiki:
>>>
>>> http://wiki.freebsd.org/OliverFromme/BootLoaderTest
>>>
>>> Any kind of feedback is welcome.
>>
>> quick test in qemu - works well.  Very cool!
>>
> 
> can you send a screenshot for those of us who can't test it now?

http://wiki.freebsd.org/OliverFromme/BootLoader
From biancalana at gmail.com  Thu Feb  5 17:58:13 2009
From: biancalana at gmail.com (Alexandre Biancalana)
Date: Thu Feb  5 17:58:20 2009
Subject: CFT: Graphics support for /boot/loader
In-Reply-To: <200902060021.30883.max@love2party.net>
References: <200902052218.n15MIaEa026891@lurza.secnetix.de>
	<200902060021.30883.max@love2party.net>
Message-ID: <8e10486b0902051758t2044238co70f89f1beb52afd1@mail.gmail.com>

On 2/5/09, Max Laier <max@love2party.net> wrote:
> On Thursday 05 February 2009 23:18:36 Oliver Fromme wrote:
>  > I have posted detailed instructions on the FreeBSD wiki:
>  >
>  > http://wiki.freebsd.org/OliverFromme/BootLoaderTest
>  >
>  > Any kind of feedback is welcome.
>
>
> quick test in qemu - works well.  Very cool

tested in Parallels, works perfect and looks great.

Congratulations!
From scottl at samsco.org  Thu Feb  5 18:52:08 2009
From: scottl at samsco.org (Scott Long)
Date: Thu Feb  5 18:52:21 2009
Subject: CFT: Graphics support for /boot/loader
In-Reply-To: <200902052218.n15MIaEa026891@lurza.secnetix.de>
References: <200902052218.n15MIaEa026891@lurza.secnetix.de>
Message-ID: <498BA5D5.4080100@samsco.org>

Oliver Fromme wrote:
> Hello fellow hackers,
> 
> Some of you might remember that I'm working on graphics
> support for our /boot/loader.  Unfortunately, progress has
> been rather slow because of non-FreeBSD-related activity.
> 
> Anyway, I have now prepared a tarball containing a loader
> binary for public testing.  If you are eager to give it a
> try, please feel free to do so.  It should work with any
> FreeBSD version on i386 and amd64 platforms.
> 
> I have posted detailed instructions on the FreeBSD wiki:
> 
> http://wiki.freebsd.org/OliverFromme/BootLoaderTest
> 
> Any kind of feedback is welcome.
> 

I think that this is really neat, you've done an impressive job
with it good job.  However, I do take issue with your criticism
of the ASCII logo; I actually spent a decent amount of time
designing the block text logo =-)  I wish that there hadn't been
moronic politics over the beastie logo, as that does look a lot
better, even if it is text.  And text is still required for
serial consoles.

Scott
From julian at elischer.org  Thu Feb  5 20:28:54 2009
From: julian at elischer.org (Julian Elischer)
Date: Thu Feb  5 20:29:07 2009
Subject: CFT: Graphics support for /boot/loader
In-Reply-To: <200902052218.n15MIaEa026891@lurza.secnetix.de>
References: <200902052218.n15MIaEa026891@lurza.secnetix.de>
Message-ID: <498BBC85.3070408@elischer.org>

Oliver Fromme wrote:
> Hello fellow hackers,
> 
> Some of you might remember that I'm working on graphics
> support for our /boot/loader.  Unfortunately, progress has
> been rather slow because of non-FreeBSD-related activity.
> 
> Anyway, I have now prepared a tarball containing a loader
> binary for public testing.  If you are eager to give it a
> try, please feel free to do so.  It should work with any
> FreeBSD version on i386 and amd64 platforms.
> 
> I have posted detailed instructions on the FreeBSD wiki:
> 
> http://wiki.freebsd.org/OliverFromme/BootLoaderTest
> 
> Any kind of feedback is welcome.
> 
> Best regards
>    Oliver
> 


very nice...

BTW most of these things seem to have <ESC> drop out of
graphics mode..
do you have something like that?
(or maybe <ESC> should go to loader prompt...?)

If I had a machine that it didn't work on I think I'd try hitting esc
  but I don't think I'd think of F7.

From alfred at freebsd.org  Thu Feb  5 20:53:50 2009
From: alfred at freebsd.org (Alfred Perlstein)
Date: Thu Feb  5 20:53:57 2009
Subject: HEADSUP usb2/usb4bsd to become default in GENERIC
Message-ID: <20090206045349.GQ78804@elvis.mu.org>

Hello -current and -usb.

We are in the final stages of bringing in the new usb
stack.

Features include: SMP, better device support, speed increases.

We hope to make it in for 8.0.  It will really take a unified effort
to make this all work and I look forward to all contributors input.

We have a few large steps ahead of us and I wanted to lay out the
schedule so that people understand what is coming and what to expect.

At this point we expect there to be no style or changes in usb2
that are not bugfixes until Phase 3 "Hand off".  The reason for
this is to prevent bugs from creeping in and allow the maintainer
to focus 100% on bugs and feature parity with the oldusb stack.

Here is the plan and timeline:

Phase 1) Make usb2 the default, by enabling it in GENERIC.

    * Sunday 8 Feb 2009  -- Toggle the usb2 knob in GENERIC

      - Add all the usb2 options to NOTES, including commented
        documentation about recommended usb2 'sets' of options,
        and the usual NOTES-based hints about the options.

      - Update GENERIC to use usb2 device names.

      - Bump __FreeBSD_version and edit UPDATING to note usb2 is now the
        default.

      - Verify that it still possible to use the old usb code as a
        fallback, until we are ready to detach and remove it from /head

    * Sunday 22 Feb 2009 -- Go through quirks in old-usb code and port
      over any remaining bits to usb2

      - Lock the oldusb code for 2 weeks, until the next usb2
        checkpoint, to verify usb2 is a viable replacement without
        having to keep chasing a moving oldusb target.

Phase 2) Removing the oldusb code.

    * Sunday 15 Mar 2009 -- usb2 bug busting weekend

      - Go through the open usb2 problem reports, and see if there are
        any usb2 blocker bugs that need fixing.

      - If the bug hunt shows we are ready to do away with oldusb,
        unlink the old usb code from the build, but leave it in for
        a few more days.

    * Sunday 22 Mar 2009 -- remove oldusb code.

      - old usb code will be removed.

Phase 3) Hand-off.

    * Sunday 29 Mar 2009 -- usb2 hand over to src-committers

      - The switch from a private Hans-only repository to the main
        subversion tree.

      - At this point, the usb2 is handed over to the src-committers
        and Hans has to go through a mentor/committer before committing
	changes.

Thank you!

-- 
- Alfred Perlstein
From beech at freebsd.org  Thu Feb  5 23:03:39 2009
From: beech at freebsd.org (Beech Rintoul)
Date: Thu Feb  5 23:03:47 2009
Subject: lpt stopped working
In-Reply-To: <200902040914.10330.jhb@freebsd.org>
References: <200902021643.39862.c47g@gmx.at>
	<200902040914.10330.jhb@freebsd.org>
Message-ID: <200902052203.37792.beech@freebsd.org>

On Wednesday 04 February 2009 05:14:10 John Baldwin wrote:
> On Monday 02 February 2009 10:43:39 am Christian Gusenbauer wrote:
> > Hi!
> >
> > Since the recent update (svn r187576) to the ppbus/ppc code my printer
>
> stopped
>
> > working. Every request seems to hang forever in ppb_request_bus waiting
> > for ppb->ppc_lock (at least 'top' tells me that it's hanging in state
> > 'ppbreq').
>
> Can you use procstat to get a stack trace of the hung thread?

My printer is still showing "device busy" for lpt0 does anyone know offhand 
when the changes were committed? I need to revert.

Beech

-- 
---------------------------------------------------------------------------------------
Beech Rintoul - FreeBSD Developer - beech@FreeBSD.org
/"\   ASCII Ribbon Campaign  | FreeBSD Since 4.x
\ / - NO HTML/RTF in e-mail   | http://people.freebsd.org/~beech
 X  - NO Word docs in e-mail | Skype: akbeech
/ \  - http://www.FreeBSD.org/releases/7.1R/announce.html
---------------------------------------------------------------------------------------




From olli at lurza.secnetix.de  Thu Feb  5 23:11:38 2009
From: olli at lurza.secnetix.de (Oliver Fromme)
Date: Thu Feb  5 23:11:51 2009
Subject: CFT: Graphics support for /boot/loader
In-Reply-To: <498BA5D5.4080100@samsco.org>
Message-ID: <200902060711.n167BZ9a048166@lurza.secnetix.de>

Scott Long wrote:
 > Oliver Fromme wrote:
 > > [...]
 > > http://wiki.freebsd.org/OliverFromme/BootLoaderTest
 > 
 > I think that this is really neat, you've done an impressive job
 > with it good job.  However, I do take issue with your criticism
 > of the ASCII logo; I actually spent a decent amount of time
 > designing the block text logo =-)

I'm sorry, it wasn't my intention to disrespect your work.
What I was trying to say is that ASCII graphics look old-
fashioned in general.  I wasn't actually picking on your
rendition of the text logo in particular.

Yeah, I noticed your smiley, but I agree that my wording
on the wiki page was misleading, so I changed it.

 > I wish that there hadn't been
 > moronic politics over the beastie logo, as that does look a lot
 > better, even if it is text.  And text is still required for
 > serial consoles.

Absolutely.  Text is also required for machines that aren't
supported by the graphics code, or machines that don't have
any graphics hardware at all.

Don't worry, I'm not going to rip your ASCII logo out.  :-)

Best regards
   Oliver

-- 
Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M.
Handelsregister: Registergericht Muenchen, HRA 74606,  Gesch?ftsfuehrung:
secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht M?n-
chen, HRB 125758,  Gesch?ftsf?hrer: Maik Bachmann, Olaf Erb, Ralf Gebhart

FreeBSD-Dienstleistungen, -Produkte und mehr:  http://www.secnetix.de/bsd

"Being really good at C++ is like being really good
at using rocks to sharpen sticks."
        -- Thant Tessman
From olli at lurza.secnetix.de  Thu Feb  5 23:21:09 2009
From: olli at lurza.secnetix.de (Oliver Fromme)
Date: Thu Feb  5 23:21:15 2009
Subject: CFT: Graphics support for /boot/loader
In-Reply-To: <freebsd-current.43073.1233894598.498BBC85.3070408@elischer.org>
Message-ID: <200902060721.n167L2px048711@lurza.secnetix.de>

Julian Elischer wrote:
 > BTW most of these things seem to have <ESC> drop out of
 > graphics mode..
 > do you have something like that?
 > (or maybe <ESC> should go to loader prompt...?)

Good question.  The screen layout isn't final, of course,
and I'm open to suggestions.  (Also, there will be a short
descriptive text for the countdown and how to pause it.)

I think it might make sense to provide an additional action
using the <Esc> key that leaves graphics mode and displays
the old text menu instead.

Best regards
   Oliver

-- 
Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M.
Handelsregister: Registergericht Muenchen, HRA 74606,  Gesch?ftsfuehrung:
secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht M?n-
chen, HRB 125758,  Gesch?ftsf?hrer: Maik Bachmann, Olaf Erb, Ralf Gebhart

FreeBSD-Dienstleistungen, -Produkte und mehr:  http://www.secnetix.de/bsd

"C++ is over-complicated nonsense. And Bjorn Shoestrap's book
a danger to public health. I tried reading it once, I was in
recovery for months."
        -- Cliff Sarginson
From danny at cs.huji.ac.il  Fri Feb  6 00:51:14 2009
From: danny at cs.huji.ac.il (Danny Braniss)
Date: Fri Feb  6 00:51:21 2009
Subject: CFT: Graphics support for /boot/loader 
In-Reply-To: <8e10486b0902051758t2044238co70f89f1beb52afd1@mail.gmail.com> 
References: <200902052218.n15MIaEa026891@lurza.secnetix.de> 
	<200902060021.30883.max@love2party.net>
	<8e10486b0902051758t2044238co70f89f1beb52afd1@mail.gmail.com>
Message-ID: <E1LVMQZ-000OKJ-U7@kabab.cs.huji.ac.il>

> On Thursday 05 February 2009 23:18:36 Oliver Fromme wrote:
> I have posted detailed instructions on the FreeBSD wiki:
[...]
just tried it via pxe:

panic: free: guard1 @ 0x7f3a4aec from /usr/src/lib/libstand/close.c:79

what changes are needed in pxeboot?

cheers,
	danny



From sobomax at FreeBSD.org  Fri Feb  6 01:22:06 2009
From: sobomax at FreeBSD.org (Maxim Sobolev)
Date: Fri Feb  6 01:22:13 2009
Subject: HEADSUP usb2/usb4bsd to become default in GENERIC
In-Reply-To: <20090206045349.GQ78804@elvis.mu.org>
References: <20090206045349.GQ78804@elvis.mu.org>
Message-ID: <498C013B.4000405@FreeBSD.org>

Alfred Perlstein wrote:
>       - Update GENERIC to use usb2 device names.

Wasn't there a plan to rename usb2 devices to match oldusb names (where 
applicable) once oldusb had been killed? I don't see it in the list.

-Maxim
From olli at lurza.secnetix.de  Fri Feb  6 01:25:50 2009
From: olli at lurza.secnetix.de (Oliver Fromme)
Date: Fri Feb  6 01:26:03 2009
Subject: CFT: Graphics support for /boot/loader
In-Reply-To: <E1LVMQZ-000OKJ-U7@kabab.cs.huji.ac.il>
Message-ID: <200902060925.n169PObG053288@lurza.secnetix.de>

Danny Braniss wrote:
 > just tried it via pxe:
 > 
 > panic: free: guard1 @ 0x7f3a4aec from /usr/src/lib/libstand/close.c:79
 > 
 > what changes are needed in pxeboot?

The panic message means that the heap memory was corruped.
It could be caused by a buffer overflow or similar.
I'll try to look into it.

When does that message appear?  Could you provide a screen
shot?

Best regards
   Oliver

-- 
Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M.
Handelsregister: Registergericht Muenchen, HRA 74606,  Gesch?ftsfuehrung:
secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht M?n-
chen, HRB 125758,  Gesch?ftsf?hrer: Maik Bachmann, Olaf Erb, Ralf Gebhart

FreeBSD-Dienstleistungen, -Produkte und mehr:  http://www.secnetix.de/bsd

We're sysadmins.  To us, data is a protocol-overhead.
From michael.gusek at web.de  Fri Feb  6 02:31:21 2009
From: michael.gusek at web.de (Michael Gusek)
Date: Fri Feb  6 02:31:28 2009
Subject: zfs: allocating allocated segment
In-Reply-To: <200902051224.34442.michael.gusek@web.de>
References: <200902051224.34442.michael.gusek@web.de>
Message-ID: <498C1175.1040006@web.de>

Is everyone out there who can help me ?

Greetings,
Michael

Michael Gusek schrieb:
> Hello,
>
> this is my first mail on this list, please excuse my bad English :)
>
> I'm running a File server with zfs, 64 Bit, 4 GB Ram and RELENG_7. Two days 
> ago i uploaded a file via ftp to the server and the server is crashing. After 
> reboot FreeBSD can't import the zfs-pool. There is a kernel-message:
>
> panic: Solaris(panic): zfs: allocating allocated 
> segment(offset=123456... size=74)
>
> cpuid = 0
> Uptime: 14m22s
> panic: bufwrite: buffer is not busy???
>
> Now i try to import the zfs-pool with a recent 8.0-current but with the same 
> result. It's very important to me to access the pool, so did you have some 
> idea's ?
>
> Greetings,
> Michael
> _______________________________________________
> 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 ale at FreeBSD.org  Fri Feb  6 02:33:24 2009
From: ale at FreeBSD.org (Alex Dupre)
Date: Fri Feb  6 02:33:36 2009
Subject: CFT: Graphics support for /boot/loader
In-Reply-To: <200902052218.n15MIaEa026891@lurza.secnetix.de>
References: <200902052218.n15MIaEa026891@lurza.secnetix.de>
Message-ID: <498C0BAE.5020803@FreeBSD.org>

Oliver Fromme ha scritto:
> Some of you might remember that I'm working on graphics
> support for our /boot/loader.

Just a side question: are you going to improve also the splash(4) 
support? Graphical loader is great, but unfortunately on amd64 the boot 
splash screen is unusable.
In any case, good job.

-- 
Alex Dupre
From skip at menantico.com  Fri Feb  6 03:22:37 2009
From: skip at menantico.com (Skip Ford)
Date: Fri Feb  6 03:22:44 2009
Subject: CFT: Graphics support for /boot/loader
In-Reply-To: <200902060721.n167L2px048711@lurza.secnetix.de>
References: <freebsd-current.43073.1233894598.498BBC85.3070408@elischer.org>
	<200902060721.n167L2px048711@lurza.secnetix.de>
Message-ID: <20090206102106.GA881@menantico.com>

Oliver Fromme wrote:
> Julian Elischer wrote:
>  > BTW most of these things seem to have <ESC> drop out of
>  > graphics mode..
>  > do you have something like that?
>  > (or maybe <ESC> should go to loader prompt...?)
> 
> Good question.  The screen layout isn't final, of course,
> and I'm open to suggestions.  (Also, there will be a short
> descriptive text for the countdown and how to pause it.)
> 
> I think it might make sense to provide an additional action
> using the <Esc> key that leaves graphics mode and displays
> the old text menu instead.

What about F8?  That's what I'd guess a majority of people would
instinctively reach for to get to a boot menu.

-- 
Skip
From skip at menantico.com  Fri Feb  6 03:28:24 2009
From: skip at menantico.com (Skip Ford)
Date: Fri Feb  6 03:28:38 2009
Subject: CFT: Graphics support for /boot/loader
In-Reply-To: <20090206102106.GA881@menantico.com>
References: <freebsd-current.43073.1233894598.498BBC85.3070408@elischer.org>
	<200902060721.n167L2px048711@lurza.secnetix.de>
	<20090206102106.GA881@menantico.com>
Message-ID: <20090206112926.GB881@menantico.com>

Skip Ford wrote:
> Oliver Fromme wrote:
> > Julian Elischer wrote:
> >  > BTW most of these things seem to have <ESC> drop out of
> >  > graphics mode..
> >  > do you have something like that?
> >  > (or maybe <ESC> should go to loader prompt...?)
> > 
> > Good question.  The screen layout isn't final, of course,
> > and I'm open to suggestions.  (Also, there will be a short
> > descriptive text for the countdown and how to pause it.)
> > 
> > I think it might make sense to provide an additional action
> > using the <Esc> key that leaves graphics mode and displays
> > the old text menu instead.
> 
> What about F8?  That's what I'd guess a majority of people would
> instinctively reach for to get to a boot menu.

Ok, scratch that idea.  Windows uses F8 to stop an automatic boot, not
really to drop to a text menu from a graphics menu.  We can press any key
to stop an automatic boot already, so F8 could be used to halt an
automatic boot and jump straight to a boot menu, but that has nothing
to do with this graphical boot menu.  It could even jump to the graphical
boot menu, not necessarily text.  Windows just happens to not have a
graphical menu.

-- 
Skip
From rbgarga at gmail.com  Fri Feb  6 03:30:27 2009
From: rbgarga at gmail.com (Renato Botelho)
Date: Fri Feb  6 03:30:33 2009
Subject: CFT: Graphics support for /boot/loader
In-Reply-To: <200902052218.n15MIaEa026891@lurza.secnetix.de>
References: <200902052218.n15MIaEa026891@lurza.secnetix.de>
Message-ID: <747dc8f30902060330l33fb0bbo489dc4fe3009747a@mail.gmail.com>

On Thu, Feb 5, 2009 at 8:18 PM, Oliver Fromme <olli@lurza.secnetix.de> wrote:
> Hello fellow hackers,
>
> Some of you might remember that I'm working on graphics
> support for our /boot/loader.  Unfortunately, progress has
> been rather slow because of non-FreeBSD-related activity.
>
> Anyway, I have now prepared a tarball containing a loader
> binary for public testing.  If you are eager to give it a
> try, please feel free to do so.  It should work with any
> FreeBSD version on i386 and amd64 platforms.
>
> I have posted detailed instructions on the FreeBSD wiki:
>
> http://wiki.freebsd.org/OliverFromme/BootLoaderTest
>
> Any kind of feedback is welcome.

Hello Oliver

It worked here, on a 8.0-current i386 r188003, the only small
thing is it show a red border when show the menu.

There is a dmidecode output attached, just to give you some
information about the bios.

Thanks and congrats for the nice job
-- 
Renato Botelho
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dmidecode.out
Type: application/octet-stream
Size: 11534 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20090206/02e984c2/dmidecode.obj
From olli at lurza.secnetix.de  Fri Feb  6 03:39:17 2009
From: olli at lurza.secnetix.de (Oliver Fromme)
Date: Fri Feb  6 03:39:30 2009
Subject: CFT: Graphics support for /boot/loader
In-Reply-To: <498C0BAE.5020803@FreeBSD.org>
Message-ID: <200902061139.n16BdB6b058473@lurza.secnetix.de>

Alex Dupre wrote:
 > Oliver Fromme ha scritto:
 > > Some of you might remember that I'm working on graphics
 > > support for our /boot/loader.
 > 
 > Just a side question: are you going to improve also the splash(4) 
 > support? Graphical loader is great, but unfortunately on amd64 the boot 
 > splash screen is unusable.

The problem is related to the fact that a 64bit kernel
cannot use VESA BIOS functions.  You should be able to
use standard VGA modes though, which don't require VESA
support.

Anyway, there have been several ideas floating around to
fix or work-around the VESA problem for amd64.  One of
them involves letting the loader prepare graphics mode
(doing all the VESA stuff) and hand all the necessary
information to the kernel, so the kernel only has to
perform framebuffer access, but no VESA BIOS calls.

It is my plan to try to look into that, but I would like
to continue with the current work on the boot loader
first.  As soon as the graphics support in the loader is
stable and "finished", I can start thinking about how to
interface that graphics support with the kernel's syscons
driver (which is a very sensitive piece of code).

Best regards
   Oliver

-- 
Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M.
Handelsregister: Registergericht Muenchen, HRA 74606,  Gesch?ftsfuehrung:
secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht M?n-
chen, HRB 125758,  Gesch?ftsf?hrer: Maik Bachmann, Olaf Erb, Ralf Gebhart

FreeBSD-Dienstleistungen, -Produkte und mehr:  http://www.secnetix.de/bsd

"File names are infinite in length, where infinity is set to 255 characters."
        -- Peter Collinson, "The Unix File System"
From barney_cordoba at yahoo.com  Fri Feb  6 04:11:15 2009
From: barney_cordoba at yahoo.com (Barney Cordoba)
Date: Fri Feb  6 04:11:25 2009
Subject: SATA drive device moving on 8.0 current
In-Reply-To: <20090201171938.H97967@ury.york.ac.uk>
Message-ID: <970727.1724.qm@web63906.mail.re1.yahoo.com>




--- On Sun, 2/1/09, Gavin Atkinson <gavin@FreeBSD.org> wrote:

> From: Gavin Atkinson <gavin@FreeBSD.org>
> Subject: Re: SATA drive device moving on 8.0 current
> To: "Barney Cordoba" <barney_cordoba@yahoo.com>
> Cc: current@FreeBSD.org
> Date: Sunday, February 1, 2009, 12:22 PM
> On Wed, 28 Jan 2009, Barney Cordoba wrote:
> 
> > I booted 8.0-current on a machine that was running 7
> and the SATA drive
> > came up as ad4 instead of ad8 (as it is detected in
> 7). This is the case
> > was loading GENERIC.
> > 
> > This is going to present a serious problem doing field
> upgrades as its
> > expected that fstab will be the same. What is the
> reason for the change and
> > is there any way to make it compatible with device
> detection in 7?
> 
> I suspect the problem is caused by some changes made in
> -CURRENT a few months ago, which had the potential to change
> the order that some devices may be detected.
> 
> Can you post online a dmesg from both 7.x and 8.0
> somewhere?
> 
> Gavin

Last login: Fri Feb  6 07:03:22 on ttys000
Mac3:~ dennis$ telnet -K 129.45.18.71
Trying 129.45.18.71...
Connected to 129.45.18.71.
Escape character is '^]'.

FreeBSD/i386 (bigby7.localdomain.com) (ttyp0)

login: root
Password:
Last login: Fri Feb  6 07:01:42 from mac3
Copyright (c) 1992-2008 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 7.0-RELEASE (DEBUG) #65: Tue Feb  3 12:54:34 EST 2009

Welcome to FreeBSD!

Before seeking technical support, please use the following resources:

o  Security advisories and updated errata information for all releases are
   at http://www.FreeBSD.org/releases/ - always consult the ERRATA section
   for your release first as it's updated frequently.

o  The Handbook and FAQ documents are at http://www.FreeBSD.org/ and,
   along with the mailing lists, can be searched by going to
   http://www.FreeBSD.org/search/.  If the doc distribution has
   been installed, they're also available formatted in /usr/share/doc.

If you still have a question or problem, please take the output of
`uname -a', along with any relevant error messages, and email it
as a question to the questions@FreeBSD.org mailing list.  If you are
unfamiliar with FreeBSD's directory layout, please refer to the hier(7)
manual page.  If you are not familiar with manual pages, type `man man'.

You may also use sysinstall(8) to re-enter the installation and
configuration utility.  Edit /etc/motd to change this login announcement.

You have new mail.
bigby7# cat /root/bootmsgs
FreeBSD 7.0:

Feb  6 06:34:57 bigby7 kernel: The Regents of the University of California. All rights reserved.
Feb  6 06:34:57 bigby7 kernel: FreeBSD is a registered trademark of The FreeBSD Foundation.
Feb  6 06:34:57 bigby7 kernel: FreeBSD 7.0-RELEASE #65: Tue Feb  3 12:54:34 EST 2009
Feb  6 06:34:57 bigby7 kernel: root@bigby7.localdomain.com:/usr/src/sys/i386/compile/DEBUG
Feb  6 06:34:57 bigby7 kernel: Timecounter "i8254" frequency 1193182 Hz quality 0
Feb  6 06:34:57 bigby7 kernel: CPU: Intel(R) Core(TM)2 Quad  CPU   Q9300  @ 2.50GHz (2493.76-MHz 686-class CPU)
Feb  6 06:34:57 bigby7 kernel: Origin = "GenuineIntel"  Id = 0x10677  Stepping = 7
Feb  6 06:34:57 bigby7 kernel: 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>
Feb  6 06:34:57 bigby7 kernel: Features2=0x8e3fd<SSE3,RSVD2,MON,DS_CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,<b19>>
Feb  6 06:34:57 bigby7 kernel: AMD Features=0x20100000<NX,LM>
Feb  6 06:34:57 bigby7 kernel: AMD Features2=0x1<LAHF>
Feb  6 06:34:57 bigby7 kernel: Cores per package: 4
Feb  6 06:34:57 bigby7 kernel: real memory  = 1072103424 (1022 MB)
Feb  6 06:34:57 bigby7 kernel: avail memory = 1039724544 (991 MB)
Feb  6 06:34:57 bigby7 kernel: ACPI APIC Table: <PTLTD  	 APIC  >
Feb  6 06:34:57 bigby7 kernel: FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs
Feb  6 06:34:57 bigby7 kernel: cpu0 (BSP): APIC ID:  0
Feb  6 06:34:57 bigby7 kernel: cpu1 (AP): APIC ID:  1
Feb  6 06:34:57 bigby7 kernel: cpu2 (AP): APIC ID:  2
Feb  6 06:34:57 bigby7 kernel: cpu3 (AP): APIC ID:  3
Feb  6 06:34:57 bigby7 kernel: ioapic0 <Version 2.0> irqs 0-23 on motherboard
Feb  6 06:34:57 bigby7 kernel: ioapic1 <Version 2.0> irqs 24-47 on motherboard
Feb  6 06:34:57 bigby7 kernel: kbd1 at kbdmux0
Feb  6 06:34:57 bigby7 kernel: acpi0: <PTLTD 	 XSDT> on motherboard
Feb  6 06:34:57 bigby7 kernel: acpi0: [ITHREAD]
Feb  6 06:34:57 bigby7 kernel: acpi0: Power Button (fixed)
Feb  6 06:34:57 bigby7 kernel: Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000
Feb  6 06:34:57 bigby7 kernel: acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1008-0x100b on acpi0
Feb  6 06:34:57 bigby7 kernel: cpu0: <ACPI CPU> on acpi0
Feb  6 06:34:57 bigby7 kernel: est0: <Enhanced SpeedStep Frequency Control> on cpu0
Feb  6 06:34:57 bigby7 kernel: p4tcc0: <CPU Frequency Thermal Control> on cpu0
Feb  6 06:34:57 bigby7 kernel: cpu1: <ACPI CPU> on acpi0
Feb  6 06:34:57 bigby7 kernel: est1: <Enhanced SpeedStep Frequency Control> on cpu1
Feb  6 06:34:57 bigby7 kernel: p4tcc1: <CPU Frequency Thermal Control> on cpu1
Feb  6 06:34:57 bigby7 kernel: cpu2: <ACPI CPU> on acpi0
Feb  6 06:34:57 bigby7 kernel: est2: <Enhanced SpeedStep Frequency Control> on cpu2
Feb  6 06:34:57 bigby7 kernel: p4tcc2: <CPU Frequency Thermal Control> on cpu2
Feb  6 06:34:57 bigby7 kernel: cpu3: <ACPI CPU> on acpi0
Feb  6 06:34:57 bigby7 kernel: est3: <Enhanced SpeedStep Frequency Control> on cpu3
Feb  6 06:34:57 bigby7 kernel: p4tcc3: <CPU Frequency Thermal Control> on cpu3
Feb  6 06:34:57 bigby7 kernel: pcib0: <ACPI Host-PCI bridge> port 0xcf8-0xcff on acpi0
Feb  6 06:34:57 bigby7 kernel: pci0: <ACPI PCI bus> on pcib0
Feb  6 06:34:57 bigby7 kernel: pcib1: <ACPI PCI-PCI bridge> irq 16 at device 1.0 on pci0
Feb  6 06:34:57 bigby7 kernel: pci1: <ACPI PCI bus> on pcib1
Feb  6 06:34:57 bigby7 kernel: pcib2: <ACPI PCI-PCI bridge> at device 0.0 on pci1
Feb  6 06:34:57 bigby7 kernel: pci2: <ACPI PCI bus> on pcib2
Feb  6 06:34:57 bigby7 kernel: pci2: <network, ethernet> at device 2.0 (no driver attached)
Feb  6 06:34:57 bigby7 kernel: pci2: <network, ethernet> at device 2.1 (no driver attached)
Feb  6 06:34:57 bigby7 kernel: uhci0: <UHCI (generic) USB controller> port 0x1820-0x183f irq 16 at device 26.0 on pci0
Feb  6 06:34:57 bigby7 kernel: uhci0: [GIANT-LOCKED]
Feb  6 06:34:57 bigby7 kernel: uhci0: [ITHREAD]
Feb  6 06:34:57 bigby7 kernel: usb0: <UHCI (generic) USB controller> on uhci0
Feb  6 06:34:57 bigby7 kernel: usb0: USB revision 1.0
Feb  6 06:34:57 bigby7 kernel: uhub0: <Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1> on usb0
Feb  6 06:34:57 bigby7 kernel: uhub0: 2 ports with 2 removable, self powered
Feb  6 06:34:57 bigby7 kernel: uhci1: <UHCI (generic) USB controller> port 0x1840-0x185f irq 17 at device 26.1 on pci0
Feb  6 06:34:57 bigby7 kernel: uhci1: [GIANT-LOCKED]
Feb  6 06:34:57 bigby7 kernel: uhci1: [ITHREAD]
Feb  6 06:34:57 bigby7 kernel: usb1: <UHCI (generic) USB controller> on uhci1
Feb  6 06:34:57 bigby7 kernel: usb1: USB revision 1.0
Feb  6 06:34:57 bigby7 kernel: uhub1: <Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1> on usb1
Feb  6 06:34:57 bigby7 kernel: uhub1: 2 ports with 2 removable, self powered
Feb  6 06:34:57 bigby7 kernel: uhci2: <UHCI (generic) USB controller> port 0x1860-0x187f irq 18 at device 26.2 on pci0
Feb  6 06:34:57 bigby7 kernel: uhci2: [GIANT-LOCKED]
Feb  6 06:34:57 bigby7 kernel: uhci2: [ITHREAD]
Feb  6 06:34:57 bigby7 kernel: usb2: <UHCI (generic) USB controller> on uhci2
Feb  6 06:34:57 bigby7 kernel: usb2: USB revision 1.0
Feb  6 06:34:57 bigby7 kernel: uhub2: <Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1> on usb2
Feb  6 06:34:57 bigby7 kernel: uhub2: 2 ports with 2 removable, self powered
Feb  6 06:34:57 bigby7 kernel: ehci0: <EHCI (generic) USB 2.0 controller> mem 0xd8701800-0xd8701bff irq 18 at device 26.7 on pci0
Feb  6 06:34:57 bigby7 kernel: ehci0: [GIANT-LOCKED]
Feb  6 06:34:57 bigby7 kernel: ehci0: [ITHREAD]
Feb  6 06:34:57 bigby7 kernel: usb3: EHCI version 1.0
Feb  6 06:34:57 bigby7 kernel: usb3: companion controllers, 2 ports each: usb0 usb1 usb2
Feb  6 06:34:57 bigby7 kernel: usb3: <EHCI (generic) USB 2.0 controller> on ehci0
Feb  6 06:34:57 bigby7 kernel: usb3: USB revision 2.0
Feb  6 06:34:57 bigby7 kernel: uhub3: <Intel EHCI root hub, class 9/0, rev 2.00/1.00, addr 1> on usb3
Feb  6 06:34:57 bigby7 kernel: uhub3: 6 ports with 6 removable, self powered
Feb  6 06:34:57 bigby7 kernel: uhub4: <Apple, Inc. Keyboard Hub, class 9/0, rev 2.00/96.15, addr 2> on uhub3
Feb  6 06:34:57 bigby7 kernel: uhub4: single transaction translator
Feb  6 06:34:57 bigby7 kernel: uhub4: 3 ports with 2 removable, bus powered
Feb  6 06:34:57 bigby7 kernel: ukbd0: <Apple, Inc Apple Keyboard, class 0/0, rev 2.00/0.67, addr 3> on uhub4
Feb  6 06:34:57 bigby7 kernel: kbd2 at ukbd0
Feb  6 06:34:57 bigby7 kernel: pcib3: <ACPI PCI-PCI bridge> irq 16 at device 28.0 on pci0
Feb  6 06:34:57 bigby7 kernel: pci5: <ACPI PCI bus> on pcib3
Feb  6 06:34:57 bigby7 kernel: pcib4: <ACPI PCI-PCI bridge> irq 16 at device 28.4 on pci0
Feb  6 06:34:57 bigby7 kernel: pci13: <ACPI PCI bus> on pcib4
Feb  6 06:34:57 bigby7 kernel: pci13: <network, ethernet> at device 0.0 (no driver attached)
Feb  6 06:34:57 bigby7 kernel: pcib5: <ACPI PCI-PCI bridge> irq 17 at device 28.5 on pci0
Feb  6 06:34:57 bigby7 kernel: pci15: <ACPI PCI bus> on pcib5
Feb  6 06:34:57 bigby7 kernel: pci15: <network, ethernet> at device 0.0 (no driver attached)
Feb  6 06:34:57 bigby7 kernel: uhci3: <UHCI (generic) USB controller> port 0x1880-0x189f irq 23 at device 29.0 on pci0
Feb  6 06:34:57 bigby7 kernel: uhci3: [GIANT-LOCKED]
Feb  6 06:34:57 bigby7 kernel: uhci3: [ITHREAD]
Feb  6 06:34:57 bigby7 kernel: usb4: <UHCI (generic) USB controller> on uhci3
Feb  6 06:34:57 bigby7 kernel: usb4: USB revision 1.0
Feb  6 06:34:57 bigby7 kernel: uhub5: <Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1> on usb4
Feb  6 06:34:57 bigby7 kernel: uhub5: 2 ports with 2 removable, self powered
Feb  6 06:34:57 bigby7 kernel: uhci4: <UHCI (generic) USB controller> port 0x18a0-0x18bf irq 22 at device 29.1 on pci0
Feb  6 06:34:57 bigby7 kernel: uhci4: [GIANT-LOCKED]
Feb  6 06:34:57 bigby7 kernel: uhci4: [ITHREAD]
Feb  6 06:34:57 bigby7 kernel: usb5: <UHCI (generic) USB controller> on uhci4
Feb  6 06:34:57 bigby7 kernel: usb5: USB revision 1.0
Feb  6 06:34:57 bigby7 kernel: uhub6: <Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1> on usb5
Feb  6 06:34:57 bigby7 kernel: uhub6: 2 ports with 2 removable, self powered
Feb  6 06:34:57 bigby7 kernel: uhci5: <UHCI (generic) USB controller> port 0x18c0-0x18df irq 18 at device 29.2 on pci0
Feb  6 06:34:57 bigby7 kernel: uhci5: [GIANT-LOCKED]
Feb  6 06:34:57 bigby7 kernel: uhci5: [ITHREAD]
Feb  6 06:34:57 bigby7 kernel: usb6: <UHCI (generic) USB controller> on uhci5
Feb  6 06:34:57 bigby7 kernel: usb6: USB revision 1.0
Feb  6 06:34:57 bigby7 kernel: uhub7: <Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1> on usb6
Feb  6 06:34:57 bigby7 kernel: uhub7: 2 ports with 2 removable, self powered
Feb  6 06:34:57 bigby7 kernel: ehci1: <EHCI (generic) USB 2.0 controller> mem 0xd8701c00-0xd8701fff irq 23 at device 29.7 on pci0
Feb  6 06:34:57 bigby7 kernel: ehci1: [GIANT-LOCKED]
Feb  6 06:34:57 bigby7 kernel: ehci1: [ITHREAD]
Feb  6 06:34:57 bigby7 kernel: usb7: EHCI version 1.0
Feb  6 06:34:57 bigby7 kernel: usb7: companion controllers, 2 ports each: usb4 usb5 usb6
Feb  6 06:34:57 bigby7 kernel: usb7: <EHCI (generic) USB 2.0 controller> on ehci1
Feb  6 06:34:57 bigby7 kernel: usb7: USB revision 2.0
Feb  6 06:34:57 bigby7 kernel: uhub8: <Intel EHCI root hub, class 9/0, rev 2.00/1.00, addr 1> on usb7
Feb  6 06:34:57 bigby7 kernel: uhub8: 6 ports with 6 removable, self powered
Feb  6 06:34:57 bigby7 kernel: pcib6: <ACPI PCI-PCI bridge> at device 30.0 on pci0
Feb  6 06:34:57 bigby7 kernel: pci17: <ACPI PCI bus> on pcib6
Feb  6 06:34:57 bigby7 kernel: vgapci0: <VGA-compatible display> port 0x5000-0x50ff mem 0xd0000000-0xd7ffffff,0xd8400000-0xd840ffff irq 22 at device 3.0 on pci17
Feb  6 06:34:57 bigby7 kernel: atapci0: <ITE IT8213F UDMA33 controller> port 0x5420-0x5427,0x5414-0x5417,0x5418-0x541f,0x5410-0x5413,0x5400-0x540f irq 23 at device 4.0 on pci17
Feb  6 06:34:57 bigby7 kernel: atapci0: [ITHREAD]
Feb  6 06:34:57 bigby7 kernel: ata2: <ATA channel 0> on atapci0
Feb  6 06:34:57 bigby7 kernel: ata2: [ITHREAD]
Feb  6 06:34:57 bigby7 kernel: ata3: <ATA channel 1> on atapci0
Feb  6 06:34:57 bigby7 kernel: ata3: [ITHREAD]
Feb  6 06:34:57 bigby7 kernel: isab0: <PCI-ISA bridge> at device 31.0 on pci0
Feb  6 06:34:57 bigby7 kernel: isa0: <ISA bus> on isab0
Feb  6 06:34:57 bigby7 kernel: atapci1: <Intel AHCI controller> port 0x1c30-0x1c37,0x1c24-0x1c27,0x1c28-0x1c2f,0x1c20-0x1c23,0x18e0-0x18ff mem 0xd8701000-0xd87017ff irq 17 at device 31.2 on pci0
Feb  6 06:34:57 bigby7 kernel: atapci1: [ITHREAD]
Feb  6 06:34:57 bigby7 kernel: atapci1: AHCI Version 01.20 controller with 4 ports detected
Feb  6 06:34:57 bigby7 kernel: ata4: <ATA channel 0> on atapci1
Feb  6 06:34:57 bigby7 kernel: ata4: [ITHREAD]
Feb  6 06:34:57 bigby7 kernel: ata5: <ATA channel 1> on atapci1
Feb  6 06:34:57 bigby7 kernel: ata5: port not implemented
Feb  6 06:34:57 bigby7 kernel: ata5: [ITHREAD]
Feb  6 06:34:57 bigby7 kernel: ata6: <ATA channel 2> on atapci1
Feb  6 06:34:57 bigby7 kernel: ata6: port not implemented
Feb  6 06:34:57 bigby7 kernel: ata6: [ITHREAD]
Feb  6 06:34:57 bigby7 kernel: ata7: <ATA channel 3> on atapci1
Feb  6 06:34:57 bigby7 kernel: ata7: port not implemented
Feb  6 06:34:57 bigby7 kernel: ata7: [ITHREAD]
Feb  6 06:34:57 bigby7 kernel: pci0: <serial bus, SMBus> at device 31.3 (no driver attached)
Feb  6 06:34:57 bigby7 kernel: pci0: <dasp> at device 31.6 (no driver attached)
Feb  6 06:34:57 bigby7 kernel: acpi_button0: <Power Button> on acpi0
Feb  6 06:34:57 bigby7 kernel: atkbdc0: <Keyboard controller (i8042)> port 0x60,0x64 irq 1 on acpi0
Feb  6 06:34:57 bigby7 kernel: atkbd0: <AT Keyboard> irq 1 on atkbdc0
Feb  6 06:34:57 bigby7 kernel: kbd0 at atkbd0
Feb  6 06:34:57 bigby7 kernel: atkbd0: [GIANT-LOCKED]
Feb  6 06:34:57 bigby7 kernel: atkbd0: [ITHREAD]
Feb  6 06:34:57 bigby7 kernel: sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0
Feb  6 06:34:57 bigby7 kernel: sio0: type 16550A
Feb  6 06:34:57 bigby7 kernel: sio0: [FILTER]
Feb  6 06:34:57 bigby7 kernel: sio1: <16550A-compatible COM port> port 0x2f8-0x2ff irq 3 on acpi0
Feb  6 06:34:57 bigby7 kernel: sio1: type 16550A
Feb  6 06:34:57 bigby7 kernel: sio1: [FILTER]
Feb  6 06:34:57 bigby7 kernel: fdc0: <floppy drive controller> port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on acpi0
Feb  6 06:34:57 bigby7 kernel: fdc0: [FILTER]
Feb  6 06:34:57 bigby7 kernel: em0: <Intel(R) PRO/1000 Network Connection 6.9.5> port 0x3000-0x301f mem 0xd8200000-0xd821ffff irq 16 at device 0.0 on pci13
Feb  6 06:34:57 bigby7 kernel: em0: Using MSI interrupt
Feb  6 06:34:57 bigby7 kernel: em0: [FILTER]
Feb  6 06:34:57 bigby7 kernel: em0: Ethernet address: 00:30:48:64:ef:76
Feb  6 06:34:57 bigby7 kernel: em1: <Intel(R) PRO/1000 Network Connection 6.9.5> port 0x4000-0x401f mem 0xd8300000-0xd831ffff irq 17 at device 0.0 on pci15
Feb  6 06:34:57 bigby7 kernel: em1: Using MSI interrupt
Feb  6 06:34:57 bigby7 kernel: em1: [FILTER]
Feb  6 06:34:57 bigby7 kernel: em1: Ethernet address: 00:30:48:64:ef:77
Feb  6 06:34:57 bigby7 kernel: em2: <Intel(R) PRO/1000 Network Connection 6.9.5> port 0x2000-0x203f mem 0xd8000000-0xd801ffff irq 24 at device 2.0 on pci2
Feb  6 06:34:57 bigby7 kernel: em2: [FILTER]
Feb  6 06:34:57 bigby7 kernel: em2: Ethernet address: 00:e0:ed:09:24:de
Feb  6 06:34:57 bigby7 kernel: em3: <Intel(R) PRO/1000 Network Connection 6.9.5> port 0x2040-0x207f mem 0xd8020000-0xd803ffff irq 25 at device 2.1 on pci2
Feb  6 06:34:57 bigby7 kernel: em3: [FILTER]
Feb  6 06:34:57 bigby7 kernel: em3: Ethernet address: 00:e0:ed:09:24:df
Feb  6 06:34:57 bigby7 kernel: pmtimer0 on isa0
Feb  6 06:34:57 bigby7 kernel: orm0: <ISA Option ROM> at iomem 0xc0000-0xcafff pnpid ORM0000 on isa0
Feb  6 06:34:57 bigby7 kernel: ata0 at port 0x1f0-0x1f7,0x3f6 irq 14 on isa0
Feb  6 06:34:57 bigby7 kernel: ata0: [ITHREAD]
Feb  6 06:34:57 bigby7 kernel: ata1 at port 0x170-0x177,0x376 irq 15 on isa0
Feb  6 06:34:57 bigby7 kernel: ata1: [ITHREAD]
Feb  6 06:34:57 bigby7 kernel: sc0: <System console> at flags 0x100 on isa0
Feb  6 06:34:57 bigby7 kernel: sc0: VGA <16 virtual consoles, flags=0x300>
Feb  6 06:34:57 bigby7 kernel: vga0: <Generic ISA VGA> at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0
Feb  6 06:34:57 bigby7 kernel: Timecounters tick every 1.000 msec
Feb  6 06:34:57 bigby7 kernel: ipfw2 initialized, divert enabled, rule-based forwarding enabled, default to accept, logging disabled
Feb  6 06:34:57 bigby7 kernel: acd0: DVDROM <DVD-ROM UJDA780/1.50> at ata2-slave PIO4
Feb  6 06:34:57 bigby7 kernel: ad8: 76319MB <WDC WD800JD-00MSA1 10.01E01> at ata4-master SATA300
Feb  6 06:34:57 bigby7 kernel: SMP: AP CPU #1 Launched!
Feb  6 06:34:57 bigby7 kernel: SMP: AP CPU #2 Launched!
Feb  6 06:34:57 bigby7 kernel: SMP: AP CPU #3 Launched!
Feb  6 06:34:57 bigby7 kernel: Trying to mount root from ufs:/dev/ad8s1a


FreeBSD 8.0:

Feb  6 06:30:48 bigby7 syslogd: kernel boot file is /boot/kernel/kernel
Feb  6 06:30:48 bigby7 kernel: Copyright (c) 1992-2009 The FreeBSD Project.
Feb  6 06:30:48 bigby7 kernel: Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
Feb  6 06:30:48 bigby7 kernel: The Regents of the University of California. All rights reserved.
Feb  6 06:30:48 bigby7 kernel: FreeBSD is a registered trademark of The FreeBSD Foundation.
Feb  6 06:30:48 bigby7 kernel: FreeBSD 8.0-CURRENT #2: Thu Feb  5 16:24:57 EST 2009
Feb  6 06:30:48 bigby7 kernel: root@bigby7.localdomain.com:/usr/src/sys/i386/compile/DEBUG
Feb  6 06:30:48 bigby7 kernel: module_register: module pci/igb already exists!
Feb  6 06:30:48 bigby7 kernel: Module pci/igb failed to register: 17
Feb  6 06:30:48 bigby7 kernel: Timecounter "i8254" frequency 1193182 Hz quality 0
Feb  6 06:30:48 bigby7 kernel: CPU: Intel(R) Core(TM)2 Quad  CPU   Q9300  @ 2.50GHz (2493.77-MHz 686-class CPU)
Feb  6 06:30:48 bigby7 kernel: Origin = "GenuineIntel"  Id = 0x10677  Stepping = 7
Feb  6 06:30:48 bigby7 kernel: 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>
Feb  6 06:30:48 bigby7 kernel: Features2=0x8e3fd<SSE3,DTES64,MON,DS_CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1>
Feb  6 06:30:48 bigby7 kernel: AMD Features=0x20100000<NX,LM>
Feb  6 06:30:48 bigby7 kernel: AMD Features2=0x1<LAHF>
Feb  6 06:30:48 bigby7 kernel: TSC: P-state invariant
Feb  6 06:30:48 bigby7 kernel: Cores per package: 4
Feb  6 06:30:48 bigby7 kernel: real memory  = 1072103424 (1022 MB)
Feb  6 06:30:48 bigby7 kernel: avail memory = 1040199680 (992 MB)
Feb  6 06:30:48 bigby7 kernel: ACPI APIC Table: <PTLTD  	 APIC  >
Feb  6 06:30:48 bigby7 kernel: FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs
Feb  6 06:30:48 bigby7 kernel: cpu0 (BSP): APIC ID:  0
Feb  6 06:30:48 bigby7 kernel: cpu1 (AP): APIC ID:  1
Feb  6 06:30:48 bigby7 kernel: cpu2 (AP): APIC ID:  2
Feb  6 06:30:48 bigby7 kernel: cpu3 (AP): APIC ID:  3
Feb  6 06:30:48 bigby7 kernel: ioapic0 <Version 2.0> irqs 0-23 on motherboard
Feb  6 06:30:48 bigby7 kernel: ioapic1 <Version 2.0> irqs 24-47 on motherboard
Feb  6 06:30:48 bigby7 kernel: kbd1 at kbdmux0
Feb  6 06:30:48 bigby7 kernel: acpi0: <PTLTD 	 XSDT> on motherboard
Feb  6 06:30:48 bigby7 kernel: acpi0: [ITHREAD]
Feb  6 06:30:48 bigby7 kernel: acpi0: Power Button (fixed)
Feb  6 06:30:48 bigby7 kernel: Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000
Feb  6 06:30:48 bigby7 kernel: acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1008-0x100b on acpi0
Feb  6 06:30:48 bigby7 kernel: pcib0: <ACPI Host-PCI bridge> port 0xcf8-0xcff on acpi0
Feb  6 06:30:48 bigby7 kernel: pci0: <ACPI PCI bus> on pcib0
Feb  6 06:30:48 bigby7 kernel: pcib1: <ACPI PCI-PCI bridge> irq 16 at device 1.0 on pci0
Feb  6 06:30:48 bigby7 kernel: pci1: <ACPI PCI bus> on pcib1
Feb  6 06:30:48 bigby7 kernel: pcib2: <ACPI PCI-PCI bridge> at device 0.0 on pci1
Feb  6 06:30:48 bigby7 kernel: pci2: <ACPI PCI bus> on pcib2
Feb  6 06:30:48 bigby7 kernel: pci2: <network, ethernet> at device 2.0 (no driver attached)
Feb  6 06:30:48 bigby7 kernel: pci2: <network, ethernet> at device 2.1 (no driver attached)
Feb  6 06:30:48 bigby7 kernel: uhci0: <Intel 82801I (ICH9) USB controller> port 0x1820-0x183f irq 16 at device 26.0 on pci0
Feb  6 06:30:48 bigby7 kernel: uhci0: [GIANT-LOCKED]
Feb  6 06:30:48 bigby7 kernel: uhci0: [ITHREAD]
Feb  6 06:30:48 bigby7 kernel: usb0: <Intel 82801I (ICH9) USB controller> on uhci0
Feb  6 06:30:48 bigby7 kernel: usb0: USB revision 1.0
Feb  6 06:30:48 bigby7 kernel: uhub0: <Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1> on usb0
Feb  6 06:30:48 bigby7 kernel: uhub0: 2 ports with 2 removable, self powered
Feb  6 06:30:48 bigby7 kernel: uhci1: <Intel 82801I (ICH9) USB controller> port 0x1840-0x185f irq 17 at device 26.1 on pci0
Feb  6 06:30:48 bigby7 kernel: uhci1: [GIANT-LOCKED]
Feb  6 06:30:48 bigby7 kernel: uhci1: [ITHREAD]
Feb  6 06:30:48 bigby7 kernel: usb1: <Intel 82801I (ICH9) USB controller> on uhci1
Feb  6 06:30:48 bigby7 kernel: usb1: USB revision 1.0
Feb  6 06:30:48 bigby7 kernel: uhub1: <Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1> on usb1
Feb  6 06:30:48 bigby7 kernel: uhub1: 2 ports with 2 removable, self powered
Feb  6 06:30:48 bigby7 kernel: uhci2: <Intel 82801I (ICH9) USB controller> port 0x1860-0x187f irq 18 at device 26.2 on pci0
Feb  6 06:30:48 bigby7 kernel: uhci2: [GIANT-LOCKED]
Feb  6 06:30:48 bigby7 kernel: uhci2: [ITHREAD]
Feb  6 06:30:48 bigby7 kernel: usb2: <Intel 82801I (ICH9) USB controller> on uhci2
Feb  6 06:30:48 bigby7 kernel: usb2: USB revision 1.0
Feb  6 06:30:48 bigby7 kernel: uhub2: <Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1> on usb2
Feb  6 06:30:48 bigby7 kernel: uhub2: 2 ports with 2 removable, self powered
Feb  6 06:30:48 bigby7 kernel: ehci0: <Intel 82801I (ICH9) USB 2.0 controller> mem 0xd8701800-0xd8701bff irq 18 at device 26.7 on pci0
Feb  6 06:30:48 bigby7 kernel: ehci0: [GIANT-LOCKED]
Feb  6 06:30:48 bigby7 kernel: ehci0: [ITHREAD]
Feb  6 06:30:48 bigby7 kernel: usb3: EHCI version 1.0
Feb  6 06:30:48 bigby7 kernel: usb3: companion controllers, 2 ports each: usb0 usb1 usb2
Feb  6 06:30:48 bigby7 kernel: usb3: <Intel 82801I (ICH9) USB 2.0 controller> on ehci0
Feb  6 06:30:48 bigby7 kernel: usb3: USB revision 2.0
Feb  6 06:30:48 bigby7 kernel: uhub3: <Intel EHCI root hub, class 9/0, rev 2.00/1.00, addr 1> on usb3
Feb  6 06:30:48 bigby7 kernel: uhub3: 6 ports with 6 removable, self powered
Feb  6 06:30:48 bigby7 kernel: uhub4: <Apple, Inc. Keyboard Hub, class 9/0, rev 2.00/96.15, addr 2> on uhub3
Feb  6 06:30:48 bigby7 kernel: uhub4: single transaction translator
Feb  6 06:30:48 bigby7 kernel: uhub4: 3 ports with 2 removable, bus powered
Feb  6 06:30:48 bigby7 kernel: ukbd0: <Apple, Inc Apple Keyboard, class 0/0, rev 2.00/0.67, addr 3> on uhub4
Feb  6 06:30:48 bigby7 kernel: kbd2 at ukbd0
Feb  6 06:30:48 bigby7 kernel: pcib3: <ACPI PCI-PCI bridge> irq 16 at device 28.0 on pci0
Feb  6 06:30:48 bigby7 kernel: pci5: <ACPI PCI bus> on pcib3
Feb  6 06:30:48 bigby7 kernel: pcib4: <ACPI PCI-PCI bridge> irq 16 at device 28.4 on pci0
Feb  6 06:30:48 bigby7 kernel: pci13: <ACPI PCI bus> on pcib4
Feb  6 06:30:48 bigby7 kernel: em0: <Intel(R) PRO/1000 Network Connection 6.9.6> port 0x3000-0x301f mem 0xd8200000-0xd821ffff irq 16 at device 0.0 on pci13
Feb  6 06:30:48 bigby7 kernel: em0: Using MSI interrupt
Feb  6 06:30:48 bigby7 kernel: em0: [FILTER]
Feb  6 06:30:48 bigby7 kernel: em0: Ethernet address: 00:30:48:64:ef:76
Feb  6 06:30:48 bigby7 kernel: pcib5: <ACPI PCI-PCI bridge> irq 17 at device 28.5 on pci0
Feb  6 06:30:48 bigby7 kernel: pci15: <ACPI PCI bus> on pcib5
Feb  6 06:30:48 bigby7 kernel: em1: <Intel(R) PRO/1000 Network Connection 6.9.6> port 0x4000-0x401f mem 0xd8300000-0xd831ffff irq 17 at device 0.0 on pci15
Feb  6 06:30:48 bigby7 kernel: em1: Using MSI interrupt
Feb  6 06:30:48 bigby7 kernel: em1: [FILTER]
Feb  6 06:30:48 bigby7 kernel: em1: Ethernet address: 00:30:48:64:ef:77
Feb  6 06:30:48 bigby7 kernel: uhci3: <Intel 82801I (ICH9) USB controller> port 0x1880-0x189f irq 23 at device 29.0 on pci0
Feb  6 06:30:48 bigby7 kernel: uhci3: [GIANT-LOCKED]
Feb  6 06:30:48 bigby7 kernel: uhci3: [ITHREAD]
Feb  6 06:30:48 bigby7 kernel: usb4: <Intel 82801I (ICH9) USB controller> on uhci3
Feb  6 06:30:48 bigby7 kernel: usb4: USB revision 1.0
Feb  6 06:30:48 bigby7 kernel: uhub5: <Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1> on usb4
Feb  6 06:30:48 bigby7 kernel: uhub5: 2 ports with 2 removable, self powered
Feb  6 06:30:48 bigby7 kernel: uhci4: <Intel 82801I (ICH9) USB controller> port 0x18a0-0x18bf irq 22 at device 29.1 on pci0
Feb  6 06:30:48 bigby7 kernel: uhci4: [GIANT-LOCKED]
Feb  6 06:30:48 bigby7 kernel: uhci4: [ITHREAD]
Feb  6 06:30:48 bigby7 kernel: usb5: <Intel 82801I (ICH9) USB controller> on uhci4
Feb  6 06:30:48 bigby7 kernel: usb5: USB revision 1.0
Feb  6 06:30:48 bigby7 kernel: uhub6: <Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1> on usb5
Feb  6 06:30:48 bigby7 kernel: uhub6: 2 ports with 2 removable, self powered
Feb  6 06:30:48 bigby7 kernel: uhci5: <Intel 82801I (ICH9) USB controller> port 0x18c0-0x18df irq 18 at device 29.2 on pci0
Feb  6 06:30:48 bigby7 kernel: uhci5: [GIANT-LOCKED]
Feb  6 06:30:48 bigby7 kernel: uhci5: [ITHREAD]
Feb  6 06:30:48 bigby7 kernel: usb6: <Intel 82801I (ICH9) USB controller> on uhci5
Feb  6 06:30:48 bigby7 kernel: usb6: USB revision 1.0
Feb  6 06:30:48 bigby7 kernel: uhub7: <Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1> on usb6
Feb  6 06:30:48 bigby7 kernel: uhub7: 2 ports with 2 removable, self powered
Feb  6 06:30:48 bigby7 kernel: ehci1: <Intel 82801I (ICH9) USB 2.0 controller> mem 0xd8701c00-0xd8701fff irq 23 at device 29.7 on pci0
Feb  6 06:30:48 bigby7 kernel: ehci1: [GIANT-LOCKED]
Feb  6 06:30:48 bigby7 kernel: ehci1: [ITHREAD]
Feb  6 06:30:48 bigby7 kernel: usb7: EHCI version 1.0
Feb  6 06:30:48 bigby7 kernel: usb7: companion controllers, 2 ports each: usb4 usb5 usb6
Feb  6 06:30:48 bigby7 kernel: usb7: <Intel 82801I (ICH9) USB 2.0 controller> on ehci1
Feb  6 06:30:48 bigby7 kernel: usb7: USB revision 2.0
Feb  6 06:30:48 bigby7 kernel: uhub8: <Intel EHCI root hub, class 9/0, rev 2.00/1.00, addr 1> on usb7
Feb  6 06:30:48 bigby7 kernel: uhub8: 6 ports with 6 removable, self powered
Feb  6 06:30:48 bigby7 kernel: pcib6: <ACPI PCI-PCI bridge> at device 30.0 on pci0
Feb  6 06:30:48 bigby7 kernel: pci17: <ACPI PCI bus> on pcib6
Feb  6 06:30:48 bigby7 kernel: isab0: <PCI-ISA bridge> at device 31.0 on pci0
Feb  6 06:30:48 bigby7 kernel: isa0: <ISA bus> on isab0
Feb  6 06:30:48 bigby7 kernel: atapci0: <Intel AHCI controller> port 0x1c30-0x1c37,0x1c24-0x1c27,0x1c28-0x1c2f,0x1c20-0x1c23,0x18e0-0x18ff mem 0xd8701000-0xd87017ff irq 17 at device 31.2 on pci0
Feb  6 06:30:48 bigby7 kernel: atapci0: [ITHREAD]
Feb  6 06:30:48 bigby7 kernel: atapci0: AHCI Version 01.20 controller with 4 ports PM supported
Feb  6 06:30:48 bigby7 kernel: ata2: <ATA channel 0> on atapci0
Feb  6 06:30:48 bigby7 kernel: ata2: executing CLO failed
Feb  6 06:30:48 bigby7 kernel: ata2: [ITHREAD]
Feb  6 06:30:48 bigby7 kernel: ata3: <ATA channel 1> on atapci0
Feb  6 06:30:48 bigby7 kernel: ata3: port not implemented
Feb  6 06:30:48 bigby7 kernel: ata3: [ITHREAD]
Feb  6 06:30:48 bigby7 kernel: ata4: <ATA channel 2> on atapci0
Feb  6 06:30:48 bigby7 kernel: ata4: port not implemented
Feb  6 06:30:48 bigby7 kernel: ata4: [ITHREAD]
Feb  6 06:30:48 bigby7 kernel: ata5: <ATA channel 3> on atapci0
Feb  6 06:30:48 bigby7 kernel: ata5: port not implemented
Feb  6 06:30:48 bigby7 kernel: ata5: [ITHREAD]
Feb  6 06:30:48 bigby7 kernel: pci0: <serial bus, SMBus> at device 31.3 (no driver attached)
Feb  6 06:30:48 bigby7 kernel: pci0: <dasp> at device 31.6 (no driver attached)
Feb  6 06:30:48 bigby7 kernel: acpi_button0: <Power Button> on acpi0
Feb  6 06:30:48 bigby7 kernel: atrtc0: <AT realtime clock> port 0x70-0x71 irq 8 on acpi0
Feb  6 06:30:48 bigby7 kernel: atkbdc0: <Keyboard controller (i8042)> port 0x60,0x64 irq 1 on acpi0
Feb  6 06:30:48 bigby7 kernel: atkbd0: <AT Keyboard> irq 1 on atkbdc0
Feb  6 06:30:48 bigby7 kernel: kbd0 at atkbd0
Feb  6 06:30:48 bigby7 kernel: atkbd0: [GIANT-LOCKED]
Feb  6 06:30:48 bigby7 kernel: atkbd0: [ITHREAD]
Feb  6 06:30:48 bigby7 kernel: fdc0: <floppy drive controller> port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on acpi0
Feb  6 06:30:48 bigby7 kernel: fdc0: [FILTER]
Feb  6 06:30:48 bigby7 kernel: cpu0: <ACPI CPU> on acpi0
Feb  6 06:30:48 bigby7 kernel: est0: <Enhanced SpeedStep Frequency Control> on cpu0
Feb  6 06:30:48 bigby7 kernel: p4tcc0: <CPU Frequency Thermal Control> on cpu0
Feb  6 06:30:48 bigby7 kernel: cpu1: <ACPI CPU> on acpi0
Feb  6 06:30:48 bigby7 kernel: est1: <Enhanced SpeedStep Frequency Control> on cpu1
Feb  6 06:30:48 bigby7 kernel: p4tcc1: <CPU Frequency Thermal Control> on cpu1
Feb  6 06:30:48 bigby7 kernel: cpu2: <ACPI CPU> on acpi0
Feb  6 06:30:48 bigby7 kernel: est2: <Enhanced SpeedStep Frequency Control> on cpu2
Feb  6 06:30:48 bigby7 kernel: p4tcc2: <CPU Frequency Thermal Control> on cpu2
Feb  6 06:30:48 bigby7 kernel: cpu3: <ACPI CPU> on acpi0
Feb  6 06:30:48 bigby7 kernel: est3: <Enhanced SpeedStep Frequency Control> on cpu3
Feb  6 06:30:48 bigby7 kernel: p4tcc3: <CPU Frequency Thermal Control> on cpu3
Feb  6 06:30:48 bigby7 kernel: pmtimer0 on isa0
Feb  6 06:30:48 bigby7 kernel: orm0: <ISA Option ROM> at iomem 0xc0000-0xcafff pnpid ORM0000 on isa0
Feb  6 06:30:48 bigby7 kernel: sc0: <System console> at flags 0x100 on isa0
Feb  6 06:30:48 bigby7 kernel: sc0: VGA <16 virtual consoles, flags=0x300>
Feb  6 06:30:48 bigby7 kernel: vga0: <Generic ISA VGA> at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0
Feb  6 06:30:48 bigby7 kernel: ata0 at port 0x1f0-0x1f7,0x3f6 irq 14 on isa0
Feb  6 06:30:48 bigby7 kernel: ata0: [ITHREAD]
Feb  6 06:30:48 bigby7 kernel: ata1 at port 0x170-0x177,0x376 irq 15 on isa0
Feb  6 06:30:48 bigby7 kernel: ata1: [ITHREAD]
Feb  6 06:30:48 bigby7 kernel: Timecounters tick every 1.000 msec
Feb  6 06:30:48 bigby7 kernel: ipfw2 initialized, divert enabled, nat loadable, rule-based forwarding enabled, default to accept, logging disabled
Feb  6 06:30:48 bigby7 kernel: ad4: 76319MB <WDC WD800JD-00MSA1 10.01E01> at ata2-master SATA300
Feb  6 06:30:48 bigby7 kernel: SMP: AP CPU #1 Launched!
Feb  6 06:30:48 bigby7 kernel: SMP: AP CPU #2 Launched!
Feb  6 06:30:48 bigby7 kernel: SMP: AP CPU #3 Launched!
Feb  6 06:30:48 bigby7 kernel: Trying to mount root from ufs:/dev/ad4s1a





      
From c47g at gmx.at  Fri Feb  6 04:43:32 2009
From: c47g at gmx.at (Christian Gusenbauer)
Date: Fri Feb  6 04:43:40 2009
Subject: lpt stopped working
In-Reply-To: <200902052203.37792.beech@freebsd.org>
References: <200902021643.39862.c47g@gmx.at>
	<200902040914.10330.jhb@freebsd.org>
	<200902052203.37792.beech@freebsd.org>
Message-ID: <200902061343.50224.c47g@gmx.at>

Hi John!

Sorry, it seems that I missed your previous mail, so my answer comes here 
right now.

On Friday 06 February 2009, Beech Rintoul wrote:
> On Wednesday 04 February 2009 05:14:10 John Baldwin wrote:
> > On Monday 02 February 2009 10:43:39 am Christian Gusenbauer wrote:
> > > Hi!
> > >
> > > Since the recent update (svn r187576) to the ppbus/ppc code my printer
> >
> > stopped
> >
> > > working. Every request seems to hang forever in ppb_request_bus waiting
> > > for ppb->ppc_lock (at least 'top' tells me that it's hanging in state
> > > 'ppbreq').
> >
> > Can you use procstat to get a stack trace of the hung thread?

# procstat -k 1199
  PID    TID COMM             TDNAME           KSTACK
 1199 100184 cat              -                mi_switch sleepq_switch 
sleepq_catch_signals sleepq_wait_sig _sleep ppb_request_bus lpt_request_ppbus 
lptwrite devfs_write_f dofilewrite kern_writev write syscall Xint0x80_syscall

Christian.


>
> My printer is still showing "device busy" for lpt0 does anyone know offhand
> when the changes were committed? I need to revert.
>
> Beech


From froloff at ukr.net  Fri Feb  6 04:52:39 2009
From: froloff at ukr.net (Yury Froloff)
Date: Fri Feb  6 04:59:29 2009
Subject: To Alexander Motin aka Mav. HDA problems.
Message-ID: <E1LVPtT-000Dej-44@ffe11.ukr.net>

????????????, ?????????!  
  
? ???? ???????? ?? ?????? ? ????? ?? ???? ?? ??????. ????? ???????? ???, ?.?. ??? ??????? ???? ???????? ? ?? ???? ??? ????????.  
????? ?????? ???. ????????, ??????????, ???????????. ?? - ??? ????????? ???????.  
===================================================  
  private# uname -a  
FreeBSD private.org 7.0-RELEASE FreeBSD 7.0-RELEASE #0: Sat Jan 31 11:21:07 EET 2009???? root@private.org:/usr/obj/usr/src/sys/NEWKERN? amd64  
===================================================  
  private# cat /dev/sndstat  
FreeBSD Audio Driver (newpcm: 64bit 2007061600/amd64)  
Installed devices:  
pcm0: <ATI SB600 High Definition Audio Controller> at memory 0xfe020000 irq 16 kld snd_hda [20071129_0050] [MPSAFE] (1p:1v/1r:1v channels duplex default)  
===================================================  
? ?????????,  
?????? ????.  
  
From c47g at gmx.at  Fri Feb  6 05:13:34 2009
From: c47g at gmx.at (Christian Gusenbauer)
Date: Fri Feb  6 05:13:41 2009
Subject: CFT: Graphics support for /boot/loader
In-Reply-To: <200902060925.n169PObG053288@lurza.secnetix.de>
References: <200902060925.n169PObG053288@lurza.secnetix.de>
Message-ID: <200902061413.53508.c47g@gmx.at>

Hi Oliver!

On Friday 06 February 2009, Oliver Fromme wrote:
> Danny Braniss wrote:
>  > just tried it via pxe:
>  >
>  > panic: free: guard1 @ 0x7f3a4aec from /usr/src/lib/libstand/close.c:79
>  >
>  > what changes are needed in pxeboot?
>
> The panic message means that the heap memory was corruped.
> It could be caused by a buffer overflow or similar.
> I'll try to look into it.

I got this some years ago when I played with FreeBSD 6.1. It has something to 
do with reading/parsing the loader.conf file. Inserting some dummy lines 
(comments etc.) into loader.conf solves it (at least that's a workaround). As 
I've never seen it again since 6.1 I thought it has already been fixed :-(.

Christian.

>
> When does that message appear?  Could you provide a screen
> shot?
>
> Best regards
>    Oliver


From olli at lurza.secnetix.de  Fri Feb  6 05:35:26 2009
From: olli at lurza.secnetix.de (Oliver Fromme)
Date: Fri Feb  6 05:35:40 2009
Subject: CFT: Graphics support for /boot/loader
In-Reply-To: <747dc8f30902060330l33fb0bbo489dc4fe3009747a@mail.gmail.com>
Message-ID: <200902061335.n16DZNA9063755@lurza.secnetix.de>

Renato Botelho wrote:
 > It worked here, on a 8.0-current i386 r188003, the only small
 > thing is it show a red border when show the menu.

Do you mean a red line at the top right corner?
That problem has already been reported and fixed
in my local source tree.

 > There is a dmidecode output attached, just to give you some
 > information about the bios.

Thanks!

Best regards
   Oliver

-- 
Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M.
Handelsregister: Registergericht Muenchen, HRA 74606,  Gesch?ftsfuehrung:
secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht M?n-
chen, HRB 125758,  Gesch?ftsf?hrer: Maik Bachmann, Olaf Erb, Ralf Gebhart

FreeBSD-Dienstleistungen, -Produkte und mehr:  http://www.secnetix.de/bsd

"If you aim the gun at your foot and pull the trigger, it's
UNIX's job to ensure reliable delivery of the bullet to
where you aimed the gun (in this case, Mr. Foot)."
        -- Terry Lambert, FreeBSD-hackers mailing list.
From olli at lurza.secnetix.de  Fri Feb  6 06:13:54 2009
From: olli at lurza.secnetix.de (Oliver Fromme)
Date: Fri Feb  6 06:14:01 2009
Subject: CFT: Graphics support for /boot/loader
In-Reply-To: <200902061413.53508.c47g@gmx.at>
Message-ID: <200902061413.n16EDgii065856@lurza.secnetix.de>


Christian Gusenbauer wrote:
 > Oliver Fromme wrote:
 > > Danny Braniss wrote:
 > > > just tried it via pxe:
 > > > 
 > > > panic: free: guard1 @ 0x7f3a4aec from /usr/src/lib/libstand/close.c:79
 > > > 
 > > > what changes are needed in pxeboot?
 > > 
 > > The panic message means that the heap memory was corruped.
 > > It could be caused by a buffer overflow or similar.
 > > I'll try to look into it.
 > 
 > I got this some years ago when I played with FreeBSD 6.1. It has something to 
 > do with reading/parsing the loader.conf file. Inserting some dummy lines 
 > (comments etc.) into loader.conf solves it (at least that's a workaround). As 
 > I've never seen it again since 6.1 I thought it has already been fixed :-(.

I think that's unrelated.  That guard panic just means
that the program has written beyond the memory that was
allocated.

Unfortunately it is difficult to find the piece of code
responsible for that behaviour (especially when I can't
reproduce the problem myself because I don't have a PXE-
capable machine).  It could be almost anywhere.

In fact, the bug doesn't even have to be in the C code:
FORTH supports (and even encourages) pointer arithmetic,
too.  This is real fun ...

Best regards
   Oliver

-- 
Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M.
Handelsregister: Registergericht Muenchen, HRA 74606,  Gesch?ftsfuehrung:
secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht M?n-
chen, HRB 125758,  Gesch?ftsf?hrer: Maik Bachmann, Olaf Erb, Ralf Gebhart

FreeBSD-Dienstleistungen, -Produkte und mehr:  http://www.secnetix.de/bsd

"Unix gives you just enough rope to hang yourself --
and then a couple of more feet, just to be sure."
        -- Eric Allman
From smrad01 at gmail.com  Fri Feb  6 06:19:53 2009
From: smrad01 at gmail.com (blah)
Date: Fri Feb  6 06:20:00 2009
Subject: To Alexander Motin aka Mav. HDA problems.
In-Reply-To: <E1LVPtT-000Dej-44@ffe11.ukr.net>
References: <E1LVPtT-000Dej-44@ffe11.ukr.net>
Message-ID: <498C4638.20500@gmail.com>

Yury Froloff wrote:
> ????????????, ?????????!  
>   
> ? ???? ???????? ?? ?????? ? ????? ?? ???? ?? ??????. ????? ???????? ???, ?.?. ??? ??????? ???? ???????? ? ?? ???? ??? ????????.  
> ????? ?????? ???. ????????, ??????????, ???????????. ?? - ??? ????????? ???????.  
> ===================================================  
>   private# uname -a  
> FreeBSD private.org 7.0-RELEASE FreeBSD 7.0-RELEASE #0: Sat Jan 31 11:21:07 EET 2009     root@private.org:/usr/obj/usr/src/sys/NEWKERN  amd64  
> ===================================================  
>   private# cat /dev/sndstat  
> FreeBSD Audio Driver (newpcm: 64bit 2007061600/amd64)  
> Installed devices:  
> pcm0: <ATI SB600 High Definition Audio Controller> at memory 0xfe020000 irq 16 kld snd_hda [20071129_0050] [MPSAFE] (1p:1v/1r:1v channels duplex default)  
> ===================================================  
> ? ?????????,  
> ?????? ????.  
>   
> _______________________________________________
> 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"
>
>   
how about :
kldload snd_hda

From rbgarga at gmail.com  Fri Feb  6 06:55:17 2009
From: rbgarga at gmail.com (Renato Botelho)
Date: Fri Feb  6 06:55:24 2009
Subject: CFT: Graphics support for /boot/loader
In-Reply-To: <200902061335.n16DZNA9063755@lurza.secnetix.de>
References: <747dc8f30902060330l33fb0bbo489dc4fe3009747a@mail.gmail.com>
	<200902061335.n16DZNA9063755@lurza.secnetix.de>
Message-ID: <747dc8f30902060655r143b5ac9ud6f060d1d8351ae1@mail.gmail.com>

On Fri, Feb 6, 2009 at 11:35 AM, Oliver Fromme <olli@lurza.secnetix.de> wrote:
> Renato Botelho wrote:
>  > It worked here, on a 8.0-current i386 r188003, the only small
>  > thing is it show a red border when show the menu.
>
> Do you mean a red line at the top right corner?
> That problem has already been reported and fixed
> in my local source tree.

Not exactly, it's a big red border on 4 sides of screen, something
like there is a red background bigger than image and image is in
front of it.

I don't have a camera here at the moment to give you a picture
but i can do it on monday.

-- 
Renato Botelho
From jhb at freebsd.org  Fri Feb  6 06:59:15 2009
From: jhb at freebsd.org (John Baldwin)
Date: Fri Feb  6 06:59:22 2009
Subject: lpt stopped working
In-Reply-To: <200902061343.50224.c47g@gmx.at>
References: <200902021643.39862.c47g@gmx.at>
	<200902052203.37792.beech@freebsd.org>
	<200902061343.50224.c47g@gmx.at>
Message-ID: <200902060958.37302.jhb@freebsd.org>

On Friday 06 February 2009 7:43:50 am Christian Gusenbauer wrote:
> Hi John!
> 
> Sorry, it seems that I missed your previous mail, so my answer comes here 
> right now.
> 
> On Friday 06 February 2009, Beech Rintoul wrote:
> > On Wednesday 04 February 2009 05:14:10 John Baldwin wrote:
> > > On Monday 02 February 2009 10:43:39 am Christian Gusenbauer wrote:
> > > > Hi!
> > > >
> > > > Since the recent update (svn r187576) to the ppbus/ppc code my printer
> > >
> > > stopped
> > >
> > > > working. Every request seems to hang forever in ppb_request_bus waiting
> > > > for ppb->ppc_lock (at least 'top' tells me that it's hanging in state
> > > > 'ppbreq').
> > >
> > > Can you use procstat to get a stack trace of the hung thread?
> 
> # procstat -k 1199
>   PID    TID COMM             TDNAME           KSTACK
>  1199 100184 cat              -                mi_switch sleepq_switch 
> sleepq_catch_signals sleepq_wait_sig _sleep ppb_request_bus lpt_request_ppbus 
> lptwrite devfs_write_f dofilewrite kern_writev write syscall Xint0x80_syscall

Ok, can you run kgdb against your running kernel (Just run 'kgdb' without any
arguments) and do the following:

(kgdb) p *(struct ppb_data *)ppbus_devclass->devices[0]->softc

Assuming the ppb_owner is not 0, can you then do this:

(kgdb) p *(device_t)((struct ppb_data *)ppbus_devclass->devices[0]->softc)->ppb_owner

-- 
John Baldwin
From olli at lurza.secnetix.de  Fri Feb  6 07:08:14 2009
From: olli at lurza.secnetix.de (Oliver Fromme)
Date: Fri Feb  6 07:08:27 2009
Subject: CFT: Graphics support for /boot/loader
In-Reply-To: <747dc8f30902060655r143b5ac9ud6f060d1d8351ae1@mail.gmail.com>
Message-ID: <200902061508.n16F8AVX068443@lurza.secnetix.de>


Renato Botelho wrote:
 > Oliver Fromme wrote:
 > > Renato Botelho wrote:
 > > > It worked here, on a 8.0-current i386 r188003, the only small
 > > > thing is it show a red border when show the menu.
 > > 
 > > Do you mean a red line at the top right corner?
 > > That problem has already been reported and fixed
 > > in my local source tree.
 > 
 > Not exactly, it's a big red border on 4 sides of screen, something
 > like there is a red background bigger than image and image is in
 > front of it.

I see.  Is that an old CRT monitor (not a TFT display)?

I think I have an idea what might be causing it.
On CRT monitors, the border beyond the pixel area is
set to the color of the first palette entry by default.
The background PCX image happens to have red as the
first palette entry.  So you see a red border.

In my tests I didn't notice the problem because I only
tested with TFT displays and qemu.  These don't have a
visible border.

The fix should be to set the border color to the same
value as the background color (in this case that would
be black).

Best regards
   Oliver

-- 
Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M.
Handelsregister: Registergericht Muenchen, HRA 74606,  Gesch?ftsfuehrung:
secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht M?n-
chen, HRB 125758,  Gesch?ftsf?hrer: Maik Bachmann, Olaf Erb, Ralf Gebhart

FreeBSD-Dienstleistungen, -Produkte und mehr:  http://www.secnetix.de/bsd

It's trivial to make fun of Microsoft products,
but it takes a real man to make them work,
and a God to make them do anything useful.
From imp at bsdimp.com  Fri Feb  6 07:21:46 2009
From: imp at bsdimp.com (M. Warner Losh)
Date: Fri Feb  6 07:21:53 2009
Subject: HEADSUP usb2/usb4bsd to become default in GENERIC
In-Reply-To: <20090206045349.GQ78804@elvis.mu.org>
References: <20090206045349.GQ78804@elvis.mu.org>
Message-ID: <20090206.081901.1923806177.imp@bsdimp.com>

Doesn't the busdma issue need to be solved before we do this?  usb2
currently doesn't work if you have memory above 4GB due to this
issue.  I thought we tagged it as a show stopper for making it the
default.

Warner


In message: <20090206045349.GQ78804@elvis.mu.org>
            Alfred Perlstein <alfred@freebsd.org> writes:
: Hello -current and -usb.
: 
: We are in the final stages of bringing in the new usb
: stack.
: 
: Features include: SMP, better device support, speed increases.
: 
: We hope to make it in for 8.0.  It will really take a unified effort
: to make this all work and I look forward to all contributors input.
: 
: We have a few large steps ahead of us and I wanted to lay out the
: schedule so that people understand what is coming and what to expect.
: 
: At this point we expect there to be no style or changes in usb2
: that are not bugfixes until Phase 3 "Hand off".  The reason for
: this is to prevent bugs from creeping in and allow the maintainer
: to focus 100% on bugs and feature parity with the oldusb stack.
: 
: Here is the plan and timeline:
: 
: Phase 1) Make usb2 the default, by enabling it in GENERIC.
: 
:     * Sunday 8 Feb 2009  -- Toggle the usb2 knob in GENERIC
: 
:       - Add all the usb2 options to NOTES, including commented
:         documentation about recommended usb2 'sets' of options,
:         and the usual NOTES-based hints about the options.
: 
:       - Update GENERIC to use usb2 device names.
: 
:       - Bump __FreeBSD_version and edit UPDATING to note usb2 is now the
:         default.
: 
:       - Verify that it still possible to use the old usb code as a
:         fallback, until we are ready to detach and remove it from /head
: 
:     * Sunday 22 Feb 2009 -- Go through quirks in old-usb code and port
:       over any remaining bits to usb2
: 
:       - Lock the oldusb code for 2 weeks, until the next usb2
:         checkpoint, to verify usb2 is a viable replacement without
:         having to keep chasing a moving oldusb target.
: 
: Phase 2) Removing the oldusb code.
: 
:     * Sunday 15 Mar 2009 -- usb2 bug busting weekend
: 
:       - Go through the open usb2 problem reports, and see if there are
:         any usb2 blocker bugs that need fixing.
: 
:       - If the bug hunt shows we are ready to do away with oldusb,
:         unlink the old usb code from the build, but leave it in for
:         a few more days.
: 
:     * Sunday 22 Mar 2009 -- remove oldusb code.
: 
:       - old usb code will be removed.
: 
: Phase 3) Hand-off.
: 
:     * Sunday 29 Mar 2009 -- usb2 hand over to src-committers
: 
:       - The switch from a private Hans-only repository to the main
:         subversion tree.
: 
:       - At this point, the usb2 is handed over to the src-committers
:         and Hans has to go through a mentor/committer before committing
: 	changes.
: 
: Thank you!
: 
: -- 
: - Alfred Perlstein
: _______________________________________________
: 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 pluknet at gmail.com  Fri Feb  6 09:17:21 2009
From: pluknet at gmail.com (pluknet)
Date: Fri Feb  6 09:17:34 2009
Subject: CFT: Graphics support for /boot/loader
In-Reply-To: <498BA5D5.4080100@samsco.org>
References: <200902052218.n15MIaEa026891@lurza.secnetix.de>
	<498BA5D5.4080100@samsco.org>
Message-ID: <a31046fc0902060917k4c37151fxaf600b81bfb98061@mail.gmail.com>

Hi, Scott!

2009/2/6 Scott Long <scottl@samsco.org>:
> Oliver Fromme wrote:
>>
>> Hello fellow hackers,
>>
>> Some of you might remember that I'm working on graphics
>> support for our /boot/loader.  Unfortunately, progress has
>> been rather slow because of non-FreeBSD-related activity.
>>
>> Anyway, I have now prepared a tarball containing a loader
>> binary for public testing.  If you are eager to give it a
>> try, please feel free to do so.  It should work with any
>> FreeBSD version on i386 and amd64 platforms.
>>
>> I have posted detailed instructions on the FreeBSD wiki:
>>
>> http://wiki.freebsd.org/OliverFromme/BootLoaderTest
>>
>> Any kind of feedback is welcome.
>>
>
> I think that this is really neat, you've done an impressive job
> with it good job.  However, I do take issue with your criticism
> of the ASCII logo; I actually spent a decent amount of time
> designing the block text logo =-)  I wish that there hadn't been
> moronic politics over the beastie logo, as that does look a lot
> better, even if it is text.  And text is still required for
> serial consoles.

Hey, then what's about that? ;)

--- /boot/beastie.4th        2008-08-19 23:59:01.000000000 +0600
+++ /boot/beastie.4th        2008-12-24 18:14:48.000000000 +0500
@@ -109,6 +109,27 @@
          at-xy ."     |____/|_____/|_____/"
 ;

+: share-logo ( x y -- )
+2dup at-xy ."            `````" 1+
+2dup at-xy ." `-/oo/-```.:oshddmmddhso:.```:+oo/." 1+
+2dup at-xy ." .--/shdmddNMMMMMMMMNNNdyhmddNNmh+--" 1+
+2dup at-xy ." `:--/smMMMMMMMMMMMMMMNy+mMMNmho/-::" 1+
+2dup at-xy ."  `/+dMMNMMMNNNNNNNNNNNmddNmho/:-/+" 1+
+2dup at-xy ."   /mNNNMMMNmmmddddhhhhhhsso/:-:+y" 1+
+2dup at-xy ."  :dmdmNMNmdhyso++///:::////::-++sh" 1+
+2dup at-xy ." `hdhdNMmhs+////:::::---------:://sy" 1+
+2dup at-xy ." -dsoyhhso/:::::::::--------.--.--+m" 1+
+2dup at-xy ." :d+/+++++/:::::::------------....oN" 1+
+2dup at-xy ." -m/://////:::::-------------...-/dm" 1+
+2dup at-xy ."  ys-:://////:::------------..--omN" 1+
+2dup at-xy ."  .d+-::///////:--------------:ohNd" 1+
+2dup at-xy ."   .ho-:::://////:::::::::///++shy" 1+
+2dup at-xy ."    `+s:-:::::////////+++++o+oyh+" 1+
+2dup at-xy ."      .+o/:::::///////++++osyy+" 1+
+2dup at-xy ."        `-//////////++ossys/-" 1+
+     at-xy ."            `..--::::::-."
+;
+
 : print-logo ( x y -- )
     s" loader_logo" getenv
     dup -1 = if
@@ -131,6 +152,11 @@
         beastie-logo
         exit
     then
+    2dup s" share" compare-insensitive 0= if
+        2drop
+        share-logo
+        exit
+    then
     2dup s" none" compare-insensitive 0= if
         2drop
         \ no logo

(spied out from http://www.opennet.ru/opennews/art.shtml?num=20136)

-- 
wbr,
pluknet
From klapperzhu at gmail.com  Fri Feb  6 10:19:08 2009
From: klapperzhu at gmail.com (Klapper Zhu)
Date: Fri Feb  6 10:19:14 2009
Subject: To John Birrell: weird behaviors of DTrace on amd64
In-Reply-To: <200902051311.00091.jhb@freebsd.org>
References: <a29c138b0902050831q13844f7bm3aa3bdebdcb9733e@mail.gmail.com>
	<200902051311.00091.jhb@freebsd.org>
Message-ID: <a29c138b0902061019y7891fa78s59376582f72f2904@mail.gmail.com>

Hi John,

I rebuilt kernel with -fno-inline and I got all isp(4) functions listed in fbt.

I noticed that there are other inline related flags
"--finline-limit=8000 -param inline-unit-growth=100  -Winline". should
I get rid of them OR -fno-inline
will just overide them ?

Thanks,

anyone has suggestion for problem 2 ?

On Thu, Feb 5, 2009 at 1:10 PM, John Baldwin <jhb@freebsd.org> wrote:
> On Thursday 05 February 2009 11:31:52 am Klapper Zhu wrote:
>> Hi John Birrell,
>>
>> I am exploring DTrace on "7.1-STABLE FreeBSD amd64" and I found several
>> weird behaviors:
>>
>> 1) Not all kernel functions show up in fbt provider. Take isp(4) as example:
>>     "dtrace -l" shows
>>         static void isp_freeze_loopdown(ispsoftc_t *, int, char *);
>> ___but not___
>>         static void isp_handle_platform_atio2(ispsoftc_t *, at2_entry_t *);
>>
>>     Both are static functions. But one shows up in fbt, another not.
>>     What's the rational behind it ? Any way to fix it ?
>
> Perhaps gcc inlined it?  Try using -fno-inline perhaps.
>
> --
> John Baldwin
>
From amdmi3 at amdmi3.ru  Fri Feb  6 10:33:54 2009
From: amdmi3 at amdmi3.ru (Dmitry Marakasov)
Date: Fri Feb  6 10:34:01 2009
Subject: Bad unicode `-' in manpages
Message-ID: <20090206183344.GE17600@hades.panopticon>

Hi!

It seems like unicode was introduced into man pages on current.

While

"Include directory entries whose names begin with a dot (?.?)"

indeed looks better than

"Include directory entries whose names begin with a dot (`.')"

, I'm concerned about (at least) minus sign, which was changed from
`-' (U+002D HYPHEN-MINUS) symbol to `?' (U+2212 MINUS SIGN) everywhere.
Now most of man pages basically provide false info, and copypasting
or search are now impossible.

-- 
Dmitry Marakasov   .   55B5 0596 FF1E 8D84 5F56  9510 D35A 80DD F9D2 F77D
amdmi3@amdmi3.ru  ..:  jabber: amdmi3@jabber.ru    http://www.amdmi3.ru
From olli at lurza.secnetix.de  Fri Feb  6 10:40:37 2009
From: olli at lurza.secnetix.de (Oliver Fromme)
Date: Fri Feb  6 10:40:44 2009
Subject: CFT: Graphics support for /boot/loader
In-Reply-To: <a31046fc0902060917k4c37151fxaf600b81bfb98061@mail.gmail.com>
Message-ID: <200902061840.n16IeYGn077754@lurza.secnetix.de>

pluknet <pluknet@gmail.com> wrote:
 > Scott Long wrote:
 > > I think that this is really neat, you've done an impressive job
 > > with it good job.  However, I do take issue with your criticism
 > > of the ASCII logo; I actually spent a decent amount of time
 > > designing the block text logo =-)  I wish that there hadn't been
 > > moronic politics over the beastie logo, as that does look a lot
 > > better, even if it is text.  And text is still required for
 > > serial consoles.
 > 
 > Hey, then what's about that? ;)
 > [...]

I have to admit that I like Scott's text logo *much* better.

Trying to render the "horned ball" logo with ASCII letters
looks butt-ugly, IMHO.

Best regards
   Oliver

-- 
Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M.
Handelsregister: Registergericht Muenchen, HRA 74606,  Gesch?ftsfuehrung:
secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht M?n-
chen, HRB 125758,  Gesch?ftsf?hrer: Maik Bachmann, Olaf Erb, Ralf Gebhart

FreeBSD-Dienstleistungen, -Produkte und mehr:  http://www.secnetix.de/bsd

$ dd if=/dev/urandom of=test.pl count=1
$ file test.pl
test.pl: perl script text executable
From jhb at freebsd.org  Fri Feb  6 10:57:08 2009
From: jhb at freebsd.org (John Baldwin)
Date: Fri Feb  6 10:57:14 2009
Subject: To John Birrell: weird behaviors of DTrace on amd64
In-Reply-To: <a29c138b0902061019y7891fa78s59376582f72f2904@mail.gmail.com>
References: <a29c138b0902050831q13844f7bm3aa3bdebdcb9733e@mail.gmail.com>
	<200902051311.00091.jhb@freebsd.org>
	<a29c138b0902061019y7891fa78s59376582f72f2904@mail.gmail.com>
Message-ID: <200902061356.51320.jhb@freebsd.org>

On Friday 06 February 2009 1:19:06 pm Klapper Zhu wrote:
> Hi John,
> 
> I rebuilt kernel with -fno-inline and I got all isp(4) functions listed in 
fbt.
> 
> I noticed that there are other inline related flags
> "--finline-limit=8000 -param inline-unit-growth=100  -Winline". should
> I get rid of them OR -fno-inline
> will just overide them ?

I believe -fno-inline overrides them.

-- 
John Baldwin
From cryx-freebsd at h3q.com  Fri Feb  6 11:32:45 2009
From: cryx-freebsd at h3q.com (Philipp Wuensche)
Date: Fri Feb  6 11:33:02 2009
Subject: Solaris live upgrade like FreeBSD ZFS-rootfs update
In-Reply-To: <498234A4.6040102@h3q.com>
References: <4981EBC6.1000907@h3q.com>	<20090129224911.GA23573@keltia.freenix.fr>
	<498234A4.6040102@h3q.com>
Message-ID: <498C905A.1020007@h3q.com>

Philipp Wuensche wrote:
> Ollivier Robert wrote:
>> According to Philipp Wuensche:
>>> I'm playing a lot with ZFS root filesystems for FreeBSD and using
>>> zfsboot with GPT. So far it works perfecly for me on three not-so
>>> production servers and I would like to thank everybody that helped make
>>> this work!
>> Excellent, care to submit an entry for the FreeBSD wiki explining all the
>> steps you took? :)
> 
> Sure, all the stuff is on the net already but a complete run-down maybe
> would be helpful to get more people into using ZFS :-)
> 
> I guess I will write something up in the next days.

First version, just typing down what I do:
http://outpost.h3q.com/patches/manageBE/create-FreeBSD-ZFS-bootfs.txt

greetings,
philipp
From llc2w at virginia.edu  Fri Feb  6 11:42:29 2009
From: llc2w at virginia.edu (L Campbell)
Date: Fri Feb  6 11:42:37 2009
Subject: iwi broken? reproducible crash :(
Message-ID: <792298050902061142k33f35be7sb19d566835e796ad@mail.gmail.com>

I recently updated to CURRENT from RELENG_7 (from sources pulled on
Feb. 6th), and since then haven't been able to get my Inspiron 6000's
Intel PRO 2200/BG working again (it worked mostly fine on RELENG_7).
The machine is running an i386 non-GENERIC kernel (I can post the
configuration if it's relevant).

The settings on the device (set from rc.conf) configured for my home
network (which experiences the same problem) look like this --

$ ifconfig iwi0
iwi0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 2290
        ether 00:16:6f:63:a6:dc
        media: IEEE 802.11 Wireless Ethernet autoselect mode 11g
        status: associated

$ ifconfig wlan0
wlan0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
        ether 00:16:6f:63:a6:dc
        media: IEEE 802.11 Wireless Ethernet autoselect (autoselect)
        status: no carrier
        ssid home_ssid channel 5 (2432 Mhz 11g)
        country US authmode OPEN privacy OFF txpower 0 bmiss 24 scanvalid 60
        protmode CTS wme bintval 0

When attempting to associate with an access point (without any
encryption or additional complications), the console gets flooded with
a barrage of messages --

$ ifconfig wlan0 down ssid wahoo bssid - channel 11 up
iwi0: need multicast update callback
iwi0: iwi_cmd: cmd 84 not sent, busy
iwi0: iwi_cmd: cmd 42 not sent, busy
iwi0: firmware error

Enabling debug via `$ sysctl debug.iwi=1` reproducibly causes the
kernel to crash:

Unread portion of the kernel message buffer:
exit SCANNING state
iwi_ops: SET_WME arg 0
iwi_newstate: SCAN -> AUTH flags 0x1
iwi_ops: AUTH arg 192
enter ASSOCIATING state
Configuring adapter
Setting ESSID to "wahoo"
Setting power mode to 0
Setting RTS threshold to 2346
Setting fragmentation threshold to 2346
Setting negotiated rates (12)
Setting WME parameters
Setting WME IE (len=7)
Setting sensitivity to 69
Join bssid 00:19:07:05:99:c3 dst 00:19:07:05:99:c3 channel 11 policy
0x1 auth 0 capinfo 0x21 lintval 100 bintval 100
iwi_newstate: AUTH -> ASSOC flags 0x1
exit ASSOCIATING state
iwi_newstate: ASSOC -> SCAN flags 0x1
iwi_ops: SET_WME arg 0
iwi_newstate: SCAN -> AUTH flags 0x1
iwi_ops: AUTH arg 192
enter ASSOCIATING state
Configuring adapter
exit ASSOCIATING state
Setting ESSID to "wahoo"
iwi_newSetting power mode to 0
state: AUTSetting RTS threshold to 2346
H -> SCAN Setting fragmentation threshold to 2346
flags 0x9Setting negotiated rates (12)

Setting WME parameters
iwi_newSetting WME IE (len=7)
state: SCA

Fatal trap 12: page fault while in kernel mode
fault virtual address   = 0xc40ee184
fault code              = supervisor read, page not present
instruction pointer     = 0x20:0xc06bea06
stack pointer           = 0x28:0xc3a05b64
frame pointer           = 0x28:0xc3a05b64
code segment            = base 0x0, limit 0xfffff, type 0x1b
                        = DPL 0, pres 1, def32 1, gran 1
processor eflags        = interrupt enabled, resume, IOPL = 0
current process         = 0 (iwi0 taskq)

kgdb> bt
#12 0xc06bea06 in node_getrssi (ni=0xc40ee000)
    at /usr/src/sys/net80211/ieee80211_node.c:1005
#13 0xc051286c in iwi_ops (arg0=0xc3d4ec00, npending=1)
    at /usr/src/sys/dev/iwi/if_iwi.c:2926
#14 0xc062d042 in taskqueue_run (queue=0xc3d73180)
    at /usr/src/sys/kern/subr_taskqueue.c:282
#15 0xc062d3db in taskqueue_thread_loop (arg=0xc3d4ec4c)
    at /usr/src/sys/kern/subr_taskqueue.c:403
#16 0xc05d6e80 in fork_exit (callout=0xc062d360 <taskqueue_thread_loop>,
    arg=0xc3d4ec4c, frame=0xc3a05d38) at /usr/src/sys/kern/kern_fork.c:821
#17 0xc07daf70 in fork_trampoline () at /usr/src/sys/i386/i386/exception.s:270

kgdb> f 12
kgdb> list
0xc06bea06 is in node_getrssi (/usr/src/sys/net80211/ieee80211_node.c:1005).
1000    }
1001
1002    static int8_t
1003    node_getrssi(const struct ieee80211_node *ni)
1004    {
1005            uint32_t avgrssi = ni->ni_avgrssi;
1006            int32_t rssi;
1007
1008            if (avgrssi == IEEE80211_RSSI_DUMMY_MARKER)
1009                    return 0;

kgdb> p ni
$1 = (const struct ieee80211_node *) 0xc40ee000

I dunno if this is the right channel to post the information (or even
if I'm posting anything useful). Let me know if you need more
information or have any ideas/suggestions/patches to test. Thanks a
bunch :3
From swell.k at gmail.com  Fri Feb  6 11:56:39 2009
From: swell.k at gmail.com (Anonymous)
Date: Fri Feb  6 11:56:48 2009
Subject: Bad unicode `-' in manpages
In-Reply-To: <20090206183344.GE17600@hades.panopticon> (Dmitry Marakasov's
	message of "Fri, 6 Feb 2009 21:33:44 +0300")
References: <20090206183344.GE17600@hades.panopticon>
Message-ID: <867i43742t.fsf@gmail.com>

Dmitry Marakasov <amdmi3@amdmi3.ru> writes:

> Hi!
>
> It seems like unicode was introduced into man pages on current.
>
> While
>
> "Include directory entries whose names begin with a dot (?.?)"
>
> indeed looks better than
>
> "Include directory entries whose names begin with a dot (`.')"
>
> , I'm concerned about (at least) minus sign, which was changed from
> `-' (U+002D HYPHEN-MINUS) symbol to `?' (U+2212 MINUS SIGN) everywhere.
> Now most of man pages basically provide false info, and copypasting
> or search are now impossible.

Have you tried to change locale to `C' or invoke man(1) with `-o'?

locale `C' and `-o' option produce `groff -S -Wall -mtty-char -man -Tascii'

locale `en_US.UTF-8' produces
    `groff -S -Wall -mtty-char -man -Tutf8 -dlocale=en.UTF-8'

Anyway, same here, but I vaguely remember it first appeared about half a
year ago. And I think it can cause trouble when trying to view localized
man page written in unicode when you can't escape to either `C' locale
or `-o' option.
From smrad01 at gmail.com  Fri Feb  6 12:51:30 2009
From: smrad01 at gmail.com (blah)
Date: Fri Feb  6 12:51:37 2009
Subject: installkernel on small disk
In-Reply-To: <20090206202032.GB76165@obspm.fr>
References: <20090206202032.GB76165@obspm.fr>
Message-ID: <498CA2CD.1090201@gmail.com>

Albert Shih wrote:
> Hi all
>
> I've two servers (in fact guest in vmware) on don't have enought disk space
> to make buildkernel (or world).
>
> For the world freebsd-update can work. But for the kernel I've my own
> kernel.
>
> So if I compile the kernel on the other server how can I put it on the
> first ?
>
> Regards.
>
>
>   
build kernel on the server
use nfs to export /usr/src, /usr/obj
mount them appropriate on the client, make same /etc/make.conf on both 
server and client
on the client cd /usr/src and make installkernel .... rebooot and you 
are done

From sziszi at bsd.hu  Fri Feb  6 12:55:00 2009
From: sziszi at bsd.hu (Szilveszter Adam)
Date: Fri Feb  6 12:55:07 2009
Subject: iwi broken? reproducible crash :(
In-Reply-To: <792298050902061142k33f35be7sb19d566835e796ad@mail.gmail.com>
References: <792298050902061142k33f35be7sb19d566835e796ad@mail.gmail.com>
Message-ID: <20090206205456.GA60974@baranyfelhocske.buza.adamsfamily.xx>

Hello,

While this is not much more than an anecdotal report, it is as good a
datapoint as any: my system (ThinkPad R50e) has no problems with iwi(4)
these days (although there have been bumpy passages in the past) I also
run up-to-date -CURRENT i386 with a custom kernel. I note however that I
have been running 8.x since 7.x was branched from it, so my upgrades
were probably more incremental in nature.

I am happy to share configs/logs/experience with this adapter.

-- 
Regards:

Szilveszter ADAM
Budapest
Hungary
From beech at freebsd.org  Fri Feb  6 13:31:48 2009
From: beech at freebsd.org (Beech Rintoul)
Date: Fri Feb  6 13:31:55 2009
Subject: lpt stopped working
In-Reply-To: <200902052203.37792.beech@freebsd.org>
References: <200902021643.39862.c47g@gmx.at>
	<200902040914.10330.jhb@freebsd.org>
	<200902052203.37792.beech@freebsd.org>
Message-ID: <200902061231.46516.beech@freebsd.org>

On Thursday 05 February 2009 22:03:37 Beech Rintoul wrote:
> On Wednesday 04 February 2009 05:14:10 John Baldwin wrote:
> > On Monday 02 February 2009 10:43:39 am Christian Gusenbauer wrote:
> > > Hi!
> > >
> > > Since the recent update (svn r187576) to the ppbus/ppc code my printer
> >
> > stopped
> >
> > > working. Every request seems to hang forever in ppb_request_bus waiting
> > > for ppb->ppc_lock (at least 'top' tells me that it's hanging in state
> > > 'ppbreq').
> >
> > Can you use procstat to get a stack trace of the hung thread?
>
> My printer is still showing "device busy" for lpt0 does anyone know offhand
> when the changes were committed? I need to revert.

There is regression somewhere in the ppbus code committed two weeks ago. I 
reverted back to previous code and lpt0 no longer reports "device busy" and 
printing is working again.

Beech 

-- 
---------------------------------------------------------------------------------------
Beech Rintoul - FreeBSD Developer - beech@FreeBSD.org
/"\   ASCII Ribbon Campaign  | FreeBSD Since 4.x
\ / - NO HTML/RTF in e-mail   | http://people.freebsd.org/~beech
 X  - NO Word docs in e-mail | Skype: akbeech
/ \  - http://www.FreeBSD.org/releases/7.1R/announce.html
---------------------------------------------------------------------------------------




From llc2w at virginia.edu  Fri Feb  6 14:03:10 2009
From: llc2w at virginia.edu (L Campbell)
Date: Fri Feb  6 14:03:17 2009
Subject: iwi broken? reproducible crash :(
In-Reply-To: <20090206205456.GA60974@baranyfelhocske.buza.adamsfamily.xx>
References: <792298050902061142k33f35be7sb19d566835e796ad@mail.gmail.com>
	<20090206205456.GA60974@baranyfelhocske.buza.adamsfamily.xx>
Message-ID: <792298050902061403o5adc52ddx3b6a476a78e5c230@mail.gmail.com>

On Fri, Feb 6, 2009 at 3:54 PM, Szilveszter Adam <sziszi@bsd.hu> wrote:
> While this is not much more than an anecdotal report, it is as good a
> datapoint as any: my system (ThinkPad R50e) has no problems with iwi(4)

A quick Google hints that the R50e also has a 2200BG adapter -- I was
half hoping that it was a different card so I could write it off.

> I am happy to share configs/logs/experience with this adapter.

Since you're offering -- back on 7.x I had all kinds of problem with
the adapter: I had to double the send/recvbuf_max and had to disable
bgscan, otherwise the connection would die after ~6-12 hours,
depending on usage. Did you ever have similar issues, or is something
wonky with my machine?

I'll see if I can't grab some more hardware to test with to rule out
hardware failure or a broken install on my part.

As always, further suggestions and ideas are welcome :3
From mav at mavhome.dp.ua  Fri Feb  6 13:37:22 2009
From: mav at mavhome.dp.ua (Alexander Motin)
Date: Fri Feb  6 14:33:46 2009
Subject: To Alexander Motin aka Mav. HDA problems.
In-Reply-To: <1233937386.00071723.1233925801@10.7.7.3>
References: <1233937386.00071723.1233925801@10.7.7.3>
Message-ID: <498C9D2E.6080901@mavhome.dp.ua>

Yury Froloff wrote:
> ? ???? ???????? ?? ?????? ? ????? ?? ???? ?? ??????. ????? ???????? ???, ?.?. ??? ??????? ???? ???????? ? ?? ???? ??? ????????.  
> ????? ?????? ???. ????????, ??????????, ???????????. ?? - ??? ????????? ???????.  
> ===================================================  
>   private# uname -a  
> FreeBSD private.org 7.0-RELEASE FreeBSD 7.0-RELEASE #0: Sat Jan 31 11:21:07 EET 2009     root@private.org:/usr/obj/usr/src/sys/NEWKERN  amd64  
> ===================================================  
>   private# cat /dev/sndstat  
> FreeBSD Audio Driver (newpcm: 64bit 2007061600/amd64)  
> Installed devices:  
> pcm0: <ATI SB600 High Definition Audio Controller> at memory 0xfe020000 irq 16 kld snd_hda [20071129_0050] [MPSAFE] (1p:1v/1r:1v channels duplex default)  
> ===================================================  

? ???? ????? ?????? ??????? 2007 ????. ???? ????? ?????? ? ?????????? 
??????? ?? 7-STABLE ??? ?? ??????? ???? ????????? ????? ?????? ??????? 
/sys/dev/sound/pci/hda ? ??????????? ?????? snd_hda.

You have old driver of year 2007. You should start from updating your 
system to latest 7-STABLE or at least take /sys/dev/sound/pci/hda folder 
from there and rebuild your snd_hda module.

-- 
Alexander Motin
From Thomas.Sparrevohn at btinternet.com  Fri Feb  6 14:44:28 2009
From: Thomas.Sparrevohn at btinternet.com (Thomas Sparrevohn)
Date: Fri Feb  6 14:44:35 2009
Subject: CFT: Graphics support for /boot/loader
In-Reply-To: <498BA5D5.4080100@samsco.org>
References: <200902052218.n15MIaEa026891@lurza.secnetix.de>
	<498BA5D5.4080100@samsco.org>
Message-ID: <200902062244.19607.Thomas.Sparrevohn@btinternet.com>

On Friday 06 February 2009 02:52:05 Scott Long wrote:

> I think that this is really neat, you've done an impressive job
> with it good job.  However, I do take issue with your criticism
> of the ASCII logo; I actually spent a decent amount of time
> designing the block text logo =-)  I wish that there hadn't been
> moronic politics over the beastie logo, as that does look a lot
> better, even if it is text.  And text is still required for
> serial consoles.
> 

Agreed - Looks very cool - but I miss beastie - Would love to have it 
as an option like,  "WITH_SENTIMENTAL=YES"  that maybe would install
the old games as well....ahh well 
From invite+o2_j=oc9 at facebookmail.com  Fri Feb  6 14:14:45 2009
From: invite+o2_j=oc9 at facebookmail.com (Ali Sohi)
Date: Fri Feb  6 14:48:46 2009
Subject: Check out my Facebook profile
Message-ID: <c00ff79b89b43923521f006e6f1328fe@localhost.localdomain>

Hi current,

I set up a Facebook profile where I can post my pictures, videos and events and I want to add you as a friend so you can see it. First, you need to join Facebook! Once you join, you can also create your own profile.

Thanks,
Ali

To sign up for Facebook, follow the link below:
http://www.facebook.com/p.php?i=1192115166&k=6YA6Y6V6P54MXF1FPKVXQ&r

From rohit.x.tripathi at jpmchase.com  Fri Feb  6 15:06:44 2009
From: rohit.x.tripathi at jpmchase.com (rohit.x.tripathi@jpmchase.com)
Date: Fri Feb  6 15:06:51 2009
Subject: running binaries under linux ABI 
Message-ID: <OFF87DE685.7221BE38-ON85257555.0073AF88-85257555.00797A7A@jpmchase.com>

Hi, I suppose this question could be answered here, or someone can point 
me in the right direction. (I read the linux abi doc before mailing)

I have a dual core laptop with 2 GB RAM which is correctly detected by a 
linux app running under fedora 64bit:

rohit@tp/home/q/l64 $ q
KDB+ 2.5 2009.02.05 Copyright (C) 1993-2009 Kx Systems
l64/ 2()core 1978MB rohit tp 127.0.0.1 EXPIRE 2009.09.09

q).z.k
2009.02.05
q)

Under FreeBSD i386 though, it seems to think that the RAM is 1MB and only 
one core is available:

KDB+ 2.5 2009.02.05 Copyright (C) 1993-2009 Kx Systems
l32/ 1()core -1MB rohit tp 255.255.255.255 EXPIRE 2009.09.09

q).z.k
2009.02.05
q)


SMP is enabled on my kernel, and it detects both cores during boot, and 
with top I can see various processes running in cores 0 and 1.
The vendor does not have a freebsd version. Is there something about the 
ABI that can explain this behavior?

If its relevant, I installed the ABI 

regards,
Rohit


(as always, please forgive the disclaimer attached to my emails)

-----------------------------------------
This communication is for informational purposes only. It is not
intended as an offer or solicitation for the purchase or sale of
any financial instrument or as an official confirmation of any
transaction. All market prices, data and other information are not
warranted as to completeness or accuracy and are subject to change
without notice. Any comments or statements made herein do not
necessarily reflect those of JPMorgan Chase & Co., its subsidiaries
and affiliates.

This transmission may contain information that is privileged,
confidential, legally privileged, and/or exempt from disclosure
under applicable law. If you are not the intended recipient, you
are hereby notified that any disclosure, copying, distribution, or
use of the information contained herein (including any reliance
thereon) is STRICTLY PROHIBITED. Although this transmission and any
attachments are believed to be free of any virus or other defect
that might affect any computer system into which it is received and
opened, it is the responsibility of the recipient to ensure that it
is virus free and no responsibility is accepted by JPMorgan Chase &
Co., its subsidiaries and affiliates, as applicable, for any loss
or damage arising in any way from its use. If you received this
transmission in error, please immediately contact the sender and
destroy the material in its entirety, whether in electronic or hard
copy format. Thank you.

Please refer to http://www.jpmorgan.com/pages/disclosures for
disclosures relating to UK legal entities.
From peter.schuller at infidyne.com  Fri Feb  6 15:23:29 2009
From: peter.schuller at infidyne.com (Peter Schuller)
Date: Fri Feb  6 15:23:36 2009
Subject: zfs: allocating allocated segment
In-Reply-To: <200902051224.34442.michael.gusek@web.de>
References: <200902051224.34442.michael.gusek@web.de>
Message-ID: <20090206232327.GA19383@hyperion.scode.org>

> I'm running a File server with zfs, 64 Bit, 4 GB Ram and RELENG_7. Two days 
> ago i uploaded a file via ftp to the server and the server is crashing. After 
> reboot FreeBSD can't import the zfs-pool. There is a kernel-message:
> 
> panic: Solaris(panic): zfs: allocating allocated 
> segment(offset=123456... size=74)
> 
> cpuid = 0
> Uptime: 14m22s
> panic: bufwrite: buffer is not busy???
> 
> Now i try to import the zfs-pool with a recent 8.0-current but with the same 
> result. It's very important to me to access the pool, so did you have some 
> idea's ?

The ZFS panic is from space_map.c in space_map_add(), happening via
zfs_panic_recover(). It in turn is affected by zfs_recover:

/*                                                                                                                                                                                                                                             * zfs_recover can be set to nonzero to attempt to recover from                                                                                                                                                                                * otherwise-fatal errors, typically caused by on-disk corruption.  When                                                                                                                                                                       * set, calls to zfs_panic_recover() will turn into warning messages.                                                                                                                                                                          */

Setting the vfs.zfs.recover loader variable to 1 might possibly
help. However I have never tried using that option and I'm not
familiar with the code, so I have no idea how safe it is. In
particular since you then seem to be getting a secondary panic (the
"buffer is not busy" which is from ffs_vfsops.

On another note:

http://www.google.com/search?client=opera&rls=en&q=zfs:+allocating+allocated+segment&sourceid=opera&ie=utf-8&oe=utf-8

indicates you're not the only person who has seen similar
errors. Unfortunately I cannot offer any insight other than to suggest
digging through the google results.

Was the original crash, prior to the mount problem, purely a software
crash or was there, for example, a power outtage? I'm wondering
whether there is any particular reason to believe there was some
hardware/firmware fault causing corruption.

-- 
/ Peter Schuller

PGP userID: 0xE9758B7D or 'Peter Schuller <peter.schuller@infidyne.com>'
Key retrieval: Send an E-Mail to getpgpkey@scode.org
E-Mail: peter.schuller@infidyne.com Web: http://www.scode.org

-------------- 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/20090206/aa6a4a53/attachment.pgp
From vince at unsane.co.uk  Fri Feb  6 16:04:32 2009
From: vince at unsane.co.uk (Vincent Hoffman)
Date: Fri Feb  6 16:04:39 2009
Subject: CFT: Graphics support for /boot/loader
In-Reply-To: <200902062244.19607.Thomas.Sparrevohn@btinternet.com>
References: <200902052218.n15MIaEa026891@lurza.secnetix.de>	<498BA5D5.4080100@samsco.org>
	<200902062244.19607.Thomas.Sparrevohn@btinternet.com>
Message-ID: <498CD00B.5010707@unsane.co.uk>

On 6/2/09 22:44, Thomas Sparrevohn wrote:
> On Friday 06 February 2009 02:52:05 Scott Long wrote:
>
>   
>> I think that this is really neat, you've done an impressive job
>> with it good job.  However, I do take issue with your criticism
>> of the ASCII logo; I actually spent a decent amount of time
>> designing the block text logo =-)  I wish that there hadn't been
>> moronic politics over the beastie logo, as that does look a lot
>> better, even if it is text.  And text is still required for
>> serial consoles.
>>
>>     
>
> Agreed - Looks very cool - but I miss beastie - Would love to have it 
> as an option like,  "WITH_SENTIMENTAL=YES"  that maybe would install
> the old games as well....ahh well 
>   
have a look through /boot/defaults/loader.conf (or man loader.conf)
specificly,
#loader_logo="fbsdbw"           # Desired logo: fbsdbw, beastiebw,
beastie, none


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 paul at fletchermoorland.co.uk  Fri Feb  6 16:05:57 2009
From: paul at fletchermoorland.co.uk (Paul Wootton)
Date: Fri Feb  6 16:06:10 2009
Subject: ZFS and Graphics support for /boot/loader
In-Reply-To: <200902052218.n15MIaEa026891@lurza.secnetix.de>
References: <200902052218.n15MIaEa026891@lurza.secnetix.de>
Message-ID: <1CDDD463937A44A09B6F4D9FD4969293@apollo>

Hi Oliver,

This doesn?t work for me.

I am booting off a ZFS mirror with GPT partitions (built from current on an
amd64).

Is there any change of a version of gloader but with ZFS support?

Cheers
Paul

-----Original Message-----
From: owner-freebsd-hackers@freebsd.org
[mailto:owner-freebsd-hackers@freebsd.org] On Behalf Of Oliver Fromme
Sent: 05 February 2009 22:19
To: freebsd-hackers@freebsd.org; freebsd-current@freebsd.org
Subject: CFT: Graphics support for /boot/loader

Hello fellow hackers,

Some of you might remember that I'm working on graphics
support for our /boot/loader.  Unfortunately, progress has
been rather slow because of non-FreeBSD-related activity.

Anyway, I have now prepared a tarball containing a loader
binary for public testing.  If you are eager to give it a
try, please feel free to do so.  It should work with any
FreeBSD version on i386 and amd64 platforms.

I have posted detailed instructions on the FreeBSD wiki:

http://wiki.freebsd.org/OliverFromme/BootLoaderTest

Any kind of feedback is welcome.

Best regards
   Oliver

-- 
Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M.
Handelsregister: Registergericht Muenchen, HRA 74606,  Gesch?ftsfuehrung:
secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht M?n-
chen, HRB 125758,  Gesch?ftsf?hrer: Maik Bachmann, Olaf Erb, Ralf Gebhart

FreeBSD-Dienstleistungen, -Produkte und mehr:  http://www.secnetix.de/bsd

"If Java had true garbage collection, most programs
would delete themselves upon execution."
        -- Robert Sewell
_______________________________________________
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org"

From voidpointer at bsd.com.br  Fri Feb  6 16:09:55 2009
From: voidpointer at bsd.com.br (Diego Rocha)
Date: Fri Feb  6 16:17:20 2009
Subject: CFT: Graphics support for /boot/loader
In-Reply-To: <200902052218.n15MIaEa026891@lurza.secnetix.de>
References: <200902052218.n15MIaEa026891@lurza.secnetix.de>
Message-ID: <e662426f0902061537t202b97f8wbcaffd066fbb1bb3@mail.gmail.com>

it's work very nice to me

FreeBSD blackbird 7.0-RELEASE-p9 FreeBSD 7.0-RELEASE-p9 #1: Wed Jan 28
22:56:31 BRST 2009     void@blackbird:/usr/obj/usr/src/sys/VPKERNEL  i386
From sam at freebsd.org  Fri Feb  6 18:55:28 2009
From: sam at freebsd.org (Sam Leffler)
Date: Fri Feb  6 18:55:34 2009
Subject: iwi broken? reproducible crash :(
In-Reply-To: <792298050902061142k33f35be7sb19d566835e796ad@mail.gmail.com>
References: <792298050902061142k33f35be7sb19d566835e796ad@mail.gmail.com>
Message-ID: <498CF81F.2090105@freebsd.org>

L Campbell wrote:
> I recently updated to CURRENT from RELENG_7 (from sources pulled on
> Feb. 6th), and since then haven't been able to get my Inspiron 6000's
> Intel PRO 2200/BG working again (it worked mostly fine on RELENG_7).
> The machine is running an i386 non-GENERIC kernel (I can post the
> configuration if it's relevant).
>
> The settings on the device (set from rc.conf) configured for my home
> network (which experiences the same problem) look like this --
>
> $ ifconfig iwi0
> iwi0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 2290
>         ether 00:16:6f:63:a6:dc
>         media: IEEE 802.11 Wireless Ethernet autoselect mode 11g
>         status: associated
>
> $ ifconfig wlan0
> wlan0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
>         ether 00:16:6f:63:a6:dc
>         media: IEEE 802.11 Wireless Ethernet autoselect (autoselect)
>         status: no carrier
>         ssid home_ssid channel 5 (2432 Mhz 11g)
>         country US authmode OPEN privacy OFF txpower 0 bmiss 24 scanvalid 60
>         protmode CTS wme bintval 0
>
> When attempting to associate with an access point (without any
> encryption or additional complications), the console gets flooded with
> a barrage of messages --
>
> $ ifconfig wlan0 down ssid wahoo bssid - channel 11 up
> iwi0: need multicast update callback
> iwi0: iwi_cmd: cmd 84 not sent, busy
> iwi0: iwi_cmd: cmd 42 not sent, busy
> iwi0: firmware error
>
> Enabling debug via `$ sysctl debug.iwi=1` reproducibly causes the
> kernel to crash:
>
> Unread portion of the kernel message buffer:
> exit SCANNING state
> iwi_ops: SET_WME arg 0
> iwi_newstate: SCAN -> AUTH flags 0x1
> iwi_ops: AUTH arg 192
> enter ASSOCIATING state
> Configuring adapter
> Setting ESSID to "wahoo"
> Setting power mode to 0
> Setting RTS threshold to 2346
> Setting fragmentation threshold to 2346
> Setting negotiated rates (12)
> Setting WME parameters
> Setting WME IE (len=7)
> Setting sensitivity to 69
> Join bssid 00:19:07:05:99:c3 dst 00:19:07:05:99:c3 channel 11 policy
> 0x1 auth 0 capinfo 0x21 lintval 100 bintval 100
> iwi_newstate: AUTH -> ASSOC flags 0x1
> exit ASSOCIATING state
> iwi_newstate: ASSOC -> SCAN flags 0x1
> iwi_ops: SET_WME arg 0
> iwi_newstate: SCAN -> AUTH flags 0x1
> iwi_ops: AUTH arg 192
> enter ASSOCIATING state
> Configuring adapter
> exit ASSOCIATING state
> Setting ESSID to "wahoo"
> iwi_newSetting power mode to 0
> state: AUTSetting RTS threshold to 2346
> H -> SCAN Setting fragmentation threshold to 2346
> flags 0x9Setting negotiated rates (12)
>
> Setting WME parameters
> iwi_newSetting WME IE (len=7)
> state: SCA
>
> Fatal trap 12: page fault while in kernel mode
> fault virtual address   = 0xc40ee184
> fault code              = supervisor read, page not present
> instruction pointer     = 0x20:0xc06bea06
> stack pointer           = 0x28:0xc3a05b64
> frame pointer           = 0x28:0xc3a05b64
> code segment            = base 0x0, limit 0xfffff, type 0x1b
>                         = DPL 0, pres 1, def32 1, gran 1
> processor eflags        = interrupt enabled, resume, IOPL = 0
> current process         = 0 (iwi0 taskq)
>
> kgdb> bt
> #12 0xc06bea06 in node_getrssi (ni=0xc40ee000)
>     at /usr/src/sys/net80211/ieee80211_node.c:1005
> #13 0xc051286c in iwi_ops (arg0=0xc3d4ec00, npending=1)
>     at /usr/src/sys/dev/iwi/if_iwi.c:2926
> #14 0xc062d042 in taskqueue_run (queue=0xc3d73180)
>     at /usr/src/sys/kern/subr_taskqueue.c:282
> #15 0xc062d3db in taskqueue_thread_loop (arg=0xc3d4ec4c)
>     at /usr/src/sys/kern/subr_taskqueue.c:403
> #16 0xc05d6e80 in fork_exit (callout=0xc062d360 <taskqueue_thread_loop>,
>     arg=0xc3d4ec4c, frame=0xc3a05d38) at /usr/src/sys/kern/kern_fork.c:821
> #17 0xc07daf70 in fork_trampoline () at /usr/src/sys/i386/i386/exception.s:270
>
> kgdb> f 12
> kgdb> list
> 0xc06bea06 is in node_getrssi (/usr/src/sys/net80211/ieee80211_node.c:1005).
> 1000    }
> 1001
> 1002    static int8_t
> 1003    node_getrssi(const struct ieee80211_node *ni)
> 1004    {
> 1005            uint32_t avgrssi = ni->ni_avgrssi;
> 1006            int32_t rssi;
> 1007
> 1008            if (avgrssi == IEEE80211_RSSI_DUMMY_MARKER)
> 1009                    return 0;
>
> kgdb> p ni
> $1 = (const struct ieee80211_node *) 0xc40ee000
>
> I dunno if this is the right channel to post the information (or even
> if I'm posting anything useful). Let me know if you need more
> information or have any ideas/suggestions/patches to test. Thanks a
> bunch :3
>   

Looks like a race in referencing the bss node and a state change.  I 
haven't looked at iwi forever so can't recall how it's supposed to 
work.  You might enable net80211 state machine debug msgs to see if it 
provides more info: wlandebug state.

    Sam

From llc2w at virginia.edu  Fri Feb  6 19:15:16 2009
From: llc2w at virginia.edu (L Campbell)
Date: Fri Feb  6 19:15:24 2009
Subject: iwi broken? reproducible crash :(
In-Reply-To: <498CF81F.2090105@freebsd.org>
References: <792298050902061142k33f35be7sb19d566835e796ad@mail.gmail.com>
	<498CF81F.2090105@freebsd.org>
Message-ID: <792298050902061915h2c345483pe0a30f7d524e7953@mail.gmail.com>

On Fri, Feb 6, 2009 at 9:55 PM, Sam Leffler <sam@freebsd.org> wrote:
> Looks like a race in referencing the bss node and a state change.  I haven't
> looked at iwi forever so can't recall how it's supposed to work.  You might
> enable net80211 state machine debug msgs to see if it provides more info:
> wlandebug state.

Awesome, I'll give that a shot on Monday and report back with the
results -- I can't seem to reproduce the panic on my home network.

In the meanwhile, I found an old Atheros-based WPC54G lying around
which will get me through the weekend.

Thanks for the help :3
From tinderbox at freebsd.org  Fri Feb  6 20:23:09 2009
From: tinderbox at freebsd.org (FreeBSD Tinderbox)
Date: Fri Feb  6 20:23:19 2009
Subject: [head tinderbox] failure on ia64/ia64
Message-ID: <20090207042305.7171F7302F@freebsd-current.sentex.ca>

TB --- 2009-02-07 02:32:17 - tinderbox 2.6 running on freebsd-current.sentex.ca
TB --- 2009-02-07 02:32:17 - starting HEAD tinderbox run for ia64/ia64
TB --- 2009-02-07 02:32:17 - cleaning the object tree
TB --- 2009-02-07 02:32:59 - cvsupping the source tree
TB --- 2009-02-07 02:32:59 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/ia64/ia64/supfile
TB --- 2009-02-07 02:33:07 - building world
TB --- 2009-02-07 02:33:07 - MAKEOBJDIRPREFIX=/obj
TB --- 2009-02-07 02:33:07 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2009-02-07 02:33:07 - TARGET=ia64
TB --- 2009-02-07 02:33:07 - TARGET_ARCH=ia64
TB --- 2009-02-07 02:33:07 - TZ=UTC
TB --- 2009-02-07 02:33:07 - __MAKE_CONF=/dev/null
TB --- 2009-02-07 02:33:07 - cd /src
TB --- 2009-02-07 02:33:07 - /usr/bin/make -B buildworld
>>> World build started on Sat Feb  7 02:33:09 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 Sat Feb  7 04:21:00 UTC 2009
TB --- 2009-02-07 04:21:00 - generating LINT kernel config
TB --- 2009-02-07 04:21:00 - cd /src/sys/ia64/conf
TB --- 2009-02-07 04:21:00 - /usr/bin/make -B LINT
TB --- 2009-02-07 04:21:00 - building LINT kernel
TB --- 2009-02-07 04:21:00 - MAKEOBJDIRPREFIX=/obj
TB --- 2009-02-07 04:21:00 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2009-02-07 04:21:00 - TARGET=ia64
TB --- 2009-02-07 04:21:00 - TARGET_ARCH=ia64
TB --- 2009-02-07 04:21:00 - TZ=UTC
TB --- 2009-02-07 04:21:00 - __MAKE_CONF=/dev/null
TB --- 2009-02-07 04:21:00 - cd /src
TB --- 2009-02-07 04:21:00 - /usr/bin/make -B buildkernel KERNCONF=LINT
>>> Kernel build for LINT started on Sat Feb  7 04:21:00 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
[...]
awk -f /src/sys/tools/makeobjops.awk /src/sys/kern/serdev_if.m -h
awk -f /src/sys/tools/makeobjops.awk /src/sys/libkern/iconv_converter_if.m -h
awk -f /src/sys/tools/makeobjops.awk /src/sys/opencrypto/cryptodev_if.m -h
awk -f /src/sys/tools/makeobjops.awk /src/sys/dev/acpica/acpi_if.m -h
rm -f .newdep
/usr/bin/make -V CFILES -V SYSTEM_CFILES -V GEN_CFILES |  MKDEP_CPP="cc -E" CC="cc" xargs mkdep -a -f .newdep -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/ipfilter -I/src/sys/contrib/pf -I/src/sys/dev/ath -I/src/sys/dev/ath/ath_hal -I/src/sys/contrib/ngatm -I/src/sys/dev/twa -I/src/sys/gnu/fs/xfs/FreeBSD -I/src/sys/gnu/fs/xfs/FreeBSD/support -I/src/sys/gnu/fs/xfs -I/src/sys/contrib/opensolaris/compat -I/src/sys/dev/cxgb -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
/src/sys/dev/agp/agp.c:30:21: error: opt_agp.h: No such file or directory
mkdep: compile failed
*** Error code 1

Stop in /obj/ia64/src/sys/LINT.
*** Error code 1

Stop in /src.
*** Error code 1

Stop in /src.
TB --- 2009-02-07 04:23:05 - WARNING: /usr/bin/make returned exit code  1 
TB --- 2009-02-07 04:23:05 - ERROR: failed to build lint kernel
TB --- 2009-02-07 04:23:05 - 5420.59 user 394.77 system 6647.41 real


http://tinderbox.des.no/tinderbox-head-HEAD-ia64-ia64.full
From sziszi at bsd.hu  Fri Feb  6 22:44:26 2009
From: sziszi at bsd.hu (Szilveszter Adam)
Date: Fri Feb  6 22:44:34 2009
Subject: iwi broken? reproducible crash :(
In-Reply-To: <792298050902061403o5adc52ddx3b6a476a78e5c230@mail.gmail.com>
References: <792298050902061142k33f35be7sb19d566835e796ad@mail.gmail.com>
	<20090206205456.GA60974@baranyfelhocske.buza.adamsfamily.xx>
	<792298050902061403o5adc52ddx3b6a476a78e5c230@mail.gmail.com>
Message-ID: <20090207064418.GA2686@baranyfelhocske.buza.adamsfamily.xx>

On Fri, Feb 06, 2009 at 05:03:08PM -0500, L Campbell wrote:
> Since you're offering -- back on 7.x I had all kinds of problem with
> the adapter: I had to double the send/recvbuf_max and had to disable
> bgscan, otherwise the connection would die after ~6-12 hours,
> depending on usage. Did you ever have similar issues, or is something
> wonky with my machine?

Well, my experience varied with time and also with the AP used. I had no
real problems with a Linksys WRT54G with original firmware v2.2. And
this in spite of the fact that there are walls made of concrete in this
flat. By contrast, I *did* have major problems with an SMC AP, but that
may have just as well been the AP, because a ral(4) based card also made
a poor showing there (even under windows in another machine). I most
certainly did not have to change the send/recvbuf_max. I did not recall
real issues with bgscan either (although I tried to turn it off with the
SMC AP, but that did not help). However, I never tried roaming in any
configuration, and there never were more APs working at the same time.
Also, I use WPA2 and configured the card to very specifically scan for,
and associate with, only the one AP that I was using, so scanning may not
have been such a bother.

> I'll see if I can't grab some more hardware to test with to rule out
> hardware failure or a broken install on my part.

I would have also suggested wlandebug. Also, if you use wpa_supplicant,
you can use the -d switch to get debug output. To be honest, I did not try
enabling the debugging under iwi, so have no experience if it works.
Will try it just for kicks, and report back if it also panics for me.

-- 
Regards:

Szilveszter ADAM
Budapest
Hungary
From antonakis at gmail.com  Sat Feb  7 00:56:01 2009
From: antonakis at gmail.com (Antonios Anastasiadis)
Date: Sat Feb  7 00:56:32 2009
Subject: CFT: Graphics support for /boot/loader
In-Reply-To: <498CD00B.5010707@unsane.co.uk>
References: <200902052218.n15MIaEa026891@lurza.secnetix.de>
	<498BA5D5.4080100@samsco.org>
	<200902062244.19607.Thomas.Sparrevohn@btinternet.com>
	<498CD00B.5010707@unsane.co.uk>
Message-ID: <655a934b0902070025p5ab5ed21ncdb1e6efd3e21c24@mail.gmail.com>

Hi. Nice work!

I've got the red border on a TFT monitor by the way.
From rdivacky at freebsd.org  Sat Feb  7 01:56:50 2009
From: rdivacky at freebsd.org (Roman Divacky)
Date: Sat Feb  7 01:56:57 2009
Subject: running binaries under linux ABI
In-Reply-To: <OFF87DE685.7221BE38-ON85257555.0073AF88-85257555.00797A7A@jpmchase.com>
References: <OFF87DE685.7221BE38-ON85257555.0073AF88-85257555.00797A7A@jpmchase.com>
Message-ID: <20090207095352.GA21138@freebsd.org>

On Fri, Feb 06, 2009 at 05:06:51PM -0500, rohit.x.tripathi@jpmchase.com wrote:
> Hi, I suppose this question could be answered here, or someone can point 
> me in the right direction. (I read the linux abi doc before mailing)
> 
> I have a dual core laptop with 2 GB RAM which is correctly detected by a 
> linux app running under fedora 64bit:
> 
> rohit@tp/home/q/l64 $ q
> KDB+ 2.5 2009.02.05 Copyright (C) 1993-2009 Kx Systems
> l64/ 2()core 1978MB rohit tp 127.0.0.1 EXPIRE 2009.09.09
> 
> q).z.k
> 2009.02.05
> q)
> 
> Under FreeBSD i386 though, it seems to think that the RAM is 1MB and only 
> one core is available:
> 
> KDB+ 2.5 2009.02.05 Copyright (C) 1993-2009 Kx Systems
> l32/ 1()core -1MB rohit tp 255.255.255.255 EXPIRE 2009.09.09
> 
> q).z.k
> 2009.02.05
> q)

did you mount linprocfs?
From tinderbox at freebsd.org  Sat Feb  7 02:33:35 2009
From: tinderbox at freebsd.org (FreeBSD Tinderbox)
Date: Sat Feb  7 02:33:53 2009
Subject: [head tinderbox] failure on amd64/amd64
Message-ID: <20090207103331.B6CBC7302F@freebsd-current.sentex.ca>

TB --- 2009-02-07 08:00:00 - tinderbox 2.6 running on freebsd-current.sentex.ca
TB --- 2009-02-07 08:00:00 - starting HEAD tinderbox run for amd64/amd64
TB --- 2009-02-07 08:00:00 - cleaning the object tree
TB --- 2009-02-07 08:00:51 - cvsupping the source tree
TB --- 2009-02-07 08:00:51 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/amd64/amd64/supfile
TB --- 2009-02-07 08:00:59 - building world
TB --- 2009-02-07 08:00:59 - MAKEOBJDIRPREFIX=/obj
TB --- 2009-02-07 08:00:59 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2009-02-07 08:00:59 - TARGET=amd64
TB --- 2009-02-07 08:00:59 - TARGET_ARCH=amd64
TB --- 2009-02-07 08:00:59 - TZ=UTC
TB --- 2009-02-07 08:00:59 - __MAKE_CONF=/dev/null
TB --- 2009-02-07 08:00:59 - cd /src
TB --- 2009-02-07 08:00:59 - /usr/bin/make -B buildworld
>>> World build started on Sat Feb  7 08:01: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
>>> stage 5.1: building 32 bit shim libraries
>>> World build completed on Sat Feb  7 10:06:23 UTC 2009
TB --- 2009-02-07 10:06:23 - generating LINT kernel config
TB --- 2009-02-07 10:06:23 - cd /src/sys/amd64/conf
TB --- 2009-02-07 10:06:23 - /usr/bin/make -B LINT
TB --- 2009-02-07 10:06:23 - building LINT kernel
TB --- 2009-02-07 10:06:23 - MAKEOBJDIRPREFIX=/obj
TB --- 2009-02-07 10:06:23 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2009-02-07 10:06:23 - TARGET=amd64
TB --- 2009-02-07 10:06:23 - TARGET_ARCH=amd64
TB --- 2009-02-07 10:06:23 - TZ=UTC
TB --- 2009-02-07 10:06:23 - __MAKE_CONF=/dev/null
TB --- 2009-02-07 10:06:23 - cd /src
TB --- 2009-02-07 10:06:23 - /usr/bin/make -B buildkernel KERNCONF=LINT
>>> Kernel build for LINT started on Sat Feb  7 10:06:23 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
[...]
awk -f /src/sys/modules/usb2/controller/../../../conf/kmod_syms.awk usb2_controller.ko  export_syms | xargs -J% objcopy % usb2_controller.ko
objcopy --strip-debug usb2_controller.ko
===> usb2/controller_ehci (all)
cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc   -DHAVE_KERNEL_OPTION_HEADERS -include /obj/amd64/src/sys/LINT/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common  -fno-omit-frame-pointer -I/obj/amd64/src/sys/LINT -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 -std=iso9899:1999 -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes  -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual  -Wundef -Wno-pointer-sign -fformat-extensions -c /src/sys/modules/usb2/controller_ehci/../../../dev/usb2/controller/ehci2.c
/src/sys/modules/usb2/controller_ehci/../../../dev/usb2/controller/ehci2.c: In function 'ehci_init':
/src/sys/modules/usb2/controller_ehci/../../../dev/usb2/controller/ehci2.c:265: error: 'error' undeclared (first use in this function)
/src/sys/modules/usb2/controller_ehci/../../../dev/usb2/controller/ehci2.c:265: error: (Each undeclared identifier is reported only once
/src/sys/modules/usb2/controller_ehci/../../../dev/usb2/controller/ehci2.c:265: error: for each function it appears in.)
*** Error code 1

Stop in /src/sys/modules/usb2/controller_ehci.
*** Error code 1

Stop in /src/sys/modules/usb2.
*** Error code 1

Stop in /src/sys/modules.
*** Error code 1

Stop in /obj/amd64/src/sys/LINT.
*** Error code 1

Stop in /src.
*** Error code 1

Stop in /src.
TB --- 2009-02-07 10:33:31 - WARNING: /usr/bin/make returned exit code  1 
TB --- 2009-02-07 10:33:31 - ERROR: failed to build lint kernel
TB --- 2009-02-07 10:33:31 - 6997.34 user 674.03 system 9211.22 real


http://tinderbox.des.no/tinderbox-head-HEAD-amd64-amd64.full
From michael.gusek at web.de  Sat Feb  7 02:53:28 2009
From: michael.gusek at web.de (Michael Gusek)
Date: Sat Feb  7 02:53:35 2009
Subject: zfs: allocating allocated segment
In-Reply-To: <20090206232327.GA19383@hyperion.scode.org>
References: <200902051224.34442.michael.gusek@web.de>
	<20090206232327.GA19383@hyperion.scode.org>
Message-ID: <498D6824.8060303@web.de>

Peter Schuller schrieb:
>> I'm running a File server with zfs, 64 Bit, 4 GB Ram and RELENG_7. Two days 
>> ago i uploaded a file via ftp to the server and the server is crashing. After 
>> reboot FreeBSD can't import the zfs-pool. There is a kernel-message:
>>
>> panic: Solaris(panic): zfs: allocating allocated 
>> segment(offset=123456... size=74)
>>
>> cpuid = 0
>> Uptime: 14m22s
>> panic: bufwrite: buffer is not busy???
>>
>> Now i try to import the zfs-pool with a recent 8.0-current but with the same 
>> result. It's very important to me to access the pool, so did you have some 
>> idea's ?
>>     
>
> The ZFS panic is from space_map.c in space_map_add(), happening via
> zfs_panic_recover(). It in turn is affected by zfs_recover:
>
> /*                                                                                                                                                                                                                                             * zfs_recover can be set to nonzero to attempt to recover from                                                                                                                                                                                * otherwise-fatal errors, typically caused by on-disk corruption.  When                                                                                                                                                                       * set, calls to zfs_panic_recover() will turn into warning messages.                                                                                                                                                                          */
>
> Setting the vfs.zfs.recover loader variable to 1 might possibly
> help. However I have never tried using that option and I'm not
> familiar with the code, so I have no idea how safe it is. In
> particular since you then seem to be getting a secondary panic (the
> "buffer is not busy" which is from ffs_vfsops.
>
> On another note:
>
> http://www.google.com/search?client=opera&rls=en&q=zfs:+allocating+allocated+segment&sourceid=opera&ie=utf-8&oe=utf-8
>
> indicates you're not the only person who has seen similar
> errors. Unfortunately I cannot offer any insight other than to suggest
> digging through the google results.
>
> Was the original crash, prior to the mount problem, purely a software
> crash or was there, for example, a power outtage? I'm wondering
> whether there is any particular reason to believe there was some
> hardware/firmware fault causing corruption.
>
>   
Thank you for your response Petter,

on Monday i will give vfs.zfs.recover a try. The original crash was 
beeing a ftp upload. There was'nt a power outtage or another kernel 
message, so i don't think it is an hardware issue.

Regards,

Michael

From tinderbox at freebsd.org  Sat Feb  7 03:05:10 2009
From: tinderbox at freebsd.org (FreeBSD Tinderbox)
Date: Sat Feb  7 03:05:17 2009
Subject: [head tinderbox] failure on i386/i386
Message-ID: <20090207110504.F30A37302F@freebsd-current.sentex.ca>

TB --- 2009-02-07 09:09:47 - tinderbox 2.6 running on freebsd-current.sentex.ca
TB --- 2009-02-07 09:09:47 - starting HEAD tinderbox run for i386/i386
TB --- 2009-02-07 09:09:47 - cleaning the object tree
TB --- 2009-02-07 09:10:23 - cvsupping the source tree
TB --- 2009-02-07 09:10:23 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/i386/i386/supfile
TB --- 2009-02-07 09:10:32 - building world
TB --- 2009-02-07 09:10:32 - MAKEOBJDIRPREFIX=/obj
TB --- 2009-02-07 09:10:32 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2009-02-07 09:10:32 - TARGET=i386
TB --- 2009-02-07 09:10:32 - TARGET_ARCH=i386
TB --- 2009-02-07 09:10:32 - TZ=UTC
TB --- 2009-02-07 09:10:32 - __MAKE_CONF=/dev/null
TB --- 2009-02-07 09:10:32 - cd /src
TB --- 2009-02-07 09:10:32 - /usr/bin/make -B buildworld
>>> World build started on Sat Feb  7 09:10:34 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 Sat Feb  7 10:34:28 UTC 2009
TB --- 2009-02-07 10:34:28 - generating LINT kernel config
TB --- 2009-02-07 10:34:28 - cd /src/sys/i386/conf
TB --- 2009-02-07 10:34:28 - /usr/bin/make -B LINT
TB --- 2009-02-07 10:34:29 - building LINT kernel
TB --- 2009-02-07 10:34:29 - MAKEOBJDIRPREFIX=/obj
TB --- 2009-02-07 10:34:29 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2009-02-07 10:34:29 - TARGET=i386
TB --- 2009-02-07 10:34:29 - TARGET_ARCH=i386
TB --- 2009-02-07 10:34:29 - TZ=UTC
TB --- 2009-02-07 10:34:29 - __MAKE_CONF=/dev/null
TB --- 2009-02-07 10:34:29 - cd /src
TB --- 2009-02-07 10:34:29 - /usr/bin/make -B buildkernel KERNCONF=LINT
>>> Kernel build for LINT started on Sat Feb  7 10:34:29 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
[...]
ld -Bshareable  -d -warn-common -o usb2_controller.ko usb2_controller.kld
objcopy --strip-debug usb2_controller.ko
===> usb2/controller_ehci (all)
cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc   -DHAVE_KERNEL_OPTION_HEADERS -include /obj/src/sys/LINT/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common  -I/obj/src/sys/LINT -mno-align-long-strings -mpreferred-stack-boundary=2  -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -std=iso9899:1999 -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes  -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual  -Wundef -Wno-pointer-sign -fformat-extensions -c /src/sys/modules/usb2/controller_ehci/../../../dev/usb2/controller/ehci2.c
/src/sys/modules/usb2/controller_ehci/../../../dev/usb2/controller/ehci2.c: In function 'ehci_init':
/src/sys/modules/usb2/controller_ehci/../../../dev/usb2/controller/ehci2.c:265: error: 'error' undeclared (first use in this function)
/src/sys/modules/usb2/controller_ehci/../../../dev/usb2/controller/ehci2.c:265: error: (Each undeclared identifier is reported only once
/src/sys/modules/usb2/controller_ehci/../../../dev/usb2/controller/ehci2.c:265: error: for each function it appears in.)
*** Error code 1

Stop in /src/sys/modules/usb2/controller_ehci.
*** Error code 1

Stop in /src/sys/modules/usb2.
*** Error code 1

Stop in /src/sys/modules.
*** Error code 1

Stop in /obj/src/sys/LINT.
*** Error code 1

Stop in /src.
*** Error code 1

Stop in /src.
TB --- 2009-02-07 11:05:04 - WARNING: /usr/bin/make returned exit code  1 
TB --- 2009-02-07 11:05:04 - ERROR: failed to build lint kernel
TB --- 2009-02-07 11:05:04 - 5464.06 user 473.75 system 6917.70 real


http://tinderbox.des.no/tinderbox-head-HEAD-i386-i386.full
From tinderbox at freebsd.org  Sat Feb  7 04:21:07 2009
From: tinderbox at freebsd.org (FreeBSD Tinderbox)
Date: Sat Feb  7 04:21:13 2009
Subject: [head tinderbox] failure on i386/pc98
Message-ID: <20090207122103.5AD217302F@freebsd-current.sentex.ca>

TB --- 2009-02-07 10:33:31 - tinderbox 2.6 running on freebsd-current.sentex.ca
TB --- 2009-02-07 10:33:31 - starting HEAD tinderbox run for i386/pc98
TB --- 2009-02-07 10:33:31 - cleaning the object tree
TB --- 2009-02-07 10:33:59 - cvsupping the source tree
TB --- 2009-02-07 10:33:59 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/i386/pc98/supfile
TB --- 2009-02-07 10:34:06 - building world
TB --- 2009-02-07 10:34:06 - MAKEOBJDIRPREFIX=/obj
TB --- 2009-02-07 10:34:06 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2009-02-07 10:34:06 - TARGET=pc98
TB --- 2009-02-07 10:34:06 - TARGET_ARCH=i386
TB --- 2009-02-07 10:34:06 - TZ=UTC
TB --- 2009-02-07 10:34:06 - __MAKE_CONF=/dev/null
TB --- 2009-02-07 10:34:06 - cd /src
TB --- 2009-02-07 10:34:06 - /usr/bin/make -B buildworld
>>> World build started on Sat Feb  7 10:34:08 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 Sat Feb  7 11:54:56 UTC 2009
TB --- 2009-02-07 11:54:56 - generating LINT kernel config
TB --- 2009-02-07 11:54:56 - cd /src/sys/pc98/conf
TB --- 2009-02-07 11:54:56 - /usr/bin/make -B LINT
TB --- 2009-02-07 11:54:56 - building LINT kernel
TB --- 2009-02-07 11:54:56 - MAKEOBJDIRPREFIX=/obj
TB --- 2009-02-07 11:54:56 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2009-02-07 11:54:56 - TARGET=pc98
TB --- 2009-02-07 11:54:56 - TARGET_ARCH=i386
TB --- 2009-02-07 11:54:56 - TZ=UTC
TB --- 2009-02-07 11:54:56 - __MAKE_CONF=/dev/null
TB --- 2009-02-07 11:54:56 - cd /src
TB --- 2009-02-07 11:54:56 - /usr/bin/make -B buildkernel KERNCONF=LINT
>>> Kernel build for LINT started on Sat Feb  7 11:54:56 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
[...]
ld -Bshareable  -d -warn-common -o usb2_controller.ko usb2_controller.kld
objcopy --strip-debug usb2_controller.ko
===> usb2/controller_ehci (all)
cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc   -DHAVE_KERNEL_OPTION_HEADERS -include /obj/pc98/src/sys/LINT/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common  -I/obj/pc98/src/sys/LINT -mno-align-long-strings -mpreferred-stack-boundary=2  -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -std=iso9899:1999 -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes  -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual  -Wundef -Wno-pointer-sign -fformat-extensions -c /src/sys/modules/usb2/controller_ehci/../../../dev/usb2/controller/ehci2.c
/src/sys/modules/usb2/controller_ehci/../../../dev/usb2/controller/ehci2.c: In function 'ehci_init':
/src/sys/modules/usb2/controller_ehci/../../../dev/usb2/controller/ehci2.c:265: error: 'error' undeclared (first use in this function)
/src/sys/modules/usb2/controller_ehci/../../../dev/usb2/controller/ehci2.c:265: error: (Each undeclared identifier is reported only once
/src/sys/modules/usb2/controller_ehci/../../../dev/usb2/controller/ehci2.c:265: error: for each function it appears in.)
*** Error code 1

Stop in /src/sys/modules/usb2/controller_ehci.
*** Error code 1

Stop in /src/sys/modules/usb2.
*** Error code 1

Stop in /src/sys/modules.
*** Error code 1

Stop in /obj/pc98/src/sys/LINT.
*** Error code 1

Stop in /src.
*** Error code 1

Stop in /src.
TB --- 2009-02-07 12:21:03 - WARNING: /usr/bin/make returned exit code  1 
TB --- 2009-02-07 12:21:03 - ERROR: failed to build lint kernel
TB --- 2009-02-07 12:21:03 - 5186.16 user 473.02 system 6451.31 real


http://tinderbox.des.no/tinderbox-head-HEAD-i386-pc98.full
From hselasky at c2i.net  Sat Feb  7 04:52:10 2009
From: hselasky at c2i.net (Hans Petter Selasky)
Date: Sat Feb  7 04:52:25 2009
Subject: USB2/USB4BSD - code reference available
Message-ID: <200902071354.28941.hselasky@c2i.net>

Hi,

I've taken the time to generate a doxygen code reference for the new USB 
stack.

Result is available here:
http://www.selasky.org/hans_petter/usb4bsd/
http://www.selasky.org/hans_petter/usb4bsd/html/index.html

--HPS
From tinderbox at freebsd.org  Sat Feb  7 05:26:42 2009
From: tinderbox at freebsd.org (FreeBSD Tinderbox)
Date: Sat Feb  7 05:27:29 2009
Subject: [head tinderbox] failure on ia64/ia64
Message-ID: <20090207132635.A27507302F@freebsd-current.sentex.ca>

TB --- 2009-02-07 11:05:05 - tinderbox 2.6 running on freebsd-current.sentex.ca
TB --- 2009-02-07 11:05:05 - starting HEAD tinderbox run for ia64/ia64
TB --- 2009-02-07 11:05:05 - cleaning the object tree
TB --- 2009-02-07 11:05:28 - cvsupping the source tree
TB --- 2009-02-07 11:05:28 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/ia64/ia64/supfile
TB --- 2009-02-07 11:05:35 - building world
TB --- 2009-02-07 11:05:35 - MAKEOBJDIRPREFIX=/obj
TB --- 2009-02-07 11:05:35 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2009-02-07 11:05:35 - TARGET=ia64
TB --- 2009-02-07 11:05:35 - TARGET_ARCH=ia64
TB --- 2009-02-07 11:05:35 - TZ=UTC
TB --- 2009-02-07 11:05:35 - __MAKE_CONF=/dev/null
TB --- 2009-02-07 11:05:35 - cd /src
TB --- 2009-02-07 11:05:35 - /usr/bin/make -B buildworld
>>> World build started on Sat Feb  7 11:05:36 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 Sat Feb  7 12:52:25 UTC 2009
TB --- 2009-02-07 12:52:25 - generating LINT kernel config
TB --- 2009-02-07 12:52:25 - cd /src/sys/ia64/conf
TB --- 2009-02-07 12:52:25 - /usr/bin/make -B LINT
TB --- 2009-02-07 12:52:25 - building LINT kernel
TB --- 2009-02-07 12:52:25 - MAKEOBJDIRPREFIX=/obj
TB --- 2009-02-07 12:52:25 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2009-02-07 12:52:25 - TARGET=ia64
TB --- 2009-02-07 12:52:25 - TARGET_ARCH=ia64
TB --- 2009-02-07 12:52:25 - TZ=UTC
TB --- 2009-02-07 12:52:25 - __MAKE_CONF=/dev/null
TB --- 2009-02-07 12:52:25 - cd /src
TB --- 2009-02-07 12:52:25 - /usr/bin/make -B buildkernel KERNCONF=LINT
>>> Kernel build for LINT started on Sat Feb  7 12:52:25 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
[...]
ld -Bshareable  -d -warn-common -o usb2_controller.ko usb2_controller.kld
objcopy --strip-debug usb2_controller.ko
===> usb2/controller_ehci (all)
cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc   -DHAVE_KERNEL_OPTION_HEADERS -include /obj/ia64/src/sys/LINT/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common  -I/obj/ia64/src/sys/LINT -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -std=iso9899:1999 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes  -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual  -Wundef -Wno-pointer-sign -fformat-extensions -c /src/sys/modules/usb2/controller_ehci/../../../dev/usb2/controller/ehci2.c
/src/sys/modules/usb2/controller_ehci/../../../dev/usb2/controller/ehci2.c: In function 'ehci_init':
/src/sys/modules/usb2/controller_ehci/../../../dev/usb2/controller/ehci2.c:265: error: 'error' undeclared (first use in this function)
/src/sys/modules/usb2/controller_ehci/../../../dev/usb2/controller/ehci2.c:265: error: (Each undeclared identifier is reported only once
/src/sys/modules/usb2/controller_ehci/../../../dev/usb2/controller/ehci2.c:265: error: for each function it appears in.)
*** Error code 1

Stop in /src/sys/modules/usb2/controller_ehci.
*** Error code 1

Stop in /src/sys/modules/usb2.
*** Error code 1

Stop in /src/sys/modules.
*** Error code 1

Stop in /obj/ia64/src/sys/LINT.
*** Error code 1

Stop in /src.
*** Error code 1

Stop in /src.
TB --- 2009-02-07 13:26:35 - WARNING: /usr/bin/make returned exit code  1 
TB --- 2009-02-07 13:26:35 - ERROR: failed to build lint kernel
TB --- 2009-02-07 13:26:35 - 7153.05 user 469.70 system 8490.36 real


http://tinderbox.des.no/tinderbox-head-HEAD-ia64-ia64.full
From tinderbox at freebsd.org  Sat Feb  7 06:07:43 2009
From: tinderbox at freebsd.org (FreeBSD Tinderbox)
Date: Sat Feb  7 06:07:54 2009
Subject: [head tinderbox] failure on powerpc/powerpc
Message-ID: <20090207140739.9C3357302F@freebsd-current.sentex.ca>

TB --- 2009-02-07 12:21:03 - tinderbox 2.6 running on freebsd-current.sentex.ca
TB --- 2009-02-07 12:21:03 - starting HEAD tinderbox run for powerpc/powerpc
TB --- 2009-02-07 12:21:03 - cleaning the object tree
TB --- 2009-02-07 12:21:33 - cvsupping the source tree
TB --- 2009-02-07 12:21:33 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/powerpc/powerpc/supfile
TB --- 2009-02-07 12:21:40 - building world
TB --- 2009-02-07 12:21:40 - MAKEOBJDIRPREFIX=/obj
TB --- 2009-02-07 12:21:40 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2009-02-07 12:21:40 - TARGET=powerpc
TB --- 2009-02-07 12:21:40 - TARGET_ARCH=powerpc
TB --- 2009-02-07 12:21:40 - TZ=UTC
TB --- 2009-02-07 12:21:40 - __MAKE_CONF=/dev/null
TB --- 2009-02-07 12:21:40 - cd /src
TB --- 2009-02-07 12:21:40 - /usr/bin/make -B buildworld
>>> World build started on Sat Feb  7 12:21:42 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 Sat Feb  7 13:44:39 UTC 2009
TB --- 2009-02-07 13:44:39 - generating LINT kernel config
TB --- 2009-02-07 13:44:39 - cd /src/sys/powerpc/conf
TB --- 2009-02-07 13:44:39 - /usr/bin/make -B LINT
TB --- 2009-02-07 13:44:39 - building LINT kernel
TB --- 2009-02-07 13:44:39 - MAKEOBJDIRPREFIX=/obj
TB --- 2009-02-07 13:44:39 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2009-02-07 13:44:39 - TARGET=powerpc
TB --- 2009-02-07 13:44:39 - TARGET_ARCH=powerpc
TB --- 2009-02-07 13:44:39 - TZ=UTC
TB --- 2009-02-07 13:44:39 - __MAKE_CONF=/dev/null
TB --- 2009-02-07 13:44:39 - cd /src
TB --- 2009-02-07 13:44:39 - /usr/bin/make -B buildkernel KERNCONF=LINT
>>> Kernel build for LINT started on Sat Feb  7 13:44:39 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
[...]
ld -Bshareable  -d -warn-common -o usb2_controller.ko usb2_controller.kld
objcopy --strip-debug usb2_controller.ko
===> usb2/controller_ehci (all)
cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc   -DHAVE_KERNEL_OPTION_HEADERS -include /obj/powerpc/src/sys/LINT/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common  -mlongcall -fno-omit-frame-pointer -I/obj/powerpc/src/sys/LINT -msoft-float -ffreestanding -fstack-protector -std=iso9899:1999 -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes  -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual  -Wundef -Wno-pointer-sign -fformat-extensions -c /src/sys/modules/usb2/controller_ehci/../../../dev/usb2/controller/ehci2.c
/src/sys/modules/usb2/controller_ehci/../../../dev/usb2/controller/ehci2.c: In function 'ehci_init':
/src/sys/modules/usb2/controller_ehci/../../../dev/usb2/controller/ehci2.c:265: error: 'error' undeclared (first use in this function)
/src/sys/modules/usb2/controller_ehci/../../../dev/usb2/controller/ehci2.c:265: error: (Each undeclared identifier is reported only once
/src/sys/modules/usb2/controller_ehci/../../../dev/usb2/controller/ehci2.c:265: error: for each function it appears in.)
*** Error code 1

Stop in /src/sys/modules/usb2/controller_ehci.
*** Error code 1

Stop in /src/sys/modules/usb2.
*** Error code 1

Stop in /src/sys/modules.
*** Error code 1

Stop in /obj/powerpc/src/sys/LINT.
*** Error code 1

Stop in /src.
*** Error code 1

Stop in /src.
TB --- 2009-02-07 14:07:39 - WARNING: /usr/bin/make returned exit code  1 
TB --- 2009-02-07 14:07:39 - ERROR: failed to build lint kernel
TB --- 2009-02-07 14:07:39 - 5237.97 user 433.50 system 6396.20 real


http://tinderbox.des.no/tinderbox-head-HEAD-powerpc-powerpc.full
From tinderbox at freebsd.org  Sat Feb  7 07:11:54 2009
From: tinderbox at freebsd.org (FreeBSD Tinderbox)
Date: Sat Feb  7 07:12:11 2009
Subject: [head tinderbox] failure on sparc64/sparc64
Message-ID: <20090207151148.350A47302F@freebsd-current.sentex.ca>

TB --- 2009-02-07 13:26:35 - tinderbox 2.6 running on freebsd-current.sentex.ca
TB --- 2009-02-07 13:26:35 - starting HEAD tinderbox run for sparc64/sparc64
TB --- 2009-02-07 13:26:35 - cleaning the object tree
TB --- 2009-02-07 13:27:07 - cvsupping the source tree
TB --- 2009-02-07 13:27:07 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/sparc64/sparc64/supfile
TB --- 2009-02-07 13:27:14 - building world
TB --- 2009-02-07 13:27:14 - MAKEOBJDIRPREFIX=/obj
TB --- 2009-02-07 13:27:14 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2009-02-07 13:27:14 - TARGET=sparc64
TB --- 2009-02-07 13:27:14 - TARGET_ARCH=sparc64
TB --- 2009-02-07 13:27:14 - TZ=UTC
TB --- 2009-02-07 13:27:14 - __MAKE_CONF=/dev/null
TB --- 2009-02-07 13:27:14 - cd /src
TB --- 2009-02-07 13:27:14 - /usr/bin/make -B buildworld
>>> World build started on Sat Feb  7 13: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 Sat Feb  7 14:46:15 UTC 2009
TB --- 2009-02-07 14:46:15 - generating LINT kernel config
TB --- 2009-02-07 14:46:15 - cd /src/sys/sparc64/conf
TB --- 2009-02-07 14:46:15 - /usr/bin/make -B LINT
TB --- 2009-02-07 14:46:15 - building LINT kernel
TB --- 2009-02-07 14:46:15 - MAKEOBJDIRPREFIX=/obj
TB --- 2009-02-07 14:46:15 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2009-02-07 14:46:15 - TARGET=sparc64
TB --- 2009-02-07 14:46:15 - TARGET_ARCH=sparc64
TB --- 2009-02-07 14:46:15 - TZ=UTC
TB --- 2009-02-07 14:46:15 - __MAKE_CONF=/dev/null
TB --- 2009-02-07 14:46:15 - cd /src
TB --- 2009-02-07 14:46:15 - /usr/bin/make -B buildkernel KERNCONF=LINT
>>> Kernel build for LINT started on Sat Feb  7 14:46:15 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
[...]
ld -Bshareable  -d -warn-common -o usb2_controller.ko usb2_controller.kld
objcopy --strip-debug usb2_controller.ko
===> usb2/controller_ehci (all)
cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc   -DHAVE_KERNEL_OPTION_HEADERS -include /obj/sparc64/src/sys/LINT/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common  -I/obj/sparc64/src/sys/LINT -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -std=iso9899:1999 -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes  -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual  -Wundef -Wno-pointer-sign -fformat-extensions -c /src/sys/modules/usb2/controller_ehci/../../../dev/usb2/controller/ehci2.c
/src/sys/modules/usb2/controller_ehci/../../../dev/usb2/controller/ehci2.c: In function 'ehci_init':
/src/sys/modules/usb2/controller_ehci/../../../dev/usb2/controller/ehci2.c:265: error: 'error' undeclared (first use in this function)
/src/sys/modules/usb2/controller_ehci/../../../dev/usb2/controller/ehci2.c:265: error: (Each undeclared identifier is reported only once
/src/sys/modules/usb2/controller_ehci/../../../dev/usb2/controller/ehci2.c:265: error: for each function it appears in.)
*** Error code 1

Stop in /src/sys/modules/usb2/controller_ehci.
*** Error code 1

Stop in /src/sys/modules/usb2.
*** Error code 1

Stop in /src/sys/modules.
*** Error code 1

Stop in /obj/sparc64/src/sys/LINT.
*** Error code 1

Stop in /src.
*** Error code 1

Stop in /src.
TB --- 2009-02-07 15:11:48 - WARNING: /usr/bin/make returned exit code  1 
TB --- 2009-02-07 15:11:48 - ERROR: failed to build lint kernel
TB --- 2009-02-07 15:11:48 - 5100.05 user 439.48 system 6312.29 real


http://tinderbox.des.no/tinderbox-head-HEAD-sparc64-sparc64.full
From tinderbox at freebsd.org  Sat Feb  7 07:48:13 2009
From: tinderbox at freebsd.org (FreeBSD Tinderbox)
Date: Sat Feb  7 07:48:25 2009
Subject: [head tinderbox] failure on sparc64/sun4v
Message-ID: <20090207154808.4C8787302F@freebsd-current.sentex.ca>

TB --- 2009-02-07 14:07:39 - tinderbox 2.6 running on freebsd-current.sentex.ca
TB --- 2009-02-07 14:07:39 - starting HEAD tinderbox run for sparc64/sun4v
TB --- 2009-02-07 14:07:39 - cleaning the object tree
TB --- 2009-02-07 14:08:12 - cvsupping the source tree
TB --- 2009-02-07 14:08:12 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/sparc64/sun4v/supfile
TB --- 2009-02-07 14:08:22 - building world
TB --- 2009-02-07 14:08:22 - MAKEOBJDIRPREFIX=/obj
TB --- 2009-02-07 14:08:22 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2009-02-07 14:08:22 - TARGET=sun4v
TB --- 2009-02-07 14:08:22 - TARGET_ARCH=sparc64
TB --- 2009-02-07 14:08:22 - TZ=UTC
TB --- 2009-02-07 14:08:22 - __MAKE_CONF=/dev/null
TB --- 2009-02-07 14:08:22 - cd /src
TB --- 2009-02-07 14:08:22 - /usr/bin/make -B buildworld
>>> World build started on Sat Feb  7 14:08:23 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 Sat Feb  7 15:25:30 UTC 2009
TB --- 2009-02-07 15:25:30 - generating LINT kernel config
TB --- 2009-02-07 15:25:30 - cd /src/sys/sun4v/conf
TB --- 2009-02-07 15:25:30 - /usr/bin/make -B LINT
TB --- 2009-02-07 15:25:30 - building LINT kernel
TB --- 2009-02-07 15:25:30 - MAKEOBJDIRPREFIX=/obj
TB --- 2009-02-07 15:25:30 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2009-02-07 15:25:30 - TARGET=sun4v
TB --- 2009-02-07 15:25:30 - TARGET_ARCH=sparc64
TB --- 2009-02-07 15:25:30 - TZ=UTC
TB --- 2009-02-07 15:25:30 - __MAKE_CONF=/dev/null
TB --- 2009-02-07 15:25:30 - cd /src
TB --- 2009-02-07 15:25:30 - /usr/bin/make -B buildkernel KERNCONF=LINT
>>> Kernel build for LINT started on Sat Feb  7 15:25: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
[...]
ld -Bshareable  -d -warn-common -o usb2_controller.ko usb2_controller.kld
objcopy --strip-debug usb2_controller.ko
===> usb2/controller_ehci (all)
cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc   -DHAVE_KERNEL_OPTION_HEADERS -include /obj/sun4v/src/sys/LINT/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common  -I/obj/sun4v/src/sys/LINT -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -std=iso9899:1999 -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes  -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual  -Wundef -Wno-pointer-sign -fformat-extensions -c /src/sys/modules/usb2/controller_ehci/../../../dev/usb2/controller/ehci2.c
/src/sys/modules/usb2/controller_ehci/../../../dev/usb2/controller/ehci2.c: In function 'ehci_init':
/src/sys/modules/usb2/controller_ehci/../../../dev/usb2/controller/ehci2.c:265: error: 'error' undeclared (first use in this function)
/src/sys/modules/usb2/controller_ehci/../../../dev/usb2/controller/ehci2.c:265: error: (Each undeclared identifier is reported only once
/src/sys/modules/usb2/controller_ehci/../../../dev/usb2/controller/ehci2.c:265: error: for each function it appears in.)
*** Error code 1

Stop in /src/sys/modules/usb2/controller_ehci.
*** Error code 1

Stop in /src/sys/modules/usb2.
*** Error code 1

Stop in /src/sys/modules.
*** Error code 1

Stop in /obj/sun4v/src/sys/LINT.
*** Error code 1

Stop in /src.
*** Error code 1

Stop in /src.
TB --- 2009-02-07 15:48:08 - WARNING: /usr/bin/make returned exit code  1 
TB --- 2009-02-07 15:48:08 - ERROR: failed to build lint kernel
TB --- 2009-02-07 15:48:08 - 5061.14 user 437.35 system 6028.53 real


http://tinderbox.des.no/tinderbox-head-HEAD-sparc64-sun4v.full
From me at janh.de  Sat Feb  7 02:40:08 2009
From: me at janh.de (Jan Henrik Sylvester)
Date: Sat Feb  7 08:45:04 2009
Subject: iwi broken? reproducible crash :(
References: 792298050902061403o5adc52ddx3b6a476a78e5c230@mail.gmail.com
Message-ID: <498D64FC.2040509@janh.de>

L Campbell wrote:
 > Since you're offering -- back on 7.x I had all kinds of problem with
 > the adapter: I had to double the send/recvbuf_max and had to disable
 > bgscan, otherwise the connection would die after ~6-12 hours,
 > depending on usage. Did you ever have similar issues, or is something
 > wonky with my machine?

With iwi on 7.0, my connections would die regularly, too -- much more 
often than the 6 to 12 hours you state, sometimes up to every 15 minutes 
or so. wpa_supplicant did reconnect, but without it, I would have to do 
it manually.

It was still better than at 6.X, though, except for monitor mode, which 
would not receive packages on 7.0 at all.

Worst, sometimes the driver would get stuck, but the firmware could not 
be reloaded, since there was not enough dmaable (?) memory. Closing all 
application did help.

Since it took too much time to work around the problems and I wanted 
monitor, I got a 5 Euro ath based mini-pci from Ebay. I can only 
recommend that.

Cheers,
Jan Henrik
From mikulas at artax.karlin.mff.cuni.cz  Sat Feb  7 02:56:21 2009
From: mikulas at artax.karlin.mff.cuni.cz (Mikulas Patocka)
Date: Sat Feb  7 08:45:18 2009
Subject: HT 1000 SATA suggestion
Message-ID: <Pine.LNX.4.64.0902071102110.8765@artax.karlin.mff.cuni.cz>

Hi

I found that you have problems with HT1000 SATA in FreeBSD.

The problem is actually explained in the comments in the Linux driver.

For normal IDE & legacy SATA cards, the sequence to perform DMA is this:

- load register file
- submit the command to the disk
- setup dma sg table address and start dma

But for ServerWorks SATA chips this sequence is wrong. If there is some 
CPU latency and data from the disk arrive BEFORE you start the dma engine, 
the controller will hang or corrupt the data.

The correct sequence is to first start dma and then write the command to 
the taskfile. (Linux does this on serverworks SATA chips for both read and 
write commands, likely it doesn't cause problems with write commands)


I am not a FreeBSD user or developer and I don't have a FreeBSD machine 
here to test, I was just developing ServerWorks SATA driver for another 
system, read the Linux driver, searched for HT1000 on the internet and 
found some your discussion where you desperately tried to work around the 
bugs in the chip and ended up restricting the transfer size (and then 
restricted it even more because it still didn't work perfectly) ... then I 
looked into FreeBSD source and saw that you start DMA after sending the 
command. So I'm writing you this like a suggestion to try.

Mikulas
From tinderbox at freebsd.org  Sat Feb  7 10:25:51 2009
From: tinderbox at freebsd.org (FreeBSD Tinderbox)
Date: Sat Feb  7 10:25:58 2009
Subject: [head tinderbox] failure on amd64/amd64
Message-ID: <20090207182547.7DE8B7302F@freebsd-current.sentex.ca>

TB --- 2009-02-07 16:00:00 - tinderbox 2.6 running on freebsd-current.sentex.ca
TB --- 2009-02-07 16:00:00 - starting HEAD tinderbox run for amd64/amd64
TB --- 2009-02-07 16:00:00 - cleaning the object tree
TB --- 2009-02-07 16:00:44 - cvsupping the source tree
TB --- 2009-02-07 16:00:44 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/amd64/amd64/supfile
TB --- 2009-02-07 16:00:51 - building world
TB --- 2009-02-07 16:00:51 - MAKEOBJDIRPREFIX=/obj
TB --- 2009-02-07 16:00:51 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2009-02-07 16:00:51 - TARGET=amd64
TB --- 2009-02-07 16:00:51 - TARGET_ARCH=amd64
TB --- 2009-02-07 16:00:51 - TZ=UTC
TB --- 2009-02-07 16:00:51 - __MAKE_CONF=/dev/null
TB --- 2009-02-07 16:00:51 - cd /src
TB --- 2009-02-07 16:00:51 - /usr/bin/make -B buildworld
>>> World build started on Sat Feb  7 16:00:54 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 Sat Feb  7 17:58:32 UTC 2009
TB --- 2009-02-07 17:58:32 - generating LINT kernel config
TB --- 2009-02-07 17:58:32 - cd /src/sys/amd64/conf
TB --- 2009-02-07 17:58:32 - /usr/bin/make -B LINT
TB --- 2009-02-07 17:58:32 - building LINT kernel
TB --- 2009-02-07 17:58:32 - MAKEOBJDIRPREFIX=/obj
TB --- 2009-02-07 17:58:32 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2009-02-07 17:58:32 - TARGET=amd64
TB --- 2009-02-07 17:58:32 - TARGET_ARCH=amd64
TB --- 2009-02-07 17:58:32 - TZ=UTC
TB --- 2009-02-07 17:58:32 - __MAKE_CONF=/dev/null
TB --- 2009-02-07 17:58:32 - cd /src
TB --- 2009-02-07 17:58:32 - /usr/bin/make -B buildkernel KERNCONF=LINT
>>> Kernel build for LINT started on Sat Feb  7 17:58:32 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
[...]
awk -f /src/sys/modules/usb2/controller/../../../conf/kmod_syms.awk usb2_controller.ko  export_syms | xargs -J% objcopy % usb2_controller.ko
objcopy --strip-debug usb2_controller.ko
===> usb2/controller_ehci (all)
cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc   -DHAVE_KERNEL_OPTION_HEADERS -include /obj/amd64/src/sys/LINT/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common  -fno-omit-frame-pointer -I/obj/amd64/src/sys/LINT -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 -std=iso9899:1999 -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes  -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual  -Wundef -Wno-pointer-sign -fformat-extensions -c /src/sys/modules/usb2/controller_ehci/../../../dev/usb2/controller/ehci2.c
/src/sys/modules/usb2/controller_ehci/../../../dev/usb2/controller/ehci2.c: In function 'ehci_init':
/src/sys/modules/usb2/controller_ehci/../../../dev/usb2/controller/ehci2.c:265: error: 'error' undeclared (first use in this function)
/src/sys/modules/usb2/controller_ehci/../../../dev/usb2/controller/ehci2.c:265: error: (Each undeclared identifier is reported only once
/src/sys/modules/usb2/controller_ehci/../../../dev/usb2/controller/ehci2.c:265: error: for each function it appears in.)
*** Error code 1

Stop in /src/sys/modules/usb2/controller_ehci.
*** Error code 1

Stop in /src/sys/modules/usb2.
*** Error code 1

Stop in /src/sys/modules.
*** Error code 1

Stop in /obj/amd64/src/sys/LINT.
*** Error code 1

Stop in /src.
*** Error code 1

Stop in /src.
TB --- 2009-02-07 18:25:47 - WARNING: /usr/bin/make returned exit code  1 
TB --- 2009-02-07 18:25:47 - ERROR: failed to build lint kernel
TB --- 2009-02-07 18:25:47 - 6983.04 user 668.07 system 8746.95 real


http://tinderbox.des.no/tinderbox-head-HEAD-amd64-amd64.full
From sos at FreeBSD.ORG  Sat Feb  7 10:37:20 2009
From: sos at FreeBSD.ORG (=?ISO-8859-1?Q?S=F8ren_Schmidt?=)
Date: Sat Feb  7 10:37:28 2009
Subject: HT 1000 SATA suggestion
In-Reply-To: <Pine.LNX.4.64.0902071102110.8765@artax.karlin.mff.cuni.cz>
References: <Pine.LNX.4.64.0902071102110.8765@artax.karlin.mff.cuni.cz>
Message-ID: <E96EB43E-04C7-4082-829F-A71F5F04BF57@FreeBSD.ORG>


On 7Feb, 2009, at 11:27 , Mikulas Patocka wrote:

> Hi
>
> I found that you have problems with HT1000 SATA in FreeBSD.
>
> The problem is actually explained in the comments in the Linux driver.
>
> For normal IDE & legacy SATA cards, the sequence to perform DMA is  
> this:
>
> - load register file
> - submit the command to the disk
> - setup dma sg table address and start dma
>
> But for ServerWorks SATA chips this sequence is wrong. If there is  
> some
> CPU latency and data from the disk arrive BEFORE you start the dma  
> engine,
> the controller will hang or corrupt the data.
>
> The correct sequence is to first start dma and then write the  
> command to
> the taskfile. (Linux does this on serverworks SATA chips for both  
> read and
> write commands, likely it doesn't cause problems with write commands)


Just for the record this (amongst lots of other things) was tried long  
ago and does *not* solve the problem we were having.

I'm not sure what to make out of their reasoning though, as the result  
from the problem they describe would be that the amount of data  
transfered would be wrong, in that case the transaction will either  
fail or hang the controller, which in both cases should trigger error  
handling.

-S?ren






From mav at FreeBSD.org  Sat Feb  7 10:50:35 2009
From: mav at FreeBSD.org (Alexander Motin)
Date: Sat Feb  7 10:50:43 2009
Subject: To Alexander Motin aka Mav. HDA problems.
In-Reply-To: <E1LVs76-0005EI-SS@ffe13.ukr.net>
References: <E1LVs76-0005EI-SS@ffe13.ukr.net>
Message-ID: <498DD7FF.7010904@FreeBSD.org>

Yury Froloff wrote:
> --- ???????? ????????? ---
> ?? ????: Alexander Motin <mav@mavhome.dp.ua>
> ????: Yury Froloff <froloff@ukr.net>
> ????: 6 ???????, 22:27:26
> ????: Re: To Alexander Motin aka Mav. HDA problems.
> 
>     Yury Froloff wrote:
>      > ? ???? ???????? ?? ?????? ? ????? ?? ???? ?? ??????. ?????
>     ???????? ???, ?.?. ??? ??????? ???? ???????? ? ?? ???? ??? ????????.
>      > ????? ?????? ???. ????????, ??????????, ???????????. ?? - ???
>     ????????? ???????.
>      > ===================================================
>      > private# uname -a
>      > FreeBSD private.org 7.0-RELEASE FreeBSD 7.0-RELEASE #0: Sat Jan
>     31 11:21:07 EET 2009 root@private.org:/usr/obj/usr/src/sys/NEWKERN
>     amd64
>      > ===================================================
>      > private# cat /dev/sndstat
>      > FreeBSD Audio Driver (newpcm: 64bit 2007061600/amd64)
>      > Installed devices:
>      > pcm0: <ATI SB600 High Definition Audio Controller> at memory
>     0xfe020000 irq 16 kld snd_hda [20071129_0050] [MPSAFE] (1p:1v/1r:1v
>     channels duplex default)
>      > ===================================================
> 
>     ? ???? ????? ?????? ??????? 2007 ????. ???? ????? ?????? ? ??????????
>     ??????? ?? 7-STABLE ??? ?? ??????? ???? ????????? ????? ?????? ???????
>     /sys/dev/sound/pci/hda ? ??????????? ?????? snd_hda.
> 
>     You have old driver of year 2007. You should start from updating your
>     system to latest 7-STABLE or at least take /sys/dev/sound/pci/hda
>     folder
>     from there and rebuild your snd_hda module.
> 
> I've updated sources & rebuilt /sys/modules/sound/, but problem still 
> there... No sound. :(
>  
> private# cat /dev/sndstat
> FreeBSD Audio Driver (newpcm: 64bit 2007061600/amd64)
> Installed devices:
> pcm0: <ATI SB600 High Definition Audio Controller> at memory 0xfe020000 
> irq 16 kld snd_hda [20080420_0052] [MPSAFE] (1p:1v/1r:1v channels duplex 
> default)
> 
> Motherboard is "ASUS M2A-VM HDMI". HDMI is disabled in BIOS. I don't now 
> what goes wrong, but I hope we can find the solution.

20080420_0052 is better, but still not good. It is 7.1-RELEASE, but not 
the 7-STABLE. Present version in 7-STABLE now is 20090131_0127. You can 
fetch it from here: 
http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/sound/pci/hda/?only_with_tag=RELENG_7

If for some reason it does not help - send me verbose boot messages.

-- 
Alexander Motin
From olli at lurza.secnetix.de  Sat Feb  7 10:59:48 2009
From: olli at lurza.secnetix.de (Oliver Fromme)
Date: Sat Feb  7 10:59:55 2009
Subject: CFT: Graphics support for /boot/loader
In-Reply-To: <200902062244.19607.Thomas.Sparrevohn@btinternet.com>
Message-ID: <200902071859.n17Ixh4k075786@lurza.secnetix.de>

Thomas Sparrevohn wrote:
 > Agreed - Looks very cool - but I miss beastie - Would love to have it 
 > as an option like,  "WITH_SENTIMENTAL=YES"  that maybe would install
 > the old games as well....ahh well 

You can easily replace the background image, it's a
standard PCX image file.  You can even re-arrange the
position of the menu if necessary; there are simple
variable settings for that in the theme.conf file.

In fact I have prepared a theme with beastie; here's
a screen shot (preliminary):

http://www.secnetix.de/olli/FreeBSD/vloader/screenshot5.png

It's not included in the tarball that I've published
for the CFT, though.

Best regards
   Oliver

-- 
Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M.
Handelsregister: Registergericht Muenchen, HRA 74606,  Gesch?ftsfuehrung:
secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht M?n-
chen, HRB 125758,  Gesch?ftsf?hrer: Maik Bachmann, Olaf Erb, Ralf Gebhart

FreeBSD-Dienstleistungen, -Produkte und mehr:  http://www.secnetix.de/bsd

"Life is short (You need Python)"
        -- Bruce Eckel, ANSI C++ Comitee member, author
           of "Thinking in C++" and "Thinking in Java"
From dougb at FreeBSD.org  Sat Feb  7 11:44:14 2009
From: dougb at FreeBSD.org (Doug Barton)
Date: Sat Feb  7 11:44:21 2009
Subject: CFT: Graphics support for /boot/loader
In-Reply-To: <200902071859.n17Ixh4k075786@lurza.secnetix.de>
References: <200902071859.n17Ixh4k075786@lurza.secnetix.de>
Message-ID: <498DE489.8000309@FreeBSD.org>

Oliver,

This is very nice looking stuff. :)  The only thing I don't see is a
timer for bypassing the menu, an indication on the menu of where we're
at in the timer, and a way to suspend the timer. These features exist
in the current boot loader and I would hate to lose them.

If they exist and I'm simply missing it, my apologies.


Doug

-- 

    This .signature sanitized for your protection
From shuvaev at physik.uni-wuerzburg.de  Sat Feb  7 12:06:33 2009
From: shuvaev at physik.uni-wuerzburg.de (Alexey Shuvaev)
Date: Sat Feb  7 12:06:51 2009
Subject: CFT: Graphics support for /boot/loader
In-Reply-To: <498DE489.8000309@FreeBSD.org>
References: <200902071859.n17Ixh4k075786@lurza.secnetix.de>
	<498DE489.8000309@FreeBSD.org>
Message-ID: <20090207200630.GA50298@wep4035.physik.uni-wuerzburg.de>

On Sat, Feb 07, 2009 at 11:44:09AM -0800, Doug Barton wrote:
> Oliver,
> 
> This is very nice looking stuff. :)  The only thing I don't see is a
> timer for bypassing the menu, an indication on the menu of where we're
> at in the timer, and a way to suspend the timer. These features exist
> in the current boot loader and I would hate to lose them.
> 
> If they exist and I'm simply missing it, my apologies.
> 
For now the timer is in the upper-left corner. You might have missed it
due to the bad fit of 640x480 resolution on modern widescreen TFT monitors.

I want just to say that it works good on:

ICH9 based motherboard with G33 intel video card,
FreeBSD wep4035 8.0-CURRENT FreeBSD 8.0-CURRENT #0: Sat Feb  7 20:25:10 CET 2009     root@wep4035:/usr/obj/usr/src/sys/NOUSB  amd64
and gpt partitioned disk (but no zfs):
=>       34  976773101  ad6  GPT  (466G)
         34    1571840    1  freebsd-ufs  (768M)
    1571874    8388608    2  freebsd-swap  (4.0G)
    9960482       1024    3  freebsd-boot  (512K)
    9961506    8388608    4  freebsd-ufs  (4.0G)
   18350114     524288    5  freebsd-ufs  (256M)
   18874402  134217728    6  freebsd-ufs  (64G)
  153092130   33554432    7  freebsd-ufs  (16G)
  186646562   33554432    8  freebsd-ufs  (16G)
  220200994  756572141       - free -  (361G)

The monitor has 1680x1050 native resolution and I see the red border too.

Looks good, BTW is 640x480 in 4 bits per pixel the maximum of standard VGA?
Can you go higher or you are already in protected mode with (almost) no BIOS?
I mean, 640x480 is ok, but 4 bits per pixel... mmm... the same 16 colors as
in text mode... although with a palette...

Just my 0.02$,
Alexey.
From olli at lurza.secnetix.de  Sat Feb  7 12:25:51 2009
From: olli at lurza.secnetix.de (Oliver Fromme)
Date: Sat Feb  7 12:25:57 2009
Subject: CFT: Graphics support for /boot/loader
In-Reply-To: <498DE489.8000309@FreeBSD.org>
Message-ID: <200902072025.n17KPmGW079257@lurza.secnetix.de>


Doug Barton wrote:
 > This is very nice looking stuff. :)  The only thing I don't see is a
 > timer for bypassing the menu, an indication on the menu of where we're
 > at in the timer, and a way to suspend the timer. These features exist
 > in the current boot loader and I would hate to lose them.
 > 
 > If they exist and I'm simply missing it, my apologies.

No need to apologize.  Those features do exist.  There's
a countdown in the upper left corner, it respects the
autoboot_delay variable from loader.conf, and pressing
space (or any other key) will stop the countdown.

It is my intention that we will *NOT* lose any existing
features!

The only thing missing is an explanatory text, something
like "autoboot in x seconds, press space to pause".
I just haven't gotten around to put that in the .4th
code yet.  The screen layout isn't final anyway, there
will certainly be changes to some details.

The purpose of the CFT is to test the compatibility of
the graphics code with a wide range of hardware (real
and virtual) and BIOS, not to decide on the detailed
screen layout.  This can be changed easily anyway in
the .4th files.

By the way, I also just implemented that pressing <Esc>
will bring you back to the old-fashioned text menu
any time.

Best regards
   Oliver

-- 
Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M.
Handelsregister: Registergericht Muenchen, HRA 74606,  Gesch?ftsfuehrung:
secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht M?n-
chen, HRB 125758,  Gesch?ftsf?hrer: Maik Bachmann, Olaf Erb, Ralf Gebhart

FreeBSD-Dienstleistungen, -Produkte und mehr:  http://www.secnetix.de/bsd

"Whatever happened to the days when hacking started
at the cerebral cortex, and not at the keyboard?"
  --  Sid on userfriendly.org by Illiad, 2007-06-20
From dougb at FreeBSD.org  Sat Feb  7 12:30:44 2009
From: dougb at FreeBSD.org (Doug Barton)
Date: Sat Feb  7 12:30:50 2009
Subject: CFT: Graphics support for /boot/loader
In-Reply-To: <200902072025.n17KPmGW079257@lurza.secnetix.de>
References: <200902072025.n17KPmGW079257@lurza.secnetix.de>
Message-ID: <498DEF6F.7000509@FreeBSD.org>

Oliver Fromme wrote:
> Doug Barton wrote:
>  > This is very nice looking stuff. :)  The only thing I don't see is a
>  > timer for bypassing the menu, an indication on the menu of where we're
>  > at in the timer, and a way to suspend the timer. These features exist
>  > in the current boot loader and I would hate to lose them.
>  > 
>  > If they exist and I'm simply missing it, my apologies.
> 
> No need to apologize.  Those features do exist.  There's
> a countdown in the upper left corner,

*slaps forehead*  So that's what the number in the screen shot is,
thanks! :)

> it respects the
> autoboot_delay variable from loader.conf, and pressing
> space (or any other key) will stop the countdown.
>
> It is my intention that we will *NOT* lose any existing
> features!

Sounds great.

> The only thing missing is an explanatory text, something
> like "autoboot in x seconds, press space to pause".
> I just haven't gotten around to put that in the .4th
> code yet. 

Ok, no worries then. I look forward to being able to give this a whirl.

Doug

-- 

    This .signature sanitized for your protection
From freebsd at masm.elcom.ru  Sat Feb  7 13:09:26 2009
From: freebsd at masm.elcom.ru (Victor M. Blood)
Date: Sat Feb  7 13:09:33 2009
Subject: boot2.c need change or not.
Message-ID: <1572322913.20090208000132@masm.elcom.ru>

Hi, All.

for my configuration with ntld realy need change of boot2.c file, may
be we can add option `BOOT_CONFIG_LINE' to kernel build instead of use
/boot.config ?

    /* Process configuration file */

    autoboot = 1;
#if (defined(BOOT_CONFIG_LINE))
        memcpy(cmd, BOOT_CONFIG_LINE, sizeof(BOOT_CONFIG_LINE));
#else
    if ((ino = lookup(PATH_CONFIG)))
        fsread(ino, cmd, sizeof(cmd));
#endif

-- 
With all regards, Victor M. Blood.     mailto: freebsd@masm.elcom.ru
FTN: 2:5024/1.95@Fidonet.org, ICQ#3567656




From freebsd at masm.elcom.ru  Sat Feb  7 13:14:27 2009
From: freebsd at masm.elcom.ru (Victor M. Blood)
Date: Sat Feb  7 13:14:34 2009
Subject: boot2 and ntldr on sata2
Message-ID: <1977211221.20090207235528@masm.elcom.ru>

Hi, All.

People, may be realy need to add compile in boot command line, souch
as /boot.config staticaly in boot2.c instead of dynamic load it at
bootstrap process.


I have sata2 disk with 4 primary partition:
[ntfs]
[bsd] (/var, /usr)
[bsd] (/, swap)
[ntfs]

then system bootup from ntldr with bootpart 2.6 support, I got an
error `Invalid Partition'

then try boot with command `0:ad(4,3,a)/boot/loader bootstrap process
finished succesful!

I tryed set in /sys/boot/i386/boot2/boot2.c
dsk.drive=0; // may be here must be 0x80 ??
dsk.unit=4;
dsk.slice=3;
dsk.part=0;
i had error 1 lba 0 ... may be i realy set wrong number to dsr.drive

I try to add at line 258, after
    if ((ino = lookup(PATH_CONFIG)))
        fsread(ino, cmd, sizeof(cmd));
line:
     memcpy(cmd, "0:ad(4,3,a)/boot/loader\0\0", 24);

after this system boot sucess!


ps: sorry for my english.
-- 
With all regards, Victor M. Blood.     mailto: freebsd@masm.elcom.ru
FTN: 2:5024/1.95@Fidonet.org, ICQ#3567656




From tinderbox at freebsd.org  Sat Feb  7 13:41:52 2009
From: tinderbox at freebsd.org (FreeBSD Tinderbox)
Date: Sat Feb  7 13:41:59 2009
Subject: [head tinderbox] failure on ia64/ia64
Message-ID: <20090207214148.7F8497302F@freebsd-current.sentex.ca>

TB --- 2009-02-07 19:32:06 - tinderbox 2.6 running on freebsd-current.sentex.ca
TB --- 2009-02-07 19:32:06 - starting HEAD tinderbox run for ia64/ia64
TB --- 2009-02-07 19:32:06 - cleaning the object tree
TB --- 2009-02-07 19:32:35 - cvsupping the source tree
TB --- 2009-02-07 19:32:35 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/ia64/ia64/supfile
TB --- 2009-02-07 19:32:44 - building world
TB --- 2009-02-07 19:32:44 - MAKEOBJDIRPREFIX=/obj
TB --- 2009-02-07 19:32:44 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2009-02-07 19:32:44 - TARGET=ia64
TB --- 2009-02-07 19:32:44 - TARGET_ARCH=ia64
TB --- 2009-02-07 19:32:44 - TZ=UTC
TB --- 2009-02-07 19:32:44 - __MAKE_CONF=/dev/null
TB --- 2009-02-07 19:32:44 - cd /src
TB --- 2009-02-07 19:32:44 - /usr/bin/make -B buildworld
>>> World build started on Sat Feb  7 19:32:47 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 Sat Feb  7 21:19:57 UTC 2009
TB --- 2009-02-07 21:19:57 - generating LINT kernel config
TB --- 2009-02-07 21:19:57 - cd /src/sys/ia64/conf
TB --- 2009-02-07 21:19:57 - /usr/bin/make -B LINT
TB --- 2009-02-07 21:19:57 - building LINT kernel
TB --- 2009-02-07 21:19:57 - MAKEOBJDIRPREFIX=/obj
TB --- 2009-02-07 21:19:57 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2009-02-07 21:19:57 - TARGET=ia64
TB --- 2009-02-07 21:19:57 - TARGET_ARCH=ia64
TB --- 2009-02-07 21:19:57 - TZ=UTC
TB --- 2009-02-07 21:19:57 - __MAKE_CONF=/dev/null
TB --- 2009-02-07 21:19:57 - cd /src
TB --- 2009-02-07 21:19:57 - /usr/bin/make -B buildkernel KERNCONF=LINT
>>> Kernel build for LINT started on Sat Feb  7 21:19:58 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  vers.c
linking kernel
alias.o(.text+0x5720): In function `LibAliasUnaliasOut':
: undefined reference to `SctpAlias'
alias_db.o(.text+0x6170): In function `FindNewPortGroup':
: undefined reference to `AliasSctpTerm'
alias_db.o(.text+0x6190): In function `FindNewPortGroup':
: undefined reference to `AliasSctpInit'
*** Error code 1

Stop in /obj/ia64/src/sys/LINT.
*** Error code 1

Stop in /src.
*** Error code 1

Stop in /src.
TB --- 2009-02-07 21:41:47 - WARNING: /usr/bin/make returned exit code  1 
TB --- 2009-02-07 21:41:47 - ERROR: failed to build lint kernel
TB --- 2009-02-07 21:41:47 - 6488.53 user 442.01 system 7781.54 real


http://tinderbox.des.no/tinderbox-head-HEAD-ia64-ia64.full
From tinderbox at freebsd.org  Sat Feb  7 14:14:58 2009
From: tinderbox at freebsd.org (FreeBSD Tinderbox)
Date: Sat Feb  7 14:15:10 2009
Subject: [head tinderbox] failure on powerpc/powerpc
Message-ID: <20090207221455.6B41E7302F@freebsd-current.sentex.ca>

TB --- 2009-02-07 20:35:46 - tinderbox 2.6 running on freebsd-current.sentex.ca
TB --- 2009-02-07 20:35:46 - starting HEAD tinderbox run for powerpc/powerpc
TB --- 2009-02-07 20:35:46 - cleaning the object tree
TB --- 2009-02-07 20:36:08 - cvsupping the source tree
TB --- 2009-02-07 20:36:08 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/powerpc/powerpc/supfile
TB --- 2009-02-07 20:36:17 - building world
TB --- 2009-02-07 20:36:17 - MAKEOBJDIRPREFIX=/obj
TB --- 2009-02-07 20:36:17 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2009-02-07 20:36:17 - TARGET=powerpc
TB --- 2009-02-07 20:36:17 - TARGET_ARCH=powerpc
TB --- 2009-02-07 20:36:17 - TZ=UTC
TB --- 2009-02-07 20:36:17 - __MAKE_CONF=/dev/null
TB --- 2009-02-07 20:36:17 - cd /src
TB --- 2009-02-07 20:36:17 - /usr/bin/make -B buildworld
>>> World build started on Sat Feb  7 20:36:19 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 Sat Feb  7 21:59:53 UTC 2009
TB --- 2009-02-07 21:59:53 - generating LINT kernel config
TB --- 2009-02-07 21:59:53 - cd /src/sys/powerpc/conf
TB --- 2009-02-07 21:59:53 - /usr/bin/make -B LINT
TB --- 2009-02-07 21:59:53 - building LINT kernel
TB --- 2009-02-07 21:59:53 - MAKEOBJDIRPREFIX=/obj
TB --- 2009-02-07 21:59:53 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2009-02-07 21:59:53 - TARGET=powerpc
TB --- 2009-02-07 21:59:53 - TARGET_ARCH=powerpc
TB --- 2009-02-07 21:59:53 - TZ=UTC
TB --- 2009-02-07 21:59:53 - __MAKE_CONF=/dev/null
TB --- 2009-02-07 21:59:53 - cd /src
TB --- 2009-02-07 21:59:53 - /usr/bin/make -B buildkernel KERNCONF=LINT
>>> Kernel build for LINT started on Sat Feb  7 21:59:53 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
[...]
alias_db.o(.text+0x3af0): In function `LibAliasUninit':
: undefined reference to `AliasSctpTerm'
alias_db.o(.text+0x3ce0): In function `LibAliasInit':
: undefined reference to `AliasSctpTerm'
alias_db.o(.text+0x3ce8): In function `LibAliasInit':
: undefined reference to `AliasSctpInit'
alias_db.o(.text+0x3e08): In function `LibAliasInit':
: undefined reference to `AliasSctpInit'
*** Error code 1

Stop in /obj/powerpc/src/sys/LINT.
*** Error code 1

Stop in /src.
*** Error code 1

Stop in /src.
TB --- 2009-02-07 22:14:55 - WARNING: /usr/bin/make returned exit code  1 
TB --- 2009-02-07 22:14:55 - ERROR: failed to build lint kernel
TB --- 2009-02-07 22:14:55 - 4828.73 user 412.76 system 5948.66 real


http://tinderbox.des.no/tinderbox-head-HEAD-powerpc-powerpc.full
From tinderbox at freebsd.org  Sat Feb  7 15:18:07 2009
From: tinderbox at freebsd.org (FreeBSD Tinderbox)
Date: Sat Feb  7 15:18:13 2009
Subject: [head tinderbox] failure on sparc64/sparc64
Message-ID: <20090207231803.A68E97302F@freebsd-current.sentex.ca>

TB --- 2009-02-07 21:41:48 - tinderbox 2.6 running on freebsd-current.sentex.ca
TB --- 2009-02-07 21:41:48 - starting HEAD tinderbox run for sparc64/sparc64
TB --- 2009-02-07 21:41:48 - cleaning the object tree
TB --- 2009-02-07 21:42:22 - cvsupping the source tree
TB --- 2009-02-07 21:42:22 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/sparc64/sparc64/supfile
TB --- 2009-02-07 21:42:32 - building world
TB --- 2009-02-07 21:42:32 - MAKEOBJDIRPREFIX=/obj
TB --- 2009-02-07 21:42:32 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2009-02-07 21:42:32 - TARGET=sparc64
TB --- 2009-02-07 21:42:32 - TARGET_ARCH=sparc64
TB --- 2009-02-07 21:42:32 - TZ=UTC
TB --- 2009-02-07 21:42:32 - __MAKE_CONF=/dev/null
TB --- 2009-02-07 21:42:32 - cd /src
TB --- 2009-02-07 21:42:32 - /usr/bin/make -B buildworld
>>> World build started on Sat Feb  7 21:42:34 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 Sat Feb  7 23:01:48 UTC 2009
TB --- 2009-02-07 23:01:48 - generating LINT kernel config
TB --- 2009-02-07 23:01:48 - cd /src/sys/sparc64/conf
TB --- 2009-02-07 23:01:48 - /usr/bin/make -B LINT
TB --- 2009-02-07 23:01:48 - building LINT kernel
TB --- 2009-02-07 23:01:48 - MAKEOBJDIRPREFIX=/obj
TB --- 2009-02-07 23:01:48 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2009-02-07 23:01:48 - TARGET=sparc64
TB --- 2009-02-07 23:01:48 - TARGET_ARCH=sparc64
TB --- 2009-02-07 23:01:48 - TZ=UTC
TB --- 2009-02-07 23:01:48 - __MAKE_CONF=/dev/null
TB --- 2009-02-07 23:01:48 - cd /src
TB --- 2009-02-07 23:01:48 - /usr/bin/make -B buildkernel KERNCONF=LINT
>>> Kernel build for LINT started on Sat Feb  7 23:01:48 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
[...]
alias_db.o(.text+0x34fc): In function `LibAliasUninit':
: undefined reference to `AliasSctpTerm'
alias_db.o(.text+0x36d4): In function `LibAliasInit':
: undefined reference to `AliasSctpTerm'
alias_db.o(.text+0x36dc): In function `LibAliasInit':
: undefined reference to `AliasSctpInit'
alias_db.o(.text+0x3894): In function `LibAliasInit':
: undefined reference to `AliasSctpInit'
*** Error code 1

Stop in /obj/sparc64/src/sys/LINT.
*** Error code 1

Stop in /src.
*** Error code 1

Stop in /src.
TB --- 2009-02-07 23:18:03 - WARNING: /usr/bin/make returned exit code  1 
TB --- 2009-02-07 23:18:03 - ERROR: failed to build lint kernel
TB --- 2009-02-07 23:18:03 - 4633.48 user 415.73 system 5774.73 real


http://tinderbox.des.no/tinderbox-head-HEAD-sparc64-sparc64.full
From tinderbox at freebsd.org  Sat Feb  7 15:47:20 2009
From: tinderbox at freebsd.org (FreeBSD Tinderbox)
Date: Sat Feb  7 15:47:32 2009
Subject: [head tinderbox] failure on sparc64/sun4v
Message-ID: <20090207234717.8669F7302F@freebsd-current.sentex.ca>

TB --- 2009-02-07 22:14:55 - tinderbox 2.6 running on freebsd-current.sentex.ca
TB --- 2009-02-07 22:14:55 - starting HEAD tinderbox run for sparc64/sun4v
TB --- 2009-02-07 22:14:55 - cleaning the object tree
TB --- 2009-02-07 22:15:28 - cvsupping the source tree
TB --- 2009-02-07 22:15:28 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/sparc64/sun4v/supfile
TB --- 2009-02-07 22:15:36 - building world
TB --- 2009-02-07 22:15:36 - MAKEOBJDIRPREFIX=/obj
TB --- 2009-02-07 22:15:36 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2009-02-07 22:15:36 - TARGET=sun4v
TB --- 2009-02-07 22:15:36 - TARGET_ARCH=sparc64
TB --- 2009-02-07 22:15:36 - TZ=UTC
TB --- 2009-02-07 22:15:36 - __MAKE_CONF=/dev/null
TB --- 2009-02-07 22:15:36 - cd /src
TB --- 2009-02-07 22:15:36 - /usr/bin/make -B buildworld
>>> World build started on Sat Feb  7 22:15:37 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 Sat Feb  7 23:32:50 UTC 2009
TB --- 2009-02-07 23:32:50 - generating LINT kernel config
TB --- 2009-02-07 23:32:50 - cd /src/sys/sun4v/conf
TB --- 2009-02-07 23:32:50 - /usr/bin/make -B LINT
TB --- 2009-02-07 23:32:50 - building LINT kernel
TB --- 2009-02-07 23:32:50 - MAKEOBJDIRPREFIX=/obj
TB --- 2009-02-07 23:32:50 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2009-02-07 23:32:50 - TARGET=sun4v
TB --- 2009-02-07 23:32:50 - TARGET_ARCH=sparc64
TB --- 2009-02-07 23:32:50 - TZ=UTC
TB --- 2009-02-07 23:32:50 - __MAKE_CONF=/dev/null
TB --- 2009-02-07 23:32:50 - cd /src
TB --- 2009-02-07 23:32:50 - /usr/bin/make -B buildkernel KERNCONF=LINT
>>> Kernel build for LINT started on Sat Feb  7 23:32:50 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
[...]
alias_db.o(.text+0x34fc): In function `LibAliasUninit':
: undefined reference to `AliasSctpTerm'
alias_db.o(.text+0x36d4): In function `LibAliasInit':
: undefined reference to `AliasSctpTerm'
alias_db.o(.text+0x36dc): In function `LibAliasInit':
: undefined reference to `AliasSctpInit'
alias_db.o(.text+0x3894): In function `LibAliasInit':
: undefined reference to `AliasSctpInit'
*** Error code 1

Stop in /obj/sun4v/src/sys/LINT.
*** Error code 1

Stop in /src.
*** Error code 1

Stop in /src.
TB --- 2009-02-07 23:47:17 - WARNING: /usr/bin/make returned exit code  1 
TB --- 2009-02-07 23:47:17 - ERROR: failed to build lint kernel
TB --- 2009-02-07 23:47:17 - 4599.20 user 413.13 system 5541.85 real


http://tinderbox.des.no/tinderbox-head-HEAD-sparc64-sun4v.full
From bruce at cran.org.uk  Sat Feb  7 16:17:05 2009
From: bruce at cran.org.uk (Bruce Cran)
Date: Sat Feb  7 16:17:11 2009
Subject: "Fatal trap" when unloading usb2_controller_ehci
Message-ID: <20090208001656.48a1a14d@gluon>

Unloading usb2_controller_ehci is crashing FreeBSD on -CURRENT
from a few days ago, resulting in a "Fatal trap" that isn't immediately
fatal but ends up knocking out the rest of the system.

Shortly after issuing a kldunload, the kernel drops into DDB with:

Fatal trap 30: reserved (unknown) fault while in kernel mode
cpuid = 0; apic id = 00
instruction pointer = 0x8 : 0xffffffff804bc646
stack pointer       = 0x10: 0xfffffffe40023b70
frame pointer       = 0x10: 0xfffffffe40023b80
code segment        = base 0x0, limit 0xfffff, type 0x1b
processor eflags    = interrupt enabled, IOPL = 0
current process     = 11 (idle : cpu0)
[thread pid 11 tid 100004]
Stopped at acpi_cpu_c1+0x6 : leave

A backtrace just shows that the idle task was running at the time of
the trap.  Attempting to continue results in a load of "calcru: runtime
went backwards" messages followed by the ATA driver dying with:

WARNING - SETFEATURES SET TRANSFER MODE taskqueue timeout - completing
request directly

Then follows similar messages about SET_MULTI, ENABLE RCACHE,
ENABLE_WCACHE and WRITE_DMA48 etc.

-- 
Bruce Cran
From tinderbox at freebsd.org  Sat Feb  7 18:16:38 2009
From: tinderbox at freebsd.org (FreeBSD Tinderbox)
Date: Sat Feb  7 18:16:55 2009
Subject: [head tinderbox] failure on amd64/amd64
Message-ID: <20090208021634.718AD7302F@freebsd-current.sentex.ca>

TB --- 2009-02-08 00:00:00 - tinderbox 2.6 running on freebsd-current.sentex.ca
TB --- 2009-02-08 00:00:00 - starting HEAD tinderbox run for amd64/amd64
TB --- 2009-02-08 00:00:01 - cleaning the object tree
TB --- 2009-02-08 00:00:43 - cvsupping the source tree
TB --- 2009-02-08 00:00:43 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/amd64/amd64/supfile
TB --- 2009-02-08 00:00:51 - building world
TB --- 2009-02-08 00:00:51 - MAKEOBJDIRPREFIX=/obj
TB --- 2009-02-08 00:00:51 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2009-02-08 00:00:51 - TARGET=amd64
TB --- 2009-02-08 00:00:51 - TARGET_ARCH=amd64
TB --- 2009-02-08 00:00:51 - TZ=UTC
TB --- 2009-02-08 00:00:51 - __MAKE_CONF=/dev/null
TB --- 2009-02-08 00:00:51 - cd /src
TB --- 2009-02-08 00:00:51 - /usr/bin/make -B buildworld
>>> World build started on Sun Feb  8 00:00:53 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 Sun Feb  8 01:58:49 UTC 2009
TB --- 2009-02-08 01:58:49 - generating LINT kernel config
TB --- 2009-02-08 01:58:49 - cd /src/sys/amd64/conf
TB --- 2009-02-08 01:58:49 - /usr/bin/make -B LINT
TB --- 2009-02-08 01:58:49 - building LINT kernel
TB --- 2009-02-08 01:58:49 - MAKEOBJDIRPREFIX=/obj
TB --- 2009-02-08 01:58:49 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2009-02-08 01:58:49 - TARGET=amd64
TB --- 2009-02-08 01:58:49 - TARGET_ARCH=amd64
TB --- 2009-02-08 01:58:49 - TZ=UTC
TB --- 2009-02-08 01:58:49 - __MAKE_CONF=/dev/null
TB --- 2009-02-08 01:58:49 - cd /src
TB --- 2009-02-08 01:58:49 - /usr/bin/make -B buildkernel KERNCONF=LINT
>>> Kernel build for LINT started on Sun Feb  8 01:58:49 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
[...]
alias_db.o(.text+0x2cfd): In function `LibAliasUninit':
: undefined reference to `AliasSctpTerm'
alias_db.o(.text+0x2e89): In function `LibAliasInit':
: undefined reference to `AliasSctpTerm'
alias_db.o(.text+0x2e91): In function `LibAliasInit':
: undefined reference to `AliasSctpInit'
alias_db.o(.text+0x2ff4): In function `LibAliasInit':
: undefined reference to `AliasSctpInit'
*** Error code 1

Stop in /obj/amd64/src/sys/LINT.
*** Error code 1

Stop in /src.
*** Error code 1

Stop in /src.
TB --- 2009-02-08 02:16:34 - WARNING: /usr/bin/make returned exit code  1 
TB --- 2009-02-08 02:16:34 - ERROR: failed to build lint kernel
TB --- 2009-02-08 02:16:34 - 6482.38 user 642.36 system 8193.27 real


http://tinderbox.des.no/tinderbox-head-HEAD-amd64-amd64.full
From tinderbox at freebsd.org  Sat Feb  7 18:46:53 2009
From: tinderbox at freebsd.org (FreeBSD Tinderbox)
Date: Sat Feb  7 18:46:59 2009
Subject: [head tinderbox] failure on i386/i386
Message-ID: <20090208024649.F39C97302F@freebsd-current.sentex.ca>

TB --- 2009-02-08 01:06:10 - tinderbox 2.6 running on freebsd-current.sentex.ca
TB --- 2009-02-08 01:06:10 - starting HEAD tinderbox run for i386/i386
TB --- 2009-02-08 01:06:10 - cleaning the object tree
TB --- 2009-02-08 01:06:39 - cvsupping the source tree
TB --- 2009-02-08 01:06:39 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/i386/i386/supfile
TB --- 2009-02-08 01:06:48 - building world
TB --- 2009-02-08 01:06:48 - MAKEOBJDIRPREFIX=/obj
TB --- 2009-02-08 01:06:48 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2009-02-08 01:06:48 - TARGET=i386
TB --- 2009-02-08 01:06:48 - TARGET_ARCH=i386
TB --- 2009-02-08 01:06:48 - TZ=UTC
TB --- 2009-02-08 01:06:48 - __MAKE_CONF=/dev/null
TB --- 2009-02-08 01:06:48 - cd /src
TB --- 2009-02-08 01:06:48 - /usr/bin/make -B buildworld
>>> World build started on Sun Feb  8 01:06:49 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 Sun Feb  8 02:27:32 UTC 2009
TB --- 2009-02-08 02:27:32 - generating LINT kernel config
TB --- 2009-02-08 02:27:32 - cd /src/sys/i386/conf
TB --- 2009-02-08 02:27:32 - /usr/bin/make -B LINT
TB --- 2009-02-08 02:27:32 - building LINT kernel
TB --- 2009-02-08 02:27:32 - MAKEOBJDIRPREFIX=/obj
TB --- 2009-02-08 02:27:32 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2009-02-08 02:27:32 - TARGET=i386
TB --- 2009-02-08 02:27:32 - TARGET_ARCH=i386
TB --- 2009-02-08 02:27:32 - TZ=UTC
TB --- 2009-02-08 02:27:32 - __MAKE_CONF=/dev/null
TB --- 2009-02-08 02:27:32 - cd /src
TB --- 2009-02-08 02:27:32 - /usr/bin/make -B buildkernel KERNCONF=LINT
>>> Kernel build for LINT started on Sun Feb  8 02:27:32 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
[...]
alias_db.o(.text+0x2e4a): In function `LibAliasUninit':
: undefined reference to `AliasSctpTerm'
alias_db.o(.text+0x2fde): In function `LibAliasInit':
: undefined reference to `AliasSctpTerm'
alias_db.o(.text+0x2fe6): In function `LibAliasInit':
: undefined reference to `AliasSctpInit'
alias_db.o(.text+0x3126): In function `LibAliasInit':
: undefined reference to `AliasSctpInit'
*** Error code 1

Stop in /obj/src/sys/LINT.
*** Error code 1

Stop in /src.
*** Error code 1

Stop in /src.
TB --- 2009-02-08 02:46:49 - WARNING: /usr/bin/make returned exit code  1 
TB --- 2009-02-08 02:46:49 - ERROR: failed to build lint kernel
TB --- 2009-02-08 02:46:49 - 4874.24 user 440.17 system 6039.47 real


http://tinderbox.des.no/tinderbox-head-HEAD-i386-i386.full
From tinderbox at freebsd.org  Sat Feb  7 19:54:41 2009
From: tinderbox at freebsd.org (FreeBSD Tinderbox)
Date: Sat Feb  7 19:54:58 2009
Subject: [head tinderbox] failure on i386/pc98
Message-ID: <20090208035437.AFCDA7302F@freebsd-current.sentex.ca>

TB --- 2009-02-08 02:16:34 - tinderbox 2.6 running on freebsd-current.sentex.ca
TB --- 2009-02-08 02:16:34 - starting HEAD tinderbox run for i386/pc98
TB --- 2009-02-08 02:16:34 - cleaning the object tree
TB --- 2009-02-08 02:17:02 - cvsupping the source tree
TB --- 2009-02-08 02:17:02 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/i386/pc98/supfile
TB --- 2009-02-08 02:17:10 - building world
TB --- 2009-02-08 02:17:10 - MAKEOBJDIRPREFIX=/obj
TB --- 2009-02-08 02:17:10 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2009-02-08 02:17:10 - TARGET=pc98
TB --- 2009-02-08 02:17:10 - TARGET_ARCH=i386
TB --- 2009-02-08 02:17:10 - TZ=UTC
TB --- 2009-02-08 02:17:10 - __MAKE_CONF=/dev/null
TB --- 2009-02-08 02:17:10 - cd /src
TB --- 2009-02-08 02:17:10 - /usr/bin/make -B buildworld
>>> World build started on Sun Feb  8 02:17:12 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 Sun Feb  8 03:37:36 UTC 2009
TB --- 2009-02-08 03:37:36 - generating LINT kernel config
TB --- 2009-02-08 03:37:36 - cd /src/sys/pc98/conf
TB --- 2009-02-08 03:37:36 - /usr/bin/make -B LINT
TB --- 2009-02-08 03:37:36 - building LINT kernel
TB --- 2009-02-08 03:37:36 - MAKEOBJDIRPREFIX=/obj
TB --- 2009-02-08 03:37:36 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2009-02-08 03:37:36 - TARGET=pc98
TB --- 2009-02-08 03:37:36 - TARGET_ARCH=i386
TB --- 2009-02-08 03:37:36 - TZ=UTC
TB --- 2009-02-08 03:37:36 - __MAKE_CONF=/dev/null
TB --- 2009-02-08 03:37:36 - cd /src
TB --- 2009-02-08 03:37:36 - /usr/bin/make -B buildkernel KERNCONF=LINT
>>> Kernel build for LINT started on Sun Feb  8 03:37: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
[...]
alias_db.o(.text+0x2e4a): In function `LibAliasUninit':
: undefined reference to `AliasSctpTerm'
alias_db.o(.text+0x2fde): In function `LibAliasInit':
: undefined reference to `AliasSctpTerm'
alias_db.o(.text+0x2fe6): In function `LibAliasInit':
: undefined reference to `AliasSctpInit'
alias_db.o(.text+0x3126): In function `LibAliasInit':
: undefined reference to `AliasSctpInit'
*** Error code 1

Stop in /obj/pc98/src/sys/LINT.
*** Error code 1

Stop in /src.
*** Error code 1

Stop in /src.
TB --- 2009-02-08 03:54:37 - WARNING: /usr/bin/make returned exit code  1 
TB --- 2009-02-08 03:54:37 - ERROR: failed to build lint kernel
TB --- 2009-02-08 03:54:37 - 4695.36 user 443.58 system 5882.92 real


http://tinderbox.des.no/tinderbox-head-HEAD-i386-pc98.full
From tinderbox at freebsd.org  Sat Feb  7 20:56:36 2009
From: tinderbox at freebsd.org (FreeBSD Tinderbox)
Date: Sat Feb  7 20:56:58 2009
Subject: [head tinderbox] failure on ia64/ia64
Message-ID: <20090208045632.99E5F7302F@freebsd-current.sentex.ca>

TB --- 2009-02-08 02:46:50 - tinderbox 2.6 running on freebsd-current.sentex.ca
TB --- 2009-02-08 02:46:50 - starting HEAD tinderbox run for ia64/ia64
TB --- 2009-02-08 02:46:50 - cleaning the object tree
TB --- 2009-02-08 02:47:11 - cvsupping the source tree
TB --- 2009-02-08 02:47:11 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/ia64/ia64/supfile
TB --- 2009-02-08 02:47:21 - building world
TB --- 2009-02-08 02:47:21 - MAKEOBJDIRPREFIX=/obj
TB --- 2009-02-08 02:47:21 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2009-02-08 02:47:21 - TARGET=ia64
TB --- 2009-02-08 02:47:21 - TARGET_ARCH=ia64
TB --- 2009-02-08 02:47:21 - TZ=UTC
TB --- 2009-02-08 02:47:21 - __MAKE_CONF=/dev/null
TB --- 2009-02-08 02:47:21 - cd /src
TB --- 2009-02-08 02:47:21 - /usr/bin/make -B buildworld
>>> World build started on Sun Feb  8 02:47:23 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 Sun Feb  8 04:34:01 UTC 2009
TB --- 2009-02-08 04:34:01 - generating LINT kernel config
TB --- 2009-02-08 04:34:01 - cd /src/sys/ia64/conf
TB --- 2009-02-08 04:34:01 - /usr/bin/make -B LINT
TB --- 2009-02-08 04:34:01 - building LINT kernel
TB --- 2009-02-08 04:34:01 - MAKEOBJDIRPREFIX=/obj
TB --- 2009-02-08 04:34:01 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2009-02-08 04:34:01 - TARGET=ia64
TB --- 2009-02-08 04:34:01 - TARGET_ARCH=ia64
TB --- 2009-02-08 04:34:01 - TZ=UTC
TB --- 2009-02-08 04:34:01 - __MAKE_CONF=/dev/null
TB --- 2009-02-08 04:34:01 - cd /src
TB --- 2009-02-08 04:34:01 - /usr/bin/make -B buildkernel KERNCONF=LINT
>>> Kernel build for LINT started on Sun Feb  8 04:34:01 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  vers.c
linking kernel
alias.o(.text+0x5720): In function `LibAliasUnaliasOut':
: undefined reference to `SctpAlias'
alias_db.o(.text+0x6170): In function `FindNewPortGroup':
: undefined reference to `AliasSctpTerm'
alias_db.o(.text+0x6190): In function `FindNewPortGroup':
: undefined reference to `AliasSctpInit'
*** Error code 1

Stop in /obj/ia64/src/sys/LINT.
*** Error code 1

Stop in /src.
*** Error code 1

Stop in /src.
TB --- 2009-02-08 04:56:31 - WARNING: /usr/bin/make returned exit code  1 
TB --- 2009-02-08 04:56:31 - ERROR: failed to build lint kernel
TB --- 2009-02-08 04:56:31 - 6487.62 user 441.77 system 7781.62 real


http://tinderbox.des.no/tinderbox-head-HEAD-ia64-ia64.full
From alfred at freebsd.org  Sat Feb  7 21:21:11 2009
From: alfred at freebsd.org (Alfred Perlstein)
Date: Sat Feb  7 21:21:25 2009
Subject: HEADSUP usb2/usb4bsd to become default in GENERIC
In-Reply-To: <498C013B.4000405@FreeBSD.org>
References: <20090206045349.GQ78804@elvis.mu.org>
	<498C013B.4000405@FreeBSD.org>
Message-ID: <20090208052110.GY78804@elvis.mu.org>

* Maxim Sobolev <sobomax@FreeBSD.org> [090206 01:50] wrote:
> Alfred Perlstein wrote:
> >      - Update GENERIC to use usb2 device names.
> 
> Wasn't there a plan to rename usb2 devices to match oldusb names (where 
> applicable) once oldusb had been killed? I don't see it in the list.

Probably, although coming from the other side as a user I find it pretty
annoying when there's somewhat gratuitous changes to the kernel config
files that I don't really care about that cause my kernels to break.

Doing it once is probably enough, but let me know if this is really,
really important...

Basically, calling it usb2 isn't as bad as renaming it back to "usb"
as it's less disruptive in my book.

If a lot of people poke me about renaming it, we'll get it done,
but I don't really believe in it.


-- 
- Alfred Perlstein
From hselasky at c2i.net  Sun Feb  8 01:24:06 2009
From: hselasky at c2i.net (Hans Petter Selasky)
Date: Sun Feb  8 01:24:19 2009
Subject: "Fatal trap" when unloading usb2_controller_ehci
In-Reply-To: <20090208001656.48a1a14d@gluon>
References: <20090208001656.48a1a14d@gluon>
Message-ID: <200902081026.22618.hselasky@c2i.net>

Hi,

I don't think this is a USB problem. I rather think it has something to do  
with the IRQ handler. On my box the EHCI IRQ is shared with the IRQ of the 
graphics adapter, and when I unload the EHCI driver under X11 a couple of 
times X11 freezes. This does not happen on the console.

--HPS

On Sunday 08 February 2009, Bruce Cran wrote:
> Unloading usb2_controller_ehci is crashing FreeBSD on -CURRENT
> from a few days ago, resulting in a "Fatal trap" that isn't immediately
> fatal but ends up knocking out the rest of the system.
>
> Shortly after issuing a kldunload, the kernel drops into DDB with:
>
> Fatal trap 30: reserved (unknown) fault while in kernel mode
> cpuid = 0; apic id = 00
> instruction pointer = 0x8 : 0xffffffff804bc646
> stack pointer       = 0x10: 0xfffffffe40023b70
> frame pointer       = 0x10: 0xfffffffe40023b80
> code segment        = base 0x0, limit 0xfffff, type 0x1b
> processor eflags    = interrupt enabled, IOPL = 0
> current process     = 11 (idle : cpu0)
> [thread pid 11 tid 100004]
> Stopped at acpi_cpu_c1+0x6 : leave
>
> A backtrace just shows that the idle task was running at the time of
> the trap.  Attempting to continue results in a load of "calcru: runtime
> went backwards" messages followed by the ATA driver dying with:
>
> WARNING - SETFEATURES SET TRANSFER MODE taskqueue timeout - completing
> request directly
>
> Then follows similar messages about SET_MULTI, ENABLE RCACHE,
> ENABLE_WCACHE and WRITE_DMA48 etc.


From hselasky at c2i.net  Sun Feb  8 01:24:06 2009
From: hselasky at c2i.net (Hans Petter Selasky)
Date: Sun Feb  8 01:24:20 2009
Subject: "Fatal trap" when unloading usb2_controller_ehci
In-Reply-To: <20090208001656.48a1a14d@gluon>
References: <20090208001656.48a1a14d@gluon>
Message-ID: <200902081026.22618.hselasky@c2i.net>

Hi,

I don't think this is a USB problem. I rather think it has something to do  
with the IRQ handler. On my box the EHCI IRQ is shared with the IRQ of the 
graphics adapter, and when I unload the EHCI driver under X11 a couple of 
times X11 freezes. This does not happen on the console.

--HPS

On Sunday 08 February 2009, Bruce Cran wrote:
> Unloading usb2_controller_ehci is crashing FreeBSD on -CURRENT
> from a few days ago, resulting in a "Fatal trap" that isn't immediately
> fatal but ends up knocking out the rest of the system.
>
> Shortly after issuing a kldunload, the kernel drops into DDB with:
>
> Fatal trap 30: reserved (unknown) fault while in kernel mode
> cpuid = 0; apic id = 00
> instruction pointer = 0x8 : 0xffffffff804bc646
> stack pointer       = 0x10: 0xfffffffe40023b70
> frame pointer       = 0x10: 0xfffffffe40023b80
> code segment        = base 0x0, limit 0xfffff, type 0x1b
> processor eflags    = interrupt enabled, IOPL = 0
> current process     = 11 (idle : cpu0)
> [thread pid 11 tid 100004]
> Stopped at acpi_cpu_c1+0x6 : leave
>
> A backtrace just shows that the idle task was running at the time of
> the trap.  Attempting to continue results in a load of "calcru: runtime
> went backwards" messages followed by the ATA driver dying with:
>
> WARNING - SETFEATURES SET TRANSFER MODE taskqueue timeout - completing
> request directly
>
> Then follows similar messages about SET_MULTI, ENABLE RCACHE,
> ENABLE_WCACHE and WRITE_DMA48 etc.


From matt at chronos.org.uk  Sun Feb  8 02:01:14 2009
From: matt at chronos.org.uk (Matt Dawson)
Date: Sun Feb  8 02:01:21 2009
Subject: CFT: Graphics support for /boot/loader
In-Reply-To: <200902071859.n17Ixh4k075786@lurza.secnetix.de>
References: <200902071859.n17Ixh4k075786@lurza.secnetix.de>
Message-ID: <200902081001.04075.matt@chronos.org.uk>

On Saturday 07 February 2009 18:59:43 Oliver Fromme wrote:
> In fact I have prepared a theme with beastie; here's
> a screen shot (preliminary):
>
> http://www.secnetix.de/olli/FreeBSD/vloader/screenshot5.png

Perfect. Clean, logical, concise, the three words I associate above all with 
FreeBSD. I would change all machines' loaders to this in a heartbeat, although 
others may have different ideas, which is where the space hopper comes in, I 
suppose. Nothing against the horned ball and your variant of the new graphics 
looks very neat and clean, but I'm used to having Beastie around. For some 
reason, this strikes the correct balance for me between nice graphics and too 
much "bling." My personal tastes only, naturally.

<crawl> That screenshot looks very professional. Well done, Oliver. Any chance 
of rolling another tarball with that theme for we traditionalists? Please? 
</crawl>

Best regards,
-- 
Matt Dawson
MTD15-RIPE
matt@chronos.org.uk
From kris at FreeBSD.org  Sun Feb  8 02:44:53 2009
From: kris at FreeBSD.org (Kris Kennaway)
Date: Sun Feb  8 02:45:03 2009
Subject: UFS Witness LoR + 5 other LoRs
In-Reply-To: <20090129233220.1ed64e6d@zelda.local>
References: <1233007263.9302.2.camel@localhost.localdomain>
	<20090129233220.1ed64e6d@zelda.local>
Message-ID: <498EB79F.4010905@FreeBSD.org>

Martin wrote:
> Am Mon, 26 Jan 2009 14:01:03 -0800
> schrieb Sean Bruno <sean.bruno@dsl-only.net>:
> 
>> Anyone else seeing this LoR today?
>>
>> lock order reversal:
>>  1st 0xc456b044 user map (user map)
>> @ /root/bsd/head/sys/vm/vm_map.c:3198
>>  2nd 0xc4911ad0 ufs (ufs) @ /root/bsd/head/sys/kern/vfs_subr.c:2071
>> KDB: stack backtrace:
>> db_trace_self_wrapper(c0bf0913,c417990c,c087a4b5,c0c1458c,0,...) at
>> db_trace_self_wrapper+0x26
>> kdb_backtrace(c0c1458c,0,c4521728,c4526730,c4179968,...) at
>> kdb_backtrace+0x29
>> _witness_debugger(c0bf3680,c4911ad0,c0be6d88,c4526730,c0bfa429,...) at
>> _witness_debugger+0x25
>> witness_checkorder(c4911ad0,1,c0bfa429,817,0,...) at
>> witness_checkorder +0x839
>> __lockmgr_args(c4911ad0,200501,c4911aec,0,0,...) at
>> __lockmgr_args+0x237
>> ffs_lock(c4179a78,c087a25b,c0c1697a,200501,c4911a78,...) at ffs_lock
>> +0x8a VOP_LOCK1_APV(c0cf7ca0,c4179a78,c4567e24,c0d0bdc0,c4911a78,...)
>> at VOP_LOCK1_APV+0xb5
>> _vn_lock(c4911a78,200501,c0bfa429,817,4,...) at _vn_lock+0x5e
>> vget(c4911a78,200501,c4567d80,4b4,0,...) at vget+0xc9
>> vnode_pager_lock(c187c1f0,0,c0c13f07,127,c4179c18,...) at
>> vnode_pager_lock+0x1e0
>> vm_fault(c456b000,80db000,2,8,80db620,...) at vm_fault+0x1df
>> trap_pfault(5,0,c0c241d1,2e7,c4565d34,...) at trap_pfault+0x118
>> trap(c4179d38) at trap+0x289
>> calltrap() at calltrap+0x6
>> --- trap 0xc, eip = 0x80480e5, esp = 0xbfbfeef0, ebp = 0xbfbfef10 ---
> 
> Hi,
> 
> I have similar LORs. One of them might be affecting Gnome2. I cannot
> even save anything once the LOR happened. nautilus is also hanging
> around. I cannot even kill it. This occurs since I migrated
> my /usr/home to ZFS (see fourth, fifth LoR).
> 
> Here one like yours:
> 
> lock order reversal:
>  1st 0xffffff0002402070 user map (user map)
> @ /usr/src/sys/vm/vm_map.c:3198 2nd 0xffffff0002b8a7f8 ufs (ufs)
> @ /usr/src/sys/kern/vfs_subr.c:2071
> 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+0xca8
> ffs_lock() at ffs_lock+0x8c
> VOP_LOCK1_APV() at VOP_LOCK1_APV+0x9b
> _vn_lock() at _vn_lock+0x47
> vget() at vget+0x8b
> vnode_pager_lock() at vnode_pager_lock+0x1d0
> vm_fault() at vm_fault+0x1e2
> trap_pfault() at trap_pfault+0x128
> trap() at trap+0x51c
> calltrap() at calltrap+0x8
> --- trap 0xc, rip = 0x40014f, rsp = 0x7fffffffee70, rbp =
> 0x7fffffffee90 ---
> 
> 
> Here a second one:
> 
> lock order reversal:
>  1st 0xfffffffe803eb610 bufwait (bufwait)
> @ /usr/src/sys/kern/vfs_bio.c:2443 2nd 0xffffff00080d2000 dirhash
> (dirhash) @ /usr/src/sys/ufs/ufs/ufs_dirhash.c:275
> 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+0x55
> ufsdirhash_acquire() at ufsdirhash_acquire+0x33
> ufsdirhash_add() at ufsdirhash_add+0x19
> ufs_direnter() at ufs_direnter+0x88b
> ufs_mkdir() at ufs_mkdir+0x633
> VOP_MKDIR_APV() at VOP_MKDIR_APV+0x93
> kern_mkdirat() at kern_mkdirat+0x2b1
> syscall() at syscall+0x1bf
> Xfast_syscall() at Xfast_syscall+0xab
> --- syscall (136, FreeBSD ELF64, mkdir), rip = 0x800719e9c, rsp =
> 0x7fffffffed08, rbp = 0x7fffffffef76 ---
> 
> 
> Here the third:
> 
> lock order reversal:
>  1st 0xffffff0008648248 filedesc structure (filedesc structure)
> @ /usr/src/sys/kern/kern_descrip.c:1076 2nd 0xffffff0019110ba8 ufs
> (ufs) @ /usr/src/sys/kern/vfs_subr.c:4057
> 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+0xc2a
> ffs_lock() at ffs_lock+0x8c
> VOP_LOCK1_APV() at VOP_LOCK1_APV+0x9b
> _vn_lock() at _vn_lock+0x47
> knlist_remove_kq() at knlist_remove_kq+0x73
> knote_fdclose() at knote_fdclose+0x177
> kern_close() at kern_close+0xe6
> syscall() at syscall+0x1bf
> Xfast_syscall() at Xfast_syscall+0xab
> --- syscall (6, FreeBSD ELF64, close), rip = 0x800e35e8c, rsp =
> 0x7fffffffe678, rbp = 0x801063a00 ---
> 
> 
> 
> And thes two are really nasty (ZFS):
> 
> lock order reversal:
>  1st 0xffffff00195ed620 zfs (zfs) @ /usr/src/sys/kern/vfs_vnops.c:531
>  2nd 0xffffff00080ab360 user map (user map)
> @ /usr/src/sys/vm/vm_map.c:3198 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_slock() at _sx_slock+0x55
> vm_map_lookup() at vm_map_lookup+0x47
> vm_fault() at vm_fault+0xfe
> trap_pfault() at trap_pfault+0x128
> trap() at trap+0x347
> calltrap() at calltrap+0x8
> --- trap 0xc, rip = 0xffffffff8081ed4b, rsp = 0xfffffffe97261850, rbp =
> 0xfffffffe972618d0 --- copyout() at copyout+0x3b
> dmu_read_uio() at dmu_read_uio+0x98
> zfs_freebsd_read() at zfs_freebsd_read+0x56d
> vn_read() at vn_read+0x267
> dofileread() at dofileread+0xa1
> kern_readv() at kern_readv+0x60
> read() at read+0x54
> syscall() at syscall+0x1bf
> Xfast_syscall() at Xfast_syscall+0xab
> --- syscall (3, FreeBSD ELF64, read), rip = 0x80647becc, rsp =
> 0x7ffffffed8c8, rbp = 0x806682f80 ---
> 
> lock order reversal:
>  1st 0xffffff0019bc2270 zfs (zfs) @ /usr/src/sys/kern/vfs_subr.c:2071
>  2nd 0xffffff0019a77448 filedesc structure (filedesc structure)
> @ /usr/src/sys/kern/vfs_syscalls.c:1720
> 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_slock() at _sx_slock+0x55
> kern_symlinkat() at kern_symlinkat+0x1f8
> syscall() at syscall+0x1bf
> Xfast_syscall() at Xfast_syscall+0xab
> --- syscall (57, FreeBSD ELF64, symlink), rip = 0x8049cb13c, rsp =
> 0x7fffffffd6f8, rbp = 0x7fffffffdd10 ---
> 
> And one with NFS:
> 
> lock order reversal:
>  1st 0xffffff00080a6940 user map (user map)
> @ /usr/src/sys/vm/vm_map.c:3198 2nd 0xffffff00566a9ba8 nfs (nfs)
> @ /usr/src/sys/kern/vfs_subr.c:2071
> 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+0xca8
> vop_stdlock() at vop_stdlock+0x39
> VOP_LOCK1_APV() at VOP_LOCK1_APV+0x9b
> _vn_lock() at _vn_lock+0x47
> vget() at vget+0x8b
> vnode_pager_lock() at vnode_pager_lock+0x1d0
> vm_fault() at vm_fault+0x1e2
> trap_pfault() at trap_pfault+0x128
> trap() at trap+0x347
> calltrap() at calltrap+0x8
> --- trap 0xc, rip = 0xffffffff8081edcd, rsp = 0xfffffffe972b67d0, rbp =
> 0xfffffffe972b6850 --- copyin() at copyin+0x3d
> ffs_write() at ffs_write+0x2f8
> VOP_WRITE_APV() at VOP_WRITE_APV+0xfe
> vn_write() at vn_write+0x23f
> dofilewrite() at dofilewrite+0x85
> kern_writev() at kern_writev+0x60
> write() at write+0x54
> syscall() at syscall+0x1bf
> Xfast_syscall() at Xfast_syscall+0xab
> --- syscall (4, FreeBSD ELF64, write), rip = 0x80072beac, rsp =
> 0x7fffffffe5d8, rbp = 0x800537000 ---
> 
> 
> Can you beat my 6 LoRs? ;)

Several of these are widely reported, and harmless (not sure about the 
filedesc ones though).  Which one do you think is causing your problem?

Kris
From nakal at web.de  Sun Feb  8 04:05:17 2009
From: nakal at web.de (Martin)
Date: Sun Feb  8 04:05:25 2009
Subject: UFS Witness LoR + 5 other LoRs
In-Reply-To: <498EB79F.4010905@FreeBSD.org>
References: <1233007263.9302.2.camel@localhost.localdomain>
	<20090129233220.1ed64e6d@zelda.local>
	<498EB79F.4010905@FreeBSD.org>
Message-ID: <20090208130506.267a838d@zelda.local>

Am Sun, 08 Feb 2009 11:44:47 +0100
schrieb Kris Kennaway <kris@FreeBSD.org>:

> Several of these are widely reported, and harmless (not sure about
> the filedesc ones though).  Which one do you think is causing your
> problem?
> 
> Kris

Hi Kris.

I found out it has something to do with the softlink to an NFS share
that I have on my desktop (nautilus). I've made some settings yesterday
to fix it and will report, if this was the problem. Of course, the amd
mounts and unmounts my NFS share and the mentioned LORs appear typically
while mounting and unmounting, I noticed. So it is perhaps misleading.

Btw... it would be very nice if someone finally implements timeouts and
a detection strategy for NFS packets that don't arrive at their
destination because of fragmentation and wrong rsize/wsize settings.
But this is a totally different topic. There is not much in the docs
about it.


You mean this LOR "with filedesc"?

lock order reversal:
 1st 0xffffff001ada0ba8 zfs (zfs) @ /usr/src/sys/kern/vfs_subr.c:2071
 2nd 0xffffff0008a92848 filedesc structure (filedesc structure)
@ /usr/src/sys/kern/vfs_syscalls.c:1720 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_slock() at _sx_slock+0x55
kern_symlinkat() at kern_symlinkat+0x1f8
syscall() at syscall+0x1bf
Xfast_syscall() at Xfast_syscall+0xab
--- syscall (57, FreeBSD ELF64, symlink), rip = 0x8049cc13c, rsp =
0x7fffffffd6f8, rbp = 0x7fffffffdd10 ---

It still occurs on:
FreeBSD zelda.local 8.0-CURRENT FreeBSD 8.0-CURRENT #0: Mon Feb  2
19:20:24 CET 2009     root@zelda.local:/usr/obj/usr/src/sys/ZELDA  amd64

It appears a bit later when Gnome is already running, I think. I
can only tell by looking at the time stamp that is 3 minutes after
booting the machine. I'll to try to figure out what is running when
exactly this LOR appears.

--
Martin
From olli at lurza.secnetix.de  Sun Feb  8 04:17:48 2009
From: olli at lurza.secnetix.de (Oliver Fromme)
Date: Sun Feb  8 04:17:56 2009
Subject: CFT: Graphics support for /boot/loader
In-Reply-To: <200902081001.04075.matt@chronos.org.uk>
Message-ID: <200902081217.n18CHYlx014125@lurza.secnetix.de>


Matt Dawson wrote:
 > On Saturday 07 February 2009 18:59:43 Oliver Fromme wrote:
 > > In fact I have prepared a theme with beastie; here's
 > > a screen shot (preliminary):
 > > 
 > > http://www.secnetix.de/olli/FreeBSD/vloader/screenshot5.png
 > 
 > Perfect. Clean, logical, concise, the three words I associate above all with 
 > FreeBSD. I would change all machines' loaders to this in a heartbeat, although 
 > others may have different ideas, which is where the space hopper comes in, I 
 > suppose. Nothing against the horned ball and your variant of the new graphics 
 > looks very neat and clean, but I'm used to having Beastie around. For some 
 > reason, this strikes the correct balance for me between nice graphics and too 
 > much "bling." My personal tastes only, naturally.
 > 
 > <crawl> That screenshot looks very professional. Well done, Oliver. Any chance 
 > of rolling another tarball with that theme for we traditionalists? Please? 
 > </crawl>

Good news:  I don't have to roll another tarball for that,
because this is quite easy to configure.

Please download the existing tarball and follow the
instructions that I posted.  Please verify that it works.
Then download the background image that contains beastie:

http://www.secnetix.de/olli/FreeBSD/vloader/background/beastie.pcx

Create a directory /boot/themes/beastie and save the image
as beastie.pcx in that directory.  Then create a text file
themes.conf in the same directory, containing these lines:

theme_background="/boot/themes/beastie/beastie.pcx"
theme_font="/boot/themes/default/stdfont"
theme_fgcolor="0 0 0"           # black
theme_bgcolor="255 255 255"     # white
theme_litcolor="255 64 32"      # bright red
theme_dimcolor="64 64 128"      # dark bluish grey
theme_options_xy="17 170"
theme_actions_xy="17 281"

Finally, change the beastie_theme line in /boot/loader.conf
like this:

beastie_theme="/boot/themes/beastie/theme.conf"

Done.

Of course, you can also use your own image if you want to
create one.  Just make sure it's 640 x 480 pixels at 4 bit
depth (16 colors maximum).  I recommend to use ppmtopcx
(from ports/graphics/netpbm), because I have used this
extensively for testing with my PCX decoder.  Also note
that there should be appropriate palette entries for the
text (e.g. black and white).  The code will try to use the
closest possible palette entry if there is no exact match
for the given RGB values.

There's ONE IMPORTANT THING I have to say:  I cannot take
credit for any of the artwork.  I am not an artist.  All of
the graphics images where taken from the FreeBSD website.
I only scaled and arranged it a little bit, adapted the
palette etc.  The only thing I created myself is the
proportional font; the "source code" is here:

http://www.secnetix.de/olli/FreeBSD/vloader/stdfont.txt

Modifying the font or creating a completely new font is
also very easy.  There's a tool that "compiles" the text
source code (like the one above) to binary format.

Best regards
   Oliver

-- 
Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M.
Handelsregister: Registergericht Muenchen, HRA 74606,  Gesch?ftsfuehrung:
secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht M?n-
chen, HRB 125758,  Gesch?ftsf?hrer: Maik Bachmann, Olaf Erb, Ralf Gebhart

FreeBSD-Dienstleistungen, -Produkte und mehr:  http://www.secnetix.de/bsd

"Software gets slower faster than hardware gets faster."
        -- Niklaus Wirth
From olli at lurza.secnetix.de  Sun Feb  8 04:39:56 2009
From: olli at lurza.secnetix.de (Oliver Fromme)
Date: Sun Feb  8 04:40:14 2009
Subject: ZFS and Graphics support for /boot/loader
In-Reply-To: <x93952x1233965239x@lurza.secnetix.de>
Message-ID: <200902081239.n18CdnOk015298@lurza.secnetix.de>

Paul Wootton wrote:
 > Hi Oliver,
 > 
 > This doesn?t work for me.
 > 
 > I am booting off a ZFS mirror with GPT partitions (built from current on an
 > amd64).

I'm sorry, I've compiled this loader binary with the default
options, which does not include ZFS support.

 > Is there any change of a version of gloader but with ZFS support?

I'll put it on my to-do list.

Best regards
   Oliver

-- 
Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M.
Handelsregister: Registergericht Muenchen, HRA 74606,  Gesch?ftsfuehrung:
secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht M?n-
chen, HRB 125758,  Gesch?ftsf?hrer: Maik Bachmann, Olaf Erb, Ralf Gebhart

FreeBSD-Dienstleistungen, -Produkte und mehr:  http://www.secnetix.de/bsd

"Software gets slower faster than hardware gets faster."
        -- Niklaus Wirth
From matt at chronos.org.uk  Sun Feb  8 04:39:58 2009
From: matt at chronos.org.uk (Matt Dawson)
Date: Sun Feb  8 04:40:16 2009
Subject: CFT: Graphics support for /boot/loader
In-Reply-To: <200902081217.n18CHYlx014125@lurza.secnetix.de>
References: <200902081217.n18CHYlx014125@lurza.secnetix.de>
Message-ID: <200902081239.54250.matt@chronos.org.uk>

On Sunday 08 February 2009 12:17:34 Oliver Fromme wrote:
> http://www.secnetix.de/olli/FreeBSD/vloader/background/beastie.pcx
>
> Create a directory /boot/themes/beastie and save the image
> as beastie.pcx in that directory. ?Then create a text file
> themes.conf in the same directory, containing these lines:
>
> theme_background="/boot/themes/beastie/beastie.pcx"
> theme_font="/boot/themes/default/stdfont"
> theme_fgcolor="0 0 0" ? ? ? ? ? # black
> theme_bgcolor="255 255 255" ? ? # white
> theme_litcolor="255 64 32" ? ? ?# bright red
> theme_dimcolor="64 64 128" ? ? ?# dark bluish grey
> theme_options_xy="17 170"
> theme_actions_xy="17 281"
>
> Finally, change the beastie_theme line in /boot/loader.conf
> like this:
>
> beastie_theme="/boot/themes/beastie/theme.conf"
>
> Done.

...and it is. Thanks, Oliver!
-- 
Matt Dawson
MTD15-RIPE
matt@chronos.org.uk
From olli at lurza.secnetix.de  Sun Feb  8 04:47:21 2009
From: olli at lurza.secnetix.de (Oliver Fromme)
Date: Sun Feb  8 04:47:28 2009
Subject: CFT: Graphics support for /boot/loader
In-Reply-To: <655a934b0902070025p5ab5ed21ncdb1e6efd3e21c24@mail.gmail.com>
Message-ID: <200902081247.n18ClJaM015821@lurza.secnetix.de>

Antonios Anastasiadis wrote:
 > I've got the red border on a TFT monitor by the way.

OK, yeah, the problem is more widespread than I thought.
Obviously some TFT monitors (probably wide-screen ones in
particular) aren't scaling VGA modes to the full size of
the screen, so the border bug becomes visible.

Anyway, I have fixed it in my local source tree.
Thanks for reporting!

Best regards
   Oliver

-- 
Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M.
Handelsregister: Registergericht Muenchen, HRA 74606,  Gesch?ftsfuehrung:
secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht M?n-
chen, HRB 125758,  Gesch?ftsf?hrer: Maik Bachmann, Olaf Erb, Ralf Gebhart

FreeBSD-Dienstleistungen, -Produkte und mehr:  http://www.secnetix.de/bsd

In my experience the term "transparent proxy" is an oxymoron (like jumbo
shrimp).  "Transparent" proxies seem to vary from the distortions of a
funhouse mirror to barely translucent.  I really, really dislike them
when trying to figure out the corrective lenses needed with each of them.
        -- R. Kevin Oberman, Network Engineer
From olli at lurza.secnetix.de  Sun Feb  8 04:52:54 2009
From: olli at lurza.secnetix.de (Oliver Fromme)
Date: Sun Feb  8 04:53:00 2009
Subject: CFT: Graphics support for /boot/loader
In-Reply-To: <20090208073927.77e2c829@bhuda.mired.org>
Message-ID: <200902081252.n18CqhZf016155@lurza.secnetix.de>


Mike Meyer wrote:
 > I'm curious - is there a reason that the numbers from the old screen
 > have turned into function keys on this one?

No.  That screen shot is an old one.  In the current code,
the number keys are used as usual, no function keys.

In fact, it is not possible to use function keys from the
FORTH code without resorting to dirty hacks.

Best regards
   Oliver

-- 
Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M.
Handelsregister: Registergericht Muenchen, HRA 74606,  Gesch?ftsfuehrung:
secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht M?n-
chen, HRB 125758,  Gesch?ftsf?hrer: Maik Bachmann, Olaf Erb, Ralf Gebhart

FreeBSD-Dienstleistungen, -Produkte und mehr:  http://www.secnetix.de/bsd

"Share your knowledge.  It is a way to achieve immortality." -- The Dalai Lama
From Alexander at Leidinger.net  Sun Feb  8 05:10:40 2009
From: Alexander at Leidinger.net (Alexander Leidinger)
Date: Sun Feb  8 05:10:47 2009
Subject: CFT: Graphics support for /boot/loader
In-Reply-To: <200902071859.n17Ixh4k075786@lurza.secnetix.de>
References: <200902071859.n17Ixh4k075786@lurza.secnetix.de>
Message-ID: <20090208135053.12691emq58yl9m4k@webmail.leidinger.net>

Quoting Oliver Fromme <olli@lurza.secnetix.de> (from Sat, 7 Feb 2009  
19:59:43 +0100 (CET)):

> Thomas Sparrevohn wrote:
>  > Agreed - Looks very cool - but I miss beastie - Would love to have it
>  > as an option like,  "WITH_SENTIMENTAL=YES"  that maybe would install
>  > the old games as well....ahh well
>
> You can easily replace the background image, it's a
> standard PCX image file.  You can even re-arrange the
> position of the menu if necessary; there are simple
> variable settings for that in the theme.conf file.

What about the actual menu items, are they configurable too (e.g. when  
I want single-user as F1... ACPI should work now on most systems and I  
don't see why disabling it should be in the first position), or does  
it use the same stuff as the text menu for this (to fiddling with  
forth would be necessary)?

Bye,
Alexander.

-- 
QOTD:
	"The elder gods went to Suggoth and all I got was this lousy T-shirt."

http://www.Leidinger.net    Alexander @ Leidinger.net: PGP ID = B0063FE7
http://www.FreeBSD.org       netchild @ FreeBSD.org  : PGP ID = 72077137
From mwm at mired.org  Sun Feb  8 05:06:50 2009
From: mwm at mired.org (Mike Meyer)
Date: Sun Feb  8 05:23:13 2009
Subject: CFT: Graphics support for /boot/loader
In-Reply-To: <200902081217.n18CHYlx014125@lurza.secnetix.de>
References: <200902081001.04075.matt@chronos.org.uk>
	<200902081217.n18CHYlx014125@lurza.secnetix.de>
Message-ID: <20090208073927.77e2c829@bhuda.mired.org>

I'm curious - is there a reason that the numbers from the old screen
have turned into function keys on this one?

     <mike
-- 
Mike Meyer <mwm@mired.org>		http://www.mired.org/consulting.html
Independent Network/Unix/Perforce consultant, email for more information.

O< ascii ribbon campaign - stop html mail - www.asciiribbon.org
From olli at lurza.secnetix.de  Sun Feb  8 05:35:09 2009
From: olli at lurza.secnetix.de (Oliver Fromme)
Date: Sun Feb  8 05:35:17 2009
Subject: CFT: Graphics support for /boot/loader
In-Reply-To: <20090208135053.12691emq58yl9m4k@webmail.leidinger.net>
Message-ID: <200902081335.n18DZ2h4018582@lurza.secnetix.de>


Alexander Leidinger wrote:
 > Oliver Fromme wrote:
 > > You can easily replace the background image, it's a
 > > standard PCX image file.  You can even re-arrange the
 > > position of the menu if necessary; there are simple
 > > variable settings for that in the theme.conf file.
 > 
 > What about the actual menu items, are they configurable too (e.g. when  
 > I want single-user as F1... ACPI should work now on most systems and I  
 > don't see why disabling it should be in the first position), or does  
 > it use the same stuff as the text menu for this (to fiddling with  
 > forth would be necessary)?

The actual menu contents are in the beastie.4th file, just
like for the old text menu.  So, yes, you'd need to speak
FORTH in order to change that.

How many of the FreeBSD developers are actually fluent in
FORTH?  How many committers are able to review the .4th
code that I wrote?

Would there be strong resistance if I tried to replace FICL
with something else that is not as brain-knotting as FORTH?
Just to name an example, I once wrote a bourne-shell-like
parser that would not be difficult to embed.  I assume that
would enable many more developers and users to play with
the boot menu stuff.

Best regards
   Oliver

-- 
Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M.
Handelsregister: Registergericht Muenchen, HRA 74606,  Gesch?ftsfuehrung:
secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht M?n-
chen, HRB 125758,  Gesch?ftsf?hrer: Maik Bachmann, Olaf Erb, Ralf Gebhart

FreeBSD-Dienstleistungen, -Produkte und mehr:  http://www.secnetix.de/bsd

'Instead of asking why a piece of software is using "1970s technology,"
start asking why software is ignoring 30 years of accumulated wisdom.'
From freebsd-listen at fabiankeil.de  Sun Feb  8 05:39:11 2009
From: freebsd-listen at fabiankeil.de (Fabian Keil)
Date: Sun Feb  8 05:39:18 2009
Subject: USB2 - libusb20 vs devel/libusb
In-Reply-To: <1233732660.1767.30.camel@localhost>
References: <1233732660.1767.30.camel@localhost>
Message-ID: <20090208142843.3c5da278@fabiankeil.de>

Vladimir Grebenschikov <vova@fbsd.ru> wrote:

> I've tried libusb, looks like it works more or less.
 
> PS. I didn't try yet libgphoto2 (it also uses ugen directly).

gphoto2 stopped working for me with the new USB code.

I needed the pictures quickly so I just moved back to
the old code. I can retry and report more details if
someone is interested.

Fabian
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20090208/684ddb34/signature.pgp
From miwi at FreeBSD.org  Sun Feb  8 05:59:31 2009
From: miwi at FreeBSD.org (Martin Wilke)
Date: Sun Feb  8 05:59:38 2009
Subject: HEADSUP usb2/usb4bsd to become default in GENERIC
In-Reply-To: <20090206045349.GQ78804@elvis.mu.org>
References: <20090206045349.GQ78804@elvis.mu.org>
Message-ID: <20090208134420.GA42242@bsdcrew.de>

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

May be also a ports exp-run to make sure you don't break to many
ports?

- - Martin


On Thu, Feb 05, 2009 at 08:53:49PM -0800, Alfred Perlstein wrote:
> Hello -current and -usb.
> 
> We are in the final stages of bringing in the new usb
> stack.
> 
> Features include: SMP, better device support, speed increases.
> 
> We hope to make it in for 8.0.  It will really take a unified effort
> to make this all work and I look forward to all contributors input.
> 
> We have a few large steps ahead of us and I wanted to lay out the
> schedule so that people understand what is coming and what to expect.
> 
> At this point we expect there to be no style or changes in usb2
> that are not bugfixes until Phase 3 "Hand off".  The reason for
> this is to prevent bugs from creeping in and allow the maintainer
> to focus 100% on bugs and feature parity with the oldusb stack.
> 
> Here is the plan and timeline:
> 
> Phase 1) Make usb2 the default, by enabling it in GENERIC.
> 
>     * Sunday 8 Feb 2009  -- Toggle the usb2 knob in GENERIC
> 
>       - Add all the usb2 options to NOTES, including commented
>         documentation about recommended usb2 'sets' of options,
>         and the usual NOTES-based hints about the options.
> 
>       - Update GENERIC to use usb2 device names.
> 
>       - Bump __FreeBSD_version and edit UPDATING to note usb2 is now the
>         default.
> 
>       - Verify that it still possible to use the old usb code as a
>         fallback, until we are ready to detach and remove it from /head
> 
>     * Sunday 22 Feb 2009 -- Go through quirks in old-usb code and port
>       over any remaining bits to usb2
> 
>       - Lock the oldusb code for 2 weeks, until the next usb2
>         checkpoint, to verify usb2 is a viable replacement without
>         having to keep chasing a moving oldusb target.
> 
> Phase 2) Removing the oldusb code.
> 
>     * Sunday 15 Mar 2009 -- usb2 bug busting weekend
> 
>       - Go through the open usb2 problem reports, and see if there are
>         any usb2 blocker bugs that need fixing.
> 
>       - If the bug hunt shows we are ready to do away with oldusb,
>         unlink the old usb code from the build, but leave it in for
>         a few more days.
> 
>     * Sunday 22 Mar 2009 -- remove oldusb code.
> 
>       - old usb code will be removed.
> 
> Phase 3) Hand-off.
> 
>     * Sunday 29 Mar 2009 -- usb2 hand over to src-committers
> 
>       - The switch from a private Hans-only repository to the main
>         subversion tree.
> 
>       - At this point, the usb2 is handed over to the src-committers
>         and Hans has to go through a mentor/committer before committing
> 	changes.
> 
> Thank you!
> 
> -- 
> - Alfred Perlstein
> _______________________________________________
> 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"
> 

- -- 

+-----------------------+-------------------------------+
|  PGP    : 0x05682353  |  Jabber : miwi(at)BSDCrew.de  |
|  ICQ    : 169139903   |  Mail   : miwi(at)FreeBSD.org |
+-----------------------+-------------------------------+
|	Mess with the Best, Die like the Rest!		|
+-----------------------+-------------------------------+
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (FreeBSD)

iEYEARECAAYFAkmO4bQACgkQFwpycAVoI1NEcACeMQyjZGYPG1WO/pAT7ErFaKop
pyYAnAuICJDTLDepTnLvvth1o+53m0nU
=R3Om
-----END PGP SIGNATURE-----
From christoph.mallon at gmx.de  Sun Feb  8 06:16:52 2009
From: christoph.mallon at gmx.de (Christoph Mallon)
Date: Sun Feb  8 06:16:58 2009
Subject: CFT: Graphics support for /boot/loader
In-Reply-To: <200902081247.n18ClJaM015821@lurza.secnetix.de>
References: <200902081247.n18ClJaM015821@lurza.secnetix.de>
Message-ID: <498EE950.300@gmx.de>

Oliver Fromme schrieb:
> Antonios Anastasiadis wrote:
>  > I've got the red border on a TFT monitor by the way.
> 
> OK, yeah, the problem is more widespread than I thought.
> Obviously some TFT monitors (probably wide-screen ones in
> particular) aren't scaling VGA modes to the full size of
> the screen, so the border bug becomes visible.

This "bug" is called "overscan" and is actually a feature of graphics 
cards. The overscan colour index can be selected with the "Overscan 
Color" register (0x11) of the attribute controller (port 0x3C0). You can 
even set a colour which is outside of the 0-15 range, so you get a 17th 
colour for the border!
From olli at lurza.secnetix.de  Sun Feb  8 07:39:09 2009
From: olli at lurza.secnetix.de (Oliver Fromme)
Date: Sun Feb  8 07:39:16 2009
Subject: CFT: Graphics support for /boot/loader
In-Reply-To: <498EE950.300@gmx.de>
Message-ID: <200902081539.n18Fd5T6023909@lurza.secnetix.de>


Christoph Mallon wrote:
 > Oliver Fromme schrieb:
 > > Antonios Anastasiadis wrote:
 > > > I've got the red border on a TFT monitor by the way.
 > > 
 > > OK, yeah, the problem is more widespread than I thought.
 > > Obviously some TFT monitors (probably wide-screen ones in
 > > particular) aren't scaling VGA modes to the full size of
 > > the screen, so the border bug becomes visible.
 > 
 > This "bug" is called "overscan"

No, the bug I'm talking about is in my code, which happens
to always leave the overscan color at index 0, no matter
what the actual palette entry is.  This bug has been fixed.

 > and is actually a feature of graphics 
 > cards.

You definitely don't have to lecture me about graphics
cards.  ;-)  I know the overscan property very well;
I already mentioned it earlier in this thread.

Best regards
   Oliver

-- 
Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M.
Handelsregister: Registergericht Muenchen, HRA 74606,  Gesch?ftsfuehrung:
secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht M?n-
chen, HRB 125758,  Gesch?ftsf?hrer: Maik Bachmann, Olaf Erb, Ralf Gebhart

FreeBSD-Dienstleistungen, -Produkte und mehr:  http://www.secnetix.de/bsd

"Clear perl code is better than unclear awk code; but NOTHING
comes close to unclear perl code"  (taken from comp.lang.awk FAQ)
From hselasky at c2i.net  Sun Feb  8 07:51:51 2009
From: hselasky at c2i.net (Hans Petter Selasky)
Date: Sun Feb  8 07:52:10 2009
Subject: USB2 - libusb20 vs devel/libusb
In-Reply-To: <20090208142843.3c5da278@fabiankeil.de>
References: <1233732660.1767.30.camel@localhost>
	<20090208142843.3c5da278@fabiankeil.de>
Message-ID: <200902081654.14659.hselasky@c2i.net>

On Sunday 08 February 2009, Fabian Keil wrote:
> Vladimir Grebenschikov <vova@fbsd.ru> wrote:
> > I've tried libusb, looks like it works more or less.
> >
> > PS. I didn't try yet libgphoto2 (it also uses ugen directly).
>
> gphoto2 stopped working for me with the new USB code.
>
> I needed the pictures quickly so I just moved back to
> the old code. I can retry and report more details if
> someone is interested.
>

Hi,

How did you try out the new USB code? Did you make sure that libusb0.1.x was 
mapped to libusb20 like described at http://wiki.freebsd.org/USB ?

--HPS
From freebsd-listen at fabiankeil.de  Sun Feb  8 08:00:11 2009
From: freebsd-listen at fabiankeil.de (Fabian Keil)
Date: Sun Feb  8 08:00:22 2009
Subject: USB2 - libusb20 vs devel/libusb
In-Reply-To: <200902081654.14659.hselasky@c2i.net>
References: <1233732660.1767.30.camel@localhost>
	<20090208142843.3c5da278@fabiankeil.de>
	<200902081654.14659.hselasky@c2i.net>
Message-ID: <20090208170003.168dd033@fabiankeil.de>

Hans Petter Selasky <hselasky@c2i.net> wrote:

> On Sunday 08 February 2009, Fabian Keil wrote:
> > Vladimir Grebenschikov <vova@fbsd.ru> wrote:
> > > I've tried libusb, looks like it works more or less.
> > >
> > > PS. I didn't try yet libgphoto2 (it also uses ugen directly).
> >
> > gphoto2 stopped working for me with the new USB code.
> >
> > I needed the pictures quickly so I just moved back to
> > the old code. I can retry and report more details if
> > someone is interested.
 
> How did you try out the new USB code? Did you make sure that libusb0.1.x was 
> mapped to libusb20 like described at http://wiki.freebsd.org/USB ?

I wasn't aware of these steps, sorry. I just recompiled
everything and assumed that was it. I'll retry this week.

Fabian
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20090208/2e9f6fed/signature.pgp
From nakal at web.de  Sun Feb  8 09:29:41 2009
From: nakal at web.de (Martin)
Date: Sun Feb  8 09:29:48 2009
Subject: UFS Witness LoR + 5 other LoRs
In-Reply-To: <20090208130506.267a838d@zelda.local>
References: <1233007263.9302.2.camel@localhost.localdomain>
	<20090129233220.1ed64e6d@zelda.local>
	<498EB79F.4010905@FreeBSD.org>
	<20090208130506.267a838d@zelda.local>
Message-ID: <20090208182940.43d6c929@zelda.local>

Am Sun, 8 Feb 2009 13:05:06 +0100
schrieb Martin <nakal@web.de>:

> I found out it has something to do with the softlink to an NFS share
> that I have on my desktop (nautilus). I've made some settings
> yesterday to fix it and will report, if this was the problem. Of
> course, the amd mounts and unmounts my NFS share and the mentioned
> LORs appear typically while mounting and unmounting, I noticed. So it
> is perhaps misleading.
> 
> Btw... it would be very nice if someone finally implements timeouts
> and a detection strategy for NFS packets that don't arrive at their
> destination because of fragmentation and wrong rsize/wsize settings.
> But this is a totally different topic. There is not much in the docs
> about it.

Hi.

I have further information on this. My desktop stopped working again,
because of NFS. Now I am sure. I have a LOR before this happened:

Feb  8 18:06:47 zelda kernel: lock order reversal:
Feb  8 18:06:47 zelda kernel: 1st 0xffffff001a1cca48 filedesc structure
(filedes c structure) @ /usr/src/sys/kern/kern_descrip.c:1076
Feb  8 18:06:47 zelda kernel: 2nd 0xffffff0002ed4098 pseudofs
(pseudofs) @ /usr/src/sys/kern/vfs_subr.c:4057 Feb  8 18:06:47 zelda
kernel: KDB: stack backtrace: Feb  8 18:06:47 zelda kernel:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2a Feb  8 18:06:47
zelda kernel: _witness_debugger() at _witness_debugger+0x2e Feb  8
18:06:47 zelda kernel: witness_checkorder() at witness_checkorder+0x81e
Feb  8 18:06:47 zelda kernel: __lockmgr_args() at __lockmgr_args+0xc2a
Feb  8 18:06:47 zelda kernel: vop_stdlock() at vop_stdlock+0x39 Feb  8
18:06:47 zelda kernel: VOP_LOCK1_APV() at VOP_LOCK1_APV+0x9b Feb  8
18:06:47 zelda kernel: _vn_lock() at _vn_lock+0x47 Feb  8 18:06:47
zelda kernel: knlist_remove_kq() at knlist_remove_kq+0x73 Feb  8
18:06:47 zelda kernel: knote_fdclose() at knote_fdclose+0x177 Feb  8
18:06:47 zelda kernel: kern_close() at kern_close+0xe6 Feb  8 18:06:47
zelda kernel: syscall() at syscall+0x1bf Feb  8 18:06:47 zelda kernel:
Xfast_syscall() at Xfast_syscall+0xab Feb  8 18:06:47 zelda kernel: ---
syscall (6, FreeBSD ELF64, close), rip = 0x800e35e8c, rsp =
0x7fffffffe4f8, rbp = 0x801063100 ---


And 5 minutes later I tried to access my amd-mounted share:

Feb  8 18:11:09 zelda amd[1063]: ignoring request from 127.0.0.1:21215,
port not reserved Feb  8 18:11:10 zelda last message repeated 7 times
Feb  8 18:11:11 zelda amd[1063]: ignoring request from 127.0.0.1:32008,
port not reserved

amd is suddenly flooding my syslog with these messages.

On 7.1R NFS client I did not have this effect at all. This is new on
8-CURRENT.

I hope this helps.

--
Martin
From barney_cordoba at yahoo.com  Sun Feb  8 09:31:54 2009
From: barney_cordoba at yahoo.com (Barney Cordoba)
Date: Sun Feb  8 09:32:01 2009
Subject: is there a protected/locked printf?
Message-ID: <426059.88012.qm@web63906.mail.re1.yahoo.com>

Its taking me all day to figure out something that should take 5 minutes
if I could get printf to not print garbage. Is there a mulitcore version
of printf that isn't completely useless for use for trace code?

Barney


      
From dimitry at andric.com  Sun Feb  8 10:20:22 2009
From: dimitry at andric.com (Dimitry Andric)
Date: Sun Feb  8 10:20:30 2009
Subject: is there a protected/locked printf?
In-Reply-To: <426059.88012.qm@web63906.mail.re1.yahoo.com>
References: <426059.88012.qm@web63906.mail.re1.yahoo.com>
Message-ID: <498F2253.9010204@andric.com>

On 2009-02-08 18:31, Barney Cordoba wrote:
> Its taking me all day to figure out something that should take 5 minutes
> if I could get printf to not print garbage. Is there a mulitcore version
> of printf that isn't completely useless for use for trace code?

Add:

options		PRINTF_BUFR_SIZE=128

to your kernel config file, that might help.
From remko at FreeBSD.org  Sun Feb  8 10:30:03 2009
From: remko at FreeBSD.org (Remko Lodder)
Date: Sun Feb  8 10:30:10 2009
Subject: HEADSUP usb2/usb4bsd to become default in GENERIC
In-Reply-To: <20090208052110.GY78804@elvis.mu.org>
References: <20090206045349.GQ78804@elvis.mu.org>
	<498C013B.4000405@FreeBSD.org> <20090208052110.GY78804@elvis.mu.org>
Message-ID: <8b3974a5f1b260fd438518f703aee2f5.squirrel@galain.elvandar.org>

On Sun, February 8, 2009 6:21 am, Alfred Perlstein wrote:
> * Maxim Sobolev <sobomax@FreeBSD.org> [090206 01:50] wrote:
>> Alfred Perlstein wrote:
>> >      - Update GENERIC to use usb2 device names.
>>
>> Wasn't there a plan to rename usb2 devices to match oldusb names (where
>> applicable) once oldusb had been killed? I don't see it in the list.

[snip]

>
> If a lot of people poke me about renaming it, we'll get it done,
> but I don't really believe in it.
>

I would like to enfavor that it is being named "usb" at some point. We do
not want to keep names like rcNG while at some point it's the defacto
standard right? Also names like USB2 tell people that there might be a
USB1 as well, which we no longer ship at some point.

Please name it "usb_*".

In addition; there is a request from Warner (if I remember correctly);
which I do share; there is a manual regeneration needed if you add
something to usbdevs, please make sure that that goes automatically like
"usb1" does at the moment.

Thanks,
Remko


-- 
/"\   Best regards,                      | remko@FreeBSD.org
\ /   Remko Lodder                       | remko@EFnet
 X    http://www.evilcoder.org/          |
/ \   ASCII Ribbon Campaign              | Against HTML Mail and News


From thompsa at FreeBSD.org  Sun Feb  8 10:38:27 2009
From: thompsa at FreeBSD.org (Andrew Thompson)
Date: Sun Feb  8 10:38:39 2009
Subject: HEADSUP usb2/usb4bsd to become default in GENERIC
In-Reply-To: <8b3974a5f1b260fd438518f703aee2f5.squirrel@galain.elvandar.org>
References: <20090206045349.GQ78804@elvis.mu.org>
	<498C013B.4000405@FreeBSD.org>
	<20090208052110.GY78804@elvis.mu.org>
	<8b3974a5f1b260fd438518f703aee2f5.squirrel@galain.elvandar.org>
Message-ID: <20090208183820.GA21343@citylink.fud.org.nz>

On Sun, Feb 08, 2009 at 06:48:39PM +0100, Remko Lodder wrote:
> On Sun, February 8, 2009 6:21 am, Alfred Perlstein wrote:
> > * Maxim Sobolev <sobomax@FreeBSD.org> [090206 01:50] wrote:
> >> Alfred Perlstein wrote:
> >> >      - Update GENERIC to use usb2 device names.
> >>
> >> Wasn't there a plan to rename usb2 devices to match oldusb names (where
> >> applicable) once oldusb had been killed? I don't see it in the list.
> 
> [snip]
> 
> >
> > If a lot of people poke me about renaming it, we'll get it done,
> > but I don't really believe in it.
> >
> 
> I would like to enfavor that it is being named "usb" at some point. We do
> not want to keep names like rcNG while at some point it's the defacto
> standard right? Also names like USB2 tell people that there might be a
> USB1 as well, which we no longer ship at some point.
> 
> Please name it "usb_*".
> 
> In addition; there is a request from Warner (if I remember correctly);
> which I do share; there is a manual regeneration needed if you add
> something to usbdevs, please make sure that that goes automatically like
> "usb1" does at the moment.

I take it the stage (1) is to switch over GENERIC to the new usb2 code
and will not involve renaming the config items.

stage (2) moves the usb code around in svn and all USB2 kernel config
items will assume their original names, ie. usb2_controller_echi ->
ehci.

I think this is what Alfred was getting about with only changing it
once.

Andrew
From dnelson at allantgroup.com  Sun Feb  8 10:42:47 2009
From: dnelson at allantgroup.com (Dan Nelson)
Date: Sun Feb  8 10:42:54 2009
Subject: UFS Witness LoR + 5 other LoRs
In-Reply-To: <20090208130506.267a838d@zelda.local>
References: <1233007263.9302.2.camel@localhost.localdomain>
	<20090129233220.1ed64e6d@zelda.local>
	<498EB79F.4010905@FreeBSD.org>
	<20090208130506.267a838d@zelda.local>
Message-ID: <20090208182023.GF85840@dan.emsphone.com>

In the last episode (Feb 08), Martin said:
> Btw... it would be very nice if someone finally implements timeouts and a
> detection strategy for NFS packets that don't arrive at their destination
> because of fragmentation and wrong rsize/wsize settings.  But this is a
> totally different topic.  There is not much in the docs about it.

The solution to that problem is TCP mounts :)

-- 
	Dan Nelson
	dnelson@allantgroup.com
From hselasky at c2i.net  Sun Feb  8 10:48:53 2009
From: hselasky at c2i.net (Hans Petter Selasky)
Date: Sun Feb  8 10:49:05 2009
Subject: HEADSUP usb2/usb4bsd to become default in GENERIC
In-Reply-To: <20090208183820.GA21343@citylink.fud.org.nz>
References: <20090206045349.GQ78804@elvis.mu.org>
	<8b3974a5f1b260fd438518f703aee2f5.squirrel@galain.elvandar.org>
	<20090208183820.GA21343@citylink.fud.org.nz>
Message-ID: <200902081951.16823.hselasky@c2i.net>

On Sunday 08 February 2009, Andrew Thompson wrote:
> On Sun, Feb 08, 2009 at 06:48:39PM +0100, Remko Lodder wrote:
> > On Sun, February 8, 2009 6:21 am, Alfred Perlstein wrote:

> >
> > Please name it "usb_*".

Beware that if you rename everything from "usb2_" to "usb_" there will be 
symbol and structure clashes with the linux USB compat layer, which needs to 
be resolved.

--HPS
From gavin at FreeBSD.org  Sun Feb  8 10:50:15 2009
From: gavin at FreeBSD.org (Gavin Atkinson)
Date: Sun Feb  8 10:50:25 2009
Subject: HEADSUP usb2/usb4bsd to become default in GENERIC
In-Reply-To: <20090208052110.GY78804@elvis.mu.org>
References: <20090206045349.GQ78804@elvis.mu.org>
	<498C013B.4000405@FreeBSD.org>  <20090208052110.GY78804@elvis.mu.org>
Message-ID: <1234119008.7997.32.camel@buffy.york.ac.uk>

On Sat, 2009-02-07 at 21:21 -0800, Alfred Perlstein wrote:
> * Maxim Sobolev <sobomax@FreeBSD.org> [090206 01:50] wrote:
> > Alfred Perlstein wrote:
> > >      - Update GENERIC to use usb2 device names.
> > 
> > Wasn't there a plan to rename usb2 devices to match oldusb names (where 
> > applicable) once oldusb had been killed? I don't see it in the list.
> 
> Probably, although coming from the other side as a user I find it pretty
> annoying when there's somewhat gratuitous changes to the kernel config
> files that I don't really care about that cause my kernels to break.

The vast majority of our users do not run -CURRENT, and so haven't had
to change config files yet.

One day, those users will be migrating from 7.x to 8.x, and shouldn't
need to change their kernel config for a "somewhat gratuitous change".

Your argument only works if people had already had to change their
config files once (usb -> usb2), and that by renaming these back they
will have to change their kernel config back.  Only people running
-CURRENT will end up having to do this twice (or indeed at all) if the
rename takes place, end users will not need to do it at all.

> Basically, calling it usb2 isn't as bad as renaming it back to "usb"
> as it's less disruptive in my book.

Again, I disagree.

Gavin
From sam at freebsd.org  Sun Feb  8 11:12:59 2009
From: sam at freebsd.org (Sam Leffler)
Date: Sun Feb  8 11:13:06 2009
Subject: HEADSUP usb2/usb4bsd to become default in GENERIC
In-Reply-To: <1234119008.7997.32.camel@buffy.york.ac.uk>
References: <20090206045349.GQ78804@elvis.mu.org>	<498C013B.4000405@FreeBSD.org>
	<20090208052110.GY78804@elvis.mu.org>
	<1234119008.7997.32.camel@buffy.york.ac.uk>
Message-ID: <498F2EBA.9000106@freebsd.org>

Gavin Atkinson wrote:
> On Sat, 2009-02-07 at 21:21 -0800, Alfred Perlstein wrote:
>   
>> * Maxim Sobolev <sobomax@FreeBSD.org> [090206 01:50] wrote:
>>     
>>> Alfred Perlstein wrote:
>>>       
>>>>      - Update GENERIC to use usb2 device names.
>>>>         
>>> Wasn't there a plan to rename usb2 devices to match oldusb names (where 
>>> applicable) once oldusb had been killed? I don't see it in the list.
>>>       
>> Probably, although coming from the other side as a user I find it pretty
>> annoying when there's somewhat gratuitous changes to the kernel config
>> files that I don't really care about that cause my kernels to break.
>>     
>
> The vast majority of our users do not run -CURRENT, and so haven't had
> to change config files yet.
>
> One day, those users will be migrating from 7.x to 8.x, and shouldn't
> need to change their kernel config for a "somewhat gratuitous change".
>
> Your argument only works if people had already had to change their
> config files once (usb -> usb2), and that by renaming these back they
> will have to change their kernel config back.  Only people running
> -CURRENT will end up having to do this twice (or indeed at all) if the
> rename takes place, end users will not need to do it at all.
>
>   
>> Basically, calling it usb2 isn't as bad as renaming it back to "usb"
>> as it's less disruptive in my book.
>>     
>
> Again, I disagree.
>   

I agree with your comments.  And, as I've said previously, any name 
changes from usb1 will require _all_ documentation (manual pages, 
handbook, etc) to change; not a good idea.

    Sam

From odhiambo at gmail.com  Sun Feb  8 11:35:24 2009
From: odhiambo at gmail.com (Odhiambo Washington)
Date: Sun Feb  8 11:35:31 2009
Subject: System Freeze when custom kernel is compiled
Message-ID: <991123400902081113p40b14113rb7f22f2649f4f9be@mail.gmail.com>

Helloz,

I have installed -CURRENT inside VMware and I am trying to compile a custom
kernel to play with. Basically, I've just added a few things - IPSEC,
Atheros wireless adapter support and IPFILTER and PF.
Kernel compiles successfully, but when I reboot, the system does not go
beyond the point where it brings the status of the network interface up.I
have had to kill the system and boot the GENERIC kernel, which boots okay.

I have put my kernel config file and dmesg.boot at
http://gw.crownkenya.com/~wash/

I have commented out some of the stuff I'd have wanted, but still no go!
Well, I still have from "device gre all the way to device ef" and two wlan_*
lines, IPFILTER and ALTQ stuff that I am not willing to comment out, as
those will make my intentions for the testing to be negated.

Is it possible I am being over-ambitious with my kernel file? Or is it
VMWare failing me? I've run 7.x inside VMWare quite successfully, so I hoped
-CURRENT woud too, but yes, I know it is -CURRENT;-)

It would be nice for me to test stuff under -CURRENT, yes?



-- 
Best regards,
Odhiambo WASHINGTON,
Nairobi,KE
+254733744121/+254722743223
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
"The only time a woman really succeeds in changing a man is when he is a
baby."
                             - Natalie Wood
From imp at bsdimp.com  Sun Feb  8 11:48:49 2009
From: imp at bsdimp.com (M. Warner Losh)
Date: Sun Feb  8 11:49:01 2009
Subject: HEADSUP usb2/usb4bsd to become default in GENERIC
In-Reply-To: <200902081951.16823.hselasky@c2i.net>
References: <8b3974a5f1b260fd438518f703aee2f5.squirrel@galain.elvandar.org>
	<20090208183820.GA21343@citylink.fud.org.nz>
	<200902081951.16823.hselasky@c2i.net>
Message-ID: <20090208.124756.-942592244.imp@bsdimp.com>

In message: <200902081951.16823.hselasky@c2i.net>
            Hans Petter Selasky <hselasky@c2i.net> writes:
: On Sunday 08 February 2009, Andrew Thompson wrote:
: > On Sun, Feb 08, 2009 at 06:48:39PM +0100, Remko Lodder wrote:
: > > On Sun, February 8, 2009 6:21 am, Alfred Perlstein wrote:
: 
: > >
: > > Please name it "usb_*".
: 
: Beware that if you rename everything from "usb2_" to "usb_" there will be 
: symbol and structure clashes with the linux USB compat layer, which needs to 
: be resolved.

No.  that's not the case.  usb2_foo vs usb_foo in the kernel config
files only affects what files config brings in, and we can easily tell
it to bring the right ones in w/o any symbol issues.

I'd leave everything else where it is now in the source tree.  The
rename is fairly trivial.  Do people want me to float a patch?

Warner
From imp at bsdimp.com  Sun Feb  8 11:54:17 2009
From: imp at bsdimp.com (M. Warner Losh)
Date: Sun Feb  8 11:54:27 2009
Subject: HEADSUP usb2/usb4bsd to become default in GENERIC
In-Reply-To: <20090208.124756.-942592244.imp@bsdimp.com>
References: <20090208183820.GA21343@citylink.fud.org.nz>
	<200902081951.16823.hselasky@c2i.net>
	<20090208.124756.-942592244.imp@bsdimp.com>
Message-ID: <20090208.125317.1170142000.imp@bsdimp.com>

In message: <20090208.124756.-942592244.imp@bsdimp.com>
            "M. Warner Losh" <imp@bsdimp.com> writes:
: In message: <200902081951.16823.hselasky@c2i.net>
:             Hans Petter Selasky <hselasky@c2i.net> writes:
: : On Sunday 08 February 2009, Andrew Thompson wrote:
: : > On Sun, Feb 08, 2009 at 06:48:39PM +0100, Remko Lodder wrote:
: : > > On Sun, February 8, 2009 6:21 am, Alfred Perlstein wrote:
: : 
: : > >
: : > > Please name it "usb_*".
: : 
: : Beware that if you rename everything from "usb2_" to "usb_" there will be 
: : symbol and structure clashes with the linux USB compat layer, which needs to 
: : be resolved.
: 
: No.  that's not the case.  usb2_foo vs usb_foo in the kernel config
: files only affects what files config brings in, and we can easily tell
: it to bring the right ones in w/o any symbol issues.
: 
: I'd leave everything else where it is now in the source tree.  The
: rename is fairly trivial.  Do people want me to float a patch?

Of course, the kernel config file names are just one aspect here.
There's also the module names, that need to be considered.  And also
just because it can be done, doesn't mean we have to it.

Warner
From imp at bsdimp.com  Sun Feb  8 14:34:09 2009
From: imp at bsdimp.com (M. Warner Losh)
Date: Sun Feb  8 14:34:15 2009
Subject: HEADSUP usb2/usb4bsd to become default in GENERIC
In-Reply-To: <F8077156-96AD-4831-9BA9-EEE68A2EF0B9@elvandar.org>
References: <8b3974a5f1b260fd438518f703aee2f5.squirrel@galain.elvandar.org>
	<20090208183820.GA21343@citylink.fud.org.nz>
	<F8077156-96AD-4831-9BA9-EEE68A2EF0B9@elvandar.org>
Message-ID: <20090208.153233.1154625921.imp@bsdimp.com>

In message: <F8077156-96AD-4831-9BA9-EEE68A2EF0B9@elvandar.org>
            Remko Lodder <remko@elvandar.org> writes:
: >>
: >
: > I take it the stage (1) is to switch over GENERIC to the new usb2 code
: > and will not involve renaming the config items.
: >
: > stage (2) moves the usb code around in svn and all USB2 kernel config
: > items will assume their original names, ie. usb2_controller_echi ->
: > ehci.
: >
: > I think this is what Alfred was getting about with only changing it
: > once.
: >
: > Andrew
: 
: 
: That I would like :-)
: 
: thnx for the additional comment :)

Also, keep in mind, once Alfred does the hand off, the project will be
free to do #2.  It really isn't a second change, if you think about
it.  Just because we change the default, that doesn't force people to
use the new default...

Warner
From yanefbsd at gmail.com  Sun Feb  8 17:00:01 2009
From: yanefbsd at gmail.com (Garrett Cooper)
Date: Sun Feb  8 17:00:08 2009
Subject: WITHOUT_INET6 broken on CURRENT
Message-ID: <7d6fde3d0902081659i7cb86al921ea109d17e1a3c@mail.gmail.com>

Hi Randall,
    I recently rebuilt my sources today and I noticed that it's now
breaking on a valid warning with sctp:

cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -march=nocona
-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/usr/src/sys -I/usr/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  -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
/usr/src/sys/netinet/sctputil.c
cc1: warnings being treated as errors
In file included from /usr/src/sys/netinet/sctputil.c:6553:
/usr/src/sys/netinet6/sctp6_var.h:57: warning: 'struct icmp6_hdr'
declared inside parameter list
/usr/src/sys/netinet6/sctp6_var.h:57: warning: its scope is only this
definition or declaration, which is probably not what you want
*** Error code 1

Stop in /usr/obj/usr/src/sys/OPTIMUS.
*** Error code 1

Stop in /usr/src.
*** Error code 1

Stop in /usr/src.

    I'm going to rebuild setting WITHOUT_SCTP for now, but this needs
to be fixed.
Thanks,
-Garrett
From mike at jellydonut.org  Sun Feb  8 17:24:03 2009
From: mike at jellydonut.org (Michael Proto)
Date: Sun Feb  8 17:24:10 2009
Subject: WITHOUT_INET6 broken on CURRENT
In-Reply-To: <7d6fde3d0902081659i7cb86al921ea109d17e1a3c@mail.gmail.com>
References: <7d6fde3d0902081659i7cb86al921ea109d17e1a3c@mail.gmail.com>
Message-ID: <1de79840902081724k243fc300n97dd4f430e0c6cde@mail.gmail.com>

On Sun, Feb 8, 2009 at 7:59 PM, Garrett Cooper <yanefbsd@gmail.com> wrote:
> Hi Randall,
>    I recently rebuilt my sources today and I noticed that it's now
> breaking on a valid warning with sctp:
>
> cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -march=nocona
> -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/usr/src/sys -I/usr/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  -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
> /usr/src/sys/netinet/sctputil.c
> cc1: warnings being treated as errors
> In file included from /usr/src/sys/netinet/sctputil.c:6553:
> /usr/src/sys/netinet6/sctp6_var.h:57: warning: 'struct icmp6_hdr'
> declared inside parameter list
> /usr/src/sys/netinet6/sctp6_var.h:57: warning: its scope is only this
> definition or declaration, which is probably not what you want
> *** Error code 1
>
> Stop in /usr/obj/usr/src/sys/OPTIMUS.
> *** Error code 1
>
> Stop in /usr/src.
> *** Error code 1
>
> Stop in /usr/src.
>
>    I'm going to rebuild setting WITHOUT_SCTP for now, but this needs
> to be fixed.
> Thanks,
> -Garrett


IIRC SCTP has always required INET6 to compile since it was first
introduced. I thought it was a prerequisite.


-Proto
From maksim.yevmenkin at gmail.com  Sun Feb  8 19:17:07 2009
From: maksim.yevmenkin at gmail.com (Maksim Yevmenkin)
Date: Sun Feb  8 19:17:14 2009
Subject: HEADSUP usb2/usb4bsd to become default in GENERIC
In-Reply-To: <498F2EBA.9000106@freebsd.org>
References: <20090206045349.GQ78804@elvis.mu.org>
	<498C013B.4000405@FreeBSD.org> <20090208052110.GY78804@elvis.mu.org>
	<1234119008.7997.32.camel@buffy.york.ac.uk>
	<498F2EBA.9000106@freebsd.org>
Message-ID: <bb4a86c70902081917r7085e867r776606c52f3d9d8c@mail.gmail.com>

On Sun, Feb 8, 2009 at 11:12 AM, Sam Leffler <sam@freebsd.org> wrote:

[...]

>>>>>     - Update GENERIC to use usb2 device names.
>>>>
>>>> Wasn't there a plan to rename usb2 devices to match oldusb names (where
>>>> applicable) once oldusb had been killed? I don't see it in the list.
>>>
>>> Probably, although coming from the other side as a user I find it pretty
>>> annoying when there's somewhat gratuitous changes to the kernel config
>>> files that I don't really care about that cause my kernels to break.
>>
>> The vast majority of our users do not run -CURRENT, and so haven't had
>> to change config files yet.
>>
>> One day, those users will be migrating from 7.x to 8.x, and shouldn't
>> need to change their kernel config for a "somewhat gratuitous change".
>>
>> Your argument only works if people had already had to change their
>> config files once (usb -> usb2), and that by renaming these back they
>> will have to change their kernel config back.  Only people running
>> -CURRENT will end up having to do this twice (or indeed at all) if the
>> rename takes place, end users will not need to do it at all.
>>
>>> Basically, calling it usb2 isn't as bad as renaming it back to "usb"
>>> as it's less disruptive in my book.
>>
>> Again, I disagree.
>
> I agree with your comments.  And, as I've said previously, any name changes
> from usb1 will require _all_ documentation (manual pages, handbook, etc) to
> change; not a good idea.

i second that. i would really like to see old module names to be
preserved as much as possible.

thanks,
max
From yanefbsd at gmail.com  Sun Feb  8 19:34:29 2009
From: yanefbsd at gmail.com (Garrett Cooper)
Date: Sun Feb  8 19:34:35 2009
Subject: WITHOUT_INET6 broken on CURRENT
In-Reply-To: <1de79840902081724k243fc300n97dd4f430e0c6cde@mail.gmail.com>
References: <7d6fde3d0902081659i7cb86al921ea109d17e1a3c@mail.gmail.com>
	<1de79840902081724k243fc300n97dd4f430e0c6cde@mail.gmail.com>
Message-ID: <7d6fde3d0902081934w18ea7a0fgdd0d603ea822f660@mail.gmail.com>

On Sun, Feb 8, 2009 at 5:24 PM, Michael Proto <mike@jellydonut.org> wrote:
> On Sun, Feb 8, 2009 at 7:59 PM, Garrett Cooper <yanefbsd@gmail.com> wrote:
>> Hi Randall,
>>    I recently rebuilt my sources today and I noticed that it's now
>> breaking on a valid warning with sctp:
>>
>> cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -march=nocona
>> -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/usr/src/sys -I/usr/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  -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
>> /usr/src/sys/netinet/sctputil.c
>> cc1: warnings being treated as errors
>> In file included from /usr/src/sys/netinet/sctputil.c:6553:
>> /usr/src/sys/netinet6/sctp6_var.h:57: warning: 'struct icmp6_hdr'
>> declared inside parameter list
>> /usr/src/sys/netinet6/sctp6_var.h:57: warning: its scope is only this
>> definition or declaration, which is probably not what you want
>> *** Error code 1
>>
>> Stop in /usr/obj/usr/src/sys/OPTIMUS.
>> *** Error code 1
>>
>> Stop in /usr/src.
>> *** Error code 1
>>
>> Stop in /usr/src.
>>
>>    I'm going to rebuild setting WITHOUT_SCTP for now, but this needs
>> to be fixed.
>> Thanks,
>> -Garrett
>
>
> IIRC SCTP has always required INET6 to compile since it was first
> introduced. I thought it was a prerequisite.
>
> -Proto

    In that file there's a #ifdef INET6 -- maybe that should be #if
INET6? Also, it's a preprocessor define that doesn't disable any
features as well.

    Also, about INET6 support -- this blurb from the manpage for sctp
makes me believe that IPV6 isn't required (pardon the formatting -- a
direct paste really screwed up the spacing):

     SCTP_I_WANT_MAPPED_V4_ADDR  SCTP supports both IPV4 and IPV6.  An associ-
                                 ation may span both IPV4 and IPV6 addresses
                                 since SCTP is multi-homed.  By default, when
                                 opening an IPV6 socket, when data arrives on
                                 the socket from a peer's V4 address the V4
                                 address  will be presented with an address
                                 family of AF_INET.  If this is undesireable,
                                 then this option can be enabled which will
                                 then convert all V4 addresses into mapped V6
                                 representations.


Thanks,
-Garrett
From yanefbsd at gmail.com  Sun Feb  8 19:40:40 2009
From: yanefbsd at gmail.com (Garrett Cooper)
Date: Sun Feb  8 19:40:47 2009
Subject: HEADSUP usb2/usb4bsd to become default in GENERIC
In-Reply-To: <bb4a86c70902081917r7085e867r776606c52f3d9d8c@mail.gmail.com>
References: <20090206045349.GQ78804@elvis.mu.org>
	<498C013B.4000405@FreeBSD.org> <20090208052110.GY78804@elvis.mu.org>
	<1234119008.7997.32.camel@buffy.york.ac.uk>
	<498F2EBA.9000106@freebsd.org>
	<bb4a86c70902081917r7085e867r776606c52f3d9d8c@mail.gmail.com>
Message-ID: <7d6fde3d0902081940o3ffd8ea1m6f59d65ee59d57ff@mail.gmail.com>

On Sun, Feb 8, 2009 at 7:17 PM, Maksim Yevmenkin
<maksim.yevmenkin@gmail.com> wrote:
> On Sun, Feb 8, 2009 at 11:12 AM, Sam Leffler <sam@freebsd.org> wrote:
>
> [...]
>
>>>>>>     - Update GENERIC to use usb2 device names.
>>>>>
>>>>> Wasn't there a plan to rename usb2 devices to match oldusb names (where
>>>>> applicable) once oldusb had been killed? I don't see it in the list.
>>>>
>>>> Probably, although coming from the other side as a user I find it pretty
>>>> annoying when there's somewhat gratuitous changes to the kernel config
>>>> files that I don't really care about that cause my kernels to break.
>>>
>>> The vast majority of our users do not run -CURRENT, and so haven't had
>>> to change config files yet.
>>>
>>> One day, those users will be migrating from 7.x to 8.x, and shouldn't
>>> need to change their kernel config for a "somewhat gratuitous change".
>>>
>>> Your argument only works if people had already had to change their
>>> config files once (usb -> usb2), and that by renaming these back they
>>> will have to change their kernel config back.  Only people running
>>> -CURRENT will end up having to do this twice (or indeed at all) if the
>>> rename takes place, end users will not need to do it at all.
>>>
>>>> Basically, calling it usb2 isn't as bad as renaming it back to "usb"
>>>> as it's less disruptive in my book.
>>>
>>> Again, I disagree.
>>
>> I agree with your comments.  And, as I've said previously, any name changes
>> from usb1 will require _all_ documentation (manual pages, handbook, etc) to
>> change; not a good idea.
>
> i second that. i would really like to see old module names to be
> preserved as much as possible.
>
> thanks,
> max

    In some cases I find the new module names to be more intuitive
(uplcom -> usb2_serial_plcom), but I find having to add the additional
modules required for USB4BSD (usb2_core, etc) to be a bit more
annoying.
    Also, there's an issue with the example USB2 kernel config -- you
need to have double-quotes around the include file otherwise config
says `syntax error' and pukes.
Thanks,
-Garrett
From sobomax at FreeBSD.org  Sun Feb  8 20:00:14 2009
From: sobomax at FreeBSD.org (Maxim Sobolev)
Date: Sun Feb  8 20:00:26 2009
Subject: HEADSUP usb2/usb4bsd to become default in GENERIC
In-Reply-To: <1234119008.7997.32.camel@buffy.york.ac.uk>
References: <20090206045349.GQ78804@elvis.mu.org>	
	<498C013B.4000405@FreeBSD.org>
	<20090208052110.GY78804@elvis.mu.org>
	<1234119008.7997.32.camel@buffy.york.ac.uk>
Message-ID: <498FAA44.9050105@FreeBSD.org>

Gavin Atkinson wrote:
> On Sat, 2009-02-07 at 21:21 -0800, Alfred Perlstein wrote:
>> * Maxim Sobolev <sobomax@FreeBSD.org> [090206 01:50] wrote:
>>> Alfred Perlstein wrote:
>>>>      - Update GENERIC to use usb2 device names.
>>> Wasn't there a plan to rename usb2 devices to match oldusb names (where 
>>> applicable) once oldusb had been killed? I don't see it in the list.
>> Probably, although coming from the other side as a user I find it pretty
>> annoying when there's somewhat gratuitous changes to the kernel config
>> files that I don't really care about that cause my kernels to break.
> 
> The vast majority of our users do not run -CURRENT, and so haven't had
> to change config files yet.
> 
> One day, those users will be migrating from 7.x to 8.x, and shouldn't
> need to change their kernel config for a "somewhat gratuitous change".
> 
> Your argument only works if people had already had to change their
> config files once (usb -> usb2), and that by renaming these back they
> will have to change their kernel config back.  Only people running
> -CURRENT will end up having to do this twice (or indeed at all) if the
> rename takes place, end users will not need to do it at all.

That's exactly my point. Number of people running -CURRENT is much less 
than total number of people running FreeBSD. Therefore, I believe we 
should try to avoid introducing any superfluous changes upon those 
users. Not even to mention large body of USB-related documentation that 
will need to be altered to match the new USB world order.

Users running -CURRENT should be prepared to make changes now and then, 
it's part of the game. I don't POLA is really applicable to them.

-Maxim
From remko at elvandar.org  Sun Feb  8 12:00:03 2009
From: remko at elvandar.org (Remko Lodder)
Date: Sun Feb  8 20:19:56 2009
Subject: HEADSUP usb2/usb4bsd to become default in GENERIC
In-Reply-To: <20090208183820.GA21343@citylink.fud.org.nz>
References: <20090206045349.GQ78804@elvis.mu.org>
	<498C013B.4000405@FreeBSD.org>
	<20090208052110.GY78804@elvis.mu.org>
	<8b3974a5f1b260fd438518f703aee2f5.squirrel@galain.elvandar.org>
	<20090208183820.GA21343@citylink.fud.org.nz>
Message-ID: <F8077156-96AD-4831-9BA9-EEE68A2EF0B9@elvandar.org>

>>
>
> I take it the stage (1) is to switch over GENERIC to the new usb2 code
> and will not involve renaming the config items.
>
> stage (2) moves the usb code around in svn and all USB2 kernel config
> items will assume their original names, ie. usb2_controller_echi ->
> ehci.
>
> I think this is what Alfred was getting about with only changing it
> once.
>
> Andrew


That I would like :-)

thnx for the additional comment :)

-- 
/"\   Best regards,                        | remko@FreeBSD.org
\ /   Remko Lodder                      | remko@EFnet
X    http://www.evilcoder.org/    |
/ \   ASCII Ribbon Campaign    | Against HTML Mail and News

From bzeeb-lists at lists.zabbadoz.net  Sun Feb  8 22:50:08 2009
From: bzeeb-lists at lists.zabbadoz.net (Bjoern A. Zeeb)
Date: Sun Feb  8 22:50:15 2009
Subject: WITHOUT_INET6 broken on CURRENT
In-Reply-To: <1de79840902081724k243fc300n97dd4f430e0c6cde@mail.gmail.com>
References: <7d6fde3d0902081659i7cb86al921ea109d17e1a3c@mail.gmail.com>
	<1de79840902081724k243fc300n97dd4f430e0c6cde@mail.gmail.com>
Message-ID: <20090209064718.C93725@maildrop.int.zabbadoz.net>

On Sun, 8 Feb 2009, Michael Proto wrote:

> On Sun, Feb 8, 2009 at 7:59 PM, Garrett Cooper <yanefbsd@gmail.com> wrote:
>> Hi Randall,
>>    I recently rebuilt my sources today and I noticed that it's now
>> breaking on a valid warning with sctp:
>>
...
>> /usr/src/sys/netinet/sctputil.c
>> cc1: warnings being treated as errors
>> In file included from /usr/src/sys/netinet/sctputil.c:6553:
>> /usr/src/sys/netinet6/sctp6_var.h:57: warning: 'struct icmp6_hdr'
>> declared inside parameter list
>> /usr/src/sys/netinet6/sctp6_var.h:57: warning: its scope is only this
>> definition or declaration, which is probably not what you want
>> *** Error code 1
...
>>    I'm going to rebuild setting WITHOUT_SCTP for now, but this needs
>> to be fixed.
>
> IIRC SCTP has always required INET6 to compile since it was first
> introduced. I thought it was a prerequisite.

No, we've always fixed it.

I have sent this patch to Randall last weekend:

Index: sys/netinet/sctputil.c
===================================================================
--- sys/netinet/sctputil.c      (revision 188293)
+++ sys/netinet/sctputil.c      (working copy)
@@ -6550,7 +6550,6 @@
  #include <netinet/udp.h>
  #include <netinet/udp_var.h>
  #include <sys/proc.h>
-#include <netinet6/sctp6_var.h>

  static void
  sctp_recv_udp_tunneled_packet(struct mbuf *m, int off, struct inpcb *ignored)

-- 
Bjoern A. Zeeb                      The greatest risk is not taking one.
From hselasky at c2i.net  Mon Feb  9 00:24:40 2009
From: hselasky at c2i.net (Hans Petter Selasky)
Date: Mon Feb  9 00:24:54 2009
Subject: HEADSUP usb2/usb4bsd to become default in GENERIC
In-Reply-To: <7d6fde3d0902081940o3ffd8ea1m6f59d65ee59d57ff@mail.gmail.com>
References: <20090206045349.GQ78804@elvis.mu.org>
	<bb4a86c70902081917r7085e867r776606c52f3d9d8c@mail.gmail.com>
	<7d6fde3d0902081940o3ffd8ea1m6f59d65ee59d57ff@mail.gmail.com>
Message-ID: <200902090927.04378.hselasky@c2i.net>

On Monday 09 February 2009, Garrett Cooper wrote:
> On Sun, Feb 8, 2009 at 7:17 PM, Maksim Yevmenkin
>
> <maksim.yevmenkin@gmail.com> wrote:
> > On Sun, Feb 8, 2009 at 11:12 AM, Sam Leffler <sam@freebsd.org> wrote:
> >
> > [...]
> >
> >>>>>>     - Update GENERIC to use usb2 device names.
> >>>>>
> >>>>> Wasn't there a plan to rename usb2 devices to match oldusb names
> >>>>> (where applicable) once oldusb had been killed? I don't see it in the
> >>>>> list.
> >>>>
> >>>> Probably, although coming from the other side as a user I find it
> >>>> pretty annoying when there's somewhat gratuitous changes to the kernel
> >>>> config files that I don't really care about that cause my kernels to
> >>>> break.
> >>>
> >>> The vast majority of our users do not run -CURRENT, and so haven't had
> >>> to change config files yet.
> >>>
> >>> One day, those users will be migrating from 7.x to 8.x, and shouldn't
> >>> need to change their kernel config for a "somewhat gratuitous change".
> >>>
> >>> Your argument only works if people had already had to change their
> >>> config files once (usb -> usb2), and that by renaming these back they
> >>> will have to change their kernel config back.  Only people running
> >>> -CURRENT will end up having to do this twice (or indeed at all) if the
> >>> rename takes place, end users will not need to do it at all.
> >>>
> >>>> Basically, calling it usb2 isn't as bad as renaming it back to "usb"
> >>>> as it's less disruptive in my book.
> >>>
> >>> Again, I disagree.
> >>
> >> I agree with your comments.  And, as I've said previously, any name
> >> changes from usb1 will require _all_ documentation (manual pages,
> >> handbook, etc) to change; not a good idea.
> >
> > i second that. i would really like to see old module names to be
> > preserved as much as possible.
> >
> > thanks,
> > max
>
>     In some cases I find the new module names to be more intuitive
> (uplcom -> usb2_serial_plcom), but I find having to add the additional
> modules required for USB4BSD (usb2_core, etc) to be a bit more
> annoying.
>     Also, there's an issue with the example USB2 kernel config -- you
> need to have double-quotes around the include file otherwise config
> says `syntax error' and pukes.

How about symlinking the old module names with the new ones?
And the same in the kernel, so that

device uplcom

Is equivalent to

device usb2_serial_plcom

From what I understand the "conf/files" syntax allows this. Not sure about 
KMODs, if there is a LINK option.

--HPS
From hselasky at c2i.net  Mon Feb  9 00:24:40 2009
From: hselasky at c2i.net (Hans Petter Selasky)
Date: Mon Feb  9 00:24:55 2009
Subject: HEADSUP usb2/usb4bsd to become default in GENERIC
In-Reply-To: <7d6fde3d0902081940o3ffd8ea1m6f59d65ee59d57ff@mail.gmail.com>
References: <20090206045349.GQ78804@elvis.mu.org>
	<bb4a86c70902081917r7085e867r776606c52f3d9d8c@mail.gmail.com>
	<7d6fde3d0902081940o3ffd8ea1m6f59d65ee59d57ff@mail.gmail.com>
Message-ID: <200902090927.04378.hselasky@c2i.net>

On Monday 09 February 2009, Garrett Cooper wrote:
> On Sun, Feb 8, 2009 at 7:17 PM, Maksim Yevmenkin
>
> <maksim.yevmenkin@gmail.com> wrote:
> > On Sun, Feb 8, 2009 at 11:12 AM, Sam Leffler <sam@freebsd.org> wrote:
> >
> > [...]
> >
> >>>>>>     - Update GENERIC to use usb2 device names.
> >>>>>
> >>>>> Wasn't there a plan to rename usb2 devices to match oldusb names
> >>>>> (where applicable) once oldusb had been killed? I don't see it in the
> >>>>> list.
> >>>>
> >>>> Probably, although coming from the other side as a user I find it
> >>>> pretty annoying when there's somewhat gratuitous changes to the kernel
> >>>> config files that I don't really care about that cause my kernels to
> >>>> break.
> >>>
> >>> The vast majority of our users do not run -CURRENT, and so haven't had
> >>> to change config files yet.
> >>>
> >>> One day, those users will be migrating from 7.x to 8.x, and shouldn't
> >>> need to change their kernel config for a "somewhat gratuitous change".
> >>>
> >>> Your argument only works if people had already had to change their
> >>> config files once (usb -> usb2), and that by renaming these back they
> >>> will have to change their kernel config back.  Only people running
> >>> -CURRENT will end up having to do this twice (or indeed at all) if the
> >>> rename takes place, end users will not need to do it at all.
> >>>
> >>>> Basically, calling it usb2 isn't as bad as renaming it back to "usb"
> >>>> as it's less disruptive in my book.
> >>>
> >>> Again, I disagree.
> >>
> >> I agree with your comments.  And, as I've said previously, any name
> >> changes from usb1 will require _all_ documentation (manual pages,
> >> handbook, etc) to change; not a good idea.
> >
> > i second that. i would really like to see old module names to be
> > preserved as much as possible.
> >
> > thanks,
> > max
>
>     In some cases I find the new module names to be more intuitive
> (uplcom -> usb2_serial_plcom), but I find having to add the additional
> modules required for USB4BSD (usb2_core, etc) to be a bit more
> annoying.
>     Also, there's an issue with the example USB2 kernel config -- you
> need to have double-quotes around the include file otherwise config
> says `syntax error' and pukes.

How about symlinking the old module names with the new ones?
And the same in the kernel, so that

device uplcom

Is equivalent to

device usb2_serial_plcom

From what I understand the "conf/files" syntax allows this. Not sure about 
KMODs, if there is a LINK option.

--HPS
From michael.gusek at web.de  Mon Feb  9 01:04:31 2009
From: michael.gusek at web.de (Michael Gusek)
Date: Mon Feb  9 01:04:38 2009
Subject: zfs: allocating allocated segment
In-Reply-To: <498D6824.8060303@web.de>
References: <200902051224.34442.michael.gusek@web.de>	<20090206232327.GA19383@hyperion.scode.org>
	<498D6824.8060303@web.de>
Message-ID: <498FF19C.7000303@web.de>

Michael Gusek schrieb:
> Peter Schuller schrieb:
>>> I'm running a File server with zfs, 64 Bit, 4 GB Ram and RELENG_7. 
>>> Two days ago i uploaded a file via ftp to the server and the server 
>>> is crashing. After reboot FreeBSD can't import the zfs-pool. There 
>>> is a kernel-message:
>>>
>>> panic: Solaris(panic): zfs: allocating allocated 
>>> segment(offset=123456... size=74)
>>>
>>> cpuid = 0
>>> Uptime: 14m22s
>>> panic: bufwrite: buffer is not busy???
>>>
>>> Now i try to import the zfs-pool with a recent 8.0-current but with 
>>> the same result. It's very important to me to access the pool, so 
>>> did you have some idea's ?
>>>     
>>
>> The ZFS panic is from space_map.c in space_map_add(), happening via
>> zfs_panic_recover(). It in turn is affected by zfs_recover:
>>
>> /*                                                                                                                                                                                                                                             
>> * zfs_recover can be set to nonzero to attempt to recover 
>> from                                                                                                                                                                                
>> * otherwise-fatal errors, typically caused by on-disk corruption.  
>> When                                                                                                                                                                       
>> * set, calls to zfs_panic_recover() will turn into warning 
>> messages.                                                                                                                                                                          
>> */
>>
>> Setting the vfs.zfs.recover loader variable to 1 might possibly
>> help. However I have never tried using that option and I'm not
>> familiar with the code, so I have no idea how safe it is. In
>> particular since you then seem to be getting a secondary panic (the
>> "buffer is not busy" which is from ffs_vfsops.
>>
>> On another note:
>>
>> http://www.google.com/search?client=opera&rls=en&q=zfs:+allocating+allocated+segment&sourceid=opera&ie=utf-8&oe=utf-8 
>>
>>
>> indicates you're not the only person who has seen similar
>> errors. Unfortunately I cannot offer any insight other than to suggest
>> digging through the google results.
>>
>> Was the original crash, prior to the mount problem, purely a software
>> crash or was there, for example, a power outtage? I'm wondering
>> whether there is any particular reason to believe there was some
>> hardware/firmware fault causing corruption.
>>
>>   
> Thank you for your response Petter,
>
> on Monday i will give vfs.zfs.recover a try. The original crash was 
> beeing a ftp upload. There was'nt a power outtage or another kernel 
> message, so i don't think it is an hardware issue.
>
> Regards,
>
> Michael
So now i'm trying set vfs.zfs.recover to 1. But the kernel crashed with

panic: solaris assert: sm->sm_space == space (0xxfceee400 == 0xfceefc00) 
file:
/usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/space_map.c, 
line: 357

I't seems the zfs structure is corrupt ? And then, is there a chance to 
repair this ?

Greetings,

Michael


From keramida at ceid.upatras.gr  Mon Feb  9 01:58:37 2009
From: keramida at ceid.upatras.gr (Giorgos Keramidas)
Date: Mon Feb  9 01:58:52 2009
Subject: HEADSUP usb2/usb4bsd to become default in GENERIC
In-Reply-To: <200902090927.04378.hselasky@c2i.net> (Hans Petter Selasky's
	message of "Mon, 9 Feb 2009 09:27:03 +0100")
References: <20090206045349.GQ78804@elvis.mu.org>
	<bb4a86c70902081917r7085e867r776606c52f3d9d8c@mail.gmail.com>
	<7d6fde3d0902081940o3ffd8ea1m6f59d65ee59d57ff@mail.gmail.com>
	<200902090927.04378.hselasky@c2i.net>
Message-ID: <87zlgwq6dd.fsf@kobe.laptop>

On Mon, 9 Feb 2009 09:27:03 +0100, Hans Petter Selasky <hselasky@c2i.net> wrote:
> On Monday 09 February 2009, Garrett Cooper wrote:
>> In some cases I find the new module names to be more intuitive
>> (uplcom -> usb2_serial_plcom), but I find having to add the additional
>> modules required for USB4BSD (usb2_core, etc) to be a bit more
>> annoying.
>>
>> Also, there's an issue with the example USB2 kernel config -- you
>> need to have double-quotes around the include file otherwise config
>> says `syntax error' and pukes.
>
> How about symlinking the old module names with the new ones?

That may work as a temporary 'hack' for kldload, but it won't really
work kldstat, kldunload and apropos(1) or the examples of these in the
documentation.

From keramida at ceid.upatras.gr  Mon Feb  9 01:58:37 2009
From: keramida at ceid.upatras.gr (Giorgos Keramidas)
Date: Mon Feb  9 01:58:53 2009
Subject: HEADSUP usb2/usb4bsd to become default in GENERIC
In-Reply-To: <200902090927.04378.hselasky@c2i.net> (Hans Petter Selasky's
	message of "Mon, 9 Feb 2009 09:27:03 +0100")
References: <20090206045349.GQ78804@elvis.mu.org>
	<bb4a86c70902081917r7085e867r776606c52f3d9d8c@mail.gmail.com>
	<7d6fde3d0902081940o3ffd8ea1m6f59d65ee59d57ff@mail.gmail.com>
	<200902090927.04378.hselasky@c2i.net>
Message-ID: <87zlgwq6dd.fsf@kobe.laptop>

On Mon, 9 Feb 2009 09:27:03 +0100, Hans Petter Selasky <hselasky@c2i.net> wrote:
> On Monday 09 February 2009, Garrett Cooper wrote:
>> In some cases I find the new module names to be more intuitive
>> (uplcom -> usb2_serial_plcom), but I find having to add the additional
>> modules required for USB4BSD (usb2_core, etc) to be a bit more
>> annoying.
>>
>> Also, there's an issue with the example USB2 kernel config -- you
>> need to have double-quotes around the include file otherwise config
>> says `syntax error' and pukes.
>
> How about symlinking the old module names with the new ones?

That may work as a temporary 'hack' for kldload, but it won't really
work kldstat, kldunload and apropos(1) or the examples of these in the
documentation.

From rrs at lakerest.net  Mon Feb  9 03:20:29 2009
From: rrs at lakerest.net (Randall Stewart)
Date: Mon Feb  9 03:20:38 2009
Subject: WITHOUT_INET6 broken on CURRENT
In-Reply-To: <7d6fde3d0902081659i7cb86al921ea109d17e1a3c@mail.gmail.com>
References: <7d6fde3d0902081659i7cb86al921ea109d17e1a3c@mail.gmail.com>
Message-ID: <E9290005-0B87-4CD4-81B9-5C764AF56211@lakerest.net>

Garrett:

Pointy hat to me :-)

I will be committing a fix within the next few minutes (also adding  
the no-v6 option to
my build list :-D)

Thanks

R
On Feb 8, 2009, at 7:59 PM, Garrett Cooper wrote:

> Hi Randall,
>    I recently rebuilt my sources today and I noticed that it's now
> breaking on a valid warning with sctp:
>
> cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -march=nocona
> -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/usr/src/sys -I/usr/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  -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
> /usr/src/sys/netinet/sctputil.c
> cc1: warnings being treated as errors
> In file included from /usr/src/sys/netinet/sctputil.c:6553:
> /usr/src/sys/netinet6/sctp6_var.h:57: warning: 'struct icmp6_hdr'
> declared inside parameter list
> /usr/src/sys/netinet6/sctp6_var.h:57: warning: its scope is only this
> definition or declaration, which is probably not what you want
> *** Error code 1
>
> Stop in /usr/obj/usr/src/sys/OPTIMUS.
> *** Error code 1
>
> Stop in /usr/src.
> *** Error code 1
>
> Stop in /usr/src.
>
>    I'm going to rebuild setting WITHOUT_SCTP for now, but this needs
> to be fixed.
> Thanks,
> -Garrett
> _______________________________________________
> 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 
> "
>

------------------------------
Randall Stewart
803-317-4952 (cell)
803-345-0391(direct)

From christoph.mallon at gmx.de  Mon Feb  9 03:24:53 2009
From: christoph.mallon at gmx.de (Christoph Mallon)
Date: Mon Feb  9 03:25:01 2009
Subject: HEADSUP usb2/usb4bsd to become default in GENERIC
In-Reply-To: <20090206045349.GQ78804@elvis.mu.org>
References: <20090206045349.GQ78804@elvis.mu.org>
Message-ID: <49901276.5040604@gmx.de>

Alfred Perlstein schrieb:
> Hello -current and -usb.
> 
> We are in the final stages of bringing in the new usb
> stack.
[...]
> At this point we expect there to be no style or changes in usb2
> that are not bugfixes until Phase 3 "Hand off".  The reason for
> this is to prevent bugs from creeping in and allow the maintainer
> to focus 100% on bugs and feature parity with the oldusb stack.

cparser identifies 40 variables in libusb20 and the usb2 code, which are 
only assigned, but never read. I think it's worrisome that 12 of these 
are named "err" or "error". This should be investigated, so here's the 
complete list:

> lib/libusb20/libusb20_desc.c:509: warning: variable 'dummy' is never read
> lib/libusb20/libusb20_desc.c:665: warning: variable 'dummy' is never read
> sys/dev/usb2/controller/at91dci.c:1829: warning: variable 'use_polling' is never read 
> sys/dev/usb2/controller/at91dci_atmelarm.c:77: warning: variable 'temp' is never read
> sys/dev/usb2/controller/at91dci_atmelarm.c:250: warning: variable 'err' is never read
> sys/dev/usb2/controller/atmegadci.c:777: warning: variable 'sc' is never read 
> sys/dev/usb2/controller/atmegadci.c:780: warning: variable 'ep_no' is never read
> sys/dev/usb2/controller/atmegadci.c:1698: warning: variable 'use_polling' is never read 
> sys/dev/usb2/controller/atmegadci.c:2151: warning: variable 'sc' is never read 
> sys/dev/usb2/controller/ehci2.c:2308: warning: variable 'slot' is never read
> sys/dev/usb2/controller/musb2_otg.c:899: warning: variable 'sc' is never read 
> sys/dev/usb2/controller/musb2_otg.c:1124: warning: variable 'sc' is never read 
> sys/dev/usb2/controller/musb2_otg.c:1127: warning: variable 'ep_no' is never read
> sys/dev/usb2/controller/musb2_otg.c:2235: warning: variable 'use_polling' is never read 
> sys/dev/usb2/controller/musb2_otg.c:2697: warning: variable 'sc' is never read 
> sys/dev/usb2/controller/musb2_otg_atmelarm.c:165: warning: variable 'err' is never read
> sys/dev/usb2/controller/ohci2.c:2501: warning: variable 'sc' is never read 
> sys/dev/usb2/controller/ohci2_atmelarm.c:151: warning: variable 'err' is never read
> sys/dev/usb2/controller/uhci2.c:1297: warning: variable 'token' is never read
> sys/dev/usb2/controller/uhci2.c:2986: warning: variable 'sc' is never read 
> sys/dev/usb2/controller/uss820dci.c:821: warning: variable 'sc' is never read 
> sys/dev/usb2/controller/uss820dci.c:824: warning: variable 'ep_no' is never read
> sys/dev/usb2/controller/uss820dci.c:1847: warning: variable 'use_polling' is never read 
> sys/dev/usb2/controller/uss820dci_atmelarm.c:206: warning: variable 'err' is never read
> sys/dev/usb2/core/usb2_busdma.c:202: warning: variable 'error' is never read
> sys/dev/usb2/core/usb2_compat_linux.c:337: warning: variable 'err' is never read
> sys/dev/usb2/core/usb2_compat_linux.c:355: warning: variable 'err' is never read
> sys/dev/usb2/core/usb2_compat_linux.c:1181: warning: variable 'err' is never read
> sys/dev/usb2/core/usb2_compat_linux.c:1274: warning: variable 'err' is never read
> sys/dev/usb2/core/usb2_dev.c:1753: warning: variable 'resid' is never read
> sys/dev/usb2/core/usb2_dev.c:1896: warning: variable 'resid' is never read
> sys/dev/usb2/core/usb2_device.c:925: warning: variable 'err' is never read
> sys/dev/usb2/core/usb2_util.c:275: warning: variable 'err' is never read
> sys/dev/usb2/serial/umoscom2.c:525: warning: variable 'lsr' is never read
> sys/dev/usb2/sound/uaudio2.c:795: warning: variable 'ep_sync' is never read
> sys/dev/usb2/sound/uaudio2.c:2001: warning: variable 'd1' is never read 
> sys/dev/usb2/storage/ata-usb2.c:328: warning: variable 'has_intr' is never read
> sys/dev/usb2/storage/umass2.c:1636: warning: variable 'err' is never read
> sys/dev/usb2/storage/ustorage2_fs.c:906: warning: variable 'file_offset' is never read 
> sys/dev/usb2/storage/ustorage2_fs.c:907: warning: variable 'amount_left' is never read 

(For easy processing copy the list into $FILE and use "vim -q $FILE")

Regards
	Christoph
From christoph.mallon at gmx.de  Mon Feb  9 03:29:38 2009
From: christoph.mallon at gmx.de (Christoph Mallon)
Date: Mon Feb  9 03:29:46 2009
Subject: HEADSUP usb2/usb4bsd to become default in GENERIC
In-Reply-To: <49901276.5040604@gmx.de>
References: <20090206045349.GQ78804@elvis.mu.org> <49901276.5040604@gmx.de>
Message-ID: <49901399.8070409@gmx.de>

Christoph Mallon schrieb:
> are named "err" or "error". This should be investigated, so here's the 
> complete list:

Sorry, my MUA seems to have damaged the list. You can get the list here: 
http://tron.homeunix.org/usb2.unread.log
From hselasky at c2i.net  Mon Feb  9 05:47:42 2009
From: hselasky at c2i.net (Hans Petter Selasky)
Date: Mon Feb  9 05:47:49 2009
Subject: HEADSUP usb2/usb4bsd to become default in GENERIC
In-Reply-To: <49901399.8070409@gmx.de>
References: <20090206045349.GQ78804@elvis.mu.org> <49901276.5040604@gmx.de>
	<49901399.8070409@gmx.de>
Message-ID: <200902091450.07014.hselasky@c2i.net>

On Monday 09 February 2009, Christoph Mallon wrote:
> Christoph Mallon schrieb:
> > are named "err" or "error". This should be investigated, so here's the
> > complete list:
>
> Sorry, my MUA seems to have damaged the list. You can get the list here:
> http://tron.homeunix.org/usb2.unread.log

I think some of these errors depend if you have USB debugging compiled or not. 
At least GCC does not warn?

--HPS
From amdmi3 at amdmi3.ru  Mon Feb  9 05:48:20 2009
From: amdmi3 at amdmi3.ru (Dmitry Marakasov)
Date: Mon Feb  9 05:48:28 2009
Subject: Bad unicode `-' in manpages
In-Reply-To: <867i43742t.fsf@gmail.com>
References: <20090206183344.GE17600@hades.panopticon>
	<867i43742t.fsf@gmail.com>
Message-ID: <20090209134806.GF17600@hades.panopticon>

* Anonymous (swell.k@gmail.com) wrote:

> Have you tried to change locale to `C' or invoke man(1) with `-o'?

Yes, they both result in the old behaviour with correct `-'.

> Anyway, same here, but I vaguely remember it first appeared about half a

I'm only using current for couple of weeks, so it's new to me.

> year ago. And I think it can cause trouble when trying to view localized
> man page written in unicode when you can't escape to either `C' locale
> or `-o' option.

Agreed. But actually you shouldn't need to specify extra arguments to
man or change locale to view /correct/ man page, so I think it should be
fixed.

-- 
Dmitry Marakasov   .   55B5 0596 FF1E 8D84 5F56  9510 D35A 80DD F9D2 F77D
amdmi3@amdmi3.ru  ..:  jabber: amdmi3@jabber.ru    http://www.amdmi3.ru
From christoph.mallon at gmx.de  Mon Feb  9 06:08:34 2009
From: christoph.mallon at gmx.de (Christoph Mallon)
Date: Mon Feb  9 06:08:47 2009
Subject: HEADSUP usb2/usb4bsd to become default in GENERIC
In-Reply-To: <200902091450.07014.hselasky@c2i.net>
References: <20090206045349.GQ78804@elvis.mu.org>
	<49901276.5040604@gmx.de>	<49901399.8070409@gmx.de>
	<200902091450.07014.hselasky@c2i.net>
Message-ID: <499038DE.3050501@gmx.de>

Hans Petter Selasky schrieb:
> On Monday 09 February 2009, Christoph Mallon wrote:
>> Christoph Mallon schrieb:
>>> are named "err" or "error". This should be investigated, so here's the
>>> complete list:
>> Sorry, my MUA seems to have damaged the list. You can get the list here:
>> http://tron.homeunix.org/usb2.unread.log
> 
> I think some of these errors depend if you have USB debugging compiled or not. 
> At least GCC does not warn?

No, it does not depend on USB debugging.
GCC has no warning at all for variables which are only assigned to.
It only can warn about variables, which are only initialised.

{
   int x = 23; // GCC warns here ...
   int y;      // ... but not here - cparser does
   y = 42;
   y++;
}

cparser has an analysis, which can warn about "y", too.

I manually verified all 40 warnings and I cannot find any users (i.e. 
readers) for these variables.
From hselasky at c2i.net  Mon Feb  9 06:31:47 2009
From: hselasky at c2i.net (Hans Petter Selasky)
Date: Mon Feb  9 06:32:03 2009
Subject: HEADSUP usb2/usb4bsd to become default in GENERIC
In-Reply-To: <499038DE.3050501@gmx.de>
References: <20090206045349.GQ78804@elvis.mu.org>
	<200902091450.07014.hselasky@c2i.net> <499038DE.3050501@gmx.de>
Message-ID: <200902091534.12506.hselasky@c2i.net>

On Monday 09 February 2009, Christoph Mallon wrote:
> Hans Petter Selasky schrieb:
> > On Monday 09 February 2009, Christoph Mallon wrote:
> >> Christoph Mallon schrieb:
> >>> are named "err" or "error". This should be investigated, so here's the
> >>> complete list:
> >>
> >> Sorry, my MUA seems to have damaged the list. You can get the list here:
> >> http://tron.homeunix.org/usb2.unread.log
> >
> > I think some of these errors depend if you have USB debugging compiled or
> > not. At least GCC does not warn?
>
> No, it does not depend on USB debugging.
> GCC has no warning at all for variables which are only assigned to.
> It only can warn about variables, which are only initialised.
>
> {
>    int x = 23; // GCC warns here ...
>    int y;      // ... but not here - cparser does
>    y = 42;
>    y++;
> }
>
> cparser has an analysis, which can warn about "y", too.
>
> I manually verified all 40 warnings and I cannot find any users (i.e.
> readers) for these variables.

What is the correct way to discard the return argument of a function? That's 
basically what most of the warnings are about.

1) (void)my_fn() cast
2) if (my_fn()) { }
3) err = my_fn();
4) my_fn();

--HPS
From christoph.mallon at gmx.de  Mon Feb  9 06:48:30 2009
From: christoph.mallon at gmx.de (Christoph Mallon)
Date: Mon Feb  9 06:48:52 2009
Subject: HEADSUP usb2/usb4bsd to become default in GENERIC
In-Reply-To: <200902091534.12506.hselasky@c2i.net>
References: <20090206045349.GQ78804@elvis.mu.org>	<200902091450.07014.hselasky@c2i.net>
	<499038DE.3050501@gmx.de> <200902091534.12506.hselasky@c2i.net>
Message-ID: <49904238.50505@gmx.de>

Hans Petter Selasky schrieb:
> On Monday 09 February 2009, Christoph Mallon wrote:
>> Hans Petter Selasky schrieb:
>>> On Monday 09 February 2009, Christoph Mallon wrote:
>>>> Christoph Mallon schrieb:
>>>>> are named "err" or "error". This should be investigated, so here's the
>>>>> complete list:
>>>> Sorry, my MUA seems to have damaged the list. You can get the list here:
>>>> http://tron.homeunix.org/usb2.unread.log
>>> I think some of these errors depend if you have USB debugging compiled or
>>> not. At least GCC does not warn?
>> No, it does not depend on USB debugging.
>> GCC has no warning at all for variables which are only assigned to.
>> It only can warn about variables, which are only initialised.
>>
>> {
>>    int x = 23; // GCC warns here ...
>>    int y;      // ... but not here - cparser does
>>    y = 42;
>>    y++;
>> }
>>
>> cparser has an analysis, which can warn about "y", too.
>>
>> I manually verified all 40 warnings and I cannot find any users (i.e.
>> readers) for these variables.
> 
> What is the correct way to discard the return argument of a function? That's 
> basically what most of the warnings are about.
> 
> 1) (void)my_fn() cast
> 2) if (my_fn()) { }
> 3) err = my_fn();
> 4) my_fn();

Just to understand this correctly: You want to discard error codes?


Basically I see four categories:

1) Getting the softc and not using it.
This can be removed completely.
Example:
   sc = ATMEGA_BUS2SC(xfer->xroot->bus);

2) calling mtx_owned() and discarding the return value.
Can be removed, too, after checking that the value is really unnecessary.
Example:
   use_polling = mtx_owned(xfer->xroot->xfer_mtx) ? 1 : 0;

3) Getting some value and not using it.
Can be removed, too, after checking that the value is really unnecessary.
Example:
   ep_no = (xfer->endpoint & UE_ADDR);

4) The rest are return values of functions, which contain error codes.
Discarding them is questionable at best.
Example: (err is not read)
     if (udev->flags.suspended) {
       err = DEVICE_SUSPEND(iface->subdev);
       device_printf(iface->subdev, "Suspend failed\n");
     }
     return (0);   /* success */
From hselasky at c2i.net  Mon Feb  9 07:06:11 2009
From: hselasky at c2i.net (Hans Petter Selasky)
Date: Mon Feb  9 07:06:18 2009
Subject: HEADSUP usb2/usb4bsd to become default in GENERIC
In-Reply-To: <49904238.50505@gmx.de>
References: <20090206045349.GQ78804@elvis.mu.org>
	<200902091534.12506.hselasky@c2i.net> <49904238.50505@gmx.de>
Message-ID: <200902091608.34376.hselasky@c2i.net>

On Monday 09 February 2009, Christoph Mallon wrote:
> Hans Petter Selasky schrieb:
> > On Monday 09 February 2009, Christoph Mallon wrote:
> >> Hans Petter Selasky schrieb:
> >>> On Monday 09 February 2009, Christoph Mallon wrote:
> >>>> Christoph Mallon schrieb:
> >>>>> are named "err" or "error". This should be investigated, so here's
> >>>>> the complete list:
> >>>>
> >>>> Sorry, my MUA seems to have damaged the list. You can get the list
> >>>> here: http://tron.homeunix.org/usb2.unread.log
> >>>
> >>> I think some of these errors depend if you have USB debugging compiled
> >>> or not. At least GCC does not warn?
> >>
> >> No, it does not depend on USB debugging.
> >> GCC has no warning at all for variables which are only assigned to.
> >> It only can warn about variables, which are only initialised.
> >>
> >> {
> >>    int x = 23; // GCC warns here ...
> >>    int y;      // ... but not here - cparser does
> >>    y = 42;
> >>    y++;
> >> }
> >>
> >> cparser has an analysis, which can warn about "y", too.
> >>
> >> I manually verified all 40 warnings and I cannot find any users (i.e.
> >> readers) for these variables.
> >
> > What is the correct way to discard the return argument of a function?
> > That's basically what most of the warnings are about.
> >
> > 1) (void)my_fn() cast
> > 2) if (my_fn()) { }
> > 3) err = my_fn();
> > 4) my_fn();
>
> Just to understand this correctly: You want to discard error codes?
>
>
> Basically I see four categories:
>
> 1) Getting the softc and not using it.
> This can be removed completely.
> Example:
>    sc = ATMEGA_BUS2SC(xfer->xroot->bus);
>
> 2) calling mtx_owned() and discarding the return value.
> Can be removed, too, after checking that the value is really unnecessary.
> Example:
>    use_polling = mtx_owned(xfer->xroot->xfer_mtx) ? 1 : 0;
>
> 3) Getting some value and not using it.
> Can be removed, too, after checking that the value is really unnecessary.
> Example:
>    ep_no = (xfer->endpoint & UE_ADDR);
>
> 4) The rest are return values of functions, which contain error codes.
> Discarding them is questionable at best.
> Example: (err is not read)
>      if (udev->flags.suspended) {
>        err = DEVICE_SUSPEND(iface->subdev);
>        device_printf(iface->subdev, "Suspend failed\n");
>      }
>      return (0);   /* success */

Hi,

Can you wait some days and re-run the analysis on -current, because there is a 
bulk of patches going in to some of the code you have analysed, so the line 
numbers are likely to not match. Then we fix those warnings!

--HPS
From julian at elischer.com  Mon Feb  9 07:15:43 2009
From: julian at elischer.com (Julian Elischer)
Date: Mon Feb  9 08:18:49 2009
Subject: performance testing of VIMAGE changes.
Message-ID: <49904626.60901@elischer.com>

I have been doing netowrk performace testing with and without
(comparing) the VIMAGE_GLOBALS option.

SO far I have seen no real significant changes in throughput
or latency, (judged by ministat).
I, however, am only one person and I would love to see if anyone
could confirm this.

just compile two (otherwise) identical kernels, but one with
options VIMAGE_GLOBALS. and perform teh same tests on each and put the 
results in ministat.

any network test you can imagine is fine..



thanks


Julian (off to DisneyLand for a few days with the kids).

From jhb at freebsd.org  Mon Feb  9 09:56:31 2009
From: jhb at freebsd.org (John Baldwin)
Date: Mon Feb  9 09:56:49 2009
Subject: sysctl question
In-Reply-To: <20090128193318.GA42071@freebsd.org>
References: <20090128193318.GA42071@freebsd.org>
Message-ID: <200902091130.08006.jhb@freebsd.org>

On Wednesday 28 January 2009 2:33:18 pm Roman Divacky wrote:
> hi
> 
> we dont need Giant to be held for sysctl_ctx_init/SYSCTL_ADD_*, right?
> 
> if that's true, is this ok for commit?

You should be able to commit this now.

> Index: cam/scsi/scsi_da.c
> ===================================================================
> --- cam/scsi/scsi_da.c	(revision 187838)
> +++ cam/scsi/scsi_da.c	(working copy)
> @@ -1086,7 +1086,6 @@
>  	snprintf(tmpstr, sizeof(tmpstr), "CAM DA unit %d", periph->unit_number);
>  	snprintf(tmpstr2, sizeof(tmpstr2), "%d", periph->unit_number);
>  
> -	mtx_lock(&Giant);
>  	sysctl_ctx_init(&softc->sysctl_ctx);
>  	softc->flags |= DA_FLAG_SCTX_INIT;
>  	softc->sysctl_tree = SYSCTL_ADD_NODE(&softc->sysctl_ctx,
> @@ -1094,7 +1093,6 @@
>  		CTLFLAG_RD, 0, tmpstr);
>  	if (softc->sysctl_tree == NULL) {
>  		printf("dasysctlinit: unable to allocate sysctl tree\n");
> -		mtx_unlock(&Giant);
>  		cam_periph_release(periph);
>  		return;
>  	}
> @@ -1108,7 +1106,6 @@
>  		&softc->minimum_cmd_size, 0, dacmdsizesysctl, "I",
>  		"Minimum CDB size");
>  
> -	mtx_unlock(&Giant);
>  	cam_periph_release(periph);
>  }
>  
> Index: cam/scsi/scsi_cd.c
> ===================================================================
> --- cam/scsi/scsi_cd.c	(revision 187838)
> +++ cam/scsi/scsi_cd.c	(working copy)
> @@ -555,8 +555,6 @@
>  	snprintf(tmpstr, sizeof(tmpstr), "CAM CD unit %d", periph->unit_number);
>  	snprintf(tmpstr2, sizeof(tmpstr2), "%d", periph->unit_number);
>  
> -	mtx_lock(&Giant);
> -
>  	sysctl_ctx_init(&softc->sysctl_ctx);
>  	softc->flags |= CD_FLAG_SCTX_INIT;
>  	softc->sysctl_tree = SYSCTL_ADD_NODE(&softc->sysctl_ctx,
> @@ -565,7 +563,6 @@
>  
>  	if (softc->sysctl_tree == NULL) {
>  		printf("cdsysctlinit: unable to allocate sysctl tree\n");
> -		mtx_unlock(&Giant);
>  		cam_periph_release(periph);
>  		return;
>  	}
> @@ -579,7 +576,6 @@
>  		&softc->minimum_command_size, 0, cdcmdsizesysctl, "I",
>  		"Minimum CDB size");
>  
> -	mtx_unlock(&Giant);
>  	cam_periph_release(periph);
>  }
>  
> 
> thnx!
> 
>    roman
> 



-- 
John Baldwin
From jhb at freebsd.org  Mon Feb  9 09:56:36 2009
From: jhb at freebsd.org (John Baldwin)
Date: Mon Feb  9 09:56:50 2009
Subject: lpt stopped working
In-Reply-To: <200902061231.46516.beech@freebsd.org>
References: <200902021643.39862.c47g@gmx.at>
	<200902052203.37792.beech@freebsd.org>
	<200902061231.46516.beech@freebsd.org>
Message-ID: <200902091133.48838.jhb@freebsd.org>

On Friday 06 February 2009 4:31:46 pm Beech Rintoul wrote:
> On Thursday 05 February 2009 22:03:37 Beech Rintoul wrote:
> > On Wednesday 04 February 2009 05:14:10 John Baldwin wrote:
> > > On Monday 02 February 2009 10:43:39 am Christian Gusenbauer wrote:
> > > > Hi!
> > > >
> > > > Since the recent update (svn r187576) to the ppbus/ppc code my printer
> > >
> > > stopped
> > >
> > > > working. Every request seems to hang forever in ppb_request_bus waiting
> > > > for ppb->ppc_lock (at least 'top' tells me that it's hanging in state
> > > > 'ppbreq').
> > >
> > > Can you use procstat to get a stack trace of the hung thread?
> >
> > My printer is still showing "device busy" for lpt0 does anyone know offhand
> > when the changes were committed? I need to revert.
> 
> There is regression somewhere in the ppbus code committed two weeks ago. I 
> reverted back to previous code and lpt0 no longer reports "device busy" and 
> printing is working again.

Please help to debug this so we can have working lpt0 in 8.0.  No one tested
the patches months ago when I first posted them, and if folks do not test them
now I will simply remove the driver before 8.0 ships.  I no longer have any
hardware such that I can test this directly, so I am depending on folks to
test things I have asked for and report back.  I believe the last thing I
asked for was for someone to do this when they lpt was hung:

Ok, can you run kgdb against your running kernel (Just run 'kgdb' without any
arguments) and do the following:

(kgdb) p *(struct ppb_data *)ppbus_devclass->devices[0]->softc

Assuming the ppb_owner is not 0, can you then do this:

(kgdb) p *(device_t)((struct ppb_data *)ppbus_devclass->devices[0]->softc)->ppb_owner


-- 
John Baldwin
From jhb at freebsd.org  Mon Feb  9 09:56:42 2009
From: jhb at freebsd.org (John Baldwin)
Date: Mon Feb  9 09:56:55 2009
Subject: "Fatal trap" when unloading usb2_controller_ehci
In-Reply-To: <200902081026.22618.hselasky@c2i.net>
References: <20090208001656.48a1a14d@gluon>
	<200902081026.22618.hselasky@c2i.net>
Message-ID: <200902091144.03748.jhb@freebsd.org>

On Sunday 08 February 2009 4:26:20 am Hans Petter Selasky wrote:
> Hi,
> 
> I don't think this is a USB problem. I rather think it has something to do  
> with the IRQ handler. On my box the EHCI IRQ is shared with the IRQ of the 
> graphics adapter, and when I unload the EHCI driver under X11 a couple of 
> times X11 freezes. This does not happen on the console.

Perhaps try reverting Jeff's per-CPU IDT changes to see if it is related to 
that?  It seems that the IDT handler was torn down, but that an APIC IRQ 
wasn't masked or some such.

> --HPS
> 
> On Sunday 08 February 2009, Bruce Cran wrote:
> > Unloading usb2_controller_ehci is crashing FreeBSD on -CURRENT
> > from a few days ago, resulting in a "Fatal trap" that isn't immediately
> > fatal but ends up knocking out the rest of the system.
> >
> > Shortly after issuing a kldunload, the kernel drops into DDB with:
> >
> > Fatal trap 30: reserved (unknown) fault while in kernel mode
> > cpuid = 0; apic id = 00
> > instruction pointer = 0x8 : 0xffffffff804bc646
> > stack pointer       = 0x10: 0xfffffffe40023b70
> > frame pointer       = 0x10: 0xfffffffe40023b80
> > code segment        = base 0x0, limit 0xfffff, type 0x1b
> > processor eflags    = interrupt enabled, IOPL = 0
> > current process     = 11 (idle : cpu0)
> > [thread pid 11 tid 100004]
> > Stopped at acpi_cpu_c1+0x6 : leave
> >
> > A backtrace just shows that the idle task was running at the time of
> > the trap.  Attempting to continue results in a load of "calcru: runtime
> > went backwards" messages followed by the ATA driver dying with:
> >
> > WARNING - SETFEATURES SET TRANSFER MODE taskqueue timeout - completing
> > request directly
> >
> > Then follows similar messages about SET_MULTI, ENABLE RCACHE,
> > ENABLE_WCACHE and WRITE_DMA48 etc.
> 
> 
> _______________________________________________
> 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"
> 



-- 
John Baldwin
From keramida at ceid.upatras.gr  Mon Feb  9 10:18:07 2009
From: keramida at ceid.upatras.gr (Giorgos Keramidas)
Date: Mon Feb  9 10:18:22 2009
Subject: HEADSUP usb2/usb4bsd to become default in GENERIC
In-Reply-To: <200902091534.12506.hselasky@c2i.net> (Hans Petter Selasky's
	message of "Mon, 9 Feb 2009 15:34:11 +0100")
References: <20090206045349.GQ78804@elvis.mu.org>
	<200902091450.07014.hselasky@c2i.net> <499038DE.3050501@gmx.de>
	<200902091534.12506.hselasky@c2i.net>
Message-ID: <87ocxbpj8t.fsf@kobe.laptop>

On Mon, 9 Feb 2009 15:34:11 +0100, Hans Petter Selasky <hselasky@c2i.net> wrote:
> On Monday 09 February 2009, Christoph Mallon wrote:
>> Hans Petter Selasky schrieb:
>> > On Monday 09 February 2009, Christoph Mallon wrote:
>> >> Christoph Mallon schrieb:
>> >>> are named "err" or "error". This should be investigated, so here's the
>> >>> complete list:
>> >>
>> >> Sorry, my MUA seems to have damaged the list. You can get the list here:
>> >> http://tron.homeunix.org/usb2.unread.log
>> >
>> > I think some of these errors depend if you have USB debugging compiled or
>> > not. At least GCC does not warn?
>>
>> No, it does not depend on USB debugging.
>> GCC has no warning at all for variables which are only assigned to.
>> It only can warn about variables, which are only initialised.
>>
>> {
>>    int x = 23; // GCC warns here ...
>>    int y;      // ... but not here - cparser does
>>    y = 42;
>>    y++;
>> }
>>
>> cparser has an analysis, which can warn about "y", too.
>>
>> I manually verified all 40 warnings and I cannot find any users (i.e.
>> readers) for these variables.
>
> What is the correct way to discard the return argument of a function?
> That's basically what most of the warnings are about.
>
> 1) (void)my_fn() cast
> 2) if (my_fn()) { }
> 3) err = my_fn();
> 4) my_fn();

If you *really* don't care about the returned error code:

        (void)function(arg1, arg2, ...);

From amdmi3 at amdmi3.ru  Mon Feb  9 10:18:46 2009
From: amdmi3 at amdmi3.ru (Dmitry Marakasov)
Date: Mon Feb  9 10:18:53 2009
Subject: UFS Witness LoR + 5 other LoRs
In-Reply-To: <20090208182940.43d6c929@zelda.local>
References: <1233007263.9302.2.camel@localhost.localdomain>
	<20090129233220.1ed64e6d@zelda.local>
	<498EB79F.4010905@FreeBSD.org>
	<20090208130506.267a838d@zelda.local>
	<20090208182940.43d6c929@zelda.local>
Message-ID: <20090209181829.GK17600@hades.panopticon>

* Martin (nakal@web.de) wrote:

> And 5 minutes later I tried to access my amd-mounted share:
> 
> Feb  8 18:11:09 zelda amd[1063]: ignoring request from 127.0.0.1:21215,
> port not reserved Feb  8 18:11:10 zelda last message repeated 7 times
> Feb  8 18:11:11 zelda amd[1063]: ignoring request from 127.0.0.1:32008,
> port not reserved
> 
> amd is suddenly flooding my syslog with these messages.
> 
> On 7.1R NFS client I did not have this effect at all. This is new on
> 8-CURRENT.
> 
> I hope this helps.

Oh, I wanted to report the same thing, after some more investigation.

The cause is most likely amd solely, as switching to static mounts
solved the problem in my case:

 9:13PM  up 7 days, 18:05, 8 users, load averages: 0,91 0,44 0,17

ports, distfiles, video, music and bunch of other stuff mounted via NFS.

With amd enabled, however, I've experienced the same behaviour with
`port not reserved' messages, hanging mount, then hanging the whole
system.

FreeBSD hades.panopticon 8.0-CURRENT FreeBSD 8.0-CURRENT #0: Sat Jan 24 06:27:03 UTC 2009     amdmi3@chrysalis.panopticon:/mnt/usr/obj/mnt/usr/src/sys/HADES  i386

I have WITNESS disabled, so I can't provide any info on whether
these LoR's appear and how they correlate with hangs. But I can
enable it and test if needed.

-- 
Dmitry Marakasov   .   55B5 0596 FF1E 8D84 5F56  9510 D35A 80DD F9D2 F77D
amdmi3@amdmi3.ru  ..:  jabber: amdmi3@jabber.ru    http://www.amdmi3.ru
From onemda at gmail.com  Mon Feb  9 10:40:21 2009
From: onemda at gmail.com (Paul B. Mahol)
Date: Mon Feb  9 10:40:28 2009
Subject: "Fatal trap" when unloading usb2_controller_ehci
In-Reply-To: <200902091144.03748.jhb@freebsd.org>
References: <20090208001656.48a1a14d@gluon>
	<200902081026.22618.hselasky@c2i.net>
	<200902091144.03748.jhb@freebsd.org>
Message-ID: <3a142e750902091040l522ab605i13d0d5a56c292a6c@mail.gmail.com>

On 2/9/09, John Baldwin <jhb@freebsd.org> wrote:
> On Sunday 08 February 2009 4:26:20 am Hans Petter Selasky wrote:
>> Hi,
>>
>> I don't think this is a USB problem. I rather think it has something to do
>>
>> with the IRQ handler. On my box the EHCI IRQ is shared with the IRQ of the
>>
>> graphics adapter, and when I unload the EHCI driver under X11 a couple of
>> times X11 freezes. This does not happen on the console.
>
> Perhaps try reverting Jeff's per-CPU IDT changes to see if it is related to
> that?  It seems that the IDT handler was torn down, but that an APIC IRQ
> wasn't masked or some such.

I'm reporting similar problem with drm+X11+intel when zaping Xorg on
SMP enabled kernel (core2 CPU)

Panic happens in something like acpi_ec handler.

I share John's opinion about *recent* per CPU IDT changes being source
of problem.

>> --HPS
>>
>> On Sunday 08 February 2009, Bruce Cran wrote:
>> > Unloading usb2_controller_ehci is crashing FreeBSD on -CURRENT
>> > from a few days ago, resulting in a "Fatal trap" that isn't immediately
>> > fatal but ends up knocking out the rest of the system.
>> >
>> > Shortly after issuing a kldunload, the kernel drops into DDB with:
>> >
>> > Fatal trap 30: reserved (unknown) fault while in kernel mode
>> > cpuid = 0; apic id = 00
>> > instruction pointer = 0x8 : 0xffffffff804bc646
>> > stack pointer       = 0x10: 0xfffffffe40023b70
>> > frame pointer       = 0x10: 0xfffffffe40023b80
>> > code segment        = base 0x0, limit 0xfffff, type 0x1b
>> > processor eflags    = interrupt enabled, IOPL = 0
>> > current process     = 11 (idle : cpu0)
>> > [thread pid 11 tid 100004]
>> > Stopped at acpi_cpu_c1+0x6 : leave
>> >
>> > A backtrace just shows that the idle task was running at the time of
>> > the trap.  Attempting to continue results in a load of "calcru: runtime
>> > went backwards" messages followed by the ATA driver dying with:
>> >
>> > WARNING - SETFEATURES SET TRANSFER MODE taskqueue timeout - completing
>> > request directly
>> >
>> > Then follows similar messages about SET_MULTI, ENABLE RCACHE,
>> > ENABLE_WCACHE and WRITE_DMA48 etc.
>>
>>
>> _______________________________________________
>> 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"
>>
>
>
>
> --
> John Baldwin
> _______________________________________________
> freebsd-current@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"
>


-- 
Paul
From c47g at gmx.at  Mon Feb  9 10:58:26 2009
From: c47g at gmx.at (Christian Gusenbauer)
Date: Mon Feb  9 10:58:36 2009
Subject: lpt stopped working
In-Reply-To: <200902091133.48838.jhb@freebsd.org>
References: <200902021643.39862.c47g@gmx.at>
	<200902061231.46516.beech@freebsd.org>
	<200902091133.48838.jhb@freebsd.org>
Message-ID: <200902091958.39480.c47g@gmx.at>

On Monday 09 February 2009, John Baldwin wrote:
> On Friday 06 February 2009 4:31:46 pm Beech Rintoul wrote:
> > On Thursday 05 February 2009 22:03:37 Beech Rintoul wrote:
> > > On Wednesday 04 February 2009 05:14:10 John Baldwin wrote:
> > > > On Monday 02 February 2009 10:43:39 am Christian Gusenbauer wrote:
> > > > > Hi!
> > > > >
> > > > > Since the recent update (svn r187576) to the ppbus/ppc code my
> > > > > printer
> > > >
> > > > stopped
> > > >
> > > > > working. Every request seems to hang forever in ppb_request_bus
> > > > > waiting for ppb->ppc_lock (at least 'top' tells me that it's
> > > > > hanging in state 'ppbreq').
> > > >
> > > > Can you use procstat to get a stack trace of the hung thread?
> > >
> > > My printer is still showing "device busy" for lpt0 does anyone know
> > > offhand when the changes were committed? I need to revert.
> >
> > There is regression somewhere in the ppbus code committed two weeks ago.
> > I reverted back to previous code and lpt0 no longer reports "device busy"
> > and printing is working again.
>
> Please help to debug this so we can have working lpt0 in 8.0.  No one
> tested the patches months ago when I first posted them, and if folks do not
> test them now I will simply remove the driver before 8.0 ships.  I no

Mea culpa, too. As you sent your patches, I thought someone else will do the 
tests surely ... :-(.

> longer have any hardware such that I can test this directly, so I am
> depending on folks to test things I have asked for and report back.  I
> believe the last thing I asked for was for someone to do this when they lpt
> was hung:
>
> Ok, can you run kgdb against your running kernel (Just run 'kgdb' without
> any arguments) and do the following:
>
> (kgdb) p *(struct ppb_data *)ppbus_devclass->devices[0]->softc
>
> Assuming the ppb_owner is not 0, can you then do this:
>
> (kgdb) p *(device_t)((struct ppb_data
> *)ppbus_devclass->devices[0]->softc)->ppb_owner

This is the output (unfortunately ppb_owner IS 0):

(kgdb) p *(struct ppb_data *)ppbus_devclass->devices[0]->softc
$1 = {class_id = 10, state = 1, error = 0, mode = 0, ppb_owner = 0x0,
  ppc_lock = 0xc56bfe7c, ppc_irq_res = 0xc573d5c0}

Christian.

From yanefbsd at gmail.com  Mon Feb  9 11:19:02 2009
From: yanefbsd at gmail.com (Garrett Cooper)
Date: Mon Feb  9 11:19:10 2009
Subject: WITHOUT_INET6 broken on CURRENT
In-Reply-To: <E9290005-0B87-4CD4-81B9-5C764AF56211@lakerest.net>
References: <7d6fde3d0902081659i7cb86al921ea109d17e1a3c@mail.gmail.com>
	<E9290005-0B87-4CD4-81B9-5C764AF56211@lakerest.net>
Message-ID: <7d6fde3d0902091119i4cb35db2ua61e7b5420b3518@mail.gmail.com>

On Mon, Feb 9, 2009 at 3:20 AM, Randall Stewart <rrs@lakerest.net> wrote:
> Garrett:
>
> Pointy hat to me :-)
>
> I will be committing a fix within the next few minutes (also adding the
> no-v6 option to
> my build list :-D)
>
> Thanks
>
> R
> On Feb 8, 2009, at 7:59 PM, Garrett Cooper wrote:
>
>> Hi Randall,
>>   I recently rebuilt my sources today and I noticed that it's now
>> breaking on a valid warning with sctp:
>>
>> cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -march=nocona
>> -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/usr/src/sys -I/usr/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  -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
>> /usr/src/sys/netinet/sctputil.c
>> cc1: warnings being treated as errors
>> In file included from /usr/src/sys/netinet/sctputil.c:6553:
>> /usr/src/sys/netinet6/sctp6_var.h:57: warning: 'struct icmp6_hdr'
>> declared inside parameter list
>> /usr/src/sys/netinet6/sctp6_var.h:57: warning: its scope is only this
>> definition or declaration, which is probably not what you want
>> *** Error code 1
>>
>> Stop in /usr/obj/usr/src/sys/OPTIMUS.
>> *** Error code 1
>>
>> Stop in /usr/src.
>> *** Error code 1
>>
>> Stop in /usr/src.
>>
>>   I'm going to rebuild setting WITHOUT_SCTP for now, but this needs
>> to be fixed.
>> Thanks,
>> -Garrett

Thanks a million Randall ;).
-Garrett
From yanefbsd at gmail.com  Mon Feb  9 11:24:24 2009
From: yanefbsd at gmail.com (Garrett Cooper)
Date: Mon Feb  9 11:24:32 2009
Subject: libteken related compiling error
In-Reply-To: <20090209062948.GK1230@hoeg.nl>
References: <7d6fde3d0902081719u476fa3bbp26cf37ba085a78b@mail.gmail.com>
	<20090209062948.GK1230@hoeg.nl>
Message-ID: <7d6fde3d0902091124m6ed63a26n2634f530437a6aba@mail.gmail.com>

On Sun, Feb 8, 2009 at 10:29 PM, Ed Schouten <ed@80386.nl> wrote:
> Hi Garrett,
>
> * Garrett Cooper <yanefbsd@gmail.com> wrote:
>> In file included from /usr/src/sys/dev/syscons/teken/teken.c:411:
>> /usr/src/sys/dev/syscons/teken/teken_state.h: In function 'teken_state_6':
>> /usr/src/sys/dev/syscons/teken/teken_state.h:188: warning: implicit
>> declaration of function 'teken_subr_scs'
>> /usr/src/sys/dev/syscons/teken/teken_state.h:188: warning: nested
>> extern declaration of 'teken_subr_scs'
>
> This file should not exist. Can you run `make clean' in
> /sys/dev/syscons/teken? Let me know if it fixes your problem. Thanks!

    Ok, that built properly that time, but it's kind of weird because
I ran make clean cleandir beforehand... hrmmmm...
Thanks :),
-Garrett
From jhb at freebsd.org  Mon Feb  9 11:59:18 2009
From: jhb at freebsd.org (John Baldwin)
Date: Mon Feb  9 11:59:25 2009
Subject: lpt stopped working
In-Reply-To: <200902091958.39480.c47g@gmx.at>
References: <200902021643.39862.c47g@gmx.at>
	<200902091133.48838.jhb@freebsd.org>
	<200902091958.39480.c47g@gmx.at>
Message-ID: <200902091458.41637.jhb@freebsd.org>

On Monday 09 February 2009 1:58:39 pm Christian Gusenbauer wrote:
> On Monday 09 February 2009, John Baldwin wrote:
> > On Friday 06 February 2009 4:31:46 pm Beech Rintoul wrote:
> > > On Thursday 05 February 2009 22:03:37 Beech Rintoul wrote:
> > > > On Wednesday 04 February 2009 05:14:10 John Baldwin wrote:
> > > > > On Monday 02 February 2009 10:43:39 am Christian Gusenbauer wrote:
> > > > > > Hi!
> > > > > >
> > > > > > Since the recent update (svn r187576) to the ppbus/ppc code my
> > > > > > printer
> > > > >
> > > > > stopped
> > > > >
> > > > > > working. Every request seems to hang forever in ppb_request_bus
> > > > > > waiting for ppb->ppc_lock (at least 'top' tells me that it's
> > > > > > hanging in state 'ppbreq').
> > > > >
> > > > > Can you use procstat to get a stack trace of the hung thread?
> > > >
> > > > My printer is still showing "device busy" for lpt0 does anyone know
> > > > offhand when the changes were committed? I need to revert.
> > >
> > > There is regression somewhere in the ppbus code committed two weeks ago.
> > > I reverted back to previous code and lpt0 no longer reports "device 
busy"
> > > and printing is working again.
> >
> > Please help to debug this so we can have working lpt0 in 8.0.  No one
> > tested the patches months ago when I first posted them, and if folks do 
not
> > test them now I will simply remove the driver before 8.0 ships.  I no
> 
> Mea culpa, too. As you sent your patches, I thought someone else will do the 
> tests surely ... :-(.
> 
> > longer have any hardware such that I can test this directly, so I am
> > depending on folks to test things I have asked for and report back.  I
> > believe the last thing I asked for was for someone to do this when they 
lpt
> > was hung:
> >
> > Ok, can you run kgdb against your running kernel (Just run 'kgdb' without
> > any arguments) and do the following:
> >
> > (kgdb) p *(struct ppb_data *)ppbus_devclass->devices[0]->softc
> >
> > Assuming the ppb_owner is not 0, can you then do this:
> >
> > (kgdb) p *(device_t)((struct ppb_data
> > *)ppbus_devclass->devices[0]->softc)->ppb_owner
> 
> This is the output (unfortunately ppb_owner IS 0):
> 
> (kgdb) p *(struct ppb_data *)ppbus_devclass->devices[0]->softc
> $1 = {class_id = 10, state = 1, error = 0, mode = 0, ppb_owner = 0x0,
>   ppc_lock = 0xc56bfe7c, ppc_irq_res = 0xc573d5c0}

And this is while lpd or the like is hung trying to write to /dev/lpt0?

-- 
John Baldwin
From lme at FreeBSD.org  Mon Feb  9 12:08:12 2009
From: lme at FreeBSD.org (Lars Engels)
Date: Mon Feb  9 12:08:18 2009
Subject: CFT: Graphics support for /boot/loader
In-Reply-To: <200902081335.n18DZ2h4018582@lurza.secnetix.de>
References: <20090208135053.12691emq58yl9m4k@webmail.leidinger.net>
	<200902081335.n18DZ2h4018582@lurza.secnetix.de>
Message-ID: <20090209200809.GK30761@e.0x20.net>

On Sun, Feb 08, 2009 at 02:35:02PM +0100, Oliver Fromme wrote:
> 
> Alexander Leidinger wrote:
>  > Oliver Fromme wrote:
>  > > You can easily replace the background image, it's a
>  > > standard PCX image file.  You can even re-arrange the
>  > > position of the menu if necessary; there are simple
>  > > variable settings for that in the theme.conf file.
>  > 
>  > What about the actual menu items, are they configurable too (e.g. when  
>  > I want single-user as F1... ACPI should work now on most systems and I  
>  > don't see why disabling it should be in the first position), or does  
>  > it use the same stuff as the text menu for this (to fiddling with  
>  > forth would be necessary)?
> 
> The actual menu contents are in the beastie.4th file, just
> like for the old text menu.  So, yes, you'd need to speak
> FORTH in order to change that.
> 
> How many of the FreeBSD developers are actually fluent in
> FORTH?  How many committers are able to review the .4th
> code that I wrote?
> 
> Would there be strong resistance if I tried to replace FICL
> with something else that is not as brain-knotting as FORTH?
> Just to name an example, I once wrote a bourne-shell-like
> parser that would not be difficult to embed.  I assume that
> would enable many more developers and users to play with
> the boot menu stuff.

Great idea. That Forth code is really an obstacle for playing with the
boot menu...
-------------- 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/20090209/35530a35/attachment.pgp
From alfred at freebsd.org  Mon Feb  9 12:19:15 2009
From: alfred at freebsd.org (Alfred Perlstein)
Date: Mon Feb  9 12:19:27 2009
Subject: HEADSUP usb2/usb4bsd to become default in GENERIC
In-Reply-To: <20090208.124756.-942592244.imp@bsdimp.com>
References: <8b3974a5f1b260fd438518f703aee2f5.squirrel@galain.elvandar.org>
	<20090208183820.GA21343@citylink.fud.org.nz>
	<200902081951.16823.hselasky@c2i.net>
	<20090208.124756.-942592244.imp@bsdimp.com>
Message-ID: <20090209201914.GM68801@elvis.mu.org>

* M. Warner Losh <imp@bsdimp.com> [090208 11:48] wrote:
> In message: <200902081951.16823.hselasky@c2i.net>
>             Hans Petter Selasky <hselasky@c2i.net> writes:
> : On Sunday 08 February 2009, Andrew Thompson wrote:
> : > On Sun, Feb 08, 2009 at 06:48:39PM +0100, Remko Lodder wrote:
> : > > On Sun, February 8, 2009 6:21 am, Alfred Perlstein wrote:
> : 
> : > >
> : > > Please name it "usb_*".
> : 
> : Beware that if you rename everything from "usb2_" to "usb_" there will be 
> : symbol and structure clashes with the linux USB compat layer, which needs to 
> : be resolved.
> 
> No.  that's not the case.  usb2_foo vs usb_foo in the kernel config
> files only affects what files config brings in, and we can easily tell
> it to bring the right ones in w/o any symbol issues.
> 
> I'd leave everything else where it is now in the source tree.  The
> rename is fairly trivial.  Do people want me to float a patch?

That would be useful, but it might be premature as there might
be changes that conflict shortly (not trying to hide information,
just don't know what changes might happen).

If you can schedule to do this at the time for the rename (when the
remove happens) that would be best.

-Alfred
From alfred at freebsd.org  Mon Feb  9 12:21:13 2009
From: alfred at freebsd.org (Alfred Perlstein)
Date: Mon Feb  9 12:21:27 2009
Subject: HEADSUP usb2/usb4bsd to become default in GENERIC
In-Reply-To: <1234119008.7997.32.camel@buffy.york.ac.uk>
References: <20090206045349.GQ78804@elvis.mu.org>
	<498C013B.4000405@FreeBSD.org>
	<20090208052110.GY78804@elvis.mu.org>
	<1234119008.7997.32.camel@buffy.york.ac.uk>
Message-ID: <20090209202112.GN68801@elvis.mu.org>

* Gavin Atkinson <gavin@FreeBSD.org> [090208 10:50] wrote:
> On Sat, 2009-02-07 at 21:21 -0800, Alfred Perlstein wrote:
> > * Maxim Sobolev <sobomax@FreeBSD.org> [090206 01:50] wrote:
> > > Alfred Perlstein wrote:
> > > >      - Update GENERIC to use usb2 device names.
> > > 
> > > Wasn't there a plan to rename usb2 devices to match oldusb names (where 
> > > applicable) once oldusb had been killed? I don't see it in the list.
> > 
> > Probably, although coming from the other side as a user I find it pretty
> > annoying when there's somewhat gratuitous changes to the kernel config
> > files that I don't really care about that cause my kernels to break.
> 
> The vast majority of our users do not run -CURRENT, and so haven't had
> to change config files yet.
> 
> One day, those users will be migrating from 7.x to 8.x, and shouldn't
> need to change their kernel config for a "somewhat gratuitous change".
> 
> Your argument only works if people had already had to change their
> config files once (usb -> usb2), and that by renaming these back they
> will have to change their kernel config back.  Only people running
> -CURRENT will end up having to do this twice (or indeed at all) if the
> rename takes place, end users will not need to do it at all.
> 
> > Basically, calling it usb2 isn't as bad as renaming it back to "usb"
> > as it's less disruptive in my book.
> 
> Again, I disagree.

Your point is very good!  I hadn't thought about 7 users
coming to 8 and having the rename actually be a nice thing for
them.  I was a bit more concerned with backlash from developers
for churn, but your point makes a lot of sense.


thanks,
-- 
- Alfred Perlstein
From swell.k at gmail.com  Mon Feb  9 12:25:41 2009
From: swell.k at gmail.com (Anonymous)
Date: Mon Feb  9 12:25:48 2009
Subject: Bad unicode `-' in manpages
In-Reply-To: <20090209134806.GF17600@hades.panopticon> (Dmitry Marakasov's
	message of "Mon, 9 Feb 2009 16:48:06 +0300")
References: <20090206183344.GE17600@hades.panopticon>
	<867i43742t.fsf@gmail.com> <20090209134806.GF17600@hades.panopticon>
Message-ID: <86fxin9x37.fsf@gmail.com>

Dmitry Marakasov <amdmi3@amdmi3.ru> writes:

>> year ago. And I think it can cause trouble when trying to view localized
>> man page written in unicode when you can't escape to either `C' locale
>> or `-o' option.
>
> Agreed. But actually you shouldn't need to specify extra arguments to
> man or change locale to view /correct/ man page, so I think it should be
> fixed.

Go ahead and file a PR.
-------------- next part --------------
Index: contrib/groff/font/devutf8/R.proto
===================================================================
--- contrib/groff/font/devutf8/R.proto	(revision 188399)
+++ contrib/groff/font/devutf8/R.proto	(working copy)
@@ -726,7 +726,7 @@
 product	24	0	0x220F
 coproduct	24	0	0x2210
 sum	24	0	0x2211
-\-	24	0	0x2212
+\-	24	0	0x002d
 mi	"
 -+	24	0	0x2213
 **	24	0	0x2217
From nakal at web.de  Mon Feb  9 12:45:40 2009
From: nakal at web.de (Martin)
Date: Mon Feb  9 12:45:46 2009
Subject: UFS Witness LoR + 5 other LoRs
In-Reply-To: <20090208182023.GF85840@dan.emsphone.com>
References: <1233007263.9302.2.camel@localhost.localdomain>
	<20090129233220.1ed64e6d@zelda.local>
	<498EB79F.4010905@FreeBSD.org>
	<20090208130506.267a838d@zelda.local>
	<20090208182023.GF85840@dan.emsphone.com>
Message-ID: <20090209214523.519ee4d6@zelda.local>

Am Sun, 8 Feb 2009 12:20:23 -0600
schrieb Dan Nelson <dnelson@allantgroup.com>:

> In the last episode (Feb 08), Martin said:
> > Btw... it would be very nice if someone finally implements timeouts
> > and a detection strategy for NFS packets that don't arrive at their
> > destination because of fragmentation and wrong rsize/wsize
> > settings.  But this is a totally different topic.  There is not
> > much in the docs about it.
> 
> The solution to that problem is TCP mounts :)

Hi Dan.

Yes. This could be right, of course. I haven't tried it yet, but I will.

There are two points, I want to add:

1) Some people say that UDP mounts have faster transfer rates. I don't
know yet, if it's true.

2) I mention the problem with NFS over UDP, because UDP mounts are
somehow "fishy", it seems. A robust piece of software should recover
from erroneous situations and not get stuck somewhere. The only
solution to this situation is an unclean reboot. This is not "nice".

--
Martin

From dougb at FreeBSD.org  Mon Feb  9 13:59:38 2009
From: dougb at FreeBSD.org (Doug Barton)
Date: Mon Feb  9 13:59:44 2009
Subject: UFS Witness LoR + 5 other LoRs
In-Reply-To: <498EB79F.4010905@FreeBSD.org>
References: <1233007263.9302.2.camel@localhost.localdomain>	<20090129233220.1ed64e6d@zelda.local>
	<498EB79F.4010905@FreeBSD.org>
Message-ID: <4990A73D.6060108@FreeBSD.org>

Kris Kennaway wrote:
> Several of these are widely reported, and harmless 

Given that we're coming closer and closer to the time when 8.x will be
in pre-release slush, shouldn't at least some of these get fixed
soonish? If for no other reason than to make it easier to detect real
problems when they arise.

Doug

-- 

    This .signature sanitized for your protection
From kostikbel at gmail.com  Mon Feb  9 14:19:39 2009
From: kostikbel at gmail.com (Kostik Belousov)
Date: Mon Feb  9 14:19:45 2009
Subject: UFS Witness LoR + 5 other LoRs
In-Reply-To: <4990A73D.6060108@FreeBSD.org>
References: <1233007263.9302.2.camel@localhost.localdomain>
	<20090129233220.1ed64e6d@zelda.local>
	<498EB79F.4010905@FreeBSD.org> <4990A73D.6060108@FreeBSD.org>
Message-ID: <20090209221930.GI9427@deviant.kiev.zoral.com.ua>

On Mon, Feb 09, 2009 at 01:59:25PM -0800, Doug Barton wrote:
> Kris Kennaway wrote:
> > Several of these are widely reported, and harmless 
> 
> Given that we're coming closer and closer to the time when 8.x will be
> in pre-release slush, shouldn't at least some of these get fixed
> soonish? If for no other reason than to make it easier to detect real
> problems when they arise.

Fix for most often reported LOR between user map and vnode lock, typically
UFS, was committed yesterday.
-------------- 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/20090209/1af0c6db/attachment.pgp
From dougb at FreeBSD.org  Mon Feb  9 14:21:52 2009
From: dougb at FreeBSD.org (Doug Barton)
Date: Mon Feb  9 14:22:02 2009
Subject: UFS Witness LoR + 5 other LoRs
In-Reply-To: <20090209221930.GI9427@deviant.kiev.zoral.com.ua>
References: <1233007263.9302.2.camel@localhost.localdomain>	<20090129233220.1ed64e6d@zelda.local>	<498EB79F.4010905@FreeBSD.org>
	<4990A73D.6060108@FreeBSD.org>
	<20090209221930.GI9427@deviant.kiev.zoral.com.ua>
Message-ID: <4990AC6D.4030508@FreeBSD.org>

Kostik Belousov wrote:
> On Mon, Feb 09, 2009 at 01:59:25PM -0800, Doug Barton wrote:
>> Kris Kennaway wrote:
>>> Several of these are widely reported, and harmless 
>> Given that we're coming closer and closer to the time when 8.x will be
>> in pre-release slush, shouldn't at least some of these get fixed
>> soonish? If for no other reason than to make it easier to detect real
>> problems when they arise.
> 
> Fix for most often reported LOR between user map and vnode lock, typically
> UFS, was committed yesterday.

Excellent! Can't wait to give this a roll.

Doug

-- 

    This .signature sanitized for your protection
From atkin901 at yahoo.com  Mon Feb  9 14:50:23 2009
From: atkin901 at yahoo.com (Mark Atkinson)
Date: Mon Feb  9 14:50:30 2009
Subject: memory alignment problems with -current on amd64?
References: <gl7hu4$q7k$1@ger.gmane.org>
Message-ID: <gmqbv1$jhe$1@ger.gmane.org>

Mark Atkinson wrote:
> With recent kernels on HAMMER/amd64 I cannot complete a buildworld.  The
> compilation keeps failing with problems like:
> 
> cc -O2 -pipe -DBFD_DEFAULT_TARGET_SIZE=64 -I.
> -I/usr/src/gnu/usr.bin/binutils/as
> -I/usr/src/gnu/usr.bin/binutils/as/../libbfd
> -I/usr/obj/usr/src/tmp/usr/src/gnu/usr.bin/binutils/as/../libbfd
> -I/usr/src/gnu/usr.bin/binutils/as/../../../../contrib/binutils/include
> -DDEFAULT_ARCH=\"x86_64\" -DTARGET_CPU=\"x86_64\"
> -DTARGET_CANONICAL=\"x86_64-obrien-freebsd\"
> -DTARGET_ALIAS=\"x86_64-obrien-freebsd\" -DVERSION=\""2.15
> [FreeBSD]
> 2004-05-23"\" -D_GNU_SOURCE
> -I/usr/src/gnu/usr.bin/binutils/as/../../../../contrib/binutils/gas
> -I/usr/src/gnu/usr.bin/binutils/as/../../../../contrib/binutils/gas/config
> -I/usr/src/gnu/usr.bin/binutils/as/../../../../contrib/binutils
> -I/usr/src/gnu/usr.bin/binutils/as
> -I/usr/src/gnu/usr.bin/binutils/as/amd64-freebsd 
> -I/usr/obj/usr/src/tmp/legacy/usr/include -c
> /usr/src/gnu/usr.bin/binutils/as/../../../../contrib/binutils/gas/subsegs.c
> /usr/src/gnu/usr.bin/binutils/as/../../../../contrib/binutils/gas/subsegs.c:
> In function 'subseg_set_rest':
> /usr/src/gnu/usr.bin/binutils/as/../../../../contrib/binutils/gas/subsegs.c:205:
> internal compiler error: Bus error: 10 Please submit a full bug report,
> with preprocessed source if appropriate. See
> <URL:http://gcc.gnu.org/bugs.html> for instructions. *** Error code 1 1
> error *** Error code 2 1 error *** Error code 2 1 error *** Error code 2
> 1 error
> *** Error code 2
> 1 error
> 
> Yet if I run the failed command it will complete successfully:
> 
> [root@dl385g5 /usr/src]#
> cc -O2 -pipe -DBFD_DEFAULT_TARGET_SIZE=64 -I.
> -I/usr/src/gnu/usr.bin/binutils/as
> -I/usr/src/gnu/usr.bin/binutils/as/../libbfd
> -I/usr/obj/usr/src/tmp/usr/src/gnu/usr.bin/binutils/as/../libbfd
> -I/usr/src/gnu/usr.bin/binutils/as/../../../../contrib/binutils/include
> -DDEFAULT_ARCH=\"x86_64\" -DTARGET_CPU=\"x86_64\"
> -DTARGET_CANONICAL=\"x86_64-obrien-freebsd\"
> -DTARGET_ALIAS=\"x86_64-obrien-freebsd\" -DVERSION=\""2.15
> [FreeBSD]
> 2004-05-23"\" -D_GNU_SOURCE
> -I/usr/src/gnu/usr.bin/binutils/as/../../../../contrib/binutils/gas
> -I/usr/src/gnu/usr.bin/binutils/as/../../../../contrib/binutils/gas/config
> -I/usr/src/gnu/usr.bin/binutils/as/../../../../contrib/binutils
> -I/usr/src/gnu/usr.bin/binutils/as
> -I/usr/src/gnu/usr.bin/binutils/as/amd64-freebsd 
> -I/usr/obj/usr/src/tmp/legacy/usr/include -c
> /usr/src/gnu/usr.bin/binutils/as/../../../../contrib/binutils/gas/subsegs.c
> [root@dl385g5 /usr/src]# echo $?
> 0
> 
> If I boot back to a kernel from sources Oct 15th 2008, I can complete a
> buildworld on this machine no problem.
> 
> * This is a HP DL385G5 with 1 quad core AMD 2100 and 10G of memory.
> * This the amd64 GENERIC kernel
> * I've tried reducing hw.physmem to 2G, but that didn't make any
> difference. * I will recieve bus errors when running buildworld w/ -j1
> * If I run buildworld with a larger number the machine will reset w/ no
> panic.
> 
> Ideas?

It turns out some errors will turn up in memtest86+ if you select 'Bios
Probe' as the sizing method.  Otherwise using the e820 method by default it
will run all day over the 10G.  The Memtest doc themselve state
that 'Probe' and 'All' may return the same sizing and are not considered
safe.  'Probe' seems to behave exactly the way -current is behaving
(returning errors, and reseting the box). 'All' happens to lock the box on
this machine.

Since I can go back to the Oct 15th kernel and do a complete buildworld, I
can only assume -current has changed since then for amd64 sizing to maybe
access something other than what the e820 method would return?

The SMAP appears the same, but you can see the difference in the Physical
memory chunk(s) below for the two kernels.   

8-current (from Feb 4th):
SMAP type=01 base=0000000000000000 len=000000000009f400
SMAP type=02 base=000000000009f400 len=0000000000000c00
SMAP type=02 base=00000000000f0000 len=0000000000010000
SMAP type=01 base=0000000000100000 len=000000000ff00000
SMAP type=01 base=0000000010000000 len=0000000010000000
SMAP type=01 base=0000000020000000 len=00000000afe4e000
SMAP type=03 base=00000000cfe4e000 len=0000000000008000
SMAP type=01 base=00000000cfe56000 len=0000000000001000
SMAP type=02 base=00000000cfe57000 len=00000000001a9000
SMAP type=02 base=00000000d0000000 len=0000000010000000
SMAP type=02 base=00000000fec00000 len=0000000000100000
SMAP type=02 base=00000000fee00000 len=0000000000010000
SMAP type=02 base=00000000ffc00000 len=0000000000400000
SMAP type=01 base=0000000100000000 len=00000001affff000

usable memory = 10720202752 (10223 MB)
Physical memory chunk(s):
0x0000000000001000 - 0x000000000009bfff, 634880 bytes (155 pages)
0x0000000000f54000 - 0x00000000cfe4dfff, 3471810560 bytes (847610 pages)
0x00000000cfe56000 - 0x00000000cfe56fff, 4096 bytes (1 pages)
0x0000000100000000 - 0x000000029d212fff, 6931165184 bytes (1692179 pages)
avail memory  = 10365558784 (9885 MB)

8-current (Oct 15th)
SMAP type=01 base=0000000000000000 len=000000000009f400
SMAP type=02 base=000000000009f400 len=0000000000000c00
SMAP type=02 base=00000000000f0000 len=0000000000010000
SMAP type=01 base=0000000000100000 len=000000000ff00000
SMAP type=01 base=0000000010000000 len=0000000010000000
SMAP type=01 base=0000000020000000 len=00000000afe4e000
SMAP type=03 base=00000000cfe4e000 len=0000000000008000
SMAP type=01 base=00000000cfe56000 len=0000000000001000
SMAP type=02 base=00000000cfe57000 len=00000000001a9000
SMAP type=02 base=00000000d0000000 len=0000000010000000
SMAP type=02 base=00000000fec00000 len=0000000000100000
SMAP type=02 base=00000000fee00000 len=0000000000010000
SMAP type=02 base=00000000ffc00000 len=0000000000400000
SMAP type=01 base=0000000100000000 len=00000001affff000

usable memory = 10720538624 (10223 MB)
Physical memory chunk(s):
0x0000000000001000 - 0x000000000009bfff, 634880 bytes (155 pages)
0x0000000000f02000 - 0x00000000cfe4dfff, 3472146432 bytes (847692 pages)
0x00000000cfe56000 - 0x00000000cfe56fff, 4096 bytes (1 pages)
0x0000000100000000 - 0x000000029d212fff, 6931165184 bytes (1692179 pages)
avail memory  = 10365890560 (9885 MB)

-- 
Mark Atkinson
atkin901@yahoo.com
(!wired)?(coffee++):(wired);

From wkoszek at freebsd.org  Mon Feb  9 14:52:02 2009
From: wkoszek at freebsd.org (Wojciech A. Koszek)
Date: Mon Feb  9 14:52:09 2009
Subject: [wkoszek@FreeBSD.org: svn commit: r188309 - head/sys/conf]
Message-ID: <20090209215909.GQ83537@FreeBSD.org>


Hi,

Just to point out, following drivers are looking for interested people,
who could actually fix and test them on real hardware:

- cy(4) (no respective sys/modules/.. directory)
- rc(4)
- rp(4)

They won't be added to NOTES till they get fixed just not to mislead
people, as all other comments have respective "device" entries.

----- Forwarded message from "Wojciech A. Koszek" <wkoszek@FreeBSD.org> -----

To: src-committers@FreeBSD.org, svn-src-all@FreeBSD.org,
	svn-src-head@FreeBSD.org
From: "Wojciech A. Koszek" <wkoszek@FreeBSD.org>
Date: Sun, 8 Feb 2009 12:33:05 +0000 (UTC)
Subject: svn commit: r188309 - head/sys/conf

Author: wkoszek
Date: Sun Feb  8 12:33:05 2009
New Revision: 188309
URL: http://svn.freebsd.org/changeset/base/188309

Log:
  Further NOTES cleanup -- following drivers didn't survive TTY-ng
  and aren't included in NOTES anyway: cy(4), rc(4), rp(4).
  
  si(4) doesn't belong to global NOTES.

Modified:
  head/sys/conf/NOTES

Modified: head/sys/conf/NOTES
==============================================================================
--- head/sys/conf/NOTES	Sun Feb  8 12:12:19 2009	(r188308)
+++ head/sys/conf/NOTES	Sun Feb  8 12:33:05 2009	(r188309)
@@ -2138,44 +2138,9 @@ device	tnt4882
 # scd: Sony CD-ROM using proprietary (non-ATAPI) interface
 # mcd: Mitsumi CD-ROM using proprietary (non-ATAPI) interface
 # bktr: Brooktree bt848/848a/849a/878/879 video capture and TV Tuner board
-# cy: Cyclades serial driver
 # joy: joystick (including IO DATA PCJOY PC Card joystick)
-# rc: RISCom/8 multiport card
-# rp: Comtrol Rocketport(ISA/PCI) - single card
-# si: Specialix SI/XIO 4-32 port terminal multiplexor
 # cmx: OmniKey CardMan 4040 pccard smartcard reader
 
<cut>

-- 
Wojciech A. Koszek
wkoszek@FreeBSD.org
http://people.freebsd.org/~wkoszek/
From bms at incunabulum.net  Mon Feb  9 21:10:24 2009
From: bms at incunabulum.net (Bruce M Simpson)
Date: Mon Feb  9 21:10:31 2009
Subject: uart(4) not working in QEMU
Message-ID: <49910C3D.90709@incunabulum.net>

Hi,

I have been trying to test my kernel code in QEMU as it saves a lot of 
time and effort.
However, I have noticed since returning to my current project, that 
sio(4) was deprecated in favour of uart(4).

Whilst I updated my kernel configs to reflect this, I've noticed a lot 
of problems with I/O and QEMU -- in particular, the kernel will log 
messages over uart(4) just fine, but when the kernel runs init, I can't 
get any I/O out of the uart(4) at all, apart from a single 'c' or 'F' 
character.

The kernel continues to log messages OK to the uart0/ttyu0 device 
regardless of what's going on in userland.

If I configure ttyv0 in the QEMU virtual machine up via /etc/ttys to run 
a getty there, I can get in, and see that the getty for ttyu0 is 
running. However, echo'ing or cat'ing data to /dev/ttyu0 won't work, 
even if I kill the getty process first. I just don't see anything 
appearing in my QEMU serial console.

I've tried a lot of combinations of 3wire.115200 vs std.9600, 
boot.config options, loader.conf options, none of which have solved the 
problem (mostly working from the threads on this list from when the 
changes were made).

I have also tried other bindings for the QEMU serial device -- e.g. tcp 
ports, nmdm(4), and always see the same effects.   I do have INVARIANTS 
enabled -- could this be an issue?

thanks,
BMS
From rdivacky at freebsd.org  Tue Feb 10 00:12:45 2009
From: rdivacky at freebsd.org (Roman Divacky)
Date: Tue Feb 10 00:12:53 2009
Subject: sysctl question
In-Reply-To: <200902091130.08006.jhb@freebsd.org>
References: <20090128193318.GA42071@freebsd.org>
	<200902091130.08006.jhb@freebsd.org>
Message-ID: <20090210080951.GA20487@freebsd.org>

On Mon, Feb 09, 2009 at 11:30:07AM -0500, John Baldwin wrote:
> On Wednesday 28 January 2009 2:33:18 pm Roman Divacky wrote:
> > hi
> > 
> > we dont need Giant to be held for sysctl_ctx_init/SYSCTL_ADD_*, right?
> > 
> > if that's true, is this ok for commit?
> 
> You should be able to commit this now.

please do it yourself.. my commit machine broke down :(
-------------- 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/20090210/a7385e08/attachment.pgp
From olli at lurza.secnetix.de  Tue Feb 10 01:08:12 2009
From: olli at lurza.secnetix.de (Oliver Fromme)
Date: Tue Feb 10 01:08:19 2009
Subject: CFT: Graphics support for /boot/loader
In-Reply-To: <20090207200630.GA50298@wep4035.physik.uni-wuerzburg.de>
Message-ID: <200902100908.n1A989IJ034744@lurza.secnetix.de>

Hi,

Sorry for the late reply.  I'm swamped with emails, and
real life takes its time, too ...

Alexey Shuvaev wrote:
 > Looks good, BTW is 640x480 in 4 bits per pixel the maximum of standard VGA?
 > Can you go higher or you are already in protected mode with (almost) no BIOS?
 > I mean, 640x480 is ok, but 4 bits per pixel... mmm... the same 16 colors as
 > in text mode... although with a palette...

For logos and simple graphics, 16 colors is actually not
that bad.  Look at the various examples (screen shots) that
you can find here:

http://www.secnetix.de/olli/FreeBSD/vloader/

With a proper palette and dithering you can make quite
nice background graphics with only 16 colors.  I made all
of those with the netbpm tools, xv and a little bit of gimp.

Also take into account that this is "only" a boot screen.
Most people will see it only for a few seconds.

Regarding your question about VGA modes:

Standard VGA supports at most 640x480 at 4 bits and 320x200
at 8 bits.  So that's the common denominator.

There are some "hacked modes" (sometimes called "mode X")
that allow somewhat higher resolutions, such as 704?528
at 4 bits or 360x256 at 8 bits.  But those don't work well
with all monitors.

And then there is VESA, of course.  I plan to add limited
VESA support, so higher resolutions are possible.  However,
there are a few issues with VESA support:

 - 1. Some VESA BIOS implementations have serious bugs,
   because nobody uses it in the Windows world.

 - 2. There is no simple and reliable way to autodetect
   which resolutions are supported by the monitor.

 - 3. There are many, many different VESA modes and display
   resolutions.  It's unfeasible that FreeBSD ships with
   appropriate graphics files for every conceivable VESA
   mode, color depth, display size and height/width ratio.

So, the default FreeBSD boot loader (as shipped on the CD
or DVD images) will use the standard VGA mode 640x480 at
4 bits, because that's the only thing guaranteed to work
everywhere out of the box.  It might be possible to use
a VESA mode at higher color depth (e.g. 8 bits), but the
default resolution should stay at 640x480.

Of course, those who want higher resolutions will be able
to use them by editing their theme.conf file and providing
graphics files of appropriate size.

Best regards
   Oliver

-- 
Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M.
Handelsregister: Registergericht Muenchen, HRA 74606,  Gesch?ftsfuehrung:
secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht M?n-
chen, HRB 125758,  Gesch?ftsf?hrer: Maik Bachmann, Olaf Erb, Ralf Gebhart

FreeBSD-Dienstleistungen, -Produkte und mehr:  http://www.secnetix.de/bsd

"When your hammer is C++, everything begins to look like a thumb."
        -- Steve Haflich, in comp.lang.c++
From pagxir at gmail.com  Tue Feb 10 01:40:46 2009
From: pagxir at gmail.com (=?UTF-8?B?6KO05Zu95YW0?=)
Date: Tue Feb 10 01:40:55 2009
Subject: patch: let msdosfs(vfat)/ntfs to support UTF-8 locale well
Message-ID: <98869b7c0902100112s6dae54bm4c14487076ceb75c@mail.gmail.com>

I write a patch to support UTF-8 locale well. I think it maybe help
for some FreeBSD user.
follow link is the patch (base on FreeBSD 7.1):
http://btload.googlegroups.com/web/msdosfs.patch?gda=MzIscT8AAABs_gmy4a1S9lRiXjEy-V5OpwtI67JnIGlz0zr18tjObOtoi5oIt3BJMRGeqGBbbj-ccyFKn-rNKC-d1pM_IdV0
the full tar.bz2 package:
http://btload.googlegroups.com/web/msdosfs.tar.bz2?gda=IG1pBkEAAABs_gmy4a1S9lRiXjEy-V5OpwtI67JnIGlz0zr18tjObNLRc95Ps2S1UISaL0WhuitTCT_pCLcFTwcI3Sro5jAzlXFeCn-cdYleF-vtiGpWAA

I also will patch for ntfs driver
http://btload.googlegroups.com/web/ntfs.patch?gda=OqsHoDwAAABs_gmy4a1S9lRiXjEy-V5O7RN7t-m4MjZ-5dQn_EvaqDVCWO9_HyYEQJyRQYPtRCL9Wm-ajmzVoAFUlE7c_fAt
http://btload.googlegroups.com/web/ntfs.tar.bz2?gda=zErXED4AAABs_gmy4a1S9lRiXjEy-V5O7RN7t-m4MjZ-5dQn_EvaqG3K0t6fVz8SMYStF_2dqCPjsKXVs-X7bdXZc5buSfmx

The Chinese characters in the fat32 partition can be displayed correctly now.

when mount windows partitions, you should do like this:
mount_ntfs -C UTF-8 /dev/ad?s? /path/to/mount
mount_msdosfs -L zh_CN.UTF-8 /dev/ad?s? /path/to/mount
From naylor.b.david at gmail.com  Tue Feb 10 05:03:11 2009
From: naylor.b.david at gmail.com (David Naylor)
Date: Tue Feb 10 05:49:59 2009
Subject: CFT: Graphics support for /boot/loader
In-Reply-To: <200902100908.n1A989IJ034744@lurza.secnetix.de>
References: <200902100908.n1A989IJ034744@lurza.secnetix.de>
Message-ID: <200902101436.53619.naylor.b.david@gmail.com>

On Tuesday 10 February 2009 11:08:09 Oliver Fromme wrote:
> Hi,
>
> Sorry for the late reply.  I'm swamped with emails, and
> real life takes its time, too ...
>
> Alexey Shuvaev wrote:
>  > Looks good, BTW is 640x480 in 4 bits per pixel the maximum of standard
>  > VGA? Can you go higher or you are already in protected mode with
>  > (almost) no BIOS? I mean, 640x480 is ok, but 4 bits per pixel... mmm...
>  > the same 16 colors as in text mode... although with a palette...
>
> For logos and simple graphics, 16 colors is actually not
> that bad.  Look at the various examples (screen shots) that
> you can find here:
>
> http://www.secnetix.de/olli/FreeBSD/vloader/
>
> With a proper palette and dithering you can make quite
> nice background graphics with only 16 colors.  I made all
> of those with the netbpm tools, xv and a little bit of gimp.
>
> Also take into account that this is "only" a boot screen.
> Most people will see it only for a few seconds.
>
> Regarding your question about VGA modes:
>
> Standard VGA supports at most 640x480 at 4 bits and 320x200
> at 8 bits.  So that's the common denominator.
>
> There are some "hacked modes" (sometimes called "mode X")
> that allow somewhat higher resolutions, such as 704?528
> at 4 bits or 360x256 at 8 bits.  But those don't work well
> with all monitors.
>
> And then there is VESA, of course.  I plan to add limited
> VESA support, so higher resolutions are possible.  However,
> there are a few issues with VESA support:
>
>  - 1. Some VESA BIOS implementations have serious bugs,
>    because nobody uses it in the Windows world.
>
>  - 2. There is no simple and reliable way to autodetect
>    which resolutions are supported by the monitor.
>
>  - 3. There are many, many different VESA modes and display
>    resolutions.  It's unfeasible that FreeBSD ships with
>    appropriate graphics files for every conceivable VESA
>    mode, color depth, display size and height/width ratio.
>
> So, the default FreeBSD boot loader (as shipped on the CD
> or DVD images) will use the standard VGA mode 640x480 at
> 4 bits, because that's the only thing guaranteed to work
> everywhere out of the box.  It might be possible to use
> a VESA mode at higher color depth (e.g. 8 bits), but the
> default resolution should stay at 640x480.
>
> Of course, those who want higher resolutions will be able
> to use them by editing their theme.conf file and providing
> graphics files of appropriate size.
>
> Best regards
>    Oliver

Agreed about 'default' behaviour, but...

It would be a nice feature to support themes at multiple (high) resolutions 
(and depth) [for example]:
 - Provide images at the common aspect ratios (and at the largest resolutions) 
and scale the image to the correct size.
 - Provide the correct theme.conf for the various aspect ratios/sizes (perhaps 
by using relative offsets [i.e. top: 10%, left-middle: 25%, width: 15%])
 - Add a switch in loader.conf to choose the correct resolution...
 - Add caching/tool to do the scaling for first point.  Or provide a way 
to 'compile' the themes at various resolutions (and provide proper theme.conf 
files for that specific resolution?)

Of course the above is just a suggestion...  

Also, GRUB AFAIK supports higher resolutions, perhaps they have found a way to 
handle the VESA problems...

Oh, and nice work ;-).  Loader is looking very good.  

Thanks

David
-------------- 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/20090210/8b7cad7e/attachment.pgp
From jhb at freebsd.org  Tue Feb 10 07:01:20 2009
From: jhb at freebsd.org (John Baldwin)
Date: Tue Feb 10 07:01:27 2009
Subject: UFS Witness LoR + 5 other LoRs
In-Reply-To: <4990A73D.6060108@FreeBSD.org>
References: <1233007263.9302.2.camel@localhost.localdomain>
	<498EB79F.4010905@FreeBSD.org> <4990A73D.6060108@FreeBSD.org>
Message-ID: <200902100942.34044.jhb@freebsd.org>

On Monday 09 February 2009 4:59:25 pm Doug Barton wrote:
> Kris Kennaway wrote:
> > Several of these are widely reported, and harmless 
> 
> Given that we're coming closer and closer to the time when 8.x will be
> in pre-release slush, shouldn't at least some of these get fixed
> soonish? If for no other reason than to make it easier to detect real
> problems when they arise.

Most of these LORs have been present in the tree since at least the unified 
buffer-cache work back in FreeBSD 2.x.  We just did not have the tools to 
report them prior to 8.x.

-- 
John Baldwin
From avg at icyb.net.ua  Tue Feb 10 10:35:18 2009
From: avg at icyb.net.ua (Andriy Gapon)
Date: Tue Feb 10 10:35:27 2009
Subject: [repost] multiple filesystems sharing/clobbering device vnode
Message-ID: <4991C8DF.1020805@icyb.net.ua>


Unfortunately I wasn't able to devote enough time/thinking to this
issue, so I am cowardly resorting to just reminding about it.

-------- Original Message --------
Subject: multiple filesystems sharing/clobbering device vnode
Date: Sat, 01 Mar 2008 11:33:37 +0200
From: Andriy Gapon <avg@icyb.net.ua>
To: freebsd-arch@freebsd.org


First, a little demonstration suggested by Bruce Evance:
[I hope you will continue reading after reboot]
1. mount_cd9660 /dev/acd0 /mnt1
2. mount -r /dev/acd0 /mnt2 # -r is important
3. ls -l /mnt1

The issue can be laconically described as follows:
1. We do not disallow multiple RO mounts of the same device (which could
be done either on purpose or by an accident).
2. All popular (on-disk) filesystems use/clobber bufobj of device's
vnode, even for RO mounts; some (ufs) do that even if mount fails.
3. There are no considerations for such a shared access, all filesystems
act as if it is an exclusive owner of the vnode / its bufobj.

Small snippet of code that speaks for itself (the most interesting lines
are marked with XXX at the beginning):
int
g_vfs_open(struct vnode *vp, struct g_consumer **cpp, const char
*fsname, int wr)
{
        struct g_geom *gp;
        struct g_provider *pp;
        struct g_consumer *cp;
        struct bufobj *bo;
        int vfslocked;
        int error;

        g_topology_assert();

        *cpp = NULL;
        pp = g_dev_getprovider(vp->v_rdev);
        if (pp == NULL)
                return (ENOENT);
        gp = g_new_geomf(&g_vfs_class, "%s.%s", fsname, pp->name);
        cp = g_new_consumer(gp);
        g_attach(cp, pp);
        error = g_access(cp, 1, wr, 1);
        if (error) {
                g_wither_geom(gp, ENXIO);
                return (error);
        }
        vfslocked = VFS_LOCK_GIANT(vp->v_mount);
        vnode_create_vobject(vp, pp->mediasize, curthread);
        VFS_UNLOCK_GIANT(vfslocked);
        *cpp = cp;
XXX     bo = &vp->v_bufobj;
XXX     bo->bo_ops = g_vfs_bufops;
XXX     bo->bo_private = cp;
XXX     bo->bo_bsize = pp->sectorsize;
        gp->softc = bo;

        return (error);
}

In addition to this, some filesystems (ufs) directly modify v_bufobj.

I've been pondering this issue for over a month now, I have some ideas
but they all are wanting in one aspect or other.

I would like to hear ideas and opinions of the people on this list.

P.S. for those who didn't actually run the test, here's a hand-copied
excerpt from stack trace:
g_io_request
g_vfs_strategy
ffs_geom_strategy
cd9660_strategy
VOP_STRATEGY_APV
bufstrategy
breadn
bread
cd9660_readdir

-- 
Andriy Gapon

From dougb at FreeBSD.org  Tue Feb 10 10:45:40 2009
From: dougb at FreeBSD.org (Doug Barton)
Date: Tue Feb 10 10:45:47 2009
Subject: UFS Witness LoR + 5 other LoRs
In-Reply-To: <200902100942.34044.jhb@freebsd.org>
References: <1233007263.9302.2.camel@localhost.localdomain>
	<498EB79F.4010905@FreeBSD.org> <4990A73D.6060108@FreeBSD.org>
	<200902100942.34044.jhb@freebsd.org>
Message-ID: <4991CB51.2060609@FreeBSD.org>

John Baldwin wrote:
> On Monday 09 February 2009 4:59:25 pm Doug Barton wrote:
>> Kris Kennaway wrote:
>>> Several of these are widely reported, and harmless 
>> Given that we're coming closer and closer to the time when 8.x will be
>> in pre-release slush, shouldn't at least some of these get fixed
>> soonish? If for no other reason than to make it easier to detect real
>> problems when they arise.
> 
> Most of these LORs have been present in the tree since at least the unified 
> buffer-cache work back in FreeBSD 2.x.  We just did not have the tools to 
> report them prior to 8.x.

I'm not saying that I think the ones that are oft-reported are
harmful. I'm saying that they ought to be fixed so that when harmful
ones do show up it's easier to spot them.

FWIW, I had an experience similar to the OP. I have several LORs that
show up every time I boot which I try to ignore. However, I recently
had a problem with my current laptop NFS mounting my 6-stable file
server. There was a LOR in there somewhere, but I couldn't tell if it
was one of the "usual" ones, or if it was relevant. As we get closer
to the 8-release slushie and start asking people to do serious
debugging this issue is going to make that more difficult.

Doug

-- 

    This .signature sanitized for your protection
From pluknet at gmail.com  Tue Feb 10 12:13:32 2009
From: pluknet at gmail.com (pluknet)
Date: Tue Feb 10 12:13:39 2009
Subject: hald/geom(?) lock up
Message-ID: <a31046fc0902101213t6dcd6a39j625bc8e4927157e5@mail.gmail.com>

Hi all.

On recent -current after inserting a CD my system locks up in a few minutes.
Any commands I tried then lock on sysctl lock; i.e. ctrl+t returns:
load: 0.04 cmd: sudo 1008 [sysctl lock] 0.00u 0.00s 0% 312k

FreeBSD 8.0-CURRENT #19: Tue Feb 10 00:24:21 UTC 2009

Captured ddb (partially transcribed as ddb capture does not return some data):

db> show alllocks

Process 924 (sshd) thread 0xc5d606c0 (100107)
exclusive sx so_rcv_sx ... uipc_sockbuf.c:148
Process 890 (hald-addon-storage) thread 0xc5afd240 (100091)
exclusive sx GEOM topology ... geom_dev.c:171
Process 880 (hald) thread 0xc5d60900 (100106)
exclusive sx sysctl lock ... kern_sysctl.c:1510
Process 12 (intr) thread 0xc5663000 (100023)
exclusive sleep mutex Giant ... kbdmux.c:1044
db> bt 890

Tracing pid 890 tid 100091 td 0xc5afd240
sched_switch(c5afd240,0,104,18d,ae7e8399,...) at sched_switch+0x437
mi_switch(104,0,c0805c50,1d2,0,...) at mi_switch+0x200
sleepq_switch(c5afd240,0,c0805c50,26a,2,...) at sleepq_switch+0x15f
sleepq_timedwait(c089b424,0,c07f05e9,2,0,...) at sleepq_timedwait+0x6b
_sleep(c089b424,0,0,c07f05e9,1f4,...) at _sleep+0x329
pause(c07f05e9,1f4,10,c5e170d0,c5986200,...) at pause+0x47
acd_geom_access(c5986200,1,0,0,0,...) at acd_geom_access+0xeb
g_access(c5989340,1,0,0,2000,...) at g_access+0x20b
g_dev_open(c59a0500,1,2000,c5afd240,c052a7b4,...) at g_dev_open+0x104
devfs_open(e7f1cacc,c5afd240,e7f1cba8,0,e7f1caf4,...) at devfs_open+0xe6
VOP_OPEN_APV(c0847e80,e7f1cacc,c07fd022,c07fa9c9,c5decb84,...) at
VOP_OPEN_APV+0xa5
vn_open_cred(e7f1cba8,e7f1cc5c,0,c5512900,c5de47a8,...) at vn_open_cred+0x429
vn_open(e7f1cba8,e7f1cc5c,0,c5de47a8,3,...) at vn_open+0x33
kern_openat(c5afd240,ffffff9c,bfbfe490,0,1,...) at kern_openat+0x110
kern_open(c5afd240,bfbfe490,0,0,0,...) at kern_open+0x35
open(c5afd240,e7f1ccf8,c,c0818fe7,c084b2d8,...) at open+0x30
syscall(e7f1cd38) at syscall+0x2a3
Xint0x80_syscall() at Xint0x80_syscall+0x20
--- syscall (5, FreeBSD ELF32, open), eip = 0x281c5fd3, esp =
0xbfbfe19c, ebp = 0xbfbfe1c8 ---
db> bt 880

Tracing pid 880 tid 100106 td 0xc5d60900
sched_switch(c5d60900,0,104,18d,dc8c7829,...) at sched_switch+0x437
mi_switch(104,0,c0805c50,1d2,4c,...) at mi_switch+0x200
sleepq_switch(c5d60900,0,c0805c50,26a,0,...) at sleepq_switch+0x15f
sleepq_timedwait(c5c8e200,4c,c07f97cd,0,0,...) at sleepq_timedwait+0x6b
_sleep(c5c8e200,0,4c,c07f97cd,3e8,...) at _sleep+0x329
g_waitfor_event(c0542cb0,c59847e0,2,0,0,...) at g_waitfor_event+0x9c
sysctl_kern_geom_conftxt(c08493c0,0,0,e7f72ba4,e7f72ba4,...) at
sysctl_kern_geom_conftxt+0x58
sysctl_root(e7f72ba4,0,c0802669,5e6,c5d60900,...) at sysctl_root+0x199
userland_sysctl(c5d60900,e7f72c10,3,0,bfbfe9c4,...) at userland_sysctl+0x115
__sysctl(c5d60900,e7f72cf8,18,c08087f9,c084c550,...) at __sysctl+0x94
syscall(e7f72d38) at syscall+0x2a3
Xint0x80_syscall() at Xint0x80_syscall+0x20
--- syscall (202, FreeBSD ELF32, __sysctl), eip = 0x28350b3f, esp =
0xbfbfe8bc, ebp = 0xbfbfe8e8 ---
db> c

[thread pid 12 tid 100023 ]
Stopped at      kdb_enter+0x3a: movl    $0,kdb_why
db> ps

  pid  ppid  pgrp   uid   state   wmesg     wchan    cmd
 1113   932  1113  1001  S+      sysctl l 0xc089b464 ls
 1042     1  1042     0  Ss      select   0xc5e3aaa4 sshd
  981   884   880     0  S       select   0xc5c950a4 initial thread
  932   868   932  1001  S+      wait     0xc5af7a90 bash
  929   928   929  1001  Ss+     ttyin    0xc575e270 bash
  928   924   924  1001  S       select   0xc5799624 sshd
  924     1   924     0  Ss      sbwait   0xc5df7238 sshd
  890   884   880     0  S       acdld    0xc089b424 initial thread
  884   880   880     0  S       select   0xc5989de4 initial thread
  883     1   883     0  Ss      (threaded)          console-kit-daemon
100111                   S       waitvt   0xc0896f84 console-kit-daemon
100125                   S       waitvt   0xc0896fbc console-kit-daemon
100124                   S       waitvt   0xc0896fb8 console-kit-daemon
100123                   S       waitvt   0xc0896fb4 console-kit-daemon
100122                   S       waitvt   0xc0896fb0 console-kit-daemon
100121                   S       waitvt   0xc0896fac console-kit-daemon
100120                   S       waitvt   0xc0896fa8 console-kit-daemon
100119                   S       waitvt   0xc0896fa4 console-kit-daemon
100118                   S       waitvt   0xc0896fa0 console-kit-daemon
db> bt 1113

Tracing pid 1113 tid 100126 td 0xc5d5f6c0
sched_switch(c5d5f6c0,0,104,18d,6d4b9014,...) at sched_switch+0x437
mi_switch(104,0,c0805c50,1d2,0,...) at mi_switch+0x200
sleepq_switch(c5d5f6c0,0,c0805c50,247,c089b464,...) at sleepq_switch+0x15f
sleepq_wait(c089b464,0,c0802757,3,0,...) at sleepq_wait+0x63
_sx_xlock_hard(c089b464,c5d5f6c0,0,c0802669,5e6,...) at _sx_xlock_hard+0x286
_sx_xlock(c089b464,0,c0802669,5e6,c5d5f6c0,...) at _sx_xlock+0xc0
userland_sysctl(c5d5f6c0,e7faec10,2,bfbfeacc,bfbfead0,...) at
userland_sysctl+0xf1
__sysctl(c5d5f6c0,e7faecf8,18,c,c084c550,...) at __sysctl+0x94
syscall(e7faed38) at syscall+0x2a3
Xint0x80_syscall() at Xint0x80_syscall+0x20
--- syscall (202, FreeBSD ELF32, __sysctl), eip = 0x2806147b, esp =
0xbfbfea6c, ebp = 0xbfbfea98 ---
db> c


-- 
wbr,
pluknet
From shuvaev at physik.uni-wuerzburg.de  Tue Feb 10 12:14:50 2009
From: shuvaev at physik.uni-wuerzburg.de (Alexey Shuvaev)
Date: Tue Feb 10 12:14:58 2009
Subject: lpt stopped working
In-Reply-To: <200902091458.41637.jhb@freebsd.org>
References: <200902021643.39862.c47g@gmx.at>
	<200902091133.48838.jhb@freebsd.org>
	<200902091958.39480.c47g@gmx.at>
	<200902091458.41637.jhb@freebsd.org>
Message-ID: <20090210201447.GA1664@wep4035.physik.uni-wuerzburg.de>

On Mon, Feb 09, 2009 at 02:58:41PM -0500, John Baldwin wrote:
> On Monday 09 February 2009 1:58:39 pm Christian Gusenbauer wrote:
> > On Monday 09 February 2009, John Baldwin wrote:
> > >
> > > Please help to debug this so we can have working lpt0 in 8.0.  No one
> > > tested the patches months ago when I first posted them, and if folks do 
> not
> > > test them now I will simply remove the driver before 8.0 ships.  I no
> > 
> > Mea culpa, too. As you sent your patches, I thought someone else will do the 
> > tests surely ... :-(.
> > 
> > > longer have any hardware such that I can test this directly, so I am
> > > depending on folks to test things I have asked for and report back.  I
> > > believe the last thing I asked for was for someone to do this when they 
> lpt
> > > was hung:
> > >
> > > Ok, can you run kgdb against your running kernel (Just run 'kgdb' without
> > > any arguments) and do the following:
> > >
> > > (kgdb) p *(struct ppb_data *)ppbus_devclass->devices[0]->softc
> > >
> > > Assuming the ppb_owner is not 0, can you then do this:
> > >
> > > (kgdb) p *(device_t)((struct ppb_data
> > > *)ppbus_devclass->devices[0]->softc)->ppb_owner
> > 
> > This is the output (unfortunately ppb_owner IS 0):
> > 
> > (kgdb) p *(struct ppb_data *)ppbus_devclass->devices[0]->softc
> > $1 = {class_id = 10, state = 1, error = 0, mode = 0, ppb_owner = 0x0,
> >   ppc_lock = 0xc56bfe7c, ppc_irq_res = 0xc573d5c0}
> 
> And this is while lpd or the like is hung trying to write to /dev/lpt0?
> 
Hello all!

Ok, here we go. 1st, the system:
~> uname -a
FreeBSD wep4035 8.0-CURRENT FreeBSD 8.0-CURRENT #0: Sat Feb  7 20:25:10 CET 2009     root@wep4035:/usr/obj/usr/src/sys/NOUSB  amd64

Parallel port (from dmesg):
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
ppbus0: IEEE1284 device found /NIBBLE/ECP
ppbus0: Probing for PnP devices:
ppbus0: <HEWLETT-PACKARD OFFICEJET R60> PRINTER MLC,PCL,PML,SCL
plip0: <PLIP network interface> on ppbus0
plip0: [ITHREAD]
lpt0: <Printer> on ppbus0
lpt0: [ITHREAD]
lpt0: Interrupt-driven port
ppi0: <Parallel I/O> on ppbus0

I have simplified things and do not run lpd. The command is:
'ktrace -id cat monitor_info > /dev/lpt0'
(I think it should work?)
kdump -E > ktrace.dump does not show anything interesting:
[snip]
  1564 cat      0.001120 CALL  open(0x7fffffffee1c,O_RDONLY,<unused>0x6d)
  1564 cat      0.001127 NAMI  "monitor_info"
  1564 cat      0.001143 RET   open 3
  1564 cat      0.001149 CALL  fstat(0x1,0x7fffffffeac0)
  1564 cat      0.001155 STRU  struct stat {dev=83951360, ino=53, mode=crw-rw---
- , nlink=1, uid=0, gid=0, rdev=53, atime=1234294743.332164000, stime=1234294743
.332164000, ctime=1234294974, birthtime=-1, size=0, blksize=4096, blocks=0, flag
s=0x0 }
  1564 cat      0.001160 RET   fstat 0
  1564 cat      0.001180 CALL  __sysctl(0x7fffffffea20,0x2,0x80085eeb8,0x7ffffff
fea18,0,0)
  1564 cat      0.001187 RET   __sysctl 0
  1564 cat      0.001191 CALL  __sysctl(0x7fffffffea60,0x2,0x7fffffffea7c,0x7fff
ffffea70,0,0)
  1564 cat      0.001198 RET   __sysctl 0
  1564 cat      0.001203 CALL  __sysctl(0x7fffffffea60,0x2,0x7fffffffea7c,0x7fffffffea70,0,0)
  1564 cat      0.001208 RET   __sysctl 0
  1564 cat      0.001230 CALL  __sysctl(0x7fffffffe5f0,0x2,0x8008509e8,0x7fffffffe5e8,0,0)
  1564 cat      0.001236 RET   __sysctl 0
  1564 cat      0.001242 CALL  readlink(0x800722639,0x7fffffffe610,0x400)
  1564 cat      0.001248 NAMI  "/etc/malloc.conf"
  1564 cat      0.001264 RET   readlink -1 errno 2 No such file or directory
  1564 cat      0.001270 CALL  issetugid
  1564 cat      0.001275 RET   issetugid 0
  1564 cat      0.001296 CALL  break(0x600000)
  1564 cat      0.001302 RET   break 0
  1564 cat      0.001317 CALL  __sysctl(0x7fffffffe850,0x2,0x7fffffffe86c,0x7fffffffe860,0,0)
  1564 cat      0.001324 RET   __sysctl 0
  1564 cat      0.001329 CALL  mmap(0,0x100000,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON,0xffffffff,0)
  1564 cat      0.001335 RET   mmap 8790016/0x800862000
  1564 cat      0.001340 CALL  mmap(0x800962000,0x9e000,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON,0xffffffff,0)
  1564 cat      0.001346 RET   mmap 9838592/0x800962000
  1564 cat      0.001351 CALL  munmap(0x800862000,0x9e000)
  1564 cat      0.001359 RET   munmap 0
  1564 cat      0.001378 CALL  read(0x3,0x800902000,0x1000)
  1564 cat      0.006845 GIO   fd 3 read 4096 bytes
       "(II) VESA(0): VESA VBE DDC supported
        (II) VESA(0): VESA VBE DDC Level 2
        (II) VESA(0): VESA VBE DDC transfer in appr. 1 sec.
        (==) VESA(0): Write-combining range (0x0,0x1000) was already clear
        (==) VESA(0): Write-combining range (0x0,0x1000) was already clear
[snip]
        1 604 625 +hsync +vsync (46.9 kHz)
        (II) VESA(0): Modeline "800x600"x0.0   50.00  800 856 976 1040  600 63\
        7 643 666 +hsync +vsync (48.1 kHz)
        (II) VESA(0): Modeline "1280x1024"x60.0  108.88  1280 1360 1496 1712  \
        1024 1025 1028 1060 -hsync +vsync (63.6 kHz)
        (II) VESA(0): Modeline "1680x1050"x60.0  147.14  16"
  1564 cat      0.006879 RET   read 4096/0x1000
  1564 cat      0.006888 CALL  write(0x1,0x800902000,0x1000)
  1564 cat      114.695563 RET   write RESTART
  1564 cat      114.695637 PSIG  SIGINT SIG_DFL

After 114 seconds I have hit Ctrl-C.

And this is from kgdb:
(kgdb) p *(struct ppb_data *)ppbus_devclass->devices[0]->softc
$1 = {class_id = 0, state = 1, error = 0, mode = 0,
  ppb_owner = 0xffffff0004668700, ppc_lock = 0xffffff0004668eb8,
  ppc_irq_res = 0xffffff0004677900}
(kgdb) p *(device_t)((struct ppb_data*)ppbus_devclass->devices[0]->softc)->ppb
_owner
$2 = {ops = 0xffffff0001520000, link = {tqe_next = 0xffffff0004668500,
    tqe_prev = 0xffffff0004668908}, devlink = {tqe_next = 0xffffff0004668500,
    tqe_prev = 0xffffff0004668918}, parent = 0xffffff0004669000, children = {
    tqh_first = 0x0, tqh_last = 0xffffff0004668730},
  driver = 0xffffffff806961c0, devclass = 0xffffff00014f4900, unit = 0,
  nameunit = 0xffffff0004666940 "lpt0", desc = 0xffffffff804fc110 "Printer",
  busy = 0, state = DS_ATTACHED, devflags = 0, flags = 7, order = 0 '\0',
  pad = 0 '\0', ivars = 0xffffff0004668800, softc = 0xffffff0004668400,
  sysctl_ctx = {tqh_first = 0xffffff0004674180,
    tqh_last = 0xffffff0004674288}, sysctl_tree = 0xffffff000467d480}
(kgdb)

The driver stays in this state even after exit of 'cat' process
(I think this was already reported):
~> cat monitor_info > /dev/lpt0
/dev/lpt0: Device busy.

I can play with the printer et. al. (ppi, maybe plip) in the evenings,
so if you need something else...

Alexey.
From atkin901 at yahoo.com  Tue Feb 10 12:20:51 2009
From: atkin901 at yahoo.com (Mark Atkinson)
Date: Tue Feb 10 12:21:01 2009
Subject: memory alignment problems with -current on amd64? [Found Cause]
References: <gl7hu4$q7k$1@ger.gmane.org> <gmqbv1$jhe$1@ger.gmane.org>
Message-ID: <gmsnin$qg9$1@ger.gmane.org>

Mark Atkinson wrote:
> Mark Atkinson wrote:
>> With recent kernels on HAMMER/amd64 I cannot complete a buildworld.  The
>> compilation keeps failing with problems like:
[...]
>> /usr/src/gnu/usr.bin/binutils/as/../../../../contrib/binutils/gas/subsegs.c:205:
>> internal compiler error: Bus error: 10 Please submit a full bug report,
>> with preprocessed source if appropriate. See
>> <URL:http://gcc.gnu.org/bugs.html> for instructions. *** Error code 1 1
[...]
>> If I boot back to a kernel from sources Oct 15th 2008, I can complete a
>> buildworld on this machine no problem.
>> 
>> * This is a HP DL385G5 with 1 quad core AMD 2100 and 10G of memory.
>> * This the amd64 GENERIC kernel
>> * I've tried reducing hw.physmem to 2G, but that didn't make any
>> difference. * I will recieve bus errors when running buildworld w/ -j1
>> * If I run buildworld with a larger number the machine will reset w/ no
>> panic.
[...]
> Since I can go back to the Oct 15th kernel and do a complete buildworld, I
> can only assume -current has changed since then for amd64 sizing to maybe
> access something other than what the e820 method would return?

Well, taking the information I knew -- OCT 15th == good, Mid DEC == BAD,
I trolled every commit logged between.   Eventually I found this one:

http://svn.freebsd.org/viewvc/base?view=revision&revision=185715

http://docs.freebsd.org/cgi/mid.cgi?200812061937.mB6JbqAI003273

I set vm.pmap.pg_ps_enabled="0" in /boot/loader.conf, and
was able to complete buildworld and -j16 buildworld and -j8 buildkernel
no problem.

It appears superpage mapping causes alignment problems on this box.  
-- 
Mark Atkinson
atkin901@yahoo.com
(!wired)?(coffee++):(wired);

From pluknet at gmail.com  Tue Feb 10 12:42:14 2009
From: pluknet at gmail.com (pluknet)
Date: Tue Feb 10 12:42:21 2009
Subject: hald/geom(?) lock up
In-Reply-To: <a31046fc0902101213t6dcd6a39j625bc8e4927157e5@mail.gmail.com>
References: <a31046fc0902101213t6dcd6a39j625bc8e4927157e5@mail.gmail.com>
Message-ID: <a31046fc0902101242p1b405810q8ff96cffb3b106da@mail.gmail.com>

2009/2/10 pluknet <pluknet@gmail.com>:
> Hi all.
>
> On recent -current after inserting a CD my system locks up in a few minutes.
> Any commands I tried then lock on sysctl lock; i.e. ctrl+t returns:
> load: 0.04 cmd: sudo 1008 [sysctl lock] 0.00u 0.00s 0% 312k
>

Well, yes, looks more like a broken acd driver.

-- 
wbr,
pluknet
From c47g at gmx.at  Tue Feb 10 12:51:27 2009
From: c47g at gmx.at (Christian Gusenbauer)
Date: Tue Feb 10 12:51:34 2009
Subject: lpt stopped working
In-Reply-To: <20090210201447.GA1664@wep4035.physik.uni-wuerzburg.de>
References: <200902021643.39862.c47g@gmx.at>
	<200902091458.41637.jhb@freebsd.org>
	<20090210201447.GA1664@wep4035.physik.uni-wuerzburg.de>
Message-ID: <200902102151.49625.c47g@gmx.at>

On Tuesday 10 February 2009, Alexey Shuvaev wrote:
> On Mon, Feb 09, 2009 at 02:58:41PM -0500, John Baldwin wrote:
> > On Monday 09 February 2009 1:58:39 pm Christian Gusenbauer wrote:
> > > On Monday 09 February 2009, John Baldwin wrote:
> > > > Please help to debug this so we can have working lpt0 in 8.0.  No one
> > > > tested the patches months ago when I first posted them, and if folks
> > > > do
> >
> > not
> >
> > > > test them now I will simply remove the driver before 8.0 ships.  I no
> > >
> > > Mea culpa, too. As you sent your patches, I thought someone else will
> > > do the tests surely ... :-(.
> > >
> > > > longer have any hardware such that I can test this directly, so I am
> > > > depending on folks to test things I have asked for and report back. 
> > > > I believe the last thing I asked for was for someone to do this when
> > > > they
> >
> > lpt
> >
> > > > was hung:
> > > >
> > > > Ok, can you run kgdb against your running kernel (Just run 'kgdb'
> > > > without any arguments) and do the following:
> > > >
> > > > (kgdb) p *(struct ppb_data *)ppbus_devclass->devices[0]->softc
> > > >
> > > > Assuming the ppb_owner is not 0, can you then do this:
> > > >
> > > > (kgdb) p *(device_t)((struct ppb_data
> > > > *)ppbus_devclass->devices[0]->softc)->ppb_owner
> > >
> > > This is the output (unfortunately ppb_owner IS 0):
> > >
> > > (kgdb) p *(struct ppb_data *)ppbus_devclass->devices[0]->softc
> > > $1 = {class_id = 10, state = 1, error = 0, mode = 0, ppb_owner = 0x0,
> > >   ppc_lock = 0xc56bfe7c, ppc_irq_res = 0xc573d5c0}
> >
> > And this is while lpd or the like is hung trying to write to /dev/lpt0?
>
> Hello all!
>
> Ok, here we go. 1st, the system:
> ~> uname -a
> FreeBSD wep4035 8.0-CURRENT FreeBSD 8.0-CURRENT #0: Sat Feb  7 20:25:10 CET
> 2009     root@wep4035:/usr/obj/usr/src/sys/NOUSB  amd64
>
> Parallel port (from dmesg):
> 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
> ppbus0: IEEE1284 device found /NIBBLE/ECP
> ppbus0: Probing for PnP devices:
> ppbus0: <HEWLETT-PACKARD OFFICEJET R60> PRINTER MLC,PCL,PML,SCL
> plip0: <PLIP network interface> on ppbus0
> plip0: [ITHREAD]
> lpt0: <Printer> on ppbus0
> lpt0: [ITHREAD]
> lpt0: Interrupt-driven port
> ppi0: <Parallel I/O> on ppbus0
>
> I have simplified things and do not run lpd. The command is:
> 'ktrace -id cat monitor_info > /dev/lpt0'
> (I think it should work?)
> kdump -E > ktrace.dump does not show anything interesting:
> [snip]
>   1564 cat      0.001120 CALL  open(0x7fffffffee1c,O_RDONLY,<unused>0x6d)
>   1564 cat      0.001127 NAMI  "monitor_info"
>   1564 cat      0.001143 RET   open 3
>   1564 cat      0.001149 CALL  fstat(0x1,0x7fffffffeac0)
>   1564 cat      0.001155 STRU  struct stat {dev=83951360, ino=53,
> mode=crw-rw--- - , nlink=1, uid=0, gid=0, rdev=53,
> atime=1234294743.332164000, stime=1234294743 .332164000, ctime=1234294974,
> birthtime=-1, size=0, blksize=4096, blocks=0, flag s=0x0 }
>   1564 cat      0.001160 RET   fstat 0
>   1564 cat      0.001180 CALL 
> __sysctl(0x7fffffffea20,0x2,0x80085eeb8,0x7ffffff fea18,0,0)
>   1564 cat      0.001187 RET   __sysctl 0
>   1564 cat      0.001191 CALL 
> __sysctl(0x7fffffffea60,0x2,0x7fffffffea7c,0x7fff ffffea70,0,0)
>   1564 cat      0.001198 RET   __sysctl 0
>   1564 cat      0.001203 CALL 
> __sysctl(0x7fffffffea60,0x2,0x7fffffffea7c,0x7fffffffea70,0,0) 1564 cat    
>  0.001208 RET   __sysctl 0
>   1564 cat      0.001230 CALL 
> __sysctl(0x7fffffffe5f0,0x2,0x8008509e8,0x7fffffffe5e8,0,0) 1564 cat     
> 0.001236 RET   __sysctl 0
>   1564 cat      0.001242 CALL  readlink(0x800722639,0x7fffffffe610,0x400)
>   1564 cat      0.001248 NAMI  "/etc/malloc.conf"
>   1564 cat      0.001264 RET   readlink -1 errno 2 No such file or
> directory 1564 cat      0.001270 CALL  issetugid
>   1564 cat      0.001275 RET   issetugid 0
>   1564 cat      0.001296 CALL  break(0x600000)
>   1564 cat      0.001302 RET   break 0
>   1564 cat      0.001317 CALL 
> __sysctl(0x7fffffffe850,0x2,0x7fffffffe86c,0x7fffffffe860,0,0) 1564 cat    
>  0.001324 RET   __sysctl 0
>   1564 cat      0.001329 CALL 
> mmap(0,0x100000,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON,0xffffffff,0)
> 1564 cat      0.001335 RET   mmap 8790016/0x800862000
>   1564 cat      0.001340 CALL 
> mmap(0x800962000,0x9e000,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON,0xffffff
>ff,0) 1564 cat      0.001346 RET   mmap 9838592/0x800962000
>   1564 cat      0.001351 CALL  munmap(0x800862000,0x9e000)
>   1564 cat      0.001359 RET   munmap 0
>   1564 cat      0.001378 CALL  read(0x3,0x800902000,0x1000)
>   1564 cat      0.006845 GIO   fd 3 read 4096 bytes
>        "(II) VESA(0): VESA VBE DDC supported
>         (II) VESA(0): VESA VBE DDC Level 2
>         (II) VESA(0): VESA VBE DDC transfer in appr. 1 sec.
>         (==) VESA(0): Write-combining range (0x0,0x1000) was already clear
>         (==) VESA(0): Write-combining range (0x0,0x1000) was already clear
> [snip]
>         1 604 625 +hsync +vsync (46.9 kHz)
>         (II) VESA(0): Modeline "800x600"x0.0   50.00  800 856 976 1040  600
> 63\ 7 643 666 +hsync +vsync (48.1 kHz)
>         (II) VESA(0): Modeline "1280x1024"x60.0  108.88  1280 1360 1496
> 1712  \ 1024 1025 1028 1060 -hsync +vsync (63.6 kHz)
>         (II) VESA(0): Modeline "1680x1050"x60.0  147.14  16"
>   1564 cat      0.006879 RET   read 4096/0x1000
>   1564 cat      0.006888 CALL  write(0x1,0x800902000,0x1000)
>   1564 cat      114.695563 RET   write RESTART
>   1564 cat      114.695637 PSIG  SIGINT SIG_DFL
>
> After 114 seconds I have hit Ctrl-C.
>
> And this is from kgdb:
> (kgdb) p *(struct ppb_data *)ppbus_devclass->devices[0]->softc
> $1 = {class_id = 0, state = 1, error = 0, mode = 0,
>   ppb_owner = 0xffffff0004668700, ppc_lock = 0xffffff0004668eb8,
>   ppc_irq_res = 0xffffff0004677900}
> (kgdb) p *(device_t)((struct
> ppb_data*)ppbus_devclass->devices[0]->softc)->ppb _owner
> $2 = {ops = 0xffffff0001520000, link = {tqe_next = 0xffffff0004668500,
>     tqe_prev = 0xffffff0004668908}, devlink = {tqe_next =
> 0xffffff0004668500, tqe_prev = 0xffffff0004668918}, parent =
> 0xffffff0004669000, children = { tqh_first = 0x0, tqh_last =
> 0xffffff0004668730},
>   driver = 0xffffffff806961c0, devclass = 0xffffff00014f4900, unit = 0,
>   nameunit = 0xffffff0004666940 "lpt0", desc = 0xffffffff804fc110
> "Printer", busy = 0, state = DS_ATTACHED, devflags = 0, flags = 7, order =
> 0 '\0', pad = 0 '\0', ivars = 0xffffff0004668800, softc =
> 0xffffff0004668400, sysctl_ctx = {tqh_first = 0xffffff0004674180,
>     tqh_last = 0xffffff0004674288}, sysctl_tree = 0xffffff000467d480}
> (kgdb)
>
> The driver stays in this state even after exit of 'cat' process
> (I think this was already reported):
> ~> cat monitor_info > /dev/lpt0
> /dev/lpt0: Device busy.
>
> I can play with the printer et. al. (ppi, maybe plip) in the evenings,
> so if you need something else...
>
> Alexey.
> _______________________________________________
> 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 second that. I do not use lpd, too. Just a plain cat as Alexey does.

@John: sorry, it seems that I still do not get your mails :-(.

Christian.


From jhb at freebsd.org  Tue Feb 10 13:13:16 2009
From: jhb at freebsd.org (John Baldwin)
Date: Tue Feb 10 13:13:23 2009
Subject: lpt stopped working
In-Reply-To: <20090210201447.GA1664@wep4035.physik.uni-wuerzburg.de>
References: <200902021643.39862.c47g@gmx.at>
	<200902091458.41637.jhb@freebsd.org>
	<20090210201447.GA1664@wep4035.physik.uni-wuerzburg.de>
Message-ID: <200902101612.57922.jhb@freebsd.org>

On Tuesday 10 February 2009 3:14:47 pm Alexey Shuvaev wrote:
> On Mon, Feb 09, 2009 at 02:58:41PM -0500, John Baldwin wrote:
> > On Monday 09 February 2009 1:58:39 pm Christian Gusenbauer wrote:
> > > On Monday 09 February 2009, John Baldwin wrote:
> > > >
> > > > Please help to debug this so we can have working lpt0 in 8.0.  No one
> > > > tested the patches months ago when I first posted them, and if folks 
do 
> > not
> > > > test them now I will simply remove the driver before 8.0 ships.  I no
> > > 
> > > Mea culpa, too. As you sent your patches, I thought someone else will do 
the 
> > > tests surely ... :-(.
> > > 
> > > > longer have any hardware such that I can test this directly, so I am
> > > > depending on folks to test things I have asked for and report back.  I
> > > > believe the last thing I asked for was for someone to do this when 
they 
> > lpt
> > > > was hung:
> > > >
> > > > Ok, can you run kgdb against your running kernel (Just run 'kgdb' 
without
> > > > any arguments) and do the following:
> > > >
> > > > (kgdb) p *(struct ppb_data *)ppbus_devclass->devices[0]->softc
> > > >
> > > > Assuming the ppb_owner is not 0, can you then do this:
> > > >
> > > > (kgdb) p *(device_t)((struct ppb_data
> > > > *)ppbus_devclass->devices[0]->softc)->ppb_owner
> > > 
> > > This is the output (unfortunately ppb_owner IS 0):
> > > 
> > > (kgdb) p *(struct ppb_data *)ppbus_devclass->devices[0]->softc
> > > $1 = {class_id = 10, state = 1, error = 0, mode = 0, ppb_owner = 0x0,
> > >   ppc_lock = 0xc56bfe7c, ppc_irq_res = 0xc573d5c0}
> > 
> > And this is while lpd or the like is hung trying to write to /dev/lpt0?
> > 
> Hello all!
> 
> Ok, here we go. 1st, the system:
> ~> uname -a
> FreeBSD wep4035 8.0-CURRENT FreeBSD 8.0-CURRENT #0: Sat Feb  7 20:25:10 CET 
2009     root@wep4035:/usr/obj/usr/src/sys/NOUSB  amd64
> 
> Parallel port (from dmesg):
> 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
> ppbus0: IEEE1284 device found /NIBBLE/ECP
> ppbus0: Probing for PnP devices:
> ppbus0: <HEWLETT-PACKARD OFFICEJET R60> PRINTER MLC,PCL,PML,SCL
> plip0: <PLIP network interface> on ppbus0
> plip0: [ITHREAD]
> lpt0: <Printer> on ppbus0
> lpt0: [ITHREAD]
> lpt0: Interrupt-driven port
> ppi0: <Parallel I/O> on ppbus0
> 
> I have simplified things and do not run lpd. The command is:
> 'ktrace -id cat monitor_info > /dev/lpt0'
> (I think it should work?)
> kdump -E > ktrace.dump does not show anything interesting:
> [snip]
>   1564 cat      0.001120 CALL  open(0x7fffffffee1c,O_RDONLY,<unused>0x6d)
>   1564 cat      0.001127 NAMI  "monitor_info"
>   1564 cat      0.001143 RET   open 3
>   1564 cat      0.001149 CALL  fstat(0x1,0x7fffffffeac0)
>   1564 cat      0.001155 STRU  struct stat {dev=83951360, ino=53, 
mode=crw-rw---
> - , nlink=1, uid=0, gid=0, rdev=53, atime=1234294743.332164000, 
stime=1234294743
> .332164000, ctime=1234294974, birthtime=-1, size=0, blksize=4096, blocks=0, 
flag
> s=0x0 }
>   1564 cat      0.001160 RET   fstat 0
>   1564 cat      0.001180 CALL  
__sysctl(0x7fffffffea20,0x2,0x80085eeb8,0x7ffffff
> fea18,0,0)
>   1564 cat      0.001187 RET   __sysctl 0
>   1564 cat      0.001191 CALL  
__sysctl(0x7fffffffea60,0x2,0x7fffffffea7c,0x7fff
> ffffea70,0,0)
>   1564 cat      0.001198 RET   __sysctl 0
>   1564 cat      0.001203 CALL  
__sysctl(0x7fffffffea60,0x2,0x7fffffffea7c,0x7fffffffea70,0,0)
>   1564 cat      0.001208 RET   __sysctl 0
>   1564 cat      0.001230 CALL  
__sysctl(0x7fffffffe5f0,0x2,0x8008509e8,0x7fffffffe5e8,0,0)
>   1564 cat      0.001236 RET   __sysctl 0
>   1564 cat      0.001242 CALL  readlink(0x800722639,0x7fffffffe610,0x400)
>   1564 cat      0.001248 NAMI  "/etc/malloc.conf"
>   1564 cat      0.001264 RET   readlink -1 errno 2 No such file or directory
>   1564 cat      0.001270 CALL  issetugid
>   1564 cat      0.001275 RET   issetugid 0
>   1564 cat      0.001296 CALL  break(0x600000)
>   1564 cat      0.001302 RET   break 0
>   1564 cat      0.001317 CALL  
__sysctl(0x7fffffffe850,0x2,0x7fffffffe86c,0x7fffffffe860,0,0)
>   1564 cat      0.001324 RET   __sysctl 0
>   1564 cat      0.001329 CALL  mmap(0,0x100000,PROT_READ|
PROT_WRITE,MAP_PRIVATE|MAP_ANON,0xffffffff,0)
>   1564 cat      0.001335 RET   mmap 8790016/0x800862000
>   1564 cat      0.001340 CALL  mmap(0x800962000,0x9e000,PROT_READ|
PROT_WRITE,MAP_PRIVATE|MAP_ANON,0xffffffff,0)
>   1564 cat      0.001346 RET   mmap 9838592/0x800962000
>   1564 cat      0.001351 CALL  munmap(0x800862000,0x9e000)
>   1564 cat      0.001359 RET   munmap 0
>   1564 cat      0.001378 CALL  read(0x3,0x800902000,0x1000)
>   1564 cat      0.006845 GIO   fd 3 read 4096 bytes
>        "(II) VESA(0): VESA VBE DDC supported
>         (II) VESA(0): VESA VBE DDC Level 2
>         (II) VESA(0): VESA VBE DDC transfer in appr. 1 sec.
>         (==) VESA(0): Write-combining range (0x0,0x1000) was already clear
>         (==) VESA(0): Write-combining range (0x0,0x1000) was already clear
> [snip]
>         1 604 625 +hsync +vsync (46.9 kHz)
>         (II) VESA(0): Modeline "800x600"x0.0   50.00  800 856 976 1040  600 
63\
>         7 643 666 +hsync +vsync (48.1 kHz)
>         (II) VESA(0): Modeline "1280x1024"x60.0  108.88  1280 1360 1496 1712  
\
>         1024 1025 1028 1060 -hsync +vsync (63.6 kHz)
>         (II) VESA(0): Modeline "1680x1050"x60.0  147.14  16"
>   1564 cat      0.006879 RET   read 4096/0x1000
>   1564 cat      0.006888 CALL  write(0x1,0x800902000,0x1000)
>   1564 cat      114.695563 RET   write RESTART
>   1564 cat      114.695637 PSIG  SIGINT SIG_DFL
> 
> After 114 seconds I have hit Ctrl-C.
> 
> And this is from kgdb:
> (kgdb) p *(struct ppb_data *)ppbus_devclass->devices[0]->softc
> $1 = {class_id = 0, state = 1, error = 0, mode = 0,
>   ppb_owner = 0xffffff0004668700, ppc_lock = 0xffffff0004668eb8,
>   ppc_irq_res = 0xffffff0004677900}
> (kgdb) p *(device_t)((struct 
ppb_data*)ppbus_devclass->devices[0]->softc)->ppb
> _owner
> $2 = {ops = 0xffffff0001520000, link = {tqe_next = 0xffffff0004668500,
>     tqe_prev = 0xffffff0004668908}, devlink = {tqe_next = 
0xffffff0004668500,
>     tqe_prev = 0xffffff0004668918}, parent = 0xffffff0004669000, children = 
{
>     tqh_first = 0x0, tqh_last = 0xffffff0004668730},
>   driver = 0xffffffff806961c0, devclass = 0xffffff00014f4900, unit = 0,
>   nameunit = 0xffffff0004666940 "lpt0", desc = 0xffffffff804fc110 "Printer",
>   busy = 0, state = DS_ATTACHED, devflags = 0, flags = 7, order = 0 '\0',
>   pad = 0 '\0', ivars = 0xffffff0004668800, softc = 0xffffff0004668400,
>   sysctl_ctx = {tqh_first = 0xffffff0004674180,
>     tqh_last = 0xffffff0004674288}, sysctl_tree = 0xffffff000467d480}
> (kgdb)
> 
> The driver stays in this state even after exit of 'cat' process
> (I think this was already reported):
> ~> cat monitor_info > /dev/lpt0
> /dev/lpt0: Device busy.

Ok, so the first cat works, the second one gets EBUSY?  Can you see if the 
first 'cat' process is still around?

Hmm, I think I've found it.  Due to a bug, lptclose() wasn't releasing the 
bus.

--- //depot/user/jhb/acpipci/dev/ppbus/lpt.c
+++ /home/jhb/work/p4/acpipci/dev/ppbus/lpt.c
@@ -611,11 +611,8 @@
 	int err;
 
 	ppb_lock(ppbus);
-	if (sc->sc_flags & LP_BYPASS) {
-		sc->sc_state = 0;
-		ppb_unlock(ppbus);
+	if (sc->sc_flags & LP_BYPASS)
 		goto end_close;
-	}
 
 	if ((err = lpt_request_ppbus(lptdev, PPB_WAIT|PPB_INTR)) != 0) {
 		ppb_unlock(ppbus);
@@ -635,16 +632,16 @@
 	sc->sc_state &= ~OPEN;
 	callout_stop(&sc->sc_timer);
 	ppb_wctr(ppbus, LPC_NINIT);
-	sc->sc_state = 0;
-	sc->sc_xfercnt = 0;
 
 	/*
 	 * unregistration of interrupt forced by release
 	 */
 	lpt_release_ppbus(lptdev);
-	ppb_unlock(ppbus);
 
 end_close:
+	sc->sc_state = 0;
+	sc->sc_xfercnt = 0;
+	ppb_unlock(ppbus);
 	lprintf(("closed.\n"));
 	return(0);
 }

-- 
John Baldwin
From shuvaev at physik.uni-wuerzburg.de  Tue Feb 10 13:57:22 2009
From: shuvaev at physik.uni-wuerzburg.de (Alexey Shuvaev)
Date: Tue Feb 10 13:57:29 2009
Subject: lpt stopped working
In-Reply-To: <200902101612.57922.jhb@freebsd.org>
References: <200902021643.39862.c47g@gmx.at>
	<200902091458.41637.jhb@freebsd.org>
	<20090210201447.GA1664@wep4035.physik.uni-wuerzburg.de>
	<200902101612.57922.jhb@freebsd.org>
Message-ID: <20090210215720.GA1594@wep4035.physik.uni-wuerzburg.de>

On Tue, Feb 10, 2009 at 04:12:57PM -0500, John Baldwin wrote:
> On Tuesday 10 February 2009 3:14:47 pm Alexey Shuvaev wrote:
> > Hello all!
> > 
> > [snip]
> > 
> > And this is from kgdb:
> > (kgdb) p *(struct ppb_data *)ppbus_devclass->devices[0]->softc
> > $1 = {class_id = 0, state = 1, error = 0, mode = 0,
> >   ppb_owner = 0xffffff0004668700, ppc_lock = 0xffffff0004668eb8,
> >   ppc_irq_res = 0xffffff0004677900}
> > (kgdb) p *(device_t)((struct 
> ppb_data*)ppbus_devclass->devices[0]->softc)->ppb
> > _owner
> > $2 = {ops = 0xffffff0001520000, link = {tqe_next = 0xffffff0004668500,
> >     tqe_prev = 0xffffff0004668908}, devlink = {tqe_next = 
> 0xffffff0004668500,
> >     tqe_prev = 0xffffff0004668918}, parent = 0xffffff0004669000, children = 
> {
> >     tqh_first = 0x0, tqh_last = 0xffffff0004668730},
> >   driver = 0xffffffff806961c0, devclass = 0xffffff00014f4900, unit = 0,
> >   nameunit = 0xffffff0004666940 "lpt0", desc = 0xffffffff804fc110 "Printer",
> >   busy = 0, state = DS_ATTACHED, devflags = 0, flags = 7, order = 0 '\0',
> >   pad = 0 '\0', ivars = 0xffffff0004668800, softc = 0xffffff0004668400,
> >   sysctl_ctx = {tqh_first = 0xffffff0004674180,
> >     tqh_last = 0xffffff0004674288}, sysctl_tree = 0xffffff000467d480}
> > (kgdb)
> > 
> > The driver stays in this state even after exit of 'cat' process
> > (I think this was already reported):
> > ~> cat monitor_info > /dev/lpt0
> > /dev/lpt0: Device busy.
> 
> Ok, so the first cat works, the second one gets EBUSY?
>
Mmm... I don't think the first cat really works.
It hangs, I suppose nothing goes to the wire,
and during this I got the above printigs from kgdb.

> Can you see if the first 'cat' process is still around?
> 
It is possible to kill this cat process either by kill
or just type Ctrl-C twice in the terminal where it hangs.
I don't see it in ps output thereafter.
Nevertheless the lpt returns 'Device busy'
and if I try kgdb commands again the results are the same.

> Hmm, I think I've found it.  Due to a bug, lptclose() wasn't releasing the 
> bus.
> 
> --- //depot/user/jhb/acpipci/dev/ppbus/lpt.c
> +++ /home/jhb/work/p4/acpipci/dev/ppbus/lpt.c
> @@ -611,11 +611,8 @@
>  	int err;
>  
>  	ppb_lock(ppbus);
> -	if (sc->sc_flags & LP_BYPASS) {
> -		sc->sc_state = 0;
> -		ppb_unlock(ppbus);
> +	if (sc->sc_flags & LP_BYPASS)
>  		goto end_close;
> -	}
>  
>  	if ((err = lpt_request_ppbus(lptdev, PPB_WAIT|PPB_INTR)) != 0) {
>  		ppb_unlock(ppbus);
> @@ -635,16 +632,16 @@
>  	sc->sc_state &= ~OPEN;
>  	callout_stop(&sc->sc_timer);
>  	ppb_wctr(ppbus, LPC_NINIT);
> -	sc->sc_state = 0;
> -	sc->sc_xfercnt = 0;
>  
>  	/*
>  	 * unregistration of interrupt forced by release
>  	 */
>  	lpt_release_ppbus(lptdev);
> -	ppb_unlock(ppbus);
>  
>  end_close:
> +	sc->sc_state = 0;
> +	sc->sc_xfercnt = 0;
> +	ppb_unlock(ppbus);
>  	lprintf(("closed.\n"));
>  	return(0);
>  }
> 
Just recompiled the whole kernel and tried again. The same symptoms
and almost the same kgdb output:
--- old 2009-02-10 22:42:53.000000000 +0100
+++ lpt_2       2009-02-10 22:41:20.000000000 +0100
@@ -9,9 +9,10 @@
     tqe_prev = 0xffffff0004668918}, parent = 0xffffff0004669000, children = {
     tqh_first = 0x0, tqh_last = 0xffffff0004668730},
   driver = 0xffffffff806961c0, devclass = 0xffffff00014f4900, unit = 0,
-  nameunit = 0xffffff0004666940 "lpt0", desc = 0xffffffff804fc110 "Printer",
+  nameunit = 0xffffff0004666930 "lpt0", desc = 0xffffffff804fc110 "Printer",
   busy = 0, state = DS_ATTACHED, devflags = 0, flags = 7, order = 0 '\0',
   pad = 0 '\0', ivars = 0xffffff0004668800, softc = 0xffffff0004668400,
-  sysctl_ctx = {tqh_first = 0xffffff0004674180,
-    tqh_last = 0xffffff0004674288}, sysctl_tree = 0xffffff000467d480}
+  sysctl_ctx = {tqh_first = 0xffffff0004674160,
+    tqh_last = 0xffffff0004674268}, sysctl_tree = 0xffffff000467d480}
 (kgdb)

Interesting, I get something in the dmesg about the printer:
ppbus0: <Parallel port bus> on ppc0
ppbus0: IEEE1284 device found /NIBBLE/ECP
ppbus0: Probing for PnP devices:
ppbus0: <HEWLETT-PACKARD OFFICEJET R60> PRINTER MLC,PCL,PML,SCL

AFAIK the second core is not launched at this moment (and yes, I am on
a dual-core machine :).

Just some thoughts,
Alexey.
From jhb at freebsd.org  Tue Feb 10 14:34:30 2009
From: jhb at freebsd.org (John Baldwin)
Date: Tue Feb 10 14:34:37 2009
Subject: lpt stopped working
In-Reply-To: <20090210215720.GA1594@wep4035.physik.uni-wuerzburg.de>
References: <200902021643.39862.c47g@gmx.at>
	<200902101612.57922.jhb@freebsd.org>
	<20090210215720.GA1594@wep4035.physik.uni-wuerzburg.de>
Message-ID: <200902101734.10365.jhb@freebsd.org>

On Tuesday 10 February 2009 4:57:20 pm Alexey Shuvaev wrote:
> On Tue, Feb 10, 2009 at 04:12:57PM -0500, John Baldwin wrote:
> > Ok, so the first cat works, the second one gets EBUSY?
> >
> Mmm... I don't think the first cat really works.
> It hangs, I suppose nothing goes to the wire,
> and during this I got the above printigs from kgdb.
> 
> > Hmm, I think I've found it.  Due to a bug, lptclose() wasn't releasing the 
> > bus.

Grr, lptopen() was also busted.  The old lpt driver didn't actually check the 
HAVEBUS flag in lpt_release_ppbus() which masked the bugs in lptopen().  Try 
this:

--- //depot/vendor/freebsd/src/sys/dev/ppbus/lpt.c	2009/01/26 21:00:15
+++ //depot/user/jhb/acpipci/dev/ppbus/lpt.c	2009/02/10 22:32:11
@@ -544,10 +544,10 @@
 	do {
 		/* ran out of waiting for the printer */
 		if (trys++ >= LPINITRDY*4) {
-			sc->sc_state = 0;
 			lprintf(("status %x\n", ppb_rstr(ppbus)));
 
 			lpt_release_ppbus(lptdev);
+			sc->sc_state = 0;
 			ppb_unlock(ppbus);
 			return (EBUSY);
 		}
@@ -555,9 +555,8 @@
 		/* wait 1/4 second, give up if we get a signal */
 		if (ppb_sleep(ppbus, lptdev, LPPRI | PCATCH, "lptinit",
 		    hz / 4) != EWOULDBLOCK) {
+			lpt_release_ppbus(lptdev);
 			sc->sc_state = 0;
-
-			lpt_release_ppbus(lptdev);
 			ppb_unlock(ppbus);
 			return (EBUSY);
 		}
@@ -577,7 +576,8 @@
 
 	ppb_wctr(ppbus, sc->sc_control);
 
-	sc->sc_state = OPEN;
+	sc->sc_state &= ~LPTINIT;
+	sc->sc_state |= OPEN;
 	sc->sc_xfercnt = 0;
 
 	/* only use timeout if using interrupt */
@@ -611,11 +611,8 @@
 	int err;
 
 	ppb_lock(ppbus);
-	if (sc->sc_flags & LP_BYPASS) {
-		sc->sc_state = 0;
-		ppb_unlock(ppbus);
+	if (sc->sc_flags & LP_BYPASS)
 		goto end_close;
-	}
 
 	if ((err = lpt_request_ppbus(lptdev, PPB_WAIT|PPB_INTR)) != 0) {
 		ppb_unlock(ppbus);
@@ -635,16 +632,16 @@
 	sc->sc_state &= ~OPEN;
 	callout_stop(&sc->sc_timer);
 	ppb_wctr(ppbus, LPC_NINIT);
-	sc->sc_state = 0;
-	sc->sc_xfercnt = 0;
 
 	/*
 	 * unregistration of interrupt forced by release
 	 */
 	lpt_release_ppbus(lptdev);
-	ppb_unlock(ppbus);
 
 end_close:
+	sc->sc_state = 0;
+	sc->sc_xfercnt = 0;
+	ppb_unlock(ppbus);
 	lprintf(("closed.\n"));
 	return(0);
 }


-- 
John Baldwin
From nox at jelal.kn-bremen.de  Tue Feb 10 15:53:53 2009
From: nox at jelal.kn-bremen.de (Juergen Lock)
Date: Tue Feb 10 16:05:10 2009
Subject: uart(4) not working in QEMU
In-Reply-To: <49910C3D.90709@incunabulum.net>
Message-ID: <200902102321.n1ANLjG2014508@saturn.kn-bremen.de>

In article <49910C3D.90709@incunabulum.net> you write:
>Hi,
>
>I have been trying to test my kernel code in QEMU as it saves a lot of 
>time and effort.
>However, I have noticed since returning to my current project, that 
>sio(4) was deprecated in favour of uart(4).
>
>Whilst I updated my kernel configs to reflect this, I've noticed a lot 
>of problems with I/O and QEMU -- in particular, the kernel will log 
>messages over uart(4) just fine, but when the kernel runs init, I can't 
>get any I/O out of the uart(4) at all, apart from a single 'c' or 'F' 
>character.
>
>The kernel continues to log messages OK to the uart0/ttyu0 device 
>regardless of what's going on in userland.
>
>If I configure ttyv0 in the QEMU virtual machine up via /etc/ttys to run 
>a getty there, I can get in, and see that the getty for ttyu0 is 
>running. However, echo'ing or cat'ing data to /dev/ttyu0 won't work, 
>even if I kill the getty process first. I just don't see anything 
>appearing in my QEMU serial console.
>
>I've tried a lot of combinations of 3wire.115200 vs std.9600, 
>boot.config options, loader.conf options, none of which have solved the 
>problem (mostly working from the threads on this list from when the 
>changes were made).
>
>I have also tried other bindings for the QEMU serial device -- e.g. tcp 
>ports, nmdm(4), and always see the same effects.   I do have INVARIANTS 
>enabled -- could this be an issue?

I dunno if INVARIANTS changes the behaviour of the uart driver (my guess
is it doesn't), but I see there have been commits to qemu's hw/serial.c
since the versions in ports so you could try a more recent svn snapshot
like the one posted here:
	http://lists.freebsd.org/pipermail/freebsd-emulation/2009-February/005650.html

 If that doesn't help and you feel like debugging this maybe uncommenting
the DEBUG_SERIAL #define in hw/serial.c helps...

 Good luck,
	Juergen
From shuvaev at physik.uni-wuerzburg.de  Tue Feb 10 16:07:44 2009
From: shuvaev at physik.uni-wuerzburg.de (Alexey Shuvaev)
Date: Tue Feb 10 16:07:51 2009
Subject: lpt stopped working
In-Reply-To: <200902101734.10365.jhb@freebsd.org>
References: <200902021643.39862.c47g@gmx.at>
	<200902101612.57922.jhb@freebsd.org>
	<20090210215720.GA1594@wep4035.physik.uni-wuerzburg.de>
	<200902101734.10365.jhb@freebsd.org>
Message-ID: <20090211000741.GA1625@wep4035.physik.uni-wuerzburg.de>

On Tue, Feb 10, 2009 at 05:34:10PM -0500, John Baldwin wrote:
> On Tuesday 10 February 2009 4:57:20 pm Alexey Shuvaev wrote:
> > On Tue, Feb 10, 2009 at 04:12:57PM -0500, John Baldwin wrote:
> > > Ok, so the first cat works, the second one gets EBUSY?
> > >
> > Mmm... I don't think the first cat really works.
> > It hangs, I suppose nothing goes to the wire,
> > and during this I got the above printigs from kgdb.
> > 
> > > Hmm, I think I've found it.  Due to a bug, lptclose() wasn't releasing the 
> > > bus.
> 
> Grr, lptopen() was also busted.  The old lpt driver didn't actually check the 
> HAVEBUS flag in lpt_release_ppbus() which masked the bugs in lptopen().  Try 
> this:
> 
> --- //depot/vendor/freebsd/src/sys/dev/ppbus/lpt.c	2009/01/26 21:00:15
> +++ //depot/user/jhb/acpipci/dev/ppbus/lpt.c	2009/02/10 22:32:11
> @@ -544,10 +544,10 @@
>  	do {
>  		/* ran out of waiting for the printer */
>  		if (trys++ >= LPINITRDY*4) {
> -			sc->sc_state = 0;
>  			lprintf(("status %x\n", ppb_rstr(ppbus)));
>  
>  			lpt_release_ppbus(lptdev);
> +			sc->sc_state = 0;
>  			ppb_unlock(ppbus);
>  			return (EBUSY);
>  		}
> @@ -555,9 +555,8 @@
>  		/* wait 1/4 second, give up if we get a signal */
>  		if (ppb_sleep(ppbus, lptdev, LPPRI | PCATCH, "lptinit",
>  		    hz / 4) != EWOULDBLOCK) {
> +			lpt_release_ppbus(lptdev);
>  			sc->sc_state = 0;
> -
> -			lpt_release_ppbus(lptdev);
>  			ppb_unlock(ppbus);
>  			return (EBUSY);
>  		}
> @@ -577,7 +576,8 @@
>  
>  	ppb_wctr(ppbus, sc->sc_control);
>  
> -	sc->sc_state = OPEN;
> +	sc->sc_state &= ~LPTINIT;
> +	sc->sc_state |= OPEN;
>  	sc->sc_xfercnt = 0;
>  
>  	/* only use timeout if using interrupt */
> @@ -611,11 +611,8 @@
>  	int err;
>  
>  	ppb_lock(ppbus);
> -	if (sc->sc_flags & LP_BYPASS) {
> -		sc->sc_state = 0;
> -		ppb_unlock(ppbus);
> +	if (sc->sc_flags & LP_BYPASS)
>  		goto end_close;
> -	}
>  
>  	if ((err = lpt_request_ppbus(lptdev, PPB_WAIT|PPB_INTR)) != 0) {
>  		ppb_unlock(ppbus);
> @@ -635,16 +632,16 @@
>  	sc->sc_state &= ~OPEN;
>  	callout_stop(&sc->sc_timer);
>  	ppb_wctr(ppbus, LPC_NINIT);
> -	sc->sc_state = 0;
> -	sc->sc_xfercnt = 0;
>  
>  	/*
>  	 * unregistration of interrupt forced by release
>  	 */
>  	lpt_release_ppbus(lptdev);
> -	ppb_unlock(ppbus);
>  
>  end_close:
> +	sc->sc_state = 0;
> +	sc->sc_xfercnt = 0;
> +	ppb_unlock(ppbus);
>  	lprintf(("closed.\n"));
>  	return(0);
>  }
> 
Seems to work!
No messages in the console, like "interrupt storm", too.
Thanks!

Alexey.
From sean.bruno at dsl-only.net  Tue Feb 10 17:23:14 2009
From: sean.bruno at dsl-only.net (Sean Bruno)
Date: Tue Feb 10 17:23:23 2009
Subject: [sysctl] New sysctl LoR today
Message-ID: <1234315393.14556.6.camel@localhost.localdomain>

I'm working on some items in the firewire stack and after a update, I
was greeted with a new LoR against the SYSCTL lock.  I noted that some
things were changing in that space.

Did I miss an interface change that I need to pickup in the firewire
stack?

Sean

lock order reversal: (sleepable after non-sleepable)
 1st 0xc471bbec sbp (sbp) @ dev/firewire/sbp.c:2253
 2nd 0xc0d3aea4 sysctl lock (sysctl lock) @ kern/kern_sysctl.c:250
KDB: stack backtrace:
db_trace_self_wrapper(c0be8361,c42aa328,c087a355,4,c0be39e8,...) at
db_trace_self_wrapper+0x26
kdb_backtrace(4,c0be39e8,c4524e00,c4521ad0,c42aa384,...) at
kdb_backtrace+0x29
_witness_debugger(c0beb056,c0d3aea4,c0be5e30,c4521ad0,c0be5d4f,...) at
_witness_debugger+0x25
witness_checkorder(c0d3aea4,9,c0be5d46,fa,0,...) at witness_checkorder
+0x839
_sx_xlock(c0d3aea4,0,c0be5d46,fa,c471a000,...) at _sx_xlock+0x85
sysctl_ctx_free(c471a2c0,c0b8f786,c0d0696c,0,c469fa0c,...) at
sysctl_ctx_free+0x30
dacleanup(c4c54700,c0b900bb,c480e000,c42aa410,246,...) at dacleanup+0x35
camperiphfree(c4c54700,c4c54700,c42aa694,c047763d,c4c54700,...) at
camperiphfree+0xc2
cam_periph_invalidate(c4c54700,c0bb6c60,c42aa6c8,c048ba73,c4c54700,...)
at cam_periph_invalidate+0x3e
cam_periph_async(c4c54700,100,c4a03450,0,c480e000,c42aa70c,c087ada8,c480e0a4,c0e7b688,c0ccf6a4) at cam_periph_async+0x2d
daasync(c4c54700,100,c4a03450,0,c4a26000,...) at daasync+0xf3
xpt_async_bcast(0,4,c0b88347,117f,c4736500,...) at xpt_async_bcast+0x32
xpt_async(100,c4a03450,0,8cd,0,...) at xpt_async+0x194
sbp_cam_detach_sdev(c471bbec,0,c0bb6c57,333,1,...) at
sbp_cam_detach_sdev+0xa4
sbp_post_explore(c471b800,c42aaca4,c42aaca0,1,3,...) at sbp_post_explore
+0xed9
fw_bus_probe_thread(c472f000,c42aad38,c0be11ff,32d,c472ea90,...) at
fw_bus_probe_thread+0x88b
fork_exit(c0636be0,c472f000,c42aad38) at fork_exit+0xb8
fork_trampoline() at fork_trampoline+0x8
--- trap 0, eip = 0, esp = 0xc42aad70, ebp = 0 ---


From chris at young-alumni.com  Tue Feb 10 18:52:33 2009
From: chris at young-alumni.com (Chris Ruiz)
Date: Tue Feb 10 18:52:40 2009
Subject: fwohci0: panic: blockable sleep lock (sleep mutex ) Giant @
	/usr/src/sys/dev/kbdmux/kbdmux.c:1103
Message-ID: <A1D83E0F-7253-45F8-9080-D92577BFCFDC@young-alumni.com>



After 11 days of uptime, I typed 'fwcontrol -p' from a ssh session and  
my system rebooted.  This is all the information I could obtain.   
After reboot, fwcontrol did not cause another panic.  I do no have any  
swap nor did I get a chance to enter the debugger before the reboot.   
I'm currently in the process of updating to 188474 and will report  
back if this happens again.

kernel:

FreeBSD attack.young-alumni.com 8.0-CURRENT FreeBSD 8.0-CURRENT #0  
r187913M: Fri Jan 30 05:35:09 CST 2009     root@attack.young- 
alumni.com:/usr/obj/usr/src/sys/FAILWHALE  amd64

panic message:

Feb 10 20:24:50 attack kernel: fwohci0: panic: blockable sleep lock  
(sleep mutex
) Giant @ /usr/src/sys/dev/kbdmux/kbdmux.c:1103panic: panic: panic:  
panic: panic
: panic: panic: panic: panic: panic: panic: panic: panic: panic:  
panic: panic: p
anic: panic: panic: panic: panic: panic: panic: panic: panic: panic:  
panic: pani
c: panic: panic: panic: panic: panic: panic: panic: panic: panic:  
panic: panic:
panic: panic: panic: panic: panic: panic: panic: panic: panic: panic:  
panic: pan
ic: panic: panic: panic: panic: panic: panic: panic: panic: panic:  
panic: panic:
  panic: panic: panic: panic: panic: panic: panic: panic: panic:  
panic: panic: pa
nic: panic: panic: panic: panic: panic: panic: panic: panic: panic:  
panic: panic
: panic: panic: panic: panic: panic: panic: panic: panic: panic:  
panic: panic: p
anic: panic: panic: panic: panic: panic: panic: panic: panic: panic:  
panic: pani
c: panic: panic: panic: panic: panic: panic: panic: panic: panic:  
panic: panic:
panic: panic: panic: panic: panic: panic: panic: panic: panic: panic:  
panic: pan
ic: pan
Feb 10 20:24:50 attack kernel: c: panic: panic: panic: panic: panic:  
panic: pani
c: panic: panic: panic: panic: panic: panic: panic: panic: panic:  
panic: panic:
panic: panic: panic: panic: panic: panic: panic: panic: panic: panic:  
panic: pan
ic: panic: panic: panic: panic: panic: panic: panic: panic: panic:  
panic: panic:
  panic: panic: panic: panic: panic: panic: panic: panic: panic:  
panic: panic: pa
nic: panic: panic: panic: panic: panic: panic: panic: panic: panic:  
panic: panic
: panic: panic: panic: panic: panic: panic: panic: panic: panic:  
panic: panic: p
anic: panic: panic: panic: panic: panic: panic: panic: panic: panic:  
panic: pani
c: panic: panic: panic: panic: panic: panic: panic: panic: panic:  
panic: panic:
panic: panic: panic: panic: panic: panic: panic: panic: panic: panic:  
panic: pan
ic: panic: panic: panic: panic: panic: panic: panic: panic: panic:  
panic: panic:
  panic: panic: panic: panic: panic: panic: panic: panic: panic:  
panic: panic: pa
nic: panic: panic: panic: panic: panic: panic: panic: panic: panic:  
panic: panic
: panic
Feb 10 20:24:50 attack kernel: panic: panic: panic: panic: panic:  
panic: panic:
panic: panic: panic: panic: panic: panic: panic: panic: panic: panic:  
panic: pan
ic: panic: panic: panic: panic: panic: panic: panic: panic: panic:  
panic: panic:
  panic: panic: panic: panic: panic: panic: panic: panic: panic:  
panic: panic: pa
nic: panic: panic: panic: panic: panic: panic: panic: panic: panic:  
panic: panic
: panic: panic: panic: panic: panic: panic: panic: panic: panic:  
panic: panic: p
anic: panic: panic: panic: panic: panic: panic: panic: panic: panic:  
panic: pani
c: panic: panic: panic: panic: panic: panic: panic: panic: panic:  
panic: panic:
panic: panic: panic: panic: panic: panic: panic: panic: panic: panic:  
panic: pan
ic: panic: panic: panic: panic: panic: panic: panic: panic: panic:  
panic: panic:
  panic: panic: panic: panic: panic: panic: panic: panic: panic:  
panic: panic: pa
nic: panic: panic: panic: panic: panic: panic: panic: panic: panic:  
panic: panic
: panic: panic: panic: panic: panic: panic: panic: panic: panic:  
panic: panic: p
anic: p
Feb 10 20:24:50 attack kernel: panic: panic: panic: panic: panic:  
panic: panic:
panic: panic: panic: panic: panic: panic: panic: panic: panic: panic:  
panic: pan
ic: panic: panic: panic: panic: panic: panic: panic: panic: panic:  
panic: panic:
  panic: panic: p4

- Chris
From delphij at delphij.net  Tue Feb 10 19:24:41 2009
From: delphij at delphij.net (Xin LI)
Date: Tue Feb 10 19:24:54 2009
Subject: [RFC] Skeleton jail (rc.d feature proposal)
Message-ID: <499244E6.9030205@delphij.net>

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

Hi,

Ok, some local users has prodded me in committing the "skeleton jail"
feature, I find it useful myself but not sure if it's appropriate to
commit it against -HEAD, so I'd like to explain it, try to present it in
a better way, and request for comments.  I'd like to have some native
English speakers to proof read the manual page changes if this is found
useful for general consumption.

Some descriptions:

=====

What is it?

Basically, a "skeleton" jail is a jail which has part of its
directories, typically directories containing the base system, say the
binaries, libraries, mount_nullfs'ed from a template, usually /.  What I
did implemented is some helper scripts as well as some Makefile changes
to make the task easier.

A NULLFS mount, typically, read-only, from either a template (an
installed world located in some directory, or the host system, say, /
itself), would reduce the time that is taken upon system upgrade; on the
other hand, it makes it possible to switch the base system libraries
on-the-fly.  The read-only nature of these NULLFS mounts also helps
development environments that don't want programmers to make
unauthorized changes to the base system itself, we actually have used it
in our development environment and found this as an useful side effect.

=====

How to use it?

One make(1) target, "installskel" has been added to top-level (/usr/src)
Makefile.  This can be used to populate a skeleton where only a minimal
set of files and directories are installed that will support the startup
of a skeleton jail.  "installskel" is actually a shortcut of "make
hierarchy" and "cd etc; make distribution".

So, to create a skeleton:

	cd /usr/src
	make installskel DESTDIR=$D

Where "D" is the directory where you want the skeleton to be placed at,
say, /vhost/myjail in this example; then, set up rc.conf(5) parameters
like this:

	jail_myjail_rootdir="/vhost/myjail/"
	jail_myjail_devfs_enable="YES"
	jail_myjail_skel_enable="YES"

The rc.d infrastructure would automatically mount the following
directories from the template (when not specified, /) as read-only:

	bin
	lib
	libexec
	sbin
	usr/bin
	usr/include
	usr/lib
	usr/libdata
	usr/libexec
	usr/sbin
	usr/share
	usr/src
	usr/obj

Cheers,
- --
Xin LI <delphij@delphij.net>	http://www.delphij.net/
FreeBSD - The Power to Serve!
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.10 (FreeBSD)

iEYEARECAAYFAkmSROUACgkQi+vbBBjt66DncwCguU5YAytGEhvwMGbLzk0uFqkI
lKEAn3RhVNxIF4XROQj0ijWyEsZgP+IJ
=Sd9e
-----END PGP SIGNATURE-----
-------------- next part --------------
Index: Makefile
===================================================================
--- Makefile	????????? 188424???
+++ Makefile	??????????????????
@@ -84,6 +84,7 @@
 	depend distribute distributeworld distrib-dirs distribution doxygen \
 	everything hierarchy install installcheck installkernel \
 	installkernel.debug reinstallkernel reinstallkernel.debug \
+	installskel \
 	installworld kernel-toolchain libraries lint maninstall \
 	obj objlink regress rerelease showconfig tags toolchain update \
 	_worldtmp _legacy _bootstrap-tools _cleanobj _obj \
@@ -98,6 +99,7 @@
 .ORDER: buildworld installworld
 .ORDER: buildworld distributeworld
 .ORDER: buildworld buildkernel
+.ORDER: buildworld installskel
 .ORDER: buildkernel installkernel
 .ORDER: buildkernel installkernel.debug
 .ORDER: buildkernel reinstallkernel
Index: Makefile.inc1
===================================================================
--- Makefile.inc1	????????? 188424???
+++ Makefile.inc1	??????????????????
@@ -651,6 +651,18 @@
 	    ${IMAKEENV} rm -rf ${INSTALLTMP}
 
 #
+# installskel
+#
+# Installs a minimum set of files that can support a mini-jail
+#
+installskel:
+	@echo "--------------------------------------------------------------"
+	@echo ">>> Making installskel"
+	@echo "--------------------------------------------------------------"
+	${_+_}cd ${.CURDIR}; ${MAKE} hierarchy
+	${_+_}cd ${.CURDIR}/etc; ${MAKE} distribution
+
+#
 # reinstall
 #
 # If you have a build server, you can NFS mount the source and obj directories
Index: etc/defaults/rc.conf
===================================================================
--- etc/defaults/rc.conf	????????? 188424???
+++ etc/defaults/rc.conf	??????????????????
@@ -611,6 +611,11 @@
 jail_set_hostname_allow="YES" # Allow root user in a jail to change its hostname
 jail_socket_unixiproute_only="YES" # Route only TCP/IP within a jail
 jail_sysvipc_allow="NO"	# Allow SystemV IPC use from within a jail
+jail_skel_enable="NO"	# Whether to globally enable "skel" jail
+jail_skel_root="/"	# The root directory for skel template
+jail_skel_romounts="bin lib libexec sbin usr/bin usr/include usr/lib usr/libdata usr/libexec usr/sbin usr/share usr/src usr/obj"
+			# Read-only nullfs mounts from the template
+jail_skel_rwmounts=""	# Read-write nullfs mounts from the template
 
 #
 # To use rc's built-in jail infrastructure create entries for
@@ -640,6 +645,11 @@
 #jail_example_mount_enable="NO"			# mount/umount jail's fs
 #jail_example_fstab=""				# fstab(5) for mount/umount
 #jail_example_flags="-l -U root"		# flags for jail(8)
+#jail_example_skel_enable="NO"			# Whether to enable "skel" jail
+#jail_example_skel_root="/"			# The root directory for skel template
+#jail_example_skel_romounts="bin lib libexec sbin usr/bin usr/include usr/lib usr/libdata usr/libexec usr/sbin usr/share usr/src usr/obj usr/ports"
+						# Read-only nullfs mounts from the template
+#jail_example_skel_rwmounts=""			# Read-write nullfs mounts from the template
 
 ##############################################################
 ### Define source_rc_confs, the mechanism used by /etc/rc.* ##
Index: etc/rc.d/jail
===================================================================
--- etc/rc.d/jail	????????? 188424???
+++ etc/rc.d/jail	??????????????????
@@ -85,6 +85,16 @@
 	[ -z "${_consolelog}" ] && _consolelog="/var/log/jail_${_j}_console.log"
 	eval _fib=\"\${jail_${_j}_fib:-${jail_fib}}\"
 
+	# Default settings for skel jail
+	eval _skel_enable=\"\${jail_${_j}_skel_enable:-${jail_skel_enable}}\"
+	[ -z "${_skel_enable}" ] && _skel_enable="NO"
+	eval _skel_root=\"\${jail_${_j}_skel_root:-${jail_skel_root}}\"
+	[ -z "${_skel_root}" ] && _skel_root="/"
+	eval _skel_romounts=\"\${jail_${_j}_skel_romounts:-${jail_skel_romounts}}\"
+	[ -z "${_skel_romounts}" ] && _skel_romounts="bin lib libexec sbin usr/bin usr/include usr/lib usr/libdata usr/libexec usr/sbin usr/share usr/src usr/obj"
+	eval _skel_rwmounts=\"\${jail_${_j}_skel_rwmounts:-${jail_skel_rwmounts}}\"
+	[ -z "${_skel_rwmounts}" ] && _skel_rwmounts=""
+
 	# Debugging aid
 	#
 	debug "$_j devfs enable: $_devfs"
@@ -120,6 +130,10 @@
 	debug "$_j exec stop: $_exec_stop"
 	debug "$_j flags: $_flags"
 	debug "$_j consolelog: $_consolelog"
+	debug "$_j skel enable: $_skel_enable"
+	debug "$_j skel mount-readonly: $_skel_romounts"
+	debug "$_j skel mount-readwrite: $_skel_rwmounts"
+	debug "$_j skel mount skeleton from: $_skel_root"
 
 	if [ -z "${_hostname}" ]; then
 		err 3 "$name: No hostname has been defined for ${_j}"
@@ -241,6 +255,14 @@
 			secure_umount ${_mountpt}
 		done
 	fi
+	if checkyesno _skel_enable; then
+		for _mntpt in ${_skel_romounts} ${_skel_rwmounts}
+		do
+			if [ -d "${_rootdir}/${_mntpt}" ] ; then
+				umount -f ${_rootdir}/${_mntpt} > /dev/null 2>&1
+			fi
+		done
+	fi
 }
 
 # jail_mount_fstab()
@@ -509,6 +531,17 @@
 			fi
 			jail_mount_fstab
 		fi
+		if checkyesno _skel_enable; then
+			info "Mounting skeleton for jail ${_jail} from ${_skel_root}"
+			for _mntpt in $_skel_rwmounts
+			do
+				mount_nullfs ${_skel_root}/${_mntpt} ${_rootdir}/${_mntpt} > /dev/null 2>&1
+			done
+			for _mntpt in $_skel_romounts
+			do
+				mount_nullfs -ordonly ${_skel_root}/${_mntpt} ${_rootdir}/${_mntpt} > /dev/null 2>&1
+			done
+		fi
 		if checkyesno _devfs; then
 			# If devfs is already mounted here, skip it.
 			df -t devfs "${_devdir}" >/dev/null
Index: share/man/man5/rc.conf.5
===================================================================
--- share/man/man5/rc.conf.5	????????? 188424???
+++ share/man/man5/rc.conf.5	??????????????????
@@ -24,7 +24,7 @@
 .\"
 .\" $FreeBSD$
 .\"
-.Dd January 27, 2009
+.Dd February 10, 2009
 .Dt RC.CONF 5
 .Os
 .Sh NAME
@@ -3413,6 +3413,46 @@
 .Va jail_ Ns Ao Ar jname Ac Ns Va _exec_stop
 for every jail in
 .Va jail_list .
+.It Va jail_skel_enable
+.Pq Vt bool
+Set to
+.Dq Li NO
+by default.
+When set to
+.Dq Li YES ,
+sets
+.Va jail_ Ns Ao Ar jname Ac Ns Va _skel_enable
+to
+.Dq Li YES
+by default for every jail in
+.Va jail_list .
+.It Va jail_skel_root
+.Pq Vt str
+Set to
+.Dq Li /
+by default.
+When set, use as default value for
+.Va jail_ Ns Ao Ar jname Ac Ns Va _skel_root
+for every jail in
+.Va jail_list .
+.It Va jail_skel_romount
+.Pq Vt str
+Set to
+.Dq Li bin lib libexec sbin usr/bin usr/include usr/lib usr/libdata usr/libexec usr/sbin usr/share usr/src usr/obj
+by default.
+When set, use as default value for
+.Va jail_ Ns Ao Ar jname Ac Ns Va _skel_romount
+for every jail in
+.Va jail_list .
+.It Va jail_skel_rwmount
+.Pq Vt str
+Set to empty by default.
+When set, use as default value for
+.Va jail_ Ns Ao Ar jname Ac Ns Va _skel_rwmount
+for every jail in
+.Va jail_list .
 .It Va jail_ Ns Ao Ar jname Ac Ns Va _rootdir
 .Pq Vt str
 Unset by default.
@@ -3549,6 +3589,38 @@
 .Dq Li /bin/sh /etc/rc.shutdown
 by default.
 This is the command executed at jail shutdown.
+.It Va jail_ Ns Ao Ar jname Ac Ns Va _skel_enable
+.Pq Vt bool
+Set to
+.Dq Li NO
+by default.
+When set to
+.Dq Li YES ,
+enable the skeleton jail, which
+.Xr mount_nullfs 8
+two lists of filesystems, one of which lists read-only,
+another lists read-write as specified by the administrator,
+relative to the template root, into inside jail
+.Ar jname
+respectively, at jail startup.
+.It Va jail_ Ns Ao Ar jname Ac Ns Va _skel_root
+.Pq Vt str
+Set to
+.Dq Li /
+by default.
+Specifies the root directory that a skeleton template is based on.
+.It Va jail_ Ns Ao Ar jname Ac Ns Va _skel_romounts
+.Pq Vt str
+Specifies a list of directories that is expected to be mounted from
+the skeleton template, into inside jail
+.Ar jname ,
+as read-only.
+.It Va jail_ Ns Ao Ar jname Ac Ns Va _skel_rwmounts
+.Pq Vt str
+Specifies a list of directories that is expected to be mounted from
+the skeleton template, into inside jail
+.Ar jname ,
+as read-write.
 .It Va jail_set_hostname_allow
 .Pq Vt bool
 If set to
Index: usr.sbin/jail/jail.8
===================================================================
--- usr.sbin/jail/jail.8	????????? 188424???
+++ usr.sbin/jail/jail.8	??????????????????
@@ -412,6 +412,46 @@
 /etc/rc.d/jail start myjail
 /etc/rc.d/jail stop myjail
 .Ed
+.Ss "Setting up a Jail from a template directory"
+A so-called skeleton jail, is an environment where part of its
+directories comes from
+.Xr mount_nullfs 8
+from a template directory.
+.Pp
+Such setup can save the time for the administrator because it makes
+it possible to share certain binaries and libraries between several
+jails, as well as easy experimenting different releases of the
+operating system libraries by switching template directories.
+Also, this type of setup would save certain amount of disk space.
+.Pp
+A template directory can be populated with
+.Dq "make world" ,
+or, the host system environment
+.Aq Dq "/" ,
+can be used as well.
+.Pp
+To set up a jail directory tree containing the jail, one can use
+the following
+.Xr sh 1
+command script:
+.Bd -literal
+D=/here/is/the/jail
+cd /usr/src
+mkdir -p $D
+make installskel DESTDIR=$D
+.Ed
+.Pp
+One should explicitly specify that the jail is skeleton jail, by
+either enabling the global flag
+.Dq jail_skel_enable ,
+or the per-jail flag
+.Dq Va jail_ Ns Ao Ar jname Ac Ns Va _skel_enable
+in 
+.Xr rc.conf 5
+configuration.  The system supplied a set of defaults that is
+useful for typical setup, and is tweakable through several variables
+as described in
+.Xr rc.conf 5 .
 .Ss "Managing the Jail"
 Normal machine shutdown commands, such as
 .Xr halt 8 ,
From delphij at delphij.net  Tue Feb 10 19:53:05 2009
From: delphij at delphij.net (Xin LI)
Date: Tue Feb 10 19:53:16 2009
Subject: [RFC] Skeleton jail (rc.d feature proposal)
In-Reply-To: <499246D4.8020908@freebsd.org>
References: <499244E6.9030205@delphij.net> <499246D4.8020908@freebsd.org>
Message-ID: <49924B92.6050307@delphij.net>

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

Lawrence Stewart wrote:
> Xin LI wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> Hi,
>>
>> Ok, some local users has prodded me in committing the "skeleton jail"
> 
> [snip]
> 
> Can you describe how this differs from the functionality provided by the
> ezjail port? (/usr/ports/sysutils/ezjail/)

I think they have different targets.  Skeleton jail is more lightweight
which is only very few lines of changes to the base system (i.e. the aim
is to provide convenient shortcut for common tasks, not to be a complete
solution); the functionality provided by skeleton jail, on the other
hand, could be useful building blocks to ezjail.

Cheers,
- --
Xin LI <delphij@delphij.net>	http://www.delphij.net/
FreeBSD - The Power to Serve!
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.10 (FreeBSD)

iEYEARECAAYFAkmSS5EACgkQi+vbBBjt66D4NQCfSL6g+UgptFPEAnea7HBjDZU4
/30AnAkF7eJU1/v6gD+irFrdO/aaLZvS
=spnz
-----END PGP SIGNATURE-----
From lists at mawer.org  Tue Feb 10 19:16:11 2009
From: lists at mawer.org (Antony Mawer)
Date: Tue Feb 10 19:55:02 2009
Subject: CFT: Graphics support for /boot/loader
In-Reply-To: <200902100908.n1A989IJ034744@lurza.secnetix.de>
References: <200902100908.n1A989IJ034744@lurza.secnetix.de>
Message-ID: <49923B2F.2080804@mawer.org>

Oliver Fromme wrote:
> Also take into account that this is "only" a boot screen.
> Most people will see it only for a few seconds.
> 
> Regarding your question about VGA modes:
> 
> Standard VGA supports at most 640x480 at 4 bits and 320x200
> at 8 bits.  So that's the common denominator.

Hi Oliver,

Do you know if it would be hard to modify splash(4) to supports 640x480 
4-bit images? At the moment, according to the man page:

   "If the standard VGA video mode is used, the size of the bitmap must
    be 320x200 or less."

I would find a 640x480 image with a custom 16 colour palette and 
appropriate dithering much more attractive than the current 320x200 but 
with 256 colours offering (ignoring VESA, which seems to have varied 
levels of support).

At the moment, a 640x480 4-bit image is just gives me a blank screen 
unless I load the VESA module (and on a VESA capable machine)

If you have any suggestions then I am willing to try patches!

Cheers
Antony
From lstewart at freebsd.org  Tue Feb 10 19:56:46 2009
From: lstewart at freebsd.org (Lawrence Stewart)
Date: Tue Feb 10 19:56:53 2009
Subject: [RFC] Skeleton jail (rc.d feature proposal)
In-Reply-To: <499244E6.9030205@delphij.net>
References: <499244E6.9030205@delphij.net>
Message-ID: <499246D4.8020908@freebsd.org>

Xin LI wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Hi,
> 
> Ok, some local users has prodded me in committing the "skeleton jail"

[snip]

Can you describe how this differs from the functionality provided by the 
ezjail port? (/usr/ports/sysutils/ezjail/)

Cheers,
Lawrence


From sean.bruno at dsl-only.net  Tue Feb 10 20:14:14 2009
From: sean.bruno at dsl-only.net (Sean Bruno)
Date: Tue Feb 10 20:14:21 2009
Subject: fwohci0: panic: blockable sleep lock (sleep mutex ) Giant @
 /usr/src/sys/dev/kbdmux/kbdmux.c:1103
In-Reply-To: <A1D83E0F-7253-45F8-9080-D92577BFCFDC@young-alumni.com>
References: <A1D83E0F-7253-45F8-9080-D92577BFCFDC@young-alumni.com>
Message-ID: <1234325652.14556.9.camel@localhost.localdomain>

On Tue, 2009-02-10 at 20:48 -0600, Chris Ruiz wrote:
> 
> After 11 days of uptime, I typed 'fwcontrol -p' from a ssh session and  
> my system rebooted.  This is all the information I could obtain.   
> After reboot, fwcontrol did not cause another panic.  I do no have any  
> swap nor did I get a chance to enter the debugger before the reboot.   
> I'm currently in the process of updating to 188474 and will report  
> back if this happens again.
> 


Ah ... finally, an AMD64 reporter.  <grins evilly>

Let's break this down a bit, what Firewire card do you have(pciconf -lv)

What Firewire device was attached to the box?

What is the output of "fwcontrol -p" and "fwcontrol"?

Also, let's move this over to freebsd-firewire for the time being.

Sean

From sean.bruno at dsl-only.net  Tue Feb 10 22:09:30 2009
From: sean.bruno at dsl-only.net (Sean Bruno)
Date: Tue Feb 10 22:09:37 2009
Subject: [sysctl] New sysctl LoR today
In-Reply-To: <1234315393.14556.6.camel@localhost.localdomain>
References: <1234315393.14556.6.camel@localhost.localdomain>
Message-ID: <1234332568.14556.11.camel@localhost.localdomain>

On Tue, 2009-02-10 at 17:23 -0800, Sean Bruno wrote:
> I'm working on some items in the firewire stack and after a update, I
> was greeted with a new LoR against the SYSCTL lock.  I noted that some
> things were changing in that space.
> 
> Did I miss an interface change that I need to pickup in the firewire
> stack?
> 
> Sean
> 
> lock order reversal: (sleepable after non-sleepable)
>  1st 0xc471bbec sbp (sbp) @ dev/firewire/sbp.c:2253
>  2nd 0xc0d3aea4 sysctl lock (sysctl lock) @ kern/kern_sysctl.c:250
> KDB: stack backtrace:
> db_trace_self_wrapper(c0be8361,c42aa328,c087a355,4,c0be39e8,...) at
> db_trace_self_wrapper+0x26
> kdb_backtrace(4,c0be39e8,c4524e00,c4521ad0,c42aa384,...) at
> kdb_backtrace+0x29
> _witness_debugger(c0beb056,c0d3aea4,c0be5e30,c4521ad0,c0be5d4f,...) at
> _witness_debugger+0x25
> witness_checkorder(c0d3aea4,9,c0be5d46,fa,0,...) at witness_checkorder
> +0x839
> _sx_xlock(c0d3aea4,0,c0be5d46,fa,c471a000,...) at _sx_xlock+0x85
> sysctl_ctx_free(c471a2c0,c0b8f786,c0d0696c,0,c469fa0c,...) at
> sysctl_ctx_free+0x30
> dacleanup(c4c54700,c0b900bb,c480e000,c42aa410,246,...) at dacleanup+0x35
> camperiphfree(c4c54700,c4c54700,c42aa694,c047763d,c4c54700,...) at
> camperiphfree+0xc2
> cam_periph_invalidate(c4c54700,c0bb6c60,c42aa6c8,c048ba73,c4c54700,...)
> at cam_periph_invalidate+0x3e
> cam_periph_async(c4c54700,100,c4a03450,0,c480e000,c42aa70c,c087ada8,c480e0a4,c0e7b688,c0ccf6a4) at cam_periph_async+0x2d
> daasync(c4c54700,100,c4a03450,0,c4a26000,...) at daasync+0xf3
> xpt_async_bcast(0,4,c0b88347,117f,c4736500,...) at xpt_async_bcast+0x32
> xpt_async(100,c4a03450,0,8cd,0,...) at xpt_async+0x194
> sbp_cam_detach_sdev(c471bbec,0,c0bb6c57,333,1,...) at
> sbp_cam_detach_sdev+0xa4
> sbp_post_explore(c471b800,c42aaca4,c42aaca0,1,3,...) at sbp_post_explore
> +0xed9
> fw_bus_probe_thread(c472f000,c42aad38,c0be11ff,32d,c472ea90,...) at
> fw_bus_probe_thread+0x88b
> fork_exit(c0636be0,c472f000,c42aad38) at fork_exit+0xb8
> fork_trampoline() at fork_trampoline+0x8
> --- trap 0, eip = 0, esp = 0xc42aad70, ebp = 0 ---
> 

I spent some time dissecting the point at which this LoR occurred in
checkin history and hit this one as the culprit:

r188232 | jhb | 2009-02-06 06:51:32 -0800 (Fri, 06 Feb 2009) | 33 lines

Reverting these changes makes the LoR warning go away.

So, does the Firewire stack need an enhancement or did I stumble across
something more?

Sean

From tinderbox at freebsd.org  Tue Feb 10 23:18:13 2009
From: tinderbox at freebsd.org (FreeBSD Tinderbox)
Date: Tue Feb 10 23:18:21 2009
Subject: [head tinderbox] failure on sparc64/sun4v
Message-ID: <20090211071810.41D217302F@freebsd-current.sentex.ca>

TB --- 2009-02-11 06:08:16 - tinderbox 2.6 running on freebsd-current.sentex.ca
TB --- 2009-02-11 06:08:16 - starting HEAD tinderbox run for sparc64/sun4v
TB --- 2009-02-11 06:08:16 - cleaning the object tree
TB --- 2009-02-11 06:08:37 - cvsupping the source tree
TB --- 2009-02-11 06:08:37 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/sparc64/sun4v/supfile
TB --- 2009-02-11 06:08:46 - building world
TB --- 2009-02-11 06:08:46 - MAKEOBJDIRPREFIX=/obj
TB --- 2009-02-11 06:08:46 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2009-02-11 06:08:46 - TARGET=sun4v
TB --- 2009-02-11 06:08:46 - TARGET_ARCH=sparc64
TB --- 2009-02-11 06:08:46 - TZ=UTC
TB --- 2009-02-11 06:08:46 - __MAKE_CONF=/dev/null
TB --- 2009-02-11 06:08:46 - cd /src
TB --- 2009-02-11 06:08:46 - /usr/bin/make -B buildworld
>>> World build started on Wed Feb 11 06:08: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
[...]
5536 bytes transferred in 0.000060 secs (92508633 bytes/sec)
===> sys/boot/sparc64/loader (all)
cc -O2 -pipe  -DLOADER_DISK_SUPPORT -DLOADER_UFS_SUPPORT -DLOADER_CD9660_SUPPORT -DLOADER_GZIP_SUPPORT -DLOADER_NET_SUPPORT -DLOADER_NFS_SUPPORT -DLOADER_TFTP_SUPPORT -DBOOT_FORTH -I/src/sys/boot/sparc64/loader/../../ficl -I/src/sys/boot/sparc64/loader/../../ficl/sparc64 -I/src/sys/boot/sparc64/loader/../../common -I. -I/src/sys/boot/sparc64/loader/../../ofw/libofw/ -I/src/sys/boot/sparc64/loader/../../../../lib/libstand/ -ffreestanding  -c /src/sys/boot/sparc64/loader/locore.S
cc -O2 -pipe  -DLOADER_DISK_SUPPORT -DLOADER_UFS_SUPPORT -DLOADER_CD9660_SUPPORT -DLOADER_GZIP_SUPPORT -DLOADER_NET_SUPPORT -DLOADER_NFS_SUPPORT -DLOADER_TFTP_SUPPORT -DBOOT_FORTH -I/src/sys/boot/sparc64/loader/../../ficl -I/src/sys/boot/sparc64/loader/../../ficl/sparc64 -I/src/sys/boot/sparc64/loader/../../common -I. -I/src/sys/boot/sparc64/loader/../../ofw/libofw/ -I/src/sys/boot/sparc64/loader/../../../../lib/libstand/ -ffreestanding  -c /src/sys/boot/sparc64/loader/main.c
/src/sys/boot/sparc64/loader/main.c: In function 'itlb_enter_sun4u':
/src/sys/boot/sparc64/loader/main.c:502: error: 'PROMBASE' undeclared (first use in this function)
/src/sys/boot/sparc64/loader/main.c:502: error: (Each undeclared identifier is reported only once
/src/sys/boot/sparc64/loader/main.c:502: error: for each function it appears in.)
*** Error code 1

Stop in /src/sys/boot/sparc64/loader.
*** Error code 1

Stop in /src/sys/boot/sparc64.
*** Error code 1

Stop in /src/sys/boot.
*** Error code 1

Stop in /src/sys.
*** Error code 1

Stop in /src.
*** Error code 1

Stop in /src.
*** Error code 1

Stop in /src.
TB --- 2009-02-11 07:18:10 - WARNING: /usr/bin/make returned exit code  1 
TB --- 2009-02-11 07:18:10 - ERROR: failed to build world
TB --- 2009-02-11 07:18:10 - 3371.59 user 331.06 system 4193.59 real


http://tinderbox.des.no/tinderbox-head-HEAD-sparc64-sun4v.full
From ed at 80386.nl  Tue Feb 10 23:23:14 2009
From: ed at 80386.nl (Ed Schouten)
Date: Tue Feb 10 23:23:21 2009
Subject: Contention on sysctl lock
In-Reply-To: <a31046fc0902101213t6dcd6a39j625bc8e4927157e5@mail.gmail.com>
References: <a31046fc0902101213t6dcd6a39j625bc8e4927157e5@mail.gmail.com>
Message-ID: <20090211072312.GL68388@hoeg.nl>

Hello,

* pluknet <pluknet@gmail.com> wrote:
> Any commands I tried then lock on sysctl lock; i.e. ctrl+t returns:
> load: 0.04 cmd: sudo 1008 [sysctl lock] 0.00u 0.00s 0% 312k

The problem with sysctl's current implementation is that all calls to
sysctl() are protected with an sx lock, sysctl lock. This means that if
one call to sysctl() gets blocked on a different lock (one of GEOM's in
this case), all further calls get blocked as well. Because we call
sysctl() on process creation (to obtain a random number for the stack
protector), this becomes a mess.

Some time ago I was thinking it shouldn't be all that hard to make
sysctl() lockless for any sysctls that aren't created dynamically. I
still have to find some time to implement this.

-- 
 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/20090211/2161fd10/attachment.pgp
From olli at lurza.secnetix.de  Wed Feb 11 01:27:44 2009
From: olli at lurza.secnetix.de (Oliver Fromme)
Date: Wed Feb 11 01:27:52 2009
Subject: CFT: Graphics support for /boot/loader
In-Reply-To: <49923B2F.2080804@mawer.org>
Message-ID: <200902110927.n1B9RXSE099109@lurza.secnetix.de>

Antony Mawer wrote:
 > Oliver Fromme wrote:
 > > Standard VGA supports at most 640x480 at 4 bits and 320x200
 > > at 8 bits.  So that's the common denominator.
 > 
 > Do you know if it would be hard to modify splash(4) to supports 640x480 
 > 4-bit images?

Uhm.  Actually I thought that was already supported.
If it's not, it shouldn't be too hard to implement it.
I'll look into that.

Best regards
   Oliver

-- 
Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M.
Handelsregister: Registergericht Muenchen, HRA 74606,  Gesch?ftsfuehrung:
secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht M?n-
chen, HRB 125758,  Gesch?ftsf?hrer: Maik Bachmann, Olaf Erb, Ralf Gebhart

FreeBSD-Dienstleistungen, -Produkte und mehr:  http://www.secnetix.de/bsd

"It combines all the worst aspects of C and Lisp:  a billion different
sublanguages in one monolithic executable.  It combines the power of C
with the readability of PostScript."
        -- Jamie Zawinski, when asked: "What's wrong with perl?"
From ale at FreeBSD.org  Wed Feb 11 03:02:38 2009
From: ale at FreeBSD.org (Alex Dupre)
Date: Wed Feb 11 03:02:57 2009
Subject: CFT: Graphics support for /boot/loader
In-Reply-To: <200902061139.n16BdB6b058473@lurza.secnetix.de>
References: <200902061139.n16BdB6b058473@lurza.secnetix.de>
Message-ID: <4992B049.30903@FreeBSD.org>

Oliver Fromme ha scritto:
> The problem is related to the fact that a 64bit kernel
> cannot use VESA BIOS functions.  You should be able to
> use standard VGA modes though, which don't require VESA
> support.

Actually I cannot see any splash screen on amd64, at least on the 
machines I tried (most with ATI ES1000 cards), with a 320x200x8 bitmap. 
No problems with i386 (on the same machines).

-- 
Alex Dupre
From Alexander at Leidinger.net  Wed Feb 11 03:02:42 2009
From: Alexander at Leidinger.net (Alexander Leidinger)
Date: Wed Feb 11 03:02:59 2009
Subject: [RFC] Skeleton jail (rc.d feature proposal)
In-Reply-To: <49924B92.6050307@delphij.net>
References: <499244E6.9030205@delphij.net> <499246D4.8020908@freebsd.org>
	<49924B92.6050307@delphij.net>
Message-ID: <20090211120226.75402wimhlvv1fk0@webmail.leidinger.net>

Quoting Xin LI <delphij@delphij.net> (from Tue, 10 Feb 2009 19:52:50 -0800):

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Lawrence Stewart wrote:
>> Xin LI wrote:
>>> -----BEGIN PGP SIGNED MESSAGE-----
>>> Hash: SHA1
>>>
>>> Hi,
>>>
>>> Ok, some local users has prodded me in committing the "skeleton jail"
>>
>> [snip]
>>
>> Can you describe how this differs from the functionality provided by the
>> ezjail port? (/usr/ports/sysutils/ezjail/)
>
> I think they have different targets.  Skeleton jail is more lightweight
> which is only very few lines of changes to the base system (i.e. the aim
> is to provide convenient shortcut for common tasks, not to be a complete
> solution); the functionality provided by skeleton jail, on the other
> hand, could be useful building blocks to ezjail.

Ezjail already has this skeleon feature. It's used for every jail you  
create with ezjail. You can then upadate this skeleton, and you update  
the basesystem of all jails at once. Your solution looks a little bit  
more generic, as you can use a different skeleton for each jail. The  
make installskel part could be compatible with ezjail, but I'm not  
sure if the rc.d part could be used easily by ezjail. Ezjail is  
nullfs-mounting (RO) the skeleton into each jail, and it has symlinks  
from the normal directory layout to the "<jail>/basejail/..."  
location. It creates the basejail by doing a full install and then  
removing some parts.

Maybe you can have a look at ezjail to see the requirements of it?  
It's simple to setup, you just need to specify the path to the  
location where you want all jails to be installed to, and then you can  
install a jail (it does a buildworld if ou do not tell to skip this  
part, e.g. becuse you already did one yourself).

Bye,
Alexander.

-- 
God said it, I believe it and that's all there is to it.

http://www.Leidinger.net    Alexander @ Leidinger.net: PGP ID = B0063FE7
http://www.FreeBSD.org       netchild @ FreeBSD.org  : PGP ID = 72077137
From olli at lurza.secnetix.de  Wed Feb 11 04:01:06 2009
From: olli at lurza.secnetix.de (Oliver Fromme)
Date: Wed Feb 11 04:01:14 2009
Subject: CFT: Graphics support for /boot/loader
In-Reply-To: <4992B049.30903@FreeBSD.org>
Message-ID: <200902111200.n1BC0wni006842@lurza.secnetix.de>


Alex Dupre wrote:
 > Oliver Fromme ha scritto:
 > > The problem is related to the fact that a 64bit kernel
 > > cannot use VESA BIOS functions.  You should be able to
 > > use standard VGA modes though, which don't require VESA
 > > support.
 > 
 > Actually I cannot see any splash screen on amd64, at least on the 
 > machines I tried (most with ATI ES1000 cards), with a 320x200x8 bitmap. 
 > No problems with i386 (on the same machines).

Yeah, my fingers were faster than my brain.  The current
syscons code cannot switch modes (no matter if VESA or
standard VGA) if there is no BIOS support.

It probably makes sense to let the boot loader set up
graphics mode (including VESA support), so it is already
active when the kernel comes up.  Then the kernel will
only have to deal with the frame buffer, not with the BIOS.
That will work on both i386 and amd64 platforms.  The only
drawback is that the mode cannot be changed by the kernel
once it is running, i.e. you have to stay in that mode
till reboot.

That solution requires support by the loader and by
syscons.  It is my plan to look into that, as soon as the
basic graphics support in the loader is finished.

Best regards
   Oliver

-- 
Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M.
Handelsregister: Registergericht Muenchen, HRA 74606,  Gesch?ftsfuehrung:
secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht M?n-
chen, HRB 125758,  Gesch?ftsf?hrer: Maik Bachmann, Olaf Erb, Ralf Gebhart

FreeBSD-Dienstleistungen, -Produkte und mehr:  http://www.secnetix.de/bsd

"[...]  one observation we can make here is that Python makes
an excellent pseudocoding language, with the wonderful attribute
that it can actually be executed."  --  Bruce Eckel
From rink at FreeBSD.org  Wed Feb 11 05:11:58 2009
From: rink at FreeBSD.org (Rink Springer)
Date: Wed Feb 11 05:12:05 2009
Subject: CFT: Graphics support for /boot/loader
In-Reply-To: <200902111200.n1BC0wni006842@lurza.secnetix.de>
References: <4992B049.30903@FreeBSD.org>
	<200902111200.n1BC0wni006842@lurza.secnetix.de>
Message-ID: <20090211131331.GA78543@rink.nu>

On Wed, Feb 11, 2009 at 01:00:58PM +0100, Oliver Fromme wrote:
> It probably makes sense to let the boot loader set up
> graphics mode (including VESA support), so it is already
> active when the kernel comes up.  Then the kernel will
> only have to deal with the frame buffer, not with the BIOS.
> That will work on both i386 and amd64 platforms.  The only
> drawback is that the mode cannot be changed by the kernel
> once it is running, i.e. you have to stay in that mode
> till reboot.

FWIW, this is exactly what FreeBSD/xbox does; the boot loader is
responsible for setting up the video mode, and all it does is remap the
framebuffer to a more sensible location (the way to do this is just
writing to a register which is the same for any Xbox, and most
bootloaders set the framebuffer to 4MB, which is a bit much for
640x480x16M especially if your machine only has 64MB of memory :-)

> That solution requires support by the loader and by
> syscons.  It is my plan to look into that, as soon as the
> basic graphics support in the loader is finished.

I think that is a good approach. Go for it!

Regards,

-- 
Rink P.W. Springer                                - http://rink.nu
"Chance favours the prepared mind"
- Penn
From ob at e-Gitt.NET  Wed Feb 11 06:02:53 2009
From: ob at e-Gitt.NET (Oliver Brandmueller)
Date: Wed Feb 11 06:03:00 2009
Subject: CFT: Graphics support for /boot/loader
In-Reply-To: <200902111200.n1BC0wni006842@lurza.secnetix.de>
References: <4992B049.30903@FreeBSD.org>
	<200902111200.n1BC0wni006842@lurza.secnetix.de>
Message-ID: <20090211140251.GF51761@e-Gitt.NET>

Hi,

On Wed, Feb 11, 2009 at 01:00:58PM +0100, Oliver Fromme wrote:
> It probably makes sense to let the boot loader set up
> graphics mode (including VESA support), so it is already
> active when the kernel comes up.  Then the kernel will
> only have to deal with the frame buffer, not with the BIOS.
> That will work on both i386 and amd64 platforms.  The only
> drawback is that the mode cannot be changed by the kernel
> once it is running, i.e. you have to stay in that mode
> till reboot.

Theoretically spoken, would this include the chance of a rotated 
display? I'm currently using 2 widescreens, but rotated (else it would 
just be too wide ;-)). Using X this is fine, but booting and probably 
doing things like fixing X after the Xorg upgrade (which worked more or 
less painless for me) is a pain when you have to turn your head 90? to 
the side ;-)

This is just a (now not anymore too) silent wish, not exactly a feature 
request, as I think this is an edge case.

Greetings,
		Olli

-- 
| Oliver Brandmueller | Offenbacher Str. 1  | Germany       D-14197 Berlin |
| Fon +49-172-3130856 | Fax +49-172-3145027 | WWW:   http://the.addict.de/ |
|               Ich bin das Internet. Sowahr ich Gott helfe.               |
| Eine gewerbliche Nutzung aller enthaltenen Adressen ist nicht gestattet! |
From jhb at freebsd.org  Wed Feb 11 06:50:33 2009
From: jhb at freebsd.org (John Baldwin)
Date: Wed Feb 11 06:50:53 2009
Subject: lpt stopped working
In-Reply-To: <20090211000741.GA1625@wep4035.physik.uni-wuerzburg.de>
References: <200902021643.39862.c47g@gmx.at>
	<200902101734.10365.jhb@freebsd.org>
	<20090211000741.GA1625@wep4035.physik.uni-wuerzburg.de>
Message-ID: <200902110934.23146.jhb@freebsd.org>

On Tuesday 10 February 2009 7:07:41 pm Alexey Shuvaev wrote:
> On Tue, Feb 10, 2009 at 05:34:10PM -0500, John Baldwin wrote:
> > On Tuesday 10 February 2009 4:57:20 pm Alexey Shuvaev wrote:
> > > On Tue, Feb 10, 2009 at 04:12:57PM -0500, John Baldwin wrote:
> > > > Ok, so the first cat works, the second one gets EBUSY?
> > > >
> > > Mmm... I don't think the first cat really works.
> > > It hangs, I suppose nothing goes to the wire,
> > > and during this I got the above printigs from kgdb.
> > > 
> > > > Hmm, I think I've found it.  Due to a bug, lptclose() wasn't releasing the 
> > > > bus.
> > 
> > Grr, lptopen() was also busted.  The old lpt driver didn't actually check the 
> > HAVEBUS flag in lpt_release_ppbus() which masked the bugs in lptopen().  Try 
> > this:
> > 
> Seems to work!
> No messages in the console, like "interrupt storm", too.
> Thanks!

Thank you to you and everyone else for patience and testing!

-- 
John Baldwin
From jhb at freebsd.org  Wed Feb 11 06:50:39 2009
From: jhb at freebsd.org (John Baldwin)
Date: Wed Feb 11 06:50:56 2009
Subject: [sysctl] New sysctl LoR today
In-Reply-To: <1234332568.14556.11.camel@localhost.localdomain>
References: <1234315393.14556.6.camel@localhost.localdomain>
	<1234332568.14556.11.camel@localhost.localdomain>
Message-ID: <200902110946.46153.jhb@freebsd.org>

On Wednesday 11 February 2009 1:09:28 am Sean Bruno wrote:
> On Tue, 2009-02-10 at 17:23 -0800, Sean Bruno wrote:
> > I'm working on some items in the firewire stack and after a update, I
> > was greeted with a new LoR against the SYSCTL lock.  I noted that some
> > things were changing in that space.
> > 
> > Did I miss an interface change that I need to pickup in the firewire
> > stack?
> > 
> > Sean
> > 
> > lock order reversal: (sleepable after non-sleepable)
> >  1st 0xc471bbec sbp (sbp) @ dev/firewire/sbp.c:2253
> >  2nd 0xc0d3aea4 sysctl lock (sysctl lock) @ kern/kern_sysctl.c:250
> > KDB: stack backtrace:
> > _sx_xlock(c0d3aea4,0,c0be5d46,fa,c471a000,...) at _sx_xlock+0x85
> > sysctl_ctx_free(c471a2c0,c0b8f786,c0d0696c,0,c469fa0c,...) at
> > sysctl_ctx_free+0x30
> > dacleanup(c4c54700,c0b900bb,c480e000,c42aa410,246,...) at dacleanup+0x35
> > camperiphfree(c4c54700,c4c54700,c42aa694,c047763d,c4c54700,...) at

No, this is due to CAM calling sysctl_ctx_free() with a lock held.  You can 
try this change:

--- //depot/user/jhb/lock/cam/scsi/scsi_cd.c
+++ /home/jhb/work/p4/lock/cam/scsi/scsi_cd.c
@@ -401,11 +401,6 @@
 
 	xpt_print(periph->path, "removing device entry\n");
 
-	if ((softc->flags & CD_FLAG_SCTX_INIT) != 0
-	    && sysctl_ctx_free(&softc->sysctl_ctx) != 0) {
-		xpt_print(periph->path, "can't remove sysctl context\n");
-	}
-
 	/*
 	 * In the queued, non-active case, the device in question
 	 * has already been removed from the changer run queue.  Since this
@@ -474,9 +469,14 @@
 		free(softc->changer, M_DEVBUF);
 	}
 	cam_periph_unlock(periph);
+	if ((softc->flags & CD_FLAG_SCTX_INIT) != 0
+	    && sysctl_ctx_free(&softc->sysctl_ctx) != 0) {
+		xpt_print(periph->path, "can't remove sysctl context\n");
+	}
+
 	disk_destroy(softc->disk);
+	free(softc, M_DEVBUF);
 	cam_periph_lock(periph);
-	free(softc, M_DEVBUF);
 }
 
 static void
--- //depot/user/jhb/lock/cam/scsi/scsi_da.c
+++ /home/jhb/work/p4/lock/cam/scsi/scsi_da.c
@@ -995,6 +995,8 @@
 	softc = (struct da_softc *)periph->softc;
 
 	xpt_print(periph->path, "removing device entry\n");
+	cam_periph_unlock(periph);
+
 	/*
 	 * If we can't free the sysctl tree, oh well...
 	 */
@@ -1003,11 +1005,10 @@
 		xpt_print(periph->path, "can't remove sysctl context\n");
 	}
 
-	cam_periph_unlock(periph);
 	disk_destroy(softc->disk);
 	callout_drain(&softc->sendordered_c);
+	free(softc, M_DEVBUF);
 	cam_periph_lock(periph);
-	free(softc, M_DEVBUF);
 }
 
 static void


-- 
John Baldwin
From c47g at gmx.at  Wed Feb 11 08:07:57 2009
From: c47g at gmx.at (Christian Gusenbauer)
Date: Wed Feb 11 08:08:04 2009
Subject: lpt stopped working
In-Reply-To: <20090211000741.GA1625@wep4035.physik.uni-wuerzburg.de>
References: <200902021643.39862.c47g@gmx.at>
	<200902101734.10365.jhb@freebsd.org>
	<20090211000741.GA1625@wep4035.physik.uni-wuerzburg.de>
Message-ID: <200902111708.23030.c47g@gmx.at>

On Wednesday 11 February 2009, Alexey Shuvaev wrote:
> On Tue, Feb 10, 2009 at 05:34:10PM -0500, John Baldwin wrote:
> > On Tuesday 10 February 2009 4:57:20 pm Alexey Shuvaev wrote:
> > > On Tue, Feb 10, 2009 at 04:12:57PM -0500, John Baldwin wrote:
> > > > Ok, so the first cat works, the second one gets EBUSY?
> > >
> > > Mmm... I don't think the first cat really works.
> > > It hangs, I suppose nothing goes to the wire,
> > > and during this I got the above printigs from kgdb.
> > >
> > > > Hmm, I think I've found it.  Due to a bug, lptclose() wasn't
> > > > releasing the bus.
> >
> > Grr, lptopen() was also busted.  The old lpt driver didn't actually check
> > the HAVEBUS flag in lpt_release_ppbus() which masked the bugs in
> > lptopen().  Try this:
> >
> > --- //depot/vendor/freebsd/src/sys/dev/ppbus/lpt.c	2009/01/26 21:00:15
> > +++ //depot/user/jhb/acpipci/dev/ppbus/lpt.c	2009/02/10 22:32:11
> > @@ -544,10 +544,10 @@
> >  	do {
> >  		/* ran out of waiting for the printer */
> >  		if (trys++ >= LPINITRDY*4) {
> > -			sc->sc_state = 0;
> >  			lprintf(("status %x\n", ppb_rstr(ppbus)));
> >
> >  			lpt_release_ppbus(lptdev);
> > +			sc->sc_state = 0;
> >  			ppb_unlock(ppbus);
> >  			return (EBUSY);
> >  		}
> > @@ -555,9 +555,8 @@
> >  		/* wait 1/4 second, give up if we get a signal */
> >  		if (ppb_sleep(ppbus, lptdev, LPPRI | PCATCH, "lptinit",
> >  		    hz / 4) != EWOULDBLOCK) {
> > +			lpt_release_ppbus(lptdev);
> >  			sc->sc_state = 0;
> > -
> > -			lpt_release_ppbus(lptdev);
> >  			ppb_unlock(ppbus);
> >  			return (EBUSY);
> >  		}
> > @@ -577,7 +576,8 @@
> >
> >  	ppb_wctr(ppbus, sc->sc_control);
> >
> > -	sc->sc_state = OPEN;
> > +	sc->sc_state &= ~LPTINIT;
> > +	sc->sc_state |= OPEN;
> >  	sc->sc_xfercnt = 0;
> >
> >  	/* only use timeout if using interrupt */
> > @@ -611,11 +611,8 @@
> >  	int err;
> >
> >  	ppb_lock(ppbus);
> > -	if (sc->sc_flags & LP_BYPASS) {
> > -		sc->sc_state = 0;
> > -		ppb_unlock(ppbus);
> > +	if (sc->sc_flags & LP_BYPASS)
> >  		goto end_close;
> > -	}
> >
> >  	if ((err = lpt_request_ppbus(lptdev, PPB_WAIT|PPB_INTR)) != 0) {
> >  		ppb_unlock(ppbus);
> > @@ -635,16 +632,16 @@
> >  	sc->sc_state &= ~OPEN;
> >  	callout_stop(&sc->sc_timer);
> >  	ppb_wctr(ppbus, LPC_NINIT);
> > -	sc->sc_state = 0;
> > -	sc->sc_xfercnt = 0;
> >
> >  	/*
> >  	 * unregistration of interrupt forced by release
> >  	 */
> >  	lpt_release_ppbus(lptdev);
> > -	ppb_unlock(ppbus);
> >
> >  end_close:
> > +	sc->sc_state = 0;
> > +	sc->sc_xfercnt = 0;
> > +	ppb_unlock(ppbus);
> >  	lprintf(("closed.\n"));
> >  	return(0);
> >  }
>
> Seems to work!
> No messages in the console, like "interrupt storm", too.
> Thanks!
>
> Alexey.

That works for me, too. Thanks for fixing it!

Christian.

From sean.bruno at dsl-only.net  Wed Feb 11 08:26:29 2009
From: sean.bruno at dsl-only.net (Sean Bruno)
Date: Wed Feb 11 08:26:36 2009
Subject: [sysctl] New sysctl LoR today
In-Reply-To: <200902110946.46153.jhb@freebsd.org>
References: <1234315393.14556.6.camel@localhost.localdomain>
	<1234332568.14556.11.camel@localhost.localdomain>
	<200902110946.46153.jhb@freebsd.org>
Message-ID: <1234369583.26300.0.camel@localhost.localdomain>

On Wed, 2009-02-11 at 09:46 -0500, John Baldwin wrote:
> On Wednesday 11 February 2009 1:09:28 am Sean Bruno wrote:
> > On Tue, 2009-02-10 at 17:23 -0800, Sean Bruno wrote:
> > > I'm working on some items in the firewire stack and after a update, I
> > > was greeted with a new LoR against the SYSCTL lock.  I noted that some
> > > things were changing in that space.
> > > 
> > > Did I miss an interface change that I need to pickup in the firewire
> > > stack?
> > > 
> > > Sean
> > > 
> > > lock order reversal: (sleepable after non-sleepable)
> > >  1st 0xc471bbec sbp (sbp) @ dev/firewire/sbp.c:2253
> > >  2nd 0xc0d3aea4 sysctl lock (sysctl lock) @ kern/kern_sysctl.c:250
> > > KDB: stack backtrace:
> > > _sx_xlock(c0d3aea4,0,c0be5d46,fa,c471a000,...) at _sx_xlock+0x85
> > > sysctl_ctx_free(c471a2c0,c0b8f786,c0d0696c,0,c469fa0c,...) at
> > > sysctl_ctx_free+0x30
> > > dacleanup(c4c54700,c0b900bb,c480e000,c42aa410,246,...) at dacleanup+0x35
> > > camperiphfree(c4c54700,c4c54700,c42aa694,c047763d,c4c54700,...) at
> 
> No, this is due to CAM calling sysctl_ctx_free() with a lock held.  You can 
> try this change:
> 
> --- //depot/user/jhb/lock/cam/scsi/scsi_cd.c
> +++ /home/jhb/work/p4/lock/cam/scsi/scsi_cd.c
> @@ -401,11 +401,6 @@
>  
>  	xpt_print(periph->path, "removing device entry\n");
>  
> -	if ((softc->flags & CD_FLAG_SCTX_INIT) != 0
> -	    && sysctl_ctx_free(&softc->sysctl_ctx) != 0) {
> -		xpt_print(periph->path, "can't remove sysctl context\n");
> -	}
> -
>  	/*
>  	 * In the queued, non-active case, the device in question
>  	 * has already been removed from the changer run queue.  Since this
> @@ -474,9 +469,14 @@
>  		free(softc->changer, M_DEVBUF);
>  	}
>  	cam_periph_unlock(periph);
> +	if ((softc->flags & CD_FLAG_SCTX_INIT) != 0
> +	    && sysctl_ctx_free(&softc->sysctl_ctx) != 0) {
> +		xpt_print(periph->path, "can't remove sysctl context\n");
> +	}
> +
>  	disk_destroy(softc->disk);
> +	free(softc, M_DEVBUF);
>  	cam_periph_lock(periph);
> -	free(softc, M_DEVBUF);
>  }
>  
>  static void
> --- //depot/user/jhb/lock/cam/scsi/scsi_da.c
> +++ /home/jhb/work/p4/lock/cam/scsi/scsi_da.c
> @@ -995,6 +995,8 @@
>  	softc = (struct da_softc *)periph->softc;
>  
>  	xpt_print(periph->path, "removing device entry\n");
> +	cam_periph_unlock(periph);
> +
>  	/*
>  	 * If we can't free the sysctl tree, oh well...
>  	 */
> @@ -1003,11 +1005,10 @@
>  		xpt_print(periph->path, "can't remove sysctl context\n");
>  	}
>  
> -	cam_periph_unlock(periph);
>  	disk_destroy(softc->disk);
>  	callout_drain(&softc->sendordered_c);
> +	free(softc, M_DEVBUF);
>  	cam_periph_lock(periph);
> -	free(softc, M_DEVBUF);
>  }
>  
>  static void
> 
> 


Yup.  Thanks for the quick fix!

Sean

From sean.bruno at dsl-only.net  Wed Feb 11 08:51:04 2009
From: sean.bruno at dsl-only.net (Sean Bruno)
Date: Wed Feb 11 08:51:11 2009
Subject: LoR when drives are dirty
Message-ID: <1234371063.26300.2.camel@localhost.localdomain>

Another LoR for your review folks.  If my file system is dirty it
appears that the background fsck generates the following LoR.  Fairly
easy to reproduce on my box.



lock order reversal:
 1st 0xc4d6a164 ufs (ufs) @ ufs/ffs/ffs_snapshot.c:424
 2nd 0xd850d7c0 bufwait (bufwait) @ kern/vfs_bio.c:2443
 3rd 0xc4b0b058 ufs (ufs) @ ufs/ffs/ffs_snapshot.c:545
KDB: stack backtrace:
db_trace_self_wrapper(c0be8332,e696540c,c087a295,4,c0be39cf,...) at
db_trace_self_wrapper+0x26
kdb_backtrace(4,c0be39cf,c4523740,c4526730,e6965468,...) at
kdb_backtrace+0x29
_witness_debugger(c0beb040,c4b0b058,c0bdea8a,c4526730,c0c078ce,...) at
_witness_debugger+0x25
witness_checkorder(c4b0b058,9,c0c078c5,221,0,...) at witness_checkorder
+0x839
__lockmgr_args(c4b0b058,80100,c4b0b074,0,0,...) at __lockmgr_args+0x797
ffs_lock(e6965578,c0e7aa00,c4a770a4,80100,c4b0b000,...) at ffs_lock+0x8a
VOP_LOCK1_APV(c0ced860,e6965578,e6965598,c0d06180,c4b0b000,...) at
VOP_LOCK1_APV+0xb5
_vn_lock(c4b0b000,80100,c0c078c5,221,c4553200,...) at _vn_lock+0x5e
ffs_snapshot(c4a4fa00,c4b3e7c0,c0c09222,15e,3,...) at ffs_snapshot
+0x1527
ffs_mount(c4a4fa00,c4a77000,c0bf1665,3d7,c4839b20,...) at ffs_mount
+0x146f
vfs_donmount(c4a77000,211000,c4a54e80,c4a54e80,bfbfed04,...) at
vfs_donmount+0x130e
nmount(c4a77000,e6965cf8,c,e6965d38,c0ccadf0,...) at nmount+0xbe
syscall(e6965d38) at syscall+0x2a3
Xint0x80_syscall() at Xint0x80_syscall+0x20
--- syscall (378, FreeBSD ELF32, nmount), eip = 0x280e6cab, esp =
0xbfbfeb2c, ebp = 0xbfbfee78 ---
lock order reversal:
 1st 0xd850d7c0 bufwait (bufwait) @ kern/vfs_bio.c:2443
 2nd 0xc4961a1c snaplk (snaplk) @ ufs/ffs/ffs_snapshot.c:794
KDB: stack backtrace:
db_trace_self_wrapper(c0be8332,e696540c,c087a295,4,c0be39cf,...) at
db_trace_self_wrapper+0x26
kdb_backtrace(4,c0be39cf,c4523740,c4526a70,e6965468,...) at
kdb_backtrace+0x29
_witness_debugger(c0beb027,c4961a1c,c0c07923,c4526a70,c0c078ce,...) at
_witness_debugger+0x25
witness_checkorder(c4961a1c,9,c0c078c5,31a,c4d6a180,...) at
witness_checkorder+0x839
__lockmgr_args(c4961a1c,80400,c4d6a180,0,0,...) at __lockmgr_args+0x797
ffs_lock(e6965578,0,0,80400,c4d6a10c,...) at ffs_lock+0x8a
VOP_LOCK1_APV(c0ced860,e6965578,c1901b14,c0d06180,c4d6a10c,...) at
VOP_LOCK1_APV+0xb5
_vn_lock(c4d6a10c,80400,c0c078c5,31a,0,...) at _vn_lock+0x5e
ffs_snapshot(c4a4fa00,c4b3e7c0,c0c09222,15e,3,...) at ffs_snapshot
+0x28c6
ffs_mount(c4a4fa00,c4a77000,c0bf1665,3d7,c4839b20,...) at ffs_mount
+0x146f
vfs_donmount(c4a77000,211000,c4a54e80,c4a54e80,bfbfed04,...) at
vfs_donmount+0x130e
nmount(c4a77000,e6965cf8,c,e6965d38,c0ccadf0,...) at nmount+0xbe
syscall(e6965d38) at syscall+0x2a3
Xint0x80_syscall() at Xint0x80_syscall+0x20
--- syscall (378, FreeBSD ELF32, nmount), eip = 0x280e6cab, esp =
0xbfbfeb2c, ebp = 0xbfbfee78 ---
lock order reversal:
 1st 0xc4961a1c snaplk (snaplk) @ kern/vfs_vnops.c:293
 2nd 0xc4d6a164 ufs (ufs) @ ufs/ffs/ffs_snapshot.c:1588
KDB: stack backtrace:
db_trace_self_wrapper(c0be8332,e69658c4,c087a295,4,c0be39cf,...) at
db_trace_self_wrapper+0x26
kdb_backtrace(4,c0be39cf,c4526a70,c4526730,e6965920,...) at
kdb_backtrace+0x29
_witness_debugger(c0beb027,c4d6a164,c0bdea8a,c4526730,c0c078ce,...) at
_witness_debugger+0x25
witness_checkorder(c4d6a164,9,c0c078c5,634,0,...) at witness_checkorder
+0x839
__lockmgr_args(c4d6a164,80000,0,0,0,...) at __lockmgr_args+0x797
ffs_snapremove(c4d6a10c,c4a4fa00,0,c0bf2e5d,414,...) at ffs_snapremove
+0x11f
softdep_releasefile(c4a5a168,e6965aa8,2,c0e7a9d0,c0ccf6a4,...) at
softdep_releasefile+0x3b
ufs_inactive(e6965ae8,c4d6a180,c4d6a10c,c4d6a180,e6965b00,...) at
ufs_inactive+0x1bc
VOP_INACTIVE_APV(c0ced860,e6965ae8,c0bf1c91,92d,c0d06140,...) at
VOP_INACTIVE_APV+0xa5
vinactive(c0ced860,e6965b1c,c0bf1c91,8b3,129,...) at vinactive+0x8e
vput(c4d6a10c,e6965b54,c0bf2e5d,125,c0d05ea0,...) at vput+0x1db
vn_close(c4d6a10c,1,c456c400,c4a77000,e6965be0,...) at vn_close+0xee
vn_closefile(c4a64bd0,c4a77000,3,0,c4a64bd0,...) at vn_closefile+0xe9
_fdrop(c4a64bd0,c4a77000,e6965c1c,c087a0dc,0,c4a770a4,c0e7a9d0,c0cd0eb0,c0be0764,c4b4612c,44f,c0be075b,e6965c44,c0842890,c4b4612c,8,c0be075b,44f) at _fdrop+0x43
closef(c4a64bd0,c4a77000,44f,434,c4a64bd0,...) at closef+0x290
kern_close(c4a77000,4,e6965d2c,c0b3e1e3,c4a77000,...) at kern_close
+0x11d
close(c4a77000,e6965cf8,4,c0bebdc0,c0cc8b10,...) at close+0x1a
syscall(e6965d38) at syscall+0x2a3
Xint0x80_syscall() at Xint0x80_syscall+0x20
--- syscall (6, FreeBSD ELF32, close), eip = 0x28184c53, esp =
0xbfbfeb2c, ebp = 0xbfbfee78 ---


Sean

From barney_cordoba at yahoo.com  Wed Feb 11 09:03:19 2009
From: barney_cordoba at yahoo.com (Barney Cordoba)
Date: Wed Feb 11 09:03:26 2009
Subject: Profiling
Message-ID: <255177.96589.qm@web63905.mail.re1.yahoo.com>

I found a page on watson.org that says that profiling generated incorrect
results in SMP mode. Has this changed? Its not clear how old the page is or if its current.

BC


      
From alan.l.cox at gmail.com  Wed Feb 11 09:30:39 2009
From: alan.l.cox at gmail.com (Alan Cox)
Date: Wed Feb 11 09:30:54 2009
Subject: memory alignment problems with -current on amd64? [Found Cause]
In-Reply-To: <gmsnin$qg9$1@ger.gmane.org>
References: <gl7hu4$q7k$1@ger.gmane.org> <gmqbv1$jhe$1@ger.gmane.org>
	<gmsnin$qg9$1@ger.gmane.org>
Message-ID: <ca3526250902110900r6e3703c2gf4f63678949a2e33@mail.gmail.com>

On Tue, Feb 10, 2009 at 2:20 PM, Mark Atkinson <atkin901@yahoo.com> wrote:
[snip]
>
>
>
> Well, taking the information I knew -- OCT 15th == good, Mid DEC == BAD,
> I trolled every commit logged between.   Eventually I found this one:
>
> http://svn.freebsd.org/viewvc/base?view=revision&revision=185715
>
> http://docs.freebsd.org/cgi/mid.cgi?200812061937.mB6JbqAI003273
>
> I set vm.pmap.pg_ps_enabled="0" in /boot/loader.conf, and
> was able to complete buildworld and -j16 buildworld and -j8 buildkernel
> no problem.
>
> It appears superpage mapping causes alignment problems on this box.


Can you please provide more detailed information about this machine, in
particular, the processor including the revision?  It would also be helpful
to see what gdb says about a couple of these crashes, specifically, the
machine registers at the time of the exception.

Thanks in advance,
Alan
From peterjeremy at optushome.com.au  Wed Feb 11 10:03:46 2009
From: peterjeremy at optushome.com.au (Peter Jeremy)
Date: Wed Feb 11 10:03:53 2009
Subject: CFT: Graphics support for /boot/loader
In-Reply-To: <200902081335.n18DZ2h4018582@lurza.secnetix.de>
References: <20090208135053.12691emq58yl9m4k@webmail.leidinger.net>
	<200902081335.n18DZ2h4018582@lurza.secnetix.de>
Message-ID: <20090211180341.GA1467@server.vk2pj.dyndns.org>

On 2009-Feb-08 14:35:02 +0100, Oliver Fromme <olli@lurza.secnetix.de> wrote:
>The actual menu contents are in the beastie.4th file, just
>like for the old text menu.  So, yes, you'd need to speak
>FORTH in order to change that.

Well, you need the ability to read the existing FORTH code and
extrapolate a bit.  You don't need to be a FORTH guru.

>Would there be strong resistance if I tried to replace FICL
>with something else that is not as brain-knotting as FORTH?

I disagree that FORTH is brain-knotting.  As a small, general-
purpose language that is close to the hardware, I don't think
you can do much better.  What are you proposing as a replacement?

>Just to name an example, I once wrote a bourne-shell-like
>parser that would not be difficult to embed.

/boot/loader isn't just a matter of parsing an rc.conf style
config file.  It needs the ability to talk to disk and physical
memory and the whole thing needs to be fairly small.

If you look at the installed base of computers, FORTH is
probably the most popular language for bootloaders.

-- 
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/20090211/76005c2e/attachment.pgp
From olivier at gid0.org  Wed Feb 11 10:28:47 2009
From: olivier at gid0.org (Olivier SMEDTS)
Date: Wed Feb 11 10:28:55 2009
Subject: CFT: Graphics support for /boot/loader
In-Reply-To: <20090211180341.GA1467@server.vk2pj.dyndns.org>
References: <20090208135053.12691emq58yl9m4k@webmail.leidinger.net>
	<200902081335.n18DZ2h4018582@lurza.secnetix.de>
	<20090211180341.GA1467@server.vk2pj.dyndns.org>
Message-ID: <367b2c980902111028q2b1e07b8q29732402f3637c54@mail.gmail.com>

2009/2/11 Peter Jeremy <peterjeremy@optushome.com.au>:
> On 2009-Feb-08 14:35:02 +0100, Oliver Fromme <olli@lurza.secnetix.de> wrote:
>>The actual menu contents are in the beastie.4th file, just
>>like for the old text menu.  So, yes, you'd need to speak
>>FORTH in order to change that.
>
> Well, you need the ability to read the existing FORTH code and
> extrapolate a bit.  You don't need to be a FORTH guru.
>
>>Would there be strong resistance if I tried to replace FICL
>>with something else that is not as brain-knotting as FORTH?
>
> I disagree that FORTH is brain-knotting.  As a small, general-
> purpose language that is close to the hardware, I don't think
> you can do much better.  What are you proposing as a replacement?
>
>>Just to name an example, I once wrote a bourne-shell-like
>>parser that would not be difficult to embed.
>
> /boot/loader isn't just a matter of parsing an rc.conf style
> config file.  It needs the ability to talk to disk and physical
> memory and the whole thing needs to be fairly small.
>
> If you look at the installed base of computers, FORTH is
> probably the most popular language for bootloaders.

Yes, that must be the way to go.
And if you look at the installed base of computers, Windows is
probably the most popular operating system. Oh, wait...

Sorry, that was just for the joke ;)
Too much slashdot reading today...

Cheers

-- 
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 tinderbox at freebsd.org  Wed Feb 11 11:22:38 2009
From: tinderbox at freebsd.org (FreeBSD Tinderbox)
Date: Wed Feb 11 11:22:51 2009
Subject: [head tinderbox] failure on i386/i386
Message-ID: <20090211192234.852997302F@freebsd-current.sentex.ca>

TB --- 2009-02-11 17:46:38 - tinderbox 2.6 running on freebsd-current.sentex.ca
TB --- 2009-02-11 17:46:38 - starting HEAD tinderbox run for i386/i386
TB --- 2009-02-11 17:46:38 - cleaning the object tree
TB --- 2009-02-11 17:47:14 - cvsupping the source tree
TB --- 2009-02-11 17:47:14 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/i386/i386/supfile
TB --- 2009-02-11 17:47:22 - building world
TB --- 2009-02-11 17:47:22 - MAKEOBJDIRPREFIX=/obj
TB --- 2009-02-11 17:47:22 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2009-02-11 17:47:22 - TARGET=i386
TB --- 2009-02-11 17:47:22 - TARGET_ARCH=i386
TB --- 2009-02-11 17:47:22 - TZ=UTC
TB --- 2009-02-11 17:47:22 - __MAKE_CONF=/dev/null
TB --- 2009-02-11 17:47:22 - cd /src
TB --- 2009-02-11 17:47:22 - /usr/bin/make -B buildworld
>>> World build started on Wed Feb 11 17:47:24 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 Wed Feb 11 19:08:19 UTC 2009
TB --- 2009-02-11 19:08:19 - generating LINT kernel config
TB --- 2009-02-11 19:08:19 - cd /src/sys/i386/conf
TB --- 2009-02-11 19:08:19 - /usr/bin/make -B LINT
TB --- 2009-02-11 19:08:19 - building LINT kernel
TB --- 2009-02-11 19:08:19 - MAKEOBJDIRPREFIX=/obj
TB --- 2009-02-11 19:08:19 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2009-02-11 19:08:19 - TARGET=i386
TB --- 2009-02-11 19:08:19 - TARGET_ARCH=i386
TB --- 2009-02-11 19:08:19 - TZ=UTC
TB --- 2009-02-11 19:08:19 - __MAKE_CONF=/dev/null
TB --- 2009-02-11 19:08:19 - cd /src
TB --- 2009-02-11 19:08:19 - /usr/bin/make -B buildkernel KERNCONF=LINT
>>> Kernel build for LINT started on Wed Feb 11 19:08:19 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/net80211/ieee80211_amrr.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/net80211/ieee80211_crypto.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/net80211/ieee80211_crypto_ccmp.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/net80211/ieee80211_crypto_none.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/net80211/ieee80211_crypto_tkip.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/net80211/ieee80211_crypto_wep.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/net80211/ieee80211_ddb.c
/src/sys/net80211/ieee80211_ddb.c:292:43: error: octal escape sequence out of range
*** Error code 1

Stop in /obj/src/sys/LINT.
*** Error code 1

Stop in /src.
*** Error code 1

Stop in /src.
TB --- 2009-02-11 19:22:34 - WARNING: /usr/bin/make returned exit code  1 
TB --- 2009-02-11 19:22:34 - ERROR: failed to build lint kernel
TB --- 2009-02-11 19:22:34 - 4601.85 user 429.51 system 5755.94 real


http://tinderbox.des.no/tinderbox-head-HEAD-i386-i386.full
From kmacy at freebsd.org  Wed Feb 11 11:48:17 2009
From: kmacy at freebsd.org (Kip Macy)
Date: Wed Feb 11 11:48:24 2009
Subject: Profiling
In-Reply-To: <255177.96589.qm@web63905.mail.re1.yahoo.com>
References: <255177.96589.qm@web63905.mail.re1.yahoo.com>
Message-ID: <3c1674c90902111120x10337a5ei199e9ba1ae6c5a69@mail.gmail.com>

Provided your hardware supports it, you are much better off using hwpmc.

Cheers,
Kip

On Wed, Feb 11, 2009 at 9:03 AM, Barney Cordoba
<barney_cordoba@yahoo.com> wrote:
> I found a page on watson.org that says that profiling generated incorrect
> results in SMP mode. Has this changed? Its not clear how old the page is or if its current.
>
> BC
>
>
>
> _______________________________________________
> 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 rdivacky at freebsd.org  Wed Feb 11 12:17:41 2009
From: rdivacky at freebsd.org (Roman Divacky)
Date: Wed Feb 11 12:17:48 2009
Subject: nvidia users of Geforce 7050 PV
Message-ID: <20090211201436.GA14586@freebsd.org>

hi

I've just bought Geforce 7050 PV and X does not
start. I use the nvidia driver (tried 3 versions
- 177.80 and two 180.x flavours)

the Xorg.log is filled with

NVIDIA(0): Initialized GPU GART.

(3217 times for one session) and the LCD says
that the card is pushing it to some insane HZ
values.

it definitely worked for the very first time
I turned the computer on, but then I rebooted
and it never worked again :(

this is on 8-current as of Feb 5th if that matters.

can someone please comment (I have the same card
and it (does not) works etc.)

thnx!

roman
-------------- 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/20090211/449c6c40/attachment.pgp
From scrappy at hub.org  Wed Feb 11 12:41:41 2009
From: scrappy at hub.org (Marc G. Fournier)
Date: Wed Feb 11 12:46:38 2009
Subject: nvidia users of Geforce 7050 PV
In-Reply-To: <20090211201436.GA14586@freebsd.org>
References: <20090211201436.GA14586@freebsd.org>
Message-ID: <20090211162217.X14664@hub.org>


xorg 7.3 or 7.4?  I just downgraded to 7.3 due to font issues (couldnt' 
read them), but haven't tried re-enablin the nvidia-driver yet ...

On Wed, 11 Feb 2009, Roman Divacky wrote:

> hi
>
> I've just bought Geforce 7050 PV and X does not
> start. I use the nvidia driver (tried 3 versions
> - 177.80 and two 180.x flavours)
>
> the Xorg.log is filled with
>
> NVIDIA(0): Initialized GPU GART.
>
> (3217 times for one session) and the LCD says
> that the card is pushing it to some insane HZ
> values.
>
> it definitely worked for the very first time
> I turned the computer on, but then I rebooted
> and it never worked again :(
>
> this is on 8-current as of Feb 5th if that matters.
>
> can someone please comment (I have the same card
> and it (does not) works etc.)
>
> thnx!
>
> roman
>

----
Marc G. Fournier           Hub.Org Networking Services (http://www.hub.org)
Email . scrappy@hub.org                              MSN . scrappy@hub.org
Yahoo . yscrappy               Skype: hub.org        ICQ . 7615664
From buganini at gmail.com  Wed Feb 11 12:52:39 2009
From: buganini at gmail.com (Buganini)
Date: Wed Feb 11 12:52:47 2009
Subject: modular kernconf
Message-ID: <e5b1e8d40902111231y23611fc4w5db3fe3c40fbb15a@mail.gmail.com>

(on i386 or amd64)
I think it would be good to modularize kernconf.
Now my kernconf include GENERIC, then add things I need,
but I need to nodevice/nooptions many things I dont want.
Maybe we can split GENERIC into several parts,
the first parts is things before "device fdc" and atkbc, syscons,
power sections.
The others could be only one part or seperated to parts like SCSI,
NIC, WIRELESS, USB...etc.

This way I can customize my kernconf cleanly and easily.
Like today I want to try USB2, I just change the GENERIC to USB2, then
I got what I want.

I dont like to make a replica GENERIC then modify it,
because sometimes options in the SCHED section changes,
and in this case, if I want to try USB2, things become dirty.

Or any better ideas?
From cswiger at mac.com  Wed Feb 11 14:01:27 2009
From: cswiger at mac.com (Chuck Swiger)
Date: Wed Feb 11 14:01:34 2009
Subject: modular kernconf
In-Reply-To: <e5b1e8d40902111231y23611fc4w5db3fe3c40fbb15a@mail.gmail.com>
References: <e5b1e8d40902111231y23611fc4w5db3fe3c40fbb15a@mail.gmail.com>
Message-ID: <FF758FB0-DA6E-4AE4-A575-A4CDC4B65FD6@mac.com>

On Feb 11, 2009, at 12:31 PM, Buganini wrote:
[ ... ]
> This way I can customize my kernconf cleanly and easily.
> Like today I want to try USB2, I just change the GENERIC to USB2, then
> I got what I want.
>
> I dont like to make a replica GENERIC then modify it,
> because sometimes options in the SCHED section changes,
> and in this case, if I want to try USB2, things become dirty.
>
> Or any better ideas?

You should look into the way the include directive is used for the SMP  
and PAE kernels (ie, /usr/src/sys/i386/conf/SMP).  You can make  
specific changes to GENERIC to enable or disable things without having  
to roll an entire kernel config file....

Regards,
-- 
-Chuck

From trebestie at gmail.com  Wed Feb 11 14:07:54 2009
From: trebestie at gmail.com (Diego Depaoli)
Date: Wed Feb 11 14:08:01 2009
Subject: nvidia users of Geforce 7050 PV
In-Reply-To: <20090211201436.GA14586@freebsd.org>
References: <20090211201436.GA14586@freebsd.org>
Message-ID: <83e5fb980902111337l5dc4c74dq6041cac459ae570f@mail.gmail.com>

On 2/11/09, Roman Divacky <rdivacky@freebsd.org> wrote:
> hi
>
> I've just bought Geforce 7050 PV and X does not
> start. I use the nvidia driver (tried 3 versions
> - 177.80 and two 180.x flavours)
> can someone please comment (I have the same card
> and it (does not) works etc.)

That one?
(--) PCI:*(0@0:18:0) nVidia Corporation GeForce 7050 PV / nForce 630a
rev 162, Mem @ 0xfc000000/0, 0xd0000000/0, 0xfb000000/0, BIOS @
0x????????/131072

It works with 180.22 driver, Xorg 7.4 on -CURRENT #13: Wed Feb 11
21:44:42 CET 2009

Cheers
-- 
Diego Depaoli
From army.of.root at googlemail.com  Wed Feb 11 14:22:39 2009
From: army.of.root at googlemail.com (army.of.root)
Date: Wed Feb 11 14:45:55 2009
Subject: modular kernconf
In-Reply-To: <e5b1e8d40902111231y23611fc4w5db3fe3c40fbb15a@mail.gmail.com>
References: <e5b1e8d40902111231y23611fc4w5db3fe3c40fbb15a@mail.gmail.com>
Message-ID: <49934959.4060803@gmail.com>

Buganini wrote:
> (on i386 or amd64)
> I think it would be good to modularize kernconf.
> Now my kernconf include GENERIC, then add things I need,
> but I need to nodevice/nooptions many things I dont want.
> Maybe we can split GENERIC into several parts,
> the first parts is things before "device fdc" and atkbc, syscons,
> power sections.
> The others could be only one part or seperated to parts like SCSI,
> NIC, WIRELESS, USB...etc.
> 
> This way I can customize my kernconf cleanly and easily.
> Like today I want to try USB2, I just change the GENERIC to USB2, then
> I got what I want.
> 
> I dont like to make a replica GENERIC then modify it,
> because sometimes options in the SCHED section changes,
> and in this case, if I want to try USB2, things become dirty.

Hi,

I would really like the kernconf to stay in one file.
What would help is a more well structure in the GENERIC and
extensive documentation for what a specific module is good for
and what depends on it and what it depends on.

I did also try the usb2 stack a while ago and got a bit confused.

:) regards

PS: Thanks to all Devs for the pure awesomness of FreeBSD!

From svein-listmail at stillbilde.net  Wed Feb 11 15:20:50 2009
From: svein-listmail at stillbilde.net (Svein Skogen (listmail account))
Date: Wed Feb 11 15:20:57 2009
Subject: modular kernconf
In-Reply-To: <FF758FB0-DA6E-4AE4-A575-A4CDC4B65FD6@mac.com>
References: <e5b1e8d40902111231y23611fc4w5db3fe3c40fbb15a@mail.gmail.com>
	<FF758FB0-DA6E-4AE4-A575-A4CDC4B65FD6@mac.com>
Message-ID: <49935993.50303@stillbilde.net>

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

Chuck Swiger wrote:
> On Feb 11, 2009, at 12:31 PM, Buganini wrote:
> [ ... ]
>> This way I can customize my kernconf cleanly and easily.
>> Like today I want to try USB2, I just change the GENERIC to USB2, then
>> I got what I want.
>>
>> I dont like to make a replica GENERIC then modify it,
>> because sometimes options in the SCHED section changes,
>> and in this case, if I want to try USB2, things become dirty.
>>
>> Or any better ideas?
> 
> You should look into the way the include directive is used for the SMP
> and PAE kernels (ie, /usr/src/sys/i386/conf/SMP).  You can make specific
> changes to GENERIC to enable or disable things without having to roll an
> entire kernel config file....
> 
> Regards,

Can the kernel file (that contains the include directive) contain an
opposite of the option and device, such as no_option or no_device?

//Svein


- --
- --------+-------------------+-------------------------------
  /"\   |Svein Skogen       | svein@d80.iso100.no
  \ /   |Solberg ?stli 9    | PGP Key:  0xE5E76831
   X    |2020 Skedsmokorset | svein@jernhuset.no
  / \   |Norway             | PGP Key:  0xCE96CE13
        |                   | svein@stillbilde.net
 ascii  |                   | PGP Key:  0x58CD33B6
 ribbon |System Admin       | svein-listmail@stillbilde.net
Campaign|stillbilde.net     | PGP Key:  0x22D494A4
        +-------------------+-------------------------------
        |msn messenger:     | Mobile Phone: +47 907 03 575
        |svein@jernhuset.no | RIPE handle:    SS16503-RIPE
- --------+-------------------+-------------------------------
  Picture Gallery: https://gallery.stillbilde.net/v/svein/
- ------------------------------------------------------------
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkmTWZMACgkQODUnwSLUlKQBMQCgqPnymLv06QkHnqieoms0fg1Q
twAAoICQrkQGusjghbkmPSCDwMMbH7I9
=rp5Y
-----END PGP SIGNATURE-----
From atkin901 at yahoo.com  Wed Feb 11 15:26:57 2009
From: atkin901 at yahoo.com (Mark Atkinson)
Date: Wed Feb 11 15:27:04 2009
Subject: memory alignment problems with -current on amd64? [Found Cause]
References: <gl7hu4$q7k$1@ger.gmane.org> <gmqbv1$jhe$1@ger.gmane.org>
	<gmsnin$qg9$1@ger.gmane.org>
	<ca3526250902110900r6e3703c2gf4f63678949a2e33@mail.gmail.com>
Message-ID: <gmvmrb$hg2$1@ger.gmane.org>

Alan Cox wrote:

> On Tue, Feb 10, 2009 at 2:20 PM, Mark Atkinson <atkin901@yahoo.com> wrote:
> [snip]
>>
>>
>>
>> Well, taking the information I knew -- OCT 15th == good, Mid DEC == BAD,
>> I trolled every commit logged between.   Eventually I found this one:
>>
>> http://svn.freebsd.org/viewvc/base?view=revision&revision=185715
>>
>> http://docs.freebsd.org/cgi/mid.cgi?200812061937.mB6JbqAI003273
>>
>> I set vm.pmap.pg_ps_enabled="0" in /boot/loader.conf, and
>> was able to complete buildworld and -j16 buildworld and -j8 buildkernel
>> no problem.
>>
>> It appears superpage mapping causes alignment problems on this box.
> 
> 
> Can you please provide more detailed information about this machine, in
> particular, the processor including the revision?  It would also be
> helpful to see what gdb says about a couple of these crashes,
> specifically, the machine registers at the time of the exception.

Is there something specifically preventing cores during buildworld?  I can't
find one after a bus error.   I'll try to find something to dump the
revision for me.  Here's the verbose boot for the processor.

CPU: Quad-Core AMD Opteron(tm) Processor 2352 (2100.09-MHz K8-class CPU)
  Origin = "AuthenticAMD"  Id = 0x100f23  Stepping = 3
 
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=0xee400800<SYSCALL,MMX+,FFXSR,Page1GB,RDTSCP,LM,3DNow
+,3DNow!>
  AMD
Features2=0x7ff<LAHF,CMP,SVM,ExtAPIC,CR8,ABM,SSE4A,MAS,Prefetch,OSVW,IBS>
  TSC: P-state invariant
  Cores per package: 4
L1 2MB data TLB: 48 entries, fully associative
L1 2MB instruction TLB: 16 entries, fully associative
L1 4KB data TLB: 48 entries, fully associative
L1 4KB instruction TLB: 32 entries, fully associative
L1 data cache: 64 kbytes, 64 bytes/line, 1 lines/tag, 2-way associative
L1 instruction cache: 64 kbytes, 64 bytes/line, 1 lines/tag, 2-way
associative
L2 2MB data TLB: 128 entries, 2-way associative
L2 2MB instruction TLB: 0 entries, 2-way associative
L2 4KB data TLB: 512 entries, 4-way associative
L2 4KB instruction TLB: 512 entries, 4-way associative
L2 unified cache: 512 kbytes, 64 bytes/line, 1 lines/tag, 16-way associative
usable memory = 10720198656 (10223 MB)
Physical memory chunk(s):
0x0000000000001000 - 0x000000000009bfff, 634880 bytes (155 pages)
0x0000000000f55000 - 0x00000000cfe4dfff, 3471806464 bytes (847609 pages)
0x00000000cfe56000 - 0x00000000cfe56fff, 4096 bytes (1 pages)
0x0000000100000000 - 0x000000029d212fff, 6931165184 bytes (1692179 pages)


-- 
Mark Atkinson
atkin901@yahoo.com
(!wired)?(coffee++):(wired);

From alan.l.cox at gmail.com  Thu Feb 12 01:21:08 2009
From: alan.l.cox at gmail.com (Alan Cox)
Date: Thu Feb 12 01:21:15 2009
Subject: memory alignment problems with -current on amd64? [Found Cause]
In-Reply-To: <gmvmrb$hg2$1@ger.gmane.org>
References: <gl7hu4$q7k$1@ger.gmane.org> <gmqbv1$jhe$1@ger.gmane.org>
	<gmsnin$qg9$1@ger.gmane.org>
	<ca3526250902110900r6e3703c2gf4f63678949a2e33@mail.gmail.com>
	<gmvmrb$hg2$1@ger.gmane.org>
Message-ID: <ca3526250902120121s360a2a8fidad95e983385c891@mail.gmail.com>

Do you know why NX is disabled on this processor?  If possible, could you
re-enable it and vm.pmap.pg_ps_enabled, and see if you still have the same
problem.

On Wed, Feb 11, 2009 at 5:26 PM, Mark Atkinson <atkin901@yahoo.com> wrote:

> Alan Cox wrote:
>
> > On Tue, Feb 10, 2009 at 2:20 PM, Mark Atkinson <atkin901@yahoo.com>
> wrote:
> > [snip]
> >>
> >>
> >>
> >> Well, taking the information I knew -- OCT 15th == good, Mid DEC == BAD,
> >> I trolled every commit logged between.   Eventually I found this one:
> >>
> >> http://svn.freebsd.org/viewvc/base?view=revision&revision=185715
> >>
> >> http://docs.freebsd.org/cgi/mid.cgi?200812061937.mB6JbqAI003273
> >>
> >> I set vm.pmap.pg_ps_enabled="0" in /boot/loader.conf, and
> >> was able to complete buildworld and -j16 buildworld and -j8 buildkernel
> >> no problem.
> >>
> >> It appears superpage mapping causes alignment problems on this box.
> >
> >
> > Can you please provide more detailed information about this machine, in
> > particular, the processor including the revision?  It would also be
> > helpful to see what gdb says about a couple of these crashes,
> > specifically, the machine registers at the time of the exception.
>
> Is there something specifically preventing cores during buildworld?  I
> can't
> find one after a bus error.   I'll try to find something to dump the
> revision for me.  Here's the verbose boot for the processor.
>
> CPU: Quad-Core AMD Opteron(tm) Processor 2352 (2100.09-MHz K8-class CPU)
>  Origin = "AuthenticAMD"  Id = 0x100f23  Stepping = 3
>
>
> 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=0xee400800<SYSCALL,MMX+,FFXSR,Page1GB,RDTSCP,LM,3DNow
> +,3DNow!>
>  AMD
> Features2=0x7ff<LAHF,CMP,SVM,ExtAPIC,CR8,ABM,SSE4A,MAS,Prefetch,OSVW,IBS>
>  TSC: P-state invariant
>  Cores per package: 4
> L1 2MB data TLB: 48 entries, fully associative
> L1 2MB instruction TLB: 16 entries, fully associative
> L1 4KB data TLB: 48 entries, fully associative
> L1 4KB instruction TLB: 32 entries, fully associative
> L1 data cache: 64 kbytes, 64 bytes/line, 1 lines/tag, 2-way associative
> L1 instruction cache: 64 kbytes, 64 bytes/line, 1 lines/tag, 2-way
> associative
> L2 2MB data TLB: 128 entries, 2-way associative
> L2 2MB instruction TLB: 0 entries, 2-way associative
> L2 4KB data TLB: 512 entries, 4-way associative
> L2 4KB instruction TLB: 512 entries, 4-way associative
> L2 unified cache: 512 kbytes, 64 bytes/line, 1 lines/tag, 16-way
> associative
> usable memory = 10720198656 (10223 MB)
> Physical memory chunk(s):
> 0x0000000000001000 - 0x000000000009bfff, 634880 bytes (155 pages)
> 0x0000000000f55000 - 0x00000000cfe4dfff, 3471806464 bytes (847609 pages)
> 0x00000000cfe56000 - 0x00000000cfe56fff, 4096 bytes (1 pages)
> 0x0000000100000000 - 0x000000029d212fff, 6931165184 bytes (1692179 pages)
>
>
> --
> Mark Atkinson
> atkin901@yahoo.com
> (!wired)?(coffee++):(wired);
>
> _______________________________________________
> 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 phk at phk.freebsd.dk  Thu Feb 12 02:01:31 2009
From: phk at phk.freebsd.dk (Poul-Henning Kamp)
Date: Thu Feb 12 02:01:39 2009
Subject: @188498: u3g works, Xorg does not
Message-ID: <1650.1234431504@critter.freebsd.dk>


I just tried @188498 on my laptop.

The good news is that with USB2 my 3G modem works.

The bad news is that Xorg does not, it takes no mouse or keyboard
input.

Interestingly, changing to a different VTY with CTRL-ALT-Fx works.

VTY switches use SIGUSR1 as far as I remember.

That could indicate that recent tty/syscons changes are to blame
and that Xorg is simply not getting the events it is waiting for.

-- 
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 rbgarga at gmail.com  Thu Feb 12 02:17:00 2009
From: rbgarga at gmail.com (Renato Botelho)
Date: Thu Feb 12 02:17:06 2009
Subject: @188498: u3g works, Xorg does not
In-Reply-To: <1650.1234431504@critter.freebsd.dk>
References: <1650.1234431504@critter.freebsd.dk>
Message-ID: <747dc8f30902120216o7755a234t435e5ed7120f1b0e@mail.gmail.com>

On Thu, Feb 12, 2009 at 7:38 AM, Poul-Henning Kamp <phk@phk.freebsd.dk> wrote:
>
> I just tried @188498 on my laptop.
>
> The good news is that with USB2 my 3G modem works.
>
> The bad news is that Xorg does not, it takes no mouse or keyboard
> input.
>
> Interestingly, changing to a different VTY with CTRL-ALT-Fx works.
>
> VTY switches use SIGUSR1 as far as I remember.
>
> That could indicate that recent tty/syscons changes are to blame
> and that Xorg is simply not getting the events it is waiting for.

Do you have hald running? If not, try to add following line to
ServerLayout section of xorg.conf

Option         "AllowEmptyInput" "off"

-- 
Renato Botelho
From max at love2party.net  Thu Feb 12 02:18:06 2009
From: max at love2party.net (Max Laier)
Date: Thu Feb 12 02:18:13 2009
Subject: @188498: u3g works, Xorg does not
In-Reply-To: <1650.1234431504@critter.freebsd.dk>
References: <1650.1234431504@critter.freebsd.dk>
Message-ID: <200902121118.03599.max@love2party.net>

On Thursday 12 February 2009 10:38:24 Poul-Henning Kamp wrote:
> I just tried @188498 on my laptop.
>
> The good news is that with USB2 my 3G modem works.
>
> The bad news is that Xorg does not, it takes no mouse or keyboard
> input.
>
> Interestingly, changing to a different VTY with CTRL-ALT-Fx works.
>
> VTY switches use SIGUSR1 as far as I remember.
>
> That could indicate that recent tty/syscons changes are to blame
> and that Xorg is simply not getting the events it is waiting for.

There have been serious changes in how xorg detects input (see ports/UPDATING 
20090123).  It now relies on hald to provide keyboard and mouse configuration.  
For us keyboard layout it's as simple as starting dbus and hald 
(dbus_enable="YES" hald_enable="YES") for localization you need something like 
this:

$cat /usr/local/etc/hal/fdi/policy/x11-input.fdi 
<?xml version="1.0" encoding="ISO-8859-1"?>
<deviceinfo version="0.2">
  <device>
    <match key="info.capabilities" contains="input.keyboard">
      <merge key="input.xkb.layout" type="string">de</merge>
    </match>
  </device>
</deviceinfo>

Ugly, isn't it.  Of course you want to change "de" to whatever your layout is 
called.

-- 
/"\  Best regards,                      | mlaier@freebsd.org
\ /  Max Laier                          | ICQ #67774661
 X   http://pf4freebsd.love2party.net/  | mlaier@EFnet
/ \  ASCII Ribbon Campaign              | Against HTML Mail and News
From hselasky at c2i.net  Thu Feb 12 02:23:31 2009
From: hselasky at c2i.net (Hans Petter Selasky)
Date: Thu Feb 12 02:23:39 2009
Subject: @188498: u3g works, Xorg does not
In-Reply-To: <200902121118.03599.max@love2party.net>
References: <1650.1234431504@critter.freebsd.dk>
	<200902121118.03599.max@love2party.net>
Message-ID: <200902121125.57378.hselasky@c2i.net>

Before enabling hald and USB2 at the same time, read the USB wiki:

http://wiki.freebsd.org/USB

--HPS
From akm at theinternet.com.au  Thu Feb 12 02:24:52 2009
From: akm at theinternet.com.au (Andrew Milton)
Date: Thu Feb 12 02:25:00 2009
Subject: @188498: u3g works, Xorg does not
In-Reply-To: <1650.1234431504@critter.freebsd.dk>
References: <1650.1234431504@critter.freebsd.dk>
Message-ID: <20090212101142.GE8296@camelot.theinternet.com.au>

+-------[ Poul-Henning Kamp ]----------------------
| 
| I just tried @188498 on my laptop.
| 
| The good news is that with USB2 my 3G modem works.
| 
| The bad news is that Xorg does not, it takes no mouse or keyboard
| input.
| 
| Interestingly, changing to a different VTY with CTRL-ALT-Fx works.
| 
| VTY switches use SIGUSR1 as far as I remember.
| 
| That could indicate that recent tty/syscons changes are to blame
| and that Xorg is simply not getting the events it is waiting for.

I see the same behaviour (on 7.1), if I kill kdm, when it 
restarts it works fine and so does the resultant session.

I think it's an X-org 7.4 issue.

-- 
Andrew Milton
akm@theinternet.com.au
From phk at phk.freebsd.dk  Thu Feb 12 02:31:09 2009
From: phk at phk.freebsd.dk (Poul-Henning Kamp)
Date: Thu Feb 12 02:31:16 2009
Subject: @188498: u3g works, Xorg does not 
In-Reply-To: Your message of "Thu, 12 Feb 2009 11:18:03 +0100."
	<200902121118.03599.max@love2party.net> 
Message-ID: <2029.1234434667@critter.freebsd.dk>

In message <200902121118.03599.max@love2party.net>, Max Laier writes:


>There have been serious changes in how xorg detects input (see ports/UPDATING 
>20090123).  It now relies on hald to provide keyboard and mouse configuration.  
So, obviously, our Xorg port should start hald automatically, shouldn't it ?

This was a freshly built system with freshly built packages, I would
generally expect that to DTRT.

Poul-Henning

-- 
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 phk at phk.freebsd.dk  Thu Feb 12 02:40:31 2009
From: phk at phk.freebsd.dk (Poul-Henning Kamp)
Date: Thu Feb 12 02:40:38 2009
Subject: @188498: u3g works, Xorg does not 
In-Reply-To: Your message of "Thu, 12 Feb 2009 11:18:10 +0100."
	<20090212101809.GB78543@rink.nu> 
Message-ID: <1521.1234435228@critter.freebsd.dk>

In message <20090212101809.GB78543@rink.nu>, Rink Springer writes:
>On Thu, Feb 12, 2009 at 09:38:24AM +0000, Poul-Henning Kamp wrote:
>> That could indicate that recent tty/syscons changes are to blame
>> and that Xorg is simply not getting the events it is waiting for.
>
>I seem to recall that hald is a requirement for X these days; have you
>tried enabling it?

That seems to solve the problem.

Thanks to all who suggested it.

-- 
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 haro at kgt.co.jp  Thu Feb 12 02:43:52 2009
From: haro at kgt.co.jp (haro@kgt.co.jp)
Date: Thu Feb 12 02:43:59 2009
Subject: @188498: u3g works, Xorg does not
In-Reply-To: <747dc8f30902120216o7755a234t435e5ed7120f1b0e@mail.gmail.com>
References: <1650.1234431504@critter.freebsd.dk>
	<747dc8f30902120216o7755a234t435e5ed7120f1b0e@mail.gmail.com>
Message-ID: <20090212.192851.57971498.haro@kgt.co.jp>

From: Renato Botelho <rbgarga@gmail.com>
Date: Thu, 12 Feb 2009 08:16:58 -0200
::On Thu, Feb 12, 2009 at 7:38 AM, Poul-Henning Kamp <phk@phk.freebsd.dk> wrote:
::>
::> I just tried @188498 on my laptop.
::>
::> The good news is that with USB2 my 3G modem works.
::>
::> The bad news is that Xorg does not, it takes no mouse or keyboard
::> input.
::>
::> Interestingly, changing to a different VTY with CTRL-ALT-Fx works.
::>
::> VTY switches use SIGUSR1 as far as I remember.
::>
::> That could indicate that recent tty/syscons changes are to blame
::> and that Xorg is simply not getting the events it is waiting for.
::
::Do you have hald running? If not, try to add following line to
::ServerLayout section of xorg.conf
::
::Option         "AllowEmptyInput" "off"

The description in /usr/ports/UPDATING is wrong about this.
It should be in ServerFlags section, not the ServerLayout section.
Adding following line to xorg.conf worked for me:

Section "ServerFlags"
        Option "AllowEmptyInput" "off"
EndSection

Hope this helps,
  Haro
=-----------------------------------------------------------------------
           _ _    Munehiro (haro) Matsuda
 -|- /_\  |_|_|   KGT Inc.
 /|\ |_|  |_|_|

From phk at phk.freebsd.dk  Thu Feb 12 02:51:54 2009
From: phk at phk.freebsd.dk (Poul-Henning Kamp)
Date: Thu Feb 12 02:52:02 2009
Subject: @188498: u3g works, Xorg does not 
In-Reply-To: Your message of "Thu, 12 Feb 2009 11:25:55 +0100."
	<200902121125.57378.hselasky@c2i.net> 
Message-ID: <1878.1234435909@critter.freebsd.dk>

In message <200902121125.57378.hselasky@c2i.net>, Hans Petter Selasky writes:

>Before enabling hald and USB2 at the same time, read the USB wiki:
>
>http://wiki.freebsd.org/USB

I added the following two lines to libmap.conf:

	libusb-0.1.so libusb20.so
	libusb-0.1.so.8 libusb20.so.1

But that does not seem to help much.

hald(8) does not seem to be linked (dynamically) against libusb ?

	critter# ldd /usr/local/sbin/hald | grep -i usb 
	critter# 

So is it statically linked ?

In that case the Wiki should state that libmap.conf is not going to help.

Why doesn't the wiki have a libmap.conf examble btw ?



-- 
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 phk at phk.freebsd.dk  Thu Feb 12 03:00:54 2009
From: phk at phk.freebsd.dk (Poul-Henning Kamp)
Date: Thu Feb 12 03:01:06 2009
Subject: @188498: u3g works, Xorg does not 
In-Reply-To: Your message of "Thu, 12 Feb 2009 19:28:51 +0900."
	<20090212.192851.57971498.haro@kgt.co.jp> 
Message-ID: <1346.1234436450@critter.freebsd.dk>

In message <20090212.192851.57971498.haro@kgt.co.jp>, haro@kgt.co.jp writes:

>
>Section "ServerFlags"
>        Option "AllowEmptyInput" "off"
>EndSection

That also works, and avoids four hald processes on the system, so
I prefer this fix.

-- 
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 hselasky at c2i.net  Thu Feb 12 03:18:44 2009
From: hselasky at c2i.net (Hans Petter Selasky)
Date: Thu Feb 12 03:18:51 2009
Subject: @188498: u3g works, Xorg does not
In-Reply-To: <1878.1234435909@critter.freebsd.dk>
References: <1878.1234435909@critter.freebsd.dk>
Message-ID: <200902121221.07622.hselasky@c2i.net>

On Thursday 12 February 2009, Poul-Henning Kamp wrote:
> In message <200902121125.57378.hselasky@c2i.net>, Hans Petter Selasky 
writes:
> >Before enabling hald and USB2 at the same time, read the USB wiki:
> >
> >http://wiki.freebsd.org/USB
>
> I added the following two lines to libmap.conf:
>
> 	libusb-0.1.so libusb20.so
> 	libusb-0.1.so.8 libusb20.so.1
>
> But that does not seem to help much.
>
> hald(8) does not seem to be linked (dynamically) against libusb ?
>
> 	critter# ldd /usr/local/sbin/hald | grep -i usb
> 	critter#
>
> So is it statically linked ?

No,

dnl Check libusb
AC_ARG_ENABLE([usb],
              AS_HELP_STRING([--disable-usb], [Do not use libusb]),
              [use_usb=$enableval], [use_usb=yes])
if test "x$use_usb" = "xyes" ; then
        AC_CHECK_HEADERS([usb.h], [USE_LIBUSB=yes], [USE_LIBUSB=no])
        if test "x$USE_LIBUSB" = "xyes"; then
                AC_CHECK_LIB([usb], [usb_find_devices], [USE_LIBUSB=yes], 
[USE_LIBUSB=no])
        fi
else
        USE_LIBUSB=no
fi

You need to have libusb0.1.x installed before building hald.

The following file is no longer useful with USB2. I could make some patches 
for HAL, but I don't know where to send them.

/usr/ports/sysutils/hal/work/hal-0.5.11/hald/freebsd/hf-usb.c

>
> In that case the Wiki should state that libmap.conf is not going to help.
>
> Why doesn't the wiki have a libmap.conf examble btw ?

Fixed.

--HPS
From rink at FreeBSD.org  Thu Feb 12 03:32:09 2009
From: rink at FreeBSD.org (Rink Springer)
Date: Thu Feb 12 03:32:17 2009
Subject: @188498: u3g works, Xorg does not
In-Reply-To: <1650.1234431504@critter.freebsd.dk>
References: <1650.1234431504@critter.freebsd.dk>
Message-ID: <20090212101809.GB78543@rink.nu>

On Thu, Feb 12, 2009 at 09:38:24AM +0000, Poul-Henning Kamp wrote:
> That could indicate that recent tty/syscons changes are to blame
> and that Xorg is simply not getting the events it is waiting for.

I seem to recall that hald is a requirement for X these days; have you
tried enabling it?

Regards,

-- 
Rink P.W. Springer                                - http://rink.nu
"Chance favours the prepared mind"
- Penn
From gary.jennejohn at freenet.de  Thu Feb 12 03:58:36 2009
From: gary.jennejohn at freenet.de (Gary Jennejohn)
Date: Thu Feb 12 03:58:43 2009
Subject: @188498: u3g works, Xorg does not
In-Reply-To: <1346.1234436450@critter.freebsd.dk>
References: <20090212.192851.57971498.haro@kgt.co.jp>
	<1346.1234436450@critter.freebsd.dk>
Message-ID: <20090212125828.2ff46a75@ernst.jennejohn.org>

On Thu, 12 Feb 2009 11:00:50 +0000
"Poul-Henning Kamp" <phk@phk.freebsd.dk> wrote:

> In message <20090212.192851.57971498.haro@kgt.co.jp>, haro@kgt.co.jp writes:
> 
> >
> >Section "ServerFlags"
> >        Option "AllowEmptyInput" "off"
> >EndSection
> 
> That also works, and avoids four hald processes on the system, so
> I prefer this fix.
> 

I agree.  Especially since hald eats 100% of one of my cores (AMD64 X2)
apparently doing nothing.

I remade the xorg server w/o hal and am now a much happier camper.

---
Gary Jennejohn
From phk at phk.freebsd.dk  Thu Feb 12 04:02:02 2009
From: phk at phk.freebsd.dk (Poul-Henning Kamp)
Date: Thu Feb 12 04:02:10 2009
Subject: @188498: u3g works, Xorg does not 
In-Reply-To: Your message of "Thu, 12 Feb 2009 12:58:28 +0100."
	<20090212125828.2ff46a75@ernst.jennejohn.org> 
Message-ID: <18203.1234440103@critter.freebsd.dk>

In message <20090212125828.2ff46a75@ernst.jennejohn.org>, Gary Jennejohn writes:
>On Thu, 12 Feb 2009 11:00:50 +0000
>"Poul-Henning Kamp" <phk@phk.freebsd.dk> wrote:
>
>> In message <20090212.192851.57971498.haro@kgt.co.jp>, haro@kgt.co.jp writes:
>> 
>> >
>> >Section "ServerFlags"
>> >        Option "AllowEmptyInput" "off"
>> >EndSection
>> 
>> That also works, and avoids four hald processes on the system, so
>> I prefer this fix.
>> 
>
>I agree.  Especially since hald eats 100% of one of my cores (AMD64 X2)
>apparently doing nothing.
>
>I remade the xorg server w/o hal and am now a much happier camper.

The ports defaults should be changed IMO.

-- 
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 oliver.pntr at gmail.com  Thu Feb 12 04:14:19 2009
From: oliver.pntr at gmail.com (Oliver Pinter)
Date: Thu Feb 12 04:14:27 2009
Subject: Fwd: [patch] libc Berkeley DB information leak
In-Reply-To: <6101e8c40901231246j264c3e43y7989d14fb9b77037@mail.gmail.com>
References: <20090115144459.GA3154@a91-153-125-115.elisa-laajakaista.fi>
	<6101e8c40901231246j264c3e43y7989d14fb9b77037@mail.gmail.com>
Message-ID: <6101e8c40902120410p5b7aedf9j87efd75e1f3d2c59@mail.gmail.com>

---------- Forwarded message ----------
From: Oliver Pinter <oliver.pntr@gmail.com>
Date: Fri, 23 Jan 2009 21:46:33 +0100
Subject: Re: [patch] libc Berkeley DB information leak
To: Jaakko Heinonen <jh@saunalahti.fi>
Cc: freebsd-security@freebsd.org

On 1/15/09, Jaakko Heinonen <jh@saunalahti.fi> wrote:
>
> Hi,
>
> FreeBSD libc Berkeley DB can leak sensitive information to database
> files. The problem is that it writes uninitialized memory obtained from
> malloc(3) to database files.
>
> You can use this simple test program to reproduce the behavior:
>
> http://www.saunalahti.fi/~jh3/dbtest.c
>
> Run the program and see the resulting test.db file which will contain a
> sequence of 0xa5 bytes directly from malloc(3). (See malloc(3) manual
> page for the explanation for the "J" flag if you need more information.)
>
> This has been reported as PR 123529
> (http://www.freebsd.org/cgi/query-pr.cgi?pr=123529) which contains a
> real information leak case. The PR is assigned to secteam and I have
> also personally reported it to secteam but I haven't heard a word from
> secteam members.
>
> A code to initialize malloc'd memory exists but the feature must be
> enabled with PURIFY macro. With following patch applied
> the test program doesn't output 0xa5 bytes to the database file:
>
> %%%
> Index: lib/libc/db/hash/hash_buf.c
> ===================================================================
> --- lib/libc/db/hash/hash_buf.c	(revision 187214)
> +++ lib/libc/db/hash/hash_buf.c	(working copy)
> @@ -57,6 +57,7 @@ __FBSDID("$FreeBSD$");
>  #include <stddef.h>
>  #include <stdio.h>
>  #include <stdlib.h>
> +#include <string.h>
>
>  #ifdef DEBUG
>  #include <assert.h>
> Index: lib/libc/db/Makefile.inc
> ===================================================================
> --- lib/libc/db/Makefile.inc	(revision 187214)
> +++ lib/libc/db/Makefile.inc	(working copy)
> @@ -3,6 +3,8 @@
>  #
>  CFLAGS+=-D__DBINTERFACE_PRIVATE
>
> +CFLAGS+=-DPURIFY
> +
>  .include "${.CURDIR}/db/btree/Makefile.inc"
>  .include "${.CURDIR}/db/db/Makefile.inc"
>  .include "${.CURDIR}/db/hash/Makefile.inc"
> %%%
>
> Could someone consider committing this or some other fix for the
> problem?
>
> --
> Jaakko
> _______________________________________________
> freebsd-security@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-security
> To unsubscribe, send any mail to "freebsd-security-unsubscribe@freebsd.org"
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-fix-mem-info-leak.patch
Type: text/x-diff
Size: 960 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20090212/bcf2527c/0001-fix-mem-info-leak.bin
From bruce at cran.org.uk  Thu Feb 12 04:38:01 2009
From: bruce at cran.org.uk (Bruce Cran)
Date: Thu Feb 12 04:38:09 2009
Subject: Duplicate slice entries in /dev
Message-ID: <20090212123753.1602cb81@gluon>

I'm running -CURRENT from about a week ago, and have noticed that
duplicate entries are showing up in /dev before a slice is mounted.
For example I created a swap-based md disk, used fdisk to write a
partition table containing a single msdos partition and noticed that
two /dev/md0s1 entries existed.  Today I've just got a new microSD card
connected via a card reader.  I created a filesystem on /dev/da0s1 and
I see the following:

tau# fdisk /dev/da0
******* Working on device /dev/da0 *******
parameters extracted from in-core disklabel are:
cylinders=968 heads=255 sectors/track=63 (16065 blks/cyl)

parameters to be used for BIOS calculations are:
cylinders=968 heads=255 sectors/track=63 (16065 blks/cyl)

Media sector size is 512
Warning: BIOS sector numbering starts with sector 1
Information from DOS bootblock is:
The data for partition 1 is:
sysid 165 (0xa5),(FreeBSD/NetBSD/386BSD)
    start 63, size 15550857 (7593 Meg), flag 80 (active)
	beg: cyl 0/ head 1/ sector 1;
	end: cyl 967/ head 254/ sector 63
The data for partition 2 is:
<UNUSED>
The data for partition 3 is:
<UNUSED>
The data for partition 4 is:
<UNUSED>
tau# ls -l /dev/da0*
crw-r-----  1 root  operator    0,  85 Feb 12 12:28 /dev/da0
crw-r-----  1 root  operator    0,  86 Feb 12 12:28 /dev/da0s1
crw-r-----  1 root  operator    0,  86 Feb 12 12:28 /dev/da0s1
tau# mount /dev/da0s1 /mnt
tau# ls -l /dev/da0*
crw-r-----  1 root  operator    0,  85 Feb 12 12:28 /dev/da0
crw-r-----  1 root  operator    0,  86 Feb 12 12:28 /dev/da0s1
tau# umount /mnt
tau# ls -l /dev/da0*
crw-r-----  1 root  operator    0,  85 Feb 12 12:28 /dev/da0
crw-r-----  1 root  operator    0,  86 Feb 12 12:28 /dev/da0s1
crw-r-----  1 root  operator    0,  86 Feb 12 12:28 /dev/da0s1

-- 
Bruce Cran
From bzeeb-lists at lists.zabbadoz.net  Thu Feb 12 05:05:10 2009
From: bzeeb-lists at lists.zabbadoz.net (Bjoern A. Zeeb)
Date: Thu Feb 12 05:05:18 2009
Subject: [RFC] Skeleton jail (rc.d feature proposal)
In-Reply-To: <499244E6.9030205@delphij.net>
References: <499244E6.9030205@delphij.net>
Message-ID: <20090212122419.Q53478@maildrop.int.zabbadoz.net>

On Tue, 10 Feb 2009, Xin LI wrote:

Hi,

PreS: I added freebsd-jail@ to Cc:.


> Ok, some local users has prodded me in committing the "skeleton jail"
> feature, I find it useful myself but not sure if it's appropriate to
> commit it against -HEAD, so I'd like to explain it, try to present it in
> a better way, and request for comments.


I have seen lots of "skeleton jail" features the last years working
with lots of different parties and I have a private one myself tied
into some other stuff which is even more meagre than most.
  It's 2 files and 7 lines of sh and that's only because I am lazy.

I have seen everything from sh scripts to install worlds/distribution
for a jail, to the same and then remove stuff, unionfs tries and nullfs
mounts. From mergemaster setups populating worlds for jail from private
trees to restores from master images.

Some were really nice, others were .. improvable.

They all helped the people in their environment but few could use what
the others had done in their environment.


> The rc.d infrastructure would automatically mount the following
> directories from the template (when not specified, /) as read-only:
>
> 	bin
> 	lib
> 	libexec
> 	sbin
> 	usr/bin
> 	usr/include
> 	usr/lib
> 	usr/libdata
> 	usr/libexec
> 	usr/sbin
> 	usr/share

I do not have the following two on most/any of my machines:

> 	usr/src
> 	usr/obj

The correct way to do this I think would leave rc.d/jail untouched and
(pre-)populate an /etc/fstab.<jname> and use that.



Considering that my last commit messages already said that Simon and I
have big worries about all the features in /etc/rc.d/jail and would
rather remove than than keep them and that this is basically two things:

1) pre-seed a jail hierachy and etc from a source tree
2) mount some nullfs into the jail on start, unmount on stop
(I hope I didn't miss anything else)

I am wondering if this large patch cannot be reduced to a few line sh
script to seed the jail + fstab, not needing to fiddle with base for
that.

  1 #/bin/sh
  2 # $1 is DESTDIR of the jail
  3 # $2 is the jail name as in rc.conf
  4 # $3 is the skel root to mount from
  5 # other arguments are rw nullfs mounts
  6 cd /usr/src
  7 make hierachy DESTDIR=$1
  8 make distribution DESTDIR=$1
  9 for d in bin lib libexec ..;  do
10  echo "$3/${d} $1/$3 nullfs ro 0 0" >> /etc/fstab.$2
11 done
12 shift; shift; shift
13 for d in bin lib libexec ..;  do
14  echo "$3/${d} $1/$3 nullfs rw 0 0" >> /etc/fstab.$2
15 done
16 echo "Add jail_$2_mount_enable='YES' to /etc/rc.conf"

This is untested and doesn't have error checking etc.
I would even put it in a Makefile instead of doing it in sh.

A lot more flexible than anything in base will ever be.

Just my 5ct.

/bz

-- 
Bjoern A. Zeeb                      The greatest risk is not taking one.
From mexas at bristol.ac.uk  Thu Feb 12 05:51:00 2009
From: mexas at bristol.ac.uk (Anton Shterenlikht)
Date: Thu Feb 12 05:51:06 2009
Subject: @188498: u3g works, Xorg does not
In-Reply-To: <20090212125828.2ff46a75@ernst.jennejohn.org>
References: <20090212.192851.57971498.haro@kgt.co.jp>
	<1346.1234436450@critter.freebsd.dk>
	<20090212125828.2ff46a75@ernst.jennejohn.org>
Message-ID: <20090212133329.GA47985@mech-cluster238.men.bris.ac.uk>

On Thu, Feb 12, 2009 at 12:58:28PM +0100, Gary Jennejohn wrote:
> On Thu, 12 Feb 2009 11:00:50 +0000
> "Poul-Henning Kamp" <phk@phk.freebsd.dk> wrote:
> 
> > In message <20090212.192851.57971498.haro@kgt.co.jp>, haro@kgt.co.jp writes:
> > 
> > >
> > >Section "ServerFlags"
> > >        Option "AllowEmptyInput" "off"
> > >EndSection
> > 
> > That also works, and avoids four hald processes on the system, so
> > I prefer this fix.
> > 
> 
> I agree.  Especially since hald eats 100% of one of my cores (AMD64 X2)
> apparently doing nothing.
> 
> I remade the xorg server w/o hal and am now a much happier camper.

but many other x parts depend on hal:

# pkg_info -xR hal
Information for hal-0.5.11_17:

Required by:
xf86-input-keyboard-1.3.2
xf86-video-intel-2.5.1
xf86-video-vesa-2.1.0
xf86-input-mouse-1.4.0_3

and these aren't optional, I think.

-- 
Anton Shterenlikht
Room 2.6, Queen's Building
Mech Eng Dept
Bristol University
University Walk, Bristol BS8 1TR, UK
Tel: +44 (0)117 928 8233 
Fax: +44 (0)117 929 4423
From rohit.trip at gmail.com  Thu Feb 12 05:55:04 2009
From: rohit.trip at gmail.com (Rohit Tripathi)
Date: Thu Feb 12 05:55:11 2009
Subject: page fault
Message-ID: <33615c8e0902120532k52d45bf2sd44efde7ef2ed1d6@mail.gmail.com>

My kernel (compiled trunk  at Feb 6th)  did the following twice:

Fatal trap 12: page fault while in kernel mode
cpuid = 0; apic id = 00
fault virtual address - 0x796f000
fault code = supervisor read, page not present
....
....
Dumping 245 MB: wlan0: link state changed to DOWN


On a different tty, I was upgrading my kernel (after the first crash), and saw:
cc: environment corrupt; missing value for -mno-align-long-strings
From akm at theinternet.com.au  Thu Feb 12 05:56:06 2009
From: akm at theinternet.com.au (Andrew Milton)
Date: Thu Feb 12 05:56:14 2009
Subject: @188498: u3g works, Xorg does not
In-Reply-To: <20090212133329.GA47985@mech-cluster238.men.bris.ac.uk>
References: <20090212.192851.57971498.haro@kgt.co.jp>
	<1346.1234436450@critter.freebsd.dk>
	<20090212125828.2ff46a75@ernst.jennejohn.org>
	<20090212133329.GA47985@mech-cluster238.men.bris.ac.uk>
Message-ID: <20090212135415.GF8296@camelot.theinternet.com.au>

+-------[ Anton Shterenlikht ]----------------------
| On Thu, Feb 12, 2009 at 12:58:28PM +0100, Gary Jennejohn wrote:
| > On Thu, 12 Feb 2009 11:00:50 +0000
| > "Poul-Henning Kamp" <phk@phk.freebsd.dk> wrote:
| > 
| > > In message <20090212.192851.57971498.haro@kgt.co.jp>, haro@kgt.co.jp writes:
| > > 
| > > >
| > > >Section "ServerFlags"
| > > >        Option "AllowEmptyInput" "off"
| > > >EndSection
| > > 
| > > That also works, and avoids four hald processes on the system, so
| > > I prefer this fix.
| > > 
| > 
| > I agree.  Especially since hald eats 100% of one of my cores (AMD64 X2)
| > apparently doing nothing.
| > 
| > I remade the xorg server w/o hal and am now a much happier camper.
| 
| but many other x parts depend on hal:
| 
| # pkg_info -xR hal
| Information for hal-0.5.11_17:
| 
| Required by:
| xf86-input-keyboard-1.3.2
| xf86-video-intel-2.5.1
| xf86-video-vesa-2.1.0
| xf86-input-mouse-1.4.0_3
| 
| and these aren't optional, I think.

But if xdm or other display managers are started from /etc/tty, X starts
before hal does leaving you with an unresponsive login screen.

-- 
Andrew Milton
akm@theinternet.com.au
From mexas at bristol.ac.uk  Thu Feb 12 06:24:15 2009
From: mexas at bristol.ac.uk (Anton Shterenlikht)
Date: Thu Feb 12 06:24:22 2009
Subject: @188498: u3g works, Xorg does not
In-Reply-To: <alpine.BSF.2.00.0902120711230.74431@wonkity.com>
References: <20090212.192851.57971498.haro@kgt.co.jp>
	<1346.1234436450@critter.freebsd.dk>
	<20090212125828.2ff46a75@ernst.jennejohn.org>
	<20090212133329.GA47985@mech-cluster238.men.bris.ac.uk>
	<20090212135415.GF8296@camelot.theinternet.com.au>
	<alpine.BSF.2.00.0902120711230.74431@wonkity.com>
Message-ID: <20090212142349.GA48301@mech-cluster238.men.bris.ac.uk>

On Thu, Feb 12, 2009 at 07:12:21AM -0700, Warren Block wrote:
> On Fri, 13 Feb 2009, Andrew Milton wrote:
> 
> > +-------[ Anton Shterenlikht ]----------------------
> > | On Thu, Feb 12, 2009 at 12:58:28PM +0100, Gary Jennejohn wrote:
> > | > On Thu, 12 Feb 2009 11:00:50 +0000
> > | > "Poul-Henning Kamp" <phk@phk.freebsd.dk> wrote:
> > | >
> > | > > In message <20090212.192851.57971498.haro@kgt.co.jp>, haro@kgt.co.jp writes:
> > | > >
> > | > > >
> > | > > >Section "ServerFlags"
> > | > > >        Option "AllowEmptyInput" "off"
> > | > > >EndSection
> > | > >
> > | > > That also works, and avoids four hald processes on the system, so
> > | > > I prefer this fix.
> > | > >
> > | >
> > | > I agree.  Especially since hald eats 100% of one of my cores (AMD64 X2)
> > | > apparently doing nothing.
> > | >
> > | > I remade the xorg server w/o hal and am now a much happier camper.
> > |
> > | but many other x parts depend on hal:
> > |
> > | # pkg_info -xR hal
> > | Information for hal-0.5.11_17:
> > |
> > | Required by:
> > | xf86-input-keyboard-1.3.2
> > | xf86-video-intel-2.5.1
> > | xf86-video-vesa-2.1.0
> > | xf86-input-mouse-1.4.0_3
> > |
> > | and these aren't optional, I think.

no, sorry, my fault. If I rebuild xorg-server without hal, and then all
above ports, they they no longer depend on hal:

# pkg_info -xR hal
Information for hal-0.5.11_17:

#

I'll give this a go.

-- 
Anton Shterenlikht
Room 2.6, Queen's Building
Mech Eng Dept
Bristol University
University Walk, Bristol BS8 1TR, UK
Tel: +44 (0)117 928 8233 
Fax: +44 (0)117 929 4423
From jhb at freebsd.org  Thu Feb 12 06:36:15 2009
From: jhb at freebsd.org (John Baldwin)
Date: Thu Feb 12 06:36:28 2009
Subject: modular kernconf
In-Reply-To: <49935993.50303@stillbilde.net>
References: <e5b1e8d40902111231y23611fc4w5db3fe3c40fbb15a@mail.gmail.com>
	<FF758FB0-DA6E-4AE4-A575-A4CDC4B65FD6@mac.com>
	<49935993.50303@stillbilde.net>
Message-ID: <200902120818.34567.jhb@freebsd.org>

On Wednesday 11 February 2009 6:04:51 pm Svein Skogen (listmail account) 
wrote:
> Chuck Swiger wrote:
> > On Feb 11, 2009, at 12:31 PM, Buganini wrote:
> > [ ... ]
> >> This way I can customize my kernconf cleanly and easily.
> >> Like today I want to try USB2, I just change the GENERIC to USB2, then
> >> I got what I want.
> >>
> >> I dont like to make a replica GENERIC then modify it,
> >> because sometimes options in the SCHED section changes,
> >> and in this case, if I want to try USB2, things become dirty.
> >>
> >> Or any better ideas?
> >
> > You should look into the way the include directive is used for the SMP
> > and PAE kernels (ie, /usr/src/sys/i386/conf/SMP).  You can make specific
> > changes to GENERIC to enable or disable things without having to roll an
> > entire kernel config file....
> >
> > Regards,
> 
> Can the kernel file (that contains the include directive) contain an
> opposite of the option and device, such as no_option or no_device?

Yes, just prefix a line with 'no', e.g. 'nodevice de'.

-- 
John Baldwin
From jhb at freebsd.org  Thu Feb 12 06:36:15 2009
From: jhb at freebsd.org (John Baldwin)
Date: Thu Feb 12 06:36:29 2009
Subject: modular kernconf
In-Reply-To: <49935993.50303@stillbilde.net>
References: <e5b1e8d40902111231y23611fc4w5db3fe3c40fbb15a@mail.gmail.com>
	<FF758FB0-DA6E-4AE4-A575-A4CDC4B65FD6@mac.com>
	<49935993.50303@stillbilde.net>
Message-ID: <200902120818.34567.jhb@freebsd.org>

On Wednesday 11 February 2009 6:04:51 pm Svein Skogen (listmail account) 
wrote:
> Chuck Swiger wrote:
> > On Feb 11, 2009, at 12:31 PM, Buganini wrote:
> > [ ... ]
> >> This way I can customize my kernconf cleanly and easily.
> >> Like today I want to try USB2, I just change the GENERIC to USB2, then
> >> I got what I want.
> >>
> >> I dont like to make a replica GENERIC then modify it,
> >> because sometimes options in the SCHED section changes,
> >> and in this case, if I want to try USB2, things become dirty.
> >>
> >> Or any better ideas?
> >
> > You should look into the way the include directive is used for the SMP
> > and PAE kernels (ie, /usr/src/sys/i386/conf/SMP).  You can make specific
> > changes to GENERIC to enable or disable things without having to roll an
> > entire kernel config file....
> >
> > Regards,
> 
> Can the kernel file (that contains the include directive) contain an
> opposite of the option and device, such as no_option or no_device?

Yes, just prefix a line with 'no', e.g. 'nodevice de'.

-- 
John Baldwin
From jhb at freebsd.org  Thu Feb 12 06:36:29 2009
From: jhb at freebsd.org (John Baldwin)
Date: Thu Feb 12 06:36:39 2009
Subject: atrtc0: Warnings about mappings of I/O and interrupt
In-Reply-To: <20081211221628.GA12494@freebsd.org>
References: <20081120171325.GA53026@freebsd.org>
	<200812041745.14587.jhb@freebsd.org>
	<20081211221628.GA12494@freebsd.org>
Message-ID: <200902120923.28105.jhb@freebsd.org>

On Thursday 11 December 2008 5:16:28 pm Roman Divacky wrote:
> On Thu, Dec 04, 2008 at 05:45:14PM -0500, John Baldwin wrote:
> > On Thursday 04 December 2008 05:04:38 pm Roman Divacky wrote:
> > > On Thu, Dec 04, 2008 at 02:24:13PM -0500, John Baldwin wrote:
> > > > On Thursday 20 November 2008 12:13:25 pm Roman Divacky wrote:
> > > > > hi
> > > > > 
> > > > > I upgraded from roughly 10 days old -CURRENT to this:
> > > > > 
> > > > > FreeBSD witten 8.0-CURRENT FreeBSD 8.0-CURRENT #55: Wed Nov 19 
23:23:49 
> > CET 
> > > > 2008
> > > > > root@witten:/usr/obj/usr/src/sys/MYKERNEL  i386
> > > > > 
> > > > > and I am getting this at boot:
> > > > > 
> > > > > atrtc0: <AT Real Time Clock> at port 0x70 irq 8 on isa0
> > > > > atrtc0: Warning: Couldn't map I/O.
> > > > > atrtc0: Warning: Couldn't map Interrupt.
> > > > > 
> > > > > the booting itself works fine and I dont see any odd effects.
> > > > 
> > > > The driver is just a stub anyway.  Do you have any atrtc0 hints, and 
can 
> > you 
> > > > grab the output for the 'atrtc0' device from 'devinfo -r'?
> > > 
> > > witten ~# grep atrtc /boot/device.hints
> > > hint.atrtc.0.at="isa"
> > > hint.atrtc.0.port="0x70"
> > > hint.atrtc.0.irq="8"
> > > 
> > > (but that's the default I believe)
> > > 
> > > devinfo -r shows "empty" atrtc0 but:
> > > 
> > >   atrtc1
> > >         Interrupt request lines:
> > >             8
> > >         I/O ports:
> > >             0x70-0x71
> > > 
> > > any more info I can provide?
> > 
> > Hmmmm, that should have worked fine in that atrtc1 should have taken over 
> > the 'atrtc0' hints.  If you don't mind, can you add some debugging printfs 
to 
> > acpi_hint_device_unit() (maybe only do them if the 'name' parameter 
> > is "atrtc" to avoid clutter).
> 
> with the attached patch I am getting the attached dmesg.
> 
> do you want me to do some other thing?

Can you get the dmesg output from this patch?

--- //depot/user/jhb/acpipci/dev/acpica/acpi.c
+++ /home/jhb/work/p4/acpipci/dev/acpica/acpi.c
@@ -974,6 +974,9 @@
     const char *s;
     long value;
     int line, matches, unit;
+    int debug;
+
+    debug = (strcmp(name, "atrtc") == 0);
 
     /*
      * Iterate over all the hints for the devices with the specified
@@ -984,11 +987,18 @@
 	if (resource_find_dev(&line, name, &unit, "at", NULL) != 0)
 	    break;
 
+	if (debug)
+		printf("Trying %s%d ...", name, unit);
+
 	/* Must have an "at" for acpi or isa. */
 	resource_string_value(name, unit, "at", &s);
 	if (!(strcmp(s, "acpi0") == 0 || strcmp(s, "acpi") == 0 ||
 	    strcmp(s, "isa0") == 0 || strcmp(s, "isa") == 0))
+	{
+	    if (debug)
+		printf(" bad bus %s\n", s);
 	    continue;
+	}
 
 	/*
 	 * Check for matching resources.  We must have at least one,
@@ -1000,9 +1010,17 @@
 	matches = 0;
 	if (resource_long_value(name, unit, "port", &value) == 0) {
 	    if (acpi_match_resource_hint(child, SYS_RES_IOPORT, value))
+	    {
 		matches++;
+		if (debug)
+		    printf(" port ok");
+	    }
 	    else
+	    {
+		if (debug)
+		    printf(" bad port\n");
 		continue;
+	    }
 	}
 	if (resource_long_value(name, unit, "maddr", &value) == 0) {
 	    if (acpi_match_resource_hint(child, SYS_RES_MEMORY, value))
@@ -1012,9 +1030,17 @@
 	}
 	if (resource_long_value(name, unit, "irq", &value) == 0) {
 	    if (acpi_match_resource_hint(child, SYS_RES_IRQ, value))
+	    {
+		if (debug)
+		    printf(" irq ok");
 		matches++;
+	    }
 	    else
+	    {
+		if (debug)
+		    printf(" bad irq\n");
 		continue;
+	    }
 	}
 	if (resource_long_value(name, unit, "drq", &value) == 0) {
 	    if (acpi_match_resource_hint(child, SYS_RES_DRQ, value))
@@ -1023,6 +1049,8 @@
 		continue;
 	}
 
+	if (debug)
+	    printf(" matches %d\n", matches);
 	if (matches > 0) {
 	    /* We have a winner! */
 	    *unitp = unit;

-- 
John Baldwin
From wblock at wonkity.com  Thu Feb 12 06:42:08 2009
From: wblock at wonkity.com (Warren Block)
Date: Thu Feb 12 06:42:16 2009
Subject: @188498: u3g works, Xorg does not
In-Reply-To: <20090212135415.GF8296@camelot.theinternet.com.au>
References: <20090212.192851.57971498.haro@kgt.co.jp>
	<1346.1234436450@critter.freebsd.dk>
	<20090212125828.2ff46a75@ernst.jennejohn.org>
	<20090212133329.GA47985@mech-cluster238.men.bris.ac.uk>
	<20090212135415.GF8296@camelot.theinternet.com.au>
Message-ID: <alpine.BSF.2.00.0902120711230.74431@wonkity.com>

On Fri, 13 Feb 2009, Andrew Milton wrote:

> +-------[ Anton Shterenlikht ]----------------------
> | On Thu, Feb 12, 2009 at 12:58:28PM +0100, Gary Jennejohn wrote:
> | > On Thu, 12 Feb 2009 11:00:50 +0000
> | > "Poul-Henning Kamp" <phk@phk.freebsd.dk> wrote:
> | >
> | > > In message <20090212.192851.57971498.haro@kgt.co.jp>, haro@kgt.co.jp writes:
> | > >
> | > > >
> | > > >Section "ServerFlags"
> | > > >        Option "AllowEmptyInput" "off"
> | > > >EndSection
> | > >
> | > > That also works, and avoids four hald processes on the system, so
> | > > I prefer this fix.
> | > >
> | >
> | > I agree.  Especially since hald eats 100% of one of my cores (AMD64 X2)
> | > apparently doing nothing.
> | >
> | > I remade the xorg server w/o hal and am now a much happier camper.
> |
> | but many other x parts depend on hal:
> |
> | # pkg_info -xR hal
> | Information for hal-0.5.11_17:
> |
> | Required by:
> | xf86-input-keyboard-1.3.2
> | xf86-video-intel-2.5.1
> | xf86-video-vesa-2.1.0
> | xf86-input-mouse-1.4.0_3
> |
> | and these aren't optional, I think.
>
> But if xdm or other display managers are started from /etc/tty, X starts
> before hal does leaving you with an unresponsive login screen.

That was fixed for me with xorg-server-1.5.3_5,1 from Sun Feb 8 07:23:46 
2009.  At least on -stable, haven't tried it yet on -current.

-Warren Block * Rapid City, South Dakota USA
From tinderbox at freebsd.org  Thu Feb 12 09:10:40 2009
From: tinderbox at freebsd.org (FreeBSD Tinderbox)
Date: Thu Feb 12 09:10:53 2009
Subject: [head tinderbox] failure on powerpc/powerpc
Message-ID: <20090212171035.9487E7302F@freebsd-current.sentex.ca>

TB --- 2009-02-12 15:42:41 - tinderbox 2.6 running on freebsd-current.sentex.ca
TB --- 2009-02-12 15:42:41 - starting HEAD tinderbox run for powerpc/powerpc
TB --- 2009-02-12 15:42:41 - cleaning the object tree
TB --- 2009-02-12 15:43:15 - cvsupping the source tree
TB --- 2009-02-12 15:43:15 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/power