Re: Reminder: FCP-101: pending removal of some 10/100 Ethernet drivers

[Brooks Davis]

On Fri, Feb 01, 2019 at 04:00:50AM -0800, Rodney W. Grimes wrote:
> > On Thu, Jan 31, 2019 at 11:43:44PM +, Brooks Davis wrote:
> > > We are currently planning to remove the following less-popular 10/100
> > > Ethernet drivers in the March/April timeframe:
> > > 
> > > ae, bm, cs, de, dme, ed, ep, ex, fe, pcn, sf, sn, tl, tx, txp, vx, wb, xe
> > > 
> > > All of these drivers generate warnings in FreeBSD 12 and to the best of
> > > my knowledge, none have cleared the bar specified in the FCP[0]:
> > > 
> > > https://github.com/freebsd/fcp/blob/master/fcp-0101.md
> > 
> > Hi,
> > 
> > The above document states that the support lifetime for FreeBSD 12 is 2023.
> > 
> > The expected EOL (but not decided) for 12 is June 30, 2020 however, 
> > according to
> 
> Can someone please go revise where ever this is posted based on the 18 month
> minima that was set to simply state "undetermined", people are reading too 
> much
> into the date posted there.
> 
> > https://www.freebsd.org/security/security.html#sup
> > 
> > So, hardware in some of my machines will only be supported until sometime 
> > next
> > year.
> 
> Brooks,
>   Given that at the time FCP-101 was written part of it was
> based on the assumption of a 5 year life time for 12.0.  Since that
> assumption is now invalid, and worse, unknown, I would ask that until
> a decision about the life of 12.0 is made we back off on the FCP-101 process
> and not do anything about removing drivers until that support
> model adjustment is finalized and we can evaluate the impact on
> FCP-101's assumption.

Per the text of my email and the schedule in the FCP, no deletions
will occur until after the support lifetime of 12 is scheduled to be
resolved.  Should that date slip then any deletions would also slip.
Should the lifetime of 12 be drastically reduced relative to the
original lifetime, then yes we should revisit our list and schedule.

A majority of these devices have *zero* confirmed users so we should
likely delete them before 13 no matter what happens to 12-STABLE's
lifetime.

No further action beyond data collection is scheduled on this FCP until
after the end of the quarter.

-- Brooks

P.S. All of this hardware will be supported until at least September 30,
2021 on FreeBSD 11-STABLE.


signature.asc
Description: PGP signature

Reminder: FCP-101: pending removal of some 10/100 Ethernet drivers

[Brooks Davis]

We are currently planning to remove the following less-popular 10/100
Ethernet drivers in the March/April timeframe:

ae, bm, cs, de, dme, ed, ep, ex, fe, pcn, sf, sn, tl, tx, txp, vx, wb, xe

All of these drivers generate warnings in FreeBSD 12 and to the best of
my knowledge, none have cleared the bar specified in the FCP[0]:

https://github.com/freebsd/fcp/blob/master/fcp-0101.md

The easiest way for you to provide data to help our decision making is
to upload dmesgs to https://dmesgd.nycbug.org/.  If you have a
installations of FreeBSD 12 that are dependent on one of these NICs and
you can not report them this way, please feel free to contact me
directly.

-- Brooks

[0] I've received a couple reports of ae(4) devices, but still not 5 of
them.


signature.asc
Description: PGP signature

Re: Address Collision using i386 4G/4G Memory Split

[Brooks Davis]

On Mon, Dec 17, 2018 at 03:58:05PM -0500, Kurt Lidl wrote:
> Alexander Lochmann writes:
> > According to git commit e3089a (https://reviews.freebsd.org/D1463)
> > FreeBSD 12.0 i386 uses separate address spaces for kernel and user
> > space. So basically two memory areas, one in each space, can have the
> > same address.
> > Is this possible with FreeBSD 12.0? Is this likely to happen?
> 
> If the userspace program and the kernel address happen to overlap, the 
> system will deal with it.  There's not anything to worry about.  As to
> whether or not it's likely to happen -- I'm not sure about that.  I
> expect the default stack and heap space locations for a fresh process
> have changed due to this change, but it should not matter.

4/4 does potentially alter the failure modes of buggy code that tries to
read directly from userspace addresses.  For example, correct calls to
the sysctls fixed in r342125 may panic prior to the fix because the
addresses in question aren't mapped in kernel space.  They might also
fail or behave bizarrely if the page is mapped and the value from the
kernel page is used.

-- Brooks


signature.asc
Description: PGP signature

Re: SCSI and dmesg

[Brooks Davis]

On Thu, Nov 29, 2018 at 11:01:01AM -0700, Alan Somers wrote:
> On Thu, Nov 29, 2018 at 10:49 AM Warner Losh  wrote:
> 
> >
> >
> > On Thu, Nov 29, 2018 at 8:09 AM Alan Somers  wrote:
> >
> >> On Mon, Nov 26, 2018 at 3:57 PM Warner Losh  wrote:
> >>
> >>> On Mon, Nov 26, 2018 at 3:32 PM Maxim Sobolev 
> >>> wrote:
> >>>
> >>> > Somebody needs to make collection/submission automatic and make a port
> >>> out
> >>> > of it, so that it's as easy as pkg install dmesg_survey &&
> >>> > dmesg_survey_enabled="YES" in the /etc/rc.conf. JIMHO. I'd gladly make
> >>> it a
> >>> > default on all dev boxes within our organization. Might also make a
> >>> nice
> >>> > SoC project idea.
> >>> >
> >>>
> >>> It's barely a weekend hack, since with the curl 1 liner 95% of what you
> >>> want is there.
> >>>
> >>> This service isn't suitable, though, to have it in rc.conf, I don't
> >>> think,
> >>> unless it's updated only when there's a material change...
> >>>
> >>> And I'd rather we get more nuanced data than dmesg can provide if we were
> >>> to do the data collection. The admonition to submit to this site was one
> >>> of
> >>> expedience...
> >>>
> >>> Warner
> >>>
> >>
> >> Sounds like somebody needs to adopt sysutils/bsdstats.  It's a great
> >> start, but it needs some TLC.
> >>
> >
> > Except there's no available data from it. And it's not a great start, but
> > a terrible one. It gathers the wrong things.
> >
> > Warner
> >
> 
> What do you mean "no available data"?  Are you saying that you'd prefer
> direct access to the server rather than access through the web UI?  I'm
> sure Scrappy would allow that.  He's implied that he'd like some help with
> the server.  What I like about bsdstats is that it's much more structured
> than your dmesg service.  Instead of a big long string, it gathers
> structured info with sysctl, pciconf, and pkg.  Plus, it already has a
> port, it's integrated into periodic(8), and it has a website.  If it omits
> some information that you would like to see, then you should enhance it;
> not replace it.

The data isn't available through the UI because it's broken.  Try
drilling down to find all the NIC types for example and you'll get:

ERROR !!

an e-mail has been sent to the staff
we are sorry for this problem

I've reported this multiple time and at least once Scrappy claimed it
was fixed, but it wasn't.

-- Brooks


signature.asc
Description: PGP signature

Re: [FreeBSD-Announce] FreeBSD Errata Notice FreeBSD-EN-18:15.loader

[Brooks Davis]

On Wed, Nov 28, 2018 at 04:32:54AM +0700, Eugene Grosbein wrote:
> 28.11.2018 4:22, FreeBSD Errata Notices wrote:
> 
> > Affects:All supported versions of FreeBSD.
> > Corrected:  2018-10-24 23:17:17 UTC (stable/11, 11.2-STABLE)
> > 2018-11-27 19:45:25 UTC (releng/11.2, 11.2-RELEASE-p5)
> 
> That's strange. Is there only single supported version or others were left 
> uncorrected
> or "Affects:" line is wrong?

There is only only supported version of FreeBSD due to the expiration of
10.4 at the end of last month.

-- Brooks


signature.asc
Description: PGP signature

Re: "sockstat: struct xinpgen size mismatch" in 11.2-p4 jail on 12-STABLE host

[Brooks Davis]

On Sat, Nov 24, 2018 at 09:17:23AM -0500, Paul Mather wrote:
> I updated a system yesterday to the latest 12-STABLE as part of the upcoming 
> 12-RELEASE cycle.  I've installed several BETA and at least one RC of 12 
> since updating from 11-STABLE as part of the 12 cycle and have had no 
> problems up to now.  Currently, I am at FreeBSD 12.0-PRERELEASE r340834 
> GENERIC amd64.
> 
> Since the most recent update, I have been getting this error when I invoke 
> "sockstat" in any of the jails running on the system:
> 
>   sockstat: struct xinpgen size mismatch
> 
> The jails are managed via iocage and all are running 11.2-RELEASE-p4, which 
> is the most up-to-date version of 11.2-RELEASE.
> 
> Has anyone encountered this error?  Unfortunately, it means that it breaks 
> Salt, which is what I use to help manage the jails.  Sockstat works fine on 
> the host, just not in the jails.
> 
> I am using a GENERIC kernel which includes "options COMPAT_FREEBSD11".  I 
> assumed this would allow FreeBSD 11 binaries to work on a FreeBSD 12 kernel, 
> which it has done up to now.

We broke this system management ABI months ago.  I'm not sure why you're
only bumping into this now.

We don't provide backward compatibility for these interfaces.  To make
this configuration work, I'd suggest replacing the sockstat in
the jail with a statically linked version built for FreeBSD 12.

-- Brooks


signature.asc
Description: PGP signature

Re: FCP-0101: Deprecating most 10/100 Ethernet drivers

[Brooks Davis]

On Wed, Oct 24, 2018 at 06:54:01AM -0700, Rodney W. Grimes wrote:
> > On Wed, Oct 24, 2018 at 05:19:33AM -0700, Rodney W. Grimes wrote:
> > > And I have read case law that boiled down to the presents vs absence
> > > of a comma
> > 
> > If we are now going to evaluate all proposed changes to FreeBSD on the
> > same rigid principles as the US legal system, I'm done.
> 
> I do not think "all" is in scope here,
> but I do feel should excercise care about procedure.
> And FYI, the case law above I am pretty sure was not US.
> 
> I also believe that what is at issue here can be fixed
> rather easily without ever going down the minor vs major
> slippery slope by some rather simple changes to order
> of events and careful steps.
> 
> Warner came very close, I think he just applied his correct
> "fix" to 1/2 of the problem.
> 
> There is the stage where the FCP is before core being voted
> on, and there is the stage that the FCP has been approved.
> He only addressed 1 of those, and he did so by allowing core
> to trivially modify the document during the voting process,
> and I am actually fine with that idea, its good, it is what
> should be allowed.  I trust core to know what is minor vs
> major.
> 
> BUTT it still does not cover the issue of the author/submitter
> modifying the document while it is in core being reviewed and
> possibly modified.  I have issue with that.  It is very hard
> to vote/formally review on something that is fluid.
> I have not been asked to trust these people with the trust I
> give core, so I would like to remove that.

There are technical measures in place that do much of this already.
Right now, authors can't directly change the documents (unless they are
repo admins which means core and former core members in practice).  We
require that pull requests be reviewed before they are merged and random
people don't have commit access.  We could make the restriction to core
members or core members and fcp-editors explicit if that was desirable.

> We could add that once the document is submitted to core
> any change to it between submitting and vote by core requires
> core to be involved, even if it is simply an ack of a change
> has been made to what was submitted.

I agree.  We'll need to think on how best to do this.

-- Brooks


signature.asc
Description: PGP signature

Re: FCP-0101: Deprecating most 10/100 Ethernet drivers

[Brooks Davis]

On Tue, Oct 23, 2018 at 04:26:45PM -0700, Rodney W. Grimes wrote:
> > On Tue, Oct 23, 2018 at 5:07 PM Rodney W. Grimes <
> > freebsd-...@pdx.rh.cn85.dnsmgr.net> wrote:
> > 
> > > > On Tue, Oct 23, 2018 at 11:33:35PM +0200, Julian H. Stacey wrote:
> > > > > > I'd also suggest that rl stands in stark contrast to the cs, wb, sn,
> > > smc,
> > > > > > sf, tl, tx and vr drivers, which nobody has mentioned in this
> > > thread, and
> > > > > > which I doubt are in use in any FreeBSD system of any age today.
> > > > >
> > > > > vr is used by my TV driver laptop:
> > > > > http://www.berklix.com/~jhs/hardware/laptops/novatech-8355/
> > > > > vr0: flags=8843 metric 0 mtu
> > > 1500
> > > > > options=82808
> > > > > ether 00:40:d0:5e:26:38
> > > > > inet 192.168.91.65 netmask 0xff00 broadcast 192.168.91.255
> > > > > media: Ethernet autoselect (100baseTX
> > > )
> > > > > status: active
> > > > >
> > > > > Which currently runs 8.4-RELEASE & eg xrandr, but I'll upgrade soon
> > > > > when I also configure it to receive from a raspberry-pi TV VPN server.
> > > >
> > > > The above was a typo.  vr is on the the STAY list.
> > > >
> > > > -- Brooks
> > > Brooks,
> > > Is there a public revised version of FCP-0101 that reflects the
> > > feedback which is what core is voting on?
> > >
> > 
> > Its on github, just like it's been the whole time for anybody to see,
> > submit pull requests against and track:
> 
> I have no gh account, desires no gh account, so have no way to
> submit a change request other than through direct email to
> brooks or another gh user.  This is fundementally flawed.
> 
> > https://github.com/freebsd/fcp/blob/master/fcp-0101.md
> 
> Thank you for the link, I had looked at it before MeetBSD,
> which did not have most of the recent changes done "a day ago".
> 
> Isnt this document now in a frozen state while core reviews/votes?

I sent it to a vote at c224c67557297d7cba909ad008542cb60980cc6b only
to notice a bug in table rendering.  I submitted a pull request fix
that and a missing word which was merged since neither was material.  I
suppose they could have waited or been skipped, but there's no value in
the FCP process being bound by the sort of pointless rigidity that led
to -DPOSIX_MISTAKE in every libc compile line.

-- Brooks


signature.asc
Description: PGP signature

Re: FCP-0101: Deprecating most 10/100 Ethernet drivers

[Brooks Davis]

On Tue, Oct 23, 2018 at 04:06:48PM -0700, Rodney W. Grimes wrote:
> > On Tue, Oct 23, 2018 at 11:33:35PM +0200, Julian H. Stacey wrote:
> > > > I'd also suggest that rl stands in stark contrast to the cs, wb, sn, 
> > > > smc,
> > > > sf, tl, tx and vr drivers, which nobody has mentioned in this thread, 
> > > > and
> > > > which I doubt are in use in any FreeBSD system of any age today.
> > > 
> > > vr is used by my TV driver laptop:
> > > http://www.berklix.com/~jhs/hardware/laptops/novatech-8355/
> > > vr0: flags=8843 metric 0 mtu 1500
> > > options=82808
> > > ether 00:40:d0:5e:26:38
> > > inet 192.168.91.65 netmask 0xff00 broadcast 192.168.91.255
> > > media: Ethernet autoselect (100baseTX 
> > > )
> > > status: active
> > > 
> > > Which currently runs 8.4-RELEASE & eg xrandr, but I'll upgrade soon
> > > when I also configure it to receive from a raspberry-pi TV VPN server.
> > 
> > The above was a typo.  vr is on the the STAY list.
> > 
> > -- Brooks
> Brooks,
>   Is there a public revised version of FCP-0101 that reflects the
> feedback which is what core is voting on?

https://github.com/freebsd/fcp/blob/master/fcp-0101.md has been updated
throughout the feedback process as drivers were moved to the STAY list,
errors were found, etc.  It also contains a summary of responses and the
hard data we have.

-- Brooks


signature.asc
Description: PGP signature

Re: FCP-0101: Deprecating most 10/100 Ethernet drivers

[Brooks Davis]

On Tue, Oct 23, 2018 at 11:33:35PM +0200, Julian H. Stacey wrote:
> > I'd also suggest that rl stands in stark contrast to the cs, wb, sn, smc,
> > sf, tl, tx and vr drivers, which nobody has mentioned in this thread, and
> > which I doubt are in use in any FreeBSD system of any age today.
> 
> vr is used by my TV driver laptop:
> http://www.berklix.com/~jhs/hardware/laptops/novatech-8355/
> vr0: flags=8843 metric 0 mtu 1500
> options=82808
> ether 00:40:d0:5e:26:38
> inet 192.168.91.65 netmask 0xff00 broadcast 192.168.91.255
> media: Ethernet autoselect (100baseTX 
> )
> status: active
> 
> Which currently runs 8.4-RELEASE & eg xrandr, but I'll upgrade soon
> when I also configure it to receive from a raspberry-pi TV VPN server.

The above was a typo.  vr is on the the STAY list.

-- Brooks


signature.asc
Description: PGP signature

Re: FCP-0101: Deprecating most 10/100 Ethernet drivers

[Brooks Davis]

On Fri, Oct 05, 2018 at 04:18:22PM +0100, Jamie Landeg-Jones wrote:
> Remember, it's not simply deprecating cards less than 1Gig.
> 
> I have a card that is 10/100 only, but works fine with the gigabit alc driver:
> 
> alc0:  port 0x2000-0x207f mem 
> 0xe050-0xe053 irq 16 at device 0.0 on pci1

There are no plans to touch such drivers.

-- Brooks


signature.asc
Description: PGP signature

Re: FCP-0101: Deprecating most 10/100 Ethernet drivers

[Brooks Davis]

>>> Please direct replies to freebsd-arch <<<

A few points of clarification:

Rod correctly points out that this message makes it look like the FCP is
a done deal as written.  This is not the case and we welcome feedback
on the entire proposal.  IMO, soliciting input on the list of drivers
along with the proposed process is a way to keep discussion concrete so
we will proceed with both.

It was asked: when does iflib conversion need to occur to save a driver?
My proposed plan it to proceed with deprecation notices of otherwise
unpopular drivers, but conversion can come in and remove those notices
at and upto (or even after) removal from the tree.

In an effort to save some email, we will be moving rl(4) to the list of
drivers to STAY as it has proved itself to be popular.  A few others
appear to be well on their way so keep the reports coming.

Thanks,
Brooks

P.S. As a person who has edited every driver in the tree multiple times
in the last year (mostly in an external tree), I will consider this
process successful even if we keep the majority of listed drivers in the
tree.

