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 th

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@
> .

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 
> >> +
> >> +.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 
> +
> +.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 
> +
> +.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  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]

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  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 
> > 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)..  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: 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  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)..  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]

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)..  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: 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  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  wrote:
> > On Wed, Jan 16, 2013 at 6:15 PM, Dimitry Andric  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  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.  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 with>32GB 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=0xbfebfbff
  
Features2=0x9ce3bd
  AMD Features=0x28100800
  AMD Features2=0x1
  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 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: 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: 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"  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 :
> > 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 Wed, Sep 09, 2009 at 07:07:01PM +0200, Thierry Thomas wrote:
> Le Mer  9 sep 09 ? 17:52:57 +0200, Brooks Davis 
>  ?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 Sat, Sep 05, 2009 at 01:06:35PM +0200, Thierry Thomas wrote:
> Le Ven  4 sep 09 ? 23:57:47 +0200, Brooks Davis 
>  ?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 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:  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 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: 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 01:40:02AM +0300, Dan Naumov wrote:
> On Wed, Jul 8, 2009 at 1:32 AM, Freddie Cash wrote:
> > On Tue, Jul 7, 2009 at 3:26 PM, Mahlon E. Smith  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 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: 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 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 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_ 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: 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 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_ variable is set (I think i can be "", but "up" is
   always a good choice if you just want a stub.
 - The ifconfig_ 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: 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: 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: cvsup freebsd 6_2 to freebsd 7_1 not upgrading?

[Brooks Davis]

lt;< >>>>>host=cvsup15.us.FreeBSD.
> 
> >org
> >><< >>>>>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.
> Try also reading the comments in 
> /usr/src/Makefile
> 
> ___
> 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"
> 
> ___
> 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"
> 


pgpLjhBdi1iq7.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=cvsup15.us.FreeBSD.org
> > << > >>>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]

[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=cvsup15.us.FreeBSD.org
> << >>>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: 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=178675&view=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  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  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 li

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: Q&A 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 Q&A 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: Q&A 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 

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 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 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_ 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 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 07:23:33PM +0100, Oliver Fromme wrote:
> Brooks Davis wrote:
>  > Oliver Fromme wrote:
>  > > Brooks Davis wrote:
>  > > > ipv4_addrs_ 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 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_ 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 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_ 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 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 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' , 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' , 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: 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/
> > 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: 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/
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: 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 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 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: 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 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: 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: 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 Thu, Sep 28, 2006 at 06:32:16AM +1200, Jonathan Chen wrote:
> On Wed, Sep 27, 2006 at 03:25:55PM +0200, Patrick M. Hausen wrote:
> > Hi!
> > 
> > On Wed, Sep 27, 2006 at 02:42:30PM +0200, Philippe Pegon wrote:
> > 
> > > it's just a me too. On our ftp server (ftp8.fr.freebsd.org), sometimes
> > > we see some "watchdog timeout" in the log with a bge card, but maybe it's
> > > not the same problem... :
> > 
> > As far as I know the watchdog timeouts are _supposed_ to be
> > mostly harmless, i.e. recoverable.
> > 
> > Some people experience additional complete hangs of network
> > communications, that may or may not be related to them.
> 
> I had "watchdog timeouts" occur on a small network setup, for a:
> 
>   ssh remote "cd /usr && tar xf - ports" | tar xvf -
> 
> and this resulted in a pretty sparse ports tree on the local drive.
> Lots of stuff being dropped. Shifting a single big tar-ball worked
> though.

I'm highly skeptical of this claim.  It's possible the connection failed
part way through and thus you didn't get all your files, but you
wouldn't get random dropouts.  TCP doesn't work that way.

-- Brooks


pgp8zFZ1luFKR.pgp
Description: PGP signature