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

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

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: 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: 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: 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: booting off GPT partitions

[Brooks Davis]

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

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

-- Brooks


pgp8pD1O6RdfM.pgp
Description: PGP signature

Re: booting off GPT partitions

[Brooks Davis]

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

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

-- Brook


pgpj5hBEqRLpB.pgp
Description: PGP signature

Re: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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

[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 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

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

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: 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: 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: 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: 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: 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 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 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 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: "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: [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: 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: 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

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: 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

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: 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: 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: 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: Do you use a value other than AUTO for network_interfaces?

[Brooks Davis]

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

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

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

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

-- Brooks


pgpmOFAe0FIRr.pgp
Description: PGP signature

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

[Brooks Davis]

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

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

Do you actually do this?

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

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

-- Brooks


pgpuOce7pt6kS.pgp
Description: PGP signature

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

[Brooks Davis]

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

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

-- Brooks


pgpkLjbT4ZI0N.pgp
Description: PGP signature

Re: ZFS: drive replacement performance

[Brooks Davis]

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

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

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

-- Brooks


pgp5qP7xlqtwD.pgp
Description: PGP signature

Re: ZFS: drive replacement performance

[Brooks Davis]

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

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

-- Brooks


pgpP0kZirFSiT.pgp
Description: PGP signature

Re: ZFS: drive replacement performance

[Brooks Davis]

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

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

-- Brooks


pgpSiTaVAy8H6.pgp
Description: PGP signature

Re: 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: 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: 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 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: 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: 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: 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: 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: 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

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: 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

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: 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

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: 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

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

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: 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

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: pkg_version confused by architecutre in package name

[Brooks Davis]

On Thu, Jul 06, 2006 at 02:45:45AM +0200, [LoN]Kamikaze wrote:
> I normally run the command
> #  pkg_version -Iv | grep \<
> before running 'portupgrade -a', to see what's going to happen. This time I 
> got the following output:
> 
> diablo-jdk-freebsd6.i386.1.5.0.07.00  <   needs updating (index has 
> 1.5.0.07.00)
> 
> It seems that the tool is confused by the i386 in the package name.

Actually I think it's confused by the fact that the package name is
"diablo-jdk" and the version is "freebsd6.i386.1.5.0.07.00".  That's
just plain bogus.

-- Brooks

-- 
Any statement of the form "X is the one, true Y" is FALSE.
PGP fingerprint 655D 519C 26A7 82E7 2529  9BF0 5D8E 8BE9 F238 1AD4


pgpGOC8Lt7rr1.pgp
Description: PGP signature

Re: pkg_version confused by architecutre in package name

[Brooks Davis]

On Thu, Jul 06, 2006 at 11:01:43AM +0200, [LoN]Kamikaze wrote:
> Brooks Davis wrote:
> > On Thu, Jul 06, 2006 at 02:45:45AM +0200, [LoN]Kamikaze wrote:
> >> I normally run the command
> >> #  pkg_version -Iv | grep \<
> >> before running 'portupgrade -a', to see what's going to happen. This time 
> >> I got the following output:
> >>
> >> diablo-jdk-freebsd6.i386.1.5.0.07.00  <   needs updating (index has 
> >> 1.5.0.07.00)
> >>
> >> It seems that the tool is confused by the i386 in the package name.
> > 
> > Actually I think it's confused by the fact that the package name is
> > "diablo-jdk" and the version is "freebsd6.i386.1.5.0.07.00".  That's
> > just plain bogus.
> > 
> So who is at fault? The ports infrastructure or the FreeBSD foundation?

I don't know.  How did you install it?

-- Brooks

-- 
Any statement of the form "X is the one, true Y" is FALSE.
PGP fingerprint 655D 519C 26A7 82E7 2529  9BF0 5D8E 8BE9 F238 1AD4


pgpco8gCRUOhB.pgp
Description: PGP signature

Re: pkg_version confused by architecutre in package name

[Brooks Davis]

On Thu, Jul 06, 2006 at 06:04:37PM +0200, [LoN]Kamikaze wrote:
> 
> Brooks Davis wrote:
> > On Thu, Jul 06, 2006 at 11:01:43AM +0200, [LoN]Kamikaze wrote:
> >> Brooks Davis wrote:
> >>> On Thu, Jul 06, 2006 at 02:45:45AM +0200, [LoN]Kamikaze wrote:
> >>>> I normally run the command
> >>>> #  pkg_version -Iv | grep \<
> >>>> before running 'portupgrade -a', to see what's going to happen. This 
> >>>> time I got the following output:
> >>>>
> >>>> diablo-jdk-freebsd6.i386.1.5.0.07.00  <   needs updating (index has 
> >>>> 1.5.0.07.00)
> >>>>
> >>>> It seems that the tool is confused by the i386 in the package name.
> >>> Actually I think it's confused by the fact that the package name is
> >>> "diablo-jdk" and the version is "freebsd6.i386.1.5.0.07.00".  That's
> >>> just plain bogus.
> >>>
> >> So who is at fault? The ports infrastructure or the FreeBSD foundation?
> > 
> > I don't know.  How did you install it?
> 
> # pkg_add diablo-jdk-freebsd6.i386.1.5.0.07.00.tbz

It definitly installs correctly if you use the port instead of the
package.  It looks like the package is incorrect.

-- Brooks

-- 
Any statement of the form "X is the one, true Y" is FALSE.
PGP fingerprint 655D 519C 26A7 82E7 2529  9BF0 5D8E 8BE9 F238 1AD4


pgpTC8REfeBKs.pgp
Description: PGP signature

Re: em device hangs on ifconfig alias ...

[Brooks Davis]

On Mon, Jul 10, 2006 at 05:55:23PM -0300, User Freebsd wrote:
> On Mon, 10 Jul 2006, Patrick M. Hausen wrote:
> 
> >Mornin'!
> >
> >On Mon, Jul 10, 2006 at 12:11:36AM -0400, Mike Tancsa wrote:
> >
> >>>Not sure what STP is
> >>
> >>Spanning Tree Protocol.  Having the link go up and down would cause
> >>the switch port to block traffic for a period of time.
> >
> >Of course, any reasonable administrator would configure
> >
> > interface FastEthernet0/1
> >  spanning-tree portfast
> 
> 'k, I know nothing about Cisco but do have access to change my configs 
> (knowing nothing tends to keep me from doing too much playing) ... what 
> does the above do, exactly?

It tells the switch that this port will never be anything but a leaf in
the tree so STP does not need to re run before allowing packets to flow.
If you do this and then create a loop with it, bad things happen, but
cisco recommends it in general.

-- Brooks

-- 
Any statement of the form "X is the one, true Y" is FALSE.
PGP fingerprint 655D 519C 26A7 82E7 2529  9BF0 5D8E 8BE9 F238 1AD4


pgpYgOwJoPkFT.pgp
Description: PGP signature

Re: interface announcement MFC

[Brooks Davis]

On Sun, Jul 23, 2006 at 10:33:06PM +1200, Andrew Thompson wrote:
>
> I would quite like to MFC the autobridge feature but it depends on this
> change, http://lists.freebsd.org/pipermail/cvs-src/2006-May/064529.html
> 
> I cant see it being a problem MFCing this to stable as the existing devd
> announcement still exists, it just adds another that includes pseudo ones
> too. Does anyone forsee any problems?

I think it should be OK.  We haven't seen any problems on -current and
there should be enough time for things to settle before 6.2 in any case.

-- Brooks


pgpgf4eLXhZqH.pgp
Description: PGP signature

Re: "scan stuck" with if_iwi(4)

[Brooks Davis]

On Thu, Jul 27, 2006 at 04:47:16PM -0700, Sam Leffler wrote:
> Andrew Thompson wrote:
> > On Wed, Jul 26, 2006 at 01:28:12PM -0700, Sam Leffler wrote:
> >> Henrik Brix Andersen wrote:
> >>> Oh? Sounds interesting, where can I find these patches?
> >> The work has always been in perforce.freebsd.org; look in the sam_wifi
> >> branch.  The code will not hit head until folks show up to fix legacy
> >> drivers that use net80211.  I got stuck holding the bag when I committed
> >> the wpa support and it ain't going to happen again.
> >>
> > 
> > Do you have a list of drivers that are stalling this? 
> 
> The changes decouple scanning from the net80211 state machine so any
> driver that uses ieee80211_new_state is affected:
> 
> tubby% grep -l ieee80211_new_state */*.c
> ath/if_ath.c
> awi/awi.c
> ipw/if_ipw.c
> iwi/if_iwi.c
> ral/rt2560.c
> ral/rt2661.c
> usb/if_ural.c
> wi/if_wi.c
> 
> I know how to convert ath and ral.  iwi and ipw might not be too bad now
> that they've been changed to not abuse the state machine so much.  awi,
> ural, and wi will break.  ural might be ok after the new usb stack comes
> in but that's not clear.
> 
> So I guess I'd take responsibility for ath and ral and want help with
> all other drivers.

IMO, losing awi in the process wouldn't be a big deal.  We'll be
maintaining 6.x until well into 2008 and all the awi cards are defunct.

-- Brooks


pgplprNnsvXkH.pgp
Description: PGP signature

Re: gzip is faster with -O3

[Brooks Davis]

On Wed, Aug 09, 2006 at 05:31:58PM -0500, Nikolas Britton wrote:
> On 8/9/06, Matthias Andree <[EMAIL PROTECTED]> wrote:
> >
> >1. gzip isn't usually used to compress incompressible data.
> >
> >2. use "time" to figure out how much CPU time it actually burns.
> >   5 GB are somewhat I/O bound, but gcc options don't help with that, so
> >   CPU time is better than wallclock time.
> >
> 
> dd if=/dev/zero of=testfile bs=1m count=5000
> 
> gzip comiled with -O3
> # time nice -10 ./gzip -c9 testfile > /dev/null
> 73.187u 8.682s 2:08.41 63.7%70+617k 40161+0io 0pf+0w
> 
> gzip compiled with -O2
> # time nice -10 ./gzip -c9 testfile > /dev/null
> 61.183u 8.468s 2:00.14 57.9%58+609k 40162+0io 0pf+0w
> 
> Now... what do all of those numbers mean, I've never used time
> before... thanks for the tip btw?

In this case the used a similar amount of system time (the number ending
in s), but the -O3 case took 8 seconds more user time (the number ending
in u) and real time (the third number.)  If this were statisticaly
meaningful, -O3 would be slower in this case.  If you want to do a
meaningful test you need to do several runs each way, probably ignoring
the first one due to cache effects and then run the results through
the program you can build in src/tools/tools/ministat/ so see if there
is a measurable difference.  Poul-Henning Kamp has a nice (if probably
somewhat overkill for this case) writeup on doing benchmarking here:

http://lists.freebsd.org/pipermail/freebsd-current/2004-January/019595.html

It's a tricky business even for something simple. :)

You might also consider using /usr/bin/time instead of the csh builtin
time.  It's output is a little more readable.

-- Brooks


pgp820W2lpVvK.pgp
Description: PGP signature

Re: Default route (IPv4) demolished by destroying clone (gif/gre) interface

[Brooks Davis]

On Wed, Aug 16, 2006 at 10:23:13AM +0200, Stefan Bethke wrote:
> 
> Ouch. Don't ppp(8), OpenVPN etc. destroy the tun interface they're  
> using when they exit?  Flushing all routes then would be rather  
> harmful.  I'm glad I haven't updated to a newer -stable yet then :-)

In general, no since tun interfaces can not be destroyed.

-- Brooks


pgpPoRI0Xs1zO.pgp
Description: PGP signature

Re: Default route (IPv4) demolished by destroying clone (gif/gre) interface

[Brooks Davis]

On Wed, Aug 16, 2006 at 07:58:44PM +0400, Yar Tikhiy wrote:
> On Wed, Aug 16, 2006 at 09:54:19AM -0500, Brooks Davis wrote:
> > On Wed, Aug 16, 2006 at 10:23:13AM +0200, Stefan Bethke wrote:
> > > 
> > > Ouch. Don't ppp(8), OpenVPN etc. destroy the tun interface they're  
> > > using when they exit?  Flushing all routes then would be rather  
> > > harmful.  I'm glad I haven't updated to a newer -stable yet then :-)
> > 
> > In general, no since tun interfaces can not be destroyed.
> 
> Did you mean "in particular"? :-)
> 
> The problem can be triggered by destroying any interface that can
> be destroyed.  Just imagine getting rid of a defunct gif tunnel on
> a remote router, or removing an unused vlan, and totally losing
> connectivity to the router due to its default route having been
> flushed.  The scenario still can be quite unpleasant.  I'd rather
> change the default for $removable_route_flush to NO and let the
> kernel choose which routes should be flushed upon the physical
> ejection or software destruction of an interface.  Note that this
> doesn't include static_routes_${ifn}, which are handled separately
> by pccard_ether_stop().

Agreed.  That code shouldn't be on by default.  I've disabled in it HEAD
and will MFC in a few days.  As another poster said, I'm not even sure
it should exist as an option.

-- Brooks


pgpV8Z2BeouxM.pgp
Description: PGP signature

Re: Default route (IPv4) demolished by destroying clone (gif/gre) interface

[Brooks Davis]

On Thu, Aug 17, 2006 at 08:49:27AM +1200, Andrew Thompson wrote:
> On Wed, Aug 16, 2006 at 12:15:25PM -0500, Brooks Davis wrote:
> > On Wed, Aug 16, 2006 at 07:58:44PM +0400, Yar Tikhiy wrote:
> > > On Wed, Aug 16, 2006 at 09:54:19AM -0500, Brooks Davis wrote:
> > > > On Wed, Aug 16, 2006 at 10:23:13AM +0200, Stefan Bethke wrote:
> > > > > 
> > > > > Ouch. Don't ppp(8), OpenVPN etc. destroy the tun interface they're  
> > > > > using when they exit?  Flushing all routes then would be rather  
> > > > > harmful.  I'm glad I haven't updated to a newer -stable yet then :-)
> > > > 
> > > > In general, no since tun interfaces can not be destroyed.
> > > 
> > > Did you mean "in particular"? :-)
> > > 
> > > The problem can be triggered by destroying any interface that can
> > > be destroyed.  Just imagine getting rid of a defunct gif tunnel on
> > > a remote router, or removing an unused vlan, and totally losing
> > > connectivity to the router due to its default route having been
> > > flushed.  The scenario still can be quite unpleasant.  I'd rather
> > > change the default for $removable_route_flush to NO and let the
> > > kernel choose which routes should be flushed upon the physical
> > > ejection or software destruction of an interface.  Note that this
> > > doesn't include static_routes_${ifn}, which are handled separately
> > > by pccard_ether_stop().
> > 
> > Agreed.  That code shouldn't be on by default.  I've disabled in it HEAD
> > and will MFC in a few days.  As another poster said, I'm not even sure
> > it should exist as an option.
> 
> Thanks for fixing this up, it certainly was odd to be flushing routes in
> userland. I have one more bug report from the ifnet/devd change to look
> at where renamed interfaces give some sort of an error.

It is a rather weird bit of code.  It deletes all IPv4 routes on exit.
I suspect it's a hack left over from before interface removal really
worked.  I may just delete the code in HEAD after the MFC.  I think we
could also remove the arp flush or move it into "netif stop" and narrow
it with the -i option.

-- Brooks


pgpIYFxEe7p4G.pgp
Description: PGP signature

Re: Default route (IPv4) demolished by destroying clone (gif/gre) interface

[Brooks Davis]

On Thu, Aug 17, 2006 at 08:49:27AM +1200, Andrew Thompson wrote:
> On Wed, Aug 16, 2006 at 12:15:25PM -0500, Brooks Davis wrote:
> > On Wed, Aug 16, 2006 at 07:58:44PM +0400, Yar Tikhiy wrote:
> > > On Wed, Aug 16, 2006 at 09:54:19AM -0500, Brooks Davis wrote:
> > > > On Wed, Aug 16, 2006 at 10:23:13AM +0200, Stefan Bethke wrote:
> > > > > 
> > > > > Ouch. Don't ppp(8), OpenVPN etc. destroy the tun interface they're  
> > > > > using when they exit?  Flushing all routes then would be rather  
> > > > > harmful.  I'm glad I haven't updated to a newer -stable yet then :-)
> > > > 
> > > > In general, no since tun interfaces can not be destroyed.
> > > 
> > > Did you mean "in particular"? :-)
> > > 
> > > The problem can be triggered by destroying any interface that can
> > > be destroyed.  Just imagine getting rid of a defunct gif tunnel on
> > > a remote router, or removing an unused vlan, and totally losing
> > > connectivity to the router due to its default route having been
> > > flushed.  The scenario still can be quite unpleasant.  I'd rather
> > > change the default for $removable_route_flush to NO and let the
> > > kernel choose which routes should be flushed upon the physical
> > > ejection or software destruction of an interface.  Note that this
> > > doesn't include static_routes_${ifn}, which are handled separately
> > > by pccard_ether_stop().
> > 
> > Agreed.  That code shouldn't be on by default.  I've disabled in it HEAD
> > and will MFC in a few days.  As another poster said, I'm not even sure
> > it should exist as an option.
> 
> Thanks for fixing this up, it certainly was odd to be flushing routes in
> userland. I have one more bug report from the ifnet/devd change to look
> at where renamed interfaces give some sort of an error.

Should be fixed in HEAD.

-- Brooks


pgpaE8JKHPsfQ.pgp
Description: PGP signature

Re: Default route (IPv4) demolished by destroying clone (gif/gre) interface

[Brooks Davis]

On Thu, Aug 17, 2006 at 11:16:51AM +0400, Yar Tikhiy wrote:
> On Wed, Aug 16, 2006 at 03:59:13PM -0500, Brooks Davis wrote:
> > On Thu, Aug 17, 2006 at 08:49:27AM +1200, Andrew Thompson wrote:
> > > On Wed, Aug 16, 2006 at 12:15:25PM -0500, Brooks Davis wrote:
> > > > On Wed, Aug 16, 2006 at 07:58:44PM +0400, Yar Tikhiy wrote:
> > > > > On Wed, Aug 16, 2006 at 09:54:19AM -0500, Brooks Davis wrote:
> > > > > > On Wed, Aug 16, 2006 at 10:23:13AM +0200, Stefan Bethke wrote:
> > > > > > > 
> > > > > > > Ouch. Don't ppp(8), OpenVPN etc. destroy the tun interface 
> > > > > > > they're  
> > > > > > > using when they exit?  Flushing all routes then would be rather  
> > > > > > > harmful.  I'm glad I haven't updated to a newer -stable yet then 
> > > > > > > :-)
> > > > > > 
> > > > > > In general, no since tun interfaces can not be destroyed.
> > > > > 
> > > > > Did you mean "in particular"? :-)
> > > > > 
> > > > > The problem can be triggered by destroying any interface that can
> > > > > be destroyed.  Just imagine getting rid of a defunct gif tunnel on
> > > > > a remote router, or removing an unused vlan, and totally losing
> > > > > connectivity to the router due to its default route having been
> > > > > flushed.  The scenario still can be quite unpleasant.  I'd rather
> > > > > change the default for $removable_route_flush to NO and let the
> > > > > kernel choose which routes should be flushed upon the physical
> > > > > ejection or software destruction of an interface.  Note that this
> > > > > doesn't include static_routes_${ifn}, which are handled separately
> > > > > by pccard_ether_stop().
> > > > 
> > > > Agreed.  That code shouldn't be on by default.  I've disabled in it HEAD
> > > > and will MFC in a few days.  As another poster said, I'm not even sure
> > > > it should exist as an option.
> > > 
> > > Thanks for fixing this up, it certainly was odd to be flushing routes in
> > > userland. I have one more bug report from the ifnet/devd change to look
> > > at where renamed interfaces give some sort of an error.
> > 
> > It is a rather weird bit of code.  It deletes all IPv4 routes on exit.
> > I suspect it's a hack left over from before interface removal really
> > worked.  I may just delete the code in HEAD after the MFC.  I think we
> > could also remove the arp flush or move it into "netif stop" and narrow
> > it with the -i option.
> 
> The -i option may not work in that case because the interface has
> ceased to exist by the time devd(8) gets the notification and runs
> /etc/pccard_ether.  It could be better just to remove the arp flush
> completely.  The kernel should take care of the arp entries by itself.
> Thanks!

I decided to leave it in, but protect it with ifexists.  That way we
preserve the scripts secondary roll of downing an interface.  I'll
probalby move it into network.subr:ifconfig_down() at some point.

-- Brooks


pgp0maUZkX0M2.pgp
Description: PGP signature

Re: The need for initialising disks before use?

[Brooks Davis]

On Thu, Aug 17, 2006 at 03:35:14AM -1000, Antony Mawer wrote:
> Hi list,
> 
> A quick question - is it recommended to initialise disks before using 
> them to allow the disks to map out any "bad spots" early on? I've seen 
> some "uninitialised" disks (ie. new disks, thrown into a machine, 
> newfs'd) start to show read errors within a few months of deployment, 
> which I thought one or two might seem okay, but on a number of machines 
> is more than a coincidence...
> 
> Is it recommended/required to do something like:
> 
> dd if=/dev/zero of=/dev/ad0 bs=1m
> 
> before use to ensure the drive's sector remappings are all in place, 
> before then doing a newfs?
> 
> FWIW, I've been seeing this on more 6.0 systems that I would have 
> thought to be just chance...

This probably isn't a bad idea in general.  It might even be something
we should add to sysinstall.

-- Brooks


pgpCOr8lmMfAQ.pgp
Description: PGP signature

Re: The need for initialising disks before use?

[Brooks Davis]

On Fri, Aug 18, 2006 at 09:19:04AM -0500, Kirk Strauser wrote:
> On Thursday 17 August 2006 8:35 am, Antony Mawer wrote:
> 
> > A quick question - is it recommended to initialise disks before using
> > them to allow the disks to map out any "bad spots" early on?
> 
> Note: if you once you actually start seeing bad sectors, the drive is almost 
> dead.  A drive can remap a pretty large number internally, but once that 
> pool is exhausted (and the number of errors is still growing 
> exponentially), there's not a lot of life left.

There are some exceptions to this.  The drive can not remap a sector
which failes to read.  You must perform a write to cause the remap to
occur.  If you get a hard write failure it's gameover, but read failures
aren't necessicary a sign the disk is hopeless.  For example, the drive
I've had in my laptop for most of the last year developed a three sector[0]
error within a week or so of arrival.  After dd'ing zeros over the
problem sectors the problem sectors I've had no problems.

-- Brooks

[0] The error occured in one of the worst possible locations and fsck
could not complete until I zeroed those locations.  That really sucked.


pgp9MRru4oamG.pgp
Description: PGP signature

Re: The need for initialising disks before use?

[Brooks Davis]

On Fri, Aug 18, 2006 at 01:41:27PM -1000, Antony Mawer wrote:
> On 18/08/2006 4:29 AM, Brooks Davis wrote:
> >On Fri, Aug 18, 2006 at 09:19:04AM -0500, Kirk Strauser wrote:
> >>On Thursday 17 August 2006 8:35 am, Antony Mawer wrote:
> >>
> >>>A quick question - is it recommended to initialise disks before using
> >>>them to allow the disks to map out any "bad spots" early on?
> >>Note: if you once you actually start seeing bad sectors, the drive is 
> >>almost dead.  A drive can remap a pretty large number internally, but 
> >>once that pool is exhausted (and the number of errors is still growing 
> >>exponentially), there's not a lot of life left.
> >
> >There are some exceptions to this.  The drive can not remap a sector
> >which failes to read.  You must perform a write to cause the remap to
> >occur.  If you get a hard write failure it's gameover, but read failures
> >aren't necessicary a sign the disk is hopeless.  For example, the drive
> >I've had in my laptop for most of the last year developed a three sector[0]
> >error within a week or so of arrival.  After dd'ing zeros over the
> >problem sectors the problem sectors I've had no problems.
> 
> This is what prompted it -- I've been seeing lots of drives that are 
> showing up with huge numbers of read errors - for instance:
> 
> >Aug 19 04:02:27 server kernel: ad0: FAILURE - READ_DMA 
> >status=51 error=40 LBA=66293984
> >Aug 19 04:02:27 server kernel: 
> >g_vfs_done():ad0s1f[READ(offset=30796791808, length=16384)]error = 5
> >Aug 19 04:02:31 server kernel: ad0: FAILURE - READ_DMA 
> >status=51 error=40 LBA=47702304
> >Aug 19 04:02:31 server kernel: 
> >g_vfs_done():ad0s1f[READ(offset=21277851648, length=16384)]error = 5
> >Aug 19 04:02:36 server kernel: ad0: FAILURE - READ_DMA 
> >status=51 error=40 LBA=34943296
> >Aug 19 04:02:36 server kernel: 
> >g_vfs_done():ad0s1f[READ(offset=14745239552, length=16384)]error = 5
> >Aug 19 04:03:08 server kernel: ad0: FAILURE - READ_DMA 
> >status=51 error=40 LBA=45514848
> >Aug 19 04:03:08 server kernel: 
> >g_vfs_done():ad0s1f[READ(offset=20157874176, length=16384)]error = 5
> 
> I have /var/log/messages flooded with incidents of these "FAILURE - 
> READ_DMA" messages. I've seen it on more than one machine with 
> relatively "young" drives.
> 
> I'm trying to determining of running a dd if=/dev/zero over the whole 
> drive prior to use will help reduce the incidence of this, or if it is 
> likely that these are developing after the initial install, in which 
> case this will make negligible difference...

I really don't know.  The only way I can think of to find out is to own
a large number of machine and perform an experiment.  We (the general
computing public) don't have the kind of models needed to really say
anything definitive.  Drive are too darn opaque.

> Once I do start seeing these, is there an easy way to:
> 
> a) determine what file/directory entry might be affected?

Not easily, but this question has been asked and answered on the mailing
lists recently (I don't remember the answer, but I think there were some
ports that can help).

> b) dd if=/dev/zero over the affected sectors only, in order to
>  trigger a sector remapping without nuking the whole drive

You can use src/tools/tools/recover disk to refresh all of the disk
except the parts that don't work and then use dd and the console error
output to do the rest.

> c) depending on where that sector is allocated, I presume I'm
>  either going to end up with:
> i) zero'd bytes within a file (how can I tell which?!)
>ii) a destroyed inode
>   iii) ???

Presumably it will be one of i, ii or a mangled superblock.  I don't
know how you'd tell which off the top of my head.  This is one of the
reasons I think Sun is on the right track with zfs's checksum everything
approach.  At least that way you actually know when something goes
wrong.

> Any thoughts/comments/etc appreciated...
> 
> How do other operating systems handle this - Windows, Linux, Solaris, 
> MacOSX ...? I would have hoped this would be a condition the OS would 
> make some attempt to trigger a sector remap... or are OSes typically 
> ignorant of such things?

The OS is generally unaware of such events except to the extent that 
they know a fatal read error occurred or that they read the SMART data
from the drive in the case of write failures.

-- Brooks


pgpUCIAcpqMtN.pgp
Description: PGP signature

Re: cron abuse

[Brooks Davis]

On Sun, Sep 03, 2006 at 11:57:44AM -0500, Don Wilde wrote:
> On 9/3/06, David Wolfskill <[EMAIL PROTECTED]> wrote:
> >On Sun, Sep 03, 2006 at 11:43:01AM -0500, Don Wilde wrote:
> >> ...
> >> Thanks for taking the time to answer, David.
> >
> >Sure thing.
> >
> >> Yes, I see that. I'm reinstalling the old /etc/crontab back into
> >> /etc/crontab.
> >
> >OK.
> >
> >> This is what's driving me nuts. Why would it be acting as though it's
> >> a user crontab?
> >
> >I doubt that it is -- more likely, a copy of /etc/crontab was installed
> >as a "user crontab" -- go check /var/cron/tabs.
> >
> Yes, it did exactly that. Will removing the /var/cron/tabs entry make
> everything Just Work again?

Yes or run "crontab -e" and delete everything in the editor window
before saving.

One good thing about your problem is it reminded me I'd forgotten to MFC
the anti foot shooting measure I added a while back which causes crontab
to refuse to load /etc/crontab as a user crontab.  It doesn't try very
hard, but it does prevent the most common error.

-- Brooks


pgpdwkRsQA33T.pgp
Description: PGP signature

Re: Still possible to directly boot without loader?

[Brooks Davis]

On Sun, Sep 10, 2006 at 09:10:26PM +0200, Stefan Bethke wrote:
> I just tried to load my standard kernel from the boot blocks (instead  
> of using loader(8)), but I either get a hang before the kernel prints  
> anything, or a BTX halted.  Is this still supposed to work in 6- 
> stable, or has it finally disappeared?

You may be able to get this to work, but it is unsupported.

-- Brooks


pgpKJ9Yg3wrWp.pgp
Description: PGP signature

Re: optimization levels for 6-STABLE build{kernel,world}

[Brooks Davis]

On Tue, Sep 12, 2006 at 04:22:51PM -0300, Marc G. Fournier wrote:
> 
> What are ppl currently using for CFLAGS/COPTFLAGS in /etc/make.conf for 
> building kernel/world?  I know awhile back it wasn't recommended to go 
> above -O2, for instance, but suspect that has changed ... ?

Nothing above -O2 is supported.  Period.  If you try another value and
something breaks, don't report it unless you can verify it happens with
-O or -O2.  For many applications, -O2 will perform better than -O3 so
you need to benchmark individual applications.  For most applications,
there's simply no point.

-- Brooks


pgps9W0UOMm0W.pgp
Description: PGP signature

Re: sed and comma-delimited file

[Brooks Davis]

On Tue, Sep 19, 2006 at 12:26:54PM -0400, SigmaX asdf wrote:
> Yo;
> 
> I have a series of comma-delimited text files with fourteen columns of
> data and several hundred rows.  I want to use a short shell script to
> strip them of the last 9 columns, leaving the same file but with just
> five of its columns.  I can do it in C++, but that seems like
> overkill.  How would I go about doing it with sed or a similar
> utility?

See cut(1):

cut -d, -f1,2,3,4,5

-- Brooks


pgp9GMxOtSzTD.pgp
Description: PGP signature

Re: 6.2 SHOWSTOPPER - em completely unusable on 6.2

[Brooks Davis]

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

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

-- Brooks



pgpeCNuKVMIZG.pgp
Description: PGP signature

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

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: 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: 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