On Wed, Oct 03, 2018 at 09:05:16PM +, Brooks Davis wrote:
> >>> Please direct replies to freebsd-arch <<<
> 
> FCP-01010 (https://github.com/freebsd/fcp/blob/master/fcp-0101.md)
> outlines a plan to deprecate most 10/100 Ethernet drivers in FreeBSD 12
> and remove them in FreeBSD 13 to reduce the burden of maintaining and
> improving the network stack.  We have discussed this within the
> core team and intend to move forward as proposed.  We are solictiting
> feedback on the list of drivers to be excepted from removal.
> 
> The current list of drivers slated for REMOVAL is:
> 
> ae, bfe, bm, cs, dme, ed, ep, ex, fe, pcn, rl, sf, smc, sn,
> ste, tl, tx, txp, vx, wb, xe
> 
> The current list of drivers that will STAY in the tree is:
> 
> dc, ffec, fxpl, hme, le, sis, vr, xl
> 
> The criteria for exception are:
>  - Popular in applications where it is likely to be deployed beyond the
>support lifetime of FreeBSD 12 (late 2023).
>- 5 reports of uses in the wild on machines running FreeBSD 12 will be
>  deemed satisfy the "popular"
>  requirement.
>  - Required to make a well supported embedded or emulation platform usable.
>  - Ported to use iflib (reducing future maintenance cost.)
> 
> Please reply to this message with nominations to the exception list.
> 
> The full FCP-0101 is included below.
> 
> -- Brooks
> 
> ---
> authors: Brooks Davis 
> state: feedback
> ---
> 
> # FCP 101: Deprecation and removal of 10/100 Ethernet drivers
> 
> Deprecate most 10 and 10/100Mbps Ethernet drivers and remove them before
> FreeBSD 13.
> 
> ## Problem Statement
> 
> Each network driver creates drag for the project as we attempt to
> improve the network stack or provide new features such as expanded
> 32-bit compatibility.  For example, the author has edited every single
> NIC driver more than once in the past year to update management (`ioctl`)
> interfaces.  We could improve this situation by converting drivers to
> iflib, but each additional driver takes work.
> 
> 10 and 100 megabit Ethernet drivers are largely irrelevant today
> and we have a significant number of them in the tree.  The ones that
> are no longer used and/or are not known to be working need to be
> removed due to the significant ongoing 'tax' on new development.
> 
> For at least a decade, most systems (including small embedded
> systems) have shipped with gigabit Ethernet devices and virtual
> machines commonly emulate popular gigabit devices.  We wish to
> retain support for popular physical and virtual devices while
> removing support for uncommon ones.  With a few exceptions these
> drivers are unlikely to be used by our user base by the time FreeBSD
> 12 is obsolete (approximately 2024).
> 
> ## Proposed Solution
> 
> We propose to deprecate devices which are not sufficiently popular.  This
> will entail:
>  - (October 2018) Send this list to freebsd-net and freebsd-stable.
>  - (Before FreeBSD 12.0-RELEASE - October 2018) Update the manpages and
>attach routines for each device to be removed and merge those changes
>to FreeBSD 12.
>  - (One month after FreeBSD 12.0-RELEASE - January 2018) Remind
>freebsd-net and freebsd-stable users of pending deletion.
>  - (Two months after FreeBSD 12.0-RELEASE - February 2019) Delete deprecated
>devices.
> 
> Through out this process, solicit feedback on additions to the exception
> list and update this document as required.  For a device to be placed on
> the exception list the device must meet one of the following criteria:
>  - Popular in applications where it is likely to be deployed beyond the
>

FCP-0101: Deprecating most 10/100 Ethernet drivers

[Brooks Davis]

>>> Please direct replies to freebsd-arch <<<

FCP-01010 (https://github.com/freebsd/fcp/blob/master/fcp-0101.md)
outlines a plan to deprecate most 10/100 Ethernet drivers in FreeBSD 12
and remove them in FreeBSD 13 to reduce the burden of maintaining and
improving the network stack.  We have discussed this within the
core team and intend to move forward as proposed.  We are solictiting
feedback on the list of drivers to be excepted from removal.

The current list of drivers slated for REMOVAL is:

ae, bfe, bm, cs, dme, ed, ep, ex, fe, pcn, rl, sf, smc, sn,
ste, tl, tx, txp, vx, wb, xe

The current list of drivers that will STAY in the tree is:

dc, ffec, fxpl, hme, le, sis, vr, xl

The criteria for exception are:
 - Popular in applications where it is likely to be deployed beyond the
   support lifetime of FreeBSD 12 (late 2023).
   - 5 reports of uses in the wild on machines running FreeBSD 12 will be
 deemed satisfy the "popular"
 requirement.
 - Required to make a well supported embedded or emulation platform usable.
 - Ported to use iflib (reducing future maintenance cost.)

Please reply to this message with nominations to the exception list.

The full FCP-0101 is included below.

-- Brooks

---
authors: Brooks Davis 
state: feedback
---

# FCP 101: Deprecation and removal of 10/100 Ethernet drivers

Deprecate most 10 and 10/100Mbps Ethernet drivers and remove them before
FreeBSD 13.

## Problem Statement

Each network driver creates drag for the project as we attempt to
improve the network stack or provide new features such as expanded
32-bit compatibility.  For example, the author has edited every single
NIC driver more than once in the past year to update management (`ioctl`)
interfaces.  We could improve this situation by converting drivers to
iflib, but each additional driver takes work.

10 and 100 megabit Ethernet drivers are largely irrelevant today
and we have a significant number of them in the tree.  The ones that
are no longer used and/or are not known to be working need to be
removed due to the significant ongoing 'tax' on new development.

For at least a decade, most systems (including small embedded
systems) have shipped with gigabit Ethernet devices and virtual
machines commonly emulate popular gigabit devices.  We wish to
retain support for popular physical and virtual devices while
removing support for uncommon ones.  With a few exceptions these
drivers are unlikely to be used by our user base by the time FreeBSD
12 is obsolete (approximately 2024).

## Proposed Solution

We propose to deprecate devices which are not sufficiently popular.  This
will entail:
 - (October 2018) Send this list to freebsd-net and freebsd-stable.
 - (Before FreeBSD 12.0-RELEASE - October 2018) Update the manpages and
   attach routines for each device to be removed and merge those changes
   to FreeBSD 12.
 - (One month after FreeBSD 12.0-RELEASE - January 2018) Remind
   freebsd-net and freebsd-stable users of pending deletion.
 - (Two months after FreeBSD 12.0-RELEASE - February 2019) Delete deprecated
   devices.

Through out this process, solicit feedback on additions to the exception
list and update this document as required.  For a device to be placed on
the exception list the device must meet one of the following criteria:
 - Popular in applications where it is likely to be deployed beyond the
   support lifetime of FreeBSD 12 (late 2023).
   - 5 reports of uses in the wild on machines running FreeBSD 12 will be
 deemed satisfy the "popular"
 requirement.
 - Required to make a well supported embedded or emulation platform usable.
 - Ported to use iflib (reducing future maintenance cost.)

### Exceptions to removal

Device | Reason
---|-
ffec   | Onboard Ethernet for Vybrid arm7 boards
fxp| Popular device long recommended by the project.
dc | Popular device for CardBus card.
hme| Built in interface on many supported sparc64 platforms.
le | Emulated by QEMU, alternatives don't yet work for mips64.
sis| Soekris Engineering net45xx, net48xx, lan1621, and lan1641.
vr | Soekris Engineering net5501, some Asus motherboards.
xl | Popular device for CardBus card.

Note: USB devices have been excluded from consideration in this round.

### Device to be removed

ae, bfe, bm, cs, dme, ed, ep, ex, fe, pcn, rl, sf, smc, sn,
ste, tl, tx, txp, vx, wb, xe

## Final Disposition

TBD


signature.asc
Description: PGP signature

Re: svn commit: r332493 - stable/11/sys/net

[Brooks Davis]

On Sat, Apr 14, 2018 at 08:54:15AM -0400, Ed Maste wrote:
> On 14 April 2018 at 07:31, Magnus Ringman  wrote:
> > Hi Brooks, this MFC missed your r331077
> > (https://reviews.freebsd.org/D14706) thus stable buildkernel currently
> > breaks on missing those two macros.
> 
> Thanks for identifying the missing commit Magnus. I've now merged it in 
> r332502.
> 

Sorry for the breakage and thanks for fixing this!

-- Brooks


signature.asc
Description: PGP signature

Re: Calling nxge(4) users

[Brooks Davis]

On Sun, Mar 25, 2018 at 01:09:27PM -0700, Rodney W. Grimes wrote:
> > The nxge(4) driver for the Neterion Xframe-I and Xframe-II 10GbE
> > adapters has obvious bugs (by inspection) and it doesn't appear the
> > company exists any more.  We'd like to see if there are any significant
> > users of this device and plan to remove it from FreeBSD-12 if not.
> > 
> > -- Brooks
> 
> Neterion has been acquired by exar. 
>   https://www.eetimes.com/document.asp?doc_id=1173009
> 
> They have the datasheet for the Xframe-I here:
>   https://www.exar.com/ds/xframedatasheet.pdf
> 
> The cards appear to be readily avaliable on ebay.

Given that most of these cards appear to have been PCI-X and the product
failed in the market, I'm not finding that compelling.  One could buy
a Chelsio or Intel card for a similar price and have a supported driver.

Unless someone has a significant deployment of these cards that will run
past the EOL of FreeBSD 11 (2021) this driver is a net negative.

-- Brooks


signature.asc
Description: PGP signature

Calling nxge(4) users

[Brooks Davis]

The nxge(4) driver for the Neterion Xframe-I and Xframe-II 10GbE
adapters has obvious bugs (by inspection) and it doesn't appear the
company exists any more.  We'd like to see if there are any significant
users of this device and plan to remove it from FreeBSD-12 if not.

-- Brooks


signature.asc
Description: PGP signature

Re: i386 with 4GB RAM: less than 2GB available on A2SAV (Intel Atom E3940)

[Brooks Davis]

On Tue, Jan 30, 2018 at 07:09:44AM -0700, Alan Somers wrote:
> On Tue, Jan 30, 2018 at 12:11 AM, Andre Albsmeier <
> andre.albsme...@siemens.com> wrote:
> 
> > On Sun, 28-Jan-2018 at 10:32:44 -0600, Mike Karels wrote:
> > > > On 28 Jan 2018, at 15:57, Andre Albsmeier 
> > =
> > > > wrote:
> > > > > I have a lot of machines running with 4 GB physical RAM and, for
> > > > > some reasons, I still have to use a 32 bits OS.
> > > > >=20
> > > > > All of them show something between 3 and 3.5 GB of RAM available
> > > > > in dmesg but the brand new Supermicro A2SAV really shocked me:
> > > > >=20
> > > > > FreeBSD 11.1-STABLE #0: Mon Jan 15 06:57:10 CET 2018
> > > > > ...
> > > > > real memory  =3D 4294967296 (4096 MB)
> > > > > avail memory =3D 1939558400 (1849 MB)
> > > > > ...
> > > > >=20
> > > > > So do people have any ideas how I might get a bit closer to at least
> > > > > 3 GB? I assume there are no FreeBSD knobs which might help but hope
> > > > > dies last...
> > >
> > > > This is a common problem on i386.  Most likely some ranges are reserved
> > > > for I/O mappings, such as video cards.  If you boot with -v, I think
> > the
> > > > kernel prints an overview of the physical ram chunks available?  I
> > don't
> > > > know of any other way to get such an overview.
> > >
> > > > Another option is to try PAE, but I have no idea how stable that is...
> > >
> > > > -Dimitry
> > >
> > > I suspect that the unavailable RAM has been mapped above 4 GB by the
> > BIOS.
> > >
> > > About PAE: at $JOB, we have a FreeBSD 8.2 system that has been running
> > > PAE reliably since 8.2 was new.  Also, we ship amd64 systems that run
> > > mostly 32-bit binaries, which works well.
> >
> > But can the entire userland be 32 bit only?
> 
> Sure.  I do this with jails.  It's no problem to have a 32-bit jail on a
> 64-bit kernel.  Kernel modules would be an issue, though.  If you need any,
> you'll have to find a way for the 64-bit machines to find 64-bit kernel
> modules.

There are some deficiencies in the management space[0], but it should
generally work.  Where it doesn't it's a bug and usually not too hard to
fix.

-- Brooks

[0] e.g. https://reviews.freebsd.org/D13459


signature.asc
Description: PGP signature

Impending NATM removal

[Brooks Davis]

As previously threatened, I plan to remove NATM support next week.  This
includes the drivers en(4), fatm(4), hatm(4), and patm(4).  None of
these devices have been manufactured in the last 20 years so it is time
to move on.

The planned commit can be seen at https://reviews.freebsd.org/D9883

-- Brooks


signature.asc
Description: PGP signature

Re: Calling ATM NIC users: en(4), fatm(4), hatm(4), patm(4)

[Brooks Davis]

Thanks, I've forwarded a copy to the list, but given that there were zero
non-spam messages in 2016, only three legitimate messages (that no one
answered) in 2015, and zero in 2014, 2013, and 2012, I think it's safe
to say there are no users.

-- Brooks

On Sun, Feb 19, 2017 at 12:38:21PM +, hartmut.bra...@dlr.de wrote:
> Hi,
> 
> there is a freebsd-atm mailing list (at least there used to be). Should have 
> been sent there too.
> 
> On the topic: I'd say: remove it. As the one who wrote/refactored much of 
> that stuff I get approximately one support request per year. The problem is, 
> that I can't really help, since while I have all of that equipment still 
> available, I don't have any time to do anything with it. So the entire ATM 
> stack is basically unsupported.
> 
> harti@
> 
> -Original Message-
> From: owner-freebsd-...@freebsd.org [mailto:owner-freebsd-...@freebsd.org] On 
> Behalf Of Brooks Davis
> Sent: Saturday, February 18, 2017 2:33 AM
> To: freebsd-stable@freebsd.org; freebsd-...@freebsd.org
> Subject: Calling ATM NIC users: en(4), fatm(4), hatm(4), patm(4)
> 
> Our current ATM stack supports a small number of NICs that were current in 
> the late 90s[0].  None of them have been manufactured in a long time and 
> while you can buy hatm(4) devices on e-bay, it's increasingly difficult to 
> find a motherboard that will accept them.
> 
> I'd like to propose removing support for these NICs along with the remaining 
> ATM stack in FreeBSD 12.  This will give any existing users a supported OS 
> until at least September 30, 2021 per our published EOL date for FreeBSD 11.
> 
> Would removal on this schedule cause you realistic hardship?  If so, please 
> let us know.
> 
> -- Brooks
> 
> [0] 1997 press release for the most advanced ATM NIC we support 
> http://www.prnewswire.com/news-releases/fore-systems-introduces-industrys-most-advanced-atm-adapter-for-enterprise-networking-77407267.html
> 


signature.asc
Description: PGP signature

Calling ATM NIC users: en(4), fatm(4), hatm(4), patm(4)

[Brooks Davis]

Our current ATM stack supports a small number of NICs that were
current in the late 90s[0].  None of them have been manufactured in a
long time and while you can buy hatm(4) devices on e-bay, it's
increasingly difficult to find a motherboard that will accept them.

I'd like to propose removing support for these NICs along with the
remaining ATM stack in FreeBSD 12.  This will give any existing users
a supported OS until at least September 30, 2021 per our published EOL
date for FreeBSD 11.

Would removal on this schedule cause you realistic hardship?  If so,
please let us know.

-- Brooks

[0] 1997 press release for the most advanced ATM NIC we support
http://www.prnewswire.com/news-releases/fore-systems-introduces-industrys-most-advanced-atm-adapter-for-enterprise-networking-77407267.html


signature.asc
Description: PGP signature

Re: Benchmarks results for Compilers on FreeBSD 11

[Brooks Davis]

On Wed, Aug 31, 2016 at 12:16:16PM -0700, K. Macy wrote:
> On Wednesday, August 31, 2016, Mark Linimon  wrote:
> 
> > I'll demur just a bit on your points.
> >
> > On Mon, Aug 29, 2016 at 08:51:02PM -0700, K. Macy wrote:
> > > "we need a compiler to build the system" (a prebuilt package does that
> > > just fine),
> >
> > Well, yes, for a tier-1 machine; and one that is connected to the network.
> >
> > > I can't speak for the whole universe of users, but I think it's safe
> > > to say that most users are not power users who individually configure
> > > ports tailored to their needs.
> >
> > We've certainly tried to provide a migration path away from that, but I
> > don't think anyone has statistics about how far along we are.  IMHO we
> > can't assume it's 100%, or maybe even 80%.
> >
> > > I think my experiences on Ubuntu [...] are illustrative.
> >
> > A number of years ago Ubuntu and FreeBSD had barely overlapping audiences:
> > end-users and developers.  With all the improvements to pkg and tier-1
> > packages I hope that is changing -- the goal of expanding the reach is
> > why I supported all the changes I saw being made.
> >
> > But for me an attraction has always been "you can build it out of the box",
> > even if I rarely do it (e.g. I am not working in the kernel/driver area),
> 
> Can clang actually bootstrap from something like lcc? As far as I can tell
> you need a fairly advanced C++ compiler just to build that compiler in src
> - which already needs to be installed. It's not exactly bootstrapping from
> Bourne shell. So I'm not sure "it's self-hosting" is even true, not to
> mention that you needed a network connection to get src in the first place.
> Thus the whole argument strikes me as circular if not outright deceptive.

Clang needs a pretty complete C++11 compiler and runtime which means
modern gcc or clang.

-- Brooks


signature.asc
Description: PGP signature

Re: Newer clang than comes with install?

[Brooks Davis]

On Fri, Mar 04, 2016 at 09:53:08AM -0500, Kevin P. Neal wrote:
> On Fri, Mar 04, 2016 at 02:22:26PM +0000, Brooks Davis wrote:
> > On Thu, Mar 03, 2016 at 08:45:05AM -0500, kpn...@pobox.com wrote:
> > > I notice on 10.2 we're using "FreeBSD clang version 3.4.1". But there are
> > > bugs in this version of clang that I'm having trouble with.
> > > 
> > > Is compiling a newer (say, 3.7.1) version of clang to target FreeBSD
> > > supported? I have no desire to replace any of the libraries, just the
> > > compiler itself. Is that supposed to work _without_ going through the
> > > ports/pkgs system?
> > > 
> > > IOW, can I just download from llvm.org the clang+llvm source, compile
> > > it on FreeBSD, and then use it safely?
> > 
> > It should.  The ports don't include many patches.
> 
> Yeah, I was just looking at the patches we do include. One of them it looks
> like causes some of the llvm.org-provided includes to not be installed.
> 
> I'm not sure I can, well, not install them because I also need to use the
> same install to do cross compiles. A quick check shows that those includes
> are used when targetting cross and native.
> 
> Am I correct about the include files? And, if so, are there plans to
> upstream patches so the llvm.org includes will work out of the box for
> FreeBSD-hosted-and-targetted compiles?

The std*.h include files included with clang are broken on FreeBSD.  On
one has stepped forward to fix them so you will have to chose between
installing them and bening able build FreeBSD.  In practice, you should
still be able to cross compile if you have a working sysroot for your
target.

-- Brooks


signature.asc
Description: PGP signature

Re: Newer clang than comes with install?

[Brooks Davis]

On Thu, Mar 03, 2016 at 08:45:05AM -0500, kpn...@pobox.com wrote:
> I notice on 10.2 we're using "FreeBSD clang version 3.4.1". But there are
> bugs in this version of clang that I'm having trouble with.
> 
> Is compiling a newer (say, 3.7.1) version of clang to target FreeBSD
> supported? I have no desire to replace any of the libraries, just the
> compiler itself. Is that supposed to work _without_ going through the
> ports/pkgs system?
> 
> IOW, can I just download from llvm.org the clang+llvm source, compile
> it on FreeBSD, and then use it safely?

It should.  The ports don't include many patches.

-- Brooks


signature.asc
Description: PGP signature

Re: MFC r282973 (disable libgomp build) and r283060 (disable libgcov build)?

[Brooks Davis]

On Fri, Jul 24, 2015 at 02:15:28PM -0700, Don Lewis wrote:
 On 24 Jul, Matthieu Volat wrote:
  I'm not fond of lang/gcc as openmp provider: if a port use c++, it
  will cause linkage headaches with libc++ (I never was able to have
  graphics/darktable working, for example).
 
 You might want to try out lang/clang-devel with devel/libiomp5-devel.
 See this thread on freebsd-ports@
 http://docs.freebsd.org/cgi/mid.cgi?55AE0474.5050207.

Just a heads up in case you try this next week, devel/libiomp5-devel is
about to be deleted and the openmp library (as well as clang-devel) will
be installed by the llvm-devel port.  The clang-devel port will become a
metaport to aid people in finding clang while we wait for multiple
packages-per-port support.

-- Brooks


pgpgFt6RczLRA.pgp
Description: PGP signature

Re: buildworld without libncursesw

[Brooks Davis]

On Wed, Mar 04, 2015 at 10:47:44AM +1100, Dewayne Geraghty wrote:
 
 On 4/03/2015 8:13 AM, Brooks Davis wrote:
  On Tue, Mar 03, 2015 at 08:20:57PM +1100, Dewayne Geraghty wrote:
  Is there a preferred way to buildworld without libncursesw?
 
  When I add to /etc/src.conf
  WITHOUT_NCURSESW=yes
 
  I find that a buildworld fails due to missing libncursesw.*.
  So what uses libncurses?  These guys do
  /usr/bin/dialog
  /usr/bin/dpv
   
  /usr/sbin/sade - /usr/libexec/bsdinstall/partedit
  /usr/sbin/tzsetup
 
  Getting a little frustrated I modifed the Makefile:, so for example
  dialog (/usr/src/contrib/dialog)
 
  +.include bsd.own.mk
  +
  +.if ${MK_NCURSESW} == no
  +DPADD= ${LIBDPV} ${LIBDIALOG} ${LIBFIGPAR} ${LIBNCURSES}
  ${LIBUTIL} ${LIBM}
  +LDADD= -ldpv -ldialog -lfigpar -lncurses -lutil -lm
  +.else
   DPADD= ${LIBDPV} ${LIBDIALOG} ${LIBFIGPAR} ${LIBNCURSESW}
  ${LIBUTIL} ${LIBM}
   LDADD= -ldpv -ldialog -lfigpar -lncursesw -lutil -lm
  +.endif
 
  And checking
  # make -VMK_NCURSESW
  no
 
  I'm at a bit of a loss as to why these are proving difficult to build,
  or what I can do to get the desired outcome, ie no libncursesw.so*
  I tried to make this work a while ago and it's not practical.  Instead,
  we need to remove libncurses (or more likely replace it with a linker
  script to cause libncursesw to be used.)
 
  It should be the case that nothing in the base system uses libncurses,
  but it's all too likely that someone has broken that since I switched
  the remaining bits over.
 
  -- Brooks
 Unfortunately I can't say which ones use libncurses as I've sprinkled
 things like this over anything that uses libncursesw
 
 -DPADD= ${LIBDEVSTAT} ${LIBKVM} ${LIBGEOM} ${LIBBSDXML} ${LIBSBUF}
 ${LIBEDIT} ${LIBNCURSESW}
 -LDADD= -ldevstat -lkvm -lgeom -lbsdxml -lsbuf -ledit -lncursesw
 +DPADD= ${LIBDEVSTAT} ${LIBKVM} ${LIBGEOM} ${LIBBSDXML} ${LIBSBUF}
 ${LIBEDIT}
 +LDADD= -ldevstat -lkvm -lgeom -lbsdxml -lsbuf -ledit
 
 +.include bsd.own.mk
 +
 +.if ${MK_NCURSESW} == no
 +DPADD+= ${LIBNCURSES}
 +LDADD+= -lncurses
 +.else
 +DPADD+= ${LIBNCURSESW}
 +LDADD+= -lncursesw
 +.endif
 +
 
 and only the above 4 programs are more of a challenge.
 
 Any consistency is a good thing, so honouring WITHOUT_NCURSESW should be
 the trigger.  This situation arose because I needed some things in
 /rescue and there was a conflict stuffing both libncurses and
 libncursesw into the /usr/src/rescue build, as you'd expect. :)

I'd forgotten I'd merged WITHOUT_NCURSESW to 10.  That was a mistake as
it turns out to be unmaintainable.  I removed it from head long ago and
it will not return.  Unless you want to fix it and keep fixing it as
things are merged from head we should either remove it or document it as
broken.

-- Brooks


pgpFsfYzIEBlL.pgp
Description: PGP signature

Re: buildworld without libncursesw

[Brooks Davis]

On Tue, Mar 03, 2015 at 08:20:57PM +1100, Dewayne Geraghty wrote:
 Is there a preferred way to buildworld without libncursesw?
 
 When I add to /etc/src.conf
 WITHOUT_NCURSESW=yes
 
 I find that a buildworld fails due to missing libncursesw.*.
 So what uses libncurses?  These guys do
 /usr/bin/dialog
 /usr/bin/dpv
  
 /usr/sbin/sade - /usr/libexec/bsdinstall/partedit
 /usr/sbin/tzsetup
 
 Getting a little frustrated I modifed the Makefile:, so for example
 dialog (/usr/src/contrib/dialog)
 
 +.include bsd.own.mk
 +
 +.if ${MK_NCURSESW} == no
 +DPADD= ${LIBDPV} ${LIBDIALOG} ${LIBFIGPAR} ${LIBNCURSES}
 ${LIBUTIL} ${LIBM}
 +LDADD= -ldpv -ldialog -lfigpar -lncurses -lutil -lm
 +.else
  DPADD= ${LIBDPV} ${LIBDIALOG} ${LIBFIGPAR} ${LIBNCURSESW}
 ${LIBUTIL} ${LIBM}
  LDADD= -ldpv -ldialog -lfigpar -lncursesw -lutil -lm
 +.endif
 
 And checking
 # make -VMK_NCURSESW
 no
 
 I'm at a bit of a loss as to why these are proving difficult to build,
 or what I can do to get the desired outcome, ie no libncursesw.so*

I tried to make this work a while ago and it's not practical.  Instead,
we need to remove libncurses (or more likely replace it with a linker
script to cause libncursesw to be used.)

It should be the case that nothing in the base system uses libncurses,
but it's all too likely that someone has broken that since I switched
the remaining bits over.

-- Brooks


pgptqg5lvAXt2.pgp
Description: PGP signature

Re: include/c++/v1 still in BSD.include.dist as well as in obsolete_files

[Brooks Davis]

On Tue, Jun 18, 2013 at 11:22:55PM +0200, Dimitry Andric wrote:
 On Jun 18, 2013, at 21:03, Kevin Oberman rkober...@gmail.com wrote:
  When I run make check-old, the /usr/include/c++/v1 and v1/ext directories
  are listed as old, but they are still present in BSD.include.dist, so are
  recreated every time I installworld.
  
  Could these directories be removed from BSD.include.dist, as I am pretty
  sure that they ARE obsolete.
 
 They are not obsolete, as they are part of libc++, but I don't think it
 is already possible to have parts of mtree files depend on WITH_XXX
 settings.  So we can either remove the directories (but not the files)
 from ObsoleteFiles.inc, or attempt to amend mtree so it can handle
 conditional parts.
 
 Brooks, any idea if NetBSD's mtree supports that feature? :-)

It doesn't.  The only way to do this currently is to create separate
mtree files for each set of option directories.  In the current world
order this sucks because each parent directly must be specified with
correct permissions so there's lots of opportunity to break things.  I'm
hoping to fix that some time soon by switch to new-format mtree files.
You'd still have to use separate files, but at least they would only
contain the relevant directories.

-- Brooks


pgpg238oMHZT7.pgp
Description: PGP signature

Re: make buildkernel for GENERIC 9-STABLE just hangs, no error

[Brooks Davis]

On Wed, Apr 17, 2013 at 09:10:59AM +0200, Olav Gr?n?s Gjerde wrote:
 I have a weird problem while building the GENERIC 9-STABLE kernel. After
 around 5 minutes of compile time, the process just hangs on same place. No
 error. I've tried compiling different commits from this week with the same
 result.
 
 The part in the buildkernel process that hangs is this:
 MAKE=make sh /usr/src/sys/conf/newvers.sh GENERIC
 /usr/local/bin/svnversion
 cc -c -O2 -frename-registers -pipe -fno-strict-aliasing  -std=c99 -g -Wall
 -Wredundant-decls -Wnested-externs -Wstrict-prototypes
 -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual  -Wundef
 -Wno-pointer-sign -fformat-extensions  -Wmissing-include-dirs
 -fdiagnostics-show-option   -nostdinc  -I. -I/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 -mno-mmx -mno-sse -msoft-float
 -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror
 vers.c
 ctfconvert -L VERSION -g vers.o
 linking kernel.debug
 ctfmerge -L VERSION -g -o kernel.debug + alot of *.o
 
 Any suggestions?

In the DTrace commit message thread, you mentioned that you were
upgrading from an old 8-STABLE to 9 when you got the hang.  Could you
quantify how old that 8-STABLE was/is?  If it's pre-8.3 it would be
really helpful if you could upgrade to 8.3 and test that.  If that works
then I think a note in UPDATING would be sufficient as our historical
policy has been to support upgrading to release X.Y from
(X-1).newest.  If it turns out that we need to upgrade to 8.4 we may
need to consider backing this out for a bit.

-- Brooks


pgp_q00Y4kJbC.pgp
Description: PGP signature

Re: make buildkernel for GENERIC 9-STABLE just hangs, no error

[Brooks Davis]

On Wed, Apr 17, 2013 at 08:57:22PM +0200, Olav Gr?n?s Gjerde wrote:
 It was(sorry) from around 12th June 2012.
 But I have another system with 8.2-RELEASE that I can upgrade to a commit
 around 12th June 2012 and then try directly to 9-STABLE(or 8.3 first?) if
 that would be helpful?

It would be helpful if you could first try an upgrade from 8.2-RELEASE.
It would also be good to know if 8.3-RELEASE builds.  If we've got a
transient issue in the 8.2-STABLE line, we can document it and move on.
If it persisted through 8.3-STABLE that's more of an issue.

Thanks,
Brooks

 
 
 On Wed, Apr 17, 2013 at 8:16 PM, Brooks Davis bro...@freebsd.org wrote:
 
  On Wed, Apr 17, 2013 at 09:10:59AM +0200, Olav Gr?n?s Gjerde wrote:
   I have a weird problem while building the GENERIC 9-STABLE kernel. After
   around 5 minutes of compile time, the process just hangs on same place.
  No
   error. I've tried compiling different commits from this week with the
  same
   result.
  
   The part in the buildkernel process that hangs is this:
   MAKE=make sh /usr/src/sys/conf/newvers.sh GENERIC
   /usr/local/bin/svnversion
   cc -c -O2 -frename-registers -pipe -fno-strict-aliasing  -std=c99 -g
  -Wall
   -Wredundant-decls -Wnested-externs -Wstrict-prototypes
   -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual  -Wundef
   -Wno-pointer-sign -fformat-extensions  -Wmissing-include-dirs
   -fdiagnostics-show-option   -nostdinc  -I. -I/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 -mno-mmx -mno-sse -msoft-float
   -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror
   vers.c
   ctfconvert -L VERSION -g vers.o
   linking kernel.debug
   ctfmerge -L VERSION -g -o kernel.debug + alot of *.o
  
   Any suggestions?
 
  In the DTrace commit message thread, you mentioned that you were
  upgrading from an old 8-STABLE to 9 when you got the hang.  Could you
  quantify how old that 8-STABLE was/is?  If it's pre-8.3 it would be
  really helpful if you could upgrade to 8.3 and test that.  If that works
  then I think a note in UPDATING would be sufficient as our historical
  policy has been to support upgrading to release X.Y from
  (X-1).newest.  If it turns out that we need to upgrade to 8.4 we may
  need to consider backing this out for a bit.
 
  -- Brooks
 


pgpU_IWwaaZOp.pgp
Description: PGP signature

Re: make buildkernel for GENERIC 9-STABLE just hangs, no error

[Brooks Davis]

Thank you.  You might try with this patch applied.  It's not the right
patch but only in that it's too agressive about building ctfconvert as a
cross tool.

Index: Makefile.inc1
===
--- Makefile.inc1   (revision 249590)
+++ Makefile.inc1   (working copy)
@@ -1114,9 +1114,7 @@
usr.bin/clang/clang-tblgen
 .endif
 
-.if ${MK_CDDL} != no  \
-${BOOTSTRAPPING}  800038  \
-!(${BOOTSTRAPPING} = 700112  ${BOOTSTRAPPING}  79)
+.if ${MK_CDDL} != no
 _dtrace_tools= cddl/usr.bin/sgsmsg cddl/lib/libctf lib/libelf \
 lib/libdwarf cddl/usr.bin/ctfconvert cddl/usr.bin/ctfmerge
 .endif

On Wed, Apr 17, 2013 at 10:09:42PM +0200, Olav Gr?n?s Gjerde wrote:
 I will try to upgrade from both of those releases and come back to you with
 my results.
 
 Kind regards,
 Olav
 
 
 On Wed, Apr 17, 2013 at 9:18 PM, Brooks Davis bro...@freebsd.org wrote:
 
  On Wed, Apr 17, 2013 at 08:57:22PM +0200, Olav Gr?n?s Gjerde wrote:
   It was(sorry) from around 12th June 2012.
   But I have another system with 8.2-RELEASE that I can upgrade to a commit
   around 12th June 2012 and then try directly to 9-STABLE(or 8.3 first?) if
   that would be helpful?
 
  It would be helpful if you could first try an upgrade from 8.2-RELEASE.
  It would also be good to know if 8.3-RELEASE builds.  If we've got a
  transient issue in the 8.2-STABLE line, we can document it and move on.
  If it persisted through 8.3-STABLE that's more of an issue.
 
  Thanks,
  Brooks
 
  
  
   On Wed, Apr 17, 2013 at 8:16 PM, Brooks Davis bro...@freebsd.org
  wrote:
  
On Wed, Apr 17, 2013 at 09:10:59AM +0200, Olav Gr?n?s Gjerde wrote:
 I have a weird problem while building the GENERIC 9-STABLE kernel.
  After
 around 5 minutes of compile time, the process just hangs on same
  place.
No
 error. I've tried compiling different commits from this week with the
same
 result.

 The part in the buildkernel process that hangs is this:
 MAKE=make sh /usr/src/sys/conf/newvers.sh GENERIC
 /usr/local/bin/svnversion
 cc -c -O2 -frename-registers -pipe -fno-strict-aliasing  -std=c99 -g
-Wall
 -Wredundant-decls -Wnested-externs -Wstrict-prototypes
 -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual  -Wundef
 -Wno-pointer-sign -fformat-extensions  -Wmissing-include-dirs
 -fdiagnostics-show-option   -nostdinc  -I. -I/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 -mno-mmx -mno-sse -msoft-float
 -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector
  -Werror
 vers.c
 ctfconvert -L VERSION -g vers.o
 linking kernel.debug
 ctfmerge -L VERSION -g -o kernel.debug + alot of *.o

 Any suggestions?
   
In the DTrace commit message thread, you mentioned that you were
upgrading from an old 8-STABLE to 9 when you got the hang.  Could you
quantify how old that 8-STABLE was/is?  If it's pre-8.3 it would be
really helpful if you could upgrade to 8.3 and test that.  If that
  works
then I think a note in UPDATING would be sufficient as our historical
policy has been to support upgrading to release X.Y from
(X-1).newest.  If it turns out that we need to upgrade to 8.4 we may
need to consider backing this out for a bit.
   
-- Brooks
   
 


pgpIbKh_zOdnm.pgp
Description: PGP signature

Re: CLANG 3.2 breaks security/pam_ssh_agent_auth on stable/9

[Brooks Davis]

On Thu, Jan 31, 2013 at 10:22:44PM -0600, Mark Linimon wrote:
 On Thu, Jan 17, 2013 at 09:15:02AM -0600, Brooks Davis wrote:
  Not unless you consider adding new functions in a reserved namespace
  (str*) to be ABI breakage.
 
 Well, what often happens is that when we add new functions, ports break.
 I think deciding whether this is or is not ABI breakage is semantics.
 The fact is that regressions get introduced with these types of changes.
 
  The port should have continued to work unless it was recompiled so it
  should have preferred it's own version of the strnvis symbol.  If its
  makefiles were properly constructed it would have failed to compile
  due to the signature mismatch.
 
 The mantra should be every possible combination of ways that a port's
 internal build glue can be wrong, is already included in the Ports 
 Collection.
 In case after case we see fragile code that is written by people who are
 clearly not professionally trained.  They get it to work on their system
 and then shove it out the door.
 
 Claiming that they shouldn't do that is correct but self-defeating.
 It's just the reality of open-source software.

I'm not sure why I'm being jumped on me in this weeks old report of a
now-fixed problem.  I did determine to root cause and others produced a
patch.  If no one else had stepped up I would have done so my self.

 IMHO, the burden should be on whoever makes the change to find out whether
 or not regressions will be introduced.  (And yes, I am very aware that we
 don't have -exp run capability right now, but this is one of the cases
 where I would like to suggest it would have helped.)

I would likely have done an exp run had there been the capability of
doing one, but this bug would not have been found since it's a runtime
crash caused by a combination of two different BSD projects not talking
to each other and poorly chosen CFLAGS in the upstream software allowing
it to compile.

One could probably write a tool to detect some forms this sort of issue
(even premptively), but it's probably not worth doing.

-- Brooks


pgpSXZsGprvjG.pgp
Description: PGP signature

[RFC] possible non-backward-compatible change to install(1)

[Brooks Davis]

In CURRENT I have added a number of features to the install(1) command
that are derived from NetBSD.  One of them is the -M metalog option
that causes new-style mtree entries to be emitted for each object that
is created in the target.  In the interest of compatibility and usability I
removed the previous meaning of the -M option (disable mmap).  I would
like to MFC this change as is in violation of our usual practice, but
before I do so I want to solicit opinions on the subject.

I believe it is sufficiently safe to remove the -M option in a stable
branch because:
 - It is not used in our source tree.
 - It is FreeBSD specific and thus it is used nowhere in portable software.
 - It has not been useful since the VM system stabilized in the
   late-90s/early-2000's so it is unlikely to be used in FreeBSD
   specific software.
 - In the unlikely even the -M option is in use in some historic
   Makefile or script, nearly all install commands that did it will result
   in command line validation errors.
 - Those that don't will not result in direct data loss.

The benefit of the change is that (in conjunction with several other
changes) it will be possible to build FreeBSD releases and some types of
embedded media images without root privilege.

Does anyone have strong (preferably non-hypothetical) objections to this
change?

-- Brooks


pgpIgUHji3ZQX.pgp
Description: PGP signature

Re: CLANG 3.2 breaks security/pam_ssh_agent_auth on stable/9

[Brooks Davis]

On Thu, Jan 17, 2013 at 09:06:27AM +0200, Kimmo Paasiala wrote:
 On Wed, Jan 16, 2013 at 8:01 PM, Kimmo Paasiala kpaas...@gmail.com wrote:
  On Wed, Jan 16, 2013 at 6:15 PM, Dimitry Andric d...@freebsd.org wrote:
  On 2013-01-16 13:05, Kimmo Paasiala wrote:
 
  I just updated my stable/9 system after clang3.2 was added. My system
  is amd64, both world and kernel are compiled with clang3.2 and the
  default compiler is clang. I'm tracking the sources with GIT and the
  version I have corresponds to SVN revision r245451.
 
  Everything else seems to work but the pam authentication module
  security/pam_ssh_agent_auth segfaults immediately.
 
  ...
 
  #0  0x000800ef2070 in strsvis () from /lib/libc.so.7
  #1  0x000800ef2584 in strvis () from /lib/libc.so.7
  #2  0x000800ef25e5 in strnvis () from /lib/libc.so.7
  #3  0x000801c0e2e7 in do_log () from
  /usr/local/lib/pam_ssh_agent_auth.so
  #4  0x000801c0e4ff in logit () from
  /usr/local/lib/pam_ssh_agent_auth.so
 
  ...
 
  The str*vis() calls suggest that it's something in the libc maybe?
 
 
  Brooks merged the new strvis implementations in r245439, so you may have
  run into a bug with them.  I don't think this is caused specifically by
  clang, at least not without more proof. :-)
 
  Can you try reverting to the revision just before r245439, rebuilding
  and reinstalling at least libc, and see if the pam_ssh_agent_auth crash
  goes away?
 
 
 Confirmed. Reverting world to one commit before r245439 and using the
 version of the port I used before fixes the problem.
 
 Trying to use the version I compiled with post r245439 world results
 in su: pam_start: system error when used on pre r245439 world.
 
 I have to repeat my question, isn't this the definition of ABI breakage?

Not unless you consider adding new functions in a reserved namespace
(str*) to be ABI breakage.  The port should have continued to work unless
it was recompiled so it should have preferred it's own version of the
strnvis symbol.  If it's makefiles were properly constructed it would
have failed to compile due to the signature mismatch.  It's unfortunate
that NetBSD and OpenBSD picked different function signatures for
strnvis, but it's beyond our control.

-- Brooks


pgpMufexVxhw3.pgp
Description: PGP signature

Re: CLANG 3.2 breaks security/pam_ssh_agent_auth on stable/9

[Brooks Davis]

On Wed, Jan 16, 2013 at 08:01:00PM +0200, Kimmo Paasiala wrote:
 On Wed, Jan 16, 2013 at 6:15 PM, Dimitry Andric d...@freebsd.org wrote:
  On 2013-01-16 13:05, Kimmo Paasiala wrote:
 
  I just updated my stable/9 system after clang3.2 was added. My system
  is amd64, both world and kernel are compiled with clang3.2 and the
  default compiler is clang. I'm tracking the sources with GIT and the
  version I have corresponds to SVN revision r245451.
 
  Everything else seems to work but the pam authentication module
  security/pam_ssh_agent_auth segfaults immediately.
 
  ...
 
  #0  0x000800ef2070 in strsvis () from /lib/libc.so.7
  #1  0x000800ef2584 in strvis () from /lib/libc.so.7
  #2  0x000800ef25e5 in strnvis () from /lib/libc.so.7
  #3  0x000801c0e2e7 in do_log () from
  /usr/local/lib/pam_ssh_agent_auth.so
  #4  0x000801c0e4ff in logit () from
  /usr/local/lib/pam_ssh_agent_auth.so
 
  ...
 
  The str*vis() calls suggest that it's something in the libc maybe?
 
 
  Brooks merged the new strvis implementations in r245439, so you may have
  run into a bug with them.  I don't think this is caused specifically by
  clang, at least not without more proof. :-)
 
  Can you try reverting to the revision just before r245439, rebuilding
  and reinstalling at least libc, and see if the pam_ssh_agent_auth crash
  goes away?
 
 I'm rebuilding world now. Took me some time to figure out how to
 revert the commits in git. I'll report back once finished.

NetBSD and OpenBSD use different signatures for strnvis(). :(
pam_ssh_agent_auth assumes that if the system has one it is the OpenBSD
one but ours is the NetBSD one.  The port will need to be patched to use
the openbsd version like it was doing or to swap the second and third
arguments when build on newer versions of FreeBSD.

-- Brooks


pgpu7MPNWFfEl.pgp
Description: PGP signature

Re: What is negative group permissions? (Re: narawntapu security run output)

[Brooks Davis]

On Mon, Dec 24, 2012 at 03:27:57PM +, jb wrote:
 Mikhail T. mi+thun at aldan.algebra.com writes:
 
  
  On 23.12.2012 11:48, Chris Rees wrote:
   They involve a lot of thought to get right, as well as chmod g-w on 
   something where you probably meant chmod go-w is a disastrous but 
   (perhaps) common error. Chris 
  
  Well, in (over 20) years of dealing with Unix, I've never made a mistake 
  like that, nor do I understand, how it can be considered common ... 
  Got to admit, I was surprised to see it. It made me think, I do not 
  understand something -- or that FreeBSD is becoming overly 
  paternalistic. It turned out to be the latter...
  
  I doubt, it is useful. Worse, issuing such warnings routinely, only 
  reinforces the unfortunate misconceptions like the one Barney 
  demonstrated in this thread. When originally added, the check was meant 
  to be off by default:
  ... 
  perhaps, it should have remained off? Yours,
 
 Those security checks are for a reason - people make mistakes (even a perfect
 guy like you will have a head in a brown bag time).
 It is better to get a heads-up, then think about it and turn it off 
 (customize)
 if considered unneeded.

This specific check is there and on by default because you CAN NOT rely
on negative group permissions unless you never use more than 14 groups
or never use NFS.  The check is a compromise I implemented as part of
the switch to allowing large number of groups per user (technically
per-process).  Users who wish to use them and know what they are doing
can easily turn it off.

IIRC the reason it was off by default to start with is that I wanted to
MFC it but it's been a long time so I'm no longer certain.

-- Brooks


pgpgTrzT6zRm2.pgp
Description: PGP signature

Re: Why not provide libclang.so in base?

[Brooks Davis]

On Thu, Jul 19, 2012 at 09:31:04AM +0200, Dimitry Andric wrote:
 On 2012-07-18 14:54, Yanhui Shen wrote:
  I'm using clang-complete plugin in vim,
  it claims with libclang.so instead of bin/clang it works better.
  
  However libclang.so is not installed by a default make buildworld  make
  installworld,
  even with 'WITH_CLANG_EXTRAS=YES' in src.conf.
 
 This is because it would add quite a lot of build overhead to produce
 that .so file: all the object files will need to be recompiled yet again
 for shared library support.
 
 That said, we will probably want to provide at least a shared LLVM lib
 in the future, since it can be re-used by other programs.  When that
 happens, it would not be too much extra work to provide a shared Clang
 library.

When I talked to Chris Lattner about shared libraries, his advice was
that under no circumstances should we consider supporting any C++ APIs
from the base system.  We can link tools in the system with them and we
can provide supportable C API wrappers as Apple does, but any port that
links against a libclang.so or libLLVM.so is doomed to break so ports
should link against port versions so they can be updated as needed.

-- Brooks


pgp22RF0hp5zB.pgp
Description: PGP signature

Re: kpanic on install 32GB of RAM

[Brooks Davis]

On Sat, Oct 16, 2010 at 12:52:00PM -0700, Sean Bruno wrote:
 On Fri, 2010-10-15 at 09:38 -0700, Sean Bruno wrote:
  On Fri, 2010-10-15 at 09:30 -0700, Boris Kochergin wrote:
   On 10/15/10 12:27, Jeremy Chadwick wrote:
On Fri, Oct 15, 2010 at 09:04:53AM -0700, Sean Bruno wrote:
So, trying to get a massively overpowered HP box up with 7.3 amd64
version up and running.
   
I can't tell at the moment, but it looks like the installer kernel is
having issues with32GB of RAM in this box.
   
Are we using the i386 kernel on amd64 installs?
If you booted a FreeBSD image that has amd64 in the ISO name, then the
kernel is actually 64-bit (amd64).  The only i386 piece would be the
bootloader.
   
There's probably someone here who can help with the issue you describe,
as there's occasional posts here and there from people who experience
issues/problems when using very large amounts of RAM.
   
   I've got an amd64 machine with 48 GB of RAM that has run 7, 8, and now 
   9, which leads me to believe that your issue is not solely related to 
   the amount of memory.
   
   -Boris
   __
  
  Edge case at 64G perhaps?  That's the minimum you can get in the HP
  DL980 apparently.
  
  Sean
 
 Hrm, no success today setting available RAM to 32G and reducing the
 number of processors to 8.
 
 I've disabled and tweaked pretty much everything available to me here
 and have tried to boot up the fbsd 8 install media with the same result
 as using the fbsd 7 media:  Repeated and continuous panics on all
 processors simultaneously after selecting install method from the boot
 menu.
 
 Not sure what to do at this point to get the system up and running.
 Suggestions?

I can say it's not the RAM amount since I'm running 8 on:

CPU: Intel(R) Xeon(R) CPU   L5520  @ 2.27GHz (2261.01-MHz K8-class CPU)
  Origin = GenuineIntel  Id = 0x106a5  Family = 6  Model = 1a  Stepping = 5
  
Features=0xbfebfbffFPU,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=0x9ce3bdSSE3,DTES64,MON,DS_CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,DCA,SSE4.1,SSE4.2,POPCNT
  AMD Features=0x28100800SYSCALL,NX,RDTSCP,LM
  AMD Features2=0x1LAHF
  TSC: P-state invariant
real memory  = 77310459904 (73729 MB)
avail memory = 74596175872 (71140 MB)

-- Brooks


pgpFceR8F886J.pgp
Description: PGP signature

Re: Hardware

[Brooks Davis]

On Fri, Oct 15, 2010 at 03:02:59PM -0300, M?rcio Luciano Donada wrote:
 Hi,
 We buy some hardware, new, but came with processors exchanged below what
 we ask. However, the manufacturing of hardware, informed us that we
 could install everything and then just replace the processor. how will I
 use FreeBSD in 90% of these servers, it really can be done well? After
 replacing the processor, I just simply re-compile the kernel and all
 packages that were installed previously? Can somebody give me some
 document FreeBSD.org about these details?

You shouldn't need to do anything.  Unless you compile with specific
optimizations which work with one processor and not the other (uncommon,
but not completely unheard of for processors that fix the same socket)
then the software will all be the same.

-- Brooks


pgpfNjOefcgjk.pgp
Description: PGP signature

Re: install root certificates

[Brooks Davis]

On Tue, Feb 02, 2010 at 12:59:31PM -0500, Xian Chen wrote:
 Hello,
 
 I use 8.0 Release on my thinkpad T42 laptop and want to connect to the WIFI
 AP near me.  The AP is encrypted by WPA2. I also need some root
 certifications installed ( UTN-USERFirst-Hardware ). I install
 /usr/ports/security/ca_root_nss and openssl but still I cannot find where
 the certifications are.
 
 Any ideas?

$ pkg_info -L ca_root_nss\*
Information for ca_root_nss-3.11.9_2:

Files:
/usr/local/share/certs/ca-root-nss.crt

-- Brooks


pgpp6ikDFVSGE.pgp
Description: PGP signature

Re: booting off GPT partitions

[Brooks Davis]

On Wed, Jan 27, 2010 at 06:45:36PM +0200, Dan Naumov wrote:
 Hey
 
 I was under the impression that everyone and their dog is using GPT
 partitioning in FreeBSD these days, including for boot drives and that
 I was just being unlucky with my current NAS motherboard (Intel
 D945GCLF2) having supposedly shaky support for GPT boot. But right now
 I am having an email exchange with Supermicro support (whom I
 contacted since I am pondering their X7SPA-H board for a new system),
 who are telling me that booting off GPT requires UEFI BIOS, which is
 supposedly a very new thing and that for example NONE of their current
 motherboards have support for this.
 
 Am I misunderstanding something or is the Supermicro support tech misguided?

The compatability MBR should be sufficent to let a non-GPT aware BIOS
boot from GPT.  Once you've loaded code from the boot partition, the
BIOS doesn't need to know anything about the partitions.

-- Brooks


pgp8pD1O6RdfM.pgp
Description: PGP signature

Re: booting off GPT partitions

[Brooks Davis]

On Thu, Jan 28, 2010 at 12:27:54AM +0100, Dimitry Andric wrote:
 On 2010-01-27 22:27, John Baldwin wrote:
 GPT was defined along with EFI, so many folks assume that you have to use EFI
 to boot a GPT-labelled disk.  However, FreeBSD has its own BIOS-based
 bootstrap that can handle GPT-labelled disks.  I doubt the SuperMicro tech is
 familiar with that case.  I thought I heard that some folks had added GPT
 support to grub as well.
 
 However, this won't boot disks larger than 2TiB, right?  At least not
 without BIOS support...

You won't be able to boot from a partition more than 2TiB in, but you
should still be able to boot as long as you boot from the front part of
the disk.

-- Brook


pgpj5hBEqRLpB.pgp
Description: PGP signature

Re: dhclient starts after NETWORK

[Brooks Davis]

On Tue, Dec 08, 2009 at 04:04:20PM +0300, Denis Shaposhnikov wrote:
 Hello,
 
 On Mon, 07 Dec 2009 22:02:26 +0100
 Ronald Klop ronald-freeb...@klop.yi.org wrote:
 
  Does ifconfig_rl0=SYNCDHCP help?
 
   synchronous_dhclient=YES
 
 helps for me, ntpdate syncs after I changed rc.conf with it.

Hmm, this sounds like defaultroute isn't working correctly for you.  Do
you have both static and dynamic interface configurations or just dhcp?

-- Brooks


pgperHeu4dGDb.pgp
Description: PGP signature

Re: dhclient starts after NETWORK

[Brooks Davis]

On Mon, Dec 07, 2009 at 12:03:39PM +0300, al...@ulgsm.ru wrote:
 
 Wrong order in /etc/rc.d scripts
 
 ~]rcorder /etc/rc.d/* | grep -n -e dhclient -e ntp
 66:/etc/rc.d/ntpdate
 112:/etc/rc.d/ntpd
 139:/etc/rc.d/dhclient
 
 Then ifconfig_rl0=DHCP? ntpdate can`t sync time.
 
 
 It is right to add dhclient in REQUIRE section in /etc/rc.d/NETWORKING ? 

The dhclient script doesn't do anything when run as part of the startup
sequence so this isn't your problem.

-- Brooks


pgpbYCfUolJ0F.pgp
Description: PGP signature

Re: Base system's Heimdal with Openldap support?

[Brooks Davis]

On Thu, Sep 24, 2009 at 04:45:05PM -0700, Doug Barton wrote:
 Peter C. Lai wrote:
  What happens when you portupgrade? You will have to deal with rebuilding
  that part of world?
 
 Not unless the shared library version number changes, that's the
 beauty of shared libraries.

Unfortunatly we're talking about openldap which has seen at least two
version bumps in the last 12 months IIRC.

-- Brooks


pgphkFcsgiaM2.pgp
Description: PGP signature

Re: svn commit: r197065 - in stable/8: etc/defaults lib/libc/stdlib sys/amd64/conf sys/i386/conf sys/ia64/conf sys/pc98/conf sys/powerpc/conf sys/sparc64/conf

[Brooks Davis]

On Thu, Sep 10, 2009 at 05:36:56PM +0200, Ivan Voras wrote:
 2009/9/10 Ken Smith kensm...@cse.buffalo.edu:
  On Thu, 2009-09-10 at 15:29 +0100, Gavin Atkinson wrote:
 
  This seems like a step backwards to me: crash dumps have been left
  enabled in 7.x and have proved very useful from the point of view of
  improved quality of received PRs. ??I'm not aware of any problems
  relating to leaving them enabled.
 
  I'd appreciate it if this decision was reconsidered.
 
 
  Unfortunately as I said before there is no Right answer for this one.
 
 No, but there is an 80% right one, based on the question: did the
 change in 7 cause known problems for any significant number of users
 (or one of two big users - that should be enough).

Given that we've shipped three releases with it this way we should have
an answer here.  If we can't identify real problem instances by now,
there probably aren't significant ones in practice.  IMO, we have always
gone too far in disabling debugging.

-- Brooks


pgpC7AykfaPUQ.pgp
Description: PGP signature

Re: ifconfig_ed0=DHCP does not work on 8.0-BETA3

[Brooks Davis]

On Sat, Sep 05, 2009 at 01:06:35PM +0200, Thierry Thomas wrote:
 Le Ven  4 sep 09 ? 23:57:47 +0200, Brooks Davis bro...@freebsd.org
  ?crivait?:
  
  This is a know issue with some devices supported by ed(4).  You can work
  around it by changing DHCP to SYNCDHCP which will cause dhclient to
  alwasy start immediatly on that interface instead of waiting for a link
  state change that never happens.
 
 Thanks for the hint!
 
 What about the following patch?
 
 --- man4_ed.4.diff begins here ---
 --- src/share/man/man4/ed.4.orig  2009-08-03 10:13:06.0 +0200
 +++ src/share/man/man4/ed.4   2009-09-05 12:51:51.0 +0200
 @@ -425,3 +425,11 @@
  .Pp
  PC Card attachment supports the D-Link DMF650TX LAN/Modem card's Ethernet
  port only at this time.
 +.Pp
 +If the line ed0: link state changed to UP does not show up in dmesg, the 
 line
 +.Pp
 +ifconfig_ed0=DHCP
 +.Pp
 +in
 +.Xr rc.conf 5
 +will be ineffective. In this case, replace DHCP by SYNCDHCP.
 --- man4_ed.4.diff ends here ---
 
 Don't hesitate to reword it - my englsh can be terrible!

I'd rather not mention the link state changed message since I'd love
to see it go away.  How's this?

Index: ed.4
===
--- ed.4(revision 196736)
+++ ed.4(working copy)
@@ -425,3 +425,21 @@
 .Pp
 PC Card attachment supports the D-Link DMF650TX LAN/Modem card's
Ethernet
 port only at this time.
+.Pp
+Some devices supported by
+.Nm
+do no generate the link state change events used by
+.Xr devd 8
+to start
+.Xr dhclinet 8 .
+If you have problems with
+.Xr dhclient 8
+not starting and the device is always attached to the network it may
+be possible to work around this by changing
+.Dq Li DHCP
+to
+.Dq Li SYNCDHCP
+in the
+.Va ifconfig_ed0
+entry in
+.Pa /etc/rc.conf .

=- Brooks


___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org

Re: ifconfig_ed0=DHCP does not work on 8.0-BETA3

[Brooks Davis]

On Wed, Sep 09, 2009 at 07:07:01PM +0200, Thierry Thomas wrote:
 Le Mer  9 sep 09 ? 17:52:57 +0200, Brooks Davis bro...@freebsd.org
  ?crivait?:
 
  I'd rather not mention the link state changed message since I'd love
  to see it go away.  How's this?
 
 Seems good, go!

Thanks.  I've committed it.

Brooks
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org

Re: ifconfig_ed0=DHCP does not work on 8.0-BETA3

[Brooks Davis]

On Fri, Sep 04, 2009 at 02:41:48PM -0700, Pyun YongHyeon wrote:
 On Fri, Sep 04, 2009 at 07:38:11PM +0200, Thierry Thomas wrote:
  Hello,
  
  I have a machine with the following ethernet PCI card:
  
  ed0: RealTek 8029 port 0xdc00-0xdc1f irq 16 at device 0.0 on pci2
  ed0: WARNING: using obsoleted if_watchdog interface
  ed0: Ethernet address: 00:50:bf:27:ba:24
  ed0: [ITHREAD]
  
  It's rather an ancient card, and it worked on FreeBSD 7.2-STABLE (and
  several previous versions) with the line:
  
  ifconfig_ed0=DHCP
  
  in /etc/rc.conf.
  
  I upgraded this machine to 8.0-BETA3, and ed0 does not get an IP anymore
  at boot time! Running `dhclient ed0' manually is working, and then
  everything is OK.
  
 
 I guess it's related with link state handling. Can you see
 ed0: link state changed to UP in dmesg output? Quick reading code
 reveals only some variants(pccard) support mii(4) but others looks
 dumb on link state handling. I vaguely remember I had ed(4)
 hardwares in FreeBSD 2.2.x days but didn't have chance to read the
 source.

This is a know issue with some devices supported by ed(4).  You can work
around it by changing DHCP to SYNCDHCP which will cause dhclient to
alwasy start immediatly on that interface instead of waiting for a link
state change that never happens.

-- brooks


pgpErHfkzFehV.pgp
Description: PGP signature

Re: ue0 dhclient FBSD8-BETA2

[Brooks Davis]

On Wed, Jul 22, 2009 at 02:05:43PM -0500, Paul A. Procacci wrote:
 Gents,
 
 Since the name changed for my cdce device, booting up the OS fails to 
 obtain an address via dhcp on this interface.  dhclient works normally 
 after the machine is booted and I provide the command on the command line.
 
 I've got the following in my rc.conf which I would have thought to be 
 enough, but it doesn't matter as dhclient never gets run,
 
 ifconfig_ue0=DHCP
 
 This isn't a deal breaker by any means, but would like to inquire about 
 about the proper steps for getting dhclient to physically work on the ue0 
 interface.  Docs on this subject (usb ethernet changes) at this point are 
 scarce and I'm not sure what specifically needs to be done.

This generally means that ue0 never reports a link up event which means
dhclient never gets run.  If so, the driver is broken, but you may be
able to work around it by changing DHCP to SYNCDHCP.  In that case
it may work if the cable is plugged in when the device it attached.

-- Brooks


pgpfg3bWNlfx2.pgp
Description: PGP signature

Re: ZFS: drive replacement performance

[Brooks Davis]

On Tue, Jul 07, 2009 at 12:56:14PM -0700, Mahlon E. Smith wrote:
 
 I've got a 9 sata drive raidz1 array, started at version 6, upgraded to
 version 13.  I had an apparent drive failure, and then at some point, a
 kernel panic (unrelated to ZFS.)  The reboot caused the device numbers
 to shuffle, so I did an 'export/import' to re-read the metadata and get
 the array back up.
 
 Once I swapped drives, I issued a 'zpool replace'.
 
 That was 4 days ago now.  The progress in a 'zpool status' looks like
 this, as of right now:
 
  scrub: resilver in progress for 0h0m, 0.00% done, 2251h0m to go
 
 ... which is a little concerning, since a) it appears to have not moved
 since I started it, and b) I'm in a DEGRADED state until it finishes...
 if it finishes.
 
 So, I reach out to the list!
 
  - Is the resilver progress notification in a known weird state under
FreeBSD?
 
  - Anything I can do to kick this in the pants?  Tuning params?
 
  - This was my first drive failure under ZFS -- anything I should have
done differently?  Such as NOT doing the export/import? (Not sure
what else I could have done there.)

I'm seeing essentially the same think on an 8.0-BETA1 box with an 8-disk
raidz1 pool.  Every once in a while the system makes it to 0.05% done
and gives a vaguely reasonable rebuild time, but it quickly drops back
to reports 0.00% and it's basically not making any forward progress.  In
my case this is a copy of a mirror so while it would be a bit annoying
to rebuild, the system could be rebuilt fairly easily.

On thing I did just notice is that my zpool version is 13, but my file
systems are all v1 rather than the latest (v3).  I don't know if this is
relevant or not.

-- Brooks


pgp5qP7xlqtwD.pgp
Description: PGP signature

Re: ZFS: drive replacement performance

[Brooks Davis]

On Wed, Jul 08, 2009 at 01:40:02AM +0300, Dan Naumov wrote:
 On Wed, Jul 8, 2009 at 1:32 AM, Freddie Cashfjwc...@gmail.com wrote:
  On Tue, Jul 7, 2009 at 3:26 PM, Mahlon E. Smith mah...@martini.nu wrote:
 
  On Tue, Jul 07, 2009, Freddie Cash wrote:
  
   This is why we've started using glabel(8) to label our drives, and then
  add
   the labels to the pool:
   ? # zpool create store raidz1 label/disk01 label/disk02 label/disk03
  
   That way, it does matter where the kernel detects the drives or what the
   physical device node is called, GEOM picks up the label, and ZFS uses the
   label.
 
  Ah, slick. ?I'll definitely be doing that moving forward. ?Wonder if I
  could do it piecemeal now via a shell game, labeling and replacing each
  individual drive? ?Will put that on my try it list.
 
 Not to derail this discussion, but can anyone explain if the actual
 glabel metadata is protected in any way? If I use glabel to label a
 disk and then create a pool using /dev/label/disklabel, won't ZFS
 eventually overwrite the glabel metadata in the last sector since the
 disk in it's entirety is given to the pool? Or is every filesystem
 used by FreeBSD (ufs, zfs, etc) hardcoded to ignore the last few
 sectors of any disk and/or partition and not write data to it to avoid
 such issues?

Disks labeled with glabel lose their last sector to the label.  It is not
accessible by ZFS.  Disks with bsdlabel partition tables are at risk due to
the brain dead decision to allow partitions to overlap the first sector,
but modern designs like glabel avoid this mistake.

-- Brooks


pgptEAL0izsL9.pgp
Description: PGP signature

Re: ZFS: drive replacement performance

[Brooks Davis]

On Wed, Jul 08, 2009 at 08:32:12AM +1000, Andrew Snow wrote:
 Mahlon E. Smith wrote:
 
 Strangely, the ETA is jumping all over the place, from 50 hours to 2000+
 hours.  Never seen the percent complete over 0.01% done, but then it
 goes back to 0.00%.
 
 Are you taking snapshots from crontab?  Older versions of the ZFS code 
 re-started scrubbing whenever a snapshot was taken.

I know I'm not doing anything to mine.  It's just sitting there unused.

-- Brooks


pgpP0kZirFSiT.pgp
Description: PGP signature

Re: ZFS: drive replacement performance

[Brooks Davis]

On Wed, Jul 08, 2009 at 11:53:17AM +1000, Emil Mikulic wrote:
 On Tue, Jul 07, 2009 at 03:53:58PM -0500, Brooks Davis wrote:
  I'm seeing essentially the same think on an 8.0-BETA1 box with an 8-disk
  raidz1 pool.  Every once in a while the system makes it to 0.05% done
  and gives a vaguely reasonable rebuild time, but it quickly drops back
  to reports 0.00% and it's basically not making any forward progress.
 
 You're not creating or deleting snapshots, are you?
 AFAICT doing that will make scrub (and resilver) start from scratch.

As far as I know, no snapshots are being created or deleted.

-- Brooks


pgpSiTaVAy8H6.pgp
Description: PGP signature

Re: Do you use a value other than AUTO for network_interfaces?

[Brooks Davis]

On Tue, Jun 02, 2009 at 06:06:48PM -0500, Erik Osterholm wrote:
 On Tue, Jun 02, 2009 at 12:20:34PM -0700, Doug Barton wrote:
  Up till Sunday in 8-current, and for a long time in general
  network.subr (part of the rc.d system) has emitted a warning that
  values of network_interfaces other than AUTO are deprecated. I
  removed that warning in HEAD Sunday, and there is no a discussion
  about whether or not it should be put back, and whether or not there
  is any need for the user to specify the list of network interfaces
  at all.
  
  If you use a value of network_interfaces other than AUTO please
  speak up so that we can make an intelligent decision about this
  issue.
  
  Thanks,
  
  Doug
 
 I'll have to preface this by disclosing that I have not been running
 -current, nor following any changes to the RC system.
 
 In 7.1, if you compile a custom kernel and comment out an interface
 (such that it is compiled as a module), one way to ensure that the
 module is loaded is to explicitly list it in network_interfaces.  If
 -current works the same way, then users will be required to modify
 /boot/loader.conf in order to load the module.  Could there could be
 possible side-effects to this change, since the loading of the module
 happens at a different time?

Do you actually do this?

 At best, users doing things the 'network_interfaces' way may be in for
 a surprise when the update (remotely), and this may be worthy of a
 note in UPDATING.
 
 If this has changed in 7.2 or -current, then I apologize for the
 noise!

The deprecation is a change relative to 7.0, but was in 7.1.

-- Brooks


pgpuOce7pt6kS.pgp
Description: PGP signature

Re: Do you use a value other than AUTO for network_interfaces?

[Brooks Davis]

On Wed, Jun 03, 2009 at 06:18:01PM +0200, Angelo Turetta wrote:
 Doug Barton wrote:
 If you use a value of network_interfaces other than AUTO please speak
 up so that we can make an intelligent decision about this issue.
 
 Maybe I am wrong, setting network_interfaces is the way I found I had to 
 use to be able to rename cloned interfaces.
 
 eg:
 
 network_interfaces=lo0 em0 dmz
 ifconfig_em0=up
 cloned_interfaces=vlan0
 
 ifconfig_vlan0_name=dmz
 ifconfig_dmz=192.168.34.129/24 vlan 2 vlandev em0
 
 I seem to remember I had to put that 'dmz' in network_interfaces, to make 
 everything happy at boot. I can do more tests if needed.

Hmm, there might be a bug related to cloned interfaces and renaming.
That should be easy to fix.

-- Brooks


pgpkLjbT4ZI0N.pgp
Description: PGP signature

Re: Do you use a value other than AUTO for network_interfaces?

[Brooks Davis]

On Tue, Jun 02, 2009 at 03:51:25PM -0500, David Kelly wrote:
 On Tue, Jun 02, 2009 at 10:30:46PM +0200, Ruben van Staveren wrote:
  
  On 2 Jun 2009, at 21:20, Doug Barton wrote:
  
  Up till Sunday in 8-current, and for a long time in general
  network.subr (part of the rc.d system) has emitted a warning that
  values of network_interfaces other than AUTO are deprecated. I
  removed that warning in HEAD Sunday, and there is no a discussion
  about whether or not it should be put back, and whether or not there
  is any need for the user to specify the list of network interfaces at
  all.
  
  Well, I do.
  
  I only want to configure only the interfaces that are connected and
  that I know about. especially in combination with IPv6 there is a nit
  that you'll get autoconfiguration for all interfaces unless they are
  all explicitly configured.
 
 And while I'm not currently using anything other than AUTO I would think
 there is a security ramification if someone were to plug in to a
 supposedly unused port, then reboot the machine to prompt AUTO to
 configure their interface.
 
 Its not just a security thing, its an idiot-proof thing. If someone is
 moving machines around I don't want them to come up and partially work
 if the wires are plugged into the wrong holes. Would rather it be
 completely broken.
 
 I think its good that there is an AUTO *option*. Is also OK that it be
 the default. I don't think mandatory AUTO is good, if I want a port
 disabled then I want it to stay disabled.

To repeat what I wrote earlier today on another list there's no need
to worry about hot plugged or newly added interfaces getting magically
configured to do dhcp or anything else[0].  For the system to do
something with an interface the following must be true:

 - It makes it in to the list of interfaces somehow (either by adding it
   to network_interfaces or leaving network_interfaces alone)
 - It actually exists or is create early in the process via
   cloned_interfaces, gif_interfaces, etc
 - The ifconfig_if variable is set (I think i can be , but up is
   always a good choice if you just want a stub.
 - The ifconfig_if variable must not contain the NOAUTO keyword.

If all of those things are true, the interface will be configured at
startup or on insert.  Otherwise, it won't be.

-- Brooks

[0] This is at least true in the IPv4 case, the IPv6 case really needs
work.  I thought someone had patches to bring the IPv6 support up to
par with the IPv4 case, but they haven't been committed yet.


pgpQtryU3OduY.pgp
Description: PGP signature

Re: Do you use a value other than AUTO for network_interfaces?

[Brooks Davis]

On Tue, Jun 02, 2009 at 10:30:46PM +0200, Ruben van Staveren wrote:
 
 On 2 Jun 2009, at 21:20, Doug Barton wrote:
 
 Up till Sunday in 8-current, and for a long time in general
 network.subr (part of the rc.d system) has emitted a warning that
 values of network_interfaces other than AUTO are deprecated. I removed
 that warning in HEAD Sunday, and there is no a discussion about
 whether or not it should be put back, and whether or not there is any
 need for the user to specify the list of network interfaces at all.
 
 Well, I do.
 
 I only want to configure only the interfaces that are connected and that I 
 know about. especially in combination with IPv6 there is a nit that you'll 
 get autoconfiguration for all interfaces unless they are all explicitly 
 configured.

See my other post on why this is a needless worry for the IPv4 case.

 e.g. bge0 connected, bge1 not, v6 autoconf on the lan. if I don't do a 
 ipv6_ifconfig_bge1=down and nail network_interfaces to bge0 bge1 lo0 only 
 I'll get autoconfiguration of v6 where I don't want it to be.
 
 
 Being a bit of my own devils advocate here, network_interfaces=AUTO is 
 already true for ipv6. with network_interfaces=bge0 lo0 network.subr 
 nevertheless sees bge1, and no configuration and takes the responsibility 
 of starting ipv6 autoconfiguration for it.

The IPv6 case is clearly a bug.  We should really consolidate the two
cases and I think there are patches to do so if someone wants to setup
up and help get them in.

-- Brooks


pgpmOFAe0FIRr.pgp
Description: PGP signature

Re: Do you use a value other than AUTO for network_interfaces?

[Brooks Davis]

On Wed, Jun 03, 2009 at 07:22:34AM +0900, Randy Bush wrote:
  To repeat what I wrote earlier today on another list there's no need
  to worry about hot plugged or newly added interfaces getting magically
  configured to do dhcp or anything else[0].
 
 such as detected by services such as bind/unbound?

The rc system will do nothing with interfaces that don't pass the tests
I enumerated so if you don't have an ifconfig_if interface there won't
be any difference no matter how you set network_interfaces.  I'd be
rather supprised if bind did anything with interaces that weren't
configured with an address (or even up in the case of correctly
funtioning drivers).

-- Brooks


pgpvekOcFGdVy.pgp
Description: PGP signature

Re: dhclient cant renew lease.

[Brooks Davis]

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


pgpoGgOqa1A4A.pgp
Description: PGP signature

Re: cvsup freebsd 6_2 to freebsd 7_1 not upgrading?

[Brooks Davis]

On Tue, Jan 06, 2009 at 09:31:48AM -0700, Brian Duke wrote:
 This is very odd.
 I got desperate last night and steeled myself for a reinstall. Copied all
 the known keeper files to an alternate drive including /home, /etc,
 /usr/local/etc and a couple others. It's on a completely separate drive with
 no OS just files on it. I downloaded what I thought was 7.1 iso and burned
 the image to disks from my spare windows machine. I sure of it as I made a
 point to upgrade to 7.1
 
 I stuck in the install disk and rebooted. 
 I didn't mess with fdisk left it the same. 
 Used disk druid to set the mount points like they were before and toggle
 newfs to Yes.
 
 I watched the install perform a newfs on the mount points. As it was loading
 the new kernel and support files I kept seeing snippets saying file for
 FreeBSD 7.0 loaded. I figured there were legacy files being added and let it
 continue. The install disks loaded everything with success. The
 congratulation screen popped up and set the final options. I got to the
 reboot and it warned me to take out the disk before rebooting.

I suspect the 7.0 stuff is a bug in the release media, but almost
certainly a red herring in this case.

 While booting I saw right after choosing normal boot it said proudly
 FreeBSD 6.2-RELEASE.
 
 My question is this, after a system boots from the CD, performs a newfs,
 loads everything in /usr perfectly as all my /home directories are gone and
 /root is empty. How can a kernel continue to exist?
 
 I'm done with newfs as that seems to have no effect. I'm going to fdisk the
 system now and seriously mess with the MBR. But just before I do, anyone
 have any idea how install disks doing a standard install do not overwrite
 the kernel?  

This is really odd.  It sounds like you are somehow booting from one
root file system (with the 6.2 kernel) and then mounting another one
over the top of it.  I'm not sure quite how I'd go about tracking this
down.  A dmesg might help and the output lsdev in the loader might be
interesting.

-- Brooks


pgpDldUa1yNi5.pgp
Description: PGP signature

Re: cvsup freebsd 6_2 to freebsd 7_1 not upgrading?

[Brooks Davis]

[This question would be better to ask on the freebsd-questions list, but see
below.]

On Mon, Jan 05, 2009 at 11:41:40AM -0700, Brian Duke wrote:
 Hello List,
 I'm trying to upgrade my system from 6_2 to 7_1 and cannot seem to do it.
 Perhaps I'm missing something. Here is the basic procedure I'm following.
 
 #cp /usr/share/examples/cvsup/standard-supfile /root/stand_sup
 #vi /root/stand_sup
 host=CHANGE_ME.freebsd.org
 host=cvsup15.us.FreeBSD.org
 tag=RELENG_6_2
 tag=RELENG_7_1
 
 #cd /usr/src
 #cvsup -g -L2 /root/stand_sup
 ...
 #make -j4 buildworld; make -j4 buildkernel; make installkernel
 
 ... (come back a hour or so later)
 #make installworld; reboot
 
 After system is back up log in as root and...
 
 # uname -a
 FreeBSD lazerus.box201.com 6.2-RELEASE FreeBSD 6.2-RELEASE #0: Fri Jan 12
 11:05:30 UTC 2007 r...@dessler.cse.buffalo.edu:/usr/obj/usr/src/sys/SMP
 i386
 
 I cannot understand why this system will not upgrade. Even with the
 mergemaster -p commands added this system always boots to FreeBSD
 6.2-RELEASE. I've tried this in various ways about 20 times and slowly I'm
 corrupting the 6.2 build. I have the install disks but the Upgrade FreeBSD
 detects the /usr/src and refuses to over-write the directory. The make
 commands always finish perfectly. Would someone give this apparent noob a
 hand?

You have misunderstood the purpose of csup/cvsup.  It will upgrade
your source tree and allow you to compile a new kernel and userspace,
but it will not upgrade your system for your.  What you appear to want
to do (binary upgrade) can be accomplished using freebsd-update.  See
the Updating and Upgrading FreeBSD chapter of the FreeBSD Handbook,
particularly the FreeBSD Update section for more details:

http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/updating-upgrading.html

-- Brooks


pgpXyiixCc2lF.pgp
Description: PGP signature

Re: cvsup freebsd 6_2 to freebsd 7_1 not upgrading?

[Brooks Davis]

OK, now I feel like an idiot, I completely misread the middle of your
e-mail.  You might still want to check out freebsd-update since it's a
lot quicker than rebuilding, but that's not your issue here.

On Mon, Jan 05, 2009 at 01:35:55PM -0600, Brooks Davis wrote:
 [This question would be better to ask on the freebsd-questions list, but see
 below.]
 
 On Mon, Jan 05, 2009 at 11:41:40AM -0700, Brian Duke wrote:
  Hello List,
  I'm trying to upgrade my system from 6_2 to 7_1 and cannot seem to do it.
  Perhaps I'm missing something. Here is the basic procedure I'm following.
  
  #cp /usr/share/examples/cvsup/standard-supfile /root/stand_sup
  #vi /root/stand_sup
  host=CHANGE_ME.freebsd.org
  host=cvsup15.us.FreeBSD.org
  tag=RELENG_6_2
  tag=RELENG_7_1
  
  #cd /usr/src

Was /usr/src empty or populated before you did the initial cvsup?  
If it was populated, you need to adopt it before updating.

http://www.cvsup.org/faq.html#caniadopt

I personally just nuke the old tree in most cases.  If you want to try an
source update, this is probably a good option.

  #cvsup -g -L2 /root/stand_sup
  ...
  #make -j4 buildworld; make -j4 buildkernel; make installkernel

Given a lack of a reboot here, you're lucky cvsup isn't working right.
If it was, you'd mostly likely have an unusable system part way through
the installworld below.

  ... (come back a hour or so later)
  #make installworld; reboot
  
  After system is back up log in as root and...
  
  # uname -a
  FreeBSD lazerus.box201.com 6.2-RELEASE FreeBSD 6.2-RELEASE #0: Fri Jan 12
  11:05:30 UTC 2007 r...@dessler.cse.buffalo.edu:/usr/obj/usr/src/sys/SMP
  i386
  
  I cannot understand why this system will not upgrade. Even with the
  mergemaster -p commands added this system always boots to FreeBSD
  6.2-RELEASE. I've tried this in various ways about 20 times and slowly I'm
  corrupting the 6.2 build. I have the install disks but the Upgrade FreeBSD
  detects the /usr/src and refuses to over-write the directory. The make
  commands always finish perfectly. Would someone give this apparent noob a
  hand?

You might try removing the directory entirely and extracting over it.  You can
also do that manually by cating tall the split files into tar.

-- Brooks

 
 You have misunderstood the purpose of csup/cvsup.  It will upgrade
 your source tree and allow you to compile a new kernel and userspace,
 but it will not upgrade your system for your.  What you appear to want
 to do (binary upgrade) can be accomplished using freebsd-update.  See
 the Updating and Upgrading FreeBSD chapter of the FreeBSD Handbook,
 particularly the FreeBSD Update section for more details:
 
 http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/updating-upgrading.html




pgpirVhv9vbj9.pgp
Description: PGP signature

Re: cvsup freebsd 6_2 to freebsd 7_1 not upgrading?

[Brooks Davis]

On Mon, Jan 05, 2009 at 03:08:01PM -0700, Brian Duke wrote:
 Forgive me for not being as clear as I should have been. I was trying to be 
 brief.
 The original email stated in the paragraph below my procedure...
 
  I cannot understand why this system will not upgrade. Even with the 
  mergemaster -p commands added this system always boots to FreeBSD 
  6.2-RELEASE.
 
 I do reboot after the 
 #make installkernel
 I do run mergemaster;
 
 The fact is I made a critical mistake at the beginning of this
 endeavor which left me in this condition.
 
 I followed this procedure
 http://people.freebsd.org/~rse/upgrade/freebsd-upgrade-6x-7x.txt up
 to the point where I was supposed to change from /usr/src to /usr/adm
 and type make update. At that moment I knew I made a mistake not
 coming from FreeBSD6.4. I got an immediate Bad system call (core
 dumped). I tried to correct the problem by building world and kernel
 manually. That didn't help. Everything builds find with no visible
 errors. Since then I've been trying to fix that mistake. Here is an
 example of what happens during freebsd-update.

 # freebsd-update fetch
 Looking up update.FreeBSD.org mirrors... Bad system call (core dumped)
 none found.
 Fetching public key from update.FreeBSD.org... done.
 Fetching metadata signature for 6.2-RELEASE from update.FreeBSD.org... done.
 Fetching metadata index... done.
 Fetching 2 metadata files... done.
 Inspecting system... done.
 Preparing to download files... done.
 Fetching 69 files... failed.
 #
 
 csup also does an immediate core dump. That???s why I'm using
 cvsup. My Perl5.8.8 seems unaffected. I'd like to keep my /usr/home
 if possible and certain video drivers. That???s why I downloaded and
 burned new 7.1 CD's to see if the upgrade there would correct my
 src. The install boots up and says it will not fix my src's and tells
 me to try cvsup again.

Since it looks like your supfile below is OK, you might try blowing away
/usr/src and the contents of /var/db/sup and trying again.  Assuming
none of the build binaries are 6.4 or 7.1 dependent, you may be able to
recover from a clean tree.  Otherwise, it looks like you'll need to do a
manual refresh of 6.2 from the CD or reinstall.  A back up of key data and
reinstall may well be fastest at this point.

 Does uname -a only show me the MOTD data? I thought that program was
 a bit more precise. I've used FreeBSD for years but still consider
 myself very new.

uname -a returns the versions string it gets from the kernel so it
should be accurate. /etc/motd is updated at boot using the output of
uname.

 My supfile looks like this:
 
 # IMPORTANT: Change the next line to use one of the CVSup mirror sites
 # listed at http://www.freebsd.org/doc/handbook/mirrors.html.
 *default host=cvsup15.us.FreeBSD.org
 *default base=/var/db
 *default prefix=/usr
 *default release=cvs tag=RELENG_7_1
 *default delete use-rel-suffix
 
 # If you seem to be limited by CPU rather than network or disk bandwidth, try
 # commenting out the following line.  (Normally, today's CPUs are fast enough
 # that you want to run compression.)
 *default compress
 
 ## Main Source Tree.
 #
 # The easiest way to get the main source tree is to use the src-all
 # mega-collection.  It includes all of the individual src-* collections.
 src-all
 -
 
 I've used FreeBSD for years but still consider myself very
 new. I appreciate the help reminding me to reboot and then make
 installworld. I should have written the first email a bit clearer.
 
 agrapha
 
 -Original Message-
 From: owner-freebsd-sta...@freebsd.org 
 [mailto:owner-freebsd-sta...@freebsd.org] On Behalf Of Barbara
 Sent: Monday, January 05, 2009 2:05 PM
 To: br...@box201.com
 Cc: FreeBSD-stable@FreeBSD.org
 Subject: cvsup freebsd 6_2 to freebsd 7_1 not upgrading?
 
 
 
 Messaggio originale
 Da: barbara.xxx1...@libero.it
 Data: 05/01/2009 
 22.01
 A: br...@box201.com, FreeBSD-stable@FreeBSD.org
 Ogg: R: cvsup 
 freebsd 6_2 to freebsd 7_1 not upgrading?
 
 
 Hello List,
 I'm trying to 
 upgrade my system from 6_2 to 7_1 and cannot seem 
 to do it.
 Perhaps I'm 
 missing something. Here is the basic procedure I'm 
 following.
 
 #cp 
 /usr/share/examples/cvsup/standard-supfile /root/stand_sup
 
 #vi 
 /root/stand_sup
 host=CHANGE_ME.freebsd.org
 host=cvsup15.us.FreeBSD.
 
 org
 tag=RELENG_6_2
 tag=RELENG_7_1
 
 #cd /usr/src
 #cvsup -g -L2 
 
 /root/stand_sup
 ...
 #make -j4 buildworld; make -j4 buildkernel; make 
 
 installkernel
 
 ... (come back a hour or so later)
 #make installworld; 
 reboot
 
 
 
 It seems that you have missed to run mergemaster -p before, 
 and 
 mergemaster after running make installworld.
 IMHO, not running 
 mergemaster, 
 you have not updated /etc/motd so it shows 6.2...
 Obviously 
 among the other files.
 And, as pointed by Brooks 
 Davis you should have 
 rebooted before running make installworld

Re: FreeBSD6.2 to 7.1 Remote update

[Brooks Davis]

On Tue, Jan 06, 2009 at 12:52:32AM +0300, l1nyx...@googlemail.com wrote:
 , FreeBSD-stable.
 
 It's real?
 I have one server with hard to access physically.
 
 Can I update him to new release over ssh only?

It's quite possible if you're careful, but there are plenty of ways to
do it wrong.  Make sure to reading the upgrading documentation and the
release notes carefully (especially if you have em* network interfaces).

-- Brooks


pgp7O0PJQMfq0.pgp
Description: PGP signature

Re: dhclient doing DISCOVER with bad IP checksum - bge

[Brooks Davis]

On Mon, Dec 01, 2008 at 12:27:58AM -0800, Jonathan Feally wrote:
 Sorry for the cross-post, but this could be either lists problem.
 
 I have 2 boxes running 7-STABLE as of 20081130, both i386 SMP. One is 
 running ISC DHCPD 3.0.x from recent ports, and the other dhclient from make 
 world.
 
 The server is refusing to answer the DISCOVER request, as it thinks the IP 
 checksum is wrong, which tcpdump also confirms. Other DHCP clients are 
 working fine on this network, so I do not believe it to be the network, 
 server or dhcpd.
 
 Server is running a 2 Port Intel card - em driver.
 
 Client is a Dell PE1750 with 2 onboard NIC's - bge driver.
 
 I have tried turning off both RXCSUM and TXCSUM on both the client and 
 server machines with no luck. I also tried the second NIC on the server 
 with the same result.
 
 This setup was working just a couple of weeks ago, and the only thing that 
 has changed is updating the src for a make world. PXE booting this server 
 does result in an IP being issued, so it is pointing towards something 
 new/changed in 7-STABLE.
 
 I have attached a 3 packet dump of the DISCOVER requests.
 
 Can anybody shed some light on this for me?

Where are you running tcpdump?  If on the host with the bge0 device,
the checksums are probably useless due to checksum offloading.  They
should be valid on the server end of things.

You might try disabling checksum offloading on the nic and see if that
changes the results.

It's possible the change to bpf.c to send packets through a socket when
reassociateing isn't working correctly in that case.  You might try
backing out this change and seeing if the problem goes away (this will
cause problems on some networks).

http://svn.freebsd.org/viewvc/base/stable/7/sbin/dhclient/bpf.c?revision=178675view=markup

-- Brooks


pgpFJmm7bBQZt.pgp
Description: PGP signature

Re: Fwd: FreeBSD 7.1 Content

[Brooks Davis]

On Sun, Sep 07, 2008 at 08:06:24AM -0400, Randy Pratt wrote:
 The ports tree distribution tarball provided on the installation disks
 is another area that needs some consideration.  I suspect that many
 people aren't aware of the need for adoption:
 
   http://myfreebsd.homeunix.net/hints_n_kinks/adoptportstree.html
 
 Is it possible to provide/install the necessary file(s) along with
 the ports tree such that cvsup/csup would be aware of the files
 installed so that obsolete files can be removed when updating the ports
 tree?  The same situation probably exists for the source tree
 and the documentation tree.  Would it just be a matter of installing
 the appropriate checkouts.cvs:. files when the sources are
 installed?
 
 I've only done the adoption process one time and decided that its
 easier to just csup a new trees right after booting the new system.

IMO, an even better (but complementary) approach would be to have
/usr/ports be a valid portsnap extraction and give users the option to
bootstrap /var/db/portsnap.  In general I'm finding it to be a much better
approach.

At this point I'm mostly using cvsup for development.  I literally check
out a separate ports tree on boxes I do ports development on and keep
the main tree up to date with portsnap.  I also use freebsd-update to
manage most of my servers at work even ones with custom kernels (just
let it update /usr/src and don't let it update the kernel).

 Additionally, I've never seen a clear way of synchronizing a
 local ports tree to that used to create the LATEST packages. I've
 had to resort to building my own package sets for the slow boxes
 on the network.  I realize that this aspect diverges from the
 subject of this thread but I do think some more thought should
 be given to this aspect.

With cvs there probably isn't a cost effective way to indicate this
(though I suppose the package collections could include a file with a
cvsup date string in them).

-- Brooks


pgpeZXRWGle0u.pgp
Description: PGP signature

Re: machine hangs on occasion - correlated with ssh break-in attempts

[Brooks Davis]

On Thu, Aug 21, 2008 at 10:10:42PM +0200, Rink Springer wrote:
 On Thu, Aug 21, 2008 at 01:03:09PM -0700, Jeremy Chadwick wrote:
  Finally, consider moving to pf instead, if you really feel ipfw is
  what's causing your machine to crash.  You might be pleasantly surprised
  by the syntax, and overall administrative usability (it is significantly
  superior to ipfw, IMHO).
 
 In fact, pf can already do this out-of-the-box, by doing something like:
 
 table sshlusers persist
 pass quick on $wan_if proto tcp from any to any port ssh flags S/SA keep
 state \
  (max-src-conn 15, max-src-conn-rate 5/3, overload sshlusers flush
 global)
 
 If that is not an option, I have found that security/denyhosts works
 pretty well too (it just adds IP's to /etc/hosts.deniedssh, and
 host_access(5) denies them based on this)

You almost certainly don't want to rate limit ssh connections, only failed
ones.  If you rate limit connections and use svn, you're likely to lock your
self out.

-- Brooks


pgpCGEoUtGw9W.pgp
Description: PGP signature

Re: infrastructure

[Brooks Davis]

On Tue, Jul 29, 2008 at 10:27:37AM +1000, Aristedes Maniatis wrote:
 How do I get in touch with FreeBSD infrastructure people about mailing list 
 set up? Sorry to post here, but I've scoured the web site and cannot find 
 anything more appropriate. Is there a [EMAIL PROTECTED] or 
 something similar?
 
 I tried [EMAIL PROTECTED] in relation to the specific question I 
 had, but that address bounced, even though mailman has it advertised as the 
 owner address for the list in question.

You can always address questions about e-mail to [EMAIL PROTECTED]

-- Brooks

 
 Thanks
 Ari Maniatis
 
 
 
 
 --
 ish
 http://www.ish.com.au
 Level 1, 30 Wilson Street Newtown 2042 Australia
 phone +61 2 9550 5001   fax +61 2 9550 4001
 GPG fingerprint CBFB 84B4 738D 4E87 5E5C  5EFA EF6A 7D2E 3E49 102A
 
 
 ___
 freebsd-stable@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/freebsd-stable
 To unsubscribe, send any mail to [EMAIL PROTECTED]
 


pgpEiqkEYN99B.pgp
Description: PGP signature

Re: dhclient and resolv.conf.sav

[Brooks Davis]

On Fri, Jul 11, 2008 at 08:32:49AM +0200, Willy Offermans wrote:
 Dear FreeBSD friends,
 
 Is this behavior, related to dhclient and /etc/resolv.conf.sav, FreeBSD
 specific or is it a general feature of dhclient? I might have a use for
 it on my debian linux laptop.

We picked it up from openbsd when we took their client (which is derived from
an early ISC client).  If it's not in the stock isc dhclient-script adding it
would be trivial.

-- Brooks

 On Thu, Jul 10, 2008 at 11:57:41AM -0500, Brooks Davis wrote:
  On Thu, Jul 10, 2008 at 10:52:35AM +0200, Patrick M. Hausen wrote:
   Hello,
   
   we have been bitten by something that obvoiusly
   is a feature, not a bug, but I do not quite understand
   the intentions and reasoning behind it.
   
   I have a host with manual interface and resolver configuration
   and an additional interface that should get it's IP address
   via DHCP. But only it's IP address and netmask, nothing else.
   
   The DHCP server used hands out only IP addresses/netmasks,
   no domain-name-servers, domain-name, etc. configured.
   
   Yet, if there happens to exist a /etc/resolv.conf.sav file,
   every renewal of the lease by dhclient overwrites the contents
   of /etc/resolv.conf with those of resolv.conf.sav.
   
   In my particular case the .sav file contained an internal
   nameserver that was used when I initially set up the host
   in the lab. This entry was of no use to the server after
   it had been deployed in our datacenter.
   
   Can anyone shed some light on the intended mechanism?
   Studying the dhclient-script was not too helpful, either.
  
  I suspect the theory is that you can have a static resolv.conf around
  that gets installed when there isn't anything else to use.  In practice,
  I think it mostly causes problems.  I'm somewhat tempted to remove the
  creation of the file and add something like a resolv.conf.default in
  it's place.
  
  -- Brooks
 
 
 
 -- 
 Met vriendelijke groeten,
 With kind regards,
 Mit freundlichen Gruessen,
 De jrus wah,
 
 Willy
 
 *
 Dr. W.K. Offermans
 CAT Postdoctoral Fellow
 CAT Catalytic Center
 Institut f?r Technische und Makromolekulare Chemie
 RWTH Aachen
 Worringerweg 1, Raum 38C-150
 D-52074 Aachen, Germany
 Phone:  +49 241 80 28592
 Home:   +31 45 544 49 44
 Mobile: +31 653 27 16 23
 e-mail: [EMAIL PROTECTED]
 e-mail: [EMAIL PROTECTED]
 
Powered by 
 
 (__)
  \\\'',)
\/  \ ^
.\._/_)
 
www.FreeBSD.org
 


pgpYOWYHO1u9U.pgp
Description: PGP signature

Re: dhclient and resolv.conf.sav

[Brooks Davis]

On Thu, Jul 10, 2008 at 10:52:35AM +0200, Patrick M. Hausen wrote:
 Hello,
 
 we have been bitten by something that obvoiusly
 is a feature, not a bug, but I do not quite understand
 the intentions and reasoning behind it.
 
 I have a host with manual interface and resolver configuration
 and an additional interface that should get it's IP address
 via DHCP. But only it's IP address and netmask, nothing else.
 
 The DHCP server used hands out only IP addresses/netmasks,
 no domain-name-servers, domain-name, etc. configured.
 
 Yet, if there happens to exist a /etc/resolv.conf.sav file,
 every renewal of the lease by dhclient overwrites the contents
 of /etc/resolv.conf with those of resolv.conf.sav.
 
 In my particular case the .sav file contained an internal
 nameserver that was used when I initially set up the host
 in the lab. This entry was of no use to the server after
 it had been deployed in our datacenter.
 
 Can anyone shed some light on the intended mechanism?
 Studying the dhclient-script was not too helpful, either.

I suspect the theory is that you can have a static resolv.conf around
that gets installed when there isn't anything else to use.  In practice,
I think it mostly causes problems.  I'm somewhat tempted to remove the
creation of the file and add something like a resolv.conf.default in
it's place.

-- Brooks


pgpBKgwLnvRdw.pgp
Description: PGP signature

Re: 6.3 stability and freebsd-update (was: Re: challenge: end of life for 6.2 is premature with buggy 6.3)

[Brooks Davis]

On Fri, Jun 06, 2008 at 11:34:01AM -0800, Royce Williams wrote:
  On Jun 4, 2008, at 4:43 PM, Clifton Royston wrote:
 
   Speaking just for myself, I'd love to get a general response from
  people who have run servers on both as to whether 6.3 is on average
  more stable than 6.2.  I really haven't gotten any clear impression as
 
 6.3 has been stable for me.  I've been running since April on DL380
 G2, Dell 2450, Supermicro 5015M-MF and 5015T-PR, and some older Intel
 815E boards.  My bge(4) NICs are detected as Broadcom BCM5703 A2 and
 BCM5704 A2, with no issues.  Running gmirror with no issues.
 
 Someone mentioned freebsd-update earlier in the thread.  I'd like to
 take a moment to plug it, since making it easy to move to 6.3 seems
 topical.  I got a little long-winded, so here's an executive summary:
 
 freebsd-update is good; business case for more hardware; updating in
 'hybrid' mode with custom kernels and stock userland; using kernel
 config 'includes' to save additional effort.
 
 
 I prefer freebsd-update over the buildworld and then
 installworld-over-NFS routine, centralized rsyncs, or anything else.
 I used freebsd-update to uplift the systems above, and also just
 bumped sixteen more from 6.2.  Worked like a charm.  Its 'rollback'
 option is also very handy, for obvious reasons.
 
 Based on how much time I save with freebsd-update, I can make a
 business case for buying another box for a farm, rather than rolling
 my own kernels and eking out xx% of additional performance.  Once ULE
 gets into 7.x-RELEASE, I probably won't even have to do that.
 
 For systems that require a custom kernel, we still patch everything
 else with freebsd-update.  When freebsd-update detects the non-stock
 kernel, it warns you to install a kernel from the target release.  If
 that scares you, you can swap in a stock kernel from the current
 release (saved off, or from the release media or FTP) and then
 upgrade.  When finished, save off the new stock kernel for future
 upgrades, and then rebuild your custom kernel.  (Anybody else doing
 anything like this, or something better?)

Alternativly, you can edit freebsd-update.conf and tell it to not update your
kernel on those machines.

You can also exclude particular files.  We use this to keep from
updating libc directly on some machines where we're using modified RPC
timings to improve NIS performance in the face of occataionl packet
loss.

-- Brooks

 GENERIC or PAE or whatever).  If you use nocpu, nooptions,
 nomakeoptions, nodevice etc. to turn off what you don't need, your
 config is reduced to a 'diff' of sorts against the stock config.  Our
 kernel configs are now ~17 lines, can be grokked at a glance, and
 should change little from release to release.  Here's a stub of an
 example that uses most of the knobs:
 
 include SMP# Inherit SMP (which inherits GENERIC).
 
 nocpu   I486_CPU   # Disable old CPU support; see tuning(7).
 nocpu   I586_CPU
 ident   SMP-GENERIC_CUSTOM_FOO  # Inherit ident, custom name.
 
 nomakeoptionDEBUG  # Do not build with gdb(1) debug symbols.
 
 nooptions   SCHED_4BSD # Do not use the 4BSD scheduler;
 options SCHED_ULE  #   use ULE schedule instead.
 
 # ALTQ support
 options ALTQ
 options ALTQ_CBQ   # Class Bases Queuing (CBQ)
 options ALTQ_RED   # Random Early Detection (RED)
 options ALTQ_RIO   # RED In/Out
 options ALTQ_HFSC  # Hierarchical Packet Scheduler (HFSC)
 options ALTQ_PRIQ  # Priority Queuing (PRIQ)
 options ALTQ_NOPCC # Required for SMP build
 
 # Devices for pf
 device  pf # PF
 device  pflog  # pflog
 device  pfsync # pfsync
 
 
 Use 'nodevice' to turn off devices worth leaving out, but only as many
 as are worth the effort.
 
 If you haven't already considered freebsd-update, either for the whole
 system or just userland, I highly recommend it.  These days, the gain
 has to be pretty significant for me to want to go back to making
 world.  For our PXE installs using custom install.cfg, we can go from
 bare metal to a fully patched vanilla system in four minutes on modern
 hardware!  The novelty of that still hasn't worn off. :-)
 
 It's more efficient (and probably safer?) to use freebsd-update
 against a binary install rather than against local compilation.  And
 if you're bumping major versions (6.x - 7.x), you still have to
 rebuild your ports.  But try it in your lab or for your next
 deployment.  You can easily convert a freebsd-updated system to a
 makeworld system, if necessary.
 
 And thanks again, Colin!
 
 Royce
 
 -- 
 Royce D. Williams   - http://royce.ws/
   Inspiration exists, but it has to find us working. - Pablo Picasso
 ___
 freebsd-stable@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/freebsd-stable
 To unsubscribe, send any mail to [EMAIL 

Re: Two DHCP servers

[Brooks Davis]

On Tue, Apr 22, 2008 at 02:09:06PM +0200, Szemer?dy G?bor wrote:
 Hello!
 We have a DHCP server listening on subnet 192.168.42.0. (On the server with 
 address 192.168.42.1)
 One of the addresses , lets say 192.168.42.11 , we plan to use as a LTSP 
 server for thin clients.
 So we installed the second network interface card with the address 
 192.168.0.254 and our server (192.168.42.11) now connects to the internet 
 via interface 192.168.42.0 segment , and the thin clients are connected to 
 to this server via subnet 192.168..0.0. In Ltsp server there is a DHCP 
 server which is listening on subnet 192.168.0.0.
 Will these two DHCPs generate a conflict?

I found your description very confusing, but I belive there were will no
conflict as long as they are on physically different networks.

-- Brooks


pgp4ns31GcMv2.pgp
Description: PGP signature

Re: QA on textdumps (fwd)

[Brooks Davis]

On Tue, Apr 01, 2008 at 12:57:06PM +0100, Robert Watson wrote:
 
 Dear all,
 
 I've now completed the MFC of basic textdump support to 7.0.  Once I've had 
 a chance to ping Brooks about it, either he or I will MFC support for 
 ddb.conf, which allows configuring textdump and debugging scripts 
 automatically at boot. I've attached a QA post I made to current@ after 
 committing textdump support to HEAD, and you can also consult textdump(4) 
 and ddb(4) for more information.

I've MFC'd support for reading ddb.conf at boot.

-- Brooks

 Thanks,
 
 Robert N M Watson
 Computer Laboratory
 University of Cambridge
 
 -- Forwarded message --
 Date: Sun, 30 Dec 2007 13:11:29 + (GMT)
 From: Robert Watson [EMAIL PROTECTED]
 To: [EMAIL PROTECTED]
 Subject: QA on textdumps
 
 
 Dear all,
 
 I've received a few textdump-related questions that I thought I'd share my 
 answers to.
 
 (1) What information is in a textdump?
 
 The textdump is stored as a tarfile with several subfiles in it:
 
 config.txt - Kernel configuration, if compiled into kernel
 ddb.txt - Captured DDB output, if present
 msgbuf.txt - Kernel message buffer
 panic.txt - Kernel panic message, if there was a panic
 version.txt - Kernel version string
 
 It is easy to add new files to textdumps, so if there's some easily 
 extractable kernel state that you feel should go in there, drop me an 
 e-mail and/or send a patch.
 
 (2) Is there any information in a textdump that can't be acquired using 
 kgdb and other available dump analysis tools?
 
 In principle no, as normal dumps include all kernel memory, and textdumps 
 operate by inspecting kernel memory using DDB, capturing only small but 
 presumably relevant parts.  However, there are some important differences 
 in approach that mean that textdumps can be used in ways that regular dumps 
 can't easily be:
 
 - DDB textdumps are very small. Including a full debugging session, kernel 
 message buffer, and kernel configuration, my textdumps are frequently 
 around 100k uncompressed. This makes it possible to use them on very small 
 machines, store them for an extended period, e-mail them around, etc, in a 
 way that you can't currently do with kernel memory dumps. This improved 
 usability will (hopefully) improve our bug and crash management.
 
 - DDB is a specialized debugging tool with intimate knowledge of the 
 kernel, and there are types of data trivially extracted with DDB that are 
 awkward or quite difficult to extract using kgdb or other currently 
 available dump analysis tools. Locking, waiting, and process information 
 are examples of where automatic extraction is currently only possible with 
 DDB, and one of the reasons many developers prefer to begin any diagnosis 
 with an interactive DDB session.
 
 - DDB textdumps can be used without the exact source tree, kernel 
 configuration, built kernel, and debug symbols, as they interpret rather 
 than save the pages of memory. They're even an architecture-independent 
 file format so you don't need a cross-debugger. Having that additional 
 context is useful (ability to map symbol+offset to line of code), but you 
 can actually go a remarkable way without it, especially looking at the 
 results in a PR potentially years later.
 
 (3) What do I lose by using textdumps?
 
 To be clear, there are also some important things that textdumps can't do 
 -- principally, a textdump doesn't contain all kernel memory, so your 
 textdump output is all you have. If you need to extract detailed structure 
 information for something DDB doesn't understand, or that you don't think 
 of in advance or during a DDB session, then there's nothing to fall back on 
 except configuring a textdump or regular dump and waiting for the panic to 
 happen again.
 
 (4) When should I use textdumps?
 
 Minidumps remain the default in 7.x and 8.x, and full dumps remain the 
 default in 6.x and earlier. Textdumps must be specifically enabled by the 
 administrator to be used.
 
 DDB is an excellent live debugging tool whose use has been limited to 
 situations where there is an accessible video console, or more ideally 
 serial or firewire console to a second box, and generally requiring an 
 experienced developer to be available to drive debugging. There are many 
 problems that can be pretty much instantly understood with a couple of DDB 
 commands, so these limitations impacted debugging effectiveness.
 
 The goal of adding DDB capture output, scripting, and textdumps was to 
 broaden the range of situations in which DDB could be used: now it is 
 usable more easily for post-mortem analysis, no console or second machine 
 is required, and a developer can install, or even e-mail, a script of DDB 
 commands to run automatically. Developers can simply define a few scripts 
 to handle various DDB cases, such as panic, and get a nice debugging bundle 
 to look at later.
 
 When I'm debugging network stack problems, I typically want a fairly small 
 set 

Re: CVS tag for 7.0 - standard

[Brooks Davis]

On Wed, Oct 31, 2007 at 10:18:26AM -0600, JD Bronson wrote:
 Can someone kindly tell me the CVS tag to follow the 7.0 patch branch 
 (only)?
 
 I am running 7.0Beta1 and want  to stay with that only. Nothing newer like 
 the 'stable' branch.
 
 It seems that the tag I am using is 7.0-stable?
 
 *default release=cvs tag=RELENG_7

At this time RELENG_7 is what there is.  At some point in the future the
release branch will be created at RELENG_7_0, but that has not happened
yet.

-- Brooks


pgpFU6uDmaP08.pgp
Description: PGP signature

Re: rrdtool performance tuning (fwd)

[Brooks Davis]

On Tue, Oct 30, 2007 at 12:32:42PM +0300, Dmitry Morozovsky wrote:
 On Mon, 29 Oct 2007, Brooks Davis wrote:
 
 BD On Mon, Oct 29, 2007 at 11:13:09AM +0300, Dmitry Morozovsky wrote:
 BD  
 BD  [hmm, after thinking a bit I decided it would be more appropriate here, 
 in 
 BD  [EMAIL PROTECTED]
 BD  
 BD  Dear colleagues,
 BD  
 BD  any hints to tune rrdtool with ~30k rrd files (approx 2k target 
 devices)?
 BD  
 BD  machine is mostly IO-bound, showing 100% disk load with 8 or sometimes 
 even 3 
 BD  mB/s, 300-400 tps (it's 2 SATA300 disks in gmirror)
 BD 
 BD Store it on a memory file system and take periodic snapshots.  The format 
 is
 BD hopeless for large numbers of updates.  The ganglia port's startup 
 scripts show
 BD an example of doing this.
 
 I thought about this, but total size of these files is already more than 
 memory, and I'm not sure md would be suitable for this.

FWIW, this is the only work around ganglia users have found.  You might
consider a solid state disk or one of the battery backed RAM cards
out there if adding more memory and switching to a 64-bit OS isn't an
option.

-- Brooks


pgpwURksOTK87.pgp
Description: PGP signature

Re: rrdtool performance tuning (fwd)

[Brooks Davis]

On Mon, Oct 29, 2007 at 11:13:09AM +0300, Dmitry Morozovsky wrote:
 
 [hmm, after thinking a bit I decided it would be more appropriate here, in 
 [EMAIL PROTECTED]
 
 Dear colleagues,
 
 any hints to tune rrdtool with ~30k rrd files (approx 2k target devices)?
 
 machine is mostly IO-bound, showing 100% disk load with 8 or sometimes even 3 
 mB/s, 300-400 tps (it's 2 SATA300 disks in gmirror)

Store it on a memory file system and take periodic snapshots.  The format is
hopeless for large numbers of updates.  The ganglia port's startup scripts show
an example of doing this.

-- Brooks


pgpdZUVvB0oQV.pgp
Description: PGP signature

Re: Background process

[Brooks Davis]

On Thu, Mar 08, 2007 at 02:03:24PM +0100, [EMAIL PROTECTED] wrote:
 Hello,
 
 I connect to my freebsd box via ssh using putty from a WindowsXP
 workstation, I want to run a process on the freebsd box, then close my ssh
 session (closing putty) while keeping the process running.
 
 So I run my process like this : # myprogram , then I exit the shell.
 
 But when I do that, I can see with ps that my process go from TT p0 to
 TT p0- and the application doesn't work anymore. For information, the
 program I want to be able to run via ssh then close the ssh session is the
 moinmoin wiki which is a wiki written in python.
 
 In man ps I can see that the trailing - after p0 means my process can
 no longer reach the controlling terminal... But what can I do to achieve
 my goal ?

I believe what you are looking for is nohup(1).

-- Brooks


pgpHT3NtMm88J.pgp
Description: PGP signature

Re: install on USB flash memory

[Brooks Davis]

On Wed, Feb 14, 2007 at 01:47:03PM +0200, Todorov @ Paladin wrote:
 Karel Miklav :
  Jeremy Chadwick wrote:
   I think this has been discussed before.  The problem is that FreeBSD's
   bootloader doesn't support booting off of such devices, thus you
   need to use GRUB or another bootloader.
 
  But the guy from tutorial is doing that, and I made such a stick too.
  And it boots on ThinkPad X40 perfectly.
 
 What is the USB protocol version on the X40. My previous laptop R40e had
 USB 1.1 interfaces. Maybe it is the USB version

The X40 supports USB 2.0, but is seems highly unlikely that's the issue.

-- Brooks


pgp70fc5exJdx.pgp
Description: PGP signature

Re: Desired behaviour of ifconfig -alias

[Brooks Davis]

On Mon, Feb 12, 2007 at 03:26:18PM +0100, Oliver Fromme wrote:
 JoaoBR [EMAIL PROTECTED] wrote:
   Brooks Davis wrote:
Jeremy Chadwick wrote:
 Kevin Way wrote:
  I recently ran into a bug in the jail startup scripts that caused 
 this
  command to be executed:
  
  ifconfig bce0 -alias
  
  It turns out that this command eliminated the primary IP for the
  device.
  
   

It's way to late to make this change.  This is known behavior and has
been for ages.  If there's a bug it's in the documentation.
   
   wellwell, we also were apes for ages but does not mean that we stay 
 behaving
   like them  and if some still does so it is also never to late to change
   that  ;)
 
 Changing the behaviour of tools always involves a certain
 danegr of breaking existing script.  That's especially true
 for symstem administration commands such as ifconfig that
 are running in automated scripts, and people depend on them
 for booting their machines remotely.
 
 I'm not saying that people are intentionally using that
 syntax ...  Maybe they are, maybe not.  But you also should
 take into accounts that there might be scripts that use the
 syntax inadvertantly and happen to work correctly because
 of the current behaviour.
 
 I'm also _not_ saying that the behaviour must not be changed
 at all.  But it should be done carefully, i.e. first to
 -current, with proper heads up warnings.  Don't change
 it in RELENG_6 without warning and expect evrybody to be
 happy.

This is the point I attempted to make and failed at earlier.  The
general policy would be that we could change it to fail in current, but
doing more than emitting a warning in STABLE would be risky.

-- Brooks


pgp68GwiAI36b.pgp
Description: PGP signature

Re: Desired behaviour of ifconfig -alias

[Brooks Davis]

On Mon, Feb 12, 2007 at 05:22:22PM +0100, Oliver Fromme wrote:
 Jeremy Chadwick wrote:
   Oliver Fromme wrote:
   FWIW, I still use alias/-alias.  Mainly because that's what has
   existed historically, and the term alias is what is used in
   reference to rc.conf ifconfig_iface_aliasX entries.
 
 Maybe it would make sense to remove alias from the rc.conf
 entries and simply number them.

ipv4_addrs_interface is a much better replacement IMO.  It's easy to
use and doesn't required the hackish pseudo array traversal used by
ifconfig_iface_aliasX.

-- Brooks


pgpjd84JGIqz7.pgp
Description: PGP signature

Re: Desired behaviour of ifconfig -alias

[Brooks Davis]

On Mon, Feb 12, 2007 at 06:39:35PM +0100, Oliver Fromme wrote:
 Brooks Davis wrote:
   Oliver Fromme wrote:
Jeremy Chadwick wrote:
 Oliver Fromme wrote:
 FWIW, I still use alias/-alias.  Mainly because that's what has
 existed historically, and the term alias is what is used in
 reference to rc.conf ifconfig_iface_aliasX entries.

Maybe it would make sense to remove alias from the rc.conf
entries and simply number them.
   
   ipv4_addrs_interface is a much better replacement IMO.  It's easy to
   use and doesn't required the hackish pseudo array traversal used by
   ifconfig_iface_aliasX.
 
 That might work for simple cases, but how do you specify
 other parameters beside the IPs if you need to?

What do you need to set?  It's sets IP and netmask.  It doesn't handle
broadcast, but I'd be pretty suprised if that's needed often.  What else
is needed?  Axing ifconfig_iface_aliasX is not needed, but reducing the
visiability of the interface in the documentation is probably in order
particularly since it's quite fragile since you have to renumber whenever
you remove an entry.

-- Brooks


pgpqE8HaqK79J.pgp
Description: PGP signature

Re: Desired behaviour of ifconfig -alias

[Brooks Davis]

On Mon, Feb 12, 2007 at 07:23:33PM +0100, Oliver Fromme wrote:
 Brooks Davis wrote:
   Oliver Fromme wrote:
Brooks Davis wrote:
 ipv4_addrs_interface is a much better replacement IMO.  It's easy to
 use and doesn't required the hackish pseudo array traversal used by
 ifconfig_iface_aliasX.

That might work for simple cases, but how do you specify
other parameters beside the IPs if you need to?
   
   What do you need to set?  It's sets IP and netmask.  It doesn't handle
   broadcast, but I'd be pretty suprised if that's needed often.
 
 True, not often, but sometimes.  I had cases like that in
 certain environments with bridged networks and arp proxies.
 
 I'm fine with your proposed syntax, as long as all the
 existing ifconfig possibilities continue to be possible,
 i.e. no regression.

FWIW, it's HEAD and 6.1.  We've actually got the aliases syntax labled
as deprecated in the manpage.  We might want to add a feature to set the
broadcast address.

   is needed?  Axing ifconfig_iface_aliasX is not needed, but reducing the
   visiability of the interface in the documentation is probably in order
   particularly since it's quite fragile since you have to renumber whenever
   you remove an entry.
 
 Yup, I agree, that's a PITA.  That could be solved in the
 shell code, though, by not enumerating until a number
 doesn't exist, but instead looking at the set of all
 shell variables that have been set, similar to this:
 
 set | grep ^ifconfig_${IFACE}_alias | cut -f1 -d= | ...

Unfortuanly grep in in /usr/bin so can't be used.  You could do it
with sh variable mangling and case though.  Something like:

{ while read _var; do
_var=${_var%%=*}
case $_var in
ifconfig_${IFACE}_alias*)
...
;;
esac
done }  `set`

-- Brooks


pgpb032iAXeAy.pgp
Description: PGP signature

Re: Desired behaviour of ifconfig -alias

[Brooks Davis]

On Mon, Feb 12, 2007 at 11:07:39AM -0800, Jeremy Chadwick wrote:
 On Mon, Feb 12, 2007 at 11:59:40AM -0600, Brooks Davis wrote:
  What do you need to set?  It's sets IP and netmask.  It doesn't handle
  broadcast, but I'd be pretty suprised if that's needed often.  What else
  is needed?  Axing ifconfig_iface_aliasX is not needed, but reducing the
  visiability of the interface in the documentation is probably in order
  particularly since it's quite fragile since you have to renumber whenever
  you remove an entry.
 
 Does it support media and mediaopt arguments?  These are very
 commonly used.  I also rely on this, for what it's worth:
 
 openvpn_enable=yes
 openvpn_configfile=/conf/ME/openvpn/openvpn.conf
 openvpn_dir=/conf/ME/openvpn
 openvpn_if=tap
 cloned_interfaces=bridge0
 ifconfig_bridge0=addm em1 up

Setting media options and the like via _aliasesX variables makes no
sense and you don't appear to be doing it so I'm confused by your
question.  The ifconfig_iface_aliasX syntax exists to add IPv4 addresses
to an interface. New ipv4_addrs_iface variable is an attempt to replace
that and nothing more.

-- Brooks


pgpDJbRFRO3nm.pgp
Description: PGP signature

Re: Desired behaviour of ifconfig -alias

[Brooks Davis]

On Mon, Feb 12, 2007 at 09:06:59PM +0200, John Hay wrote:
 On Mon, Feb 12, 2007 at 11:59:40AM -0600, Brooks Davis wrote:
  On Mon, Feb 12, 2007 at 06:39:35PM +0100, Oliver Fromme wrote:
   Brooks Davis wrote:
 Oliver Fromme wrote:
  Jeremy Chadwick wrote:
   Oliver Fromme wrote:
   FWIW, I still use alias/-alias.  Mainly because that's what has
   existed historically, and the term alias is what is used in
   reference to rc.conf ifconfig_iface_aliasX entries.
  
  Maybe it would make sense to remove alias from the rc.conf
  entries and simply number them.
 
 ipv4_addrs_interface is a much better replacement IMO.  It's easy to
 use and doesn't required the hackish pseudo array traversal used by
 ifconfig_iface_aliasX.
   
   That might work for simple cases, but how do you specify
   other parameters beside the IPs if you need to?
  
  What do you need to set?  It's sets IP and netmask.  It doesn't handle
  broadcast, but I'd be pretty suprised if that's needed often.  What else
  is needed?  Axing ifconfig_iface_aliasX is not needed, but reducing the
  visiability of the interface in the documentation is probably in order
  particularly since it's quite fragile since you have to renumber whenever
  you remove an entry.
 
 Some stuff cannot be done on a single line, so I have abused the _aliasX
 mechanism for that. With the bridge interface:
 
 ifconfig_bridge0=ether 00:00:24:c0:0e:40 addm sis0 stp sis0 addm sis1 stp 
 sis1 up
 ifconfig_bridge0_alias0=inet 146.64.84.1/24

ipv4_addrs_bridge0=146.64.84.1/24 :)

 Also with the atheros driver I had problems in the past with some parameters
 that did not like to be on a single commandline.

I do agree there's some need for a way to pass multiple sets of
parameters to ifconfig since this has commonly been a problem.
Something actually designed for that might be nice. :)

-- Brooks


pgpjPsFNS9Bsi.pgp
Description: PGP signature

Re: Desired behaviour of ifconfig -alias

[Brooks Davis]

On Tue, Feb 13, 2007 at 02:37:53AM +0100, Joerg Pernfuss wrote:
 On Mon, 12 Feb 2007 19:18:54 -0300
 JoaoBR [EMAIL PROTECTED] wrote:
 
  I believe the problem here is that
  
  ifconfig_nic=inet IP
  ifconfig_nic=ether MAC
  
  does not work on one line and does not work on two either, the latter 
  overrides and or you get an IP address with original MAC or you get a
  new MAC without IP.
 
 Yes, you have to put 'ifconfig nic ether MAC' in /etc/start_if.nic
 for this to work afair. Same approach you need to set WEP etc on a
 wireless nic if you have ifconfig_nic=DHCP in your rc.conf.

The second is no longer true.  DHCP (like WPA) is a magic keywork that
tells the system to run DHCP on the interface and is not passwd to
ifconfig so the line can contain other things.

-- Brooks


pgp0uewPFgzQe.pgp
Description: PGP signature

Re: Desired behaviour of ifconfig -alias

[Brooks Davis]

On Fri, Feb 09, 2007 at 01:49:08PM -0800, Jeremy Chadwick wrote:
 On Fri, Feb 09, 2007 at 04:06:56PM -0500, Kevin Way wrote:
  I recently ran into a bug in the jail startup scripts that caused this
  command to be executed:
  
  ifconfig bce0 -alias
  
  It turns out that this command eliminated the primary IP for the device.
  
  man ifconfig defines the behavior of -alias to be:
  
   -alias  Remove the network address specified.  This would be used
  if you
   incorrectly specified an alias, or it was no longer needed.  If
   you have incorrectly set an NS address having the side
  effect of
   specifying the host portion, removing all NS addresses will
  allow
   you to respecify the host portion.
  
  
  I can't help but wonder if it would be better behavior to throw an error
  when no
  argument is supplied.
  
  The only discussion I found of this in a quick search of the archives
  was a post in
  2004 which noted that the fxp driver actually deletes all IP addresses,
  but there was
  no significant follow-up.
  
  Should ifconfig throw an error if no address is supplied?
 
 My vote is for either 1) an error, or 2) delete all of the aliases
 associated with that interface.  If I had a preference, I'd choose #1.
 
 I'd argue that -alias doing what you described (removing the non-aliased
 IP bound to the iface) when no inet/inet6 arguments are suppied is
 indeed a bug.

It's way to late to make this change.  This is known behavior and has
been for ages.  If there's a bug it's in the documentation.

-- Brooks


pgpJSwTuBuQil.pgp
Description: PGP signature

Re: dhclient taking up all CPU

[Brooks Davis]

It doesn't effect nearly enough people to warrent a commit to the eratta
branch.  It's also not serious enough; the bar has typically been set at
the level of data corruption bugs.

-- Brooks

On Mon, Nov 06, 2006 at 02:20:42PM +0100, Spil Oss wrote:
 Hi all,
 
 Rebuilt dhclient with the bpf.c from RELENG_6 ( line 285 == - =)
 According to the cvs commit log this fixes my problem.
 
 Still leaves me wondering why this was not applied to RELENG_6_1
 
 Kind regards,
 
 Spil.
 
 
 On 05/11/06, Brooks Davis [EMAIL PROTECTED] wrote:
 It should be fixed in STABLE.  The particular fixes were to bpf.c so I
 belive (but have not verified) that if you grab the latest version of
 that file, put it in src/sbin/dhclient/ and rebuild dhclient the
 problems will go away.
 
 -- Brooks
 
 On Sun, Nov 05, 2006 at 09:12:25PM +0100, Spil Oss wrote:
  Hi all,
 
  Been experiencing this same behaviour every now-and-then.
 
  FreeBSD/i386 6.1-RELEASE-p10
 
  Any solutions to this?
 
  Kind regards,
 
  Spil.
 
  On 06/05/06, Lodewijk V??ge [EMAIL PROTECTED] wrote:
  hello,
  
  a while ago someone reported the same problem I had been seeing, that
  dhclient starts taking up 100% CPU. it's probably something comcast
  is doing.
  
  I couldn't get the requested coredump then, if I set kern.corefile
  to /tmp/%N.core and kill -QUIT it, it doesn't seem to produce a
  coredump. but it happened again just now, and I was able to attach
  gdb. this is where it's spinning, in receive_packet() in bpf.c:
  
  (gdb)
  285 if (interface-rbuf_offset == interface-
   rbuf_len) {
  (gdb)
  299 if (interface-rbuf_len - interface-
   rbuf_offset 
  (gdb)
  306 memcpy(hdr, interface-rbuf[interface-
   rbuf_offset],
  (gdb)
  313 if (interface-rbuf_offset + hdr.bh_hdrlen +
  hdr.bh_caplen 
  (gdb)
  320 interface-rbuf_offset += hdr.bh_hdrlen;
  (gdb)
  327 if (hdr.bh_caplen != hdr.bh_datalen) {
  (gdb)
  328 interface-rbuf_offset =
  (gdb)
  331 continue;
  (gdb)
  385 } while (!length);
  
  and then it goes back to line 285. interesting variables are:
  
  (gdb) p *interface
  $1 = {next = 0x0, hw_address = {htype = 1 '\001', hlen = 6 '\006',
  haddr = \000\021??\223?\000\000\000\000\000\000\000\000\000},
  primary_address = {s_addr = 0},
name = vr0, '\0' repeats 12 times, rfdesc = 7, wfdesc = 7,
  rbuf = 0x807d000 \022?\\Dk\214, rbuf_max = 4096,
rbuf_offset = 416, rbuf_len = 415, ifp = 0x806f160, client =
  0x8075000, noifmedia = 0, errors = 0, dead = 0, index = 2}
  (gdb) p length
  $2 = 0
  (gdb) p hdr
  $3 = {bh_tstamp = {tv_sec = 0, tv_usec = 0}, bh_caplen = 4294901760,
  bh_datalen = 4294901778, bh_hdrlen = 65535}
  
  this is FreeBSD/i386 6.1-RC as of about two weeks ago.
  
  Lodewijk
  
  ___
  freebsd-stable@freebsd.org mailing list
  http://lists.freebsd.org/mailman/listinfo/freebsd-stable
  To unsubscribe, send any mail to 
 [EMAIL PROTECTED]
  
 
  ___
  freebsd-stable@freebsd.org mailing list
  http://lists.freebsd.org/mailman/listinfo/freebsd-stable
  To unsubscribe, send any mail to [EMAIL PROTECTED]
 
 
 
 
 


pgps9YbfWTZ5I.pgp
Description: PGP signature

Re: dhclient taking up all CPU

[Brooks Davis]

It should be fixed in STABLE.  The particular fixes were to bpf.c so I
belive (but have not verified) that if you grab the latest version of
that file, put it in src/sbin/dhclient/ and rebuild dhclient the
problems will go away.

-- Brooks

On Sun, Nov 05, 2006 at 09:12:25PM +0100, Spil Oss wrote:
 Hi all,
 
 Been experiencing this same behaviour every now-and-then.
 
 FreeBSD/i386 6.1-RELEASE-p10
 
 Any solutions to this?
 
 Kind regards,
 
 Spil.
 
 On 06/05/06, Lodewijk V??ge [EMAIL PROTECTED] wrote:
 hello,
 
 a while ago someone reported the same problem I had been seeing, that
 dhclient starts taking up 100% CPU. it's probably something comcast
 is doing.
 
 I couldn't get the requested coredump then, if I set kern.corefile
 to /tmp/%N.core and kill -QUIT it, it doesn't seem to produce a
 coredump. but it happened again just now, and I was able to attach
 gdb. this is where it's spinning, in receive_packet() in bpf.c:
 
 (gdb)
 285 if (interface-rbuf_offset == interface-
  rbuf_len) {
 (gdb)
 299 if (interface-rbuf_len - interface-
  rbuf_offset 
 (gdb)
 306 memcpy(hdr, interface-rbuf[interface-
  rbuf_offset],
 (gdb)
 313 if (interface-rbuf_offset + hdr.bh_hdrlen +
 hdr.bh_caplen 
 (gdb)
 320 interface-rbuf_offset += hdr.bh_hdrlen;
 (gdb)
 327 if (hdr.bh_caplen != hdr.bh_datalen) {
 (gdb)
 328 interface-rbuf_offset =
 (gdb)
 331 continue;
 (gdb)
 385 } while (!length);
 
 and then it goes back to line 285. interesting variables are:
 
 (gdb) p *interface
 $1 = {next = 0x0, hw_address = {htype = 1 '\001', hlen = 6 '\006',
 haddr = \000\021??\223?\000\000\000\000\000\000\000\000\000},
 primary_address = {s_addr = 0},
   name = vr0, '\0' repeats 12 times, rfdesc = 7, wfdesc = 7,
 rbuf = 0x807d000 \022?\\Dk\214, rbuf_max = 4096,
   rbuf_offset = 416, rbuf_len = 415, ifp = 0x806f160, client =
 0x8075000, noifmedia = 0, errors = 0, dead = 0, index = 2}
 (gdb) p length
 $2 = 0
 (gdb) p hdr
 $3 = {bh_tstamp = {tv_sec = 0, tv_usec = 0}, bh_caplen = 4294901760,
 bh_datalen = 4294901778, bh_hdrlen = 65535}
 
 this is FreeBSD/i386 6.1-RC as of about two weeks ago.
 
 Lodewijk
 
 ___
 freebsd-stable@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/freebsd-stable
 To unsubscribe, send any mail to [EMAIL PROTECTED]
 

 ___
 freebsd-stable@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/freebsd-stable
 To unsubscribe, send any mail to [EMAIL PROTECTED]



pgpTKTQD58wJW.pgp
Description: PGP signature

Re: Ensuring inetd is started before any RPC services

[Brooks Davis]

On Tue, Oct 17, 2006 at 08:46:49AM +0200, Trond Endrest?l wrote:
 I have on many occasions run into the situation where the RPC based 
 services have occupied the well-known ports for other non-RPC based 
 services. Last week rpc.lockd on one of my systems got hold of TCP 
 port 995, leaving inetd unable to start any pop3s services.
 
 The easy cure is to add this line
 
 # BEFORE: rpcbind
 
 to /etc/rc.d/inetd.
 
 You might want to consider fixing /etc/rc.d/inetd prior to the release 
 of 6.2.

I'm pretty sure this change would break inetd's rpc service support and
would change the startup order more significantly than I think is
appropriate this late in the release cycle.

-- Brooks


pgpbQm9W5wG3L.pgp
Description: PGP signature

Re: kernel panic mounting /tmp - 6.2-PRERELEASE

[Brooks Davis]

On Wed, Oct 18, 2006 at 12:25:58AM +1000, Norberto Meijome wrote:
 Hi everyone,
 
 tonight when I started my laptop, i was welcomed with a very nice panic, which
 was happening JUST when mounting the filesystems. 
 
 Some info:
 Fault code : supervisor read, page not present.
 current process : 112 (mount)
 trap 12
 panic :page fault
 
 with nm -m I saw that the following procs where candidates ...
 
 ufsdirhash_build
 ufsdirhas_free
 ufsdirhash_lookup
 
 Booting with 6.1 Release CD and mounting showed no obvious problems at all, 
 but
 the panic could be reproduced every time with this particular kernel (6 days
 old). Commenting out /tmp in fstab worked around the problem.
 
 recreating the filesystem in /dev/ad0s1e (my /tmp) solved the problem and now
 everything is back to normal. The computer works great as usual.
 
 $ uname -a
 FreeBSD ayiin.xxx 6.2-PRERELEASE FreeBSD 6.2-PRERELEASE #14:
 Wed Oct 11 14:13:49 EST 2006
 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/AYIIN  i386
 
 I have a good kernel dump , a copy of /boot/kernel that was being used, and a
 dump (dump -0 -a -f usr/ad0s1e.dump /dev/ad0s1e ) of the /tmp partition at the
 time (before the newfs, of course). Available for anyone interested.
 
 Is there a bigger issue here? anything I can do to help diagnose / debug this?

Possibly and no.  By recreating the file system you've destroyed
the information needed to isolate the cause.  It's known that an
appropriately corrupt file system can do this, but the causes (there are
probably several) are not yet known.  There is some speculation that the
only solution is to add checksums to all key data sections.

-- Brooks


pgpX6Z5Sm6gCs.pgp
Description: PGP signature

Re: Ensuring inetd is started before any RPC services

[Brooks Davis]

On Tue, Oct 17, 2006 at 05:14:22PM +0200, Trond Endrest?l wrote:
 On Tue, 17 Oct 2006 09:39-0500, Brooks Davis wrote:
 
  On Tue, Oct 17, 2006 at 08:46:49AM +0200, Trond Endrest?l wrote:
   I have on many occasions run into the situation where the RPC based 
   services have occupied the well-known ports for other non-RPC based 
   services. Last week rpc.lockd on one of my systems got hold of TCP 
   port 995, leaving inetd unable to start any pop3s services.
   
   The easy cure is to add this line
   
   # BEFORE: rpcbind
   
   to /etc/rc.d/inetd.
   
   You might want to consider fixing /etc/rc.d/inetd prior to the release 
   of 6.2.
  
  I'm pretty sure this change would break inetd's rpc service support and
  would change the startup order more significantly than I think is
  appropriate this late in the release cycle.
 
 Yes, I see your point.
 
 I guess we who never run any RPC services through inetd must make this 
 change ourself, and it's relatively easy to maintain this change when 
 using mergemaster after each installworld. One size does not fit all, 
 not in this case.

It's clear to me that we need a better way to specifying which ports
services that want an arbitrary port can use.  That's probably the long
term solution.

-- Brooks


pgpdyR40ReYwX.pgp
Description: PGP signature

Re: kernel panic mounting /tmp - 6.2-PRERELEASE

[Brooks Davis]

On Wed, Oct 18, 2006 at 07:11:55AM +1000, Norberto Meijome wrote:
 On Tue, 17 Oct 2006 09:59:46 -0500
 Brooks Davis [EMAIL PROTECTED] wrote:
 
   Is there a bigger issue here? anything I can do to help diagnose / debug
   this?  
  
  Possibly and no.  By recreating the file system you've destroyed
  the information needed to isolate the cause.  It's known that an
  appropriately corrupt file system can do this, but the causes (there are
  probably several) are not yet known.  There is some speculation that the
  only solution is to add checksums to all key data sections.
  
  -- Brooks
 
 Gotcha - i thought as much... i hoped a dump -0 would save enough info though.
 I just needed to have /tmp back in place asap
 
 i'll keep the files around for a week or so in case something comes up.

Good thought, but anything short of dd if=/dev/tmpdevices
of=/path/to/some/location probably won't preserve the corrupt bits.
Think of dump as a version of tar that also knows how to read file
systems directly.  It only preserves files and their contents not the
actual file system bits on the disk

-- Brooks


pgp5PDDdtYuVc.pgp
Description: PGP signature

Re: kernel panic mounting /tmp - 6.2-PRERELEASE

[Brooks Davis]

On Wed, Oct 18, 2006 at 08:44:39AM +1000, Norberto Meijome wrote:
 On Tue, 17 Oct 2006 17:33:50 -0500
 Brooks Davis [EMAIL PROTECTED] wrote:
 
   Gotcha - i thought as much... i hoped a dump -0 would save enough info
   though. I just needed to have /tmp back in place asap
   
   i'll keep the files around for a week or so in case something comes up.  
  
  Good thought, but anything short of dd if=/dev/tmpdevices
  of=/path/to/some/location probably won't preserve the corrupt bits.
  Think of dump as a version of tar that also knows how to read file
  systems directly.  It only preserves files and their contents not the
  actual file system bits on the disk
 
 Yes, I realise that now, it was late and I wasn't thinking too straight
 obviously.

 BTW, the mount in 6.1-RELEASE CD had no issue at all mounting the filesystem..
 dump I used was 6.1-RELEASE too . would have  been user land app related, or
 actual UFS kernel code that made the difference? 

That's somewhat distrubing.  That sounds like a change to the UFS code
somehow made things more fragile, though it could be an access pattern
issue of some sort.

-- Brooks


pgpFAkZ9X54D0.pgp
Description: PGP signature

Re: scp -c none (was Re: NFS client slow on amd64 6.2-PRERELEASE #2)

[Brooks Davis]

On Sun, Oct 08, 2006 at 11:05:55AM -0400, Brandon S. Allbery KF8NH wrote:
 
 On Oct 8, 2006, at 10:54 , Oliver Fromme wrote:
 
 Jeremy Chadwick [EMAIL PROTECTED] wrote:
 [...]
 It's really too bad the OpenBSD guys refuse to
 incorporate the HP (high-performance) patches into OpenSSH, and
 being able to say -c none would *really* help when it comes to
 benchmarking network I/O via scp
 
 I considered submitting the patch for official inclusion,
 but the OpenSSH people would reject it because they call
 it insecure, and the FreeBSD people would reject it
 because they say the patch should be submitted to the
 OpenSSH people.  *sigh*  :-(
 
 Actually, the openssh-portable folks are keeping an eye on the hpn  
 patches, but those are still evolving so PSC isn't willing to submit  
 them for inclusion.  Try searching the openssh list for discussion  
 about it.

The HPN patches are an available option in the port.

Intrestingly the HPN patches demonstrate that crypto overhead isn't all
the significant with modern hardware unless you're pretty close to
1Gbps.

-- Brooks


pgpyoLb9FFAq2.pgp
Description: PGP signature

Re: Recommendations for a serial port card you can actually BUY?

[Brooks Davis]

On Fri, Oct 06, 2006 at 11:33:13AM +1000, Greg Black wrote:
 On 2006-10-05, Brooks Davis wrote:
  On Thu, Oct 05, 2006 at 07:09:56PM -0500, Karl Denninger wrote:
   On Thu, Oct 05, 2006 at 04:04:47PM -0500, Brooks Davis wrote:
On Thu, Oct 05, 2006 at 03:21:44PM -0500, Karl Denninger wrote:
 
 FreeBSD's USB support has always been somewhat deficient.  For 
 example,
 apcupsd can't talk to their UPSs over the USB bus, even though the 
 software
 itself knows how, because FreeBSD doesn't know what a UPS is and 
 throws up
 its hands when you plug it in.

This is false for at least the APC SmartUPS the machine I'm sending this
from is connected to.  I wouldn't be suprised if it was true once, but
it isn't today.

ugen0: American Power Conversion Smart-UPS 750 FW:651.12.D USB FW:4.2, 
rev 1.10/0.06, addr 2
   
   Does apcupsd connect to it?  I tried this back on 5.x and it failed
   miserably.  It identified the unit, but wouldn't talk to it.
  
  Yes.  I get notifications of power failures and can query status.
 
 I don't know what you guys are doing right, but it doesn't work
 right for me on
 
 $ uname -srm
 FreeBSD 6.1-RELEASE amd64
 
 I do get some results: this is the console when it's connected:
 
 ugen1: American Power Conversion Smart-UPS 750 FW:651.12.I USB FW:7.3, 
 rev 1.10/0.06, addr 6
 
 I find that apcaccess gives much less info from the USB port
 than it does from the RS232 port (on the same hardware) and
 apctest (which I want to use to set eprom values) doesn't work
 at all.  This is very irritating, as I'd like to use my only
 serial port for a remote console.
 
 For now, I've gone back to using the serial port.  But I'd love
 the USB to work fully.

I don't seem to need the other features.  This is not a FreeBSD issue
since FreeBSD just knows enough to not try to do anything to the device,
it's an apcupsd issue or possibly a weakness in APCs USB implementation.

-- Brooks


pgpXggZQTKeqM.pgp
Description: PGP signature

Re: Recommendations for a serial port card you can actually BUY?

[Brooks Davis]

On Thu, Oct 05, 2006 at 03:21:44PM -0500, Karl Denninger wrote:
 
 FreeBSD's USB support has always been somewhat deficient.  For example,
 apcupsd can't talk to their UPSs over the USB bus, even though the software
 itself knows how, because FreeBSD doesn't know what a UPS is and throws up
 its hands when you plug it in.

This is false for at least the APC SmartUPS the machine I'm sending this
from is connected to.  I wouldn't be suprised if it was true once, but
it isn't today.

ugen0: American Power Conversion Smart-UPS 750 FW:651.12.D USB FW:4.2, rev 
1.10/0.06, addr 2

-- Brooks


pgp7xaOqphxz8.pgp
Description: PGP signature

Re: Recommendations for a serial port card you can actually BUY?

[Brooks Davis]

On Thu, Oct 05, 2006 at 07:09:56PM -0500, Karl Denninger wrote:
 On Thu, Oct 05, 2006 at 04:04:47PM -0500, Brooks Davis wrote:
  On Thu, Oct 05, 2006 at 03:21:44PM -0500, Karl Denninger wrote:
   
   FreeBSD's USB support has always been somewhat deficient.  For example,
   apcupsd can't talk to their UPSs over the USB bus, even though the 
   software
   itself knows how, because FreeBSD doesn't know what a UPS is and throws up
   its hands when you plug it in.
  
  This is false for at least the APC SmartUPS the machine I'm sending this
  from is connected to.  I wouldn't be suprised if it was true once, but
  it isn't today.
  
  ugen0: American Power Conversion Smart-UPS 750 FW:651.12.D USB FW:4.2, rev 
  1.10/0.06, addr 2
 
 Does apcupsd connect to it?  I tried this back on 5.x and it failed
 miserably.  It identified the unit, but wouldn't talk to it.

Yes.  I get notifications of power failures and can query status.

-- Brooks


pgpukGQDBDeJP.pgp
Description: PGP signature

Re: Drives always come up dirty after shutdown on 6.2-PRERELEASE.

[Brooks Davis]

On Mon, Oct 02, 2006 at 12:10:10PM +0100, Josef Karthauser wrote:
 On Fri, Sep 29, 2006 at 09:44:07AM -0500, Brooks Davis wrote:
  On Fri, Sep 29, 2006 at 02:16:12PM +0100, Josef Karthauser wrote:
   Hey guys,
   
   I'm not really on the ball with reading the lists now-a-days, and so
   I've not idea whether this has been discussed already.
   
   On my laptop running 6.2-PRERELEASE the drives always mount dirty, which
   suggests that they are not being shutdown clean; however the machine
   always syncs the disks and switches itself off after a 'shutdown -p
   now', and so I'm not sure what it could be.
   
   Has anyone else seen this?
  
  I haven't seen any other reports of this.  Have you tried running a
  fsck -f on the drives?  It's possible there's a latent error that
  isn't being fixed by bgfsck.
  
 
 Closer investigation reveals that I've getting this error:
 
 laptop# fsck -B /var
 background fsck lacks a snapshot
 
 So, that explains it.  The background fsck isn't running.  So, any ideas
 why it isn't snapshotting?
 
 laptop# ls -ld /var/.snap
 drwxrwx---  2 root  operator  512 Oct  2 12:09 /var/.snap

This message appears to be the result of fsck thinking it created a
snapshot, but not actually doing so.  You might try asking over on -fs.

-- Brooks
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: Drives always come up dirty after shutdown on 6.2-PRERELEASE.

[Brooks Davis]

On Fri, Sep 29, 2006 at 02:16:12PM +0100, Josef Karthauser wrote:
 Hey guys,
 
 I'm not really on the ball with reading the lists now-a-days, and so
 I've not idea whether this has been discussed already.
 
 On my laptop running 6.2-PRERELEASE the drives always mount dirty, which
 suggests that they are not being shutdown clean; however the machine
 always syncs the disks and switches itself off after a 'shutdown -p
 now', and so I'm not sure what it could be.
 
 Has anyone else seen this?

I haven't seen any other reports of this.  Have you tried running a
fsck -f on the drives?  It's possible there's a latent error that
isn't being fixed by bgfsck.

-- Brooks


pgpKsFRj0Ha1i.pgp
Description: PGP signature

Re: 6.2 SHOWSTOPPER - em completely unusable on 6.2

[Brooks Davis]

On Wed, Sep 27, 2006 at 05:28:24PM +0200, Oliver Brandmueller wrote:
 Hi Scott,
 
 On Wed, Sep 27, 2006 at 03:16:57AM -0600, Scott Long wrote:
  Well, the best I can say at the moment is, Wow.  =-(  I guess the 
  thing to do here is to figure out if the problem lies with the em 
  interrupt handler not getting run, or the taskqueue not getting run.
  Since you've stated that it seems to be related to shared interrupts,
  the first possibility is more likely.  However, I'm not sure why the
  symptom would only be showing up now.  The Intel docs say that the
  82547EI are a bit interesting, and I wonder if assumptions that we
  make about PCI ordering aren't true (or if there are bugs that make
  our assumptions invalid).
  
  Does this happen after there has been a lot of disk activity, like a
  large tar extraction?  Are you using the SMBus interface at all, or is
  it sitting completely idle?
 
 Disk activity does not trigger the problem, I hammered the disk with 
 around 85 MB/s (dd) for about half an hour without seeing any effect. A 
 CPU bound thing like a buildworld triggered the problem.

I'm not sure that's a valid test by it self.  As things go, dd is pretty
easy on the disk IO system especially with large buffer sizes.  I'd
suggest tar extraction or possible parallel tar extraction.  The goal is
to generate a large number of transations not large transactions.

-- Brooks



pgpeCNuKVMIZG.pgp
Description: PGP signature