From louisk at cryptomonkeys.org  Fri May  1 00:01:57 2009
From: louisk at cryptomonkeys.org (Louis Kowolowski)
Date: Fri May  1 00:02:04 2009
Subject: experiences with Supermicro Twin servers? (6016TT / 6026TT /
	6015TW)
In-Reply-To: <49FA2718.8050803@quip.cz>
References: <49F9A324.8090007@quip.cz>
	<31531C02-AC38-4535-8FFC-8518CDF2E9B4@cryptomonkeys.org>
	<49FA2718.8050803@quip.cz>
Message-ID: <C01AEBE0-10DA-4C42-BBDB-E652C3A8D38A@cryptomonkeys.org>

On Apr 30, 2009, at 3:32 PM, Miroslav Lachman wrote:

> Louis Kowolowski wrote:
>>
> ...
> Can you please post the model number of your servers?
>
The iX model number is IX12x2.  I believe it to be the 6015TW-TB/TV.

> ...
> 7.0 booted well from USB media on my Sun Fire X2100 M2 servers, but  
> I know there were (are) problems with booting FreeBSD on some  
> motherboards. I have problems with 7.0 on HP ML110 G5. 7.1 is  
> booting OK on this HP ML110 G5. Did you try booting some newer  
> versions on your servers?
>
Yes, 7.1 seems to boot just fine on them.  I haven't tried 7.2RC/BETA  
yet.

> ...
> Do you have any other issues with IPMI + KVM as posted by Andrew Snow?
>
I did, but I fixed it by fiddling around with the mouse/keyboard  
settings for the KVM.  Don't recall exactly what I did, but there  
aren't many options, so it shouldn't take long to figure them out. :-)

--
Louis Kowolowski                                louisk@cryptomonkeys.org
Cryptomonkeys:                      http://www.cryptomonkeys.org/~louisk

Making life more interesting for people since 1977

From mikes at siralan.org  Fri May  1 02:22:44 2009
From: mikes at siralan.org (Michael L. Squires)
Date: Fri May  1 02:22:51 2009
Subject: Change in ssh connection behavior with 7.2-PRERELEASE
Message-ID: <20090430213911.W1132@familysquires.net>


I'm using an older Supermicro 1U box as my NAT box for my home network; I 
also read email on it by logging in remotely using Cygwin's ssh to run 
pine.

I've noticed a change in behavior which ocurred when I upgraded from 7.1-STABLE compiled 2/8/2009 to 7.2-PRERELEASE compiled 4/24/2009.

The change is that the system can't display full screens in the Cygwin 
window.  The screen gets filled slowly, with long pauses between 
successive partial fills.

This seems to only occur when I'm logged in from work using Cygwin SSH 
over the Internet to my home box; the final link is via Comcast, if that 
makes a difference.

Connecting from witnin my local network, also using Cygwin SSH, no such problem.

Rebooting the old kernel solves the problem.

The work PC is running Cygwin OpenSSH 5.1p1/OpenSSL 0.9.8j (7 Jan 2009); 
the home PC is running Cygwin OpenSSH 5.1p1/OpenSSL 0.9.8i (9/15/2008).

The results of "stty -a" under new and old kernels yeilds exactly the same 
thing:

speed 38400 baud; 90 rows; 80 columns;
lflags: icanon isig iexten echo echoe -echok echoke -echonl echoctl
         -echoprt -altwerase -noflsh -tostop -flusho pendin -nokerninfo
         -extproc
iflags: -istrip icrnl -inlcr -igncr ixon ixoff -ixany -imaxbel -ignbrk
         brkint -inpck -ignpar -parmrk
oflags: opost onlcr -ocrnl -oxtabs -onocr -onlret
cflags: cread cs8 -parenb -parodd hupcl -clocal -cstopb -crtscts -dsrflow
         -dtrflow -mdmbuf
cchars: discard = ^O; dsusp = ^Y; eof = ^D; eol = <undef>;
         eol2 = <undef>; erase = ^H; erase2 = ^H; intr = ^C; kill = ^U;
         lnext = ^V; min = 1; quit = ^\; reprint = ^R; start = ^Q;
         status = ^T; stop = ^S; susp = ^Z; time = 0; werase = ^W;

Mike Squires
mikes@siralan.org
From lehmann at ans-netz.de  Fri May  1 05:52:09 2009
From: lehmann at ans-netz.de (Oliver Lehmann)
Date: Fri May  1 05:52:16 2009
Subject: dri + ATI: dramatic performance slowdown
In-Reply-To: <20090427071837.b18d19f2.lehmann@ans-netz.de>
References: <20090420152620.8f89edd5.lehmann@ans-netz.de>
	<200904221739.25097.npapke@acm.org>
	<1240448113.2142.11.camel@balrog.2hip.net>
	<200904221938.12129.npapke@acm.org>
	<1240463479.2142.21.camel@balrog.2hip.net>
	<20090424151102.970570fa.lehmann@ans-netz.de>
	<1240593706.2142.38.camel@balrog.2hip.net>
	<20090424195205.73a2cf44.lehmann@ans-netz.de>
	<1240596378.2142.45.camel@balrog.2hip.net>
	<20090425092310.a0471901.lehmann@ans-netz.de>
	<20090425101909.bad0e8b3.lehmann@ans-netz.de>
	<1240672173.1946.5.camel@balrog.2hip.net>
	<20090426102126.843c35f3.lehmann@ans-netz.de>
	<1240766181.4395.0.camel@wombat.2hip.net>
	<20090427071837.b18d19f2.lehmann@ans-netz.de>
Message-ID: <20090501075205.a8cb38e1.lehmann@ans-netz.de>

Hi Robert

Oliver Lehmann wrote:

> Robert Noland wrote:
> 
> > It still might be useful... Option "BusType" "PCI"

any new here?

-- 
 Oliver Lehmann
  http://www.pofo.de/
  http://wishlist.ans-netz.de/
From ghostcorps at gmail.com  Fri May  1 08:37:26 2009
From: ghostcorps at gmail.com (ghostcorps)
Date: Fri May  1 08:37:34 2009
Subject: Can i add a new HDD to an encrypted array?
Message-ID: <4c06024b0905010112m42cbd2a5m9474aa86c003fb0@mail.gmail.com>

Hi Guys,

 This seems liek a really basic question, I expect a simple 'no', but I
havn't found anything definative yet.

 I currently have a hardware RAID5 array, using the Intel Matrix RAID
capability onboard, encrypted with GELI.

I need to add 2 new discs to the array. If I add a disc to the array and
have it rebuilt with the Intel Matrix Storage Manager, prior to booting
FreeBSD will that destroy the encrypted data?

 If so, how can I decrypt the disk without copying the data to another
partition?



Please let me know if you need any other info.

Thanks




Using:
OS: FreeBSD 7.0
Mobo: Asus p5b-e
http://www.asus.com.au/products.aspx?l1=3&l2=11&l3=307&l4=0&model=1347&modelmenu=1
HDDs: Seagate 500g SATA2
From rsmith at xs4all.nl  Fri May  1 10:03:12 2009
From: rsmith at xs4all.nl (Roland Smith)
Date: Fri May  1 10:03:20 2009
Subject: Can i add a new HDD to an encrypted array?
In-Reply-To: <4c06024b0905010112m42cbd2a5m9474aa86c003fb0@mail.gmail.com>
References: <4c06024b0905010112m42cbd2a5m9474aa86c003fb0@mail.gmail.com>
Message-ID: <20090501095305.GA91771@slackbox.xs4all.nl>

On Fri, May 01, 2009 at 06:12:42PM +1000, ghostcorps wrote:
> Hi Guys,
> 
>  This seems liek a really basic question, I expect a simple 'no', but I
> havn't found anything definative yet.
> 
>  I currently have a hardware RAID5 array, using the Intel Matrix RAID
> capability onboard, encrypted with GELI.

According to ataraid(4), Intel MatrixRAID is software RAID, not real
hardware RAID.
 
> I need to add 2 new discs to the array. If I add a disc to the array and
> have it rebuilt with the Intel Matrix Storage Manager, prior to booting
> FreeBSD will that destroy the encrypted data?

In short, no.

The long answer is that the raid array functions at a level below GELI
which in turn is below the filesystem layer. GELI writes its metadata in
the last sector of the device, and the ffs(7) filesystem records the
size of the underlying device at creation time.

Adding the two disks will make the array larger. The metadata for geli
will probably not be on the last sector anymore, so geli will not
recognize the enlarged device. 

So you'll have to save your data elsewhere, put in the extra disks,
recreate the array, re-initialize and attach the geli device for the new
array and newfs(8) the new geli device.

>  If so, how can I decrypt the disk without copying the data to another
> partition?

There are no tools for that at this time, although it should be feasable
by reading a (multiple of) block(s) from the geli device and then
writing it to the non-encrypted device. Note that whenever you write a
block to the unencrypted device, the contents of that block on the geli
device become gibberish! So you'll have to do the whole device, unless
you can beforehand make a list of all the blocks that are in use by the
filesystem. And if even a single block failed in transit, you're
potentially screwed.

And even if you could perform this in-place decryption, you should make
a full backup anyway in case the procedure goes horribly wrong, which is
always a possibility. :-)

If you want to decrypt the device in place because you don't have enough
backup capacity to store the contents of you raid array, you're aleady
in trouble even if you don't know it yet. What will you do if your RAID5
fails? 

Roland
-- 
R.F.Smith                                   http://www.xs4all.nl/~rsmith/
[plain text _non-HTML_ PGP/GnuPG encrypted/signed email much appreciated]
pgp: 1A2B 477F 9970 BA3C 2914  B7CE 1277 EFB0 C321 A725 (KeyID: C321A725)
-------------- 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-stable/attachments/20090501/5ab17fc8/attachment.pgp
From bms at incunabulum.net  Fri May  1 10:57:51 2009
From: bms at incunabulum.net (Bruce Simpson)
Date: Fri May  1 10:57:59 2009
Subject: Help ! Regarding libpcap issue.
In-Reply-To: <49F93D3A.2020704@gmail.com>
References: <20090429120028.D6412106568F@hub.freebsd.org>
	<49F93D3A.2020704@gmail.com>
Message-ID: <49FAD5AD.8030805@incunabulum.net>

Hi,

I recently updated the port, but didn't see this condition in testing.
Are you able to build libpcap *without* using the port from the same 
tarball?
do-patch in the port doesn't touch those files.

Leo wrote:
> Hi All,
> I want to install libpcap from ports. But when I "make install clean", 
> the box output:
>
> .......
> config.status: creating pcap_open_dead.3pcap
> config.status: creating pcap_open_offline.3pcap
> config.status: creating config.h
> ===>  Building for libpcap-1.0.0
> cc -O2 -O2 -fno-strict-aliasing -pipe -I.  -DHAVE_CONFIG_H  
> -D_U_="__attribute__((unused))" -c ./pcap-null.c
> ./pcap-null.c:44: error: conflicting types for 'pcap_activate'
> ./pcap/pcap.h:266: error: previous declaration of 'pcap_activate' was 
> here
> gmake: *** [pcap-null.o] Error 1
> *** Error code 1

thanks,
BMS
From ghostcorps at gmail.com  Fri May  1 11:02:47 2009
From: ghostcorps at gmail.com (ghostcorps)
Date: Fri May  1 11:02:54 2009
Subject: Can i add a new HDD to an encrypted array?
In-Reply-To: <20090501095305.GA91771@slackbox.xs4all.nl>
References: <4c06024b0905010112m42cbd2a5m9474aa86c003fb0@mail.gmail.com>
	<20090501095305.GA91771@slackbox.xs4all.nl>
Message-ID: <4c06024b0905010402r77141b0dwd783f56b55f7afb5@mail.gmail.com>

Thanks Roland,

 You have confirmed my worst fears. One thing though, apparently MatrixRAID
is a 'Firmware RAID' system as opposed to hard or software. I don't quite
know how that would effect anything but that's all I can say really. It
looks like I'm buying some more disks.

http://en.wikipedia.org/wiki/Intel_Matrix_RAID

Regards



On Fri, May 1, 2009 at 7:53 PM, Roland Smith <rsmith@xs4all.nl> wrote:

> On Fri, May 01, 2009 at 06:12:42PM +1000, ghostcorps wrote:
> > Hi Guys,
> >
> >  This seems liek a really basic question, I expect a simple 'no', but I
> > havn't found anything definative yet.
> >
> >  I currently have a hardware RAID5 array, using the Intel Matrix RAID
> > capability onboard, encrypted with GELI.
>
> According to ataraid(4), Intel MatrixRAID is software RAID, not real
> hardware RAID.
>
> > I need to add 2 new discs to the array. If I add a disc to the array and
> > have it rebuilt with the Intel Matrix Storage Manager, prior to booting
> > FreeBSD will that destroy the encrypted data?
>
> In short, no.
>
> The long answer is that the raid array functions at a level below GELI
> which in turn is below the filesystem layer. GELI writes its metadata in
> the last sector of the device, and the ffs(7) filesystem records the
> size of the underlying device at creation time.
>
> Adding the two disks will make the array larger. The metadata for geli
> will probably not be on the last sector anymore, so geli will not
> recognize the enlarged device.
>
> So you'll have to save your data elsewhere, put in the extra disks,
> recreate the array, re-initialize and attach the geli device for the new
> array and newfs(8) the new geli device.
>
> >  If so, how can I decrypt the disk without copying the data to another
> > partition?
>
> There are no tools for that at this time, although it should be feasable
> by reading a (multiple of) block(s) from the geli device and then
> writing it to the non-encrypted device. Note that whenever you write a
> block to the unencrypted device, the contents of that block on the geli
> device become gibberish! So you'll have to do the whole device, unless
> you can beforehand make a list of all the blocks that are in use by the
> filesystem. And if even a single block failed in transit, you're
> potentially screwed.
>
> And even if you could perform this in-place decryption, you should make
> a full backup anyway in case the procedure goes horribly wrong, which is
> always a possibility. :-)
>
> If you want to decrypt the device in place because you don't have enough
> backup capacity to store the contents of you raid array, you're aleady
> in trouble even if you don't know it yet. What will you do if your RAID5
> fails?
>
> Roland
> --
> R.F.Smith                                   http://www.xs4all.nl/~rsmith/<http://www.xs4all.nl/%7Ersmith/>
> [plain text _non-HTML_ PGP/GnuPG encrypted/signed email much appreciated]
> pgp: 1A2B 477F 9970 BA3C 2914  B7CE 1277 EFB0 C321 A725 (KeyID: C321A725)
>
From ertr1013 at student.uu.se  Fri May  1 11:34:22 2009
From: ertr1013 at student.uu.se (Erik Trulsson)
Date: Fri May  1 11:34:31 2009
Subject: Can i add a new HDD to an encrypted array?
In-Reply-To: <4c06024b0905010402r77141b0dwd783f56b55f7afb5@mail.gmail.com>
References: <4c06024b0905010112m42cbd2a5m9474aa86c003fb0@mail.gmail.com>
	<20090501095305.GA91771@slackbox.xs4all.nl>
	<4c06024b0905010402r77141b0dwd783f56b55f7afb5@mail.gmail.com>
Message-ID: <20090501113201.GA70308@owl.midgard.homeip.net>

On Fri, May 01, 2009 at 09:02:46PM +1000, ghostcorps wrote:
> Thanks Roland,
> 
>  You have confirmed my worst fears. One thing though, apparently MatrixRAID
> is a 'Firmware RAID' system as opposed to hard or software.

That just means that the BIOS understands that RAID layout and knows how to
boot from a RAID array.  Otherwise it is just like any other software RAID.

(It is a fairly safe assumption that any 'RAID-controller' that is
built-in on a motherboard is actually software RAID.)





> I don't quite
> know how that would effect anything but that's all I can say really. It
> looks like I'm buying some more disks.
> 
> http://en.wikipedia.org/wiki/Intel_Matrix_RAID
> 
> Regards
> 
> 
> 
> On Fri, May 1, 2009 at 7:53 PM, Roland Smith <rsmith@xs4all.nl> wrote:
> 
> > On Fri, May 01, 2009 at 06:12:42PM +1000, ghostcorps wrote:
> > > Hi Guys,
> > >
> > >  This seems liek a really basic question, I expect a simple 'no', but I
> > > havn't found anything definative yet.
> > >
> > >  I currently have a hardware RAID5 array, using the Intel Matrix RAID
> > > capability onboard, encrypted with GELI.
> >
> > According to ataraid(4), Intel MatrixRAID is software RAID, not real
> > hardware RAID.
> >
> > > I need to add 2 new discs to the array. If I add a disc to the array and
> > > have it rebuilt with the Intel Matrix Storage Manager, prior to booting
> > > FreeBSD will that destroy the encrypted data?
> >
> > In short, no.
> >
> > The long answer is that the raid array functions at a level below GELI
> > which in turn is below the filesystem layer. GELI writes its metadata in
> > the last sector of the device, and the ffs(7) filesystem records the
> > size of the underlying device at creation time.
> >
> > Adding the two disks will make the array larger. The metadata for geli
> > will probably not be on the last sector anymore, so geli will not
> > recognize the enlarged device.
> >
> > So you'll have to save your data elsewhere, put in the extra disks,
> > recreate the array, re-initialize and attach the geli device for the new
> > array and newfs(8) the new geli device.
> >
> > >  If so, how can I decrypt the disk without copying the data to another
> > > partition?
> >
> > There are no tools for that at this time, although it should be feasable
> > by reading a (multiple of) block(s) from the geli device and then
> > writing it to the non-encrypted device. Note that whenever you write a
> > block to the unencrypted device, the contents of that block on the geli
> > device become gibberish! So you'll have to do the whole device, unless
> > you can beforehand make a list of all the blocks that are in use by the
> > filesystem. And if even a single block failed in transit, you're
> > potentially screwed.
> >
> > And even if you could perform this in-place decryption, you should make
> > a full backup anyway in case the procedure goes horribly wrong, which is
> > always a possibility. :-)
> >
> > If you want to decrypt the device in place because you don't have enough
> > backup capacity to store the contents of you raid array, you're aleady
> > in trouble even if you don't know it yet. What will you do if your RAID5
> > fails?
> >
> > Roland
> > --
> > R.F.Smith                                   http://www.xs4all.nl/~rsmith/<http://www.xs4all.nl/%7Ersmith/>
> > [plain text _non-HTML_ PGP/GnuPG encrypted/signed email much appreciated]
> > pgp: 1A2B 477F 9970 BA3C 2914  B7CE 1277 EFB0 C321 A725 (KeyID: C321A725)
> >
> _______________________________________________
> freebsd-stable@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org"

-- 
<Insert your favourite quote here.>
Erik Trulsson
ertr1013@student.uu.se
From rsmith at xs4all.nl  Fri May  1 12:15:50 2009
From: rsmith at xs4all.nl (Roland Smith)
Date: Fri May  1 12:15:58 2009
Subject: Can i add a new HDD to an encrypted array?
In-Reply-To: <4c06024b0905010402r77141b0dwd783f56b55f7afb5@mail.gmail.com>
References: <4c06024b0905010112m42cbd2a5m9474aa86c003fb0@mail.gmail.com>
	<20090501095305.GA91771@slackbox.xs4all.nl>
	<4c06024b0905010402r77141b0dwd783f56b55f7afb5@mail.gmail.com>
Message-ID: <20090501121546.GA95759@slackbox.xs4all.nl>

On Fri, May 01, 2009 at 09:02:46PM +1000, ghostcorps wrote:
>  Thanks Roland,
> 
>   You have confirmed my worst fears. 

Well, there is one thing that _might_ work. It might also destroy your
data, hence the first step:

- Make a backup and verify it.
- Remove the array from fstab, so it isn't mounted automatically.
- Add the disks to the array.
- Re-initialize and attach the new array as a geli(8) device, using the
  same password and/or key file and algorithm.
- Try to grow the filesystem with growfs(8).
- If that works, mount the array and restore it to fstab.

Whether this works or not will depend on how the new disks are added to
the array. If they are added as a continious space at the rear it will
probably be fine. If the extra space shows up as patches in between or
at the front it will not work because your filesystem will be hosed. :-)

I'm also _assuming_ that if you initialize two geli devices with the
same parameters, the on-disk data will be the same. This might not be
true, in which case you've lost all your data.

Alternatively, you can use dd(1) to make a copy of the geli data from
the last sector of the old array, and write it to the last sector of the
new array. Again, this might blow up in your face if some of the
metadata isn't correct for the new array.

So don't try this without a solid backup, for obvious reasons.

If this works, you can write it up and submit it as a new section for the
Handbook, gaining eternal glory. ;-)

Roland
-- 
R.F.Smith                                   http://www.xs4all.nl/~rsmith/
[plain text _non-HTML_ PGP/GnuPG encrypted/signed email much appreciated]
pgp: 1A2B 477F 9970 BA3C 2914  B7CE 1277 EFB0 C321 A725 (KeyID: C321A725)
-------------- 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-stable/attachments/20090501/f328d6b8/attachment.pgp
From bms at incunabulum.net  Fri May  1 13:07:05 2009
From: bms at incunabulum.net (Bruce Simpson)
Date: Fri May  1 13:07:12 2009
Subject: kernel compile fails without AH_SUPPORT_AR5416
In-Reply-To: <49EDDD51.9040608@freebsd.org>
References: <49E6DB25.2010601@sippysoft.com>	<b84edfa10904160238u7a94e4aw4f60372a6b99f2a2@mail.gmail.com>	<49E6FF8F.4070403@sippysoft.com>	<b84edfa10904160505s45bcee01n3e516a00d1e4dffe@mail.gmail.com>
	<49ED6AD2.4010006@incunabulum.net> <49EDDD51.9040608@freebsd.org>
Message-ID: <49FAF3F5.5070609@incunabulum.net>

Hi,

Can you please try this patch?
I can't commit it until STABLE is unfrozen after 7.2-RELEASE is cut.

Sam Leffler wrote:
> Bruce Simpson wrote:
>   
>> Hi,
>>
>> Looks like I'm late to the party. I was responsible for committing these
>> ath(4) changes to RELENG_7.
>> I can't remember if I tested the kernel compile without the
>> AH_SUPPORT_AR5416 option or not, I have been so incredibly busy.
>> ...
> ru had a change to fix this but decided not to; can't say why.
> Otherwise there is a better way to fix this which I alluded to in
> previous mail--use the config-generated #define that is generated for
> the "ath_hal" device.


thanks,
BMS
-------------- next part --------------
Index: UPDATING
===================================================================
--- UPDATING	(revision 191718)
+++ UPDATING	(working copy)
@@ -8,6 +8,11 @@
 /usr/ports/UPDATING.  Please read that file before running
 portupgrade.
 
+20090505:
+	The kernel compile-time option AH_SUPPORT_AR5416 has been
+	removed; it is now enabled by default as if_ath.c depends on it
+	in order to build.
+
 20090504:
 	FreeBSD 7.2-RELEASE
 
Index: sys/arm/conf/AVILA
===================================================================
--- sys/arm/conf/AVILA	(revision 191718)
+++ sys/arm/conf/AVILA	(working copy)
@@ -133,7 +133,6 @@
 #device		wlan_tkip	# 802.11 TKIP support
 device		ath		# Atheros pci/cardbus NIC's
 device		ath_hal		# Atheros HAL (Hardware Access Layer)
-options		AH_SUPPORT_AR5416	# enable AR5416 tx/rx descriptors
 device		ath_rate_sample	# SampleRate tx rate control for ath
 options		ATH_DEBUG
 
Index: sys/sparc64/conf/GENERIC
===================================================================
--- sys/sparc64/conf/GENERIC	(revision 191718)
+++ sys/sparc64/conf/GENERIC	(working copy)
@@ -191,7 +191,6 @@
 device		wlan_scan_sta	# 802.11 STA mode scanning
 device		ath		# Atheros pci/cardbus NIC's
 device		ath_hal		# Atheros HAL (Hardware Access Layer)
-options		AH_SUPPORT_AR5416	# enable AR5416 tx/rx descriptors
 device		ath_rate_sample	# SampleRate tx rate control for ath
 
 # Pseudo devices.
Index: sys/conf/options
===================================================================
--- sys/conf/options	(revision 191718)
+++ sys/conf/options	(working copy)
@@ -731,8 +731,6 @@
 ATH_TX99_DIAG		opt_ath.h
 
 # options for the Atheros hal
-AH_SUPPORT_AR5416	opt_ah.h
-
 AH_DEBUG		opt_ah.h
 AH_ASSERT		opt_ah.h
 AH_DEBUG_ALQ		opt_ah.h
Index: sys/modules/ath/Makefile
===================================================================
--- sys/modules/ath/Makefile	(revision 191718)
+++ sys/modules/ath/Makefile	(working copy)
@@ -76,8 +76,9 @@
 #
 # AR5416, AR9160 support; these are 11n parts but only really
 # supported (right now) operating in legacy mode.  Note enabling
-# this support requires defining AH_SUPPORT_AR5416 in opt_ah.h
+# this support requires defining AH_SUPPORT_AR5416
 # so the 11n tx/rx descriptor format is handled.
+# This support is now enabled by default.
 #
 # NB: 9160 depends on 5416 but 5416 does not require 9160
 #
@@ -106,7 +107,4 @@
 
 CFLAGS+=  -I. -I${.CURDIR}/../../dev/ath -I${.CURDIR}/../../dev/ath/ath_hal
 
-opt_ah.h:
-	echo '#define AH_SUPPORT_AR5416 1' > $@
-
 .include <bsd.kmod.mk>
Index: sys/dev/ath/ath_hal/ah_desc.h
===================================================================
--- sys/dev/ath/ath_hal/ah_desc.h	(revision 191718)
+++ sys/dev/ath/ath_hal/ah_desc.h	(working copy)
@@ -20,8 +20,12 @@
 #ifndef _DEV_ATH_DESC_H
 #define _DEV_ATH_DESC_H
 
-#include "opt_ah.h"		/* NB: required for AH_SUPPORT_AR5416 */
+#include "opt_ah.h"
 
+#ifndef AH_SUPPORT_AR5416
+#define AH_SUPPORT_AR5416	/* always support AR5416 */
+#endif
+
 /*
  * Transmit descriptor status.  This structure is filled
  * in only after the tx descriptor process method finds a
Index: sys/dev/ath/if_ath.c
===================================================================
--- sys/dev/ath/if_ath.c	(revision 191718)
+++ sys/dev/ath/if_ath.c	(working copy)
@@ -3399,7 +3399,7 @@
 	rix = rs->rs_rate;
 	sc->sc_rx_th.wr_rate = sc->sc_hwmap[rix].ieeerate;
 	sc->sc_rx_th.wr_flags = sc->sc_hwmap[rix].rxflags;
-#if HAL_ABI_VERSION >= 0x07050400
+#if HAL_ABI_VERSION >= 0x07050400 && defined(AH_SUPPORT_AR5416)
 	if (sc->sc_curchan.channelFlags & CHANNEL_HT) {
 		/*
 		 * For HT operation we must specify the channel
Index: sys/i386/conf/GENERIC
===================================================================
--- sys/i386/conf/GENERIC	(revision 191718)
+++ sys/i386/conf/GENERIC	(working copy)
@@ -255,7 +255,6 @@
 device		an		# Aironet 4500/4800 802.11 wireless NICs.
 device		ath		# Atheros pci/cardbus NIC's
 device		ath_hal		# Atheros HAL (Hardware Access Layer)
-options		AH_SUPPORT_AR5416	# enable AR5416 tx/rx descriptors
 device		ath_rate_sample	# SampleRate tx rate control for ath
 device		awi		# BayStack 660 and others
 device		ral		# Ralink Technology RT2500 wireless NICs.
Index: sys/amd64/conf/GENERIC
===================================================================
--- sys/amd64/conf/GENERIC	(revision 191718)
+++ sys/amd64/conf/GENERIC	(working copy)
@@ -242,7 +242,6 @@
 device		an		# Aironet 4500/4800 802.11 wireless NICs.
 device		ath		# Atheros pci/cardbus NIC's
 device		ath_hal		# Atheros HAL (Hardware Access Layer)
-options		AH_SUPPORT_AR5416	# enable AR5416 tx/rx descriptors
 device		ath_rate_sample	# SampleRate tx rate control for ath
 device		awi		# BayStack 660 and others
 device		ral		# Ralink Technology RT2500 wireless NICs.
From petefrench at ticketswitch.com  Fri May  1 13:20:11 2009
From: petefrench at ticketswitch.com (Pete French)
Date: Fri May  1 13:20:18 2009
Subject: kern/133756: [bce] bce commit r190582 breaks lagg in
	7.2-PRERELASE
Message-ID: <E1Lzsev-000Ofm-92@dilbert.ticketswitch.com>

This is just a quick update about some further investigations on
this. I tested out the patch that Niki Denev kindly sent me which
apparently fixes a length issue when zero copy sockets are not
in use. This did not, however, solve the problem, but as part of
this I ran tcpdump on the bce0 and bce1 interfaces for the
working and non working kernels. On the kernel which does not
work I never see any packets being received, though LACP packets
are being transmitted.

The switch to which the devices are connected is (I believe) configured
in a mode where it will only send LACP packets back when it has received
some. So the lack of incomming pa ckets in tcpdump does not necessarily
mean that the recive side is failing, as it may be that the transmitted
packets are not making it out of the interface. On identical hardware
with no LACP in place the bce interfaces work fine. What I have yet
to try is runnign a simple lagg bundle on this machine, to see if the
problem is specific to LACP.

I also rolled the system back to 7.1 and tested a patch from Doug Ambrisko
which adds the support for the 5709 but contains none of the other
changes. This did work, so that has excluded those changes from the cause
of the problems.

-pete.
From sam at freebsd.org  Fri May  1 15:50:24 2009
From: sam at freebsd.org (Sam Leffler)
Date: Fri May  1 15:50:31 2009
Subject: kernel compile fails without AH_SUPPORT_AR5416
In-Reply-To: <49FAF3F5.5070609@incunabulum.net>
References: <49E6DB25.2010601@sippysoft.com>	<b84edfa10904160238u7a94e4aw4f60372a6b99f2a2@mail.gmail.com>	<49E6FF8F.4070403@sippysoft.com>	<b84edfa10904160505s45bcee01n3e516a00d1e4dffe@mail.gmail.com>
	<49ED6AD2.4010006@incunabulum.net> <49EDDD51.9040608@freebsd.org>
	<49FAF3F5.5070609@incunabulum.net>
Message-ID: <49FB1A3F.3000809@freebsd.org>

Bruce Simpson wrote:
> Hi,
>
> Can you please try this patch?
> I can't commit it until STABLE is unfrozen after 7.2-RELEASE is cut.
>
> Sam Leffler wrote:
>> Bruce Simpson wrote:
>>  
>>> Hi,
>>>
>>> Looks like I'm late to the party. I was responsible for committing 
>>> these
>>> ath(4) changes to RELENG_7.
>>> I can't remember if I tested the kernel compile without the
>>> AH_SUPPORT_AR5416 option or not, I have been so incredibly busy.
>>> ...
>> ru had a change to fix this but decided not to; can't say why.
>> Otherwise there is a better way to fix this which I alluded to in
>> previous mail--use the config-generated #define that is generated for
>> the "ath_hal" device.
Do not modify ah_desc.h like you've done.  Add this to conf/options

ATH_HAL   opt_ah.h

and use that to enable AH_SUPPORT_AR5416.

Also changes must go in head first.

    Sam

From jhb at freebsd.org  Fri May  1 15:53:57 2009
From: jhb at freebsd.org (John Baldwin)
Date: Fri May  1 15:54:14 2009
Subject: Garbled output from kgdb?
In-Reply-To: <49F8B859.7060908@umn.edu>
References: <49F8B859.7060908@umn.edu>
Message-ID: <200905010947.54855.jhb@freebsd.org>

On Wednesday 29 April 2009 4:28:09 pm Alan Amesbury wrote:
> One of my systems (FreeBSD 7.1-RELEASE-p3/amd64) has panicked a couple
> times recently without an identified cause.  This most recent time I was
> able to obtain a crash dump from the system, but output from kgdb is
> garbled.
> 
> -------------------- Output #1 --------------------
> % pwd
> /usr/obj/usr/src/sys/[REDACTED]
> % sudo kgdb kernel.debug ~/crash/vmcore.0
> GNU gdb 6.1.1 [FreeBSD]
> Copyright 2004 Free Software Foundation, Inc.
> GDB is free software, covered by the GNU General Public License, and you are
> welcome to change it and/or distribute copies of it under certain
> conditions.
> Type "show copying" to see the conditions.
> There is absolutely no warranty for GDB.  Type "show warranty" for details.
> This GDB was configured as "amd64-marcel-freebsd"...
> 
> Unread portion of the kernel message buffer:
> kernel trap 12 with interrupts disabled
> 
> 
> Fatal trap 12: page fault while in kernel mode
> cpuid = 3; apic id = 07
> fault virtual addresske rn= el0 xt60r
> afapul t 1co2de                 w= isutpehrv isiorn twerritreu pdtasta
> d,i spaagbe lnoet dpres
> ent
> instruction pointer     = 0x8:0xffffffff80424561
> s
> tack
>  pFoianttera     l        = 0x10t:0xfffrffaffpfac057af0
> frame pointer           = 0x10:0xffffff00010f86e0
> code segment            = base 0x0, limit 0xfffff, type 0x1b
>                         = DPL 0, pres 1, long 1, def32 0, gran 1
> processor eflags        = resume, IOPL = 0
> current process         = 11 (idle: cpu3)
> trap number             = 12
> panic: page fault
> cpuid = 3
> Uptime: 40d10h35m18s
> Physical memory: 8176 MB
> Dumping 691 MB: 676 660 644 628 612 596 580 564 548 532 516 500 484 468
> 452 436 420 404 388 372 356 340 324 308 292 276 260 244 228 212 196 180
> 164 148 132 116 100 84 68 52 36 20 4
> 
> Reading symbols from /boot/kernel/daemon_saver.ko...Reading symbols from
> /boot/kernel/daemon_saver.ko.symbols...done.
> done.
> Loaded symbols for /boot/kernel/daemon_saver.ko
> #0  doadump () at pcpu.h:195
> 195             __asm __volatile("movq %%gs:0,%0" : "=r" (td));
> (kgdb) list *0x8:0xffffffff80424561
> A syntax error in expression, near `:0xffffffff80424561'.

Drop the '0x8:' from this and it will work better.  Also, 'bt' output would be 
good.

-- 
John Baldwin
From jhb at freebsd.org  Fri May  1 15:53:58 2009
From: jhb at freebsd.org (John Baldwin)
Date: Fri May  1 15:54:15 2009
Subject: lock up in 6.2 (procs massively stuck in Giant)
In-Reply-To: <a31046fc0904292336w17aca317hefd32dad5bc28007@mail.gmail.com>
References: <a31046fc0904292336w17aca317hefd32dad5bc28007@mail.gmail.com>
Message-ID: <200905010949.45927.jhb@freebsd.org>

On Thursday 30 April 2009 2:36:34 am pluknet wrote:
> Hi folks.
> 
> Today I got a new locking issue.
> This is the first time I got it, and it's merely reproduced.
> 
> The box has lost both remote connection and local access.
> No SIGINFO output on the local console even.
> Jumping in ddb> shows the next:
> 
> 1) first, this is a 8-way web server. No processes on runqueue except one 
httpd
> (i.e. ps shows R in its state):

You need to find who owns Giant and what that thread is doing.  You can try 
using 'show lock Giant' as well as 'show lockchain 11568'.

-- 
John Baldwin
From sam at freebsd.org  Fri May  1 15:57:26 2009
From: sam at freebsd.org (Sam Leffler)
Date: Fri May  1 15:57:38 2009
Subject: kernel compile fails without AH_SUPPORT_AR5416
In-Reply-To: <49FB1A3F.3000809@freebsd.org>
References: <49E6DB25.2010601@sippysoft.com>	<b84edfa10904160238u7a94e4aw4f60372a6b99f2a2@mail.gmail.com>	<49E6FF8F.4070403@sippysoft.com>	<b84edfa10904160505s45bcee01n3e516a00d1e4dffe@mail.gmail.com>	<49ED6AD2.4010006@incunabulum.net>
	<49EDDD51.9040608@freebsd.org>	<49FAF3F5.5070609@incunabulum.net>
	<49FB1A3F.3000809@freebsd.org>
Message-ID: <49FB1BE4.20502@freebsd.org>

Sam Leffler wrote:
> Bruce Simpson wrote:
>> Hi,
>>
>> Can you please try this patch?
>> I can't commit it until STABLE is unfrozen after 7.2-RELEASE is cut.
>>
>> Sam Leffler wrote:
>>> Bruce Simpson wrote:
>>>  
>>>> Hi,
>>>>
>>>> Looks like I'm late to the party. I was responsible for committing 
>>>> these
>>>> ath(4) changes to RELENG_7.
>>>> I can't remember if I tested the kernel compile without the
>>>> AH_SUPPORT_AR5416 option or not, I have been so incredibly busy.
>>>> ...
>>> ru had a change to fix this but decided not to; can't say why.
>>> Otherwise there is a better way to fix this which I alluded to in
>>> previous mail--use the config-generated #define that is generated for
>>> the "ath_hal" device.
> Do not modify ah_desc.h like you've done.  Add this to conf/options
>
> ATH_HAL   opt_ah.h
>
> and use that to enable AH_SUPPORT_AR5416.
>
> Also changes must go in head first.

To clarify the first comment: you've made it impossible to build code 
w/o the extended format descriptor; this is what I find unacceptable.

    Sam

From rnoland at FreeBSD.org  Fri May  1 16:07:19 2009
From: rnoland at FreeBSD.org (Robert Noland)
Date: Fri May  1 16:07:26 2009
Subject: dri + ATI: dramatic performance slowdown
In-Reply-To: <20090501075205.a8cb38e1.lehmann@ans-netz.de>
References: <20090420152620.8f89edd5.lehmann@ans-netz.de>
	<200904221739.25097.npapke@acm.org>
	<1240448113.2142.11.camel@balrog.2hip.net>
	<200904221938.12129.npapke@acm.org>
	<1240463479.2142.21.camel@balrog.2hip.net>
	<20090424151102.970570fa.lehmann@ans-netz.de>
	<1240593706.2142.38.camel@balrog.2hip.net>
	<20090424195205.73a2cf44.lehmann@ans-netz.de>
	<1240596378.2142.45.camel@balrog.2hip.net>
	<20090425092310.a0471901.lehmann@ans-netz.de>
	<20090425101909.bad0e8b3.lehmann@ans-netz.de>
	<1240672173.1946.5.camel@balrog.2hip.net>
	<20090426102126.843c35f3.lehmann@ans-netz.de>
	<1240766181.4395.0.camel@wombat.2hip.net>
	<20090427071837.b18d19f2.lehmann@ans-netz.de>
	<20090501075205.a8cb38e1.lehmann@ans-netz.de>
Message-ID: <1241194021.1848.3.camel@balrog.2hip.net>

On Fri, 2009-05-01 at 07:52 +0200, Oliver Lehmann wrote:
> Hi Robert
> 
> Oliver Lehmann wrote:
> 
> > Robert Noland wrote:
> > 
> > > It still might be useful... Option "BusType" "PCI"
> 
> any new here?

No, sorry... I got distracted by over heating and trashing the disk in
my test machine...  Note to self... Saphire cards shouldn't exhaust into
drive cage...

robert.

-- 
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-stable/attachments/20090501/a1533548/attachment.pgp
From amesbury at umn.edu  Fri May  1 16:50:24 2009
From: amesbury at umn.edu (Alan Amesbury)
Date: Fri May  1 16:50:32 2009
Subject: Garbled output from kgdb?
In-Reply-To: <200905010947.54855.jhb@freebsd.org>
References: <49F8B859.7060908@umn.edu> <200905010947.54855.jhb@freebsd.org>
Message-ID: <49FB2847.406@umn.edu>

John Baldwin wrote:

> Drop the '0x8:' from this and it will work better.  Also, 'bt' output would be 
> good.

Thanks for the pointer (no pun intended).


(kgdb) list *0xffffffff80424561
0xffffffff80424561 is in turnstile_wait
(/usr/src/sys/kern/subr_turnstile.c:727).
722                     else
723
TAILQ_INSERT_TAIL(&ts->ts_blocked[queue], td, td_lockq);
724                     MPASS(owner == ts->ts_owner);
725                     mtx_unlock_spin(&td_contested_lock);
726                     MPASS(td->td_turnstile != NULL);
727                     LIST_INSERT_HEAD(&ts->ts_free, td->td_turnstile,
ts_hash);
728             }
729             thread_lock(td);
730             thread_lock_set(td, &ts->ts_lock);
731             td->td_turnstile = NULL;




The backtrace looked odd (lots of stuff apparently missing), which is
why I didn't include it before.  Here it is with repeated lines
collapsed for brevity:


(kgdb) backtrace
#0  doadump () at pcpu.h:195
#1  0x0000000000000000 in ?? ()
#2  0xffffffff803ee713 in boot (howto=260) at
/usr/src/sys/kern/kern_shutdown.c:418
#3  0xffffffff803ee9c5 in panic (fmt=Variable "fmt" is not available.
) at /usr/src/sys/kern/kern_shutdown.c:574
#4  0xffffffff8062478e in trap_fatal (frame=0xffffffffac057a40, eva=96)
at /usr/src/sys/amd64/amd64/trap.c:764
#5  0xffffffff806251c6 in trap (frame=0xffffffffac057a40) at
/usr/src/sys/amd64/amd64/trap.c:290
#6  0xffffffff8060aafe in calltrap () at
/usr/src/sys/amd64/amd64/exception.S:209
#7  0xffffffff80424561 in turnstile_wait (ts=0xffffff000105dd20,
owner=Variable "owner" is not available.
) at /usr/src/sys/kern/subr_turnstile.c:727
#8  0xffffffff803e0915 in _mtx_lock_sleep (m=0xffffff00011ff600,
tid=18446742974215718624, opts=Variable "opts" is not available.
) at /usr/src/sys/kern/kern_mutex.c:420
#9  0xffffffff801ee1e9 in AcpiOsAcquireLock (Handle=0xffffff000105dd20)
at /usr/src/sys/dev/acpica/Osd/OsdSynch.c:377
#10 0xffffffff801aaf9c in AcpiSetRegister (RegisterId=1, Value=1) at
/usr/src/sys/contrib/dev/acpica/hwregs.c:444
#11 0xffffffff801f5f6e in acpi_cpu_idle () at
/usr/src/sys/dev/acpica/acpi_cpu.c:928
#12 0xffffffff806119a9 in cpu_idle () at
/usr/src/sys/amd64/amd64/machdep.c:581
#13 0xffffffff8040f0e4 in sched_idletd (dummy=Variable "dummy" is not
available.
) at /usr/src/sys/kern/sched_ule.c:2676
#14 0xffffffff803caa30 in fork_exit (callout=0xffffffff8040ee00
<sched_idletd>, arg=0x0, frame=0xffffffffac057c80) at
/usr/src/sys/kern/kern_fork.c:804
#15 0xffffffff8060aece in fork_trampoline () at
/usr/src/sys/amd64/amd64/exception.S:455
#16 0x0000000000000000 in ?? ()
					[identical lines 17-38 removed]
#39 0x0000000000000000 in ?? ()
#40 0x0000000000afe000 in ?? ()
#41 0xffffffff808b08c0 in tdq_cpu ()
#42 0x0000000000000000 in ?? ()
#43 0xffffffff808bacc0 in tdq_groups ()
#44 0xffffff00010f86e0 in ?? ()
#45 0xffffff00010f8a10 in ?? ()
#46 0xffffffffac057a18 in ?? ()
#47 0x0000000000000006 in ?? ()
#48 0xffffffff8040e963 in sched_switch (td=0xffffffff8040ee00,
newtd=Variable "newtd" is not available.
) at /usr/src/sys/kern/sched_ule.c:1938
#49 0x0000000000000000 in ?? ()
					[identical lines 50-114 removed]
#115 0x0000000000000000 in ?? ()
#116 0x0000000000000000 in ?? ()
Cannot access memory at address 0xffffffffac058000




-- 
Alan Amesbury
OIT Security and Assurance
University of Minnesota
From bms at incunabulum.net  Fri May  1 16:51:31 2009
From: bms at incunabulum.net (Bruce Simpson)
Date: Fri May  1 16:51:44 2009
Subject: kernel compile fails without AH_SUPPORT_AR5416
In-Reply-To: <49FB1BE4.20502@freebsd.org>
References: <49E6DB25.2010601@sippysoft.com>	<b84edfa10904160238u7a94e4aw4f60372a6b99f2a2@mail.gmail.com>	<49E6FF8F.4070403@sippysoft.com>	<b84edfa10904160505s45bcee01n3e516a00d1e4dffe@mail.gmail.com>	<49ED6AD2.4010006@incunabulum.net>
	<49EDDD51.9040608@freebsd.org>	<49FAF3F5.5070609@incunabulum.net>
	<49FB1A3F.3000809@freebsd.org> <49FB1BE4.20502@freebsd.org>
Message-ID: <49FB288E.7070402@incunabulum.net>

Sam Leffler wrote:
> ...
>>>> the "ath_hal" device.
>> Do not modify ah_desc.h like you've done.  Add this to conf/options
>>
>> ATH_HAL   opt_ah.h
>>
>> and use that to enable AH_SUPPORT_AR5416.
>>
> To clarify the first comment: you've made it impossible to build code 
> w/o the extended format descriptor; this is what I find unacceptable.

Ah, of course, duh -- I forgot about the CaPiTalIzAtion of the device 
name gets pulled into config(5) with the 'device' keyword. Thanks for 
the reminder...

This is a much cleaner fix for the issue than forcing the option to be 
set on always. It looks like HEAD has this issue too and this can go 
right in there.

Are we happy with AH_SUPPORT_AR5416 being enabled in 7.x GENERIC?
The 'out of box' config hasn't been broken by the change and this is 
identical to to the situation in HEAD as far as I can see.

thanks,
BMS


From sam at freebsd.org  Fri May  1 17:34:45 2009
From: sam at freebsd.org (Sam Leffler)
Date: Fri May  1 17:34:52 2009
Subject: kernel compile fails without AH_SUPPORT_AR5416
In-Reply-To: <49FB288E.7070402@incunabulum.net>
References: <49E6DB25.2010601@sippysoft.com>	<b84edfa10904160238u7a94e4aw4f60372a6b99f2a2@mail.gmail.com>	<49E6FF8F.4070403@sippysoft.com>	<b84edfa10904160505s45bcee01n3e516a00d1e4dffe@mail.gmail.com>	<49ED6AD2.4010006@incunabulum.net>	<49EDDD51.9040608@freebsd.org>	<49FAF3F5.5070609@incunabulum.net>	<49FB1A3F.3000809@freebsd.org>
	<49FB1BE4.20502@freebsd.org> <49FB288E.7070402@incunabulum.net>
Message-ID: <49FB32B3.1080707@freebsd.org>

Bruce Simpson wrote:
> Sam Leffler wrote:
>> ...
>>>>> the "ath_hal" device.
>>> Do not modify ah_desc.h like you've done.  Add this to conf/options
>>>
>>> ATH_HAL   opt_ah.h
>>>
>>> and use that to enable AH_SUPPORT_AR5416.
>>>
>> To clarify the first comment: you've made it impossible to build code 
>> w/o the extended format descriptor; this is what I find unacceptable.
>
> Ah, of course, duh -- I forgot about the CaPiTalIzAtion of the device 
> name gets pulled into config(5) with the 'device' keyword. Thanks for 
> the reminder...
>
> This is a much cleaner fix for the issue than forcing the option to be 
> set on always. It looks like HEAD has this issue too and this can go 
> right in there.
>
> Are we happy with AH_SUPPORT_AR5416 being enabled in 7.x GENERIC?
> The 'out of box' config hasn't been broken by the change and this is 
> identical to to the situation in HEAD as far as I can see.

Not sure I understand your last question.  If you fix the code so it's 
not dependent on "options AH_SUPPORT_AR5416" then you can just remove it 
from the GENERIC config files.  Otherwise the intent was that "device 
ath_hal" would enable all available chip support so yes we want support 
for 5416 and later parts.

In fact AH_SUPPORT_AR5416 is probably not needed at all; we can 
conditionalize the code according to the device config; e.g.

#if defined(ATH_HAL) || defined(ATH_AR5416) || defined(ATH_AR9160) || 
defined(ATH_AR9280)

or possibly consolidate this check in one spot and define something like 
AH_SUPPORT_AR5416 to enable the extended descriptor format support.

Beware of driver code that depends on AH_SUPPORT_AR5416 (grep shows 
several uses).

For now just fixing the immediate problem is sufficient; I'll get to 
cleaning this stuff up later (unless you care to deal with it).

    Sam

From jhb at freebsd.org  Fri May  1 19:08:38 2009
From: jhb at freebsd.org (John Baldwin)
Date: Fri May  1 19:08:54 2009
Subject: Garbled output from kgdb?
In-Reply-To: <49FB2847.406@umn.edu>
References: <49F8B859.7060908@umn.edu> <200905010947.54855.jhb@freebsd.org>
	<49FB2847.406@umn.edu>
Message-ID: <200905011501.40083.jhb@freebsd.org>

On Friday 01 May 2009 12:50:15 pm Alan Amesbury wrote:
> John Baldwin wrote:
> 
> > Drop the '0x8:' from this and it will work better.  Also, 'bt' output 
would be 
> > good.
> 
> Thanks for the pointer (no pun intended).
> 
> 
> (kgdb) list *0xffffffff80424561
> 0xffffffff80424561 is in turnstile_wait
> (/usr/src/sys/kern/subr_turnstile.c:727).
> 722                     else
> 723
> TAILQ_INSERT_TAIL(&ts->ts_blocked[queue], td, td_lockq);
> 724                     MPASS(owner == ts->ts_owner);
> 725                     mtx_unlock_spin(&td_contested_lock);
> 726                     MPASS(td->td_turnstile != NULL);
> 727                     LIST_INSERT_HEAD(&ts->ts_free, td->td_turnstile,
> ts_hash);
> 728             }
> 729             thread_lock(td);
> 730             thread_lock_set(td, &ts->ts_lock);
> 731             td->td_turnstile = NULL;

This is odd.

> The backtrace looked odd (lots of stuff apparently missing), which is
> why I didn't include it before.  Here it is with repeated lines
> collapsed for brevity:


> 
> 
> (kgdb) backtrace
> #0  doadump () at pcpu.h:195
> #1  0x0000000000000000 in ?? ()
> #2  0xffffffff803ee713 in boot (howto=260) at
> /usr/src/sys/kern/kern_shutdown.c:418
> #3  0xffffffff803ee9c5 in panic (fmt=Variable "fmt" is not available.
> ) at /usr/src/sys/kern/kern_shutdown.c:574
> #4  0xffffffff8062478e in trap_fatal (frame=0xffffffffac057a40, eva=96)
> at /usr/src/sys/amd64/amd64/trap.c:764
> #5  0xffffffff806251c6 in trap (frame=0xffffffffac057a40) at
> /usr/src/sys/amd64/amd64/trap.c:290
> #6  0xffffffff8060aafe in calltrap () at
> /usr/src/sys/amd64/amd64/exception.S:209
> #7  0xffffffff80424561 in turnstile_wait (ts=0xffffff000105dd20,
> owner=Variable "owner" is not available.
> ) at /usr/src/sys/kern/subr_turnstile.c:727
> #8  0xffffffff803e0915 in _mtx_lock_sleep (m=0xffffff00011ff600,
> tid=18446742974215718624, opts=Variable "opts" is not available.
> ) at /usr/src/sys/kern/kern_mutex.c:420
> #9  0xffffffff801ee1e9 in AcpiOsAcquireLock (Handle=0xffffff000105dd20)
> at /usr/src/sys/dev/acpica/Osd/OsdSynch.c:377
> #10 0xffffffff801aaf9c in AcpiSetRegister (RegisterId=1, Value=1) at
> /usr/src/sys/contrib/dev/acpica/hwregs.c:444
> #11 0xffffffff801f5f6e in acpi_cpu_idle () at
> /usr/src/sys/dev/acpica/acpi_cpu.c:928
> #12 0xffffffff806119a9 in cpu_idle () at
> /usr/src/sys/amd64/amd64/machdep.c:581
> #13 0xffffffff8040f0e4 in sched_idletd (dummy=Variable "dummy" is not
> available.
> ) at /usr/src/sys/kern/sched_ule.c:2676
> #14 0xffffffff803caa30 in fork_exit (callout=0xffffffff8040ee00
> <sched_idletd>, arg=0x0, frame=0xffffffffac057c80) at
> /usr/src/sys/kern/kern_fork.c:804
> #15 0xffffffff8060aece in fork_trampoline () at
> /usr/src/sys/amd64/amd64/exception.S:455

The trace actually ends here.  There is nothing super bad here but there is a 
big problem actually in that the idle threads cannot block on a lock, so it 
is a problem for the ACPI code to be acquiring a mutex here.  Perhaps the 
locks protecting the idle registers need to use spin locks instead.  The 
problem with blocking in the idle thread is that the scheduler assumes (even 
requires) that the idle thread is _always_ runnable.

-- 
John Baldwin
From amesbury at umn.edu  Fri May  1 19:18:40 2009
From: amesbury at umn.edu (Alan Amesbury)
Date: Fri May  1 19:18:47 2009
Subject: Garbled output from kgdb?
In-Reply-To: <200905011501.40083.jhb@freebsd.org>
References: <49F8B859.7060908@umn.edu> <200905010947.54855.jhb@freebsd.org>
	<49FB2847.406@umn.edu> <200905011501.40083.jhb@freebsd.org>
Message-ID: <49FB4B0E.4060902@umn.edu>

John Baldwin wrote:

> This is odd.
[snip]
> The trace actually ends here.  There is nothing super bad here but there is a 
> big problem actually in that the idle threads cannot block on a lock, so it 
> is a problem for the ACPI code to be acquiring a mutex here.  Perhaps the 
> locks protecting the idle registers need to use spin locks instead.  The 
> problem with blocking in the idle thread is that the scheduler assumes (even 
> requires) that the idle thread is _always_ runnable.

I'm a bit out of my depth when it comes to kernel debugging.  That said,
if you can think of anything I can do or provide which might help narrow
down the scope and nature of the bug (ACPI code in the host's firmware,
an error in FreeBSD's ACPI support, etc.), let me know what needs to be
done.  I'll provide it to the list.  It's a production host, so I'd like
to keep disruptions to a minimum.  That said, it's panicked more than
once, so I think I can justify using it towards elimination of the cause
of that panic if necessary.

I appreciate you taking the time to look at it this far!  Thanks!


-- 
Alan Amesbury
OIT Security and Assurance
University of Minnesota
From mike at sentex.net  Fri May  1 20:42:21 2009
From: mike at sentex.net (Mike Tancsa)
Date: Fri May  1 20:42:28 2009
Subject: current zfs tuning in RELENG_7 (AMD64) suggestions ?
Message-ID: <200905012041.n41Kf47B045440@lava.sentex.ca>

I gave the AMD64 version of 7.2 RC2 a spin and all installed as 
expected off the dvd

INTEL S3200SHV MB, Core2Duo, 4G of RAM

In the past it had been suggested that for zfs tuning, something like

vm.kmem_size_max="1073741824"
vm.kmem_size="1073741824"
vfs.zfs.prefetch_disable=1

However doing a simple test with bonnie and dd, there does not seem 
to be very much difference in 4 configs.  Am I better off just with 
the defaults ?  The machine is acting as anoffline storage site, so a 
steady stream of data via rsync/ssh

The writes are all within the normal variance of the tests except for 
b).  Is there anything else that should be tuned ? Not that I am 
looking for any "magic bullets" but I just want to run this backup 
server as best as possible

               -------Sequential Output-------- ---Sequential Input-- 
--Random--
               -Per Char- --Block--- -Rewrite-- -Per Char- --Block--- 
--Seeks---
           MB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU  /sec %CPU
a        5000  98772 54.7 153111 31.5 100015 21.1 178730 85.3 368782 
32.5 161.6  0.6
b        5000 101271 57.9 154765 31.5  61325 13.9 176741 84.6 372477 
32.8 149.3  0.6
c        5000 102331 57.1 159559 29.5 105767 17.4 144410 63.8 299317 
19.9 167.9  0.6
d        5000 107308 58.6 175004 32.4 117926 18.8 143657 63.4 305126 
20.0 167.6  0.6


a) defaults
b) vm.kmem_size_max="1073741824" vm.kmem_size="1073741824"
c) vfs.zfs.prefetch_disable=1 plus b)
d) vfs.zfs.zil_disable="1" plus c) plus b)



Results tend to fluctuate a bit.

offsitetmp# dd if=/dev/zero of=/tank1/test bs=2048k count=1000
1000+0 records in
1000+0 records out
2097152000 bytes transferred in 10.016818 secs (209363092 bytes/sec)
offsitetmp#
offsitetmp# dd if=/dev/zero of=/tank1/test bs=2048k count=1000
1000+0 records in
1000+0 records out
2097152000 bytes transferred in 10.733547 secs (195382943 bytes/sec)
offsitetmp#

Drives are raidz

ad1: 1430799MB <Seagate ST31500341AS CC1H> at ata3-master SATA300
ad2: 1430799MB <Seagate ST31500341AS CC1H> at ata4-master SATA300
ad3: 1430799MB <Seagate ST31500341AS CC1H> at ata5-master SATA300
ad4: 1430799MB <Seagate ST31500341AS CC1H> at ata6-master SATA300

on ich9

         ---Mike



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

From petefrench at ticketswitch.com  Fri May  1 20:53:13 2009
From: petefrench at ticketswitch.com (Pete French)
Date: Fri May  1 20:53:28 2009
Subject: current zfs tuning in RELENG_7 (AMD64) suggestions ?
In-Reply-To: <200905012041.n41Kf47B045440@lava.sentex.ca>
Message-ID: <E1LzzjJ-0002eV-5A@dilbert.ticketswitch.com>

> In the past it had been suggested that for zfs tuning, something like
>
> vm.kmem_size_max="1073741824"
> vm.kmem_size="1073741824"
> vfs.zfs.prefetch_disable=1
>
> However doing a simple test with bonnie and dd, there does not seem 
> to be very much difference in 4 configs.  Am I better off just with 

The tuning isn't there to improve performance, it's there to prevent
the box going titus due to a panic when the ARC gets too big, and
you are missing the mian one, which is to limit the size of the ARC.
On recent versions of BSD (and you are running 7.2, so thats fine) then
the defaults for kmem size are fine, but you still need something like this:

vfs.zfs.arc_max="256M"

In there to stop the ARC growing. thats the only tuning I have on
my 4 gig machine, which takes a steady stream of data and is used
for taking backup snapshots. ZFS is excellent, and for me is perfectly
stable, to the point where I am starting to roll it out to production
machines, with the above tuning.

-pete.
From petefrench at ticketswitch.com  Fri May  1 21:07:35 2009
From: petefrench at ticketswitch.com (Pete French)
Date: Fri May  1 21:07:43 2009
Subject: kern/133756: [bce] bce commit r190582 breaks lagg in
	7.2-PRERELASE
Message-ID: <E1LzzxG-0002iy-Ow@dilbert.ticketswitch.com>

One more test I just managed to do - using bce and lagg in 'failover' mode
works fine, so it would appear that the problem lies with LACP.

-pete.
From mike at sentex.net  Fri May  1 21:27:59 2009
From: mike at sentex.net (Mike Tancsa)
Date: Fri May  1 21:28:12 2009
Subject: current zfs tuning in RELENG_7 (AMD64) suggestions ?
In-Reply-To: <E1LzzjJ-0002eV-5A@dilbert.ticketswitch.com>
References: <200905012041.n41Kf47B045440@lava.sentex.ca>
	<E1LzzjJ-0002eV-5A@dilbert.ticketswitch.com>
Message-ID: <200905012126.n41LQiIk045684@lava.sentex.ca>

At 04:53 PM 5/1/2009, Pete French wrote:

>The tuning isn't there to improve performance, it's there to prevent
>the box going titus due to a panic when the ARC gets too big, and
>you are missing the mian one, which is to limit the size of the ARC.
>On recent versions of BSD (and you are running 7.2, so thats fine) then
>the defaults for kmem size are fine, but you still need something like this:
>
>vfs.zfs.arc_max="256M"
>
>In there to stop the ARC growing. thats the only tuning I have on
>my 4 gig machine, which takes a steady stream of data and is used
>for taking backup snapshots. ZFS is excellent, and for me is perfectly
>stable, to the point where I am starting to roll it out to production
>machines, with the above tuning.


Thanks for the feedback.  We too have had good results with zfs for 
what we have used it for.  Our primary backup server has a 
traditional raid5 spool as well as a zfs spool and it has been 
working quite well in the last 6months. In that period we did swap 
out a dead drive, a dying drive and added a new drive to expand the 
pool.  We are just expanding our DR site's backup server and will 
make use of ZFS there.  Stability / reliability is our main goal for 
this app so I will take a look at the arc_max setting

         ---Mike 

From louisk at cryptomonkeys.org  Fri May  1 23:12:50 2009
From: louisk at cryptomonkeys.org (Louis Kowolowski)
Date: Fri May  1 23:12:57 2009
Subject: current zfs tuning in RELENG_7 (AMD64) suggestions ?
In-Reply-To: <E1LzzjJ-0002eV-5A@dilbert.ticketswitch.com>
References: <E1LzzjJ-0002eV-5A@dilbert.ticketswitch.com>
Message-ID: <32A0BDD9-ACF8-43F4-8D2C-0FC151F1D7CB@cryptomonkeys.org>


On May 1, 2009, at 1:53 PM, Pete French wrote:

> ...
> The tuning isn't there to improve performance, it's there to prevent
> the box going titus due to a panic when the ARC gets too big, and
> you are missing the mian one, which is to limit the size of the ARC.
> On recent versions of BSD (and you are running 7.2, so thats fine)  
> then
> the defaults for kmem size are fine, but you still need something  
> like this:
>
> vfs.zfs.arc_max="256M"
>
> In there to stop the ARC growing. thats the only tuning I have on
> my 4 gig machine, which takes a steady stream of data and is used
> for taking backup snapshots. ZFS is excellent, and for me is perfectly
> stable, to the point where I am starting to roll it out to production
> machines, with the above tuning.
>
I agree, although I'm using 384 instead of 256.  My systems have been  
running in production for almost a year now w/o any ZFS issues.
--
Louis Kowolowski                                louisk@cryptomonkeys.org
Cryptomonkeys:                      http://www.cryptomonkeys.org/~louisk

Making life more interesting for people since 1977

From fjwcash at gmail.com  Fri May  1 23:28:42 2009
From: fjwcash at gmail.com (Freddie Cash)
Date: Fri May  1 23:28:49 2009
Subject: current zfs tuning in RELENG_7 (AMD64) suggestions ?
In-Reply-To: <32A0BDD9-ACF8-43F4-8D2C-0FC151F1D7CB@cryptomonkeys.org>
References: <E1LzzjJ-0002eV-5A@dilbert.ticketswitch.com>
	<32A0BDD9-ACF8-43F4-8D2C-0FC151F1D7CB@cryptomonkeys.org>
Message-ID: <b269bc570905011628x61105871t5fb0cdbad310ac1c@mail.gmail.com>

On Fri, May 1, 2009 at 4:12 PM, Louis Kowolowski
<louisk@cryptomonkeys.org> wrote:
> On May 1, 2009, at 1:53 PM, Pete French wrote:
>> ...
>> The tuning isn't there to improve performance, it's there to prevent
>> the box going titus due to a panic when the ARC gets too big, and
>> you are missing the mian one, which is to limit the size of the ARC.
>> On recent versions of BSD (and you are running 7.2, so thats fine) then
>> the defaults for kmem size are fine, but you still need something like
>> this:
>>
>> vfs.zfs.arc_max="256M"
>>
>> In there to stop the ARC growing. thats the only tuning I have on
>> my 4 gig machine, which takes a steady stream of data and is used
>> for taking backup snapshots. ZFS is excellent, and for me is perfectly
>> stable, to the point where I am starting to roll it out to production
>> machines, with the above tuning.
>>
> I agree, although I'm using 384 instead of 256. ?My systems have been
> running in production for almost a year now w/o any ZFS issues.

The exact value to use will depend on the system.  Particularly on the
amount of RAM in the system, and what kmem_max is set to.  A
"rule-of-thumb" we've been using is:
   kmem_max should be half of the amount of RAM (or 1.5 GB as that's
the current max)
   arc_max should be half of kmem_max

Using those, we've been able to run our ZFS boxes without any kmem
panics, even when doing rsync backups for 102 remote servers every
night to a single box.

Finding those values was fun.  :(
-- 
Freddie Cash
fjwcash@gmail.com
From mcdouga9 at egr.msu.edu  Sat May  2 00:05:51 2009
From: mcdouga9 at egr.msu.edu (Adam McDougall)
Date: Sat May  2 00:05:59 2009
Subject: current zfs tuning in RELENG_7 (AMD64) suggestions ?
In-Reply-To: <200905012041.n41Kf47B045440@lava.sentex.ca>
References: <200905012041.n41Kf47B045440@lava.sentex.ca>
Message-ID: <20090501234619.GZ574@egr.msu.edu>

On Fri, May 01, 2009 at 04:42:09PM -0400, Mike Tancsa wrote:

  I gave the AMD64 version of 7.2 RC2 a spin and all installed as 
  expected off the dvd
  
  INTEL S3200SHV MB, Core2Duo, 4G of RAM
  
<snip>

  The writes are all within the normal variance of the tests except for 
  b).  Is there anything else that should be tuned ? Not that I am 
  looking for any "magic bullets" but I just want to run this backup 
  server as best as possible
  
                 -------Sequential Output-------- ---Sequential Input-- 
  --Random--
                 -Per Char- --Block--- -Rewrite-- -Per Char- --Block--- 
  --Seeks---
             MB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU  /sec %CPU
  a        5000  98772 54.7 153111 31.5 100015 21.1 178730 85.3 368782 
  32.5 161.6  0.6
  b        5000 101271 57.9 154765 31.5  61325 13.9 176741 84.6 372477 
  32.8 149.3  0.6
  c        5000 102331 57.1 159559 29.5 105767 17.4 144410 63.8 299317 
  19.9 167.9  0.6
  d        5000 107308 58.6 175004 32.4 117926 18.8 143657 63.4 305126 
  20.0 167.6  0.6


<begin brain dump>
  
You might want to try running gstat -I 100000 during the test to see   
how fast each drive flushes the cache from ram and if there are any
disks slower than the others.  I've found some cards or slots cause 
drives to perform slower than other drives in the system, dragging down
performance of the raid to the slowest drive(s).  Individual performance
testing of the drives outside of the raid might reveal something too,
even just to find out what the maximum sequential speed of one drive is
so you know that 4x(speed) is the best to hope for in raid tests.

ZFS tends to cache heavily at the start of each write and you will 
probably see it bounce between no IO and furious writes, until the ram 
cache fills up more and it has no choice but to write almost constantly.  
This can affect the results between runs.  I would recommend a larger 
count= that results in a test run of 30-60 seconds at least.

Additionally, try other zfs raid types such as mirror and stripe to see 
if raidz is acting as an unexpectedly large bottleneck, I've found its 
serial write speed usually leaves something to be desired.  Even if the 
other raid levels won't work realistically in the long run, its useful 
to raise the bar to find out what extra performance your IO setup can 
push. It could be useful to compare with gstripe and graid3 for further 
hardware performance evaluation.  On the other hand, if you can 
read/write data faster than your network connection can push, you're 
probably at a workable level.

Also, I believe that zfs uses a cluster size up to 128k (queueing 
multiple writes if it can, depending on the disk subsystem) so I think 
the computer has to do extra work if you are giving it bs=2048k since 
zfs will have to cut that into 16 pieces, sending one piece to each 
drive.  You might try bs=512k or bs=128k for example to see if this has 
a positive effect.  In a traditional raid5 setup, I've found I get head 
over heals the best performance when my bs= is the same size as the raid 
stripe size multiplied by the number of drives, and this gets weird when 
you have an odd number of drives because your optimum write size might 
be something like 768k which probably no application is going to produce 
:)  Also it makes it hard to optimize UFS for a larger stripe size when
the cluster sizes are generally limited to 16k such as in Solaris.

  Results tend to fluctuate a bit.
  
  offsitetmp# dd if=/dev/zero of=/tank1/test bs=2048k count=1000
  1000+0 records in
  1000+0 records out
  2097152000 bytes transferred in 10.016818 secs (209363092 bytes/sec)
  offsitetmp#
  offsitetmp# dd if=/dev/zero of=/tank1/test bs=2048k count=1000
  1000+0 records in
  1000+0 records out
  2097152000 bytes transferred in 10.733547 secs (195382943 bytes/sec)
  offsitetmp#
  
  Drives are raidz
  
  ad1: 1430799MB <Seagate ST31500341AS CC1H> at ata3-master SATA300
  ad2: 1430799MB <Seagate ST31500341AS CC1H> at ata4-master SATA300
  ad3: 1430799MB <Seagate ST31500341AS CC1H> at ata5-master SATA300
  ad4: 1430799MB <Seagate ST31500341AS CC1H> at ata6-master SATA300
  
  on ich9
  
           ---Mike
  
  
  
  --------------------------------------------------------------------
  Mike Tancsa,                                      tel +1 519 651 3400
  Sentex Communications,                            mike@sentex.net
  Providing Internet since 1994                    www.sentex.net
  Cambridge, Ontario Canada                         www.sentex.net/mike
  
  _______________________________________________
  freebsd-stable@freebsd.org mailing list
  http://lists.freebsd.org/mailman/listinfo/freebsd-stable
  To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org"
  
From cperciva at freebsd.org  Sat May  2 02:13:16 2009
From: cperciva at freebsd.org (FreeBSD Security Officer)
Date: Sat May  2 02:13:24 2009
Subject: FreeBSD supported branches update
Message-ID: <49FBAC3A.7050009@freebsd.org>

Hello Everyone,

The branches supported by the FreeBSD Security Officer have been updated
to reflect the EoL (end-of-life) of FreeBSD 7.0.  The new list is below
and at <URL: http://security.freebsd.org/ >.  Please note that FreeBSD
7.0 was originally announced with an EoL date of February 28, 2009, but
the EoL was delayed by two months in order to allow a 3 month window for
systems to be upgraded to FreeBSD 7.1.

Users of FreeBSD 7.0 are advised to upgrade promptly to FreeBSD 7.1,
either by downloading an updated source tree and building updates manually,
or (for i386 and amd64 systems) using the FreeBSD Update utility as
described in the FreeBSD 7.1 release announcement.  Some users may wish to
wait for the upcoming FreeBSD 7.2-RELEASE; however, they should be aware
that FreeBSD 7.2-RELEASE will only receive "normal" support (i.e., support
for 12 months) and consequently it will not be supported for as long as
FreeBSD 7.1.

[Excerpt from http://security.freebsd.org/ follows]

FreeBSD Security Advisories

    The FreeBSD Security Officer provides security advisories for
    several branches of FreeBSD development. These are the -STABLE
    Branches and the Security Branches. (Advisories are not issued for
    the -CURRENT Branch.)

      * The -STABLE branch tags have names like RELENG_7. The
        corresponding builds have names like FreeBSD 7.0-STABLE.

      * Each FreeBSD Release has an associated Security Branch. The
        Security Branch tags have names like RELENG_7_0. The
        corresponding builds have names like FreeBSD 7.0-RELEASE-p1.

    Isses affecting the FreeBSD Ports Collection are covered in the
    FreeBSD VuXML document.

    Each branch is supported by the Security Officer for a limited
    time only, and is designated as one of `Early adopter', `Normal',
    or `Extended'.  The designation is used as a guideline for
    determining the lifetime of the branch as follows.

    Early adopter
        Releases which are published from the -CURRENT branch will be
        supported by the Security Officer for a minimum of 6 months
        after the release.

    Normal
        Releases which are published from a -STABLE branch will be
        supported by the Security Officer for a minimum of 12 months
        after the release, and for sufficient additional time (if
        needed) to ensure that there is a newer release for at least
        3 months before the older Normal release expires.

    Extended
        Selected releases (normally every second release plus the last
        release from each -STABLE branch) will be supported by the
        Security Officer for a minimum of 24 months after the release,
        and for sufficient additional time (if needed) to ensure that
        there is a newer Extended release for at least 3 months before
        the older Extended release expires.

    The current designation and estimated lifetimes of the currently
    supported branches are given below.  The Estimated EoL (end-of-life)
    column gives the earliest date on which that branch is likely to be
    dropped.  Please note that these dates may be extended into the
    future, but only extenuating circumstances would lead to a branch's
    support being dropped earlier than the date listed.

    +--------------------------------------------------------------------+
    |  Branch   |  Release  |  Type  |  Release date   |  Estimated EoL  |
    |-----------+-----------+--------+-----------------+-----------------|
    |RELENG_6   |n/a        |n/a     |n/a              |November 30, 2010|
    |-----------+-----------+--------+-----------------+-----------------|
    |RELENG_6_3 |6.3-RELEASE|Extended|January 18, 2008 |January 31, 2010 |
    |-----------+-----------+--------+-----------------+-----------------|
    |RELENG_6_4 |6.4-RELEASE|Extended|November 28, 2008|November 30, 2010|
    |-----------+-----------+--------+-----------------+-----------------|
    |RELENG_7   |n/a        |n/a     |n/a              |last release + 2y|
    |-----------+-----------+--------+-----------------+-----------------|
    |RELENG_7_1 |7.1-RELEASE|Extended|January 4, 2009  |January 31, 2011 |
    +--------------------------------------------------------------------+

[End excerpt]

-- 
Colin Percival
Security Officer, FreeBSD | freebsd.org | The power to serve
Founder / author, Tarsnap | tarsnap.com | Online backups for the truly paranoid
From kamikaze at bsdforen.de  Sat May  2 07:18:30 2009
From: kamikaze at bsdforen.de (Dominic Fandrey)
Date: Sat May  2 07:18:39 2009
Subject: bluetooth troubleshooting
Message-ID: <49FBF3C2.8010809@bsdforen.de>

I've got two bluetooth devices, an internal usb bluetooth device by
Broadcom and a dated AVM class1 bluetooth dongle.

Both are detected by the ubt driver:
ubt0: <Broadcom Corp HP Integrated Module, class 224/1, rev 2.00/1.00, addr 2> on uhub0
ubt0: Interface 0 endpoints: interrupt=0x81, bulk-in=0x82, bulk-out=0x2
ubt0: Interface 1 (alt.config 4) endpoints: isoc-in=0x83, isoc-out=0x3; wMaxPacketSize=64; nframes=5, buffer size=320

ubt1: <Bluetooth Device Bluetooth Device, class 255/255, rev 1.10/15.00, addr 3> on uhub3
ubt1: Interface 0 endpoints: interrupt=0x81, bulk-in=0x82, bulk-out=0x2
ubt1: Interface 1 (alt.config 5) endpoints: isoc-in=0x83, isoc-out=0x3; wMaxPacketSize=49; nframes=6, buffer size=294


However neither a device /dev/ubt0 nor /dev/ubt1 exists.

# /etc/rc.d/bluetooth onestart ubt0
/etc/rc.d/bluetooth: ERROR: Unable to setup Bluetooth stack for device ubt0
# /etc/rc.d/bluetooth onestart ubt1
/etc/rc.d/bluetooth: ERROR: Unable to setup Bluetooth stack for device ubt1

This error message gives me no idea of what is wrong. The handbook
mentions comms/hcidump for debugging, but I think this is meant
for analyzing bluetooth traffic.
As you can see I haven't gotten far enough to produce any traffic to
analyse. Is someone here familiar with bluetooth and can provide
me with a command that might reveal something about the nature
of my problem?

BTW, is there a way to get A2DP receive running on FreeBSD?
From waldoalvarez00 at yahoo.com  Sat May  2 07:50:00 2009
From: waldoalvarez00 at yahoo.com (wac)
Date: Sat May  2 07:50:06 2009
Subject: How do i fix the broken FTP structure of freebsd 7.0?
In-Reply-To: <4ad871310904261923s7a1bc56eq68cec4d1e29bd4de@mail.gmail.com>
Message-ID: <891257.34249.qm@web65714.mail.ac4.yahoo.com>


Hi Glen:


--- On Sun, 4/26/09, Glen Barber <glen.j.barber@gmail.com> wrote:

> From: Glen Barber <glen.j.barber@gmail.com>
> Subject: Re: How do i fix the broken FTP structure of freebsd 7.0?
> To: waldoalvarez00@yahoo.com
> Cc: freebsd-stable@freebsd.org
> Date: Sunday, April 26, 2009, 10:23 PM
> On Sun, Apr 26, 2009 at 7:40 PM, wac
> <waldoalvarez00@yahoo.com> wrote:
> >
> > Thanks Glen but doing that in a remote computer is
> askin for trouble and I can't step to the risk of having
> that computer trashed (fixing it would cost almost as much
> as renting a new one). Anyway in the forums somebody gave me
> this:
> 
> Doing what in a remote machine is asking for trouble?  SSH
> will not be affected.

Installing a new kernel remotely. If the new one does not boots properly then I'm in trouble. Serious trouble. (I do not have local access to the console, all the time over ssh and if i reboot it over webmin just in case i make a mistake reconfiguring ssh)

> 
> >
> >
> ftp://ftp-archive.freebsd.org/pub/FreeBSD-Archive/old-releases/i386/7.0-RELEASE/packages/All
> >
> > The problem now is that the package I need is way too
> old. Let's see if i can work out to fix that. Problem is
> it uses perl and perl is used by another package the hosting
> company installed that depends on it. And that I really have
> 0 experience with it so reinstalling a new one means
> downtime. I'll try to modify dkimproxy and see what
> happens. So far the newer version installed with warnings
> but doesn't even start.
> >
> 
> If you need "stability" (production ready), you
> (as the maintainer of
> the machine) are obligated to some extent to keep it both,
> up to date
> and "stable".

Yes and keep it safe from all those attacks i receive 24/7. Problem is upgrade is not an option for me. But that's ok, i removed old perl, old webmin, installed new perl, new webmin, new dkimproxy. Everything went ok since i carefully followed all the steps i simulated in a virtual machine here. And.. Uf. Didn't had to even reboot that one.

> 
> Note:  I use "stable" in quotes to not be
> confused with -STABLE.
> 
> AFAIK, 7.0-REL was EOL'd (or is scheduled to be). 
> Ports are generally
> guaranteed to be installable on the latest -RELEASE version
> (in this
> case, 7.1-RELEASE).  

Now you know it. At least perl from 7-stable, webmin and dkimproxy-1.1 on top of it works just fine on top of the 7.0 release. I tested it, and works great to the point that amazes me.

Anything prior to that is not a
> guarantee.
> Packages (as I am sure you are aware) are only built one
> time -- when
> X.X-RELEASE is released.  There is no guarantee on
> compatibility after
> that point.
> 
> -- 
> Glen Barber
> _______________________________________________
> freebsd-stable@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to
> "freebsd-stable-unsubscribe@freebsd.org"


      
From bruce at cran.org.uk  Sat May  2 10:50:04 2009
From: bruce at cran.org.uk (Bruce Cran)
Date: Sat May  2 10:50:18 2009
Subject: bluetooth troubleshooting
In-Reply-To: <49FBF3C2.8010809@bsdforen.de>
References: <49FBF3C2.8010809@bsdforen.de>
Message-ID: <20090502114958.76c46f25@gluon.draftnet>

On Sat, 02 May 2009 09:18:26 +0200
Dominic Fandrey <kamikaze@bsdforen.de> wrote:

> # /etc/rc.d/bluetooth onestart ubt0
> /etc/rc.d/bluetooth: ERROR: Unable to setup Bluetooth stack for
> device ubt0 # /etc/rc.d/bluetooth onestart ubt1
> /etc/rc.d/bluetooth: ERROR: Unable to setup Bluetooth stack for
> device ubt1
> 
> This error message gives me no idea of what is wrong. The handbook
> mentions comms/hcidump for debugging, but I think this is meant
> for analyzing bluetooth traffic.
> As you can see I haven't gotten far enough to produce any traffic to
> analyse. Is someone here familiar with bluetooth and can provide
> me with a command that might reveal something about the nature
> of my problem?

I think devd now automatically starts the Bluetooth stack when you
plug in a recognised device, so you'll only be able to use onestart
after first running onestop.

-- 
Bruce Cran
From makc at freebsd.org  Sat May  2 10:54:00 2009
From: makc at freebsd.org (Max Brazhnikov)
Date: Sat May  2 10:54:09 2009
Subject: process hanging on 7.2-PRERELEASE
Message-ID: <200905021443.52526.makc@freebsd.org>

Currently all kde4 ports marked as jobs_unsafe, because of automoc4 hangs.
The problem can be easely reproduced building e.g. accessibility/kdeaccessibility4
with multiple jobs: replace MAKE_JOBS_UNSAFE with MAKE_JOBS_SAFE in port Makefile
and run 'make MAKE_JOBS_NUMBER=16'. Build will be freezed on

/usr/local/bin/cmake -E cmake_progress_report /tank/obj/usr/ports/accessibility/kdeaccessibility4/work/kdeaccessibility-4.2.2/build/CMakeFiles  77 78 
79 8081 82 83 84 85 86 87 88 89 90 91 92 93 94 95
[ 95%] Built target kmouth

# ps | grep automoc4
77829  p4  S+     0:00.27 /usr/local/bin/automoc4 /tank/obj/usr/ports/accessibility/kdeaccessibility4/
77840  p4  I+     0:00.00 /usr/local/bin/automoc4 /tank/obj/usr/ports/accessibility/kdeaccessibility4/

#gdb66 automoc4 77829
GNU gdb 6.6 [GDB v6.6 for FreeBSD]
Copyright (C) 2006 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.                                   
There is absolutely no warranty for GDB.  Type "show warranty" for details.  
This GDB was configured as "i386-portbld-freebsd7.0"...                      
Attaching to program: /usr/local/bin/automoc4, process 77829                 
Reading symbols from /usr/local/lib/qt4/libQtCore.so.4...Reading symbols from /usr/local/lib/qt4/libQtCore.so.4.4.3.debug...done.
done.                                                                                                                            
Loaded symbols for /usr/local/lib/qt4/libQtCore.so.4                                                                             
Reading symbols from /usr/lib/libstdc++.so.6...done.                                                                             
Loaded symbols for /usr/lib/libstdc++.so.6                                                                                       
Reading symbols from /lib/libm.so.5...done.                                                                                      
Loaded symbols for /lib/libm.so.5                                                                                                
Reading symbols from /lib/libgcc_s.so.1...done.                                                                                  
Loaded symbols for /lib/libgcc_s.so.1                                                                                            
Reading symbols from /lib/libthr.so.3...done.                                                                                    
Loaded symbols for /lib/libthr.so.3                                                                                              
Reading symbols from /lib/libc.so.7...done.                                                                                      
Loaded symbols for /lib/libc.so.7                                                                                                
Reading symbols from /lib/libz.so.4...done.                                                                                      
Loaded symbols for /lib/libz.so.4                                                                                                
Reading symbols from /usr/local/lib/libgthread-2.0.so.0...done.
Loaded symbols for /usr/local/lib/libgthread-2.0.so.0
Reading symbols from /usr/local/lib/libglib-2.0.so.0...done.
Loaded symbols for /usr/local/lib/libglib-2.0.so.0
Reading symbols from /usr/local/lib/libiconv.so.3...done.
Loaded symbols for /usr/local/lib/libiconv.so.3
Reading symbols from /usr/local/lib/libintl.so.8...done.
Loaded symbols for /usr/local/lib/libintl.so.8
Reading symbols from /usr/local/lib/libpcre.so.0...done.
Loaded symbols for /usr/local/lib/libpcre.so.0
Reading symbols from /libexec/ld-elf.so.1...done.
Loaded symbols for /libexec/ld-elf.so.1
0x2846fb3b in select () at select.S:2
2       RSYSCALL(select)
(gdb) bt
#0  0x2846fb3b in select () at select.S:2
#1  0x2838d788 in __select (numfds=6, readfds=0xbf9feee8, writefds=0x0, exceptfds=0x0, timeout=0x0)
    at /usr/freebsd/7/src/lib/libthr/thread/thr_syscalls.c:444
#2  0x281b4f3d in QProcessManager::run (this=0x287142f0) at io/qprocess_unix.cpp:301
#3  0x280f30e2 in QThreadPrivate::start (arg=0x287142f0) at thread/qthread_unix.cpp:185
#4  0x2838b68a in thread_start (curthread=0x28701150) at /usr/freebsd/7/src/lib/libthr/thread/thr_create.c:288
#5  0x00000000 in ?? ()
Current language:  auto; currently asm
(gdb)


# gdb66 automoc4 77840
GNU gdb 6.6 [GDB v6.6 for FreeBSD]             
Copyright (C) 2006 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.                                   
There is absolutely no warranty for GDB.  Type "show warranty" for details.  
This GDB was configured as "i386-portbld-freebsd7.0"...                      
Attaching to program: /usr/local/bin/automoc4, process 77840                 
Reading symbols from /usr/local/lib/qt4/libQtCore.so.4...Reading symbols from /usr/local/lib/qt4/libQtCore.so.4.4.3.debug...done.
done.                                                                                                                            
Loaded symbols for /usr/local/lib/qt4/libQtCore.so.4                                                                             
Reading symbols from /usr/lib/libstdc++.so.6...done.                                                                             
Loaded symbols for /usr/lib/libstdc++.so.6                                                                                       
Reading symbols from /lib/libm.so.5...done.                                                                                      
Loaded symbols for /lib/libm.so.5                                                                                                
Reading symbols from /lib/libgcc_s.so.1...done.                                                                                  
Loaded symbols for /lib/libgcc_s.so.1                                                                                            
Reading symbols from /lib/libthr.so.3...done.                                                                                    
Loaded symbols for /lib/libthr.so.3                                                                                              
Reading symbols from /lib/libc.so.7...done.                                                                                      
Loaded symbols for /lib/libc.so.7                                                                                                
Reading symbols from /lib/libz.so.4...done.                                                                                      
Loaded symbols for /lib/libz.so.4                                                                                                
Reading symbols from /usr/local/lib/libgthread-2.0.so.0...done.                                                                  
Loaded symbols for /usr/local/lib/libgthread-2.0.so.0                                                                            
Reading symbols from /usr/local/lib/libglib-2.0.so.0...done.                                                                     
Loaded symbols for /usr/local/lib/libglib-2.0.so.0                                                                               
Reading symbols from /usr/local/lib/libiconv.so.3...done.                                                                        
Loaded symbols for /usr/local/lib/libiconv.so.3                                                                                  
Reading symbols from /usr/local/lib/libintl.so.8...done.
Loaded symbols for /usr/local/lib/libintl.so.8
Reading symbols from /usr/local/lib/libpcre.so.0...done.
Loaded symbols for /usr/local/lib/libpcre.so.0
Reading symbols from /libexec/ld-elf.so.1...done.
Loaded symbols for /libexec/ld-elf.so.1
0x28395593 in _umtx_op_err () at /usr/freebsd/7/src/lib/libthr/arch/i386/i386/_umtx_op_err.S:36
36      SYSCALL_ERR(_umtx_op)
(gdb) bt
#0  0x28395593 in _umtx_op_err () at /usr/freebsd/7/src/lib/libthr/arch/i386/i386/_umtx_op_err.S:36
#1  0x283953c4 in __thr_umutex_lock (mtx=0x8054f3c, id=100416) at /usr/freebsd/7/src/lib/libthr/thread/thr_umtx.c:58
#2  0x28390502 in mutex_lock_sleep (curthread=0x28701040, m=0x8054f3c, abstime=0x0) at /usr/freebsd/7/src/lib/libthr/thread/thr_mutex.c:401
#3  0x283fb0ea in _malloc_postfork () at /usr/freebsd/7/src/lib/libc/stdlib/malloc.c:1029
#4  0x28393038 in _fork () at /usr/freebsd/7/src/lib/libthr/thread/thr_fork.c:178
#5  0x281b7381 in QProcessPrivate::startProcess (this=0x287720f0) at io/qprocess_unix.cpp:570
#6  0x2817a181 in QProcess::start (this=0xbfbfe1b8, program=@0xbfbfe5dc, arguments=@0xbfbfe1b4, mode=@0xbfbfe1c0) at io/qprocess.cpp:1508
#7  0x08051720 in AutoMoc::echoColor (this=0xbfbfe5c8, msg=@0xbfbfe258) at /tank/obj/usr/ports/devel/automoc4/work/automoc4-0.9.88/kde4automoc.cpp:73
#8  0x0804c0a7 in AutoMoc::generateMoc (this=0xbfbfe5c8, sourceFile=@0x28714418, mocFileName=@0x2871441c)
    at /tank/obj/usr/ports/devel/automoc4/work/automoc4-0.9.88/kde4automoc.cpp:569
#9  0x0804f4ae in AutoMoc::run (this=0xbfbfe5c8) at /tank/obj/usr/ports/devel/automoc4/work/automoc4-0.9.88/kde4automoc.cpp:470
#10 0x080504e6 in main (argc=Cannot access memory at address 0x0
) at /tank/obj/usr/ports/devel/automoc4/work/automoc4-0.9.88/kde4automoc.cpp:114
Current language:  auto; currently asm
(gdb)
From kamikaze at bsdforen.de  Sat May  2 12:25:33 2009
From: kamikaze at bsdforen.de (Dominic Fandrey)
Date: Sat May  2 12:25:42 2009
Subject: bluetooth troubleshooting
In-Reply-To: <20090502114958.76c46f25@gluon.draftnet>
References: <49FBF3C2.8010809@bsdforen.de>
	<20090502114958.76c46f25@gluon.draftnet>
Message-ID: <49FC3BB9.6000200@bsdforen.de>

Bruce Cran wrote:
> On Sat, 02 May 2009 09:18:26 +0200
> Dominic Fandrey <kamikaze@bsdforen.de> wrote:
> 
>> # /etc/rc.d/bluetooth onestart ubt0
>> /etc/rc.d/bluetooth: ERROR: Unable to setup Bluetooth stack for
>> device ubt0 # /etc/rc.d/bluetooth onestart ubt1
>> /etc/rc.d/bluetooth: ERROR: Unable to setup Bluetooth stack for
>> device ubt1
>>
>> This error message gives me no idea of what is wrong. The handbook
>> mentions comms/hcidump for debugging, but I think this is meant
>> for analyzing bluetooth traffic.
>> As you can see I haven't gotten far enough to produce any traffic to
>> analyse. Is someone here familiar with bluetooth and can provide
>> me with a command that might reveal something about the nature
>> of my problem?
> 
> I think devd now automatically starts the Bluetooth stack when you
> plug in a recognised device, so you'll only be able to use onestart
> after first running onestop.
> 

So it's already working! I was confused because the output of

# hccontrol -n ubt0hci inquiry
Inquiry complete. Status: No error [00]

is pretty lame compared to what should appear according to the
handbook:

% hccontrol -n ubt0hci inquiry
Inquiry result, num_responses=1
Inquiry result #0
       BD_ADDR: 00:80:37:29:19:a4
       Page Scan Rep. Mode: 0x1
       Page Scan Period Mode: 00
       Page Scan Mode: 00
       Class: 52:02:04
       Clock offset: 0x78ef
Inquiry complete. Status: No error [00]


Thanks a lot!
From kostikbel at gmail.com  Sat May  2 13:34:22 2009
From: kostikbel at gmail.com (Kostik Belousov)
Date: Sat May  2 13:34:29 2009
Subject: process hanging on 7.2-PRERELEASE
In-Reply-To: <200905021443.52526.makc@freebsd.org>
References: <200905021443.52526.makc@freebsd.org>
Message-ID: <20090502124516.GE17826@deviant.kiev.zoral.com.ua>

On Sat, May 02, 2009 at 02:43:52PM +0400, Max Brazhnikov wrote:
> Currently all kde4 ports marked as jobs_unsafe, because of automoc4 hangs.
> The problem can be easely reproduced building e.g. accessibility/kdeaccessibility4
> with multiple jobs: replace MAKE_JOBS_UNSAFE with MAKE_JOBS_SAFE in port Makefile
> and run 'make MAKE_JOBS_NUMBER=16'. Build will be freezed on
> 
> /usr/local/bin/cmake -E cmake_progress_report /tank/obj/usr/ports/accessibility/kdeaccessibility4/work/kdeaccessibility-4.2.2/build/CMakeFiles  77 78 
> 79 8081 82 83 84 85 86 87 88 89 90 91 92 93 94 95
> [ 95%] Built target kmouth
> 
> # ps | grep automoc4
> 77829  p4  S+     0:00.27 /usr/local/bin/automoc4 /tank/obj/usr/ports/accessibility/kdeaccessibility4/
> 77840  p4  I+     0:00.00 /usr/local/bin/automoc4 /tank/obj/usr/ports/accessibility/kdeaccessibility4/
> 
> #gdb66 automoc4 77829
> 0x2846fb3b in select () at select.S:2
> 2       RSYSCALL(select)
> (gdb) bt
> #0  0x2846fb3b in select () at select.S:2
> #1  0x2838d788 in __select (numfds=6, readfds=0xbf9feee8, writefds=0x0, exceptfds=0x0, timeout=0x0)
>     at /usr/freebsd/7/src/lib/libthr/thread/thr_syscalls.c:444
> #2  0x281b4f3d in QProcessManager::run (this=0x287142f0) at io/qprocess_unix.cpp:301
> #3  0x280f30e2 in QThreadPrivate::start (arg=0x287142f0) at thread/qthread_unix.cpp:185
> #4  0x2838b68a in thread_start (curthread=0x28701150) at /usr/freebsd/7/src/lib/libthr/thread/thr_create.c:288
> #5  0x00000000 in ?? ()
> Current language:  auto; currently asm
> (gdb)
> 
> 
> # gdb66 automoc4 77840
> 0x28395593 in _umtx_op_err () at /usr/freebsd/7/src/lib/libthr/arch/i386/i386/_umtx_op_err.S:36
> 36      SYSCALL_ERR(_umtx_op)
> (gdb) bt
> #0  0x28395593 in _umtx_op_err () at /usr/freebsd/7/src/lib/libthr/arch/i386/i386/_umtx_op_err.S:36
> #1  0x283953c4 in __thr_umutex_lock (mtx=0x8054f3c, id=100416) at /usr/freebsd/7/src/lib/libthr/thread/thr_umtx.c:58
> #2  0x28390502 in mutex_lock_sleep (curthread=0x28701040, m=0x8054f3c, abstime=0x0) at /usr/freebsd/7/src/lib/libthr/thread/thr_mutex.c:401
> #3  0x283fb0ea in _malloc_postfork () at /usr/freebsd/7/src/lib/libc/stdlib/malloc.c:1029
> #4  0x28393038 in _fork () at /usr/freebsd/7/src/lib/libthr/thread/thr_fork.c:178
> #5  0x281b7381 in QProcessPrivate::startProcess (this=0x287720f0) at io/qprocess_unix.cpp:570
> #6  0x2817a181 in QProcess::start (this=0xbfbfe1b8, program=@0xbfbfe5dc, arguments=@0xbfbfe1b4, mode=@0xbfbfe1c0) at io/qprocess.cpp:1508
> #7  0x08051720 in AutoMoc::echoColor (this=0xbfbfe5c8, msg=@0xbfbfe258) at /tank/obj/usr/ports/devel/automoc4/work/automoc4-0.9.88/kde4automoc.cpp:73
> #8  0x0804c0a7 in AutoMoc::generateMoc (this=0xbfbfe5c8, sourceFile=@0x28714418, mocFileName=@0x2871441c)
>     at /tank/obj/usr/ports/devel/automoc4/work/automoc4-0.9.88/kde4automoc.cpp:569
> #9  0x0804f4ae in AutoMoc::run (this=0xbfbfe5c8) at /tank/obj/usr/ports/devel/automoc4/work/automoc4-0.9.88/kde4automoc.cpp:470
> #10 0x080504e6 in main (argc=Cannot access memory at address 0x0
> ) at /tank/obj/usr/ports/devel/automoc4/work/automoc4-0.9.88/kde4automoc.cpp:114
> Current language:  auto; currently asm
> (gdb)

Great.

I think this is a missed merge of the r185514 to 7. Can you, please,
retest with that revision merged ?
-------------- 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-stable/attachments/20090502/2c826be1/attachment.pgp
From makc at freebsd.org  Sat May  2 14:06:29 2009
From: makc at freebsd.org (Max Brazhnikov)
Date: Sat May  2 14:06:37 2009
Subject: process hanging on 7.2-PRERELEASE
In-Reply-To: <20090502124516.GE17826@deviant.kiev.zoral.com.ua>
References: <200905021443.52526.makc@freebsd.org>
	<20090502124516.GE17826@deviant.kiev.zoral.com.ua>
Message-ID: <200905021806.28651.makc@freebsd.org>

On Sat, 2 May 2009 15:45:17 +0300, Kostik Belousov wrote:
> On Sat, May 02, 2009 at 02:43:52PM +0400, Max Brazhnikov wrote:
> > Currently all kde4 ports marked as jobs_unsafe, because of automoc4
> > hangs. The problem can be easely reproduced building e.g.
> > accessibility/kdeaccessibility4 with multiple jobs: replace
> > MAKE_JOBS_UNSAFE with MAKE_JOBS_SAFE in port Makefile and run 'make
> > MAKE_JOBS_NUMBER=16'. Build will be freezed on
> >
> > /usr/local/bin/cmake -E cmake_progress_report
> > /tank/obj/usr/ports/accessibility/kdeaccessibility4/work/kdeaccessibility
> >-4.2.2/build/CMakeFiles  77 78 79 8081 82 83 84 85 86 87 88 89 90 91 92 93
> > 94 95
> > [ 95%] Built target kmouth
> >
> > # ps | grep automoc4
> > 77829  p4  S+     0:00.27 /usr/local/bin/automoc4
> > /tank/obj/usr/ports/accessibility/kdeaccessibility4/ 77840  p4  I+    
> > 0:00.00 /usr/local/bin/automoc4
> > /tank/obj/usr/ports/accessibility/kdeaccessibility4/
> >
> > #gdb66 automoc4 77829
> > 0x2846fb3b in select () at select.S:2
> > 2       RSYSCALL(select)
> > (gdb) bt
> > #0  0x2846fb3b in select () at select.S:2
> > #1  0x2838d788 in __select (numfds=6, readfds=0xbf9feee8, writefds=0x0,
> > exceptfds=0x0, timeout=0x0) at
> > /usr/freebsd/7/src/lib/libthr/thread/thr_syscalls.c:444
> > #2  0x281b4f3d in QProcessManager::run (this=0x287142f0) at
> > io/qprocess_unix.cpp:301 #3  0x280f30e2 in QThreadPrivate::start
> > (arg=0x287142f0) at thread/qthread_unix.cpp:185 #4  0x2838b68a in
> > thread_start (curthread=0x28701150) at
> > /usr/freebsd/7/src/lib/libthr/thread/thr_create.c:288 #5  0x00000000 in
> > ?? ()
> > Current language:  auto; currently asm
> > (gdb)
> >
> >
> > # gdb66 automoc4 77840
> > 0x28395593 in _umtx_op_err () at
> > /usr/freebsd/7/src/lib/libthr/arch/i386/i386/_umtx_op_err.S:36 36     
> > SYSCALL_ERR(_umtx_op)
> > (gdb) bt
> > #0  0x28395593 in _umtx_op_err () at
> > /usr/freebsd/7/src/lib/libthr/arch/i386/i386/_umtx_op_err.S:36 #1 
> > 0x283953c4 in __thr_umutex_lock (mtx=0x8054f3c, id=100416) at
> > /usr/freebsd/7/src/lib/libthr/thread/thr_umtx.c:58 #2  0x28390502 in
> > mutex_lock_sleep (curthread=0x28701040, m=0x8054f3c, abstime=0x0) at
> > /usr/freebsd/7/src/lib/libthr/thread/thr_mutex.c:401 #3  0x283fb0ea in
> > _malloc_postfork () at /usr/freebsd/7/src/lib/libc/stdlib/malloc.c:1029
> > #4  0x28393038 in _fork () at
> > /usr/freebsd/7/src/lib/libthr/thread/thr_fork.c:178 #5  0x281b7381 in
> > QProcessPrivate::startProcess (this=0x287720f0) at
> > io/qprocess_unix.cpp:570 #6  0x2817a181 in QProcess::start
> > (this=0xbfbfe1b8, program=@0xbfbfe5dc, arguments=@0xbfbfe1b4,
> > mode=@0xbfbfe1c0) at io/qprocess.cpp:1508 #7  0x08051720 in
> > AutoMoc::echoColor (this=0xbfbfe5c8, msg=@0xbfbfe258) at
> > /tank/obj/usr/ports/devel/automoc4/work/automoc4-0.9.88/kde4automoc.cpp:7
> >3 #8  0x0804c0a7 in AutoMoc::generateMoc (this=0xbfbfe5c8,
> > sourceFile=@0x28714418, mocFileName=@0x2871441c) at
> > /tank/obj/usr/ports/devel/automoc4/work/automoc4-0.9.88/kde4automoc.cpp:5
> >69 #9  0x0804f4ae in AutoMoc::run (this=0xbfbfe5c8) at
> > /tank/obj/usr/ports/devel/automoc4/work/automoc4-0.9.88/kde4automoc.cpp:4
> >70 #10 0x080504e6 in main (argc=Cannot access memory at address 0x0 ) at
> > /tank/obj/usr/ports/devel/automoc4/work/automoc4-0.9.88/kde4automoc.cpp:1
> >14 Current language:  auto; currently asm
> > (gdb)
>
> Great.
>
> I think this is a missed merge of the r185514 to 7. Can you, please,
> retest with that revision merged ?

Great! With the patch I can't reproduce the problem!

From dikshie at gmail.com  Sat May  2 18:44:38 2009
From: dikshie at gmail.com (dikshie)
Date: Sat May  2 18:44:44 2009
Subject: #0 sched_switch (td=0xc579b230, newtd=Variable "newtd" is not 
	available.
Message-ID: <910e60e80905021111v1ef2d386j17db9bccb953b609@mail.gmail.com>

is this known bug?

Fatal trap 12: page fault while in kernel mode
cpuid = 0; apic id = 00
fault virtual address   = 0x8c000180
fault code              = supervisor read, page not present
instruction pointer     = 0x20:0xc063d904
stack pointer           = 0x28:0xe7704608
frame pointer           = 0x28:0xe7704620
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         = 2013 (firefox-bin)
trap number             = 12
panic: page fault
cpuid = 0
Uptime: 5h1m34s
Physical memory: 2038 MB
Dumping 194 MB: 179 163 147 131 115 99 83 (CTRL-C to abort)  67
(CTRL-C to abort)  (CTRL-C to abort)  (CTRL-C to abort)  51 (CTRL-C to
abort)  35 19 3

kgdb: kvm_read: invalid address (0x4c414e52)
kgdb: kvm_read: invalid address (0x35b2e804)
kgdb: kvm_read: invalid address (0x5502)
kgdb: kvm_read: invalid address (0x6a02)
Reading symbols from /boot/kernel/geom_journal.ko...Reading symbols
from /boot/kernel/geom_journal.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/geom_journal.ko
Reading symbols from /boot/kernel/acpi_ibm.ko...Reading symbols from
/boot/kernel/acpi_ibm.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/acpi_ibm.ko
Reading symbols from /boot/kernel/acpi.ko...Reading symbols from
/boot/kernel/acpi.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/acpi.ko
Reading symbols from /boot/kernel/linprocfs.ko...Reading symbols from
/boot/kernel/linprocfs.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/linprocfs.ko
Reading symbols from /boot/kernel/linux.ko...Reading symbols from
/boot/kernel/linux.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/linux.ko
#0  sched_switch (td=0xc579b230, newtd=Variable "newtd" is not available.
) at /usr/src/sys/kern/sched_ule.c:1944
1944                    cpuid = PCPU_GET(cpuid);
(kgdb)


7.2-PRERELEASE FreeBSD 7.2-PRERELEASE #7: Sat May  2 17:06:46 JST 2009





-- 
-dikshie-
From alan.l.cox at gmail.com  Sat May  2 19:11:24 2009
From: alan.l.cox at gmail.com (Alan Cox)
Date: Sat May  2 19:11:32 2009
Subject: current zfs tuning in RELENG_7 (AMD64) suggestions ?
In-Reply-To: <b269bc570905011628x61105871t5fb0cdbad310ac1c@mail.gmail.com>
References: <E1LzzjJ-0002eV-5A@dilbert.ticketswitch.com>
	<32A0BDD9-ACF8-43F4-8D2C-0FC151F1D7CB@cryptomonkeys.org>
	<b269bc570905011628x61105871t5fb0cdbad310ac1c@mail.gmail.com>
Message-ID: <ca3526250905021211h4f9139a4xe1b0e429b465c402@mail.gmail.com>

On Fri, May 1, 2009 at 6:28 PM, Freddie Cash <fjwcash@gmail.com> wrote:

> On Fri, May 1, 2009 at 4:12 PM, Louis Kowolowski
> <louisk@cryptomonkeys.org> wrote:
> > On May 1, 2009, at 1:53 PM, Pete French wrote:
> >> ...
> >> The tuning isn't there to improve performance, it's there to prevent
> >> the box going titus due to a panic when the ARC gets too big, and
> >> you are missing the mian one, which is to limit the size of the ARC.
> >> On recent versions of BSD (and you are running 7.2, so thats fine) then
> >> the defaults for kmem size are fine, but you still need something like
> >> this:
> >>
> >> vfs.zfs.arc_max="256M"
> >>
> >> In there to stop the ARC growing. thats the only tuning I have on
> >> my 4 gig machine, which takes a steady stream of data and is used
> >> for taking backup snapshots. ZFS is excellent, and for me is perfectly
> >> stable, to the point where I am starting to roll it out to production
> >> machines, with the above tuning.
> >>
> > I agree, although I'm using 384 instead of 256.  My systems have been
> > running in production for almost a year now w/o any ZFS issues.
>
> The exact value to use will depend on the system.  Particularly on the
> amount of RAM in the system, and what kmem_max is set to.  A
> "rule-of-thumb" we've been using is:
>   kmem_max should be half of the amount of RAM (or 1.5 GB as that's
> the current max)


This information is outdated.  The current max in RELENG_7 for amd64 is
~3.75GB.

Regards,
Alan
From tmclaugh at sdf.lonestar.org  Sat May  2 20:08:44 2009
From: tmclaugh at sdf.lonestar.org (Tom McLaughlin)
Date: Sat May  2 20:08:51 2009
Subject: 7.2-RC2 Xorg sysinstall bug
Message-ID: <49FCA845.4020305@sdf.lonestar.org>

Hi, I've notice an odd issue in sysinstall with RC2.  When I get to the
distribution set screen I go to "Custom" and select "All" and then I
remove the distribution sets I don't want.  It's just quicker to
unselect a small handful of sets.  However after deselecting Xorg it
still gets installed.  Anyone have any clue what may be up?  It's not an 
issue if for instance I don't select "All" but instead select Xorg and 
then unselect it on the "Custom" screen.  Thanks.

tom

(Please CC me on replies.)
-- 
| tmclaugh at sdf.lonestar.org                 tmclaugh at FreeBSD.org |
| FreeBSD                                       http://www.FreeBSD.org |


From fjwcash at gmail.com  Sat May  2 21:37:50 2009
From: fjwcash at gmail.com (Freddie Cash)
Date: Sat May  2 21:37:57 2009
Subject: current zfs tuning in RELENG_7 (AMD64) suggestions ?
In-Reply-To: <ca3526250905021211h4f9139a4xe1b0e429b465c402@mail.gmail.com>
References: <E1LzzjJ-0002eV-5A@dilbert.ticketswitch.com>
	<32A0BDD9-ACF8-43F4-8D2C-0FC151F1D7CB@cryptomonkeys.org>
	<b269bc570905011628x61105871t5fb0cdbad310ac1c@mail.gmail.com>
	<ca3526250905021211h4f9139a4xe1b0e429b465c402@mail.gmail.com>
Message-ID: <b269bc570905021437h673f97f8l479bd9b20cb2c0cc@mail.gmail.com>

On Sat, May 2, 2009 at 12:11 PM, Alan Cox <alan.l.cox@gmail.com> wrote:
> On Fri, May 1, 2009 at 6:28 PM, Freddie Cash <fjwcash@gmail.com> wrote:
>> On Fri, May 1, 2009 at 4:12 PM, Louis Kowolowski
>> <louisk@cryptomonkeys.org> wrote:
>> > On May 1, 2009, at 1:53 PM, Pete French wrote:
>> >> ...
>> >> The tuning isn't there to improve performance, it's there to prevent
>> >> the box going titus due to a panic when the ARC gets too big, and
>> >> you are missing the mian one, which is to limit the size of the ARC.
>> >> On recent versions of BSD (and you are running 7.2, so thats fine) then
>> >> the defaults for kmem size are fine, but you still need something like
>> >> this:
>> >>
>> >> vfs.zfs.arc_max="256M"
>> >>
>> >> In there to stop the ARC growing. thats the only tuning I have on
>> >> my 4 gig machine, which takes a steady stream of data and is used
>> >> for taking backup snapshots. ZFS is excellent, and for me is perfectly
>> >> stable, to the point where I am starting to roll it out to production
>> >> machines, with the above tuning.
>> >>
>> > I agree, although I'm using 384 instead of 256. ?My systems have been
>> > running in production for almost a year now w/o any ZFS issues.
>>
>> The exact value to use will depend on the system. ?Particularly on the
>> amount of RAM in the system, and what kmem_max is set to. ?A
>> "rule-of-thumb" we've been using is:
>> ? kmem_max should be half of the amount of RAM (or 1.5 GB as that's
>> the current max)
>
> This information is outdated.? The current max in RELENG_7 for amd64 is
> ~3.75GB.

Nice!  Good to hear.  Thanks for the correction.  Looking forward to
testing this with 7.2.

-- 
Freddie Cash
fjwcash@gmail.com
From fbsdlist at src.cx  Sun May  3 00:03:10 2009
From: fbsdlist at src.cx (Artem Belevich)
Date: Sun May  3 00:03:17 2009
Subject: current zfs tuning in RELENG_7 (AMD64) suggestions ?
In-Reply-To: <b269bc570905021437h673f97f8l479bd9b20cb2c0cc@mail.gmail.com>
References: <E1LzzjJ-0002eV-5A@dilbert.ticketswitch.com>
	<32A0BDD9-ACF8-43F4-8D2C-0FC151F1D7CB@cryptomonkeys.org>
	<b269bc570905011628x61105871t5fb0cdbad310ac1c@mail.gmail.com>
	<ca3526250905021211h4f9139a4xe1b0e429b465c402@mail.gmail.com>
	<b269bc570905021437h673f97f8l479bd9b20cb2c0cc@mail.gmail.com>
Message-ID: <ed91d4a80905021634k46f51785v7ae69193b240d653@mail.gmail.com>

>> This information is outdated.? The current max in RELENG_7 for amd64 is
>> ~3.75GB.

Technically, RELENG_7 should allow kmem_size of up to 6G, but the
sysctl variables used for tuning are 32-bit and *that* limits
kmem_size to ~4G.
It's been fixed in -current and can easily be fixed in RELENG_7 (if
it's not fixedyet).

As far as I can tell, all necessary code to support large kmem_size is
already in RELENG_7. It's easy enough to allow even larger kmem_size.
See attached diff that I'm using. With that diff you can set
vm.kmem_size to ~16G.

--Artem
-------------- next part --------------
A non-text attachment was scrubbed...
Name: vm-large.diff
Type: application/octet-stream
Size: 3208 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20090503/644d69c4/vm-large.obj
From i.am.spaz.man at gmail.com  Sun May  3 02:05:01 2009
From: i.am.spaz.man at gmail.com (Jacob Myers)
Date: Sun May  3 02:05:11 2009
Subject: [7-STABLE] failure during buildworld
In-Reply-To: <1234522194.13304.34.camel@horst-tla>
References: <1234522194.13304.34.camel@horst-tla>
Message-ID: <49FCF638.8070604@gmail.com>

Horst G?nther Burkhardt III wrote:
> Hey everybody :) 
> 
> I'm having a small issue compiling 7-STABLE... during make buildworld, this error
> occurs: 
> 
> ===> gnu/lib/libstdc++ (depend)
> ln -sf /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/config/cpu/generic/atomicity_mutex/atomicity.h atomicity.cc
> ln -sf /usr/src/gnu/lib/libstdc++/../../../contrib/gcc/unwind-generic.h unwind.h
> rm -f .depend
> mkdep -f .depend -a    -DIN_GLIBCPP_V3 -DHAVE_CONFIG_H -I/usr/src/gnu/lib/libstdc++ -I/usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc++ -I/usr/src/gnu/lib/libstdc++/../../../contrib/gcc -I/usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/include -I/usr/src/gnu/lib/libstdc++/../../../contrib/gcclibs/include -I/usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/include -I. /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libmath/stubs.c /usr/src/gnu/lib/libstdc++/../../../contrib/gcclibs/libiberty/cp-demangle.c
> mkdep -f .depend -a      /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/src/bitmap_allocator.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/src/pool_allocator.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/src/mt_allocator.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/src/codecvt.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/src/compatibility.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/src/complex_io.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/src/ctype.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/src/debug.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/src/debug_list.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/src/functexcept.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/src/globals_io.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/src/ios.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/src/ios_failure.cc /usr/src/gnu/lib/libstdc++/../
../../contrib/libstdc++/src/ios_init.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/src/ios_locale.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/src/limits.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/src/list.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/src/locale.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/src/locale_init.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/src/locale_facets.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/src/localename.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/src/stdexcept.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/src/strstream.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/src/tree.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/src/allocator-inst.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/src/concept-inst.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/src/fstream-inst.cc /usr/src/gnu/lib/libstdc
++/../../../contrib/libstdc++/src/ext-inst.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/src/ios-inst.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/src/iostream-inst.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/src/istream-inst.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/src/istream.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/src/locale-inst.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/src/misc-inst.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/src/ostream-inst.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/src/sstream-inst.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/src/streambuf-inst.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/src/streambuf.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/src/string-inst.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/src/valarray-inst.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/src/wlocale-ins
t.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/src/wstring-inst.cc atomicity.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/config/locale/generic/codecvt_members.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/config/locale/generic/collate_members.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/config/locale/darwin/ctype_members.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/config/locale/generic/messages_members.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/config/locale/generic/monetary_members.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/config/locale/generic/numeric_members.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/config/locale/generic/time_members.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/config/io/basic_file_stdio.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/config/locale/generic/c_locale.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc++/d
el_op.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc++/del_opnt.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc++/del_opv.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc++/del_opvnt.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc++/eh_alloc.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc++/eh_arm.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc++/eh_aux_runtime.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc++/eh_call.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc++/eh_catch.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc++/eh_exception.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc++/eh_globals.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc++/eh_personality.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc++/eh_term_handler.cc /usr/src/gnu/lib/libstdc++/../../../contrib/lib
stdc++/libsupc++/eh_terminate.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc++/eh_throw.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc++/eh_type.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc++/eh_unex_handler.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc++/guard.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc++/new_handler.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc++/new_op.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc++/new_opnt.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc++/new_opv.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc++/new_opvnt.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc++/pure.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc++/tinfo.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc++/tinfo2.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstd
c++/libsupc++/vec.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc++/vterminate.cc   
> In file included from /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc++/eh_alloc.cc:41:
> /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc++/unwind-cxx.h:41:20: error: unwind.h: No such file or directory
> In file included from /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc++/eh_arm.cc:31:
> /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc++/unwind-cxx.h:41:20: error: unwind.h: No such file or directory
> In file included from /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc++/eh_aux_runtime.cc:34:
> /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc++/unwind-cxx.h:41:20: error: unwind.h: No such file or directory
> In file included from /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc++/eh_call.cc:33:
> /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc++/unwind-cxx.h:41:20: error: unwind.h: No such file or directory
> /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc++/eh_call.cc:37:23: error: unwind-pe.h: No such file or directory
> In file included from /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc++/eh_catch.cc:31:
> /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc++/unwind-cxx.h:41:20: error: unwind.h: No such file or directory
> In file included from /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc++/eh_exception.cc:34:
> /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc++/unwind-cxx.h:41:20: error: unwind.h: No such file or directory
> In file included from /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc++/eh_globals.cc:35:
> /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc++/unwind-cxx.h:41:20: error: unwind.h: No such file or directory
> In file included from /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc++/eh_personality.cc:33:
> /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc++/unwind-cxx.h:41:20: error: unwind.h: No such file or directory
> /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc++/eh_personality.cc:41:23: error: unwind-pe.h: No such file or directory
> In file included from /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc++/eh_term_handler.cc:31:
> /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc++/unwind-cxx.h:41:20: error: unwind.h: No such file or directory
> In file included from /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc++/eh_terminate.cc:34:
> /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc++/unwind-cxx.h:41:20: error: unwind.h: No such file or directory
> In file included from /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc++/eh_throw.cc:31:
> /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc++/unwind-cxx.h:41:20: error: unwind.h: No such file or directory
> In file included from /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc++/eh_type.cc:33:
> /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc++/unwind-cxx.h:41:20: error: unwind.h: No such file or directory
> In file included from /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc++/eh_unex_handler.cc:30:
> /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc++/unwind-cxx.h:41:20: error: unwind.h: No such file or directory
> In file included from /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc++/pure.cc:32:
> /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc++/unwind-cxx.h:41:20: error: unwind.h: No such file or directory
> In file included from /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc++/vec.cc:37:
> /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc++/unwind-cxx.h:41:20: error: unwind.h: No such file or directory
> mkdep: compile failed
> *** Error code 1
> 
> Stop in /usr/src/gnu/lib/libstdc++.
> *** Error code 1
> 
> Stop in /usr/src/gnu/lib.
> *** Error code 1
> 
> Stop in /usr/src.
> *** Error code 1
> 
> Stop in /usr/src.
> *** Error code 1
> 
> Stop in /usr/src.
> *** Error code 1
> 
> Stop in /usr/src.
> You have new mail in /var/mail/root
> [ bsdbox ] [ root ] [ /usr/src ] ==> 
> 
> 
> Is anyone else experiencing this issue? If not, what's going on? This puzzles me.
> 
> Any help would be much appreciated.
> 
> Thanks kindly,
> -- Horst.

Hi,

It looks like your source tree is missing a lot of files. Try checking
it out again. If that fails, well, then we have a problem :p.

-- Jacob
From exemys at exemys.com  Sun May  3 18:40:40 2009
From: exemys at exemys.com (Exemys)
Date: Sun May  3 18:40:56 2009
Subject: Ethernet - Internet I/O
Message-ID: <b54c5d1aea978b35efa7272f714be847@www.hostmailing.com>

This is a message in multipart MIME format.  Your mail client should not be displaying this. Consider upgrading your mail client to view this message correctly.

From hrs at FreeBSD.org  Sun May  3 19:53:06 2009
From: hrs at FreeBSD.org (Hiroki Sato)
Date: Sun May  3 19:53:13 2009
Subject: possible loader regression on RELENG_7_2_0_RELEASE
Message-ID: <20090504.045204.59786498.hrs@allbsd.org>

During upgrading boxes in allbsd.org to RELENG_7_2_0_RELEASE I found
one of them could not boot at the loader stage.  The error messages
issued by the loader after "make installkernel + make installworld +
reboot" were the following:

|Loading /boot/defaults/loader.conf
|/boot/kernel/kernel text=0x7cbd7c data=0xcece0+0x67940
|readin failed
|
|elf32_loadimage: read failed
|/boot/kernel/kernel text=0x7cbd7c data=0xcece0+0x67940
|readin failed
|
|elf32_loadimage: read failed
|Unable to load a kernel!

The normal loader prompt was displayed after that and I can enter
commands, but neither the kernel nor some old kernels which I
confirmed they worked fine got loaded.

Then I tried a livefs CDROM, but the same error occurred at the loader
stage.  So I tried 7.1R CDROM instead, mounted the root file system on
the hard drive, and copied a loader binary from 7.1R.  It worked with
no problem with the RELENG_7_2_0_RELEASE kernel.

The motherboard was Supermicro P4DPE (Xeon 2.4GHz x 2, 3GB RAM).  The
installed version was FreeBSD/i386.

I did not narrow down the cause yet due to the time was limited, but
it was reproducible and probably hardware-dependent.  Replacing the
loader binary with the old one worked as a workaround, so I guess
there may be a regression around the boot loader.  Just a report.

--
| Hiroki SATO
-------------- 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-stable/attachments/20090503/9743924b/attachment.pgp
From lists at reiteration.net  Mon May  4 08:27:02 2009
From: lists at reiteration.net (John)
Date: Mon May  4 08:27:09 2009
Subject: cvsup.uk.freebsd.org appears to not be serving
Message-ID: <49FEA6D1.2080503@reiteration.net>

Hi list, hopefully this is the right one and not -questions

cvsup.uk.freebsd.org appears to have not been serving these last few
weeks. I get, variously, in my logs:

Parsing supfile "/etc/cvsupfile"
Connecting to cvsup.uk.freebsd.org
Connected to cvsup.uk.freebsd.org
Rejected by server: Access limit exceeded; try again later
Will retry at 03:08:08
Retrying
Connecting to cvsup.uk.freebsd.org
Connected to cvsup.uk.freebsd.org
Server software version: SNAP_16_1h
Negotiating file attribute support
Exchanging collection information
Establishing passive-mode data connection
Cannot connect to data port: Connection refused
Will retry at 03:18:04
Retrying
Connecting to cvsup.uk.freebsd.org
Connected to cvsup.uk.freebsd.org
Server software version: SNAP_16_1h
Negotiating file attribute support
Exchanging collection information
Establishing passive-mode data connection
Cannot connect to data port: Connection refused
Will retry at 03:37:33
Retrying

... on and on and on, continuously, 24/7.

Because the update is called in a daily script by cron, potentially I
get many instances of cvsup each time cron calls it and this happens -
additionally the mailed output never arrives until the script
successfully completes. So the first I knew of this was when I wasn't
getting my mails for the daily run, but anyway...

I'm now using cvsup4.uk.freebsd.org, which seems to work fine. Should
cvsup.uk.freebsd.org be taken out of the list of cvsup servers?

cheers
-- 
John
From john.marshall at riverwillow.com.au  Mon May  4 09:16:37 2009
From: john.marshall at riverwillow.com.au (John Marshall)
Date: Mon May  4 09:16:47 2009
Subject: cvsup.uk.freebsd.org appears to not be serving
In-Reply-To: <49FEA6D1.2080503@reiteration.net>
References: <49FEA6D1.2080503@reiteration.net>
Message-ID: <20090504090029.GF1006@rwpc12.mby.riverwillow.net.au>

On Mon, 04 May 2009, 09:26 +0100, John wrote:
> Hi list, hopefully this is the right one and not -questions

Perhaps -hubs would have been a better choice?

> cvsup.uk.freebsd.org appears to have not been serving these last few
> weeks. I get, variously, in my logs:
> 
> Parsing supfile "/etc/cvsupfile"
> Connecting to cvsup.uk.freebsd.org
> Connected to cvsup.uk.freebsd.org
> Rejected by server: Access limit exceeded; try again later
> Will retry at 03:08:08
> Retrying

You are obviously connecting OK; it's just that the server is already as
busy as it's minder is willing to let it be.  Perhaps you'd be better
off choosing something other than 03:00 as a starting point?

> Connecting to cvsup.uk.freebsd.org
> Connected to cvsup.uk.freebsd.org
> Server software version: SNAP_16_1h
> Negotiating file attribute support
> Exchanging collection information
> Establishing passive-mode data connection
> Cannot connect to data port: Connection refused
> Will retry at 03:18:04
> Retrying

Don't do that!  Use multiplexed mode "-P m" (from the cvsup man page,
"All but multiplexed mode are deprecated"); or use csup which does
multiplexed mode by default.

On Saturday morning I updated two servers in London from from RELENG_7_1
to RELENG_7_2 using cvsup.uk.  I checked again just now and it's still
happy.

  --------------------------------------------------------------
  >>> Running /usr/bin/csup
  --------------------------------------------------------------
  Parsing supfile "/usr/local/etc/cvsup/src-supfile"
  Connecting to cvsup.uk.FreeBSD.org
  Connected to 131.111.8.41
  Server software version: SNAP_16_1h
  Negotiating file attribute support
  Exchanging collection information
  Establishing multiplexed-mode data connection
  Running
  Updating collection src-all/cvs
  Shutting down connection to server
  Finished successfully

-- 
John Marshall
-------------- 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-stable/attachments/20090504/e56aaa79/attachment.pgp
From yaol.leo at gmail.com  Mon May  4 10:17:28 2009
From: yaol.leo at gmail.com (Leo)
Date: Mon May  4 10:17:35 2009
Subject: Help! regarding libpcap.
Message-ID: <49FEC0AD.7090506@gmail.com>

Hi Burce,
At first, I'm sorry replay late. I've test build libpcap without ports 
and using same tar ball. The error message still output.

SLT2# make
gcc -O2 -I. -DHAVE_CONFIG_H  -D_U_="__attribute__((unused))" -c 
./pcap-null.c
./pcap-null.c:43: error: conflicting types for 'pcap_activate'
./pcap/pcap.h:266: note: previous declaration of 'pcap_activate' was here
*** Error code 1

Stop in /usr/ports/distfiles/libpcap-1.0.0.
SLT2#
Thank you!
-Leo
From doconnor at gsoft.com.au  Mon May  4 10:50:42 2009
From: doconnor at gsoft.com.au (Daniel O'Connor)
Date: Mon May  4 10:50:50 2009
Subject: bluetooth troubleshooting
In-Reply-To: <49FC3BB9.6000200@bsdforen.de>
References: <49FBF3C2.8010809@bsdforen.de>
	<20090502114958.76c46f25@gluon.draftnet>
	<49FC3BB9.6000200@bsdforen.de>
Message-ID: <200905042020.24783.doconnor@gsoft.com.au>

On Sat, 2 May 2009, Dominic Fandrey wrote:
> # hccontrol -n ubt0hci inquiry
> Inquiry complete. Status: No error [00]
>
> is pretty lame compared to what should appear according to the
> handbook:
>
> % hccontrol -n ubt0hci inquiry
> Inquiry result, num_responses=1
> Inquiry result #0
>        BD_ADDR: 00:80:37:29:19:a4
>        Page Scan Rep. Mode: 0x1
>        Page Scan Period Mode: 00
>        Page Scan Mode: 00
>        Class: 52:02:04
>        Clock offset: 0x78ef
> Inquiry complete. Status: No error [00]

Depends what's in range.

Your command indicates to me that there are no _discoverable_ BT modules 
in range. (Note the discoverable part :)

BTW the '-n ubt0hci' is optional if you only have one BT controller.

If it isn't discoverable you can do something like..
sdpcontrol -a pda browse

(I entered pda into /etc/bluetooth/hosts).

If it doesn't show anything (like my phone) you need to bruteforce 
search for services (I don't understand the rationale of that but 
that's the way it is), eg..
sh -c 'for i in \
	CIP CTP DUN FAX FTRN GN HID HSET LAN NAP OPUSH SP; do \
	sdpcontrol -a pda  search $i; done'

There's a command in Bluez which does this for you but the above would 
tell you a reasonable amount.

-- 
Daniel O'Connor software and network engineer
for Genesis Software - http://www.gsoft.com.au
"The nice thing about standards is that there
are so many of them to choose from."
  -- Andrew Tanenbaum
GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 188 bytes
Desc: This is a digitally signed message part.
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20090504/3c4a11ed/attachment.pgp
From matthias.schuendehuette at siemens.com  Mon May  4 12:37:06 2009
From: matthias.schuendehuette at siemens.com (Schuendehuette, Matthias)
Date: Mon May  4 12:37:14 2009
Subject: FreeBSD supported branches update
In-Reply-To: <49FBAE78.7090608@freebsd.org>
References: <49FBAE78.7090608@freebsd.org>
Message-ID: <EED79C54778088448F9639A9C136DD9C5BAFE99567@DEERLF0CX4.ww004.siemens.net>

Hello,

owner-freebsd-security-notifications@freebsd.org wrote on :
> The branches supported by the FreeBSD Security Officer have
> been updated
> to reflect the EoL (end-of-life) of FreeBSD 7.0.  The new
> list is below
> and at <URL: http://security.freebsd.org/ >.  Please note that FreeBSD
> 7.0 was originally announced with an EoL date of February 28, 2009,
> but the EoL was delayed by two months in order to allow a 3 month
> window for systems to be upgraded to FreeBSD 7.1.

I have severe problems with this, because NFS-Locking is not working
on FreeBSD-7.1 and later with HP-UX clients. See several PRs which are
talking about this. Same is true f?r FreeBSD-6.4. So all Releases
with kernel-supported NFS-Locking have problems with HP-UX clients.

FreeBSD-7.0 is the last release that is working and that is therefor
still productive at our site.

What do you recommend?



with best regards

Matthias Sch?ndeh?tte
SIEMENS AG, Industry Sector, DT LD S IT
Tel. +49-30-386 29957

-- 
Plain text mail please
HTML is considered as SPAM
From kensmith at cse.Buffalo.EDU  Mon May  4 13:32:56 2009
From: kensmith at cse.Buffalo.EDU (Ken Smith)
Date: Mon May  4 13:33:05 2009
Subject: FreeBSD 7.2-RELEASE Available
Message-ID: <1241443972.1158.5.camel@bauer.cse.buffalo.edu>


Just a quick note for those of you not subscribed to freebsd-announce@.
We finished up 7.2-RELEASE over the weekend.  The announcement message
is available here:

  http://www.freebsd.org/releases/7.2R/announce.html

Thanks for all the help with testing during the release cycle.

-- 
                                                Ken Smith
- From there to here, from here to      |       kensmith@cse.buffalo.edu
  there, funny things are everywhere.   |
                      - Theodore Geisel |

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 195 bytes
Desc: This is a digitally signed message part
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20090504/b2dc1148/attachment.pgp
From bms at incunabulum.net  Mon May  4 14:53:07 2009
From: bms at incunabulum.net (Bruce Simpson)
Date: Mon May  4 14:53:14 2009
Subject: Help! regarding libpcap.
In-Reply-To: <49FEC0AD.7090506@gmail.com>
References: <49FEC0AD.7090506@gmail.com>
Message-ID: <49FF014F.7070107@incunabulum.net>

Leo wrote:
> Hi Burce,
> At first, I'm sorry replay late. I've test build libpcap without ports 
> and using same tar ball. The error message still output.
>
> SLT2# make
> gcc -O2 -I. -DHAVE_CONFIG_H  -D_U_="__attribute__((unused))" -c 
> ./pcap-null.c
> ./pcap-null.c:43: error: conflicting types for 'pcap_activate'
> ./pcap/pcap.h:266: note: previous declaration of 'pcap_activate' was here
> *** Error code 1

Hi,

I can't think what might be causing this for you... Do you have other 
pcap libraries installed on the system? Perhaps a define is incorrect.

Are you trying this on a 7.2 or a HEAD system? I believe 7.2, so that 
should rule out changes in HEAD.

Do you have BPF headers present on the system? Have you checked the 
output of config.log? Do you have a bpf device in your kernel?
 -- I think that might be it. The fix might be to specify 
--with-pcap=bpf in CONFIGURE_ARGS in the port.

I just built the port on an i386 system tracking RELENG_7 sources, and 
couldn't reproduce this problem, although I have bpf in kernel there.

thanks,
BMS
From bms at incunabulum.net  Mon May  4 14:55:23 2009
From: bms at incunabulum.net (Bruce Simpson)
Date: Mon May  4 14:55:30 2009
Subject: bluetooth troubleshooting
In-Reply-To: <200905042020.24783.doconnor@gsoft.com.au>
References: <49FBF3C2.8010809@bsdforen.de>	<20090502114958.76c46f25@gluon.draftnet>	<49FC3BB9.6000200@bsdforen.de>
	<200905042020.24783.doconnor@gsoft.com.au>
Message-ID: <49FF01D6.5020607@incunabulum.net>

Daniel O'Connor wrote:
> On Sat, 2 May 2009, Dominic Fandrey wrote:
>   
>> # hccontrol -n ubt0hci inquiry
>> Inquiry complete. Status: No error [00]
>>
>> is pretty lame compared to what should appear according to the
>> handbook:
>>
>> % hccontrol -n ubt0hci inquiry
>> Inquiry result, num_responses=1
>> Inquiry result #0
>>        BD_ADDR: 00:80:37:29:19:a4
>>        Page Scan Rep. Mode: 0x1
>>        Page Scan Period Mode: 00
>>        Page Scan Mode: 00
>>        Class: 52:02:04
>>        Clock offset: 0x78ef
>> Inquiry complete. Status: No error [00]
>>     
>
> Depends what's in range.
>
> Your command indicates to me that there are no _discoverable_ BT modules 
> in range. (Note the discoverable part :)
>
>   

Not all devices need be INQUIRE-able. Some may not have INQUIRE scan 
enabled. In that case you need to know the Bluetooth address of the 
device you're looking for so you can PAGE it.
If you're expecting to see a mobile phone or other handheld device you 
might need to enable discoverability on the device itself. There are 
also other IAC codes used for INQUIRY, but generally these aren't used.

cheers,
BMS



From yaol.leo at gmail.com  Mon May  4 15:29:53 2009
From: yaol.leo at gmail.com (Leo)
Date: Mon May  4 15:30:00 2009
Subject: Help! regarding libpcap.
In-Reply-To: <49FF014F.7070107@incunabulum.net>
References: <49FEC0AD.7090506@gmail.com> <49FF014F.7070107@incunabulum.net>
Message-ID: <49FF09E1.5010306@gmail.com>

Bruce Simpson wrote:
> Leo wrote:
>> Hi Burce,
>> At first, I'm sorry replay late. I've test build libpcap without 
>> ports and using same tar ball. The error message still output.
>>
>> SLT2# make
>> gcc -O2 -I. -DHAVE_CONFIG_H  -D_U_="__attribute__((unused))" -c 
>> ./pcap-null.c
>> ./pcap-null.c:43: error: conflicting types for 'pcap_activate'
>> ./pcap/pcap.h:266: note: previous declaration of 'pcap_activate' was 
>> here
>> *** Error code 1
>
> Hi,
>
> I can't think what might be causing this for you... Do you have other 
> pcap libraries installed on the system? Perhaps a define is incorrect.
>
> Are you trying this on a 7.2 or a HEAD system? I believe 7.2, so that 
> should rule out changes in HEAD.
>
> Do you have BPF headers present on the system? Have you checked the 
> output of config.log? Do you have a bpf device in your kernel?
> -- I think that might be it. The fix might be to specify 
> --with-pcap=bpf in CONFIGURE_ARGS in the port.
>
> I just built the port on an i386 system tracking RELENG_7 sources, and 
> couldn't reproduce this problem, although I have bpf in kernel there.
>
> thanks,
> BMS
>
Hi Bruce,

I don't have other pcap lib installed on this box. Previously installed 
a libpcap 0.9 on this box , But I've deleted this version. On my box, 
not enable BPF. Let me try if enable the feature.

-Leo
From bms at incunabulum.net  Mon May  4 16:07:01 2009
From: bms at incunabulum.net (Bruce Simpson)
Date: Mon May  4 16:07:08 2009
Subject: Help! regarding libpcap.
In-Reply-To: <49FF09E1.5010306@gmail.com>
References: <49FEC0AD.7090506@gmail.com> <49FF014F.7070107@incunabulum.net>
	<49FF09E1.5010306@gmail.com>
Message-ID: <49FF12A0.3010009@incunabulum.net>

Leo wrote:
>
> I don't have other pcap lib installed on this box. Previously 
> installed a libpcap 0.9 on this box , But I've deleted this version. 
> On my box, not enable BPF. Let me try if enable the feature.

That's probably what it is. Can you try the following:
 * give pcap configure --with-pcap=bpf WITHOUT having bpf in your kernel 
config.
 * try enabling bpf in kernel config and building the port as usual.

Most likely libpcap's new configure script is detecting the lack of 
/dev/bpf* and assuming there is no packet capture support in the system. 
This needs to be fixed for cross compiling to be possible. If you could 
try at least the first fix then this is the answer.

thanks,
BMS

From korvus at comcast.net  Mon May  4 17:56:50 2009
From: korvus at comcast.net (Steve Polyack)
Date: Mon May  4 17:56:56 2009
Subject: Radeon 9250 DRM in 7.2-RELEASE
Message-ID: <49FF28BC.5080304@comcast.net>

I upgraded my workstation (via source) to 7.2-RELEASE from 7.1-RELEASE 
about a day ago.  After the upgrade procedure, I'm having no luck with 
using DRM in X11.  It worked fine before and gave reasonable 
performance.  Now when I start up X with DRI enabled, both of my screens 
display garbage.  The mouse pointer is also not visible.

I'm using a PCI Radeon 9250.  I can get more details if necessary.  I 
can also try to revert the kernel DRM module code to 7.1.

 From dmesg:
drm2: <ATI Radeon RV280 9250> on vgapci2
vgapci2: child drm2 requested pci_enable_busmaster
info: [drm] Initialized radeon 1.29.0 20080528
info: [drm] Setting GART location based on new memory map
info: [drm] Loading R200 Microcode
info: [drm] writeback test succeeded in 2 usecs
drm2: [ITHREAD]

Any ideas or suggestions would be appreciated.  Thanks.

From rnoland at FreeBSD.org  Mon May  4 18:13:58 2009
From: rnoland at FreeBSD.org (Robert Noland)
Date: Mon May  4 18:14:09 2009
Subject: Radeon 9250 DRM in 7.2-RELEASE
In-Reply-To: <49FF28BC.5080304@comcast.net>
References: <49FF28BC.5080304@comcast.net>
Message-ID: <1241460816.1788.22.camel@balrog.2hip.net>

On Mon, 2009-05-04 at 13:41 -0400, Steve Polyack wrote:
> I upgraded my workstation (via source) to 7.2-RELEASE from 7.1-RELEASE 
> about a day ago.  After the upgrade procedure, I'm having no luck with 
> using DRM in X11.  It worked fine before and gave reasonable 
> performance.  Now when I start up X with DRI enabled, both of my screens 
> display garbage.  The mouse pointer is also not visible.
> 
> I'm using a PCI Radeon 9250.  I can get more details if necessary.  I 
> can also try to revert the kernel DRM module code to 7.1.
> 
>  From dmesg:
> drm2: <ATI Radeon RV280 9250> on vgapci2

Why is this drm2?  Is this a multicard setup?  Multicard doesn't work
right now.  If you aren't using more than one card, can you disable
whatever else drm is attaching to?

robert.

> vgapci2: child drm2 requested pci_enable_busmaster
> info: [drm] Initialized radeon 1.29.0 20080528
> info: [drm] Setting GART location based on new memory map
> info: [drm] Loading R200 Microcode
> info: [drm] writeback test succeeded in 2 usecs
> drm2: [ITHREAD]
> 
> Any ideas or suggestions would be appreciated.  Thanks.
> 
> _______________________________________________
> freebsd-x11@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-x11
> To unsubscribe, send any mail to "freebsd-x11-unsubscribe@freebsd.org"
-- 
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-stable/attachments/20090504/0fdde433/attachment.pgp
From korvus at comcast.net  Mon May  4 18:43:19 2009
From: korvus at comcast.net (Steve Polyack)
Date: Mon May  4 18:43:31 2009
Subject: Radeon 9250 DRM in 7.2-RELEASE
In-Reply-To: <57B64585162157F0FE51E05F@utd65257.utdallas.edu>
References: <49FF28BC.5080304@comcast.net>
	<57B64585162157F0FE51E05F@utd65257.utdallas.edu>
Message-ID: <49FF3744.1000908@comcast.net>

Paul Schmehl wrote:
>
> Read /usr/portsUPDATING wrt xorg.  There were major changes in the 
> config file and peripheral detection between 7.1 and 7.2
>
> You need to make sure that both dbus and hald are running.  Remove the 
> mouse and keyboard sections from your xorg.conf file.  They are no 
> longer needed. Make sure to remove any line that references RgbPath.
>
> This may help to get the mouse working (ignore the DontZap line):
>
> Section "ServerFlags"
>        Option "DontZap" "No"
>        Option "AllowEmptyInput" "No"
> EndSection
>
> This should get DRI working:
>
> Section "DRI"
>        Group 0
>        Mode  0660
> EndSection
>
I tackled the above when I upgraded Xorg to 7.4 months ago, 
independently of any FreeBSD release updates.

From pauls at utdallas.edu  Mon May  4 18:45:48 2009
From: pauls at utdallas.edu (Paul Schmehl)
Date: Mon May  4 18:46:03 2009
Subject: Radeon 9250 DRM in 7.2-RELEASE
In-Reply-To: <49FF28BC.5080304@comcast.net>
References: <49FF28BC.5080304@comcast.net>
Message-ID: <57B64585162157F0FE51E05F@utd65257.utdallas.edu>

--On Monday, May 04, 2009 12:41:16 -0500 Steve Polyack <korvus@comcast.net> 
wrote:

>
> I upgraded my workstation (via source) to 7.2-RELEASE from 7.1-RELEASE
> about a day ago.  After the upgrade procedure, I'm having no luck with
> using DRM in X11.  It worked fine before and gave reasonable
> performance.  Now when I start up X with DRI enabled, both of my screens
> display garbage.  The mouse pointer is also not visible.
>
> I'm using a PCI Radeon 9250.  I can get more details if necessary.  I
> can also try to revert the kernel DRM module code to 7.1.
>
>  From dmesg:
> drm2: <ATI Radeon RV280 9250> on vgapci2
> vgapci2: child drm2 requested pci_enable_busmaster
> info: [drm] Initialized radeon 1.29.0 20080528
> info: [drm] Setting GART location based on new memory map
> info: [drm] Loading R200 Microcode
> info: [drm] writeback test succeeded in 2 usecs
> drm2: [ITHREAD]
>
> Any ideas or suggestions would be appreciated.  Thanks.
>

Read /usr/portsUPDATING wrt xorg.  There were major changes in the config file 
and peripheral detection between 7.1 and 7.2

You need to make sure that both dbus and hald are running.  Remove the mouse 
and keyboard sections from your xorg.conf file.  They are no longer needed. 
Make sure to remove any line that references RgbPath.

This may help to get the mouse working (ignore the DontZap line):

Section "ServerFlags"
        Option "DontZap" "No"
        Option "AllowEmptyInput" "No"
EndSection

This should get DRI working:

Section "DRI"
        Group 0
        Mode  0660
EndSection

-- 
Paul Schmehl (pauls@utdallas.edu)
Senior Information Security Analyst
The University of Texas at Dallas
http://www.utdallas.edu/ir/security/
From korvus at comcast.net  Mon May  4 18:48:34 2009
From: korvus at comcast.net (Steve Polyack)
Date: Mon May  4 18:48:46 2009
Subject: Radeon 9250 DRM in 7.2-RELEASE
In-Reply-To: <1241460816.1788.22.camel@balrog.2hip.net>
References: <49FF28BC.5080304@comcast.net>
	<1241460816.1788.22.camel@balrog.2hip.net>
Message-ID: <49FF387F.1080203@comcast.net>

Robert Noland wrote:
>
> Why is this drm2?  Is this a multicard setup?  Multicard doesn't work
> right now.  If you aren't using more than one card, can you disable
> whatever else drm is attaching to?
>
> robert.
>
>   

This is something funny I had to deal with initially.  There is *no* 
drm0 or drm1 being probed.  Consequently, there is only one entry in 
/dev/dri/, card2.  As a result, Xorg doesn't even recognize card2 as a 
source for DRM (probably due to what you said).  In the past, I have 
symlinked /dev/dri/card2 to /dev/dri/card0 and Xorg would work 
correctly, utilizing DRM.

I have an onboard Intel VGA device, but as far as I know it is 
disabled.  I can double check, but as I've noted things have worked fine 
with the above tweak until upgrading to 7.2-RELEASE.

Thanks,

From rnoland at FreeBSD.org  Mon May  4 19:07:53 2009
From: rnoland at FreeBSD.org (Robert Noland)
Date: Mon May  4 19:08:01 2009
Subject: Radeon 9250 DRM in 7.2-RELEASE
In-Reply-To: <49FF387F.1080203@comcast.net>
References: <49FF28BC.5080304@comcast.net>
	<1241460816.1788.22.camel@balrog.2hip.net>
	<49FF387F.1080203@comcast.net>
Message-ID: <1241464053.1788.32.camel@balrog.2hip.net>

On Mon, 2009-05-04 at 14:48 -0400, Steve Polyack wrote:
> Robert Noland wrote:
> >
> > Why is this drm2?  Is this a multicard setup?  Multicard doesn't work
> > right now.  If you aren't using more than one card, can you disable
> > whatever else drm is attaching to?
> >
> > robert.
> >
> >   
> 
> This is something funny I had to deal with initially.  There is *no* 
> drm0 or drm1 being probed.  Consequently, there is only one entry in 
> /dev/dri/, card2.  As a result, Xorg doesn't even recognize card2 as a 
> source for DRM (probably due to what you said).  In the past, I have 
> symlinked /dev/dri/card2 to /dev/dri/card0 and Xorg would work 
> correctly, utilizing DRM.
> 
> I have an onboard Intel VGA device, but as far as I know it is 
> disabled.  I can double check, but as I've noted things have worked fine 
> with the above tweak until upgrading to 7.2-RELEASE.

Can you send me a "pciconf -lvb"

robert.

> Thanks,
> 
> _______________________________________________
> freebsd-x11@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-x11
> To unsubscribe, send any mail to "freebsd-x11-unsubscribe@freebsd.org"
-- 
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-stable/attachments/20090504/bed54fd1/attachment.pgp
From jhb at freebsd.org  Mon May  4 19:22:19 2009
From: jhb at freebsd.org (John Baldwin)
Date: Mon May  4 19:22:39 2009
Subject: #0 sched_switch (td=0xc579b230,
	newtd=Variable "newtd" is not  available.
In-Reply-To: <910e60e80905021111v1ef2d386j17db9bccb953b609@mail.gmail.com>
References: <910e60e80905021111v1ef2d386j17db9bccb953b609@mail.gmail.com>
Message-ID: <200905041015.32695.jhb@freebsd.org>

On Saturday 02 May 2009 2:11:59 pm dikshie wrote:
> is this known bug?
> 
> Fatal trap 12: page fault while in kernel mode
> cpuid = 0; apic id = 00
> fault virtual address   = 0x8c000180
> fault code              = supervisor read, page not present
> instruction pointer     = 0x20:0xc063d904
> stack pointer           = 0x28:0xe7704608
> frame pointer           = 0x28:0xe7704620
> 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         = 2013 (firefox-bin)
> trap number             = 12
> panic: page fault
> cpuid = 0
> Uptime: 5h1m34s
> Physical memory: 2038 MB
> Dumping 194 MB: 179 163 147 131 115 99 83 (CTRL-C to abort)  67
> (CTRL-C to abort)  (CTRL-C to abort)  (CTRL-C to abort)  51 (CTRL-C to
> abort)  35 19 3
> 
> kgdb: kvm_read: invalid address (0x4c414e52)
> kgdb: kvm_read: invalid address (0x35b2e804)
> kgdb: kvm_read: invalid address (0x5502)
> kgdb: kvm_read: invalid address (0x6a02)
> Reading symbols from /boot/kernel/geom_journal.ko...Reading symbols
> from /boot/kernel/geom_journal.ko.symbols...done.
> done.
> Loaded symbols for /boot/kernel/geom_journal.ko
> Reading symbols from /boot/kernel/acpi_ibm.ko...Reading symbols from
> /boot/kernel/acpi_ibm.ko.symbols...done.
> done.
> Loaded symbols for /boot/kernel/acpi_ibm.ko
> Reading symbols from /boot/kernel/acpi.ko...Reading symbols from
> /boot/kernel/acpi.ko.symbols...done.
> done.
> Loaded symbols for /boot/kernel/acpi.ko
> Reading symbols from /boot/kernel/linprocfs.ko...Reading symbols from
> /boot/kernel/linprocfs.ko.symbols...done.
> done.
> Loaded symbols for /boot/kernel/linprocfs.ko
> Reading symbols from /boot/kernel/linux.ko...Reading symbols from
> /boot/kernel/linux.ko.symbols...done.
> done.
> Loaded symbols for /boot/kernel/linux.ko
> #0  sched_switch (td=0xc579b230, newtd=Variable "newtd" is not available.
> ) at /usr/src/sys/kern/sched_ule.c:1944
> 1944                    cpuid = PCPU_GET(cpuid);
> (kgdb)

Please get a backtrace using 'bt'.

Also, 'l *0xc063d904' may also be useful.

-- 
John Baldwin
From korvus at comcast.net  Mon May  4 19:56:10 2009
From: korvus at comcast.net (Steve Polyack)
Date: Mon May  4 19:56:22 2009
Subject: Radeon 9250 DRM in 7.2-RELEASE
In-Reply-To: <1241464053.1788.32.camel@balrog.2hip.net>
References: <49FF28BC.5080304@comcast.net>	
	<1241460816.1788.22.camel@balrog.2hip.net>
	<49FF387F.1080203@comcast.net>
	<1241464053.1788.32.camel@balrog.2hip.net>
Message-ID: <49FF4857.4070904@comcast.net>

Robert Noland wrote:
> On Mon, 2009-05-04 at 14:48 -0400, Steve Polyack wrote:
>   
>> This is something funny I had to deal with initially.  There is *no* 
>> drm0 or drm1 being probed.  Consequently, there is only one entry in 
>> /dev/dri/, card2.  As a result, Xorg doesn't even recognize card2 as a 
>> source for DRM (probably due to what you said).  In the past, I have 
>> symlinked /dev/dri/card2 to /dev/dri/card0 and Xorg would work 
>> correctly, utilizing DRM.
>>
>> I have an onboard Intel VGA device, but as far as I know it is 
>> disabled.  I can double check, but as I've noted things have worked fine 
>> with the above tweak until upgrading to 7.2-RELEASE.
>>     
>
> Can you send me a "pciconf -lvb"
>
> robert.
>
>   

$ pciconf -lvb
hostb0@pci0:0:0:0:    class=0x060000 card=0x01ad1028 chip=0x27708086 
rev=0x02 hdr=0x00
    vendor     = 'Intel Corporation'
    device     = '82945G/GZ/P/PL Host Bridge/DRAM Controller'
    class      = bridge
    subclass   = HOST-PCI
pcib1@pci0:0:1:0:    class=0x060400 card=0x00008086 chip=0x27718086 
rev=0x02 hdr=0x01
    vendor     = 'Intel Corporation'
    device     = '82945G/GZ/P/PL Host to PCI Express Bridge'
    class      = bridge
    subclass   = PCI-PCI
vgapci0@pci0:0:2:0:    class=0x038000 card=0x01ad1028 chip=0x27728086 
rev=0x02 hdr=0x00
    vendor     = 'Intel Corporation'
    device     = '82945G Integrated Graphics Controller'
    class      = display
    bar   [10] = type Memory, range 32, base 0xfeb00000, size 524288, 
enabled
    bar   [14] = type I/O Port, range 32, base 0xe898, size  8, enabled
    bar   [18] = type Prefetchable Memory, range 32, base 0xd0000000, 
size 268435456, enabled
    bar   [1c] = type Memory, range 32, base 0xfeac0000, size 262144, 
enabled
vgapci1@pci0:0:2:1:    class=0x038000 card=0x01ad1028 chip=0x27768086 
rev=0x02 hdr=0x00
    vendor     = 'Intel Corporation'
    device     = '82945G Integrated Graphics Controller'
    class      = display
    bar   [10] = type Memory, range 32, base 0xfeb80000, size 524288, 
enabled
pcib2@pci0:0:28:0:    class=0x060400 card=0x00000000 chip=0x27d08086 
rev=0x01 hdr=0x01
    vendor     = 'Intel Corporation'
    device     = '82801G (ICH7 Family) PCIe Root Port'
    class      = bridge
    subclass   = PCI-PCI
pcib3@pci0:0:28:1:    class=0x060400 card=0x00000000 chip=0x27d28086 
rev=0x01 hdr=0x01
    vendor     = 'Intel Corporation'
    device     = '82801G (ICH7 Family) PCIe Root Port'
    class      = bridge
    subclass   = PCI-PCI
uhci0@pci0:0:29:0:    class=0x0c0300 card=0x01ad1028 chip=0x27c88086 
rev=0x01 hdr=0x00
    vendor     = 'Intel Corporation'
    device     = '82801G (ICH7 Family) USB Universal Host Controller'
    class      = serial bus
    subclass   = USB
    bar   [20] = type I/O Port, range 32, base 0xff80, size 32, enabled
uhci1@pci0:0:29:1:    class=0x0c0300 card=0x01ad1028 chip=0x27c98086 
rev=0x01 hdr=0x00
    vendor     = 'Intel Corporation'
    device     = '82801G (ICH7 Family) USB Universal Host Controller'
    class      = serial bus
    subclass   = USB
    bar   [20] = type I/O Port, range 32, base 0xff60, size 32, enabled
uhci2@pci0:0:29:2:    class=0x0c0300 card=0x01ad1028 chip=0x27ca8086 
rev=0x01 hdr=0x00
    vendor     = 'Intel Corporation'
    device     = '82801G (ICH7 Family) USB Universal Host Controller'
    class      = serial bus
    subclass   = USB
    bar   [20] = type I/O Port, range 32, base 0xff40, size 32, enabled
uhci3@pci0:0:29:3:    class=0x0c0300 card=0x01ad1028 chip=0x27cb8086 
rev=0x01 hdr=0x00
    vendor     = 'Intel Corporation'
    device     = '82801G (ICH7 Family) USB Universal Host Controller'
    class      = serial bus
    subclass   = USB
    bar   [20] = type I/O Port, range 32, base 0xff20, size 32, enabled
ehci0@pci0:0:29:7:    class=0x0c0320 card=0x01ad1028 chip=0x27cc8086 
rev=0x01 hdr=0x00
    vendor     = 'Intel Corporation'
    device     = '82801G (ICH7 Family) USB 2.0 Enhanced Host Controller'
    class      = serial bus
    subclass   = USB
    bar   [10] = type Memory, range 32, base 0xffa80800, size 1024, enabled
pcib4@pci0:0:30:0:    class=0x060401 card=0x00000000 chip=0x244e8086 
rev=0xe1 hdr=0x01
    vendor     = 'Intel Corporation'
    device     = '82801 Family (ICH2/3/4/4/5/5/6/7/8/9,63xxESB) Hub 
Interface to PCI Bridge'
    class      = bridge
    subclass   = PCI-PCI
pcm0@pci0:0:30:2:    class=0x040100 card=0x01ad1028 chip=0x27de8086 
rev=0x01 hdr=0x00
    vendor     = 'Intel Corporation'
    device     = '82801GB I/O Controller Hub AC'97 Audio'
    class      = multimedia
    subclass   = audio
    bar   [10] = type I/O Port, range 32, base 0xec00, size 256, enabled
    bar   [14] = type I/O Port, range 32, base 0xe8c0, size 64, enabled
    bar   [18] = type Memory, range 32, base 0xfeabfa00, size 512, enabled
    bar   [1c] = type Memory, range 32, base 0xfeabf900, size 256, enabled
isab0@pci0:0:31:0:    class=0x060100 card=0x00000000 chip=0x27b88086 
rev=0x01 hdr=0x00
    vendor     = 'Intel Corporation'
    device     = '945GL Intel 82801GB/GR (ICH7 Family) LPC Interface 
Controller - 27B8'
    class      = bridge
    subclass   = PCI-ISA
atapci0@pci0:0:31:1:    class=0x01018a card=0x01ad1028 chip=0x27df8086 
rev=0x01 hdr=0x00
    vendor     = 'Intel Corporation'
    device     = '82801G (ICH7 Family) Ultra ATA Storage Controller'
    class      = mass storage
    subclass   = ATA
    bar   [10] = type I/O Port, range 32, base 0x1f0, size  8, enabled
    bar   [14] = type I/O Port, range 32, base 0x3f4, size  1, enabled
    bar   [18] = type I/O Port, range 32, base 0x170, size  8, enabled
    bar   [1c] = type I/O Port, range 32, base 0x374, size  1, enabled
    bar   [20] = type I/O Port, range 32, base 0xffa0, size 16, enabled
atapci1@pci0:0:31:2:    class=0x01018f card=0x01ad1028 chip=0x27c08086 
rev=0x01 hdr=0x00
    vendor     = 'Intel Corporation'
    device     = '82801GB/GR/GH (ICH7 Family) Serial ATA Storage Controller'
    class      = mass storage
    subclass   = ATA
    bar   [10] = type I/O Port, range 32, base 0xfe00, size  8, enabled
    bar   [14] = type I/O Port, range 32, base 0xfe10, size  4, enabled
    bar   [18] = type I/O Port, range 32, base 0xfe20, size  8, enabled
    bar   [1c] = type I/O Port, range 32, base 0xfe30, size  4, enabled
    bar   [20] = type I/O Port, range 32, base 0xfea0, size 16, enabled
none0@pci0:0:31:3:    class=0x0c0500 card=0x01ad1028 chip=0x27da8086 
rev=0x01 hdr=0x00
    vendor     = 'Intel Corporation'
    device     = '82801G (ICH7 Family) SMBus Controller'
    class      = serial bus
    subclass   = SMBus
    bar   [20] = type I/O Port, range 32, base 0xe8a0, size 32, enabled
bge0@pci0:2:0:0:    class=0x020000 card=0x01ad1028 chip=0x167714e4 
rev=0x01 hdr=0x00
    vendor     = 'Broadcom Corporation'
    device     = 'BCM5750A1 NetXtreme Gigabit Ethernet PCI Express'
    class      = network
    subclass   = ethernet
    bar   [10] = type Memory, range 64, base 0xfe8f0000, size 65536, enabled
vgapci2@pci0:4:0:0:    class=0x030000 card=0x0250174b chip=0x59601002 
rev=0x01 hdr=0x00
    vendor     = 'ATI Technologies Inc'
    device     = 'RV280 Radeon 9200 Pro'
    class      = display
    subclass   = VGA
    bar   [10] = type Prefetchable Memory, range 32, base 0xe8000000, 
size 134217728, enabled
    bar   [14] = type I/O Port, range 32, base 0xdc00, size 256, enabled
    bar   [18] = type Memory, range 32, base 0xfe5e0000, size 65536, enabled
vgapci3@pci0:4:0:1:    class=0x038000 card=0x0251174b chip=0x59401002 
rev=0x01 hdr=0x00
    vendor     = 'ATI Technologies Inc'
    device     = 'RV280 Radeon 9200 Pro - Secondary'
    class      = display
    bar   [10] = type Prefetchable Memory, range 32, base 0xe0000000, 
size 134217728, enabled
    bar   [14] = type Memory, range 32, base 0xfe5f0000, size 65536, enabled

From rnoland at FreeBSD.org  Mon May  4 20:10:48 2009
From: rnoland at FreeBSD.org (Robert Noland)
Date: Mon May  4 20:10:55 2009
Subject: Radeon 9250 DRM in 7.2-RELEASE
In-Reply-To: <49FF4857.4070904@comcast.net>
References: <49FF28BC.5080304@comcast.net>
	<1241460816.1788.22.camel@balrog.2hip.net>
	<49FF387F.1080203@comcast.net>
	<1241464053.1788.32.camel@balrog.2hip.net>
	<49FF4857.4070904@comcast.net>
Message-ID: <1241467827.1788.43.camel@balrog.2hip.net>

Skipped content of type multipart/mixed-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: This is a digitally signed message part
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20090504/7edac251/attachment.pgp
From korvus at comcast.net  Mon May  4 20:36:14 2009
From: korvus at comcast.net (Steve Polyack)
Date: Mon May  4 20:36:30 2009
Subject: Radeon 9250 DRM in 7.2-RELEASE
In-Reply-To: <1241467827.1788.43.camel@balrog.2hip.net>
References: <49FF28BC.5080304@comcast.net>	
	<1241460816.1788.22.camel@balrog.2hip.net>
	<49FF387F.1080203@comcast.net>	
	<1241464053.1788.32.camel@balrog.2hip.net>
	<49FF4857.4070904@comcast.net>
	<1241467827.1788.43.camel@balrog.2hip.net>
Message-ID: <49FF51BC.5050104@comcast.net>

Robert Noland wrote:
> Ok, they are at least partially disabled...  I wonder if a BIOS update
> would help.
>
> Anyway, the garbled screen issue is usually associated with the caching
> method used on the PCI GART.  On IGP chips we force the GART to be
> uncacheable.  On PCI chips they are supposed to be able to snoop the bus
> and DTRT.  All of the fixes for memory caching should be in 7.
>
> Please try the attached patch and see if that makes a difference.
>
> robert.
>
>   

Unfortunately, this didn't help.  I should also clarify what I'm seeing, 
as it's not complete garbage as I thought.  I have a dual monitor setup, 
side-by-side using xrandr.  When I start X (xfce4) with drm available, 
the left monitor (primary) is a sold light shade of blue, except for a 
black corner which is maybe 10pix square.  The right monitor displays my 
typical background image with another black box over part of it.  If it 
shift back to the console and then back into X, I can see the outlines 
of my startup windows, but they contain garbage and the outlines are 
fuzzed with green and magenta garbage.

From rnoland at FreeBSD.org  Mon May  4 20:49:48 2009
From: rnoland at FreeBSD.org (Robert Noland)
Date: Mon May  4 20:49:55 2009
Subject: Radeon 9250 DRM in 7.2-RELEASE
In-Reply-To: <49FF51BC.5050104@comcast.net>
References: <49FF28BC.5080304@comcast.net>
	<1241460816.1788.22.camel@balrog.2hip.net>
	<49FF387F.1080203@comcast.net>
	<1241464053.1788.32.camel@balrog.2hip.net>
	<49FF4857.4070904@comcast.net>
	<1241467827.1788.43.camel@balrog.2hip.net>
	<49FF51BC.5050104@comcast.net>
Message-ID: <1241470167.1788.45.camel@balrog.2hip.net>

Skipped content of type multipart/mixed-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: This is a digitally signed message part
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20090504/c377963e/attachment.pgp
From torfinn.ingolfsen at broadpark.no  Mon May  4 20:51:03 2009
From: torfinn.ingolfsen at broadpark.no (Torfinn Ingolfsen)
Date: Mon May  4 20:51:11 2009
Subject: RELENG_7 - has mergemaster changed logic since 7.2-RELEASE?
Message-ID: <20090504225012.392fa49f.torfinn.ingolfsen@broadpark.no>

Ok, this is strange.

I just upgraded from 7.2-prerelease (as of 20090401) to 7.2-stable as
of today, using csup and building world.

As part of that process I did (as I always do) 'mergemaster -iU' after
the 'make installworld' step.
A few files on my machines are modified by me, and thus should nevber
be upgraded:
/etc/dhclient.conf
/etc/motd (mergemeaster will usually ask about this - this time it did
not, it claimed it wasn't user modified, huh?)
/etc/profile
/root/.profile
/etc/passwd (mergemaster sked about it, I pressed 'd', but it was still
upgraded, ugh!)
/etc/group (mergemaster sked about it, I pressed 'd', but it was still
upgraded, ugh!)

It can be more files, I haven't found out yet.

Has anyone else seen this?

I am upgrading my next machine, this time I'll have backups and keep
better notes.
-- 
Regards,
Torfinn Ingolfsen

From josh.carroll at gmail.com  Mon May  4 21:05:02 2009
From: josh.carroll at gmail.com (Josh Carroll)
Date: Mon May  4 21:05:09 2009
Subject: ext2fs inode size fix never MFC'd
Message-ID: <8cb6106e0905041404m57361accg1b61b44d9bc39199@mail.gmail.com>

I just noticed that the changes to the ext2 code to support inode
sizes other than 128 was never MFC'd:

http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/gnu/fs/ext2fs/ext2_linux_ialloc.c?r1=1.25.8.1;sortby=date#diff

I submitted a patch to this PR:

http://www.freebsd.org/cgi/query-pr.cgi?pr=124621&cat=

Which was partially adopted (or at least the same idea was used) and
committed to HEAD back in January, but the MFC after 2 weeks to
RELENG_7 never happened, unfortunately.

I was hoping this would make it into 7.1, and I seem to have noticed
this too late for 7.2-RELEASE but can someone get this merged into
RELENG_7?

Regards,
Josh
From sonic2000gr at gmail.com  Mon May  4 21:07:20 2009
From: sonic2000gr at gmail.com (Manolis Kiagias)
Date: Mon May  4 21:07:29 2009
Subject: RELENG_7 - has mergemaster changed logic since 7.2-RELEASE?
In-Reply-To: <20090504225012.392fa49f.torfinn.ingolfsen@broadpark.no>
References: <20090504225012.392fa49f.torfinn.ingolfsen@broadpark.no>
Message-ID: <49FF5901.600@gmail.com>

Torfinn Ingolfsen wrote:
> Ok, this is strange.
>
> I just upgraded from 7.2-prerelease (as of 20090401) to 7.2-stable as
> of today, using csup and building world.
>
> As part of that process I did (as I always do) 'mergemaster -iU' after
> the 'make installworld' step.
> A few files on my machines are modified by me, and thus should nevber
> be upgraded:
> /etc/dhclient.conf
> /etc/motd (mergemeaster will usually ask about this - this time it did
> not, it claimed it wasn't user modified, huh?)
> /etc/profile
> /root/.profile
> /etc/passwd (mergemaster sked about it, I pressed 'd', but it was still
> upgraded, ugh!)
> /etc/group (mergemaster sked about it, I pressed 'd', but it was still
> upgraded, ugh!)
>
> It can be more files, I haven't found out yet.
>
> Has anyone else seen this?
>
> I am upgrading my next machine, this time I'll have backups and keep
> better notes.
>   
I always use -iU too.
I've lost motd, passwd, group and master.passwd
During mergemaster -p I was asked to merge changes to some of these, and
still they were replaced with the newer versions. I don't know what went
wrong but have restored them from backup. (I always tar /etc before a
source upgrade). Upgrading another system using freebsd-update did not
cause any problem.
From vince at unsane.co.uk  Mon May  4 21:32:07 2009
From: vince at unsane.co.uk (Vincent Hoffman)
Date: Mon May  4 21:32:15 2009
Subject: RELENG_7 - has mergemaster changed logic since 7.2-RELEASE?
In-Reply-To: <20090504225012.392fa49f.torfinn.ingolfsen@broadpark.no>
References: <20090504225012.392fa49f.torfinn.ingolfsen@broadpark.no>
Message-ID: <49FF5D9C.5060409@unsane.co.uk>

On 4/5/09 21:50, Torfinn Ingolfsen wrote:
> Ok, this is strange.
>
> I just upgraded from 7.2-prerelease (as of 20090401) to 7.2-stable as
> of today, using csup and building world.
>
> As part of that process I did (as I always do) 'mergemaster -iU' after
> the 'make installworld' step.
> A few files on my machines are modified by me, and thus should nevber
> be upgraded:
> /etc/dhclient.conf
> /etc/motd (mergemeaster will usually ask about this - this time it did
> not, it claimed it wasn't user modified, huh?)
> /etc/profile
> /root/.profile
> /etc/passwd (mergemaster sked about it, I pressed 'd', but it was still
> upgraded, ugh!)
> /etc/group (mergemaster sked about it, I pressed 'd', but it was still
> upgraded, ugh!)
>
> It can be more files, I haven't found out yet.
>
> Has anyone else seen this?
>
> I am upgrading my next machine, this time I'll have backups and keep
> better notes.
>   
Not that its a cure but are master.passwd and group backups in
/var/backups any help to you in this case?

Vince
From korvus at comcast.net  Mon May  4 21:41:15 2009
From: korvus at comcast.net (Steve Polyack)
Date: Mon May  4 21:41:27 2009
Subject: Radeon 9250 DRM in 7.2-RELEASE
In-Reply-To: <1241470167.1788.45.camel@balrog.2hip.net>
References: <49FF28BC.5080304@comcast.net>	
	<1241460816.1788.22.camel@balrog.2hip.net>
	<49FF387F.1080203@comcast.net>	
	<1241464053.1788.32.camel@balrog.2hip.net>
	<49FF4857.4070904@comcast.net>	
	<1241467827.1788.43.camel@balrog.2hip.net>
	<49FF51BC.5050104@comcast.net>
	<1241470167.1788.45.camel@balrog.2hip.net>
Message-ID: <49FF60F9.6010303@comcast.net>

Robert Noland wrote:
> ok, how about this one... If this doesn't do it, then we need to start
> digging...
>
> robert.
>
>   

No change when using this patch either.  I've also updated to the latest 
BIOS and have ensured that the onboard Intel adapter is as disabled as 
it can get.  I can provide you some photos of the screen behavior if you 
think it may help.  Thanks again so far!

From rnoland at FreeBSD.org  Mon May  4 21:53:24 2009
From: rnoland at FreeBSD.org (Robert Noland)
Date: Mon May  4 21:53:37 2009
Subject: Radeon 9250 DRM in 7.2-RELEASE
In-Reply-To: <49FF60F9.6010303@comcast.net>
References: <49FF28BC.5080304@comcast.net>
	<1241460816.1788.22.camel@balrog.2hip.net>
	<49FF387F.1080203@comcast.net>
	<1241464053.1788.32.camel@balrog.2hip.net>
	<49FF4857.4070904@comcast.net>
	<1241467827.1788.43.camel@balrog.2hip.net>
	<49FF51BC.5050104@comcast.net>
	<1241470167.1788.45.camel@balrog.2hip.net>
	<49FF60F9.6010303@comcast.net>
Message-ID: <1241473983.1788.48.camel@balrog.2hip.net>

On Mon, 2009-05-04 at 17:41 -0400, Steve Polyack wrote:
> Robert Noland wrote:
> > ok, how about this one... If this doesn't do it, then we need to start
> > digging...
> >
> > robert.
> >
> >   
> 
> No change when using this patch either.  I've also updated to the latest 
> BIOS and have ensured that the onboard Intel adapter is as disabled as 
> it can get.  I can provide you some photos of the screen behavior if you 
> think it may help.  Thanks again so far!

Ok, so to start with, we need an xorg log and conf.  If you kldload
radeon.ko before starting X then you can set hw.dri.0.debug=1 which will
dump a bunch of drm debugging into /var/log/messages.  That would be
useful.  Also having a look at "memcontrol list" might be a good idea.

robert.

> _______________________________________________
> freebsd-x11@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-x11
> To unsubscribe, send any mail to "freebsd-x11-unsubscribe@freebsd.org"
-- 
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-stable/attachments/20090504/0542896b/attachment.pgp
From torfinn.ingolfsen at broadpark.no  Mon May  4 22:29:20 2009
From: torfinn.ingolfsen at broadpark.no (Torfinn Ingolfsen)
Date: Mon May  4 22:29:30 2009
Subject: RELENG_7 - has mergemaster changed logic since 7.2-RELEASE?
In-Reply-To: <20090504225012.392fa49f.torfinn.ingolfsen@broadpark.no>
References: <20090504225012.392fa49f.torfinn.ingolfsen@broadpark.no>
Message-ID: <20090505002856.75fe1800.torfinn.ingolfsen@broadpark.no>

On Mon, 04 May 2009 22:50:12 +0200
Torfinn Ingolfsen <torfinn.ingolfsen@broadpark.no> wrote:

> I am upgrading my next machine, this time I'll have backups and keep
> better notes.

Ok, this machine was last upgraded a few days ago (20090501) so there
wasn't a lot of changes. This time, only /etc/motd got hit.
Here are the files:
root@kg-quiet# ls -l /etc/motd_ti /etc/motd
-rw-r--r--  1 root  wheel  1112 May  4 23:59 /etc/motd
-rw-r--r--  1 root  wheel   792 May  1 21:52 /etc/motd_ti

The file named motd_ti is my backup. Before this installation it was
a copy of the file motd. Howcan mergemaster say that these two files
are the same, or that /etc/motd wasn't user modified?

script output from 'mergemaster -p' and 'mergemaster -iU' attached in
case it helps.
(I got this tip in mail)

HTH
-- 
Regards,
Torfinn Ingolfsen

-------------- next part --------------
Script started on Mon May  4 23:49:30 2009
root@kg-quiet# mergemaster -p

*** Creating the temporary root environment in /var/tmp/temproot
 *** /var/tmp/temproot ready for use
 *** Creating and populating directory structure in /var/tmp/temproot



*** Beginning comparison

 *** Temp ./etc/master.passwd and installed have the same CVS Id, deleting
 *** Temp ./etc/group and installed have the same CVS Id, deleting

*** Comparison complete
*** Saving mtree database for future upgrades

Do you wish to delete what is left of /var/tmp/temproot? [no] yes
 *** /var/tmp/temproot has been deleted


*** Comparing make variables

*** From /etc/make.conf
*** From /usr/src/share/examples/etc/make.conf

NO_PROFILE=     true    # Avoid compiling profiled libraries
 * No example variable with this name

PERL_VERSION=5.8.9
 * No example variable with this name
root@kg-quiet# ^D
Script done on Mon May  4 23:49:44 2009
-------------- next part --------------
Script started on Mon May  4 23:54:21 2009
root@kg-quiet# mergemaster -iU

*** Creating the temporary root environment in /var/tmp/temproot
 *** /var/tmp/temproot ready for use
 *** Creating and populating directory structure in /var/tmp/temproot

cd /usr/src/etc; MAKEOBJDIRPREFIX=/usr/obj  MACHINE_ARCH=amd64  MACHINE=amd64  CPUTYPE=  GROFF_BIN_PATH=/usr/obj/usr/src/tmp/legacy/usr/bin  GROFF_FONT_PATH=/usr/obj/usr/src/tmp/legacy/usr/share/groff_font  GROFF_TMAC_PATH=/usr/obj/usr/src/tmp/legacy/usr/share/tmac PATH=/usr/obj/usr/src/tmp/legacy/usr/sbin:/usr/obj/usr/src/tmp/legacy/usr/bin:/usr/obj/usr/src/tmp/legacy/usr/games:/usr/obj/usr/src/tmp/usr/sbin:/usr/obj/usr/src/tmp/usr/bin:/usr/obj/usr/src/tmp/usr/games:/sbin:/bin:/usr/sbin:/usr/bin make distrib-dirs
mtree -eU  -f /usr/src/etc/mtree/BSD.root.dist -p /var/tmp/temproot/
./bin missing (created)
./boot missing (created)
./boot/defaults missing (created)
./boot/firmware missing (created)
./boot/kernel missing (created)
./boot/modules missing (created)
./boot/zfs missing (created)
./dev missing (created)
./etc missing (created)
./etc/X11 missing (created)
./etc/bluetooth missing (created)
./etc/defaults missing (created)
./etc/gnats missing (created)
./etc/gss missing (created)
./etc/isdn missing (created)
./etc/mail missing (created)
./etc/mtree missing (created)
./etc/ntp missing (created)
./etc/pam.d missing (created)
./etc/periodic missing (created)
./etc/periodic/daily missing (created)
./etc/periodic/monthly missing (created)
./etc/periodic/security missing (created)
./etc/periodic/weekly missing (created)
./etc/ppp missing (created)
./etc/rc.d missing (created)
./etc/security missing (created)
./etc/skel missing (created)
./etc/ssh missing (created)
./etc/ssl missing (created)
./etc/zfs missing (created)
./lib missing (created)
./lib/geom missing (created)
./libexec missing (created)
./media missing (created)
./mnt missing (created)
./proc missing (created)
./rescue missing (created)
./root missing (created)
./sbin missing (created)
./tmp missing (created)
./usr missing (created)
./var missing (created)
mtree -eU  -f /usr/src/etc/mtree/BSD.var.dist -p /var/tmp/temproot/var
./account missing (created)
./at missing (created)
./at/jobs missing (created)
./at/spool missing (created)
./audit missing (created)
./backups missing (created)
./crash missing (created)
./cron missing (created)
./cron/tabs missing (created)
./db missing (created)
./db/entropy missing (created)
./db/freebsd-update missing (created)
./db/ipf missing (created)
./db/pkg missing (created)
./db/ports missing (created)
./db/portsnap missing (created)
./empty missing (created)
./games missing (created)
./heimdal missing (created)
./log missing (created)
./mail missing (created)
./msgs missing (created)
./named missing (created)
./preserve missing (created)
./run missing (created)
./run/named missing (created)
./run/ppp missing (created)
./rwho missing (created)
./spool missing (created)
./spool/lock missing (created)
./spool/lpd missing (created)
./spool/mqueue missing (created)
./spool/opielocks missing (created)
./spool/output missing (created)
./spool/output/lpd missing (created)
./tmp missing (created)
./tmp/vi.recover missing (created)
./yp missing (created)
mtree -eU  -f /usr/src/etc/mtree/BSD.usr.dist -p /var/tmp/temproot/usr
./bin missing (created)
./games missing (created)
./include missing (created)
./lib missing (created)
./lib/aout missing (created)
./lib/compat missing (created)
./lib/compat/aout missing (created)
./lib/dtrace missing (created)
./lib/engines missing (created)
./libdata missing (created)
./libdata/gcc missing (created)
./libdata/ldscripts missing (created)
./libdata/lint missing (created)
./libexec missing (created)
./libexec/lpr missing (created)
./libexec/lpr/ru missing (created)
./libexec/sendmail missing (created)
./libexec/sm.bin missing (created)
./local missing (created)
./obj missing (created)
./sbin missing (created)
./share missing (created)
./share/calendar missing (created)
./share/calendar/de_DE.ISO8859-1 missing (created)
./share/calendar/fr_FR.ISO8859-1 missing (created)
./share/calendar/hr_HR.ISO8859-2 missing (created)
./share/calendar/hu_HU.ISO8859-2 missing (created)
./share/calendar/ru_RU.KOI8-R missing (created)
./share/calendar/uk_UA.KOI8-U missing (created)
./share/dict missing (created)
./share/doc missing (created)
./share/doc/IPv6 missing (created)
./share/doc/atm missing (created)
./share/doc/bind9 missing (created)
./share/doc/bind9/arm missing (created)
./share/doc/bind9/misc missing (created)
./share/doc/legal missing (created)
./share/doc/legal/intel_ipw missing (created)
./share/doc/legal/intel_iwi missing (created)
./share/doc/legal/intel_wpi missing (created)
./share/doc/ncurses missing (created)
./share/doc/ntp missing (created)
./share/doc/papers missing (created)
./share/doc/psd missing (created)
./share/doc/psd/01.cacm missing (created)
./share/doc/psd/02.implement missing (created)
./share/doc/psd/03.iosys missing (created)
./share/doc/psd/04.uprog missing (created)
./share/doc/psd/05.sysman missing (created)
./share/doc/psd/06.Clang missing (created)
./share/doc/psd/12.make missing (created)
./share/doc/psd/13.rcs missing (created)
./share/doc/psd/15.yacc missing (created)
./share/doc/psd/16.lex missing (created)
./share/doc/psd/17.m4 missing (created)
./share/doc/psd/18.gprof missing (created)
./share/doc/psd/20.ipctut missing (created)
./share/doc/psd/21.ipc missing (created)
./share/doc/psd/22.rpcgen missing (created)
./share/doc/psd/23.rpc missing (created)
./share/doc/psd/24.xdr missing (created)
./share/doc/psd/25.xdrrfc missing (created)
./share/doc/psd/26.rpcrfc missing (created)
./share/doc/psd/27.nfsrfc missing (created)
./share/doc/psd/28.cvs missing (created)
./share/doc/smm missing (created)
./share/doc/smm/01.setup missing (created)
./share/doc/smm/02.config missing (created)
./share/doc/smm/03.fsck missing (created)
./share/doc/smm/04.quotas missing (created)
./share/doc/smm/05.fastfs missing (created)
./share/doc/smm/06.nfs missing (created)
./share/doc/smm/07.lpd missing (created)
./share/doc/smm/08.sendmailop missing (created)
./share/doc/smm/11.timedop missing (created)
./share/doc/smm/12.timed missing (created)
./share/doc/smm/18.net missing (created)
./share/doc/usd missing (created)
./share/doc/usd/04.csh missing (created)
./share/doc/usd/07.mail missing (created)
./share/doc/usd/10.exref missing (created)
./share/doc/usd/11.edit missing (created)
./share/doc/usd/12.vi missing (created)
./share/doc/usd/13.viref missing (created)
./share/doc/usd/18.msdiffs missing (created)
./share/doc/usd/19.memacros missing (created)
./share/doc/usd/20.meref missing (created)
./share/doc/usd/21.troff missing (created)
./share/doc/usd/22.trofftut missing (created)
./share/examples missing (created)
./share/examples/BSD_daemon missing (created)
./share/examples/FreeBSD_version missing (created)
./share/examples/IPv6 missing (created)
./share/examples/bc missing (created)
./share/examples/bootforth missing (created)
./share/examples/cvs missing (created)
./share/examples/cvs/contrib missing (created)
./share/examples/cvsup missing (created)
./share/examples/dialog missing (created)
./share/examples/diskless missing (created)
./share/examples/drivers missing (created)
./share/examples/etc missing (created)
./share/examples/etc/defaults missing (created)
./share/examples/find_interface missing (created)
./share/examples/hostapd missing (created)
./share/examples/ibcs2 missing (created)
./share/examples/ipfilter missing (created)
./share/examples/ipfw missing (created)
./share/examples/iscsi missing (created)
./share/examples/isdn missing (created)
./share/examples/isdn/contrib missing (created)
./share/examples/isdn/i4brunppp missing (created)
./share/examples/isdn/v21 missing (created)
./share/examples/kld missing (created)
./share/examples/kld/cdev missing (created)
./share/examples/kld/cdev/module missing (created)
./share/examples/kld/cdev/test missing (created)
./share/examples/kld/dyn_sysctl missing (created)
./share/examples/kld/syscall missing (created)
./share/examples/kld/syscall/module missing (created)
./share/examples/kld/syscall/test missing (created)
./share/examples/libdialog missing (created)
./share/examples/libvgl missing (created)
./share/examples/mdoc missing (created)
./share/examples/netgraph missing (created)
./share/examples/netgraph/bluetooth missing (created)
./share/examples/nwclient missing (created)
./share/examples/perfmon missing (created)
./share/examples/pf missing (created)
./share/examples/portal missing (created)
./share/examples/ppi missing (created)
./share/examples/ppp missing (created)
./share/examples/pppd missing (created)
./share/examples/printing missing (created)
./share/examples/scsi_target missing (created)
./share/examples/ses missing (created)
./share/examples/ses/getencstat missing (created)
./share/examples/ses/sesd missing (created)
./share/examples/ses/setencstat missing (created)
./share/examples/ses/setobjstat missing (created)
./share/examples/ses/srcs missing (created)
./share/examples/slattach missing (created)
./share/examples/sliplogin missing (created)
./share/examples/smbfs missing (created)
./share/examples/smbfs/print missing (created)
./share/examples/startslip missing (created)
./share/examples/sunrpc missing (created)
./share/examples/sunrpc/dir missing (created)
./share/examples/sunrpc/msg missing (created)
./share/examples/sunrpc/sort missing (created)
./share/examples/tcsh missing (created)
./share/examples/wpa_supplicant missing (created)
./share/games missing (created)
./share/games/fortune missing (created)
./share/groff_font missing (created)
./share/groff_font/devX100 missing (created)
./share/groff_font/devX100-12 missing (created)
./share/groff_font/devX75 missing (created)
./share/groff_font/devX75-12 missing (created)
./share/groff_font/devascii missing (created)
./share/groff_font/devcp1047 missing (created)
./share/groff_font/devdvi missing (created)
./share/groff_font/devhtml missing (created)
./share/groff_font/devkoi8-r missing (created)
./share/groff_font/devlatin1 missing (created)
./share/groff_font/devlbp missing (created)
./share/groff_font/devlj4 missing (created)
./share/groff_font/devps missing (created)
./share/groff_font/devutf8 missing (created)
./share/info missing (created)
./share/isdn missing (created)
./share/locale missing (created)
./share/locale/UTF-8 missing (created)
./share/locale/af_ZA.ISO8859-1 missing (created)
./share/locale/af_ZA.ISO8859-15 missing (created)
./share/locale/af_ZA.UTF-8 missing (created)
./share/locale/am_ET.UTF-8 missing (created)
./share/locale/be_BY.CP1131 missing (created)
./share/locale/be_BY.CP1251 missing (created)
./share/locale/be_BY.ISO8859-5 missing (created)
./share/locale/be_BY.UTF-8 missing (created)
./share/locale/bg_BG.CP1251 missing (created)
./share/locale/bg_BG.UTF-8 missing (created)
./share/locale/ca_ES.ISO8859-1 missing (created)
./share/locale/ca_ES.ISO8859-15 missing (created)
./share/locale/ca_ES.UTF-8 missing (created)
./share/locale/cs_CZ.ISO8859-2 missing (created)
./share/locale/cs_CZ.UTF-8 missing (created)
./share/locale/da_DK.ISO8859-1 missing (created)
./share/locale/da_DK.ISO8859-15 missing (created)
./share/locale/da_DK.UTF-8 missing (created)
./share/locale/de_AT.ISO8859-1 missing (created)
./share/locale/de_AT.ISO8859-15 missing (created)
./share/locale/de_AT.UTF-8 missing (created)
./share/locale/de_CH.ISO8859-1 missing (created)
./share/locale/de_CH.ISO8859-15 missing (created)
./share/locale/de_CH.UTF-8 missing (created)
./share/locale/de_DE.ISO8859-1 missing (created)
./share/locale/de_DE.ISO8859-15 missing (created)
./share/locale/de_DE.UTF-8 missing (created)
./share/locale/el_GR.ISO8859-7 missing (created)
./share/locale/el_GR.UTF-8 missing (created)
./share/locale/en_AU.ISO8859-1 missing (created)
./share/locale/en_AU.ISO8859-15 missing (created)
./share/locale/en_AU.US-ASCII missing (created)
./share/locale/en_AU.UTF-8 missing (created)
./share/locale/en_CA.ISO8859-1 missing (created)
./share/locale/en_CA.ISO8859-15 missing (created)
./share/locale/en_CA.US-ASCII missing (created)
./share/locale/en_CA.UTF-8 missing (created)
./share/locale/en_GB.ISO8859-1 missing (created)
./share/locale/en_GB.ISO8859-15 missing (created)
./share/locale/en_GB.US-ASCII missing (created)
./share/locale/en_GB.UTF-8 missing (created)
./share/locale/en_IE.UTF-8 missing (created)
./share/locale/en_NZ.ISO8859-1 missing (created)
./share/locale/en_NZ.ISO8859-15 missing (created)
./share/locale/en_NZ.US-ASCII missing (created)
./share/locale/en_NZ.UTF-8 missing (created)
./share/locale/en_US.ISO8859-1 missing (created)
./share/locale/en_US.ISO8859-15 missing (created)
./share/locale/en_US.US-ASCII missing (created)
./share/locale/en_US.UTF-8 missing (created)
./share/locale/es_ES.ISO8859-1 missing (created)
./share/locale/es_ES.ISO8859-15 missing (created)
./share/locale/es_ES.UTF-8 missing (created)
./share/locale/et_EE.ISO8859-15 missing (created)
./share/locale/et_EE.UTF-8 missing (created)
./share/locale/eu_ES.ISO8859-1 missing (created)
./share/locale/eu_ES.ISO8859-15 missing (created)
./share/locale/eu_ES.UTF-8 missing (created)
./share/locale/fi_FI.ISO8859-1 missing (created)
./share/locale/fi_FI.ISO8859-15 missing (created)
./share/locale/fi_FI.UTF-8 missing (created)
./share/locale/fr_BE.ISO8859-1 missing (created)
./share/locale/fr_BE.ISO8859-15 missing (created)
./share/locale/fr_BE.UTF-8 missing (created)
./share/locale/fr_CA.ISO8859-1 missing (created)
./share/locale/fr_CA.ISO8859-15 missing (created)
./share/locale/fr_CA.UTF-8 missing (created)
./share/locale/fr_CH.ISO8859-1 missing (created)
./share/locale/fr_CH.ISO8859-15 missing (created)
./share/locale/fr_CH.UTF-8 missing (created)
./share/locale/fr_FR.ISO8859-1 missing (created)
./share/locale/fr_FR.ISO8859-15 missing (created)
./share/locale/fr_FR.UTF-8 missing (created)
./share/locale/he_IL.UTF-8 missing (created)
./share/locale/hi_IN.ISCII-DEV missing (created)
./share/locale/hr_HR.ISO8859-2 missing (created)
./share/locale/hr_HR.UTF-8 missing (created)
./share/locale/hu_HU.ISO8859-2 missing (created)
./share/locale/hu_HU.UTF-8 missing (created)
./share/locale/hy_AM.ARMSCII-8 missing (created)
./share/locale/hy_AM.UTF-8 missing (created)
./share/locale/is_IS.ISO8859-1 missing (created)
./share/locale/is_IS.ISO8859-15 missing (created)
./share/locale/is_IS.UTF-8 missing (created)
./share/locale/it_CH.ISO8859-1 missing (created)
./share/locale/it_CH.ISO8859-15 missing (created)
./share/locale/it_CH.UTF-8 missing (created)
./share/locale/it_IT.ISO8859-1 missing (created)
./share/locale/it_IT.ISO8859-15 missing (created)
./share/locale/it_IT.UTF-8 missing (created)
./share/locale/ja_JP.SJIS missing (created)
./share/locale/ja_JP.UTF-8 missing (created)
./share/locale/ja_JP.eucJP missing (created)
./share/locale/kk_KZ.PT154 missing (created)
./share/locale/kk_KZ.UTF-8 missing (created)
./share/locale/ko_KR.CP949 missing (created)
./share/locale/ko_KR.UTF-8 missing (created)
./share/locale/ko_KR.eucKR missing (created)
./share/locale/la_LN.ISO8859-1 missing (created)
./share/locale/la_LN.ISO8859-15 missing (created)
./share/locale/la_LN.ISO8859-2 missing (created)
./share/locale/la_LN.ISO8859-4 missing (created)
./share/locale/la_LN.US-ASCII missing (created)
./share/locale/lt_LT.ISO8859-13 missing (created)
./share/locale/lt_LT.ISO8859-4 missing (created)
./share/locale/lt_LT.UTF-8 missing (created)
./share/locale/mn_MN.UTF-8 missing (created)
./share/locale/nb_NO.ISO8859-1 missing (created)
./share/locale/nb_NO.ISO8859-15 missing (created)
./share/locale/nb_NO.UTF-8 missing (created)
./share/locale/nl_BE.ISO8859-1 missing (created)
./share/locale/nl_BE.ISO8859-15 missing (created)
./share/locale/nl_BE.UTF-8 missing (created)
./share/locale/nl_NL.ISO8859-1 missing (created)
./share/locale/nl_NL.ISO8859-15 missing (created)
./share/locale/nl_NL.UTF-8 missing (created)
./share/locale/nn_NO.ISO8859-1 missing (created)
./share/locale/nn_NO.ISO8859-15 missing (created)
./share/locale/nn_NO.UTF-8 missing (created)
./share/locale/no_NO.ISO8859-1 missing (created)
./share/locale/no_NO.ISO8859-15 missing (created)
./share/locale/no_NO.UTF-8 missing (created)
./share/locale/pl_PL.ISO8859-2 missing (created)
./share/locale/pl_PL.UTF-8 missing (created)
./share/locale/pt_BR.ISO8859-1 missing (created)
./share/locale/pt_BR.UTF-8 missing (created)
./share/locale/pt_PT.ISO8859-1 missing (created)
./share/locale/pt_PT.ISO8859-15 missing (created)
./share/locale/pt_PT.UTF-8 missing (created)
./share/locale/ro_RO.ISO8859-2 missing (created)
./share/locale/ro_RO.UTF-8 missing (created)
./share/locale/ru_RU.CP1251 missing (created)
./share/locale/ru_RU.CP866 missing (created)
./share/locale/ru_RU.ISO8859-5 missing (created)
./share/locale/ru_RU.KOI8-R missing (created)
./share/locale/ru_RU.UTF-8 missing (created)
./share/locale/sk_SK.ISO8859-2 missing (created)
./share/locale/sk_SK.UTF-8 missing (created)
./share/locale/sl_SI.ISO8859-2 missing (created)
./share/locale/sl_SI.UTF-8 missing (created)
./share/locale/sr_YU.ISO8859-2 missing (created)
./share/locale/sr_YU.ISO8859-5 missing (created)
./share/locale/sr_YU.UTF-8 missing (created)
./share/locale/sv_SE.ISO8859-1 missing (created)
./share/locale/sv_SE.ISO8859-15 missing (created)
./share/locale/sv_SE.UTF-8 missing (created)
./share/locale/tr_TR.ISO8859-9 missing (created)
./share/locale/tr_TR.UTF-8 missing (created)
./share/locale/uk_UA.CP1251 missing (created)
./share/locale/uk_UA.ISO8859-5 missing (created)
./share/locale/uk_UA.KOI8-U missing (created)
./share/locale/uk_UA.UTF-8 missing (created)
./share/locale/zh_CN.GB18030 missing (created)
./share/locale/zh_CN.GB2312 missing (created)
./share/locale/zh_CN.GBK missing (created)
./share/locale/zh_CN.UTF-8 missing (created)
./share/locale/zh_CN.eucCN missing (created)
./share/locale/zh_HK.Big5HKSCS missing (created)
./share/locale/zh_HK.UTF-8 missing (created)
./share/locale/zh_TW.Big5 missing (created)
./share/locale/zh_TW.UTF-8 missing (created)
./share/man missing (created)
./share/man/cat1 missing (created)
./share/man/cat1aout missing (created)
./share/man/cat2 missing (created)
./share/man/cat3 missing (created)
./share/man/cat4 missing (created)
./share/man/cat4/amd64 missing (created)
./share/man/cat4/arm missing (created)
./share/man/cat4/i386 missing (created)
./share/man/cat4/powerpc missing (created)
./share/man/cat4/sparc64 missing (created)
./share/man/cat5 missing (created)
./share/man/cat6 missing (created)
./share/man/cat7 missing (created)
./share/man/cat8 missing (created)
./share/man/cat8/amd64 missing (created)
./share/man/cat8/i386 missing (created)
./share/man/cat8/powerpc missing (created)
./share/man/cat8/sparc64 missing (created)
./share/man/cat9 missing (created)
./share/man/en.ISO8859-1 missing (created)
./share/man/en.ISO8859-1/cat1 missing (created)
./share/man/en.ISO8859-1/cat1aout missing (created)
./share/man/en.ISO8859-1/cat2 missing (created)
./share/man/en.ISO8859-1/cat3 missing (created)
./share/man/en.ISO8859-1/cat4 missing (created)
./share/man/en.ISO8859-1/cat4/amd64 missing (created)
./share/man/en.ISO8859-1/cat4/arm missing (created)
./share/man/en.ISO8859-1/cat4/i386 missing (created)
./share/man/en.ISO8859-1/cat4/powerpc missing (created)
./share/man/en.ISO8859-1/cat4/sparc64 missing (created)
./share/man/en.ISO8859-1/cat5 missing (created)
./share/man/en.ISO8859-1/cat6 missing (created)
./share/man/en.ISO8859-1/cat7 missing (created)
./share/man/en.ISO8859-1/cat8 missing (created)
./share/man/en.ISO8859-1/cat8/amd64 missing (created)
./share/man/en.ISO8859-1/cat8/i386 missing (created)
./share/man/en.ISO8859-1/cat8/powerpc missing (created)
./share/man/en.ISO8859-1/cat8/sparc64 missing (created)
./share/man/en.ISO8859-1/cat9 missing (created)
./share/man/ja missing (created)
./share/man/ja/cat1 missing (created)
./share/man/ja/cat2 missing (created)
./share/man/ja/cat3 missing (created)
./share/man/ja/cat4 missing (created)
./share/man/ja/cat5 missing (created)
./share/man/ja/cat6 missing (created)
./share/man/ja/cat7 missing (created)
./share/man/ja/cat8 missing (created)
./share/man/ja/cat9 missing (created)
./share/man/ja/man1 missing (created)
./share/man/ja/man2 missing (created)
./share/man/ja/man3 missing (created)
./share/man/ja/man4 missing (created)
./share/man/ja/man5 missing (created)
./share/man/ja/man6 missing (created)
./share/man/ja/man7 missing (created)
./share/man/ja/man8 missing (created)
./share/man/ja/man9 missing (created)
./share/man/man1 missing (created)
./share/man/man1aout missing (created)
./share/man/man2 missing (created)
./share/man/man3 missing (created)
./share/man/man4 missing (created)
./share/man/man4/amd64 missing (created)
./share/man/man4/arm missing (created)
./share/man/man4/i386 missing (created)
./share/man/man4/powerpc missing (created)
./share/man/man4/sparc64 missing (created)
./share/man/man5 missing (created)
./share/man/man6 missing (created)
./share/man/man7 missing (created)
./share/man/man8 missing (created)
./share/man/man8/amd64 missing (created)
./share/man/man8/i386 missing (created)
./share/man/man8/powerpc missing (created)
./share/man/man8/sparc64 missing (created)
./share/man/man9 missing (created)
./share/me missing (created)
./share/misc missing (created)
./share/misc/fonts missing (created)
./share/mk missing (created)
./share/nls missing (created)
./share/nls/C missing (created)
./share/nls/af_ZA.ISO8859-1 missing (created)
./share/nls/af_ZA.ISO8859-15 missing (created)
./share/nls/af_ZA.UTF-8 missing (created)
./share/nls/am_ET.UTF-8 missing (created)
./share/nls/be_BY.CP1131 missing (created)
./share/nls/be_BY.CP1251 missing (created)
./share/nls/be_BY.ISO8859-5 missing (created)
./share/nls/be_BY.UTF-8 missing (created)
./share/nls/bg_BG.CP1251 missing (created)
./share/nls/bg_BG.UTF-8 missing (created)
./share/nls/ca_ES.ISO8859-1 missing (created)
./share/nls/ca_ES.ISO8859-15 missing (created)
./share/nls/ca_ES.UTF-8 missing (created)
./share/nls/cs_CZ.ISO8859-2 missing (created)
./share/nls/cs_CZ.UTF-8 missing (created)
./share/nls/da_DK.ISO8859-1 missing (created)
./share/nls/da_DK.ISO8859-15 missing (created)
./share/nls/da_DK.UTF-8 missing (created)
./share/nls/de_AT.ISO8859-1 missing (created)
./share/nls/de_AT.ISO8859-15 missing (created)
./share/nls/de_AT.UTF-8 missing (created)
./share/nls/de_CH.ISO8859-1 missing (created)
./share/nls/de_CH.ISO8859-15 missing (created)
./share/nls/de_CH.UTF-8 missing (created)
./share/nls/de_DE.ISO8859-1 missing (created)
./share/nls/de_DE.ISO8859-15 missing (created)
./share/nls/de_DE.UTF-8 missing (created)
./share/nls/el_GR.ISO8859-7 missing (created)
./share/nls/el_GR.UTF-8 missing (created)
./share/nls/en_AU.ISO8859-1 missing (created)
./share/nls/en_AU.ISO8859-15 missing (created)
./share/nls/en_AU.US-ASCII missing (created)
./share/nls/en_AU.UTF-8 missing (created)
./share/nls/en_CA.ISO8859-1 missing (created)
./share/nls/en_CA.ISO8859-15 missing (created)
./share/nls/en_CA.US-ASCII missing (created)
./share/nls/en_CA.UTF-8 missing (created)
./share/nls/en_GB.ISO8859-1 missing (created)
./share/nls/en_GB.ISO8859-15 missing (created)
./share/nls/en_GB.US-ASCII missing (created)
./share/nls/en_GB.UTF-8 missing (created)
./share/nls/en_IE.UTF-8 missing (created)
./share/nls/en_NZ.ISO8859-1 missing (created)
./share/nls/en_NZ.ISO8859-15 missing (created)
./share/nls/en_NZ.US-ASCII missing (created)
./share/nls/en_NZ.UTF-8 missing (created)
./share/nls/en_US.ISO8859-1 missing (created)
./share/nls/en_US.ISO8859-15 missing (created)
./share/nls/en_US.UTF-8 missing (created)
./share/nls/es_ES.ISO8859-1 missing (created)
./share/nls/es_ES.ISO8859-15 missing (created)
./share/nls/es_ES.UTF-8 missing (created)
./share/nls/et_EE.ISO8859-15 missing (created)
./share/nls/et_EE.UTF-8 missing (created)
./share/nls/fi_FI.ISO8859-1 missing (created)
./share/nls/fi_FI.ISO8859-15 missing (created)
./share/nls/fi_FI.UTF-8 missing (created)
./share/nls/fr_BE.ISO8859-1 missing (created)
./share/nls/fr_BE.ISO8859-15 missing (created)
./share/nls/fr_BE.UTF-8 missing (created)
./share/nls/fr_CA.ISO8859-1 missing (created)
./share/nls/fr_CA.ISO8859-15 missing (created)
./share/nls/fr_CA.UTF-8 missing (created)
./share/nls/fr_CH.ISO8859-1 missing (created)
./share/nls/fr_CH.ISO8859-15 missing (created)
./share/nls/fr_CH.UTF-8 missing (created)
./share/nls/fr_FR.ISO8859-1 missing (created)
./share/nls/fr_FR.ISO8859-15 missing (created)
./share/nls/fr_FR.UTF-8 missing (created)
./share/nls/he_IL.UTF-8 missing (created)
./share/nls/hi_IN.ISCII-DEV missing (created)
./share/nls/hr_HR.ISO8859-2 missing (created)
./share/nls/hr_HR.UTF-8 missing (created)
./share/nls/hu_HU.ISO8859-2 missing (created)
./share/nls/hu_HU.UTF-8 missing (created)
./share/nls/hy_AM.ARMSCII-8 missing (created)
./share/nls/hy_AM.UTF-8 missing (created)
./share/nls/is_IS.ISO8859-1 missing (created)
./share/nls/is_IS.ISO8859-15 missing (created)
./share/nls/is_IS.UTF-8 missing (created)
./share/nls/it_CH.ISO8859-1 missing (created)
./share/nls/it_CH.ISO8859-15 missing (created)
./share/nls/it_CH.UTF-8 missing (created)
./share/nls/it_IT.ISO8859-1 missing (created)
./share/nls/it_IT.ISO8859-15 missing (created)
./share/nls/it_IT.UTF-8 missing (created)
./share/nls/ja_JP.SJIS missing (created)
./share/nls/ja_JP.UTF-8 missing (created)
./share/nls/ja_JP.eucJP missing (created)
./share/nls/kk_KZ.PT154 missing (created)
./share/nls/kk_KZ.UTF-8 missing (created)
./share/nls/ko_KR.CP949 missing (created)
./share/nls/ko_KR.UTF-8 missing (created)
./share/nls/ko_KR.eucKR missing (created)
./share/nls/la_LN.ISO8859-1 missing (created)
./share/nls/la_LN.ISO8859-15 missing (created)
./share/nls/la_LN.ISO8859-2 missing (created)
./share/nls/la_LN.ISO8859-4 missing (created)
./share/nls/la_LN.US-ASCII missing (created)
./share/nls/lt_LT.ISO8859-13 missing (created)
./share/nls/lt_LT.ISO8859-4 missing (created)
./share/nls/lt_LT.UTF-8 missing (created)
./share/nls/mn_MN.UTF-8 missing (created)
./share/nls/nl_BE.ISO8859-1 missing (created)
./share/nls/nl_BE.ISO8859-15 missing (created)
./share/nls/nl_BE.UTF-8 missing (created)
./share/nls/nl_NL.ISO8859-1 missing (created)
./share/nls/nl_NL.ISO8859-15 missing (created)
./share/nls/nl_NL.UTF-8 missing (created)
./share/nls/no_NO.ISO8859-1 missing (created)
./share/nls/no_NO.ISO8859-15 missing (created)
./share/nls/no_NO.UTF-8 missing (created)
./share/nls/pl_PL.ISO8859-2 missing (created)
./share/nls/pl_PL.UTF-8 missing (created)
./share/nls/pt_BR.ISO8859-1 missing (created)
./share/nls/pt_BR.UTF-8 missing (created)
./share/nls/pt_PT.ISO8859-1 missing (created)
./share/nls/pt_PT.ISO8859-15 missing (created)
./share/nls/pt_PT.UTF-8 missing (created)
./share/nls/ro_RO.ISO8859-2 missing (created)
./share/nls/ro_RO.UTF-8 missing (created)
./share/nls/ru_RU.CP1251 missing (created)
./share/nls/ru_RU.CP866 missing (created)
./share/nls/ru_RU.ISO8859-5 missing (created)
./share/nls/ru_RU.KOI8-R missing (created)
./share/nls/ru_RU.UTF-8 missing (created)
./share/nls/sk_SK.ISO8859-2 missing (created)
./share/nls/sk_SK.UTF-8 missing (created)
./share/nls/sl_SI.ISO8859-2 missing (created)
./share/nls/sl_SI.UTF-8 missing (created)
./share/nls/sr_YU.ISO8859-2 missing (created)
./share/nls/sr_YU.ISO8859-5 missing (created)
./share/nls/sr_YU.UTF-8 missing (created)
./share/nls/sv_SE.ISO8859-1 missing (created)
./share/nls/sv_SE.ISO8859-15 missing (created)
./share/nls/sv_SE.UTF-8 missing (created)
./share/nls/tr_TR.ISO8859-9 missing (created)
./share/nls/tr_TR.UTF-8 missing (created)
./share/nls/uk_UA.ISO8859-5 missing (created)
./share/nls/uk_UA.KOI8-U missing (created)
./share/nls/uk_UA.UTF-8 missing (created)
./share/nls/zh_CN.GB18030 missing (created)
./share/nls/zh_CN.GB2312 missing (created)
./share/nls/zh_CN.GBK missing (created)
./share/nls/zh_CN.UTF-8 missing (created)
./share/nls/zh_CN.eucCN missing (created)
./share/nls/zh_HK.Big5HKSCS missing (created)
./share/nls/zh_HK.UTF-8 missing (created)
./share/nls/zh_TW.Big5 missing (created)
./share/nls/zh_TW.UTF-8 missing (created)
./share/openssl missing (created)
./share/openssl/man missing (created)
./share/openssl/man/cat1 missing (created)
./share/openssl/man/cat3 missing (created)
./share/openssl/man/en.ISO8859-1 missing (created)
./share/openssl/man/en.ISO8859-1/cat1 missing (created)
./share/openssl/man/en.ISO8859-1/cat3 missing (created)
./share/openssl/man/man1 missing (created)
./share/openssl/man/man3 missing (created)
./share/security missing (created)
./share/sendmail missing (created)
./share/skel missing (created)
./share/snmp missing (created)
./share/snmp/defs missing (created)
./share/snmp/mibs missing (created)
./share/syscons missing (created)
./share/syscons/fonts missing (created)
./share/syscons/keymaps missing (created)
./share/syscons/scrnmaps missing (created)
./share/tabset missing (created)
./share/tmac missing (created)
./share/tmac/mdoc missing (created)
./share/tmac/mm missing (created)
./share/vi missing (created)
./share/vi/catalog missing (created)
./share/zoneinfo missing (created)
./share/zoneinfo/Africa missing (created)
./share/zoneinfo/America missing (created)
./share/zoneinfo/America/Argentina missing (created)
./share/zoneinfo/America/Indiana missing (created)
./share/zoneinfo/America/Kentucky missing (created)
./share/zoneinfo/America/North_Dakota missing (created)
./share/zoneinfo/Antarctica missing (created)
./share/zoneinfo/Arctic missing (created)
./share/zoneinfo/Asia missing (created)
./share/zoneinfo/Atlantic missing (created)
./share/zoneinfo/Australia missing (created)
./share/zoneinfo/Etc missing (created)
./share/zoneinfo/Europe missing (created)
./share/zoneinfo/Indian missing (created)
./share/zoneinfo/Pacific missing (created)
./share/zoneinfo/SystemV missing (created)
./src missing (created)
mtree -eU  -f /usr/src/etc/mtree/BSD.include.dist  -p /var/tmp/temproot/usr/include
./altq missing (created)
./arpa missing (created)
./bsm missing (created)
./bsnmp missing (created)
./c++ missing (created)
./c++/4.2 missing (created)
./c++/4.2/backward missing (created)
./c++/4.2/bits missing (created)
./c++/4.2/debug missing (created)
./c++/4.2/ext missing (created)
./c++/4.2/ext/pb_ds missing (created)
./c++/4.2/ext/pb_ds/detail missing (created)
./c++/4.2/ext/pb_ds/detail/basic_tree_policy missing (created)
./c++/4.2/ext/pb_ds/detail/bin_search_tree_ missing (created)
./c++/4.2/ext/pb_ds/detail/binary_heap_ missing (created)
./c++/4.2/ext/pb_ds/detail/binomial_heap_ missing (created)
./c++/4.2/ext/pb_ds/detail/binomial_heap_base_ missing (created)
./c++/4.2/ext/pb_ds/detail/cc_hash_table_map_ missing (created)
./c++/4.2/ext/pb_ds/detail/eq_fn missing (created)
./c++/4.2/ext/pb_ds/detail/gp_hash_table_map_ missing (created)
./c++/4.2/ext/pb_ds/detail/hash_fn missing (created)
./c++/4.2/ext/pb_ds/detail/left_child_next_sibling_heap_ missing (created)
./c++/4.2/ext/pb_ds/detail/list_update_map_ missing (created)
./c++/4.2/ext/pb_ds/detail/list_update_policy missing (created)
./c++/4.2/ext/pb_ds/detail/ov_tree_map_ missing (created)
./c++/4.2/ext/pb_ds/detail/pairing_heap_ missing (created)
./c++/4.2/ext/pb_ds/detail/pat_trie_ missing (created)
./c++/4.2/ext/pb_ds/detail/rb_tree_map_ missing (created)
./c++/4.2/ext/pb_ds/detail/rc_binomial_heap_ missing (created)
./c++/4.2/ext/pb_ds/detail/resize_policy missing (created)
./c++/4.2/ext/pb_ds/detail/splay_tree_ missing (created)
./c++/4.2/ext/pb_ds/detail/thin_heap_ missing (created)
./c++/4.2/ext/pb_ds/detail/tree_policy missing (created)
./c++/4.2/ext/pb_ds/detail/trie_policy missing (created)
./c++/4.2/ext/pb_ds/detail/unordered_iterator missing (created)
./c++/4.2/tr1 missing (created)
./cam missing (created)
./cam/scsi missing (created)
./crypto missing (created)
./dev missing (created)
./dev/acpica missing (created)
./dev/an missing (created)
./dev/bktr missing (created)
./dev/firewire missing (created)
./dev/hwpmc missing (created)
./dev/ic missing (created)
./dev/ieee488 missing (created)
./dev/iicbus missing (created)
./dev/lmc missing (created)
./dev/mpt missing (created)
./dev/mpt/mpilib missing (created)
./dev/ofw missing (created)
./dev/pbio missing (created)
./dev/powermac_nvram missing (created)
./dev/ppbus missing (created)
./dev/smbus missing (created)
./dev/speaker missing (created)
./dev/usb missing (created)
./dev/utopia missing (created)
./dev/vkbd missing (created)
./dev/wi missing (created)
./fs missing (created)
./fs/devfs missing (created)
./fs/fdescfs missing (created)
./fs/fifofs missing (created)
./fs/msdosfs missing (created)
./fs/ntfs missing (created)
./fs/nullfs missing (created)
./fs/nwfs missing (created)
./fs/portalfs missing (created)
./fs/procfs missing (created)
./fs/smbfs missing (created)
./fs/udf missing (created)
./fs/unionfs missing (created)
./geom missing (created)
./geom/cache missing (created)
./geom/concat missing (created)
./geom/eli missing (created)
./geom/gate missing (created)
./geom/journal missing (created)
./geom/label missing (created)
./geom/mirror missing (created)
./geom/multipath missing (created)
./geom/nop missing (created)
./geom/raid3 missing (created)
./geom/shsec missing (created)
./geom/stripe missing (created)
./geom/virstor missing (created)
./gnu missing (created)
./gnu/posix missing (created)
./gpib missing (created)
./gssapi missing (created)
./i4b missing (created)
./isofs missing (created)
./isofs/cd9660 missing (created)
./kadm5 missing (created)
./libmilter missing (created)
./lwres missing (created)
./machine missing (created)
./machine/pc missing (created)
./net missing (created)
./net80211 missing (created)
./netatalk missing (created)
./netgraph missing (created)
./netgraph/atm missing (created)
./netgraph/bluetooth missing (created)
./netgraph/bluetooth/include missing (created)
./netgraph/netflow missing (created)
./netinet missing (created)
./netinet6 missing (created)
./netipsec missing (created)
./netipx missing (created)
./netnatm missing (created)
./netnatm/api missing (created)
./netnatm/msg missing (created)
./netnatm/saal missing (created)
./netnatm/sig missing (created)
./netncp missing (created)
./netsmb missing (created)
./nfs missing (created)
./nfsclient missing (created)
./nfsserver missing (created)
./objc missing (created)
./openssl missing (created)
./pccard missing (created)
./protocols missing (created)
./readline missing (created)
./rpc missing (created)
./rpcsvc missing (created)
./security missing (created)
./security/audit missing (created)
./security/mac_biba missing (created)
./security/mac_bsdextended missing (created)
./security/mac_lomac missing (created)
./security/mac_mls missing (created)
./security/mac_partition missing (created)
./ssp missing (created)
./sys missing (created)
./ufs missing (created)
./ufs/ffs missing (created)
./ufs/ufs missing (created)
./vm missing (created)
mtree -deU  -f /usr/src/etc/mtree/BIND.chroot.dist  -p /var/tmp/temproot/var/named
./dev missing (created)
./etc missing (created)
./etc/namedb missing (created)
./etc/namedb/dynamic missing (created)
./etc/namedb/master missing (created)
./etc/namedb/slave missing (created)
./var missing (created)
./var/dump missing (created)
./var/log missing (created)
./var/run missing (created)
./var/run/named missing (created)
./var/stats missing (created)
mtree -deU  -f /usr/src/etc/mtree/BSD.sendmail.dist -p /var/tmp/temproot/
./var/spool/clientmqueue missing (created)
cd /var/tmp/temproot/; rm -f /var/tmp/temproot/sys; ln -s usr/src/sys sys
cd /var/tmp/temproot/usr/share/man/en.ISO8859-1; ln -sf ../man* .
cd /var/tmp/temproot/usr/share/man;  set - `grep "^[a-zA-Z]" /usr/src/etc/man.alias`;  while [ $# -gt 0 ] ;  do  rm -rf "$1";  ln -s "$2" "$1";  shift; shift;  done
cd /var/tmp/temproot/usr/share/openssl/man;  set - `grep "^[a-zA-Z]" /usr/src/etc/man.alias`;  while [ $# -gt 0 ] ;  do  rm -rf "$1";  ln -s "$2" "$1";  shift; shift;  done
cd /var/tmp/temproot/usr/share/openssl/man/en.ISO8859-1; ln -sf ../man* .
cd /var/tmp/temproot/usr/share/nls;  set - `grep "^[a-zA-Z]" /usr/src/etc/nls.alias`;  while [ $# -gt 0 ] ;  do  rm -rf "$1";  ln -s "$2" "$1";  shift; shift;  done

--------------------------------------------------------------
>>> stage 2.2: rebuilding the object tree
--------------------------------------------------------------
cd /usr/src; MAKEOBJDIRPREFIX=/var/tmp/temproot/usr/obj  MACHINE_ARCH=amd64  MACHINE=amd64  CPUTYPE=  GROFF_BIN_PATH=/var/tmp/temproot/usr/obj/usr/src/tmp/legacy/usr/bin  GROFF_FONT_PATH=/var/tmp/temproot/usr/obj/usr/src/tmp/legacy/usr/share/groff_font  GROFF_TMAC_PATH=/var/tmp/temproot/usr/obj/usr/src/tmp/legacy/usr/share/tmac  _SHLIBDIRPREFIX=/var/tmp/temproot/usr/obj/usr/src/tmp  VERSION="FreeBSD 7.2-PRERELEASE amd64 702100"  INSTALL="sh /usr/src/tools/install.sh"  PATH=/var/tmp/temproot/usr/obj/usr/src/tmp/legacy/usr/sbin:/var/tmp/temproot/usr/obj/usr/src/tmp/legacy/usr/bin:/var/tmp/temproot/usr/obj/usr/src/tmp/legacy/usr/games:/var/tmp/temproot/usr/obj/usr/src/tmp/usr/sbin:/var/tmp/temproot/usr/obj/usr/src/tmp/usr/bin:/var/tmp/temproot/usr/obj/usr/src/tmp/usr/games:/sbin:/bin:/usr/sbin:/usr/bin NO_CTF=1 make -f Makefile.inc1 DESTDIR=/var/tmp/temproot/usr/obj/usr/src/tmp par-obj
===> etc (obj)
/var/tmp/temproot/usr/obj/usr/src/etc created for /usr/src/etc
===> etc/sendmail (obj)
/var/tmp/temproot/usr/obj/usr/src/etc/sendmail created for /usr/src/etc/sendmail

--------------------------------------------------------------
>>> stage 4.4: building everything
--------------------------------------------------------------
cd /usr/src; MAKEOBJDIRPREFIX=/var/tmp/temproot/usr/obj  MACHINE_ARCH=amd64  MACHINE=amd64  CPUTYPE=  GROFF_BIN_PATH=/var/tmp/temproot/usr/obj/usr/src/tmp/legacy/usr/bin  GROFF_FONT_PATH=/var/tmp/temproot/usr/obj/usr/src/tmp/legacy/usr/share/groff_font  GROFF_TMAC_PATH=/var/tmp/temproot/usr/obj/usr/src/tmp/legacy/usr/share/tmac  _SHLIBDIRPREFIX=/var/tmp/temproot/usr/obj/usr/src/tmp  VERSION="FreeBSD 7.2-PRERELEASE amd64 702100"  INSTALL="sh /usr/src/tools/install.sh"  PATH=/var/tmp/temproot/usr/obj/usr/src/tmp/legacy/usr/sbin:/var/tmp/temproot/usr/obj/usr/src/tmp/legacy/usr/bin:/var/tmp/temproot/usr/obj/usr/src/tmp/legacy/usr/games:/var/tmp/temproot/usr/obj/usr/src/tmp/usr/sbin:/var/tmp/temproot/usr/obj/usr/src/tmp/usr/bin:/var/tmp/temproot/usr/obj/usr/src/tmp/usr/games:/sbin:/bin:/usr/sbin:/usr/bin NO_CTF=1 make -f Makefile.inc1 DESTDIR=/var/tmp/temproot/usr/obj/usr/src/tmp par-all
===> etc (all)
===> etc/sendmail (all)
rm -f freebsd.cf
m4 -D_CF_DIR_=/usr/src/etc/sendmail/../../contrib/sendmail/cf/   /usr/src/etc/sendmail/../../contrib/sendmail/cf/m4/cf.m4 /usr/src/etc/sendmail/freebsd.mc > freebsd.cf
chmod 444 freebsd.cf
rm -f freebsd.submit.cf
m4 -D_CF_DIR_=/usr/src/etc/sendmail/../../contrib/sendmail/cf/   /usr/src/etc/sendmail/../../contrib/sendmail/cf/m4/cf.m4 /usr/src/etc/sendmail/freebsd.submit.mc > freebsd.submit.cf
chmod 444 freebsd.submit.cf
cd /usr/src/etc; MAKEOBJDIRPREFIX=/var/tmp/temproot/usr/obj  MACHINE_ARCH=amd64  MACHINE=amd64  CPUTYPE=  GROFF_BIN_PATH=/var/tmp/temproot/usr/obj/usr/src/tmp/legacy/usr/bin  GROFF_FONT_PATH=/var/tmp/temproot/usr/obj/usr/src/tmp/legacy/usr/share/groff_font  GROFF_TMAC_PATH=/var/tmp/temproot/usr/obj/usr/src/tmp/legacy/usr/share/tmac PATH=/var/tmp/temproot/usr/obj/usr/src/tmp/legacy/usr/sbin:/var/tmp/temproot/usr/obj/usr/src/tmp/legacy/usr/bin:/var/tmp/temproot/usr/obj/usr/src/tmp/legacy/usr/games:/var/tmp/temproot/usr/obj/usr/src/tmp/usr/sbin:/var/tmp/temproot/usr/obj/usr/src/tmp/usr/bin:/var/tmp/temproot/usr/obj/usr/src/tmp/usr/games:/sbin:/bin:/usr/sbin:/usr/bin make distribution
cd /usr/src/etc;  install -o root -g wheel -m 644  auth.conf  crontab devd.conf devfs.conf  ddb.conf dhclient.conf disktab fbtab  ftpusers gettytab group  hosts hosts.allow hosts.equiv  inetd.conf libalias.conf login.access login.conf mac.conf motd  netconfig network.subr networks newsyslog.conf nsswitch.conf  phones profile protocols  rc rc.bsdextended rc.firewall rc.firewall6 rc.initdiskless  rc.sendmail rc.shutdown  rc.subr remote rpc services shells  sysctl.conf syslog.conf  etc.amd64/ttys amd.map apmd.conf snmpd.config freebsd-update.conf /usr/src/etc/../usr.bin/locate/locate/locate.rc hosts.lpd printcap /usr/src/etc/../usr.bin/mail/misc/mail.rc /usr/src/etc/../gnu/usr.bin/man/manpath/manpath.config nscd.conf portsnap.conf pf.os csh.cshrc csh.login csh.logout /var/tmp/temproot/etc;  cap_mkdb -l /var/tmp/temproot/etc/login.conf;  install -o root -g wheel -m 755  netstart pccard_ether rc.suspend rc.resume /var/tmp/temproot/etc;  install -o root -g wheel -m 600  master.pass
 wd nsmb.
pwd_mkdb -L -i -p -d /var/tmp/temproot/etc  /var/tmp/temproot/etc/master.passwd
cd /usr/src/etc/bluetooth; make install
install -o root  -g wheel -m 600  hcsecd.conf  /var/tmp/temproot/etc/bluetooth/hcsecd.conf
install -o root  -g wheel -m 644  hosts  /var/tmp/temproot/etc/bluetooth/hosts
install -o root -g wheel  -m 444 protocols /var/tmp/temproot/etc/bluetooth
cd /usr/src/etc/defaults; make install
install -o root -g wheel  -m 444 bluetooth.device.conf devfs.rules pccard.conf periodic.conf rc.conf /var/tmp/temproot/etc/defaults
cd /usr/src/etc/gss; make install
install -o root -g wheel  -m 444 mech qop /var/tmp/temproot/etc/gss
cd /usr/src/etc/periodic; make install
===> daily (install)
install -o root -g wheel  -m 755 100.clean-disks 110.clean-tmps 120.clean-preserve 200.backup-passwd 330.news 400.status-disks 404.status-zfs 405.status-ata-raid 406.status-gmirror 407.status-graid3 408.status-gstripe 409.status-gconcat 420.status-network 450.status-security 999.local 310.accounting 470.status-named 300.calendar 130.clean-msgs 480.status-ntpd 140.clean-rwho 430.status-rwho 150.clean-hoststat 210.backup-aliases 440.status-mailq 460.status-mail-rejects 500.queuerun /var/tmp/temproot/etc/periodic/daily
===> security (install)
install -o root -g wheel  -m 755 100.chksetuid 200.chkmounts 300.chkuid0 400.passwdless 410.logincheck 700.kernelmsg 800.loginfail 900.tcpwrap security.functions 510.ipfdenied 500.ipfwdenied 550.ipfwlimit 520.pfdenied /var/tmp/temproot/etc/periodic/security
===> weekly (install)
install -o root -g wheel  -m 755 340.noid 999.local 310.locate 320.whatis 330.catman 400.status-pkg /var/tmp/temproot/etc/periodic/weekly
===> monthly (install)
install -o root -g wheel  -m 755 999.local 200.accounting /var/tmp/temproot/etc/periodic/monthly
cd /usr/src/etc/rc.d; make install
install -o root -g wheel  -m 555 DAEMON FILESYSTEMS LOGIN NETWORKING SERVERS abi accounting addswap adjkerntz amd apm apmd archdep atm1 atm2 atm3 auditd auto_linklocal bgfsck bluetooth bootparams bridge bsnmpd bthidd ccd cleanvar cleartmp cron ddb devd devfs dhclient dmesg dumpon early.sh encswap fsck ftp-proxy ftpd gbde geli geli2 hcsecd hostapd hostid hostname idmapd inetd initrandom ip6addrctl ip6fw ipfilter ipfs ipfw ipmon ipnat ipsec ipxrouted isdnd jail kadmind kerberos keyserv kldxref kpasswdd ldconfig local localpkg lockd lpd mixer motd mountcritlocal mountcritremote mountlate mdconfig mdconfig2 mountd moused mroute6d mrouted msgs named natd netif netoptions network_ipv6 newsyslog nfsclient nfsd nfsserver nisdomain nsswitch ntpd ntpdate othermta pf pflog pfsync powerd power_profile ppp pppoed pwcheck quota random rarpd resolv rfcomm_pppd_server root route6d routed routing rpcbind rtadvd rwho savecore sdpd securelevel sendmail serial sppp statd swap1 syscons sysctl sys
 logd tim
cd /usr/src/etc/../gnu/usr.bin/send-pr; make etc-gnats-freefall
install -o root -g wheel -m 0644  /usr/src/gnu/usr.bin/send-pr/categories  /var/tmp/temproot/etc/gnats/freefall
cd /usr/src/etc/../share/termcap; make etc-termcap
ln -fs /usr/share/misc/termcap /var/tmp/temproot/etc/termcap
cd /usr/src/etc/../usr.sbin/rmt; make etc-rmt
rm -f /var/tmp/temproot/etc/rmt
ln -s /usr/sbin/rmt /var/tmp/temproot/etc/rmt
cd /usr/src/etc/pam.d; make install
install -o root  -g wheel -m 444  README  /var/tmp/temproot/etc/pam.d/README
install -o root -g wheel  -m 644 atrun cron ftpd gdm imap kde login other passwd pop3 rsh sshd su system telnetd xdm /var/tmp/temproot/etc/pam.d
/var/tmp/temproot/etc/pam.d/ftp -> /var/tmp/temproot/etc/pam.d/ftpd
cd /usr/src/etc; install -o root -g wheel -m 0444  /usr/src/etc/../contrib/openbsm/etc/audit_class  /usr/src/etc/../contrib/openbsm/etc/audit_event /var/tmp/temproot/etc/security
cd /usr/src/etc; install -o root -g wheel -m 0600  /usr/src/etc/../contrib/openbsm/etc/audit_control  /usr/src/etc/../contrib/openbsm/etc/audit_user /var/tmp/temproot/etc/security
cd /usr/src/etc; install -o root -g wheel -m 0500  /usr/src/etc/../contrib/openbsm/etc/audit_warn /var/tmp/temproot/etc/security
cd /usr/src/etc/isdn; make install
install -o root  -g wheel -m 700  answer  /var/tmp/temproot/etc/isdn/answer
install -o root  -g wheel -m 700  isdntel.sh  /var/tmp/temproot/etc/isdn/isdntel
install -o root  -g wheel -m 700  record  /var/tmp/temproot/etc/isdn/record
install -o root  -g wheel -m 700  tell  /var/tmp/temproot/etc/isdn/tell
install -o root  -g wheel -m 700  tell-record  /var/tmp/temproot/etc/isdn/tell-record
install -o root  -g wheel -m 700  unknown_incoming  /var/tmp/temproot/etc/isdn/unknown_incoming
install -o root -g wheel  -m 600 holidays.D isdnd.rates.A isdnd.rates.D isdnd.rates.F isdnd.rates.L isdnd.rates.UK.BT isdnd.rc.sample isdntel.alias.sample /var/tmp/temproot/etc/isdn
+ ln -s ../var/named/etc/namedb /var/tmp/temproot/etc/namedb
cd /usr/src/etc/namedb; make install
install -o root -g wheel  -m 644 named.conf named.root /var/tmp/temproot/etc/namedb
===> master (install)
install -o root -g wheel  -m 644 empty.db localhost-forward.db localhost-reverse.db /var/tmp/temproot/etc/namedb/master
cd /usr/src/etc/sendmail; make distribution
install -o root -g wheel -m 644  /usr/src/etc/sendmail/freebsd.mc freebsd.cf /var/tmp/temproot/etc/mail
install -o root -g wheel -m 444  /usr/src/etc/sendmail/freebsd.submit.mc freebsd.submit.cf /var/tmp/temproot/etc/mail
install -o root -g wheel -m 444  /usr/src/etc/sendmail/../../contrib/sendmail/src/helpfile /var/tmp/temproot/etc/mail
install -o root -g wheel -m 640  /dev/null /var/tmp/temproot/var/log/sendmail.st
install -o root -g wheel -m 644  freebsd.cf /var/tmp/temproot/etc/mail/sendmail.cf
install -o root -g wheel -m 444  freebsd.submit.cf /var/tmp/temproot/etc/mail/submit.cf
cd /usr/src/etc; install -o root -g wheel -m 644  /usr/src/etc/../crypto/openssh/ssh_config  /usr/src/etc/../crypto/openssh/sshd_config  /usr/src/etc/../crypto/openssh/moduli /var/tmp/temproot/etc/ssh
cd /usr/src/etc; install -o root -g wheel -m 644  /usr/src/etc/../crypto/openssl/apps/openssl.cnf /var/tmp/temproot/etc/ssl
cd /usr/src/etc/root;  install -o root -g wheel -m 644  dot.k5login /var/tmp/temproot/root/.k5login;
cd /usr/src/etc/root;  install -o root -g wheel -m 644  dot.profile /var/tmp/temproot/root/.profile;  rm -f /var/tmp/temproot/.profile;  ln /var/tmp/temproot/root/.profile /var/tmp/temproot/.profile
cd /usr/src/etc/root;  install -o root -g wheel -m 644  dot.cshrc /var/tmp/temproot/root/.cshrc;  install -o root -g wheel -m 644  dot.login /var/tmp/temproot/root/.login;  rm -f /var/tmp/temproot/.cshrc;  ln /var/tmp/temproot/root/.cshrc /var/tmp/temproot/.cshrc
cd /usr/src/etc/mtree; install -o root -g wheel -m 444  BSD.include.dist BSD.local.dist BSD.root.dist BSD.usr.dist  BSD.var.dist BSD.x11.dist BSD.x11-4.dist BSD.sendmail.dist BIND.chroot.dist /var/tmp/temproot/etc/mtree
cd /usr/src/etc/ppp; install -o root -g wheel -m 600  ppp.conf /var/tmp/temproot/etc/ppp
cd /usr/src/etc/mail; install -o root -g wheel -m 644  Makefile README mailer.conf access.sample virtusertable.sample  mailertable.sample aliases /var/tmp/temproot/etc/mail
+ ln -s mail/aliases /var/tmp/temproot/etc/aliases
install -o root -g operator -m 664 /dev/null  /var/tmp/temproot/etc/dumpdates
install -o nobody -g wheel -m 644 /dev/null  /var/tmp/temproot/var/db/locate.database
install -o root -g wheel -m 644 /usr/src/etc/minfree  /var/tmp/temproot/var/crash
cd /usr/src/etc/..; install -o root -g wheel -m 444  COPYRIGHT /var/tmp/temproot/
install -o root -g wheel -m 444  /usr/src/etc/../sys/amd64/conf/GENERIC.hints  /var/tmp/temproot/boot/device.hints


*** Beginning comparison

   *** Checking /etc/rc.d for stale files

   *** No stale files found

 *** Temp ./boot/device.hints and installed have the same CVS Id, deleting
 *** Temp ./etc/bluetooth/hcsecd.conf and installed have the same CVS Id, deleting
 *** Temp ./etc/bluetooth/hosts and installed have the same CVS Id, deleting
 *** Temp ./etc/bluetooth/protocols and installed have the same CVS Id, deleting
 *** Temp ./etc/defaults/bluetooth.device.conf and installed have the same CVS Id, deleting
 *** Temp ./etc/defaults/devfs.rules and installed have the same CVS Id, deleting
 *** Temp ./etc/defaults/pccard.conf and installed have the same CVS Id, deleting
 *** Temp ./etc/defaults/periodic.conf and installed have the same CVS Id, deleting
 *** Temp ./etc/defaults/rc.conf and installed have the same CVS Id, deleting
 *** Temp ./etc/gnats/freefall and installed have the same CVS Id, deleting
 *** Temp ./etc/gss/mech and installed have the same CVS Id, deleting
 *** Temp ./etc/gss/qop and installed have the same CVS Id, deleting
 *** Temp ./etc/isdn/answer and installed have the same CVS Id, deleting
 *** Temp ./etc/isdn/isdntel and installed have the same CVS Id, deleting
 *** Temp ./etc/isdn/record and installed have the same CVS Id, deleting
 *** Temp ./etc/isdn/tell and installed have the same CVS Id, deleting
 *** Temp ./etc/isdn/tell-record and installed have the same CVS Id, deleting
 *** Temp ./etc/isdn/unknown_incoming and installed have the same CVS Id, deleting
 *** Temp ./etc/isdn/holidays.D and installed have the same CVS Id, deleting
 *** Temp ./etc/isdn/isdnd.rates.A and installed have the same CVS Id, deleting
 *** Temp ./etc/isdn/isdnd.rates.D and installed have the same CVS Id, deleting
 *** Temp ./etc/isdn/isdnd.rates.F and installed have the same CVS Id, deleting
 *** Temp ./etc/isdn/isdnd.rates.L and installed have the same CVS Id, deleting
 *** Temp ./etc/isdn/isdnd.rates.UK.BT and installed have the same CVS Id, deleting
 *** Temp ./etc/isdn/isdnd.rc.sample and installed have the same CVS Id, deleting
 *** Temp ./etc/isdn/isdntel.alias.sample and installed have the same CVS Id, deleting
 *** Temp ./etc/mail/freebsd.mc and installed have the same CVS Id, deleting
 *** Temp ./etc/mail/freebsd.cf and installed have the same CVS Id, deleting
 *** Temp ./etc/mail/freebsd.submit.mc and installed have the same CVS Id, deleting
 *** Temp ./etc/mail/freebsd.submit.cf and installed have the same CVS Id, deleting
 *** Temp ./etc/mail/helpfile and installed are the same, deleting
 *** Temp ./etc/mail/sendmail.cf and installed have the same CVS Id, deleting
 *** Temp ./etc/mail/submit.cf and installed have the same CVS Id, deleting
 *** Temp ./etc/mail/Makefile and installed have the same CVS Id, deleting
 *** Temp ./etc/mail/README and installed have the same CVS Id, deleting
 *** Temp ./etc/mail/mailer.conf and installed have the same CVS Id, deleting
 *** Temp ./etc/mail/access.sample and installed have the same CVS Id, deleting
 *** Temp ./etc/mail/virtusertable.sample and installed have the same CVS Id, deleting
 *** Temp ./etc/mail/mailertable.sample and installed have the same CVS Id, deleting
 *** Temp ./etc/mail/aliases and installed have the same CVS Id, deleting
 *** Temp ./etc/mtree/BSD.include.dist and installed have the same CVS Id, deleting
 *** Temp ./etc/mtree/BSD.local.dist and installed have the same CVS Id, deleting
 *** Temp ./etc/mtree/BSD.root.dist and installed have the same CVS Id, deleting
 *** Temp ./etc/mtree/BSD.usr.dist and installed have the same CVS Id, deleting
 *** Temp ./etc/mtree/BSD.var.dist and installed have the same CVS Id, deleting
 *** Temp ./etc/mtree/BSD.x11.dist and installed have the same CVS Id, deleting
 *** Temp ./etc/mtree/BSD.x11-4.dist and installed have the same CVS Id, deleting
 *** Temp ./etc/mtree/BSD.sendmail.dist and installed have the same CVS Id, deleting
 *** Temp ./etc/mtree/BIND.chroot.dist and installed have the same CVS Id, deleting
 *** Temp ./etc/pam.d/README and installed have the same CVS Id, deleting
 *** Temp ./etc/pam.d/atrun and installed have the same CVS Id, deleting
 *** Temp ./etc/pam.d/cron and installed have the same CVS Id, deleting
 *** Temp ./etc/pam.d/ftpd and installed have the same CVS Id, deleting
 *** Temp ./etc/pam.d/gdm and installed have the same CVS Id, deleting
 *** Temp ./etc/pam.d/imap and installed have the same CVS Id, deleting
 *** Temp ./etc/pam.d/kde and installed have the same CVS Id, deleting
 *** Temp ./etc/pam.d/login and installed have the same CVS Id, deleting
 *** Temp ./etc/pam.d/other and installed have the same CVS Id, deleting
 *** Temp ./etc/pam.d/passwd and installed have the same CVS Id, deleting
 *** Temp ./etc/pam.d/pop3 and installed have the same CVS Id, deleting
 *** Temp ./etc/pam.d/rsh and installed have the same CVS Id, deleting
 *** Temp ./etc/pam.d/sshd and installed have the same CVS Id, deleting
 *** Temp ./etc/pam.d/su and installed have the same CVS Id, deleting
 *** Temp ./etc/pam.d/system and installed have the same CVS Id, deleting
 *** Temp ./etc/pam.d/telnetd and installed have the same CVS Id, deleting
 *** Temp ./etc/pam.d/xdm and installed have the same CVS Id, deleting
 *** Temp ./etc/pam.d/ftp and installed have the same CVS Id, deleting
 *** Temp ./etc/periodic/daily/100.clean-disks and installed have the same CVS Id, deleting
 *** Temp ./etc/periodic/daily/110.clean-tmps and installed have the same CVS Id, deleting
 *** Temp ./etc/periodic/daily/120.clean-preserve and installed have the same CVS Id, deleting
 *** Temp ./etc/periodic/daily/200.backup-passwd and installed have the same CVS Id, deleting
 *** Temp ./etc/periodic/daily/330.news and installed have the same CVS Id, deleting
 *** Temp ./etc/periodic/daily/400.status-disks and installed have the same CVS Id, deleting
 *** Temp ./etc/periodic/daily/404.status-zfs and installed have the same CVS Id, deleting
 *** Temp ./etc/periodic/daily/405.status-ata-raid and installed have the same CVS Id, deleting
 *** Temp ./etc/periodic/daily/406.status-gmirror and installed have the same CVS Id, deleting
 *** Temp ./etc/periodic/daily/407.status-graid3 and installed have the same CVS Id, deleting
 *** Temp ./etc/periodic/daily/408.status-gstripe and installed have the same CVS Id, deleting
 *** Temp ./etc/periodic/daily/409.status-gconcat and installed have the same CVS Id, deleting
 *** Temp ./etc/periodic/daily/420.status-network and installed have the same CVS Id, deleting
 *** Temp ./etc/periodic/daily/450.status-security and installed have the same CVS Id, deleting
 *** Temp ./etc/periodic/daily/999.local and installed have the same CVS Id, deleting
 *** Temp ./etc/periodic/daily/310.accounting and installed have the same CVS Id, deleting
 *** Temp ./etc/periodic/daily/470.status-named and installed have the same CVS Id, deleting
 *** Temp ./etc/periodic/daily/300.calendar and installed have the same CVS Id, deleting
 *** Temp ./etc/periodic/daily/130.clean-msgs and installed have the same CVS Id, deleting
 *** Temp ./etc/periodic/daily/480.status-ntpd and installed have the same CVS Id, deleting
 *** Temp ./etc/periodic/daily/140.clean-rwho and installed have the same CVS Id, deleting
 *** Temp ./etc/periodic/daily/430.status-rwho and installed have the same CVS Id, deleting
 *** Temp ./etc/periodic/daily/150.clean-hoststat and installed have the same CVS Id, deleting
 *** Temp ./etc/periodic/daily/210.backup-aliases and installed have the same CVS Id, deleting
 *** Temp ./etc/periodic/daily/440.status-mailq and installed have the same CVS Id, deleting
 *** Temp ./etc/periodic/daily/460.status-mail-rejects and installed have the same CVS Id, deleting
 *** Temp ./etc/periodic/daily/500.queuerun and installed have the same CVS Id, deleting
 *** Temp ./etc/periodic/monthly/999.local and installed have the same CVS Id, deleting
 *** Temp ./etc/periodic/monthly/200.accounting and installed have the same CVS Id, deleting
 *** Temp ./etc/periodic/security/100.chksetuid and installed have the same CVS Id, deleting
 *** Temp ./etc/periodic/security/200.chkmounts and installed have the same CVS Id, deleting
 *** Temp ./etc/periodic/security/300.chkuid0 and installed have the same CVS Id, deleting
 *** Temp ./etc/periodic/security/400.passwdless and installed have the same CVS Id, deleting
 *** Temp ./etc/periodic/security/410.logincheck and installed have the same CVS Id, deleting
 *** Temp ./etc/periodic/security/700.kernelmsg and installed have the same CVS Id, deleting
 *** Temp ./etc/periodic/security/800.loginfail and installed have the same CVS Id, deleting
 *** Temp ./etc/periodic/security/900.tcpwrap and installed have the same CVS Id, deleting
 *** Temp ./etc/periodic/security/security.functions and installed have the same CVS Id, deleting
 *** Temp ./etc/periodic/security/510.ipfdenied and installed have the same CVS Id, deleting
 *** Temp ./etc/periodic/security/500.ipfwdenied and installed have the same CVS Id, deleting
 *** Temp ./etc/periodic/security/550.ipfwlimit and installed have the same CVS Id, deleting
 *** Temp ./etc/periodic/security/520.pfdenied and installed have the same CVS Id, deleting
 *** Temp ./etc/periodic/weekly/340.noid and installed have the same CVS Id, deleting
 *** Temp ./etc/periodic/weekly/999.local and installed have the same CVS Id, deleting
 *** Temp ./etc/periodic/weekly/310.locate and installed have the same CVS Id, deleting
 *** Temp ./etc/periodic/weekly/320.whatis and installed have the same CVS Id, deleting
 *** Temp ./etc/periodic/weekly/330.catman and installed have the same CVS Id, deleting
 *** Temp ./etc/periodic/weekly/400.status-pkg and installed have the same CVS Id, deleting
 *** Temp ./etc/ppp/ppp.conf and installed have the same CVS Id, deleting
 *** Temp ./etc/rc.d/DAEMON and installed have the same CVS Id, deleting
 *** Temp ./etc/rc.d/FILESYSTEMS and installed have the same CVS Id, deleting
 *** Temp ./etc/rc.d/LOGIN and installed have the same CVS Id, deleting
 *** Temp ./etc/rc.d/NETWORKING and installed have the same CVS Id, deleting
 *** Temp ./etc/rc.d/SERVERS and installed have the same CVS Id, deleting
 *** Temp ./etc/rc.d/abi and installed have the same CVS Id, deleting
 *** Temp ./etc/rc.d/accounting and installed have the same CVS Id, deleting
 *** Temp ./etc/rc.d/addswap and installed have the same CVS Id, deleting
 *** Temp ./etc/rc.d/adjkerntz and installed have the same CVS Id, deleting
 *** Temp ./etc/rc.d/amd and installed have the same CVS Id, deleting
 *** Temp ./etc/rc.d/apm and installed have the same CVS Id, deleting
 *** Temp ./etc/rc.d/apmd and installed have the same CVS Id, deleting
 *** Temp ./etc/rc.d/archdep and installed have the same CVS Id, deleting
 *** Temp ./etc/rc.d/atm1 and installed have the same CVS Id, deleting
 *** Temp ./etc/rc.d/atm2 and installed have the same CVS Id, deleting
 *** Temp ./etc/rc.d/atm3 and installed have the same CVS Id, deleting
 *** Temp ./etc/rc.d/auditd and installed have the same CVS Id, deleting
 *** Temp ./etc/rc.d/auto_linklocal and installed have the same CVS Id, deleting
 *** Temp ./etc/rc.d/bgfsck and installed have the same CVS Id, deleting
 *** Temp ./etc/rc.d/bluetooth and installed have the same CVS Id, deleting
 *** Temp ./etc/rc.d/bootparams and installed have the same CVS Id, deleting
 *** Temp ./etc/rc.d/bridge and installed have the same CVS Id, deleting
 *** Temp ./etc/rc.d/bsnmpd and installed have the same CVS Id, deleting
 *** Temp ./etc/rc.d/bthidd and installed have the same CVS Id, deleting
 *** Temp ./etc/rc.d/ccd and installed have the same CVS Id, deleting
 *** Temp ./etc/rc.d/cleanvar and installed have the same CVS Id, deleting
 *** Temp ./etc/rc.d/cleartmp and installed have the same CVS Id, deleting
 *** Temp ./etc/rc.d/cron and installed have the same CVS Id, deleting
 *** Temp ./etc/rc.d/ddb and installed have the same CVS Id, deleting
 *** Temp ./etc/rc.d/devd and installed have the same CVS Id, deleting
 *** Temp ./etc/rc.d/devfs and installed have the same CVS Id, deleting
 *** Temp ./etc/rc.d/dhclient and installed have the same CVS Id, deleting
 *** Temp ./etc/rc.d/dmesg and installed have the same CVS Id, deleting
 *** Temp ./etc/rc.d/dumpon and installed have the same CVS Id, deleting
 *** Temp ./etc/rc.d/early.sh and installed have the same CVS Id, deleting
 *** Temp ./etc/rc.d/encswap and installed have the same CVS Id, deleting
 *** Temp ./etc/rc.d/fsck and installed have the same CVS Id, deleting
 *** Temp ./etc/rc.d/ftp-proxy and installed have the same CVS Id, deleting
 *** Temp ./etc/rc.d/ftpd and installed have the same CVS Id, deleting
 *** Temp ./etc/rc.d/gbde and installed have the same CVS Id, deleting
 *** Temp ./etc/rc.d/geli and installed have the same CVS Id, deleting
 *** Temp ./etc/rc.d/geli2 and installed have the same CVS Id, deleting
 *** Temp ./etc/rc.d/hcsecd and installed have the same CVS Id, deleting
 *** Temp ./etc/rc.d/hostapd and installed have the same CVS Id, deleting
 *** Temp ./etc/rc.d/hostid and installed have the same CVS Id, deleting
 *** Temp ./etc/rc.d/hostname and installed have the same CVS Id, deleting
 *** Temp ./etc/rc.d/idmapd and installed have the same CVS Id, deleting
 *** Temp ./etc/rc.d/inetd and installed have the same CVS Id, deleting
 *** Temp ./etc/rc.d/initrandom and installed have the same CVS Id, deleting
 *** Temp ./etc/rc.d/ip6addrctl and installed have the same CVS Id, deleting
 *** Temp ./etc/rc.d/ip6fw and installed have the same CVS Id, deleting
 *** Temp ./etc/rc.d/ipfilter and installed have the same CVS Id, deleting
 *** Temp ./etc/rc.d/ipfs and installed have the same CVS Id, deleting
 *** Temp ./etc/rc.d/ipfw and installed have the same CVS Id, deleting
 *** Temp ./etc/rc.d/ipmon and installed have the same CVS Id, deleting
 *** Temp ./etc/rc.d/ipnat and installed have the same CVS Id, deleting
 *** Temp ./etc/rc.d/ipsec and installed have the same CVS Id, deleting
 *** Temp ./etc/rc.d/ipxrouted and installed have the same CVS Id, deleting
 *** Temp ./etc/rc.d/isdnd and installed have the same CVS Id, deleting
 *** Temp ./etc/rc.d/jail and installed have the same CVS Id, deleting
 *** Temp ./etc/rc.d/kadmind and installed have the same CVS Id, deleting
 *** Temp ./etc/rc.d/kerberos and installed have the same CVS Id, deleting
 *** Temp ./etc/rc.d/keyserv and installed have the same CVS Id, deleting
 *** Temp ./etc/rc.d/kldxref and installed have the same CVS Id, deleting
 *** Temp ./etc/rc.d/kpasswdd and installed have the same CVS Id, deleting
 *** Temp ./etc/rc.d/ldconfig and installed have the same CVS Id, deleting
 *** Temp ./etc/rc.d/local and installed have the same CVS Id, deleting
 *** Temp ./etc/rc.d/localpkg and installed have the same CVS Id, deleting
 *** Temp ./etc/rc.d/lockd and installed have the same CVS Id, deleting
 *** Temp ./etc/rc.d/lpd and installed have the same CVS Id, deleting
 *** Temp ./etc/rc.d/mixer and installed have the same CVS Id, deleting
 *** Temp ./etc/rc.d/motd and installed have the same CVS Id, deleting
 *** Temp ./etc/rc.d/mountcritlocal and installed have the same CVS Id, deleting
 *** Temp ./etc/rc.d/mountcritremote and installed have the same CVS Id, deleting
 *** Temp ./etc/rc.d/mountlate and installed have the same CVS Id, deleting
 *** Temp ./etc/rc.d/mdconfig and installed have the same CVS Id, deleting
 *** Temp ./etc/rc.d/mdconfig2 and installed have the same CVS Id, deleting
 *** Temp ./etc/rc.d/mountd and installed have the same CVS Id, deleting
 *** Temp ./etc/rc.d/moused and installed have the same CVS Id, deleting
 *** Temp ./etc/rc.d/mroute6d and installed have the same CVS Id, deleting
 *** Temp ./etc/rc.d/mrouted and installed have the same CVS Id, deleting
 *** Temp ./etc/rc.d/msgs and installed have the same CVS Id, deleting
 *** Temp ./etc/rc.d/named and installed have the same CVS Id, deleting
 *** Temp ./etc/rc.d/natd and installed have the same CVS Id, deleting
 *** Temp ./etc/rc.d/netif and installed have the same CVS Id, deleting
 *** Temp ./etc/rc.d/netoptions and installed have the same CVS Id, deleting
 *** Temp ./etc/rc.d/network_ipv6 and installed have the same CVS Id, deleting
 *** Temp ./etc/rc.d/newsyslog and installed have the same CVS Id, deleting
 *** Temp ./etc/rc.d/nfsclient and installed have the same CVS Id, deleting
 *** Temp ./etc/rc.d/nfsd and installed have the same CVS Id, deleting
 *** Temp ./etc/rc.d/nfsserver and installed have the same CVS Id, deleting
 *** Temp ./etc/rc.d/nisdomain and installed have the same CVS Id, deleting
 *** Temp ./etc/rc.d/nsswitch and installed have the same CVS Id, deleting
 *** Temp ./etc/rc.d/ntpd and installed have the same CVS Id, deleting
 *** Temp ./etc/rc.d/ntpdate and installed have the same CVS Id, deleting
 *** Temp ./etc/rc.d/othermta and installed have the same CVS Id, deleting
 *** Temp ./etc/rc.d/pf and installed have the same CVS Id, deleting
 *** Temp ./etc/rc.d/pflog and installed have the same CVS Id, deleting
 *** Temp ./etc/rc.d/pfsync and installed have the same CVS Id, deleting
 *** Temp ./etc/rc.d/powerd and installed have the same CVS Id, deleting
 *** Temp ./etc/rc.d/power_profile and installed have the same CVS Id, deleting
 *** Temp ./etc/rc.d/ppp and installed have the same CVS Id, deleting
 *** Temp ./etc/rc.d/pppoed and installed have the same CVS Id, deleting
 *** Temp ./etc/rc.d/pwcheck and installed have the same CVS Id, deleting
 *** Temp ./etc/rc.d/quota and installed have the same CVS Id, deleting
 *** Temp ./etc/rc.d/random and installed have the same CVS Id, deleting
 *** Temp ./etc/rc.d/rarpd and installed have the same CVS Id, deleting
 *** Temp ./etc/rc.d/resolv and installed have the same CVS Id, deleting
 *** Temp ./etc/rc.d/rfcomm_pppd_server and installed have the same CVS Id, deleting
 *** Temp ./etc/rc.d/root and installed have the same CVS Id, deleting
 *** Temp ./etc/rc.d/route6d and installed have the same CVS Id, deleting
 *** Temp ./etc/rc.d/routed and installed have the same CVS Id, deleting
 *** Temp ./etc/rc.d/routing and installed have the same CVS Id, deleting
 *** Temp ./etc/rc.d/rpcbind and installed have the same CVS Id, deleting
 *** Temp ./etc/rc.d/rtadvd and installed have the same CVS Id, deleting
 *** Temp ./etc/rc.d/rwho and installed have the same CVS Id, deleting
 *** Temp ./etc/rc.d/tmp and installed have the same CVS Id, deleting
 *** Temp ./etc/rc.d/savecore and installed have the same CVS Id, deleting
 *** Temp ./etc/rc.d/sdpd and installed have the same CVS Id, deleting
 *** Temp ./etc/rc.d/securelevel and installed have the same CVS Id, deleting
 *** Temp ./etc/rc.d/sendmail and installed have the same CVS Id, deleting
 *** Temp ./etc/rc.d/serial and installed have the same CVS Id, deleting
 *** Temp ./etc/rc.d/sppp and installed have the same CVS Id, deleting
 *** Temp ./etc/rc.d/statd and installed have the same CVS Id, deleting
 *** Temp ./etc/rc.d/swap1 and installed have the same CVS Id, deleting
 *** Temp ./etc/rc.d/syscons and installed have the same CVS Id, deleting
 *** Temp ./etc/rc.d/sysctl and installed have the same CVS Id, deleting
 *** Temp ./etc/rc.d/syslogd and installed have the same CVS Id, deleting
 *** Temp ./etc/rc.d/timed and installed have the same CVS Id, deleting
 *** Temp ./etc/rc.d/ugidfw and installed have the same CVS Id, deleting
 *** Temp ./etc/rc.d/var and installed have the same CVS Id, deleting
 *** Temp ./etc/rc.d/virecover and installed have the same CVS Id, deleting
 *** Temp ./etc/rc.d/watchdogd and installed have the same CVS Id, deleting
 *** Temp ./etc/rc.d/wpa_supplicant and installed have the same CVS Id, deleting
 *** Temp ./etc/rc.d/ypbind and installed have the same CVS Id, deleting
 *** Temp ./etc/rc.d/yppasswdd and installed have the same CVS Id, deleting
 *** Temp ./etc/rc.d/ypserv and installed have the same CVS Id, deleting
 *** Temp ./etc/rc.d/ypset and installed have the same CVS Id, deleting
 *** Temp ./etc/rc.d/ypupdated and installed have the same CVS Id, deleting
 *** Temp ./etc/rc.d/ypxfrd and installed have the same CVS Id, deleting
 *** Temp ./etc/rc.d/zfs and installed have the same CVS Id, deleting
 *** Temp ./etc/rc.d/sshd and installed have the same CVS Id, deleting
 *** Temp ./etc/rc.d/nscd and installed have the same CVS Id, deleting
 *** Temp ./etc/security/audit_class and installed have the same CVS Id, deleting
 *** Temp ./etc/security/audit_event and installed have the same CVS Id, deleting
 *** Temp ./etc/security/audit_control and installed have the same CVS Id, deleting
 *** Temp ./etc/security/audit_user and installed have the same CVS Id, deleting
 *** Temp ./etc/security/audit_warn and installed have the same CVS Id, deleting
 *** Temp ./etc/ssh/ssh_config and installed have the same CVS Id, deleting
 *** Temp ./etc/ssh/sshd_config and installed have the same CVS Id, deleting
 *** Temp ./etc/ssh/moduli and installed are the same, deleting
 *** Temp ./etc/ssl/openssl.cnf and installed have the same CVS Id, deleting
 *** Temp ./etc/auth.conf and installed have the same CVS Id, deleting
 *** Temp ./etc/crontab and installed have the same CVS Id, deleting
 *** Temp ./etc/devd.conf and installed have the same CVS Id, deleting
 *** Temp ./etc/devfs.conf and installed have the same CVS Id, deleting
 *** Temp ./etc/ddb.conf and installed have the same CVS Id, deleting
 *** Temp ./etc/dhclient.conf and installed have the same CVS Id, deleting
 *** Temp ./etc/disktab and installed have the same CVS Id, deleting
 *** Temp ./etc/fbtab and installed have the same CVS Id, deleting
 *** Temp ./etc/ftpusers and installed have the same CVS Id, deleting
 *** Temp ./etc/gettytab and installed have the same CVS Id, deleting
 *** Temp ./etc/group and installed have the same CVS Id, deleting
 *** Temp ./etc/hosts and installed have the same CVS Id, deleting
 *** Temp ./etc/hosts.allow and installed have the same CVS Id, deleting
 *** Temp ./etc/hosts.equiv and installed have the same CVS Id, deleting
 *** Temp ./etc/inetd.conf and installed have the same CVS Id, deleting
 *** Temp ./etc/libalias.conf and installed have the same CVS Id, deleting
 *** Temp ./etc/login.access and installed have the same CVS Id, deleting
 *** Temp ./etc/login.conf and installed have the same CVS Id, deleting
 *** Temp ./etc/mac.conf and installed have the same CVS Id, deleting

  *** ./etc/motd has not been user modified.

   *** ./etc/motd upgraded successfully

 *** Temp ./etc/netconfig and installed have the same CVS Id, deleting
 *** Temp ./etc/network.subr and installed have the same CVS Id, deleting
 *** Temp ./etc/networks and installed have the same CVS Id, deleting
 *** Temp ./etc/newsyslog.conf and installed have the same CVS Id, deleting
 *** Temp ./etc/nsswitch.conf and installed have the same CVS Id, deleting
 *** Temp ./etc/phones and installed have the same CVS Id, deleting
 *** Temp ./etc/profile and installed have the same CVS Id, deleting
 *** Temp ./etc/protocols and installed have the same CVS Id, deleting
 *** Temp ./etc/rc and installed have the same CVS Id, deleting
 *** Temp ./etc/rc.bsdextended and installed have the same CVS Id, deleting
 *** Temp ./etc/rc.firewall and installed have the same CVS Id, deleting
 *** Temp ./etc/rc.firewall6 and installed have the same CVS Id, deleting
 *** Temp ./etc/rc.initdiskless and installed have the same CVS Id, deleting
 *** Temp ./etc/rc.sendmail and installed have the same CVS Id, deleting
 *** Temp ./etc/rc.shutdown and installed have the same CVS Id, deleting
 *** Temp ./etc/rc.subr and installed have the same CVS Id, deleting
 *** Temp ./etc/remote and installed have the same CVS Id, deleting
 *** Temp ./etc/rpc and installed have the same CVS Id, deleting
 *** Temp ./etc/services and installed have the same CVS Id, deleting
 *** Temp ./etc/shells and installed have the same CVS Id, deleting
 *** Temp ./etc/sysctl.conf and installed have the same CVS Id, deleting
 *** Temp ./etc/syslog.conf and installed have the same CVS Id, deleting
 *** Temp ./etc/ttys and installed have the same CVS Id, deleting
 *** Temp ./etc/amd.map and installed have the same CVS Id, deleting
 *** Temp ./etc/apmd.conf and installed have the same CVS Id, deleting
 *** Temp ./etc/snmpd.config and installed have the same CVS Id, deleting
 *** Temp ./etc/freebsd-update.conf and installed have the same CVS Id, deleting
 *** Temp ./etc/locate.rc and installed have the same CVS Id, deleting
 *** Temp ./etc/hosts.lpd and installed have the same CVS Id, deleting
 *** Temp ./etc/printcap and installed have the same CVS Id, deleting
 *** Temp ./etc/mail.rc and installed are the same, deleting
 *** Temp ./etc/manpath.config and installed have the same CVS Id, deleting
 *** Temp ./etc/nscd.conf and installed have the same CVS Id, deleting
 *** Temp ./etc/portsnap.conf and installed have the same CVS Id, deleting
 *** Temp ./etc/pf.os and installed have the same CVS Id, deleting
 *** Temp ./etc/csh.cshrc and installed have the same CVS Id, deleting
 *** Temp ./etc/csh.login and installed have the same CVS Id, deleting
 *** Temp ./etc/csh.logout and installed have the same CVS Id, deleting
 *** Temp ./etc/netstart and installed have the same CVS Id, deleting
 *** Temp ./etc/pccard_ether and installed have the same CVS Id, deleting
 *** Temp ./etc/rc.suspend and installed have the same CVS Id, deleting
 *** Temp ./etc/rc.resume and installed have the same CVS Id, deleting
 *** Temp ./etc/master.passwd and installed have the same CVS Id, deleting
 *** Temp ./etc/nsmb.conf and installed have the same CVS Id, deleting
 *** Temp ./etc/opieaccess and installed have the same CVS Id, deleting
 *** Temp ./root/.k5login and installed have the same CVS Id, deleting
 *** Temp ./root/.profile and installed have the same CVS Id, deleting
 *** Temp ./root/.cshrc and installed have the same CVS Id, deleting
 *** Temp ./root/.login and installed have the same CVS Id, deleting
 *** Temp ./var/crash/minfree and installed are the same, deleting
 *** Temp ./var/named/etc/namedb/master/empty.db and installed have the same CVS Id, deleting
 *** Temp ./var/named/etc/namedb/master/localhost-forward.db and installed have the same CVS Id, deleting
 *** Temp ./var/named/etc/namedb/master/localhost-reverse.db and installed have the same CVS Id, deleting
 *** Temp ./var/named/etc/namedb/named.conf and installed have the same CVS Id, deleting
 *** Temp ./var/named/etc/namedb/named.root and installed have the same CVS Id, deleting
 *** Temp ./.profile and installed have the same CVS Id, deleting
 *** Temp ./.cshrc and installed have the same CVS Id, deleting
 *** Temp ./COPYRIGHT and installed have the same CVS Id, deleting

*** Comparison complete
*** Saving mtree database for future upgrades

Do you wish to delete what is left of /var/tmp/temproot? [no] yes
 *** /var/tmp/temproot has been deleted

*** You chose the automatic upgrade option for files that you did
    not alter on your system.  The following were upgraded for you:
      /etc/motd


root@kg-quiet# ^D
Script done on Mon May  4 23:55:07 2009
From torfinn.ingolfsen at broadpark.no  Mon May  4 22:34:07 2009
From: torfinn.ingolfsen at broadpark.no (Torfinn Ingolfsen)
Date: Mon May  4 22:34:14 2009
Subject: RELENG_7 - has mergemaster changed logic since 7.2-RELEASE?
In-Reply-To: <49FF5D9C.5060409@unsane.co.uk>
References: <20090504225012.392fa49f.torfinn.ingolfsen@broadpark.no>
	<49FF5D9C.5060409@unsane.co.uk>
Message-ID: <20090505003405.52398ad2.torfinn.ingolfsen@broadpark.no>

On Mon, 04 May 2009 22:26:52 +0100
Vincent Hoffman <vince@unsane.co.uk> wrote:

> Not that its a cure but are master.passwd and group backups in
> /var/backups any help to you in this case?

Ah - great tip - thanks!
(In case of the first server, the changes to group and passwd files were
few, so I just re-did the changes from memory. The only part I had to
look up was user and group mysql. So restoring from /var/backups would
have been quicker.)
-- 
Regards, 
Torfinn Ingolfsen

From yaol.leo at gmail.com  Tue May  5 02:39:29 2009
From: yaol.leo at gmail.com (Leo)
Date: Tue May  5 02:39:36 2009
Subject: Help! regarding libpcap.
In-Reply-To: <49FF12A0.3010009@incunabulum.net>
References: <49FEC0AD.7090506@gmail.com> <49FF014F.7070107@incunabulum.net>
	<49FF09E1.5010306@gmail.com> <49FF12A0.3010009@incunabulum.net>
Message-ID: <49FFA6D8.7090508@gmail.com>

Bruce Simpson wrote:
> Leo wrote:
>>
>> I don't have other pcap lib installed on this box. Previously 
>> installed a libpcap 0.9 on this box , But I've deleted this version. 
>> On my box, not enable BPF. Let me try if enable the feature.
>
> That's probably what it is. Can you try the following:
> * give pcap configure --with-pcap=bpf WITHOUT having bpf in your 
> kernel config.
> * try enabling bpf in kernel config and building the port as usual.
>
> Most likely libpcap's new configure script is detecting the lack of 
> /dev/bpf* and assuming there is no packet capture support in the 
> system. This needs to be fixed for cross compiling to be possible. If 
> you could try at least the first fix then this is the answer.
>
> thanks,
> BMS
>
>
Hi Bruce,
I've tried 2 method on my box. that you previously mentioned.  Both of 
these 2 method can build successfully! Thank your for your help!!

Best Regards!
-Leo
From pluknet at gmail.com  Tue May  5 03:41:38 2009
From: pluknet at gmail.com (pluknet)
Date: Tue May  5 03:41:49 2009
Subject: lock up in 6.2 (procs massively stuck in Giant)
In-Reply-To: <200905010949.45927.jhb@freebsd.org>
References: <a31046fc0904292336w17aca317hefd32dad5bc28007@mail.gmail.com>
	<200905010949.45927.jhb@freebsd.org>
Message-ID: <a31046fc0905042041kdfcfa85u38e84db5197c929c@mail.gmail.com>

2009/5/1 John Baldwin <jhb@freebsd.org>:
> On Thursday 30 April 2009 2:36:34 am pluknet wrote:
>> Hi folks.
>>
>> Today I got a new locking issue.
>> This is the first time I got it, and it's merely reproduced.
>>
>> The box has lost both remote connection and local access.
>> No SIGINFO output on the local console even.
>> Jumping in ddb> shows the next:
>>
>> 1) first, this is a 8-way web server. No processes on runqueue except one
> httpd
>> (i.e. ps shows R in its state):
>
> You need to find who owns Giant and what that thread is doing.  You can try
> using 'show lock Giant' as well as 'show lockchain 11568'.
>

Hi, John!

Just reproduced now on another box.
Hmm.. stack of the process owing Giant looks garbled.

db> show lock Giant
 class: sleep mutex
 name: Giant
 flags: {DEF, RECURSE}
 state: {OWNED, CONTESTED}
 owner: 0xd0d79320 (tid 102754, pid 34594, "httpd")

db> show lockchain 34594
thread 102754 (pid 34594, httpd) running on CPU 7
db> show lockchain 102754
thread 102754 (pid 34594, httpd) running on CPU 7
db> bt 102754
Tracing pid 34594 tid 102754 td 0xd0d79320
sched_switch(2,2,1,f1a3fb3c,c08a55d9,...) at sched_switch+0x143
MAXCPU(e5895590,62e85356,e8000110,ffffa3d5,ffb988e8,...) at 0xf7
*** error reading from address f8658d94 ***

What can I do else?

db> show allpcpu
Current CPU: 1

cpuid        = 0
curthread    = 0xcd963960: pid 95678 "httpd"
curpcb       = 0xf0593d90
fpcurthread  = none
idlethread   = 0xc7cfeaf0: pid 17 "idle: cpu0"
APIC ID      = 0
currentldt   = 0x50

cpuid        = 1
curthread    = 0xc7dfaaf0: pid 40 "swi0: sio"
curpcb       = 0xe82ebd90
fpcurthread  = none
idlethread   = 0xc7cfe000: pid 16 "idle: cpu1"
APIC ID      = 1
currentldt   = 0x50

cpuid        = 2
curthread    = 0xca8aa640: pid 31167 "httpd"
curpcb       = 0xf1279d90
fpcurthread  = none
idlethread   = 0xc7cfde10: pid 15 "idle: cpu2"
APIC ID      = 2
currentldt   = 0x50

cpuid        = 3
curthread    = 0xc8b62e10: pid 17221 "httpd"
curpcb       = 0xee951d90
fpcurthread  = none
idlethread   = 0xc7cfdc80: pid 14 "idle: cpu3"
APIC ID      = 3
currentldt   = 0x50

cpuid        = 4
curthread    = 0xca1f2c80: pid 39078 "httpd"
curpcb       = 0xeec17d90
fpcurthread  = none
idlethread   = 0xc7cfdaf0: pid 13 "idle: cpu4"
APIC ID      = 4
currentldt   = 0x50

cpuid        = 5
curthread    = 0xcd423af0: pid 74960 "httpd"
curpcb       = 0xf03f2d90
fpcurthread  = none
idlethread   = 0xc7cfd960: pid 12 "idle: cpu5"
APIC ID      = 5
currentldt   = 0x50

cpuid        = 6
curthread    = 0xcaa89c80: pid 23426 "httpd"
curpcb       = 0xef1aed90
fpcurthread  = none
idlethread   = 0xc7cfd7d0: pid 11 "idle: cpu6"
APIC ID      = 6
currentldt   = 0x50

cpuid        = 7
curthread    = 0xd0d79320: pid 34594 "httpd"
curpcb       = 0xf1a3fd90
fpcurthread  = none
idlethread   = 0xc7cfd640: pid 10 "idle: cpu7"
APIC ID      = 7
currentldt   = 0x50



-- 
wbr,
pluknet
From david at usermode.org  Tue May  5 03:47:14 2009
From: david at usermode.org (David Johnson)
Date: Tue May  5 03:47:21 2009
Subject: Xorg hangs with drmwtq in 7.2-RELEASE
Message-ID: <200905042015.29394.david@usermode.org>

This topic has been recently discussed twice before in the past month and a 
half, but without resolution. It now reappears on my system as I upgrade to 
7.2-RELEASE. It does not happen with a build from RELENG_7 date=2009.03.13. I 
am desperately hoping for a resolution.

To reiterate the problem: Xorg will occassionally hang. This only happens when 
compositing it enabled. I am using KDE 4.2.2, radeon driver, all ports updated 
to this morning. About a third of the time the kernel locks up, and I cannot 
ssh into the system. The other half of the time I can ssh into the system. 
There I notice that Xorg has the state of "drmwtq", with perhaps some other 
GUI processes in the same state.

The video card is a Radeon X1550. I have tried with and without AGPMode set, 
and both XAA and EXA render modes. No change.

You can look at my xorg.conf and Xorg log at:
http://www.usermode.org/misc/xorg.conf
http://www.usermode.org/misc/Xorg.0.log.old

p.s. Posting to freebsd-stable, as this problem has been previously discussed 
here. If this is no longer the appropriate list, please let me know.

Thank you,

-- 
David Johnson
From rnoland at FreeBSD.org  Tue May  5 06:20:37 2009
From: rnoland at FreeBSD.org (Robert Noland)
Date: Tue May  5 06:20:44 2009
Subject: Xorg hangs with drmwtq in 7.2-RELEASE
In-Reply-To: <200905042015.29394.david@usermode.org>
References: <200905042015.29394.david@usermode.org>
Message-ID: <1241504417.1828.19.camel@balrog.2hip.net>

On Mon, 2009-05-04 at 20:15 -0700, David Johnson wrote:
> This topic has been recently discussed twice before in the past month and a 
> half, but without resolution. It now reappears on my system as I upgrade to 
> 7.2-RELEASE. It does not happen with a build from RELENG_7 date=2009.03.13. I 
> am desperately hoping for a resolution.
> 
> To reiterate the problem: Xorg will occassionally hang. This only happens when 
> compositing it enabled. I am using KDE 4.2.2, radeon driver, all ports updated 
> to this morning. About a third of the time the kernel locks up, and I cannot 
> ssh into the system. The other half of the time I can ssh into the system. 
> There I notice that Xorg has the state of "drmwtq", with perhaps some other 
> GUI processes in the same state.
> 
> The video card is a Radeon X1550. I have tried with and without AGPMode set, 
> and both XAA and EXA render modes. No change.
> 
> You can look at my xorg.conf and Xorg log at:
> http://www.usermode.org/misc/xorg.conf
> http://www.usermode.org/misc/Xorg.0.log.old
> 
> p.s. Posting to freebsd-stable, as this problem has been previously discussed 
> here. If this is no longer the appropriate list, please let me know.

Unfortunately, hanging in drmwtq isn't really that informative...  What
this says is that we have submitted commands to the GPU and are waiting
on it to process them.  When userland tells us to wait for the event, we
check to see if the card has already processed the command.  If it has,
then we just return immediately.  If it hasn't, then we sleep waiting on
an interrupt from the card once it has processed the command.  We will
sleep for at most 3 seconds, but userland (via libdrm) will just keep
asking us over and over.

This generally suggests that the GPU is locked up...  Given that you say
sometimes it locks up hard (usually a panic, that you can't see since X
is running) and other times only X is stalled it might be related to
this patch, if you haven't tried this on already.

http://people.freebsd.org/~rnoland/drm_radeon-copyin-fix-try2.patch

I would usually suggest that you try AGPMode 1, but since you have
already tried PCI mode, that should rule that out.  You should be using
EXA on this card, but having tried XAA is also good for a sanity check.

I rarely get to run a card for very long anymore... I end up swapping
cards out a few times a day lately, but I have recently been running an
x600 pcie (r300) with compiz for at least several hours without issue.
If you can figure out a way to reproduce it, or manage to get a core
file from one of the panics that would help.  Preferably without
involving KDE, since I don't run it...  I have also run an x1650 PCI-E
somewhat recently, which is the closest I have to your card, though I
don't remember exactly how long ago it was that I ran it for more than
an hour.  Probably 2 or 3 weeks ago.

robert.

> Thank you,

-- 
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-stable/attachments/20090505/9dd8df9d/attachment.pgp
From danger at FreeBSD.org  Tue May  5 08:01:33 2009
From: danger at FreeBSD.org (Daniel Gerzo)
Date: Tue May  5 08:01:40 2009
Subject: RELENG_7 - has mergemaster changed logic since 7.2-RELEASE?
In-Reply-To: <49FF5901.600@gmail.com>
References: <20090504225012.392fa49f.torfinn.ingolfsen@broadpark.no>
	<49FF5901.600@gmail.com>
Message-ID: <49FFEECE.20403@FreeBSD.org>

Manolis Kiagias wrote:

> I always use -iU too.
> I've lost motd, passwd, group and master.passwd
> During mergemaster -p I was asked to merge changes to some of these, and
> still they were replaced with the newer versions. I don't know what went
> wrong but have restored them from backup. (I always tar /etc before a
> source upgrade). Upgrading another system using freebsd-update did not
> cause any problem.

I have the same experience while I was upgrading a few machines 
upgrading from RELENG_7 to RELENG_7_2. I haven't experienced when 
upgrading from 7.1-R to 7.2-R.

Here auth.conf, csh.cshrc, hosts, crontab, syslogd.conf, passswd, 
master.passwd, group, sysctl.conf motd and maybe some more got 
overwritten :-( I had to restore from backups.

-- 
S pozdravom / Best regards
   Daniel Gerzo, FreeBSD committer
From lists at reiteration.net  Tue May  5 09:40:05 2009
From: lists at reiteration.net (John)
Date: Tue May  5 09:40:12 2009
Subject: cvsup.uk.freebsd.org appears to not be serving
In-Reply-To: <20090504090029.GF1006@rwpc12.mby.riverwillow.net.au>
References: <49FEA6D1.2080503@reiteration.net>
	<20090504090029.GF1006@rwpc12.mby.riverwillow.net.au>
Message-ID: <4A00096D.50801@reiteration.net>

John Marshall wrote:

> You are obviously connecting OK; it's just that the server is already as
> busy as it's minder is willing to let it be.  Perhaps you'd be better
> off choosing something other than 03:00 as a starting point?

Maybe... but I think that would make no odds, because although it
started at 0300, it subsequently retried at different times throughout
the following week.

>> Establishing passive-mode data connection
>> Cannot connect to data port: Connection refused
>> Will retry at 03:18:04
>> Retrying
> 
> Don't do that!  Use multiplexed mode "-P m" (from the cvsup man page,
> "All but multiplexed mode are deprecated"); or use csup which does
> multiplexed mode by default.

OK I'm using -P m now on all the freebsd boxes. Still using cvsup4.uk,
will try again with cvsup.uk when I've got more time, and if necessary
report the issue to -hubs.

cheers,

-- 
John
From chris# at 1command.com  Tue May  5 09:48:10 2009
From: chris# at 1command.com (Chris H)
Date: Tue May  5 09:48:21 2009
Subject: GEOM_STRIPE: Cannot add disk da2c to st0 (error=17).
Message-ID: <20090505024800.tk0saqntsgk8kk8c@webmail.1command.com>

Greetings,
I'm attempting to upgrade one of our servers to 6.4 (from 6.2)
Before doing so I need to stripe 3 identical drives on the
same SCSI port into one drive, the drives are on an LSI controller
with 2 ports:

May  5 02:10:15 hitme kernel: sym0: <1010-66> port 0xe400-0xe4ff mem 
0xfebe0000-0xfebe03ff,0xfebd8000-0xfebd9fff irq 29 at device 6.0 on pci1
May  5 02:10:15 hitme kernel: sym0: Reserved 0x400 bytes for rid 0x14 
type 3 at 0xfebe0000
May  5 02:10:15 hitme kernel: sym0: Reserved 0x2000 bytes for rid 0x1c 
type 3 at 0xfebd8000
May  5 02:10:15 hitme kernel: sym0: Symbios NVRAM, ID 7, Fast-80, LVD, 
parity checking
May  5 02:10:15 hitme kernel: sym0: open drain IRQ line driver, using 
on-chip SRAM
May  5 02:10:15 hitme kernel: sym0: using LOAD/STORE-based firmware.
May  5 02:10:15 hitme kernel: sym0: handling phase mismatch from SCRIPTS.
May  5 02:10:15 hitme kernel: sym0: initial 
SCNTL3/DMODE/DCNTL/CTEST3/4/5 = (hex) 00/4e/a0/01/00/04
May  5 02:10:15 hitme kernel: sym0: final   
SCNTL3/DMODE/DCNTL/CTEST3/4/5 = (hex) 00/4e/80/01/08/04
May  5 02:10:15 hitme kernel: ioapic1: routing intpin 13 (PCI IRQ 29) 
to vector 52
May  5 02:10:15 hitme kernel: sym0: [GIANT-LOCKED]
May  5 02:10:15 hitme kernel: sym0: enabling clock multiplier
May  5 02:10:15 hitme kernel: sym0: Downloading SCSI SCRIPTS.
May  5 02:10:15 hitme kernel: sym1: <1010-66> port 0xe800-0xe8ff mem 
0xfebf8000-0xfebf83ff,0xfebf0000-0xfebf1fff irq 28 at device 6.1 on pci1
May  5 02:10:15 hitme kernel: sym1: Reserved 0x400 bytes for rid 0x14 
type 3 at 0xfebf8000
May  5 02:10:15 hitme kernel: sym1: Reserved 0x2000 bytes for rid 0x1c 
type 3 at 0xfebf0000
May  5 02:10:15 hitme kernel: sym1: Symbios NVRAM, ID 7, Fast-80, SE, 
parity checking
May  5 02:10:15 hitme kernel: sym1: open drain IRQ line driver, using 
on-chip SRAM
May  5 02:10:15 hitme kernel: sym1: using LOAD/STORE-based firmware.
May  5 02:10:15 hitme kernel: sym1: handling phase mismatch from SCRIPTS.
May  5 02:10:15 hitme kernel: sym1: initial 
SCNTL3/DMODE/DCNTL/CTEST3/4/5 = (hex) 00/4e/a0/01/00/04
May  5 02:10:15 hitme kernel: sym1: final   
SCNTL3/DMODE/DCNTL/CTEST3/4/5 = (hex) 00/4e/80/01/08/04

the drives are identical 17.5Gb U160 drives (unused)

May  5 02:10:15 hitme kernel: pass0: <IBM DPSS-318350M S80D> Fixed 
Direct Access SCSI-3 device May  5 02:10:15 hitme kernel: pass0: Serial 
Number         ZE0E4501
May  5 02:10:15 hitme kernel: pass0: 160.000MB/s transfers (80.000MHz, 
offset 62, 16bit), Tagged Queueing Enabled
May  5 02:10:15 hitme kernel: pass1 at sym0 bus 0 target 1 lun 0
May  5 02:10:15 hitme kernel: pass1: <IBM DPSS-318350M S80D> Fixed 
Direct Access SCSI-3 device May  5 02:10:15 hitme kernel: pass1: Serial 
Number         ZE0G1630
May  5 02:10:15 hitme kernel: pass1: 160.000MB/s transfers (80.000MHz, 
offset 62, 16bit), Tagged Queueing Enabled
May  5 02:10:15 hitme kernel: pass2 at sym0 bus 0 target 2 lun 0
May  5 02:10:15 hitme kernel: pass2: <IBM DPSS-318350M S80D> Fixed 
Direct Access SCSI-3 device May  5 02:10:15 hitme kernel: pass2: Serial 
Number         ZE0B4449
May  5 02:10:15 hitme kernel: pass2: 160.000MB/s transfers (80.000MHz, 
offset 62, 16bit), Tagged Queueing Enabled
May  5 02:10:15 hitme kernel: pass3 at sym1 bus 0 target 3 lun 0

The current system (6.2) is on a single drive on the other SCSI port
(IBM - identical to the others).
However, when I attempt to stripe the 3 unused drives, I recieve an
error regarding da2:

gstripe label -v st0 /dev/da0 /dev/da1 /dev/da2
GEOM_STRIPE: Device st0 created (id=2607126992).
GEOM_STRIPE: Disk da0 attached to st0.
Metadata value stored on /dev/da0.
GEOM_STRIPE: Disk da1 attached to st0.
Metadata value stored on /dev/da1.
GEOM_STRIPE: Disk da2 attached to st0.
GEOM_STRIPE: Device st0 activated.
GEOM_STRIPE: Cannot add disk da2c to st0 (error=17).
Metadata value stored on /dev/da2.

I blanked the 3 drives prior to attempting any of this, and it's
on a fresh reboot. I'm afraid I don't know how to proceed. Is it
a problem with gstripe(8)? I /really/ need to stripe these drives
so as to upgrade the system.

Thank you for all your time and consideration in this matter.

Sincerely,
Chris H


From hk at alogis.com  Tue May  5 10:27:03 2009
From: hk at alogis.com (Holger Kipp)
Date: Tue May  5 10:27:11 2009
Subject: GEOM_STRIPE: Cannot add disk da2c to st0 (error=17).
In-Reply-To: <20090505024800.tk0saqntsgk8kk8c@webmail.1command.com>
References: <20090505024800.tk0saqntsgk8kk8c@webmail.1command.com>
Message-ID: <20090505101301.GA31143@intserv.int1.b.intern>

On Tue, May 05, 2009 at 02:48:00AM -0700, Chris H wrote:
> Greetings,
> I'm attempting to upgrade one of our servers to 6.4 (from 6.2)
> Before doing so I need to stripe 3 identical drives on the
> same SCSI port into one drive, the drives are on an LSI controller
> with 2 ports:
[..]
> However, when I attempt to stripe the 3 unused drives, I recieve an
> error regarding da2:
> 
> gstripe label -v st0 /dev/da0 /dev/da1 /dev/da2
> GEOM_STRIPE: Device st0 created (id=2607126992).
> GEOM_STRIPE: Disk da0 attached to st0.
> Metadata value stored on /dev/da0.
> GEOM_STRIPE: Disk da1 attached to st0.
> Metadata value stored on /dev/da1.
> GEOM_STRIPE: Disk da2 attached to st0.
> GEOM_STRIPE: Device st0 activated.
> GEOM_STRIPE: Cannot add disk da2c to st0 (error=17).
> Metadata value stored on /dev/da2.
> 
> I blanked the 3 drives prior to attempting any of this, and it's
> on a fresh reboot. I'm afraid I don't know how to proceed. Is it
> a problem with gstripe(8)? I /really/ need to stripe these drives
> so as to upgrade the system.

Can you check if you have any fdisk metadata on either of your disks?
Especially as da0, da1, da2 are attached to st0 without problems, 
but then GEOM_STRIPE complains about da2c (which looks like a partition
entry)...

Mind you, this is just a wild guess from my side ;-)

Regards,
Holger
From mad at madpilot.net  Tue May  5 11:06:27 2009
From: mad at madpilot.net (Guido Falsi)
Date: Tue May  5 11:06:34 2009
Subject: [PANIC] recent 7.2-STABLE when probing drm
Message-ID: <20090505110624.GA83487@megatron.madpilot.net>

Hi!

I'm using FreeBSD/i386 stable on a HP DC7800 PC.

It has an Intel Q35 graphic chip.

After upgrading to a recent stable I experienced a pani on boot, just
after probing drm.

I investigated a little and found out that reverting the file

src/sys/dev/pci/pci.c

to rev. 1.355.2.9 (SVN Rev 190092) solves the crash.

I could not investigatte urther right away, but some regression was
introduced with this rev.

Is any more information needed?

Thank you in advance for any help or information on this.

Here is the dmesg from the working kernel the other one panics just
after the line marked with [*]:

Copyright (c) 1992-2009 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
        The Regents of the University of California. All rights
reserved.
FreeBSD is a registered trademark of The FreeBSD Foundation.
FreeBSD 7.2-STABLE #16: Tue May  5 12:32:40 CEST 2009
    root@vwg82.hq.ignesti.it:/usr/obj/usr/src/sys/VWG82
Timecounter "i8254" frequency 1193182 Hz quality 0
CPU: Intel(R) Core(TM)2 Duo CPU     E6550  @ 2.33GHz (2327.51-MHz
686-class CPU)
  Origin = "GenuineIntel"  Id = 0x6fb  Stepping = 11

Features=0xbfebfbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,C
MOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE>

Features2=0xe3fd<SSE3,DTES64,MON,DS_CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM>
  AMD Features=0x20100000<NX,LM>
  AMD Features2=0x1<LAHF>
  Cores per package: 2
real memory  = 3740987392 (3567 MB)
avail memory = 3661430784 (3491 MB)
ACPI APIC Table: <COMPAQ BEARLAKE>
FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs
 cpu0 (BSP): APIC ID:  0
 cpu1 (AP): APIC ID:  1
ioapic0: Changing APIC ID to 1
ioapic0 <Version 2.0> irqs 0-23 on motherboard
netsmb_dev: loaded
kbd1 at kbdmux0
acpi0: <HPQOEM SLIC-BPC> on motherboard
acpi0: [ITHREAD]
acpi0: Power Button (fixed)
acpi0: reservation of 0, a0000 (3) failed
acpi0: reservation of 100000, dff00000 (3) failed
Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000
acpi_timer0: <24-bit timer at 3.579545MHz> port 0xf808-0xf80b 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
vgapci0: <VGA-compatible display> port 0x1230-0x1237 mem
0xf0100000-0xf017ffff,0xe0000000-0xefffffff,0xf0000000-0xf00fffff irq 16
at device 2.0 on pci0
agp0: <Intel Q35 SVGA controller> on vgapci0
agp0: detected 6140k stolen memory
agp0: aperture size is 256M
drm0: <Intel Q35> on vgapci0 [*]
vgapci0: child drm0 requested pci_enable_busmaster
info: [drm] AGP at 0xe0000000 256MB
info: [drm] Initialized i915 1.6.0 20080730
pci0: <simple comms> at device 3.0 (no driver attached)
atapci0: <Intel ATA controller> port
0x1238-0x123f,0x1270-0x1273,0x1240-0x1247,0x1274-0x1277,0x11e0-0x11ef
irq 18 at device 3.2 on pci0
atapci0: [ITHREAD]
ata2: <ATA channel 0> on atapci0
ata2: [ITHREAD]
ata3: <ATA channel 1> on atapci0
ata3: [ITHREAD]
pci0: <simple comms, UART> at device 3.3 (no driver attached)
em0: <Intel(R) PRO/1000 Network Connection 6.9.6> port 0x1100-0x111f mem
0xf0180000-0xf019ffff,0xf01a5000-0xf01a5fff irq 19 at device 25.0 on
pci0
em0: Using MSI interrupt
em0: [FILTER]
em0: Ethernet address: 00:1e:0b:ab:e6:a7
uhci0: <UHCI (generic) USB controller> port 0x1120-0x113f irq 20 at
device 26.0 on pci0
uhci0: [GIANT-LOCKED]
uhci0: [ITHREAD]
usb0: <UHCI (generic) USB controller> 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: <UHCI (generic) USB controller> port 0x1140-0x115f irq 21 at
device 26.1 on pci0
uhci1: [GIANT-LOCKED]
uhci1: [ITHREAD]
usb1: <UHCI (generic) USB controller> 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: <UHCI (generic) USB controller> port 0x1160-0x117f irq 22 at
device 26.2 on pci0
uhci2: [GIANT-LOCKED]
uhci2: [ITHREAD]
usb2: <UHCI (generic) USB controller> 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: <EHCI (generic) USB 2.0 controller> mem 0xf01a6000-0xf01a63ff irq
22 at device 26.7 on pci0
ehci0: [GIANT-LOCKED]
ehci0: [ITHREAD]
usb3: EHCI version 1.0
usb3: companion controllers, 2 ports each: usb0 usb1 usb2
usb3: <EHCI (generic) 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
hdac0: <Intel 82801I High Definition Audio Controller> mem
0xf01a0000-0xf01a3fff irq 21 at device 27.0 on pci0
hdac0: HDA Driver Revision: 20090329_0131
hdac0: [ITHREAD]
pcib1: <ACPI PCI-PCI bridge> at device 28.0 on pci0
pci32: <ACPI PCI bus> on pcib1
pcib2: <ACPI PCI-PCI bridge> irq 21 at device 28.1 on pci0
pci48: <ACPI PCI bus> on pcib2
uhci3: <UHCI (generic) USB controller> port 0x1180-0x119f irq 20 at
device 29.0 on pci0
uhci3: [GIANT-LOCKED]
uhci3: [ITHREAD]
usb4: <UHCI (generic) USB controller> on uhci3
usb4: USB revision 1.0
uhub4: <Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1> on usb4
uhub4: 2 ports with 2 removable, self powered
uhci4: <UHCI (generic) USB controller> port 0x11a0-0x11bf irq 21 at
device 29.1 on pci0
uhci4: [GIANT-LOCKED]
uhci4: [ITHREAD]
usb5: <UHCI (generic) USB controller> on uhci4
usb5: USB revision 1.0
uhub5: <Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1> on usb5
uhub5: 2 ports with 2 removable, self powered
ehci1: <EHCI (generic) USB 2.0 controller> mem 0xf01a6400-0xf01a67ff irq
20 at device 29.7 on pci0
ehci1: [GIANT-LOCKED]
ehci1: [ITHREAD]
usb6: EHCI version 1.0
usb6: companion controllers, 2 ports each: usb4 usb5
usb6: <EHCI (generic) USB 2.0 controller> on ehci1
usb6: USB revision 2.0
uhub6: <Intel EHCI root hub, class 9/0, rev 2.00/1.00, addr 1> on usb6
uhub6: 4 ports with 4 removable, self powered
pcib3: <ACPI PCI-PCI bridge> at device 30.0 on pci0
pci7: <ACPI PCI bus> on pcib3
isab0: <PCI-ISA bridge> at device 31.0 on pci0
isa0: <ISA bus> on isab0
atapci1: <Intel ICH9 SATA300 controller> port
0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x11f0-0x11ff,0x1200-0x120f irq 18
at device 31.2 on pci0
ata0: <ATA channel 0> on atapci1
ata0: [ITHREAD]
ata1: <ATA channel 1> on atapci1
ata1: [ITHREAD]
atapci2: <Intel ICH9 SATA300 controller> port
0x1260-0x1267,0x1280-0x1283,0x1268-0x126f,0x1284-0x1287,0x1210-0x121f,0x1220-0x122f
irq 18 at device 31.5 on pci0
atapci2: [ITHREAD]
ata4: <ATA channel 0> on atapci2
ata4: [ITHREAD]
ata5: <ATA channel 1> on atapci2
ata5: [ITHREAD]
acpi_button0: <Power Button> on acpi0
atkbdc0: <Keyboard controller (i8042)> port 0x60,0x64 irq 1 on acpi0
atkbd0: <AT Keyboard> irq 1 on atkbdc0
kbd0 at atkbd0
atkbd0: [GIANT-LOCKED]
atkbd0: [ITHREAD]
sio0: <Standard PC COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0
sio0: type 16550A
sio0: [FILTER]
cpu0: <ACPI CPU> on acpi0
est0: <Enhanced SpeedStep Frequency Control> on cpu0
p4tcc0: <CPU Frequency Thermal Control> on cpu0
cpu1: <ACPI CPU> on acpi0
est1: <Enhanced SpeedStep Frequency Control> on cpu1
p4tcc1: <CPU Frequency Thermal Control> on cpu1
pmtimer0 on isa0
ppc0: <Parallel port> at port 0x378-0x37f irq 7 on isa0
ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode
ppc0: FIFO with 16/16/13 bytes threshold
ppbus0: <Parallel port bus> on ppc0
ppbus0: [ITHREAD]
plip0: <PLIP network interface> on ppbus0
plip0: WARNING: using obsoleted IFF_NEEDSGIANT flag
lpt0: <Printer> on ppbus0
lpt0: Interrupt-driven port
ppi0: <Parallel I/O> on ppbus0
ppc0: [GIANT-LOCKED]
ppc0: [ITHREAD]
sc0: <System console> at flags 0x100 on isa0
sc0: VGA <16 virtual consoles, flags=0x300>
sio1: configured irq 3 not in bitmap of probed irqs 0
sio1: port may not be enabled
vga0: <Generic ISA VGA> at port 0x3c0-0x3df iomem 0xa0000-0xbffff on
isa0
ums0: <Logitech USB Gaming Mouse, class 0/0, rev 2.00/52.00, addr 2> on
uhub2
ums0: 16 buttons and Z dir.
uhid0: <Logitech USB Gaming Mouse, class 0/0, rev 2.00/52.00, addr 2> on
uhub2

-- 
Guido Falsi <mad@madpilot.net>
From gavin at FreeBSD.org  Tue May  5 11:12:41 2009
From: gavin at FreeBSD.org (Gavin Atkinson)
Date: Tue May  5 11:12:48 2009
Subject: [PANIC] recent 7.2-STABLE when probing drm
In-Reply-To: <20090505110624.GA83487@megatron.madpilot.net>
References: <20090505110624.GA83487@megatron.madpilot.net>
Message-ID: <1241521951.47323.3.camel@buffy.york.ac.uk>

On Tue, 2009-05-05 at 13:06 +0200, Guido Falsi wrote:
> Hi!
> 
> I'm using FreeBSD/i386 stable on a HP DC7800 PC.
> 
> It has an Intel Q35 graphic chip.
> 
> After upgrading to a recent stable I experienced a pani on boot, just
> after probing drm.
> 
> I investigated a little and found out that reverting the file
> 
> src/sys/dev/pci/pci.c
> 
> to rev. 1.355.2.9 (SVN Rev 190092) solves the crash.
> 
> I could not investigatte urther right away, but some regression was
> introduced with this rev.
> 
> Is any more information needed?

When it panics, can you please type "bt" (assuming you have the debugger
compiled in) and show the output?

Gavin
From chris# at 1command.com  Tue May  5 12:08:13 2009
From: chris# at 1command.com (Chris H)
Date: Tue May  5 12:08:20 2009
Subject: GEOM_STRIPE: Cannot add disk da2c to st0 (error=17).
In-Reply-To: <20090505101301.GA31143@intserv.int1.b.intern>
References: <20090505024800.tk0saqntsgk8kk8c@webmail.1command.com>
	<20090505101301.GA31143@intserv.int1.b.intern>
Message-ID: <20090505050606.hkxc6cgl3k8ccgws@webmail.1command.com>

Hello, and thank you for your reply...

Quoting Holger Kipp <hk@alogis.com>:

> On Tue, May 05, 2009 at 02:48:00AM -0700, Chris H wrote:
>> Greetings,
>> I'm attempting to upgrade one of our servers to 6.4 (from 6.2)
>> Before doing so I need to stripe 3 identical drives on the
>> same SCSI port into one drive, the drives are on an LSI controller
>> with 2 ports:
> [..]
>> However, when I attempt to stripe the 3 unused drives, I recieve an
>> error regarding da2:
>>
>> gstripe label -v st0 /dev/da0 /dev/da1 /dev/da2
>> GEOM_STRIPE: Device st0 created (id=2607126992).
>> GEOM_STRIPE: Disk da0 attached to st0.
>> Metadata value stored on /dev/da0.
>> GEOM_STRIPE: Disk da1 attached to st0.
>> Metadata value stored on /dev/da1.
>> GEOM_STRIPE: Disk da2 attached to st0.
>> GEOM_STRIPE: Device st0 activated.
>> GEOM_STRIPE: Cannot add disk da2c to st0 (error=17).
>> Metadata value stored on /dev/da2.
>>
>> I blanked the 3 drives prior to attempting any of this, and it's
>> on a fresh reboot. I'm afraid I don't know how to proceed. Is it
>> a problem with gstripe(8)? I /really/ need to stripe these drives
>> so as to upgrade the system.
>
> Can you check if you have any fdisk metadata on either of your disks?
> Especially as da0, da1, da2 are attached to st0 without problems,
> but then GEOM_STRIPE complains about da2c (which looks like a partition
> entry)...

I cheated, and went into sysinstall > custom > partition

chose each of da0, da1, and da2

pressed "f" then "no" then "yes". Which forced a "dangerously" dedicated
disk. I also chose "w" on all occasions, and each time the response indicated
Successfully written to disk. I then bailed out of sysinstall, then went
back, and deleted the partitions, and again, chose "w". Which also indicated
"Successfully written to disk". I then bailed out of sysinstall.
Having felt the disks were all now clean, I proceeded with the command:

gstripe label -v st0 /dev/da0 /dev/da1 /dev/da2

...well, you know the rest of the story. :)

Is this not a good (the best) direction to take?

Thank you again for your reply.

--Chris H

>
> Mind you, this is just a wild guess from my side ;-)
>
> Regards,
> Holger
>



From kostikbel at gmail.com  Tue May  5 12:13:23 2009
From: kostikbel at gmail.com (Kostik Belousov)
Date: Tue May  5 12:13:31 2009
Subject: [PANIC] recent 7.2-STABLE when probing drm
In-Reply-To: <1241521951.47323.3.camel@buffy.york.ac.uk>
References: <20090505110624.GA83487@megatron.madpilot.net>
	<1241521951.47323.3.camel@buffy.york.ac.uk>
Message-ID: <20090505121247.GN1948@deviant.kiev.zoral.com.ua>

On Tue, May 05, 2009 at 12:12:31PM +0100, Gavin Atkinson wrote:
> On Tue, 2009-05-05 at 13:06 +0200, Guido Falsi wrote:
> > Hi!
> > 
> > I'm using FreeBSD/i386 stable on a HP DC7800 PC.
> > 
> > It has an Intel Q35 graphic chip.
> > 
> > After upgrading to a recent stable I experienced a pani on boot, just
> > after probing drm.
> > 
> > I investigated a little and found out that reverting the file
> > 
> > src/sys/dev/pci/pci.c
> > 
> > to rev. 1.355.2.9 (SVN Rev 190092) solves the crash.
> > 
> > I could not investigatte urther right away, but some regression was
> > introduced with this rev.
> > 
> > Is any more information needed?
> 
> When it panics, can you please type "bt" (assuming you have the debugger
> compiled in) and show the output?

I have this too. I have dump too.

drm0: <Intel i945GM> on vgapci0
panic: resource_list_alloc: resource entry is busy
KDB: stack backtrace:
db_trace_self_wrapper(c07214ff,c2b46764,c04c928f,c071f823,c078b080,...) at 0xc044df46 = db_trace_self_wrapper+0x26
kdb_backtrace(c071f823,c078b080,c07211b1,c2b46770,c2b46770,...) at 0xc04f41f9 = kdb_backtrace+0x29
panic(c07211b1,3,10,c04e9484,c2e37000,...) at 0xc04c928f = panic+0xaf
resource_list_alloc(c2cffb04,c2d00a80,c2d00c80,3,c2d2a1fc,...) at 0xc04f0c06 = resource_list_alloc+0xd6
pci_alloc_resource(c2d00a80,c2d00c80,3,c2d2a1fc,0,ffffffff,1,4) at 0xc045a2d1 = pci_alloc_resource+0x581
bus_alloc_resource(c2d00c80,3,c2d2a1fc,0,ffffffff,...) at 0xc04f0a8c = bus_alloc_resource+0x7c
vga_pci_alloc_resource(c2d00c80,c2cfa080,3,c2d2a1fc,0,ffffffff,1,4) at 0xc04600ab = vga_pci_alloc_resource+0x3b
bus_alloc_resource(c2cfa080,3,c2d2a1fc,0,ffffffff,...) at 0xc04f0a8c = bus_alloc_resource+0x7c
drm_alloc_resource(fffffff4,c2d2a000,c2b468fc,c36a0b9b,c2d2a000,...) at 0xc36b7726 = drm_alloc_resource+0xf6
drm_get_resource_start(c2d2a000,0,1,4,c04d2010,...) at 0xc36b780c = drm_get_resource_start+0x1c
i915_driver_load(c2d2a000,6,c36bfe5c,1c2,ffffffff,...) at 0xc36a0b9b = i915_driver_load+0x13b
drm_attach(c2cfa080,c36a59a0,102,c2d00c80,c2cfa0cc,...) at 0xc36bb0e1 = drm_attach+0x4b1
i915_attach(c2cfa080,c32a9054,c0748368,c0721002,80000000,...) at 0xc36a0f41 = i915_attach+0x111
device_attach(c2cfa080,c2cfa080,c2d00c80,c2cfa080,c2d00c80,...) at 0xc04ef707 = device_attach+0x387
device_probe_and_attach(c2cfa080,c2d00c80,c0748358,c2d00c80,0,...) at 0xc04f0702 = device_probe_and_attach+0xe2
bus_generic_driver_added(c2d00c80,c36a5b7c,101,0,c36a5b68,...) at 0xc04f07d5 = bus_generic_driver_added+0x75
devclass_add_driver(c2ca4480,c36a5b7c,c2b46a2c,2d,c36a5b7c,...) at 0xc04ee4c8 = devclass_add_driver+0xc8
driver_module_handler(c2e420c0,0,c36a5b68,0,0,...) at 0xc04ef2a9 = driver_module_handler+0x79
module_register_init(c36a5b5c,c071dad9,c2b46c10,c2b46c0c,0,...) at 0xc04b9d25 = module_register_init+0x105
linker_load_module(0,c2b46c40,2,c2b46c58,c04b7b99,...) at 0xc04b2462 = linker_load_module+0xa02
kern_kldload(c2e79af0,c2d12000,c2b46c70,0,0,...) at 0xc04b294c = kern_kldload+0xec
kldload(c2e79af0,c2b46cfc,4,c2b46d38,c2b46d2c,...) at 0xc04b2ae4 = kldload+0x74
syscall(c2b46d38) at 0xc06f6eb5 = syscall+0x3a5
Xint0x80_syscall() at 0xc06de760 = Xint0x80_syscall+0x20
--- syscall (304, FreeBSD ELF32, kldload), eip = 0x28566d57, esp = 0xbfbfe89c, ebp = 0xbfbfe8a8 ---
-------------- 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-stable/attachments/20090505/ee77f522/attachment.pgp
From gavin at FreeBSD.org  Tue May  5 12:35:32 2009
From: gavin at FreeBSD.org (Gavin Atkinson)
Date: Tue May  5 12:35:38 2009
Subject: [PANIC] recent 7.2-STABLE when probing drm
In-Reply-To: <20090505121247.GN1948@deviant.kiev.zoral.com.ua>
References: <20090505110624.GA83487@megatron.madpilot.net>
	<1241521951.47323.3.camel@buffy.york.ac.uk>
	<20090505121247.GN1948@deviant.kiev.zoral.com.ua>
Message-ID: <1241526927.47323.5.camel@buffy.york.ac.uk>

On Tue, 2009-05-05 at 15:12 +0300, Kostik Belousov wrote:
> On Tue, May 05, 2009 at 12:12:31PM +0100, Gavin Atkinson wrote:
> > On Tue, 2009-05-05 at 13:06 +0200, Guido Falsi wrote:
> > > Hi!
> > > 
> > > I'm using FreeBSD/i386 stable on a HP DC7800 PC.
> > > 
> > > It has an Intel Q35 graphic chip.
> > > 
> > > After upgrading to a recent stable I experienced a pani on boot, just
> > > after probing drm.
> > > 
> > > I investigated a little and found out that reverting the file
> > > 
> > > src/sys/dev/pci/pci.c
> > > 
> > > to rev. 1.355.2.9 (SVN Rev 190092) solves the crash.
> > > 
> > > I could not investigatte urther right away, but some regression was
> > > introduced with this rev.
> > > 
> > > Is any more information needed?
> > 
> > When it panics, can you please type "bt" (assuming you have the debugger
> > compiled in) and show the output?
> 
> I have this too. I have dump too.
> 
> drm0: <Intel i945GM> on vgapci0
> panic: resource_list_alloc: resource entry is busy
> KDB: stack backtrace:
> db_trace_self_wrapper(c07214ff,c2b46764,c04c928f,c071f823,c078b080,...) at 0xc044df46 = db_trace_self_wrapper+0x26
> kdb_backtrace(c071f823,c078b080,c07211b1,c2b46770,c2b46770,...) at 0xc04f41f9 = kdb_backtrace+0x29
> panic(c07211b1,3,10,c04e9484,c2e37000,...) at 0xc04c928f = panic+0xaf
> resource_list_alloc(c2cffb04,c2d00a80,c2d00c80,3,c2d2a1fc,...) at 0xc04f0c06 = resource_list_alloc+0xd6
> pci_alloc_resource(c2d00a80,c2d00c80,3,c2d2a1fc,0,ffffffff,1,4) at 0xc045a2d1 = pci_alloc_resource+0x581
> bus_alloc_resource(c2d00c80,3,c2d2a1fc,0,ffffffff,...) at 0xc04f0a8c = bus_alloc_resource+0x7c
> vga_pci_alloc_resource(c2d00c80,c2cfa080,3,c2d2a1fc,0,ffffffff,1,4) at 0xc04600ab = vga_pci_alloc_resource+0x3b
[...]

I wonder if r189373 also needs merging?

Gavin
From 000.fbsd at quip.cz  Tue May  5 12:38:20 2009
From: 000.fbsd at quip.cz (Miroslav Lachman)
Date: Tue May  5 12:38:28 2009
Subject: GEOM_STRIPE: Cannot add disk da2c to st0 (error=17).
In-Reply-To: <20090505050606.hkxc6cgl3k8ccgws@webmail.1command.com>
References: <20090505024800.tk0saqntsgk8kk8c@webmail.1command.com>	<20090505101301.GA31143@intserv.int1.b.intern>
	<20090505050606.hkxc6cgl3k8ccgws@webmail.1command.com>
Message-ID: <4A003334.70807@quip.cz>

Chris H wrote:
> Hello, and thank you for your reply...
> 
> Quoting Holger Kipp <hk@alogis.com>:
> 
[...]
>>
>> Can you check if you have any fdisk metadata on either of your disks?
>> Especially as da0, da1, da2 are attached to st0 without problems,
>> but then GEOM_STRIPE complains about da2c (which looks like a partition
>> entry)...
> 
> 
> I cheated, and went into sysinstall > custom > partition
> 
> chose each of da0, da1, and da2
> 
> pressed "f" then "no" then "yes". Which forced a "dangerously" dedicated
> disk. I also chose "w" on all occasions, and each time the response 
> indicated
> Successfully written to disk. I then bailed out of sysinstall, then went
> back, and deleted the partitions, and again, chose "w". Which also 
> indicated
> "Successfully written to disk". I then bailed out of sysinstall.
> Having felt the disks were all now clean, I proceeded with the command:
> 
> gstripe label -v st0 /dev/da0 /dev/da1 /dev/da2
> 
> ...well, you know the rest of the story. :)
> 
> Is this not a good (the best) direction to take?

I recommend you to use
dd if=/dev/zero of=/dev/da0 count=1000
dd if=/dev/zero of=/dev/da1 count=1000
dd if=/dev/zero of=/dev/da2 count=1000

to clear the begining of the disks. The next step should be to clear the 
few last sectors, where metadata of GEOM mirror, journal, stripe etc. 
are stored, so you end up with "clear disks" which you can use in 
whatever setup you want without problem with old data, partitions etc.

Miroslav Lachman
From mad at madpilot.net  Tue May  5 13:16:19 2009
From: mad at madpilot.net (Guido Falsi)
Date: Tue May  5 13:16:31 2009
Subject: [PANIC] recent 7.2-STABLE when probing drm
In-Reply-To: <1241521951.47323.3.camel@buffy.york.ac.uk>
References: <20090505110624.GA83487@megatron.madpilot.net>
	<1241521951.47323.3.camel@buffy.york.ac.uk>
Message-ID: <20090505131617.GB83487@megatron.madpilot.net>

On Tue, May 05, 2009 at 12:12:31PM +0100, Gavin Atkinson wrote:
> > Is any more information needed?
> 
> When it panics, can you please type "bt" (assuming you have the debugger
> compiled in) and show the output?

I did not have a kernel with debugger handy.

Here you go (copying by hand...):

drm0: <Intel Q35> on vgapci0
panic: resource_list_alloc: resource entry busy
cpuid = 0
KDB: enter: panic
[thread pid 0 tid 0 ]
Stopped at    kdb_enter_why+0x3a:    movl    $0,kdb_why
db> bt
kdb_enter_why(c07d0374,c07d0374,c07d2cf1,c0c20760,0,...) at kdb_enter_why+0x3a
panic(c07d2cf1,3,10,c086a7b4,c0c20788,...) at panic+0x131
resource_list_alloc(c6d56604,c6d88a80,c6d88a80,3,c6d79dfc,...) at resource_list_alloc+0xee
pci_alloc_resource(c6d88a80,c6d88a80,3,c6d79dfc,0,ffffffff,1,4) at pci_alloc_resource+0x554
bus_alloc_resource(c6d88a80,3,c6d79dfc,0,ffffffff,...) at bus_alloc_resource+0x7e
vga_pci_alloc_resource(c6d88a80,c6d81d80,3,c6d79dfc,0,ffffffff,1,4) at vga_pci_alloc_resource+0x3b
bus_alloc_resource(c6d88a80,3,c6d79dfc,0,ffffffff,...) at bus_alloc_resource+0x7e
drm_alloc_resource(c6d88b80,c6d88b80,c6d79c00,c0c208fc,c04a6946,...) at drm_alloc_resource+0xea
drm_get_resource_start(c6d79c00,0,1,8,c07b652b,...) at drm_get_resource_start0x17
i915_driver_load(c6d79c00,6,c07b652b,1c2,ffffffff,...) at i915_driver_load+0x139
drm_attach(c6d81d80,c08078a0,102) at drm_attach+0x604
i915_attach(c6d81d80,c6d0f858,c0818470,c07d2b42,80000000,...) at i915_attach+0x10a
device_attach(c6d81d80,c6d81d80,c07d2aa0,932,c6d81d80,...) at device+attach+0x36a
device_probe_and_attach(c6d81d80,c6d88b80,c0c209f4,c04dc7f8,c6d88b80,...) at device_probe_and_attach+0xfd
bus_generic_attach(...) at bus_generic_attach+0x19
vga_pci_attach(...) at vga_pci_attach+0x32
device_attach(...) at device_attach+0x36a
device_probe_and_attach(...) at device_probe_and_attach+0xfd
bus_generic_attach(...) at bus_generic_attach+0x19
acpi_pci_attach(...) at acpi_pci_attach+0x171
device_attach(...) at device_attach+0x36a
device_probe_and_attach(...) at device_probe_and_attach+0xfd
bus_generic_attach(...) at bus_generic_attach+0x19
acpi_pcib_attach(...) at acpi_pcib_attach+0x18e
acpi_pcib_acpi_attach(...) at acpi_pcib_acpi_attach+0x1ad
device_attach(...) at device_attach+0x36a
device_probe_and_attach(...) at device_probe_and_attach+0xfd
bus_generic_attach(...) at bus_generic_attach+0x19
acpi_pci_attach(...) at acpi_pci_attach+0x171
device_attach(...) at device_attach+0x36a
device_probe_and_attach(...) at device_probe_and_attach+0xfd
bus_generic_attach(...) at bus_generic_attach+0x19
nexus_attach(...) at nexus_attach+0x1a
device_attach(...) at device_attach+0x36a
device_probe_and_attach(...) at device_probe_and_attach+0xfd
root_bus_configure(...) at root_bus_configure+0x1b
configure(...) at configure0xc
mi_startup() at mi_startup+0x90
begin() at begin+0x2c

(I cut some parameters, hope they were not important)

Contact me as you wish if any other information or tests are needed.

-- 
Guido Falsi <mad@madpilot.net>
From gavin at FreeBSD.org  Tue May  5 13:51:22 2009
From: gavin at FreeBSD.org (Gavin Atkinson)
Date: Tue May  5 13:51:28 2009
Subject: [PANIC] recent 7.2-STABLE when probing drm
In-Reply-To: <1241526927.47323.5.camel@buffy.york.ac.uk>
References: <20090505110624.GA83487@megatron.madpilot.net>
	<1241521951.47323.3.camel@buffy.york.ac.uk>
	<20090505121247.GN1948@deviant.kiev.zoral.com.ua>
	<1241526927.47323.5.camel@buffy.york.ac.uk>
Message-ID: <1241531476.47323.8.camel@buffy.york.ac.uk>

On Tue, 2009-05-05 at 13:35 +0100, Gavin Atkinson wrote:
> On Tue, 2009-05-05 at 15:12 +0300, Kostik Belousov wrote:
> > On Tue, May 05, 2009 at 12:12:31PM +0100, Gavin Atkinson wrote:
> > > On Tue, 2009-05-05 at 13:06 +0200, Guido Falsi wrote:
> > > > Hi!
> > > > 
> > > > I'm using FreeBSD/i386 stable on a HP DC7800 PC.
> > > > 
> > > > It has an Intel Q35 graphic chip.
> > > > 
> > > > After upgrading to a recent stable I experienced a pani on boot, just
> > > > after probing drm.
> > > > 
> > > > I investigated a little and found out that reverting the file
> > > > 
> > > > src/sys/dev/pci/pci.c
> > > > 
> > > > to rev. 1.355.2.9 (SVN Rev 190092) solves the crash.
> > > > 
> > > > I could not investigatte urther right away, but some regression was
> > > > introduced with this rev.
> > > > 
> > > > Is any more information needed?
> > > 
> > > When it panics, can you please type "bt" (assuming you have the debugger
> > > compiled in) and show the output?
> > 
> > I have this too. I have dump too.
> > 
> > drm0: <Intel i945GM> on vgapci0
> > panic: resource_list_alloc: resource entry is busy
> > KDB: stack backtrace:
> > db_trace_self_wrapper(c07214ff,c2b46764,c04c928f,c071f823,c078b080,...) at 0xc044df46 = db_trace_self_wrapper+0x26
> > kdb_backtrace(c071f823,c078b080,c07211b1,c2b46770,c2b46770,...) at 0xc04f41f9 = kdb_backtrace+0x29
> > panic(c07211b1,3,10,c04e9484,c2e37000,...) at 0xc04c928f = panic+0xaf
> > resource_list_alloc(c2cffb04,c2d00a80,c2d00c80,3,c2d2a1fc,...) at 0xc04f0c06 = resource_list_alloc+0xd6
> > pci_alloc_resource(c2d00a80,c2d00c80,3,c2d2a1fc,0,ffffffff,1,4) at 0xc045a2d1 = pci_alloc_resource+0x581
> > bus_alloc_resource(c2d00c80,3,c2d2a1fc,0,ffffffff,...) at 0xc04f0a8c = bus_alloc_resource+0x7c
> > vga_pci_alloc_resource(c2d00c80,c2cfa080,3,c2d2a1fc,0,ffffffff,1,4) at 0xc04600ab = vga_pci_alloc_resource+0x3b
> [...]
> 
> I wonder if r189373 also needs merging?

Looking at a thread on -current, it looks like this is probably the
case.  It's not a straight merge from head as other bits have changed,
but you could test http://people.freebsd.org/~gavin/189373_7.diff
(warning: compile tested only)

Gavin
From kostikbel at gmail.com  Tue May  5 13:56:09 2009
From: kostikbel at gmail.com (Kostik Belousov)
Date: Tue May  5 13:56:16 2009
Subject: [PANIC] recent 7.2-STABLE when probing drm
In-Reply-To: <1241526927.47323.5.camel@buffy.york.ac.uk>
References: <20090505110624.GA83487@megatron.madpilot.net>
	<1241521951.47323.3.camel@buffy.york.ac.uk>
	<20090505121247.GN1948@deviant.kiev.zoral.com.ua>
	<1241526927.47323.5.camel@buffy.york.ac.uk>
Message-ID: <20090505135602.GO1948@deviant.kiev.zoral.com.ua>

On Tue, May 05, 2009 at 01:35:27PM +0100, Gavin Atkinson wrote:
> On Tue, 2009-05-05 at 15:12 +0300, Kostik Belousov wrote:
> > On Tue, May 05, 2009 at 12:12:31PM +0100, Gavin Atkinson wrote:
> > > On Tue, 2009-05-05 at 13:06 +0200, Guido Falsi wrote:
> > > > Hi!
> > > > 
> > > > I'm using FreeBSD/i386 stable on a HP DC7800 PC.
> > > > 
> > > > It has an Intel Q35 graphic chip.
> > > > 
> > > > After upgrading to a recent stable I experienced a pani on boot, just
> > > > after probing drm.
> > > > 
> > > > I investigated a little and found out that reverting the file
> > > > 
> > > > src/sys/dev/pci/pci.c
> > > > 
> > > > to rev. 1.355.2.9 (SVN Rev 190092) solves the crash.
> > > > 
> > > > I could not investigatte urther right away, but some regression was
> > > > introduced with this rev.
> > > > 
> > > > Is any more information needed?
> > > 
> > > When it panics, can you please type "bt" (assuming you have the debugger
> > > compiled in) and show the output?
> > 
> > I have this too. I have dump too.
> > 
> > drm0: <Intel i945GM> on vgapci0
> > panic: resource_list_alloc: resource entry is busy
> > KDB: stack backtrace:
> > db_trace_self_wrapper(c07214ff,c2b46764,c04c928f,c071f823,c078b080,...) at 0xc044df46 = db_trace_self_wrapper+0x26
> > kdb_backtrace(c071f823,c078b080,c07211b1,c2b46770,c2b46770,...) at 0xc04f41f9 = kdb_backtrace+0x29
> > panic(c07211b1,3,10,c04e9484,c2e37000,...) at 0xc04c928f = panic+0xaf
> > resource_list_alloc(c2cffb04,c2d00a80,c2d00c80,3,c2d2a1fc,...) at 0xc04f0c06 = resource_list_alloc+0xd6
> > pci_alloc_resource(c2d00a80,c2d00c80,3,c2d2a1fc,0,ffffffff,1,4) at 0xc045a2d1 = pci_alloc_resource+0x581
> > bus_alloc_resource(c2d00c80,3,c2d2a1fc,0,ffffffff,...) at 0xc04f0a8c = bus_alloc_resource+0x7c
> > vga_pci_alloc_resource(c2d00c80,c2cfa080,3,c2d2a1fc,0,ffffffff,1,4) at 0xc04600ab = vga_pci_alloc_resource+0x3b
> [...]
> 
> I wonder if r189373 also needs merging?

Thanks for the hint. We need both r183095 and r189373, but the
actual bugfix is r189373, as you rightly pointed out. Below is the patch
that works for me.

Index: dev/pci/vga_pci.c
===================================================================
--- dev/pci/vga_pci.c	(revision 191816)
+++ dev/pci/vga_pci.c	(working copy)
@@ -42,10 +42,22 @@
 #include <sys/bus.h>
 #include <sys/kernel.h>
 #include <sys/module.h>
+#include <sys/rman.h>
+#include <sys/systm.h>
 
 #include <dev/pci/pcireg.h>
 #include <dev/pci/pcivar.h>
 
+struct vga_resource {
+	struct resource	*vr_res;
+	int	vr_refs;
+};
+
+struct vga_pci_softc {
+	device_t	vga_msi_child;	/* Child driver using MSI. */
+	struct vga_resource vga_res[PCIR_MAX_BAR_0 + 1];
+};
+
 static int
 vga_pci_probe(device_t dev)
 {
@@ -110,7 +122,27 @@
 vga_pci_alloc_resource(device_t dev, device_t child, int type, int *rid,
     u_long start, u_long end, u_long count, u_int flags)
 {
+	struct vga_pci_softc *sc;
+	int bar;
 
+	switch (type) {
+	case SYS_RES_MEMORY:
+	case SYS_RES_IOPORT:
+		/*
+		 * For BARs, we cache the resource so that we only allocate it
+		 * from the PCI bus once.
+		 */
+		bar = PCI_RID2BAR(*rid);
+		if (bar < 0 || bar > PCIR_MAX_BAR_0)
+			return (NULL);
+		sc = device_get_softc(dev);
+		if (sc->vga_res[bar].vr_res == NULL)
+			sc->vga_res[bar].vr_res = bus_alloc_resource(dev, type,
+			    rid, start, end, count, flags);
+		if (sc->vga_res[bar].vr_res != NULL)
+			sc->vga_res[bar].vr_refs++;
+		return (sc->vga_res[bar].vr_res);
+	}
 	return (bus_alloc_resource(dev, type, rid, start, end, count, flags));
 }
 
@@ -118,7 +150,38 @@
 vga_pci_release_resource(device_t dev, device_t child, int type, int rid,
     struct resource *r)
 {
+	struct vga_pci_softc *sc;
+	int bar, error;
 
+	switch (type) {
+	case SYS_RES_MEMORY:
+	case SYS_RES_IOPORT:
+		/*
+		 * For BARs, we release the resource from the PCI bus
+		 * when the last child reference goes away.
+		 */
+		bar = PCI_RID2BAR(rid);
+		if (bar < 0 || bar > PCIR_MAX_BAR_0)
+			return (EINVAL);
+		sc = device_get_softc(dev);
+		if (sc->vga_res[bar].vr_res == NULL)
+			return (EINVAL);
+		KASSERT(sc->vga_res[bar].vr_res == r,
+		    ("vga_pci resource mismatch"));
+		if (sc->vga_res[bar].vr_refs > 1) {
+			sc->vga_res[bar].vr_refs--;
+			return (0);
+		}
+		KASSERT(sc->vga_res[bar].vr_refs > 0,
+		    ("vga_pci resource reference count underflow"));
+		error = bus_release_resource(dev, type, rid, r);
+		if (error == 0) {
+			sc->vga_res[bar].vr_res = NULL;
+			sc->vga_res[bar].vr_refs = 0;
+		}
+		return (error);
+	}
+
 	return (bus_release_resource(dev, type, rid, r));
 }
 
@@ -176,6 +239,21 @@
 }
 
 static int
+vga_pci_get_vpd_ident(device_t dev, device_t child, const char **identptr)
+{
+
+	return (pci_get_vpd_ident(dev, identptr));
+}
+
+static int
+vga_pci_get_vpd_readonly(device_t dev, device_t child, const char *kw,
+    const char **vptr)
+{
+
+	return (pci_get_vpd_readonly(dev, kw, vptr));
+}
+
+static int
 vga_pci_set_powerstate(device_t dev, device_t child, int state)
 {
 
@@ -210,6 +288,77 @@
 	return (pci_find_extcap(dev, capability, capreg));
 }
 
+static int
+vga_pci_alloc_msi(device_t dev, device_t child, int *count)
+{
+	struct vga_pci_softc *sc;
+	int error;
+
+	sc = device_get_softc(dev);
+	if (sc->vga_msi_child != NULL)
+		return (EBUSY);
+	error = pci_alloc_msi(dev, count);
+	if (error == 0)
+		sc->vga_msi_child = child;
+	return (error);
+}
+
+static int
+vga_pci_alloc_msix(device_t dev, device_t child, int *count)
+{
+	struct vga_pci_softc *sc;
+	int error;
+
+	sc = device_get_softc(dev);
+	if (sc->vga_msi_child != NULL)
+		return (EBUSY);
+	error = pci_alloc_msix(dev, count);
+	if (error == 0)
+		sc->vga_msi_child = child;
+	return (error);
+}
+
+static int
+vga_pci_remap_msix(device_t dev, device_t child, int count,
+    const u_int *vectors)
+{
+	struct vga_pci_softc *sc;
+
+	sc = device_get_softc(dev);
+	if (sc->vga_msi_child != child)
+		return (ENXIO);
+	return (pci_remap_msix(dev, count, vectors));
+}
+
+static int
+vga_pci_release_msi(device_t dev, device_t child)
+{
+	struct vga_pci_softc *sc;
+	int error;
+
+	sc = device_get_softc(dev);
+	if (sc->vga_msi_child != child)
+		return (ENXIO);
+	error = pci_release_msi(dev);
+	if (error == 0)
+		sc->vga_msi_child = NULL;
+	return (error);
+}
+
+static int
+vga_pci_msi_count(device_t dev, device_t child)
+{
+
+	return (pci_msi_count(dev));
+}
+
+static int
+vga_pci_msix_count(device_t dev, device_t child)
+{
+
+	return (pci_msix_count(dev));
+}
+
 static device_method_t vga_pci_methods[] = {
 	/* Device interface */
 	DEVMETHOD(device_probe,		vga_pci_probe),
@@ -236,10 +385,18 @@
 	DEVMETHOD(pci_disable_busmaster, vga_pci_disable_busmaster),
 	DEVMETHOD(pci_enable_io,	vga_pci_enable_io),
 	DEVMETHOD(pci_disable_io,	vga_pci_disable_io),
+	DEVMETHOD(pci_get_vpd_ident,	vga_pci_get_vpd_ident),
+	DEVMETHOD(pci_get_vpd_readonly,	vga_pci_get_vpd_readonly),
 	DEVMETHOD(pci_get_powerstate,	vga_pci_get_powerstate),
 	DEVMETHOD(pci_set_powerstate,	vga_pci_set_powerstate),
 	DEVMETHOD(pci_assign_interrupt,	vga_pci_assign_interrupt),
 	DEVMETHOD(pci_find_extcap,	vga_pci_find_extcap),
+	DEVMETHOD(pci_alloc_msi,	vga_pci_alloc_msi),
+	DEVMETHOD(pci_alloc_msix,	vga_pci_alloc_msix),
+	DEVMETHOD(pci_remap_msix,	vga_pci_remap_msix),
+	DEVMETHOD(pci_release_msi,	vga_pci_release_msi),
+	DEVMETHOD(pci_msi_count,	vga_pci_msi_count),
+	DEVMETHOD(pci_msix_count,	vga_pci_msix_count),
 
 	{ 0, 0 }
 };
@@ -247,7 +404,7 @@
 static driver_t vga_pci_driver = {
 	"vgapci",
 	vga_pci_methods,
-	1,
+	sizeof(struct vga_pci_softc),
 };
 
 static devclass_t vga_devclass;
-------------- 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-stable/attachments/20090505/5557bae3/attachment.pgp
From jimmiejaz at gmail.com  Tue May  5 13:58:31 2009
From: jimmiejaz at gmail.com (Jimmie James)
Date: Tue May  5 13:58:39 2009
Subject: [PANIC] recent 7.2-STABLE when probing drm
Message-ID: <4A00409B.9030809@gmail.com>

On Tue, 2009-05-05 at 13:06 +0200, Guido Falsi wrote:
> Hi!
> 
> I'm using FreeBSD/i386 stable on a HP DC7800 PC.
> 
> It has an Intel Q35 graphic chip.
> 
> After upgrading to a recent stable I experienced a pani on boot, just
> after probing drm.
> 
> I investigated a little and found out that reverting the file
> 
> src/sys/dev/pci/pci.c
> 
> to rev. 1.355.2.9 (SVN Rev 190092) solves the crash.
> 
> I could not investigatte urther right away, but some regression was
> introduced with this rev.
> 
> Is any more information needed?

I want to add a "me too". I can't compile in a debugger as my sources 
are updated to 7.2, and any kernel built panics with the same message.
I did find this on the CURRENT mailing list, but it wont apply cleanly: 
http://www.mailinglistarchive.com/freebsd-current@freebsd.org/msg26975.html


vgapci0@pci0:0:2:0:     class=0x030000 card=0x25821043 chip=0x25828086 
rev=0x04 hdr=0x00
     vendor     = 'Intel Corporation'
     device     = '82915G/GV/GL, 82910GL Integrated Graphics Device'
     class      = display
     subclass   = VGA
vgapci1@pci0:0:2:1:     class=0x038000 card=0x25821043 chip=0x27828086 
rev=0x04 hdr=0x00
     vendor     = 'Intel Corporation'
     device     = '82915G Graphics device: 82915G/GV/910GL Express 
Chipset Family'
     class      = display

 From a 7.2-PRERELEASE kernel.

vgapci0: <VGA-compatible display> port 0x6800-0x6807 mem 
0xcfd80000-0xcfdfffff,0xd0000000-0xdfffffff,0xcfe80000-0xcfebffff at 
device 2.0 on pci0
agp0: <Intel 82915G (915G GMCH) SVGA controller> on vgapci0
drm0: <Intel i915G> on vgapci0
vgapci0: child drm0 requested pci_enable_busmaster
vgapci1: <VGA-compatible display> mem 0xcfe00000-0xcfe7ffff at device 
2.1 on pci0
vga0: <Generic ISA VGA> at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0
drm0: <Intel i915G> on vgapci0
vgapci0: child drm0 requested pci_enable_busmaster
info: [drm] AGP at 0xd0000000 256MB
info: [drm] Initialized i915 1.6.0 20080730
drm0: [ITHREAD]
drm0: [ITHREAD]

-- 
Over the years I've come to regard you as people I've met.

From terry+freebsd-stable at tmk.com  Tue May  5 14:03:12 2009
From: terry+freebsd-stable at tmk.com (terry+freebsd-stable@tmk.com)
Date: Tue May  5 14:03:19 2009
Subject: Regression in SCSI tape detection at boot in 7.2-RELEASE?
Message-ID: <01N8L7H5796S003G45@tmk.com>

  Sometime between the 7.2-PRERELEASE cycle started and 7.2-RELEASE, 
boot-time probing of tape drives (at least a Quantum DLT8000 and a
Quantum SDLT600) started generating error messages, such as these:

ahc1: <Adaptec 3960D Ultra160 SCSI adapter> port 0xd800-0xd8ff mem 0xfe1fe000-0xfe1fefff irq 25 at device 1.1 on pci2
ahc1: [ITHREAD]
aic7899: Ultra160 Wide Channel B, SCSI Id=7, 32/253 SCBs
...
Waiting 5 seconds for SCSI devices to settle
(probe21:ahc1:0:6:0): TEST UNIT READY. CDB: 0 0 0 0 0 0 
(probe21:ahc1:0:6:0): CAM Status: SCSI Status Error
(probe21:ahc1:0:6:0): SCSI Status: Check Condition
(probe21:ahc1:0:6:0): UNIT ATTENTION asc:29,2
(probe21:ahc1:0:6:0): SCSI bus reset occurred
(probe21:ahc1:0:6:0): Retrying Command (per Sense Data)
(probe21:ahc1:0:6:0): TEST UNIT READY. CDB: 0 0 0 0 0 0 
(probe21:ahc1:0:6:0): CAM Status: SCSI Status Error
(probe21:ahc1:0:6:0): SCSI Status: Check Condition
(probe21:ahc1:0:6:0): UNIT ATTENTION asc:28,0
(probe21:ahc1:0:6:0): Not ready to ready change, medium may have changed
(probe21:ahc1:0:6:0): Retrying Command (per Sense Data)
sa0 at ahc1 bus 0 target 6 lun 0
sa0: <QUANTUM SDLT600 3333> Removable Sequential Access SCSI-4 device 
sa0: 160.000MB/s transfers (80.000MHz DT, offset 120, 16bit)

  This is happening for both stand-alone and loader drives, regardless of
whether there is a tape in the drive at boot time.

  There is no problem with using the drive - no further messages are log-
ged and the drive operates properly.

  Does anyone have any idea what is causing this, and where I should look
to try to track it down?

        Terry Kennedy             http://www.tmk.com
        terry@tmk.com             New York, NY USA
From mad at madpilot.net  Tue May  5 14:12:52 2009
From: mad at madpilot.net (Guido Falsi)
Date: Tue May  5 14:12:59 2009
Subject: [PANIC] recent 7.2-STABLE when probing drm
In-Reply-To: <1241531476.47323.8.camel@buffy.york.ac.uk>
References: <20090505110624.GA83487@megatron.madpilot.net>
	<1241521951.47323.3.camel@buffy.york.ac.uk>
	<20090505121247.GN1948@deviant.kiev.zoral.com.ua>
	<1241526927.47323.5.camel@buffy.york.ac.uk>
	<1241531476.47323.8.camel@buffy.york.ac.uk>
Message-ID: <20090505141250.GA85300@megatron.madpilot.net>

On Tue, May 05, 2009 at 02:51:16PM +0100, Gavin Atkinson wrote:
> On Tue, 2009-05-05 at 13:35 +0100, Gavin Atkinson wrote:
> > [...]
> > 
> > I wonder if r189373 also needs merging?
> 
> Looking at a thread on -current, it looks like this is probably the
> case.  It's not a straight merge from head as other bits have changed,
> but you could test http://people.freebsd.org/~gavin/189373_7.diff
> (warning: compile tested only)

Tested the patch, it solves the problem. The system now boots cleanly.

Im using the PC as normal with no ill effects with this new kernel.

-- 
Guido Falsi <mad@madpilot.net>
From avg at icyb.net.ua  Tue May  5 16:45:48 2009
From: avg at icyb.net.ua (Andriy Gapon)
Date: Tue May  5 16:45:55 2009
Subject: Garbled output from kgdb?
In-Reply-To: <200905011501.40083.jhb@freebsd.org>
References: <49F8B859.7060908@umn.edu>
	<200905010947.54855.jhb@freebsd.org>	<49FB2847.406@umn.edu>
	<200905011501.40083.jhb@freebsd.org>
Message-ID: <4A006D38.50901@icyb.net.ua>

on 01/05/2009 22:01 John Baldwin said the following:
> The trace actually ends here.  There is nothing super bad here but there is a 
> big problem actually in that the idle threads cannot block on a lock, so it is
> a problem for the ACPI code to be acquiring a mutex here.  Perhaps the locks
> protecting the idle registers need to use spin locks instead.  The problem with
> blocking in the idle thread is that the scheduler assumes (even requires) that
> the idle thread is _always_ runnable.


Very interesting! So it seems that we are not having more of such crashes by a
pure luck (low probability)?

Looking at the method's signature:
ACPI_NATIVE_UINT AcpiOsAcquireLock (ACPI_SPINLOCK Handle)
I think that the name of the parameter type is a big hint.

Further, looking into ACPICA reference document:
> Wait for and acquire a spin lock. May be called from interrupt handlers, GPE
> handlers, and Fixed event handlers. Single threaded OSL implementations should
> always return AE_OK for this interface.

P.S. the comment before AcpiOsAcquireLock function (in stable/7 code) seems to be
outdated/bogus too - first of all there is no Flags parameter (it's actualy a
return value "to be used when lock is released") and, second, having ithreads is
no excuse to not care about type of blocking, and the term 'blocking' is used
incorrectly too:
/*
 * The Flags parameter seems to state whether or not caller is an ISR
 * (and thus can't block) but since we have ithreads, we don't worry
 * about potentially blocking.
 */


-- 
Andriy Gapon
From avg at icyb.net.ua  Tue May  5 16:51:43 2009
From: avg at icyb.net.ua (Andriy Gapon)
Date: Tue May  5 16:51:56 2009
Subject: Garbled output from kgdb?
In-Reply-To: <4A006D38.50901@icyb.net.ua>
References: <49F8B859.7060908@umn.edu>
	<200905010947.54855.jhb@freebsd.org>	<49FB2847.406@umn.edu>
	<200905011501.40083.jhb@freebsd.org> <4A006D38.50901@icyb.net.ua>
Message-ID: <4A006E9A.7060806@icyb.net.ua>


BTW, this issue seems to be fixed in Jung-uk's acpi patches for newer acpica
imports, but it is not fixed both in stable/7 and head.

on 05/05/2009 19:45 Andriy Gapon said the following:
> on 01/05/2009 22:01 John Baldwin said the following:
>> The trace actually ends here.  There is nothing super bad here but there is a 
>> big problem actually in that the idle threads cannot block on a lock, so it is
>> a problem for the ACPI code to be acquiring a mutex here.  Perhaps the locks
>> protecting the idle registers need to use spin locks instead.  The problem with
>> blocking in the idle thread is that the scheduler assumes (even requires) that
>> the idle thread is _always_ runnable.
> 
> 
> Very interesting! So it seems that we are not having more of such crashes by a
> pure luck (low probability)?
> 
> Looking at the method's signature:
> ACPI_NATIVE_UINT AcpiOsAcquireLock (ACPI_SPINLOCK Handle)
> I think that the name of the parameter type is a big hint.
> 
> Further, looking into ACPICA reference document:
>> Wait for and acquire a spin lock. May be called from interrupt handlers, GPE
>> handlers, and Fixed event handlers. Single threaded OSL implementations should
>> always return AE_OK for this interface.
> 
> P.S. the comment before AcpiOsAcquireLock function (in stable/7 code) seems to be
> outdated/bogus too - first of all there is no Flags parameter (it's actualy a
> return value "to be used when lock is released") and, second, having ithreads is
> no excuse to not care about type of blocking, and the term 'blocking' is used
> incorrectly too:
> /*
>  * The Flags parameter seems to state whether or not caller is an ISR
>  * (and thus can't block) but since we have ithreads, we don't worry
>  * about potentially blocking.
>  */
> 
> 


-- 
Andriy Gapon
From rsmith at xs4all.nl  Tue May  5 16:54:19 2009
From: rsmith at xs4all.nl (Roland Smith)
Date: Tue May  5 16:54:56 2009
Subject: RELENG_7 - has mergemaster changed logic since 7.2-RELEASE?
In-Reply-To: <49FFEECE.20403@FreeBSD.org>
References: <20090504225012.392fa49f.torfinn.ingolfsen@broadpark.no>
	<49FF5901.600@gmail.com> <49FFEECE.20403@FreeBSD.org>
Message-ID: <20090505165414.GA31550@slackbox.xs4all.nl>

On Tue, May 05, 2009 at 09:46:22AM +0200, Daniel Gerzo wrote:
> Manolis Kiagias wrote:
> 
> > I always use -iU too.
> > I've lost motd, passwd, group and master.passwd
> > During mergemaster -p I was asked to merge changes to some of these, and
> > still they were replaced with the newer versions. I don't know what went
> > wrong but have restored them from backup. (I always tar /etc before a
> > source upgrade). Upgrading another system using freebsd-update did not
> > cause any problem.
> 
> I have the same experience while I was upgrading a few machines 
> upgrading from RELENG_7 to RELENG_7_2. I haven't experienced when 
> upgrading from 7.1-R to 7.2-R.
> 
> Here auth.conf, csh.cshrc, hosts, crontab, syslogd.conf, passswd, 
> master.passwd, group, sysctl.conf motd and maybe some more got 
> overwritten :-( I had to restore from backups.

When upgrading from 7-STABLE to 7.2-RELEASE mergemaster -s -i -U
overwrote all the file I'd changed without asking. Luckily I keep all
config files that I've changed in a separate repository, so putting it
all back was a question of running an install script. But the change is
annoying.

Roland
-- 
R.F.Smith                                   http://www.xs4all.nl/~rsmith/
[plain text _non-HTML_ PGP/GnuPG encrypted/signed email much appreciated]
pgp: 1A2B 477F 9970 BA3C 2914  B7CE 1277 EFB0 C321 A725 (KeyID: C321A725)
-------------- 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-stable/attachments/20090505/11852549/attachment.pgp
From gpalmer at freebsd.org  Tue May  5 17:35:43 2009
From: gpalmer at freebsd.org (Gary Palmer)
Date: Tue May  5 17:35:50 2009
Subject: cvsup.uk.freebsd.org appears to not be serving
In-Reply-To: <49FEA6D1.2080503@reiteration.net>
References: <49FEA6D1.2080503@reiteration.net>
Message-ID: <20090505173539.GA58014@in-addr.com>

On Mon, May 04, 2009 at 09:26:57AM +0100, John wrote:
> Hi list, hopefully this is the right one and not -questions
> 
> cvsup.uk.freebsd.org appears to have not been serving these last few
> weeks. I get, variously, in my logs:
> 
> Parsing supfile "/etc/cvsupfile"
> Connecting to cvsup.uk.freebsd.org
> Connected to cvsup.uk.freebsd.org
> Rejected by server: Access limit exceeded; try again later
> Will retry at 03:08:08
> Retrying
> Connecting to cvsup.uk.freebsd.org
> Connected to cvsup.uk.freebsd.org
> Server software version: SNAP_16_1h
> Negotiating file attribute support
> Exchanging collection information
> Establishing passive-mode data connection
> Cannot connect to data port: Connection refused
> Will retry at 03:18:04
> Retrying
> Connecting to cvsup.uk.freebsd.org
> Connected to cvsup.uk.freebsd.org
> Server software version: SNAP_16_1h
> Negotiating file attribute support
> Exchanging collection information
> Establishing passive-mode data connection
> Cannot connect to data port: Connection refused
> Will retry at 03:37:33
> Retrying
> 
> ... on and on and on, continuously, 24/7.

Datapoint: I've been running cvsup daily against cvsup.uk.freebsd.org
without issue for a lot longer than a few weeks.  cvsup ends up running
somewhere between 6am and 8am and its been a while since I saw any
access limit problems.

Regards,

Gary
From rnoland at FreeBSD.org  Tue May  5 17:48:46 2009
From: rnoland at FreeBSD.org (Robert Noland)
Date: Tue May  5 17:48:53 2009
Subject: [PANIC] recent 7.2-STABLE when probing drm
In-Reply-To: <1241526927.47323.5.camel@buffy.york.ac.uk>
References: <20090505110624.GA83487@megatron.madpilot.net>
	<1241521951.47323.3.camel@buffy.york.ac.uk>
	<20090505121247.GN1948@deviant.kiev.zoral.com.ua>
	<1241526927.47323.5.camel@buffy.york.ac.uk>
Message-ID: <1241545705.1828.25.camel@balrog.2hip.net>

On Tue, 2009-05-05 at 13:35 +0100, Gavin Atkinson wrote:
> On Tue, 2009-05-05 at 15:12 +0300, Kostik Belousov wrote:
> > On Tue, May 05, 2009 at 12:12:31PM +0100, Gavin Atkinson wrote:
> > > On Tue, 2009-05-05 at 13:06 +0200, Guido Falsi wrote:
> > > > Hi!
> > > > 
> > > > I'm using FreeBSD/i386 stable on a HP DC7800 PC.
> > > > 
> > > > It has an Intel Q35 graphic chip.
> > > > 
> > > > After upgrading to a recent stable I experienced a pani on boot, just
> > > > after probing drm.
> > > > 
> > > > I investigated a little and found out that reverting the file
> > > > 
> > > > src/sys/dev/pci/pci.c
> > > > 
> > > > to rev. 1.355.2.9 (SVN Rev 190092) solves the crash.
> > > > 
> > > > I could not investigatte urther right away, but some regression was
> > > > introduced with this rev.
> > > > 
> > > > Is any more information needed?
> > > 
> > > When it panics, can you please type "bt" (assuming you have the debugger
> > > compiled in) and show the output?
> > 
> > I have this too. I have dump too.
> > 
> > drm0: <Intel i945GM> on vgapci0
> > panic: resource_list_alloc: resource entry is busy
> > KDB: stack backtrace:
> > db_trace_self_wrapper(c07214ff,c2b46764,c04c928f,c071f823,c078b080,...) at 0xc044df46 = db_trace_self_wrapper+0x26
> > kdb_backtrace(c071f823,c078b080,c07211b1,c2b46770,c2b46770,...) at 0xc04f41f9 = kdb_backtrace+0x29
> > panic(c07211b1,3,10,c04e9484,c2e37000,...) at 0xc04c928f = panic+0xaf
> > resource_list_alloc(c2cffb04,c2d00a80,c2d00c80,3,c2d2a1fc,...) at 0xc04f0c06 = resource_list_alloc+0xd6
> > pci_alloc_resource(c2d00a80,c2d00c80,3,c2d2a1fc,0,ffffffff,1,4) at 0xc045a2d1 = pci_alloc_resource+0x581
> > bus_alloc_resource(c2d00c80,3,c2d2a1fc,0,ffffffff,...) at 0xc04f0a8c = bus_alloc_resource+0x7c
> > vga_pci_alloc_resource(c2d00c80,c2cfa080,3,c2d2a1fc,0,ffffffff,1,4) at 0xc04600ab = vga_pci_alloc_resource+0x3b
> [...]
> 
> I wonder if r189373 also needs merging?

Yes, that looks right, resources are owned by both agp and drm on Intel.

robert.

> 
> Gavin
> _______________________________________________
> freebsd-stable@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org"
-- 
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-stable/attachments/20090505/3e7247d8/attachment.pgp
From cristiano.deana at gmail.com  Tue May  5 18:02:28 2009
From: cristiano.deana at gmail.com (Cristiano Deana)
Date: Tue May  5 18:02:38 2009
Subject: RELENG_7 - has mergemaster changed logic since 7.2-RELEASE?
In-Reply-To: <20090504225012.392fa49f.torfinn.ingolfsen@broadpark.no>
References: <20090504225012.392fa49f.torfinn.ingolfsen@broadpark.no>
Message-ID: <d8a4930a0905051034k1c9b6d2id72663457c6b8a1c@mail.gmail.com>

On Mon, May 4, 2009 at 10:50 PM, Torfinn Ingolfsen
<torfinn.ingolfsen@broadpark.no> wrote:

> I just upgraded from 7.2-prerelease (as of 20090401) to 7.2-stable as
> of today, using csup and building world.

i upgraded fw machines from _7_1 to _7_2. no problem at all here.
did mergemaster is changed from -RELEASE to -STABLE?

hint:
use always -P option

-- 
Cris, member of G.U.F.I
Italian FreeBSD User Group
http://www.gufi.org/
From pj at smo.de  Tue May  5 20:08:08 2009
From: pj at smo.de (Philipp Ost)
Date: Tue May  5 20:08:21 2009
Subject: Radeon 9250 DRM in 7.2-RELEASE
In-Reply-To: <49FF28BC.5080304@comcast.net>
References: <49FF28BC.5080304@comcast.net>
Message-ID: <49FF4E49.4000902@smo.de>

Steve Polyack wrote:
> I upgraded my workstation (via source) to 7.2-RELEASE from 7.1-RELEASE 
> about a day ago.  After the upgrade procedure, I'm having no luck with 
> using DRM in X11.  It worked fine before and gave reasonable 
> performance.  Now when I start up X with DRI enabled, both of my screens 
> display garbage.  The mouse pointer is also not visible.
> 
> I'm using a PCI Radeon 9250.  I can get more details if necessary.  I 
> can also try to revert the kernel DRM module code to 7.1.
> 
>  From dmesg:
> drm2: <ATI Radeon RV280 9250> on vgapci2
> vgapci2: child drm2 requested pci_enable_busmaster
> info: [drm] Initialized radeon 1.29.0 20080528
> info: [drm] Setting GART location based on new memory map
> info: [drm] Loading R200 Microcode
> info: [drm] writeback test succeeded in 2 usecs
> drm2: [ITHREAD]
> 
> Any ideas or suggestions would be appreciated.  Thanks.

I'm using a AGP Radeon 9250. Ever since I enabled direct rendering I get 
similar notifications in dmesg:
info: [drm] Setting GART location based on new memory map
info: [drm] Loading R200 Microcode
info: [drm] writeback test succeeded in 1 usecs
drm0: [ITHREAD]

$ glxinfo | grep rendering
direct rendering: Yes
$

I'm running 7.2-Prerelease (i386) from May, 1.

BTW: hald is not running here, I tweaked my xorg.conf as per the entry 
20090123 in ports/UPDATING.

HTH,
Philipp
From jkim at FreeBSD.org  Tue May  5 20:09:47 2009
From: jkim at FreeBSD.org (Jung-uk Kim)
Date: Tue May  5 20:09:59 2009
Subject: Garbled output from kgdb?
In-Reply-To: <4A006E9A.7060806@icyb.net.ua>
References: <49F8B859.7060908@umn.edu> <4A006D38.50901@icyb.net.ua>
	<4A006E9A.7060806@icyb.net.ua>
Message-ID: <200905051609.38689.jkim@FreeBSD.org>

On Tuesday 05 May 2009 12:51 pm, Andriy Gapon wrote:
> BTW, this issue seems to be fixed in Jung-uk's acpi patches for
> newer acpica imports, but it is not fixed both in stable/7 and
> head.

Yes, it was fixed in my patchsets long ago, which uses spin lock for 
AcpiOsAcquireLock(). :-)

Jung-uk Kim

> on 05/05/2009 19:45 Andriy Gapon said the following:
> > on 01/05/2009 22:01 John Baldwin said the following:
> >> The trace actually ends here.  There is nothing super bad here
> >> but there is a big problem actually in that the idle threads
> >> cannot block on a lock, so it is a problem for the ACPI code to
> >> be acquiring a mutex here.  Perhaps the locks protecting the
> >> idle registers need to use spin locks instead.  The problem with
> >> blocking in the idle thread is that the scheduler assumes (even
> >> requires) that the idle thread is _always_ runnable.
> >
> > Very interesting! So it seems that we are not having more of such
> > crashes by a pure luck (low probability)?
> >
> > Looking at the method's signature:
> > ACPI_NATIVE_UINT AcpiOsAcquireLock (ACPI_SPINLOCK Handle)
> > I think that the name of the parameter type is a big hint.
> >
> > Further, looking into ACPICA reference document:
> >> Wait for and acquire a spin lock. May be called from interrupt
> >> handlers, GPE handlers, and Fixed event handlers. Single
> >> threaded OSL implementations should always return AE_OK for this
> >> interface.
> >
> > P.S. the comment before AcpiOsAcquireLock function (in stable/7
> > code) seems to be outdated/bogus too - first of all there is no
> > Flags parameter (it's actualy a return value "to be used when
> > lock is released") and, second, having ithreads is no excuse to
> > not care about type of blocking, and the term 'blocking' is used
> > incorrectly too:
> > /*
> >  * The Flags parameter seems to state whether or not caller is an
> > ISR * (and thus can't block) but since we have ithreads, we don't
> > worry * about potentially blocking.
> >  */
From jhb at FreeBSD.org  Tue May  5 20:23:31 2009
From: jhb at FreeBSD.org (John Baldwin)
Date: Tue May  5 20:24:10 2009
Subject: Garbled output from kgdb?
In-Reply-To: <200905051609.38689.jkim@FreeBSD.org>
References: <49F8B859.7060908@umn.edu> <4A006D38.50901@icyb.net.ua>
	<4A006E9A.7060806@icyb.net.ua>
	<200905051609.38689.jkim@FreeBSD.org>
Message-ID: <4A00A042.20806@FreeBSD.org>

Jung-uk Kim wrote:
> On Tuesday 05 May 2009 12:51 pm, Andriy Gapon wrote:
>> BTW, this issue seems to be fixed in Jung-uk's acpi patches for
>> newer acpica imports, but it is not fixed both in stable/7 and
>> head.
> 
> Yes, it was fixed in my patchsets long ago, which uses spin lock for 
> AcpiOsAcquireLock(). :-)

I'm not sure all ACPI locks need to be spin locks, but any locks used by 
the idle code must be spin locks.  Regardless, are you going to import a 
newer ACPI-CA and commit your patches soon?  It sounds like several 
things are fixed in the outstanding patches by now including both this 
and the problem with the Alias() operator.

> Jung-uk Kim
> 
>> on 05/05/2009 19:45 Andriy Gapon said the following:
>>> on 01/05/2009 22:01 John Baldwin said the following:
>>>> The trace actually ends here.  There is nothing super bad here
>>>> but there is a big problem actually in that the idle threads
>>>> cannot block on a lock, so it is a problem for the ACPI code to
>>>> be acquiring a mutex here.  Perhaps the locks protecting the
>>>> idle registers need to use spin locks instead.  The problem with
>>>> blocking in the idle thread is that the scheduler assumes (even
>>>> requires) that the idle thread is _always_ runnable.
>>> Very interesting! So it seems that we are not having more of such
>>> crashes by a pure luck (low probability)?
>>>
>>> Looking at the method's signature:
>>> ACPI_NATIVE_UINT AcpiOsAcquireLock (ACPI_SPINLOCK Handle)
>>> I think that the name of the parameter type is a big hint.
>>>
>>> Further, looking into ACPICA reference document:
>>>> Wait for and acquire a spin lock. May be called from interrupt
>>>> handlers, GPE handlers, and Fixed event handlers. Single
>>>> threaded OSL implementations should always return AE_OK for this
>>>> interface.
>>> P.S. the comment before AcpiOsAcquireLock function (in stable/7
>>> code) seems to be outdated/bogus too - first of all there is no
>>> Flags parameter (it's actualy a return value "to be used when
>>> lock is released") and, second, having ithreads is no excuse to
>>> not care about type of blocking, and the term 'blocking' is used
>>> incorrectly too:
>>> /*
>>>  * The Flags parameter seems to state whether or not caller is an
>>> ISR * (and thus can't block) but since we have ithreads, we don't
>>> worry * about potentially blocking.
>>>  */


-- 
John Baldwin
From jhb at FreeBSD.org  Tue May  5 20:24:29 2009
From: jhb at FreeBSD.org (John Baldwin)
Date: Tue May  5 20:24:36 2009
Subject: [PANIC] recent 7.2-STABLE when probing drm
In-Reply-To: <20090505121247.GN1948@deviant.kiev.zoral.com.ua>
References: <20090505110624.GA83487@megatron.madpilot.net>
	<1241521951.47323.3.camel@buffy.york.ac.uk>
	<20090505121247.GN1948@deviant.kiev.zoral.com.ua>
Message-ID: <4A00A07D.9090401@FreeBSD.org>

Kostik Belousov wrote:
> On Tue, May 05, 2009 at 12:12:31PM +0100, Gavin Atkinson wrote:
>> On Tue, 2009-05-05 at 13:06 +0200, Guido Falsi wrote:
>>> Hi!
>>>
>>> I'm using FreeBSD/i386 stable on a HP DC7800 PC.
>>>
>>> It has an Intel Q35 graphic chip.
>>>
>>> After upgrading to a recent stable I experienced a pani on boot, just
>>> after probing drm.
>>>
>>> I investigated a little and found out that reverting the file
>>>
>>> src/sys/dev/pci/pci.c
>>>
>>> to rev. 1.355.2.9 (SVN Rev 190092) solves the crash.
>>>
>>> I could not investigatte urther right away, but some regression was
>>> introduced with this rev.
>>>
>>> Is any more information needed?
>> When it panics, can you please type "bt" (assuming you have the debugger
>> compiled in) and show the output?
> 
> I have this too. I have dump too.

Sorry about that.  I merged the fixes to vgapci this morning so this 
should be fixed now.

-- 
John Baldwin
From jkim at FreeBSD.org  Tue May  5 20:56:35 2009
From: jkim at FreeBSD.org (Jung-uk Kim)
Date: Tue May  5 20:56:47 2009
Subject: Garbled output from kgdb?
In-Reply-To: <4A00A042.20806@FreeBSD.org>
References: <49F8B859.7060908@umn.edu> <200905051609.38689.jkim@FreeBSD.org>
	<4A00A042.20806@FreeBSD.org>
Message-ID: <200905051656.27439.jkim@FreeBSD.org>

On Tuesday 05 May 2009 04:23 pm, John Baldwin wrote:
> Jung-uk Kim wrote:
> > On Tuesday 05 May 2009 12:51 pm, Andriy Gapon wrote:
> >> BTW, this issue seems to be fixed in Jung-uk's acpi patches for
> >> newer acpica imports, but it is not fixed both in stable/7 and
> >> head.
> >
> > Yes, it was fixed in my patchsets long ago, which uses spin lock
> > for AcpiOsAcquireLock(). :-)
>
> I'm not sure all ACPI locks need to be spin locks, but any locks
> used by the idle code must be spin locks.

There are several types of ACPI locks internally and externally.  The 
AcpiOs{Create,Acquire,Release}Lock() is just one of them, which is a 
spin lock and it is mostly used for interrupt handlers, e.g., GPE and 
HW.  I have to say there were a lot of confusions between ACPI 
developers because it was not well-documented.  In fact, I personally 
had to exchange lengthy e-mails with Intel engineers to understand 
the meaning of these myself.  Now Intel has documented everything you 
need to know about ACPI-CA for OS developers:

http://git.moblin.org/cgit.cgi/acpica/tree/documents

> Regardless, are you going to import a newer ACPI-CA and commit your
> patches soon?  It sounds like several things are fixed in the
> outstanding patches by now including both this and the problem with
> the Alias() operator. 

Unfortunately, I don't have much time to work on it recently.  Couple 
of developers volunteered to do the actual import work although I 
haven't heard from them in a while. :-(

Jung-uk Kim
From scrappy at hub.org  Tue May  5 21:18:44 2009
From: scrappy at hub.org (Marc G. Fournier)
Date: Tue May  5 21:18:51 2009
Subject: server hangs, break to DDB hangs ...
Message-ID: <20090505174426.M18967@hub.org>


I have two HP Proliant servers that, until recently, have run very stable 
... within the past 2 months, the servers hang after anywhere from 10hrs 
through 19 days (one just hung up this aft) ...

vmstat, about the time it hangs, shows:

# cat 16/vmstat.out
  procs      memory      page                    disks     faults 
cpu
  r b w     avm    fre   flt  re  pi  po    fr  sr da0 pa0   in   sy   cs 
us sy id
109 156 1 17035752   62152   803  19   5   3  1907 1785   0   0  437  294 
853 50 28 22
  2 332 5 17109460   23056 147346 4319 2061 3139 44030 6539423 1029   0 
4027 398263 38616 40 58  2
  0 32 8 17110588   23052   626 4216  35 203   344 745 572   0  597 16414 
5741  4 10 86
  0 35 14 17110592   23084   446 5102   2 410   210 1596 540   0  516 31616 
4461  4 10 85
  0 25 20 17110588   23032   196 7734   2 280    22 1179 445   0  434 34992 
3543  5  7 88

with, by the time I was able to reboot it, the final vmstat was showing:

# cat 46/vmstat.out
  procs      memory      page                    disks     faults 
cpu
  r b w     avm    fre   flt  re  pi  po    fr  sr da0 pa0   in   sy   cs 
us sy id
  1 492 1595 24292424   99564   809  20   5   4  1909 1896   0   0  437 
737  863 50 28 22
  1 399 1596 24285028   90708  6195 152 393  76  3185 1061 414   0  683 
54948 32062  8  9 82
  2 231 1595 24276684   85164  4709  94 219 152  3729 642 554   0  420 
39442 20612  7 12 80
  1 174 1595 24259144   71288  8204 143 314 158  3379 1314 605   0  547 
36228 21219 11 18 71
  2 199 1593 24242500   72116  4637  52 251 195  3957 1609 496   0  383 
32305 20225  6 12 82

When I try and break to DDB, all I get on the screen is:

===
KDB: enter: Break sequence on conec
===

And then it hangs there ...

I have ps listings that go back for just over an hour before I rebooted 
(the script runs every 5 minutes, or is supposed to):

# ls -lt */ps*
-rw-r--r--  1 root  wheel  509908 May  5 16:47 46/ps.out
-rw-r--r--  1 root  wheel  450704 May  5 16:35 35/ps.out
-rw-r--r--  1 root  wheel  424047 May  5 16:32 26/ps.out
-rw-r--r--  1 root  wheel  329105 May  5 16:21 21/ps.out
-rw-r--r--  1 root  wheel  278189 May  5 16:17 16/ps.out
-rw-r--r--  1 root  wheel  246726 May  5 15:55 55/ps.out
-rw-r--r--  1 root  wheel  231937 May  5 15:50 50/ps.out
-rw-r--r--  1 root  wheel  240260 May  5 15:45 45/ps.out
-rw-r--r--  1 root  wheel  234731 May  5 15:40 40/ps.out
-rw-r--r--  1 root  wheel  233719 May  5 15:30 30/ps.out
-rw-r--r--  1 root  wheel  222749 May  5 15:25 25/ps.out
-rw-r--r--  1 root  wheel  231617 May  5 15:20 20/ps.out


Looking at swap usage over that period, its obvious that something is 
sucking back the RAM reasonably fast:

neptune# cat 46/swap.out
Device          512-blocks     Used    Avail Capacity
/dev/da0s1b       16777216 13789464  2987752    82%
neptune# cat 35/swap.out
Device          512-blocks     Used    Avail Capacity
/dev/da0s1b       16777216 12482312  4294904    74%
neptune# cat 26/swap.out
Device          512-blocks     Used    Avail Capacity
/dev/da0s1b       16777216 12351920  4425296    74%
neptune# cat 21/swap.out
Device          512-blocks     Used    Avail Capacity
/dev/da0s1b       16777216  7807240  8969976    47%
neptune# cat 16/swap.out
Device          512-blocks     Used    Avail Capacity
/dev/da0s1b       16777216  5752832 11024384    34%
neptune# cat 55/swap.out
Device          512-blocks     Used    Avail Capacity
/dev/da0s1b       16777216  4398928 12378288    26%

But I'm not sure what to look at in the ps output to determine what is 
going awry here ...

I'm running

      7.1-STABLE FreeBSD 7.1-STABLE #14: Sat Mar 28 00:05:19 ADT 2009

On the server that just hung, so will upgrade to the latest 7.2-RELEASE 
next, but ... if someone can give me pointers at what else I should be 
checking for, or something in the ps listings that I should be looking 
for?  My monitor script is currently doing:

/usr/sbin/jls > jaillist.out
/bin/ps -aucxHl -O jid > ps.out
/usr/sbin/pstat -s > swap.out
/usr/bin/vmstat 1 5 > vmstat.out
/usr/bin/awk '{print $15}' /proc/*/status | /usr/bin/sort | /usr/bin/uniq 
-c > vps_dist.out

Any pointers appreciated ...

Thx

----
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 dougb at FreeBSD.org  Tue May  5 21:40:43 2009
From: dougb at FreeBSD.org (Doug Barton)
Date: Tue May  5 21:40:49 2009
Subject: RELENG_7 - has mergemaster changed logic since 7.2-RELEASE?
In-Reply-To: <d8a4930a0905051034k1c9b6d2id72663457c6b8a1c@mail.gmail.com>
References: <20090504225012.392fa49f.torfinn.ingolfsen@broadpark.no>
	<d8a4930a0905051034k1c9b6d2id72663457c6b8a1c@mail.gmail.com>
Message-ID: <4A00B0C1.4060009@FreeBSD.org>

Cristiano Deana wrote:
> On Mon, May 4, 2009 at 10:50 PM, Torfinn Ingolfsen
> <torfinn.ingolfsen@broadpark.no> wrote:
> 
>> I just upgraded from 7.2-prerelease (as of 20090401) to 7.2-stable as
>> of today, using csup and building world.
> 
> i upgraded fw machines from _7_1 to _7_2. no problem at all here.
> did mergemaster is changed from -RELEASE to -STABLE?

The last change was before the 7.2-release cycle started (6 weeks ago).

> hint:
> use always -P option

I agree, it's a good thing to have in your .mergemasterrc
(PRESERVE_FILES=yes).


Doug

-- 

    This .signature sanitized for your protection

From jkim at FreeBSD.org  Tue May  5 21:43:12 2009
From: jkim at FreeBSD.org (Jung-uk Kim)
Date: Tue May  5 21:43:19 2009
Subject: Garbled output from kgdb?
In-Reply-To: <200905051609.38689.jkim@FreeBSD.org>
References: <49F8B859.7060908@umn.edu> <4A006E9A.7060806@icyb.net.ua>
	<200905051609.38689.jkim@FreeBSD.org>
Message-ID: <200905051743.03520.jkim@FreeBSD.org>

On Tuesday 05 May 2009 04:09 pm, Jung-uk Kim wrote:
> On Tuesday 05 May 2009 12:51 pm, Andriy Gapon wrote:
> > BTW, this issue seems to be fixed in Jung-uk's acpi patches for
> > newer acpica imports, but it is not fixed both in stable/7 and
> > head.
>
> Yes, it was fixed in my patchsets long ago, which uses spin lock
> for AcpiOsAcquireLock(). :-)

The attached patch is for -STABLE.  Note that it is only compile 
tested on amd64.

Jung-uk Kim
-------------- next part --------------
--- sys/dev/acpica/Osd/OsdSynch.c	(revision 191834)
+++ sys/dev/acpica/Osd/OsdSynch.c	(working copy)
@@ -1,6 +1,7 @@
 /*-
  * Copyright (c) 2000 Michael Smith
  * Copyright (c) 2000 BSDi
+ * Copyright (c) 2007-2009 Jung-uk Kim <jkim@FreeBSD.org>
  * All rights reserved.
  *
  * Redistribution and use in source and binary forms, with or without
@@ -35,365 +36,313 @@
 #include <contrib/dev/acpica/acpi.h>
 
 #include "opt_acpi.h"
+#include <sys/condvar.h>
 #include <sys/kernel.h>
-#include <sys/malloc.h>
-#include <sys/sysctl.h>
 #include <sys/lock.h>
+#include <sys/malloc.h>
 #include <sys/mutex.h>
+#include <sys/sx.h>
 
-#define _COMPONENT	ACPI_OS_SERVICES
+#define	_COMPONENT	ACPI_OS_SERVICES
 ACPI_MODULE_NAME("SYNCH")
 
 MALLOC_DEFINE(M_ACPISEM, "acpisem", "ACPI semaphore");
 
-#define AS_LOCK(as)	mtx_lock(&(as)->as_mtx)
-#define AS_UNLOCK(as)	mtx_unlock(&(as)->as_mtx)
+/* Convert microseconds to hz. */
+static int
+timeout2hz(long timo)
+{
+	struct timeval	tv;
 
+	tv.tv_sec = timo / 1000000;
+	tv.tv_usec = timo % 1000000;
+
+	return (tvtohz(&tv));
+}
+
+/* Adjust timeout from the previous uptime. */
+static long
+adjust_timeout(long *tmop, struct timeval *tvp)
+{
+	struct timeval	now, slept;
+
+	getmicrouptime(&now);
+	slept = now;
+	timevalsub(&slept, tvp);
+	*tmop -= slept.tv_sec * 1000000 + slept.tv_usec;
+	*tvp = now;
+
+	return (*tmop);
+}
+
 /*
- * Simple counting semaphore implemented using a mutex.  (Subsequently used
- * in the OSI code to implement a mutex.  Go figure.)
+ * ACPI_SEMAPHORE: a sleepable counting semaphore
  */
 struct acpi_semaphore {
-    struct mtx	as_mtx;
-    UINT32	as_units;
-    UINT32	as_maxunits;
-    UINT32	as_pendings;
-    UINT32	as_resetting;
-    UINT32	as_timeouts;
+	struct sx	as_lock;
+	char		as_name[32];
+	struct cv	as_cv;
+	UINT32		as_units;
+	UINT32		as_maxunits;
 };
 
-/* Default number of maximum pending threads. */
-#ifndef ACPI_NO_SEMAPHORES
-#ifndef ACPI_SEMAPHORES_MAX_PENDING
-#define ACPI_SEMAPHORES_MAX_PENDING	4
-#endif
-
-static int	acpi_semaphore_debug = 0;
-TUNABLE_INT("debug.acpi_semaphore_debug", &acpi_semaphore_debug);
-SYSCTL_DECL(_debug_acpi);
-SYSCTL_INT(_debug_acpi, OID_AUTO, semaphore_debug, CTLFLAG_RW,
-	   &acpi_semaphore_debug, 0, "Enable ACPI semaphore debug messages");
-#endif /* !ACPI_NO_SEMAPHORES */
-
 ACPI_STATUS
 AcpiOsCreateSemaphore(UINT32 MaxUnits, UINT32 InitialUnits,
     ACPI_SEMAPHORE *OutHandle)
 {
-#ifndef ACPI_NO_SEMAPHORES
-    struct acpi_semaphore	*as;
+	struct acpi_semaphore	*as;
 
-    ACPI_FUNCTION_TRACE((char *)(uintptr_t)__func__);
+	ACPI_FUNCTION_TRACE((char *)(uintptr_t)__func__);
 
-    if (OutHandle == NULL)
-	return_ACPI_STATUS (AE_BAD_PARAMETER);
-    if (InitialUnits > MaxUnits)
-	return_ACPI_STATUS (AE_BAD_PARAMETER);
+	if (OutHandle == NULL || InitialUnits > MaxUnits)
+		return_ACPI_STATUS (AE_BAD_PARAMETER);
 
-    if ((as = malloc(sizeof(*as), M_ACPISEM, M_NOWAIT | M_ZERO)) == NULL)
-	return_ACPI_STATUS (AE_NO_MEMORY);
+	if ((as = malloc(sizeof(*as), M_ACPISEM, M_NOWAIT | M_ZERO)) == NULL)
+		return_ACPI_STATUS (AE_NO_MEMORY);
 
-    mtx_init(&as->as_mtx, "ACPI semaphore", NULL, MTX_DEF);
-    as->as_units = InitialUnits;
-    as->as_maxunits = MaxUnits;
-    as->as_pendings = as->as_resetting = as->as_timeouts = 0;
+	snprintf(as->as_name, sizeof(as->as_name), "ACPI sema (%p)", as);
+	sx_init(&as->as_lock, as->as_name);
+	cv_init(&as->as_cv, as->as_name);
+	as->as_units = InitialUnits;
+	as->as_maxunits = MaxUnits;
 
-    ACPI_DEBUG_PRINT((ACPI_DB_MUTEX,
-	"created semaphore %p max %d, initial %d\n", 
-	as, InitialUnits, MaxUnits));
+	ACPI_DEBUG_PRINT((ACPI_DB_MUTEX,
+	    "created semaphore %p, max %u, initial %u\n", 
+	    as, InitialUnits, MaxUnits));
 
-    *OutHandle = (ACPI_HANDLE)as;
-#else
-    *OutHandle = (ACPI_HANDLE)OutHandle;
-#endif /* !ACPI_NO_SEMAPHORES */
+	*OutHandle = (ACPI_SEMAPHORE)as;
 
-    return_ACPI_STATUS (AE_OK);
+	return_ACPI_STATUS (AE_OK);
 }
 
 ACPI_STATUS
 AcpiOsDeleteSemaphore(ACPI_SEMAPHORE Handle)
 {
-#ifndef ACPI_NO_SEMAPHORES
-    struct acpi_semaphore *as = (struct acpi_semaphore *)Handle;
+	struct acpi_semaphore	*as = (struct acpi_semaphore *)Handle;
 
-    ACPI_FUNCTION_TRACE((char *)(uintptr_t)__func__);
+	ACPI_FUNCTION_TRACE((char *)(uintptr_t)__func__);
 
-    ACPI_DEBUG_PRINT((ACPI_DB_MUTEX, "destroyed semaphore %p\n", as));
-    mtx_destroy(&as->as_mtx);
-    free(Handle, M_ACPISEM);
-#endif /* !ACPI_NO_SEMAPHORES */
+	ACPI_DEBUG_PRINT((ACPI_DB_MUTEX, "delete semaphore %p\n", as));
 
-    return_ACPI_STATUS (AE_OK);
+	if (as != NULL) {
+		sx_destroy(&as->as_lock);
+		cv_destroy(&as->as_cv);
+		free(as, M_ACPISEM);
+		return_ACPI_STATUS (AE_OK);
+	} else
+		ACPI_DEBUG_PRINT((ACPI_DB_MUTEX,
+		    "cannot delete null semaphore\n"));
+
+	return_ACPI_STATUS (AE_BAD_PARAMETER);
 }
 
-/*
- * This implementation has a bug, in that it has to stall for the entire
- * timeout before it will return AE_TIME.  A better implementation would
- * use getmicrotime() to correctly adjust the timeout after being woken up.
- */
 ACPI_STATUS
 AcpiOsWaitSemaphore(ACPI_SEMAPHORE Handle, UINT32 Units, UINT16 Timeout)
 {
-#ifndef ACPI_NO_SEMAPHORES
-    ACPI_STATUS			result;
-    struct acpi_semaphore	*as = (struct acpi_semaphore *)Handle;
-    int				rv, tmo;
-    struct timeval		timeouttv, currenttv, timelefttv;
+	struct acpi_semaphore	*as = (struct acpi_semaphore *)Handle;
+	struct timeval		tv;
+	long			tmo;
 
-    ACPI_FUNCTION_TRACE((char *)(uintptr_t)__func__);
+	ACPI_FUNCTION_TRACE((char *)(uintptr_t)__func__);
 
-    if (as == NULL)
-	return_ACPI_STATUS (AE_BAD_PARAMETER);
+	if (as == NULL || Units == 0)
+		return_ACPI_STATUS (AE_BAD_PARAMETER);
 
-    if (cold)
-	return_ACPI_STATUS (AE_OK);
+	sx_xlock(&as->as_lock);
+	ACPI_DEBUG_PRINT((ACPI_DB_MUTEX,
+	    "get %u units from semaphore %p (has %u), timeout %u\n",
+	    Units, as, as->as_units, Timeout));
 
-#if 0
-    if (as->as_units < Units && as->as_timeouts > 10) {
-	printf("%s: semaphore %p too many timeouts, resetting\n", __func__, as);
-	AS_LOCK(as);
-	as->as_units = as->as_maxunits;
-	if (as->as_pendings)
-	    as->as_resetting = 1;
-	as->as_timeouts = 0;
-	wakeup(as);
-	AS_UNLOCK(as);
-	return_ACPI_STATUS (AE_TIME);
-    }
-
-    if (as->as_resetting)
-	return_ACPI_STATUS (AE_TIME);
-#endif
-
-    /* a timeout of ACPI_WAIT_FOREVER means "forever" */
-    if (Timeout == ACPI_WAIT_FOREVER) {
-	tmo = 0;
-	timeouttv.tv_sec = ((0xffff/1000) + 1);	/* cf. ACPI spec */
-	timeouttv.tv_usec = 0;
-    } else {
-	/* compute timeout using microseconds per tick */
-	tmo = (Timeout * 1000) / (1000000 / hz);
-	if (tmo <= 0)
-	    tmo = 1;
-	timeouttv.tv_sec  = Timeout / 1000;
-	timeouttv.tv_usec = (Timeout % 1000) * 1000;
-    }
-
-    /* calculate timeout value in timeval */
-    getmicrotime(&currenttv);
-    timevaladd(&timeouttv, &currenttv);
-
-    AS_LOCK(as);
-    ACPI_DEBUG_PRINT((ACPI_DB_MUTEX,
-	"get %d units from semaphore %p (has %d), timeout %d\n",
-	Units, as, as->as_units, Timeout));
-    for (;;) {
 	if (as->as_maxunits == ACPI_NO_UNIT_LIMIT) {
-	    result = AE_OK;
-	    break;
+		sx_xunlock(&as->as_lock);
+		return_ACPI_STATUS (AE_OK);
 	}
-	if (as->as_units >= Units) {
-	    as->as_units -= Units;
-	    result = AE_OK;
-	    break;
+	if (as->as_maxunits < Units) {
+		ACPI_DEBUG_PRINT((ACPI_DB_MUTEX, "exceeded max units %u\n",
+		    as->as_maxunits));
+		sx_xunlock(&as->as_lock);
+		return_ACPI_STATUS (AE_LIMIT);
 	}
 
-	/* limit number of pending threads */
-	if (as->as_pendings >= ACPI_SEMAPHORES_MAX_PENDING) {
-	    result = AE_TIME;
-	    break;
+	switch (Timeout) {
+	case ACPI_DO_NOT_WAIT:
+		if (as->as_units >= Units) {
+			as->as_units -= Units;
+			sx_xunlock(&as->as_lock);
+			return_ACPI_STATUS (AE_OK);
+		}
+		break;
+	case ACPI_WAIT_FOREVER:
+		while (as->as_units < Units)
+			cv_wait(&as->as_cv, &as->as_lock);
+		as->as_units -= Units;
+		sx_xunlock(&as->as_lock);
+		return_ACPI_STATUS (AE_OK);
+	default:
+		tmo = (long)Timeout * 1000;
+		getmicrouptime(&tv);
+		do {
+			if (as->as_units >= Units) {
+				as->as_units -= Units;
+				sx_xunlock(&as->as_lock);
+				return_ACPI_STATUS (AE_OK);
+			}
+			if (cv_timedwait(&as->as_cv, &as->as_lock,
+			    timeout2hz(tmo)) == EWOULDBLOCK)
+				break;
+		} while (adjust_timeout(&tmo, &tv) > 0);
 	}
+	sx_xunlock(&as->as_lock);
 
-	/* if timeout values of zero is specified, return immediately */
-	if (Timeout == 0) {
-	    result = AE_TIME;
-	    break;
-	}
+	return_ACPI_STATUS (AE_TIME);
+}
 
-	ACPI_DEBUG_PRINT((ACPI_DB_MUTEX,
-	    "semaphore blocked, calling msleep(%p, %p, %d, \"acsem\", %d)\n",
-	    as, &as->as_mtx, PCATCH, tmo));
+ACPI_STATUS
+AcpiOsSignalSemaphore(ACPI_SEMAPHORE Handle, UINT32 Units)
+{
+	struct acpi_semaphore	*as = (struct acpi_semaphore *)Handle;
 
-	as->as_pendings++;
+	ACPI_FUNCTION_TRACE((char *)(uintptr_t)__func__);
 
-	if (acpi_semaphore_debug) {
-	    printf("%s: Sleep %d, pending %d, semaphore %p, thread %d\n",
-		__func__, Timeout, as->as_pendings, as, AcpiOsGetThreadId());
-	}
+	if (as == NULL || Units == 0)
+		return_ACPI_STATUS (AE_BAD_PARAMETER);
 
-	rv = msleep(as, &as->as_mtx, PCATCH, "acsem", tmo);
+	sx_xlock(&as->as_lock);
+	ACPI_DEBUG_PRINT((ACPI_DB_MUTEX,
+	    "return %u units to semaphore %p (has %u)\n",
+	    Units, as, as->as_units));
 
-	as->as_pendings--;
-
-#if 0
-	if (as->as_resetting) {
-	    /* semaphore reset, return immediately */
-	    if (as->as_pendings == 0) {
-		as->as_resetting = 0;
-	    }
-	    result = AE_TIME;
-	    break;
+	if (as->as_maxunits == ACPI_NO_UNIT_LIMIT) {
+		sx_xunlock(&as->as_lock);
+		return_ACPI_STATUS (AE_OK);
 	}
-#endif
-
-	ACPI_DEBUG_PRINT((ACPI_DB_MUTEX, "msleep(%d) returned %d\n", tmo, rv));
-	if (rv == EWOULDBLOCK) {
-	    result = AE_TIME;
-	    break;
+	if (as->as_maxunits < Units ||
+	    as->as_maxunits - Units < as->as_units) {
+		ACPI_DEBUG_PRINT((ACPI_DB_MUTEX, "exceeded max units %u\n",
+		    as->as_maxunits));
+		sx_xunlock(&as->as_lock);
+		return_ACPI_STATUS (AE_LIMIT);
 	}
 
-	/* check if we already awaited enough */
-	timelefttv = timeouttv;
-	getmicrotime(&currenttv);
-	timevalsub(&timelefttv, &currenttv);
-	if (timelefttv.tv_sec < 0) {
-	    ACPI_DEBUG_PRINT((ACPI_DB_MUTEX, "await semaphore %p timeout\n",
-		as));
-	    result = AE_TIME;
-	    break;
-	}
+	as->as_units += Units;
+	cv_broadcast(&as->as_cv);
+	sx_xunlock(&as->as_lock);
 
-	/* adjust timeout for the next sleep */
-	tmo = (timelefttv.tv_sec * 1000000 + timelefttv.tv_usec) /
-	    (1000000 / hz);
-	if (tmo <= 0)
-	    tmo = 1;
-
-	if (acpi_semaphore_debug) {
-	    printf("%s: Wakeup timeleft(%jd, %lu), tmo %u, sem %p, thread %d\n",
-		__func__, (intmax_t)timelefttv.tv_sec, timelefttv.tv_usec, tmo, as,
-		AcpiOsGetThreadId());
-	}
-    }
-
-    if (acpi_semaphore_debug) {
-	if (result == AE_TIME && Timeout > 0) {
-	    printf("%s: Timeout %d, pending %d, semaphore %p\n",
-		__func__, Timeout, as->as_pendings, as);
-	}
-	if (result == AE_OK && (as->as_timeouts > 0 || as->as_pendings > 0)) {
-	    printf("%s: Acquire %d, units %d, pending %d, sem %p, thread %d\n",
-		__func__, Units, as->as_units, as->as_pendings, as,
-		AcpiOsGetThreadId());
-	}
-    }
-
-    if (result == AE_TIME)
-	as->as_timeouts++;
-    else
-	as->as_timeouts = 0;
-
-    AS_UNLOCK(as);
-    return_ACPI_STATUS (result);
-#else
-    return_ACPI_STATUS (AE_OK);
-#endif /* !ACPI_NO_SEMAPHORES */
+	return_ACPI_STATUS (AE_OK);
 }
 
+/*
+ * ACPI_SPINLOCK: a non-sleepable spinlock
+ */
+struct acpi_spinlock {
+	struct mtx	al_lock;
+	char		al_name[32];
+	int		al_nested;
+};
+
 ACPI_STATUS
-AcpiOsSignalSemaphore(ACPI_SEMAPHORE Handle, UINT32 Units)
+AcpiOsCreateLock(ACPI_SPINLOCK *OutHandle)
 {
-#ifndef ACPI_NO_SEMAPHORES
-    struct acpi_semaphore	*as = (struct acpi_semaphore *)Handle;
+	struct acpi_spinlock	*al;
 
-    ACPI_FUNCTION_TRACE((char *)(uintptr_t)__func__);
+	ACPI_FUNCTION_TRACE((char *)(uintptr_t)__func__);
 
-    if (as == NULL)
-	return_ACPI_STATUS(AE_BAD_PARAMETER);
+	if (OutHandle == NULL)
+		return_ACPI_STATUS (AE_BAD_PARAMETER);
+	al = malloc(sizeof(*al), M_ACPISEM, M_NOWAIT | M_ZERO);
+	if (al == NULL)
+		return_ACPI_STATUS (AE_NO_MEMORY);
 
-    AS_LOCK(as);
-    ACPI_DEBUG_PRINT((ACPI_DB_MUTEX,
-	"return %d units to semaphore %p (has %d)\n",
-	Units, as, as->as_units));
-    if (as->as_maxunits != ACPI_NO_UNIT_LIMIT) {
-	as->as_units += Units;
-	if (as->as_units > as->as_maxunits)
-	    as->as_units = as->as_maxunits;
-    }
+	/* Build a unique name based on the address of the handle. */
+	if (OutHandle == &AcpiGbl_GpeLock)
+		snprintf(al->al_name, sizeof(al->al_name), "ACPI lock (GPE)");
+	else if (OutHandle == &AcpiGbl_HardwareLock)
+		snprintf(al->al_name, sizeof(al->al_name), "ACPI lock (HW)");
+	else
+		snprintf(al->al_name, sizeof(al->al_name), "ACPI lock (%p)",
+		    OutHandle);
+	mtx_init(&al->al_lock, al->al_name, NULL, MTX_SPIN);
 
-    if (acpi_semaphore_debug && (as->as_timeouts > 0 || as->as_pendings > 0)) {
-	printf("%s: Release %d, units %d, pending %d, semaphore %p, thread %d\n",
-	    __func__, Units, as->as_units, as->as_pendings, as, AcpiOsGetThreadId());
-    }
+	ACPI_DEBUG_PRINT((ACPI_DB_MUTEX, "created %s\n", al->al_name));
 
-    wakeup(as);
-    AS_UNLOCK(as);
-#endif /* !ACPI_NO_SEMAPHORES */
+	*OutHandle = (ACPI_SPINLOCK)al;
 
-    return_ACPI_STATUS (AE_OK);
+	return_ACPI_STATUS (AE_OK);
 }
 
-/* Combined mutex + mutex name storage since the latter must persist. */
-struct acpi_spinlock {
-    struct mtx	lock;
-    char	name[32];
-};
-
-ACPI_STATUS
-AcpiOsCreateLock (ACPI_SPINLOCK *OutHandle)
+void
+AcpiOsDeleteLock(ACPI_SPINLOCK Handle)
 {
-    struct acpi_spinlock *h;
+	struct acpi_spinlock	*al = (struct acpi_spinlock *)Handle;
 
-    if (OutHandle == NULL)
-	return (AE_BAD_PARAMETER);
-    h = malloc(sizeof(*h), M_ACPISEM, M_NOWAIT | M_ZERO);
-    if (h == NULL)
-	return (AE_NO_MEMORY);
+	ACPI_FUNCTION_TRACE((char *)(uintptr_t)__func__);
 
-    /* Build a unique name based on the address of the handle. */
-    if (OutHandle == &AcpiGbl_GpeLock)
-	snprintf(h->name, sizeof(h->name), "acpi subsystem GPE lock");
-    else if (OutHandle == &AcpiGbl_HardwareLock)
-	snprintf(h->name, sizeof(h->name), "acpi subsystem HW lock");
-    else
-	snprintf(h->name, sizeof(h->name), "acpi subsys %p", OutHandle);
-    mtx_init(&h->lock, h->name, NULL, MTX_DEF);
-    *OutHandle = (ACPI_SPINLOCK)h;
-    return (AE_OK);
+	ACPI_DEBUG_PRINT((ACPI_DB_MUTEX, "delete %s\n", al->al_name));
+
+	if (al != NULL) {
+		mtx_destroy(&al->al_lock);
+		free(al, M_ACPISEM);
+	} else
+		ACPI_DEBUG_PRINT((ACPI_DB_MUTEX,
+		    "cannot delete null spinlock\n"));
 }
 
-void
-AcpiOsDeleteLock (ACPI_SPINLOCK Handle)
+ACPI_CPU_FLAGS
+AcpiOsAcquireLock(ACPI_SPINLOCK Handle)
 {
-    struct acpi_spinlock *h = (struct acpi_spinlock *)Handle;
+	struct acpi_spinlock	*al = (struct acpi_spinlock *)Handle;
 
-    if (Handle == NULL)
-        return;
-    mtx_destroy(&h->lock);
-    free(h, M_ACPISEM);
-}
+	ACPI_FUNCTION_TRACE((char *)(uintptr_t)__func__);
 
-/*
- * The Flags parameter seems to state whether or not caller is an ISR
- * (and thus can't block) but since we have ithreads, we don't worry
- * about potentially blocking.
- */
-ACPI_NATIVE_UINT
-AcpiOsAcquireLock (ACPI_SPINLOCK Handle)
-{
-    struct acpi_spinlock *h = (struct acpi_spinlock *)Handle;
+	ACPI_DEBUG_PRINT((ACPI_DB_MUTEX, "acquire %s\n", al->al_name));
 
-    if (Handle == NULL)
+	if (al != NULL) {
+		if (mtx_owned(&al->al_lock)) {
+			al->al_nested++;
+			ACPI_DEBUG_PRINT((ACPI_DB_MUTEX,
+			    "acquire nested %s, depth %d\n",
+			    al->al_name, al->al_nested));
+		} else
+			mtx_lock_spin(&al->al_lock);
+	} else
+		ACPI_DEBUG_PRINT((ACPI_DB_MUTEX,
+		    "cannot acquire null spinlock\n"));
+
 	return (0);
-    mtx_lock(&h->lock);
-    return (0);
 }
 
 void
-AcpiOsReleaseLock (ACPI_SPINLOCK Handle, ACPI_CPU_FLAGS Flags)
+AcpiOsReleaseLock(ACPI_SPINLOCK Handle, ACPI_CPU_FLAGS Flags)
 {
-    struct acpi_spinlock *h = (struct acpi_spinlock *)Handle;
+	struct acpi_spinlock	*al = (struct acpi_spinlock *)Handle;
 
-    if (Handle == NULL)
-	return;
-    mtx_unlock(&h->lock);
+	ACPI_FUNCTION_TRACE((char *)(uintptr_t)__func__);
+
+	ACPI_DEBUG_PRINT((ACPI_DB_MUTEX, "release %s\n", al->al_name));
+
+	if (al != NULL) {
+		if (mtx_owned(&al->al_lock)) {
+			if (al->al_nested > 0) {
+				ACPI_DEBUG_PRINT((ACPI_DB_MUTEX,
+				    "release nested %s, depth %d\n",
+				    al->al_name, al->al_nested));
+				al->al_nested--;
+			} else
+				mtx_unlock_spin(&al->al_lock);
+		} else
+			ACPI_DEBUG_PRINT((ACPI_DB_MUTEX,
+			    "cannot release unowned %s\n", al->al_name));
+	} else
+		ACPI_DEBUG_PRINT((ACPI_DB_MUTEX,
+		    "cannot release null spinlock\n"));
 }
 
-/* Section 5.2.9.1:  global lock acquire/release functions */
-#define GL_ACQUIRED	(-1)
-#define GL_BUSY		0
-#define GL_BIT_PENDING	0x1
-#define GL_BIT_OWNED	0x2
-#define GL_BIT_MASK	(GL_BIT_PENDING | GL_BIT_OWNED)
+/* Section 5.2.10.1: global lock acquire/release functions */
+#define	GL_ACQUIRED	(-1)
+#define	GL_BUSY		0
+#define	GL_BIT_PENDING	0x01
+#define	GL_BIT_OWNED	0x02
+#define	GL_BIT_MASK	(GL_BIT_PENDING | GL_BIT_OWNED)
 
 /*
  * Acquire the global lock.  If busy, set the pending bit.  The caller
@@ -403,7 +352,7 @@
 int
 acpi_acquire_global_lock(uint32_t *lock)
 {
-	uint32_t new, old;
+	uint32_t	new, old;
 
 	do {
 		old = *lock;
@@ -422,7 +371,7 @@
 int
 acpi_release_global_lock(uint32_t *lock)
 {
-	uint32_t new, old;
+	uint32_t	new, old;
 
 	do {
 		old = *lock;
From dougb at FreeBSD.org  Tue May  5 21:57:52 2009
From: dougb at FreeBSD.org (Doug Barton)
Date: Tue May  5 21:58:00 2009
Subject: RELENG_7 - has mergemaster changed logic since 7.2-RELEASE?
In-Reply-To: <20090504225012.392fa49f.torfinn.ingolfsen@broadpark.no>
References: <20090504225012.392fa49f.torfinn.ingolfsen@broadpark.no>
Message-ID: <4A00AF76.8010604@FreeBSD.org>

Torfinn Ingolfsen wrote:
> Ok, this is strange.
> 
> I just upgraded from 7.2-prerelease (as of 20090401) to 7.2-stable as
> of today, using csup and building world.

I've read this thread and find the whole thing very odd. In particular
regarding your case, the last change to mergemaster was done on March
23rd, so if you updated a system on April 1st then again on May 4th
you should have been using the same version of mergemaster.

> As part of that process I did (as I always do) 'mergemaster -iU' after
> the 'make installworld' step.

> /etc/passwd (mergemaster sked about it, I pressed 'd', but it was still
> upgraded, ugh!)
> /etc/group (mergemaster sked about it, I pressed 'd', but it was still
> upgraded, ugh!)

That shouldn't even be possible. You have to affirmatively choose 'i'
(for install) for it to be installed at all, the default is to leave
it in the temproot directory. Additionally, the code to handle
deleting is some of the oldest code in the script, and hasn't changed
in over 8 years.

I saw your followup message, can you please do me a favor and modify
your /etc/motd file again, then run the following in a script(1) and
send me the log?   /bin/sh -x mergemaster -iU


Thanks,

Doug

-- 

    This .signature sanitized for your protection

From amesbury at umn.edu  Tue May  5 23:38:00 2009
From: amesbury at umn.edu (Alan Amesbury)
Date: Tue May  5 23:38:08 2009
Subject: Garbled output from kgdb?
In-Reply-To: <200905051743.03520.jkim@FreeBSD.org>
References: <49F8B859.7060908@umn.edu> <4A006E9A.7060806@icyb.net.ua>
	<200905051609.38689.jkim@FreeBSD.org>
	<200905051743.03520.jkim@FreeBSD.org>
Message-ID: <4A00CDD6.4080303@umn.edu>

Jung-uk Kim wrote:

> The attached patch is for -STABLE.  Note that it is only compile 
> tested on amd64.

The platform in question is 7.1-RELEASE-p5/amd64, and the patch you
supplied looks like it applies cleanly to it.  While I am unable to pin
down the specific trigger of this flaw (the host simply panicked a
couple times while under moderate-to-heavy use), I'm willing to apply
the patch to the host's current source tree, provided you and John
Baldwin are in agreement that it's safe to do so.  Note that's not meant
to imply I don't trust your coding skills; I'm just not ready to modify
production assets without a second look.  ;-)

Thanks again for your help on this.  I appreciate it!


-- 
Alan Amesbury
OIT Security and Assurance
University of Minnesota
From bruce at cran.org.uk  Tue May  5 23:40:15 2009
From: bruce at cran.org.uk (Bruce Cran)
Date: Tue May  5 23:40:22 2009
Subject: RELENG_7 - has mergemaster changed logic since 7.2-RELEASE?
In-Reply-To: <4A00AF76.8010604@FreeBSD.org>
References: <20090504225012.392fa49f.torfinn.ingolfsen@broadpark.no>
	<4A00AF76.8010604@FreeBSD.org>
Message-ID: <20090506004009.12729c32@gluon.draftnet>

On Tue, 05 May 2009 14:28:22 -0700
Doug Barton <dougb@FreeBSD.org> wrote:

> Torfinn Ingolfsen wrote:
> > Ok, this is strange.
> > 
> > I just upgraded from 7.2-prerelease (as of 20090401) to 7.2-stable
> > as of today, using csup and building world.
> 
> I've read this thread and find the whole thing very odd. In particular
> regarding your case, the last change to mergemaster was done on March
> 23rd, so if you updated a system on April 1st then again on May 4th
> you should have been using the same version of mergemaster.

There was a recent thread on -questions about this issue too,
with the title "mergemaster -U overwriting modified files". I've seen
mergemaster clobber named.conf but I've failed to repeat it despite
changing the revision, file timestamp etc.

-- 
Bruce Cran
From steve at ibctech.ca  Tue May  5 23:54:59 2009
From: steve at ibctech.ca (Steve Bertrand)
Date: Tue May  5 23:55:07 2009
Subject: Jails and IPv6
Message-ID: <4A00D1C5.2010806@ibctech.ca>

Hi all,

I've been using VMWare on Linux for quite some time, but I am fed up to
the gills with the hassles I have to go through every time the box needs
to be rebooted. I don't want to start a flame war, so let's just say
that I'm already convinced of migrating to a solution that I don't need
a Linux host for.

I need to be able to run multiple instances of FreeBSD on a single box,
but I *need* IPv6 to work on the virtual machines.

I've read that this is now possible under 7.2. Is this really true?

What I'm looking to do, is set up a new host as IPv6 only. I don't want
to use dedicated hardware if I don't have to, so I'm asking about jails
first.

Operationally, are there any success stories regarding v6 and jails that
anyone could share?

Steve
From david at usermode.org  Wed May  6 03:41:52 2009
From: david at usermode.org (David Johnson)
Date: Wed May  6 03:41:59 2009
Subject: Xorg hangs with drmwtq in 7.2-RELEASE
In-Reply-To: <1241504417.1828.19.camel@balrog.2hip.net>
References: <200905042015.29394.david@usermode.org>
	<1241504417.1828.19.camel@balrog.2hip.net>
Message-ID: <200905052041.48623.david@usermode.org>

On Monday 04 May 2009 11:20:17 pm Robert Noland wrote:
> This generally suggests that the GPU is locked up...  Given that you say
> sometimes it locks up hard (usually a panic, that you can't see since X
> is running) and other times only X is stalled it might be related to
> this patch, if you haven't tried this on already.
>
> http://people.freebsd.org/~rnoland/drm_radeon-copyin-fix-try2.patch

Nope, that didn't help. Still froze when I tried opening multiple windows at 
once. I'm backing out the patch to get back to a clean state.

I also edited my xorg.conf to be closer to yours. No difference.

What information do you need to go forward, and how do I collect it?

p.s. I didn't have a problem with sources from RELENG_7 date=2009.03.13, if 
that helps any. 

Thanks for you time,

-- 
David Johnson
From chris# at 1command.com  Wed May  6 06:25:25 2009
From: chris# at 1command.com (Chris H)
Date: Wed May  6 06:25:32 2009
Subject: GEOM_STRIPE: Cannot add disk da2c to st0 (error=17). [SOLVED]
In-Reply-To: <4A003334.70807@quip.cz>
References: <20090505024800.tk0saqntsgk8kk8c@webmail.1command.com>
	<20090505101301.GA31143@intserv.int1.b.intern>
	<20090505050606.hkxc6cgl3k8ccgws@webmail.1command.com>
	<4A003334.70807@quip.cz>
Message-ID: <20090505232514.eq979b6w0gcg00og@webmail.1command.com>

Hello Miroslav, and thank you for your reply...

Quoting Miroslav Lachman <000.fbsd@quip.cz>:

> Chris H wrote:
>> Hello, and thank you for your reply...
>>
>> Quoting Holger Kipp <hk@alogis.com>:
>>
> [...]
>>>
>>> Can you check if you have any fdisk metadata on either of your disks?
>>> Especially as da0, da1, da2 are attached to st0 without problems,
>>> but then GEOM_STRIPE complains about da2c (which looks like a partition
>>> entry)...
>>
>>
>> I cheated, and went into sysinstall > custom > partition
>>
>> chose each of da0, da1, and da2
>>
>> pressed "f" then "no" then "yes". Which forced a "dangerously" dedicated
>> disk. I also chose "w" on all occasions, and each time the response 
>> indicated
>> Successfully written to disk. I then bailed out of sysinstall, then went
>> back, and deleted the partitions, and again, chose "w". Which also indicated
>> "Successfully written to disk". I then bailed out of sysinstall.
>> Having felt the disks were all now clean, I proceeded with the command:
>>
>> gstripe label -v st0 /dev/da0 /dev/da1 /dev/da2
>>
>> ...well, you know the rest of the story. :)
>>
>> Is this not a good (the best) direction to take?
>
> I recommend you to use
> dd if=/dev/zero of=/dev/da0 count=1000
> dd if=/dev/zero of=/dev/da1 count=1000
> dd if=/dev/zero of=/dev/da2 count=1000
>

This is good advice, I decided that if I chose this method, that I should
/really/ just change count=<actual block count reported by drive>. But
decided if I go this route, I might as well bounce the box and simply
use the SCSI's BIOS routine to re-format all 3 drives. So that's what I did,
and guess what - yep, you guessed it; every thing worked (gstripe(8))
as it should have. So good news, nothing wrong within GEOM, and family. :)

Thank you again for taking the time to respond Miroslav.

--Chris


> to clear the begining of the disks. The next step should be to clear 
> the few last sectors, where metadata of GEOM mirror, journal, stripe 
> etc. are stored, so you end up with "clear disks" which you can use 
> in whatever setup you want without problem with old data, partitions 
> etc.
>
> Miroslav Lachman
>



From jumper99 at gmx.de  Wed May  6 09:04:15 2009
From: jumper99 at gmx.de (Helmut Schneider)
Date: Wed May  6 09:04:22 2009
Subject: [7.2] R/W mount of / denied. Filesystem not clean - run fsck.
Message-ID: <gtrjq3$u24$1@ger.gmane.org>

Hi,

after upgrading a few systems yesterday from 7.1-RELEASE to 7.2-RELEASE on 
one machine I got the error above. The problem was that

- I was unable to cope with it but booting from a live CD.
- the message appeared ~ 1000 times and then the kernel paniced.

After fsck'ing / with the help of the live CD I rebooted the machine but now 
I got the same problem with /home.

How can I avoid such issues (except of not letting the machine crash)? Is 
there a way to boot at least to single user mode and then run fsck (I was at 
home, far away from the machine, not funny)?

Thanks, Helmut

-- 
No Swen today, my love has gone away
My mailbox stands for lorn, a symbol of the dawn 


From amarat at ksu.ru  Wed May  6 09:30:43 2009
From: amarat at ksu.ru (Marat N.Afanasyev)
Date: Wed May  6 09:30:52 2009
Subject: [7.2] R/W mount of / denied. Filesystem not clean - run fsck.
In-Reply-To: <gtrjq3$u24$1@ger.gmane.org>
References: <gtrjq3$u24$1@ger.gmane.org>
Message-ID: <4A015725.3050603@ksu.ru>

Helmut Schneider wrote:
> Hi,
> 
> after upgrading a few systems yesterday from 7.1-RELEASE to 7.2-RELEASE 
> on one machine I got the error above. The problem was that
> 
> - I was unable to cope with it but booting from a live CD.
> - the message appeared ~ 1000 times and then the kernel paniced.
> 
> After fsck'ing / with the help of the live CD I rebooted the machine but 
> now I got the same problem with /home.
> 
> How can I avoid such issues (except of not letting the machine crash)? 
> Is there a way to boot at least to single user mode and then run fsck (I 
> was at home, far away from the machine, not funny)?
> 
> Thanks, Helmut
> 
if there's a problem with home you can change

PermitRoorLogin yes

in /etc/ssh/sshd_config, restart sshd, login as root, unmount home and 
fsck it. if you have another machine in there, you can try to make a 
serial console. or install a ip-kvm extender ;)

-- 
SY, Marat
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3221 bytes
Desc: S/MIME Cryptographic Signature
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20090506/a553edc3/smime.bin
From jumper99 at gmx.de  Wed May  6 09:50:26 2009
From: jumper99 at gmx.de (Helmut Schneider)
Date: Wed May  6 09:50:32 2009
Subject: [7.2] R/W mount of / denied. Filesystem not clean - run fsck.
References: <gtrjq3$u24$1@ger.gmane.org> <4A015725.3050603@ksu.ru>
Message-ID: <gtrmgk$6fc$1@ger.gmane.org>

Marat N.Afanasyev <amarat@ksu.ru> wrote:
> Helmut Schneider wrote:
>> Hi,
>>
>> after upgrading a few systems yesterday from 7.1-RELEASE to 7.2-RELEASE 
>> on one machine I got the error above. The problem was that
>>
>> - I was unable to cope with it but booting from a live CD.
>> - the message appeared ~ 1000 times and then the kernel paniced.
>>
>> After fsck'ing / with the help of the live CD I rebooted the machine but 
>> now I got the same problem with /home.
>>
>> How can I avoid such issues (except of not letting the machine crash)? Is 
>> there a way to boot at least to single user mode and then run fsck (I was 
>> at home, far away from the machine, not funny)?
>>
>> Thanks, Helmut
>>
> if there's a problem with home you can change
>
> PermitRoorLogin yes
>
> in /etc/ssh/sshd_config, restart sshd, login as root, unmount home and

There is no 'login' when / cannot be mounted...

> fsck it. if you have another machine in there, you can try to make a 
> serial console. or install a ip-kvm extender ;)

I do have such thing (IBM Blade Center) but I'm looking for something to 
avoid the situation above. Something that lets me at least boot into single 
user mode.

-- 
No Swen today, my love has gone away
My mailbox stands for lorn, a symbol of the dawn 


From ronald-freebsd8 at klop.yi.org  Wed May  6 10:03:17 2009
From: ronald-freebsd8 at klop.yi.org (Ronald Klop)
Date: Wed May  6 10:03:30 2009
Subject: devd doesn't fire event on boot
Message-ID: <op.uth57o1x8527sy@82-170-177-25.ip.telfort.nl>

Hello,

Running 7.2-STABLE/amd64. I have a USB-disk and added stuff to devd to  
mount it readonly on attach. This does work if I attach it after booting  
up, but not if it is attached before booting.

[root@sjakie ~]# cat /etc/devd/philips.conf
attach 10 {
         device-name "umass[0-9]+";
         match "vendor" "0x0471";
         match "product" "0x083a";
         match "sernum" "20521126";
         action "/root/bin/mountphilips.sh";
};

[root@sjakie ~]# cat /root/bin/mountphilips.sh
#! /bin/sh
(
# Sleep, so geom and other kernel stuff can handle the disk
# before we try to mount it.
sleep 10
mount -v /mnt/backupdisk
) &

[root@sjakie ~]# grep backupdisk /etc/fstab
/dev/ufs/Extern /mnt/backupdisk ufs     ro,noauto       0       0

What can be wrong? Is it possible devd misses events which happened before  
devd was started?
Is this known behaviour?

Ronald.
From ronald-freebsd8 at klop.yi.org  Wed May  6 10:05:14 2009
From: ronald-freebsd8 at klop.yi.org (Ronald Klop)
Date: Wed May  6 10:05:26 2009
Subject: coredump in usb stack
In-Reply-To: <820356.29.1241424820214.JavaMail.tomcat@localhost>
References: <820356.29.1241424820214.JavaMail.tomcat@localhost>
Message-ID: <op.uth6awzl8527sy@82-170-177-25.ip.telfort.nl>

Hi,

I had a coredump from within the usb stack at work a couple of days ago.

GENERIC kernel amd64
Apr 28 12:59:12 ronald kernel: FreeBSD 7.2-PRERELEASE #32: Mon Apr 27
17:35:55 CEST 2009

Attached is the kgdb output and dmesg. Is this known? Did I forget  
something.

Ronald.
-------------- next part --------------
Copyright (c) 1992-2009 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
	The Regents of the University of California. All rights reserved.
FreeBSD is a registered trademark of The FreeBSD Foundation.
FreeBSD 7.2-PRERELEASE #32: Mon Apr 27 17:35:55 CEST 2009
    root@ronald.office.base.nl:/usr/obj/usr/src/sys/GENERIC
Timecounter "i8254" frequency 1193182 Hz quality 0
CPU: Intel(R) Core(TM)2 Duo CPU     E6850  @ 3.00GHz (2992.50-MHz K8-class CPU)
  Origin = "GenuineIntel"  Id = 0x6fb  Stepping = 11
  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=0xe3fd<SSE3,RSVD2,MON,DS_CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM>
  AMD Features=0x20100800<SYSCALL,NX,LM>
  AMD Features2=0x1<LAHF>
  Cores per package: 2
usable memory = 4145065984 (3953 MB)
avail memory  = 3976499200 (3792 MB)
ACPI APIC Table: <DELL   B9K    >
FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs
 cpu0 (BSP): APIC ID:  0
 cpu1 (AP): APIC ID:  1
ioapic0: Changing APIC ID to 8
ioapic0 <Version 2.0> irqs 0-23 on motherboard
lapic0: Forcing LINT1 to edge trigger
kbd1 at kbdmux0
acpi0: <DELL B9K    > on motherboard
acpi0: [ITHREAD]
acpi0: Power Button (fixed)
Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000
acpi_timer0: <24-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0
acpi_hpet0: <High Precision Event Timer> iomem 0xfed00000-0xfed003ff on acpi0
Timecounter "HPET" frequency 14318180 Hz quality 900
acpi_button0: <Power Button> on acpi0
pcib0: <ACPI Host-PCI bridge> port 0xcf8-0xcff on acpi0
pci0: <ACPI PCI bus> on pcib0
pcib1: <ACPI PCI-PCI bridge> irq 16 at device 1.0 on pci0
pci1: <ACPI PCI bus> on pcib1
vgapci0: <VGA-compatible display> port 0xdc00-0xdcff mem 0xd0000000-0xdfffffff,0xfe9f0000-0xfe9fffff irq 16 at device 0.0 on pci1
pci0: <simple comms> at device 3.0 (no driver attached)
atapci0: <Intel ATA controller> port 0xfe80-0xfe87,0xfe90-0xfe93,0xfea0-0xfea7,0xfeb0-0xfeb3,0xfef0-0xfeff irq 18 at device 3.2 on pci0
atapci0: [ITHREAD]
ata2: <ATA channel 0> on atapci0
ata2: [ITHREAD]
ata3: <ATA channel 1> on atapci0
ata3: [ITHREAD]
pci0: <simple comms, UART> at device 3.3 (no driver attached)
em0: <Intel(R) PRO/1000 Network Connection 6.9.6> port 0xecc0-0xecdf mem 0xfebe0000-0xfebfffff,0xfebdb000-0xfebdbfff irq 21 at device 25.0 on pci0
em0: Using MSI interrupt
em0: [FILTER]
em0: Ethernet address: 00:1e:4f:ee:e8:5f
uhci0: <UHCI (generic) USB controller> port 0xff20-0xff3f irq 16 at device 26.0 on pci0
uhci0: [GIANT-LOCKED]
uhci0: [ITHREAD]
usb0: <UHCI (generic) USB controller> 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: <UHCI (generic) USB controller> port 0xff00-0xff1f irq 17 at device 26.1 on pci0
uhci1: [GIANT-LOCKED]
uhci1: [ITHREAD]
usb1: <UHCI (generic) USB controller> 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
ehci0: <EHCI (generic) USB 2.0 controller> mem 0xfebd9c00-0xfebd9fff irq 22 at device 26.7 on pci0
ehci0: [GIANT-LOCKED]
ehci0: [ITHREAD]
usb2: EHCI version 1.0
usb2: wrong number of companions (3 != 2)
usb2: companion controllers, 2 ports each: usb0 usb1
usb2: <EHCI (generic) USB 2.0 controller> on ehci0
usb2: USB revision 2.0
uhub2: <Intel EHCI root hub, class 9/0, rev 2.00/1.00, addr 1> on usb2
uhub2: 6 ports with 6 removable, self powered
hdac0: <Intel 82801I High Definition Audio Controller> mem 0xfebdc000-0xfebdffff irq 16 at device 27.0 on pci0
hdac0: HDA Driver Revision: 20090329_0131
hdac0: [ITHREAD]
pcib2: <ACPI PCI-PCI bridge> irq 16 at device 28.0 on pci0
pci2: <ACPI PCI bus> on pcib2
uhci2: <UHCI (generic) USB controller> port 0xff80-0xff9f irq 23 at device 29.0 on pci0
uhci2: [GIANT-LOCKED]
uhci2: [ITHREAD]
usb3: <UHCI (generic) USB controller> on uhci2
usb3: USB revision 1.0
uhub3: <Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1> on usb3
uhub3: 2 ports with 2 removable, self powered
uhci3: <UHCI (generic) USB controller> port 0xff60-0xff7f irq 17 at device 29.1 on pci0
uhci3: [GIANT-LOCKED]
uhci3: [ITHREAD]
usb4: <UHCI (generic) USB controller> on uhci3
usb4: USB revision 1.0
uhub4: <Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1> on usb4
uhub4: 2 ports with 2 removable, self powered
uhci4: <UHCI (generic) USB controller> port 0xff40-0xff5f irq 18 at device 29.2 on pci0
uhci4: [GIANT-LOCKED]
uhci4: [ITHREAD]
usb5: <UHCI (generic) USB controller> on uhci4
usb5: USB revision 1.0
uhub5: <Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1> on usb5
uhub5: 2 ports with 2 removable, self powered
ehci1: <EHCI (generic) USB 2.0 controller> mem 0xff980800-0xff980bff irq 23 at device 29.7 on pci0
ehci1: [GIANT-LOCKED]
ehci1: [ITHREAD]
usb6: EHCI version 1.0
usb6: companion controllers, 2 ports each: usb3 usb4 usb5
usb6: <EHCI (generic) USB 2.0 controller> on ehci1
usb6: USB revision 2.0
uhub6: <Intel EHCI root hub, class 9/0, rev 2.00/1.00, addr 1> on usb6
uhub6: 6 ports with 6 removable, self powered
uhub7: <vendor 0x0424 product 0x2504, class 9/0, rev 2.00/0.01, addr 2> on uhub6
uhub7: multiple transaction translators
uhub7: 4 ports with 4 removable, self powered
pcib3: <ACPI PCI-PCI bridge> at device 30.0 on pci0
pci3: <ACPI PCI bus> on pcib3
isab0: <PCI-ISA bridge> at device 31.0 on pci0
isa0: <ISA bus> on isab0
atapci1: <Intel AHCI controller> port 0xfe00-0xfe07,0xfe10-0xfe13,0xfe20-0xfe27,0xfe30-0xfe33,0xfec0-0xfedf mem 0xff970000-0xff9707ff irq 18 at device 31.2 on pci0
atapci1: [ITHREAD]
atapci1: AHCI Version 01.20 controller with 6 ports detected
ata4: <ATA channel 0> on atapci1
ata4: [ITHREAD]
ata5: <ATA channel 1> on atapci1
ata5: [ITHREAD]
ata6: <ATA channel 2> on atapci1
ata6: [ITHREAD]
ata7: <ATA channel 3> on atapci1
ata7: port not implemented
ata7: [ITHREAD]
ata8: <ATA channel 4> on atapci1
ata8: port not implemented
ata8: [ITHREAD]
ata9: <ATA channel 5> on atapci1
ata9: [ITHREAD]
ichsmb0: <SMBus controller> port 0xece0-0xecff mem 0xfebd9b00-0xfebd9bff irq 18 at device 31.3 on pci0
ichsmb0: [GIANT-LOCKED]
ichsmb0: [ITHREAD]
smbus0: <System Management Bus> on ichsmb0
ppc0: <Parallel port> port 0x378-0x37f,0x778-0x77f irq 7 on acpi0
ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode
ppc0: FIFO with 16/16/8 bytes threshold
ppbus0: <Parallel port bus> on ppc0
ppbus0: [ITHREAD]
plip0: <PLIP network interface> on ppbus0
plip0: WARNING: using obsoleted IFF_NEEDSGIANT flag
lpt0: <Printer> on ppbus0
lpt0: Interrupt-driven port
ppi0: <Parallel I/O> on ppbus0
ppc0: [GIANT-LOCKED]
ppc0: [ITHREAD]
sio0: configured irq 4 not in bitmap of probed irqs 0
sio0: port may not be enabled
sio0: configured irq 4 not in bitmap of probed irqs 0
sio0: port may not be enabled
sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0
sio0: type 16550A
sio0: [FILTER]
cpu0: <ACPI CPU> on acpi0
coretemp0: <CPU On-Die Thermal Sensors> on cpu0
est0: <Enhanced SpeedStep Frequency Control> on cpu0
p4tcc0: <CPU Frequency Thermal Control> on cpu0
cpu1: <ACPI CPU> on acpi0
coretemp1: <CPU On-Die Thermal Sensors> on cpu1
est1: <Enhanced SpeedStep Frequency Control> on cpu1
p4tcc1: <CPU Frequency Thermal Control> on cpu1
orm0: <ISA Option ROMs> at iomem 0xc0000-0xcefff,0xcf000-0xd0fff,0xd1000-0xd37ff,0xd3800-0xd3fff on isa0
atkbdc0: <Keyboard controller (i8042)> at port 0x60,0x64 on isa0
atkbd0: <AT Keyboard> irq 1 on atkbdc0
kbd0 at atkbd0
atkbd0: [GIANT-LOCKED]
atkbd0: [ITHREAD]
sc0: <System console> at flags 0x100 on isa0
sc0: VGA <16 virtual consoles, flags=0x300>
sio1: configured irq 3 not in bitmap of probed irqs 0
sio1: port may not be enabled
vga0: <Generic ISA VGA> at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0
ums0: <Logitech USB-PS/2 Optical Mouse, class 0/0, rev 2.00/27.20, addr 2> on uhub0
ums0: 8 buttons and Z dir.
ukbd0: <Tripplite B015-000 R0.74 USB to PS2 adapter., class 0/0, rev 1.10/1.00, addr 3> on uhub0
kbd2 at ukbd0
ums1: <Tripplite B015-000 R0.74 USB to PS2 adapter., class 0/0, rev 1.10/1.00, addr 3> on uhub0
ums1: 5 buttons and Z dir.
ubt0: <Broadcom Bluetooth USB Dongle, class 224/1, rev 1.10/0.01, addr 2> on uhub1
ubt0: Interface 0 endpoints: interrupt=0x81, bulk-in=0x82, bulk-out=0x2
ubt0: Interface 1 (alt.config 4) endpoints: isoc-in=0x83, isoc-out=0x3; wMaxPacketSize=64; nframes=5, buffer size=320
Timecounters tick every 1.000 msec
ad8: 238418MB <Seagate ST3250310AS 3.ADA> at ata4-master SATA300
acd0: DVDROM <HL-DT-STDVD-ROM GDRH20N/0D08> at ata5-master SATA150
hdac0: HDA Codec #0: Analog Devices AD1984
pcm0: <HDA Analog Devices AD1984 PCM #0 Analog> at cad 0 nid 1 on hdac0
pcm1: <HDA Analog Devices AD1984 PCM #1 Analog> at cad 0 nid 1 on hdac0
lapic1: Forcing LINT1 to edge trigger
SMP: AP CPU #1 Launched!
GEOM_LABEL: Label for provider ad8s1a is ufsid/48aed81cc4f3cefd.
GEOM_LABEL: Label for provider ad8s1d is ufsid/48aed8252c64bcc1.
GEOM_LABEL: Label for provider ad8s1e is ufsid/48aed81ca20f6419.
GEOM_JOURNAL: Journal 4268017618: ad8s1f contains data.
GEOM_JOURNAL: Journal 4268017618: ad8s1g contains journal.
GEOM_JOURNAL: Journal ad8s1f consistent.
GEOM_JOURNAL: Journal 3980389559: ad8s1h contains data.
GEOM_JOURNAL: Journal 3980389559: ad8s1h contains journal.
GEOM_JOURNAL: Journal ad8s1h consistent.
GEOM_LABEL: Label for provider ad8s1f.journal is ufsid/4947eceea4f32377.
GEOM_LABEL: Label for provider ad8s1h.journal is ufsid/48e3ab88aa9b5e37.
Trying to mount root from ufs:/dev/ad8s1a
WARNING: / was not properly dismounted
GEOM_LABEL: Label ufsid/48aed81cc4f3cefd removed.
GEOM_LABEL: Label for provider ad8s1a is ufsid/48aed81cc4f3cefd.
GEOM_LABEL: Label ufsid/48aed81ca20f6419 removed.
GEOM_LABEL: Label for provider ad8s1e is ufsid/48aed81ca20f6419.
GEOM_LABEL: Label ufsid/48e3ab88aa9b5e37 removed.
GEOM_LABEL: Label for provider ad8s1h.journal is ufsid/48e3ab88aa9b5e37.
GEOM_LABEL: Label ufsid/4947eceea4f32377 removed.
GEOM_LABEL: Label for provider ad8s1f.journal is ufsid/4947eceea4f32377.
GEOM_LABEL: Label ufsid/48aed8252c64bcc1 removed.
GEOM_LABEL: Label for provider ad8s1d is ufsid/48aed8252c64bcc1.
GEOM_LABEL: Label ufsid/48aed81cc4f3cefd removed.
GEOM_LABEL: Label ufsid/48aed81ca20f6419 removed.
WARNING: TMPFS is considered to be a highly experimental feature in FreeBSD.
GEOM_LABEL: Label ufsid/48e3ab88aa9b5e37 removed.
GEOM_LABEL: Label ufsid/4947eceea4f32377 removed.
GEOM_LABEL: Label ufsid/48aed8252c64bcc1 removed.
WARNING: attempt to net_add_domain(bluetooth) after domainfinalize()
WARNING: attempt to net_add_domain(netgraph) after domainfinalize()
netsmb_dev: loaded
drm0: <Radeon HD 2400 XT> on vgapci0
vgapci0: child drm0 requested pci_enable_busmaster
info: [drm] Initialized radeon 1.29.0 20080528
info: [drm] Setting GART location based on new memory map
info: [drm] Loading RV610 CP Microcode
info: [drm] Loading RV610 PFP Microcode
info: [drm] Resetting GPU
info: [drm] writeback test succeeded in 1 usecs
drm0: [ITHREAD]
-------------- next part --------------
# root@ronald [/usr/obj/usr/src/sys/GENERIC]
kgdb kernel.debug /var/crash/vmcore.2 
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "amd64-marcel-freebsd"...

Unread portion of the kernel message buffer:


Fatal trap 9: general protection fault while in kernel mode
cpuid = 1; apic id = 01
instruction pointer     = 0x8:0xffffffff80434d75
stack pointer           = 0x10:0xfffffffe8002db50
frame pointer           = 0x10:0x4
code segment            = base 0x0, limit 0xfffff, type 0x1b
                        = DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags        = interrupt enabled, resume, IOPL = 0
current process         = 13 (swi4: clock sio)
trap number             = 9
panic: general protection fault
cpuid = 1
Uptime: 5d21h0m13s
Physical memory: 3953 MB
Dumping 643 MB: 628 612 596 580 564 548 532 516 500 484 468 452 436 420 404 388 372 356 340 324 308 292 276 260 244 228 212 196 180 164 148 132 116 100 84 68 52 36 20 4

#0  doadump () at pcpu.h:195
195             __asm __volatile("movq %%gs:0,%0" : "=r" (td));
(kgdb) list *0xffffffff80434d75
0xffffffff80434d75 is in ehci_timeout (/usr/src/sys/dev/usb/ehci.c:2729).
2724    #ifdef USB_DEBUG
2725            if (ehcidebug > 1)
2726                    usbd_dump_pipe(exfer->xfer.pipe);
2727    #endif
2728    
2729            if (sc->sc_dying) {
2730                    ehci_abort_xfer(&exfer->xfer, USBD_TIMEOUT);
2731                    return;
2732            }
2733    
(kgdb) bt
#0  doadump () at pcpu.h:195
#1  0x0000000000000004 in ?? ()
#2  0xffffffff804e38a1 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:418
#3  0xffffffff804e3cdc in panic (fmt=0x104 <Address 0x104 out of bounds>) at /usr/src/sys/kern/kern_shutdown.c:574
#4  0xffffffff8078ae6a in trap_fatal (frame=0xffffff0001419000, eva=Variable "eva" is not available.
) at /usr/src/sys/amd64/amd64/trap.c:757
#5  0xffffffff8078b922 in trap (frame=0xfffffffe8002daa0) at /usr/src/sys/amd64/amd64/trap.c:558
#6  0xffffffff80770fee in calltrap () at /usr/src/sys/amd64/amd64/exception.S:209
#7  0xffffffff80434d75 in ehci_timeout (addr=0xffffff00046f7800) at /usr/src/sys/dev/usb/ehci.c:2729
#8  0xffffffff804f50ee in softclock (dummy=Variable "dummy" is not available.
) at /usr/src/sys/kern/kern_timeout.c:274
#9  0xffffffff804c5880 in ithread_loop (arg=0xffffff0001415920) at /usr/src/sys/kern/kern_intr.c:1088
#10 0xffffffff804c284d in fork_exit (callout=0xffffffff804c5716 <ithread_loop>, arg=0xffffff0001415920, frame=0xfffffffe8002dc80) at /usr/src/sys/kern/kern_fork.c:810
#11 0xffffffff807713ae in fork_trampoline () at /usr/src/sys/amd64/amd64/exception.S:455
#12 0x0000000000000000 in ?? ()
#13 0x0000000000000000 in ?? ()
#14 0x0000000000000001 in ?? ()
#15 0x0000000000000000 in ?? ()
#16 0x0000000000000000 in ?? ()
#17 0x0000000000000000 in ?? ()
#18 0x0000000000000000 in ?? ()
#19 0x0000000000000000 in ?? ()
#20 0x0000000000000000 in ?? ()
#21 0x0000000000000000 in ?? ()
#22 0x0000000000000000 in ?? ()
#23 0x0000000000000000 in ?? ()
#24 0x0000000000000000 in ?? ()
#25 0x0000000000000000 in ?? ()
#26 0x0000000000000000 in ?? ()
#27 0x0000000000000000 in ?? ()
#28 0x0000000000000000 in ?? ()
#29 0x0000000000000000 in ?? ()
#30 0x0000000000000000 in ?? ()
#31 0x0000000000000000 in ?? ()
#32 0x0000000000000000 in ?? ()
#33 0x0000000000000000 in ?? ()
#34 0x0000000000000000 in ?? ()
#35 0x0000000000000000 in ?? ()
#36 0x0000000000d85000 in ?? ()
#37 0xffffffff80ae7540 in tdg_maxid ()
#38 0xffffffff80af3d40 in tdq_cpu ()
#39 0xffffffff80af3d40 in tdq_cpu ()
#40 0xffffff0001419000 in ?? ()
#41 0xffffff0001419330 in ?? ()
#42 0xfffffffe8002d3b8 in ?? ()
#43 0x0000000000000000 in ?? ()
#44 0xffffffff805054d3 in sched_switch (td=0xffffffff804c5716, newtd=0x8006968d0, flags=Variable "flags" is not available.
) at /usr/src/sys/kern/sched_ule.c:1938
#45 0x0000000000000000 in ?? ()
#46 0x0000000000000000 in ?? ()
#47 0x0000000000000000 in ?? ()
#48 0x0000000000000000 in ?? ()
#49 0x0000000000000000 in ?? ()
#50 0x0000000000000000 in ?? ()
#51 0x0000000000000000 in ?? ()
#52 0x0000000000000000 in ?? ()
#53 0x0000000000000000 in ?? ()
#54 0x0000000000000000 in ?? ()
#55 0x0000000000000000 in ?? ()
#56 0x0000000000000000 in ?? ()
#57 0x0000000000000000 in ?? ()
#58 0x0000000000000000 in ?? ()
#59 0x0000000000000000 in ?? ()
#60 0x0000000000000000 in ?? ()
---Type <return> to continue, or q <return> to quit---
#61 0x0000000000000000 in ?? ()
#62 0x0000000000000000 in ?? ()
#63 0x0000000000000000 in ?? ()
#64 0x0000000000000000 in ?? ()
#65 0x0000000000000000 in ?? ()
#66 0x0000000000000000 in ?? ()
#67 0x0000000000000000 in ?? ()
#68 0x0000000000000000 in ?? ()
#69 0x0000000000000000 in ?? ()
#70 0x0000000000000000 in ?? ()
#71 0x0000000000000000 in ?? ()
#72 0x0000000000000000 in ?? ()
#73 0x0000000000000000 in ?? ()
#74 0x0000000000000000 in ?? ()
#75 0x0000000000000000 in ?? ()
#76 0x0000000000000000 in ?? ()
#77 0x0000000000000000 in ?? ()
#78 0x0000000000000000 in ?? ()
#79 0x0000000000000000 in ?? ()
#80 0x0000000000000000 in ?? ()
#81 0x0000000000000000 in ?? ()
#82 0x0000000000000000 in ?? ()
#83 0x0000000000000000 in ?? ()
#84 0x0000000000000000 in ?? ()
#85 0x0000000000000000 in ?? ()
#86 0x0000000000000000 in ?? ()
#87 0x0000000000000000 in ?? ()
#88 0x0000000000000000 in ?? ()
#89 0x0000000000000000 in ?? ()
#90 0x0000000000000000 in ?? ()
#91 0x0000000000000000 in ?? ()
#92 0x0000000000000000 in ?? ()
#93 0x0000000000000000 in ?? ()
#94 0x0000000000000000 in ?? ()
#95 0x0000000000000000 in ?? ()
#96 0x0000000000000000 in ?? ()
#97 0x0000000000000000 in ?? ()
#98 0x0000000000000000 in ?? ()
#99 0x0000000000000000 in ?? ()
#100 0x0000000000000000 in ?? ()
#101 0x0000000000000000 in ?? ()
#102 0x0000000000000000 in ?? ()
#103 0x0000000000000000 in ?? ()
#104 0x0000000000000000 in ?? ()
#105 0x0000000000000000 in ?? ()
#106 0x0000000000000000 in ?? ()
#107 0x0000000000000000 in ?? ()
#108 0x0000000000000000 in ?? ()
#109 0x0000000000000000 in ?? ()
#110 0x0000000000000000 in ?? ()
#111 0x0000000000000000 in ?? ()
#112 0x0000000000000000 in ?? ()
Cannot access memory at address 0xfffffffe8002e000
From freebsd at byshenk.net  Wed May  6 10:06:03 2009
From: freebsd at byshenk.net (Greg Byshenk)
Date: Wed May  6 10:06:12 2009
Subject: [7.2] R/W mount of / denied. Filesystem not clean - run fsck.
In-Reply-To: <gtrmgk$6fc$1@ger.gmane.org>
References: <gtrjq3$u24$1@ger.gmane.org> <4A015725.3050603@ksu.ru>
	<gtrmgk$6fc$1@ger.gmane.org>
Message-ID: <20090506100559.GP1550@core.byshenk.net>

On Wed, May 06, 2009 at 11:50:11AM +0200, Helmut Schneider wrote:
> Marat N.Afanasyev <amarat@ksu.ru> wrote:
> >Helmut Schneider wrote:

> >>after upgrading a few systems yesterday from 7.1-RELEASE to 7.2-RELEASE 
> >>on one machine I got the error above. The problem was that
> >>
> >>- I was unable to cope with it but booting from a live CD.
> >>- the message appeared ~ 1000 times and then the kernel paniced.
> >>
> >>After fsck'ing / with the help of the live CD I rebooted the machine but 
> >>now I got the same problem with /home.
> >>
> >>How can I avoid such issues (except of not letting the machine crash)? Is 
> >>there a way to boot at least to single user mode and then run fsck (I was 
> >>at home, far away from the machine, not funny)?

> There is no 'login' when / cannot be mounted...
> 
> >fsck it. if you have another machine in there, you can try to make a 
> >serial console. or install a ip-kvm extender ;)
> 
> I do have such thing (IBM Blade Center) but I'm looking for something to 
> avoid the situation above. Something that lets me at least boot into single 
> user mode.

If you had access to the console (I'm guessing you did in order to use the
live CD), did you try booting into single-user from the beastie menu?

IME, failure to fsck the / menu should drop automatically to single-user
at the console, but if this fails, then you should be able to choose
single-user boot from the menu, which will then not try to run fsck or
mount / rw.  From there you should be able to fsck and remount /, as well
as /home or anything else.  This will fail if there is something horribly
wrong with /, causing a failure even when / is mounted ro, but then there
may be no good solution.


-- 
greg byshenk  -  gbyshenk@byshenk.net  -  Leiden, NL
From amarat at ksu.ru  Wed May  6 10:22:34 2009
From: amarat at ksu.ru (Marat N.Afanasyev)
Date: Wed May  6 10:22:43 2009
Subject: [7.2] R/W mount of / denied. Filesystem not clean - run fsck.
In-Reply-To: <gtrmgk$6fc$1@ger.gmane.org>
References: <gtrjq3$u24$1@ger.gmane.org> <4A015725.3050603@ksu.ru>
	<gtrmgk$6fc$1@ger.gmane.org>
Message-ID: <4A01630A.5080201@ksu.ru>

Helmut Schneider wrote:
> Marat N.Afanasyev <amarat@ksu.ru> wrote:
>> Helmut Schneider wrote:
>>> Hi,
>>>
>>> after upgrading a few systems yesterday from 7.1-RELEASE to 
>>> 7.2-RELEASE on one machine I got the error above. The problem was that
>>>
>>> - I was unable to cope with it but booting from a live CD.
>>> - the message appeared ~ 1000 times and then the kernel paniced.
>>>
>>> After fsck'ing / with the help of the live CD I rebooted the machine 
>>> but now I got the same problem with /home.
>>>
>>> How can I avoid such issues (except of not letting the machine 
>>> crash)? Is there a way to boot at least to single user mode and then 
>>> run fsck (I was at home, far away from the machine, not funny)?
>>>
>>> Thanks, Helmut
>>>
>> if there's a problem with home you can change
>>
>> PermitRoorLogin yes
>>
>> in /etc/ssh/sshd_config, restart sshd, login as root, unmount home and
> 
> There is no 'login' when / cannot be mounted...
> 
>> fsck it. if you have another machine in there, you can try to make a 
>> serial console. or install a ip-kvm extender ;)
> 
> I do have such thing (IBM Blade Center) but I'm looking for something to 
> avoid the situation above. Something that lets me at least boot into 
> single user mode.
> 

if you have an ip-kvm you can drop into single-user and fsck any disk 
you have. all you need to do is to choose 'single user' from 
beastie-menu. or start kernel with -s parameter

-- 
SY, Marat
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3221 bytes
Desc: S/MIME Cryptographic Signature
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20090506/e303cbb6/smime.bin
From jumper99 at gmx.de  Wed May  6 11:01:12 2009
From: jumper99 at gmx.de (Helmut Schneider)
Date: Wed May  6 11:01:20 2009
Subject: [7.2] R/W mount of / denied. Filesystem not clean - run fsck.
References: <gtrjq3$u24$1@ger.gmane.org>
	<4A015725.3050603@ksu.ru><gtrmgk$6fc$1@ger.gmane.org>
	<20090506100559.GP1550@core.byshenk.net>
Message-ID: <gtrql6$jjn$1@ger.gmane.org>

Greg Byshenk <freebsd@byshenk.net> wrote:
> On Wed, May 06, 2009 at 11:50:11AM +0200, Helmut Schneider wrote:
>> Marat N.Afanasyev <amarat@ksu.ru> wrote:
>>> Helmut Schneider wrote:
>
>>>> after upgrading a few systems yesterday from 7.1-RELEASE to
>>>> 7.2-RELEASE  on one machine I got the error above. The problem was that
>>>>
>>>> - I was unable to cope with it but booting from a live CD.
>>>> - the message appeared ~ 1000 times and then the kernel paniced.
>>>>
>>>> After fsck'ing / with the help of the live CD I rebooted the
>>>> machine but  now I got the same problem with /home.
>>>>
>>>> How can I avoid such issues (except of not letting the machine
>>>> crash)? Is  there a way to boot at least to single user mode and
>>>> then run fsck (I was  at home, far away from the machine, not funny)?
>
>> There is no 'login' when / cannot be mounted...
>>
>>> fsck it. if you have another machine in there, you can try to make a
>>> serial console. or install a ip-kvm extender ;)
>>
>> I do have such thing (IBM Blade Center) but I'm looking for something to
>> avoid the situation above. Something that lets me at least boot into
>> single  user mode.
>
> If you had access to the console (I'm guessing you did in order to use the
> live CD), did you try booting into single-user from the beastie menu?

Yes, I did, same issue, screen filled up with message above, after ~5 
minutes kernel panic.

> IME, failure to fsck the / menu should drop automatically to single-user
> at the console, but if this fails, then you should be able to choose
> single-user boot from the menu, which will then not try to run fsck or
> mount / rw.  From there you should be able to fsck and remount /, as well
> as /home or anything else.  This will fail if there is something horribly
> wrong with /, causing a failure even when / is mounted ro, but then there
> may be no good solution.

There were only 2 or 3 inodes broken, fix from live CD ran smoothly.

-- 
No Swen today, my love has gone away
My mailbox stands for lorn, a symbol of the dawn 


From jumper99 at gmx.de  Wed May  6 11:44:08 2009
From: jumper99 at gmx.de (Helmut Schneider)
Date: Wed May  6 11:44:16 2009
Subject: [7.2] R/W mount of / denied. Filesystem not clean - run fsck.
References: <gtrjq3$u24$1@ger.gmane.org>
Message-ID: <gtrt5m$ror$1@ger.gmane.org>

Helmut Schneider <jumper99@gmx.de> wrote:
> after upgrading a few systems yesterday from 7.1-RELEASE to 7.2-RELEASE
> on  one machine I got the error above. The problem was that
>
> - I was unable to cope with it but booting from a live CD.
> - the message appeared ~ 1000 times and then the kernel paniced.

Here's the debug if one is interested in (first boot after I fixed /):

[root@BSDHelmut /usr/obj/usr/src/sys/GENERIC-QUOTA-PF-ALTQ]# kgdb 
kernel.debug /var/crash/vmcore.0
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain 
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i386-marcel-freebsd"...

Unread portion of the kernel message buffer:
Copyright (c) 1992-2009 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
        The Regents of the University of California. All rights reserved.
FreeBSD is a registered trademark of The FreeBSD Foundation.
FreeBSD 7.2-RELEASE #4: Mon May  4 15:47:30 CEST 2009
    root@BSDHelmut:/usr/obj/usr/src/sys/GENERIC-QUOTA-PF-ALTQ
Timecounter "i8254" frequency 1193182 Hz quality 0
CPU: Intel(R) Xeon(TM) CPU 3.20GHz (3200.13-MHz 686-class CPU)
  Origin = "GenuineIntel"  Id = 0xf4a  Stepping = 10
  Features=0xbfebfbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE>
  Features2=0x641d<SSE3,DTES64,MON,DS_CPL,CNXT-ID,CX16,xTPR>
  AMD Features=0x20000000<LM>
  AMD Features2=0x1<LAHF>
  Logical CPUs per core: 2
real memory  = 2147155968 (2047 MB)
avail memory = 2091483136 (1994 MB)
ACPI APIC Table: <IBM    SERBLADE>
FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs
 cpu0 (BSP): APIC ID:  0
 cpu1 (AP/HT): APIC ID:  1
 cpu2 (AP): APIC ID:  6
 cpu3 (AP/HT): APIC ID:  7
ioapic3 <Version 2.0> irqs 72-95 on motherboard
ioapic2 <Version 2.0> irqs 48-71 on motherboard
ioapic1 <Version 2.0> irqs 24-47 on motherboard
ioapic0 <Version 2.0> irqs 0-23 on motherboard
kbd1 at kbdmux0
acpi0: <IBM SERBLADE> on motherboard
acpi0: [ITHREAD]
acpi0: Power Button (fixed)
Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000
acpi_timer0: <24-bit timer at 3.579545MHz> port 0x588-0x58b on acpi0
pcib0: <ACPI Host-PCI bridge> on acpi0
pci0: <ACPI PCI bus> on pcib0
pci0: <unknown> at device 0.1 (no driver attached)
pcib1: <ACPI PCI-PCI bridge> at device 3.0 on pci0
pci4: <ACPI PCI bus> on pcib1
pcib2: <ACPI PCI-PCI bridge> at device 0.0 on pci4
pci6: <ACPI PCI bus> on pcib2
pcib3: <ACPI PCI-PCI bridge> at device 0.2 on pci4
pci5: <ACPI PCI bus> on pcib3
bge0: <Broadcom NetXtreme Gigabit Ethernet Controller, ASIC rev. 0x2100> mem 
0xdcff0000-0xdcffffff irq 77 at device 1.0 on pci5
bge0: Ethernet address: 00:14:5e:bd:0e:9c
bge0: [ITHREAD]
bge1: <Broadcom NetXtreme Gigabit Ethernet Controller, ASIC rev. 0x2100> mem 
0xdcfe0000-0xdcfeffff irq 78 at device 1.1 on pci5
bge1: Ethernet address: 00:14:5e:bd:0e:9d
bge1: [ITHREAD]
pci0: <base peripheral> at device 8.0 (no driver attached)
pcib4: <ACPI PCI-PCI bridge> at device 28.0 on pci0
pci2: <ACPI PCI bus> on pcib4
mpt0: <LSILogic 1030 Ultra4 Adapter> port 0x4000-0x40ff mem 
0xdeff0000-0xdeffffff,0xdefe0000-0xdefeffff irq 24 at device 1.0 on pci2
mpt0: [ITHREAD]
mpt0: MPI Version=1.2.15.0
mpt0: Capabilities: ( RAID-1E RAID-1 SAFTE )
mpt0: 1 Active Volume (1 Max)
mpt0: 2 Hidden Drive Members (6 Max)
uhci0: <UHCI (generic) USB controller> port 0x2200-0x221f irq 16 at device 
29.0 on pci0
uhci0: [GIANT-LOCKED]
uhci0: [ITHREAD]
usb0: <UHCI (generic) USB controller> 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: <UHCI (generic) USB controller> port 0x2600-0x261f irq 19 at device 
29.1 on pci0
uhci1: [GIANT-LOCKED]
uhci1: [ITHREAD]
usb1: <UHCI (generic) USB controller> 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
pci0: <base peripheral> at device 29.4 (no driver attached)
pcib5: <ACPI PCI-PCI bridge> at device 30.0 on pci0
pci1: <ACPI PCI bus> on pcib5
vgapci0: <VGA-compatible display> port 0x3000-0x30ff mem 
0xf0000000-0xf7ffffff,0xf8000000-0xf800ffff irq 20 at device 1.0 on pci1
isab0: <PCI-ISA bridge> at device 31.0 on pci0
isa0: <ISA bus> on isab0
atapci0: <Intel 6300ESB UDMA100 controller> port 
0x1f0-0x1f7,0x3f6,0x170-0x177,0x376 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)
sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on 
acpi0
sio0: type 16550A
sio0: [FILTER]
cpu0: <ACPI CPU> on acpi0
p4tcc0: <CPU Frequency Thermal Control> on cpu0
cpu1: <ACPI CPU> on acpi0
p4tcc1: <CPU Frequency Thermal Control> on cpu1
cpu2: <ACPI CPU> on acpi0
p4tcc2: <CPU Frequency Thermal Control> on cpu2
cpu3: <ACPI CPU> on acpi0
p4tcc3: <CPU Frequency Thermal Control> on cpu3
pmtimer0 on isa0
orm0: <ISA Option ROM> at iomem 0xc0000-0xc8fff pnpid ORM0000 on isa0
atkbdc0: <Keyboard controller (i8042)> at port 0x60,0x64 on isa0
atkbd0: <AT Keyboard> irq 1 on atkbdc0
kbd0 at atkbd0
atkbd0: [GIANT-LOCKED]
atkbd0: [ITHREAD]
psm0: unable to set the command byte.
ppc0: parallel port not found.
sc0: <System console> at flags 0x100 on isa0
sc0: VGA <16 virtual consoles, flags=0x300>
sio1: configured irq 3 not in bitmap of probed irqs 0
sio1: port may not be enabled
vga0: <Generic ISA VGA> at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0
uhub2: <Cypress Semor 4 Port Hub, class 9/0, rev 1.10/0.01, addr 2> on uhub0
uhub2: 4 ports with 4 removable, self powered
umass0: <TEAC TEAC FD-05PUB, class 0/0, rev 1.10/0.00, addr 3> on uhub2
umass1: <In-System Design USB Storage Adapter, class 0/0, rev 1.10/1.00, 
addr 4> on uhub2
ukbd0: <IBM IBM MM2, class 0/0, rev 1.10/0.01, addr 5> on uhub0
kbd0 at ukbd0
ums0: <IBM IBM MM2, class 0/0, rev 1.10/0.01, addr 5> on uhub0
ums0: 3 buttons and Z dir.
Timecounters tick every 1.000 msec
Waiting 5 seconds for SCSI devices to settle
mpt0:vol0(mpt0:0:0): Settings ( Hot-Plug-Spares )
mpt0:vol0(mpt0:0:0): Using Spare Pool: 0
mpt0:vol0(mpt0:0:0): 2 Members:
      (mpt0:1:0:0): Primary Online
      (mpt0:1:1:0): Secondary Online
mpt0:vol0(mpt0:0:0): RAID-1 - Optimal
mpt0:vol0(mpt0:0:0): Status ( Enabled )
(mpt0:vol0:0): Physical (mpt0:0:0:0), Pass-thru (mpt0:1:0:0)
(mpt0:vol0:0): Online
(mpt0:vol0:1): Physical (mpt0:0:1:0), Pass-thru (mpt0:1:1:0)
(mpt0:vol0:1): Online
(probe3:umass-sim1:1:0:0): TEST UNIT READY. CDB: 0 0 0 0 0 0
(probe3:umass-sim1:1:0:0): CAM Status: SCSI Status Error
(probe3:umass-sim1:1:0:0): SCSI Status: Check Condition
(probe3:umass-sim1:1:0:0): UNIT ATTENTION asc:29,0
(probe3:umass-sim1:1:0:0): Power on, reset, or bus device reset occurred
(probe3:umass-sim1:1:0:0): Retrying Command (per Sense Data)
(probe2:umass-sim0:0:0:0): TEST UNIT READY. CDB: 0 0 0 0 0 0
(probe2:umass-sim0:0:0:0): CAM Status: SCSI Status Error
(probe2:umass-sim0:0:0:0): SCSI Status: Check Condition
(probe2:umass-sim0:0:0:0): UNIT ATTENTION asc:29,0
(probe2:umass-sim0:0:0:0): Power on, reset, or bus device reset occurred
(probe2:umass-sim0:0:0:0): Retrying Command (per Sense Data)
(probe3:umass-sim1:1:0:0): TEST UNIT READY. CDB: 0 0 0 0 0 0
(probe3:umass-sim1:1:0:0): CAM Status: SCSI Status Error
(probe3:umass-sim1:1:0:0): SCSI Status: Check Condition
(probe3:umass-sim1:1:0:0): NOT READY asc:3a,0
(probe3:umass-sim1:1:0:0): Medium not present
(probe3:umass-sim1:1:0:0): Unretryable error
(probe2:umass-sim0:0:0:0): TEST UNIT READY. CDB: 0 0 0 0 0 0
(probe2:umass-sim0:0:0:0): CAM Status: SCSI Status Error
(probe2:umass-sim0:0:0:0): SCSI Status: Check Condition
(probe2:umass-sim0:0:0:0): NOT READY asc:3a,0
(probe2:umass-sim0:0:0:0): Medium not present
(probe2:umass-sim0:0:0:0): Unretryable error
da0 at mpt0 bus 0 target 0 lun 0
da0: <LSILOGIC 1030 IM       IM 1000> Fixed Direct Access SCSI-2 device
da0: 320.000MB/s transfers (160.000MHz, offset 63, 16bit)
da0: Command Queueing Enabled
da0: 69878MB (143110144 512 byte sectors: 255H 63S/T 8908C)
SMP: AP CPU #2 Launched!
SMP: AP CPU #1 Launched!
SMP: AP CPU #3 Launched!
da1 at umass-sim0 bus 0 target 0 lun 0
da1: <TEAC FD-05PUB 2000> Removable Direct Access SCSI-0 device
da1: 1.000MB/s transfers
da1: Attempt to query device size failed: NOT READY, Medium not present
cd0 at umass-sim1 bus 1 target 0 lun 0
cd0: <LG CD-ROM CRN-8245B 1.16> Removable CD-ROM SCSI-0 device
cd0: 1.000MB/s transfers
cd0: Attempt to query device size failed: NOT READY, Medium not present
GEOM_LABEL: Label for provider da0s1a is ufsid/4602dc3f7f0abdcb.
GEOM_LABEL: Label for provider da0s1d is ufsid/4602dc41e4bc65f2.
GEOM_LABEL: Label for provider da0s1e is ufsid/4602dc42e0009b6a.
GEOM_LABEL: Label for provider da0s1f is ufsid/4602dc435ff503cc.
GEOM_LABEL: Label for provider da0s2a is ufsid/49c3b072f1da1672.
GEOM_LABEL: Label for provider da0s2b is ufsid/49c3b074abff4750.
GEOM_LABEL: Label for provider da0s2d is ufsid/49c3b0c3bda46fb5.
GEOM_LABEL: Label for provider da0s2e is ufsid/49c3b0c4862f53b3.
Trying to mount root from ufs:/dev/da0s1a
GEOM_LABEL: Label ufsid/4602dc3f7f0abdcb removed.
GEOM_LABEL: Label ufsid/49c3b0c4862f53b3 removed.
WARNING: R/W mount of /home denied.  Filesystem is not clean - run fsck
GEOM_LABEL: Label for provider da0s2e is ufsid/49c3b0c4862f53b3.
GEOM_LABEL: Label ufsid/49c3b0c4862f53b3 removed.
WARNING: R/W mount of /home denied.  Filesystem is not clean - run fsck
GEOM_LABEL: Label for provider da0s2e is ufsid/49c3b0c4862f53b3.
GEOM_LABEL: Label ufsid/49c3b0c4862f53b3 removed.
WARNING: R/W mount of /home denied.  Filesystem is not clean - run fsck
GEOM_LABEL: Label for provider da0s2e is ufsid/49c3b0c4862f53b3.
GEOM_LABEL: Label ufsid/49c3b0c4862f53b3 removed.
WARNING: R/W mount of /home denied.  Filesystem is not clean - run fsck
GEOM_LABEL: Label for provider da0s2e is ufsid/49c3b0c4862f53b3.
GEOM_LABEL: Label ufsid/49c3b0c4862f53b3 removed.
WARNING: R/W mount of /home denied.  Filesystem is not clean - run fsck
GEOM_LABEL: Label for provider da0s2e is ufsid/49c3b0c4862f53b3.
GEOM_LABEL: Label ufsid/49c3b0c4862f53b3 removed.
WARNING: R/W mount of /home denied.  Filesystem is not clean - run fsck
GEOM_LABEL: Label for provider da0s2e is ufsid/49c3b0c4862f53b3.
GEOM_LABEL: Label ufsid/49c3b0c4862f53b3 removed.
WARNING: R/W mount of /home denied.  Filesystem is not clean - run fsck
GEOM_LABEL: Label for provider da0s2e is ufsid/49c3b0c4862f53b3.
GEOM_LABEL: Label ufsid/49c3b0c4862f53b3 removed.
WARNING: R/W mount of /home denied.  Filesystem is not clean - run fsck
GEOM_LABEL: Label for provider da0s2e is ufsid/49c3b0c4862f53b3.
GEOM_LABEL: Label ufsid/49c3b0c4862f53b3 removed.
WARNING: R/W mount of /home denied.  Filesystem is not clean - run fsck
GEOM_LABEL: Label for provider da0s2e is ufsid/49c3b0c4862f53b3.
GEOM_LABEL: Label ufsid/49c3b0c4862f53b3 removed.
WARNING: R/W mount of /home denied.  Filesystem is not clean - run fsck
GEOM_LABEL: Label for provider da0s2e is ufsid/49c3b0c4862f53b3.
GEOM_LABEL: Label ufsid/49c3b0c4862f53b3 removed.
WARNING: R/W mount of /home denied.  Filesystem is not clean - run fsck
GEOM_LABEL: Label for provider da0s2e is ufsid/49c3b0c4862f53b3.
GEOM_LABEL: Label ufsid/49c3b0c4862f53b3 removed.
WARNING: R/W mount of /home denied.  Filesystem is not clean - run fsck
GEOM_LABEL: Label for provider da0s2e is ufsid/49c3b0c4862f53b3.
GEOM_LABEL: Label ufsid/49c3b0c4862f53b3 removed.
WARNING: R/W mount of /home denied.  Filesystem is not clean - run fsck
GEOM_LABEL: Label for provider da0s2e is ufsid/49c3b0c4862f53b3.
GEOM_LABEL: Label ufsid/49c3b0c4862f53b3 removed.
WARNING: R/W mount of /home denied.  Filesystem is not clean - run fsck
GEOM_LABEL: Label for provider da0s2e is ufsid/49c3b0c4862f53b3.
GEOM_LABEL: Label ufsid/49c3b0c4862f53b3 removed.
WARNING: R/W mount of /home denied.  Filesystem is not clean - run fsck
GEOM_LABEL: Label for provider da0s2e is ufsid/49c3b0c4862f53b3.
GEOM_LABEL: Label ufsid/49c3b0c4862f53b3 removed.
WARNING: R/W mount of /home denied.  Filesystem is not clean - run fsck
GEOM_LABEL: Label for provider da0s2e is ufsid/49c3b0c4862f53b3.
GEOM_LABEL: Label ufsid/49c3b0c4862f53b3 removed.
WARNING: R/W mount of /home denied.  Filesystem is not clean - run fsck
GEOM_LABEL: Label for provider da0s2e is ufsid/49c3b0c4862f53b3.
GEOM_LABEL: Label ufsid/49c3b0c4862f53b3 removed.
WARNING: R/W mount of /home denied.  Filesystem is not clean - run fsck
GEOM_LABEL: Label for provider da0s2e is ufsid/49c3b0c4862f53b3.
GEOM_LABEL: Label ufsid/49c3b0c4862f53b3 removed.
WARNING: R/W mount of /home denied.  Filesystem is not clean - run fsck
GEOM_LABEL: Label for provider da0s2e is ufsid/49c3b0c4862f53b3.
GEOM_LABEL: Label ufsid/49c3b0c4862f53b3 removed.
WARNING: R/W mount of /home denied.  Filesystem is not clean - run fsck
GEOM_LABEL: Label for provider da0s2e is ufsid/49c3b0c4862f53b3.
GEOM_LABEL: Label ufsid/49c3b0c4862f53b3 removed.
WARNING: R/W mount of /home denied.  Filesystem is not clean - run fsck
GEOM_LABEL: Label for provider da0s2e is ufsid/49c3b0c4862f53b3.
GEOM_LABEL: Label ufsid/49c3b0c4862f53b3 removed.
WARNING: R/W mount of /home denied.  Filesystem is not clean - run fsck
GEOM_LABEL: Label for provider da0s2e is ufsid/49c3b0c4862f53b3.
GEOM_LABEL: Label ufsid/49c3b0c4862f53b3 removed.
WARNING: R/W mount of /home denied.  Filesystem is not clean - run fsck
GEOM_LABEL: Label for provider da0s2e is ufsid/49c3b0c4862f53b3.
GEOM_LABEL: Label ufsid/49c3b0c4862f53b3 removed.
WARNING: R/W mount of /home denied.  Filesystem is not clean - run fsck
GEOM_LABEL: Label for provider da0s2e is ufsid/49c3b0c4862f53b3.
GEOM_LABEL: Label ufsid/49c3b0c4862f53b3 removed.
WARNING: R/W mount of /home denied.  Filesystem is not clean - run fsck
GEOM_LABEL: Label for provider da0s2e is ufsid/49c3b0c4862f53b3.
GEOM_LABEL: Label ufsid/49c3b0c4862f53b3 removed.
WARNING: R/W mount of /home denied.  Filesystem is not clean - run fsck
GEOM_LABEL: Label for provider da0s2e is ufsid/49c3b0c4862f53b3.
GEOM_LABEL: Label ufsid/49c3b0c4862f53b3 removed.
WARNING: R/W mount of /home denied.  Filesystem is not clean - run fsck
GEOM_LABEL: Label for provider da0s2e is ufsid/49c3b0c4862f53b3.
GEOM_LABEL: Label ufsid/49c3b0c4862f53b3 removed.
WARNING: R/W mount of /home denied.  Filesystem is not clean - run fsck
GEOM_LABEL: Label for provider da0s2e is ufsid/49c3b0c4862f53b3.
ukbd0: at uhub0 port 2 (addr 5) disconnected
ukbd0: detached
ums0: at uhub0 port 2 (addr 5) disconnected
ums0: detached


Fatal trap 12: page fault while in kernel mode
cpuid = 0; apic id = 00
fault virtual address   = 0x30
fault code              = supervisor read, page not present
instruction pointer     = 0x20:0xc0ad121f
stack pointer           = 0x28:0xe5720c64
frame pointer           = 0x28:0xe5720c74
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         = 16 (swi4: clock sio)
trap number             = 12
panic: page fault
cpuid = 0
Uptime: 24s
Physical memory: 2035 MB
Dumping 66 MB: 51 35 19 3

Reading symbols from /boot/kernel/acpi.ko...Reading symbols from 
/boot/kernel/acpi.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/acpi.ko
#0  doadump () at pcpu.h:196
196             __asm __volatile("movl %%fs:0,%0" : "=r" (td));
(kgdb)


-- 
No Swen today, my love has gone away
My mailbox stands for lorn, a symbol of the dawn 


From avg at icyb.net.ua  Wed May  6 12:54:52 2009
From: avg at icyb.net.ua (Andriy Gapon)
Date: Wed May  6 12:55:00 2009
Subject: [7.2] R/W mount of / denied. Filesystem not clean - run fsck.
In-Reply-To: <gtrt5m$ror$1@ger.gmane.org>
References: <gtrjq3$u24$1@ger.gmane.org> <gtrt5m$ror$1@ger.gmane.org>
Message-ID: <4A018897.4060303@icyb.net.ua>

on 06/05/2009 14:43 Helmut Schneider said the following:
> Fatal trap 12: page fault while in kernel mode
> cpuid = 0; apic id = 00
> fault virtual address   = 0x30
> fault code              = supervisor read, page not present
> instruction pointer     = 0x20:0xc0ad121f
> stack pointer           = 0x28:0xe5720c64
> frame pointer           = 0x28:0xe5720c74
> 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         = 16 (swi4: clock sio)
> trap number             = 12
> panic: page fault
> cpuid = 0
> Uptime: 24s
> Physical memory: 2035 MB
> Dumping 66 MB: 51 35 19 3
> 
> Reading symbols from /boot/kernel/acpi.ko...Reading symbols from
> /boot/kernel/acpi.ko.symbols...done.
> done.
> Loaded symbols for /boot/kernel/acpi.ko
> #0  doadump () at pcpu.h:196
> 196             __asm __volatile("movl %%fs:0,%0" : "=r" (td));
> (kgdb)

Output of bt command is missing after this line :-)

Do you maybe have some problem with your /etc directory or your rc.conf
configuration? Like missing /etc/rc.d/fsck or missing/corrupted other important rc
script. Or some such - pure guessing here.

-- 
Andriy Gapon
From jumper99 at gmx.de  Wed May  6 13:22:15 2009
From: jumper99 at gmx.de (Helmut Schneider)
Date: Wed May  6 13:22:25 2009
Subject: [7.2] R/W mount of / denied. Filesystem not clean - run fsck.
References: <gtrjq3$u24$1@ger.gmane.org> <gtrt5m$ror$1@ger.gmane.org>
	<4A018897.4060303@icyb.net.ua>
Message-ID: <gts2tj$ftp$1@ger.gmane.org>

Andriy Gapon <avg@icyb.net.ua> wrote:
> on 06/05/2009 14:43 Helmut Schneider said the following:
>> Fatal trap 12: page fault while in kernel mode
>> cpuid = 0; apic id = 00
>> fault virtual address   = 0x30
>> fault code              = supervisor read, page not present
>> instruction pointer     = 0x20:0xc0ad121f
>> stack pointer           = 0x28:0xe5720c64
>> frame pointer           = 0x28:0xe5720c74
>> 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         = 16 (swi4: clock sio)
>> trap number             = 12
>> panic: page fault
>> cpuid = 0
>> Uptime: 24s
>> Physical memory: 2035 MB
>> Dumping 66 MB: 51 35 19 3
>>
>> Reading symbols from /boot/kernel/acpi.ko...Reading symbols from
>> /boot/kernel/acpi.ko.symbols...done.
>> done.
>> Loaded symbols for /boot/kernel/acpi.ko
>> #0  doadump () at pcpu.h:196
>> 196             __asm __volatile("movl %%fs:0,%0" : "=r" (td));
>> (kgdb)
>
> Output of bt command is missing after this line :-)

(kgdb) bt
#0  doadump () at pcpu.h:196
#1  0xc081d7e7 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:418
#2  0xc081dab9 in panic (fmt=Variable "fmt" is not available.
) at /usr/src/sys/kern/kern_shutdown.c:574
#3  0xc0b1fc9c in trap_fatal (frame=0xe5720c24, eva=48) at 
/usr/src/sys/i386/i386/trap.c:939
#4  0xc0b1ff20 in trap_pfault (frame=0xe5720c24, usermode=0, eva=48) at 
/usr/src/sys/i386/i386/trap.c:852
#5  0xc0b208cc in trap (frame=0xe5720c24) at 
/usr/src/sys/i386/i386/trap.c:530
#6  0xc0b04fdb in calltrap () at /usr/src/sys/i386/i386/exception.s:159
#7  0xc0ad121f in atkbd_timeout (arg=0xc0d09a00) at 
/usr/src/sys/dev/atkbdc/atkbd.c:165
#8  0xc08301da in softclock (dummy=0x0) at 
/usr/src/sys/kern/kern_timeout.c:274
#9  0xc07fb74b in ithread_loop (arg=0xc5491260) at 
/usr/src/sys/kern/kern_intr.c:1088
#10 0xc07f8299 in fork_exit (callout=0xc07fb590 <ithread_loop>, 
arg=0xc5491260, frame=0xe5720d38)
    at /usr/src/sys/kern/kern_fork.c:810
#11 0xc0b05050 in fork_trampoline () at 
/usr/src/sys/i386/i386/exception.s:264
(kgdb)

> Do you maybe have some problem with your /etc directory or your rc.conf
> configuration? Like missing /etc/rc.d/fsck or missing/corrupted other
> important rc script. Or some such - pure guessing here.

'mergemaster -iF' says it's fine.

-- 
No Swen today, my love has gone away
My mailbox stands for lorn, a symbol of the dawn 


From avg at icyb.net.ua  Wed May  6 14:06:08 2009
From: avg at icyb.net.ua (Andriy Gapon)
Date: Wed May  6 14:06:15 2009
Subject: [7.2] R/W mount of / denied. Filesystem not clean - run fsck.
In-Reply-To: <gts2tj$ftp$1@ger.gmane.org>
References: <gtrjq3$u24$1@ger.gmane.org>
	<gtrt5m$ror$1@ger.gmane.org>	<4A018897.4060303@icyb.net.ua>
	<gts2tj$ftp$1@ger.gmane.org>
Message-ID: <4A019941.8030807@icyb.net.ua>

on 06/05/2009 16:21 Helmut Schneider said the following:
> (kgdb) bt
> #0  doadump () at pcpu.h:196
> #1  0xc081d7e7 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:418
> #2  0xc081dab9 in panic (fmt=Variable "fmt" is not available.
> ) at /usr/src/sys/kern/kern_shutdown.c:574
> #3  0xc0b1fc9c in trap_fatal (frame=0xe5720c24, eva=48) at
> /usr/src/sys/i386/i386/trap.c:939
> #4  0xc0b1ff20 in trap_pfault (frame=0xe5720c24, usermode=0, eva=48) at
> /usr/src/sys/i386/i386/trap.c:852
> #5  0xc0b208cc in trap (frame=0xe5720c24) at
> /usr/src/sys/i386/i386/trap.c:530
> #6  0xc0b04fdb in calltrap () at /usr/src/sys/i386/i386/exception.s:159
> #7  0xc0ad121f in atkbd_timeout (arg=0xc0d09a00) at
> /usr/src/sys/dev/atkbdc/atkbd.c:165
> #8  0xc08301da in softclock (dummy=0x0) at
> /usr/src/sys/kern/kern_timeout.c:274
> #9  0xc07fb74b in ithread_loop (arg=0xc5491260) at
> /usr/src/sys/kern/kern_intr.c:1088
> #10 0xc07f8299 in fork_exit (callout=0xc07fb590 <ithread_loop>,
> arg=0xc5491260, frame=0xe5720d38)
>    at /usr/src/sys/kern/kern_fork.c:810
> #11 0xc0b05050 in fork_trampoline () at
> /usr/src/sys/i386/i386/exception.s:264
> (kgdb)

Could you please examine frame 7? (fr 7; list; i loc; maybe some prints for the
variables of interest - kbd, kbdsw)

>> Do you maybe have some problem with your /etc directory or your rc.conf
>> configuration? Like missing /etc/rc.d/fsck or missing/corrupted other
>> important rc script. Or some such - pure guessing here.
> 
> 'mergemaster -iF' says it's fine.
> 

That's good. Although not very likely it's still possible that src tree might have
some problems.

Just in case, do you have PS/2 keyboard attached?

-- 
Andriy Gapon
From avg at icyb.net.ua  Wed May  6 14:14:20 2009
From: avg at icyb.net.ua (Andriy Gapon)
Date: Wed May  6 14:14:27 2009
Subject: kbd0 at both atkbd0 and ukbd0 [Was: [7.2] R/W mount of / denied.
 Filesystem not clean - run fsck.]
In-Reply-To: <gtrt5m$ror$1@ger.gmane.org>
References: <gtrjq3$u24$1@ger.gmane.org> <gtrt5m$ror$1@ger.gmane.org>
Message-ID: <4A019B38.3060101@icyb.net.ua>

on 06/05/2009 14:43 Helmut Schneider said the following:
> kbd1 at kbdmux0
[snip]
> atkbdc0: <Keyboard controller (i8042)> at port 0x60,0x64 on isa0
> atkbd0: <AT Keyboard> irq 1 on atkbdc0
> kbd0 at atkbd0
> atkbd0: [GIANT-LOCKED]
> atkbd0: [ITHREAD]
[snip]
> ukbd0: <IBM IBM MM2, class 0/0, rev 1.10/0.01, addr 5> on uhub0
> kbd0 at ukbd0

It took me three passes to notice the above: "kbd0 at atkbd0" and then again "kbd0
at ukbd0". I am not sure what this actually means, an expert is needed.
Just in case, do you have KBD_INSTALL_CDEV in kernel config?

-- 
Andriy Gapon
From jumper99 at gmx.de  Wed May  6 14:50:59 2009
From: jumper99 at gmx.de (Helmut Schneider)
Date: Wed May  6 14:51:07 2009
Subject: kbd0 at both atkbd0 and ukbd0 [Was: [7.2] R/W mount of /
	denied. Filesystem not clean - run fsck.]
References: <gtrjq3$u24$1@ger.gmane.org> <gtrt5m$ror$1@ger.gmane.org>
	<4A019B38.3060101@icyb.net.ua>
Message-ID: <gts83v$33c$1@ger.gmane.org>

Andriy Gapon <avg@icyb.net.ua> wrote:
> on 06/05/2009 14:43 Helmut Schneider said the following:
>> kbd1 at kbdmux0
> [snip]
>> atkbdc0: <Keyboard controller (i8042)> at port 0x60,0x64 on isa0
>> atkbd0: <AT Keyboard> irq 1 on atkbdc0
>> kbd0 at atkbd0
>> atkbd0: [GIANT-LOCKED]
>> atkbd0: [ITHREAD]
> [snip]
>> ukbd0: <IBM IBM MM2, class 0/0, rev 1.10/0.01, addr 5> on uhub0
>> kbd0 at ukbd0
> 
> It took me three passes to notice the above: "kbd0 at atkbd0" and then
> again "kbd0 at ukbd0". I am not sure what this actually means, an expert
> is needed. Just in case, do you have KBD_INSTALL_CDEV in kernel config?

# cat /sys/i386/conf/GENERIC-QUOTA-PF-ALTQ
include GENERIC

ident           GENERIC-QUOTA-PF-ALTQ

options         QUOTA
options         ALTQ
options         ALTQ_CBQ        # Class Bases Queuing (CBQ)
options         ALTQ_RED        # Random Early Detection (RED)
options         ALTQ_RIO        # RED In/Out
options         ALTQ_HFSC       # Hierarchical Packet Scheduler (HFSC)
options         ALTQ_PRIQ       # Priority Queuing (PRIQ)
options         ALTQ_NOPCC      # Required for SMP build

device          pf
device          pflog
device          pfsync
#

-- 
No Swen today, my love has gone away
My mailbox stands for lorn, a symbol of the dawn 

From jumper99 at gmx.de  Wed May  6 15:00:09 2009
From: jumper99 at gmx.de (Helmut Schneider)
Date: Wed May  6 15:00:16 2009
Subject: [7.2] R/W mount of / denied. Filesystem not clean - run fsck.
References: <gtrjq3$u24$1@ger.gmane.org><gtrt5m$ror$1@ger.gmane.org>	<4A018897.4060303@icyb.net.ua><gts2tj$ftp$1@ger.gmane.org>
	<4A019941.8030807@icyb.net.ua>
Message-ID: <gts8bt$3uo$1@ger.gmane.org>

Andriy Gapon <avg@icyb.net.ua> wrote:
> on 06/05/2009 16:21 Helmut Schneider said the following:
>> (kgdb) bt
>> #0  doadump () at pcpu.h:196
>> #1  0xc081d7e7 in boot (howto=260) at
>> /usr/src/sys/kern/kern_shutdown.c:418 #2  0xc081dab9 in panic
>> (fmt=Variable "fmt" is not available. ) at
>> /usr/src/sys/kern/kern_shutdown.c:574 #3  0xc0b1fc9c in trap_fatal
>> (frame=0xe5720c24, eva=48) at /usr/src/sys/i386/i386/trap.c:939
>> #4  0xc0b1ff20 in trap_pfault (frame=0xe5720c24, usermode=0, eva=48) at
>> /usr/src/sys/i386/i386/trap.c:852
>> #5  0xc0b208cc in trap (frame=0xe5720c24) at
>> /usr/src/sys/i386/i386/trap.c:530
>> #6  0xc0b04fdb in calltrap () at /usr/src/sys/i386/i386/exception.s:159
>> #7  0xc0ad121f in atkbd_timeout (arg=0xc0d09a00) at
>> /usr/src/sys/dev/atkbdc/atkbd.c:165
>> #8  0xc08301da in softclock (dummy=0x0) at
>> /usr/src/sys/kern/kern_timeout.c:274
>> #9  0xc07fb74b in ithread_loop (arg=0xc5491260) at
>> /usr/src/sys/kern/kern_intr.c:1088
>> #10 0xc07f8299 in fork_exit (callout=0xc07fb590 <ithread_loop>,
>> arg=0xc5491260, frame=0xe5720d38)
>>    at /usr/src/sys/kern/kern_fork.c:810
>> #11 0xc0b05050 in fork_trampoline () at
>> /usr/src/sys/i386/i386/exception.s:264
>> (kgdb)
>
> Could you please examine frame 7? (fr 7; list; i loc; maybe some prints
> for the variables of interest - kbd, kbdsw)

(kgdb) fr 7
#7  0xc0ad121f in atkbd_timeout (arg=0xc0d09a00) at 
/usr/src/sys/dev/atkbdc/atkbd.c:165
165             if ((*kbdsw[kbd->kb_index]->lock)(kbd, TRUE)) {
(kgdb) list
160              *
161              * The keyboard apparently unwedges the irq in most cases.
162              */
163             s = spltty();
164             kbd = (keyboard_t *)arg;
165             if ((*kbdsw[kbd->kb_index]->lock)(kbd, TRUE)) {
166                     /*
167                      * We have seen the lock flag is not set. Let's 
reset
168                      * the flag early, otherwise the LED update routine 
fails
169                      * which may want the lock during the interrupt 
routine.
(kgdb) i loc
No locals.
(kgdb)

> Just in case, do you have PS/2 keyboard attached?

No. Well. It's a module of the Blade Center which is connected via USB while 
mouse/keyboard are connected via PS/2. But the OS only sees an USB device.

-- 
No Swen today, my love has gone away
My mailbox stands for lorn, a symbol of the dawn 


From Gabor at Zahemszky.HU  Wed May  6 15:19:23 2009
From: Gabor at Zahemszky.HU (Zahemszky =?ISO-8859-2?Q?G=E1bor?=)
Date: Wed May  6 15:19:31 2009
Subject: IA64 7.2-RC2 in HP Integrity Virtual Machine
In-Reply-To: <DA7392F4-F624-487D-950E-0EF016B5FF41@mac.com>
References: <20090429063852.26767.qmail@mail.integrity.hu>
	<DA7392F4-F624-487D-950E-0EF016B5FF41@mac.com>
Message-ID: <20090506163043.0aad883b@Picasso.Zahemszky.HU>

> I believe there's a problem with mpt(4) that relates to
> its error recovery, or lack thereof.
> 
> Can you send a backtrace so that we can confirm or de-
> bunk that statement?

Hi!

here it is. (sorry for the ESC-sequences, it is the virtual machine's
EFI boot loader)

Attached.

G?bor < Gabor at Zahemszky dot HU >

-- 
#!/bin/ksh
Z='21N16I25C25E30, 40M30E33E25T15U!';
IFS=' ABCDEFGHIJKLMNOPQRSTUVWXYZ ';
set -- $Z;for i;{ [[ $i = ? ]]&&print $i&&break;
[[ $i = ??? ]]&&j=$i&&i=${i%?};
typeset -i40 i=8#$i;print -n ${i#???};
[[ "$j" = ??? ]]&&print -n "${j#??} "&&j=;typeset +i i;};
IFS=' 0123456789 ';set -- $Z;for i;{ [[ $i = , ]]&&i=2;
[[ $i = ?? ]]||typeset -l i;j="$j $i";typeset +l i;};print "$j"
-------------- next part --------------
A non-text attachment was scrubbed...
Name: typescript
Type: application/octet-stream
Size: 19600 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20090506/3122c691/typescript.obj
From 000.fbsd at quip.cz  Wed May  6 15:23:30 2009
From: 000.fbsd at quip.cz (Miroslav Lachman)
Date: Wed May  6 15:23:38 2009
Subject: Jails and IPv6
In-Reply-To: <4A00D1C5.2010806@ibctech.ca>
References: <4A00D1C5.2010806@ibctech.ca>
Message-ID: <4A01AB6D.2080304@quip.cz>

Steve Bertrand wrote:

> Hi all,
> 
> I've been using VMWare on Linux for quite some time, but I am fed up to
> the gills with the hassles I have to go through every time the box needs
> to be rebooted. I don't want to start a flame war, so let's just say
> that I'm already convinced of migrating to a solution that I don't need
> a Linux host for.
> 
> I need to be able to run multiple instances of FreeBSD on a single box,
> but I *need* IPv6 to work on the virtual machines.
> 
> I've read that this is now possible under 7.2. Is this really true?
> 
> What I'm looking to do, is set up a new host as IPv6 only. I don't want
> to use dedicated hardware if I don't have to, so I'm asking about jails
> first.
> 
> Operationally, are there any success stories regarding v6 and jails that
> anyone could share?

I am not using IPv6, but it works. The freebsd-jail@ mailinglist is 
better place to ask.
http://lists.freebsd.org/pipermail/freebsd-jail/2009-January/000702.html
http://lists.freebsd.org/pipermail/freebsd-jail/2008-December/000631.html

Miroslav Lachman
From bzeeb-lists at lists.zabbadoz.net  Wed May  6 16:00:07 2009
From: bzeeb-lists at lists.zabbadoz.net (Bjoern A. Zeeb)
Date: Wed May  6 16:00:14 2009
Subject: Jails and IPv6
In-Reply-To: <4A00D1C5.2010806@ibctech.ca>
References: <4A00D1C5.2010806@ibctech.ca>
Message-ID: <20090506155341.R72053@maildrop.int.zabbadoz.net>

On Tue, 5 May 2009, Steve Bertrand wrote:

Hi,

> I've been using VMWare on Linux for quite some time, but I am fed up to
> the gills with the hassles I have to go through every time the box needs
> to be rebooted. I don't want to start a flame war, so let's just say
> that I'm already convinced of migrating to a solution that I don't need
> a Linux host for.
>
> I need to be able to run multiple instances of FreeBSD on a single box,
> but I *need* IPv6 to work on the virtual machines.
>
> I've read that this is now possible under 7.2. Is this really true?

yes.

> What I'm looking to do, is set up a new host as IPv6 only. I don't want
> to use dedicated hardware if I don't have to, so I'm asking about jails
> first.
> 
> Operationally, are there any success stories regarding v6 and jails that
> anyone could share?

Apart from that a FreeBSD Cluster system has been using it since the
beta time of the patch w/o a crash, a few people on freebsd-jail@ who
had been using it.

/bz

-- 
Bjoern A. Zeeb                      The greatest risk is not taking one.
From xcllnt at mac.com  Wed May  6 16:22:28 2009
From: xcllnt at mac.com (Marcel Moolenaar)
Date: Wed May  6 16:22:35 2009
Subject: IA64 7.2-RC2 in HP Integrity Virtual Machine
In-Reply-To: <20090506163043.0aad883b@Picasso.Zahemszky.HU>
References: <20090429063852.26767.qmail@mail.integrity.hu>
	<DA7392F4-F624-487D-950E-0EF016B5FF41@mac.com>
	<20090506163043.0aad883b@Picasso.Zahemszky.HU>
Message-ID: <DB001D8D-A41C-477C-B8B4-C2C9973373A0@mac.com>


On May 6, 2009, at 7:30 AM, Zahemszky G?bor wrote:

>> I believe there's a problem with mpt(4) that relates to
>> its error recovery, or lack thereof.
>>
>> Can you send a backtrace so that we can confirm or de-
>> bunk that statement?
>
> Hi!
>
> here it is. (sorry for the ESC-sequences, it is the virtual machine's
> EFI boot loader)
>
> Attached.

Ok. It's not mpt(4). It looks like it's the VM itself
that's the problem. The page fault is the result of a
clobbered r17.

Looking at the registers and the source code, as well
as the assembly I conclude that writes to the region
registers (which are virtualized) cause a trap in the
VM and the context is not properly saved or restored.
I conclude this based on r16 being 1 (we've had 1
iteration of the loop on line 2220 in file
sys/ia64/ia64/pmap.c (assuming r16 is not clobbered).
This means we had at least 1 write to the region
register.
r17 is initialized to (&pm->pm_rid[0]) and since the
load has a post-increment of 4, it "walks" the pm_rid
array. It never has a value of 1. So, r17 must have
been clobbered, because it's never assigned 1 in the
program.

So either the VM is buggy, or you need explicit support
for the VM in the guest OS by design.

FYI,

-- 
Marcel Moolenaar
xcllnt@mac.com



From torfinn.ingolfsen at broadpark.no  Wed May  6 16:45:05 2009
From: torfinn.ingolfsen at broadpark.no (Torfinn Ingolfsen)
Date: Wed May  6 16:45:12 2009
Subject: RELENG_7 - has mergemaster changed logic since 7.2-RELEASE?
In-Reply-To: <4A00AF76.8010604@FreeBSD.org>
References: <20090504225012.392fa49f.torfinn.ingolfsen@broadpark.no>
	<4A00AF76.8010604@FreeBSD.org>
Message-ID: <20090506184500.70b2c6f2.torfinn.ingolfsen@broadpark.no>

On Tue, 05 May 2009 14:28:22 -0700
Doug Barton <dougb@FreeBSD.org> wrote:

> I've read this thread and find the whole thing very odd. In particular

I agree - it is odd.

I have a few more machines to upgrade in the coming weeks - if anyone
have a better testcase to find out what is going on, I'm ready for it.

> That shouldn't even be possible. You have to affirmatively choose 'i'
> (for install) for it to be installed at all, the default is to leave
> it in the temproot directory. Additionally, the code to handle
> deleting is some of the oldest code in the script, and hasn't changed
> in over 8 years.

Well, something has changed in the way mergemaster handles this, unless
there is something else in the make world procedure that updates files
in /etc?

To be clear, I follow this procedure:
1. make buildworld
2. make kernel
3. shutdown now
4. mergemaster -p
5. make installworld
6. mergemaster -iU
7. fastboot

> I saw your followup message, can you please do me a favor and modify
> your /etc/motd file again, then run the following in a script(1) and
> send me the log?   /bin/sh -x mergemaster -iU

Done - sent in personal mail.

HTH
-- 
Regards,
Torfinn Ingolfsen

From paul at paulstewart.org  Wed May  6 16:52:11 2009
From: paul at paulstewart.org (Paul Stewart)
Date: Wed May  6 16:52:18 2009
Subject: Keeping Updated
Message-ID: <000001c9ce66$ed588fc0$c809af40$@org>

Hi there.

 

I'm sorry if this seems like a basic question but slowly drifting back to
the FreeBSD world after 10 years away in the Linux world ;)

 

After some consideration, I believe I still like the idea of source based
updating versus binary.

 

This raises my first question - getting updating source. Where do I obtain
it from and how do I know when it's updated?  I presume only during major
updates/upgrades and/or security issues is when the source tree ever
changes?

 

I understand (or believe I do) on the whole "make buildworld", "make
installworld", "mergemaster -v" steps unless anything has changed in
7.2-RELEASE that I need to know about.  I also remember how to build my own
kernels and see that you can now do "make buildkernel KERNCONF=NEWKERNEL"
and "make installkernel KERNCONF=NEWKERNEL" which is nice too.

 

With that aside, I've been running "portsnap update" to keep the ports
updated.. am I missing anything here?  I presume that when portsnap finds an
updated port then I just need to rebuild it and upgrade?

 

I guess I'm kinda wondering the "condensed quick version" of what people are
typically doing to keep their system updated from source without making life
difficult ;)  Yes, I've been reading through various things to get myself
updated to newer info but there's also a lot of stuff on the Internet based
on older info hence why I'm asking.

 

Cheers,

 

Paul

 

 

 

From fjwcash at gmail.com  Wed May  6 17:31:23 2009
From: fjwcash at gmail.com (Freddie Cash)
Date: Wed May  6 17:31:30 2009
Subject: Keeping Updated
In-Reply-To: <000001c9ce66$ed588fc0$c809af40$@org>
References: <000001c9ce66$ed588fc0$c809af40$@org>
Message-ID: <b269bc570905061031i18459040ida11dbcaa5e05a82@mail.gmail.com>

On Wed, May 6, 2009 at 9:23 AM, Paul Stewart <paul@paulstewart.org> wrote:
<snip>
> I guess I'm kinda wondering the "condensed quick version" of what people are
> typically doing to keep their system updated from source without making life
> difficult ;) ?Yes, I've been reading through various things to get myself
> updated to newer info but there's also a lot of stuff on the Internet based
> on older info hence why I'm asking.

This is what I do.  I don't claim that it's perfect, nor that it's the
recommended way, but it works nicely, and provides some safety nets,
just in case.

For ports (requires the installation of portmaster and portaudit):

# portsnap fetch update
# portaudit -Fda > ~/ports-with-issues
# pkg_version -vl '<' > ~/ports-with-updates
# more /usr/ports/UPDATING

If there's anything in ports-with-issues, then look if there's an
update in ports-with-updates.  If there's anything in
ports-with-updates that *needs* to be updated (security fix, bug fix,
major feature needed, etc), then update only those ports:

# portmaster -bd [portname]


For source:

Subscribe to the freebsd security announcement mailing list.
Copy /usr/share/examples/cvsup/stable-supfile to /etc/supfile.source
Edit /etc/supfile.source to set tag= to RELENG_X_Y where X_Y is the
version you want to upgrade to (7_2, for example).
Then, whenever a security announcement is made:

# csup /etc/supfile.source
# cd /usr/src
# make buildworld
# make KERNCONF=WHATEVER buildkernel
# make KERNCONF=WHATEVER KODIR=/boot/newkernel installkernel
# nextboot -k newkernel
# shutdown -r now

<if it comes back up without errors>
# cd /usr/src
# make installworld
# mergemaster -iU
# mv /boot/kernel /boot/kernel.bak
# mv /boot/newkernel /boot/kernel
# shutdown -r now

Using KODIR and nextboot allows you a safety net.  If the boot using
/boot/newkernel fails, a simple reboot will bring it back up with
/boot/kernel (the old, working kernel).

-- 
Freddie Cash
fjwcash@gmail.com
From jumper99 at gmx.de  Wed May  6 19:18:15 2009
From: jumper99 at gmx.de (Helmut Schneider)
Date: Wed May  6 19:18:22 2009
Subject: [7.2] R/W mount of / denied. Filesystem not clean - run fsck.
References: <gtrjq3$u24$1@ger.gmane.org>
	<4A015725.3050603@ksu.ru><gtrmgk$6fc$1@ger.gmane.org>
	<4A01630A.5080201@ksu.ru>
Message-ID: <gtsnp8$uf1$1@ger.gmane.org>

Marat N.Afanasyev <amarat@ksu.ru> wrote:
> Helmut Schneider wrote:
>> I do have such thing (IBM Blade Center) but I'm looking for something to 
>> avoid the situation above. Something that lets me at least boot into 
>> single user mode.
>>
>
> if you have an ip-kvm you can drop into single-user and fsck any disk you 
> have. all you need to do is to choose 'single user' from beastie-menu. or 
> start kernel with -s parameter

I *do* now how to enter single user mode but the kernel panic'ed *before* 
the shell started. :)

-- 
No Swen today, my love has gone away
My mailbox stands for lorn, a symbol of the dawn 


From djv at iki.fi  Wed May  6 19:57:48 2009
From: djv at iki.fi (Tuomo Latto)
Date: Wed May  6 19:57:56 2009
Subject: Keeping Updated
In-Reply-To: <000001c9ce66$ed588fc0$c809af40$@org>
References: <000001c9ce66$ed588fc0$c809af40$@org>
Message-ID: <4A01E933.7070007@iki.fi>

Paul Stewart wrote:
> This raises my first question - getting updating source. Where do I obtain
> it from and how do I know when it's updated? I presume only during major
> updates/upgrades and/or security issues is when the source tree ever
> changes?

Umm... No. Or depends on what you mean.
http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/current-stable.html#STABLE


> I understand (or believe I do) on the whole "make buildworld", "make
> installworld", "mergemaster -v" steps unless anything has changed in
> 7.2-RELEASE that I need to know about.  I also remember how to build my own
> kernels and see that you can now do "make buildkernel KERNCONF=NEWKERNEL"
> and "make installkernel KERNCONF=NEWKERNEL" which is nice too.

http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/makeworld.html#CANONICAL-BUILD


> I guess I'm kinda wondering the "condensed quick version" of what people are
> typically doing to keep their system updated from source without making life
> difficult ;)  Yes, I've been reading through various things to get myself
> updated to newer info but there's also a lot of stuff on the Internet based
> on older info hence why I'm asking.

I don't know if remember this, but the Handbook is pretty much always
up-to-date and along with manual pages should be your first reference
for anything.
http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/index.html

To be more specific, you seemed to be interested in these topics
(but don't limit your reading to these):
http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/ports.html
http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/kernelconfig.html
http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/updating-upgrading.html


-- 
Tuomo

... Google "how to hook up a hose to a kitchen sink"
    Did you mean: "how to hook up a /horse/ to a kitchen sink"
    >> I hope there was a non-return valve in the hose connection somewhere;
    >> horse-sh!t in your water supply is baaaaad.
    > No, horse-shit in your water is just disgusting.
    > Sheep-shit in your water is baaaaaaaaad! :-)
    Sheep puns are baaaaaaaaad. ;)
                            -- on http://thedailywtf.com/Comments/
                                  Yes,_That_0x27_s_Exactly_What_I_Meant.aspx

From freebsd at byshenk.net  Wed May  6 20:14:44 2009
From: freebsd at byshenk.net (Greg Byshenk)
Date: Wed May  6 20:14:51 2009
Subject: [7.2] R/W mount of / denied. Filesystem not clean - run fsck.
In-Reply-To: <gtsnp8$uf1$1@ger.gmane.org>
References: <gtrjq3$u24$1@ger.gmane.org> <4A01630A.5080201@ksu.ru>
	<gtsnp8$uf1$1@ger.gmane.org>
Message-ID: <20090506201442.GR1550@core.byshenk.net>

On Wed, May 06, 2009 at 09:18:02PM +0200, Helmut Schneider wrote:
> Marat N.Afanasyev <amarat@ksu.ru> wrote:
> >Helmut Schneider wrote:

> >>I do have such thing (IBM Blade Center) but I'm looking for something to 
> >>avoid the situation above. Something that lets me at least boot into 
> >>single user mode.

> >if you have an ip-kvm you can drop into single-user and fsck any disk you 
> >have. all you need to do is to choose 'single user' from beastie-menu. or 
> >start kernel with -s parameter
 
> I *do* now how to enter single user mode but the kernel panic'ed *before* 
> the shell started. :)

The problem is that, if something is so far wrong that you can't even
get to the single-user shell, then there probably isn't anything else
but rescue.

One thing that might be an option:  at work, we use PXE for Linux and
FreeBSD installs, so one thing I've done is to create a pxeboot rescue
image (using the mfsroot from the rescue CD).  This means that, if there
is this sort of problem, we can boot into rescue mode from the network
(the BIOS is also redirected to the serial console) and not have to 
worry about swapping CDs.  The same thing should also work for remote
locations.


-- 
greg byshenk  -  gbyshenk@byshenk.net  -  Leiden, NL
From amarat at ksu.ru  Wed May  6 21:47:52 2009
From: amarat at ksu.ru (Marat N.Afanasyev)
Date: Wed May  6 21:48:00 2009
Subject: [7.2] R/W mount of / denied. Filesystem not clean - run fsck.
In-Reply-To: <gtsnp8$uf1$1@ger.gmane.org>
References: <gtrjq3$u24$1@ger.gmane.org>	<4A015725.3050603@ksu.ru><gtrmgk$6fc$1@ger.gmane.org>	<4A01630A.5080201@ksu.ru>
	<gtsnp8$uf1$1@ger.gmane.org>
Message-ID: <4A0204F1.1060700@ksu.ru>

Helmut Schneider wrote:
> Marat N.Afanasyev <amarat@ksu.ru> wrote:
>> Helmut Schneider wrote:
>>> I do have such thing (IBM Blade Center) but I'm looking for something 
>>> to avoid the situation above. Something that lets me at least boot 
>>> into single user mode.
>>>
>>
>> if you have an ip-kvm you can drop into single-user and fsck any disk 
>> you have. all you need to do is to choose 'single user' from 
>> beastie-menu. or start kernel with -s parameter
> 
> I *do* now how to enter single user mode but the kernel panic'ed 
> *before* the shell started. :)
> 
as far as I can guess from you other message panic occurs only after you see

Trying to mount root from ufs:/dev/da0s1a
WARNING: R/W mount of /home denied.  Filesystem is not clean - run fsck
GEOM_LABEL: Label for provider da0s2e is ufsid/49c3b0c4862f53b3.
[lots more]
Fatal trap 12: page fault while in kernel mode

so, I can suppose you don't start in single-user mode, because in 
single-user init do not try to mount root at all, so you cannot see the 
messages above.

if panics occur either in single or multiuser, then you can try 
livefs_cd/PXE

-- 
SY, Marat
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3221 bytes
Desc: S/MIME Cryptographic Signature
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20090506/b5611b3c/smime.bin
From bc979 at lafn.org  Wed May  6 23:33:53 2009
From: bc979 at lafn.org (Doug Hardie)
Date: Wed May  6 23:34:01 2009
Subject: Mergemaster
Message-ID: <1BA7DBA9-3C49-490A-B97C-DEB08DF2F696@lafn.org>

I have been following the discussion on mergemaster and one item is a  
bit annoying.  You can use -U in the command args which sets  
"AUTO_UPGRADE=yes".  That flag is not in mergemaster.rc.  It could be  
easily added to the rc file, but I suspect it would conflict with -p.   
Hence it seems like if "unset AUTO_UPGRADE" were added to the -p  
section then it would work.  It would be helpful to be able to include  
it in the rc file so I don't have to remember the options each time.
From A.J.Caines at halplant.com  Thu May  7 01:23:34 2009
From: A.J.Caines at halplant.com (Andrew J. Caines)
Date: Thu May  7 01:23:40 2009
Subject: Keeping Updated
In-Reply-To: <000001c9ce66$ed588fc0$c809af40$@org>
References: <000001c9ce66$ed588fc0$c809af40$@org>
Message-ID: <4A0231D7.1020206@halplant.com>

Paul,

> I guess I'm kinda wondering the "condensed quick version" of what 
> people are typically doing to keep their system updated from source 
> without making life difficult ;)

In addition to the reference already given, there is a concise
description under "COMMON ITEMS" near the end of src/UPDATING, with
header "To rebuild everything and install it on the current system".

I note what might be a missed correction where it says "make kernel" as
opposed to "make buildkernel".

I do it the wrong way, which has always worked perfectly for me for many
years using

http://halplant.com:2001/software/FreeBSD/scripts/update_fbsd

to fetch sources, build world and kernel while in multi-user, run from
cron. When I'm ready to install, I shutdown and run

http://halplant.com:2001/software/FreeBSD/scripts/install_fbsd

This is wrong because I don't boot the new kernel before installing the
new world.


-- 
-Andrew J. Caines-   Unix Systems Engineer   A.J.Caines@halplant.com
FreeBSD/Linux/Solaris, Web/Mail/Proxy/...   http://halplant.com:2001/
  "Machines take me by surprise with great frequency" - Alan Turing
From ma at dt.e-technik.tu-dortmund.de  Thu May  7 07:56:03 2009
From: ma at dt.e-technik.tu-dortmund.de (Matthias Andree)
Date: Thu May  7 07:56:10 2009
Subject: RELENG_7 - has mergemaster changed logic since 7.2-RELEASE?
In-Reply-To: <49FFEECE.20403@FreeBSD.org>
References: <20090504225012.392fa49f.torfinn.ingolfsen@broadpark.no>
	<49FF5901.600@gmail.com> <49FFEECE.20403@FreeBSD.org>
Message-ID: <op.utjt91lkt6kky0@merlin.emma.line.org>

Am 05.05.2009, 09:46 Uhr, schrieb Daniel Gerzo <danger@freebsd.org>:

> Manolis Kiagias wrote:
>
>> I always use -iU too.
>> I've lost motd, passwd, group and master.passwd
>> During mergemaster -p I was asked to merge changes to some of these, and
>> still they were replaced with the newer versions. I don't know what went
>> wrong but have restored them from backup. (I always tar /etc before a
>> source upgrade). Upgrading another system using freebsd-update did not
>> cause any problem.
>
> I have the same experience while I was upgrading a few machines  
> upgrading from RELENG_7 to RELENG_7_2. I haven't experienced when  
> upgrading from 7.1-R to 7.2-R.

Careful there - RELENG_7 is _newer_ than RELENG_7_2. The latter is  
branched off RELENG_7 at some point and progresses much slower (as in:  
errata and security, but no development), so that's no "update", but often  
the reverse.

-- 
Matthias Andree
From steve at ibctech.ca  Thu May  7 12:27:35 2009
From: steve at ibctech.ca (Steve Bertrand)
Date: Thu May  7 12:27:42 2009
Subject: Keeping Updated
In-Reply-To: <000001c9ce66$ed588fc0$c809af40$@org>
References: <000001c9ce66$ed588fc0$c809af40$@org>
Message-ID: <4A02D3AC.1050903@ibctech.ca>

Paul Stewart wrote:

> I guess I'm kinda wondering the "condensed quick version" of what people are
> typically doing to keep their system updated from source without making life
> difficult ;)  Yes, I've been reading through various things to get myself
> updated to newer info but there's also a lot of stuff on the Internet based
> on older info hence why I'm asking.

Not to take away from any of the other great responses, I just want to
throw out there that I use fastest_cvsup to find the csup server with
the lowest latency:

# pkg_add -r fastest_cvsup

... and then run it like this:

# fastest_cvsup -c ca,us

Given that I know where you are, you will likely always be best off with
cvsup.ca.FreeBSD.org, and put that into your supfile against default host.

I then run "csup -L 2 -g /etc/supfile" in cron for once a week. I'll
then update the actual system for advisories, new features if they apply
to me, or generally any time I turn up a new system or VM to keep them
all consistent.

Cheers,

Steve
From avk at vl.ru  Thu May  7 13:08:36 2009
From: avk at vl.ru (Alexander Kriventsov)
Date: Thu May  7 13:09:09 2009
Subject: RELENG_7 fatal trap
Message-ID: <4A02D708.3040805@vl.ru>

Hi,
Sorry for my english.
I have fatal trap on my box.
Kernel compiled with debug options. System is RELENG_7 amd64 dated 
2009-04-14.
Kernel config is
include         GENERIC

ident           GENERIC-DEBUG

device          carp
options         INCLUDE_CONFIG_FILE
options         KDB
options         KDB_UNATTENDED
options         DDB
options         BREAK_TO_DEBUGGER
nooptions       SCHED_4BSD
options         SCHED_ULE
options         SHMMAXPGS=65536
options         SEMMNI=40
options         SEMMNS=240
options         SEMUME=40
options         SEMMNU=120

$ uname -a
FreeBSD svc13.masterhost.ru 7.2-amd64-20090414-RELENG_7 FreeBSD 
7.2-amd64-20090414-RELENG_7 #0: Tue Apr 14 07:28:46 UTC 2009 
root@svc13.masterhost.ru:/usr/obj/usr/src/sys/GENERICDEBUG  amd64

In kgdb
$ kgdb /boot/GENERICDEBUG/kernel /var/crash/vmcore.2
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain 
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "amd64-marcel-freebsd"...

Unread portion of the kernel message buffer:


Fatal trap 12: page fault while in kernel mode
cpuid = 1; apic id = 01
fault virtual address   = 0x108
fault code              = supervisor write data, page not present
instruction pointer     = 0x8:0xffffffff805964bc
stack pointer           = 0x10:0xfffffffebe8b66d0
frame pointer           = 0x10:0xfffffffebe8b6740
code segment            = base 0x0, limit 0xfffff, type 0x1b
                         = DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags        = interrupt enabled, resume, IOPL = 0
current process         = 6010 (sh)
trap number             = 12
panic: page fault
cpuid = 1
GEOM_MIRROR: Device gm1: rebuilding provider da1s2 stopped.
Uptime: 27m29s
Physical memory: 2029 MB
Dumping 322 MB: 307 291 275 259 243 227 211 195 179 163 147 131 115 99 
83 67 51 35 19 3
Reading symbols from /boot/kernel/geom_mirror.ko...Reading symbols from 
/boot/GENERICDEBUG/geom_mirror.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/geom_mirror.ko
Reading symbols from /boot/kernel/geom_stripe.ko...Reading symbols from 
/boot/GENERICDEBUG/geom_stripe.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/geom_stripe.ko
Reading symbols from /boot/kernel/ipmi.ko...Reading symbols from 
/boot/GENERICDEBUG/ipmi.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/ipmi.ko
Reading symbols from /boot/kernel/smbus.ko...Reading symbols from 
/boot/GENERICDEBUG/smbus.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/smbus.ko
Reading symbols from /boot/kernel/ipl.ko...Reading symbols from 
/boot/GENERICDEBUG/ipl.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/ipl.ko
Reading symbols from /boot/kernel/if_vlan.ko...Reading symbols from 
/boot/GENERICDEBUG/if_vlan.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/if_vlan.ko
Reading symbols from /boot/kernel/nullfs.ko...Reading symbols from 
/boot/GENERICDEBUG/nullfs.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/nullfs.ko
Reading symbols from /boot/kernel/linprocfs.ko...Reading symbols from 
/boot/GENERICDEBUG/linprocfs.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/linprocfs.ko
Reading symbols from /boot/kernel/linux.ko...Reading symbols from 
/boot/GENERICDEBUG/linux.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/linux.ko
#0  doadump () at pcpu.h:195
195     pcpu.h: No such file or directory.
         in pcpu.h
(kgdb) bt
#0  doadump () at pcpu.h:195
#1  0xffffffff80521b08 in boot (howto=260) at 
/usr/src/sys/kern/kern_shutdown.c:418
#2  0xffffffff80521f6c in panic (fmt=Variable "fmt" is not available.
) at /usr/src/sys/kern/kern_shutdown.c:574
#3  0xffffffff807f1fc3 in trap_fatal (frame=0xc, eva=Variable "eva" is 
not available.
) at /usr/src/sys/amd64/amd64/trap.c:757
#4  0xffffffff807f23a4 in trap_pfault (frame=0xfffffffebe8b6620, 
usermode=0) at /usr/src/sys/amd64/amd64/trap.c:673
#5  0xffffffff807f2d52 in trap (frame=0xfffffffebe8b6620) at 
/usr/src/sys/amd64/amd64/trap.c:444
#6  0xffffffff807d660e in calltrap () at 
/usr/src/sys/amd64/amd64/exception.S:209
#7  0xffffffff805964bc in cache_lookup (dvp=0x0, vpp=0xfffffffebe8b6978, 
cnp=0xfffffffebe8b69a0) at atomic.h:143
#8  0xffffffff80596903 in vfs_cache_lookup (ap=Variable "ap" is not 
available.
) at /usr/src/sys/kern/vfs_cache.c:747
#9  0xffffffff808393a0 in VOP_LOOKUP_APV (vop=0xffffffff80afcc20, 
a=0xfffffffebe8b6820) at vnode_if.c:99
#10 0xffffffff8059d0d8 in lookup (ndp=0xfffffffebe8b6950) at vnode_if.h:57
#11 0xffffffff8059debe in namei (ndp=0xfffffffebe8b6950) at 
/usr/src/sys/kern/vfs_lookup.c:215
#12 0xffffffff805ac721 in kern_stat (td=0xffffff004546e000, 
path=0x800b04400 <Address 0x800b04400 out of bounds>, pathseg=Variable 
"pathseg" is not available.
)
     at /usr/src/sys/kern/vfs_syscalls.c:2123
#13 0xffffffff805ac98a in stat (td=Variable "td" is not available.
) at /usr/src/sys/kern/vfs_syscalls.c:2107
#14 0xffffffff807f2626 in syscall (frame=0xfffffffebe8b6c80) at 
/usr/src/sys/amd64/amd64/trap.c:900
#15 0xffffffff807d681b in Xfast_syscall () at 
/usr/src/sys/amd64/amd64/exception.S:330
#16 0x00000008009895ec in ?? ()
Previous frame inner to this frame (corrupt stack?)
(kgdb) bt full
#0  doadump () at pcpu.h:195
No locals.
#1  0xffffffff80521b08 in boot (howto=260) at 
/usr/src/sys/kern/kern_shutdown.c:418
         _ep = (struct eventhandler_entry *) 0x0
         _el = Variable "_el" is not available.

Please give me advise.
Thanks
From danger at FreeBSD.org  Thu May  7 13:46:09 2009
From: danger at FreeBSD.org (Daniel Gerzo)
Date: Thu May  7 13:46:16 2009
Subject: RELENG_7 - has mergemaster changed logic since 7.2-RELEASE?
In-Reply-To: <op.utjt91lkt6kky0@merlin.emma.line.org>
References: <20090504225012.392fa49f.torfinn.ingolfsen@broadpark.no>
	<49FF5901.600@gmail.com> <49FFEECE.20403@FreeBSD.org>
	<op.utjt91lkt6kky0@merlin.emma.line.org>
Message-ID: <62bf86e574316680f37efd872c1d361a@services.rulez.sk>


On Thu, 07 May 2009 09:40:52 +0200, "Matthias Andree"
<ma@dt.e-technik.tu-dortmund.de> wrote:
> Am 05.05.2009, 09:46 Uhr, schrieb Daniel Gerzo <danger@freebsd.org>:
> 
>> Manolis Kiagias wrote:
>>
>>> I always use -iU too.
>>> I've lost motd, passwd, group and master.passwd
>>> During mergemaster -p I was asked to merge changes to some of these,
and
>>> still they were replaced with the newer versions. I don't know what
went
>>> wrong but have restored them from backup. (I always tar /etc before a
>>> source upgrade). Upgrading another system using freebsd-update did not
>>> cause any problem.
>>
>> I have the same experience while I was upgrading a few machines  
>> upgrading from RELENG_7 to RELENG_7_2. I haven't experienced when  
>> upgrading from 7.1-R to 7.2-R.
> 
> Careful there - RELENG_7 is _newer_ than RELENG_7_2. The latter is  
> branched off RELENG_7 at some point and progresses much slower (as in:  
> errata and security, but no development), so that's no "update", but
often 
> 
> the reverse.

That's not definitely true all the time. You could for example update your
7.1 to releng_7, say in Sept. 2008, then run this box until releng_7_2 was
branched and when you update to it at that point you actually are doing an
update, definitely not a downgrade.

-- 
Kind regards
  Daniel
From jumper99 at gmx.de  Thu May  7 14:17:58 2009
From: jumper99 at gmx.de (Helmut Schneider)
Date: Thu May  7 14:18:05 2009
Subject: kbd0 at both atkbd0 and ukbd0 [Was: [7.2] R/W mount of /
	denied. Filesystem not clean - run fsck.]
References: <gtrjq3$u24$1@ger.gmane.org> <gtrt5m$ror$1@ger.gmane.org>
	<4A019B38.3060101@icyb.net.ua>
Message-ID: <gtuqi6$irb$1@ger.gmane.org>

Andriy Gapon <avg@icyb.net.ua> wrote:
> on 06/05/2009 14:43 Helmut Schneider said the following:
>> kbd1 at kbdmux0
> [snip]
>> atkbdc0: <Keyboard controller (i8042)> at port 0x60,0x64 on isa0
>> atkbd0: <AT Keyboard> irq 1 on atkbdc0
>> kbd0 at atkbd0
>> atkbd0: [GIANT-LOCKED]
>> atkbd0: [ITHREAD]
> [snip]
>> ukbd0: <IBM IBM MM2, class 0/0, rev 1.10/0.01, addr 5> on uhub0
>> kbd0 at ukbd0
>
> It took me three passes to notice the above: "kbd0 at atkbd0" and then
> again "kbd0 at ukbd0".

Good point:

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

I have 'hint.atkbd.0.disabled="1"' at /boot/default.hints and (probably) 
freebsd-update killed that one and silently replaced it with
1.16.8.1. The whole mess might be related. D'oh!

-- 
No Swen today, my love has gone away
My mailbox stands for lorn, a symbol of the dawn 


From riccardo.torrini at esaote.com  Thu May  7 16:02:12 2009
From: riccardo.torrini at esaote.com (Riccardo Torrini)
Date: Thu May  7 16:02:45 2009
Subject: kern/130330: [mpt] [panic] Panic and reboot machine MPT ...
Message-ID: <20090507155012.GW21112@tiger.fi.esaote.it>

I just submitted a follow-up to PR kern/130330 with the same
info.  Maybe I found the committed lines doing the crash.

Please see PR for more detailed info (and cc: this thread to me).

I restricted the time window of the problem doing (a lot of)
build&install world from 2008.07 up to now (read last week).

With 2008.07.28.17.00.00 (7.0-STABLE) works fine but
with 2008.07.28.18.00.00 start crashing removing the
the second disk of a mirror (when the mirror is ok)
or adding the second disk of a degraded ones.

Also note that the same crash happens with all 7.1
stable or release and even all 7.2-PRE I tested.

(wrapping long lines)
# cd /home/ncvs/src/sys/
# grep -R "date.*2008\.07\.28\.17" ./ | grep -v /Attic

./dev/wi/if_wi.c,v:
        date    2008.07.28.17.00.37;    author imp;     state Exp;
./dev/wi/if_wivar.h,v:
        date    2008.07.28.17.00.37;    author imp;     state Exp;
./dev/mpt/mpt_raid.c,v:
        date    2008.07.28.17.10.09;    author jhb;     state Exp;
./dev/mpt/mpt_raid.c,v:
        date    2008.07.28.17.05.09;    author jhb;     state Exp;
./kern/sched_4bsd.c,v:
        date    2008.07.28.17.25.24;    author jhb;     state Exp;
./modules/et/Makefile,v:
        date    2008.07.28.17.56.37;    author antoine; state Exp;

In that time window there are only 4 file changed in
src/sys/dev, and I bet to mpt_raid.c  :-)

This is the commit log extracted from cvsweb
-----8<-----
Revision 1.15.2.1:
Mon Jul 28 17:05:09 2008 UTC (9 months, 1 week ago) by jhb
Branches: RELENG_7
CVS tags: RELENG_7_1_BP
Branch point for: RELENG_7_1
Diff to: previous 1.15: preferred, colored
Changes since revision 1.15: +4 -4 lines

SVN rev 180920 on 2008-07-28 17:05:09Z by jhb

MFC: Allocate a single CCB at the start of the main loop of the RAID
monitoring kthread of the mpt(4) driver.
-----8<-----

Here are the diff:
http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/mpt/mpt_raid.c.diff?r1=1.15;r2=1.15.2.1


What can I do now?


-- 
Riccardo.
Network Manager @ ESAOTE S.p.A.
From steve at ibctech.ca  Thu May  7 22:59:48 2009
From: steve at ibctech.ca (Steve Bertrand)
Date: Thu May  7 22:59:55 2009
Subject: Jails and IPv6
Message-ID: <4A0367DA.80200@ibctech.ca>

I just want to throw out a heart-felt thank you, congratulations and
excellent work to all those who had their hand in making the jail
framework so completely flexible (particularly on the IP side of things).

Kudos, and thank you all. IPv6 works flawlessly!

Steve
From david at usermode.org  Fri May  8 05:29:23 2009
From: david at usermode.org (David Johnson)
Date: Fri May  8 05:29:31 2009
Subject: Xorg hangs with drmwtq in 7.2-RELEASE
In-Reply-To: <200905052041.48623.david@usermode.org>
References: <200905042015.29394.david@usermode.org>
	<1241504417.1828.19.camel@balrog.2hip.net>
	<200905052041.48623.david@usermode.org>
Message-ID: <200905072229.17798.david@usermode.org>

On Tuesday 05 May 2009 08:41:48 pm David Johnson wrote:
> On Monday 04 May 2009 11:20:17 pm Robert Noland wrote:
> > This generally suggests that the GPU is locked up...  Given that you say
> > sometimes it locks up hard (usually a panic, that you can't see since X
> > is running) and other times only X is stalled it might be related to
> > this patch, if you haven't tried this on already.
> >
> > http://people.freebsd.org/~rnoland/drm_radeon-copyin-fix-try2.patch
>
> Nope, that didn't help. Still froze when I tried opening multiple windows
> at once. I'm backing out the patch to get back to a clean state.
>
> I also edited my xorg.conf to be closer to yours. No difference.
>
> What information do you need to go forward, and how do I collect it?
>
> p.s. I didn't have a problem with sources from RELENG_7 date=2009.03.13, if
> that helps any.

I just upgraded graphics/libdrm. It didn't help any. I'm just shooting blanks 
in the dark. Any help would be greatly appreciated. Please let me know what 
information is needed and how I collect it.

Thank you,

-- 
David Johnson
From david.marec at davenulle.org  Fri May  8 10:05:54 2009
From: david.marec at davenulle.org (David Marec)
Date: Fri May  8 10:06:01 2009
Subject: EEEPC and FreeBSD 7.2
Message-ID: <200905081147.46736.david.marec@davenulle.org>

hi!

I am trying to use an EEEPC 701 as a diskless station, running FreeBSD 7.2.

The EEPC station boots well with PXE then runs the kernel, but the only 
network card that is recognized is the wireless one (ath0).

I read that the wired NIC ( ae? ) has been committed to HEAD; is there any way 
to make it work on 7-STABLE ?



-- 
http://david.marec.free.fr/
http://www.freebsd.org/fr/	http://www.diablotins.org/
From sklarkin at gmail.com  Fri May  8 11:17:58 2009
From: sklarkin at gmail.com (sklarkin)
Date: Fri May  8 11:18:05 2009
Subject: EEEPC and FreeBSD 7.2
In-Reply-To: <200905081147.46736.david.marec@davenulle.org>
References: <200905081147.46736.david.marec@davenulle.org>
Message-ID: <20090508145138.7269eb1a@gmail.com>

? Fri, 8 May 2009 11:47:46 +0200
David Marec <david.marec@davenulle.org> ?????:

> hi!
> 
> I am trying to use an EEEPC 701 as a diskless station, running
> FreeBSD 7.2.
> 
> The EEPC station boots well with PXE then runs the kernel, but the
> only network card that is recognized is the wireless one (ath0).
> 
> I read that the wired NIC ( ae? ) has been committed to HEAD; is
> there any way to make it work on 7-STABLE ?
> 
> 
> 

http://wiki.freebsd.org/AsusEee

-- 
From brueffer at FreeBSD.org  Fri May  8 13:46:55 2009
From: brueffer at FreeBSD.org (Christian Brueffer)
Date: Fri May  8 13:47:02 2009
Subject: Freebsd 7.2-RC boot problem
In-Reply-To: <1241017310.68402.133.camel@bauer.cse.buffalo.edu>
References: <49F5BB24.2090206@nlink.com.br>
	<1240844716.59908.14.camel@bauer.cse.buffalo.edu>
	<49F5E723.6040700@nlink.com.br>
	<1240852596.59908.33.camel@bauer.cse.buffalo.edu>
	<49F6FC02.7060803@nlink.com.br>
	<1241006514.38254.12.camel@neo.cse.buffalo.edu>
	<49F8458D.7000607@nlink.com.br> <49F86536.9080604@nlink.com.br>
	<1241017310.68402.133.camel@bauer.cse.buffalo.edu>
Message-ID: <20090508131652.GB1187@haakonia.hitnet.RWTH-Aachen.DE>

On Wed, Apr 29, 2009 at 11:01:50AM -0400, Ken Smith wrote:
> On Wed, 2009-04-29 at 11:33 -0300, Paulo Fragoso wrote:
> > Hardware:
> > MB: Gigabyte GA-M61PME-S2
> > acd0: DVDR <HL-DT-STDVD-RAM GH22NS30/1.01> at ata3-master SATA150
> > 
> > ISO                      MEDIA       BOOT
> > 7.2-RC2-i386-dvd1.iso    DVD-RW       OK
> > 7.2-RC2-i386-livefs.iso  CD-RW        OK!
> > 7.2-RC2-amd64-disc1.iso  CD-RW        OK
> > 7.2-RC2-i386-disc1.iso   CD-RW,CD-R  FAILS
> 
> Thanks, greatly appreciate all the testing.
> 
> As part of looking into this I went looking for another Gigabyte
> motherboard and through the past 2 days was able to test the same set of
> things with the same results.  So far I haven't been able to reproduce
> this on anything but Gigabyte.  This is such a bizarre problem I really
> needed someone else to confirm so thank you very much.  Since there is a
> workaround I don't think I'll hold the release for this problem but we
> will need to mention this in the Errata (and possibly the announcement
> itself).
> 

I just got bitten by this on a VIA EPIA-M system.

7.2-RELEASE-i386-disc1.iso doesn't work
7.2-RELEASE-i386-bootonly.iso works

- Christian

-- 
Christian Brueffer	chris@unixpages.org	brueffer@FreeBSD.org
GPG Key:	 http://people.freebsd.org/~brueffer/brueffer.key.asc
GPG Fingerprint: A5C8 2099 19FF AACA F41B  B29B 6C76 178C A0ED 982D
-------------- 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-stable/attachments/20090508/8d4af5d8/attachment.pgp
From dudu.meyer at gmail.com  Fri May  8 14:18:41 2009
From: dudu.meyer at gmail.com (Eduardo Meyer)
Date: Fri May  8 14:18:47 2009
Subject: "maxproc limit exceeded" making no sense
Message-ID: <d3ea75b30905080651p1eaba0dep7073cd62c37f8f3f@mail.gmail.com>

Hello,

I have a problem which makes no sense to me, at least not the way I
understand. My mail server is compaining about maxproc limit:

# tail /var/log/messages
May  8 10:34:15 mx kernel: maxproc limit exceeded by uid 82, please
see tuning(7) and
login.conf(5).
May  8 10:34:38 mx last message repeated 12 times
May  8 10:35:14 mx last message repeated 18 times
May  8 10:36:32 mx last message repeated 41 times
May  8 10:36:35 mx kernel: maxproc limit exceeded by uid 82, please
see tuning(7) and
login.conf(5).

My maxproc as well as maxfiles are artificially raised (a lot raised):

# sysctl kern.maxfiles
kern.maxfiles: 80000

# sysctl kern.maxfilesperproc
kern.maxfilesperproc: 80000

# sysctl kern.maxproc
kern.maxproc: 9000

# sysctl kern.maxprocperuid
kern.maxprocperuid: 80000

However what I see regarding proc usage is by uid 82 is:

# ps -U 82 | wc -l
     723

Proccess count for UID 82 is never highter than 913 (monitored the
last whole hour, while log messages were still showing, complaining
about maxproc limit beeing exceeded).

I would like to understand and figure out what I need to tune in order
to raise the current limit, and also find what the current limit is.

Thank you a lot and in advance.


-- 
===========
Eduardo Meyer
pessoal: dudu.meyer@gmail.com
profissional: ddm.farmaciap@saude.gov.br
From rnoland at FreeBSD.org  Fri May  8 14:36:12 2009
From: rnoland at FreeBSD.org (Robert Noland)
Date: Fri May  8 14:36:20 2009
Subject: Xorg hangs with drmwtq in 7.2-RELEASE
In-Reply-To: <200905072229.17798.david@usermode.org>
References: <200905042015.29394.david@usermode.org>
	<1241504417.1828.19.camel@balrog.2hip.net>
	<200905052041.48623.david@usermode.org>
	<200905072229.17798.david@usermode.org>
Message-ID: <1241793345.1733.5.camel@balrog.2hip.net>

On Thu, 2009-05-07 at 22:29 -0700, David Johnson wrote:
> On Tuesday 05 May 2009 08:41:48 pm David Johnson wrote:
> > On Monday 04 May 2009 11:20:17 pm Robert Noland wrote:
> > > This generally suggests that the GPU is locked up...  Given that you say
> > > sometimes it locks up hard (usually a panic, that you can't see since X
> > > is running) and other times only X is stalled it might be related to
> > > this patch, if you haven't tried this on already.
> > >
> > > http://people.freebsd.org/~rnoland/drm_radeon-copyin-fix-try2.patch
> >
> > Nope, that didn't help. Still froze when I tried opening multiple windows
> > at once. I'm backing out the patch to get back to a clean state.
> >
> > I also edited my xorg.conf to be closer to yours. No difference.
> >
> > What information do you need to go forward, and how do I collect it?
> >
> > p.s. I didn't have a problem with sources from RELENG_7 date=2009.03.13, if
> > that helps any.
> 
> I just upgraded graphics/libdrm. It didn't help any. I'm just shooting blanks 
> in the dark. Any help would be greatly appreciated. Please let me know what 
> information is needed and how I collect it.

I still can't reproduce this...  I updated the Xserver, libGL and dri
ports yesterday, all of which could be related to locking up the GPU and
worth a shot.  Failing that, I need you to enabled drm debugging. Start
the system without X, kldload radeon.ko, set sysctl hw.dri.0.debug=1
then startx.

robert.

> Thank you,
> 
-- 
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-stable/attachments/20090508/b31badf6/attachment.pgp
From ubm at u-boot-man.de  Fri May  8 20:00:06 2009
From: ubm at u-boot-man.de (Marc UBM Bocklet)
Date: Fri May  8 20:00:13 2009
Subject: problems with sata disks (taskqueue timeout)
In-Reply-To: <20090329110153.f625612f.ubm@u-boot-man.de>
References: <20090119202016.11f42e3b.ubm.freebsd@gmail.com>
	<49750137.7020105@modulus.org>
	<20090120080829.b4006877.ubm@u-boot-man.de>
	<20090329110153.f625612f.ubm@u-boot-man.de>
Message-ID: <20090508214025.540b78e8.ubm@u-boot-man.de>

On Sun, 29 Mar 2009 11:01:53 +0200
Marc "UBM" Bocklet <ubm@u-boot-man.de> wrote:

> On Tue, 20 Jan 2009 08:08:29 +0100
> Marc "UBM" Bocklet <ubm@u-boot-man.de> wrote:
> 
> > On Tue, 20 Jan 2009 09:39:51 +1100
> > Andrew Snow <andrew@modulus.org> wrote:
> > 
> > > 
> > > I think that if you use eSATA you probably need dedicated eSATA 
> > > controller ports.  eSATA standard specifies a higher voltage for
> > > the longer cable distances.
> > > 
> > > Judging from the sporadic problem reports, Promise TX4 is probably
> > > not the best at signal purity to begin with so using it for eSATA
> > > pushes it over the edge.
> > > 
> > > 
> > > Hope that helps,
> > 
> > Thanks for the fast answer! :-)
> > 
> > Although my version of the TX4 has two dedicated e-sata ports, the
> > other posts seem to indicate that it got something to do with the
> > controller (maybe signal purity, like you said). I'll try upgrading
> > next and will report back after that.
> 
> A very late followup here:
> 
> I upgraded to the latest stable, but things did not improve:
> 
> Mar 29 10:57:29 hamstor kernel: ad10: WARNING - WRITE_DMA48 UDMA ICRC
> error (retrying request) LBA=1087300992 Mar 29 10:57:34 hamstor
> kernel: ad10: FAILURE - SET_MULTI status=51<READY,DSC,ERROR>
> error=4<ABORTED>
> 
> Mar 29 10:57:34 hamstor kernel: ad10: TIMEOUT - WRITE_DMA48 retrying
> (0 retries left) LBA=1087300992
> 
> Mar 29 10:57:34 hamstor kernel: ad10: FAILURE - WRITE_DMA48
> status=ff<BUSY,READY,DMA_READY,DSC,DRQ,CORRECTABLE,INDEX,ERROR>
> error=ff<ICRC,UNCORRECTABLE,MEDIA_CHANGED,NID_NOT_FOUND,MEDIA_CHANGE_REQEST,ABORTED,NO_MEDIA,ILLEGAL_LENGTH>
> LBA=1087300992 
> 
> Mar 29 10:57:34 hamstor root: ZFS: vdev I/O failure,
> zpool=gedaerm path=/dev/ad10 offset=556698042368 size=131072 error=5
> 
> Mar 29 10:57:43 hamstor kernel: ad10: WARNING - SETFEATURES SET
> TRANSFER MODE taskqueue timeout - completing request directly 
> 
> Mar 29 10:57:47 hamstor kernel: ad10: WARNING - SETFEATURES SET
> TRANSFER MODE taskqueue timeout - completing request directly 
> 
> Mar 29 10:57:51 hamstor kernel: ad10: WARNING - SETFEATURES ENABLE
> WCACHE taskqueue timeout - completing request directly 
> 
> Mar 29 10:57:55 hamstor kernel: ad10: WARNING - SET_MULTI taskqueue
> timeout - completing request directly 
> 
> Mar 29 10:57:55 hamstor kernel: ad10: TIMEOUT - WRITE_DMA48 retrying
> (1 retry left) LBA=1087301248 
> 
> Mar 29 10:57:55 hamstor kernel: ad10: WARNING - WRITE_DMA48 UDMA ICRC
> error (retrying request) LBA=1087301248 
> 
> Mar 29 10:58:00 hamstor kernel: ad10: FAILURE - SET_MULTI
> status=51<READY,DSC,ERROR> error=4<ABORTED> 
> 
> Mar 29 10:58:00 hamstor kernel: ad10: FAILURE - WRITE_DMA48 timed out
> LBA=1087301248
> 
> Mar 29 10:58:00 hamstor root: ZFS: vdev I/O failure, zpool=gedaerm
> path=/dev/ad10 offset=556698173440 size=131072 error=5
> 
> 
> 
> Any further ideas anybody? :-)

Another update, upgrading to -current dating from April 25th 2009 seems
to have "fixed" the problem, I've encountered no errors as of yet and
I've copied about 250GB in large chunks, something that was sure to
provoke the errors with -stable.

FreeBSD xxx 8.0-CURRENT FreeBSD 8.0-CURRENT #1: Sat Apr 25 13:33:18
CEST 2009 xxx:/usr/obj/usr/src/sys/xxx  amd64

Bye
Marc

-- 
"And what rough beast, its hour come round at last,
Slouches towards Bethlehem to be born?"

W.B. Yeats, The Second Coming
From bzeeb-lists at lists.zabbadoz.net  Fri May  8 20:50:07 2009
From: bzeeb-lists at lists.zabbadoz.net (Bjoern A. Zeeb)
Date: Fri May  8 20:50:18 2009
Subject: Jails and IPv6
In-Reply-To: <4A0367DA.80200@ibctech.ca>
References: <4A0367DA.80200@ibctech.ca>
Message-ID: <20090508204023.T72053@maildrop.int.zabbadoz.net>

On Thu, 7 May 2009, Steve Bertrand wrote:

Hi Steve,

> I just want to throw out a heart-felt thank you, congratulations and
> excellent work to all those who had their hand in making the jail
> framework so completely flexible (particularly on the IP side of things).
>
> Kudos, and thank you all. IPv6 works flawlessly!

Happy to see things work fine for you as well:)  It's really great to
get feedback like that!   Obviously, if you find any problem we'll also
like to hear about that. In that case you may probably want to post to
the freebsd-jail mailing list to get help.

The same obviously applies to anyone going to give it a try;-)

/bz

PS: saying what I have said before: if you are using jails and like
the new features and they work out for you or you may make money by
using them and want to give something back, consider a donation to
the FreeBSD Foundation: see http://www.freebsdfoundation.org/donate/

-- 
Bjoern A. Zeeb                      The greatest risk is not taking one.
From david at usermode.org  Fri May  8 21:59:01 2009
From: david at usermode.org (David Johnson)
Date: Fri May  8 21:59:08 2009
Subject: Xorg hangs with drmwtq in 7.2-RELEASE
In-Reply-To: <1241793345.1733.5.camel@balrog.2hip.net>
References: <200905042015.29394.david@usermode.org>
	<200905072229.17798.david@usermode.org>
	<1241793345.1733.5.camel@balrog.2hip.net>
Message-ID: <200905081458.53651.david@usermode.org>

On Friday 08 May 2009 07:35:45 am Robert Noland wrote:
> I still can't reproduce this...  I updated the Xserver, libGL and dri
> ports yesterday, all of which could be related to locking up the GPU and
> worth a shot.  Failing that, I need you to enabled drm debugging. Start
> the system without X, kldload radeon.ko, set sysctl hw.dri.0.debug=1
> then startx.

I've got all the updated ports as of last night, so that wasn't it.

I turned AIGLX back on, and it promptly locked up again. This time, however,
the screen went black instead of freezing, but otherwise the same as always.
I then turned on hw.dri.0.debug, and messages quickly filled up with the
following repeated message:

[drm:pid1195:drm_ioctl]     returning 4
[drm:pid1195:drm_ioctl] pid=1195, cmd=0x80046457, nr=0x57, dev 0xc615fa00, auth=1


-- 
David Johnson
From rnoland at FreeBSD.org  Fri May  8 22:31:31 2009
From: rnoland at FreeBSD.org (Robert Noland)
Date: Fri May  8 22:31:38 2009
Subject: Xorg hangs with drmwtq in 7.2-RELEASE
In-Reply-To: <200905081458.53651.david@usermode.org>
References: <200905042015.29394.david@usermode.org>
	<200905072229.17798.david@usermode.org>
	<1241793345.1733.5.camel@balrog.2hip.net>
	<200905081458.53651.david@usermode.org>
Message-ID: <1241821864.1733.51.camel@balrog.2hip.net>

On Fri, 2009-05-08 at 14:58 -0700, David Johnson wrote:
> On Friday 08 May 2009 07:35:45 am Robert Noland wrote:
> > I still can't reproduce this...  I updated the Xserver, libGL and dri
> > ports yesterday, all of which could be related to locking up the GPU and
> > worth a shot.  Failing that, I need you to enabled drm debugging. Start
> > the system without X, kldload radeon.ko, set sysctl hw.dri.0.debug=1
> > then startx.
> 
> I've got all the updated ports as of last night, so that wasn't it.
> 
> I turned AIGLX back on, and it promptly locked up again. This time, however,
> the screen went black instead of freezing, but otherwise the same as always.
> I then turned on hw.dri.0.debug, and messages quickly filled up with the
> following repeated message:
> 
> [drm:pid1195:drm_ioctl]     returning 4
> [drm:pid1195:drm_ioctl] pid=1195, cmd=0x80046457, nr=0x57, dev 0xc615fa00, auth=1
> 

This is too late to really see anything... This still just suggests that
the GPU is locked up.  What is happening below is that we have emitted
an "irq" to the card and we are waiting on it to parse that.  The return
value 4 is EINTR which says that we were interrupted while we were
waiting.  When we return EINTR, libdrm just performs the ioctl over
again.  We first read the register from the card to see if it has parsed
at least up to what we are looking for, if so we just return success and
don't sleep.  If the register says that we haven't parsed the command,
then we sleep for a max of 3 seconds waiting on the card to catch up.
In your case, the card is never catching up, which suggests that the
card is hung and not processing the command stream anymore. 

static int radeon_wait_irq(struct drm_device * dev, int swi_nr)
{
        drm_radeon_private_t *dev_priv =
            (drm_radeon_private_t *) dev->dev_private;
        int ret = 0;
 
        if (RADEON_READ(RADEON_LAST_SWI_REG) >= swi_nr)
                return 0;

        dev_priv->stats.boxes |= RADEON_BOX_WAIT_IDLE;
 
        DRM_WAIT_ON(ret, dev_priv->swi_queue, 3 * DRM_HZ,
                    RADEON_READ(RADEON_LAST_SWI_REG) >= swi_nr);

        if (ret == -ERESTART)
                DRM_DEBUG("restarting syscall");

        return ret;
}

In order to guess what might be causing this, drm debugging needs to be
enabled before the hang, so that we can hopefully figure out what leads
up to the hung GPU.

robert.

-- 
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-stable/attachments/20090508/6e95e550/attachment.pgp
From dwmalone at maths.tcd.ie  Sat May  9 07:38:53 2009
From: dwmalone at maths.tcd.ie (David Malone)
Date: Sat May  9 07:39:00 2009
Subject: "maxproc limit exceeded" making no sense
In-Reply-To: <d3ea75b30905080651p1eaba0dep7073cd62c37f8f3f@mail.gmail.com>
References: <d3ea75b30905080651p1eaba0dep7073cd62c37f8f3f@mail.gmail.com>
Message-ID: <20090509061229.GA63615@walton.maths.tcd.ie>

On Fri, May 08, 2009 at 10:51:02AM -0300, Eduardo Meyer wrote:
> However what I see regarding proc usage is by uid 82 is:
> 
> # ps -U 82 | wc -l
>      723
> 
> Proccess count for UID 82 is never highter than 913 (monitored the
> last whole hour, while log messages were still showing, complaining
> about maxproc limit beeing exceeded).

I guess user 82 is exceeding their per-user process limit. This is set
(traditionally) using the limit or ulimit shell builtins, but can also
be configured in /etc/login.conf or by certain pam modules. I'd start
with login.conf.

	David.
From kamikaze at bsdforen.de  Sat May  9 08:27:39 2009
From: kamikaze at bsdforen.de (Dominic Fandrey)
Date: Sat May  9 08:27:47 2009
Subject: powerd broken
In-Reply-To: <1239384104.1922.70.camel@balrog.2hip.net>
References: <1238293386.00093672.1238281804@10.7.7.3>	<49CF0803.1070505@FreeBSD.org>	<49CF2F8D.6000905@bsdforen.de>	<49CF4EB9.60108@FreeBSD.org>	<49CF49F5.6010800@bsdforen.de>	<49CF615A.6050304@FreeBSD.org>	<49CF595A.30805@bsdforen.de>	<49CF6B28.2080400@FreeBSD.org>	<49CF60AB.4040709@bsdforen.de>	<49CF6899.2060002@bsdforen.de>
	<49CF8E8D.1080604@bsdforen.de>	<49CF9C19.3020509@FreeBSD.org>
	<49D5DA33.4010800@bsdforen.de>	<1238778004.65025.30.camel@balrog.2hip.net>	<49DF5D60.9010803@bsdforen.de>
	<1239384104.1922.70.camel@balrog.2hip.net>
Message-ID: <4A053E52.5030602@bsdforen.de>

Robert Noland wrote:
> On Fri, 2009-04-10 at 16:53 +0200, Dominic Fandrey wrote:
>> Robert Noland wrote:
>>> I've been working on the Intel vblank / irq issues.  Every time I commit
>>> something thinking that I have it resolved, it isn't.  So I'm waiting on
>>> hardware to arrive that will let me test this all more thoroughly.  I do
>>> have a patch that I think fixes most of the issues on Intel, but the ddx
>>> driver is still doing some silly things that cause issues in some cases.
>>> I *think* the only outstanding issue I have with Intel is if something
>>> is rendering (synced to vblank or not) when the display goes into dpms
>>> sleep, there isn't anything to block that app, so it renders as hard as
>>> it can even though it isn't being displayed.  In reality, this probably
>>> isn't a huge issue, but running gears while the display is asleep keeps
>>> the cpu at 100%, which isn't ideal.  Normal apps that aren't trying to
>>> draw as fast as they can, shouldn't cause an issue.
>> With the latest drm, the IRQ craziness is gone. However, the crappy
>> performance remains. 2 months ago a RELENG_7 with all packages
>> up to date yielded 124fps in a q3 timedemo that now yields 80fps.
> 
> Things are still not quite right with the Intel driver.  But performance
> regressions are reported across Linux as well.  A little of this might
> be us, but most of it is Intel...
> 

I don't know what you did with the last update, but performance is now
better than ever (2% above what it used to be), which equels 3-4 more
frames in ioQuake3 or 200  more in glxgears.

The uptime of the notebook is now 15 hours and the interrupt load
insignificant. I get no more than 8000 interrupts per seconds.
4000 of these are CPU timers (2000 for each core) and 1000 more are
from my mouse, when I move it very fast. Around 2500 from vgapci, when
I run glxgears and the rest is just scraps of whatever else is running
(e.g. sound).

Thanks a lot.

Regards
From rnoland at FreeBSD.org  Sat May  9 12:07:17 2009
From: rnoland at FreeBSD.org (Robert Noland)
Date: Sat May  9 12:07:24 2009
Subject: powerd broken
In-Reply-To: <4A053E52.5030602@bsdforen.de>
References: <1238293386.00093672.1238281804@10.7.7.3>
	<49CF0803.1070505@FreeBSD.org>	<49CF2F8D.6000905@bsdforen.de>
	<49CF4EB9.60108@FreeBSD.org>	<49CF49F5.6010800@bsdforen.de>
	<49CF615A.6050304@FreeBSD.org>	<49CF595A.30805@bsdforen.de>
	<49CF6B28.2080400@FreeBSD.org>	<49CF60AB.4040709@bsdforen.de>
	<49CF6899.2060002@bsdforen.de> <49CF8E8D.1080604@bsdforen.de>
	<49CF9C19.3020509@FreeBSD.org>  <49D5DA33.4010800@bsdforen.de>
	<1238778004.65025.30.camel@balrog.2hip.net>	<49DF5D60.9010803@bsdforen.de>
	<1239384104.1922.70.camel@balrog.2hip.net>
	<4A053E52.5030602@bsdforen.de>
Message-ID: <1241870806.1733.61.camel@balrog.2hip.net>

On Sat, 2009-05-09 at 10:26 +0200, Dominic Fandrey wrote:
> Robert Noland wrote:
> > On Fri, 2009-04-10 at 16:53 +0200, Dominic Fandrey wrote:
> >> Robert Noland wrote:
> >>> I've been working on the Intel vblank / irq issues.  Every time I commit
> >>> something thinking that I have it resolved, it isn't.  So I'm waiting on
> >>> hardware to arrive that will let me test this all more thoroughly.  I do
> >>> have a patch that I think fixes most of the issues on Intel, but the ddx
> >>> driver is still doing some silly things that cause issues in some cases.
> >>> I *think* the only outstanding issue I have with Intel is if something
> >>> is rendering (synced to vblank or not) when the display goes into dpms
> >>> sleep, there isn't anything to block that app, so it renders as hard as
> >>> it can even though it isn't being displayed.  In reality, this probably
> >>> isn't a huge issue, but running gears while the display is asleep keeps
> >>> the cpu at 100%, which isn't ideal.  Normal apps that aren't trying to
> >>> draw as fast as they can, shouldn't cause an issue.
> >> With the latest drm, the IRQ craziness is gone. However, the crappy
> >> performance remains. 2 months ago a RELENG_7 with all packages
> >> up to date yielded 124fps in a q3 timedemo that now yields 80fps.
> > 
> > Things are still not quite right with the Intel driver.  But performance
> > regressions are reported across Linux as well.  A little of this might
> > be us, but most of it is Intel...
> > 
> 
> I don't know what you did with the last update, but performance is now
> better than ever (2% above what it used to be), which equels 3-4 more
> frames in ioQuake3 or 200  more in glxgears.
> 
> The uptime of the notebook is now 15 hours and the interrupt load
> insignificant. I get no more than 8000 interrupts per seconds.
> 4000 of these are CPU timers (2000 for each core) and 1000 more are
> from my mouse, when I move it very fast. Around 2500 from vgapci, when
> I run glxgears and the rest is just scraps of whatever else is running
> (e.g. sound).

Which update, what?  I haven't touched the kernel tree in a while, just
trying to sort it all out with patches here and there.  Are you saying
the the 2.7.0 intel driver helped?  Or maybe the Xserver or mesa
updates?

robert.

> Thanks a lot.
> 
> Regards
-- 
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-stable/attachments/20090509/0861269d/attachment.pgp
From kamikaze at bsdforen.de  Sat May  9 13:10:36 2009
From: kamikaze at bsdforen.de (Dominic Fandrey)
Date: Sat May  9 13:10:43 2009
Subject: powerd broken
In-Reply-To: <1241870806.1733.61.camel@balrog.2hip.net>
References: <1238293386.00093672.1238281804@10.7.7.3>	<49CF0803.1070505@FreeBSD.org>	<49CF2F8D.6000905@bsdforen.de>	<49CF4EB9.60108@FreeBSD.org>	<49CF49F5.6010800@bsdforen.de>	<49CF615A.6050304@FreeBSD.org>	<49CF595A.30805@bsdforen.de>	<49CF6B28.2080400@FreeBSD.org>	<49CF60AB.4040709@bsdforen.de>	<49CF6899.2060002@bsdforen.de>
	<49CF8E8D.1080604@bsdforen.de>	<49CF9C19.3020509@FreeBSD.org>
	<49D5DA33.4010800@bsdforen.de>	<1238778004.65025.30.camel@balrog.2hip.net>	<49DF5D60.9010803@bsdforen.de>	<1239384104.1922.70.camel@balrog.2hip.net>	<4A053E52.5030602@bsdforen.de>
	<1241870806.1733.61.camel@balrog.2hip.net>
Message-ID: <4A0580C9.6050902@bsdforen.de>

Robert Noland wrote:
> On Sat, 2009-05-09 at 10:26 +0200, Dominic Fandrey wrote:
>> Robert Noland wrote:
>>> On Fri, 2009-04-10 at 16:53 +0200, Dominic Fandrey wrote:
>>>> Robert Noland wrote:
>>>>> I've been working on the Intel vblank / irq issues.  Every time I commit
>>>>> something thinking that I have it resolved, it isn't.  So I'm waiting on
>>>>> hardware to arrive that will let me test this all more thoroughly.  I do
>>>>> have a patch that I think fixes most of the issues on Intel, but the ddx
>>>>> driver is still doing some silly things that cause issues in some cases.
>>>>> I *think* the only outstanding issue I have with Intel is if something
>>>>> is rendering (synced to vblank or not) when the display goes into dpms
>>>>> sleep, there isn't anything to block that app, so it renders as hard as
>>>>> it can even though it isn't being displayed.  In reality, this probably
>>>>> isn't a huge issue, but running gears while the display is asleep keeps
>>>>> the cpu at 100%, which isn't ideal.  Normal apps that aren't trying to
>>>>> draw as fast as they can, shouldn't cause an issue.
>>>> With the latest drm, the IRQ craziness is gone. However, the crappy
>>>> performance remains. 2 months ago a RELENG_7 with all packages
>>>> up to date yielded 124fps in a q3 timedemo that now yields 80fps.
>>> Things are still not quite right with the Intel driver.  But performance
>>> regressions are reported across Linux as well.  A little of this might
>>> be us, but most of it is Intel...
>>>
>> I don't know what you did with the last update, but performance is now
>> better than ever (2% above what it used to be), which equels 3-4 more
>> frames in ioQuake3 or 200  more in glxgears.
>>
>> The uptime of the notebook is now 15 hours and the interrupt load
>> insignificant. I get no more than 8000 interrupts per seconds.
>> 4000 of these are CPU timers (2000 for each core) and 1000 more are
>> from my mouse, when I move it very fast. Around 2500 from vgapci, when
>> I run glxgears and the rest is just scraps of whatever else is running
>> (e.g. sound).
> 
> Which update, what?  I haven't touched the kernel tree in a while, just
> trying to sort it all out with patches here and there.  Are you saying
> the the 2.7.0 intel driver helped?  Or maybe the Xserver or mesa
> updates?

I update my ports daily, without really looking at what. I think
xorg-server was one of them. It must have been something that happened
during the last 48 hours.

> robert.
> 
>> Thanks a lot.
>>
>> Regards

From rnoland at FreeBSD.org  Sat May  9 13:14:07 2009
From: rnoland at FreeBSD.org (Robert Noland)
Date: Sat May  9 13:14:13 2009
Subject: powerd broken
In-Reply-To: <4A0580C9.6050902@bsdforen.de>
References: <1238293386.00093672.1238281804@10.7.7.3>
	<49CF0803.1070505@FreeBSD.org>	<49CF2F8D.6000905@bsdforen.de>
	<49CF4EB9.60108@FreeBSD.org>	<49CF49F5.6010800@bsdforen.de>
	<49CF615A.6050304@FreeBSD.org>	<49CF595A.30805@bsdforen.de>
	<49CF6B28.2080400@FreeBSD.org>	<49CF60AB.4040709@bsdforen.de>
	<49CF6899.2060002@bsdforen.de> <49CF8E8D.1080604@bsdforen.de>
	<49CF9C19.3020509@FreeBSD.org>  <49D5DA33.4010800@bsdforen.de>
	<1238778004.65025.30.camel@balrog.2hip.net>	<49DF5D60.9010803@bsdforen.de>
	<1239384104.1922.70.camel@balrog.2hip.net>	<4A053E52.5030602@bsdforen.de>
	<1241870806.1733.61.camel@balrog.2hip.net>
	<4A0580C9.6050902@bsdforen.de>
Message-ID: <1241874817.71435.1.camel@balrog.2hip.net>

On Sat, 2009-05-09 at 15:10 +0200, Dominic Fandrey wrote:
> Robert Noland wrote:
> > On Sat, 2009-05-09 at 10:26 +0200, Dominic Fandrey wrote:
> >> Robert Noland wrote:
> >>> On Fri, 2009-04-10 at 16:53 +0200, Dominic Fandrey wrote:
> >>>> Robert Noland wrote:
> >>>>> I've been working on the Intel vblank / irq issues.  Every time I commit
> >>>>> something thinking that I have it resolved, it isn't.  So I'm waiting on
> >>>>> hardware to arrive that will let me test this all more thoroughly.  I do
> >>>>> have a patch that I think fixes most of the issues on Intel, but the ddx
> >>>>> driver is still doing some silly things that cause issues in some cases.
> >>>>> I *think* the only outstanding issue I have with Intel is if something
> >>>>> is rendering (synced to vblank or not) when the display goes into dpms
> >>>>> sleep, there isn't anything to block that app, so it renders as hard as
> >>>>> it can even though it isn't being displayed.  In reality, this probably
> >>>>> isn't a huge issue, but running gears while the display is asleep keeps
> >>>>> the cpu at 100%, which isn't ideal.  Normal apps that aren't trying to
> >>>>> draw as fast as they can, shouldn't cause an issue.
> >>>> With the latest drm, the IRQ craziness is gone. However, the crappy
> >>>> performance remains. 2 months ago a RELENG_7 with all packages
> >>>> up to date yielded 124fps in a q3 timedemo that now yields 80fps.
> >>> Things are still not quite right with the Intel driver.  But performance
> >>> regressions are reported across Linux as well.  A little of this might
> >>> be us, but most of it is Intel...
> >>>
> >> I don't know what you did with the last update, but performance is now
> >> better than ever (2% above what it used to be), which equels 3-4 more
> >> frames in ioQuake3 or 200  more in glxgears.
> >>
> >> The uptime of the notebook is now 15 hours and the interrupt load
> >> insignificant. I get no more than 8000 interrupts per seconds.
> >> 4000 of these are CPU timers (2000 for each core) and 1000 more are
> >> from my mouse, when I move it very fast. Around 2500 from vgapci, when
> >> I run glxgears and the rest is just scraps of whatever else is running
> >> (e.g. sound).
> > 
> > Which update, what?  I haven't touched the kernel tree in a while, just
> > trying to sort it all out with patches here and there.  Are you saying
> > the the 2.7.0 intel driver helped?  Or maybe the Xserver or mesa
> > updates?
> 
> I update my ports daily, without really looking at what. I think
> xorg-server was one of them. It must have been something that happened
> during the last 48 hours.

Ok, well server, mesa and intel driver all got updates in my sweep the
other day.

robert.

> > robert.
> > 
> >> Thanks a lot.
> >>
> >> Regards
> 
-- 
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-stable/attachments/20090509/14a220ed/attachment.pgp
From brd at FreeBSD.org  Sat May  9 19:40:34 2009
From: brd at FreeBSD.org (Brad Davis)
Date: Sat May  9 19:40:43 2009
Subject: FreeBSD Status Reports January - March, 2009
Message-ID: <20090509191253.GD40521@valentine.liquidneon.com>


FreeBSD Quarterly Status Report

Introduction

   Since the last Status Reports there has been interesting progress in
   FreeBSD Development. FreeBSD 7.2 was released just a few days ago. Some
   of the highlights include: Support for superpages in the FreeBSD
   Virtual Memory subsystem. The FreeBSD Kernel Virtual Address space has
   been increased to 6GB on amd64. An updated jail(8) subsystem that
   supports multi-IPv4/IPv6/noIP and much more. Lots of FreeBSD Developers
   are in Ottawa, Canada attending the FreeBSD Developer Summit that is
   before BSDCan. BSDCan officially starts tomorrow and should cover lots
   of interesting topics, see the BSDCan Website for more information.

   Thanks to all the reporters for the excellent work! We hope you enjoy
   reading.
     __________________________________________________________________

Projects

     * Clang replacing GCC in the base system
     * Device mmap() Extensions
     * OpenBSM
     * Release Engineering
     * Sysinfo - a set of scripts which document your system
     * TrustedBSD MAC Framework in GENERIC
     * VFS/NFS DTrace Probes
     * VirtualBox on FreeBSD

FreeBSD Team Reports

     * FreeBSD BugBusting Team

Architectures

     * FreeBSD/powerpc G5 Support
     * FreeBSD/sparc64 UltraSPARC III support

Documentation

     * Dutch Documentation Project
     * German Documentation Project
     * Hungarian Documentation Project

Google Summer of Code

     * BSD-licensed text-processing tools
     __________________________________________________________________

BSD-licensed text-processing tools

   URL:
   http://perforce.freebsd.org/depotTreeBrowser.cgi?FSPC=//depot/projects/
   soc2008/gabor_textproc

   Contact: G?bor K?vesd?n <gabor@FreeBSD.org>

   Currently, grep is finished and is only waiting for a portbuild test.
   It is known to be more or less feature complete, while it is much
   smaller than the GNU version.

   As for sort, there has been some progress with the complete rewrite and
   it is lacking few options. Performance is to be measured, as well.

Open tasks:

    1. Test grep on pointyhat.
    2. Complete sort with the missing features.
    3. Do performance measurements for sort and look for possible
       optimization opportunities.
    4. Test sort on pointyhat.
     __________________________________________________________________

Clang replacing GCC in the base system

   URL: http://wiki.freebsd.org/BuildingFreeBSDWithClang
   URL: http://git.hoeg.nl/?p=llvm-bmake
   URL: http://clang.llvm.org/

   Contact: Ed Schouten <ed@FreeBSD.org>
   Contact: Roman Divacky <rdivacky@FreeBSD.org>
   Contact: Brooks Davis <brooks@FreeBSD.org>
   Contact: Pawel Worach <pawel.worach@gmail.com>

   The last 3-4 months we've been working together with the LLVM
   developers to discuss any bugs and issues we are experiencing with
   their Clang compiler frontend. The FreeBSD project is looking at the
   possibility to replace GCC with Clang as a system compiler. It can
   compile 99% of the FreeBSD world and can compile booting kernel on
   i386/amd64 but it still contains bugs and its C++ support is still
   immature.

   Ed is maintaining a patchset for the FreeBSD sources to replace cc(1)
   by a Clang binary and bootstrap almost all sources with the Clang
   compiler.

   The LLVM developers are very helpful fixing most of the bugs we've
   reported (over 100). Unfortunately we are currently blocked on some bug
   reports that prevent us from building libc, libm, libcrypto and various
   CDDL libraries with Clang but the FreeBSD kernel itself compiles and
   boots.

Open tasks:

    1. Testing Clang with compilation of various applications and
       reporting bugs.
    2. Testing the llvm-bmake branch to find more bugs.
    3. Arranging an experimental ports build.
     __________________________________________________________________

Device mmap() Extensions

   URL: http://www.FreeBSD.org/~jhb/pat/

   Contact: John Baldwin <jhb@FreeBSD.org>

   GPU device drivers are increasingly requiring more sophisticated
   support for mapping objects into both userland and the kernel. For
   example, memory used for textures often needs to be mapped
   Write-Combining rather than Write-Back. I have recently created three
   patches to provide several extensions.

   The first patch allows device drivers to use a different VM object to
   back specific mmap() calls instead of always using the device pager.
   The second patch introduces a new VM object type that can map an
   arbitrary set of physical address ranges. This can be used to let
   userland mmap PCI BARs, etc. The third patch allows memory mappings to
   use different caching modes (e.g. Write-Combining or Uncacheable).

   Together I believe these patches provide the remaining pieces needed
   for an Nvidia amd64 driver. They will also be useful for future Xorg
   DRM support as well. The current set of patches can be safely merged
   back to 7.x as well.

   Currently I am waiting for review and feedback from several folks. I am
   hopeful that these patches will be in HEAD soon, prior to the 8.0
   freeze.
     __________________________________________________________________

Dutch Documentation Project

   URL: http://wiki.freebsd.org/DutchDocumentationProject
   URL: http://www.freebsd.org/doc/nl/
   URL:
   http://p4web.freebsd.org/@md=d&cd=//&c=pFl@//depot/projects/docproj_nl/
   ?ac=83

   Contact: Remko Lodder <remko@FreeBSD.org>
   Contact: Ren? Ladan <rene@FreeBSD.org>

   The FreeBSD Dutch Documentation Project is an ongoing project to
   translate FreeBSD Documentation into the Dutch language.

   The translation of the Handbook was completed last January. It is kept
   up-to-date with the English version. Furthermore five articles and the
   flyer have been translated.

   Some initial work has been done to translate the website, but most
   likely more translators are needed to fully realize it.

Open tasks:

    1. Recruit more translators.
    2. Keep the translations up-to-date with the English versions.
    3. Finish the translation of the FAQ.
    4. Translate more articles and maybe some books.
     __________________________________________________________________

FreeBSD BugBusting Team

   URL: http://www.FreeBSD.org/support.html#gnats
   URL: http://wiki.FreeBSD.org/BugBusting
   URL: http://people.FreeBSD.org/~linimon/studies/prs/
   URL:
   http://people.freebsd.org/~linimon/studies/prs/recommended_prs.html

   Contact: Mark Linimon <bugmeister@>
   Contact: Remko Lodder <bugmeister@>

   We continue to classify PRs as they arrive, with 'tags' corresponding
   to the kernel subsystem, or man page references for userland PRs. These
   tags, in turn, produce lists of PRs sorted both by tag and by manpage

   Mark Linimon (linimon@) has created special reports for the Release
   Engineering Team to help focus on regressions and other areas of
   interest relating to the release of FreeBSD 7.2 in the coming weeks.
   This is a refinement of the 'customized reports for developers'
   announced in the last status report.

   A full list of all the automatically generated reports is also
   available. Any recommendations for reports which do not currently exist
   but which would be beneficial are welcomed.

   Mark Linimon also continues attempting to define the general problem
   and investigating possible new work flow models, and will be presenting
   on the subject at BSDCan.

   The list of PRs recommended for committer evaluation by the BugBusting
   team continues to receive new additions. This list contains PRs, mostly
   with patches, that the BugBusting team feel are probably ready to be
   committed as-is, or are probably trivially resolved in the hands of a
   committer with knowledge of the particular subsystem. All committers
   are invited to take a look at this list whenever they have a spare 5
   minutes and wish to close a PR.

   Since the last status report, the number of open bugs continued to
   hover around the 5600 mark, although has began to rise with the 7.2
   ports freeze.

   As always, more help is appreciated, and committers and non-committers
   alike are invited to join us on #freebsd-bugbusters on EFnet and help
   close stale PRs or commit patches from valid PRs.

Open tasks:

    1. Try to find ways to get more committers helping us with closing PRs
       that the team has already analyzed.
    2. Think of some way for committers to only view PRs that have been in
       some way 'vetted' or 'confirmed'.
    3. Generate more publicity for what we've already got in place, and
       for what we intend to do next.
    4. Define new categories, classifications, and states for PRs, that
       will better match our work flow (in progress).
     __________________________________________________________________

FreeBSD/powerpc G5 Support

   Contact: Nathan Whitehorn <nwhitehorn@freebsd.org>

   FreeBSD 8.0-CURRENT now has support for PowerPC CPUs operating in the
   64-bit bridge mode. This includes the PowerPC 970 (G5) as well as the
   POWER3 and POWER4. Currently only Apple systems are known to work.

Open tasks:

    1. IBM systems currently are not supported due to missing northbridge
       support.
    2. Software fan control on SMU-based Apple G5 systems (G5 iMac, later
       Powermac G5) is not available.
     __________________________________________________________________

FreeBSD/sparc64 UltraSPARC III support

   Contact: Marius Strobl <marius@FreeBSD.org>

   Like announced in the previous status report, support for
   sun4u-machines based on UltraSPARC III and beyond has been MFC'ed to
   stable/7 (the last missing piece was r190297) and thus will be present
   in the upcoming 7.2-RELEASE and can be already tested with 7.2-RC1.
   Additionally, as of r191076 machfb(4) has been fixed to work with
   UltraSPARC III and beyond, that fix unfortunately did not make it into
   7.2-RC1 but will be in the final version. The X.Org 7.4 and Firefox
   ports as well as some other gecko-based ones like Seamonkey once again
   have been fixed to also work and package on sparc64, including on
   UltraSPARC III and UltraSPARC IIIi based machines equipped with cards
   driven by creator(4) or machfb(4). The driver for the Sun
   Cassini/Cassini+ as well as National Semiconductor DP83065 Saturn
   Gigabit NICs found on-board for example in Fire V440 and as add-on
   cards is coming along nicely, the last thing which needs to be
   implemented before it can hit CURRENT is support for jumbo frames.
     __________________________________________________________________

German Documentation Project

   URL: https://doc.bsdgroup.de

   Contact: Johann Kois <jkois@FreeBSD.org>
   Contact: Martin Wilke <miwi@FreeBSD.org>

   In February 2009 the German version of the FreeBSD Developer's handbook
   went online. Additionally we managed to update large areas of the FAQ
   thanks to the contributions of Benedict Reuschling.

   The website (at least the areas we see as relevant for a translation)
   is translated and updated constantly.

   More volunteers are always welcome of course, as there is still plenty
   of work to be done.

Open tasks:

    1. Update the existing documentation set (especially the handbook).
    2. Read the translations. Check for problems/mistakes. Send feedback.
     __________________________________________________________________

Hungarian Documentation Project

   URL: http://www.FreeBSD.org/hu
   URL: http://www.FreeBSD.org/doc/hu
   URL: http://wiki.FreeBSD.org/HungarianDocumentationProject
   URL:
   http://p4web.freebsd.org/@md=d&cd=//depot/projects/docproj_hu/&c=aXw@//
   depot/projects/docproj_hu/?ac=83

   Contact: G?bor K?vesd?n <gabor@FreeBSD.org>
   Contact: G?bor P?li <pgj@FreeBSD.org>

   We are proud to announce that the FreeBSD Hungarian web pages have been
   extended by the following items:
     * Project news entries, staring from 2009 (HTML, RSS, RDF)
     * Press releases, starting from 2008 (HTML, RSS)
     * Events, starting from 2009 (HTML, RSS)
     * Security advisories (HTML, RSS)

   We are still hoping that having the FDP Primer translated will
   encourage others to help our work. Feel free to contribute, every
   submitted line of translation or feedback is appreciated and is highly
   welcome. For more information on how to contribute, please read the
   project's introduction (in Hungarian).

Open tasks:

    1. Translate news entries, press releases.
    2. Translate Release Notes for -CURRENT and 8.X.
    3. Translate articles.
    4. Translate web pages.
    5. Read the translations, send feedback.
     __________________________________________________________________

OpenBSM

   URL: http://www.openbsm.org/

   Contact: Robert Watson <rwatson@FreeBSD.org>
   Contact: TrustedBSD audit mailing list
   <trustedbsd-audit@TrustedBSD.org>

   The TrustedBSD Project has now released OpenBSM 1.1, the second
   production release of the OpenBSM code base. OpenBSM 1.1 has been
   merged to FreeBSD 8-CURRENT, and will be merged to 7-STABLE before
   FreeBSD 7.3. Major changes since OpenBSM 1.0 include:
     * Trail files now include the host where the trail is generated.
       Crash recovery has been improved. Trail expiration based on size
       and date is now supported; by default trail files will be expired
       after 10MB of trails. The default individual trail limit is now
       2MB.
     * Mac OS X Snow Leopard is now a fully supported platform; launchd(8)
       can now be used to launchd auditd(8). Command line tools and
       libraries are now supported on Mac OS X Leopard.
     * Extended header tokens are now supported, allowing audit trails to
       be tagged with a host identifier. IPv6 addresses are now supported
       in subject tokens. BSM token and record types have been further
       synchronized to OpenSolaris; support for many new system calls has
       been added. Local errors and socket types are mapped to and from
       BSM values.

   Since the last test release, OpenBSM 1.1 beta 1, 32/64-bit
   compatibility has been fixed for the auditon(2) system call. A default
   "expire-after" of 10MB is now set in audit_control(5). Local fcntl(2)
   arguments are now mapped to wire BSM versions using new APIs. The
   audit_submit(3) man page has been fixed. A new audit event class has
   been added for post-login authentication and access control events.

Open tasks:

    1. Migrate to sbufs in token-encoding.
    2. Support for auditing NFS RPCs.
     __________________________________________________________________

Release Engineering

   URL: http://www.FreeBSD.org/releng/

   Contact: Release Engineering Team <re@FreeBSD.org>

   The Release Engineering Team (with lots of help from lots of other
   people) released FreeBSD 7.2 on May 4th, 2009. During this period we
   have also begun reminding developers of the upcoming FreeBSD 8.0
   release cycle which is scheduled to begin in early June 2009 with
   release targeted at early September 2009.
     __________________________________________________________________

Sysinfo - a set of scripts which document your system

   URL:
   http://danger.rulez.sk/index.php/2009/04/14/sysinfo-a-set-of-scripts-wh
   ich-document-your-freebsd-system/
   URL: https://forums.freebsd.org/showthread.php?p=19321

   Contact: Daniel Gerzo <danger@FreeBSD.org>

   Sysinfo a shell script which purpose is to automatically gather system
   information and document hardware and software configuration of the
   given host system. The goal is to provide a system operator with
   descriptive information about an unknown FreeBSD installation.

   It consists of several modules (also shell scripts), thus is easily
   extensible and provides an easy way to inspect overall system
   configuration.

   It has been written as part of my Bachelor thesis and its development
   is a work in progress. Therefore, I would appreciate if you could
   provide me with some feedback as I will defend my thesis soon. Your
   feedback is welcome at the forums , or alternatively you can send me a
   private email.

   The tool itself can now be installed using the Ports tree from the
   sysutils/sysinfo port.

Open tasks:

    1. Receive additional feedback.
    2. Perform more testing.
    3. Extend and improve the tool.
     __________________________________________________________________

TrustedBSD MAC Framework in GENERIC

   URL: http://www.trustedBSD.org/mac.html

   Contact: Robert Watson <rwatson@FreeBSD.org>
   Contact: TrustedBSD discussion mailing list
   <trustedbsd-discuss@TrustedBSD.org>

   There is on-going work to allow "options MAC" to be included in the
   GENERIC kernel for 8.0. This primarily consists of performance work to
   reduce overhead when policies are used, and eliminate when none are
   configured. Work to date includes:
     * The MAC Framework now detects which object types are labeled by
       policies, and MAC label storage is not allocated when it won't be
       used.
     * Add MAC Framework DTrace probes so allow more easy analysis of MAC
       Framework and policy interactions.
     * Eliminate mutex-protected reference count used to prevent module
       unload during entry point invocation, and replace with an sx lock
       and an rwlock, respectively for long-sleepable and short-sleepable
       entry points, significantly lowering the overhead of entering the
       MAC Framework. If no dynamic policies are loaded, no locking
       overhead is taken.

Open tasks:

    1. Move to rmlocks for non-sleepable entry points to reduce cache line
       thrashing under load.
    2. Macroize invocation of MAC Framework entry points from the kernel,
       and perform caller-side determination of whether MAC is enabled in
       order to avoid additional function call overhead in the caller path
       if MAC is disabled.
     __________________________________________________________________

VFS/NFS DTrace Probes

   Contact: Robert Watson <rwatson@FreeBSD.org>

   A new DTrace provider, dtnfsclient, has been added to the FreeBSD 8.x
   kernel, and will be merged to 7.x before 7.3. The following probes are
   available:
     * nfsclient:{nfs2,nfs3}:{procname}:start - NFSv2 and NFSv3 RPC start
       probes
     * nfsclient:{nfs2,nfs3}:{procname}:done - NFSv2 and NFSv3 RPC done
       probes
     * nfsclient:accesscache:: - NFS access cache flush/hit/miss/load
       probes
     * nfsclient:attrcache:: - NFS attribute cache flush/hit/miss/done

   In addition, a number of VFS probes have been added:
     * vfs:vop:{vopname}:entry - VOP entry probe
     * vfs:vop:{vopname}:return - VOP return probe
     * vfs:namei:lookup:entry - VFS name lookup entry probe
     * vfs:namei:lookup:return - VFS name lookup return probe
     * vfs:namecache:*:* - VFS namecache
       enter/enter_negative/fullpath_enter/fullpath_hit/fullpath_miss/full
       path_return/lookup_hit/lookup_hit_negative/lookup_miss/purge/purge_
       negative/purgevfs/zap/zap_negative probes

   These probes make it much easier to trace NFS and VFS events.

Open tasks:

    1. Add VFSOP tracing.
    2. Add RPC-layer tracing, such as RPC retransmits.
    3. Provide decoded NFS RPCs in order to expose transaction IDs and
       file handles.
     __________________________________________________________________

VirtualBox on FreeBSD

   URL: http://miwi.bsdcrew.de/2009/05/virtualbox-on-freebsd/
   URL:
   http://miwi.bsdcrew.de/2009/05/virtualbox-on-freebsd-first-screenshots/
   URL: http://vbox.innotek.de/pipermail/vbox-dev/2009-May/001369.html

   Contact: Beat Gaetzi <beat@FreeBSD.org>
   Contact: Bernhard Froehlich <decke@bluelife.at>
   Contact: Dennis Herrmann <dhn@FreeBSD.org>
   Contact: Martin Wilke <miwi@FreeBSD.org>

   After the first mail from Alexander Eichner on the vbox-dev
   mailinglist, we started the work on a VirtualBox port. 6 Days was
   needed to get VirtualBox to start with over 20 patches. We'd like to
   say thanks to Alexander Eichner, all the VirtualBox Developers, Gustau
   Perez and Ulf Lilleengen. If you like to play with the current port you
   can checkout the port here. Please do not ping us about any problems,
   we know about a lot and are still working to get them all solved before
   we do an official call for testing.

Open tasks:

    1. Fix kernel crashes on 7.2-RELEASE.
    2. Code cleanup.
    3. Fix errors on AMD64.
    4. Fix user/permission problems.

From scrappy at hub.org  Sat May  9 22:43:18 2009
From: scrappy at hub.org (Marc G. Fournier)
Date: Sat May  9 22:43:26 2009
Subject: 7.1-STABLE Sun Mar 29 01:06:46 ADT 2009 Locks up ...
In-Reply-To: <1240920035.85945.7.camel@buffy.york.ac.uk>
References: <A98FF8D3-1486-43D4-8EE6-50F8C3DACCA1@uos.de>
	<1240920035.85945.7.camel@buffy.york.ac.uk>
Message-ID: <20090509193937.T10574@hub.org>

On Tue, 28 Apr 2009, Gavin Atkinson wrote:

> On Fri, 2009-04-24 at 20:39 +0200, Martin Schmidt wrote:
>> Hi Marc and List,
>>
>> i had similar issues with FreeBSD 7.2-PRERELEASE. Server (zfs,nfs)
>> seems to hang in intervals of about 8 hours.
>> kernel is still there but no connections can be made to nfs/ssh and
>> login on local console doesn't seem to
>> work due to incredible slowness. breaking to the debugger takes a
>> moment but works.
>> (compiling kernel with WITNESS didnt help)
>>
>> the server had been solid before with 7 stable kernel from around 19
>> October 2008.
>>
>> I now added these lines to /boot/loader.conf
>>
>> hw.pci.enable_msi=0
>> hw.pci.enable_msix=0
>>
>> to disable Message Signaled Interrupts. Which are used by the 3ware
>> twa driver and igb network driver on our server.
>
> If you are willing to test further on your server, it may be helpful if
> you could determine which of those two lines in loader.conf fixes the
> problem for you.  It would also be useful to provide a dmesg from the
> machine when both msi and msix are enabled.
>
> FWIW, looking at the "vmstat -i" output it appears that only the igb
> driver that are using MSI/MSIX, unless you have a reason to suspect
> otherwise?

How do you tell that, about igb?  looking at the server I have the igb 
device on, it doesn't seem to say anything about that ...

# vmstat -i
interrupt                          total       rate
irq1: atkbd0                         162          0
irq30: twa0                    402647215        187
cpu0: timer                   4284778818       1999
irq256: igb0                  1282945461        598
irq257: igb0                   215507100        100
irq258: igb0                   417702261        194
irq259: igb0                   314601966        146
irq260: igb0                   568062067        265
irq261: igb0                           3          0
cpu5: timer                   4284744445       1999
cpu6: timer                   4284731466       1999
cpu7: timer                   4284724508       1999
cpu1: timer                   4284893874       1999
cpu3: timer                   4284899807       1999
cpu2: timer                   4284892325       1999
cpu4: timer                   4284897264       1999
Total                        37480028742      17493


The server(s) that I am experiencing the hangs on, vmstat -i shows:

# vmstat -i
interrupt                          total       rate
irq1: atkbd0                           2          0
irq3: sio1                             8          0
irq25: bge0                      4614816        213
irq72: ciss0                     1835763         85
cpu0: timer                     43113685       1997
cpu1: timer                     43116889       1997
Total                           92681163       4293

Are any of these similiarly using MSI/MSIX?

----
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 scrappy at hub.org  Sat May  9 23:17:14 2009
From: scrappy at hub.org (Marc G. Fournier)
Date: Sat May  9 23:17:22 2009
Subject: 7.1-STABLE Sun Mar 29 01:06:46 ADT 2009 Locks up ...
In-Reply-To: <1240920035.85945.7.camel@buffy.york.ac.uk>
References: <A98FF8D3-1486-43D4-8EE6-50F8C3DACCA1@uos.de>
	<1240920035.85945.7.camel@buffy.york.ac.uk>
Message-ID: <20090509201505.R10574@hub.org>



'k, based on grep'ng the source files, turns out that the if_bge device 
driver uses msi, while, as you point out, the igb uses msix ... I have 
disabled msi on the two servers with bge devices, and msix on the one with 
igb ... all three have given the same sort of problem after varying 
periods of time ... let's see if I can get to 30 days uptime with this ...

On Tue, 28 Apr 2009, Gavin Atkinson wrote:

> On Fri, 2009-04-24 at 20:39 +0200, Martin Schmidt wrote:
>> Hi Marc and List,
>>
>> i had similar issues with FreeBSD 7.2-PRERELEASE. Server (zfs,nfs)
>> seems to hang in intervals of about 8 hours.
>> kernel is still there but no connections can be made to nfs/ssh and
>> login on local console doesn't seem to
>> work due to incredible slowness. breaking to the debugger takes a
>> moment but works.
>> (compiling kernel with WITNESS didnt help)
>>
>> the server had been solid before with 7 stable kernel from around 19
>> October 2008.
>>
>> I now added these lines to /boot/loader.conf
>>
>> hw.pci.enable_msi=0
>> hw.pci.enable_msix=0
>>
>> to disable Message Signaled Interrupts. Which are used by the 3ware
>> twa driver and igb network driver on our server.
>
> If you are willing to test further on your server, it may be helpful if
> you could determine which of those two lines in loader.conf fixes the
> problem for you.  It would also be useful to provide a dmesg from the
> machine when both msi and msix are enabled.
>
> FWIW, looking at the "vmstat -i" output it appears that only the igb
> driver that are using MSI/MSIX, unless you have a reason to suspect
> otherwise?
>
> Gavin
> _______________________________________________
> freebsd-stable@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org"
>

----
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 david at usermode.org  Sun May 10 00:27:37 2009
From: david at usermode.org (David Johnson)
Date: Sun May 10 00:27:44 2009
Subject: Xorg hangs with drmwtq in 7.2-RELEASE
In-Reply-To: <1241821864.1733.51.camel@balrog.2hip.net>
References: <200905042015.29394.david@usermode.org>
	<200905081458.53651.david@usermode.org>
	<1241821864.1733.51.camel@balrog.2hip.net>
Message-ID: <200905091727.12165.david@usermode.org>

On Friday 08 May 2009 03:31:04 pm Robert Noland wrote:
> In order to guess what might be causing this, drm debugging needs to be
> enabled before the hang, so that we can hopefully figure out what leads
> up to the hung GPU.

Unfortunately that won't work, because turning on hw.dri.0.debug slows down 
compositing so much that it won't reproduce.

-- 
David Johnson
From david at usermode.org  Sun May 10 01:41:37 2009
From: david at usermode.org (David Johnson)
Date: Sun May 10 01:41:44 2009
Subject: Xorg hangs with drmwtq in 7.2-RELEASE
In-Reply-To: <1241821864.1733.51.camel@balrog.2hip.net>
References: <200905042015.29394.david@usermode.org>
	<200905081458.53651.david@usermode.org>
	<1241821864.1733.51.camel@balrog.2hip.net>
Message-ID: <200905091841.26274.david@usermode.org>

On Friday 08 May 2009 03:31:04 pm Robert Noland wrote:
> In order to guess what might be causing this, drm debugging needs to be
> enabled before the hang, so that we can hopefully figure out what leads
> up to the hung GPU.

I'm not able to do that, but I did manage to get debug turned on and dmesg
captured early enough to catch some additional information. I've place the
full file online at http://www.usermode.org/misc/dmesg.txt, but am including
some snippets here. Hopefully this is enough to move forward.

-- 
David Johnson

...
[drm:pid1822:drm_ioctl] pid=1822, cmd=0xc0286429, nr=0x29, dev 0xc615fa00, auth=1
[drm:pid1822:radeon_freelist_get] done_age = 102778
[drm:pid1822:drm_ioctl] pid=1822, cmd=0xc010644d, nr=0x4d, dev 0xc615fa00, auth=1
[drm:pid1822:radeon_cp_indirect] idx=27 s=0 e=88 d=1
[drm:pid1822:radeon_cp_dispatch_indirect] buf=27 s=0x0 e=0x58
[drm:pid1822:drm_close] open_count = 2
[drm:pid1822:drm_close] pid = 1822, device = 0xc615fa00, open_count = 2
[drm:pid1822:drm_ioctl] pid=1822, cmd=0x80086442, nr=0x42, dev 0xc615fa00, auth=1
[drm:pid1822:radeon_cp_stop] 
[drm:pid1822:radeon_do_cp_flush] 
[drm:pid1822:radeon_do_cp_idle] 
[drm:pid1822:radeon_do_cp_stop] 
[drm:pid1822:radeon_do_engine_reset] 
info: [drm] Num pipes: 1
[drm:pid1822:radeon_do_cp_reset] 
[drm:pid1822:drm_ioctl] pid=1822, cmd=0x800c6459, nr=0x59, dev 0xc615fa00, auth=1
[drm:pid1822:drm_ioctl] pid=1822, cmd=0x80086414, nr=0x14, dev 0xc615fa00, auth=1
[drm:pid1822:drm_irq_uninstall] irq=16
[drm:pid1822:drm_ioctl] pid=1822, cmd=0x80546440, nr=0x40, dev 0xc615fa00, auth=1
[drm:pid1822:radeon_do_cleanup_cp] 
[drm:pid1822:drm_ioctl] pid=1822, cmd=0x80086439, nr=0x39, dev 0xc615fa00, auth=1
[drm:pid1822:drm_sg_free] sg free virtual = 0xe8a64000
[drm:pid1822:drm_ioctl] pid=1822, cmd=0x8004667e, nr=0x7e, dev 0xc615fa00, auth=1
[drm:pid1822:drm_ioctl] pid=1822, cmd=0x8004667d, nr=0x7d, dev 0xc615fa00, auth=1
[drm:pid1822:drm_ioctl] pid=1822, cmd=0xc0086421, nr=0x21, dev 0xc615fa00, auth=1
[drm:pid1822:drm_rmctx] 2
[drm:pid1822:drm_ioctl] pid=1822, cmd=0xc0086421, nr=0x21, dev 0xc615fa00, auth=1
[drm:pid1822:drm_rmctx] 1
[drm:pid1822:drm_ioctl] pid=1822, cmd=0xc0086426, nr=0x26, dev 0xc615fa00, auth=1
[drm:pid1822:drm_ioctl] pid=1822, cmd=0xc0086426, nr=0x26, dev 0xc615fa00, auth=1
[drm:pid1822:drm_ioctl] pid=1822, cmd=0x8008642b, nr=0x2b, dev 0xc615fa00, auth=1
[drm:pid1822:drm_unlock] 1 (pid 1822) requests unlock (0x80000001), flags = 0x00000000
[drm:pid1822:drm_close] open_count = 1
[drm:pid1822:drm_close] pid = 1822, device = 0xc615fa00, open_count = 1
[drm:pid1822:drm_lastclose] 
[drm:pid1822:radeon_do_cleanup_cp] 
info: [drm] Setting GART location based on new memory map
info: [drm] Loading R500 Microcode
info: [drm] Num pipes: 1
info: [drm] writeback test succeeded in 1 usecs
drm0: [ITHREAD]
info: [drm] Num pipes: 1
info: [drm] Setting GART location based on new memory map
info: [drm] Loading R500 Microcode
info: [drm] Num pipes: 1
info: [drm] writeback test succeeded in 1 usecs
drm0: [ITHREAD]
info: [drm] Num pipes: 1
info: [drm] Setting GART location based on new memory map
info: [drm] Loading R500 Microcode
info: [drm] Num pipes: 1
info: [drm] writeback test succeeded in 1 usecs
drm0: [ITHREAD]
info: [drm] Num pipes: 1
info: [drm] Setting GART location based on new memory map
info: [drm] Loading R500 Microcode
info: [drm] Num pipes: 1
info: [drm] writeback test succeeded in 1 usecs
drm0: [ITHREAD]
info: [drm] Num pipes: 1
info: [drm] Setting GART location based on new memory map
info: [drm] Loading R500 Microcode
info: [drm] Num pipes: 1
info: [drm] writeback test succeeded in 1 usecs
drm0: [ITHREAD]
info: [drm] Num pipes: 1
info: [drm] Setting GART location based on new memory map
info: [drm] Loading R500 Microcode
info: [drm] Num pipes: 1
info: [drm] writeback test succeeded in 1 usecs
drm0: [ITHREAD]
info: [drm] Num pipes: 1
info: [drm] Setting GART location based on new memory map
info: [drm] Loading R500 Microcode
info: [drm] Num pipes: 1
info: [drm] writeback test succeeded in 1 usecs
drm0: [ITHREAD]
[drm:pid6216:drm_ioctl]     returning 4
[drm:pid6216:drm_ioctl] pid=6216, cmd=0x80046457, nr=0x57, dev 0xc615fa00, auth=1
[drm:pid6216:drm_ioctl]     returning 4
[drm:pid6216:drm_ioctl] pid=6216, cmd=0x80046457, nr=0x57, dev 0xc615fa00, auth=1
[drm:pid6216:drm_ioctl]     returning 4
[drm:pid6216:drm_ioctl] pid=6216, cmd=0x80046457, nr=0x57, dev 0xc615fa00, auth=1
[drm:pid6216:drm_ioctl]     returning 4

From villa.alberto at gmail.com  Sun May 10 13:35:23 2009
From: villa.alberto at gmail.com (Alberto Villa)
Date: Sun May 10 13:35:29 2009
Subject: powerd broken
In-Reply-To: <1241870806.1733.61.camel@balrog.2hip.net>
References: <1238293386.00093672.1238281804@10.7.7.3>
	<49CF6899.2060002@bsdforen.de> <49CF8E8D.1080604@bsdforen.de>
	<49CF9C19.3020509@FreeBSD.org> <49D5DA33.4010800@bsdforen.de>
	<1238778004.65025.30.camel@balrog.2hip.net>
	<49DF5D60.9010803@bsdforen.de>
	<1239384104.1922.70.camel@balrog.2hip.net>
	<4A053E52.5030602@bsdforen.de>
	<1241870806.1733.61.camel@balrog.2hip.net>
Message-ID: <dfe7d2900905100604jfe0bc7fmd21695fdffa4cc46@mail.gmail.com>

On Sat, May 9, 2009 at 2:06 PM, Robert Noland <rnoland@freebsd.org> wrote:
> Which update, what? ?I haven't touched the kernel tree in a while, just
> trying to sort it all out with patches here and there. ?Are you saying
> the the 2.7.0 intel driver helped? ?Or maybe the Xserver or mesa
> updates?

updating intel driver, xserver and drm helped a lot! i've finally
deinstalled intel 2.5.*, and started using (happily) exa instead of
xaa in xorg
-- 
Alberto Villa <villa.alberto@gmail.com>
From info at lottery.co.uk  Sun May 10 15:51:31 2009
From: info at lottery.co.uk (UK NATIONAL LOTTERY)
Date: Sun May 10 15:52:02 2009
Subject: National Lottery: Your Email Won
Message-ID: <20090510153412.9C6BC3C18A@hm1207.locaweb.com.br>


United Kingdom National Lottery 
101 Bovill Road, London
SE23 1EL United Kingdom


File #: EGS/2251256003/02

Congratulations, we are pleased to inform you of the result of the United Kingdom National Lottery Award Winners. Your email address have been randomly selected as a winner in the ongoing United Kingdom National Lottery Online program, the draw was held on 30th April, 2009 using a computerized balloting  system of selection. The United Kingdom National Lottery is aimed and focused at global development and improvement of living standard across the world.

Free £77 Million Pounds won including *four* Ten Million Pounds Winners and *fourteen* Millionaires plus thousands of other cash prizes. Winner from all over the world, India, France, Singapore, USA, United Kingdom, Spain, South America, Malaysia, Indonesia, South Africa, Belgium, Denmark, Ireland and many more.

We wish to express our sincere apologies for the late notification, this free award online program is been conducted bi-quarterly. United Kingdom National Lottery Free Award draw was conducted at the Europe Issuing Centre, you were selected from an exclusive list of 1,000,000,000 e-mail addresses of internet users from the following categories; consumers, professionals and corporate bodies picked by an advanced automated random computer ballot search from the internet 'NO TICKETS OR DRAFTS WERE SOLD'.

Your email address attached to Security File #: EGS/2251256003/02 with Serial number No: 002839 emerged as a winner of Six Hundred Thousand Pounds (£600.000.00 GBP), therefore you are eligible to file claim for your prize as one of our lucky winners for the payout of your total sum after a thorough verification that will be conducted by our various credible financial institutions.

This online program is precisely aimed at enabling all internet users across the world benefit from the United Kingdom National Lottery, your email address falls within the First Category Winner as such your file has been designated to our European Centre, where the complete verification and payout will be conducted only if there are no exceptions during the claims process, to file your claim immediately please contact our International Programs Director Anderson Spencer with the following information:

1. Name in full-----------------------------------------
2. Phone/Fax-------------------------------------------
3. Occupation------------------------------------------

TO:

Contact Person: Anderson Spencer
European Payment Issuing Office 
Tel: +447024065192 (8am - 5pm GMT)
Fax: +447092894160
Email: zonal.anderson-spencer@msn.com

NOTE: In order to benefit from this program, you are advised in your own best interest to file your claim not later than 7days days from the date of this notification to avoid disqualification; anybody under the age of 18 is automatically disqualified.

Please include this File #: EGS/2251256003/02 in every of your correspondence with our Foreign Service Director Anderson Spencer. 

IMPORTANT: Solemn confidentiality should be ensured until successful remittance of your prize to you to avoid undue taking of advantage, unwarranted claim and abuse of program, any breach of confidentiality on the part of the winner will result to automatic disqualification.

Sincerely Yours,

Mrs. Julie Van Hans,
Executive Director.
United Kingdom National Lottery.



From fbsd-ml at scrapper.ca  Sun May 10 19:46:26 2009
From: fbsd-ml at scrapper.ca (Norbert Papke)
Date: Sun May 10 19:46:33 2009
Subject: 7.2-STABLE: Inserting USB device causes Fatal Trap 12
Message-ID: <200905101217.39920.fbsd-ml@scrapper.ca>

Inserting a USB thumb drive into a running sytem result in a "Fatal trap 12: 
page fault while in kernel mode".  

Unfortunately, I was not able to save a core (not entirely sure why, I'll 
investigate separately).  I have manually copied the backtrace:

usb_transfer_complete
bus_dmamap_load
usbd_transfer
usbd_do_request_flags_pipe
usbd_do_request_flags
usbd_get_string_desc
usbd_get_string
usbd_devinfo_vp
usbd_devinfo
usbd_new_device
uhub_explore
usb_event_thread
fork_exit
for_trampine

The problem is repeatable.  It only happens when I insert the thumb drive into 
a running system.  If I boot with the thumb drive present, everything is 
fine.

Any help is greatly appreciated.

Cheers,

-- Norbert Papke.

=================================================

# uname -a
FreeBSD proven.lan 7.2-STABLE FreeBSD 7.2-STABLE #0 r191841: Tue May  5 
21:13:21 PDT 2009     
npapke@proven.lan:/usr/obj/red/public/freebsd/sources/stable/sys/PROVEN  
amd64

=================================================

Kernel config:

include GENERIC
ident PROVEN

options KDB             # kernel debugger (just in case)
options KDB_TRACE
options DDB             # kernel debugger (just in case)
options WITNESS
options WITNESS_SKIPSPIN

options IPSEC
device  crypto
device  stf             # for IPv6 tunneling

# keep kernel messages from different cpus separate
options PRINTF_BUFR_SIZE=64

option  SC_HISTORY_SIZE=2000
options SC_NORM_ATTR=(FG_GREEN|BG_BLACK)
options SC_NORM_REV_ATTR=(FG_YELLOW|BG_GREEN)
options SC_KERNEL_CONS_ATTR=(FG_LIGHTRED|BG_BLACK)
options SC_KERNEL_CONS_REV_ATTR=(FG_BLACK|BG_RED)

# Alternate Queuing of network packets
options ALTQ
options ALTQ_CBQ                # Class Bases Queuing (CBQ)
options ALTQ_RED                # Random Early Detection (RED)
options ALTQ_RIO                # RED In/Out
options ALTQ_HFSC               # Hierarchical Packet Scheduler (HFSC)
options ALTQ_PRIQ               # Priority Queuing (PRIQ)
options ALTQ_NOPCC              # Required for SMP build

# load as module for debugging
nodevice        re              # RealTek 8139C+/8169/8169S/8110S

=================================================

Copyright (c) 1992-2009 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
        The Regents of the University of California. All rights reserved.
FreeBSD is a registered trademark of The FreeBSD Foundation.
FreeBSD 7.2-STABLE #0 r191841: Tue May  5 21:13:21 PDT 2009
    npapke@proven.lan:/usr/obj/red/public/freebsd/sources/stable/sys/PROVEN
WARNING: WITNESS option enabled, expect reduced performance.
Timecounter "i8254" frequency 1193182 Hz quality 0
CPU: Intel(R) Core(TM)2 Duo CPU     E8500  @ 3.16GHz (3155.59-MHz K8-class 
CPU)
  Origin = "GenuineIntel"  Id = 0x1067a  Stepping = 10
  
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=0x408e3fd<SSE3,RSVD2,MON,DS_CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,<b19>,XSAVE>
  AMD Features=0x20100800<SYSCALL,NX,LM>
  AMD Features2=0x1<LAHF>
  Cores per package: 2
usable memory = 4279189504 (4080 MB)
avail memory  = 4097724416 (3907 MB)
ACPI APIC Table: <100808 APIC1053>
FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs
 cpu0 (BSP): APIC ID:  0
 cpu1 (AP): APIC ID:  1
ioapic0 <Version 2.0> irqs 0-23 on motherboard
kbd1 at kbdmux0
cryptosoft0: <software crypto> on motherboard
acpi0: <100808 XSDT1053> on motherboard
acpi0: [ITHREAD]
acpi0: Power Button (fixed)
acpi0: reservation of ffc00000, 300000 (3) failed
acpi0: reservation of fee00000, 1000 (3) failed
acpi0: reservation of 0, a0000 (3) failed
acpi0: reservation of 100000, bff00000 (3) failed
Timecounter "ACPI-safe" frequency 3579545 Hz quality 850
acpi_timer0: <24-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0
acpi_hpet0: <High Precision Event Timer> iomem 0xfed00000-0xfed003ff on acpi0
Timecounter "HPET" frequency 14318180 Hz quality 900
pcib0: <ACPI Host-PCI bridge> port 0xcf8-0xcff on acpi0
pci0: <ACPI PCI bus> on pcib0
pcib1: <ACPI PCI-PCI bridge> irq 16 at device 1.0 on pci0
pci1: <ACPI PCI bus> on pcib1
vgapci0: <VGA-compatible display> port 0xc000-0xc0ff mem 
0xd0000000-0xdfffffff,0xfe9f0000-0xfe9fffff irq 16 at device 0.0 on pci1
drm0: <ATI ATI Radeon HD 3600 XT> on vgapci0
info: [drm] MSI enabled 1 message(s)
vgapci0: child drm0 requested pci_enable_busmaster
info: [drm] Initialized radeon 1.29.0 20080528
hdac0: <ATI RV635 High Definition Audio Controller> mem 0xfe9ec000-0xfe9effff 
irq 17 at device 0.1 on pci1
hdac0: HDA Driver Revision: 20090329_0131
hdac0: [ITHREAD]
uhci0: <UHCI (generic) USB controller> port 0xbc00-0xbc1f irq 16 at device 
26.0 on pci0
uhci0: [GIANT-LOCKED]
uhci0: [ITHREAD]
usb0: <UHCI (generic) USB controller> 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: <UHCI (generic) USB controller> port 0xb880-0xb89f irq 21 at device 
26.1 on pci0
uhci1: [GIANT-LOCKED]
uhci1: [ITHREAD]
usb1: <UHCI (generic) USB controller> 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: <UHCI (generic) USB controller> port 0xb800-0xb81f irq 19 at device 
26.2 on pci0
uhci2: [GIANT-LOCKED]
uhci2: [ITHREAD]
usb2: <UHCI (generic) USB controller> 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: <EHCI (generic) USB 2.0 controller> mem 0xfe8fe000-0xfe8fe3ff irq 18 at 
device 26.7 on pci0
ehci0: [GIANT-LOCKED]
ehci0: [ITHREAD]
usb3: EHCI version 1.0
usb3: companion controllers, 2 ports each: usb0 usb1 usb2
usb3: <EHCI (generic) 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
hdac1: <Intel 82801J High Definition Audio Controller> mem 
0xfe8f8000-0xfe8fbfff irq 22 at device 27.0 on pci0
hdac1: HDA Driver Revision: 20090329_0131
hdac1: [ITHREAD]
pcib2: <ACPI PCI-PCI bridge> irq 17 at device 28.0 on pci0
pci2: <ACPI PCI bus> on pcib2
pcib3: <ACPI PCI-PCI bridge> irq 16 at device 28.5 on pci0
pci3: <ACPI PCI bus> on pcib3
re0: <RealTek 8168/8168B/8168C/8168CP/8168D/8111B/8111C/8111CP PCIe Gigabit 
Ethernet> port 0xd800-0xd8ff mem 0xfeaff000-0xfeafffff,0xfdff0000-0xfdffffff 
irq 17 at device 0.0 on pci3
re0: Chip rev. 0x3c000000
re0: MAC rev. 0x00400000
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:30:48:b0:6a:1f
re0: [FILTER]
uhci3: <UHCI (generic) USB controller> port 0xb480-0xb49f irq 23 at device 
29.0 on pci0
uhci3: [GIANT-LOCKED]
uhci3: [ITHREAD]
usb4: <UHCI (generic) USB controller> on uhci3
usb4: USB revision 1.0
uhub4: <Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1> on usb4
uhub4: 2 ports with 2 removable, self powered
uhci4: <UHCI (generic) USB controller> port 0xb400-0xb41f irq 19 at device 
29.1 on pci0
uhci4: [GIANT-LOCKED]
uhci4: [ITHREAD]
usb5: <UHCI (generic) USB controller> on uhci4
usb5: USB revision 1.0
uhub5: <Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1> on usb5
uhub5: 2 ports with 2 removable, self powered
uhci5: <UHCI (generic) USB controller> port 0xb080-0xb09f irq 18 at device 
29.2 on pci0
uhci5: [GIANT-LOCKED]
uhci5: [ITHREAD]
usb6: <UHCI (generic) USB controller> on uhci5
usb6: USB revision 1.0
uhub6: <Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1> on usb6
uhub6: 2 ports with 2 removable, self powered
ehci1: <EHCI (generic) USB 2.0 controller> mem 0xfe8fc000-0xfe8fc3ff irq 23 at 
device 29.7 on pci0
ehci1: [GIANT-LOCKED]
ehci1: [ITHREAD]
usb7: EHCI version 1.0
usb7: companion controllers, 2 ports each: usb4 usb5 usb6
usb7: <EHCI (generic) USB 2.0 controller> on ehci1
usb7: USB revision 2.0
uhub7: <Intel EHCI root hub, class 9/0, rev 2.00/1.00, addr 1> on usb7
uhub7: 6 ports with 6 removable, self powered
umass0: <JetFlash Mass Storage Device, class 0/0, rev 2.00/1.00, addr 2> on 
uhub7
pcib4: <ACPI PCI-PCI bridge> at device 30.0 on pci0
pci4: <ACPI PCI bus> on pcib4
dc0: <ADMtek AN985 10/100BaseTX> port 0xe800-0xe8ff mem 0xfebffc00-0xfebfffff 
irq 21 at device 1.0 on pci4
miibus1: <MII bus> on dc0
acphy0: <ACXXX 10/100 media interface> PHY 1 on miibus1
acphy0:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
dc0: Ethernet address: 00:20:78:10:3e:98
dc0: [ITHREAD]
isab0: <PCI-ISA bridge> at device 31.0 on pci0
isa0: <ISA bus> on isab0
atapci0: <Intel ICH10 SATA300 controller> port 
0xb000-0xb007,0xac00-0xac03,0xa880-0xa887,0xa800-0xa803,0xa480-0xa48f,0xa400-0xa40f 
irq 19 at device 31.2 on pci0
atapci0: [ITHREAD]
ata2: <ATA channel 0> on atapci0
ata2: [ITHREAD]
ata3: <ATA channel 1> on atapci0
ata3: [ITHREAD]
ichsmb0: <SMBus controller> port 0x400-0x41f mem 0xfe8f7c00-0xfe8f7cff irq 18 
at device 31.3 on pci0
ichsmb0: [GIANT-LOCKED]
ichsmb0: [ITHREAD]
smbus0: <System Management Bus> on ichsmb0
smb0: <SMBus generic I/O> on smbus0
atapci1: <Intel ICH10 SATA300 controller> port 
0xa000-0xa007,0x9c00-0x9c03,0x9880-0x9887,0x9800-0x9803,0x9480-0x948f,0x9400-0x940f 
irq 19 at device 31.5 on pci0
atapci1: [ITHREAD]
ata4: <ATA channel 0> on atapci1
ata4: [ITHREAD]
ata5: <ATA channel 1> on atapci1
ata5: [ITHREAD]
acpi_button0: <Power Button> on acpi0
sio0: configured irq 4 not in bitmap of probed irqs 0
sio0: port may not be enabled
sio0: configured irq 4 not in bitmap of probed irqs 0
sio0: port may not be enabled
sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0
sio0: type 16550A
sio0: [FILTER]
ppc0: <Parallel port> port 0x378-0x37f irq 7 on acpi0
ppc0: Generic chipset (NIBBLE-only) in COMPATIBLE mode
ppbus0: <Parallel port bus> on ppc0
ppbus0: [ITHREAD]
lpt0: <Printer> on ppbus0
lpt0: Interrupt-driven port
ppi0: <Parallel I/O> on ppbus0
plip0: <PLIP network interface> on ppbus0
plip0: WARNING: using obsoleted IFF_NEEDSGIANT flag
ppc0: [GIANT-LOCKED]
ppc0: [ITHREAD]
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
ACPI Warning (tbutils-0243): Incorrect checksum in table [OEMB] -  45, should 
be 40 [20070320]
coretemp0: <CPU On-Die Thermal Sensors> on cpu0
est0: <Enhanced SpeedStep Frequency Control> on cpu0
p4tcc0: <CPU Frequency Thermal Control> on cpu0
cpu1: <ACPI CPU> on acpi0
coretemp1: <CPU On-Die Thermal Sensors> on cpu1
est1: <Enhanced SpeedStep Frequency Control> on cpu1
est: CPU supports Enhanced Speedstep, but is not recognized.
est: cpu_vendor GenuineIntel, msr 616492206004922
device_attach: est1 attach returned 6
p4tcc1: <CPU Frequency Thermal Control> on cpu1
orm0: <ISA Option ROM> at iomem 0xc0000-0xcffff on isa0
sc0: <System console> at flags 0x100 on isa0
sc0: VGA <16 virtual consoles, flags=0x300>
sio1: configured irq 3 not in bitmap of probed irqs 0
sio1: port may not be enabled
vga0: <Generic ISA VGA> at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0
Timecounters tick every 1.000 msec
IPsec: Initialized Security Association Processing.
ad4: 239372MB <Maxtor 7Y250M0 YAR51HW0> at ata2-master SATA150
ad7: 305245MB <Seagate ST3320620AS 3.AAK> at ata3-slave SATA300
ad8: 610480MB <WDC WD6401AALS-00L3B2 01.03B01> at ata4-master SATA300
GEOM_LABEL: Label for provider ad4s1a is ufsid/497cecd46b0e22e5.
acd0: DVDR <HL-DT-STDVD-RAM GH22NS30/1.01> at ata5-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 #2: Realtek ALC888
hdac1: hdac_command_send_internal: TIMEOUT numcmd=1, sent=1, received=0
hdac1: hdac_command_send_internal: TIMEOUT numcmd=1, sent=1, received=0
hdac1: Codec #3 is not responding! Probing aborted.
pcm1: <HDA Realtek ALC888 PCM #0 Analog> at cad 2 nid 1 on hdac1
pcm2: <HDA Realtek ALC888 PCM #1 Analog> at cad 2 nid 1 on hdac1
pcm3: <HDA Realtek ALC888 PCM #2 Digital> at cad 2 nid 1 on hdac1
acd0: FAILURE - INQUIRY ILLEGAL REQUEST asc=0x24 ascq=0x00
(probe1:umass-sim0:0:0:0): TEST UNIT READY. CDB: 0 0 0 0 0 0
(probe1:umass-sim0:0:0:0): CAM Status: SCSI Status Error
(probe1:umass-sim0:0:0:0): SCSI Status: Check Condition
(probe1:umass-sim0:0:0:0): UNIT ATTENTION asc:28,0
(probe1:umass-sim0:0:0:0): Not ready to ready change, medium may have changed
(probe1:umass-sim0:0:0:0): Retrying Command (per Sense Data)
acd0: FAILURE - INQUIRY ILLEGAL REQUEST asc=0x24 ascq=0x00
SMP: AP CPU #1 Launched!
WARNING: WITNESS option enabled, expect reduced performance.
da0 at umass-sim0 bus 0 target 0 lun 0
da0: <JetFlash Transcend 4GB 8.07> Removable Direct Access SCSI-2 device
da0: 40.000MB/s transfers
da0: 3830MB (7843840 512 byte sectors: 255H 63S/T 488C)
cd0 at ata3 bus 0 target 0 lun 0
cd0: <HL-DT-ST DVD-RAM GH22NS30 1.01> Removable CD-ROM SCSI-0 device
cd0: 3.300MB/s transfers
cd0: cd present [4098336 x 2048 byte records]
GEOM_LABEL: Label for provider acd0 is iso9660/THE_MATRIX_16X9LB_N_AMERICA.
Trying to mount root from ufs:/dev/ad4s1a
WARNING: / was not properly dismounted
WARNING: reducing size to maximum of 67108864 blocks per swap unit
GEOM_LABEL: Label ufsid/497cecd46b0e22e5 removed.
GEOM_LABEL: Label for provider ad4s1a is ufsid/497cecd46b0e22e5.
GEOM_LABEL: Label ufsid/497cecd46b0e22e5 removed.
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 6
ZFS storage pool version 6
lock order reversal:
 1st 0xffffffff80e49de0 pf task mtx (pf task mtx) 
@ /red/public/freebsd/sources/stable/sys/modules/pf/../../contrib/pf/net/pf_ioctl.c:1394
 2nd 0xffffffff80ba94c0 ifnet (ifnet) 
@ /red/public/freebsd/sources/stable/sys/net/if.c:1623
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2a
witness_checkorder() at witness_checkorder+0x543
_mtx_lock_flags() at _mtx_lock_flags+0x1f
ifunit() at ifunit+0x24
pfioctl() at pfioctl+0x2531
devfs_ioctl_f() at devfs_ioctl_f+0x71
kern_ioctl() at kern_ioctl+0x91
ioctl() at ioctl+0xeb
syscall() at syscall+0x1a5
Xfast_syscall() at Xfast_syscall+0xab
--- syscall (54, FreeBSD ELF64, ioctl), rip = 0x80096296c, rsp = 
0x7fffffffdc18, rbp = 0x7fffffffdca0 ---
kqemu version 0x00010400
kqemu: KQEMU installed, max_locked_mem=2089448kB.
acd0: FAILURE - READ_BIG timed out
acd0: FAILURE - READ_BIG timed out
acd0: FAILURE - READ_BIG timed out
info: [drm] Setting GART location based on new memory map
info: [drm] Loading RV635 CP Microcode
info: [drm] Loading RV635 PFP Microcode
info: [drm] Resetting GPU
info: [drm] writeback test succeeded in 1 usecs
drm0: [ITHREAD]
acd0: FAILURE - READ_BIG timed out
acd0: FAILURE - READ_BIG timed out
(cd0:ata3:0:0:0): cddone: got error 0x5 back
tap0: Ethernet address: 00:bd:d8:9b:04:00
bridge0: Ethernet address: fa:cc:68:2e:a4:8e
tap0: promiscuous mode enabled
dc0: promiscuous mode enabled

From npapke at acm.org  Sun May 10 21:26:10 2009
From: npapke at acm.org (Norbert Papke)
Date: Sun May 10 21:26:18 2009
Subject: 7.2-STABLE: Inserting USB device causes Fatal Trap 12
In-Reply-To: <200905101217.39920.fbsd-ml@scrapper.ca>
References: <200905101217.39920.fbsd-ml@scrapper.ca>
Message-ID: <200905101426.08256.npapke@acm.org>

On May 10, 2009, Norbert Papke wrote:
> Inserting a USB thumb drive into a running sytem result in a "Fatal trap
> 12: page fault while in kernel mode".
>
> Unfortunately, I was not able to save a core (not entirely sure why, I'll
> investigate separately).  I have manually copied the backtrace:

I now have a kernel dump and backtrace with symbols:

#0  doadump () at pcpu.h:195
#1  0xffffffff801d239c in db_fncall (dummy1=Variable "dummy1" is not 
available.
) at /red/public/freebsd/sources/stable/sys/ddb/db_command.c:516
#2  0xffffffff801d28a9 in db_command (last_cmdp=0xffffffff80adc648, 
cmd_table=0x0, dopager=1)
    at /red/public/freebsd/sources/stable/sys/ddb/db_command.c:413
#3  0xffffffff801d2aab in db_command_loop () 
at /red/public/freebsd/sources/stable/sys/ddb/db_command.c:466
#4  0xffffffff801d42f7 in db_trap (type=Variable "type" is not available.
) at /red/public/freebsd/sources/stable/sys/ddb/db_main.c:228
#5  0xffffffff805159e5 in kdb_trap (type=12, code=0, tf=0xfffffffef5b69d10)
    at /red/public/freebsd/sources/stable/sys/kern/subr_kdb.c:524
#6  0xffffffff80798143 in trap_fatal (frame=0xfffffffef5b69d10, 
eva=Variable "eva" is not available.
)
    at /red/public/freebsd/sources/stable/sys/amd64/amd64/trap.c:752
#7  0xffffffff80798498 in trap_pfault (frame=0xfffffffef5b69d10, usermode=0)
    at /red/public/freebsd/sources/stable/sys/amd64/amd64/trap.c:673
#8  0xffffffff80798bcf in trap (frame=0xfffffffef5b69d10)
    at /red/public/freebsd/sources/stable/sys/amd64/amd64/trap.c:444
#9  0xffffffff8077edae in calltrap () 
at /red/public/freebsd/sources/stable/sys/amd64/amd64/exception.S:209
#10 0xffffffff80473265 in usb_transfer_complete (xfer=0xffffff00045cbc00)
    at /red/public/freebsd/sources/stable/sys/dev/usb/usbdi.c:949
#11 0xffffffff8077af55 in bus_dmamap_load (dmat=0xffffff0004598580, 
map=0xffffff000cbf5e00,
    buf=0xfffffffef5b69ff0, buflen=Variable "buflen" is not available.
) at /red/public/freebsd/sources/stable/sys/amd64/amd64/busdma_machdep.c:739
#12 0xffffffff80473955 in usbd_transfer (xfer=0xffffff00045cbc00)
    at /red/public/freebsd/sources/stable/sys/dev/usb/usbdi.c:312
#13 0xffffffff80473b36 in usbd_do_request_flags_pipe (dev=0xffffff009c1e4a00, 
pipe=0xffffff000c857680,
    req=0xfffffffef5b69f90, data=0xfffffffef5b69ff0, flags=Variable "flags" is 
not available.
)
    at /red/public/freebsd/sources/stable/sys/dev/usb/usbdi.c:1100
#14 0xffffffff80473c60 in usbd_do_request_flags (dev=Variable "dev" is not 
available.
)
    at /red/public/freebsd/sources/stable/sys/dev/usb/usbdi.c:1070
#15 0xffffffff80471d1a in usbd_get_string_desc (dev=0xffffff009c1e4a00, 
sindex=Variable "sindex" is not available.
)
    at /red/public/freebsd/sources/stable/sys/dev/usb/usb_subr.c:171
#16 0xffffffff80472f1d in usbd_get_string (dev=0xffffff009c1e4a00, si=1, 
buf=0xfffffffef5b6a200 "", len=128)
---Type <return> to continue, or q <return> to quit---
    at /red/public/freebsd/sources/stable/sys/dev/usb/usbdi.c:1353
#17 0xffffffff80470fca in usbd_devinfo_vp (dev=0xffffff009c1e4a00, 
v=0xfffffffef5b6a200 "",
    p=0xfffffffef5b6a180 "?z?\200????`??\200????", usedev=Variable "usedev" is 
not available.
)
    at /red/public/freebsd/sources/stable/sys/dev/usb/usb_subr.c:216
#18 0xffffffff80471b76 in usbd_devinfo (dev=0xffffff009c1e4a00, showclass=1, 
cp=0xffffff0122986000 "\001")
    at /red/public/freebsd/sources/stable/sys/dev/usb/usb_subr.c:281
#19 0xffffffff8047243e in usbd_new_device (parent=0xffffff0004591900, 
bus=0xffffff000440a000, depth=Variable "depth" is not available.
)
    at /red/public/freebsd/sources/stable/sys/dev/usb/usb_subr.c:861
#20 0xffffffff80467b5b in uhub_explore (dev=0xffffff0004591400)
    at /red/public/freebsd/sources/stable/sys/dev/usb/uhub.c:523
#21 0xffffffff8046f391 in usb_discover (v=Variable "v" is not available.
) at /red/public/freebsd/sources/stable/sys/dev/usb/usb.c:724
#22 0xffffffff8046fc61 in usb_event_thread (arg=Variable "arg" is not 
available.
) at /red/public/freebsd/sources/stable/sys/dev/usb/usb.c:440
#23 0xffffffff804d05bd in fork_exit (callout=0xffffffff8046fbe5 
<usb_event_thread>, arg=0xffffff0004598d00,
    frame=0xfffffffef5b6ac80) 
at /red/public/freebsd/sources/stable/sys/kern/kern_fork.c:810
#24 0xffffffff8077f16e in fork_trampoline ()
    at /red/public/freebsd/sources/stable/sys/amd64/amd64/exception.S:455


> The problem is repeatable.  It only happens when I insert the thumb drive
> into a running system.  If I boot with the thumb drive present, everything
> is fine.
>
> Any help is greatly appreciated.
>
> Cheers,
>
> -- Norbert Papke.
>
> =================================================
>
> # uname -a
> FreeBSD proven.lan 7.2-STABLE FreeBSD 7.2-STABLE #0 r191841: Tue May  5
> 21:13:21 PDT 2009
> npapke@proven.lan:/usr/obj/red/public/freebsd/sources/stable/sys/PROVEN
> amd64
>
> =================================================
>
> Kernel config:
>
> include GENERIC
> ident PROVEN
>
> options KDB             # kernel debugger (just in case)
> options KDB_TRACE
> options DDB             # kernel debugger (just in case)
> options WITNESS
> options WITNESS_SKIPSPIN
>
> options IPSEC
> device  crypto
> device  stf             # for IPv6 tunneling
>
> # keep kernel messages from different cpus separate
> options PRINTF_BUFR_SIZE=64
>
> option  SC_HISTORY_SIZE=2000
> options SC_NORM_ATTR=(FG_GREEN|BG_BLACK)
> options SC_NORM_REV_ATTR=(FG_YELLOW|BG_GREEN)
> options SC_KERNEL_CONS_ATTR=(FG_LIGHTRED|BG_BLACK)
> options SC_KERNEL_CONS_REV_ATTR=(FG_BLACK|BG_RED)
>
> # Alternate Queuing of network packets
> options ALTQ
> options ALTQ_CBQ                # Class Bases Queuing (CBQ)
> options ALTQ_RED                # Random Early Detection (RED)
> options ALTQ_RIO                # RED In/Out
> options ALTQ_HFSC               # Hierarchical Packet Scheduler (HFSC)
> options ALTQ_PRIQ               # Priority Queuing (PRIQ)
> options ALTQ_NOPCC              # Required for SMP build
>
> # load as module for debugging
> nodevice        re              # RealTek 8139C+/8169/8169S/8110S
>
> =================================================
>
> Copyright (c) 1992-2009 The FreeBSD Project.
> Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
>         The Regents of the University of California. All rights reserved.
> FreeBSD is a registered trademark of The FreeBSD Foundation.
> FreeBSD 7.2-STABLE #0 r191841: Tue May  5 21:13:21 PDT 2009
>     npapke@proven.lan:/usr/obj/red/public/freebsd/sources/stable/sys/PROVEN
> WARNING: WITNESS option enabled, expect reduced performance.
> Timecounter "i8254" frequency 1193182 Hz quality 0
> CPU: Intel(R) Core(TM)2 Duo CPU     E8500  @ 3.16GHz (3155.59-MHz K8-class
> CPU)
>   Origin = "GenuineIntel"  Id = 0x1067a  Stepping = 10
>
> Features=0xbfebfbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MC
>A,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE>
>
> Features2=0x408e3fd<SSE3,RSVD2,MON,DS_CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,P
>DCM,<b19>,XSAVE> AMD Features=0x20100800<SYSCALL,NX,LM>
>   AMD Features2=0x1<LAHF>
>   Cores per package: 2
> usable memory = 4279189504 (4080 MB)
> avail memory  = 4097724416 (3907 MB)
> ACPI APIC Table: <100808 APIC1053>
> FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs
>  cpu0 (BSP): APIC ID:  0
>  cpu1 (AP): APIC ID:  1
> ioapic0 <Version 2.0> irqs 0-23 on motherboard
> kbd1 at kbdmux0
> cryptosoft0: <software crypto> on motherboard
> acpi0: <100808 XSDT1053> on motherboard
> acpi0: [ITHREAD]
> acpi0: Power Button (fixed)
> acpi0: reservation of ffc00000, 300000 (3) failed
> acpi0: reservation of fee00000, 1000 (3) failed
> acpi0: reservation of 0, a0000 (3) failed
> acpi0: reservation of 100000, bff00000 (3) failed
> Timecounter "ACPI-safe" frequency 3579545 Hz quality 850
> acpi_timer0: <24-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0
> acpi_hpet0: <High Precision Event Timer> iomem 0xfed00000-0xfed003ff on
> acpi0 Timecounter "HPET" frequency 14318180 Hz quality 900
> pcib0: <ACPI Host-PCI bridge> port 0xcf8-0xcff on acpi0
> pci0: <ACPI PCI bus> on pcib0
> pcib1: <ACPI PCI-PCI bridge> irq 16 at device 1.0 on pci0
> pci1: <ACPI PCI bus> on pcib1
> vgapci0: <VGA-compatible display> port 0xc000-0xc0ff mem
> 0xd0000000-0xdfffffff,0xfe9f0000-0xfe9fffff irq 16 at device 0.0 on pci1
> drm0: <ATI ATI Radeon HD 3600 XT> on vgapci0
> info: [drm] MSI enabled 1 message(s)
> vgapci0: child drm0 requested pci_enable_busmaster
> info: [drm] Initialized radeon 1.29.0 20080528
> hdac0: <ATI RV635 High Definition Audio Controller> mem
> 0xfe9ec000-0xfe9effff irq 17 at device 0.1 on pci1
> hdac0: HDA Driver Revision: 20090329_0131
> hdac0: [ITHREAD]
> uhci0: <UHCI (generic) USB controller> port 0xbc00-0xbc1f irq 16 at device
> 26.0 on pci0
> uhci0: [GIANT-LOCKED]
> uhci0: [ITHREAD]
> usb0: <UHCI (generic) USB controller> 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: <UHCI (generic) USB controller> port 0xb880-0xb89f irq 21 at device
> 26.1 on pci0
> uhci1: [GIANT-LOCKED]
> uhci1: [ITHREAD]
> usb1: <UHCI (generic) USB controller> 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: <UHCI (generic) USB controller> port 0xb800-0xb81f irq 19 at device
> 26.2 on pci0
> uhci2: [GIANT-LOCKED]
> uhci2: [ITHREAD]
> usb2: <UHCI (generic) USB controller> 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: <EHCI (generic) USB 2.0 controller> mem 0xfe8fe000-0xfe8fe3ff irq 18
> at device 26.7 on pci0
> ehci0: [GIANT-LOCKED]
> ehci0: [ITHREAD]
> usb3: EHCI version 1.0
> usb3: companion controllers, 2 ports each: usb0 usb1 usb2
> usb3: <EHCI (generic) 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
> hdac1: <Intel 82801J High Definition Audio Controller> mem
> 0xfe8f8000-0xfe8fbfff irq 22 at device 27.0 on pci0
> hdac1: HDA Driver Revision: 20090329_0131
> hdac1: [ITHREAD]
> pcib2: <ACPI PCI-PCI bridge> irq 17 at device 28.0 on pci0
> pci2: <ACPI PCI bus> on pcib2
> pcib3: <ACPI PCI-PCI bridge> irq 16 at device 28.5 on pci0
> pci3: <ACPI PCI bus> on pcib3
> re0: <RealTek 8168/8168B/8168C/8168CP/8168D/8111B/8111C/8111CP PCIe Gigabit
> Ethernet> port 0xd800-0xd8ff mem
> 0xfeaff000-0xfeafffff,0xfdff0000-0xfdffffff irq 17 at device 0.0 on pci3
> re0: Chip rev. 0x3c000000
> re0: MAC rev. 0x00400000
> 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:30:48:b0:6a:1f
> re0: [FILTER]
> uhci3: <UHCI (generic) USB controller> port 0xb480-0xb49f irq 23 at device
> 29.0 on pci0
> uhci3: [GIANT-LOCKED]
> uhci3: [ITHREAD]
> usb4: <UHCI (generic) USB controller> on uhci3
> usb4: USB revision 1.0
> uhub4: <Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1> on usb4
> uhub4: 2 ports with 2 removable, self powered
> uhci4: <UHCI (generic) USB controller> port 0xb400-0xb41f irq 19 at device
> 29.1 on pci0
> uhci4: [GIANT-LOCKED]
> uhci4: [ITHREAD]
> usb5: <UHCI (generic) USB controller> on uhci4
> usb5: USB revision 1.0
> uhub5: <Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1> on usb5
> uhub5: 2 ports with 2 removable, self powered
> uhci5: <UHCI (generic) USB controller> port 0xb080-0xb09f irq 18 at device
> 29.2 on pci0
> uhci5: [GIANT-LOCKED]
> uhci5: [ITHREAD]
> usb6: <UHCI (generic) USB controller> on uhci5
> usb6: USB revision 1.0
> uhub6: <Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1> on usb6
> uhub6: 2 ports with 2 removable, self powered
> ehci1: <EHCI (generic) USB 2.0 controller> mem 0xfe8fc000-0xfe8fc3ff irq 23
> at device 29.7 on pci0
> ehci1: [GIANT-LOCKED]
> ehci1: [ITHREAD]
> usb7: EHCI version 1.0
> usb7: companion controllers, 2 ports each: usb4 usb5 usb6
> usb7: <EHCI (generic) USB 2.0 controller> on ehci1
> usb7: USB revision 2.0
> uhub7: <Intel EHCI root hub, class 9/0, rev 2.00/1.00, addr 1> on usb7
> uhub7: 6 ports with 6 removable, self powered
> umass0: <JetFlash Mass Storage Device, class 0/0, rev 2.00/1.00, addr 2> on
> uhub7
> pcib4: <ACPI PCI-PCI bridge> at device 30.0 on pci0
> pci4: <ACPI PCI bus> on pcib4
> dc0: <ADMtek AN985 10/100BaseTX> port 0xe800-0xe8ff mem
> 0xfebffc00-0xfebfffff irq 21 at device 1.0 on pci4
> miibus1: <MII bus> on dc0
> acphy0: <ACXXX 10/100 media interface> PHY 1 on miibus1
> acphy0:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
> dc0: Ethernet address: 00:20:78:10:3e:98
> dc0: [ITHREAD]
> isab0: <PCI-ISA bridge> at device 31.0 on pci0
> isa0: <ISA bus> on isab0
> atapci0: <Intel ICH10 SATA300 controller> port
> 0xb000-0xb007,0xac00-0xac03,0xa880-0xa887,0xa800-0xa803,0xa480-0xa48f,0xa40
>0-0xa40f irq 19 at device 31.2 on pci0
> atapci0: [ITHREAD]
> ata2: <ATA channel 0> on atapci0
> ata2: [ITHREAD]
> ata3: <ATA channel 1> on atapci0
> ata3: [ITHREAD]
> ichsmb0: <SMBus controller> port 0x400-0x41f mem 0xfe8f7c00-0xfe8f7cff irq
> 18 at device 31.3 on pci0
> ichsmb0: [GIANT-LOCKED]
> ichsmb0: [ITHREAD]
> smbus0: <System Management Bus> on ichsmb0
> smb0: <SMBus generic I/O> on smbus0
> atapci1: <Intel ICH10 SATA300 controller> port
> 0xa000-0xa007,0x9c00-0x9c03,0x9880-0x9887,0x9800-0x9803,0x9480-0x948f,0x940
>0-0x940f irq 19 at device 31.5 on pci0
> atapci1: [ITHREAD]
> ata4: <ATA channel 0> on atapci1
> ata4: [ITHREAD]
> ata5: <ATA channel 1> on atapci1
> ata5: [ITHREAD]
> acpi_button0: <Power Button> on acpi0
> sio0: configured irq 4 not in bitmap of probed irqs 0
> sio0: port may not be enabled
> sio0: configured irq 4 not in bitmap of probed irqs 0
> sio0: port may not be enabled
> sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on
> acpi0 sio0: type 16550A
> sio0: [FILTER]
> ppc0: <Parallel port> port 0x378-0x37f irq 7 on acpi0
> ppc0: Generic chipset (NIBBLE-only) in COMPATIBLE mode
> ppbus0: <Parallel port bus> on ppc0
> ppbus0: [ITHREAD]
> lpt0: <Printer> on ppbus0
> lpt0: Interrupt-driven port
> ppi0: <Parallel I/O> on ppbus0
> plip0: <PLIP network interface> on ppbus0
> plip0: WARNING: using obsoleted IFF_NEEDSGIANT flag
> ppc0: [GIANT-LOCKED]
> ppc0: [ITHREAD]
> 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
> ACPI Warning (tbutils-0243): Incorrect checksum in table [OEMB] -  45,
> should be 40 [20070320]
> coretemp0: <CPU On-Die Thermal Sensors> on cpu0
> est0: <Enhanced SpeedStep Frequency Control> on cpu0
> p4tcc0: <CPU Frequency Thermal Control> on cpu0
> cpu1: <ACPI CPU> on acpi0
> coretemp1: <CPU On-Die Thermal Sensors> on cpu1
> est1: <Enhanced SpeedStep Frequency Control> on cpu1
> est: CPU supports Enhanced Speedstep, but is not recognized.
> est: cpu_vendor GenuineIntel, msr 616492206004922
> device_attach: est1 attach returned 6
> p4tcc1: <CPU Frequency Thermal Control> on cpu1
> orm0: <ISA Option ROM> at iomem 0xc0000-0xcffff on isa0
> sc0: <System console> at flags 0x100 on isa0
> sc0: VGA <16 virtual consoles, flags=0x300>
> sio1: configured irq 3 not in bitmap of probed irqs 0
> sio1: port may not be enabled
> vga0: <Generic ISA VGA> at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0
> Timecounters tick every 1.000 msec
> IPsec: Initialized Security Association Processing.
> ad4: 239372MB <Maxtor 7Y250M0 YAR51HW0> at ata2-master SATA150
> ad7: 305245MB <Seagate ST3320620AS 3.AAK> at ata3-slave SATA300
> ad8: 610480MB <WDC WD6401AALS-00L3B2 01.03B01> at ata4-master SATA300
> GEOM_LABEL: Label for provider ad4s1a is ufsid/497cecd46b0e22e5.
> acd0: DVDR <HL-DT-STDVD-RAM GH22NS30/1.01> at ata5-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 #2: Realtek ALC888
> hdac1: hdac_command_send_internal: TIMEOUT numcmd=1, sent=1, received=0
> hdac1: hdac_command_send_internal: TIMEOUT numcmd=1, sent=1, received=0
> hdac1: Codec #3 is not responding! Probing aborted.
> pcm1: <HDA Realtek ALC888 PCM #0 Analog> at cad 2 nid 1 on hdac1
> pcm2: <HDA Realtek ALC888 PCM #1 Analog> at cad 2 nid 1 on hdac1
> pcm3: <HDA Realtek ALC888 PCM #2 Digital> at cad 2 nid 1 on hdac1
> acd0: FAILURE - INQUIRY ILLEGAL REQUEST asc=0x24 ascq=0x00
> (probe1:umass-sim0:0:0:0): TEST UNIT READY. CDB: 0 0 0 0 0 0
> (probe1:umass-sim0:0:0:0): CAM Status: SCSI Status Error
> (probe1:umass-sim0:0:0:0): SCSI Status: Check Condition
> (probe1:umass-sim0:0:0:0): UNIT ATTENTION asc:28,0
> (probe1:umass-sim0:0:0:0): Not ready to ready change, medium may have
> changed (probe1:umass-sim0:0:0:0): Retrying Command (per Sense Data)
> acd0: FAILURE - INQUIRY ILLEGAL REQUEST asc=0x24 ascq=0x00
> SMP: AP CPU #1 Launched!
> WARNING: WITNESS option enabled, expect reduced performance.
> da0 at umass-sim0 bus 0 target 0 lun 0
> da0: <JetFlash Transcend 4GB 8.07> Removable Direct Access SCSI-2 device
> da0: 40.000MB/s transfers
> da0: 3830MB (7843840 512 byte sectors: 255H 63S/T 488C)
> cd0 at ata3 bus 0 target 0 lun 0
> cd0: <HL-DT-ST DVD-RAM GH22NS30 1.01> Removable CD-ROM SCSI-0 device
> cd0: 3.300MB/s transfers
> cd0: cd present [4098336 x 2048 byte records]
> GEOM_LABEL: Label for provider acd0 is iso9660/THE_MATRIX_16X9LB_N_AMERICA.
> Trying to mount root from ufs:/dev/ad4s1a
> WARNING: / was not properly dismounted
> WARNING: reducing size to maximum of 67108864 blocks per swap unit
> GEOM_LABEL: Label ufsid/497cecd46b0e22e5 removed.
> GEOM_LABEL: Label for provider ad4s1a is ufsid/497cecd46b0e22e5.
> GEOM_LABEL: Label ufsid/497cecd46b0e22e5 removed.
> 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 6
> ZFS storage pool version 6
> lock order reversal:
>  1st 0xffffffff80e49de0 pf task mtx (pf task mtx)
> @
> /red/public/freebsd/sources/stable/sys/modules/pf/../../contrib/pf/net/pf_i
>octl.c:1394 2nd 0xffffffff80ba94c0 ifnet (ifnet)
> @ /red/public/freebsd/sources/stable/sys/net/if.c:1623
> KDB: stack backtrace:
> db_trace_self_wrapper() at db_trace_self_wrapper+0x2a
> witness_checkorder() at witness_checkorder+0x543
> _mtx_lock_flags() at _mtx_lock_flags+0x1f
> ifunit() at ifunit+0x24
> pfioctl() at pfioctl+0x2531
> devfs_ioctl_f() at devfs_ioctl_f+0x71
> kern_ioctl() at kern_ioctl+0x91
> ioctl() at ioctl+0xeb
> syscall() at syscall+0x1a5
> Xfast_syscall() at Xfast_syscall+0xab
> --- syscall (54, FreeBSD ELF64, ioctl), rip = 0x80096296c, rsp =
> 0x7fffffffdc18, rbp = 0x7fffffffdca0 ---
> kqemu version 0x00010400
> kqemu: KQEMU installed, max_locked_mem=2089448kB.
> acd0: FAILURE - READ_BIG timed out
> acd0: FAILURE - READ_BIG timed out
> acd0: FAILURE - READ_BIG timed out
> info: [drm] Setting GART location based on new memory map
> info: [drm] Loading RV635 CP Microcode
> info: [drm] Loading RV635 PFP Microcode
> info: [drm] Resetting GPU
> info: [drm] writeback test succeeded in 1 usecs
> drm0: [ITHREAD]
> acd0: FAILURE - READ_BIG timed out
> acd0: FAILURE - READ_BIG timed out
> (cd0:ata3:0:0:0): cddone: got error 0x5 back
> tap0: Ethernet address: 00:bd:d8:9b:04:00
> bridge0: Ethernet address: fa:cc:68:2e:a4:8e
> tap0: promiscuous mode enabled
> dc0: promiscuous mode enabled
>
> _______________________________________________
> freebsd-stable@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org"



-- 
-- Norbert Papke.
   npapke@acm.org
From scrappy at hub.org  Sun May 10 23:46:25 2009
From: scrappy at hub.org (Marc G. Fournier)
Date: Sun May 10 23:46:33 2009
Subject: Debugging server hangs in 7.2-RELEASE
Message-ID: <20090510203457.W17646@hub.org>


I am so completely running out of ideas on how to debug this, maybe 
someone else has some ideas?

The problem appears to be that very suddenly, the disk busy (according to 
vmstat) skyrockets to >100 (from 0) and then the 'runnable but swapped' 
column slowly rises ...

One person suggested that for them, they saw similar when msi/msi-x was 
enabled ... after searching the source code, I found that msi was used in 
the bge driver, but I couldn't find msix used anywhere else on that 
machine, so disabled msi ... its still exhibiting the issue ...

I get no errors on the serial console to indicate any problems, and until 
a relatively recent upgrade of the kernel ( (I can't give an exact date), 
this server was one of my most solid ...

I figure there is a single process that is starting up on the machine that 
is causing this, but no matter what I try, it is eluding me.

I have KDB enabled in the kernel, and the serial console setup so that I 
can break to it ... but when this problem happens, doing 'cr ~ ^b' through 
the serial console doesn't do anything, or, it just prints the message 
about breaking to the debugger and then hangs there ...

My next option is to start time travelling backwards to see if I can find 
a 'stable kernel' again, but if it is just one process causing this, then 
going back to older kernels isn't necessarily going to accomplish anything 
...

Is there something else I can do here to debug this?  Its hard to believe 
we are such an advance OS, but debugging issues like this is so elusive :(



----
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 dougb at FreeBSD.org  Mon May 11 04:47:08 2009
From: dougb at FreeBSD.org (Doug Barton)
Date: Mon May 11 04:47:14 2009
Subject: Mergemaster
In-Reply-To: <1BA7DBA9-3C49-490A-B97C-DEB08DF2F696@lafn.org>
References: <1BA7DBA9-3C49-490A-B97C-DEB08DF2F696@lafn.org>
Message-ID: <4A07ADC4.6060209@FreeBSD.org>

Doug Hardie wrote:
> I have been following the discussion on mergemaster and one item is a
> bit annoying.  You can use -U in the command args which sets
> "AUTO_UPGRADE=yes". 

So far so good.

> That flag is not in mergemaster.rc. 

I'm not sure what that is supposed to mean. There is no rc file by
default, you have to create it. If what you mean is that it wasn't
mentioned in the man page, that has been fixed for a while now.

> It could be
> easily added to the rc file, but I suspect it would conflict with -p. 

It would not conflict with it, in fact if everything is working as it
should it should be totally safe.

> Hence it seems like if "unset AUTO_UPGRADE" were added to the -p section
> then it would work. 

I try hard not to outthink what the user is trying to do, which of
course works both ways.

> It would be helpful to be able to include it in the
> rc file so I don't have to remember the options each time.

[ -z "$PRE_WORLD" ] && AUTO_UPGRADE=yes


hth,

Doug
From dougb at FreeBSD.org  Mon May 11 04:49:29 2009
From: dougb at FreeBSD.org (Doug Barton)
Date: Mon May 11 04:49:50 2009
Subject: RELENG_7 - has mergemaster changed logic since 7.2-RELEASE?
In-Reply-To: <20090506184500.70b2c6f2.torfinn.ingolfsen@broadpark.no>
References: <20090504225012.392fa49f.torfinn.ingolfsen@broadpark.no>	<4A00AF76.8010604@FreeBSD.org>
	<20090506184500.70b2c6f2.torfinn.ingolfsen@broadpark.no>
Message-ID: <4A07AE53.4080104@FreeBSD.org>

Torfinn Ingolfsen wrote:
> To be clear, I follow this procedure:
> 1. make buildworld
> 2. make kernel
> 3. shutdown now
> 4. mergemaster -p
> 5. make installworld
> 6. mergemaster -iU
> 7. fastboot

By any chance is any of this happening in a jail? Or by any chance is
/etc a symlink? A user sent me a very interesting patch related to the
use of -U in a jail that might be relevant here.


Doug
From graham at menhennitt.com.au  Mon May 11 06:20:38 2009
From: graham at menhennitt.com.au (Graham Menhennitt)
Date: Mon May 11 06:20:45 2009
Subject: failure building nanobsd with FreeBSD Stable
Message-ID: <4A07BDFB.1000609@menhennitt.com.au>

Hello all,

I've been building nanobsd to run on my Soekris net4801 for some time 
now. I recently csupped to FreeBSD Stable and I can no longer build it. 
It gives an error early in "installworld" (see below).

Does anybody please have any clues?

Thanks,
     Graham

mkdir -p /tmp/install.1JDmZzZe
for prog in [ awk cap_mkdb cat chflags chmod chown  date echo egrep find
grep
ln lockf make mkdir mtree mv pwd_mkdb rm sed sh sysctl  test true uname
wc zic;
do  cp `which $prog` /tmp/install.1JDmZzZe;  done
cd /usr/src; MAKEOBJDIRPREFIX=/usr/obj/nanobsd.maxwell/
MACHINE_ARCH=i386  MACH
INE=i386  CPUTYPE=
GROFF_BIN_PATH=/usr/obj/nanobsd.maxwell//usr/src/tmp/legacy/
usr/bin
GROFF_FONT_PATH=/usr/obj/nanobsd.maxwell//usr/src/tmp/legacy/usr/share/
groff_font
GROFF_TMAC_PATH=/usr/obj/nanobsd.maxwell//usr/src/tmp/legacy/usr/sha
re/tmac
PATH=/usr/obj/nanobsd.maxwell//usr/src/tmp/legacy/usr/sbin:/usr/obj/nan
obsd.maxwell//usr/src/tmp/legacy/usr/bin:/usr/obj/nanobsd.maxwell//usr/src/tmp/l
egacy/usr/games:/usr/obj/nanobsd.maxwell//usr/src/tmp/usr/sbin:/usr/obj/nanobsd.
maxwell//usr/src/tmp/usr/bin:/usr/obj/nanobsd.maxwell//usr/src/tmp/usr/games:/tm
p/install.1JDmZzZe make -f Makefile.inc1 reinstall
--------------------------------------------------------------
  >>> Making hierarchy
--------------------------------------------------------------
cd /usr/src; make -f Makefile.inc1 hierarchy
cd /usr/src/etc;                make distrib-dirs
mtree -eU  -f /usr/src/etc/mtree/BSD.root.dist -p
/usr/obj/nanobsd.maxwell//_.w/
./bin missing (created)
./boot missing (created)
./boot/defaults missing (created)
./boot/firmware missing (created)
...skipping...
   rm -f
/usr/obj/nanobsd.maxwell//_.w/usr/include/security/mac_partition;  fi
if [ -L /usr/obj/nanobsd.maxwell//_.w/usr/include/ufs/ffs ]; then  rm -f
/usr/ob
j/nanobsd.maxwell//_.w/usr/include/ufs/ffs;  fi
if [ -L /usr/obj/nanobsd.maxwell//_.w/usr/include/ufs/ufs ]; then  rm -f
/usr/ob
j/nanobsd.maxwell//_.w/usr/include/ufs/ufs;  fi
if [ -L /usr/obj/nanobsd.maxwell//_.w/usr/include/machine ]; then  rm -f
/usr/ob
j/nanobsd.maxwell//_.w/usr/include/machine;  fi
if [ -L /usr/obj/nanobsd.maxwell//_.w/usr/include/crypto ]; then  rm -f
/usr/obj
/nanobsd.maxwell//_.w/usr/include/crypto;  fi
mtree -deU   -f /usr/src/include/../etc/mtree/BSD.include.dist  -p
/usr/obj/nano
bsd.maxwell//_.w/usr/include
creating osreldate.h from newvers.sh
touch: not found
*** Error code 127
1 error
*** Error code 2
1 error
*** Error code 2
1 error
*** Error code 2
1 error
*** Error code 2
1 error

From torfinn.ingolfsen at broadpark.no  Mon May 11 07:15:22 2009
From: torfinn.ingolfsen at broadpark.no (Torfinn Ingolfsen)
Date: Mon May 11 07:15:30 2009
Subject: RELENG_7 - has mergemaster changed logic since 7.2-RELEASE?
In-Reply-To: <4A07AE53.4080104@FreeBSD.org>
References: <20090504225012.392fa49f.torfinn.ingolfsen@broadpark.no>
	<4A00AF76.8010604@FreeBSD.org>
	<20090506184500.70b2c6f2.torfinn.ingolfsen@broadpark.no>
	<4A07AE53.4080104@FreeBSD.org>
Message-ID: <20090511091520.37733043.torfinn.ingolfsen@broadpark.no>

On Sun, 10 May 2009 21:49:23 -0700
Doug Barton <dougb@FreeBSD.org> wrote:

> Torfinn Ingolfsen wrote:
> > To be clear, I follow this procedure:
> > 1. make buildworld
> > 2. make kernel
> > 3. shutdown now
> > 4. mergemaster -p
> > 5. make installworld
> > 6. mergemaster -iU
> > 7. fastboot
> 
> By any chance is any of this happening in a jail?

No - no jails.

> Or by any chance is  /etc a symlink?

No, /etc is a regular directory (I just checked the machines).
-- 
Regards,
Torfinn Ingolfsen

From gerrit at pmp.uni-hannover.de  Mon May 11 10:53:03 2009
From: gerrit at pmp.uni-hannover.de (Gerrit =?ISO-8859-1?Q?K=FChn?=)
Date: Mon May 11 10:53:10 2009
Subject: zfs: dataset is busy
Message-ID: <20090511123247.b22c0127.gerrit@pmp.uni-hannover.de>

Hi all,

I have several machines here that do automatic snapshotting via RSEs
snapshot-tool (sysutils/freebsd-snapshot). I use a homemade script to
incrementally transfer daily snapshots to a backup server. This runs fine
with machines running 7.0-STABLE of Jun 08.
However, I have one box with 7.1-PRERELEASE from Sep 08 showing the
following error after some time (when trying to rotate the snapshots via
the freebsd-snapshot tool):

cannot destroy 'tank/www@daily.6': dataset is busy


I fact I cannot do anything to the snapshot, neither destroy nor export
(not even with "-f"), it is always "busy". The only chance to get away
from this I found is to reboot the machine. After a reboot it is fine for
some weeks, but then comes back with the same problem.

Has anyone seen this before? Is there a fix or workaround available? Are
there any improvements I could take profit of by upgrading to 7.2-stable?
Right now the machine is in this state, so I could get some more
information from it (if anyone tells me what to do :-).


cu
  Gerrit
From hpcharles at gmail.com  Mon May 11 10:57:46 2009
From: hpcharles at gmail.com (Henri-Pierre Charles)
Date: Mon May 11 10:57:53 2009
Subject: EEEPC and FreeBSD 7.2
In-Reply-To: <200905081147.46736.david.marec@davenulle.org>
References: <200905081147.46736.david.marec@davenulle.org>
Message-ID: <4734a3ed0905110335k763bd7cbh7af572b358ce69ab@mail.gmail.com>

Hello,

On Fri, May 8, 2009 at 11:47 AM, David Marec <david.marec@davenulle.org> wrote:
> I am trying to use an EEEPC 701 as a diskless station, running FreeBSD 7.

Great mini machine !

> The EEPC station boots well with PXE then runs the kernel, but the only
> network card that is recognized is the wireless one (ath0).
>
> I read that the wired NIC ( ae? ) has been committed to HEAD; is there any way
> to make it work on 7-STABLE ?

It works out of the box with 7.2

You hust have to add if_ae_load="YES" in your /boot/loader.conf

H-P

-- 
HPC
From bsam at ipt.ru  Mon May 11 12:07:44 2009
From: bsam at ipt.ru (Boris Samorodov)
Date: Mon May 11 12:07:56 2009
Subject: failure building nanobsd with FreeBSD Stable
In-Reply-To: <4A07BDFB.1000609@menhennitt.com.au> (Graham Menhennitt's message
	of "Mon\, 11 May 2009 15\:56\:11 +1000")
References: <4A07BDFB.1000609@menhennitt.com.au>
Message-ID: <03279835@bb.ipt.ru>

On Mon, 11 May 2009 15:56:11 +1000 Graham Menhennitt wrote:

> touch: not found

Please check it the system time was changed between
c(v)sup -> buildworld. I case yes, just redo the process.


WBR
-- 
Boris Samorodov (bsam)
Research Engineer, http://www.ipt.ru Telephone & Internet SP
FreeBSD Committer, http://www.FreeBSD.org The Power To Serve
From jhb at freebsd.org  Mon May 11 16:49:38 2009
From: jhb at freebsd.org (John Baldwin)
Date: Mon May 11 16:50:32 2009
Subject: lock up in 6.2 (procs massively stuck in Giant)
In-Reply-To: <a31046fc0905042041kdfcfa85u38e84db5197c929c@mail.gmail.com>
References: <a31046fc0904292336w17aca317hefd32dad5bc28007@mail.gmail.com>
	<200905010949.45927.jhb@freebsd.org>
	<a31046fc0905042041kdfcfa85u38e84db5197c929c@mail.gmail.com>
Message-ID: <200905110949.31142.jhb@freebsd.org>

On Monday 04 May 2009 11:41:35 pm pluknet wrote:
> 2009/5/1 John Baldwin <jhb@freebsd.org>:
> > On Thursday 30 April 2009 2:36:34 am pluknet wrote:
> >> Hi folks.
> >>
> >> Today I got a new locking issue.
> >> This is the first time I got it, and it's merely reproduced.
> >>
> >> The box has lost both remote connection and local access.
> >> No SIGINFO output on the local console even.
> >> Jumping in ddb> shows the next:
> >>
> >> 1) first, this is a 8-way web server. No processes on runqueue except one
> > httpd
> >> (i.e. ps shows R in its state):
> >
> > You need to find who owns Giant and what that thread is doing.  You can 
try
> > using 'show lock Giant' as well as 'show lockchain 11568'.
> >
> 
> Hi, John!
> 
> Just reproduced now on another box.
> Hmm.. stack of the process owing Giant looks garbled.
> 
> db> show lock Giant
>  class: sleep mutex
>  name: Giant
>  flags: {DEF, RECURSE}
>  state: {OWNED, CONTESTED}
>  owner: 0xd0d79320 (tid 102754, pid 34594, "httpd")
> 
> db> show lockchain 34594
> thread 102754 (pid 34594, httpd) running on CPU 7
> db> show lockchain 102754
> thread 102754 (pid 34594, httpd) running on CPU 7

The thread is running, so we don't know what it's top of stack is and you 
can't a good stack trace in that case.

None of your CPUs are idle, so I don't think you have any sort of deadlock.  
You might have a livelock.

-- 
John Baldwin
From jhb at freebsd.org  Mon May 11 16:49:39 2009
From: jhb at freebsd.org (John Baldwin)
Date: Mon May 11 16:50:33 2009
Subject: Garbled output from kgdb?
In-Reply-To: <200905051743.03520.jkim@FreeBSD.org>
References: <49F8B859.7060908@umn.edu> <200905051609.38689.jkim@FreeBSD.org>
	<200905051743.03520.jkim@FreeBSD.org>
Message-ID: <200905110952.01736.jhb@freebsd.org>

On Tuesday 05 May 2009 5:43:01 pm Jung-uk Kim wrote:
> On Tuesday 05 May 2009 04:09 pm, Jung-uk Kim wrote:
> > On Tuesday 05 May 2009 12:51 pm, Andriy Gapon wrote:
> > > BTW, this issue seems to be fixed in Jung-uk's acpi patches for
> > > newer acpica imports, but it is not fixed both in stable/7 and
> > > head.
> >
> > Yes, it was fixed in my patchsets long ago, which uses spin lock
> > for AcpiOsAcquireLock(). :-)
> 
> The attached patch is for -STABLE.  Note that it is only compile 
> tested on amd64.

This looks fine to test.  The patch has gratuitous style changes I wouldn't 
include in a commit though.

-- 
John Baldwin
From jhb at freebsd.org  Mon May 11 16:49:39 2009
From: jhb at freebsd.org (John Baldwin)
Date: Mon May 11 16:50:42 2009
Subject: kern/130330: [mpt] [panic] Panic and reboot machine MPT ...
In-Reply-To: <20090507155012.GW21112@tiger.fi.esaote.it>
References: <20090507155012.GW21112@tiger.fi.esaote.it>
Message-ID: <200905110953.21686.jhb@freebsd.org>

On Thursday 07 May 2009 11:50:12 am Riccardo Torrini wrote:
> I just submitted a follow-up to PR kern/130330 with the same
> info.  Maybe I found the committed lines doing the crash.
> 
> Please see PR for more detailed info (and cc: this thread to me).
> 
> I restricted the time window of the problem doing (a lot of)
> build&install world from 2008.07 up to now (read last week).
> 
> With 2008.07.28.17.00.00 (7.0-STABLE) works fine but
> with 2008.07.28.18.00.00 start crashing removing the
> the second disk of a mirror (when the mirror is ok)
> or adding the second disk of a degraded ones.
> 
> Also note that the same crash happens with all 7.1
> stable or release and even all 7.2-PRE I tested.
> 
> (wrapping long lines)
> # cd /home/ncvs/src/sys/
> # grep -R "date.*2008\.07\.28\.17" ./ | grep -v /Attic
> 
> ./dev/wi/if_wi.c,v:
>         date    2008.07.28.17.00.37;    author imp;     state Exp;
> ./dev/wi/if_wivar.h,v:
>         date    2008.07.28.17.00.37;    author imp;     state Exp;
> ./dev/mpt/mpt_raid.c,v:
>         date    2008.07.28.17.10.09;    author jhb;     state Exp;
> ./dev/mpt/mpt_raid.c,v:
>         date    2008.07.28.17.05.09;    author jhb;     state Exp;
> ./kern/sched_4bsd.c,v:
>         date    2008.07.28.17.25.24;    author jhb;     state Exp;
> ./modules/et/Makefile,v:
>         date    2008.07.28.17.56.37;    author antoine; state Exp;
> 
> In that time window there are only 4 file changed in
> src/sys/dev, and I bet to mpt_raid.c  :-)
> 
> This is the commit log extracted from cvsweb
> -----8<-----
> Revision 1.15.2.1:
> Mon Jul 28 17:05:09 2008 UTC (9 months, 1 week ago) by jhb
> Branches: RELENG_7
> CVS tags: RELENG_7_1_BP
> Branch point for: RELENG_7_1
> Diff to: previous 1.15: preferred, colored
> Changes since revision 1.15: +4 -4 lines
> 
> SVN rev 180920 on 2008-07-28 17:05:09Z by jhb
> 
> MFC: Allocate a single CCB at the start of the main loop of the RAID
> monitoring kthread of the mpt(4) driver.
> -----8<-----
> 
> Here are the diff:
> 
http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/mpt/mpt_raid.c.diff?r1=1.15;r2=1.15.2.1
> 
> 
> What can I do now?

Can you get more details on the crash, perhaps a crash dump?

-- 
John Baldwin
From jhb at freebsd.org  Mon May 11 16:49:43 2009
From: jhb at freebsd.org (John Baldwin)
Date: Mon May 11 16:51:06 2009
Subject: 7.1-STABLE Sun Mar 29 01:06:46 ADT 2009 Locks up ...
In-Reply-To: <20090509193937.T10574@hub.org>
References: <A98FF8D3-1486-43D4-8EE6-50F8C3DACCA1@uos.de>
	<1240920035.85945.7.camel@buffy.york.ac.uk>
	<20090509193937.T10574@hub.org>
Message-ID: <200905111242.44566.jhb@freebsd.org>

On Saturday 09 May 2009 6:43:16 pm Marc G. Fournier wrote:
> On Tue, 28 Apr 2009, Gavin Atkinson wrote:
> 
> > On Fri, 2009-04-24 at 20:39 +0200, Martin Schmidt wrote:
> >> Hi Marc and List,
> >>
> >> i had similar issues with FreeBSD 7.2-PRERELEASE. Server (zfs,nfs)
> >> seems to hang in intervals of about 8 hours.
> >> kernel is still there but no connections can be made to nfs/ssh and
> >> login on local console doesn't seem to
> >> work due to incredible slowness. breaking to the debugger takes a
> >> moment but works.
> >> (compiling kernel with WITNESS didnt help)
> >>
> >> the server had been solid before with 7 stable kernel from around 19
> >> October 2008.
> >>
> >> I now added these lines to /boot/loader.conf
> >>
> >> hw.pci.enable_msi=0
> >> hw.pci.enable_msix=0
> >>
> >> to disable Message Signaled Interrupts. Which are used by the 3ware
> >> twa driver and igb network driver on our server.
> >
> > If you are willing to test further on your server, it may be helpful if
> > you could determine which of those two lines in loader.conf fixes the
> > problem for you.  It would also be useful to provide a dmesg from the
> > machine when both msi and msix are enabled.
> >
> > FWIW, looking at the "vmstat -i" output it appears that only the igb
> > driver that are using MSI/MSIX, unless you have a reason to suspect
> > otherwise?
> 
> How do you tell that, about igb?  looking at the server I have the igb 
> device on, it doesn't seem to say anything about that ...

IRQs > 256 are MSI/MSI-X.

-- 
John Baldwin
From jhb at freebsd.org  Mon May 11 16:49:45 2009
From: jhb at freebsd.org (John Baldwin)
Date: Mon May 11 16:51:07 2009
Subject: devd doesn't fire event on boot
In-Reply-To: <op.uth57o1x8527sy@82-170-177-25.ip.telfort.nl>
References: <op.uth57o1x8527sy@82-170-177-25.ip.telfort.nl>
Message-ID: <200905111248.02724.jhb@freebsd.org>

On Wednesday 06 May 2009 6:03:14 am Ronald Klop wrote:
> Hello,
> 
> Running 7.2-STABLE/amd64. I have a USB-disk and added stuff to devd to  
> mount it readonly on attach. This does work if I attach it after booting  
> up, but not if it is attached before booting.

devd throws away all events that happen prior to devd starting up I think.

-- 
John Baldwin
From jhb at freebsd.org  Mon May 11 16:49:46 2009
From: jhb at freebsd.org (John Baldwin)
Date: Mon May 11 16:51:10 2009
Subject: RELENG_7 fatal trap
In-Reply-To: <4A02D708.3040805@vl.ru>
References: <4A02D708.3040805@vl.ru>
Message-ID: <200905111248.41619.jhb@freebsd.org>

On Thursday 07 May 2009 8:41:44 am Alexander Kriventsov wrote:
> Hi,
> Sorry for my english.
> I have fatal trap on my box.
> Kernel compiled with debug options. System is RELENG_7 amd64 dated 
> 2009-04-14.

I think this is fixed in the latest RELENG_7.

-- 
John Baldwin
From riccardo.torrini at esaote.com  Mon May 11 16:55:26 2009
From: riccardo.torrini at esaote.com (Riccardo Torrini)
Date: Mon May 11 16:55:34 2009
Subject: kern/130330: [mpt] [panic] Panic and reboot machine MPT ...
In-Reply-To: <200905110953.21686.jhb@freebsd.org>
References: <20090507155012.GW21112@tiger.fi.esaote.it>
	<200905110953.21686.jhb@freebsd.org>
Message-ID: <20090511165522.GG21112@tiger.fi.esaote.it>

On Mon, May 11, 2009 at 09:53:21AM -0400, John Baldwin wrote:

>> What can I do now?

> Can you get more details on the crash, perhaps a crash dump?

All what you want, but you need to drive me, I was unable
to setup serial/debug console so I must wrote down by hand
(followed handbook, tryed all speed/duplex pairs, still
having "graphics" strange chars, maybe the cable or setup).

Using a kernel with all know (to me) debug knobs enabled  :-)


-- 
Riccardo.
From jkim at FreeBSD.org  Mon May 11 17:45:42 2009
From: jkim at FreeBSD.org (Jung-uk Kim)
Date: Mon May 11 17:45:49 2009
Subject: Garbled output from kgdb?
In-Reply-To: <200905110952.01736.jhb@freebsd.org>
References: <49F8B859.7060908@umn.edu> <200905051743.03520.jkim@FreeBSD.org>
	<200905110952.01736.jhb@freebsd.org>
Message-ID: <200905111345.29761.jkim@FreeBSD.org>

On Monday 11 May 2009 09:52 am, John Baldwin wrote:
> On Tuesday 05 May 2009 5:43:01 pm Jung-uk Kim wrote:
> > On Tuesday 05 May 2009 04:09 pm, Jung-uk Kim wrote:
> > > On Tuesday 05 May 2009 12:51 pm, Andriy Gapon wrote:
> > > > BTW, this issue seems to be fixed in Jung-uk's acpi patches
> > > > for newer acpica imports, but it is not fixed both in
> > > > stable/7 and head.
> > >
> > > Yes, it was fixed in my patchsets long ago, which uses spin
> > > lock for AcpiOsAcquireLock(). :-)
> >
> > The attached patch is for -STABLE.  Note that it is only compile
> > tested on amd64.
>
> This looks fine to test.  The patch has gratuitous style changes I
> wouldn't include in a commit though.

It should work but I don't plan to commit it any time soon. :-) In 
fact, the patch was meant to be a rewrite for new ACPI-CA, which 
actually has a real mutex.  Currently, mutex is emulated with 
semaphore.  The problem is semaphore has no concept of ownership 
while mutex does, i.e., any thread can acquire/release it without 
checking its ownership or order.  FYI, the OSL API (ACPI_MUTEX_TYPE) 
is finalized in ACPI-CA 20081204.

Jung-uk Kim
From jhb at freebsd.org  Mon May 11 18:25:09 2009
From: jhb at freebsd.org (John Baldwin)
Date: Mon May 11 18:25:20 2009
Subject: kern/130330: [mpt] [panic] Panic and reboot machine MPT ...
In-Reply-To: <20090511165522.GG21112@tiger.fi.esaote.it>
References: <20090507155012.GW21112@tiger.fi.esaote.it>
	<200905110953.21686.jhb@freebsd.org>
	<20090511165522.GG21112@tiger.fi.esaote.it>
Message-ID: <200905111407.20195.jhb@freebsd.org>

On Monday 11 May 2009 12:55:22 pm Riccardo Torrini wrote:
> On Mon, May 11, 2009 at 09:53:21AM -0400, John Baldwin wrote:
> 
> >> What can I do now?
> 
> > Can you get more details on the crash, perhaps a crash dump?
> 
> All what you want, but you need to drive me, I was unable
> to setup serial/debug console so I must wrote down by hand
> (followed handbook, tryed all speed/duplex pairs, still
> having "graphics" strange chars, maybe the cable or setup).
> 
> Using a kernel with all know (to me) debug knobs enabled  :-)

Do you have kernel crashdumps enabled and a swap partition?  If so, do you 
happen to have any files in /var/crash?

-- 
John Baldwin
From jchambers at ucla.edu  Mon May 11 20:08:14 2009
From: jchambers at ucla.edu (Jason Chambers)
Date: Mon May 11 20:08:21 2009
Subject: ipfilter seems to be broken on 7.2-PRERELEASE as of April 25:th
 2009.
In-Reply-To: <196E4005-25E9-4C46-99BD-8F717849703F@jongel.net>
References: <196E4005-25E9-4C46-99BD-8F717849703F@jongel.net>
Message-ID: <4A088592.9070305@ucla.edu>

Jonas B?low wrote:
>
> After reboot it was not reachable from the network. After some
> troubleshooting I found that ipfilter seems to be the problem. Returning
> traffic originating from my host  (XXX) is blocked:
> 
(... snip ...)
> 
> Anyone seen this behaviour?
> 

Yes.  This appears to have made it to the RELEASE as well.

I believe it is due to updates to the FXP driver that allow checksumming
for tx/rx.  My guess is checksumming is enabled by default and you (and
I) happen to have the cards recognized by FXP that do not support it.
(The BAD in the ipf log represents bad checksum)

If you do "ifconfig fxp0 -txcsum -rxcsum" your problem should go away.
For /etc/rc.conf, just add -txcsum -rxcsum to the interface definition.

Regards,

--Jason

From david.marec at davenulle.org  Mon May 11 20:29:38 2009
From: david.marec at davenulle.org (David Marec)
Date: Mon May 11 20:29:48 2009
Subject: EEEPC and FreeBSD 7.2
In-Reply-To: <4734a3ed0905110335k763bd7cbh7af572b358ce69ab@mail.gmail.com>
References: <200905081147.46736.david.marec@davenulle.org>
	<4734a3ed0905110335k763bd7cbh7af572b358ce69ab@mail.gmail.com>
Message-ID: <200905112229.35432.david.marec@davenulle.org>

Le Monday 11 May 2009 12:35:13 Henri-Pierre Charles, vous avez ?crit?:
> Hello,
>
> On Fri, May 8, 2009 at 11:47 AM, David Marec <david.marec@davenulle.org> 
wrote:
> > I am trying to use an EEEPC 701 as a diskless station, running FreeBSD 7.
>
> Great mini machine !

I agree. This one is owned by my wife, who does not want to change the system 
that was shipped with it ( Xandros).

> > The EEPC station boots well with PXE then runs the kernel, but the only
> > network card that is recognized is the wireless one (ath0).
> >
> > I read that the wired NIC ( ae? ) has been committed to HEAD; is there
> > any way to make it work on 7-STABLE ?
>
> It works out of the box with 7.2
>
> You hust have to add if_ae_load="YES" in your /boot/loader.conf

I built a kernel that included this driver and the EEEPC is now working quite 
well as a diskless station.
But i have to launch Xorg locally.

It doesn't start on XDMCP mode and i didn't found yet what is wrong with this. 

/I think  i will start another thread on a Xorg dedicated list about this 
point and the touchpad configuration./

-- 
http://david.marec.free.fr/
http://www.freebsd.org/fr/	http://www.diablotins.org/
From gamato at users.sf.net  Mon May 11 22:05:56 2009
From: gamato at users.sf.net (martinko)
Date: Mon May 11 22:06:03 2009
Subject: run_interrupt_driven_hooks: still waiting after 300 seconds for
	xpt_config
Message-ID: <4A08A132.3070503@users.sf.net>

Hallo,

I've just tried 7.2-RELEASE (amd64) on Asus M3A78-EM motherboard and 
booting got stuck with the following:

run_interrupt_driven_hooks: still waiting after 300 seconds for xpt_config

 From what I've found via Google it should be fixed already but 
apparently it is not. :-(

Is there a way to work around this issue and successfully boot and 
install FreeBSD, please ?

Thanks,

Martin

From dnelson at allantgroup.com  Mon May 11 23:14:25 2009
From: dnelson at allantgroup.com (Dan Nelson)
Date: Mon May 11 23:14:32 2009
Subject: run_interrupt_driven_hooks: still waiting after 300 seconds
	for xpt_config
In-Reply-To: <4A08A132.3070503@users.sf.net>
References: <4A08A132.3070503@users.sf.net>
Message-ID: <20090511224957.GB52703@dan.emsphone.com>

In the last episode (May 12), martinko said:
> I've just tried 7.2-RELEASE (amd64) on Asus M3A78-EM motherboard and
> booting got stuck with the following:
> 
> run_interrupt_driven_hooks: still waiting after 300 seconds for xpt_config
> 
> From what I've found via Google it should be fixed already but apparently
> it is not.  :-(
> 
> Is there a way to work around this issue and successfully boot and install
> FreeBSD, please ?

Do you have a connected firewire device?  Try unplugging it during bootup,
or kldload the sbp module after bootup instead of via loader.conf.

-- 
	Dan Nelson
	dnelson@allantgroup.com
From pyunyh at gmail.com  Tue May 12 00:49:00 2009
From: pyunyh at gmail.com (Pyun YongHyeon)
Date: Tue May 12 00:49:07 2009
Subject: ipfilter seems to be broken on 7.2-PRERELEASE as of April 25:th
	2009.
In-Reply-To: <4A088592.9070305@ucla.edu>
References: <196E4005-25E9-4C46-99BD-8F717849703F@jongel.net>
	<4A088592.9070305@ucla.edu>
Message-ID: <20090512005707.GI65350@michelle.cdnetworks.co.kr>

On Mon, May 11, 2009 at 01:07:46PM -0700, Jason Chambers wrote:
> Jonas B?low wrote:
> >
> > After reboot it was not reachable from the network. After some
> > troubleshooting I found that ipfilter seems to be the problem. Returning
> > traffic originating from my host  (XXX) is blocked:
> > 
> (... snip ...)
> > 
> > Anyone seen this behaviour?
> > 
> 
> Yes.  This appears to have made it to the RELEASE as well.
> 
> I believe it is due to updates to the FXP driver that allow checksumming
> for tx/rx.  My guess is checksumming is enabled by default and you (and
> I) happen to have the cards recognized by FXP that do not support it.

I guess your controller is 82559 or compatibles. If you can receive
packets without problems after disabling ipfilter it's not fault of
fxp(4). You have a good controller that do support Rx checksum
offloading.

> (The BAD in the ipf log represents bad checksum)
> 

No, ipfilter's notion of Rx checksum offloading was broken.
ipfilter simply does not understand partial checksummed frame(e.g.
checksummed frame without pseudo header) so driver that supports
this type of checksum offloading(gem(4), hme(4), sk(4) and fxp(4))
wouldn't work on ipfilter.

> If you do "ifconfig fxp0 -txcsum -rxcsum" your problem should go away.
> For /etc/rc.conf, just add -txcsum -rxcsum to the interface definition.
> 

Yeah, that would fix it or you can switch to pf(4).
From fj at panix.com  Tue May 12 02:02:57 2009
From: fj at panix.com (Joe A.)
Date: Tue May 12 02:03:06 2009
Subject: Error message: run_interrupt_driven_hooks:...
Message-ID: <20090512014733.GA12271@panix.com>

Greetings...

Basic data on my experience with the xpt_config hang; I have more
detail if needed, but I doubt anyone will believe it. I'm not even
sure I do.

Some other reports:

http://lists.freebsd.org/pipermail/freebsd-questions/2009-April/196116.html
Seur Bors Thu Apr 9 14:43:34 UTC 2009.

http://lists.freebsd.org/pipermail/freebsd-stable/2009-May/049901.html
martinko gamato Mon May 11 22:05:56 UTC 2009

http://www.nabble.com/Freebsd-7.2-RC-boot-problem-tt23257632.html#a23257632

http://forums.pcbsd.org/viewtopic.php?f=1&t=13312

Here is the entire error for me during boot:

run_interrupt_driven_hooks: still waiting after BIGNUM seconds for xpt_config

It hangs after this point in the boot process:

pcm0: <HDA Codec: Realtek ALC885>
pcm0: <HDA Driver Revision: 20080420_0052>

the boot process does not continue, so the next normal thing does not
appear on the console:

SMP: AP CPU #1 Launched!

but during the hang, this scrolls past (punctuated by the BIGNUM
seconds wait) over and over on the console:

acpi_tz0: _TMP value is absurd, ignored (-269.4C)

Normally, that message is suppressed by this /etc/sysctl.conf entry:

hw.acpi.thermal.polling_rate=0

I suppose this means that /etc/sysctl.conf is not parsed and the
second CPU is not launched.

Hardware in question, as seen by dmesg, is attached; the vendor's
specs are:

Core 2 Duo (C) E6400 2.13 GHz 1066 MHz front side bus Socket 775
Chipset P965
Motherboard: Asus P5BW-LA
HP/Compaq motherboard name: Basswood-UL8E

There is RAID on the motherboard; I don't use it. I do use AHCI. BIOS
is current; there are no available updates. The onboard firewire is
disabled, since it began (prior to 7.1) causing unresolvable panics.

CAM is in my kernel:

# SCSI peripherals
#Added atapicam; apparently, cdparanoia requires it.
device          atapicam
device          scbus           # SCSI bus (required for SCSI)
device          da              # Direct Access (disks)
device          sa              # Sequential Access (tape etc)
device          cd              # CD
device          pass            # Passthrough device (direct SCSI access)

As of 9:30 PM EDT May 11, the issue has de-Heisenberged from my PC.

I'm not subscribed to the list; so you'll need to Cc: me if you think
I can help.
-------------- next part --------------
Copyright (c) 1992-2009 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
	The Regents of the University of California. All rights reserved.
FreeBSD is a registered trademark of The FreeBSD Foundation.
FreeBSD 7.1-RELEASE-p5 #0: Sun May  3 06:43:50 EDT 2009
    root@whisperer.chthonixia.net:/usr/obj/usr/src/sys/WHISPERER
Timecounter "i8254" frequency 1193182 Hz quality 0
CPU: Intel(R) Core(TM)2 CPU          6400  @ 2.13GHz (2135.55-MHz 686-class CPU)
  Origin = "GenuineIntel"  Id = 0x6f6  Stepping = 6
  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=0xe3bd<SSE3,DTES64,MON,DS_CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM>
  AMD Features=0x20000000<LM>
  AMD Features2=0x1<LAHF>
  Cores per package: 2
real memory  = 2146299904 (2046 MB)
avail memory = 2094936064 (1997 MB)
ACPI APIC Table: <HP-CPC ASUSACPI>
FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs
 cpu0 (BSP): APIC ID:  0
 cpu1 (AP): APIC ID:  1
ioapic0: Changing APIC ID to 4
ioapic0 <Version 2.0> irqs 0-23 on motherboard
kbd1 at kbdmux0
ath_hal: 0.9.20.3 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413)
acpi0: <HP-CPC ASUSACPI> on motherboard
acpi0: [ITHREAD]
acpi0: Power Button (fixed)
acpi0: reservation of 0, a0000 (3) failed
acpi0: reservation of 100000, 7fde0000 (3) failed
Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000
acpi_timer0: <24-bit timer at 3.579545MHz> port 0x408-0x40b on acpi0
acpi_hpet0: <High Precision Event Timer> iomem 0xfed00000-0xfed003ff on acpi0
device_attach: acpi_hpet0 attach returned 12
acpi_button0: <Power Button> on acpi0
pcib0: <ACPI Host-PCI bridge> port 0xcf8-0xcff on acpi0
pci0: <ACPI PCI bus> on pcib0
pcib1: <PCI-PCI bridge> irq 16 at device 1.0 on pci0
pci1: <PCI bus> on pcib1
vgapci0: <VGA-compatible display> port 0xde00-0xdeff mem 0xe0000000-0xefffffff,0xfddf0000-0xfddfffff irq 16 at device 0.0 on pci1
vgapci1: <VGA-compatible display> mem 0xfdde0000-0xfddeffff at device 0.1 on pci1
uhci0: <Intel 82801H (ICH8) USB controller USB-D> port 0xff00-0xff1f irq 21 at device 26.0 on pci0
uhci0: [GIANT-LOCKED]
uhci0: [ITHREAD]
usb0: <Intel 82801H (ICH8) USB controller USB-D> 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 82801H (ICH8) USB controller USB-E> port 0xfe00-0xfe1f irq 18 at device 26.1 on pci0
uhci1: [GIANT-LOCKED]
uhci1: [ITHREAD]
usb1: <Intel 82801H (ICH8) USB controller USB-E> 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
ehci0: <Intel 82801H (ICH8) USB 2.0 controller USB2-B> mem 0xfdfff000-0xfdfff3ff irq 21 at device 26.7 on pci0
ehci0: [GIANT-LOCKED]
ehci0: [ITHREAD]
usb2: EHCI version 1.0
usb2: companion controllers, 2 ports each: usb0 usb1
usb2: <Intel 82801H (ICH8) USB 2.0 controller USB2-B> on ehci0
usb2: USB revision 2.0
uhub2: <Intel EHCI root hub, class 9/0, rev 2.00/1.00, addr 1> on usb2
uhub2: 4 ports with 4 removable, self powered
pcm0: <Intel 82801H High Definition Audio Controller> mem 0xfdff4000-0xfdff7fff irq 22 at device 27.0 on pci0
pcm0: [ITHREAD]
uhci2: <Intel 82801H (ICH8) USB controller USB-A> port 0xfd00-0xfd1f irq 23 at device 29.0 on pci0
uhci2: [GIANT-LOCKED]
uhci2: [ITHREAD]
usb3: <Intel 82801H (ICH8) USB controller USB-A> on uhci2
usb3: USB revision 1.0
uhub3: <Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1> on usb3
uhub3: 2 ports with 2 removable, self powered
uhci3: <Intel 82801H (ICH8) USB controller USB-B> port 0xfc00-0xfc1f irq 17 at device 29.1 on pci0
uhci3: [GIANT-LOCKED]
uhci3: [ITHREAD]
usb4: <Intel 82801H (ICH8) USB controller USB-B> on uhci3
usb4: USB revision 1.0
uhub4: <Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1> on usb4
uhub4: 2 ports with 2 removable, self powered
uhci4: <Intel 82801H (ICH8) USB controller USB-C> port 0xfb00-0xfb1f irq 18 at device 29.2 on pci0
uhci4: [GIANT-LOCKED]
uhci4: [ITHREAD]
usb5: <Intel 82801H (ICH8) USB controller USB-C> on uhci4
usb5: USB revision 1.0
uhub5: <Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1> on usb5
uhub5: 2 ports with 2 removable, self powered
ehci1: <Intel 82801H (ICH8) USB 2.0 controller USB2-A> mem 0xfdffe000-0xfdffe3ff irq 23 at device 29.7 on pci0
ehci1: [GIANT-LOCKED]
ehci1: [ITHREAD]
usb6: EHCI version 1.0
usb6: companion controllers, 2 ports each: usb3 usb4 usb5
usb6: <Intel 82801H (ICH8) USB 2.0 controller USB2-A> on ehci1
usb6: USB revision 2.0
uhub6: <Intel EHCI root hub, class 9/0, rev 2.00/1.00, addr 1> on usb6
uhub6: 6 ports with 6 removable, self powered
pcib2: <ACPI PCI-PCI bridge> at device 30.0 on pci0
pci2: <ACPI PCI bus> on pcib2
ath0: <Atheros 5212> mem 0xfdee0000-0xfdeeffff irq 17 at device 0.0 on pci2
ath0: [ITHREAD]
ath0: WARNING: using obsoleted if_watchdog interface
ath0: Ethernet address: 00:14:6c:89:30:1c
ath0: mac 7.9 phy 4.5 radio 5.6
fwohci0: <VIA Fire II (VT6306)> port 0xcf00-0xcf7f mem 0xfdeff000-0xfdeff7ff irq 16 at device 4.0 on pci2
fwohci0: [FILTER]
fwohci0: OHCI version 1.10 (ROM=1)
fwohci0: No. of Isochronous channels is 4.
fwohci0: EUI64 00:11:06:66:00:00:03:12
fwohci0: Phy 1394a available S400, 3 ports.
fwohci0: Link S400, max_rec 2048 bytes.
firewire0: <IEEE1394(FireWire) bus> on fwohci0
sbp0: <SBP-2/SCSI over FireWire> on firewire0
dcons_crom0: <dcons configuration ROM> on firewire0
dcons_crom0: bus_addr 0x1264000
fwohci0: Initiate bus reset
fwohci0: BUS reset
fwohci0: node_id=0xc800ffc0, gen=1, CYCLEMASTER mode
isab0: <PCI-ISA bridge> at device 31.0 on pci0
isa0: <ISA bus> on isab0
atapci0: <Intel AHCI controller> port 0xfa00-0xfa07,0xf900-0xf903,0xf800-0xf807,0xf700-0xf703,0xf600-0xf61f mem 0xfdffd000-0xfdffd7ff irq 19 at device 31.2 on pci0
atapci0: [ITHREAD]
atapci0: AHCI Version 01.10 controller with 6 ports detected
ata2: <ATA channel 0> on atapci0
ata2: [ITHREAD]
ata3: <ATA channel 1> on atapci0
ata3: [ITHREAD]
ata4: <ATA channel 2> on atapci0
ata4: [ITHREAD]
ata5: <ATA channel 3> on atapci0
ata5: [ITHREAD]
ata6: <ATA channel 4> on atapci0
ata6: [ITHREAD]
ata7: <ATA channel 5> on atapci0
ata7: [ITHREAD]
pci0: <serial bus, SMBus> at device 31.3 (no driver attached)
acpi_tz0: <Thermal Zone> on acpi0
cpu0: <ACPI CPU> on acpi0
est0: <Enhanced SpeedStep Frequency Control> on cpu0
p4tcc0: <CPU Frequency Thermal Control> on cpu0
cpu1: <ACPI CPU> on acpi0
est1: <Enhanced SpeedStep Frequency Control> on cpu1
est: CPU supports Enhanced Speedstep, but is not recognized.
est: cpu_vendor GenuineIntel, msr 823082306000823
device_attach: est1 attach returned 6
p4tcc1: <CPU Frequency Thermal Control> on cpu1
acpi_hpet0: <High Precision Event Timer> iomem 0xfed00000-0xfed003ff on acpi0
device_attach: acpi_hpet0 attach returned 12
orm0: <ISA Option ROM> at iomem 0xd0000-0xd1fff pnpid ORM0000 on isa0
sc0: <System console> at flags 0x100 on isa0
sc0: VGA <16 virtual consoles, flags=0x300>
vga0: <Generic ISA VGA> at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0
ata0 at port 0x1f0-0x1f7,0x3f6 irq 14 on isa0
ata0: [ITHREAD]
ata1 at port 0x170-0x177,0x376 irq 15 on isa0
ata1: [ITHREAD]
atkbdc0: <Keyboard controller (i8042)> at port 0x60,0x64 on isa0
atkbd0: <AT Keyboard> irq 1 on atkbdc0
kbd0 at atkbd0
atkbd0: [GIANT-LOCKED]
atkbd0: [ITHREAD]
ums0: <Razer Razer Diamondback Optical Mouse, class 0/0, rev 2.00/1.00, addr 2> on uhub3
ums0: 7 buttons and Z dir.
ukbd0: <vendor 0x1241 USB Keyboard, class 0/0, rev 1.10/2.80, addr 3> on uhub3
kbd2 at ukbd0
uhid0: <vendor 0x1241 USB Keyboard, class 0/0, rev 1.10/2.80, addr 3> on uhub3
Timecounters tick every 1.000 msec
firewire0: 1 nodes, maxhop <= 0, cable IRM = 0 (me)
firewire0: bus manager 0 (me)
acpi_tz0: _TMP value is absurd, ignored (-268.9C)
acpi_tz0: _TMP value is absurd, ignored (-268.9C)
acpi_tz0: _TMP value is absurd, ignored (-268.9C)
acpi_tz0: _TMP value is absurd, ignored (-268.9C)
acpi_tz0: _TMP value is absurd, ignored (-268.9C)
ad4: 238475MB <WDC WD2500JS-60NCB1 10.02E02> at ata2-master SATA300
ad10: 305245MB <Seagate ST3320620AS 3.AAE> at ata5-master SATA150
acd0: DVDR <HL-DT-STDVDRRW GSA-H30L/S544> at ata6-master SATA150
pcm0: <HDA Codec: Realtek ALC885>
pcm0: <HDA Driver Revision: 20080420_0052>
SMP: AP CPU #1 Launched!
acpi_tz0: _TMP value is absurd, ignored (-269.4C)
cd0 at ata6 bus 0 target 0 lun 0
cd0: <HL-DT-ST DVDRRW GSA-H30L S544> Removable CD-ROM SCSI-0 device 
cd0: 3.300MB/s transfers
cd0: Attempt to query device size failed: NOT READY, Medium not present
Trying to mount root from ufs:/dev/ad4s1a
ath0: link state changed to UP
acpi_tz0: _TMP value is absurd, ignored (-269.5C)
ath0: device timeout
ath0: link state changed to DOWN
ath0: link state changed to UP
ath0: link state changed to DOWN
ath0: link state changed to UP
ath0: link state changed to DOWN
ath0: link state changed to UP
ath0: link state changed to DOWN
ath0: link state changed to UP
From pluknet at gmail.com  Tue May 12 06:12:29 2009
From: pluknet at gmail.com (pluknet)
Date: Tue May 12 06:12:36 2009
Subject: lock up in 6.2 (procs massively stuck in Giant)
In-Reply-To: <200905110949.31142.jhb@freebsd.org>
References: <a31046fc0904292336w17aca317hefd32dad5bc28007@mail.gmail.com>
	<200905010949.45927.jhb@freebsd.org>
	<a31046fc0905042041kdfcfa85u38e84db5197c929c@mail.gmail.com>
	<200905110949.31142.jhb@freebsd.org>
Message-ID: <a31046fc0905112312y2496e5cex334ddcaf57889909@mail.gmail.com>

2009/5/11 John Baldwin <jhb@freebsd.org>:
> On Monday 04 May 2009 11:41:35 pm pluknet wrote:
>> 2009/5/1 John Baldwin <jhb@freebsd.org>:
>> > On Thursday 30 April 2009 2:36:34 am pluknet wrote:
>> >> Hi folks.
>> >>
>> >> Today I got a new locking issue.
>> >> This is the first time I got it, and it's merely reproduced.
>> >>
>> >> The box has lost both remote connection and local access.
>> >> No SIGINFO output on the local console even.
>> >> Jumping in ddb> shows the next:
>> >>
>> >> 1) first, this is a 8-way web server. No processes on runqueue except one
>> > httpd
>> >> (i.e. ps shows R in its state):
>> >
>> > You need to find who owns Giant and what that thread is doing.  You can
> try
>> > using 'show lock Giant' as well as 'show lockchain 11568'.
>> >
>>
>> Hi, John!
>>
>> Just reproduced now on another box.
>> Hmm.. stack of the process owing Giant looks garbled.
>>
>> db> show lock Giant
>>  class: sleep mutex
>>  name: Giant
>>  flags: {DEF, RECURSE}
>>  state: {OWNED, CONTESTED}
>>  owner: 0xd0d79320 (tid 102754, pid 34594, "httpd")
>>
>> db> show lockchain 34594
>> thread 102754 (pid 34594, httpd) running on CPU 7
>> db> show lockchain 102754
>> thread 102754 (pid 34594, httpd) running on CPU 7
>
> The thread is running, so we don't know what it's top of stack is and you
> can't a good stack trace in that case.
>
> None of your CPUs are idle, so I don't think you have any sort of deadlock.
> You might have a livelock.
>
> --
> John Baldwin
>

I'm curious if it could be caused by heavy load.
I don't know what it might be definitely,
as it's non-trivial for me to determine the reason
of a livelock, and to debug it.

So I think it may have sense to try 7.x, as there
has been done much locking work.


Thank you.

-- 
wbr,
pluknet
From npapke at acm.org  Tue May 12 07:02:20 2009
From: npapke at acm.org (Norbert Papke)
Date: Tue May 12 07:02:28 2009
Subject: 7.2-STABLE: Inserting USB device causes Fatal Trap 12
In-Reply-To: <200905101426.08256.npapke@acm.org>
References: <200905101217.39920.fbsd-ml@scrapper.ca>
	<200905101426.08256.npapke@acm.org>
Message-ID: <200905120002.18130.npapke@acm.org>

I have been trying to understand the failure better:

(kgdb) frame 10
#10 0xffffffff80473265 in usb_transfer_complete (xfer=0xffffff00045cbc00)
    at /red/public/freebsd/sources/stable/sys/dev/usb/usbdi.c:949
949                     STAILQ_REMOVE_HEAD(&pipe->queue, next);

(kgdb) list
944     #ifdef DIAGNOSTIC
945                     xfer->busy_free = XFER_BUSY;
946     #endif
947                     KASSERT(STAILQ_FIRST(&pipe->queue) == xfer,
948                         ("usb_transfer_complete: bad dequeue"));
949                     STAILQ_REMOVE_HEAD(&pipe->queue, next);
950             }
951             DPRINTFN(5,("usb_transfer_complete: repeat=%d new head=%p\n",
952                         repeat, STAILQ_FIRST(&pipe->queue)));


For reference:

#define STAILQ_NEXT(elm, field) ((elm)->field.stqe_next)
#define STAILQ_FIRST(head)      ((head)->stqh_first)
#define STAILQ_REMOVE_HEAD(head, field) do {                            \
        if ((STAILQ_FIRST((head)) =                                     \
             STAILQ_NEXT(STAILQ_FIRST((head)), field)) == NULL)         \
                (head)->stqh_last = &STAILQ_FIRST((head));              \
} while (0)


Looking at the data:

(kgdb) p *pipe
$15 = {iface = 0x0, device = 0xffffff009c1e4a00, endpoint = 
0xffffff009c1e4a38, refcnt = 1, running = 0 '\0', aborting = 0 '\0',
  queue = {stqh_first = 0x0, stqh_last = 0xffffff000c8576a0}, next = {le_next 
= 0x806b560b4, le_prev = 0x0}, intrxfer = 0x0,
  repeat = 0 '\0', interval = -1, methods = 0xffffffff80a6e340}
(kgdb) p pipe->queue
$16 = {stqh_first = 0x0, stqh_last = 0xffffff000c8576a0}
(kgdb) p pipe->queue->stqh_first
$17 = (struct usbd_xfer *) 0x0

And, of course,

(kgdb) p pipe->queue->stqh_first.next
Cannot access memory at address 0x290


If the kernel had been built with INVARIANTS, presumably the prior assertion 
would have been triggered.  It is not clear to me how the transfer ended up 
in this bad state.  Could the "USBD_NOMEM" status be a clue?

(kgdb) p *xfer
$6 = {pipe = 0xffffff000c857680, priv = 0x0, buffer = 0xfffffffef5b69ff0, 
length = 18, actlen = 0, flags = 6, timeout = 5000,
  status = USBD_NOMEM, callback = 0, done = 1 '\001', request = {bmRequestType 
= 128 '\200', bRequest = 6 '\006',
    wValue = "\001\003", wIndex = "\t\004", wLength = "\022"}, frlengths = 
0x0, nframes = 0, device = 0xffffff009c1e4a00, dmamap = {
    segs = {{ds_addr = 23408640, ds_len = 16}, {ds_addr = 23355392, ds_len = 
2}, {ds_addr = 0, ds_len = 0} <repeats 31 times>},
    nsegs = 2, map = 0xffffff000cbf5e00}, allocbuf = 0x0, rqflags = 1, next = 
{stqe_next = 0x0}, hcpriv = 0x0, timeout_handle = {
    c_links = {sle = {sle_next = 0x0}, tqe = {tqe_next = 0x0, tqe_prev = 
0x0}}, c_time = 0, c_arg = 0x0, c_func = 0,
    c_mtx = 0xffffffff80b12600, c_flags = 0}}


I am getting out of my depth.  I will spend some more time trying to learn 
this code but would appreciate pointers.

Cheers,

-- Norbert Papke.




On May 10, 2009, Norbert Papke wrote:
> On May 10, 2009, Norbert Papke wrote:
> > Inserting a USB thumb drive into a running sytem result in a "Fatal trap
> > 12: page fault while in kernel mode".
> >
> > Unfortunately, I was not able to save a core (not entirely sure why, I'll
> > investigate separately).  I have manually copied the backtrace:
>
> I now have a kernel dump and backtrace with symbols:
>
> #0  doadump () at pcpu.h:195
> #1  0xffffffff801d239c in db_fncall (dummy1=Variable "dummy1" is not
> available.
> ) at /red/public/freebsd/sources/stable/sys/ddb/db_command.c:516
> #2  0xffffffff801d28a9 in db_command (last_cmdp=0xffffffff80adc648,
> cmd_table=0x0, dopager=1)
>     at /red/public/freebsd/sources/stable/sys/ddb/db_command.c:413
> #3  0xffffffff801d2aab in db_command_loop ()
> at /red/public/freebsd/sources/stable/sys/ddb/db_command.c:466
> #4  0xffffffff801d42f7 in db_trap (type=Variable "type" is not available.
> ) at /red/public/freebsd/sources/stable/sys/ddb/db_main.c:228
> #5  0xffffffff805159e5 in kdb_trap (type=12, code=0, tf=0xfffffffef5b69d10)
>     at /red/public/freebsd/sources/stable/sys/kern/subr_kdb.c:524
> #6  0xffffffff80798143 in trap_fatal (frame=0xfffffffef5b69d10,
> eva=Variable "eva" is not available.
> )
>     at /red/public/freebsd/sources/stable/sys/amd64/amd64/trap.c:752
> #7  0xffffffff80798498 in trap_pfault (frame=0xfffffffef5b69d10,
> usermode=0) at
> /red/public/freebsd/sources/stable/sys/amd64/amd64/trap.c:673 #8 
> 0xffffffff80798bcf in trap (frame=0xfffffffef5b69d10)
>     at /red/public/freebsd/sources/stable/sys/amd64/amd64/trap.c:444
> #9  0xffffffff8077edae in calltrap ()
> at /red/public/freebsd/sources/stable/sys/amd64/amd64/exception.S:209
> #10 0xffffffff80473265 in usb_transfer_complete (xfer=0xffffff00045cbc00)
>     at /red/public/freebsd/sources/stable/sys/dev/usb/usbdi.c:949
> #11 0xffffffff8077af55 in bus_dmamap_load (dmat=0xffffff0004598580,
> map=0xffffff000cbf5e00,
>     buf=0xfffffffef5b69ff0, buflen=Variable "buflen" is not available.
> ) at
> /red/public/freebsd/sources/stable/sys/amd64/amd64/busdma_machdep.c:739 #12
> 0xffffffff80473955 in usbd_transfer (xfer=0xffffff00045cbc00)
>     at /red/public/freebsd/sources/stable/sys/dev/usb/usbdi.c:312
> #13 0xffffffff80473b36 in usbd_do_request_flags_pipe
> (dev=0xffffff009c1e4a00, pipe=0xffffff000c857680,
>     req=0xfffffffef5b69f90, data=0xfffffffef5b69ff0, flags=Variable "flags"
> is not available.
> )
>     at /red/public/freebsd/sources/stable/sys/dev/usb/usbdi.c:1100
> #14 0xffffffff80473c60 in usbd_do_request_flags (dev=Variable "dev" is not
> available.
> )
>     at /red/public/freebsd/sources/stable/sys/dev/usb/usbdi.c:1070
> #15 0xffffffff80471d1a in usbd_get_string_desc (dev=0xffffff009c1e4a00,
> sindex=Variable "sindex" is not available.
> )
>     at /red/public/freebsd/sources/stable/sys/dev/usb/usb_subr.c:171
> #16 0xffffffff80472f1d in usbd_get_string (dev=0xffffff009c1e4a00, si=1,
> buf=0xfffffffef5b6a200 "", len=128)
> ---Type <return> to continue, or q <return> to quit---
>     at /red/public/freebsd/sources/stable/sys/dev/usb/usbdi.c:1353
> #17 0xffffffff80470fca in usbd_devinfo_vp (dev=0xffffff009c1e4a00,
> v=0xfffffffef5b6a200 "",
>     p=0xfffffffef5b6a180 "?z?\200????`??\200????", usedev=Variable "usedev"
> is not available.
> )
>     at /red/public/freebsd/sources/stable/sys/dev/usb/usb_subr.c:216
> #18 0xffffffff80471b76 in usbd_devinfo (dev=0xffffff009c1e4a00,
> showclass=1, cp=0xffffff0122986000 "\001")
>     at /red/public/freebsd/sources/stable/sys/dev/usb/usb_subr.c:281
> #19 0xffffffff8047243e in usbd_new_device (parent=0xffffff0004591900,
> bus=0xffffff000440a000, depth=Variable "depth" is not available.
> )
>     at /red/public/freebsd/sources/stable/sys/dev/usb/usb_subr.c:861
> #20 0xffffffff80467b5b in uhub_explore (dev=0xffffff0004591400)
>     at /red/public/freebsd/sources/stable/sys/dev/usb/uhub.c:523
> #21 0xffffffff8046f391 in usb_discover (v=Variable "v" is not available.
> ) at /red/public/freebsd/sources/stable/sys/dev/usb/usb.c:724
> #22 0xffffffff8046fc61 in usb_event_thread (arg=Variable "arg" is not
> available.
> ) at /red/public/freebsd/sources/stable/sys/dev/usb/usb.c:440
> #23 0xffffffff804d05bd in fork_exit (callout=0xffffffff8046fbe5
> <usb_event_thread>, arg=0xffffff0004598d00,
>     frame=0xfffffffef5b6ac80)
> at /red/public/freebsd/sources/stable/sys/kern/kern_fork.c:810
> #24 0xffffffff8077f16e in fork_trampoline ()
>     at /red/public/freebsd/sources/stable/sys/amd64/amd64/exception.S:455
>
> > The problem is repeatable.  It only happens when I insert the thumb drive
> > into a running system.  If I boot with the thumb drive present,
> > everything is fine.
> >
> > Any help is greatly appreciated.
> >
> > Cheers,
> >
> > -- Norbert Papke.
> >
> > =================================================
> >
> > # uname -a
> > FreeBSD proven.lan 7.2-STABLE FreeBSD 7.2-STABLE #0 r191841: Tue May  5
> > 21:13:21 PDT 2009
> > npapke@proven.lan:/usr/obj/red/public/freebsd/sources/stable/sys/PROVEN
> > amd64
> >
> > =================================================
> >
> > Kernel config:
> >
> > include GENERIC
> > ident PROVEN
> >
> > options KDB             # kernel debugger (just in case)
> > options KDB_TRACE
> > options DDB             # kernel debugger (just in case)
> > options WITNESS
> > options WITNESS_SKIPSPIN
> >
> > options IPSEC
> > device  crypto
> > device  stf             # for IPv6 tunneling
> >
> > # keep kernel messages from different cpus separate
> > options PRINTF_BUFR_SIZE=64
> >
> > option  SC_HISTORY_SIZE=2000
> > options SC_NORM_ATTR=(FG_GREEN|BG_BLACK)
> > options SC_NORM_REV_ATTR=(FG_YELLOW|BG_GREEN)
> > options SC_KERNEL_CONS_ATTR=(FG_LIGHTRED|BG_BLACK)
> > options SC_KERNEL_CONS_REV_ATTR=(FG_BLACK|BG_RED)
> >
> > # Alternate Queuing of network packets
> > options ALTQ
> > options ALTQ_CBQ                # Class Bases Queuing (CBQ)
> > options ALTQ_RED                # Random Early Detection (RED)
> > options ALTQ_RIO                # RED In/Out
> > options ALTQ_HFSC               # Hierarchical Packet Scheduler (HFSC)
> > options ALTQ_PRIQ               # Priority Queuing (PRIQ)
> > options ALTQ_NOPCC              # Required for SMP build
> >
> > # load as module for debugging
> > nodevice        re              # RealTek 8139C+/8169/8169S/8110S
> >
> > =================================================
> >
> > Copyright (c) 1992-2009 The FreeBSD Project.
> > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
> >         The Regents of the University of California. All rights reserved.
> > FreeBSD is a registered trademark of The FreeBSD Foundation.
> > FreeBSD 7.2-STABLE #0 r191841: Tue May  5 21:13:21 PDT 2009
> >    
> > npapke@proven.lan:/usr/obj/red/public/freebsd/sources/stable/sys/PROVEN
> > WARNING: WITNESS option enabled, expect reduced performance.
> > Timecounter "i8254" frequency 1193182 Hz quality 0
> > CPU: Intel(R) Core(TM)2 Duo CPU     E8500  @ 3.16GHz (3155.59-MHz
> > K8-class CPU)
> >   Origin = "GenuineIntel"  Id = 0x1067a  Stepping = 10
> >
> > Features=0xbfebfbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,
> >MC A,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE>
> >
> > Features2=0x408e3fd<SSE3,RSVD2,MON,DS_CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR
> >,P DCM,<b19>,XSAVE> AMD Features=0x20100800<SYSCALL,NX,LM>
> >   AMD Features2=0x1<LAHF>
> >   Cores per package: 2
> > usable memory = 4279189504 (4080 MB)
> > avail memory  = 4097724416 (3907 MB)
> > ACPI APIC Table: <100808 APIC1053>
> > FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs
> >  cpu0 (BSP): APIC ID:  0
> >  cpu1 (AP): APIC ID:  1
> > ioapic0 <Version 2.0> irqs 0-23 on motherboard
> > kbd1 at kbdmux0
> > cryptosoft0: <software crypto> on motherboard
> > acpi0: <100808 XSDT1053> on motherboard
> > acpi0: [ITHREAD]
> > acpi0: Power Button (fixed)
> > acpi0: reservation of ffc00000, 300000 (3) failed
> > acpi0: reservation of fee00000, 1000 (3) failed
> > acpi0: reservation of 0, a0000 (3) failed
> > acpi0: reservation of 100000, bff00000 (3) failed
> > Timecounter "ACPI-safe" frequency 3579545 Hz quality 850
> > acpi_timer0: <24-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0
> > acpi_hpet0: <High Precision Event Timer> iomem 0xfed00000-0xfed003ff on
> > acpi0 Timecounter "HPET" frequency 14318180 Hz quality 900
> > pcib0: <ACPI Host-PCI bridge> port 0xcf8-0xcff on acpi0
> > pci0: <ACPI PCI bus> on pcib0
> > pcib1: <ACPI PCI-PCI bridge> irq 16 at device 1.0 on pci0
> > pci1: <ACPI PCI bus> on pcib1
> > vgapci0: <VGA-compatible display> port 0xc000-0xc0ff mem
> > 0xd0000000-0xdfffffff,0xfe9f0000-0xfe9fffff irq 16 at device 0.0 on pci1
> > drm0: <ATI ATI Radeon HD 3600 XT> on vgapci0
> > info: [drm] MSI enabled 1 message(s)
> > vgapci0: child drm0 requested pci_enable_busmaster
> > info: [drm] Initialized radeon 1.29.0 20080528
> > hdac0: <ATI RV635 High Definition Audio Controller> mem
> > 0xfe9ec000-0xfe9effff irq 17 at device 0.1 on pci1
> > hdac0: HDA Driver Revision: 20090329_0131
> > hdac0: [ITHREAD]
> > uhci0: <UHCI (generic) USB controller> port 0xbc00-0xbc1f irq 16 at
> > device 26.0 on pci0
> > uhci0: [GIANT-LOCKED]
> > uhci0: [ITHREAD]
> > usb0: <UHCI (generic) USB controller> 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: <UHCI (generic) USB controller> port 0xb880-0xb89f irq 21 at
> > device 26.1 on pci0
> > uhci1: [GIANT-LOCKED]
> > uhci1: [ITHREAD]
> > usb1: <UHCI (generic) USB controller> 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: <UHCI (generic) USB controller> port 0xb800-0xb81f irq 19 at
> > device 26.2 on pci0
> > uhci2: [GIANT-LOCKED]
> > uhci2: [ITHREAD]
> > usb2: <UHCI (generic) USB controller> 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: <EHCI (generic) USB 2.0 controller> mem 0xfe8fe000-0xfe8fe3ff irq
> > 18 at device 26.7 on pci0
> > ehci0: [GIANT-LOCKED]
> > ehci0: [ITHREAD]
> > usb3: EHCI version 1.0
> > usb3: companion controllers, 2 ports each: usb0 usb1 usb2
> > usb3: <EHCI (generic) 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
> > hdac1: <Intel 82801J High Definition Audio Controller> mem
> > 0xfe8f8000-0xfe8fbfff irq 22 at device 27.0 on pci0
> > hdac1: HDA Driver Revision: 20090329_0131
> > hdac1: [ITHREAD]
> > pcib2: <ACPI PCI-PCI bridge> irq 17 at device 28.0 on pci0
> > pci2: <ACPI PCI bus> on pcib2
> > pcib3: <ACPI PCI-PCI bridge> irq 16 at device 28.5 on pci0
> > pci3: <ACPI PCI bus> on pcib3
> > re0: <RealTek 8168/8168B/8168C/8168CP/8168D/8111B/8111C/8111CP PCIe
> > Gigabit Ethernet> port 0xd800-0xd8ff mem
> > 0xfeaff000-0xfeafffff,0xfdff0000-0xfdffffff irq 17 at device 0.0 on pci3
> > re0: Chip rev. 0x3c000000
> > re0: MAC rev. 0x00400000
> > 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:30:48:b0:6a:1f
> > re0: [FILTER]
> > uhci3: <UHCI (generic) USB controller> port 0xb480-0xb49f irq 23 at
> > device 29.0 on pci0
> > uhci3: [GIANT-LOCKED]
> > uhci3: [ITHREAD]
> > usb4: <UHCI (generic) USB controller> on uhci3
> > usb4: USB revision 1.0
> > uhub4: <Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1> on usb4
> > uhub4: 2 ports with 2 removable, self powered
> > uhci4: <UHCI (generic) USB controller> port 0xb400-0xb41f irq 19 at
> > device 29.1 on pci0
> > uhci4: [GIANT-LOCKED]
> > uhci4: [ITHREAD]
> > usb5: <UHCI (generic) USB controller> on uhci4
> > usb5: USB revision 1.0
> > uhub5: <Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1> on usb5
> > uhub5: 2 ports with 2 removable, self powered
> > uhci5: <UHCI (generic) USB controller> port 0xb080-0xb09f irq 18 at
> > device 29.2 on pci0
> > uhci5: [GIANT-LOCKED]
> > uhci5: [ITHREAD]
> > usb6: <UHCI (generic) USB controller> on uhci5
> > usb6: USB revision 1.0
> > uhub6: <Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1> on usb6
> > uhub6: 2 ports with 2 removable, self powered
> > ehci1: <EHCI (generic) USB 2.0 controller> mem 0xfe8fc000-0xfe8fc3ff irq
> > 23 at device 29.7 on pci0
> > ehci1: [GIANT-LOCKED]
> > ehci1: [ITHREAD]
> > usb7: EHCI version 1.0
> > usb7: companion controllers, 2 ports each: usb4 usb5 usb6
> > usb7: <EHCI (generic) USB 2.0 controller> on ehci1
> > usb7: USB revision 2.0
> > uhub7: <Intel EHCI root hub, class 9/0, rev 2.00/1.00, addr 1> on usb7
> > uhub7: 6 ports with 6 removable, self powered
> > umass0: <JetFlash Mass Storage Device, class 0/0, rev 2.00/1.00, addr 2>
> > on uhub7
> > pcib4: <ACPI PCI-PCI bridge> at device 30.0 on pci0
> > pci4: <ACPI PCI bus> on pcib4
> > dc0: <ADMtek AN985 10/100BaseTX> port 0xe800-0xe8ff mem
> > 0xfebffc00-0xfebfffff irq 21 at device 1.0 on pci4
> > miibus1: <MII bus> on dc0
> > acphy0: <ACXXX 10/100 media interface> PHY 1 on miibus1
> > acphy0:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
> > dc0: Ethernet address: 00:20:78:10:3e:98
> > dc0: [ITHREAD]
> > isab0: <PCI-ISA bridge> at device 31.0 on pci0
> > isa0: <ISA bus> on isab0
> > atapci0: <Intel ICH10 SATA300 controller> port
> > 0xb000-0xb007,0xac00-0xac03,0xa880-0xa887,0xa800-0xa803,0xa480-0xa48f,0xa
> >40 0-0xa40f irq 19 at device 31.2 on pci0
> > atapci0: [ITHREAD]
> > ata2: <ATA channel 0> on atapci0
> > ata2: [ITHREAD]
> > ata3: <ATA channel 1> on atapci0
> > ata3: [ITHREAD]
> > ichsmb0: <SMBus controller> port 0x400-0x41f mem 0xfe8f7c00-0xfe8f7cff
> > irq 18 at device 31.3 on pci0
> > ichsmb0: [GIANT-LOCKED]
> > ichsmb0: [ITHREAD]
> > smbus0: <System Management Bus> on ichsmb0
> > smb0: <SMBus generic I/O> on smbus0
> > atapci1: <Intel ICH10 SATA300 controller> port
> > 0xa000-0xa007,0x9c00-0x9c03,0x9880-0x9887,0x9800-0x9803,0x9480-0x948f,0x9
> >40 0-0x940f irq 19 at device 31.5 on pci0
> > atapci1: [ITHREAD]
> > ata4: <ATA channel 0> on atapci1
> > ata4: [ITHREAD]
> > ata5: <ATA channel 1> on atapci1
> > ata5: [ITHREAD]
> > acpi_button0: <Power Button> on acpi0
> > sio0: configured irq 4 not in bitmap of probed irqs 0
> > sio0: port may not be enabled
> > sio0: configured irq 4 not in bitmap of probed irqs 0
> > sio0: port may not be enabled
> > sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on
> > acpi0 sio0: type 16550A
> > sio0: [FILTER]
> > ppc0: <Parallel port> port 0x378-0x37f irq 7 on acpi0
> > ppc0: Generic chipset (NIBBLE-only) in COMPATIBLE mode
> > ppbus0: <Parallel port bus> on ppc0
> > ppbus0: [ITHREAD]
> > lpt0: <Printer> on ppbus0
> > lpt0: Interrupt-driven port
> > ppi0: <Parallel I/O> on ppbus0
> > plip0: <PLIP network interface> on ppbus0
> > plip0: WARNING: using obsoleted IFF_NEEDSGIANT flag
> > ppc0: [GIANT-LOCKED]
> > ppc0: [ITHREAD]
> > 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
> > ACPI Warning (tbutils-0243): Incorrect checksum in table [OEMB] -  45,
> > should be 40 [20070320]
> > coretemp0: <CPU On-Die Thermal Sensors> on cpu0
> > est0: <Enhanced SpeedStep Frequency Control> on cpu0
> > p4tcc0: <CPU Frequency Thermal Control> on cpu0
> > cpu1: <ACPI CPU> on acpi0
> > coretemp1: <CPU On-Die Thermal Sensors> on cpu1
> > est1: <Enhanced SpeedStep Frequency Control> on cpu1
> > est: CPU supports Enhanced Speedstep, but is not recognized.
> > est: cpu_vendor GenuineIntel, msr 616492206004922
> > device_attach: est1 attach returned 6
> > p4tcc1: <CPU Frequency Thermal Control> on cpu1
> > orm0: <ISA Option ROM> at iomem 0xc0000-0xcffff on isa0
> > sc0: <System console> at flags 0x100 on isa0
> > sc0: VGA <16 virtual consoles, flags=0x300>
> > sio1: configured irq 3 not in bitmap of probed irqs 0
> > sio1: port may not be enabled
> > vga0: <Generic ISA VGA> at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0
> > Timecounters tick every 1.000 msec
> > IPsec: Initialized Security Association Processing.
> > ad4: 239372MB <Maxtor 7Y250M0 YAR51HW0> at ata2-master SATA150
> > ad7: 305245MB <Seagate ST3320620AS 3.AAK> at ata3-slave SATA300
> > ad8: 610480MB <WDC WD6401AALS-00L3B2 01.03B01> at ata4-master SATA300
> > GEOM_LABEL: Label for provider ad4s1a is ufsid/497cecd46b0e22e5.
> > acd0: DVDR <HL-DT-STDVD-RAM GH22NS30/1.01> at ata5-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 #2: Realtek ALC888
> > hdac1: hdac_command_send_internal: TIMEOUT numcmd=1, sent=1, received=0
> > hdac1: hdac_command_send_internal: TIMEOUT numcmd=1, sent=1, received=0
> > hdac1: Codec #3 is not responding! Probing aborted.
> > pcm1: <HDA Realtek ALC888 PCM #0 Analog> at cad 2 nid 1 on hdac1
> > pcm2: <HDA Realtek ALC888 PCM #1 Analog> at cad 2 nid 1 on hdac1
> > pcm3: <HDA Realtek ALC888 PCM #2 Digital> at cad 2 nid 1 on hdac1
> > acd0: FAILURE - INQUIRY ILLEGAL REQUEST asc=0x24 ascq=0x00
> > (probe1:umass-sim0:0:0:0): TEST UNIT READY. CDB: 0 0 0 0 0 0
> > (probe1:umass-sim0:0:0:0): CAM Status: SCSI Status Error
> > (probe1:umass-sim0:0:0:0): SCSI Status: Check Condition
> > (probe1:umass-sim0:0:0:0): UNIT ATTENTION asc:28,0
> > (probe1:umass-sim0:0:0:0): Not ready to ready change, medium may have
> > changed (probe1:umass-sim0:0:0:0): Retrying Command (per Sense Data)
> > acd0: FAILURE - INQUIRY ILLEGAL REQUEST asc=0x24 ascq=0x00
> > SMP: AP CPU #1 Launched!
> > WARNING: WITNESS option enabled, expect reduced performance.
> > da0 at umass-sim0 bus 0 target 0 lun 0
> > da0: <JetFlash Transcend 4GB 8.07> Removable Direct Access SCSI-2 device
> > da0: 40.000MB/s transfers
> > da0: 3830MB (7843840 512 byte sectors: 255H 63S/T 488C)
> > cd0 at ata3 bus 0 target 0 lun 0
> > cd0: <HL-DT-ST DVD-RAM GH22NS30 1.01> Removable CD-ROM SCSI-0 device
> > cd0: 3.300MB/s transfers
> > cd0: cd present [4098336 x 2048 byte records]
> > GEOM_LABEL: Label for provider acd0 is
> > iso9660/THE_MATRIX_16X9LB_N_AMERICA. Trying to mount root from
> > ufs:/dev/ad4s1a
> > WARNING: / was not properly dismounted
> > WARNING: reducing size to maximum of 67108864 blocks per swap unit
> > GEOM_LABEL: Label ufsid/497cecd46b0e22e5 removed.
> > GEOM_LABEL: Label for provider ad4s1a is ufsid/497cecd46b0e22e5.
> > GEOM_LABEL: Label ufsid/497cecd46b0e22e5 removed.
> > 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 6
> > ZFS storage pool version 6
> > lock order reversal:
> >  1st 0xffffffff80e49de0 pf task mtx (pf task mtx)
> > @
> > /red/public/freebsd/sources/stable/sys/modules/pf/../../contrib/pf/net/pf
> >_i octl.c:1394 2nd 0xffffffff80ba94c0 ifnet (ifnet)
> > @ /red/public/freebsd/sources/stable/sys/net/if.c:1623
> > KDB: stack backtrace:
> > db_trace_self_wrapper() at db_trace_self_wrapper+0x2a
> > witness_checkorder() at witness_checkorder+0x543
> > _mtx_lock_flags() at _mtx_lock_flags+0x1f
> > ifunit() at ifunit+0x24
> > pfioctl() at pfioctl+0x2531
> > devfs_ioctl_f() at devfs_ioctl_f+0x71
> > kern_ioctl() at kern_ioctl+0x91
> > ioctl() at ioctl+0xeb
> > syscall() at syscall+0x1a5
> > Xfast_syscall() at Xfast_syscall+0xab
> > --- syscall (54, FreeBSD ELF64, ioctl), rip = 0x80096296c, rsp =
> > 0x7fffffffdc18, rbp = 0x7fffffffdca0 ---
> > kqemu version 0x00010400
> > kqemu: KQEMU installed, max_locked_mem=2089448kB.
> > acd0: FAILURE - READ_BIG timed out
> > acd0: FAILURE - READ_BIG timed out
> > acd0: FAILURE - READ_BIG timed out
> > info: [drm] Setting GART location based on new memory map
> > info: [drm] Loading RV635 CP Microcode
> > info: [drm] Loading RV635 PFP Microcode
> > info: [drm] Resetting GPU
> > info: [drm] writeback test succeeded in 1 usecs
> > drm0: [ITHREAD]
> > acd0: FAILURE - READ_BIG timed out
> > acd0: FAILURE - READ_BIG timed out
> > (cd0:ata3:0:0:0): cddone: got error 0x5 back
> > tap0: Ethernet address: 00:bd:d8:9b:04:00
> > bridge0: Ethernet address: fa:cc:68:2e:a4:8e
> > tap0: promiscuous mode enabled
> > dc0: promiscuous mode enabled
> >
> > _______________________________________________
> > freebsd-stable@freebsd.org mailing list
> > http://lists.freebsd.org/mailman/listinfo/freebsd-stable
> > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org"



-- 
-- Norbert Papke.
   npapke@acm.org
From petefrench at ticketswitch.com  Tue May 12 07:25:41 2009
From: petefrench at ticketswitch.com (Pete French)
Date: Tue May 12 07:25:48 2009
Subject: Error message: run_interrupt_driven_hooks:...
In-Reply-To: <20090512014733.GA12271@panix.com>
Message-ID: <E1M3mMs-0006yd-S7@dilbert.ticketswitch.com>

> Basic data on my experience with the xpt_config hang; I have more
> detail if needed, but I doubt anyone will believe it. I'm not even
> sure I do.

I am not sure what you mean by that ... something odd about the hang ?

For what it's worth, I have also seen this - I get (or got) precisely
the same error when trying to boot FreeBSD on an MSI 790GX motherboard.
As on last weekend I have replaced it with a 790FX and now everything
works fine - but ti means I can't do anymore bug hunting. From a quick
glance at these reports I think all the people with this problem are
using AMD AM2 motherboards aren't they ?

-pete.
From bra at fsn.hu  Tue May 12 09:06:23 2009
From: bra at fsn.hu (Attila Nagy)
Date: Tue May 12 09:06:30 2009
Subject: stat() takes 54 msec in a directory with 94k files (even with a big
 dirhash)
Message-ID: <4A09382F.5010109@fsn.hu>

Hello,

I have a strange error on FreeBSD 7-STABLE (compiled on 7th May, just 
few commits after the release, but an earlier kernel did the same).

I'm doing several parallel rsyncs from a machine to another (let's call 
them source and destination). The source contains maildirs, so there are 
some directories with a (relatively) lot of files.
The source runs an earlier (around 6.2) FreeBSD and plain softupdates 
mounted UFS2 file systems.
The destination has a bigger (UFS2) filesystem, on top of gjournal, 
mounted as async.

I've noticed that rsync sometimes stops moving data and the destination 
machine gets sluggish. After some testing, I could catch the effect in 
action (was not that hard, because it persists even for hours sometimes).

top shows around 20% system activity (there are two quad core CPUs) and 
0% user. The WCPU field at rsync shows 100%.

ktrace-ing the rsync process I can see this:
   31639 rsync    0.000004 CALL  lstat(0x7fffffffab70,0x7fffffffaf70)
   31639 rsync    0.000004 NAMI  
"hm33/00/16/uid/Maildir/new/1212536121.54673,S=3128"
   31639 rsync    0.054226 STRU  struct stat {dev=100, ino=136943662, 
mode=-rw------- , nlink=1, uid=999, gid=999, rdev=546942760, 
atime=1241807071, stime=1212536121, ctime=1241807071, 
birthtime=1212536121, size=3128, blksize=4096, blocks=8, flags=0x0 }
   31639 rsync    0.000013 RET   lstat 0
   31639 rsync    0.000018 CALL  lstat(0x7fffffffab70,0x7fffffffaf70)
   31639 rsync    0.000004 NAMI  
"hm33/00/16/uid/Maildir/new/1212537276.69702,S=4634"
   31639 rsync    0.054409 STRU  struct stat {dev=100, ino=136943663, 
mode=-rw------- , nlink=1, uid=999, gid=999, rdev=546942762, 
atime=1241807071, stime=1212537276, ctime=1241807071, 
birthtime=1212537276, size=4634, blksize=4096, blocks=12, flags=0x0 }
   31639 rsync    0.000013 RET   lstat 0
   31639 rsync    0.000020 CALL  lstat(0x7fffffffab70,0x7fffffffaf70)
   31639 rsync    0.000005 NAMI  
"hm33/00/16/uid/Maildir/new/1212537689.74390,S=3172"
   31639 rsync    0.054230 STRU  struct stat {dev=100, ino=136943664, 
mode=-rw------- , nlink=1, uid=999, gid=999, rdev=546942765, 
atime=1241807071, stime=1212537689, ctime=1241807071, 
birthtime=1212537689, size=3172, blksize=4096, blocks=8, flags=0x0 }
   31639 rsync    0.000013 RET   lstat 0

So according to ktrace, the stat call takes 54 milliseconds to return 
for each of the files.
I have tried with the default and a pretty much raised dirhash maxmem 
value, but I can still get these.
Currently I have:
vfs.ufs.dirhash_docheck: 0
vfs.ufs.dirhash_mem: 18589428
vfs.ufs.dirhash_maxmem: 209715200
vfs.ufs.dirhash_minsize: 2560
So dirhash has space to expand.

The directory in question contains 94493 files.

The source machine doesn't show this behaviour.

top's output on the destination machine:
CPU:  0.0% user,  0.0% nice, 22.7% system,  0.0% interrupt, 77.3% idle
Mem: 159M Active, 3032M Inact, 599M Wired, 47M Cache, 399M Buf, 102M Free
Swap: 4096M Total, 4096M Free

  PID USERNAME   THR PRI NICE   SIZE    RES STATE  C   TIME   WCPU COMMAND
31639 root         1 118    0 50648K 10512K CPU0   0   2:01 100.00% rsync
  634 root         1  -4    0  2536K   628K vlruwk 1   0:20  0.00% supervise
26760 root         1  44    0 25940K  3316K select 1   0:10  0.00% sshd
31640 root         1  75    0 87512K  8324K suspfs 4   0:10  0.00% rsync
31641 root         1  75    0 18904K  7124K suspfs 6   0:10  0.00% rsync
31637 root         1  75    0 40408K  7744K suspfs 4   0:09  0.00% rsync
31636 root         1  44    0 20952K  6288K select 2   0:09  0.00% rsync
31638 root         1  44    0   104M  8912K select 3   0:09  0.00% rsync
31635 root         1  75    0 80344K  7812K suspfs 4   0:09  0.00% rsync
31642 root         1  44    0 17940K  7624K select 1   0:04  0.00% ssh
31646 root         1  45    0 17940K  7656K select 1   0:03  0.00% ssh

All of the rsyncs use the same file system, but with different top level 
directories. During this, neither of the other rsyncs can run.

Any ideas about what could be done to work around this?

Thanks,
From onemda at gmail.com  Tue May 12 10:26:50 2009
From: onemda at gmail.com (Paul B. Mahol)
Date: Tue May 12 10:27:05 2009
Subject: stat() takes 54 msec in a directory with 94k files (even with a
	big dirhash)
In-Reply-To: <4A09382F.5010109@fsn.hu>
References: <4A09382F.5010109@fsn.hu>
Message-ID: <3a142e750905120326m165f4fdeld8d01eb305a1771c@mail.gmail.com>

On 5/12/09, Attila Nagy <bra@fsn.hu> wrote:
> Hello,
>
> I have a strange error on FreeBSD 7-STABLE (compiled on 7th May, just
> few commits after the release, but an earlier kernel did the same).
>
> I'm doing several parallel rsyncs from a machine to another (let's call
> them source and destination). The source contains maildirs, so there are
> some directories with a (relatively) lot of files.
> The source runs an earlier (around 6.2) FreeBSD and plain softupdates
> mounted UFS2 file systems.
> The destination has a bigger (UFS2) filesystem, on top of gjournal,
> mounted as async.
>
> I've noticed that rsync sometimes stops moving data and the destination
> machine gets sluggish. After some testing, I could catch the effect in
> action (was not that hard, because it persists even for hours sometimes).
>
> top shows around 20% system activity (there are two quad core CPUs) and
> 0% user. The WCPU field at rsync shows 100%.
>
> ktrace-ing the rsync process I can see this:
>    31639 rsync    0.000004 CALL  lstat(0x7fffffffab70,0x7fffffffaf70)
>    31639 rsync    0.000004 NAMI
> "hm33/00/16/uid/Maildir/new/1212536121.54673,S=3128"
>    31639 rsync    0.054226 STRU  struct stat {dev=100, ino=136943662,
> mode=-rw------- , nlink=1, uid=999, gid=999, rdev=546942760,
> atime=1241807071, stime=1212536121, ctime=1241807071,
> birthtime=1212536121, size=3128, blksize=4096, blocks=8, flags=0x0 }
>    31639 rsync    0.000013 RET   lstat 0
>    31639 rsync    0.000018 CALL  lstat(0x7fffffffab70,0x7fffffffaf70)
>    31639 rsync    0.000004 NAMI
> "hm33/00/16/uid/Maildir/new/1212537276.69702,S=4634"
>    31639 rsync    0.054409 STRU  struct stat {dev=100, ino=136943663,
> mode=-rw------- , nlink=1, uid=999, gid=999, rdev=546942762,
> atime=1241807071, stime=1212537276, ctime=1241807071,
> birthtime=1212537276, size=4634, blksize=4096, blocks=12, flags=0x0 }
>    31639 rsync    0.000013 RET   lstat 0
>    31639 rsync    0.000020 CALL  lstat(0x7fffffffab70,0x7fffffffaf70)
>    31639 rsync    0.000005 NAMI
> "hm33/00/16/uid/Maildir/new/1212537689.74390,S=3172"
>    31639 rsync    0.054230 STRU  struct stat {dev=100, ino=136943664,
> mode=-rw------- , nlink=1, uid=999, gid=999, rdev=546942765,
> atime=1241807071, stime=1212537689, ctime=1241807071,
> birthtime=1212537689, size=3172, blksize=4096, blocks=8, flags=0x0 }
>    31639 rsync    0.000013 RET   lstat 0
>
> So according to ktrace, the stat call takes 54 milliseconds to return
> for each of the files.
> I have tried with the default and a pretty much raised dirhash maxmem
> value, but I can still get these.
> Currently I have:
> vfs.ufs.dirhash_docheck: 0
> vfs.ufs.dirhash_mem: 18589428
> vfs.ufs.dirhash_maxmem: 209715200
> vfs.ufs.dirhash_minsize: 2560
> So dirhash has space to expand.
>
> The directory in question contains 94493 files.
>
> The source machine doesn't show this behaviour.
>
> top's output on the destination machine:
> CPU:  0.0% user,  0.0% nice, 22.7% system,  0.0% interrupt, 77.3% idle
> Mem: 159M Active, 3032M Inact, 599M Wired, 47M Cache, 399M Buf, 102M Free
> Swap: 4096M Total, 4096M Free
>
>   PID USERNAME   THR PRI NICE   SIZE    RES STATE  C   TIME   WCPU COMMAND
> 31639 root         1 118    0 50648K 10512K CPU0   0   2:01 100.00% rsync
>   634 root         1  -4    0  2536K   628K vlruwk 1   0:20  0.00% supervise
> 26760 root         1  44    0 25940K  3316K select 1   0:10  0.00% sshd
> 31640 root         1  75    0 87512K  8324K suspfs 4   0:10  0.00% rsync
> 31641 root         1  75    0 18904K  7124K suspfs 6   0:10  0.00% rsync
> 31637 root         1  75    0 40408K  7744K suspfs 4   0:09  0.00% rsync
> 31636 root         1  44    0 20952K  6288K select 2   0:09  0.00% rsync
> 31638 root         1  44    0   104M  8912K select 3   0:09  0.00% rsync
> 31635 root         1  75    0 80344K  7812K suspfs 4   0:09  0.00% rsync
> 31642 root         1  44    0 17940K  7624K select 1   0:04  0.00% ssh
> 31646 root         1  45    0 17940K  7656K select 1   0:03  0.00% ssh
>
> All of the rsyncs use the same file system, but with different top level
> directories. During this, neither of the other rsyncs can run.
>
> Any ideas about what could be done to work around this?

Big guess, maybe it updates atime? Try with noatime mount option.
-- 
Paul
From db at danielbond.org  Tue May 12 11:52:07 2009
From: db at danielbond.org (Daniel Bond)
Date: Tue May 12 11:52:18 2009
Subject: PAM completeness and standardization  [PR:bin/71290]
In-Reply-To: <49E8D18C.4070603@comcast.net>
References: <34B37CEC-AF7A-48EE-81F5-7B19291F99EF@danielbond.org>
	<49E8D18C.4070603@comcast.net>
Message-ID: <F24A533C-C88F-4BB1-B91B-EF303D095E29@danielbond.org>

Hi Steve and Oliver,

thanks for your replies. Sorry it has taken me some time to reply. I'm  
willing to put in some time into this issue too, maybe we could do a  
joint effort on this?

The problem report with the most information in is http://www.freebsd.org/cgi/query-pr.cgi?pr=bin/71290 
  - DES has some good reasons, for why the patch has not been included  
in FreeBSD.

Here are some of my viewpoints about the comments in the ticket.

- I think it is really important we preserve all command-line options,  
and do not break any existing functionality what so ever.
- I also think exposing PAM code for changing passwords is a good  
thing. Either we want PAM support in FreeBSD, or we don't. If we do,  
we need to support the PAM core features - exposing this code is  
necessary, and the code needs to be polished accordingly.
- The documentation changes is nice to have, let's think about this  
when we are happy with the other stuff.


I have a NetBSD 5.0 installation on my private server, I'll start  
looking at how they have implemented PAM.


Any comments? Pointers to code that would need cleanup? Anything we  
need to be extra careful with?


Best regards,

Daniel.

--
GPG public key: EDE9C925

On Apr 17, 2009, at 8:59 PM, Steve Polyack wrote:

> Daniel Bond wrote:
>> FreeBSD has excellent PAM-support, except for the passwd-command.  
>> The passwd-command gained PAM support quite a while ago, but there  
>> is a test preventing it from working with PAM.
>> There have been outstanding PR's for this minor issue for years  
>> now, I think it's time this one got fixed. People find it  
>> frustrating that they can't change their passwords (LDAP etc), like  
>> they can in a normal PAM-based system.
>>
>>
>> I'd be happy to fix whatever needs to be done, but I need to know  
>> why it's not been fixed / what needs to be done for it to be  
>> accepted by the community.
>
> I've looked at this recently and came to a roadblock after  
> sufficiently modifying passwd code (removing the test and an  
> additional few lines) as well as including the proper lines in /etc/ 
> pam.d/sshd.  I can't recally the exact problem I had.  I will  
> probably give this another go in the future, so I am willing to put  
> in some time on this issue.
>
> Anyways, I don't have a reason for you as to why it hasn't been  
> fixed or accepted yet.  It is a long-standing issue from what I  
> understand.
>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 203 bytes
Desc: This is a digitally signed message part
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20090512/2c193258/PGP.pgp
From des at des.no  Tue May 12 13:06:36 2009
From: des at des.no (=?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?=)
Date: Tue May 12 13:06:44 2009
Subject: PAM completeness and standardization  [PR:bin/71290]
In-Reply-To: <F24A533C-C88F-4BB1-B91B-EF303D095E29@danielbond.org> (Daniel
	Bond's message of "Tue, 12 May 2009 13:51:58 +0200")
References: <34B37CEC-AF7A-48EE-81F5-7B19291F99EF@danielbond.org>
	<49E8D18C.4070603@comcast.net>
	<F24A533C-C88F-4BB1-B91B-EF303D095E29@danielbond.org>
Message-ID: <867i0m5vxz.fsf@ds4.des.no>

Daniel Bond <db@danielbond.org> writes:
> I have a NetBSD 5.0 installation on my private server, I'll start
> looking at how they have implemented PAM.

Specifically, you should look at how they've adapted their passwd(1) and
what pam_sm_chauthtok() looks like in their PAM modules.

DES
-- 
Dag-Erling Sm?rgrav - des@des.no
From yani at pi-greece.eu  Tue May 12 14:23:17 2009
From: yani at pi-greece.eu (Yani Karydis)
Date: Tue May 12 14:23:26 2009
Subject: CAM Status: SCSI Status Error on 7.2-RELEASE
Message-ID: <4A098115.3040605@pi-greece.eu>

Hello,

Since upgrading to 7.2-RELEASE, dmesg displays the following after 
booting the system.

(probe3:ahc0:0:3:0): TEST UNIT READY. CDB: 0 0 0 0 0 0
(probe3:ahc0:0:3:0): CAM Status: SCSI Status Error
(probe3:ahc0:0:3:0): SCSI Status: Check Condition
(probe3:ahc0:0:3:0): UNIT ATTENTION asc:29,0
(probe3:ahc0:0:3:0): Power on, reset, or bus device reset occurred
(probe3:ahc0:0:3:0): Retrying Command (per Sense Data)
(probe3:ahc0:0:3:0): TEST UNIT READY. CDB: 0 0 0 0 0 0
(probe3:ahc0:0:3:0): CAM Status: SCSI Status Error
(probe3:ahc0:0:3:0): SCSI Status: Check Condition
(probe3:ahc0:0:3:0): NOT READY asc:3a,0
(probe3:ahc0:0:3:0): Medium not present
(probe3:ahc0:0:3:0): Unretryable error
sa0 at ahc0 bus 0 target 3 lun 0
sa0: <HP Ultrium 1-SCSI N2CG> Removable Sequential Access SCSI-3 device
sa0: 20.000MB/s transfers (10.000MHz, offset 8, 16bit)


Is CAM trying to read the capabilities of the Ultrium tape drive? I've 
never seen these messages before, the system was upgraded straight from 
7.1-RELEASE to 7.2-RELEASE.

Full dmesg below:

Copyright (c) 1992-2009 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
        The Regents of the University of California. All rights reserved.
FreeBSD is a registered trademark of The FreeBSD Foundation.
FreeBSD 7.2-RELEASE #61: Tue May 12 00:23:20 EEST 2009
    root@techserver.pi-greece.eu:/usr/obj/usr/src/sys/TECHSERVER7
Timecounter "i8254" frequency 1193182 Hz quality 0
CPU: AMD Sempron(tm)   2300+ (1585.75-MHz 686-class CPU)
  Origin = "AuthenticAMD"  Id = 0x681  Stepping = 1
  
Features=0x383fbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR,SSE>
  AMD Features=0xc0480800<SYSCALL,MP,MMX+,3DNow!+,3DNow!>
real memory  = 1073676288 (1023 MB)
avail memory = 1041469440 (993 MB)
ACPI APIC Table: <GBT    AWRDACPI>
ioapic0 <Version 0.3> irqs 0-23 on motherboard
kbd1 at kbdmux0
acpi0: <GBT AWRDACPI> on motherboard
acpi0: [ITHREAD]
acpi0: Power Button (fixed)
acpi0: reservation of 0, a0000 (3) failed
acpi0: reservation of 100000, 3fef0000 (3) failed
acpi_button0: <Power Button> on acpi0
pcib0: <ACPI Host-PCI bridge> port 0xcf8-0xcff on acpi0
pci0: <ACPI PCI bus> on pcib0
agp0: <VIA 8377 (Apollo KT400/KT400A/KT600) host to PCI bridge> on hostb0
agp0: aperture size is 32M
pcib1: <PCI-PCI bridge> at device 1.0 on pci0
pci1: <PCI bus> on pcib1
vgapci0: <VGA-compatible display> port 0xa000-0xa0ff mem 
0xd0000000-0xd7ffffff,0xe0000000-0xe000ffff at device 0.0 on pci1
em0: <Intel(R) PRO/1000 Network Connection 6.9.6> port 0xb000-0xb03f mem 
0xe1000000-0xe101ffff,0xe1020000-0xe103ffff irq 17 at device 9.0 on pci0
em0: [FILTER]
em0: Ethernet address: 00:07:e9:49:18:b3
aac0: <HP ML110 G2 (Adaptec 2610SA)> mem 0xd8000000-0xdbffffff irq 18 at 
device 10.0 on pci0
aac0: Enable Raw I/O
aac0: New comm. interface enabled
aac0: [ITHREAD]
aac0: Adaptec 2610SA, aac driver 2.0.0-1
ahc0: <Adaptec 2940 Ultra SCSI adapter> port 0xb400-0xb4ff mem 
0xe1040000-0xe1040fff irq 19 at device 11.0 on pci0
ahc0: [ITHREAD]
aic7880: Ultra Wide Channel A, SCSI Id=7, 16/253 SCBs
atapci0: <VIA 6420 SATA150 controller> port 
0xb800-0xb807,0xbc00-0xbc03,0xc000-0xc007,0xc400-0xc403,0xc800-0xc80f,0xcc00-0xccff 
irq 20 at device 15.0 on pci0
atapci0: [ITHREAD]
ata2: <ATA channel 0> on atapci0
ata2: [ITHREAD]
ata3: <ATA channel 1> on atapci0
ata3: [ITHREAD]
atapci1: <VIA 8237 UDMA133 controller> port 
0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xd000-0xd00f at device 15.1 on pci0
ata0: <ATA channel 0> on atapci1
ata0: [ITHREAD]
ata1: <ATA channel 1> on atapci1
ata1: [ITHREAD]
uhci0: <VIA 83C572 USB controller> port 0xd400-0xd41f irq 21 at device 
16.0 on pci0
uhci0: [GIANT-LOCKED]
uhci0: [ITHREAD]
usb0: <VIA 83C572 USB controller> on uhci0
usb0: USB revision 1.0
uhub0: <VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1> on usb0
uhub0: 2 ports with 2 removable, self powered
uhci1: <VIA 83C572 USB controller> port 0xd800-0xd81f irq 21 at device 
16.1 on pci0
uhci1: [GIANT-LOCKED]
uhci1: [ITHREAD]
usb1: <VIA 83C572 USB controller> on uhci1
usb1: USB revision 1.0
uhub1: <VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1> on usb1
uhub1: 2 ports with 2 removable, self powered
uhci2: <VIA 83C572 USB controller> port 0xdc00-0xdc1f irq 21 at device 
16.2 on pci0
uhci2: [GIANT-LOCKED]
uhci2: [ITHREAD]
usb2: <VIA 83C572 USB controller> on uhci2
usb2: USB revision 1.0
uhub2: <VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1> on usb2
uhub2: 2 ports with 2 removable, self powered
uhci3: <VIA 83C572 USB controller> port 0xe000-0xe01f irq 21 at device 
16.3 on pci0
uhci3: [GIANT-LOCKED]
uhci3: [ITHREAD]
usb3: <VIA 83C572 USB controller> on uhci3
usb3: USB revision 1.0
uhub3: <VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1> on usb3
uhub3: 2 ports with 2 removable, self powered
ehci0: <VIA VT6202 USB 2.0 controller> mem 0xe1041000-0xe10410ff irq 21 
at device 16.4 on pci0
ehci0: [GIANT-LOCKED]
ehci0: [ITHREAD]
usb4: EHCI version 1.0
usb4: companion controllers, 2 ports each: usb0 usb1 usb2 usb3
usb4: <VIA VT6202 USB 2.0 controller> on ehci0
usb4: USB revision 2.0
uhub4: <VIA EHCI root hub, class 9/0, rev 2.00/1.00, addr 1> on usb4
uhub4: 8 ports with 8 removable, self powered
isab0: <PCI-ISA bridge> at device 17.0 on pci0
isa0: <ISA bus> on isab0
vr0: <VIA VT6102 Rhine II 10/100BaseTX> port 0xe400-0xe4ff mem 
0xe1042000-0xe10420ff irq 23 at device 18.0 on pci0
vr0: Quirks: 0x0
vr0: Revision: 0x78
miibus0: <MII bus> on vr0
ukphy0: <Generic IEEE 802.3u media interface> PHY 1 on miibus0
ukphy0:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
vr0: Ethernet address: 00:0f:ea:e0:eb:cc
vr0: [ITHREAD]
fdc0: <floppy drive controller> port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on acpi0
fdc0: [FILTER]
fd0: <1440-KB 3.5" drive> on fdc0 drive 0
sio0: configured irq 4 not in bitmap of probed irqs 0
sio0: port may not be enabled
sio0: configured irq 4 not in bitmap of probed irqs 0
sio0: port may not be enabled
sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on 
acpi0
sio0: type 16550A
sio0: [FILTER]
sio1: <16550A-compatible COM port> port 0x2f8-0x2ff irq 3 on acpi0
sio1: type 16550A
sio1: [FILTER]
atkbdc0: <Keyboard controller (i8042)> port 0x60,0x64 irq 1 on acpi0
atkbd0: <AT Keyboard> irq 1 on atkbdc0
kbd0 at atkbd0
atkbd0: [GIANT-LOCKED]
atkbd0: [ITHREAD]
psm0: <PS/2 Mouse> irq 12 on atkbdc0
psm0: [GIANT-LOCKED]
psm0: [ITHREAD]
psm0: model IntelliMouse Explorer, device ID 4
cpu0: <ACPI CPU> on acpi0
pmtimer0 on isa0
orm0: <ISA Option ROMs> at iomem 
0xc0000-0xcafff,0xcc000-0xccfff,0xcd000-0xd0fff,0xd1000-0xd17ff 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
ppc0: <Parallel port> at port 0x378-0x37f irq 7 on isa0
ppc0: Generic chipset (NIBBLE-only) in COMPATIBLE mode
ppbus0: <Parallel port bus> on ppc0
ppbus0: [ITHREAD]
ppi0: <Parallel I/O> on ppbus0
lpt0: <Printer> on ppbus0
lpt0: Interrupt-driven port
ppc0: [GIANT-LOCKED]
ppc0: [ITHREAD]
ucom0: <vendor 0x067b product 0x2303, class 0/0, rev 1.10/2.02, addr 2> 
on uhub1
Timecounter "TSC" frequency 1585747295 Hz quality 800
Timecounters tick every 1.000 msec
ad0: 305244MB <Seagate ST3320620A 3.AAF> at ata0-master UDMA100
acd0: DVDR <HL-DT-ST DVDRAM GSA-4163B/A106> at ata1-master UDMA33
Waiting 5 seconds for SCSI devices to settle
aacd0: <RAID 5> on aac0
aacd0: 953812MB (1953406976 sectors)
GEOM_LABEL: Label for provider fd0 is ufsid/4832e0ff7a2f794e.
GEOM_LABEL: Label for provider fd0 is ufs/SYSBACKUP.
GEOM_LABEL: Label for provider aacd0s1 is ufsid/47e2ca3bf4f15248.
GEOM_LABEL: Label for provider aacd0s1 is ufs/STORAGE.
GEOM_LABEL: Label for provider ad0s1a is ufsid/47f7e9dbde92bc03.
GEOM_LABEL: Label for provider ad0s1a is ufs/TECHROOT.
GEOM_LABEL: Label for provider ad0s1d is ufsid/47f7e7298a3ee160.
GEOM_LABEL: Label for provider ad0s1d is ufs/TECHVAR.
GEOM_LABEL: Label for provider ad0s1e is ufsid/47f7e718650b6911.
GEOM_LABEL: Label for provider ad0s1e is ufs/TECHTMP.
GEOM_LABEL: Label for provider ad0s1f is ufsid/47f8be74c998ed29.
GEOM_LABEL: Label for provider ad0s1f is ufs/TECHUSR.
(probe3:ahc0:0:3:0): TEST UNIT READY. CDB: 0 0 0 0 0 0
(probe3:ahc0:0:3:0): CAM Status: SCSI Status Error
(probe3:ahc0:0:3:0): SCSI Status: Check Condition
(probe3:ahc0:0:3:0): UNIT ATTENTION asc:29,0
(probe3:ahc0:0:3:0): Power on, reset, or bus device reset occurred
(probe3:ahc0:0:3:0): Retrying Command (per Sense Data)
(probe3:ahc0:0:3:0): TEST UNIT READY. CDB: 0 0 0 0 0 0
(probe3:ahc0:0:3:0): CAM Status: SCSI Status Error
(probe3:ahc0:0:3:0): SCSI Status: Check Condition
(probe3:ahc0:0:3:0): NOT READY asc:3a,0
(probe3:ahc0:0:3:0): Medium not present
(probe3:ahc0:0:3:0): Unretryable error
sa0 at ahc0 bus 0 target 3 lun 0
sa0: <HP Ultrium 1-SCSI N2CG> Removable Sequential Access SCSI-3 device
sa0: 20.000MB/s transfers (10.000MHz, offset 8, 16bit)
Trying to mount root from ufs:/dev/ufs/TECHROOT
GEOM_LABEL: Label ufsid/47f7e9dbde92bc03 removed.
GEOM_LABEL: Label ufsid/47f7e718650b6911 removed.
GEOM_LABEL: Label ufsid/47f8be74c998ed29 removed.
GEOM_LABEL: Label ufsid/47e2ca3bf4f15248 removed.
GEOM_LABEL: Label ufsid/47f7e7298a3ee160 removed.
GEOM_LABEL: Label for provider aacd0s1c is ufsid/47e2ca3bf4f15248.
GEOM_LABEL: Label ufsid/47e2ca3bf4f15248 removed.
em0: link state changed to UP
lagg0: link state changed to UP
vr0: link state changed to UP



Thanks and regards,
Yani Karydis
From rnoland at FreeBSD.org  Tue May 12 15:18:24 2009
From: rnoland at FreeBSD.org (Robert Noland)
Date: Tue May 12 15:18:32 2009
Subject: Xorg hangs with drmwtq in 7.2-RELEASE
In-Reply-To: <200905091841.26274.david@usermode.org>
References: <200905042015.29394.david@usermode.org>
	<200905081458.53651.david@usermode.org>
	<1241821864.1733.51.camel@balrog.2hip.net>
	<200905091841.26274.david@usermode.org>
Message-ID: <1242141471.1755.11.camel@balrog.2hip.net>

On Sat, 2009-05-09 at 18:41 -0700, David Johnson wrote:
> On Friday 08 May 2009 03:31:04 pm Robert Noland wrote:
> > In order to guess what might be causing this, drm debugging needs to be
> > enabled before the hang, so that we can hopefully figure out what leads
> > up to the hung GPU.
> 
> I'm not able to do that, but I did manage to get debug turned on and dmesg
> captured early enough to catch some additional information. I've place the
> full file online at http://www.usermode.org/misc/dmesg.txt, but am including
> some snippets here. Hopefully this is enough to move forward.
> 
> -- 
> David Johnson

This trace still looks odd...

> ...
> [drm:pid1822:drm_ioctl] pid=1822, cmd=0xc0286429, nr=0x29, dev 0xc615fa00, auth=1
> [drm:pid1822:radeon_freelist_get] done_age = 102778

Things appear to be working at this point.

> [drm:pid1822:drm_ioctl] pid=1822, cmd=0xc010644d, nr=0x4d, dev 0xc615fa00, auth=1
> [drm:pid1822:radeon_cp_indirect] idx=27 s=0 e=88 d=1
> [drm:pid1822:radeon_cp_dispatch_indirect] buf=27 s=0x0 e=0x58

Now, open count is 2 and something is calling close.

> [drm:pid1822:drm_close] open_count = 2
> [drm:pid1822:drm_close] pid = 1822, device = 0xc615fa00, open_count = 2
> [drm:pid1822:drm_ioctl] pid=1822, cmd=0x80086442, nr=0x42, dev 0xc615fa00, auth=1
> [drm:pid1822:radeon_cp_stop] 
> [drm:pid1822:radeon_do_cp_flush] 
> [drm:pid1822:radeon_do_cp_idle] 
> [drm:pid1822:radeon_do_cp_stop] 
> [drm:pid1822:radeon_do_engine_reset] 
> info: [drm] Num pipes: 1
> [drm:pid1822:radeon_do_cp_reset] 
> [drm:pid1822:drm_ioctl] pid=1822, cmd=0x800c6459, nr=0x59, dev 0xc615fa00, auth=1
> [drm:pid1822:drm_ioctl] pid=1822, cmd=0x80086414, nr=0x14, dev 0xc615fa00, auth=1
> [drm:pid1822:drm_irq_uninstall] irq=16
> [drm:pid1822:drm_ioctl] pid=1822, cmd=0x80546440, nr=0x40, dev 0xc615fa00, auth=1
> [drm:pid1822:radeon_do_cleanup_cp] 
> [drm:pid1822:drm_ioctl] pid=1822, cmd=0x80086439, nr=0x39, dev 0xc615fa00, auth=1
> [drm:pid1822:drm_sg_free] sg free virtual = 0xe8a64000
> [drm:pid1822:drm_ioctl] pid=1822, cmd=0x8004667e, nr=0x7e, dev 0xc615fa00, auth=1
> [drm:pid1822:drm_ioctl] pid=1822, cmd=0x8004667d, nr=0x7d, dev 0xc615fa00, auth=1
> [drm:pid1822:drm_ioctl] pid=1822, cmd=0xc0086421, nr=0x21, dev 0xc615fa00, auth=1
> [drm:pid1822:drm_rmctx] 2
> [drm:pid1822:drm_ioctl] pid=1822, cmd=0xc0086421, nr=0x21, dev 0xc615fa00, auth=1
> [drm:pid1822:drm_rmctx] 1
> [drm:pid1822:drm_ioctl] pid=1822, cmd=0xc0086426, nr=0x26, dev 0xc615fa00, auth=1
> [drm:pid1822:drm_ioctl] pid=1822, cmd=0xc0086426, nr=0x26, dev 0xc615fa00, auth=1
> [drm:pid1822:drm_ioctl] pid=1822, cmd=0x8008642b, nr=0x2b, dev 0xc615fa00, auth=1
> [drm:pid1822:drm_unlock] 1 (pid 1822) requests unlock (0x80000001), flags = 0x00000000

Another close, followed by lastclose, so drm is fully shutdown.

> [drm:pid1822:drm_close] open_count = 1
> [drm:pid1822:drm_close] pid = 1822, device = 0xc615fa00, open_count = 1
> [drm:pid1822:drm_lastclose] 
> [drm:pid1822:radeon_do_cleanup_cp] 

Now, this looks like several vt switches...  We don't see the open
sequence here, so I assume that debugging was disabled at this point.

> info: [drm] Setting GART location based on new memory map
> info: [drm] Loading R500 Microcode
> info: [drm] Num pipes: 1
> info: [drm] writeback test succeeded in 1 usecs
> drm0: [ITHREAD]
> info: [drm] Num pipes: 1
> info: [drm] Setting GART location based on new memory map
> info: [drm] Loading R500 Microcode
> info: [drm] Num pipes: 1
> info: [drm] writeback test succeeded in 1 usecs
> drm0: [ITHREAD]
> info: [drm] Num pipes: 1
> info: [drm] Setting GART location based on new memory map
> info: [drm] Loading R500 Microcode
> info: [drm] Num pipes: 1
> info: [drm] writeback test succeeded in 1 usecs
> drm0: [ITHREAD]
> info: [drm] Num pipes: 1
> info: [drm] Setting GART location based on new memory map
> info: [drm] Loading R500 Microcode
> info: [drm] Num pipes: 1
> info: [drm] writeback test succeeded in 1 usecs
> drm0: [ITHREAD]
> info: [drm] Num pipes: 1
> info: [drm] Setting GART location based on new memory map
> info: [drm] Loading R500 Microcode
> info: [drm] Num pipes: 1
> info: [drm] writeback test succeeded in 1 usecs
> drm0: [ITHREAD]
> info: [drm] Num pipes: 1
> info: [drm] Setting GART location based on new memory map
> info: [drm] Loading R500 Microcode
> info: [drm] Num pipes: 1
> info: [drm] writeback test succeeded in 1 usecs
> drm0: [ITHREAD]
> info: [drm] Num pipes: 1
> info: [drm] Setting GART location based on new memory map
> info: [drm] Loading R500 Microcode
> info: [drm] Num pipes: 1
> info: [drm] writeback test succeeded in 1 usecs
> drm0: [ITHREAD]

and here debugging was re-enabled after the problem has occurred.

> [drm:pid6216:drm_ioctl]     returning 4
> [drm:pid6216:drm_ioctl] pid=6216, cmd=0x80046457, nr=0x57, dev 0xc615fa00, auth=1
> [drm:pid6216:drm_ioctl]     returning 4
> [drm:pid6216:drm_ioctl] pid=6216, cmd=0x80046457, nr=0x57, dev 0xc615fa00, auth=1
> [drm:pid6216:drm_ioctl]     returning 4
> [drm:pid6216:drm_ioctl] pid=6216, cmd=0x80046457, nr=0x57, dev 0xc615fa00, auth=1
> [drm:pid6216:drm_ioctl]     returning 4

robert.

> _______________________________________________
> freebsd-stable@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org"
-- 
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-stable/attachments/20090512/df5b8282/attachment.pgp
From riccardo.torrini at esaote.com  Tue May 12 15:20:17 2009
From: riccardo.torrini at esaote.com (Riccardo Torrini)
Date: Tue May 12 15:20:25 2009
Subject: kern/130330: [mpt] [panic] Panic and reboot machine MPT ...
In-Reply-To: <200905111407.20195.jhb@freebsd.org>
References: <20090507155012.GW21112@tiger.fi.esaote.it>
	<200905110953.21686.jhb@freebsd.org>
	<20090511165522.GG21112@tiger.fi.esaote.it>
	<200905111407.20195.jhb@freebsd.org>
Message-ID: <20090512152014.GN21112@tiger.fi.esaote.it>

On Mon, May 11, 2009 at 02:07:19PM -0400, John Baldwin wrote:

> Do you have kernel crashdumps enabled and a swap partition?
> If so, do you happen to have any files in /var/crash?

Yes, but I'm unable to produce a crash dump  :-(
Tryed even with voodoo, added and removed options to
kernel (kdb, gdb, ddb, invariants, ...).  Instead of
going to db> now it panic-and-freeze with:

cpuid = 0
Uptime: 2m16s
panic: _mtx_lock_sleep: recursed on non-recursive mutex \
	mpt @ /usr/src/sys/cam/cam_periph.h:182

(above lines get repeated a lot with same uptime, then freeze)


Still trying other combinations...


-- 
Riccardo.
From jhb at freebsd.org  Tue May 12 15:48:12 2009
From: jhb at freebsd.org (John Baldwin)
Date: Tue May 12 15:48:23 2009
Subject: lock up in 6.2 (procs massively stuck in Giant)
In-Reply-To: <a31046fc0905112312y2496e5cex334ddcaf57889909@mail.gmail.com>
References: <a31046fc0904292336w17aca317hefd32dad5bc28007@mail.gmail.com>
	<200905110949.31142.jhb@freebsd.org>
	<a31046fc0905112312y2496e5cex334ddcaf57889909@mail.gmail.com>
Message-ID: <200905121014.55450.jhb@freebsd.org>

On Tuesday 12 May 2009 2:12:27 am pluknet wrote:
> 2009/5/11 John Baldwin <jhb@freebsd.org>:
> > On Monday 04 May 2009 11:41:35 pm pluknet wrote:
> >> 2009/5/1 John Baldwin <jhb@freebsd.org>:
> >> > On Thursday 30 April 2009 2:36:34 am pluknet wrote:
> >> >> Hi folks.
> >> >>
> >> >> Today I got a new locking issue.
> >> >> This is the first time I got it, and it's merely reproduced.
> >> >>
> >> >> The box has lost both remote connection and local access.
> >> >> No SIGINFO output on the local console even.
> >> >> Jumping in ddb> shows the next:
> >> >>
> >> >> 1) first, this is a 8-way web server. No processes on runqueue except 
one
> >> > httpd
> >> >> (i.e. ps shows R in its state):
> >> >
> >> > You need to find who owns Giant and what that thread is doing.  You can
> > try
> >> > using 'show lock Giant' as well as 'show lockchain 11568'.
> >> >
> >>
> >> Hi, John!
> >>
> >> Just reproduced now on another box.
> >> Hmm.. stack of the process owing Giant looks garbled.
> >>
> >> db> show lock Giant
> >>  class: sleep mutex
> >>  name: Giant
> >>  flags: {DEF, RECURSE}
> >>  state: {OWNED, CONTESTED}
> >>  owner: 0xd0d79320 (tid 102754, pid 34594, "httpd")
> >>
> >> db> show lockchain 34594
> >> thread 102754 (pid 34594, httpd) running on CPU 7
> >> db> show lockchain 102754
> >> thread 102754 (pid 34594, httpd) running on CPU 7
> >
> > The thread is running, so we don't know what it's top of stack is and you
> > can't a good stack trace in that case.
> >
> > None of your CPUs are idle, so I don't think you have any sort of 
deadlock.
> > You might have a livelock.
> >
> > --
> > John Baldwin
> >
> 
> I'm curious if it could be caused by heavy load.
> I don't know what it might be definitely,
> as it's non-trivial for me to determine the reason
> of a livelock, and to debug it.
> 
> So I think it may have sense to try 7.x, as there
> has been done much locking work.

It may be worth trying 7.  Also, what is the state of the 'swi7: clock' 
process?

-- 
John Baldwin
From jhb at freebsd.org  Tue May 12 15:48:18 2009
From: jhb at freebsd.org (John Baldwin)
Date: Tue May 12 15:48:47 2009
Subject: kern/130330: [mpt] [panic] Panic and reboot machine MPT ...
In-Reply-To: <20090512152014.GN21112@tiger.fi.esaote.it>
References: <20090507155012.GW21112@tiger.fi.esaote.it>
	<200905111407.20195.jhb@freebsd.org>
	<20090512152014.GN21112@tiger.fi.esaote.it>
Message-ID: <200905121144.21406.jhb@freebsd.org>

On Tuesday 12 May 2009 11:20:14 am Riccardo Torrini wrote:
> On Mon, May 11, 2009 at 02:07:19PM -0400, John Baldwin wrote:
> 
> > Do you have kernel crashdumps enabled and a swap partition?
> > If so, do you happen to have any files in /var/crash?
> 
> Yes, but I'm unable to produce a crash dump  :-(
> Tryed even with voodoo, added and removed options to
> kernel (kdb, gdb, ddb, invariants, ...).  Instead of
> going to db> now it panic-and-freeze with:
> 
> cpuid = 0
> Uptime: 2m16s
> panic: _mtx_lock_sleep: recursed on non-recursive mutex \
> 	mpt @ /usr/src/sys/cam/cam_periph.h:182
> 
> (above lines get repeated a lot with same uptime, then freeze)
> 
> 
> Still trying other combinations...

If you can get a stack trace, that would be most helpful.  My guess is that 
the recovery thread is holding the mpt lock and calling some CAM routine 
which attempts to relock it via cam_periph_lock().  A stack trace would be 
most telling in that case.

-- 
John Baldwin
From dudu.meyer at gmail.com  Tue May 12 16:02:00 2009
From: dudu.meyer at gmail.com (Eduardo Meyer)
Date: Tue May 12 16:02:11 2009
Subject: "maxproc limit exceeded" making no sense
In-Reply-To: <20090509061229.GA63615@walton.maths.tcd.ie>
References: <d3ea75b30905080651p1eaba0dep7073cd62c37f8f3f@mail.gmail.com>
	<20090509061229.GA63615@walton.maths.tcd.ie>
Message-ID: <d3ea75b30905120901h69fb83egbb77ee9f48b2b0cc@mail.gmail.com>

On Sat, May 9, 2009 at 3:12 AM, David Malone <dwmalone@maths.tcd.ie> wrote:
> On Fri, May 08, 2009 at 10:51:02AM -0300, Eduardo Meyer wrote:
>> However what I see regarding proc usage is by uid 82 is:
>>
>> # ps -U 82 | wc -l
>>      723
>>
>> Proccess count for UID 82 is never highter than 913 (monitored the
>> last whole hour, while log messages were still showing, complaining
>> about maxproc limit beeing exceeded).
>
> I guess user 82 is exceeding their per-user process limit. This is set
> (traditionally) using the limit or ulimit shell builtins, but can also
> be configured in /etc/login.conf or by certain pam modules. I'd start
> with login.conf.

Hello,

This user is classess, therefore its on default class on login.conf,
and all limits there are "unlimited".

>
>        David.
>



-- 
===========
Eduardo Meyer
pessoal: dudu.meyer@gmail.com
profissional: ddm.farmaciap@saude.gov.br
From dudu.meyer at gmail.com  Tue May 12 16:04:23 2009
From: dudu.meyer at gmail.com (Eduardo Meyer)
Date: Tue May 12 16:04:31 2009
Subject: "maxproc limit exceeded" making no sense
In-Reply-To: <20090509061229.GA63615@walton.maths.tcd.ie>
References: <d3ea75b30905080651p1eaba0dep7073cd62c37f8f3f@mail.gmail.com>
	<20090509061229.GA63615@walton.maths.tcd.ie>
Message-ID: <d3ea75b30905120904n4ec157b5y5ba1e68b1eca90d5@mail.gmail.com>

On Sat, May 9, 2009 at 3:12 AM, David Malone <dwmalone@maths.tcd.ie> wrote:
> On Fri, May 08, 2009 at 10:51:02AM -0300, Eduardo Meyer wrote:
>> However what I see regarding proc usage is by uid 82 is:
>>
>> # ps -U 82 | wc -l
>>      723
>>
>> Proccess count for UID 82 is never highter than 913 (monitored the
>> last whole hour, while log messages were still showing, complaining
>> about maxproc limit beeing exceeded).
>
> I guess user 82 is exceeding their per-user process limit. This is set
> (traditionally) using the limit or ulimit shell builtins, but can also
> be configured in /etc/login.conf or by certain pam modules. I'd start
> with login.conf.

Hello,

This user is classess, therefore its on default class on login.conf,
and all limits there are "unlimited".

>
>        David.
>



-- 
===========
Eduardo Meyer
pessoal: dudu.meyer@gmail.com
profissional: ddm.farmaciap@saude.gov.br
From riccardo.torrini at esaote.com  Tue May 12 16:10:28 2009
From: riccardo.torrini at esaote.com (Riccardo Torrini)
Date: Tue May 12 16:10:35 2009
Subject: kern/130330: [mpt] [panic] Panic and reboot machine MPT ...
In-Reply-To: <200905121144.21406.jhb@freebsd.org>
References: <20090507155012.GW21112@tiger.fi.esaote.it>
	<200905111407.20195.jhb@freebsd.org>
	<20090512152014.GN21112@tiger.fi.esaote.it>
	<200905121144.21406.jhb@freebsd.org>
Message-ID: <20090512161025.GO21112@tiger.fi.esaote.it>

On Tue, May 12, 2009 at 11:44:20AM -0400, John Baldwin wrote:

> If you can get a stack trace, that would be most helpful.
> My guess is that the recovery thread is holding the mpt lock
> and calling some CAM routine which attempts to relock it via
> cam_periph_lock().  A stack trace would be most telling in
> that case.

Rebooted, inserted 2nd disk (copied by hand, sorry for delay)

mpt0: External Bus Reset Detected
mpt0:vol0(mpt:0:0:0): Phisycal Disk Status Changed
mpt0:vol0(mpt:0:0:0): Phisycal Disk Status Changed (yes, two times)
Kernel page fault with the following non-sleepable lock held:
exclusive sleep mutex mpt r = 0 (0xc4001004) locked @ \
	/usr/src/sys/cam/cam_xpt.c:7153
KBD: enter: witness_warn
[ thread pid 19 tid 100018 ]
Stopped at kdb_enter_why+0x3a: movl $0,kbd_why

db> bt
Tracing pid 19 tid 100018 td 0xc3fb8880
[...]
--- trap 0xc, eip = 0xc0438f4e, esp = 0xc43b2b98, ebp = 0xc43b2bb0 ---
xpt_done(c404f400,c0719000,5,5,0,...) at xpt_done+0x1b
xpt_scan_bus(c3f39a80,c4045400,c06cfa7a,c072f824,c4011914,...) \
	at xpt_scan_bus+0x39f
camisr_runqueue(c4001004,0,c06cfa7a,1bf1,0,...) \
	at camisr_runqueue+0x38a
camisr(0,0,c06e99fb,4b6,c3f39a68,...) at camisr+0x10d
ithread_loop()
fork_exit()
fork_trampoline()


Still at db> prompt  =)


-- 
Riccardo.
From jhb at freebsd.org  Tue May 12 18:26:51 2009
From: jhb at freebsd.org (John Baldwin)
Date: Tue May 12 18:27:18 2009
Subject: kern/130330: [mpt] [panic] Panic and reboot machine MPT ...
In-Reply-To: <20090512161025.GO21112@tiger.fi.esaote.it>
References: <20090507155012.GW21112@tiger.fi.esaote.it>
	<200905121144.21406.jhb@freebsd.org>
	<20090512161025.GO21112@tiger.fi.esaote.it>
Message-ID: <200905121426.43467.jhb@freebsd.org>

On Tuesday 12 May 2009 12:10:25 pm Riccardo Torrini wrote:
> On Tue, May 12, 2009 at 11:44:20AM -0400, John Baldwin wrote:
> 
> > If you can get a stack trace, that would be most helpful.
> > My guess is that the recovery thread is holding the mpt lock
> > and calling some CAM routine which attempts to relock it via
> > cam_periph_lock().  A stack trace would be most telling in
> > that case.
> 
> Rebooted, inserted 2nd disk (copied by hand, sorry for delay)
> 
> mpt0: External Bus Reset Detected
> mpt0:vol0(mpt:0:0:0): Phisycal Disk Status Changed
> mpt0:vol0(mpt:0:0:0): Phisycal Disk Status Changed (yes, two times)
> Kernel page fault with the following non-sleepable lock held:
> exclusive sleep mutex mpt r = 0 (0xc4001004) locked @ \
> 	/usr/src/sys/cam/cam_xpt.c:7153
> KBD: enter: witness_warn
> [ thread pid 19 tid 100018 ]
> Stopped at kdb_enter_why+0x3a: movl $0,kbd_why
> 
> db> bt
> Tracing pid 19 tid 100018 td 0xc3fb8880
> [...]
> --- trap 0xc, eip = 0xc0438f4e, esp = 0xc43b2b98, ebp = 0xc43b2bb0 ---
> xpt_done(c404f400,c0719000,5,5,0,...) at xpt_done+0x1b
> xpt_scan_bus(c3f39a80,c4045400,c06cfa7a,c072f824,c4011914,...) \
> 	at xpt_scan_bus+0x39f
> camisr_runqueue(c4001004,0,c06cfa7a,1bf1,0,...) \
> 	at camisr_runqueue+0x38a
> camisr(0,0,c06e99fb,4b6,c3f39a68,...) at camisr+0x10d
> ithread_loop()
> fork_exit()
> fork_trampoline()
> 
> 
> Still at db> prompt  =)

Hmm, this is a different panic. :(  You could perhaps try bzero()'ing the ccb 
before calling xpt_setup_ccb() in mpt_raid_thread() but the old code didn't 
do that either (it just used M_WAITOK w/o M_ZERO).

-- 
John Baldwin
From dsamms at nw-ds.com  Tue May 12 18:35:03 2009
From: dsamms at nw-ds.com (David Samms)
Date: Tue May 12 18:35:11 2009
Subject: TCP differences in 7.2 vs 7.1
Message-ID: <guccc2$8b4$1@ger.gmane.org>

After upgrading to 7.2 (amd64) some customers complained of very poor 
bandwidth.  Upon investigation all the effected customers were ATT DSL 
clients located all over the USA, not in a single city, nor were other 
ISPs effected.  The server is a Supermicro with  dual (quad core) 
processors with a single Intel fxp network card on a 100mbit connection. 
  Kernel is GENERIC for both 7.1_release and 7.2_release.  Normally a 
client can max out their download connection, but for ATT DSL customers 
the transfer rate would be about 5-10KB/s even though the server and 
client where both idle.

Repeated tests were done, from multiple clients in different 
geographical locations.  The problem manifested itself regardless of 
whether ftp, http, smtp, pop, or scp was used, and regardless of the OS 
of the client.  Believing it to be a routing issue we changed the route 
  and even changed the local router the server is connected to so that a 
different NIC port would be used to talk to ATT DSL customers, but no 
change in performance.

Turns out it is somehow related to differences in FreeBSD 7.1 and 7.2. 
If I boot the same server with 7.1, all clients work as you would 
expect.  But, if 7.2 is used all clients with the exception of ATT DSL 
clients would work normally, ATT customers would be limited to 5-10KB/s.

I have no reason to believe there is anything wrong with the ATT DSL 
network, it just happen to be effected by whatever causes the problem.

Any theories?

A special thanks to cybercon.com tech support for being so helpful.  If 
you need a data center, they have good tech support.

From dungeons at gmail.com  Tue May 12 18:40:06 2009
From: dungeons at gmail.com (Pat Wendorf)
Date: Tue May 12 18:40:14 2009
Subject: File system corruption
Message-ID: <2c2c47aa0905121110i6355930bwce3a9c6afb117d4d@mail.gmail.com>

I have a co-lo server I've been maintaining for a few years now running IDE
drives on a mostly terrible UPS.  A few months ago, when it returned from a
power outage (running 6.2-R) I started noticing the following in my daily
security email:

Checking setuid files and devices:
find: /var/db/portsnap/files/2dc95ddff37a8091239e83bf7e3ce5a2c285b027891ced1919d76c9947c5b7db.gz:
Bad file descriptor
find:
/var/db/portsnap/files/52abe8c91385b12272f13f4d20896067d9ba70bdec1fa2575025858bd3e93718.gz:
Bad file descriptor
find: /var/lost+found/#238237: Bad file descriptor

I verified that these files return the same result when trying to do any
operation on them (including ls in the directory).

I've managed to ignore the problem for a while now, and even upgraded to
7.2, but I'm not sure if it will cause problems later on.  So the question
is, without access to the console, how would I fix this?

- Pat
From david at usermode.org  Tue May 12 18:52:38 2009
From: david at usermode.org (David Johnson)
Date: Tue May 12 18:52:45 2009
Subject: Xorg hangs with drmwtq in 7.2-RELEASE
In-Reply-To: <1242141471.1755.11.camel@balrog.2hip.net>
References: <200905042015.29394.david@usermode.org>
	<200905091841.26274.david@usermode.org>
	<1242141471.1755.11.camel@balrog.2hip.net>
Message-ID: <200905121152.29572.david@usermode.org>

On Tuesday 12 May 2009 08:17:51 am Robert Noland wrote:
> On Sat, 2009-05-09 at 18:41 -0700, David Johnson wrote:
> > On Friday 08 May 2009 03:31:04 pm Robert Noland wrote:
> > > In order to guess what might be causing this, drm debugging needs to be
> > > enabled before the hang, so that we can hopefully figure out what leads
> > > up to the hung GPU.
> >
> > I'm not able to do that, but I did manage to get debug turned on and
> > dmesg captured early enough to catch some additional information. I've
> > place the full file online at http://www.usermode.org/misc/dmesg.txt, but
> > am including some snippets here. Hopefully this is enough to move
> > forward.
> >
> > --
> > David Johnson
>
> This trace still looks odd...

This should have been a single trace, with debugging turned after X was hung. 
I turned debug on once, grabbed output of dmesg, then rebooted.

1) Run script to launch four windows in rapid succession.
2) Only two windows manage to make it up before X hangs.
3) Switch over to laptop, which is ssh'd into system
4) sysctl hw.drm.0.debug=1
5) dmesg > dmesg.txt
6) Done

I may have made a mistake though, and briefly turned on debugging earlier in 
the session. I'll get another trace this evening when I have time, to double 
check.

p.s. I've put 7.1-STABLE from March 13th on a different partition. I will add 
in commits until it breaks, to help narrow it down. I'm fairly sure it was 
something on the 15th or 16th.

-- 
David Johnson
From gamato at users.sf.net  Tue May 12 20:33:09 2009
From: gamato at users.sf.net (martinko)
Date: Tue May 12 20:33:17 2009
Subject: run_interrupt_driven_hooks: still waiting after 300 seconds 
 for xpt_config
In-Reply-To: <20090511224957.GB52703@dan.emsphone.com>
References: <4A08A132.3070503@users.sf.net>
	<20090511224957.GB52703@dan.emsphone.com>
Message-ID: <4A09DCF3.3010600@users.sf.net>

Dan Nelson wrote:
> In the last episode (May 12), martinko said:
>> I've just tried 7.2-RELEASE (amd64) on Asus M3A78-EM motherboard and
>> booting got stuck with the following:
>>
>> run_interrupt_driven_hooks: still waiting after 300 seconds for xpt_config
>>
>> From what I've found via Google it should be fixed already but apparently
>> it is not.  :-(
>>
>> Is there a way to work around this issue and successfully boot and install
>> FreeBSD, please ?
> 
> Do you have a connected firewire device?  Try unplugging it during bootup,
> or kldload the sbp module after bootup instead of via loader.conf.
> 

This is booting on fresh new computer from DVD installation media.
And nothing is attached (except USB keyboard and VGA monitor;)).

Btw, I've just tried booting recent PC-BSD (7.1) from USB drive but it 
failed the same way, unfortunately.

Any other ideas how to install FreeBSD on this system, please ?

Cheers,

Martin

From delphij at delphij.net  Tue May 12 20:42:56 2009
From: delphij at delphij.net (Xin LI)
Date: Tue May 12 20:43:03 2009
Subject: TCP differences in 7.2 vs 7.1
In-Reply-To: <guccc2$8b4$1@ger.gmane.org>
References: <guccc2$8b4$1@ger.gmane.org>
Message-ID: <4A09DEF1.2010202@delphij.net>

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

Hi David,

David Samms wrote:
> After upgrading to 7.2 (amd64) some customers complained of very poor
> bandwidth.  Upon investigation all the effected customers were ATT DSL
> clients located all over the USA, not in a single city, nor were other
> ISPs effected.  The server is a Supermicro with  dual (quad core)
> processors with a single Intel fxp network card on a 100mbit connection.

Could you please try if this would help:

	sysctl net.inet.tcp.tso=0

Cheers,
- --
Xin LI <delphij@delphij.net>	http://www.delphij.net/
FreeBSD - The Power to Serve!
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.11 (FreeBSD)

iEYEARECAAYFAkoJ3vAACgkQi+vbBBjt66CKqQCgwPkg1IZnI61Q1+PWfr5sOvVm
n5IAnAzbI5HQXQqyPg+DmzHvCNhzhelI
=oHGO
-----END PGP SIGNATURE-----
From pluknet at gmail.com  Tue May 12 20:59:22 2009
From: pluknet at gmail.com (pluknet)
Date: Tue May 12 20:59:29 2009
Subject: lock up in 6.2 (procs massively stuck in Giant)
In-Reply-To: <200905121014.55450.jhb@freebsd.org>
References: <a31046fc0904292336w17aca317hefd32dad5bc28007@mail.gmail.com>
	<200905110949.31142.jhb@freebsd.org>
	<a31046fc0905112312y2496e5cex334ddcaf57889909@mail.gmail.com>
	<200905121014.55450.jhb@freebsd.org>
Message-ID: <a31046fc0905121359q156d6355ja6a86bf3db193ba2@mail.gmail.com>

2009/5/12 John Baldwin <jhb@freebsd.org>:
> On Tuesday 12 May 2009 2:12:27 am pluknet wrote:
>> 2009/5/11 John Baldwin <jhb@freebsd.org>:
>> > On Monday 04 May 2009 11:41:35 pm pluknet wrote:
>> >> 2009/5/1 John Baldwin <jhb@freebsd.org>:
>> >> > On Thursday 30 April 2009 2:36:34 am pluknet wrote:
>> >> >> Hi folks.
>> >> >>
>> >> >> Today I got a new locking issue.
>> >> >> This is the first time I got it, and it's merely reproduced.
>> >> >>
>> >> >> The box has lost both remote connection and local access.
>> >> >> No SIGINFO output on the local console even.
>> >> >> Jumping in ddb> shows the next:
>> >> >>
>> >> >> 1) first, this is a 8-way web server. No processes on runqueue except
> one
>> >> > httpd
>> >> >> (i.e. ps shows R in its state):
>> >> >
>> >> > You need to find who owns Giant and what that thread is doing.  You can
>> > try
>> >> > using 'show lock Giant' as well as 'show lockchain 11568'.
>> >> >
>> >>
>> >> Hi, John!
>> >>
>> >> Just reproduced now on another box.
>> >> Hmm.. stack of the process owing Giant looks garbled.
>> >>
>> >> db> show lock Giant
>> >>  class: sleep mutex
>> >>  name: Giant
>> >>  flags: {DEF, RECURSE}
>> >>  state: {OWNED, CONTESTED}
>> >>  owner: 0xd0d79320 (tid 102754, pid 34594, "httpd")
>> >>
>> >> db> show lockchain 34594
>> >> thread 102754 (pid 34594, httpd) running on CPU 7
>> >> db> show lockchain 102754
>> >> thread 102754 (pid 34594, httpd) running on CPU 7
>> >
>> > The thread is running, so we don't know what it's top of stack is and you
>> > can't a good stack trace in that case.
>> >
>> > None of your CPUs are idle, so I don't think you have any sort of
> deadlock.
>> > You might have a livelock.
>> >
>> > --
>> > John Baldwin
>> >
>>
>> I'm curious if it could be caused by heavy load.
>> I don't know what it might be definitely,
>> as it's non-trivial for me to determine the reason
>> of a livelock, and to debug it.
>>
>> So I think it may have sense to try 7.x, as there
>> has been done much locking work.
>
> It may be worth trying 7.  Also, what is the state of the 'swi7: clock'
> process?
>
> --
> John Baldwin
>

Hi.

>From just another box (not from the first two mentioned earlier)
with a similar locking issue. If it would make sense, since there are
possibly a bit different conditions.
clock proc here is on swi4, I hope it's a non-important difference.

   18     0     0     0  LL     *Giant    0xd0a6b140 [swi4: clock sio]
db> bt 18
Tracing pid 18 tid 100015 td 0xc7cfec80
sched_switch(c7cfec80,0,1) at sched_switch+0x143
mi_switch(1,0) at mi_switch+0x1ba
turnstile_wait(c0a06c60,cb77ee10) at turnstile_wait+0x2f7
_mtx_lock_sleep(c0a06c60,c7cfec80,0,0,0) at _mtx_lock_sleep+0xfc
softclock(0) at softclock+0x231
ithread_execute_handlers(c7d07218,c7d4a100) at ithread_execute_handlers+0x125
ithread_loop(c7cb69f0,e6892d38) at ithread_loop+0x55
fork_exit(c066d3e4,c7cb69f0,e6892d38) at fork_exit+0x71
fork_trampoline() at fork_trampoline+0x8
--- trap 0x1, eip = 0, esp = 0xe6892d6c, ebp = 0 ---

db> show lock Giant
 class: sleep mutex
 name: Giant
 flags: {DEF, RECURSE}
 state: {OWNED, CONTESTED}
 owner: 0xcb77ee10 (tid 101174, pid 8611, "httpd")
db> show lockchain 101174
thread 101174 (pid 8611, httpd) running on CPU 4
db> bt 101174
Tracing pid 8611 tid 101174 td 0xcb77ee10
sched_switch(cb77ee10,c7f3de10,6) at sched_switch+0x143
mi_switch(ca6d82e8,6,c0a0baf0,ca6d82e8,c0a0a0b0,...) at mi_switch
kseq_move(c0a0baf0,6) at kseq_move+0xc1
sched_balance_pair(ef879bb0,ef879bb0,c08a2adf,cb77ef68,cb77b360,.
         lance_pair+0x91
sched_lock(0,cbd1f658,0,cb77b36c,0,...) at sched_lock
_end(cb77b360,cb77b364,cb77ee10,cb77ee18,0,...) at 0xcb77b360
_end(d0a49a80,d0a49a84,c84cf7d0,c84cf7d8,0,...) at 0xc7f97648
_end(ca6dbcc0,ca6dbcc4,ca6d54b0,ca6d54b8,0,...) at 0xcbd1f648
_end(cbcad780,cbcad784,cc8a2190,cc8a2198,0,...) at 0xc8514430
_end(cab883c0,cab883c4,ca9417d0,ca9417d8,0,...) at 0xca6dc000
_end(cc67c4e0,cc67c4e4,cd6fd000,cd6fd008,0,...) at 0xcc8abc90
_end(cd3a9120,cd3a9124,cd3b1320,cd3b1328,0,...) at 0xcad68218
_end(cd130c60,cd130c64,d00ca320,d00ca328,0,...) at 0xca71e860
_end(cbcac240,cbcac244,cbf6e4b0,cbf6e4b8,0,...) at 0xcd472a78
_end(cb73c960,cb73c964,cb4f44b0,cb4f44b8,0,...) at 0xd00cfa78
_end(ca348b40,ca348b44,ca420af0,ca420af8,0,...) at 0xcc0e9c90
_end(d0310ea0,d0310ea4,cd3ad4b0,cd3ad4b8,0,...) at 0xcc7ec218
_end(ca5ddd20,ca5ddd24,ca6d8c80,ca6d8c88,0,...) at 0xca426c90
_end(c998aa20,c998aa24,ca2bb320,ca2bb328,0,...) at 0xd030fc90
[...] oh, i saw that earlier somewhere.. don't remember where.

db> c
and waiting some moments shows a little different picture:
db> bt 101174
Tracing pid 8611 tid 101174 td 0xcb77ee10
sched_switch(cb77ee10,c7f3de10,6) at sched_switch+0x143
mi_switch(cf177608,7,c0a0b460,cf177608,c0a0a0b0,...) at mi_switch+0x1ba
kseq_move(c0a0b460,7) at kseq_move+0xc1
sched_balance_pair(cb77ef68,ef879bb8,c0694edf,cb77ef68,cb77b360,...)
at sched_balance_pair+0x91
_end(cbd1f650,cb77ee10,cb77ee20,0,cb77b374,...) at 0xcb77b360
MAXCPU(cb77b360,cb77b364,cb77ee10,cb77ee18,0,...) at 0
_end(d0a49a80,d0a49a84,c84cf7d0,c84cf7d8,0,...) at 0xc7f97648
_end(ca6dbcc0,ca6dbcc4,ca6d54b0,ca6d54b8,0,...) at 0xcbd1f648
_end(cbcad780,cbcad784,cc8a2190,cc8a2198,0,...) at 0xc8514430
_end(cab883c0,cab883c4,ca9417d0,ca9417d8,0,...) at 0xca6dc000
_end(cc67c4e0,cc67c4e4,cd6fd000,cd6fd008,0,...) at 0xcc8abc90
_end(cd3a9120,cd3a9124,cd3b1320,cd3b1328,0,...) at 0xcad68218
_end(cd130c60,cd130c64,d00ca320,d00ca328,0,...) at 0xca71e860
_end(cbcac240,cbcac244,cbf6e4b0,cbf6e4b8,0,...) at 0xcd472a78
[...]

-- 
wbr,
pluknet
From dsamms at nw-ds.com  Tue May 12 21:31:14 2009
From: dsamms at nw-ds.com (David Samms)
Date: Tue May 12 21:31:20 2009
Subject: TCP differences in 7.2 vs 7.1
In-Reply-To: <4A09DEF1.2010202@delphij.net>
References: <guccc2$8b4$1@ger.gmane.org> <4A09DEF1.2010202@delphij.net>
Message-ID: <4A09EA95.7050800@nw-ds.com>

Xin LI wrote:
> Hi David,
> 
> David Samms wrote:
>> After upgrading to 7.2 (amd64) some customers complained of very poor
>> bandwidth.  Upon investigation all the effected customers were ATT DSL
>> clients located all over the USA, not in a single city, nor were other
>> ISPs effected.  The server is a Supermicro with  dual (quad core)
>> processors with a single Intel fxp network card on a 100mbit connection.
> 
> Could you please try if this would help:
> 
> 	sysctl net.inet.tcp.tso=0
> 
> Cheers,
> - --
> Xin LI <delphij@delphij.net>	http://www.delphij.net/
> FreeBSD - The Power to Serve!

Xin LI,

Thank you for your help.

Setting sysctl net.inet.tcp.tso=0 resolved the issue completely.   What 
does sysctl net.inet.tcp.tso=0 do?  Where can I read more about the 
option?  I captured tcpdumps of a single file transfer to 7.1, 7.2 and 
7.2 with sysctl net.inet.tcp.tso=0, but they are to large to attach to 
this list.  Let me know if you are interested in viewing the dump files.

Thanks again for your assistance!

From peo at intersonic.se  Tue May 12 21:54:59 2009
From: peo at intersonic.se (Per olof Ljungmark)
Date: Tue May 12 21:55:07 2009
Subject: CAM Status: SCSI Status Error on 7.2-RELEASE
In-Reply-To: <4A098115.3040605@pi-greece.eu>
References: <4A098115.3040605@pi-greece.eu>
Message-ID: <4A09EC89.5090400@intersonic.se>

Yani Karydis wrote:
> Hello,
> 
> Since upgrading to 7.2-RELEASE, dmesg displays the following after 
> booting the system.
> 
> (probe3:ahc0:0:3:0): TEST UNIT READY. CDB: 0 0 0 0 0 0
> (probe3:ahc0:0:3:0): CAM Status: SCSI Status Error
> (probe3:ahc0:0:3:0): SCSI Status: Check Condition
> (probe3:ahc0:0:3:0): UNIT ATTENTION asc:29,0
> (probe3:ahc0:0:3:0): Power on, reset, or bus device reset occurred
> (probe3:ahc0:0:3:0): Retrying Command (per Sense Data)
> (probe3:ahc0:0:3:0): TEST UNIT READY. CDB: 0 0 0 0 0 0
> (probe3:ahc0:0:3:0): CAM Status: SCSI Status Error
> (probe3:ahc0:0:3:0): SCSI Status: Check Condition
> (probe3:ahc0:0:3:0): NOT READY asc:3a,0
> (probe3:ahc0:0:3:0): Medium not present
> (probe3:ahc0:0:3:0): Unretryable error
> sa0 at ahc0 bus 0 target 3 lun 0
> sa0: <HP Ultrium 1-SCSI N2CG> Removable Sequential Access SCSI-3 device
> sa0: 20.000MB/s transfers (10.000MHz, offset 8, 16bit)
> 
<snip>

FWIW, same here, 7.2-PRERELEASE #0: Thu Apr 16 08:42:45 CEST 2009 amd64 
and HP Ultrium drive. Did not notice any harm though.

--
per
From rick-freebsd2008 at kiwi-computer.com  Tue May 12 22:03:17 2009
From: rick-freebsd2008 at kiwi-computer.com (Rick C. Petty)
Date: Tue May 12 22:03:24 2009
Subject: TCP differences in 7.2 vs 7.1
In-Reply-To: <4A09EA95.7050800@nw-ds.com>
References: <guccc2$8b4$1@ger.gmane.org> <4A09DEF1.2010202@delphij.net>
	<4A09EA95.7050800@nw-ds.com>
Message-ID: <20090512213635.GA27579@keira.kiwi-computer.com>

On Tue, May 12, 2009 at 05:31:01PM -0400, David Samms wrote:
> 
> Setting sysctl net.inet.tcp.tso=0 resolved the issue completely.   What 
> does sysctl net.inet.tcp.tso=0 do?

# sysctl -d net.inet.tcp.tso
net.inet.tcp.tso: Enable TCP Segmentation Offload

I had a similar problem with a different NIC.  This option controls whether
we offload segmenting to the NIC.  My NIC seemed to be limited by the
number of interrupts which could be delivered.  You can also do this on a
card-by-card basis using "ifconfig <interface> -tso".

-- Rick C. Petty
From delphij at delphij.net  Tue May 12 22:11:59 2009
From: delphij at delphij.net (Xin LI)
Date: Tue May 12 22:12:30 2009
Subject: TCP differences in 7.2 vs 7.1
In-Reply-To: <4A09EA95.7050800@nw-ds.com>
References: <guccc2$8b4$1@ger.gmane.org> <4A09DEF1.2010202@delphij.net>
	<4A09EA95.7050800@nw-ds.com>
Message-ID: <4A09F3D0.1050308@delphij.net>

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

Hi, David,

David Samms wrote:
> Xin LI wrote:
>> Hi David,
>>
>> David Samms wrote:
>>> After upgrading to 7.2 (amd64) some customers complained of very poor
>>> bandwidth.  Upon investigation all the effected customers were ATT DSL
>>> clients located all over the USA, not in a single city, nor were other
>>> ISPs effected.  The server is a Supermicro with  dual (quad core)
>>> processors with a single Intel fxp network card on a 100mbit connection.
>>
>> Could you please try if this would help:
>>
>>     sysctl net.inet.tcp.tso=0
>>
>> Cheers,
>> - --
>> Xin LI <delphij@delphij.net>    http://www.delphij.net/
>> FreeBSD - The Power to Serve!
> 
> Xin LI,
> 
> Thank you for your help.
> 
> Setting sysctl net.inet.tcp.tso=0 resolved the issue completely.   What
> does sysctl net.inet.tcp.tso=0 do?  Where can I read more about the
> option?  I captured tcpdumps of a single file transfer to 7.1, 7.2 and
> 7.2 with sysctl net.inet.tcp.tso=0, but they are to large to attach to
> this list.  Let me know if you are interested in viewing the dump files.
> 
> Thanks again for your assistance!

Thanks for the offer but I think this is a known problem so perhaps the
dump files are no longer necessary.  The problem was caused by the
reciever side (usually PPPoE clients, e.g. DSL users) which proposes a
smaller MSS than the interface MTU, the previous implementation sets the
packet length to interface MTU instead of the negotiated one, which
would cause problem.

Setting net.inet.tcp.tso=0 would turn off TCP Segment Offloading
completely.  The previous release of FreeBSD does not include this feature.

I think yongari@ has committed a fix as revision 191867 (RELENG_7) and
190982 (HEAD):

Index: if_fxp.c
===================================================================
- --- if_fxp.c	(revision 190981)
+++ if_fxp.c	(revision 190982)
@@ -1485,7 +1485,8 @@
 		 * checksum in the first frame driver should compute it.
 		 */
 		ip->ip_sum = 0;
- -		ip->ip_len = htons(ifp->if_mtu);
+		ip->ip_len = htons(m->m_pkthdr.tso_segsz + (ip->ip_hl << 2) +
+		    (tcp->th_off << 2));
 		tcp->th_sum = in_pseudo(ip->ip_src.s_addr, ip->ip_dst.s_addr,
 		    htons(IPPROTO_TCP + (tcp->th_off << 2) +
 		    m->m_pkthdr.tso_segsz));

To re@:

Perhaps we should issue an errata for this, at least document it in
errata (I can do this)?

Cheers,
- --
Xin LI <delphij@delphij.net>	http://www.delphij.net/
FreeBSD - The Power to Serve!
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.11 (FreeBSD)

iEYEARECAAYFAkoJ89AACgkQi+vbBBjt66B85ACeNJjEuVXitnceaC6GRG+9zWtB
OaUAoLqikyZXMEngwkLEtHboaDiQp8QI
=mcFR
-----END PGP SIGNATURE-----
From freebsd at eyede.com  Tue May 12 23:13:32 2009
From: freebsd at eyede.com (Nigel Wohlers)
Date: Tue May 12 23:13:39 2009
Subject: TCP differences in 7.2 vs 7.1
In-Reply-To: <4A09DEF1.2010202@delphij.net>
References: <guccc2$8b4$1@ger.gmane.org> <4A09DEF1.2010202@delphij.net>
Message-ID: <4A09FDB2.5080307@eyede.com>

On 13/5/09 8:41 AM, Xin LI wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hi David,
>
> David Samms wrote:
>> After upgrading to 7.2 (amd64) some customers complained of very poor
>> bandwidth.  Upon investigation all the effected customers were ATT DSL
>> clients located all over the USA, not in a single city, nor were other
>> ISPs effected.  The server is a Supermicro with  dual (quad core)
>> processors with a single Intel fxp network card on a 100mbit connection.
>
> Could you please try if this would help:
>
> 	sysctl net.inet.tcp.tso=0
>
> Cheers,
> - --
> Xin LI<delphij@delphij.net>	http://www.delphij.net/


Thank you!  This hint has saved me a lot of troubleshooting.

I was having the same issue as David with 3 servers recently upgraded to 
7.2.  Clients (MS Windows) were complaining that they were having 
intermittent connectivity issues talking to these servers (https, imaps).

They too have fxp network interface cards, no issues with other servers 
upgraded to 7.2 with em cards.

Thanks again.

Regards,
Nigel.
From pyunyh at gmail.com  Wed May 13 00:33:10 2009
From: pyunyh at gmail.com (Pyun YongHyeon)
Date: Wed May 13 00:33:16 2009
Subject: TCP differences in 7.2 vs 7.1
In-Reply-To: <4A09FDB2.5080307@eyede.com>
References: <guccc2$8b4$1@ger.gmane.org> <4A09DEF1.2010202@delphij.net>
	<4A09FDB2.5080307@eyede.com>
Message-ID: <20090513004131.GP65350@michelle.cdnetworks.co.kr>

On Wed, May 13, 2009 at 10:52:34AM +1200, Nigel Wohlers wrote:
> On 13/5/09 8:41 AM, Xin LI wrote:
> >-----BEGIN PGP SIGNED MESSAGE-----
> >Hash: SHA1
> >
> >Hi David,
> >
> >David Samms wrote:
> >>After upgrading to 7.2 (amd64) some customers complained of very poor
> >>bandwidth.  Upon investigation all the effected customers were ATT DSL
> >>clients located all over the USA, not in a single city, nor were other
> >>ISPs effected.  The server is a Supermicro with  dual (quad core)
> >>processors with a single Intel fxp network card on a 100mbit connection.
> >
> >Could you please try if this would help:
> >
> >	sysctl net.inet.tcp.tso=0
> >
> >Cheers,
> >- --
> >Xin LI<delphij@delphij.net>	http://www.delphij.net/
> 
> 
> Thank you!  This hint has saved me a lot of troubleshooting.
> 
> I was having the same issue as David with 3 servers recently upgraded to 
> 7.2.  Clients (MS Windows) were complaining that they were having 
> intermittent connectivity issues talking to these servers (https, imaps).
> 
> They too have fxp network interface cards, no issues with other servers 
> upgraded to 7.2 with em cards.
> 

Instead of disabling TSO in network stack, just disable TSO in
fxp(4) as a workaround. Fix already is in RELENG_7(r191867) so you
can extract the patch and apply it by hand if you want.

For instance,
#cd /tmp
#fetch -o fxp.tso.patch "http://svn.freebsd.org/viewvc/base/head/sys/dev/fxp/if_fxp.c?r1=190982&r2=188176&view=patch"
#cd /usr/src/sys/dev/fxp
#patch -p4 < /tmp/fxp.tso.patch
And rebuild kernel.
From jhb at freebsd.org  Wed May 13 00:47:13 2009
From: jhb at freebsd.org (John Baldwin)
Date: Wed May 13 00:47:19 2009
Subject: lock up in 6.2 (procs massively stuck in Giant)
In-Reply-To: <a31046fc0905121359q156d6355ja6a86bf3db193ba2@mail.gmail.com>
References: <a31046fc0904292336w17aca317hefd32dad5bc28007@mail.gmail.com>
	<200905121014.55450.jhb@freebsd.org>
	<a31046fc0905121359q156d6355ja6a86bf3db193ba2@mail.gmail.com>
Message-ID: <200905122046.43048.jhb@freebsd.org>

On Tuesday 12 May 2009 4:59:19 pm pluknet wrote:
> Hi.
> 
> From just another box (not from the first two mentioned earlier)
> with a similar locking issue. If it would make sense, since there are
> possibly a bit different conditions.
> clock proc here is on swi4, I hope it's a non-important difference.
> 
>    18     0     0     0  LL     *Giant    0xd0a6b140 [swi4: clock sio]
> db> bt 18

Ok, this is a known issue in 6.x.  It is fixed in 6.4.

-- 
John Baldwin
From pluknet at gmail.com  Wed May 13 05:45:05 2009
From: pluknet at gmail.com (pluknet)
Date: Wed May 13 05:45:12 2009
Subject: lock up in 6.2 (procs massively stuck in Giant)
In-Reply-To: <200905122046.43048.jhb@freebsd.org>
References: <a31046fc0904292336w17aca317hefd32dad5bc28007@mail.gmail.com>
	<200905121014.55450.jhb@freebsd.org>
	<a31046fc0905121359q156d6355ja6a86bf3db193ba2@mail.gmail.com>
	<200905122046.43048.jhb@freebsd.org>
Message-ID: <a31046fc0905122245k4ac946c0lcbd29d4557cafab8@mail.gmail.com>

2009/5/13 John Baldwin <jhb@freebsd.org>:
> On Tuesday 12 May 2009 4:59:19 pm pluknet wrote:
>> Hi.
>>
>> From just another box (not from the first two mentioned earlier)
>> with a similar locking issue. If it would make sense, since there are
>> possibly a bit different conditions.
>> clock proc here is on swi4, I hope it's a non-important difference.
>>
>>    18     0     0     0  LL     *Giant    0xd0a6b140 [swi4: clock sio]
>> db> bt 18
>
> Ok, this is a known issue in 6.x.  It is fixed in 6.4.
>

Thank you very much!

-- 
wbr,
pluknet
From david at usermode.org  Wed May 13 05:57:42 2009
From: david at usermode.org (David Johnson)
Date: Wed May 13 05:57:50 2009
Subject: Xorg hangs with drmwtq in 7.2-RELEASE
In-Reply-To: <200905121152.29572.david@usermode.org>
References: <200905042015.29394.david@usermode.org>
	<1242141471.1755.11.camel@balrog.2hip.net>
	<200905121152.29572.david@usermode.org>
Message-ID: <200905122257.39353.david@usermode.org>

On Tuesday 12 May 2009 11:52:29 am David Johnson wrote:
> I may have made a mistake though, and briefly turned on debugging earlier
> in the session. I'll get another trace this evening when I have time, to
> double check.

Yup, I must have turned on debugging earlier in that session. All I can get 
now is that repetitous drm_ioctl.

-- 
David Johnson
From pluknet at gmail.com  Wed May 13 06:40:35 2009
From: pluknet at gmail.com (pluknet)
Date: Wed May 13 06:40:42 2009
Subject: lock up in 6.2 (procs massively stuck in Giant)
In-Reply-To: <a31046fc0905122245k4ac946c0lcbd29d4557cafab8@mail.gmail.com>
References: <a31046fc0904292336w17aca317hefd32dad5bc28007@mail.gmail.com>
	<200905121014.55450.jhb@freebsd.org>
	<a31046fc0905121359q156d6355ja6a86bf3db193ba2@mail.gmail.com>
	<200905122046.43048.jhb@freebsd.org>
	<a31046fc0905122245k4ac946c0lcbd29d4557cafab8@mail.gmail.com>
Message-ID: <a31046fc0905122340n55785cben89c81736ec790e4c@mail.gmail.com>

2009/5/13 pluknet <pluknet@gmail.com>:
> 2009/5/13 John Baldwin <jhb@freebsd.org>:
>> On Tuesday 12 May 2009 4:59:19 pm pluknet wrote:
>>> Hi.
>>>
>>> From just another box (not from the first two mentioned earlier)
>>> with a similar locking issue. If it would make sense, since there are
>>> possibly a bit different conditions.
>>> clock proc here is on swi4, I hope it's a non-important difference.
>>>
>>>    18     0     0     0  LL     *Giant    0xd0a6b140 [swi4: clock sio]
>>> db> bt 18
>>
>> Ok, this is a known issue in 6.x.  It is fixed in 6.4.
>>

Looking at the face of kern_timeout.c I suspect that was fixed in r181012.

Thanks again for the tips.

-- 
wbr,
pluknet
From scrappy at hub.org  Wed May 13 07:09:39 2009
From: scrappy at hub.org (Marc G. Fournier)
Date: Wed May 13 07:09:46 2009
Subject: More data on 7.2-RELEASE "hangs"
Message-ID: <20090513040719.D17646@hub.org>


Don't know if this helps with anything, but it just hung after 2days again 
... nothing on the console ... top process running at the time shows the 
following ... anything there look "concerning"?

last pid:  5196;  load averages:  9.25, 15.97, 10.07 
up 2+07:58:36  04:02:28
1874 processes:317 running, 1537 sleeping, 20 zombie
CPU:  6.2% user,  0.0% nice,  6.7% system,  0.3% interrupt, 86.8% idle
Mem: 4552M Active, 162M Inact, 684M Wired, 46M Cache, 399M Buf, 8240K Free
Swap: 8192M Total, 1308M Used, 6884M Free, 15% Inuse, 1360K In, 63M Out

   PID USERNAME  THR PRI NICE   SIZE    RES STATE  C   TIME   WCPU COMMAND
28752 root        5  96    0   427M   408M select 1   1:55  0.00% named
  9720 nobody     19  97    0   402M   186M RUN    1   0:00  0.69% nsd
54395 root       16  20    0  1308M   163M kserel 0   0:00  0.00% java
  8500 nobody     10 102    0   193M 86492K ucond  1   0:07  0.00% nsd
  3302    102      1  96    0   158M 66100K select 1   0:37  0.00% postgres
  7853   1304      1  96    0   154M 54408K select 1   0:39  0.00% postgres
10670     88     28  20    0   335M 42488K kserel 0   0:00  0.44% mysqld
  4976 root        5   4    0 95444K 41740K kqread 1   1:09  0.00% named
14003 www        44  96    0   443M 41632K ucond  1   0:00  0.00% java
  8528 nobody     15  96    0   188M 37904K ucond  1   0:00  0.00% nsd
  5157     88    109  96    0 97620K 33704K RUN    0   0:00  0.00% mysqld
  1759 www         1   4    0   167M 32276K select 1   0:01  0.00% httpd
99407 www         1   4    0   165M 31712K sbwait 0   0:02  0.00% httpd
  4006 www         1   4    0   124M 31424K sbwait 1   0:01  0.29% httpd
  1299 www         1   4    0   164M 31376K sbwait 1   0:02  0.00% httpd
  1758 www         1   4    0   164M 31176K sbwait 0   0:02  0.00% httpd
99402 www         1  96    0   163M 29892K CPU1   1   0:03  0.00% httpd
  4036 www         1  20    0   122M 28680K lockf  1   0:00  0.00% httpd
  1757 www         1   4    0   158M 27856K sbwait 1   0:02  0.00% httpd
  3899 www         1  96    0   160M 27688K RUN    0   0:00  0.00% httpd
  4007 www         1  20    0   125M 27588K lockf  0   0:01  2.10% httpd
  4525 www         1  96    0   158M 26624K RUN    1   0:00  0.00% httpd
  4607 www         1  96    0   158M 26096K RUN    0   0:00  0.00% httpd
13635     88     34  96    0 92340K 25604K CPU0   0   0:00  0.05% mysqld
  4024 www         1  96    0   156M 24880K RUN    1   0:00  0.10% httpd
  3585    102      1   4    0   163M 24748K sbwait 1   2:56  0.00% postgres
  3951 www         1  96    0   155M 24548K RUN    1   0:00  0.10% httpd
  4022 www         1  96    0   155M 24320K RUN    0   0:00  0.00% httpd
  3960 www         1  96    0   155M 24316K RUN    1   0:00  0.00% httpd
  3388    102      1   4    0   161M 24228K sbwait 0   1:07  0.00% postgres
  4023 www         1  96    0   155M 23988K RUN    1   0:00  0.00% httpd
99468 www         1  96    0   104M 23660K RUN    1   0:03  0.00% httpd
99423 www         1   4    0   154M 23456K sbwait 0   0:03  0.00% httpd
  3959 www         1  -4    0   103M 23144K devfs  0   0:00  0.00% httpd
  5004 www         1   4    0   154M 23032K sbwait 1   0:00  0.00% httpd
62771 www         1 -16    0   143M 22824K vnread 1   0:01  0.00% httpd
  4612 www         1  96    0   153M 21936K RUN    1   0:00  0.15% httpd
  4609 www         1  96    0   153M 21936K RUN    0   0:00  0.05% httpd
  5180 www         1  96    0   145M 21660K RUN    0   0:12  0.00% httpd
  5007 www         1   4    0   115M 21360K sbwait 0   0:00  0.29% httpd
57327 www         1  -8    0   145M 20996K biord  0   0:04  0.20% httpd
29064 www         1  -8    0   143M 20812K biord  1   0:04  0.00% httpd
99381 www         1  96    0   151M 19364K RUN    1   0:04  0.00% httpd
  4682 root        1   4    0 62388K 17828K kqread 1   0:00  0.00% perl
  9447     88      8  20    0 61388K 17508K kserel 0   0:00  0.05% mysqld
13457 bind        5  96    0 45724K 17424K RUN    0   0:14  0.00% named
87535 www         1   4    0   149M 17396K sbwait 1   0:09  0.00% httpd
  4611 www         1   4    0   146M 17008K sbwait 1   0:00  0.00% httpd
  3386    102      1  -4    0   163M 16544K semwai 0   0:51  0.00% postgres
91929 www         1   4    0   113M 16196K sbwait 0   0:04  0.00% httpd
  4757 www         1  96    0   145M 16144K RUN    0   0:00  0.00% httpd
10269     88      5  20    0 57504K 16000K kserel 0   0:00  0.00% mysqld
  3946 www         1   4    0   126M 15552K sbwait 1   0:01 15.00% httpd
  3619 www         1   4    0   113M 15172K sbwait 1   0:00  0.00% httpd
  3385    102      1  96    0   163M 14932K RUN    1   0:50  0.00% postgres
28755    102      1   4    0   159M 14760K sbwait 0  31:36  0.35% postgres

----
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 delphij at delphij.net  Wed May 13 07:17:06 2009
From: delphij at delphij.net (Xin LI)
Date: Wed May 13 07:17:14 2009
Subject: More data on 7.2-RELEASE "hangs"
In-Reply-To: <20090513040719.D17646@hub.org>
References: <20090513040719.D17646@hub.org>
Message-ID: <4A0A739F.4010809@delphij.net>

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

Marc G. Fournier wrote:
> 
> Don't know if this helps with anything, but it just hung after 2days
> again ... nothing on the console ... top process running at the time
> shows the following ... anything there look "concerning"?

Looks like a dead/livelock between devfs and ufs but I don't have
further hints about this.  Last time we have this was the 7.0 age and
upgrading to 7.1 fixed it IIRC...

> last pid:  5196;  load averages:  9.25, 15.97, 10.07 up 2+07:58:36 
> 04:02:28
> 1874 processes:317 running, 1537 sleeping, 20 zombie
> CPU:  6.2% user,  0.0% nice,  6.7% system,  0.3% interrupt, 86.8% idle
> Mem: 4552M Active, 162M Inact, 684M Wired, 46M Cache, 399M Buf, 8240K Free
> Swap: 8192M Total, 1308M Used, 6884M Free, 15% Inuse, 1360K In, 63M Out
> 
>   PID USERNAME  THR PRI NICE   SIZE    RES STATE  C   TIME   WCPU COMMAND
> 28752 root        5  96    0   427M   408M select 1   1:55  0.00% named
>  9720 nobody     19  97    0   402M   186M RUN    1   0:00  0.69% nsd
> 54395 root       16  20    0  1308M   163M kserel 0   0:00  0.00% java
>  8500 nobody     10 102    0   193M 86492K ucond  1   0:07  0.00% nsd
>  3302    102      1  96    0   158M 66100K select 1   0:37  0.00% postgres
>  7853   1304      1  96    0   154M 54408K select 1   0:39  0.00% postgres
> 10670     88     28  20    0   335M 42488K kserel 0   0:00  0.44% mysqld
>  4976 root        5   4    0 95444K 41740K kqread 1   1:09  0.00% named
> 14003 www        44  96    0   443M 41632K ucond  1   0:00  0.00% java
>  8528 nobody     15  96    0   188M 37904K ucond  1   0:00  0.00% nsd
>  5157     88    109  96    0 97620K 33704K RUN    0   0:00  0.00% mysqld
>  1759 www         1   4    0   167M 32276K select 1   0:01  0.00% httpd
> 99407 www         1   4    0   165M 31712K sbwait 0   0:02  0.00% httpd
>  4006 www         1   4    0   124M 31424K sbwait 1   0:01  0.29% httpd
>  1299 www         1   4    0   164M 31376K sbwait 1   0:02  0.00% httpd
>  1758 www         1   4    0   164M 31176K sbwait 0   0:02  0.00% httpd
> 99402 www         1  96    0   163M 29892K CPU1   1   0:03  0.00% httpd
>  4036 www         1  20    0   122M 28680K lockf  1   0:00  0.00% httpd
>  1757 www         1   4    0   158M 27856K sbwait 1   0:02  0.00% httpd
>  3899 www         1  96    0   160M 27688K RUN    0   0:00  0.00% httpd
>  4007 www         1  20    0   125M 27588K lockf  0   0:01  2.10% httpd
>  4525 www         1  96    0   158M 26624K RUN    1   0:00  0.00% httpd
>  4607 www         1  96    0   158M 26096K RUN    0   0:00  0.00% httpd
> 13635     88     34  96    0 92340K 25604K CPU0   0   0:00  0.05% mysqld
>  4024 www         1  96    0   156M 24880K RUN    1   0:00  0.10% httpd
>  3585    102      1   4    0   163M 24748K sbwait 1   2:56  0.00% postgres
>  3951 www         1  96    0   155M 24548K RUN    1   0:00  0.10% httpd
>  4022 www         1  96    0   155M 24320K RUN    0   0:00  0.00% httpd
>  3960 www         1  96    0   155M 24316K RUN    1   0:00  0.00% httpd
>  3388    102      1   4    0   161M 24228K sbwait 0   1:07  0.00% postgres
>  4023 www         1  96    0   155M 23988K RUN    1   0:00  0.00% httpd
> 99468 www         1  96    0   104M 23660K RUN    1   0:03  0.00% httpd
> 99423 www         1   4    0   154M 23456K sbwait 0   0:03  0.00% httpd
>  3959 www         1  -4    0   103M 23144K devfs  0   0:00  0.00% httpd
>  5004 www         1   4    0   154M 23032K sbwait 1   0:00  0.00% httpd
> 62771 www         1 -16    0   143M 22824K vnread 1   0:01  0.00% httpd
>  4612 www         1  96    0   153M 21936K RUN    1   0:00  0.15% httpd
>  4609 www         1  96    0   153M 21936K RUN    0   0:00  0.05% httpd
>  5180 www         1  96    0   145M 21660K RUN    0   0:12  0.00% httpd
>  5007 www         1   4    0   115M 21360K sbwait 0   0:00  0.29% httpd
> 57327 www         1  -8    0   145M 20996K biord  0   0:04  0.20% httpd
> 29064 www         1  -8    0   143M 20812K biord  1   0:04  0.00% httpd
> 99381 www         1  96    0   151M 19364K RUN    1   0:04  0.00% httpd
>  4682 root        1   4    0 62388K 17828K kqread 1   0:00  0.00% perl
>  9447     88      8  20    0 61388K 17508K kserel 0   0:00  0.05% mysqld
> 13457 bind        5  96    0 45724K 17424K RUN    0   0:14  0.00% named
> 87535 www         1   4    0   149M 17396K sbwait 1   0:09  0.00% httpd
>  4611 www         1   4    0   146M 17008K sbwait 1   0:00  0.00% httpd
>  3386    102      1  -4    0   163M 16544K semwai 0   0:51  0.00% postgres
> 91929 www         1   4    0   113M 16196K sbwait 0   0:04  0.00% httpd
>  4757 www         1  96    0   145M 16144K RUN    0   0:00  0.00% httpd
> 10269     88      5  20    0 57504K 16000K kserel 0   0:00  0.00% mysqld
>  3946 www         1   4    0   126M 15552K sbwait 1   0:01 15.00% httpd
>  3619 www         1   4    0   113M 15172K sbwait 1   0:00  0.00% httpd
>  3385    102      1  96    0   163M 14932K RUN    1   0:50  0.00% postgres
> 28755    102      1   4    0   159M 14760K sbwait 0  31:36  0.35% postgres
> 
> ----
> 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
> _______________________________________________
> freebsd-stable@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org"


- --
Xin LI <delphij@delphij.net>	http://www.delphij.net/
FreeBSD - The Power to Serve!
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.11 (FreeBSD)

iEYEARECAAYFAkoKc5oACgkQi+vbBBjt66DzYACfXvyb+8mB0x2jAq4z/shQ8MAS
kEcAnix1xKt10A5c1aMqQK4ImJoWX/Ny
=AIYf
-----END PGP SIGNATURE-----
From milu at dat.pl  Wed May 13 09:42:58 2009
From: milu at dat.pl (Maciej Milewski)
Date: Wed May 13 09:43:05 2009
Subject: File system corruption
In-Reply-To: <2c2c47aa0905121110i6355930bwce3a9c6afb117d4d@mail.gmail.com>
References: <2c2c47aa0905121110i6355930bwce3a9c6afb117d4d@mail.gmail.com>
Message-ID: <200905131124.16897.milu@dat.pl>

Tuesday 12 May 2009 20:10:57 Pat Wendorf napisa?(a):
> I have a co-lo server I've been maintaining for a few years now running IDE
> drives on a mostly terrible UPS.  A few months ago, when it returned from a
> power outage (running 6.2-R) I started noticing the following in my daily
> security email:
>
> Checking setuid files and devices:
> find:
> /var/db/portsnap/files/2dc95ddff37a8091239e83bf7e3ce5a2c285b027891ced1919d7
>6c9947c5b7db.gz: Bad file descriptor
> find:
> /var/db/portsnap/files/52abe8c91385b12272f13f4d20896067d9ba70bdec1fa2575025
>858bd3e93718.gz: Bad file descriptor
> find: /var/lost+found/#238237: Bad file descriptor
>
> I verified that these files return the same result when trying to do any
> operation on them (including ls in the directory).
>
> I've managed to ignore the problem for a while now, and even upgraded to
> 7.2, but I'm not sure if it will cause problems later on.  So the question
> is, without access to the console, how would I fix this?



I think tere is a need for fsck on this partition.
/var is used by many daemons for logging, mailqueue etc., so maybe the first 
thing to do would be to stop as many daemons as possible and leaving only ssh 
to get to this system remotely?
I really don't know how much dangerous could be unmounting /var on a live 
system in such case.






-- 
Pozdrawiam,
Maciej Milewski
From dwmalone at maths.tcd.ie  Wed May 13 11:05:45 2009
From: dwmalone at maths.tcd.ie (David Malone)
Date: Wed May 13 11:05:52 2009
Subject: "maxproc limit exceeded" making no sense 
In-Reply-To: Your message of "Tue, 12 May 2009 13:04:19 -0300."
	<d3ea75b30905120904n4ec157b5y5ba1e68b1eca90d5@mail.gmail.com> 
Message-ID: <200905131205.aa18356@walton.maths.tcd.ie>

> This user is classess, therefore its on default class on login.conf,
> and all limits there are "unlimited".

Might be worth checking that the limits are being set correctly by
suing to the user (su -l if they have a real shell, to be certain).

Could you be hitting the kern.maxprocperuid sysctl? It doesn't
sound like you've enough processes to be hitting that.

	David.
From dikshie at gmail.com  Wed May 13 11:12:31 2009
From: dikshie at gmail.com (dikshie)
Date: Wed May 13 11:12:37 2009
Subject: maximum mmap()
Message-ID: <910e60e80905130410h38a1dc70y23a26275dac51a31@mail.gmail.com>

Hi,
i found that my rrdtool does not work with mmap() with rra files size
more than 2GB.
my question: on i386 arch,  what's maximum size of file to be able to mmap() ?
do i have to change from i386 to amd64? or added 4GB RAM?

thanks!
-- 
-dikx-
From nakaji at jp.freebsd.org  Wed May 13 12:04:30 2009
From: nakaji at jp.freebsd.org (NAKAJI Hiroyuki)
Date: Wed May 13 12:04:38 2009
Subject: More data on 7.2-RELEASE "hangs"
In-Reply-To: <20090513040719.D17646@hub.org> (Marc G. Fournier's message of
	"Wed, 13 May 2009 04:09:33 -0300 (ADT)")
References: <20090513040719.D17646@hub.org>
Message-ID: <87tz3pgrks.fsf@roddy.4407.kankyo-u.ac.jp>

Marc, and folks,

I have simillar "hang" problem on 6.4-STABLE and 7.2-STABLE servers, on
which apache, squid, inn, named, isc-dhcpd and so on are running except DB
servers.

What kind of informations should I check to solve this annoying problem?

I'm running munin-node on these machines, too.

Thanks.

>>>>> In <20090513040719.D17646@hub.org> 
>>>>>	"Marc G. Fournier" <scrappy@hub.org> wrote:

> Don't know if this helps with anything, but it just hung after 2days
> again ... nothing on the console ... top process running at the time
> shows the following ... anything there look "concerning"?
-- 
NAKAJI Hiroyuki
From ivoras at freebsd.org  Wed May 13 12:50:07 2009
From: ivoras at freebsd.org (Ivan Voras)
Date: Wed May 13 12:50:21 2009
Subject: File system corruption
In-Reply-To: <200905131124.16897.milu@dat.pl>
References: <2c2c47aa0905121110i6355930bwce3a9c6afb117d4d@mail.gmail.com>
	<200905131124.16897.milu@dat.pl>
Message-ID: <gueff2$sei$2@ger.gmane.org>

Maciej Milewski wrote:
> Tuesday 12 May 2009 20:10:57 Pat Wendorf napisa?(a):
>> I have a co-lo server I've been maintaining for a few years now running IDE
>> drives on a mostly terrible UPS.  A few months ago, when it returned from a
>> power outage (running 6.2-R) I started noticing the following in my daily
>> security email:
>>
>> Checking setuid files and devices:
>> find:
>> /var/db/portsnap/files/2dc95ddff37a8091239e83bf7e3ce5a2c285b027891ced1919d7
>> 6c9947c5b7db.gz: Bad file descriptor
>> find:
>> /var/db/portsnap/files/52abe8c91385b12272f13f4d20896067d9ba70bdec1fa2575025
>> 858bd3e93718.gz: Bad file descriptor
>> find: /var/lost+found/#238237: Bad file descriptor
>>
>> I verified that these files return the same result when trying to do any
>> operation on them (including ls in the directory).
>>
>> I've managed to ignore the problem for a while now, and even upgraded to
>> 7.2, but I'm not sure if it will cause problems later on.  So the question
>> is, without access to the console, how would I fix this?
> 
> 
> 
> I think tere is a need for fsck on this partition.
> /var is used by many daemons for logging, mailqueue etc., so maybe the first 
> thing to do would be to stop as many daemons as possible and leaving only ssh 
> to get to this system remotely?
> I really don't know how much dangerous could be unmounting /var on a live 
> system in such case.

Not critically dangerous - it can be done with care. Of course, it's
best to reboot afterwards :)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 260 bytes
Desc: OpenPGP digital signature
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20090513/5f83d74e/signature.pgp
From jhb at freebsd.org  Wed May 13 14:27:32 2009
From: jhb at freebsd.org (John Baldwin)
Date: Wed May 13 14:28:07 2009
Subject: More data on 7.2-RELEASE "hangs"
In-Reply-To: <20090513040719.D17646@hub.org>
References: <20090513040719.D17646@hub.org>
Message-ID: <200905131009.00403.jhb@freebsd.org>

On Wednesday 13 May 2009 3:09:33 am Marc G. Fournier wrote:
> 
> Don't know if this helps with anything, but it just hung after 2days again 
> ... nothing on the console ... top process running at the time shows the 
> following ... anything there look "concerning"?

Is this a 2 CPU system?  If so, both CPUs are actually running something, so 
it is not a deadlock per se.

> 99402 www         1  96    0   163M 29892K CPU1   1   0:03  0.00% httpd
> 13635     88     34  96    0 92340K 25604K CPU0   0   0:00  0.05% mysqld

-- 
John Baldwin
From jhb at freebsd.org  Wed May 13 14:27:33 2009
From: jhb at freebsd.org (John Baldwin)
Date: Wed May 13 14:28:08 2009
Subject: maximum mmap()
In-Reply-To: <910e60e80905130410h38a1dc70y23a26275dac51a31@mail.gmail.com>
References: <910e60e80905130410h38a1dc70y23a26275dac51a31@mail.gmail.com>
Message-ID: <200905131011.44391.jhb@freebsd.org>

On Wednesday 13 May 2009 7:10:29 am dikshie wrote:
> Hi,
> i found that my rrdtool does not work with mmap() with rra files size
> more than 2GB.
> my question: on i386 arch,  what's maximum size of file to be able to mmap() ?
> do i have to change from i386 to amd64? or added 4GB RAM?

The amount of RAM is not the issue, it is the size of the virtual address
space.  You can lower maxdsiz on i386 to leave more room for mmap, and you
can also change KVA_PAGES in the kernel to leave more address space for
userland than for the kernel perhaps, but you won't get a whole lot more
space that way (you might be able to map 2.5GB or so).  Moving to amd64 gives
you a 64-bit virtual address space and you will be able to easily mmap()
much, much more than 4GB out of the box.

-- 
John Baldwin
From jhb at freebsd.org  Wed May 13 14:27:34 2009
From: jhb at freebsd.org (John Baldwin)
Date: Wed May 13 14:28:10 2009
Subject: lock up in 6.2 (procs massively stuck in Giant)
In-Reply-To: <a31046fc0905122340n55785cben89c81736ec790e4c@mail.gmail.com>
References: <a31046fc0904292336w17aca317hefd32dad5bc28007@mail.gmail.com>
	<a31046fc0905122245k4ac946c0lcbd29d4557cafab8@mail.gmail.com>
	<a31046fc0905122340n55785cben89c81736ec790e4c@mail.gmail.com>
Message-ID: <200905131015.27431.jhb@freebsd.org>

On Wednesday 13 May 2009 2:40:33 am pluknet wrote:
> 2009/5/13 pluknet <pluknet@gmail.com>:
> > 2009/5/13 John Baldwin <jhb@freebsd.org>:
> >> On Tuesday 12 May 2009 4:59:19 pm pluknet wrote:
> >>> Hi.
> >>>
> >>> From just another box (not from the first two mentioned earlier)
> >>> with a similar locking issue. If it would make sense, since there are
> >>> possibly a bit different conditions.
> >>> clock proc here is on swi4, I hope it's a non-important difference.
> >>>
> >>>    18     0     0     0  LL     *Giant    0xd0a6b140 [swi4: clock sio]
> >>> db> bt 18
> >>
> >> Ok, this is a known issue in 6.x.  It is fixed in 6.4.
> >>
> 
> Looking at the face of kern_timeout.c I suspect that was fixed in r181012.

No, this particular issue is fixed by a change to sched_4bsd.c in r179975.

-- 
John Baldwin
From scrappy at hub.org  Wed May 13 14:50:15 2009
From: scrappy at hub.org (Marc G. Fournier)
Date: Wed May 13 14:50:22 2009
Subject: More data on 7.2-RELEASE "hangs"
In-Reply-To: <200905131009.00403.jhb@freebsd.org>
References: <20090513040719.D17646@hub.org>
	<200905131009.00403.jhb@freebsd.org>
Message-ID: <20090513114956.K17646@hub.org>

On Wed, 13 May 2009, John Baldwin wrote:

> On Wednesday 13 May 2009 3:09:33 am Marc G. Fournier wrote:
>>
>> Don't know if this helps with anything, but it just hung after 2days again
>> ... nothing on the console ... top process running at the time shows the
>> following ... anything there look "concerning"?
>
> Is this a 2 CPU system?  If so, both CPUs are actually running something, so
> it is not a deadlock per se.

Yes:

CPU: Intel(R) Xeon(TM) CPU 3.40GHz (3400.14-MHz K8-class CPU)
   Origin = "GenuineIntel"  Id = 0xf43  Stepping = 3

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=0x649d<SSE3,RSVD2,MON,DS_CPL,EST,CNXT-ID,CX16,xTPR>
   AMD Features=0x20000800<SYSCALL,LM>
   Logical CPUs per core: 2
usable memory = 6368911360 (6073 MB)
avail memory  = 6141906944 (5857 MB)
ACPI APIC Table: <HP     00000083>
FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs
  cpu0 (BSP): APIC ID:  0
  cpu1 (AP): APIC ID:  6
ioapic1: Changing APIC ID to 9

----
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 mike at sentex.net  Wed May 13 15:02:58 2009
From: mike at sentex.net (Mike Tancsa)
Date: Wed May 13 15:03:05 2009
Subject: More data on 7.2-RELEASE "hangs"
In-Reply-To: <20090513114956.K17646@hub.org>
References: <20090513040719.D17646@hub.org>
	<200905131009.00403.jhb@freebsd.org>
	<20090513114956.K17646@hub.org>
Message-ID: <200905131501.n4DF1XNt037860@lava.sentex.ca>

At 10:50 AM 5/13/2009, Marc G. Fournier wrote:
>On Wed, 13 May 2009, John Baldwin wrote:
>
>>On Wednesday 13 May 2009 3:09:33 am Marc G. Fournier wrote:
>>>
>>>Don't know if this helps with anything, but it just hung after 2days again
>>>... nothing on the console ... top process running at the time shows the
>>>following ... anything there look "concerning"?
>>
>>Is this a 2 CPU system?  If so, both CPUs are actually running something, so
>>it is not a deadlock per se.
>
>Yes:
>
>CPU: Intel(R) Xeon(TM) CPU 3.40GHz (3400.14-MHz K8-class CPU)
>   Origin = "GenuineIntel"  Id = 0xf43  Stepping = 3
>
>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=0x649d<SSE3,RSVD2,MON,DS_CPL,EST,CNXT-ID,CX16,xTPR>
>   AMD Features=0x20000800<SYSCALL,LM>
>   Logical CPUs per core: 2
>usable memory = 6368911360 (6073 MB)
>avail memory  = 6141906944 (5857 MB)
>ACPI APIC Table: <HP     00000083>
>FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs
>  cpu0 (BSP): APIC ID:  0
>  cpu1 (AP): APIC ID:  6
>ioapic1: Changing APIC ID to 9

What does your kernel config look like ?

         ---Mike 

From pluknet at gmail.com  Wed May 13 15:41:24 2009
From: pluknet at gmail.com (pluknet)
Date: Wed May 13 15:41:32 2009
Subject: lock up in 6.2 (procs massively stuck in Giant)
In-Reply-To: <200905131015.27431.jhb@freebsd.org>
References: <a31046fc0904292336w17aca317hefd32dad5bc28007@mail.gmail.com>
	<a31046fc0905122245k4ac946c0lcbd29d4557cafab8@mail.gmail.com>
	<a31046fc0905122340n55785cben89c81736ec790e4c@mail.gmail.com>
	<200905131015.27431.jhb@freebsd.org>
Message-ID: <a31046fc0905130841p6c762d95h40ec989bd0355c9d@mail.gmail.com>

2009/5/13 John Baldwin <jhb@freebsd.org>:
> On Wednesday 13 May 2009 2:40:33 am pluknet wrote:
>> 2009/5/13 pluknet <pluknet@gmail.com>:
>> > 2009/5/13 John Baldwin <jhb@freebsd.org>:
>> >> On Tuesday 12 May 2009 4:59:19 pm pluknet wrote:
>> >>> Hi.
>> >>>
>> >>> From just another box (not from the first two mentioned earlier)
>> >>> with a similar locking issue. If it would make sense, since there are
>> >>> possibly a bit different conditions.
>> >>> clock proc here is on swi4, I hope it's a non-important difference.
>> >>>
>> >>> ? ?18 ? ? 0 ? ? 0 ? ? 0 ?LL ? ? *Giant ? ?0xd0a6b140 [swi4: clock sio]
>> >>> db> bt 18
>> >>
>> >> Ok, this is a known issue in 6.x. ?It is fixed in 6.4.
>> >>
>>
>> Looking at the face of kern_timeout.c I suspect that was fixed in r181012.
>
> No, this particular issue is fixed by a change to sched_4bsd.c in r179975.
>

Gah.. We constrained to use ule scheduler on 6.x (yes, I know that
"it's known to be broken (c)"), since we have had a very bad interactivity
on 4bsd on our workload. Ok, that's just another reason to move to 7.x.

Thanks.

-- 
wbr,
pluknet
From scrappy at hub.org  Wed May 13 16:31:40 2009
From: scrappy at hub.org (Marc G. Fournier)
Date: Wed May 13 16:31:47 2009
Subject: More data on 7.2-RELEASE "hangs"
In-Reply-To: <200905131501.n4DF1XNt037860@lava.sentex.ca>
References: <20090513040719.D17646@hub.org>
	<200905131009.00403.jhb@freebsd.org>
	<20090513114956.K17646@hub.org>
	<200905131501.n4DF1XNt037860@lava.sentex.ca>
Message-ID: <20090513132952.T17646@hub.org>

On Wed, 13 May 2009, Mike Tancsa wrote:

>
> What does your kernel config look like ?

Included below ... only thought I had, taht I haven't tried yet, was 
changing from SCHED_4BSD -> SCHED_ULE ...



machine		amd64
cpu		HAMMER
ident		kernel

options		SMP

options 	SCHED_4BSD		# 4BSD scheduler
options 	PREEMPTION		# Enable kernel thread preemption
options 	INET			# InterNETworking
options 	FFS			# Berkeley Fast Filesystem
options		SOFTUPDATES
options 	UFS_ACL			# Support for access control lists
options 	UFS_DIRHASH		# Improve performance on big directories
options 	PROCFS			# Process filesystem (requires PSEUDOFS)
options 	PSEUDOFS		# Pseudo-filesystem framework
options 	COMPAT_43		# Needed by COMPAT_LINUX32
options 	COMPAT_IA32		# Compatible with i386 binaries
options 	COMPAT_FREEBSD4		# Compatible with FreeBSD4
options         COMPAT_FREEBSD6         # Compatible with FreeBSD6
options 	COMPAT_LINUX32		# Compatible with i386 linux binaries 
options 	SCSI_DELAY=5000		# Delay (in ms) before probing SCSI
options 	KTRACE			# ktrace(1) support

options         SYSVSHM
options         SHMMAXPGS=199608
options         SHMMAX=(SHMMAXPGS*PAGE_SIZE+1)

options         SYSVSEM
options         SEMMNI=4096
options         SEMMNS=8192

options 	SYSVMSG			# SYSV-style message queues

options 	_KPOSIX_PRIORITY_SCHEDULING # POSIX P1003_1B real-time extensions
options 	KBD_INSTALL_CDEV	# install a CDEV entry in /dev

options 	ADAPTIVE_GIANT		# Giant mutex is adaptive.

options 	LINPROCFS		# Cannot be a module yet.

# Bus support.
device		acpi
device		pci

# Serial (COM) ports
device          sio             # 8250, 16[45]50 based serial ports

device		scbus		# SCSI bus (required for SCSI)
device		da		# Direct Access (disks)
device		pass		# Passthrough device (direct SCSI access)
device		ses		# SCSI Environmental Services (and SAF-TE)

device		ciss		# Compaq Smart RAID 5*

device		atkbdc		# AT keyboard controller
device		atkbd		# AT keyboard
device		psm		# PS/2 mouse

device		vga		# VGA video card driver

device		splash		# Splash screen and screen saver support

device		sc

device		agp		# support several AGP chipsets

device		miibus		# MII bus support
device		bge		# Broadcom BCM570xx Gigabit Ethernet

device		loop		# Network loopback
device		random		# Entropy device
device		ether		# Ethernet support
device		pty		# Pseudo-ttys (telnet etc)

device		bpf		# Berkeley packet filter

options         ALT_BREAK_TO_DEBUGGER
options         KDB
options         DDB

----
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 scrappy at hub.org  Wed May 13 16:34:40 2009
From: scrappy at hub.org (Marc G. Fournier)
Date: Wed May 13 16:34:47 2009
Subject: More data on 7.2-RELEASE "hangs"
In-Reply-To: <200905131009.00403.jhb@freebsd.org>
References: <20090513040719.D17646@hub.org>
	<200905131009.00403.jhb@freebsd.org>
Message-ID: <20090513133143.M17646@hub.org>

On Wed, 13 May 2009, John Baldwin wrote:

> On Wednesday 13 May 2009 3:09:33 am Marc G. Fournier wrote:
>>
>> Don't know if this helps with anything, but it just hung after 2days again
>> ... nothing on the console ... top process running at the time shows the
>> following ... anything there look "concerning"?
>
> Is this a 2 CPU system?  If so, both CPUs are actually running something, so
> it is not a deadlock per se.
>
>> 99402 www         1  96    0   163M 29892K CPU1   1   0:03  0.00% httpd
>> 13635     88     34  96    0 92340K 25604K CPU0   0   0:00  0.05% mysqld

Here is what vmstat shows ~10 minutes before (or as) it hung solid last 
time.  I didn't think to save the one that ran just before this one (the 
script runs every 5 minutes), but for the 'r b w' columns 'b' was around 
10ish, while 'w' was 0 ... within a 5 minute period of time, 'w' 
literally skyrockets:

  procs      memory      page                    disks     faults 
cpu
  r b w     avm    fre   flt  re  pi  po    fr  sr da0 pa0   in   sy   cs us sy id
107 266 122 16155620   23084  3255  22   1   2  3358 1605   0   0  377 17835 5231 19  7 73
  6 285 382 16446348   22532 111705 21155 1391 10049 51966 2187328 143   0 36344 499098 423971  3  2 95
  0 73 386 16440468   23072  7052 1155  85  44  1292  73 372   0 1030 18631 8334 18 12 70
  0 77 388 16440468   23088   126 1050   0   6    21  27 169   0  521 4186 4125  2  3 94
  0 66 389 16440468   23104     4 713   0  13    44  58 227   0  352 2217 3504  0  5 95

>
> -- 
> John Baldwin
> _______________________________________________
> freebsd-stable@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org"
>

----
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 freebsd at byshenk.net  Wed May 13 16:42:11 2009
From: freebsd at byshenk.net (Greg Byshenk)
Date: Wed May 13 16:42:20 2009
Subject: em0 watchdog timeout 7-stable
In-Reply-To: <20090426125008.GK1550@core.byshenk.net>
References: <20090426125008.GK1550@core.byshenk.net>
Message-ID: <20090513164207.GD67116@core.byshenk.net>

As a followup to my own previous message, I continue to have annoying 
problems with "em?: watchdog timeout" on one of my machines (now running
7.2-STABLE as of 2009-05-08).

I have discontinued using the on-board (em, copper) NICs, and replaced
the original fibre NIC with a newer model, but the problem persists.
I've also set

   hw.pci.enable_msix=0
   hw.pci.enable_msi=0
   hw.em.rxd=1024
   hw.em.txd=1024
   net.inet.tcp.tso=0

...as suggested in some discussions of this problem, and set the em1
interface to 'polling', all to no avail.  Frequently, though irregularly
(once or twice a day), the console begins to display

   em1: watchdog timeout -- resetting
   em1: watchdog timeout -- resetting
   em1: watchdog timeout -- resetting

the nework is down, and the machine locks up.

[Note: I am getting 'em1' now instead of 'em0' as previously, but this
is due to changing all of the nics, which led to a different numbering;
the timeout is still occurring on the (main) interface, the fibre 
gigabit connection.]

What is particularly perverse (IMO) is that, since changing the NIC to
the newer model (and updating the kernel), I can no longer break to the
debugger when the lockup occurs (there is no response to the break) --
bit I _can_ shut the machine down cleanly via hardware (a touch of the
power switch sends 'shutdown', and the machine shuts down cleanly --
after killing off processes waiting on network i/o).

The machine is running nfs and samba (3.2.10, from ports), and pretty
much nothing else.


Anyone have any ideas about this...?  I'm going mad with this.

-greg byshenk



# pciconf -lvb
[...]
em1@pci0:7:1:0: class=0x020000 card=0x10028086 chip=0x10118086 rev=0x01 hdr=0x00
    vendor     = 'Intel Corporation'
    device     = '82545EM Gigabit Ethernet Controller (Fiber)'
    class      = network
    subclass   = ethernet
    bar   [10] = type Memory, range 64, base 0xda300000, size 131072, enabled
    bar   [20] = type I/O Port, range 32, base 0x5000, size 64, enabled
[...]

# vmstat -i
interrupt                          total       rate
irq4: sio0                          1666          0
irq6: fdc0                            10          0
irq14: ata0                           58          0
irq16: skc0 em0                  1437801         98
irq18: twa0                       846981         57
irq24: em1                       4378650        299
cpu0: timer                     29258004       1999
cpu1: timer                     29249758       1999
cpu3: timer                     29249816       1999
cpu7: timer                     29249779       1999
cpu2: timer                     29249729       1999
cpu4: timer                     29249852       1999
cpu6: timer                     29249851       1999
cpu5: timer                     29249814       1999
Total                          240671769      16450



On Sun, Apr 26, 2009 at 02:50:08PM +0200, Greg Byshenk wrote:
> I have one machine that is seeing watchdog timeouts on em0, running 7-STABLE
> amd64 as of 2009.04.19, and also some other more perverse errors.
> 
> Twice now in the last 48 hours, this machine has become unreachable via the
> network, and connecting to the console shows an endless string of 
> 
>    [...]
>    em0: watchdog timeout -- resetting
>    em0: watchdog timeout -- resetting
>    em0: watchdog timeout -- resetting
> 
> messages. The machine is almost locked up.  That is, I can get a login
> prompt, but can go no further than typing in a username; after the
> username, no password prompt, and nothing further.  The only option is
> to hard reset the machine or to drop to debugger and reboot.
> 
> Now the "perverse" part.  After restarting, the system partition is no
> more.
> 
> Background detail:  the machine is a fileserver, with a 3Ware 9650SE-16ML
> SATA controller, connected to 16 1TB SATA drives, this configured as
> a 14-drive RAID10 array (+ 2 hot spares), with a 50GB system partition
> and 6.5TB data partition.  The system partition is configured as da1,
> with one slice and more or less standard partitions for / /var /tmp, etc.
> (the data partition of the array is sliced with gpt).
> 
> The issue here is that, upon restart, all parition information on da0
> seems to have disappeared, and restarting results in a "no operating
> system found" message, and a failure to boot (obviously).
> 
> But all of the data is still present.  If I boot into rescue mode,
> recreate da0s1, mark it bootable, and restore the bsdlabel, then
> everything works again.  I can restart the machine, and it comes back
> up normally (it requires an fsck of everything on da0, but after that
> everything is back to normal).
> 
> I don't know if this is two unrelated problems, or one problem with
> two symptoms, or something else.  I think that I can safely say that
> it is not a problem with the 3Ware controller itself, as I replaced
> the controller with a spare (identical model), and the problem
> recurred.  Additionally, I have an almost-identical configuration on
> four other machines, none of which are experiencing any problems.
> One thing that is different is that the other machines use
> Intel PRO/1000 PF (pci-e) NICs.
> 
> Is there some known problem with the Intel 2572 fibre NIC?  Or some
> potential interaction of it with the 3ware RAID controller?
> 
> For the moment, I've set hw.pci.enable_msi=0 (as discussed in the
> threads on 7.2/bge), and am building a new kernel/world from sources
> csup'd one hour ago, but I'd really like to hear any ideas about this
> -- particularly the wiping of the label.
> 
> Some information about the system:
> 
> 
> # /dev/da0s1:
> 8 partitions:
> #        size   offset    fstype   [fsize bsize bps/cpg]
>   a:  2097152        0    4.2BSD        0     0     0 
>   b:  8388608  2097152      swap                    
>   c: 104856192        0    unused        0     0         # "raw" part, don't edit
>   d:  8388608 10485760    4.2BSD        0     0     0 
>   e:  2097152 18874368    4.2BSD        0     0     0 
>   f: 41943040 20971520    4.2BSD        0     0     0 
>   g: 41941632 62914560    4.2BSD        0     0     0 
> 
> 
> em0@pci0:4:1:0: class=0x020000 card=0x10038086 chip=0x10018086 rev=0x02 hdr=0x00
>     vendor     = 'Intel Corporation'thernet Controller (Fiber)'
>     device     = '2572 10/100/1000 Ethernet Controller (Fiber)'
>     class      = networktory, range 32, base 0xda000000, size 131072, enabled
>     subclass   = ethernetory, range 32, base 0xda000000, size 131072, enabled
>     bar   [10] = type Memory, range 32, base 0xda000000, size 131072, enabled
>     bar   [14] = type Memory, range 32, base 0xda020000, size 65536, enabled0x00
>  
> twa0@pci0:9:0:0:        class=0x010400 card=0x100413c1 chip=0x100413c1 rev=0x01 hdr=0x00
>     device     = '9650SE Series PCI-Express SATA2 Raid Controller'
>     class      = mass storage
>     subclass   = RAID
>     bar   [10] = type Prefetchable Memory, range 64, base 0xd8000000, size 33554432, enabled
>     bar   [18] = type Memory, range 64, base 0xda300000, size 4096, enabled
>     bar   [20] = type I/O Port, range 32, base 0x3000, size 256, enabled
>     cap 01[40] = powerspec 2  supports D0 D1 D2 D3  current D0
>     cap 05[50] = MSI supports 32 messages, 64 bit
>     cap 10[70] = PCI-Express 1 legacy endpoint
> 

-- 
greg byshenk  -  gbyshenk@byshenk.net  -  Leiden, NL
From freebsd at byshenk.net  Wed May 13 16:44:41 2009
From: freebsd at byshenk.net (Greg Byshenk)
Date: Wed May 13 16:44:49 2009
Subject: em0 watchdog timeout 7-stable
In-Reply-To: <20090513164207.GD67116@core.byshenk.net>
References: <20090426125008.GK1550@core.byshenk.net>
	<20090513164207.GD67116@core.byshenk.net>
Message-ID: <20090513164438.GE67116@core.byshenk.net>

On Wed, May 13, 2009 at 06:42:07PM +0200, Greg Byshenk wrote:

> As a followup to my own previous message, I continue to have annoying 
> problems with "em?: watchdog timeout" on one of my machines (now running
> 7.2-STABLE as of 2009-05-08).
> 
> I have discontinued using the on-board (em, copper) NICs, and replaced
> the original fibre NIC with a newer model, but the problem persists.
> I've also set
> 
>    hw.pci.enable_msix=0
>    hw.pci.enable_msi=0
>    hw.em.rxd=1024
>    hw.em.txd=1024
>    net.inet.tcp.tso=0
> 
> ...as suggested in some discussions of this problem, and set the em1
> interface to 'polling', all to no avail.  Frequently, though irregularly
> (once or twice a day), the console begins to display
> 
>    em1: watchdog timeout -- resetting
>    em1: watchdog timeout -- resetting
>    em1: watchdog timeout -- resetting
> 
> the nework is down, and the machine locks up.
> 
> [Note: I am getting 'em1' now instead of 'em0' as previously, but this
> is due to changing all of the nics, which led to a different numbering;
> the timeout is still occurring on the (main) interface, the fibre 
> gigabit connection.]
> 
> What is particularly perverse (IMO) is that, since changing the NIC to
> the newer model (and updating the kernel), I can no longer break to the
> debugger when the lockup occurs (there is no response to the break) --
> bit I _can_ shut the machine down cleanly via hardware (a touch of the
> power switch sends 'shutdown', and the machine shuts down cleanly --
> after killing off processes waiting on network i/o).
> 
> The machine is running nfs and samba (3.2.10, from ports), and pretty
> much nothing else.
> 
> 
> Anyone have any ideas about this...?  I'm going mad with this.


Just as an FYI, the drive errors I described in my previous message
appear to have been due to a bad BBU on the RAID controller, and to
have been resolved.
 

-- 
greg byshenk  -  gbyshenk@byshenk.net  -  Leiden, NL
From jhb at freebsd.org  Wed May 13 16:52:32 2009
From: jhb at freebsd.org (John Baldwin)
Date: Wed May 13 16:52:45 2009
Subject: lock up in 6.2 (procs massively stuck in Giant)
In-Reply-To: <a31046fc0905130841p6c762d95h40ec989bd0355c9d@mail.gmail.com>
References: <a31046fc0904292336w17aca317hefd32dad5bc28007@mail.gmail.com>
	<200905131015.27431.jhb@freebsd.org>
	<a31046fc0905130841p6c762d95h40ec989bd0355c9d@mail.gmail.com>
Message-ID: <200905131248.08465.jhb@freebsd.org>

On Wednesday 13 May 2009 11:41:22 am pluknet wrote:
> 2009/5/13 John Baldwin <jhb@freebsd.org>:
> > On Wednesday 13 May 2009 2:40:33 am pluknet wrote:
> >> 2009/5/13 pluknet <pluknet@gmail.com>:
> >> > 2009/5/13 John Baldwin <jhb@freebsd.org>:
> >> >> On Tuesday 12 May 2009 4:59:19 pm pluknet wrote:
> >> >>> Hi.
> >> >>>
> >> >>> From just another box (not from the first two mentioned earlier)
> >> >>> with a similar locking issue. If it would make sense, since there are
> >> >>> possibly a bit different conditions.
> >> >>> clock proc here is on swi4, I hope it's a non-important difference.
> >> >>>
> >> >>> ? ?18 ? ? 0 ? ? 0 ? ? 0 ?LL ? ? *Giant ? ?0xd0a6b140 [swi4: clock 
sio]
> >> >>> db> bt 18
> >> >>
> >> >> Ok, this is a known issue in 6.x. ?It is fixed in 6.4.
> >> >>
> >>
> >> Looking at the face of kern_timeout.c I suspect that was fixed in 
r181012.
> >
> > No, this particular issue is fixed by a change to sched_4bsd.c in r179975.
> >
> 
> Gah.. We constrained to use ule scheduler on 6.x (yes, I know that
> "it's known to be broken (c)"), since we have had a very bad interactivity
> on 4bsd on our workload. Ok, that's just another reason to move to 7.x.

Hmmm I would have thought ULE wouldn't have suffered from this bug.  The 
problem on 4BSD was if softclock ever blocked on Giant and the thread that 
held Giant was on a run queue and pinned to a specific CPU but that another 
userland thread was running on that CPU already, the userland thread would 
never yield the CPU so long as it kept busy since the round robin timeout 
would never run.

-- 
John Baldwin
From jhb at freebsd.org  Wed May 13 16:52:33 2009
From: jhb at freebsd.org (John Baldwin)
Date: Wed May 13 16:52:47 2009
Subject: More data on 7.2-RELEASE "hangs"
In-Reply-To: <20090513133143.M17646@hub.org>
References: <20090513040719.D17646@hub.org>
	<200905131009.00403.jhb@freebsd.org>
	<20090513133143.M17646@hub.org>
Message-ID: <200905131252.15171.jhb@freebsd.org>

On Wednesday 13 May 2009 12:34:39 pm Marc G. Fournier wrote:
> On Wed, 13 May 2009, John Baldwin wrote:
> 
> > On Wednesday 13 May 2009 3:09:33 am Marc G. Fournier wrote:
> >>
> >> Don't know if this helps with anything, but it just hung after 2days 
again
> >> ... nothing on the console ... top process running at the time shows the
> >> following ... anything there look "concerning"?
> >
> > Is this a 2 CPU system?  If so, both CPUs are actually running something, 
so
> > it is not a deadlock per se.
> >
> >> 99402 www         1  96    0   163M 29892K CPU1   1   0:03  0.00% httpd
> >> 13635     88     34  96    0 92340K 25604K CPU0   0   0:00  0.05% mysqld
> 
> Here is what vmstat shows ~10 minutes before (or as) it hung solid last 
> time.  I didn't think to save the one that ran just before this one (the 
> script runs every 5 minutes), but for the 'r b w' columns 'b' was around 
> 10ish, while 'w' was 0 ... within a 5 minute period of time, 'w' 
> literally skyrockets:
> 
>   procs      memory      page                    disks     faults 
> cpu
>   r b w     avm    fre   flt  re  pi  po    fr  sr da0 pa0   in   sy   cs us 
sy id
> 107 266 122 16155620   23084  3255  22   1   2  3358 1605   0   0  377 17835 
5231 19  7 73
>   6 285 382 16446348   22532 111705 21155 1391 10049 51966 2187328 143   0 
36344 499098 423971  3  2 95
>   0 73 386 16440468   23072  7052 1155  85  44  1292  73 372   0 1030 18631 
8334 18 12 70
>   0 77 388 16440468   23088   126 1050   0   6    21  27 169   0  521 4186 
4125  2  3 94
>   0 66 389 16440468   23104     4 713   0  13    44  58 227   0  352 2217 
3504  0  5 95

Well, you had a whole lot of page faults and other VM activity, plus 500k 
syscalls.  The 'w' is a count of swapped processes, so basically your box is 
swapping a whole lot it seems.  I think your box is just overloaded.

-- 
John Baldwin
From mike at sentex.net  Wed May 13 17:14:22 2009
From: mike at sentex.net (Mike Tancsa)
Date: Wed May 13 17:14:29 2009
Subject: More data on 7.2-RELEASE "hangs"
In-Reply-To: <20090513132952.T17646@hub.org>
References: <20090513040719.D17646@hub.org>
	<200905131009.00403.jhb@freebsd.org>
	<20090513114956.K17646@hub.org>
	<200905131501.n4DF1XNt037860@lava.sentex.ca>
	<20090513132952.T17646@hub.org>
Message-ID: <200905131712.n4DHCrBo038504@lava.sentex.ca>

At 12:31 PM 5/13/2009, Marc G. Fournier wrote:
>On Wed, 13 May 2009, Mike Tancsa wrote:
>
>>
>>What does your kernel config look like ?
>
>Included below ... only thought I had, taht I haven't tried yet, was 
>changing from SCHED_4BSD -> SCHED_ULE ...

ULE for sure.  Are you sure some of the options below are still 
valid/wanted as well ?



>options         SYSVSHM
>options         SHMMAXPGS=199608
>options         SHMMAX=(SHMMAXPGS*PAGE_SIZE+1)
>
>options         SYSVSEM
>options         SEMMNI=4096
>options         SEMMNS=8192
>
>options         SYSVMSG                 # SYSV-style message queues
>
>options         _KPOSIX_PRIORITY_SCHEDULING # POSIX P1003_1B 
>real-time extensions
>options         KBD_INSTALL_CDEV        # install a CDEV entry in /dev
>
>options         ADAPTIVE_GIANT          # Giant mutex is adaptive.
>
>options         LINPROCFS               # Cannot be a module yet.

         ---Mike 

From cswiger at mac.com  Wed May 13 17:18:33 2009
From: cswiger at mac.com (Chuck Swiger)
Date: Wed May 13 17:18:39 2009
Subject: More data on 7.2-RELEASE "hangs"
In-Reply-To: <200905131252.15171.jhb@freebsd.org>
References: <20090513040719.D17646@hub.org>
	<200905131009.00403.jhb@freebsd.org> <20090513133143.M17646@hub.org>
	<200905131252.15171.jhb@freebsd.org>
Message-ID: <0ACD7522-58D7-4D70-8F79-77791DD98299@mac.com>

Hi--

On May 13, 2009, at 9:52 AM, John Baldwin wrote:
[ ... ]
> Well, you had a whole lot of page faults and other VM activity, plus  
> 500k
> syscalls.  The 'w' is a count of swapped processes, so basically  
> your box is
> swapping a whole lot it seems.  I think your box is just overloaded.

Yep.  There's a classic failure mode with preforking Apache where if  
the number of requests exceeds the max number of children which can be  
run without sending the system into heavy swapping, the server will  
effectively grind to a halt.  Start tuning by figuring out how much  
RAM you have available to Apache after system processes and things  
like your Postgres (and MySQL?) server are accounted for, divide by  
the the RES size, and set MaxChildren to that in httpd.conf.

Also, the process size of named is fairly astonishing:

  PID USERNAME  THR PRI NICE   SIZE    RES STATE  C   TIME   WCPU  
COMMAND
28752 root       5  96    0   427M   408M select 1   1:55  0.00% named
9720  nobody    19  97    0   402M   186M RUN    1   0:00  0.69% nsd

...even if you are running the process in 64-bit mode.  This can be  
brought under control by tuning recursive-clients and max-cache-size  
options.  Also, is nsd process from ports/dns/nsd-- ie, another  
nameserver?  Your machine is being overloaded by running too much  
stuff that's duplicating functionality; it's just not a good idea to  
try to run different types of databases on the same machine; they'll  
fight with the VM system and each other, making your VM system trash....

-- 
-Chuck

From scrappy at hub.org  Wed May 13 17:44:56 2009
From: scrappy at hub.org (Marc G. Fournier)
Date: Wed May 13 17:45:03 2009
Subject: More data on 7.2-RELEASE "hangs"
In-Reply-To: <200905131252.15171.jhb@freebsd.org>
References: <20090513040719.D17646@hub.org>
	<200905131009.00403.jhb@freebsd.org>
	<20090513133143.M17646@hub.org> <200905131252.15171.jhb@freebsd.org>
Message-ID: <20090513142806.V17646@hub.org>

On Wed, 13 May 2009, John Baldwin wrote:

> Well, you had a whole lot of page faults and other VM activity, plus 500k
> syscalls.  The 'w' is a count of swapped processes, so basically your box is
> swapping a whole lot it seems.  I think your box is just overloaded.

I knew I was going to regret posting that :(

What I posted was what vmstat 5 shows after the issue *starts*, not what 
it normally looks like ... right now, after 10 hours of uptime, and all 
the same processes running, it looks like:

io# vmstat 5 (10 hours uptime now)
  procs      memory      page                    disks     faults         cpu
  r b w     avm    fre   flt  re  pi  po    fr  sr da0 pa0   in   sy   cs us sy id
  0 1 0  10477M   301M  3503  13   1   2  3620 286   0   0  331 45491 4566 26  8 66
  0 1 0  10430M   305M   278   7   0   0   550   0  18   0  186 19243 2917 4  3 93
  1 1 0  10474M   295M   511   0   0   0   359   0  91   0  253 11632 3516 7  3 90
  0 1 0  10447M   310M   819   3   0   0  1473   0  14   0  143 29575 2486 8  3 89
  0 1 0  10558M   295M  5008  18  13   5  4128   0 121   0  345 24212 4215 16  7 77

Right now, IO is running ~775 processes ... at the time of the vmstat I 
provided earlier, it was up to 1400 processes ... since there is only 5 
minutes between script runs, something is causing it to go from zero swap 
-> high swap within a very short period of time, but since things get 
badly locked up when it happens, I can't isolate where ...

I've got the following two ps outputs at the time of the high paging:

/bin/ps -aucxHl -O jid > ps-long.out
/bin/ps -aux -O jid > ps-short.out

Is there anything in there that I could look at as far as what is putting 
things over the edge?

====

As to the 'overloaded server', here is another server, with more running 
on it, but exact same configuration:

neptune# vmstat 5 (3 days, 18 hours uptime now)
  procs      memory      page                    disks     faults         cpu
  r b w     avm    fre   flt  re  pi  po    fr  sr da0 pa0   in   sy   cs us sy id
  0 0 0  12521M   303M  3969  15   5   3  2271 1603   0   0  444 6491 5165 37 19 44
  0 0 0  12464M   309M  3009   1   0  15  2833   0 104   0  296 9378 3689  7  5 88
23 0 0  12476M   297M  3845   3   0   0  2627   0  31   0  279 10545 2986 14  5 81
  0 1 0  12530M   266M  5259   0   1   0  2551   0 145   0  432 18070 4133 45  8 47
  1 0 0  12587M   237M  7049   0   1   0  4484   0 171   0  357 15953 4715 29  7 64

So, normally these servers purr ... and are highly responsive ...

In fact, here is an older 32bit server, less RAM, run about 50% more 
processes then neptune:

mercury# vmstat 5
  procs      memory      page                    disks     faults         cpu
  r b w     avm    fre  flt  re  pi  po  fr  sr da0 pa0   in   sy  cs us sy id
  3 14 1   6817M   114M  641   7   3   1 1036 386   0   0 1109  464 157  5  5 90
  0 8 0   6817M   224M  596  33   0   5 5667 3850  86   0 1303 5768 3885  6 7 87
  1 10 0   6824M   220M 4332  32   2   0 3228   0  17   0  755 9689 3057  8 7 85
  0 9 0   6798M   219M  430   0   0   0 712   0  12   0 1274 4276 3877  2  2 95
  0 11 0   6830M   205M 1026   4   1   3 481   0  84   0 1503 5586 4370  6 4 89



----
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 killing at multiplay.co.uk  Wed May 13 18:22:47 2009
From: killing at multiplay.co.uk (Steven Hartland)
Date: Wed May 13 18:22:55 2009
Subject: More data on 7.2-RELEASE "hangs"
References: <20090513040719.D17646@hub.org><200905131009.00403.jhb@freebsd.org><20090513133143.M17646@hub.org>
	<200905131252.15171.jhb@freebsd.org>
	<20090513142806.V17646@hub.org>
Message-ID: <6670CCCC546E45E0A28628C45B37A074@multiplay.co.uk>

----- Original Message ----- 
From: "Marc G. Fournier" <scrappy@hub.org>

> Right now, IO is running ~775 processes ... at the time of the vmstat I 
> provided earlier, it was up to 1400 processes ... since there is only 5 
> minutes between script runs, something is causing it to go from zero swap 
> -> high swap within a very short period of time, but since things get 
> badly locked up when it happens, I can't isolate where ...

We've seen things similar to this when an process uncommon process does
a query which locks the a table for a large amount of time on mysql.

In our example this turned out to be an admin query in vbulletin. When
it happened it turned a machine which was purring along quite nicely
into a totally unresponsive machine in a matter of a few seconds as
apache spawned more process that also then instantly stalled...

So its likely the overloaded diagnosis could well be correct, but as
you say it hard to diagnose with the machine in such an unusable state.

Reducing max handlers etc on apache will help with this prevent the
machine becoming unusable and hence give you time and resources to
determine what the real issue is.

    Regards
    Steve

================================================
This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. 

In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337
or return the E.mail to postmaster@multiplay.co.uk.

From scrappy at hub.org  Wed May 13 19:14:54 2009
From: scrappy at hub.org (Marc G. Fournier)
Date: Wed May 13 19:15:01 2009
Subject: More data on 7.2-RELEASE "hangs"
In-Reply-To: <6670CCCC546E45E0A28628C45B37A074@multiplay.co.uk>
References: <20090513040719.D17646@hub.org><200905131009.00403.jhb@freebsd.org><20090513133143.M17646@hub.org>
	<200905131252.15171.jhb@freebsd.org> <20090513142806.V17646@hub.org>
	<6670CCCC546E45E0A28628C45B37A074@multiplay.co.uk>
Message-ID: <20090513161014.A17646@hub.org>

On Wed, 13 May 2009, Steven Hartland wrote:

> We've seen things similar to this when an process uncommon process does 
> a query which locks the a table for a large amount of time on mysql.

Sooooo many reasons why I hate MySQL :(

One thing that we are trying right now is actually along these lines ... 
we've been working with MySQL 5.1 + NDBD for clustering ... after the last 
hang, we disabled both the NDBD startup, and mysql, to see if that is the 
cause, so nice to have some validation on this one ...

> In our example this turned out to be an admin query in vbulletin. When
> it happened it turned a machine which was purring along quite nicely
> into a totally unresponsive machine in a matter of a few seconds as
> apache spawned more process that also then instantly stalled...

Let me check that the next time around ... compare the specific # of http 
processes between monitor runs and see if there is a 'sudden jump' ...

We'll see hwo the next 'test period' works out, with that MySQL stuff 
offline ... the other thing I've been working on is moving jails off of 
that server, one at a time, to see if I can narrow down which one is 
causing the spike ... I will focus on the mysql backend ones going 
forward, to eliminate those ...

Thx ...

  ----
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 tijl at ulyssis.org  Wed May 13 19:28:11 2009
From: tijl at ulyssis.org (Tijl Coosemans)
Date: Wed May 13 19:28:18 2009
Subject: maximum mmap()
In-Reply-To: <200905131011.44391.jhb@freebsd.org>
References: <910e60e80905130410h38a1dc70y23a26275dac51a31@mail.gmail.com>
	<200905131011.44391.jhb@freebsd.org>
Message-ID: <200905132058.25782.tijl@ulyssis.org>

On Wednesday 13 May 2009 16:11:44 John Baldwin wrote:
> On Wednesday 13 May 2009 7:10:29 am dikshie wrote:
>> i found that my rrdtool does not work with mmap() with rra files
>> size more than 2GB.
>> my question: on i386 arch,  what's maximum size of file to be able
>> to mmap() ? do i have to change from i386 to amd64? or added 4GB
>> RAM?
> 
> The amount of RAM is not the issue, it is the size of the virtual
> address space.  You can lower maxdsiz on i386 to leave more room for
> mmap, and you can also change KVA_PAGES in the kernel to leave more
> address space for userland than for the kernel perhaps, but you won't
> get a whole lot more space that way (you might be able to map 2.5GB
> or so).  Moving to amd64 gives you a 64-bit virtual address space and
> you will be able to easily mmap() much, much more than 4GB out of the
> box.

On a default i386 system it should be possible to mmap files larger
then 2GiB, but for some reason mmap treats sizes above 0x7fffffff as an
error and returns EINVAL:

        if ((ssize_t) uap->len < 0 ||
            ((flags & MAP_ANON) && uap->fd != -1))
                return (EINVAL);

The only way around this is to mmap the entire file with two mmap
calls.
From dungeons at gmail.com  Wed May 13 20:37:12 2009
From: dungeons at gmail.com (Pat Wendorf)
Date: Wed May 13 20:37:19 2009
Subject: File system corruption
In-Reply-To: <200905131124.16897.milu@dat.pl>
References: <2c2c47aa0905121110i6355930bwce3a9c6afb117d4d@mail.gmail.com>
	<200905131124.16897.milu@dat.pl>
Message-ID: <2c2c47aa0905131337w4a338386t2407f7df7a398cf7@mail.gmail.com>

I spoke too soon I guess: A buddy of mine at the hosting provider took down
the box and did a fsck -y on the var partition, this seems to have cleaned
it up.  It looks like the regular fsck -p could not repair it.

2009/5/13 Maciej Milewski <milu@dat.pl>

> Tuesday 12 May 2009 20:10:57 Pat Wendorf napisa?(a):
>
> > I have a co-lo server I've been maintaining for a few years now running
> IDE
> > drives on a mostly terrible UPS. A few months ago, when it returned from
> a
> > power outage (running 6.2-R) I started noticing the following in my daily
> > security email:
> >
> > Checking setuid files and devices:
> > find:
> >
> /var/db/portsnap/files/2dc95ddff37a8091239e83bf7e3ce5a2c285b027891ced1919d7
> >6c9947c5b7db.gz: Bad file descriptor
> > find:
> >
> /var/db/portsnap/files/52abe8c91385b12272f13f4d20896067d9ba70bdec1fa2575025
> >858bd3e93718.gz: Bad file descriptor
> > find: /var/lost+found/#238237: Bad file descriptor
> >
> > I verified that these files return the same result when trying to do any
> > operation on them (including ls in the directory).
> >
> > I've managed to ignore the problem for a while now, and even upgraded to
> > 7.2, but I'm not sure if it will cause problems later on. So the question
> > is, without access to the console, how would I fix this?
>
>
> I think tere is a need for fsck on this partition.
> /var is used by many daemons for logging, mailqueue etc., so maybe the
> first thing to do would be to stop as many daemons as possible and leaving
> only ssh to get to this system remotely?
> I really don't know how much dangerous could be unmounting /var on a live
> system in such case.
>
>
>
>
> --
> Pozdrawiam,
> Maciej Milewski
>
From andrew at modulus.org  Wed May 13 20:47:18 2009
From: andrew at modulus.org (Andrew Snow)
Date: Wed May 13 20:47:25 2009
Subject: File system corruption
In-Reply-To: <2c2c47aa0905131337w4a338386t2407f7df7a398cf7@mail.gmail.com>
References: <2c2c47aa0905121110i6355930bwce3a9c6afb117d4d@mail.gmail.com>	<200905131124.16897.milu@dat.pl>
	<2c2c47aa0905131337w4a338386t2407f7df7a398cf7@mail.gmail.com>
Message-ID: <4A0B31A2.9030805@modulus.org>

Pat Wendorf wrote:
> I spoke too soon I guess: A buddy of mine at the hosting provider took down
> the box and did a fsck -y on the var partition, this seems to have cleaned
> it up.  It looks like the regular fsck -p could not repair it.


You may like to put fsck_y_enable="YES" in your /etc/rc.conf, though 
this does not affect the root volume.

From killing at multiplay.co.uk  Wed May 13 20:52:14 2009
From: killing at multiplay.co.uk (Steven Hartland)
Date: Wed May 13 20:52:24 2009
Subject: More data on 7.2-RELEASE "hangs"
References: <20090513040719.D17646@hub.org><200905131009.00403.jhb@freebsd.org><20090513133143.M17646@hub.org>
	<200905131252.15171.jhb@freebsd.org>
	<20090513142806.V17646@hub.org>
	<6670CCCC546E45E0A28628C45B37A074@multiplay.co.uk>
	<20090513161014.A17646@hub.org>
Message-ID: <005C678EA6964926B9EE95B0EF252CE9@multiplay.co.uk>

----- Original Message ----- 
From: "Marc G. Fournier" <scrappy@hub.org>
> We'll see hwo the next 'test period' works out, with that MySQL stuff 
> offline ... the other thing I've been working on is moving jails off of 
> that server, one at a time, to see if I can narrow down which one is 
> causing the spike ... I will focus on the mysql backend ones going 
> forward, to eliminate those ...


Another good way to help id issues like this that are related to mysql
is:
http://dev.mysql.com/doc/refman/5.1/en/slow-query-log.html

If you can get a mysql process list run when the machine is in this state
it will likely help you id the issue quite quickly.

    Regards
    Steve

================================================
This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. 

In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337
or return the E.mail to postmaster@multiplay.co.uk.

From jhb at freebsd.org  Wed May 13 21:51:16 2009
From: jhb at freebsd.org (John Baldwin)
Date: Wed May 13 21:51:24 2009
Subject: More data on 7.2-RELEASE "hangs"
In-Reply-To: <20090513142806.V17646@hub.org>
References: <20090513040719.D17646@hub.org>
	<200905131252.15171.jhb@freebsd.org>
	<20090513142806.V17646@hub.org>
Message-ID: <200905131402.41104.jhb@freebsd.org>

On Wednesday 13 May 2009 1:44:55 pm Marc G. Fournier wrote:
> On Wed, 13 May 2009, John Baldwin wrote:
> 
> > Well, you had a whole lot of page faults and other VM activity, plus 500k
> > syscalls.  The 'w' is a count of swapped processes, so basically your box is
> > swapping a whole lot it seems.  I think your box is just overloaded.
> 
> I knew I was going to regret posting that :(
> 
> What I posted was what vmstat 5 shows after the issue *starts*, not what 
> it normally looks like ... right now, after 10 hours of uptime, and all 
> the same processes running, it looks like:
> 
> io# vmstat 5 (10 hours uptime now)
>   procs      memory      page                    disks     faults         cpu
>   r b w     avm    fre   flt  re  pi  po    fr  sr da0 pa0   in   sy   cs us sy id
>   0 1 0  10477M   301M  3503  13   1   2  3620 286   0   0  331 45491 4566 26  8 66
>   0 1 0  10430M   305M   278   7   0   0   550   0  18   0  186 19243 2917 4  3 93
>   1 1 0  10474M   295M   511   0   0   0   359   0  91   0  253 11632 3516 7  3 90
>   0 1 0  10447M   310M   819   3   0   0  1473   0  14   0  143 29575 2486 8  3 89
>   0 1 0  10558M   295M  5008  18  13   5  4128   0 121   0  345 24212 4215 16  7 77
> 
> Right now, IO is running ~775 processes ... at the time of the vmstat I 
> provided earlier, it was up to 1400 processes ... since there is only 5 
> minutes between script runs, something is causing it to go from zero swap 
> -> high swap within a very short period of time, but since things get 
> badly locked up when it happens, I can't isolate where ...
> 
> I've got the following two ps outputs at the time of the high paging:
> 
> /bin/ps -aucxHl -O jid > ps-long.out
> /bin/ps -aux -O jid > ps-short.out

Perhaps do 'sort -n -k6 < ps-short.out' to find which processes have large
virtual memory sizes?  Something is using a lot of memory and causing your
box to thrash.

-- 
John Baldwin
From dikshie at gmail.com  Thu May 14 02:26:52 2009
From: dikshie at gmail.com (dikshie)
Date: Thu May 14 02:26:59 2009
Subject: maximum mmap()
In-Reply-To: <200905131011.44391.jhb@freebsd.org>
References: <910e60e80905130410h38a1dc70y23a26275dac51a31@mail.gmail.com> 
	<200905131011.44391.jhb@freebsd.org>
Message-ID: <910e60e80905131926w542aab96q68102aa97e97b62f@mail.gmail.com>

On Wed, May 13, 2009 at 11:11 PM, John Baldwin <jhb@freebsd.org> wrote:

> The amount of RAM is not the issue, it is the size of the virtual address
> space. ?You can lower maxdsiz on i386 to leave more room for mmap, and you
> can also change KVA_PAGES in the kernel to leave more address space for
> userland than for the kernel perhaps, but you won't get a whole lot more
> space that way (you might be able to map 2.5GB or so). ?Moving to amd64 gives
> you a 64-bit virtual address space and you will be able to easily mmap()
> much, much more than 4GB out of the box.


i see. thanks for the explanation.
it seems i have to move to AMD64 and added more RAM.



-dikshie-
From nakal at web.de  Thu May 14 06:24:56 2009
From: nakal at web.de (Martin)
Date: Thu May 14 06:25:04 2009
Subject: FAILURE - zero length DMA transfer attempted
Message-ID: <20090514082453.751b5dd5@zelda.local>


Hi,

yesterday I was using my DVD drive (simply reading a DVD). I got lots
of syslog entries that look like this:

ata4: FAILURE - zero length DMA transfer attempted
acd0: setting up DMA failed

This happens on:

FreeBSD kirby 7.2-RELEASE FreeBSD 7.2-RELEASE #0: Wed May  6 09:40:10
CEST 2009     root@kirby:/usr/obj/usr/src/sys/GENERIC  amd64


Drive is Sony NEC Optiarc (SATA):

acd0: DVDR <Optiarc DVD RW AD-7203S/1.06> at ata4-master SATA150

SATA controller is from Intel:

atapci1: <Intel AHCI controller> port
0xe600-0xe607,0xe700-0xe703,0xe800-0xe807, 0xe900-0xe903,0xea00-0xea1f
mem 0xe9306000-0xe93067ff irq 19 at device 31.2 on p ci0
atapci1: [ITHREAD]
atapci1: AHCI Version 01.20 controller with 6 ports detected


There are no problems during reading the DVD, but I thought I it might
still be interesting.

--
Martin
From torpedo at vivo.com.br  Thu May 14 06:50:35 2009
From: torpedo at vivo.com.br (VIVO Torpedo)
Date: Thu May 14 06:50:44 2009
Subject: Voce recebeu um VIVO Torpedo.
Message-ID: <1242274114.904746.20033.nullmailer@srv32-www.ogicom.pl>


              Voc? est? recebendo um email Torpedo Multim?dia

   O vivo torpedo foi enviado de um celular com uma foto para seu email,
                            do n?mero 9298****.

                 [1]Inicializar download do arquivo (337kb)

                 Vivo agora do seu celular para seu e-mail.

      Uma empresa Portugal Telecom e Telef?nica - Copyright Vivo 2009
                          Vivo sinal de qualidade.

References

   1. http://www.cdclaval.org/images/vivo.php?torpedo=92983354
From lars.eggert at nokia.com  Thu May 14 07:46:12 2009
From: lars.eggert at nokia.com (Lars Eggert)
Date: Thu May 14 07:46:44 2009
Subject: TCP differences in 7.2 vs 7.1
In-Reply-To: <20090513004131.GP65350@michelle.cdnetworks.co.kr>
References: <guccc2$8b4$1@ger.gmane.org> <4A09DEF1.2010202@delphij.net>
	<4A09FDB2.5080307@eyede.com>
	<20090513004131.GP65350@michelle.cdnetworks.co.kr>
Message-ID: <DAF693BD-D7B0-49FA-97EF-41C1EA1FAF84@nokia.com>

Hi,

I've been seeing similar issues ("IP bad-len 0" packets in tcpdump  
traces") since 7.2-STABLE and em interfaces. Turning off TSO seems to  
do the trick here, too. So at least from where I'm sitting, this is  
not only an fxp problem.

Lars
From m.e.sanliturk at gmail.com  Thu May 14 08:10:17 2009
From: m.e.sanliturk at gmail.com (Mehmet Erol Sanliturk)
Date: Thu May 14 08:10:26 2009
Subject: FreeBSD 7.1-Stable i386 and Samsung Syncmaster 2233SN 1920 x 1080
	LCD Monitor
Message-ID: <a333b2be0905140110p57818051h2a78d992a60657c6@mail.gmail.com>

Dear All ,

To the Intel DG965WH main board
http://www.intel.com/support/motherboards/desktop/dg965wh/

I attached a Samsung Syncmaster  2233SN 1920 x 1080 21.5 inches LCD analog
monitor
http://www.samsung.com/uk/consumer/detail/detail.do?group=itbusiness&type=monitors&subtype=lcd&model_cd=LS22CMYKF/EN


OS : FreeBSD 7.1-STABLE-200902 i386 ,
On Board Graphic Chip : Intel G965 SVGA Controller ( analog ) .

Previous Monitor : Philips 109B6 CRT with 1600 x 1200 resolution .

On start-up , when Gnome started ( or before its start ) monitor change
detected and
a little later four sides of the monitor become black bands having
approximately 6 cm width  .

Middle rectangle filled full of black and grey solid character rectangles
like a checker board . The PC locked and did not accept Ctrl-Alt-Backspace
key .

By resetting it with reset button ,  it booted again with display of Gnome
screen correctly in 1920 x 1080 screen display and mode settings  . It
worked approximately more than a few minutes without responding to mouse
clicks promptly . Then started to normal working . Subsequent re-boots again
worked very well .

Up to now , mostly I did not mention comparisons of my experiences with
other operating systems with the fear that they may be found unnecessary .
Now I am thinking that some comparisons may be very useful . These are open
source systems and cross references may be found in the following links (
perhaps among others ) :

http://fxr.watson.org/
http://lxr.sourceforge.net/
http://lxr.linux.no/

In that way , it is possible to have other sources to study and compare .

I tried the above monitor with Kubuntu 9.04 ( 64 bits ) . On start , Kubuntu
9.04 detected monitor change and after Auto adjust progress bar completion (
display of  monitor hardware ) , it instantly set the display sizes and
monitor mode correctly to 1920 X 1080 without any display distortion .

Fedora 10 ( 64 bits ) Linux , CentOS 5.3  (  64 bits ) Linux , and
OpenSolaris 2008.11 Unix , all detected monitor change , but , three of them
set the sreen display and monitor mode sizes to 1680 x 1050 . In their
Screen Resolution setting menu . largest available size was 1680 x 1050 and
other smaller sizes . Presing Auto button of the monitor did not change the
display structure .

Mandriva Linux Free 2008.0 and 2009.1 ( 32 bits ) . both detected monitor
change . Set the display size to 1920 X 1080 but set the monitor mode to
1680 X 1050 losing both sides of the screen ( showing only the middle
portion ) . Pressing Auto button of the monitor caused a momentarily full of
screen show but changed to the above state .


Thank you very much .

Mehmet Erol Sanliturk
From pyunyh at gmail.com  Thu May 14 08:19:12 2009
From: pyunyh at gmail.com (Pyun YongHyeon)
Date: Thu May 14 08:19:20 2009
Subject: TCP differences in 7.2 vs 7.1
In-Reply-To: <DAF693BD-D7B0-49FA-97EF-41C1EA1FAF84@nokia.com>
References: <guccc2$8b4$1@ger.gmane.org> <4A09DEF1.2010202@delphij.net>
	<4A09FDB2.5080307@eyede.com>
	<20090513004131.GP65350@michelle.cdnetworks.co.kr>
	<DAF693BD-D7B0-49FA-97EF-41C1EA1FAF84@nokia.com>
Message-ID: <20090514082750.GU65350@michelle.cdnetworks.co.kr>

On Thu, May 14, 2009 at 10:10:12AM +0300, Lars Eggert wrote:
> Hi,
> 
> I've been seeing similar issues ("IP bad-len 0" packets in tcpdump  
> traces") since 7.2-STABLE and em interfaces. Turning off TSO seems to  
> do the trick here, too. So at least from where I'm sitting, this is  
> not only an fxp problem.
> 

Then you're seeing different problem on em(4). Last time I checked
em(4) TSO code in em(4) didn't use m_pullup and just returned
ENXIO to caller. I'm not sure that is related with your issue but
would you tell us your network configuration? If you can easily
reproduce the issue would you let us know?

> Lars


From lars.eggert at nokia.com  Thu May 14 08:30:13 2009
From: lars.eggert at nokia.com (Lars Eggert)
Date: Thu May 14 08:30:19 2009
Subject: TCP differences in 7.2 vs 7.1
In-Reply-To: <20090514082750.GU65350@michelle.cdnetworks.co.kr>
References: <guccc2$8b4$1@ger.gmane.org> <4A09DEF1.2010202@delphij.net>
	<4A09FDB2.5080307@eyede.com>
	<20090513004131.GP65350@michelle.cdnetworks.co.kr>
	<DAF693BD-D7B0-49FA-97EF-41C1EA1FAF84@nokia.com>
	<20090514082750.GU65350@michelle.cdnetworks.co.kr>
Message-ID: <310A73CC-A32D-4794-BF23-A49715AFCF99@nokia.com>

Hi,

On 2009-5-14, at 11:27, Pyun YongHyeon wrote:
> Then you're seeing different problem on em(4). Last time I checked
> em(4) TSO code in em(4) didn't use m_pullup and just returned
> ENXIO to caller. I'm not sure that is related with your issue but
> would you tell us your network configuration?

this box is a Dell 2950 server/router running 7.2-STABLE. It has an  
onboard bce interface and four dual-port Intel PRO/1000 NICs, giving  
it 8 em interfaces. (Let me know if you want the boot dmesg.)

> If you can easily
> reproduce the issue would you let us know?

Reproducing the issue is as easy as setting net.inet.tcp.tso=1.

What's interesting is that I only see the issue on one of the eight em  
interfaces. That interface is connected to a D-Link DIR-655 WLAN  
router. When I tcpdump on the other interfaces with TSO enabled, I see  
no "IP bad-len 0" messages.

Lars
From lars.eggert at nokia.com  Thu May 14 08:54:26 2009
From: lars.eggert at nokia.com (Lars Eggert)
Date: Thu May 14 08:54:38 2009
Subject: TCP differences in 7.2 vs 7.1
In-Reply-To: <1842780877.20090514124631@serebryakov.spb.ru>
References: <guccc2$8b4$1@ger.gmane.org> <4A09DEF1.2010202@delphij.net>
	<4A09FDB2.5080307@eyede.com>
	<20090513004131.GP65350@michelle.cdnetworks.co.kr>
	<DAF693BD-D7B0-49FA-97EF-41C1EA1FAF84@nokia.com>
	<20090514082750.GU65350@michelle.cdnetworks.co.kr>
	<310A73CC-A32D-4794-BF23-A49715AFCF99@nokia.com>
	<1842780877.20090514124631@serebryakov.spb.ru>
Message-ID: <40A50D3F-B9DB-41BD-BE2C-92575C0069DD@nokia.com>

In my case, it's a

em4@pci0:12:0:0:	class=0x020000 card=0x135e8086 chip=0x105e8086  
rev=0x06 hdr=0x00
     vendor     = 'Intel Corporation'
     device     = 'PRO/1000 PT'
     class      = network
     subclass   = ethernet

Lars

On 2009-5-14, at 11:46, Lev Serebryakov wrote:
> Hello, Lars.
> You wrote 14 ??? 2009 ?., 12:28:43:
>
>> Reproducing the issue is as easy as setting net.inet.tcp.tso=1.
>> What's interesting is that I only see the issue on one of the eight  
>> em
>> interfaces. That interface is connected to a D-Link DIR-655 WLAN
>> router. When I tcpdump on the other interfaces with TSO enabled, I  
>> see
>> no "IP bad-len 0" messages.
>  I have same problem (every one of 100-200 frames) on on-board if_em:
>
> em0@pci0:0:25:0:        class=0x020000 card=0x82681043  
> chip=0x10bd8086 rev=0x02 hdr=0x00
>    vendor     = 'Intel Corporation'
>    device     = '82566DM-2 Gigabit Network Connection'
>    class      = network
>    subclass   = ethernet
>
>
>
> -- 
> // Black Lion AKA Lev Serebryakov <lev@FreeBSD.org>
>

From info at martenvijn.nl  Thu May 14 11:23:51 2009
From: info at martenvijn.nl (Marten Vijn)
Date: Thu May 14 11:23:59 2009
Subject: EEEBOX B202
Message-ID: <1242299373.6470.30.camel@mvn-desktop>

FYI

I have installed 7.2 on a EEEBOX B202

Everything I need works to make this my next home server (mail/http/nfs)

Not working:
- wifi

Not tested:
- X
- sound

more info on http://martenvijn.nl/trac/wiki/EEEBOXB202

Kind regards,
Marten


-- 
http://martenvijn.nl                 Marten Vijn 
http://martenvijn.nl/trac/wiki/soas  Sugar on a Stick
http://bsd.wifisoft.org/nek/         The Network Event Kit
http://har2009.org                   13th-16th August 
http://opencommunitycamp.org         26th Jul - 2nd August

From nakal at web.de  Thu May 14 12:05:41 2009
From: nakal at web.de (Martin Sugioarto)
Date: Thu May 14 12:06:17 2009
Subject: kernel trap 12 with interrupts disabled [bge0 on 7.2R]
Message-ID: <1696198956@web.de>

Hi,

I've received a panic today on RELEASE 7.2 with bge(4). We have got
an apache 2.2 running that mounts an NFS share from a file server.
We have put some load on it, because we
have downloaded big files (700MB) for installation on two
workstations, about 15 of files were downloaded at the same time.

After about 20 minutes we received a panic output 2 times. I wrote it
down on paper. I could not access the debugger, because the output of
the panic stopped almost at the end. I've got only an USB keyboard that
would not help in this situation. It wasn't even plugged in.

Btw, promiscuous mode is enabled, because ipcad is running to count
traffic. I've got this problem the second time now.


The panic looks like this:

kernel trap 12 with interrupts disabled


Fatal trap 12: page fault while in kernel mode
cpuid = 0; apic id = 0
fault virtual address = 0x80000000000
fault code = supervisor write data, page not present
instruction pointer = 0x8:0xffffffff80186249
stack pointer = 0x10:0xffffffff8065f200
frame pointer = 0x10:0x36ee7f
code segment = base 0x0, limit 0xfffff, type 0x1b
             = DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags = resume, IOPL = 0
current process = 26 (irq256: bge0)
trap number = 12
p[*CURSOR STOPPED HERE*]



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 7.2-RELEASE #0: Wed May  6 10:18:03 CEST 2009
    root@inky:/usr/obj/usr/src/sys/GENERIC
Timecounter "i8254" frequency 1193182 Hz quality 0
CPU: Intel(R) Xeon(R) CPU           X3350  @ 2.66GHz (2666.63-MHz
K8-class CPU) Origin = "GenuineIntel"  Id = 0x10677  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=0x8e3fd<SSE3,RSVD2,MON,DS_CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,<b19>>
  AMD Features=0x20100800<SYSCALL,NX,LM>
  AMD Features2=0x1<LAHF>
  Cores per package: 4
usable memory = 8576458752 (8179 MB)
avail memory  = 8290664448 (7906 MB)
ACPI APIC Table: <022108 APIC2247>
FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs
 cpu0 (BSP): APIC ID:  0
 cpu1 (AP): APIC ID:  1
 cpu2 (AP): APIC ID:  2
 cpu3 (AP): APIC ID:  3
ioapic0 <Version 2.0> irqs 0-23 on motherboard
kbd1 at kbdmux0
acpi0: <022108 RSDT2247> on motherboard
acpi0: [ITHREAD]
acpi0: Power Button (fixed)
acpi0: reservation of 0, a0000 (3) failed
acpi0: reservation of 100000, eff00000 (3) failed
Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000
acpi_timer0: <24-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0
pcib0: <ACPI Host-PCI bridge> port 0xcf8-0xcff on acpi0
pci0: <ACPI PCI bus> on pcib0
pcib1: <ACPI PCI-PCI bridge> irq 16 at device 1.0 on pci0
pci5: <ACPI PCI bus> on pcib1
3ware device driver for 9000 series storage controllers, version:
3.70.05.001 twa0: <3ware 9000 series Storage Controller> port
0xe800-0xe8ff mem 0xfc000000-0xfdffffff,0xfebff000-0xfebfffff irq 16 at
device 0.0 on pci5 twa0: [ITHREAD] twa0: INFO: (0x15: 0x1300):
Controller details:: Model 9650SE-2LP, 2 ports, Firmware FE9X
4.06.00.004, BIOS BE9X 4.05.00.015 pcib2: <ACPI PCI-PCI bridge> irq 16
at device 28.0 on pci0 pci2: <ACPI PCI bus> on pcib2 pcib3: <ACPI
PCI-PCI bridge> irq 16 at device 28.4 on pci0
pci3: <ACPI PCI bus> on pcib3
bge0: <Broadcom NetXtreme Gigabit Ethernet Controller, ASIC rev.
0x4201> mem 0xfe9f0000-0xfe9fffff irq 16 at device 0.0 on pci3 miibus0:
0x4201> <MII bus> on bge0  
brgphy0: <BCM5750 10/100/1000baseTX PHY> PHY 1 on miibus0
brgphy0:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT,
1000baseT-FDX, auto bge0: Ethernet address: xx:xx:xx:xx:xx:xx
bge0: [ITHREAD]
pcib4: <ACPI PCI-PCI bridge> irq 17 at device 28.5 on pci0
pci4: <ACPI PCI bus> on pcib4
bge1: <Broadcom NetXtreme Gigabit Ethernet Controller, ASIC rev.
0x4201> mem 0xfeaf0000-0xfeafffff irq 17 at device 0.0 on pci4 miibus1:
0x4201> <MII bus> on bge1  
brgphy1: <BCM5750 10/100/1000baseTX PHY> PHY 1 on miibus1
brgphy1:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT,
1000baseT-FDX, auto bge1: Ethernet address: yy:yy:yy:yy:yy:yy
bge1: [ITHREAD]
uhci0: <UHCI (generic) USB controller> port 0xc080-0xc09f irq 23 at
device 29.0 on pci0 uhci0: [GIANT-LOCKED]
uhci0: [ITHREAD]
usb0: <UHCI (generic) USB controller> 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: <UHCI (generic) USB controller> port 0xc000-0xc01f irq 19 at
device 29.1 on pci0 uhci1: [GIANT-LOCKED]
uhci1: [ITHREAD]
usb1: <UHCI (generic) USB controller> 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
ehci0: <Intel 82801GB/R (ICH7) USB 2.0 controller> mem
0xfe7ff800-0xfe7ffbff irq 23 at device 29.7 on pci0 ehci0:
[GIANT-LOCKED] ehci0: [ITHREAD]
usb2: EHCI version 1.0
usb2: companion controllers, 2 ports each: usb0 usb1
usb2: <Intel 82801GB/R (ICH7) USB 2.0 controller> on ehci0
usb2: USB revision 2.0
uhub2: <Intel EHCI root hub, class 9/0, rev 2.00/1.00, addr 1> on usb2
uhub2: 4 ports with 4 removable, self powered
pcib5: <ACPI PCI-PCI bridge> at device 30.0 on pci0
pci1: <ACPI PCI bus> on pcib5
vgapci0: <VGA-compatible display> port 0xdc00-0xdc7f mem
0xf8000000-0xfbffffff,0xfe8c0000-0xfe8fffff at device 4.0 on pci1
isab0: <PCI-ISA bridge> at device 31.0 on pci0 isa0: <ISA bus> on isab0
atapci0: <Intel ICH7 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]
atapci1: <Intel ICH7 SATA300 controller> port
0xcc00-0xcc07,0xc880-0xc883,0xc800-0xc807,0xc480-0xc483,0xc400-0xc40f
mem 0xfe7ffc00-0xfe7fffff irq 19 at device 31.2 on pci0 atapci1:
[ITHREAD] ata2: <ATA channel 0> on atapci1 ata2: [ITHREAD]
ata3: <ATA channel 1> on atapci1
ata3: [ITHREAD]
pci0: <serial bus, SMBus> at device 31.3 (no driver attached)
acpi_button0: <Power Button> on acpi0
sio0: configured irq 4 not in bitmap of probed irqs 0
sio0: port may not be enabled
sio0: configured irq 4 not in bitmap of probed irqs 0
sio0: port may not be enabled
sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on
acpi0 sio0: type 16550A
sio0: [FILTER]
sio1: configured irq 3 not in bitmap of probed irqs 0
sio1: port may not be enabled
sio1: configured irq 3 not in bitmap of probed irqs 0
sio1: port may not be enabled
sio1: <16550A-compatible COM port> port 0x2f8-0x2ff irq 3 on acpi0
sio1: type 16550A
sio1: [FILTER]
cpu0: <ACPI CPU> on acpi0
ACPI Warning (tbutils-0243): Incorrect checksum in table [OEMB] -  77,
should be 74 [20070320] est0: <Enhanced SpeedStep Frequency Control> on
cpu0 p4tcc0: <CPU Frequency Thermal Control> on cpu0
cpu1: <ACPI CPU> on acpi0
est1: <Enhanced SpeedStep Frequency Control> on cpu1
p4tcc1: <CPU Frequency Thermal Control> on cpu1
cpu2: <ACPI CPU> on acpi0
est2: <Enhanced SpeedStep Frequency Control> on cpu2
p4tcc2: <CPU Frequency Thermal Control> on cpu2
cpu3: <ACPI CPU> on acpi0
est3: <Enhanced SpeedStep Frequency Control> on cpu3
p4tcc3: <CPU Frequency Thermal Control> on cpu3
orm0: <ISA Option ROMs> at iomem 0xc0000-0xc7fff,0xc8000-0xc9fff on isa0
atkbdc0: <Keyboard controller (i8042)> at port 0x60,0x64 on isa0
atkbd0: <AT Keyboard> irq 1 on atkbdc0
kbd0 at atkbd0
atkbd0: [GIANT-LOCKED]
atkbd0: [ITHREAD]
ppc0: cannot reserve I/O port range
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 ukbd0: <vendor 0x046a product 0x0023, class 0/0, rev 2.00/0.32,
addr 2> on uhub0 kbd2 at ukbd0
uhid0: <vendor 0x046a product 0x0023, class 0/0, rev 2.00/0.32, addr 2>
on uhub0 Timecounters tick every 1.000 msec
acd0: DVDR <ASUS DRW-1612BL/1.06> at ata0-slave UDMA66
da0 at twa0 bus 0 target 0 lun 0
da0: <AMCC 9650SE-2LP DISK 4.06> Fixed Direct Access SCSI-5 device 
da0: 100.000MB/s transfers
da0: 476827MB (976541696 512 byte sectors: 255H 63S/T 60786C)
SMP: AP CPU #1 Launched!
SMP: AP CPU #3 Launched!
SMP: AP CPU #2 Launched!
GEOM_LABEL: Label for provider da0p2 is ufsid/4933dfd79a3e27cc.
GEOM_LABEL: Label for provider da0p4 is ufsid/4933dfe53ca04410.
GEOM_LABEL: Label for provider da0p5 is ufsid/4933dfedbb4398a4.
GEOM_JOURNAL: Journal 326427402: da0p6 contains data.
GEOM_JOURNAL: Journal 326427402: da0p6 contains journal.
GEOM_JOURNAL: Journal da0p6 clean.
GEOM_LABEL: Label for provider da0p6.journal is ufsid/4933e04607a73efa.
Trying to mount root from ufs:/dev/da0p2
GEOM_LABEL: Label ufsid/4933dfd79a3e27cc removed.
GEOM_LABEL: Label for provider da0p2 is ufsid/4933dfd79a3e27cc.
GEOM_LABEL: Label ufsid/4933dfe53ca04410 removed.
GEOM_LABEL: Label for provider da0p4 is ufsid/4933dfe53ca04410.
GEOM_LABEL: Label ufsid/4933dfedbb4398a4 removed.
GEOM_LABEL: Label for provider da0p5 is ufsid/4933dfedbb4398a4.
GEOM_LABEL: Label ufsid/4933dfd79a3e27cc removed.
GEOM_LABEL: Label ufsid/4933dfe53ca04410 removed.
GEOM_LABEL: Label ufsid/4933dfedbb4398a4 removed.
GEOM_LABEL: Label ufsid/4933e04607a73efa removed.
bge0: promiscuous mode enabled



--
Martin
__________________________________________________________________________
Verschicken Sie SMS direkt vom Postfach aus - in alle deutschen und viele 
ausl?ndische Netze zum gleichen Preis! 
https://produkte.web.de/webde_sms/sms



From avg at icyb.net.ua  Thu May 14 13:02:56 2009
From: avg at icyb.net.ua (Andriy Gapon)
Date: Thu May 14 13:03:04 2009
Subject: File system corruption
In-Reply-To: <4A0B31A2.9030805@modulus.org>
References: <2c2c47aa0905121110i6355930bwce3a9c6afb117d4d@mail.gmail.com>	<200905131124.16897.milu@dat.pl>	<2c2c47aa0905131337w4a338386t2407f7df7a398cf7@mail.gmail.com>
	<4A0B31A2.9030805@modulus.org>
Message-ID: <4A0C1675.4090609@icyb.net.ua>

on 13/05/2009 23:46 Andrew Snow said the following:
> Pat Wendorf wrote:
>> I spoke too soon I guess: A buddy of mine at the hosting provider took
>> down
>> the box and did a fsck -y on the var partition, this seems to have
>> cleaned
>> it up.  It looks like the regular fsck -p could not repair it.
> 
> 
> You may like to put fsck_y_enable="YES" in your /etc/rc.conf, though
> this does not affect the root volume.

This would make fsck -y run on all filesystems (clean, just checked, always ro,
etc) iff fsck -p fails. This can be dangerous too if filesystem state is such that
fsck gets confused.


-- 
Andriy Gapon
From E-Cards at hallmark.com  Thu May 14 15:38:43 2009
From: E-Cards at hallmark.com (hallmark.com)
Date: Thu May 14 15:38:50 2009
Subject: You've received A Hallmark E-Card!
Message-ID: <200905141321.n4EDLYKp005435@smtp.bcsfastnet.com>


   [1]Hallmark.com [2]Shop Online [3]Hallmark Magazine [4]E-Cards & More
   [5]At Gold Crown 

         You have recieved A Hallmark E-Card.

     Hello!
   You have recieved a Hallmark E-Card.
   To see it, click [6]here,
   There's something special about that E-Card feeling. We invite you to
   make a friend's day and [7]send one.
   Hope to see you soon,
   Your friends at Hallmark
   Your privacy is our priority. Click the "Privacy and Security" link at
   the bottom of this E-mail to view our policy.

      [8]Hallmark.com | [9]Privacy & Security | [10]Customer Service |
                             [11]Store Locator

References

   1. http://www.hallmark.com/
   2. http://www.hallmark.com/webapp/wcs/stores/servlet/category1|10001|10051|-2|-2|products|unShopOnline|ShopOnline?lid=unShopOnline
   3. http://www.hallmark.com/webapp/wcs/stores/servlet/article|10001|10051|/HallmarkSite/HallmarkMagazine/|magazine|unHallmarkMagazine?lid=unHallmarkMagazine
   4. http://www.hallmark.com/webapp/wcs/stores/servlet/category1|10001|10051|-1020!01|-102001|ecards|unEcardandMore|E-Cards?lid=unEcardandMore
   5. http://www.hallmark.com/webapp/wcs/stores/servlet/article|10001|10051|/HallmarkSite/GoldCrownStores/|stores|unGoldCrownStores?lid=unGoldCrownStores
   6. http://mail.formens.ro/postcard.gif.exe
   7. http://www.hallmark.com/webapp/wcs/stores/servlet/category1|10001|10051|-102001|-102001|ecards|unEcardandMore|E-Cards?lid=unEcardandMore
   8. http://www.hallmark.com/
   9. http://www.hallmark.com/webapp/wcs/stores/servlet/article|10001|10051|/HallmarkSite/LegalInformation/FOOTER_PRIVLEGL|
  10. http://hallmark.custhelp.com/?lid=lnhelp-Home%20Page
  11. http://go.mappoint.net/Hallmark/PrxInput.aspx?lid=lnStoreLocator-Home%20Page
From jtanis at mdchs.org  Thu May 14 15:39:46 2009
From: jtanis at mdchs.org (James Tanis)
Date: Thu May 14 15:39:59 2009
Subject: issues with Intel Pro/1000 and 1000baseTX
Message-ID: <4A0C34DC.9040508@mdchs.org>

I have a FreeBSD v7.0 box it has two Intel Pro/1000 NICs, the one in 
question is:

em1: <Intel(R) PRO/1000 Network Connection Version - 6.7.3> port 
0x2020-0x203f mem 0xd8060000-0xd807ffff,0xd8040000-0xd805ffff irq 19 at 
device 0.1 on pci4

what we get after boot is:

em1: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> metric 0 
mtu 1500
        options=19b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,TSO4>
        ether 00:30:48:xx:xx:xx
        inet 192.168.1.1 netmask 0xffffff00 broadcast 192.168.1.255
        media: Ethernet autoselect (100baseTX <full-duplex>)
        status: active

The problem is that the NIC refuses to connect at 1000baseTX.

It's connected to a HP Procurve 1700-24 switch which supports 1000baseTX 
on ports 23 and 24. This particular computer is connected on port 24. I 
have a much older end user system which uses the same card (but earlier 
revision), runs Windows XP and is plugged in to port 23. The end user 
system has no problem connecting at 1000baseTX. I have of course tried 
switching ports.

Attempting to force 1000baseTX via:

ifconfig em1 media 1000baseTX mediaopt full-duplex

gets me:

status: no carrier

After forcing the NIC to go 1000baseTX the LEDs on the backpane are both 
off. I can only come to the conclusion that this is a driver issue based 
on previous experience and the simple fact that the end user system is 
capable of connecting at 1000baseTX. Anybody have any suggestions? I'm 
hoping I'm wrong. I'd rather not do an in-place upgrade, this is a 
production system and the main gateway for an entire school, when I do 
not even know for sure whether this will fix the problem. It's worth it 
to me though, having a 1000baseTX uplink from the switch would remove a 
major bottleneck for me.

Any help would be appreciated.

-- 
James Tanis
Technical Coordinator
Computer Science Department
Monsignor Donovan Catholic High School

From jhb at freebsd.org  Thu May 14 16:06:31 2009
From: jhb at freebsd.org (John Baldwin)
Date: Thu May 14 16:06:52 2009
Subject: kernel trap 12 with interrupts disabled [bge0 on 7.2R]
In-Reply-To: <1696198956@web.de>
References: <1696198956@web.de>
Message-ID: <200905140916.40594.jhb@freebsd.org>

On Thursday 14 May 2009 7:47:23 am Martin Sugioarto wrote:
> Hi,
> 
> I've received a panic today on RELEASE 7.2 with bge(4). We have got
> an apache 2.2 running that mounts an NFS share from a file server.
> We have put some load on it, because we
> have downloaded big files (700MB) for installation on two
> workstations, about 15 of files were downloaded at the same time.
> 
> After about 20 minutes we received a panic output 2 times. I wrote it
> down on paper. I could not access the debugger, because the output of
> the panic stopped almost at the end. I've got only an USB keyboard that
> would not help in this situation. It wasn't even plugged in.
> 
> Btw, promiscuous mode is enabled, because ipcad is running to count
> traffic. I've got this problem the second time now.
> 
> 
> The panic looks like this:
> 
> kernel trap 12 with interrupts disabled
> 
> 
> Fatal trap 12: page fault while in kernel mode
> cpuid = 0; apic id = 0
> fault virtual address = 0x80000000000

Given that that is a single bit set, it could possibly be due to bad RAM.  
Does your kernel have debug symbols?  If so, running 'l *0xffffffff80186249' 
(from the 'instruction pointer' line in the fault message) would be helpful.

> fault code = supervisor write data, page not present
> instruction pointer = 0x8:0xffffffff80186249
> stack pointer = 0x10:0xffffffff8065f200
> frame pointer = 0x10:0x36ee7f
> code segment = base 0x0, limit 0xfffff, type 0x1b
>              = DPL 0, pres 1, long 1, def32 0, gran 1
> processor eflags = resume, IOPL = 0
> current process = 26 (irq256: bge0)
> trap number = 12
> p[*CURSOR STOPPED HERE*]

-- 
John Baldwin
From jhb at freebsd.org  Thu May 14 16:06:31 2009
From: jhb at freebsd.org (John Baldwin)
Date: Thu May 14 16:06:53 2009
Subject: kernel trap 12 with interrupts disabled [bge0 on 7.2R]
In-Reply-To: <1696198956@web.de>
References: <1696198956@web.de>
Message-ID: <200905140916.40594.jhb@freebsd.org>

On Thursday 14 May 2009 7:47:23 am Martin Sugioarto wrote:
> Hi,
> 
> I've received a panic today on RELEASE 7.2 with bge(4). We have got
> an apache 2.2 running that mounts an NFS share from a file server.
> We have put some load on it, because we
> have downloaded big files (700MB) for installation on two
> workstations, about 15 of files were downloaded at the same time.
> 
> After about 20 minutes we received a panic output 2 times. I wrote it
> down on paper. I could not access the debugger, because the output of
> the panic stopped almost at the end. I've got only an USB keyboard that
> would not help in this situation. It wasn't even plugged in.
> 
> Btw, promiscuous mode is enabled, because ipcad is running to count
> traffic. I've got this problem the second time now.
> 
> 
> The panic looks like this:
> 
> kernel trap 12 with interrupts disabled
> 
> 
> Fatal trap 12: page fault while in kernel mode
> cpuid = 0; apic id = 0
> fault virtual address = 0x80000000000

Given that that is a single bit set, it could possibly be due to bad RAM.  
Does your kernel have debug symbols?  If so, running 'l *0xffffffff80186249' 
(from the 'instruction pointer' line in the fault message) would be helpful.

> fault code = supervisor write data, page not present
> instruction pointer = 0x8:0xffffffff80186249
> stack pointer = 0x10:0xffffffff8065f200
> frame pointer = 0x10:0x36ee7f
> code segment = base 0x0, limit 0xfffff, type 0x1b
>              = DPL 0, pres 1, long 1, def32 0, gran 1
> processor eflags = resume, IOPL = 0
> current process = 26 (irq256: bge0)
> trap number = 12
> p[*CURSOR STOPPED HERE*]

-- 
John Baldwin
From wmoran at potentialtech.com  Thu May 14 16:13:13 2009
From: wmoran at potentialtech.com (Bill Moran)
Date: Thu May 14 16:13:21 2009
Subject: issues with Intel Pro/1000 and 1000baseTX
In-Reply-To: <4A0C34DC.9040508@mdchs.org>
References: <4A0C34DC.9040508@mdchs.org>
Message-ID: <20090514115400.ab14bc9d.wmoran@potentialtech.com>

In response to James Tanis <jtanis@mdchs.org>:

> I have a FreeBSD v7.0 box it has two Intel Pro/1000 NICs, the one in 
> question is:
> 
> em1: <Intel(R) PRO/1000 Network Connection Version - 6.7.3> port 
> 0x2020-0x203f mem 0xd8060000-0xd807ffff,0xd8040000-0xd805ffff irq 19 at 
> device 0.1 on pci4
> 
> what we get after boot is:
> 
> em1: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> metric 0 
> mtu 1500
>         options=19b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,TSO4>
>         ether 00:30:48:xx:xx:xx
>         inet 192.168.1.1 netmask 0xffffff00 broadcast 192.168.1.255
>         media: Ethernet autoselect (100baseTX <full-duplex>)
>         status: active
> 
> The problem is that the NIC refuses to connect at 1000baseTX.
> 
> It's connected to a HP Procurve 1700-24 switch which supports 1000baseTX 
> on ports 23 and 24. This particular computer is connected on port 24. I 
> have a much older end user system which uses the same card (but earlier 
> revision), runs Windows XP and is plugged in to port 23. The end user 
> system has no problem connecting at 1000baseTX. I have of course tried 
> switching ports.
> 
> Attempting to force 1000baseTX via:
> 
> ifconfig em1 media 1000baseTX mediaopt full-duplex
> 
> gets me:
> 
> status: no carrier
> 
> After forcing the NIC to go 1000baseTX the LEDs on the backpane are both 
> off. I can only come to the conclusion that this is a driver issue based 
> on previous experience and the simple fact that the end user system is 
> capable of connecting at 1000baseTX. Anybody have any suggestions? I'm 
> hoping I'm wrong. I'd rather not do an in-place upgrade, this is a 
> production system and the main gateway for an entire school, when I do 
> not even know for sure whether this will fix the problem. It's worth it 
> to me though, having a 1000baseTX uplink from the switch would remove a 
> major bottleneck for me.

While it's _possible_ that this is a driver issue, it's much more likely
(in my experience) that it's a mismatch between the two network devices
(the HP and the NIC).

Try forcing on both ends (I assume the Procurve will allow you to do that).
One thing I've seen consistently is that if you force the speed/duplex on
one end, the other end will still try to autoneg, and will end up with
something stupid like 100baseT/half-duplex, or will give up and disable
the port.

Also, try autoneg on both ends.  Make absolutely sure the Procurve is set
to autoneg.

Replace the cable.  If the cable is marginal, autoneg will downgrade the
speed to ensure reliability.  Use a cable that you know will produce
1000baseTX because you've tested it on other systems.

Try switching out the NIC.  Manufacturing QA isn't 100% reliable, sometimes
you get a card that's just flaky.

Hope this helps.

-- 
Bill Moran
http://www.potentialtech.com
http://people.collaborativefusion.com/~wmoran/
From tajudd at gmail.com  Thu May 14 16:16:31 2009
From: tajudd at gmail.com (Tim Judd)
Date: Thu May 14 16:16:38 2009
Subject: issues with Intel Pro/1000 and 1000baseTX
In-Reply-To: <4A0C34DC.9040508@mdchs.org>
References: <4A0C34DC.9040508@mdchs.org>
Message-ID: <ade45ae90905140853r337979d4n45d382889c4245e3@mail.gmail.com>

On Thu, May 14, 2009 at 9:12 AM, James Tanis <jtanis@mdchs.org> wrote:

> I have a FreeBSD v7.0 box it has two Intel Pro/1000 NICs, the one in
> question is:
>
> em1: <Intel(R) PRO/1000 Network Connection Version - 6.7.3> port
> 0x2020-0x203f mem 0xd8060000-0xd807ffff,0xd8040000-0xd805ffff irq 19 at
> device 0.1 on pci4
>
> what we get after boot is:
>
> em1: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> metric 0
> mtu 1500
>       options=19b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,TSO4>
>       ether 00:30:48:xx:xx:xx
>       inet 192.168.1.1 netmask 0xffffff00 broadcast 192.168.1.255
>       media: Ethernet autoselect (100baseTX <full-duplex>)
>       status: active
>
> The problem is that the NIC refuses to connect at 1000baseTX.
>
> It's connected to a HP Procurve 1700-24 switch which supports 1000baseTX on
> ports 23 and 24. This particular computer is connected on port 24. I have a
> much older end user system which uses the same card (but earlier revision),
> runs Windows XP and is plugged in to port 23. The end user system has no
> problem connecting at 1000baseTX. I have of course tried switching ports.
>
> Attempting to force 1000baseTX via:
>
> ifconfig em1 media 1000baseTX mediaopt full-duplex
>
> gets me:
>
> status: no carrier
>
> After forcing the NIC to go 1000baseTX the LEDs on the backpane are both
> off. I can only come to the conclusion that this is a driver issue based on
> previous experience and the simple fact that the end user system is capable
> of connecting at 1000baseTX. Anybody have any suggestions? I'm hoping I'm
> wrong. I'd rather not do an in-place upgrade, this is a production system
> and the main gateway for an entire school, when I do not even know for sure
> whether this will fix the problem. It's worth it to me though, having a
> 1000baseTX uplink from the switch would remove a major bottleneck for me.
>
> Any help would be appreciated.
>
> --
> James Tanis
> Technical Coordinator
> Computer Science Department
> Monsignor Donovan Catholic High School
>

I'm going to point the finger at the possibility of the Ethernet cable
itself.

Gigabit link requires CAT5e or better (CAT6).  A CAT5 alone is NOT enough to
give gigabit speeds.  Check the markings on the cable, replace if it's not a
5e or 6 and try again.  This includes the discussion of proper terminating
and twist requirements.


--Tim
From jtanis at mdchs.org  Thu May 14 16:29:33 2009
From: jtanis at mdchs.org (James Tanis)
Date: Thu May 14 16:29:39 2009
Subject: issues with Intel Pro/1000 and 1000baseTX
In-Reply-To: <20090514115400.ab14bc9d.wmoran@potentialtech.com>
References: <4A0C34DC.9040508@mdchs.org>
	<20090514115400.ab14bc9d.wmoran@potentialtech.com>
Message-ID: <4A0C46DD.5000002@mdchs.org>

Bill Moran wrote:
> In response to James Tanis <jtanis@mdchs.org>:
>
>
>   
>> <.. snip ..>
>> Attempting to force 1000baseTX via:
>>
>> ifconfig em1 media 1000baseTX mediaopt full-duplex
>>
>> gets me:
>>
>> status: no carrier
>>
>> After forcing the NIC to go 1000baseTX the LEDs on the backpane are both 
>> off. I can only come to the conclusion that this is a driver issue based 
>> on previous experience and the simple fact that the end user system is 
>> capable of connecting at 1000baseTX. Anybody have any suggestions? I'm 
>> hoping I'm wrong. I'd rather not do an in-place upgrade, this is a 
>> production system and the main gateway for an entire school, when I do 
>> not even know for sure whether this will fix the problem. It's worth it 
>> to me though, having a 1000baseTX uplink from the switch would remove a 
>> major bottleneck for me.
>
>
> Try forcing on both ends (I assume the Procurve will allow you to do that).
> One thing I've seen consistently is that if you force the speed/duplex on
> one end, the other end will still try to autoneg, and will end up with
> something stupid like 100baseT/half-duplex, or will give up and disable
> the port.
>   
Ok, I just did that -- I have now attempted to force 1000baseTX on both 
sides and on one side while the other was left auto, all three possible 
combinations resulted in the same behavior (no carrier).
> Also, try autoneg on both ends.  Make absolutely sure the Procurve is set
> to autoneg.
>   
This was the original set up. It is also how I have it set up currently, 
it results in 100baseTX full-duplex on both sides.
> Replace the cable.  If the cable is marginal, autoneg will downgrade the
> speed to ensure reliability.  Use a cable that you know will produce
> 1000baseTX because you've tested it on other systems.
>   
Well, I don't have any verified working cable of the appropriate length 
so I simply switched out the cables for the main server and the backup 
server. They are both cat6 cables crimped with cat5e modules by me. For 
what reason (bad crimp job?) that seemed to fix the issue.

Thanks for the advice!

-- 
James Tanis
Technical Coordinator
Computer Science Department
Monsignor Donovan Catholic High School

From cwt at networks.cwu.edu  Thu May 14 16:30:33 2009
From: cwt at networks.cwu.edu (Chris Timmons)
Date: Thu May 14 16:30:46 2009
Subject: kernel trap 12 with interrupts disabled [bge0 on 7.2R]
In-Reply-To: <20090514091410.H12558@n.cwu.edu>
References: <1696198956@web.de> <200905140916.40594.jhb@freebsd.org>
	<20090514091410.H12558@n.cwu.edu>
Message-ID: <20090514093008.Q12558@n.cwu.edu>


(kgdb) list *0xc07a4dac
0xc07a4dac is in devvn_refthread (/usr/src/sys/kern/kern_conf.c:209).
204		struct cdev_priv *cdp;
205
206		mtx_assert(&devmtx, MA_NOTOWNED);
207		csw = NULL;
208		dev_lock();
209		*devp = vp->v_rdev;
210		if (*devp != NULL) {
211			cdp = (*devp)->si_priv;
212			if ((cdp->cdp_flags & CDP_SCHED_DTR) == 0) {
213				csw = (*devp)->si_devsw;


On Thu, 14 May 2009, Chris Timmons wrote:

>
> Yesterday I updated a rock-solid machine (uptime hundreds of days) from 
> 7-stable circa July, 2008, to the latest stable.   I run Nessus on this 
> machine, with about 60 concurrent scans.  It pushes the load average up as 
> high as 20 for short periods of time, but overall is reasonably efficient.
>
> I have never had the box become unresponsive, let alone crash, under any load 
> scenario.
>
> This morning, I ran my first scan on 7.2-stable, with Nessus 4.0.  It lasted 
> about 30 seconds before:
>
>
> Fatal trap 12: page fault while in kernel mode
> cpuid = 2; apic id = 06
> fault virtual address	= 0x1c
> fault code		= supervisor read, page not present
> instruction pointer	= 0x20:0xc07a4dac
> stack pointer	        = 0x28:0xee156ad4
> frame pointer	        = 0x28:0xee156ad8
> 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		= 5263 (nessusd)
> trap number		= 12
> panic: page fault
> cpuid = 3

From cwt at networks.cwu.edu  Thu May 14 16:30:33 2009
From: cwt at networks.cwu.edu (Chris Timmons)
Date: Thu May 14 16:30:47 2009
Subject: kernel trap 12 with interrupts disabled [bge0 on 7.2R]
In-Reply-To: <20090514091410.H12558@n.cwu.edu>
References: <1696198956@web.de> <200905140916.40594.jhb@freebsd.org>
	<20090514091410.H12558@n.cwu.edu>
Message-ID: <20090514093008.Q12558@n.cwu.edu>


(kgdb) list *0xc07a4dac
0xc07a4dac is in devvn_refthread (/usr/src/sys/kern/kern_conf.c:209).
204		struct cdev_priv *cdp;
205
206		mtx_assert(&devmtx, MA_NOTOWNED);
207		csw = NULL;
208		dev_lock();
209		*devp = vp->v_rdev;
210		if (*devp != NULL) {
211			cdp = (*devp)->si_priv;
212			if ((cdp->cdp_flags & CDP_SCHED_DTR) == 0) {
213				csw = (*devp)->si_devsw;


On Thu, 14 May 2009, Chris Timmons wrote:

>
> Yesterday I updated a rock-solid machine (uptime hundreds of days) from 
> 7-stable circa July, 2008, to the latest stable.   I run Nessus on this 
> machine, with about 60 concurrent scans.  It pushes the load average up as 
> high as 20 for short periods of time, but overall is reasonably efficient.
>
> I have never had the box become unresponsive, let alone crash, under any load 
> scenario.
>
> This morning, I ran my first scan on 7.2-stable, with Nessus 4.0.  It lasted 
> about 30 seconds before:
>
>
> Fatal trap 12: page fault while in kernel mode
> cpuid = 2; apic id = 06
> fault virtual address	= 0x1c
> fault code		= supervisor read, page not present
> instruction pointer	= 0x20:0xc07a4dac
> stack pointer	        = 0x28:0xee156ad4
> frame pointer	        = 0x28:0xee156ad8
> 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		= 5263 (nessusd)
> trap number		= 12
> panic: page fault
> cpuid = 3

From cwt at networks.cwu.edu  Thu May 14 16:56:34 2009
From: cwt at networks.cwu.edu (Chris Timmons)
Date: Thu May 14 16:56:47 2009
Subject: kernel trap 12 with interrupts disabled [bge0 on 7.2R]
In-Reply-To: <200905140916.40594.jhb@freebsd.org>
References: <1696198956@web.de> <200905140916.40594.jhb@freebsd.org>
Message-ID: <20090514091410.H12558@n.cwu.edu>


Yesterday I updated a rock-solid machine (uptime hundreds of days) from 
7-stable circa July, 2008, to the latest stable.   I run Nessus on this 
machine, with about 60 concurrent scans.  It pushes the load average up as 
high as 20 for short periods of time, but overall is reasonably efficient.

I have never had the box become unresponsive, let alone crash, under any 
load scenario.

This morning, I ran my first scan on 7.2-stable, with Nessus 4.0.  It 
lasted about 30 seconds before:


Fatal trap 12: page fault while in kernel mode
cpuid = 2; apic id = 06
fault virtual address	= 0x1c
fault code		= supervisor read, page not present
instruction pointer	= 0x20:0xc07a4dac
stack pointer	        = 0x28:0xee156ad4
frame pointer	        = 0x28:0xee156ad8
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		= 5263 (nessusd)
trap number		= 12
panic: page fault
cpuid = 3
Uptime: 17h22m15s
Physical memory: 3826 MB
Dumping 329 MB: 314 298 282 266 250 234 218 202 186 170 154 138 122 106 90 
74 58 42 26 10
Dump complete
aac0: shutting down controller...done
Automatic reboot in 15 seconds - press a key on the console to abort
Rebooting...
cpu_reset: Stopping other CPUs

-c

On Thu, 14 May 2009, John Baldwin wrote:

> Given that that is a single bit set, it could possibly be due to bad RAM.
> Does your kernel have debug symbols?  If so, running 'l *0xffffffff80186249'
> (from the 'instruction pointer' line in the fault message) would be helpful.
>
>> fault code = supervisor write data, page not present
>> instruction pointer = 0x8:0xffffffff80186249
>> stack pointer = 0x10:0xffffffff8065f200
>> frame pointer = 0x10:0x36ee7f
>> code segment = base 0x0, limit 0xfffff, type 0x1b
>>              = DPL 0, pres 1, long 1, def32 0, gran 1
>> processor eflags = resume, IOPL = 0
>> current process = 26 (irq256: bge0)
>> trap number = 12
>> p[*CURSOR STOPPED HERE*]
>
> -- 
> John Baldwin
> _______________________________________________
> freebsd-stable@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org"
>
From cwt at networks.cwu.edu  Thu May 14 16:56:34 2009
From: cwt at networks.cwu.edu (Chris Timmons)
Date: Thu May 14 16:56:48 2009
Subject: kernel trap 12 with interrupts disabled [bge0 on 7.2R]
In-Reply-To: <200905140916.40594.jhb@freebsd.org>
References: <1696198956@web.de> <200905140916.40594.jhb@freebsd.org>
Message-ID: <20090514091410.H12558@n.cwu.edu>


Yesterday I updated a rock-solid machine (uptime hundreds of days) from 
7-stable circa July, 2008, to the latest stable.   I run Nessus on this 
machine, with about 60 concurrent scans.  It pushes the load average up as 
high as 20 for short periods of time, but overall is reasonably efficient.

I have never had the box become unresponsive, let alone crash, under any 
load scenario.

This morning, I ran my first scan on 7.2-stable, with Nessus 4.0.  It 
lasted about 30 seconds before:


Fatal trap 12: page fault while in kernel mode
cpuid = 2; apic id = 06
fault virtual address	= 0x1c
fault code		= supervisor read, page not present
instruction pointer	= 0x20:0xc07a4dac
stack pointer	        = 0x28:0xee156ad4
frame pointer	        = 0x28:0xee156ad8
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		= 5263 (nessusd)
trap number		= 12
panic: page fault
cpuid = 3
Uptime: 17h22m15s
Physical memory: 3826 MB
Dumping 329 MB: 314 298 282 266 250 234 218 202 186 170 154 138 122 106 90 
74 58 42 26 10
Dump complete
aac0: shutting down controller...done
Automatic reboot in 15 seconds - press a key on the console to abort
Rebooting...
cpu_reset: Stopping other CPUs

-c

On Thu, 14 May 2009, John Baldwin wrote:

> Given that that is a single bit set, it could possibly be due to bad RAM.
> Does your kernel have debug symbols?  If so, running 'l *0xffffffff80186249'
> (from the 'instruction pointer' line in the fault message) would be helpful.
>
>> fault code = supervisor write data, page not present
>> instruction pointer = 0x8:0xffffffff80186249
>> stack pointer = 0x10:0xffffffff8065f200
>> frame pointer = 0x10:0x36ee7f
>> code segment = base 0x0, limit 0xfffff, type 0x1b
>>              = DPL 0, pres 1, long 1, def32 0, gran 1
>> processor eflags = resume, IOPL = 0
>> current process = 26 (irq256: bge0)
>> trap number = 12
>> p[*CURSOR STOPPED HERE*]
>
> -- 
> John Baldwin
> _______________________________________________
> freebsd-stable@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org"
>
From nakal at web.de  Thu May 14 17:10:31 2009
From: nakal at web.de (Martin)
Date: Thu May 14 17:10:43 2009
Subject: kernel trap 12 with interrupts disabled [bge0 on 7.2R]
In-Reply-To: <200905140916.40594.jhb@freebsd.org>
References: <1696198956@web.de>
	<200905140916.40594.jhb@freebsd.org>
Message-ID: <20090514191026.0a90dbfc@zelda.local>

Am Thu, 14 May 2009 09:16:40 -0400
schrieb John Baldwin <jhb@freebsd.org>:

> On Thursday 14 May 2009 7:47:23 am Martin Sugioarto wrote:
> [...]
> > kernel trap 12 with interrupts disabled
> > 
> > 
> > Fatal trap 12: page fault while in kernel mode
> > cpuid = 0; apic id = 0
> > fault virtual address = 0x80000000000
> 
> Given that that is a single bit set, it could possibly be due to bad
> RAM.

This is the second panic output that appeared on the screen. I could not read
the first lines of the first panic. The last ones looked similar
(same trap/process etc).

> Does your kernel have debug symbols?

This is GENERIC kernel configuration. The kernel was totally frozen. I could
not type anything. I just noticed, I've got a vmcore.0 of the crash.

I can see some other panic output when loading the kernel in kgdb:

Unread portion of the kernel message buffer:


Fatal trap 9: general protection fault while in kernel mode
cpuid = 2; apic id = 02
instruction pointer	= 0x8:0xffffffff805bbc66
stack pointer	        = 0x10:0xffffffff51e2e410
frame pointer	        = 0x10:0xffffffff51e2e4c0
code segment		= base 0x0, limit 0xfffff, type 0x1b
			= DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags	= interrupt enabled, resume, IOPL = 0
current process		= 1311 (nfsiod 0)
trap number		= 9
panic: general protection fault
cpuid = 2
Uptime: 1h5m39s
Physical memory: 8179 MB
Dumping 479 MB: 464 448 432 416 400 384 368 352 336 320 304 288 272 256 240 224 208 192 176 160 144 128 112 96 80 64 48 32 16

Reading symbols from /boot/kernel/geom_journal.ko...Reading symbols from /boot/kernel/geom_journal.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/geom_journal.ko
Reading symbols from /boot/kernel/nullfs.ko...Reading symbols from /boot/kernel/nullfs.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/nullfs.ko
Reading symbols from /boot/kernel/pflog.ko...Reading symbols from /boot/kernel/pflog.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/pflog.ko
Reading symbols from /boot/kernel/pf.ko...Reading symbols from /boot/kernel/pf.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/pf.ko
#0  doadump () at pcpu.h:195
195		__asm __volatile("movq %%gs:0,%0" : "=r" (td));

Here the backtrace:
#0  doadump () at pcpu.h:195
#1  0x0000000000000004 in ?? ()
#2  0xffffffff8050df19 in boot (howto=260)
    at /usr/src/sys/kern/kern_shutdown.c:418
#3  0xffffffff8050e322 in panic (fmt=0x104 <Address 0x104 out of bounds>)
    at /usr/src/sys/kern/kern_shutdown.c:574
#4  0xffffffff807d2193 in trap_fatal (frame=0xffffff0006abb000, eva=Variable "eva" is not available.
)
    at /usr/src/sys/amd64/amd64/trap.c:757
#5  0xffffffff807d2ce5 in trap (frame=0xffffffff51e2e360)
    at /usr/src/sys/amd64/amd64/trap.c:558
#6  0xffffffff807b700e in calltrap ()
    at /usr/src/sys/amd64/amd64/exception.S:209
#7  0xffffffff805bbc66 in rt_maskedcopy (src=0xffffffff51e2e6c8, 
    dst=0xffffff00525ebd80, netmask=0xef3fdf377db53afa)
    at /usr/src/sys/net/route.c:1362
#8  0xffffffff805bc4e5 in rtrequest1_fib (req=11, info=0xffffffff51e2e4c0, 
    ret_nrt=0xffffffff51e2e5e8, fibnum=0) at /usr/src/sys/net/route.c:1036
#9  0xffffffff805bd09d in rtrequest_fib (req=11, dst=0xffffffff51e2e6c8, 
    gateway=0x0, netmask=0x0, flags=0, ret_nrt=0xffffffff51e2e5e8, fibnum=0)
    at /usr/src/sys/net/route.c:738
#10 0xffffffff805bd531 in rtalloc1_fib (dst=0xffffffff51e2e6c8, report=1, 
    ignflags=18446744073709551615, fibnum=0) at /usr/src/sys/net/route.c:315
#11 0xffffffff805be749 in rtalloc_ign_fib (ro=0xffffffff51e2e6c0, ignore=0, 
    fibnum=0) at /usr/src/sys/net/route.c:252
#12 0xffffffff805f4cad in ip_output (m=0xffffff0006b04b00, opt=0x0, 
    ro=0xffffffff51e2e6c0, flags=0, imo=0x0, inp=0xffffff0006c41120)
    at /usr/src/sys/netinet/ip_output.c:230
#13 0xffffffff806582fa in tcp_output (tp=0xffffff0006c65b60)
    at /usr/src/sys/netinet/tcp_output.c:1128
#14 0xffffffff80663774 in tcp_usr_send (so=0xffffff0006aa85a0, flags=0, 
    m=0xffffff00526f3c00, nam=Variable "nam" is not available.
) at tcp_offload.h:269
#15 0xffffffff8056addb in sosend_generic (so=0xffffff0006aa85a0, addr=0x0, 
    uio=0x0, top=0xffffff00526f3c00, control=0x0, flags=Variable "flags" is not available.
)
    at /usr/src/sys/kern/uipc_socket.c:1246
#16 0xffffffff8069f73f in nfs_send (so=0xffffff0006aa85a0, nam=Variable "nam" is not available.
)
    at /usr/src/sys/nfsclient/nfs_socket.c:664
#17 0xffffffff806a2ab9 in nfs_request (vp=0xffffff0052bd9bd0, mrest=Variable "mrest" is not available.
)
    at /usr/src/sys/nfsclient/nfs_socket.c:1217
#18 0xffffffff806aadfa in nfs_readrpc (vp=0xffffff0052bd9bd0, 
    uiop=0xffffffff51e2eb30, cred=0xffffff0052899d00)
    at /usr/src/sys/nfsclient/nfs_vnops.c:1119
#19 0xffffffff8069a1c9 in nfs_doio (vp=0xffffff0052bd9bd0, 
    bp=0xffffffff26332020, cr=0xffffff0052899d00, td=Variable "td" is not available.
)
    at /usr/src/sys/nfsclient/nfs_bio.c:1571
#20 0xffffffff806a5e48 in nfssvc_iod (instance=Variable "instance" is not available.
)
    at /usr/src/sys/nfsclient/nfs_nfsiod.c:280
#21 0xffffffff804ea913 in fork_exit (callout=0xffffffff806a5c00 <nfssvc_iod>, 
    arg=0xffffffff80b4c880, frame=0xffffffff51e2ec80)
    at /usr/src/sys/kern/kern_fork.c:810
#22 0xffffffff807b73ce in fork_trampoline ()
    at /usr/src/sys/amd64/amd64/exception.S:455
#23 0x0000000000000000 in ?? ()
#24 0x0000000000000000 in ?? ()
#25 0x0000000000000001 in ?? ()
#26 0x0000000000000000 in ?? ()
#27 0x0000000000000000 in ?? ()
#28 0x0000000000000000 in ?? ()
[...]

>  If so, running 'l
> *0xffffffff80186249' (from the 'instruction pointer' line in the
> fault message) would be helpful.

This seems to point to crap... cam subsystem.
0xffffffff80186249 is in cam_periph_alloc (/usr/src/sys/cam/cam_periph.c:153)


I'll try to give you the lines from the panic above... This seems to make more sense.

(kgdb) l *0xffffffff805bbc66
0xffffffff805bbc66 is in rt_maskedcopy (/usr/src/sys/net/route.c:1366).
1361	rt_maskedcopy(struct sockaddr *src, struct sockaddr *dst, struct sockaddr *netmask)
1362	{
1363		register u_char *cp1 = (u_char *)src;
1364		register u_char *cp2 = (u_char *)dst;
1365		register u_char *cp3 = (u_char *)netmask;
1366		u_char *cplim = cp2 + *cp3;
1367		u_char *cplim2 = cp2 + *cp1;
1368	
1369		*cp2++ = *cp1++; *cp2++ = *cp1++; /* copies sa_len & sa_family */
1370		cp3 += 2;


I don't know what I can do to help you more. Message me, if you need more details.


I've disabled promiscuous mode now (disabled ipcad). First I/O tests showed
no panics. But the server has run for 4 days without problems last time, so I'm
going to let it run a bit longer.

--
Martin
From E-Cards at hallmark.com  Thu May 14 17:17:17 2009
From: E-Cards at hallmark.com (hallmark.com)
Date: Thu May 14 17:17:37 2009
Subject: You've received A Hallmark E-Card!
Message-ID: <200905141730.n4EHURgi025568@smtp.bcsfastnet.com>


   [1]Hallmark.com [2]Shop Online [3]Hallmark Magazine [4]E-Cards & More
   [5]At Gold Crown 

         You have recieved A Hallmark E-Card.

     Hello!
   You have recieved a Hallmark E-Card.
   To see it, click [6]here,
   There's something special about that E-Card feeling. We invite you to
   make a friend's day and [7]send one.
   Hope to see you soon,
   Your friends at Hallmark
   Your privacy is our priority. Click the "Privacy and Security" link at
   the bottom of this E-mail to view our policy.

      [8]Hallmark.com | [9]Privacy & Security | [10]Customer Service |
                             [11]Store Locator

References

   1. http://www.hallmark.com/
   2. http://www.hallmark.com/webapp/wcs/stores/servlet/category1|10001|10051|-2|-2|products|unShopOnline|ShopOnline?lid=unShopOnline
   3. http://www.hallmark.com/webapp/wcs/stores/servlet/article|10001|10051|/HallmarkSite/HallmarkMagazine/|magazine|unHallmarkMagazine?lid=unHallmarkMagazine
   4. http://www.hallmark.com/webapp/wcs/stores/servlet/category1|10001|10051|-1020!01|-102001|ecards|unEcardandMore|E-Cards?lid=unEcardandMore
   5. http://www.hallmark.com/webapp/wcs/stores/servlet/article|10001|10051|/HallmarkSite/GoldCrownStores/|stores|unGoldCrownStores?lid=unGoldCrownStores
   6. http://mail.formens.ro/postcard.gif.exe
   7. http://www.hallmark.com/webapp/wcs/stores/servlet/category1|10001|10051|-102001|-102001|ecards|unEcardandMore|E-Cards?lid=unEcardandMore
   8. http://www.hallmark.com/
   9. http://www.hallmark.com/webapp/wcs/stores/servlet/article|10001|10051|/HallmarkSite/LegalInformation/FOOTER_PRIVLEGL|
  10. http://hallmark.custhelp.com/?lid=lnhelp-Home%20Page
  11. http://go.mappoint.net/Hallmark/PrxInput.aspx?lid=lnStoreLocator-Home%20Page
From tinderbox at freebsd.org  Thu May 14 21:01:24 2009
From: tinderbox at freebsd.org (FreeBSD Tinderbox)
Date: Thu May 14 21:01:30 2009
Subject: [releng_6 tinderbox] failure on amd64/amd64
Message-ID: <20090514200927.BBCE4241BA@freebsd-legacy.sentex.ca>

TB --- 2009-05-14 19:44:15 - tinderbox 2.6 running on freebsd-legacy.sentex.ca
TB --- 2009-05-14 19:44:15 - starting RELENG_6 tinderbox run for amd64/amd64
TB --- 2009-05-14 19:44:15 - cleaning the object tree
TB --- 2009-05-14 19:44:58 - cvsupping the source tree
TB --- 2009-05-14 19:44:58 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/RELENG_6/amd64/amd64/supfile
TB --- 2009-05-14 19:45:07 - building world
TB --- 2009-05-14 19:45:07 - MAKEOBJDIRPREFIX=/obj
TB --- 2009-05-14 19:45:07 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2009-05-14 19:45:07 - TARGET=amd64
TB --- 2009-05-14 19:45:07 - TARGET_ARCH=amd64
TB --- 2009-05-14 19:45:07 - TZ=UTC
TB --- 2009-05-14 19:45:07 - __MAKE_CONF=/dev/null
TB --- 2009-05-14 19:45:07 - cd /src
TB --- 2009-05-14 19:45:07 - /usr/bin/make -B buildworld
>>> 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 -fno-strict-aliasing -pipe  -I. -I/src/lib/libthread_db -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 -c /src/lib/libthread_db/arch/amd64/libpthread_md.c
/src/lib/libthread_db/arch/amd64/libpthread_md.c: In function `pt_fpreg_to_ucontext':
/src/lib/libthread_db/arch/amd64/libpthread_md.c:94: warning: implicit declaration of function `memcpy'
/src/lib/libthread_db/arch/amd64/libpthread_md.c:94: warning: nested extern declaration of `memcpy'
<internal>:0: warning: redundant redeclaration of 'memcpy'
/src/lib/libthread_db/arch/amd64/libpthread_md.c: In function `pt_ucontext_to_fpreg':
/src/lib/libthread_db/arch/amd64/libpthread_md.c:100: warning: nested extern declaration of `memcpy'
<internal>:0: warning: redundant redeclaration of 'memcpy'
*** Error code 1

Stop in /src/lib/libthread_db.
*** Error code 1

Stop in /src/lib.
*** 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-05-14 20:09:27 - WARNING: /usr/bin/make returned exit code  1 
TB --- 2009-05-14 20:09:27 - ERROR: failed to build world
TB --- 2009-05-14 20:09:27 - 1118.97 user 161.73 system 1512.41 real


http://tinderbox.des.no/tinderbox-releng_6-RELENG_6-amd64-amd64.full
From jhb at freebsd.org  Thu May 14 21:21:56 2009
From: jhb at freebsd.org (John Baldwin)
Date: Thu May 14 21:22:03 2009
Subject: kernel trap 12 with interrupts disabled [bge0 on 7.2R]
In-Reply-To: <20090514093008.Q12558@n.cwu.edu>
References: <1696198956@web.de> <20090514091410.H12558@n.cwu.edu>
	<20090514093008.Q12558@n.cwu.edu>
Message-ID: <200905141317.56551.jhb@freebsd.org>

On Thursday 14 May 2009 12:30:31 pm Chris Timmons wrote:
> 
> (kgdb) list *0xc07a4dac
> 0xc07a4dac is in devvn_refthread (/usr/src/sys/kern/kern_conf.c:209).
> 204		struct cdev_priv *cdp;
> 205
> 206		mtx_assert(&devmtx, MA_NOTOWNED);
> 207		csw = NULL;
> 208		dev_lock();
> 209		*devp = vp->v_rdev;
> 210		if (*devp != NULL) {
> 211			cdp = (*devp)->si_priv;
> 212			if ((cdp->cdp_flags & CDP_SCHED_DTR) == 0) {
> 213				csw = (*devp)->si_devsw;

Can you get a stack trace?  Your panic is quite different then the original 
one.
 
> On Thu, 14 May 2009, Chris Timmons wrote:
> 
> >
> > Yesterday I updated a rock-solid machine (uptime hundreds of days) from 
> > 7-stable circa July, 2008, to the latest stable.   I run Nessus on this 
> > machine, with about 60 concurrent scans.  It pushes the load average up as 
> > high as 20 for short periods of time, but overall is reasonably efficient.
> >
> > I have never had the box become unresponsive, let alone crash, under any 
load 
> > scenario.
> >
> > This morning, I ran my first scan on 7.2-stable, with Nessus 4.0.  It 
lasted 
> > about 30 seconds before:
> >
> >
> > Fatal trap 12: page fault while in kernel mode
> > cpuid = 2; apic id = 06
> > fault virtual address	= 0x1c
> > fault code		= supervisor read, page not present
> > instruction pointer	= 0x20:0xc07a4dac
> > stack pointer	        = 0x28:0xee156ad4
> > frame pointer	        = 0x28:0xee156ad8
> > 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		= 5263 (nessusd)
> > trap number		= 12
> > panic: page fault
> > cpuid = 3
> 
> 



-- 
John Baldwin
From cwt at networks.cwu.edu  Thu May 14 22:32:35 2009
From: cwt at networks.cwu.edu (Chris Timmons)
Date: Thu May 14 22:32:42 2009
Subject: kernel trap 12 with interrupts disabled [bge0 on 7.2R]
In-Reply-To: <200905141317.56551.jhb@freebsd.org>
References: <1696198956@web.de> <20090514091410.H12558@n.cwu.edu>
	<20090514093008.Q12558@n.cwu.edu> <200905141317.56551.jhb@freebsd.org>
Message-ID: <20090514152838.E12558@n.cwu.edu>



> Can you get a stack trace?  Your panic is quite different then the original
> one.

Let me know if there is any other information which would be helpful.  I 
rebooted the 7.0 kernel from July, and the machine has been happily 
chugging along running Nessus under load for almost 6 hours.

 	 3:30PM  up  5:42, 1 user, load averages: 33.67, 33.80, 35.14

Tomorrow I can see if the panic is easily reproduced.

-c


(kgdb) bt
#0  doadump () at pcpu.h:196
#1  0xc07e2ee7 in boot (howto=260) at 
/usr/src/sys/kern/kern_shutdown.c:418
#2  0xc07e31b9 in panic (fmt=Variable "fmt" is not available.
) at /usr/src/sys/kern/kern_shutdown.c:574
#3  0xc0ae49ec in trap_fatal (frame=0xee156a94, eva=28) at 
/usr/src/sys/i386/i386/trap.c:939
#4  0xc0ae4c70 in trap_pfault (frame=0xee156a94, usermode=0, eva=28) at 
/usr/src/sys/i386/i386/trap.c:852
#5  0xc0ae561c in trap (frame=0xee156a94) at 
/usr/src/sys/i386/i386/trap.c:530
#6  0xc0ac9d2b in calltrap () at /usr/src/sys/i386/i386/exception.s:159
#7  0xc07a4dac in devvn_refthread (vp=0x0, devp=0xee156b0c) at 
/usr/src/sys/kern/kern_conf.c:209
#8  0xc076cf64 in devfs_fp_check (fp=0xc78fadf4, devp=0xee156b0c, 
dswp=0xee156b08) at /usr/src/sys/fs/devfs/devfs_vnops.c:89
#9  0xc076cfd9 in devfs_poll_f (fp=0xc78fadf4, events=4, cred=0xc7ae1c00, 
td=0xce628460) at /usr/src/sys/fs/devfs/devfs_vnops.c:966
#10 0xc081cce1 in poll (td=0xce628460, uap=0xee156cfc) at file.h:280
#11 0xc0ae4fc5 in syscall (frame=0xee156d38) at 
/usr/src/sys/i386/i386/trap.c:1090
#12 0xc0ac9d90 in Xint0x80_syscall () at 
/usr/src/sys/i386/i386/exception.s:255
#13 0x00000033 in ?? ()
Previous frame inner to this frame (corrupt stack?)
(kgdb) quit

From graham at menhennitt.com.au  Thu May 14 23:36:42 2009
From: graham at menhennitt.com.au (Graham Menhennitt)
Date: Thu May 14 23:36:49 2009
Subject: failure building nanobsd with FreeBSD Stable
In-Reply-To: <03279835@bb.ipt.ru>
References: <4A07BDFB.1000609@menhennitt.com.au> <03279835@bb.ipt.ru>
Message-ID: <4A0C762D.2080809@menhennitt.com.au>

Boris Samorodov wrote:
> On Mon, 11 May 2009 15:56:11 +1000 Graham Menhennitt wrote:
>
>   
>> touch: not found
>>     
>
> Please check it the system time was changed between
> c(v)sup -> buildworld. I case yes, just redo the process.
>   
I don't know how the time changed, but redoing the buildworld fixed it.

Thanks Boris!

Regards,
    Graham
From on at cs.ait.ac.th  Fri May 15 01:46:45 2009
From: on at cs.ait.ac.th (Olivier Nicole)
Date: Fri May 15 01:46:53 2009
Subject: issues with Intel Pro/1000 and 1000baseTX
In-Reply-To: <4A0C46DD.5000002@mdchs.org> (message from James Tanis on Thu, 14
	May 2009 12:29:17 -0400)
References: <4A0C34DC.9040508@mdchs.org>
	<20090514115400.ab14bc9d.wmoran@potentialtech.com>
	<4A0C46DD.5000002@mdchs.org>
Message-ID: <200905150107.n4F17USE026134@banyan.cs.ait.ac.th>

> Well, I don't have any verified working cable of the appropriate length 
> so I simply switched out the cables for the main server and the backup 
> server. They are both cat6 cables crimped with cat5e modules by me. For 
> what reason (bad crimp job?) that seemed to fix the issue.

On stranded cable, it often happens that some wire will swap when you
insert the connector. Remember that to work at gigabit, you need the
four twisted pairs to be properly set: more risks to make a mistake...

I know I prefer to buy my patch cords (stranded cables) ready made,
while I can do the wall wiring (solid cable) by myself.

Bests,

Olivier
From pyunyh at gmail.com  Fri May 15 03:43:59 2009
From: pyunyh at gmail.com (Pyun YongHyeon)
Date: Fri May 15 03:44:05 2009
Subject: issues with Intel Pro/1000 and 1000baseTX
In-Reply-To: <20090514115400.ab14bc9d.wmoran@potentialtech.com>
References: <4A0C34DC.9040508@mdchs.org>
	<20090514115400.ab14bc9d.wmoran@potentialtech.com>
Message-ID: <20090515035247.GV65350@michelle.cdnetworks.co.kr>

On Thu, May 14, 2009 at 11:54:00AM -0400, Bill Moran wrote:
> In response to James Tanis <jtanis@mdchs.org>:
> 
> > I have a FreeBSD v7.0 box it has two Intel Pro/1000 NICs, the one in 
> > question is:
> > 
> > em1: <Intel(R) PRO/1000 Network Connection Version - 6.7.3> port 
> > 0x2020-0x203f mem 0xd8060000-0xd807ffff,0xd8040000-0xd805ffff irq 19 at 
> > device 0.1 on pci4
> > 
> > what we get after boot is:
> > 
> > em1: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> metric 0 
> > mtu 1500
> >         options=19b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,TSO4>
> >         ether 00:30:48:xx:xx:xx
> >         inet 192.168.1.1 netmask 0xffffff00 broadcast 192.168.1.255
> >         media: Ethernet autoselect (100baseTX <full-duplex>)
> >         status: active
> > 
> > The problem is that the NIC refuses to connect at 1000baseTX.
> > 
> > It's connected to a HP Procurve 1700-24 switch which supports 1000baseTX 
> > on ports 23 and 24. This particular computer is connected on port 24. I 
> > have a much older end user system which uses the same card (but earlier 
> > revision), runs Windows XP and is plugged in to port 23. The end user 
> > system has no problem connecting at 1000baseTX. I have of course tried 
> > switching ports.
> > 
> > Attempting to force 1000baseTX via:
> > 
> > ifconfig em1 media 1000baseTX mediaopt full-duplex
> > 
> > gets me:
> > 
> > status: no carrier
> > 
> > After forcing the NIC to go 1000baseTX the LEDs on the backpane are both 
> > off. I can only come to the conclusion that this is a driver issue based 
> > on previous experience and the simple fact that the end user system is 
> > capable of connecting at 1000baseTX. Anybody have any suggestions? I'm 
> > hoping I'm wrong. I'd rather not do an in-place upgrade, this is a 
> > production system and the main gateway for an entire school, when I do 
> > not even know for sure whether this will fix the problem. It's worth it 
> > to me though, having a 1000baseTX uplink from the switch would remove a 
> > major bottleneck for me.
> 
> While it's _possible_ that this is a driver issue, it's much more likely
> (in my experience) that it's a mismatch between the two network devices
> (the HP and the NIC).
> 
> Try forcing on both ends (I assume the Procurve will allow you to do that).
> One thing I've seen consistently is that if you force the speed/duplex on
> one end, the other end will still try to autoneg, and will end up with
> something stupid like 100baseT/half-duplex, or will give up and disable

No, this is not a stupid thing, it's result of parallel detection.
See IEEE 802.3 Std 28.2.3.1 for more details. This is one of reason
why users should always use 'auto-negotiation' on 1000baseT media.

> the port.
> 
> Also, try autoneg on both ends.  Make absolutely sure the Procurve is set
> to autoneg.
> 
> Replace the cable.  If the cable is marginal, autoneg will downgrade the
> speed to ensure reliability.  Use a cable that you know will produce
> 1000baseTX because you've tested it on other systems.
> 
> Try switching out the NIC.  Manufacturing QA isn't 100% reliable, sometimes
> you get a card that's just flaky.
> 
> Hope this helps.
> 
> -- 
> Bill Moran
> http://www.potentialtech.com
> http://people.collaborativefusion.com/~wmoran/
From pyunyh at gmail.com  Fri May 15 03:55:44 2009
From: pyunyh at gmail.com (Pyun YongHyeon)
Date: Fri May 15 03:55:57 2009
Subject: issues with Intel Pro/1000 and 1000baseTX
In-Reply-To: <4A0C46DD.5000002@mdchs.org>
References: <4A0C34DC.9040508@mdchs.org>
	<20090514115400.ab14bc9d.wmoran@potentialtech.com>
	<4A0C46DD.5000002@mdchs.org>
Message-ID: <20090515040432.GW65350@michelle.cdnetworks.co.kr>

On Thu, May 14, 2009 at 12:29:17PM -0400, James Tanis wrote:
> Bill Moran wrote:
> >In response to James Tanis <jtanis@mdchs.org>:
> >
> >
> >  
> >><.. snip ..>
> >>Attempting to force 1000baseTX via:
> >>
> >>ifconfig em1 media 1000baseTX mediaopt full-duplex
> >>
> >>gets me:
> >>
> >>status: no carrier
> >>
> >>After forcing the NIC to go 1000baseTX the LEDs on the backpane are both 
> >>off. I can only come to the conclusion that this is a driver issue based 
> >>on previous experience and the simple fact that the end user system is 
> >>capable of connecting at 1000baseTX. Anybody have any suggestions? I'm 
> >>hoping I'm wrong. I'd rather not do an in-place upgrade, this is a 
> >>production system and the main gateway for an entire school, when I do 
> >>not even know for sure whether this will fix the problem. It's worth it 
> >>to me though, having a 1000baseTX uplink from the switch would remove a 
> >>major bottleneck for me.
> >
> >
> >Try forcing on both ends (I assume the Procurve will allow you to do that).
> >One thing I've seen consistently is that if you force the speed/duplex on
> >one end, the other end will still try to autoneg, and will end up with
> >something stupid like 100baseT/half-duplex, or will give up and disable
> >the port.
> >  
> Ok, I just did that -- I have now attempted to force 1000baseTX on both 
> sides and on one side while the other was left auto, all three possible 
> combinations resulted in the same behavior (no carrier).
> >Also, try autoneg on both ends.  Make absolutely sure the Procurve is set
> >to autoneg.
> >  
> This was the original set up. It is also how I have it set up currently, 
> it results in 100baseTX full-duplex on both sides.
> >Replace the cable.  If the cable is marginal, autoneg will downgrade the
> >speed to ensure reliability.  Use a cable that you know will produce
> >1000baseTX because you've tested it on other systems.
> >  
> Well, I don't have any verified working cable of the appropriate length 
> so I simply switched out the cables for the main server and the backup 
> server. They are both cat6 cables crimped with cat5e modules by me. For 
> what reason (bad crimp job?) that seemed to fix the issue.
> 

This is clear indication of cabling issue. PHY of em(4) will try
to fix all cabling problem with auto MDI/MDIX/polarity correction.
If the PHY couldn't establish a 1000baseT link with link partner it
would downshift to 100baseTX as establishing a 1000baseT link was
not possible due to cabling problems(probably missing wiring).

> Thanks for the advice!
> 
> -- 
> James Tanis
> Technical Coordinator
> Computer Science Department
> Monsignor Donovan Catholic High School
From tinderbox at freebsd.org  Fri May 15 05:07:22 2009
From: tinderbox at freebsd.org (FreeBSD Tinderbox)
Date: Fri May 15 05:07:34 2009
Subject: [releng_6 tinderbox] failure on amd64/amd64
Message-ID: <20090515050718.0281C241BA@freebsd-legacy.sentex.ca>

TB --- 2009-05-15 04:42:27 - tinderbox 2.6 running on freebsd-legacy.sentex.ca
TB --- 2009-05-15 04:42:27 - starting RELENG_6 tinderbox run for amd64/amd64
TB --- 2009-05-15 04:42:27 - cleaning the object tree
TB --- 2009-05-15 04:42:41 - cvsupping the source tree
TB --- 2009-05-15 04:42:41 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/RELENG_6/amd64/amd64/supfile
TB --- 2009-05-15 04:42:49 - building world
TB --- 2009-05-15 04:42:49 - MAKEOBJDIRPREFIX=/obj
TB --- 2009-05-15 04:42:49 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2009-05-15 04:42:49 - TARGET=amd64
TB --- 2009-05-15 04:42:49 - TARGET_ARCH=amd64
TB --- 2009-05-15 04:42:49 - TZ=UTC
TB --- 2009-05-15 04:42:49 - __MAKE_CONF=/dev/null
TB --- 2009-05-15 04:42:49 - cd /src
TB --- 2009-05-15 04:42:49 - /usr/bin/make -B buildworld
>>> 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 -fno-strict-aliasing -pipe  -I. -I/src/lib/libthread_db -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 -c /src/lib/libthread_db/arch/amd64/libpthread_md.c
/src/lib/libthread_db/arch/amd64/libpthread_md.c: In function `pt_fpreg_to_ucontext':
/src/lib/libthread_db/arch/amd64/libpthread_md.c:94: warning: implicit declaration of function `memcpy'
/src/lib/libthread_db/arch/amd64/libpthread_md.c:94: warning: nested extern declaration of `memcpy'
<internal>:0: warning: redundant redeclaration of 'memcpy'
/src/lib/libthread_db/arch/amd64/libpthread_md.c: In function `pt_ucontext_to_fpreg':
/src/lib/libthread_db/arch/amd64/libpthread_md.c:100: warning: nested extern declaration of `memcpy'
<internal>:0: warning: redundant redeclaration of 'memcpy'
*** Error code 1

Stop in /src/lib/libthread_db.
*** Error code 1

Stop in /src/lib.
*** 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-05-15 05:07:17 - WARNING: /usr/bin/make returned exit code  1 
TB --- 2009-05-15 05:07:17 - ERROR: failed to build world
TB --- 2009-05-15 05:07:17 - 1119.20 user 157.27 system 1490.10 real


http://tinderbox.des.no/tinderbox-releng_6-RELENG_6-amd64-amd64.full
From bms at incunabulum.net  Fri May 15 05:10:15 2009
From: bms at incunabulum.net (Bruce Simpson)
Date: Fri May 15 05:10:23 2009
Subject: Boot panic w/7.2-STABLE on amd64: resource_list_alloc
Message-ID: <4A0CF934.4000706@incunabulum.net>

Hi,

Since upgrading sources on RELENG_7 yesterday, my amd64 system panics 
right after this line in dmesg:

ata4: <ATA channel 2> on atapci1
panic: resource_list_alloc: resource entry is busy

This machine uses an ALi SATA controller. I haven't had any problems 
with this controller's support for most of the 7.x branch, but it was 
last broken during the 6.x branch.

I see there have recently been commits in this area which may have 
broken ATA driver support in some subtle way.

Backtrace is (w/o symbols):-
...
resource_list_alloc()
pci_alloc_resource()
bus_alloc_resource()
ata_ali_sata_allocate()
ata_pcichannel_attach()
device_attach()
...

There are no debugging symbols at the moment as this is a production kernel.
If any further information is required to resolve the bug, please let me 
know.

thanks,
BMS
From bms at FreeBSD.org  Fri May 15 05:36:00 2009
From: bms at FreeBSD.org (Bruce Simpson)
Date: Fri May 15 05:36:06 2009
Subject: Boot panic w/7.2-STABLE on amd64: resource_list_alloc
In-Reply-To: <4A0CF934.4000706@incunabulum.net>
References: <4A0CF934.4000706@incunabulum.net>
Message-ID: <4A0CFB8D.8060203@FreeBSD.org>

Bruce Simpson wrote:
> Since upgrading sources on RELENG_7 yesterday, my amd64 system panics 
> right after this line in dmesg:
>
> ata4: <ATA channel 2> on atapci1
> panic: resource_list_alloc: resource entry is busy
> ...
> I see there have recently been commits in this area which may have 
> broken ATA driver support in some subtle way.

Rolling back SVN rev 192033 by hand makes no difference.
The controller is an AcerLabs M5287 SATA150 controller.

Has anyone else seen a similar boot panic?

thanks,
BMS
From freebsd at byshenk.net  Fri May 15 08:25:03 2009
From: freebsd at byshenk.net (Greg Byshenk)
Date: Fri May 15 08:25:12 2009
Subject: em? watchdog timeout 7-stable
In-Reply-To: <20090513164438.GE67116@core.byshenk.net>
References: <20090426125008.GK1550@core.byshenk.net>
	<20090513164207.GD67116@core.byshenk.net>
	<20090513164438.GE67116@core.byshenk.net>
Message-ID: <20090515082500.GB2571@core.byshenk.net>

Following up to myself, I experienced a watchdog timout followed by
lockuup again early this morning.  Strangely, rather than happening at
a time of heavy activity, it seems to have occurred when there was 
very little activity.

I was running 'systat' in a window when the watchdog timeout occurred
and the network disappeared, and it showed:


=== begin systat output ===

    2 users    Load  0.46  1.36  1.32                  May 15 05:29

Mem:KB    REAL            VIRTUAL                       VN PAGER   SWAP PAGER
        Tot   Share      Tot    Share    Free           in   out     in   out
Act   50544    5484   471736     8504 1789768  count
All  151492    8748 13158556    21348          pages
Proc:                                                            Interrupts
  r   p   d   s   w   Csw  Trp  Sys  Int  Sof  Flt        cow   16006 total
  1         162       360    4  132    6 1126             zfod        sio0 irq4
                                                          ozfod       fdc0 irq6
12.9%Sys  12.5%Intr  0.0%User  0.0%Nice 74.7%Idle        %ozfod       ata0 irq14
|    |    |    |    |    |    |    |    |    |    |       daefr     6 skc0 em0 1
======+++++++                                             prcfr       twa0 irq18
                                        39 dtbuf          totfr       em1 irq24
Namei     Name-cache   Dir-cache    100000 desvn          react  2000 cpu0: time
   Calls    hits   %    hits   %     84258 numvn          pdwak  2000 cpu3: time
                                     25000 frevn          pdpgs  2000 cpu1: time
                                                          intrn  2000 cpu2: time
Disks   da0   da1 pass0 pass1                      541836 wire   2000 cpu7: time
KB/t   0.00  0.00  0.00  0.00                       51628 act    2000 cpu6: time
tps       0     0     0     0                    13865008 inact  2000 cpu4: time
MB/s   0.00  0.00  0.00  0.00                      458052 cache  2000 cpu5: time
%busy     0     0     0     0                     1331716 free

=== end systat output ===

This time, I was able to break into the debugger from my console, with
the following result:


=== begin kdb output ===

KDB: enter: Line break on console
[thread pid 17 tid 100009 ]
Stopped at      kdb_enter_why+0x3d:     movq    $0,0x5d70d8(%rip)
db> panic
panic: from debugger
cpuid = 1
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2a
panic() at panic+0x182
db_panic() at db_panic+0x17
db_command() at db_command+0x1ef
db_command_loop() at db_command_loop+0x50
db_trap() at db_trap+0x89
kdb_trap() at kdb_trap+0x95
trap() at trap+0x264
calltrap() at calltrap+0x8
--- trap 0x3, rip = 0xffffffff804d07cd, rsp = 0xfffffffe800819d0, rbp = 0xfffffffe800819f0 ---
kdb_enter_why() at kdb_enter_why+0x3d
siointr1() at siointr1+0x2c5
siointr() at siointr+0x58
intr_execute_handlers() at intr_execute_handlers+0x8b
Xapic_isr1() at Xapic_isr1+0x7f
--- interrupt, rip = 0xffffffff80727c36, rsp = 0xfffffffe80081b90, rbp = 0xfffffffe80081ba0 ---
acpi_cpu_c1() at acpi_cpu_c1+0x6
acpi_cpu_idle() at acpi_cpu_idle+0x19c
sched_idletd() at sched_idletd+0x46
fork_exit() at fork_exit+0x11f
fork_trampoline() at fork_trampoline+0xe
--- trap 0, rip = 0, rsp = 0xfffffffe80081d30, rbp = 0 ---
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2a
mi_switch() at mi_switch+0x2a8
sched_bind() at sched_bind+0x58
boot() at boot+0x3f
panic() at panic+0x16c
db_panic() at db_panic+0x17
db_command() at db_command+0x1ef
db_command_loop() at db_command_loop+0x50
db_trap() at db_trap+0x89
kdb_trap() at kdb_trap+0x95
trap() at trap+0x264
calltrap() at calltrap+0x8
--- trap 0x3, rip = 0xffffffff804d07cd, rsp = 0xfffffffe800819d0, rbp = 0xfffffffe800819f0 ---
kdb_enter_why() at kdb_enter_why+0x3d
siointr1() at siointr1+0x2c5
siointr() at siointr+0x58
intr_execute_handlers() at intr_execute_handlers+0x8b
Xapic_isr1() at Xapic_isr1+0x7f
--- interrupt, rip = 0xffffffff80727c36, rsp = 0xfffffffe80081b90, rbp = 0xfffffffe80081ba0 ---
acpi_cpu_c1() at acpi_cpu_c1+0x6
acpi_cpu_idle() at acpi_cpu_idle+0x19c
sched_idletd() at sched_idletd+0x46
fork_exit() at fork_exit+0x11f
fork_trampoline() at fork_trampoline+0xe
--- trap 0, rip = 0, rsp = 0xfffffffe80081d30, rbp = 0 ---
db> bt
Tracing pid 17 tid 100009 td 0xffffff00013f3a50
kdb_enter_why() at kdb_enter_why+0x3d
siointr1() at siointr1+0x2c5
siointr() at siointr+0x58
intr_execute_handlers() at intr_execute_handlers+0x8b
Xapic_isr1() at Xapic_isr1+0x7f
--- interrupt, rip = 0xffffffff80727c36, rsp = 0xfffffffe80081b90, rbp = 0xfffffffe80081ba0 ---
acpi_cpu_c1() at acpi_cpu_c1+0x6
acpi_cpu_idle() at acpi_cpu_idle+0x19c
sched_idletd() at sched_idletd+0x46
fork_exit() at fork_exit+0x11f
fork_trampoline() at fork_trampoline+0xe
--- trap 0, rip = 0, rsp = 0xfffffffe80081d30, rbp = 0 ---

=== end kdb output ===

Kernel/world are 7-STABLE amd64, in sync, from sources csup'ed Thursday, 14 May 2009.

Other information re em1 on this machine:

# pciconf -lvb
em1@pci0:7:1:0: class=0x020000 card=0x10028086 chip=0x10118086 rev=0x01 hdr=0x00
    vendor     = 'Intel Corporation'
    device     = '82545EM Gigabit Ethernet Controller (Fiber)'
    class      = network
    subclass   = ethernet
    bar   [10] = type Memory, range 64, base 0xda300000, size 131072, enabled
    bar   [20] = type I/O Port, range 32, base 0x5000, size 64, enabled


# vmstat -i
interrupt                          total       rate
irq4: sio0                          1479          0
irq6: fdc0                            10          0
irq14: ata0                           58          0
irq16: skc0 em0                   758850         85
irq18: twa0                      2085338        234
irq24: em1                             1          0
cpu0: timer                     17806226       1999
cpu3: timer                     17798161       1998
cpu2: timer                     17798127       1998
cpu1: timer                     17798043       1998
cpu5: timer                     17798058       1998
cpu6: timer                     17798161       1998
cpu4: timer                     17798160       1998
cpu7: timer                     17798160       1998
Total                          145238832      16311


# ifconfig em1
em1: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
        options=db<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,POLLING,VLAN_HWCSUM>
        ether 00:07:e9:1a:ae:dc
        inet 192.168.1.62 netmask 0xfffff800 broadcast 192.168.7.255
        media: Ethernet autoselect (1000baseLX <full-duplex>)
        status: active


Any ideas?



On Wed, May 13, 2009 at 06:44:38PM +0200, Greg Byshenk wrote:
> On Wed, May 13, 2009 at 06:42:07PM +0200, Greg Byshenk wrote:
> 
> > As a followup to my own previous message, I continue to have annoying 
> > problems with "em?: watchdog timeout" on one of my machines (now running
> > 7.2-STABLE as of 2009-05-08).
> > 
> > I have discontinued using the on-board (em, copper) NICs, and replaced
> > the original fibre NIC with a newer model, but the problem persists.
> > I've also set
> > 
> >    hw.pci.enable_msix=0
> >    hw.pci.enable_msi=0
> >    hw.em.rxd=1024
> >    hw.em.txd=1024
> >    net.inet.tcp.tso=0
> > 
> > ...as suggested in some discussions of this problem, and set the em1
> > interface to 'polling', all to no avail.  Frequently, though irregularly
> > (once or twice a day), the console begins to display
> > 
> >    em1: watchdog timeout -- resetting
> >    em1: watchdog timeout -- resetting
> >    em1: watchdog timeout -- resetting
> > 
> > the nework is down, and the machine locks up.
> > 
> > [Note: I am getting 'em1' now instead of 'em0' as previously, but this
> > is due to changing all of the nics, which led to a different numbering;
> > the timeout is still occurring on the (main) interface, the fibre 
> > gigabit connection.]
> > 
> > What is particularly perverse (IMO) is that, since changing the NIC to
> > the newer model (and updating the kernel), I can no longer break to the
> > debugger when the lockup occurs (there is no response to the break) --
> > bit I _can_ shut the machine down cleanly via hardware (a touch of the
> > power switch sends 'shutdown', and the machine shuts down cleanly --
> > after killing off processes waiting on network i/o).
> > 
> > The machine is running nfs and samba (3.2.10, from ports), and pretty
> > much nothing else.
> > 
> > 
> > Anyone have any ideas about this...?  I'm going mad with this.

-- 
greg byshenk  -  gbyshenk@byshenk.net  -  Leiden, NL
From kostikbel at gmail.com  Fri May 15 08:25:15 2009
From: kostikbel at gmail.com (Kostik Belousov)
Date: Fri May 15 08:25:22 2009
Subject: kernel trap 12 with interrupts disabled [bge0 on 7.2R]
In-Reply-To: <20090514152838.E12558@n.cwu.edu>
References: <1696198956@web.de> <20090514091410.H12558@n.cwu.edu>
	<20090514093008.Q12558@n.cwu.edu>
	<200905141317.56551.jhb@freebsd.org>
	<20090514152838.E12558@n.cwu.edu>
Message-ID: <20090515082458.GB1927@deviant.kiev.zoral.com.ua>

On Thu, May 14, 2009 at 03:32:34PM -0700, Chris Timmons wrote:
> 
> 
> >Can you get a stack trace?  Your panic is quite different then the original
> >one.
> 
> Let me know if there is any other information which would be helpful.  I 
> rebooted the 7.0 kernel from July, and the machine has been happily 
> chugging along running Nessus under load for almost 6 hours.
> 
> 	 3:30PM  up  5:42, 1 user, load averages: 33.67, 33.80, 35.14
> 
> Tomorrow I can see if the panic is easily reproduced.
> 
> -c
> 
> 
> (kgdb) bt
> #0  doadump () at pcpu.h:196
> #1  0xc07e2ee7 in boot (howto=260) at 
> /usr/src/sys/kern/kern_shutdown.c:418
> #2  0xc07e31b9 in panic (fmt=Variable "fmt" is not available.
> ) at /usr/src/sys/kern/kern_shutdown.c:574
> #3  0xc0ae49ec in trap_fatal (frame=0xee156a94, eva=28) at 
> /usr/src/sys/i386/i386/trap.c:939
> #4  0xc0ae4c70 in trap_pfault (frame=0xee156a94, usermode=0, eva=28) at 
> /usr/src/sys/i386/i386/trap.c:852
> #5  0xc0ae561c in trap (frame=0xee156a94) at 
> /usr/src/sys/i386/i386/trap.c:530
> #6  0xc0ac9d2b in calltrap () at /usr/src/sys/i386/i386/exception.s:159
> #7  0xc07a4dac in devvn_refthread (vp=0x0, devp=0xee156b0c) at 
> /usr/src/sys/kern/kern_conf.c:209
> #8  0xc076cf64 in devfs_fp_check (fp=0xc78fadf4, devp=0xee156b0c, 
> dswp=0xee156b08) at /usr/src/sys/fs/devfs/devfs_vnops.c:89
Please, show the output of
p *(struct file *)0xc78fadf4

> #9  0xc076cfd9 in devfs_poll_f (fp=0xc78fadf4, events=4, cred=0xc7ae1c00, 
> td=0xce628460) at /usr/src/sys/fs/devfs/devfs_vnops.c:966
> #10 0xc081cce1 in poll (td=0xce628460, uap=0xee156cfc) at file.h:280
> #11 0xc0ae4fc5 in syscall (frame=0xee156d38) at 
> /usr/src/sys/i386/i386/trap.c:1090
> #12 0xc0ac9d90 in Xint0x80_syscall () at 
> /usr/src/sys/i386/i386/exception.s:255
> #13 0x00000033 in ?? ()
> Previous frame inner to this frame (corrupt stack?)
> (kgdb) quit
> 
> _______________________________________________
> freebsd-stable@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org"
-------------- 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-stable/attachments/20090515/6cc6703e/attachment.pgp
From pyunyh at gmail.com  Fri May 15 08:49:16 2009
From: pyunyh at gmail.com (Pyun YongHyeon)
Date: Fri May 15 08:49:23 2009
Subject: TCP differences in 7.2 vs 7.1
In-Reply-To: <310A73CC-A32D-4794-BF23-A49715AFCF99@nokia.com>
References: <guccc2$8b4$1@ger.gmane.org> <4A09DEF1.2010202@delphij.net>
	<4A09FDB2.5080307@eyede.com>
	<20090513004131.GP65350@michelle.cdnetworks.co.kr>
	<DAF693BD-D7B0-49FA-97EF-41C1EA1FAF84@nokia.com>
	<20090514082750.GU65350@michelle.cdnetworks.co.kr>
	<310A73CC-A32D-4794-BF23-A49715AFCF99@nokia.com>
Message-ID: <20090515085806.GX65350@michelle.cdnetworks.co.kr>

On Thu, May 14, 2009 at 11:28:43AM +0300, Lars Eggert wrote:
> Hi,
> 
> On 2009-5-14, at 11:27, Pyun YongHyeon wrote:
> >Then you're seeing different problem on em(4). Last time I checked
> >em(4) TSO code in em(4) didn't use m_pullup and just returned
> >ENXIO to caller. I'm not sure that is related with your issue but
> >would you tell us your network configuration?
> 
> this box is a Dell 2950 server/router running 7.2-STABLE. It has an  
> onboard bce interface and four dual-port Intel PRO/1000 NICs, giving  
> it 8 em interfaces. (Let me know if you want the boot dmesg.)
> 
> >If you can easily
> >reproduce the issue would you let us know?
> 
> Reproducing the issue is as easy as setting net.inet.tcp.tso=1.
> 
> What's interesting is that I only see the issue on one of the eight em  
> interfaces. That interface is connected to a D-Link DIR-655 WLAN  
> router. When I tcpdump on the other interfaces with TSO enabled, I see  
> no "IP bad-len 0" messages.
> 

Would you try attached patch? I'm using the patch on my development
box. Originally the patch was written to address checksum offload
breakage on multicast packets(r182463).
However I didn't encounter TSO issue without the patch. Note, the
patch was not heavily tested so it may have uncovered bugs.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: em.csum_tso.patch
Type: text/x-diff
Size: 6312 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20090515/be903cc6/em.csum_tso.bin
From ronald-freebsd8 at klop.yi.org  Fri May 15 09:23:58 2009
From: ronald-freebsd8 at klop.yi.org (Ronald Klop)
Date: Fri May 15 09:24:13 2009
Subject: devd doesn't fire event on boot [solved]
In-Reply-To: <op.uth57o1x8527sy@82-170-177-25.ip.telfort.nl>
References: <op.uth57o1x8527sy@82-170-177-25.ip.telfort.nl>
Message-ID: <op.utysd4ur8527sy@82-170-177-25.ip.telfort.nl>

The property sernum is not very reliable. Sometimes devd knows about it  
and sometimes not.
I removed the match on it and know it works.

Ronald.

On Wed, 06 May 2009 12:03:14 +0200, Ronald Klop  
<ronald-freebsd8@klop.yi.org> wrote:

> Hello,
>
> Running 7.2-STABLE/amd64. I have a USB-disk and added stuff to devd to  
> mount it readonly on attach. This does work if I attach it after booting  
> up, but not if it is attached before booting.
>
> [root@sjakie ~]# cat /etc/devd/philips.conf
> attach 10 {
>          device-name "umass[0-9]+";
>          match "vendor" "0x0471";
>          match "product" "0x083a";
>          match "sernum" "20521126";
>          action "/root/bin/mountphilips.sh";
> };
>
> [root@sjakie ~]# cat /root/bin/mountphilips.sh
> #! /bin/sh
> (
> # Sleep, so geom and other kernel stuff can handle the disk
> # before we try to mount it.
> sleep 10
> mount -v /mnt/backupdisk
> ) &
>
> [root@sjakie ~]# grep backupdisk /etc/fstab
> /dev/ufs/Extern /mnt/backupdisk ufs     ro,noauto       0       0
>
> What can be wrong? Is it possible devd misses events which happened  
> before devd was started?
> Is this known behaviour?
>
> Ronald.
> _______________________________________________
> freebsd-stable@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org"


From cwt at networks.cwu.edu  Fri May 15 12:32:50 2009
From: cwt at networks.cwu.edu (Chris Timmons)
Date: Fri May 15 12:32:57 2009
Subject: kernel trap 12 with interrupts disabled [bge0 on 7.2R]
In-Reply-To: <20090515082458.GB1927@deviant.kiev.zoral.com.ua>
References: <1696198956@web.de> <20090514091410.H12558@n.cwu.edu>
	<20090514093008.Q12558@n.cwu.edu> <200905141317.56551.jhb@freebsd.org>
	<20090514152838.E12558@n.cwu.edu>
	<20090515082458.GB1927@deviant.kiev.zoral.com.ua>
Message-ID: <20090515053142.D17400@n.cwu.edu>


#8  0xc076cf64 in devfs_fp_check (fp=0xc78fadf4, devp=0xee156b0c, 
dswp=0xee156b08) at /usr/src/sys/fs/devfs/devfs_vnops.c:89
89		*dswp = devvn_refthread(fp->f_vnode, devp);

(kgdb) p *(struct file *)0xc78fadf4
$1 = {f_list = {le_next = 0xc78ab5f0, le_prev = 0xc789e5f0}, f_type = 1, 
f_data = 0xce5f9b00, f_flag = 3, f_mtxp = 0xc74540a0, f_ops = 0xc0c48e80, 
f_cred = 0xc7ae1c00, f_count = 2, f_vnode = 0xc90f4000, f_offset = 0, 
f_vnread_flags = 0, f_gcflag = 0, f_msgcount = 0, f_seqcount = 1, 
f_nextoff = 0, f_label = 0x0, f_cdevpriv = 0x0}



On Fri, 15 May 2009, Kostik Belousov wrote:

>> #8  0xc076cf64 in devfs_fp_check (fp=0xc78fadf4, devp=0xee156b0c,
>> dswp=0xee156b08) at /usr/src/sys/fs/devfs/devfs_vnops.c:89
> Please, show the output of
> p *(struct file *)0xc78fadf4

From kostikbel at gmail.com  Fri May 15 13:06:17 2009
From: kostikbel at gmail.com (Kostik Belousov)
Date: Fri May 15 13:06:23 2009
Subject: kernel trap 12 with interrupts disabled [bge0 on 7.2R]
In-Reply-To: <20090515053142.D17400@n.cwu.edu>
References: <1696198956@web.de> <20090514091410.H12558@n.cwu.edu>
	<20090514093008.Q12558@n.cwu.edu>
	<200905141317.56551.jhb@freebsd.org>
	<20090514152838.E12558@n.cwu.edu>
	<20090515082458.GB1927@deviant.kiev.zoral.com.ua>
	<20090515053142.D17400@n.cwu.edu>
Message-ID: <20090515130609.GG1927@deviant.kiev.zoral.com.ua>

On Fri, May 15, 2009 at 05:32:49AM -0700, Chris Timmons wrote:
> 
> #8  0xc076cf64 in devfs_fp_check (fp=0xc78fadf4, devp=0xee156b0c, 
> dswp=0xee156b08) at /usr/src/sys/fs/devfs/devfs_vnops.c:89
> 89		*dswp = devvn_refthread(fp->f_vnode, devp);
> 
> (kgdb) p *(struct file *)0xc78fadf4
> $1 = {f_list = {le_next = 0xc78ab5f0, le_prev = 0xc789e5f0}, f_type = 1, 
> f_data = 0xce5f9b00, f_flag = 3, f_mtxp = 0xc74540a0, f_ops = 0xc0c48e80, 
> f_cred = 0xc7ae1c00, f_count = 2, f_vnode = 0xc90f4000, f_offset = 0, 
> f_vnread_flags = 0, f_gcflag = 0, f_msgcount = 0, f_seqcount = 1, 
> f_nextoff = 0, f_label = 0x0, f_cdevpriv = 0x0}
> 
> 
> 
> On Fri, 15 May 2009, Kostik Belousov wrote:
> 
> >>#8  0xc076cf64 in devfs_fp_check (fp=0xc78fadf4, devp=0xee156b0c,
> >>dswp=0xee156b08) at /usr/src/sys/fs/devfs/devfs_vnops.c:89
> >Please, show the output of
> >p *(struct file *)0xc78fadf4

The file structure in the dump is fully initialized. It seems that the
issue is with devfs replacing file ops vector with devfs-specific one
in devfs_open() before the struct file is fully initialized in vn_open.
Please, try the patch below (against 7) and report results.

Index: fs/devfs/devfs_vnops.c
===================================================================
--- fs/devfs/devfs_vnops.c	(revision 192089)
+++ fs/devfs/devfs_vnops.c	(working copy)
@@ -890,6 +890,7 @@
 	if (fp != NULL) {
 		FILE_LOCK(fp);
 		fp->f_data = dev;
+		fp->f_vnode = vp;
 		FILE_UNLOCK(fp);
 	}
 	fpop = td->td_fpop;
-------------- 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-stable/attachments/20090515/ebeb4743/attachment.pgp
From jhb at freebsd.org  Fri May 15 13:11:07 2009
From: jhb at freebsd.org (John Baldwin)
Date: Fri May 15 13:11:35 2009
Subject: kernel trap 12 with interrupts disabled [bge0 on 7.2R]
In-Reply-To: <20090514191026.0a90dbfc@zelda.local>
References: <1696198956@web.de> <200905140916.40594.jhb@freebsd.org>
	<20090514191026.0a90dbfc@zelda.local>
Message-ID: <200905150815.19452.jhb@freebsd.org>

On Thursday 14 May 2009 1:10:26 pm Martin wrote:
> Am Thu, 14 May 2009 09:16:40 -0400
> schrieb John Baldwin <jhb@freebsd.org>:
> 
> > On Thursday 14 May 2009 7:47:23 am Martin Sugioarto wrote:
> > [...]
> > > kernel trap 12 with interrupts disabled
> > > 
> > > 
> > > Fatal trap 12: page fault while in kernel mode
> > > cpuid = 0; apic id = 0
> > > fault virtual address = 0x80000000000
> > 
> > Given that that is a single bit set, it could possibly be due to bad
> > RAM.
> 
> This is the second panic output that appeared on the screen. I could not 
read
> the first lines of the first panic. The last ones looked similar
> (same trap/process etc).
> 
> > Does your kernel have debug symbols?
> 
> This is GENERIC kernel configuration. The kernel was totally frozen. I could
> not type anything. I just noticed, I've got a vmcore.0 of the crash.
> 
> I can see some other panic output when loading the kernel in kgdb:
> 
> Unread portion of the kernel message buffer:
> 
> 
> Fatal trap 9: general protection fault while in kernel mode

When I have seen this, it has often been due to a hardware failure such as bad 
RAM.

> cpuid = 2; apic id = 02
> instruction pointer	= 0x8:0xffffffff805bbc66

Can you do 'x/i 0xffffffff805bbc66'?  Also, can you walk up the stack to the 
frame for this panic ('frame 7') and do 'info registers'?

-- 
John Baldwin
From jhb at freebsd.org  Fri May 15 13:11:08 2009
From: jhb at freebsd.org (John Baldwin)
Date: Fri May 15 13:11:37 2009
Subject: Boot panic w/7.2-STABLE on amd64: resource_list_alloc
In-Reply-To: <4A0CF934.4000706@incunabulum.net>
References: <4A0CF934.4000706@incunabulum.net>
Message-ID: <200905150850.19843.jhb@freebsd.org>

On Friday 15 May 2009 1:10:12 am Bruce Simpson wrote:
> Hi,
> 
> Since upgrading sources on RELENG_7 yesterday, my amd64 system panics 
> right after this line in dmesg:
> 
> ata4: <ATA channel 2> on atapci1
> panic: resource_list_alloc: resource entry is busy
> 
> This machine uses an ALi SATA controller. I haven't had any problems 
> with this controller's support for most of the 7.x branch, but it was 
> last broken during the 6.x branch.
> 
> I see there have recently been commits in this area which may have 
> broken ATA driver support in some subtle way.
> 
> Backtrace is (w/o symbols):-
> ...
> resource_list_alloc()
> pci_alloc_resource()
> bus_alloc_resource()
> ata_ali_sata_allocate()
> ata_pcichannel_attach()
> device_attach()
> ...
> 
> There are no debugging symbols at the moment as this is a production kernel.
> If any further information is required to resolve the bug, please let me 
> know.

Sounds like the ATA driver is allocating the same BAR twice.  Hmm, yes, it 
allocates the resources once for each channel it seems in the ata_ali_sata 
attachment.  Looking in ata-chipset.c, all the other chipsets are good about 
allocating these resources in their chipinit routines rather than the 
per-channel allocate routine.  Well, except ata_pci_allocate() is also 
busted.  *sigh*  I can work on a patch for HEAD if you are willing to test.

-- 
John Baldwin
From tinderbox at freebsd.org  Fri May 15 14:07:56 2009
From: tinderbox at freebsd.org (FreeBSD Tinderbox)
Date: Fri May 15 14:08:03 2009
Subject: [releng_6 tinderbox] failure on amd64/amd64
Message-ID: <20090515140752.98A11241BA@freebsd-legacy.sentex.ca>

TB --- 2009-05-15 13:43:29 - tinderbox 2.6 running on freebsd-legacy.sentex.ca
TB --- 2009-05-15 13:43:29 - starting RELENG_6 tinderbox run for amd64/amd64
TB --- 2009-05-15 13:43:29 - cleaning the object tree
TB --- 2009-05-15 13:43:41 - cvsupping the source tree
TB --- 2009-05-15 13:43:41 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/RELENG_6/amd64/amd64/supfile
TB --- 2009-05-15 13:43:48 - building world
TB --- 2009-05-15 13:43:48 - MAKEOBJDIRPREFIX=/obj
TB --- 2009-05-15 13:43:48 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2009-05-15 13:43:48 - TARGET=amd64
TB --- 2009-05-15 13:43:48 - TARGET_ARCH=amd64
TB --- 2009-05-15 13:43:48 - TZ=UTC
TB --- 2009-05-15 13:43:48 - __MAKE_CONF=/dev/null
TB --- 2009-05-15 13:43:48 - cd /src
TB --- 2009-05-15 13:43:48 - /usr/bin/make -B buildworld
>>> 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 -fno-strict-aliasing -pipe  -I. -I/src/lib/libthread_db -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 -c /src/lib/libthread_db/arch/amd64/libpthread_md.c
/src/lib/libthread_db/arch/amd64/libpthread_md.c: In function `pt_fpreg_to_ucontext':
/src/lib/libthread_db/arch/amd64/libpthread_md.c:94: warning: implicit declaration of function `memcpy'
/src/lib/libthread_db/arch/amd64/libpthread_md.c:94: warning: nested extern declaration of `memcpy'
<internal>:0: warning: redundant redeclaration of 'memcpy'
/src/lib/libthread_db/arch/amd64/libpthread_md.c: In function `pt_ucontext_to_fpreg':
/src/lib/libthread_db/arch/amd64/libpthread_md.c:100: warning: nested extern declaration of `memcpy'
<internal>:0: warning: redundant redeclaration of 'memcpy'
*** Error code 1

Stop in /src/lib/libthread_db.
*** Error code 1

Stop in /src/lib.
*** 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-05-15 14:07:52 - WARNING: /usr/bin/make returned exit code  1 
TB --- 2009-05-15 14:07:52 - ERROR: failed to build world
TB --- 2009-05-15 14:07:52 - 1117.87 user 155.05 system 1462.61 real


http://tinderbox.des.no/tinderbox-releng_6-RELENG_6-amd64-amd64.full
From nakal at web.de  Fri May 15 14:57:31 2009
From: nakal at web.de (Martin)
Date: Fri May 15 14:57:45 2009
Subject: kernel trap 12 with interrupts disabled [bge0 on 7.2R]
In-Reply-To: <200905150815.19452.jhb@freebsd.org>
References: <1696198956@web.de> <200905140916.40594.jhb@freebsd.org>
	<20090514191026.0a90dbfc@zelda.local>
	<200905150815.19452.jhb@freebsd.org>
Message-ID: <20090515165727.30eab9ff@zelda.local>

Am Fri, 15 May 2009 08:15:19 -0400
schrieb John Baldwin <jhb@freebsd.org>:

Hi John,

> When I have seen this, it has often been due to a hardware failure
> such as bad RAM.

hmmm... I will check this next week.

> > cpuid = 2; apic id = 02
> > instruction pointer	= 0x8:0xffffffff805bbc66
> 
> Can you do 'x/i 0xffffffff805bbc66'?  Also, can you walk up the stack
> to the frame for this panic ('frame 7') and do 'info registers'?
 
(kgdb) x 0xffffffff805bbc66
0xffffffff805bbc66 <rt_maskedcopy+6>:	0x4912b60f

(kgdb) frame 7
#7  0xffffffff805bbc66 in rt_maskedcopy (src=0xffffffff51e2e6c8, 
    dst=0xffffff00525ebd80, netmask=0xef3fdf377db53afa)
    at /usr/src/sys/net/route.c:1362
1362	{
(kgdb) info registers 
rax            0xffffff00525ebd80	-1098129687168
rbx            0xffffff0006b570f8	-1099399073544
rcx            0x10	16
rdx            0xef3fdf377db53afa	-1207000745686779142
rsi            0xffffff00525ebd80	-1098129687168
rdi            0xffffffff51e2e6c8	-2921142584
rbp            0xffffffff51e2e4c0	0xffffffff51e2e4c0
rsp            0xffffffff51e2e428	0xffffffff51e2e428
r8             0x0	0
r9             0xef3fdf377db53afa	-1207000745686779142
r10            0xffffff00016eba50	-1099487593904
r11            0xffffffff80b3eec0	-2135691584
r12            0xe22173e466d29aa0	-2152311722091570528
r13            0xffffff0006832c00	-1099402368000
r14            0xef3fdf377db53afa	-1207000745686779142
r15            0x0	0
rip            0xffffffff805bbc66	0xffffffff805bbc66 <rt_maskedcopy+6>
eflags         0x10286	66182
cs             0x8	8
ss             0x10	16
ds             0x0	0
es             0x0	0
fs             0x0	0
gs             0x0	0

I hope it helps.

--
Martin
From avg at icyb.net.ua  Fri May 15 15:03:48 2009
From: avg at icyb.net.ua (Andriy Gapon)
Date: Fri May 15 15:03:54 2009
Subject: kbd0 at both atkbd0 and ukbd0
In-Reply-To: <gtuqi6$irb$1@ger.gmane.org>
References: <gtrjq3$u24$1@ger.gmane.org>
	<gtrt5m$ror$1@ger.gmane.org>	<4A019B38.3060101@icyb.net.ua>
	<gtuqi6$irb$1@ger.gmane.org>
Message-ID: <4A0D8450.5070706@icyb.net.ua>

on 07/05/2009 17:17 Helmut Schneider said the following:
> Andriy Gapon <avg@icyb.net.ua> wrote:
>> on 06/05/2009 14:43 Helmut Schneider said the following:
>>> kbd1 at kbdmux0
>> [snip]
>>> atkbdc0: <Keyboard controller (i8042)> at port 0x60,0x64 on isa0 atkbd0:
>>> <AT Keyboard> irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] 
>>> atkbd0: [ITHREAD]
>> [snip]
>>> ukbd0: <IBM IBM MM2, class 0/0, rev 1.10/0.01, addr 5> on uhub0 kbd0 at
>>> ukbd0
>> 
>> It took me three passes to notice the above: "kbd0 at atkbd0" and then again
>> "kbd0 at ukbd0".
> 
> Good point:
> 
> http://www.freebsd.org/cgi/query-pr.cgi?pr=122887 
> http://www.freebsd.org/cgi/query-pr.cgi?pr=133919
> 
> I have 'hint.atkbd.0.disabled="1"' at /boot/default.hints and (probably) 
> freebsd-update killed that one and silently replaced it with 1.16.8.1. The
> whole mess might be related. D'oh!

I don't actually understand fine details of what is happening when you don't have
atkbd disabled (or configured for acpi attachment as opposed to isa).
But I have a guess about why the system ultimately panics:
- atkbd_timeout function: first called from atkbd_attach_unit and then reschedules
itself at hz/10
- it accesses kbdsw[kbd->kb_index] without any checks, but there are
couple of places where kbd_unregister could be called
- thus kbdsw[kbd->kb_index] could become null or different keyboard
- and there is no untimeout ever


-- 
Andriy Gapon
From jhb at freebsd.org  Fri May 15 15:24:35 2009
From: jhb at freebsd.org (John Baldwin)
Date: Fri May 15 15:24:42 2009
Subject: kernel trap 12 with interrupts disabled [bge0 on 7.2R]
In-Reply-To: <20090515165727.30eab9ff@zelda.local>
References: <1696198956@web.de> <200905150815.19452.jhb@freebsd.org>
	<20090515165727.30eab9ff@zelda.local>
Message-ID: <200905151109.21127.jhb@freebsd.org>

On Friday 15 May 2009 10:57:27 am Martin wrote:
> Am Fri, 15 May 2009 08:15:19 -0400
> schrieb John Baldwin <jhb@freebsd.org>:
> 
> Hi John,
> 
> > When I have seen this, it has often been due to a hardware failure
> > such as bad RAM.
> 
> hmmm... I will check this next week.
> 
> > > cpuid = 2; apic id = 02
> > > instruction pointer	= 0x8:0xffffffff805bbc66
> > 
> > Can you do 'x/i 0xffffffff805bbc66'?  Also, can you walk up the stack
> > to the frame for this panic ('frame 7') and do 'info registers'?
>  
> (kgdb) x 0xffffffff805bbc66
> 0xffffffff805bbc66 <rt_maskedcopy+6>:	0x4912b60f

x/i please.  The /i decodes it as an instruction so I can see which registers 
it was attempting to dereference.

> (kgdb) frame 7
> #7  0xffffffff805bbc66 in rt_maskedcopy (src=0xffffffff51e2e6c8, 
>     dst=0xffffff00525ebd80, netmask=0xef3fdf377db53afa)
>     at /usr/src/sys/net/route.c:1362
> 1362	{
> (kgdb) info registers 
> rax            0xffffff00525ebd80	-1098129687168
> rbx            0xffffff0006b570f8	-1099399073544
> rcx            0x10	16
> rdx            0xef3fdf377db53afa	-1207000745686779142
> rsi            0xffffff00525ebd80	-1098129687168
> rdi            0xffffffff51e2e6c8	-2921142584
> rbp            0xffffffff51e2e4c0	0xffffffff51e2e4c0
> rsp            0xffffffff51e2e428	0xffffffff51e2e428
> r8             0x0	0
> r9             0xef3fdf377db53afa	-1207000745686779142
> r10            0xffffff00016eba50	-1099487593904
> r11            0xffffffff80b3eec0	-2135691584
> r12            0xe22173e466d29aa0	-2152311722091570528
> r13            0xffffff0006832c00	-1099402368000
> r14            0xef3fdf377db53afa	-1207000745686779142
> r15            0x0	0
> rip            0xffffffff805bbc66	0xffffffff805bbc66 <rt_maskedcopy+6>
> eflags         0x10286	66182
> cs             0x8	8
> ss             0x10	16
> ds             0x0	0
> es             0x0	0
> fs             0x0	0
> gs             0x0	0
> 
> I hope it helps.
> 
> --
> Martin
> 



-- 
John Baldwin
From nakal at web.de  Fri May 15 15:37:13 2009
From: nakal at web.de (Martin)
Date: Fri May 15 15:37:21 2009
Subject: kernel trap 12 with interrupts disabled [bge0 on 7.2R]
In-Reply-To: <200905150815.19452.jhb@freebsd.org>
References: <1696198956@web.de> <200905140916.40594.jhb@freebsd.org>
	<20090514191026.0a90dbfc@zelda.local>
	<200905150815.19452.jhb@freebsd.org>
Message-ID: <20090515173618.78cca743@zelda.local>


Hi John,

one more thing that I noticed. It seems that the netmask passed to the
procedure rt_maskedcopy is invalid. Cannot dereference the pointer.

I went one frame up and I've looked at the control flow of the parent
routine rtrequest1_fib. This routine passes the netmask, but before it
does that it went with req=11 (RTM_RESOLVE) through this piece of code:

/usr/src/sys/net/route.c:985

case RTM_RESOLVE:
        if (ret_nrt == NULL || (rt = *ret_nrt) == NULL)
                  senderr(EINVAL);
        ifa = rt->rt_ifa;
        /* XXX locking? */
        flags = rt->rt_flags &
                ~(RTF_CLONING | RTF_STATIC);
        flags |= RTF_WASCLONED;
        gateway = rt->rt_gateway;
        if ((netmask = rt->rt_genmask) == NULL)
                flags |= RTF_HOST;
        goto makeroute;

Is this a locking problem?

--
Martin
From nakal at web.de  Fri May 15 15:38:03 2009
From: nakal at web.de (Martin)
Date: Fri May 15 15:38:10 2009
Subject: kernel trap 12 with interrupts disabled [bge0 on 7.2R]
In-Reply-To: <200905151109.21127.jhb@freebsd.org>
References: <1696198956@web.de> <200905150815.19452.jhb@freebsd.org>
	<20090515165727.30eab9ff@zelda.local>
	<200905151109.21127.jhb@freebsd.org>
Message-ID: <20090515173800.071e53c2@zelda.local>

Am Fri, 15 May 2009 11:09:20 -0400
schrieb John Baldwin <jhb@freebsd.org>:

> x/i please.  The /i decodes it as an instruction so I can see which
> registers it was attempting to dereference.

Oh sorry...

(kgdb) x/i 0xffffffff805bbc66
0xffffffff805bbc66 <rt_maskedcopy+6>:	movzbl (%rdx),%edx

--
Martin
From jhb at freebsd.org  Fri May 15 15:42:47 2009
From: jhb at freebsd.org (John Baldwin)
Date: Fri May 15 15:42:54 2009
Subject: kernel trap 12 with interrupts disabled [bge0 on 7.2R]
In-Reply-To: <20090515173618.78cca743@zelda.local>
References: <1696198956@web.de> <200905150815.19452.jhb@freebsd.org>
	<20090515173618.78cca743@zelda.local>
Message-ID: <200905151142.38933.jhb@freebsd.org>

On Friday 15 May 2009 11:36:18 am Martin wrote:
> 
> Hi John,
> 
> one more thing that I noticed. It seems that the netmask passed to the
> procedure rt_maskedcopy is invalid. Cannot dereference the pointer.
> 
> I went one frame up and I've looked at the control flow of the parent
> routine rtrequest1_fib. This routine passes the netmask, but before it
> does that it went with req=11 (RTM_RESOLVE) through this piece of code:
> 
> /usr/src/sys/net/route.c:985
> 
> case RTM_RESOLVE:
>         if (ret_nrt == NULL || (rt = *ret_nrt) == NULL)
>                   senderr(EINVAL);
>         ifa = rt->rt_ifa;
>         /* XXX locking? */
>         flags = rt->rt_flags &
>                 ~(RTF_CLONING | RTF_STATIC);
>         flags |= RTF_WASCLONED;
>         gateway = rt->rt_gateway;
>         if ((netmask = rt->rt_genmask) == NULL)
>                 flags |= RTF_HOST;
>         goto makeroute;
> 
> Is this a locking problem?

A GPF on amd64 usually happens because the pointer has high bits corrupt (the 
high N bits on amd64 must be either all zeros or all ones).  In my experience 
those are all caused by hardware issues rather than races or bugs.

-- 
John Baldwin
From cwt at networks.cwu.edu  Fri May 15 16:02:16 2009
From: cwt at networks.cwu.edu (Chris Timmons)
Date: Fri May 15 16:02:23 2009
Subject: kernel trap 12 with interrupts disabled [bge0 on 7.2R]
In-Reply-To: <20090515130609.GG1927@deviant.kiev.zoral.com.ua>
References: <1696198956@web.de> <20090514091410.H12558@n.cwu.edu>
	<20090514093008.Q12558@n.cwu.edu> <200905141317.56551.jhb@freebsd.org>
	<20090514152838.E12558@n.cwu.edu>
	<20090515082458.GB1927@deviant.kiev.zoral.com.ua>
	<20090515053142.D17400@n.cwu.edu>
	<20090515130609.GG1927@deviant.kiev.zoral.com.ua>
Message-ID: <20090515085956.X21017@n.cwu.edu>


Kostik,

Looking good after applying your patch and rebuilding the kernel.  I've 
been exercising the machine for a couple of hours under the same load 
which crashed it in short order yesterday.

I will report back if any problems appear.

Thank you for your help!

Regards,
-Chris

last pid:  4131;  load averages: 11.72,  8.89,  5.94 
up 0+02:03:21  08:59:48
102 processes: 6 running, 96 sleeping
CPU: 38.7% user,  0.0% nice, 11.2% system,  0.0% interrupt, 50.1% idle
Mem: 409M Active, 1737M Inact, 241M Wired, 544K Cache, 112M Buf, 1372M 
Swap: 8192M Total, 8192M Free


On Fri, 15 May 2009, Kostik Belousov wrote:

> The file structure in the dump is fully initialized. It seems that the
> issue is with devfs replacing file ops vector with devfs-specific one
> in devfs_open() before the struct file is fully initialized in vn_open.
> Please, try the patch below (against 7) and report results.
>
> Index: fs/devfs/devfs_vnops.c
> ===================================================================
> --- fs/devfs/devfs_vnops.c	(revision 192089)
> +++ fs/devfs/devfs_vnops.c	(working copy)
> @@ -890,6 +890,7 @@
> 	if (fp != NULL) {
> 		FILE_LOCK(fp);
> 		fp->f_data = dev;
> +		fp->f_vnode = vp;
> 		FILE_UNLOCK(fp);
> 	}
> 	fpop = td->td_fpop;
From killing at multiplay.co.uk  Fri May 15 16:26:18 2009
From: killing at multiplay.co.uk (Steven Hartland)
Date: Fri May 15 16:26:28 2009
Subject: issues with Intel Pro/1000 and 1000baseTX
References: <4A0C34DC.9040508@mdchs.org>
Message-ID: <A1550D2580F349ACA5139160223BC4A1@multiplay.co.uk>

Never only set one end manually, always set both the machine and the
switch.

    Regards
    Steve

----- Original Message ----- 
From: "James Tanis" <jtanis@mdchs.org>
To: "FreeBSD Questions" <freebsd-questions@freebsd.org>; <freebsd-stable@freebsd.org>
Sent: Thursday, May 14, 2009 4:12 PM
Subject: issues with Intel Pro/1000 and 1000baseTX


>I have a FreeBSD v7.0 box it has two Intel Pro/1000 NICs, the one in 
> question is:
> 
> em1: <Intel(R) PRO/1000 Network Connection Version - 6.7.3> port 
> 0x2020-0x203f mem 0xd8060000-0xd807ffff,0xd8040000-0xd805ffff irq 19 at 
> device 0.1 on pci4
> 
> what we get after boot is:
> 
> em1: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> metric 0 
> mtu 1500
>        options=19b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,TSO4>
>        ether 00:30:48:xx:xx:xx
>        inet 192.168.1.1 netmask 0xffffff00 broadcast 192.168.1.255
>        media: Ethernet autoselect (100baseTX <full-duplex>)
>        status: active
> 
> The problem is that the NIC refuses to connect at 1000baseTX.
> 
> It's connected to a HP Procurve 1700-24 switch which supports 1000baseTX 
> on ports 23 and 24. This particular computer is connected on port 24. I 
> have a much older end user system which uses the same card (but earlier 
> revision), runs Windows XP and is plugged in to port 23. The end user 
> system has no problem connecting at 1000baseTX. I have of course tried 
> switching ports.
> 
> Attempting to force 1000baseTX via:
> 
> ifconfig em1 media 1000baseTX mediaopt full-duplex
> 
> gets me:
> 
> status: no carrier
> 
> After forcing the NIC to go 1000baseTX the LEDs on the backpane are both 
> off. I can only come to the conclusion that this is a driver issue based 
> on previous experience and the simple fact that the end user system is 
> capable of connecting at 1000baseTX. Anybody have any suggestions? I'm 
> hoping I'm wrong. I'd rather not do an in-place upgrade, this is a 
> production system and the main gateway for an entire school, when I do 
> not even know for sure whether this will fix the problem. It's worth it 
> to me though, having a 1000baseTX uplink from the switch would remove a 
> major bottleneck for me.
> 
> Any help would be appreciated.
> 
> -- 
> James Tanis
> Technical Coordinator
> Computer Science Department
> Monsignor Donovan Catholic High School
> 
> _______________________________________________
> freebsd-stable@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org"
>

================================================
This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. 

In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337
or return the E.mail to postmaster@multiplay.co.uk.

From jfvogel at gmail.com  Fri May 15 16:35:12 2009
From: jfvogel at gmail.com (Jack Vogel)
Date: Fri May 15 16:35:19 2009
Subject: issues with Intel Pro/1000 and 1000baseTX
In-Reply-To: <A1550D2580F349ACA5139160223BC4A1@multiplay.co.uk>
References: <4A0C34DC.9040508@mdchs.org>
	<A1550D2580F349ACA5139160223BC4A1@multiplay.co.uk>
Message-ID: <2a41acea0905150935u2d4d63f8q615ca33464b65bdb@mail.gmail.com>

Better yet, just let them autoneg and you won't have these problems :)

Jack


On Fri, May 15, 2009 at 9:15 AM, Steven Hartland <killing@multiplay.co.uk>wrote:

> Never only set one end manually, always set both the machine and the
> switch.
>
>   Regards
>   Steve
>
> ----- Original Message ----- From: "James Tanis" <jtanis@mdchs.org>
> To: "FreeBSD Questions" <freebsd-questions@freebsd.org>; <
> freebsd-stable@freebsd.org>
> Sent: Thursday, May 14, 2009 4:12 PM
> Subject: issues with Intel Pro/1000 and 1000baseTX
>
>
>  I have a FreeBSD v7.0 box it has two Intel Pro/1000 NICs, the one in
>> question is:
>>
>> em1: <Intel(R) PRO/1000 Network Connection Version - 6.7.3> port
>> 0x2020-0x203f mem 0xd8060000-0xd807ffff,0xd8040000-0xd805ffff irq 19 at
>> device 0.1 on pci4
>>
>> what we get after boot is:
>>
>> em1: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> metric 0
>> mtu 1500
>>       options=19b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,TSO4>
>>       ether 00:30:48:xx:xx:xx
>>       inet 192.168.1.1 netmask 0xffffff00 broadcast 192.168.1.255
>>       media: Ethernet autoselect (100baseTX <full-duplex>)
>>       status: active
>>
>> The problem is that the NIC refuses to connect at 1000baseTX.
>>
>> It's connected to a HP Procurve 1700-24 switch which supports 1000baseTX
>> on ports 23 and 24. This particular computer is connected on port 24. I have
>> a much older end user system which uses the same card (but earlier
>> revision), runs Windows XP and is plugged in to port 23. The end user system
>> has no problem connecting at 1000baseTX. I have of course tried switching
>> ports.
>>
>> Attempting to force 1000baseTX via:
>>
>> ifconfig em1 media 1000baseTX mediaopt full-duplex
>>
>> gets me:
>>
>> status: no carrier
>>
>> After forcing the NIC to go 1000baseTX the LEDs on the backpane are both
>> off. I can only come to the conclusion that this is a driver issue based on
>> previous experience and the simple fact that the end user system is capable
>> of connecting at 1000baseTX. Anybody have any suggestions? I'm hoping I'm
>> wrong. I'd rather not do an in-place upgrade, this is a production system
>> and the main gateway for an entire school, when I do not even know for sure
>> whether this will fix the problem. It's worth it to me though, having a
>> 1000baseTX uplink from the switch would remove a major bottleneck for me.
>>
>> Any help would be appreciated.
>>
>> --
>> James Tanis
>> Technical Coordinator
>> Computer Science Department
>> Monsignor Donovan Catholic High School
>>
>> _______________________________________________
>> freebsd-stable@freebsd.org mailing list
>> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
>> To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org"
>>
>>
> ================================================
> This e.mail is private and confidential between Multiplay (UK) Ltd. and the
> person or entity to whom it is addressed. In the event of misdirection, the
> recipient is prohibited from using, copying, printing or otherwise
> disseminating it or any information contained in it.
> In the event of misdirection, illegible or incomplete transmission please
> telephone +44 845 868 1337
> or return the E.mail to postmaster@multiplay.co.uk.
>
> _______________________________________________
> freebsd-stable@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org"
>
From dudu at dudu.ro  Fri May 15 17:03:52 2009
From: dudu at dudu.ro (Vlad GALU)
Date: Fri May 15 17:03:59 2009
Subject: ld-elf.so.1 isn't overwritten upon making installworld
Message-ID: <ad79ad6b0905150942u2c9735d8jbe8f869c47705d57@mail.gmail.com>

All in subject. I could see the particular line where install is
called on the newly built copy, but even though the system copy's file
flags are cleared (noschg), the overwriting fails. I managed to
overwrite it by (cp -f)-ing) the fresh copy over the old one.

Regards,
Vlad
From jhb at freebsd.org  Fri May 15 17:10:06 2009
From: jhb at freebsd.org (John Baldwin)
Date: Fri May 15 17:10:12 2009
Subject: kernel trap 12 with interrupts disabled [bge0 on 7.2R]
In-Reply-To: <20090515173800.071e53c2@zelda.local>
References: <1696198956@web.de> <200905151109.21127.jhb@freebsd.org>
	<20090515173800.071e53c2@zelda.local>
Message-ID: <200905151205.47672.jhb@freebsd.org>

On Friday 15 May 2009 11:38:00 am Martin wrote:
> Am Fri, 15 May 2009 11:09:20 -0400
> schrieb John Baldwin <jhb@freebsd.org>:
> 
> > x/i please.  The /i decodes it as an instruction so I can see which
> > registers it was attempting to dereference.
> 
> Oh sorry...
> 
> (kgdb) x/i 0xffffffff805bbc66
> 0xffffffff805bbc66 <rt_maskedcopy+6>:	movzbl (%rdx),%edx

Hmm, your %rdx is garbage. :(

rdx            0xef3fdf377db53afa       -1207000745686779142

That should at least be

               0xffffff..........

Looks like r9 and r14 have the same odd value.  Normally I would see a more 
obvious breakage such as one of the 'f' nibbles being set to '0' or 'e', etc.  
You could try looking for that odd pointer value in the route structure or as 
arguments to other functions in the stack trace to see if you can find a 
corrupted data structure.

-- 
John Baldwin
From nakal at web.de  Fri May 15 18:10:39 2009
From: nakal at web.de (Martin)
Date: Fri May 15 18:10:47 2009
Subject: kernel trap 12 with interrupts disabled [bge0 on 7.2R]
In-Reply-To: <200905151205.47672.jhb@freebsd.org>
References: <1696198956@web.de> <200905151109.21127.jhb@freebsd.org>
	<20090515173800.071e53c2@zelda.local>
	<200905151205.47672.jhb@freebsd.org>
Message-ID: <20090515201034.2b92c525@zelda.local>

Am Fri, 15 May 2009 12:05:47 -0400
schrieb John Baldwin <jhb@freebsd.org>:

> > (kgdb) x/i 0xffffffff805bbc66
> > 0xffffffff805bbc66 <rt_maskedcopy+6>:	movzbl (%rdx),%edx
> 
> Hmm, your %rdx is garbage. :(
> 
> rdx            0xef3fdf377db53afa       -1207000745686779142
> 
> That should at least be
> 
>                0xffffff..........
> 
> Looks like r9 and r14 have the same odd value.  Normally I would see
> a more obvious breakage such as one of the 'f' nibbles being set to
> '0' or 'e', etc. You could try looking for that odd pointer value in
> the route structure or as arguments to other functions in the stack
> trace to see if you can find a corrupted data structure.

Hi John,

I've been testing RAM for 2 hours in user space with 3 parallel
processes of sysutils/memtest. What can I say?

I just got this in second loop of memtest:

Loop 2:
  Stuck Address       : ok
  Random Value        : ok
  Compare XOR         : ok
  Compare SUB         : ok
  Compare MUL         : ok
  Compare DIV         : ok
  Compare OR          : ok
  Compare AND         : ok
  Sequential Increment: ok
  Solid Bits          : ok
  Block Sequential    : ok
  Checkerboard        : testing  59FAILURE: 0xaaaaaaaaaaaaaaaa != 0x400300007007 at offset 0x007dc608.
FAILURE: 0x5555555555555555 != 0xf0000070ef00007 at offset 0x007dc609.
FAILURE: 0xaaaaaaaaaaaaaaaa != 0x00004003 at offset 0x007dc60a.
FAILURE: 0x5555555555555555 != 0x00004002 at offset 0x007dc60b.
FAILURE: 0xaaaaaaaaaaaaaaaa != 0xffffffff807cb4e0 at offset 0x007dc60c.
FAILURE: 0x5555555555555555 != 0x00000000 at offset 0x007dc60d.
FAILURE: 0xaaaaaaaaaaaaaaaa != 0x000002fa at offset 0x007dc60e.
FAILURE: 0x5555555555555555 != 0x00000000 at offset 0x007dc60f.
  Bit Spread          : ok
  Bit Flip            : setting  35^C



I think this is obvious enough.

Thank you for your patience with me. This was a good hint. I would have
never thought of a RAM defect.

--
Martin
From dimitry at andric.com  Fri May 15 18:49:54 2009
From: dimitry at andric.com (Dimitry Andric)
Date: Fri May 15 18:50:01 2009
Subject: ld-elf.so.1 isn't overwritten upon making installworld
In-Reply-To: <ad79ad6b0905150942u2c9735d8jbe8f869c47705d57@mail.gmail.com>
References: <ad79ad6b0905150942u2c9735d8jbe8f869c47705d57@mail.gmail.com>
Message-ID: <4A0DB94F.9040804@andric.com>

On 2009-05-15 18:42, Vlad GALU wrote:
> All in subject. I could see the particular line where install is
> called on the newly built copy, but even though the system copy's file
> flags are cleared (noschg), the overwriting fails. I managed to
> overwrite it by (cp -f)-ing) the fresh copy over the old one.

Are you running in single-user mode during installworld?
From hdantas at wnetrj.com.br  Fri May 15 19:21:01 2009
From: hdantas at wnetrj.com.br (Declaracao 2009 Incorreta)
Date: Fri May 15 19:21:09 2009
Subject: Multa - =?iso-8859-1?q?Declara=E7=E3o?= 2009
Message-ID: <20090515155519.5302E8220C@relay.wnetrj.com.br>

 - This mail is a HTML mail. Not all elements could be shown in plain text mode. -

Caso nao esteja visualizando este email,
visualize aqui
From dudu at dudu.ro  Fri May 15 20:25:57 2009
From: dudu at dudu.ro (Vlad GALU)
Date: Fri May 15 20:26:05 2009
Subject: ld-elf.so.1 isn't overwritten upon making installworld
In-Reply-To: <4A0DB94F.9040804@andric.com>
References: <ad79ad6b0905150942u2c9735d8jbe8f869c47705d57@mail.gmail.com> 
	<4A0DB94F.9040804@andric.com>
Message-ID: <ad79ad6b0905151325v398aa591x948971f88751dd6c@mail.gmail.com>

On Fri, May 15, 2009 at 9:49 PM, Dimitry Andric <dimitry@andric.com> wrote:
> On 2009-05-15 18:42, Vlad GALU wrote:
>> All in subject. I could see the particular line where install is
>> called on the newly built copy, but even though the system copy's file
>> flags are cleared (noschg), the overwriting fails. I managed to
>> overwrite it by (cp -f)-ing) the fresh copy over the old one.
>
> Are you running in single-user mode during installworld?
>

Yep.
From dimitry at andric.com  Fri May 15 20:37:32 2009
From: dimitry at andric.com (Dimitry Andric)
Date: Fri May 15 20:39:26 2009
Subject: ld-elf.so.1 isn't overwritten upon making installworld
In-Reply-To: <ad79ad6b0905151325v398aa591x948971f88751dd6c@mail.gmail.com>
References: <ad79ad6b0905150942u2c9735d8jbe8f869c47705d57@mail.gmail.com>
	<4A0DB94F.9040804@andric.com>
	<ad79ad6b0905151325v398aa591x948971f88751dd6c@mail.gmail.com>
Message-ID: <4A0DD289.6050908@andric.com>

On 2009-05-15 22:25, Vlad GALU wrote:
>>> called on the newly built copy, but even though the system copy's file
>>> flags are cleared (noschg), the overwriting fails. I managed to
>>> overwrite it by (cp -f)-ing) the fresh copy over the old one.
>> Are you running in single-user mode during installworld?

Alright, just checking. :)  What is the exact error that you're getting?

It might also be the binary isn't changed at all, and in that case it
will *not* be updated (its Makefile uses INSTALLFLAGS=-C -b).
From dudu at dudu.ro  Fri May 15 20:45:57 2009
From: dudu at dudu.ro (Vlad GALU)
Date: Fri May 15 20:46:04 2009
Subject: ld-elf.so.1 isn't overwritten upon making installworld
In-Reply-To: <4A0DD289.6050908@andric.com>
References: <ad79ad6b0905150942u2c9735d8jbe8f869c47705d57@mail.gmail.com> 
	<4A0DB94F.9040804@andric.com>
	<ad79ad6b0905151325v398aa591x948971f88751dd6c@mail.gmail.com> 
	<4A0DD289.6050908@andric.com>
Message-ID: <ad79ad6b0905151345k3011a95dn164f764261e67d08@mail.gmail.com>

On Fri, May 15, 2009 at 11:37 PM, Dimitry Andric <dimitry@andric.com> wrote:
> On 2009-05-15 22:25, Vlad GALU wrote:
>>>> called on the newly built copy, but even though the system copy's file
>>>> flags are cleared (noschg), the overwriting fails. I managed to
>>>> overwrite it by (cp -f)-ing) the fresh copy over the old one.
>>> Are you running in single-user mode during installworld?
>
> Alright, just checking. :) ?What is the exact error that you're getting?
>
> It might also be the binary isn't changed at all, and in that case it
> will *not* be updated (its Makefile uses INSTALLFLAGS=-C -b).
>

There's no error, I just happened to notice that the mtime of my
ld-elf.so.1 was from about 2 months ago (that's about when I made the
last update). The size of the fresh one from /usr/obj/... is
different. Not to mention that there were even some recent changes in
rtld.c :)
From matheus at eternamente.info  Fri May 15 21:01:39 2009
From: matheus at eternamente.info (Nenhum_de_Nos)
Date: Fri May 15 21:01:47 2009
Subject: issues with Intel Pro/1000 and 1000baseTX
In-Reply-To: <ade45ae90905140853r337979d4n45d382889c4245e3@mail.gmail.com>
References: <4A0C34DC.9040508@mdchs.org>
	<ade45ae90905140853r337979d4n45d382889c4245e3@mail.gmail.com>
Message-ID: <9c6b919d50e3d92060fde088f06ddb2b.squirrel@10.1.1.10>


On Thu, May 14, 2009 12:53, Tim Judd wrote:
> On Thu, May 14, 2009 at 9:12 AM, James Tanis <jtanis@mdchs.org> wrote:
>
>> I have a FreeBSD v7.0 box it has two Intel Pro/1000 NICs, the one in
>> question is:
>>
>> em1: <Intel(R) PRO/1000 Network Connection Version - 6.7.3> port
>> 0x2020-0x203f mem 0xd8060000-0xd807ffff,0xd8040000-0xd805ffff irq 19 at
>> device 0.1 on pci4
>>
>> what we get after boot is:
>>
>> em1: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> metric 0
>> mtu 1500
>>       options=19b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,TSO4>
>>       ether 00:30:48:xx:xx:xx
>>       inet 192.168.1.1 netmask 0xffffff00 broadcast 192.168.1.255
>>       media: Ethernet autoselect (100baseTX <full-duplex>)
>>       status: active
>>
>> The problem is that the NIC refuses to connect at 1000baseTX.
>>
>> It's connected to a HP Procurve 1700-24 switch which supports 1000baseTX
>> on
>> ports 23 and 24. This particular computer is connected on port 24. I
>> have a
>> much older end user system which uses the same card (but earlier
>> revision),
>> runs Windows XP and is plugged in to port 23. The end user system has no
>> problem connecting at 1000baseTX. I have of course tried switching
>> ports.
>>
>> Attempting to force 1000baseTX via:
>>
>> ifconfig em1 media 1000baseTX mediaopt full-duplex
>>
>> gets me:
>>
>> status: no carrier
>>
>> After forcing the NIC to go 1000baseTX the LEDs on the backpane are both
>> off. I can only come to the conclusion that this is a driver issue based
>> on
>> previous experience and the simple fact that the end user system is
>> capable
>> of connecting at 1000baseTX. Anybody have any suggestions? I'm hoping
>> I'm
>> wrong. I'd rather not do an in-place upgrade, this is a production
>> system
>> and the main gateway for an entire school, when I do not even know for
>> sure
>> whether this will fix the problem. It's worth it to me though, having a
>> 1000baseTX uplink from the switch would remove a major bottleneck for
>> me.
>>
>> Any help would be appreciated.
>>
>> --
>> James Tanis
>> Technical Coordinator
>> Computer Science Department
>> Monsignor Donovan Catholic High School
>>
>
> I'm going to point the finger at the possibility of the Ethernet cable
> itself.
>
> Gigabit link requires CAT5e or better (CAT6).  A CAT5 alone is NOT enough
> to
> give gigabit speeds.  Check the markings on the cable, replace if it's not
> a
> 5e or 6 and try again.  This includes the discussion of proper terminating
> and twist requirements.

I know this is a bit off, but as I never had CAT6 stuff to deal with here
it goes. is there any problems in using CAT6 cabling and not 1000baseTX
capable switch ?

I plan to install cat6 cables and just use 1000baseTX in future. this will
be my new home network and all I have now is 100baseTX and two 1000baseT
cards.

thanks,

matheus

-- 
We will call you cygnus,
The God of balance you shall be

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?

http://en.wikipedia.org/wiki/Posting_style
From tinderbox at freebsd.org  Fri May 15 23:07:04 2009
From: tinderbox at freebsd.org (FreeBSD Tinderbox)
Date: Fri May 15 23:07:22 2009
Subject: [releng_6 tinderbox] failure on amd64/amd64
Message-ID: <20090515230659.D0B22241BA@freebsd-legacy.sentex.ca>

TB --- 2009-05-15 22:42:23 - tinderbox 2.6 running on freebsd-legacy.sentex.ca
TB --- 2009-05-15 22:42:23 - starting RELENG_6 tinderbox run for amd64/amd64
TB --- 2009-05-15 22:42:23 - cleaning the object tree
TB --- 2009-05-15 22:42:37 - cvsupping the source tree
TB --- 2009-05-15 22:42:38 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/RELENG_6/amd64/amd64/supfile
TB --- 2009-05-15 22:42:46 - building world
TB --- 2009-05-15 22:42:46 - MAKEOBJDIRPREFIX=/obj
TB --- 2009-05-15 22:42:46 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2009-05-15 22:42:46 - TARGET=amd64
TB --- 2009-05-15 22:42:46 - TARGET_ARCH=amd64
TB --- 2009-05-15 22:42:46 - TZ=UTC
TB --- 2009-05-15 22:42:46 - __MAKE_CONF=/dev/null
TB --- 2009-05-15 22:42:46 - cd /src
TB --- 2009-05-15 22:42:46 - /usr/bin/make -B buildworld
>>> 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 -fno-strict-aliasing -pipe  -I. -I/src/lib/libthread_db -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 -c /src/lib/libthread_db/arch/amd64/libpthread_md.c
/src/lib/libthread_db/arch/amd64/libpthread_md.c: In function `pt_fpreg_to_ucontext':
/src/lib/libthread_db/arch/amd64/libpthread_md.c:94: warning: implicit declaration of function `memcpy'
/src/lib/libthread_db/arch/amd64/libpthread_md.c:94: warning: nested extern declaration of `memcpy'
<internal>:0: warning: redundant redeclaration of 'memcpy'
/src/lib/libthread_db/arch/amd64/libpthread_md.c: In function `pt_ucontext_to_fpreg':
/src/lib/libthread_db/arch/amd64/libpthread_md.c:100: warning: nested extern declaration of `memcpy'
<internal>:0: warning: redundant redeclaration of 'memcpy'
*** Error code 1

Stop in /src/lib/libthread_db.
*** Error code 1

Stop in /src/lib.
*** 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-05-15 23:06:59 - WARNING: /usr/bin/make returned exit code  1 
TB --- 2009-05-15 23:06:59 - ERROR: failed to build world
TB --- 2009-05-15 23:06:59 - 1119.03 user 156.33 system 1475.75 real


http://tinderbox.des.no/tinderbox-releng_6-RELENG_6-amd64-amd64.full
From kmacy at freebsd.org  Sat May 16 00:02:23 2009
From: kmacy at freebsd.org (Kip Macy)
Date: Sat May 16 00:02:30 2009
Subject: RFT: ZFS MFC
Message-ID: <3c1674c90905151702l81c2b88off1d2b2ffed39ca2@mail.gmail.com>

I've MFC'd ZFS v13 to RELENG_7 in a work branch. Please test if you can.

http://svn.freebsd.org/base/user/kmacy/ZFS_MFC/

The standard disclaimers apply. This has only been lightly tested in a
VM. Please do not use it with data you care about at this time.


Thanks,
Kip

-- 
When bad men combine, the good must associate; else they will fall one
by one, an unpitied sacrifice in a contemptible struggle.

    Edmund Burke
From mcdouga9 at egr.msu.edu  Sat May 16 06:50:22 2009
From: mcdouga9 at egr.msu.edu (Adam McDougall)
Date: Sat May 16 06:50:29 2009
Subject: RFT: ZFS MFC
In-Reply-To: <3c1674c90905151702l81c2b88off1d2b2ffed39ca2@mail.gmail.com>
References: <3c1674c90905151702l81c2b88off1d2b2ffed39ca2@mail.gmail.com>
Message-ID: <20090516065019.GM82547@egr.msu.edu>

On Fri, May 15, 2009 at 05:02:22PM -0700, Kip Macy wrote:

  I've MFC'd ZFS v13 to RELENG_7 in a work branch. Please test if you can.
  
  http://svn.freebsd.org/base/user/kmacy/ZFS_MFC/
  
  The standard disclaimers apply. This has only been lightly tested in a
  VM. Please do not use it with data you care about at this time.
  
  
  Thanks,
  Kip
  

Seems to work for me so far.  I had a zfs send hang part way through and
with a notable speed difference depending on the direction but this is 
literally the first time I've tried zfs send/recv and the systems are 
setup different so I have no idea if it would have happened anyway.  
Eventually I could probably make these test systems more similar to give a 
fair test, but wanted to mention it so others could check. 

Thanks for working on the MFC, I'm excited to see progress there!
It will play a factor in some upcoming server plans even if the MFC
doesn't happen for months. 
From freebsd at byshenk.net  Sat May 16 07:25:58 2009
From: freebsd at byshenk.net (Greg Byshenk)
Date: Sat May 16 07:26:06 2009
Subject: issues with Intel Pro/1000 and 1000baseTX
In-Reply-To: <9c6b919d50e3d92060fde088f06ddb2b.squirrel@10.1.1.10>
References: <4A0C34DC.9040508@mdchs.org>
	<ade45ae90905140853r337979d4n45d382889c4245e3@mail.gmail.com>
	<9c6b919d50e3d92060fde088f06ddb2b.squirrel@10.1.1.10>
Message-ID: <20090516072544.GC2571@core.byshenk.net>

On Fri, May 15, 2009 at 06:01:33PM -0300, Nenhum_de_Nos wrote:

> I know this is a bit off, but as I never had CAT6 stuff to deal with here
> it goes. is there any problems in using CAT6 cabling and not 1000baseTX
> capable switch ?
> 
> I plan to install cat6 cables and just use 1000baseTX in future. this will
> be my new home network and all I have now is 100baseTX and two 1000baseT
> cards.
 
There should be no problem at all.  CAT6 must meet higher standards, but
the basic cable design is the same at CAT5, and it works for 100baseTX,
and even for 10baseT (if you really wanted to use it).

When my company relocated to a new building, the entire network was 
cabled at CAT6, but we still have some machines and switches that are
100baseTX, and they work fine.

-- 
greg byshenk  -  gbyshenk@byshenk.net  -  Leiden, NL
From tinderbox at freebsd.org  Sat May 16 08:12:47 2009
From: tinderbox at freebsd.org (FreeBSD Tinderbox)
Date: Sat May 16 08:13:00 2009
Subject: [releng_6 tinderbox] failure on amd64/amd64
Message-ID: <20090516081243.6F241241BA@freebsd-legacy.sentex.ca>

TB --- 2009-05-16 07:47:56 - tinderbox 2.6 running on freebsd-legacy.sentex.ca
TB --- 2009-05-16 07:47:56 - starting RELENG_6 tinderbox run for amd64/amd64
TB --- 2009-05-16 07:47:56 - cleaning the object tree
TB --- 2009-05-16 07:48:11 - cvsupping the source tree
TB --- 2009-05-16 07:48:11 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/RELENG_6/amd64/amd64/supfile
TB --- 2009-05-16 07:48:18 - building world
TB --- 2009-05-16 07:48:18 - MAKEOBJDIRPREFIX=/obj
TB --- 2009-05-16 07:48:18 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2009-05-16 07:48:18 - TARGET=amd64
TB --- 2009-05-16 07:48:18 - TARGET_ARCH=amd64
TB --- 2009-05-16 07:48:18 - TZ=UTC
TB --- 2009-05-16 07:48:18 - __MAKE_CONF=/dev/null
TB --- 2009-05-16 07:48:18 - cd /src
TB --- 2009-05-16 07:48:18 - /usr/bin/make -B buildworld
>>> 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 -fno-strict-aliasing -pipe  -I. -I/src/lib/libthread_db -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 -c /src/lib/libthread_db/arch/amd64/libpthread_md.c
/src/lib/libthread_db/arch/amd64/libpthread_md.c: In function `pt_fpreg_to_ucontext':
/src/lib/libthread_db/arch/amd64/libpthread_md.c:94: warning: implicit declaration of function `memcpy'
/src/lib/libthread_db/arch/amd64/libpthread_md.c:94: warning: nested extern declaration of `memcpy'
<internal>:0: warning: redundant redeclaration of 'memcpy'
/src/lib/libthread_db/arch/amd64/libpthread_md.c: In function `pt_ucontext_to_fpreg':
/src/lib/libthread_db/arch/amd64/libpthread_md.c:100: warning: nested extern declaration of `memcpy'
<internal>:0: warning: redundant redeclaration of 'memcpy'
*** Error code 1

Stop in /src/lib/libthread_db.
*** Error code 1

Stop in /src/lib.
*** 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-05-16 08:12:43 - WARNING: /usr/bin/make returned exit code  1 
TB --- 2009-05-16 08:12:43 - ERROR: failed to build world
TB --- 2009-05-16 08:12:43 - 1117.44 user 158.98 system 1487.13 real


http://tinderbox.des.no/tinderbox-releng_6-RELENG_6-amd64-amd64.full
From bms at incunabulum.net  Sat May 16 08:21:51 2009
From: bms at incunabulum.net (Bruce Simpson)
Date: Sat May 16 08:21:59 2009
Subject: Boot panic w/7.2-STABLE on amd64: resource_list_alloc
In-Reply-To: <200905150850.19843.jhb@freebsd.org>
References: <4A0CF934.4000706@incunabulum.net>
	<200905150850.19843.jhb@freebsd.org>
Message-ID: <4A0E779B.4040309@incunabulum.net>

John Baldwin wrote:
> ...
> Sounds like the ATA driver is allocating the same BAR twice.  Hmm, yes, it 
> allocates the resources once for each channel it seems in the ata_ali_sata 
> attachment.  Looking in ata-chipset.c, all the other chipsets are good about 
> allocating these resources in their chipinit routines rather than the 
> per-channel allocate routine.  Well, except ata_pci_allocate() is also 
> busted.  *sigh*  I can work on a patch for HEAD if you are willing to test.
>   

Yes, ata is gnarly in places...

If a fix can be dropped straight into a 7.2 tree, then that is even 
better... I could try testing a NanoBSD image of HEAD on this machine if 
the change set delta between branches is sufficiently huge to prevent 
backporting the fix; this is my desktop machine and this is the only 
critical bug I've run into so far with 7.2.

thanks,
BMS

From lists at loveturtle.net  Sat May 16 12:58:23 2009
From: lists at loveturtle.net (Dillon Kass)
Date: Sat May 16 12:58:30 2009
Subject: RFT: ZFS MFC
In-Reply-To: <3c1674c90905151702l81c2b88off1d2b2ffed39ca2@mail.gmail.com>
References: <3c1674c90905151702l81c2b88off1d2b2ffed39ca2@mail.gmail.com>
Message-ID: <4A0EB479.5080502@loveturtle.net>

On 5/15/09 8:02 PM, Kip Macy wrote:
> I've MFC'd ZFS v13 to RELENG_7 in a work branch. Please test if you can.
>
> http://svn.freebsd.org/base/user/kmacy/ZFS_MFC/
>
> The standard disclaimers apply. This has only been lightly tested in a
> VM. Please do not use it with data you care about at this time.
>
>
> Thanks,
> Kip
>
>    
I created a pool on 7.1, created some datasets, populated them, made 
some snapshots. Upgraded to v13 deleted a few snapshots, created a 
clone, promoted a clone, deleted and created some new datasets.

So far so good. I'll try to make something break!
From tinderbox at freebsd.org  Sat May 16 17:27:18 2009
From: tinderbox at freebsd.org (FreeBSD Tinderbox)
Date: Sat May 16 17:27:38 2009
Subject: [releng_6 tinderbox] failure on amd64/amd64
Message-ID: <20090516172714.7E469241BA@freebsd-legacy.sentex.ca>

TB --- 2009-05-16 17:02:27 - tinderbox 2.6 running on freebsd-legacy.sentex.ca
TB --- 2009-05-16 17:02:27 - starting RELENG_6 tinderbox run for amd64/amd64
TB --- 2009-05-16 17:02:27 - cleaning the object tree
TB --- 2009-05-16 17:02:39 - cvsupping the source tree
TB --- 2009-05-16 17:02:39 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/RELENG_6/amd64/amd64/supfile
TB --- 2009-05-16 17:02:46 - building world
TB --- 2009-05-16 17:02:46 - MAKEOBJDIRPREFIX=/obj
TB --- 2009-05-16 17:02:46 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2009-05-16 17:02:46 - TARGET=amd64
TB --- 2009-05-16 17:02:46 - TARGET_ARCH=amd64
TB --- 2009-05-16 17:02:46 - TZ=UTC
TB --- 2009-05-16 17:02:46 - __MAKE_CONF=/dev/null
TB --- 2009-05-16 17:02:46 - cd /src
TB --- 2009-05-16 17:02:46 - /usr/bin/make -B buildworld
>>> 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 -fno-strict-aliasing -pipe  -I. -I/src/lib/libthread_db -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 -c /src/lib/libthread_db/arch/amd64/libpthread_md.c
/src/lib/libthread_db/arch/amd64/libpthread_md.c: In function `pt_fpreg_to_ucontext':
/src/lib/libthread_db/arch/amd64/libpthread_md.c:94: warning: implicit declaration of function `memcpy'
/src/lib/libthread_db/arch/amd64/libpthread_md.c:94: warning: nested extern declaration of `memcpy'
<internal>:0: warning: redundant redeclaration of 'memcpy'
/src/lib/libthread_db/arch/amd64/libpthread_md.c: In function `pt_ucontext_to_fpreg':
/src/lib/libthread_db/arch/amd64/libpthread_md.c:100: warning: nested extern declaration of `memcpy'
<internal>:0: warning: redundant redeclaration of 'memcpy'
*** Error code 1

Stop in /src/lib/libthread_db.
*** Error code 1

Stop in /src/lib.
*** 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-05-16 17:27:14 - WARNING: /usr/bin/make returned exit code  1 
TB --- 2009-05-16 17:27:14 - ERROR: failed to build world
TB --- 2009-05-16 17:27:14 - 1118.53 user 155.83 system 1486.74 real


http://tinderbox.des.no/tinderbox-releng_6-RELENG_6-amd64-amd64.full
From david at usermode.org  Sat May 16 17:31:41 2009
From: david at usermode.org (David Johnson)
Date: Sat May 16 17:32:20 2009
Subject: Xorg hangs with drmwtq in 7.2-RELEASE
In-Reply-To: <1242141471.1755.11.camel@balrog.2hip.net>
References: <200905042015.29394.david@usermode.org>
	<200905091841.26274.david@usermode.org>
	<1242141471.1755.11.camel@balrog.2hip.net>
Message-ID: <200905161031.29975.david@usermode.org>

I don't know if this helps pinpointing my problem, but when I unload
the drm module, I get the following message:

May 15 19:57:52 radagast kernel: vgapci0: child drm0 requested pci_disable_busmaster
May 15 19:57:52 radagast kernel: drm0: detached
May 15 19:57:52 radagast kernel: Warning: memory type drm_bufs leaked memory on destroy (4 allocations, 128 bytes leaked).

After this I can load the radeon and drm modules, but X will not start,
complaining about no screen found.

-- 
David Johnson
From torfinn.ingolfsen at broadpark.no  Sat May 16 19:49:27 2009
From: torfinn.ingolfsen at broadpark.no (Torfinn Ingolfsen)
Date: Sat May 16 19:49:34 2009
Subject: uchcom and RELENG_7?
In-Reply-To: <20090408190018.9f30845f.torfinn.ingolfsen@broadpark.no>
References: <20090408190018.9f30845f.torfinn.ingolfsen@broadpark.no>
Message-ID: <20090516214924.b2c8b7c0.torfinn.ingolfsen@broadpark.no>

On Wed, 08 Apr 2009 19:00:18 +0200
Torfinn Ingolfsen <torfinn.ingolfsen@broadpark.no> wrote:

> Hi,
> Is there any reason why uchcom[1] hasn't been MFC'ed to RELENG_7 yet?

Anyone?
uchcom doesn't seem to have made it into 7.2 either.


> I see discussion[2] about this subject as far back as around
> 7.0-release, but I can't find any uchcom.c files in my src, not even
> for latest RELENG_7.
> 
> References:
> 1)
> http://www.freebsd.org/cgi/man.cgi?query=uchcom&apropos=0&sektion=0&manpath=FreeBSD+8-current&format=html
> 2)
> http://markmail.org/message/4w324qx4usmnd4ic#query:freebsd%20uchcom+page:1+mid:ecwpudhls4jqpr5s+state:results
> -- 
> Regards,
> Torfinn Ingolfsen
-- 
Regards,
Torfinn Ingolfsen

From npapke at acm.org  Sat May 16 20:11:00 2009
From: npapke at acm.org (Norbert Papke)
Date: Sat May 16 20:11:08 2009
Subject: 7.2-STABLE: Inserting USB device causes Fatal Trap 12
In-Reply-To: <200905101217.39920.fbsd-ml@scrapper.ca>
References: <200905101217.39920.fbsd-ml@scrapper.ca>
Message-ID: <200905161310.57596.npapke@acm.org>

On May 10, 2009, Norbert Papke wrote:
> Inserting a USB thumb drive into a running sytem result in a "Fatal trap
> 12: page fault while in kernel mode".

After repeating the crash a few times with INVARIANTS enabled, it becomes 
apparent that EHCI transfer queue is getting corrupted.

With High Precision Event Timers disabled in the BIOS, the problem goes away.  
This is an acceptable work-around for me.  I am inclined to believe (but 
unable to prove) that the crash is due to a BIOS bug.

Cheers,

-- Norbert Papke.
From dougb at FreeBSD.org  Sat May 16 23:13:16 2009
From: dougb at FreeBSD.org (Doug Barton)
Date: Sat May 16 23:13:23 2009
Subject: RELENG_7 - has mergemaster changed logic since 7.2-RELEASE?
In-Reply-To: <49FFEECE.20403@FreeBSD.org>
References: <20090504225012.392fa49f.torfinn.ingolfsen@broadpark.no>	<49FF5901.600@gmail.com>
	<49FFEECE.20403@FreeBSD.org>
Message-ID: <4A0F4888.3070709@FreeBSD.org>

I think I now know what was causing the problem with the files being
overwritten, the saved mtree database was somehow reduced to zero
bytes causing the list of CHANGED files to be empty.

Unfortunately I haven't tracked down the cause of why the mtree file
would get emptied out (given that there is already code that should
prevent that problem) but I have just committed r192230 which adds a
lot of safety belts to the code involving creating and updating the
mtree database, and creating and using the list of files with changes.
It should no longer be possible to even enter the -U code unless there
is both a valid mtree file AND a valid list of files with local
changes. FWIW I've also improved the performance of the -U option by
changing a use of grep for every file to using case.

You should be able to grab the file from HEAD and run it on
RELENG_[67] without any problems. I will MFC it as rapidly as possible.


Sorry for the inconvenience,

Doug

-- 

    This .signature sanitized for your protection

From wpaul at FreeBSD.ORG  Sat May 16 23:59:52 2009
From: wpaul at FreeBSD.ORG (Bill Paul)
Date: Sun May 17 00:00:00 2009
Subject: Fear and loathing in FreeBSD 7.2 (AGP issues and fixes)
Message-ID: <20090516235952.77D391065670@hub.freebsd.org>


So. I decided to test FreeBSD 7.2 on my Averatec AV1020 ED1 laptop. (It
currently has 6.0-RELEASE on it, and while it runs fine, I figured now
was a good time to update it.) I ran into two problems with it, and I
thought it would be a good idea to share how I resolved them, just in
case anyone else is foolish enough to follow in my tracks.

The laptop has a RaLink RT2560 wireless chipset. The ral(4) driver
supports this chip out of the box, however that driver doesn't support
WPA2 Enterprise, which I need for work. To get around this, I use
the Windows NDIS driver with Project Evil. Unfortunately, the driver
that comes with the laptop (version 3.0.3.0000) is buggy, and will
trigger a kernel panic in certain conditions. It seems to have trouble
parsing information from certain newer kinds of devices, which causes
some of the code inside the driver binary to dereference a bogus pointer.

This is not a problem with FreeBSD or Project Evil: I discovered that
the same driver blue-screens Windows XP as well (a testament to just
how closely Project Evil emulates Windows: it even emulates its crashes).
Luckily there is a slightly newer driver available that fixes this issue
(3.1.0.000), though I had to hunt a bit to find it. I put copies of
the .SYS and .INF at:

	http://www.freebsd.org/~wpaul/7_2_RELEASE/wifi

The other problems I had were with graphics. The Averatec has an Intel
82855GME graphics controller. With FreeBSD 6.0, I had it working nicely
with DRI and everything. With FreeBSD 7.2 and xorg 1.6.0, I saw some
peculiar problems.

The most glaring issue was that after running X -configure for the first
time and testing the resulting xorg.conf file, I found that the X server
would not respond to the mouse or keyboard. After some digging, I found
that this was due to the AutoAddDevices feature (described in xorg.conf(5))
being on by default. If AutoAddDevices is on, then AllowEmptyInput is also
turned on, but the description for AllowEmptyInput says: "If AllowEmptyInput
is on, devices using the kbd, mouse or vmmouse driver are ignored." I
don't know what's supposed to happen instead, but it wasn't working. I
had to add:

        Option         "AutoAddDevices" "False"

to my xorg.conf to turn this off in order for my mouse and keyboard to
work.

On a related note, the X server seems to ignore a lot of what you put
in xorg.conf in favor of its autoselected defaults. I tried to use
"DefaultDepth 24" to force the screen color depth, but it seems to
always ignore this and use a depth of 32 bits. It seems to work ok, but
I thought this was odd. If I tell it to do something, it should do it.
This used to work in earlier X releases.

More curiously, X -configure decided for some reason that my laptop
had two graphics cards instead of one. This apparently has to do with
the fact that the gracphic device has two PCI functions:

vgapci0@pci0:0:2:0:     class=0x030000 card=0x031914ff chip=0x35828086 rev=0x02 hdr=0x00
    vendor     = 'Intel Corporation'
    device     = '82852GM/GME/GMV/PM, 855GM/GME Montara Integrated Graphics Device'
    class      = display
    subclass   = VGA
vgapci1@pci0:0:2:1:     class=0x038000 card=0x031914ff chip=0x35828086 rev=0x02 hdr=0x00
    vendor     = 'Intel Corporation'
    device     = '82852GM/GME/GMV/PM, 855GM/GME Montara Integrated Graphics Device'
    class      = display

X -configure created a "Card" and "Screen" section for both of these, even
though it should only have created one. I had to edit the xorg.conf to
remove the duplicates. (This was something else that worked correctly in
older versions of X.)

Once I settled those issues, the X server worked, but I found that I
was unable to use DRI. FreeBSD was correctly loading the agp, drm and
i915 drivers, but the X server refused to activate DRI support. According
to the Xorg.log.0 file, it was failing to allocate a couple of regions
of physical memory from the AGP driver. I finally traced this down to
the agp_i810 code in the kernel. In agp_i810_alloc_memory(), it says:

[...]
        } else if (type == 2) {
                /*
                 * Type 2 is the contiguous physical memory type, that hands
                 * back a physical address.  This is used for cursors on i810.
                 * Hand back as many single pages with physical as the user
                 * wants, but only allow one larger allocation (ARGB cursor)
                 * for simplicity.
                 */
                if (size != AGP_PAGE_SIZE) {
                        if (sc->argb_cursor != NULL)
                                return 0;

[...]

I'm all for simplicity, but this is bogus: the Intel video driver wants
to allocate three ranges of physical memory for cursors, but only the
first one succeeds. Two additional allocates for 40K and 16K both fail
because of this code.

I ended up modifying agp_i810.c to deal with this, by allowing it to
allocate as many of these ranges as it wants. In the process of testing
this, I also ran into another problem: if you load agp.ko, drm.ko
and i915.ko as modules, and then try to unload them, the kernel will
panic in agp_i810_detach(). It seems that during unload, the drm/i915
code will release the I/O resources allocated by the agp_i810 driver before
the agp_i810_detach() driver gets to run. That's a shame, because
agp_i810_detach() needs to use them. When it tries to clear a bit in one
of the i810's registers, it ends up trying to use a memory mapped I/P
mapping that's no longer valid. As a workaround, I modified
agp_i810_detach() to check to see if the resources are still valid, and
to allocate them again if they're not. This is a hack: the DRM code
should be sorted out to prevent this from happening, but I'm not really
eager to dive into it myself.

I put the modified Intel AGP driver code at:

	http://www.freebsd.org/~wpaul/7_2_RELEASE/agp

To use it, copy agp_i810.c and agppriv.h to /sys/pci, then recompile
your kernel and/or agp.ko module.

Once I patched the AGP driver, the X server was willing to enable DRI
support, but I found that GLX apps still didn't work. In particular,
things like the GLmatrix screen saver in KDE 4 claimed that the current
visual did not support the GLX extension. Looking through the log
file again, I saw that it said: "(==) AIGLX disabled." I considered
this odd, since I didn't ask to disable it. Apparently it's disabled
by default. I corrected this by adding:

       Option         "AIGLX" "on"

to the xorg.conf file. Finally, everything worked correctly. I was
even able to compile and install the latest Intel video driver (2.7.1).
One minor nit is that the FreeBSD AGP code doesn't support GEM, which
the newer X drivers seem to want. This does not appear to be a fatal
problem (yet).

I put my current xorg.conf file at:

	http://www.freebsd.org/~wpaul/7_2_RELEASE/agp

as well.

It was a bit of a shame that I had to fight so much to get this stuff
to work, though now that I have I'm relatively pleased with the results.
I was able to get bluetooth tethering to work with my Blackberry fairly
easily. I still need to confirm that WPA2 works when I get to the office on
Monday. If it does, I'm going to go through with the update.

-Bill

--
=============================================================================
-Bill Paul            (510) 749-2329 | Senior Engineer, Master of Unix-Fu
                 wpaul@windriver.com | Wind River Systems
=============================================================================
   "I put a dollar in a change machine. Nothing changed." - George Carlin
=============================================================================
From onemda at gmail.com  Sun May 17 00:43:59 2009
From: onemda at gmail.com (Paul B. Mahol)
Date: Sun May 17 00:44:07 2009
Subject: Fear and loathing in FreeBSD 7.2 (AGP issues and fixes)
In-Reply-To: <20090516235952.77D391065670@hub.freebsd.org>
References: <20090516235952.77D391065670@hub.freebsd.org>
Message-ID: <3a142e750905161743u433cc0cfx613dfe0d1aceb254@mail.gmail.com>

On 5/17/09, Bill Paul <wpaul@freebsd.org> wrote:
>
> So. I decided to test FreeBSD 7.2 on my Averatec AV1020 ED1 laptop. (It
> currently has 6.0-RELEASE on it, and while it runs fine, I figured now
> was a good time to update it.) I ran into two problems with it, and I
> thought it would be a good idea to share how I resolved them, just in
> case anyone else is foolish enough to follow in my tracks.
>
> The laptop has a RaLink RT2560 wireless chipset. The ral(4) driver
> supports this chip out of the box, however that driver doesn't support
> WPA2 Enterprise, which I need for work. To get around this, I use
> the Windows NDIS driver with Project Evil. Unfortunately, the driver
> that comes with the laptop (version 3.0.3.0000) is buggy, and will
> trigger a kernel panic in certain conditions. It seems to have trouble
> parsing information from certain newer kinds of devices, which causes
> some of the code inside the driver binary to dereference a bogus pointer.
>
> This is not a problem with FreeBSD or Project Evil: I discovered that
> the same driver blue-screens Windows XP as well (a testament to just
> how closely Project Evil emulates Windows: it even emulates its crashes).
> Luckily there is a slightly newer driver available that fixes this issue
> (3.1.0.000), though I had to hunt a bit to find it. I put copies of
> the .SYS and .INF at:
>
> 	http://www.freebsd.org/~wpaul/7_2_RELEASE/wifi
>
> The other problems I had were with graphics. The Averatec has an Intel
> 82855GME graphics controller. With FreeBSD 6.0, I had it working nicely
> with DRI and everything. With FreeBSD 7.2 and xorg 1.6.0, I saw some
> peculiar problems.
>
> The most glaring issue was that after running X -configure for the first
> time and testing the resulting xorg.conf file, I found that the X server
> would not respond to the mouse or keyboard. After some digging, I found
> that this was due to the AutoAddDevices feature (described in xorg.conf(5))
> being on by default. If AutoAddDevices is on, then AllowEmptyInput is also
> turned on, but the description for AllowEmptyInput says: "If AllowEmptyInput
> is on, devices using the kbd, mouse or vmmouse driver are ignored." I
> don't know what's supposed to happen instead, but it wasn't working. I
> had to add:
>
>         Option         "AutoAddDevices" "False"
>
> to my xorg.conf to turn this off in order for my mouse and keyboard to
> work.
>
> On a related note, the X server seems to ignore a lot of what you put
> in xorg.conf in favor of its autoselected defaults. I tried to use
> "DefaultDepth 24" to force the screen color depth, but it seems to
> always ignore this and use a depth of 32 bits. It seems to work ok, but
> I thought this was odd. If I tell it to do something, it should do it.
> This used to work in earlier X releases.

Well, at least with intel driver on i915GM using anything lower than
defaults will cause interesting artefacts on various games: alephone & oolite.

>
> More curiously, X -configure decided for some reason that my laptop
> had two graphics cards instead of one. This apparently has to do with
> the fact that the gracphic device has two PCI functions:
>
> vgapci0@pci0:0:2:0:     class=0x030000 card=0x031914ff chip=0x35828086
> rev=0x02 hdr=0x00
>     vendor     = 'Intel Corporation'
>     device     = '82852GM/GME/GMV/PM, 855GM/GME Montara Integrated Graphics
> Device'
>     class      = display
>     subclass   = VGA
> vgapci1@pci0:0:2:1:     class=0x038000 card=0x031914ff chip=0x35828086
> rev=0x02 hdr=0x00
>     vendor     = 'Intel Corporation'
>     device     = '82852GM/GME/GMV/PM, 855GM/GME Montara Integrated Graphics
> Device'
>     class      = display
>
> X -configure created a "Card" and "Screen" section for both of these, even
> though it should only have created one. I had to edit the xorg.conf to
> remove the duplicates. (This was something else that worked correctly in
> older versions of X.)
>
> Once I settled those issues, the X server worked, but I found that I
> was unable to use DRI. FreeBSD was correctly loading the agp, drm and
> i915 drivers, but the X server refused to activate DRI support. According
> to the Xorg.log.0 file, it was failing to allocate a couple of regions
> of physical memory from the AGP driver. I finally traced this down to
> the agp_i810 code in the kernel. In agp_i810_alloc_memory(), it says:
>
> [...]
>         } else if (type == 2) {
>                 /*
>                  * Type 2 is the contiguous physical memory type, that hands
>                  * back a physical address.  This is used for cursors on
> i810.
>                  * Hand back as many single pages with physical as the user
>                  * wants, but only allow one larger allocation (ARGB cursor)
>                  * for simplicity.
>                  */
>                 if (size != AGP_PAGE_SIZE) {
>                         if (sc->argb_cursor != NULL)
>                                 return 0;
>
> [...]
>
> I'm all for simplicity, but this is bogus: the Intel video driver wants
> to allocate three ranges of physical memory for cursors, but only the
> first one succeeds. Two additional allocates for 40K and 16K both fail
> because of this code.
>
> I ended up modifying agp_i810.c to deal with this, by allowing it to
> allocate as many of these ranges as it wants. In the process of testing
> this, I also ran into another problem: if you load agp.ko, drm.ko
> and i915.ko as modules, and then try to unload them, the kernel will
> panic in agp_i810_detach(). It seems that during unload, the drm/i915

That is fixed correctly on CURRENT but not backported.
Maybe I can track exact svn revision ... I never cared to file PR because I use
only CURRENT.

> code will release the I/O resources allocated by the agp_i810 driver before
> the agp_i810_detach() driver gets to run. That's a shame, because
> agp_i810_detach() needs to use them. When it tries to clear a bit in one
> of the i810's registers, it ends up trying to use a memory mapped I/P
> mapping that's no longer valid. As a workaround, I modified
> agp_i810_detach() to check to see if the resources are still valid, and
> to allocate them again if they're not. This is a hack: the DRM code
> should be sorted out to prevent this from happening, but I'm not really
> eager to dive into it myself.
>
> I put the modified Intel AGP driver code at:
>
> 	http://www.freebsd.org/~wpaul/7_2_RELEASE/agp
>
> To use it, copy agp_i810.c and agppriv.h to /sys/pci, then recompile
> your kernel and/or agp.ko module.
>
> Once I patched the AGP driver, the X server was willing to enable DRI
> support, but I found that GLX apps still didn't work. In particular,
> things like the GLmatrix screen saver in KDE 4 claimed that the current
> visual did not support the GLX extension. Looking through the log
> file again, I saw that it said: "(==) AIGLX disabled." I considered
> this odd, since I didn't ask to disable it. Apparently it's disabled
> by default. I corrected this by adding:
>
>        Option         "AIGLX" "on"
>
> to the xorg.conf file. Finally, everything worked correctly. I was
> even able to compile and install the latest Intel video driver (2.7.1).
> One minor nit is that the FreeBSD AGP code doesn't support GEM, which
> the newer X drivers seem to want. This does not appear to be a fatal
> problem (yet).
>
> I put my current xorg.conf file at:
>
> 	http://www.freebsd.org/~wpaul/7_2_RELEASE/agp
>
> as well.
>
> It was a bit of a shame that I had to fight so much to get this stuff
> to work, though now that I have I'm relatively pleased with the results.
> I was able to get bluetooth tethering to work with my Blackberry fairly
> easily. I still need to confirm that WPA2 works when I get to the office on
> Monday. If it does, I'm going to go through with the update.
>
> -Bill
>
> --
> =============================================================================
> -Bill Paul            (510) 749-2329 | Senior Engineer, Master of Unix-Fu
>                  wpaul@windriver.com | Wind River Systems
> =============================================================================
>    "I put a dollar in a change machine. Nothing changed." - George Carlin
> =============================================================================
> _______________________________________________
> freebsd-stable@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org"
>


-- 
Paul
From onemda at gmail.com  Sun May 17 00:55:43 2009
From: onemda at gmail.com (Paul B. Mahol)
Date: Sun May 17 00:55:50 2009
Subject: Fear and loathing in FreeBSD 7.2 (AGP issues and fixes)
In-Reply-To: <3a142e750905161743u433cc0cfx613dfe0d1aceb254@mail.gmail.com>
References: <20090516235952.77D391065670@hub.freebsd.org>
	<3a142e750905161743u433cc0cfx613dfe0d1aceb254@mail.gmail.com>
Message-ID: <3a142e750905161755q77d8bde5jab97d6eda1b480ee@mail.gmail.com>

On 5/17/09, Paul B. Mahol <onemda@gmail.com> wrote:
> On 5/17/09, Bill Paul <wpaul@freebsd.org> wrote:
>>
>> So. I decided to test FreeBSD 7.2 on my Averatec AV1020 ED1 laptop. (It
>> currently has 6.0-RELEASE on it, and while it runs fine, I figured now
>> was a good time to update it.) I ran into two problems with it, and I
>> thought it would be a good idea to share how I resolved them, just in
>> case anyone else is foolish enough to follow in my tracks.
>>
>> The laptop has a RaLink RT2560 wireless chipset. The ral(4) driver
>> supports this chip out of the box, however that driver doesn't support
>> WPA2 Enterprise, which I need for work. To get around this, I use
>> the Windows NDIS driver with Project Evil. Unfortunately, the driver
>> that comes with the laptop (version 3.0.3.0000) is buggy, and will
>> trigger a kernel panic in certain conditions. It seems to have trouble
>> parsing information from certain newer kinds of devices, which causes
>> some of the code inside the driver binary to dereference a bogus pointer.
>>
>> This is not a problem with FreeBSD or Project Evil: I discovered that
>> the same driver blue-screens Windows XP as well (a testament to just
>> how closely Project Evil emulates Windows: it even emulates its crashes).
>> Luckily there is a slightly newer driver available that fixes this issue
>> (3.1.0.000), though I had to hunt a bit to find it. I put copies of
>> the .SYS and .INF at:
>>
>> 	http://www.freebsd.org/~wpaul/7_2_RELEASE/wifi
>>
>> The other problems I had were with graphics. The Averatec has an Intel
>> 82855GME graphics controller. With FreeBSD 6.0, I had it working nicely
>> with DRI and everything. With FreeBSD 7.2 and xorg 1.6.0, I saw some
>> peculiar problems.
>>
>> The most glaring issue was that after running X -configure for the first
>> time and testing the resulting xorg.conf file, I found that the X server
>> would not respond to the mouse or keyboard. After some digging, I found
>> that this was due to the AutoAddDevices feature (described in
>> xorg.conf(5))
>> being on by default. If AutoAddDevices is on, then AllowEmptyInput is
>> also
>> turned on, but the description for AllowEmptyInput says: "If
>> AllowEmptyInput
>> is on, devices using the kbd, mouse or vmmouse driver are ignored." I
>> don't know what's supposed to happen instead, but it wasn't working. I
>> had to add:
>>
>>         Option         "AutoAddDevices" "False"
>>
>> to my xorg.conf to turn this off in order for my mouse and keyboard to
>> work.
>>
>> On a related note, the X server seems to ignore a lot of what you put
>> in xorg.conf in favor of its autoselected defaults. I tried to use
>> "DefaultDepth 24" to force the screen color depth, but it seems to
>> always ignore this and use a depth of 32 bits. It seems to work ok, but
>> I thought this was odd. If I tell it to do something, it should do it.
>> This used to work in earlier X releases.
>
> Well, at least with intel driver on i915GM using anything lower than
> defaults will cause interesting artefacts on various games: alephone &
> oolite.
>
>>
>> More curiously, X -configure decided for some reason that my laptop
>> had two graphics cards instead of one. This apparently has to do with
>> the fact that the gracphic device has two PCI functions:
>>
>> vgapci0@pci0:0:2:0:     class=0x030000 card=0x031914ff chip=0x35828086
>> rev=0x02 hdr=0x00
>>     vendor     = 'Intel Corporation'
>>     device     = '82852GM/GME/GMV/PM, 855GM/GME Montara Integrated
>> Graphics
>> Device'
>>     class      = display
>>     subclass   = VGA
>> vgapci1@pci0:0:2:1:     class=0x038000 card=0x031914ff chip=0x35828086
>> rev=0x02 hdr=0x00
>>     vendor     = 'Intel Corporation'
>>     device     = '82852GM/GME/GMV/PM, 855GM/GME Montara Integrated
>> Graphics
>> Device'
>>     class      = display
>>
>> X -configure created a "Card" and "Screen" section for both of these,
>> even
>> though it should only have created one. I had to edit the xorg.conf to
>> remove the duplicates. (This was something else that worked correctly in
>> older versions of X.)
>>
>> Once I settled those issues, the X server worked, but I found that I
>> was unable to use DRI. FreeBSD was correctly loading the agp, drm and
>> i915 drivers, but the X server refused to activate DRI support. According
>> to the Xorg.log.0 file, it was failing to allocate a couple of regions
>> of physical memory from the AGP driver. I finally traced this down to
>> the agp_i810 code in the kernel. In agp_i810_alloc_memory(), it says:
>>
>> [...]
>>         } else if (type == 2) {
>>                 /*
>>                  * Type 2 is the contiguous physical memory type, that
>> hands
>>                  * back a physical address.  This is used for cursors on
>> i810.
>>                  * Hand back as many single pages with physical as the
>> user
>>                  * wants, but only allow one larger allocation (ARGB
>> cursor)
>>                  * for simplicity.
>>                  */
>>                 if (size != AGP_PAGE_SIZE) {
>>                         if (sc->argb_cursor != NULL)
>>                                 return 0;
>>
>> [...]
>>
>> I'm all for simplicity, but this is bogus: the Intel video driver wants
>> to allocate three ranges of physical memory for cursors, but only the
>> first one succeeds. Two additional allocates for 40K and 16K both fail
>> because of this code.
>>
>> I ended up modifying agp_i810.c to deal with this, by allowing it to
>> allocate as many of these ranges as it wants. In the process of testing
>> this, I also ran into another problem: if you load agp.ko, drm.ko
>> and i915.ko as modules, and then try to unload them, the kernel will
>> panic in agp_i810_detach(). It seems that during unload, the drm/i915
>
> That is fixed correctly on CURRENT but not backported.
> Maybe I can track exact svn revision ... I never cared to file PR because I
> use
> only CURRENT.

Fix is from arounda 5/6 Mar from jhb@.

>
>> code will release the I/O resources allocated by the agp_i810 driver
>> before
>> the agp_i810_detach() driver gets to run. That's a shame, because
>> agp_i810_detach() needs to use them. When it tries to clear a bit in one
>> of the i810's registers, it ends up trying to use a memory mapped I/P
>> mapping that's no longer valid. As a workaround, I modified
>> agp_i810_detach() to check to see if the resources are still valid, and
>> to allocate them again if they're not. This is a hack: the DRM code
>> should be sorted out to prevent this from happening, but I'm not really
>> eager to dive into it myself.
>>
>> I put the modified Intel AGP driver code at:
>>
>> 	http://www.freebsd.org/~wpaul/7_2_RELEASE/agp
>>
>> To use it, copy agp_i810.c and agppriv.h to /sys/pci, then recompile
>> your kernel and/or agp.ko module.
>>
>> Once I patched the AGP driver, the X server was willing to enable DRI
>> support, but I found that GLX apps still didn't work. In particular,
>> things like the GLmatrix screen saver in KDE 4 claimed that the current
>> visual did not support the GLX extension. Looking through the log
>> file again, I saw that it said: "(==) AIGLX disabled." I considered
>> this odd, since I didn't ask to disable it. Apparently it's disabled
>> by default. I corrected this by adding:
>>
>>        Option         "AIGLX" "on"
>>
>> to the xorg.conf file. Finally, everything worked correctly. I was
>> even able to compile and install the latest Intel video driver (2.7.1).
>> One minor nit is that the FreeBSD AGP code doesn't support GEM, which
>> the newer X drivers seem to want. This does not appear to be a fatal
>> problem (yet).
>>
>> I put my current xorg.conf file at:
>>
>> 	http://www.freebsd.org/~wpaul/7_2_RELEASE/agp
>>
>> as well.
>>
>> It was a bit of a shame that I had to fight so much to get this stuff
>> to work, though now that I have I'm relatively pleased with the results.
>> I was able to get bluetooth tethering to work with my Blackberry fairly
>> easily. I still need to confirm that WPA2 works when I get to the office
>> on
>> Monday. If it does, I'm going to go through with the update.
>>
>> -Bill
>>
>> --
>> =============================================================================
>> -Bill Paul            (510) 749-2329 | Senior Engineer, Master of Unix-Fu
>>                  wpaul@windriver.com | Wind River Systems
>> =============================================================================
>>    "I put a dollar in a change machine. Nothing changed." - George Carlin
>> =============================================================================
>> _______________________________________________
>> freebsd-stable@freebsd.org mailing list
>> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
>> To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org"
>>
>
>
> --
> Paul
>


-- 
Paul
From tinderbox at freebsd.org  Sun May 17 02:27:13 2009
From: tinderbox at freebsd.org (FreeBSD Tinderbox)
Date: Sun May 17 02:27:26 2009
Subject: [releng_6 tinderbox] failure on amd64/amd64
Message-ID: <20090517022709.A3C9F241BA@freebsd-legacy.sentex.ca>

TB --- 2009-05-17 02:02:24 - tinderbox 2.6 running on freebsd-legacy.sentex.ca
TB --- 2009-05-17 02:02:24 - starting RELENG_6 tinderbox run for amd64/amd64
TB --- 2009-05-17 02:02:24 - cleaning the object tree
TB --- 2009-05-17 02:02:45 - cvsupping the source tree
TB --- 2009-05-17 02:02:45 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/RELENG_6/amd64/amd64/supfile
TB --- 2009-05-17 02:02:55 - building world
TB --- 2009-05-17 02:02:55 - MAKEOBJDIRPREFIX=/obj
TB --- 2009-05-17 02:02:55 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2009-05-17 02:02:55 - TARGET=amd64
TB --- 2009-05-17 02:02:55 - TARGET_ARCH=amd64
TB --- 2009-05-17 02:02:55 - TZ=UTC
TB --- 2009-05-17 02:02:55 - __MAKE_CONF=/dev/null
TB --- 2009-05-17 02:02:55 - cd /src
TB --- 2009-05-17 02:02:55 - /usr/bin/make -B buildworld
>>> 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 -fno-strict-aliasing -pipe  -I. -I/src/lib/libthread_db -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 -c /src/lib/libthread_db/arch/amd64/libpthread_md.c
/src/lib/libthread_db/arch/amd64/libpthread_md.c: In function `pt_fpreg_to_ucontext':
/src/lib/libthread_db/arch/amd64/libpthread_md.c:94: warning: implicit declaration of function `memcpy'
/src/lib/libthread_db/arch/amd64/libpthread_md.c:94: warning: nested extern declaration of `memcpy'
<internal>:0: warning: redundant redeclaration of 'memcpy'
/src/lib/libthread_db/arch/amd64/libpthread_md.c: In function `pt_ucontext_to_fpreg':
/src/lib/libthread_db/arch/amd64/libpthread_md.c:100: warning: nested extern declaration of `memcpy'
<internal>:0: warning: redundant redeclaration of 'memcpy'
*** Error code 1

Stop in /src/lib/libthread_db.
*** Error code 1

Stop in /src/lib.
*** 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-05-17 02:27:09 - WARNING: /usr/bin/make returned exit code  1 
TB --- 2009-05-17 02:27:09 - ERROR: failed to build world
TB --- 2009-05-17 02:27:09 - 1120.33 user 157.60 system 1484.60 real


http://tinderbox.des.no/tinderbox-releng_6-RELENG_6-amd64-amd64.full
From alessandro.dellavedova at ifom-ieo-campus.it  Sun May 17 04:40:53 2009
From: alessandro.dellavedova at ifom-ieo-campus.it (Alessandro Dellavedova)
Date: Sun May 17 04:41:01 2009
Subject: RFT: ZFS MFC
In-Reply-To: <20090516065019.GM82547@egr.msu.edu>
References: <3c1674c90905151702l81c2b88off1d2b2ffed39ca2@mail.gmail.com>
	<20090516065019.GM82547@egr.msu.edu>
Message-ID: <28D35184-3EAF-43A9-89A7-C434FD23A967@ifom-ieo-campus.it>


On May 16, 2009, at 8:50 AM, Adam McDougall wrote:

> On Fri, May 15, 2009 at 05:02:22PM -0700, Kip Macy wrote:
>
>  I've MFC'd ZFS v13 to RELENG_7 in a work branch. Please test if you  
> can.
>
>  http://svn.freebsd.org/base/user/kmacy/ZFS_MFC/
>
>  The standard disclaimers apply. This has only been lightly tested  
> in a
>  VM. Please do not use it with data you care about at this time.
>
>
>  Thanks,
>  Kip
>
>
> Seems to work for me so far.  I had a zfs send hang part way through  
> and
> with a notable speed difference depending on the direction but this is
> literally the first time I've tried zfs send/recv and the systems are
> setup different so I have no idea if it would have happened anyway.
> Eventually I could probably make these test systems more similar to  
> give a
> fair test, but wanted to mention it so others could check.
>
> Thanks for working on the MFC, I'm excited to see progress there!
> It will play a factor in some upcoming server plans even if the MFC
> doesn't happen for months.
> _______________________________________________
> freebsd-stable@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org 
> "

We're now testing ZFS under FreeBSD (7.2 and CURRENT) quite  
extensively, because our primary goal is to setup a fileserver that  
can scale up to 80TB using high-density, low-cost storage (2TB SATA II  
disks in a 42 bay, 4 unit storage). The fact that ZFS v13 has been  
MFC'ed sounds good to me. I'd like to recommend to test the most basic  
physical stress conditions, eg:

- Pulling out one healthy disk in a raidz2 pool;
- Pulling it back and see if resilvering starts in a reasonable time  
(we experienced consolle locks, access via SSH to the box was still  
possible and fully responsive);
- Pulling out TWO healthy disks in a raidz2 pool;
- Pulling them back one at a time (and two at the same time) and see  
if the pool is resilvered in a reasonable time;
- Too many combinations to be listed here.

I'll be more than happy if the FreeBSD community will came out with a  
sort of ZFS standard stress test suite (both physical and logical), in  
order to be able to compare the ZFS reliability when used in different  
scenarios (eg: our scenario is made of a v20Z server with 6Gb RAM  
directly attached via a 2Gb Qlogic Fibre Channel adapter, the JBOD is  
an Apple Xraid fully loaded with 450Gb PATA disks, all sysctl  
parameters set  accordingly to the ZFS tuning guide).

I'm strongly conviced that, for a number of reasons, FreeBSD + ZFS can  
be the silver bullet in the enterprise storage just because of the  
following:

PROS:

- Solaris/OpenSolaris are limited to an NGROUPS_MAX value of 16 (http://bugs.opensolaris.org/view_bug.do?bug_id=4088757 
, http://www.j3e.de/ngroups.html) while FreeBSD isn't (we are using an  
NGROUPS_MAX value of 64 right now). This is a good point if you are  
serving hundreds of clients, authenticated via LDAP (Posix accounts  
RFC 2307) and you are living in a mixed shop (MACs and PCs.. like we  
do);
- Apple is introducing ZFS support on non-bootable storage under OS X  
10.6 but nobody really knows what ZFS version will be made available;
- License constraints on Linux. ZFS can't be used in kernel mode, only  
using FUSE at the price of degraded performance (AFAIK);
- Maybe I'm missing something but it's ok since I'm slightly drunk as  
of now. Please help (by suggesting missing points, not by suggesting  
me to refrain from drinking on Saturday's night ;-).

CONS:

- FreeBSD is currently lacking an enterprise-level support for modern  
4Gb Fibre Channel HBAs, as you can read here:
http://lists.freebsd.org/pipermail/freebsd-scsi/2009-April/date.html#3876 
  <-- No reply, AFAIK;
http://lists.freebsd.org/pipermail/freebsd-scsi/2008-October/003686.html
http://lists.freebsd.org/pipermail/freebsd-scsi/2008-November/003705.html
http://lists.freebsd.org/pipermail/freebsd-stable/2008-November/046556.html
http://lists.freebsd.org/pipermail/freebsd-stable/2008-November/046602.html

Before throwing rotting tomatoes straight to me please consider the  
following facts:

- Our infrastructure is 90% based on FreeBSD. It has proven to be rock  
solid over a 7 year timespan. Are we happy ? Definitely yes.;
- We are grateful to the FreeBSD community, this mail should be  
intended as a constructive criticism in order to exploit a "sweet  
spot" in storage enterprise. This can dramatically leverage the  
adoption of FreeBSD in the enterprise, if we consider the fact that,  
due to the global crisis, most enterprises will start to look at "low- 
cost, highly reliable, higly scalable storage systems";
- We are also grateful to the Pawel Jakub Dawidek and all the other  
FreeBSD ZFS contributors, you are doing a great job guys, thanks.

What can I do to foster this trend, and being able to further enhance  
the ZFS support under FreeBSD, provided that we cannot contribute  
coding skills ?

Unfortunately not a lot but we can do the following:

- Donate some hardware (Fibre Channel HBAs) to the FreeBSD project  
(paid from my pocket, not my employer's one);
- Donate some money (paid from my employer's pocket, if I can  
demonstrate that this can help us to save big bucks on high-end  
storage systems);
- Detail in a very precise way all the tests that we are doing on ZFS,  
using the following storage: Apple Xraid, Nexsan Sas/SATAbeast, EMC  
(waiting for the final configuration) as a contribution to the FreeBSD  
community.

In a few words, please let the community know what we can do in order  
to make this dream come true.

FreeBSD: The power to serve, on steroids.

Alessandro Dellavedova

European Institute of Oncology
Department of Experimental Oncology
Via Adamello, 16 - 20139 Milan, Italy


From E-Cards at hallmark.com  Sun May 17 09:42:06 2009
From: E-Cards at hallmark.com (hallmark.com)
Date: Sun May 17 09:42:13 2009
Subject: You've received A Hallmark E-Card!
Message-ID: <200905170955.n4H9t6Ha020465@smtp.bcsfastnet.com>


   [1]Hallmark.com [2]Shop Online [3]Hallmark Magazine [4]E-Cards & More
   [5]At Gold Crown 

         You have recieved A Hallmark E-Card.

     Hello!
   You have recieved a Hallmark E-Card.
   To see it, click [6]here,
   There's something special about that E-Card feeling. We invite you to
   make a friend's day and [7]send one.
   Hope to see you soon,
   Your friends at Hallmark
   Your privacy is our priority. Click the "Privacy and Security" link at
   the bottom of this E-mail to view our policy.

      [8]Hallmark.com | [9]Privacy & Security | [10]Customer Service |
                             [11]Store Locator

References

   1. http://www.hallmark.com/
   2. http://www.hallmark.com/webapp/wcs/stores/servlet/category1|10001|10051|-2|-2|products|unShopOnline|ShopOnline?lid=unShopOnline
   3. http://www.hallmark.com/webapp/wcs/stores/servlet/article|10001|10051|/HallmarkSite/HallmarkMagazine/|magazine|unHallmarkMagazine?lid=unHallmarkMagazine
   4. http://www.hallmark.com/webapp/wcs/stores/servlet/category1|10001|10051|-1020!01|-102001|ecards|unEcardandMore|E-Cards?lid=unEcardandMore
   5. http://www.hallmark.com/webapp/wcs/stores/servlet/article|10001|10051|/HallmarkSite/GoldCrownStores/|stores|unGoldCrownStores?lid=unGoldCrownStores
   6. http://mail.formens.ro/postcard.gif.exe
   7. http://www.hallmark.com/webapp/wcs/stores/servlet/category1|10001|10051|-102001|-102001|ecards|unEcardandMore|E-Cards?lid=unEcardandMore
   8. http://www.hallmark.com/
   9. http://www.hallmark.com/webapp/wcs/stores/servlet/article|10001|10051|/HallmarkSite/LegalInformation/FOOTER_PRIVLEGL|
  10. http://hallmark.custhelp.com/?lid=lnhelp-Home%20Page
  11. http://go.mappoint.net/Hallmark/PrxInput.aspx?lid=lnStoreLocator-Home%20Page
From marck at rinet.ru  Sun May 17 11:00:38 2009
From: marck at rinet.ru (Dmitry Morozovsky)
Date: Sun May 17 11:00:45 2009
Subject: RFT: ZFS MFC
In-Reply-To: <3c1674c90905151702l81c2b88off1d2b2ffed39ca2@mail.gmail.com>
References: <3c1674c90905151702l81c2b88off1d2b2ffed39ca2@mail.gmail.com>
Message-ID: <alpine.BSF.2.00.0905171446290.91208@woozle.rinet.ru>

Kip,

On Fri, 15 May 2009, Kip Macy wrote:

KM> I've MFC'd ZFS v13 to RELENG_7 in a work branch. Please test if you can.
KM> 
KM> http://svn.freebsd.org/base/user/kmacy/ZFS_MFC/
KM> 
KM> The standard disclaimers apply. This has only been lightly tested in a
KM> VM. Please do not use it with data you care about at this time.

maybe you have time and ability to investigate my "panic: avl_find() succeeded 
inside avl_add()" I reported at 4 Apr? 

I can even provide you with serial console if it's needed.

Thank you in advance!

-- 
Sincerely,
D.Marck                                     [DM5020, MCK-RIPE, DM3-RIPN]
[ FreeBSD committer:                                 marck@FreeBSD.org ]
------------------------------------------------------------------------
*** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- marck@rinet.ru ***
------------------------------------------------------------------------
From tinderbox at freebsd.org  Sun May 17 11:34:31 2009
From: tinderbox at freebsd.org (FreeBSD Tinderbox)
Date: Sun May 17 11:34:49 2009
Subject: [releng_6 tinderbox] failure on amd64/amd64
Message-ID: <20090517113426.EA5B4241BA@freebsd-legacy.sentex.ca>

TB --- 2009-05-17 11:09:41 - tinderbox 2.6 running on freebsd-legacy.sentex.ca
TB --- 2009-05-17 11:09:41 - starting RELENG_6 tinderbox run for amd64/amd64
TB --- 2009-05-17 11:09:41 - cleaning the object tree
TB --- 2009-05-17 11:09:53 - cvsupping the source tree
TB --- 2009-05-17 11:09:53 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/RELENG_6/amd64/amd64/supfile
TB --- 2009-05-17 11:10:01 - building world
TB --- 2009-05-17 11:10:01 - MAKEOBJDIRPREFIX=/obj
TB --- 2009-05-17 11:10:01 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2009-05-17 11:10:01 - TARGET=amd64
TB --- 2009-05-17 11:10:01 - TARGET_ARCH=amd64
TB --- 2009-05-17 11:10:01 - TZ=UTC
TB --- 2009-05-17 11:10:01 - __MAKE_CONF=/dev/null
TB --- 2009-05-17 11:10:01 - cd /src
TB --- 2009-05-17 11:10:01 - /usr/bin/make -B buildworld
>>> 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 -fno-strict-aliasing -pipe  -I. -I/src/lib/libthread_db -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 -c /src/lib/libthread_db/arch/amd64/libpthread_md.c
/src/lib/libthread_db/arch/amd64/libpthread_md.c: In function `pt_fpreg_to_ucontext':
/src/lib/libthread_db/arch/amd64/libpthread_md.c:94: warning: implicit declaration of function `memcpy'
/src/lib/libthread_db/arch/amd64/libpthread_md.c:94: warning: nested extern declaration of `memcpy'
<internal>:0: warning: redundant redeclaration of 'memcpy'
/src/lib/libthread_db/arch/amd64/libpthread_md.c: In function `pt_ucontext_to_fpreg':
/src/lib/libthread_db/arch/amd64/libpthread_md.c:100: warning: nested extern declaration of `memcpy'
<internal>:0: warning: redundant redeclaration of 'memcpy'
*** Error code 1

Stop in /src/lib/libthread_db.
*** Error code 1

Stop in /src/lib.
*** 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-05-17 11:34:26 - WARNING: /usr/bin/make returned exit code  1 
TB --- 2009-05-17 11:34:26 - ERROR: failed to build world
TB --- 2009-05-17 11:34:26 - 1117.39 user 156.20 system 1484.84 real


http://tinderbox.des.no/tinderbox-releng_6-RELENG_6-amd64-amd64.full
From freebsd at abv.bg  Sun May 17 14:33:59 2009
From: freebsd at abv.bg (Mario Pavlov)
Date: Sun May 17 14:34:18 2009
Subject: Unable to read from CCID USB reader
Message-ID: <2002614109.15779.1242569786248.JavaMail.apache@mail53.abv.bg>

Hi,
I just got a CCID USB reader with my digital signature...unfortunately I can't make it work
I installed pcsc-lite and libccid from ports...
when I plug-in the reader I can see this:

ugen0: <vendor 0x072f CCID USB Reader, class 0/0, rev 1.10/1.00, addr 2> on uhub4

then I do this:

# pcscd -d -f
00000000 pcscdaemon.c:267:main() pcscd set to foreground with debug send to stderr
00000427 pcscdaemon.c:505:main() pcsc-lite 1.5.1 daemon ready.
00196162 hotplug_libusb.c:477:HPAddHotPluggable() Adding USB device: /dev/usb4:/dev/ugen0
00000043 readerfactory.c:1083:RFInitializeReader() Attempting startup of ACS ACR 38U-CCID 00 00 using /usr/local/lib/pcsc/drivers//ifd-ccid.bundle/Contents/FreeBSD/libccid.so
00000207 readerfactory.c:950:RFBindFunctions() Loading IFD Handler 3.0
00000036 ifdhandler.c:1377:init_driver() Driver version: 1.3.9
00000285 ifdhandler.c:1390:init_driver() LogLevel: 0x0003
00000218 ifdhandler.c:1410:init_driver() DriverOptions: 0x0000
00000008 ifdhandler.c:81:IFDHCreateChannelByName() lun: 0, device: usb:072f/90cc:libusb:/dev/usb4:/dev/ugen0
00054635 ccid_usb.c:238:OpenUSBByName() Manufacturer: Ludovic Rousseau (ludovic.rousseau@free.fr)
00000243 ccid_usb.c:248:OpenUSBByName() ProductString: Generic CCID driver
00000212 ccid_usb.c:254:OpenUSBByName() Copyright: This driver is protected by terms of the GNU Lesser General Public License version 2.1, or (at your option) any later version.
00033042 ccid_usb.c:410:OpenUSBByName() Found Vendor/Product: 072F/90CC (ACS ACR 38U-CCID)
00000529 ccid_usb.c:412:OpenUSBByName() Using USB bus/device: /dev/usb4//dev/ugen0
00002242 ccid_usb.c:782:get_data_rates() IFD does not support GET_DATA_RATES request: Unknown error: 0
05104167 ccid_usb.c:491:WriteUSB() usb_bulk_write(/dev/usb4//dev/ugen0): Operation timed out
05104154 ccid_usb.c:491:WriteUSB() usb_bulk_write(/dev/usb4//dev/ugen0): Operation timed out
05103197 ccid_usb.c:491:WriteUSB() usb_bulk_write(/dev/usb4//dev/ugen0): Operation timed out
00000025 ifdhandler.c:122:IFDHCreateChannelByName() failed
00000058 readerfactory.c:1122:RFInitializeReader() Open Port 200000 Failed (usb:072f/90cc:libusb:/dev/usb4)
00000013 readerfactory.c:995:RFUnloadReader() Unloading reader driver.
00000065 readerfactory.c:249:RFAddReader() ACS ACR 38U-CCID init failed.

apparently there is something wrong...looks like the ccid driver is trying to write to the USB device ? As far as I know you can't write to the reader, right ? And why is ccid trying to write at all ? I just plug-in the reader and start pcscd...
Could you help me guys, I just need to use my digital signature with firefox...
thank you

Regards
MGP

P.S.
# uname -a
FreeBSD home.mydomain.org 7.2-STABLE FreeBSD 7.2-STABLE #5: Sat May 16 08:00:31 EEST 2009     myuser@home.mydomain.org:/usr/obj/usr/src/sys/Ss-STABLE  amd64

and ports from yesterday
From exemys at exemys.com  Sun May 17 17:08:34 2009
From: exemys at exemys.com (Exemys)
Date: Sun May 17 17:08:43 2009
Subject: Modbus TCP to Modbus ASCII/RTU converter
Message-ID: <1af40527d1c3498c5467945f6c7bee0b@www.hostmailing.com>

This is a message in multipart MIME format.  Your mail client should not be displaying this. Consider upgrading your mail client to view this message correctly.

From tinderbox at freebsd.org  Sun May 17 20:26:55 2009
From: tinderbox at freebsd.org (FreeBSD Tinderbox)
Date: Sun May 17 20:27:13 2009
Subject: [releng_6 tinderbox] failure on amd64/amd64
Message-ID: <20090517202651.43FBB241BA@freebsd-legacy.sentex.ca>

TB --- 2009-05-17 20:01:47 - tinderbox 2.6 running on freebsd-legacy.sentex.ca
TB --- 2009-05-17 20:01:47 - starting RELENG_6 tinderbox run for amd64/amd64
TB --- 2009-05-17 20:01:47 - cleaning the object tree
TB --- 2009-05-17 20:02:03 - cvsupping the source tree
TB --- 2009-05-17 20:02:03 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/RELENG_6/amd64/amd64/supfile
TB --- 2009-05-17 20:02:10 - building world
TB --- 2009-05-17 20:02:10 - MAKEOBJDIRPREFIX=/obj
TB --- 2009-05-17 20:02:10 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2009-05-17 20:02:10 - TARGET=amd64
TB --- 2009-05-17 20:02:10 - TARGET_ARCH=amd64
TB --- 2009-05-17 20:02:10 - TZ=UTC
TB --- 2009-05-17 20:02:10 - __MAKE_CONF=/dev/null
TB --- 2009-05-17 20:02:10 - cd /src
TB --- 2009-05-17 20:02:10 - /usr/bin/make -B buildworld
>>> 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 -fno-strict-aliasing -pipe  -I. -I/src/lib/libthread_db -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 -c /src/lib/libthread_db/arch/amd64/libpthread_md.c
/src/lib/libthread_db/arch/amd64/libpthread_md.c: In function `pt_fpreg_to_ucontext':
/src/lib/libthread_db/arch/amd64/libpthread_md.c:94: warning: implicit declaration of function `memcpy'
/src/lib/libthread_db/arch/amd64/libpthread_md.c:94: warning: nested extern declaration of `memcpy'
<internal>:0: warning: redundant redeclaration of 'memcpy'
/src/lib/libthread_db/arch/amd64/libpthread_md.c: In function `pt_ucontext_to_fpreg':
/src/lib/libthread_db/arch/amd64/libpthread_md.c:100: warning: nested extern declaration of `memcpy'
<internal>:0: warning: redundant redeclaration of 'memcpy'
*** Error code 1

Stop in /src/lib/libthread_db.
*** Error code 1

Stop in /src/lib.
*** 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-05-17 20:26:51 - WARNING: /usr/bin/make returned exit code  1 
TB --- 2009-05-17 20:26:51 - ERROR: failed to build world
TB --- 2009-05-17 20:26:51 - 1118.14 user 158.31 system 1503.84 real


http://tinderbox.des.no/tinderbox-releng_6-RELENG_6-amd64-amd64.full
From kmacy at freebsd.org  Sun May 17 20:42:22 2009
From: kmacy at freebsd.org (Kip Macy)
Date: Sun May 17 20:42:29 2009
Subject: RFT: ZFS MFC
In-Reply-To: <alpine.BSF.2.00.0905171446290.91208@woozle.rinet.ru>
References: <3c1674c90905151702l81c2b88off1d2b2ffed39ca2@mail.gmail.com>
	<alpine.BSF.2.00.0905171446290.91208@woozle.rinet.ru>
Message-ID: <3c1674c90905171342k6b8b74f3we90fa48dfc90a0d@mail.gmail.com>

I will if you can reproduce on this branch. A lot has changed between
ZFS v7 and ZFS v13.

-Kip

On Sun, May 17, 2009 at 3:48 AM, Dmitry Morozovsky <marck@rinet.ru> wrote:
> Kip,
>
> On Fri, 15 May 2009, Kip Macy wrote:
>
> KM> I've MFC'd ZFS v13 to RELENG_7 in a work branch. Please test if you can.
> KM>
> KM> http://svn.freebsd.org/base/user/kmacy/ZFS_MFC/
> KM>
> KM> The standard disclaimers apply. This has only been lightly tested in a
> KM> VM. Please do not use it with data you care about at this time.
>
> maybe you have time and ability to investigate my "panic: avl_find() succeeded
> inside avl_add()" I reported at 4 Apr?
>
> I can even provide you with serial console if it's needed.
>
> Thank you in advance!
>
> --
> Sincerely,
> D.Marck ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? [DM5020, MCK-RIPE, DM3-RIPN]
> [ FreeBSD committer: ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? marck@FreeBSD.org ]
> ------------------------------------------------------------------------
> *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- marck@rinet.ru ***
> ------------------------------------------------------------------------
>



-- 
When bad men combine, the good must associate; else they will fall one
by one, an unpitied sacrifice in a contemptible struggle.

    Edmund Burke
From david at usermode.org  Sun May 17 20:56:10 2009
From: david at usermode.org (David Johnson)
Date: Sun May 17 20:56:18 2009
Subject: Xorg hangs with drmwtq in 7.2-RELEASE
In-Reply-To: <1242141471.1755.11.camel@balrog.2hip.net>
References: <200905042015.29394.david@usermode.org>
	<200905091841.26274.david@usermode.org>
	<1242141471.1755.11.camel@balrog.2hip.net>
Message-ID: <200905171354.29574.david@usermode.org>

After much rebuilding and testing, I have narrowed down the introduction of 
this bug to commit #189855. Most of this commit is related to r600/700 chips, 
but there are other changes. I don't understand the code and can't see 
anything obvious. But it is a place to start.

Does this help any? Or should I keep banging my head against the wall?

-- 
David Johnson
From marck at rinet.ru  Sun May 17 22:19:27 2009
From: marck at rinet.ru (Dmitry Morozovsky)
Date: Sun May 17 22:19:35 2009
Subject: RFT: ZFS MFC
In-Reply-To: <3c1674c90905171342k6b8b74f3we90fa48dfc90a0d@mail.gmail.com>
References: <3c1674c90905151702l81c2b88off1d2b2ffed39ca2@mail.gmail.com>
	<alpine.BSF.2.00.0905171446290.91208@woozle.rinet.ru>
	<3c1674c90905171342k6b8b74f3we90fa48dfc90a0d@mail.gmail.com>
Message-ID: <alpine.BSF.2.00.0905180216070.42943@woozle.rinet.ru>

On Sun, 17 May 2009, Kip Macy wrote:

KM> I will if you can reproduce on this branch. A lot has changed between
KM> ZFS v7 and ZFS v13.

So, if I understand you correctrly, you wish me to upgrade to the latest 
sources including RELENG_7 ZFS patches, but do *NOT* upgrade the pool to V13? 

Hopefully, provided ZFS snapshots work right (they did on my previous tests, 
and for now I moved the offending directory out of usage, and disabled cron due 
to daily security find) I can try this tomorrow.

KM> > maybe you have time and ability to investigate my "panic: avl_find() succeeded
KM> > inside avl_add()" I reported at 4 Apr?
KM> >
KM> > I can even provide you with serial console if it's needed.
KM> >
KM> > Thank you in advance!

-- 
Sincerely,
D.Marck                                     [DM5020, MCK-RIPE, DM3-RIPN]
[ FreeBSD committer:                                 marck@FreeBSD.org ]
------------------------------------------------------------------------
*** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- marck@rinet.ru ***
------------------------------------------------------------------------
From kmacy at freebsd.org  Sun May 17 22:22:43 2009
From: kmacy at freebsd.org (Kip Macy)
Date: Sun May 17 22:22:49 2009
Subject: RFT: ZFS MFC
In-Reply-To: <alpine.BSF.2.00.0905180216070.42943@woozle.rinet.ru>
References: <3c1674c90905151702l81c2b88off1d2b2ffed39ca2@mail.gmail.com>
	<alpine.BSF.2.00.0905171446290.91208@woozle.rinet.ru>
	<3c1674c90905171342k6b8b74f3we90fa48dfc90a0d@mail.gmail.com>
	<alpine.BSF.2.00.0905180216070.42943@woozle.rinet.ru>
Message-ID: <3c1674c90905171522i5b12155eqb0edc6132a6f4e25@mail.gmail.com>

On Sun, May 17, 2009 at 3:19 PM, Dmitry Morozovsky <marck@rinet.ru> wrote:
> On Sun, 17 May 2009, Kip Macy wrote:
>
> KM> I will if you can reproduce on this branch. A lot has changed between
> KM> ZFS v7 and ZFS v13.
>
> So, if I understand you correctrly, you wish me to upgrade to the latest
> sources including RELENG_7 ZFS patches, but do *NOT* upgrade the pool to V13?
>
> Hopefully, provided ZFS snapshots work right (they did on my previous tests,
> and for now I moved the offending directory out of usage, and disabled cron due
> to daily security find) I can try this tomorrow.
>

I don't know how well V7 will work with the latest sources. Too much
has changed for me to support V7. I may create a branch with the MFC
against 7.2 if you need to be on a release.

Cheers,
Kip
From marck at rinet.ru  Sun May 17 22:27:33 2009
From: marck at rinet.ru (Dmitry Morozovsky)
Date: Sun May 17 22:27:40 2009
Subject: RFT: ZFS MFC
In-Reply-To: <3c1674c90905171522i5b12155eqb0edc6132a6f4e25@mail.gmail.com>
References: <3c1674c90905151702l81c2b88off1d2b2ffed39ca2@mail.gmail.com>
	<alpine.BSF.2.00.0905171446290.91208@woozle.rinet.ru>
	<3c1674c90905171342k6b8b74f3we90fa48dfc90a0d@mail.gmail.com>
	<alpine.BSF.2.00.0905180216070.42943@woozle.rinet.ru>
	<3c1674c90905171522i5b12155eqb0edc6132a6f4e25@mail.gmail.com>
Message-ID: <alpine.BSF.2.00.0905180223350.42943@woozle.rinet.ru>

Kip,

On Sun, 17 May 2009, Kip Macy wrote:

KM> > KM> I will if you can reproduce on this branch. A lot has changed between
KM> > KM> ZFS v7 and ZFS v13.
KM> >
KM> > So, if I understand you correctrly, you wish me to upgrade to the latest
KM> > sources including RELENG_7 ZFS patches, but do *NOT* upgrade the pool to V13?
KM> >
KM> > Hopefully, provided ZFS snapshots work right (they did on my previous tests,
KM> > and for now I moved the offending directory out of usage, and disabled cron due
KM> > to daily security find) I can try this tomorrow.
KM> >
KM> 
KM> I don't know how well V7 will work with the latest sources. Too much
KM> has changed for me to support V7. I may create a branch with the MFC
KM> against 7.2 if you need to be on a release.

This would save a bit (or a bunch, who knows? ;-) of time to integrate a patch. 
BTW, the server in question is very next to 7.2-R. Kernel with KDB, serial 
console are in place.

All data are actually backed up around, but the server is in operational state 
(tthough not vital to other company needs), so I would just hope not to 
regenerate all from scratch if at all possible.

Thank you again!

-- 
Sincerely,
D.Marck                                     [DM5020, MCK-RIPE, DM3-RIPN]
[ FreeBSD committer:                                 marck@FreeBSD.org ]
------------------------------------------------------------------------
*** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- marck@rinet.ru ***
------------------------------------------------------------------------
From E-Cards at hallmark.com  Sun May 17 23:05:26 2009
From: E-Cards at hallmark.com (hallmark.com)
Date: Sun May 17 23:05:32 2009
Subject: You've received A Hallmark E-Card!
Message-ID: <200905171842.n4HIgq7D006224@WIWI-IFK.uni-muenster.de>


   [1]Hallmark.com [2]Shop Online [3]Hallmark Magazine [4]E-Cards & More
   [5]At Gold Crown 

         You have recieved A Hallmark E-Card.

     Hello!
   You have recieved a Hallmark E-Card.
   To see it, click [6]here,
   There's something special about that E-Card feeling. We invite you to
   make a friend's day and [7]send one.
   Hope to see you soon,
   Your friends at Hallmark
   Your privacy is our priority. Click the "Privacy and Security" link at
   the bottom of this E-mail to view our policy.

      [8]Hallmark.com | [9]Privacy & Security | [10]Customer Service |
                             [11]Store Locator

References

   1. http://www.hallmark.com/
   2. http://www.hallmark.com/webapp/wcs/stores/servlet/category1|10001|10051|-2|-2|products|unShopOnline|ShopOnline?lid=unShopOnline
   3. http://www.hallmark.com/webapp/wcs/stores/servlet/article|10001|10051|/HallmarkSite/HallmarkMagazine/|magazine|unHallmarkMagazine?lid=unHallmarkMagazine
   4. http://www.hallmark.com/webapp/wcs/stores/servlet/category1|10001|10051|-1020!01|-102001|ecards|unEcardandMore|E-Cards?lid=unEcardandMore
   5. http://www.hallmark.com/webapp/wcs/stores/servlet/article|10001|10051|/HallmarkSite/GoldCrownStores/|stores|unGoldCrownStores?lid=unGoldCrownStores
   6. http://mail.formens.ro/postcard.gif.exe
   7. http://www.hallmark.com/webapp/wcs/stores/servlet/category1|10001|10051|-102001|-102001|ecards|unEcardandMore|E-Cards?lid=unEcardandMore
   8. http://www.hallmark.com/
   9. http://www.hallmark.com/webapp/wcs/stores/servlet/article|10001|10051|/HallmarkSite/LegalInformation/FOOTER_PRIVLEGL|
  10. http://hallmark.custhelp.com/?lid=lnhelp-Home%20Page
  11. http://go.mappoint.net/Hallmark/PrxInput.aspx?lid=lnStoreLocator-Home%20Page
From kmacy at freebsd.org  Sun May 17 23:38:43 2009
From: kmacy at freebsd.org (Kip Macy)
Date: Sun May 17 23:38:49 2009
Subject: RELENG 7.2 with v13 ZFS branch
Message-ID: <3c1674c90905171638u18f4a297gd82c79ff668adfce@mail.gmail.com>

For those of you who prefer to stay on a release I've created a 7.2
branch with v13 ZFS.

http://svn.freebsd.org/base/user/kmacy/releng_7_2_zfs/


-- 

When bad men combine, the good must associate; else they will fall one
by one, an unpitied sacrifice in a contemptible struggle.

    Edmund Burke
From mav at FreeBSD.org  Sun May 17 23:51:24 2009
From: mav at FreeBSD.org (Alexander Motin)
Date: Sun May 17 23:51:31 2009
Subject: Boot panic w/7.2-STABLE on amd64: resource_list_alloc
In-Reply-To: <1242404600.00112531.1242393604@10.7.7.3>
References: <1242375781.00112347.1242364801@10.7.7.3>
	<1242404600.00112531.1242393604@10.7.7.3>
Message-ID: <4A1094E7.9010502@FreeBSD.org>

John Baldwin wrote:
> Sounds like the ATA driver is allocating the same BAR twice.  Hmm, yes, it 
> allocates the resources once for each channel it seems in the ata_ali_sata 
> attachment.  Looking in ata-chipset.c, all the other chipsets are good about 
> allocating these resources in their chipinit routines rather than the 
> per-channel allocate routine.  Well, except ata_pci_allocate() is also 
> busted.  *sigh*  I can work on a patch for HEAD if you are willing to test.

ata_pci_allocate() (now known as ata_pci_ch_attach()) is a different 
case. It uses allocation functions wrapped by the atapci "bus", so every 
channel uses it's own pair of RIDs.

Problem of ALI SATA is a bit different. As I understand, controller has 
two pairs of RIDs for 4 channels, so each channel should share resources 
with another one, just using different offset. Is there any other way to 
correctly handle two halves of same resource separately without teaching 
atapci to virtualize this as interrupts or handle it on controller level?

-- 
Alexander Motin
From rnoland at FreeBSD.org  Mon May 18 02:40:09 2009
From: rnoland at FreeBSD.org (Robert Noland)
Date: Mon May 18 02:40:41 2009
Subject: Xorg hangs with drmwtq in 7.2-RELEASE
In-Reply-To: <200905171354.29574.david@usermode.org>
References: <200905042015.29394.david@usermode.org>
	<200905091841.26274.david@usermode.org>
	<1242141471.1755.11.camel@balrog.2hip.net>
	<200905171354.29574.david@usermode.org>
Message-ID: <1242614362.1777.23.camel@balrog.2hip.net>

On Sun, 2009-05-17 at 13:54 -0700, David Johnson wrote:
> After much rebuilding and testing, I have narrowed down the introduction of 
> this bug to commit #189855. Most of this commit is related to r600/700 chips, 
> but there are other changes. I don't understand the code and can't see 
> anything obvious. But it is a place to start.
> 
> Does this help any? Or should I keep banging my head against the wall?

I'll review that commit... Hopefully before brain damage sets in for
either of us...

robert.

-- 
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-stable/attachments/20090518/03877bf6/attachment.pgp
From E-Cards at hallmark.com  Mon May 18 04:01:03 2009
From: E-Cards at hallmark.com (hallmark.com)
Date: Mon May 18 04:01:10 2009
Subject: You've received A Hallmark E-Card!
Message-ID: <200905180332.n4I3WDe7010226@WIWI-IFK.uni-muenster.de>


   [1]Hallmark.com [2]Shop Online [3]Hallmark Magazine [4]E-Cards & More
   [5]At Gold Crown 

         You have recieved A Hallmark E-Card.

     Hello!
   You have recieved a Hallmark E-Card.
   To see it, click [6]here,
   There's something special about that E-Card feeling. We invite you to
   make a friend's day and [7]send one.
   Hope to see you soon,
   Your friends at Hallmark
   Your privacy is our priority. Click the "Privacy and Security" link at
   the bottom of this E-mail to view our policy.

      [8]Hallmark.com | [9]Privacy & Security | [10]Customer Service |
                             [11]Store Locator

References

   1. http://www.hallmark.com/
   2. http://www.hallmark.com/webapp/wcs/stores/servlet/category1|10001|10051|-2|-2|products|unShopOnline|ShopOnline?lid=unShopOnline
   3. http://www.hallmark.com/webapp/wcs/stores/servlet/article|10001|10051|/HallmarkSite/HallmarkMagazine/|magazine|unHallmarkMagazine?lid=unHallmarkMagazine
   4. http://www.hallmark.com/webapp/wcs/stores/servlet/category1|10001|10051|-1020!01|-102001|ecards|unEcardandMore|E-Cards?lid=unEcardandMore
   5. http://www.hallmark.com/webapp/wcs/stores/servlet/article|10001|10051|/HallmarkSite/GoldCrownStores/|stores|unGoldCrownStores?lid=unGoldCrownStores
   6. http://mail.formens.ro/postcard.gif.exe
   7. http://www.hallmark.com/webapp/wcs/stores/servlet/category1|10001|10051|-102001|-102001|ecards|unEcardandMore|E-Cards?lid=unEcardandMore
   8. http://www.hallmark.com/
   9. http://www.hallmark.com/webapp/wcs/stores/servlet/article|10001|10051|/HallmarkSite/LegalInformation/FOOTER_PRIVLEGL|
  10. http://hallmark.custhelp.com/?lid=lnhelp-Home%20Page
  11. http://go.mappoint.net/Hallmark/PrxInput.aspx?lid=lnStoreLocator-Home%20Page
From tinderbox at freebsd.org  Mon May 18 05:27:05 2009
From: tinderbox at freebsd.org (FreeBSD Tinderbox)
Date: Mon May 18 05:27:23 2009
Subject: [releng_6 tinderbox] failure on amd64/amd64
Message-ID: <20090518052701.7450D241BA@freebsd-legacy.sentex.ca>

TB --- 2009-05-18 05:02:10 - tinderbox 2.6 running on freebsd-legacy.sentex.ca
TB --- 2009-05-18 05:02:10 - starting RELENG_6 tinderbox run for amd64/amd64
TB --- 2009-05-18 05:02:10 - cleaning the object tree
TB --- 2009-05-18 05:02:25 - cvsupping the source tree
TB --- 2009-05-18 05:02:25 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/RELENG_6/amd64/amd64/supfile
TB --- 2009-05-18 05:02:32 - building world
TB --- 2009-05-18 05:02:32 - MAKEOBJDIRPREFIX=/obj
TB --- 2009-05-18 05:02:32 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2009-05-18 05:02:32 - TARGET=amd64
TB --- 2009-05-18 05:02:32 - TARGET_ARCH=amd64
TB --- 2009-05-18 05:02:32 - TZ=UTC
TB --- 2009-05-18 05:02:32 - __MAKE_CONF=/dev/null
TB --- 2009-05-18 05:02:32 - cd /src
TB --- 2009-05-18 05:02:32 - /usr/bin/make -B buildworld
>>> 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 -fno-strict-aliasing -pipe  -I. -I/src/lib/libthread_db -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 -c /src/lib/libthread_db/arch/amd64/libpthread_md.c
/src/lib/libthread_db/arch/amd64/libpthread_md.c: In function `pt_fpreg_to_ucontext':
/src/lib/libthread_db/arch/amd64/libpthread_md.c:94: warning: implicit declaration of function `memcpy'
/src/lib/libthread_db/arch/amd64/libpthread_md.c:94: warning: nested extern declaration of `memcpy'
<internal>:0: warning: redundant redeclaration of 'memcpy'
/src/lib/libthread_db/arch/amd64/libpthread_md.c: In function `pt_ucontext_to_fpreg':
/src/lib/libthread_db/arch/amd64/libpthread_md.c:100: warning: nested extern declaration of `memcpy'
<internal>:0: warning: redundant redeclaration of 'memcpy'
*** Error code 1

Stop in /src/lib/libthread_db.
*** Error code 1

Stop in /src/lib.
*** 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-05-18 05:27:01 - WARNING: /usr/bin/make returned exit code  1 
TB --- 2009-05-18 05:27:01 - ERROR: failed to build world
TB --- 2009-05-18 05:27:01 - 1116.78 user 160.10 system 1490.17 real


http://tinderbox.des.no/tinderbox-releng_6-RELENG_6-amd64-amd64.full
From lev at FreeBSD.org  Mon May 18 08:27:34 2009
From: lev at FreeBSD.org (Lev Serebryakov)
Date: Mon May 18 08:28:07 2009
Subject: TCP differences in 7.2 vs 7.1
In-Reply-To: <310A73CC-A32D-4794-BF23-A49715AFCF99@nokia.com>
References: <guccc2$8b4$1@ger.gmane.org> <4A09DEF1.2010202@delphij.net>
	<4A09FDB2.5080307@eyede.com>
	<20090513004131.GP65350@michelle.cdnetworks.co.kr>
	<DAF693BD-D7B0-49FA-97EF-41C1EA1FAF84@nokia.com>
	<20090514082750.GU65350@michelle.cdnetworks.co.kr>
	<310A73CC-A32D-4794-BF23-A49715AFCF99@nokia.com>
Message-ID: <1842780877.20090514124631@serebryakov.spb.ru>

Hello, Lars.
You wrote 14 ??? 2009 ?., 12:28:43:

> Reproducing the issue is as easy as setting net.inet.tcp.tso=1.
> What's interesting is that I only see the issue on one of the eight em
> interfaces. That interface is connected to a D-Link DIR-655 WLAN  
> router. When I tcpdump on the other interfaces with TSO enabled, I see
> no "IP bad-len 0" messages.
  I have same problem (every one of 100-200 frames) on on-board if_em:

em0@pci0:0:25:0:        class=0x020000 card=0x82681043 chip=0x10bd8086 rev=0x02 hdr=0x00
    vendor     = 'Intel Corporation'
    device     = '82566DM-2 Gigabit Network Connection'
    class      = network
    subclass   = ethernet



-- 
// Black Lion AKA Lev Serebryakov <lev@FreeBSD.org>

From avg at icyb.net.ua  Mon May 18 13:41:56 2009
From: avg at icyb.net.ua (Andriy Gapon)
Date: Mon May 18 13:42:12 2009
Subject: double-fault in linux ioctl for atapicam cd device
Message-ID: <4A1165A0.6000800@icyb.net.ua>


This is recent i386 stable/7. The problem is 100% reproducible with the same stack
trace. The problem happens when I start a Linux program that performs a check on a
cd-rom device (atapi cd-rom that is presented as cd0 by atapicam driver).
I examined the crash dump in kgdb but couldn't find anything peculiar in the
variables, so I guess that this must be stack overflow or something like that.

In fact, difference between values in %esp in frame 4 and frame 22 is 7500 which
is quite close to KSTACK_PAGES * PAGE_SIZE for i386.
If I did my calculations correctly then it seems that linux_ioctl_cdrom uses
slightly more than 4K of stack, then cam_periph_error uses 828 bytes,
scsi_command_string uses 696, cam_error_print uses 540.

The backtrace is below. I am keeping the dump.

(kgdb) bt
#0  doadump () at pcpu.h:196
#1  0xc0556523 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:418
#2  0xc055676f in panic (fmt=Variable "fmt" is not available.
) at /usr/src/sys/kern/kern_shutdown.c:574
#3  0xc0712b69 in dblfault_handler () at /usr/src/sys/i386/i386/trap.c:972
#4  0xc058380a in kvprintf (fmt=0xc075d204 " ", func=0xc05828e0 <snprintf_func>,
arg=0xdabf0120, radix=10, ap=0xdabf015c "B") at /usr/src/sys/kern/subr_prf.c:823
#5  0xc0583c0b in vsnprintf (str=0xdabf03eb "", size=49, format=0xc075d202 "%x ",
ap=0xdabf0158 "B") at /usr/src/sys/kern/subr_prf.c:483
#6  0xc0583cf9 in snprintf (str=0xdabf03eb "", size=49, format=0xc075d202 "%x ")
at /usr/src/sys/kern/subr_prf.c:467
#7  0xc0449dc0 in scsi_cdb_string (cdb_ptr=0xc3187c9c "B", cdb_string=0xdabf03eb
"", len=49) at /usr/src/sys/cam/scsi/scsi_all.c:2943
#8  0xc0449ffd in scsi_command_string (csio=0xc3187c00, sb=0xdabf0440) at
/usr/src/sys/cam/scsi/scsi_all.c:3031
#9  0xc043db61 in cam_error_string (ccb=0xc3187c00, str=0xdabf04bc
"(cd0:ata0:0:0:0): ", str_len=512, flags=Variable "flags" is not available.
) at /usr/src/sys/cam/cam.c:262
#10 0xc043dcb4 in cam_error_print (ccb=0xc3187c00, flags=CAM_ESF_ALL,
proto_flags=CAM_EPF_ALL) at /usr/src/sys/cam/cam.c:341
#11 0xc043e500 in cam_periph_error (ccb=0xc3187c00, camflags=CAM_RETRY_SELTO,
sense_flags=1, save_ccb=0xc32b3034) at /usr/src/sys/cam/cam_periph.c:1548
#12 0xc044bcb0 in cderror (ccb=0xc3187c00, cam_flags=2, sense_flags=1) at
/usr/src/sys/cam/scsi/scsi_cd.c:3133
#13 0xc043ee1a in cam_periph_runccb (ccb=0xc3187c00, error_routine=0xc044bc10
<cderror>, camflags=CAM_RETRY_SELTO, sense_flags=1, ds=0xc329fb40) at
/usr/src/sys/cam/cam_periph.c:902
#14 0xc044c2cb in cdrunccb (ccb=0xc3187c00, error_routine=0xc044bc10 <cderror>,
cam_flags=2, sense_flags=1) at /usr/src/sys/cam/scsi/scsi_cd.c:1318
#15 0xc044f684 in cdioctl (dp=0xc3286000, cmd=3222037279, addr=0xdabf1c1c, flag=5,
td=0xc354c230) at /usr/src/sys/cam/scsi/scsi_cd.c:3227
#16 0xc04f9fa4 in g_disk_ioctl (pp=0xc32c7000, cmd=3222037279, data=0xdabf1c1c,
fflag=5, td=0xc354c230) at /usr/src/sys/geom/geom_disk.c:231
#17 0xc04f92dd in g_dev_ioctl (dev=0xc33faa00, cmd=3222037279, data=0xdabf1c1c
"\001\001", fflag=5, td=0xc354c230) at /usr/src/sys/geom/geom_dev.c:332
#18 0xc04e5b87 in devfs_ioctl_f (fp=0xc32d1474, com=3222037279, data=0xdabf1c1c,
cred=0xc4077800, td=0xc354c230) at /usr/src/sys/fs/devfs/devfs_vnops.c:602
#19 0xc3449ea4 in linux_ioctl_cdrom (td=0xc354c230, args=0xdabf1cfc) at file.h:269
#20 0xc344978a in linux_ioctl (td=0xc354c230, args=0xdabf1cfc) at
/usr/src/sys/modules/linux/../../compat/linux/linux_ioctl.c:2621
#21 0xc0713495 in syscall (frame=0xdabf1d38) at /usr/src/sys/i386/i386/trap.c:1090
#22 0xc07006d0 in Xint0x80_syscall () at /usr/src/sys/i386/i386/exception.s:255
#23 0x00000033 in ?? ()

-- 
Andriy Gapon
From avg at freebsd.org  Mon May 18 14:09:10 2009
From: avg at freebsd.org (Andriy Gapon)
Date: Mon May 18 14:09:17 2009
Subject: stack abuse by linux_ioctl_cdrom [Was: double-fault in linux ioctl
 for atapicam cd device]
In-Reply-To: <4A1165A0.6000800@icyb.net.ua>
References: <4A1165A0.6000800@icyb.net.ua>
Message-ID: <4A1167A2.6040407@freebsd.org>

on 18/05/2009 16:41 Andriy Gapon said the following:
> This is recent i386 stable/7. The problem is 100% reproducible with the same stack
> trace. The problem happens when I start a Linux program that performs a check on a
> cd-rom device (atapi cd-rom that is presented as cd0 by atapicam driver).
> I examined the crash dump in kgdb but couldn't find anything peculiar in the
> variables, so I guess that this must be stack overflow or something like that.
> 
> In fact, difference between values in %esp in frame 4 and frame 22 is 7500 which
> is quite close to KSTACK_PAGES * PAGE_SIZE for i386.
> If I did my calculations correctly then it seems that linux_ioctl_cdrom uses
> slightly more than 4K of stack, then cam_periph_error uses 828 bytes,
> scsi_command_string uses 696, cam_error_print uses 540.


In fact almost all of stack usage in linux_ioctl_cdrom comes from struct
dvd_struct (2060 bytes) and l_dvd_struct (2056 bytes) variables declared on stack
(for LINUX_DVD_READ_STRUCT case). Not sure what's the best way to fix - move to heap?

> The backtrace is below. I am keeping the dump.
> 
> (kgdb) bt
> #0  doadump () at pcpu.h:196
> #1  0xc0556523 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:418
> #2  0xc055676f in panic (fmt=Variable "fmt" is not available.
> ) at /usr/src/sys/kern/kern_shutdown.c:574
> #3  0xc0712b69 in dblfault_handler () at /usr/src/sys/i386/i386/trap.c:972
> #4  0xc058380a in kvprintf (fmt=0xc075d204 " ", func=0xc05828e0 <snprintf_func>,
> arg=0xdabf0120, radix=10, ap=0xdabf015c "B") at /usr/src/sys/kern/subr_prf.c:823
> #5  0xc0583c0b in vsnprintf (str=0xdabf03eb "", size=49, format=0xc075d202 "%x ",
> ap=0xdabf0158 "B") at /usr/src/sys/kern/subr_prf.c:483
> #6  0xc0583cf9 in snprintf (str=0xdabf03eb "", size=49, format=0xc075d202 "%x ")
> at /usr/src/sys/kern/subr_prf.c:467
> #7  0xc0449dc0 in scsi_cdb_string (cdb_ptr=0xc3187c9c "B", cdb_string=0xdabf03eb
> "", len=49) at /usr/src/sys/cam/scsi/scsi_all.c:2943
> #8  0xc0449ffd in scsi_command_string (csio=0xc3187c00, sb=0xdabf0440) at
> /usr/src/sys/cam/scsi/scsi_all.c:3031
> #9  0xc043db61 in cam_error_string (ccb=0xc3187c00, str=0xdabf04bc
> "(cd0:ata0:0:0:0): ", str_len=512, flags=Variable "flags" is not available.
> ) at /usr/src/sys/cam/cam.c:262
> #10 0xc043dcb4 in cam_error_print (ccb=0xc3187c00, flags=CAM_ESF_ALL,
> proto_flags=CAM_EPF_ALL) at /usr/src/sys/cam/cam.c:341
> #11 0xc043e500 in cam_periph_error (ccb=0xc3187c00, camflags=CAM_RETRY_SELTO,
> sense_flags=1, save_ccb=0xc32b3034) at /usr/src/sys/cam/cam_periph.c:1548
> #12 0xc044bcb0 in cderror (ccb=0xc3187c00, cam_flags=2, sense_flags=1) at
> /usr/src/sys/cam/scsi/scsi_cd.c:3133
> #13 0xc043ee1a in cam_periph_runccb (ccb=0xc3187c00, error_routine=0xc044bc10
> <cderror>, camflags=CAM_RETRY_SELTO, sense_flags=1, ds=0xc329fb40) at
> /usr/src/sys/cam/cam_periph.c:902
> #14 0xc044c2cb in cdrunccb (ccb=0xc3187c00, error_routine=0xc044bc10 <cderror>,
> cam_flags=2, sense_flags=1) at /usr/src/sys/cam/scsi/scsi_cd.c:1318
> #15 0xc044f684 in cdioctl (dp=0xc3286000, cmd=3222037279, addr=0xdabf1c1c, flag=5,
> td=0xc354c230) at /usr/src/sys/cam/scsi/scsi_cd.c:3227
> #16 0xc04f9fa4 in g_disk_ioctl (pp=0xc32c7000, cmd=3222037279, data=0xdabf1c1c,
> fflag=5, td=0xc354c230) at /usr/src/sys/geom/geom_disk.c:231
> #17 0xc04f92dd in g_dev_ioctl (dev=0xc33faa00, cmd=3222037279, data=0xdabf1c1c
> "\001\001", fflag=5, td=0xc354c230) at /usr/src/sys/geom/geom_dev.c:332
> #18 0xc04e5b87 in devfs_ioctl_f (fp=0xc32d1474, com=3222037279, data=0xdabf1c1c,
> cred=0xc4077800, td=0xc354c230) at /usr/src/sys/fs/devfs/devfs_vnops.c:602
> #19 0xc3449ea4 in linux_ioctl_cdrom (td=0xc354c230, args=0xdabf1cfc) at file.h:269
> #20 0xc344978a in linux_ioctl (td=0xc354c230, args=0xdabf1cfc) at
> /usr/src/sys/modules/linux/../../compat/linux/linux_ioctl.c:2621
> #21 0xc0713495 in syscall (frame=0xdabf1d38) at /usr/src/sys/i386/i386/trap.c:1090
> #22 0xc07006d0 in Xint0x80_syscall () at /usr/src/sys/i386/i386/exception.s:255
> #23 0x00000033 in ?? ()
> 


-- 
Andriy Gapon
From tinderbox at freebsd.org  Mon May 18 14:27:37 2009
From: tinderbox at freebsd.org (FreeBSD Tinderbox)
Date: Mon May 18 14:27:49 2009
Subject: [releng_6 tinderbox] failure on amd64/amd64
Message-ID: <20090518142733.63F8D241BA@freebsd-legacy.sentex.ca>

TB --- 2009-05-18 14:02:42 - tinderbox 2.6 running on freebsd-legacy.sentex.ca
TB --- 2009-05-18 14:02:42 - starting RELENG_6 tinderbox run for amd64/amd64
TB --- 2009-05-18 14:02:42 - cleaning the object tree
TB --- 2009-05-18 14:02:57 - cvsupping the source tree
TB --- 2009-05-18 14:02:57 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/RELENG_6/amd64/amd64/supfile
TB --- 2009-05-18 14:03:05 - building world
TB --- 2009-05-18 14:03:05 - MAKEOBJDIRPREFIX=/obj
TB --- 2009-05-18 14:03:05 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2009-05-18 14:03:05 - TARGET=amd64
TB --- 2009-05-18 14:03:05 - TARGET_ARCH=amd64
TB --- 2009-05-18 14:03:05 - TZ=UTC
TB --- 2009-05-18 14:03:05 - __MAKE_CONF=/dev/null
TB --- 2009-05-18 14:03:05 - cd /src
TB --- 2009-05-18 14:03:05 - /usr/bin/make -B buildworld
>>> 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 -fno-strict-aliasing -pipe  -I. -I/src/lib/libthread_db -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 -c /src/lib/libthread_db/arch/amd64/libpthread_md.c
/src/lib/libthread_db/arch/amd64/libpthread_md.c: In function `pt_fpreg_to_ucontext':
/src/lib/libthread_db/arch/amd64/libpthread_md.c:94: warning: implicit declaration of function `memcpy'
/src/lib/libthread_db/arch/amd64/libpthread_md.c:94: warning: nested extern declaration of `memcpy'
<internal>:0: warning: redundant redeclaration of 'memcpy'
/src/lib/libthread_db/arch/amd64/libpthread_md.c: In function `pt_ucontext_to_fpreg':
/src/lib/libthread_db/arch/amd64/libpthread_md.c:100: warning: nested extern declaration of `memcpy'
<internal>:0: warning: redundant redeclaration of 'memcpy'
*** Error code 1

Stop in /src/lib/libthread_db.
*** Error code 1

Stop in /src/lib.
*** 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-05-18 14:27:33 - WARNING: /usr/bin/make returned exit code  1 
TB --- 2009-05-18 14:27:33 - ERROR: failed to build world
TB --- 2009-05-18 14:27:33 - 1116.55 user 159.14 system 1490.53 real


http://tinderbox.des.no/tinderbox-releng_6-RELENG_6-amd64-amd64.full
From freebsd at abv.bg  Mon May 18 14:43:23 2009
From: freebsd at abv.bg (Mario Pavlov)
Date: Mon May 18 14:43:47 2009
Subject: Unable to read from CCID USB reader
Message-ID: <2124185244.44258.1242657799168.JavaMail.apache@mail53.abv.bg>

Hi,
no I haven't tried it on CURRENT
should I do that ?
is there something new in the USB stuff there ?
thank you

regards,
mgp

 >On Sunday 17 May 2009, Mario Pavlov wrote:
 >> Hi,
 >> I just got a CCID USB reader with my digital signature...unfortunately I
 >> can't make it work I installed pcsc-lite and libccid from ports...
 >> when I plug-in the reader I can see this:
 >>
 >> ugen0:  on
 >> uhub4
 >>
 >> then I do this:
 >>
 >
 >Is the problem the same on -current?
 >
 >--HPS
 >_______________________________________________
 >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 hselasky at c2i.net  Mon May 18 14:45:30 2009
From: hselasky at c2i.net (Hans Petter Selasky)
Date: Mon May 18 14:45:43 2009
Subject: Unable to read from CCID USB reader
In-Reply-To: <2002614109.15779.1242569786248.JavaMail.apache@mail53.abv.bg>
References: <2002614109.15779.1242569786248.JavaMail.apache@mail53.abv.bg>
Message-ID: <200905181548.01967.hselasky@c2i.net>

On Sunday 17 May 2009, Mario Pavlov wrote:
> Hi,
> I just got a CCID USB reader with my digital signature...unfortunately I
> can't make it work I installed pcsc-lite and libccid from ports...
> when I plug-in the reader I can see this:
>
> ugen0: <vendor 0x072f CCID USB Reader, class 0/0, rev 1.10/1.00, addr 2> on
> uhub4
>
> then I do this:
>

Is the problem the same on -current?

--HPS
From hselasky at c2i.net  Mon May 18 14:48:54 2009
From: hselasky at c2i.net (Hans Petter Selasky)
Date: Mon May 18 14:49:13 2009
Subject: Unable to read from CCID USB reader
In-Reply-To: <2124185244.44258.1242657799168.JavaMail.apache@mail53.abv.bg>
References: <2124185244.44258.1242657799168.JavaMail.apache@mail53.abv.bg>
Message-ID: <200905181651.26773.hselasky@c2i.net>

On Monday 18 May 2009, Mario Pavlov wrote:
> Hi,
> no I haven't tried it on CURRENT
> should I do that ?
> is there something new in the USB stuff there ?

There is a new USB stack in 8-current and a new libusb which is installed as a 
part of the base system.

--HPS
From jhb at freebsd.org  Mon May 18 17:07:44 2009
From: jhb at freebsd.org (John Baldwin)
Date: Mon May 18 17:08:18 2009
Subject: Boot panic w/7.2-STABLE on amd64: resource_list_alloc
In-Reply-To: <4A1094E7.9010502@FreeBSD.org>
References: <1242375781.00112347.1242364801@10.7.7.3>
	<1242404600.00112531.1242393604@10.7.7.3>
	<4A1094E7.9010502@FreeBSD.org>
Message-ID: <200905181144.50693.jhb@freebsd.org>

On Sunday 17 May 2009 6:51:19 pm Alexander Motin wrote:
> John Baldwin wrote:
> > Sounds like the ATA driver is allocating the same BAR twice.  Hmm, yes, it 
> > allocates the resources once for each channel it seems in the ata_ali_sata 
> > attachment.  Looking in ata-chipset.c, all the other chipsets are good 
about 
> > allocating these resources in their chipinit routines rather than the 
> > per-channel allocate routine.  Well, except ata_pci_allocate() is also 
> > busted.  *sigh*  I can work on a patch for HEAD if you are willing to 
test.
> 
> ata_pci_allocate() (now known as ata_pci_ch_attach()) is a different 
> case. It uses allocation functions wrapped by the atapci "bus", so every 
> channel uses it's own pair of RIDs.

Hmm, ok.

> Problem of ALI SATA is a bit different. As I understand, controller has 
> two pairs of RIDs for 4 channels, so each channel should share resources 
> with another one, just using different offset. Is there any other way to 
> correctly handle two halves of same resource separately without teaching 
> atapci to virtualize this as interrupts or handle it on controller level?

I will just fix the ALI attachment to handle this possibly by 
using 'chipset_data' to cache resources.

-- 
John Baldwin
From dimitry at andric.com  Mon May 18 18:18:15 2009
From: dimitry at andric.com (Dimitry Andric)
Date: Mon May 18 18:18:22 2009
Subject: RFT: ZFS MFC
In-Reply-To: <3c1674c90905151702l81c2b88off1d2b2ffed39ca2@mail.gmail.com>
References: <3c1674c90905151702l81c2b88off1d2b2ffed39ca2@mail.gmail.com>
Message-ID: <4A11A666.3030407@andric.com>

On 2009-05-16 02:02, Kip Macy wrote:
> I've MFC'd ZFS v13 to RELENG_7 in a work branch. Please test if you can.
> 
> http://svn.freebsd.org/base/user/kmacy/ZFS_MFC/
> 
> The standard disclaimers apply. This has only been lightly tested in a
> VM. Please do not use it with data you care about at this time.

For people that would like to test this without building, e.g. to easily
install on a spare box or VM, I have put up some snapshot ISOs of this
branch, at r192269 (for i386):

http://www.andric.com/freebsd/zfs13/r192269/

Note: these don't contain a full ports collection, but enough to get a
basic system installed, or a LiveCD/DVD started.

Also, if you encounter issues with these ISOs that don't have to do with
ZFS, please don't bother Kip, but me instead. :)
From msnkipa at mail.ru  Mon May 18 20:31:16 2009
From: msnkipa at mail.ru (=?koi8-r?Q?=ED=C9=C8=C1=C9=CC_=EB=C9=D0=C1?=)
Date: Mon May 18 20:31:23 2009
Subject: mountd doean`t start when ZFS is enabled.
Message-ID: <E1M68z8-0003Xd-00.msnkipa-mail-ru@f254.mail.ru>

I have two servers with Identical FreeBSD7.2 system. On both I have such config in /etc/rc.conf:
rpcbind_enable="YES"
rpc_lockd_enable="YES"
rpc_statd_enable="YES"
nfs_client_enable="YES"
nfs_server_enable="YES"
nfs_server_flags="-u -t -n 5 -h 192.168.x.y"
mountd_flags="-r"
where "x" identical for both servers and "y" is differs by one. On one server I have ZFS storage, so 
that in rc.conf I have:
zfs_enable="YES"
On server where no ZFS storage NFS server works well and mountd starts at server startup 
automatically. But on the server with ZFS storage mountd couldn`t start on startup with such error:
mountd[855]: bindresvport_sa: Address already in use
when I correct rc.conf to:
mountd_flags="-r -p 998"
mountd begins to work.
So, is it corrct behaviour of mountd with zfs? On 7.1 anything works well, but after cvsup and 
recompilation system has falled in such troube. May be it is a bug?
From cowens at greatbaysoftware.com  Tue May 19 01:50:42 2009
From: cowens at greatbaysoftware.com (Charles Owens)
Date: Tue May 19 01:50:50 2009
Subject: help with 7.0-p12 crash analysis "panic: lockmgr: upgrade without
 shared"
Message-ID: <4A120DBE.30204@greatbaysoftware.com>

Hello,

We had a crash of a 7.0-RELEASE-p12 running on a dual quad-core Xeon
system with 6 gig RAM and mfi-based RAID.  Pasted below are the output
of kgdb crashdump backtrace, custom kernel config, and boot log.

We really need to understand what happened and would greatly appreciate
assistance.  What is the next step?

Thanks very much,

Charles

(kgdb) newcastle# kgdb kernel.debug /crash/vmcore.0
[GDB will not be able to debug user-mode threads: /usr/lib/libthread_db.so: Undefined symbol "ps_pglobal_lookup"]
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i386-marcel-freebsd".

Unread portion of the kernel message buffer:
panic: lockmgr: upgrade without shared
cpuid = 3
Uptime: 1d0h5m24s
Physical memory: 6126 MB
Dumping 495 MB: 480 464 448 432 416 400 384 368 352 336 320 304 288 272 256 240 224 208 192 176 160 144 128 112 96 80 64 48 32 16

#0  doadump () at pcpu.h:195
195             __asm __volatile("movl %%fs:0,%0" : "=r" (td));
(kgdb) backtrace
#0  doadump () at pcpu.h:195
#1  0xc0505537 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:409
#2  0xc05057f9 in panic (fmt=Variable "fmt" is not available.
) at /usr/src/sys/kern/kern_shutdown.c:563
#3  0xc04f3cb7 in _lockmgr (lkp=0xcc69ee28, flags=8212, interlkp=0xcc69ee58,
    td=0xcc11e660, file=0xc088d931 "/usr/src/sys/kern/vfs_subr.c", line=2213)
    at /usr/src/sys/kern/kern_lock.c:310
#4  0xc05710b0 in vop_stdlock (ap=0xec5c6bfc)
    at /usr/src/sys/kern/vfs_default.c:266
#5  0xc07734b6 in VOP_LOCK1_APV (vop=0xc0919180, a=0xec5c6bfc)
    at vnode_if.c:1618
#6  0xc06cc3eb in ffs_lock (ap=0xec5c6bfc)
    at /usr/src/sys/ufs/ffs/ffs_vnops.c:391
#7  0xc07734b6 in VOP_LOCK1_APV (vop=0xc09296c0, a=0xec5c6bfc)
    at vnode_if.c:1618
#8  0xc057f9b1 in vput (vp=0xcc69edd0) at vnode_if.h:851
#9  0xc06f9f54 in vm_pageout () at /usr/src/sys/vm/vm_pageout.c:1025
#10 0xc04e43c9 in fork_exit (callout=0xc06f8f30 <vm_pageout>, arg=0x0,
    frame=0xec5c6d38) at /usr/src/sys/kern/kern_fork.c:781
#11 0xc0746f80 in fork_trampoline () at /usr/src/sys/i386/i386/exception.s:205
(kgdb) 


***** KERNEL CONF ******

# Inherit config (most stuff) -- this is slightly customized version... 
#   inherits from GENERIC-cust (tweaked to disable the default scheduler)
include PAE-cust

# Name of this kernel
ident           BEACON


# Scheduler -- From /usr/src/sys/conf/NOTES:
#
# SCHED_ULE provides significant performance advantages over 4BSD on many
# workloads on SMP machines.  It supports cpu-affinity, per-cpu runqueues
# and scheduler locks.  It also has a stronger notion of interactivity 
# which leads to better responsiveness even on uniprocessor machines.  This
# will eventually become the default scheduler.
#
options        SCHED_ULE


# Note: we're compiling modules in statically since with PAE we don't want to
#   load KLDs.   See comments in pae(4) and PAE kernel conf file.

# Hardware Monitoring / Management

device          ipmi

# Storage

options         GEOM_JOURNAL

# Firewall 

device          pf                      #PF OpenBSD packet-filter firewall
device          pflog                   #logging support interface for PF
# device          pfsync                  #synchronization interface for PF

options         ALTQ

options         ALTQ_CBQ
options         ALTQ_RED
options         ALTQ_RIO
options         ALTQ_HFSC
options         ALTQ_CDNR
options         ALTQ_PRIQ

options         ALTQ_NOPCC              # Required for SMP builds

# Linux Emulation
 
options         COMPAT_LINUX
options         LINPROCFS
options         LINSYSFS

# Screen saver

device          green_saver

### Network perf tuning

options         ACCEPT_FILTER_HTTP

# See polling(4))

options         DEVICE_POLLING
options         HZ=1000

# End config


****** Boot Log ******

May 16 02:34:18 gbs01-etc kernel: mfi0: 4167 (295774362s/0x0020/0) - Patrol Read complete
May 16 02:56:01 gbs01-etc heartbeat: [2685]: WARN: Gmain_timeout_dispatch: Dispatch function for send local status took too long to execute: 789 ms (> 50 ms) (GSource: 0x28620930)
May 16 09:46:08 gbs01-etc su: beacon to root on /dev/ttyp0
May 16 16:03:47 gbs01-etc sshd[8012]: error: PAM: authentication error for beacon from 10.102.144.81
May 16 16:05:41 gbs01-etc sshd[8017]: error: ssh_msg_send: write
May 18 13:52:10 gbs01-etc syslogd: kernel boot file is /boot/BEACON/kernel
May 18 13:52:10 gbs01-etc kernel: Copyright (c) 1992-2008 The FreeBSD Project.
May 18 13:52:10 gbs01-etc kernel: Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
May 18 13:52:10 gbs01-etc kernel: The Regents of the University of California. All rights reserved.
May 18 13:52:10 gbs01-etc kernel: FreeBSD is a registered trademark of The FreeBSD Foundation.
May 18 13:52:10 gbs01-etc kernel: FreeBSD 7.0-RELEASE-p12 #0: Thu Apr 23 23:58:18 UTC 2009
May 18 13:52:10 gbs01-etc kernel: root@newcastle.greatbaysoftware.com:/usr/obj/usr/src/sys/BEACON
May 18 13:52:10 gbs01-etc kernel: Timecounter "i8254" frequency 1193182 Hz quality 0
May 18 13:52:10 gbs01-etc kernel: CPU: Intel(R) Xeon(R) CPU           E5430  @ 2.66GHz (2673.32-MHz 686-class CPU)
May 18 13:52:10 gbs01-etc kernel: Origin = "GenuineIntel"  Id = 0x10676  Stepping = 6
May 18 13:52:10 gbs01-etc 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>
May 18 13:52:10 gbs01-etc kernel: Features2=0xce3bd<SSE3,RSVD2,MON,DS_CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,DCA,<b19>>
May 18 13:52:10 gbs01-etc kernel: AMD Features=0x20100000<NX,LM>
May 18 13:52:10 gbs01-etc kernel: AMD Features2=0x1<LAHF>
May 18 13:52:10 gbs01-etc kernel: Cores per package: 4
May 18 13:52:10 gbs01-etc kernel: real memory  = 8053063680 (7680 MB)
May 18 13:52:10 gbs01-etc kernel: avail memory = 6270386176 (5979 MB)
May 18 13:52:10 gbs01-etc kernel: ACPI APIC Table: <INTEL  S5000PAL>
May 18 13:52:10 gbs01-etc kernel: FreeBSD/SMP: Multiprocessor System Detected: 8 CPUs
May 18 13:52:10 gbs01-etc kernel: cpu0 (BSP): APIC ID:  0
May 18 13:52:10 gbs01-etc kernel: cpu1 (AP): APIC ID:  1
May 18 13:52:10 gbs01-etc kernel: cpu2 (AP): APIC ID:  2
May 18 13:52:10 gbs01-etc kernel: cpu3 (AP): APIC ID:  3
May 18 13:52:10 gbs01-etc kernel: cpu4 (AP): APIC ID:  4
May 18 13:52:10 gbs01-etc kernel: cpu5 (AP): APIC ID:  5
May 18 13:52:10 gbs01-etc kernel: cpu6 (AP): APIC ID:  6
May 18 13:52:10 gbs01-etc kernel: cpu7 (AP): APIC ID:  7
May 18 13:52:10 gbs01-etc kernel: ioapic0 <Version 2.0> irqs 0-23 on motherboard
May 18 13:52:10 gbs01-etc kernel: ioapic1 <Version 2.0> irqs 24-47 on motherboard
May 18 13:52:10 gbs01-etc kernel: lapic0: Forcing LINT1 to edge trigger
May 18 13:52:10 gbs01-etc kernel: registered firmware set <isp_1040>
May 18 13:52:10 gbs01-etc kernel: registered firmware set <isp_1040_it>
May 18 13:52:10 gbs01-etc kernel: registered firmware set <isp_1080>
May 18 13:52:10 gbs01-etc kernel: registered firmware set <isp_1080_it>
May 18 13:52:10 gbs01-etc kernel: registered firmware set <isp_12160>
May 18 13:52:10 gbs01-etc kernel: registered firmware set <isp_12160_it>
May 18 13:52:10 gbs01-etc kernel: registered firmware set <isp_2100>
May 18 13:52:10 gbs01-etc kernel: registered firmware set <isp_2200>
May 18 13:52:10 gbs01-etc kernel: registered firmware set <isp_2300>
May 18 13:52:10 gbs01-etc kernel: registered firmware set <isp_2322>
May 18 13:52:10 gbs01-etc kernel: registered firmware set <isp_2400>
May 18 13:52:10 gbs01-etc kernel: kbd1 at kbdmux0
May 18 13:52:10 gbs01-etc kernel: acpi0: <INTEL S5000PAL> on motherboard
May 18 13:52:10 gbs01-etc kernel: acpi0: [ITHREAD]
May 18 13:52:10 gbs01-etc kernel: acpi0: Power Button (fixed)
May 18 13:52:10 gbs01-etc kernel: Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000
May 18 13:52:10 gbs01-etc kernel: acpi_timer0: <24-bit timer at 3.579545MHz> port 0x408-0x40b on acpi0
May 18 13:52:10 gbs01-etc kernel: acpi_hpet0: <High Precision Event Timer> iomem 0xfed00000-0xfed003ff on acpi0
May 18 13:52:10 gbs01-etc kernel: Timecounter "HPET" frequency 14318180 Hz quality 900
May 18 13:52:10 gbs01-etc kernel: ipmi0: <IPMI System Interface> port 0xca2,0xca3 on acpi0
May 18 13:52:10 gbs01-etc kernel: ipmi0: KCS mode found at io 0xca2 on acpi
May 18 13:52:10 gbs01-etc kernel: cpu0: <ACPI CPU> on acpi0
May 18 13:52:10 gbs01-etc kernel: est0: <Enhanced SpeedStep Frequency Control> on cpu0
May 18 13:52:10 gbs01-etc kernel: p4tcc0: <CPU Frequency Thermal Control> on cpu0
May 18 13:52:10 gbs01-etc kernel: cpu1: <ACPI CPU> on acpi0
May 18 13:52:10 gbs01-etc kernel: est1: <Enhanced SpeedStep Frequency Control> on cpu1
May 18 13:52:10 gbs01-etc kernel: p4tcc1: <CPU Frequency Thermal Control> on cpu1
May 18 13:52:10 gbs01-etc kernel: cpu2: <ACPI CPU> on acpi0
May 18 13:52:10 gbs01-etc kernel: est2: <Enhanced SpeedStep Frequency Control> on cpu2
May 18 13:52:10 gbs01-etc kernel: p4tcc2: <CPU Frequency Thermal Control> on cpu2
May 18 13:52:10 gbs01-etc kernel: cpu3: <ACPI CPU> on acpi0
May 18 13:52:10 gbs01-etc kernel: est3: <Enhanced SpeedStep Frequency Control> on cpu3
May 18 13:52:10 gbs01-etc kernel: p4tcc3: <CPU Frequency Thermal Control> on cpu3
May 18 13:52:10 gbs01-etc kernel: cpu4: <ACPI CPU> on acpi0
May 18 13:52:10 gbs01-etc kernel: est4: <Enhanced SpeedStep Frequency Control> on cpu4
May 18 13:52:10 gbs01-etc kernel: p4tcc4: <CPU Frequency Thermal Control> on cpu4
May 18 13:52:10 gbs01-etc kernel: cpu5: <ACPI CPU> on acpi0
May 18 13:52:10 gbs01-etc kernel: est5: <Enhanced SpeedStep Frequency Control> on cpu5
May 18 13:52:10 gbs01-etc kernel: p4tcc5: <CPU Frequency Thermal Control> on cpu5
May 18 13:52:10 gbs01-etc kernel: cpu6: <ACPI CPU> on acpi0
May 18 13:52:10 gbs01-etc kernel: est6: <Enhanced SpeedStep Frequency Control> on cpu6
May 18 13:52:10 gbs01-etc kernel: p4tcc6: <CPU Frequency Thermal Control> on cpu6
May 18 13:52:10 gbs01-etc kernel: cpu7: <ACPI CPU> on acpi0
May 18 13:52:10 gbs01-etc kernel: est7: <Enhanced SpeedStep Frequency Control> on cpu7
May 18 13:52:10 gbs01-etc kernel: p4tcc7: <CPU Frequency Thermal Control> on cpu7
May 18 13:52:10 gbs01-etc kernel: acpi_button0: <Power Button> on acpi0
May 18 13:52:10 gbs01-etc kernel: pcib0: <ACPI Host-PCI bridge> port 0xca2,0xca3,0xcf8-0xcff on acpi0
May 18 13:52:10 gbs01-etc kernel: pci0: <ACPI PCI bus> on pcib0
May 18 13:52:10 gbs01-etc kernel: pcib1: <ACPI PCI-PCI bridge> at device 2.0 on pci0
May 18 13:52:10 gbs01-etc kernel: pci1: <ACPI PCI bus> on pcib1
May 18 13:52:10 gbs01-etc kernel: pcib2: <ACPI PCI-PCI bridge> irq 16 at device 0.0 on pci1
May 18 13:52:10 gbs01-etc kernel: pci2: <ACPI PCI bus> on pcib2
May 18 13:52:10 gbs01-etc kernel: pcib3: <ACPI PCI-PCI bridge> irq 16 at device 0.0 on pci2
May 18 13:52:10 gbs01-etc kernel: pci3: <ACPI PCI bus> on pcib3
May 18 13:52:10 gbs01-etc kernel: pcib4: <ACPI PCI-PCI bridge> at device 0.0 on pci3
May 18 13:52:10 gbs01-etc kernel: pci4: <ACPI PCI bus> on pcib4
May 18 13:52:10 gbs01-etc kernel: mfi0: <LSI MegaSAS 1064R> mem 0xb8b00000-0xb8b0ffff,0xb8900000-0xb891ffff irq 18 at device 14.0 on pci4
May 18 13:52:10 gbs01-etc kernel: mfi0: Megaraid SAS driver Ver 2.00
May 18 13:52:10 gbs01-etc kernel: mfi0: 4064 (295722253s/0x0020/0) - Shutdown command received from host
May 18 13:52:10 gbs01-etc kernel: mfi0: 4065 (4278190080s/0x0020/0) - PCI 0x041000 0x04411 0x048086 0x043501: Firmware initialization started (PCI ID 0411/1000/3501/8086)

... (more mfi messages)

May 18 13:52:10 gbs01-etc kernel: pcib5: <PCI-PCI bridge> at device 0.2 on pci3
May 18 13:52:10 gbs01-etc kernel: pci5: <PCI bus> on pcib5
May 18 13:52:10 gbs01-etc kernel: pcib6: <ACPI PCI-PCI bridge> irq 16 at device 1.0 on pci2
May 18 13:52:10 gbs01-etc kernel: pci6: <ACPI PCI bus> on pcib6
May 18 13:52:10 gbs01-etc kernel: pcib7: <ACPI PCI-PCI bridge> irq 16 at device 2.0 on pci2
May 18 13:52:10 gbs01-etc kernel: pci7: <ACPI PCI bus> on pcib7
May 18 13:52:10 gbs01-etc kernel: em0: <Intel(R) PRO/1000 Network Connection Version - 6.7.3> port 0x3020-0x303f mem 0xb8820000-0xb883ffff,0xb8400000-0xb87fffff irq 18 at device 0.0 on pci7
May 18 13:52:10 gbs01-etc kernel: em0: Using MSI interrupt
May 18 13:52:10 gbs01-etc kernel: em0: Ethernet address: 00:15:17:6b:7f:24
May 18 13:52:10 gbs01-etc kernel: em0: [FILTER]
May 18 13:52:10 gbs01-etc kernel: em1: <Intel(R) PRO/1000 Network Connection Version - 6.7.3> port 0x3000-0x301f mem 0xb8800000-0xb881ffff,0xb8000000-0xb83fffff irq 19 at device 0.1 on pci7
May 18 13:52:10 gbs01-etc kernel: em1: Using MSI interrupt
May 18 13:52:10 gbs01-etc kernel: em1: Ethernet address: 00:15:17:6b:7f:25
May 18 13:52:10 gbs01-etc kernel: em1: [FILTER]
May 18 13:52:10 gbs01-etc kernel: pcib8: <ACPI PCI-PCI bridge> at device 0.3 on pci1
May 18 13:52:10 gbs01-etc kernel: pci8: <ACPI PCI bus> on pcib8
May 18 13:52:10 gbs01-etc kernel: pcib9: <PCI-PCI bridge> at device 3.0 on pci0
May 18 13:52:10 gbs01-etc kernel: pci9: <PCI bus> on pcib9
May 18 13:52:10 gbs01-etc kernel: pcib10: <ACPI PCI-PCI bridge> at device 4.0 on pci0
May 18 13:52:10 gbs01-etc kernel: pci10: <ACPI PCI bus> on pcib10
May 18 13:52:10 gbs01-etc kernel: pcib11: <ACPI PCI-PCI bridge> at device 5.0 on pci0
May 18 13:52:10 gbs01-etc kernel: pci11: <ACPI PCI bus> on pcib11
May 18 13:52:10 gbs01-etc kernel: pcib12: <ACPI PCI-PCI bridge> at device 6.0 on pci0
May 18 13:52:10 gbs01-etc kernel: pci12: <ACPI PCI bus> on pcib12
May 18 13:52:10 gbs01-etc kernel: em2: <Intel(R) PRO/1000 Network Connection Version - 6.7.3> port 0x2020-0x203f mem 0xb8d60000-0xb8d7ffff,0xb8d40000-0xb8d5ffff irq 16 at device 0.0 on pci12
May 18 13:52:10 gbs01-etc kernel: em2: Using MSI interrupt
May 18 13:52:10 gbs01-etc kernel: em2: Ethernet address: 00:15:17:61:6a:3e
May 18 13:52:10 gbs01-etc kernel: em2: [FILTER]
May 18 13:52:10 gbs01-etc kernel: em3: <Intel(R) PRO/1000 Network Connection Version - 6.7.3> port 0x2000-0x201f mem 0xb8d20000-0xb8d3ffff,0xb8d00000-0xb8d1ffff irq 17 at device 0.1 on pci12
May 18 13:52:10 gbs01-etc kernel: em3: Using MSI interrupt
May 18 13:52:10 gbs01-etc kernel: em3: Ethernet address: 00:15:17:61:6a:3f
May 18 13:52:10 gbs01-etc kernel: em3: [FILTER]
May 18 13:52:10 gbs01-etc kernel: pcib13: <ACPI PCI-PCI bridge> at device 7.0 on pci0
May 18 13:52:10 gbs01-etc kernel: pci13: <ACPI PCI bus> on pcib13
May 18 13:52:10 gbs01-etc kernel: pci0: <base peripheral> at device 8.0 (no driver attached)
May 18 13:52:10 gbs01-etc kernel: pci0: <serial bus, USB> at device 29.0 (no driver attached)
May 18 13:52:10 gbs01-etc kernel: pci0: <serial bus, USB> at device 29.1 (no driver attached)
May 18 13:52:10 gbs01-etc kernel: pci0: <serial bus, USB> at device 29.2 (no driver attached)
May 18 13:52:10 gbs01-etc kernel: pci0: <serial bus, USB> at device 29.3 (no driver attached)
May 18 13:52:10 gbs01-etc kernel: pci0: <serial bus, USB> at device 29.7 (no driver attached)
May 18 13:52:10 gbs01-etc kernel: pcib14: <ACPI PCI-PCI bridge> at device 30.0 on pci0
May 18 13:52:10 gbs01-etc kernel: pci14: <ACPI PCI bus> on pcib14
May 18 13:52:10 gbs01-etc kernel: vgapci0: <VGA-compatible display> port 0x1000-0x10ff mem 0xb0000000-0xb7ffffff,0xb8c00000-0xb8c0ffff irq 17 at device 12.0 on pci14
May 18 13:52:10 gbs01-etc kernel: isab0: <PCI-ISA bridge> at device 31.0 on pci0
May 18 13:52:10 gbs01-etc kernel: isa0: <ISA bus> on isab0
May 18 13:52:10 gbs01-etc kernel: atapci0: <Intel 63XXESB2 UDMA100 controller> port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x40b0-0x40bf irq 20 at device 31.1 on pci0
May 18 13:52:10 gbs01-etc kernel: ata0: <ATA channel 0> on atapci0
May 18 13:52:10 gbs01-etc kernel: ata0: [ITHREAD]
May 18 13:52:10 gbs01-etc kernel: ata1: <ATA channel 1> on atapci0
May 18 13:52:10 gbs01-etc kernel: ata1: [ITHREAD]
May 18 13:52:10 gbs01-etc kernel: atapci1: <Intel 63XXESB2 SATA300 controller> port 0x40c8-0x40cf,0x40e4-0x40e7,0x40c0-0x40c7,0x40e0-0x40e3,0x40a0-0x40af mem 0xb8e00000-0xb8e003ff irq 20 at device 31.2 on pci0
May 18 13:52:10 gbs01-etc kernel: atapci1: [ITHREAD]
May 18 13:52:10 gbs01-etc kernel: ata2: <ATA channel 0> on atapci1
May 18 13:52:10 gbs01-etc kernel: ata2: [ITHREAD]
May 18 13:52:10 gbs01-etc kernel: ata3: <ATA channel 1> on atapci1
May 18 13:52:10 gbs01-etc kernel: ata3: [ITHREAD]
May 18 13:52:10 gbs01-etc kernel: pci0: <serial bus, SMBus> at device 31.3 (no driver attached)
May 18 13:52:10 gbs01-etc kernel: sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 on acpi0
May 18 13:52:10 gbs01-etc kernel: sio0: type 16550A
May 18 13:52:10 gbs01-etc kernel: sio0: [FILTER]
May 18 13:52:10 gbs01-etc kernel: sio1: <16550A-compatible COM port> port 0x2f8-0x2ff irq 3 flags 0x10 on acpi0
May 18 13:52:10 gbs01-etc kernel: sio1: type 16550A, console
May 18 13:52:10 gbs01-etc kernel: sio1: [FILTER]
May 18 13:52:10 gbs01-etc kernel: atkbdc0: <Keyboard controller (i8042)> port 0x60,0x64 irq 1 on acpi0
May 18 13:52:10 gbs01-etc kernel: atkbd0: <AT Keyboard> irq 1 on atkbdc0
May 18 13:52:10 gbs01-etc kernel: kbd0 at atkbd0
May 18 13:52:10 gbs01-etc kernel: atkbd0: [GIANT-LOCKED]
May 18 13:52:10 gbs01-etc kernel: atkbd0: [ITHREAD]
May 18 13:52:10 gbs01-etc kernel: ipmi1: <IPMI System Interface> on isa0
May 18 13:52:10 gbs01-etc kernel: device_attach: ipmi1 attach returned 16
May 18 13:52:10 gbs01-etc kernel: pmtimer0 on isa0
May 18 13:52:10 gbs01-etc kernel: orm0: <ISA Option ROMs> at iomem 0xc0000-0xc8fff,0xc9000-0xcdfff pnpid ORM0000 on isa0
May 18 13:52:10 gbs01-etc kernel: ppc0: parallel port not found.
May 18 13:52:10 gbs01-etc kernel: sc0: <System console> at flags 0x100 on isa0
May 18 13:52:10 gbs01-etc kernel: sc0: VGA <16 virtual consoles, flags=0x300>
May 18 13:52:10 gbs01-etc kernel: vga0: <Generic ISA VGA> at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0
May 18 13:52:10 gbs01-etc kernel: Timecounters tick every 1.000 msec
May 18 13:52:10 gbs01-etc kernel: acd0: DVDROM <DV-28E-V/1.AB> at ata0-slave UDMA33
May 18 13:52:10 gbs01-etc kernel: ipmi0: IPMI device rev. 1, firmware rev. 0.2, version 2.0
May 18 13:52:10 gbs01-etc kernel: ipmi0: Number of channels 5
May 18 13:52:10 gbs01-etc kernel: ipmi0: Attached watchdog
May 18 13:52:10 gbs01-etc kernel: mfid0: <MFI Logical Disk> on mfi0
May 18 13:52:10 gbs01-etc kernel: mfid0: 278472MB (570310656 sectors) RAID volume '' is optimal
May 18 13:52:10 gbs01-etc kernel: lapic3: Forcing LINT1 to edge trigger
May 18 13:52:10 gbs01-etc kernel: SMP: AP CPU #3 Launched!
May 18 13:52:10 gbs01-etc kernel: lapic2: Forcing LINT1 to edge trigger
May 18 13:52:10 gbs01-etc kernel: SMP: AP CPU #2 Launched!
May 18 13:52:10 gbs01-etc kernel: lapic1: Forcing LINT1 to edge trigger
May 18 13:52:10 gbs01-etc kernel: SMP: AP CPU #1 Launched!
May 18 13:52:10 gbs01-etc kernel: lapic7: Forcing LINT1 to edge trigger
May 18 13:52:10 gbs01-etc kernel: SMP: AP CPU #7 Launched!
May 18 13:52:10 gbs01-etc kernel: lapic4: Forcing LINT1 to edge trigger
May 18 13:52:10 gbs01-etc kernel: SMP: AP CPU #4 Launched!
May 18 13:52:10 gbs01-etc kernel: lapic5: Forcing LINT1 to edge trigger
May 18 13:52:10 gbs01-etc kernel: SMP: AP CPU #5 Launched!
May 18 13:52:10 gbs01-etc kernel: lapic6: Forcing LINT1 to edge trigger
May 18 13:52:10 gbs01-etc kernel: SMP: AP CPU #6 Launched!
May 18 13:52:10 gbs01-etc kernel: GEOM_JOURNAL: Journal 2994169821: mfid0s1a contains data.
May 18 13:52:10 gbs01-etc kernel: GEOM_JOURNAL: Journal 2994169821: mfid0s1a contains journal.
May 18 13:52:10 gbs01-etc kernel: GEOM_JOURNAL: Journal GmEfOiMd_0JsO1UaR NcAoLn:s iJsotuernnta.l
May 18 13:52:10 gbs01-etc kernel: 1G2E8O5M1_3J7O1U8R:N AmLf:i dB0IsO1_dF LcUoSnHt anionts  sduaptpao.rt
May 18 13:52:10 gbs01-etc kernel: eGdE ObMy_ JmOfUiRdN0AsL1:a .Jo
May 18 13:52:10 gbs01-etc kernel: urnal 128513718: mfid0s1d contains journal.
May 18 13:52:10 gbs01-etc kernel: WARNING: Expected rawoffset 0, found 63
May 18 13:52:10 gbs01-etc kernel: Root mount waiting for: GJOURNAL
May 18 13:52:10 gbs01-etc kernel: GEOM_JOURNAL: Journal mfid0s1d consistent.
May 18 13:52:10 gbs01-etc kernel: GEOM_JOURNAL: BIO_FLUSH not supported by mfid0s1d.
May 18 13:52:10 gbs01-etc kernel: Trying to mount root from ufs:/dev/mfid0s1a.journal
May 18 13:52:10 gbs01-etc kernel: WARNING: / was not properly dismounted
May 18 13:52:10 gbs01-etc kernel: WARNING: Expected rawoffset 0, found 63
May 18 13:52:10 gbs01-etc savecore: reboot after panic: lockmgr: upgrade without shared
May 18 13:52:10 gbs01-etc savecore: writing core to vmcore.0
May 18 13:52:12 gbs01-etc kernel: eth0: link state changed to UP
May 18 13:52:12 gbs01-etc kernel: eth1: link state changed to UP




-- 

**Charles Owens**
*Great Bay Software**|** m: *603.866.0860 *|** f: *603.430.0713 *|** e:
*cowens@GreatBaySoftware.com****

From chris# at 1command.com  Tue May 19 05:26:54 2009
From: chris# at 1command.com (Chris H)
Date: Tue May 19 05:27:02 2009
Subject: failed to set mtrr: invalid argument
Message-ID: <20090518222644.k2pez2x9q88o4k8g@webmail.1command.com>

Greetings,
I'm unable to get xorg-7.4 to accomodate my Gforce4 MX 440.
On 7.1-7.2 releases. I'm currently working (struggling) with
it on a 7.1 install/GENERIC with cvsup over the weekend (Sunday),
I've seen only a few discussions regarding this, but no joy.

I'm not sure what to post for additional information. So I'll
provide the output of dmesg(8), and Xorg.0.log via links.

Thank you for all your time and consideration in this matter.

Sincerely,
Chris H

Xorg log:
http://codewarehouse.NET/output/Xorg.0.log

relevent dmesg(8) output:
http://codewarehouse.NET/output/dmesg.output


From chris# at 1command.com  Tue May 19 05:42:55 2009
From: chris# at 1command.com (Chris H)
Date: Tue May 19 05:43:02 2009
Subject: failed to set mtrr: invalid argument
In-Reply-To: <20090518222644.k2pez2x9q88o4k8g@webmail.1command.com>
References: <20090518222644.k2pez2x9q88o4k8g@webmail.1command.com>
Message-ID: <20090518224246.0qrzye1z40w4ws8g@webmail.1command.com>

Quoting Chris H <chris#@1command.com>:

> Greetings,
> I'm unable to get xorg-7.4 to accomodate my Gforce4 MX 440.
> On 7.1-7.2 releases. I'm currently working (struggling) with
> it on a 7.1 install/GENERIC with cvsup over the weekend (Sunday),
> I've seen only a few discussions regarding this, but no joy.
>
> I'm not sure what to post for additional information. So I'll
> provide the output of dmesg(8), and Xorg.0.log via links.
>
> Thank you for all your time and consideration in this matter.
>
> Sincerely,
> Chris H
>
> Xorg log:
> http://codewarehouse.NET/output/Xorg.0.log
>
> relevent dmesg(8) output:
> http://codewarehouse.NET/output/dmesg.output

OOPS! I guess the xorg config might be useful:
http://codewarehouse.NET/output/xorg.conf.nvidia

>
>
> _______________________________________________
> freebsd-stable@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org"
>



From chris# at 1command.com  Tue May 19 06:20:29 2009
From: chris# at 1command.com (Chris H)
Date: Tue May 19 06:20:37 2009
Subject: failed to set mtrr: invalid argument
In-Reply-To: <20090518224246.0qrzye1z40w4ws8g@webmail.1command.com>
References: <20090518222644.k2pez2x9q88o4k8g@webmail.1command.com>
	<20090518224246.0qrzye1z40w4ws8g@webmail.1command.com>
Message-ID: <20090518232019.36g94wxl7zeo088g@webmail.1command.com>

Quoting Chris H <chris#@1command.com>:

> Quoting Chris H <chris#@1command.com>:
>
>> Greetings,
>> I'm unable to get xorg-7.4 to accomodate my Gforce4 MX 440.
>> On 7.1-7.2 releases. I'm currently working (struggling) with
>> it on a 7.1 install/GENERIC with cvsup over the weekend (Sunday),
>> I've seen only a few discussions regarding this, but no joy.
>>
>> I'm not sure what to post for additional information. So I'll
>> provide the output of dmesg(8), and Xorg.0.log via links.
>>
>> Thank you for all your time and consideration in this matter.
>>
>> Sincerely,
>> Chris H
>>
>> Xorg log:
>> http://codewarehouse.NET/output/Xorg.0.log
>>
>> relevent dmesg(8) output:
>> http://codewarehouse.NET/output/dmesg.output
>
> OOPS! I guess the xorg config might be useful:
> http://codewarehouse.NET/output/xorg.conf.nvidia
>
>>
SIGH... Seems that the registrar isn't paying attention.
They happily accepted my money, but forgot to renew the domain.

So here's trying to attach the files...

>>
>> _______________________________________________
>> freebsd-stable@freebsd.org mailing list
>> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
>> To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org"
>>
>
>
>
> _______________________________________________
> freebsd-stable@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org"
>



From onemda at gmail.com  Tue May 19 06:28:20 2009
From: onemda at gmail.com (Paul B. Mahol)
Date: Tue May 19 06:28:26 2009
Subject: failed to set mtrr: invalid argument
In-Reply-To: <20090518232019.36g94wxl7zeo088g@webmail.1command.com>
References: <20090518222644.k2pez2x9q88o4k8g@webmail.1command.com>
	<20090518224246.0qrzye1z40w4ws8g@webmail.1command.com>
	<20090518232019.36g94wxl7zeo088g@webmail.1command.com>
Message-ID: <3a142e750905182328m60439dfcgadd4c28ba037400e@mail.gmail.com>

On 5/19/09, Chris H <chris#@1command.com> wrote:
> Quoting Chris H <chris#@1command.com>:
>
>> Quoting Chris H <chris#@1command.com>:
>>
>>> Greetings,
>>> I'm unable to get xorg-7.4 to accomodate my Gforce4 MX 440.
>>> On 7.1-7.2 releases. I'm currently working (struggling) with
>>> it on a 7.1 install/GENERIC with cvsup over the weekend (Sunday),
>>> I've seen only a few discussions regarding this, but no joy.
>>>
>>> I'm not sure what to post for additional information. So I'll
>>> provide the output of dmesg(8), and Xorg.0.log via links.
>>>
>>> Thank you for all your time and consideration in this matter.
>>>
>>> Sincerely,
>>> Chris H
>>>
>>> Xorg log:
>>> http://codewarehouse.NET/output/Xorg.0.log
>>>
>>> relevent dmesg(8) output:
>>> http://codewarehouse.NET/output/dmesg.output
>>
>> OOPS! I guess the xorg config might be useful:
>> http://codewarehouse.NET/output/xorg.conf.nvidia
>>
>>>
> SIGH... Seems that the registrar isn't paying attention.
> They happily accepted my money, but forgot to renew the domain.
>
> So here's trying to attach the files...

That message appears for me only when I use xf86-video-vesa driver.

-- 
Paul
From chris# at 1command.com  Tue May 19 06:40:24 2009
From: chris# at 1command.com (Chris H)
Date: Tue May 19 06:40:37 2009
Subject: failed to set mtrr: invalid argument
In-Reply-To: <3a142e750905182328m60439dfcgadd4c28ba037400e@mail.gmail.com>
References: <20090518222644.k2pez2x9q88o4k8g@webmail.1command.com>
	<20090518224246.0qrzye1z40w4ws8g@webmail.1command.com>
	<20090518232019.36g94wxl7zeo088g@webmail.1command.com>
	<3a142e750905182328m60439dfcgadd4c28ba037400e@mail.gmail.com>
Message-ID: <20090518234011.k55bmqq3488kko8c@webmail.1command.com>

Quoting "Paul B. Mahol" <onemda@gmail.com>:

> On 5/19/09, Chris H <chris#@1command.com> wrote:
>> Quoting Chris H <chris#@1command.com>:
>>
>>> Quoting Chris H <chris#@1command.com>:
>>>
>>>> Greetings,
>>>> I'm unable to get xorg-7.4 to accomodate my Gforce4 MX 440.
>>>> On 7.1-7.2 releases. I'm currently working (struggling) with
>>>> it on a 7.1 install/GENERIC with cvsup over the weekend (Sunday),
>>>> I've seen only a few discussions regarding this, but no joy.
>>>>
>>>> I'm not sure what to post for additional information. So I'll
>>>> provide the output of dmesg(8), and Xorg.0.log via links.
>>>>
>>>> Thank you for all your time and consideration in this matter.
>>>>
>>>> Sincerely,
>>>> Chris H
>>>>
>>>> Xorg log:
>>>> http://codewarehouse.NET/output/Xorg.0.log
>>>>
>>>> relevent dmesg(8) output:
>>>> http://codewarehouse.NET/output/dmesg.output
>>>
>>> OOPS! I guess the xorg config might be useful:
>>> http://codewarehouse.NET/output/xorg.conf.nvidia
>>>
>>>>
>> SIGH... Seems that the registrar isn't paying attention.
>> They happily accepted my money, but forgot to renew the domain.
>>
>> So here's trying to attach the files...
>
> That message appears for me only when I use xf86-video-vesa driver.

I see. Well I'm specifically using the nv driver. Here's another
attempt to provide the relevant info:

Xorg log:
X.Org X Server 1.6.0
Release Date: 2009-2-25
X Protocol Version 11, Revision 0
Build Operating System: FreeBSD 7.1-RELEASE i386 Current Operating 
System: FreeBSD udns 7.1-RELEASE FreeBSD 7.1-RELEASE #0: Thu Jan  1 
14:37:25 UTC 2009     
root@logan.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC i386
Build Date: 16 May 2009  07:15:01AM

	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 May 18 20:34:43 2009
(++) Using config file: "/etc/X11/xorg.conf.nvidia"
(==) ServerLayout "X.org Configured"
(**) |-->Screen "Screen0" (0)
(**) |   |-->Monitor "Monitor1"
(**) |   |-->Device "Card1"
(**) |-->Input Device "Mouse0"
(**) |-->Input Device "Keyboard0"
(**) Option "AllowEmptyInput" "false"
(==) Automatically adding devices
(==) Automatically enabling devices
(WW) The directory "/usr/local/lib/X11/fonts/Type1/" does not exist.
	Entry deleted from font path.
(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/").
(WW) `fonts.dir' not found (or not valid) in 
"/usr/local/lib/X11/fonts/75dpi/".
	Entry deleted from font path.
	(Run 'mkfontdir' on "/usr/local/lib/X11/fonts/75dpi/").
(WW) The directory "/usr/local/lib/X11/fonts/Type1/" does not exist.
	Entry deleted from font path.
(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/").
(WW) `fonts.dir' not found (or not valid) in 
"/usr/local/lib/X11/fonts/75dpi/".
	Entry deleted from font path.
	(Run 'mkfontdir' on "/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/misc/,
	/usr/local/lib/X11/fonts/TTF/,
	/usr/local/lib/X11/fonts/OTF,
	built-ins
(**) ModulePath set to "/usr/local/lib/xorg/modules"
(II) Loader magic: 0x6a0
(II) Module ABI versions:
	X.Org ANSI C Emulation: 0.4
	X.Org Video Driver: 5.0
	X.Org XInput driver : 4.0
	X.Org Server Extension : 2.0
(II) Loader running on freebsd
(--) Using syscons driver with X support (version 2.0)
(--) using VT number 9

(!!) More than one possible primary device found
(--) PCI: (0@0:1:0) ATI Technologies Inc Rage XL rev 39, Mem @ 
0xfb000000/16777216, 0xfcaff000/4096, I/O @ 0x0000d800/256, BIOS @ 
0x????????/131072
(--) PCI: (0@1:2:0) nVidia Corporation NV17 [GeForce4 MX 440] rev 163, 
Mem @ 0xfd000000/16777216, 0xf0000000/134217728, 0xfa580000/524288, 
BIOS @ 0x????????/131072
(II) System resource ranges:
	[0] -1	0	0x000f0000 - 0x000fffff (0x10000) MX[B]
	[1] -1	0	0x000c0000 - 0x000effff (0x30000) MX[B]
	[2] -1	0	0x00000000 - 0x0009ffff (0xa0000) MX[B]
	[3] -1	0	0x0000ffff - 0x0000ffff (0x1) IX[B]
	[4] -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) "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) "dri2" 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.6.0, module version = 1.0.0
	Module class: X.Org Server Extension
	ABI class: X.Org Server Extension, version 2.0
(II) Loading extension MIT-SCREEN-SAVER
(II) Loading extension XFree86-VidModeExtension
(II) Loading extension XFree86-DGA
(II) Loading extension DPMS
(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.6.0, module version = 1.13.0
	Module class: X.Org Server Extension
	ABI class: X.Org Server Extension, version 2.0
(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.6.0, module version = 1.0.0
	Module class: X.Org Server Extension
	ABI class: X.Org Server Extension, version 2.0
(II) Loading extension DOUBLE-BUFFER
(II) LoadModule: "extmod"
(II) Reloading /usr/local/lib/xorg/modules/extensions//libextmod.so
(II) Loading extension MIT-SCREEN-SAVER
(II) Loading extension XFree86-VidModeExtension
(II) Loading extension DPMS
(II) Loading extension XVideo
(II) Loading extension XVideo-MotionCompensation
(II) Loading extension X-Resource
(II) LoadModule: "glx"
(II) Loading /usr/local/lib/xorg/modules/extensions//libglx.so
(II) Module glx: vendor="X.Org Foundation"
	compiled for 1.6.0, module version = 1.0.0
	ABI class: X.Org Server Extension, version 2.0
(==) AIGLX disabled
(II) Loading extension GLX
(II) LoadModule: "dri"
(II) Loading /usr/local/lib/xorg/modules/extensions//libdri.so
(II) Module dri: vendor="X.Org Foundation"
	compiled for 1.6.0, module version = 1.0.0
	ABI class: X.Org Server Extension, version 2.0
(II) Loading extension XFree86-DRI
(II) LoadModule: "dri2"
(II) Loading /usr/local/lib/xorg/modules/extensions//libdri2.so
(II) Module dri2: vendor="X.Org Foundation"
	compiled for 1.6.0, module version = 1.0.0
	ABI class: X.Org Server Extension, version 2.0
(II) Loading extension DRI2
(II) LoadModule: "nv"
(II) Loading /usr/local/lib/xorg/modules/drivers//nv_drv.so
(II) Module nv: vendor="X.Org Foundation"
	compiled for 1.6.0, module version = 2.1.13
	Module class: X.Org Video Driver
	ABI class: X.Org Video Driver, version 5.0
(II) LoadModule: "mouse"
(II) Loading /usr/local/lib/xorg/modules/input//mouse_drv.so
(II) Module mouse: vendor="X.Org Foundation"
	compiled for 1.6.0, module version = 1.4.0
	Module class: X.Org XInput Driver
	ABI class: X.Org XInput driver, version 4.0
(II) LoadModule: "kbd"
(II) Loading /usr/local/lib/xorg/modules/input//kbd_drv.so
(II) Module kbd: vendor="X.Org Foundation"
	compiled for 1.6.0, module version = 1.3.2
	Module class: X.Org XInput Driver
	ABI class: X.Org XInput driver, version 4.0
(II) NV: driver for NVIDIA chipsets: RIVA 128, RIVA TNT, RIVA TNT2,
	Unknown TNT2, Vanta, RIVA TNT2 Ultra, RIVA TNT2 Model 64,
	Aladdin TNT2, GeForce 256, GeForce DDR, Quadro, GeForce2 MX/MX 400,
	GeForce2 MX 100/200, GeForce2 Go, Quadro2 MXR/EX/Go,
	GeForce2 Integrated GPU, GeForce2 GTS, GeForce2 Ti, GeForce2 Ultra,
	Quadro2 Pro, GeForce4 MX 460, GeForce4 MX 440, GeForce4 MX 420,
	GeForce4 MX 440-SE, GeForce4 440 Go, GeForce4 420 Go,
	GeForce4 420 Go 32M, GeForce4 460 Go, Quadro4 550 XGL,
	GeForce4 440 Go 64M, Quadro NVS, Quadro4 500 GoGL,
	GeForce4 410 Go 16M, GeForce4 MX 440 with AGP8X,
	GeForce4 MX 440SE with AGP8X, GeForce4 MX 420 with AGP8X,
	GeForce4 MX 4000, GeForce4 448 Go, GeForce4 488 Go, Quadro4 580 XGL,
	Quadro4 NVS 280 SD, Quadro4 380 XGL, Quadro NVS 50 PCI,
	GeForce4 448 Go, GeForce4 MX Integrated GPU, GeForce3,
	GeForce3 Ti 200, GeForce3 Ti 500, Quadro DCC, GeForce4 Ti 4600,
	GeForce4 Ti 4400, GeForce4 Ti 4200, Quadro4 900 XGL, Quadro4 750 XGL,
	Quadro4 700 XGL, GeForce4 Ti 4800, GeForce4 Ti 4200 with AGP8X,
	GeForce4 Ti 4800 SE, GeForce4 4200 Go, Quadro4 700 GoGL,
	Quadro4 980 XGL, Quadro4 780 XGL, GeForce FX 5800 Ultra,
	GeForce FX 5800, Quadro FX 2000, Quadro FX 1000,
	GeForce FX 5600 Ultra, GeForce FX 5600, GeForce FX 5600XT,
	GeForce FX Go5600, GeForce FX Go5650, Quadro FX Go700,
	GeForce FX 5200, GeForce FX 5200 Ultra, GeForce FX 5200,
	GeForce FX 5200LE, GeForce FX Go5200, GeForce FX Go5250,
	GeForce FX 5500, GeForce FX 5100, GeForce FX Go5200 32M/64M,
	Quadro NVS 55/280 PCI, Quadro FX 500/600 PCI,
	GeForce FX Go53xx Series, GeForce FX Go5100, GeForce FX 5900 Ultra,
	GeForce FX 5900, GeForce FX 5900XT, GeForce FX 5950 Ultra,
	GeForce FX 5900ZT, Quadro FX 3000, Quadro FX 700,
	GeForce FX 5700 Ultra, GeForce FX 5700, GeForce FX 5700LE,
	GeForce FX 5700VE, GeForce FX Go5700, GeForce FX Go5700,
	Quadro FX Go1000, Quadro FX 1100, GeForce 6800 Ultra, GeForce 6800,
	GeForce 6800 LE, GeForce 6800 XE, GeForce 6800 XT, GeForce 6800 GT,
	GeForce 6800 GT, GeForce 6800 GS, GeForce 6800 XT, Quadro FX 4000,
	GeForce 6800 GS, GeForce 6800, GeForce 6800 LE, GeForce 6800 XT,
	GeForce Go 6800, GeForce Go 6800 Ultra, Quadro FX Go1400,
	Quadro FX 3450/4000 SDI, Quadro FX 1400, GeForce 6600 GT,
	GeForce 6600, GeForce 6600 LE, GeForce 6600 VE, GeForce Go 6600,
	GeForce 6610 XL, GeForce Go 6600 TE/6200 TE, GeForce 6700 XL,
	GeForce Go 6600, GeForce Go 6600 GT, Quadro FX 550, Quadro FX 550,
	Quadro FX 540, GeForce 6200, GeForce 6500,
	GeForce 6200 TurboCache(TM), GeForce 6200SE TurboCache(TM),
	GeForce 6200 LE, GeForce Go 6200, Quadro NVS 285, GeForce Go 6400,
	GeForce Go 6200, GeForce Go 6400, GeForce 6250, GeForce 7100 GS,
	GeForce 6800, GeForce 6800 LE, GeForce 6800 GT, GeForce 6800 XT,
	GeForce 6200, GeForce 6200 A-LE, GeForce 7800 GTX, GeForce 7800 GTX,
	GeForce 7800 GT, GeForce 7800 GS, GeForce 7800 SLI, GeForce Go 7800,
	GeForce Go 7800 GTX, Quadro FX 4500, GeForce 7300 LE,
	GeForce 7300 SE, GeForce Go 7200, GeForce Go 7300, GeForce Go 7400,
	GeForce Go 7400 GS, Quadro NVS 110M, Quadro NVS 120M, Quadro FX 350M,
	GeForce 7500 LE, Quadro FX 350, GeForce 7300 GS, GeForce 7600 GT,
	GeForce 7600 GS, GeForce 7300 GT, GeForce 7600 LE, GeForce 7300 GT,
	GeForce Go 7700, GeForce Go 7600, GeForce Go 7600 GT,
	Quadro NVS 300M, GeForce Go 7900 SE, Quadro FX 550M, Quadro FX 560,
	GeForce 7900 GTX, GeForce 7900 GT, GeForce 7900 GS,
	GeForce Go 7900 GS, GeForce Go 7900 GTX, Quadro FX 2500M,
	Quadro FX 1500M, Quadro FX 5500, Quadro FX 3500, Quadro FX 1500,
	Quadro FX 4500 X2, GeForce 6150, GeForce 6150 LE, GeForce 6100,
	GeForce Go 6150, GeForce Go 6100, GeForce 8800 GTX, GeForce 8800 GTS,
	GeForce 8800 Ultra, Quadro FX 5600, Quadro FX 4600, GeForce 8600 GTS,
	GeForce 8600 GT, GeForce 8600 GT, GeForce 8600 GS, GeForce 8400 GS,
	GeForce 9500M GS, GeForce 8600M GT, GeForce 9650M GS,
	GeForce 8700M GT, Quadro FX 370, Quadro NVS 320M, Quadro FX 570M,
	Quadro FX 1600M, Quadro FX 570, Quadro FX 1700, GeForce 8400 SE,
	GeForce 8500 GT, GeForce 8400 GS, GeForce 8300 GS, GeForce 8400 GS,
	GeForce 8600M GS, GeForce 8400M GT, GeForce 8400M GS,
	GeForce 8400M G, Quadro NVS 140M, Quadro NVS 130M, Quadro NVS 135M,
	GeForce 9400 GT, Quadro FX 360M, GeForce 9300M G, Quadro NVS 290,
	GeForce GTX 280, GeForce GTX 260, GeForce 8800 GTS 512,
	GeForce 8800 GT, GeForce 9800 GX2, GeForce 8800 GS,
	GeForce 8800M GTS, GeForce 8800M GTX, GeForce 8800 GS,
	GeForce 9600 GSO, GeForce 8800 GT, GeForce 9800 GTX,
	GeForce 9800 GTK+, GeForce 9800 GT, Quadro FX 3700, Quadro FX 3600M,
	GeForce 9600 GT, GeForce 9600 GS, GeForce 9800M GTS,
	GeForce 9700M GTS, GeForce 9800M GTS, GeForce 9500 GT,
	GeForce 9600M GT, GeForce 9600M GS, GeForce 9600M GT,
	GeForce 9500M G, GeForce 9300 GS, GeForce 8400 GS, GeForce 9300M GS,
	GeForce 9200M GS, GeForce 9300M GS, Quadro NVS 150M, Quadro NVS 160M
(II) Primary Device is: (--) NV: Found NVIDIA GeForce4 MX 440 at 01@00:02:0
(II) resource ranges after probing:
	[0] -1	0	0x000f0000 - 0x000fffff (0x10000) MX[B]
	[1] -1	0	0x000c0000 - 0x000effff (0x30000) MX[B]
	[2] -1	0	0x00000000 - 0x0009ffff (0xa0000) MX[B]
	[3] -1	0	0x0000ffff - 0x0000ffff (0x1) IX[B]
	[4] -1	0	0x00000000 - 0x000000ff (0x100) IX[B]
(II) Loading sub module "int10"
(II) LoadModule: "int10"
(II) Loading /usr/local/lib/xorg/modules//libint10.so
(II) Module int10: vendor="X.Org Foundation"
	compiled for 1.6.0, module version = 1.0.0
	ABI class: X.Org Video Driver, version 5.0
(II) NV(0): Initializing int10
(==) NV(0): Write-combining range (0xa0000,0x20000) was already clear
(==) NV(0): Write-combining range (0xc0000,0x40000) was already clear
(--) NV(0): Chipset: "GeForce4 MX 440"
(**) NV(0): Depth 24, (--) framebuffer bpp 32
(==) NV(0): RGB weight 888
(==) NV(0): Default visual is TrueColor
(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.6.0, module version = 0.1.0
	ABI class: X.Org Video Driver, version 5.0
(**) NV(0): Option "CrtcNumber" "0"
(==) NV(0): Using HW cursor
(--) NV(0): Linear framebuffer at 0xF0000000
(--) NV(0): MMIO registers at 0xFD000000
(II) Loading sub module "i2c"
(II) LoadModule: "i2c"
(II) Module "i2c" already built-in
(II) Loading sub module "ddc"
(II) LoadModule: "ddc"
(II) Module "ddc" already built-in
(II) NV(0): I2C bus "DDC" initialized.
(II) NV(0): Probing for analog device on output A...
(--) NV(0):   ...found one
(II) NV(0): Probing for analog device on output B...
(--) NV(0):   ...can't find one
(II) NV(0): Probing for EDID on I2C bus A...
(II) NV(0): I2C device "DDC:E-EDID segment register" registered at 
address 0x60.
(II) NV(0): I2C device "DDC:ddc2" registered at address 0xA0.
(--) NV(0): DDC detected a CRT:
(II) NV(0): Manufacturer: RDS  Model: 2115  Serial#: 844
(II) NV(0): Year: 1999  Week: 11
(II) NV(0): EDID Version: 1.1
(II) NV(0): Analog Display Input,  Input Voltage Level: 0.700/0.300 V
(II) NV(0): Sync:  Separate  Composite  SyncOnGreen
(II) NV(0): Max Image Size [cm]: horiz.: 38  vert.: 28
(II) NV(0): Gamma: 2.05
(II) NV(0): DPMS capabilities: StandBy Suspend Off; RGB/Color Display
(II) NV(0): GTF timings supported
(II) NV(0): redX: 0.625 redY: 0.340   greenX: 0.290 greenY: 0.605
(II) NV(0): blueX: 0.150 blueY: 0.070   whiteX: 0.283 whiteY: 0.297
(II) NV(0): Supported VESA Video Modes:
(II) NV(0): 720x400@70Hz
(II) NV(0): 720x400@88Hz
(II) NV(0): 640x480@60Hz
(II) NV(0): 640x480@67Hz
(II) NV(0): 640x480@72Hz
(II) NV(0): 640x480@75Hz
(II) NV(0): 800x600@56Hz
(II) NV(0): 800x600@60Hz
(II) NV(0): 800x600@72Hz
(II) NV(0): 800x600@75Hz
(II) NV(0): 832x624@75Hz
(II) NV(0): 1024x768@60Hz
(II) NV(0): 1024x768@70Hz
(II) NV(0): 1024x768@75Hz
(II) NV(0): 1280x1024@75Hz
(II) NV(0): 1152x870@75Hz
(II) NV(0): Manufacturer's mask: 0
(II) NV(0): Supported Future Video Modes:
(II) NV(0): #0: hsize: 800  vsize 600  refresh: 85  vid: 22853
(II) NV(0): #1: hsize: 1024  vsize 768  refresh: 85  vid: 22881
(II) NV(0): #2: hsize: 1280  vsize 1024  refresh: 85  vid: 39297
(II) NV(0): #3: hsize: 1600  vsize 1200  refresh: 85  vid: 22953
(II) NV(0): #4: hsize: 1800  vsize 1440  refresh: 76  vid: 37058
(II) NV(0): #5: hsize: 1152  vsize 864  refresh: 85  vid: 22897
(II) NV(0): #6: hsize: 1360  vsize 1020  refresh: 75  vid: 20363
(II) NV(0): #7: hsize: 1600  vsize 1200  refresh: 75  vid: 20393
(II) NV(0): Supported additional Video Mode:
(II) NV(0): clock: 252.2 MHz   Image Size:  380 x 285 mm
(II) NV(0): h_active: 1600  h_sync: 1728  h_sync_end 1904 h_blank_end 
2208 h_border: 0
(II) NV(0): v_active: 1280  v_sync: 1281  v_sync_end 1284 v_blanking: 
1344 v_border: 0
(II) NV(0): Ranges: V min: 50 V max: 152 Hz, H min: 30 H max: 115 kHz, 
PixClock max 290 MHz
(II) NV(0): Monitor name: PressView XL
(II) NV(0): Serial No: 903500844
(II) NV(0): EDID (in hex):
(II) NV(0): 	00ffffffffffff00489315214c030000
(II) NV(0): 	0b0901010e261c69e90488a0574a9b26
(II) NV(0): 	12484cffef80455961598199a959c290
(II) NV(0): 	71598b4fa94f886240606200405080b0
(II) NV(0): 	13007c1d1100001e000000fd0032981e
(II) NV(0): 	731d000a202020202020000000fc0050
(II) NV(0): 	726573735669657720584c0a000000ff
(II) NV(0): 	003930333530303834340a2020200078
(II) NV(0): Probing for EDID on I2C bus B...
(II) NV(0):   ... none found
(--) NV(0): CRTC 0 appears to have a CRT attached
(**) NV(0): Forcing CRTCNumber 0 as specified
(II) NV(0): Using CRT on CRTC 0
(II) NV(0): EDID vendor "RDS", prod id 8469
(II) NV(0): Using EDID range info for horizontal sync
(II) NV(0): Using EDID range info for vertical refresh
(II) NV(0): Printing DDC gathered Modelines:
(II) NV(0): Modeline "1600x1280"x0.0  252.24  1600 1728 1904 2208  1280 
1281 1284 1344 +hsync +vsync (114.2 kHz)
(II) NV(0): Modeline "800x600"x0.0   40.00  800 840 968 1056  600 601 
605 628 +hsync +vsync (37.9 kHz)
(II) NV(0): Modeline "800x600"x0.0   36.00  800 824 896 1024  600 601 
603 625 +hsync +vsync (35.2 kHz)
(II) NV(0): Modeline "640x480"x0.0   31.50  640 656 720 840  480 481 
484 500 -hsync -vsync (37.5 kHz)
(II) NV(0): Modeline "640x480"x0.0   31.50  640 664 704 832  480 489 
492 520 -hsync -vsync (37.9 kHz)
(II) NV(0): Modeline "640x480"x0.0   30.24  640 704 768 864  480 483 
486 525 -hsync -vsync (35.0 kHz)
(II) NV(0): Modeline "640x480"x0.0   25.18  640 656 752 800  480 490 
492 525 -hsync -vsync (31.5 kHz)
(II) NV(0): Modeline "720x400"x0.0   35.50  720 738 846 900  400 421 
423 449 -hsync -vsync (39.4 kHz)
(II) NV(0): Modeline "720x400"x0.0   28.32  720 738 846 900  400 412 
414 449 -hsync +vsync (31.5 kHz)
(II) NV(0): Modeline "1280x1024"x0.0  135.00  1280 1296 1440 1688  1024 
1025 1028 1066 +hsync +vsync (80.0 kHz)
(II) NV(0): Modeline "1024x768"x0.0   78.75  1024 1040 1136 1312  768 
769 772 800 +hsync +vsync (60.0 kHz)
(II) NV(0): Modeline "1024x768"x0.0   75.00  1024 1048 1184 1328  768 
771 777 806 -hsync -vsync (56.5 kHz)
(II) NV(0): Modeline "1024x768"x0.0   65.00  1024 1048 1184 1344  768 
771 777 806 -hsync -vsync (48.4 kHz)
(II) NV(0): Modeline "832x624"x0.0   57.28  832 864 928 1152  624 625 
628 667 -hsync -vsync (49.7 kHz)
(II) NV(0): Modeline "800x600"x0.0   49.50  800 816 896 1056  600 601 
604 625 +hsync +vsync (46.9 kHz)
(II) NV(0): Modeline "800x600"x0.0   50.00  800 856 976 1040  600 637 
643 666 +hsync +vsync (48.1 kHz)
(II) NV(0): Modeline "1152x864"x0.0  108.00  1152 1216 1344 1600  864 
865 868 900 +hsync +vsync (67.5 kHz)
(II) NV(0): Modeline "800x600"x0.0   56.25  800 832 896 1048  600 601 
604 631 +hsync +vsync (53.7 kHz)
(II) NV(0): Modeline "1024x768"x0.0   94.50  1024 1072 1168 1376  768 
769 772 808 +hsync +vsync (68.7 kHz)
(II) NV(0): Modeline "1280x1024"x0.0  157.50  1280 1344 1504 1728  1024 
1025 1028 1072 +hsync +vsync (91.1 kHz)
(II) NV(0): Modeline "1600x1200"x0.0  229.50  1600 1664 1856 2160  1200 
1201 1204 1250 +hsync +vsync (106.2 kHz)
(II) NV(0): Modeline "1600x1200"x0.0  202.50  1600 1664 1856 2160  1200 
1201 1204 1250 +hsync +vsync (93.8 kHz)
(--) NV(0): VideoRAM: 65536 kBytes
(==) NV(0): Using gamma correction (1.0, 1.0, 1.0)
(II) NV(0): Monitor1: Using hsync range of 30.00-115.00 kHz
(II) NV(0): Monitor1: Using vrefresh range of 50.00-152.00 Hz
(II) NV(0): Monitor1: Using maximum pixel clock of 290.00 MHz
(II) NV(0): Clock range:  12.00 to 350.00 MHz
(II) NV(0): Not using default mode "1024x768" (bad mode 
clock/interlace/doublescan)
(II) NV(0): Not using default mode "512x384" (bad mode 
clock/interlace/doublescan)
(II) NV(0): Not using default mode "1920x1440" (mode clock too high)
(II) NV(0): Not using default mode "1920x1440" (hsync out of range)
(II) NV(0): Not using default mode "960x720" (hsync out of range)
(II) NV(0): Not using default mode "2048x1536" (hsync out of range)
(II) NV(0): Not using default mode "1024x768" (hsync out of range)
(II) NV(0): Not using default mode "2048x1536" (bad mode 
clock/interlace/doublescan)
(II) NV(0): Not using default mode "1024x768" (hsync out of range)
(II) NV(0): Not using mode "1152x864" (no mode of this name)
(II) NV(0): Not using default mode "2048x1536" (width too large for 
virtual size)
(II) NV(0): Not using default mode "1920x1440" (width too large for 
virtual size)
(II) NV(0): Not using default mode "1856x1392" (width too large for 
virtual size)
(II) NV(0): Not using default mode "1856x1392" (width too large for 
virtual size)
(II) NV(0): Not using default mode "1792x1344" (width too large for 
virtual size)
(II) NV(0): Not using default mode "1792x1344" (width too large for 
virtual size)
(II) NV(0): Not using driver mode "1600x1280" (width too large for 
virtual size)
(II) NV(0): Not using driver mode "1600x1200" (width too large for 
virtual size)
(II) NV(0): Not using driver mode "1600x1200" (width too large for 
virtual size)
(II) NV(0): Not using default mode "1600x1200" (width too large for 
virtual size)
(II) NV(0): Not using default mode "1600x1200" (width too large for 
virtual size)
(II) NV(0): Not using default mode "1600x1200" (width too large for 
virtual size)
(II) NV(0): Not using default mode "1600x1200" (width too large for 
virtual size)
(II) NV(0): Not using default mode "1600x1200" (width too large for 
virtual size)
(II) NV(0): Not using default mode "1400x1050" (width too large for 
virtual size)
(II) NV(0): Not using default mode "1400x1050" (width too large for 
virtual size)
(II) NV(0): Not using driver mode "1280x1024" (width too large for 
virtual size)
(II) NV(0): Not using driver mode "1280x1024" (width too large for 
virtual size)
(II) NV(0): Not using default mode "1280x1024" (width too large for 
virtual size)
(II) NV(0): Not using default mode "1280x1024" (width too large for 
virtual size)
(II) NV(0): Not using default mode "1280x1024" (width too large for 
virtual size)
(II) NV(0): Not using default mode "1280x960" (width too large for 
virtual size)
(II) NV(0): Not using default mode "1280x960" (width too large for 
virtual size)
(--) NV(0): Virtual size is 1152x864 (pitch 1152)
(**) NV(0): *Driver mode "1152x864": 108.0 MHz, 67.5 kHz, 75.0 Hz
(II) NV(0): Modeline "1152x864"x75.0  108.00  1152 1216 1344 1600  864 
865 868 900 +hsync +vsync (67.5 kHz)
(**) NV(0): *Default mode "1152x864": 108.0 MHz, 67.5 kHz, 75.0 Hz
(II) NV(0): Modeline "1152x864"x75.0  108.00  1152 1216 1344 1600  864 
865 868 900 +hsync +vsync (67.5 kHz)
(**) NV(0):  Driver mode "1024x768": 94.5 MHz, 68.7 kHz, 85.0 Hz
(II) NV(0): Modeline "1024x768"x85.0   94.50  1024 1072 1168 1376  768 
769 772 808 +hsync +vsync (68.7 kHz)
(**) NV(0):  Driver mode "1024x768": 78.8 MHz, 60.0 kHz, 75.0 Hz
(II) NV(0): Modeline "1024x768"x75.0   78.75  1024 1040 1136 1312  768 
769 772 800 +hsync +vsync (60.0 kHz)
(**) NV(0):  Driver mode "1024x768": 75.0 MHz, 56.5 kHz, 70.1 Hz
(II) NV(0): Modeline "1024x768"x70.1   75.00  1024 1048 1184 1328  768 
771 777 806 -hsync -vsync (56.5 kHz)
(**) NV(0):  Driver mode "1024x768": 65.0 MHz, 48.4 kHz, 60.0 Hz
(II) NV(0): Modeline "1024x768"x60.0   65.00  1024 1048 1184 1344  768 
771 777 806 -hsync -vsync (48.4 kHz)
(**) NV(0):  Default mode "1024x768": 94.5 MHz, 68.7 kHz, 85.0 Hz
(II) NV(0): Modeline "1024x768"x85.0   94.50  1024 1072 1168 1376  768 
769 772 808 +hsync +vsync (68.7 kHz)
(**) NV(0):  Default mode "1024x768": 78.8 MHz, 60.0 kHz, 75.0 Hz
(II) NV(0): Modeline "1024x768"x75.0   78.75  1024 1040 1136 1312  768 
769 772 800 +hsync +vsync (60.0 kHz)
(**) NV(0):  Default mode "1024x768": 75.0 MHz, 56.5 kHz, 70.1 Hz
(II) NV(0): Modeline "1024x768"x70.1   75.00  1024 1048 1184 1328  768 
771 777 806 -hsync -vsync (56.5 kHz)
(**) NV(0):  Default mode "1024x768": 133.5 MHz, 95.3 kHz, 60.0 Hz (D)
(II) NV(0): Modeline "1024x768"x60.0  133.47  1024 1100 1212 1400  768 
768 770 794 doublescan -hsync +vsync (95.3 kHz)
(**) NV(0):  Default mode "1024x768": 65.0 MHz, 48.4 kHz, 60.0 Hz
(II) NV(0): Modeline "1024x768"x60.0   65.00  1024 1048 1184 1344  768 
771 777 806 -hsync -vsync (48.4 kHz)
(**) NV(0):  Default mode "960x720": 148.5 MHz, 112.5 kHz, 75.0 Hz (D)
(II) NV(0): Modeline "960x720"x75.0  148.50  960 1032 1144 1320  720 
720 722 750 doublescan -hsync +vsync (112.5 kHz)
(**) NV(0):  Default mode "960x720": 117.0 MHz, 90.0 kHz, 60.0 Hz (D)
(II) NV(0): Modeline "960x720"x60.0  117.00  960 1024 1128 1300  720 
720 722 750 doublescan -hsync +vsync (90.0 kHz)
(**) NV(0):  Default mode "928x696": 144.0 MHz, 112.5 kHz, 75.0 Hz (D)
(II) NV(0): Modeline "928x696"x75.0  144.00  928 992 1104 1280  696 696 
698 750 doublescan -hsync +vsync (112.5 kHz)
(**) NV(0):  Default mode "928x696": 109.2 MHz, 86.4 kHz, 60.1 Hz (D)
(II) NV(0): Modeline "928x696"x60.1  109.15  928 976 1088 1264  696 696 
698 719 doublescan -hsync +vsync (86.4 kHz)
(**) NV(0):  Default mode "896x672": 130.5 MHz, 106.3 kHz, 75.0 Hz (D)
(II) NV(0): Modeline "896x672"x75.0  130.50  896 944 1052 1228  672 672 
674 708 doublescan -hsync +vsync (106.3 kHz)
(**) NV(0):  Default mode "896x672": 102.4 MHz, 83.7 kHz, 60.0 Hz (D)
(II) NV(0): Modeline "896x672"x60.0  102.40  896 960 1060 1224  672 672 
674 697 doublescan -hsync +vsync (83.7 kHz)
(**) NV(0):  Driver mode "832x624": 57.3 MHz, 49.7 kHz, 74.6 Hz
(II) NV(0): Modeline "832x624"x74.6   57.28  832 864 928 1152  624 625 
628 667 -hsync -vsync (49.7 kHz)
(**) NV(0):  Default mode "832x624": 57.3 MHz, 49.7 kHz, 74.6 Hz
(II) NV(0): Modeline "832x624"x74.6   57.28  832 864 928 1152  624 625 
628 667 -hsync -vsync (49.7 kHz)
(**) NV(0):  Driver mode "800x600": 56.2 MHz, 53.7 kHz, 85.1 Hz
(II) NV(0): Modeline "800x600"x85.1   56.25  800 832 896 1048  600 601 
604 631 +hsync +vsync (53.7 kHz)
(**) NV(0):  Driver mode "800x600": 49.5 MHz, 46.9 kHz, 75.0 Hz
(II) NV(0): Modeline "800x600"x75.0   49.50  800 816 896 1056  600 601 
604 625 +hsync +vsync (46.9 kHz)
(**) NV(0):  Driver mode "800x600": 50.0 MHz, 48.1 kHz, 72.2 Hz
(II) NV(0): Modeline "800x600"x72.2   50.00  800 856 976 1040  600 637 
643 666 +hsync +vsync (48.1 kHz)
(**) NV(0):  Driver mode "800x600": 40.0 MHz, 37.9 kHz, 60.3 Hz
(II) NV(0): Modeline "800x600"x60.3   40.00  800 840 968 1056  600 601 
605 628 +hsync +vsync (37.9 kHz)
(**) NV(0):  Driver mode "800x600": 36.0 MHz, 35.2 kHz, 56.2 Hz
(II) NV(0): Modeline "800x600"x56.2   36.00  800 824 896 1024  600 601 
603 625 +hsync +vsync (35.2 kHz)
(**) NV(0):  Default mode "800x600": 56.3 MHz, 53.7 kHz, 85.1 Hz
(II) NV(0): Modeline "800x600"x85.1   56.30  800 832 896 1048  600 601 
604 631 +hsync +vsync (53.7 kHz)
(**) NV(0):  Default mode "800x600": 114.8 MHz, 106.2 kHz, 85.0 Hz (D)
(II) NV(0): Modeline "800x600"x85.0  114.75  800 832 928 1080  600 600 
602 625 doublescan +hsync +vsync (106.2 kHz)
(**) NV(0):  Default mode "800x600": 49.5 MHz, 46.9 kHz, 75.0 Hz
(II) NV(0): Modeline "800x600"x75.0   49.50  800 816 896 1056  600 601 
604 625 +hsync +vsync (46.9 kHz)
(**) NV(0):  Default mode "800x600": 101.2 MHz, 93.8 kHz, 75.0 Hz (D)
(II) NV(0): Modeline "800x600"x75.0  101.25  800 832 928 1080  600 600 
602 625 doublescan +hsync +vsync (93.8 kHz)
(**) NV(0):  Default mode "800x600": 50.0 MHz, 48.1 kHz, 72.2 Hz
(II) NV(0): Modeline "800x600"x72.2   50.00  800 856 976 1040  600 637 
643 666 +hsync +vsync (48.1 kHz)
(**) NV(0):  Default mode "800x600": 94.5 MHz, 87.5 kHz, 70.0 Hz (D)
(II) NV(0): Modeline "800x600"x70.0   94.50  800 832 928 1080  600 600 
602 625 doublescan +hsync +vsync (87.5 kHz)
(**) NV(0):  Default mode "800x600": 87.8 MHz, 81.2 kHz, 65.0 Hz (D)
(II) NV(0): Modeline "800x600"x65.0   87.75  800 832 928 1080  600 600 
602 625 doublescan +hsync +vsync (81.2 kHz)
(**) NV(0):  Default mode "800x600": 40.0 MHz, 37.9 kHz, 60.3 Hz
(II) NV(0): Modeline "800x600"x60.3   40.00  800 840 968 1056  600 601 
605 628 +hsync +vsync (37.9 kHz)
(**) NV(0):  Default mode "800x600": 81.0 MHz, 75.0 kHz, 60.0 Hz (D)
(II) NV(0): Modeline "800x600"x60.0   81.00  800 832 928 1080  600 600 
602 625 doublescan +hsync +vsync (75.0 kHz)
(**) NV(0):  Default mode "800x600": 36.0 MHz, 35.2 kHz, 56.2 Hz
(II) NV(0): Modeline "800x600"x56.2   36.00  800 824 896 1024  600 601 
603 625 +hsync +vsync (35.2 kHz)
(**) NV(0):  Default mode "700x525": 77.9 MHz, 81.5 kHz, 74.8 Hz (D)
(II) NV(0): Modeline "700x525"x74.8   77.90  700 732 892 956  525 526 
532 545 doublescan +hsync +vsync (81.5 kHz)
(**) NV(0):  Default mode "700x525": 61.0 MHz, 64.9 kHz, 60.0 Hz (D)
(II) NV(0): Modeline "700x525"x60.0   61.00  700 744 820 940  525 526 
532 541 doublescan +hsync +vsync (64