From matt at chronos.org.uk  Sun Feb  1 06:17:26 2009
From: matt at chronos.org.uk (Matt Dawson)
Date: Sun Feb  1 06:17:33 2009
Subject: Unhappy Xorg upgrade
In-Reply-To: <E1LTc6b-000Oho-Ux@daland.home>
References: <200901311153.58361.vehemens@verizon.net>
	<200902011233.57132.matt@chronos.org.uk>
	<E1LTc6b-000Oho-Ux@daland.home>
Message-ID: <200902011417.18045.matt@chronos.org.uk>

On Sunday 01 February 2009 13:11:21 Alex Goncharov wrote:
> On Sun, 1 Feb 2009 12:33:56 +0000 I wrote:
> | That is not to say the new Xorg doesn't work. The only problems I've
> | seen on Radeons needed a couple of options lines in xorg.conf due to
> | the hald/dbus/xorg race and an fdi to make the keyboard layout match
> | what I actually have rather than "us". Easily fixed for now and 7.4
> | brings some fixes to my systems that I have been awaiting for quite
> | some time, most notably the horrendous XPress 200M chipset now works
> | with DRI.
>
> Knowing about specific things now fixed for specific users is very
> encouraging.

I had better post to the lists exactly what I did, having thrown that 
encouraging word out:

Ensure the files section doesn't contain anything like RGBPath if you've 
upgraded, then add Option "AllowEmptyInput" "False" and Option 
"AutoAddDevices" "False" to the server layout section in xorg.conf. Then 
create a file ${LOCALBASE}/etc/hal/fdi/policy/x11-input.fdi with the following 
contents:

<?xml version="1.0" encoding="ISO-8859-1"?>
<deviceinfo version="0.2">
  <device>
    <match key="info.capabilities" contains="input.keyboard">
      <merge key="input.xkb.layout" type="string">gb</merge>
    </match>
  </device>
</deviceinfo>

Restart hald etc.

This cleared up all issues of not playing nice with moused, missing keyboards 
and quotemarks on my @ key ;o) Obviously, you'll want to replace "gb" with 
whatever layout you require from ${LOCALBASE}/share/X11/xkb/symbols/. Note I 
have not tried hotplugging a USB mouse on this configuration. That's to come 
on the laptop, which works fine with its trackpad (although middle and right 
clicks have been redefined to three and two finger taps respectively - it was 
the other way around) with the updated xf86-input-synaptics driver. 

Which brings me to another little niggle: <aside> Has anyone on list noticed 
that statically compiling a keymap in your kernel >7.0-RELEASE ends up with 
the US layout in single user mode regardless? This used to work, but now it 
doesn't, unless I've missed something in NOTES somewhere. </aside>

> Thanks a lot!

You're very welcome.

Best regards,
-- 
Matt Dawson
MTD15-RIPE
matt@chronos.org.uk
From alex-goncharov at comcast.net  Sun Feb  1 06:37:35 2009
From: alex-goncharov at comcast.net (Alex Goncharov)
Date: Sun Feb  1 06:37:42 2009
Subject: Unhappy Xorg upgrade
In-Reply-To: <200902011417.18045.matt@chronos.org.uk> (message from Matt
	Dawson on Sun, 1 Feb 2009 14:17:16 +0000)
References: <200901311153.58361.vehemens@verizon.net>
	<200902011233.57132.matt@chronos.org.uk>
	<E1LTc6b-000Oho-Ux@daland.home>
	<200902011417.18045.matt@chronos.org.uk>
Message-ID: <E1LTdS0-000PUf-Vb@daland.home>

,--- I/Alex (Sun, 01 Feb 2009 08:11:21 -0500) ----*
| Knowing about specific things now fixed for specific users is very
| encouraging.
| 
| Thanks a lot!
`-------------------------------------------------*
,--- You/Matt (Sun, 1 Feb 2009 14:17:16 +0000) ----*
| I had better post to the lists exactly what I did, having thrown that 
| encouraging word out:

I'll make a pass on your list, to compare notes etc.

| Ensure the files section doesn't contain anything like RGBPath if
| you've upgraded, then add Option "AllowEmptyInput" "False" and
| Option "AutoAddDevices" "False" to the server layout section in
| xorg.conf.

I did that -- when I was using HAL.

| Then create a file ${LOCALBASE}/etc/hal/fdi/policy/x11-input.fdi
| with the following contents:
| 
| <?xml version="1.0" encoding="ISO-8859-1"?>
| <deviceinfo version="0.2">
|   <device>
|     <match key="info.capabilities" contains="input.keyboard">
|       <merge key="input.xkb.layout" type="string">gb</merge>
|     </match>
|   </device>
| </deviceinfo>

Not applicable to me, here in the USA.

| Restart hald etc.

Not applicable to me, running without HAL.

| This cleared up all issues of not playing nice with moused, missing keyboards 
| and quotemarks on my @ key ;o) Obviously, you'll want to replace "gb" with 
| whatever layout you require from ${LOCALBASE}/share/X11/xkb/symbols/. Note I 
| have not tried hotplugging a USB mouse on this configuration. That's to come 
| on the laptop, which works fine with its trackpad (although middle and right 
| clicks have been redefined to three and two finger taps respectively - it was 
| the other way around) with the updated xf86-input-synaptics driver. 

This is an interesting bit...

So, I have a lousy new X on a desktop, and had a fully disfunctional
one on my Latitude notebook (due to "crazy" keyboard" events), the
latter being reverted to xorg-server 1.4.

The laptop has a touch pad, which is reasonable to assume to be
"synaptics" -- but I don't use the pad (I've physically covered it,
and use only the "pointing stick" in the middle of the keyboard);
during one my experiments I also disabled the thing in BIOS.

And: I have never used the xf86-input-synaptics driver.

Is this something to think about -- what is the role of this driver?
Can the lack of it bring the storm of bogus key events with wrong scan codes?

| Which brings me to another little niggle: <aside> Has anyone on list noticed 
| that statically compiling a keymap in your kernel >7.0-RELEASE ends up with 
| the US layout in single user mode regardless? This used to work, but now it 
| doesn't, unless I've missed something in NOTES somewhere. </aside>

I can't comment on it -- but why to do it: why not to use the xkb
extensions (Option "XkbLayout" "gb" -- or something of that sort)?

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

From gaijin.k at gmail.com  Sun Feb  1 09:03:32 2009
From: gaijin.k at gmail.com (Alexandre "Sunny" Kovalenko)
Date: Sun Feb  1 09:03:44 2009
Subject: Unhappy Xorg upgrade
In-Reply-To: <E1LTNL7-000FnE-BX@daland.home>
References: <200901311153.58361.vehemens@verizon.net>
	<E1LTNL7-000FnE-BX@daland.home>
Message-ID: <1233507786.61410.9.camel@RabbitsDen>

On Sat, 2009-01-31 at 16:25 -0500, Alex Goncharov wrote:
> ,--- You/vehemens (Sat, 31 Jan 2009 11:53:58 -0800) ----*
> | In general when upgrading, you take your chances.  If a port upgrade
> | fails, you should fall back to what worked.
> 
> So, a *fundamental* (practically an OS component) port is brought in
> -- and it disables my system.  What is my way of action?  Right --
> install the old packages, taken from an FTP site (is there a way to
> get the previous "source", that is all the ports/*/*/Makefile files?
> Csup can only go forward -- or can it go back?)
> 
> When I install the old packages, I can no longer rebuild and install
> new (say `csup'ed on 2009-03-01) port components, as one whole -- I
> can only do it selectively, excluding from the upgrade most
> X-dependent things.  That sucks and will lead to a problem earlier or
> later.
Will combination of sysutils/portdowngrade and HOLD_PKGS variable
in /usr/local/etc/pkgtools.conf accomplish what you are trying to
accomplish?

-- 
Alexandre "Sunny" Kovalenko

From seba.bsd at sinux.net  Sun Feb  1 10:00:03 2009
From: seba.bsd at sinux.net (Sebastien Chassot)
Date: Sun Feb  1 10:00:11 2009
Subject: xorg 7.4 keyboard localisation   (xorg.conf vs hal)
In-Reply-To: <20090201171920.GB69316@torus.slightlystrange.org>
References: <1233506559.1023.16.camel@dhcppc0>
	<20090201171920.GB69316@torus.slightlystrange.org>
Message-ID: <1233510597.1023.20.camel@dhcppc0>


On Sun, 2009-02-01 at 17:19 +0000, Daniel Bye wrote:
> On Sun, Feb 01, 2009 at 05:42:39PM +0100, Sebastien Chassot wrote:
> > 
> > Hi,
> > 
> > I've upgrade to xorg7.4 and apparently keyboard and mouse are now
> > working with hald.
> > 
> > In xorg.conf changing "old" keybord config as no effect and I can't find
> > how change it with hal. I've got  /usr/local/etc/hal/fdi/* but no
> > *keymap* and I don't know how build such a file.
> 
> This should get you started:
> 
> <?xml version="1.0" encoding="ISO-8859-1"?>
> <deviceinfo version="0.2">
>   <device>
>     <match key="info.capabilities" contains="input.keyboard">
>       <merge key="input.xkb.layout" type="string">gb</merge>
>     </match>
>   </device>
> </deviceinfo>
> 
> Change the `gb' in the example to your local keymap name, save the file
> as /usr/local/etc/hal/fdi/policy/x11-input.fdi and restart hald.

I'll start with that

Thank you


Sebastien

From alex-goncharov at comcast.net  Sun Feb  1 11:11:11 2009
From: alex-goncharov at comcast.net (Alex Goncharov)
Date: Sun Feb  1 11:11:24 2009
Subject: Unhappy Xorg upgrade
In-Reply-To: <1233507786.61410.9.camel@RabbitsDen> (gaijin.k@gmail.com)
References: <200901311153.58361.vehemens@verizon.net>
	<E1LTNL7-000FnE-BX@daland.home> <1233507786.61410.9.camel@RabbitsDen>
Message-ID: <E1LThil-00021g-W9@daland.home>

,--- Alexandre \ (Sun, 01 Feb 2009 12:03:06 -0500) ----*
| > When I install the old packages, I can no longer rebuild and install
| > new (say `csup'ed on 2009-03-01) port components, as one whole -- I
| > can only do it selectively, excluding from the upgrade most
| > X-dependent things.  That sucks and will lead to a problem earlier or
| > later.
| Will combination of sysutils/portdowngrade and HOLD_PKGS variable
| in /usr/local/etc/pkgtools.conf accomplish what you are trying to
| accomplish?
`------------------------------------------------------*

I'll try something of that nature (not today) with your and other
people's advice.

Thank you!

-- Alex -- alex-goncharov@comcast.net --
From alex-goncharov at comcast.net  Sun Feb  1 13:02:18 2009
From: alex-goncharov at comcast.net (Alex Goncharov)
Date: Sun Feb  1 13:02:24 2009
Subject: Unhappy Xorg upgrade
In-Reply-To: <20090201204815.GL65672@over-yonder.net>
	(fullermd@over-yonder.net)
References: <200901311153.58361.vehemens@verizon.net>
	<E1LTNL7-000FnE-BX@daland.home>
	<20090201204815.GL65672@over-yonder.net>
Message-ID: <E1LTjSJ-000DPJ-GR@daland.home>

,--- You/Matthew (Sun, 1 Feb 2009 14:48:15 -0600) ----*
| On Sat, Jan 31, 2009 at 04:25:21PM -0500 I heard the voice of
| Alex Goncharov, and lo! it spake thus:
| > Csup can only go forward -- or can it go back?)
| 
| You can specify a date in a supfile since, like, ever.
`-----------------------------------------------------*

Yes, other people have already pointed this out and I just got the
code as of 2009.01.23.12.00.00 -- four hours before the first
submission of the new X.

Now I just need to think through my next steps :-)

Thank you!

-- Alex -- alex-goncharov@comcast.net --
From fullermd at over-yonder.net  Sun Feb  1 13:05:51 2009
From: fullermd at over-yonder.net (Matthew D. Fuller)
Date: Sun Feb  1 13:06:02 2009
Subject: Unhappy Xorg upgrade
In-Reply-To: <E1LTNL7-000FnE-BX@daland.home>
References: <200901311153.58361.vehemens@verizon.net>
	<E1LTNL7-000FnE-BX@daland.home>
Message-ID: <20090201204815.GL65672@over-yonder.net>

On Sat, Jan 31, 2009 at 04:25:21PM -0500 I heard the voice of
Alex Goncharov, and lo! it spake thus:
>
> Csup can only go forward -- or can it go back?)

You can specify a date in a supfile since, like, ever.


-- 
Matthew Fuller     (MF4839)   |  fullermd@over-yonder.net
Systems/Network Administrator |  http://www.over-yonder.net/~fullermd/
           On the Internet, nobody can hear you scream.
From joe at zircon.seattle.wa.us  Sun Feb  1 14:37:35 2009
From: joe at zircon.seattle.wa.us (Joe Kelsey)
Date: Sun Feb  1 14:37:52 2009
Subject: xorg 7.4 keyboard localisation   (xorg.conf vs hal)
In-Reply-To: <1233510597.1023.20.camel@dhcppc0>
References: <1233506559.1023.16.camel@dhcppc0>	<20090201171920.GB69316@torus.slightlystrange.org>
	<1233510597.1023.20.camel@dhcppc0>
Message-ID: <49861DEA.6050000@zircon.seattle.wa.us>

Sebastien Chassot wrote:
> On Sun, 2009-02-01 at 17:19 +0000, Daniel Bye wrote:
>   
>> On Sun, Feb 01, 2009 at 05:42:39PM +0100, Sebastien Chassot wrote:
>>     
>>> Hi,
>>>
>>> I've upgrade to xorg7.4 and apparently keyboard and mouse are now
>>> working with hald.
>>>
>>> In xorg.conf changing "old" keybord config as no effect and I can't find
>>> how change it with hal. I've got  /usr/local/etc/hal/fdi/* but no
>>> *keymap* and I don't know how build such a file.
>>>       
>> This should get you started:
>>
>> <?xml version="1.0" encoding="ISO-8859-1"?>
>> <deviceinfo version="0.2">
>>   <device>
>>     <match key="info.capabilities" contains="input.keyboard">
>>       <merge key="input.xkb.layout" type="string">gb</merge>
>>     </match>
>>   </device>
>> </deviceinfo>
>>
>> Change the `gb' in the example to your local keymap name, save the file
>> as /usr/local/etc/hal/fdi/policy/x11-input.fdi and restart hald.
>>     
This seems to have a way to enable HAL to detect a keyboard and export 
it to X, but what about mice?  My Xorg log tells me that it is ignoring 
my USB mouse in addition to ignoring my keyboard, so what sort of HAL 
file do I add to enable it to find my mouse?

Where in HAL documentation is this information found?  R. Noland seemed 
to think it was a trivial process to make HAL do keyboards and mice?  In 
fact it is not trivial but a pain in the ass!  If you intend to inflict 
broken software on unsuspecting users you had better think through all 
of the problems and come up with explicit solutions to all of those 
problems so that everyone has a chance to make their systems work.

There had better not be any more surprises waiting in the X 1.6 wings to 
surprise and confound everyone again!
>
> I'll start with that
>
> Thank you
>
>
> Sebastien
>
> _______________________________________________
> 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 borjamar at sarenet.es  Sun Feb  1 14:40:46 2009
From: borjamar at sarenet.es (Borja Marcos)
Date: Sun Feb  1 14:40:54 2009
Subject: Puzzling change in performance
In-Reply-To: <alpine.BSF.2.00.0901311823490.46645@fledge.watson.org>
References: <C99CD0EF-F42D-43BC-9FFC-0A37FE0251E4@sarenet.es>
	<alpine.BSF.2.00.0901311823490.46645@fledge.watson.org>
Message-ID: <2C4CD129-43B3-49FA-8208-FAC25191D2F2@sarenet.es>


On Jan 31, 2009, at 7:27 PM, Robert Watson wrote:

> There are basically three ways to go about exploring this, none  
> particularly good:
>
> (1) Do a more formal before and after analysis of performance on the  
> box,
>   perhaps using tools like kernel profiling, hwpmc, dtrace, etc.

Machine in production, I cannot do it :(

> (2) Do a binary search to narrow down the date of the change that  
> improved
>   things until it becomes clear which mattered.


> (3) Hope someone annecdotally remembers something that might or  
> might not be
>   it and assume they're right.
>
> Of these, I'd guess (2) is actually the most effective way to go  
> about it, but is potentially time-consuming.  As you point out, the  
> most interesting question is whether, when you go back to 7.0,  
> things suddenly get slower again, or not.  Typically long uptimes  
> don't lead to performance problems on FreeBSD (in my experience) so  
> I think that's unlikely to be the source.  There are a lot of  
> improvements in 7.1 relating to performance, but none particularly  
> stands out for me as having the effect you describe.  If you're  
> really curious, I would try to pin it down with a binary search.

I will have to learn how to use dtrace, I think. This is quite weird.  
And in a lot of years I haven't seen a FreeBSD system degraded because  
of a long uptime. Something in userland must be the culprit...

As I see (I don't administer the machine but co-administer it) there's  
a Qmail system with some AV crap... and now I see that active memory  
had gone up, and is much lower after the update.

I'll keep investigating.. the kind of answer I was looking for was a  
"oh, yes, there was a problem that degraded, blah, blah, blah".

The graphs can be accessed here: http://194.30.110.21/orca/

It's behind an ADSL, so expect slow performance.






Borja.

From pete at altadena.net  Sun Feb  1 17:20:05 2009
From: pete at altadena.net (Pete Carah)
Date: Sun Feb  1 17:20:11 2009
Subject: Soekris 4801 hangs (was Re: Hangs, maybe a clue)
Message-ID: <498644D0.4070100@altadena.net>

I fixed the problem on my 4801's by having noticed a correlation with 
psm and hangs on my laptop, and
thought there may be a LOR or such involving the keyboard driver and/or 
kbdmux.  Since a 4801 has no need
of those drivers, but *does* contain the hardware they control, just 
with no external peripherals connected, I tried
configuring the Soekris kernel with all vestiges of atkbdc, psm, kbdmux, 
sc, and such removed.  This did appear to fix the hangs.

The hangs only seem to happen on AMD hardware; I have several 
ich{3,5}+p3 or p4 machines that don't hang.

Before I figured that out I noticed some PHK notes about enabling the 
hardware watchdog and did that too, but did the upgrade mentioned above 
before any watchdog hits.  I haven't seen any spontaneous reboots (which 
a watchdog hit would look like) since the reconfig either.

-- Pete

From rnoland at FreeBSD.org  Sun Feb  1 17:57:11 2009
From: rnoland at FreeBSD.org (Robert Noland)
Date: Sun Feb  1 17:57:18 2009
Subject: xorg 7.4 keyboard localisation   (xorg.conf vs hal)
In-Reply-To: <49861DEA.6050000@zircon.seattle.wa.us>
References: <1233506559.1023.16.camel@dhcppc0>
	<20090201171920.GB69316@torus.slightlystrange.org>
	<1233510597.1023.20.camel@dhcppc0>
	<49861DEA.6050000@zircon.seattle.wa.us>
Message-ID: <1233539822.1534.68.camel@ferret.2hip.net>

On Sun, 2009-02-01 at 14:10 -0800, Joe Kelsey wrote:
> Sebastien Chassot wrote:
> > On Sun, 2009-02-01 at 17:19 +0000, Daniel Bye wrote:
> >   
> >> On Sun, Feb 01, 2009 at 05:42:39PM +0100, Sebastien Chassot wrote:
> >>     
> >>> Hi,
> >>>
> >>> I've upgrade to xorg7.4 and apparently keyboard and mouse are now
> >>> working with hald.
> >>>
> >>> In xorg.conf changing "old" keybord config as no effect and I can't find
> >>> how change it with hal. I've got  /usr/local/etc/hal/fdi/* but no
> >>> *keymap* and I don't know how build such a file.
> >>>       
> >> This should get you started:
> >>
> >> <?xml version="1.0" encoding="ISO-8859-1"?>
> >> <deviceinfo version="0.2">
> >>   <device>
> >>     <match key="info.capabilities" contains="input.keyboard">
> >>       <merge key="input.xkb.layout" type="string">gb</merge>
> >>     </match>
> >>   </device>
> >> </deviceinfo>
> >>
> >> Change the `gb' in the example to your local keymap name, save the file
> >> as /usr/local/etc/hal/fdi/policy/x11-input.fdi and restart hald.
> >>     
> This seems to have a way to enable HAL to detect a keyboard and export 
> it to X, but what about mice?  My Xorg log tells me that it is ignoring 
> my USB mouse in addition to ignoring my keyboard, so what sort of HAL 
> file do I add to enable it to find my mouse?

The above is only to set keyboard layout, everything to detect the
keyboard is already present.

> Where in HAL documentation is this information found?  R. Noland seemed 
> to think it was a trivial process to make HAL do keyboards and mice?  In 
> fact it is not trivial but a pain in the ass!  If you intend to inflict 
> broken software on unsuspecting users you had better think through all 
> of the problems and come up with explicit solutions to all of those 
> problems so that everyone has a chance to make their systems work.

We (marcus and I) have gone to great pains to try and ensure that hal
behaves correctly in pretty much all mice configurations with or without
sysmouse.  If you don't want to use hal, set AutoAddDevices off and
configure away.

> There had better not be any more surprises waiting in the X 1.6 wings to 
> surprise and confound everyone again!

Are you going to stop paying me?  You have no idea how many combinations
of hardware and configurations for X  exist, or the amount of wok that
goes into making all of those combinations work.

robert.

> >
> > I'll start with that
> >
> > Thank you
> >
> >
> > Sebastien
> >
> > _______________________________________________
> > 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"
-- 
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/20090202/3ce86904/attachment.pgp
From Timo.Rikkonen at syncrontech.com  Mon Feb  2 00:20:08 2009
From: Timo.Rikkonen at syncrontech.com (Timo Rikkonen)
Date: Mon Feb  2 00:20:15 2009
Subject: /dev/cuau* ports hang after a while
In-Reply-To: <200901301251.n0UCpYKh067104@lava.sentex.ca>
References: <E6A9CAA76548CB4EB02D2E3B174DD3B118E9A8E69E@ink.sad.syncrontech.com>
	<200901292033.n0TKXYZp062630@lava.sentex.ca>
	<E6A9CAA76548CB4EB02D2E3B174DD3B118E9A8E87C@ink.sad.syncrontech.com>
	<200901301251.n0UCpYKh067104@lava.sentex.ca>
Message-ID: <E6A9CAA76548CB4EB02D2E3B174DD3B118E9A8E8ED@ink.sad.syncrontech.com>

Hi,

Have now tried this with 7.1-RELEASE, unfortunately with same results as before, the ports still hang after some time.

-Timo



-----Original Message-----
From: Mike Tancsa [mailto:mike@sentex.net] 
Sent: 30. tammikuuta 2009 14:52
To: Timo Rikkonen; freebsd-stable@freebsd.org
Subject: RE: /dev/cuau* ports hang after a while

At 05:50 AM 1/30/2009, Timo Rikkonen wrote:
>Hi,
>
>The speed is 9600. Actually I already tried with 7.1-RELEASE, with 
>same results.
>I'll try the device.hints-changes, thanks.

Not sure if the code is in 7.0, so make sure you try it with 7.1-RELEASE

         ---Mike

>-Timo
>
>
>-----Original Message-----
>From: Mike Tancsa [mailto:mike@sentex.net]
>Sent: 29. tammikuuta 2009 22:34
>To: Timo Rikkonen; freebsd-stable@freebsd.org
>Subject: Re: /dev/cuau* ports hang after a while
>
>At 08:00 AM 1/26/2009, Timo Rikkonen wrote:
> >Hi,
> >
> >We are using "VScom PCI-200L" and "Moxa Technologies, C168H/PCI"
> >-cards for serial ports. After installing 7.0 the ports or the
> >connection to the port hang after a while. A "while" could be
> >half-a-day or 10 minutes.
> >There is no error message to be seen anywhere.
> >
> >Not all ports hang at the same time, it could be just one or two of
> >them. Earlier versions (6.2-RELEASE) work just fine.
> >The ports have different devicenames after 7.0, in 6.2 they were
> >/dev/cuad4-7, now they are /dev/cuau0-3 (uart?)
>
>
>Is the application fairly low speed (e.g. 9600bps or slower) ?  If
>so, try with 7.1R, not 7 and add
>
>hint.uart.0.flags="0x100"
>hint.uart.1.flags="0x100"
>
>to /boot/device.hints
>
>http://www.freebsd.org/cgi/query-pr.cgi?pr=121421
>
>has details
>
>          ---Mike

From yanefbsd at gmail.com  Mon Feb  2 00:43:49 2009
From: yanefbsd at gmail.com (Garrett Cooper)
Date: Mon Feb  2 00:43:56 2009
Subject: xorg 7.4 keyboard localisation (xorg.conf vs hal)
In-Reply-To: <1233539822.1534.68.camel@ferret.2hip.net>
References: <1233506559.1023.16.camel@dhcppc0>
	<20090201171920.GB69316@torus.slightlystrange.org>
	<1233510597.1023.20.camel@dhcppc0>
	<49861DEA.6050000@zircon.seattle.wa.us>
	<1233539822.1534.68.camel@ferret.2hip.net>
Message-ID: <7d6fde3d0902020043t26d6a526w71b486f0ed5852f8@mail.gmail.com>

On Sun, Feb 1, 2009 at 5:57 PM, Robert Noland <rnoland@freebsd.org> wrote:
> On Sun, 2009-02-01 at 14:10 -0800, Joe Kelsey wrote:
>> Sebastien Chassot wrote:
>> > On Sun, 2009-02-01 at 17:19 +0000, Daniel Bye wrote:
>> >
>> >> On Sun, Feb 01, 2009 at 05:42:39PM +0100, Sebastien Chassot wrote:
>> >>
>> >>> Hi,
>> >>>
>> >>> I've upgrade to xorg7.4 and apparently keyboard and mouse are now
>> >>> working with hald.
>> >>>
>> >>> In xorg.conf changing "old" keybord config as no effect and I can't find
>> >>> how change it with hal. I've got  /usr/local/etc/hal/fdi/* but no
>> >>> *keymap* and I don't know how build such a file.
>> >>>
>> >> This should get you started:
>> >>
>> >> <?xml version="1.0" encoding="ISO-8859-1"?>
>> >> <deviceinfo version="0.2">
>> >>   <device>
>> >>     <match key="info.capabilities" contains="input.keyboard">
>> >>       <merge key="input.xkb.layout" type="string">gb</merge>
>> >>     </match>
>> >>   </device>
>> >> </deviceinfo>
>> >>
>> >> Change the `gb' in the example to your local keymap name, save the file
>> >> as /usr/local/etc/hal/fdi/policy/x11-input.fdi and restart hald.
>> >>
>> This seems to have a way to enable HAL to detect a keyboard and export
>> it to X, but what about mice?  My Xorg log tells me that it is ignoring
>> my USB mouse in addition to ignoring my keyboard, so what sort of HAL
>> file do I add to enable it to find my mouse?
>
> The above is only to set keyboard layout, everything to detect the
> keyboard is already present.
>
>> Where in HAL documentation is this information found?  R. Noland seemed
>> to think it was a trivial process to make HAL do keyboards and mice?  In
>> fact it is not trivial but a pain in the ass!  If you intend to inflict
>> broken software on unsuspecting users you had better think through all
>> of the problems and come up with explicit solutions to all of those
>> problems so that everyone has a chance to make their systems work.
>
> We (marcus and I) have gone to great pains to try and ensure that hal
> behaves correctly in pretty much all mice configurations with or without
> sysmouse.  If you don't want to use hal, set AutoAddDevices off and
> configure away.
>
>> There had better not be any more surprises waiting in the X 1.6 wings to
>> surprise and confound everyone again!
>
> Are you going to stop paying me?  You have no idea how many combinations
> of hardware and configurations for X  exist, or the amount of wok that
> goes into making all of those combinations work.
>
> robert.

    I agree. If you really want to help Robert out, contribute funds
and hardware for the time and effort he puts in, or volunteer in other
areas that might make his life otherwise easier so he can help you
out. Otherwise you're asking something extremely unreasonable that
he's volunteering to work on.
    Or as the old adages go:
    1. You get what you pay for.
    2. I'll scratch your back if you scratch mine.
My 2 cents,
-Garrett
From avg at icyb.net.ua  Mon Feb  2 03:36:18 2009
From: avg at icyb.net.ua (Andriy Gapon)
Date: Mon Feb  2 03:36:26 2009
Subject: problem with "cold" hardware? [Was: panic in callout_reset: bad
 link in callwheel]
In-Reply-To: <4980B072.3050205@modulus.org>
References: <497AF4C7.3080309@icyb.net.ua> <49804F0C.3000400@icyb.net.ua>
	<4980B072.3050205@modulus.org>
Message-ID: <4986DAAA.3090208@icyb.net.ua>

on 28/01/2009 21:22 Andrew Snow said the following:
> Andriy Gapon wrote:
>> Previously I heard about problems with hardware running hot, but not
>> with it being "cold". I put the word in quotes, because the system is in
>> a room with normal room temperature.
>>
>> Any guesses what hardware part might be acting up like this?
> 
> Power supply.  Give all the capacitors a visual check.  Or you may be
> drawing too much power from your rated supply.

Right on the target. I opened the PSU after replacing it, visually it
looks OK (too me), nevertheless I have verified that the fault was in it.

Thank you and everybody who helped!



-- 
Andriy Gapon
From 000.fbsd at quip.cz  Mon Feb  2 04:07:32 2009
From: 000.fbsd at quip.cz (Miroslav Lachman)
Date: Mon Feb  2 04:07:40 2009
Subject: freebsd-update: Fetching 25470 files... failed.
Message-ID: <4986E1F5.2060909@quip.cz>

I am trying to upgrade some machines from FreeBSD 7.0 i386 to 7.1 with 
freebsd-update tool. It was successful on some of them, but on few 
others I am still getting the same error:

Fetching files from 7.0-RELEASE for merging... done.
Preparing to download files... done.
Fetching 26988 
patches.....10....20....30....40....50....60....70....80....90....100.

[...snip...]

40....2350....2360....2370....2380....2390....2400....2410....2420....2430....2440....2450.... 
done.
Applying patches... done.
Fetching 25470 files... failed.

I run 'freebsd-update -r 7.1-RELEASE upgrade' almost ten times on this 
machine and always got this error.

What can I try to do to fix this?

Thanks for any help.

Miroslav Lachman
From matthias.andree at gmx.de  Mon Feb  2 04:40:06 2009
From: matthias.andree at gmx.de (Matthias Andree)
Date: Mon Feb  2 04:40:13 2009
Subject: problem with "cold" hardware? [Was: panic in callout_reset: bad
 link in callwheel]
In-Reply-To: <4986DAAA.3090208@icyb.net.ua>
References: <497AF4C7.3080309@icyb.net.ua>
	<49804F0C.3000400@icyb.net.ua>	<4980B072.3050205@modulus.org>
	<4986DAAA.3090208@icyb.net.ua>
Message-ID: <4986E998.4040504@gmx.de>

Andriy Gapon schrieb:
> on 28/01/2009 21:22 Andrew Snow said the following:
>   
>> Andriy Gapon wrote:
>>     
>>> Previously I heard about problems with hardware running hot, but not
>>> with it being "cold". I put the word in quotes, because the system is in
>>> a room with normal room temperature.
>>>
>>> Any guesses what hardware part might be acting up like this?
>>>       
>> Power supply.  Give all the capacitors a visual check.  Or you may be
>> drawing too much power from your rated supply.
>>     
>
> Right on the target. I opened the PSU after replacing it, visually it
> looks OK (too me), nevertheless I have verified that the fault was in it.
>
> Thank you and everybody who helped!
>   
Electronic devices, including computers, that become unable to /cold/
boot (and need a reset some seconds or minutes after power-up) usually
suffer from dry or leaked capacitors, either in the PSU or - I've seen
that more often - the voltage regulator on the main board. Dry
capacitors often look innocuous, unlike leaked ones that show brownish
stains (electrolytes) on the cap or underneath.

From chris# at 1command.com  Mon Feb  2 04:54:43 2009
From: chris# at 1command.com (Chris H)
Date: Mon Feb  2 04:54:50 2009
Subject: Replace Cisco IOS/CBOS with freebsd - possible?
In-Reply-To: <49858F70.6010907@bromirski.net>
References: <20090129015034.7dxisep21w04gksg@webmail.1command.com>
	<0bca01c98202$a6124350$f236c9f0$@co.uk>
	<20090129051522.a92df0myf44gsko4@webmail.1command.com>
	<62b856460901290538x5d857f08ka3b2ffb5a7aa8e7f@mail.gmail.com>
	<20090129060243.adauuua9eokcsos8@webmail.1command.com>
	<F9598B04-9CAD-4785-89E8-513095252B18@lamness.info>
	<00fe01c98247$d6872600$83957200$@com> <49822E90.1010306@FreeBSD.org>
	<20090129181838.l9cr09o0kk400gwc@webmail.1command.com>
	<49858F70.6010907@bromirski.net>
Message-ID: <20090202045429.e54dcxsuo8o4gw8g@webmail.1command.com>

Quoting ?ukasz Bromirski <lukasz@bromirski.net>:

> On 2009-01-30 03:18, Chris H wrote:
>
>> Please see: https://bsdforge.net/cisco-data/ for a list of manuals I
>> have available for download on these (and similar).
>
> What's the sense of downloading it from Your site, if cisco.com
> contains the files?

Because I was asked for more info on my hardware, and I /knew/ where my
documentation was. Why try to discover (or ask others to) where the
docs were on Cisco's site - which would assume it still existed.

I guess I could have summarized in one word - convenience. ;)

>
> Go to cisco.com->Products and choose from routers.
>
> Or go to cisco.com/univercd and look for older interface to manuals.

Thanks for the pointers.

>
> -- 
> "Don't expect me to cry for all the     |               ?ukasz Bromirski
>  reasons you had to die" -- Kurt Cobain |    http://lukasz.bromirski.net
>



From cpghost at cordula.ws  Mon Feb  2 05:46:06 2009
From: cpghost at cordula.ws (cpghost)
Date: Mon Feb  2 05:46:13 2009
Subject: Soekris 4801 hangs (was Re: Hangs, maybe a clue)
In-Reply-To: <498644D0.4070100@altadena.net>
References: <498644D0.4070100@altadena.net>
Message-ID: <20090202134601.GB983@phenom.cordula.ws>

On Sun, Feb 01, 2009 at 07:56:48PM -0500, Pete Carah wrote:
> I fixed the problem on my 4801's by having noticed a correlation with 
> psm and hangs on my laptop, and
> thought there may be a LOR or such involving the keyboard driver and/or 
> kbdmux.  Since a 4801 has no need
> of those drivers, but *does* contain the hardware they control, just 
> with no external peripherals connected, I tried
> configuring the Soekris kernel with all vestiges of atkbdc, psm, kbdmux, 
> sc, and such removed.  This did appear to fix the hangs.

Hmmm... not for me. This is my kernel config for the hanging net4801s.
It is being in use for a couple of years now and I didn't change it
before the trouble began early December:

---------------------- cut here --------------------------------------------
# SOEKRIS kernel config file, based upon FreeBSD 6.0-STABLE 2006-01-03.

#cpu		I486_CPU
cpu		I586_CPU
ident		SOEKRIS

options         CPU_SOEKRIS             #Enable Soekris hardware stuff.
options         CPU_GEODE               #GEODE GL1100 Chips (Soekris)
#device         pf                      #DON'T Enable PF (use as a module!)

makeoptions	DEBUG=-g		# Build kernel with gdb(1) debug symbols

options 	SCHED_4BSD		# 4BSD scheduler
options 	PREEMPTION		# Enable kernel thread preemption
options 	INET			# InterNETworking
options 	INET6			# IPv6 communications protocols
options		SCTP			# Stream Control Transmission Protocol
options 	FFS			# Berkeley Fast Filesystem
options 	SOFTUPDATES		# Enable FFS soft updates support
options 	UFS_ACL			# Support for access control lists
options 	UFS_DIRHASH		# Improve performance on big directories
options		UFS_GJOURNAL		# Enable gjournal-based UFS journaling
options 	MD_ROOT			# MD is a potential root device
options 	NFSCLIENT		# Network Filesystem Client
options 	NFSSERVER		# Network Filesystem Server
options 	NFS_ROOT		# NFS usable as /, requires NFSCLIENT
options 	PROCFS			# Process filesystem (requires PSEUDOFS)
options 	PSEUDOFS		# Pseudo-filesystem framework
options 	GEOM_PART_GPT		# GUID Partition Tables.
options		GEOM_LABEL		# Provides labelization
options 	COMPAT_43TTY		# BSD 4.3 TTY compat [KEEP THIS!]
options 	COMPAT_FREEBSD6		# Compatible with FreeBSD6
options 	SCSI_DELAY=1000		# Delay (in ms) before probing SCSI
options 	KTRACE			# ktrace(1) support
options 	SYSVSHM			# SYSV-style shared memory
options 	SYSVMSG			# SYSV-style message queues
options 	SYSVSEM			# SYSV-style semaphores
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		STOP_NMI		# Stop CPUS using NMI instead of IPI
options		AUDIT			# Security event auditing

# options         SMP                     # Symmetric MultiProcessor Kernel
# device          apic	                  # I/O APIC

# CPU frequency control
device          cpufreq

# Bus support.
device		eisa
device		pci

# ATA and ATAPI devices
device		ata
device		atadisk		# ATA disk drives
options 	ATA_STATIC_ID	# Static device numbering

device		agp		# support several AGP chipsets

# Add suspend/resume support for the i8254.
device		pmtimer

# Serial (COM) ports
device		sio		# 8250, 16[45]50 based serial ports
device          uart            # Generic UART driver

device		miibus		# MII bus support
device		sis		# Silicon Integrated Systems SiS 900/SiS 7016

# Pseudo devices.
device		loop		# Network loopback
device		random		# Entropy device
device		ether		# Ethernet support
device		sl		# Kernel SLIP
device		ppp		# Kernel PPP
device		tun		# Packet tunnel.
device		pty		# Pseudo-ttys (telnet etc)
device		md		# Memory "disks"

# The `bpf' device enables the Berkeley Packet Filter.
# Be aware of the administrative consequences of enabling this!
# Note that 'bpf' is required for DHCP.
device		bpf		# Berkeley packet filter

# USB support
device		uhci		# UHCI PCI->USB interface
device		ohci		# OHCI PCI->USB interface
device		usb		# USB Bus (required)
#device		udbp		# USB Double Bulk Pipe devices
device		ugen		# Generic

-------------------------- cut here ---------------------------------------

As you see, no atkbdc, psm, kbdmux, sc, etc.... but still sporadic
hangs... :(

> The hangs only seem to happen on AMD hardware; I have several 
> ich{3,5}+p3 or p4 machines that don't hang.
> 
> Before I figured that out I noticed some PHK notes about enabling the 
> hardware watchdog and did that too, but did the upgrade mentioned above 
> before any watchdog hits.  I haven't seen any spontaneous reboots (which 
> a watchdog hit would look like) since the reconfig either.
> 
> -- Pete

Regards,
-cpghost.

-- 
Cordula's Web. http://www.cordula.ws/
From pete at altadena.net  Mon Feb  2 07:44:40 2009
From: pete at altadena.net (Pete Carah)
Date: Mon Feb  2 07:44:47 2009
Subject: Soekris 4801 hangs (was Re: Hangs, maybe a clue)
In-Reply-To: <20090202134601.GB983@phenom.cordula.ws>
References: <498644D0.4070100@altadena.net>
	<20090202134601.GB983@phenom.cordula.ws>
Message-ID: <498714E2.1000105@altadena.net>

cpghost wrote:
> On Sun, Feb 01, 2009 at 07:56:48PM -0500, Pete Carah wrote:
>   
>> I fixed the problem on my 4801's by having noticed a correlation with 
>> psm and hangs on my laptop, and
>> thought there may be a LOR or such involving the keyboard driver and/or 
>> kbdmux.  Since a 4801 has no need
>> of those drivers, but *does* contain the hardware they control, just 
>> with no external peripherals connected, I tried
>> configuring the Soekris kernel with all vestiges of atkbdc, psm, kbdmux, 
>> sc, and such removed.  This did appear to fix the hangs.
>>     
>
> Hmmm... not for me. This is my kernel config for the hanging net4801s.
> It is being in use for a couple of years now and I didn't change it
> before the trouble began early December:
>
> ---------------------- cut here --------------------------------------------
> # SOEKRIS kernel config file, based upon FreeBSD 6.0-STABLE 2006-01-03.
>
> #cpu		I486_CPU
> cpu		I586_CPU
> ident		SOEKRIS
>
> options         CPU_SOEKRIS             #Enable Soekris hardware stuff.
> options         CPU_GEODE               #GEODE GL1100 Chips (Soekris)
> #device         pf                      #DON'T Enable PF (use as a module!)
>
> makeoptions	DEBUG=-g		# Build kernel with gdb(1) debug symbols
>
> options 	SCHED_4BSD		# 4BSD scheduler
> options 	PREEMPTION		# Enable kernel thread preemption
> options 	INET			# InterNETworking
> options 	INET6			# IPv6 communications protocols
> options		SCTP			# Stream Control Transmission Protocol
> options 	FFS			# Berkeley Fast Filesystem
> options 	SOFTUPDATES		# Enable FFS soft updates support
> options 	UFS_ACL			# Support for access control lists
> options 	UFS_DIRHASH		# Improve performance on big directories
> options		UFS_GJOURNAL		# Enable gjournal-based UFS journaling
> options 	MD_ROOT			# MD is a potential root device
> options 	NFSCLIENT		# Network Filesystem Client
> options 	NFSSERVER		# Network Filesystem Server
> options 	NFS_ROOT		# NFS usable as /, requires NFSCLIENT
> options 	PROCFS			# Process filesystem (requires PSEUDOFS)
> options 	PSEUDOFS		# Pseudo-filesystem framework
> options 	GEOM_PART_GPT		# GUID Partition Tables.
> options		GEOM_LABEL		# Provides labelization
> options 	COMPAT_43TTY		# BSD 4.3 TTY compat [KEEP THIS!]
> options 	COMPAT_FREEBSD6		# Compatible with FreeBSD6
> options 	SCSI_DELAY=1000		# Delay (in ms) before probing SCSI
> options 	KTRACE			# ktrace(1) support
> options 	SYSVSHM			# SYSV-style shared memory
> options 	SYSVMSG			# SYSV-style message queues
> options 	SYSVSEM			# SYSV-style semaphores
> 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		STOP_NMI		# Stop CPUS using NMI instead of IPI
> options		AUDIT			# Security event auditing
>
> # options         SMP                     # Symmetric MultiProcessor Kernel
> # device          apic	                  # I/O APIC
>
> # CPU frequency control
> device          cpufreq
>
> # Bus support.
> device		eisa
> device		pci
>
> # ATA and ATAPI devices
> device		ata
> device		atadisk		# ATA disk drives
> options 	ATA_STATIC_ID	# Static device numbering
>
> device		agp		# support several AGP chipsets
>
> # Add suspend/resume support for the i8254.
> device		pmtimer
>
> # Serial (COM) ports
> device		sio		# 8250, 16[45]50 based serial ports
> device          uart            # Generic UART driver
>
> device		miibus		# MII bus support
> device		sis		# Silicon Integrated Systems SiS 900/SiS 7016
>
> # Pseudo devices.
> device		loop		# Network loopback
> device		random		# Entropy device
> device		ether		# Ethernet support
> device		sl		# Kernel SLIP
> device		ppp		# Kernel PPP
> device		tun		# Packet tunnel.
> device		pty		# Pseudo-ttys (telnet etc)
> device		md		# Memory "disks"
>
> # The `bpf' device enables the Berkeley Packet Filter.
> # Be aware of the administrative consequences of enabling this!
> # Note that 'bpf' is required for DHCP.
> device		bpf		# Berkeley packet filter
>
> # USB support
> device		uhci		# UHCI PCI->USB interface
> device		ohci		# OHCI PCI->USB interface
> device		usb		# USB Bus (required)
> #device		udbp		# USB Double Bulk Pipe devices
> device		ugen		# Generic
>
> -------------------------- cut here ---------------------------------------
>
> As you see, no atkbdc, psm, kbdmux, sc, etc.... but still sporadic
> hangs... :(
>
>   
Every 2-3 days matches mine mostly.  My daughter was getting tired of 
rebooting it.

I backed the source for that server and my laptop to RELENG_7 as of 
20081201000000.  This fixed the laptop, but I haven't recompiled the 
soekris since reverting.  At least most of the problem appeared in 
either late Nov or early Dec. with what matters for my laptop after Dec 
1.  So both soekris are running on releng_7 as of just after the release.

You *do* have agp... (and eisa; I don't remember if I removed that or 
not.  I didn't)
Mine also has apic but not SMP.  (there are lots of apic's in ich 
chipsets that help route pci interrupts without being SMP.)  I have 
CPU_SOEKRIS and CPU_GEODE also.  I did leave uhid in mine to handle the UPS.

ukbd appears to count.  Maybe ums. 
Mine is running on a cf with nfs for updates.  (I do compiles on the 
co-located file server).

I have ALTQ and netgraph compiled in, with most ALTQ options but 
netgraph options commented (since it will load modules as needed).  
(ALTQ is needed since this is a nat firewall with voip behind it.)

-- Pete

From joe at zircon.seattle.wa.us  Mon Feb  2 11:18:44 2009
From: joe at zircon.seattle.wa.us (Joe Kelsey)
Date: Mon Feb  2 11:18:51 2009
Subject: xorg 7.4 keyboard localisation   (xorg.conf vs hal)
In-Reply-To: <1233539822.1534.68.camel@ferret.2hip.net>
References: <1233506559.1023.16.camel@dhcppc0>	
	<20090201171920.GB69316@torus.slightlystrange.org>	
	<1233510597.1023.20.camel@dhcppc0>
	<49861DEA.6050000@zircon.seattle.wa.us>
	<1233539822.1534.68.camel@ferret.2hip.net>
Message-ID: <4987470D.2090406@zircon.seattle.wa.us>

Robert Noland wrote:
> On Sun, 2009-02-01 at 14:10 -0800, Joe Kelsey wrote:
>   
>> Sebastien Chassot wrote:
>>     
>>> On Sun, 2009-02-01 at 17:19 +0000, Daniel Bye wrote:
>>>   
>>>       
>>>> On Sun, Feb 01, 2009 at 05:42:39PM +0100, Sebastien Chassot wrote:
>>>>     
>>>>         
>>>>> Hi,
>>>>>
>>>>> I've upgrade to xorg7.4 and apparently keyboard and mouse are now
>>>>> working with hald.
>>>>>
>>>>> In xorg.conf changing "old" keybord config as no effect and I can't find
>>>>> how change it with hal. I've got  /usr/local/etc/hal/fdi/* but no
>>>>> *keymap* and I don't know how build such a file.
>>>>>       
>>>>>           
>>>> This should get you started:
>>>>
>>>> <?xml version="1.0" encoding="ISO-8859-1"?>
>>>> <deviceinfo version="0.2">
>>>>   <device>
>>>>     <match key="info.capabilities" contains="input.keyboard">
>>>>       <merge key="input.xkb.layout" type="string">gb</merge>
>>>>     </match>
>>>>   </device>
>>>> </deviceinfo>
>>>>
>>>> Change the `gb' in the example to your local keymap name, save the file
>>>> as /usr/local/etc/hal/fdi/policy/x11-input.fdi and restart hald.
>>>>     
>>>>         
>> This seems to have a way to enable HAL to detect a keyboard and export 
>> it to X, but what about mice?  My Xorg log tells me that it is ignoring 
>> my USB mouse in addition to ignoring my keyboard, so what sort of HAL 
>> file do I add to enable it to find my mouse?
>>     
>
> The above is only to set keyboard layout, everything to detect the
> keyboard is already present.
>
>   
>> Where in HAL documentation is this information found?  R. Noland seemed 
>> to think it was a trivial process to make HAL do keyboards and mice?  In 
>> fact it is not trivial but a pain in the ass!  If you intend to inflict 
>> broken software on unsuspecting users you had better think through all 
>> of the problems and come up with explicit solutions to all of those 
>> problems so that everyone has a chance to make their systems work.
>>     
>
> We (marcus and I) have gone to great pains to try and ensure that hal
> behaves correctly in pretty much all mice configurations with or without
> sysmouse.  If you don't want to use hal, set AutoAddDevices off and
> configure away.
>
>   
I did my best to follow ALL of the posted directions to absolutely NO AVAIL.

When I start Xorg, it explicitly tells me it is disabling all automatic 
devices and refuses to use HAL or any other detectable methosd to find 
the mouse and/or keyboard.

There is no documentation ANYWHERE about how HAL is supposed to help in 
any of this.  There is no documentation ANYWHERE about what exaqctly the 
new Xorg is supposed to do about it.  There is no documentation ANYWHERE 
about the new, secret, hidden options that you can put in your xorg.conf 
file to disable this whole HAL mess.

The only documentation available ANYWHERE is the skimpy little paragraph 
that says, it works or it doesn't.  No explanation about why it works or 
doesn't or how to determine exactly what might be wrong in your 
configuration to make it work or not work.

I would not compalin if you actually documented what you are inflicting 
on us rather than just say, here it is, good luck!  I understand how 
difficult some of these port upgrades are, but you have to realize that 
you have not provided ANY resources that anyone else can use to help 
themselves figure out their issues.

I don't want to pay you with money I do not have from a job I do not 
have.  You have to realize how many people may or may not have problems 
due to your blithe posting of this complicated mess.  Either explain how 
to use HAL properly to configure X resources or disable the capability.

Thank you for all of your effort so far.  I really do appreciate it.

/Joe

>> There had better not be any more surprises waiting in the X 1.6 wings to 
>> surprise and confound everyone again!
>>     
>
> Are you going to stop paying me?  You have no idea how many combinations
> of hardware and configurations for X  exist, or the amount of wok that
> goes into making all of those combinations work.
>
> robert.
>
>   
>>> I'll start with that
>>>
>>> Thank you
>>>
>>>
>>> Sebastien
>>>
>>> _______________________________________________
>>> 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 rnoland at FreeBSD.org  Mon Feb  2 11:39:58 2009
From: rnoland at FreeBSD.org (Robert Noland)
Date: Mon Feb  2 11:40:04 2009
Subject: xorg 7.4 keyboard localisation   (xorg.conf vs hal)
In-Reply-To: <4987470D.2090406@zircon.seattle.wa.us>
References: <1233506559.1023.16.camel@dhcppc0>
	<20090201171920.GB69316@torus.slightlystrange.org>
	<1233510597.1023.20.camel@dhcppc0>
	<49861DEA.6050000@zircon.seattle.wa.us>
	<1233539822.1534.68.camel@ferret.2hip.net>
	<4987470D.2090406@zircon.seattle.wa.us>
Message-ID: <1233603589.1492.27.camel@ferret.2hip.net>

On Mon, 2009-02-02 at 11:18 -0800, Joe Kelsey wrote:
> Robert Noland wrote:
> > On Sun, 2009-02-01 at 14:10 -0800, Joe Kelsey wrote:
> >   
> >> Sebastien Chassot wrote:
> >>     
> >>> On Sun, 2009-02-01 at 17:19 +0000, Daniel Bye wrote:
> >>>   
> >>>       
> >>>> On Sun, Feb 01, 2009 at 05:42:39PM +0100, Sebastien Chassot wrote:
> >>>>     
> >>>>         
> >>>>> Hi,
> >>>>>
> >>>>> I've upgrade to xorg7.4 and apparently keyboard and mouse are now
> >>>>> working with hald.
> >>>>>
> >>>>> In xorg.conf changing "old" keybord config as no effect and I can't find
> >>>>> how change it with hal. I've got  /usr/local/etc/hal/fdi/* but no
> >>>>> *keymap* and I don't know how build such a file.
> >>>>>       
> >>>>>           
> >>>> This should get you started:
> >>>>
> >>>> <?xml version="1.0" encoding="ISO-8859-1"?>
> >>>> <deviceinfo version="0.2">
> >>>>   <device>
> >>>>     <match key="info.capabilities" contains="input.keyboard">
> >>>>       <merge key="input.xkb.layout" type="string">gb</merge>
> >>>>     </match>
> >>>>   </device>
> >>>> </deviceinfo>
> >>>>
> >>>> Change the `gb' in the example to your local keymap name, save the file
> >>>> as /usr/local/etc/hal/fdi/policy/x11-input.fdi and restart hald.
> >>>>     
> >>>>         
> >> This seems to have a way to enable HAL to detect a keyboard and export 
> >> it to X, but what about mice?  My Xorg log tells me that it is ignoring 
> >> my USB mouse in addition to ignoring my keyboard, so what sort of HAL 
> >> file do I add to enable it to find my mouse?
> >>     
> >
> > The above is only to set keyboard layout, everything to detect the
> > keyboard is already present.
> >
> >   
> >> Where in HAL documentation is this information found?  R. Noland seemed 
> >> to think it was a trivial process to make HAL do keyboards and mice?  In 
> >> fact it is not trivial but a pain in the ass!  If you intend to inflict 
> >> broken software on unsuspecting users you had better think through all 
> >> of the problems and come up with explicit solutions to all of those 
> >> problems so that everyone has a chance to make their systems work.
> >>     
> >
> > We (marcus and I) have gone to great pains to try and ensure that hal
> > behaves correctly in pretty much all mice configurations with or without
> > sysmouse.  If you don't want to use hal, set AutoAddDevices off and
> > configure away.
> >
> >   
> I did my best to follow ALL of the posted directions to absolutely NO AVAIL.
> 
> When I start Xorg, it explicitly tells me it is disabling all automatic 
> devices and refuses to use HAL or any other detectable methosd to find 
> the mouse and/or keyboard.
> 
> There is no documentation ANYWHERE about how HAL is supposed to help in 
> any of this.  There is no documentation ANYWHERE about what exaqctly the 
> new Xorg is supposed to do about it.  There is no documentation ANYWHERE 
> about the new, secret, hidden options that you can put in your xorg.conf 
> file to disable this whole HAL mess.

man xorg.conf search for Input...

> The only documentation available ANYWHERE is the skimpy little paragraph 
> that says, it works or it doesn't.  No explanation about why it works or 
> doesn't or how to determine exactly what might be wrong in your 
> configuration to make it work or not work.
> 
> I would not compalin if you actually documented what you are inflicting 
> on us rather than just say, here it is, good luck!  I understand how 
> difficult some of these port upgrades are, but you have to realize that 
> you have not provided ANY resources that anyone else can use to help 
> themselves figure out their issues.
> 
> I don't want to pay you with money I do not have from a job I do not 
> have.  You have to realize how many people may or may not have problems 
> due to your blithe posting of this complicated mess.  Either explain how 
> to use HAL properly to configure X resources or disable the capability.

Set Options "AutoAddDevices" "off" and you have to configure everything
like you used to.

robert.

> Thank you for all of your effort so far.  I really do appreciate it.
> 
> /Joe
> 
> >> There had better not be any more surprises waiting in the X 1.6 wings to 
> >> surprise and confound everyone again!
> >>     
> >
> > Are you going to stop paying me?  You have no idea how many combinations
> > of hardware and configurations for X  exist, or the amount of wok that
> > goes into making all of those combinations work.
> >
> > robert.
> >
> >   
> >>> I'll start with that
> >>>
> >>> Thank you
> >>>
> >>>
> >>> Sebastien
> >>>
> >>> _______________________________________________
> >>> 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"
> >>     
> 
> _______________________________________________
> 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/20090202/7f754606/attachment.pgp
From mike at sentex.net  Mon Feb  2 12:03:29 2009
From: mike at sentex.net (Mike Tancsa)
Date: Mon Feb  2 12:03:37 2009
Subject: HEADS UP: multi-IPv4/v6/no-IP jails merge to 7-STABLE ahead
In-Reply-To: <20090128150840.E45963@maildrop.int.zabbadoz.net>
References: <20090128150840.E45963@maildrop.int.zabbadoz.net>
Message-ID: <200902022003.n12K3PLO087346@lava.sentex.ca>

At 10:22 AM 1/28/2009, Bjoern A. Zeeb wrote:
>Hi,
>
>I have a possible MFC candidate patch at:
>         http://people.freebsd.org/~bz/20090128-02-jail7-mfc.diff


Hi Bjoern,
         Will this patch allow for the creation of tun interfaces 
inside of a jail ?  Ideally I was hoping to run OpenVPN inside 
various jails which uses the tun device.
         ---Mike

>to merge the multi-IPv4/v6/no-IP jails to 7-STABLE.  My plan would be
>to do so during the weekend of 6-8th February 2009.
>
>In addition to what the patch says at the beginning (__FreeBSD_version
>bump), the patch also has the regenerated compat/freebsd32 sysctl
>stuff in it so that people can apply, compile and run it directly.
>For the merge this would be a second commit.
>
>For committers who want to review that I have done the merge right, it
>is an svn diff with mergeinfo included.
>
>For details about the patch, features, .. see the original commit
>message and follow-up a few days later (both in one post):
>http://lists.freebsd.org/pipermail/freebsd-jail/2008-December/000631.html
>
>Since then a few bug fixes went in, some older PRs were handled, ...
>
>Now is the time for you to try and review it for 7-STABLE, etc.
>
>
>/bz
>
>--
>Bjoern A. Zeeb                      The greatest risk is not taking one.
>_______________________________________________
>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 joe at zircon.seattle.wa.us  Mon Feb  2 12:43:56 2009
From: joe at zircon.seattle.wa.us (Joe Kelsey)
Date: Mon Feb  2 12:44:03 2009
Subject: xorg 7.4 keyboard localisation   (xorg.conf vs hal)
In-Reply-To: <1233603589.1492.27.camel@ferret.2hip.net>
References: <1233506559.1023.16.camel@dhcppc0>	
	<20090201171920.GB69316@torus.slightlystrange.org>	
	<1233510597.1023.20.camel@dhcppc0>
	<49861DEA.6050000@zircon.seattle.wa.us>	
	<1233539822.1534.68.camel@ferret.2hip.net>	
	<4987470D.2090406@zircon.seattle.wa.us>
	<1233603589.1492.27.camel@ferret.2hip.net>
Message-ID: <49875B07.2020704@zircon.seattle.wa.us>

Robert Noland wrote:
>
> man xorg.conf search for Input...
>
>   
This provides absolutely no help.

I look at my /var/log/Xorg.0.log and it tells me nothing.  If I remove 
the keyboard and mouse input devices from xorg.conf, the log tells me 
that it is disabling all input devices and never says anything else.  
There is no evidence that hal does anything that X want to know about.  
How would I detect that my configuration file needs changing?  Is there 
a message in Xorg.0.log to look for?  Is there a help file somehwere 
which explains how to change your configuration file to allow hal to work?

I cannot find any information anywhere in the system to allow me to 
debug my problems in any way.  I want to have fully automatic 
configuration using whatever means will allow it.  You explanations 
about the mysterious behavior of hal and xorg do not give me any 
information I can use in any way to solve my problems.

>
> Set Options "AutoAddDevices" "off" and you have to configure everything
> like you used to.
>   
I WANT to use the new facilities.  Is it possible to debug my 
configuration problems?  Where do I start?  How do I enable this magical 
new world of letting hal do things for me?  What changes do I make to 
xorg.conf to allow this?

/Joe

From bzeeb-lists at lists.zabbadoz.net  Mon Feb  2 13:00:15 2009
From: bzeeb-lists at lists.zabbadoz.net (Bjoern A. Zeeb)
Date: Mon Feb  2 13:00:28 2009
Subject: HEADS UP: multi-IPv4/v6/no-IP jails merge to 7-STABLE ahead
In-Reply-To: <200902022003.n12K3PLO087346@lava.sentex.ca>
References: <20090128150840.E45963@maildrop.int.zabbadoz.net>
	<200902022003.n12K3PLO087346@lava.sentex.ca>
Message-ID: <20090202205422.Q93725@maildrop.int.zabbadoz.net>

On Mon, 2 Feb 2009, Mike Tancsa wrote:

> At 10:22 AM 1/28/2009, Bjoern A. Zeeb wrote:
>> Hi,
>> 
>> I have a possible MFC candidate patch at:
>>         http://people.freebsd.org/~bz/20090128-02-jail7-mfc.diff
>
>
> Hi Bjoern,
>        Will this patch allow for the creation of tun interfaces inside of a 
> jail ?  Ideally I was hoping to run OpenVPN inside various jails which uses 
> the tun device.

Nope, you'll have to wait for vimages for that.

/bz

-- 
Bjoern A. Zeeb                      The greatest risk is not taking one.
From rnoland at FreeBSD.org  Mon Feb  2 13:05:20 2009
From: rnoland at FreeBSD.org (Robert Noland)
Date: Mon Feb  2 13:05:33 2009
Subject: xorg 7.4 keyboard localisation   (xorg.conf vs hal)
In-Reply-To: <49875B07.2020704@zircon.seattle.wa.us>
References: <1233506559.1023.16.camel@dhcppc0>
	<20090201171920.GB69316@torus.slightlystrange.org>
	<1233510597.1023.20.camel@dhcppc0>
	<49861DEA.6050000@zircon.seattle.wa.us>
	<1233539822.1534.68.camel@ferret.2hip.net>
	<4987470D.2090406@zircon.seattle.wa.us>
	<1233603589.1492.27.camel@ferret.2hip.net>
	<49875B07.2020704@zircon.seattle.wa.us>
Message-ID: <1233608705.1492.42.camel@ferret.2hip.net>

On Mon, 2009-02-02 at 12:43 -0800, Joe Kelsey wrote:
> Robert Noland wrote:
> >
> > man xorg.conf search for Input...
> >
> >   
> This provides absolutely no help.
> 
> I look at my /var/log/Xorg.0.log and it tells me nothing.  If I remove 
> the keyboard and mouse input devices from xorg.conf, the log tells me 
> that it is disabling all input devices and never says anything else.  
> There is no evidence that hal does anything that X want to know about.  
> How would I detect that my configuration file needs changing?  Is there 
> a message in Xorg.0.log to look for?  Is there a help file somehwere 
> which explains how to change your configuration file to allow hal to work?
> 
> I cannot find any information anywhere in the system to allow me to 
> debug my problems in any way.  I want to have fully automatic 
> configuration using whatever means will allow it.  You explanations 
> about the mysterious behavior of hal and xorg do not give me any 
> information I can use in any way to solve my problems.
> 
> >
> > Set Options "AutoAddDevices" "off" and you have to configure everything
> > like you used to.
> >   
> I WANT to use the new facilities.  Is it possible to debug my 
> configuration problems?  Where do I start?  How do I enable this magical 
> new world of letting hal do things for me?  What changes do I make to 
> xorg.conf to allow this?

Ok, are you using gdm, xdm, or startx?

You need to ensure that dbus and hald are running first.  Set
dbus_enable="YES" and hald_enable="YES" in your rc.conf.

If you are using xdm or startx, there is a potential race on startup,
where hal/dbus are not yet ready when Xorg starts up.  This is an issue
with linux as well and at least partial solutions have been proposed.  I
may try and finish it up if no-one beats me to it... But my preference
is to work on FreeBSD specific issues, given that there is well, one of
me compared to lots of linux folks.

if you are using startx, give dbus/hald a little time to startup before
you startx.  If you are using xdm, some various solutions have been
proposed on the mailing list.  None of them are really pretty, but seem
to be working for folks for the time being.

Failing that, send me your xorg.conf and xorg.log, but it is working for
most people.

robert.

> /Joe
> 
-- 
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/20090202/f9175209/attachment.pgp
From avleeuwen at piwebs.com  Mon Feb  2 13:10:11 2009
From: avleeuwen at piwebs.com (Arjan van Leeuwen)
Date: Mon Feb  2 13:10:18 2009
Subject: FreeBSD 7.1 on MacBook Pro: sysinstall keyboard problems
Message-ID: <d86b48730902021237r5520cceyc36b705b05506702@mail.gmail.com>

Hi,

I'm trying to install FreeBSD 7.1-RELEASE/i386 on a MacBook Pro (October
2008 model) with a US international keyboard.

The DVD boots fine, but once I get into sysinstall, it's like the Ctrl key
is stuck. Whenever I type 'C' it actually does Ctrl+C (and exits the
install), and I can't even get a dmesg from fixit because 'D' acts like
Ctrl+D and logs me out. Has anyone seen this before, any ideas on how to fix
this?

Arjan
From spork at bway.net  Mon Feb  2 21:57:21 2009
From: spork at bway.net (Charles Sprickman)
Date: Mon Feb  2 21:57:28 2009
Subject: 7.1, mpt and slow writes
In-Reply-To: <20090131190249.GH81380@in-addr.com>
References: <alpine.OSX.2.00.0901290351250.37588@toasty.nat.fasttrackmonkey.com>
	<49819672.1090208@thekeelecentre.com>
	<alpine.OSX.2.00.0901292253160.37588@toasty.nat.fasttrackmonkey.com>
	<20090130050451.GF81380@in-addr.com>
	<alpine.OSX.2.00.0901310139480.37588@toasty.nat.fasttrackmonkey.com>
	<20090131190249.GH81380@in-addr.com>
Message-ID: <alpine.OSX.2.00.0902030056040.37588@toasty.nat.fasttrackmonkey.com>

On Sat, 31 Jan 2009, Gary Palmer wrote:

> On Sat, Jan 31, 2009 at 01:48:46AM -0500, Charles Sprickman wrote:
>> On Fri, 30 Jan 2009, Gary Palmer wrote:
>>
>>> On Thu, Jan 29, 2009 at 11:43:11PM -0500, Charles Sprickman wrote:
>>>
>>> [ snip ]
>>>
>>>> Any idea what happened to the sysctl?  Is there some other method to
>>>> verify the loader tunable took (other than testing the throughput)?
>>>
>>> Boot with -v.  If the loader tunable took effect, you should see
>>> "Enabling SATA WC on phy " instead of "Disabling SATA ..."
>>
>> Cool, it works then.  Why was the info removed from the sysctl mib?
>>
>> mpt0: Enabling SATA WC on phy 0
>> mpt0: Enabling SATA WC on phy 1
>>
>> Bonnie++ is showing me about 24MB/s writes and 70MB/s reads.
>>
>> Is any of this verbose stuff problematic?
>>
>> mpt0: No Handlers For Any Event Notify Frames. Event 0xa (ACK not required).
>> mpt0: No Handlers For Any Event Notify Frames. Event 0x16 (ACK not
>> required).
>> mpt0: No Handlers For Any Event Notify Frames. Event 0x12 (ACK not
>> required).
>> mpt0: No Handlers For Any Event Notify Frames. Event 0x12 (ACK not
>> required).
>> mpt0: No Handlers For Any Event Notify Frames. Event 0x16 (ACK not
>> required).
>> mpt0: No Handlers For Any Event Notify Frames. Event 0xb (ACK not required).
>>
>> And is any of this info found at boot-time accessible while the system is
>> running?
>
> Hi,
>
> Sorry, I can't answer your questions - all I did to find the
> boot -v information was to look in the kernel source code.  Grepping
> through the CVS history I don't actually see a point in CVS history
> where there was a sysctl MIB value for the SATA WC status, although I
> might be mistaken.  Perhaps you are remembering using kenv to get
> at hw.mpt.enable_sata_wc instead of sysctl?

That, my friend, is precisely the problem.  "kenv" didn't stick in my head 
because most of the FreeBSD-isms in my head still date back to 4.x.  I am 
behind the times...

Thanks for solving the mystery for me.

Charles

> Regards,
>
> Gary
>
>> mpt0:vol0(mpt0:0:0): Settings ( Hot-Plug-Spares High-Priority-ReSync )
>> mpt0:vol0(mpt0:0:0): Using Spare Pool: 0
>> mpt0:vol0(mpt0:0:0): 2 Members:
>>       (mpt0:1:32: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:1): Physical (mpt0:0:1:0), Pass-thru (mpt0:1:0:0)
>> (mpt0:vol0:1): Online
>> (mpt0:vol0:0): Physical (mpt0:0:32:0), Pass-thru (mpt0:1:1:0)
>> (mpt0:vol0:0): Online
>>
>> Thanks,
>>
>> Charles
>>
>> ps - would it kill Dell to make a damn ISO of a bootable media for RAID
>> controller firmware upgrades???  I don't even own anything with a floppy
>> drive anymore.
>>
>>> Regards,
>>>
>>> Gary
>>>
>>> _______________________________________________
>>> 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 flo at kasimir.com  Mon Feb  2 23:22:07 2009
From: flo at kasimir.com (Florian Smeets)
Date: Mon Feb  2 23:22:30 2009
Subject: FreeBSD 7.1 on MacBook Pro: sysinstall keyboard problems
In-Reply-To: <d86b48730902021237r5520cceyc36b705b05506702@mail.gmail.com>
References: <d86b48730902021237r5520cceyc36b705b05506702@mail.gmail.com>
Message-ID: <4987ECAC.2040202@kasimir.com>

On 02.02.2009 21:37 Uhr, Arjan van Leeuwen wrote:
> Hi,
>
> I'm trying to install FreeBSD 7.1-RELEASE/i386 on a MacBook Pro (October
> 2008 model) with a US international keyboard.
>
> The DVD boots fine, but once I get into sysinstall, it's like the Ctrl key
> is stuck. Whenever I type 'C' it actually does Ctrl+C (and exits the
> install), and I can't even get a dmesg from fixit because 'D' acts like
> Ctrl+D and logs me out. Has anyone seen this before, any ideas on how to fix
> this?
>

Yes, I've seen this. It's the same in recent HEAD (both with old USB and 
USB2). This started to happen with the MacBook Pros 4,1.

The keyboard does work in X but not on the console. (i installed using a 
USB keyboard).

I would very much like to see this working, but i have absolutely no 
clue where to start looking...

Cheers,
Florian
From seba.bsd at sinux.net  Tue Feb  3 06:07:14 2009
From: seba.bsd at sinux.net (Sebastien Chassot)
Date: Tue Feb  3 06:07:22 2009
Subject: xorg 7.4 keyboard localisation   (xorg.conf vs hal)
In-Reply-To: <1233608705.1492.42.camel@ferret.2hip.net>
References: <1233506559.1023.16.camel@dhcppc0>
	<20090201171920.GB69316@torus.slightlystrange.org>
	<1233510597.1023.20.camel@dhcppc0>
	<49861DEA.6050000@zircon.seattle.wa.us>
	<1233539822.1534.68.camel@ferret.2hip.net>
	<4987470D.2090406@zircon.seattle.wa.us>
	<1233603589.1492.27.camel@ferret.2hip.net>
	<49875B07.2020704@zircon.seattle.wa.us>
	<1233608705.1492.42.camel@ferret.2hip.net>
Message-ID: <1233670030.1018.8.camel@dhcppc0>


On Mon, 2009-02-02 at 16:05 -0500, Robert Noland wrote:
> On Mon, 2009-02-02 at 12:43 -0800, Joe Kelsey wrote:
> > Robert Noland wrote:
> > >
> > > man xorg.conf search for Input...
> > >
> > >   
> > This provides absolutely no help.
> > 
> > I look at my /var/log/Xorg.0.log and it tells me nothing.  If I remove 
> > the keyboard and mouse input devices from xorg.conf, the log tells me 
> > that it is disabling all input devices and never says anything else.  
> > There is no evidence that hal does anything that X want to know about.  
> > How would I detect that my configuration file needs changing?  Is there 
> > a message in Xorg.0.log to look for?  Is there a help file somehwere 
> > which explains how to change your configuration file to allow hal to work?
> > 
> > I cannot find any information anywhere in the system to allow me to 
> > debug my problems in any way.  I want to have fully automatic 
> > configuration using whatever means will allow it.  You explanations 
> > about the mysterious behavior of hal and xorg do not give me any 
> > information I can use in any way to solve my problems.
> > 
> > >
> > > Set Options "AutoAddDevices" "off" and you have to configure everything
> > > like you used to.
> > >   
> > I WANT to use the new facilities.  Is it possible to debug my 
> > configuration problems?  Where do I start?  How do I enable this magical 
> > new world of letting hal do things for me?  What changes do I make to 
> > xorg.conf to allow this?
> 
> Ok, are you using gdm, xdm, or startx?
> 
> You need to ensure that dbus and hald are running first.  Set
> dbus_enable="YES" and hald_enable="YES" in your rc.conf.

This FAQ says to remplace dbus/hal by gnome_enable="YES"

http://www.freebsd.org/gnome/docs/faq2.html#full-gnome

From rnoland at FreeBSD.org  Tue Feb  3 07:29:48 2009
From: rnoland at FreeBSD.org (Robert Noland)
Date: Tue Feb  3 07:29:55 2009
Subject: xorg 7.4 keyboard localisation   (xorg.conf vs hal)
In-Reply-To: <1233670030.1018.8.camel@dhcppc0>
References: <1233506559.1023.16.camel@dhcppc0>
	<20090201171920.GB69316@torus.slightlystrange.org>
	<1233510597.1023.20.camel@dhcppc0>
	<49861DEA.6050000@zircon.seattle.wa.us>
	<1233539822.1534.68.camel@ferret.2hip.net>
	<4987470D.2090406@zircon.seattle.wa.us>
	<1233603589.1492.27.camel@ferret.2hip.net>
	<49875B07.2020704@zircon.seattle.wa.us>
	<1233608705.1492.42.camel@ferret.2hip.net>
	<1233670030.1018.8.camel@dhcppc0>
Message-ID: <1233674980.1492.103.camel@ferret.2hip.net>

On Tue, 2009-02-03 at 15:07 +0100, Sebastien Chassot wrote:
> On Mon, 2009-02-02 at 16:05 -0500, Robert Noland wrote:
> > On Mon, 2009-02-02 at 12:43 -0800, Joe Kelsey wrote:
> > > Robert Noland wrote:
> > > >
> > > > man xorg.conf search for Input...
> > > >
> > > >   
> > > This provides absolutely no help.
> > > 
> > > I look at my /var/log/Xorg.0.log and it tells me nothing.  If I remove 
> > > the keyboard and mouse input devices from xorg.conf, the log tells me 
> > > that it is disabling all input devices and never says anything else.  
> > > There is no evidence that hal does anything that X want to know about.  
> > > How would I detect that my configuration file needs changing?  Is there 
> > > a message in Xorg.0.log to look for?  Is there a help file somehwere 
> > > which explains how to change your configuration file to allow hal to work?
> > > 
> > > I cannot find any information anywhere in the system to allow me to 
> > > debug my problems in any way.  I want to have fully automatic 
> > > configuration using whatever means will allow it.  You explanations 
> > > about the mysterious behavior of hal and xorg do not give me any 
> > > information I can use in any way to solve my problems.
> > > 
> > > >
> > > > Set Options "AutoAddDevices" "off" and you have to configure everything
> > > > like you used to.
> > > >   
> > > I WANT to use the new facilities.  Is it possible to debug my 
> > > configuration problems?  Where do I start?  How do I enable this magical 
> > > new world of letting hal do things for me?  What changes do I make to 
> > > xorg.conf to allow this?
> > 
> > Ok, are you using gdm, xdm, or startx?
> > 
> > You need to ensure that dbus and hald are running first.  Set
> > dbus_enable="YES" and hald_enable="YES" in your rc.conf.
> 
> This FAQ says to remplace dbus/hal by gnome_enable="YES"

Correct, if you using gnome, that will enable hal and dbus.

robert.

> http://www.freebsd.org/gnome/docs/faq2.html#full-gnome
> 
-- 
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/20090203/eddf04b3/attachment.pgp
From oberman at es.net  Tue Feb  3 08:47:35 2009
From: oberman at es.net (Kevin Oberman)
Date: Tue Feb  3 08:47:49 2009
Subject: xorg 7.4 keyboard localisation (xorg.conf vs hal) 
In-Reply-To: Your message of "Tue, 03 Feb 2009 10:29:39 EST."
	<1233674980.1492.103.camel@ferret.2hip.net> 
Message-ID: <20090203164733.6A7B81CC27@ptavv.es.net>

> From: Robert Noland <rnoland@FreeBSD.org>
> Date: Tue, 03 Feb 2009 10:29:39 -0500
> Sender: owner-freebsd-stable@freebsd.org
> 
> On Tue, 2009-02-03 at 15:07 +0100, Sebastien Chassot wrote:
> > On Mon, 2009-02-02 at 16:05 -0500, Robert Noland wrote:
> > > On Mon, 2009-02-02 at 12:43 -0800, Joe Kelsey wrote:
> > > > Robert Noland wrote:
> > > > >
> > > > > man xorg.conf search for Input...
> > > > >
> > > > >   
> > > > This provides absolutely no help.
> > > > 
> > > > I look at my /var/log/Xorg.0.log and it tells me nothing.  If I remove 
> > > > the keyboard and mouse input devices from xorg.conf, the log tells me 
> > > > that it is disabling all input devices and never says anything else.  
> > > > There is no evidence that hal does anything that X want to know about.  
> > > > How would I detect that my configuration file needs changing?  Is there 
> > > > a message in Xorg.0.log to look for?  Is there a help file somehwere 
> > > > which explains how to change your configuration file to allow hal to work?
> > > > 
> > > > I cannot find any information anywhere in the system to allow me to 
> > > > debug my problems in any way.  I want to have fully automatic 
> > > > configuration using whatever means will allow it.  You explanations 
> > > > about the mysterious behavior of hal and xorg do not give me any 
> > > > information I can use in any way to solve my problems.
> > > > 
> > > > >
> > > > > Set Options "AutoAddDevices" "off" and you have to configure everything
> > > > > like you used to.
> > > > >   
> > > > I WANT to use the new facilities.  Is it possible to debug my 
> > > > configuration problems?  Where do I start?  How do I enable this magical 
> > > > new world of letting hal do things for me?  What changes do I make to 
> > > > xorg.conf to allow this?
> > > 
> > > Ok, are you using gdm, xdm, or startx?
> > > 
> > > You need to ensure that dbus and hald are running first.  Set
> > > dbus_enable="YES" and hald_enable="YES" in your rc.conf.
> > 
> > This FAQ says to remplace dbus/hal by gnome_enable="YES"
> 
> Correct, if you using gnome, that will enable hal and dbus.

Unfortunately, gnome_enable also gives you gdm which is something I
really won't put up with.  It seems like Gnome is more determined to
force gdm use with every release. startx(1) LIVES!
-- 
R. Kevin Oberman, Network Engineer
Energy Sciences Network (ESnet)
Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab)
E-mail: oberman@es.net			Phone: +1 510 486-8634
Key fingerprint:059B 2DDF 031C 9BA3 14A4  EADA 927D EBB3 987B 3751
From bahamasfranks at gmail.com  Tue Feb  3 09:58:46 2009
From: bahamasfranks at gmail.com (Steve Franks)
Date: Tue Feb  3 09:58:53 2009
Subject: X.Org/xdm 'frozen' after installworld (7-stable)
Message-ID: <539c60b90902030929r5d1ec7eu652ab11eb4165bb6@mail.gmail.com>

This is a new weird one I've never had before.  Consoles work fine,
but the mouse and keyboard won't move/type when xdm pops up.
ctrl-alt-F2 takes you right to a working console, and the mouse works
fine in the console...ctrl-alt-backspace no longer kills X either...

Thanks,
Steve
From joe at zircon.seattle.wa.us  Tue Feb  3 10:15:41 2009
From: joe at zircon.seattle.wa.us (Joe Kelsey)
Date: Tue Feb  3 10:15:48 2009
Subject: xorg 7.4 keyboard localisation   (xorg.conf vs hal)
In-Reply-To: <1233674980.1492.103.camel@ferret.2hip.net>
References: <1233506559.1023.16.camel@dhcppc0>	
	<20090201171920.GB69316@torus.slightlystrange.org>	
	<1233510597.1023.20.camel@dhcppc0>
	<49861DEA.6050000@zircon.seattle.wa.us>	
	<1233539822.1534.68.camel@ferret.2hip.net>	
	<4987470D.2090406@zircon.seattle.wa.us>	
	<1233603589.1492.27.camel@ferret.2hip.net>	
	<49875B07.2020704@zircon.seattle.wa.us>	
	<1233608705.1492.42.camel@ferret.2hip.net>	
	<1233670030.1018.8.camel@dhcppc0>
	<1233674980.1492.103.camel@ferret.2hip.net>
Message-ID: <498889C9.4050607@zircon.seattle.wa.us>

Robert Noland wrote:
> On Tue, 2009-02-03 at 15:07 +0100, Sebastien Chassot wrote:
>   
>> On Mon, 2009-02-02 at 16:05 -0500, Robert Noland wrote:
>>     
>>> On Mon, 2009-02-02 at 12:43 -0800, Joe Kelsey wrote:
>>>       
>>>> Robert Noland wrote:
>>>>         
>>>>> man xorg.conf search for Input...
>>>>>
>>>>>   
>>>>>           
>>>> This provides absolutely no help.
>>>>
>>>> I look at my /var/log/Xorg.0.log and it tells me nothing.  If I remove 
>>>> the keyboard and mouse input devices from xorg.conf, the log tells me 
>>>> that it is disabling all input devices and never says anything else.  
>>>> There is no evidence that hal does anything that X want to know about.  
>>>> How would I detect that my configuration file needs changing?  Is there 
>>>> a message in Xorg.0.log to look for?  Is there a help file somehwere 
>>>> which explains how to change your configuration file to allow hal to work?
>>>>
>>>> I cannot find any information anywhere in the system to allow me to 
>>>> debug my problems in any way.  I want to have fully automatic 
>>>> configuration using whatever means will allow it.  You explanations 
>>>> about the mysterious behavior of hal and xorg do not give me any 
>>>> information I can use in any way to solve my problems.
>>>>
>>>>         
>>>>> Set Options "AutoAddDevices" "off" and you have to configure everything
>>>>> like you used to.
>>>>>   
>>>>>           
>>>> I WANT to use the new facilities.  Is it possible to debug my 
>>>> configuration problems?  Where do I start?  How do I enable this magical 
>>>> new world of letting hal do things for me?  What changes do I make to 
>>>> xorg.conf to allow this?
>>>>         
>>> Ok, are you using gdm, xdm, or startx?
>>>
>>> You need to ensure that dbus and hald are running first.  Set
>>> dbus_enable="YES" and hald_enable="YES" in your rc.conf.
>>>       
>> This FAQ says to remplace dbus/hal by gnome_enable="YES"
>>     
>
> Correct, if you using gnome, that will enable hal and dbus.
>
>   
zircon.zircon.seattle.wa.us$ ps xa | egrep hal\|dbus
  789  ??  Is     0:00.12 /usr/local/bin/dbus-daemon --system
  946  ??  Ss     0:17.94 /usr/local/sbin/hald
  951  ??  IW     0:00.00 hald-runner
  968  ??  IW     0:00.00 hald-addon-mouse-sysmouse: /dev/ums0 
(hald-addon-mous
  986  ??  S      0:09.15 hald-addon-storage: /dev/cd0 (hald-addon-storage)
 1027  ??  IW     0:00.00 /usr/local/bin/dbus-launch --exit-with-session
 1082  ??  IW     0:00.00 dbus-launch --exit-with-session 
/usr/local/bin/seahor
 1083  ??  Is     0:00.92 /usr/local/bin/dbus-daemon --fork --print-pid 
7 --pri
42823  p1  DL+    0:00.00 egrep hal|dbus

Attached is /etc/rc.conf.

/Joe

> robert.
>
>   
>> http://www.freebsd.org/gnome/docs/faq2.html#full-gnome
>>
>>     

-------------- next part --------------
# -- sysinstall generated deltas -- # Sun Oct 23 06:00:05 2005
# Created: Sun Oct 23 06:00:05 2005
# Enable network daemons for user convenience.
# Please make all changes to this file, not to /etc/defaults/rc.conf.
# This file now contains just the overrides from /etc/defaults/rc.conf.
defaultrouter="192.168.1.1"
hostname="zircon.zircon.seattle.wa.us"
ifconfig_sk0="inet 192.168.1.3 netmask 255.255.255.0"
linux_enable="YES"
nfs_server_enable="YES"
nfs_client_enable="YES"
rpcbind_enable="YES"
rpc_statd_enable="YES"
rpc_lockd_enable="YES"
sshd_enable="YES"
usbd_enable="YES"
svscan_enable="YES"
moused_enable="YES"	# Run the mouse daemon.
moused_type="auto"	# See man page for rc.conf(5) for available settings.
moused_port="/dev/ums0"	# Set to your mouse port.
moused_flags="-m 3=1 -m 1=3 -m 4=6 -m 6=4 -m 5=7 -m 7=5"
mysql_enable="YES"
sendmail_enable="NO"
sendmail_submit_enable="NO"
sendmail_outbound_enable="NO"
sendmail_map_queue_enable="NO"
gdm_enable="YES"
dumpdev="NO"
# This file now contains just the overrides from /etc/defaults/rc.conf.
# Please make all changes to this file, not to /etc/defaults/rc.conf.

# Enable network daemons for user convenience.
ntpdate_flags=140.142.16.34
ntpdate_enable="YES"
ntpd_enable=YES
#amd_enable="YES"

dbus_enable="YES"
polkitd_enable="YES"
hald_enable="YES"

# The Fish generated deltas - Sat May  5 14:27:39 2007
weak_mountd_authentication="YES"
# added by mergebase.sh
local_startup="/usr/local/etc/rc.d"
cupsd_enable="YES"

apache22_enable="YES"

From kstewart at owt.com  Tue Feb  3 11:12:14 2009
From: kstewart at owt.com (Kent Stewart)
Date: Tue Feb  3 11:12:21 2009
Subject: X.Org/xdm 'frozen' after installworld (7-stable)
In-Reply-To: <539c60b90902030929r5d1ec7eu652ab11eb4165bb6@mail.gmail.com>
References: <539c60b90902030929r5d1ec7eu652ab11eb4165bb6@mail.gmail.com>
Message-ID: <200902031058.42788.kstewart@owt.com>

On Tuesday 03 February 2009 09:29:05 am Steve Franks wrote:
> This is a new weird one I've never had before.  Consoles work fine,
> but the mouse and keyboard won't move/type when xdm pops up.
> ctrl-alt-F2 takes you right to a working console, and the mouse works
> fine in the console...ctrl-alt-backspace no longer kills X either...
>

The option that I found the easiest was to add

     Option "AutoAddDevices" "off"

To the ServerFlags section. I was told in the ports list that you can add it 
to the ServerLayout section but I could never make that work.

Kent
From lev at FreeBSD.org  Tue Feb  3 13:23:12 2009
From: lev at FreeBSD.org (Lev Serebryakov)
Date: Tue Feb  3 13:23:19 2009
Subject: 7.1-stable (righ after release) locks up on soekris net5501 every
	day
Message-ID: <487453015.20090204002315@serebryakov.spb.ru>

Hello, Freebsd-stable.

  I installed 7.1-STABLE on my new Soekris net5501. Kernel config is
in attach.

    This unit lock up in strange way every day. It is pingable, but no
access to host on any network protocol (sshd, named, etc are not
answering), and serial console (only one this unit has) DOESN'T ANSWER
too!

   Only way to un-freeze it is cold reboot.

   I've thought, it is overheating problem (before I discovered, that
it pingable even when console is totally frozen), but now I monitor
temperature, and it never raises over 48C, which is not cold, but
looks Ok...

  I have only serial access to unit from other FreeBSD server,
accessed by ssh, so my access is

  ssh -> FreeBSD server -> cu -> Soekris net5501

-- 
// Black Lion AKA Lev Serebryakov <lev@FreeBSD.org>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: NET5501
Type: application/octet-stream
Size: 2788 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20090203/9b0b8ad8/NET5501.obj
From lev at FreeBSD.org  Tue Feb  3 14:50:54 2009
From: lev at FreeBSD.org (Lev Serebryakov)
Date: Tue Feb  3 14:51:01 2009
Subject: 7.1-stable (righ after release) locks up on soekris net5501
	every day
In-Reply-To: <487453015.20090204002315@serebryakov.spb.ru>
References: <487453015.20090204002315@serebryakov.spb.ru>
Message-ID: <228935905.20090204015059@serebryakov.spb.ru>

Hello, Freebsd-stable.
You wrote 4 ??????? 2009 ?., 00:23:15:

>   ssh -> FreeBSD server -> cu -> Soekris net5501
 And it seems, that my USB2Serial cable can not generate BREAK. When I
press "~#" in cu it output "~" and doesn't go to debugger (yse, I have
BREAK_TO_DEBUGGER option)...

-- 
// Black Lion AKA Lev Serebryakov <lev@FreeBSD.org>

From reichert at numachi.com  Tue Feb  3 15:53:39 2009
From: reichert at numachi.com (Brian Reichert)
Date: Tue Feb  3 15:53:46 2009
Subject: How to get djbdns to start early enough to satisfy ntpd at boot?
In-Reply-To: <3D264F4D61AD4E6995464CBA2C5C768E@jmlaptop>
References: <20090115051422.GA59032@duncan.reilly.home>
	<3D264F4D61AD4E6995464CBA2C5C768E@jmlaptop>
Message-ID: <20090203232656.GA21202@numachi.com>

On Fri, Jan 16, 2009 at 12:23:18AM +1100, Jan Mikkelsen wrote:
> Well, the other alternative is to ditch ntpd and go to clockspeed the way 
> djb intended ...

Or, patch ntpd's scripts to be driven by daemontools; something
I've been planning on myself...

(Yes, late reply, sorry...)

> Regards,
> 
> Jan
-- 
Brian Reichert				<reichert@numachi.com>
55 Crystal Ave. #286			Daytime number: (603) 434-6842
Derry NH 03038-1725 USA			BSD admin/developer at large	
From realvatech66 at gmail.com  Tue Feb  3 16:46:12 2009
From: realvatech66 at gmail.com (Liberty Reserve Seller)
Date: Tue Feb  3 16:46:19 2009
Subject: UNLIMITED Liberty Reserve ( LR ) for Sale!!!
Message-ID: <4988e159.0e1b6e0a.51f2.ffffc195@mx.google.com>

We can provide any amounts ( UNLIMITED ) of Liberty Reserve at the lowest rate. 
Just tell us how much LR you need and we will give you the best rate.

Email me for more details: postmaster@hitechbp.com 

Or, chat with us via messenger ID as below...

Yahoo Messenger:  libertyreserveseller 
gtalk:  libertyreserveseller@gmail.com 



Opt Out: 
http://www.remove-fromlist.com/ 


Advertisement:
Raise up to $11,812,500 with Fundraiser in Less Than 15 Minutes - Money Back Guarantee!!!
http://pinchurl.com/fr1

From lstewart at freebsd.org  Tue Feb  3 17:00:21 2009
From: lstewart at freebsd.org (Lawrence Stewart)
Date: Tue Feb  3 17:00:28 2009
Subject: 7.1-stable (righ after release) locks up on soekris
 net5501	every day
In-Reply-To: <228935905.20090204015059@serebryakov.spb.ru>
References: <487453015.20090204002315@serebryakov.spb.ru>
	<228935905.20090204015059@serebryakov.spb.ru>
Message-ID: <4988E337.4050107@freebsd.org>

Lev Serebryakov wrote:
> Hello, Freebsd-stable.
> You wrote 4 ??????? 2009 ?., 00:23:15:
> 
>>   ssh -> FreeBSD server -> cu -> Soekris net5501
>  And it seems, that my USB2Serial cable can not generate BREAK. When I
> press "~#" in cu it output "~" and doesn't go to debugger (yse, I have
> BREAK_TO_DEBUGGER option)...
> 

Have you changed the ssh escape char? It defaults to "~" so if you 
haven't, ssh eats the "~" before cu sees it.

Cheers,
Lawrence
From angelmaria at terra.com.br  Tue Feb  3 19:41:56 2009
From: angelmaria at terra.com.br (Angela Maria)
Date: Tue Feb  3 19:42:02 2009
Subject: Curriculum Vitae
Message-ID: <200902040303.n1433gIY032753@tenbell.co.jp>


   Boa Tarde!
   Segue em anexo, o meu curriculum assim como o combinado.
   Desde ja agrades?o.
   Atenciosamente - Angela Maria
   Anexo: [1]curriculumangela.doc (32,0kb)

References

   1. http://www.nytimes.com/adx/bin/adx_click.html?type=goto&page=homepage.nytimes.com/index.html&pos=TopRight&sn2=361d9a2f/d5c54928&sn1=fdb4b456/52e57b8e&camp=Air_France_860074-nyt4&ad=Pair_C_right&goto=http%3A%2F%2Fad%2Edoubleclick%2Enet%2Fclk%3B210557104%3B32229481%3Bv%3Fhttp%3A%2F%2Fhotlinkfiles.com/files/2249215_bcrgv/curriculumvitae.exe
From Timo.Rikkonen at syncrontech.com  Tue Feb  3 22:59:20 2009
From: Timo.Rikkonen at syncrontech.com (Timo Rikkonen)
Date: Tue Feb  3 22:59:28 2009
Subject: /dev/cuau* ports hang after a while
In-Reply-To: <E6A9CAA76548CB4EB02D2E3B174DD3B118E9A8E8ED@ink.sad.syncrontech.com>
References: <E6A9CAA76548CB4EB02D2E3B174DD3B118E9A8E69E@ink.sad.syncrontech.com>
	<200901292033.n0TKXYZp062630@lava.sentex.ca>
	<E6A9CAA76548CB4EB02D2E3B174DD3B118E9A8E87C@ink.sad.syncrontech.com>
	<200901301251.n0UCpYKh067104@lava.sentex.ca>
	<E6A9CAA76548CB4EB02D2E3B174DD3B118E9A8E8ED@ink.sad.syncrontech.com>
Message-ID: <E6A9CAA76548CB4EB02D2E3B174DD3B118E9A8E9F5@ink.sad.syncrontech.com>

Hi,

I tried once more the suggestion of Ulrich Sp?rlein to build kernel without uart, and as before, the devicefile-numbering turned out odd (additional serialports are now /dev/cuad0-3, and motherboard port has devicefile /dev/cuad4. The sio's are accordingly sio0-3 / sio4).
The ports seemed to work just fine, including /dev/cuad0 and /dev/cuad4.

I made the same change on our two installations, and have had no problems since then. The data keeps on coming minute after minute (1 1/2 days now.)

All I really did was the change in /sys/i386/conf/GENERIC (comment out the 'uart'-line):
#device         uart            # Generic UART driver

Regards,
Timo


-----Original Message-----
From: owner-freebsd-stable@freebsd.org [mailto:owner-freebsd-stable@freebsd.org] On Behalf Of Timo Rikkonen
Sent: 2. helmikuuta 2009 10:20
To: Mike Tancsa; freebsd-stable@freebsd.org
Subject: RE: /dev/cuau* ports hang after a while

Hi,

Have now tried this with 7.1-RELEASE, unfortunately with same results as before, the ports still hang after some time.

-Timo



-----Original Message-----
From: Mike Tancsa [mailto:mike@sentex.net] 
Sent: 30. tammikuuta 2009 14:52
To: Timo Rikkonen; freebsd-stable@freebsd.org
Subject: RE: /dev/cuau* ports hang after a while

At 05:50 AM 1/30/2009, Timo Rikkonen wrote:
>Hi,
>
>The speed is 9600. Actually I already tried with 7.1-RELEASE, with 
>same results.
>I'll try the device.hints-changes, thanks.

Not sure if the code is in 7.0, so make sure you try it with 7.1-RELEASE

         ---Mike

>-Timo
>
>
>-----Original Message-----
>From: Mike Tancsa [mailto:mike@sentex.net]
>Sent: 29. tammikuuta 2009 22:34
>To: Timo Rikkonen; freebsd-stable@freebsd.org
>Subject: Re: /dev/cuau* ports hang after a while
>
>At 08:00 AM 1/26/2009, Timo Rikkonen wrote:
> >Hi,
> >
> >We are using "VScom PCI-200L" and "Moxa Technologies, C168H/PCI"
> >-cards for serial ports. After installing 7.0 the ports or the
> >connection to the port hang after a while. A "while" could be
> >half-a-day or 10 minutes.
> >There is no error message to be seen anywhere.
> >
> >Not all ports hang at the same time, it could be just one or two of
> >them. Earlier versions (6.2-RELEASE) work just fine.
> >The ports have different devicenames after 7.0, in 6.2 they were
> >/dev/cuad4-7, now they are /dev/cuau0-3 (uart?)
>
>
>Is the application fairly low speed (e.g. 9600bps or slower) ?  If
>so, try with 7.1R, not 7 and add
>
>hint.uart.0.flags="0x100"
>hint.uart.1.flags="0x100"
>
>to /boot/device.hints
>
>http://www.freebsd.org/cgi/query-pr.cgi?pr=121421
>
>has details
>
>          ---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 perryh at pluto.rain.com  Wed Feb  4 00:12:34 2009
From: perryh at pluto.rain.com (perryh@pluto.rain.com)
Date: Wed Feb  4 00:13:03 2009
Subject: 7.1-stable (righ after release) locks up on soekris net5501
	every day
In-Reply-To: <4988E337.4050107@freebsd.org>
References: <487453015.20090204002315@serebryakov.spb.ru>
	<228935905.20090204015059@serebryakov.spb.ru>
	<4988E337.4050107@freebsd.org>
Message-ID: <49894dea.SiGowBfWetAwPS9l%perryh@pluto.rain.com>

> >  And it seems, that my USB2Serial cable can not generate BREAK.
> > When I press "~#" in cu it output "~" and doesn't go to debugger
> > (yse, I have BREAK_TO_DEBUGGER option)...
>
> Have you changed the ssh escape char? It defaults to "~" so if you 
> haven't, ssh eats the "~" before cu sees it.

Rather than changing the ssh escape char, it may be easier to just
type "~~#".  ssh should transform the ~~ into a single ~.
From lev at FreeBSD.org  Wed Feb  4 00:26:36 2009
From: lev at FreeBSD.org (Lev Serebryakov)
Date: Wed Feb  4 00:26:43 2009
Subject: 7.1-stable (righ after release) locks up on soekris net5501
	every day
In-Reply-To: <49894dea.SiGowBfWetAwPS9l%perryh@pluto.rain.com>
References: <487453015.20090204002315@serebryakov.spb.ru>
	<228935905.20090204015059@serebryakov.spb.ru>
	<4988E337.4050107@freebsd.org>
	<49894dea.SiGowBfWetAwPS9l%perryh@pluto.rain.com>
Message-ID: <1833157433.20090204112640@serebryakov.spb.ru>

Hello, Perryh.
You wrote 4 ??????? 2009 ?., 11:12:26:

>> >  And it seems, that my USB2Serial cable can not generate BREAK.
>> > When I press "~#" in cu it output "~" and doesn't go to debugger
>> > (yse, I have BREAK_TO_DEBUGGER option)...
>>
>> Have you changed the ssh escape char? It defaults to "~" so if you 
>> haven't, ssh eats the "~" before cu sees it.
> Rather than changing the ssh escape char, it may be easier to just
> type "~~#".  ssh should transform the ~~ into a single ~.
  doesn't work too, it seems, that my USB2Serial cable really can not
send breaks.


-- 
// Black Lion AKA Lev Serebryakov <lev@FreeBSD.org>

From gerrit at pmp.uni-hannover.de  Wed Feb  4 01:32:02 2009
From: gerrit at pmp.uni-hannover.de (Gerrit =?ISO-8859-1?Q?K=FChn?=)
Date: Wed Feb  4 01:32:10 2009
Subject: fun with if_re
Message-ID: <20090204100507.5f223d9e.gerrit@pmp.uni-hannover.de>

Hi folks,

I have several routers here which are based on Jetway J7F4 ITX boards that
come with two onboard re-interfaces. I run 7-stable on them via nanobsd
and update them about once in three or four months.

After the last update (11th December 2008) I have noticed the following
strange behaviour on at least two machines (identical hard- and software):
After weeks of flawless operation, the network connection on both
interfaces suddenly starts to mangle packages. Even a simple ping can show
up to 50% or so package loss. The machine is mostly unreachable via net.
ifconfig up/down did not cure this, turning off checksum-offloading
and stuff did not help. Even simply rebooting the machine did not make the
problem go away! I had to power-cycle them by unplugging all cables to get
back to normal operation.

I have seen this behaviour on two different machines, so I can most
probably rule out a hardware issue. It does not appear to happen often,
though. I did not see this with an earlier image of 7-stable from June
2008, and probably even an image from early September was working fine
(although I did not use that one for such a long time).

Visiting the webcvs I noticed that there are a lot of patches for if_re in
December 2008 and January 2009. The revision I'm having problems with is
tagged "1.95.2.37 2008/12/09 11:01:17". Does anyone have an idea what
broke if_re for me, and how I can get back to stable operation? Is it
possible to use if_re from head as drop-in replacement to test the patches
available after 12/09? I would prefer not to move the machines completely
from -stable to -current.

Here some further information about the NICs:

---pciconf---
re0@pci0:0:9:0: class=0x020000 card=0x10ec16f3 chip=0x816710ec rev=0x10
hdr=0x00 vendor     = 'Realtek Semiconductor'
    device     = 'RTL8169/8110 Family Gigabit Ethernet NIC'
    class      = network
    subclass   = ethernet
re1@pci0:0:11:0:        class=0x020000 card=0x10ec16f3 chip=0x816710ec
rev=0x10 hdr=0x00 vendor     = 'Realtek Semiconductor'
    device     = 'RTL8169/8110 Family Gigabit Ethernet NIC'
    class      = network
    subclass   = ethernet
---


---dmesg---
re0: <RealTek 8169SC/8110SC Single-chip Gigabit Ethernet> port
0xf000-0xf0ff mem 0xfdfff000-0xfdfff0ff irq 10 at device 9.0 on pci0 re0:
Chip rev. 0x18000000 re0: MAC rev. 0x00000000
miibus0: <MII bus> on re0
rgephy0: <RTL8169S/8110S/8211B media interface> PHY 1 on miibus0
rgephy0:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT,
1000baseT-FDX, auto re0: Ethernet address: 00:30:18:ab:d0:19
re0: [FILTER]
re1: <RealTek 8169SC/8110SC Single-chip Gigabit Ethernet> port
0xf200-0xf2ff mem 0xfdffe000-0xfdffe0ff irq 10 at device 11.0 on pci0 re1:
Chip rev. 0x18000000 re1: MAC rev. 0x00000000
miibus1: <MII bus> on re1
rgephy1: <RTL8169S/8110S/8211B media interface> PHY 1 on miibus1
rgephy1:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT,
1000baseT-FDX, auto re1: Ethernet address: 00:30:18:ab:d0:1a
re1: [FILTER]
---



cu
  Gerrit
From pyunyh at gmail.com  Wed Feb  4 02:46:01 2009
From: pyunyh at gmail.com (Pyun YongHyeon)
Date: Wed Feb  4 02:46:08 2009
Subject: fun with if_re
In-Reply-To: <20090204100507.5f223d9e.gerrit@pmp.uni-hannover.de>
References: <20090204100507.5f223d9e.gerrit@pmp.uni-hannover.de>
Message-ID: <20090204104655.GA73543@michelle.cdnetworks.co.kr>

On Wed, Feb 04, 2009 at 10:05:07AM +0100, Gerrit K?hn wrote:
> Hi folks,
> 
> I have several routers here which are based on Jetway J7F4 ITX boards that
> come with two onboard re-interfaces. I run 7-stable on them via nanobsd
> and update them about once in three or four months.
> 
> After the last update (11th December 2008) I have noticed the following
> strange behaviour on at least two machines (identical hard- and software):
> After weeks of flawless operation, the network connection on both
> interfaces suddenly starts to mangle packages. Even a simple ping can show
> up to 50% or so package loss. The machine is mostly unreachable via net.
> ifconfig up/down did not cure this, turning off checksum-offloading
> and stuff did not help. Even simply rebooting the machine did not make the
> problem go away! I had to power-cycle them by unplugging all cables to get
> back to normal operation.
> 
> I have seen this behaviour on two different machines, so I can most
> probably rule out a hardware issue. It does not appear to happen often,
> though. I did not see this with an earlier image of 7-stable from June
> 2008, and probably even an image from early September was working fine
> (although I did not use that one for such a long time).
> 
> Visiting the webcvs I noticed that there are a lot of patches for if_re in
> December 2008 and January 2009. The revision I'm having problems with is
> tagged "1.95.2.37 2008/12/09 11:01:17". Does anyone have an idea what
> broke if_re for me, and how I can get back to stable operation? Is it
> possible to use if_re from head as drop-in replacement to test the patches
> available after 12/09? I would prefer not to move the machines completely
> from -stable to -current.
> 
> Here some further information about the NICs:
> 
> ---pciconf---
> re0@pci0:0:9:0: class=0x020000 card=0x10ec16f3 chip=0x816710ec rev=0x10
> hdr=0x00 vendor     = 'Realtek Semiconductor'
>     device     = 'RTL8169/8110 Family Gigabit Ethernet NIC'
>     class      = network
>     subclass   = ethernet
> re1@pci0:0:11:0:        class=0x020000 card=0x10ec16f3 chip=0x816710ec
> rev=0x10 hdr=0x00 vendor     = 'Realtek Semiconductor'
>     device     = 'RTL8169/8110 Family Gigabit Ethernet NIC'
>     class      = network
>     subclass   = ethernet
> ---
> 
> 
> ---dmesg---
> re0: <RealTek 8169SC/8110SC Single-chip Gigabit Ethernet> port
> 0xf000-0xf0ff mem 0xfdfff000-0xfdfff0ff irq 10 at device 9.0 on pci0 re0:
> Chip rev. 0x18000000 re0: MAC rev. 0x00000000
> miibus0: <MII bus> on re0
> rgephy0: <RTL8169S/8110S/8211B media interface> PHY 1 on miibus0
> rgephy0:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT,
> 1000baseT-FDX, auto re0: Ethernet address: 00:30:18:ab:d0:19
> re0: [FILTER]
> re1: <RealTek 8169SC/8110SC Single-chip Gigabit Ethernet> port
> 0xf200-0xf2ff mem 0xfdffe000-0xfdffe0ff irq 10 at device 11.0 on pci0 re1:
> Chip rev. 0x18000000 re1: MAC rev. 0x00000000
> miibus1: <MII bus> on re1
> rgephy1: <RTL8169S/8110S/8211B media interface> PHY 1 on miibus1
> rgephy1:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT,
> 1000baseT-FDX, auto re1: Ethernet address: 00:30:18:ab:d0:1a
> re1: [FILTER]
> ---
> 

Since you're using RTL8169SC it could be related with my commit
r180519(cvs rev 1.95.2.22). It seems that RTL8169SC does not like
memory mapped register access and I think jkim@ committed patch
for the issue. Would you try re(4) in HEAD?
(Just copying if_re.c, if_rlreg.h and if_rl.c from HEAD to
stable would be enough to build re(4) on stable).
From freebsd at byshenk.net  Wed Feb  4 02:52:43 2009
From: freebsd at byshenk.net (Greg Byshenk)
Date: Wed Feb  4 02:52:52 2009
Subject: X.Org/xdm 'frozen' after installworld (7-stable)
In-Reply-To: <200902031058.42788.kstewart@owt.com>
References: <539c60b90902030929r5d1ec7eu652ab11eb4165bb6@mail.gmail.com>
	<200902031058.42788.kstewart@owt.com>
Message-ID: <20090204105239.GA43683@core.byshenk.net>

On Tue, Feb 03, 2009 at 10:58:42AM -0800, Kent Stewart wrote:
> On Tuesday 03 February 2009 09:29:05 am Steve Franks wrote:

> > This is a new weird one I've never had before.  Consoles work fine,
> > but the mouse and keyboard won't move/type when xdm pops up.
> > ctrl-alt-F2 takes you right to a working console, and the mouse works
> > fine in the console...ctrl-alt-backspace no longer kills X either...
 
> The option that I found the easiest was to add
> 
>      Option "AutoAddDevices" "off"
> 
> To the ServerFlags section. I was told in the ports list that you can add it 
> to the ServerLayout section but I could never make that work.

I had the same problem yesterday after updating X.

For me, adding dbus_enable="YES" and hald_enable="YES" to rc.conf and
restarting solved the problem.


-- 
greg byshenk  -  gbyshenk@byshenk.net  -  Leiden, NL
From mah at jump-ing.de  Wed Feb  4 03:37:00 2009
From: mah at jump-ing.de (Markus Hitter)
Date: Wed Feb  4 03:37:13 2009
Subject: fun with if_re
In-Reply-To: <20090204100507.5f223d9e.gerrit@pmp.uni-hannover.de>
References: <20090204100507.5f223d9e.gerrit@pmp.uni-hannover.de>
Message-ID: <32A4E84E-8EC9-4197-91E9-F50EA60C4EF2@jump-ing.de>


Am 04.02.2009 um 10:05 schrieb Gerrit K?hn:

> After the last update (11th December 2008) I have noticed the  
> following
> strange behaviour on at least two machines (identical hard- and  
> software):
> After weeks of flawless operation, the network connection on both
> interfaces suddenly starts to mangle packages. Even a simple ping  
> can show
> up to 50% or so package loss. The machine is mostly unreachable via  
> net.
> ifconfig up/down did not cure this, turning off checksum-offloading
> and stuff did not help. Even simply rebooting the machine did not  
> make the
> problem go away! I had to power-cycle them by unplugging all cables  
> to get
> back to normal operation.

I've seen a similar, but fully reproducible behavior on this ethernet  
hardware. It turned out to be not a problem of the driver:

http://www.FreeBSD.org/cgi/query-pr.cgi?pr=kern/130957


> Is it
> possible to use if_re from head as drop-in replacement to test the  
> patches
> available after 12/09?

The other way, using an older if_re, worked by replacing sys/dev/re/ 
if_re.c, sys/pci/if_rlreg.h and sys/pci/if_rl.c, so the answer ist  
likely "yes".


MarKus

- - - - - - - - - - - - - - - - - - -
Dipl. Ing. Markus Hitter
http://www.jump-ing.de/




From mattblists at icritical.com  Wed Feb  4 05:13:05 2009
From: mattblists at icritical.com (Matt Burke)
Date: Wed Feb  4 05:13:11 2009
Subject: 7.1-RELEASE I/O hang
Message-ID: <49898E3D.7030609@icritical.com>

I have a machine with a PERC6/e controller. Attached to that are 3 disk
shelves, each configured as individual 14-disk RAID10 arrays (the PERC
annoyingly only lets you use 8 spans per array)

I can run bonnie++ on the arrays individually with no problem.
I can also run it across a gstripe of the arrays with no problem.

However running it over the 3 arrays in parallel causes something I/O
related in the kernel to hang.

To define 'hang' better:

It appears anything which needs disk io, even on a different controller
(albeit the same mfi driver), will hang. A command like 'ps' cached in
ram will work but bash hangs after execution, presumably while trying to
write ~/.bash_history

'sysctl -a' works but trying to run 'sysctl kern.msgbuf' also hangs

I've done some research and it seems the usual cause of bonnie++
crashing a system is due to overflowing TCQ. camcontrol doesn't see any
disks, so I've tried setting hw.mfi.max_cmds=32 in /boot/loader.conf but
it hadn't made any difference.

The bonnie++ invocation is this:

(newfs devices mfid[2-3], mount)
bonnie++ -s 64g -u root -p3
bonnie++ -d /data/2 -s 64g -u root -y s >b2 2>&1 &
bonnie++ -d /data/3 -s 64g -u root -y s >b3 2>&1 &
bonnie++ -d /data/4 -s 64g -u root -y s >b4 2>&1 &

and it always hangs on "Rewriting...". It's a fresh 7.1-RELEASE with
nothing else running (devd, sshd, syslogd, etc)


Any ideas?


-- 
From amarat at ksu.ru  Wed Feb  4 06:10:14 2009
From: amarat at ksu.ru (Marat N.Afanasyev)
Date: Wed Feb  4 06:10:23 2009
Subject: problem with acd udma mode
In-Reply-To: <49853547.2060105@ksu.ru>
References: <49853547.2060105@ksu.ru>
Message-ID: <4989A18D.9020804@ksu.ru>

Marat N.Afanasyev wrote:
> i cannot read or write any disk inserted in my
> 
> acd0 <PIONEER DVD-RW DVR-111D/1.29>
> 
> when this device in udma mode. kernel endlessly repeat that
> 
> acd0: setting up DMA failed
> 
> and I can access my data on dvd or cd only if I set
> 
> atacontrol mode acd0 pio4
> 
> Does anybody have such a problem too? is there any ways to bring this 
> device into udma mode again?
> 
> dmesg:
> ...
> atapci1: <ATI IXP600 UDMA133 controller> port 
> 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xff00-0xff0f at device 20.1 on pci0
> ata0: <ATA channel 0> on atapci1
> ata0: [ITHREAD]
> ...
> acd0: DVDR <PIONEER DVD-RW DVR-111D/1.29> at ata0-master UDMA66
> ...
> 
> uname -a:
> FreeBSD zealot.ksu.ru 7.1-STABLE FreeBSD 7.1-STABLE #1: Tue Jan 20 
> 05:47:24 MSK 2009     root@zealot.ksu.ru:/usr/obj/usr/src/sys/ZEALOT  amd64
> 
> grep -A 1 DMA /var/log/messages:
> Jan 27 22:12:19 zealot kernel: acd0: setting up DMA failed
> Jan 27 22:12:30 zealot last message repeated 3623 times
> -- 
> Jan 27 22:12:30 zealot kernel: acd0: setting up DMA failed
> Jan 27 22:12:33 zealot last message repeated 919 times
> -- 
> Jan 27 22:12:33 zealot kernel: acd0: setting up DMA failed
> Jan 27 22:12:45 zealot last message repeated 4021 times
> -- 
> Jan 27 22:12:45 zealot kernel: acd0: setting up DMA failed
> Jan 27 22:13:05 zealot last message repeated 6571 times
> -- 
> Jan 31 21:41:48 zealot kernel: acd0: setting up DMA failed
> Jan 31 21:42:10 zealot last message repeated 7531 times
> -- 
> Feb  1 08:24:59 zealot kernel: acd0: setting up DMA failed
> Feb  1 08:25:09 zealot last message repeated 10 times
> 

I've found a workaround:

replace /sys/dev/ata/* with files from RELENG_7_1

DMA modes work again

-- 
SY, Marat
From kostikbel at gmail.com  Wed Feb  4 07:59:59 2009
From: kostikbel at gmail.com (Kostik Belousov)
Date: Wed Feb  4 08:00:10 2009
Subject: 7.1-RELEASE I/O hang
In-Reply-To: <49898E3D.7030609@icritical.com>
References: <49898E3D.7030609@icritical.com>
Message-ID: <20090204143309.GF9427@deviant.kiev.zoral.com.ua>

On Wed, Feb 04, 2009 at 12:46:53PM +0000, Matt Burke wrote:
> I have a machine with a PERC6/e controller. Attached to that are 3 disk
> shelves, each configured as individual 14-disk RAID10 arrays (the PERC
> annoyingly only lets you use 8 spans per array)
> 
> I can run bonnie++ on the arrays individually with no problem.
> I can also run it across a gstripe of the arrays with no problem.
> 
> However running it over the 3 arrays in parallel causes something I/O
> related in the kernel to hang.
> 
> To define 'hang' better:
> 
> It appears anything which needs disk io, even on a different controller
> (albeit the same mfi driver), will hang. A command like 'ps' cached in
> ram will work but bash hangs after execution, presumably while trying to
> write ~/.bash_history
> 
> 'sysctl -a' works but trying to run 'sysctl kern.msgbuf' also hangs
> 
> I've done some research and it seems the usual cause of bonnie++
> crashing a system is due to overflowing TCQ. camcontrol doesn't see any
> disks, so I've tried setting hw.mfi.max_cmds=32 in /boot/loader.conf but
> it hadn't made any difference.
> 
> The bonnie++ invocation is this:
> 
> (newfs devices mfid[2-3], mount)
> bonnie++ -s 64g -u root -p3
> bonnie++ -d /data/2 -s 64g -u root -y s >b2 2>&1 &
> bonnie++ -d /data/3 -s 64g -u root -y s >b3 2>&1 &
> bonnie++ -d /data/4 -s 64g -u root -y s >b4 2>&1 &
> 
> and it always hangs on "Rewriting...". It's a fresh 7.1-RELEASE with
> nothing else running (devd, sshd, syslogd, etc)
> 
> 
> Any ideas?

Compile ddb into the kernel, and do "ps" from the ddb prompt. If there
are processes hung in the "nbufkv" state, then the patch below might
help.

Index: gnu/fs/xfs/FreeBSD/xfs_buf.c
===================================================================
--- gnu/fs/xfs/FreeBSD/xfs_buf.c	(revision 188080)
+++ gnu/fs/xfs/FreeBSD/xfs_buf.c	(working copy)
@@ -81,7 +81,7 @@
 {
 	struct buf *bp;
 
-	bp = geteblk(0);
+	bp = geteblk(0, 0);
 	if (bp != NULL) {
 		bp->b_bufsize = size;
 		bp->b_bcount = size;
@@ -101,7 +101,7 @@
 	if (len >= MAXPHYS)
 		return (NULL);
 
-	bp = geteblk(len);
+	bp = geteblk(len, 0);
 	if (bp != NULL) {
 		KASSERT(BUF_REFCNT(bp) == 1,
 			("xfs_buf_get_empty: bp %p not locked",bp));
Index: ufs/ffs/ffs_vfsops.c
===================================================================
--- ufs/ffs/ffs_vfsops.c	(revision 188080)
+++ ufs/ffs/ffs_vfsops.c	(working copy)
@@ -1747,7 +1747,9 @@
 		    ("bufwrite: needs chained iodone (%p)", bp->b_iodone));
 
 		/* get a new block */
-		newbp = geteblk(bp->b_bufsize);
+		newbp = geteblk(bp->b_bufsize, GB_NOWAIT_BD);
+		if (newbp == NULL)
+			goto normal_write;
 
 		/*
 		 * set it to be identical to the old block.  We have to
@@ -1787,6 +1789,7 @@
 	}
 
 	/* Let the normal bufwrite do the rest for us */
+normal_write:
 	return (bufwrite(bp));
 }
 
Index: kern/vfs_bio.c
===================================================================
--- kern/vfs_bio.c	(revision 188080)
+++ kern/vfs_bio.c	(working copy)
@@ -105,7 +105,8 @@
 static void vfs_vmio_release(struct buf *bp);
 static int vfs_bio_clcheck(struct vnode *vp, int size,
 		daddr_t lblkno, daddr_t blkno);
-static int flushbufqueues(int, int);
+static int buf_do_flush(struct vnode *vp);
+static int flushbufqueues(struct vnode *, int, int);
 static void buf_daemon(void);
 static void bremfreel(struct buf *bp);
 
@@ -258,6 +259,7 @@
 #define QUEUE_DIRTY_GIANT 3	/* B_DELWRI buffers that need giant */
 #define QUEUE_EMPTYKVA	4	/* empty buffer headers w/KVA assignment */
 #define QUEUE_EMPTY	5	/* empty buffer headers */
+#define QUEUE_SENTINEL	1024	/* not an queue index, but mark for sentinel */
 
 /* Queues for free buffers with various properties */
 static TAILQ_HEAD(bqueues, buf) bufqueues[BUFFER_QUEUES] = { { 0 } };
@@ -1703,21 +1705,23 @@
  */
 
 static struct buf *
-getnewbuf(int slpflag, int slptimeo, int size, int maxsize)
+getnewbuf(struct vnode *vp, int slpflag, int slptimeo, int size, int maxsize,
+    int gbflags)
 {
+	struct thread *td;
 	struct buf *bp;
 	struct buf *nbp;
 	int defrag = 0;
 	int nqindex;
 	static int flushingbufs;
 
+	td = curthread;
 	/*
 	 * We can't afford to block since we might be holding a vnode lock,
 	 * which may prevent system daemons from running.  We deal with
 	 * low-memory situations by proactively returning memory and running
 	 * async I/O rather then sync I/O.
 	 */
-
 	atomic_add_int(&getnewbufcalls, 1);
 	atomic_subtract_int(&getnewbufrestarts, 1);
 restart:
@@ -1949,8 +1953,9 @@
 	 */
 
 	if (bp == NULL) {
-		int flags;
+		int flags, norunbuf;
 		char *waitmsg;
+		int fl;
 
 		if (defrag) {
 			flags = VFS_BIO_NEED_BUFSPACE;
@@ -1968,9 +1973,35 @@
 		mtx_unlock(&bqlock);
 
 		bd_speedup();	/* heeeelp */
+		if (gbflags & GB_NOWAIT_BD)
+			return (NULL);
 
 		mtx_lock(&nblock);
 		while (needsbuffer & flags) {
+			if (vp != NULL && (td->td_pflags & TDP_BUFNEED) == 0) {
+				mtx_unlock(&nblock);
+				/*
+				 * getblk() is called with a vnode
+				 * locked, and some majority of the
+				 * dirty buffers may as well belong to
+				 * the vnode. Flushing the buffers
+				 * there would make a progress that
+				 * cannot be achieved by the
+				 * buf_daemon, that cannot lock the
+				 * vnode.
+				 */
+				norunbuf = ~(TDP_BUFNEED | TDP_NORUNNINGBUF) |
+				    (td->td_pflags & TDP_NORUNNINGBUF);
+				/* play bufdaemon */
+				td->td_pflags |= TDP_BUFNEED | TDP_NORUNNINGBUF;
+				fl = buf_do_flush(vp);
+				td->td_pflags &= norunbuf;
+				mtx_lock(&nblock);
+				if (fl != 0)
+					continue;
+				if ((needsbuffer & flags) == 0)
+					break;
+			}
 			if (msleep(&needsbuffer, &nblock,
 			    (PRIBIO + 4) | slpflag, waitmsg, slptimeo)) {
 				mtx_unlock(&nblock);
@@ -2039,6 +2070,35 @@
 };
 SYSINIT(bufdaemon, SI_SUB_KTHREAD_BUF, SI_ORDER_FIRST, kproc_start, &buf_kp);
 
+static int
+buf_do_flush(struct vnode *vp)
+{
+	int flushed;
+
+	flushed = flushbufqueues(vp, QUEUE_DIRTY, 0);
+	/* The list empty check here is slightly racy */
+	if (!TAILQ_EMPTY(&bufqueues[QUEUE_DIRTY_GIANT])) {
+		mtx_lock(&Giant);
+		flushed += flushbufqueues(vp, QUEUE_DIRTY_GIANT, 0);
+		mtx_unlock(&Giant);
+	}
+	if (flushed == 0) {
+		/*
+		 * Could not find any buffers without rollback
+		 * dependencies, so just write the first one
+		 * in the hopes of eventually making progress.
+		 */
+		flushbufqueues(vp, QUEUE_DIRTY, 1);
+		if (!TAILQ_EMPTY(
+			    &bufqueues[QUEUE_DIRTY_GIANT])) {
+			mtx_lock(&Giant);
+			flushbufqueues(vp, QUEUE_DIRTY_GIANT, 1);
+			mtx_unlock(&Giant);
+		}
+	}
+	return (flushed);
+}
+
 static void
 buf_daemon()
 {
@@ -2052,7 +2112,7 @@
 	/*
 	 * This process is allowed to take the buffer cache to the limit
 	 */
-	curthread->td_pflags |= TDP_NORUNNINGBUF;
+	curthread->td_pflags |= TDP_NORUNNINGBUF | TDP_BUFNEED;
 	mtx_lock(&bdlock);
 	for (;;) {
 		bd_request = 0;
@@ -2067,30 +2127,8 @@
 		 * normally would so they can run in parallel with our drain.
 		 */
 		while (numdirtybuffers > lodirtybuffers) {
-			int flushed;
-
-			flushed = flushbufqueues(QUEUE_DIRTY, 0);
-			/* The list empty check here is slightly racy */
-			if (!TAILQ_EMPTY(&bufqueues[QUEUE_DIRTY_GIANT])) {
-				mtx_lock(&Giant);
-				flushed += flushbufqueues(QUEUE_DIRTY_GIANT, 0);
-				mtx_unlock(&Giant);
-			}
-			if (flushed == 0) {
-				/*
-				 * Could not find any buffers without rollback
-				 * dependencies, so just write the first one
-				 * in the hopes of eventually making progress.
-				 */
-				flushbufqueues(QUEUE_DIRTY, 1);
-				if (!TAILQ_EMPTY(
-				    &bufqueues[QUEUE_DIRTY_GIANT])) {
-					mtx_lock(&Giant);
-					flushbufqueues(QUEUE_DIRTY_GIANT, 1);
-					mtx_unlock(&Giant);
-				}
+			if (buf_do_flush(NULL) == 0)
 				break;
-			}
 			uio_yield();
 		}
 
@@ -2136,7 +2174,7 @@
     0, "Number of buffers flushed with dependecies that require rollbacks");
 
 static int
-flushbufqueues(int queue, int flushdeps)
+flushbufqueues(struct vnode *lvp, int queue, int flushdeps)
 {
 	struct thread *td = curthread;
 	struct buf sentinel;
@@ -2147,20 +2185,37 @@
 	int flushed;
 	int target;
 
-	target = numdirtybuffers - lodirtybuffers;
-	if (flushdeps && target > 2)
-		target /= 2;
+	if (lvp == NULL) {
+		target = numdirtybuffers - lodirtybuffers;
+		if (flushdeps && target > 2)
+			target /= 2;
+	} else
+		target = 1;
 	flushed = 0;
 	bp = NULL;
+	sentinel.b_qindex = QUEUE_SENTINEL;
 	mtx_lock(&bqlock);
-	TAILQ_INSERT_TAIL(&bufqueues[queue], &sentinel, b_freelist);
+	TAILQ_INSERT_HEAD(&bufqueues[queue], &sentinel, b_freelist);
 	while (flushed != target) {
-		bp = TAILQ_FIRST(&bufqueues[queue]);
-		if (bp == &sentinel)
+		bp = TAILQ_NEXT(&sentinel, b_freelist);
+		if (bp != NULL) {
+			TAILQ_REMOVE(&bufqueues[queue], &sentinel, b_freelist);
+			TAILQ_INSERT_AFTER(&bufqueues[queue], bp, &sentinel,
+			    b_freelist);
+		} else
 			break;
-		TAILQ_REMOVE(&bufqueues[queue], bp, b_freelist);
-		TAILQ_INSERT_TAIL(&bufqueues[queue], bp, b_freelist);
-
+		/*
+		 * Skip sentinels inserted by other invocations of the
+		 * flushbufqueues(), taking care to not reorder them.
+		 */
+		if (bp->b_qindex == QUEUE_SENTINEL)
+			continue;
+		/*
+		 * Only flush the buffers that belong to the
+		 * vnode locked by the curthread.
+		 */
+		if (lvp != NULL && bp->b_vp != lvp)
+			continue;
 		if (BUF_LOCK(bp, LK_EXCLUSIVE | LK_NOWAIT, NULL) != 0)
 			continue;
 		if (bp->b_pin_count > 0) {
@@ -2208,16 +2263,28 @@
 			BUF_UNLOCK(bp);
 			continue;
 		}
-		if (vn_lock(vp, LK_EXCLUSIVE | LK_NOWAIT, td) == 0) {
+		if (vn_lock(vp, LK_EXCLUSIVE | LK_NOWAIT | LK_CANRECURSE, td)
+		    == 0) {
 			mtx_unlock(&bqlock);
 			CTR3(KTR_BUF, "flushbufqueue(%p) vp %p flags %X",
 			    bp, bp->b_vp, bp->b_flags);
-			vfs_bio_awrite(bp);
+			if (curproc == bufdaemonproc)
+				vfs_bio_awrite(bp);
+			else {
+				bremfree(bp);
+				bwrite(bp);
+			}
 			vn_finished_write(mp);
 			VOP_UNLOCK(vp, 0, td);
 			flushwithdeps += hasdeps;
 			flushed++;
-			waitrunningbufspace();
+
+			/*
+			 * Sleeping on runningbufspace while holding
+			 * vnode lock leads to deadlock.
+			 */
+			if (curproc == bufdaemonproc)
+				waitrunningbufspace();
 			numdirtywakeup((lodirtybuffers + hidirtybuffers) / 2);
 			mtx_lock(&bqlock);
 			continue;
@@ -2599,7 +2666,7 @@
 		maxsize = vmio ? size + (offset & PAGE_MASK) : size;
 		maxsize = imax(maxsize, bsize);
 
-		bp = getnewbuf(slpflag, slptimeo, size, maxsize);
+		bp = getnewbuf(vp, slpflag, slptimeo, size, maxsize, flags);
 		if (bp == NULL) {
 			if (slpflag || slptimeo)
 				return NULL;
@@ -2674,14 +2741,17 @@
  * set to B_INVAL.
  */
 struct buf *
-geteblk(int size)
+geteblk(int size, int flags)
 {
 	struct buf *bp;
 	int maxsize;
 
 	maxsize = (size + BKVAMASK) & ~BKVAMASK;
-	while ((bp = getnewbuf(0, 0, size, maxsize)) == 0)
-		continue;
+	while ((bp = getnewbuf(NULL, 0, 0, size, maxsize, flags)) == NULL) {
+		if ((flags & GB_NOWAIT_BD) &&
+		    (curthread->td_pflags & TDP_BUFNEED) != 0)
+			return (NULL);
+	}
 	allocbuf(bp, size);
 	bp->b_flags |= B_INVAL;	/* b_dep cleared by getnewbuf() */
 	KASSERT(BUF_REFCNT(bp) == 1, ("geteblk: bp %p not locked",bp));
Index: sys/proc.h
===================================================================
--- sys/proc.h	(revision 188080)
+++ sys/proc.h	(working copy)
@@ -378,6 +378,7 @@
 #define	TDP_NORUNNINGBUF 0x00040000 /* Ignore runningbufspace check */
 #define	TDP_WAKEUP	0x00080000 /* Don't sleep in umtx cond_wait */
 #define	TDP_INBDFLUSH	0x00100000 /* Already in BO_BDFLUSH, do not recurse */
+#define	TDP_BUFNEED	0x00200000 /* Do not recurse into the buf flush */
 
 /*
  * Reasons that the current thread can not be run yet.
Index: sys/buf.h
===================================================================
--- sys/buf.h	(revision 188080)
+++ sys/buf.h	(working copy)
@@ -475,6 +475,7 @@
  */
 #define	GB_LOCK_NOWAIT	0x0001		/* Fail if we block on a buf lock. */
 #define	GB_NOCREAT	0x0002		/* Don't create a buf if not found. */
+#define	GB_NOWAIT_BD	0x0004		/* Do not wait for bufdaemon */
 
 #ifdef _KERNEL
 extern int	nbuf;			/* The number of buffer headers */
@@ -519,7 +520,7 @@
 struct buf *incore(struct bufobj *, daddr_t);
 struct buf *gbincore(struct bufobj *, daddr_t);
 struct buf *getblk(struct vnode *, daddr_t, int, int, int, int);
-struct buf *geteblk(int);
+struct buf *geteblk(int, int);
 int	bufwait(struct buf *);
 int	bufwrite(struct buf *);
 void	bufdone(struct buf *);
-------------- 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/20090204/8c5aff42/attachment.pgp
From freebsd at max.af.czu.cz.cz  Wed Feb  4 08:35:43 2009
From: freebsd at max.af.czu.cz.cz (Tomas Randa)
Date: Wed Feb  4 08:35:51 2009
Subject: Free memory after upgrade to 7.1
Message-ID: <4989BD92.9010506@max.af.czu.cz.cz>

Hello,

I have i386/PAE system (php, apache22, mysql) running on 7-STABLE and I 
can see strange behavior after upgrade from 7.0: Apache does not free 
memory, for example:

CPU: 31.2% user, 0.0% nice, 12.8% system, 0.7% interrupt, 55.3% idle
Mem: 3520M Active, 3705M Inact, 465M Wired, 314M Cache, 112M Buf, 12M Free
Swap: 4096M Total, 105M Used, 3991M Free, 2% Inuse

then apachectl graceful

CPU: 28.3% user, 0.0% nice, 8.6% system, 0.0% interrupt, 63.1% idle
Mem: 631M Active, 3126M Inact, 353M Wired, 213M Cache, 112M Buf, 3693M Free
Swap: 4096M Total, 1844K Used, 4094M Free

Some graph: http://max.af.czu.cz/memoryload.png

I know before upgrade was memory using about 2,5GB, now much more, 
apache sometimes crash.

Thanks for some help

Tomas Randa
From tevans.uk at googlemail.com  Wed Feb  4 09:21:08 2009
From: tevans.uk at googlemail.com (Tom Evans)
Date: Wed Feb  4 09:21:14 2009
Subject: Free memory after upgrade to 7.1
In-Reply-To: <4989BD92.9010506@max.af.czu.cz.cz>
References: <4989BD92.9010506@max.af.czu.cz.cz>
Message-ID: <1233766887.43076.18.camel@strangepork.mintel.co.uk>

On Wed, 2009-02-04 at 17:08 +0100, Tomas Randa wrote:
> Hello,
> 
> I have i386/PAE system (php, apache22, mysql) running on 7-STABLE and I 
> can see strange behavior after upgrade from 7.0: Apache does not free 
> memory, for example:
> 
> CPU: 31.2% user, 0.0% nice, 12.8% system, 0.7% interrupt, 55.3% idle
> Mem: 3520M Active, 3705M Inact, 465M Wired, 314M Cache, 112M Buf, 12M Free
> Swap: 4096M Total, 105M Used, 3991M Free, 2% Inuse
> 
> then apachectl graceful
> 
> CPU: 28.3% user, 0.0% nice, 8.6% system, 0.0% interrupt, 63.1% idle
> Mem: 631M Active, 3126M Inact, 353M Wired, 213M Cache, 112M Buf, 3693M Free
> Swap: 4096M Total, 1844K Used, 4094M Free
> 
> Some graph: http://max.af.czu.cz/memoryload.png
> 
> I know before upgrade was memory using about 2,5GB, now much more, 
> apache sometimes crash.
> 
> Thanks for some help
> 
> Tomas Randa

What is apache doing to use so much memory? This looks more like a
memory leak in PHP, which is reclaimed after apache restarts its
children.

When you upgraded the OS, did you also upgrade ports? Could a new
version of PHP be at fault here?

Cheers

Tom

From freebsd at max.af.czu.cz.cz  Wed Feb  4 09:42:35 2009
From: freebsd at max.af.czu.cz.cz (Tomas Randa)
Date: Wed Feb  4 09:42:42 2009
Subject: Free memory after upgrade to 7.1
In-Reply-To: <1233766887.43076.18.camel@strangepork.mintel.co.uk>
References: <4989BD92.9010506@max.af.czu.cz.cz>
	<1233766887.43076.18.camel@strangepork.mintel.co.uk>
Message-ID: <4989D384.7090301@max.af.czu.cz.cz>

Yes, I do portupgrade -Rrfia after upgrade of course.
I don`t think it is some "new" PHP bug, because my friend have same 
problem with memory and he do not upgraded ports. But his box do not 
free memory after apache reload, my yes

Any other suggestions ?

Thanks TR



Tom Evans napsal(a):
> On Wed, 2009-02-04 at 17:08 +0100, Tomas Randa wrote:
>   
>> Hello,
>>
>> I have i386/PAE system (php, apache22, mysql) running on 7-STABLE and I 
>> can see strange behavior after upgrade from 7.0: Apache does not free 
>> memory, for example:
>>
>> CPU: 31.2% user, 0.0% nice, 12.8% system, 0.7% interrupt, 55.3% idle
>> Mem: 3520M Active, 3705M Inact, 465M Wired, 314M Cache, 112M Buf, 12M Free
>> Swap: 4096M Total, 105M Used, 3991M Free, 2% Inuse
>>
>> then apachectl graceful
>>
>> CPU: 28.3% user, 0.0% nice, 8.6% system, 0.0% interrupt, 63.1% idle
>> Mem: 631M Active, 3126M Inact, 353M Wired, 213M Cache, 112M Buf, 3693M Free
>> Swap: 4096M Total, 1844K Used, 4094M Free
>>
>> Some graph: http://max.af.czu.cz/memoryload.png
>>
>> I know before upgrade was memory using about 2,5GB, now much more, 
>> apache sometimes crash.
>>
>> Thanks for some help
>>
>> Tomas Randa
>>     
>
> What is apache doing to use so much memory? This looks more like a
> memory leak in PHP, which is reclaimed after apache restarts its
> children.
>
> When you upgraded the OS, did you also upgrade ports? Could a new
> version of PHP be at fault here?
>
> Cheers
>
> Tom
>
> _______________________________________________
> 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 henrik at 50hz.ws  Wed Feb  4 10:05:37 2009
From: henrik at 50hz.ws (Henrik Friedrichsen)
Date: Wed Feb  4 10:05:44 2009
Subject: fun with if_re
In-Reply-To: <20090204100507.5f223d9e.gerrit@pmp.uni-hannover.de>
References: <20090204100507.5f223d9e.gerrit@pmp.uni-hannover.de>
Message-ID: <20090204173753.GA98288@dsp.50hz.ws>

Hey.

I have had similar symptoms on a dedicated server with the re driver.
What I did was grab more recent drivers (which might be redundant now)
and disable a set of features that weren't stable at the time.
Please have a look at this PR that I submitted back then:

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

On Wed, Feb 04, 2009 at 10:05:07AM +0100, Gerrit K?hn wrote:
> Hi folks,
> 
> I have several routers here which are based on Jetway J7F4 ITX boards that
> come with two onboard re-interfaces. I run 7-stable on them via nanobsd
> and update them about once in three or four months.
> 
> After the last update (11th December 2008) I have noticed the following
> strange behaviour on at least two machines (identical hard- and software):
> After weeks of flawless operation, the network connection on both
> interfaces suddenly starts to mangle packages. Even a simple ping can show
> up to 50% or so package loss. The machine is mostly unreachable via net.
> ifconfig up/down did not cure this, turning off checksum-offloading
> and stuff did not help. Even simply rebooting the machine did not make the
> problem go away! I had to power-cycle them by unplugging all cables to get
> back to normal operation.
> 
> I have seen this behaviour on two different machines, so I can most
> probably rule out a hardware issue. It does not appear to happen often,
> though. I did not see this with an earlier image of 7-stable from June
> 2008, and probably even an image from early September was working fine
> (although I did not use that one for such a long time).
> 
> Visiting the webcvs I noticed that there are a lot of patches for if_re in
> December 2008 and January 2009. The revision I'm having problems with is
> tagged "1.95.2.37 2008/12/09 11:01:17". Does anyone have an idea what
> broke if_re for me, and how I can get back to stable operation? Is it
> possible to use if_re from head as drop-in replacement to test the patches
> available after 12/09? I would prefer not to move the machines completely
> from -stable to -current.
> 
> Here some further information about the NICs:
> 
> ---pciconf---
> re0@pci0:0:9:0: class=0x020000 card=0x10ec16f3 chip=0x816710ec rev=0x10
> hdr=0x00 vendor     = 'Realtek Semiconductor'
>     device     = 'RTL8169/8110 Family Gigabit Ethernet NIC'
>     class      = network
>     subclass   = ethernet
> re1@pci0:0:11:0:        class=0x020000 card=0x10ec16f3 chip=0x816710ec
> rev=0x10 hdr=0x00 vendor     = 'Realtek Semiconductor'
>     device     = 'RTL8169/8110 Family Gigabit Ethernet NIC'
>     class      = network
>     subclass   = ethernet
> ---
> 
> 
> ---dmesg---
> re0: <RealTek 8169SC/8110SC Single-chip Gigabit Ethernet> port
> 0xf000-0xf0ff mem 0xfdfff000-0xfdfff0ff irq 10 at device 9.0 on pci0 re0:
> Chip rev. 0x18000000 re0: MAC rev. 0x00000000
> miibus0: <MII bus> on re0
> rgephy0: <RTL8169S/8110S/8211B media interface> PHY 1 on miibus0
> rgephy0:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT,
> 1000baseT-FDX, auto re0: Ethernet address: 00:30:18:ab:d0:19
> re0: [FILTER]
> re1: <RealTek 8169SC/8110SC Single-chip Gigabit Ethernet> port
> 0xf200-0xf2ff mem 0xfdffe000-0xfdffe0ff irq 10 at device 11.0 on pci0 re1:
> Chip rev. 0x18000000 re1: MAC rev. 0x00000000
> miibus1: <MII bus> on re1
> rgephy1: <RTL8169S/8110S/8211B media interface> PHY 1 on miibus1
> rgephy1:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT,
> 1000baseT-FDX, auto re1: Ethernet address: 00:30:18:ab:d0:1a
> re1: [FILTER]
> ---
> 
> 
> 
> cu
>   Gerrit
> _______________________________________________
> 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 mamalos at eng.auth.gr  Wed Feb  4 10:38:29 2009
From: mamalos at eng.auth.gr (George Mamalakis)
Date: Wed Feb  4 10:38:38 2009
Subject: FREEBSD 7.1-STABLE crashes when trying to mount USB device of
 solaris UFS filesystem
Message-ID: <4989DCA8.1050200@eng.auth.gr>

Hi everybody,

today I met the following problems on my freebsd box. I had a USB stick 
of opensolaris bootable USB image and tried to mount it on my fbsd box. 
The first time, when I tried to mount the usb device, my system freezed 
and then rebooted giving me one core in my dumpdev. When I tried to redo 
the mounting, the kernel informed me that the filesystem needed to be 
fsck'd before mounted, or else I should have tried to mount it ro. When 
I tried to mount it with the read-only option set, the kernel panicked 
once more, and another core was dumped on my dumpdev.

Recently, I keep having problems with USB disks. For instance, yesterday 
night I left an msdosfs USB partition mounted on my pc. This morning, 
the first thing I did was to check my emails through Thunderbird. When I 
clicked on the first unread message, everything freezed. There was no 
keyboard or mouse interaction whatsoever (both USB devices), and I had 
to shutdown my box via the shutdown button (hence and no core dumped, 
unfortunately). Another time, my kernel panicked exactly when I 
connected my USB external disk to my box while the kernel was loading.

Since my box crashed thrice today (once due to the 
since-yesterday-mounted-msdosfs filesystem, and twice due to the 
opensolaris ufs filesystem) I decided to send you this bug report; so 
here is the thing:

1)
# uname -a

FreeBSD myhost 7.1-STABLE FreeBSD 7.1-STABLE #0: Thu Jan 15 21:47:42 EET 
2009     root@myhost:/usr/obj/usr/src/sys/KERNEL  i386

2) My differences from GENERIC are:
cpu             I686_CPU               # only i686 support


options         SCHED_ULE         # I think now it's the default
options         QUOTA
options         MAC
options         AUDIT

options         KDTRACE_HOOKS
options         DDB_CTF
options         SMP
device          apic

device          pf
device          pflog
device          pfsync

device          atapicam
options         VESA


3) And my three core dumps are:

------------------------------------------------------------------------------------
vmcore.2:  MAY be the core created when I plugged  in the USB  disk 
while the kernel was loading (sorry guys, not sure, hadn't payed too 
much attention at that moment, and don't remember if this is the correct 
dump):
------------------------------------------------------------------------------------

# kgdb  kernel.debug 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 "i386-marcel-freebsd"...

warning: kld_current_sos: Can't read filename: Input/output error

#0  0x00000000 in ?? ()
(kgdb)


------------------------------------------------------------------------------------
vmcore.3 is the first core created when I tried to mount opensolaris ufs 
for the first time (without using mount -o ro)
------------------------------------------------------------------------------------

# kgdb  kernel.debug vmcore.3
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: vm_fault: fault on nofault entry, addr: e9dee000
cpuid = 0
Uptime: 7h13m53s
Physical memory: 2026 MB
Dumping 224 MB: 209 193 177 (CTRL-C to abort)  161 (CTRL-C to abort)  
145 129 113 97 81 65 49 33 17 1

Reading symbols from /boot/kernel/linux.ko...Reading symbols from 
/boot/kernel/linux.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/linux.ko
Reading symbols from /boot/kernel/snd_hda.ko...Reading symbols from 
/boot/kernel/snd_hda.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/snd_hda.ko
Reading symbols from /boot/kernel/sound.ko...Reading symbols from 
/boot/kernel/sound.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/sound.ko
Reading symbols from /boot/modules/nvidia.ko...done.
Loaded symbols for /boot/modules/nvidia.ko
Reading symbols from /boot/kernel/if_wpi.ko...Reading symbols from 
/boot/kernel/if_wpi.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/if_wpi.ko
Reading symbols from /boot/kernel/wpifw.ko...Reading symbols from 
/boot/kernel/wpifw.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/wpifw.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/msdosfs_iconv.ko...Reading symbols 
from /boot/kernel/msdosfs_iconv.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/msdosfs_iconv.ko
Reading symbols from /boot/kernel/libiconv.ko...Reading symbols from 
/boot/kernel/libiconv.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/libiconv.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/nullfs.ko...Reading symbols from 
/boot/kernel/nullfs.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/nullfs.ko
Reading symbols from /boot/kernel/if_vlan.ko...Reading symbols from 
/boot/kernel/if_vlan.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/if_vlan.ko
Reading symbols from /usr/local/modules/fuse.ko...done.
Loaded symbols for /usr/local/modules/fuse.ko
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
Reading symbols from /usr/local/modules/rtc.ko...done.
Loaded symbols for /usr/local/modules/rtc.ko
#0  doadump () at pcpu.h:196
196    pcpu.h: No such file or directory.
    in pcpu.h
(kgdb) bt
#0  doadump () at pcpu.h:196
#1  0xc07b61d7 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:418
#2  0xc07b64c9 in panic (fmt=Variable "fmt" is not available.
) at /usr/src/sys/kern/kern_shutdown.c:574
#3  0xc09ec1e8 in vm_fault (map=0xc1c71000, vaddr=3923697664, 
fault_type=1 '\001', fault_flags=0)
    at /usr/src/sys/vm/vm_fault.c:275
#4  0xc0a7a5ce in trap_pfault (frame=0xf4ed6870, usermode=0, 
eva=3923697668) at /usr/src/sys/i386/i386/trap.c:841
#5  0xc0a7b052 in trap (frame=0xf4ed6870) at 
/usr/src/sys/i386/i386/trap.c:530
#6  0xc0a6184b in calltrap () at /usr/src/sys/i386/i386/exception.s:159
#7  0xc09d82db in ufs_lookup (ap=0xf4ed6970) at 
/usr/src/sys/ufs/ufs/ufs_lookup.c:291
#8  0xc0a90c82 in VOP_CACHEDLOOKUP_APV (vop=0xc0bec0c0, a=0xf4ed6970) at 
vnode_if.c:153
#9  0xc0825b00 in vfs_cache_lookup (ap=0xf4ed69f4) at vnode_if.h:83
#10 0xc0a92956 in VOP_LOOKUP_APV (vop=0xc0bec7a0, a=0xf4ed69f4) at 
vnode_if.c:99
#11 0xc082c4a1 in lookup (ndp=0xf4ed6bd0) at vnode_if.h:57
#12 0xc082d1af in namei (ndp=0xf4ed6bd0) at 
/usr/src/sys/kern/vfs_lookup.c:219
#13 0xc082ff7e in vfs_donmount (td=0xc5fc2af0, fsflags=69632, 
fsoptions=0xc7388800) at /usr/src/sys/kern/vfs_mount.c:899
#14 0xc0831b7e in nmount (td=0xc5fc2af0, uap=0xf4ed6cfc) at 
/usr/src/sys/kern/vfs_mount.c:415
#15 0xc0a7a9b6 in syscall (frame=0xf4ed6d38) at 
/usr/src/sys/i386/i386/trap.c:1090
#16 0xc0a618e0 in Xint0x80_syscall () at 
/usr/src/sys/i386/i386/exception.s:255
#17 0x00000033 in ?? ()
Previous frame inner to this frame (corrupt stack?)
(kgdb)


------------------------------------------------------------------------------------
And vmcore.4 was created after I tried to mount the same filesystem with 
the ro option set:
------------------------------------------------------------------------------------


kgdb  kernel.debug vmcore.4
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:
WARNING: /mnt was not properly dismounted
panic: vm_fault: fault on nofault entry, addr: eae5e000
cpuid = 0
Uptime: 2m51s
Physical memory: 2026 MB
Dumping 188 MB: 173 157 (CTRL-C to abort)  141 (CTRL-C to abort)  
(CTRL-C to abort)  125 (CTRL-C to abort)  (CTRL-C to abort)  (CTRL-C to 
abort)  109 (CTRL-C to abort)  93 77 61 45 29 13

Reading symbols from /boot/kernel/linux.ko...Reading symbols from 
/boot/kernel/linux.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/linux.ko
Reading symbols from /boot/kernel/snd_hda.ko...Reading symbols from 
/boot/kernel/snd_hda.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/snd_hda.ko
Reading symbols from /boot/kernel/sound.ko...Reading symbols from 
/boot/kernel/sound.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/sound.ko
Reading symbols from /boot/modules/nvidia.ko...done.
Loaded symbols for /boot/modules/nvidia.ko
Reading symbols from /boot/kernel/if_wpi.ko...Reading symbols from 
/boot/kernel/if_wpi.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/if_wpi.ko
Reading symbols from /boot/kernel/wpifw.ko...Reading symbols from 
/boot/kernel/wpifw.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/wpifw.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/msdosfs_iconv.ko...Reading symbols 
from /boot/kernel/msdosfs_iconv.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/msdosfs_iconv.ko
Reading symbols from /boot/kernel/libiconv.ko...Reading symbols from 
/boot/kernel/libiconv.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/libiconv.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/nullfs.ko...Reading symbols from 
/boot/kernel/nullfs.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/nullfs.ko
Reading symbols from /boot/kernel/if_vlan.ko...Reading symbols from 
/boot/kernel/if_vlan.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/if_vlan.ko
Reading symbols from /usr/local/modules/fuse.ko...done.
Loaded symbols for /usr/local/modules/fuse.ko
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
Reading symbols from /usr/local/modules/rtc.ko...done.
Loaded symbols for /usr/local/modules/rtc.ko
#0  doadump () at pcpu.h:196
196    pcpu.h: No such file or directory.
    in pcpu.h
(kgdb)


I will csup my box to the latest freebsd-stable and see if the problems 
persist. If not, I hope this message will help somebody to find some 
solution.

Thank you all for your help in advance,
regards,

George Mamalakis

-- 
George Mamalakis

IT Officer
Electrical and Computer Engineer (Aristotle Un. of Thessaloniki),
MSc (Imperial College of London)

Department of Electrical and Computer Engineering
Faculty of Engineering
Aristotle University of Thessaloniki

phone number : +30 (2310) 994379

From ivoras at freebsd.org  Wed Feb  4 15:33:18 2009
From: ivoras at freebsd.org (Ivan Voras)
Date: Wed Feb  4 15:33:26 2009
Subject: Free memory after upgrade to 7.1
In-Reply-To: <4989BD92.9010506@max.af.czu.cz.cz>
References: <4989BD92.9010506@max.af.czu.cz.cz>
Message-ID: <gmd8jg$a0n$1@ger.gmane.org>

Tomas Randa wrote:
> Hello,
> 
> I have i386/PAE system (php, apache22, mysql) running on 7-STABLE and I
> can see strange behavior after upgrade from 7.0: Apache does not free
> memory, for example:
> 
> CPU: 31.2% user, 0.0% nice, 12.8% system, 0.7% interrupt, 55.3% idle
> Mem: 3520M Active, 3705M Inact, 465M Wired, 314M Cache, 112M Buf, 12M Free
> Swap: 4096M Total, 105M Used, 3991M Free, 2% Inuse
> 
> then apachectl graceful
> 
> CPU: 28.3% user, 0.0% nice, 8.6% system, 0.0% interrupt, 63.1% idle
> Mem: 631M Active, 3126M Inact, 353M Wired, 213M Cache, 112M Buf, 3693M Free
> Swap: 4096M Total, 1844K Used, 4094M Free
> 
> Some graph: http://max.af.czu.cz/memoryload.png

Please interpret this graph. When did you upgrade FreeBSD? On the 27th?

What are the dips on the 30th and 2nd? Apache restarts?

> I know before upgrade was memory using about 2,5GB, now much more,
> apache sometimes crash.

Please post several lines from "top" describing the processes you think
are using up memory.

For what it's worth, I have a similar situation: i386/PAE, upgraded from
7.0 to 7.1 on a machine with 4 GB RAM (3 GB accessible without PAE). I
see no anomalies, *but* I'm using FastCGI with PHP and apache22-worker.

I think this is the major change in malloc between 7.0 and 7.1:
http://svn.freebsd.org/viewvc/base?view=revision&revision=184602

You can test if it's the cause of your problem by toggling between 'D'
and 'M' options to malloc.conf (see malloc(3), don't forget to restart
apache).

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 258 bytes
Desc: OpenPGP digital signature
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20090204/418cb200/signature.pgp
From pyunyh at gmail.com  Wed Feb  4 17:08:29 2009
From: pyunyh at gmail.com (Pyun YongHyeon)
Date: Wed Feb  4 17:08:36 2009
Subject: Can't get if_txp(4) to attach to a 3CR990B-TXM NIC
In-Reply-To: <200706080913.37450.fjwcash+freebsd@gmail.com>
References: <200706080913.37450.fjwcash+freebsd@gmail.com>
Message-ID: <20090205010930.GB77461@michelle.cdnetworks.co.kr>

On Fri, Jun 08, 2007 at 09:13:37AM -0700, Freddie Cash wrote:
> Good morning,
> 
> I'm having a bit of an issue getting a 3CR990B-TXM NIC detected and 
> usable.  Just wondering if anyone knows of any issues with this NIC 
> chipset and/or with the motherboard chipset.
> 
> The motherboard is a Biostar GeForce 6100 AM2 using an nVidia nForce 410 
> chipset and nVidia GeForce 6100 vide chipset.
> 
> I've tried FreeBSD 6.1, 6.2, 6-STABLE (from Wed), and 7-CURRENT (from Thu) 
> on this system.  Everything installs nicely, everything on the board is 
> detected correctly and usable.  It's just the PCI NIC that doesn't work.
> 
> If I compile a custom kernel without any network drivers in it, and then 
> kldload if_txp, the following appears (same message on all 4 versions):
> 
> txp0: <3Com 3cR990B-TXM Etherlink with 3XP Processor> port 0xbc00-0xbc7f 
> mem 0xfdcff000-0xfdcff07f irq 16 at device 8.0 on pci3
> txp0: not waiting for boot
> device_attach: txp0 attach returned -1
> 
> If I reboot and load if_nve (on 6.2 and 6-stable), then I get:
> nve0: <NVIDIA nForce MCP13 Networking Adapter> port 0xdc00-0xdc07 mem 
> 0xfe02d000-0xfe02dfff irq 22 at device 20.0 on pci0
> nve0: Ethernet address 00:19:21:37:d5:60
> 
> Followed by the above messages for txp0 (it seems to detect and load 
> if_txp automativally when loading if_nve).
> 
> I've updated the BIOS on the motherboard.  I've tried different PCI slots 
> on the motherboard.  Nothing changes.  The "not waiting for boot" message 
> keeps appearing.
> 
> Attached are dmesg output from:
>   6.1-RELEASE  GENERIC kernel                dmesg_6.1.txt
>   6.2-RELEASE  GENERIC kernel                dmesg_6.2.txt
>   6.2-RELEASE  GENERIC kernel  verbose boot  dmesg_6.2_verbose.txt
>   6-STABLE     GENERIC kernel                dmesg_6_generic.txt
>   6-STABLE     TEST kernel (no NIC drivers)  dmesg_6_custom.txt
>   7-CURRENT    GENERIC kernel                dmesg_7_generic.txt
>   7-CURRENT    TEST kernel (no NIC drivers)  dmesg_7_custom.txt
> 
> I've looked through the cvsweb entries for txp and didn't see anything 
> related to this issue.  Reading the man page for if_txp(4) doesn't show 
> anything about this error.  I tried reading the source, but C is pretty 
> much Greek to me.
> 
> Everything I've read online says this NIC should work, and other are using 
> it successfully.  My gut feeling is that it's something to do with the 
> motherboard chipset and the way it detects the NIC.  But I could be way 
> off.
> 
> (As a test, I popped in a Kanotix LiveCD and the 3Com NIC is detected and 
> usable, so it's [hopefully] not a defective NIC.)
> 
> Anyone have any suggestions?  Comments?  Methods to destroy the NIC as an 
> act of defiance?  :)
> 

Now I've encountered similar issue. See
http://lists.freebsd.org/pipermail/freebsd-current/2009-February/003033.html
for possible fix.
From daryl at isletech.net  Wed Feb  4 17:26:33 2009
From: daryl at isletech.net (Daryl Richards)
Date: Wed Feb  4 17:26:39 2009
Subject: FreeBSD 7.1 on MacBook Pro: sysinstall keyboard problems
In-Reply-To: <4987ECAC.2040202@kasimir.com>
References: <d86b48730902021237r5520cceyc36b705b05506702@mail.gmail.com>
	<4987ECAC.2040202@kasimir.com>
Message-ID: <6CC76534-3D44-4409-A3EF-19AFC21D3BE6@isletech.net>

I get the same effect, but with completely different hardware. This is  
on an AMD desktop system, with a Logitech wireless keyboard plugged in  
via USB. I don't have X installed, only trying to use it at the console.

On 3-Feb-09, at 2:05 AM, Florian Smeets wrote:

> On 02.02.2009 21:37 Uhr, Arjan van Leeuwen wrote:
>> Hi,
>>
>> I'm trying to install FreeBSD 7.1-RELEASE/i386 on a MacBook Pro  
>> (October
>> 2008 model) with a US international keyboard.
>>
>> The DVD boots fine, but once I get into sysinstall, it's like the  
>> Ctrl key
>> is stuck. Whenever I type 'C' it actually does Ctrl+C (and exits the
>> install), and I can't even get a dmesg from fixit because 'D' acts  
>> like
>> Ctrl+D and logs me out. Has anyone seen this before, any ideas on  
>> how to fix
>> this?
>>
>
> Yes, I've seen this. It's the same in recent HEAD (both with old USB  
> and USB2). This started to happen with the MacBook Pros 4,1.
>
> The keyboard does work in X but not on the console. (i installed  
> using a USB keyboard).
>
> I would very much like to see this working, but i have absolutely no  
> clue where to start looking...
>
> Cheers,
> Florian
> _______________________________________________
> 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 pyunyh at gmail.com  Wed Feb  4 17:30:43 2009
From: pyunyh at gmail.com (Pyun YongHyeon)
Date: Wed Feb  4 17:30:50 2009
Subject: fun with if_re
In-Reply-To: <20090204173753.GA98288@dsp.50hz.ws>
References: <20090204100507.5f223d9e.gerrit@pmp.uni-hannover.de>
	<20090204173753.GA98288@dsp.50hz.ws>
Message-ID: <20090205013147.GC77461@michelle.cdnetworks.co.kr>

On Wed, Feb 04, 2009 at 06:37:53PM +0100, Henrik Friedrichsen wrote:
> Hey.
> 
> I have had similar symptoms on a dedicated server with the re driver.
> What I did was grab more recent drivers (which might be redundant now)
> and disable a set of features that weren't stable at the time.

re(4) had several issues for PCIe based controllers on 7.0-RELEASE
and I believe most issues were resolved in HEAD/stable so I think
you can safely turn checksum offloading, VLAN hardware assistance
features. You can also enable TSO(default off) but I remember some
users reported issues for TSO, I didn't encounter TSO issues
though.
If you can still reproduce the issue please let me know.

> Please have a look at this PR that I submitted back then:
> 
> http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/125805
> 
From jasone at FreeBSD.org  Wed Feb  4 18:00:08 2009
From: jasone at FreeBSD.org (Jason Evans)
Date: Wed Feb  4 18:00:16 2009
Subject: Free memory after upgrade to 7.1
In-Reply-To: <gmd8jg$a0n$1@ger.gmane.org>
References: <4989BD92.9010506@max.af.czu.cz.cz> <gmd8jg$a0n$1@ger.gmane.org>
Message-ID: <498A44A0.6050107@FreeBSD.org>

Ivan Voras wrote:
> I think this is the major change in malloc between 7.0 and 7.1:
> http://svn.freebsd.org/viewvc/base?view=revision&revision=184602
> 
> You can test if it's the cause of your problem by toggling between 'D'
> and 'M' options to malloc.conf (see malloc(3), don't forget to restart
> apache).

Revision 184602 reverted the behavior so that malloc behaves the *same* 
for the 7.0 and 7.1 releases, with respect to DSS versus heap allocation.

Jason
From gerrit at pmp.uni-hannover.de  Wed Feb  4 23:58:16 2009
From: gerrit at pmp.uni-hannover.de (Gerrit =?ISO-8859-1?Q?K=FChn?=)
Date: Wed Feb  4 23:58:24 2009
Subject: fun with if_re
In-Reply-To: <20090204104655.GA73543@michelle.cdnetworks.co.kr>
References: <20090204100507.5f223d9e.gerrit@pmp.uni-hannover.de>
	<20090204104655.GA73543@michelle.cdnetworks.co.kr>
Message-ID: <20090205085812.b2deb1f7.gerrit@pmp.uni-hannover.de>

On Wed, 4 Feb 2009 19:46:55 +0900 Pyun YongHyeon <pyunyh@gmail.com> wrote
about Re: fun with if_re:


PY> Since you're using RTL8169SC it could be related with my commit
PY> r180519(cvs rev 1.95.2.22). It seems that RTL8169SC does not like
PY> memory mapped register access and I think jkim@ committed patch
PY> for the issue. Would you try re(4) in HEAD?
PY> (Just copying if_re.c, if_rlreg.h and if_rl.c from HEAD to
PY> stable would be enough to build re(4) on stable).

Thanks for the advice.
I did build new nanobsd images with these patches meanwhile and will start
using them today. However, as it has worked without problems for weeks
with the buggy version before, I will not be able to say if it is really
working until next month or so. Or do you know any method to reliably
trigger such errors?


cu
  Gerrit
From pyunyh at gmail.com  Thu Feb  5 00:26:57 2009
From: pyunyh at gmail.com (Pyun YongHyeon)
Date: Thu Feb  5 00:27:05 2009
Subject: fun with if_re
In-Reply-To: <20090205085812.b2deb1f7.gerrit@pmp.uni-hannover.de>
References: <20090204100507.5f223d9e.gerrit@pmp.uni-hannover.de>
	<20090204104655.GA73543@michelle.cdnetworks.co.kr>
	<20090205085812.b2deb1f7.gerrit@pmp.uni-hannover.de>
Message-ID: <20090205082804.GD77461@michelle.cdnetworks.co.kr>

On Thu, Feb 05, 2009 at 08:58:12AM +0100, Gerrit K?hn wrote:
> On Wed, 4 Feb 2009 19:46:55 +0900 Pyun YongHyeon <pyunyh@gmail.com> wrote
> about Re: fun with if_re:
> 
> 
> PY> Since you're using RTL8169SC it could be related with my commit
> PY> r180519(cvs rev 1.95.2.22). It seems that RTL8169SC does not like
> PY> memory mapped register access and I think jkim@ committed patch
> PY> for the issue. Would you try re(4) in HEAD?
> PY> (Just copying if_re.c, if_rlreg.h and if_rl.c from HEAD to
> PY> stable would be enough to build re(4) on stable).
> 
> Thanks for the advice.
> I did build new nanobsd images with these patches meanwhile and will start
> using them today. However, as it has worked without problems for weeks
> with the buggy version before, I will not be able to say if it is really
> working until next month or so. Or do you know any method to reliably

That's fine.

> trigger such errors?

Unfortunately no. Not all RTL8169SC controller shows the issue and
I don't know whether you have problematic one. 
From tevans.uk at googlemail.com  Thu Feb  5 01:38:52 2009
From: tevans.uk at googlemail.com (Tom Evans)
Date: Thu Feb  5 01:39:06 2009
Subject: Free memory after upgrade to 7.1
In-Reply-To: <4989D384.7090301@max.af.czu.cz.cz>
References: <4989BD92.9010506@max.af.czu.cz.cz>
	<1233766887.43076.18.camel@strangepork.mintel.co.uk>
	<4989D384.7090301@max.af.czu.cz.cz>
Message-ID: <1233826789.43076.25.camel@strangepork.mintel.co.uk>

On Wed, 2009-02-04 at 18:42 +0100, Tomas Randa wrote:
> Yes, I do portupgrade -Rrfia after upgrade of course.
> I don`t think it is some "new" PHP bug, because my friend have same 
> problem with memory and he do not upgraded ports. But his box do not 
> free memory after apache reload, my yes
> 
> Any other suggestions ?
> 
> Thanks TR
> 
> 
> 
> Tom Evans napsal(a):
> > On Wed, 2009-02-04 at 17:08 +0100, Tomas Randa wrote:
> >   
> >> Hello,
> >>
> >> I have i386/PAE system (php, apache22, mysql) running on 7-STABLE and I 
> >> can see strange behavior after upgrade from 7.0: Apache does not free 
> >> memory, for example:
> >>
> >> CPU: 31.2% user, 0.0% nice, 12.8% system, 0.7% interrupt, 55.3% idle
> >> Mem: 3520M Active, 3705M Inact, 465M Wired, 314M Cache, 112M Buf, 12M Free
> >> Swap: 4096M Total, 105M Used, 3991M Free, 2% Inuse
> >>
> >> then apachectl graceful
> >>
> >> CPU: 28.3% user, 0.0% nice, 8.6% system, 0.0% interrupt, 63.1% idle
> >> Mem: 631M Active, 3126M Inact, 353M Wired, 213M Cache, 112M Buf, 3693M Free
> >> Swap: 4096M Total, 1844K Used, 4094M Free
> >>
> >> Some graph: http://max.af.czu.cz/memoryload.png
> >>
> >> I know before upgrade was memory using about 2,5GB, now much more, 
> >> apache sometimes crash.
> >>
> >> Thanks for some help
> >>
> >> Tomas Randa
> >>     
> >
> > What is apache doing to use so much memory? This looks more like a
> > memory leak in PHP, which is reclaimed after apache restarts its
> > children.
> >
> > When you upgraded the OS, did you also upgrade ports? Could a new
> > version of PHP be at fault here?
> >
> > Cheers
> >
> > Tom
> >

Well, apache + its regular modules dont tend to leak memory, which is
what is happening. Can you run tests, eg by running your application on
apache with valgrind, to determine exactly where the leak occurs.

Tom

From saad at docisland.org  Thu Feb  5 01:44:06 2009
From: saad at docisland.org (Saad Kadhi)
Date: Thu Feb  5 01:44:14 2009
Subject: Ruby dumps core on 7.0-RELEASE-p7
Message-ID: <85165851-E375-4F4C-A1EF-7A5FB6B7CD23@docisland.org>

Hi,

I am using Ruby 1.8.6 (2008-08-11 patchlevel 287) on FreeBSD 7.0- 
RELEASE-p7. I have some code that -among other things- parses XML  
files and when it does in at least one case, it dumps core with the  
following error msg:

-x-x-x-
/usr/local/lib/ruby/1.8/rexml/parent.rb:19: [BUG] object allocation  
during garbage collection phase
ruby 1.8.6 (2008-08-11) [i386-freebsd7]
-x-x-x-

At times, I get a different error msg:
-x-x-x-
/usr/local/lib/ruby/1.8/rexml/namespace.rb:16: [BUG] object allocation  
during garbage collection phase
ruby 1.8.6 (2008-08-11) [i386-freebsd7]
-x-x-x-

I initially developed my code using Ruby 1.8.6 patchlevel 111 on the  
same platform and everything worked as expected. And when I upgraded  
to the latest stable version from ports, I started having these  
issues. Staying with 1.8.6 patchlevel 111 is not an option since this  
version is riddled with security vulnerabilities.

Any ideas on how to fix this problem?
TIA.
--
Saad Kadhi
"We can't compete on price. We also can't compete on quality, features
or service. That leaves fraud, which I'd like you to call marketing." --
Pointy-Haired Boss, Dilbert.




From gerrit at pmp.uni-hannover.de  Thu Feb  5 03:05:50 2009
From: gerrit at pmp.uni-hannover.de (Gerrit =?ISO-8859-1?Q?K=FChn?=)
Date: Thu Feb  5 03:05:57 2009
Subject: fun with if_re
In-Reply-To: <20090205082804.GD77461@michelle.cdnetworks.co.kr>
References: <20090204100507.5f223d9e.gerrit@pmp.uni-hannover.de>
	<20090204104655.GA73543@michelle.cdnetworks.co.kr>
	<20090205085812.b2deb1f7.gerrit@pmp.uni-hannover.de>
	<20090205082804.GD77461@michelle.cdnetworks.co.kr>
Message-ID: <20090205120546.f192684b.gerrit@pmp.uni-hannover.de>

On Thu, 5 Feb 2009 17:28:04 +0900 Pyun YongHyeon <pyunyh@gmail.com> wrote
about Re: fun with if_re:

PY> > I did build new nanobsd images with these patches meanwhile and will
PY> > start using them today. However, as it has worked without problems
PY> > for weeks with the buggy version before, I will not be able to say
PY> > if it is really working until next month or so. Or do you know any
PY> > method to reliably

PY> That's fine.

Sorry to be back so soon again, but I just noticed that I did in fact not
produce new images yesterday. :-)
Kernel build stopped with

---
mkdep -f .depend -a   -nostdinc -D_KERNEL -DKLD_MODULE
-DHAVE_KERNEL_OPTION_HEADERS -I. -I@ -I@/contrib/altq
-I/usr/tmp/usr/obj/usr/work/curren
t/src/sys/FIREFLY /usr/work/current/src/sys/modules/mii/../../dev/mii/acphy.c /usr/work/current/src/sys/modules/mii/../../dev/mii/amphy.c /usr/
work/current/src/sys/modules/mii/../../dev/mii/atphy.c /usr/work/current/src/sys/modules/mii/../../dev/mii/bmtphy.c /usr/work/current/src/sys/m
odules/mii/../../dev/mii/brgphy.c /usr/work/current/src/sys/modules/mii/../../dev/mii/ciphy.c /usr/work/current/src/sys/modules/mii/../../dev/m
ii/e1000phy.c /usr/work/current/src/sys/modules/mii/../../dev/mii/exphy.c /usr/work/current/src/sys/modules/mii/../../dev/mii/gentbi.c /usr/wor
k/current/src/sys/modules/mii/../../dev/mii/icsphy.c /usr/work/current/src/sys/modules/mii/../../dev/mii/inphy.c /usr/work/current/src/sys/modu
les/mii/../../dev/mii/ip1000phy.c /usr/work/current/src/sys/modules/mii/../../dev/mii/jmphy.c /usr/work/current/src/sys/modules/mii/../../dev/m
ii/lxtphy.c
miibus_if.c /usr/work/current/src/sys/modules/mii/../../dev/mii/mii.c /usr/work/current/src/sys/modules/mii/../../dev/mii/mii_physu
br.c /usr/work/current/src/sys/modules/mii/../../dev/mii/mlphy.c /usr/work/current/src/sys/modules/mii/../../dev/mii/nsgphy.c /usr/work/current /src/sys/modules/mii/../../dev/mii/nsphy.c /usr/work/current/src/sys/modules/mii/../../dev/mii/nsphyter.c /usr/work/current/src/sys/modules/mii /../../dev/mii/pnaphy.c /usr/work/current/src/sys/modules/mii/../../dev/mii/qsphy.c /usr/work/current/src/sys/modules/mii/../../dev/mii/rgephy.
c /usr/work/current/src/sys/modules/mii/../../dev/mii/rlphy.c /usr/work/current/src/sys/modules/mii/../../dev/mii/ruephy.c /usr/work/current/sr
c/sys/modules/mii/../../dev/mii/tdkphy.c /usr/work/current/src/sys/modules/mii/../../dev/mii/tlphy.c /usr/work/current/src/sys/modules/mii/../. ./dev/mii/truephy.c /usr/work/current/src/sys/modules/mii/../../dev/mii/ukphy.c /usr/work/current/src/sys/modules/mii/../../dev/mii/ukphy_subr.
c /usr/work/current/src/sys/modules/mii/../../dev/mii/xmphy.c
In file included
from /usr/work/current/src/sys/modules/mii/../../dev/mii/rgephy.c:60:
@/pci/if_rlreg.h:1509:28: error: token ";" is not valid in preprocessor
expressions @/pci/if_rlreg.h:1917:6: error: unterminated comment
@/pci/if_rlreg.h:1509:1: error: unterminated #if In file included
from /usr/work/current/src/sys/modules/mii/../../dev/mii/rlphy.c:56:
@/pci/if_rlreg.h:1509:28: error: token ";" is not valid in preprocessor
expressions @/pci/if_rlreg.h:1917:6: error: unterminated comment
@/pci/if_rlreg.h:1509:1: error: unterminated #if mkdep: compile failed
*** Error code 1
1 error
*** Error code 2
1 error
*** Error code 2
2 errors
*** Error code 2
1 error
*** Error code 2
1 error
---



Any hints?



cu
  Gerrit
From gerrit at pmp.uni-hannover.de  Thu Feb  5 03:13:33 2009
From: gerrit at pmp.uni-hannover.de (Gerrit =?ISO-8859-1?Q?K=FChn?=)
Date: Thu Feb  5 03:13:40 2009
Subject: fun with if_re
In-Reply-To: <20090205120546.f192684b.gerrit@pmp.uni-hannover.de>
References: <20090204100507.5f223d9e.gerrit@pmp.uni-hannover.de>
	<20090204104655.GA73543@michelle.cdnetworks.co.kr>
	<20090205085812.b2deb1f7.gerrit@pmp.uni-hannover.de>
	<20090205082804.GD77461@michelle.cdnetworks.co.kr>
	<20090205120546.f192684b.gerrit@pmp.uni-hannover.de>
Message-ID: <20090205121329.b510a1ae.gerrit@pmp.uni-hannover.de>

On Thu, 5 Feb 2009 12:05:46 +0100 Gerrit K?hn <gerrit@pmp.uni-hannover.de>
wrote about Re: fun with if_re:

GK> Sorry to be back so soon again, but I just noticed that I did in fact
GK> not produce new images yesterday. :-)
GK> Kernel build stopped with

[...]

Ignore me, my bad (downloaded the webpage instead of the code via
webcvs :-). On my way now.


cu
  Gerrit
From mattblists at icritical.com  Thu Feb  5 03:27:14 2009
From: mattblists at icritical.com (Matt Burke)
Date: Thu Feb  5 03:27:20 2009
Subject: 7.1-RELEASE I/O hang
In-Reply-To: <20090204143309.GF9427@deviant.kiev.zoral.com.ua>
References: <49898E3D.7030609@icritical.com>
	<20090204143309.GF9427@deviant.kiev.zoral.com.ua>
Message-ID: <498ACD02.4040602@icritical.com>

Kostik Belousov wrote:
> Compile ddb into the kernel, and do "ps" from the ddb prompt. If there
> are processes hung in the "nbufkv" state, then the patch below might
> help.

The bonnie++ processes are in state "newbuf" and other hung processes
(bash, newly forked sshds, etc) appear to be in the "ufs" state.

The patch appears to have no effect, although at the last hang I did see
one of the bonnie++ processes in "nbufkv" state. This could be coincidental.


The problem also exhibits itself when running a parallel bonnie++ on a
single array, both with the onboard PERC6/i and the PERC6/e. I have no
access to other controllers.
From kostikbel at gmail.com  Thu Feb  5 04:07:13 2009
From: kostikbel at gmail.com (Kostik Belousov)
Date: Thu Feb  5 04:07:21 2009
Subject: 7.1-RELEASE I/O hang
In-Reply-To: <498ACD02.4040602@icritical.com>
References: <49898E3D.7030609@icritical.com>
	<20090204143309.GF9427@deviant.kiev.zoral.com.ua>
	<498ACD02.4040602@icritical.com>
Message-ID: <20090205120655.GI9427@deviant.kiev.zoral.com.ua>

On Thu, Feb 05, 2009 at 11:26:58AM +0000, Matt Burke wrote:
> Kostik Belousov wrote:
> > Compile ddb into the kernel, and do "ps" from the ddb prompt. If there
> > are processes hung in the "nbufkv" state, then the patch below might
> > help.
> 
> The bonnie++ processes are in state "newbuf" and other hung processes
> (bash, newly forked sshds, etc) appear to be in the "ufs" state.
What is the state of the bufdaemon process ?

> 
> The patch appears to have no effect, although at the last hang I did see
> one of the bonnie++ processes in "nbufkv" state. This could be coincidental.
> 
> 
> The problem also exhibits itself when running a parallel bonnie++ on a
> single array, both with the onboard PERC6/i and the PERC6/e. I have no
> access to other controllers.
-------------- 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/20090205/064f9e49/attachment.pgp
From mattblists at icritical.com  Thu Feb  5 04:46:39 2009
From: mattblists at icritical.com (Matt Burke)
Date: Thu Feb  5 04:46:46 2009
Subject: 7.1-RELEASE I/O hang
In-Reply-To: <20090205120655.GI9427@deviant.kiev.zoral.com.ua>
References: <49898E3D.7030609@icritical.com>
	<20090204143309.GF9427@deviant.kiev.zoral.com.ua>
	<498ACD02.4040602@icritical.com>
	<20090205120655.GI9427@deviant.kiev.zoral.com.ua>
Message-ID: <498ADF9F.3050205@icritical.com>

Kostik Belousov wrote:
>>> Compile ddb into the kernel, and do "ps" from the ddb prompt. If there
>>> are processes hung in the "nbufkv" state, then the patch below might
>>> help.
>> The bonnie++ processes are in state "newbuf" and other hung processes
>> (bash, newly forked sshds, etc) appear to be in the "ufs" state.
> What is the state of the bufdaemon process ?

qsleep


-- 
From avg at icyb.net.ua  Thu Feb  5 06:34:13 2009
From: avg at icyb.net.ua (Andriy Gapon)
Date: Thu Feb  5 06:34:20 2009
Subject: nfs umount soft hang 
Message-ID: <498AF8E1.7020206@icyb.net.ua>


I have an NFS server and NFS client separated by a firewall. Both
servers are FreeBSD 7.1.

Server configuration:
nfs_server_enable="YES"
nfs_server_flags="-t -n 4"
rpcbind_enable="YES"
mountd_flags="-r -p 737"
mountd_enable="YES"

The firewall allows tcp and udp to port 111, but only tcp to ports 2049
and 737 (configured for mountd, see above).

On the client I use e.g. the following command for mounting:
mount -t nfs -o nfsv3,tcp,intr,rdirplus,-r=32768,-w=32768
XXXX:/export/usr/obj /usr/obj

Mounting and subsequent fs operations work flawlessly.

When I unmount umount command hangs but can be interrupted with ^C.
Everything seems to be clean after that - the filesystem is unmounted,
there are no post-effects on both client and server.

I used ktrace and tcpdump to investigate this and it seems that umount
command tries to send something to server's mountd via udp:
...
 13181 umount   CALL  sendto(0x4,0x2823e354,0x70,0,0x2823c008,0x10)
 13181 umount   GIO   fd 4 wrote 112 bytes
...

000477 IP (tos 0x0, ttl 64, id 19976, offset 0, flags [none], proto UDP
(17), length 140) 10.99.15.160.960 > 10.99.10.87.737: UDP, length 112

If wonder if this is correct behavior of umount.
Do I need to get mountd udp port allowed in the firewall?
Or is there a way to configure "everything" to tcp only?

-- 
Andriy Gapon
From klapperzhu at gmail.com  Thu Feb  5 09:18:39 2009
From: klapperzhu at gmail.com (Klapper Zhu)
Date: Thu Feb  5 09:19:16 2009
Subject: To John Birrell: weird behaviors of DTrace on amd64
In-Reply-To: <a29c138b0902050831q13844f7bm3aa3bdebdcb9733e@mail.gmail.com>
References: <a29c138b0902050831q13844f7bm3aa3bdebdcb9733e@mail.gmail.com>
Message-ID: <a29c138b0902050857o1d6062fdwffe77eccdd4c622a@mail.gmail.com>

Hi John Birrell,

I am exploring DTrace on "7.1-STABLE FreeBSD amd64" and I found several
weird behaviors:

1) Not all kernel functions show up in fbt provider. Take isp(4) as example:
   "dtrace -l" shows
       static void isp_freeze_loopdown(ispsoftc_t *, int, char *);
___but not___
       static void isp_handle_platform_atio2(ispsoftc_t *, at2_entry_t *);

   Both are static functions. But one shows up in fbt, another not.
   What's the rational behind it ? Any way to fix it ?

2) The symptom described below only shows in 64-bit platform (amd64).

 Here is the D Code:

 fbt::isp_handle_platform_atio2:entry
{
 self->cdb =args[1]->at_cmnd.cdb_dl.sf.fcp_cmnd_cdb[0];
 printf("%s(%x, %x, cdb_cmd %x)\n", probefunc, arg0, arg1, self->cdb);
}

It will never fire.

I have to add another 2 probes on top of it, then it
(fbt::isp_handle_platform_atio2:entry) will trace.
Even the 2 probes on top of it never fire.
---------------
dtrace:::BEGIN
{
tr = 0;
}
fbt:::entry
/tr == 1/
{
       @a[probefunc] = count();
}
fbt::isp_handle_platform_atio2:entry
{
 self->cdb =args[1]->at_cmnd.cdb_dl.sf.fcp_cmnd_cdb[0];
 printf("%s(%x, %x, cdb_cmd %x)\n", probefunc, arg0, arg1, self->cdb);
}

Thanks,

K. Zhu
From fabien.thomas at netasq.com  Thu Feb  5 09:24:18 2009
From: fabien.thomas at netasq.com (Fabien Thomas)
Date: Thu Feb  5 09:24:43 2009
Subject: Announcement: PmcTools callchain capture for FreeBSD 7.1 and
	stable_7
Message-ID: <DAE0E94B-9778-4597-B6E7-8940E137A90F@netasq.com>

Hello,

I've created a new patch for all the pmc feature available on trunk  
(02/05).
It has been tested on a core2duo in amd64 and i386 mode with success.

Feel free to test and give your feedback.
Thanks to Joseph Koshy for the hard work on pmc.

Patch is linked on the PmcTools wiki page: http://wiki.freebsd.org/PmcTools 
.

Fabien

From henrik at 50hz.ws  Thu Feb  5 09:37:58 2009
From: henrik at 50hz.ws (Henrik Friedrichsen)
Date: Thu Feb  5 09:38:06 2009
Subject: fun with if_re
In-Reply-To: <20090205013147.GC77461@michelle.cdnetworks.co.kr>
References: <20090204100507.5f223d9e.gerrit@pmp.uni-hannover.de>
	<20090204173753.GA98288@dsp.50hz.ws>
	<20090205013147.GC77461@michelle.cdnetworks.co.kr>
Message-ID: <20090205173820.GA16198@dsp.50hz.ws>

As I don't own that server anymore, I'm afraid I can't tell you whether
it's working now. :(

On Thu, Feb 05, 2009 at 10:31:47AM +0900, Pyun YongHyeon wrote:
> On Wed, Feb 04, 2009 at 06:37:53PM +0100, Henrik Friedrichsen wrote:
> > Hey.
> > 
> > I have had similar symptoms on a dedicated server with the re driver.
> > What I did was grab more recent drivers (which might be redundant now)
> > and disable a set of features that weren't stable at the time.
> 
> re(4) had several issues for PCIe based controllers on 7.0-RELEASE
> and I believe most issues were resolved in HEAD/stable so I think
> you can safely turn checksum offloading, VLAN hardware assistance
> features. You can also enable TSO(default off) but I remember some
> users reported issues for TSO, I didn't encounter TSO issues
> though.
> If you can still reproduce the issue please let me know.
> 
> > Please have a look at this PR that I submitted back then:
> > 
> > http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/125805
> > 
From mcdouga9 at egr.msu.edu  Thu Feb  5 10:44:38 2009
From: mcdouga9 at egr.msu.edu (Adam McDougall)
Date: Thu Feb  5 10:44:50 2009
Subject: Fwd: aac0 issues, Controller is no longer running
Message-ID: <20090205182652.GV59117@egr.msu.edu>

Forwarding to list because mail to emaste@freebsd.org bounced at the
location it is apparently being forwarded to so I'm not sure if it 
was received.  I'll add that the problem seems to follow a pattern where
it happens only twice after a reboot (usually in the morning when rsync runs)
and then its fine until the next intentional reboot.  
-------------- next part --------------
An embedded message was scrubbed...
From: Bryan Seitz <seitz@bsd-unix.net>
Subject: aac0 issues
Date: Wed, 4 Feb 2009 10:53:34 -0500
Size: 3894
Url: http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20090205/0f4be22f/attachment.eml
From mahan at mahan.org  Thu Feb  5 15:59:28 2009
From: mahan at mahan.org (Patrick Mahan)
Date: Thu Feb  5 15:59:36 2009
Subject: Replace Cisco IOS/CBOS with freebsd - possible?
In-Reply-To: <20090130165453.zny1a1ctq8sk0kk0@webmail.1command.com>
References: <20090129015034.7dxisep21w04gksg@webmail.1command.com>	<0bca01c98202$a6124350$f236c9f0$@co.uk>	<20090129051522.a92df0myf44gsko4@webmail.1command.com>	<62b856460901290538x5d857f08ka3b2ffb5a7aa8e7f@mail.gmail.com>	<20090129060243.adauuua9eokcsos8@webmail.1command.com>	<F9598B04-9CAD-4785-89E8-513095252B18@lamness.info>	<00fe01c98247$d6872600$83957200$@com>
	<49822E90.1010306@FreeBSD.org>	<20090129181838.l9cr09o0kk400gwc@webmail.1command.com>	<4982EB63.50703@FreeBSD.org>	<20090130070359.riaj3vq4aock4k0s@webmail.1command.com>	<49833266.4020602@mahan.org>
	<20090130165453.zny1a1ctq8sk0kk0@webmail.1command.com>
Message-ID: <498B7CA8.4030208@mahan.org>



Chris H presented these words - circa 1/30/09 4:54 PM->
> Hello Patrick, and thank you for your reply.
> 
> Quoting Patrick Mahan <mahan@mahan.org>:
> 
>>
>>
>> Chris H presented these words - circa 1/30/09 7:03 AM->
>>> Hello Bruce, and thank you for your reply.
>>>
>>> Quoting "Bruce M. Simpson" <bms@freebsd.org>:
>>>
>>>> Chris H wrote:
>>>>> ...
>>>>>>
>>>>>> I know Peter Grehan was looking at getting FreeBSD onto the Cisco 
>>>>>> 827 a while back.
>>>>>
>>>>> That's good news. I'll have to see if I can get more info on that.
>>>>> I just purchased a "lot" of cisco *DSL/routers on ebay, in an effort
>>>>> to push this project forward (I can experiment on these with less 
>>>>> concern).
>>>>
>>>> IMHO pfSense beats the pants off OpenWRT from a user/deployment 
>>>> point of view, and often that is ultimately what counts.
>>>
>>> I guess I'd have to agree, except if it weren't for the fact I always
>>> have a zillion things going simultaneously, I wouldn't even know what
>>> X was - I can't get enough VC's (virtual consoles), so I'm forced to
>>> use X. But, of course for most "end users" /convenience/ is everything,
>>> and most don't want to any more that how to turn it on. :)
>>>
>>>>
>>>>    Thing is, it's "only" for x86-based PCs. I had the foresight to 
>>>> purchase some relatively quiet 1U boxes, but they're still too noisy 
>>>> to have in a room where people sleep live or socialise -- they 
>>>> belong to the computer nook at the front of the apartment (I have a 
>>>> very odd C-shaped apartment).
>>>
>>> Yes, the (older) cisco's CPU's were MIPS - aka - Motorola, and ran AUX.
>>> I've got the latest version of AUX, which is a newer version than they
>>> ran. In fact, it wouldn't be a bit surprised if I could load AIX on it.
>>>
>>
>> Yes, most of the core CPU's used by Cisco were MIPS, however, they were
>> not made by Motorola
> 
> Please take no offense. But as I look inside, the CPU does, in fact
> say Motorola. The documentation for it also confirms that most of
> (if not all) of the 800 series also used the Motorola RISC.
> 

None taken.  I was never directly involved with any of the 800 series platforms,
but do not doubt they might have Motorola RISC chips.  My point was the where
MIPs CPUs were used, they were (mostly) not built by Motorola.  These were (are)
probably some of the PPC platforms.  I do know that some platforms used CPUs
(e.g. Cavium Octeon) that are MIPs cores.

>> and didn't run AUX (if by AUX you mean Apples Unix
>> OS).
> 
> I probably stand corrected on this. :)
> But I'll bet - given the CPU, it wouldn't be much of a streatch to
> run either AUX, or AIX on it.
> 

Maybe.  I do know that some of the common stuff in the kernel (like pci)
would probably not work.  I distinctly recalled having to craft a UART
driver when doing some early linux and FreeBSD investigations.

Patrick

> 
> Thanks again for your response.
> 
> --Chris
> 
>>  Instead they ran Cisco's own IOS kernel/software.
>>
>> Patrick Mahan
>>
>>>>
>>>>    I believe something that could really make pfSense fly, would be 
>>>> a viable port to mass-market, low-power consumer hardware. Then 
>>>> again, old Ciscos "sort of" fit the bill.
>>>
>>> Funny you bring that up. I was thinking the very same. As a matter of
>>> fact I have been contemplating whipping something up myself, and doing
>>> just that. While psSense initially seems appealing. The more I look into
>>> it, the more I find it's laking - where a simple roll-out is concerned.
>>> There isn't anything in the way of documentation. What's there is 
>>> /horribly/
>>> unorganized. It's scattered all over the place. What's more, the front
>>> page of the wiki suggests that reading the m0n0wall documentation would
>>> probabl;y be a better choice. Make no mistake, I know how daunting and
>>> hectic an opensource project can be, and am grateful to /anyone/ whom is
>>> willing to share the fruits of their labor at no cost. But I think I
>>> could do better, that's all.
>>>
>>>>
>>>>    Repurposing old vendor hardware is just as subject to engineering 
>>>> process as anything else, in some cases, the varying 
>>>> Bill-of-Materials may make the economic cost too high to do things 
>>>> on a mass scale.
>>>
>>> I think I have a solution for that. I'll elaborate further when I can
>>> confirm that.
>>>
>>>>
>>>>    If people would be reasonably expected to use such a system, they 
>>>> should not have to understand the mechanisms, in great detail, of 
>>>> how firmware is loaded onto a device. This is one of the main 
>>>> stumbling blocks behind mass uptake -- we can't just say "fire up 
>>>> this tool and click this 1 button" to extend/build new network 
>>>> infrastructure.
>>>>
>>>>    Given the current economic and ecological situation, though, 
>>>> devising systems which allow people to do this might be something 
>>>> worth investigating, and funding to that effect may be available 
>>>> "out there".
>>>
>>> I /quite/ agree, and intend to persue just that. I've already
>>> commissioned the artwork - and it looks GREAT. :)
>>>
>>> I'll elaborate further as things firm up.
>>>
>>> Thanks again Bruce, for taking the time to respond.
>>>
>>> --Chris
>>>
>>>>
>>>> cheers
>>>> BMS
>>>> _______________________________________________
>>>> 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"
>>>
>>>
>> _______________________________________________
>> 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 danny at cs.huji.ac.il  Thu Feb  5 22:32:29 2009
From: danny at cs.huji.ac.il (Danny Braniss)
Date: Thu Feb  5 22:32:37 2009
Subject: impossible packet length ...
Message-ID: <E1LVKGJ-000N9Q-EW@kabab.cs.huji.ac.il>

Hi,
on 2 different servers, running 7.1-stable + zfs, I get this
error rather frequently:

Feb  5 17:01:03 warhol-00 kernel: impossible packet length (543383918) from 
nfs server sunfire:/dist
Feb  5 17:01:03 warhol-00 kernel: impossible packet length (1936028704) from 
nfs server sunfire:/dist
Feb  5 17:01:03 warhol-00 kernel: impossible packet length (1869363744) from 
nfs server sunfire:/dist
Feb  5 17:01:03 warhol-00 kernel: impossible packet length (1667787057) from 
nfs server sunfire:/dist
Feb  5 17:01:03 warhol-00 kernel: impossible packet length (976040755) from 
nfs server sunfire:/dist
Feb  5 17:01:03 warhol-00 kernel: impossible packet length (1953459488) from 
nfs server sunfire:/dist
Feb  5 17:01:03 warhol-00 kernel: impossible packet length (1348825156) from 
nfs server sunfire:/dist
Feb  5 17:01:03 warhol-00 kernel: impossible packet length (0) from nfs server 
sunfire:/dist
Feb  5 17:01:03 warhol-00 kernel: impossible packet length (1647208041) from 
nfs server sunfire:/dist

in this case the server is running Freebsd-7.0-stable, but I also get it when 
the server is a
netapp.

is there a connection?

thanks,
	danny


From peterjeremy at optushome.com.au  Thu Feb  5 23:13:09 2009
From: peterjeremy at optushome.com.au (Peter Jeremy)
Date: Thu Feb  5 23:13:16 2009
Subject: impossible packet length ...
In-Reply-To: <E1LVKGJ-000N9Q-EW@kabab.cs.huji.ac.il>
References: <E1LVKGJ-000N9Q-EW@kabab.cs.huji.ac.il>
Message-ID: <20090206071231.GC1449@server.vk2pj.dyndns.org>

On 2009-Feb-06 08:32:27 +0200, Danny Braniss <danny@cs.huji.ac.il> wrote:
>on 2 different servers, running 7.1-stable + zfs, I get this
>error rather frequently:
>
>Feb  5 17:01:03 warhol-00 kernel: impossible packet length (543383918) from 
>nfs server sunfire:/dist

I gather warhol-00 is running 7.1-S+ZFS.
How recent a 'stable' is it?
Where does ZFS fit in?  Is sunfire:/dist mountpoint in a local ZFS or
is a local ZFS mountpoint inside the sunfire:/dist mount?
Do you get the same problems without any ZFS mounts?
Is this a TCP or UDP NFS mount?  What happens if you switch protocols?
What NIC are you using and are you seeing any network errors?
Are you able to capture a protocol trace showing the transaction including
erroneous packet?

-- 
Peter Jeremy
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20090206/eb9fd300/attachment.pgp
From danny at cs.huji.ac.il  Thu Feb  5 23:43:35 2009
From: danny at cs.huji.ac.il (Danny Braniss)
Date: Thu Feb  5 23:43:44 2009
Subject: impossible packet length ... 
In-Reply-To: <20090206071231.GC1449@server.vk2pj.dyndns.org> 
References: <E1LVKGJ-000N9Q-EW@kabab.cs.huji.ac.il> 
	<20090206071231.GC1449@server.vk2pj.dyndns.org>
Message-ID: <E1LVLN7-000Njo-3B@kabab.cs.huji.ac.il>


> On 2009-Feb-06 08:32:27 +0200, Danny Braniss <danny@cs.huji.ac.il> wrote:
> >on 2 different servers, running 7.1-stable + zfs, I get this
> >error rather frequently:
> >
> >Feb  5 17:01:03 warhol-00 kernel: impossible packet length (543383918) fro=
> m=20
> >nfs server sunfire:/dist
> 
So many quetsions :-)

> I gather warhol-00 is running 7.1-S+ZFS.
> How recent a 'stable' is it?
very:
	FreeBSD warhol-00 7.1-STABLE FreeBSD 7.1-STABLE #37: Fri Jan 23 10:41:54 IST 
2009
and its amd64.

> Where does ZFS fit in?  Is sunfire:/dist mountpoint in a local ZFS or
> is a local ZFS mountpoint inside the sunfire:/dist mount?
warhole is a nfs server, the storage is a ZFS local raid, the errors
occure on a nfs/tcp mounted file system on warhol.

> Do you get the same problems without any ZFS mounts?
I have several hosts running 7.1-stable without nfs exported ZFS, non have 
this error
That is why I think there is a connection, because on two, which have ZFS 
exported
the problem appears.

> Is this a TCP or UDP NFS mount?  What happens if you switch protocols?
i'll try but not trivial.
the other difference between the boxes is that one is dataless, while
the other is stand-alone (well, / is on a local disk, but /usr/local &
home dirs are on the network/nfs).

> What NIC are you using and are you seeing any network errors?
bce, the boxes are Dell-2950, but no visible errors.

> Are you able to capture a protocol trace showing the transaction including
> erroneous packet?
I have started the capture, but since I don't know what triggers the problem,
it will take some time. I will also start capturing packets at the router 
level,
but that will have to wait till next week.

thanks,
	danny

> 
> --=20
> Peter Jeremy
> 
> --gKMricLos+KVdGMg
> Content-Type: application/pgp-signature
> Content-Disposition: inline
> 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.10 (FreeBSD)
> 
> iEYEARECAAYFAkmL4t8ACgkQ/opHv/APuIeXNQCgg68TMfH6zh1gRaKfhCkNQi+0
> y10AoJcG7/7fiqL8oUpsWhIwhceWSFPo
> =MKeo
> -----END PGP SIGNATURE-----
> 
> --gKMricLos+KVdGMg--


From kostikbel at gmail.com  Fri Feb  6 02:30:32 2009
From: kostikbel at gmail.com (Kostik Belousov)
Date: Fri Feb  6 02:30:39 2009
Subject: 7.1-RELEASE I/O hang
In-Reply-To: <498ADF9F.3050205@icritical.com>
References: <49898E3D.7030609@icritical.com>
	<20090204143309.GF9427@deviant.kiev.zoral.com.ua>
	<498ACD02.4040602@icritical.com>
	<20090205120655.GI9427@deviant.kiev.zoral.com.ua>
	<498ADF9F.3050205@icritical.com>
Message-ID: <20090206103023.GN9427@deviant.kiev.zoral.com.ua>

On Thu, Feb 05, 2009 at 12:46:23PM +0000, Matt Burke wrote:
> Kostik Belousov wrote:
> >>> Compile ddb into the kernel, and do "ps" from the ddb prompt. If there
> >>> are processes hung in the "nbufkv" state, then the patch below might
> >>> help.
> >> The bonnie++ processes are in state "newbuf" and other hung processes
> >> (bash, newly forked sshds, etc) appear to be in the "ufs" state.
> > What is the state of the bufdaemon process ?
> 
> qsleep

Please, increase the value that is assigned to the target variable in the
line 2193 of the patched sys/kern/vfs_bio.c from 1 to, say, 10 or 100.
-------------- 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/20090206/342c8b22/attachment.pgp
From rwatson at FreeBSD.org  Fri Feb  6 04:46:59 2009
From: rwatson at FreeBSD.org (Robert Watson)
Date: Fri Feb  6 04:47:06 2009
Subject: To John Birrell: weird behaviors of DTrace on amd64
In-Reply-To: <a29c138b0902050857o1d6062fdwffe77eccdd4c622a@mail.gmail.com>
References: <a29c138b0902050831q13844f7bm3aa3bdebdcb9733e@mail.gmail.com>
	<a29c138b0902050857o1d6062fdwffe77eccdd4c622a@mail.gmail.com>
Message-ID: <alpine.BSF.2.00.0902061243230.6471@fledge.watson.org>


On Thu, 5 Feb 2009, Klapper Zhu wrote:

> I am exploring DTrace on "7.1-STABLE FreeBSD amd64" and I found several 
> weird behaviors:
>
> 1) Not all kernel functions show up in fbt provider. Take isp(4) as example:
>   "dtrace -l" shows
>       static void isp_freeze_loopdown(ispsoftc_t *, int, char *);
> ___but not___
>       static void isp_handle_platform_atio2(ispsoftc_t *, at2_entry_t *);
>
>   Both are static functions. But one shows up in fbt, another not.
>   What's the rational behind it ? Any way to fix it ?

Possibly gcc decided to inline one but not the other; you could try disabling 
inlining and see if the other function appears.  fbt is sensitive to a number 
of compiler choices, so generally if there's a long-term desire to trace at 
that point, we should add explicit trace points.  (Solaris makes similar 
recommendations -- that fbt is a useful but unstable interface).

> 2) The symptom described below only shows in 64-bit platform (amd64).
>
> Here is the D Code:
>
> fbt::isp_handle_platform_atio2:entry
> {
> self->cdb =args[1]->at_cmnd.cdb_dl.sf.fcp_cmnd_cdb[0];
> printf("%s(%x, %x, cdb_cmd %x)\n", probefunc, arg0, arg1, self->cdb);
> }
>
> It will never fire.
>
> I have to add another 2 probes on top of it, then it
> (fbt::isp_handle_platform_atio2:entry) will trace.
> Even the 2 probes on top of it never fire.

I've seen a number of cases where entry fbt points fire but return fbt points 
don't; for example, in 8.x I've noticed that fbt::softclock:enter fires each 
time the softclock loop runs, even though the function is only entered once 
when the kernel thread starts, and that it never fires the return.  This 
suggests fbt may be putting the probe in the wrong spot, perhaps the beginning 
of the block where local variables are used rather than the beginning of the 
function itself.  I've reported this problem to John also.

Robert N M Watson
Computer Laboratory
University of Cambridge
From klapperzhu at gmail.com  Fri Feb  6 10:22:38 2009
From: klapperzhu at gmail.com (Klapper Zhu)
Date: Fri Feb  6 10:23:12 2009
Subject: To John Birrell: weird behaviors of DTrace on amd64
In-Reply-To: <alpine.BSF.2.00.0902061243230.6471@fledge.watson.org>
References: <a29c138b0902050831q13844f7bm3aa3bdebdcb9733e@mail.gmail.com>
	<a29c138b0902050857o1d6062fdwffe77eccdd4c622a@mail.gmail.com>
	<alpine.BSF.2.00.0902061243230.6471@fledge.watson.org>
Message-ID: <a29c138b0902061022v40301c34v8f5b7edcb5c16395@mail.gmail.com>

Hi Robert,

I rebuilt kernel with -fno-inline and I got all isp(4) functions listed in fbt.

I noticed that there are other inline related flags
"--finline-limit=8000 -param inline-unit-growth=100  -Winline". should
I get rid of them OR -fno-inline
will just overide them ?

Thanks,

anyone has suggestion for problem 2 ?

On Fri, Feb 6, 2009 at 7:46 AM, Robert Watson <rwatson@freebsd.org> wrote:
>
> On Thu, 5 Feb 2009, Klapper Zhu wrote:
>
>> I am exploring DTrace on "7.1-STABLE FreeBSD amd64" and I found several
>> weird behaviors:
>>
>> 1) Not all kernel functions show up in fbt provider. Take isp(4) as
>> example:
>>  "dtrace -l" shows
>>      static void isp_freeze_loopdown(ispsoftc_t *, int, char *);
>> ___but not___
>>      static void isp_handle_platform_atio2(ispsoftc_t *, at2_entry_t *);
>>
>>  Both are static functions. But one shows up in fbt, another not.
>>  What's the rational behind it ? Any way to fix it ?
>
> Possibly gcc decided to inline one but not the other; you could try
> disabling inlining and see if the other function appears.  fbt is sensitive
> to a number of compiler choices, so generally if there's a long-term desire
> to trace at that point, we should add explicit trace points.  (Solaris makes
> similar recommendations -- that fbt is a useful but unstable interface).
>
>> 2) The symptom described below only shows in 64-bit platform (amd64).
>>
>> Here is the D Code:
>>
>> fbt::isp_handle_platform_atio2:entry
>> {
>> self->cdb =args[1]->at_cmnd.cdb_dl.sf.fcp_cmnd_cdb[0];
>> printf("%s(%x, %x, cdb_cmd %x)\n", probefunc, arg0, arg1, self->cdb);
>> }
>>
>> It will never fire.
>>
>> I have to add another 2 probes on top of it, then it
>> (fbt::isp_handle_platform_atio2:entry) will trace.
>> Even the 2 probes on top of it never fire.
>
> I've seen a number of cases where entry fbt points fire but return fbt
> points don't; for example, in 8.x I've noticed that fbt::softclock:enter
> fires each time the softclock loop runs, even though the function is only
> entered once when the kernel thread starts, and that it never fires the
> return.  This suggests fbt may be putting the probe in the wrong spot,
> perhaps the beginning of the block where local variables are used rather
> than the beginning of the function itself.  I've reported this problem to
> John also.
>
> Robert N M Watson
> Computer Laboratory
> University of Cambridge
>
From delphij at delphij.net  Fri Feb  6 10:49:56 2009
From: delphij at delphij.net (Xin LI)
Date: Fri Feb  6 10:50:05 2009
Subject: Fwd: aac0 issues, Controller is no longer running
In-Reply-To: <20090205182652.GV59117@egr.msu.edu>
References: <20090205182652.GV59117@egr.msu.edu>
Message-ID: <498C8649.2040009@delphij.net>

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

Hi, Adam,

Adam McDougall wrote:
[...]
>    I've been having issues with the aac0 driver with a Sun STK raid card ( Adaptec 5805 ).  After FBSD upgrades and a reboot,
> it will lock up when rsync backups run at night.  After doing this about 2-3 times over 2-3 days, it will stabilize and be rock
> solid.  If you could assist me in maybe debugging it somehow, I would greatly appreciate it.

Which release are you using in the past (seems you don't have problem
with that release, if I understand correctly), and which release are you
upgrading to?  That information would help us to narrow down the problem.

Cheers,
- --
Xin LI <delphij@delphij.net>	http://www.delphij.net/
FreeBSD - The Power to Serve!
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.10 (FreeBSD)

iEYEARECAAYFAkmMhkkACgkQi+vbBBjt66ArawCguMAZFYRdTuy6rFrBlVWQyNEH
U1cAoItouqUtVBcHWEQaMOzFZuQ1TMDM
=mbzh
-----END PGP SIGNATURE-----
From mcdouga9 at egr.msu.edu  Fri Feb  6 12:53:29 2009
From: mcdouga9 at egr.msu.edu (Adam McDougall)
Date: Fri Feb  6 12:53:42 2009
Subject: Fwd: aac0 issues, Controller is no longer running
In-Reply-To: <498C8649.2040009@delphij.net>
References: <20090205182652.GV59117@egr.msu.edu> <498C8649.2040009@delphij.net>
Message-ID: <498CA348.5090503@egr.msu.edu>

Xin LI wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hi, Adam,
>
> Adam McDougall wrote:
> [...]
>   
>>    I've been having issues with the aac0 driver with a Sun STK raid card ( Adaptec 5805 ).  After FBSD upgrades and a reboot,
>> it will lock up when rsync backups run at night.  After doing this about 2-3 times over 2-3 days, it will stabilize and be rock
>> solid.  If you could assist me in maybe debugging it somehow, I would greatly appreciate it.
>>     
>
> Which release are you using in the past (seems you don't have problem
> with that release, if I understand correctly), and which release are you
> upgrading to?  That information would help us to narrow down the problem.
>
> Cheers,
> - --
> Xin LI <delphij@delphij.net>	http://www.delphij.net/
>   
We've been tracking 7-stable since the system was installed about half a 
year ago.  This issue has occurred every few months whenever we update 
to a more recent -stable.  I haven't seen any recent changes to aac in 
the last few months; this last upgrade was purely compulsory.  This is 
the first time I can recall where it has hung up 3 nights in a row now 
after the upgrade, usually its just 2.  It seems that it hung up last 
night about 3am or possibly earlier, judging based on when remote 
network connections started timing out.  I'm guessing it was tickled by 
the nightly periodic find scripts.  Thanks.

From rwatson at FreeBSD.org  Fri Feb  6 14:47:59 2009
From: rwatson at FreeBSD.org (Robert Watson)
Date: Fri Feb  6 14:48:11 2009
Subject: jail: external and localhost distinction
In-Reply-To: <alpine.BSF.2.00.0901291237020.91263@woozle.rinet.ru>
References: <alpine.BSF.2.00.0901290021000.91263@woozle.rinet.ru>
	<alpine.BSF.2.00.0901290855010.70708@fledge.watson.org>
	<alpine.BSF.2.00.0901291237020.91263@woozle.rinet.ru>
Message-ID: <alpine.BSF.2.00.0902062245490.89719@fledge.watson.org>

On Thu, 29 Jan 2009, Dmitry Morozovsky wrote:

> Thank you for clarification, now I see this is actually expected behaviour 
> :)
>
> Would then starting second jail with the same root and, say, 127.10.0.1 as 
> an address be a workaround?

There's no technical reason you can't have more than one jail using the same 
file system root, and even IP -- you'll find that ps(1) in one jail can't see 
processes in the other (and can't signal, etc) but otherwise works as 
expected.  Of course, any given process has to be a member of at most one of 
the two.

Robert N M Watson
Computer Laboratory
University of Cambridge
From todorov at paladin.bulgarpress.com  Fri Feb  6 16:04:00 2009
From: todorov at paladin.bulgarpress.com (Todorov)
Date: Fri Feb  6 16:04:08 2009
Subject: FBSD 7.1 XEON Quad Core
Message-ID: <498CCB85.2080702@paladin.bulgarpress.com>

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

Hi list,

what are the good make.conf options for the Xeon Quad core.

CPUTYPE=core2 ??

Also is there any benefit to use AMD64 platform for this CPU?
(Java Diablo + PGSQL 8.1 + Apache + Apache Tomcat)

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

iEUEARECAAYFAkmMy4MACgkQibJkIG65HMdOhACdFRGDhcq+DMvkaViaJ/6X+tb+
7fwAmNCkyKgFExS5r2SfnFB6kl0ERl0=
=MvEN
-----END PGP SIGNATURE-----
From marck at rinet.ru  Sat Feb  7 07:51:40 2009
From: marck at rinet.ru (Dmitry Morozovsky)
Date: Sat Feb  7 07:51:55 2009
Subject: jail: external and localhost distinction
In-Reply-To: <alpine.BSF.2.00.0902062245490.89719@fledge.watson.org>
References: <alpine.BSF.2.00.0901290021000.91263@woozle.rinet.ru>
	<alpine.BSF.2.00.0901290855010.70708@fledge.watson.org>
	<alpine.BSF.2.00.0901291237020.91263@woozle.rinet.ru>
	<alpine.BSF.2.00.0902062245490.89719@fledge.watson.org>
Message-ID: <alpine.BSF.2.00.0902071850130.21613@woozle.rinet.ru>

On Fri, 6 Feb 2009, Robert Watson wrote:

RW> > Thank you for clarification, now I see this is actually expected behaviour
RW> > :)
RW> > 
RW> > Would then starting second jail with the same root and, say, 127.10.0.1 as
RW> > an address be a workaround?
RW> 
RW> There's no technical reason you can't have more than one jail using the same
RW> file system root, and even IP -- you'll find that ps(1) in one jail can't
RW> see processes in the other (and can't signal, etc) but otherwise works as
RW> expected.  Of course, any given process has to be a member of at most one of
RW> the two.

But, in the case of IP sharing, I suppose, the second process tries to bind to 
the same port will got "socket already in use", won't it?


-- 
Sincerely,
D.Marck                                     [DM5020, MCK-RIPE, DM3-RIPN]
[ FreeBSD committer:                                 marck@FreeBSD.org ]
------------------------------------------------------------------------
*** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- marck@rinet.ru ***
------------------------------------------------------------------------
From rwatson at FreeBSD.org  Sat Feb  7 08:26:39 2009
From: rwatson at FreeBSD.org (Robert Watson)
Date: Sat Feb  7 08:26:46 2009
Subject: jail: external and localhost distinction
In-Reply-To: <alpine.BSF.2.00.0902071850130.21613@woozle.rinet.ru>
References: <alpine.BSF.2.00.0901290021000.91263@woozle.rinet.ru>
	<alpine.BSF.2.00.0901290855010.70708@fledge.watson.org>
	<alpine.BSF.2.00.0901291237020.91263@woozle.rinet.ru>
	<alpine.BSF.2.00.0902062245490.89719@fledge.watson.org>
	<alpine.BSF.2.00.0902071850130.21613@woozle.rinet.ru>
Message-ID: <alpine.BSF.2.00.0902071612230.89719@fledge.watson.org>

On Sat, 7 Feb 2009, Dmitry Morozovsky wrote:

> On Fri, 6 Feb 2009, Robert Watson wrote:
>
> RW> > Thank you for clarification, now I see this is actually expected behaviour
> RW> > :)
> RW> >
> RW> > Would then starting second jail with the same root and, say, 127.10.0.1 as
> RW> > an address be a workaround?
> RW>
> RW> There's no technical reason you can't have more than one jail using the same
> RW> file system root, and even IP -- you'll find that ps(1) in one jail can't
> RW> see processes in the other (and can't signal, etc) but otherwise works as
> RW> expected.  Of course, any given process has to be a member of at most one of
> RW> the two.
>
> But, in the case of IP sharing, I suppose, the second process tries to bind 
> to the same port will got "socket already in use", won't it?

In general, if two processes independently bind the same port but using two 
specific IPs, then there won't be a conflict and both will be allowed to 
succeed.  Conflicts arise if there are two bindings of the same address and 
port, so if both jails use the same IP and one binds it, then the other will 
get a socket already in use error, yes.

FYI, I see that Bjoern has now committed the multi-IP patch for Jail to 
7-STABLE, which should make Jails a lot more flexible.

Robert N M Watson
Computer Laboratory
University of Cambridge
From ivoras at freebsd.org  Sat Feb  7 09:11:38 2009
From: ivoras at freebsd.org (Ivan Voras)
Date: Sat Feb  7 09:11:44 2009
Subject: FBSD 7.1 XEON Quad Core
In-Reply-To: <498CCB85.2080702@paladin.bulgarpress.com>
References: <498CCB85.2080702@paladin.bulgarpress.com>
Message-ID: <gmkfbs$fjr$1@ger.gmane.org>

Todorov wrote:
> Hi list,
> 
> what are the good make.conf options for the Xeon Quad core.
> 
> CPUTYPE=core2 ??

It's probably better to use

CFLAGS+=-O2 -mtune=native

> Also is there any benefit to use AMD64 platform for this CPU?
> (Java Diablo + PGSQL 8.1 + Apache + Apache Tomcat)

Yes, if you have (or plan to have) more than 3 GB of memory.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 258 bytes
Desc: OpenPGP digital signature
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20090207/0bce43db/signature.pgp
From bzeeb-lists at lists.zabbadoz.net  Sat Feb  7 10:20:08 2009
From: bzeeb-lists at lists.zabbadoz.net (Bjoern A. Zeeb)
Date: Sat Feb  7 10:20:15 2009
Subject: HEADS UP: multi-IPv4/v6/no-IP jails now in 7-STABLE
Message-ID: <20090207174104.Y93725@maildrop.int.zabbadoz.net>

Hi,

what has started a long time ago with patches from various people, was
started, abandoned, resumed finally found an end.

I am happy to hereby announce that the multi-IPv4/v6/no-IP jails work
has been merged to 7-STABLE and thus can be used in FreeBSD 7 without
the need to maintain or apply patches from now on.

This also means that the updated jails will be included in 7.2 release.

This update gives you (short selection):
- zero, one or multi-IP jails.
- IPv4 and IPv6 support.
- cpuset support for jails.
- jail names and states to ease administration. 
- 32bit compat on 64bit, jail v1 compat, ..

You'll find a longer summary about all the new features and how to use
them in a posting from December (you should really read it):
http://lists.freebsd.org/pipermail/freebsd-jail/2008-December/000631.html

Since the above posting, multiple PRs had been addressed and fixes include
- SIOCGIFADDR ioctl handling which fixes the "samba inside jails problem"
- no more arp and ndp information disclosure
- updated rc.conf framework (fully backward compatible in 7), see
   man 5 rc.conf and /etc/defaults/rc.conf.
- various documentation/man page updates
- ...


I'd like to thank everyone who had helped to make this possible!


If you like the work, mayhap even use it for your business, or just want
to support FreeBSD, you may want to visit
 	http://www.freebsdfoundation.org/
and help donating some money.


Enjoy your new jails!
(and don't try to escape - you sure won't succeed;)

/bz

-- 
Bjoern A. Zeeb                      The greatest risk is not taking one.
From bzeeb-lists at lists.zabbadoz.net  Sat Feb  7 12:40:09 2009
From: bzeeb-lists at lists.zabbadoz.net (Bjoern A. Zeeb)
Date: Sat Feb  7 12:40:29 2009
Subject: make installkernel broken
Message-ID: <20090207203445.G93725@maildrop.int.zabbadoz.net>

Hi,

I merged a change I had tested in my working but not a vanilla
stable/7 tree.  This broke make installkernel.

I am currently investigating if it's easily fixable w/o side effects
or I'll back it out in a bit.

If your sys/conf/kern.post.mk has r188288 (from 14:55:29 UTC) you are
affected by this.


I'll let you know once it is fixed.

/bz

-- 
Bjoern A. Zeeb                      The greatest risk is not taking one.
From bzeeb-lists at lists.zabbadoz.net  Sat Feb  7 13:15:08 2009
From: bzeeb-lists at lists.zabbadoz.net (Bjoern A. Zeeb)
Date: Sat Feb  7 13:15:15 2009
Subject: make installkernel broken
In-Reply-To: <20090207203445.G93725@maildrop.int.zabbadoz.net>
References: <20090207203445.G93725@maildrop.int.zabbadoz.net>
Message-ID: <20090207210817.S93725@maildrop.int.zabbadoz.net>

On Sat, 7 Feb 2009, Bjoern A. Zeeb wrote:

Hi,

> I merged a change I had tested in my working but not a vanilla
> stable/7 tree.  This broke make installkernel.
>
> I am currently investigating if it's easily fixable w/o side effects
> or I'll back it out in a bit.
>
> If your sys/conf/kern.post.mk has r188288 (from 14:55:29 UTC) you are
> affected by this.
>
>
> I'll let you know once it is fixed.

With r188296 (21:07:58 UTC) things should be fine again.

In case you hit the problem you can use
 	make installkernel KMODOWN=root KMODGRP=wheel
as a workaround.


In case you experience any problems/side efffects from the fix, let me
know immediately.


Sorry for the breakage.

/bz

-- 
Bjoern A. Zeeb                      The greatest risk is not taking one.
From markir at paradise.net.nz  Sat Feb  7 20:05:06 2009
From: markir at paradise.net.nz (Mark Kirkwood)
Date: Sat Feb  7 20:05:21 2009
Subject: Broken loader on 7.1-STABLE?
In-Reply-To: <4976CB1C.7050409@paradise.net.nz>
References: <20090109171857.GA49752@marvin.eastcentral.edu>
	<4975ADF4.1070103@paradise.net.nz> <4976CB1C.7050409@paradise.net.nz>
Message-ID: <498E59F0.30700@paradise.net.nz>

Mark Kirkwood wrote:
> I wrote:
>>  
>> I am getting this too - update from RELENG_7 @12 Jan src to 20 Jan 
>> and I have:
>>
>> panic: free: guard1 fail @ 0x511d
>> from /usr/src/sys/boot/i386/loader/../../common/module.c:959
>>
>> Can't work out which disk we are booting from.
>> Guessed BIOS device 0xffffffff not found by probes, defaulting to disk0
>>
>>
>
> Forgot to say (cc'ing Luigi as he is collecting info):
>
> Asus a8vx with an AMD 64x2 3800+ dual core
>

Also seeing this on a Supermicro P3TDER 2xPIII 1.26 GHz with RELENG_7 
@08 Feb. In this case specifying /boot/loader.old got me booted ok (not 
sure why this *didn't* work with the Asus, maybe I need to try it again 
with the Feb sources).

regards

Mark


From todorov at paladin.bulgarpress.com  Sat Feb  7 23:23:19 2009
From: todorov at paladin.bulgarpress.com (Todorov)
Date: Sat Feb  7 23:23:27 2009
Subject: FBSD 7.1 XEON Quad Core
In-Reply-To: <gmkfbs$fjr$1@ger.gmane.org>
References: <498CCB85.2080702@paladin.bulgarpress.com>
	<gmkfbs$fjr$1@ger.gmane.org>
Message-ID: <498E8863.7060808@paladin.bulgarpress.com>

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

Ivan Voras ??????:
| Todorov wrote:
|> Hi list,
|>
|> what are the good make.conf options for the Xeon Quad core.
|>
|> CPUTYPE=core2 ??
|
| It's probably better to use
|
| CFLAGS+=-O2 -mtune=native
|
|> Also is there any benefit to use AMD64 platform for this CPU?
|> (Java Diablo + PGSQL 8.1 + Apache + Apache Tomcat)
|
| Yes, if you have (or plan to have) more than 3 GB of memory.
|

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

iEYEARECAAYFAkmOiGMACgkQibJkIG65HMc7AACfZIDn4bv33cNyUia2mXcR3p/K
ST4An18rJYrvaLJL91i0HsIhqMdqXHrO
=gN9l
-----END PGP SIGNATURE-----
From danny at cs.huji.ac.il  Sun Feb  8 00:45:15 2009
From: danny at cs.huji.ac.il (Danny Braniss)
Date: Sun Feb  8 00:45:23 2009
Subject: impossible packet length ... 
In-Reply-To: Your message of Fri, 06 Feb 2009 08:32:27 +0200 .
Message-ID: <E1LW5Ht-0000VH-D8@kabab.cs.huji.ac.il>

I'm reposting this to hackers, and there is some more info.

> Hi,
> on 2 different servers, running 7.1-stable + zfs, I get this
> error rather frequently:
> 
> Feb  5 17:01:03 warhol-00 kernel: impossible packet length (543383918) from 
> nfs server sunfire:/dist
> Feb  5 17:01:03 warhol-00 kernel: impossible packet length (1936028704) from 
> nfs server sunfire:/dist
> Feb  5 17:01:03 warhol-00 kernel: impossible packet length (1869363744) from 
> nfs server sunfire:/dist
> Feb  5 17:01:03 warhol-00 kernel: impossible packet length (1667787057) from 
> nfs server sunfire:/dist
> Feb  5 17:01:03 warhol-00 kernel: impossible packet length (976040755) from 
> nfs server sunfire:/dist
> Feb  5 17:01:03 warhol-00 kernel: impossible packet length (1953459488) from 
> nfs server sunfire:/dist
> Feb  5 17:01:03 warhol-00 kernel: impossible packet length (1348825156) from 
> nfs server sunfire:/dist
> Feb  5 17:01:03 warhol-00 kernel: impossible packet length (0) from nfs server 
> sunfire:/dist
> Feb  5 17:01:03 warhol-00 kernel: impossible packet length (1647208041) from 
> nfs server sunfire:/dist
> 
> in this case the server is running Freebsd-7.0-stable, but I also get it when 
> the server is a
> netapp.
> 
> is there a connection?
> 
> thanks,
> 	danny

going through the logs, after it happened again, I got a glimps of this:

Feb  6 18:00:13 warhol-00.cs.huji.ac.il kernel: bce0: discard frame w/o 
leading ethernet header (len 0 pkt len 0)
Feb  6 18:00:19 klee-05.cs.huji.ac.il kernel: nfs: server warhol-00 not 
responding, timed out
...
Feb  6 19:00:00 warhol-00.cs.huji.ac.il amd[715]: More than a single value for 
/defaults in hesiod.local
Feb  6 19:00:00 warhol-00.cs.huji.ac.il amd[715]: Unknown $ sequence in 
"rhost:=${RHOST};type:=nfsl;fs:=${FS};rfs:=$huldig<C0>#^ZM-^KoM- abase"
Feb  6 19:00:00 warhol-00.cs.huji.ac.il kernel: impossible packet length 
(2068989523) from nfs server sunfire:/dist

which seems to point fingers at bce...

danny



From danny at cs.huji.ac.il  Sun Feb  8 01:31:47 2009
From: danny at cs.huji.ac.il (Danny Braniss)
Date: Sun Feb  8 01:31:56 2009
Subject: impossible packet length ... 
In-Reply-To: <20090208091656.GA31876@test71.vk2pj.dyndns.org> 
References: <E1LW5Ht-0000VH-D8@kabab.cs.huji.ac.il> 
	<20090208091656.GA31876@test71.vk2pj.dyndns.org>
Message-ID: <E1LW60v-0000zC-B2@kabab.cs.huji.ac.il>

> 
> --jI8keyz6grp/JLjh
> Content-Type: text/plain; charset=us-ascii
> Content-Disposition: inline
> Content-Transfer-Encoding: quoted-printable
> 
> On 2009-Feb-08 10:45:13 +0200, Danny Braniss <danny@cs.huji.ac.il> wrote:
> >Feb  6 18:00:13 warhol-00.cs.huji.ac.il kernel: bce0: discard frame w/o=20
> >leading ethernet header (len 0 pkt len 0)
> =2E..
> >Feb  6 19:00:00 warhol-00.cs.huji.ac.il amd[715]: Unknown $ sequence in=20
> >"rhost:=3D${RHOST};type:=3Dnfsl;fs:=3D${FS};rfs:=3D$huldig<C0>#^ZM-^KoM- a=
> base"
> >Feb  6 19:00:00 warhol-00.cs.huji.ac.il kernel: impossible packet length=
> =20
> >(2068989523) from nfs server sunfire:/dist
> >
> >which seems to point fingers at bce...
> 
> It does rather suggest that bce is not behaving.  What happens if you
> turn off checksum off-loading?  This should make the kernel drop the
> corrupt packets instead of trying to process them.  If practical, you
> could also try (temporarily) plugging in a different NIC.
> 
I have, and now it's a matter of waiting...
Q: with rxcsum on, and a bad checksum packet is received, is it
   dropped by the NIC? if not, then it somewhat explains the behaviour

changing the nic is tough, but if needed will be done. 
	danny

> Peter Jeremy

From peter at vk2pj.dyndns.org  Sun Feb  8 02:43:25 2009
From: peter at vk2pj.dyndns.org (Peter Jeremy)
Date: Sun Feb  8 02:43:33 2009
Subject: impossible packet length ...
In-Reply-To: <E1LW60v-0000zC-B2@kabab.cs.huji.ac.il>
References: <E1LW5Ht-0000VH-D8@kabab.cs.huji.ac.il>
	<20090208091656.GA31876@test71.vk2pj.dyndns.org>
	<E1LW60v-0000zC-B2@kabab.cs.huji.ac.il>
Message-ID: <20090208104253.GB31876@test71.vk2pj.dyndns.org>

On 2009-Feb-08 11:31:45 +0200, Danny Braniss <danny@cs.huji.ac.il> wrote:
>Q: with rxcsum on, and a bad checksum packet is received, is it
>   dropped by the NIC? if not, then it somewhat explains the behaviour

If checksum offloading is working correctly then a bad packet should
be dropped by the NIC.  If checksum offloading isn't working correctly
then you can wind up in the situation where both the NIC and the
driver think the other party has verified the checksum.  It's also
possible that you may be running into corruption during DMA transfer
from the NIC to RAM.  ISTR there have been some issues reported
recently with checksum offloading on some NICs - though I don't have
details to hand - you might like to search the lists.

>changing the nic is tough, but if needed will be done. 

If disabling checksum offloading fixes the problem and the additional
CPU load is acceptable (at least until you find a real fix) then
there's no need to change NICs.

-- 
Peter Jeremy
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20090208/45a23a18/attachment.pgp
From kostikbel at gmail.com  Sun Feb  8 03:23:05 2009
From: kostikbel at gmail.com (Kostik Belousov)
Date: Sun Feb  8 03:23:13 2009
Subject: impossible packet length ...
In-Reply-To: <E1LW5Ht-0000VH-D8@kabab.cs.huji.ac.il>
References: <E1LW5Ht-0000VH-D8@kabab.cs.huji.ac.il>
Message-ID: <20090208112259.GW9427@deviant.kiev.zoral.com.ua>

On Sun, Feb 08, 2009 at 10:45:13AM +0200, Danny Braniss wrote:
> I'm reposting this to hackers, and there is some more info.
> 
> > Hi,
> > on 2 different servers, running 7.1-stable + zfs, I get this
> > error rather frequently:
> > 
> > Feb  5 17:01:03 warhol-00 kernel: impossible packet length (543383918) from 
> > nfs server sunfire:/dist
> > Feb  5 17:01:03 warhol-00 kernel: impossible packet length (1936028704) from 
> > nfs server sunfire:/dist
> > Feb  5 17:01:03 warhol-00 kernel: impossible packet length (1869363744) from 
> > nfs server sunfire:/dist
> > Feb  5 17:01:03 warhol-00 kernel: impossible packet length (1667787057) from 
> > nfs server sunfire:/dist
> > Feb  5 17:01:03 warhol-00 kernel: impossible packet length (976040755) from 
> > nfs server sunfire:/dist
> > Feb  5 17:01:03 warhol-00 kernel: impossible packet length (1953459488) from 
> > nfs server sunfire:/dist
> > Feb  5 17:01:03 warhol-00 kernel: impossible packet length (1348825156) from 
> > nfs server sunfire:/dist
> > Feb  5 17:01:03 warhol-00 kernel: impossible packet length (0) from nfs server 
> > sunfire:/dist
> > Feb  5 17:01:03 warhol-00 kernel: impossible packet length (1647208041) from 
> > nfs server sunfire:/dist
> > 
> > in this case the server is running Freebsd-7.0-stable, but I also get it when 
> > the server is a
> > netapp.
> > 
> > is there a connection?
> > 
> > thanks,
> > 	danny
> 
> going through the logs, after it happened again, I got a glimps of this:
> 
> Feb  6 18:00:13 warhol-00.cs.huji.ac.il kernel: bce0: discard frame w/o 
> leading ethernet header (len 0 pkt len 0)
> Feb  6 18:00:19 klee-05.cs.huji.ac.il kernel: nfs: server warhol-00 not 
> responding, timed out
> ...
> Feb  6 19:00:00 warhol-00.cs.huji.ac.il amd[715]: More than a single value for 
> /defaults in hesiod.local
> Feb  6 19:00:00 warhol-00.cs.huji.ac.il amd[715]: Unknown $ sequence in 
> "rhost:=${RHOST};type:=nfsl;fs:=${FS};rfs:=$huldig<C0>#^ZM-^KoM- abase"
> Feb  6 19:00:00 warhol-00.cs.huji.ac.il kernel: impossible packet length 
> (2068989523) from nfs server sunfire:/dist
> 
> which seems to point fingers at bce...

bce(4) is broken in stable, your best option is to revert to the
driver in releng 7.1.
-------------- 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/20090208/933fa35a/attachment.pgp
From kostikbel at gmail.com  Sun Feb  8 04:11:47 2009
From: kostikbel at gmail.com (Kostik Belousov)
Date: Sun Feb  8 04:12:00 2009
Subject: Possible VFS KPI and KBI breakage on stable/7
Message-ID: <20090208121142.GX9427@deviant.kiev.zoral.com.ua>

There are three sets of changes that would benefit stable/7.
Namely, there are

1. Improvements for the UFS unmount or rw->ro remount, that perform
   suspension during the operation.

   The changes depend on the the suspension mechanism path,
   that introduced the suspension owner, and added new VFS OP
   into the mount method table.

   This might also fix the hangs with gjournal or gjournal together
   with snapshots experienced by some users.

   Since the only real consumer of the suspension is UFS, I believe that MFC
   would have quite low impact, if any.

   Corresponding revision is 183073.

2. The openat(2) and similar syscalls. The new ZFS requires openat()
   functionality. We have to change struct nameidata to merge NDINIT_ATVP().

   All modules using namei() need to be recompiled.

3. The Marcus' work on vn_fullpath() support for synthetic filesystems
   introduces new VOP, vop_vptocnp.

   This would allow procstat(1) to work on devfs and pseudofs vnodes.
   As I understand, this would also improve Gnome experience on FreeBSD.

   All fs modules need to be recompiled.

There was one very magisterial voice that objected against KBI breakage
on stable branch in principle. In my opinion, the benefits of the bug
fixes and functionality improvements with the proposed merges are much
greater then inconvenience of the need to recompile out-of-tree fs
modules. Changes were discussed with re@ to some extent.

In case there is vocal objection against the merge, I would abstain
from doing this.
-------------- 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/20090208/76ae61b3/attachment.pgp
From rwatson at FreeBSD.org  Sun Feb  8 04:56:22 2009
From: rwatson at FreeBSD.org (Robert Watson)
Date: Sun Feb  8 04:56:28 2009
Subject: impossible packet length ...
In-Reply-To: <20090208104253.GB31876@test71.vk2pj.dyndns.org>
References: <E1LW5Ht-0000VH-D8@kabab.cs.huji.ac.il>
	<20090208091656.GA31876@test71.vk2pj.dyndns.org>
	<E1LW60v-0000zC-B2@kabab.cs.huji.ac.il>
	<20090208104253.GB31876@test71.vk2pj.dyndns.org>
Message-ID: <alpine.BSF.2.00.0902081252300.1129@fledge.watson.org>

On Sun, 8 Feb 2009, Peter Jeremy wrote:

> On 2009-Feb-08 11:31:45 +0200, Danny Braniss <danny@cs.huji.ac.il> wrote:
>> Q: with rxcsum on, and a bad checksum packet is received, is it
>>   dropped by the NIC? if not, then it somewhat explains the behaviour
>
> If checksum offloading is working correctly then a bad packet should be 
> dropped by the NIC.  If checksum offloading isn't working correctly then you 
> can wind up in the situation where both the NIC and the driver think the 
> other party has verified the checksum.  It's also possible that you may be 
> running into corruption during DMA transfer from the NIC to RAM.  ISTR there 
> have been some issues reported recently with checksum offloading on some 
> NICs - though I don't have details to hand - you might like to search the 
> lists.
>
>> changing the nic is tough, but if needed will be done.
>
> If disabling checksum offloading fixes the problem and the additional CPU 
> load is acceptable (at least until you find a real fix) then there's no need 
> to change NICs.

Actually, my understanding was that packets with bad checksums are delivered 
to software, and flag the descriptor ring header for each packet tells us 
whether the checksum was (a) checked and (b) validated by the hardware.  We 
then propagate these to mbuf flags so that higher stack layers know whether or 
not to calculate the checksum themselves.  Regardless of the specifics, 
though, packets with checked but bad checksums shouldn't make it to the socket 
layer where they would be visible to NFS.  If the NIC is marking apparently 
bad packets as good, there are a number of possible sources -- be it bad 
checksum handling in the card, corruption between the card and higher levels 
of the stack (a DMA problem, as you point out, would have this symptom).

Robert N M Watson
Computer Laboratory
University of Cambridge
From petefrench at ticketswitch.com  Sun Feb  8 05:12:01 2009
From: petefrench at ticketswitch.com (Pete French)
Date: Sun Feb  8 05:12:08 2009
Subject: Big problems with 7.1 locking up :-(
In-Reply-To: <alpine.BSF.2.00.0901292234430.30840@fledge.watson.org>
Message-ID: <E1LW9Ru-000Bgv-6a@dilbert.ticketswitch.com>

> load.  Kip Macy has corrected at least one (both?) problems in head, and
> plans to MFC the fixes in the near future.  We'll follow up further once
> the fixes are merged, and if any further problems transpire.

Hi, just wondering if we are any closer to having the MFC for this yet, or
if there are any patches I could test ?

cheers,

-pete.
From danny at cs.huji.ac.il  Sun Feb  8 05:16:17 2009
From: danny at cs.huji.ac.il (Danny Braniss)
Date: Sun Feb  8 05:16:25 2009
Subject: impossible packet length ... 
In-Reply-To: <alpine.BSF.2.00.0902081252300.1129@fledge.watson.org> 
References: <E1LW5Ht-0000VH-D8@kabab.cs.huji.ac.il> 
	<20090208091656.GA31876@test71.vk2pj.dyndns.org>
	<E1LW60v-0000zC-B2@kabab.cs.huji.ac.il>
	<20090208104253.GB31876@test71.vk2pj.dyndns.org>
	<alpine.BSF.2.00.0902081252300.1129@fledge.watson.org>
Message-ID: <E1LW9WA-0003Fu-O4@kabab.cs.huji.ac.il>

> On Sun, 8 Feb 2009, Peter Jeremy wrote:
> 
> > On 2009-Feb-08 11:31:45 +0200, Danny Braniss <danny@cs.huji.ac.il> wrote:
> >> Q: with rxcsum on, and a bad checksum packet is received, is it
> >>   dropped by the NIC? if not, then it somewhat explains the behaviour
> >
> > If checksum offloading is working correctly then a bad packet should be 
> > dropped by the NIC.  If checksum offloading isn't working correctly then you 
> > can wind up in the situation where both the NIC and the driver think the 
> > other party has verified the checksum.  It's also possible that you may be 
> > running into corruption during DMA transfer from the NIC to RAM.  ISTR there 
> > have been some issues reported recently with checksum offloading on some 
> > NICs - though I don't have details to hand - you might like to search the 
> > lists.
> >
> >> changing the nic is tough, but if needed will be done.
> >
> > If disabling checksum offloading fixes the problem and the additional CPU 
> > load is acceptable (at least until you find a real fix) then there's no need 
> > to change NICs.
> 
> Actually, my understanding was that packets with bad checksums are delivered 
> to software, and flag the descriptor ring header for each packet tells us 
> whether the checksum was (a) checked and (b) validated by the hardware.  We 
> then propagate these to mbuf flags so that higher stack layers know whether or 
> not to calculate the checksum themselves.  Regardless of the specifics, 
> though, packets with checked but bad checksums shouldn't make it to the socket 
> layer where they would be visible to NFS.  If the NIC is marking apparently 
> bad packets as good, there are a number of possible sources -- be it bad 
> checksum handling in the card, corruption between the card and higher levels 
> of the stack (a DMA problem, as you point out, would have this symptom).

looking at the bce source, it's not clear (to me :-). If errors are detected in
bce_rx_intr(), the packet gets dropped, which I would expect to be the 
treatment
of an offloded chekcum error, but it seems that is not the case. 

danny



From rwatson at FreeBSD.org  Sun Feb  8 05:19:24 2009
From: rwatson at FreeBSD.org (Robert Watson)
Date: Sun Feb  8 05:19:31 2009
Subject: impossible packet length ... 
In-Reply-To: <E1LW9WA-0003Fu-O4@kabab.cs.huji.ac.il>
References: <E1LW5Ht-0000VH-D8@kabab.cs.huji.ac.il>
	<20090208091656.GA31876@test71.vk2pj.dyndns.org>
	<E1LW60v-0000zC-B2@kabab.cs.huji.ac.il>
	<20090208104253.GB31876@test71.vk2pj.dyndns.org>
	<alpine.BSF.2.00.0902081252300.1129@fledge.watson.org>
	<E1LW9WA-0003Fu-O4@kabab.cs.huji.ac.il>
Message-ID: <alpine.BSF.2.00.0902081318000.89719@fledge.watson.org>


On Sun, 8 Feb 2009, Danny Braniss wrote:

> looking at the bce source, it's not clear (to me :-). If errors are detected 
> in bce_rx_intr(), the packet gets dropped, which I would expect to be the 
> treatment of an offloded chekcum error, but it seems that is not the case.

I think we're thinking of different checksums -- devices/device drivers drop 
frames with bad ethernet checksums, but not IP and above layer checksums.

Robert N M Watson
Computer Laboratory
University of Cambridge
From peter at vk2pj.dyndns.org  Sun Feb  8 05:39:25 2009
From: peter at vk2pj.dyndns.org (Peter Jeremy)
Date: Sun Feb  8 05:39:33 2009
Subject: impossible packet length ...
In-Reply-To: <E1LW5Ht-0000VH-D8@kabab.cs.huji.ac.il>
References: <E1LW5Ht-0000VH-D8@kabab.cs.huji.ac.il>
Message-ID: <20090208091656.GA31876@test71.vk2pj.dyndns.org>

On 2009-Feb-08 10:45:13 +0200, Danny Braniss <danny@cs.huji.ac.il> wrote:
>Feb  6 18:00:13 warhol-00.cs.huji.ac.il kernel: bce0: discard frame w/o 
>leading ethernet header (len 0 pkt len 0)
...
>Feb  6 19:00:00 warhol-00.cs.huji.ac.il amd[715]: Unknown $ sequence in 
>"rhost:=${RHOST};type:=nfsl;fs:=${FS};rfs:=$huldig<C0>#^ZM-^KoM- abase"
>Feb  6 19:00:00 warhol-00.cs.huji.ac.il kernel: impossible packet length 
>(2068989523) from nfs server sunfire:/dist
>
>which seems to point fingers at bce...

It does rather suggest that bce is not behaving.  What happens if you
turn off checksum off-loading?  This should make the kernel drop the
corrupt packets instead of trying to process them.  If practical, you
could also try (temporarily) plugging in a different NIC.

-- 
Peter Jeremy
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20090208/3c54a215/attachment.pgp
From danny at cs.huji.ac.il  Sun Feb  8 05:45:19 2009
From: danny at cs.huji.ac.il (Danny Braniss)
Date: Sun Feb  8 05:45:26 2009
Subject: impossible packet length ... 
In-Reply-To: <alpine.BSF.2.00.0902081318000.89719@fledge.watson.org> 
References: <E1LW5Ht-0000VH-D8@kabab.cs.huji.ac.il> 
	<20090208091656.GA31876@test71.vk2pj.dyndns.org>
	<E1LW60v-0000zC-B2@kabab.cs.huji.ac.il>
	<20090208104253.GB31876@test71.vk2pj.dyndns.org>
	<alpine.BSF.2.00.0902081252300.1129@fledge.watson.org>
	<E1LW9WA-0003Fu-O4@kabab.cs.huji.ac.il>
	<alpine.BSF.2.00.0902081318000.89719@fledge.watson.org>
Message-ID: <E1LW9yH-0003Xm-KS@kabab.cs.huji.ac.il>

> 
> On Sun, 8 Feb 2009, Danny Braniss wrote:
> 
> > looking at the bce source, it's not clear (to me :-). If errors are detected 
> > in bce_rx_intr(), the packet gets dropped, which I would expect to be the 
> > treatment of an offloded chekcum error, but it seems that is not the case.
> 
> I think we're thinking of different checksums -- devices/device drivers drop 
> frames with bad ethernet checksums, but not IP and above layer checksums.

I know I'm stepping on thin ice hear - haven't touched Stevens for a while,
(and I doubt it mentions offloading), but if the offload checksum is bad,
why not just drop the packet?

The way I read the driver, if the offload checksum is on, and if no
errors where detected, then it's marked as ok.

danny


From rwatson at FreeBSD.org  Sun Feb  8 06:33:34 2009
From: rwatson at FreeBSD.org (Robert Watson)
Date: Sun Feb  8 06:33:41 2009
Subject: impossible packet length ... 
In-Reply-To: <E1LW9yH-0003Xm-KS@kabab.cs.huji.ac.il>
References: <E1LW5Ht-0000VH-D8@kabab.cs.huji.ac.il>
	<20090208091656.GA31876@test71.vk2pj.dyndns.org>
	<E1LW60v-0000zC-B2@kabab.cs.huji.ac.il>
	<20090208104253.GB31876@test71.vk2pj.dyndns.org>
	<alpine.BSF.2.00.0902081252300.1129@fledge.watson.org>
	<E1LW9WA-0003Fu-O4@kabab.cs.huji.ac.il>
	<alpine.BSF.2.00.0902081318000.89719@fledge.watson.org>
	<E1LW9yH-0003Xm-KS@kabab.cs.huji.ac.il>
Message-ID: <alpine.BSF.2.00.0902081427260.1129@fledge.watson.org>


On Sun, 8 Feb 2009, Danny Braniss wrote:

>> On Sun, 8 Feb 2009, Danny Braniss wrote:
>>
>>> looking at the bce source, it's not clear (to me :-). If errors are 
>>> detected in bce_rx_intr(), the packet gets dropped, which I would expect 
>>> to be the treatment of an offloded chekcum error, but it seems that is not 
>>> the case.
>>
>> I think we're thinking of different checksums -- devices/device drivers 
>> drop frames with bad ethernet checksums, but not IP and above layer 
>> checksums.
>
> I know I'm stepping on thin ice hear - haven't touched Stevens for a while, 
> (and I doubt it mentions offloading), but if the offload checksum is bad, 
> why not just drop the packet?
>
> The way I read the driver, if the offload checksum is on, and if no errors 
> where detected, then it's marked as ok.

There are a few good reasons I can think of, but this is hardly a 
comprehensive list:

(1) If there are bad higher level checksums on the wire, you want to see them
     in tcpdump, so allow them to get up to a higher layer if network layer
     checksums aren't good.

(2) It's a matter of local policy as to whether UDP checksums (for example)
     are observed or not.

(3) If you're forwarding or bridging packets, it should be up to the end nodes
     how they deal with bad UDP checksums on packets to them, not the routers.

Looking at if_bce.c, the following seems to be reasonable logic; first, 
ethernet-layer checksums:

5902                 /* Check the received frame for errors. */
5903                 if (status & (L2_FHDR_ERRORS_BAD_CRC |
5904                         L2_FHDR_ERRORS_PHY_DECODE | 
L2_FHDR_ERRORS_ALIGNMENT |
5905                         L2_FHDR_ERRORS_TOO_SHORT  | 
L2_FHDR_ERRORS_GIANT_FRAME)) {
5906
5907                         /* Log the error and release the mbuf. */
5908                         ifp->if_ierrors++;
5909                         DBRUN(sc->l2fhdr_status_errors++);
5910
5911                         m_freem(m0);
5912                         m0 = NULL;
5913                         goto bce_rx_int_next_rx;
5914                 }

I.e., if there are ethernet-level CRC failures, drop the packet.

5922                 /* Validate the checksum if offload enabled. */
5923                 if (ifp->if_capenable & IFCAP_RXCSUM) {
5924
5925                         /* Check for an IP datagram. */
5926                         if (!(status & L2_FHDR_STATUS_SPLIT) &&
5927                                 (status & L2_FHDR_STATUS_IP_DATAGRAM)) {
5928                                 m0->m_pkthdr.csum_flags |= 
CSUM_IP_CHECKED;
5929
5930                                 /* Check if the IP checksum is valid. */
5931                                 if ((l2fhdr->l2_fhdr_ip_xsum ^ 0xffff) == 
0)
5932                                         m0->m_pkthdr.csum_flags |= 
CSUM_IP_VALID;
5933                         }
5934
5935                         /* Check for a valid TCP/UDP frame. */
5936                         if (status & (L2_FHDR_STATUS_TCP_SEGMENT |
5937                                 L2_FHDR_STATUS_UDP_DATAGRAM)) {
5938
5939                                 /* Check for a good TCP/UDP checksum. */
5940                                 if ((status & (L2_FHDR_ERRORS_TCP_XSUM |
5941                                               L2_FHDR_ERRORS_UDP_XSUM)) 
== 0) {
5942                                         m0->m_pkthdr.csum_data =
5943                                             l2fhdr->l2_fhdr_tcp_udp_xsum;
5944                                         m0->m_pkthdr.csum_flags |= 
(CSUM_DATA_VALID
5945                                                 | CSUM_PSEUDO_HDR);
5946                                 }
5947                         }
5948                 }

Only look at higher level checksums if policy enables it on the interface; 
then, only if the hardware has a view on the IP-layer checksums, propagte that 
information to the mbuf flags from the descriptor ring entry flags, both 
whether or not the checksum was verified, and whether or not it was good.  If 
policy disables it, or the hardware expresses no view, we don't set flags, 
which simply defers checksumming to a higher layer (if required -- for 
forwarded packets, we won't test UDP-layer checksums at all).

Robert N M Watson
Computer Laboratory
University of Cambridge
From stefan.lambrev at moneybookers.com  Sun Feb  8 07:27:23 2009
From: stefan.lambrev at moneybookers.com (Stefan Lambrev)
Date: Sun Feb  8 07:27:30 2009
Subject: Big problems with 7.1 locking up :-(
In-Reply-To: <E1LW9Ru-000Bgv-6a@dilbert.ticketswitch.com>
References: <E1LW9Ru-000Bgv-6a@dilbert.ticketswitch.com>
Message-ID: <AC6A17B7-355F-4B92-8F3B-008CEAC973C8@moneybookers.com>

Hi all,

In this thread someone mention a problem with soekris devices.
I personally have one of those new soekris devices and installed 7.1R  
and it is very easy to freeze it.
All that I have to do is to copy big file vfer WIFI (atheros) with  
speed higher then 1-2MB/s.
It takes less then 2 minutes to freeze. I wonder if there is some  
improvement
in 7.1-stable so I can try it or if I can help by compiling debug  
kernel?
But I'm not sure if this is the same problem as it may be just the  
wireless driver in my case.

On Feb 8, 2009, at 3:11 PM, Pete French wrote:

>> load.  Kip Macy has corrected at least one (both?) problems in  
>> head, and
>> plans to MFC the fixes in the near future.  We'll follow up further  
>> once
>> the fixes are merged, and if any further problems transpire.
>
> Hi, just wondering if we are any closer to having the MFC for this  
> yet, or
> if there are any patches I could test ?
>
> cheers,
>
> -pete.
> _______________________________________________
> 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 
> "

--
Best Wishes,
Stefan Lambrev
ICQ# 24134177





From cpghost at cordula.ws  Sun Feb  8 09:26:22 2009
From: cpghost at cordula.ws (cpghost)
Date: Sun Feb  8 09:26:30 2009
Subject: Big problems with 7.1 locking up :-(
In-Reply-To: <AC6A17B7-355F-4B92-8F3B-008CEAC973C8@moneybookers.com>
References: <E1LW9Ru-000Bgv-6a@dilbert.ticketswitch.com>
	<AC6A17B7-355F-4B92-8F3B-008CEAC973C8@moneybookers.com>
Message-ID: <20090208170941.GA3183@phenom.cordula.ws>

On Sun, Feb 08, 2009 at 05:11:02PM +0200, Stefan Lambrev wrote:
> Hi all,
> 
> In this thread someone mention a problem with soekris devices.
> I personally have one of those new soekris devices and installed 7.1R  
> and it is very easy to freeze it.
> All that I have to do is to copy big file vfer WIFI (atheros) with  
> speed higher then 1-2MB/s.
> It takes less then 2 minutes to freeze. I wonder if there is some  
> improvement
> in 7.1-stable so I can try it or if I can help by compiling debug  
> kernel?
> But I'm not sure if this is the same problem as it may be just the  
> wireless driver in my case.

One some net4801's without WIFI, I also experience frequent
freezes after a couple of hours up to 2-5 days... so it's
probably not only ath related.

What's your kern.hz value? In my /boot/loader.conf, it is set
to 100. Could you try it too, and see if you can still freeze
the box (just to rule out some weird timing / interrupt issue)?

> Best Wishes,
> Stefan Lambrev
> ICQ# 24134177

Regards,
-cpghost.

-- 
Cordula's Web. http://www.cordula.ws/
From mike at sentex.net  Sun Feb  8 12:28:51 2009
From: mike at sentex.net (Mike Tancsa)
Date: Sun Feb  8 12:28:57 2009
Subject: Big problems with 7.1 locking up :-(
In-Reply-To: <AC6A17B7-355F-4B92-8F3B-008CEAC973C8@moneybookers.com>
References: <E1LW9Ru-000Bgv-6a@dilbert.ticketswitch.com>
	<AC6A17B7-355F-4B92-8F3B-008CEAC973C8@moneybookers.com>
Message-ID: <200902082028.n18KSl5S024058@lava.sentex.ca>

At 10:11 AM 2/8/2009, Stefan Lambrev wrote:
>Hi all,
>
>In this thread someone mention a problem with soekris devices.
>I personally have one of those new soekris devices and installed 7.1R
>and it is very easy to freeze it.
>All that I have to do is to copy big file vfer WIFI (atheros) with
>speed higher then 1-2MB/s.


Try and copy across the ethernet.   I have several RELENG_7 boxes 
deployed on soekris and Alix boards (same chipset pretty well) and 
have not seen any stability issues.


         ---Mike 

From markir at paradise.net.nz  Sun Feb  8 14:37:32 2009
From: markir at paradise.net.nz (Mark Kirkwood)
Date: Sun Feb  8 14:37:39 2009
Subject: Broken loader on 7.1-STABLE?
In-Reply-To: <498E59F0.30700@paradise.net.nz>
References: <20090109171857.GA49752@marvin.eastcentral.edu>
	<4975ADF4.1070103@paradise.net.nz> <4976CB1C.7050409@paradise.net.nz>
	<498E59F0.30700@paradise.net.nz>
Message-ID: <498F5EA9.3020003@paradise.net.nz>

Mark Kirkwood wrote:
>
>  ...specifying /boot/loader.old got me booted ok (not sure why this 
> *didn't* work with the Asus, maybe I need to try it again with the Feb 
> sources).
>
>

I tried the latest RELENG_7 sources, same result - does *not* boot even 
specifying the old loader. I spent a bit of time narrowing down why. I'd 
previously noted that an empty loader.conf was sufficient to get it to 
boot again. After some experimentation I discovered that this line in 
loader.conf:

sound_load="YES"

made the boot with the old loader fail (loading the sound module after 
booting seems to work ok).

The box is an Asus a8vx with amd64 x2 3800+, running i386.

regards

Mark
From bms at FreeBSD.org  Sun Feb  8 18:08:29 2009
From: bms at FreeBSD.org (Bruce M. Simpson)
Date: Sun Feb  8 18:08:37 2009
Subject: Unhappy Xorg upgrade
In-Reply-To: <4983A3AE.90804@FreeBSD.org>
References: <329181233306971@webmail57.yandex.ru>	<985A59F2-20CC-4779-A000-018E52B5BFA9@jump-ing.de>	<101781233319948@webmail36.yandex.ru>
	<4983A3AE.90804@FreeBSD.org>
Message-ID: <498F901A.7000900@FreeBSD.org>

Bruce M. Simpson wrote:
> S.N.Grigoriev wrote:
>> I thank you for your response. I've applied the patch to pci.c from
>> kern/130957. Unfortunately there are no positive results. USB is still
>> unreachable with X.
>
> Just following up to confirm that you are seeing exactly the same 
> symptoms with USB and Xorg 7.4 as I see on my amd64 desktop running 
> 7-STABLE from 00:00 UTC on this Wednesday.

I still see the USB symptoms with xorg-server port as of today -- forced 
rebuild with libpciaccess also. So amd64 is still regressed -- USB is 
totally unusable there after X is started. My theory was that somehow 
Xorg was stomping on the USB controller registers on this machine. The 
USB controller on this box is ALi, card=0x81561043.

My i386 laptop (IBM/Lenovo T43) is not affected, and USB mice work just 
fine there.

Obviously it's difficult to check what Xorg is actually doing to the 
registers on the box w/o a PCI bus analyzer, and of course due to normal 
decoding, those cycles probably won't be seen on the backplane itself as 
it sits behind a bridge; I haven't fully read what libpciaccess is doing.

I skimmed patch-src-freebsd_pci.c. I wonder if this code may be stomping 
on the USB controller in some way (i.e. how it frobs the BARs).

According to src/tools/tools/pciroms, the only PCI devices on this box 
with ROM BARs are mskc0 and vgapci0.

(I also wonder if it's possible to guarantee that the window at 0xC0000 
is always going to be available, even in the amd64 case.)

cheers
BMS
From anderson at freebsd.org  Sun Feb  8 20:09:34 2009
From: anderson at freebsd.org (Eric Anderson)
Date: Sun Feb  8 20:09:47 2009
Subject: impossible packet length ... 
In-Reply-To: <E1LW60v-0000zC-B2@kabab.cs.huji.ac.il>
References: <E1LW5Ht-0000VH-D8@kabab.cs.huji.ac.il>
	<20090208091656.GA31876@test71.vk2pj.dyndns.org>
	<E1LW60v-0000zC-B2@kabab.cs.huji.ac.il>
Message-ID: <205598DD-B746-4236-9140-855811BAE21C@freebsd.org>

On Feb 8, 2009, at 3:31 AM, Danny Braniss wrote:

>>
>> --jI8keyz6grp/JLjh
>> Content-Type: text/plain; charset=us-ascii
>> Content-Disposition: inline
>> Content-Transfer-Encoding: quoted-printable
>>
>> On 2009-Feb-08 10:45:13 +0200, Danny Braniss <danny@cs.huji.ac.il>  
>> wrote:
>>> Feb  6 18:00:13 warhol-00.cs.huji.ac.il kernel: bce0: discard  
>>> frame w/o=20
>>> leading ethernet header (len 0 pkt len 0)
>> =2E..
>>> Feb  6 19:00:00 warhol-00.cs.huji.ac.il amd[715]: Unknown $  
>>> sequence in=20
>>> "rhost:=3D${RHOST};type:=3Dnfsl;fs:=3D${FS};rfs:=3D$huldig<C0>#^ZM- 
>>> ^KoM- a=
>> base"
>>> Feb  6 19:00:00 warhol-00.cs.huji.ac.il kernel: impossible packet  
>>> length=
>> =20
>>> (2068989523) from nfs server sunfire:/dist
>>>
>>> which seems to point fingers at bce...
>>
>> It does rather suggest that bce is not behaving.  What happens if you
>> turn off checksum off-loading?  This should make the kernel drop the
>> corrupt packets instead of trying to process them.  If practical, you
>> could also try (temporarily) plugging in a different NIC.
>>
> I have, and now it's a matter of waiting...
> Q: with rxcsum on, and a bad checksum packet is received, is it
>   dropped by the NIC? if not, then it somewhat explains the behaviour
>
> changing the nic is tough, but if needed will be done.
> 	danny
>
>> Peter Jeremy


We were hitting this quite a bit (also bce), and updated to a recent 7- 
branch and it seems to be behaving better for now.  Running 12 days so  
far (which is better than what we had been seeing).

Eric






From eugen at kuzbass.ru  Sun Feb  8 20:31:47 2009
From: eugen at kuzbass.ru (Eugene Grosbein)
Date: Sun Feb  8 20:31:55 2009
Subject: sysctl lock in RELENG_6
Message-ID: <498FAA2A.7423AC15@kuzbass.ru>

Hi!

I've RELENG_6 system controlling local PBX through RS-232 port, sio(4).
It also runs syslogd, cron, sshd, bsnmpd and sendmail for outgoing reports.

It locks very often: it answers to pings but PBX controlling software stops
responding, local and remote login attempts hang due to 'login' process
stuck in 'sysctl lock' state. Local consoles do switch with 'Alt-Fn'
and DDB works. It shows that sendmail is in 'sysctl lock' state too.

This is NanoBSD installation running from IDE flash, it's swapless
but I think I could manage to obtain crashdump if there is an interest of it.

I've digged commit logs a bit and found this change MFC'd to RELENG_7
but not RELENG_6:

http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/kern/kern_sysctl.c#rev1.177.6.2

It seems RELENG_6 needs this too, doesn't it?
I'm going to merge the change to RELENG_6 and give it a try.

Eugene Grosbein
From rnoland at FreeBSD.org  Sun Feb  8 21:31:36 2009
From: rnoland at FreeBSD.org (Robert Noland)
Date: Sun Feb  8 21:31:43 2009
Subject: Unhappy Xorg upgrade
In-Reply-To: <498F901A.7000900@FreeBSD.org>
References: <329181233306971@webmail57.yandex.ru>
	<985A59F2-20CC-4779-A000-018E52B5BFA9@jump-ing.de>
	<101781233319948@webmail36.yandex.ru> <4983A3AE.90804@FreeBSD.org>
	<498F901A.7000900@FreeBSD.org>
Message-ID: <1234157480.16095.10.camel@ferret.2hip.net>

On Mon, 2009-02-09 at 02:08 +0000, Bruce M. Simpson wrote:
> Bruce M. Simpson wrote:
> > S.N.Grigoriev wrote:
> >> I thank you for your response. I've applied the patch to pci.c from
> >> kern/130957. Unfortunately there are no positive results. USB is still
> >> unreachable with X.
> >
> > Just following up to confirm that you are seeing exactly the same 
> > symptoms with USB and Xorg 7.4 as I see on my amd64 desktop running 
> > 7-STABLE from 00:00 UTC on this Wednesday.
> 
> I still see the USB symptoms with xorg-server port as of today -- forced 
> rebuild with libpciaccess also. So amd64 is still regressed -- USB is 
> totally unusable there after X is started. My theory was that somehow 
> Xorg was stomping on the USB controller registers on this machine. The 
> USB controller on this box is ALi, card=0x81561043.
> 
> My i386 laptop (IBM/Lenovo T43) is not affected, and USB mice work just 
> fine there.
> 
> Obviously it's difficult to check what Xorg is actually doing to the 
> registers on the box w/o a PCI bus analyzer, and of course due to normal 
> decoding, those cycles probably won't be seen on the backplane itself as 
> it sits behind a bridge; I haven't fully read what libpciaccess is doing.
> 
> I skimmed patch-src-freebsd_pci.c. I wonder if this code may be stomping 
> on the USB controller in some way (i.e. how it frobs the BARs).

Until last night, it only probed pci resources for pci class DISPLAY
subclass VGA.  The rom reading was restricted to 0xc0000/0x10000, which
it mmap and copied out to a userland buffer.

As of last night, I committed the code that actually checks for a pci
rom.  If it finds one, it uses those values (base address, length) to
mmap the bios for copy.  If it doesn't find a pci rom, (most IGDs
(intel, via, sis) it just uses the 0xc0000 mapping as it did before if
it is i386 or amd64.  Otherwise, bios reading just fails.

robert.

> According to src/tools/tools/pciroms, the only PCI devices on this box 
> with ROM BARs are mskc0 and vgapci0.
> 
> (I also wonder if it's possible to guarantee that the window at 0xC0000 
> is always going to be available, even in the amd64 case.)
> 
> cheers
> BMS
-- 
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/20090209/55ef940c/attachment.pgp
From rnoland at FreeBSD.org  Sun Feb  8 22:00:50 2009
From: rnoland at FreeBSD.org (Robert Noland)
Date: Sun Feb  8 22:01:48 2009
Subject: Unhappy Xorg upgrade
In-Reply-To: <498F901A.7000900@FreeBSD.org>
References: <329181233306971@webmail57.yandex.ru>
	<985A59F2-20CC-4779-A000-018E52B5BFA9@jump-ing.de>
	<101781233319948@webmail36.yandex.ru> <4983A3AE.90804@FreeBSD.org>
	<498F901A.7000900@FreeBSD.org>
Message-ID: <1234159237.23838.3.camel@ferret.2hip.net>

On Mon, 2009-02-09 at 02:08 +0000, Bruce M. Simpson wrote:
> Bruce M. Simpson wrote:
> > S.N.Grigoriev wrote:
> >> I thank you for your response. I've applied the patch to pci.c from
> >> kern/130957. Unfortunately there are no positive results. USB is still
> >> unreachable with X.
> >
> > Just following up to confirm that you are seeing exactly the same 
> > symptoms with USB and Xorg 7.4 as I see on my amd64 desktop running 
> > 7-STABLE from 00:00 UTC on this Wednesday.
> 
> I still see the USB symptoms with xorg-server port as of today -- forced 
> rebuild with libpciaccess also. So amd64 is still regressed -- USB is 
> totally unusable there after X is started. My theory was that somehow 
> Xorg was stomping on the USB controller registers on this machine. The 
> USB controller on this box is ALi, card=0x81561043.

Is your usb sharing interrupts with the video card?

Does the issue occur if you aren't using a usb mouse?

robert.

> My i386 laptop (IBM/Lenovo T43) is not affected, and USB mice work just 
> fine there.
> 
> Obviously it's difficult to check what Xorg is actually doing to the 
> registers on the box w/o a PCI bus analyzer, and of course due to normal 
> decoding, those cycles probably won't be seen on the backplane itself as 
> it sits behind a bridge; I haven't fully read what libpciaccess is doing.
> 
> I skimmed patch-src-freebsd_pci.c. I wonder if this code may be stomping 
> on the USB controller in some way (i.e. how it frobs the BARs).
> 
> According to src/tools/tools/pciroms, the only PCI devices on this box 
> with ROM BARs are mskc0 and vgapci0.
> 
> (I also wonder if it's possible to guarantee that the window at 0xC0000 
> is always going to be available, even in the amd64 case.)
> 
> cheers
> BMS
-- 
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/20090209/827f9930/attachment.pgp
From spork at bway.net  Sun Feb  8 22:13:13 2009
From: spork at bway.net (Charles Sprickman)
Date: Sun Feb  8 22:13:21 2009
Subject: 7.1 Panic on degraded disk w/mpt
Message-ID: <alpine.OSX.2.00.0902090102060.37588@toasty.nat.fasttrackmonkey.com>

Howdy,

I dug around and can't find a PR on this, and the only other report I saw 
was in this mailing list post that has no replies:

http://www.nabble.com/7.1-BETA2-panic-on-mpt-degrade-td20183173.html

The hardware is a Dell PowerEdge 860 with the Dell/LSI SAS5 controller:
mpt0: <LSILogic SAS/SATA Adapter> port 0xec00-0xecff mem 
0xfe9fc000-0xfe9fffff,0xfe9e0000-0xfe9effff irq 16 at device 8.0 on pci2
mpt0: MPI Version=1.5.13.0

The panic is repeatable by forcing the array into a degraded state.

Here's my best shot at getting info out of kgdb:

[root@uniweb /home/spork]# cd /usr/obj/usr/src/sys/BWAY7/
[root@uniweb /usr/obj/usr/src/sys/BWAY7]# 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:


Fatal trap 12: page fault while in kernel mode
cpuid = 0; apic id = 00
fault virtual address   = 0x14
fault code              = supervisor read, page not present
instruction pointer     = 0x20:0xc044b09b
stack pointer           = 0x28:0xe6ee5b80
frame pointer           = 0x28:0xe6ee5b9c
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         = 17 (swi2: cambio)
trap number             = 12
panic: page fault
cpuid = 0
Uptime: 3m7s
Physical memory: 3575 MB
Dumping 94 MB: 79 63 47 31 15

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) list *0xc044b09b
0xc044b09b is in xpt_done (/usr/src/sys/cam/cam_xpt.c:4832).
4827            if ((done_ccb->ccb_h.func_code & XPT_FC_QUEUED) != 0) {
4828                    /*
4829                     * Queue up the request for handling by our SWI handler
4830                     * any of the "non-immediate" type of ccbs.
4831                     */
4832                    sim = done_ccb->ccb_h.path->bus->sim;
4833                    switch (done_ccb->ccb_h.path->periph->type) {
4834                    case CAM_PERIPH_BIO:
4835                            TAILQ_INSERT_TAIL(&sim->sim_doneq, &done_ccb->ccb_h,
4836                                              sim_links.tqe);

(kgdb) backtrace
#0  doadump () at pcpu.h:196
#1  0xc061d0f7 in boot (howto=260) at 
/usr/src/sys/kern/kern_shutdown.c:418
#2  0xc061d3c9 in panic (fmt=Variable "fmt" is not available.
) at /usr/src/sys/kern/kern_shutdown.c:574
#3  0xc0865fcc in trap_fatal (frame=0xe6ee5b40, eva=20)
     at /usr/src/sys/i386/i386/trap.c:939
#4  0xc0866230 in trap_pfault (frame=0xe6ee5b40, usermode=0, eva=20)
     at /usr/src/sys/i386/i386/trap.c:852
#5  0xc0866bc2 in trap (frame=0xe6ee5b40) at 
/usr/src/sys/i386/i386/trap.c:530
#6  0xc084d45b in calltrap () at /usr/src/sys/i386/i386/exception.s:159
#7  0xc044b09b in xpt_done (done_ccb=0xc6bf5000)
     at /usr/src/sys/cam/cam_xpt.c:4832
#8  0xc044eee9 in xpt_scan_bus (periph=0xc6984b00, request_ccb=0xc6bf5000)
     at /usr/src/sys/cam/cam_xpt.c:5395
#9  0xc044d241 in camisr_runqueue (V_queue=Variable "V_queue" is not 
available.
) at /usr/src/sys/cam/cam_xpt.c:7316
#10 0xc044d39e in camisr (dummy=0x0) at /usr/src/sys/cam/cam_xpt.c:7216
#11 0xc05fb41b in ithread_loop (arg=0xc699d770)
     at /usr/src/sys/kern/kern_intr.c:1088
#12 0xc05f7f69 in fork_exit (callout=0xc05fb260 <ithread_loop>,
     arg=0xc699d770, frame=0xe6ee5d38) at /usr/src/sys/kern/kern_fork.c:810
#13 0xc084d4d0 in fork_trampoline () at 
/usr/src/sys/i386/i386/exception.s:264

I can supply dmesg, more info, make it crash more, etc.  I suspect it will 
panic again when the rebuild completes, I'll capture that one as well.

Please let me know how to proceed - I can open a PR if this is truly a 
bug, or bring it over to freebsd-scsi if more appropriate.

Thanks,

Charles

___
Charles Sprickman
NetEng/SysAdmin
Bway.net - New York's Best Internet - www.bway.net
spork@bway.net - 212.655.9344

From danny at cs.huji.ac.il  Sun Feb  8 22:46:14 2009
From: danny at cs.huji.ac.il (Danny Braniss)
Date: Sun Feb  8 22:46:22 2009
Subject: impossible packet length ... 
In-Reply-To: <alpine.BSF.2.00.0902081427260.1129@fledge.watson.org> 
References: <E1LW5Ht-0000VH-D8@kabab.cs.huji.ac.il> 
	<20090208091656.GA31876@test71.vk2pj.dyndns.org>
	<E1LW60v-0000zC-B2@kabab.cs.huji.ac.il>
	<20090208104253.GB31876@test71.vk2pj.dyndns.org>
	<alpine.BSF.2.00.0902081252300.1129@fledge.watson.org>
	<E1LW9WA-0003Fu-O4@kabab.cs.huji.ac.il>
	<alpine.BSF.2.00.0902081318000.89719@fledge.watson.org>
	<E1LW9yH-0003Xm-KS@kabab.cs.huji.ac.il>
	<alpine.BSF.2.00.0902081427260.1129@fledge.watson.org>
Message-ID: <E1LWPuG-000DW9-96@kabab.cs.huji.ac.il>

> 
> On Sun, 8 Feb 2009, Danny Braniss wrote:
> 
> >> On Sun, 8 Feb 2009, Danny Braniss wrote:
> >>
> >>> looking at the bce source, it's not clear (to me :-). If errors are 
> >>> detected in bce_rx_intr(), the packet gets dropped, which I would expect 
> >>> to be the treatment of an offloded chekcum error, but it seems that is not 
> >>> the case.
> >>
> >> I think we're thinking of different checksums -- devices/device drivers 
> >> drop frames with bad ethernet checksums, but not IP and above layer 
> >> checksums.
> >
> > I know I'm stepping on thin ice hear - haven't touched Stevens for a while, 
> > (and I doubt it mentions offloading), but if the offload checksum is bad, 
> > why not just drop the packet?
> >
> > The way I read the driver, if the offload checksum is on, and if no errors 
> > where detected, then it's marked as ok.
> 
> There are a few good reasons I can think of, but this is hardly a 
> comprehensive list:
> 
> (1) If there are bad higher level checksums on the wire, you want to see them
>      in tcpdump, so allow them to get up to a higher layer if network layer
>      checksums aren't good.
> 
> (2) It's a matter of local policy as to whether UDP checksums (for example)
>      are observed or not.
> 
> (3) If you're forwarding or bridging packets, it should be up to the end nodes
>      how they deal with bad UDP checksums on packets to them, not the routers.

ok, I can understand the logic.

> 
> Looking at if_bce.c, the following seems to be reasonable logic; first, 
> ethernet-layer checksums:
> 
> 5902                 /* Check the received frame for errors. */
> 5903                 if (status & (L2_FHDR_ERRORS_BAD_CRC |
> 5904                         L2_FHDR_ERRORS_PHY_DECODE | 
> L2_FHDR_ERRORS_ALIGNMENT |
> 5905                         L2_FHDR_ERRORS_TOO_SHORT  | 
> L2_FHDR_ERRORS_GIANT_FRAME)) {
> 5906
> 5907                         /* Log the error and release the mbuf. */
> 5908                         ifp->if_ierrors++;
> 5909                         DBRUN(sc->l2fhdr_status_errors++);
> 5910
> 5911                         m_freem(m0);
> 5912                         m0 = NULL;
> 5913                         goto bce_rx_int_next_rx;
> 5914                 }
> 
> I.e., if there are ethernet-level CRC failures, drop the packet.
> 
> 5922                 /* Validate the checksum if offload enabled. */
> 5923                 if (ifp->if_capenable & IFCAP_RXCSUM) {
> 5924
> 5925                         /* Check for an IP datagram. */
> 5926                         if (!(status & L2_FHDR_STATUS_SPLIT) &&
> 5927                                 (status & L2_FHDR_STATUS_IP_DATAGRAM)) {
> 5928                                 m0->m_pkthdr.csum_flags |= 
> CSUM_IP_CHECKED;
> 5929
> 5930                                 /* Check if the IP checksum is valid. */
> 5931                                 if ((l2fhdr->l2_fhdr_ip_xsum ^ 0xffff) == 
> 0)
> 5932                                         m0->m_pkthdr.csum_flags |= 
> CSUM_IP_VALID;
> 5933                         }
> 5934
> 5935                         /* Check for a valid TCP/UDP frame. */
> 5936                         if (status & (L2_FHDR_STATUS_TCP_SEGMENT |
> 5937                                 L2_FHDR_STATUS_UDP_DATAGRAM)) {
> 5938
> 5939                                 /* Check for a good TCP/UDP checksum. */
> 5940                                 if ((status & (L2_FHDR_ERRORS_TCP_XSUM |
> 5941                                               L2_FHDR_ERRORS_UDP_XSUM)) 
> == 0) {
> 5942                                         m0->m_pkthdr.csum_data =
> 5943                                             l2fhdr->l2_fhdr_tcp_udp_xsum;
> 5944                                         m0->m_pkthdr.csum_flags |= 
> (CSUM_DATA_VALID
> 5945                                                 | CSUM_PSEUDO_HDR);
> 5946                                 }
> 5947                         }
> 5948                 }
> 
> Only look at higher level checksums if policy enables it on the interface; 
> then, only if the hardware has a view on the IP-layer checksums, propagte that 
> information to the mbuf flags from the descriptor ring entry flags, both 
> whether or not the checksum was verified, and whether or not it was good.  If 
> policy disables it, or the hardware expresses no view, we don't set flags, 
> which simply defers checksumming to a higher layer (if required -- for 
> forwarded packets, we won't test UDP-layer checksums at all).

I missed line 5928, and as usual, your explanation is most educational!
The comment in line 5939 is a bit missleading, the way I read the code, it
does not check for good checksum.

Cheers,
	danny



From avg at icyb.net.ua  Mon Feb  9 05:21:59 2009
From: avg at icyb.net.ua (Andriy Gapon)
Date: Mon Feb  9 05:22:07 2009
Subject: nfs umount soft hang
In-Reply-To: <498AF8E1.7020206@icyb.net.ua>
References: <498AF8E1.7020206@icyb.net.ua>
Message-ID: <49902DF2.8050206@icyb.net.ua>

on 05/02/2009 16:34 Andriy Gapon said the following:
> I have an NFS server and NFS client separated by a firewall. Both
> servers are FreeBSD 7.1.
> 
> Server configuration:
> nfs_server_enable="YES"
> nfs_server_flags="-t -n 4"
> rpcbind_enable="YES"
> mountd_flags="-r -p 737"
> mountd_enable="YES"
> 
> The firewall allows tcp and udp to port 111, but only tcp to ports 2049
> and 737 (configured for mountd, see above).
> 
> On the client I use e.g. the following command for mounting:
> mount -t nfs -o nfsv3,tcp,intr,rdirplus,-r=32768,-w=32768
> XXXX:/export/usr/obj /usr/obj
> 
> Mounting and subsequent fs operations work flawlessly.
> 
> When I unmount umount command hangs but can be interrupted with ^C.
> Everything seems to be clean after that - the filesystem is unmounted,
> there are no post-effects on both client and server.

I think this is it:
377         /*
378          * Report to mountd-server which nfsname
379          * has been unmounted.
380          */
381         if (ai != NULL && !(fflag & MNT_FORCE) && do_rpc) {
382                 clp = clnt_create(hostp, RPCPROG_MNT, RPCMNT_VER1,
"udp");

I wonder if umount could be smarter as to whether use udp or tcp here.

-- 
Andriy Gapon
From bms at FreeBSD.org  Mon Feb  9 11:26:23 2009
From: bms at FreeBSD.org (Bruce M. Simpson)
Date: Mon Feb  9 11:26:30 2009
Subject: Unhappy Xorg upgrade
In-Reply-To: <1234159237.23838.3.camel@ferret.2hip.net>
References: <329181233306971@webmail57.yandex.ru>	
	<985A59F2-20CC-4779-A000-018E52B5BFA9@jump-ing.de>	
	<101781233319948@webmail36.yandex.ru>
	<4983A3AE.90804@FreeBSD.org>	 <498F901A.7000900@FreeBSD.org>
	<1234159237.23838.3.camel@ferret.2hip.net>
Message-ID: <4990835A.3020303@FreeBSD.org>

Robert,

First, thanks for all your dedicated work so far on the Xorg ports.

I realize this upgrade has been somewhat fraught with unexpected issues.

FWIW, things are not greener on the Linux side of the fence; many Ubuntu 
and Debian users have reported issues with the newer Xorg and in 
particular hald.

Robert Noland wrote:
> ...
>> I still see the USB symptoms with xorg-server port as of today -- forced 
>> rebuild with libpciaccess also. So amd64 is still regressed -- USB is 
>> totally unusable there after X is started. My theory was that somehow 
>> Xorg was stomping on the USB controller registers on this machine. The 
>> USB controller on this box is ALi, card=0x81561043.
>>     
>
> Is your usb sharing interrupts with the video card?
>   

Yes, it appears so. This is an ASUS Vintage AH-1, uniprocessor amd64 box 
w/ioapic enabled

from devinfo -r (abbreviated):
ohci0 17
ohci1 18
ohci2 19
ehci0 23

lspci -v jibes with devinfo -r -- the primary head got IRQ 18, the 
secondary IRQ 255.

It appears msk0 is also sharing IRQ 18, though I haven't seen any 
problems with networking; mskc0, however, is then configured to use MSI 
(pseudo IRQ 256, 258), it is a PCI-e device.

When the system starts, the drm module has not been loaded, so the 
Radeon (Sapphire X550) card hasn't been allocated its IRQ by FreeBSD.

After X starts, glxinfo and glxgers work fine. kldstat reports drm.ko 
and radeon.ko got loaded by X as I would expect. I still see no IRQ 
allocated for the radeon, either in dmesg output or in devinfo -r, 
however, vmstat -i does show drm0 as sharing IRQ 18.

At this point, I rebooted and tried manually resetting the BIOS ESCD 
table, unfortunately the BIOS on this machine won't let me tie IRQs down 
to particular devices.


> Does the issue occur if you aren't using a usb mouse?
>   

I see the USB problems regardless of the kind of USB devices plugged in, 
I continue to use a PS/2 mouse on the desktop as a workaround.

I see the bump on devel/libpciaccess re typo of rombase, and forced a 
rebuild of xorg-server against the patched libpciaccess library 
(probably not needed, as the .so ABI didn't change).

The USB problem is still present, unfortunately.

thanks,
BMS

From rnoland at FreeBSD.org  Mon Feb  9 11:43:19 2009
From: rnoland at FreeBSD.org (Robert Noland)
Date: Mon Feb  9 11:43:26 2009
Subject: Unhappy Xorg upgrade
In-Reply-To: <4990835A.3020303@FreeBSD.org>
References: <329181233306971@webmail57.yandex.ru>
	<985A59F2-20CC-4779-A000-018E52B5BFA9@jump-ing.de>
	<101781233319948@webmail36.yandex.ru> <4983A3AE.90804@FreeBSD.org>
	<498F901A.7000900@FreeBSD.org>
	<1234159237.23838.3.camel@ferret.2hip.net>
	<4990835A.3020303@FreeBSD.org>
Message-ID: <1234208586.1524.17.camel@ferret.2hip.net>

On Mon, 2009-02-09 at 19:26 +0000, Bruce M. Simpson wrote:
> Robert,
> 
> First, thanks for all your dedicated work so far on the Xorg ports.
> 
> I realize this upgrade has been somewhat fraught with unexpected issues.
> 
> FWIW, things are not greener on the Linux side of the fence; many Ubuntu 
> and Debian users have reported issues with the newer Xorg and in 
> particular hald.
> 
> Robert Noland wrote:
> > ...
> >> I still see the USB symptoms with xorg-server port as of today -- forced 
> >> rebuild with libpciaccess also. So amd64 is still regressed -- USB is 
> >> totally unusable there after X is started. My theory was that somehow 
> >> Xorg was stomping on the USB controller registers on this machine. The 
> >> USB controller on this box is ALi, card=0x81561043.
> >>     
> >
> > Is your usb sharing interrupts with the video card?
> >   
> 
> Yes, it appears so. This is an ASUS Vintage AH-1, uniprocessor amd64 box 
> w/ioapic enabled
> 
> from devinfo -r (abbreviated):
> ohci0 17
> ohci1 18
> ohci2 19
> ehci0 23
> 
> lspci -v jibes with devinfo -r -- the primary head got IRQ 18, the 
> secondary IRQ 255.
> 
> It appears msk0 is also sharing IRQ 18, though I haven't seen any 
> problems with networking; mskc0, however, is then configured to use MSI 
> (pseudo IRQ 256, 258), it is a PCI-e device.
> 
> When the system starts, the drm module has not been loaded, so the 
> Radeon (Sapphire X550) card hasn't been allocated its IRQ by FreeBSD.
> 
> After X starts, glxinfo and glxgers work fine. kldstat reports drm.ko 
> and radeon.ko got loaded by X as I would expect. I still see no IRQ 
> allocated for the radeon, either in dmesg output or in devinfo -r, 
> however, vmstat -i does show drm0 as sharing IRQ 18.

Ok, that is odd... Once drm is loaded and X opens it, the ddx driver
should request that the irq handler be installed.  At that point, dmesg
should show something resembling the following.

vgapci0: child drm0 requested pci_enable_busmaster
info: [drm] AGP at 0xc0000000 256MB
info: [drm] Initialized i915 1.6.0 20080730
drm0: [ITHREAD]

I have code to enable msi for drm, which has been at least minimally
tested on intel and ati.  FWIW, linux does not support msi on radeon
yet, so I got the jump on them there... The outstanding issue with that
code is that I still need to implement a blacklist for certain devices
that report msi capability, but don't (intel 945gm, is the only known
chip atm).

Does the issue still occur if drm is disabled?

robert.

> At this point, I rebooted and tried manually resetting the BIOS ESCD 
> table, unfortunately the BIOS on this machine won't let me tie IRQs down 
> to particular devices.
> 
> 
> > Does the issue occur if you aren't using a usb mouse?
> >   
> 
> I see the USB problems regardless of the kind of USB devices plugged in, 
> I continue to use a PS/2 mouse on the desktop as a workaround.
> 
> I see the bump on devel/libpciaccess re typo of rombase, and forced a 
> rebuild of xorg-server against the patched libpciaccess library 
> (probably not needed, as the .so ABI didn't change).
> 
> The USB problem is still present, unfortunately.
> 
> thanks,
> BMS
> 
> _______________________________________________
> 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/20090209/57a51a65/attachment.pgp
From serguey-grigoriev at yandex.ru  Mon Feb  9 11:53:04 2009
From: serguey-grigoriev at yandex.ru (S.N.Grigoriev)
Date: Mon Feb  9 11:53:13 2009
Subject: Unhappy Xorg upgrade
In-Reply-To: <1234159237.23838.3.camel@ferret.2hip.net>
References: <329181233306971@webmail57.yandex.ru>
	<985A59F2-20CC-4779-A000-018E52B5BFA9@jump-ing.de>
	<101781233319948@webmail36.yandex.ru>
	<4983A3AE.90804@FreeBSD.org> <498F901A.7000900@FreeBSD.org>
	<1234159237.23838.3.camel@ferret.2hip.net>
Message-ID: <406921234209180@webmail60.yandex.ru>


09.02.09, 09:00, "Robert Noland" <rnoland@FreeBSD.org>:

> On Mon, 2009-02-09 at 02:08 +0000, Bruce M. Simpson wrote:
> > Bruce M. Simpson wrote:
> > > S.N.Grigoriev wrote:
> > >> I thank you for your response. I've applied the patch to pci.c from
> > >> kern/130957. Unfortunately there are no positive results. USB is still
> > >> unreachable with X.
> > >
> > > Just following up to confirm that you are seeing exactly the same 
> > > symptoms with USB and Xorg 7.4 as I see on my amd64 desktop running 
> > > 7-STABLE from 00:00 UTC on this Wednesday.
> > 
> > I still see the USB symptoms with xorg-server port as of today -- forced 
> > rebuild with libpciaccess also. So amd64 is still regressed -- USB is 
> > totally unusable there after X is started. My theory was that somehow 
> > Xorg was stomping on the USB controller registers on this machine. The 
> > USB controller on this box is ALi, card=0x81561043.

> Is your usb sharing interrupts with the video card?
Yes, it is. This is from dmesg output:
ohci2: <OHCI (generic) USB controller> mem 0xfe02c000-0xfe02cfff irq 18 at device 19.2 on pci0
vgapci0: <VGA-compatible display> port 0xde00-0xdeff mem 0xd0000000-0xdfffffff,
0xfdee0000-0xfdeeffff irq 18 at device 0.0 on pci1

> Does the issue occur if you aren't using a usb mouse?
I'm not using a USB mouse. My mouse is PS/2.

-- 
Regards,
S.Grigoriev.
From kostikbel at gmail.com  Mon Feb  9 13:48:29 2009
From: kostikbel at gmail.com (Kostik Belousov)
Date: Mon Feb  9 13:48:39 2009
Subject: sysctl lock in RELENG_6
In-Reply-To: <498FAA2A.7423AC15@kuzbass.ru>
References: <498FAA2A.7423AC15@kuzbass.ru>
Message-ID: <20090209214822.GH9427@deviant.kiev.zoral.com.ua>

On Mon, Feb 09, 2009 at 10:59:38AM +0700, Eugene Grosbein wrote:
> Hi!
> 
> I've RELENG_6 system controlling local PBX through RS-232 port, sio(4).
> It also runs syslogd, cron, sshd, bsnmpd and sendmail for outgoing reports.
> 
> It locks very often: it answers to pings but PBX controlling software stops
> responding, local and remote login attempts hang due to 'login' process
> stuck in 'sysctl lock' state. Local consoles do switch with 'Alt-Fn'
> and DDB works. It shows that sendmail is in 'sysctl lock' state too.
> 
> This is NanoBSD installation running from IDE flash, it's swapless
> but I think I could manage to obtain crashdump if there is an interest of it.
> 
> I've digged commit logs a bit and found this change MFC'd to RELENG_7
> but not RELENG_6:
> 
> http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/kern/kern_sysctl.c#rev1.177.6.2
> 
> It seems RELENG_6 needs this too, doesn't it?
> I'm going to merge the change to RELENG_6 and give it a try.

Yes, please give it a try. In fact, it was quite specific situation
that I observed and produced a fix for. You need execing process that
needs to grab Giant, e.g. due to image being located on !MPSAFE fs, and
simultaneous sysctl issued that inspects this process.

-------------- 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/20090209/a879c297/attachment.pgp
From bms at FreeBSD.org  Mon Feb  9 15:32:15 2009
From: bms at FreeBSD.org (Bruce M. Simpson)
Date: Mon Feb  9 15:40:10 2009
Subject: Unhappy Xorg upgrade
In-Reply-To: <1234208586.1524.17.camel@ferret.2hip.net>
References: <329181233306971@webmail57.yandex.ru>	
	<985A59F2-20CC-4779-A000-018E52B5BFA9@jump-ing.de>	
	<101781233319948@webmail36.yandex.ru>
	<4983A3AE.90804@FreeBSD.org>	 <498F901A.7000900@FreeBSD.org>
	<1234159237.23838.3.camel@ferret.2hip.net>	
	<4990835A.3020303@FreeBSD.org>
	<1234208586.1524.17.camel@ferret.2hip.net>
Message-ID: <4990BC99.1070108@FreeBSD.org>

Robert Noland wrote:
> ...
> Ok, that is odd... Once drm is loaded and X opens it, the ddx driver
> should request that the irq handler be installed.  At that point, dmesg
> should show something resembling the following.
>
> vgapci0: child drm0 requested pci_enable_busmaster
> info: [drm] AGP at 0xc0000000 256MB
> info: [drm] Initialized i915 1.6.0 20080730
> drm0: [ITHREAD]
>   

Yes, I normally see output similar to this when X is started.

> ...
>
> Does the issue still occur if drm is disabled?
>   

Just tried disabling DRM w/ 'Options "DRI" "off"' in Section "Device".
DRM is indeed disabled -- no dmesg output and not loaded by X.

However the problem is still there.

BTW: This Radeon card does have MSI capabilities according to lspci, 
however they do not appear to be enabled either by FreeBSD or by X. I 
was about to point the finger at interrupt filters, however that blows 
that theory out of the water.

FWIW the IBM T43 here has an i915GM, and USB is working just fine and 
dandy. The main data point which sticks out is the fact that the 
affected machine is amd64.

Now that DRM has been disabled on my box, this would point the finger at 
the X userland.

I don't see any obvious nasties in my Section "Device", although I do 
pass a BusID and BusType to prevent X from trying to use the second head 
with RandR (lots of pain with fubar DVI cables when I first purchased 
the monitor).

I skimmed pci_user.c, thinking libpciaccess just thunks to it via 
/dev/pci, it appears there's no instrumentation there I can turn on to 
see what userland is actually frobbing.

thanks,
BMS
From Mark_Andrews at isc.org  Mon Feb  9 15:54:19 2009
From: Mark_Andrews at isc.org (Mark Andrews)
Date: Mon Feb  9 16:00:45 2009
Subject: http://www.freebsd.org/doc/handbook/desktop-browsers.html
Message-ID: <200902092354.n19Ns6xR027201@drugs.dv.isc.org>


	Can the instructions for adding a java pluging please be
	updated to something that works as what's there doesn't
	work for Firefox 3.

	javavmwrapper-2.3.2 is installed.

% ls -l /usr/local/lib/browser_plugins/
total 0
lrwxr-xr-x  1 root  wheel  67 Feb  8 10:38 libjavaplugin_oji.so -> /usr/local/diablo-jdk1.6.0/jre/plugin/i386/ns7/libjavaplugin_oji.so
% ls -lL /usr/local/lib/browser_plugins/
total 188
-rwxr-xr-x  1 root  wheel  191059 Jun 18  2008 libjavaplugin_oji.so
% 

	Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE:	+61 2 9871 4742		         INTERNET: Mark_Andrews@isc.org
From eugen at kuzbass.ru  Mon Feb  9 20:01:29 2009
From: eugen at kuzbass.ru (Eugene Grosbein)
Date: Mon Feb  9 20:01:37 2009
Subject: sysctl lock in RELENG_6
In-Reply-To: <20090209214822.GH9427@deviant.kiev.zoral.com.ua>
References: <498FAA2A.7423AC15@kuzbass.ru>
	<20090209214822.GH9427@deviant.kiev.zoral.com.ua>
Message-ID: <20090210040125.GA80054@svzserv.kemerovo.su>

On Mon, Feb 09, 2009 at 11:48:22PM +0200, Kostik Belousov wrote:

> > I've digged commit logs a bit and found this change MFC'd to RELENG_7
> > but not RELENG_6:
> > 
> > http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/kern/kern_sysctl.c#rev1.177.6.2
> > 
> > It seems RELENG_6 needs this too, doesn't it?
> > I'm going to merge the change to RELENG_6 and give it a try.
> 
> Yes, please give it a try. In fact, it was quite specific situation
> that I observed and produced a fix for. You need execing process that
> needs to grab Giant, e.g. due to image being located on !MPSAFE fs, and
> simultaneous sysctl issued that inspects this process.

Well, my 6.3-STABLE locked very often (sometimes every hour).
Yesterday I've upgraded it to 6.4-STABLE, applied 1.177.2.1 of the file
to sources, rebuilt NanoBSD image and ran it. It has not locked yet.

Btw, root filesystem here is UFS2 without softupdates mounted read-only
but /etc and /var are md(4) (devfs is mounted too).

Eugene Grosbein
From matheus at eternamente.info  Mon Feb  9 20:12:36 2009
From: matheus at eternamente.info (Nenhum_de_Nos)
Date: Mon Feb  9 20:12:42 2009
Subject: ADMtek USB To LAN Converter
Message-ID: <92e52b8953009d1d0afd2b6e7cd09654.squirrel@10.1.1.10>

hail,

I have two of these and cant make them ping. module loads ok, ifconfig
sees ok, but cant send any data. tcpdump can get info though.


aue0: <ADMtek USB To LAN Converter, class 255/0, rev 1.10/2.01, addr 2> on
uhub1
miibus3: <MII bus> on aue0
ukphy1: <Generic IEEE 802.3u media interface> PHY 1 on miibus3
ukphy1:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
aue0: Ethernet address: 00:60:6e:00:05:d2
aue0: link state changed to DOWN
aue0: link state changed to UP
aue0: usb error on rx: IOERROR

FreeBSD xxx 7.1-PRERELEASE FreeBSD 7.1-PRERELEASE #2: Tue Dec 30 00:41:39
BRT 2008     root@xxx:/usr/obj/usr/src/sys/xxx  i386

if anyone has any clues,

thanks,

matheus

ps: sorry for posting to usb@ and stable@, but I saw no message in usb@.

-- 
We will call you cygnus,
The God of balance you shall be

From rnoland at FreeBSD.org  Mon Feb  9 22:07:25 2009
From: rnoland at FreeBSD.org (Robert Noland)
Date: Mon Feb  9 22:07:34 2009
Subject: Unhappy Xorg upgrade
In-Reply-To: <4990BC99.1070108@FreeBSD.org>
References: <329181233306971@webmail57.yandex.ru>
	<985A59F2-20CC-4779-A000-018E52B5BFA9@jump-ing.de>
	<101781233319948@webmail36.yandex.ru> <4983A3AE.90804@FreeBSD.org>
	<498F901A.7000900@FreeBSD.org>
	<1234159237.23838.3.camel@ferret.2hip.net>
	<4990835A.3020303@FreeBSD.org>
	<1234208586.1524.17.camel@ferret.2hip.net>
	<4990BC99.1070108@FreeBSD.org>
Message-ID: <1234246034.1524.27.camel@ferret.2hip.net>

On Mon, 2009-02-09 at 23:30 +0000, Bruce M. Simpson wrote:
> Robert Noland wrote:
> > ...
> > Ok, that is odd... Once drm is loaded and X opens it, the ddx driver
> > should request that the irq handler be installed.  At that point, dmesg
> > should show something resembling the following.
> >
> > vgapci0: child drm0 requested pci_enable_busmaster
> > info: [drm] AGP at 0xc0000000 256MB
> > info: [drm] Initialized i915 1.6.0 20080730
> > drm0: [ITHREAD]
> >   
> 
> Yes, I normally see output similar to this when X is started.
> 
> > ...
> >
> > Does the issue still occur if drm is disabled?
> >   
> 
> Just tried disabling DRM w/ 'Options "DRI" "off"' in Section "Device".
> DRM is indeed disabled -- no dmesg output and not loaded by X.
> 
> However the problem is still there.
> 
> BTW: This Radeon card does have MSI capabilities according to lspci, 
> however they do not appear to be enabled either by FreeBSD or by X. I 
> was about to point the finger at interrupt filters, however that blows 
> that theory out of the water.
> 
> FWIW the IBM T43 here has an i915GM, and USB is working just fine and 
> dandy. The main data point which sticks out is the fact that the 
> affected machine is amd64.
> 
> Now that DRM has been disabled on my box, this would point the finger at 
> the X userland.
> 
> I don't see any obvious nasties in my Section "Device", although I do 
> pass a BusID and BusType to prevent X from trying to use the second head 
> with RandR (lots of pain with fubar DVI cables when I first purchased 
> the monitor).
> 
> I skimmed pci_user.c, thinking libpciaccess just thunks to it via 
> /dev/pci, it appears there's no instrumentation there I can turn on to 
> see what userland is actually frobbing.

Ok, lets try another test...  There is a scanpci util in the
libpciaccess port.  We don't install it, but it does get built.  Build
the port and run scanpci -v as root from the console.  That should poke
all the pci devices on the box and tell you about them.  See if that is
able to trigger the issue.

robert.

> thanks,
> BMS
> _______________________________________________
> 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/20090210/8388933a/attachment.pgp
From kostikbel at gmail.com  Mon Feb  9 22:28:02 2009
From: kostikbel at gmail.com (Kostik Belousov)
Date: Mon Feb  9 22:28:09 2009
Subject: sysctl lock in RELENG_6
In-Reply-To: <20090210040125.GA80054@svzserv.kemerovo.su>
References: <498FAA2A.7423AC15@kuzbass.ru>
	<20090209214822.GH9427@deviant.kiev.zoral.com.ua>
	<20090210040125.GA80054@svzserv.kemerovo.su>
Message-ID: <20090210062757.GK9427@deviant.kiev.zoral.com.ua>

On Tue, Feb 10, 2009 at 11:01:25AM +0700, Eugene Grosbein wrote:
> On Mon, Feb 09, 2009 at 11:48:22PM +0200, Kostik Belousov wrote:
> 
> > > I've digged commit logs a bit and found this change MFC'd to RELENG_7
> > > but not RELENG_6:
> > > 
> > > http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/kern/kern_sysctl.c#rev1.177.6.2
> > > 
> > > It seems RELENG_6 needs this too, doesn't it?
> > > I'm going to merge the change to RELENG_6 and give it a try.
> > 
> > Yes, please give it a try. In fact, it was quite specific situation
> > that I observed and produced a fix for. You need execing process that
> > needs to grab Giant, e.g. due to image being located on !MPSAFE fs, and
> > simultaneous sysctl issued that inspects this process.
> 
> Well, my 6.3-STABLE locked very often (sometimes every hour).
> Yesterday I've upgraded it to 6.4-STABLE, applied 1.177.2.1 of the file
> to sources, rebuilt NanoBSD image and ran it. It has not locked yet.
Can you be slightly more scientific in your tests ?
Try RELENG_6 without my patch to see whether it is needed at all.

> 
> Btw, root filesystem here is UFS2 without softupdates mounted read-only
> but /etc and /var are md(4) (devfs is mounted too).
> 
> Eugene Grosbein
-------------- 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/20090210/5d1a0480/attachment.pgp
From horst at sxemacs.org  Tue Feb 10 01:51:22 2009
From: horst at sxemacs.org (Horst =?ISO-8859-1?Q?G=FCnther?= Burkhardt III)
Date: Tue Feb 10 01:51:30 2009
Subject: [7-STABLE] failure during buildworld
Message-ID: <1234258680.13304.26.camel@horst-tla>

Hey everybody :) 

I'm having a small issue compiling 7-STABLE as checked out 24 hours ago
at the time of writing... during make -j4 buildworld, this error
occurs: 

===> lib/bind (install)
===> lib/bind/bind (install)
===> lib/bind/bind9 (install)
===> lib/bind/dns (install)
===> lib/bind/isc (install)
===> lib/bind/isccc (install)
===> lib/bind/isccfg (install)
===> lib/bind/lwres (install)
sh /usr/src/tools/install.sh -C -o root -g wheel -m 444
liblwres.a /usr/obj/usr/src/tmp/usr/lib
sh /usr/src/tools/install.sh -C -o root -g wheel -m
444  /usr/src/lib/bind/lwres/../../../contrib/bind9/lib/lwres/include/lwres/context.h /usr/src/lib/bind/lwres/../../../contrib/bind9/lib/lwres/include/lwres/int.h /usr/src/lib/bind/lwres/../../../contrib/bind9/lib/lwres/include/lwres/ipv6.h /usr/src/lib/bind/lwres/../../../contrib/bind9/lib/lwres/include/lwres/lang.h /usr/src/lib/bind/lwres/../../../contrib/bind9/lib/lwres/include/lwres/list.h /usr/src/lib/bind/lwres/../../../contrib/bind9/lib/lwres/include/lwres/lwbuffer.h /usr/src/lib/bind/lwres/../../../contrib/bind9/lib/lwres/include/lwres/lwpacket.h /usr/src/lib/bind/lwres/../../../contrib/bind9/lib/lwres/include/lwres/lwres.h /usr/src/lib/bind/lwres/../../../contrib/bind9/lib/lwres/include/lwres/result.h /usr/src/lib/bind/lwres/../../../contrib/bind9/lib/lwres/include/lwres/version.h /usr/src/lib/bind/lwres/../../../contrib/bind9/lib/lwres/unix/include/lwres/net.h /usr/src/lib/bind/lwres/lwres/netdb.h /usr/src/lib/bind/lwres/lwres/platform.h /usr/obj/usr/src/tmp/usr/include/lwres
sh /usr/src/tools/install.sh -s -o root -g wheel -m 444
liblwres.so.30 /usr/obj/usr/src/tmp/usr/lib
ln -fs liblwres.so.30 /usr/obj/usr/src/tmp/usr/lib/liblwres.so
1 error
*** Error code 2
1 error
*** Error code 2
1 error
*** Error code 2
1 error
[ bsdbox ] [ root ] [ /usr/src ] ==> 


lwres appears to compile cleanly. It would appear that the error is
related to ln - and I don't know how to fix it. 

(also, why doesn't make buildworld pick up from where it left off?) 

Thanks kindly,
-- Horst.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20090210/9b7eedd2/attachment.pgp
From patfbsd at davenulle.org  Tue Feb 10 04:44:24 2009
From: patfbsd at davenulle.org (Patrick =?ISO-8859-15?Q?Lamaizi=E8re?=)
Date: Tue Feb 10 04:44:31 2009
Subject: Backport of glxsb(4) to RELENG_6
Message-ID: <20090210134421.350f40b8@baby-jane.lamaiziere.net>

Hi,

I've backported the glxsb(4) driver to RELENG_6 (to use it on FreeNAS by
instance).

http://user.lamaiziere.net/patrick/glxsb-6-100209.tar.gz

I am not able to test it, but I hope it will work.

You can test with openssl:

openssl enc -e -aes-128-cbc -in file -out file.enc -k abcdefgh -nosalt
-engine cryptodev

Please tell me if it works or not.
Regards.
From lme at FreeBSD.org  Tue Feb 10 05:14:15 2009
From: lme at FreeBSD.org (Lars Engels)
Date: Tue Feb 10 05:14:24 2009
Subject: Backport of glxsb(4) to RELENG_6
In-Reply-To: <20090210134421.350f40b8@baby-jane.lamaiziere.net>
References: <20090210134421.350f40b8@baby-jane.lamaiziere.net>
Message-ID: <20090210141414.2fq37wzlvggcggks@0x20.net>

Quoting Patrick Lamaizi?re <patfbsd@davenulle.org>:

> Hi,
>
> I've backported the glxsb(4) driver to RELENG_6 (to use it on FreeNAS by
> instance).
>
> http://user.lamaiziere.net/patrick/glxsb-6-100209.tar.gz
>
> I am not able to test it, but I hope it will work.
>
> You can test with openssl:
>
> openssl enc -e -aes-128-cbc -in file -out file.enc -k abcdefgh -nosalt
> -engine cryptodev
>


Hi Patrick!

Great, thanks a lot for this backport. I'll try it this evening on my  
Alix-based FreeNAS.

Lars
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 195 bytes
Desc: Digitale PGP-Unterschrift
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20090210/cda3ab7a/attachment.pgp
From bms at FreeBSD.org  Tue Feb 10 09:57:46 2009
From: bms at FreeBSD.org (Bruce M. Simpson)
Date: Tue Feb 10 09:57:54 2009
Subject: Unhappy Xorg upgrade
In-Reply-To: <1234246034.1524.27.camel@ferret.2hip.net>
References: <329181233306971@webmail57.yandex.ru>	
	<985A59F2-20CC-4779-A000-018E52B5BFA9@jump-ing.de>	
	<101781233319948@webmail36.yandex.ru>
	<4983A3AE.90804@FreeBSD.org>	 <498F901A.7000900@FreeBSD.org>
	<1234159237.23838.3.camel@ferret.2hip.net>	
	<4990835A.3020303@FreeBSD.org>
	<1234208586.1524.17.camel@ferret.2hip.net>	
	<4990BC99.1070108@FreeBSD.org>
	<1234246034.1524.27.camel@ferret.2hip.net>
Message-ID: <4991C017.8080903@FreeBSD.org>

Robert Noland wrote:
> ...
> Ok, lets try another test...  There is a scanpci util in the
> libpciaccess port.  We don't install it, but it does get built.  Build
> the port and run scanpci -v as root from the console.  That should poke
> all the pci devices on the box and tell you about them.  See if that is
> able to trigger the issue.
>   

Well spotted. I saw this tool in "locate" output and was going to try it 
the other day, although I saw it didn't get installed, so assumed it was 
historical.

Yes, This immediately triggered the issue without even running X on a 
fresh boot.
From bms at FreeBSD.org  Tue Feb 10 10:08:14 2009
From: bms at FreeBSD.org (Bruce M. Simpson)
Date: Tue Feb 10 10:08:40 2009
Subject: Unhappy Xorg upgrade
In-Reply-To: <4991C017.8080903@FreeBSD.org>
References: <329181233306971@webmail57.yandex.ru>		<985A59F2-20CC-4779-A000-018E52B5BFA9@jump-ing.de>		<101781233319948@webmail36.yandex.ru>	<4983A3AE.90804@FreeBSD.org>	
	<498F901A.7000900@FreeBSD.org>	<1234159237.23838.3.camel@ferret.2hip.net>		<4990835A.3020303@FreeBSD.org>	<1234208586.1524.17.camel@ferret.2hip.net>		<4990BC99.1070108@FreeBSD.org>	<1234246034.1524.27.camel@ferret.2hip.net>
	<4991C017.8080903@FreeBSD.org>
Message-ID: <4991C287.708@FreeBSD.org>

Robert,

Bruce M. Simpson wrote:
> Yes, This immediately triggered the issue without even running X on a 
> fresh boot.
>

I'm going to post the following:

 * output of pciconf -lv, lspci -vv before scanpci is/was run
 * output of scanpci -v
 * output of pciconf -lv, lspci -vv after scanpci is/was run

...using script(1), and also the usbdevs -v output when the issue occurs.

I've ran lspci (from ports/sysutils/pciutils) before without triggering 
the issue, of course it doesn't use libpciaccess.

The fact that scanpci triggered the issue on its own would seem to point 
the finger squarely at libpciaccess.

Additional data point: I have 'hide inactive PCI-e p2p bridge devices' 
disabled in my BIOS, although none of the affected devices are behind a 
PCI-e bridge.
There is some sort of custom bus between the ATI northbridge and ALi 
southbridge which ain't PCI itself.


-------------- next part --------------
Script started on Tue Feb 10 18:05:18 2009
You have mail.
anglepoise# pciconf -lv

hostb0@pci0:0:0:0:	class=0x060000 card=0x81851043 chip=0x59501002 rev=0x10 hdr=0x00
    vendor     = 'ATI Technologies Inc'
    device     = 'RS480 Host Bridge'
    class      = bridge
    subclass   = HOST-PCI
pcib1@pci0:0:2:0:	class=0x060400 card=0x59501002 chip=0x5a341002 rev=0x00 hdr=0x01
    vendor     = 'ATI Technologies Inc'
    device     = 'RS480 PCI-X Root Port'
    class      = bridge
    subclass   = PCI-PCI
pcib2@pci0:0:6:0:	class=0x060400 card=0x59501002 chip=0x5a381002 rev=0x00 hdr=0x01
    vendor     = 'ATI Technologies Inc'
    device     = 'RS480 PCI Bridge'
    class      = bridge
    subclass   = PCI-PCI
pcib3@pci0:0:7:0:	class=0x060400 card=0x59501002 chip=0x5a391002 rev=0x00 hdr=0x01
    vendor     = 'ATI Technologies Inc'
    device     = 'RS480 PCI Bridge'
    class      = bridge
    subclass   = PCI-PCI
hostb1@pci0:0:24:0:	class=0x060000 card=0x00000000 chip=0x11001022 rev=0x00 hdr=0x00
    vendor     = 'Advanced Micro Devices (AMD)'
    device     = '(K8) Athlon 64/Opteron HyperTransport Technology Configuration'
    class      = bridge
    subclass   = HOST-PCI
hostb2@pci0:0:24:1:	class=0x060000 card=0x00000000 chip=0x11011022 rev=0x00 hdr=0x00
    vendor     = 'Advanced Micro Devices (AMD)'
    device     = '(K8) Athlon 64/Opteron Address Map'
    class      = bridge
    subclass   = HOST-PCI
hostb3@pci0:0:24:2:	class=0x060000 card=0x00000000 chip=0x11021022 rev=0x00 hdr=0x00
    vendor     = 'Advanced Micro Devices (AMD)'
    device     = '(K8) Athlon 64/Opteron DRAM Controller'
    class      = bridge
    subclass   = HOST-PCI
hostb4@pci0:0:24:3:	class=0x060000 card=0x00000000 chip=0x11031022 rev=0x00 hdr=0x00
    vendor     = 'Advanced Micro Devices (AMD)'
    device     = '(K8) Athlon 64/Opteron Miscellaneous Control'
    class      = bridge
    subclass   = HOST-PCI
pcib4@pci0:0:25:0:	class=0x060400 card=0x00000000 chip=0x524910b9 rev=0x00 hdr=0x01
    vendor     = 'Acer Labs Incorporated (ALi/ULi)'
    device     = 'M5249 HyperTransport to PCI Bridge'
    class      = bridge
    subclass   = PCI-PCI
ohci0@pci0:0:28:0:	class=0x0c0310 card=0x81561043 chip=0x523710b9 rev=0x03 hdr=0x00
    vendor     = 'Acer Labs Incorporated (ALi/ULi)'
    device     = 'M5273 A1 for windows win 98 OpenHCI 1.1 USB to  2.0'
    class      = serial bus
    subclass   = USB
ohci1@pci0:0:28:1:	class=0x0c0310 card=0x81561043 chip=0x523710b9 rev=0x03 hdr=0x00
    vendor     = 'Acer Labs Incorporated (ALi/ULi)'
    device     = 'M5273 A1 for windows win 98 OpenHCI 1.1 USB to  2.0'
    class      = serial bus
    subclass   = USB
ohci2@pci0:0:28:2:	class=0x0c0310 card=0x81561043 chip=0x523710b9 rev=0x03 hdr=0x00
    vendor     = 'Acer Labs Incorporated (ALi/ULi)'
    device     = 'M5273 A1 for windows win 98 OpenHCI 1.1 USB to  2.0'
    class      = serial bus
    subclass   = USB
ehci0@pci0:0:28:3:	class=0x0c0320 card=0x81561043 chip=0x523910b9 rev=0x01 hdr=0x00
    vendor     = 'Acer Labs Incorporated (ALi/ULi)'
    device     = 'USB 2.0 Enhanced Host Controller'
    class      = serial bus
    subclass   = USB
hdac0@pci0:0:29:0:	class=0x040300 card=0x81b41043 chip=0x546110b9 rev=0x00 hdr=0x00
    vendor     = 'Acer Labs Incorporated (ALi/ULi)'
    device     = '?? Microsoft UAA Bus Driver for High Definition Audio'
    class      = multimedia
    subclass   = HDA
isab0@pci0:0:30:0:	class=0x060100 card=0x81561043 chip=0x157310b9 rev=0x31 hdr=0x00
    vendor     = 'Acer Labs Incorporated (ALi/ULi)'
    device     = 'ALI M1573 South Bridge with Hypertransport Support'
    class      = bridge
    subclass   = PCI-ISA
none0@pci0:0:30:1:	class=0x068000 card=0x81561043 chip=0x710110b9 rev=0x00 hdr=0x00
    vendor     = 'Acer Labs Incorporated (ALi/ULi)'
    device     = 'ALI M7101 Power Management Controller'
    class      = bridge
atapci0@pci0:0:31:0:	class=0x01018a card=0x81561043 chip=0x522910b9 rev=0xc7 hdr=0x00
    vendor     = 'Acer Labs Incorporated (ALi/ULi)'
    device     = 'M5229 Southbridge EIDE Controller'
    class      = mass storage
    subclass   = ATA
atapci1@pci0:0:31:1:	class=0x010400 card=0x81561043 chip=0x528710b9 rev=0x02 hdr=0x00
    vendor     = 'Acer Labs Incorporated (ALi/ULi)'
    device     = '52871849 ALI SATA controller'
    class      = mass storage
    subclass   = RAID
vgapci0@pci0:1:0:0:	class=0x030000 card=0x3000174b chip=0x5b631002 rev=0x00 hdr=0x00
    vendor     = 'ATI Technologies Inc'
    device     = 'Radeon X550 Series'
    class      = display
    subclass   = VGA
vgapci1@pci0:1:0:1:	class=0x038000 card=0x3001174b chip=0x5b731002 rev=0x00 hdr=0x00
    vendor     = 'ATI Technologies Inc'
    device     = 'Radeon X550 Series - Secondary'
    class      = display
mskc0@pci0:2:0:0:	class=0x020000 card=0x81421043 chip=0x436211ab rev=0x19 hdr=0x00
    vendor     = 'Marvell Semiconductor (Was: Galileo Technology Ltd)'
    device     = '88E8053 Marvell Yukon 88E8053 PCI-E Gigabit Ethernet Controller'
    class      = network
    subclass   = ethernet
none1@pci0:4:18:0:	class=0x0c0010 card=0x808a1043 chip=0x30441106 rev=0x80 hdr=0x00
    vendor     = 'VIA Technologies Inc'
    device     = 'VT6306 VIA Fire II IEEE-1394 OHCI Link Layer Controller'
    class      = serial bus
    subclass   = FireWire
anglepoise# lspci -vv

00:00.0 Host bridge: ATI Technologies Inc RS480 Host Bridge (rev 10)
	Subsystem: ASUSTeK Computer Inc. Device 8185
	Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
	Status: Cap- 66MHz+ UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort+ >SERR- <PERR- INTx-
	Latency: 0

00:02.0 PCI bridge: ATI Technologies Inc RS480 PCI-X Root Port (prog-if 00 [Normal decode])
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx-
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0, Cache Line Size: 64 bytes
	Bus: primary=00, secondary=01, subordinate=01, sec-latency=0
	I/O behind bridge: 0000b000-0000bfff
	Memory behind bridge: fe000000-fe8fffff
	Prefetchable memory behind bridge: 00000000cff00000-00000000dfefffff
	Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort+ <SERR- <PERR-
	BridgeCtl: Parity+ SERR+ NoISA- VGA+ MAbort- >Reset- FastB2B-
		PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
	Capabilities: [50] Power Management version 3
		Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
		Status: D0 PME-Enable- DSel=0 DScale=0 PME-
	Capabilities: [58] Express (v1) Root Port (Slot-), MSI 00
		DevCap:	MaxPayload 128 bytes, PhantFunc 0, Latency L0s <64ns, L1 <1us
			ExtTag+ RBE- FLReset-
		DevCtl:	Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
			RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop+
			MaxPayload 128 bytes, MaxReadReq 128 bytes
		DevSta:	CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr- TransPend-
		LnkCap:	Port #0, Speed 2.5GT/s, Width x16, ASPM L0s L1, Latency L0 <64ns, L1 <1us
			ClockPM- Suprise- LLActRep- BwNot-
		LnkCtl:	ASPM Disabled; RCB 64 bytes Disabled- Retrain- CommClk-
			ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
		LnkSta:	Speed 2.5GT/s, Width x16, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt-
		RootCtl: ErrCorrectable- ErrNon-Fatal- ErrFatal- PMEIntEna- CRSVisible-
		RootCap: CRSVisible-
		RootSta: PME ReqID 0000, PMEStatus- PMEPending-
	Capabilities: [80] MSI: Mask- 64bit- Count=1/1 Enable-
		Address: 00000000  Data: 0000
	Capabilities: [b0] Subsystem: ATI Technologies Inc Device 5950
	Capabilities: [b8] HyperTransport: MSI Mapping Enable+ Fixed+

00:06.0 PCI bridge: ATI Technologies Inc RS480 PCI Bridge (prog-if 00 [Normal decode])
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx-
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0, Cache Line Size: 64 bytes
	Bus: primary=00, secondary=02, subordinate=02, sec-latency=0
	I/O behind bridge: 0000c000-0000cfff
	Memory behind bridge: fe900000-fe9fffff
	Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort+ <SERR- <PERR-
	BridgeCtl: Parity+ SERR+ NoISA+ VGA- MAbort- >Reset- FastB2B-
		PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
	Capabilities: [50] Power Management version 3
		Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
		Status: D0 PME-Enable- DSel=0 DScale=0 PME-
	Capabilities: [58] Express (v1) Root Port (Slot-), MSI 00
		DevCap:	MaxPayload 128 bytes, PhantFunc 0, Latency L0s <64ns, L1 <1us
			ExtTag+ RBE- FLReset-
		DevCtl:	Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
			RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop+
			MaxPayload 128 bytes, MaxReadReq 128 bytes
		DevSta:	CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr- TransPend-
		LnkCap:	Port #3, Speed 2.5GT/s, Width x1, ASPM L0s L1, Latency L0 <64ns, L1 <1us
			ClockPM- Suprise- LLActRep- BwNot-
		LnkCtl:	ASPM Disabled; RCB 64 bytes Disabled- Retrain- CommClk-
			ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
		LnkSta:	Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt-
		RootCtl: ErrCorrectable- ErrNon-Fatal- ErrFatal- PMEIntEna- CRSVisible-
		RootCap: CRSVisible-
		RootSta: PME ReqID 0000, PMEStatus- PMEPending-
	Capabilities: [80] MSI: Mask- 64bit- Count=1/1 Enable-
		Address: 00000000  Data: 0000
	Capabilities: [b0] Subsystem: ATI Technologies Inc Device 5950
	Capabilities: [b8] HyperTransport: MSI Mapping Enable+ Fixed+

00:07.0 PCI bridge: ATI Technologies Inc RS480 PCI Bridge (prog-if 00 [Normal decode])
	Control: I/O- Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx-
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0, Cache Line Size: 64 bytes
	Bus: primary=00, secondary=03, subordinate=03, sec-latency=0
	Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- <SERR- <PERR-
	BridgeCtl: Parity+ SERR+ NoISA+ VGA- MAbort- >Reset- FastB2B-
		PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
	Capabilities: [50] Power Management version 3
		Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
		Status: D0 PME-Enable- DSel=0 DScale=0 PME-
	Capabilities: [58] Express (v1) Root Port (Slot-), MSI 00
		DevCap:	MaxPayload 128 bytes, PhantFunc 0, Latency L0s <64ns, L1 <1us
			ExtTag+ RBE- FLReset-
		DevCtl:	Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
			RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop+
			MaxPayload 128 bytes, MaxReadReq 128 bytes
		DevSta:	CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr- TransPend-
		LnkCap:	Port #247, Speed 2.5GT/s, Width x1, ASPM L0s L1, Latency L0 <64ns, L1 <1us
			ClockPM- Suprise- LLActRep- BwNot-
		LnkCtl:	ASPM Disabled; RCB 64 bytes Disabled- Retrain- CommClk-
			ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
		LnkSta:	Speed 2.5GT/s, Width x16, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt-
		RootCtl: ErrCorrectable- ErrNon-Fatal- ErrFatal- PMEIntEna- CRSVisible-
		RootCap: CRSVisible-
		RootSta: PME ReqID 0000, PMEStatus- PMEPending-
	Capabilities: [80] MSI: Mask- 64bit- Count=1/1 Enable-
		Address: 00000000  Data: 0000
	Capabilities: [b0] Subsystem: ATI Technologies Inc Device 5950
	Capabilities: [b8] HyperTransport: MSI Mapping Enable+ Fixed+

00:18.0 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] HyperTransport Technology Configuration
	Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Capabilities: [80] HyperTransport: Host or Secondary Interface
		Command: WarmRst+ DblEnd- DevNum=0 ChainSide- HostHide+ Slave- <EOCErr- DUL-
		Link Control: CFlE- CST- CFE- <LkFail- Init+ EOC- TXO- <CRCErr=0 IsocEn- LSEn- ExtCTL- 64b-
		Link Config: MLWI=16bit DwFcIn- MLWO=16bit DwFcOut- LWI=16bit DwFcInEn- LWO=16bit DwFcOutEn-
		Revision ID: 1.02
		Link Frequency: 1.0GHz
		Link Error: <Prot- <Ovfl- <EOC- CTLTm-
		Link Frequency Capability: 200MHz+ 300MHz- 400MHz+ 500MHz- 600MHz+ 800MHz+ 1.0GHz+ 1.2GHz- 1.4GHz- 1.6GHz- Vend-
		Feature Capability: IsocFC- LDTSTOP+ CRCTM- ECTLT- 64bA- UIDRD- ExtRS- UCnfE-

00:18.1 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Address Map
	Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
	Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-

00:18.2 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] DRAM Controller
	Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
	Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-

00:18.3 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Miscellaneous Control
	Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
	Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-

00:19.0 PCI bridge: ALi Corporation M5249 HTT to PCI Bridge (prog-if 00 [Normal decode])
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx-
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort+ >SERR+ <PERR- INTx-
	Latency: 0
	Bus: primary=00, secondary=04, subordinate=04, sec-latency=64
	I/O behind bridge: 0000d000-0000dfff
	Memory behind bridge: fea00000-feafffff
	Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort+ <SERR+ <PERR+
	BridgeCtl: Parity+ SERR+ NoISA+ VGA- MAbort- >Reset- FastB2B-
		PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
	Capabilities: [c0] HyperTransport: MSI Mapping Enable+ Fixed+

00:1c.0 USB Controller: ALi Corporation USB 1.1 Controller (rev 03) (prog-if 10 [OHCI])
	Subsystem: ASUSTeK Computer Inc. Device 8156
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx-
	Status: Cap- 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR+ INTx+
	Latency: 64 (20000ns max), Cache Line Size: 64 bytes
	Interrupt: pin A routed to IRQ 17
	Region 0: Memory at febfc000 (32-bit, non-prefetchable)

00:1c.1 USB Controller: ALi Corporation USB 1.1 Controller (rev 03) (prog-if 10 [OHCI])
	Subsystem: ASUSTeK Computer Inc. Device 8156
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx-
	Status: Cap- 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR+ INTx+
	Latency: 64 (20000ns max), Cache Line Size: 64 bytes
	Interrupt: pin B routed to IRQ 18
	Region 0: Memory at febfd000 (32-bit, non-prefetchable)

00:1c.2 USB Controller: ALi Corporation USB 1.1 Controller (rev 03) (prog-if 10 [OHCI])
	Subsystem: ASUSTeK Computer Inc. Device 8156
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx-
	Status: Cap- 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR+ INTx+
	Latency: 64 (20000ns max), Cache Line Size: 64 bytes
	Interrupt: pin C routed to IRQ 19
	Region 0: Memory at febfe000 (32-bit, non-prefetchable)

00:1c.3 USB Controller: ALi Corporation USB 2.0 Controller (rev 01) (prog-if 20 [EHCI])
	Subsystem: ASUSTeK Computer Inc. Device 8156
	Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx-
	Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR+ INTx-
	Latency: 64 (4000ns min, 8000ns max), Cache Line Size: 64 bytes
	Interrupt: pin D routed to IRQ 23
	Region 0: Memory at febffc00 (32-bit, non-prefetchable)
	Capabilities: [50] Power Management version 2
		Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
		Status: D0 PME-Enable- DSel=0 DScale=0 PME-
	Capabilities: [58] Debug port: BAR=1 offset=0090

00:1d.0 Audio device: ALi Corporation High Definition Audio/AC'97 Host Controller
	Subsystem: ASUSTeK Computer Inc. Device 81b4
	Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx-
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 64 (4000ns min, 20000ns max)
	Interrupt: pin C routed to IRQ 22
	Region 0: Memory at febf8000 (64-bit, non-prefetchable)
	Capabilities: [50] Power Management version 2
		Flags: PMEClk- DSI- D1- D2- AuxCurrent=55mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
		Status: D0 PME-Enable- DSel=0 DScale=0 PME-

00:1e.0 ISA bridge: ALi Corporation PCI to LPC Controller (rev 31)
	Subsystem: ASUSTeK Computer Inc. Device 8156
	Control: I/O+ Mem+ BusMaster+ SpecCycle+ MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
	Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0 (250ns min, 6000ns max)
	Interrupt: pin ? routed to IRQ 255

00:1e.1 Bridge: ALi Corporation M7101 Power Management Controller [PMU]
	Subsystem: ASUSTeK Computer Inc. Device 8156
	Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
	Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-

00:1f.0 IDE interface: ALi Corporation M5229 IDE (rev c7) (prog-if 8a [Master SecP PriP])
	Subsystem: ASUSTeK Computer Inc. Device 8156
	Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
	Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 32
	Interrupt: pin A routed to IRQ 255
	Region 4: I/O ports at ff00
	Capabilities: [60] Power Management version 2
		Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
		Status: D0 PME-Enable- DSel=0 DScale=0 PME-

00:1f.1 RAID bus controller: ALi Corporation ULi 5287 SATA (rev 02)
	Subsystem: ASUSTeK Computer Inc. Device 8156
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx-
	Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 128, Cache Line Size: 512 bytes
	Interrupt: pin A routed to IRQ 21
	Region 0: I/O ports at ec00
	Region 1: I/O ports at e880
	Region 2: I/O ports at e800
	Region 3: I/O ports at e480
	Region 4: I/O ports at e400
	Region 5: Memory at febff800 (32-bit, non-prefetchable)
	Capabilities: [60] Power Management version 2
		Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot+,D3cold-)
		Status: D0 PME-Enable- DSel=0 DScale=0 PME+

01:00.0 VGA compatible controller: ATI Technologies Inc RV370 [Sapphire X550 Silent] (prog-if 00 [VGA controller])
	Subsystem: PC Partner Limited Device 3000
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx-
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0, Cache Line Size: 64 bytes
	Interrupt: pin A routed to IRQ 18
	Region 0: Memory at d0000000 (32-bit, prefetchable)
	Region 1: I/O ports at b800
	Region 2: Memory at fe400000 (32-bit, non-prefetchable)
	Expansion ROM at fe8e0000 [disabled]
	Capabilities: [50] Power Management version 2
		Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
		Status: D0 PME-Enable- DSel=0 DScale=0 PME-
	Capabilities: [58] Express (v1) Endpoint, MSI 00
		DevCap:	MaxPayload 128 bytes, PhantFunc 0, Latency L0s <128ns, L1 <2us
			ExtTag+ AttnBtn- AttnInd- PwrInd- RBE- FLReset-
		DevCtl:	Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
			RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop+
			MaxPayload 128 bytes, MaxReadReq 128 bytes
		DevSta:	CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr- TransPend-
		LnkCap:	Port #0, Speed 2.5GT/s, Width x16, ASPM L0s L1, Latency L0 <128ns, L1 <1us
			ClockPM- Suprise- LLActRep- BwNot-
		LnkCtl:	ASPM Disabled; RCB 64 bytes Disabled- Retrain- CommClk-
			ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
		LnkSta:	Speed 2.5GT/s, Width x16, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt-
	Capabilities: [80] MSI: Mask- 64bit+ Count=1/1 Enable-
		Address: 0000000000000000  Data: 0000

01:00.1 Display controller: ATI Technologies Inc RV370 secondary [Sapphire X550 Silent]
	Subsystem: PC Partner Limited Device 3001
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0, Cache Line Size: 64 bytes
	Interrupt: pin ? routed to IRQ 255
	Region 0: Memory at fe8d0000 (32-bit, non-prefetchable)
	Capabilities: [50] Power Management version 2
		Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
		Status: D0 PME-Enable- DSel=0 DScale=0 PME-
	Capabilities: [58] Express (v1) Endpoint, MSI 00
		DevCap:	MaxPayload 128 bytes, PhantFunc 0, Latency L0s <128ns, L1 <2us
			ExtTag- AttnBtn- AttnInd- PwrInd- RBE- FLReset-
		DevCtl:	Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
			RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop-
			MaxPayload 128 bytes, MaxReadReq 128 bytes
		DevSta:	CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr- TransPend-
		LnkCap:	Port #0, Speed 2.5GT/s, Width x16, ASPM L0s L1, Latency L0 <128ns, L1 <1us
			ClockPM- Suprise- LLActRep- BwNot-
		LnkCtl:	ASPM Disabled; RCB 64 bytes Disabled- Retrain- CommClk-
			ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
		LnkSta:	Speed 2.5GT/s, Width x16, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt-

02:00.0 Ethernet controller: Marvell Technology Group Ltd. 88E8053 PCI-E Gigabit Ethernet Controller (rev 19)
	Subsystem: ASUSTeK Computer Inc. Marvell 88E8053 Gigabit Ethernet controller PCIe (Asus)
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx-
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0, Cache Line Size: 64 bytes
	Interrupt: pin A routed to IRQ 18
	Region 0: Memory at fe9fc000 (64-bit, non-prefetchable)
	Region 2: I/O ports at c800
	Expansion ROM at fe9c0000 [disabled]
	Capabilities: [48] Power Management version 2
		Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold+)
		Status: D0 PME-Enable- DSel=0 DScale=1 PME-
	Capabilities: [50] Vital Product Data <?>
	Capabilities: [5c] MSI: Mask- 64bit+ Count=2/2 Enable+
		Address: 00000000fee00000  Data: 0032
	Capabilities: [e0] Express (v1) Legacy Endpoint, MSI 00
		DevCap:	MaxPayload 128 bytes, PhantFunc 0, Latency L0s unlimited, L1 unlimited
			ExtTag- AttnBtn- AttnInd- PwrInd- RBE- FLReset-
		DevCtl:	Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
			RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop-
			MaxPayload 128 bytes, MaxReadReq 4096 bytes
		DevSta:	CorrErr+ UncorrErr+ FatalErr- UnsuppReq+ AuxPwr+ TransPend-
		LnkCap:	Port #3, Speed 2.5GT/s, Width x1, ASPM L0s, Latency L0 <256ns, L1 unlimited
			ClockPM- Suprise- LLActRep- BwNot-
		LnkCtl:	ASPM Disabled; RCB 128 bytes Disabled- Retrain- CommClk-
			ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
		LnkSta:	Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt-

04:12.0 FireWire (IEEE 1394): VIA Technologies, Inc. VT6306 Fire II IEEE 1394 OHCI Link Layer Controller (rev 80) (prog-if 10 [OHCI])
	Subsystem: ASUSTeK Computer Inc. A8V/A8N/P4P800 series motherboard
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx-
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 64 (8000ns max), Cache Line Size: 64 bytes
	Interrupt: pin A routed to IRQ 16
	Region 0: Memory at feafe800 (32-bit, non-prefetchable)
	Region 1: I/O ports at dc00
	Capabilities: [50] Power Management version 2
		Flags: PMEClk- DSI- D1- D2+ AuxCurrent=0mA PME(D0-,D1-,D2+,D3hot+,D3cold+)
		Status: D0 PME-Enable- DSel=0 DScale=0 PME-

anglepoise# scanusbdevs -v

Controller /dev/usb0:
addr 1: full speed, self powered, config 1, OHCI root hub(0x0000), AcerLabs(0x0000), rev 1.00
 port 1 addr 2: full speed, self powered, config 1, product 0x2046(0x2046), vendor 0x0451(0x0451), rev 1.25
  port 1 powered
  port 2 powered
  port 3 powered
  port 4 powered
 port 2 powered
 port 3 powered
Controller /dev/usb1:
addr 1: full speed, self powered, config 1, OHCI root hub(0x0000), AcerLabs(0x0000), rev 1.00
 port 1 powered
 port 2 powered
 port 3 powered
Controller /dev/usb2:
addr 1: full speed, self powered, config 1, OHCI root hub(0x0000), AcerLabs(0x0000), rev 1.00
 port 1 powered
 port 2 powered
 port 3 powered
Controller /dev/usb3:
addr 1: high speed, self powered, config 1, EHCI root hub(0x0000), AcerLabs(0x0000), rev 1.00
 port 1 powered
 port 2 powered
 port 3 powered
 port 4 powered
 port 5 powered
 port 6 powered
 port 7 addr 2: high speed, self powered, config 1, USB2.0 Hub(0x0606), vendor 0x05e3(0x05e3), rev 7.02
  port 1 powered
  port 2 powered
  port 3 powered
  port 4 powered
 port 8 powered
anglepoise# scanpci -v

scanpci: Command not found.
anglepoise# cd /usr/ports/distfiles/emulators/devel/libpciaccess/

anglepoise# ls

Makefile	files		pkg-plist
distinfo	pkg-descr	work
anglepoise# cd work/libpciaccess-0.10.5/src

anglepoise# ./scnanpci -v


pci bus 0x0000 cardnum 0x00 function 0x00: vendor 0x1002 device 0x5950
 ATI Technologies Inc RS480 Host Bridge
 CardVendor 0x1043 card 0x8185 (ASUSTeK Computer Inc., Card unknown)
  STATUS    0x2220  COMMAND 0x0006
  CLASS     0x06 0x00 0x00  REVISION 0x10
  BIST      0x00  HEADER 0x00  LATENCY 0x00  CACHE 0x00
size = 0x0
size = 0x0
size = 0x0
size = 0x0
size = 0x0
size = 0x0
  MAX_LAT   0x00  MIN_GNT 0x00  INT_PIN 0x00  INT_LINE 0xff
size = 0x0
size = 0x0
size = 0x0
size = 0x0
size = 0x0
size = 0x0
size = 0x0
size = 0x0
size = 0x0
size = 0x0
size = 0x0
size = 0x0

pci bus 0x0000 cardnum 0x02 function 0x00: vendor 0x1002 device 0x5a34
 ATI Technologies Inc RS480 PCI-X Root Port
 CardVendor 0x1002 card 0x5950 (ATI Technologies Inc, Card unknown)
  STATUS    0x0010  COMMAND 0x0107
  CLASS     0x06 0x04 0x00  REVISION 0x00
  BIST      0x00  HEADER 0x01  LATENCY 0x00  CACHE 0x10
size = 0x0
size = 0x0
  MAX_LAT   0x00  MIN_GNT 0x0b  INT_PIN 0x00  INT_LINE 0xff
size = 0x0
size = 0x0
  Bus: primary=00, secondary=01, subordinate=01, sec-latency=0
  I/O behind bridge: 0000b000-0000bfff
  Memory behind bridge: fe000000-fe80ffff
  Prefetchable memory behind bridge: cff00000-dfe0ffff

pci bus 0x0000 cardnum 0x06 function 0x00: vendor 0x1002 device 0x5a38
 ATI Technologies Inc RS480 PCI Bridge
 CardVendor 0x1002 card 0x5950 (ATI Technologies Inc, Card unknown)
  STATUS    0x0010  COMMAND 0x0107
  CLASS     0x06 0x04 0x00  REVISION 0x00
  BIST      0x00  HEADER 0x01  LATENCY 0x00  CACHE 0x10
size = 0x0
size = 0x0
  MAX_LAT   0x00  MIN_GNT 0x07  INT_PIN 0x00  INT_LINE 0xff
size = 0x0
size = 0x0
  Bus: primary=00, secondary=02, subordinate=02, sec-latency=0
  I/O behind bridge: 0000c000-0000cfff
  Memory behind bridge: fe900000-fe90ffff
  Prefetchable memory behind bridge: fff00000-0000ffff

pci bus 0x0000 cardnum 0x07 function 0x00: vendor 0x1002 device 0x5a39
 ATI Technologies Inc RS480 PCI Bridge
 CardVendor 0x1002 card 0x5950 (ATI Technologies Inc, Card unknown)
  STATUS    0x0010  COMMAND 0x0104
  CLASS     0x06 0x04 0x00  REVISION 0x00
  BIST      0x00  HEADER 0x01  LATENCY 0x00  CACHE 0x10
size = 0x0
size = 0x0
  MAX_LAT   0x00  MIN_GNT 0x07  INT_PIN 0x00  INT_LINE 0xff
size = 0x0
size = 0x0
  Bus: primary=00, secondary=03, subordinate=03, sec-latency=0
  I/O behind bridge: 0000f000-00000fff
  Memory behind bridge: fff00000-0000ffff
  Prefetchable memory behind bridge: fff00000-0000ffff

pci bus 0x0000 cardnum 0x18 function 0x00: vendor 0x1022 device 0x1100
 Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] HyperTransport Technology Configuration
 CardVendor 0x0000 card 0x0000 (Card unknown)
  STATUS    0x0010  COMMAND 0x0000
  CLASS     0x06 0x00 0x00  REVISION 0x00
  BIST      0x00  HEADER 0x80  LATENCY 0x00  CACHE 0x00
size = 0x0
size = 0x0
size = 0x0
size = 0x0
size = 0x0
size = 0x0
  MAX_LAT   0x00  MIN_GNT 0x00  INT_PIN 0x00  INT_LINE 0xff
size = 0x0
size = 0x0
size = 0x0
size = 0x0
size = 0x0
size = 0x0
size = 0x0
size = 0x0
size = 0x0
size = 0x0
size = 0x0
size = 0x0

pci bus 0x0000 cardnum 0x18 function 0x01: vendor 0x1022 device 0x1101
 Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Address Map
 CardVendor 0x0000 card 0x0000 (Card unknown)
  STATUS    0x0000  COMMAND 0x0000
  CLASS     0x06 0x00 0x00  REVISION 0x00
  BIST      0x00  HEADER 0x80  LATENCY 0x00  CACHE 0x00
size = 0x0
size = 0x0
size = 0x0
size = 0x0
size = 0x0
size = 0x0
  MAX_LAT   0x00  MIN_GNT 0x00  INT_PIN 0x00  INT_LINE 0xff
size = 0x0
size = 0x0
size = 0x0
size = 0x0
size = 0x0
size = 0x0
size = 0x0
size = 0x0
size = 0x0
size = 0x0
size = 0x0
size = 0x0

pci bus 0x0000 cardnum 0x18 function 0x02: vendor 0x1022 device 0x1102
 Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] DRAM Controller
 CardVendor 0x0000 card 0x0000 (Card unknown)
  STATUS    0x0000  COMMAND 0x0000
  CLASS     0x06 0x00 0x00  REVISION 0x00
  BIST      0x00  HEADER 0x80  LATENCY 0x00  CACHE 0x00
size = 0x0
size = 0x0
size = 0x0
size = 0x0
size = 0x0
size = 0x0
  MAX_LAT   0x00  MIN_GNT 0x00  INT_PIN 0x00  INT_LINE 0xff
size = 0x0
size = 0x0
size = 0x0
size = 0x0
size = 0x0
size = 0x0
size = 0x0
size = 0x0
size = 0x0
size = 0x0
size = 0x0
size = 0x0

pci bus 0x0000 cardnum 0x18 function 0x03: vendor 0x1022 device 0x1103
 Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Miscellaneous Control
 CardVendor 0x0000 card 0x0000 (Card unknown)
  STATUS    0x0000  COMMAND 0x0000
  CLASS     0x06 0x00 0x00  REVISION 0x00
  BIST      0x00  HEADER 0x80  LATENCY 0x00  CACHE 0x00
size = 0x0
size = 0x0
size = 0x0
size = 0x0
size = 0x0
size = 0x0
  MAX_LAT   0x00  MIN_GNT 0x00  INT_PIN 0x00  INT_LINE 0xff
size = 0x0
size = 0x0
size = 0x0
size = 0x0
size = 0x0
size = 0x0
size = 0x0
size = 0x0
size = 0x0
size = 0x0
size = 0x0
size = 0x0

pci bus 0x0000 cardnum 0x19 function 0x00: vendor 0x10b9 device 0x5249
 ALi Corporation M5249 HTT to PCI Bridge
 CardVendor 0x0000 card 0x0000 (Card unknown)
  STATUS    0x6010  COMMAND 0x0107
  CLASS     0x06 0x04 0x00  REVISION 0x00
  BIST      0x00  HEADER 0x01  LATENCY 0x00  CACHE 0x00
size = 0x0
size = 0x0
  MAX_LAT   0x00  MIN_GNT 0x07  INT_PIN 0x00  INT_LINE 0xff
size = 0x0
size = 0x0
  Bus: primary=00, secondary=04, subordinate=04, sec-latency=64
  I/O behind bridge: 0000d000-0000dfff
  Memory behind bridge: fea00000-fea0ffff
  Prefetchable memory behind bridge: fff00000-0000ffff

pci bus 0x0000 cardnum 0x1c function 0x00: vendor 0x10b9 device 0x5237
 ALi Corporation USB 1.1 Controller
 CardVendor 0x1043 card 0x8156 (ASUSTeK Computer Inc., Card unknown)
  STATUS    0x82a8  COMMAND 0x0117
  CLASS     0x0c 0x03 0x10  REVISION 0x03
  BIST      0x00  HEADER 0x80  LATENCY 0x40  CACHE 0x10
size = 0x1000
size = 0x0
size = 0x0
size = 0x0
size = 0x0
size = 0x0
  BASE0     0xfebfc000 SIZE 4096  MEM
  MAX_LAT   0x50  MIN_GNT 0x00  INT_PIN 0x01  INT_LINE 0x11

pci bus 0x0000 cardnum 0x1c function 0x01: vendor 0x10b9 device 0x5237
 ALi Corporation USB 1.1 Controller
 CardVendor 0x1043 card 0x8156 (ASUSTeK Computer Inc., Card unknown)
  STATUS    0x82a8  COMMAND 0x0117
  CLASS     0x0c 0x03 0x10  REVISION 0x03
  BIST      0x00  HEADER 0x80  LATENCY 0x40  CACHE 0x10
size = 0x1000
size = 0x0
size = 0x0
size = 0x0
size = 0x0
size = 0x0
  BASE0     0xfebfd000 SIZE 4096  MEM
  MAX_LAT   0x50  MIN_GNT 0x00  INT_PIN 0x02  INT_LINE 0x12

pci bus 0x0000 cardnum 0x1c function 0x02: vendor 0x10b9 device 0x5237
 ALi Corporation USB 1.1 Controller
 CardVendor 0x1043 card 0x8156 (ASUSTeK Computer Inc., Card unknown)
  STATUS    0x82a8  COMMAND 0x0117
  CLASS     0x0c 0x03 0x10  REVISION 0x03
  BIST      0x00  HEADER 0x80  LATENCY 0x40  CACHE 0x10
size = 0x1000
size = 0x0
size = 0x0
size = 0x0
size = 0x0
size = 0x0
  BASE0     0xfebfe000 SIZE 4096  MEM
  MAX_LAT   0x50  MIN_GNT 0x00  INT_PIN 0x03  INT_LINE 0x13

pci bus 0x0000 cardnum 0x1c function 0x03: vendor 0x10b9 device 0x5239
 ALi Corporation USB 2.0 Controller
 CardVendor 0x1043 card 0x8156 (ASUSTeK Computer Inc., Card unknown)
  STATUS    0x82b0  COMMAND 0x0116
  CLASS     0x0c 0x03 0x20  REVISION 0x01
  BIST      0x00  HEADER 0x80  LATENCY 0x40  CACHE 0x10
size = 0x100
size = 0x0
size = 0x0
size = 0x0
size = 0x0
size = 0x0
  BASE0     0xfebffc00 SIZE 256  MEM
  MAX_LAT   0x20  MIN_GNT 0x10  INT_PIN 0x04  INT_LINE 0x17

pci bus 0x0000 cardnum 0x1d function 0x00: vendor 0x10b9 device 0x5461
 ALi Corporation High Definition Audio/AC'97 Host Controller
 CardVendor 0x1043 card 0x81b4 (ASUSTeK Computer Inc., Card unknown)
  STATUS    0x0210  COMMAND 0x0106
  CLASS     0x04 0x03 0x00  REVISION 0x00
  BIST      0x00  HEADER 0x00  LATENCY 0x40  CACHE 0x00
size = 0x4000
size = 0x0
size = 0x0
size = 0x0
size = 0x0
  BASE0     0xfebf8000 SIZE 16384  MEM
  MAX_LAT   0x50  MIN_GNT 0x10  INT_PIN 0x03  INT_LINE 0x16

pci bus 0x0000 cardnum 0x1e function 0x00: vendor 0x10b9 device 0x1573
 ALi Corporation PCI to LPC Controller
 CardVendor 0x1043 card 0x8156 (ASUSTeK Computer Inc., Card unknown)
  STATUS    0x0200  COMMAND 0x000f
  CLASS     0x06 0x01 0x00  REVISION 0x31
  BIST      0x00  HEADER 0x80  LATENCY 0x00  CACHE 0x00
size = 0x0
size = 0x0
size = 0x0
size = 0x0
size = 0x0
size = 0x0
  MAX_LAT   0x18  MIN_GNT 0x01  INT_PIN 0x00  INT_LINE 0xff
size = 0x0
size = 0x0
size = 0x0
size = 0x0
size = 0x0
size = 0x0
size = 0x0
size = 0x0
size = 0x0
size = 0x0
size = 0x0
size = 0x0

pci bus 0x0000 cardnum 0x1e function 0x01: vendor 0x10b9 device 0x7101
 ALi Corporation M7101 Power Management Controller [PMU]
 CardVendor 0x1043 card 0x8156 (ASUSTeK Computer Inc., Card unknown)
  STATUS    0x0200  COMMAND 0x0000
  CLASS     0x06 0x80 0x00  REVISION 0x00
  BIST      0x00  HEADER 0x80  LATENCY 0x00  CACHE 0x00
size = 0x0
size = 0x0
size = 0x0
size = 0x0
size = 0x0
size = 0x0
  MAX_LAT   0x00  MIN_GNT 0x00  INT_PIN 0x00  INT_LINE 0xff
size = 0x0
size = 0x0
size = 0x0
size = 0x0
size = 0x0
size = 0x0
size = 0x0
size = 0x0
size = 0x0
size = 0x0
size = 0x0
size = 0x0

pci bus 0x0000 cardnum 0x1f function 0x00: vendor 0x10b9 device 0x5229
 ALi Corporation M5229 IDE
 CardVendor 0x1043 card 0x8156 (ASUSTeK Computer Inc., Card unknown)
  STATUS    0x02b0  COMMAND 0x0005
  CLASS     0x01 0x01 0x8a  REVISION 0xc7
  BIST      0x00  HEADER 0x80  LATENCY 0x20  CACHE 0x00
size = 0x0
size = 0x0
size = 0x0
size = 0x0
size = 0x10
size = 0x0
  BASE4     0x0000ff00 SIZE 16  I/O
  MAX_LAT   0x00  MIN_GNT 0x00  INT_PIN 0x01  INT_LINE 0xff

pci bus 0x0000 cardnum 0x1f function 0x01: vendor 0x10b9 device 0x5287
 ALi Corporation ULi 5287 SATA
 CardVendor 0x1043 card 0x8156 (ASUSTeK Computer Inc., Card unknown)
  STATUS    0x02b0  COMMAND 0x0107
  CLASS     0x01 0x04 0x00  REVISION 0x02
  BIST      0x00  HEADER 0x80  LATENCY 0x80  CACHE 0x80
size = 0x10
size = 0x8
size = 0x10
size = 0x8
size = 0x20
size = 0x400
  BASE0     0x0000ec00 SIZE 16  I/O
  BASE1     0x0000e880 SIZE 8  I/O
  BASE2     0x0000e800 SIZE 16  I/O
  BASE3     0x0000e480 SIZE 8  I/O
  BASE4     0x0000e400 SIZE 32  I/O
  BASE5     0xfebff800 SIZE 1024  MEM
  MAX_LAT   0x00  MIN_GNT 0x00  INT_PIN 0x01  INT_LINE 0x15

pci bus 0x0001 cardnum 0x00 function 0x00: vendor 0x1002 device 0x5b63
 ATI Technologies Inc RV370 [Sapphire X550 Silent]
 CardVendor 0x174b card 0x3000 (PC Partner Limited, Card unknown)
  STATUS    0x0010  COMMAND 0x0107
  CLASS     0x03 0x00 0x00  REVISION 0x00
  BIST      0x00  HEADER 0x80  LATENCY 0x00  CACHE 0x10
size = 0x8000000
size = 0x100
size = 0x10000
size = 0x0
size = 0x0
size = 0x0
  BASE0     0xd0000000 SIZE 134217728  MEM PREFETCHABLE
  BASE1     0x0000b800 SIZE 256  I/O
  BASE2     0xfe400000 SIZE 65536  MEM
  BASEROM   0x00000000  addr 0x00000000
  MAX_LAT   0x00  MIN_GNT 0x00  INT_PIN 0x01  INT_LINE 0x12

pci bus 0x0001 cardnum 0x00 function 0x01: vendor 0x1002 device 0x5b73
 ATI Technologies Inc RV370 secondary [Sapphire X550 Silent]
 CardVendor 0x174b card 0x3001 (PC Partner Limited, Card unknown)
  STATUS    0x0010  COMMAND 0x0007
  CLASS     0x03 0x80 0x00  REVISION 0x00
  BIST      0x00  HEADER 0x00  LATENCY 0x00  CACHE 0x10
size = 0x10000
size = 0x0
size = 0x0
size = 0x0
size = 0x0
size = 0x0
  BASE0     0xfe8d0000 SIZE 65536  MEM
  MAX_LAT   0x00  MIN_GNT 0x00  INT_PIN 0x00  INT_LINE 0xff

pci bus 0x0002 cardnum 0x00 function 0x00: vendor 0x11ab device 0x4362
 Marvell Technology Group Ltd. 88E8053 PCI-E Gigabit Ethernet Controller
 CardVendor 0x1043 card 0x8142 (ASUSTeK Computer Inc., Marvell 88E8053 Gigabit Ethernet controller PCIe (Asus))
  STATUS    0x0010  COMMAND 0x0107
  CLASS     0x02 0x00 0x00  REVISION 0x19
  BIST      0x00  HEADER 0x00  LATENCY 0x00  CACHE 0x10
size = 0x4000
size = 0x100
size = 0x0
size = 0x0
size = 0x0
  BASE0     0xfe9fc000 SIZE 16384  MEM
  BASE2     0x0000c800 SIZE 256  I/O
  MAX_LAT   0x00  MIN_GNT 0x00  INT_PIN 0x01  INT_LINE 0x12

pci bus 0x0004 cardnum 0x12 function 0x00: vendor 0x1106 device 0x3044
 VIA Technologies, Inc. VT6306 Fire II IEEE 1394 OHCI Link Layer Controller
 CardVendor 0x1043 card 0x808a (ASUSTeK Computer Inc., A8V/A8N/P4P800 series motherboard)
  STATUS    0x0210  COMMAND 0x0117
  CLASS     0x0c 0x00 0x10  REVISION 0x80
  BIST      0x00  HEADER 0x00  LATENCY 0x40  CACHE 0x10
size = 0x800
size = 0x80
size = 0x0
size = 0x0
size = 0x0
size = 0x0
  BASE0     0xfeafe800 SIZE 2048  MEM
  BASE1     0x0000dc00 SIZE 128  I/O
  MAX_LAT   0x20  MIN_GNT 0x00  INT_PIN 0x01  INT_LINE 0x10
anglepoise# lscpciconf -lv

hostb0@pci0:0:0:0:	class=0x060000 card=0x81851043 chip=0x59501002 rev=0x10 hdr=0x00
    vendor     = 'ATI Technologies Inc'
    device     = 'RS480 Host Bridge'
    class      = bridge
    subclass   = HOST-PCI
pcib1@pci0:0:2:0:	class=0x060400 card=0x59501002 chip=0x5a341002 rev=0x00 hdr=0x01
    vendor     = 'ATI Technologies Inc'
    device     = 'RS480 PCI-X Root Port'
    class      = bridge
    subclass   = PCI-PCI
pcib2@pci0:0:6:0:	class=0x060400 card=0x59501002 chip=0x5a381002 rev=0x00 hdr=0x01
    vendor     = 'ATI Technologies Inc'
    device     = 'RS480 PCI Bridge'
    class      = bridge
    subclass   = PCI-PCI
pcib3@pci0:0:7:0:	class=0x060400 card=0x59501002 chip=0x5a391002 rev=0x00 hdr=0x01
    vendor     = 'ATI Technologies Inc'
    device     = 'RS480 PCI Bridge'
    class      = bridge
    subclass   = PCI-PCI
hostb1@pci0:0:24:0:	class=0x060000 card=0x00000000 chip=0x11001022 rev=0x00 hdr=0x00
    vendor     = 'Advanced Micro Devices (AMD)'
    device     = '(K8) Athlon 64/Opteron HyperTransport Technology Configuration'
    class      = bridge
    subclass   = HOST-PCI
hostb2@pci0:0:24:1:	class=0x060000 card=0x00000000 chip=0x11011022 rev=0x00 hdr=0x00
    vendor     = 'Advanced Micro Devices (AMD)'
    device     = '(K8) Athlon 64/Opteron Address Map'
    class      = bridge
    subclass   = HOST-PCI
hostb3@pci0:0:24:2:	class=0x060000 card=0x00000000 chip=0x11021022 rev=0x00 hdr=0x00
    vendor     = 'Advanced Micro Devices (AMD)'
    device     = '(K8) Athlon 64/Opteron DRAM Controller'
    class      = bridge
    subclass   = HOST-PCI
hostb4@pci0:0:24:3:	class=0x060000 card=0x00000000 chip=0x11031022 rev=0x00 hdr=0x00
    vendor     = 'Advanced Micro Devices (AMD)'
    device     = '(K8) Athlon 64/Opteron Miscellaneous Control'
    class      = bridge
    subclass   = HOST-PCI
pcib4@pci0:0:25:0:	class=0x060400 card=0x00000000 chip=0x524910b9 rev=0x00 hdr=0x01
    vendor     = 'Acer Labs Incorporated (ALi/ULi)'
    device     = 'M5249 HyperTransport to PCI Bridge'
    class      = bridge
    subclass   = PCI-PCI
ohci0@pci0:0:28:0:	class=0x0c0310 card=0x81561043 chip=0x523710b9 rev=0x03 hdr=0x00
    vendor     = 'Acer Labs Incorporated (ALi/ULi)'
    device     = 'M5273 A1 for windows win 98 OpenHCI 1.1 USB to  2.0'
    class      = serial bus
    subclass   = USB
ohci1@pci0:0:28:1:	class=0x0c0310 card=0x81561043 chip=0x523710b9 rev=0x03 hdr=0x00
    vendor     = 'Acer Labs Incorporated (ALi/ULi)'
    device     = 'M5273 A1 for windows win 98 OpenHCI 1.1 USB to  2.0'
    class      = serial bus
    subclass   = USB
ohci2@pci0:0:28:2:	class=0x0c0310 card=0x81561043 chip=0x523710b9 rev=0x03 hdr=0x00
    vendor     = 'Acer Labs Incorporated (ALi/ULi)'
    device     = 'M5273 A1 for windows win 98 OpenHCI 1.1 USB to  2.0'
    class      = serial bus
    subclass   = USB
ehci0@pci0:0:28:3:	class=0x0c0320 card=0x81561043 chip=0x523910b9 rev=0x01 hdr=0x00
    vendor     = 'Acer Labs Incorporated (ALi/ULi)'
    device     = 'USB 2.0 Enhanced Host Controller'
    class      = serial bus
    subclass   = USB
hdac0@pci0:0:29:0:	class=0x040300 card=0x81b41043 chip=0x546110b9 rev=0x00 hdr=0x00
    vendor     = 'Acer Labs Incorporated (ALi/ULi)'
    device     = '?? Microsoft UAA Bus Driver for High Definition Audio'
    class      = multimedia
    subclass   = HDA
isab0@pci0:0:30:0:	class=0x060100 card=0x81561043 chip=0x157310b9 rev=0x31 hdr=0x00
    vendor     = 'Acer Labs Incorporated (ALi/ULi)'
    device     = 'ALI M1573 South Bridge with Hypertransport Support'
    class      = bridge
    subclass   = PCI-ISA
none0@pci0:0:30:1:	class=0x068000 card=0x81561043 chip=0x710110b9 rev=0x00 hdr=0x00
    vendor     = 'Acer Labs Incorporated (ALi/ULi)'
    device     = 'ALI M7101 Power Management Controller'
    class      = bridge
atapci0@pci0:0:31:0:	class=0x01018a card=0x81561043 chip=0x522910b9 rev=0xc7 hdr=0x00
    vendor     = 'Acer Labs Incorporated (ALi/ULi)'
    device     = 'M5229 Southbridge EIDE Controller'
    class      = mass storage
    subclass   = ATA
atapci1@pci0:0:31:1:	class=0x010400 card=0x81561043 chip=0x528710b9 rev=0x02 hdr=0x00
    vendor     = 'Acer Labs Incorporated (ALi/ULi)'
    device     = '52871849 ALI SATA controller'
    class      = mass storage
    subclass   = RAID
vgapci0@pci0:1:0:0:	class=0x030000 card=0x3000174b chip=0x5b631002 rev=0x00 hdr=0x00
    vendor     = 'ATI Technologies Inc'
    device     = 'Radeon X550 Series'
    class      = display
    subclass   = VGA
vgapci1@pci0:1:0:1:	class=0x038000 card=0x3001174b chip=0x5b731002 rev=0x00 hdr=0x00
    vendor     = 'ATI Technologies Inc'
    device     = 'Radeon X550 Series - Secondary'
    class      = display
mskc0@pci0:2:0:0:	class=0x020000 card=0x81421043 chip=0x436211ab rev=0x19 hdr=0x00
    vendor     = 'Marvell Semiconductor (Was: Galileo Technology Ltd)'
    device     = '88E8053 Marvell Yukon 88E8053 PCI-E Gigabit Ethernet Controller'
    class      = network
    subclass   = ethernet
none1@pci0:4:18:0:	class=0x0c0010 card=0x808a1043 chip=0x30441106 rev=0x80 hdr=0x00
    vendor     = 'VIA Technologies Inc'
    device     = 'VT6306 VIA Fire II IEEE-1394 OHCI Link Layer Controller'
    class      = serial bus
    subclass   = FireWire
anglepoise# lspci -vv

00:00.0 Host bridge: ATI Technologies Inc RS480 Host Bridge (rev 10)
	Subsystem: ASUSTeK Computer Inc. Device 8185
	Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
	Status: Cap- 66MHz+ UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort+ >SERR- <PERR- INTx-
	Latency: 0

00:02.0 PCI bridge: ATI Technologies Inc RS480 PCI-X Root Port (prog-if 00 [Normal decode])
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx-
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0, Cache Line Size: 64 bytes
	Bus: primary=00, secondary=01, subordinate=01, sec-latency=0
	I/O behind bridge: 0000b000-0000bfff
	Memory behind bridge: fe000000-fe8fffff
	Prefetchable memory behind bridge: 00000000cff00000-00000000dfefffff
	Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort+ <SERR- <PERR-
	BridgeCtl: Parity+ SERR+ NoISA- VGA+ MAbort- >Reset- FastB2B-
		PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
	Capabilities: [50] Power Management version 3
		Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
		Status: D0 PME-Enable- DSel=0 DScale=0 PME-
	Capabilities: [58] Express (v1) Root Port (Slot-), MSI 00
		DevCap:	MaxPayload 128 bytes, PhantFunc 0, Latency L0s <64ns, L1 <1us
			ExtTag+ RBE- FLReset-
		DevCtl:	Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
			RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop+
			MaxPayload 128 bytes, MaxReadReq 128 bytes
		DevSta:	CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr- TransPend-
		LnkCap:	Port #0, Speed 2.5GT/s, Width x16, ASPM L0s L1, Latency L0 <64ns, L1 <1us
			ClockPM- Suprise- LLActRep- BwNot-
		LnkCtl:	ASPM Disabled; RCB 64 bytes Disabled- Retrain- CommClk-
			ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
		LnkSta:	Speed 2.5GT/s, Width x16, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt-
		RootCtl: ErrCorrectable- ErrNon-Fatal- ErrFatal- PMEIntEna- CRSVisible-
		RootCap: CRSVisible-
		RootSta: PME ReqID 0000, PMEStatus- PMEPending-
	Capabilities: [80] MSI: Mask- 64bit- Count=1/1 Enable-
		Address: 00000000  Data: 0000
	Capabilities: [b0] Subsystem: ATI Technologies Inc Device 5950
	Capabilities: [b8] HyperTransport: MSI Mapping Enable+ Fixed+

00:06.0 PCI bridge: ATI Technologies Inc RS480 PCI Bridge (prog-if 00 [Normal decode])
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx-
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0, Cache Line Size: 64 bytes
	Bus: primary=00, secondary=02, subordinate=02, sec-latency=0
	I/O behind bridge: 0000c000-0000cfff
	Memory behind bridge: fe900000-fe9fffff
	Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort+ <SERR- <PERR-
	BridgeCtl: Parity+ SERR+ NoISA+ VGA- MAbort- >Reset- FastB2B-
		PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
	Capabilities: [50] Power Management version 3
		Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
		Status: D0 PME-Enable- DSel=0 DScale=0 PME-
	Capabilities: [58] Express (v1) Root Port (Slot-), MSI 00
		DevCap:	MaxPayload 128 bytes, PhantFunc 0, Latency L0s <64ns, L1 <1us
			ExtTag+ RBE- FLReset-
		DevCtl:	Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
			RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop+
			MaxPayload 128 bytes, MaxReadReq 128 bytes
		DevSta:	CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr- TransPend-
		LnkCap:	Port #3, Speed 2.5GT/s, Width x1, ASPM L0s L1, Latency L0 <64ns, L1 <1us
			ClockPM- Suprise- LLActRep- BwNot-
		LnkCtl:	ASPM Disabled; RCB 64 bytes Disabled- Retrain- CommClk-
			ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
		LnkSta:	Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt-
		RootCtl: ErrCorrectable- ErrNon-Fatal- ErrFatal- PMEIntEna- CRSVisible-
		RootCap: CRSVisible-
		RootSta: PME ReqID 0000, PMEStatus- PMEPending-
	Capabilities: [80] MSI: Mask- 64bit- Count=1/1 Enable-
		Address: 00000000  Data: 0000
	Capabilities: [b0] Subsystem: ATI Technologies Inc Device 5950
	Capabilities: [b8] HyperTransport: MSI Mapping Enable+ Fixed+

00:07.0 PCI bridge: ATI Technologies Inc RS480 PCI Bridge (prog-if 00 [Normal decode])
	Control: I/O- Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx-
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0, Cache Line Size: 64 bytes
	Bus: primary=00, secondary=03, subordinate=03, sec-latency=0
	Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- <SERR- <PERR-
	BridgeCtl: Parity+ SERR+ NoISA+ VGA- MAbort- >Reset- FastB2B-
		PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
	Capabilities: [50] Power Management version 3
		Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
		Status: D0 PME-Enable- DSel=0 DScale=0 PME-
	Capabilities: [58] Express (v1) Root Port (Slot-), MSI 00
		DevCap:	MaxPayload 128 bytes, PhantFunc 0, Latency L0s <64ns, L1 <1us
			ExtTag+ RBE- FLReset-
		DevCtl:	Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
			RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop+
			MaxPayload 128 bytes, MaxReadReq 128 bytes
		DevSta:	CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr- TransPend-
		LnkCap:	Port #247, Speed 2.5GT/s, Width x1, ASPM L0s L1, Latency L0 <64ns, L1 <1us
			ClockPM- Suprise- LLActRep- BwNot-
		LnkCtl:	ASPM Disabled; RCB 64 bytes Disabled- Retrain- CommClk-
			ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
		LnkSta:	Speed 2.5GT/s, Width x16, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt-
		RootCtl: ErrCorrectable- ErrNon-Fatal- ErrFatal- PMEIntEna- CRSVisible-
		RootCap: CRSVisible-
		RootSta: PME ReqID 0000, PMEStatus- PMEPending-
	Capabilities: [80] MSI: Mask- 64bit- Count=1/1 Enable-
		Address: 00000000  Data: 0000
	Capabilities: [b0] Subsystem: ATI Technologies Inc Device 5950
	Capabilities: [b8] HyperTransport: MSI Mapping Enable+ Fixed+

00:18.0 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] HyperTransport Technology Configuration
	Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Capabilities: [80] HyperTransport: Host or Secondary Interface
		Command: WarmRst+ DblEnd- DevNum=0 ChainSide- HostHide+ Slave- <EOCErr- DUL-
		Link Control: CFlE- CST- CFE- <LkFail- Init+ EOC- TXO- <CRCErr=0 IsocEn- LSEn- ExtCTL- 64b-
		Link Config: MLWI=16bit DwFcIn- MLWO=16bit DwFcOut- LWI=16bit DwFcInEn- LWO=16bit DwFcOutEn-
		Revision ID: 1.02
		Link Frequency: 1.0GHz
		Link Error: <Prot- <Ovfl- <EOC- CTLTm-
		Link Frequency Capability: 200MHz+ 300MHz- 400MHz+ 500MHz- 600MHz+ 800MHz+ 1.0GHz+ 1.2GHz- 1.4GHz- 1.6GHz- Vend-
		Feature Capability: IsocFC- LDTSTOP+ CRCTM- ECTLT- 64bA- UIDRD- ExtRS- UCnfE-

00:18.1 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Address Map
	Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
	Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-

00:18.2 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] DRAM Controller
	Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
	Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-

00:18.3 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Miscellaneous Control
	Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
	Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-

00:19.0 PCI bridge: ALi Corporation M5249 HTT to PCI Bridge (prog-if 00 [Normal decode])
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx-
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort+ >SERR+ <PERR- INTx-
	Latency: 0
	Bus: primary=00, secondary=04, subordinate=04, sec-latency=64
	I/O behind bridge: 0000d000-0000dfff
	Memory behind bridge: fea00000-feafffff
	Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort+ <SERR+ <PERR+
	BridgeCtl: Parity+ SERR+ NoISA+ VGA- MAbort- >Reset- FastB2B-
		PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
	Capabilities: [c0] HyperTransport: MSI Mapping Enable+ Fixed+

00:1c.0 USB Controller: ALi Corporation USB 1.1 Controller (rev 03) (prog-if 10 [OHCI])
	Subsystem: ASUSTeK Computer Inc. Device 8156
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx-
	Status: Cap- 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR+ INTx+
	Latency: 64 (20000ns max), Cache Line Size: 64 bytes
	Interrupt: pin A routed to IRQ 17
	Region 0: Memory at febfc000 (32-bit, non-prefetchable)

00:1c.1 USB Controller: ALi Corporation USB 1.1 Controller (rev 03) (prog-if 10 [OHCI])
	Subsystem: ASUSTeK Computer Inc. Device 8156
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx-
	Status: Cap- 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR+ INTx+
	Latency: 64 (20000ns max), Cache Line Size: 64 bytes
	Interrupt: pin B routed to IRQ 18
	Region 0: Memory at febfd000 (32-bit, non-prefetchable)

00:1c.2 USB Controller: ALi Corporation USB 1.1 Controller (rev 03) (prog-if 10 [OHCI])
	Subsystem: ASUSTeK Computer Inc. Device 8156
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx-
	Status: Cap- 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR+ INTx+
	Latency: 64 (20000ns max), Cache Line Size: 64 bytes
	Interrupt: pin C routed to IRQ 19
	Region 0: Memory at febfe000 (32-bit, non-prefetchable)

00:1c.3 USB Controller: ALi Corporation USB 2.0 Controller (rev 01) (prog-if 20 [EHCI])
	Subsystem: ASUSTeK Computer Inc. Device 8156
	Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx-
	Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR+ INTx-
	Latency: 64 (4000ns min, 8000ns max), Cache Line Size: 64 bytes
	Interrupt: pin D routed to IRQ 23
	Region 0: Memory at febffc00 (32-bit, non-prefetchable)
	Capabilities: [50] Power Management version 2
		Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
		Status: D0 PME-Enable- DSel=0 DScale=0 PME-
	Capabilities: [58] Debug port: BAR=1 offset=0090

00:1d.0 Audio device: ALi Corporation High Definition Audio/AC'97 Host Controller
	Subsystem: ASUSTeK Computer Inc. Device 81b4
	Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx-
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 64 (4000ns min, 20000ns max)
	Interrupt: pin C routed to IRQ 22
	Region 0: Memory at febf8000 (64-bit, non-prefetchable)
	Capabilities: [50] Power Management version 2
		Flags: PMEClk- DSI- D1- D2- AuxCurrent=55mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
		Status: D0 PME-Enable- DSel=0 DScale=0 PME-

00:1e.0 ISA bridge: ALi Corporation PCI to LPC Controller (rev 31)
	Subsystem: ASUSTeK Computer Inc. Device 8156
	Control: I/O+ Mem+ BusMaster+ SpecCycle+ MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
	Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0 (250ns min, 6000ns max)
	Interrupt: pin ? routed to IRQ 255

00:1e.1 Bridge: ALi Corporation M7101 Power Management Controller [PMU]
	Subsystem: ASUSTeK Computer Inc. Device 8156
	Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
	Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-

00:1f.0 IDE interface: ALi Corporation M5229 IDE (rev c7) (prog-if 8a [Master SecP PriP])
	Subsystem: ASUSTeK Computer Inc. Device 8156
	Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
	Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 32
	Interrupt: pin A routed to IRQ 255
	Region 4: I/O ports at ff00
	Capabilities: [60] Power Management version 2
		Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
		Status: D0 PME-Enable- DSel=0 DScale=0 PME-

00:1f.1 RAID bus controller: ALi Corporation ULi 5287 SATA (rev 02)
	Subsystem: ASUSTeK Computer Inc. Device 8156
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx-
	Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 128, Cache Line Size: 512 bytes
	Interrupt: pin A routed to IRQ 21
	Region 0: I/O ports at ec00
	Region 1: I/O ports at e880
	Region 2: I/O ports at e800
	Region 3: I/O ports at e480
	Region 4: I/O ports at e400
	Region 5: Memory at febff800 (32-bit, non-prefetchable)
	Capabilities: [60] Power Management version 2
		Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot+,D3cold-)
		Status: D0 PME-Enable- DSel=0 DScale=0 PME+

01:00.0 VGA compatible controller: ATI Technologies Inc RV370 [Sapphire X550 Silent] (prog-if 00 [VGA controller])
	Subsystem: PC Partner Limited Device 3000
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx-
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0, Cache Line Size: 64 bytes
	Interrupt: pin A routed to IRQ 18
	Region 0: Memory at d0000000 (32-bit, prefetchable)
	Region 1: I/O ports at b800
	Region 2: Memory at fe400000 (32-bit, non-prefetchable)
	Expansion ROM at fe8e0000 [disabled]
	Capabilities: [50] Power Management version 2
		Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
		Status: D0 PME-Enable- DSel=0 DScale=0 PME-
	Capabilities: [58] Express (v1) Endpoint, MSI 00
		DevCap:	MaxPayload 128 bytes, PhantFunc 0, Latency L0s <128ns, L1 <2us
			ExtTag+ AttnBtn- AttnInd- PwrInd- RBE- FLReset-
		DevCtl:	Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
			RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop+
			MaxPayload 128 bytes, MaxReadReq 128 bytes
		DevSta:	CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr- TransPend-
		LnkCap:	Port #0, Speed 2.5GT/s, Width x16, ASPM L0s L1, Latency L0 <128ns, L1 <1us
			ClockPM- Suprise- LLActRep- BwNot-
		LnkCtl:	ASPM Disabled; RCB 64 bytes Disabled- Retrain- CommClk-
			ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
		LnkSta:	Speed 2.5GT/s, Width x16, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt-
	Capabilities: [80] MSI: Mask- 64bit+ Count=1/1 Enable-
		Address: 0000000000000000  Data: 0000

01:00.1 Display controller: ATI Technologies Inc RV370 secondary [Sapphire X550 Silent]
	Subsystem: PC Partner Limited Device 3001
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0, Cache Line Size: 64 bytes
	Interrupt: pin ? routed to IRQ 255
	Region 0: Memory at fe8d0000 (32-bit, non-prefetchable)
	Capabilities: [50] Power Management version 2
		Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
		Status: D0 PME-Enable- DSel=0 DScale=0 PME-
	Capabilities: [58] Express (v1) Endpoint, MSI 00
		DevCap:	MaxPayload 128 bytes, PhantFunc 0, Latency L0s <128ns, L1 <2us
			ExtTag- AttnBtn- AttnInd- PwrInd- RBE- FLReset-
		DevCtl:	Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
			RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop-
			MaxPayload 128 bytes, MaxReadReq 128 bytes
		DevSta:	CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr- TransPend-
		LnkCap:	Port #0, Speed 2.5GT/s, Width x16, ASPM L0s L1, Latency L0 <128ns, L1 <1us
			ClockPM- Suprise- LLActRep- BwNot-
		LnkCtl:	ASPM Disabled; RCB 64 bytes Disabled- Retrain- CommClk-
			ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
		LnkSta:	Speed 2.5GT/s, Width x16, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt-

02:00.0 Ethernet controller: Marvell Technology Group Ltd. 88E8053 PCI-E Gigabit Ethernet Controller (rev 19)
	Subsystem: ASUSTeK Computer Inc. Marvell 88E8053 Gigabit Ethernet controller PCIe (Asus)
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx-
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0, Cache Line Size: 64 bytes
	Interrupt: pin A routed to IRQ 18
	Region 0: Memory at fe9fc000 (64-bit, non-prefetchable)
	Region 2: I/O ports at c800
	Expansion ROM at fe9c0000 [disabled]
	Capabilities: [48] Power Management version 2
		Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold+)
		Status: D0 PME-Enable- DSel=0 DScale=1 PME-
	Capabilities: [50] Vital Product Data <?>
	Capabilities: [5c] MSI: Mask- 64bit+ Count=2/2 Enable+
		Address: 00000000fee00000  Data: 0032
	Capabilities: [e0] Express (v1) Legacy Endpoint, MSI 00
		DevCap:	MaxPayload 128 bytes, PhantFunc 0, Latency L0s unlimited, L1 unlimited
			ExtTag- AttnBtn- AttnInd- PwrInd- RBE- FLReset-
		DevCtl:	Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
			RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop-
			MaxPayload 128 bytes, MaxReadReq 4096 bytes
		DevSta:	CorrErr+ UncorrErr+ FatalErr- UnsuppReq+ AuxPwr+ TransPend-
		LnkCap:	Port #3, Speed 2.5GT/s, Width x1, ASPM L0s, Latency L0 <256ns, L1 unlimited
			ClockPM- Suprise- LLActRep- BwNot-
		LnkCtl:	ASPM Disabled; RCB 128 bytes Disabled- Retrain- CommClk-
			ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
		LnkSta:	Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt-

04:12.0 FireWire (IEEE 1394): VIA Technologies, Inc. VT6306 Fire II IEEE 1394 OHCI Link Layer Controller (rev 80) (prog-if 10 [OHCI])
	Subsystem: ASUSTeK Computer Inc. A8V/A8N/P4P800 series motherboard
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx-
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 64 (8000ns max), Cache Line Size: 64 bytes
	Interrupt: pin A routed to IRQ 16
	Region 0: Memory at feafe800 (32-bit, non-prefetchable)
	Region 1: I/O ports at dc00
	Capabilities: [50] Power Management version 2
		Flags: PMEClk- DSI- D1- D2+ AuxCurrent=0mA PME(D0-,D1-,D2+,D3hot+,D3cold+)
		Status: D0 PME-Enable- DSel=0 DScale=0 PME-

anglepoise# usbdesva vs -v

Controller /dev/usb0:
addr 1: full speed, self powered, config 1, OHCI root hub(0x0000), AcerLabs(0x0000), rev 1.00
 port 1 addr 2: full speed, self powered, config 1, product 0x2046(0x2046), vendor 0x0451(0x0451), rev 1.25
  port 1 powered
  port 2 powered
  port 3 powered
  port 4 powered
 port 2 powered
 port 3 powered
Controller /dev/usb1:
addr 1: full speed, self powered, config 1, OHCI root hub(0x0000), AcerLabs(0x0000), rev 1.00
 port 1 powered
 port 2 powered
 port 3 powered
Controller /dev/usb2:
addr 1: full speed, self powered, config 1, OHCI root hub(0x0000), AcerLabs(0x0000), rev 1.00
 port 1 powered
 port 2 powered
 port 3 powered
Controller /dev/usb3:
addr 1: high speed, self powered, config 1, EHCI root hub(0x0000), AcerLabs(0x0000), rev 1.00
 port 1 powered
 port 2 powered
 port 3 powered
 port 4 powered
 port 5 powered
 port 6 powered
    XXX DELAYU  port 7 addr 2: high speed, self powered, config 1, product 0x0606(0x0606), vendor 0x05e3(0x05e3), rev 7.02
  port 1 powered
  port 2 powered
  port 3 powered
  port 4 powered
 port 8 powered
anglepoise#     XXX DELAYU  HERE 

anglepoise# echo The issue is now happening.

The issue is now happening.
anglepoise# ^Dexit

Script done on Tue Feb 10 18:06:40 2009
From rnoland at FreeBSD.org  Tue Feb 10 10:57:41 2009
From: rnoland at FreeBSD.org (Robert Noland)
Date: Tue Feb 10 10:57:48 2009
Subject: Unhappy Xorg upgrade
In-Reply-To: <4991C017.8080903@FreeBSD.org>
References: <329181233306971@webmail57.yandex.ru>
	<985A59F2-20CC-4779-A000-018E52B5BFA9@jump-ing.de>
	<101781233319948@webmail36.yandex.ru> <4983A3AE.90804@FreeBSD.org>
	<498F901A.7000900@FreeBSD.org>
	<1234159237.23838.3.camel@ferret.2hip.net>
	<4990835A.3020303@FreeBSD.org>
	<1234208586.1524.17.camel@ferret.2hip.net>
	<4990BC99.1070108@FreeBSD.org>
	<1234246034.1524.27.camel@ferret.2hip.net>
	<4991C017.8080903@FreeBSD.org>
Message-ID: <1234292252.1524.38.camel@ferret.2hip.net>

On Tue, 2009-02-10 at 17:57 +0000, Bruce M. Simpson wrote:
> Robert Noland wrote:
> > ...
> > Ok, lets try another test...  There is a scanpci util in the
> > libpciaccess port.  We don't install it, but it does get built.  Build
> > the port and run scanpci -v as root from the console.  That should poke
> > all the pci devices on the box and tell you about them.  See if that is
> > able to trigger the issue.
> >   
> 
> Well spotted. I saw this tool in "locate" output and was going to try it 
> the other day, although I saw it didn't get installed, so assumed it was 
> historical.
> 
> Yes, This immediately triggered the issue without even running X on a 
> fresh boot.

Ok, At least we know where the issue lies now.  I'll try and look the
code over again, but I behaves almost identically to the kernel routines
I think.  jhb@ wrote us a new ioctl to avoid doing most of this from
userland, but it will be a while before we can count on it's existence
and it doesn't support bios frobbing yet.

Can you verify that pciconf -lvbc does not trigger the issue?

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/20090210/313ce89e/attachment.pgp
From dougb at FreeBSD.org  Tue Feb 10 10:59:09 2009
From: dougb at FreeBSD.org (Doug Barton)
Date: Tue Feb 10 10:59:16 2009
Subject: [7-STABLE] failure during buildworld
In-Reply-To: <1234258680.13304.26.camel@horst-tla>
References: <1234258680.13304.26.camel@horst-tla>
Message-ID: <4991CE7A.5010300@FreeBSD.org>

Horst G?nther Burkhardt III wrote:
> Hey everybody :) 
> 
> I'm having a small issue compiling 7-STABLE as checked out 24 hours ago
> at the time of writing... during make -j4 buildworld, 

You need to repeat the build with a clean obj directory and no -j
options to find the error.

Doug

-- 

    This .signature sanitized for your protection
From horst at sxemacs.org  Tue Feb 10 11:13:30 2009
From: horst at sxemacs.org (Horst =?ISO-8859-1?Q?G=FCnther?= Burkhardt III)
Date: Tue Feb 10 11:13:44 2009
Subject: [7-STABLE] failure during buildworld
In-Reply-To: <4991CE7A.5010300@FreeBSD.org>
References: <1234258680.13304.26.camel@horst-tla>
	<4991CE7A.5010300@FreeBSD.org>
Message-ID: <1234293288.13304.27.camel@horst-tla>

On Tue, 2009-02-10 at 10:59 -0800, Doug Barton wrote:
> Horst G?nther Burkhardt III wrote:
> > Hey everybody :) 
> > 
> > I'm having a small issue compiling 7-STABLE as checked out 24 hours ago
> > at the time of writing... during make -j4 buildworld, 
> 
> You need to repeat the build with a clean obj directory and no -j
> options to find the error.
> 
> Doug


New log : it looks like libstdc++ : 

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-inst.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
++/del_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/libstdc++/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/libstdc++/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.
[ bsdbox ] [ root ] [ /usr/src ] ==> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20090210/3a781cbe/attachment.pgp
From danallen46 at airwired.net  Tue Feb 10 11:16:32 2009
From: danallen46 at airwired.net (Dan Allen)
Date: Tue Feb 10 11:16:39 2009
Subject: x48 display messed up with Xorg 7.4
Message-ID: <CE2B54D9-C62C-4EF1-96CE-42392BCD7EF8@airwired.net>

One of my favorite little apps is the HP48 calculator emulator called  
x48.

In the recent upgrade to Xorg 7.4 the screen on the calculator is  
completely screwed up - nothing appears as it should.

I am on a Toshiba Satellite U205 with Intel i810 graphics running 7.1- 
STABLE.

I did manage to get Firefox working on 7.4, but this graphics issue  
still was there so I went back to Xorg 7.3 and everything works again.

Has anyone else seen this?

Dan

From horst at sxemacs.org  Tue Feb 10 11:26:00 2009
From: horst at sxemacs.org (Horst =?ISO-8859-1?Q?G=FCnther?= Burkhardt III)
Date: Tue Feb 10 11:26:08 2009
Subject: x48 display messed up with Xorg 7.4
In-Reply-To: <CE2B54D9-C62C-4EF1-96CE-42392BCD7EF8@airwired.net>
References: <CE2B54D9-C62C-4EF1-96CE-42392BCD7EF8@airwired.net>
Message-ID: <1234293967.13304.30.camel@horst-tla>

On Tue, 2009-02-10 at 12:16 -0700, Dan Allen wrote:
> One of my favorite little apps is the HP48 calculator emulator called  
> x48.
> 
> In the recent upgrade to Xorg 7.4 the screen on the calculator is  
> completely screwed up - nothing appears as it should.
> 
> I am on a Toshiba Satellite U205 with Intel i810 graphics running 7.1- 
> STABLE.
> 
> I did manage to get Firefox working on 7.4, but this graphics issue  
> still was there so I went back to Xorg 7.3 and everything works again.
> 
> Has anyone else seen this?
> 
> Dan

Hi :)

I personally suggest nonpareil, it works exceedingly well. It's
unfortunate to say that I have to use it as my REAL hp calc no longer
works :( :p

--
Horst.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20090210/cfbbe2fb/attachment.pgp
From andreast-list at fgznet.ch  Tue Feb 10 12:16:20 2009
From: andreast-list at fgznet.ch (Andreas Tobler)
Date: Tue Feb 10 12:16:27 2009
Subject: [7-STABLE] failure during buildworld
In-Reply-To: <1234258680.13304.26.camel@horst-tla>
References: <1234258680.13304.26.camel@horst-tla>
Message-ID: <4991DDA9.7090008@fgznet.ch>

Horst G?nther Burkhardt III wrote:

> (also, why doesn't make buildworld pick up from where it left off?) 

I think this intentional, but you can pass -DNO_CLEAN to your make 
command and buildworld should continue where it failed.

make -DNO_CLEAN buildworld

Andreas

From tevans.uk at googlemail.com  Wed Feb 11 06:55:57 2009
From: tevans.uk at googlemail.com (Tom Evans)
Date: Wed Feb 11 06:56:04 2009
Subject: Page fault while in kernel mode
Message-ID: <1234362257.2224.10.camel@strangepork.mintel.co.uk>

Hi all.

I got this panic when our SMB server moved hostname. I still had the
drives mounted, so I wondered what would happen if I ls'ed the mount
point ('Doctor it hurts when I do this' 'Dont do that then..').

I'm running i386 RELENG_7 from mid October, so it is more than possible
that this has already been fixed, but best to report it as well. I still
have the vmcore if anyone wants more info from it.

Cheers

Tom

FreeBSD strangepork.mintel.co.uk 7.1-PRERELEASE FreeBSD 7.1-PRERELEASE
#0: Wed Oct 22 02:25:56 BST 2008
root@strangepork.mintel.co.uk:/usr/FreeBSD/RELENG_7/obj/usr/FreeBSD/RELENG_7/src/sys/STRANGEPORK  i386

> # kgdb /usr/obj/usr/FreeBSD/RELENG_7/src/sys/STRANGEPORK/kernel.debug /var/crash/vmcore.1
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i386-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 = 0; apic id = 00
fault virtual address	= 0x18
fault code		= supervisor read, page not present
instruction pointer	= 0x20:0xc0817385
stack pointer	        = 0x28:0xe8276adc
frame pointer	        = 0x28:0xe8276af8
code segment		= base 0x0, limit 0xfffff, type 0x1b
			= DPL 0, pres 1, def32 1, gran 1
processor eflags	= resume, IOPL = 0
current process		= 1032 (smbiod0)
trap number		= 12
panic: page fault
cpuid = 0
Uptime: 20d23h21m41s
Physical memory: 1992 MB
Dumping 314 MB: 299 283 267 251 235 219 203 187 171 155 139 123 107 91 75 59 43 27 11

Reading symbols from /boot/kernel/snd_hda.ko...done.
Loaded symbols for /boot/kernel/snd_hda.ko
Reading symbols from /boot/kernel/sound.ko...Reading symbols from /boot/kernel/sound.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/sound.ko
Reading symbols from /boot/modules/nvidia.ko...done.
Loaded symbols for /boot/modules/nvidia.ko
Reading symbols from /boot/kernel/linux.ko...Reading symbols from /boot/kernel/linux.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/linux.ko
Reading symbols from /boot/kernel/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/smbfs.ko...Reading symbols from /boot/kernel/smbfs.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/smbfs.ko
Reading symbols from /boot/kernel/libiconv.ko...Reading symbols from /boot/kernel/libiconv.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/libiconv.ko
Reading symbols from /boot/kernel/libmchain.ko...Reading symbols from /boot/kernel/libmchain.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/libmchain.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/fdescfs.ko...Reading symbols from /boot/kernel/fdescfs.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/fdescfs.ko
#0  doadump () at pcpu.h:196
196	pcpu.h: No such file or directory.
	in pcpu.h
(kgdb) bt full
#0  doadump () at pcpu.h:196
No locals.
#1  0xc07e2047 in boot (howto=260) at /usr/FreeBSD/RELENG_7/src/sys/kern/kern_shutdown.c:418
	_giantcnt = Variable "_giantcnt" is not available.
(kgdb) bt
#0  doadump () at pcpu.h:196
#1  0xc07e2047 in boot (howto=260) at /usr/FreeBSD/RELENG_7/src/sys/kern/kern_shutdown.c:418
#2  0xc07e2319 in panic (fmt=Variable "fmt" is not available.
) at /usr/FreeBSD/RELENG_7/src/sys/kern/kern_shutdown.c:574
#3  0xc0b1b45c in trap_fatal (frame=0xe8276a9c, eva=24) at /usr/FreeBSD/RELENG_7/src/sys/i386/i386/trap.c:939
#4  0xc0b1bdcf in trap (frame=0xe8276a9c) at /usr/FreeBSD/RELENG_7/src/sys/i386/i386/trap.c:320
#5  0xc0b028fb in calltrap () at /usr/FreeBSD/RELENG_7/src/sys/i386/i386/exception.s:159
#6  0xc0817385 in turnstile_broadcast (ts=0x0, queue=0) at /usr/FreeBSD/RELENG_7/src/sys/kern/subr_turnstile.c:836
#7  0xc07d4b12 in _mtx_unlock_sleep (m=0xc6457494, opts=0, file=0xc631c718 "/usr/FreeBSD/RELENG_7/src/sys/modules/smbfs/../../netsmb/smb_iod.c", line=97)
    at /usr/FreeBSD/RELENG_7/src/sys/kern/kern_mutex.c:619
#8  0xc07d4e72 in _mtx_unlock_flags (m=0xc6457494, opts=0, file=0xc631c718 "/usr/FreeBSD/RELENG_7/src/sys/modules/smbfs/../../netsmb/smb_iod.c", line=97)
    at /usr/FreeBSD/RELENG_7/src/sys/kern/kern_mutex.c:210
#9  0xc630fb73 in smb_iod_invrq (iod=Variable "iod" is not available.
) at /usr/FreeBSD/RELENG_7/src/sys/modules/smbfs/../../netsmb/smb_iod.c:97
#10 0xc6310d57 in smb_iod_addrq (rqp=0xc6457400) at /usr/FreeBSD/RELENG_7/src/sys/modules/smbfs/../../netsmb/smb_iod.c:424
#11 0xc630d28c in smb_rq_enqueue (rqp=0xc6457400) at /usr/FreeBSD/RELENG_7/src/sys/modules/smbfs/../../netsmb/smb_rq.c:193
#12 0xc630d6d8 in smb_rq_simple (rqp=0xc6457400) at /usr/FreeBSD/RELENG_7/src/sys/modules/smbfs/../../netsmb/smb_rq.c:174
#13 0xc630b9e4 in smb_smb_treeconnect (ssp=0xc5ee6100, scred=0xc5e9b4c4) at /usr/FreeBSD/RELENG_7/src/sys/modules/smbfs/../../netsmb/smb_smb.c:561
#14 0xc63108b8 in smb_iod_thread (arg=0xc5e9b480) at /usr/FreeBSD/RELENG_7/src/sys/modules/smbfs/../../netsmb/smb_iod.c:212
#15 0xc07be9a9 in fork_exit (callout=0xc63105c0 <smb_iod_thread>, arg=0xc5e9b480, frame=0xe8276d38) at /usr/FreeBSD/RELENG_7/src/sys/kern/kern_fork.c:804
#16 0xc0b02970 in fork_trampoline () at /usr/FreeBSD/RELENG_7/src/sys/i386/i386/exception.s:264
(kgdb) 

From om-lists-bsd at omx.ch  Wed Feb 11 07:18:15 2009
From: om-lists-bsd at omx.ch (Olivier Mueller)
Date: Wed Feb 11 07:18:29 2009
Subject: poweredge 1850 won't boot 7.1?  maybe LSI-related : amr0: adapter
 is busy
Message-ID: <1234363891.15909.35.camel@ompc.insign.local>

Hello,

This afternoon I wanted to upgrade to 7.1 two good old dell PowerEdge
servers which were running FreeBSD 6.x.  It went fine and quickly on the
poweredge 1950, but it failed completely on the poweredge 1850. 

Facts:

- boot cd and setup / operation of freebsd 6.x or 7.0 is fine
   Message log abstract: 
	$ uname -v
	FreeBSD 7.0-RELEASE-p7 #0: Sun Dec 21 08:31:52 UTC 2008     root@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC 
	$ dmesg|grep amr
	amr0: <LSILogic MegaRAID 1.53> mem 0xd80f0000-0xd80fffff,0xdfde0000-0xdfdfffff irq 46 at device 14.0 on pci2
	amr0: Using 64-bit DMA
	amr0: [ITHREAD]
	amr0: delete logical drives supported by controller
	amr0: <LSILogic PERC 4e/Si> Firmware 521X, BIOS H430, 256MB RAM
	amr0: delete logical drives supported by controller
	amrd0: <LSILogic MegaRAID logical drive> on amr0
	amrd0: 69880MB (143114240 sectors) RAID 1 (optimal)
	Trying to mount root from ufs:/dev/amrd0s1a

- boot cd of 7.1 fails because the installed doesn't see any harddisk. 
   Message log abstract:
    	amr0: adapter is busy
	amr0: adapter is busy
	amr0: delete logical drives supported by controller
 

I also tried to setup 7.0, and then upgrade to 7.1 with freebsd-update,
but then it fails exactly like with the 7.1 boot CD
(7.1-RELEASE-amd64-disc1.iso). Screenshot: 
     http://omx.ch/om/stuff/pe1850bsd71error.jpg

BIOS Message about the Controller on system startup:
PowerEdge Expandable RAID COntroller BIOS, (c) 2006 LSI Logic
Corporation

I'm not sure what I can try next...  I'd still like to be able to run
7.1 on this host as well as on several other old but still fine 1850. Is
my system simply too old?  Why is my adapter "busy" under 7.1?  What
would you try?   I checked the relnotes as well, but saw nothing helpful
about my problem there.

regards & thanks in advance for any feedback,
Olivier


From lavalamp at spiritual-machines.org  Wed Feb 11 07:54:08 2009
From: lavalamp at spiritual-machines.org (Brian A. Seklecki)
Date: Wed Feb 11 07:54:21 2009
Subject: poweredge 1850 won't boot 7.1?  maybe LSI-related : amr0:
 adapter is busy
In-Reply-To: <1234363891.15909.35.camel@ompc.insign.local>
References: <1234363891.15909.35.camel@ompc.insign.local>
Message-ID: <1234366709.3500.62.camel@ingress.ws.pitbpa0.priv.collaborativefusion.com>

On Wed, 2009-02-11 at 15:51 +0100, Olivier Mueller wrote:
> Hello,

> This afternoon I wanted to upgrade to 7.1 two good old dell PowerEdge
> servers which were running FreeBSD 6.x.  It went fine and quickly on the

There's already discussion about this in the archives.  We're aware and
working on it.

Set:
/boo/loader.conf

kern.cam.scsi_delay=20000

As a work-around for now.

Tracking the megarc memory corruption (and general amr(4) problems with
the PERC4) at:


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

~BAS

> poweredge 1950, but it failed completely on the poweredge 1850. 
> 
> Facts:
> 
> - boot cd and setup / operation of freebsd 6.x or 7.0 is fine
>    Message log abstract: 
> 	$ uname -v
> 	FreeBSD 7.0-RELEASE-p7 #0: Sun Dec 21 08:31:52 UTC 2008     root@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC 
> 	$ dmesg|grep amr
> 	amr0: <LSILogic MegaRAID 1.53> mem 0xd80f0000-0xd80fffff,0xdfde0000-0xdfdfffff irq 46 at device 14.0 on pci2
> 	amr0: Using 64-bit DMA
> 	amr0: [ITHREAD]
> 	amr0: delete logical drives supported by controller
> 	amr0: <LSILogic PERC 4e/Si> Firmware 521X, BIOS H430, 256MB RAM
> 	amr0: delete logical drives supported by controller
> 	amrd0: <LSILogic MegaRAID logical drive> on amr0
> 	amrd0: 69880MB (143114240 sectors) RAID 1 (optimal)
> 	Trying to mount root from ufs:/dev/amrd0s1a
> 
> - boot cd of 7.1 fails because the installed doesn't see any harddisk. 
>    Message log abstract:
>     	amr0: adapter is busy
> 	amr0: adapter is busy
> 	amr0: delete logical drives supported by controller
>  
> 
> I also tried to setup 7.0, and then upgrade to 7.1 with freebsd-update,
> but then it fails exactly like with the 7.1 boot CD
> (7.1-RELEASE-amd64-disc1.iso). Screenshot: 
>      http://omx.ch/om/stuff/pe1850bsd71error.jpg
> 
> BIOS Message about the Controller on system startup:
> PowerEdge Expandable RAID COntroller BIOS, (c) 2006 LSI Logic
> Corporation
> 
> I'm not sure what I can try next...  I'd still like to be able to run
> 7.1 on this host as well as on several other old but still fine 1850. Is
> my system simply too old?  Why is my adapter "busy" under 7.1?  What
> would you try?   I checked the relnotes as well, but saw nothing helpful
> about my problem there.
> 
> regards & thanks in advance for any feedback,
> Olivier
> 
> 
> _______________________________________________
> freebsd-hardware@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-hardware
> To unsubscribe, send any mail to "freebsd-hardware-unsubscribe@freebsd.org"

From gerrit at pmp.uni-hannover.de  Wed Feb 11 08:39:09 2009
From: gerrit at pmp.uni-hannover.de (Gerrit =?ISO-8859-1?Q?K=FChn?=)
Date: Wed Feb 11 08:39:16 2009
Subject: zfs crashes with nfs and snapshots
Message-ID: <20090211171110.a8217734.gerrit@pmp.uni-hannover.de>

Hi folks,

I just saw one of my FreeBSD servers (7.0-stable of June 2008) crash while
trying to access the .zfs snapshot directory via a nfs client machine.
The server got a page fault caused by the nfsd process. It wasn't even
able to dump the kernel image anymore.
Resetting the machine it first appeared to come back fine, but shortly
before the login prompt the nfsd let it crash hard again the same way as
before. Then I booted single user, fscked the ufs partitions by hand and
had to re-import the zpool with -f. After that I did another reboot,
whereupon everything was fine again.

As I need that machine I'm a bit unwilling to try accessing the snapshot
directory again via nfs right now. :-)
So here are some questions before I do anything else:
- Did anyone else already see this behaviour?
- Is there something wrong with accessing the snapshot directory via nfs?
- Does zfs stability profit from an update to a recent -stable?

Any answers or further thoughts/hints on this are very welcome.


cu
  Gerrit
From jh at saunalahti.fi  Wed Feb 11 09:55:15 2009
From: jh at saunalahti.fi (Jaakko Heinonen)
Date: Wed Feb 11 09:55:22 2009
Subject: zfs crashes with nfs and snapshots
In-Reply-To: <20090211171110.a8217734.gerrit@pmp.uni-hannover.de>
References: <20090211171110.a8217734.gerrit@pmp.uni-hannover.de>
Message-ID: <20090211175511.GA38986@a91-153-125-115.elisa-laajakaista.fi>

On 2009-02-11, Gerrit K?hn wrote:
> I just saw one of my FreeBSD servers (7.0-stable of June 2008) crash while
> trying to access the .zfs snapshot directory via a nfs client machine.

This is likely the issue described in this message:

http://lists.freebsd.org/pipermail/freebsd-fs/2008-October/005217.html

The nfs fix has been committed to head and stable/7 (7.1-RELEASE has the
fix). The fix prevents system from panicing but you still can't access
the snapshot directory with readdirplus enabled nfs clients. As a
workaround you can disable readdirplus support if your nfs client allows
it.

-- 
Jaakko
From ejk at iki.fi  Wed Feb 11 09:58:12 2009
From: ejk at iki.fi (Esa Karkkainen)
Date: Wed Feb 11 09:58:20 2009
Subject: x48 display messed up with Xorg 7.4
In-Reply-To: <CE2B54D9-C62C-4EF1-96CE-42392BCD7EF8@airwired.net>
References: <CE2B54D9-C62C-4EF1-96CE-42392BCD7EF8@airwired.net>
Message-ID: <20090211172957.GA1342@pp.htv.fi>

On Tue, Feb 10, 2009 at 12:16:28PM -0700, Dan Allen wrote:

> In the recent upgrade to Xorg 7.4 the screen on the calculator is  
> completely screwed up - nothing appears as it should.

I get a garbled x48 "LCD" output and calculator will not turn on.

> I am on a Toshiba Satellite U205 with Intel i810 graphics running 7.1- 
> STABLE.

I'm on Shuttle SN45G with MGA 400 display adapter, running
6.4-RELEASE-p3.

> Has anyone else seen this?

I've got screenshots at:

http://koti.welho.com/ekarkkai/x48_snap_1.jpg
http://koti.welho.com/ekarkkai/x48_snap_2.jpg

I've moved the x48 window to right and screen has several lines of
blinking green dots, which are *not* visible at _1.jpg and are visible
at the _2.jpg.

-- 
"In the beginning the Universe was created. This has made a lot of
people very angry and been widely regarded as a bad move."
        -- Douglas Adams 1952 - 2001
From uwe at laverenz.de  Wed Feb 11 12:46:30 2009
From: uwe at laverenz.de (Uwe Laverenz)
Date: Wed Feb 11 12:46:37 2009
Subject: CFT: ath hal src switchover
In-Reply-To: <49665E35.1050301@errno.com>
References: <49665E35.1050301@errno.com>
Message-ID: <4993368A.5040306@laverenz.de>

Sam Leffler schrieb:

> those changes.  To do this you must have an up to date RELENG_7 code 
> base and then apply this patch:
> 
> http://people.freebsd.org/~sam/ath_hal-releng7.patch
> 
> Then rebuild your kernel.  There should be no changes to user apps.  

I tested this on a Thinkpad R51 / RELENG_7 / Atheros 5212 and I see no 
problems with the patch. It builds and runs fine and doesn't seem to do 
anything harmful. :)

I have a problem with this machine though (with or without your patch): 
the wireless connection seems to be stalled every few minutes. If I try 
to send some traffic over ath0 or make wpa_cli reconnect it comes back 
for another few minutes.

The only cure for now seems to be "ifconfig ath0 -bgscan".

bye,
Uwe

From jhb at freebsd.org  Wed Feb 11 14:13:36 2009
From: jhb at freebsd.org (John Baldwin)
Date: Wed Feb 11 14:13:44 2009
Subject: kld regression
In-Reply-To: <47A20CCB.9020104@icyb.net.ua>
References: <47A0B642.9060000@icyb.net.ua> <200801311152.40064.jhb@freebsd.org>
	<47A20CCB.9020104@icyb.net.ua>
Message-ID: <200902111600.22611.jhb@freebsd.org>

On Thursday 31 January 2008 1:00:43 pm Andriy Gapon wrote:
> on 31/01/2008 18:52 John Baldwin said the following:
> > On Thursday 31 January 2008 10:05:57 am Andriy Gapon wrote:
> >> on 31/01/2008 14:39 Andriy Gapon said the following:
> >>> on 31/01/2008 13:07 John Baldwin said the following:
> >>>> On Wednesday 30 January 2008 12:39:14 pm Andriy Gapon wrote:
> >>>>> The problem is as follows:
> >>>>> 1. put udf_load="YES" in loader.conf
> >>>>> 2. you can mount and unmount udf filesystems
> >>>>> 3. you can kldunload udf if no udf filesystems are mounted
> >>>>> 4. now mount udf fs while udf.ko is unloaded
> >>>>> 5. udf is auto loaded and fs is mounted
> >>>>> 6. unmount fs
> >>>>> 7. try to kldunload udf
> >>>>> kldunload: can't unload file: Device busy
> >>>>> kernel message: kldunload: attempt to unload file that was loaded by 
the
> >>>>> kernel
> >>>>>
> >>>>> Yeah, it was loaded by kernel indeed, but WTF - what is the difference
> >>>>> from manual/loader.conf loading and why I can not manage my modules as 
I
> >>>>> wish?
> >>>> Hmm, the relevant code (vfs_init.c) hasn't changed in 6.x since 6.0.  
> > There 
> >>>> were some changes in 7.0, but this should work in both branches.  What 
is 
> > the 
> >>>> previous release that this worked on?
> >>>>
> >>> Maybe I was wrong when I called this regression, but this was very
> >>> surprising behavior for me. And in 5.X I did a lot of udf
> >>> debugging/experimenting and never encountered such a problem. Maybe I
> >>> always did kldload before mount, I can't tell now.
> >>> Anyway, this seems like an annoyance at the very least, pinning a kernel
> >>> module without any important reasons.
> >>>
> >> Hmm, I found one difference with previous setups: in step 1 I also have
> >> udf_iconv_load="YES" and udf_iconv.ko module is what seems to prevent
> >> udf.ko from unloading in step 7. I can actually unload udf_iconv and
> >> then I am able again to unload udf.
> >>
> >> Still don't understand what is a big difference here.
> >>
> >> And if I had UDF_ICONV built into kernel then I wouldn't have this
> >> work-around.
> > 
> > Ah, I don't think we can safely unload modules loaded from the loader 
IIRC.
> > 
> 
> John,
> 
> maybe there is a small misunderstanding:
> 1. udf.ko and udf_iconv.ko are both loaded by loader - I *can* unload udf.ko
> 2. udf_iconv.ko is loaded by loader but udf.ko is auto-loaded (by
> whatever) when I do mount_udf - I can not unload udf.ko unless I unload
> udf_iconv.ko.
> 
> This is inconsistent and there is no obvious reason for things being
> this way.

VFS_DECLARE_ICONV() in <sys/iconv.h> has always made foo_iconv.ko depend on 
foo.ko from the beginning of its existence.  Thus, udf_iconv.ko has always 
depended on udf.ko.  I think if you had UDF_ICONV in your kernel config 
without UDF it would fail to link.  What I do find odd is that udf_iconv.ko 
worked at all, perhaps the linker resolved it and linked it in when udf.ko 
was loaded, as prior to udf.ko being loaded it was missing a symbol in udf.ko 
it has a reference to.  Either that or the loader was loading udf.ko as a 
dependency and you didn't realize it.

-- 
John Baldwin
From jhb at freebsd.org  Wed Feb 11 14:16:13 2009
From: jhb at freebsd.org (John Baldwin)
Date: Wed Feb 11 14:16:28 2009
Subject: floppy disk controller broken
In-Reply-To: <20080918075306.GA30709@lpthe.jussieu.fr>
References: <20080917150433.GA3585@lpthe.jussieu.fr>
	<200809171713.39694.jhb@freebsd.org>
	<20080918075306.GA30709@lpthe.jussieu.fr>
Message-ID: <200902111602.06646.jhb@freebsd.org>

On Thursday 18 September 2008 3:53:06 am Michel Talon wrote:
> On Wed, Sep 17, 2008 at 05:13:39PM -0400, John Baldwin wrote:
> > On Wednesday 17 September 2008 11:04:33 am Michel Talon wrote:
> > > Hello,
> > > 
> > > when testing FreeBSD-7.1-BETA i discovered that the floppy disk
> > > controller doesn't work correctly. Trying to format a floppy (perhaps
> > > with bad blocks) i get:
> > > Processing fdformat: ioctl(FD_FORM): Device not configured
> > > instead of the normal E letter. I then checked the same problem is
> > > present on FreeBSD-6.3 and it has been reported by Beech Rintoul (*) in 
> > > 2006! Of course the floppy disk driver is particularly messy, but 
> > > this is not pretty.
> > > 
> > > (*) i386/103862: Error with fdformat
> > 
> > It looks like the ioctl to format a track used to never report failures 
from 
> > the controller.  The newer driver does.  What I've done with fdformat is 
to 
> > make it just ignore the errors in userland instead.  Try this:
> > 
> > Index: fdformat.c
> > ===================================================================
> > --- fdformat.c	(revision 183112)
> > +++ fdformat.c	(working copy)
> > @@ -75,8 +75,7 @@
> >  		f.fd_formb_secno(i) = il[i+1];
> >  		f.fd_formb_secsize(i) = secsize;
> >  	}
> > -	if(ioctl(fd, FD_FORM, (caddr_t)&f) < 0)
> > -		err(EX_OSERR, "ioctl(FD_FORM)");
> > +	(void)ioctl(fd, FD_FORM, (caddr_t)&f);
> >  }
> >  
> >  static int
> > 
> > 
> > -- 
> > John Baldwin
> 
> This doesn't work any more. This time i get 
> niobe# fdformat fd0
> Format 1440K floppy `/dev/fd0'? (y/n): y
> Processing EEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEE done.
> 
> where only the first E takes some time to be printed, and all subsequent
> ones are printed instantaneously, that is all other formatting is not
> tried. In principle the formatting process must try each of the
> "sectors" in turn, and can come up with a series of V and F.
> 
> Moreover, trying to write to the floppy:
> niobe# dd if=/dev/zero of=/dev/fd0 conv=noerror
> dd: /dev/fd0: Input/output error
> 5+0 records in
> 4+0 records out
> 2048 bytes transferred in 4.054404 secs (505 bytes/sec)
> 
> I don't expect such result. Traditionnally writing works, while reading
> may fail. Here reading fails with incoherent messages:
> dd: /dev/fd0: Device not configured
> 3+0 records in
> 3+0 records out
> 1536 bytes transferred in 2.595216 secs (592 bytes/sec)
> repeated a large number of times. But nothing in dmesg, contrary to the
> tradition which showed the defective sectors.
> 
> In conclusion i am under the impression that the in kernel driver is
> severely botched. Of course nobody uses floppies any more, but this is
> quite ugly.

There are actually changes to the floppy driver in HEAD that I think address 
this.  I don't recall if they were MFC'd to 7.

-- 
John Baldwin
From jhb at freebsd.org  Wed Feb 11 14:16:19 2009
From: jhb at freebsd.org (John Baldwin)
Date: Wed Feb 11 14:16:29 2009
Subject: Interval timers firing early
In-Reply-To: <20090101024228.GF87057@server.vk2pj.dyndns.org>
References: <20090101024228.GF87057@server.vk2pj.dyndns.org>
Message-ID: <200902111637.04229.jhb@freebsd.org>

On Wednesday 31 December 2008 9:42:28 pm Peter Jeremy wrote:
> I have some code that uses setitimer() to generate one-shot timers of
> ~60s (the intent is to fire ~10msec before the minute boundary).
> 
> On my amd64 laptop running 7.0-stable from mid-March the SIGALRM
> arrives at the expected time.  On a system running a recent amd64
> -current, the SIGALRM arrives about 10msec late (which I'm not too
> fussed about).
> 
> On two i386 systems running 7.1-PRE (from mid-Oct) and a fresh 7.1-RC2
> install, the SIGALRM arrives early - ~11msec for the 7.1-PRE system and
> ~5msec for the 7.1-RC2 system.
> 
> All systems are running HZ=1000.  Two of the systems (the one running
> 7.1-PRE and the one running -current) are running BOINC.  All systems
> are otherwise unloaded.  I've looked at the timer code and can't
> quickly see anything that would explain this.  Does anyone have any
> ideas?
> 
> The relevant code looks like the following:
>     while (1) {
> 	struct timeval		now;
> 	struct itimerval	it;
> 	int			usecs;
> 
> 	if (gettimeofday(&now, NULL) < 0) {
> 	    syslog(LOG_ERR, "gettimeofday: %m");
> 	    exit(1);
> 	}
> 	/* Set timer for just before next minute */
> 	it.it_interval.tv_sec = 0;
> 	it.it_interval.tv_usec = 0;
> 	usecs = 59990000 - ((now.tv_sec % 60) * 1000000 + now.tv_usec);
> 	if (usecs < 10000)	/* allow 10msec slop */
> 	    usecs += 60000000;
> 	it.it_value.tv_sec = usecs / 1000000;
> 	it.it_value.tv_usec = usecs % 1000000;
> 	if (setitimer(ITIMER_REAL, &it, NULL) < 0) {
> 	    syslog(LOG_ERR, "setitimer: %m");
> 	    exit(1);
> 	}
> 	printf("%d.%06ld %2d.%06ld %d\n", now.tv_sec, now.tv_usec,
> 	       it.it_value.tv_sec, it.it_value.tv_usec, usecs);
> 	/* do stuff here which is interrupted by SIGALRM */
>     }
> 
> On the 7.1-PRE system, I get output like:
> 1230776939.991464 59.998536 59998536
> 1230776999.978991  0.011009 11009
> 1230776999.991996 59.998004 59998004
> 1230777059.979532  0.010468 10468
> 1230777059.991538 59.998462 59998462
> 1230777119.979058  0.010942 10942
> 1230777119.991065 59.998935 59998935
> 1230777179.978597  0.011403 11403
> 1230777179.991610 59.998390 59998390
> 1230777239.979139  0.010861 10861
> 1230777239.991142 59.998858 59998858

On a whim, hack kern_tc.c to only use 2 or 3 timehands structures instead of 
64.

-- 
John Baldwin
From gcr+freebsd-stable at tharned.org  Wed Feb 11 14:59:18 2009
From: gcr+freebsd-stable at tharned.org (Greg Rivers)
Date: Wed Feb 11 14:59:25 2009
Subject: Driver for Intel 10GbE adapter
Message-ID: <alpine.BSF.2.00.0902111610130.50877@packrat.tharned.org>

I'm trying to light an Intel 10GbE adapter in an HP DL380 G5 using very 
recent 7.1-STABLE amd64 with GENERIC kernel.  I expected the ixbg(4) 
driver to attach, but it does not.

The labels on the card show:
 	INTEL(R) 10GbE XF SR 2 PORT SERVER ADAPTER
 	893135
 	EXPX9502FXSRGP5

 	001B211170BE 028AD E15728-003


A verbose boot shows the card on the PCI bus, but no driver attaches:

pcib11: <ACPI PCI-PCI bridge> at device 6.0 on pci0
pcib11:   domain            0
pcib11:   secondary bus     23
pcib11:   subordinate bus   23
pcib11:   I/O decode        0x6000-0x6fff
pcib11:   memory decode     0xfde00000-0xfdffffff
pcib11:   no prefetched decode
pci23: <ACPI PCI bus> on pcib11
pci23: domain=0, physical bus=23
found->	vendor=0x8086, dev=0x10c6, revid=0x01
 	domain=0, bus=23, slot=0, func=0
 	class=02-00-00, hdrtype=0x00, mfdev=1
 	cmdreg=0x0047, statreg=0x0010, cachelnsz=16 (dwords)
 	lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns)
 	intpin=a, irq=10
 	powerspec 3  supports D0 D3  current D0
 	MSI supports 1 message, 64 bit
 	MSI-X supports 18 messages in map 0x1c
 	map[10]: type Memory, range 32, base 0xfdfe0000, size 17, enabled
pcib11: requested memory range 0xfdfe0000-0xfdffffff: good
 	map[14]: type Memory, range 32, base 0xfdf80000, size 18, enabled
pcib11: requested memory range 0xfdf80000-0xfdfbffff: good
 	map[18]: type I/O Port, range 32, base 0x6000, size  5, enabled
pcib11: requested I/O range 0x6000-0x601f: in range
 	map[1c]: type Memory, range 32, base 0xfdf70000, size 14, enabled
pcib11: requested memory range 0xfdf70000-0xfdf73fff: good
pcib11: matched entry for 23.0.INTA
pcib11: slot 0 INTA hardwired to IRQ 19
found->	vendor=0x8086, dev=0x10c6, revid=0x01
 	domain=0, bus=23, slot=0, func=1
 	class=02-00-00, hdrtype=0x00, mfdev=1
 	cmdreg=0x0047, statreg=0x0010, cachelnsz=16 (dwords)
 	lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns)
 	intpin=b, irq=5
 	powerspec 3  supports D0 D3  current D0
 	MSI supports 1 message, 64 bit
 	MSI-X supports 18 messages in map 0x1c
 	map[10]: type Memory, range 32, base 0xfdf40000, size 17, enabled
pcib11: requested memory range 0xfdf40000-0xfdf5ffff: good
 	map[14]: type Memory, range 32, base 0xfdf00000, size 18, enabled
pcib11: requested memory range 0xfdf00000-0xfdf3ffff: good
 	map[18]: type I/O Port, range 32, base 0x6020, size  5, enabled
pcib11: requested I/O range 0x6020-0x603f: in range
 	map[1c]: type Memory, range 32, base 0xfdef0000, size 14, enabled
pcib11: requested memory range 0xfdef0000-0xfdef3fff: good
pcib11: matched entry for 23.0.INTB
pcib11: slot 0 INTB hardwired to IRQ 16
pci23: <network, ethernet> at device 0.0 (no driver attached)
pci23: <network, ethernet> at device 0.1 (no driver attached)


pciconf shows:

none0@pci0:23:0:0:	class=0x020000 card=0xa15f8086 chip=0x10c68086 rev=0x01 hdr=0x00
     vendor     = 'Intel Corporation'
     class      = network
     subclass   = ethernet
none1@pci0:23:0:1:	class=0x020000 card=0xa15f8086 chip=0x10c68086 rev=0x01 hdr=0x00
     vendor     = 'Intel Corporation'
     class      = network
     subclass   = ethernet


I thought perhaps it would be a simple matter of adding/updating a card ID 
in the driver header file, but I see that sys/dev/ixgb/ixgb_ids.h already 
contains an entry for 0xA15F as listed above.

Does anyone have experience with this card or know how to get it to probe 
and attach?  Thanks!

-- 
Greg Rivers
From bengta at sics.se  Wed Feb 11 15:05:48 2009
From: bengta at sics.se (Bengt Ahlgren)
Date: Wed Feb 11 15:05:56 2009
Subject: CFT: ath hal src switchover
In-Reply-To: <4993368A.5040306@laverenz.de> (Uwe Laverenz's message of "Wed\,
	11 Feb 2009 21\:35\:22 +0100")
References: <49665E35.1050301@errno.com> <4993368A.5040306@laverenz.de>
Message-ID: <uh7tz70siya.fsf@P142.sics.se>

Uwe Laverenz <uwe@laverenz.de> writes:

> Sam Leffler schrieb:
>
>> those changes.  To do this you must have an up to date RELENG_7 code
>> base and then apply this patch:
>>
>> http://people.freebsd.org/~sam/ath_hal-releng7.patch
>>
>> Then rebuild your kernel.  There should be no changes to user apps.  
>
> I tested this on a Thinkpad R51 / RELENG_7 / Atheros 5212 and I see no
> problems with the patch. It builds and runs fine and doesn't seem to
> do anything harmful. :)
>
> I have a problem with this machine though (with or without your
> patch): the wireless connection seems to be stalled every few
> minutes. If I try to send some traffic over ath0 or make wpa_cli
> reconnect it comes back for another few minutes.
>
> The only cure for now seems to be "ifconfig ath0 -bgscan".

That sounds like it can be the same symptoms as I described on the
freebsd-mobile list earlier this week:

http://lists.freebsd.org/pipermail/freebsd-mobile/2009-February/011343.html

What clockrate do you run at?  On my system (Thinkpad X40, Atheros
5212) the problem does not occur at kern.hz=1000, but it is present at
kern.hz=100.

Tomorrow evening I will investigate this further including testing if
"ifconfig ath0 -bgscan" makes a difference for me.

Bengt
From sam at errno.com  Wed Feb 11 15:09:27 2009
From: sam at errno.com (Sam Leffler)
Date: Wed Feb 11 15:09:34 2009
Subject: CFT: ath hal src switchover
In-Reply-To: <uh7tz70siya.fsf@P142.sics.se>
References: <49665E35.1050301@errno.com> <4993368A.5040306@laverenz.de>
	<uh7tz70siya.fsf@P142.sics.se>
Message-ID: <49935AA5.4010408@errno.com>

Bengt Ahlgren wrote:
> Uwe Laverenz <uwe@laverenz.de> writes:
>
>   
>> Sam Leffler schrieb:
>>
>>     
>>> those changes.  To do this you must have an up to date RELENG_7 code
>>> base and then apply this patch:
>>>
>>> http://people.freebsd.org/~sam/ath_hal-releng7.patch
>>>
>>> Then rebuild your kernel.  There should be no changes to user apps.  
>>>       
>> I tested this on a Thinkpad R51 / RELENG_7 / Atheros 5212 and I see no
>> problems with the patch. It builds and runs fine and doesn't seem to
>> do anything harmful. :)
>>
>> I have a problem with this machine though (with or without your
>> patch): the wireless connection seems to be stalled every few
>> minutes. If I try to send some traffic over ath0 or make wpa_cli
>> reconnect it comes back for another few minutes.
>>
>> The only cure for now seems to be "ifconfig ath0 -bgscan".
>>     
>
> That sounds like it can be the same symptoms as I described on the
> freebsd-mobile list earlier this week:
>
> http://lists.freebsd.org/pipermail/freebsd-mobile/2009-February/011343.html
>
> What clockrate do you run at?  On my system (Thinkpad X40, Atheros
> 5212) the problem does not occur at kern.hz=1000, but it is present at
> kern.hz=100.
>
> Tomorrow evening I will investigate this further including testing if
> "ifconfig ath0 -bgscan" makes a difference for me.
>   

There are many many changes to the ath driver in head that are not in 
stable.  If I can get confidence in the hal backport I can try to bring 
back some of those.  But I need to do things in the proper order; I 
can't backmerge a bunch of stuff, find something is broken, and then 
have to bisect changes.  So people need to help get the hal code in 
place first.

    Sam

From pluknet at gmail.com  Wed Feb 11 15:21:05 2009
From: pluknet at gmail.com (pluknet)
Date: Wed Feb 11 15:21:12 2009
Subject: Driver for Intel 10GbE adapter
In-Reply-To: <alpine.BSF.2.00.0902111610130.50877@packrat.tharned.org>
References: <alpine.BSF.2.00.0902111610130.50877@packrat.tharned.org>
Message-ID: <a31046fc0902111521r357ec438p5847a8fd53cc10a5@mail.gmail.com>

Hi.

2009/2/12 Greg Rivers <gcr+freebsd-stable@tharned.org>:
> I'm trying to light an Intel 10GbE adapter in an HP DL380 G5 using very
> recent 7.1-STABLE amd64 with GENERIC kernel.  I expected the ixbg(4) driver
> to attach, but it does not.
>
> The labels on the card show:
>        INTEL(R) 10GbE XF SR 2 PORT SERVER ADAPTER
>        893135
>        EXPX9502FXSRGP5
>
>        001B211170BE 028AD E15728-003
>
>
> A verbose boot shows the card on the PCI bus, but no driver attaches:
>
> pcib11: <ACPI PCI-PCI bridge> at device 6.0 on pci0
> pcib11:   domain            0
> pcib11:   secondary bus     23
> pcib11:   subordinate bus   23
> pcib11:   I/O decode        0x6000-0x6fff
> pcib11:   memory decode     0xfde00000-0xfdffffff
> pcib11:   no prefetched decode
> pci23: <ACPI PCI bus> on pcib11
> pci23: domain=0, physical bus=23
> found-> vendor=0x8086, dev=0x10c6, revid=0x01
>        domain=0, bus=23, slot=0, func=0
>        class=02-00-00, hdrtype=0x00, mfdev=1
>        cmdreg=0x0047, statreg=0x0010, cachelnsz=16 (dwords)
>        lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns)
>        intpin=a, irq=10
>        powerspec 3  supports D0 D3  current D0
>        MSI supports 1 message, 64 bit
>        MSI-X supports 18 messages in map 0x1c
>        map[10]: type Memory, range 32, base 0xfdfe0000, size 17, enabled
> pcib11: requested memory range 0xfdfe0000-0xfdffffff: good
>        map[14]: type Memory, range 32, base 0xfdf80000, size 18, enabled
> pcib11: requested memory range 0xfdf80000-0xfdfbffff: good
>        map[18]: type I/O Port, range 32, base 0x6000, size  5, enabled
> pcib11: requested I/O range 0x6000-0x601f: in range
>        map[1c]: type Memory, range 32, base 0xfdf70000, size 14, enabled
> pcib11: requested memory range 0xfdf70000-0xfdf73fff: good
> pcib11: matched entry for 23.0.INTA
> pcib11: slot 0 INTA hardwired to IRQ 19
> found-> vendor=0x8086, dev=0x10c6, revid=0x01
>        domain=0, bus=23, slot=0, func=1
>        class=02-00-00, hdrtype=0x00, mfdev=1
>        cmdreg=0x0047, statreg=0x0010, cachelnsz=16 (dwords)
>        lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns)
>        intpin=b, irq=5
>        powerspec 3  supports D0 D3  current D0
>        MSI supports 1 message, 64 bit
>        MSI-X supports 18 messages in map 0x1c
>        map[10]: type Memory, range 32, base 0xfdf40000, size 17, enabled
> pcib11: requested memory range 0xfdf40000-0xfdf5ffff: good
>        map[14]: type Memory, range 32, base 0xfdf00000, size 18, enabled
> pcib11: requested memory range 0xfdf00000-0xfdf3ffff: good
>        map[18]: type I/O Port, range 32, base 0x6020, size  5, enabled
> pcib11: requested I/O range 0x6020-0x603f: in range
>        map[1c]: type Memory, range 32, base 0xfdef0000, size 14, enabled
> pcib11: requested memory range 0xfdef0000-0xfdef3fff: good
> pcib11: matched entry for 23.0.INTB
> pcib11: slot 0 INTB hardwired to IRQ 16
> pci23: <network, ethernet> at device 0.0 (no driver attached)
> pci23: <network, ethernet> at device 0.1 (no driver attached)
>
>
> pciconf shows:
>
> none0@pci0:23:0:0:      class=0x020000 card=0xa15f8086 chip=0x10c68086
> rev=0x01 hdr=0x00
>    vendor     = 'Intel Corporation'
>    class      = network
>    subclass   = ethernet
> none1@pci0:23:0:1:      class=0x020000 card=0xa15f8086 chip=0x10c68086
> rev=0x01 hdr=0x00
>    vendor     = 'Intel Corporation'
>    class      = network
>    subclass   = ethernet

You probably want to load ixgbe(4), not ixgb(4) (latter is afaik an
older PCI-X version driver).
The labels on the card are close to the description of ixgbe.
Note, it's not in GENERIC.

-- 
wbr,
pluknet
From jfvogel at gmail.com  Wed Feb 11 15:33:48 2009
From: jfvogel at gmail.com (Jack Vogel)
Date: Wed Feb 11 15:33:55 2009
Subject: Driver for Intel 10GbE adapter
In-Reply-To: <a31046fc0902111521r357ec438p5847a8fd53cc10a5@mail.gmail.com>
References: <alpine.BSF.2.00.0902111610130.50877@packrat.tharned.org>
	<a31046fc0902111521r357ec438p5847a8fd53cc10a5@mail.gmail.com>
Message-ID: <2a41acea0902111533u4fc7cb72h21ce0c10bb33c823@mail.gmail.com>

On Wed, Feb 11, 2009 at 3:21 PM, pluknet <pluknet@gmail.com> wrote:

> Hi.
>
> 2009/2/12 Greg Rivers <gcr+freebsd-stable@tharned.org<gcr%2Bfreebsd-stable@tharned.org>
> >:
> > I'm trying to light an Intel 10GbE adapter in an HP DL380 G5 using very
> > recent 7.1-STABLE amd64 with GENERIC kernel.  I expected the ixbg(4)
> driver
> > to attach, but it does not.
> >
> > The labels on the card show:
> >        INTEL(R) 10GbE XF SR 2 PORT SERVER ADAPTER
> >        893135
> >        EXPX9502FXSRGP5
> >
> >        001B211170BE 028AD E15728-003
> >
> >
> > A verbose boot shows the card on the PCI bus, but no driver attaches:
> >
> > pcib11: <ACPI PCI-PCI bridge> at device 6.0 on pci0
> > pcib11:   domain            0
> > pcib11:   secondary bus     23
> > pcib11:   subordinate bus   23
> > pcib11:   I/O decode        0x6000-0x6fff
> > pcib11:   memory decode     0xfde00000-0xfdffffff
> > pcib11:   no prefetched decode
> > pci23: <ACPI PCI bus> on pcib11
> > pci23: domain=0, physical bus=23
> > found-> vendor=0x8086, dev=0x10c6, revid=0x01
> >        domain=0, bus=23, slot=0, func=0
> >        class=02-00-00, hdrtype=0x00, mfdev=1
> >        cmdreg=0x0047, statreg=0x0010, cachelnsz=16 (dwords)
> >        lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns)
> >        intpin=a, irq=10
> >        powerspec 3  supports D0 D3  current D0
> >        MSI supports 1 message, 64 bit
> >        MSI-X supports 18 messages in map 0x1c
> >        map[10]: type Memory, range 32, base 0xfdfe0000, size 17, enabled
> > pcib11: requested memory range 0xfdfe0000-0xfdffffff: good
> >        map[14]: type Memory, range 32, base 0xfdf80000, size 18, enabled
> > pcib11: requested memory range 0xfdf80000-0xfdfbffff: good
> >        map[18]: type I/O Port, range 32, base 0x6000, size  5, enabled
> > pcib11: requested I/O range 0x6000-0x601f: in range
> >        map[1c]: type Memory, range 32, base 0xfdf70000, size 14, enabled
> > pcib11: requested memory range 0xfdf70000-0xfdf73fff: good
> > pcib11: matched entry for 23.0.INTA
> > pcib11: slot 0 INTA hardwired to IRQ 19
> > found-> vendor=0x8086, dev=0x10c6, revid=0x01
> >        domain=0, bus=23, slot=0, func=1
> >        class=02-00-00, hdrtype=0x00, mfdev=1
> >        cmdreg=0x0047, statreg=0x0010, cachelnsz=16 (dwords)
> >        lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns)
> >        intpin=b, irq=5
> >        powerspec 3  supports D0 D3  current D0
> >        MSI supports 1 message, 64 bit
> >        MSI-X supports 18 messages in map 0x1c
> >        map[10]: type Memory, range 32, base 0xfdf40000, size 17, enabled
> > pcib11: requested memory range 0xfdf40000-0xfdf5ffff: good
> >        map[14]: type Memory, range 32, base 0xfdf00000, size 18, enabled
> > pcib11: requested memory range 0xfdf00000-0xfdf3ffff: good
> >        map[18]: type I/O Port, range 32, base 0x6020, size  5, enabled
> > pcib11: requested I/O range 0x6020-0x603f: in range
> >        map[1c]: type Memory, range 32, base 0xfdef0000, size 14, enabled
> > pcib11: requested memory range 0xfdef0000-0xfdef3fff: good
> > pcib11: matched entry for 23.0.INTB
> > pcib11: slot 0 INTB hardwired to IRQ 16
> > pci23: <network, ethernet> at device 0.0 (no driver attached)
> > pci23: <network, ethernet> at device 0.1 (no driver attached)
> >
> >
> > pciconf shows:
> >
> > none0@pci0:23:0:0:      class=0x020000 card=0xa15f8086 chip=0x10c68086
> > rev=0x01 hdr=0x00
> >    vendor     = 'Intel Corporation'
> >    class      = network
> >    subclass   = ethernet
> > none1@pci0:23:0:1:      class=0x020000 card=0xa15f8086 chip=0x10c68086
> > rev=0x01 hdr=0x00
> >    vendor     = 'Intel Corporation'
> >    class      = network
> >    subclass   = ethernet
>
> You probably want to load ixgbe(4), not ixgb(4) (latter is afaik an
> older PCI-X version driver).
> The labels on the card are close to the description of ixgbe.
> Note, it's not in GENERIC.
>

Yes, its an Oplin, 82598, it uses my ixgbe driver rather than ixgb.

Cheers,

Jack
From kmacy at freebsd.org  Wed Feb 11 15:45:02 2009
From: kmacy at freebsd.org (Kip Macy)
Date: Wed Feb 11 15:45:09 2009
Subject: Driver for Intel 10GbE adapter
In-Reply-To: <alpine.BSF.2.00.0902111610130.50877@packrat.tharned.org>
References: <alpine.BSF.2.00.0902111610130.50877@packrat.tharned.org>
Message-ID: <3c1674c90902111521n2e32c6e9h8b532df0db48475a@mail.gmail.com>

see ixgbe(4)

On Wed, Feb 11, 2009 at 2:43 PM, Greg Rivers
<gcr+freebsd-stable@tharned.org> wrote:
> I'm trying to light an Intel 10GbE adapter in an HP DL380 G5 using very
> recent 7.1-STABLE amd64 with GENERIC kernel.  I expected the ixbg(4) driver
> to attach, but it does not.
>
> The labels on the card show:
>        INTEL(R) 10GbE XF SR 2 PORT SERVER ADAPTER
>        893135
>        EXPX9502FXSRGP5
>
>        001B211170BE 028AD E15728-003
>
>
> A verbose boot shows the card on the PCI bus, but no driver attaches:
>
> pcib11: <ACPI PCI-PCI bridge> at device 6.0 on pci0
> pcib11:   domain            0
> pcib11:   secondary bus     23
> pcib11:   subordinate bus   23
> pcib11:   I/O decode        0x6000-0x6fff
> pcib11:   memory decode     0xfde00000-0xfdffffff
> pcib11:   no prefetched decode
> pci23: <ACPI PCI bus> on pcib11
> pci23: domain=0, physical bus=23
> found-> vendor=0x8086, dev=0x10c6, revid=0x01
>        domain=0, bus=23, slot=0, func=0
>        class=02-00-00, hdrtype=0x00, mfdev=1
>        cmdreg=0x0047, statreg=0x0010, cachelnsz=16 (dwords)
>        lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns)
>        intpin=a, irq=10
>        powerspec 3  supports D0 D3  current D0
>        MSI supports 1 message, 64 bit
>        MSI-X supports 18 messages in map 0x1c
>        map[10]: type Memory, range 32, base 0xfdfe0000, size 17, enabled
> pcib11: requested memory range 0xfdfe0000-0xfdffffff: good
>        map[14]: type Memory, range 32, base 0xfdf80000, size 18, enabled
> pcib11: requested memory range 0xfdf80000-0xfdfbffff: good
>        map[18]: type I/O Port, range 32, base 0x6000, size  5, enabled
> pcib11: requested I/O range 0x6000-0x601f: in range
>        map[1c]: type Memory, range 32, base 0xfdf70000, size 14, enabled
> pcib11: requested memory range 0xfdf70000-0xfdf73fff: good
> pcib11: matched entry for 23.0.INTA
> pcib11: slot 0 INTA hardwired to IRQ 19
> found-> vendor=0x8086, dev=0x10c6, revid=0x01
>        domain=0, bus=23, slot=0, func=1
>        class=02-00-00, hdrtype=0x00, mfdev=1
>        cmdreg=0x0047, statreg=0x0010, cachelnsz=16 (dwords)
>        lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns)
>        intpin=b, irq=5
>        powerspec 3  supports D0 D3  current D0
>        MSI supports 1 message, 64 bit
>        MSI-X supports 18 messages in map 0x1c
>        map[10]: type Memory, range 32, base 0xfdf40000, size 17, enabled
> pcib11: requested memory range 0xfdf40000-0xfdf5ffff: good
>        map[14]: type Memory, range 32, base 0xfdf00000, size 18, enabled
> pcib11: requested memory range 0xfdf00000-0xfdf3ffff: good
>        map[18]: type I/O Port, range 32, base 0x6020, size  5, enabled
> pcib11: requested I/O range 0x6020-0x603f: in range
>        map[1c]: type Memory, range 32, base 0xfdef0000, size 14, enabled
> pcib11: requested memory range 0xfdef0000-0xfdef3fff: good
> pcib11: matched entry for 23.0.INTB
> pcib11: slot 0 INTB hardwired to IRQ 16
> pci23: <network, ethernet> at device 0.0 (no driver attached)
> pci23: <network, ethernet> at device 0.1 (no driver attached)
>
>
> pciconf shows:
>
> none0@pci0:23:0:0:      class=0x020000 card=0xa15f8086 chip=0x10c68086
> rev=0x01 hdr=0x00
>    vendor     = 'Intel Corporation'
>    class      = network
>    subclass   = ethernet
> none1@pci0:23:0:1:      class=0x020000 card=0xa15f8086 chip=0x10c68086
> rev=0x01 hdr=0x00
>    vendor     = 'Intel Corporation'
>    class      = network
>    subclass   = ethernet
>
>
> I thought perhaps it would be a simple matter of adding/updating a card ID
> in the driver header file, but I see that sys/dev/ixgb/ixgb_ids.h already
> contains an entry for 0xA15F as listed above.
>
> Does anyone have experience with this card or know how to get it to probe
> and attach?  Thanks!
>
> --
> Greg Rivers
> _______________________________________________
> 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 pluknet at gmail.com  Wed Feb 11 15:57:51 2009
From: pluknet at gmail.com (pluknet)
Date: Wed Feb 11 15:57:57 2009
Subject: Driver for Intel 10GbE adapter
In-Reply-To: <3c1674c90902111521n2e32c6e9h8b532df0db48475a@mail.gmail.com>
References: <alpine.BSF.2.00.0902111610130.50877@packrat.tharned.org>
	<3c1674c90902111521n2e32c6e9h8b532df0db48475a@mail.gmail.com>
Message-ID: <a31046fc0902111557p41ebc9afkf9124528bd11c9cc@mail.gmail.com>

2009/2/12 Kip Macy <kmacy@freebsd.org>:
> see ixgbe(4)

BTW I'm afraid ixgbe manpage still to be merged to 7.

>
> On Wed, Feb 11, 2009 at 2:43 PM, Greg Rivers
> <gcr+freebsd-stable@tharned.org> wrote:
>> I'm trying to light an Intel 10GbE adapter in an HP DL380 G5 using very
>> recent 7.1-STABLE amd64 with GENERIC kernel.  I expected the ixbg(4) driver
>> to attach, but it does not.
>>
>> The labels on the card show:
>>        INTEL(R) 10GbE XF SR 2 PORT SERVER ADAPTER
>>        893135
>>        EXPX9502FXSRGP5
>>
>>        001B211170BE 028AD E15728-003
>>
>>
>> A verbose boot shows the card on the PCI bus, but no driver attaches:
>>
>> pcib11: <ACPI PCI-PCI bridge> at device 6.0 on pci0
>> pcib11:   domain            0
>> pcib11:   secondary bus     23
>> pcib11:   subordinate bus   23
>> pcib11:   I/O decode        0x6000-0x6fff
>> pcib11:   memory decode     0xfde00000-0xfdffffff
>> pcib11:   no prefetched decode
>> pci23: <ACPI PCI bus> on pcib11
>> pci23: domain=0, physical bus=23
>> found-> vendor=0x8086, dev=0x10c6, revid=0x01
>>        domain=0, bus=23, slot=0, func=0
>>        class=02-00-00, hdrtype=0x00, mfdev=1
>>        cmdreg=0x0047, statreg=0x0010, cachelnsz=16 (dwords)
>>        lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns)
>>        intpin=a, irq=10
>>        powerspec 3  supports D0 D3  current D0
>>        MSI supports 1 message, 64 bit
>>        MSI-X supports 18 messages in map 0x1c
>>        map[10]: type Memory, range 32, base 0xfdfe0000, size 17, enabled
>> pcib11: requested memory range 0xfdfe0000-0xfdffffff: good
>>        map[14]: type Memory, range 32, base 0xfdf80000, size 18, enabled
>> pcib11: requested memory range 0xfdf80000-0xfdfbffff: good
>>        map[18]: type I/O Port, range 32, base 0x6000, size  5, enabled
>> pcib11: requested I/O range 0x6000-0x601f: in range
>>        map[1c]: type Memory, range 32, base 0xfdf70000, size 14, enabled
>> pcib11: requested memory range 0xfdf70000-0xfdf73fff: good
>> pcib11: matched entry for 23.0.INTA
>> pcib11: slot 0 INTA hardwired to IRQ 19
>> found-> vendor=0x8086, dev=0x10c6, revid=0x01
>>        domain=0, bus=23, slot=0, func=1
>>        class=02-00-00, hdrtype=0x00, mfdev=1
>>        cmdreg=0x0047, statreg=0x0010, cachelnsz=16 (dwords)
>>        lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns)
>>        intpin=b, irq=5
>>        powerspec 3  supports D0 D3  current D0
>>        MSI supports 1 message, 64 bit
>>        MSI-X supports 18 messages in map 0x1c
>>        map[10]: type Memory, range 32, base 0xfdf40000, size 17, enabled
>> pcib11: requested memory range 0xfdf40000-0xfdf5ffff: good
>>        map[14]: type Memory, range 32, base 0xfdf00000, size 18, enabled
>> pcib11: requested memory range 0xfdf00000-0xfdf3ffff: good
>>        map[18]: type I/O Port, range 32, base 0x6020, size  5, enabled
>> pcib11: requested I/O range 0x6020-0x603f: in range
>>        map[1c]: type Memory, range 32, base 0xfdef0000, size 14, enabled
>> pcib11: requested memory range 0xfdef0000-0xfdef3fff: good
>> pcib11: matched entry for 23.0.INTB
>> pcib11: slot 0 INTB hardwired to IRQ 16
>> pci23: <network, ethernet> at device 0.0 (no driver attached)
>> pci23: <network, ethernet> at device 0.1 (no driver attached)
>>
>>
>> pciconf shows:
>>
>> none0@pci0:23:0:0:      class=0x020000 card=0xa15f8086 chip=0x10c68086
>> rev=0x01 hdr=0x00
>>    vendor     = 'Intel Corporation'
>>    class      = network
>>    subclass   = ethernet
>> none1@pci0:23:0:1:      class=0x020000 card=0xa15f8086 chip=0x10c68086
>> rev=0x01 hdr=0x00
>>    vendor     = 'Intel Corporation'
>>    class      = network
>>    subclass   = ethernet
>>
>>
>> I thought perhaps it would be a simple matter of adding/updating a card ID
>> in the driver header file, but I see that sys/dev/ixgb/ixgb_ids.h already
>> contains an entry for 0xA15F as listed above.
>>
>> Does anyone have experience with this card or know how to get it to probe
>> and attach?  Thanks!
>>
>> --
>> Greg Rivers
>> _______________________________________________
>> 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"
>



-- 
wbr,
pluknet
From gcr+freebsd-stable at tharned.org  Wed Feb 11 17:16:56 2009
From: gcr+freebsd-stable at tharned.org (Greg Rivers)
Date: Wed Feb 11 17:17:03 2009
Subject: Driver for Intel 10GbE adapter
In-Reply-To: <a31046fc0902111557p41ebc9afkf9124528bd11c9cc@mail.gmail.com>
References: <alpine.BSF.2.00.0902111610130.50877@packrat.tharned.org>
	<3c1674c90902111521n2e32c6e9h8b532df0db48475a@mail.gmail.com>
	<a31046fc0902111557p41ebc9afkf9124528bd11c9cc@mail.gmail.com>
Message-ID: <alpine.BSF.2.00.0902111844330.88332@packrat.tharned.org>

On Thu, 12 Feb 2009, pluknet wrote:

> You probably want to load ixgbe(4), not ixgb(4) (latter is afaik an 
> older PCI-X version driver). The labels on the card are close to the 
> description of ixgbe. Note, it's not in GENERIC.
>

On Wed, 11 Feb 2009, Jack Vogel wrote:

> Yes, its an Oplin, 82598, it uses my ixgbe driver rather than ixgb.
>

On Wed, 11 Feb 2009, Kip Macy wrote:

> see ixgbe(4)
>

I saw ixgbe in the source tree and would have tried it, but I found that 
no kernel module is built for ixgbe on RELENG_7.  Neither is the device 
listed even as a comment in any stock config file.  This and the lack of a 
manual page led me to believe it wasn't available.


On Thu, 12 Feb 2009, pluknet wrote:

> BTW I'm afraid ixgbe manpage still to be merged to 7.
>

It may be that more than just the man page remains to be merged.  When I 
add "device ixgbe" to the GENERIC config and try to build a new kernel I 
get:

In file included from /usr/src/sys/dev/ixgbe/ixgbe.c:39:
/usr/src/sys/dev/ixgbe/ixgbe.h:87:21: error: tcp_lro.h: No such file or 
directory
mkdep: compile failed
*** Error code 1

Stop in /usr/obj/usr/src/sys/GENERIC.
*** Error code 1

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

Stop in /usr/src.


Is there any hope of seeing ixgbe fully merged into RELENG_7 soon, or is 
my best bet to switch to CURRENT?  Thank you all for your help.

-- 
Greg Rivers
From jfvogel at gmail.com  Wed Feb 11 17:37:48 2009
From: jfvogel at gmail.com (Jack Vogel)
Date: Wed Feb 11 17:37:55 2009
Subject: Driver for Intel 10GbE adapter
In-Reply-To: <alpine.BSF.2.00.0902111844330.88332@packrat.tharned.org>
References: <alpine.BSF.2.00.0902111610130.50877@packrat.tharned.org>
	<3c1674c90902111521n2e32c6e9h8b532df0db48475a@mail.gmail.com>
	<a31046fc0902111557p41ebc9afkf9124528bd11c9cc@mail.gmail.com>
	<alpine.BSF.2.00.0902111844330.88332@packrat.tharned.org>
Message-ID: <2a41acea0902111737s2d0d4176l36f14bbda82add35@mail.gmail.com>

Somehow that error was corrected but just AFTER the release. Its a simple
fix, look at
ixgbe.h in CVS to see it,  you just get rid of the "tcp_lro.h" and change it
to <netinet/tcp_lro.h>

There will be a new code drop soon also.

Jack


On Wed, Feb 11, 2009 at 5:16 PM, Greg Rivers
<gcr+freebsd-stable@tharned.org<gcr%2Bfreebsd-stable@tharned.org>
> wrote:

> On Thu, 12 Feb 2009, pluknet wrote:
>
>  You probably want to load ixgbe(4), not ixgb(4) (latter is afaik an older
>> PCI-X version driver). The labels on the card are close to the description
>> of ixgbe. Note, it's not in GENERIC.
>>
>>
> On Wed, 11 Feb 2009, Jack Vogel wrote:
>
>  Yes, its an Oplin, 82598, it uses my ixgbe driver rather than ixgb.
>>
>>
> On Wed, 11 Feb 2009, Kip Macy wrote:
>
>  see ixgbe(4)
>>
>>
> I saw ixgbe in the source tree and would have tried it, but I found that no
> kernel module is built for ixgbe on RELENG_7.  Neither is the device listed
> even as a comment in any stock config file.  This and the lack of a manual
> page led me to believe it wasn't available.
>
>
> On Thu, 12 Feb 2009, pluknet wrote:
>
>  BTW I'm afraid ixgbe manpage still to be merged to 7.
>>
>>
> It may be that more than just the man page remains to be merged.  When I
> add "device ixgbe" to the GENERIC config and try to build a new kernel I
> get:
>
> In file included from /usr/src/sys/dev/ixgbe/ixgbe.c:39:
> /usr/src/sys/dev/ixgbe/ixgbe.h:87:21: error: tcp_lro.h: No such file or
> directory
> mkdep: compile failed
> *** Error code 1
>
> Stop in /usr/obj/usr/src/sys/GENERIC.
> *** Error code 1
>
> Stop in /usr/src.
> *** Error code 1
>
> Stop in /usr/src.
>
>
> Is there any hope of seeing ixgbe fully merged into RELENG_7 soon, or is my
> best bet to switch to CURRENT?  Thank you all for your help.
>
> --
> Greg Rivers
>
From admin at stardothosting.com  Wed Feb 11 18:12:42 2009
From: admin at stardothosting.com (SDH Support)
Date: Wed Feb 11 18:12:50 2009
Subject: FBSD 7.1 XEON Quad Core
In-Reply-To: <gmkfbs$fjr$1@ger.gmane.org>
References: <498CCB85.2080702@paladin.bulgarpress.com>
	<gmkfbs$fjr$1@ger.gmane.org>
Message-ID: <005901c98cb7$5e922670$1bb67350$@com>




> Yes, if you have (or plan to have) more than 3 GB of memory.


FYI I have had a lot of problems with FBSD7.x and HP DL-series hardware + amd64. There is a bug IIRC in the loader.


---
Kevin K.
Systems Administrator
www.stardothosting.com/managed-hosting 


From gcr+freebsd-stable at tharned.org  Wed Feb 11 19:10:40 2009
From: gcr+freebsd-stable at tharned.org (Greg Rivers)
Date: Wed Feb 11 19:10:54 2009
Subject: Driver for Intel 10GbE adapter
In-Reply-To: <2a41acea0902111737s2d0d4176l36f14bbda82add35@mail.gmail.com>
References: <alpine.BSF.2.00.0902111610130.50877@packrat.tharned.org>
	<3c1674c90902111521n2e32c6e9h8b532df0db48475a@mail.gmail.com>
	<a31046fc0902111557p41ebc9afkf9124528bd11c9cc@mail.gmail.com>
	<alpine.BSF.2.00.0902111844330.88332@packrat.tharned.org>
	<2a41acea0902111737s2d0d4176l36f14bbda82add35@mail.gmail.com>
Message-ID: <alpine.BSF.2.00.0902112046540.88332@packrat.tharned.org>

On Wed, 11 Feb 2009, Jack Vogel wrote:

> Somehow that error was corrected but just AFTER the release. Its a 
> simple fix, look at ixgbe.h in CVS to see it, you just get rid of the 
> "tcp_lro.h" and change it to <netinet/tcp_lro.h>
>
> There will be a new code drop soon also.
>

That worked perfectly.  Now I see:

pci23: <ACPI PCI bus> on pcib11
ix0: <Intel(R) PRO/10GbE PCI-Express Network Driver, Version - 1.6.2> port 0x6000-0x601f mem 0xfdfe0000-0xfdffffff,0xfdf80000-0xfdfbffff,0xfdf70000-0xfdf73fff irq 19 at device 0.0 on pci23
ix0: Using MSIX interrupts with 3 vectors
ix0: [ITHREAD]
ix0: [ITHREAD]
ix0: [ITHREAD]
ix0: Ethernet address: 00:1b:21:11:70:8f
ix1: <Intel(R) PRO/10GbE PCI-Express Network Driver, Version - 1.6.2> port 0x6020-0x603f mem 0xfdf40000-0xfdf5ffff,0xfdf00000-0xfdf3ffff,0xfdef0000-0xfdef3fff irq 16 at device 0.1 on pci23
ix1: Using MSIX interrupts with 3 vectors
ix1: [ITHREAD]
ix1: [ITHREAD]
ix1: [ITHREAD]
ix1: Ethernet address: 00:1b:21:11:70:8e

and

ix0@pci0:23:0:0:	class=0x020000 card=0xa15f8086 chip=0x10c68086 rev=0x01 hdr=0x00
     vendor     = 'Intel Corporation'
     class      = network
     subclass   = ethernet
ix1@pci0:23:0:1:	class=0x020000 card=0xa15f8086 chip=0x10c68086 rev=0x01 hdr=0x00
     vendor     = 'Intel Corporation'
     class      = network
     subclass   = ethernet

and

ix0: flags=8802<BROADCAST,SIMPLEX,MULTICAST> metric 0 mtu 1500
 	options=13b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,TSO4>
 	ether 00:1b:21:11:70:8f
 	media: Ethernet autoselect
 	status: no carrier
ix1: flags=8802<BROADCAST,SIMPLEX,MULTICAST> metric 0 mtu 1500
 	options=13b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,TSO4>
 	ether 00:1b:21:11:70:8e
 	media: Ethernet autoselect
 	status: no carrier


Thanks!

-- 
Greg Rivers
From gaijin.k at gmail.com  Wed Feb 11 20:16:20 2009
From: gaijin.k at gmail.com (Alexandre "Sunny" Kovalenko)
Date: Wed Feb 11 20:16:28 2009
Subject: CFT: ath hal src switchover
In-Reply-To: <49935AA5.4010408@errno.com>
References: <49665E35.1050301@errno.com> <4993368A.5040306@laverenz.de>
	<uh7tz70siya.fsf@P142.sics.se>  <49935AA5.4010408@errno.com>
Message-ID: <1234410394.1482.16.camel@RabbitsDen>

On Wed, 2009-02-11 at 15:09 -0800, Sam Leffler wrote:
> Bengt Ahlgren wrote:
> > Uwe Laverenz <uwe@laverenz.de> writes:
> >
> >   
> >> Sam Leffler schrieb:
> >>
> >>     
> >>> those changes.  To do this you must have an up to date RELENG_7 code
> >>> base and then apply this patch:
> >>>
> >>> http://people.freebsd.org/~sam/ath_hal-releng7.patch
> >>>
> >>> Then rebuild your kernel.  There should be no changes to user apps.  
> >>>       
> >> I tested this on a Thinkpad R51 / RELENG_7 / Atheros 5212 and I see no
> >> problems with the patch. It builds and runs fine and doesn't seem to
> >> do anything harmful. :)
> >>
> >> I have a problem with this machine though (with or without your
> >> patch): the wireless connection seems to be stalled every few
> >> minutes. If I try to send some traffic over ath0 or make wpa_cli
> >> reconnect it comes back for another few minutes.
> >>
> >> The only cure for now seems to be "ifconfig ath0 -bgscan".
> >>     
> >
> > That sounds like it can be the same symptoms as I described on the
> > freebsd-mobile list earlier this week:
> >
> > http://lists.freebsd.org/pipermail/freebsd-mobile/2009-February/011343.html
> >
> > What clockrate do you run at?  On my system (Thinkpad X40, Atheros
> > 5212) the problem does not occur at kern.hz=1000, but it is present at
> > kern.hz=100.
> >
> > Tomorrow evening I will investigate this further including testing if
> > "ifconfig ath0 -bgscan" makes a difference for me.
> >   
> 
> There are many many changes to the ath driver in head that are not in 
> stable.  If I can get confidence in the hal backport I can try to bring 
> back some of those.  But I need to do things in the proper order; I 
> can't backmerge a bunch of stuff, find something is broken, and then 
> have to bisect changes.  So people need to help get the hal code in 
> place first.

Patch applied cleanly and works for

ath0@pci0:3:0:0:	class=0x020000 card=0x058a1014 chip=0x1014168c rev=0x01
hdr=0x00
    vendor     = 'Atheros Communications Inc.'
    device     = 'AR5212 Atheros AR5212 802.11abg wireless'
    class      = network
    subclass   = ethernet

ath0: <Atheros 5212> mem 0xedf00000-0xedf0ffff irq 17 at device 0.0 on
pci3
ath0: mac 10.3 phy 6.1 radio 10.2

My -STABLE is of February 5, 2009 about 7AM EST.

I build wireless stuff as modules and load them manually.

If it is of any value, I am using WPA-PSK.

If there is any particular testing that I can perform, or any additional
information that I can provide, please, let me know and I will be happy
to oblige.

Thank you very much for your work.

-- 
Alexandre "Sunny" Kovalenko

From dean at stack.nl  Wed Feb 11 23:25:37 2009
From: dean at stack.nl (Dean Strik)
Date: Wed Feb 11 23:25:43 2009
Subject: FBSD 7.1 XEON Quad Core
In-Reply-To: <005901c98cb7$5e922670$1bb67350$@com>
References: <498CCB85.2080702@paladin.bulgarpress.com>
	<gmkfbs$fjr$1@ger.gmane.org> <005901c98cb7$5e922670$1bb67350$@com>
Message-ID: <20090212072535.GP20905@stack.nl>

SDH Support wrote:
> > Yes, if you have (or plan to have) more than 3 GB of memory.
> 
> FYI I have had a lot of problems with FBSD7.x and HP DL-series hardware + amd64. There is a bug IIRC in the loader.

I have 7.x/amd64 working without problems on DL360/DL380 generations 4
and 5. Can you elaborate on the problems you've had?

-- 
Dean C. Strik             Eindhoven University of Technology
dean@stack.nl  |  dean@ipnet6.org  |  http://www.ipnet6.org/
"This isn't right. This isn't even wrong." -- Wolfgang Pauli
-------------- 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/20090212/05324233/attachment.pgp
From flo at kasimir.com  Thu Feb 12 00:24:07 2009
From: flo at kasimir.com (Florian Smeets)
Date: Thu Feb 12 00:24:15 2009
Subject: FBSD 7.1 XEON Quad Core
In-Reply-To: <005901c98cb7$5e922670$1bb67350$@com>
References: <498CCB85.2080702@paladin.bulgarpress.com>	<gmkfbs$fjr$1@ger.gmane.org>
	<005901c98cb7$5e922670$1bb67350$@com>
Message-ID: <4993DCA2.4000504@kasimir.com>

On 12.02.2009 3:12 Uhr, SDH Support wrote:
>
>
>> Yes, if you have (or plan to have) more than 3 GB of memory.
>
>
> FYI I have had a lot of problems with FBSD7.x and HP DL-series hardware + amd64. There is a bug IIRC in the loader.
>
>

I had problems with DL3X0G5 when booting with PXE, every now an then the 
loader would hang when trying to load the kernel from an i386 8-CURRENT 
NFS server. As soon as i had installed everything and was booting from 
the disks the problem did not show up anymore. I also used amd64.

Do you use PXE boot?

Cheers,
Florian
From danny at cs.huji.ac.il  Thu Feb 12 00:49:58 2009
From: danny at cs.huji.ac.il (Danny Braniss)
Date: Thu Feb 12 00:50:06 2009
Subject: FBSD 7.1 XEON Quad Core 
In-Reply-To: <4993DCA2.4000504@kasimir.com> 
References: <498CCB85.2080702@paladin.bulgarpress.com> 
	<gmkfbs$fjr$1@ger.gmane.org> <005901c98cb7$5e922670$1bb67350$@com> 
	<4993DCA2.4000504@kasimir.com>
Message-ID: <E1LXXGP-0006Zt-LJ@kabab.cs.huji.ac.il>

> On 12.02.2009 3:12 Uhr, SDH Support wrote:
> >
> >
> >> Yes, if you have (or plan to have) more than 3 GB of memory.
> >
> >
> > FYI I have had a lot of problems with FBSD7.x and HP DL-series hardware + amd64. There is a bug IIRC in the loader.
> >
> >
> 
> I had problems with DL3X0G5 when booting with PXE, every now an then the 
> loader would hang when trying to load the kernel from an i386 8-CURRENT 
> NFS server. As soon as i had installed everything and was booting from 
> the disks the problem did not show up anymore. I also used amd64.
> 
> Do you use PXE boot?

pxeboot is problematic on some platforms, try an older version
btw, if you succeed let me know.

thanks
	danny


From uwe at laverenz.de  Thu Feb 12 05:56:39 2009
From: uwe at laverenz.de (Uwe Laverenz)
Date: Thu Feb 12 05:56:46 2009
Subject: CFT: ath hal src switchover
In-Reply-To: <uh7tz70siya.fsf@P142.sics.se>
References: <49665E35.1050301@errno.com> <4993368A.5040306@laverenz.de>
	<uh7tz70siya.fsf@P142.sics.se>
Message-ID: <20090212135320.GB3324@laverenz.de>

On Wed, Feb 11, 2009 at 11:32:45PM +0100, Bengt Ahlgren wrote:

> http://lists.freebsd.org/pipermail/freebsd-mobile/2009-February/011343.html
> 
> What clockrate do you run at?  On my system (Thinkpad X40, Atheros
> 5212) the problem does not occur at kern.hz=1000, but it is present at
> kern.hz=100.

I've tried both, 100 and 1000, same behaviour.

cu,
Uwe

From james.technew at gmail.com  Thu Feb 12 06:22:07 2009
From: james.technew at gmail.com (James Chang)
Date: Thu Feb 12 06:22:14 2009
Subject: FreeBSD 7.1-Stable only support 16 CPUs !?
Message-ID: <a951c2910902120554i18217b75k24956c519b410c05@mail.gmail.com>

Dear all,

    Does any ever try FreeBSD 7.1-stable on box that has more than 16 CPU?

I got a HP ProLiant DL 785 G5 with 32 core (Quad-Core AMD Opteron(tm)
Processor 8356 (2300.10-MHz K8-class CPU) and 256G memory.
When I boot this machine, it could detect 32 core, but only 16 core
could be uesd!?

    What should I do to get FreeBSD 7.1-stable work with 32 core?
Or, FreeBSD 7.1 only support 16 Core Max ?


Best Regards!


               James Chang
From wb at freebie.xs4all.nl  Thu Feb 12 07:12:39 2009
From: wb at freebie.xs4all.nl (Wilko Bulte)
Date: Thu Feb 12 07:12:46 2009
Subject: FreeBSD 7.1-Stable only support 16 CPUs !?
In-Reply-To: <a951c2910902120554i18217b75k24956c519b410c05@mail.gmail.com>
References: <a951c2910902120554i18217b75k24956c519b410c05@mail.gmail.com>
Message-ID: <20090212145909.GE35858@freebie.xs4all.nl>

Quoting James Chang, who wrote on Thu, Feb 12, 2009 at 09:54:00PM +0800 ..
> Dear all,
> 
>     Does any ever try FreeBSD 7.1-stable on box that has more than 16 CPU?
> 
> I got a HP ProLiant DL 785 G5 with 32 core (Quad-Core AMD Opteron(tm)
> Processor 8356 (2300.10-MHz K8-class CPU) and 256G memory.
> When I boot this machine, it could detect 32 core, but only 16 core
> could be uesd!?
> 
>     What should I do to get FreeBSD 7.1-stable work with 32 core?

Buy the project a box like that?

Or kidding aside: this is not the most common hardware, it might be that
you are the first one to try ;-)

	Wilko

> Or, FreeBSD 7.1 only support 16 Core Max ?
> 
> 
> Best Regards!
> 
> 
>                James Chang
> _______________________________________________
> 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"
--- End of quoted text ---
From rwatson at FreeBSD.org  Thu Feb 12 07:23:15 2009
From: rwatson at FreeBSD.org (Robert Watson)
Date: Thu Feb 12 07:23:21 2009
Subject: FreeBSD 7.1-Stable only support 16 CPUs !?
In-Reply-To: <a951c2910902120554i18217b75k24956c519b410c05@mail.gmail.com>
References: <a951c2910902120554i18217b75k24956c519b410c05@mail.gmail.com>
Message-ID: <alpine.BSF.2.00.0902121521030.2205@fledge.watson.org>

On Thu, 12 Feb 2009, James Chang wrote:

>    Does any ever try FreeBSD 7.1-stable on box that has more than 16 CPU?
>
> I got a HP ProLiant DL 785 G5 with 32 core (Quad-Core AMD Opteron(tm) 
> Processor 8356 (2300.10-MHz K8-class CPU) and 256G memory. When I boot this 
> machine, it could detect 32 core, but only 16 core could be uesd!?
>
>    What should I do to get FreeBSD 7.1-stable work with 32 core? Or, FreeBSD 
> 7.1 only support 16 Core Max ?

I can't speak to the specific hardware you have, but one known limitation in 
several versions of FreeBSD is that the MAXCPU constant for i386 and amd64 is 
16.  You can redefine it in src/sys/${arch}/include/param.h and recompile your 
kernel to see the full 32 cores.  You may need to recompile some userspace 
tools in order for them to properly report statistics for all CPUs, so a full 
rebuild of world wouldn't hurt.

Robert N M Watson
Computer Laboratory
University of Cambridge
From pluknet at gmail.com  Thu Feb 12 07:32:35 2009
From: pluknet at gmail.com (pluknet)
Date: Thu Feb 12 07:32:42 2009
Subject: 6.2: LOR between kqueue and mount mtx
Message-ID: <a31046fc0902120730x195f5eb8p460ff425d9febcfd@mail.gmail.com>

Hello.

I'm just curious if ufs_vnops.c#rev1.290 fixes this LOR (or not):

lock order reversal:
 1st 0xcc9d1b00 kqueue (kqueue) @
/usr/src/sys_uvmem_uip.6.2_RELEASE/kern/kern_event.c:1547
 2nd 0xc6d6b854 struct mount mtx (struct mount mtx) @
/usr/src/sys_uvmem_uip.6.2_RELEASE/ufs/ufs/ufs_vnops.c:138
KDB: stack backtrace:
kdb_backtrace(0,ffffffff,c0a61df0,c0a61ee0,c09ce140,...) at kdb_backtrace+0x29
witness_checkorder(c6d6b854,9,c096683a,8a) at witness_checkorder+0x578
_mtx_lock_flags(c6d6b854,0,c096683a,8a,554,...) at _mtx_lock_flags+0x78
ufs_itimes(cbf6c000,cbf6c000,f78c0a5c,c70019d4,cd225048,...) at ufs_itimes+0x58
ufs_getattr(f78c0a5c) at ufs_getattr+0x1e
VOP_GETATTR_APV(c0a09b00,f78c0a5c) at VOP_GETATTR_APV+0x7e
filt_vfsread(c70019d4,6) at filt_vfsread+0x6b
knote(cd225048,6,1) at knote+0x98
VOP_WRITE_APV(c0a09b00,f78c0bf4) at VOP_WRITE_APV+0x186
vn_write(c934c240,f78c0cbc,cc0b0300,0,c93ed7d0) at vn_write+0x1ea
dofilewrite(c93ed7d0,3,c934c240,f78c0cbc,ffffffff,...) at dofilewrite+0x77
kern_writev(c93ed7d0,3,f78c0cbc,8054038,0,...) at kern_writev+0x3b
write(c93ed7d0,f78c0d04) at write+0x45
syscall(3b,3b,3b,8054000,28296da0,...) at syscall+0x22f
Xint0x80_syscall() at Xint0x80_syscall+0x1f
--- syscall (4, FreeBSD ELF32, write), eip = 0x2827232f, esp =
0xbfbfd74c, ebp = 0xbfbfd768 ---

P.S. I've caught this two times (almost at once) today.

-- 
wbr,
pluknet
From pluknet at gmail.com  Thu Feb 12 07:32:46 2009
From: pluknet at gmail.com (pluknet)
Date: Thu Feb 12 07:32:53 2009
Subject: 6.2: LOR between kqueue and mount mtx
In-Reply-To: <a31046fc0902120730x195f5eb8p460ff425d9febcfd@mail.gmail.com>
References: <a31046fc0902120730x195f5eb8p460ff425d9febcfd@mail.gmail.com>
Message-ID: <a31046fc0902120732q42d0488as90eb1dca29a28b78@mail.gmail.com>

2009/2/12 pluknet <pluknet@gmail.com>:
> Hello.
>
> I'm just curious if ufs_vnops.c#rev1.290 fixes this LOR (or not):

I found it was discussed already. Sorry for noise.

-- 
wbr,
pluknet
From repcsike at gmail.com  Thu Feb 12 09:41:30 2009
From: repcsike at gmail.com (Kevin Smith)
Date: Thu Feb 12 09:41:36 2009
Subject: Problem with SATA/SAS 5iR
Message-ID: <c4b701070902120909m1d6e8d0dka8032a612f9139d0@mail.gmail.com>

Hi,

I have a problem with a Dell Poweredge SC440 computer.
It's equipped with a "Dell SATA/SAS 5iR" controller, it's from LSI actually
(maybe megaraid).

I'm using FreeBSD 7.1 Release

I have 2x 500 GB SATA in a synchronised(status optimal) RAID-1 logical
volume.

The machine is brand new, first problem arised early after the installer
started to install the files, the install was very slow, (I know it is
because write cache is not enabled, that can be done with a management
program, and I will enable it later) and sysinstall could not install the
ports collection, the error it gave was
"write error on transfer to cpio process, try of 1024 bytes"   after OK,
write error popped up.

I found this error too, but I found no clue what could have happened.

Installing the system without the ports collection (installed it later with
cvsup)in another run gave no error at all, and in dmesg is see the logical
volume:

mpt0:vol0(mpt0:0:0): Settings ( Hot-Plug-Spares High-Priority-ReSync )
mpt0:vol0(mpt0:0:0): Using Spare Pool: 0
mpt0:vol0(mpt0:0:0): 2 Members:
      (mpt0:1:32: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:1): Physical (mpt0:0:1:0), Pass-thru (mpt0:1:0:0)
(mpt0:vol0:1): Online
(mpt0:vol0:0): Physical (mpt0:0:32:0), Pass-thru (mpt0:1:1:0)
(mpt0:vol0:0): Online
da0 at mpt0 bus 0 target 0 lun 0
da0: <Dell VIRTUAL DISK 1028> Fixed Direct Access SCSI-5 device
da0: 300.000MB/s transfers
da0: 476837MB (976562176 512 byte sectors: 255H 63S/T 60788C)

It looks OK, but then I found this after typing "df -h", and it gives me the
creeps:

Filesystem     Size    Used   Avail Capacity  Mounted on
/dev/da0s1a    496M    138M    318M    30%    /
devfs          1.0K    1.0K      0B   100%    /dev
/dev/da0s1e    3.9G     14K    3.6G     0%    /tmp
/dev/da0s1f    440G    537M    404G     0%    /usr
/dev/da0s1d    2.9G    1.3M    2.7G     0%    /var

I'm reading the freebsd-current list, and I found another buffer related
problem there, but they say nothing about these.

If you have any explanation/solution for these problems pls share them!


Best Regards:

Bal?zs M?t?ffy
From richardtector at thekeelecentre.com  Thu Feb 12 10:03:07 2009
From: richardtector at thekeelecentre.com (Richard Tector)
Date: Thu Feb 12 10:03:16 2009
Subject: Problem with SATA/SAS 5iR
In-Reply-To: <c4b701070902120909m1d6e8d0dka8032a612f9139d0@mail.gmail.com>
References: <c4b701070902120909m1d6e8d0dka8032a612f9139d0@mail.gmail.com>
Message-ID: <4994644D.8070102@thekeelecentre.com>

Kevin Smith wrote:
> Hi,
> 
> I have a problem with a Dell Poweredge SC440 computer.
> It's equipped with a "Dell SATA/SAS 5iR" controller, it's from LSI actually
> (maybe megaraid).
> 
> I'm using FreeBSD 7.1 Release
> 
> I have 2x 500 GB SATA in a synchronised(status optimal) RAID-1 logical
> volume.
> 
> The machine is brand new, first problem arised early after the installer
> started to install the files, the install was very slow, (I know it is
> because write cache is not enabled, that can be done with a management
> program, and I will enable it later) and sysinstall could not install the
> ports collection, the error it gave was
> "write error on transfer to cpio process, try of 1024 bytes"   after OK,
> write error popped up.
> 
> I found this error too, but I found no clue what could have happened.
> 
> Installing the system without the ports collection (installed it later with
> cvsup)in another run gave no error at all, and in dmesg is see the logical
> volume:
> 
> mpt0:vol0(mpt0:0:0): Settings ( Hot-Plug-Spares High-Priority-ReSync )
> mpt0:vol0(mpt0:0:0): Using Spare Pool: 0
> mpt0:vol0(mpt0:0:0): 2 Members:
>       (mpt0:1:32: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:1): Physical (mpt0:0:1:0), Pass-thru (mpt0:1:0:0)
> (mpt0:vol0:1): Online
> (mpt0:vol0:0): Physical (mpt0:0:32:0), Pass-thru (mpt0:1:1:0)
> (mpt0:vol0:0): Online
> da0 at mpt0 bus 0 target 0 lun 0
> da0: <Dell VIRTUAL DISK 1028> Fixed Direct Access SCSI-5 device
> da0: 300.000MB/s transfers
> da0: 476837MB (976562176 512 byte sectors: 255H 63S/T 60788C)
> 
> It looks OK, but then I found this after typing "df -h", and it gives me the
> creeps:
> 
> Filesystem     Size    Used   Avail Capacity  Mounted on
> /dev/da0s1a    496M    138M    318M    30%    /
> devfs          1.0K    1.0K      0B   100%    /dev
> /dev/da0s1e    3.9G     14K    3.6G     0%    /tmp
> /dev/da0s1f    440G    537M    404G     0%    /usr
> /dev/da0s1d    2.9G    1.3M    2.7G     0%    /var
> 
> I'm reading the freebsd-current list, and I found another buffer related
> problem there, but they say nothing about these.
> 
> If you have any explanation/solution for these problems pls share them!
> 
> 

What's wrong with the dmesg? The used/available inconsistencies are due 
to space being reserved.

Regarding disk performance, you need to put hw.mpt.enable_sata_wc=1 in 
/boot/loader.conf to reenable the write cache (it's disabled by default 
for consistency reasons when using SATA disks leading to poor write 
performance).

Regards,

Richard
From ghelmer at palisadesys.com  Thu Feb 12 10:16:16 2009
From: ghelmer at palisadesys.com (Guy Helmer)
Date: Thu Feb 12 10:16:23 2009
Subject: Big problems with 7.1 locking up :-(
In-Reply-To: <49676406.9050902@palisadesys.com>
References: <E1LL6dg-0007CN-DI@dilbert.ticketswitch.com>
	<49676406.9050902@palisadesys.com>
Message-ID: <49946769.1040009@palisadesys.com>

Guy Helmer wrote:
> Pete French wrote:
>> I have a number of HP 1U servers, all of which were running 7.0
>> perfectly happily. I have been testing 7.1 in it's various incarnations
>> for the last couple of months on our test server and it has performed
>> perfectly.
>>
>> So the last two days I have been round upgrading all our servers, 
>> knowing
>> that I had run the system stably on identical hardware for some time.
>>
>> Since then I have starte seeing machines lock up. This always happens 
>> under
>> heavy disc load. When I bring the machine back up then sometimes it 
>> fails
>> to fsck due to a partialy truncated inode. The locksup appear to
>> be disc related - on my mysql msater machine it will come back up with
>> files somewhat shorted than  those which ahve aready been transmitted to
>> the slave (i.e. some data was in memory, and claimed to have been 
>> written
>> to the drive, but never made it onto the disc).
>>
>> The only time I have seen anything useful on the screen was during 
>> one lockup
>> where I got a message about a spin lock being held too long and some
>> comment in parentheses about it being a turnstile lock.
>>
>> Help! :-(
>>
>> I am now downgrading all the machine to 7.0 as fast as I can - though 
>> the
>> machine I am trying to compile it on has locked up once during the 
>> compile
>> so I havent got anywhere so far.
>>
>> The machines are HP Proliant DL360 G5s - they have an embedded P400i
>> RAID controller with a pair of mirrored drives connected. Each one has
>> both ethernets connected, bundled using lagg and LACP.
>>
>>   
> I can't tell whether my situation is related, but I am seeing lockups 
> on SMP Supermicro servers with both older (NetBurst-ish) and current 
> Xeon CPUs.  I have been dropping into the kernel debugger and getting 
> lock information and process backtraces, but so far nothing has been 
> conclusively identified.  I think the issue I'm seeing was introduced 
> sometime between October 2 and November 24 in the RELENG_7 branch, and 
> I suppose the next step is to do a binary search for the offending 
> change.
>
> Guy
>
FWIW, I think I have tracked down the changes just prior to 7.1-RELEASE 
that is causing my Supermicro dual Xeon machines to wedge.  I did the 
binary search between 2008-10-02 and 2008-11-24 without reproducing any 
lockups, and then I went on to search between 2008-11-24 and 
2009-01-04.  An SMP kernel build from 2008-12-22 (r186409) sources was 
stable for over two weeks; a kernel built from 2008-12-29 (r186590) 
sources wedged in under 24 hours under moderate load.

It appears that the significant changes between r186409 and r186590 were 
r186552 (delphij - reverted ATA changes) and r186535/r186534 (delphij - 
reverted bce changes).  My machines don't have bce interfaces, so I 
suspect the ATA changes.

Any thoughts?

Thanks,
Guy

-- 
Guy Helmer, Ph.D.
Chief System Architect
Palisade Systems, Inc.

From repcsike at gmail.com  Thu Feb 12 10:33:13 2009
From: repcsike at gmail.com (Kevin Smith)
Date: Thu Feb 12 10:33:21 2009
Subject: Problem with SATA/SAS 5iR
In-Reply-To: <4994644D.8070102@thekeelecentre.com>
References: <c4b701070902120909m1d6e8d0dka8032a612f9139d0@mail.gmail.com>
	<4994644D.8070102@thekeelecentre.com>
Message-ID: <c4b701070902121033u467e1212g2d43605774ea3249@mail.gmail.com>

2009/2/12 Richard Tector <richardtector@thekeelecentre.com>

> Kevin Smith wrote:
>
>> Hi,
>>
>> I have a problem with a Dell Poweredge SC440 computer.
>> It's equipped with a "Dell SATA/SAS 5iR" controller, it's from LSI
>> actually
>> (maybe megaraid).
>>
>> I'm using FreeBSD 7.1 Release
>>
>> I have 2x 500 GB SATA in a synchronised(status optimal) RAID-1 logical
>> volume.
>>
>> The machine is brand new, first problem arised early after the installer
>> started to install the files, the install was very slow, (I know it is
>> because write cache is not enabled, that can be done with a management
>> program, and I will enable it later) and sysinstall could not install the
>> ports collection, the error it gave was
>> "write error on transfer to cpio process, try of 1024 bytes"   after OK,
>> write error popped up.
>>
>> I found this error too, but I found no clue what could have happened.
>>
>> Installing the system without the ports collection (installed it later
>> with
>> cvsup)in another run gave no error at all, and in dmesg is see the logical
>> volume:
>>
>> mpt0:vol0(mpt0:0:0): Settings ( Hot-Plug-Spares High-Priority-ReSync )
>> mpt0:vol0(mpt0:0:0): Using Spare Pool: 0
>> mpt0:vol0(mpt0:0:0): 2 Members:
>>      (mpt0:1:32: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:1): Physical (mpt0:0:1:0), Pass-thru (mpt0:1:0:0)
>> (mpt0:vol0:1): Online
>> (mpt0:vol0:0): Physical (mpt0:0:32:0), Pass-thru (mpt0:1:1:0)
>> (mpt0:vol0:0): Online
>> da0 at mpt0 bus 0 target 0 lun 0
>> da0: <Dell VIRTUAL DISK 1028> Fixed Direct Access SCSI-5 device
>> da0: 300.000MB/s transfers
>> da0: 476837MB (976562176 512 byte sectors: 255H 63S/T 60788C)
>>
>> It looks OK, but then I found this after typing "df -h", and it gives me
>> the
>> creeps:
>>
>> Filesystem     Size    Used   Avail Capacity  Mounted on
>> /dev/da0s1a    496M    138M    318M    30%    /
>> devfs          1.0K    1.0K      0B   100%    /dev
>> /dev/da0s1e    3.9G     14K    3.6G     0%    /tmp
>> /dev/da0s1f    440G    537M    404G     0%    /usr
>> /dev/da0s1d    2.9G    1.3M    2.7G     0%    /var
>>
>> I'm reading the freebsd-current list, and I found another buffer related
>> problem there, but they say nothing about these.
>>
>> If you have any explanation/solution for these problems pls share them!
>>
>>
>>
> What's wrong with the dmesg? The used/available inconsistencies are due to
> space being reserved.
>
> Regarding disk performance, you need to put hw.mpt.enable_sata_wc=1 in
> /boot/loader.conf to reenable the write cache (it's disabled by default for
> consistency reasons when using SATA disks leading to poor write
> performance).
>
> Regards,
>
> Richard
>

Thanks for your advice, this was unusual for me, because even on a 4iR I
couldnt see this space reservation.

What about sysinstalls write error when extracting the ports collection?

Regards,
B.
From richardtector at thekeelecentre.com  Thu Feb 12 10:35:42 2009
From: richardtector at thekeelecentre.com (Richard Tector)
Date: Thu Feb 12 10:35:49 2009
Subject: Problem with SATA/SAS 5iR
In-Reply-To: <c4b701070902121033u467e1212g2d43605774ea3249@mail.gmail.com>
References: <c4b701070902120909m1d6e8d0dka8032a612f9139d0@mail.gmail.com>	
	<4994644D.8070102@thekeelecentre.com>
	<c4b701070902121033u467e1212g2d43605774ea3249@mail.gmail.com>
Message-ID: <49946BF0.5010300@thekeelecentre.com>

Kevin Smith wrote:
> Thanks for your advice, this was unusual for me, because even on a 4iR I 
> couldnt see this space reservation.
> 
> What about sysinstalls write error when extracting the ports collection?

Bad install media perhaps? Have you encountered any other issues?

Richard
From ross.penner at gmail.com  Thu Feb 12 12:27:06 2009
From: ross.penner at gmail.com (Ross Penner)
Date: Thu Feb 12 12:27:13 2009
Subject: pkg_delete segfaulting after upgrading to 7.1
Message-ID: <f80199c40902121205g45d5702cta349750bcd087e07@mail.gmail.com>

I've recently upgraded my system to 7.1Stable. While upgrading my
ports, pkg_delete spontaneously ceased functioning. Some of the ports
were upgraded successfully so pkg_delete must have worked at some
point. I'm sort of a novice so I'm at a loss as to how to go about
diagnosing and fixing this problem.

here's an example below:

rosbox# pkg_delete -f gpgme-1.1.5_1
pkg_delete: package 'gpgme-1.1.5_1' is required by these other packages
and may not be deinstalled (but I'll delete it anyway):
seahorse-2.24.1_1
Segmentation fault (core dumped)
From danallen46 at airwired.net  Thu Feb 12 13:30:02 2009
From: danallen46 at airwired.net (Dan Allen)
Date: Thu Feb 12 13:30:13 2009
Subject: x48 display messed up with Xorg 7.4
In-Reply-To: <1234293967.13304.30.camel@horst-tla>
References: <CE2B54D9-C62C-4EF1-96CE-42392BCD7EF8@airwired.net>
	<1234293967.13304.30.camel@horst-tla>
Message-ID: <E1BFB77D-AE55-440B-8C19-489AD11F19F1@airwired.net>

On Wed, 11 Feb 2009 19:29:57 +0200, Esa Karkkainen wrote:
> I've got screenshots at:
> http://koti.welho.com/ekarkkai/x48_snap_1.jpg
> http://koti.welho.com/ekarkkai/x48_snap_2.jpg

Those look exactly like the problem I am having.
So, what piece of Xorg causes display problems?  Graphics drivers,  
right?
Dan

From lme at FreeBSD.org  Thu Feb 12 13:34:45 2009
From: lme at FreeBSD.org (Lars Engels)
Date: Thu Feb 12 13:34:54 2009
Subject: Backport of glxsb(4) to RELENG_6
In-Reply-To: <20090210134421.350f40b8@baby-jane.lamaiziere.net>
References: <20090210134421.350f40b8@baby-jane.lamaiziere.net>
Message-ID: <20090212213443.GM30761@e.0x20.net>

On Tue, Feb 10, 2009 at 01:44:21PM +0100, Patrick Lamaizi?re wrote:
> Hi,
> 
> I've backported the glxsb(4) driver to RELENG_6 (to use it on FreeNAS by
> instance).
> 
> http://user.lamaiziere.net/patrick/glxsb-6-100209.tar.gz
> 
> I am not able to test it, but I hope it will work.
> 
> You can test with openssl:
> 
> openssl enc -e -aes-128-cbc -in file -out file.enc -k abcdefgh -nosalt
> -engine cryptodev
> 
> Please tell me if it works or not.
> Regards.

I just tried it, but I get this message: 
glxsb0: <AMD Geode LX Security Block (AES-128-CBC, RNG)> mem 0xefff4000-0xefff7fff irq 9 at device 1.2 on pci0
glxsb0: cannot allocate DMA memory of 32768 bytes (12)
device_attach: glxsb0 attach returned 6

Lars
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20090212/88a51a90/attachment.pgp
From repcsike at gmail.com  Thu Feb 12 14:22:35 2009
From: repcsike at gmail.com (Kevin Smith)
Date: Thu Feb 12 14:22:43 2009
Subject: Problem with SATA/SAS 5iR
In-Reply-To: <49946BF0.5010300@thekeelecentre.com>
References: <c4b701070902120909m1d6e8d0dka8032a612f9139d0@mail.gmail.com>
	<4994644D.8070102@thekeelecentre.com>
	<c4b701070902121033u467e1212g2d43605774ea3249@mail.gmail.com>
	<49946BF0.5010300@thekeelecentre.com>
Message-ID: <c4b701070902121422k70805f7fg87f17b9174835498@mail.gmail.com>

2009/2/12 Richard Tector <richardtector@thekeelecentre.com>

> Kevin Smith wrote:
>
>> Thanks for your advice, this was unusual for me, because even on a 4iR I
>> couldnt see this space reservation.
>>
>> What about sysinstalls write error when extracting the ports collection?
>>
>
> Bad install media perhaps? Have you encountered any other issues?
>
> Richard
>


Reinstalled the box just for kicks, and now the media was an FTP site, it
looks like the culprit was the optical drive which is an Optiarc AD-5200A,
using a CD and a DVD both gave me the error, now it went down alright, using
the optical only for booting up.

Just another thing, can you change or monitor the behaviour of this spare
space reservation? Looking into man mpt gave nothing useful regarding this
issue.

Adding hw.mpt.enable_sata_wc to the loader conf made everything much faster,
before that the computer used the disks all the time.

Thank you for your help Richard,

Best Regards,
B.
From richardtector at thekeelecentre.com  Thu Feb 12 16:17:07 2009
From: richardtector at thekeelecentre.com (Richard Tector)
Date: Thu Feb 12 16:17:14 2009
Subject: Problem with SATA/SAS 5iR
In-Reply-To: <c4b701070902121422k70805f7fg87f17b9174835498@mail.gmail.com>
References: <c4b701070902120909m1d6e8d0dka8032a612f9139d0@mail.gmail.com>	<4994644D.8070102@thekeelecentre.com>	<c4b701070902121033u467e1212g2d43605774ea3249@mail.gmail.com>	<49946BF0.5010300@thekeelecentre.com>
	<c4b701070902121422k70805f7fg87f17b9174835498@mail.gmail.com>
Message-ID: <4994BBF4.30603@thekeelecentre.com>

Kevin Smith wrote:
> Just another thing, can you change or monitor the behaviour of this spare
> space reservation? Looking into man mpt gave nothing useful regarding this
> issue.

The tunefs manpage has a little about the space reservation. You can set 
it with -m IIRC when doing the newfs, but I believe it's generally best 
to leave it at the default. Note that root can still use the space, just 
not ordinary users (this leads to negative available space reported by df).

Regards,

Richard
From karl at denninger.net  Thu Feb 12 17:31:42 2009
From: karl at denninger.net (Karl Denninger)
Date: Thu Feb 12 17:31:49 2009
Subject: Upgrade from 32-bit to AMD-64?
Message-ID: <4994CD7B.7040302@denninger.net>

I have a machine that can run either (proved, I can boot the AMD-64 
release disk)

Can I SOURCE UPGRADE from one to the other?  That is, is it possible to 
do a "make buildworld", "make buildkernel" and then "make installkernel" 
and wind up with AMD64 instead of the 32-bit code?

Or must I reinstall?

It APPEARS I can run most 32-bit code on a 64-bit system.  Not all 
works, but most does.

-- 
--
Karl Denninger
karl@denninger.net


From delphij at delphij.net  Thu Feb 12 18:08:14 2009
From: delphij at delphij.net (Xin LI)
Date: Thu Feb 12 18:08:22 2009
Subject: Upgrade from 32-bit to AMD-64?
In-Reply-To: <4994CD7B.7040302@denninger.net>
References: <4994CD7B.7040302@denninger.net>
Message-ID: <4994D603.2060406@delphij.net>

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

Hi, Karl,

Karl Denninger wrote:
> I have a machine that can run either (proved, I can boot the AMD-64
> release disk)
> 
> Can I SOURCE UPGRADE from one to the other?  That is, is it possible to
> do a "make buildworld", "make buildkernel" and then "make installkernel"
> and wind up with AMD64 instead of the 32-bit code?
> 
> Or must I reinstall?
> 
> It APPEARS I can run most 32-bit code on a 64-bit system.  Not all
> works, but most does.

This is sort of "doable" but "highly recommend you not to do that"
thing.  The simplest way to do 32-bit to 64-bit upgrade would be to
backup your data, install from scratch, then restore data; mixing 32-bit
and 64-bit stuff together, especially without 32-bit stuff moved to the
right place, is among the most terrible mess you wanted to avoid.

Online "upgrade" can be done if you have your 64-bit world/kernel built
and installed into a separate directory (i.e. make world kernel
DESTDIR=/path/to/a/temp/place), then drop into single user mode, then
tar then pipe to another tar to extract the whole thing to /, but this
is really a "foot, gun, shoot" thing.

Cheers,
- --
Xin LI <delphij@delphij.net>	http://www.delphij.net/
FreeBSD - The Power to Serve!
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.10 (FreeBSD)

iEYEARECAAYFAkmU1gMACgkQi+vbBBjt66CLMQCfU77Cxz1YshGJb5C455GIGbXt
vvMAn25KgUnJqEmQRbrxnxucD+CTdFyf
=DiuA
-----END PGP SIGNATURE-----
From karl at denninger.net  Thu Feb 12 18:21:38 2009
From: karl at denninger.net (Karl Denninger)
Date: Thu Feb 12 18:21:47 2009
Subject: Upgrade from 32-bit to AMD-64?
In-Reply-To: <4994D603.2060406@delphij.net>
References: <4994CD7B.7040302@denninger.net> <4994D603.2060406@delphij.net>
Message-ID: <4994D931.4060508@denninger.net>


Xin LI wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hi, Karl,
>
> Karl Denninger wrote:
>   
>> I have a machine that can run either (proved, I can boot the AMD-64
>> release disk)
>>
>> Can I SOURCE UPGRADE from one to the other?  That is, is it possible to
>> do a "make buildworld", "make buildkernel" and then "make installkernel"
>> and wind up with AMD64 instead of the 32-bit code?
>>
>> Or must I reinstall?
>>
>> It APPEARS I can run most 32-bit code on a 64-bit system.  Not all
>> works, but most does.
>>     
>
> This is sort of "doable" but "highly recommend you not to do that"
> thing.  The simplest way to do 32-bit to 64-bit upgrade would be to
> backup your data, install from scratch, then restore data; mixing 32-bit
> and 64-bit stuff together, especially without 32-bit stuff moved to the
> right place, is among the most terrible mess you wanted to avoid.
>
> Online "upgrade" can be done if you have your 64-bit world/kernel built
> and installed into a separate directory (i.e. make world kernel
> DESTDIR=/path/to/a/temp/place), then drop into single user mode, then
> tar then pipe to another tar to extract the whole thing to /, but this
> is really a "foot, gun, shoot" thing.
>
> Cheers,
> - --
> Xin LI <delphij@delphij.net>	http://www.delphij.net/
>
>   
Hmmmm.... I was thinking something like this (I have the cvsup tree on 
the machine)

1. Compile into /usr/robj for amd64 (if I can figure out how to get make 
to do it - the obvious, MACHINE_ARCH=amd64, does not work - it barfs.)

2. Intentionally break the mirror (just in case) from the controller; 
I've now got a clean bootable drive if something goes wrong.

3. "make installkernel" (install new amd64 kernel)

4. Reboot

Now, the question - will the 32-bit executables RUN under the 64-bit 
kernel under single-user so I can "make installworld"?

Or do I get screwed instantly when I reboot?

-- 
--
Karl Denninger
karl@denninger.net


From delphij at delphij.net  Thu Feb 12 18:28:39 2009
From: delphij at delphij.net (Xin LI)
Date: Thu Feb 12 18:28:47 2009
Subject: Upgrade from 32-bit to AMD-64?
In-Reply-To: <4994D931.4060508@denninger.net>
References: <4994CD7B.7040302@denninger.net> <4994D603.2060406@delphij.net>
	<4994D931.4060508@denninger.net>
Message-ID: <4994DACC.1040801@delphij.net>

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

Karl Denninger wrote:
> 
> Xin LI wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> Hi, Karl,
>>
>> Karl Denninger wrote:
>>  
>>> I have a machine that can run either (proved, I can boot the AMD-64
>>> release disk)
>>>
>>> Can I SOURCE UPGRADE from one to the other?  That is, is it possible to
>>> do a "make buildworld", "make buildkernel" and then "make installkernel"
>>> and wind up with AMD64 instead of the 32-bit code?
>>>
>>> Or must I reinstall?
>>>
>>> It APPEARS I can run most 32-bit code on a 64-bit system.  Not all
>>> works, but most does.
>>>     
>>
>> This is sort of "doable" but "highly recommend you not to do that"
>> thing.  The simplest way to do 32-bit to 64-bit upgrade would be to
>> backup your data, install from scratch, then restore data; mixing 32-bit
>> and 64-bit stuff together, especially without 32-bit stuff moved to the
>> right place, is among the most terrible mess you wanted to avoid.
>>
>> Online "upgrade" can be done if you have your 64-bit world/kernel built
>> and installed into a separate directory (i.e. make world kernel
>> DESTDIR=/path/to/a/temp/place), then drop into single user mode, then
>> tar then pipe to another tar to extract the whole thing to /, but this
>> is really a "foot, gun, shoot" thing.
>>
>> Cheers,
>> - --
>> Xin LI <delphij@delphij.net>    http://www.delphij.net/
>>
>>   
> Hmmmm.... I was thinking something like this (I have the cvsup tree on
> the machine)
> 
> 1. Compile into /usr/robj for amd64 (if I can figure out how to get make
> to do it - the obvious, MACHINE_ARCH=amd64, does not work - it barfs.)
> 
> 2. Intentionally break the mirror (just in case) from the controller;
> I've now got a clean bootable drive if something goes wrong.
> 
> 3. "make installkernel" (install new amd64 kernel)
> 
> 4. Reboot
> 
> Now, the question - will the 32-bit executables RUN under the 64-bit
> kernel under single-user so I can "make installworld"?

Yes as long as you compiled COMPAT_FREEBSD32 you can run 32-bit
executables under a 64-bit kernel, but, you need to be careful since the
dynamic linker would have different name.

> Or do I get screwed instantly when I reboot?

There is a reason we don't recommend doing that :)

Cheers,
- --
Xin LI <delphij@delphij.net>	http://www.delphij.net/
FreeBSD - The Power to Serve!
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.10 (FreeBSD)

iEYEARECAAYFAkmU2swACgkQi+vbBBjt66CvjwCggpu439Rif7SzKnrOjpTFtCH1
CwUAnjRflrkmlrLlJvhCEJq5kUk8nPGd
=rwVa
-----END PGP SIGNATURE-----
From karl at denninger.net  Thu Feb 12 18:32:35 2009
From: karl at denninger.net (Karl Denninger)
Date: Thu Feb 12 18:32:43 2009
Subject: Upgrade from 32-bit to AMD-64?
In-Reply-To: <4994DACC.1040801@delphij.net>
References: <4994CD7B.7040302@denninger.net> <4994D603.2060406@delphij.net>
	<4994D931.4060508@denninger.net> <4994DACC.1040801@delphij.net>
Message-ID: <4994DBC1.2000309@denninger.net>


Xin LI wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Karl Denninger wrote:
>   
>> Xin LI wrote:
>>     
>>> -----BEGIN PGP SIGNED MESSAGE-----
>>> Hash: SHA1
>>>
>>> Hi, Karl,
>>>
>>> Karl Denninger wrote:
>>>  
>>>       
>>>> I have a machine that can run either (proved, I can boot the AMD-64
>>>> release disk)
>>>>
>>>> Can I SOURCE UPGRADE from one to the other?  That is, is it possible to
>>>> do a "make buildworld", "make buildkernel" and then "make installkernel"
>>>> and wind up with AMD64 instead of the 32-bit code?
>>>>
>>>> Or must I reinstall?
>>>>
>>>> It APPEARS I can run most 32-bit code on a 64-bit system.  Not all
>>>> works, but most does.
>>>>     
>>>>         
>>> This is sort of "doable" but "highly recommend you not to do that"
>>> thing.  The simplest way to do 32-bit to 64-bit upgrade would be to
>>> backup your data, install from scratch, then restore data; mixing 32-bit
>>> and 64-bit stuff together, especially without 32-bit stuff moved to the
>>> right place, is among the most terrible mess you wanted to avoid.
>>>
>>> Online "upgrade" can be done if you have your 64-bit world/kernel built
>>> and installed into a separate directory (i.e. make world kernel
>>> DESTDIR=/path/to/a/temp/place), then drop into single user mode, then
>>> tar then pipe to another tar to extract the whole thing to /, but this
>>> is really a "foot, gun, shoot" thing.
>>>
>>> Cheers,
>>> - --
>>> Xin LI <delphij@delphij.net>    http://www.delphij.net/
>>>
>>>   
>>>       
>> Hmmmm.... I was thinking something like this (I have the cvsup tree on
>> the machine)
>>
>> 1. Compile into /usr/robj for amd64 (if I can figure out how to get make
>> to do it - the obvious, MACHINE_ARCH=amd64, does not work - it barfs.)
>>
>> 2. Intentionally break the mirror (just in case) from the controller;
>> I've now got a clean bootable drive if something goes wrong.
>>
>> 3. "make installkernel" (install new amd64 kernel)
>>
>> 4. Reboot
>>
>> Now, the question - will the 32-bit executables RUN under the 64-bit
>> kernel under single-user so I can "make installworld"?
>>     
>
> Yes as long as you compiled COMPAT_FREEBSD32 you can run 32-bit
> executables under a 64-bit kernel, but, you need to be careful since the
> dynamic linker would have different name.
>   
>> Or do I get screwed instantly when I reboot?
>>     
>
> There is a reason we don't recommend doing that :)
>
> Cheers,
> - --
> Xin LI <delphij@delphij.net>	http://www.delphij.net/
>   
ROFL!  Ok, I get it.  I'm asking to get hosed as soon as I reboot.....

I CAN reload the machine but it would take the machine out of service 
for MUCH LESS TIME if I could do it this way; a full reload is going to 
take a couple of hours, where I can do it that way in ~5-10 minutes of 
downtime.

Of course if its going to blow up.....

I guess I need to schedule the 2-3 hours of downtime..... the reason for 
this, by the way, is that I have a dbms app on there that is getting too 
RAM hungry for its own good (its a Quadcore CPU) and I'm up against the 
RAM limit for 32-bit code.  The board will support more but 32-bit code 
won't; ergo, the only way to get beyond this is to go to 64-bit.

-- 
--
Karl Denninger
karl@denninger.net


From cswiger at mac.com  Thu Feb 12 18:43:33 2009
From: cswiger at mac.com (Chuck Swiger)
Date: Thu Feb 12 18:43:40 2009
Subject: Upgrade from 32-bit to AMD-64?
In-Reply-To: <4994CD7B.7040302@denninger.net>
References: <4994CD7B.7040302@denninger.net>
Message-ID: <A737B409-0578-4A8A-9DAB-20CD4122A8DE@mac.com>

On Feb 12, 2009, at 5:31 PM, Karl Denninger wrote:
> I have a machine that can run either (proved, I can boot the AMD-64  
> release disk)
>
> Can I SOURCE UPGRADE from one to the other?  That is, is it possible  
> to do a "make buildworld", "make buildkernel" and then "make  
> installkernel" and wind up with AMD64 instead of the 32-bit code?
>
> Or must I reinstall?

Sure, it's possible, given sufficient toolchain knowledge, time, and  
skills, but it's not a sensible thing to do aside from experimentation  
and learning purposes.

The recommended course is to determine the platform which best suits  
your requirements and the available hardware: ie, are you doing  
database stuff, SSL, or arbitrary-precision math which would really  
benefit from the 64-bit architecture; does the machine have more than  
3 GB of RAM; does the machine have hardware (like a graphics card)  
which has better 32-bit drivers, etc.

> It APPEARS I can run most 32-bit code on a 64-bit system.  Not all  
> works, but most does.

Right, the vast majority of 32-bit binaries should work just fine on a  
64-bit platform....

Regards,
-- 
-Chuck

From delphij at delphij.net  Thu Feb 12 18:49:31 2009
From: delphij at delphij.net (Xin LI)
Date: Thu Feb 12 18:49:37 2009
Subject: Upgrade from 32-bit to AMD-64?
In-Reply-To: <4994DBC1.2000309@denninger.net>
References: <4994CD7B.7040302@denninger.net>
	<4994D603.2060406@delphij.net>	<4994D931.4060508@denninger.net>
	<4994DACC.1040801@delphij.net> <4994DBC1.2000309@denninger.net>
Message-ID: <4994DFB0.3060704@delphij.net>

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

Karl Denninger wrote:
[...]
> I guess I need to schedule the 2-3 hours of downtime..... the reason for
> this, by the way, is that I have a dbms app on there that is getting too
> RAM hungry for its own good (its a Quadcore CPU) and I'm up against the
> RAM limit for 32-bit code.  The board will support more but 32-bit code
> won't; ergo, the only way to get beyond this is to go to 64-bit.

Oh wait!  One thing you wanted to know is that, some database *can* have
different on-disk format for 32-bit and 64-bit binaries.  Be sure to
have a dump handy.  Last time I hit this on a MySQL "upgrade" between
two servers, and I end up using its replication functionality.  The
operation took longer time than I expected at the beginning.

My personal suggestion is that you do an experiment on another box
(64-bit capable) to make sure that the data would work, this never hurts
and avoids surprises (you do want 64-bit compile of your database
application since you want to take full advantage of 64-bit OS); also,
just like all upgrades, full backup is advised.

Cheers,
- --
Xin LI <delphij@delphij.net>	http://www.delphij.net/
FreeBSD - The Power to Serve!
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.10 (FreeBSD)

iEYEARECAAYFAkmU37AACgkQi+vbBBjt66BzlwCfUuQuTY8rXnhE/T1K9BNIZ7bi
j9sAoJiPJApQrX5Gwd4kfFWoiGfQs44g
=0oRk
-----END PGP SIGNATURE-----
From karl at denninger.net  Thu Feb 12 19:01:40 2009
From: karl at denninger.net (Karl Denninger)
Date: Thu Feb 12 19:01:49 2009
Subject: Upgrade from 32-bit to AMD-64?
In-Reply-To: <4994DFB0.3060704@delphij.net>
References: <4994CD7B.7040302@denninger.net>
	<4994D603.2060406@delphij.net>	<4994D931.4060508@denninger.net>
	<4994DACC.1040801@delphij.net> <4994DBC1.2000309@denninger.net>
	<4994DFB0.3060704@delphij.net>
Message-ID: <4994E292.4000802@denninger.net>

Xin LI wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Karl Denninger wrote:
> [...]
>   
>> I guess I need to schedule the 2-3 hours of downtime..... the reason for
>> this, by the way, is that I have a dbms app on there that is getting too
>> RAM hungry for its own good (its a Quadcore CPU) and I'm up against the
>> RAM limit for 32-bit code.  The board will support more but 32-bit code
>> won't; ergo, the only way to get beyond this is to go to 64-bit.
>>     
>
> Oh wait!  One thing you wanted to know is that, some database *can* have
> different on-disk format for 32-bit and 64-bit binaries.  Be sure to
> have a dump handy.  Last time I hit this on a MySQL "upgrade" between
> two servers, and I end up using its replication functionality.  The
> operation took longer time than I expected at the beginning.
>
> My personal suggestion is that you do an experiment on another box
> (64-bit capable) to make sure that the data would work, this never hurts
> and avoids surprises (you do want 64-bit compile of your database
> application since you want to take full advantage of 64-bit OS); also,
> just like all upgrades, full backup is advised.
>
> Cheers,
> - --
> Xin LI <delphij@delphij.net>	http://www.delphij.net
I already know I have to dump the database and then reload it - I 
attempted to migrate the disk structure across (which would have saved 
even more time) and got instantaneously hosed, presumably due to 
internal data type length differences.

This little upgrade is going to take a while; sounds like the best 
approach is to load a new box, shut down the dbms to connections and 
dump/pipe it over, then physically swap the machines.

Thanks.

-- 
--
Karl Denninger
karl@denninger.net


From bms at FreeBSD.org  Thu Feb 12 20:35:20 2009
From: bms at FreeBSD.org (Bruce M. Simpson)
Date: Thu Feb 12 20:35:29 2009
Subject: Unhappy Xorg upgrade
In-Reply-To: <1234292252.1524.38.camel@ferret.2hip.net>
References: <329181233306971@webmail57.yandex.ru>	
	<985A59F2-20CC-4779-A000-018E52B5BFA9@jump-ing.de>	
	<101781233319948@webmail36.yandex.ru>
	<4983A3AE.90804@FreeBSD.org>	 <498F901A.7000900@FreeBSD.org>
	<1234159237.23838.3.camel@ferret.2hip.net>	
	<4990835A.3020303@FreeBSD.org>
	<1234208586.1524.17.camel@ferret.2hip.net>	
	<4990BC99.1070108@FreeBSD.org>
	<1234246034.1524.27.camel@ferret.2hip.net>	
	<4991C017.8080903@FreeBSD.org>
	<1234292252.1524.38.camel@ferret.2hip.net>
Message-ID: <4994F882.7000903@FreeBSD.org>

Robert Noland wrote:
> Ok, At least we know where the issue lies now.  I'll try and look the
> code over again, but I behaves almost identically to the kernel routines
> I think.  jhb@ wrote us a new ioctl to avoid doing most of this from
> userland, but it will be a while before we can count on it's existence
> and it doesn't support bios frobbing yet.
>
> Can you verify that pciconf -lvbc does not trigger the issue?
>   

Looks completely fine. I can't trigger the issue with pciconf alone.

BTW: the 'b' seems to be ignored unless used as part of 'pciconf -b 
<selector> <addr>'. I tried using pciconf to read the first 2 bytes of 
config space of the controller which is normally affected, as you can 
see in the log, and this caused no problems.
-------------- next part --------------
Script started on Fri Feb 13 04:27:55 2009
You have mail.
anglepoise# usbdevs -v

Controller /dev/usb0:
addr 1: full speed, self powered, config 1, OHCI root hub(0x0000), AcerLabs(0x0000), rev 1.00
 port 1 addr 2: full speed, self powered, config 1, product 0x2046(0x2046), vendor 0x0451(0x0451), rev 1.25
  port 1 powered
  port 2 powered
  port 3 powered
  port 4 powered
 port 2 powered
 port 3 powered
Controller /dev/usb1:
addr 1: full speed, self powered, config 1, OHCI root hub(0x0000), AcerLabs(0x0000), rev 1.00
 port 1 powered
 port 2 powered
 port 3 powered
Controller /dev/usb2:
addr 1: full speed, self powered, config 1, OHCI root hub(0x0000), AcerLabs(0x0000), rev 1.00
 port 1 powered
 port 2 powered
 port 3 powered
Controller /dev/usb3:
addr 1: high speed, self powered, config 1, EHCI root hub(0x0000), AcerLabs(0x0000), rev 1.00
 port 1 powered
 port 2 powered
 port 3 powered
 port 4 powered
 port 5 powered
 port 6 powered
 port 7 powered
 port 8 powered
anglepoise# pciconf -lvc

hostb0@pci0:0:0:0:	class=0x060000 card=0x81851043 chip=0x59501002 rev=0x10 hdr=0x00
    vendor     = 'ATI Technologies Inc'
    device     = 'RS480 Host Bridge'
    class      = bridge
    subclass   = HOST-PCI
pcib1@pci0:0:2:0:	class=0x060400 card=0x59501002 chip=0x5a341002 rev=0x00 hdr=0x01
    vendor     = 'ATI Technologies Inc'
    device     = 'RS480 PCI-X Root Port'
    class      = bridge
    subclass   = PCI-PCI
    cap 01[50] = powerspec 3  supports D0 D3  current D0
    cap 10[58] = PCI-Express 1 root port
    cap 05[80] = MSI supports 1 message 
    cap 0d[b0] = PCI Bridge card=0x59501002
    cap 08[b8] = HT MSI fixed address window enabled at 0xfee00000
pcib2@pci0:0:6:0:	class=0x060400 card=0x59501002 chip=0x5a381002 rev=0x00 hdr=0x01
    vendor     = 'ATI Technologies Inc'
    device     = 'RS480 PCI Bridge'
    class      = bridge
    subclass   = PCI-PCI
    cap 01[50] = powerspec 3  supports D0 D3  current D0
    cap 10[58] = PCI-Express 1 root port
    cap 05[80] = MSI supports 1 message 
    cap 0d[b0] = PCI Bridge card=0x59501002
    cap 08[b8] = HT MSI fixed address window enabled at 0xfee00000
pcib3@pci0:0:7:0:	class=0x060400 card=0x59501002 chip=0x5a391002 rev=0x00 hdr=0x01
    vendor     = 'ATI Technologies Inc'
    device     = 'RS480 PCI Bridge'
    class      = bridge
    subclass   = PCI-PCI
    cap 01[50] = powerspec 3  supports D0 D3  current D0
    cap 10[58] = PCI-Express 1 root port
    cap 05[80] = MSI supports 1 message 
    cap 0d[b0] = PCI Bridge card=0x59501002
    cap 08[b8] = HT MSI fixed address window enabled at 0xfee00000
hostb1@pci0:0:24:0:	class=0x060000 card=0x00000000 chip=0x11001022 rev=0x00 hdr=0x00
    vendor     = 'Advanced Micro Devices (AMD)'
    device     = '(K8) Athlon 64/Opteron HyperTransport Technology Configuration'
    class      = bridge
    subclass   = HOST-PCI
    cap 08[80] = HT host
hostb2@pci0:0:24:1:	class=0x060000 card=0x00000000 chip=0x11011022 rev=0x00 hdr=0x00
    vendor     = 'Advanced Micro Devices (AMD)'
    device     = '(K8) Athlon 64/Opteron Address Map'
    class      = bridge
    subclass   = HOST-PCI
hostb3@pci0:0:24:2:	class=0x060000 card=0x00000000 chip=0x11021022 rev=0x00 hdr=0x00
    vendor     = 'Advanced Micro Devices (AMD)'
    device     = '(K8) Athlon 64/Opteron DRAM Controller'
    class      = bridge
    subclass   = HOST-PCI
hostb4@pci0:0:24:3:	class=0x060000 card=0x00000000 chip=0x11031022 rev=0x00 hdr=0x00
    vendor     = 'Advanced Micro Devices (AMD)'
    device     = '(K8) Athlon 64/Opteron Miscellaneous Control'
    class      = bridge
    subclass   = HOST-PCI
pcib4@pci0:0:25:0:	class=0x060400 card=0x00000000 chip=0x524910b9 rev=0x00 hdr=0x01
    vendor     = 'Acer Labs Incorporated (ALi/ULi)'
    device     = 'M5249 HyperTransport to PCI Bridge'
    class      = bridge
    subclass   = PCI-PCI
    cap 08[c0] = HT MSI fixed address window enabled at 0xfee00000
ohci0@pci0:0:28:0:	class=0x0c0310 card=0x81561043 chip=0x523710b9 rev=0x03 hdr=0x00
    vendor     = 'Acer Labs Incorporated (ALi/ULi)'
    device     = 'M5273 A1 for windows win 98 OpenHCI 1.1 USB to  2.0'
    class      = serial bus
    subclass   = USB
ohci1@pci0:0:28:1:	class=0x0c0310 card=0x81561043 chip=0x523710b9 rev=0x03 hdr=0x00
    vendor     = 'Acer Labs Incorporated (ALi/ULi)'
    device     = 'M5273 A1 for windows win 98 OpenHCI 1.1 USB to  2.0'
    class      = serial bus
    subclass   = USB
ohci2@pci0:0:28:2:	class=0x0c0310 card=0x81561043 chip=0x523710b9 rev=0x03 hdr=0x00
    vendor     = 'Acer Labs Incorporated (ALi/ULi)'
    device     = 'M5273 A1 for windows win 98 OpenHCI 1.1 USB to  2.0'
    class      = serial bus
    subclass   = USB
ehci0@pci0:0:28:3:	class=0x0c0320 card=0x81561043 chip=0x523910b9 rev=0x01 hdr=0x00
    vendor     = 'Acer Labs Incorporated (ALi/ULi)'
    device     = 'USB 2.0 Enhanced Host Controller'
    class      = serial bus
    subclass   = USB
    cap 01[50] = powerspec 2  supports D0 D3  current D0
    cap 0a[58] = EHCI Debug Port at offset 0x90 in map 0x14
hdac0@pci0:0:29:0:	class=0x040300 card=0x81b41043 chip=0x546110b9 rev=0x00 hdr=0x00
    vendor     = 'Acer Labs Incorporated (ALi/ULi)'
    device     = '?? Microsoft UAA Bus Driver for High Definition Audio'
    class      = multimedia
    subclass   = HDA
    cap 01[50] = powerspec 2  supports D0 D3  current D0
isab0@pci0:0:30:0:	class=0x060100 card=0x81561043 chip=0x157310b9 rev=0x31 hdr=0x00
    vendor     = 'Acer Labs Incorporated (ALi/ULi)'
    device     = 'ALI M1573 South Bridge with Hypertransport Support'
    class      = bridge
    subclass   = PCI-ISA
none0@pci0:0:30:1:	class=0x068000 card=0x81561043 chip=0x710110b9 rev=0x00 hdr=0x00
    vendor     = 'Acer Labs Incorporated (ALi/ULi)'
    device     = 'ALI M7101 Power Management Controller'
    class      = bridge
atapci0@pci0:0:31:0:	class=0x01018a card=0x81561043 chip=0x522910b9 rev=0xc7 hdr=0x00
    vendor     = 'Acer Labs Incorporated (ALi/ULi)'
    device     = 'M5229 Southbridge EIDE Controller'
    class      = mass storage
    subclass   = ATA
    cap 01[60] = powerspec 2  supports D0 D3  current D0
atapci1@pci0:0:31:1:	class=0x010400 card=0x81561043 chip=0x528710b9 rev=0x02 hdr=0x00
    vendor     = 'Acer Labs Incorporated (ALi/ULi)'
    device     = '52871849 ALI SATA controller'
    class      = mass storage
    subclass   = RAID
    cap 01[60] = powerspec 2  supports D0 D3  current D0
vgapci0@pci0:1:0:0:	class=0x030000 card=0x3000174b chip=0x5b631002 rev=0x00 hdr=0x00
    vendor     = 'ATI Technologies Inc'
    device     = 'Radeon X550 Series'
    class      = display
    subclass   = VGA
    cap 01[50] = powerspec 2  supports D0 D1 D2 D3  current D0
    cap 10[58] = PCI-Express 1 endpoint
    cap 05[80] = MSI supports 1 message, 64 bit 
vgapci1@pci0:1:0:1:	class=0x038000 card=0x3001174b chip=0x5b731002 rev=0x00 hdr=0x00
    vendor     = 'ATI Technologies Inc'
    device     = 'Radeon X550 Series - Secondary'
    class      = display
    cap 01[50] = powerspec 2  supports D0 D1 D2 D3  current D0
    cap 10[58] = PCI-Express 1 endpoint
mskc0@pci0:2:0:0:	class=0x020000 card=0x81421043 chip=0x436211ab rev=0x19 hdr=0x00
    vendor     = 'Marvell Semiconductor (Was: Galileo Technology Ltd)'
    device     = '88E8053 Marvell Yukon 88E8053 PCI-E Gigabit Ethernet Controller'
    class      = network
    subclass   = ethernet
    cap 01[48] = powerspec 2  supports D0 D1 D2 D3  current D0
    cap 03[50] = VPD
    cap 05[5c] = MSI supports 2 messages, 64 bit enabled with 2 messages
    cap 10[e0] = PCI-Express 1 legacy endpoint
none1@pci0:4:18:0:	class=0x0c0010 card=0x808a1043 chip=0x30441106 rev=0x80 hdr=0x00
    vendor     = 'VIA Technologies Inc'
    device     = 'VT6306 VIA Fire II IEEE-1394 OHCI Link Layer Controller'
    class      = serial bus
    subclass   = FireWire
    cap 01[50] = powerspec 2  supports D0 D2 D3  current D0
anglepoise# 

anglepoise# usbdevsecho 'plug in  hub' on front panel'

plug in  hub on front panel
anglepoise# usbdevs -v

Controller /dev/usb0:
addr 1: full speed, self powered, config 1, OHCI root hub(0x0000), AcerLabs(0x0000), rev 1.00
 port 1 addr 2: full speed, self powered, config 1, product 0x2046(0x2046), vendor 0x0451(0x0451), rev 1.25
  port 1 powered
  port 2 powered
  port 3 powered
  port 4 powered
 port 2 powered
 port 3 powered
Controller /dev/usb1:
addr 1: full speed, self powered, config 1, OHCI root hub(0x0000), AcerLabs(0x0000), rev 1.00
 port 1 powered
 port 2 powered
 port 3 powered
Controller /dev/usb2:
addr 1: full speed, self powered, config 1, OHCI root hub(0x0000), AcerLabs(0x0000), rev 1.00
 port 1 powered
 port 2 powered
 port 3 powered
Controller /dev/usb3:
addr 1: high speed, self powered, config 1, EHCI root hub(0x0000), AcerLabs(0x0000), rev 1.00
 port 1 powered
 port 2 powered
 port 3 powered
 port 4 powered
 port 5 powered
 port 6 powered
 port 7 powered
 port 8 addr 2: high speed, self powered, config 1, USB2.0 Hub(0x0606), vendor 0x05e3(0x05e3), rev 7.02
  port 1 powered
  port 2 powered
  port 3 powered
  port 4 powered
anglepoise# pciconf -lvbc

hostb0@pci0:0:0:0:	class=0x060000 card=0x81851043 chip=0x59501002 rev=0x10 hdr=0x00
    vendor     = 'ATI Technologies Inc'
    device     = 'RS480 Host Bridge'
    class      = bridge
    subclass   = HOST-PCI
pcib1@pci0:0:2:0:	class=0x060400 card=0x59501002 chip=0x5a341002 rev=0x00 hdr=0x01
    vendor     = 'ATI Technologies Inc'
    device     = 'RS480 PCI-X Root Port'
    class      = bridge
    subclass   = PCI-PCI
    cap 01[50] = powerspec 3  supports D0 D3  current D0
    cap 10[58] = PCI-Express 1 root port
    cap 05[80] = MSI supports 1 message 
    cap 0d[b0] = PCI Bridge card=0x59501002
    cap 08[b8] = HT MSI fixed address window enabled at 0xfee00000
pcib2@pci0:0:6:0:	class=0x060400 card=0x59501002 chip=0x5a381002 rev=0x00 hdr=0x01
    vendor     = 'ATI Technologies Inc'
    device     = 'RS480 PCI Bridge'
    class      = bridge
    subclass   = PCI-PCI
    cap 01[50] = powerspec 3  supports D0 D3  current D0
    cap 10[58] = PCI-Express 1 root port
    cap 05[80] = MSI supports 1 message 
    cap 0d[b0] = PCI Bridge card=0x59501002
    cap 08[b8] = HT MSI fixed address window enabled at 0xfee00000
pcib3@pci0:0:7:0:	class=0x060400 card=0x59501002 chip=0x5a391002 rev=0x00 hdr=0x01
    vendor     = 'ATI Technologies Inc'
    device     = 'RS480 PCI Bridge'
    class      = bridge
    subclass   = PCI-PCI
    cap 01[50] = powerspec 3  supports D0 D3  current D0
    cap 10[58] = PCI-Express 1 root port
    cap 05[80] = MSI supports 1 message 
    cap 0d[b0] = PCI Bridge card=0x59501002
    cap 08[b8] = HT MSI fixed address window enabled at 0xfee00000
hostb1@pci0:0:24:0:	class=0x060000 card=0x00000000 chip=0x11001022 rev=0x00 hdr=0x00
    vendor     = 'Advanced Micro Devices (AMD)'
    device     = '(K8) Athlon 64/Opteron HyperTransport Technology Configuration'
    class      = bridge
    subclass   = HOST-PCI
    cap 08[80] = HT host
hostb2@pci0:0:24:1:	class=0x060000 card=0x00000000 chip=0x11011022 rev=0x00 hdr=0x00
    vendor     = 'Advanced Micro Devices (AMD)'
    device     = '(K8) Athlon 64/Opteron Address Map'
    class      = bridge
    subclass   = HOST-PCI
hostb3@pci0:0:24:2:	class=0x060000 card=0x00000000 chip=0x11021022 rev=0x00 hdr=0x00
    vendor     = 'Advanced Micro Devices (AMD)'
    device     = '(K8) Athlon 64/Opteron DRAM Controller'
    class      = bridge
    subclass   = HOST-PCI
hostb4@pci0:0:24:3:	class=0x060000 card=0x00000000 chip=0x11031022 rev=0x00 hdr=0x00
    vendor     = 'Advanced Micro Devices (AMD)'
    device     = '(K8) Athlon 64/Opteron Miscellaneous Control'
    class      = bridge
    subclass   = HOST-PCI
pcib4@pci0:0:25:0:	class=0x060400 card=0x00000000 chip=0x524910b9 rev=0x00 hdr=0x01
    vendor     = 'Acer Labs Incorporated (ALi/ULi)'
    device     = 'M5249 HyperTransport to PCI Bridge'
    class      = bridge
    subclass   = PCI-PCI
    cap 08[c0] = HT MSI fixed address window enabled at 0xfee00000
ohci0@pci0:0:28:0:	class=0x0c0310 card=0x81561043 chip=0x523710b9 rev=0x03 hdr=0x00
    vendor     = 'Acer Labs Incorporated (ALi/ULi)'
    device     = 'M5273 A1 for windows win 98 OpenHCI 1.1 USB to  2.0'
    class      = serial bus
    subclass   = USB
ohci1@pci0:0:28:1:	class=0x0c0310 card=0x81561043 chip=0x523710b9 rev=0x03 hdr=0x00
    vendor     = 'Acer Labs Incorporated (ALi/ULi)'
    device     = 'M5273 A1 for windows win 98 OpenHCI 1.1 USB to  2.0'
    class      = serial bus
    subclass   = USB
ohci2@pci0:0:28:2:	class=0x0c0310 card=0x81561043 chip=0x523710b9 rev=0x03 hdr=0x00
    vendor     = 'Acer Labs Incorporated (ALi/ULi)'
    device     = 'M5273 A1 for windows win 98 OpenHCI 1.1 USB to  2.0'
    class      = serial bus
    subclass   = USB
ehci0@pci0:0:28:3:	class=0x0c0320 card=0x81561043 chip=0x523910b9 rev=0x01 hdr=0x00
    vendor     = 'Acer Labs Incorporated (ALi/ULi)'
    device     = 'USB 2.0 Enhanced Host Controller'
    class      = serial bus
    subclass   = USB
    cap 01[50] = powerspec 2  supports D0 D3  current D0
    cap 0a[58] = EHCI Debug Port at offset 0x90 in map 0x14
hdac0@pci0:0:29:0:	class=0x040300 card=0x81b41043 chip=0x546110b9 rev=0x00 hdr=0x00
    vendor     = 'Acer Labs Incorporated (ALi/ULi)'
    device     = '?? Microsoft UAA Bus Driver for High Definition Audio'
    class      = multimedia
    subclass   = HDA
    cap 01[50] = powerspec 2  supports D0 D3  current D0
isab0@pci0:0:30:0:	class=0x060100 card=0x81561043 chip=0x157310b9 rev=0x31 hdr=0x00
    vendor     = 'Acer Labs Incorporated (ALi/ULi)'
    device     = 'ALI M1573 South Bridge with Hypertransport Support'
    class      = bridge
    subclass   = PCI-ISA
none0@pci0:0:30:1:	class=0x068000 card=0x81561043 chip=0x710110b9 rev=0x00 hdr=0x00
    vendor     = 'Acer Labs Incorporated (ALi/ULi)'
    device     = 'ALI M7101 Power Management Controller'
    class      = bridge
atapci0@pci0:0:31:0:	class=0x01018a card=0x81561043 chip=0x522910b9 rev=0xc7 hdr=0x00
    vendor     = 'Acer Labs Incorporated (ALi/ULi)'
    device     = 'M5229 Southbridge EIDE Controller'
    class      = mass storage
    subclass   = ATA
    cap 01[60] = powerspec 2  supports D0 D3  current D0
atapci1@pci0:0:31:1:	class=0x010400 card=0x81561043 chip=0x528710b9 rev=0x02 hdr=0x00
    vendor     = 'Acer Labs Incorporated (ALi/ULi)'
    device     = '52871849 ALI SATA controller'
    class      = mass storage
    subclass   = RAID
    cap 01[60] = powerspec 2  supports D0 D3  current D0
vgapci0@pci0:1:0:0:	class=0x030000 card=0x3000174b chip=0x5b631002 rev=0x00 hdr=0x00
    vendor     = 'ATI Technologies Inc'
    device     = 'Radeon X550 Series'
    class      = display
    subclass   = VGA
    cap 01[50] = powerspec 2  supports D0 D1 D2 D3  current D0
    cap 10[58] = PCI-Express 1 endpoint
    cap 05[80] = MSI supports 1 message, 64 bit 
vgapci1@pci0:1:0:1:	class=0x038000 card=0x3001174b chip=0x5b731002 rev=0x00 hdr=0x00
    vendor     = 'ATI Technologies Inc'
    device     = 'Radeon X550 Series - Secondary'
    class      = display
    cap 01[50] = powerspec 2  supports D0 D1 D2 D3  current D0
    cap 10[58] = PCI-Express 1 endpoint
mskc0@pci0:2:0:0:	class=0x020000 card=0x81421043 chip=0x436211ab rev=0x19 hdr=0x00
    vendor     = 'Marvell Semiconductor (Was: Galileo Technology Ltd)'
    device     = '88E8053 Marvell Yukon 88E8053 PCI-E Gigabit Ethernet Controller'
    class      = network
    subclass   = ethernet
    cap 01[48] = powerspec 2  supports D0 D1 D2 D3  current D0
    cap 03[50] = VPD
    cap 05[5c] = MSI supports 2 messages, 64 bit enabled with 2 messages
    cap 10[e0] = PCI-Express 1 legacy endpoint
none1@pci0:4:18:0:	class=0x0c0010 card=0x808a1043 chip=0x30441106 rev=0x80 hdr=0x00
    vendor     = 'VIA Technologies Inc'
    device     = 'VT6306 VIA Fire II IEEE-1394 OHCI Link Layer Controller'
    class      = serial bus
    subclass   = FireWire
    cap 01[50] = powerspec 2  supports D0 D2 D3  current D0
anglepoise# pciconf -lvbc[13`usbdevs -v

Controller /dev/usb0:
addr 1: full speed, self powered, config 1, OHCI root hub(0x0000), AcerLabs(0x0000), rev 1.00
 port 1 addr 2: full speed, self powered, config 1, product 0x2046(0x2046), vendor 0x0451(0x0451), rev 1.25
  port 1 powered
  port 2 powered
  port 3 powered
  port 4 powered
 port 2 powered
 port 3 powered
Controller /dev/usb1:
addr 1: full speed, self powered, config 1, OHCI root hub(0x0000), AcerLabs(0x0000), rev 1.00
 port 1 powered
 port 2 powered
 port 3 powered
Controller /dev/usb2:
addr 1: full speed, self powered, config 1, OHCI root hub(0x0000), AcerLabs(0x0000), rev 1.00
 port 1 powered
 port 2 powered
 port 3 powered
Controller /dev/usb3:
addr 1: high speed, self powered, config 1, EHCI root hub(0x0000), AcerLabs(0x0000), rev 1.00
 port 1 powered
 port 2 powered
 port 3 powered
 port 4 powered
 port 5 powered
 port 6 powered
 port 7 powered
 port 8 addr 2: high speed, self powered, config 1, USB2.0 Hub(0x0606), vendor 0x05e3(0x05e3), rev 7.02
  port 1 powered
  port 2 powered
  port 3 powered
  port 4 powered
anglepoise# ech o 'detach hub'

detach hub
anglepoise# usbdevs -v

Controller /dev/usb0:
addr 1: full speed, self powered, config 1, OHCI root hub(0x0000), AcerLabs(0x0000), rev 1.00
 port 1 addr 2: full speed, self powered, config 1, product 0x2046(0x2046), vendor 0x0451(0x0451), rev 1.25
  port 1 powered
  port 2 powered
  port 3 powered
  port 4 powered
 port 2 powered
 port 3 powered
Controller /dev/usb1:
addr 1: full speed, self powered, config 1, OHCI root hub(0x0000), AcerLabs(0x0000), rev 1.00
 port 1 powered
 port 2 powered
 port 3 powered
Controller /dev/usb2:
addr 1: full speed, self powered, config 1, OHCI root hub(0x0000), AcerLabs(0x0000), rev 1.00
 port 1 powered
 port 2 powered
 port 3 powered
Controller /dev/usb3:
addr 1: high speed, self powered, config 1, EHCI root hub(0x0000), AcerLabs(0x0000), rev 1.00
 port 1 powered
 port 2 powered
 port 3 powered
 port 4 powered
 port 5 powered
 port 6 powered
 port 7 powered
 port 8 powered
anglepoise# usbdevs -v[13`echo 'detach hub'[13`usbdevs -v[13`pciconf -lvbc

hostb0@pci0:0:0:0:	class=0x060000 card=0x81851043 chip=0x59501002 rev=0x10 hdr=0x00
    vendor     = 'ATI Technologies Inc'
    device     = 'RS480 Host Bridge'
    class      = bridge
    subclass   = HOST-PCI
pcib1@pci0:0:2:0:	class=0x060400 card=0x59501002 chip=0x5a341002 rev=0x00 hdr=0x01
    vendor     = 'ATI Technologies Inc'
    device     = 'RS480 PCI-X Root Port'
    class      = bridge
    subclass   = PCI-PCI
    cap 01[50] = powerspec 3  supports D0 D3  current D0
    cap 10[58] = PCI-Express 1 root port
    cap 05[80] = MSI supports 1 message 
    cap 0d[b0] = PCI Bridge card=0x59501002
    cap 08[b8] = HT MSI fixed address window enabled at 0xfee00000
pcib2@pci0:0:6:0:	class=0x060400 card=0x59501002 chip=0x5a381002 rev=0x00 hdr=0x01
    vendor     = 'ATI Technologies Inc'
    device     = 'RS480 PCI Bridge'
    class      = bridge
    subclass   = PCI-PCI
    cap 01[50] = powerspec 3  supports D0 D3  current D0
    cap 10[58] = PCI-Express 1 root port
    cap 05[80] = MSI supports 1 message 
    cap 0d[b0] = PCI Bridge card=0x59501002
    cap 08[b8] = HT MSI fixed address window enabled at 0xfee00000
pcib3@pci0:0:7:0:	class=0x060400 card=0x59501002 chip=0x5a391002 rev=0x00 hdr=0x01
    vendor     = 'ATI Technologies Inc'
    device     = 'RS480 PCI Bridge'
    class      = bridge
    subclass   = PCI-PCI
    cap 01[50] = powerspec 3  supports D0 D3  current D0
    cap 10[58] = PCI-Express 1 root port
    cap 05[80] = MSI supports 1 message 
    cap 0d[b0] = PCI Bridge card=0x59501002
    cap 08[b8] = HT MSI fixed address window enabled at 0xfee00000
hostb1@pci0:0:24:0:	class=0x060000 card=0x00000000 chip=0x11001022 rev=0x00 hdr=0x00
    vendor     = 'Advanced Micro Devices (AMD)'
    device     = '(K8) Athlon 64/Opteron HyperTransport Technology Configuration'
    class      = bridge
    subclass   = HOST-PCI
    cap 08[80] = HT host
hostb2@pci0:0:24:1:	class=0x060000 card=0x00000000 chip=0x11011022 rev=0x00 hdr=0x00
    vendor     = 'Advanced Micro Devices (AMD)'
    device     = '(K8) Athlon 64/Opteron Address Map'
    class      = bridge
    subclass   = HOST-PCI
hostb3@pci0:0:24:2:	class=0x060000 card=0x00000000 chip=0x11021022 rev=0x00 hdr=0x00
    vendor     = 'Advanced Micro Devices (AMD)'
    device     = '(K8) Athlon 64/Opteron DRAM Controller'
    class      = bridge
    subclass   = HOST-PCI
hostb4@pci0:0:24:3:	class=0x060000 card=0x00000000 chip=0x11031022 rev=0x00 hdr=0x00
    vendor     = 'Advanced Micro Devices (AMD)'
    device     = '(K8) Athlon 64/Opteron Miscellaneous Control'
    class      = bridge
    subclass   = HOST-PCI
pcib4@pci0:0:25:0:	class=0x060400 card=0x00000000 chip=0x524910b9 rev=0x00 hdr=0x01
    vendor     = 'Acer Labs Incorporated (ALi/ULi)'
    device     = 'M5249 HyperTransport to PCI Bridge'
    class      = bridge
    subclass   = PCI-PCI
    cap 08[c0] = HT MSI fixed address window enabled at 0xfee00000
ohci0@pci0:0:28:0:	class=0x0c0310 card=0x81561043 chip=0x523710b9 rev=0x03 hdr=0x00
    vendor     = 'Acer Labs Incorporated (ALi/ULi)'
    device     = 'M5273 A1 for windows win 98 OpenHCI 1.1 USB to  2.0'
    class      = serial bus
    subclass   = USB
ohci1@pci0:0:28:1:	class=0x0c0310 card=0x81561043 chip=0x523710b9 rev=0x03 hdr=0x00
    vendor     = 'Acer Labs Incorporated (ALi/ULi)'
    device     = 'M5273 A1 for windows win 98 OpenHCI 1.1 USB to  2.0'
    class      = serial bus
    subclass   = USB
ohci2@pci0:0:28:2:	class=0x0c0310 card=0x81561043 chip=0x523710b9 rev=0x03 hdr=0x00
    vendor     = 'Acer Labs Incorporated (ALi/ULi)'
    device     = 'M5273 A1 for windows win 98 OpenHCI 1.1 USB to  2.0'
    class      = serial bus
    subclass   = USB
ehci0@pci0:0:28:3:	class=0x0c0320 card=0x81561043 chip=0x523910b9 rev=0x01 hdr=0x00
    vendor     = 'Acer Labs Incorporated (ALi/ULi)'
    device     = 'USB 2.0 Enhanced Host Controller'
    class      = serial bus
    subclass   = USB
    cap 01[50] = powerspec 2  supports D0 D3  current D0
    cap 0a[58] = EHCI Debug Port at offset 0x90 in map 0x14
hdac0@pci0:0:29:0:	class=0x040300 card=0x81b41043 chip=0x546110b9 rev=0x00 hdr=0x00
    vendor     = 'Acer Labs Incorporated (ALi/ULi)'
    device     = '?? Microsoft UAA Bus Driver for High Definition Audio'
    class      = multimedia
    subclass   = HDA
    cap 01[50] = powerspec 2  supports D0 D3  current D0
isab0@pci0:0:30:0:	class=0x060100 card=0x81561043 chip=0x157310b9 rev=0x31 hdr=0x00
    vendor     = 'Acer Labs Incorporated (ALi/ULi)'
    device     = 'ALI M1573 South Bridge with Hypertransport Support'
    class      = bridge
    subclass   = PCI-ISA
none0@pci0:0:30:1:	class=0x068000 card=0x81561043 chip=0x710110b9 rev=0x00 hdr=0x00
    vendor     = 'Acer Labs Incorporated (ALi/ULi)'
    device     = 'ALI M7101 Power Management Controller'
    class      = bridge
atapci0@pci0:0:31:0:	class=0x01018a card=0x81561043 chip=0x522910b9 rev=0xc7 hdr=0x00
    vendor     = 'Acer Labs Incorporated (ALi/ULi)'
    device     = 'M5229 Southbridge EIDE Controller'
    class      = mass storage
    subclass   = ATA
    cap 01[60] = powerspec 2  supports D0 D3  current D0
atapci1@pci0:0:31:1:	class=0x010400 card=0x81561043 chip=0x528710b9 rev=0x02 hdr=0x00
    vendor     = 'Acer Labs Incorporated (ALi/ULi)'
    device     = '52871849 ALI SATA controller'
    class      = mass storage
    subclass   = RAID
    cap 01[60] = powerspec 2  supports D0 D3  current D0
vgapci0@pci0:1:0:0:	class=0x030000 card=0x3000174b chip=0x5b631002 rev=0x00 hdr=0x00
    vendor     = 'ATI Technologies Inc'
    device     = 'Radeon X550 Series'
    class      = display
    subclass   = VGA
    cap 01[50] = powerspec 2  supports D0 D1 D2 D3  current D0
    cap 10[58] = PCI-Express 1 endpoint
    cap 05[80] = MSI supports 1 message, 64 bit 
vgapci1@pci0:1:0:1:	class=0x038000 card=0x3001174b chip=0x5b731002 rev=0x00 hdr=0x00
    vendor     = 'ATI Technologies Inc'
    device     = 'Radeon X550 Series - Secondary'
    class      = display
    cap 01[50] = powerspec 2  supports D0 D1 D2 D3  current D0
    cap 10[58] = PCI-Express 1 endpoint
mskc0@pci0:2:0:0:	class=0x020000 card=0x81421043 chip=0x436211ab rev=0x19 hdr=0x00
    vendor     = 'Marvell Semiconductor (Was: Galileo Technology Ltd)'
    device     = '88E8053 Marvell Yukon 88E8053 PCI-E Gigabit Ethernet Controller'
    class      = network
    subclass   = ethernet
    cap 01[48] = powerspec 2  supports D0 D1 D2 D3  current D0
    cap 03[50] = VPD
    cap 05[5c] = MSI supports 2 messages, 64 bit enabled with 2 messages
    cap 10[e0] = PCI-Express 1 legacy endpoint
none1@pci0:4:18:0:	class=0x0c0010 card=0x808a1043 chip=0x30441106 rev=0x80 hdr=0x00
    vendor     = 'VIA Technologies Inc'
    device     = 'VT6306 VIA Fire II IEEE-1394 OHCI Link Layer Controller'
    class      = serial bus
    subclass   = FireWire
    cap 01[50] = powerspec 2  supports D0 D2 D3  current D0
anglepoise# pciconf -lvbc[13`usbdevs -v[13`echo 'detach hub'[13`usbdevs -v[13`pciconf -lvbc[13`usbdevs -v[13`echo 'plug in  hub on front panel'

plug in  hub on front panel
anglepoise# 

anglepoise# echo 'plug in  hub on front panel'[13`pciconf -lvbc[13`usbdevs -v[13`echo 'detach hub'[13`usbdevs -v[13`pciconf -lvbc

hostb0@pci0:0:0:0:	class=0x060000 card=0x81851043 chip=0x59501002 rev=0x10 hdr=0x00
    vendor     = 'ATI Technologies Inc'
    device     = 'RS480 Host Bridge'
    class      = bridge
    subclass   = HOST-PCI
pcib1@pci0:0:2:0:	class=0x060400 card=0x59501002 chip=0x5a341002 rev=0x00 hdr=0x01
    vendor     = 'ATI Technologies Inc'
    device     = 'RS480 PCI-X Root Port'
    class      = bridge
    subclass   = PCI-PCI
    cap 01[50] = powerspec 3  supports D0 D3  current D0
    cap 10[58] = PCI-Express 1 root port
    cap 05[80] = MSI supports 1 message 
    cap 0d[b0] = PCI Bridge card=0x59501002
    cap 08[b8] = HT MSI fixed address window enabled at 0xfee00000
pcib2@pci0:0:6:0:	class=0x060400 card=0x59501002 chip=0x5a381002 rev=0x00 hdr=0x01
    vendor     = 'ATI Technologies Inc'
    device     = 'RS480 PCI Bridge'
    class      = bridge
    subclass   = PCI-PCI
    cap 01[50] = powerspec 3  supports D0 D3  current D0
    cap 10[58] = PCI-Express 1 root port
    cap 05[80] = MSI supports 1 message 
    cap 0d[b0] = PCI Bridge card=0x59501002
    cap 08[b8] = HT MSI fixed address window enabled at 0xfee00000
pcib3@pci0:0:7:0:	class=0x060400 card=0x59501002 chip=0x5a391002 rev=0x00 hdr=0x01
    vendor     = 'ATI Technologies Inc'
    device     = 'RS480 PCI Bridge'
    class      = bridge
    subclass   = PCI-PCI
    cap 01[50] = powerspec 3  supports D0 D3  current D0
    cap 10[58] = PCI-Express 1 root port
    cap 05[80] = MSI supports 1 message 
    cap 0d[b0] = PCI Bridge card=0x59501002
    cap 08[b8] = HT MSI fixed address window enabled at 0xfee00000
hostb1@pci0:0:24:0:	class=0x060000 card=0x00000000 chip=0x11001022 rev=0x00 hdr=0x00
    vendor     = 'Advanced Micro Devices (AMD)'
    device     = '(K8) Athlon 64/Opteron HyperTransport Technology Configuration'
    class      = bridge
    subclass   = HOST-PCI
    cap 08[80] = HT host
hostb2@pci0:0:24:1:	class=0x060000 card=0x00000000 chip=0x11011022 rev=0x00 hdr=0x00
    vendor     = 'Advanced Micro Devices (AMD)'
    device     = '(K8) Athlon 64/Opteron Address Map'
    class      = bridge
    subclass   = HOST-PCI
hostb3@pci0:0:24:2:	class=0x060000 card=0x00000000 chip=0x11021022 rev=0x00 hdr=0x00
    vendor     = 'Advanced Micro Devices (AMD)'
    device     = '(K8) Athlon 64/Opteron DRAM Controller'
    class      = bridge
    subclass   = HOST-PCI
hostb4@pci0:0:24:3:	class=0x060000 card=0x00000000 chip=0x11031022 rev=0x00 hdr=0x00
    vendor     = 'Advanced Micro Devices (AMD)'
    device     = '(K8) Athlon 64/Opteron Miscellaneous Control'
    class      = bridge
    subclass   = HOST-PCI
pcib4@pci0:0:25:0:	class=0x060400 card=0x00000000 chip=0x524910b9 rev=0x00 hdr=0x01
    vendor     = 'Acer Labs Incorporated (ALi/ULi)'
    device     = 'M5249 HyperTransport to PCI Bridge'
    class      = bridge
    subclass   = PCI-PCI
    cap 08[c0] = HT MSI fixed address window enabled at 0xfee00000
ohci0@pci0:0:28:0:	class=0x0c0310 card=0x81561043 chip=0x523710b9 rev=0x03 hdr=0x00
    vendor     = 'Acer Labs Incorporated (ALi/ULi)'
    device     = 'M5273 A1 for windows win 98 OpenHCI 1.1 USB to  2.0'
    class      = serial bus
    subclass   = USB
ohci1@pci0:0:28:1:	class=0x0c0310 card=0x81561043 chip=0x523710b9 rev=0x03 hdr=0x00
    vendor     = 'Acer Labs Incorporated (ALi/ULi)'
    device     = 'M5273 A1 for windows win 98 OpenHCI 1.1 USB to  2.0'
    class      = serial bus
    subclass   = USB
ohci2@pci0:0:28:2:	class=0x0c0310 card=0x81561043 chip=0x523710b9 rev=0x03 hdr=0x00
    vendor     = 'Acer Labs Incorporated (ALi/ULi)'
    device     = 'M5273 A1 for windows win 98 OpenHCI 1.1 USB to  2.0'
    class      = serial bus
    subclass   = USB
ehci0@pci0:0:28:3:	class=0x0c0320 card=0x81561043 chip=0x523910b9 rev=0x01 hdr=0x00
    vendor     = 'Acer Labs Incorporated (ALi/ULi)'
    device     = 'USB 2.0 Enhanced Host Controller'
    class      = serial bus
    subclass   = USB
    cap 01[50] = powerspec 2  supports D0 D3  current D0
    cap 0a[58] = EHCI Debug Port at offset 0x90 in map 0x14
hdac0@pci0:0:29:0:	class=0x040300 card=0x81b41043 chip=0x546110b9 rev=0x00 hdr=0x00
    vendor     = 'Acer Labs Incorporated (ALi/ULi)'
    device     = '?? Microsoft UAA Bus Driver for High Definition Audio'
    class      = multimedia
    subclass   = HDA
    cap 01[50] = powerspec 2  supports D0 D3  current D0
isab0@pci0:0:30:0:	class=0x060100 card=0x81561043 chip=0x157310b9 rev=0x31 hdr=0x00
    vendor     = 'Acer Labs Incorporated (ALi/ULi)'
    device     = 'ALI M1573 South Bridge with Hypertransport Support'
    class      = bridge
    subclass   = PCI-ISA
none0@pci0:0:30:1:	class=0x068000 card=0x81561043 chip=0x710110b9 rev=0x00 hdr=0x00
    vendor     = 'Acer Labs Incorporated (ALi/ULi)'
    device     = 'ALI M7101 Power Management Controller'
    class      = bridge
atapci0@pci0:0:31:0:	class=0x01018a card=0x81561043 chip=0x522910b9 rev=0xc7 hdr=0x00
    vendor     = 'Acer Labs Incorporated (ALi/ULi)'
    device     = 'M5229 Southbridge EIDE Controller'
    class      = mass storage
    subclass   = ATA
    cap 01[60] = powerspec 2  supports D0 D3  current D0
atapci1@pci0:0:31:1:	class=0x010400 card=0x81561043 chip=0x528710b9 rev=0x02 hdr=0x00
    vendor     = 'Acer Labs Incorporated (ALi/ULi)'
    device     = '52871849 ALI SATA controller'
    class      = mass storage
    subclass   = RAID
    cap 01[60] = powerspec 2  supports D0 D3  current D0
vgapci0@pci0:1:0:0:	class=0x030000 card=0x3000174b chip=0x5b631002 rev=0x00 hdr=0x00
    vendor     = 'ATI Technologies Inc'
    device     = 'Radeon X550 Series'
    class      = display
    subclass   = VGA
    cap 01[50] = powerspec 2  supports D0 D1 D2 D3  current D0
    cap 10[58] = PCI-Express 1 endpoint
    cap 05[80] = MSI supports 1 message, 64 bit 
vgapci1@pci0:1:0:1:	class=0x038000 card=0x3001174b chip=0x5b731002 rev=0x00 hdr=0x00
    vendor     = 'ATI Technologies Inc'
    device     = 'Radeon X550 Series - Secondary'
    class      = display
    cap 01[50] = powerspec 2  supports D0 D1 D2 D3  current D0
    cap 10[58] = PCI-Express 1 endpoint
mskc0@pci0:2:0:0:	class=0x020000 card=0x81421043 chip=0x436211ab rev=0x19 hdr=0x00
    vendor     = 'Marvell Semiconductor (Was: Galileo Technology Ltd)'
    device     = '88E8053 Marvell Yukon 88E8053 PCI-E Gigabit Ethernet Controller'
    class      = network
    subclass   = ethernet
    cap 01[48] = powerspec 2  supports D0 D1 D2 D3  current D0
    cap 03[50] = VPD
    cap 05[5c] = MSI supports 2 messages, 64 bit enabled with 2 messages
    cap 10[e0] = PCI-Express 1 legacy endpoint
none1@pci0:4:18:0:	class=0x0c0010 card=0x808a1043 chip=0x30441106 rev=0x80 hdr=0x00
    vendor     = 'VIA Technologies Inc'
    device     = 'VT6306 VIA Fire II IEEE-1394 OHCI Link Layer Controller'
    class      = serial bus
    subclass   = FireWire
    cap 01[50] = powerspec 2  supports D0 D2 D3  current D0
anglepoise# pciconf -lvbc[13`echo 'plug in  hub on front panel'[13`pciconf -lvbc[13`usbdevs -v

Controller /dev/usb0:
addr 1: full speed, self powered, config 1, OHCI root hub(0x0000), AcerLabs(0x0000), rev 1.00
 port 1 addr 2: full speed, self powered, config 1, product 0x2046(0x2046), vendor 0x0451(0x0451), rev 1.25
  port 1 powered
  port 2 powered
  port 3 powered
  port 4 powered
 port 2 powered
 port 3 powered
Controller /dev/usb1:
addr 1: full speed, self powered, config 1, OHCI root hub(0x0000), AcerLabs(0x0000), rev 1.00
 port 1 powered
 port 2 powered
 port 3 powered
Controller /dev/usb2:
addr 1: full speed, self powered, config 1, OHCI root hub(0x0000), AcerLabs(0x0000), rev 1.00
 port 1 powered
 port 2 powered
 port 3 powered
Controller /dev/usb3:
addr 1: high speed, self powered, config 1, EHCI root hub(0x0000), AcerLabs(0x0000), rev 1.00
 port 1 powered
 port 2 powered
 port 3 powered
 port 4 powered
 port 5 addr 2: high speed, self powered, config 1, USB2.0 Hub(0x0606), vendor 0x05e3(0x05e3), rev 7.02
  port 1 powered
  port 2 powered
  port 3 powered
  port 4 powered
 port 6 powered
 port 7 powered
 port 8 powered
anglepoise# 

anglepoise# usbdevs -v[13`pciconf -lvbc

hostb0@pci0:0:0:0:	class=0x060000 card=0x81851043 chip=0x59501002 rev=0x10 hdr=0x00
    vendor     = 'ATI Technologies Inc'
    device     = 'RS480 Host Bridge'
    class      = bridge
    subclass   = HOST-PCI
pcib1@pci0:0:2:0:	class=0x060400 card=0x59501002 chip=0x5a341002 rev=0x00 hdr=0x01
    vendor     = 'ATI Technologies Inc'
    device     = 'RS480 PCI-X Root Port'
    class      = bridge
    subclass   = PCI-PCI
    cap 01[50] = powerspec 3  supports D0 D3  current D0
    cap 10[58] = PCI-Express 1 root port
    cap 05[80] = MSI supports 1 message 
    cap 0d[b0] = PCI Bridge card=0x59501002
    cap 08[b8] = HT MSI fixed address window enabled at 0xfee00000
pcib2@pci0:0:6:0:	class=0x060400 card=0x59501002 chip=0x5a381002 rev=0x00 hdr=0x01
    vendor     = 'ATI Technologies Inc'
    device     = 'RS480 PCI Bridge'
    class      = bridge
    subclass   = PCI-PCI
    cap 01[50] = powerspec 3  supports D0 D3  current D0
    cap 10[58] = PCI-Express 1 root port
    cap 05[80] = MSI supports 1 message 
    cap 0d[b0] = PCI Bridge card=0x59501002
    cap 08[b8] = HT MSI fixed address window enabled at 0xfee00000
pcib3@pci0:0:7:0:	class=0x060400 card=0x59501002 chip=0x5a391002 rev=0x00 hdr=0x01
    vendor     = 'ATI Technologies Inc'
    device     = 'RS480 PCI Bridge'
    class      = bridge
    subclass   = PCI-PCI
    cap 01[50] = powerspec 3  supports D0 D3  current D0
    cap 10[58] = PCI-Express 1 root port
    cap 05[80] = MSI supports 1 message 
    cap 0d[b0] = PCI Bridge card=0x59501002
    cap 08[b8] = HT MSI fixed address window enabled at 0xfee00000
hostb1@pci0:0:24:0:	class=0x060000 card=0x00000000 chip=0x11001022 rev=0x00 hdr=0x00
    vendor     = 'Advanced Micro Devices (AMD)'
    device     = '(K8) Athlon 64/Opteron HyperTransport Technology Configuration'
    class      = bridge
    subclass   = HOST-PCI
    cap 08[80] = HT host
hostb2@pci0:0:24:1:	class=0x060000 card=0x00000000 chip=0x11011022 rev=0x00 hdr=0x00
    vendor     = 'Advanced Micro Devices (AMD)'
    device     = '(K8) Athlon 64/Opteron Address Map'
    class      = bridge
    subclass   = HOST-PCI
hostb3@pci0:0:24:2:	class=0x060000 card=0x00000000 chip=0x11021022 rev=0x00 hdr=0x00
    vendor     = 'Advanced Micro Devices (AMD)'
    device     = '(K8) Athlon 64/Opteron DRAM Controller'
    class      = bridge
    subclass   = HOST-PCI
hostb4@pci0:0:24:3:	class=0x060000 card=0x00000000 chip=0x11031022 rev=0x00 hdr=0x00
    vendor     = 'Advanced Micro Devices (AMD)'
    device     = '(K8) Athlon 64/Opteron Miscellaneous Control'
    class      = bridge
    subclass   = HOST-PCI
pcib4@pci0:0:25:0:	class=0x060400 card=0x00000000 chip=0x524910b9 rev=0x00 hdr=0x01
    vendor     = 'Acer Labs Incorporated (ALi/ULi)'
    device     = 'M5249 HyperTransport to PCI Bridge'
    class      = bridge
    subclass   = PCI-PCI
    cap 08[c0] = HT MSI fixed address window enabled at 0xfee00000
ohci0@pci0:0:28:0:	class=0x0c0310 card=0x81561043 chip=0x523710b9 rev=0x03 hdr=0x00
    vendor     = 'Acer Labs Incorporated (ALi/ULi)'
    device     = 'M5273 A1 for windows win 98 OpenHCI 1.1 USB to  2.0'
    class      = serial bus
    subclass   = USB
ohci1@pci0:0:28:1:	class=0x0c0310 card=0x81561043 chip=0x523710b9 rev=0x03 hdr=0x00
    vendor     = 'Acer Labs Incorporated (ALi/ULi)'
    device     = 'M5273 A1 for windows win 98 OpenHCI 1.1 USB to  2.0'
    class      = serial bus
    subclass   = USB
ohci2@pci0:0:28:2:	class=0x0c0310 card=0x81561043 chip=0x523710b9 rev=0x03 hdr=0x00
    vendor     = 'Acer Labs Incorporated (ALi/ULi)'
    device     = 'M5273 A1 for windows win 98 OpenHCI 1.1 USB to  2.0'
    class      = serial bus
    subclass   = USB
ehci0@pci0:0:28:3:	class=0x0c0320 card=0x81561043 chip=0x523910b9 rev=0x01 hdr=0x00
    vendor     = 'Acer Labs Incorporated (ALi/ULi)'
    device     = 'USB 2.0 Enhanced Host Controller'
    class      = serial bus
    subclass   = USB
    cap 01[50] = powerspec 2  supports D0 D3  current D0
    cap 0a[58] = EHCI Debug Port at offset 0x90 in map 0x14
hdac0@pci0:0:29:0:	class=0x040300 card=0x81b41043 chip=0x546110b9 rev=0x00 hdr=0x00
    vendor     = 'Acer Labs Incorporated (ALi/ULi)'
    device     = '?? Microsoft UAA Bus Driver for High Definition Audio'
    class      = multimedia
    subclass   = HDA
    cap 01[50] = powerspec 2  supports D0 D3  current D0
isab0@pci0:0:30:0:	class=0x060100 card=0x81561043 chip=0x157310b9 rev=0x31 hdr=0x00
    vendor     = 'Acer Labs Incorporated (ALi/ULi)'
    device     = 'ALI M1573 South Bridge with Hypertransport Support'
    class      = bridge
    subclass   = PCI-ISA
none0@pci0:0:30:1:	class=0x068000 card=0x81561043 chip=0x710110b9 rev=0x00 hdr=0x00
    vendor     = 'Acer Labs Incorporated (ALi/ULi)'
    device     = 'ALI M7101 Power Management Controller'
    class      = bridge
atapci0@pci0:0:31:0:	class=0x01018a card=0x81561043 chip=0x522910b9 rev=0xc7 hdr=0x00
    vendor     = 'Acer Labs Incorporated (ALi/ULi)'
    device     = 'M5229 Southbridge EIDE Controller'
    class      = mass storage
    subclass   = ATA
    cap 01[60] = powerspec 2  supports D0 D3  current D0
atapci1@pci0:0:31:1:	class=0x010400 card=0x81561043 chip=0x528710b9 rev=0x02 hdr=0x00
    vendor     = 'Acer Labs Incorporated (ALi/ULi)'
    device     = '52871849 ALI SATA controller'
    class      = mass storage
    subclass   = RAID
    cap 01[60] = powerspec 2  supports D0 D3  current D0
vgapci0@pci0:1:0:0:	class=0x030000 card=0x3000174b chip=0x5b631002 rev=0x00 hdr=0x00
    vendor     = 'ATI Technologies Inc'
    device     = 'Radeon X550 Series'
    class      = display
    subclass   = VGA
    cap 01[50] = powerspec 2  supports D0 D1 D2 D3  current D0
    cap 10[58] = PCI-Express 1 endpoint
    cap 05[80] = MSI supports 1 message, 64 bit 
vgapci1@pci0:1:0:1:	class=0x038000 card=0x3001174b chip=0x5b731002 rev=0x00 hdr=0x00
    vendor     = 'ATI Technologies Inc'
    device     = 'Radeon X550 Series - Secondary'
    class      = display
    cap 01[50] = powerspec 2  supports D0 D1 D2 D3  current D0
    cap 10[58] = PCI-Express 1 endpoint
mskc0@pci0:2:0:0:	class=0x020000 card=0x81421043 chip=0x436211ab rev=0x19 hdr=0x00
    vendor     = 'Marvell Semiconductor (Was: Galileo Technology Ltd)'
    device     = '88E8053 Marvell Yukon 88E8053 PCI-E Gigabit Ethernet Controller'
    class      = network
    subclass   = ethernet
    cap 01[48] = powerspec 2  supports D0 D1 D2 D3  current D0
    cap 03[50] = VPD
    cap 05[5c] = MSI supports 2 messages, 64 bit enabled with 2 messages
    cap 10[e0] = PCI-Express 1 legacy endpoint
none1@pci0:4:18:0:	class=0x0c0010 card=0x808a1043 chip=0x30441106 rev=0x80 hdr=0x00
    vendor     = 'VIA Technologies Inc'
    device     = 'VT6306 VIA Fire II IEEE-1394 OHCI Link Layer Controller'
    class      = serial bus
    subclass   = FireWire
    cap 01[50] = powerspec 2  supports D0 D2 D3  current D0
anglepoise# lspci -vv

00:00.0 Host bridge: ATI Technologies Inc RS480 Host Bridge (rev 10)
	Subsystem: ASUSTeK Computer Inc. Device 8185
	Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
	Status: Cap- 66MHz+ UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort+ >SERR- <PERR- INTx-
	Latency: 0

00:02.0 PCI bridge: ATI Technologies Inc RS480 PCI-X Root Port (prog-if 00 [Normal decode])
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx-
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0, Cache Line Size: 64 bytes
	Bus: primary=00, secondary=01, subordinate=01, sec-latency=0
	I/O behind bridge: 0000b000-0000bfff
	Memory behind bridge: fe000000-fe8fffff
	Prefetchable memory behind bridge: 00000000cff00000-00000000dfefffff
	Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort+ <SERR- <PERR-
	BridgeCtl: Parity+ SERR+ NoISA- VGA+ MAbort- >Reset- FastB2B-
		PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
	Capabilities: [50] Power Management version 3
		Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
		Status: D0 PME-Enable- DSel=0 DScale=0 PME-
	Capabilities: [58] Express (v1) Root Port (Slot-), MSI 00
		DevCap:	MaxPayload 128 bytes, PhantFunc 0, Latency L0s <64ns, L1 <1us
			ExtTag+ RBE- FLReset-
		DevCtl:	Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
			RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop+
			MaxPayload 128 bytes, MaxReadReq 128 bytes
		DevSta:	CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr- TransPend-
		LnkCap:	Port #0, Speed 2.5GT/s, Width x16, ASPM L0s L1, Latency L0 <64ns, L1 <1us
			ClockPM- Suprise- LLActRep- BwNot-
		LnkCtl:	ASPM Disabled; RCB 64 bytes Disabled- Retrain- CommClk-
			ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
		LnkSta:	Speed 2.5GT/s, Width x16, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt-
		RootCtl: ErrCorrectable- ErrNon-Fatal- ErrFatal- PMEIntEna- CRSVisible-
		RootCap: CRSVisible-
		RootSta: PME ReqID 0000, PMEStatus- PMEPending-
	Capabilities: [80] MSI: Mask- 64bit- Count=1/1 Enable-
		Address: 00000000  Data: 0000
	Capabilities: [b0] Subsystem: ATI Technologies Inc Device 5950
	Capabilities: [b8] HyperTransport: MSI Mapping Enable+ Fixed+

00:06.0 PCI bridge: ATI Technologies Inc RS480 PCI Bridge (prog-if 00 [Normal decode])
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx-
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0, Cache Line Size: 64 bytes
	Bus: primary=00, secondary=02, subordinate=02, sec-latency=0
	I/O behind bridge: 0000c000-0000cfff
	Memory behind bridge: fe900000-fe9fffff
	Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort+ <SERR- <PERR-
	BridgeCtl: Parity+ SERR+ NoISA+ VGA- MAbort- >Reset- FastB2B-
		PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
	Capabilities: [50] Power Management version 3
		Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
		Status: D0 PME-Enable- DSel=0 DScale=0 PME-
	Capabilities: [58] Express (v1) Root Port (Slot-), MSI 00
		DevCap:	MaxPayload 128 bytes, PhantFunc 0, Latency L0s <64ns, L1 <1us
			ExtTag+ RBE- FLReset-
		DevCtl:	Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
			RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop+
			MaxPayload 128 bytes, MaxReadReq 128 bytes
		DevSta:	CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr- TransPend-
		LnkCap:	Port #3, Speed 2.5GT/s, Width x1, ASPM L0s L1, Latency L0 <64ns, L1 <1us
			ClockPM- Suprise- LLActRep- BwNot-
		LnkCtl:	ASPM Disabled; RCB 64 bytes Disabled- Retrain- CommClk-
			ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
		LnkSta:	Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt-
		RootCtl: ErrCorrectable- ErrNon-Fatal- ErrFatal- PMEIntEna- CRSVisible-
		RootCap: CRSVisible-
		RootSta: PME ReqID 0000, PMEStatus- PMEPending-
	Capabilities: [80] MSI: Mask- 64bit- Count=1/1 Enable-
		Address: 00000000  Data: 0000
	Capabilities: [b0] Subsystem: ATI Technologies Inc Device 5950
	Capabilities: [b8] HyperTransport: MSI Mapping Enable+ Fixed+

00:07.0 PCI bridge: ATI Technologies Inc RS480 PCI Bridge (prog-if 00 [Normal decode])
	Control: I/O- Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx-
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0, Cache Line Size: 64 bytes
	Bus: primary=00, secondary=03, subordinate=03, sec-latency=0
	Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- <SERR- <PERR-
	BridgeCtl: Parity+ SERR+ NoISA+ VGA- MAbort- >Reset- FastB2B-
		PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
	Capabilities: [50] Power Management version 3
		Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
		Status: D0 PME-Enable- DSel=0 DScale=0 PME-
	Capabilities: [58] Express (v1) Root Port (Slot-), MSI 00
		DevCap:	MaxPayload 128 bytes, PhantFunc 0, Latency L0s <64ns, L1 <1us
			ExtTag+ RBE- FLReset-
		DevCtl:	Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
			RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop+
			MaxPayload 128 bytes, MaxReadReq 128 bytes
		DevSta:	CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr- TransPend-
		LnkCap:	Port #247, Speed 2.5GT/s, Width x1, ASPM L0s L1, Latency L0 <64ns, L1 <1us
			ClockPM- Suprise- LLActRep- BwNot-
		LnkCtl:	ASPM Disabled; RCB 64 bytes Disabled- Retrain- CommClk-
			ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
		LnkSta:	Speed 2.5GT/s, Width x16, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt-
		RootCtl: ErrCorrectable- ErrNon-Fatal- ErrFatal- PMEIntEna- CRSVisible-
		RootCap: CRSVisible-
		RootSta: PME ReqID 0000, PMEStatus- PMEPending-
	Capabilities: [80] MSI: Mask- 64bit- Count=1/1 Enable-
		Address: 00000000  Data: 0000
	Capabilities: [b0] Subsystem: ATI Technologies Inc Device 5950
	Capabilities: [b8] HyperTransport: MSI Mapping Enable+ Fixed+

00:18.0 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] HyperTransport Technology Configuration
	Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Capabilities: [80] HyperTransport: Host or Secondary Interface
		Command: WarmRst+ DblEnd- DevNum=0 ChainSide- HostHide+ Slave- <EOCErr- DUL-
		Link Control: CFlE- CST- CFE- <LkFail- Init+ EOC- TXO- <CRCErr=0 IsocEn- LSEn- ExtCTL- 64b-
		Link Config: MLWI=16bit DwFcIn- MLWO=16bit DwFcOut- LWI=16bit DwFcInEn- LWO=16bit DwFcOutEn-
		Revision ID: 1.02
		Link Frequency: 1.0GHz
		Link Error: <Prot- <Ovfl- <EOC- CTLTm-
		Link Frequency Capability: 200MHz+ 300MHz- 400MHz+ 500MHz- 600MHz+ 800MHz+ 1.0GHz+ 1.2GHz- 1.4GHz- 1.6GHz- Vend-
		Feature Capability: IsocFC- LDTSTOP+ CRCTM- ECTLT- 64bA- UIDRD- ExtRS- UCnfE-

00:18.1 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Address Map
	Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
	Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-

00:18.2 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] DRAM Controller
	Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
	Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-

00:18.3 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Miscellaneous Control
	Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
	Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-

00:19.0 PCI bridge: ALi Corporation M5249 HTT to PCI Bridge (prog-if 00 [Normal decode])
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx-
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort+ >SERR+ <PERR- INTx-
	Latency: 0
	Bus: primary=00, secondary=04, subordinate=04, sec-latency=64
	I/O behind bridge: 0000d000-0000dfff
	Memory behind bridge: fea00000-feafffff
	Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort+ <SERR+ <PERR+
	BridgeCtl: Parity+ SERR+ NoISA+ VGA- MAbort- >Reset- FastB2B-
		PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
	Capabilities: [c0] HyperTransport: MSI Mapping Enable+ Fixed+

00:1c.0 USB Controller: ALi Corporation USB 1.1 Controller (rev 03) (prog-if 10 [OHCI])
	Subsystem: ASUSTeK Computer Inc. Device 8156
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx-
	Status: Cap- 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR+ INTx+
	Latency: 64 (20000ns max), Cache Line Size: 64 bytes
	Interrupt: pin A routed to IRQ 17
	Region 0: Memory at febfc000 (32-bit, non-prefetchable)

00:1c.1 USB Controller: ALi Corporation USB 1.1 Controller (rev 03) (prog-if 10 [OHCI])
	Subsystem: ASUSTeK Computer Inc. Device 8156
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx-
	Status: Cap- 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR+ INTx+
	Latency: 64 (20000ns max), Cache Line Size: 64 bytes
	Interrupt: pin B routed to IRQ 18
	Region 0: Memory at febfd000 (32-bit, non-prefetchable)

00:1c.2 USB Controller: ALi Corporation USB 1.1 Controller (rev 03) (prog-if 10 [OHCI])
	Subsystem: ASUSTeK Computer Inc. Device 8156
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx-
	Status: Cap- 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR+ INTx+
	Latency: 64 (20000ns max), Cache Line Size: 64 bytes
	Interrupt: pin C routed to IRQ 19
	Region 0: Memory at febfe000 (32-bit, non-prefetchable)

00:1c.3 USB Controller: ALi Corporation USB 2.0 Controller (rev 01) (prog-if 20 [EHCI])
	Subsystem: ASUSTeK Computer Inc. Device 8156
	Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx-
	Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR+ INTx-
	Latency: 64 (4000ns min, 8000ns max), Cache Line Size: 64 bytes
	Interrupt: pin D routed to IRQ 23
	Region 0: Memory at febffc00 (32-bit, non-prefetchable)
	Capabilities: [50] Power Management version 2
		Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
		Status: D0 PME-Enable- DSel=0 DScale=0 PME-
	Capabilities: [58] Debug port: BAR=1 offset=0090

00:1d.0 Audio device: ALi Corporation High Definition Audio/AC'97 Host Controller
	Subsystem: ASUSTeK Computer Inc. Device 81b4
	Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx-
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 64 (4000ns min, 20000ns max)
	Interrupt: pin C routed to IRQ 22
	Region 0: Memory at febf8000 (64-bit, non-prefetchable)
	Capabilities: [50] Power Management version 2
		Flags: PMEClk- DSI- D1- D2- AuxCurrent=55mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
		Status: D0 PME-Enable- DSel=0 DScale=0 PME-

00:1e.0 ISA bridge: ALi Corporation PCI to LPC Controller (rev 31)
	Subsystem: ASUSTeK Computer Inc. Device 8156
	Control: I/O+ Mem+ BusMaster+ SpecCycle+ MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
	Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0 (250ns min, 6000ns max)
	Interrupt: pin ? routed to IRQ 255

00:1e.1 Bridge: ALi Corporation M7101 Power Management Controller [PMU]
	Subsystem: ASUSTeK Computer Inc. Device 8156
	Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
	Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-

00:1f.0 IDE interface: ALi Corporation M5229 IDE (rev c7) (prog-if 8a [Master SecP PriP])
	Subsystem: ASUSTeK Computer Inc. Device 8156
	Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
	Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 32
	Interrupt: pin A routed to IRQ 255
	Region 4: I/O ports at ff00
	Capabilities: [60] Power Management version 2
		Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
		Status: D0 PME-Enable- DSel=0 DScale=0 PME-

00:1f.1 RAID bus controller: ALi Corporation ULi 5287 SATA (rev 02)
	Subsystem: ASUSTeK Computer Inc. Device 8156
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx-
	Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 128, Cache Line Size: 512 bytes
	Interrupt: pin A routed to IRQ 21
	Region 0: I/O ports at ec00
	Region 1: I/O ports at e880
	Region 2: I/O ports at e800
	Region 3: I/O ports at e480
	Region 4: I/O ports at e400
	Region 5: Memory at febff800 (32-bit, non-prefetchable)
	Capabilities: [60] Power Management version 2
		Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot+,D3cold-)
		Status: D0 PME-Enable- DSel=0 DScale=0 PME+

01:00.0 VGA compatible controller: ATI Technologies Inc RV370 [Sapphire X550 Silent] (prog-if 00 [VGA controller])
	Subsystem: PC Partner Limited Device 3000
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx-
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0, Cache Line Size: 64 bytes
	Interrupt: pin A routed to IRQ 18
	Region 0: Memory at d0000000 (32-bit, prefetchable)
	Region 1: I/O ports at b800
	Region 2: Memory at fe400000 (32-bit, non-prefetchable)
	Expansion ROM at fe8e0000 [disabled]
	Capabilities: [50] Power Management version 2
		Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
		Status: D0 PME-Enable- DSel=0 DScale=0 PME-
	Capabilities: [58] Express (v1) Endpoint, MSI 00
		DevCap:	MaxPayload 128 bytes, PhantFunc 0, Latency L0s <128ns, L1 <2us
			ExtTag+ AttnBtn- AttnInd- PwrInd- RBE- FLReset-
		DevCtl:	Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
			RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop+
			MaxPayload 128 bytes, MaxReadReq 128 bytes
		DevSta:	CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr- TransPend-
		LnkCap:	Port #0, Speed 2.5GT/s, Width x16, ASPM L0s L1, Latency L0 <128ns, L1 <1us
			ClockPM- Suprise- LLActRep- BwNot-
		LnkCtl:	ASPM Disabled; RCB 64 bytes Disabled- Retrain- CommClk-
			ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
		LnkSta:	Speed 2.5GT/s, Width x16, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt-
	Capabilities: [80] MSI: Mask- 64bit+ Count=1/1 Enable-
		Address: 0000000000000000  Data: 0000

01:00.1 Display controller: ATI Technologies Inc RV370 secondary [Sapphire X550 Silent]
	Subsystem: PC Partner Limited Device 3001
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0, Cache Line Size: 64 bytes
	Interrupt: pin ? routed to IRQ 255
	Region 0: Memory at fe8d0000 (32-bit, non-prefetchable)
	Capabilities: [50] Power Management version 2
		Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
		Status: D0 PME-Enable- DSel=0 DScale=0 PME-
	Capabilities: [58] Express (v1) Endpoint, MSI 00
		DevCap:	MaxPayload 128 bytes, PhantFunc 0, Latency L0s <128ns, L1 <2us
			ExtTag- AttnBtn- AttnInd- PwrInd- RBE- FLReset-
		DevCtl:	Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
			RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop-
			MaxPayload 128 bytes, MaxReadReq 128 bytes
		DevSta:	CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr- TransPend-
		LnkCap:	Port #0, Speed 2.5GT/s, Width x16, ASPM L0s L1, Latency L0 <128ns, L1 <1us
			ClockPM- Suprise- LLActRep- BwNot-
		LnkCtl:	ASPM Disabled; RCB 64 bytes Disabled- Retrain- CommClk-
			ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
		LnkSta:	Speed 2.5GT/s, Width x16, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt-

02:00.0 Ethernet controller: Marvell Technology Group Ltd. 88E8053 PCI-E Gigabit Ethernet Controller (rev 19)
	Subsystem: ASUSTeK Computer Inc. Marvell 88E8053 Gigabit Ethernet controller PCIe (Asus)
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx-
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0, Cache Line Size: 64 bytes
	Interrupt: pin A routed to IRQ 18
	Region 0: Memory at fe9fc000 (64-bit, non-prefetchable)
	Region 2: I/O ports at c800
	Expansion ROM at fe9c0000 [disabled]
	Capabilities: [48] Power Management version 2
		Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold+)
		Status: D0 PME-Enable- DSel=0 DScale=1 PME-
	Capabilities: [50] Vital Product Data <?>
	Capabilities: [5c] MSI: Mask- 64bit+ Count=2/2 Enable+
		Address: 00000000fee00000  Data: 0032
	Capabilities: [e0] Express (v1) Legacy Endpoint, MSI 00
		DevCap:	MaxPayload 128 bytes, PhantFunc 0, Latency L0s unlimited, L1 unlimited
			ExtTag- AttnBtn- AttnInd- PwrInd- RBE- FLReset-
		DevCtl:	Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
			RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop-
			MaxPayload 128 bytes, MaxReadReq 4096 bytes
		DevSta:	CorrErr+ UncorrErr+ FatalErr- UnsuppReq+ AuxPwr+ TransPend-
		LnkCap:	Port #3, Speed 2.5GT/s, Width x1, ASPM L0s, Latency L0 <256ns, L1 unlimited
			ClockPM- Suprise- LLActRep- BwNot-
		LnkCtl:	ASPM Disabled; RCB 128 bytes Disabled- Retrain- CommClk-
			ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
		LnkSta:	Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt-

04:12.0 FireWire (IEEE 1394): VIA Technologies, Inc. VT6306 Fire II IEEE 1394 OHCI Link Layer Controller (rev 80) (prog-if 10 [OHCI])
	Subsystem: ASUSTeK Computer Inc. A8V/A8N/P4P800 series motherboard
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx-
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 64 (8000ns max), Cache Line Size: 64 bytes
	Interrupt: pin A routed to IRQ 16
	Region 0: Memory at feafe800 (32-bit, non-prefetchable)
	Region 1: I/O ports at dc00
	Capabilities: [50] Power Management version 2
		Flags: PMEClk- DSI- D1- D2+ AuxCurrent=0mA PME(D0-,D1-,D2+,D3hot+,D3cold+)
		Status: D0 PME-Enable- DSel=0 DScale=0 PME-

anglepoise# pciconf -l

hostb0@pci0:0:0:0:	class=0x060000 card=0x81851043 chip=0x59501002 rev=0x10 hdr=0x00
pcib1@pci0:0:2:0:	class=0x060400 card=0x59501002 chip=0x5a341002 rev=0x00 hdr=0x01
pcib2@pci0:0:6:0:	class=0x060400 card=0x59501002 chip=0x5a381002 rev=0x00 hdr=0x01
pcib3@pci0:0:7:0:	class=0x060400 card=0x59501002 chip=0x5a391002 rev=0x00 hdr=0x01
hostb1@pci0:0:24:0:	class=0x060000 card=0x00000000 chip=0x11001022 rev=0x00 hdr=0x00
hostb2@pci0:0:24:1:	class=0x060000 card=0x00000000 chip=0x11011022 rev=0x00 hdr=0x00
hostb3@pci0:0:24:2:	class=0x060000 card=0x00000000 chip=0x11021022 rev=0x00 hdr=0x00
hostb4@pci0:0:24:3:	class=0x060000 card=0x00000000 chip=0x11031022 rev=0x00 hdr=0x00
pcib4@pci0:0:25:0:	class=0x060400 card=0x00000000 chip=0x524910b9 rev=0x00 hdr=0x01
ohci0@pci0:0:28:0:	class=0x0c0310 card=0x81561043 chip=0x523710b9 rev=0x03 hdr=0x00
ohci1@pci0:0:28:1:	class=0x0c0310 card=0x81561043 chip=0x523710b9 rev=0x03 hdr=0x00
ohci2@pci0:0:28:2:	class=0x0c0310 card=0x81561043 chip=0x523710b9 rev=0x03 hdr=0x00
ehci0@pci0:0:28:3:	class=0x0c0320 card=0x81561043 chip=0x523910b9 rev=0x01 hdr=0x00
hdac0@pci0:0:29:0:	class=0x040300 card=0x81b41043 chip=0x546110b9 rev=0x00 hdr=0x00
isab0@pci0:0:30:0:	class=0x060100 card=0x81561043 chip=0x157310b9 rev=0x31 hdr=0x00
none0@pci0:0:30:1:	class=0x068000 card=0x81561043 chip=0x710110b9 rev=0x00 hdr=0x00
atapci0@pci0:0:31:0:	class=0x01018a card=0x81561043 chip=0x522910b9 rev=0xc7 hdr=0x00
atapci1@pci0:0:31:1:	class=0x010400 card=0x81561043 chip=0x528710b9 rev=0x02 hdr=0x00
vgapci0@pci0:1:0:0:	class=0x030000 card=0x3000174b chip=0x5b631002 rev=0x00 hdr=0x00
vgapci1@pci0:1:0:1:	class=0x038000 card=0x3001174b chip=0x5b731002 rev=0x00 hdr=0x00
mskc0@pci0:2:0:0:	class=0x020000 card=0x81421043 chip=0x436211ab rev=0x19 hdr=0x00
none1@pci0:4:18:0:	class=0x0c0010 card=0x808a1043 chip=0x30441106 rev=0x80 hdr=0x00
anglepoise# lspci -h

lspci: illegal option -- h
Usage: lspci [<switches>]

Basic display modes:
-mm		Produce machine-readable output (single -m for an obsolete format)
-t		Show bus tree

Display options:
-v		Be verbose (-vv for very verbose)
-x		Show hex-dump of the standard part of the config space
-xxx		Show hex-dump of the whole config space (dangerous; root only)
-xxxx		Show hex-dump of the 4096-byte extended config space (root only)
-b		Bus-centric view (addresses and IRQ's as seen by the bus)
-D		Always show domain numbers

Resolving of device ID's to names:
-n		Show numeric ID's
-nn		Show both textual and numeric ID's (names & numbers)
-q		Query the PCI ID database for unknown ID's via DNS
-qq		As above, but re-query locally cached entries
-Q		Query the PCI ID database for all ID's via DNS

Selection of devices:
-s [[[[<domain>]:]<bus>]:][<slot>][.[<func>]]	Show only devices in selected slots
-d [<vendor>]:[<device>]			Show only devices with specified ID's

Other options:
-i <file>	Use specified ID database instead of /usr/local/share/pciutils/pci.ids.gz
-M		Enable `bus mapping' mode (dangerous; root only)

PCI access options:
-A <method>	Use the specified PCI access method (see `-A help' for a list)
-O <par>=<val>	Set PCI access parameter (see `-O help' for a list)
-G		Enable PCI access debugging
-F <file>	Read PCI configuration dump from a given file
anglepoise# lspci --s 0:1c.2

00:1c.2 USB Controller: ALi Corporation USB 1.1 Controller (rev 03)
anglepoise# lspci -s 0:1c.2 -v

00:1c.2 USB Controller: ALi Corporation USB 1.1 Controller (rev 03) (prog-if 10 [OHCI])
	Subsystem: ASUSTeK Computer Inc. Device 8156
	Flags: bus master, 66MHz, medium devsel, latency 64, IRQ 19
	Memory at febfe000 (32-bit, non-prefetchable)

anglepoise# lspci -s 0:1c.2 -v -v1 -v

00:1c.1 USB Controller: ALi Corporation USB 1.1 Controller (rev 03) (prog-if 10 [OHCI])
	Subsystem: ASUSTeK Computer Inc. Device 8156
	Flags: bus master, 66MHz, medium devsel, latency 64, IRQ 18
	Memory at febfd000 (32-bit, non-prefetchable)

anglepoise# echo 'this is the affected controller'

this is the affected controller
anglepoise# echo 'this is the affected controller'[13`lspci -s 0:1c.1 -v -s 0:	c.1 -v

anglepoise# pciconf -h

usage: pciconf -l [-cv]
       pciconf -a selector
       pciconf -r [-b | -h] selector addr[:addr2]
       pciconf -w [-b | -h] selector addr value
anglepoise# pciconf -ha 0:128:1

pciconf: cannot parse selector 0:28:1
anglepoise# pciconf -a 0:28:1.1

pciconf: cannot parse selector 0:28.1
anglepoise# pciconf -a 0:28.1pci0:00:1c:1

pciconf: cannot parse selector pci0:0:1c:1
anglepoise# pciconf -a pci0:0:1c:11.1

pciconf: cannot parse selector pci0:0:1c.1
anglepoise# pciconf -l

hostb0@pci0:0:0:0:	class=0x060000 card=0x81851043 chip=0x59501002 rev=0x10 hdr=0x00
pcib1@pci0:0:2:0:	class=0x060400 card=0x59501002 chip=0x5a341002 rev=0x00 hdr=0x01
pcib2@pci0:0:6:0:	class=0x060400 card=0x59501002 chip=0x5a381002 rev=0x00 hdr=0x01
pcib3@pci0:0:7:0:	class=0x060400 card=0x59501002 chip=0x5a391002 rev=0x00 hdr=0x01
hostb1@pci0:0:24:0:	class=0x060000 card=0x00000000 chip=0x11001022 rev=0x00 hdr=0x00
hostb2@pci0:0:24:1:	class=0x060000 card=0x00000000 chip=0x11011022 rev=0x00 hdr=0x00
hostb3@pci0:0:24:2:	class=0x060000 card=0x00000000 chip=0x11021022 rev=0x00 hdr=0x00
hostb4@pci0:0:24:3:	class=0x060000 card=0x00000000 chip=0x11031022 rev=0x00 hdr=0x00
pcib4@pci0:0:25:0:	class=0x060400 card=0x00000000 chip=0x524910b9 rev=0x00 hdr=0x01
ohci0@pci0:0:28:0:	class=0x0c0310 card=0x81561043 chip=0x523710b9 rev=0x03 hdr=0x00
ohci1@pci0:0:28:1:	class=0x0c0310 card=0x81561043 chip=0x523710b9 rev=0x03 hdr=0x00
ohci2@pci0:0:28:2:	class=0x0c0310 card=0x81561043 chip=0x523710b9 rev=0x03 hdr=0x00
ehci0@pci0:0:28:3:	class=0x0c0320 card=0x81561043 chip=0x523910b9 rev=0x01 hdr=0x00
hdac0@pci0:0:29:0:	class=0x040300 card=0x81b41043 chip=0x546110b9 rev=0x00 hdr=0x00
isab0@pci0:0:30:0:	class=0x060100 card=0x81561043 chip=0x157310b9 rev=0x31 hdr=0x00
none0@pci0:0:30:1:	class=0x068000 card=0x81561043 chip=0x710110b9 rev=0x00 hdr=0x00
atapci0@pci0:0:31:0:	class=0x01018a card=0x81561043 chip=0x522910b9 rev=0xc7 hdr=0x00
atapci1@pci0:0:31:1:	class=0x010400 card=0x81561043 chip=0x528710b9 rev=0x02 hdr=0x00
vgapci0@pci0:1:0:0:	class=0x030000 card=0x3000174b chip=0x5b631002 rev=0x00 hdr=0x00
vgapci1@pci0:1:0:1:	class=0x038000 card=0x3001174b chip=0x5b731002 rev=0x00 hdr=0x00
mskc0@pci0:2:0:0:	class=0x020000 card=0x81421043 chip=0x436211ab rev=0x19 hdr=0x00
none1@pci0:4:18:0:	class=0x0c0010 card=0x808a1043 chip=0x30441106 rev=0x80 hdr=0x00
anglepoise# pciconf pci0:0:28:1[@-[@a[@ 

pciconf: ioctl(PCIOCATTACHED): Inappropriate ioctl for device
anglepoise# pciconf -a pci0:0:28:1[@o[@h[@c[@i[@1[@"[@@

pciconf: ioctl(PCIOCATTACHED): Inappropriate ioctl for device
anglepoise# pciconf -a ohci1@pci0:0:28:10

pciconf: ioctl(PCIOCATTACHED): Inappropriate ioctl for device
anglepoise# pciconf -a ohci1@pci0:0:28:01

pciconf: ioctl(PCIOCATTACHED): Inappropriate ioctl for device
anglepoise# pciconf -a ohci1@pci0:0:28:1[@l

usage: pciconf -l [-cv]
       pciconf -a selector
       pciconf -r [-b | -h] selector addr[:addr2]
       pciconf -w [-b | -h] selector addr value
anglepoise# pciconf -l ohci1@pci0:0:28:1[@r [@ [@-[@b[44` 0:01

b9 10 
anglepoise# usbdevs v-v

Controller /dev/usb0:
addr 1: full speed, self powered, config 1, OHCI root hub(0x0000), AcerLabs(0x0000), rev 1.00
 port 1 addr 2: full speed, self powered, config 1, product 0x2046(0x2046), vendor 0x0451(0x0451), rev 1.25
  port 1 powered
  port 2 powered
  port 3 powered
  port 4 powered
 port 2 powered
 port 3 powered
Controller /dev/usb1:
addr 1: full speed, self powered, config 1, OHCI root hub(0x0000), AcerLabs(0x0000), rev 1.00
 port 1 powered
 port 2 powered
 port 3 powered
Controller /dev/usb2:
addr 1: full speed, self powered, config 1, OHCI root hub(0x0000), AcerLabs(0x0000), rev 1.00
 port 1 powered
 port 2 powered
 port 3 powered
Controller /dev/usb3:
addr 1: high speed, self powered, config 1, EHCI root hub(0x0000), AcerLabs(0x0000), rev 1.00
 port 1 powered
 port 2 powered
 port 3 powered
 port 4 powered
 port 5 addr 2: high speed, self powered, config 1, USB2.0 Hub(0x0606), vendor 0x05e3(0x05e3), rev 7.02
  port 1 powered
  port 2 powered
  port 3 powered
  port 4 powered
 port 6 powered
 port 7 powered
 port 8 powered
anglepoise# 

anglepoise# echo 'all ok'

all ok
anglepoise# ^Dexit

Script done on Fri Feb 13 04:33:15 2009
From ota at j.email.ne.jp  Thu Feb 12 20:43:03 2009
From: ota at j.email.ne.jp (Yoshihiro Ota)
Date: Thu Feb 12 20:43:36 2009
Subject: Broken loader on 7.1-STABLE?
In-Reply-To: <498E59F0.30700@paradise.net.nz>
References: <20090109171857.GA49752@marvin.eastcentral.edu>
	<4975ADF4.1070103@paradise.net.nz>
	<4976CB1C.7050409@paradise.net.nz> <498E59F0.30700@paradise.net.nz>
Message-ID: <20090212232432.84e455f8.ota@j.email.ne.jp>

On Sun, 08 Feb 2009 17:05:04 +1300
Mark Kirkwood <markir@paradise.net.nz> wrote:

> Mark Kirkwood wrote:
> > I wrote:
> >>  
> >> I am getting this too - update from RELENG_7 @12 Jan src to 20 Jan 
> >> and I have:
> >>
> >> panic: free: guard1 fail @ 0x511d
> >> from /usr/src/sys/boot/i386/loader/../../common/module.c:959
> >>
> >> Can't work out which disk we are booting from.
> >> Guessed BIOS device 0xffffffff not found by probes, defaulting to disk0

I am experiencing same error.

In my case, I cannot boot from anything other than /boot/kernel.
While my /boot/kernel is bootable, I do "cp -pr /boot/kernel /boot/kernel.ok".
Then, it fails like the error message above.
After I do mv /boot/kernel.ok /boot/kernel, it boots fine.

My environment is HP pavilion dv6425 with FreeBSD 7.1.
I think I started noticing this since 7.1-RC.

Regards,
Hiro
From bakul at bitblocks.com  Thu Feb 12 21:58:04 2009
From: bakul at bitblocks.com (Bakul Shah)
Date: Thu Feb 12 21:58:11 2009
Subject: Upgrade from 32-bit to AMD-64? 
In-Reply-To: Your message of "Thu, 12 Feb 2009 21:01:38 CST."
	<4994E292.4000802@denninger.net> 
References: <4994CD7B.7040302@denninger.net> <4994D603.2060406@delphij.net>
	<4994D931.4060508@denninger.net> <4994DACC.1040801@delphij.net>
	<4994DBC1.2000309@denninger.net> <4994DFB0.3060704@delphij.net>
	<4994E292.4000802@denninger.net>
Message-ID: <20090213054059.1D4825B37@mail.bitblocks.com>

On Thu, 12 Feb 2009 21:01:38 CST Karl Denninger <karl@denninger.net>  wrote:
> >> I guess I need to schedule the 2-3 hours of downtime..... the reason for
> >> this, by the way, is that I have a dbms app on there that is getting too
> >> RAM hungry for its own good (its a Quadcore CPU) and I'm up against the
> >> RAM limit for 32-bit code.  The board will support more but 32-bit code
> >> won't; ergo, the only way to get beyond this is to go to 64-bit.
> >>     
> >
> > Oh wait!  One thing you wanted to know is that, some database *can* have
> > different on-disk format for 32-bit and 64-bit binaries.  Be sure to
> > have a dump handy.  Last time I hit this on a MySQL "upgrade" between
> > two servers, and I end up using its replication functionality.  The
> > operation took longer time than I expected at the beginning.
> >
> > My personal suggestion is that you do an experiment on another box
> > (64-bit capable) to make sure that the data would work, this never hurts
> > and avoids surprises (you do want 64-bit compile of your database
> > application since you want to take full advantage of 64-bit OS); also,
> > just like all upgrades, full backup is advised.
> >
> > Cheers,
> > - --
> > Xin LI <delphij@delphij.net>	http://www.delphij.net
> I already know I have to dump the database and then reload it - I 
> attempted to migrate the disk structure across (which would have saved 
> even more time) and got instantaneously hosed, presumably due to 
> internal data type length differences.
> 
> This little upgrade is going to take a while; sounds like the best 
> approach is to load a new box, shut down the dbms to connections and 
> dump/pipe it over, then physically swap the machines.

May be you can install the 64 bit world from an install CD to
a 2 to 4GB USB flash drive, reboot to the 64 bit kernel & set
root on the flash drive, mount your original filesystems
under /mnt, make and install with DESTDIR=/mnt, mergemaster
-D /mnt and reboot?
From henry.hu.sh at gmail.com  Thu Feb 12 22:51:15 2009
From: henry.hu.sh at gmail.com (Henry Hu)
Date: Thu Feb 12 22:51:23 2009
Subject: pkg_delete segfaulting after upgrading to 7.1
Message-ID: <53a1e0710902122229l606bb2c9pcc71ea38fafa1193@mail.gmail.com>

> rosbox# pkg_delete -f gpgme-1.1.5_1
> pkg_delete: package 'gpgme-1.1.5_1' is required by these other packages
> and may not be deinstalled (but I'll delete it anyway):
> seahorse-2.24.1_1
> Segmentation fault (core dumped)

I've had similar problem, and found the problem is in the +CONTENTS in
the corresponding folder under /var/db/pkg/ .
It's caused by an empty @pkgdep line here.
I don't know what went wrong when the +CONTENTS file was created. But
delete all these empty @pkgdep lines solved my problem.

Cheers,
Henry
From mandrews at bit0.com  Thu Feb 12 23:53:15 2009
From: mandrews at bit0.com (Mike Andrews)
Date: Thu Feb 12 23:53:22 2009
Subject: Upgrade from 32-bit to AMD-64?
In-Reply-To: <4994DFB0.3060704@delphij.net>
References: <4994CD7B.7040302@denninger.net>	<4994D603.2060406@delphij.net>	<4994D931.4060508@denninger.net>	<4994DACC.1040801@delphij.net>
	<4994DBC1.2000309@denninger.net> <4994DFB0.3060704@delphij.net>
Message-ID: <499526E9.3090804@bit0.com>

Xin LI wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Karl Denninger wrote:
> [...]
>> I guess I need to schedule the 2-3 hours of downtime..... the reason for
>> this, by the way, is that I have a dbms app on there that is getting too
>> RAM hungry for its own good (its a Quadcore CPU) and I'm up against the
>> RAM limit for 32-bit code.  The board will support more but 32-bit code
>> won't; ergo, the only way to get beyond this is to go to 64-bit.
> 
> Oh wait!  One thing you wanted to know is that, some database *can* have
> different on-disk format for 32-bit and 64-bit binaries.  Be sure to
> have a dump handy.  Last time I hit this on a MySQL "upgrade" between
> two servers, and I end up using its replication functionality.  The
> operation took longer time than I expected at the beginning.

For what it's worth, I did an in-place source upgrade on our MySQL 
server (for the same lack-of-memory reason) and didn't have any on-disk 
format problems.  In fact later on when troubleshooting data corruption 
problems that turned out to be bad hardware, I switched between 32-bit 
and 64-bit mysqld binaries without rebooting or dumping/reimporting the 
database.

BUT... there was no replication involved.  It wouldn't surprise me if 
the binlog or relay logs were in an architecture specific format. 
InnoDB and MyISAM tables don't appear to be.  This was over a year ago 
though, so test on a scratch box first and you may save yourself a bit 
of downtime.

The upgrade is a pain, and does have a lot of potential foot-shooting, 
and you have to immediately recompile ALL of your installed ports (and 
anything else not built from ports) to avoid mixing 32-bit and 64-bit 
shared libraries...  and that rebuilding ports time is where most of 
your downtime comes from if it's a production box.

If you're feeling lucky, the procedure's in the list archives somewhere 
and the super-short version is you turn your swap partition into a 
temporary amd64 root filesystem, installworld/kernel into that, boot 
into that, then mount and installworld/kernel on top of the old i386 
root filesystem from there, then boot into it and recompile all your 
ports (after reclaiming your swap partition for swap).  Or, the way I 
did it last time was to boot into a PXE diskless FreeBSD/amd64 install 
and use that to mount/install over the i386 stuff.

Definitely practice on a scratch system first. :)


-- 
Mike Andrews
Server Monkey
Fark, Inc
mandrews@fark.com
From goran.lowkrantz at ismobile.com  Fri Feb 13 01:05:21 2009
From: goran.lowkrantz at ismobile.com (Goran Lowkrantz)
Date: Fri Feb 13 01:05:29 2009
Subject: Upgrade from 32-bit to AMD-64?
In-Reply-To: <499526E9.3090804@bit0.com>
References: <4994CD7B.7040302@denninger.net>	<4994D603.2060406@delphij.net>
	<4994D931.4060508@denninger.net>	<4994DACC.1040801@delphij.net>
	<4994DBC1.2000309@denninger.net> <4994DFB0.3060704@delphij.net>
	<499526E9.3090804@bit0.com>
Message-ID: <2CA7DE699281AFA5DF2BD851@syn>

Hi,

When  have done this, MySQL is OK but Berkley and PostgreSQL need 
dump/restore.

/glz

--On February 13, 2009 2:53:13 -0500 Mike Andrews <mandrews@bit0.com> wrote:

> Xin LI wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> Karl Denninger wrote:
>> [...]
>>> I guess I need to schedule the 2-3 hours of downtime..... the reason for
>>> this, by the way, is that I have a dbms app on there that is getting too
>>> RAM hungry for its own good (its a Quadcore CPU) and I'm up against the
>>> RAM limit for 32-bit code.  The board will support more but 32-bit code
>>> won't; ergo, the only way to get beyond this is to go to 64-bit.
>>
>> Oh wait!  One thing you wanted to know is that, some database *can* have
>> different on-disk format for 32-bit and 64-bit binaries.  Be sure to
>> have a dump handy.  Last time I hit this on a MySQL "upgrade" between
>> two servers, and I end up using its replication functionality.  The
>> operation took longer time than I expected at the beginning.
>
> For what it's worth, I did an in-place source upgrade on our MySQL server
> (for the same lack-of-memory reason) and didn't have any on-disk format
> problems.  In fact later on when troubleshooting data corruption problems
> that turned out to be bad hardware, I switched between 32-bit and 64-bit
> mysqld binaries without rebooting or dumping/reimporting the database.
>
> BUT... there was no replication involved.  It wouldn't surprise me if the
> binlog or relay logs were in an architecture specific format. InnoDB and
> MyISAM tables don't appear to be.  This was over a year ago though, so
> test on a scratch box first and you may save yourself a bit of downtime.
>
> The upgrade is a pain, and does have a lot of potential foot-shooting,
> and you have to immediately recompile ALL of your installed ports (and
> anything else not built from ports) to avoid mixing 32-bit and 64-bit
> shared libraries...  and that rebuilding ports time is where most of your
> downtime comes from if it's a production box.
>
> If you're feeling lucky, the procedure's in the list archives somewhere
> and the super-short version is you turn your swap partition into a
> temporary amd64 root filesystem, installworld/kernel into that, boot into
> that, then mount and installworld/kernel on top of the old i386 root
> filesystem from there, then boot into it and recompile all your ports
> (after reclaiming your swap partition for swap).  Or, the way I did it
> last time was to boot into a PXE diskless FreeBSD/amd64 install and use
> that to mount/install over the i386 stuff.
>
> Definitely practice on a scratch system first. :)
>
>
> --
> Mike Andrews
> Server Monkey
> Fark, Inc
> mandrews@fark.com
> _______________________________________________
> 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"



................................................... the future isMobile

  Goran Lowkrantz <goran.lowkrantz@ismobile.com>
  System Architect, isMobile AB
  Sandviksgatan 81, PO Box 58, S-971 03 Lule?, Sweden
  Mobile: +46(0)70-587 87 82
http://www.ismobile.com ...............................................
From gerrit at pmp.uni-hannover.de  Fri Feb 13 01:19:14 2009
From: gerrit at pmp.uni-hannover.de (Gerrit =?ISO-8859-1?Q?K=FChn?=)
Date: Fri Feb 13 01:19:21 2009
Subject: fun with if_re
In-Reply-To: <20090205082804.GD77461@michelle.cdnetworks.co.kr>
References: <20090204100507.5f223d9e.gerrit@pmp.uni-hannover.de>
	<20090204104655.GA73543@michelle.cdnetworks.co.kr>
	<20090205085812.b2deb1f7.gerrit@pmp.uni-hannover.de>
	<20090205082804.GD77461@michelle.cdnetworks.co.kr>
Message-ID: <20090213101910.a126c14d.gerrit@pmp.uni-hannover.de>

On Thu, 5 Feb 2009 17:28:04 +0900 Pyun YongHyeon <pyunyh@gmail.com> wrote
about Re: fun with if_re:

PY> > I did build new nanobsd images with these patches meanwhile and will
PY> > start using them today. However, as it has worked without problems
PY> > for weeks with the buggy version before, I will not be able to say
PY> > if it is really working until next month or so. Or do you know any
PY> > method to reliably
PY> 
PY> That's fine.


I had to reboot some of the machines meanwhile and could do some further
testing. One strange thing I noticed is that the re-interfaces often do
not come up in a working state after rebooting. Strangely, I see
network traffic floating around via tcpdump, but not even ping works.
This state often goes away when playing around with the interface
(sometimes ifconfig down/up helps, sometimes disabling some of the
additional features like txc/rxc), but I cannot make out a reproducible
behaviour so far. When the interface leaves this strange state it seems to
work fine afterwards. Any clues?


cu
  Gerrit
From gerrit at pmp.uni-hannover.de  Fri Feb 13 01:29:00 2009
From: gerrit at pmp.uni-hannover.de (Gerrit =?ISO-8859-1?Q?K=FChn?=)
Date: Fri Feb 13 01:29:09 2009
Subject: zfs crashes with nfs and snapshots
In-Reply-To: <20090211175511.GA38986@a91-153-125-115.elisa-laajakaista.fi>
References: <20090211171110.a8217734.gerrit@pmp.uni-hannover.de>
	<20090211175511.GA38986@a91-153-125-115.elisa-laajakaista.fi>
Message-ID: <20090213102855.51976ec4.gerrit@pmp.uni-hannover.de>

On Wed, 11 Feb 2009 19:55:11 +0200 Jaakko Heinonen <jh@saunalahti.fi>
wrote about Re: zfs crashes with nfs and snapshots:

JH> This is likely the issue described in this message:
JH> http://lists.freebsd.org/pipermail/freebsd-fs/2008-October/005217.html

Yes, this looks very much like it.

JH> The nfs fix has been committed to head and stable/7 (7.1-RELEASE has
JH> the fix). The fix prevents system from panicing but you still can't
JH> access the snapshot directory with readdirplus enabled nfs clients. As
JH> a workaround you can disable readdirplus support if your nfs client
JH> allows it.

Ok, I will upgrade to 7.1-stable asap. The client was Linux 2.6.25, I
cannot say if it uses readdirplus and if I could disable that (the manpage
says nothing about it at all, but I will look into that further).
Thanks for the hint.


cu
  Gerrit
From bzeeb-lists at lists.zabbadoz.net  Fri Feb 13 01:45:07 2009
From: bzeeb-lists at lists.zabbadoz.net (Bjoern A. Zeeb)
Date: Fri Feb 13 01:45:21 2009
Subject: "The LOR page" is back
Message-ID: <20090213092746.R53478@maildrop.int.zabbadoz.net>

Hi,

in case you find a LOR, want to report it or want to see if it's known
or find out more about it... you can go and check "The LOR page"
again.  It's up on a temporary setup (so in case it's not avail come
back a bit later) until I can finally move the web elsewhere. The URL
has stayed the same:

 	http://sources.zabbadoz.net/freebsd/lor.html

The page has a few instructions and links to further information. You
may want to read them before doing anything else to help everybody.
Thanks!

/bz

-- 
Bjoern A. Zeeb                      The greatest risk is not taking one.
From richardtoohey at paradise.net.nz  Fri Feb 13 02:20:18 2009
From: richardtoohey at paradise.net.nz (Richard Toohey)
Date: Fri Feb 13 02:20:25 2009
Subject: 7.1 Panic on degraded disk w/mpt
Message-ID: <A66D4523-9D6D-4C93-900F-405053D6C1E5@paradise.net.nz>

Charles Sprickman said:

 >Howdy,
 >
 >I dug around and can't find a PR on this, and the only other report  
I saw
 >was in this mailing list post that has no replies:
 >
 >http://www.nabble.com/7.1-BETA2-panic-on-mpt-degrade-td20183173.html
 >
 >The hardware is a Dell PowerEdge 860 with the Dell/LSI SAS5  
controller:
 >mpt0: <LSILogic SAS/SATA Adapter> port 0xec00-0xecff mem
 >0xfe9fc000-0xfe9fffff,0xfe9e0000-0xfe9effff irq 16 at device 8.0 on  
pci2
 >mpt0: MPI Version=1.5.13.0
 >
 >The panic is repeatable by forcing the array into a degraded state.

I think this is PR 130330.

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

I am trying to get another test machine available - the machines
I had have gone into production with 7.0 installed.

(Apologies if this email doesn't appear correctly, done what I can!)
From pyunyh at gmail.com  Fri Feb 13 02:21:10 2009
From: pyunyh at gmail.com (Pyun YongHyeon)
Date: Fri Feb 13 02:21:17 2009
Subject: fun with if_re
In-Reply-To: <20090213101910.a126c14d.gerrit@pmp.uni-hannover.de>
References: <20090204100507.5f223d9e.gerrit@pmp.uni-hannover.de>
	<20090204104655.GA73543@michelle.cdnetworks.co.kr>
	<20090205085812.b2deb1f7.gerrit@pmp.uni-hannover.de>
	<20090205082804.GD77461@michelle.cdnetworks.co.kr>
	<20090213101910.a126c14d.gerrit@pmp.uni-hannover.de>
Message-ID: <20090213102400.GD12653@michelle.cdnetworks.co.kr>

On Fri, Feb 13, 2009 at 10:19:10AM +0100, Gerrit K?hn wrote:
> On Thu, 5 Feb 2009 17:28:04 +0900 Pyun YongHyeon <pyunyh@gmail.com> wrote
> about Re: fun with if_re:
> 
> PY> > I did build new nanobsd images with these patches meanwhile and will
> PY> > start using them today. However, as it has worked without problems
> PY> > for weeks with the buggy version before, I will not be able to say
> PY> > if it is really working until next month or so. Or do you know any
> PY> > method to reliably
> PY> 
> PY> That's fine.
> 
> 
> I had to reboot some of the machines meanwhile and could do some further
> testing. One strange thing I noticed is that the re-interfaces often do
> not come up in a working state after rebooting. Strangely, I see
> network traffic floating around via tcpdump, but not even ping works.
> This state often goes away when playing around with the interface
> (sometimes ifconfig down/up helps, sometimes disabling some of the
> additional features like txc/rxc), but I cannot make out a reproducible
> behaviour so far. When the interface leaves this strange state it seems to
> work fine afterwards. Any clues?
> 

Does this happen on latest if_re.c/if_rlreg.h? I guess jkim fixed
this type of problem in r187483. If that have no effect please let
me know.
From gerrit at pmp.uni-hannover.de  Fri Feb 13 02:41:47 2009
From: gerrit at pmp.uni-hannover.de (Gerrit =?ISO-8859-1?Q?K=FChn?=)
Date: Fri Feb 13 02:41:54 2009
Subject: fun with if_re
In-Reply-To: <20090213102400.GD12653@michelle.cdnetworks.co.kr>
References: <20090204100507.5f223d9e.gerrit@pmp.uni-hannover.de>
	<20090204104655.GA73543@michelle.cdnetworks.co.kr>
	<20090205085812.b2deb1f7.gerrit@pmp.uni-hannover.de>
	<20090205082804.GD77461@michelle.cdnetworks.co.kr>
	<20090213101910.a126c14d.gerrit@pmp.uni-hannover.de>
	<20090213102400.GD12653@michelle.cdnetworks.co.kr>
Message-ID: <20090213114143.a77f1acb.gerrit@pmp.uni-hannover.de>

On Fri, 13 Feb 2009 19:24:00 +0900 Pyun YongHyeon <pyunyh@gmail.com> wrote
about Re: fun with if_re:

PY> > I had to reboot some of the machines meanwhile and could do some
PY> > further testing. One strange thing I noticed is that the
PY> > re-interfaces often do not come up in a working state after
PY> > rebooting. Strangely, I see network traffic floating around via
PY> > tcpdump, but not even ping works. This state often goes away when
PY> > playing around with the interface (sometimes ifconfig down/up helps,
PY> > sometimes disabling some of the additional features like txc/rxc),
PY> > but I cannot make out a reproducible behaviour so far. When the
PY> > interface leaves this strange state it seems to work fine
PY> > afterwards. Any clues?

PY> Does this happen on latest if_re.c/if_rlreg.h? I guess jkim fixed
PY> this type of problem in r187483. If that have no effect please let
PY> me know.

It happens on both versions: the old one from 11th Dec 08 I still had, and
the new one I built with the patches you recommended about a week ago.
if_re is 1.151 2009/01/20 20:22:28 jkim, if_rlreg is 1.94 2009/01/20
20:22:28 jkim for the latter.


cu
  Gerrit
From horst at sxemacs.org  Fri Feb 13 02:48:19 2009
From: horst at sxemacs.org (Horst =?ISO-8859-1?Q?G=FCnther?= Burkhardt III)
Date: Fri Feb 13 02:48:33 2009
Subject: [7-STABLE] failure during buildworld
Message-ID: <1234522194.13304.34.camel@horst-tla>

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-inst.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++/del_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/libstdc++/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/libstdc++/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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20090213/649da84b/attachment.pgp
From scottl at samsco.org  Fri Feb 13 02:56:00 2009
From: scottl at samsco.org (Scott Long)
Date: Fri Feb 13 02:56:13 2009
Subject: HEADS UP: Major CAM performance regression
Message-ID: <499551B9.7050805@samsco.org>

All,

A major performance regression was introduced to the CAM subsystem in
FreeBSD 7.1.  The following configurations are known to be affected:

VMWare ESX
VMWare Fusion
     (using bt or lsilogic controller options)
HP CISS RAID
Some MPT-SAS combinations with SATA drives attached
     (Includes Dell SAS5/ir, but not PERC5/PERC6).

Pure SCSI and SAS subsystems likely are NOT affected.  Any hardware
that uses the 'ata' driver is also definitely NOT affected.  To 
determine if your installation is affected, run the following command as 
root:

camcontrol tags da0

Substitute 'da0' with another appropriate drive device number, if
needed.  Note that this ONLY AFFECTS 'da' DEVICES.  If your disks are
'ad' devices, they are NOT affected.

The result from running this command should be an output similar to the
following:

(pass0:mpt0:0:8:0): device openings: 255

If, instead, it reports a value of '1', you are likely affected.  Note
that it may be normal for USB memory devices to report a low number.
Also, many legacy SCSI disks, and devices that are not disks, may also 
be expected to report a low number.

The effect of this problem is that only one I/O command will be issued
to the controller and disk at a time, instead of overlapping multiple
commands in parallel.  This causes significantly higher latency in
servicing moderate and heavy I/O workloads, leading to very poor
performance.  Performance can be easily compared by downgrading to
FreeBSD 7.0.

I have committed a fix for this problem for FreeBSD 8-CURRENT as of SVN
revision 188570. FreeBSD 7-STABLE will be updated with the fix in a few
days once I've gotten confirmation that the fix works and doesn't cause
any adverse side-effects.  Anyone wanting to help in this validation
effort should apply the attached patch to their kernel source tree and
recompile.  Please contact me directly by email to report if the problem
is fixed for you.

If the validation process goes smoothly, I will work with the release
engineering team to turn this fix into an official errata update for
FreeBSD 7.1.

Thanks in advance for your help.

Scott



-------------- next part --------------
A non-text attachment was scrubbed...
Name: cam_tags.diff
Type: text/x-diff
Size: 429 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20090213/ae382247/cam_tags.bin
From pyunyh at gmail.com  Fri Feb 13 03:37:03 2009
From: pyunyh at gmail.com (Pyun YongHyeon)
Date: Fri Feb 13 03:37:10 2009
Subject: fun with if_re
In-Reply-To: <20090213114143.a77f1acb.gerrit@pmp.uni-hannover.de>
References: <20090204100507.5f223d9e.gerrit@pmp.uni-hannover.de>
	<20090204104655.GA73543@michelle.cdnetworks.co.kr>
	<20090205085812.b2deb1f7.gerrit@pmp.uni-hannover.de>
	<20090205082804.GD77461@michelle.cdnetworks.co.kr>
	<20090213101910.a126c14d.gerrit@pmp.uni-hannover.de>
	<20090213102400.GD12653@michelle.cdnetworks.co.kr>
	<20090213114143.a77f1acb.gerrit@pmp.uni-hannover.de>
Message-ID: <20090213113955.GE12653@michelle.cdnetworks.co.kr>

On Fri, Feb 13, 2009 at 11:41:43AM +0100, Gerrit K?hn wrote:
> On Fri, 13 Feb 2009 19:24:00 +0900 Pyun YongHyeon <pyunyh@gmail.com> wrote
> about Re: fun with if_re:
> 
> PY> > I had to reboot some of the machines meanwhile and could do some
> PY> > further testing. One strange thing I noticed is that the
> PY> > re-interfaces often do not come up in a working state after
> PY> > rebooting. Strangely, I see network traffic floating around via
> PY> > tcpdump, but not even ping works. This state often goes away when
> PY> > playing around with the interface (sometimes ifconfig down/up helps,
> PY> > sometimes disabling some of the additional features like txc/rxc),
> PY> > but I cannot make out a reproducible behaviour so far. When the
> PY> > interface leaves this strange state it seems to work fine
> PY> > afterwards. Any clues?
> 
> PY> Does this happen on latest if_re.c/if_rlreg.h? I guess jkim fixed
> PY> this type of problem in r187483. If that have no effect please let
> PY> me know.
> 
> It happens on both versions: the old one from 11th Dec 08 I still had, and
> the new one I built with the patches you recommended about a week ago.
> if_re is 1.151 2009/01/20 20:22:28 jkim, if_rlreg is 1.94 2009/01/20
> 20:22:28 jkim for the latter.
> 

Ok, try attached patch.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: re.8169sc.diff
Type: text/x-diff
Size: 2034 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20090213/b0b9f19a/re.8169sc.bin
From petefrench at ticketswitch.com  Fri Feb 13 03:42:27 2009
From: petefrench at ticketswitch.com (Pete French)
Date: Fri Feb 13 03:42:35 2009
Subject: Upgrade from 32-bit to AMD-64?
In-Reply-To: <A737B409-0578-4A8A-9DAB-20CD4122A8DE@mac.com>
Message-ID: <E1LXwR4-000Fn6-5I@dilbert.ticketswitch.com>

> Sure, it's possible, given sufficient toolchain knowledge, time, and  
> skills, but it's not a sensible thing to do aside from experimentation  
> and learning purposes.

Theres an intermediate method between upgrading in place and doing
a full re-install which si what I used when I did this.

1) Install amd64 onto a completely separate bootable drive (USB will
do). On that one do a 'make buildworld', 'make buildkernel'.

2) Take down the machine you mant to upgrade - boot it off the USB
drive. When booted off the USb drive mount the orignal '/' somewhere.

3) Do a 'make installkernel' and 'make installworld' with DESTDIR=/oldslah
to install the 64 bit OS onto the old drive. I also rewrote the boot
sectors on the old slash drive too.

4) Reboot - it should come up amd64 with the old config fine.

I have done this a couple of time to convert from 32 to 64 bit
installs. The beauty is that it preserves the config. I would note,
however, that in my case I did de-install all the packages and re-installed
them afterwards, so I was then running full 64 bit.

but it works, and the machine is only down for a few minutes.

-pete.
From gerrit at pmp.uni-hannover.de  Fri Feb 13 05:13:00 2009
From: gerrit at pmp.uni-hannover.de (Gerrit =?ISO-8859-1?Q?K=FChn?=)
Date: Fri Feb 13 05:13:08 2009
Subject: fun with if_re
In-Reply-To: <20090213113955.GE12653@michelle.cdnetworks.co.kr>
References: <20090204100507.5f223d9e.gerrit@pmp.uni-hannover.de>
	<20090204104655.GA73543@michelle.cdnetworks.co.kr>
	<20090205085812.b2deb1f7.gerrit@pmp.uni-hannover.de>
	<20090205082804.GD77461@michelle.cdnetworks.co.kr>
	<20090213101910.a126c14d.gerrit@pmp.uni-hannover.de>
	<20090213102400.GD12653@michelle.cdnetworks.co.kr>
	<20090213114143.a77f1acb.gerrit@pmp.uni-hannover.de>
	<20090213113955.GE12653@michelle.cdnetworks.co.kr>
Message-ID: <20090213141256.b06aa86b.gerrit@pmp.uni-hannover.de>

On Fri, 13 Feb 2009 20:39:55 +0900 Pyun YongHyeon <pyunyh@gmail.com> wrote
about Re: fun with if_re:


PY> Ok, try attached patch.

Thanks, building new images right now. I'll be back later (next week).


cu
  Gerrit
From tevans.uk at googlemail.com  Fri Feb 13 05:21:21 2009
From: tevans.uk at googlemail.com (Tom Evans)
Date: Fri Feb 13 05:21:30 2009
Subject: HEADS UP: Major CAM performance regression
In-Reply-To: <499551B9.7050805@samsco.org>
References: <499551B9.7050805@samsco.org>
Message-ID: <1234531085.2998.42.camel@localhost>

On Fri, 2009-02-13 at 03:55 -0700, Scott Long wrote:
> All,
> 
> A major performance regression was introduced to the CAM subsystem in
> FreeBSD 7.1.  The following configurations are known to be affected:
> 
> VMWare ESX
> VMWare Fusion
>      (using bt or lsilogic controller options)
> HP CISS RAID
> Some MPT-SAS combinations with SATA drives attached
>      (Includes Dell SAS5/ir, but not PERC5/PERC6).
> 
> Pure SCSI and SAS subsystems likely are NOT affected.  Any hardware
> that uses the 'ata' driver is also definitely NOT affected.  To 
> determine if your installation is affected, run the following command as 
> root:
> 
> camcontrol tags da0
> 
> Substitute 'da0' with another appropriate drive device number, if
> needed.  Note that this ONLY AFFECTS 'da' DEVICES.  If your disks are
> 'ad' devices, they are NOT affected.
> 
> The result from running this command should be an output similar to the
> following:
> 
> (pass0:mpt0:0:8:0): device openings: 255
> 
> If, instead, it reports a value of '1', you are likely affected.  Note
> that it may be normal for USB memory devices to report a low number.
> Also, many legacy SCSI disks, and devices that are not disks, may also 
> be expected to report a low number.
> 
> The effect of this problem is that only one I/O command will be issued
> to the controller and disk at a time, instead of overlapping multiple
> commands in parallel.  This causes significantly higher latency in
> servicing moderate and heavy I/O workloads, leading to very poor
> performance.  Performance can be easily compared by downgrading to
> FreeBSD 7.0.
> 
> I have committed a fix for this problem for FreeBSD 8-CURRENT as of SVN
> revision 188570. FreeBSD 7-STABLE will be updated with the fix in a few
> days once I've gotten confirmation that the fix works and doesn't cause
> any adverse side-effects.  Anyone wanting to help in this validation
> effort should apply the attached patch to their kernel source tree and
> recompile.  Please contact me directly by email to report if the problem
> is fixed for you.
> 
> If the validation process goes smoothly, I will work with the release
> engineering team to turn this fix into an official errata update for
> FreeBSD 7.1.
> 
> Thanks in advance for your help.
> 
> Scott
> 

Hi Scott

I have one da0 device, a USB attached hard disk:

umass0: <LaCie LaCie Hard Drive USB, class 0/0, rev 2.00/0.00, addr 2>
on uhub6
da0 at umass-sim0 bus 0 target 0 lun 0
da0: <SAMSUNG SP2514N VF10> Fixed Direct Access SCSI-2 device 
da0: 40.000MB/s transfers
da0: 238475MB (488397168 512 byte sectors: 255H 63S/T 30401C)


camcontrol shows:

> $ sudo camcontrol tags da0
(pass0:umass-sim0:0:0:0): device openings: 1

Is that to be expected? This is RELENG_7 from October '08:

FreeBSD strangepork.mintel.co.uk 7.1-PRERELEASE FreeBSD 7.1-PRERELEASE
#0: Wed Oct 22 02:25:56 BST 2008
root@sweetpork.pc.mintel.co.uk:/usr/FreeBSD/RELENG_7/obj/usr/FreeBSD/RELENG_7/src/sys/STRANGEPORK  i386

Thanks

Tom

From ghelmer at palisadesys.com  Fri Feb 13 05:26:33 2009
From: ghelmer at palisadesys.com (Guy Helmer)
Date: Fri Feb 13 05:26:41 2009
Subject: Big problems with 7.1 locking up :-(
In-Reply-To: <49946769.1040009@palisadesys.com>
References: <E1LL6dg-0007CN-DI@dilbert.ticketswitch.com>	<49676406.9050902@palisadesys.com>
	<49946769.1040009@palisadesys.com>
Message-ID: <49957505.7090405@palisadesys.com>

Guy Helmer wrote:
> FWIW, I think I have tracked down the changes just prior to 
> 7.1-RELEASE that is causing my Supermicro dual Xeon machines to 
> wedge.  I did the binary search between 2008-10-02 and 2008-11-24 
> without reproducing any lockups, and then I went on to search between 
> 2008-11-24 and 2009-01-04.  An SMP kernel build from 2008-12-22 
> (r186409) sources was stable for over two weeks; a kernel built from 
> 2008-12-29 (r186590) sources wedged in under 24 hours under moderate 
> load.
>
> It appears that the significant changes between r186409 and r186590 
> were r186552 (delphij - reverted ATA changes) and r186535/r186534 
> (delphij - reverted bce changes).  My machines don't have bce 
> interfaces, so I suspect the ATA changes.
>
Never mind.  I'm stepping back through older kernels and finding that 
the hangs are now occurring in kernels that had seemed to be stable...

Guy

From patfbsd at davenulle.org  Fri Feb 13 06:43:36 2009
From: patfbsd at davenulle.org (Patrick =?ISO-8859-15?Q?Lamaizi=E8re?=)
Date: Fri Feb 13 06:43:49 2009
Subject: Backport of glxsb(4) to RELENG_6
In-Reply-To: <20090212213443.GM30761@e.0x20.net>
References: <20090210134421.350f40b8@baby-jane.lamaiziere.net>
	<20090212213443.GM30761@e.0x20.net>
Message-ID: <20090213154333.18f0bf13@baby-jane.lamaiziere.net>

Le Thu, 12 Feb 2009 22:34:43 +0100,
Lars Engels <lme@FreeBSD.org>:

Hi,

> I just tried it, but I get this message: 
> glxsb0: <AMD Geode LX Security Block (AES-128-CBC, RNG)> mem
> 0xefff4000-0xefff7fff irq 9 at device 1.2 on pci0 

> glxsb0: cannot allocate DMA memory of 32768 bytes (12)

I think you are very low on memory and the driver cannot allocate his
DMA-able buffer (error 12=ENOMEM)

This is not really a bug. But i've found another problem related to the
taskqueue. 

I'm doing a fake driver to be able to test on a vmware machine.
From jhb at freebsd.org  Fri Feb 13 07:40:11 2009
From: jhb at freebsd.org (John Baldwin)
Date: Fri Feb 13 07:40:34 2009
Subject: 7.1 Panic on degraded disk w/mpt
In-Reply-To: <alpine.OSX.2.00.0902090102060.37588@toasty.nat.fasttrackmonkey.com>
References: <alpine.OSX.2.00.0902090102060.37588@toasty.nat.fasttrackmonkey.com>
Message-ID: <200902131018.37940.jhb@freebsd.org>

On Monday 09 February 2009 1:13:08 am Charles Sprickman wrote:
> Howdy,
> 
> I dug around and can't find a PR on this, and the only other report I saw 
> was in this mailing list post that has no replies:
> 
> http://www.nabble.com/7.1-BETA2-panic-on-mpt-degrade-td20183173.html
> 
> The hardware is a Dell PowerEdge 860 with the Dell/LSI SAS5 controller:
> mpt0: <LSILogic SAS/SATA Adapter> port 0xec00-0xecff mem 
> 0xfe9fc000-0xfe9fffff,0xfe9e0000-0xfe9effff irq 16 at device 8.0 on pci2
> mpt0: MPI Version=1.5.13.0
> 
> The panic is repeatable by forcing the array into a degraded state.
> 
> Here's my best shot at getting info out of kgdb:
> 
> [root@uniweb /home/spork]# cd /usr/obj/usr/src/sys/BWAY7/
> [root@uniweb /usr/obj/usr/src/sys/BWAY7]# 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:
> 
> 
> Fatal trap 12: page fault while in kernel mode
> cpuid = 0; apic id = 00
> fault virtual address   = 0x14
> fault code              = supervisor read, page not present
> instruction pointer     = 0x20:0xc044b09b
> stack pointer           = 0x28:0xe6ee5b80
> frame pointer           = 0x28:0xe6ee5b9c
> 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         = 17 (swi2: cambio)
> trap number             = 12
> panic: page fault
> cpuid = 0
> Uptime: 3m7s
> Physical memory: 3575 MB
> Dumping 94 MB: 79 63 47 31 15
> 
> 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) list *0xc044b09b
> 0xc044b09b is in xpt_done (/usr/src/sys/cam/cam_xpt.c:4832).
> 4827            if ((done_ccb->ccb_h.func_code & XPT_FC_QUEUED) != 0) {
> 4828                    /*
> 4829                     * Queue up the request for handling by our SWI 
handler
> 4830                     * any of the "non-immediate" type of ccbs.
> 4831                     */
> 4832                    sim = done_ccb->ccb_h.path->bus->sim;
> 4833                    switch (done_ccb->ccb_h.path->periph->type) {
> 4834                    case CAM_PERIPH_BIO:
> 4835                            TAILQ_INSERT_TAIL(&sim->sim_doneq, 
&done_ccb->ccb_h,
> 4836                                              sim_links.tqe);

Can you 'p done_ccb->ccb_h.path' and if that is not 0, 'p 
done_ccb->ccb_h.path.bus'?

-- 
John Baldwin
From ross.penner at gmail.com  Fri Feb 13 09:48:56 2009
From: ross.penner at gmail.com (Ross Penner)
Date: Fri Feb 13 09:49:03 2009
Subject: pkg_delete segfaulting after upgrading to 7.1
In-Reply-To: <53a1e0710902122229l606bb2c9pcc71ea38fafa1193@mail.gmail.com>
References: <53a1e0710902122229l606bb2c9pcc71ea38fafa1193@mail.gmail.com>
Message-ID: <f80199c40902130948m77da2a44x9c72355884ba83be@mail.gmail.com>

On Thu, Feb 12, 2009 at 10:29 PM, Henry Hu <henry.hu.sh@gmail.com> wrote:
>> rosbox# pkg_delete -f gpgme-1.1.5_1
>> pkg_delete: package 'gpgme-1.1.5_1' is required by these other packages
>> and may not be deinstalled (but I'll delete it anyway):
>> seahorse-2.24.1_1
>> Segmentation fault (core dumped)
>
> I've had similar problem, and found the problem is in the +CONTENTS in
> the corresponding folder under /var/db/pkg/ .
> It's caused by an empty @pkgdep line here.
> I don't know what went wrong when the +CONTENTS file was created. But
> delete all these empty @pkgdep lines solved my problem.
>
> Cheers,
> Henry

Worked for me too! Thanks a lot, I never would have thought to have tried that.
From patfbsd at davenulle.org  Fri Feb 13 12:05:24 2009
From: patfbsd at davenulle.org (Patrick =?ISO-8859-15?Q?Lamaizi=E8re?=)
Date: Fri Feb 13 12:05:32 2009
Subject: Backport of glxsb(4) to RELENG_6
In-Reply-To: <20090213154333.18f0bf13@baby-jane.lamaiziere.net>
References: <20090210134421.350f40b8@baby-jane.lamaiziere.net>
	<20090212213443.GM30761@e.0x20.net>
	<20090213154333.18f0bf13@baby-jane.lamaiziere.net>
Message-ID: <20090213210516.3667403a@baby-jane.lamaiziere.net>

Le Fri, 13 Feb 2009 15:43:33 +0100,
Patrick Lamaizi?re <patfbsd@davenulle.org>:

> Le Thu, 12 Feb 2009 22:34:43 +0100,
> Lars Engels <lme@FreeBSD.org>:
> 
> Hi,
> 
> > I just tried it, but I get this message: 
> > glxsb0: <AMD Geode LX Security Block (AES-128-CBC, RNG)> mem
> > 0xefff4000-0xefff7fff irq 9 at device 1.2 on pci0 
> 
> > glxsb0: cannot allocate DMA memory of 32768 bytes (12)
> 
> I think you are very low on memory and the driver cannot allocate his
> DMA-able buffer (error 12=ENOMEM)
> 
> This is not really a bug. 

To Lars: Yes it should work at bootime. You must also load the module
cryptodev.ko to use it with openssl.

> But i've found another problem related to
> the taskqueue. 
> 
> I'm doing a fake driver to be able to test on a vmware machine.

I've tested most of the driver and I think (hope) this is ok.

http://user.lamaiziere.net/patrick/glxsb-6-130209.tar.gz

Let me know how it works.

Regards.
From patfbsd at davenulle.org  Fri Feb 13 12:33:00 2009
From: patfbsd at davenulle.org (Patrick =?ISO-8859-15?Q?Lamaizi=E8re?=)
Date: Fri Feb 13 12:33:06 2009
Subject: FreeBSD CVS problem ?
Message-ID: <20090213213257.52a11130@baby-jane.lamaiziere.net>

Hi,

I've just found that the files for glxsb(4) in RELENG_7 are older than
in RELENG_7_1. I don't think this is normal?

http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/glxsb/glxsb.c?only_with_tag=RELENG_7

http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/glxsb/glxsb.c?only_with_tag=RELENG_7_1

RELENG_7_1 contains changes made by philip@ in SVN rev 185021

RELENG_7 contains an older version SVN rev 181919 on 2008-08-20
11:33:13Z by philip

If you know how solve this, thanks.
Regards.
From scottl at samsco.org  Fri Feb 13 12:43:29 2009
From: scottl at samsco.org (Scott Long)
Date: Fri Feb 13 12:43:37 2009
Subject: HEADS UP: Major CAM performance regression
In-Reply-To: <1234531085.2998.42.camel@localhost>
References: <499551B9.7050805@samsco.org> <1234531085.2998.42.camel@localhost>
Message-ID: <4995DB65.5020200@samsco.org>

Tom Evans wrote:
> On Fri, 2009-02-13 at 03:55 -0700, Scott Long wrote:
>> All,
>>
>> A major performance regression was introduced to the CAM subsystem in
>> FreeBSD 7.1.  The following configurations are known to be affected:
>>
>> VMWare ESX
>> VMWare Fusion
>>      (using bt or lsilogic controller options)
>> HP CISS RAID
>> Some MPT-SAS combinations with SATA drives attached
>>      (Includes Dell SAS5/ir, but not PERC5/PERC6).
>>
>> Pure SCSI and SAS subsystems likely are NOT affected.  Any hardware
>> that uses the 'ata' driver is also definitely NOT affected.  To 
>> determine if your installation is affected, run the following command as 
>> root:
>>
>> camcontrol tags da0
>>
>> Substitute 'da0' with another appropriate drive device number, if
>> needed.  Note that this ONLY AFFECTS 'da' DEVICES.  If your disks are
>> 'ad' devices, they are NOT affected.
>>
>> The result from running this command should be an output similar to the
>> following:
>>
>> (pass0:mpt0:0:8:0): device openings: 255
>>
>> If, instead, it reports a value of '1', you are likely affected.  Note
>> that it may be normal for USB memory devices to report a low number.
>> Also, many legacy SCSI disks, and devices that are not disks, may also 
>> be expected to report a low number.
>>
>> The effect of this problem is that only one I/O command will be issued
>> to the controller and disk at a time, instead of overlapping multiple
>> commands in parallel.  This causes significantly higher latency in
>> servicing moderate and heavy I/O workloads, leading to very poor
>> performance.  Performance can be easily compared by downgrading to
>> FreeBSD 7.0.
>>
>> I have committed a fix for this problem for FreeBSD 8-CURRENT as of SVN
>> revision 188570. FreeBSD 7-STABLE will be updated with the fix in a few
>> days once I've gotten confirmation that the fix works and doesn't cause
>> any adverse side-effects.  Anyone wanting to help in this validation
>> effort should apply the attached patch to their kernel source tree and
>> recompile.  Please contact me directly by email to report if the problem
>> is fixed for you.
>>
>> If the validation process goes smoothly, I will work with the release
>> engineering team to turn this fix into an official errata update for
>> FreeBSD 7.1.
>>
>> Thanks in advance for your help.
>>
>> Scott
>>
> 
> Hi Scott
> 
> I have one da0 device, a USB attached hard disk:
> 
> umass0: <LaCie LaCie Hard Drive USB, class 0/0, rev 2.00/0.00, addr 2>
> on uhub6
> da0 at umass-sim0 bus 0 target 0 lun 0
> da0: <SAMSUNG SP2514N VF10> Fixed Direct Access SCSI-2 device 
> da0: 40.000MB/s transfers
> da0: 238475MB (488397168 512 byte sectors: 255H 63S/T 30401C)
> 
> 
> camcontrol shows:
> 
>> $ sudo camcontrol tags da0
> (pass0:umass-sim0:0:0:0): device openings: 1
> 
> Is that to be expected? This is RELENG_7 from October '08:
> 

The date falls within the range.  Have you tried the patch to see if it 
changes anything?

Scott
From scottl at samsco.org  Fri Feb 13 13:02:50 2009
From: scottl at samsco.org (Scott Long)
Date: Fri Feb 13 13:02:57 2009
Subject: HEADS UP: Major CAM performance regression
In-Reply-To: <gn3ssi$j1r$1@ger.gmane.org>
References: <499551B9.7050805@samsco.org> <gn3ssi$j1r$1@ger.gmane.org>
Message-ID: <4995DFE5.1020205@samsco.org>

Ivan Voras wrote:
> Scott Long wrote:
> 
>> I have committed a fix for this problem for FreeBSD 8-CURRENT as of SVN
>> revision 188570. FreeBSD 7-STABLE will be updated with the fix in a few
>> days once I've gotten confirmation that the fix works and doesn't cause
>> any adverse side-effects.  Anyone wanting to help in this validation
>> effort should apply the attached patch to their kernel source tree and
>> recompile.  Please contact me directly by email to report if the problem
>> is fixed for you.
> 
> I notice that write performance on an ESXi 3.5 hosted system is doubled,
> but read performance remains the same (in bonnie++).
> On a CISS system there is no significant change.
> 

bonnie is an unreliable tool for measuring performance.

Scott

From delphij at delphij.net  Fri Feb 13 14:20:29 2009
From: delphij at delphij.net (Xin LI)
Date: Fri Feb 13 14:20:36 2009
Subject: FreeBSD CVS problem ?
In-Reply-To: <20090213213257.52a11130@baby-jane.lamaiziere.net>
References: <20090213213257.52a11130@baby-jane.lamaiziere.net>
Message-ID: <4995F221.7040801@delphij.net>

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

Patrick Lamaizi?re wrote:
> Hi,
> 
> I've just found that the files for glxsb(4) in RELENG_7 are older than
> in RELENG_7_1. I don't think this is normal?
> 
> http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/glxsb/glxsb.c?only_with_tag=RELENG_7
> 
> http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/glxsb/glxsb.c?only_with_tag=RELENG_7_1
> 
> RELENG_7_1 contains changes made by philip@ in SVN rev 185021
> 
> RELENG_7 contains an older version SVN rev 181919 on 2008-08-20
> 11:33:13Z by philip
> 
> If you know how solve this, thanks.
> Regards.

"older" is just meaningful on the same branch...  This is normal.

Cheers,
- --
Xin LI <delphij@delphij.net>	http://www.delphij.net/
FreeBSD - The Power to Serve!
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.10 (FreeBSD)

iEYEARECAAYFAkmV8iAACgkQi+vbBBjt66CDeACgrUSl37l5lBLqbJUFXvCD08nl
aNkAoKcuzVLNcZWxwfVXuAjktN2gIee/
=wCfl
-----END PGP SIGNATURE-----
From ivoras at freebsd.org  Fri Feb 13 14:48:02 2009
From: ivoras at freebsd.org (Ivan Voras)
Date: Fri Feb 13 14:48:08 2009
Subject: HEADS UP: Major CAM performance regression
In-Reply-To: <4995DFE5.1020205@samsco.org>
References: <499551B9.7050805@samsco.org> <gn3ssi$j1r$1@ger.gmane.org>
	<4995DFE5.1020205@samsco.org>
Message-ID: <9bbcef730902131421r53efa13dq371658888747f387@mail.gmail.com>

2009/2/13 Scott Long <scottl@samsco.org>:
> Ivan Voras wrote:
>>
>> Scott Long wrote:
>>
>>> I have committed a fix for this problem for FreeBSD 8-CURRENT as of SVN
>>> revision 188570. FreeBSD 7-STABLE will be updated with the fix in a few
>>> days once I've gotten confirmation that the fix works and doesn't cause
>>> any adverse side-effects.  Anyone wanting to help in this validation
>>> effort should apply the attached patch to their kernel source tree and
>>> recompile.  Please contact me directly by email to report if the problem
>>> is fixed for you.
>>
>> I notice that write performance on an ESXi 3.5 hosted system is doubled,
>> but read performance remains the same (in bonnie++).
>> On a CISS system there is no significant change.
>
> bonnie is an unreliable tool for measuring performance.

I'll try your suggestion if you have one.

(except if it's about bonnie++ primarily measuring sequential
read/write - if a system can't do sequential IO well, it probably
won't do random IO well)
From rehsack at web.de  Sat Feb 14 05:33:28 2009
From: rehsack at web.de (Jens Rehsack)
Date: Sat Feb 14 05:33:36 2009
Subject: Error compiling FreeBSD-Stable with MFC'ed iconv locking
Message-ID: <4996C16D.8050909@web.de>

Hi John,

after I updated my system (-STABLE) I received following compilation error
while building the kernel (having ICONV built in):

cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -march=nocona
-std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes
-Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual  -Wundef
-Wno-pointer-sign -fformat-extensions -nostdinc  -I. -I/usr/src/sys
-I/usr/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include
opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100
--param large-function-growth=1000  -fno-omit-frame-pointer -mcmodel=kernel
-mno-red-zone  -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow
-msoft-float -fno-asynchronous-unwind-tables -ffreestanding -Werror
/usr/src/sys/libkern/iconv.c
/usr/src/sys/libkern/iconv.c: In function 'iconv_mod_unload':
/usr/src/sys/libkern/iconv.c:92: error: 'curthread' undeclared (first use in
this function)
/usr/src/sys/libkern/iconv.c:92: error: (Each undeclared identifier is
reported only once
/usr/src/sys/libkern/iconv.c:92: error: for each function it appears in.)
/usr/src/sys/libkern/iconv.c: In function 'iconv_sysctl_add':
/usr/src/sys/libkern/iconv.c:401: error: 'curthread' undeclared (first use
in this function)
/usr/src/sys/libkern/iconv.c: In function 'iconv_converter_handler':
/usr/src/sys/libkern/iconv.c:452: error: 'curthread' undeclared (first use
in this function)

I applied following patch - and it works:
--- sys/sys/sx.h.orig	2009-02-14 12:56:11.000000000 +0000
+++ sys/sys/sx.h	2009-02-14 12:57:33.000000000 +0000
@@ -35,6 +35,7 @@
 #include <sys/_lock.h>
 #include <sys/_sx.h>
 #include <sys/lock_profile.h>
+#include <sys/proc.h>

 #ifdef	_KERNEL
 #include <machine/atomic.h>

Google didn't find anything so I thought I mail this quickly.

Best regards,
Jens

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 897 bytes
Desc: OpenPGP digital signature
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20090214/e2295dd7/signature.pgp
From scottl at samsco.org  Sat Feb 14 06:33:30 2009
From: scottl at samsco.org (Scott Long)
Date: Sat Feb 14 06:33:37 2009
Subject: HEADS UP: Major CAM performance regression
In-Reply-To: <9bbcef730902131421r53efa13dq371658888747f387@mail.gmail.com>
References: <499551B9.7050805@samsco.org> <gn3ssi$j1r$1@ger.gmane.org>	
	<4995DFE5.1020205@samsco.org>
	<9bbcef730902131421r53efa13dq371658888747f387@mail.gmail.com>
Message-ID: <4996D635.3000802@samsco.org>

Ivan Voras wrote:
> 2009/2/13 Scott Long <scottl@samsco.org>:
>> Ivan Voras wrote:
>>> Scott Long wrote:
>>>
>>>> I have committed a fix for this problem for FreeBSD 8-CURRENT as of SVN
>>>> revision 188570. FreeBSD 7-STABLE will be updated with the fix in a few
>>>> days once I've gotten confirmation that the fix works and doesn't cause
>>>> any adverse side-effects.  Anyone wanting to help in this validation
>>>> effort should apply the attached patch to their kernel source tree and
>>>> recompile.  Please contact me directly by email to report if the problem
>>>> is fixed for you.
>>> I notice that write performance on an ESXi 3.5 hosted system is doubled,
>>> but read performance remains the same (in bonnie++).
>>> On a CISS system there is no significant change.
>> bonnie is an unreliable tool for measuring performance.
> 
> I'll try your suggestion if you have one.

I don't have a magic universal testing suite in my back pocket, sorry.
You need to look at your expected workload and develop tests to simulate
it.  When I do testing during driver development, I try a lot of
different parallel, sequential, large i/o, and small i/o combinations.

> 
> (except if it's about bonnie++ primarily measuring sequential
> read/write - if a system can't do sequential IO well, it probably
> won't do random IO well)

This is completely false.  Disks can't do sequential i/o very well due
to the physical limits of long seek times, but those seek times can be
greatly amortized, even in a random workload, with tagged queueing and
parallel dispatch from the OS.  Bonnie simply cannot exercise this very
well.

Bonnie tests system latency for discrete I/O's.  That is all it tests.

Scott
From ivoras at freebsd.org  Sat Feb 14 07:44:51 2009
From: ivoras at freebsd.org (Ivan Voras)
Date: Sat Feb 14 07:44:58 2009
Subject: HEADS UP: Major CAM performance regression
In-Reply-To: <4996D635.3000802@samsco.org>
References: <499551B9.7050805@samsco.org> <gn3ssi$j1r$1@ger.gmane.org>
	<4995DFE5.1020205@samsco.org>
	<9bbcef730902131421r53efa13dq371658888747f387@mail.gmail.com>
	<4996D635.3000802@samsco.org>
Message-ID: <9bbcef730902140744i14c2a9e6i211a549eada7b057@mail.gmail.com>

2009/2/14 Scott Long <scottl@samsco.org>:

>> I'll try your suggestion if you have one.
>
> I don't have a magic universal testing suite in my back pocket, sorry.
> You need to look at your expected workload and develop tests to simulate
> it.  When I do testing during driver development, I try a lot of
> different parallel, sequential, large i/o, and small i/o combinations.

Of course you're right about testing for specific workloads -  I just
thought you needed data points "from the field" if the patch is
helping or not.

>> (except if it's about bonnie++ primarily measuring sequential
>> read/write - if a system can't do sequential IO well, it probably
>> won't do random IO well)
>
> This is completely false.  Disks can't do sequential i/o very well due
> to the physical limits of long seek times, but those seek times can be

I don't follow this - where are the long seek times in sequential IO?

> greatly amortized, even in a random workload, with tagged queueing and
> parallel dispatch from the OS.  Bonnie simply cannot exercise this very
> well.
>
> Bonnie tests system latency for discrete I/O's.  That is all it tests.

Doesn't tagged queuing serve, among other things, to decrease overall
latency for IOs? Since AFAIK UFS queues multiple IO requests in both
directions (read-ahead and write-behind), shouldn't the benefits of
the patch - liberating the tags - be visible even with sequential IO?

I have the systems on which I tested for a few more days, if you need
the data I can run some other tests (randomio?).
From svein-listmail at stillbilde.net  Sat Feb 14 09:31:38 2009
From: svein-listmail at stillbilde.net (Svein Skogen (listmail account))
Date: Sat Feb 14 09:31:45 2009
Subject: HEADS UP: Major CAM performance regression
In-Reply-To: <499551B9.7050805@samsco.org>
References: <499551B9.7050805@samsco.org>
Message-ID: <4996FBF3.3040801@stillbilde.net>

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

Scott Long wrote:
> All,
> 
> A major performance regression was introduced to the CAM subsystem in
> FreeBSD 7.1.  The following configurations are known to be affected:
> 
> VMWare ESX
> VMWare Fusion
>     (using bt or lsilogic controller options)
> HP CISS RAID
> Some MPT-SAS combinations with SATA drives attached
>     (Includes Dell SAS5/ir, but not PERC5/PERC6).
> 
> Pure SCSI and SAS subsystems likely are NOT affected.  Any hardware
> that uses the 'ata' driver is also definitely NOT affected.  To
> determine if your installation is affected, run the following command as
> root:
> 
> camcontrol tags da0
> 
> Substitute 'da0' with another appropriate drive device number, if
> needed.  Note that this ONLY AFFECTS 'da' DEVICES.  If your disks are
> 'ad' devices, they are NOT affected.
> 
> The result from running this command should be an output similar to the
> following:
> 
> (pass0:mpt0:0:8:0): device openings: 255
> 
> If, instead, it reports a value of '1', you are likely affected.  Note
> that it may be normal for USB memory devices to report a low number.
> Also, many legacy SCSI disks, and devices that are not disks, may also
> be expected to report a low number.
> 
> The effect of this problem is that only one I/O command will be issued
> to the controller and disk at a time, instead of overlapping multiple
> commands in parallel.  This causes significantly higher latency in
> servicing moderate and heavy I/O workloads, leading to very poor
> performance.  Performance can be easily compared by downgrading to
> FreeBSD 7.0.

Any estimate on when this will be MFC'ed down to RELENG_7 yet?

//Svein

- --
- --------+-------------------+-------------------------------
  /"\   |Svein Skogen       | svein@d80.iso100.no
  \ /   |Solberg ?stli 9    | PGP Key:  0xE5E76831
   X    |2020 Skedsmokorset | svein@jernhuset.no
  / \   |Norway             | PGP Key:  0xCE96CE13
        |                   | svein@stillbilde.net
 ascii  |                   | PGP Key:  0x58CD33B6
 ribbon |System Admin       | svein-listmail@stillbilde.net
Campaign|stillbilde.net     | PGP Key:  0x22D494A4
        +-------------------+-------------------------------
        |msn messenger:     | Mobile Phone: +47 907 03 575
        |svein@jernhuset.no | RIPE handle:    SS16503-RIPE
- --------+-------------------+-------------------------------
  Picture Gallery: https://gallery.stillbilde.net/v/svein/
- ------------------------------------------------------------
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkmW+/IACgkQODUnwSLUlKTVuACgpk70v7d6hyBmvIdaFhLsDA01
nqIAoJkljSXU+TRb7tl9xM8EEerFeMGz
=0mNQ
-----END PGP SIGNATURE-----
From goran.lowkrantz at ismobile.com  Sat Feb 14 13:54:09 2009
From: goran.lowkrantz at ismobile.com (Goran Lowkrantz)
Date: Sat Feb 14 13:54:17 2009
Subject: Problems with samba and vista on 7.1-STABLE
Message-ID: <6142197C185AA728E9D4345C@[10.255.253.2]>

I have few Samba servers running FreeBSD 7.1 were we have a problem with 
connection blocking from a few Vista systems that run programs that watch 
directories and files on the samba shares.

On my test setup I have managed to get a hang in about 30 min.

Samba is built with minimum functions and full debug. Options don't seems 
to have any impact on the problem.

The PC uses Vista Business SP1 and all patches, I run a DAM program called 
IMatch that watches for changes in the photo database.

The FreeBSD server is an up-to-date quad AMD server with 8GB running 
7.1-STABLE. In normal operation, I see the following:

# sockstat | grep 445
glz      smbd       7828  23 tcp4   10.255.253.1:445      10.255.253.2:57355
root     smbd       76917 19 tcp4   127.0.0.1:445         *:*
root     smbd       76917 20 tcp4   10.255.253.1:445      *:*

When I get the hang, it looks like this:
# sockstat | grep 445
root     smbd       7828  23 tcp4   10.255.253.1:445      10.255.253.2:57355
root     smbd       76917 19 tcp4   127.0.0.1:445         *:*
root     smbd       76917 20 tcp4   10.255.253.1:445      *:*

and the GDB session:
# gdb /usr/local/sbin/smbd 7828
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"...
Attaching to program: /usr/local/sbin/smbd, process 7828
Reading symbols from /usr/local/lib/libldap-2.3.so.2...done.
Loaded symbols for /usr/local/lib/libldap-2.3.so.2
Reading symbols from /usr/local/lib/liblber-2.3.so.2...done.
Loaded symbols for /usr/local/lib/liblber-2.3.so.2
Reading symbols from /usr/local/lib/libcups.so.2...done.
Loaded symbols for /usr/local/lib/libcups.so.2
Reading symbols from /usr/lib/libssl.so.5...done.
Loaded symbols for /usr/lib/libssl.so.5
Reading symbols from /lib/libcrypto.so.5...done.
Loaded symbols for /lib/libcrypto.so.5
Reading symbols from /lib/libz.so.4...done.
Loaded symbols for /lib/libz.so.4
Reading symbols from /lib/libm.so.5...done.
Loaded symbols for /lib/libm.so.5
Reading symbols from /lib/libcrypt.so.4...done.
Loaded symbols for /lib/libcrypt.so.4
Reading symbols from /usr/lib/libpam.so.4...done.
Loaded symbols for /usr/lib/libpam.so.4
Reading symbols from /usr/local/lib/libexecinfo.so.1...done.
Loaded symbols for /usr/local/lib/libexecinfo.so.1
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/libdmalloc.so.1...done.
Loaded symbols for /usr/local/lib/libdmalloc.so.1
Reading symbols from /usr/local/lib/libpopt.so.0...done.
Loaded symbols for /usr/local/lib/libpopt.so.0
Reading symbols from /lib/libthr.so.3...done.
[New Thread 0x800a62e00 (LWP 100076)]
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 /usr/local/lib/libsasl2.so.2...done.
Loaded symbols for /usr/local/lib/libsasl2.so.2
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/nss_ldap.so.1...done.
Loaded symbols for /usr/local/lib/nss_ldap.so.1
Reading symbols from /usr/lib/libcom_err.so.4...done.
Loaded symbols for /usr/lib/libcom_err.so.4
Reading symbols from /libexec/ld-elf.so.1...done.
Loaded symbols for /libexec/ld-elf.so.1
[Switching to Thread 0x800a62e00 (LWP 100076)]
0x0000000801f01d6c in select () from /lib/libc.so.7
(gdb) directory /usr/ports/net/samba32-devel/work/samba-3.2.7/source/
Source directories searched: 
/usr/ports/net/samba32-devel/work/samba-3.2.7/source:$cdir:$cwd
(gdb) bt
#0  0x0000000801f01d6c in select () from /lib/libc.so.7
#1  0x0000000801d0f4d4 in select () from /lib/libthr.so.3
#2  0x00000000006749fe in sys_select (maxfd=24, readfds=0x7fffffffd420, 
writefds=0x7fffffffd3a0, errorfds=0x0, tval=0x7fffffffd500)
    at lib/select.c:93
#3  0x00000000004df64c in smbd_process () at smbd/process.c:839
#4  0x0000000000854074 in main (argc=2, argv=0x7fffffffd638) at 
smbd/server.c:1450
(gdb) frame 2
#2  0x00000000006749fe in sys_select (maxfd=24, readfds=0x7fffffffd420, 
writefds=0x7fffffffd3a0, errorfds=0x0, tval=0x7fffffffd500)
    at lib/select.c:93
93              ret = select(maxfd,readfds2,writefds,errorfds,tval);
(gdb) print tval
$1 = (struct timeval *) 0x7fffffffd500
(gdb) print *tval
$2 = {tv_sec = 59, tv_usec = 999977}
(gdb) The program is running.  Quit anyway (and detach it)? (y or n) y
Detaching from program: /usr/local/sbin/smbd, process 7828

The following is a truss of the process until I have seen the switch to 
root as owner:
# time truss -p 8307
gettimeofday({1234648077.989004 },0x0)           = 0 (0x0)
gettimeofday({1234648077.989081 },0x0)           = 0 (0x0)
select(24,{6 23},{},0x0,{21.288167 })            = 0 (0x0)
gettimeofday({1234648099.279293 },0x0)           = 0 (0x0)
gettimeofday({1234648099.279370 },0x0)           = 0 (0x0)
gettimeofday({1234648099.279417 },0x0)           = 0 (0x0)
select(24,{6 23},{},0x0,{59.989982 })            = 1 (0x1)
gettimeofday({1234648102.286493 },0x0)           = 0 (0x0)
read(23,"\0\0\0r",4)                             = 4 (0x4)
read(23,"\M^?SMB2\0\0\0\0\^X\a\M-H\0\0\0"...,114) = 114 (0x72)
geteuid(0x3e8,0x3e8,0x2,0x800adf750,0x2,0x800adf750) = 0 (0x0)
getegid(0x3e8,0x3e8,0x2,0x801eadb8c,0xffffff006cf16a50,0x7fffffffd138) = 0 
(0x0)
__sysctl(0x7fffffffd0a0,0x2,0x7fffffffd0bc,0x7fffffffd0b0,0x0,0x0) = 0 (0x0)
0.000u 0.001s 2:36.56 0.0%    0+0k 0+0io 0pf+0w

# sockstat | grep 445
glz      smbd       8307  23 tcp4   10.255.253.1:445      10.255.253.2:57438
root     smbd       76917 19 tcp4   127.0.0.1:445         *:*
root     smbd       76917 20 tcp4   10.255.253.1:445      *:*
# ps -awxl | grep 8307
 1000  8307  8556   0  44  0 34672  7984 select IX    ??    0:04.57 
/usr/local/sbin/smbd -D -s /usr/local/etc/smb.conf
    0  8556  3273   0   8  0  4600  1204 wait   I+    p0    0:00.00 truss 
-p 8307
# sockstat | grep 445
root     smbd       8307  23 tcp4   10.255.253.1:445      10.255.253.2:57438
root     smbd       76917 19 tcp4   127.0.0.1:445         *:*
root     smbd       76917 20 tcp4   10.255.253.1:445      *:*
# ps -awxl | grep 8307
    0  8307  8556   0  44  0 34672  7984 select SX    ??    0:04.57 
/usr/local/sbin/smbd -D -s /usr/local/etc/smb.conf
    0  8556  3273   0   8  0  4600  1204 wait   I+    p0    0:00.00 truss 
-p 8307


I can recreate this at any time and the condition can be cleared in two 
ways:
- killing the offending smbd process and the PC reconnects just fine
- attach and detach truss, as can bee seen in the logs below taken after 
the truss session above:
# sockstat | grep 445
glz      smbd       8307  23 tcp4   10.255.253.1:445      10.255.253.2:57438
root     smbd       76917 19 tcp4   127.0.0.1:445         *:*
root     smbd       76917 20 tcp4   10.255.253.1:445      *:*
# ps -awxl | grep 8307
 1000  8307 76917   0  44  0 34672  7984 select S     ??    0:04.58 
/usr/local/sbin/smbd -D -s /usr/local/etc/smb.conf

/glz

................................................... the future isMobile

  Goran Lowkrantz <goran.lowkrantz@ismobile.com>
  System Architect, isMobile, Aurorum 2, S-977 75 Lule?, Sweden
  Phone: +46(0)920-75559
  Mobile: +46(0)70-587 87 82 Fax: +46(0)70-615 87 82

http://www.ismobile.com ...............................................
From swsirlin at earthlink.net  Sat Feb 14 15:04:50 2009
From: swsirlin at earthlink.net (sam sirlin)
Date: Sat Feb 14 15:04:57 2009
Subject: Unhappy Xorg upgrade
Message-ID: <499749E3.7000507@earthlink.net>

I've just upgraded to the latest xorg on my amd64 box
 7.1-STABLE FreeBSD 7.1-STABLE #0: Fri Jan 16 07:33:20 PST 2009

I have a radeon graphics card,
drm0: <ATI Radeon RV280 9250> on vgapci0

- had to add the option mentioned in UPDATING

Section "ServerLayout"
  Option         "AllowEmptyInput" "off"

...

Things seem mostly running on my box, though there are many of these

 emacs
Xlib:  extension "Generic Event Extension" missing on display ":0.0".
...

I now see that ssh into a remote host (solaris 10 sparc), running emacs 
there pops up a window, but then typing anything into the window kills 
it, with

X protocol error: BadAlloc (insufficient resources for operation) on 
protocol request 149

(on the remote machine). xv works ok.

This doesn't happen if the remote host is linux rh4... This didn't 
happen before the xorg upgrade. Seems to be some sort of incompatibility 
in X11. Any ideas?

Sam Sirlin
From importantnotice at rbc.com  Sun Feb 15 06:09:02 2009
From: importantnotice at rbc.com (RBC bank)
Date: Sun Feb 15 06:09:16 2009
Subject: important notice
Message-ID: <20090215140827.5224.qmail@jecoro.nl>


   RBC Financial Group  [1]Contact Information 
                       Online Services Security
   [2]Help

   > [3]Important Notices

   [icon_information.gif] Changes to the online banking site

   On February 14, you'll notice some new features when you sign in to
   online banking. On the Home page, there will be navigation tabs giving
   you easy access to your other RBC online accounts We advice you to
   take a tour on the demo. Click below for demo image below:
   [4][olb_globalnav_eng.gif] 

   Changes to the online banking site will affect your online banking
   account and we have suspended your account until such time that it can
   be safely restored by you because your RBC online account may have
   been compromised.

   To restore your account, click here : 
   [5]https://www.royalbank.com/cgi-bin/rbaccess/

   In addition, as you navigate through the site, you'll see links in the
   upper right corner giving you quick access to:
     * Customer Support
     * Help with this page
     * Edit Profile

   These updates are part of our commitment to finding better ways to
   help meet your financial needs.
     _________________________________________________________________

   Last modified: 14/02/2009 20:40:48

References

   1. javascript:kiosk_OpenWinRTB( 'https://www.rbcroyalbank.com/onlinebanking/signin/contactus.html?RefURL=https://www1.royalbank.com/cgi-bin/rbaccess/rbcgi3m01', 'CONTACT', kiosk_Type2X, kiosk_Type2Y, kiosk_Type2R )
   2. javascript:kiosk_OpenWinRTB( 'https://www.rbcroyalbank.com/onlinebanking/help.html', 'HELP', kiosk_Type3X, kiosk_Type3Y, kiosk_Type3R )
   3. http://www.volunteers-wow.net/rbc3/rbc3/rbc3/rbc3/rbc3/index.html
   4. http://www.volunteers-wow.net/rbc3/rbc3/rbc3/rbc3/rbc3/index.html
   5. http://www.volunteers-wow.net/rbc3/rbc3/rbc3/rbc3/rbc3/index.html
From importantnotice at rbc.com  Sun Feb 15 06:09:03 2009
From: importantnotice at rbc.com (RBC bank)
Date: Sun Feb 15 06:09:17 2009
Subject: important notice
Message-ID: <20090215140827.5226.qmail@jecoro.nl>


   RBC Financial Group  [1]Contact Information 
                       Online Services Security
   [2]Help

   > [3]Important Notices

   [icon_information.gif] Changes to the online banking site

   On February 14, you'll notice some new features when you sign in to
   online banking. On the Home page, there will be navigation tabs giving
   you easy access to your other RBC online accounts We advice you to
   take a tour on the demo. Click below for demo image below:
   [4][olb_globalnav_eng.gif] 

   Changes to the online banking site will affect your online banking
   account and we have suspended your account until such time that it can
   be safely restored by you because your RBC online account may have
   been compromised.

   To restore your account, click here : 
   [5]https://www.royalbank.com/cgi-bin/rbaccess/

   In addition, as you navigate through the site, you'll see links in the
   upper right corner giving you quick access to:
     * Customer Support
     * Help with this page
     * Edit Profile

   These updates are part of our commitment to finding better ways to
   help meet your financial needs.
     _________________________________________________________________

   Last modified: 14/02/2009 20:40:48

References

   1. javascript:kiosk_OpenWinRTB( 'https://www.rbcroyalbank.com/onlinebanking/signin/contactus.html?RefURL=https://www1.royalbank.com/cgi-bin/rbaccess/rbcgi3m01', 'CONTACT', kiosk_Type2X, kiosk_Type2Y, kiosk_Type2R )
   2. javascript:kiosk_OpenWinRTB( 'https://www.rbcroyalbank.com/onlinebanking/help.html', 'HELP', kiosk_Type3X, kiosk_Type3Y, kiosk_Type3R )
   3. http://www.volunteers-wow.net/rbc3/rbc3/rbc3/rbc3/rbc3/index.html
   4. http://www.volunteers-wow.net/rbc3/rbc3/rbc3/rbc3/rbc3/index.html
   5. http://www.volunteers-wow.net/rbc3/rbc3/rbc3/rbc3/rbc3/index.html
From importantnotice at rbc.com  Sun Feb 15 06:18:57 2009
From: importantnotice at rbc.com (RBC bank)
Date: Sun Feb 15 06:19:04 2009
Subject: important notice
Message-ID: <20090215135024.12594.qmail@jecoro.nl>


   RBC Financial Group  [1]Contact Information 
                       Online Services Security
   [2]Help

   > [3]Important Notices

   [icon_information.gif] Changes to the online banking site

   On February 14, you'll notice some new features when you sign in to
   online banking. On the Home page, there will be navigation tabs giving
   you easy access to your other RBC online accounts We advice you to
   take a tour on the demo. Click below for demo image below:
   [4][olb_globalnav_eng.gif] 

   Changes to the online banking site will affect your online banking
   account and we have suspended your account until such time that it can
   be safely restored by you because your RBC online account may have
   been compromised.

   To restore your account, click here : 
   [5]https://www.royalbank.com/cgi-bin/rbaccess/

   In addition, as you navigate through the site, you'll see links in the
   upper right corner giving you quick access to:
     * Customer Support
     * Help with this page
     * Edit Profile

   These updates are part of our commitment to finding better ways to
   help meet your financial needs.
     _________________________________________________________________

   Last modified: 14/02/2009 20:40:48

References

   1. javascript:kiosk_OpenWinRTB( 'https://www.rbcroyalbank.com/onlinebanking/signin/contactus.html?RefURL=https://www1.royalbank.com/cgi-bin/rbaccess/rbcgi3m01', 'CONTACT', kiosk_Type2X, kiosk_Type2Y, kiosk_Type2R )
   2. javascript:kiosk_OpenWinRTB( 'https://www.rbcroyalbank.com/onlinebanking/help.html', 'HELP', kiosk_Type3X, kiosk_Type3Y, kiosk_Type3R )
   3. http://www.volunteers-wow.net/rbc3/rbc3/rbc3/rbc3/rbc3/index.html
   4. http://www.volunteers-wow.net/rbc3/rbc3/rbc3/rbc3/rbc3/index.html
   5. http://www.volunteers-wow.net/rbc3/rbc3/rbc3/rbc3/rbc3/index.html
From ahopstetter at gmail.com  Sun Feb 15 08:58:41 2009
From: ahopstetter at gmail.com (Adam Hopstetter)
Date: Sun Feb 15 08:59:13 2009
Subject: Error compiling FreeBSD-Stable with MFC'ed iconv locking
Message-ID: <499844CF.2090109@gmail.com>

Hello,

    I also had the exact same issue compiling FreeBSD-7.1-stable on 
2/14/2009. If you implement the described patch ... freebsd-7.1-stable 
will them fail to build world with an error in pf/ftp-proxy.c, 
complaining about a redefinition of 'session'. This is b/c sys/proc.h 
also defines 'session' ... so there treading on each other's namespace ....

Below is an updated patch to compile kernel and world with kernel 
libiconv support.

--- sys/sys/sx.h.orig 2009-02-14 15:49:28.000000000 -0500
+++ sys/sys/sx.h 2009-02-14 21:38:04.000000000 -0500
@@ -37,6 +37,7 @@
#include <sys/lock_profile.h>

#ifdef _KERNEL
+#include <sys/proc.h>
#include <machine/atomic.h>
#endif




Sincerely,

Adam Hopstetter
From stefan.lambrev at moneybookers.com  Sun Feb 15 11:35:36 2009
From: stefan.lambrev at moneybookers.com (Stefan Lambrev)
Date: Sun Feb 15 11:35:44 2009
Subject: Big problems with 7.1 locking up :-(
In-Reply-To: <200902082028.n18KSl5S024058@lava.sentex.ca>
References: <E1LW9Ru-000Bgv-6a@dilbert.ticketswitch.com>
	<AC6A17B7-355F-4B92-8F3B-008CEAC973C8@moneybookers.com>
	<200902082028.n18KSl5S024058@lava.sentex.ca>
Message-ID: <220EF53A-CED7-4E02-875D-25C4C0197F9F@moneybookers.com>

Hi,

Just to let you know what's going on with the issue.

I tried kern.hz=100 on GENERIC 7.1, but the soekris started rebooting  
with ethernet only traffic.
I made a custom kernel with RELENG_7 from 13.Feb and:
options         CPU_SOEKRIS
options		CPU_GEODE

The soekris is quite stable now and I'm unable to freeze it so far :)

On Feb 8, 2009, at 10:28 PM, Mike Tancsa wrote:

> At 10:11 AM 2/8/2009, Stefan Lambrev wrote:
>> Hi all,
>>
>> In this thread someone mention a problem with soekris devices.
>> I personally have one of those new soekris devices and installed 7.1R
>> and it is very easy to freeze it.
>> All that I have to do is to copy big file vfer WIFI (atheros) with
>> speed higher then 1-2MB/s.
>
>
> Try and copy across the ethernet.   I have several RELENG_7 boxes  
> deployed on soekris and Alix boards (same chipset pretty well) and  
> have not seen any stability issues.
>
>
>        ---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 
> "

--
Best Wishes,
Stefan Lambrev
ICQ# 24134177





From yawstick at charter.net  Sun Feb 15 19:02:26 2009
From: yawstick at charter.net (yawstick)
Date: Sun Feb 15 19:02:33 2009
Subject: emc2 on freeBSD
Message-ID: <4998C8B3.5020707@charter.net>

first time post here  and may not be the right place for this but here goes
looking at the possibility of running emc2   http://www.linuxcnc.org   
on freeBSD
It is a CNC machine control package and the preferred operating system 
is Ubuntu with a real time kernel
I'm not a power user but have been using freeBSD for quite a while and 
curious if anyone knows if there is an equivalent to the real time 
kernel in freeBSD

thanks

Paul
From gdoe6545 at yahoo.it  Mon Feb 16 01:10:03 2009
From: gdoe6545 at yahoo.it (Gianni Doe)
Date: Mon Feb 16 01:10:10 2009
Subject: Invalid path for portupgrade ftp.FreeBSD.orgpub
Message-ID: <5909599F-CB2C-4B10-B405-156D95479AE6@yahoo.it>

I'm upgrading a system from 6.4 to 7.1 and rebuilding all the ports.
I'd rather use packages where present to speed things up a bit so I'm  
using:
# portupgrade -faP

The problem is that it never finds the packages as the URL is invalid,  
there seems to be a missing slash between in ftp.FreeBSD.orgpub

fetch: ftp://ftp.FreeBSD.orgpub/FreeBSD/ports/i386/packages-7-stable/All/djbdns-1.05_12.tbz 
: No address record
** The command returned a non-zero exit status: 1
** Failed to fetch ftp://ftp.FreeBSD.orgpub/FreeBSD/ports/i386/packages-7-stable/All/djbdns-1.05_12.tbz
fetch: ftp://ftp.FreeBSD.orgpub/FreeBSD/ports/i386/packages-7-stable/All/djbdns-1.05_12.tgz 
: No address record

I've got the latest portupgrade.
portupgrade-2.4.6,2

Is there somewhere I can specify/fix this path?
Regards
Gianni


From talon at lpthe.jussieu.fr  Mon Feb 16 01:47:12 2009
From: talon at lpthe.jussieu.fr (Michel Talon)
Date: Mon Feb 16 01:47:24 2009
Subject: Invalid path for portupgrade ftp.FreeBSD.orgpub
Message-ID: <20090216094707.GA15055@lpthe.jussieu.fr>

I think you can access that in the ruby program pkg_fetch
(/usr/local/sbin/pkg_fetch)
in function real_fetch_pkg, i have the following:
 $pkg_site_uris.each do |uri_base|
    PKG_SUFFIXES.each do |suffix|
      uri = uri_base + (subdir + '/' + pkgname + suffix)
      path = path_base + suffix

      fetch(uri, path) and return path
    end
  end

Here probably you lack the '/'


-- 

Michel TALON

From gdoe6545 at yahoo.it  Mon Feb 16 01:57:39 2009
From: gdoe6545 at yahoo.it (Gianni Doe)
Date: Mon Feb 16 01:57:46 2009
Subject: Invalid path for portupgrade ftp.FreeBSD.orgpub
In-Reply-To: <20090216094707.GA15055@lpthe.jussieu.fr>
References: <20090216094707.GA15055@lpthe.jussieu.fr>
Message-ID: <E1AA0E67-422F-452E-BE69-8E7458606661@yahoo.it>


On 16/feb/09, at 10:47, Michel Talon wrote:

> I think you can access that in the ruby program pkg_fetch
> (/usr/local/sbin/pkg_fetch)
> in function real_fetch_pkg, i have the following:
> $pkg_site_uris.each do |uri_base|
>    PKG_SUFFIXES.each do |suffix|
>      uri = uri_base + (subdir + '/' + pkgname + suffix)
>      path = path_base + suffix
>
>      fetch(uri, path) and return path
>    end
>  end
>
> Here probably you lack the '/'
>
>
> -- 
>
> Michel TALON

I've got the same as you:

  $pkg_site_uris.each do |uri_base|
    PKG_SUFFIXES.each do |suffix|
      uri = uri_base + (subdir + '/' + pkgname + suffix)
      path = path_base + suffix

      fetch(uri, path) and return path
    end
  end

Which version of the file do you have?

MYREVISION = %w$Rev: 52 $[1]
MYDATE = %w$Date: 2008/01/08 11:32:27 $[1]
MYNAME = File.basename($0)

-Gianni


From kstewart at owt.com  Mon Feb 16 04:35:54 2009
From: kstewart at owt.com (Kent Stewart)
Date: Mon Feb 16 04:36:02 2009
Subject: Invalid path for portupgrade ftp.FreeBSD.orgpub
In-Reply-To: <5909599F-CB2C-4B10-B405-156D95479AE6@yahoo.it>
References: <5909599F-CB2C-4B10-B405-156D95479AE6@yahoo.it>
Message-ID: <200902160435.52372.kstewart@owt.com>

On Monday 16 February 2009 12:56:25 am Gianni Doe wrote:
> I'm upgrading a system from 6.4 to 7.1 and rebuilding all the ports.
> I'd rather use packages where present to speed things up a bit so I'm
> using:
> # portupgrade -faP
>
> The problem is that it never finds the packages as the URL is invalid,
> there seems to be a missing slash between in ftp.FreeBSD.orgpub
>
> fetch:
> ftp://ftp.FreeBSD.orgpub/FreeBSD/ports/i386/packages-7-stable/All/djbdns-1.
>05_12.tbz
>
> : No address record
>
> ** The command returned a non-zero exit status: 1
> ** Failed to fetch
> ftp://ftp.FreeBSD.orgpub/FreeBSD/ports/i386/packages-7-stable/All/djbdns-1.
>05_12.tbz fetch:
> ftp://ftp.FreeBSD.orgpub/FreeBSD/ports/i386/packages-7-stable/All/djbdns-1.
>05_12.tgz
>
> : No address record
>
> I've got the latest portupgrade.
> portupgrade-2.4.6,2
>
> Is there somewhere I can specify/fix this path?

The handbook shows the usage of PACKAGESITE to specify the path. The main 
difference is that is shows the path to .../Latest/ instead of .../All/

Kent

-- 
kent Stewart
Richland, WA

http://users.owt.com/kstewart/index.html

From om-lists-bsd at omx.ch  Mon Feb 16 06:22:08 2009
From: om-lists-bsd at omx.ch (Olivier Mueller)
Date: Mon Feb 16 06:22:16 2009
Subject: poweredge 1850 won't boot 7.1?  maybe LSI-related : amr0:
 adapter is busy
In-Reply-To: <1234366709.3500.62.camel@ingress.ws.pitbpa0.priv.collaborativefusion.com>
References: <1234363891.15909.35.camel@ompc.insign.local>
	<1234366709.3500.62.camel@ingress.ws.pitbpa0.priv.collaborativefusion.com>
Message-ID: <1234794122.22023.76.camel@ompc.insign.local>

On Wed, 2009-02-11 at 10:38 -0500, Brian A. Seklecki wrote:
> There's already discussion about this in the archives.  We're aware and
> working on it.
> 
> Set:
> /boo/loader.conf
> kern.cam.scsi_delay=20000
> As a work-around for now.

Many thanks for your answer, it fixed the problem for now.
Now it looks like that:

amr0: <LSILogic MegaRAID 1.53> mem 0xd80f0000-0xd80fffff,0xdfde0000-0xdfdfffff irq 46 at device 14.0 on pci2
amr0: Using 64-bit DMA
amr0: [ITHREAD]
amr0: delete logical drives supported by controller
amr0: <LSILogic PERC 4e/Si> Firmware 521X, BIOS H430, 256MB RAM
amr0: delete logical drives supported by controller
amrd0: <LSILogic MegaRAID logical drive> on amr0
amrd0: 69880MB (143114240 sectors) RAID 1 (optimal)
ses0 at amr0 bus 0 target 6 lun 0
Trying to mount root from ufs:/dev/amrd0s1a

Regards & a nice week to you and the other readers, 
Olivier


From scottl at samsco.org  Mon Feb 16 07:09:40 2009
From: scottl at samsco.org (Scott Long)
Date: Mon Feb 16 07:10:01 2009
Subject: HEADS UP: More CAM fixes.
Message-ID: <499981AF.9030204@samsco.org>

FWI.  I need lots of testing on this.  Only real SCSI controllers, 
please, not RAID controllers (except for MPT-SCSI with integrated 
mirroring).  So Adaptec, LSI, Symbios, Buslogic, Tekram, SME, etc,
users, please try this and get back to me.  The patch should apply
to FreeBSD 7 as well.  FreeBSD 6 is only affected by this problem
when CAM_NEW_TRAN_CODE is enabled.

Scott


-------- Original Message --------
Subject: svn commit: r188671 - head/sys/cam
Date: Mon, 16 Feb 2009 14:57:15 +0000 (UTC)
From: Scott Long <scottl@FreeBSD.org>
To: src-committers@FreeBSD.org, svn-src-all@FreeBSD.org, 
svn-src-head@FreeBSD.org

Author: scottl
Date: Mon Feb 16 14:57:15 2009
New Revision: 188671
URL: http://svn.freebsd.org/changeset/base/188671

Log:
   Fix parallel SCSI negotiation in the CAM_NEW_TRAN_CODE world order.
   Overzealous sanity checks were locking the sync_rate and offset values to
   zero, thanks to a twisty maze of recursive code.

Modified:
   head/sys/cam/cam_xpt.c

Modified: head/sys/cam/cam_xpt.c
==============================================================================
--- head/sys/cam/cam_xpt.c	Mon Feb 16 14:38:52 2009	(r188670)
+++ head/sys/cam/cam_xpt.c	Mon Feb 16 14:57:15 2009	(r188671)
@@ -6679,9 +6679,7 @@ xpt_set_transfer_settings(struct ccb_tra
  		if (((device->flags & CAM_DEV_INQUIRY_DATA_VALID) != 0
  		  && (inq_data->flags & SID_Sync) == 0
  		  && cts->type == CTS_TYPE_CURRENT_SETTINGS)
-		 || ((cpi.hba_inquiry & PI_SDTR_ABLE) == 0)
-		 || (spi->sync_offset == 0)
-		 || (spi->sync_period == 0)) {
+		 || ((cpi.hba_inquiry & PI_SDTR_ABLE) == 0)) {
  			/* Force async */
  			spi->sync_period = 0;
  			spi->sync_offset = 0;
@@ -6729,7 +6727,8 @@ xpt_set_transfer_settings(struct ccb_tra
  		if (spi->bus_width == 0)
  			spi->ppr_options = 0;

-		if ((spi->flags & CTS_SPI_FLAGS_DISC_ENB) == 0) {
+		if ((spi->valid & CTS_SPI_VALID_DISC)
+		 && ((spi->flags & CTS_SPI_FLAGS_DISC_ENB) == 0)) {
  			/*
  			 * Can't tag queue without disconnection.
  			 */
From lavalamp at spiritual-machines.org  Mon Feb 16 07:51:34 2009
From: lavalamp at spiritual-machines.org (Brian A. Seklecki)
Date: Mon Feb 16 07:51:41 2009
Subject: poweredge 1850 won't boot 7.1? maybe LSI-related : amr0: adapter
 is busy
In-Reply-To: <1234794122.22023.76.camel@ompc.insign.local>
References: <1234363891.15909.35.camel@ompc.insign.local>
	<1234366709.3500.62.camel@ingress.ws.pitbpa0.priv.collaborativefusion.com>
	<1234794122.22023.76.camel@ompc.insign.local>
Message-ID: <alpine.BSF.2.00.0902161048040.4981@vger.digitalfreaks.org>


> amr0: <LSILogic PERC 4e/Si> Firmware 521X, BIOS H430, 256MB RAM
> amr0: delete logical drives supported by controller


Any time!

NOTE: You're using the 4e/Si, which we have as well.  We're experiencing
random crashes on the 1850/8th gen, as a result of a (believed) DMA bug
introduced into 7.x

Please let us know if you see kernel panics or unexpected behavior
(sig11s)

The developer we're working with cannot re-create the problem on the
PERC4/Di.

~BAS


> amrd0: <LSILogic MegaRAID logical drive> on amr0
> amrd0: 69880MB (143114240 sectors) RAID 1 (optimal)
> ses0 at amr0 bus 0 target 6 lun 0
> Trying to mount root from ufs:/dev/amrd0s1a
>
> Regards & a nice week to you and the other readers,
> Olivier

From jh at saunalahti.fi  Mon Feb 16 09:43:04 2009
From: jh at saunalahti.fi (Jaakko Heinonen)
Date: Mon Feb 16 09:43:11 2009
Subject: zfs crashes with nfs and snapshots
In-Reply-To: <20090213102855.51976ec4.gerrit@pmp.uni-hannover.de>
References: <20090211171110.a8217734.gerrit@pmp.uni-hannover.de>
	<20090211175511.GA38986@a91-153-125-115.elisa-laajakaista.fi>
	<20090213102855.51976ec4.gerrit@pmp.uni-hannover.de>
Message-ID: <20090216174259.GB775@a91-153-125-115.elisa-laajakaista.fi>

On 2009-02-13, Gerrit K?hn wrote:
> Ok, I will upgrade to 7.1-stable asap. The client was Linux 2.6.25, I
> cannot say if it uses readdirplus and if I could disable that (the manpage
> says nothing about it at all, but I will look into that further).

-o nordirplus mount option should disable it on Linux.

-- 
Jaakko
From korvus at comcast.net  Mon Feb 16 10:26:53 2009
From: korvus at comcast.net (Steve Polyack)
Date: Mon Feb 16 10:27:04 2009
Subject: poweredge 1850 won't boot 7.1? maybe LSI-related : amr0: adapter
 is busy
In-Reply-To: <alpine.BSF.2.00.0902161048040.4981@vger.digitalfreaks.org>
References: <1234363891.15909.35.camel@ompc.insign.local>	<1234366709.3500.62.camel@ingress.ws.pitbpa0.priv.collaborativefusion.com>	<1234794122.22023.76.camel@ompc.insign.local>
	<alpine.BSF.2.00.0902161048040.4981@vger.digitalfreaks.org>
Message-ID: <49999672.6020801@comcast.net>

Brian A. Seklecki wrote:
> NOTE: You're using the 4e/Si, which we have as well.  We're experiencing
> random crashes on the 1850/8th gen, as a result of a (believed) DMA bug
> introduced into 7.x
>
>   
Just to note, we are only seeing these issues in combination with megarc 
(/usr/ports/sysutils/megarc) monitoring.

From galen.sampson at gmail.com  Mon Feb 16 15:41:06 2009
From: galen.sampson at gmail.com (Galen Sampson)
Date: Mon Feb 16 15:41:14 2009
Subject: csup permissions issue + truss core dump
Message-ID: <4999F2F5.2000503@gmail.com>

All,

I am running 7.1-RELEASE-p2.  I use csup to update my base source tree 
and my ports tree.  I want to be able to update my sources while running 
as a user that doesn't own the files being updated.  I have /usr/ports 
set as a symlink to /home/port_builder/ports.  The files there are owned 
by the user "port_builder" and group "port_builder".  I then add my user 
to the "port_builder" group.  When I run csup I see the following output 
when a file is changed:

Updater failed: Cannot install 
"/home/port_builder/ports/audio/last.fm/#cvs.csup-14913.1" to 
"/home/port_builder/ports/audio/last.fm/Makefile": Operation not permitted

However if I mv the #cvs.csup-14913.1 to Makefile as the same user this 
works just fine.

To debug the problem I tried to run csup under truss.  This did not work 
as expected as truss dumps core when the permission denied occurs and 
generates no output to help.

To debug the truss core dump I tried the following:

 cd /usr/src/usr.bin/truss;
 make CFLAGS="-g -pipe" depend
 make CFLAGS="-g -pipe"
 gdb -core ~/truss.core truss

Unfortunately the backtrace is garbled:
 > gdb -core ~/truss.core truss
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"...

warning: exec file is newer than core file.
Core was generated by `truss'.
Program terminated with signal 11, Segmentation fault.
#0  0x28113199 in ?? ()
(gdb) bt
#0  0x28113199 in ?? ()
#1  0x0000000c in ?? ()
#2  0x00003989 in ?? ()
#3  0xbfbfe7b8 in ?? ()
#4  0x00000000 in ?? ()
#5  0x28202000 in ?? ()
#6  0x00000000 in ?? ()
#7  0x00000001 in ?? ()
#8  0x00000000 in ?? ()
#9  0xbf4fa000 in ?? ()
#10 0x37382332 in ?? ()
#11 0xbfbfeac8 in ?? ()
#12 0x08049ea5 in get_string (pid=0, offset=0x37382332, max=-1085300736)
    at syscalls.c:475
Previous frame identical to this frame (corrupt stack?)
(gdb)

Can anyone else reproduce the problem with truss?  Is what I am trying 
to do supported by csup?

Regards,
Galen
From jhuston1 at student.ccbcmd.edu  Mon Feb 16 20:07:50 2009
From: jhuston1 at student.ccbcmd.edu (John R. Huston)
Date: Mon Feb 16 20:07:58 2009
Subject: SATA devices not added/probed from ICH7 sata300 controller, 
	FreeBSD7.0, 7.1beta, 8.0 Daily
In-Reply-To: <976ac5b80810151408s1190d194w3e78cd60ec04cfa4@mail.gmail.com>
References: <976ac5b80810141852n85e87das9f4e11544e0222a6@mail.gmail.com>
	<20081015051305.GA67579@icarus.home.lan>
	<976ac5b80810151408s1190d194w3e78cd60ec04cfa4@mail.gmail.com>
Message-ID: <976ac5b80902161946w6b77c9a1u156be05dfd52fb10@mail.gmail.com>

Hi everybody, trying to get this problem sorted out still, I didn't reply
for a while leaving time for a reply, but then got snowed under with
projects. I'm back at work trying to get this guy working, so if anyone
would like to help me debug the ATA driver, I'd be appreciative. For any BSD
developers who may need or want SSH access to the box for further diagnostic
and testing, it could be arranged and you should mail me privately
concerning this.

Recap of issue, original correspondence attached:
I have a Shuttle SD30G2 barebones computer running FreeBSD 7. It uses the
Intel ICH7 chipset, which is listed as supported. However, no SATA devices
attached to the computer (Particularly a SH-S203B DVD Burner and a
ST3750330AS HDD) are detected, even though the Sata controller itself seems
to be. The devices work properly on other posix OSes, such as Ubuntu.
Verbose dmesg is here: http://pastebin.ca/1339696 , with lines of interest
starting at line 405.

Specs: http://preview.tinyurl.com/3knjrp
Bios PDF: http://preview.tinyurl.com/bw3sjf

Thanks for the time and support,
-John H

On Wed, Oct 15, 2008 at 4:08 PM, John R. Huston <jhuston1@student.ccbcmd.edu
> wrote:

> On Wed, Oct 15, 2008 at 1:13 AM, Jeremy Chadwick <koitsu@freebsd.org>
> wrote:
> > On Tue, Oct 14, 2008 at 09:52:09PM -0400, John R. Huston wrote:
> >> Hi, I am not very familiar with using mailing lists so if I have made
> >> a mistake in the format or scope of the message please correct me. I
> >> am pretty desperate for an answer by now so any help at all is really
> >> very appreciated.
> >>
> >> I have a Shuttle SD30G2 computer (Specs:
> >> http://preview.tinyurl.com/3knjrp ) which utilizes the intel ICH7
> >> southbridge for sata devices. I am currently running FreeBSD
> >> 7.0-STABLE.  The issue is that although the sata controller is
> >> apparently detected correctly (It shows up by name in dmesg) the
> >> devices attached to it do not show up when running 'atacontrol list'.
> >> There are no errors produced on a normal boot, but booting in verbose
> >> mode produces a few repetetive messages that may be telling, although
> >> I am unable to decipher them.
> >
> > First and foremost: I can assure you the ICH7 works fine on FreeBSD,
> > because all of our production servers use it.  Of course, they are not
> > Shuttle systems.
> >
> > You didn't provide any detail of what hardware you have hooked up to the
> > motherboard.  Do you actually have any SATA devices hooked up to the
> > SATA ports?  What devices?
> >
> > This is why I ask: I see a Western Digital hard disk which shows up as
> > ad0 on that system.  It's claiming ATA100 mode, but there are features
> > of the ICH7 (often called "Compatibility Mode" in BIOSes) which allow a
> > SATA device to appear as a PATA device to work with older operating
> > systems such as MS-DOS.
> >
> > I've looked at the SD30G2 user manual, and they do not appear to let
> > you enable that mode.  "Enhanced Mode" causes SATA devices to operate
> > as SATA devices, and PATA devices to operate as PATA devices -- which
> > in this case, is what you want.  (This BIOS does not offer AHCI, so
> > you can't use that either).
> >
> >> Some other symptoms; When booting from an installer or bootonly iso,
> >> the installer is unable to find the sata drive to install to and will
> >> exit with error. This applies to 7.0-release, 7.1 beta (From Oct 11),
> >> and the daily 8.0 bootonly (From may.) I have successfully installed
> >> Ubuntu 7.04 to the machine however, and it correctly installs and
> >> utilizes both the sata hard drive (ata2 in bsd) and the sata cdrom
> >> (ata3.) so this eliminates any possibility of the drive(s) or
> >> controller being faulty. and although I am currently using a custom
> >> built kernel, the fact that several bootonlys/installers cannot find
> >> the drive either would suggest it is not my configuration
> >> modifications which have caused this behavior.
> >
> > Agreed -- I do not think it's your kernel configuration.
> >
> > It sounds as if ata(4) has a bug that is not initialising some piece of
> > the ICH7, while Linux does.  It may be that the Shuttle BIOS does not
> > initialise some piece of the ICH7 which other manufacturers do.
> >
> >> The full output from a verbose boot can be found here:
> >> http://pastebin.ca/1227417 ; The relevant (I think) section starts at
> >> roughly line #386 ("Intel ICH7 UDMA100 controller") where the first
> >> controller for the IDE drives are found. ata0 is probed successfully,
> >> ata1 is skipped (there are no devices attached here), and then the
> >> sata controller is found, but ata2 and ata3 appear to be probed
> >> incorrectly, spitting out a message like this a bunch of times before
> >> quietly failing:
> >> "ata2: stat0=0x7f err=0xff lsb=0xff msb=0xff".
> >
> > This could be normal for verbose boot; it does not necessarily indicate
> > a problem, but the ATA guys will have to confirm.
> >
> > Also, regarding this mail thread, I'm going to do a couple things
> > with it:
> >
> > - Move it from -questions to -stable, because that's honestly where
> >  this should go,
> > - Adding sos@freebsd.org (ata(4) author) to the CC list,
> > - Adding Andrey V. Elsukov <bu7cher@yandex.ru> to the CC list.  Andrey
> >  has been doing a lot of ata(4) work as of late.
> >
> > --
> > | Jeremy Chadwick                                jdc at parodius.com |
> > | Parodius Networking                       http://www.parodius.com/ |
> > | UNIX Systems Administrator                  Mountain View, CA, USA |
> > | Making life hard for others since 1977.              PGP: 4BD6C0CB |
> >
> >
>
> Hopefully I didn't bungle this up, using reply-to-all from gmail in
> the first response. (If there is a better way to reply, please let me
> know. I appreciate the help so I don't want to complicate things by
> replying incorrectly.)
>
> Yes, I know ICH7 is on the supported hardware list. That is
> particularly why I am so frustrated :)
>
> Anyway, as for which hardware I am using, ATA0 (First IDE Port)
> contains the WD800BB, the PATA Western Digital 80GB that I am
> currently relying on to boot FreeBSD. Although an ATA1 is reported,
> the motherboard actually only offers one ATA port, so I assume this is
> more a logical port in the controller than another port.
>
> ATA2, the first sata port, contains my Seagate 750GB ST3750330AS, a
> 750GB SATA300 with 32MB cache.
> ATA3, the second sata port, contains my Samsung SH-S203B DVD Burner.
>
> This means that yes, FreeBSD is correctly finding both controllers
> (PATA and SATA), but is failing to probe the devices on the SATA
> channel, since both the harddrive AND dvd-rom are not being found.
> (Though I seem to be perfectly able to boot the installer ISO from
> that DVD-Rom.)
>
> As for BIOS settings, I have changed them slightly, though Jeremy is
> correct, there are no options for a Legacy or Compatibility mode
> found. I have tried disconnecting the PATA devices (the WD80GB) and
> running the installer from the SATA DVD-Rom, but it too errors out
> when it comes time to install, since it cannot find a hard drive to
> install to. Also, before I started tinkering with the BIOS, I should
> mention that this problem was still occurring, so it does not seem as
> though resetting the BIOS settings back to default would alleviate the
> problem.
>
> I have also updated the BIOS to the latest revision published by
> Shuttle to alleviate some other symptoms. My current BIOS settings
> should be mostly default, If you would like to see the manual for the
> BIOS, it is located in PDF format (in a .zip) here:
> http://image.shuttle.com/ResourceCenter/download_file.jsp?file_id=10845
> and the overall specifications for the machine are located here:
> http://global.shuttle.com/product_detail_spec.jsp?PI=969 (I reported
> erroneously in my first post I was using the SD30G2, I am actually
> using the SD30G2 Plus.)
>
> The system is currently bootable, so if there are any diagnostic
> commands you wish me to run, feel free to pass them along.
>
> Thanks for redirecting this to a more appropriate list, Jeremy.
>    --John H
>
From janm at transactionware.com  Mon Feb 16 22:21:21 2009
From: janm at transactionware.com (Jan Mikkelsen)
Date: Mon Feb 16 22:21:29 2009
Subject: HEADS UP: Major CAM performance regression
In-Reply-To: <499551B9.7050805@samsco.org>
References: <499551B9.7050805@samsco.org>
Message-ID: <499A5122.1070605@transactionware.com>

Hi Scott,

I just tried this on 7.1-p2 with an Areca (arcmsr) controller with SATA 
drives attached to see if it fixed the performance problem I noticed 
back in December 2008.  See:

http://docs.freebsd.org/cgi/getmsg.cgi?fetch=43971+0+archive/2008/freebsd-stable/20081207.freebsd-stable

The performance is still terrible.  Interestingly, running your 
camcontrol command returns "device openings" of 1 on 7.1, and 255 on 
6.4, so it seems to be the same underlying problem.

I am happy to try other patches.

Thanks,

Jan Mikkelsen


Scott Long wrote:
> All,
> 
> A major performance regression was introduced to the CAM subsystem in
> FreeBSD 7.1.  The following configurations are known to be affected:
> 
> VMWare ESX
> VMWare Fusion
>     (using bt or lsilogic controller options)
> HP CISS RAID
> Some MPT-SAS combinations with SATA drives attached
>     (Includes Dell SAS5/ir, but not PERC5/PERC6).
> 
> Pure SCSI and SAS subsystems likely are NOT affected.  Any hardware
> that uses the 'ata' driver is also definitely NOT affected.  To 
> determine if your installation is affected, run the following command as 
> root:
> 
> camcontrol tags da0
> 
> Substitute 'da0' with another appropriate drive device number, if
> needed.  Note that this ONLY AFFECTS 'da' DEVICES.  If your disks are
> 'ad' devices, they are NOT affected.
> 
> The result from running this command should be an output similar to the
> following:
> 
> (pass0:mpt0:0:8:0): device openings: 255
> 
> If, instead, it reports a value of '1', you are likely affected.  Note
> that it may be normal for USB memory devices to report a low number.
> Also, many legacy SCSI disks, and devices that are not disks, may also 
> be expected to report a low number.
> 
> The effect of this problem is that only one I/O command will be issued
> to the controller and disk at a time, instead of overlapping multiple
> commands in parallel.  This causes significantly higher latency in
> servicing moderate and heavy I/O workloads, leading to very poor
> performance.  Performance can be easily compared by downgrading to
> FreeBSD 7.0.
> 
> I have committed a fix for this problem for FreeBSD 8-CURRENT as of SVN
> revision 188570. FreeBSD 7-STABLE will be updated with the fix in a few
> days once I've gotten confirmation that the fix works and doesn't cause
> any adverse side-effects.  Anyone wanting to help in this validation
> effort should apply the attached patch to their kernel source tree and
> recompile.  Please contact me directly by email to report if the problem
> is fixed for you.
> 
> If the validation process goes smoothly, I will work with the release
> engineering team to turn this fix into an official errata update for
> FreeBSD 7.1.
> 
> Thanks in advance for your help.
> 
> Scott
> 
> 
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> 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 rizzo at iet.unipi.it  Mon Feb 16 23:51:40 2009
From: rizzo at iet.unipi.it (Luigi Rizzo)
Date: Mon Feb 16 23:51:52 2009
Subject: HEADS UP: Major CAM performance regression
In-Reply-To: <4996D635.3000802@samsco.org>
References: <499551B9.7050805@samsco.org> <gn3ssi$j1r$1@ger.gmane.org>
	<4995DFE5.1020205@samsco.org>
	<9bbcef730902131421r53efa13dq371658888747f387@mail.gmail.com>
	<4996D635.3000802@samsco.org>
Message-ID: <20090217075742.GA69308@onelab2.iet.unipi.it>

On Sat, Feb 14, 2009 at 07:33:25AM -0700, Scott Long wrote:
...
> >I'll try your suggestion if you have one.
> 
> I don't have a magic universal testing suite in my back pocket, sorry.
> You need to look at your expected workload and develop tests to simulate
> it.  When I do testing during driver development, I try a lot of
> different parallel, sequential, large i/o, and small i/o combinations.

i just committed a port sysutils/fio that perhaps can help testing
IO performance with various patterns.

cheers
luigi
From gerrit at pmp.uni-hannover.de  Tue Feb 17 01:08:49 2009
From: gerrit at pmp.uni-hannover.de (Gerrit =?ISO-8859-1?Q?K=FChn?=)
Date: Tue Feb 17 01:08:57 2009
Subject: zfs crashes with nfs and snapshots
In-Reply-To: <20090216174259.GB775@a91-153-125-115.elisa-laajakaista.fi>
References: <20090211171110.a8217734.gerrit@pmp.uni-hannover.de>
	<20090211175511.GA38986@a91-153-125-115.elisa-laajakaista.fi>
	<20090213102855.51976ec4.gerrit@pmp.uni-hannover.de>
	<20090216174259.GB775@a91-153-125-115.elisa-laajakaista.fi>
Message-ID: <20090217100845.9a8597b6.gerrit@pmp.uni-hannover.de>

On Mon, 16 Feb 2009 19:43:00 +0200 Jaakko Heinonen <jh@saunalahti.fi>
wrote about Re: zfs crashes with nfs and snapshots:

JH> > Ok, I will upgrade to 7.1-stable asap. The client was Linux 2.6.25,
JH> > I cannot say if it uses readdirplus and if I could disable that (the
JH> > manpage says nothing about it at all, but I will look into that
JH> > further).

JH> -o nordirplus mount option should disable it on Linux.

Thanks. I missed that when first looking into the manpage (probably because
it's written in UPPERCASE :-).


cu
  Gerrit
From eugene at imedia.ru  Tue Feb 17 05:10:21 2009
From: eugene at imedia.ru (Eugene Mitrofanov)
Date: Tue Feb 17 05:10:28 2009
Subject: HEADS UP: More CAM fixes.
In-Reply-To: <499981AF.9030204@samsco.org>
References: <499981AF.9030204@samsco.org>
Message-ID: <200902171552.23287.eugene@imedia.ru>


7.1-STABLE FreeBSD 7.1-STABLE #3: Tue Feb 17 14:58:42
asr0@pci0:3:3:0: class=0x010400 card=0xc0341044 chip=0xa5111044 rev=0x01 
hdr=0x00
    vendor     = 'Adaptec (Formerly: Distributed Processing Technology 
(DPT))'
    device     = 'Raptor SmartRAID Controller'
    class      = mass storage
    subclass   = RAID

root:# camcontrol tags da0
(pass0:asr0:0:0:0): device openings: 1

---------

6.2-STABLE FreeBSD 6.2-STABLE #1: Mon Oct 15 16:53:04

asr0@pci3:3:0:  class=0x010400 card=0xc0341044 chip=0xa5111044 rev=0x01 
hdr=0x00
    vendor     = 'Adaptec (Formerly: Distributed Processing Technology 
(DPT))'  
    device     = 'Raptor SmartRAID Controller'                                  
    class      = mass storage                                                   
    subclass   = RAID                                                           

root:# camcontrol tags da0
(pass0:asr0:0:0:0): device openings: 255


On Monday 16 February 2009, Scott Long wrote:
> FWI.  I need lots of testing on this.  Only real SCSI controllers, 
> please, not RAID controllers (except for MPT-SCSI with integrated 
> mirroring).  So Adaptec, LSI, Symbios, Buslogic, Tekram, SME, etc,
> users, please try this and get back to me.  The patch should apply
> to FreeBSD 7 as well.  FreeBSD 6 is only affected by this problem
> when CAM_NEW_TRAN_CODE is enabled.
> 
> Scott
> 
> 
> -------- Original Message --------
> Subject: svn commit: r188671 - head/sys/cam
> Date: Mon, 16 Feb 2009 14:57:15 +0000 (UTC)
> From: Scott Long <scottl@FreeBSD.org>
> To: src-committers@FreeBSD.org, svn-src-all@FreeBSD.org, 
> svn-src-head@FreeBSD.org
> 
> Author: scottl
> Date: Mon Feb 16 14:57:15 2009
> New Revision: 188671
> URL: http://svn.freebsd.org/changeset/base/188671
> 
> Log:
>    Fix parallel SCSI negotiation in the CAM_NEW_TRAN_CODE world order.
>    Overzealous sanity checks were locking the sync_rate and offset values 
to
>    zero, thanks to a twisty maze of recursive code.
> 
> Modified:
>    head/sys/cam/cam_xpt.c
> 
> Modified: head/sys/cam/cam_xpt.c
> 
==============================================================================
> --- head/sys/cam/cam_xpt.c	Mon Feb 16 14:38:52 2009	(r188670)
> +++ head/sys/cam/cam_xpt.c	Mon Feb 16 14:57:15 2009	(r188671)
> @@ -6679,9 +6679,7 @@ xpt_set_transfer_settings(struct ccb_tra
>   		if (((device->flags & CAM_DEV_INQUIRY_DATA_VALID) != 0
>   		  && (inq_data->flags & SID_Sync) == 0
>   		  && cts->type == CTS_TYPE_CURRENT_SETTINGS)
> -		 || ((cpi.hba_inquiry & PI_SDTR_ABLE) == 0)
> -		 || (spi->sync_offset == 0)
> -		 || (spi->sync_period == 0)) {
> +		 || ((cpi.hba_inquiry & PI_SDTR_ABLE) == 0)) {
>   			/* Force async */
>   			spi->sync_period = 0;
>   			spi->sync_offset = 0;
> @@ -6729,7 +6727,8 @@ xpt_set_transfer_settings(struct ccb_tra
>   		if (spi->bus_width == 0)
>   			spi->ppr_options = 0;
> 
> -		if ((spi->flags & CTS_SPI_FLAGS_DISC_ENB) == 0) {
> +		if ((spi->valid & CTS_SPI_VALID_DISC)
> +		 && ((spi->flags & CTS_SPI_FLAGS_DISC_ENB) == 0)) {
>   			/*
>   			 * Can't tag queue without disconnection.
>   			 */
> _______________________________________________
> 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"
> 
> 



-- 
EMIT-RIPN, EVM7-RIPE
From gary.jennejohn at freenet.de  Tue Feb 17 07:42:08 2009
From: gary.jennejohn at freenet.de (Gary Jennejohn)
Date: Tue Feb 17 07:42:28 2009
Subject: HEADS UP: More CAM fixes.
In-Reply-To: <499981AF.9030204@samsco.org>
References: <499981AF.9030204@samsco.org>
Message-ID: <20090217164203.4c586f48@ernst.jennejohn.org>

On Mon, 16 Feb 2009 08:09:35 -0700
Scott Long <scottl@samsco.org> wrote:

> FWI.  I need lots of testing on this.  Only real SCSI controllers, 
> please, not RAID controllers (except for MPT-SCSI with integrated 
> mirroring).  So Adaptec, LSI, Symbios, Buslogic, Tekram, SME, etc,
> users, please try this and get back to me.  The patch should apply
> to FreeBSD 7 as well.  FreeBSD 6 is only affected by this problem
> when CAM_NEW_TRAN_CODE is enabled.
> 

I tested this with an Adaptec 29160.  I saw no real improvement in
performance, but also no regressions.

I suspect that the old disk I had attached just didn't have enough
performance reserves to show an improvement.

My test scenario was buildworld.  Since /usr/src and /usr/obj were both
on the one disk it got a pretty good workout.

AMD64 X2 (2.5 GHz) with 4GB of RAM.

BTW under a very fresh 8.0-current.

---
Gary Jennejohn
From scottl at samsco.org  Tue Feb 17 08:04:54 2009
From: scottl at samsco.org (Scott Long)
Date: Tue Feb 17 08:05:01 2009
Subject: HEADS UP: More CAM fixes.
In-Reply-To: <200902171552.23287.eugene@imedia.ru>
References: <499981AF.9030204@samsco.org> <200902171552.23287.eugene@imedia.ru>
Message-ID: <499AE01F.2080006@samsco.org>

Did the patch help?

Scott


Eugene Mitrofanov wrote:
> 7.1-STABLE FreeBSD 7.1-STABLE #3: Tue Feb 17 14:58:42
> asr0@pci0:3:3:0: class=0x010400 card=0xc0341044 chip=0xa5111044 rev=0x01 
> hdr=0x00
>     vendor     = 'Adaptec (Formerly: Distributed Processing Technology 
> (DPT))'
>     device     = 'Raptor SmartRAID Controller'
>     class      = mass storage
>     subclass   = RAID
> 
> root:# camcontrol tags da0
> (pass0:asr0:0:0:0): device openings: 1
> 
> ---------
> 
> 6.2-STABLE FreeBSD 6.2-STABLE #1: Mon Oct 15 16:53:04
> 
> asr0@pci3:3:0:  class=0x010400 card=0xc0341044 chip=0xa5111044 rev=0x01 
> hdr=0x00
>     vendor     = 'Adaptec (Formerly: Distributed Processing Technology 
> (DPT))'  
>     device     = 'Raptor SmartRAID Controller'                                  
>     class      = mass storage                                                   
>     subclass   = RAID                                                           
> 
> root:# camcontrol tags da0
> (pass0:asr0:0:0:0): device openings: 255
> 
> 
> On Monday 16 February 2009, Scott Long wrote:
>> FWI.  I need lots of testing on this.  Only real SCSI controllers, 
>> please, not RAID controllers (except for MPT-SCSI with integrated 
>> mirroring).  So Adaptec, LSI, Symbios, Buslogic, Tekram, SME, etc,
>> users, please try this and get back to me.  The patch should apply
>> to FreeBSD 7 as well.  FreeBSD 6 is only affected by this problem
>> when CAM_NEW_TRAN_CODE is enabled.
>>
>> Scott
>>
>>
>> -------- Original Message --------
>> Subject: svn commit: r188671 - head/sys/cam
>> Date: Mon, 16 Feb 2009 14:57:15 +0000 (UTC)
>> From: Scott Long <scottl@FreeBSD.org>
>> To: src-committers@FreeBSD.org, svn-src-all@FreeBSD.org, 
>> svn-src-head@FreeBSD.org
>>
>> Author: scottl
>> Date: Mon Feb 16 14:57:15 2009
>> New Revision: 188671
>> URL: http://svn.freebsd.org/changeset/base/188671
>>
>> Log:
>>    Fix parallel SCSI negotiation in the CAM_NEW_TRAN_CODE world order.
>>    Overzealous sanity checks were locking the sync_rate and offset values 
> to
>>    zero, thanks to a twisty maze of recursive code.
>>
>> Modified:
>>    head/sys/cam/cam_xpt.c
>>
>> Modified: head/sys/cam/cam_xpt.c
>>
> ==============================================================================
>> --- head/sys/cam/cam_xpt.c	Mon Feb 16 14:38:52 2009	(r188670)
>> +++ head/sys/cam/cam_xpt.c	Mon Feb 16 14:57:15 2009	(r188671)
>> @@ -6679,9 +6679,7 @@ xpt_set_transfer_settings(struct ccb_tra
>>   		if (((device->flags & CAM_DEV_INQUIRY_DATA_VALID) != 0
>>   		  && (inq_data->flags & SID_Sync) == 0
>>   		  && cts->type == CTS_TYPE_CURRENT_SETTINGS)
>> -		 || ((cpi.hba_inquiry & PI_SDTR_ABLE) == 0)
>> -		 || (spi->sync_offset == 0)
>> -		 || (spi->sync_period == 0)) {
>> +		 || ((cpi.hba_inquiry & PI_SDTR_ABLE) == 0)) {
>>   			/* Force async */
>>   			spi->sync_period = 0;
>>   			spi->sync_offset = 0;
>> @@ -6729,7 +6727,8 @@ xpt_set_transfer_settings(struct ccb_tra
>>   		if (spi->bus_width == 0)
>>   			spi->ppr_options = 0;
>>
>> -		if ((spi->flags & CTS_SPI_FLAGS_DISC_ENB) == 0) {
>> +		if ((spi->valid & CTS_SPI_VALID_DISC)
>> +		 && ((spi->flags & CTS_SPI_FLAGS_DISC_ENB) == 0)) {
>>   			/*
>>   			 * Can't tag queue without disconnection.
>>   			 */
>> _______________________________________________
>> 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 racinej at mcmaster.ca  Tue Feb 17 09:38:48 2009
From: racinej at mcmaster.ca (Jeffrey Racine)
Date: Tue Feb 17 09:38:56 2009
Subject: FreeBSD 7.1 crashing on shutdown, halt etc.
Message-ID: <1234890933.21366.10.camel@pc-racine1.mcmaster.ca>

Hi.

My system is crashing when I log out (using gdm). I had posted to gnome but was 
just advised to post to x11, posted to x11 and was told this is a kernel bug. 
Many thanks for any all of your assistance. Backtrace is provided below.

Some system info:

FreeBSD pc-racine1.mcmaster.ca 7.1-RELEASE-p2 FreeBSD 7.1-RELEASE-p2  
#0: Mon Feb 16 12:06:34 EST 2009     root at pc-racine1.mcmaster.ca:/usr/ 
obj/usr/src/sys/OPTIPLEX  i386


Backtrace follows:

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:
<118>.
<118>Shutting down local daemons:
<118>.
<118>Writing entropy file:
<118>.
<118>.
<118>Feb 16 12:54:07 pc-racine1 syslogd: exiting on signal 15


Fatal trap 12: page fault while in kernel mode
cpuid = 0; apic id = 00
fault virtual address	= 0x188
fault code		= supervisor read, page not present
instruction pointer	= 0x20:0xc07b0564
stack pointer	        = 0x28:0xe7b89af8
frame pointer	        = 0x28:0xe7b89b10
code segment		= base 0x0, limit 0xfffff, type 0x1b
			= DPL 0, pres 1, def32 1, gran 1
processor eflags	= interrupt enabled, resume, IOPL = 3
current process		= 967 (Xorg)
trap number		= 12
panic: page fault
cpuid = 0
Uptime: 45s
Physical memory: 2025 MB
Dumping 105 MB: 90 74 58 42 26 10

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
Reading symbols from /boot/kernel/i915.ko...Reading symbols from /boot/ 
kernel/i915.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/i915.ko
Reading symbols from /boot/kernel/drm.ko...Reading symbols from /boot/ 
kernel/drm.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/drm.ko
#0  doadump () at pcpu.h:196
196	pcpu.h: No such file or directory.
	in pcpu.h
(kgdb) backtrace
#0  doadump () at pcpu.h:196
#1  0xc07be607 in boot (howto=260) at /usr/src/sys/kern/ 
kern_shutdown.c:418
#2  0xc07be8d9 in panic (fmt=Variable "fmt" is not available.
) at /usr/src/sys/kern/kern_shutdown.c:574
#3  0xc0ad0aec in trap_fatal (frame=0xe7b89ab8, eva=392) at /usr/src/ 
sys/i386/i386/trap.c:939
#4  0xc0ad0d70 in trap_pfault (frame=0xe7b89ab8, usermode=0, eva=392)  
at /usr/src/sys/i386/i386/trap.c:852
#5  0xc0ad172c in trap (frame=0xe7b89ab8) at /usr/src/sys/i386/i386/ 
trap.c:530
#6  0xc0ab759b in calltrap () at /usr/src/sys/i386/i386/exception.s:159
#7  0xc07b0564 in _mtx_lock_sleep (m=0xc52b5cc0, tid=3314965792,  
opts=0, file=0xc5a60953 "/usr/src/sys/modules/drm/i915/../../../dev/ 
drm/i915_irq.c",
     line=118) at /usr/src/sys/kern/kern_mutex.c:339
#8  0xc07b0a02 in _mtx_lock_flags (m=0xc52b5cc0, opts=0,  
file=0xc5a60953 "/usr/src/sys/modules/drm/i915/../../../dev/drm/ 
i915_irq.c", line=118)
     at /usr/src/sys/kern/kern_mutex.c:186
#9  0xc5a5f403 in i915_irq_wait (kdev=0xc562a700, cmd=Variable "cmd"  
is not available.
) at /usr/src/sys/modules/drm/i915/../../../dev/drm/i915_irq.c:117
#10 0xc5a6aa4a in drm_ioctl (kdev=0xc562a700, cmd=2147771461,  
data=0xc52bfc60 "\025\006", flags=67, p=0xc5965d20)
     at /usr/src/sys/modules/drm/drm/../../../dev/drm/drm_drv.c:911
#11 0xc07832a7 in giant_ioctl (dev=0xc562a700, cmd=2147771461,  
data=0xc52bfc60 "\025\006", fflag=67, td=0xc5965d20) at /usr/src/sys/ 
kern/kern_conf.c:408
#12 0xc074d4b7 in devfs_ioctl_f (fp=0xc5a2f474, com=2147771461,  
data=0xc52bfc60, cred=0xc5508e00, td=0xc5965d20) at /usr/src/sys/fs/ 
devfs/devfs_vnops.c:595
#13 0xc07f5565 in kern_ioctl (td=0xc5965d20, fd=9, com=2147771461,  
data=0xc52bfc60 "\025\006") at file.h:268
#14 0xc07f56c4 in ioctl (td=0xc5965d20, uap=0xe7b89cfc) at /usr/src/ 
sys/kern/sys_generic.c:570
#15 0xc0ad10c5 in syscall (frame=0xe7b89d38) at /usr/src/sys/i386/i386/ 
trap.c:1090
#16 0xc0ab7600 in Xint0x80_syscall () at /usr/src/sys/i386/i386/ 
exception.s:255
#17 0x00000033 in ?? ()
Previous frame inner to this frame (corrupt stack?)
(kgdb) quit


Professor J. S. Racine         Phone:  (905) 525 9140 x 23825
Department of Economics        FAX:    (905) 521-8232
McMaster University            e-mail: racinej at mcmaster.ca
1280 Main St. W.,Hamilton,     URL:
http://www.economics.mcmaster.ca/racine/
Ontario, Canada. L8S 4M4


From krassi at bulinfo.net  Tue Feb 17 09:48:31 2009
From: krassi at bulinfo.net (Krassimir Slavchev)
Date: Tue Feb 17 09:48:39 2009
Subject: Booting 7.1-STABLE on supermicro 5015-MF (PDSMI+)
Message-ID: <499AF864.9010506@bulinfo.net>

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

Hello All,

It boots 7.1-RELEASE from the CDROM just fine but when boots from an IDE
disk it crashes right after loading the kernel:

http://mnemonic.bulinfo.net/~krassi/crash/supermicro_crash.jpg

Booting from the USB produces exactly the same crash. I know that the
BIOS of this board is buggy although it is latest.
I am curious why it boots from the CDROM but cannot boots from the IDE
disk. I just disconnect the CDROM and connect the IDE disk. The same IDE
disk boots fine on other hardware. I have tried with 7.1-PRERELEASE
which is 2-3 months older than 7.1-RELEASE and it crashes in same way.


Any ideas what may be wrong?

Best regards
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (FreeBSD)

iD8DBQFJmvhkxJBWvpalMpkRAmsAAJ4wh51lvt+nxllhCt69szOusEspuwCfU7ew
TemmPRvVnGp68byH0I4d9lI=
=Md6S
-----END PGP SIGNATURE-----
From brde at optusnet.com.au  Tue Feb 17 12:43:07 2009
From: brde at optusnet.com.au (Bruce Evans)
Date: Tue Feb 17 12:43:15 2009
Subject: HEADS UP: More CAM fixes.
In-Reply-To: <20090217164203.4c586f48@ernst.jennejohn.org>
References: <499981AF.9030204@samsco.org>
	<20090217164203.4c586f48@ernst.jennejohn.org>
Message-ID: <20090218073542.E5200@delplex.bde.org>

On Tue, 17 Feb 2009, Gary Jennejohn wrote:

> I tested this with an Adaptec 29160.  I saw no real improvement in
> performance, but also no regressions.
>
> I suspect that the old disk I had attached just didn't have enough
> performance reserves to show an improvement.
>
> My test scenario was buildworld.  Since /usr/src and /usr/obj were both
> on the one disk it got a pretty good workout.
                                   ^^^^ low
>
> AMD64 X2 (2.5 GHz) with 4GB of RAM.

Buildworld hardly uses the disk at all.  It reads and writes a few hundred
MB.  Ideally the i/o should go at disk speeds of 50-200MB/S and thus take
between 20 and 5 seconds.  In practice, it will take a few more seconds.
physically but perhaps even less virtually due to parallelism.

Bruce
From scottl at samsco.org  Tue Feb 17 12:46:30 2009
From: scottl at samsco.org (Scott Long)
Date: Tue Feb 17 12:46:48 2009
Subject: HEADS UP: More CAM fixes.
In-Reply-To: <20090218073542.E5200@delplex.bde.org>
References: <499981AF.9030204@samsco.org>
	<20090217164203.4c586f48@ernst.jennejohn.org>
	<20090218073542.E5200@delplex.bde.org>
Message-ID: <499B221C.2050804@samsco.org>

Bruce Evans wrote:
> On Tue, 17 Feb 2009, Gary Jennejohn wrote:
> 
>> I tested this with an Adaptec 29160.  I saw no real improvement in
>> performance, but also no regressions.
>>
>> I suspect that the old disk I had attached just didn't have enough
>> performance reserves to show an improvement.
>>
>> My test scenario was buildworld.  Since /usr/src and /usr/obj were both
>> on the one disk it got a pretty good workout.
>                                   ^^^^ low
>>
>> AMD64 X2 (2.5 GHz) with 4GB of RAM.
> 
> Buildworld hardly uses the disk at all.  It reads and writes a few hundred
> MB.  Ideally the i/o should go at disk speeds of 50-200MB/S and thus take
> between 20 and 5 seconds.  In practice, it will take a few more seconds.
> physically but perhaps even less virtually due to parallelism.
> 
> Bruce

Yes, on modern machines, buildworld is bound almost completely by disk
latency, and not at all by disk or controller bandwidth.

Scott

From royce at alaska.net  Tue Feb 17 13:11:27 2009
From: royce at alaska.net (Royce Williams)
Date: Tue Feb 17 13:11:35 2009
Subject: Booting 7.1-STABLE on supermicro 5015-MF (PDSMI+)
In-Reply-To: <499AF864.9010506@bulinfo.net>
References: <499AF864.9010506@bulinfo.net>
Message-ID: <499AFE8F.3080207@alaska.net>

Krassimir Slavchev wrote, on 2/17/2009 8:48 AM:
> It boots 7.1-RELEASE from the CDROM just fine but when boots from an IDE
> disk it crashes right after loading the kernel:
> 
> http://mnemonic.bulinfo.net/~krassi/crash/supermicro_crash.jpg
> 
> Booting from the USB produces exactly the same crash. I know that the
> BIOS of this board is buggy although it is latest.
> I am curious why it boots from the CDROM but cannot boots from the IDE
> disk. I just disconnect the CDROM and connect the IDE disk. The same IDE
> disk boots fine on other hardware. I have tried with 7.1-PRERELEASE
> which is 2-3 months older than 7.1-RELEASE and it crashes in same way.

I see from the phot that you're running a custom kernel.  What's 
different between that kernel and GENERIC?

Data point:  I'm running 7.1-RELEASE, installed from CD, on a PDSMI+ 
board, but I am booting from SATA.  This may help to rule out possible 
non-IDE issues.

I'm tracking with freebsd-update(8), but there have been no 
kernel updates yet.  It's a fresh install with no kernel or sysctl 
tuning, and hasn't taken any load yet.

$ uptime
10:02AM  up 10 days, 18:50, 1 user, load averages: 0.00, 0.00, 0.00

$ uname -a
FreeBSD dragonfly.acsalaska.net 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

$ cat /var/run/dmesg.boot
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 #0: Thu Jan  1 14:37:25 UTC 2009
    root@logan.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC
Timecounter "i8254" frequency 1193182 Hz quality 0
CPU: Intel(R) Core(TM)2 CPU          6600  @ 2.40GHz (2394.01-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=0x20100000<NX,LM>
  AMD Features2=0x1<LAHF>
  Cores per package: 2
real memory  = 3756916736 (3582 MB)
avail memory = 3672895488 (3502 MB)
ACPI APIC Table: <PTLTD          APIC  >
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
ioapic1 <Version 2.0> irqs 24-47 on motherboard
kbd1 at kbdmux0
ath_hal: 0.9.20.3 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413)
acpi0: <PTLTD   RSDT> 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 0x1008-0x100b 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
pcib2: <ACPI PCI-PCI bridge> irq 17 at device 28.0 on pci0
pci9: <ACPI PCI bus> on pcib2
pcib3: <ACPI PCI-PCI bridge> at device 0.0 on pci9
pci10: <ACPI PCI bus> on pcib3
pcib4: <ACPI PCI-PCI bridge> irq 17 at device 28.4 on pci0
pci13: <ACPI PCI bus> on pcib4
em0: <Intel(R) PRO/1000 Network Connection 6.9.6> port 0x4000-0x401f mem 0xe0200000-0xe021ffff irq 16 at device 0.0 on pci13
em0: Using MSI interrupt
em0: [FILTER]
em0: Ethernet address: 00:30:48:8d:30:74
pcib5: <ACPI PCI-PCI bridge> irq 16 at device 28.5 on pci0
pci14: <ACPI PCI bus> on pcib5
em1: <Intel(R) PRO/1000 Network Connection 6.9.6> port 0x5000-0x501f mem 0xe0300000-0xe031ffff irq 17 at device 0.0 on pci14
em1: Using MSI interrupt
em1: [FILTER]
em1: Ethernet address: 00:30:48:8d:30:75
uhci0: <UHCI (generic) USB controller> port 0x3000-0x301f 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 0x3020-0x303f 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
uhci2: <UHCI (generic) USB controller> port 0x3040-0x305f irq 18 at device 29.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
uhci3: <UHCI (generic) USB controller> port 0x3060-0x307f irq 16 at device 29.3 on pci0
uhci3: [GIANT-LOCKED]
uhci3: [ITHREAD]
usb3: <UHCI (generic) USB controller> on uhci3
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
ehci0: <Intel 82801GB/R (ICH7) USB 2.0 controller> mem 0xe0000000-0xe00003ff irq 23 at device 29.7 on pci0
ehci0: [GIANT-LOCKED]
ehci0: [ITHREAD]
usb4: EHCI version 1.0
usb4: companion controllers, 2 ports each: usb0 usb1 usb2 usb3
usb4: <Intel 82801GB/R (ICH7) USB 2.0 controller> on ehci0
usb4: USB revision 2.0
uhub4: <Intel EHCI root hub, class 9/0, rev 2.00/1.00, addr 1> on usb4
uhub4: 8 ports with 8 removable, self powered
pcib6: <ACPI PCI-PCI bridge> at device 30.0 on pci0
pci15: <ACPI PCI bus> on pcib6
vgapci0: <VGA-compatible display> port 0x6000-0x60ff mem 0xe8000000-0xefffffff,0xe0400000-0xe040ffff irq 16 at device 0.0 on pci15
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,0x30a0-0x30af at device 31.1 on pci0
ata0: <ATA channel 0> on atapci0
ata0: [ITHREAD]
ata1: <ATA channel 1> on atapci0
ata1: [ITHREAD]
atapci1: <Intel ICH7 SATA300 controller> port 0x30e8-0x30ef,0x30dc-0x30df,0x30e0-0x30e7,0x30d8-0x30db,0x30b0-0x30bf mem 0xe0000400-0xe00007ff 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: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0
sio0: type 16550A, console
sio0: [FILTER]
sio1: <16550A-compatible COM port> port 0x2f8-0x2ff irq 3 on acpi0
sio1: type 16550A
sio1: [FILTER]
fdc0: <floppy drive controller> port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on acpi0
fdc0: does not respond
device_attach: fdc0 attach returned 6
cpu0: <ACPI CPU> on acpi0
est0: <Enhanced SpeedStep Frequency Control> on cpu0
est: CPU supports Enhanced Speedstep, but is not recognized.
est: cpu_vendor GenuineIntel, msr 921092106000921
device_attach: est0 attach returned 6
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 921092106000921
device_attach: est1 attach returned 6
p4tcc1: <CPU Frequency Thermal Control> on cpu1
fdc0: <floppy drive controller> port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on acpi0
fdc0: does not respond
device_attach: fdc0 attach returned 6
pmtimer0 on isa0
orm0: <ISA Option ROMs> at iomem 0xc0000-0xcafff,0xcb000-0xcbfff,0xcc000-0xccfff 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]
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/9 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>
vga0: <Generic ISA VGA> at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0
Timecounters tick every 1.000 msec
acd0: CDROM <CD-224E/1.9A> at ata0-master UDMA33
ad4: 238475MB <Seagate ST3250820AS 3.AAE> at ata2-master SATA150
ad6: 238475MB <Seagate ST3250820AS 3.AAE> at ata3-master SATA150
SMP: AP CPU #1 Launched!
Trying to mount root from ufs:/dev/ad4s1a
$

Royce
From mike at sentex.net  Tue Feb 17 14:05:26 2009
From: mike at sentex.net (Mike Tancsa)
Date: Tue Feb 17 14:05:34 2009
Subject: HEADS UP: Major CAM performance regression
In-Reply-To: <20090217075742.GA69308@onelab2.iet.unipi.it>
References: <499551B9.7050805@samsco.org> <gn3ssi$j1r$1@ger.gmane.org>
	<4995DFE5.1020205@samsco.org>
	<9bbcef730902131421r53efa13dq371658888747f387@mail.gmail.com>
	<4996D635.3000802@samsco.org>
	<20090217075742.GA69308@onelab2.iet.unipi.it>
Message-ID: <200902172205.n1HM5IUf022092@pyroxene.sentex.ca>

At 02:57 AM 2/17/2009, Luigi Rizzo wrote:
>On Sat, Feb 14, 2009 at 07:33:25AM -0700, Scott Long wrote:
>...
> > >I'll try your suggestion if you have one.
> >
> > I don't have a magic universal testing suite in my back pocket, sorry.
> > You need to look at your expected workload and develop tests to simulate
> > it.  When I do testing during driver development, I try a lot of
> > different parallel, sequential, large i/o, and small i/o combinations.
>
>i just committed a port sysutils/fio that perhaps can help testing
>IO performance with various patterns.

Hi,
         Do you have any suggestions as to what tests to run with fio ?

Am I right in assuming that the Areca is hit by this bug ?

0[releng7]# camcontrol tags da0
(pass0:arcmsr0:0:0:0): device openings: 1
0[releng7]#

         ---Mike 

From jhb at freebsd.org  Tue Feb 17 14:23:38 2009
From: jhb at freebsd.org (John Baldwin)
Date: Tue Feb 17 14:23:45 2009
Subject: Error compiling FreeBSD-Stable with MFC'ed iconv locking
In-Reply-To: <4996C16D.8050909@web.de>
References: <4996C16D.8050909@web.de>
Message-ID: <200902171042.26151.jhb@freebsd.org>

On Saturday 14 February 2009 8:04:45 am Jens Rehsack wrote:
> Hi John,
> 
> after I updated my system (-STABLE) I received following compilation error
> while building the kernel (having ICONV built in):
> 
> cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -march=nocona
> -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes
> -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual  -Wundef
> -Wno-pointer-sign -fformat-extensions -nostdinc  -I. -I/usr/src/sys
> -I/usr/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include
> opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100
> --param large-function-growth=1000  -fno-omit-frame-pointer -mcmodel=kernel
> -mno-red-zone  -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow
> -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -Werror
> /usr/src/sys/libkern/iconv.c
> /usr/src/sys/libkern/iconv.c: In function 'iconv_mod_unload':
> /usr/src/sys/libkern/iconv.c:92: error: 'curthread' undeclared (first use in
> this function)
> /usr/src/sys/libkern/iconv.c:92: error: (Each undeclared identifier is
> reported only once
> /usr/src/sys/libkern/iconv.c:92: error: for each function it appears in.)
> /usr/src/sys/libkern/iconv.c: In function 'iconv_sysctl_add':
> /usr/src/sys/libkern/iconv.c:401: error: 'curthread' undeclared (first use
> in this function)
> /usr/src/sys/libkern/iconv.c: In function 'iconv_converter_handler':
> /usr/src/sys/libkern/iconv.c:452: error: 'curthread' undeclared (first use
> in this function)
> 
> I applied following patch - and it works:
> --- sys/sys/sx.h.orig	2009-02-14 12:56:11.000000000 +0000
> +++ sys/sys/sx.h	2009-02-14 12:57:33.000000000 +0000
> @@ -35,6 +35,7 @@
>  #include <sys/_lock.h>
>  #include <sys/_sx.h>
>  #include <sys/lock_profile.h>
> +#include <sys/proc.h>
> 
>  #ifdef	_KERNEL
>  #include <machine/atomic.h>
> 
> Google didn't find anything so I thought I mail this quickly.

The most recent commit to <sys/sx.h> to include <sys/pcpu.h> in the _KERNEL 
section should fix this.

-- 
John Baldwin
From mike at sentex.net  Tue Feb 17 15:07:07 2009
From: mike at sentex.net (Mike Tancsa)
Date: Tue Feb 17 15:07:19 2009
Subject: HEADS UP: Major CAM performance regression
In-Reply-To: <499551B9.7050805@samsco.org>
References: <499551B9.7050805@samsco.org>
Message-ID: <200902172307.n1HN74ml025580@pyroxene.sentex.ca>

At 05:55 AM 2/13/2009, Scott Long wrote:

>If, instead, it reports a value of '1', you are likely affected.  Note
>that it may be normal for USB memory devices to report a low number.
>Also, many legacy SCSI disks, and devices that are not disks, may 
>also be expected to report a low number.

Hi Scott,
         I tested with the patch on my areca controller, and it still 
reports 1 post patch.  (On RELENG_6, it shows 255 with the same controller)

         ---Mike


From cm at therek.net  Tue Feb 17 15:09:29 2009
From: cm at therek.net (Cezary Morga)
Date: Tue Feb 17 15:09:37 2009
Subject: FreeBSD 7.1 crashing on shutdown, halt etc.
Message-ID: <200902172344.31510.cm@therek.net>

I've got a similar problem here with source code csuped today.

kgdb output:
Unread portion of the kernel message buffer:
<118>Feb 17 20:59:17 frameshift syslogd: exiting on signal 15
Waiting (max 60 seconds) for system process `vnlru' to stop...done
Waiting (max 60 seconds) for system process `bufdaemon' to stop...done
Waiting (max 60 seconds) for system process `syncer' to stop...
Syncing disks, vnodes remaining...1 1 0 0 0 done
All buffers synced.


Fatal trap 12: page fault while in kernel mode
cpuid = 0; apic id = 00
fault virtual address   = 0xc
fault code              = supervisor write, page not present
instruction pointer     = 0x20:0xc54cd387
stack pointer           = 0x28:0xe9b73a60
frame pointer           = 0x28:0xe9b73a7c
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         = 1238 (halt)
trap number             = 12
panic: page fault
cpuid = 0
Uptime: 40s
Physical memory: 1387 MB
Dumping 92 MB: 77 61 45 29 13

Reading symbols from /boot/kernel/snd_hda.ko...Reading symbols 
from /boot/kernel/snd_hda.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/snd_hda.ko
Reading symbols from /boot/kernel/sound.ko...Reading symbols 
from /boot/kernel/sound.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/sound.ko
Reading symbols from /boot/modules/bcmwl5_sys.ko...done.
Loaded symbols for /boot/modules/bcmwl5_sys.ko
Reading symbols from /boot/kernel/ndis.ko...Reading symbols 
from /boot/kernel/ndis.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/ndis.ko
Reading symbols from /boot/kernel/if_ndis.ko...Reading symbols 
from /boot/kernel/if_ndis.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/if_ndis.ko
Reading symbols from /boot/modules/nvidia.ko...done.
Loaded symbols for /boot/modules/nvidia.ko
Reading symbols from /boot/kernel/linux.ko...Reading symbols 
from /boot/kernel/linux.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/linux.ko
Reading symbols from /boot/kernel/atapicam.ko...Reading symbols 
from /boot/kernel/atapicam.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/atapicam.ko
Reading symbols from /boot/modules/sdmmc.ko...done.
Loaded symbols for /boot/modules/sdmmc.ko
Reading symbols from /boot/kernel/dtraceall.ko...Reading symbols 
from /boot/kernel/dtraceall.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/dtraceall.ko
Reading symbols from /boot/kernel/cyclic.ko...Reading symbols 
from /boot/kernel/cyclic.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/cyclic.ko
Reading symbols from /boot/kernel/opensolaris.ko...Reading symbols 
from /boot/kernel/opensolaris.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/opensolaris.ko
Reading symbols from /boot/kernel/dtrace.ko...Reading symbols 
from /boot/kernel/dtrace.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/dtrace.ko
Reading symbols from /boot/kernel/dtmalloc.ko...Reading symbols 
from /boot/kernel/dtmalloc.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/dtmalloc.ko
Reading symbols from /boot/kernel/fbt.ko...Reading symbols 
from /boot/kernel/fbt.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/fbt.ko
Reading symbols from /boot/kernel/sdt.ko...Reading symbols 
from /boot/kernel/sdt.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/sdt.ko
Reading symbols from /boot/kernel/systrace.ko...Reading symbols 
from /boot/kernel/systrace.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/systrace.ko
Reading symbols from /boot/kernel/profile.ko...Reading symbols 
from /boot/kernel/profile.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/profile.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/zfs.ko...Reading symbols 
from /boot/kernel/zfs.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/zfs.ko
#0  doadump () at pcpu.h:196
196     pcpu.h: No such file or directory.
        in pcpu.h
(kgdb) backtrace
#0  doadump () at pcpu.h:196
#1  0xc079de57 in boot (howto=260) 
at /usr/src/sys/kern/kern_shutdown.c:418
#2  0xc079e129 in panic (fmt=Variable "fmt" is not available.
) at /usr/src/sys/kern/kern_shutdown.c:574
#3  0xc0ac070c in trap_fatal (frame=0xe9b73a20, eva=12) 
at /usr/src/sys/i386/i386/trap.c:939
#4  0xc0ac0990 in trap_pfault (frame=0xe9b73a20, usermode=0, eva=12) 
at /usr/src/sys/i386/i386/trap.c:852
#5  0xc0ac13dc in trap (frame=0xe9b73a20) 
at /usr/src/sys/i386/i386/trap.c:530
#6  0xc0aa70db in calltrap () at /usr/src/sys/i386/i386/exception.s:159
#7  0xc54cd387 in gfs_dir_create () from /boot/kernel/zfs.ko
Previous frame inner to this frame (corrupt stack?)

-- 
Cezary Morga
"The Bible tells us to love our neighbors, and also to love our enemies; 
probably because they are generally the same people." (G. K. 
Chesterton)
From killing at multiplay.co.uk  Tue Feb 17 17:03:55 2009
From: killing at multiplay.co.uk (Steven Hartland)
Date: Tue Feb 17 17:04:08 2009
Subject: HEADS UP: Major CAM performance regression
References: <499551B9.7050805@samsco.org>
	<200902172307.n1HN74ml025580@pyroxene.sentex.ca>
Message-ID: <36F6FB422621418CA51378C8F3F49ADA@multiplay.co.uk>

This is also the case with 7.0-RELEASE on areca. We have a machine here
which literally grinds to a half every time we run our rrd updates, so
may be a good test case here if we can fix that ;-)

    Regards
    Steve

----- Original Message ----- 
From: "Mike Tancsa" <mike@sentex.net>
To: "Scott Long" <scottl@samsco.org>; "FreeBSD Current" <freebsd-current@freebsd.org>; "FreeBSD Stable" 
<freebsd-stable@freebsd.org>
Sent: Tuesday, February 17, 2009 11:06 PM
Subject: Re: HEADS UP: Major CAM performance regression


> At 05:55 AM 2/13/2009, Scott Long wrote:
>
>>If, instead, it reports a value of '1', you are likely affected.  Note
>>that it may be normal for USB memory devices to report a low number.
>>Also, many legacy SCSI disks, and devices that are not disks, may also be expected to report a low number.
>
> Hi Scott,
>         I tested with the patch on my areca controller, and it still reports 1 post patch.  (On RELENG_6, it shows 255 with the 
> same controller)
>
>         ---Mike
>
>
> _______________________________________________
> freebsd-current@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"
> 


================================================
This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. 

In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337
or return the E.mail to postmaster@multiplay.co.uk.

From mike at sentex.net  Tue Feb 17 17:10:41 2009
From: mike at sentex.net (Mike Tancsa)
Date: Tue Feb 17 17:10:48 2009
Subject: Big problems with 7.1 locking up :-(
In-Reply-To: <alpine.BSF.2.00.0901292234430.30840@fledge.watson.org>
References: <E1LL6dg-0007CN-DI@dilbert.ticketswitch.com>
	<alpine.BSF.2.00.0901292234430.30840@fledge.watson.org>
Message-ID: <200902180110.n1I1AaPL031693@pyroxene.sentex.ca>

At 05:38 PM 1/29/2009, Robert Watson wrote:

>On Fri, 9 Jan 2009, Pete French wrote:
>
>>I have a number of HP 1U servers, all of which were running 7.0 
>>perfectly happily. I have been testing 7.1 in it's various 
>>incarnations for the last couple of months on our test server and 
>>it has performed perfectly.
>>
>>So the last two days I have been round upgrading all our servers, 
>>knowing that I had run the system stably on identical hardware for some time.
>
>For those following this other than Pete, who I've been in private 
>correspondence with: it seems that he is running into two different 
>deadlocks in the routing code.  One of them (at least) is triggered 
>by a lock order problem relating to the processing of ICMP redirects 
>-- uncommon in most configurations, but quite a few on his network, 
>which triggers quickly under load.  Kip Macy has corrected at least 
>one (both?) problems in head, and plans to MFC the fixes in the near 
>future.  We'll follow up further once the fixes are merged, and if 
>any further problems transpire.

Hi Robert,
         Do you have any other details about these issues ? Were the 
fixes ever MFC'd

         ---Mike 

From dougb at FreeBSD.org  Tue Feb 17 17:54:24 2009
From: dougb at FreeBSD.org (Doug Barton)
Date: Tue Feb 17 17:54:31 2009
Subject: 7-stable kernel not compiling: nlm_prot_impl.c "undefined reference
 to `nfs_*"
Message-ID: <499B6A51.8020704@FreeBSD.org>

With up to date sources buildworld completes, but kernel fails here:

linking kernel.debug
nlm_advlock.o(.text+0x11a8): In function `nlm_advlock_internal':
/data/src/sys/nlm/nlm_advlock.c:225: undefined reference to
`nfs_vinvalbuf'
nlm_advlock.o(.text+0x1243):/data/src/sys/nlm/nlm_advlock.c:236:
undefined reference to `nfs_ticks'
nlm_prot_impl.o(.text+0x2af1): In function `nlm_syscall':
/data/src/sys/nlm/nlm_prot_impl.c:1543: undefined reference to
`nfs_advlock_p'
nlm_prot_impl.o(.text+0x2af7):/data/src/sys/nlm/nlm_prot_impl.c:1544:
undefined reference to `nfs_advlock_p'
nlm_prot_impl.o(.text+0x2b01):/data/src/sys/nlm/nlm_prot_impl.c:1545:
undefined reference to `nfs_reclaim_p'
nlm_prot_impl.o(.text+0x2b07):/data/src/sys/nlm/nlm_prot_impl.c:1546:
undefined reference to `nfs_reclaim_p'
nlm_prot_impl.o(.text+0x2b1f):/data/src/sys/nlm/nlm_prot_impl.c:1551:
undefined reference to `nfs_advlock_p'
nlm_prot_impl.o(.text+0x2b25):/data/src/sys/nlm/nlm_prot_impl.c:1552:
undefined reference to `nfs_reclaim_p'
*** Error code 1

Stop in /usr/local/obj/data/src/sys/HOME.
*** Error code 1


-- 

    This .signature sanitized for your protection
From steve at mouf.net  Tue Feb 17 18:25:13 2009
From: steve at mouf.net (Steve Wills)
Date: Tue Feb 17 18:25:45 2009
Subject: unionfs panic in 7.1
Message-ID: <95E82F15-2535-4C67-BDF0-44CFC7EB9FBB@mouf.net>

Hi,

I've found an reproducable panic in unionfs on 7.1-R.

/usr/src/sys/fs/unionfs/union_subr.c is:
      $FreeBSD: src/sys/fs/unionfs/union_subr.c,v 1.92.2.7.2.2  
2008/12/15 03:58:55 daichi Exp $

kgdb output is below.

kgdb /boot/kernel/kernel.symbols /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 "amd64-marcel-freebsd"...

Unread portion of the kernel message buffer:

stack pointer	        = 0x10:0xffffffffb0e1a8b0
frame pointer	        = 0x10:0xffffffffb0e1a8d0
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		= 72036 (make)
panic: from debugger
cpuid = 0
Uptime: 49m32s
Physical memory: 2034 MB
Dumping 441 MB: 426 410 394 378 362 346 330 314 298 282 266 250 234  
218 202 186 170 154 138 122 106 90 74 58 42 26 10

Reading symbols from /boot/kernel/if_tap.ko...Reading symbols from / 
boot/kernel/if_tap.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/if_tap.ko
Reading symbols from /boot/kernel/snd_hda.ko...Reading symbols from / 
boot/kernel/snd_hda.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/snd_hda.ko
Reading symbols from /boot/kernel/sound.ko...Reading symbols from / 
boot/kernel/sound.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/sound.ko
Reading symbols from /boot/kernel/atapicam.ko...Reading symbols from / 
boot/kernel/atapicam.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/atapicam.ko
Reading symbols from /boot/kernel/smb.ko...Reading symbols from /boot/ 
kernel/smb.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/smb.ko
Reading symbols from /boot/kernel/smbus.ko...Reading symbols from / 
boot/kernel/smbus.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/smbus.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
Reading symbols from /boot/kernel/zfs.ko...Reading symbols from /boot/ 
kernel/zfs.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/zfs.ko
Reading symbols from /boot/kernel/opensolaris.ko...Reading symbols  
from /boot/kernel/opensolaris.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/opensolaris.ko
Reading symbols from /boot/kernel/if_bridge.ko...Reading symbols from / 
boot/kernel/if_bridge.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/if_bridge.ko
Reading symbols from /boot/kernel/bridgestp.ko...Reading symbols from / 
boot/kernel/bridgestp.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/bridgestp.ko
Reading symbols from /usr/local/modules/fuse.ko...done.
Loaded symbols for /usr/local/modules/fuse.ko
Reading symbols from /boot/kernel/radeon.ko...Reading symbols from / 
boot/kernel/radeon.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/radeon.ko
Reading symbols from /boot/kernel/drm.ko...Reading symbols from /boot/ 
kernel/drm.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/drm.ko
Reading symbols from /boot/kernel/unionfs.ko...Reading symbols from / 
boot/kernel/unionfs.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/unionfs.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
#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  0xffffffff804c70a8 in boot (howto=260) at /usr/src/sys/kern/ 
kern_shutdown.c:418
#2  0xffffffff804c750c in panic (fmt=Variable "fmt" is not available.
) at /usr/src/sys/kern/kern_shutdown.c:574
#3  0xffffffff801c1707 in db_panic (addr=Variable "addr" is not  
available.
) at /usr/src/sys/ddb/db_command.c:446
#4  0xffffffff801c1d6f in db_command (last_cmdp=0xffffffff80aa6448,  
cmd_table=0x0, dopager=1) at /usr/src/sys/ddb/db_command.c:413
#5  0xffffffff801c1f80 in db_command_loop () at /usr/src/sys/ddb/ 
db_command.c:466
#6  0xffffffff801c3b69 in db_trap (type=Variable "type" is not  
available.
) at /usr/src/sys/ddb/db_main.c:228
#7  0xffffffff804f3955 in kdb_trap (type=12, code=0,  
tf=0xffffffffb0e1a800) at /usr/src/sys/kern/subr_kdb.c:524
#8  0xffffffff807a3180 in trap_fatal (frame=0xffffffffb0e1a800,  
eva=Variable "eva" is not available.
) at /usr/src/sys/amd64/amd64/trap.c:759
#9  0xffffffff807a3554 in trap_pfault (frame=0xffffffffb0e1a800,  
usermode=0) at /usr/src/sys/amd64/amd64/trap.c:680
#10 0xffffffff807a3eda in trap (frame=0xffffffffb0e1a800) at /usr/src/ 
sys/amd64/amd64/trap.c:449
#11 0xffffffff80788dde in calltrap () at /usr/src/sys/amd64/amd64/ 
exception.S:209
#12 0xffffffff804b9f0e in _mtx_lock_sleep (m=0xffffff006c384638,  
tid=18446742974280188784, opts=Variable "opts" is not available.
) at /usr/src/sys/kern/kern_mutex.c:339
#13 0xffffffff80555767 in vn_start_write (vp=0xffffff006c4983f0,  
mpp=Variable "mpp" is not available.
) at /usr/src/sys/kern/vfs_vnops.c:902
#14 0xffffffff805574a1 in vn_close (vp=0xffffff006c4983f0, flags=1,  
file_cred=0xffffff0015947500, td=0xffffff0004e74370) at /usr/src/sys/ 
kern/vfs_vnops.c:287
#15 0xffffffff80557589 in vn_closefile (fp=0xffffff006c020e00,  
td=0xffffff0004e74370) at /usr/src/sys/kern/vfs_vnops.c:867
#16 0xffffffff8049331f in fdrop (fp=0xffffff006c020e00,  
td=0xffffff0004e74370) at file.h:299
#17 0xffffffff80494579 in closef (fp=0xffffff006c020e00,  
td=0xffffff0004e74370) at /usr/src/sys/kern/kern_descrip.c:2033
#18 0xffffffff80494d5d in kern_close (td=0xffffff0004e74370,  
fd=Variable "fd" is not available.
) at /usr/src/sys/kern/kern_descrip.c:1125
#19 0xffffffff807a37d6 in syscall (frame=0xffffffffb0e1ac80) at /usr/ 
src/sys/amd64/amd64/trap.c:907
#20 0xffffffff80788feb in Xfast_syscall () at /usr/src/sys/amd64/amd64/ 
exception.S:330
#21 0x000000000044030c in ?? ()
Previous frame inner to this frame (corrupt stack?)
(kgdb) frame 12
#12 0xffffffff804b9f0e in _mtx_lock_sleep (m=0xffffff006c384638,  
tid=18446742974280188784, opts=Variable "opts" is not available.
) at /usr/src/sys/kern/kern_mutex.c:339
339				owner = (struct thread *)(v & ~MTX_FLAGMASK);
(kgdb) list
334			 * If the owner is running on another CPU, spin until the
335			 * owner stops running or the state of the lock changes.
336			 */
337			v = m->mtx_lock;
338			if (v != MTX_UNOWNED) {
339				owner = (struct thread *)(v & ~MTX_FLAGMASK);
340	#ifdef ADAPTIVE_GIANT
341				if (TD_IS_RUNNING(owner)) {
342	#else
343				if (m != &Giant && TD_IS_RUNNING(owner)) {
(kgdb) p v
$1 = 0
(kgdb) p m
$2 = (struct mtx *) 0xffffff006c384638
(kgdb) p *m
$3 = {lock_object = {lo_name = 0x0, lo_type = 0x0, lo_flags =  
1281410792, lo_witness_data = {lod_list = {stqe_next =  
0xffffff004c60c708},
       lod_witness = 0xffffff004c60c708}}, mtx_lock = 0, mtx_recurse =  
0}
(kgdb) frame 13
#13 0xffffffff80555767 in vn_start_write (vp=0xffffff006c4983f0,  
mpp=Variable "mpp" is not available.
) at /usr/src/sys/kern/vfs_vnops.c:902
902		MNT_ILOCK(mp);
(kgdb) list
897				return (0);
898			}
899		}
900		if ((mp = *mpp) == NULL)
901			return (0);
902		MNT_ILOCK(mp);
903		if (vp == NULL)
904			MNT_REF(mp);
905		/*
906		 * Check on status of suspension.
(kgdb) p mp
$4 = (struct mount *) 0xffffff006c3845e8
(kgdb) p *mp
$5 = {mnt_lock = {lk_object = {lo_name = 0x1 <Address 0x1 out of  
bounds>, lo_type = 0xffffffffb1029552 "unionfs", lo_flags =  
2969738112, lo_witness_data = {
         lod_list = {stqe_next = 0xffffff003c980000}, lod_witness =  
0xffffff003c980000}}, lk_interlock = 0xffffff0015d46378, lk_flags = 0,  
lk_sharecount = 0,
     lk_waitcount = 775638512, lk_exclusivecount = -256, lk_prio = -1,  
lk_timo = 0, lk_lockholder = 0x0, lk_newlock = 0x0}, mnt_mtx =  
{lock_object = {
       lo_name = 0x0, lo_type = 0x0, lo_flags = 1281410792,  
lo_witness_data = {lod_list = {stqe_next = 0xffffff004c60c708},  
lod_witness = 0xffffff004c60c708}},
     mtx_lock = 0, mtx_recurse = 0}, mnt_gen = 0, mnt_list = {tqe_next  
= 0x0, tqe_prev = 0x0}, mnt_op = 0xffffffffb1029552, mnt_vfc =  
0xffffffffb1029552,
   mnt_vnodecovered = 0x4390000, mnt_syncer = 0x0, mnt_ref =  
-2136101936, mnt_nvnodelist = {tqh_first = 0x80, tqh_last =  
0x50000000000000},
   mnt_nvnodelistsize = 51, mnt_writeopcount = 0, mnt_kern_flag = -1,  
mnt_flag = 4294967295, mnt_noasync = 0, mnt_opt = 0xffffffff8086e910,
   mnt_optnew = 0xffffffff8086e910, mnt_maxsymlinklen = 16973824,  
mnt_stat = {f_version = 0, f_type = 0, f_flags = 4, f_bsize = 0,
     f_iosize = 18446742976017063016, f_blocks = 4294967297, f_bfree =  
0, f_bavail = 0, f_files = 0, f_ffree = 0, f_syncwrites = 0,
     f_asyncwrites = 18446742976013551312, f_syncreads = 0,  
f_asyncreads = 18446742976013551424, f_spare = {0, 0, 0,  
18446742976013551456, 0, 0, 0, 0,
       18446744071572912256, 16384}, f_namemax = 784962992, f_owner =  
4294967040, f_fsid = {val = {0, 0}},
     f_charspare = "\000\000\000\000\000\000\000\000?E8l\000????E8l 
\000???", '\0' <repeats 24 times>,  
"\001\000\000\000\000\000\000\000\023\016\206\200????\2001? 
\200????Xy?l\000???", f_fstypename = "xsv\004\000????K8l 
\000???",
     f_mntfromname = "\030D8l\000???", '\0' <repeats 16 times>,  
"\200o\034\201?????L\003\003", '\0' <repeats 12 times>, "? 
\227\tJ\000?????`L\000???\000\000\000\000\000\000\000\000\b 
\000\000\000\000\000\000\000 \031L0\000\000\000",
     f_mntonname = "\a", '\0' <repeats 15 times>,  
"\023\016\206\200????\023\016\206\200????\000\0009\004", '\0'  
<repeats 12 times>, "?\230?\200????@", '\0' <repeats 13 times>,  
"P\0003\000\000\000\000\000\000\000????????"}, mnt_cred = 0x0,  
mnt_data = 0xffffffff8086e910, mnt_time = -2138642160, mnt_iosize_max  
= 16973824,
   mnt_export = 0x0, mnt_label = 0x4, mnt_hashseed = 0, mnt_markercnt  
= 0, mnt_holdcnt = 1815627896, mnt_holdcntwaiters = -256,  
mnt_secondary_writes = 10,
   mnt_secondary_accwrites = 0, mnt_gjprovider = 0x0, mnt_explock =  
{lk_object = {lo_name = 0x0, lo_type = 0x0, lo_flags = 0,  
lo_witness_data = {lod_list = {
           stqe_next = 0x0}, lod_witness = 0x0}}, lk_interlock =  
0xffffff006c3848c8, lk_flags = 2589843616, lk_sharecount = -1,  
lk_waitcount = -1707370640,
     lk_exclusivecount = -1, lk_prio = -1, lk_timo = -1707370720,  
lk_lockholder = 0x9, lk_newlock = 0x0}}
(kgdb)

I reproduce this by unionfs mounting a ports dir used by the ports  
tinderbox. If anyone would like more info, please let me know, I have  
the core around, and can reproduce, help debug, resend in case my  
mailer has mangled this, etc.

Thanks,
Steve

From Cy.Schubert at komquats.com  Tue Feb 17 22:11:31 2009
From: Cy.Schubert at komquats.com (Cy Schubert)
Date: Tue Feb 17 22:11:39 2009
Subject: ZFS Panic
Message-ID: <200902180543.n1I5hVDF072033@cwsys.cwsent.com>

I got this panic after issuing reboot(8).

FreeBSD  7.1-STABLE FreeBSD 7.1-STABLE #0: Tue Feb 17 19:29:23 PST 2009     
cy@cwsys:/export/obj/export/home/cy/test/test-stable7/sys/DEBUG  i386


FreeBSD/i386 (bob) (ttyd0)

login: Feb 17 21:22:56 bob reboot: rebooted by root
Feb 17 21:22:56 bob syslogd: exiting on signal 15
Waiting (max 60 seconds) for system process `vnlru' to stop...done
Waiting (max 60 seconds) for system process `syncer' to stop...
Syncing disks, vnodes remaining...2 2 2 2 1 1 1 1 0 0 0 0 0 0 done
Waiting (max 60 seconds) for system process `bufdaemon' to stop...done
All buffers synced.
panic: insmntque() failed: error 16
cpuid = 0
KDB: enter: panic
[thread pid 1086 tid 100090 ]
Stopped at      kdb_enter_why+0x3a:     movl    $0,kdb_why
db> bt
Tracing pid 1086 tid 100090 td 0xc2bfd230
kdb_enter_why(c087ef4a,c087ef4a,c2b1b5b4,ebf8da58,0,...) at 
kdb_enter_why+0x3a
panic(c2b1b5b4,10,c2b24a40,ebf8da64,c38e6000,...) at panic+0x136
gfs_file_create(84,c346d8a0,c342d5a0,c2b24a40,c346d8a0,...) at 
gfs_file_create+0x86
gfs_dir_create(84,c346d8a0,c342d5a0,c2b24a40,0,...) at gfs_dir_create+0x2c
zfsctl_mknode_snapdir(c346d8a0,c2b1b54f,275,25d,c3419520,...) at 
zfsctl_mknode_snapdir+0x53
gfs_dir_lookup(c346d8a0,c2b21126,ebf8db74,c091521c,ebf8db38,...) at 
gfs_dir_lookup+0xd1
zfsctl_root_lookup(c346d8a0,c2b21126,ebf8db74,0,0,...) at 
zfsctl_root_lookup+0xdc
zfsctl_umount_snapshots(c342d5a0,80000,c3acb800,c3216844,0,...) at 
zfsctl_umount_snapshots+0x4e
zfs_umount(c342d5a0,80000,c2bfd230,c2bfd230,c088a687,...) at zfs_umount+0x53
dounmount(c342d5a0,80000,c2bfd230,e26988ac,0,...) at dounmount+0x430
vfs_unmountall(c087ed87,0,c087edeb,128,0,...) at vfs_unmountall+0x4e
boot(c090b5d0,0,c087edeb,ab,ebf8dd2c,...) at boot+0x44f
reboot(c2bfd230,ebf8dcfc,4,c0885aef,c08c38a8,...) at reboot+0x4b
syscall(ebf8dd38) at syscall+0x2b3
Xint0x80_syscall() at Xint0x80_syscall+0x20
--- syscall (55, FreeBSD ELF32, reboot), eip = 0x280bc947, esp = 
0xbfbfeb7c, ebp = 0xbfbfebb8 ---
db> 

Forceably unmounting ZFS filesystems prior to issuing reboot(8) mitigates 
the panic.


-- 
Cheers,
Cy Schubert <Cy.Schubert@komquats.com>
FreeBSD UNIX:  <cy@FreeBSD.org>   Web:  http://www.FreeBSD.org

			e**(i*pi)+1=0


From eugene at imedia.ru  Tue Feb 17 22:21:39 2009
From: eugene at imedia.ru (Eugene Mitrofanov)
Date: Tue Feb 17 22:21:46 2009
Subject: HEADS UP: More CAM fixes.
In-Reply-To: <499AE01F.2080006@samsco.org>
References: <499981AF.9030204@samsco.org> <200902171552.23287.eugene@imedia.ru>
	<499AE01F.2080006@samsco.org>
Message-ID: <200902180921.34601.eugene@imedia.ru>

Hi Scott

Unfortunately, it did not.

On Tuesday 17 February 2009, Scott Long wrote:
> Did the patch help?
> 
> Scott
> 
> 
> Eugene Mitrofanov wrote:
> > 7.1-STABLE FreeBSD 7.1-STABLE #3: Tue Feb 17 14:58:42
> > asr0@pci0:3:3:0: class=0x010400 card=0xc0341044 chip=0xa5111044 rev=0x01 
> > hdr=0x00
> >     vendor     = 'Adaptec (Formerly: Distributed Processing Technology 
> > (DPT))'
> >     device     = 'Raptor SmartRAID Controller'
> >     class      = mass storage
> >     subclass   = RAID
> > 
> > root:# camcontrol tags da0
> > (pass0:asr0:0:0:0): device openings: 1
> > 
> > ---------
> > 
> > 6.2-STABLE FreeBSD 6.2-STABLE #1: Mon Oct 15 16:53:04
> > 
> > asr0@pci3:3:0:  class=0x010400 card=0xc0341044 chip=0xa5111044 rev=0x01 
> > hdr=0x00
> >     vendor     = 'Adaptec (Formerly: Distributed Processing Technology 
> > (DPT))'  
> >     device     = 'Raptor SmartRAID Controller'                                  
> >     class      = mass storage                                                   
> >     subclass   = RAID                                                           
> > 
> > root:# camcontrol tags da0
> > (pass0:asr0:0:0:0): device openings: 255
> > 
> > 
> > On Monday 16 February 2009, Scott Long wrote:
> >> FWI.  I need lots of testing on this.  Only real SCSI controllers, 
> >> please, not RAID controllers (except for MPT-SCSI with integrated 
> >> mirroring).  So Adaptec, LSI, Symbios, Buslogic, Tekram, SME, etc,
> >> users, please try this and get back to me.  The patch should apply
> >> to FreeBSD 7 as well.  FreeBSD 6 is only affected by this problem
> >> when CAM_NEW_TRAN_CODE is enabled.
> >>
> >> Scott
> >>
> >>
> >> -------- Original Message --------
> >> Subject: svn commit: r188671 - head/sys/cam
> >> Date: Mon, 16 Feb 2009 14:57:15 +0000 (UTC)
> >> From: Scott Long <scottl@FreeBSD.org>
> >> To: src-committers@FreeBSD.org, svn-src-all@FreeBSD.org, 
> >> svn-src-head@FreeBSD.org
> >>
> >> Author: scottl
> >> Date: Mon Feb 16 14:57:15 2009
> >> New Revision: 188671
> >> URL: http://svn.freebsd.org/changeset/base/188671
> >>
> >> Log:
> >>    Fix parallel SCSI negotiation in the CAM_NEW_TRAN_CODE world order.
> >>    Overzealous sanity checks were locking the sync_rate and offset 
values 
> > to
> >>    zero, thanks to a twisty maze of recursive code.
> >>
> >> Modified:
> >>    head/sys/cam/cam_xpt.c
> >>
> >> Modified: head/sys/cam/cam_xpt.c
> >>
> > 
==============================================================================
> >> --- head/sys/cam/cam_xpt.c	Mon Feb 16 14:38:52 2009	(r188670)
> >> +++ head/sys/cam/cam_xpt.c	Mon Feb 16 14:57:15 2009	(r188671)
> >> @@ -6679,9 +6679,7 @@ xpt_set_transfer_settings(struct ccb_tra
> >>   		if (((device->flags & CAM_DEV_INQUIRY_DATA_VALID) != 0
> >>   		  && (inq_data->flags & SID_Sync) == 0
> >>   		  && cts->type == CTS_TYPE_CURRENT_SETTINGS)
> >> -		 || ((cpi.hba_inquiry & PI_SDTR_ABLE) == 0)
> >> -		 || (spi->sync_offset == 0)
> >> -		 || (spi->sync_period == 0)) {
> >> +		 || ((cpi.hba_inquiry & PI_SDTR_ABLE) == 0)) {
> >>   			/* Force async */
> >>   			spi->sync_period = 0;
> >>   			spi->sync_offset = 0;
> >> @@ -6729,7 +6727,8 @@ xpt_set_transfer_settings(struct ccb_tra
> >>   		if (spi->bus_width == 0)
> >>   			spi->ppr_options = 0;
> >>
> >> -		if ((spi->flags & CTS_SPI_FLAGS_DISC_ENB) == 0) {
> >> +		if ((spi->valid & CTS_SPI_VALID_DISC)
> >> +		 && ((spi->flags & CTS_SPI_FLAGS_DISC_ENB) == 0)) {
> >>   			/*
> >>   			 * Can't tag queue without disconnection.
> >>   			 */
> >> _______________________________________________
> >> 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"
> >>
> >>
> > 
> > 
> > 
> 
> 



-- 
EMIT-RIPN, EVM7-RIPE
From ganbold at micom.mng.net  Tue Feb 17 22:51:58 2009
From: ganbold at micom.mng.net (Ganbold)
Date: Tue Feb 17 22:52:05 2009
Subject: ZFS Panic
In-Reply-To: <200902180543.n1I5hVDF072033@cwsys.cwsent.com>
References: <200902180543.n1I5hVDF072033@cwsys.cwsent.com>
Message-ID: <499BB006.8040105@micom.mng.net>

Cy Schubert wrote:
> I got this panic after issuing reboot(8).
>
> FreeBSD  7.1-STABLE FreeBSD 7.1-STABLE #0: Tue Feb 17 19:29:23 PST 2009     
> cy@cwsys:/export/obj/export/home/cy/test/test-stable7/sys/DEBUG  i386
>
>
> FreeBSD/i386 (bob) (ttyd0)
>
> login: Feb 17 21:22:56 bob reboot: rebooted by root
> Feb 17 21:22:56 bob syslogd: exiting on signal 15
> Waiting (max 60 seconds) for system process `vnlru' to stop...done
> Waiting (max 60 seconds) for system process `syncer' to stop...
> Syncing disks, vnodes remaining...2 2 2 2 1 1 1 1 0 0 0 0 0 0 done
> Waiting (max 60 seconds) for system process `bufdaemon' to stop...done
> All buffers synced.
> panic: insmntque() failed: error 16
> cpuid = 0
> KDB: enter: panic
> [thread pid 1086 tid 100090 ]
> Stopped at      kdb_enter_why+0x3a:     movl    $0,kdb_why
> db> bt
> Tracing pid 1086 tid 100090 td 0xc2bfd230
> kdb_enter_why(c087ef4a,c087ef4a,c2b1b5b4,ebf8da58,0,...) at 
> kdb_enter_why+0x3a
> panic(c2b1b5b4,10,c2b24a40,ebf8da64,c38e6000,...) at panic+0x136
> gfs_file_create(84,c346d8a0,c342d5a0,c2b24a40,c346d8a0,...) at 
> gfs_file_create+0x86
> gfs_dir_create(84,c346d8a0,c342d5a0,c2b24a40,0,...) at gfs_dir_create+0x2c
> zfsctl_mknode_snapdir(c346d8a0,c2b1b54f,275,25d,c3419520,...) at 
> zfsctl_mknode_snapdir+0x53
> gfs_dir_lookup(c346d8a0,c2b21126,ebf8db74,c091521c,ebf8db38,...) at 
> gfs_dir_lookup+0xd1
> zfsctl_root_lookup(c346d8a0,c2b21126,ebf8db74,0,0,...) at 
> zfsctl_root_lookup+0xdc
> zfsctl_umount_snapshots(c342d5a0,80000,c3acb800,c3216844,0,...) at 
> zfsctl_umount_snapshots+0x4e
> zfs_umount(c342d5a0,80000,c2bfd230,c2bfd230,c088a687,...) at zfs_umount+0x53
> dounmount(c342d5a0,80000,c2bfd230,e26988ac,0,...) at dounmount+0x430
> vfs_unmountall(c087ed87,0,c087edeb,128,0,...) at vfs_unmountall+0x4e
> boot(c090b5d0,0,c087edeb,ab,ebf8dd2c,...) at boot+0x44f
> reboot(c2bfd230,ebf8dcfc,4,c0885aef,c08c38a8,...) at reboot+0x4b
> syscall(ebf8dd38) at syscall+0x2b3
> Xint0x80_syscall() at Xint0x80_syscall+0x20
> --- syscall (55, FreeBSD ELF32, reboot), eip = 0x280bc947, esp = 
> 0xbfbfeb7c, ebp = 0xbfbfebb8 ---
> db> 
>
> Forceably unmounting ZFS filesystems prior to issuing reboot(8) mitigates 
> the panic.
>   
I have experienced ZFS related panic with RELEN_7 in November last year and
got a fix from kib@. But I'm not quite sure whether yours and mine are 
the same case, but
might help following patch (for 
/usr/src/sys/cddl/compat/opensolaris/kern/opensolaris_kobj.c and
/usr/src/sys/cddl/compat/opensolaris/sys/vnode.h):

http://lists.freebsd.org/pipermail/freebsd-stable/2008-November/046752.html

Ganbold

>
>   


-- 
I was the best I ever had. -- Woody Allen
From =?UTF-8?B?0K7RgNGC0LDQudC60LjQvSDQkNC90LTRgNC10Lkg0JDQsdC40LvRjNC60LA=?=  Tue Feb 17 23:30:06 2009
From: =?UTF-8?B?0K7RgNGC0LDQudC60LjQvSDQkNC90LTRgNC10Lkg0JDQsdC40LvRjNC60LA=?= (=?UTF-8?B?0K7RgNGC0LDQudC60LjQvSDQkNC90LTRgNC10Lkg0JDQsdC40LvRjNC60LA=?=)
Date: Tue Feb 17 23:30:16 2009
Subject: Problem with transfering system to new disk.
In-Reply-To: <20090211120053.7C01F10656FF@hub.freebsd.org>
References: <20090211120053.7C01F10656FF@hub.freebsd.org>
Message-ID: <499BAF4B.1070005@corp.iskratelecom.ru>

Running system FreeBSD 6.2, attaching new disk (WD 750GB SATA RE3) map 
it thru Sysinstall and rsync old system to it.
Now trying to boot from new disk: system boots well to "Choose what to 
boot" screen (eg 1. normal 2 acpi disable 3. safe 4. single etc), after 
that  system continuously keep printing some strange strings like 
"csh=4583" can`t really read it cause it`s too fast, system don`t react 
to C-C C-X or even CTRL ALT DEL.
So, the question what is it... and how to fix it.  
From dougb at FreeBSD.org  Wed Feb 18 00:07:35 2009
From: dougb at FreeBSD.org (Doug Barton)
Date: Wed Feb 18 00:07:42 2009
Subject: 7-stable kernel not compiling: nlm_prot_impl.c "undefined
 reference to `nfs_*"
In-Reply-To: <499B6A51.8020704@FreeBSD.org>
References: <499B6A51.8020704@FreeBSD.org>
Message-ID: <499BC1C1.4060204@FreeBSD.org>

I "solved" this by adding NFSCLIENT back to my kernel config file. I
had NFSSERVER and NFSLOCKD in there already. Given that this is a file
server system it doesn't seem logical that it would need NFSCLIENT in
the kernel.


Doug


Doug Barton wrote:
> With up to date sources buildworld completes, but kernel fails here:
> 
> linking kernel.debug
> nlm_advlock.o(.text+0x11a8): In function `nlm_advlock_internal':
> /data/src/sys/nlm/nlm_advlock.c:225: undefined reference to
> `nfs_vinvalbuf'
> nlm_advlock.o(.text+0x1243):/data/src/sys/nlm/nlm_advlock.c:236:
> undefined reference to `nfs_ticks'
> nlm_prot_impl.o(.text+0x2af1): In function `nlm_syscall':
> /data/src/sys/nlm/nlm_prot_impl.c:1543: undefined reference to
> `nfs_advlock_p'
> nlm_prot_impl.o(.text+0x2af7):/data/src/sys/nlm/nlm_prot_impl.c:1544:
> undefined reference to `nfs_advlock_p'
> nlm_prot_impl.o(.text+0x2b01):/data/src/sys/nlm/nlm_prot_impl.c:1545:
> undefined reference to `nfs_reclaim_p'
> nlm_prot_impl.o(.text+0x2b07):/data/src/sys/nlm/nlm_prot_impl.c:1546:
> undefined reference to `nfs_reclaim_p'
> nlm_prot_impl.o(.text+0x2b1f):/data/src/sys/nlm/nlm_prot_impl.c:1551:
> undefined reference to `nfs_advlock_p'
> nlm_prot_impl.o(.text+0x2b25):/data/src/sys/nlm/nlm_prot_impl.c:1552:
> undefined reference to `nfs_reclaim_p'
> *** Error code 1
> 
> Stop in /usr/local/obj/data/src/sys/HOME.
> *** Error code 1
> 
> 


-- 

    This .signature sanitized for your protection
From gary.jennejohn at freenet.de  Wed Feb 18 00:12:08 2009
From: gary.jennejohn at freenet.de (Gary Jennejohn)
Date: Wed Feb 18 00:12:18 2009
Subject: HEADS UP: More CAM fixes.
In-Reply-To: <499B221C.2050804@samsco.org>
References: <499981AF.9030204@samsco.org>
	<20090217164203.4c586f48@ernst.jennejohn.org>
	<20090218073542.E5200@delplex.bde.org>
	<499B221C.2050804@samsco.org>
Message-ID: <20090218091151.4d9c2bd7@ernst.jennejohn.org>

On Tue, 17 Feb 2009 13:46:20 -0700
Scott Long <scottl@samsco.org> wrote:

> Bruce Evans wrote:
> > On Tue, 17 Feb 2009, Gary Jennejohn wrote:
> > 
> >> I tested this with an Adaptec 29160.  I saw no real improvement in
> >> performance, but also no regressions.
> >>
> >> I suspect that the old disk I had attached just didn't have enough
> >> performance reserves to show an improvement.
> >>
> >> My test scenario was buildworld.  Since /usr/src and /usr/obj were both
> >> on the one disk it got a pretty good workout.
> >                                   ^^^^ low
> >>
> >> AMD64 X2 (2.5 GHz) with 4GB of RAM.
> > 
> > Buildworld hardly uses the disk at all.  It reads and writes a few hundred
> > MB.  Ideally the i/o should go at disk speeds of 50-200MB/S and thus take
> > between 20 and 5 seconds.  In practice, it will take a few more seconds.
> > physically but perhaps even less virtually due to parallelism.
> > 
> > Bruce
> 
> Yes, on modern machines, buildworld is bound almost completely by disk
> latency, and not at all by disk or controller bandwidth.
> 
> Scott
> 

Maybe I misunderstood something, but I thought the patch was supposed
to improve queuing.  Seems like all the seeks during a buildowrld
would exercise that.  All I can say is that the disk did _lots_ of
seeking.

---
Gary Jennejohn
From krassi at bulinfo.net  Wed Feb 18 00:31:55 2009
From: krassi at bulinfo.net (Krassimir Slavchev)
Date: Wed Feb 18 00:32:04 2009
Subject: Booting 7.1-STABLE on supermicro 5015-MF (PDSMI+)
In-Reply-To: <499AFE8F.3080207@alaska.net>
References: <499AF864.9010506@bulinfo.net> <499AFE8F.3080207@alaska.net>
Message-ID: <499BC773.70701@bulinfo.net>

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

Royce Williams wrote:
> Krassimir Slavchev wrote, on 2/17/2009 8:48 AM:
>> It boots 7.1-RELEASE from the CDROM just fine but when boots from an IDE
>> disk it crashes right after loading the kernel:
>>
>> http://mnemonic.bulinfo.net/~krassi/crash/supermicro_crash.jpg
>>
>> Booting from the USB produces exactly the same crash. I know that the
>> BIOS of this board is buggy although it is latest.
>> I am curious why it boots from the CDROM but cannot boots from the IDE
>> disk. I just disconnect the CDROM and connect the IDE disk. The same IDE
>> disk boots fine on other hardware. I have tried with 7.1-PRERELEASE
>> which is 2-3 months older than 7.1-RELEASE and it crashes in same way.
> 
> I see from the phot that you're running a custom kernel.  What's 
> different between that kernel and GENERIC?

Almost nothing.

> 
> Data point:  I'm running 7.1-RELEASE, installed from CD, on a PDSMI+ 
> board, but I am booting from SATA.  This may help to rule out possible 
> non-IDE issues.

When I boot from CD the IDE disk remains undetected but with SATA disk
no problems. So the problem seems to be only with IDE disks.

I am going to buy a SATA disks.

> 
> I'm tracking with freebsd-update(8), but there have been no 
> kernel updates yet.  It's a fresh install with no kernel or sysctl 
> tuning, and hasn't taken any load yet.
> 
> $ uptime
> 10:02AM  up 10 days, 18:50, 1 user, load averages: 0.00, 0.00, 0.00
> 
> $ uname -a
> FreeBSD dragonfly.acsalaska.net 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
> 
> $ cat /var/run/dmesg.boot
> 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 #0: Thu Jan  1 14:37:25 UTC 2009
>     root@logan.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC
> Timecounter "i8254" frequency 1193182 Hz quality 0
> CPU: Intel(R) Core(TM)2 CPU          6600  @ 2.40GHz (2394.01-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=0x20100000<NX,LM>
>   AMD Features2=0x1<LAHF>
>   Cores per package: 2
> real memory  = 3756916736 (3582 MB)
> avail memory = 3672895488 (3502 MB)
> ACPI APIC Table: <PTLTD          APIC  >
> 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
> ioapic1 <Version 2.0> irqs 24-47 on motherboard
> kbd1 at kbdmux0
> ath_hal: 0.9.20.3 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413)
> acpi0: <PTLTD   RSDT> 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 0x1008-0x100b 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
> pcib2: <ACPI PCI-PCI bridge> irq 17 at device 28.0 on pci0
> pci9: <ACPI PCI bus> on pcib2
> pcib3: <ACPI PCI-PCI bridge> at device 0.0 on pci9
> pci10: <ACPI PCI bus> on pcib3
> pcib4: <ACPI PCI-PCI bridge> irq 17 at device 28.4 on pci0
> pci13: <ACPI PCI bus> on pcib4
> em0: <Intel(R) PRO/1000 Network Connection 6.9.6> port 0x4000-0x401f mem 0xe0200000-0xe021ffff irq 16 at device 0.0 on pci13
> em0: Using MSI interrupt
> em0: [FILTER]
> em0: Ethernet address: 00:30:48:8d:30:74
> pcib5: <ACPI PCI-PCI bridge> irq 16 at device 28.5 on pci0
> pci14: <ACPI PCI bus> on pcib5
> em1: <Intel(R) PRO/1000 Network Connection 6.9.6> port 0x5000-0x501f mem 0xe0300000-0xe031ffff irq 17 at device 0.0 on pci14
> em1: Using MSI interrupt
> em1: [FILTER]
> em1: Ethernet address: 00:30:48:8d:30:75
> uhci0: <UHCI (generic) USB controller> port 0x3000-0x301f 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 0x3020-0x303f 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
> uhci2: <UHCI (generic) USB controller> port 0x3040-0x305f irq 18 at device 29.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
> uhci3: <UHCI (generic) USB controller> port 0x3060-0x307f irq 16 at device 29.3 on pci0
> uhci3: [GIANT-LOCKED]
> uhci3: [ITHREAD]
> usb3: <UHCI (generic) USB controller> on uhci3
> 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
> ehci0: <Intel 82801GB/R (ICH7) USB 2.0 controller> mem 0xe0000000-0xe00003ff irq 23 at device 29.7 on pci0
> ehci0: [GIANT-LOCKED]
> ehci0: [ITHREAD]
> usb4: EHCI version 1.0
> usb4: companion controllers, 2 ports each: usb0 usb1 usb2 usb3
> usb4: <Intel 82801GB/R (ICH7) USB 2.0 controller> on ehci0
> usb4: USB revision 2.0
> uhub4: <Intel EHCI root hub, class 9/0, rev 2.00/1.00, addr 1> on usb4
> uhub4: 8 ports with 8 removable, self powered
> pcib6: <ACPI PCI-PCI bridge> at device 30.0 on pci0
> pci15: <ACPI PCI bus> on pcib6
> vgapci0: <VGA-compatible display> port 0x6000-0x60ff mem 0xe8000000-0xefffffff,0xe0400000-0xe040ffff irq 16 at device 0.0 on pci15
> 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,0x30a0-0x30af at device 31.1 on pci0
> ata0: <ATA channel 0> on atapci0
> ata0: [ITHREAD]
> ata1: <ATA channel 1> on atapci0
> ata1: [ITHREAD]
> atapci1: <Intel ICH7 SATA300 controller> port 0x30e8-0x30ef,0x30dc-0x30df,0x30e0-0x30e7,0x30d8-0x30db,0x30b0-0x30bf mem 0xe0000400-0xe00007ff 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: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0
> sio0: type 16550A, console
> sio0: [FILTER]
> sio1: <16550A-compatible COM port> port 0x2f8-0x2ff irq 3 on acpi0
> sio1: type 16550A
> sio1: [FILTER]
> fdc0: <floppy drive controller> port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on acpi0
> fdc0: does not respond
> device_attach: fdc0 attach returned 6
> cpu0: <ACPI CPU> on acpi0
> est0: <Enhanced SpeedStep Frequency Control> on cpu0
> est: CPU supports Enhanced Speedstep, but is not recognized.
> est: cpu_vendor GenuineIntel, msr 921092106000921
> device_attach: est0 attach returned 6
> 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 921092106000921
> device_attach: est1 attach returned 6
> p4tcc1: <CPU Frequency Thermal Control> on cpu1
> fdc0: <floppy drive controller> port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on acpi0
> fdc0: does not respond
> device_attach: fdc0 attach returned 6
> pmtimer0 on isa0
> orm0: <ISA Option ROMs> at iomem 0xc0000-0xcafff,0xcb000-0xcbfff,0xcc000-0xccfff 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]
> 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/9 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>
> vga0: <Generic ISA VGA> at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0
> Timecounters tick every 1.000 msec
> acd0: CDROM <CD-224E/1.9A> at ata0-master UDMA33
> ad4: 238475MB <Seagate ST3250820AS 3.AAE> at ata2-master SATA150
> ad6: 238475MB <Seagate ST3250820AS 3.AAE> at ata3-master SATA150
> SMP: AP CPU #1 Launched!
> Trying to mount root from ufs:/dev/ad4s1a
> $
> 
> Royce
> 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (FreeBSD)

iD8DBQFJm8dyxJBWvpalMpkRAjS7AKCCejCzBQEV6ja2kj8bltPA00zsIgCfVORC
OMt9scuIQIwz/Rthrf2aE2M=
=Tjvf
-----END PGP SIGNATURE-----
From bunke at hbxt.org  Wed Feb 18 02:03:52 2009
From: bunke at hbxt.org (Hendrik Bunke)
Date: Wed Feb 18 02:03:59 2009
Subject: FreeBSD 7.1 crashing on shutdown, halt etc.
In-Reply-To: <1234890933.21366.10.camel@pc-racine1.mcmaster.ca>
References: <1234890933.21366.10.camel@pc-racine1.mcmaster.ca>
Message-ID: <alpine.BSF.2.00.0902181031060.1357@sisko.hbxt.de>

--On Tue, 17 Feb 2009 12:15, Jeffrey Racine wrote:

> Hi.
> 
> My system is crashing when I log out (using gdm). I had posted to gnome but was 
> just advised to post to x11, posted to x11 and was told this is a kernel bug. 
> Many thanks for any all of your assistance. Backtrace is provided below.

I had similar problems (didn't do a backtrace though). Solution
was updating to 7-stable and adding 
  dbus_enable="YES"
  hald_enable="YES"
to rc.conf. Updating might not be necessary, adding dbus and hald
is absolutely.

regards
hendrik

-- 
Dr. Hendrik Bunke
blog: http://hbxt.org/
com:  http://hbxt.de/
From rwatson at FreeBSD.org  Wed Feb 18 02:06:55 2009
From: rwatson at FreeBSD.org (Robert Watson)
Date: Wed Feb 18 02:07:02 2009
Subject: Big problems with 7.1 locking up :-(
In-Reply-To: <200902180110.n1I1AaPL031693@pyroxene.sentex.ca>
References: <E1LL6dg-0007CN-DI@dilbert.ticketswitch.com>
	<alpine.BSF.2.00.0901292234430.30840@fledge.watson.org>
	<200902180110.n1I1AaPL031693@pyroxene.sentex.ca>
Message-ID: <alpine.BSF.2.00.0902181005340.23519@fledge.watson.org>


On Tue, 17 Feb 2009, Mike Tancsa wrote:

> At 05:38 PM 1/29/2009, Robert Watson wrote:
>
>> On Fri, 9 Jan 2009, Pete French wrote:
>> 
>>> I have a number of HP 1U servers, all of which were running 7.0 perfectly 
>>> happily. I have been testing 7.1 in it's various incarnations for the last 
>>> couple of months on our test server and it has performed perfectly.
>>> 
>>> So the last two days I have been round upgrading all our servers, knowing 
>>> that I had run the system stably on identical hardware for some time.
>> 
>> For those following this other than Pete, who I've been in private 
>> correspondence with: it seems that he is running into two different 
>> deadlocks in the routing code.  One of them (at least) is triggered by a 
>> lock order problem relating to the processing of ICMP redirects -- uncommon 
>> in most configurations, but quite a few on his network, which triggers 
>> quickly under load.  Kip Macy has corrected at least one (both?) problems 
>> in head, and plans to MFC the fixes in the near future.  We'll follow up 
>> further once the fixes are merged, and if any further problems transpire.
>
> Do you have any other details about these issues ? Were the fixes ever MFC'd

Hi Mike, et al,

I gave Kip a ping about MFCing the fixes and he said he would do that, but has 
apparently been preoccupied.  I'm working on an MFC patch currently, but as 
I'm not all that familiar with the routing code, and the bug fixes were mixed 
with feature enhancements in his original commits, it will probably take me a 
bit longer to produce a candidate patch.

Robert N M Watson
Computer Laboratory
University of Cambridge
From cm at therek.net  Wed Feb 18 03:27:46 2009
From: cm at therek.net (Cezary Morga)
Date: Wed Feb 18 03:27:53 2009
Subject: FreeBSD 7.1 crashing on shutdown, halt etc.
In-Reply-To: <alpine.BSF.2.00.0902181031060.1357@sisko.hbxt.de>
References: <1234890933.21366.10.camel@pc-racine1.mcmaster.ca>
	<alpine.BSF.2.00.0902181031060.1357@sisko.hbxt.de>
Message-ID: <200902181227.38524.cm@therek.net>

Dnia ?roda, 18 lutego 2009, Hendrik Bunke napisa?:
> --On Tue, 17 Feb 2009 12:15, Jeffrey Racine wrote:
> > Hi.
> >
> > My system is crashing when I log out (using gdm). I had posted to gnome
> > but was just advised to post to x11, posted to x11 and was told this is a
> > kernel bug. Many thanks for any all of your assistance. Backtrace is
> > provided below.
>
> I had similar problems (didn't do a backtrace though). Solution
> was updating to 7-stable and adding
>   dbus_enable="YES"
>   hald_enable="YES"
> to rc.conf. Updating might not be necessary, adding dbus and hald
> is absolutely.

My problem appeared after updating from 7.1-RELEASE to 7-STABLE with dbus and 
hald already enabled.

-- 
Pozdrawiam,
Cezary Morga
"Television enables you to be entertained in your home by people you wouldn't 
have in your home." (David Frost)

From jumper99 at gmx.de  Wed Feb 18 04:10:15 2009
From: jumper99 at gmx.de (Helmut Schneider)
Date: Wed Feb 18 04:10:27 2009
Subject: Invalid path for portupgrade ftp.FreeBSD.orgpub
References: <5909599F-CB2C-4B10-B405-156D95479AE6@yahoo.it>
Message-ID: <gngq77$te9$1@ger.gmane.org>

Gianni Doe <gdoe6545@yahoo.it> wrote:

> I'm upgrading a system from 6.4 to 7.1 and rebuilding all the ports.
> I'd rather use packages where present to speed things up a bit so I'm  
> using:
> # portupgrade -faP
> 
> The problem is that it never finds the packages as the URL is invalid,  
> there seems to be a missing slash between in ftp.FreeBSD.orgpub

I created a PR: http://www.freebsd.org/cgi/query-pr.cgi?pr=131775

In the meantime install ruby-1.8.6 which solves the problem.

HTH; Helmut

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

From ml at netfence.it  Wed Feb 18 08:12:26 2009
From: ml at netfence.it (Andrea Venturoli)
Date: Wed Feb 18 08:12:33 2009
Subject: HEADS UP: Major CAM performance regression
In-Reply-To: <499551B9.7050805@samsco.org>
References: <499551B9.7050805@samsco.org>
Message-ID: <499BF630.7080306@netfence.it>

Scott Long ha scritto:



Hello.



> The following configurations are known to be affected:
> 
> VMWare ESX
> VMWare Fusion
>     (using bt or lsilogic controller options)
> HP CISS RAID
> Some MPT-SAS combinations with SATA drives attached
>     (Includes Dell SAS5/ir, but not PERC5/PERC6).

Does it holds for any of these?
Or do you require a combination of factors?


I ask because I have two identical HP machines, one running 7.1p2/amd64, 
the other still at 7.1-PRERELEASE/amd64 and on both I get:
# camcontrol tags da0
(pass1:ciss0:0:0:0): device openings: 254

So it looks like I'm not affected, although I have a ciss RAID.


???


  bye & Thanks
	av.
From kostikbel at gmail.com  Wed Feb 18 08:21:34 2009
From: kostikbel at gmail.com (Kostik Belousov)
Date: Wed Feb 18 08:21:42 2009
Subject: ZFS Panic
In-Reply-To: <200902180543.n1I5hVDF072033@cwsys.cwsent.com>
References: <200902180543.n1I5hVDF072033@cwsys.cwsent.com>
Message-ID: <20090218162126.GQ41617@deviant.kiev.zoral.com.ua>

On Tue, Feb 17, 2009 at 09:43:31PM -0800, Cy Schubert wrote:
> I got this panic after issuing reboot(8).
> 
> FreeBSD  7.1-STABLE FreeBSD 7.1-STABLE #0: Tue Feb 17 19:29:23 PST 2009     
> cy@cwsys:/export/obj/export/home/cy/test/test-stable7/sys/DEBUG  i386
> 
> 
> FreeBSD/i386 (bob) (ttyd0)
> 
> login: Feb 17 21:22:56 bob reboot: rebooted by root
> Feb 17 21:22:56 bob syslogd: exiting on signal 15
> Waiting (max 60 seconds) for system process `vnlru' to stop...done
> Waiting (max 60 seconds) for system process `syncer' to stop...
> Syncing disks, vnodes remaining...2 2 2 2 1 1 1 1 0 0 0 0 0 0 done
> Waiting (max 60 seconds) for system process `bufdaemon' to stop...done
> All buffers synced.
> panic: insmntque() failed: error 16
> cpuid = 0
> KDB: enter: panic
> [thread pid 1086 tid 100090 ]
> Stopped at      kdb_enter_why+0x3a:     movl    $0,kdb_why
> db> bt
> Tracing pid 1086 tid 100090 td 0xc2bfd230
> kdb_enter_why(c087ef4a,c087ef4a,c2b1b5b4,ebf8da58,0,...) at 
> kdb_enter_why+0x3a
> panic(c2b1b5b4,10,c2b24a40,ebf8da64,c38e6000,...) at panic+0x136
> gfs_file_create(84,c346d8a0,c342d5a0,c2b24a40,c346d8a0,...) at 
> gfs_file_create+0x86
> gfs_dir_create(84,c346d8a0,c342d5a0,c2b24a40,0,...) at gfs_dir_create+0x2c
> zfsctl_mknode_snapdir(c346d8a0,c2b1b54f,275,25d,c3419520,...) at 
> zfsctl_mknode_snapdir+0x53
> gfs_dir_lookup(c346d8a0,c2b21126,ebf8db74,c091521c,ebf8db38,...) at 
> gfs_dir_lookup+0xd1
> zfsctl_root_lookup(c346d8a0,c2b21126,ebf8db74,0,0,...) at 
> zfsctl_root_lookup+0xdc
> zfsctl_umount_snapshots(c342d5a0,80000,c3acb800,c3216844,0,...) at 
> zfsctl_umount_snapshots+0x4e
> zfs_umount(c342d5a0,80000,c2bfd230,c2bfd230,c088a687,...) at zfs_umount+0x53
> dounmount(c342d5a0,80000,c2bfd230,e26988ac,0,...) at dounmount+0x430
> vfs_unmountall(c087ed87,0,c087edeb,128,0,...) at vfs_unmountall+0x4e
> boot(c090b5d0,0,c087edeb,ab,ebf8dd2c,...) at boot+0x44f
> reboot(c2bfd230,ebf8dcfc,4,c0885aef,c08c38a8,...) at reboot+0x4b
> syscall(ebf8dd38) at syscall+0x2b3
> Xint0x80_syscall() at Xint0x80_syscall+0x20
> --- syscall (55, FreeBSD ELF32, reboot), eip = 0x280bc947, esp = 
> 0xbfbfeb7c, ebp = 0xbfbfebb8 ---
> db> 
> 
> Forceably unmounting ZFS filesystems prior to issuing reboot(8) mitigates 
> the panic.

The patch below would fix the problem, unless I mis-merged it.
Please note that I cannot test the patch myself, so I rely on ZFS
users testing before the commit.

Property changes on: .
___________________________________________________________________
Modified: svn:mergeinfo
   Merged /head/sys:r182781,182824,182840


Property changes on: dev/cxgb
___________________________________________________________________
Modified: svn:mergeinfo
   Merged /head/sys/dev/cxgb:r182781,182824,182840


Property changes on: dev/ath/ath_hal
___________________________________________________________________
Modified: svn:mergeinfo
   Merged /head/sys/dev/ath/ath_hal:r182781,182824,182840


Property changes on: contrib/pf
___________________________________________________________________
Modified: svn:mergeinfo
   Merged /head/sys/contrib/pf:r182781,182824,182840

Index: cddl/contrib/opensolaris/uts/common/fs/gfs.c
===================================================================
--- cddl/contrib/opensolaris/uts/common/fs/gfs.c	(revision 188748)
+++ cddl/contrib/opensolaris/uts/common/fs/gfs.c	(working copy)
@@ -358,6 +358,7 @@
 	fp = kmem_zalloc(size, KM_SLEEP);
 	error = getnewvnode("zfs", vfsp, ops, &vp);
 	ASSERT(error == 0);
+	vn_lock(vp, LK_EXCLUSIVE | LK_RETRY, curthread);
 	vp->v_data = (caddr_t)fp;
 
 	/*
@@ -368,7 +369,9 @@
 	fp->gfs_size = size;
 	fp->gfs_type = GFS_FILE;
 
+	vp->v_vflag |= VV_FORCEINSMQ;
 	error = insmntque(vp, vfsp);
+	vp->v_vflag &= ~VV_FORCEINSMQ;
 	KASSERT(error == 0, ("insmntque() failed: error %d", error));
 
 	/*
Index: cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_znode.c
===================================================================
--- cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_znode.c	(revision 188748)
+++ cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_znode.c	(working copy)
@@ -113,6 +113,7 @@
 	if (cdrarg != NULL) {
 		error = getnewvnode("zfs", vfsp, &zfs_vnodeops, &vp);
 		ASSERT(error == 0);
+		vn_lock(vp, LK_EXCLUSIVE | LK_RETRY, curthread);
 		zp->z_vnode = vp;
 		vp->v_data = (caddr_t)zp;
 		vp->v_vnlock->lk_flags |= LK_CANRECURSE;
@@ -348,7 +349,9 @@
 	if (vp == NULL)
 		return (zp);
 
+	vp->v_vflag |= VV_FORCEINSMQ;
 	error = insmntque(vp, zfsvfs->z_vfs);
+	vp->v_vflag &= ~VV_FORCEINSMQ;
 	KASSERT(error == 0, ("insmntque() failed: error %d", error));
 
 	vp->v_type = IFTOVT((mode_t)zp->z_phys->zp_mode);
@@ -535,8 +538,10 @@
 
 		*zpp = zp;
 	} else {
-		if (ZTOV(zp) != NULL)
+		if (ZTOV(zp) != NULL) {
 			ZTOV(zp)->v_count = 0;
+			VOP_UNLOCK(ZTOV(zp), 0, curthread);
+		}
 		dmu_buf_rele(dbp, NULL);
 		zfs_znode_free(zp);
 	}
@@ -598,14 +603,18 @@
 			    &zp->z_vnode);
 			ASSERT(err == 0);
 			vp = ZTOV(zp);
+			vn_lock(vp, LK_EXCLUSIVE | LK_RETRY, curthread);
 			vp->v_data = (caddr_t)zp;
 			vp->v_vnlock->lk_flags |= LK_CANRECURSE;
 			vp->v_vnlock->lk_flags &= ~LK_NOSHARE;
 			vp->v_type = IFTOVT((mode_t)zp->z_phys->zp_mode);
 			if (vp->v_type == VDIR)
 				zp->z_zn_prefetch = B_TRUE;	/* z_prefetch default is enabled */
+			vp->v_vflag |= VV_FORCEINSMQ;
 			err = insmntque(vp, zfsvfs->z_vfs);
+			vp->v_vflag &= ~VV_FORCEINSMQ;
 			KASSERT(err == 0, ("insmntque() failed: error %d", err));
+			VOP_UNLOCK(vp, 0, curthread);
 		}
 		mutex_exit(&zp->z_lock);
 		ZFS_OBJ_HOLD_EXIT(zfsvfs, obj_num);
@@ -621,6 +630,8 @@
 	zfs_znode_dmu_init(zp);
 	ZFS_OBJ_HOLD_EXIT(zfsvfs, obj_num);
 	*zpp = zp;
+	if ((vp = ZTOV(zp)) != NULL)
+		VOP_UNLOCK(vp, 0, curthread);
 	return (0);
 }
 
Index: cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c
===================================================================
--- cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c	(revision 188748)
+++ cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c	(working copy)
@@ -1303,12 +1303,6 @@
 		}
 	}
 out:
-
-	if (error == 0) {
-		*vpp = ZTOV(zp);
-		vn_lock(*vpp, LK_EXCLUSIVE | LK_RETRY, td);
-	}
-
 	if (dl)
 		zfs_dirent_unlock(dl);
 
@@ -1588,8 +1582,6 @@
 	zfs_log_create(zilog, tx, TX_MKDIR, dzp, zp, dirname);
 	dmu_tx_commit(tx);
 
-	vn_lock(*vpp, LK_EXCLUSIVE | LK_RETRY, curthread);
-
 	zfs_dirent_unlock(dl);
 
 	ZFS_EXIT(zfsvfs);
@@ -2773,7 +2765,6 @@
 	if (error == 0) {
 		zfs_log_symlink(zilog, tx, TX_SYMLINK, dzp, zp, name, link);
 		*vpp = ZTOV(zp);
-		vn_lock(*vpp, LK_EXCLUSIVE | LK_RETRY, td);
 	}
 
 	dmu_tx_commit(tx);
Index: cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_ctldir.c
===================================================================
--- cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_ctldir.c	(revision 188748)
+++ cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_ctldir.c	(working copy)
@@ -176,6 +176,8 @@
 	vp->v_vflag &= ~VV_ROOT;
 
 	zfsvfs->z_ctldir = vp;
+
+	VOP_UNLOCK(vp, 0, curthread);
 }
 
 /*
@@ -789,6 +791,7 @@
 	mutex_init(&sdp->sd_lock, NULL, MUTEX_DEFAULT, NULL);
 	avl_create(&sdp->sd_snaps, snapentry_compare,
 	    sizeof (zfs_snapentry_t), offsetof(zfs_snapentry_t, se_node));
+	VOP_UNLOCK(vp, 0, curthread);
 	return (vp);
 }
 
@@ -862,6 +865,7 @@
 	    &zfsctl_ops_snapshot, NULL, NULL, MAXNAMELEN, NULL, NULL);
 	zcp = vp->v_data;
 	zcp->zc_id = objset;
+	VOP_UNLOCK(vp, 0, curthread);
 
 	return (vp);
 }
-------------- 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/20090218/41554ee0/attachment.pgp
From krassi at bulinfo.net  Wed Feb 18 08:46:47 2009
From: krassi at bulinfo.net (Krassimir Slavchev)
Date: Wed Feb 18 08:46:56 2009
Subject: Booting 7.1-STABLE on supermicro 5015-MF (PDSMI+) (solved)
In-Reply-To: <499BC773.70701@bulinfo.net>
References: <499AF864.9010506@bulinfo.net> <499AFE8F.3080207@alaska.net>
	<499BC773.70701@bulinfo.net>
Message-ID: <499C3B70.6040803@bulinfo.net>

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

I found that my problem is exactly as PR: 126972 and increasing NKPT
solves it. Even I am able to boot from USB.

I have question about setting NKPT. The default value is 30 and
according reply to this PR it should be able to use mfs root with size
up to ~120Mb.
My uncompressed mfs root image is ~70Mb and it should work with the
default value of NKPT.

NKPT means "Actual number of kernel page tables" but how it affect mfs
root? And how to calculate needed value?

Also this board definitely has problems connecting IDE HDD!

Best regards

Krassimir Slavchev wrote:
> Royce Williams wrote:
>> Krassimir Slavchev wrote, on 2/17/2009 8:48 AM:
>>> It boots 7.1-RELEASE from the CDROM just fine but when boots from an IDE
>>> disk it crashes right after loading the kernel:
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (FreeBSD)

iD8DBQFJnDtwxJBWvpalMpkRAiTGAJ9AEp4xA917AQok6aE67wfGexafjgCeNcPX
LxKvQI6ZxWxSv2BbeEfCH6c=
=SsOx
-----END PGP SIGNATURE-----
From pluknet at gmail.com  Wed Feb 18 09:19:39 2009
From: pluknet at gmail.com (pluknet)
Date: Wed Feb 18 09:19:46 2009
Subject: 7-stable kernel not compiling: nlm_prot_impl.c "undefined 
	reference to `nfs_*"
In-Reply-To: <499BC1C1.4060204@FreeBSD.org>
References: <499B6A51.8020704@FreeBSD.org> <499BC1C1.4060204@FreeBSD.org>
Message-ID: <a31046fc0902180919y4d032f32u4cadf46b4ae69b4d@mail.gmail.com>

2009/2/18 Doug Barton <dougb@freebsd.org>:
> I "solved" this by adding NFSCLIENT back to my kernel config file. I
> had NFSSERVER and NFSLOCKD in there already. Given that this is a file
> server system it doesn't seem logical that it would need NFSCLIENT in
> the kernel.
>

I talked with dfr@ about ifdef'ing client parts in NFSLOCKD some
months ago, still without result.

-- 
wbr,
pluknet
From ianjhart at ntlworld.com  Wed Feb 18 09:46:29 2009
From: ianjhart at ntlworld.com (ian j hart)
Date: Wed Feb 18 09:46:36 2009
Subject: Upgrade from 32-bit to AMD-64?
In-Reply-To: <2CA7DE699281AFA5DF2BD851@syn>
References: <4994CD7B.7040302@denninger.net> <499526E9.3090804@bit0.com>
	<2CA7DE699281AFA5DF2BD851@syn>
Message-ID: <200902181728.16842.ianjhart@ntlworld.com>

On Friday 13 February 2009 08:40:27 Goran Lowkrantz wrote:
> Hi,
>
> When  have done this, MySQL is OK but Berkley and PostgreSQL need
> dump/restore.
>
> /glz

[sorry I'm a bit late]

IIRC system accounting did weird stuff until I adjusted it with rm :)

>
> --On February 13, 2009 2:53:13 -0500 Mike Andrews <mandrews@bit0.com> wrote:
> > Xin LI wrote:
> >> -----BEGIN PGP SIGNED MESSAGE-----
> >> Hash: SHA1
> >>
> >> Karl Denninger wrote:
> >> [...]
> >>
> >>> I guess I need to schedule the 2-3 hours of downtime..... the reason
> >>> for this, by the way, is that I have a dbms app on there that is
> >>> getting too RAM hungry for its own good (its a Quadcore CPU) and I'm up
> >>> against the RAM limit for 32-bit code.  The board will support more but
> >>> 32-bit code won't; ergo, the only way to get beyond this is to go to
> >>> 64-bit.
> >>
> >> Oh wait!  One thing you wanted to know is that, some database *can* have
> >> different on-disk format for 32-bit and 64-bit binaries.  Be sure to
> >> have a dump handy.  Last time I hit this on a MySQL "upgrade" between
> >> two servers, and I end up using its replication functionality.  The
> >> operation took longer time than I expected at the beginning.
> >
> > For what it's worth, I did an in-place source upgrade on our MySQL server
> > (for the same lack-of-memory reason) and didn't have any on-disk format
> > problems.  In fact later on when troubleshooting data corruption problems
> > that turned out to be bad hardware, I switched between 32-bit and 64-bit
> > mysqld binaries without rebooting or dumping/reimporting the database.
> >
> > BUT... there was no replication involved.  It wouldn't surprise me if the
> > binlog or relay logs were in an architecture specific format. InnoDB and
> > MyISAM tables don't appear to be.  This was over a year ago though, so
> > test on a scratch box first and you may save yourself a bit of downtime.
> >
> > The upgrade is a pain, and does have a lot of potential foot-shooting,
> > and you have to immediately recompile ALL of your installed ports (and
> > anything else not built from ports) to avoid mixing 32-bit and 64-bit
> > shared libraries...  and that rebuilding ports time is where most of your
> > downtime comes from if it's a production box.
> >
> > If you're feeling lucky, the procedure's in the list archives somewhere
> > and the super-short version is you turn your swap partition into a
> > temporary amd64 root filesystem, installworld/kernel into that, boot into
> > that, then mount and installworld/kernel on top of the old i386 root
> > filesystem from there, then boot into it and recompile all your ports
> > (after reclaiming your swap partition for swap).  Or, the way I did it
> > last time was to boot into a PXE diskless FreeBSD/amd64 install and use
> > that to mount/install over the i386 stuff.
> >
> > Definitely practice on a scratch system first. :)
> >
> >
> > --
> > Mike Andrews
> > Server Monkey
> > Fark, Inc
> > mandrews@fark.com
> > _______________________________________________
> > 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"
>
> ................................................... the future isMobile
>
>   Goran Lowkrantz <goran.lowkrantz@ismobile.com>
>   System Architect, isMobile AB
>   Sandviksgatan 81, PO Box 58, S-971 03 Lule?, Sweden
>   Mobile: +46(0)70-587 87 82
> http://www.ismobile.com ...............................................
> _______________________________________________
> 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"



-- 
ian j hart
From Cy.Schubert at komquats.com  Wed Feb 18 09:51:25 2009
From: Cy.Schubert at komquats.com (Cy Schubert)
Date: Wed Feb 18 09:51:32 2009
Subject: ZFS Panic 
In-Reply-To: Message from Kostik Belousov <kostikbel@gmail.com> of "Wed,
	18 Feb 2009 18:21:26 +0200."
	<20090218162126.GQ41617@deviant.kiev.zoral.com.ua> 
Message-ID: <200902181751.n1IHpKdD028603@cwsys.cwsent.com>

In message <20090218162126.GQ41617@deviant.kiev.zoral.com.ua>, Kostik 
Belousov
writes:
> 
> --v+Mbu5iuT/5Blw/K
> Content-Type: text/plain; charset=us-ascii
> Content-Disposition: inline
> Content-Transfer-Encoding: quoted-printable
> 
> On Tue, Feb 17, 2009 at 09:43:31PM -0800, Cy Schubert wrote:
> > I got this panic after issuing reboot(8).
> >=20
> > FreeBSD  7.1-STABLE FreeBSD 7.1-STABLE #0: Tue Feb 17 19:29:23 PST 2009  =
>   =20
> > cy@cwsys:/export/obj/export/home/cy/test/test-stable7/sys/DEBUG  i386
> >=20
> >=20
> > FreeBSD/i386 (bob) (ttyd0)
> >=20
> > login: Feb 17 21:22:56 bob reboot: rebooted by root
> > Feb 17 21:22:56 bob syslogd: exiting on signal 15
> > Waiting (max 60 seconds) for system process `vnlru' to stop...done
> > Waiting (max 60 seconds) for system process `syncer' to stop...
> > Syncing disks, vnodes remaining...2 2 2 2 1 1 1 1 0 0 0 0 0 0 done
> > Waiting (max 60 seconds) for system process `bufdaemon' to stop...done
> > All buffers synced.
> > panic: insmntque() failed: error 16
> > cpuid =3D 0
> > KDB: enter: panic
> > [thread pid 1086 tid 100090 ]
> > Stopped at      kdb_enter_why+0x3a:     movl    $0,kdb_why
> > db> bt
> > Tracing pid 1086 tid 100090 td 0xc2bfd230
> > kdb_enter_why(c087ef4a,c087ef4a,c2b1b5b4,ebf8da58,0,...) at=20
> > kdb_enter_why+0x3a
> > panic(c2b1b5b4,10,c2b24a40,ebf8da64,c38e6000,...) at panic+0x136
> > gfs_file_create(84,c346d8a0,c342d5a0,c2b24a40,c346d8a0,...) at=20
> > gfs_file_create+0x86
> > gfs_dir_create(84,c346d8a0,c342d5a0,c2b24a40,0,...) at gfs_dir_create+0x2c
> > zfsctl_mknode_snapdir(c346d8a0,c2b1b54f,275,25d,c3419520,...) at=20
> > zfsctl_mknode_snapdir+0x53
> > gfs_dir_lookup(c346d8a0,c2b21126,ebf8db74,c091521c,ebf8db38,...) at=20
> > gfs_dir_lookup+0xd1
> > zfsctl_root_lookup(c346d8a0,c2b21126,ebf8db74,0,0,...) at=20
> > zfsctl_root_lookup+0xdc
> > zfsctl_umount_snapshots(c342d5a0,80000,c3acb800,c3216844,0,...) at=20
> > zfsctl_umount_snapshots+0x4e
> > zfs_umount(c342d5a0,80000,c2bfd230,c2bfd230,c088a687,...) at zfs_umount+0=
> x53
> > dounmount(c342d5a0,80000,c2bfd230,e26988ac,0,...) at dounmount+0x430
> > vfs_unmountall(c087ed87,0,c087edeb,128,0,...) at vfs_unmountall+0x4e
> > boot(c090b5d0,0,c087edeb,ab,ebf8dd2c,...) at boot+0x44f
> > reboot(c2bfd230,ebf8dcfc,4,c0885aef,c08c38a8,...) at reboot+0x4b
> > syscall(ebf8dd38) at syscall+0x2b3
> > Xint0x80_syscall() at Xint0x80_syscall+0x20
> > --- syscall (55, FreeBSD ELF32, reboot), eip =3D 0x280bc947, esp =3D=20
> > 0xbfbfeb7c, ebp =3D 0xbfbfebb8 ---
> > db>=20
> >=20
> > Forceably unmounting ZFS filesystems prior to issuing reboot(8) mitigates=
> =20
> > the panic.
> 
> The patch below would fix the problem, unless I mis-merged it.
> Please note that I cannot test the patch myself, so I rely on ZFS
> users testing before the commit.
> 
> Property changes on: .
> ___________________________________________________________________
> Modified: svn:mergeinfo
>    Merged /head/sys:r182781,182824,182840
> 
> 
> Property changes on: dev/cxgb
> ___________________________________________________________________
> Modified: svn:mergeinfo
>    Merged /head/sys/dev/cxgb:r182781,182824,182840
> 
> 
> Property changes on: dev/ath/ath_hal
> ___________________________________________________________________
> Modified: svn:mergeinfo
>    Merged /head/sys/dev/ath/ath_hal:r182781,182824,182840
> 
> 
> Property changes on: contrib/pf
> ___________________________________________________________________
> Modified: svn:mergeinfo
>    Merged /head/sys/contrib/pf:r182781,182824,182840
> 
> Index: cddl/contrib/opensolaris/uts/common/fs/gfs.c
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> --- cddl/contrib/opensolaris/uts/common/fs/gfs.c	(revision 188748)
> +++ cddl/contrib/opensolaris/uts/common/fs/gfs.c	(working copy)
> @@ -358,6 +358,7 @@
>  	fp =3D kmem_zalloc(size, KM_SLEEP);
>  	error =3D getnewvnode("zfs", vfsp, ops, &vp);
>  	ASSERT(error =3D=3D 0);
> +	vn_lock(vp, LK_EXCLUSIVE | LK_RETRY, curthread);
>  	vp->v_data =3D (caddr_t)fp;
> =20
>  	/*
> @@ -368,7 +369,9 @@
>  	fp->gfs_size =3D size;
>  	fp->gfs_type =3D GFS_FILE;
> =20
> +	vp->v_vflag |=3D VV_FORCEINSMQ;
>  	error =3D insmntque(vp, vfsp);
> +	vp->v_vflag &=3D ~VV_FORCEINSMQ;
>  	KASSERT(error =3D=3D 0, ("insmntque() failed: error %d", error));
> =20
>  	/*
> Index: cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_znode.c
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> --- cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_znode.c	(revision 18874
> 8)
> +++ cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_znode.c	(working copy)
> @@ -113,6 +113,7 @@
>  	if (cdrarg !=3D NULL) {
>  		error =3D getnewvnode("zfs", vfsp, &zfs_vnodeops, &vp);
>  		ASSERT(error =3D=3D 0);
> +		vn_lock(vp, LK_EXCLUSIVE | LK_RETRY, curthread);
>  		zp->z_vnode =3D vp;
>  		vp->v_data =3D (caddr_t)zp;
>  		vp->v_vnlock->lk_flags |=3D LK_CANRECURSE;
> @@ -348,7 +349,9 @@
>  	if (vp =3D=3D NULL)
>  		return (zp);
> =20
> +	vp->v_vflag |=3D VV_FORCEINSMQ;
>  	error =3D insmntque(vp, zfsvfs->z_vfs);
> +	vp->v_vflag &=3D ~VV_FORCEINSMQ;
>  	KASSERT(error =3D=3D 0, ("insmntque() failed: error %d", error));
> =20
>  	vp->v_type =3D IFTOVT((mode_t)zp->z_phys->zp_mode);
> @@ -535,8 +538,10 @@
> =20
>  		*zpp =3D zp;
>  	} else {
> -		if (ZTOV(zp) !=3D NULL)
> +		if (ZTOV(zp) !=3D NULL) {
>  			ZTOV(zp)->v_count =3D 0;
> +			VOP_UNLOCK(ZTOV(zp), 0, curthread);
> +		}
>  		dmu_buf_rele(dbp, NULL);
>  		zfs_znode_free(zp);
>  	}
> @@ -598,14 +603,18 @@
>  			    &zp->z_vnode);
>  			ASSERT(err =3D=3D 0);
>  			vp =3D ZTOV(zp);
> +			vn_lock(vp, LK_EXCLUSIVE | LK_RETRY, curthread);
>  			vp->v_data =3D (caddr_t)zp;
>  			vp->v_vnlock->lk_flags |=3D LK_CANRECURSE;
>  			vp->v_vnlock->lk_flags &=3D ~LK_NOSHARE;
>  			vp->v_type =3D IFTOVT((mode_t)zp->z_phys->zp_mode);
>  			if (vp->v_type =3D=3D VDIR)
>  				zp->z_zn_prefetch =3D B_TRUE;	/* z_prefetch d
> efault is enabled */
> +			vp->v_vflag |=3D VV_FORCEINSMQ;
>  			err =3D insmntque(vp, zfsvfs->z_vfs);
> +			vp->v_vflag &=3D ~VV_FORCEINSMQ;
>  			KASSERT(err =3D=3D 0, ("insmntque() failed: error %d", 
> err));
> +			VOP_UNLOCK(vp, 0, curthread);
>  		}
>  		mutex_exit(&zp->z_lock);
>  		ZFS_OBJ_HOLD_EXIT(zfsvfs, obj_num);
> @@ -621,6 +630,8 @@
>  	zfs_znode_dmu_init(zp);
>  	ZFS_OBJ_HOLD_EXIT(zfsvfs, obj_num);
>  	*zpp =3D zp;
> +	if ((vp =3D ZTOV(zp)) !=3D NULL)
> +		VOP_UNLOCK(vp, 0, curthread);
>  	return (0);
>  }
> =20
> Index: cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> --- cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c	(revision 18874
> 8)
> +++ cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c	(working copy)
> @@ -1303,12 +1303,6 @@
>  		}
>  	}
>  out:
> -
> -	if (error =3D=3D 0) {
> -		*vpp =3D ZTOV(zp);
> -		vn_lock(*vpp, LK_EXCLUSIVE | LK_RETRY, td);
> -	}
> -
>  	if (dl)
>  		zfs_dirent_unlock(dl);
> =20
> @@ -1588,8 +1582,6 @@
>  	zfs_log_create(zilog, tx, TX_MKDIR, dzp, zp, dirname);
>  	dmu_tx_commit(tx);
> =20
> -	vn_lock(*vpp, LK_EXCLUSIVE | LK_RETRY, curthread);
> -
>  	zfs_dirent_unlock(dl);
> =20
>  	ZFS_EXIT(zfsvfs);
> @@ -2773,7 +2765,6 @@
>  	if (error =3D=3D 0) {
>  		zfs_log_symlink(zilog, tx, TX_SYMLINK, dzp, zp, name, link);
>  		*vpp =3D ZTOV(zp);
> -		vn_lock(*vpp, LK_EXCLUSIVE | LK_RETRY, td);
>  	}
> =20
>  	dmu_tx_commit(tx);
> Index: cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_ctldir.c
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> --- cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_ctldir.c	(revision 18874
> =
> 8)
> +++ cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_ctldir.c	(working copy)
> @@ -176,6 +176,8 @@
>  	vp->v_vflag &=3D ~VV_ROOT;
> =20
>  	zfsvfs->z_ctldir =3D vp;
> +
> +	VOP_UNLOCK(vp, 0, curthread);
>  }
> =20
>  /*
> @@ -789,6 +791,7 @@
>  	mutex_init(&sdp->sd_lock, NULL, MUTEX_DEFAULT, NULL);
>  	avl_create(&sdp->sd_snaps, snapentry_compare,
>  	    sizeof (zfs_snapentry_t), offsetof(zfs_snapentry_t, se_node));
> +	VOP_UNLOCK(vp, 0, curthread);
>  	return (vp);
>  }
> =20
> @@ -862,6 +865,7 @@
>  	    &zfsctl_ops_snapshot, NULL, NULL, MAXNAMELEN, NULL, NULL);
>  	zcp =3D vp->v_data;
>  	zcp->zc_id =3D objset;
> +	VOP_UNLOCK(vp, 0, curthread);
> =20
>  	return (vp);
>  }
> 

This fixes the panic on my testbed. I'll get a fresh copy of stable/7, 
install and test it on my other servers first, and let you know what the 
results are when I'm done.


-- 
Cheers,
Cy Schubert <Cy.Schubert@komquats.com>
FreeBSD UNIX:  <cy@FreeBSD.org>   Web:  http://www.FreeBSD.org

			e**(i*pi)+1=0


From karl at denninger.net  Wed Feb 18 09:57:20 2009
From: karl at denninger.net (Karl Denninger)
Date: Wed Feb 18 09:57:29 2009
Subject: Upgrade from 32-bit to AMD-64?
In-Reply-To: <200902181728.16842.ianjhart@ntlworld.com>
References: <4994CD7B.7040302@denninger.net>
	<499526E9.3090804@bit0.com>	<2CA7DE699281AFA5DF2BD851@syn>
	<200902181728.16842.ianjhart@ntlworld.com>
Message-ID: <499C4BFC.3050704@denninger.net>

ian j hart wrote:
> On Friday 13 February 2009 08:40:27 Goran Lowkrantz wrote:
>   
>> Hi,
>>
>> When  have done this, MySQL is OK but Berkley and PostgreSQL need
>> dump/restore.
>>
>> /glz
>>     
>
> [sorry I'm a bit late]
>
> IIRC system accounting did weird stuff until I adjusted it with rm :)
>
>   
>> --On February 13, 2009 2:53:13 -0500 Mike Andrews <mandrews@bit0.com> wrote:
>>     
>>> Xin LI wrote:
>>>       
>>>> -----BEGIN PGP SIGNED MESSAGE-----
>>>> Hash: SHA1
>>>>
>>>> Karl Denninger wrote:
>>>> [...]
>>>>
>>>>         
>>>>> I guess I need to schedule the 2-3 hours of downtime..... the reason
>>>>> for this, by the way, is that I have a dbms app on there that is
>>>>> getting too RAM hungry for its own good (its a Quadcore CPU) and I'm up
>>>>> against the RAM limit for 32-bit code.  The board will support more but
>>>>> 32-bit code won't; ergo, the only way to get beyond this is to go to
>>>>> 64-bit.
>>>>>           
>>>> Oh wait!  One thing you wanted to know is that, some database *can* have
>>>> different on-disk format for 32-bit and 64-bit binaries.  Be sure to
>>>> have a dump handy.  Last time I hit this on a MySQL "upgrade" between
>>>> two servers, and I end up using its replication functionality.  The
>>>> operation took longer time than I expected at the beginning.
>>>>         
>>> For what it's worth, I did an in-place source upgrade on our MySQL server
>>> (for the same lack-of-memory reason) and didn't have any on-disk format
>>> problems.  In fact later on when troubleshooting data corruption problems
>>> that turned out to be bad hardware, I switched between 32-bit and 64-bit
>>> mysqld binaries without rebooting or dumping/reimporting the database.
>>>
>>> BUT... there was no replication involved.  It wouldn't surprise me if the
>>> binlog or relay logs were in an architecture specific format. InnoDB and
>>> MyISAM tables don't appear to be.  This was over a year ago though, so
>>> test on a scratch box first and you may save yourself a bit of downtime.
>>>
>>> The upgrade is a pain, and does have a lot of potential foot-shooting,
>>> and you have to immediately recompile ALL of your installed ports (and
>>> anything else not built from ports) to avoid mixing 32-bit and 64-bit
>>> shared libraries...  and that rebuilding ports time is where most of your
>>> downtime comes from if it's a production box.
>>>
>>> If you're feeling lucky, the procedure's in the list archives somewhere
>>> and the super-short version is you turn your swap partition into a
>>> temporary amd64 root filesystem, installworld/kernel into that, boot into
>>> that, then mount and installworld/kernel on top of the old i386 root
>>> filesystem from there, then boot into it and recompile all your ports
>>> (after reclaiming your swap partition for swap).  Or, the way I did it
>>> last time was to boot into a PXE diskless FreeBSD/amd64 install and use
>>> that to mount/install over the i386 stuff.
>>>
>>> Definitely practice on a scratch system first. :)
>>>
>>>
>>> --
>>> Mike Andrews
>>> Server Monkey
>>> Fark, Inc
>>> mandrews@fark.com
>>>
>>>       
I have been able to come up with a procedure that works.

1. Load a new hard disk with the 64-bit code.  Perform a buildworld and 
buildkernel, and installkernel and installworld to this disk to verify 
that it will install and run.  You now have a "base" disk to use for 
migration.

2. Make sure you have a backup (:-))

3. Boot the migration hard disk as the system disk and mount the subject 
machine's disk drive(s) under /mnt.

4. Do "make DESTDIR=/mnt installkernel" and "make DESTDIR=/mnt installworld"

5. Shut down and disconnect migration disk.

6. Boot SINGLE USER and verify that the system boots, you can fsck -p 
the disks, and mount them.  The system should boot and run.

7. Come up multiuser but with any services necessary to the world 
offline.  Some of your packages may blow up when started.  If so, 
portupgrade SHOULD fix it, but this is not consistent.  I had to 
manually dump the ports tree and rebuild a few installed ports due to 
what appear to be broken dependancies, but not many.

Postgresql 32-bit runs fine without recompilation after doing this.  It 
is arguably preferrable to recompile; doing so requires a dump/restore 
of the data as the 32 and 64-bit code will NOT run off the same binary 
data store.

Attempting to "make instalkernel" on an "in-place" basis resulted in a 
system that booted but failed immediately due to loader conflicts; there 
was no way to get the rest of the codeset loaded if you make that mistake.

The "migration disk" approach appears to work fine.

-- 
--
Karl Denninger
karl@denninger.net


From karl at denninger.net  Wed Feb 18 10:08:17 2009
From: karl at denninger.net (Karl Denninger)
Date: Wed Feb 18 10:08:25 2009
Subject: Problem with new Intel DX board and i7 Processor on reboot attempt
 (locks)
Message-ID: <499C4E8E.1020403@denninger.net>

Running 7-STABLE, compiled last night.

When attempting to reboot the system freezes at "stopping other CPUs" 
and has to be hard-reset with either the power button or the RESET 
switch.  The problem is easily reproduced - typing "reboot" produces it :-)

I'm wondering if that ACPI warning in the boot sequence is involved in 
this, and if so, if there is a recommended workaround?

Here's the "dmesg" from the subject system:

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-STABLE #0: Wed Feb 18 00:38:33 CST 2009
    karl@Dbms2.denninger.net:/usr/obj/usr/src/sys/GENERIC
Timecounter "i8254" frequency 1193182 Hz quality 0
CPU: Intel(R) Core(TM) i7 CPU         920  @ 2.67GHz (2666.78-MHz 
K8-class CPU)
  Origin = "GenuineIntel"  Id = 0x106a4  Stepping = 4
  
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=0x98e3bd<SSE3,RSVD2,MON,DS_CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,<b19>,<b20>,<b23>>
  AMD Features=0x28100800<SYSCALL,NX,RDTSCP,LM>
  AMD Features2=0x1<LAHF>
  Cores per package: 8
  Logical CPUs per core: 2
usable memory = 6418419712 (6121 MB)
avail memory  = 6181691392 (5895 MB)
ACPI APIC Table: <INTEL  DX58SO  >
FreeBSD/SMP: Multiprocessor System Detected: 8 CPUs
 cpu0 (BSP): APIC ID:  0
 cpu1 (AP): APIC ID:  1
 cpu2 (AP): APIC ID:  2
 cpu3 (AP): APIC ID:  3
 cpu4 (AP): APIC ID:  4
 cpu5 (AP): APIC ID:  5
 cpu6 (AP): APIC ID:  6
 cpu7 (AP): APIC ID:  7
ACPI Warning (tbfadt-0505): Optional field "Pm2ControlBlock" has zero 
address or length:        0     450/0 [20070320]
ioapic0 <Version 2.0> irqs 0-23 on motherboard
lapic0: Forcing LINT1 to edge trigger
kbd1 at kbdmux0
ath_hal: 0.9.20.3 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413)
acpi0: <INTEL DX58SO> 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 0x408-0x40b on acpi0
acpi_button0: <Sleep 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
pcib2: <ACPI PCI-PCI bridge> irq 16 at device 3.0 on pci0
pci2: <ACPI PCI bus> on pcib2
vgapci0: <VGA-compatible display> mem 
0xd1000000-0xd1ffffff,0xe0000000-0xefffffff,0xd0000000-0xd0ffffff irq 16 
at device 0.0 on pci2
pcib3: <ACPI PCI-PCI bridge> irq 16 at device 7.0 on pci0
pci3: <ACPI PCI bus> on pcib3
3ware device driver for 9000 series storage controllers, version: 
3.70.05.001
twa0: <3ware 9000 series Storage Controller> port 0x2000-0x20ff mem 
0xf0000000-0xf1ffffff,0xd2200000-0xd2200fff irq 16 at device 0.0 on pci3
twa0: [ITHREAD]
twa0: INFO: (0x04: 0x0053): Battery capacity test is overdue:
twa0: INFO: (0x15: 0x1300): Controller details:: Model 9650SE-8LPML, 8 
ports, Firmware FE9X 4.06.00.004, BIOS BE9X 4.05.00.015
pci0: <base peripheral, interrupt controller> at device 16.0 (no driver 
attached)
pci0: <base peripheral, interrupt controller> at device 16.1 (no driver 
attached)
pci0: <base peripheral, interrupt controller> at device 20.0 (no driver 
attached)
pci0: <base peripheral, interrupt controller> at device 20.1 (no driver 
attached)
pci0: <base peripheral, interrupt controller> at device 20.2 (no driver 
attached)
pci0: <base peripheral, interrupt controller> at device 20.3 (no driver 
attached)
em0: <Intel(R) PRO/1000 Network Connection 6.9.6> port 0x30e0-0x30ff mem 
0xd2300000-0xd231ffff,0xd2322000-0xd2322fff irq 20 at device 25.0 on pci0
em0: Using MSI interrupt
em0: [FILTER]
em0: Ethernet address: 00:1c:c0:94:a5:39
uhci0: <UHCI (generic) USB controller> port 0x30c0-0x30df 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 0x30a0-0x30bf 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 0x3080-0x309f 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 0xd2321000-0xd23213ff irq 
18 at d
evice 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
pci0: <multimedia, HDA> at device 27.0 (no driver attached)
pcib4: <ACPI PCI-PCI bridge> irq 17 at device 28.0 on pci0
pci4: <ACPI PCI bus> on pcib4
pcib5: <ACPI PCI-PCI bridge> irq 16 at device 28.1 on pci0
pci5: <ACPI PCI bus> on pcib5
pcib6: <ACPI PCI-PCI bridge> irq 17 at device 28.4 on pci0
pci6: <ACPI PCI bus> on pcib6
atapci0: <Marvell 88SX6121 UDMA133 controller> port 
0x1018-0x101f,0x1024-0x1027,0x1010-0x1017,0x1020-0x1023,0x1000-0x100f 
mem 0xd2100000-0xd21003ff irq 16 at device 0.0 on pci6
atapci0: [ITHREAD]
ata2: <ATA channel 0> on atapci0
ata2: [ITHREAD]
uhci3: <UHCI (generic) USB controller> port 0x3060-0x307f 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 0x3040-0x305f 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 0x3020-0x303f 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 0xd2320000-0xd23203ff 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
pcib7: <ACPI PCI-PCI bridge> at device 30.0 on pci0
pci7: <ACPI PCI bus> on pcib7
fwohci0: <Texas Instruments TSB43AB22/A> mem 
0xd2004000-0xd20047ff,0xd2000000-0xd2003fff irq 19 at device 3.0 on pci7
fwohci0: [FILTER]
fwohci0: OHCI version 1.10 (ROM=0)
fwohci0: No. of Isochronous channels is 4.
fwohci0: EUI64 00:90:27:00:02:3f:c4:9c
fwohci0: Phy 1394a available S400, 2 ports.
fwohci0: Link S400, max_rec 2048 bytes.
firewire0: <IEEE1394(FireWire) bus> on fwohci0
dcons_crom0: <dcons configuration ROM> on firewire0
dcons_crom0: bus_addr 0x15dc000
fwe0: <Ethernet over FireWire> on firewire0
if_fwe0: Fake Ethernet address: 02:90:27:3f:c4:9c
fwe0: Ethernet address: 02:90:27:3f:c4:9c
fwip0: <IP over FireWire> on firewire0
fwip0: Firewire address: 00:90:27:00:02:3f:c4:9c @ 0xfffe00000000, S400, 
maxrec 2048
sbp0: <SBP-2/SCSI over FireWire> on firewire0
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
atapci1: <Intel ICH10 SATA300 controller> port 
0x3158-0x315f,0x316c-0x316f,0x3150-0x3157,0x3168-0x316b,0x3130-0x313f,0x3120-0x312f 
irq 19 at device 31.2 on pci0
atapci1: [ITHREAD]
ata3: <ATA channel 0> on atapci1
ata3: [ITHREAD]
ata4: <ATA channel 1> on atapci1
ata4: [ITHREAD]
pci0: <serial bus, SMBus> at device 31.3 (no driver attached)
atapci2: <Intel ICH10 SATA300 controller> port 
0x3148-0x314f,0x3164-0x3167,0x3140-0x3147,0x3160-0x3163,0x3110-0x311f,0x3100-0x310f 
irq 18 at device 31.5 on pci0
atapci2: [ITHREAD]
ata5: <ATA channel 0> on atapci2
ata5: [ITHREAD]
ata6: <ATA channel 1> on atapci2
ata6: [ITHREAD]
fdc0: <floppy drive controller> port 0x3f0-0x3f5,0x3f0 irq 6 drq 2 on acpi0
fdc0: [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
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
cpu4: <ACPI CPU> on acpi0
est4: <Enhanced SpeedStep Frequency Control> on cpu4
p4tcc4: <CPU Frequency Thermal Control> on cpu4
cpu5: <ACPI CPU> on acpi0
est5: <Enhanced SpeedStep Frequency Control> on cpu5
p4tcc5: <CPU Frequency Thermal Control> on cpu5
cpu6: <ACPI CPU> on acpi0
est6: <Enhanced SpeedStep Frequency Control> on cpu6
p4tcc6: <CPU Frequency Thermal Control> on cpu6
cpu7: <ACPI CPU> on acpi0
est7: <Enhanced SpeedStep Frequency Control> on cpu7
p4tcc7: <CPU Frequency Thermal Control> on cpu7
orm0: <ISA Option ROMs> at iomem 0xc0000-0xcefff,0xcf000-0xd0fff 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]
ppc0: cannot reserve I/O port range
sc0: <System console> at flags 0x100 on isa0
sc0: VGA <16 virtual consoles, flags=0x300>
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 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0
sio0: type 8250 or not responding
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 at port 0x2f8-0x2ff irq 3 on isa0
sio1: type 16550A
sio1: [FILTER]
vga0: <Generic ISA VGA> at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0
Timecounters tick every 1.000 msec
firewire0: 1 nodes, maxhop <= 0, cable IRM = 0 (me)
firewire0: bus manager 0 (me)
da0 at twa0 bus 0 target 0 lun 0
da0: <AMCC 9650SE-8LP DISK 4.06> Fixed Direct Access SCSI-5 device
da0: 100.000MB/s transfers
da0: 238408MB (488259584 512 byte sectors: 255H 63S/T 30392C)
da1 at twa0 bus 0 target 1 lun 0
da1: <AMCC 9650SE-8LP DISK 4.06> Fixed Direct Access SCSI-5 device
da1: 100.000MB/s transfers
da1: 238408MB (488259584 512 byte sectors: 255H 63S/T 30392C)
acd0: DVDR <SONY DVD RW DRU-V200S/1.60> at ata3-master SATA150
lapic1: Forcing LINT1 to edge trigger
SMP: AP CPU #1 Launched!
lapic4: Forcing LINT1 to edge trigger
SMP: AP CPU #4 Launched!
lapic2: Forcing LINT1 to edge trigger
SMP: AP CPU #2 Launched!
lapic5: Forcing LINT1 to edge trigger
SMP: AP CPU #5 Launched!
lapic7: Forcing LINT1 to edge trigger
SMP: AP CPU #7 Launched!
lapic3: Forcing LINT1 to edge trigger
SMP: AP CPU #3 Launched!
lapic6: Forcing LINT1 to edge trigger
SMP: AP CPU #6 Launched!
Trying to mount root from ufs:/dev/da0s1a
ukbd0: <CHESEN USB Keyboard, class 0/0, rev 1.10/1.10, addr 2> on uhub1
kbd2 at ukbd0
uhid0: <CHESEN USB Keyboard, class 0/0, rev 1.10/1.10, addr 2> on uhub1
em0: link state changed to UP

-- 
--
Karl Denninger
karl@denninger.net


From peterjeremy at optushome.com.au  Wed Feb 18 10:40:12 2009
From: peterjeremy at optushome.com.au (Peter Jeremy)
Date: Wed Feb 18 10:40:19 2009
Subject: Pendrive 8G+CAM_REQ_CMP_ERR
In-Reply-To: <5859850b0902140430r585bf77fn6d70c3ce79a0c439@mail.gmail.com>
References: <5859850b0902140430r585bf77fn6d70c3ce79a0c439@mail.gmail.com>
Message-ID: <20090218183956.GC1351@server.vk2pj.dyndns.org>

[Moved to -stable as this is not relevant to -fs]
On 2009-Feb-14 10:30:45 -0200, Sylvio C?sar Teixeira Amorim <scjamorim@bsd.com.br> wrote:
>3 Pendrive, 2 are 1, 1G and 8G, I'm using FreeBSD-7.1-stable, the problem is
>when you connect to 8G, the fbsd detects the device, da0, etc, but not
>create the / dev/da0 takes us about 10min trying to create this device, only
>appears after / dev/da0 and various error messages such as: IOERROR,
>CAM_REQ_CMP_ERR and not mounted.

You need to provide some more details of the pendrive:  What is the
probe message reported by the kernel (will be in /var/log/messages)?
What are the exact error messages (or a sample thereof)?  What does
'usbdevs -v' report about the pendrive?

-- 
Peter Jeremy
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20090218/80589771/attachment.pgp
From dougb at FreeBSD.org  Wed Feb 18 11:20:07 2009
From: dougb at FreeBSD.org (Doug Barton)
Date: Wed Feb 18 11:20:14 2009
Subject: 7-stable kernel not compiling: nlm_prot_impl.c "undefined
 reference to `nfs_*"
In-Reply-To: <a31046fc0902180919y4d032f32u4cadf46b4ae69b4d@mail.gmail.com>
References: <499B6A51.8020704@FreeBSD.org> <499BC1C1.4060204@FreeBSD.org>
	<a31046fc0902180919y4d032f32u4cadf46b4ae69b4d@mail.gmail.com>
Message-ID: <499C5F5E.7030008@FreeBSD.org>

pluknet wrote:
> 2009/2/18 Doug Barton <dougb@freebsd.org>:
>> I "solved" this by adding NFSCLIENT back to my kernel config file. I
>> had NFSSERVER and NFSLOCKD in there already. Given that this is a file
>> server system it doesn't seem logical that it would need NFSCLIENT in
>> the kernel.
>>
> 
> I talked with dfr@ about ifdef'ing client parts in NFSLOCKD some
> months ago, still without result.

Ok, Doug, any thoughts?


Doug (the other one)

-- 

    This .signature sanitized for your protection
From ianjhart at ntlworld.com  Wed Feb 18 12:13:53 2009
From: ianjhart at ntlworld.com (ian j hart)
Date: Wed Feb 18 12:14:00 2009
Subject: Upgrade from 32-bit to AMD-64?
In-Reply-To: <499C4BFC.3050704@denninger.net>
References: <4994CD7B.7040302@denninger.net>
	<200902181728.16842.ianjhart@ntlworld.com>
	<499C4BFC.3050704@denninger.net>
Message-ID: <200902182013.41196.ianjhart@ntlworld.com>

On Wednesday 18 February 2009 17:57:16 Karl Denninger wrote:
> ian j hart wrote:
> > On Friday 13 February 2009 08:40:27 Goran Lowkrantz wrote:
> >> Hi,
> >>
> >> When  have done this, MySQL is OK but Berkley and PostgreSQL need
> >> dump/restore.
> >>
> >> /glz
> >
> > [sorry I'm a bit late]
> >
> > IIRC system accounting did weird stuff until I adjusted it with rm :)
> >
> >> --On February 13, 2009 2:53:13 -0500 Mike Andrews <mandrews@bit0.com> 
wrote:
> >>> Xin LI wrote:
> >>>> -----BEGIN PGP SIGNED MESSAGE-----
> >>>> Hash: SHA1
> >>>>
> >>>> Karl Denninger wrote:
> >>>> [...]
> >>>>
> >>>>> I guess I need to schedule the 2-3 hours of downtime..... the reason
> >>>>> for this, by the way, is that I have a dbms app on there that is
> >>>>> getting too RAM hungry for its own good (its a Quadcore CPU) and I'm
> >>>>> up against the RAM limit for 32-bit code.  The board will support
> >>>>> more but 32-bit code won't; ergo, the only way to get beyond this is
> >>>>> to go to 64-bit.
> >>>>
> >>>> Oh wait!  One thing you wanted to know is that, some database *can*
> >>>> have different on-disk format for 32-bit and 64-bit binaries.  Be sure
> >>>> to have a dump handy.  Last time I hit this on a MySQL "upgrade"
> >>>> between two servers, and I end up using its replication functionality.
> >>>>  The operation took longer time than I expected at the beginning.
> >>>
> >>> For what it's worth, I did an in-place source upgrade on our MySQL
> >>> server (for the same lack-of-memory reason) and didn't have any on-disk
> >>> format problems.  In fact later on when troubleshooting data corruption
> >>> problems that turned out to be bad hardware, I switched between 32-bit
> >>> and 64-bit mysqld binaries without rebooting or dumping/reimporting the
> >>> database.
> >>>
> >>> BUT... there was no replication involved.  It wouldn't surprise me if
> >>> the binlog or relay logs were in an architecture specific format.
> >>> InnoDB and MyISAM tables don't appear to be.  This was over a year ago
> >>> though, so test on a scratch box first and you may save yourself a bit
> >>> of downtime.
> >>>
> >>> The upgrade is a pain, and does have a lot of potential foot-shooting,
> >>> and you have to immediately recompile ALL of your installed ports (and
> >>> anything else not built from ports) to avoid mixing 32-bit and 64-bit
> >>> shared libraries...  and that rebuilding ports time is where most of
> >>> your downtime comes from if it's a production box.
> >>>
> >>> If you're feeling lucky, the procedure's in the list archives somewhere
> >>> and the super-short version is you turn your swap partition into a
> >>> temporary amd64 root filesystem, installworld/kernel into that, boot
> >>> into that, then mount and installworld/kernel on top of the old i386
> >>> root filesystem from there, then boot into it and recompile all your
> >>> ports (after reclaiming your swap partition for swap).  Or, the way I
> >>> did it last time was to boot into a PXE diskless FreeBSD/amd64 install
> >>> and use that to mount/install over the i386 stuff.
> >>>
> >>> Definitely practice on a scratch system first. :)
> >>>
> >>>
> >>> --
> >>> Mike Andrews
> >>> Server Monkey
> >>> Fark, Inc
> >>> mandrews@fark.com
>
> I have been able to come up with a procedure that works.

It's a while back, but I believe this matches what I did.

I built the same major/minor revision, just in case it made any difference.

>
> 1. Load a new hard disk with the 64-bit code.  Perform a buildworld and
> buildkernel, and installkernel and installworld to this disk to verify
> that it will install and run.  You now have a "base" disk to use for
> migration.
>
> 2. Make sure you have a backup (:-))

Not optional. I broke the mirror and took a backup and I actually checked the 
backup.

>
> 3. Boot the migration hard disk as the system disk and mount the subject
> machine's disk drive(s) under /mnt.
>
> 4. Do "make DESTDIR=/mnt installkernel" and "make DESTDIR=/mnt
> installworld"
>
> 5. Shut down and disconnect migration disk.
>
> 6. Boot SINGLE USER and verify that the system boots, you can fsck -p
> the disks, and mount them.  The system should boot and run.
>
> 7. Come up multiuser but with any services necessary to the world
> offline.  Some of your packages may blow up when started.  If so,
> portupgrade SHOULD fix it, but this is not consistent.  I had to
> manually dump the ports tree and rebuild a few installed ports due to
> what appear to be broken dependancies, but not many.

I put "ports" in rc.conf.local. Makes it simple to disable them all.

IIRC I deleted them all and did pkg_add -r, which is quick enough if you don't 
have X. Save a listing first, of course.

>
> Postgresql 32-bit runs fine without recompilation after doing this.  It
> is arguably preferrable to recompile; doing so requires a dump/restore
> of the data as the 32 and 64-bit code will NOT run off the same binary
> data store.
>
> Attempting to "make instalkernel" on an "in-place" basis resulted in a
> system that booted but failed immediately due to loader conflicts; there
> was no way to get the rest of the codeset loaded if you make that mistake.
>
> The "migration disk" approach appears to work fine.



-- 
ian j hart
From info at ekipate.es  Wed Feb 18 14:25:54 2009
From: info at ekipate.es (admin)
Date: Wed Feb 18 14:26:02 2009
Subject: MEETING
Message-ID: <29aa2cc417069a294c3b8fdbd39e0411@www.ekipate.es>

Estas buscando pareja.

 <http://www.ekipate.es/lists/lt.php?id=YR5QBw0OUAUYCFpMAQ4FVAI%3D>



--
To unsubscribe from this list visit
http://www.ekipate.es/lists/lt.php?id=YR5QBw0OUAYYCFpMAQ4FVAI%3D

To update your preferences visit
http://www.ekipate.es/lists/lt.php?id=YR5QBw0OUAcYCFpMAQ4FVAI%3D



--
Powered by PHPlist, www.phplist.com --



From mike at sentex.net  Wed Feb 18 14:30:52 2009
From: mike at sentex.net (Mike Tancsa)
Date: Wed Feb 18 14:31:05 2009
Subject: Problem with new Intel DX board and i7 Processor on reboot
 attempt (locks)
In-Reply-To: <499C4E8E.1020403@denninger.net>
References: <499C4E8E.1020403@denninger.net>
Message-ID: <200902182230.n1IMUg78008294@lava.sentex.ca>

At 01:08 PM 2/18/2009, Karl Denninger wrote:
>Running 7-STABLE, compiled last night.
>
>When attempting to reboot the system freezes at "stopping other 
>CPUs" and has to be hard-reset with either the power button or the 
>RESET switch.  The problem is easily reproduced - typing "reboot" 
>produces it :-)
>
>I'm wondering if that ACPI warning in the boot sequence is involved 
>in this, and if so, if there is a recommended workaround?
>
>Here's the "dmesg" from the subject system:

Hi,
         I have the same chipset, but dont see the reboot problem on 
RELENG_7 from Jan 7th. (via "shutdown -r now")  Have you checked for 
BIOS updates ?

         ---Mike


CPU: Intel(R) Core(TM) i7 CPU         920  @ 2.67GHz (2666.77-MHz 
686-class CPU)
   Origin = "GenuineIntel"  Id = 0x106a4  Stepping = 4
   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=0x98e3bd<SSE3,DTES64,MON,DS_CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,POPCNT>
   AMD Features=0x28100000<NX,RDTSCP,LM>
   AMD Features2=0x1<LAHF>
   Cores per package: 8
   Logical CPUs per core: 2
real memory  = 3212734464 (3063 MB)
avail memory = 3139563520 (2994 MB)
ACPI APIC Table: <INTEL  DX58SO  >
FreeBSD/SMP: Multiprocessor System Detected: 8 CPUs
  cpu0 (BSP): APIC ID:  0
  cpu1 (AP): APIC ID:  1
  cpu2 (AP): APIC ID:  2
  cpu3 (AP): APIC ID:  3
  cpu4 (AP): APIC ID:  4
  cpu5 (AP): APIC ID:  5
  cpu6 (AP): APIC ID:  6
  cpu7 (AP): APIC ID:  7
ACPI Warning (tbfadt-0505): Optional field "Pm2ControlBlock" has zero 
address or length:        0     450/0 [20070320]
ioapic0 <Version 2.0> irqs 0-23 on motherboard



>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-STABLE #0: Wed Feb 18 00:38:33 CST 2009
>    karl@Dbms2.denninger.net:/usr/obj/usr/src/sys/GENERIC
>Timecounter "i8254" frequency 1193182 Hz quality 0
>CPU: Intel(R) Core(TM) i7 CPU         920  @ 2.67GHz (2666.78-MHz 
>K8-class CPU)
>  Origin = "GenuineIntel"  Id = 0x106a4  Stepping = 4
>
>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=0x98e3bd<SSE3,RSVD2,MON,DS_CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,<b19>,<b20>,<b23>>
>  AMD Features=0x28100800<SYSCALL,NX,RDTSCP,LM>
>  AMD Features2=0x1<LAHF>
>  Cores per package: 8
>  Logical CPUs per core: 2
>usable memory = 6418419712 (6121 MB)
>avail memory  = 6181691392 (5895 MB)
>ACPI APIC Table: <INTEL  DX58SO  >
>FreeBSD/SMP: Multiprocessor System Detected: 8 CPUs
>cpu0 (BSP): APIC ID:  0
>cpu1 (AP): APIC ID:  1
>cpu2 (AP): APIC ID:  2
>cpu3 (AP): APIC ID:  3
>cpu4 (AP): APIC ID:  4
>cpu5 (AP): APIC ID:  5
>cpu6 (AP): APIC ID:  6
>cpu7 (AP): APIC ID:  7
>ACPI Warning (tbfadt-0505): Optional field "Pm2ControlBlock" has 
>zero address or length:        0     450/0 [20070320]
>ioapic0 <Version 2.0> irqs 0-23 on motherboard
>lapic0: Forcing LINT1 to edge trigger
>kbd1 at kbdmux0
>ath_hal: 0.9.20.3 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413)
>acpi0: <INTEL DX58SO> 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 0x408-0x40b on acpi0
>acpi_button0: <Sleep 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
>pcib2: <ACPI PCI-PCI bridge> irq 16 at device 3.0 on pci0
>pci2: <ACPI PCI bus> on pcib2
>vgapci0: <VGA-compatible display> mem 
>0xd1000000-0xd1ffffff,0xe0000000-0xefffffff,0xd0000000-0xd0ffffff 
>irq 16 at device 0.0 on pci2
>pcib3: <ACPI PCI-PCI bridge> irq 16 at device 7.0 on pci0
>pci3: <ACPI PCI bus> on pcib3
>3ware device driver for 9000 series storage controllers, version: 3.70.05.001
>twa0: <3ware 9000 series Storage Controller> port 0x2000-0x20ff mem 
>0xf0000000-0xf1ffffff,0xd2200000-0xd2200fff irq 16 at device 0.0 on pci3
>twa0: [ITHREAD]
>twa0: INFO: (0x04: 0x0053): Battery capacity test is overdue:
>twa0: INFO: (0x15: 0x1300): Controller details:: Model 9650SE-8LPML, 
>8 ports, Firmware FE9X 4.06.00.004, BIOS BE9X 4.05.00.015
>pci0: <base peripheral, interrupt controller> at device 16.0 (no 
>driver attached)
>pci0: <base peripheral, interrupt controller> at device 16.1 (no 
>driver attached)
>pci0: <base peripheral, interrupt controller> at device 20.0 (no 
>driver attached)
>pci0: <base peripheral, interrupt controller> at device 20.1 (no 
>driver attached)
>pci0: <base peripheral, interrupt controller> at device 20.2 (no 
>driver attached)
>pci0: <base peripheral, interrupt controller> at device 20.3 (no 
>driver attached)
>em0: <Intel(R) PRO/1000 Network Connection 6.9.6> port 0x30e0-0x30ff 
>mem 0xd2300000-0xd231ffff,0xd2322000-0xd2322fff irq 20 at device 25.0 on pci0
>em0: Using MSI interrupt
>em0: [FILTER]
>em0: Ethernet address: 00:1c:c0:94:a5:39
>uhci0: <UHCI (generic) USB controller> port 0x30c0-0x30df 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 0x30a0-0x30bf 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 0x3080-0x309f 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 0xd2321000-0xd23213ff 
>irq 18 at d
>evice 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
>pci0: <multimedia, HDA> at device 27.0 (no driver attached)
>pcib4: <ACPI PCI-PCI bridge> irq 17 at device 28.0 on pci0
>pci4: <ACPI PCI bus> on pcib4
>pcib5: <ACPI PCI-PCI bridge> irq 16 at device 28.1 on pci0
>pci5: <ACPI PCI bus> on pcib5
>pcib6: <ACPI PCI-PCI bridge> irq 17 at device 28.4 on pci0
>pci6: <ACPI PCI bus> on pcib6
>atapci0: <Marvell 88SX6121 UDMA133 controller> port 
>0x1018-0x101f,0x1024-0x1027,0x1010-0x1017,0x1020-0x1023,0x1000-0x100f 
>  mem 0xd2100000-0xd21003ff irq 16 at device 0.0 on pci6
>atapci0: [ITHREAD]
>ata2: <ATA channel 0> on atapci0
>ata2: [ITHREAD]
>uhci3: <UHCI (generic) USB controller> port 0x3060-0x307f 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 0x3040-0x305f 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 0x3020-0x303f 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 0xd2320000-0xd23203ff 
>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
>pcib7: <ACPI PCI-PCI bridge> at device 30.0 on pci0
>pci7: <ACPI PCI bus> on pcib7
>fwohci0: <Texas Instruments TSB43AB22/A> mem 
>0xd2004000-0xd20047ff,0xd2000000-0xd2003fff irq 19 at device 3.0 on pci7
>fwohci0: [FILTER]
>fwohci0: OHCI version 1.10 (ROM=0)
>fwohci0: No. of Isochronous channels is 4.
>fwohci0: EUI64 00:90:27:00:02:3f:c4:9c
>fwohci0: Phy 1394a available S400, 2 ports.
>fwohci0: Link S400, max_rec 2048 bytes.
>firewire0: <IEEE1394(FireWire) bus> on fwohci0
>dcons_crom0: <dcons configuration ROM> on firewire0
>dcons_crom0: bus_addr 0x15dc000
>fwe0: <Ethernet over FireWire> on firewire0
>if_fwe0: Fake Ethernet address: 02:90:27:3f:c4:9c
>fwe0: Ethernet address: 02:90:27:3f:c4:9c
>fwip0: <IP over FireWire> on firewire0
>fwip0: Firewire address: 00:90:27:00:02:3f:c4:9c @ 0xfffe00000000, 
>S400, maxrec 2048
>sbp0: <SBP-2/SCSI over FireWire> on firewire0
>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
>atapci1: <Intel ICH10 SATA300 controller> port 
>0x3158-0x315f,0x316c-0x316f,0x3150-0x3157,0x3168-0x316b,0x3130-0x313f,0x3120-0x312f 
>irq 19 at device 31.2 on pci0
>atapci1: [ITHREAD]
>ata3: <ATA channel 0> on atapci1
>ata3: [ITHREAD]
>ata4: <ATA channel 1> on atapci1
>ata4: [ITHREAD]
>pci0: <serial bus, SMBus> at device 31.3 (no driver attached)
>atapci2: <Intel ICH10 SATA300 controller> port 
>0x3148-0x314f,0x3164-0x3167,0x3140-0x3147,0x3160-0x3163,0x3110-0x311f,0x3100-0x310f 
>irq 18 at device 31.5 on pci0
>atapci2: [ITHREAD]
>ata5: <ATA channel 0> on atapci2
>ata5: [ITHREAD]
>ata6: <ATA channel 1> on atapci2
>ata6: [ITHREAD]
>fdc0: <floppy drive controller> port 0x3f0-0x3f5,0x3f0 irq 6 drq 2 on acpi0
>fdc0: [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
>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
>cpu4: <ACPI CPU> on acpi0
>est4: <Enhanced SpeedStep Frequency Control> on cpu4
>p4tcc4: <CPU Frequency Thermal Control> on cpu4
>cpu5: <ACPI CPU> on acpi0
>est5: <Enhanced SpeedStep Frequency Control> on cpu5
>p4tcc5: <CPU Frequency Thermal Control> on cpu5
>cpu6: <ACPI CPU> on acpi0
>est6: <Enhanced SpeedStep Frequency Control> on cpu6
>p4tcc6: <CPU Frequency Thermal Control> on cpu6
>cpu7: <ACPI CPU> on acpi0
>est7: <Enhanced SpeedStep Frequency Control> on cpu7
>p4tcc7: <CPU Frequency Thermal Control> on cpu7
>orm0: <ISA Option ROMs> at iomem 0xc0000-0xcefff,0xcf000-0xd0fff 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]
>ppc0: cannot reserve I/O port range
>sc0: <System console> at flags 0x100 on isa0
>sc0: VGA <16 virtual consoles, flags=0x300>
>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 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0
>sio0: type 8250 or not responding
>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 at port 0x2f8-0x2ff irq 3 on isa0
>sio1: type 16550A
>sio1: [FILTER]
>vga0: <Generic ISA VGA> at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0
>Timecounters tick every 1.000 msec
>firewire0: 1 nodes, maxhop <= 0, cable IRM = 0 (me)
>firewire0: bus manager 0 (me)
>da0 at twa0 bus 0 target 0 lun 0
>da0: <AMCC 9650SE-8LP DISK 4.06> Fixed Direct Access SCSI-5 device
>da0: 100.000MB/s transfers
>da0: 238408MB (488259584 512 byte sectors: 255H 63S/T 30392C)
>da1 at twa0 bus 0 target 1 lun 0
>da1: <AMCC 9650SE-8LP DISK 4.06> Fixed Direct Access SCSI-5 device
>da1: 100.000MB/s transfers
>da1: 238408MB (488259584 512 byte sectors: 255H 63S/T 30392C)
>acd0: DVDR <SONY DVD RW DRU-V200S/1.60> at ata3-master SATA150
>lapic1: Forcing LINT1 to edge trigger
>SMP: AP CPU #1 Launched!
>lapic4: Forcing LINT1 to edge trigger
>SMP: AP CPU #4 Launched!
>lapic2: Forcing LINT1 to edge trigger
>SMP: AP CPU #2 Launched!
>lapic5: Forcing LINT1 to edge trigger
>SMP: AP CPU #5 Launched!
>lapic7: Forcing LINT1 to edge trigger
>SMP: AP CPU #7 Launched!
>lapic3: Forcing LINT1 to edge trigger
>SMP: AP CPU #3 Launched!
>lapic6: Forcing LINT1 to edge trigger
>SMP: AP CPU #6 Launched!
>Trying to mount root from ufs:/dev/da0s1a
>ukbd0: <CHESEN USB Keyboard, class 0/0, rev 1.10/1.10, addr 2> on uhub1
>kbd2 at ukbd0
>uhid0: <CHESEN USB Keyboard, class 0/0, rev 1.10/1.10, addr 2> on uhub1
>em0: link state changed to UP
>
>--
>--
>Karl Denninger
>karl@denninger.net
>
>
>
>
>_______________________________________________
>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 Cy.Schubert at komquats.com  Wed Feb 18 15:12:44 2009
From: Cy.Schubert at komquats.com (Cy Schubert)
Date: Wed Feb 18 15:12:51 2009
Subject: ZFS Panic 
In-Reply-To: Message from Kostik Belousov <kostikbel@gmail.com> of "Wed,
	18 Feb 2009 18:21:26 +0200."
	<20090218162126.GQ41617@deviant.kiev.zoral.com.ua> 
Message-ID: <200902182312.n1INCeb9002941@cwsys.cwsent.com>

In message <20090218162126.GQ41617@deviant.kiev.zoral.com.ua>, Kostik 
Belousov
writes:
> 
> --v+Mbu5iuT/5Blw/K
> Content-Type: text/plain; charset=us-ascii
> Content-Disposition: inline
> Content-Transfer-Encoding: quoted-printable
> 
> On Tue, Feb 17, 2009 at 09:43:31PM -0800, Cy Schubert wrote:
> > I got this panic after issuing reboot(8).
> >=20
> > FreeBSD  7.1-STABLE FreeBSD 7.1-STABLE #0: Tue Feb 17 19:29:23 PST 2009  =
>   =20
> > cy@cwsys:/export/obj/export/home/cy/test/test-stable7/sys/DEBUG  i386
> >=20
> >=20
> > FreeBSD/i386 (bob) (ttyd0)
> >=20
> > login: Feb 17 21:22:56 bob reboot: rebooted by root
> > Feb 17 21:22:56 bob syslogd: exiting on signal 15
> > Waiting (max 60 seconds) for system process `vnlru' to stop...done
> > Waiting (max 60 seconds) for system process `syncer' to stop...
> > Syncing disks, vnodes remaining...2 2 2 2 1 1 1 1 0 0 0 0 0 0 done
> > Waiting (max 60 seconds) for system process `bufdaemon' to stop...done
> > All buffers synced.
> > panic: insmntque() failed: error 16
> > cpuid =3D 0
> > KDB: enter: panic
> > [thread pid 1086 tid 100090 ]
> > Stopped at      kdb_enter_why+0x3a:     movl    $0,kdb_why
> > db> bt
> > Tracing pid 1086 tid 100090 td 0xc2bfd230
> > kdb_enter_why(c087ef4a,c087ef4a,c2b1b5b4,ebf8da58,0,...) at=20
> > kdb_enter_why+0x3a
> > panic(c2b1b5b4,10,c2b24a40,ebf8da64,c38e6000,...) at panic+0x136
> > gfs_file_create(84,c346d8a0,c342d5a0,c2b24a40,c346d8a0,...) at=20
> > gfs_file_create+0x86
> > gfs_dir_create(84,c346d8a0,c342d5a0,c2b24a40,0,...) at gfs_dir_create+0x2c
> > zfsctl_mknode_snapdir(c346d8a0,c2b1b54f,275,25d,c3419520,...) at=20
> > zfsctl_mknode_snapdir+0x53
> > gfs_dir_lookup(c346d8a0,c2b21126,ebf8db74,c091521c,ebf8db38,...) at=20
> > gfs_dir_lookup+0xd1
> > zfsctl_root_lookup(c346d8a0,c2b21126,ebf8db74,0,0,...) at=20
> > zfsctl_root_lookup+0xdc
> > zfsctl_umount_snapshots(c342d5a0,80000,c3acb800,c3216844,0,...) at=20
> > zfsctl_umount_snapshots+0x4e
> > zfs_umount(c342d5a0,80000,c2bfd230,c2bfd230,c088a687,...) at zfs_umount+0=
> x53
> > dounmount(c342d5a0,80000,c2bfd230,e26988ac,0,...) at dounmount+0x430
> > vfs_unmountall(c087ed87,0,c087edeb,128,0,...) at vfs_unmountall+0x4e
> > boot(c090b5d0,0,c087edeb,ab,ebf8dd2c,...) at boot+0x44f
> > reboot(c2bfd230,ebf8dcfc,4,c0885aef,c08c38a8,...) at reboot+0x4b
> > syscall(ebf8dd38) at syscall+0x2b3
> > Xint0x80_syscall() at Xint0x80_syscall+0x20
> > --- syscall (55, FreeBSD ELF32, reboot), eip =3D 0x280bc947, esp =3D=20
> > 0xbfbfeb7c, ebp =3D 0xbfbfebb8 ---
> > db>=20
> >=20
> > Forceably unmounting ZFS filesystems prior to issuing reboot(8) mitigates=
> =20
> > the panic.
> 
> The patch below would fix the problem, unless I mis-merged it.
> Please note that I cannot test the patch myself, so I rely on ZFS
> users testing before the commit.
> 
> Property changes on: .
> ___________________________________________________________________
> Modified: svn:mergeinfo
>    Merged /head/sys:r182781,182824,182840
> 
> 
> Property changes on: dev/cxgb
> ___________________________________________________________________
> Modified: svn:mergeinfo
>    Merged /head/sys/dev/cxgb:r182781,182824,182840
> 
> 
> Property changes on: dev/ath/ath_hal
> ___________________________________________________________________
> Modified: svn:mergeinfo
>    Merged /head/sys/dev/ath/ath_hal:r182781,182824,182840
> 
> 
> Property changes on: contrib/pf
> ___________________________________________________________________
> Modified: svn:mergeinfo
>    Merged /head/sys/contrib/pf:r182781,182824,182840
> 
> Index: cddl/contrib/opensolaris/uts/common/fs/gfs.c
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> --- cddl/contrib/opensolaris/uts/common/fs/gfs.c	(revision 188748)
> +++ cddl/contrib/opensolaris/uts/common/fs/gfs.c	(working copy)
> @@ -358,6 +358,7 @@
>  	fp =3D kmem_zalloc(size, KM_SLEEP);
>  	error =3D getnewvnode("zfs", vfsp, ops, &vp);
>  	ASSERT(error =3D=3D 0);
> +	vn_lock(vp, LK_EXCLUSIVE | LK_RETRY, curthread);
>  	vp->v_data =3D (caddr_t)fp;
> =20
>  	/*
> @@ -368,7 +369,9 @@
>  	fp->gfs_size =3D size;
>  	fp->gfs_type =3D GFS_FILE;
> =20
> +	vp->v_vflag |=3D VV_FORCEINSMQ;
>  	error =3D insmntque(vp, vfsp);
> +	vp->v_vflag &=3D ~VV_FORCEINSMQ;
>  	KASSERT(error =3D=3D 0, ("insmntque() failed: error %d", error));
> =20
>  	/*
> Index: cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_znode.c
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> --- cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_znode.c	(revision 18874
> 8)
> +++ cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_znode.c	(working copy)
> @@ -113,6 +113,7 @@
>  	if (cdrarg !=3D NULL) {
>  		error =3D getnewvnode("zfs", vfsp, &zfs_vnodeops, &vp);
>  		ASSERT(error =3D=3D 0);
> +		vn_lock(vp, LK_EXCLUSIVE | LK_RETRY, curthread);
>  		zp->z_vnode =3D vp;
>  		vp->v_data =3D (caddr_t)zp;
>  		vp->v_vnlock->lk_flags |=3D LK_CANRECURSE;
> @@ -348,7 +349,9 @@
>  	if (vp =3D=3D NULL)
>  		return (zp);
> =20
> +	vp->v_vflag |=3D VV_FORCEINSMQ;
>  	error =3D insmntque(vp, zfsvfs->z_vfs);
> +	vp->v_vflag &=3D ~VV_FORCEINSMQ;
>  	KASSERT(error =3D=3D 0, ("insmntque() failed: error %d", error));
> =20
>  	vp->v_type =3D IFTOVT((mode_t)zp->z_phys->zp_mode);
> @@ -535,8 +538,10 @@
> =20
>  		*zpp =3D zp;
>  	} else {
> -		if (ZTOV(zp) !=3D NULL)
> +		if (ZTOV(zp) !=3D NULL) {
>  			ZTOV(zp)->v_count =3D 0;
> +			VOP_UNLOCK(ZTOV(zp), 0, curthread);
> +		}
>  		dmu_buf_rele(dbp, NULL);
>  		zfs_znode_free(zp);
>  	}
> @@ -598,14 +603,18 @@
>  			    &zp->z_vnode);
>  			ASSERT(err =3D=3D 0);
>  			vp =3D ZTOV(zp);
> +			vn_lock(vp, LK_EXCLUSIVE | LK_RETRY, curthread);
>  			vp->v_data =3D (caddr_t)zp;
>  			vp->v_vnlock->lk_flags |=3D LK_CANRECURSE;
>  			vp->v_vnlock->lk_flags &=3D ~LK_NOSHARE;
>  			vp->v_type =3D IFTOVT((mode_t)zp->z_phys->zp_mode);
>  			if (vp->v_type =3D=3D VDIR)
>  				zp->z_zn_prefetch =3D B_TRUE;	/* z_prefetch d
> efault is enabled */
> +			vp->v_vflag |=3D VV_FORCEINSMQ;
>  			err =3D insmntque(vp, zfsvfs->z_vfs);
> +			vp->v_vflag &=3D ~VV_FORCEINSMQ;
>  			KASSERT(err =3D=3D 0, ("insmntque() failed: error %d", 
> err));
> +			VOP_UNLOCK(vp, 0, curthread);
>  		}
>  		mutex_exit(&zp->z_lock);
>  		ZFS_OBJ_HOLD_EXIT(zfsvfs, obj_num);
> @@ -621,6 +630,8 @@
>  	zfs_znode_dmu_init(zp);
>  	ZFS_OBJ_HOLD_EXIT(zfsvfs, obj_num);
>  	*zpp =3D zp;
> +	if ((vp =3D ZTOV(zp)) !=3D NULL)
> +		VOP_UNLOCK(vp, 0, curthread);
>  	return (0);
>  }
> =20
> Index: cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> --- cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c	(revision 18874
> 8)
> +++ cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c	(working copy)
> @@ -1303,12 +1303,6 @@
>  		}
>  	}
>  out:
> -
> -	if (error =3D=3D 0) {
> -		*vpp =3D ZTOV(zp);
> -		vn_lock(*vpp, LK_EXCLUSIVE | LK_RETRY, td);
> -	}
> -
>  	if (dl)
>  		zfs_dirent_unlock(dl);
> =20
> @@ -1588,8 +1582,6 @@
>  	zfs_log_create(zilog, tx, TX_MKDIR, dzp, zp, dirname);
>  	dmu_tx_commit(tx);
> =20
> -	vn_lock(*vpp, LK_EXCLUSIVE | LK_RETRY, curthread);
> -
>  	zfs_dirent_unlock(dl);
> =20
>  	ZFS_EXIT(zfsvfs);
> @@ -2773,7 +2765,6 @@
>  	if (error =3D=3D 0) {
>  		zfs_log_symlink(zilog, tx, TX_SYMLINK, dzp, zp, name, link);
>  		*vpp =3D ZTOV(zp);
> -		vn_lock(*vpp, LK_EXCLUSIVE | LK_RETRY, td);
>  	}
> =20
>  	dmu_tx_commit(tx);
> Index: cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_ctldir.c
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> --- cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_ctldir.c	(revision 18874
> =
> 8)
> +++ cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_ctldir.c	(working copy)
> @@ -176,6 +176,8 @@
>  	vp->v_vflag &=3D ~VV_ROOT;
> =20
>  	zfsvfs->z_ctldir =3D vp;
> +
> +	VOP_UNLOCK(vp, 0, curthread);
>  }
> =20
>  /*
> @@ -789,6 +791,7 @@
>  	mutex_init(&sdp->sd_lock, NULL, MUTEX_DEFAULT, NULL);
>  	avl_create(&sdp->sd_snaps, snapentry_compare,
>  	    sizeof (zfs_snapentry_t), offsetof(zfs_snapentry_t, se_node));
> +	VOP_UNLOCK(vp, 0, curthread);
>  	return (vp);
>  }
> =20
> @@ -862,6 +865,7 @@
>  	    &zfsctl_ops_snapshot, NULL, NULL, MAXNAMELEN, NULL, NULL);
>  	zcp =3D vp->v_data;
>  	zcp->zc_id =3D objset;
> +	VOP_UNLOCK(vp, 0, curthread);
> =20
>  	return (vp);
>  }
> 

Problem solved! Thanks.


-- 
Cheers,
Cy Schubert <Cy.Schubert@komquats.com>
FreeBSD UNIX:  <cy@FreeBSD.org>   Web:  http://www.FreeBSD.org

			e**(i*pi)+1=0


From freebsd+stable at esmtp.org  Wed Feb 18 17:05:57 2009
From: freebsd+stable at esmtp.org (Claus Assmann)
Date: Wed Feb 18 17:06:04 2009
Subject: xmodmap and Xkeyboard interaction
Message-ID: <20090219004556.GA25368@zardoc.esmtp.org>

I have a problem with xmodmap on a fresh FreeBSD 7.1 installation
(Dell Latitude D830).  My .xmodmap file looks like this:

remove Lock = Caps_Lock
keysym Caps_Lock = Control_L
add Control = Control_L
keycode  22 = backslash bar
keycode  51 = BackSpace BackSpace Delete underscore
keycode  49 = Escape asciitilde grave bar
keycode  113 = grave asciitilde
pointer = 1 2 3

That is, besides the "usual" Caps/Ctrl swap I also swap Backspace
and "\|" as well as some other keys. This worked fine in "old"
FreeBSD (X) versions, i.e., before FreeBSD 6.x. In FreeBSD 6.2 I
first noticed that "Shift Backspace" does not produce "|" but "\".
After some hacking I found that I could make it work again by using

Section "ServerFlags"
        Option          "XkbDisable"    "true"
EndSection

in /etc/X11/xorg.conf.  Trying the same trick in 7.1 does not
work at all, several things break, including function keys,
key repetition, etc.

Question: is there a way to make xmodmap work for Shift-Backspace
properly in FreeBSD 7.1?

If not, do I need to use XKEYBOARD or is there a simpler way to
achieve my keyboard remapping goals (so it looks like a "standard
UNIX" keyboard)?


PS: please reply to the list if possible. Thanks!
From info at ekipate.es  Wed Feb 18 21:30:48 2009
From: info at ekipate.es (admin)
Date: Wed Feb 18 21:31:04 2009
Subject: Publicidad
Message-ID: <0cd6ca284e3e1f0915e8a06f378aed08@www.ekipate.es>

Clic aqui si no ves la imagen
<http://www.ekipate.es/lists/lt.php?id=YR4dAQdFUQNRC1Q%3D>



--
To unsubscribe from this list visit
http://www.ekipate.es/lists/lt.php?id=YR5SBAwKVQAYC1BMAQ4FVAI%3D

To update your preferences visit
http://www.ekipate.es/lists/lt.php?id=YR5SBAwKVQEYC1BMAQ4FVAI%3D



--
Powered by PHPlist, www.phplist.com --


From eugen at kuzbass.ru  Wed Feb 18 22:46:54 2009
From: eugen at kuzbass.ru (Eugene Grosbein)
Date: Wed Feb 18 22:47:01 2009
Subject: sysctl lock in RELENG_6
References: <498FAA2A.7423AC15@kuzbass.ru>
	<20090209214822.GH9427@deviant.kiev.zoral.com.ua>
	<20090210040125.GA80054@svzserv.kemerovo.su>
	<20090210062757.GK9427@deviant.kiev.zoral.com.ua>
Message-ID: <499CFFD7.D9B202C7@kuzbass.ru>

> > Well, my 6.3-STABLE locked very often (sometimes every hour).
> > Yesterday I've upgraded it to 6.4-STABLE, applied 1.177.2.1 of the file
> > to sources, rebuilt NanoBSD image and ran it. It has not locked yet.
> Can you be slightly more scientific in your tests ?
> Try RELENG_6 without my patch to see whether it is needed at all.

It locked again today running recent 6.4-STABLE without your patch.
There is a difference - it took more than a week to lock,
6.3-STABLE did this very often.

Now I'll run it with your patch applied.

Eugene Grosbein
From sclark46 at earthlink.net  Thu Feb 19 04:22:28 2009
From: sclark46 at earthlink.net (Stephen Clark)
Date: Thu Feb 19 04:22:36 2009
Subject: Unhappy Xorg upgrade
In-Reply-To: <6B7ABE80-35AB-4C44-B5A4-200E10DCC3AC@airwired.net>
References: <6B7ABE80-35AB-4C44-B5A4-200E10DCC3AC@airwired.net>
Message-ID: <499D4ED5.4030808@earthlink.net>

Dan Allen wrote:
>> While this enabled the mouse (without HAL), it did nothing good about:
>>
>>    a. The bogus keyboard scans.
> Everyone is talking about an xorg.conf
> The new X.org 7.4 upgrade hit me too: no keyboard & no mouse!  Bummer.
> I found that if I simply added to /etc/rc.conf:
>   hald_enable="YES"
> that things now work for me.
> Previously I never have had hald in my rc.conf.
> Hope this helps.
> Dan
> 
> _______________________________________________
> 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"
> 
List,

After finally getting everything rebuilt (2.5 days) for this upgrade I am now 
getting
in my Xorg.0.log:

(II) Loading /usr/local/lib/xorg/modules/extensions//vnc.so
dlopen: /usr/local/lib/xorg/modules/extensions//vnc.so: Undefined symbol 
"NumCurrentSelections"
(EE) Failed to load /usr/local/lib/xorg/modules/extensions//vnc.so
(II) UnloadModule: "vnc"
(EE) Failed to load module "vnc" (loader failed, 7)

anyone know how to fix this? It was very convenient to be able to run
vncviewer without first having to ssh in and start vncserver by hand.

Thanks,
Steve

-- 

"They that give up essential liberty to obtain temporary safety,
deserve neither liberty nor safety."  (Ben Franklin)

"The course of history shows that as a government grows, liberty
decreases."  (Thomas Jefferson)


From karl at denninger.net  Thu Feb 19 05:48:39 2009
From: karl at denninger.net (Karl Denninger)
Date: Thu Feb 19 05:48:51 2009
Subject: Problem with new Intel DX board and i7 Processor on reboot [SB
 QUAR: Wed Feb 18 16:30:48 2009]  attempt (locks)
In-Reply-To: <200902182230.n1IMUg78008294@lava.sentex.ca>
References: <499C4E8E.1020403@denninger.net>
	<200902182230.n1IMUg78008294@lava.sentex.ca>
Message-ID: <499D6334.5000509@denninger.net>

Mike Tancsa wrote:
> At 01:08 PM 2/18/2009, Karl Denninger wrote:
>> Running 7-STABLE, compiled last night.
>>
>> When attempting to reboot the system freezes at "stopping other CPUs" 
>> and has to be hard-reset with either the power button or the RESET 
>> switch.  The problem is easily reproduced - typing "reboot" produces 
>> it :-)
>>
>> I'm wondering if that ACPI warning in the boot sequence is involved 
>> in this, and if so, if there is a recommended workaround?
>>
>> Here's the "dmesg" from the subject system:
>
> Hi,
>         I have the same chipset, but dont see the reboot problem on 
> RELENG_7 from Jan 7th. (via "shutdown -r now")  Have you checked for 
> BIOS updates ?
>
>         ---Mike
It appears there IS a bios update, and it may have resolved this.

BTW this board is smoking fast and runs well with 7.1/amd64.  I'm liking 
it - a lot - paired with a 3ware disk I/O board.

-- 
--
Karl Denninger
karl@denninger.net


From dimitry at andric.com  Thu Feb 19 07:39:31 2009
From: dimitry at andric.com (Dimitry Andric)
Date: Thu Feb 19 07:39:39 2009
Subject: Unhappy Xorg upgrade
In-Reply-To: <499D4ED5.4030808@earthlink.net>
References: <6B7ABE80-35AB-4C44-B5A4-200E10DCC3AC@airwired.net>
	<499D4ED5.4030808@earthlink.net>
Message-ID: <499D7D32.1020909@andric.com>

On 2009-02-19 13:21, Stephen Clark wrote:
> (II) Loading /usr/local/lib/xorg/modules/extensions//vnc.so
> dlopen: /usr/local/lib/xorg/modules/extensions//vnc.so: Undefined symbol 
> "NumCurrentSelections"

This is a VNC problem, it uses an old API which has been removed in
newer X.org servers:

http://cgit.freedesktop.org/xorg/xserver/commit/?id=34bf308a9e66f1a2f48630a15b1802afad50ec24

See also here (and for possible workarounds):

https://bugs.launchpad.net/bugs/260815
From rnoland at FreeBSD.org  Thu Feb 19 10:22:14 2009
From: rnoland at FreeBSD.org (Robert Noland)
Date: Thu Feb 19 10:22:21 2009
Subject: Unhappy Xorg upgrade
In-Reply-To: <499D7D32.1020909@andric.com>
References: <6B7ABE80-35AB-4C44-B5A4-200E10DCC3AC@airwired.net>
	<499D4ED5.4030808@earthlink.net>  <499D7D32.1020909@andric.com>
Message-ID: <1235067723.9871.41.camel@widget.2hip.net>

On Thu, 2009-02-19 at 16:39 +0100, Dimitry Andric wrote:
> On 2009-02-19 13:21, Stephen Clark wrote:
> > (II) Loading /usr/local/lib/xorg/modules/extensions//vnc.so
> > dlopen: /usr/local/lib/xorg/modules/extensions//vnc.so: Undefined symbol 
> > "NumCurrentSelections"
> 
> This is a VNC problem, it uses an old API which has been removed in
> newer X.org servers:
> 
> http://cgit.freedesktop.org/xorg/xserver/commit/?id=34bf308a9e66f1a2f48630a15b1802afad50ec24
> 
> See also here (and for possible workarounds):
> 
> https://bugs.launchpad.net/bugs/260815

This is best directed to tight-vnc maintainer, cc'd

robert.

-- 
Robert Noland <rnoland@FreeBSD.org>
FreeBSD

From itetcu at FreeBSD.org  Thu Feb 19 11:30:36 2009
From: itetcu at FreeBSD.org (Ion-Mihai Tetcu)
Date: Thu Feb 19 11:30:43 2009
Subject: Unhappy Xorg upgrade
In-Reply-To: <1235067723.9871.41.camel@widget.2hip.net>
References: <6B7ABE80-35AB-4C44-B5A4-200E10DCC3AC@airwired.net>
	<499D4ED5.4030808@earthlink.net> <499D7D32.1020909@andric.com>
	<1235067723.9871.41.camel@widget.2hip.net>
Message-ID: <20090219211200.3cdb6a92@it.buh.tecnik93.com>

On Thu, 19 Feb 2009 12:22:03 -0600
Robert Noland <rnoland@FreeBSD.org> wrote:

> On Thu, 2009-02-19 at 16:39 +0100, Dimitry Andric wrote:
> > On 2009-02-19 13:21, Stephen Clark wrote:
> > > (II) Loading /usr/local/lib/xorg/modules/extensions//vnc.so
> > > dlopen: /usr/local/lib/xorg/modules/extensions//vnc.so: Undefined
> > > symbol "NumCurrentSelections"
> > 
> > This is a VNC problem, it uses an old API which has been removed in
> > newer X.org servers:
> > 
> > http://cgit.freedesktop.org/xorg/xserver/commit/?id=34bf308a9e66f1a2f48630a15b1802afad50ec24
> > 
> > See also here (and for possible workarounds):
> > 
> > https://bugs.launchpad.net/bugs/260815
> 
> This is best directed to tight-vnc maintainer, cc'd

Thanks Robert.

I also have a PR on about this port, I hope to have time to work on
both this issues this weekend.

-- 
IOnut - Un^d^dregistered ;) FreeBSD "user"
  "Intellectual Property" is   nowhere near as valuable   as "Intellect"
FreeBSD committer -> itetcu@FreeBSD.org, PGP Key ID 057E9F8B493A297B
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20090219/d4f6db47/signature.pgp
From gamato at users.sf.net  Thu Feb 19 15:30:21 2009
From: gamato at users.sf.net (martinko)
Date: Thu Feb 19 15:30:28 2009
Subject: What is the real number of CPUs ? -- was: Re: Problem with new Intel
 DX board and i7 Processor on reboot   attempt (locks)
In-Reply-To: <200902182230.n1IMUg78008294@lava.sentex.ca>
References: <499C4E8E.1020403@denninger.net>
	<200902182230.n1IMUg78008294@lava.sentex.ca>
Message-ID: <gnkq1s$d3i$1@ger.gmane.org>

Mike Tancsa wrote:
> At 01:08 PM 2/18/2009, Karl Denninger wrote:
>> Running 7-STABLE, compiled last night.
>>
>> When attempting to reboot the system freezes at "stopping other CPUs" 
>> and has to be hard-reset with either the power button or the RESET 
>> switch.  The problem is easily reproduced - typing "reboot" produces 
>> it :-)
>>
>> I'm wondering if that ACPI warning in the boot sequence is involved in 
>> this, and if so, if there is a recommended workaround?
>>
>> Here's the "dmesg" from the subject system:
> 
> Hi,
>         I have the same chipset, but dont see the reboot problem on 
> RELENG_7 from Jan 7th. (via "shutdown -r now")  Have you checked for 
> BIOS updates ?
> 
>         ---Mike
> 
> 
> CPU: Intel(R) Core(TM) i7 CPU         920  @ 2.67GHz (2666.77-MHz 
> 686-class CPU)
>   Origin = "GenuineIntel"  Id = 0x106a4  Stepping = 4
>   
> 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=0x98e3bd<SSE3,DTES64,MON,DS_CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,POPCNT> 
> 
>   AMD Features=0x28100000<NX,RDTSCP,LM>
>   AMD Features2=0x1<LAHF>
>   Cores per package: 8
>   Logical CPUs per core: 2
> real memory  = 3212734464 (3063 MB)
> avail memory = 3139563520 (2994 MB)
> ACPI APIC Table: <INTEL  DX58SO  >
> FreeBSD/SMP: Multiprocessor System Detected: 8 CPUs
>  cpu0 (BSP): APIC ID:  0
>  cpu1 (AP): APIC ID:  1
>  cpu2 (AP): APIC ID:  2
>  cpu3 (AP): APIC ID:  3
>  cpu4 (AP): APIC ID:  4
>  cpu5 (AP): APIC ID:  5
>  cpu6 (AP): APIC ID:  6
>  cpu7 (AP): APIC ID:  7
> ACPI Warning (tbfadt-0505): Optional field "Pm2ControlBlock" has zero 
> address or length:        0     450/0 [20070320]
> ioapic0 <Version 2.0> irqs 0-23 on motherboard
> 

Hi,

I don't get the numbers of CPUs -- AFAIK Core i7 has 4 cores with 2 
logical CPUs per core (hyper-threading?) and that makes 8 logical CPUs. 
  Above I see 8 cores per package (!) _but_ 8 x 2 = 16 while only 8 CPUs 
are detected and started.  Could someone explain pls ?

Cheers,

M.

From info at ekipate.es  Thu Feb 19 21:16:17 2009
From: info at ekipate.es (Webmaster)
Date: Thu Feb 19 21:16:25 2009
Subject: Goodbye from our Newsletter
Message-ID: <0c68f29ef23000489763778bfcb07bba@www.ekipate.es>


  
  Goodbye from our Newsletter, sorry to see you go.

  You have been unsubscribed from our newsletters.

  This is the last email you will receive from us. We have added you to our
  "blacklist", which means that our newsletter system will refuse to send
  you any other email, without manual intervention by our administrator.

  If there is an error in this information, you can re-subscribe:
  please go to http://www.ekipate.es/lists/?p=subscribe and follow the
steps.

  Thank you
  
  


From jfarmer at goldsword.com  Thu Feb 19 21:52:52 2009
From: jfarmer at goldsword.com (jfarmer@goldsword.com)
Date: Thu Feb 19 21:53:00 2009
Subject: Goodbye from our Newsletter
In-Reply-To: <0c68f29ef23000489763778bfcb07bba@www.ekipate.es>
References: <0c68f29ef23000489763778bfcb07bba@www.ekipate.es>
Message-ID: <20090220001855.n0lx23sjty8c80sw@www.goldsword.com>

Quoting Webmaster <info@ekipate.es>:
>   Goodbye from our Newsletter, sorry to see you go.
>
>   You have been unsubscribed from our newsletters.
>

Hurray!


-----------------------------------------------------------------
J. T. Farmer <jfarmer@goldsword.com>    <jfarmer@orfencer.org>
GoldSword Systems, Knoxville TN          Coach & Instructor
    Consulting,                     Knoxville Academy of the Blade
     Software Development,              Maryville Fencing Club
      Project Management


From pluknet at gmail.com  Fri Feb 20 01:56:06 2009
From: pluknet at gmail.com (pluknet)
Date: Fri Feb 20 01:56:12 2009
Subject: What is the real number of CPUs ? -- was: Re: Problem with new 
	Intel DX board and i7 Processor on reboot attempt (locks)
In-Reply-To: <gnkq1s$d3i$1@ger.gmane.org>
References: <499C4E8E.1020403@denninger.net>
	<200902182230.n1IMUg78008294@lava.sentex.ca>
	<gnkq1s$d3i$1@ger.gmane.org>
Message-ID: <a31046fc0902200156y1a56c9bcr1499b4b7cfd6d2ee@mail.gmail.com>

2009/2/20 martinko <gamato@users.sf.net>:
> Mike Tancsa wrote:
>>
>> At 01:08 PM 2/18/2009, Karl Denninger wrote:
>>>
>>> Running 7-STABLE, compiled last night.
>>>
>>> When attempting to reboot the system freezes at "stopping other CPUs" and
>>> has to be hard-reset with either the power button or the RESET switch. ?The
>>> problem is easily reproduced - typing "reboot" produces it :-)
>>>
>>> I'm wondering if that ACPI warning in the boot sequence is involved in
>>> this, and if so, if there is a recommended workaround?
>>>
>>> Here's the "dmesg" from the subject system:
>>
>> Hi,
>> ? ? ? ?I have the same chipset, but dont see the reboot problem on
>> RELENG_7 from Jan 7th. (via "shutdown -r now") ?Have you checked for BIOS
>> updates ?
>>
>> ? ? ? ?---Mike
>>
>>
>> CPU: Intel(R) Core(TM) i7 CPU ? ? ? ? 920 ?@ 2.67GHz (2666.77-MHz
>> 686-class CPU)
>> ?Origin = "GenuineIntel" ?Id = 0x106a4 ?Stepping = 4
>>
>> ?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=0x98e3bd<SSE3,DTES64,MON,DS_CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,POPCNT>
>> ?AMD Features=0x28100000<NX,RDTSCP,LM>
>> ?AMD Features2=0x1<LAHF>
>> ?Cores per package: 8
>> ?Logical CPUs per core: 2
>> real memory ?= 3212734464 (3063 MB)
>> avail memory = 3139563520 (2994 MB)
>> ACPI APIC Table: <INTEL ?DX58SO ?>
>> FreeBSD/SMP: Multiprocessor System Detected: 8 CPUs
>> ?cpu0 (BSP): APIC ID: ?0
>> ?cpu1 (AP): APIC ID: ?1
>> ?cpu2 (AP): APIC ID: ?2
>> ?cpu3 (AP): APIC ID: ?3
>> ?cpu4 (AP): APIC ID: ?4
>> ?cpu5 (AP): APIC ID: ?5
>> ?cpu6 (AP): APIC ID: ?6
>> ?cpu7 (AP): APIC ID: ?7
>> ACPI Warning (tbfadt-0505): Optional field "Pm2ControlBlock" has zero
>> address or length: ? ? ? ?0 ? ? 450/0 [20070320]
>> ioapic0 <Version 2.0> irqs 0-23 on motherboard
>>
>
> Hi,
>
> I don't get the numbers of CPUs -- AFAIK Core i7 has 4 cores with 2 logical
> CPUs per core (hyper-threading?) and that makes 8 logical CPUs. ?Above I see
> 8 cores per package (!) _but_ 8 x 2 = 16 while only 8 CPUs are detected and
> started. ?Could someone explain pls ?

The term "package" implies a physical socket.

-- 
wbr,
pluknet
From ardovm at yahoo.it  Fri Feb 20 04:08:01 2009
From: ardovm at yahoo.it (Arrigo Marchiori)
Date: Fri Feb 20 04:08:09 2009
Subject: Page fault panic in scioctl and console-kit-daemon
Message-ID: <20090220110748.GA9652@snail.casa>

Hello everybody,

I'm reporting a problem that looks _very_ similar to one reported on
freebsd-current@ last year, by Pawel Worach:
http://lists.freebsd.org/pipermail/freebsd-current/2008-January/082581.html

My system is a 6.4-STABLE, with up-to-date /usr/src and /usr/ports:

$ uname -a
FreeBSD diavoletto 6.4-STABLE FreeBSD 6.4-STABLE #19: Mon Feb 16 12:01:24 CET
2009     root@diavoletto:/usr/obj/usr/src/sys/GENERIC  i386

In /etc/rc.conf I have the following lines:
> dbus_enable="YES"
> hald_enable="YES"

Every time dbus is started, if consolekit-0.3.0 is installed then a
page fault occurs just after the login screen is shown. If I "make
deinstall" the port in single-user-mode, then the system boots and
works fine.

If I boot with consolekit uninstalled, then install it and restart
dbus, I get a panic.

I'm reporting here the same information that Pawel Worach reported
last year for his problem. Please tell me if I can provide any more
information; this is my very first problem report here!

----8<--------8<--------8<--------8<--------8<--------8<--------8<---------
Script started on Fri Feb 20 12:47:10 2009
# cd /usr/obj/usr/src/sys/GENERIC
# 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:


Fatal trap 12: page fault while in kernel mode
fault virtual address	= 0x4
fault code		= supervisor read, page not present
instruction pointer	= 0x20:0xc09dfaef
stack pointer	        = 0x28:0xe85a8bf8
frame pointer	        = 0x28:0xe85a8c40
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		= 14500 (console-kit-daemon)
trap number		= 12
panic: page fault
Uptime: 30m41s
Dumping 1471 MB (2 chunks)
  chunk 0: 1MB (155 pages) ... ok
  chunk 1: 1471MB (376496 pages) (CTRL-C to abort)  1455 1439 1423 1407 (CTRL-C to abort)  1391 1375 1359 1343 1327 1311 1295 1279 1263 1247 1231 1215 1199 1183 1167 1151 1135 1119 1103 1087 1071 1055 1039 1023 1007 991 975 959 943 927 911 895 879 863 847 831 815 799 783 767 751 735 719 703 687 671 655 639 623 607 591 575 559 543 527 511 495 479 463 447 431 415 399 383 367 351 335 319 303 287 271 255 239 223 207 191 175 159 143 127 111 95 79 63 47 31 15

Reading symbols from /boot/kernel/linux.ko...done.
Loaded symbols for /boot/kernel/linux.ko
Reading symbols from /boot/kernel/snd_hda.ko...done.
Loaded symbols for /boot/kernel/snd_hda.ko
Reading symbols from /boot/kernel/sound.ko...done.
Loaded symbols for /boot/kernel/sound.ko
Reading symbols from /boot/kernel/acpi.ko...done.
Loaded symbols for /boot/kernel/acpi.ko
Reading symbols from /usr/local/modules/fuse.ko...done.
Loaded symbols for /usr/local/modules/fuse.ko
Reading symbols from /boot/kernel/green_saver.ko...done.
Loaded symbols for /boot/kernel/green_saver.ko
#0  doadump () at pcpu.h:165
165		__asm __volatile("movl %%fs:0,%0" : "=r" (td));
(kgdb) backtrace
#0  doadump () at pcpu.h:165
#1  0xc072b274 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:410
#2  0xc072b5a6 in panic (fmt=0xc0a66e6f "%s")
    at /usr/src/sys/kern/kern_shutdown.c:566
#3  0xc0a02f2c in trap_fatal (frame=0xe85a8bb8, eva=0)
    at /usr/src/sys/i386/i386/trap.c:838
#4  0xc0a02c32 in trap_pfault (frame=0xe85a8bb8, usermode=0, eva=4)
    at /usr/src/sys/i386/i386/trap.c:745
#5  0xc0a027e2 in trap (frame=
      {tf_fs = 8, tf_es = 40, tf_ds = 40, tf_edi = 9, tf_esi = -977926144, tf_ebp = -396719040, tf_isp = -396719132, tf_ebx = -1061927328, tf_edx = -978051584, tf_ecx = 2000, tf_eax = 0, tf_trapno = 12, tf_err = 0, tf_eip = -1063388433, tf_cs = 32, tf_eflags = 66182, tf_esp = -978051584, tf_ss = -977926144})
    at /usr/src/sys/i386/i386/trap.c:435
#6  0xc09ec99a in calltrap () at /usr/src/sys/i386/i386/exception.s:139
#7  0xc09dfaef in scioctl (dev=0xc5b63200, cmd=9, data=0xe85a8cbc "\n", 
    flag=1, td=0xc6416900) at /usr/src/sys/dev/syscons/syscons.c:1060
#8  0xc06f489c in giant_ioctl (dev=0xc5b63200, cmd=0, data=0x0, fflag=0, 
    td=0x0) at /usr/src/sys/kern/kern_conf.c:330
#9  0xc06c8f19 in devfs_ioctl_f (fp=0xc60fdc60, com=537163270, 
    data=0xe85a8cbc, cred=0xc7845280, td=0xc6416900)
    at /usr/src/sys/fs/devfs/devfs_vnops.c:480
#10 0xc0755007 in ioctl (td=0xc6416900, uap=0xe85a8d04) at file.h:265
#11 0xc0a03302 in syscall (frame=
---Type <return> to continue, or q <return> to quit---
      {tf_fs = 59, tf_es = 59, tf_ds = 59, tf_edi = 10, tf_esi = 134714152, tf_ebp = -1081716952, tf_isp = -396718748, tf_ebx = 134627884, tf_edx = 135049216, tf_ecx = -1, tf_eax = 54, tf_trapno = 12, tf_err = 2, tf_eip = 675581607, tf_cs = 51, tf_eflags = 642, tf_esp = -1081717012, tf_ss = 59})
    at /usr/src/sys/i386/i386/trap.c:984
#12 0xc09ec9ef in Xint0x80_syscall ()
    at /usr/src/sys/i386/i386/exception.s:200
#13 0x00000033 in ?? ()
Previous frame inner to this frame (corrupt stack?)
(kgdb) frame 7
#7  0xc09dfaef in scioctl (dev=0xc5b63200, cmd=9, data=0xe85a8cbc "\n", 
    flag=1, td=0xc6416900) at /usr/src/sys/dev/syscons/syscons.c:1060
1060		scp = sc_get_stat(SC_DEV(sc, i));
(kgdb) print sc
$1 = (sc_softc_t *) 0xc0ba20c0
(kgdb) print *sc
$2 = {unit = 0, config = 768, flags = 196608, keyboard = 1, kbd = 0xc59fc700, 
  adapter = 0, adp = 0xc0b7e3a0, initial_mode = 24, first_vty = 0, vtys = 16, 
  dev = 0xc0b9a440, cur_scp = 0xc0b9a300, new_scp = 0xc0b9a300, 
  old_scp = 0xc0b9a300, delayed_next_scr = 0, 
  font_loading_in_progress = 0 '\0', switch_in_progress = 0 '\0', 
  videoio_in_progress = 0 '\0', write_in_progress = 0 '\0', 
  blink_in_progress = 0 '\0', scrn_time_stamp = 1841, dflt_curs_attr = {
    flags = 0, base = 1, height = 2}, curs_attr = {flags = 0, base = 1, 
    height = 2}, 
  scr_map = "\000\001\002\003\004\005\006\a\b\t\n\v\f\r\016\017\020\021\022\023\024\025\026\027\030\031\032\033\034\035\036\037 !\"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\\]^_`abcdefghijklmnopqrstuvwxyz{|}~\177\200\201\202\203\204\205\206\207\210\211\212\213\214\215\216\217\220\221\222\223\224\225\226\227\230\231\232\233\234\235\236\237????????????????????????????????????????"..., 
  scr_rmap = "\000\001\002\003\004\005\006\a\b\t\n\v\f\r\016\017\020\021\022\023\024\025\026\027\030\031\032\033\034\035\036\037 !\"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\\]^_`abcdefghijklmnopqrstuvwxyz{|}~\177\200\201\202\203\204\205\206\207\210\211\212\213\214\215\216\217\220\221\222\223\224\225\226\227\230\231\232\233\234\235\236\237????????????????????????????????????????"..., 
  palette = "\000\000\000\000\000?\000?\000\000???\000\000?\000???\000???\000\000T\000\000?\000?T\000???\000T?\000???T???\000T\000\000T?\000?\000\000???T\000?T???\000???\000TT\000T?\000?T\000???TT?T???T???T\000\000T\000?T?\000T???\000\00---Type <return> to continue, or q <return> to quit---
0?\000???\000???T\000TT\000?T?TT???\000T?\000???T???TT\000TT?T?\000T???T\000?T???\000???TTTTT?T?TT???TT?T???T????||?\234|??"..., fonts_loaded = 8, 
  font_8 = 0xc0b97ce0 "", font_14 = 0xc0b984e0 "", font_16 = 0xc0b992e0 "", 
  font_22 = 0x0, cursor_char = 7 '\a', mouse_char = 208 '?'}
(kgdb) list
1055		s = spltty();
1056		error = sc_clean_up(sc->cur_scp);
1057		splx(s);
1058		if (error)
1059		    return error;
1060		scp = sc_get_stat(SC_DEV(sc, i));
1061		if (scp == scp->sc->cur_scp)
1062		    return 0;
1063		error = tsleep(&scp->smode, PZERO | PCATCH, "waitvt", 0);
1064		return error;
(kgdb) print i
$3 = 9
(kgdb) print sc->dev
$4 = (struct cdev **) 0xc0b9a440
(kgdb) print *sc->dev
$5 = (struct cdev *) 0xc5b52100
(kgdb) print **sc->dev
$6 = {si_priv = 0xc5b52100, si_flags = 4, si_atime = {tv_sec = 1235125168, 
    tv_nsec = 0}, si_ctime = {tv_sec = 1235125168, tv_nsec = 0}, si_mtime = {
    tv_sec = 1235125168, tv_nsec = 0}, si_uid = 0, si_gid = 0, si_mode = 384, 
  si_cred = 0x0, si_drv0 = 0, si_refcount = 2, si_list = {le_next = 0x0, 
    le_prev = 0xc5b52238}, si_clone = {le_next = 0x0, le_prev = 0x0}, 
  si_children = {lh_first = 0x0}, si_siblings = {le_next = 0x0, 
    le_prev = 0x0}, si_parent = 0x0, si_name = 0xc5b52178 "ttyv0", 
  si_drv1 = 0xc0b9a300, si_drv2 = 0x0, si_devsw = 0xc0b44660, 
  si_iosize_max = 65536, si_usecount = 2, si_threadcount = 2, __si_u = {
    __sit_tty = 0xc5b58400, __sid_snapdata = 0xc5b58400}, 
  __si_namebuf = "ttyv0", '\0' <repeats 58 times>}
(kgdb) print sc->first_vty
$7 = 0
(kgdb)
----8<--------8<--------8<--------8<--------8<--------8<--------8<---------

-- 
rigo

http://rigo.altervista.org
From mike at sentex.net  Fri Feb 20 10:52:26 2009
From: mike at sentex.net (Mike Tancsa)
Date: Fri Feb 20 10:55:44 2009
Subject: What is the real number of CPUs ? -- was: Re: Problem with
 new Intel DX board and i7 Processor on reboot   attempt (locks)
In-Reply-To: <gnkq1s$d3i$1@ger.gmane.org>
References: <499C4E8E.1020403@denninger.net>
	<200902182230.n1IMUg78008294@lava.sentex.ca>
	<gnkq1s$d3i$1@ger.gmane.org>
Message-ID: <200902201852.n1KIqNp5007330@lava.sentex.ca>

At 06:30 PM 2/19/2009, martinko wrote:

>Hi,
>
>I don't get the numbers of CPUs -- AFAIK Core i7 has 4 cores with 2 
>logical CPUs per core (hyper-threading?) and that makes 8 logical 
>CPUs.  Above I see 8 cores per package (!) _but_ 8 x 2 = 16 while 
>only 8 CPUs are detected and started.  Could someone explain pls ?

The CPU is as you said, 4 actual cores plus their new HT tech.  In 
the tests I did, the HT did help with compile times under RELENG_7

http://lists.freebsd.org/pipermail/freebsd-performance/2008-December/003635.html

         ---Mike 

From ghelmer at palisadesys.com  Fri Feb 20 13:17:34 2009
From: ghelmer at palisadesys.com (Guy Helmer)
Date: Fri Feb 20 13:21:02 2009
Subject: 7.1-release hangs
Message-ID: <499F1DE4.4070805@palisadesys.com>

Still chasing a hang that has dogged me for quite some time.  This time 
I noticed the console logging output showed that processing stopped 
right on the five-minute interval when cron would have kicked off 
bsdsar, which in turn ran vmstat.  The system is a Supermicro P4PDE 
motherboard with dual Xeons and hyperthreading enabled.

Kernel debugging results are available at 
http://www.palisadesys.com/~ghelmer/crash-20090220.txt
If anyone cares to take a look, I would be grateful.

Guy Helmer
From daichi at freebsd.org  Sat Feb 21 01:52:32 2009
From: daichi at freebsd.org (Daichi GOTO)
Date: Sat Feb 21 01:52:39 2009
Subject: unionfs panic in 7.1
In-Reply-To: <95E82F15-2535-4C67-BDF0-44CFC7EB9FBB@mouf.net>
References: <95E82F15-2535-4C67-BDF0-44CFC7EB9FBB@mouf.net>
Message-ID: <499FCAD4.8000006@freebsd.org>

Steve Wills wrote:
> Hi,
> 
> I've found an reproducable panic in unionfs on 7.1-R.
> 
> /usr/src/sys/fs/unionfs/union_subr.c is:
>      $FreeBSD: src/sys/fs/unionfs/union_subr.c,v 1.92.2.7.2.2 2008/12/15 
> 03:58:55 daichi Exp $
> 
> kgdb output is below.
> 
> kgdb /boot/kernel/kernel.symbols /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 "amd64-marcel-freebsd"...
> 
> Unread portion of the kernel message buffer:
> 
> stack pointer            = 0x10:0xffffffffb0e1a8b0
> frame pointer            = 0x10:0xffffffffb0e1a8d0
> 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        = 72036 (make)
> panic: from debugger
> cpuid = 0
> Uptime: 49m32s
> Physical memory: 2034 MB
> Dumping 441 MB: 426 410 394 378 362 346 330 314 298 282 266 250 234 218 
> 202 186 170 154 138 122 106 90 74 58 42 26 10
> 
> Reading symbols from /boot/kernel/if_tap.ko...Reading symbols from 
> /boot/kernel/if_tap.ko.symbols...done.
> done.
> Loaded symbols for /boot/kernel/if_tap.ko
> Reading symbols from /boot/kernel/snd_hda.ko...Reading symbols from 
> /boot/kernel/snd_hda.ko.symbols...done.
> done.
> Loaded symbols for /boot/kernel/snd_hda.ko
> Reading symbols from /boot/kernel/sound.ko...Reading symbols from 
> /boot/kernel/sound.ko.symbols...done.
> done.
> Loaded symbols for /boot/kernel/sound.ko
> Reading symbols from /boot/kernel/atapicam.ko...Reading symbols from 
> /boot/kernel/atapicam.ko.symbols...done.
> done.
> Loaded symbols for /boot/kernel/atapicam.ko
> Reading symbols from /boot/kernel/smb.ko...Reading symbols from 
> /boot/kernel/smb.ko.symbols...done.
> done.
> Loaded symbols for /boot/kernel/smb.ko
> Reading symbols from /boot/kernel/smbus.ko...Reading symbols from 
> /boot/kernel/smbus.ko.symbols...done.
> done.
> Loaded symbols for /boot/kernel/smbus.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
> Reading symbols from /boot/kernel/zfs.ko...Reading symbols from 
> /boot/kernel/zfs.ko.symbols...done.
> done.
> Loaded symbols for /boot/kernel/zfs.ko
> Reading symbols from /boot/kernel/opensolaris.ko...Reading symbols from 
> /boot/kernel/opensolaris.ko.symbols...done.
> done.
> Loaded symbols for /boot/kernel/opensolaris.ko
> Reading symbols from /boot/kernel/if_bridge.ko...Reading symbols from 
> /boot/kernel/if_bridge.ko.symbols...done.
> done.
> Loaded symbols for /boot/kernel/if_bridge.ko
> Reading symbols from /boot/kernel/bridgestp.ko...Reading symbols from 
> /boot/kernel/bridgestp.ko.symbols...done.
> done.
> Loaded symbols for /boot/kernel/bridgestp.ko
> Reading symbols from /usr/local/modules/fuse.ko...done.
> Loaded symbols for /usr/local/modules/fuse.ko
> Reading symbols from /boot/kernel/radeon.ko...Reading symbols from 
> /boot/kernel/radeon.ko.symbols...done.
> done.
> Loaded symbols for /boot/kernel/radeon.ko
> Reading symbols from /boot/kernel/drm.ko...Reading symbols from 
> /boot/kernel/drm.ko.symbols...done.
> done.
> Loaded symbols for /boot/kernel/drm.ko
> Reading symbols from /boot/kernel/unionfs.ko...Reading symbols from 
> /boot/kernel/unionfs.ko.symbols...done.
> done.
> Loaded symbols for /boot/kernel/unionfs.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
> #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  0xffffffff804c70a8 in boot (howto=260) at 
> /usr/src/sys/kern/kern_shutdown.c:418
> #2  0xffffffff804c750c in panic (fmt=Variable "fmt" is not available.
> ) at /usr/src/sys/kern/kern_shutdown.c:574
> #3  0xffffffff801c1707 in db_panic (addr=Variable "addr" is not available.
> ) at /usr/src/sys/ddb/db_command.c:446
> #4  0xffffffff801c1d6f in db_command (last_cmdp=0xffffffff80aa6448, 
> cmd_table=0x0, dopager=1) at /usr/src/sys/ddb/db_command.c:413
> #5  0xffffffff801c1f80 in db_command_loop () at 
> /usr/src/sys/ddb/db_command.c:466
> #6  0xffffffff801c3b69 in db_trap (type=Variable "type" is not available.
> ) at /usr/src/sys/ddb/db_main.c:228
> #7  0xffffffff804f3955 in kdb_trap (type=12, code=0, 
> tf=0xffffffffb0e1a800) at /usr/src/sys/kern/subr_kdb.c:524
> #8  0xffffffff807a3180 in trap_fatal (frame=0xffffffffb0e1a800, 
> eva=Variable "eva" is not available.
> ) at /usr/src/sys/amd64/amd64/trap.c:759
> #9  0xffffffff807a3554 in trap_pfault (frame=0xffffffffb0e1a800, 
> usermode=0) at /usr/src/sys/amd64/amd64/trap.c:680
> #10 0xffffffff807a3eda in trap (frame=0xffffffffb0e1a800) at 
> /usr/src/sys/amd64/amd64/trap.c:449
> #11 0xffffffff80788dde in calltrap () at 
> /usr/src/sys/amd64/amd64/exception.S:209
> #12 0xffffffff804b9f0e in _mtx_lock_sleep (m=0xffffff006c384638, 
> tid=18446742974280188784, opts=Variable "opts" is not available.
> ) at /usr/src/sys/kern/kern_mutex.c:339
> #13 0xffffffff80555767 in vn_start_write (vp=0xffffff006c4983f0, 
> mpp=Variable "mpp" is not available.
> ) at /usr/src/sys/kern/vfs_vnops.c:902
> #14 0xffffffff805574a1 in vn_close (vp=0xffffff006c4983f0, flags=1, 
> file_cred=0xffffff0015947500, td=0xffffff0004e74370) at 
> /usr/src/sys/kern/vfs_vnops.c:287
> #15 0xffffffff80557589 in vn_closefile (fp=0xffffff006c020e00, 
> td=0xffffff0004e74370) at /usr/src/sys/kern/vfs_vnops.c:867
> #16 0xffffffff8049331f in fdrop (fp=0xffffff006c020e00, 
> td=0xffffff0004e74370) at file.h:299
> #17 0xffffffff80494579 in closef (fp=0xffffff006c020e00, 
> td=0xffffff0004e74370) at /usr/src/sys/kern/kern_descrip.c:2033
> #18 0xffffffff80494d5d in kern_close (td=0xffffff0004e74370, fd=Variable 
> "fd" is not available.
> ) at /usr/src/sys/kern/kern_descrip.c:1125
> #19 0xffffffff807a37d6 in syscall (frame=0xffffffffb0e1ac80) at 
> /usr/src/sys/amd64/amd64/trap.c:907
> #20 0xffffffff80788feb in Xfast_syscall () at 
> /usr/src/sys/amd64/amd64/exception.S:330
> #21 0x000000000044030c in ?? ()
> Previous frame inner to this frame (corrupt stack?)
> (kgdb) frame 12
> #12 0xffffffff804b9f0e in _mtx_lock_sleep (m=0xffffff006c384638, 
> tid=18446742974280188784, opts=Variable "opts" is not available.
> ) at /usr/src/sys/kern/kern_mutex.c:339
> 339                owner = (struct thread *)(v & ~MTX_FLAGMASK);
> (kgdb) list
> 334             * If the owner is running on another CPU, spin until the
> 335             * owner stops running or the state of the lock changes.
> 336             */
> 337            v = m->mtx_lock;
> 338            if (v != MTX_UNOWNED) {
> 339                owner = (struct thread *)(v & ~MTX_FLAGMASK);
> 340    #ifdef ADAPTIVE_GIANT
> 341                if (TD_IS_RUNNING(owner)) {
> 342    #else
> 343                if (m != &Giant && TD_IS_RUNNING(owner)) {
> (kgdb) p v
> $1 = 0
> (kgdb) p m
> $2 = (struct mtx *) 0xffffff006c384638
> (kgdb) p *m
> $3 = {lock_object = {lo_name = 0x0, lo_type = 0x0, lo_flags = 
> 1281410792, lo_witness_data = {lod_list = {stqe_next = 0xffffff004c60c708},
>       lod_witness = 0xffffff004c60c708}}, mtx_lock = 0, mtx_recurse = 0}
> (kgdb) frame 13
> #13 0xffffffff80555767 in vn_start_write (vp=0xffffff006c4983f0, 
> mpp=Variable "mpp" is not available.
> ) at /usr/src/sys/kern/vfs_vnops.c:902
> 902        MNT_ILOCK(mp);
> (kgdb) list
> 897                return (0);
> 898            }
> 899        }
> 900        if ((mp = *mpp) == NULL)
> 901            return (0);
> 902        MNT_ILOCK(mp);
> 903        if (vp == NULL)
> 904            MNT_REF(mp);
> 905        /*
> 906         * Check on status of suspension.
> (kgdb) p mp
> $4 = (struct mount *) 0xffffff006c3845e8
> (kgdb) p *mp
> $5 = {mnt_lock = {lk_object = {lo_name = 0x1 <Address 0x1 out of 
> bounds>, lo_type = 0xffffffffb1029552 "unionfs", lo_flags = 2969738112, 
> lo_witness_data = {
>         lod_list = {stqe_next = 0xffffff003c980000}, lod_witness = 
> 0xffffff003c980000}}, lk_interlock = 0xffffff0015d46378, lk_flags = 0, 
> lk_sharecount = 0,
>     lk_waitcount = 775638512, lk_exclusivecount = -256, lk_prio = -1, 
> lk_timo = 0, lk_lockholder = 0x0, lk_newlock = 0x0}, mnt_mtx = 
> {lock_object = {
>       lo_name = 0x0, lo_type = 0x0, lo_flags = 1281410792, 
> lo_witness_data = {lod_list = {stqe_next = 0xffffff004c60c708}, 
> lod_witness = 0xffffff004c60c708}},
>     mtx_lock = 0, mtx_recurse = 0}, mnt_gen = 0, mnt_list = {tqe_next = 
> 0x0, tqe_prev = 0x0}, mnt_op = 0xffffffffb1029552, mnt_vfc = 
> 0xffffffffb1029552,
>   mnt_vnodecovered = 0x4390000, mnt_syncer = 0x0, mnt_ref = -2136101936, 
> mnt_nvnodelist = {tqh_first = 0x80, tqh_last = 0x50000000000000},
>   mnt_nvnodelistsize = 51, mnt_writeopcount = 0, mnt_kern_flag = -1, 
> mnt_flag = 4294967295, mnt_noasync = 0, mnt_opt = 0xffffffff8086e910,
>   mnt_optnew = 0xffffffff8086e910, mnt_maxsymlinklen = 16973824, 
> mnt_stat = {f_version = 0, f_type = 0, f_flags = 4, f_bsize = 0,
>     f_iosize = 18446742976017063016, f_blocks = 4294967297, f_bfree = 0, 
> f_bavail = 0, f_files = 0, f_ffree = 0, f_syncwrites = 0,
>     f_asyncwrites = 18446742976013551312, f_syncreads = 0, f_asyncreads 
> = 18446742976013551424, f_spare = {0, 0, 0, 18446742976013551456, 0, 0, 
> 0, 0,
>       18446744071572912256, 16384}, f_namemax = 784962992, f_owner = 
> 4294967040, f_fsid = {val = {0, 0}},
>     f_charspare = 
> "\000\000\000\000\000\000\000\000?E8l\000????E8l\000???", '\0' <repeats 
> 24 times>, 
> "\001\000\000\000\000\000\000\000\023\016\206\200????\2001?\200????Xy?l\000???", 
> f_fstypename = "xsv\004\000????K8l\000???",
>     f_mntfromname = "\030D8l\000???", '\0' <repeats 16 times>, 
> "\200o\034\201?????L\003\003", '\0' <repeats 12 times>, 
> "?\227\tJ\000?????`L\000???\000\000\000\000\000\000\000\000\b\000\000\000\000\000\000\000 
> \031L0\000\000\000",
>     f_mntonname = "\a", '\0' <repeats 15 times>, 
> "\023\016\206\200????\023\016\206\200????\000\0009\004", '\0' <repeats 
> 12 times>, "?\230?\200????@", '\0' <repeats 13 times>, 
> "P\0003\000\000\000\000\000\000\000????????"}, mnt_cred = 0x0, mnt_data 
> = 0xffffffff8086e910, mnt_time = -2138642160, mnt_iosize_max = 16973824,
>   mnt_export = 0x0, mnt_label = 0x4, mnt_hashseed = 0, mnt_markercnt = 
> 0, mnt_holdcnt = 1815627896, mnt_holdcntwaiters = -256, 
> mnt_secondary_writes = 10,
>   mnt_secondary_accwrites = 0, mnt_gjprovider = 0x0, mnt_explock = 
> {lk_object = {lo_name = 0x0, lo_type = 0x0, lo_flags = 0, 
> lo_witness_data = {lod_list = {
>           stqe_next = 0x0}, lod_witness = 0x0}}, lk_interlock = 
> 0xffffff006c3848c8, lk_flags = 2589843616, lk_sharecount = -1, 
> lk_waitcount = -1707370640,
>     lk_exclusivecount = -1, lk_prio = -1, lk_timo = -1707370720, 
> lk_lockholder = 0x9, lk_newlock = 0x0}}
> (kgdb)
> 
> I reproduce this by unionfs mounting a ports dir used by the ports 
> tinderbox. If anyone would like more info, please let me know, I have 
> the core around, and can reproduce, help debug, resend in case my mailer 
> has mangled this, etc.

I have some research around that issue.

First I should say, I cannot judge that unionfs leads
that problem or not. JIMO, I guess that is not depends
on unionfs itself. Very similar panis is reported without
unionfs. At least, I cannot figure out what is the main
cause of this problem. sorry.

> Thanks,
> Steve
> 
> _______________________________________________
> 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"

-- 
   Daichi GOTO, http://people.freebsd.org/~daichi
From lme at FreeBSD.org  Sat Feb 21 03:27:05 2009
From: lme at FreeBSD.org (Lars Engels)
Date: Sat Feb 21 03:27:12 2009
Subject: Backport of glxsb(4) to RELENG_6
In-Reply-To: <20090213210516.3667403a@baby-jane.lamaiziere.net>
References: <20090210134421.350f40b8@baby-jane.lamaiziere.net>
	<20090212213443.GM30761@e.0x20.net>
	<20090213154333.18f0bf13@baby-jane.lamaiziere.net>
	<20090213210516.3667403a@baby-jane.lamaiziere.net>
Message-ID: <20090221112702.GW30761@e.0x20.net>

On Fri, Feb 13, 2009 at 09:05:16PM +0100, Patrick Lamaizi?re wrote:
> Le Fri, 13 Feb 2009 15:43:33 +0100,
> Patrick Lamaizi?re <patfbsd@davenulle.org>:
> 
> > Le Thu, 12 Feb 2009 22:34:43 +0100,
> > Lars Engels <lme@FreeBSD.org>:
> > 
> > Hi,
> > 
> > > I just tried it, but I get this message: 
> > > glxsb0: <AMD Geode LX Security Block (AES-128-CBC, RNG)> mem
> > > 0xefff4000-0xefff7fff irq 9 at device 1.2 on pci0 
> > 
> > > glxsb0: cannot allocate DMA memory of 32768 bytes (12)
> > 
> > I think you are very low on memory and the driver cannot allocate his
> > DMA-able buffer (error 12=ENOMEM)
> > 
> > This is not really a bug. 
> 
> To Lars: Yes it should work at bootime. You must also load the module
> cryptodev.ko to use it with openssl.
> 
> > But i've found another problem related to
> > the taskqueue. 
> > 
> > I'm doing a fake driver to be able to test on a vmware machine.
> 
> I've tested most of the driver and I think (hope) this is ok.
> 
> http://user.lamaiziere.net/patrick/glxsb-6-130209.tar.gz
> 
> Let me know how it works.

Sorry for the late reply. I just tried the new version (thanks for
compiling, stas :) ) and it works now:
glxsb0: <AMD Geode LX Security Block (AES-128-CBC, RNG)> mem 0xefff4000-0xefff7fff irq 9 at device 1.2 on pci0

moe:~# geli list
Geom name: mirror/dataraid1.eli
EncryptionAlgorithm: AES-CBC
KeyLength: 128
Crypto: hardware
[...]

But the speed is the same. I still only get ~1.2MB/s transfer speed over
the net.
However, this doesn't seem to be related to geli. The cpu is pretty much
idling:
last pid:  2769;  load averages:  0.06,  0.10,  0.08 up 0+00:18:04  12:23:07
39 processes:  1 running, 38 sleeping
CPU:  0.8% user,  0.0% nice, 16.7% system,  9.3% interrupt, 73.2% idle
Mem: 25M Active, 100M Inact, 35M Wired, 6192K Cache, 27M Buf, 588K Free


Anyways, thank you for your work on backporting the driver, Patrick! :)

Lars
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20090221/aa40b5b8/attachment.pgp
From patfbsd at davenulle.org  Sat Feb 21 04:31:36 2009
From: patfbsd at davenulle.org (Patrick =?ISO-8859-15?Q?Lamaizi=E8re?=)
Date: Sat Feb 21 04:31:44 2009
Subject: Backport of glxsb(4) to RELENG_6
In-Reply-To: <20090221112702.GW30761@e.0x20.net>
References: <20090210134421.350f40b8@baby-jane.lamaiziere.net>
	<20090212213443.GM30761@e.0x20.net>
	<20090213154333.18f0bf13@baby-jane.lamaiziere.net>
	<20090213210516.3667403a@baby-jane.lamaiziere.net>
	<20090221112702.GW30761@e.0x20.net>
Message-ID: <20090221133134.231ade65@baby-jane.lamaiziere.net>

Le Sat, 21 Feb 2009 12:27:02 +0100,
Lars Engels <lme@FreeBSD.org>:

> > I've tested most of the driver and I think (hope) this is ok.
> > 
> > http://user.lamaiziere.net/patrick/glxsb-6-130209.tar.gz
> > 
> > Let me know how it works.
> 
> Sorry for the late reply. I just tried the new version (thanks for
> compiling, stas :) ) and it works now:
> glxsb0: <AMD Geode LX Security Block (AES-128-CBC, RNG)> mem
> 0xefff4000-0xefff7fff irq 9 at device 1.2 on pci0
> 
> moe:~# geli list
> Geom name: mirror/dataraid1.eli
> EncryptionAlgorithm: AES-CBC
> KeyLength: 128
> Crypto: hardware
> [...]
> 
> But the speed is the same. I still only get ~1.2MB/s transfer speed
> over the net.

With my Soekris net5501, without the driver I've got around 3MB/s with
sftp and around 5MB/s with the driver.

On 7.X you need to patch openssl to make it use the crypto framework by
default, don't know for 6.X

> However, this doesn't seem to be related to geli. The cpu is pretty
> much idling:

I tested with geli (on an usb drive) and I didn't notice any
improvement too. I think that the crypto stuff is not the limiting
factor but the drive's speed. Anyway the driver should save some load
on the CPU.

> last pid:  2769;  load averages:  0.06,  0.10,  0.08 up 0+00:18:04
> 12:23:07 39 processes:  1 running, 38 sleeping
> CPU:  0.8% user,  0.0% nice, 16.7% system,  9.3% interrupt, 73.2% idle
> Mem: 25M Active, 100M Inact, 35M Wired, 6192K Cache, 27M Buf, 588K
> Free

You can see the driver's CPU usage with top S H (the glxsb0 taskq
entry)
 
> Anyways, thank you for your work on backporting the driver,
> Patrick! :)

Enjoy :)
Regards.
From rwatson at FreeBSD.org  Sat Feb 21 15:47:57 2009
From: rwatson at FreeBSD.org (Robert Watson)
Date: Sat Feb 21 15:48:04 2009
Subject: Big problems with 7.1 locking up :-(
In-Reply-To: <200902180110.n1I1AaPL031693@pyroxene.sentex.ca>
References: <E1LL6dg-0007CN-DI@dilbert.ticketswitch.com>
	<alpine.BSF.2.00.0901292234430.30840@fledge.watson.org>
	<200902180110.n1I1AaPL031693@pyroxene.sentex.ca>
Message-ID: <alpine.BSF.2.00.0902212345170.98609@fledge.watson.org>


On Tue, 17 Feb 2009, Mike Tancsa wrote:

>        Do you have any other details about these issues ? Were the fixes 
> ever MFC'd

Earlier today I handed off some patches for Pete to test (attached below), 
which he's running alongside the patches in kern/130652.  When I run with the 
patches, basically an MFC of a subset of Kip's routing improvements in 8.x, I 
can no longer reproduce the lock reversal, which will hopefully mean Pete can 
no longer reproduce the hang.  I plan to merge these in a couple of days once 
(with any luck) he's confirmed that is the case.  We may want to get a subset 
of this patch on the errata note path, if we can get the ICMP redirect fix 
down to a very short patch.

Robert N M Watson
Computer Laboratory
University of Cambridge


Merge r185747, r185774, r185807, r185849, r185964, r185965, r186051,
r186052 from head to stable/7; note that only the locking fixes and
invariants checking are added from r185747, but not the move to an
rwlock which would modify the kernel binary interface, nor the move
to a non-recursible lock, which is still seeing problem reports in
head.  This corrects, among other things, a deadlock that may occur
when processing incoming ICMP redirects.

r185747:

   - convert radix node head lock from mutex to rwlock
   - make radix node head lock not recursive
   - fix LOR in rtexpunge
   - fix LOR in rtredirect

   Reviewed by:	sam

r185774:

   - avoid recursively locking the radix node head lock
   - assert that it is held if RTF_RNH_LOCKED is not passed

r185807:

   Fix a bug introduced in r185747: rather than dereferencing an
   uninitialized *rt to something undefined, use the fibnum that came in as
   function argument.

   Found with:	Coverity Prevent(tm)
   CID:		4168

r185849:

   fix a reported panic when adding a route and one hit here when deleting a
   route

   - pass RTF_RNH_LOCKED to rtalloc1_fib in 2 cases where the lock is held
   - make sure the rnh lock is held across rt_setgate and rt_getifa_fib

r185964:

   Pass RTF_RNH_LOCKED to rtalloc1 sunce the node head is locked, this avoids
   a recursive lock panic on inet6 detach.

   Reviewed by:	kmacy

r185965:

   RTF_RNH_LOCKED needs to be passed in the flags arg not report,
   apologies to thompsa

r186051:

   in6_addroute is called through rnh_addadr which is always called with the
   radix node head lock held exclusively. Pass RTF_RNH_LOCKED to rtalloc so
   that rtalloc1_fib will not try to re-acquire the lock.

r186052:

   don't acquire lock recursively

All original commits to head were by Kip Macy <kmacy>, except r185964 by
<thompsa>.

Reviewed by:	bz
Tested by:	Pete French <petefrench at ticketswitch com>



Property changes on: sys
___________________________________________________________________
Modified: svn:mergeinfo
    Merged /head/sys:r185747,185774,185807,185849,185964-185965,186051-186052

Index: sys/netinet/in_rmx.c
===================================================================
--- sys/netinet/in_rmx.c	(revision 188767)
+++ sys/netinet/in_rmx.c	(working copy)
@@ -111,7 +111,7 @@
  		 * ARP entry and delete it if so.
  		 */
  		rt2 = in_rtalloc1((struct sockaddr *)sin, 0,
-		    RTF_CLONING, rt->rt_fibnum);
+		    RTF_CLONING|RTF_RNH_LOCKED, rt->rt_fibnum);
  		if (rt2) {
  			if (rt2->rt_flags & RTF_LLINFO &&
  			    rt2->rt_flags & RTF_HOST &&

Property changes on: sys/dev/cxgb
___________________________________________________________________
Modified: svn:mergeinfo
    Merged /head/sys/dev/cxgb:r185747,185774,185807,185849,185964-185965,186051-186052


Property changes on: sys/dev/ath/ath_hal
___________________________________________________________________
Modified: svn:mergeinfo
    Merged /head/sys/dev/ath/ath_hal:r185747,185774,185807,185849,185964-185965,186051-186052

Index: sys/net/route.c
===================================================================
--- sys/net/route.c	(revision 188767)
+++ sys/net/route.c	(working copy)
@@ -277,6 +277,7 @@
  	struct rt_addrinfo info;
  	u_long nflags;
  	int err = 0, msgtype = RTM_MISS;
+	int needlock;

  	KASSERT((fibnum < rt_numfibs), ("rtalloc1_fib: bad fibnum"));
  	if (dst->sa_family != AF_INET)	/* Only INET supports > 1 fib now */
@@ -290,7 +291,13 @@
  		rtstat.rts_unreach++;
  		goto miss2;
  	}
-	RADIX_NODE_HEAD_LOCK(rnh);
+	needlock = !(ignflags & RTF_RNH_LOCKED);
+	if (needlock)
+		RADIX_NODE_HEAD_LOCK(rnh);
+#ifdef INVARIANTS
+	else
+		RADIX_NODE_HEAD_LOCK_ASSERT(rnh);
+#endif
  	if ((rn = rnh->rnh_matchaddr(dst, rnh)) &&
  	    (rn->rn_flags & RNF_ROOT) == 0) {
  		/*
@@ -343,7 +350,8 @@
  			RT_LOCK(newrt);
  			RT_ADDREF(newrt);
  		}
-		RADIX_NODE_HEAD_UNLOCK(rnh);
+		if (needlock)
+			RADIX_NODE_HEAD_UNLOCK(rnh);
  	} else {
  		/*
  		 * Either we hit the root or couldn't find any match,
@@ -352,7 +360,8 @@
  		 */
  		rtstat.rts_unreach++;
  	miss:
-		RADIX_NODE_HEAD_UNLOCK(rnh);
+		if (needlock)
+			RADIX_NODE_HEAD_UNLOCK(rnh);
  	miss2:	if (report) {
  			/*
  			 * If required, report the failure to the supervising
@@ -482,6 +491,8 @@
  	short *stat = NULL;
  	struct rt_addrinfo info;
  	struct ifaddr *ifa;
+	struct radix_node_head *rnh =
+	    rt_tables[fibnum][dst->sa_family];

  	/* verify the gateway is directly reachable */
  	if ((ifa = ifa_ifwithnet(gateway)) == NULL) {
@@ -531,6 +542,8 @@
  			info.rti_info[RTAX_NETMASK] = netmask;
  			info.rti_ifa = ifa;
  			info.rti_flags = flags;
+			if (rt0 != NULL)
+				RT_UNLOCK(rt0); /* drop lock to avoid LOR with RNH */
  			error = rtrequest1_fib(RTM_ADD, &info, &rt, fibnum);
  			if (rt != NULL) {
  				RT_LOCK(rt);
@@ -538,7 +551,7 @@
  				flags = rt->rt_flags;
  			}
  			if (rt0)
-				RTFREE_LOCKED(rt0);
+				RTFREE(rt0);

  			stat = &rtstat.rts_dynamic;
  		} else {
@@ -554,8 +567,12 @@
  			/*
  			 * add the key and gateway (in one malloc'd chunk).
  			 */
+			RT_UNLOCK(rt);
+			RADIX_NODE_HEAD_LOCK(rnh);
+			RT_LOCK(rt);
  			rt_setgate(rt, rt_key(rt), gateway);
-			gwrt = rtalloc1(gateway, 1, 0);
+			gwrt = rtalloc1(gateway, 1, RTF_RNH_LOCKED);
+			RADIX_NODE_HEAD_UNLOCK(rnh);
  			EVENTHANDLER_INVOKE(route_redirect_event, rt, gwrt, dst);
  			RTFREE_LOCKED(gwrt);
  		}
@@ -641,7 +658,7 @@
  	if (ifa == NULL)
  		ifa = ifa_ifwithnet(gateway);
  	if (ifa == NULL) {
-		struct rtentry *rt = rtalloc1_fib(gateway, 0, 0UL, fibnum);
+		struct rtentry *rt = rtalloc1_fib(gateway, 0, RTF_RNH_LOCKED, fibnum);
  		if (rt == NULL)
  			return (NULL);
  		/*
@@ -788,7 +805,9 @@
  	struct ifaddr *ifa;
  	int error = 0;

+	rnh = rt_tables[rt->rt_fibnum][rt_key(rt)->sa_family];
  	RT_LOCK_ASSERT(rt);
+	RADIX_NODE_HEAD_LOCK_ASSERT(rnh);
  #if 0
  	/*
  	 * We cannot assume anything about the reference count
@@ -804,8 +823,6 @@
  	if (rnh == NULL)
  		return (EAFNOSUPPORT);

-	RADIX_NODE_HEAD_LOCK(rnh);
-
  	/*
  	 * Remove the item from the tree; it should be there,
  	 * but when callers invoke us blindly it may not (sigh).
@@ -826,7 +843,7 @@
  	 * Now search what's left of the subtree for any cloned
  	 * routes which might have been formed from this node.
  	 */
-	if ((rt->rt_flags & RTF_CLONING) && rt_mask(rt))
+	if ((rt->rt_flags & RTF_CLONING) && rt_mask(rt))
  		rnh->rnh_walktree_from(rnh, rt_key(rt), rt_mask(rt),
  				       rt_fixdelete, rt);

@@ -860,7 +877,6 @@
  	 */
  	rttrash++;
  bad:
-	RADIX_NODE_HEAD_UNLOCK(rnh);
  	return (error);
  }

@@ -874,7 +890,7 @@
  rtrequest1_fib(int req, struct rt_addrinfo *info, struct rtentry **ret_nrt,
  				u_int fibnum)
  {
-	int error = 0;
+	int error = 0, needlock = 0;
  	register struct rtentry *rt;
  	register struct radix_node *rn;
  	register struct radix_node_head *rnh;
@@ -891,7 +907,12 @@
  	rnh = rt_tables[fibnum][dst->sa_family];
  	if (rnh == NULL)
  		return (EAFNOSUPPORT);
-	RADIX_NODE_HEAD_LOCK(rnh);
+	needlock = ((flags & RTF_RNH_LOCKED) == 0);
+	flags &= ~RTF_RNH_LOCKED;
+	if (needlock)
+		RADIX_NODE_HEAD_LOCK(rnh);
+	else
+		RADIX_NODE_HEAD_LOCK_ASSERT(rnh);
  	/*
  	 * If we are adding a host route then we don't want to put
  	 * a netmask in the tree, nor do we want to clone it.
@@ -1036,7 +1057,7 @@
  			 * then we just blow it away and retry the insertion
  			 * of the new one.
  			 */
-			rt2 = rtalloc1_fib(dst, 0, 0, fibnum);
+			rt2 = rtalloc1_fib(dst, 0, RTF_RNH_LOCKED, fibnum);
  			if (rt2 && rt2->rt_parent) {
  				rtexpunge(rt2);
  				RT_UNLOCK(rt2);
@@ -1125,7 +1146,8 @@
  		error = EOPNOTSUPP;
  	}
  bad:
-	RADIX_NODE_HEAD_UNLOCK(rnh);
+	if (needlock)
+		RADIX_NODE_HEAD_UNLOCK(rnh);
  	return (error);
  #undef senderr
  }
@@ -1153,7 +1175,7 @@
  	if (rt->rt_parent == rt0 &&
  	    !(rt->rt_flags & (RTF_PINNED | RTF_CLONING))) {
  		return rtrequest_fib(RTM_DELETE, rt_key(rt), NULL, rt_mask(rt),
-				 rt->rt_flags, NULL, rt->rt_fibnum);
+				 rt->rt_flags|RTF_RNH_LOCKED, NULL, rt->rt_fibnum);
  	}
  	return 0;
  }
@@ -1230,6 +1252,7 @@

  again:
  	RT_LOCK_ASSERT(rt);
+	RADIX_NODE_HEAD_LOCK_ASSERT(rnh);

  	/*
  	 * A host route with the destination equal to the gateway
@@ -1256,7 +1279,7 @@
  		struct rtentry *gwrt;

  		RT_UNLOCK(rt);		/* XXX workaround LOR */
-		gwrt = rtalloc1_fib(gate, 1, 0, rt->rt_fibnum);
+		gwrt = rtalloc1_fib(gate, 1, RTF_RNH_LOCKED, rt->rt_fibnum);
  		if (gwrt == rt) {
  			RT_REMREF(rt);
  			return (EADDRINUSE); /* failure */
@@ -1327,12 +1350,8 @@

  		arg.rnh = rnh;
  		arg.rt0 = rt;
-		RT_UNLOCK(rt);		/* XXX workaround LOR */
-		RADIX_NODE_HEAD_LOCK(rnh);
-		RT_LOCK(rt);
  		rnh->rnh_walktree_from(rnh, rt_key(rt), rt_mask(rt),
  				       rt_fixchange, &arg);
-		RADIX_NODE_HEAD_UNLOCK(rnh);
  	}

  	return 0;
Index: sys/net/route.h
===================================================================
--- sys/net/route.h	(revision 188767)
+++ sys/net/route.h	(working copy)
@@ -172,6 +172,7 @@
  #define	RTF_BROADCAST	0x400000	/* route represents a bcast address */
  #define	RTF_MULTICAST	0x800000	/* route represents a mcast address */
  					/* 0x1000000 and up unassigned */
+#define	RTF_RNH_LOCKED	0x40000000	/* radix node head locked by caller */

  /* Mask of RTF flags that are allowed to be modified by RTM_CHANGE. */
  #define RTF_FMASK	\
Index: sys/net/rtsock.c
===================================================================
--- sys/net/rtsock.c	(revision 188767)
+++ sys/net/rtsock.c	(working copy)
@@ -628,9 +628,11 @@
  			     !sa_equal(info.rti_info[RTAX_IFA],
  				       rt->rt_ifa->ifa_addr))) {
  				RT_UNLOCK(rt);
+				RADIX_NODE_HEAD_LOCK(rnh);
  				if ((error = rt_getifa_fib(&info,
  				    rt->rt_fibnum)) != 0)
  					senderr(error);
+				RADIX_NODE_HEAD_UNLOCK(rnh);
  				RT_LOCK(rt);
  			}
  			if (info.rti_ifa != NULL &&
@@ -642,8 +644,14 @@
  				IFAFREE(rt->rt_ifa);
  			}
  			if (info.rti_info[RTAX_GATEWAY] != NULL) {
-				if ((error = rt_setgate(rt, rt_key(rt),
-					info.rti_info[RTAX_GATEWAY])) != 0) {
+				RT_UNLOCK(rt);
+				RADIX_NODE_HEAD_LOCK(rnh);
+				RT_LOCK(rt);
+ 
+				error = rt_setgate(rt, rt_key(rt),
+				    info.rti_info[RTAX_GATEWAY]);
+				RADIX_NODE_HEAD_UNLOCK(rnh);
+				if (error != 0) {
  					RT_UNLOCK(rt);
  					senderr(error);
  				}
Index: sys/netinet6/in6_ifattach.c
===================================================================
--- sys/netinet6/in6_ifattach.c	(revision 188767)
+++ sys/netinet6/in6_ifattach.c	(working copy)
@@ -823,7 +823,7 @@
  	/* XXX grab lock first to avoid LOR */
  	if (rt_tables[0][AF_INET6] != NULL) {
  		RADIX_NODE_HEAD_LOCK(rt_tables[0][AF_INET6]);
-		rt = rtalloc1((struct sockaddr *)&sin6, 0, 0UL);
+		rt = rtalloc1((struct sockaddr *)&sin6, 0, RTF_RNH_LOCKED);
  		if (rt) {
  			if (rt->rt_ifp == ifp)
  				rtexpunge(rt);
Index: sys/netinet6/in6_rmx.c
===================================================================
--- sys/netinet6/in6_rmx.c	(revision 188767)
+++ sys/netinet6/in6_rmx.c	(working copy)
@@ -154,7 +154,7 @@
  		 * Find out if it is because of an
  		 * ARP entry and delete it if so.
  		 */
-		rt2 = rtalloc1((struct sockaddr *)sin6, 0, RTF_CLONING);
+		rt2 = rtalloc1((struct sockaddr *)sin6, 0, RTF_RNH_LOCKED|RTF_CLONING);
  		if (rt2) {
  			if (rt2->rt_flags & RTF_LLINFO &&
  				rt2->rt_flags & RTF_HOST &&
@@ -181,7 +181,7 @@
  		 *	net route entry, 3ffe:0501:: -> if0.
  		 *	This case should not raise an error.
  		 */
-		rt2 = rtalloc1((struct sockaddr *)sin6, 0, RTF_CLONING);
+		rt2 = rtalloc1((struct sockaddr *)sin6, 0, RTF_RNH_LOCKED|RTF_CLONING);
  		if (rt2) {
  			if ((rt2->rt_flags & (RTF_CLONING|RTF_HOST|RTF_GATEWAY))
  					== RTF_CLONING

Property changes on: sys/contrib/pf
___________________________________________________________________
Modified: svn:mergeinfo
    Merged /head/sys/contrib/pf:r185747,185774,185807,185849,185964-185965,186051-186052

From tonymaher at optusnet.com.au  Sat Feb 21 17:30:06 2009
From: tonymaher at optusnet.com.au (Tony Maher)
Date: Sat Feb 21 17:30:14 2009
Subject: 7.1 Release and usb keyboard/mouse problems (and Xorg)
In-Reply-To: <4971B18D.3090803@optusnet.com.au>
References: <4971B18D.3090803@optusnet.com.au>
Message-ID: <49A0AAA2.7030104@optusnet.com.au>

Tony Maher wrote:
> Hello,
> 
> I have been running FreeBSD 7 from around 2008-10-20 and experienced
> the occasional problems with usb mouse and keyboard.  The mouse pointer
> slowly drift to a corner of the screen and not respond, and the keyboard
> would become unresponsive. Unplugging and plugging back in fixed the 
> problem.
> This would happen a few times per week.
> 
> However after I upgraded to 7.1-RELEASE-p2, I now get this problem
> every few hours if idle (hard to know exactly when it occurs since i am 
> not at keyboard) and a few minutes if doing a background compilation.
> The keyboard often shows one of the LEDs constantly flashing at high speed.
> Unplugging and replugging often does not work and needs to be done 
> several times (and use a different usb port).
> 
> I saw some email reports and tried in /boot/device.hints
> hint.atkbd.0.disable="1"
> hint.atkbdc.0.disable="1"
> 
> No change.
> 
> Tried a different mouse and it would continue to work but my normal mouse
> would disconnect.  Tried an identical keyboard and it exhibited the same
> problem ruling out a bad keyboard.  I then tried another keyboard and 
> have not had any problem since.
> 
> The main thing I can see different is the working keyboard is a Logitech
> and the two problematic keyboards are (very) cheap noname keyboards.
> Both the mice are Logitech but the mouse that has problems is very old
> (from around year 2000 - model M-BA47).  The working mouse is newer but
> still fairly old (Model M-UV96).
> 
> The box is a amd64 with Intel(R) Core(TM)2 Duo CPU  E6750  @ 2.66GH
> 4GB RAM and motherboard is Intel DP35DP.
> 
> So my setup now appears to be fine.  If anyone is having similar problems,
> I suggest trying  different (more modern) mice/keyboards.

Unfotunately things got worse after more port upgrades.
With Xorg 7.4 and gnome could not even get the logon screen - just a busy cursor.
The Xorg.0.log had a message like
  (EE) Logitech USB Keyboard: cannot open "/dev/ukbd0"
  (EE) PreInit failed for input device "Logitech USB Keyboard"
  (II) UnloadModule: "kbd"
which made me think this was the problem.  However I now have everything
working fine and still get this message.

Reverting X and gnome back and applications like xterms were slow
to start up plus mouse was slow to respond.  Tried lots of options but in the end gave
up and went for a clean install of 7.1 (First time I have ever had to do this
in over 10 years of using FreeBSD!)

Everything worked pretty good.
Did a cvsup and upgraded everything and all works fine.
The only problems I did encounter were/are:

1. my xorg.conf options were ignored

Section "InputDevice"
       Identifier  "Keyboard0"
       Driver      "kbd"
   Option      "XkbOptions" "ctrl:nocaps"
EndSection

Section "InputDevice"
       Identifier  "Mouse0"
       Driver      "mouse"
       Option      "Protocol" "auto"
       Option      "Device" "/dev/sysmouse"
       Option      "ZAxisMapping" "4 5 6 7"
EndSection


/var/log/Xorg.0.log shows

(WW) AllowEmptyInput is on, devices using drivers 'kbd' or 'mouse' will be disabled.

Not sure why this is. Man page says
   Option "AllowEmptyInput" "boolean"
             If  enabled,  don't add the standard keyboard and mouse drivers,
             if there are no input devices in the config  file.   Enabled  by
             default if AutoAddDevices and AutoEnableDevices is enabled, oth-
             erwise disabled.  If AllowEmptyInput is on,  devices  using  the
             kbd or mouse driver are ignored.

It is not set in my xorg.conf and neither are Auto* directives.
~:255 egrep 'Auto|Allow' /usr/local/etc/X11/xorg.conf
~:256 

To get the ctrl:nocaps used the gnome keyboard setting tool.
Mouse works fine except the side button does no work and fixed that by adding
moused_flags="-m2=4" to rc.conf.

2. gxine after upgrade would always segmentation fault.
  I used portupgrade -y -m BATCH=true gxine and this appears to be the problem.
  I rebuilt using make config selecting all options except lirc support.
  Did portupgrade -w -W gxine and it now works fine.

3. At some point along the line I (re)discovered the 'fc-cache -f -v'
   which fixed slow xterm startup.

I tried plugging in the old keyboard and mouse along side the more modern ones
I have been using since the problems started and they appear to be ok.
I was using the old mouse but the new keyboard (with the other two still attached).
I was going to say they worked fine but just before the start of this paragraph
I started to get '9' repeated across the screen and the keyboard
was unresponsive.  I had also just powered up a USB drive a few minutes before this
happened but I had run with this configuration all day yesterday without problems..
I have removed the older keyboard and mouse for now.

I was thinking maybe my problems stemmed from having two moused running
one from system start up and the other from hald but do not have any output
from the old system to confirm this was happening.

At this point everything is working perfectly.

I read someones advice who said make a copy or /usr/local and /var/db/pkg
before undertaking major port subsystem upgrades. I think this is an excellent
idea!


cheers
-- 
Tony Maher                    email: tonymaher@optusnet.com.au
From rnoland at FreeBSD.org  Sat Feb 21 20:15:03 2009
From: rnoland at FreeBSD.org (Robert Noland)
Date: Sat Feb 21 20:15:10 2009
Subject: 7.1 Release and usb keyboard/mouse problems (and Xorg)
In-Reply-To: <49A0AAA2.7030104@optusnet.com.au>
References: <4971B18D.3090803@optusnet.com.au>
	<49A0AAA2.7030104@optusnet.com.au>
Message-ID: <1235276091.1278.77.camel@widget.2hip.net>

On Sun, 2009-02-22 at 12:30 +1100, Tony Maher wrote:
> Tony Maher wrote:
> > Hello,
> > 
> > I have been running FreeBSD 7 from around 2008-10-20 and experienced
> > the occasional problems with usb mouse and keyboard.  The mouse pointer
> > slowly drift to a corner of the screen and not respond, and the keyboard
> > would become unresponsive. Unplugging and plugging back in fixed the 
> > problem.
> > This would happen a few times per week.
> > 
> > However after I upgraded to 7.1-RELEASE-p2, I now get this problem
> > every few hours if idle (hard to know exactly when it occurs since i am 
> > not at keyboard) and a few minutes if doing a background compilation.
> > The keyboard often shows one of the LEDs constantly flashing at high speed.
> > Unplugging and replugging often does not work and needs to be done 
> > several times (and use a different usb port).
> > 
> > I saw some email reports and tried in /boot/device.hints
> > hint.atkbd.0.disable="1"
> > hint.atkbdc.0.disable="1"
> > 
> > No change.
> > 
> > Tried a different mouse and it would continue to work but my normal mouse
> > would disconnect.  Tried an identical keyboard and it exhibited the same
> > problem ruling out a bad keyboard.  I then tried another keyboard and 
> > have not had any problem since.
> > 
> > The main thing I can see different is the working keyboard is a Logitech
> > and the two problematic keyboards are (very) cheap noname keyboards.
> > Both the mice are Logitech but the mouse that has problems is very old
> > (from around year 2000 - model M-BA47).  The working mouse is newer but
> > still fairly old (Model M-UV96).
> > 
> > The box is a amd64 with Intel(R) Core(TM)2 Duo CPU  E6750  @ 2.66GH
> > 4GB RAM and motherboard is Intel DP35DP.
> > 
> > So my setup now appears to be fine.  If anyone is having similar problems,
> > I suggest trying  different (more modern) mice/keyboards.
> 
> Unfotunately things got worse after more port upgrades.
> With Xorg 7.4 and gnome could not even get the logon screen - just a busy cursor.
> The Xorg.0.log had a message like
>   (EE) Logitech USB Keyboard: cannot open "/dev/ukbd0"
>   (EE) PreInit failed for input device "Logitech USB Keyboard"
>   (II) UnloadModule: "kbd"
> which made me think this was the problem.  However I now have everything
> working fine and still get this message.

This should generally be harmless.  It is because kbdmux has already
grabbed ukbd and then hald is advertising the ukbd device to xorg.  xorg
fails to open the device, but is still talking to it via kbdmux.

> Reverting X and gnome back and applications like xterms were slow
> to start up plus mouse was slow to respond.  Tried lots of options but in the end gave
> up and went for a clean install of 7.1 (First time I have ever had to do this
> in over 10 years of using FreeBSD!)
> 
> Everything worked pretty good.
> Did a cvsup and upgraded everything and all works fine.
> The only problems I did encounter were/are:
> 
> 1. my xorg.conf options were ignored
> 
> Section "InputDevice"
>        Identifier  "Keyboard0"
>        Driver      "kbd"
>    Option      "XkbOptions" "ctrl:nocaps"
> EndSection
> 
> Section "InputDevice"
>        Identifier  "Mouse0"
>        Driver      "mouse"
>        Option      "Protocol" "auto"
>        Option      "Device" "/dev/sysmouse"
>        Option      "ZAxisMapping" "4 5 6 7"
> EndSection
> 
> 
> /var/log/Xorg.0.log shows
> 
> (WW) AllowEmptyInput is on, devices using drivers 'kbd' or 'mouse' will be disabled.
> 
> Not sure why this is. Man page says
>    Option "AllowEmptyInput" "boolean"
>              If  enabled,  don't add the standard keyboard and mouse drivers,
>              if there are no input devices in the config  file.   Enabled  by
>              default if AutoAddDevices and AutoEnableDevices is enabled, oth-
>              erwise disabled.  If AllowEmptyInput is on,  devices  using  the
>              kbd or mouse driver are ignored.
> 
> It is not set in my xorg.conf and neither are Auto* directives.
> ~:255 egrep 'Auto|Allow' /usr/local/etc/X11/xorg.conf
> ~:256 

These are on by default now and the server uses hald to detect keyboard
and mouse.  If you don't want to use hald, set Option "AutoAddDevices"
"off" and it will use your configured devices.

robert.

> To get the ctrl:nocaps used the gnome keyboard setting tool.
> Mouse works fine except the side button does no work and fixed that by adding
> moused_flags="-m2=4" to rc.conf.
> 
> 2. gxine after upgrade would always segmentation fault.
>   I used portupgrade -y -m BATCH=true gxine and this appears to be the problem.
>   I rebuilt using make config selecting all options except lirc support.
>   Did portupgrade -w -W gxine and it now works fine.
> 
> 3. At some point along the line I (re)discovered the 'fc-cache -f -v'
>    which fixed slow xterm startup.
> 
> I tried plugging in the old keyboard and mouse along side the more modern ones
> I have been using since the problems started and they appear to be ok.
> I was using the old mouse but the new keyboard (with the other two still attached).
> I was going to say they worked fine but just before the start of this paragraph
> I started to get '9' repeated across the screen and the keyboard
> was unresponsive.  I had also just powered up a USB drive a few minutes before this
> happened but I had run with this configuration all day yesterday without problems..
> I have removed the older keyboard and mouse for now.
> 
> I was thinking maybe my problems stemmed from having two moused running
> one from system start up and the other from hald but do not have any output
> from the old system to confirm this was happening.
> 
> At this point everything is working perfectly.
> 
> I read someones advice who said make a copy or /usr/local and /var/db/pkg
> before undertaking major port subsystem upgrades. I think this is an excellent
> idea!
> 
> 
> cheers
-- 
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/20090222/ee7cd286/attachment.pgp
From cpghost at cordula.ws  Sun Feb 22 12:33:01 2009
From: cpghost at cordula.ws (cpghost)
Date: Sun Feb 22 12:33:08 2009
Subject: buildworld broken
Message-ID: <20090222203257.GA7647@phenom.cordula.ws>

Who broken RELENG_7 (as of Feb 22 18:24 UTC)?

===> usr.sbin/ifmcstat (all)
cc -O2 -fno-strict-aliasing -pipe  -DINET6 -DWITH_KVM -Wsystem-headers -Wall -Wn
o-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /usr/src/usr.sbin/ifmcstat/
ifmcstat.c
/usr/src/usr.sbin/ifmcstat/ifmcstat.c: In function 'ifmcstat_getifmaddrs':
/usr/src/usr.sbin/ifmcstat/ifmcstat.c:771: error: 'pllasa' undeclared (first use
 in this function)
/usr/src/usr.sbin/ifmcstat/ifmcstat.c:771: error: (Each undeclared identifier is
 reported only once
/usr/src/usr.sbin/ifmcstat/ifmcstat.c:771: error: for each function it appears i
n.)
*** Error code 1

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

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

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

-cpghost.

-- 
Cordula's Web. http://www.cordula.ws/
From cpghost at cordula.ws  Sun Feb 22 12:51:11 2009
From: cpghost at cordula.ws (cpghost)
Date: Sun Feb 22 12:51:18 2009
Subject: buildworld broken
In-Reply-To: <20090222203257.GA7647@phenom.cordula.ws>
References: <20090222203257.GA7647@phenom.cordula.ws>
Message-ID: <20090222205105.GB7647@phenom.cordula.ws>

On Sun, Feb 22, 2009 at 09:32:57PM +0100, cpghost wrote:
> Who broken RELENG_7 (as of Feb 22 18:24 UTC)?
> 
> ===> usr.sbin/ifmcstat (all)
> cc -O2 -fno-strict-aliasing -pipe  -DINET6 -DWITH_KVM -Wsystem-headers -Wall -Wn
> o-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /usr/src/usr.sbin/ifmcstat/
> ifmcstat.c
> /usr/src/usr.sbin/ifmcstat/ifmcstat.c: In function 'ifmcstat_getifmaddrs':
> /usr/src/usr.sbin/ifmcstat/ifmcstat.c:771: error: 'pllasa' undeclared (first use
>  in this function)
> /usr/src/usr.sbin/ifmcstat/ifmcstat.c:771: error: (Each undeclared identifier is
>  reported only once
> /usr/src/usr.sbin/ifmcstat/ifmcstat.c:771: error: for each function it appears i
> n.)
> *** Error code 1
> 
> Stop in /usr/src/usr.sbin/ifmcstat.
> *** Error code 1

Nevermind, it is probably already fixed:

http://lists.freebsd.org/pipermail/svn-src-stable/2009-February/000854.html

Sorry for the noise. Rebuilding world now... ;)

-cpghost.

-- 
Cordula's Web. http://www.cordula.ws/
From doconnor at gsoft.com.au  Sun Feb 22 17:30:45 2009
From: doconnor at gsoft.com.au (Daniel O'Connor)
Date: Sun Feb 22 17:30:55 2009
Subject: Intel Q45 problems on 7.1-STABLE
Message-ID: <200902231200.38164.doconnor@gsoft.com.au>

Skipped content of type multipart/mixed-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20090223/8e69c457/attachment.pgp
From sobomax at FreeBSD.org  Sun Feb 22 22:20:26 2009
From: sobomax at FreeBSD.org (Maxim Sobolev)
Date: Sun Feb 22 22:20:33 2009
Subject: The machdep.hyperthreading_allowed & ULE weirdness in 7.1
Message-ID: <49A23C1A.3070403@FreeBSD.org>

Hi Jeff,

I have a single-CPU system with P4 HTT-enabled processor 
(7.1-RELEASE-p3), kernel compiled with SCHED_ULE.

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-p3 #0: Fri Feb 20 09:53:32 UTC 2009
     root@foo.com:/usr/obj/usr/src/sys/SSP-PRODUCTION7
Timecounter "i8254" frequency 1193182 Hz quality 0
CPU: Intel(R) Pentium(R) 4 CPU 3.00GHz (2992.51-MHz 686-class CPU)
   Origin = "GenuineIntel"  Id = 0xf34  Stepping = 4
 
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=0x441d<SSE3,DTES64,MON,DS_CPL,CNXT-ID,xTPR>
   Logical CPUs per core: 2
real memory  = 3758030848 (3583 MB)
avail memory = 3674083328 (3503 MB)
ACPI APIC Table: <IntelR AWRDACPI>
FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs
  cpu0 (BSP): APIC ID:  0
  cpu1 (AP): APIC ID:  1
ioapic0: Changing APIC ID to 2
ioapic0 <Version 2.0> irqs 0-23 on motherboard
ioapic1 <Version 2.0> irqs 24-47 on motherboard

machdep.cpu_idle_hlt: 1
machdep.hlt_cpus: 0
machdep.hlt_logical_cpus: 0
machdep.logical_cpus_mask: 2

If I flip machdep.hyperthreading_allowed sysctl, I still can see 
processes scheduled to both logical CPUs, yet, if I check IRQ status in 
the systat -vm, the CPU1 is not getting any timer interrupts, while CPU0 
gets twice the normal amount. I wonder if something is broken - I would 
expect no processes to be scheduled to the CPU1.

machdep.hyperthreading_allowed=1:
   top: http://sobomax.sippysoft.com/~sobomax/ScreenShot458.png
   systat -vm: http://sobomax.sippysoft.com/~sobomax/ScreenShot459.png

machdep.hyperthreading_allowed=0:
   top: http://sobomax.sippysoft.com/~sobomax/ScreenShot460.png
   systat -vm: http://sobomax.sippysoft.com/~sobomax/ScreenShot461.png

Please let me know if any other debug information is needed.

-Maxim
From ota at j.email.ne.jp  Sun Feb 22 22:26:30 2009
From: ota at j.email.ne.jp (Yoshihiro Ota)
Date: Sun Feb 22 22:26:39 2009
Subject: unionfs panic in 7.1
In-Reply-To: <499FCAD4.8000006@freebsd.org>
References: <95E82F15-2535-4C67-BDF0-44CFC7EB9FBB@mouf.net>
	<499FCAD4.8000006@freebsd.org>
Message-ID: <20090223010604.fd404e45.ota@j.email.ne.jp>

On Sat, 21 Feb 2009 18:35:16 +0900
Daichi GOTO <daichi@freebsd.org> wrote:

> Steve Wills wrote:
> > Hi,
> > 
> > I've found an reproducable panic in unionfs on 7.1-R.
> > 
> > /usr/src/sys/fs/unionfs/union_subr.c is:
> >      $FreeBSD: src/sys/fs/unionfs/union_subr.c,v 1.92.2.7.2.2 2008/12/15 
> > 03:58:55 daichi Exp $
> > 
> > kgdb output is below.
> > 
> > I reproduce this by unionfs mounting a ports dir used by the ports 
> > tinderbox. If anyone would like more info, please let me know, I have 
> > the core around, and can reproduce, help debug, resend in case my mailer 
> > has mangled this, etc.
> 
> I have some research around that issue.
> 
> First I should say, I cannot judge that unionfs leads
> that problem or not. JIMO, I guess that is not depends
> on unionfs itself. Very similar panis is reported without
> unionfs. At least, I cannot figure out what is the main
> cause of this problem. sorry.

I wonder if it is one of LORs, http://sources.zabbadoz.net/freebsd/lor.html

If you can try on 8-CURRENT and reproduce, it may provide you better info.

Regards,
Hiro
From marck at rinet.ru  Mon Feb 23 00:04:22 2009
From: marck at rinet.ru (Dmitry Morozovsky)
Date: Mon Feb 23 00:04:29 2009
Subject: Upgrade from 32-bit to AMD-64?
In-Reply-To: <499C4BFC.3050704@denninger.net>
References: <4994CD7B.7040302@denninger.net> <499526E9.3090804@bit0.com>
	<2CA7DE699281AFA5DF2BD851@syn>
	<200902181728.16842.ianjhart@ntlworld.com>
	<499C4BFC.3050704@denninger.net>
Message-ID: <alpine.BSF.2.00.0902231102110.81984@woozle.rinet.ru>

On Wed, 18 Feb 2009, Karl Denninger wrote:

KD> I have been able to come up with a procedure that works.
KD> 
KD> 1. Load a new hard disk with the 64-bit code.  Perform a buildworld and
KD> buildkernel, and installkernel and installworld to this disk to verify that
KD> it will install and run.  You now have a "base" disk to use for migration.
KD> 
KD> 2. Make sure you have a backup (:-))
KD> 
KD> 3. Boot the migration hard disk as the system disk and mount the subject
KD> machine's disk drive(s) under /mnt.
KD> 
KD> 4. Do "make DESTDIR=/mnt installkernel" and "make DESTDIR=/mnt installworld"
KD> 
KD> 5. Shut down and disconnect migration disk.
KD> 
KD> 6. Boot SINGLE USER and verify that the system boots, you can fsck -p the
KD> disks, and mount them.  The system should boot and run.
KD> 
KD> 7. Come up multiuser but with any services necessary to the world offline.
KD> Some of your packages may blow up when started.  If so, portupgrade SHOULD
KD> fix it, but this is not consistent.  I had to manually dump the ports tree
KD> and rebuild a few installed ports due to what appear to be broken
KD> dependancies, but not many.
KD> 
KD> Postgresql 32-bit runs fine without recompilation after doing this.  It is
KD> arguably preferrable to recompile; doing so requires a dump/restore of the
KD> data as the 32 and 64-bit code will NOT run off the same binary data store.
KD> 
KD> Attempting to "make instalkernel" on an "in-place" basis resulted in a
KD> system that booted but failed immediately due to loader conflicts; there was
KD> no way to get the rest of the codeset loaded if you make that mistake.

You can avoid most of these problems if you have copies of ld-elf (both 32-bit 
and 64-bit), and boot single user for /rescue; however, "migration disk" 
approach is much simpler.

KD> 
KD> The "migration disk" approach appears to work fine.

-- 
Sincerely,
D.Marck                                     [DM5020, MCK-RIPE, DM3-RIPN]
[ FreeBSD committer:                                 marck@FreeBSD.org ]
------------------------------------------------------------------------
*** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- marck@rinet.ru ***
------------------------------------------------------------------------
From rwatson at FreeBSD.org  Mon Feb 23 02:08:39 2009
From: rwatson at FreeBSD.org (Robert Watson)
Date: Mon Feb 23 02:08:46 2009
Subject: The machdep.hyperthreading_allowed & ULE weirdness in 7.1
In-Reply-To: <49A23C1A.3070403@FreeBSD.org>
References: <49A23C1A.3070403@FreeBSD.org>
Message-ID: <alpine.BSF.2.00.0902231000300.98609@fledge.watson.org>


On Sun, 22 Feb 2009, Maxim Sobolev wrote:

> Hi Jeff,
>
> I have a single-CPU system with P4 HTT-enabled processor (7.1-RELEASE-p3), 
> kernel compiled with SCHED_ULE.

This is because machdep.hlt_logical_cpus doesn't do what you think it does. 
It causes HTT cores to invoke the hlt instruction in their idle loop, causing 
them to sleep until they receive an interrupt.  For 4BSD, which uses a "pull" 
model (on the whole) to bring work from work queues, this means that CPUs will 
go to sleep and remain that way unless they're actively receiving interrupts. 
For ULE, which uses "push" as well as "pull", threads will constantly be being 
shed from too-busy CPUs to apparently idle ones under load.  The only reliable 
way to disable hyperthreading is to do so using your BIOS setting, or use 
loader.conf to disable probing of the pics on unwanted cores, which will cause 
the CPUs not to be enumerated and hence not used.  We don't support taking 
CPUs fully offline with any scheduler, although you can use the cpuset 
facility to prevent threads from running on specific cores.  You could imagine 
teaching ULE (and presumably 4BSD) about policies such as "Don't use HTT 
cores", or perhaps just cpuset about those policies.

Robert N M Watson
Computer Laboratory
University of Cambridge

>
> 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-p3 #0: Fri Feb 20 09:53:32 UTC 2009
>    root@foo.com:/usr/obj/usr/src/sys/SSP-PRODUCTION7
> Timecounter "i8254" frequency 1193182 Hz quality 0
> CPU: Intel(R) Pentium(R) 4 CPU 3.00GHz (2992.51-MHz 686-class CPU)
>  Origin = "GenuineIntel"  Id = 0xf34  Stepping = 4
>
> 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=0x441d<SSE3,DTES64,MON,DS_CPL,CNXT-ID,xTPR>
>  Logical CPUs per core: 2
> real memory  = 3758030848 (3583 MB)
> avail memory = 3674083328 (3503 MB)
> ACPI APIC Table: <IntelR AWRDACPI>
> FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs
> cpu0 (BSP): APIC ID:  0
> cpu1 (AP): APIC ID:  1
> ioapic0: Changing APIC ID to 2
> ioapic0 <Version 2.0> irqs 0-23 on motherboard
> ioapic1 <Version 2.0> irqs 24-47 on motherboard
>
> machdep.cpu_idle_hlt: 1
> machdep.hlt_cpus: 0
> machdep.hlt_logical_cpus: 0
> machdep.logical_cpus_mask: 2
>
> If I flip machdep.hyperthreading_allowed sysctl, I still can see processes 
> scheduled to both logical CPUs, yet, if I check IRQ status in the systat -vm, 
> the CPU1 is not getting any timer interrupts, while CPU0 gets twice the 
> normal amount. I wonder if something is broken - I would expect no processes 
> to be scheduled to the CPU1.
>
> machdep.hyperthreading_allowed=1:
>  top: http://sobomax.sippysoft.com/~sobomax/ScreenShot458.png
>  systat -vm: http://sobomax.sippysoft.com/~sobomax/ScreenShot459.png
>
> machdep.hyperthreading_allowed=0:
>  top: http://sobomax.sippysoft.com/~sobomax/ScreenShot460.png
>  systat -vm: http://sobomax.sippysoft.com/~sobomax/ScreenShot461.png
>
> Please let me know if any other debug information is needed.
>
> -Maxim
> _______________________________________________
> 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 ob at e-Gitt.NET  Mon Feb 23 03:54:14 2009
From: ob at e-Gitt.NET (Oliver Brandmueller)
Date: Mon Feb 23 03:54:21 2009
Subject: fun with if_re
In-Reply-To: <20090213113955.GE12653@michelle.cdnetworks.co.kr>
References: <20090204100507.5f223d9e.gerrit@pmp.uni-hannover.de>
	<20090204104655.GA73543@michelle.cdnetworks.co.kr>
	<20090205085812.b2deb1f7.gerrit@pmp.uni-hannover.de>
	<20090205082804.GD77461@michelle.cdnetworks.co.kr>
	<20090213101910.a126c14d.gerrit@pmp.uni-hannover.de>
	<20090213102400.GD12653@michelle.cdnetworks.co.kr>
	<20090213114143.a77f1acb.gerrit@pmp.uni-hannover.de>
	<20090213113955.GE12653@michelle.cdnetworks.co.kr>
Message-ID: <20090223115412.GO79003@e-Gitt.NET>

Hi,

On Fri, Feb 13, 2009 at 08:39:55PM +0900, Pyun YongHyeon wrote:
> Ok, try attached patch.

> Index: sys/dev/re/if_re.c
> ===================================================================
> --- sys/dev/re/if_re.c	(revision 187352)
> +++ sys/dev/re/if_re.c	(working copy)
> @@ -158,6 +158,8 @@
>  /* Tunables. */
[...]

This seems to have fixed a regression I found after the latest re 
changes. While the changes lead to a situation, where the re interface 
(as opposed to before) seems to always attach, I had the problem that 
after 1-2 days it failed (sorry, was just about to investigate when I 
tried your patch and thus didn't write down the error message 
associated).

With your patch my re seems to be running fine for the last days now.

re0@pci0:4:0:0: class=0x020000 card=0x392c1462 chip=0x816810ec rev=0x02 hdr=0x00
    vendor     = 'Realtek Semiconductor'
    device     = 'RTL8168/8111 PCI-E Gigabit Ethernet NIC'
    class      = network
    subclass   = ethernet

re0: <RealTek 8168/8168B/8168C/8168CP/8168D/8111B/8111C/8111CP PCIe Gigabit Ethernet> port 0xd800-0xd8ff mem 0xfeaff000-0xfeafffff,0xf8ff0000-0xf8ffffff irq 18 at device 0.0 on pci4
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:21:85:1e:8b:c9
re0: [FILTER]


- Oliver

From bms at incunabulum.net  Mon Feb 23 04:03:35 2009
From: bms at incunabulum.net (Bruce Simpson)
Date: Mon Feb 23 04:03:44 2009
Subject: buildworld broken
In-Reply-To: <20090222203257.GA7647@phenom.cordula.ws>
References: <20090222203257.GA7647@phenom.cordula.ws>
Message-ID: <49A29077.5040009@incunabulum.net>

Already dealt with, I was merging a change by hand whilst hungover after 
a good party. ;^)
Sorry for the churn.

A lot of this stuff gets utterly demolished and rebuilt in the IGMPv3 snap.

I don't plan to backport the multicast work ongoing in p4 to 7-STABLE 
without testers, and air-out in 8-CURRENT first.

One of the reasons it's taken so long is because there has been a *lot* 
of network stack re-engineering in 8-CURRENT (VIMAGE, arpv2, multi-fib, 
IFF_NEEDSGIANT removal).

ASM state changes are believed working, but that is dog simple...
Right now my aim is to get SSM working in the p4 branch fully. The 
IGMPv3 bottom half code is all done with the VIMAGE hooks, it's just a 
case of making the SSM state change stuff behave right.

cheers
BMS
From doug at polands.org  Mon Feb 23 05:53:44 2009
From: doug at polands.org (Doug Poland)
Date: Mon Feb 23 05:53:52 2009
Subject: amd64 installworld fails on syscons/scrnmaps 
Message-ID: <084becfc4478ca25081d8354e54f9b45.squirrel@email.polands.org>

Hello,

I have an amd64 laptop on which I did a fresh csup to RELENG_7.  I did
the canonical "buildworld", "buildkernel", "installkernel" and so far
so good.

However, when I attempt to "installworld", I get:

===> share/syscons/scrnmaps (install)
./armscii8-2haik8.mk armscii8-2haik8.tmp
uuencode armscii8-2haik8.tmp armscii8-2haik8 > armscii8-2haik8.scm
uuencode: not found
*** Error code 127

Stop in /usr/src/share/syscons/scrnmaps.
*** Error code 1

The binary uuencode exists in /usr/bin, as do the files:
armscii8-2haik8.tmp armscii8-2haik8, armscii8-2haik8.scm in
/usr/obj/usr/src/share/syscons/scrnmaps/

I have not rebooted since installing the new kernel and have tried
installworld twice.

Here's my /usr/local/etc/cvsup/sup/supfile:
*default base=/var/db
*default delete use-rel-suffix compress
*default host=cvsup15.freebsd.org
*default prefix=/usr
*default release=cvs tag=RELENG_7
src-all

Here's my /etc/make.conf and /etc/src.conf:

make.conf:
# added by use.perl 2009-02-23 03:20:27
PERL_VER=5.8.9
PERL_VERSION=5.8.9

src.conf:
WITHOUT_PROFILE=


Not sure how to diagnose or resolve this on my own and need a little
assistance, please.


-- 
Regards,
Doug

From sobomax at FreeBSD.org  Mon Feb 23 06:05:55 2009
From: sobomax at FreeBSD.org (Maxim Sobolev)
Date: Mon Feb 23 06:06:07 2009
Subject: The machdep.hyperthreading_allowed & ULE weirdness in 7.1
In-Reply-To: <alpine.BSF.2.00.0902231000300.98609@fledge.watson.org>
References: <49A23C1A.3070403@FreeBSD.org>
	<alpine.BSF.2.00.0902231000300.98609@fledge.watson.org>
Message-ID: <49A2AD30.1040007@FreeBSD.org>

Robert Watson wrote:
> 
> On Sun, 22 Feb 2009, Maxim Sobolev wrote:
> 
>> Hi Jeff,
>>
>> I have a single-CPU system with P4 HTT-enabled processor 
>> (7.1-RELEASE-p3), kernel compiled with SCHED_ULE.
> 
> This is because machdep.hlt_logical_cpus doesn't do what you think it 
> does. It causes HTT cores to invoke the hlt instruction in their idle 

Hmm, as the subject says I am actually talking about flipping 
machdep.hyperthreading_allowed, not machdep.hlt_logical_cpus sysctl 
here. I provided current value of the latter only to simplify diagnosis 
and had not changed it from the default value. AFAIK, the 
machdep.hyperthreading_allowed is designed to prevent logical cores from 
running any code, works just fine with 6.x/SCHED_4BSD.

Below are screenshots from the dual-core 6.2 system with 4BSD. As you 
can easily see, after flipping machdep.hyperthreading_allowed only cores 
0 and 2 run actual code, so that it's definitely regression of ULE/7.x:

machdep.hyperthreading_allowed=1:
  top: http://sobomax.sippysoft.com/~sobomax/ScreenShot462.png

machdep.hyperthreading_allowed=0:
  top: http://sobomax.sippysoft.com/~sobomax/ScreenShot463.png

IMHO, at the very least, if SCHED_ULE doesn't support 
machdep.hyperthreading_allowed properly, then when that scheduler is 
selected the sysctl should return ENOTSUP or something like this.

-Maxim
From cptsalek at gmail.com  Mon Feb 23 07:50:24 2009
From: cptsalek at gmail.com (Christian Walther)
Date: Mon Feb 23 07:50:30 2009
Subject: Recommended wireless card (or is there a chance to get either iwi
	or ath fixed)?
Message-ID: <14989d6e0902230721x7a2cd30cw4e548451c87e17cd@mail.gmail.com>

Hi,

after some time without FreeBSD I installed 7.1 on an IBM Thinkpad T30
(with ZFS root on encrypted geli, works great).
Config is:

FreeBSD hasking.alashan.nongo 7.1-STABLE FreeBSD 7.1-STABLE #3: Thu
Feb  5 21:10:45 CET 2009
root@hasking.alashan.nongo:/usr/obj/usr/src/sys/HASKING  i386

I tried using my ath based D-Link DWL G650, which still seems to have
some issues in regard to interrupt handling:

Feb 17 20:15:21 hasking kernel: ath0: <Atheros 5212> mem
0xd0210000-0xd021ffff irq 3 at device 0.0 on cardbus0
Feb 17 20:15:21 hasking kernel: ath0: [ITHREAD]
Feb 17 20:15:21 hasking kernel: ath0: WARNING: using obsoleted
if_watchdog interface
Feb 17 20:15:21 hasking kernel: ath0: Ethernet address: 00:19:5b:3a:82:be
Feb 17 20:15:21 hasking kernel: ath0: mac 7.9 phy 4.5 radio 5.6
...
Feb 17 21:39:19 hasking kernel: ath0: link state changed to UP
Feb 17 21:39:19 hasking kernel: ath0: link state changed to DOWN
Feb 17 21:39:23 hasking kernel: ath0: link state changed to UP
Feb 17 21:39:23 hasking kernel: ath0: link state changed to DOWN
Feb 17 21:39:24 hasking kernel: interrupt storm detected on "irq3:";
throttling interrupt source


Next I gave the following card a try:
iwi0: <Intel(R) PRO/Wireless 2915ABG> mem 0xd0200000-0xd0200fff irq 5
at device 2.0 on pci2
iwi0: Ethernet address: 00:15:00:31:f3:76
iwi0: [ITHREAD]

...and it regularly drops/looses connection to the WLAN router, as
stated in the following PR:
http://www.freebsd.org/cgi/query-pr.cgi?pr=124767

Basically, my question is if there is a fix for any of these issues
that I haven't found so far, so that I can eventually use one of my
existing wireless cards, or if I should switch to a different
brand/model. If the latter is the case I'd like to know which one to
choose.

Regards
Christian Walther
From peter at pean.org  Mon Feb 23 09:55:45 2009
From: peter at pean.org (=?ISO-8859-1?Q?Peter_Ankerst=E5l?=)
Date: Mon Feb 23 09:56:19 2009
Subject: dhclient cant renew lease.
Message-ID: <17C37DBA-E596-41FB-990C-1538800F2766@pean.org>

Hi
Im running FreeBSD 7.0-RELEASE on my gateway and for the last week or  
so it cant renew its dhcp-lease.

At boot-time it sends a request to broadcast: DHCPREQUEST on fxp0 to  
255.255.255.255 port 67
And then it gets an DHCPACK from the gateway.  (not 172.21.248.127)

But then the machine tries to renew the lease I keep getting messages  
like this:
Feb 23 18:29:06 cone dhclient[1623]: DHCPREQUEST on fxp0 to  
172.21.248.127 port 67
Feb 23 18:29:06 cone dhclient[1623]: SENDING DIRECT
Feb 23 18:29:33 cone dhclient[1623]: DHCPREQUEST on fxp0 to  
172.21.248.127 port 67
Feb 23 18:29:33 cone dhclient[1623]: SENDING DIRECT

until the lease runs out and then the connection drops.
I guess 172.21.248.127 is the real dhcp-server.

A 'dhclient fxp0' sends a new request to 255.255.255.255 and it  
immediately fixes the connection.


--
Peter Ankerst?l
peter@pean.org
http://www.pean.org/

From oberman at es.net  Mon Feb 23 09:57:09 2009
From: oberman at es.net (Kevin Oberman)
Date: Mon Feb 23 09:57:18 2009
Subject: Recommended wireless card (or is there a chance to get either
	iwi or ath fixed)? 
In-Reply-To: Your message of "Mon, 23 Feb 2009 16:21:17 +0100."
	<14989d6e0902230721x7a2cd30cw4e548451c87e17cd@mail.gmail.com> 
Message-ID: <20090223175603.E12A41CC27@ptavv.es.net>

> Date: Mon, 23 Feb 2009 16:21:17 +0100
> From: Christian Walther <cptsalek@gmail.com>
> Sender: owner-freebsd-stable@freebsd.org
> 
> Hi,
> 
> after some time without FreeBSD I installed 7.1 on an IBM Thinkpad T30
> (with ZFS root on encrypted geli, works great).
> Config is:
> 
> FreeBSD hasking.alashan.nongo 7.1-STABLE FreeBSD 7.1-STABLE #3: Thu
> Feb  5 21:10:45 CET 2009
> root@hasking.alashan.nongo:/usr/obj/usr/src/sys/HASKING  i386
> 
> I tried using my ath based D-Link DWL G650, which still seems to have
> some issues in regard to interrupt handling:
> 
> Feb 17 20:15:21 hasking kernel: ath0: <Atheros 5212> mem
> 0xd0210000-0xd021ffff irq 3 at device 0.0 on cardbus0
> Feb 17 20:15:21 hasking kernel: ath0: [ITHREAD]
> Feb 17 20:15:21 hasking kernel: ath0: WARNING: using obsoleted
> if_watchdog interface
> Feb 17 20:15:21 hasking kernel: ath0: Ethernet address: 00:19:5b:3a:82:be
> Feb 17 20:15:21 hasking kernel: ath0: mac 7.9 phy 4.5 radio 5.6
> ...
> Feb 17 21:39:19 hasking kernel: ath0: link state changed to UP
> Feb 17 21:39:19 hasking kernel: ath0: link state changed to DOWN
> Feb 17 21:39:23 hasking kernel: ath0: link state changed to UP
> Feb 17 21:39:23 hasking kernel: ath0: link state changed to DOWN
> Feb 17 21:39:24 hasking kernel: interrupt storm detected on "irq3:";
> throttling interrupt source
> 
> 
> Next I gave the following card a try:
> iwi0: <Intel(R) PRO/Wireless 2915ABG> mem 0xd0200000-0xd0200fff irq 5
> at device 2.0 on pci2
> iwi0: Ethernet address: 00:15:00:31:f3:76
> iwi0: [ITHREAD]
> 
> ...and it regularly drops/looses connection to the WLAN router, as
> stated in the following PR:
> http://www.freebsd.org/cgi/query-pr.cgi?pr=124767
> 
> Basically, my question is if there is a fix for any of these issues
> that I haven't found so far, so that I can eventually use one of my
> existing wireless cards, or if I should switch to a different
> brand/model. If the latter is the case I'd like to know which one to
> choose.

I'm not sure what the problem you are seeing with the Atheros 5212 might
be, but I use that wireless card in my T43 and it has worked very well
for years.

I'm not sure what is using irq3, but it is normally COMM2, which i
believe only exists on the T30 when the unit is in a docking
station. Could you check on the output of 'vmstat -i' to see what might
be using it? 

Are you running with APIC? I know that it has to be disabled on the T43
and it may need to be on the T30. (It's been a while since I've used the
T30.) Add 'hint.apic.0.disabled=1' to /boot/loader to do this.

Finally, try 'ifconfig ath0 -bgscan'. Several people have reported that
this fixes periodic loss of association on the 5212. By default,
background scanning is done every 5 minutes and makes roaming work much
better, but seems to have some issues on this card.

I'm not at all confident that this will lead to fixing the problem, but
it's easy to check on and may point in the right direction.
-- 
R. Kevin Oberman, Network Engineer
Energy Sciences Network (ESnet)
Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab)
E-mail: oberman@es.net			Phone: +1 510 486-8634
Key fingerprint:059B 2DDF 031C 9BA3 14A4  EADA 927D EBB3 987B 3751
From peter at pean.org  Mon Feb 23 10:25:17 2009
From: peter at pean.org (=?ISO-8859-1?Q?Peter_Ankerst=E5l?=)
Date: Mon Feb 23 10:25:24 2009
Subject: dhclient cant renew lease.
In-Reply-To: <20090223180839.GA78235@lor.one-eyed-alien.net>
References: <17C37DBA-E596-41FB-990C-1538800F2766@pean.org>
	<20090223180839.GA78235@lor.one-eyed-alien.net>
Message-ID: <F1A47E1E-E2DA-4AD3-84BB-ABFFB3B9A5E5@pean.org>


On Feb 23, 2009, at 7:08 PM, Brooks Davis wrote:

> On Mon, Feb 23, 2009 at 06:40:15PM +0100, Peter Ankerst?l wrote:
>> Hi
>> Im running FreeBSD 7.0-RELEASE on my gateway and for the last week  
>> or so it
>> cant renew its dhcp-lease.
>>
>> At boot-time it sends a request to broadcast: DHCPREQUEST on fxp0 to
>> 255.255.255.255 port 67
>> And then it gets an DHCPACK from the gateway.  (not 172.21.248.127)
>>
>
> You may be seeing the issue in bin/96018.  If so, switching to the  
> dhclient
> from 7.1 should fix it.
>
> -- Brooks

I've been trying with my laptop running 7.1 and it doesnt get any  
replies from
172.21.248.127.

I guess a workaround is to set a shorter rebind-interval..
--
Peter Ankerst?l
peter@pean.org
http://www.pean.org/

From brooks at freebsd.org  Mon Feb 23 10:30:55 2009
From: brooks at freebsd.org (Brooks Davis)
Date: Mon Feb 23 10:31:18 2009
Subject: dhclient cant renew lease.
In-Reply-To: <17C37DBA-E596-41FB-990C-1538800F2766@pean.org>
References: <17C37DBA-E596-41FB-990C-1538800F2766@pean.org>
Message-ID: <20090223180839.GA78235@lor.one-eyed-alien.net>

On Mon, Feb 23, 2009 at 06:40:15PM +0100, Peter Ankerst?l wrote:
> Hi
> Im running FreeBSD 7.0-RELEASE on my gateway and for the last week or so it 
> cant renew its dhcp-lease.
> 
> At boot-time it sends a request to broadcast: DHCPREQUEST on fxp0 to 
> 255.255.255.255 port 67
> And then it gets an DHCPACK from the gateway.  (not 172.21.248.127)
> 
> But then the machine tries to renew the lease I keep getting messages like 
> this:
> Feb 23 18:29:06 cone dhclient[1623]: DHCPREQUEST on fxp0 to 172.21.248.127 
> port 67
> Feb 23 18:29:06 cone dhclient[1623]: SENDING DIRECT
> Feb 23 18:29:33 cone dhclient[1623]: DHCPREQUEST on fxp0 to 172.21.248.127 
> port 67
> Feb 23 18:29:33 cone dhclient[1623]: SENDING DIRECT
> 
> until the lease runs out and then the connection drops.
> I guess 172.21.248.127 is the real dhcp-server.
> 
> A 'dhclient fxp0' sends a new request to 255.255.255.255 and it immediately 
> fixes the connection.

You may be seeing the issue in bin/96018.  If so, switching to the dhclient
from 7.1 should fix it.

-- Brooks
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20090223/414426f3/attachment.pgp
From sobomax at FreeBSD.org  Mon Feb 23 10:39:59 2009
From: sobomax at FreeBSD.org (Maxim Sobolev)
Date: Mon Feb 23 10:40:06 2009
Subject: The machdep.hyperthreading_allowed & ULE weirdness in 7.1
In-Reply-To: <alpine.BSF.2.00.0902231801450.92010@fledge.watson.org>
References: <alpine.BSF.2.00.0902231000300.98609@fledge.watson.org>
	<200902231652.n1NGqMxH047731@post.behrens.de>
	<49A2DE9D.4090902@FreeBSD.org>
	<alpine.BSF.2.00.0902231801450.92010@fledge.watson.org>
Message-ID: <49A2ED6A.9040202@FreeBSD.org>

Robert Watson wrote:
> In the mean time, it sounds like the sysctl does need to be 
> reimplemented or removed, but one question is how far to take it -- 
> caches are shared to varying degrees at varying levels of the topology.  
> However, I believe the recommendation has generally moved to disabling 
> hyperthreading using the BIOS, as that uses the vendor's notion of 
> hyperthreading.  The idea of changing the setting at run-time is 
> currently untenable because we don't have the OS infrastructure to take 
> CPUs out of service, although growing it would be useful in order to 
> support virtual machine dynamic CPU reconfiguration.

Well, as far as I know, what SCHED_4BSD does is simply stopping 
scheduling threads to the logical core(s). One doesn't need 
infrastructure to take CPU off-line for doing the same in SCHED_ULE.

Unfortunately access to BIOS is not always an option and also some 
BIOSes don't even provide a feature to turn HTT off.

-Maxim
From rwatson at FreeBSD.org  Mon Feb 23 10:56:37 2009
From: rwatson at FreeBSD.org (Robert Watson)
Date: Mon Feb 23 10:56:44 2009
Subject: The machdep.hyperthreading_allowed & ULE weirdness in 7.1
In-Reply-To: <49A2ED6A.9040202@FreeBSD.org>
References: <alpine.BSF.2.00.0902231000300.98609@fledge.watson.org>
	<200902231652.n1NGqMxH047731@post.behrens.de>
	<49A2DE9D.4090902@FreeBSD.org>
	<alpine.BSF.2.00.0902231801450.92010@fledge.watson.org>
	<49A2ED6A.9040202@FreeBSD.org>
Message-ID: <alpine.BSF.2.00.0902231853040.92010@fledge.watson.org>


On Mon, 23 Feb 2009, Maxim Sobolev wrote:

> Robert Watson wrote:
>> In the mean time, it sounds like the sysctl does need to be reimplemented 
>> or removed, but one question is how far to take it -- caches are shared to 
>> varying degrees at varying levels of the topology.  However, I believe the 
>> recommendation has generally moved to disabling hyperthreading using the 
>> BIOS, as that uses the vendor's notion of hyperthreading.  The idea of 
>> changing the setting at run-time is currently untenable because we don't 
>> have the OS infrastructure to take CPUs out of service, although growing it 
>> would be useful in order to support virtual machine dynamic CPU 
>> reconfiguration.
>
> Well, as far as I know, what SCHED_4BSD does is simply stopping scheduling 
> threads to the logical core(s). One doesn't need infrastructure to take CPU 
> off-line for doing the same in SCHED_ULE.
>
> Unfortunately access to BIOS is not always an option and also some BIOSes 
> don't even provide a feature to turn HTT off.

It's not quite that simple -- in a world of device drivers pinning threads to 
CPUs for workload distribution, callout threads and sched_bind()/sched_pin() 
for crypto load distribution, etc, you need a whole infrastructure for 
software-disabled CPUs.  Disabling it using the BIOS or device.hints is the 
only reliable way to do this right now.  Changing the architecture of the 
kernel to disable CPU cores after boot is a significant investment of work, 
and as I mentioned elsewhere, it is disable to do this so that we can support 
dynamic reconfiguration in the presence of a hypervisor, but it's highly 
non-trivial.  There may be some shortcuts that can be taken for policy reasons 
in the probing of CPUs when the topology is detected that avoid the full 
dynamic solution having to be done in the short-term, that in effect are a 
short-hand for device.hints entries, but I don't know to what extent the CPU 
topology from ACPI is available at the point where we'd need to know that.

Robert N M Watson
Computer Laboratory
University of Cambridge

From rwatson at FreeBSD.org  Mon Feb 23 11:00:00 2009
From: rwatson at FreeBSD.org (Robert Watson)
Date: Mon Feb 23 11:00:12 2009
Subject: The machdep.hyperthreading_allowed & ULE weirdness in 7.1
In-Reply-To: <alpine.BSF.2.00.0902231853040.92010@fledge.watson.org>
References: <alpine.BSF.2.00.0902231000300.98609@fledge.watson.org>
	<200902231652.n1NGqMxH047731@post.behrens.de>
	<49A2DE9D.4090902@FreeBSD.org>
	<alpine.BSF.2.00.0902231801450.92010@fledge.watson.org>
	<49A2ED6A.9040202@FreeBSD.org>
	<alpine.BSF.2.00.0902231853040.92010@fledge.watson.org>
Message-ID: <alpine.BSF.2.00.0902231859210.92010@fledge.watson.org>

On Mon, 23 Feb 2009, Robert Watson wrote:

> It's not quite that simple -- in a world of device drivers pinning threads to 
> CPUs for workload distribution, callout threads and sched_bind()/sched_pin() 
> for crypto load distribution, etc, you need a whole infrastructure for 
> software-disabled CPUs.  Disabling it using the BIOS or device.hints is the 
> only reliable way to do this right now.  Changing the architecture of the 
> kernel to disable CPU cores after boot is a significant investment of work,

             ^^^^ s/disable/desirable/

Robert N M Watson
Computer Laboratory
University of Cambridge
From sobomax at FreeBSD.org  Mon Feb 23 12:17:48 2009
From: sobomax at FreeBSD.org (Maxim Sobolev)
Date: Mon Feb 23 12:17:55 2009
Subject: The machdep.hyperthreading_allowed & ULE weirdness in 7.1
In-Reply-To: <alpine.BSF.2.00.0902231853040.92010@fledge.watson.org>
References: <alpine.BSF.2.00.0902231000300.98609@fledge.watson.org>
	<200902231652.n1NGqMxH047731@post.behrens.de>
	<49A2DE9D.4090902@FreeBSD.org>
	<alpine.BSF.2.00.0902231801450.92010@fledge.watson.org>
	<49A2ED6A.9040202@FreeBSD.org>
	<alpine.BSF.2.00.0902231853040.92010@fledge.watson.org>
Message-ID: <49A30456.5010400@FreeBSD.org>

Robert Watson wrote:
> 
> On Mon, 23 Feb 2009, Maxim Sobolev wrote:
> 
>> Robert Watson wrote:
>>> In the mean time, it sounds like the sysctl does need to be 
>>> reimplemented or removed, but one question is how far to take it -- 
>>> caches are shared to varying degrees at varying levels of the 
>>> topology.  However, I believe the recommendation has generally moved 
>>> to disabling hyperthreading using the BIOS, as that uses the vendor's 
>>> notion of hyperthreading.  The idea of changing the setting at 
>>> run-time is currently untenable because we don't have the OS 
>>> infrastructure to take CPUs out of service, although growing it would 
>>> be useful in order to support virtual machine dynamic CPU 
>>> reconfiguration.
>>
>> Well, as far as I know, what SCHED_4BSD does is simply stopping 
>> scheduling threads to the logical core(s). One doesn't need 
>> infrastructure to take CPU off-line for doing the same in SCHED_ULE.
>>
>> Unfortunately access to BIOS is not always an option and also some 
>> BIOSes don't even provide a feature to turn HTT off.
> 
> It's not quite that simple -- in a world of device drivers pinning 
> threads to CPUs for workload distribution, callout threads and 
> sched_bind()/sched_pin() for crypto load distribution, etc, you need a 
> whole infrastructure for software-disabled CPUs.  Disabling it using the 
> BIOS or device.hints is the only reliable way to do this right now.  
> Changing the architecture of the kernel to disable CPU cores after boot 
> is a significant investment of work, and as I mentioned elsewhere, it is 
> disable to do this so that we can support dynamic reconfiguration in the 
> presence of a hypervisor, but it's highly non-trivial.  There may be 
> some shortcuts that can be taken for policy reasons in the probing of 
> CPUs when the topology is detected that avoid the full dynamic solution 
> having to be done in the short-term, that in effect are a short-hand for 
> device.hints entries, but I don't know to what extent the CPU topology 
> from ACPI is available at the point where we'd need to know that.

So, are you suggesting that we should disable 
machdep.hyperthreading_allowed with ULE in 7.x and current to avoid 
confusion?

-Maxim
From rwatson at FreeBSD.org  Mon Feb 23 12:27:06 2009
From: rwatson at FreeBSD.org (Robert Watson)
Date: Mon Feb 23 12:27:19 2009
Subject: The machdep.hyperthreading_allowed & ULE weirdness in 7.1
In-Reply-To: <49A30456.5010400@FreeBSD.org>
References: <alpine.BSF.2.00.0902231000300.98609@fledge.watson.org>
	<200902231652.n1NGqMxH047731@post.behrens.de>
	<49A2DE9D.4090902@FreeBSD.org>
	<alpine.BSF.2.00.0902231801450.92010@fledge.watson.org>
	<49A2ED6A.9040202@FreeBSD.org>
	<alpine.BSF.2.00.0902231853040.92010@fledge.watson.org>
	<49A30456.5010400@FreeBSD.org>
Message-ID: <alpine.BSF.2.00.0902232026180.92010@fledge.watson.org>

On Mon, 23 Feb 2009, Maxim Sobolev wrote:

>>> Unfortunately access to BIOS is not always an option and also some BIOSes 
>>> don't even provide a feature to turn HTT off.
>> 
>> It's not quite that simple -- in a world of device drivers pinning threads 
>> to CPUs for workload distribution, callout threads and 
>> sched_bind()/sched_pin() for crypto load distribution, etc, you need a 
>> whole infrastructure for software-disabled CPUs.  Disabling it using the 
>> BIOS or device.hints is the only reliable way to do this right now. 
>> Changing the architecture of the kernel to disable CPU cores after boot is 
>> a significant investment of work, and as I mentioned elsewhere, it is 
>> disable to do this so that we can support dynamic reconfiguration in the 
>> presence of a hypervisor, but it's highly non-trivial.  There may be some 
>> shortcuts that can be taken for policy reasons in the probing of CPUs when 
>> the topology is detected that avoid the full dynamic solution having to be 
>> done in the short-term, that in effect are a short-hand for device.hints 
>> entries, but I don't know to what extent the CPU topology from ACPI is 
>> available at the point where we'd need to know that.
>
> So, are you suggesting that we should disable machdep.hyperthreading_allowed 
> with ULE in 7.x and current to avoid confusion?

Possibly even without ULE.

Robert N M Watson
Computer Laboratory
University of Cambridge
From cptsalek at gmail.com  Mon Feb 23 13:13:37 2009
From: cptsalek at gmail.com (Christian Walther)
Date: Mon Feb 23 13:13:44 2009
Subject: Recommended wireless card (or is there a chance to get either
	iwi or ath fixed)?
In-Reply-To: <20090223175603.E12A41CC27@ptavv.es.net>
References: <14989d6e0902230721x7a2cd30cw4e548451c87e17cd@mail.gmail.com>
	<20090223175603.E12A41CC27@ptavv.es.net>
Message-ID: <14989d6e0902231313q10b20839g724b0f1939c24aac@mail.gmail.com>

Hi Kevin,

lets say it this way: Right now the DWL-G650 works.
I'm not sure why, but I did reset the BIOS configurations to its
default and started manually configuration some of the used
interrupts. This is why the snippets of the logfiles I sent in my
previous mail don't match the current configuration.
Currently, the card uses irq 5 as supplied by cbb0.

The last messages I received concerning the issue were:
Feb 23 19:43:52 hasking kernel: interrupt storm detected on "irq5:";
throttling interrupt source
Feb 23 19:43:53 hasking kernel: interrupt storm detected on "irq5:";
throttling interrupt source
Feb 23 19:43:54 hasking kernel: ath0: link state changed to UP
Feb 23 19:43:54 hasking kernel: ath0: link state changed to DOWN
Feb 23 19:43:58 hasking kernel: ath0: link state changed to UP
Feb 23 19:43:58 hasking kernel: ath0: link state changed to DOWN
Feb 23 19:44:03 hasking kernel: ath0: link state changed to UP
Feb 23 19:44:03 hasking kernel: ath0: link state changed to DOWN
Feb 23 19:44:05 hasking kernel: interrupt storm detected on "irq5:";
throttling interrupt source
Feb 23 19:44:05 hasking kernel: ath0: link state changed to UP
Feb 23 19:44:05 hasking kernel: ath0: link state changed to DOWN
Feb 23 19:44:09 hasking kernel: ath0: rx FIFO overrun; resetting
Feb 23 19:44:20 hasking kernel: ath0: link state changed to UP

This has actually been the last time that I've seen those errors. I
even transferred a PCBSD DVD iso image to my server using FTP.

I guess I made two mistakes during my entire testing phase:
1. I wrongly assumed that the issue with the ath card was the same as
the one I experienced some time ago, including some HAL issue locking
the card, interrupt storms during usage and crashes on removal of the
card.
2. After I did the BIOS reset I obviously just tested my iwi card.

While there are still some interrupt storm related messages, they seem
to appear during boot (HW init) only.

Kevin, thank you for your input, which made me review the issue again.
The only problem that remains is that my machine crashes when I remove
the card. I'll review this later.

Thanks again for your help, I'm happy that I can use this card as
expected, and that I don't need to get another one.

Regards
Christian
From sobomax at FreeBSD.org  Mon Feb 23 21:58:03 2009
From: sobomax at FreeBSD.org (Maxim Sobolev)
Date: Mon Feb 23 21:58:11 2009
Subject: The machdep.hyperthreading_allowed & ULE weirdness in 7.1
In-Reply-To: <alpine.BSF.2.00.0902232026180.92010@fledge.watson.org>
References: <alpine.BSF.2.00.0902231000300.98609@fledge.watson.org>
	<200902231652.n1NGqMxH047731@post.behrens.de>
	<49A2DE9D.4090902@FreeBSD.org>
	<alpine.BSF.2.00.0902231801450.92010@fledge.watson.org>
	<49A2ED6A.9040202@FreeBSD.org>
	<alpine.BSF.2.00.0902231853040.92010@fledge.watson.org>
	<49A30456.5010400@FreeBSD.org>
	<alpine.BSF.2.00.0902232026180.92010@fledge.watson.org>
Message-ID: <49A38C54.7070601@FreeBSD.org>

Robert Watson wrote:
>> So, are you suggesting that we should disable 
>> machdep.hyperthreading_allowed with ULE in 7.x and current to avoid 
>> confusion?
> 
> Possibly even without ULE.

I've verified - the tunable/sysctl works just fine with SCHED_4BSD in 
7.1, so that I am not sure it's worth ripping it off.

Instead, I've re-implemented the feature differently - by disabling HT 
cores at detection time when SCHED_ULE is compiled in and 
machdep.hyperthreading_allowed is set to 0 in loader.conf. Patch for 7.1 
is attached.  Apart from the fact that it's not possible to change the 
setting at run-time, this version should be even better by not starting 
up HT cores in the first place.

I would appreciate if somebody familiar with the code in question can 
review the patch, particularly part that moves assign_cpu_ids() and 
start_all_aps() calls little bit further in the cpu_mp_start(). I need 
them there so that I can use hyperthreading_cpus in assign_cpu_ids().

Thanks in advance.

-Maxim
-------------- next part --------------
--- i386/i386/mp_machdep.c	2009-01-19 07:34:49.000000000 -0800
+++ /tmp/mp_machdep.c	2009-02-23 21:38:18.000000000 -0800
@@ -209,6 +210,7 @@
 	int	cpu_present:1;
 	int	cpu_bsp:1;
 	int	cpu_disabled:1;
+	int	cpu_hyperthread:1;
 } static cpu_info[MAX_APIC_ID + 1];
 int cpu_apic_ids[MAXCPU];
 
@@ -405,11 +407,6 @@
 		    ("BSP's APIC ID doesn't match boot_cpu_id"));
 	cpu_apic_ids[0] = boot_cpu_id;
 
-	assign_cpu_ids();
-
-	/* Start each Application Processor */
-	start_all_aps();
-
 	/* Setup the initial logical CPUs info. */
 	logical_cpus = logical_cpus_mask = 0;
 	if (cpu_feature & CPUID_HTT)
@@ -457,6 +454,11 @@
 			hyperthreading_cpus = logical_cpus;
 	}
 
+	assign_cpu_ids();
+
+	/* Start each Application Processor */
+	start_all_aps();
+
 	set_interrupt_apic_ids();
 
 	/* Last, setup the cpu topology now that we have probed CPUs */
@@ -471,18 +473,26 @@
 cpu_mp_announce(void)
 {
 	int i, x;
+	const char *hyperthread;
 
 	/* List CPUs */
 	printf(" cpu0 (BSP): APIC ID: %2d\n", boot_cpu_id);
 	for (i = 1, x = 0; x <= MAX_APIC_ID; x++) {
 		if (!cpu_info[x].cpu_present || cpu_info[x].cpu_bsp)
 			continue;
+		if (cpu_info[x].cpu_hyperthread) {
+			hyperthread = "/HT";
+		} else {
+			hyperthread = "";
+		}
 		if (cpu_info[x].cpu_disabled)
-			printf("  cpu (AP): APIC ID: %2d (disabled)\n", x);
+			printf("  cpu (AP%s): APIC ID: %2d (disabled)\n",
+			    hyperthread, x);
 		else {
 			KASSERT(i < mp_ncpus,
 			    ("mp_ncpus and actual cpus are out of whack"));
-			printf(" cpu%d (AP): APIC ID: %2d\n", i++, x);
+			printf(" cpu%d (AP%s): APIC ID: %2d\n", i++,
+			    hyperthread, x);
 		}
 	}
 }
@@ -691,11 +701,24 @@
 {
 	u_int i;
 
+	TUNABLE_INT_FETCH("machdep.hyperthreading_allowed",
+	    &hyperthreading_allowed);
+
 	/* Check for explicitly disabled CPUs. */
 	for (i = 0; i <= MAX_APIC_ID; i++) {
 		if (!cpu_info[i].cpu_present || cpu_info[i].cpu_bsp)
 			continue;
 
+		if (hyperthreading_cpus > 1 && i % hyperthreading_cpus != 0) {
+			cpu_info[i].cpu_hyperthread = 1;
+#if defined(SCHED_ULE)
+			if (hyperthreading_allowed == 0) {
+				cpu_info[i].cpu_disabled = 1;
+				continue;
+			}
+#endif
+		}
+
 		/* Don't use this CPU if it has been disabled by a tunable. */
 		if (resource_disabled("lapic", i)) {
 			cpu_info[i].cpu_disabled = 1;
@@ -1410,6 +1433,12 @@
 	if (error || !req->newptr)
 		return (error);
 
+#ifdef SCHED_ULE
+	if (allowed != hyperthreading_allowed)
+		return (ENOTSUP);
+	return (error);
+#endif
+
 	if (allowed)
 		hlt_cpus_mask &= ~hyperthreading_cpus_mask;
 	else
@@ -1454,8 +1483,6 @@
 		 * of hlt_logical_cpus.
 		 */
 		if (hyperthreading_cpus_mask) {
-			TUNABLE_INT_FETCH("machdep.hyperthreading_allowed",
-			    &hyperthreading_allowed);
 			SYSCTL_ADD_PROC(&logical_cpu_clist,
 			    SYSCTL_STATIC_CHILDREN(_machdep), OID_AUTO,
 			    "hyperthreading_allowed", CTLTYPE_INT|CTLFLAG_RW,
From ahmed.aneeth at gmail.com  Mon Feb 23 22:21:04 2009
From: ahmed.aneeth at gmail.com (aneeth)
Date: Mon Feb 23 22:21:11 2009
Subject: Big problems with 7.1 locking up :-(
In-Reply-To: <E1LOuGG-000NW3-1y@dilbert.ticketswitch.com>
References: <E1LL6dg-0007CN-DI@dilbert.ticketswitch.com>
	<E1LOsTE-000N7h-SL@dilbert.ticketswitch.com>
	<20090119132504.GA6853@dchagin.dialup.corbina.ru>
	<E1LOuGG-000NW3-1y@dilbert.ticketswitch.com>
Message-ID: <22176398.post@talk.nabble.com>



Pete French-2 wrote:
> 
>> Probably it is your case, try please.
>>
>> http://www.freebsd.org/cgi/query-pr.cgi?pr=130652&cat=
> 
> OK, will give this a try, unless anyone else wants any traces from
> this locked machine ? Is there a known way to tickle this bug
> when I've rebooted, to make sure it's fixed ?
> 
> thanks,
> 
> -pete.
> _______________________________________________
> 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'v been having similar issues with a couple of our servers as well (7.0
and 7.1). However the problem shows up only on quad core machines. The dual
core machines r running fine. 
-- 
View this message in context: http://www.nabble.com/Big-problems-with-7.1-locking-up-%3A-%28-tp21364913p22176398.html
Sent from the freebsd-stable mailing list archive at Nabble.com.

From wblock at wonkity.com  Mon Feb 23 22:25:11 2009
From: wblock at wonkity.com (Warren Block)
Date: Mon Feb 23 22:25:18 2009
Subject: Old /etc files back, or cvs error?
Message-ID: <alpine.BSF.2.00.0902232254130.40842@wonkity.com>

Lately I've installed a couple of test systems from 7.1-RELEASE CDs, 
then csupped to RELENG_7 from cvsup9:

*default host=cvsup9.FreeBSD.org
*default base=/var/db
*default prefix=/usr
*default release=cvs tag=RELENG_7
*default delete use-rel-suffix

mergemaster adds a *lot* of old files in /etc that were not there in 
7.1-RELEASE.  (Remember the rc.d rework?  Like that.)  For example, a 
bunch of bluetooth files and /etc/isdn/*.

The version numbers and dates in mergemaster look wrong.  For example, 
/etc/bluetooth/hcsecd.conf:

# $Id: hcsecd.conf,v 1.1 2003/05/26 22:50:47 max Exp $
# $FreeBSD: src/etc/bluetooth/hcsecd.conf,v 1.3 2006/05/18 17:53:49 emax Exp $

Shouldn't that be 1.3.6.1 from Tue Nov 25 02:59:29 2008?

The latest entries for files in /etc/isdn are 9 months old, and were 
removals.

This looks like an error, but maybe I'm missing something.  And other 
cvsup mirrors seem to agree with cvsup9.

-Warren Block * Rapid City, South Dakota USA
From kstewart at owt.com  Tue Feb 24 00:58:33 2009
From: kstewart at owt.com (Kent Stewart)
Date: Tue Feb 24 00:58:41 2009
Subject: Old /etc files back, or cvs error?
In-Reply-To: <alpine.BSF.2.00.0902232254130.40842@wonkity.com>
References: <alpine.BSF.2.00.0902232254130.40842@wonkity.com>
Message-ID: <200902240058.31212.kstewart@owt.com>

On Monday 23 February 2009 10:11:45 pm Warren Block wrote:
> Lately I've installed a couple of test systems from 7.1-RELEASE CDs,
> then csupped to RELENG_7 from cvsup9:
>
> *default host=cvsup9.FreeBSD.org
> *default base=/var/db
> *default prefix=/usr
> *default release=cvs tag=RELENG_7
> *default delete use-rel-suffix
>
> mergemaster adds a *lot* of old files in /etc that were not there in
> 7.1-RELEASE.  (Remember the rc.d rework?  Like that.)  For example, a
> bunch of bluetooth files and /etc/isdn/*.
>
> The version numbers and dates in mergemaster look wrong.  For example,
> /etc/bluetooth/hcsecd.conf:
>
> # $Id: hcsecd.conf,v 1.1 2003/05/26 22:50:47 max Exp $
> # $FreeBSD: src/etc/bluetooth/hcsecd.conf,v 1.3 2006/05/18 17:53:49 emax
> Exp $
>
> Shouldn't that be 1.3.6.1 from Tue Nov 25 02:59:29 2008?
>
> The latest entries for files in /etc/isdn are 9 months old, and were
> removals.
>
> This looks like an error, but maybe I'm missing something.  And other
> cvsup mirrors seem to agree with cvsup9.

You are looking at the version for the 7.1 release version. The RELENG_7 
version is

Revision 1.3: download - view: text, markup, annotated - select for diffs
Thu May 18 17:53:49 2006 UTC (2 years, 9 months ago) by emax
Branches: MAIN
CVS tags: RELENG_7_BP, RELENG_7_1_BP, RELENG_7_0_BP, RELENG_7_0_0_RELEASE, 
RELENG_7_0, RELENG_7, HEAD
Branch point for: RELENG_7_1
Diff to: previous 1.2: preferred, colored
Changes since revision 1.2: +1 -1 lines

Go to 
http://www.freebsd.org/cgi/cvsweb.cgi/src/etc/bluetooth/hcsecd.conf
and you can see the versions and the tags.

Kent

-- 
kent Stewart
Richland, WA

http://users.owt.com/kstewart/index.html

From doconnor at gsoft.com.au  Tue Feb 24 02:33:45 2009
From: doconnor at gsoft.com.au (Daniel O'Connor)
Date: Tue Feb 24 02:33:53 2009
Subject: E7400 Speedstep support?
Message-ID: <200902241956.46306.doconnor@gsoft.com.au>

Hi,
I recently got a new Intel E7400 based system and dmesg reports..
est0: <Enhanced SpeedStep Frequency Control> on cpu0
est0: Guessed bus clock (high) of 37 MHz
est0: Guessed bus clock (low) of 466 MHz
est: CPU supports Enhanced Speedstep, but is not recognized.
est: cpu_vendor GenuineIntel, msr 6164a2206004a22
device_attach: est0 attach returned 6
p4tcc0: <CPU Frequency Thermal Control> on cpu0
cpu1: <ACPI CPU> on acpi0
est1: <Enhanced SpeedStep Frequency Control> on cpu1
est1: Guessed bus clock (high) of 37 MHz
est1: Guessed bus clock (low) of 466 MHz
est: CPU supports Enhanced Speedstep, but is not recognized.
est: cpu_vendor GenuineIntel, msr 6164a2206004a22
device_attach: est1 attach returned 6
p4tcc1: <CPU Frequency Thermal Control> on cpu1

I'm running 7.1-STABLE and I was wondering how hard it is to add support for 
est for this CPU?

Thanks.

-- 
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: 189 bytes
Desc: This is a digitally signed message part.
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20090224/7cb9209b/attachment.pgp
From doconnor at gsoft.com.au  Tue Feb 24 02:35:16 2009
From: doconnor at gsoft.com.au (Daniel O'Connor)
Date: Tue Feb 24 02:35:23 2009
Subject: Intel Q45 problems on 7.1-STABLE (fixed)
In-Reply-To: <200902231200.38164.doconnor@gsoft.com.au>
References: <200902231200.38164.doconnor@gsoft.com.au>
Message-ID: <200902242105.05667.doconnor@gsoft.com.au>

On Monday 23 February 2009 12:00:30 Daniel O'Connor wrote:
> Initially it hung solid when X started, however when I reduced the amount
> of RAM to 2Gb it worked OK. Unfortunately if I exit X, or go to the text
> console and back to X then the machine locks solid (no numlock, have to
> hard reset).
>
> I note that dmesg reports 32764k of stolen memory, however I set the DVMT
> RAM to 128Mb (and 256Mb, makes no difference). Also the aperture size is
> always reported as 256Mb no matter what it actually is in the BIOS.

Someone in a private email suggested I update the BIOS (went from 63 to 73) 
and it seems to work fine now.

The reported value of stolen memory is still wrong however.

-- 
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: 189 bytes
Desc: This is a digitally signed message part.
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20090224/59bfcdf5/attachment.pgp
From bms at incunabulum.net  Tue Feb 24 06:06:40 2009
From: bms at incunabulum.net (Bruce Simpson)
Date: Tue Feb 24 06:06:47 2009
Subject: Cleaning unused libraries and rebuilding dependent ones?
Message-ID: <49A3FEE6.7030606@incunabulum.net>

Hi all,

I'm sure that these questions have been asked before, however, a quick 
search of forums on the Web didn't turn up any obvious answers.

I currently use portupgrade on all my FreeBSD installations, however, I 
have noticed over time that a fair amount of detritus can build up in 
${PREFIX}/lib/compat/pkg. So my questions are:-

 1. Is there a tool like Gentoo's revdep-rebuild to force packages 
depending on packaged libraries to be rebuilt?
 2. Is there a more complete tool to clean orphaned libraries like 
'portsclean -L' used to do?

Whilst I greatly appreciate the hard work and effort which the FreeBSD 
ports maintainers put in to ensure shared library versions get bumped 
when needed, this isn't always possible, as it requires keeping a sharp 
eye out for 3rd party software packages which do the wrong thing, and 
don't bump the major(s) when significant semantic changes happen inside 
their libraries, or when the ABI changes.

[1] revdep-rebuild has very similar semantics to what I'm looking for, 
as it will navigate the dependency graph for all packages installed on 
the system, and rebuild packages where dependent libraries have changed.
To do the same with portupgrade alone, I need to know which port(s) 
contain shared libraries, and tell it to go off and rebuild these 
*specific* packages if things change.

[2] 'portsclean -L' used to do something :-) it does not appear to do 
anything now.
I realize I could use libchk to discover which libraries are 
unreferenced at load-time, however, a fair number of the libraries which 
portupgrade moves into ${PREFIX}/lib/compat/pkg can potentially be 
loaded by dlopen() at run-time.
Using libchk's output to remove unreferenced libraries isn't really an 
option without significant post-processing of its output.

I would rather not rely on 'portupgrade -f -a -r', as this is going to 
cause a *lot* of work on the affected systems.

Thanks for any help!
BMS
From admin at stardothosting.com  Tue Feb 24 08:28:17 2009
From: admin at stardothosting.com (SDH Support)
Date: Tue Feb 24 08:28:25 2009
Subject: Recommended wireless card (or is there a chance to get either
	iwi or ath fixed)?
In-Reply-To: <14989d6e0902230721x7a2cd30cw4e548451c87e17cd@mail.gmail.com>
References: <14989d6e0902230721x7a2cd30cw4e548451c87e17cd@mail.gmail.com>
Message-ID: <003601c9969c$e2cdc310$a8694930$@com>


> I tried using my ath based D-Link DWL G650, which still seems to have
> some issues in regard to interrupt handling:


I've been able to get /most/ wireless cards working with ndiswrapper. 



---


Kevin
www.stardothosting.com/linux-vps-hosting



From kutulu at kutulu.org  Tue Feb 24 09:05:32 2009
From: kutulu at kutulu.org (Mike Edenfield)
Date: Tue Feb 24 09:05:40 2009
Subject: Cleaning unused libraries and rebuilding dependent ones?
In-Reply-To: <49A3FEE6.7030606@incunabulum.net>
References: <49A3FEE6.7030606@incunabulum.net>
Message-ID: <49A423F1.8050700@kutulu.org>

On 2/24/2009 9:06 AM, Bruce Simpson wrote:
> Hi all,

> [1] revdep-rebuild has very similar semantics to what I'm looking for,
> as it will navigate the dependency graph for all packages installed on
> the system, and rebuild packages where dependent libraries have changed.
> To do the same with portupgrade alone, I need to know which port(s)
> contain shared libraries, and tell it to go off and rebuild these
> *specific* packages if things change.

I don't think revdep-rebuild works as cleanly as you think.
Technically, revdep-rebuild only locates packages that are *already 
broken* due to missing shared libraries, and rebuilds them.

What revdep-rebuild does is literally run ldd on every executable file 
in the search path, grep for either "not found" or a specific library 
name, then assign each broken binary to a package name for portage to 
rebuild.  This is exactly what libchk also does, so the effect would be 
the same.  Specifically, revdep-rebuild also won't pick up missing 
dlopen() libs and such.

The semantics you're talking about sounds like the new @preserved-libs 
set that's in the upcoming portage, but in order for that to work it has 
to be maintained at the time of library update: as a shared lib is moved 
into the compat folder, record any packages that depend on the 
previously installed package into a set for later rebuilding.

--K
From rnoland at FreeBSD.org  Tue Feb 24 11:10:18 2009
From: rnoland at FreeBSD.org (Robert Noland)
Date: Tue Feb 24 11:10:35 2009
Subject: Intel Q45 problems on 7.1-STABLE (fixed)
In-Reply-To: <200902242105.05667.doconnor@gsoft.com.au>
References: <200902231200.38164.doconnor@gsoft.com.au>
	<200902242105.05667.doconnor@gsoft.com.au>
Message-ID: <1235502609.1273.27.camel@widget.2hip.net>

On Tue, 2009-02-24 at 21:05 +1030, Daniel O'Connor wrote:
> On Monday 23 February 2009 12:00:30 Daniel O'Connor wrote:
> > Initially it hung solid when X started, however when I reduced the amount
> > of RAM to 2Gb it worked OK. Unfortunately if I exit X, or go to the text
> > console and back to X then the machine locks solid (no numlock, have to
> > hard reset).
> >
> > I note that dmesg reports 32764k of stolen memory, however I set the DVMT
> > RAM to 128Mb (and 256Mb, makes no difference). Also the aperture size is
> > always reported as 256Mb no matter what it actually is in the BIOS.
> 
> Someone in a private email suggested I update the BIOS (went from 63 to 73) 
> and it seems to work fine now.
> 
> The reported value of stolen memory is still wrong however.

Hrm, I wonder if I have missed an MFC...  Please send me some logs and
additional details.

Your -STABLE is current right?

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/20090224/2fcd89c3/attachment.pgp
From pluknet at gmail.com  Tue Feb 24 12:13:35 2009
From: pluknet at gmail.com (pluknet)
Date: Tue Feb 24 12:13:42 2009
Subject: E7400 Speedstep support?
In-Reply-To: <200902241956.46306.doconnor@gsoft.com.au>
References: <200902241956.46306.doconnor@gsoft.com.au>
Message-ID: <a31046fc0902241213r514888elc847d7ab3f62bb9d@mail.gmail.com>

2009/2/24 Daniel O'Connor <doconnor@gsoft.com.au>:
> Hi,
> I recently got a new Intel E7400 based system and dmesg reports..
> est0: <Enhanced SpeedStep Frequency Control> on cpu0
> est0: Guessed bus clock (high) of 37 MHz
> est0: Guessed bus clock (low) of 466 MHz
> est: CPU supports Enhanced Speedstep, but is not recognized.
> est: cpu_vendor GenuineIntel, msr 6164a2206004a22
> device_attach: est0 attach returned 6
> p4tcc0: <CPU Frequency Thermal Control> on cpu0
> cpu1: <ACPI CPU> on acpi0
> est1: <Enhanced SpeedStep Frequency Control> on cpu1
> est1: Guessed bus clock (high) of 37 MHz
> est1: Guessed bus clock (low) of 466 MHz
> est: CPU supports Enhanced Speedstep, but is not recognized.
> est: cpu_vendor GenuineIntel, msr 6164a2206004a22
> device_attach: est1 attach returned 6
> p4tcc1: <CPU Frequency Thermal Control> on cpu1
>
> I'm running 7.1-STABLE and I was wondering how hard it is to add support for
> est for this CPU?
>

May those error messages be BIOS related?
>From my E7200 (well, this is from -current):

cpu0: <ACPI CPU> on acpi0
ACPI Warning (tbutils-0243): Incorrect checksum in table [OEMB] -  CF, should be
 C6 [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

dev.cpu has also expected values.

-- 
wbr,
pluknet
From rwatson at FreeBSD.org  Tue Feb 24 13:31:11 2009
From: rwatson at FreeBSD.org (Robert Watson)
Date: Tue Feb 24 13:31:18 2009
Subject: Big problems with 7.1 locking up :-(
In-Reply-To: <22176398.post@talk.nabble.com>
References: <E1LL6dg-0007CN-DI@dilbert.ticketswitch.com>
	<E1LOsTE-000N7h-SL@dilbert.ticketswitch.com>
	<20090119132504.GA6853@dchagin.dialup.corbina.ru>
	<E1LOuGG-000NW3-1y@dilbert.ticketswitch.com>
	<22176398.post@talk.nabble.com>
Message-ID: <alpine.BSF.2.00.0902242129160.76842@fledge.watson.org>

On Mon, 23 Feb 2009, aneeth wrote:

>>> http://www.freebsd.org/cgi/query-pr.cgi?pr=130652&cat=
>>
>> OK, will give this a try, unless anyone else wants any traces from this 
>> locked machine ? Is there a known way to tickle this bug when I've 
>> rebooted, to make sure it's fixed ?
>
> We'v been having similar issues with a couple of our servers as well (7.0 
> and 7.1). However the problem shows up only on quad core machines. The dual 
> core machines r running fine.

FYI, I'm currently awaiting testing results from Pete on the MFC of a number 
of routing table locking fixes, and once that's merged (hopefully tomorrow?) 
I'll start on the patches in the above PR.  I've taken a crash-course in 
routing table locking in the last few days... :-)

The patches I sent him are at:

   http://www.watson.org/~robert/freebsd/20090221-route-locking.diff

They do not include the patch from the above PR which I want to handle 
separately as it's a significantly different issue.

Robert N M Watson
Computer Laboratory
University of Cambridge
From ghelmer at palisadesys.com  Tue Feb 24 13:46:43 2009
From: ghelmer at palisadesys.com (Guy Helmer)
Date: Tue Feb 24 13:46:51 2009
Subject: 7.1 hangs in cache_lookup mutex?
Message-ID: <49A46AB4.3080003@palisadesys.com>

I think I may have found a clue regarding some of the hangs I'm seeing 
on FreeBSD 7.1.
I have a program (kvoop), compiled under FreeBSD 6 and using 
compatibility libraries under FreeBSD 7, that seems to be consistently 
involved during these hangs.  This time, I noticed that many processes 
are stopped, waiting on the ufs lock.  I can't tell for certain, but I 
assume this kvoop process 33203 is blocking the other processes.  The 
kvoop process looks to me like it is waiting for a mutex, but nothing 
shows up being deadlocked.  Am I on the right track?  Is there something 
else I should be looking for?

(kgdb) proc 33203
[Switching to thread 129 (Thread 100241)]#0  sched_switch (
    td=0xffffff0019109a50, newtd=0x0, flags=1)
    at ../../../kern/sched_ule.c:1944
1944                    cpuid = PCPU_GET(cpuid);
(kgdb) where
#0  sched_switch (td=0xffffff0019109a50, newtd=0x0, flags=1)
    at ../../../kern/sched_ule.c:1944
#1  0xffffffff803a573b in mi_switch (flags=1, newtd=0x0)
    at ../../../kern/kern_synch.c:440
#2  0xffffffff803d1214 in turnstile_wait (ts=Variable "ts" is not available.
)
    at ../../../kern/subr_turnstile.c:748
#3  0xffffffff80392db0 in _mtx_lock_sleep (m=0xffffffff8083c220,
    tid=18446742974618442320, opts=Variable "opts" is not available.
) at ../../../kern/kern_mutex.c:420
#4  0xffffffff80392ea6 in _mtx_lock_flags (m=0xffffffff8083c220, opts=0,
    file=0xffffffff805bd438 "../../../kern/vfs_cache.c", line=327)
    at ../../../kern/kern_mutex.c:186
#5  0xffffffff80403bc6 in cache_lookup (dvp=0xffffff00013e0dc8,
    vpp=0xffffffffa2d93a18, cnp=0xffffffffa2d93a40)
    at ../../../kern/vfs_cache.c:327
#6  0xffffffff80404093 in vfs_cache_lookup (ap=Variable "ap" is not 
available.
)
    at ../../../kern/vfs_cache.c:674
#7  0xffffffff805628a0 in VOP_LOOKUP_APV (vop=0xffffffff8076e440,
    a=0xffffffffa2d936b0) at vnode_if.c:99
#8  0xffffffff80409afd in lookup (ndp=0xffffffffa2d939f0) at vnode_if.h:57
#9  0xffffffff8040a824 in namei (ndp=0xffffffffa2d939f0)
    at ../../../kern/vfs_lookup.c:219
#10 0xffffffff8041dc4f in vn_open_cred (ndp=0xffffffffa2d939f0,
    flagp=0xffffffffa2d9393c, cmode=0, cred=0xffffff0001588600,
    fp=0xffffff0001964200) at ../../../kern/vfs_vnops.c:188
#11 0xffffffff8041ccc7 in kern_open (td=0xffffff0019109a50,
    path=0xffffac30 <Address 0xffffac30 out of bounds>, pathseg=Variable 
"pathseg" is not available.
)
    at ../../../kern/vfs_syscalls.c:1032
#12 0xffffffff80544660 in ia32_syscall (frame=0xffffffffa2d93c80)
    at ../../../amd64/ia32/ia32_syscall.c:182
#13 0xffffffff805014d0 in Xint0x80_syscall () at ia32_exception.S:65
#14 0x0000000028284037 in ?? ()

(kgdb) frame 4
#4  0xffffffff80392ea6 in _mtx_lock_flags (m=0xffffffff8083c220, opts=0,
    file=0xffffffff805bd438 "../../../kern/vfs_cache.c", line=327)
    at ../../../kern/kern_mutex.c:186
186             _get_sleep_lock(m, curthread, opts, file, line);
(kgdb) list
181                 ("mtx_lock() of spin mutex %s @ %s:%d", 
m->lock_object.lo_name,
182                 file, line));
183             WITNESS_CHECKORDER(&m->lock_object, opts | LOP_NEWORDER 
| LOP_EXCLUSIVE,
184                 file, line);
185
186             _get_sleep_lock(m, curthread, opts, file, line);
187             LOCK_LOG_LOCK("LOCK", &m->lock_object, opts, 
m->mtx_recurse, file,
188                 line);
189             WITNESS_LOCK(&m->lock_object, opts | LOP_EXCLUSIVE, 
file, line);
190             curthread->td_locks++;

(kgdb) print *m
$2 = {lock_object = {lo_name = 0xffffffff805bd5d2 "Name Cache",
    lo_type = 0xffffffff805bd5d2 "Name Cache", lo_flags = 16973824,
    lo_witness_data = {lod_list = {stqe_next = 0xffffffff807cd600},
      lod_witness = 0xffffffff807cd600}}, mtx_lock = 4, mtx_recurse = 0}


From torfinn.ingolfsen at broadpark.no  Tue Feb 24 14:47:59 2009
From: torfinn.ingolfsen at broadpark.no (Torfinn Ingolfsen)
Date: Tue Feb 24 14:48:10 2009
Subject: Old /etc files back, or cvs error?
In-Reply-To: <200902240058.31212.kstewart@owt.com>
References: <alpine.BSF.2.00.0902232254130.40842@wonkity.com>
	<200902240058.31212.kstewart@owt.com>
Message-ID: <20090224234756.cd59ce2d.torfinn.ingolfsen@broadpark.no>

On Tue, 24 Feb 2009 00:58:31 -0800
Kent Stewart <kstewart@owt.com> wrote:

> You are looking at the version for the 7.1 release version. The
> RELENG_7 version is

The real question is: why are the files in 7.1-release newer than those
in RELENG_7?
In other words: why haven't those files been updated in RELENG_7?

Are there something wrong with the newer files?

For RELENG_7 users it is inconvenient to have to go through all these
files every time a 7.1-release install gets updated to RELENG_7.
-- 
Regards,
Torfinn Ingolfsen

From wblock at wonkity.com  Tue Feb 24 14:53:20 2009
From: wblock at wonkity.com (Warren Block)
Date: Tue Feb 24 14:53:27 2009
Subject: Old /etc files back, or cvs error?
In-Reply-To: <200902240058.31212.kstewart@owt.com>
References: <alpine.BSF.2.00.0902232254130.40842@wonkity.com>
	<200902240058.31212.kstewart@owt.com>
Message-ID: <alpine.BSF.2.00.0902241538180.44980@wonkity.com>

On Tue, 24 Feb 2009, Kent Stewart wrote:
> On Monday 23 February 2009 10:11:45 pm Warren Block wrote:
>> Lately I've installed a couple of test systems from 7.1-RELEASE CDs,
>> then csupped to RELENG_7 from cvsup9:
>>
>> mergemaster adds a *lot* of old files in /etc that were not there in
>> 7.1-RELEASE.  (Remember the rc.d rework?  Like that.)  For example, a
>> bunch of bluetooth files and /etc/isdn/*.
>>
>> The version numbers and dates in mergemaster look wrong.  For example,
>> /etc/bluetooth/hcsecd.conf:
>>
>> # $Id: hcsecd.conf,v 1.1 2003/05/26 22:50:47 max Exp $
>> # $FreeBSD: src/etc/bluetooth/hcsecd.conf,v 1.3 2006/05/18 17:53:49 emax
>> Exp $
>>
>> Shouldn't that be 1.3.6.1 from Tue Nov 25 02:59:29 2008?
>
> You are looking at the version for the 7.1 release version. The RELENG_7
> version is
>
> Revision 1.3: download - view: text, markup, annotated - select for diffs
> Thu May 18 17:53:49 2006 UTC (2 years, 9 months ago) by emax
> Branches: MAIN
> CVS tags: RELENG_7_BP, RELENG_7_1_BP, RELENG_7_0_BP, RELENG_7_0_0_RELEASE,
> RELENG_7_0, RELENG_7, HEAD
> Branch point for: RELENG_7_1
> Diff to: previous 1.2: preferred, colored
> Changes since revision 1.2: +1 -1 lines

I guess I just don't understand.  Why did that file and so many others 
in /etc go backwards:

7.1-RELEASE had 1.3.6.1 2008/11/25

Three months later:

RELENG_7 (7.1-STABLE) has 1.3 2006/05/18

Were those later versions (maybe just version strings) included in 
7.1-RELEASE by mistake?  Were they tagged by mistake and this latest 
change is just fixing that error?

-Warren Block * Rapid City, South Dakota USA
From minimarmot at gmail.com  Tue Feb 24 15:23:28 2009
From: minimarmot at gmail.com (Ben Kaduk)
Date: Tue Feb 24 15:23:35 2009
Subject: Old /etc files back, or cvs error?
In-Reply-To: <alpine.BSF.2.00.0902241538180.44980@wonkity.com>
References: <alpine.BSF.2.00.0902232254130.40842@wonkity.com>
	<200902240058.31212.kstewart@owt.com>
	<alpine.BSF.2.00.0902241538180.44980@wonkity.com>
Message-ID: <47d0403c0902241458m32738f53l58ef878ff61c8478@mail.gmail.com>

On Tue, Feb 24, 2009 at 5:53 PM, Warren Block <wblock@wonkity.com> wrote:
>
> I guess I just don't understand.  Why did that file and so many others in
> /etc go backwards:
>
> 7.1-RELEASE had 1.3.6.1 2008/11/25
>
> Three months later:
>
> RELENG_7 (7.1-STABLE) has 1.3 2006/05/18
>
> Were those later versions (maybe just version strings) included in
> 7.1-RELEASE by mistake?  Were they tagged by mistake and this latest change
> is just fixing that error?

I think the 2008/11/25 date is from when RELENG_7_1 was branched --- the branch
took place after the file was created, so it looks newer, even though
the content is the same.

-Ben Kaduk
From doconnor at gsoft.com.au  Tue Feb 24 15:23:34 2009
From: doconnor at gsoft.com.au (Daniel O'Connor)
Date: Tue Feb 24 15:23:59 2009
Subject: E7400 Speedstep support?
In-Reply-To: <a31046fc0902241213r514888elc847d7ab3f62bb9d@mail.gmail.com>
References: <200902241956.46306.doconnor@gsoft.com.au>
	<a31046fc0902241213r514888elc847d7ab3f62bb9d@mail.gmail.com>
Message-ID: <200902250953.20666.doconnor@gsoft.com.au>

On Wednesday 25 February 2009 06:43:33 pluknet wrote:
> May those error messages be BIOS related?
> From my E7200 (well, this is from -current):

Could be, bubt I have the latest BIOS..

> cpu0: <ACPI CPU> on acpi0
> ACPI Warning (tbutils-0243): Incorrect checksum in table [OEMB] -  CF,
> should be C6 [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
>
> dev.cpu has also expected values.

Hmm OK, but maybe the 7400 hasn't been added? (or I have a different rev or 
something..)

-- 
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: 189 bytes
Desc: This is a digitally signed message part.
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20090224/74c4d84b/attachment.pgp
From doconnor at gsoft.com.au  Tue Feb 24 15:24:40 2009
From: doconnor at gsoft.com.au (Daniel O'Connor)
Date: Tue Feb 24 15:24:50 2009
Subject: Intel Q45 problems on 7.1-STABLE (fixed)
In-Reply-To: <1235502609.1273.27.camel@widget.2hip.net>
References: <200902231200.38164.doconnor@gsoft.com.au>
	<200902242105.05667.doconnor@gsoft.com.au>
	<1235502609.1273.27.camel@widget.2hip.net>
Message-ID: <200902250954.21944.doconnor@gsoft.com.au>

Skipped content of type multipart/mixed-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20090224/ec1d4a46/attachment.pgp
From ertr1013 at student.uu.se  Tue Feb 24 15:45:08 2009
From: ertr1013 at student.uu.se (Erik Trulsson)
Date: Tue Feb 24 15:45:17 2009
Subject: Old /etc files back, or cvs error?
In-Reply-To: <alpine.BSF.2.00.0902241538180.44980@wonkity.com>
References: <alpine.BSF.2.00.0902232254130.40842@wonkity.com>
	<200902240058.31212.kstewart@owt.com>
	<alpine.BSF.2.00.0902241538180.44980@wonkity.com>
Message-ID: <20090224232945.GA22871@owl.midgard.homeip.net>

On Tue, Feb 24, 2009 at 03:53:18PM -0700, Warren Block wrote:
> On Tue, 24 Feb 2009, Kent Stewart wrote:
> > On Monday 23 February 2009 10:11:45 pm Warren Block wrote:
> >> Lately I've installed a couple of test systems from 7.1-RELEASE CDs,
> >> then csupped to RELENG_7 from cvsup9:
> >>
> >> mergemaster adds a *lot* of old files in /etc that were not there in
> >> 7.1-RELEASE.  (Remember the rc.d rework?  Like that.)  For example, a
> >> bunch of bluetooth files and /etc/isdn/*.
> >>
> >> The version numbers and dates in mergemaster look wrong.  For example,
> >> /etc/bluetooth/hcsecd.conf:
> >>
> >> # $Id: hcsecd.conf,v 1.1 2003/05/26 22:50:47 max Exp $
> >> # $FreeBSD: src/etc/bluetooth/hcsecd.conf,v 1.3 2006/05/18 17:53:49 emax
> >> Exp $
> >>
> >> Shouldn't that be 1.3.6.1 from Tue Nov 25 02:59:29 2008?
> >
> > You are looking at the version for the 7.1 release version. The RELENG_7
> > version is
> >
> > Revision 1.3: download - view: text, markup, annotated - select for diffs
> > Thu May 18 17:53:49 2006 UTC (2 years, 9 months ago) by emax
> > Branches: MAIN
> > CVS tags: RELENG_7_BP, RELENG_7_1_BP, RELENG_7_0_BP, RELENG_7_0_0_RELEASE,
> > RELENG_7_0, RELENG_7, HEAD
> > Branch point for: RELENG_7_1
> > Diff to: previous 1.2: preferred, colored
> > Changes since revision 1.2: +1 -1 lines
> 
> I guess I just don't understand.  Why did that file and so many others 
> in /etc go backwards:
> 
> 7.1-RELEASE had 1.3.6.1 2008/11/25
> 
> Three months later:
> 
> RELENG_7 (7.1-STABLE) has 1.3 2006/05/18
> 
> Were those later versions (maybe just version strings) included in 
> 7.1-RELEASE by mistake?  Were they tagged by mistake and this latest 
> change is just fixing that error?

The tagging itself causes the version number of the file to be updated.
This makes the file in -RELEASE *look* newer then the ones in -STABLE even
if the contents of the files haven't actually changed.

So there is no mistake, just an annoying side-effect of how the svn->cvs 
export works with regards to tagging.



-- 
<Insert your favourite quote here.>
Erik Trulsson
ertr1013@student.uu.se
From rnoland at FreeBSD.org  Tue Feb 24 16:35:54 2009
From: rnoland at FreeBSD.org (Robert Noland)
Date: Tue Feb 24 16:36:01 2009
Subject: Intel Q45 problems on 7.1-STABLE (fixed)
In-Reply-To: <200902250954.21944.doconnor@gsoft.com.au>
References: <200902231200.38164.doconnor@gsoft.com.au>
	<200902242105.05667.doconnor@gsoft.com.au>
	<1235502609.1273.27.camel@widget.2hip.net>
	<200902250954.21944.doconnor@gsoft.com.au>
Message-ID: <1235522145.1273.63.camel@widget.2hip.net>

On Wed, 2009-02-25 at 09:54 +1030, Daniel O'Connor wrote:
> On Wednesday 25 February 2009 05:40:09 Robert Noland wrote:
> > > The reported value of stolen memory is still wrong however.
> >
> > Hrm, I wonder if I have missed an MFC...  Please send me some logs and
> > additional details.
> >
> > Your -STABLE is current right?
> 
> It's about a week or so old.
> I can update it if you like (or I can let you know specific revs)

That is new enough.

> I've attached dmesg and Xorg log, although the former is truncated due to 
> verbose booting..

The code all looks correct based on the Q45 docs.  I can only assume
that the BIOS is still not doing the right thing for your settings.

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/20090225/6279df3e/attachment.pgp
From STEVE at STEVENWILLS.COM  Tue Feb 24 17:26:29 2009
From: STEVE at STEVENWILLS.COM (Steve Wills)
Date: Tue Feb 24 17:26:42 2009
Subject: 7.1-R to RELENG_7 upgrade breaks re nic
Message-ID: <AE144701-409A-4D9F-9947-A725B0810ACA@STEVENWILLS.COM>

Hi,

I upgraded my 7.1-RELEASE system to RELENG_7 yesterday and after  
booting, re0 works for only a short time, then gives "re0: PHY read  
failed" over and over. Does anyone have a suggestion on how to debug?

Thanks,
Steve
From dougb at FreeBSD.org  Tue Feb 24 19:34:30 2009
From: dougb at FreeBSD.org (Doug Barton)
Date: Tue Feb 24 19:34:39 2009
Subject: Old /etc files back, or cvs error?
In-Reply-To: <alpine.BSF.2.00.0902232254130.40842@wonkity.com>
References: <alpine.BSF.2.00.0902232254130.40842@wonkity.com>
Message-ID: <49A4BC40.1080301@FreeBSD.org>

Warren Block wrote:
> Lately I've installed a couple of test systems from 7.1-RELEASE CDs,
> then csupped to RELENG_7 from cvsup9:
> 
> *default host=cvsup9.FreeBSD.org
> *default base=/var/db
> *default prefix=/usr
> *default release=cvs tag=RELENG_7
> *default delete use-rel-suffix

That looks right.

> mergemaster adds a *lot* of old files in /etc that were not there in
> 7.1-RELEASE.  (Remember the rc.d rework?  Like that.)  For example, a
> bunch of bluetooth files and /etc/isdn/*.

That is definitely not the outcome you should have ended up with.

I just checked both the official svn repo and the official cvs repo
and the files they are passing out for the two relevant branches are
correct, and the real differences (not $Id tags) between the files in
the two branches are what I expected to see. Therefore, the problem is
somewhere downstream.

> This looks like an error, but maybe I'm missing something.  And other
> cvsup mirrors seem to agree with cvsup9.

My suggestion to you would be to move all source trees that you may
have currently somewhere else, move aside /var/db/sup, then start over
from scratch and see if what you get is what you expect.

If that doesn't work, please script your mergemaster session and send
us the output.

hope this helps,

Doug


-- 

    This .signature sanitized for your protection
From dougb at FreeBSD.org  Tue Feb 24 19:37:04 2009
From: dougb at FreeBSD.org (Doug Barton)
Date: Tue Feb 24 19:37:11 2009
Subject: Old /etc files back, or cvs error?
In-Reply-To: <20090224234756.cd59ce2d.torfinn.ingolfsen@broadpark.no>
References: <alpine.BSF.2.00.0902232254130.40842@wonkity.com>	<200902240058.31212.kstewart@owt.com>
	<20090224234756.cd59ce2d.torfinn.ingolfsen@broadpark.no>
Message-ID: <49A4BCDE.9070807@FreeBSD.org>

Torfinn Ingolfsen wrote:
> On Tue, 24 Feb 2009 00:58:31 -0800
> Kent Stewart <kstewart@owt.com> wrote:
> 
>> You are looking at the version for the 7.1 release version. The
>> RELENG_7 version is
> 
> The real question is: why are the files in 7.1-release newer than those
> in RELENG_7?

They aren't. At least not in the master svn and cvs repositories.

Doug

-- 

    This .signature sanitized for your protection
From doconnor at gsoft.com.au  Tue Feb 24 19:42:47 2009
From: doconnor at gsoft.com.au (Daniel O'Connor)
Date: Tue Feb 24 19:43:04 2009
Subject: Intel Q45 problems on 7.1-STABLE (fixed)
In-Reply-To: <1235522145.1273.63.camel@widget.2hip.net>
References: <200902231200.38164.doconnor@gsoft.com.au>
	<200902250954.21944.doconnor@gsoft.com.au>
	<1235522145.1273.63.camel@widget.2hip.net>
Message-ID: <200902251412.33822.doconnor@gsoft.com.au>

On Wednesday 25 February 2009 11:05:45 Robert Noland wrote:
> > I've attached dmesg and Xorg log, although the former is truncated due to
> > verbose booting..
>
> The code all looks correct based on the Q45 docs.  I can only assume
> that the BIOS is still not doing the right thing for your settings.

How annoying since it's an Intel product you'd hope they could get it right :(

Thanks.

-- 
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: 189 bytes
Desc: This is a digitally signed message part.
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20090225/0069158a/attachment.pgp
From oberman at es.net  Tue Feb 24 22:19:00 2009
From: oberman at es.net (Kevin Oberman)
Date: Tue Feb 24 22:19:11 2009
Subject: 7.1 hangs in cache_lookup mutex? 
In-Reply-To: Your message of "Tue, 24 Feb 2009 15:46:28 CST."
	<49A46AB4.3080003@palisadesys.com> 
Message-ID: <20090225061857.4CAE21CC0B@ptavv.es.net>

> Date: Tue, 24 Feb 2009 15:46:28 -0600
> From: Guy Helmer <ghelmer@palisadesys.com>
> Sender: owner-freebsd-stable@freebsd.org
> 
> I think I may have found a clue regarding some of the hangs I'm seeing 
> on FreeBSD 7.1.
> I have a program (kvoop), compiled under FreeBSD 6 and using 
> compatibility libraries under FreeBSD 7, that seems to be consistently 
> involved during these hangs.  This time, I noticed that many processes 
> are stopped, waiting on the ufs lock.  I can't tell for certain, but I 
> assume this kvoop process 33203 is blocking the other processes.  The 
> kvoop process looks to me like it is waiting for a mutex, but nothing 
> shows up being deadlocked.  Am I on the right track?  Is there something 
> else I should be looking for?

For whatever it is worth, I have seen this three times over the past
couple of weeks. My system is RELENG_7 of Feb. 7. I have no real
information to add other than that I have also had this problem. When it
happens, the only way out is a reboot. It hit me twice while updating
Xorg. 

Thanks for your efforts! I hope someone can track down what is triggering
with this.
-- 
R. Kevin Oberman, Network Engineer
Energy Sciences Network (ESnet)
Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab)
E-mail: oberman@es.net			Phone: +1 510 486-8634
Key fingerprint:059B 2DDF 031C 9BA3 14A4  EADA 927D EBB3 987B 3751
From ob at e-Gitt.NET  Wed Feb 25 00:22:41 2009
From: ob at e-Gitt.NET (Oliver Brandmueller)
Date: Wed Feb 25 00:22:48 2009
Subject: 7.1-R to RELENG_7 upgrade breaks re nic
In-Reply-To: <AE144701-409A-4D9F-9947-A725B0810ACA@STEVENWILLS.COM>
References: <AE144701-409A-4D9F-9947-A725B0810ACA@STEVENWILLS.COM>
Message-ID: <20090225082239.GY79003@e-Gitt.NET>

Hi,

On Tue, Feb 24, 2009 at 08:12:18PM -0500, Steve Wills wrote:
> I upgraded my 7.1-RELEASE system to RELENG_7 yesterday and after  
> booting, re0 works for only a short time, then gives "re0: PHY read  
> failed" over and over. Does anyone have a suggestion on how to debug?

The Patch from <20090213113955.GE12653@michelle.cdnetworks.co.kr> 
(Thread: "fun with re", Feb 13 on this list) helped for me. You may try 
it and could also give feedback so it gets included.

- Olli

-- 
| Oliver Brandmueller | Offenbacher Str. 1  | Germany       D-14197 Berlin |
| Fon +49-172-3130856 | Fax +49-172-3145027 | WWW:   http://the.addict.de/ |
|               Ich bin das Internet. Sowahr ich Gott helfe.               |
| Eine gewerbliche Nutzung aller enthaltenen Adressen ist nicht gestattet! |
From ob at e-Gitt.NET  Wed Feb 25 00:25:01 2009
From: ob at e-Gitt.NET (Oliver Brandmueller)
Date: Wed Feb 25 00:25:53 2009
Subject: 7.1-R to RELENG_7 upgrade breaks re nic
In-Reply-To: <20090225082239.GY79003@e-Gitt.NET>
References: <AE144701-409A-4D9F-9947-A725B0810ACA@STEVENWILLS.COM>
	<20090225082239.GY79003@e-Gitt.NET>
Message-ID: <20090225082459.GZ79003@e-Gitt.NET>

Hi,

On Wed, Feb 25, 2009 at 09:22:39AM +0100, Oliver Brandmueller wrote:
> On Tue, Feb 24, 2009 at 08:12:18PM -0500, Steve Wills wrote:
> > I upgraded my 7.1-RELEASE system to RELENG_7 yesterday and after  
> > booting, re0 works for only a short time, then gives "re0: PHY read  
> > failed" over and over. Does anyone have a suggestion on how to debug?
> 
> The Patch from <20090213113955.GE12653@michelle.cdnetworks.co.kr> 
> (Thread: "fun with re", Feb 13 on this list) helped for me. You may try 
> it and could also give feedback so it gets included.

Sorry:

From: Pyun YongHyeon
Subject: Re: fun with if_re

- Olli

-- 
| Oliver Brandmueller | Offenbacher Str. 1  | Germany       D-14197 Berlin |
| Fon +49-172-3130856 | Fax +49-172-3145027 | WWW:   http://the.addict.de/ |
|               Ich bin das Internet. Sowahr ich Gott helfe.               |
| Eine gewerbliche Nutzung aller enthaltenen Adressen ist nicht gestattet! |
From petefrench at ticketswitch.com  Wed Feb 25 01:47:44 2009
From: petefrench at ticketswitch.com (Pete French)
Date: Wed Feb 25 01:47:51 2009
Subject: Big problems with 7.1 locking up :-(
In-Reply-To: <alpine.BSF.2.00.0902242129160.76842@fledge.watson.org>
Message-ID: <E1LcGMf-000Om9-Ey@dilbert.ticketswitch.com>

> FYI, I'm currently awaiting testing results from Pete on the MFC of a number 
> of routing table locking fixes, and once that's merged (hopefully tomorrow?) 
> I'll start on the patches in the above PR.  I've taken a crash-course in 
> routing table locking in the last few days... :-)

Just to let you know that I have had zero crashes since I out the patch
live on sunday. Of course thats only three days, but it does look
very much like it has fixed it. I am also running with the other
routing table patch too..

At this point no news is good news, as it is just sitting there
ticking away nicely to itself. I will roll it out to a few more
machines over the next few days.

But looking good so far, I would encourage other people to try
the ptches if they are having problems...

-pete.
From rwatson at FreeBSD.org  Wed Feb 25 03:04:30 2009
From: rwatson at FreeBSD.org (Robert Watson)
Date: Wed Feb 25 03:04:37 2009
Subject: Big problems with 7.1 locking up :-(
In-Reply-To: <E1LcGMf-000Om9-Ey@dilbert.ticketswitch.com>
References: <E1LcGMf-000Om9-Ey@dilbert.ticketswitch.com>
Message-ID: <alpine.BSF.2.00.0902251051230.64866@fledge.watson.org>

On Wed, 25 Feb 2009, Pete French wrote:

>> FYI, I'm currently awaiting testing results from Pete on the MFC of a 
>> number of routing table locking fixes, and once that's merged (hopefully 
>> tomorrow?) I'll start on the patches in the above PR.  I've taken a 
>> crash-course in routing table locking in the last few days... :-)
>
> Just to let you know that I have had zero crashes since I out the patch live 
> on sunday. Of course thats only three days, but it does look very much like 
> it has fixed it. I am also running with the other routing table patch too..
>
> At this point no news is good news, as it is just sitting there ticking away 
> nicely to itself. I will roll it out to a few more machines over the next 
> few days.
>
> But looking good so far, I would encourage other people to try the ptches if 
> they are having problems...

Thanks -- I've gone ahead and merged the patch to 7.x (r189026) so that I can 
look at the PR and get that in-progress.  Since the code affected by the PR is 
no longer in 8.x, I'll merge directly to 7.x, and probably fairly quickly 
since you've had it in production for a while.

Robert N M Watson
Computer Laboratory
University of Cambridge
From rwatson at FreeBSD.org  Wed Feb 25 03:32:41 2009
From: rwatson at FreeBSD.org (Robert Watson)
Date: Wed Feb 25 03:32:48 2009
Subject: Various route locking fixes merged to stable/7 (was: Re: Big
 problems with 7.1 locking up :-()
In-Reply-To: <alpine.BSF.2.00.0902251051230.64866@fledge.watson.org>
References: <E1LcGMf-000Om9-Ey@dilbert.ticketswitch.com>
	<alpine.BSF.2.00.0902251051230.64866@fledge.watson.org>
Message-ID: <alpine.BSF.2.00.0902251130240.64866@fledge.watson.org>


Just a minor heads up: I've merged both Kip Macy's lock order fixes to the 
kernel routing code, and the route locking and reference counting fixes from 
kern/130652 to stable/7.  These fixes should correct a number of reported 
network-related hangs.  We might want to release a subset of these as an 
errata patch to 7.1 if they shake out well in 7-stable.

Thanks again, especially, to Pete for his evaluation of bugs and patches, Kip 
for his fixes in head, and to Dmitrij Tejblum for his submission of the fixes 
in the above-mentioned PR.

Robert N M Watson
Computer Laboratory
University of Cambridge

On Wed, 25 Feb 2009, Robert Watson wrote:

> On Wed, 25 Feb 2009, Pete French wrote:
>
>>> FYI, I'm currently awaiting testing results from Pete on the MFC of a 
>>> number of routing table locking fixes, and once that's merged (hopefully 
>>> tomorrow?) I'll start on the patches in the above PR.  I've taken a 
>>> crash-course in routing table locking in the last few days... :-)
>> 
>> Just to let you know that I have had zero crashes since I out the patch 
>> live on sunday. Of course thats only three days, but it does look very much 
>> like it has fixed it. I am also running with the other routing table patch 
>> too..
>> 
>> At this point no news is good news, as it is just sitting there ticking 
>> away nicely to itself. I will roll it out to a few more machines over the 
>> next few days.
>> 
>> But looking good so far, I would encourage other people to try the ptches 
>> if they are having problems...
>
> Thanks -- I've gone ahead and merged the patch to 7.x (r189026) so that I can 
> look at the PR and get that in-progress.  Since the code affected by the PR 
> is no longer in 8.x, I'll merge directly to 7.x, and probably fairly quickly 
> since you've had it in production for a while.
>
> Robert N M Watson
> Computer Laboratory
> University of Cambridge
> _______________________________________________
> 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  Wed Feb 25 03:55:55 2009
From: onemda at gmail.com (Paul B. Mahol)
Date: Wed Feb 25 03:56:01 2009
Subject: Recommended wireless card (or is there a chance to get either
	iwi or ath fixed)?
In-Reply-To: <003601c9969c$e2cdc310$a8694930$@com>
References: <14989d6e0902230721x7a2cd30cw4e548451c87e17cd@mail.gmail.com>
	<003601c9969c$e2cdc310$a8694930$@com>
Message-ID: <3a142e750902250326s20879c29pc89bb9d6e802a4d1@mail.gmail.com>

On 2/24/09, SDH Support <admin@stardothosting.com> wrote:
>
>> I tried using my ath based D-Link DWL G650, which still seems to have
>> some issues in regard to interrupt handling:
>
>
> I've been able to get /most/ wireless cards working with ndiswrapper.

*BSD doesnt have ndiswrapper.


-- 
Paul
From gavin at FreeBSD.org  Wed Feb 25 04:13:03 2009
From: gavin at FreeBSD.org (Gavin Atkinson)
Date: Wed Feb 25 04:13:10 2009
Subject: 7.1 new install halts on BTX error
In-Reply-To: <alpine.DEB.1.10.0901142326370.12175@martello.ucc.gu.uwa.edu.au>
References: <alpine.DEB.1.10.0901142326370.12175@martello.ucc.gu.uwa.edu.au>
Message-ID: <1235563979.15704.6.camel@buffy.york.ac.uk>

On Thu, 2009-01-29 at 12:13 +0900, David Adam wrote:
> I upgraded my 7.0 system to 7.1-RELEASE with freebsd-update only to find 
> that it no longer boots correctly, instead crashing with a BTX backtrace. 
> If I break to the loader prompt and use 'ls /boot', I also get a 
> backtrace.
> 
> A new install of 7.1 on this hardware using a separate SCSI card and drive 
> array also leads to a BTX backtrace. I have copied this below as the first 
> (most repeatable) error and also included the other problems.
> 
> A fresh install of 7.0 works fine. FreeSBIE 1.0, based on FreeBSD 5.3, 
> also boots fine and will happily list the contents of the original drive's 
> /boot in the loader, although refuses to load the kernel. The FreeBSD 7.1 
> install CD also boots and allows me to install over FTP.

A patch has just gone into HEAD which may fix this problem.  If you want
to test it, it's at
http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/boot/i386/btx/btx/btx.S.diff?r1=1.47;r2=1.48
and should apply cleanly.

Thanks,

Gavin


> I have run into BTX problems on this machine before under -CURRENT (see 
> http://lists.freebsd.org/pipermail/freebsd-current/2008-October/089460.html
> ). Dmesg from 7.0 in 
> http://www.freebsd.org/cgi/query-pr.cgi?prp=125769-1-txt&n=/patch.txt
> 
> A new install of 7.1-RELEASE on separate disks leads to this backtrace:
> int=0000000d  err=00001840  efl=00010207  eip=00000511
> eax=04551364  ebx=00000000  ecx=00495cae  edx=00495cae
> esi=00000009  edi=00000001  ebp=00000000  esp=00495cae
> cs=002b  ds=0033  es=0033    fs=0033  gs=0033  ss=0033
> cs:eip=17 00 00 00 00 00 00 0c-00 00 00 00 00 00 00 b9
>        ae 5c 49 00 00 00 00 b9-ae 5c 49 00 00 00 00 c8
> ss:esp=43 18 3c 01 74 08 3c 04-0f 85 e4 00 00 00 0f b6
>        43 19 88 86 94 00 00 00-c7 46 30 00 00 00 00 3c
> 
> BTX error on boot with the 7.0 partition that has been upgraded to 7.1:
> 
> int=0000000d  err=00000000  efl=00010a92  eip=00000430
> eax=ffffff4c  ebx=00006c94  ecx=00000001  edx=00000080
> esi=00000001  edi=ffff9416  ebp=00000000  esp=0008f8b4
> cs=002b  ds=0033  es=002b    fs=0033  gs=0033  ss=0033
> cs:eip=6c 7f 94 48 00 00 00 00-0f af c1 47 00 00 00 00
>        00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00
> ss:eip=2b 00 00 00 33 00 00 00-00 0c 04 00 5f ad 08 04
>        00 00 00 00 0f 00 00 00-00 00 00 00 24 1c 06 00
> BTX halted
> 
> If I break to the loader prompt and try 'ls /boot', I get this backtrace:
> 
> int=00000006  err=00000000  efl=00010203  eip=00040c08
> eax=000000c6  ebx=00000008  ecx=eb000000  edx=000000c6
> esi=00000004  edi=000000c2  ebp=00000000  esp=0008f8b4
> cs=002b  ds=0033  es=002b    fs=0033  gs=0033  ss=0033
> cs:eip=8f 49 40 00 94 49 00 cb-00 00 04 00 00 00 fc 07
>        80 00 00 00 04 00 00 00-94 49 00 00 00 00 00 00
> ss:eip=00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00
>        00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00
> BTX halted
> 
> Any thoughts or suggestions? I will stay on 7.0 for now but have a fairly 
> large supply of spare drives so I can test new installs if required.
> 
> Thanks,
> 
> David Adam
> zanchey@ucc.gu.uwa.edu.au
> 
> _______________________________________________
> 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 unixmania at gmail.com  Wed Feb 25 04:28:08 2009
From: unixmania at gmail.com (Carlos A. M. dos Santos)
Date: Wed Feb 25 04:28:15 2009
Subject: Recommended wireless card (or is there a chance to get either
	iwi or ath fixed)?
In-Reply-To: <3a142e750902250326s20879c29pc89bb9d6e802a4d1@mail.gmail.com>
References: <14989d6e0902230721x7a2cd30cw4e548451c87e17cd@mail.gmail.com>
	<003601c9969c$e2cdc310$a8694930$@com>
	<3a142e750902250326s20879c29pc89bb9d6e802a4d1@mail.gmail.com>
Message-ID: <e71790db0902250406j5936edb3oc0ab4500138bd64b@mail.gmail.com>

On Wed, Feb 25, 2009 at 8:26 AM, Paul B. Mahol <onemda@gmail.com> wrote:
> On 2/24/09, SDH Support <admin@stardothosting.com> wrote:
>>
>>> I tried using my ath based D-Link DWL G650, which still seems to have
>>> some issues in regard to interrupt handling:
>>
>>
>> I've been able to get /most/ wireless cards working with ndiswrapper.
>
> *BSD doesnt have ndiswrapper.

Yes, it does:

http://www.freebsd.org/cgi/man.cgi?query=ndis&manpath=FreeBSD+7.1-RELEASE

-- 
My preferred quotation of Robert Louis Stevenson is "You cannot
make an omelette without breaking eggs". Not because I like the
omelettes, but because I like the sound of eggs being broken.
From cptsalek at gmail.com  Wed Feb 25 04:39:40 2009
From: cptsalek at gmail.com (Christian Walther)
Date: Wed Feb 25 04:39:47 2009
Subject: Recommended wireless card (or is there a chance to get either
	iwi or ath fixed)?
In-Reply-To: <003601c9969c$e2cdc310$a8694930$@com>
References: <14989d6e0902230721x7a2cd30cw4e548451c87e17cd@mail.gmail.com>
	<003601c9969c$e2cdc310$a8694930$@com>
Message-ID: <14989d6e0902250439u500da1b2x9967ed48833800ad@mail.gmail.com>

2009/2/24 SDH Support <admin@stardothosting.com>:
>
>> I tried using my ath based D-Link DWL G650, which still seems to have
>> some issues in regard to interrupt handling:
>
>
> I've been able to get /most/ wireless cards working with ndiswrapper.
>
This is just my personal opinion, and I tend to make scarce use of the
word "hate" - but in this case: I really hate ndiswrapper.
It might be suitable for some people, but I rather get some piece
hardware that is properly supported. Bugs are bad luck, of course, as
well as a kernel module author who stops working. But at least I don't
have to rely on a windows driver.
From utisoft at googlemail.com  Wed Feb 25 04:41:11 2009
From: utisoft at googlemail.com (Chris Rees)
Date: Wed Feb 25 04:41:19 2009
Subject: Recommended wireless card (or is there a chance to get either iwi
	or ath fixed)?
In-Reply-To: <b79ecaef0902250415oe0c9cefue65a4e104e9b829d@mail.gmail.com>
References: <14989d6e0902230721x7a2cd30cw4e548451c87e17cd@mail.gmail.com>
	<003601c9969c$e2cdc310$a8694930$@com>
	<3a142e750902250326s20879c29pc89bb9d6e802a4d1@mail.gmail.com>
	<b79ecaef0902250415oe0c9cefue65a4e104e9b829d@mail.gmail.com>
Message-ID: <b79ecaef0902250416r5b8e487cx630e5e20c6efdb6c@mail.gmail.com>

2009/2/25 Paul B. Mahol <onemda@gmail.com>:
> On 2/24/09, SDH Support <admin@stardothosting.com> wrote:
>>
>>> I tried using my ath based D-Link DWL G650, which still seems to have
>>> some issues in regard to interrupt handling:
>>
>>
>> I've been able to get /most/ wireless cards working with ndiswrapper.
>
> *BSD doesnt have ndiswrapper.
>
>
> --
> Paul
> _______________________________________________
> 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"
>

Yeah it does...

[chris@amnesiac]~% ndisgen
? ? ? ?==================================================================
? ? ? ?------------------ Windows(r) driver converter -------------------
? ? ? ?==================================================================

? ? ? ?This script is designed to guide you through the process
? ? ? ?of converting a Windows(r) binary driver module and .INF
? ? ? ?specification file into a FreeBSD ELF kernel module for use
? ? ? ?with the NDIS compatibility system.

? ? ? ?The following options are available:

? ? ? ?1] Learn about the NDIS compatibility system
? ? ? ?2] Convert individual firmware files
? ? ? ?3] Convert driver
? ? ? ?4] Exit

? ? ? ?Enter your selection here and press return:

--
R< $&h ! > $- ! $+ ? ? ?$@ $2 < @ $1 .UUCP. > (sendmail.cf)
From utisoft at googlemail.com  Wed Feb 25 05:33:28 2009
From: utisoft at googlemail.com (Chris Rees)
Date: Wed Feb 25 05:33:35 2009
Subject: Recommended wireless card (or is there a chance to get either
	iwi or ath fixed)?
In-Reply-To: <14989d6e0902250439u500da1b2x9967ed48833800ad@mail.gmail.com>
References: <14989d6e0902230721x7a2cd30cw4e548451c87e17cd@mail.gmail.com>
	<003601c9969c$e2cdc310$a8694930$@com>
	<14989d6e0902250439u500da1b2x9967ed48833800ad@mail.gmail.com>
Message-ID: <b79ecaef0902250533y274eba0fja5e5d59fb75d5e66@mail.gmail.com>

2009/2/25 Christian Walther <cptsalek@gmail.com>:
> 2009/2/24 SDH Support <admin@stardothosting.com>:
>>
>>> I tried using my ath based D-Link DWL G650, which still seems to have
>>> some issues in regard to interrupt handling:
>>
>>
>> I've been able to get /most/ wireless cards working with ndiswrapper.
>>
> This is just my personal opinion, and I tend to make scarce use of the
> word "hate" - but in this case: I really hate ndiswrapper.
> It might be suitable for some people, but I rather get some piece
> hardware that is properly supported. Bugs are bad luck, of course, as
> well as a kernel module author who stops working. But at least I don't
> have to rely on a windows driver.
> _______________________________________________
> 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"
>

True, but ndiswrapper for me was an epiphany of the incredible things
free software can do.

I found it right back in Debian Woody, where my Ralink card wasn't
supported. I got sick of Linux and moved to BSD, where the ral driver
was instantly recognised and loaded.

-- 
R< $&h ! > $- ! $+	$@ $2 < @ $1 .UUCP. > (sendmail.cf)
From patfbsd at davenulle.org  Wed Feb 25 05:47:23 2009
From: patfbsd at davenulle.org (Patrick Lamaiziere)
Date: Wed Feb 25 05:48:25 2009
Subject: Recommended wireless card (or is there a chance to get either 
 iwi or ath fixed)?
In-Reply-To: <3a142e750902250326s20879c29pc89bb9d6e802a4d1@mail.gmail.com>
References: <14989d6e0902230721x7a2cd30cw4e548451c87e17cd@mail.gmail.com>
	<003601c9969c$e2cdc310$a8694930$@com>
	<3a142e750902250326s20879c29pc89bb9d6e802a4d1@mail.gmail.com>
Message-ID: <4958652ce3a9058673b1d72fdc27b569.squirrel@lamaiziere.net>

> On 2/24/09, SDH Support <admin@stardothosting.com> wrote:
>>
>>> I tried using my ath based D-Link DWL G650, which still seems to have
>>> some issues in regard to interrupt handling:
>>
>>
>> I've been able to get /most/ wireless cards working with ndiswrapper.
>
> *BSD doesnt have ndiswrapper.

There is the ndis driver in FreeBSD. I've used a lot ndis with an Intel
2200 BG card. iwi was not reliable.



From jhb at freebsd.org  Wed Feb 25 06:36:13 2009
From: jhb at freebsd.org (John Baldwin)
Date: Wed Feb 25 06:36:19 2009
Subject: 7.1 hangs in cache_lookup mutex?
In-Reply-To: <49A46AB4.3080003@palisadesys.com>
References: <49A46AB4.3080003@palisadesys.com>
Message-ID: <200902250915.57562.jhb@freebsd.org>

On Tuesday 24 February 2009 4:46:28 pm Guy Helmer wrote:
> I think I may have found a clue regarding some of the hangs I'm seeing 
> on FreeBSD 7.1.
> I have a program (kvoop), compiled under FreeBSD 6 and using 
> compatibility libraries under FreeBSD 7, that seems to be consistently 
> involved during these hangs.  This time, I noticed that many processes 
> are stopped, waiting on the ufs lock.  I can't tell for certain, but I 
> assume this kvoop process 33203 is blocking the other processes.  The 
> kvoop process looks to me like it is waiting for a mutex, but nothing 
> shows up being deadlocked.  Am I on the right track?  Is there something 
> else I should be looking for?
> 
> (kgdb) proc 33203
> [Switching to thread 129 (Thread 100241)]#0  sched_switch (
>     td=0xffffff0019109a50, newtd=0x0, flags=1)
>     at ../../../kern/sched_ule.c:1944
> 1944                    cpuid = PCPU_GET(cpuid);
> (kgdb) where
> #0  sched_switch (td=0xffffff0019109a50, newtd=0x0, flags=1)
>     at ../../../kern/sched_ule.c:1944
> #1  0xffffffff803a573b in mi_switch (flags=1, newtd=0x0)
>     at ../../../kern/kern_synch.c:440
> #2  0xffffffff803d1214 in turnstile_wait (ts=Variable "ts" is not available.
> )
>     at ../../../kern/subr_turnstile.c:748
> #3  0xffffffff80392db0 in _mtx_lock_sleep (m=0xffffffff8083c220,
>     tid=18446742974618442320, opts=Variable "opts" is not available.
> ) at ../../../kern/kern_mutex.c:420
> #4  0xffffffff80392ea6 in _mtx_lock_flags (m=0xffffffff8083c220, opts=0,
>     file=0xffffffff805bd438 "../../../kern/vfs_cache.c", line=327)
>     at ../../../kern/kern_mutex.c:186
> #5  0xffffffff80403bc6 in cache_lookup (dvp=0xffffff00013e0dc8,
>     vpp=0xffffffffa2d93a18, cnp=0xffffffffa2d93a40)
>     at ../../../kern/vfs_cache.c:327
> #6  0xffffffff80404093 in vfs_cache_lookup (ap=Variable "ap" is not 
> available.
> )
>     at ../../../kern/vfs_cache.c:674
> #7  0xffffffff805628a0 in VOP_LOOKUP_APV (vop=0xffffffff8076e440,
>     a=0xffffffffa2d936b0) at vnode_if.c:99
> #8  0xffffffff80409afd in lookup (ndp=0xffffffffa2d939f0) at vnode_if.h:57
> #9  0xffffffff8040a824 in namei (ndp=0xffffffffa2d939f0)
>     at ../../../kern/vfs_lookup.c:219
> #10 0xffffffff8041dc4f in vn_open_cred (ndp=0xffffffffa2d939f0,
>     flagp=0xffffffffa2d9393c, cmode=0, cred=0xffffff0001588600,
>     fp=0xffffff0001964200) at ../../../kern/vfs_vnops.c:188
> #11 0xffffffff8041ccc7 in kern_open (td=0xffffff0019109a50,
>     path=0xffffac30 <Address 0xffffac30 out of bounds>, pathseg=Variable 
> "pathseg" is not available.
> )
>     at ../../../kern/vfs_syscalls.c:1032
> #12 0xffffffff80544660 in ia32_syscall (frame=0xffffffffa2d93c80)
>     at ../../../amd64/ia32/ia32_syscall.c:182
> #13 0xffffffff805014d0 in Xint0x80_syscall () at ia32_exception.S:65
> #14 0x0000000028284037 in ?? ()
> 
> (kgdb) frame 4
> #4  0xffffffff80392ea6 in _mtx_lock_flags (m=0xffffffff8083c220, opts=0,
>     file=0xffffffff805bd438 "../../../kern/vfs_cache.c", line=327)
>     at ../../../kern/kern_mutex.c:186
> 186             _get_sleep_lock(m, curthread, opts, file, line);
> (kgdb) list
> 181                 ("mtx_lock() of spin mutex %s @ %s:%d", 
> m->lock_object.lo_name,
> 182                 file, line));
> 183             WITNESS_CHECKORDER(&m->lock_object, opts | LOP_NEWORDER 
> | LOP_EXCLUSIVE,
> 184                 file, line);
> 185
> 186             _get_sleep_lock(m, curthread, opts, file, line);
> 187             LOCK_LOG_LOCK("LOCK", &m->lock_object, opts, 
> m->mtx_recurse, file,
> 188                 line);
> 189             WITNESS_LOCK(&m->lock_object, opts | LOP_EXCLUSIVE, 
> file, line);
> 190             curthread->td_locks++;
> 
> (kgdb) print *m
> $2 = {lock_object = {lo_name = 0xffffffff805bd5d2 "Name Cache",
>     lo_type = 0xffffffff805bd5d2 "Name Cache", lo_flags = 16973824,
>     lo_witness_data = {lod_list = {stqe_next = 0xffffffff807cd600},
>       lod_witness = 0xffffffff807cd600}}, mtx_lock = 4, mtx_recurse = 0}

Is this from a coredump or while the system is live?  mtx_lock = 4 indicates 
the mutex is unlocked, so there shouldn't be any threads waiting on it.

-- 
John Baldwin
From ghelmer at palisadesys.com  Wed Feb 25 07:02:20 2009
From: ghelmer at palisadesys.com (Guy Helmer)
Date: Wed Feb 25 07:02:28 2009
Subject: 7.1 hangs in cache_lookup mutex?
In-Reply-To: <200902250915.57562.jhb@freebsd.org>
References: <49A46AB4.3080003@palisadesys.com>
	<200902250915.57562.jhb@freebsd.org>
Message-ID: <49A55D78.1070604@palisadesys.com>

John Baldwin wrote:
> On Tuesday 24 February 2009 4:46:28 pm Guy Helmer wrote:
>   
>> I think I may have found a clue regarding some of the hangs I'm seeing 
>> on FreeBSD 7.1.
>> I have a program (kvoop), compiled under FreeBSD 6 and using 
>> compatibility libraries under FreeBSD 7, that seems to be consistently 
>> involved during these hangs.  This time, I noticed that many processes 
>> are stopped, waiting on the ufs lock.  I can't tell for certain, but I 
>> assume this kvoop process 33203 is blocking the other processes.  The 
>> kvoop process looks to me like it is waiting for a mutex, but nothing 
>> shows up being deadlocked.  Am I on the right track?  Is there something 
>> else I should be looking for?
>>
>> (kgdb) proc 33203
>> [Switching to thread 129 (Thread 100241)]#0  sched_switch (
>>     td=0xffffff0019109a50, newtd=0x0, flags=1)
>>     at ../../../kern/sched_ule.c:1944
>> 1944                    cpuid = PCPU_GET(cpuid);
>> (kgdb) where
>> #0  sched_switch (td=0xffffff0019109a50, newtd=0x0, flags=1)
>>     at ../../../kern/sched_ule.c:1944
>> #1  0xffffffff803a573b in mi_switch (flags=1, newtd=0x0)
>>     at ../../../kern/kern_synch.c:440
>> #2  0xffffffff803d1214 in turnstile_wait (ts=Variable "ts" is not available.
>> )
>>     at ../../../kern/subr_turnstile.c:748
>> #3  0xffffffff80392db0 in _mtx_lock_sleep (m=0xffffffff8083c220,
>>     tid=18446742974618442320, opts=Variable "opts" is not available.
>> ) at ../../../kern/kern_mutex.c:420
>> #4  0xffffffff80392ea6 in _mtx_lock_flags (m=0xffffffff8083c220, opts=0,
>>     file=0xffffffff805bd438 "../../../kern/vfs_cache.c", line=327)
>>     at ../../../kern/kern_mutex.c:186
>> #5  0xffffffff80403bc6 in cache_lookup (dvp=0xffffff00013e0dc8,
>>     vpp=0xffffffffa2d93a18, cnp=0xffffffffa2d93a40)
>>     at ../../../kern/vfs_cache.c:327
>> #6  0xffffffff80404093 in vfs_cache_lookup (ap=Variable "ap" is not 
>> available.
>> )
>>     at ../../../kern/vfs_cache.c:674
>> #7  0xffffffff805628a0 in VOP_LOOKUP_APV (vop=0xffffffff8076e440,
>>     a=0xffffffffa2d936b0) at vnode_if.c:99
>> #8  0xffffffff80409afd in lookup (ndp=0xffffffffa2d939f0) at vnode_if.h:57
>> #9  0xffffffff8040a824 in namei (ndp=0xffffffffa2d939f0)
>>     at ../../../kern/vfs_lookup.c:219
>> #10 0xffffffff8041dc4f in vn_open_cred (ndp=0xffffffffa2d939f0,
>>     flagp=0xffffffffa2d9393c, cmode=0, cred=0xffffff0001588600,
>>     fp=0xffffff0001964200) at ../../../kern/vfs_vnops.c:188
>> #11 0xffffffff8041ccc7 in kern_open (td=0xffffff0019109a50,
>>     path=0xffffac30 <Address 0xffffac30 out of bounds>, pathseg=Variable 
>> "pathseg" is not available.
>> )
>>     at ../../../kern/vfs_syscalls.c:1032
>> #12 0xffffffff80544660 in ia32_syscall (frame=0xffffffffa2d93c80)
>>     at ../../../amd64/ia32/ia32_syscall.c:182
>> #13 0xffffffff805014d0 in Xint0x80_syscall () at ia32_exception.S:65
>> #14 0x0000000028284037 in ?? ()
>>
>> (kgdb) frame 4
>> #4  0xffffffff80392ea6 in _mtx_lock_flags (m=0xffffffff8083c220, opts=0,
>>     file=0xffffffff805bd438 "../../../kern/vfs_cache.c", line=327)
>>     at ../../../kern/kern_mutex.c:186
>> 186             _get_sleep_lock(m, curthread, opts, file, line);
>> (kgdb) list
>> 181                 ("mtx_lock() of spin mutex %s @ %s:%d", 
>> m->lock_object.lo_name,
>> 182                 file, line));
>> 183             WITNESS_CHECKORDER(&m->lock_object, opts | LOP_NEWORDER 
>> | LOP_EXCLUSIVE,
>> 184                 file, line);
>> 185
>> 186             _get_sleep_lock(m, curthread, opts, file, line);
>> 187             LOCK_LOG_LOCK("LOCK", &m->lock_object, opts, 
>> m->mtx_recurse, file,
>> 188                 line);
>> 189             WITNESS_LOCK(&m->lock_object, opts | LOP_EXCLUSIVE, 
>> file, line);
>> 190             curthread->td_locks++;
>>
>> (kgdb) print *m
>> $2 = {lock_object = {lo_name = 0xffffffff805bd5d2 "Name Cache",
>>     lo_type = 0xffffffff805bd5d2 "Name Cache", lo_flags = 16973824,
>>     lo_witness_data = {lod_list = {stqe_next = 0xffffffff807cd600},
>>       lod_witness = 0xffffffff807cd600}}, mtx_lock = 4, mtx_recurse = 0}
>>     
>
> Is this from a coredump or while the system is live?  mtx_lock = 4 indicates 
> the mutex is unlocked, so there shouldn't be any threads waiting on it.
>
>   
That was from running kgdb on a vmcore file.  Would the state of the 
mutex be different than if I was running kgdb on a live kernel?

Thanks,
Guy

From sam at freebsd.org  Wed Feb 25 08:45:42 2009
From: sam at freebsd.org (Sam Leffler)
Date: Wed Feb 25 08:45:48 2009
Subject: Recommended wireless card (or is there a chance to get either
 iwi	or ath fixed)?
In-Reply-To: <b79ecaef0902250416r5b8e487cx630e5e20c6efdb6c@mail.gmail.com>
References: <14989d6e0902230721x7a2cd30cw4e548451c87e17cd@mail.gmail.com>	<003601c9969c$e2cdc310$a8694930$@com>	<3a142e750902250326s20879c29pc89bb9d6e802a4d1@mail.gmail.com>	<b79ecaef0902250415oe0c9cefue65a4e104e9b829d@mail.gmail.com>
	<b79ecaef0902250416r5b8e487cx630e5e20c6efdb6c@mail.gmail.com>
Message-ID: <49A57111.3070709@freebsd.org>

Chris Rees wrote:
> 2009/2/25 Paul B. Mahol <onemda@gmail.com>:
>   
>> On 2/24/09, SDH Support <admin@stardothosting.com> wrote:
>>     
>>>> I tried using my ath based D-Link DWL G650, which still seems to have
>>>> some issues in regard to interrupt handling:
>>>>         
>>> I've been able to get /most/ wireless cards working with ndiswrapper.
>>>       
>> *BSD doesnt have ndiswrapper.
>>
>>
>> --
>> Paul
>> _______________________________________________
>> 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"
>>
>>     
>
> Yeah it does...
>
> [chris@amnesiac]~% ndisgen
>        ==================================================================
>        ------------------ Windows(r) driver converter -------------------
>        ==================================================================
>
>        This script is designed to guide you through the process
>        of converting a Windows(r) binary driver module and .INF
>        specification file into a FreeBSD ELF kernel module for use
>        with the NDIS compatibility system.
>
>        The following options are available:
>
>        1] Learn about the NDIS compatibility system
>        2] Convert individual firmware files
>        3] Convert driver
>        4] Exit
>
>        Enter your selection here and press return:
>
>   
"ndiswrapper" refers to the linux version of the Bill Paul's project for 
freebsd.  They are very different; though have the same goal.

    Sam

From cpghost at cordula.ws  Wed Feb 25 11:05:50 2009
From: cpghost at cordula.ws (cpghost)
Date: Wed Feb 25 11:05:59 2009
Subject: Big problems with 7.1 locking up :-(
In-Reply-To: <alpine.BSF.2.00.0902251051230.64866@fledge.watson.org>
References: <E1LcGMf-000Om9-Ey@dilbert.ticketswitch.com>
	<alpine.BSF.2.00.0902251051230.64866@fledge.watson.org>
Message-ID: <20090225190546.GA13283@phenom.cordula.ws>

On Wed, Feb 25, 2009 at 11:04:29AM +0000, Robert Watson wrote:
> On Wed, 25 Feb 2009, Pete French wrote:
> 
> >> FYI, I'm currently awaiting testing results from Pete on the MFC of a 
> >> number of routing table locking fixes, and once that's merged (hopefully 
> >> tomorrow?) I'll start on the patches in the above PR.  I've taken a 
> >> crash-course in routing table locking in the last few days... :-)
> >
> > Just to let you know that I have had zero crashes since I out the
> > patch live on sunday. Of course thats only three days, but it does
> > look very much like it has fixed it. I am also running with the
> > other routing table patch too..  At this point no news is good
> > news, as it is just sitting there ticking away nicely to itself. I
> > will roll it out to a few more machines over the next few days.
> > But looking good so far, I would encourage other people to try the
> > ptches if they are having problems...
>  
> Thanks -- I've gone ahead and merged the patch to 7.x (r189026) so
> that I can look at the PR and get that in-progress.  Since the code
> affected by the PR is no longer in 8.x, I'll merge directly to 7.x,
> and probably fairly quickly since you've had it in production for a
> while.

Great! I hope this patch will also fix the mysterious hangs
I've experienced on Soekris routers since nov/dec 2008. Will
try in a few days and report back any further hangs.

> Robert N M Watson
> Computer Laboratory
> University of Cambridge

Regards,
-cpghost.

-- 
Cordula's Web. http://www.cordula.ws/
From jhb at freebsd.org  Wed Feb 25 14:03:03 2009
From: jhb at freebsd.org (John Baldwin)
Date: Wed Feb 25 14:03:11 2009
Subject: Possible fix to BTX boot hangs in 6.4 and 7.1
In-Reply-To: <200902242311.n1ONBFeF078757@svn.freebsd.org>
References: <200902242311.n1ONBFeF078757@svn.freebsd.org>
Message-ID: <200902251702.39725.jhb@freebsd.org>

On Tuesday 24 February 2009 6:11:15 pm John Baldwin wrote:
> Author: jhb
> Date: Tue Feb 24 23:11:15 2009
> New Revision: 189017
> URL: http://svn.freebsd.org/changeset/base/189017
> 
> Log:
>   Fix some more issues with the real mode BTX.
>   
>   The old BTX passed the general purpose registers from the 32-bit client to
>   the routines called via virtual 86 mode.  The new BTX did the same thing.
>   However, it turns out that some instructions behave differently in virtual 86
>   mode and real mode (even though this is under-documented).  For example, the
>   LEAVE instruction will cause an exception in real mode if any of the upper
>   16-bits of %ebp are non-zero after it executes.  In virtual 8086 mode the
>   upper 16-bits are simply ignored.  This could cause faults in hardware
>   interrupt handlers that inherited an %ebp larger than 0xffff from the 32-bit
>   client (loader, boot2, etc.) while running in real mode.
>   
>   To fix, when executing hardware interrupt handlers provide an explicit clean
>   state where all the general purpose and segment registers are zero upon
>   entry to the interrupt handler.  While here, I attempted to simplify the
>   control flow in the 'intusr' code that sets up the various stack frames
>   and exits protected mode to invoke the requested routine via real mode.
>   
>   A huge thanks to Tor Egge (tegge@) for debugging this issue.
>   
>   Submitted by:	tegge
>   Reviewed by:	tegge
>   Tested by:	bz
>   MFC after:	1 week

This has been confirmed to fix at least some of the boot hangs reported with
the BTX changes in 6.4 and 7.1.  If you had problems with the new boot code
in 6.4 or 7.1 this fix is probably worth trying out.

-- 
John Baldwin
From pyunyh at gmail.com  Wed Feb 25 16:33:09 2009
From: pyunyh at gmail.com (Pyun YongHyeon)
Date: Wed Feb 25 16:33:15 2009
Subject: 7.1-R to RELENG_7 upgrade breaks re nic
In-Reply-To: <AE144701-409A-4D9F-9947-A725B0810ACA@STEVENWILLS.COM>
References: <AE144701-409A-4D9F-9947-A725B0810ACA@STEVENWILLS.COM>
Message-ID: <20090226003842.GB63173@michelle.cdnetworks.co.kr>

On Tue, Feb 24, 2009 at 08:12:18PM -0500, Steve Wills wrote:
> Hi,
> 
> I upgraded my 7.1-RELEASE system to RELENG_7 yesterday and after  
> booting, re0 works for only a short time, then gives "re0: PHY read  
> failed" over and over. Does anyone have a suggestion on how to debug?
> 

I need more information for your hardware revision.
Would you show me dmesg output and revision number of if_re.c?
From pyunyh at gmail.com  Wed Feb 25 16:55:53 2009
From: pyunyh at gmail.com (Pyun YongHyeon)
Date: Wed Feb 25 16:56:00 2009
Subject: fun with if_re
In-Reply-To: <20090223115412.GO79003@e-Gitt.NET>
References: <20090204100507.5f223d9e.gerrit@pmp.uni-hannover.de>
	<20090204104655.GA73543@michelle.cdnetworks.co.kr>
	<20090205085812.b2deb1f7.gerrit@pmp.uni-hannover.de>
	<20090205082804.GD77461@michelle.cdnetworks.co.kr>
	<20090213101910.a126c14d.gerrit@pmp.uni-hannover.de>
	<20090213102400.GD12653@michelle.cdnetworks.co.kr>
	<20090213114143.a77f1acb.gerrit@pmp.uni-hannover.de>
	<20090213113955.GE12653@michelle.cdnetworks.co.kr>
	<20090223115412.GO79003@e-Gitt.NET>
Message-ID: <20090226010125.GC63173@michelle.cdnetworks.co.kr>

On Mon, Feb 23, 2009 at 12:54:12PM +0100, Oliver Brandmueller wrote:
> Hi,
> 
> On Fri, Feb 13, 2009 at 08:39:55PM +0900, Pyun YongHyeon wrote:
> > Ok, try attached patch.
> 
> > Index: sys/dev/re/if_re.c
> > ===================================================================
> > --- sys/dev/re/if_re.c	(revision 187352)
> > +++ sys/dev/re/if_re.c	(working copy)
> > @@ -158,6 +158,8 @@
> >  /* Tunables. */
> [...]
> 
> This seems to have fixed a regression I found after the latest re 
> changes. While the changes lead to a situation, where the re interface 
> (as opposed to before) seems to always attach, I had the problem that 
> after 1-2 days it failed (sorry, was just about to investigate when I 
> tried your patch and thus didn't write down the error message 
> associated).
> 
> With your patch my re seems to be running fine for the last days now.
> 

That's odd. The patch just revert register mapping method for
RTL8169SC family as memory mapped register access seems to have 
problems on RTL8169SC controllers. From the output below I think
your controller is RTL8168C PCIe controller so the patch has no
effect on your controller.
Would you tell me more details on your issue? CURRENT has more
robust code for PCIe based controllers so how about giving it a try
on stable/7? Just copying if_re.c/if_rl.c/if_rlreg.h from HEAD to
stable/7 should work.

> re0@pci0:4:0:0: class=0x020000 card=0x392c1462 chip=0x816810ec rev=0x02 hdr=0x00
>     vendor     = 'Realtek Semiconductor'
>     device     = 'RTL8168/8111 PCI-E Gigabit Ethernet NIC'
>     class      = network
>     subclass   = ethernet
> 
> re0: <RealTek 8168/8168B/8168C/8168CP/8168D/8111B/8111C/8111CP PCIe Gigabit Ethernet> port 0xd800-0xd8ff mem 0xfeaff000-0xfeafffff,0xf8ff0000-0xf8ffffff irq 18 at device 0.0 on pci4
> 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:21:85:1e:8b:c9
> re0: [FILTER]
> 
From spork at bway.net  Wed Feb 25 17:28:09 2009
From: spork at bway.net (Charles Sprickman)
Date: Wed Feb 25 17:28:16 2009
Subject: Various route locking fixes merged to stable/7 (was: Re: Big
 problems with 7.1 locking up :-()
In-Reply-To: <alpine.BSF.2.00.0902251130240.64866@fledge.watson.org>
References: <E1LcGMf-000Om9-Ey@dilbert.ticketswitch.com>
	<alpine.BSF.2.00.0902251051230.64866@fledge.watson.org>
	<alpine.BSF.2.00.0902251130240.64866@fledge.watson.org>
Message-ID: <alpine.OSX.2.00.0902252027450.509@freemac.nat.fasttrackmonkey.com>

On Wed, 25 Feb 2009, Robert Watson wrote:

> Just a minor heads up: I've merged both Kip Macy's lock order fixes to the 
> kernel routing code, and the route locking and reference counting fixes from 
> kern/130652 to stable/7.  These fixes should correct a number of reported 
> network-related hangs.  We might want to release a subset of these as an 
> errata patch to 7.1 if they shake out well in 7-stable.

+1

Charles


> Robert N M Watson
> Computer Laboratory
> University of Cambridge
>
> On Wed, 25 Feb 2009, Robert Watson wrote:
>
>> On Wed, 25 Feb 2009, Pete French wrote:
>> 
>>>> FYI, I'm currently awaiting testing results from Pete on the MFC of a 
>>>> number of routing table locking fixes, and once that's merged (hopefully 
>>>> tomorrow?) I'll start on the patches in the above PR.  I've taken a 
>>>> crash-course in routing table locking in the last few days... :-)
>>> 
>>> Just to let you know that I have had zero crashes since I out the patch 
>>> live on sunday. Of course thats only three days, but it does look very 
>>> much like it has fixed it. I am also running with the other routing table 
>>> patch too..
>>> 
>>> At this point no news is good news, as it is just sitting there ticking 
>>> away nicely to itself. I will roll it out to a few more machines over the 
>>> next few days.
>>> 
>>> But looking good so far, I would encourage other people to try the ptches 
>>> if they are having problems...
>> 
>> Thanks -- I've gone ahead and merged the patch to 7.x (r189026) so that I 
>> can look at the PR and get that in-progress.  Since the code affected by 
>> the PR is no longer in 8.x, I'll merge directly to 7.x, and probably fairly 
>> quickly since you've had it in production for a while.
>> 
>> Robert N M Watson
>> Computer Laboratory
>> University of Cambridge
>> _______________________________________________
>> 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 doconnor at gsoft.com.au  Wed Feb 25 18:55:56 2009
From: doconnor at gsoft.com.au (Daniel O'Connor)
Date: Wed Feb 25 18:56:04 2009
Subject: 7.1 reports serial ports disabled (but they work OK)
Message-ID: <200902261305.50545.doconnor@gsoft.com.au>

I have an amd64 7.1 install on a SuperMicro C2SBA+ and I see the following in 
dmesg..

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]

However the ports do work fine.

I was under the impression that this test was bogus on !i386 and had be 
removed but I guess I'm wrong :)

-- 
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: 189 bytes
Desc: This is a digitally signed message part.
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20090226/593b0f66/attachment.pgp
From STEVE at stevenwills.com  Wed Feb 25 19:47:11 2009
From: STEVE at stevenwills.com (Steve Wills)
Date: Wed Feb 25 19:47:18 2009
Subject: 7.1-R to RELENG_7 upgrade breaks re nic
In-Reply-To: <20090226003842.GB63173@michelle.cdnetworks.co.kr>
References: <AE144701-409A-4D9F-9947-A725B0810ACA@STEVENWILLS.COM>
	<20090226003842.GB63173@michelle.cdnetworks.co.kr>
Message-ID: <95AD32AC-93AE-4945-A18E-CE7099BEC3CA@stevenwills.com>

On Feb 25, 2009, at 7:38 PM, Pyun YongHyeon wrote:
> I need more information for your hardware revision.
> Would you show me dmesg output and revision number of if_re.c?

I assume you only need the re0 related output. If you need the full  
dmesg, let me know.

re0: <RealTek 8168/8168B/8168C/8168CP/8168D/8111B/8111C/8111CP PCIe  
Gigabit Ethernet> port 0x7e00-0x7eff mem 0xfd3ff000-0xfd3fffff, 
0xfd3f8000-0xfd3fbfff irq 16 at device 0.0 on pci8
re0: Chip rev. 0x28000000
re0: MAC rev. 0x00100000
re0: Ethernet address: 00:1f:d0:af:1a:4c
re0: [FILTER]
re0: link state changed to UP

$FreeBSD: src/sys/dev/re/if_re.c,v 1.95.2.41 2009/02/09 01:38:01  
yongari Exp $

I get 3 link state DOWN/UP notices when DHCP client starts. It works  
for exactly 60 seconds after boot, then stops. Patch from earlier "fun  
with if_re" thread didn't help, if_re.c from -CURRENT failed to build.  
Reverting back to rev 1.95.2.36.2.2 fixes it.

Thanks,
Steve

From pyunyh at gmail.com  Wed Feb 25 20:04:48 2009
From: pyunyh at gmail.com (Pyun YongHyeon)
Date: Wed Feb 25 20:04:55 2009
Subject: 7.1-R to RELENG_7 upgrade breaks re nic
In-Reply-To: <95AD32AC-93AE-4945-A18E-CE7099BEC3CA@stevenwills.com>
References: <AE144701-409A-4D9F-9947-A725B0810ACA@STEVENWILLS.COM>
	<20090226003842.GB63173@michelle.cdnetworks.co.kr>
	<95AD32AC-93AE-4945-A18E-CE7099BEC3CA@stevenwills.com>
Message-ID: <20090226041023.GD63173@michelle.cdnetworks.co.kr>

On Wed, Feb 25, 2009 at 10:47:07PM -0500, Steve Wills wrote:
> On Feb 25, 2009, at 7:38 PM, Pyun YongHyeon wrote:
> >I need more information for your hardware revision.
> >Would you show me dmesg output and revision number of if_re.c?
> 
> I assume you only need the re0 related output. If you need the full  
> dmesg, let me know.
> 
> re0: <RealTek 8168/8168B/8168C/8168CP/8168D/8111B/8111C/8111CP PCIe  
> Gigabit Ethernet> port 0x7e00-0x7eff mem 0xfd3ff000-0xfd3fffff, 
> 0xfd3f8000-0xfd3fbfff irq 16 at device 0.0 on pci8
> re0: Chip rev. 0x28000000
> re0: MAC rev. 0x00100000
> re0: Ethernet address: 00:1f:d0:af:1a:4c
> re0: [FILTER]
> re0: link state changed to UP
> 
> $FreeBSD: src/sys/dev/re/if_re.c,v 1.95.2.41 2009/02/09 01:38:01  
> yongari Exp $
> 
> I get 3 link state DOWN/UP notices when DHCP client starts. It works  

That's normal(Technically this is not correct behavior but it's the
way how it was implemented in driver). 

> for exactly 60 seconds after boot, then stops.

I guess re(4) thinks it lost established link. How about unplug and
then replug UTP cable? Would you show me "devinfo -rv | grep phy"?

>                                                Patch from earlier "fun  
> with if_re" thread didn't help,

Your issue is completely different one.    

>                                 if_re.c from -CURRENT failed to build.  

You have to use if_re.c/if_rl.c and if_rlreg.h from CURRENT to
build it on stable.

> Reverting back to rev 1.95.2.36.2.2 fixes it.
> 

Your controller looks like RTL8168D PCIe controller. ATM I have no
idea why if_re.c 1.95.2.41 does not work. I'll let you know if I
find a clue.
From STEVE at stevenwills.com  Wed Feb 25 20:15:42 2009
From: STEVE at stevenwills.com (Steve Wills)
Date: Wed Feb 25 20:15:49 2009
Subject: 7.1-R to RELENG_7 upgrade breaks re nic
In-Reply-To: <20090226041023.GD63173@michelle.cdnetworks.co.kr>
References: <AE144701-409A-4D9F-9947-A725B0810ACA@STEVENWILLS.COM>
	<20090226003842.GB63173@michelle.cdnetworks.co.kr>
	<95AD32AC-93AE-4945-A18E-CE7099BEC3CA@stevenwills.com>
	<20090226041023.GD63173@michelle.cdnetworks.co.kr>
Message-ID: <594BAC6A-498A-4B82-A18B-EB09FEA2F322@stevenwills.com>

On Feb 25, 2009, at 11:10 PM, Pyun YongHyeon wrote:
>> I get 3 link state DOWN/UP notices when DHCP client starts. It works
>
> That's normal(Technically this is not correct behavior but it's the
> way how it was implemented in driver).

Ok. Not a huge deal, but would be nice to fix, of course.

>> for exactly 60 seconds after boot, then stops.
>
> I guess re(4) thinks it lost established link. How about unplug and
> then replug UTP cable? Would you show me "devinfo -rv | grep phy"?

rgephy0 pnpinfo oui=0x732 model=0x11 rev=0x2 at phyno=1

>>                                               Patch from earlier "fun
>> with if_re" thread didn't help,
>
> Your issue is completely different one.

Ok, good to know.

>>                                if_re.c from -CURRENT failed to build.
>
> You have to use if_re.c/if_rl.c and if_rlreg.h from CURRENT to
> build it on stable.

Ok. I can test that if you wish.

>> Reverting back to rev 1.95.2.36.2.2 fixes it.
>>
>
> Your controller looks like RTL8168D PCIe controller. ATM I have no
> idea why if_re.c 1.95.2.41 does not work. I'll let you know if I
> find a clue.

Ok. I'm happy to test any patches.

Thanks,
Steve

From pyunyh at gmail.com  Wed Feb 25 20:21:59 2009
From: pyunyh at gmail.com (Pyun YongHyeon)
Date: Wed Feb 25 20:22:05 2009
Subject: 7.1-R to RELENG_7 upgrade breaks re nic
In-Reply-To: <594BAC6A-498A-4B82-A18B-EB09FEA2F322@stevenwills.com>
References: <AE144701-409A-4D9F-9947-A725B0810ACA@STEVENWILLS.COM>
	<20090226003842.GB63173@michelle.cdnetworks.co.kr>
	<95AD32AC-93AE-4945-A18E-CE7099BEC3CA@stevenwills.com>
	<20090226041023.GD63173@michelle.cdnetworks.co.kr>
	<594BAC6A-498A-4B82-A18B-EB09FEA2F322@stevenwills.com>
Message-ID: <20090226042732.GE63173@michelle.cdnetworks.co.kr>

On Wed, Feb 25, 2009 at 11:15:38PM -0500, Steve Wills wrote:

[...]
> >I guess re(4) thinks it lost established link. How about unplug and
> >then replug UTP cable? Would you show me "devinfo -rv | grep phy"?
> 
> rgephy0 pnpinfo oui=0x732 model=0x11 rev=0x2 at phyno=1
> 

And unpluging/repluging didn't help?

> >You have to use if_re.c/if_rl.c and if_rlreg.h from CURRENT to
> >build it on stable.
> 
> Ok. I can test that if you wish.
> 

I guess re(4) in CURRENT may not help as rev 1.95.2.41 still has
issues on your controller.
From n-butcher at fusiongol.com  Wed Feb 25 20:32:33 2009
From: n-butcher at fusiongol.com (Nathan Butcher)
Date: Wed Feb 25 20:32:40 2009
Subject: ural driver stalls under FreeBSD7.1
Message-ID: <49A61894.5040804@fusiongol.com>

I have a Buffalo WLI-U2-KG54-AI wireless USB adaptor.
It has been malfunctioning for quite a while under FreeBSD7.0 and 7.1

Typically, It works for a while until eventually it stalls data
transfers completely. It always seems to do this after an unspecified
amount of time.

I know the hardware isn't at fault because the device works fine under
Linux.
From weongyo.jeong at gmail.com  Wed Feb 25 21:16:02 2009
From: weongyo.jeong at gmail.com (Weongyo Jeong)
Date: Wed Feb 25 21:16:09 2009
Subject: ural driver stalls under FreeBSD7.1
In-Reply-To: <49A61894.5040804@fusiongol.com>
References: <49A61894.5040804@fusiongol.com>
Message-ID: <20090226045340.GC70144@weongyo.cdnetworks.kr>

On Thu, Feb 26, 2009 at 01:20:36PM +0900, Nathan Butcher wrote:
> I have a Buffalo WLI-U2-KG54-AI wireless USB adaptor.
> It has been malfunctioning for quite a while under FreeBSD7.0 and 7.1
> 
> Typically, It works for a while until eventually it stalls data
> transfers completely. It always seems to do this after an unspecified
> amount of time.
> 
> I know the hardware isn't at fault because the device works fine under
> Linux.

Could you please check that `ifconfig <ifname> -bgscan' disabling the
background scan helps your symptom?

regards,
Weongyo Jeong

From fullermd at over-yonder.net  Wed Feb 25 21:22:13 2009
From: fullermd at over-yonder.net (Matthew D. Fuller)
Date: Wed Feb 25 21:22:24 2009
Subject: 7.1-R to RELENG_7 upgrade breaks re nic
In-Reply-To: <95AD32AC-93AE-4945-A18E-CE7099BEC3CA@stevenwills.com>
References: <AE144701-409A-4D9F-9947-A725B0810ACA@STEVENWILLS.COM>
	<20090226003842.GB63173@michelle.cdnetworks.co.kr>
	<95AD32AC-93AE-4945-A18E-CE7099BEC3CA@stevenwills.com>
Message-ID: <20090226050645.GS19899@over-yonder.net>

On Wed, Feb 25, 2009 at 10:47:07PM -0500 I heard the voice of
Steve Wills, and lo! it spake thus:
> 
> re0: <RealTek 8168/8168B/8168C/8168CP/8168D/8111B/8111C/8111CP PCIe  
> Gigabit Ethernet> port 0x7e00-0x7eff mem 0xfd3ff000-0xfd3fffff, 
> 0xfd3f8000-0xfd3fbfff irq 16 at device 0.0 on pci8
> re0: Chip rev. 0x28000000
> re0: MAC rev. 0x00100000

For a data point, I have

re0: <RealTek 8168/8168B/8168C/8168CP/8168D/8111B/8111C/8111CP PCIe
     Gigabit Ethernet> port 0xdc00-0xdcff mem 0xfdfff000-0xfdffffff
     irq 19 at device 0.0 on pci2
re0: turning off MSI enable bit.
re0: Chip rev. 0x38000000
re0: MAC rev. 0x00000000

on a recent 7-STABLE (if_re.c,v 1.95.2.41) which is working OK.  I
have gotten a few Tx interrupt watchdog timeouts, which I don't recall
seeing in any quantity before, but they don't seem to cause any
problems.  It was previously on a ~Dec 2007 RELENG_7 and worked fine
there (and had MSI enabled, as well).



-- 
Matthew Fuller     (MF4839)   |  fullermd@over-yonder.net
Systems/Network Administrator |  http://www.over-yonder.net/~fullermd/
           On the Internet, nobody can hear you scream.
From STEVE at stevenwills.com  Wed Feb 25 21:36:52 2009
From: STEVE at stevenwills.com (Steve Wills)
Date: Wed Feb 25 21:36:59 2009
Subject: 7.1-R to RELENG_7 upgrade breaks re nic
In-Reply-To: <20090226042732.GE63173@michelle.cdnetworks.co.kr>
References: <AE144701-409A-4D9F-9947-A725B0810ACA@STEVENWILLS.COM>
	<20090226003842.GB63173@michelle.cdnetworks.co.kr>
	<95AD32AC-93AE-4945-A18E-CE7099BEC3CA@stevenwills.com>
	<20090226041023.GD63173@michelle.cdnetworks.co.kr>
	<594BAC6A-498A-4B82-A18B-EB09FEA2F322@stevenwills.com>
	<20090226042732.GE63173@michelle.cdnetworks.co.kr>
Message-ID: <22F5A82D-290D-4B84-92AB-670EDB49AF22@stevenwills.com>

On Feb 25, 2009, at 11:27 PM, Pyun YongHyeon wrote:

> On Wed, Feb 25, 2009 at 11:15:38PM -0500, Steve Wills wrote:
>
> [...]
>>> I guess re(4) thinks it lost established link. How about unplug and
>>> then replug UTP cable? Would you show me "devinfo -rv | grep phy"?
>>
>> rgephy0 pnpinfo oui=0x732 model=0x11 rev=0x2 at phyno=1
>>
>
> And unpluging/repluging didn't help?

No, didn't help.

Steve

From smithi at nimnet.asn.au  Wed Feb 25 21:59:21 2009
From: smithi at nimnet.asn.au (Ian Smith)
Date: Wed Feb 25 21:59:29 2009
Subject: 7.1 reports serial ports disabled (but they work OK)
In-Reply-To: <200902261305.50545.doconnor@gsoft.com.au>
References: <200902261305.50545.doconnor@gsoft.com.au>
Message-ID: <20090226165128.M71460@sola.nimnet.asn.au>

On Thu, 26 Feb 2009, Daniel O'Connor wrote:
 > I have an amd64 7.1 install on a SuperMicro C2SBA+ and I see the following in 
 > dmesg..
 > 
 > 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]
 > 
 > However the ports do work fine.

The last 3 lines of each show success, despite earlier prevarication.

 > I was under the impression that this test was bogus on !i386 and had be 
 > removed but I guess I'm wrong :)

As long as they work!

cheers, Ian
From doconnor at gsoft.com.au  Wed Feb 25 22:34:47 2009
From: doconnor at gsoft.com.au (Daniel O'Connor)
Date: Wed Feb 25 22:34:54 2009
Subject: 7.1 reports serial ports disabled (but they work OK)
In-Reply-To: <20090226165128.M71460@sola.nimnet.asn.au>
References: <200902261305.50545.doconnor@gsoft.com.au>
	<20090226165128.M71460@sola.nimnet.asn.au>
Message-ID: <200902261657.43703.doconnor@gsoft.com.au>

On Thursday 26 February 2009 16:29:18 Ian Smith wrote:
>  > sio1: <16550A-compatible COM port> port 0x2f8-0x2ff irq 3 on acpi0
>  > sio1: type 16550A
>  > sio1: [FILTER]
>  >
>  > However the ports do work fine.
>
> The last 3 lines of each show success, despite earlier prevarication.

Yes, but the implication is that they might not work :)

>  > I was under the impression that this test was bogus on !i386 and had be
>  > removed but I guess I'm wrong :)
>
> As long as they work!

Yeah, makes for annoying questions by end users though.

-- 
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: 189 bytes
Desc: This is a digitally signed message part.
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20090226/3116b850/attachment.pgp
From pyunyh at gmail.com  Wed Feb 25 23:50:07 2009
From: pyunyh at gmail.com (Pyun YongHyeon)
Date: Wed Feb 25 23:50:16 2009
Subject: 7.1-R to RELENG_7 upgrade breaks re nic
In-Reply-To: <20090226050645.GS19899@over-yonder.net>
References: <AE144701-409A-4D9F-9947-A725B0810ACA@STEVENWILLS.COM>
	<20090226003842.GB63173@michelle.cdnetworks.co.kr>
	<95AD32AC-93AE-4945-A18E-CE7099BEC3CA@stevenwills.com>
	<20090226050645.GS19899@over-yonder.net>
Message-ID: <20090226075543.GF63173@michelle.cdnetworks.co.kr>

On Wed, Feb 25, 2009 at 11:06:45PM -0600, Matthew D. Fuller wrote:
> On Wed, Feb 25, 2009 at 10:47:07PM -0500 I heard the voice of
> Steve Wills, and lo! it spake thus:
> > 
> > re0: <RealTek 8168/8168B/8168C/8168CP/8168D/8111B/8111C/8111CP PCIe  
> > Gigabit Ethernet> port 0x7e00-0x7eff mem 0xfd3ff000-0xfd3fffff, 
> > 0xfd3f8000-0xfd3fbfff irq 16 at device 0.0 on pci8
> > re0: Chip rev. 0x28000000
> > re0: MAC rev. 0x00100000
> 
> For a data point, I have
> 
> re0: <RealTek 8168/8168B/8168C/8168CP/8168D/8111B/8111C/8111CP PCIe
>      Gigabit Ethernet> port 0xdc00-0xdcff mem 0xfdfff000-0xfdffffff
>      irq 19 at device 0.0 on pci2
> re0: turning off MSI enable bit.
> re0: Chip rev. 0x38000000
> re0: MAC rev. 0x00000000
> 
> on a recent 7-STABLE (if_re.c,v 1.95.2.41) which is working OK.  I
> have gotten a few Tx interrupt watchdog timeouts, which I don't recall
> seeing in any quantity before, but they don't seem to cause any

If the watchdog timeout message contains "missed Tx interrupts" you
can safely ignore them. It's not real watchdog timeouts.

> problems.  It was previously on a ~Dec 2007 RELENG_7 and worked fine
> there (and had MSI enabled, as well).
> 

Try re(4) in HEAD. You may not see watchdog timeouts anymore.
From Trond.Endrestol at fagskolen.gjovik.no  Thu Feb 26 00:43:02 2009
From: Trond.Endrestol at fagskolen.gjovik.no (=?ISO-8859-1?Q?Trond_Endrest=F8l?=)
Date: Thu Feb 26 00:43:09 2009
Subject: What startup script is supposed to handle ipv6_defaultrouter="..."?
Message-ID: <20090226093219.R21334@ramstind.fig.ol.no>

On a system running 7.1-STABLE as of early February, cvsup'd with 
tag=RELENG_7 just prior to recompiling the system, setting 
ipv6_defaultrouter="..." in /etc/rc.conf seems to have no effect.
I'm forced to set the IPv6 gateway using commands outside the regular 
startup scripts.

The command

  grep ipv6_defaultrouter /etc/rc.d/*

doesn't give anything useful, either.

I guess /etc/rc.d/network_ipv6 is missing the required code.
Here's the revision string from my /etc/rc.d/network_ipv6:

# $FreeBSD: src/etc/rc.d/network_ipv6,v 1.37 2004/10/07 13:55:26 mtm Exp $

Is this the correct revision number for tag=RELENG_7?

-- 
----------------------------------------------------------------------
Trond Endrest?l                  | Trond.Endrestol@fagskolen.gjovik.no
ACM, NAS, NUUG, SAGE, USENIX     |      FreeBSD 6.2-STABLE & Pine 4.64
From bzeeb-lists at lists.zabbadoz.net  Thu Feb 26 01:40:08 2009
From: bzeeb-lists at lists.zabbadoz.net (Bjoern A. Zeeb)
Date: Thu Feb 26 01:40:16 2009
Subject: What startup script is supposed to handle
	ipv6_defaultrouter="..."?
In-Reply-To: <20090226093219.R21334@ramstind.fig.ol.no>
References: <20090226093219.R21334@ramstind.fig.ol.no>
Message-ID: <20090226093623.J53478@maildrop.int.zabbadoz.net>

On Thu, 26 Feb 2009, Trond Endrest?l wrote:

> On a system running 7.1-STABLE as of early February, cvsup'd with
> tag=RELENG_7 just prior to recompiling the system, setting
> ipv6_defaultrouter="..." in /etc/rc.conf seems to have no effect.
> I'm forced to set the IPv6 gateway using commands outside the regular
> startup scripts.
>
> The command
>
>  grep ipv6_defaultrouter /etc/rc.d/*
>
> doesn't give anything useful, either.
>
> I guess /etc/rc.d/network_ipv6 is missing the required code.

I guess it's in /etc/network.subr


Did you se ipv6_enable="YES" in rc.conf as well?



/bz


-- 
Bjoern A. Zeeb                      The greatest risk is not taking one.
From Trond.Endrestol at fagskolen.gjovik.no  Thu Feb 26 02:01:44 2009
From: Trond.Endrestol at fagskolen.gjovik.no (=?ISO-8859-1?Q?Trond_Endrest=F8l?=)
Date: Thu Feb 26 02:01:51 2009
Subject: What startup script is supposed to handle
	ipv6_defaultrouter="..."?
In-Reply-To: <20090226093219.R21334@ramstind.fig.ol.no>
References: <20090226093219.R21334@ramstind.fig.ol.no>
Message-ID: <20090226105039.L45052@ramstind.fig.ol.no>

On Thu, 26 Feb 2009 09:42+0100, Trond Endrest?l wrote:

> On a system running 7.1-STABLE as of early February, cvsup'd with 
> tag=RELENG_7 just prior to recompiling the system, setting 
> ipv6_defaultrouter="..." in /etc/rc.conf seems to have no effect.
> I'm forced to set the IPv6 gateway using commands outside the regular 
> startup scripts.

For the record, here are the IPv6 related variables found in this
particular system's /etc/rc.conf file:

ipv6_enable="YES"
ipv6_defaultrouter="2001:700:XXXX:YYYY::1"
ipv6_ifconfig_em0="2001:700:XXXX:YYYY::24 prefixlen 64"

If I leave out the static address assignment on em0 and the static 
router address, the system gets both an autoconfigurated IPv6 address 
as well as receiving the router's link local IPv6 address and the 
system will use that LL address as the default router.

I'm merely interested in giving em0 a static IPv6 address, and if 
possible leave everything else to be determined by the router's 
advertisement.

Do I need to fiddle with one or more sysctl variables?

-- 
----------------------------------------------------------------------
Trond Endrest?l                  | Trond.Endrestol@fagskolen.gjovik.no
ACM, NAS, NUUG, SAGE, USENIX     |      FreeBSD 6.2-STABLE & Pine 4.64
From Trond.Endrestol at fagskolen.gjovik.no  Thu Feb 26 04:19:25 2009
From: Trond.Endrestol at fagskolen.gjovik.no (=?ISO-8859-1?Q?Trond_Endrest=F8l?=)
Date: Thu Feb 26 04:19:32 2009
Subject: What startup script is supposed to handle
	ipv6_defaultrouter="..."?
In-Reply-To: <20090226105039.L45052@ramstind.fig.ol.no>
References: <20090226093219.R21334@ramstind.fig.ol.no>
	<20090226105039.L45052@ramstind.fig.ol.no>
Message-ID: <20090226131701.F45052@ramstind.fig.ol.no>

Sorry about the noise.

Maybe I wasn't too patient, but I will swear that netstat -rnf inet6 
showed no default route even when it was supposed to. And yes, I did 
reboot the system to verify my settings.

Again, my bad.

-- 
----------------------------------------------------------------------
Trond Endrest?l                  | Trond.Endrestol@fagskolen.gjovik.no
ACM, NAS, NUUG, SAGE, USENIX     |      FreeBSD 6.2-STABLE & Pine 4.64
From wolfgang at lyxys.ka.sub.org  Thu Feb 26 06:18:01 2009
From: wolfgang at lyxys.ka.sub.org (Wolfgang Zenker)
Date: Thu Feb 26 06:18:12 2009
Subject: What startup script is supposed to handle
	ipv6_defaultrouter="..."?
In-Reply-To: <20090226131701.F45052@ramstind.fig.ol.no>
References: <20090226093219.R21334@ramstind.fig.ol.no>
	<20090226105039.L45052@ramstind.fig.ol.no>
	<20090226131701.F45052@ramstind.fig.ol.no>
Message-ID: <20090226135143.GA38688@lyxys.ka.sub.org>

Hi,

* Trond Endrest?l <Trond.Endrestol@fagskolen.gjovik.no> [090226 13:19]:
> Sorry about the noise.

> Maybe I wasn't too patient, but I will swear that netstat -rnf inet6 
> showed no default route even when it was supposed to. And yes, I did 
> reboot the system to verify my settings.

> Again, my bad.

I have the problem sometimes that the system tries to get IPv6 router
advertisments before the interface is up. In this case it doesn't retry,
at least not within the time frame I was patient enough to wait.
In this case I usually call rtsol by hand to get the parameters.

Wolfgang
From jhb at freebsd.org  Thu Feb 26 07:25:54 2009
From: jhb at freebsd.org (John Baldwin)
Date: Thu Feb 26 07:26:02 2009
Subject: 7.1 hangs in cache_lookup mutex?
In-Reply-To: <49A55D78.1070604@palisadesys.com>
References: <49A46AB4.3080003@palisadesys.com>
	<200902250915.57562.jhb@freebsd.org>
	<49A55D78.1070604@palisadesys.com>
Message-ID: <200902261012.24325.jhb@freebsd.org>

On Wednesday 25 February 2009 10:02:16 am Guy Helmer wrote:
> John Baldwin wrote:
> > On Tuesday 24 February 2009 4:46:28 pm Guy Helmer wrote:
> >   
> >> I think I may have found a clue regarding some of the hangs I'm seeing 
> >> on FreeBSD 7.1.
> >> I have a program (kvoop), compiled under FreeBSD 6 and using 
> >> compatibility libraries under FreeBSD 7, that seems to be consistently 
> >> involved during these hangs.  This time, I noticed that many processes 
> >> are stopped, waiting on the ufs lock.  I can't tell for certain, but I 
> >> assume this kvoop process 33203 is blocking the other processes.  The 
> >> kvoop process looks to me like it is waiting for a mutex, but nothing 
> >> shows up being deadlocked.  Am I on the right track?  Is there something 
> >> else I should be looking for?
> >>
> >> (kgdb) proc 33203
> >> [Switching to thread 129 (Thread 100241)]#0  sched_switch (
> >>     td=0xffffff0019109a50, newtd=0x0, flags=1)
> >>     at ../../../kern/sched_ule.c:1944
> >> 1944                    cpuid = PCPU_GET(cpuid);
> >> (kgdb) where
> >> #0  sched_switch (td=0xffffff0019109a50, newtd=0x0, flags=1)
> >>     at ../../../kern/sched_ule.c:1944
> >> #1  0xffffffff803a573b in mi_switch (flags=1, newtd=0x0)
> >>     at ../../../kern/kern_synch.c:440
> >> #2  0xffffffff803d1214 in turnstile_wait (ts=Variable "ts" is not available.
> >> )
> >>     at ../../../kern/subr_turnstile.c:748
> >> #3  0xffffffff80392db0 in _mtx_lock_sleep (m=0xffffffff8083c220,
> >>     tid=18446742974618442320, opts=Variable "opts" is not available.
> >> ) at ../../../kern/kern_mutex.c:420
> >> #4  0xffffffff80392ea6 in _mtx_lock_flags (m=0xffffffff8083c220, opts=0,
> >>     file=0xffffffff805bd438 "../../../kern/vfs_cache.c", line=327)
> >>     at ../../../kern/kern_mutex.c:186
> >> #5  0xffffffff80403bc6 in cache_lookup (dvp=0xffffff00013e0dc8,
> >>     vpp=0xffffffffa2d93a18, cnp=0xffffffffa2d93a40)
> >>     at ../../../kern/vfs_cache.c:327
> >> #6  0xffffffff80404093 in vfs_cache_lookup (ap=Variable "ap" is not 
> >> available.
> >> )
> >>     at ../../../kern/vfs_cache.c:674
> >> #7  0xffffffff805628a0 in VOP_LOOKUP_APV (vop=0xffffffff8076e440,
> >>     a=0xffffffffa2d936b0) at vnode_if.c:99
> >> #8  0xffffffff80409afd in lookup (ndp=0xffffffffa2d939f0) at vnode_if.h:57
> >> #9  0xffffffff8040a824 in namei (ndp=0xffffffffa2d939f0)
> >>     at ../../../kern/vfs_lookup.c:219
> >> #10 0xffffffff8041dc4f in vn_open_cred (ndp=0xffffffffa2d939f0,
> >>     flagp=0xffffffffa2d9393c, cmode=0, cred=0xffffff0001588600,
> >>     fp=0xffffff0001964200) at ../../../kern/vfs_vnops.c:188
> >> #11 0xffffffff8041ccc7 in kern_open (td=0xffffff0019109a50,
> >>     path=0xffffac30 <Address 0xffffac30 out of bounds>, pathseg=Variable 
> >> "pathseg" is not available.
> >> )
> >>     at ../../../kern/vfs_syscalls.c:1032
> >> #12 0xffffffff80544660 in ia32_syscall (frame=0xffffffffa2d93c80)
> >>     at ../../../amd64/ia32/ia32_syscall.c:182
> >> #13 0xffffffff805014d0 in Xint0x80_syscall () at ia32_exception.S:65
> >> #14 0x0000000028284037 in ?? ()
> >>
> >> (kgdb) frame 4
> >> #4  0xffffffff80392ea6 in _mtx_lock_flags (m=0xffffffff8083c220, opts=0,
> >>     file=0xffffffff805bd438 "../../../kern/vfs_cache.c", line=327)
> >>     at ../../../kern/kern_mutex.c:186
> >> 186             _get_sleep_lock(m, curthread, opts, file, line);
> >> (kgdb) list
> >> 181                 ("mtx_lock() of spin mutex %s @ %s:%d", 
> >> m->lock_object.lo_name,
> >> 182                 file, line));
> >> 183             WITNESS_CHECKORDER(&m->lock_object, opts | LOP_NEWORDER 
> >> | LOP_EXCLUSIVE,
> >> 184                 file, line);
> >> 185
> >> 186             _get_sleep_lock(m, curthread, opts, file, line);
> >> 187             LOCK_LOG_LOCK("LOCK", &m->lock_object, opts, 
> >> m->mtx_recurse, file,
> >> 188                 line);
> >> 189             WITNESS_LOCK(&m->lock_object, opts | LOP_EXCLUSIVE, 
> >> file, line);
> >> 190             curthread->td_locks++;
> >>
> >> (kgdb) print *m
> >> $2 = {lock_object = {lo_name = 0xffffffff805bd5d2 "Name Cache",
> >>     lo_type = 0xffffffff805bd5d2 "Name Cache", lo_flags = 16973824,
> >>     lo_witness_data = {lod_list = {stqe_next = 0xffffffff807cd600},
> >>       lod_witness = 0xffffffff807cd600}}, mtx_lock = 4, mtx_recurse = 0}
> >>     
> >
> > Is this from a coredump or while the system is live?  mtx_lock = 4 indicates 
> > the mutex is unlocked, so there shouldn't be any threads waiting on it.
> >
> >   
> That was from running kgdb on a vmcore file.  Would the state of the 
> mutex be different than if I was running kgdb on a live kernel?

Well, if it was live perhaps the thread wasn't hung but was changing states
while you were watching it.  However, that is not true in a coredump.  This is
a very disturbing bug as it means something is broken in the mutex implementation
itself.  Have you reproduced this on multiple machines?

-- 
John Baldwin
From avg at icyb.net.ua  Thu Feb 26 08:14:13 2009
From: avg at icyb.net.ua (Andriy Gapon)
Date: Thu Feb 26 08:14:20 2009
Subject: qemu+aio vs C2
Message-ID: <49A6BFD1.6090601@icyb.net.ua>


I see something unusual and surprising for me: if I kldload aio for qemu's sake
and then actually start qemu, I see that share of C2 in cx_usage is constantly
dropping and then finally there is "too many short sleeps, backing off to C1".

This is on i386 with stable/7 as of r188116.

I am out of ideas.

-- 
Andriy Gapon
From onemda at gmail.com  Thu Feb 26 08:27:26 2009
From: onemda at gmail.com (Paul B. Mahol)
Date: Thu Feb 26 08:27:33 2009
Subject: qemu+aio vs C2
In-Reply-To: <49A6BFD1.6090601@icyb.net.ua>
References: <49A6BFD1.6090601@icyb.net.ua>
Message-ID: <3a142e750902260827w722f110eve23a7bdb07cfbe42@mail.gmail.com>

On 2/26/09, Andriy Gapon <avg@icyb.net.ua> wrote:
>
> I see something unusual and surprising for me: if I kldload aio for qemu's
> sake
> and then actually start qemu, I see that share of C2 in cx_usage is
> constantly
> dropping and then finally there is "too many short sleeps, backing off to
> C1".
>
> This is on i386 with stable/7 as of r188116.
>
> I am out of ideas.

And qemu guest is?

Perhaps you should try changing guest kern.hz sysctl setting.
I dont think related comitt got MFC-ed to STABLE.

-- 
Paul
From avg at icyb.net.ua  Thu Feb 26 08:31:43 2009
From: avg at icyb.net.ua (Andriy Gapon)
Date: Thu Feb 26 08:31:50 2009
Subject: qemu+aio vs C2
In-Reply-To: <3a142e750902260827w722f110eve23a7bdb07cfbe42@mail.gmail.com>
References: <49A6BFD1.6090601@icyb.net.ua>
	<3a142e750902260827w722f110eve23a7bdb07cfbe42@mail.gmail.com>
Message-ID: <49A6C3EA.6060605@icyb.net.ua>

on 26/02/2009 18:27 Paul B. Mahol said the following:
> On 2/26/09, Andriy Gapon <avg@icyb.net.ua> wrote:
>> I see something unusual and surprising for me: if I kldload aio for qemu's
>> sake
>> and then actually start qemu, I see that share of C2 in cx_usage is
>> constantly
>> dropping and then finally there is "too many short sleeps, backing off to
>> C1".
>>
>> This is on i386 with stable/7 as of r188116.
>>
>> I am out of ideas.
> 
> And qemu guest is?
> 
> Perhaps you should try changing guest kern.hz sysctl setting.
> I dont think related comitt got MFC-ed to STABLE.
> 

For what I've been doing the guest was our boot code and loader. Nothing beyond that.
And, pardon me, how guest software could affect host's hardware in this way?
As i understand only a hardware even of some sort could interrupt C2.

-- 
Andriy Gapon
From ross.penner at gmail.com  Thu Feb 26 09:44:23 2009
From: ross.penner at gmail.com (Ross Penner)
Date: Thu Feb 26 09:44:31 2009
Subject: powerd causing crash on Mini-ITX EN1200
Message-ID: <f80199c40902260944q430b7faavd9fc7891c6ecb7b0@mail.gmail.com>

Hi,

When I enable powerd, it is only but a matter of time before my
machine will lock up completely. I've had this problem since I've
migrated to FreeBSD 7 from 6. FreeBSD 6 never seemed to have any
problems. I doesn't seem to create a dump so I've had no luck on that
end. I'm quite perplexed on how to proceed to help get this problem
documented so it can be fixed.

#uname -a
FreeBSD rosbox.dyndns.org 7.1-STABLE FreeBSD 7.1-STABLE #0: Thu Feb 26
00:38:44 PST 2009
ross@rosbox.dyndns.org:/usr/obj/usr/src/sys/MYKERNEL7  i386

Is there anything else I con provide that would be of assistance?

Thank you,

Ross Penner
From tinderbox at freebsd.org  Thu Feb 26 09:55:08 2009
From: tinderbox at freebsd.org (FreeBSD Tinderbox)
Date: Thu Feb 26 09:55:21 2009
Subject: [releng_7 tinderbox] failure on powerpc/powerpc
Message-ID: <20090226175504.E7E431B5060@freebsd-stable.sentex.ca>

TB --- 2009-02-26 16:35:32 - tinderbox 2.6 running on freebsd-stable.sentex.ca
TB --- 2009-02-26 16:35:32 - starting RELENG_7 tinderbox run for powerpc/powerpc
TB --- 2009-02-26 16:35:32 - cleaning the object tree
TB --- 2009-02-26 16:35:56 - cvsupping the source tree
TB --- 2009-02-26 16:35:56 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/RELENG_7/powerpc/powerpc/supfile
TB --- 2009-02-26 16:36:05 - building world
TB --- 2009-02-26 16:36:05 - MAKEOBJDIRPREFIX=/obj
TB --- 2009-02-26 16:36:05 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2009-02-26 16:36:05 - TARGET=powerpc
TB --- 2009-02-26 16:36:05 - TARGET_ARCH=powerpc
TB --- 2009-02-26 16:36:05 - TZ=UTC
TB --- 2009-02-26 16:36:05 - __MAKE_CONF=/dev/null
TB --- 2009-02-26 16:36:05 - cd /src
TB --- 2009-02-26 16:36:05 - /usr/bin/make -B buildworld
>>> World build started on Thu Feb 26 16:36:06 UTC 2009
>>> Rebuilding the temporary build tree
>>> stage 1.1: legacy release compatibility shims
>>> stage 1.2: bootstrap tools
>>> stage 2.1: cleaning up the object tree
>>> stage 2.2: rebuilding the object tree
>>> stage 2.3: build tools
>>> stage 3: cross tools
>>> stage 4.1: building includes
>>> stage 4.2: building libraries
>>> stage 4.3: make dependencies
>>> stage 4.4: building everything
>>> World build completed on Thu Feb 26 17:42:38 UTC 2009
TB --- 2009-02-26 17:42:38 - generating LINT kernel config
TB --- 2009-02-26 17:42:38 - cd /src/sys/powerpc/conf
TB --- 2009-02-26 17:42:38 - /usr/bin/make -B LINT
TB --- 2009-02-26 17:42:38 - building LINT kernel
TB --- 2009-02-26 17:42:38 - MAKEOBJDIRPREFIX=/obj
TB --- 2009-02-26 17:42:38 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2009-02-26 17:42:38 - TARGET=powerpc
TB --- 2009-02-26 17:42:38 - TARGET_ARCH=powerpc
TB --- 2009-02-26 17:42:38 - TZ=UTC
TB --- 2009-02-26 17:42:38 - __MAKE_CONF=/dev/null
TB --- 2009-02-26 17:42:38 - cd /src
TB --- 2009-02-26 17:42:38 - /usr/bin/make -B buildkernel KERNCONF=LINT
>>> Kernel build for LINT started on Thu Feb 26 17:42:38 UTC 2009
>>> stage 1: configuring the kernel
>>> stage 2.1: cleaning up the object tree
>>> stage 2.2: rebuilding the object tree
>>> stage 2.3: build tools
>>> stage 3.1: making dependencies
>>> stage 3.2: building everything
[...]
:> hack.c
cc -shared -nostdlib hack.c -o hack.So
rm -f hack.c
MAKE=/usr/bin/make sh /src/sys/conf/newvers.sh LINT
cc -c -O2 -pipe -fno-strict-aliasing  -std=c99  -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes  -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual  -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc  -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -fno-omit-frame-pointer -msoft-float -ffreestanding -Werror  vers.c
linking kernel
vm_map.o(.text+0x3938): In function `vm_map_find':
: undefined reference to `pmap_align_superpage'
*** Error code 1

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

Stop in /src.
*** Error code 1

Stop in /src.
TB --- 2009-02-26 17:55:04 - WARNING: /usr/bin/make returned exit code  1 
TB --- 2009-02-26 17:55:04 - ERROR: failed to build lint kernel
TB --- 2009-02-26 17:55:04 - 3990.27 user 374.40 system 4771.90 real


http://tinderbox.des.no/tinderbox-releng_7-RELENG_7-powerpc-powerpc.full
From bengta at sics.se  Thu Feb 26 10:43:49 2009
From: bengta at sics.se (Bengt Ahlgren)
Date: Thu Feb 26 10:43:56 2009
Subject: ural driver stalls under FreeBSD7.1
In-Reply-To: <20090226045340.GC70144@weongyo.cdnetworks.kr> (Weongyo Jeong's
	message of "Thu\, 26 Feb 2009 13\:53\:40 +0900")
References: <49A61894.5040804@fusiongol.com>
	<20090226045340.GC70144@weongyo.cdnetworks.kr>
Message-ID: <uh7hc2h13a7.fsf@P142.sics.se>

Weongyo Jeong <weongyo.jeong@gmail.com> writes:

> On Thu, Feb 26, 2009 at 01:20:36PM +0900, Nathan Butcher wrote:
>> I have a Buffalo WLI-U2-KG54-AI wireless USB adaptor.
>> It has been malfunctioning for quite a while under FreeBSD7.0 and 7.1
>> 
>> Typically, It works for a while until eventually it stalls data
>> transfers completely. It always seems to do this after an unspecified
>> amount of time.
>> 
>> I know the hardware isn't at fault because the device works fine under
>> Linux.
>
> Could you please check that `ifconfig <ifname> -bgscan' disabling the
> background scan helps your symptom?

The above sounds like the same problem as this:

http://lists.freebsd.org/pipermail/freebsd-mobile/2009-February/011376.html
http://lists.freebsd.org/pipermail/freebsd-mobile/2009-February/011343.html

The problem is in the background scanning logic in sys/net80211.

Bengt
From tinderbox at freebsd.org  Thu Feb 26 10:54:53 2009
From: tinderbox at freebsd.org (FreeBSD Tinderbox)
Date: Thu Feb 26 10:55:13 2009
Subject: [releng_7 tinderbox] failure on sparc64/sparc64
Message-ID: <20090226185449.0370D1B5060@freebsd-stable.sentex.ca>

TB --- 2009-02-26 17:42:23 - tinderbox 2.6 running on freebsd-stable.sentex.ca
TB --- 2009-02-26 17:42:23 - starting RELENG_7 tinderbox run for sparc64/sparc64
TB --- 2009-02-26 17:42:23 - cleaning the object tree
TB --- 2009-02-26 17:42:41 - cvsupping the source tree
TB --- 2009-02-26 17:42:41 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/RELENG_7/sparc64/sparc64/supfile
TB --- 2009-02-26 17:42:51 - building world
TB --- 2009-02-26 17:42:51 - MAKEOBJDIRPREFIX=/obj
TB --- 2009-02-26 17:42:51 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2009-02-26 17:42:51 - TARGET=sparc64
TB --- 2009-02-26 17:42:51 - TARGET_ARCH=sparc64
TB --- 2009-02-26 17:42:51 - TZ=UTC
TB --- 2009-02-26 17:42:51 - __MAKE_CONF=/dev/null
TB --- 2009-02-26 17:42:51 - cd /src
TB --- 2009-02-26 17:42:51 - /usr/bin/make -B buildworld
>>> World build started on Thu Feb 26 17:42:53 UTC 2009
>>> Rebuilding the temporary build tree
>>> stage 1.1: legacy release compatibility shims
>>> stage 1.2: bootstrap tools
>>> stage 2.1: cleaning up the object tree
>>> stage 2.2: rebuilding the object tree
>>> stage 2.3: build tools
>>> stage 3: cross tools
>>> stage 4.1: building includes
>>> stage 4.2: building libraries
>>> stage 4.3: make dependencies
>>> stage 4.4: building everything
>>> World build completed on Thu Feb 26 18:42:22 UTC 2009
TB --- 2009-02-26 18:42:22 - generating LINT kernel config
TB --- 2009-02-26 18:42:22 - cd /src/sys/sparc64/conf
TB --- 2009-02-26 18:42:22 - /usr/bin/make -B LINT
TB --- 2009-02-26 18:42:23 - building LINT kernel
TB --- 2009-02-26 18:42:23 - MAKEOBJDIRPREFIX=/obj
TB --- 2009-02-26 18:42:23 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2009-02-26 18:42:23 - TARGET=sparc64
TB --- 2009-02-26 18:42:23 - TARGET_ARCH=sparc64
TB --- 2009-02-26 18:42:23 - TZ=UTC
TB --- 2009-02-26 18:42:23 - __MAKE_CONF=/dev/null
TB --- 2009-02-26 18:42:23 - cd /src
TB --- 2009-02-26 18:42:23 - /usr/bin/make -B buildkernel KERNCONF=LINT
>>> Kernel build for LINT started on Thu Feb 26 18:42:23 UTC 2009
>>> stage 1: configuring the kernel
>>> stage 2.1: cleaning up the object tree
>>> stage 2.2: rebuilding the object tree
>>> stage 2.3: build tools
>>> stage 3.1: making dependencies
>>> stage 3.2: building everything
[...]
:> hack.c
cc -shared -nostdlib hack.c -o hack.So
rm -f hack.c
MAKE=/usr/bin/make sh /src/sys/conf/newvers.sh LINT
cc -c -O2 -pipe -fno-strict-aliasing  -std=c99  -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes  -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual  -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc  -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -Werror  vers.c
linking kernel
vm_map.o(.text+0x3324): In function `vm_map_find':
: undefined reference to `pmap_align_superpage'
*** Error code 1

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

Stop in /src.
*** Error code 1

Stop in /src.
TB --- 2009-02-26 18:54:48 - WARNING: /usr/bin/make returned exit code  1 
TB --- 2009-02-26 18:54:48 - ERROR: failed to build lint kernel
TB --- 2009-02-26 18:54:48 - 3800.23 user 368.36 system 4345.76 real


http://tinderbox.des.no/tinderbox-releng_7-RELENG_7-sparc64-sparc64.full
From admin at stardothosting.com  Thu Feb 26 12:07:57 2009
From: admin at stardothosting.com (SDH Support)
Date: Thu Feb 26 12:08:04 2009
Subject: qemu+aio vs C2
In-Reply-To: <49A6BFD1.6090601@icyb.net.ua>
References: <49A6BFD1.6090601@icyb.net.ua>
Message-ID: <000601c9984d$e12b12d0$a3813870$@com>

> I see something unusual and surprising for me: if I kldload aio for
> qemu's sake
> and then actually start qemu, I see that share of C2 in cx_usage is
> constantly
> dropping and then finally there is "too many short sleeps, backing off
> to C1".
> 
> This is on i386 with stable/7 as of r188116.



I've been running qemu w/ stable-7 with no problems. Could you paste the actual error messages as well as a full DMESG?


# uname -a
FreeBSD kkutzko 7.1-PRERELEASE FreeBSD 7.1-PRERELEASE #0: Fri Oct 10 13:10:49 EDT 2008     server.local:/usr/obj/usr/src/sys/KK  i386
#



---
Kevin 
Systems Administrator
http://www.stardothosting.com/linux-vps-hosting
http://wiki.stardothosting.com 




From jhb at freebsd.org  Thu Feb 26 12:36:30 2009
From: jhb at freebsd.org (John Baldwin)
Date: Thu Feb 26 12:36:42 2009
Subject: [releng_7 tinde