Re: Experiences with FreeBSD 9.0-BETA2

From: Arnaud Lacombe <lacombar_at_gmail.com>
Date: Sun, 25 Sep 2011 23:34:09 -0400
Hi,

On Sun, Sep 25, 2011 at 8:52 PM, Brett Glass <brett_at_lariat.net> wrote:
> Next thing I did was try to recompile the kernel to streamline it and add
> features I want compiled in, such as ipfw and dummynet. Alas, I saw no sign
> of the BSD-licensed Clang compiler, for which I've waited for many years (I
> can't believe that now, in 2011, one cannot build FreeBSD without GPLed
> code.)
>
LLVM is still behind gcc performance wise, at least for current stable
gcc vs. current stable llvm, it might not be so true with FreeBSD's 4
years old gcc. Moreover, you still need GPL binutils, as AFAIK, there
is no BSD assembler and linker.

These might also have been codgen issue with LLVM, cf archives of this list.

> I got hung up at the "mountroot" prompt. The system couldn't find the root
> partition specified in /etc/fstab. However, if I manually loaded the GENERIC
> kernel, the system DID boot.
>
> I soon discovered why. An innocuous message that I didn't notice at the
> beginning of installation proclaimed that the GENERIC kernel was renaming
> the SATA SSD, which started out as ad0, to ada0. I modified /etc/fstab to
> use ad0p2 as the root filesystem slice, and the system booted the new
> kernel.
>
> I then explored what had happened in more depth. The problem seemed to be
> that my kernel configuration completely eliminated SCSI. (I had no SCSI
> devices in the system and didn't need or want the bloat that came with it.)
> But when I booted the GENERIC kernel, the SCSI subsystem took control of ATA
> devices, renaming them in the process. This is a big violation of POLA; the
> change and the failure to boot were a big surprise.
>
normally, the device should still have been accessible through the old name.

> The GENERIC kernel, instead of just using a direct ATA driver, was
> assembling a complex, memory-intensive, and compute-intensive layer cake of
> shims -- including the ata, ahci, da, and scbus drivers, not to mention GEOM
> -- to get to the SATA disk. Since the system I was trying to build has only
> one mass storage device -- a simple SSD -- and is tight on RAM, I'd rather
> go without bloating the kernel, slowing the system, or exposing myself to
> SCSI bugs by simply using an ATA driver. With all due respect for the hard
> work of the people who went to the trouble to create all of those shims, I
> hope that it remains possible to do this.
>
Reason for that is that your SSD is certainly connected to a SATA bus
which, with AHCI, has more similarity with SCSI than plain IDE-ATA, cf
[0]. The Linux folks have taken the same approach.

> 2) I saw many warnings of lock order reversals under the GENERIC kernel, in
> particular in the file system code. These obviously should be fixed before
> release.
>
Where did you report them ? [btw, they might already be known.]

 - Arnaud

[0]: mail from Andriy Gapon (FreeBSD), on NetBSD's tech-kern_at_:
http://mail-index.netbsd.org/tech-kern/2011/04/26/msg010424.html
Received on Mon Sep 26 2011 - 01:56:54 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:18 UTC