8.x grudges

[Kevin Oberman]

> Date: Wed, 07 Jul 2010 14:22:22 -0400
> From: "Mikhail T." <mi+thun at aldan.algebra.com>
> Sender: owner-freebsd-stable at freebsd.org
> 
> I'm upgrading several systems these days to the 8.1 (pre-release) and 
> have hit the following troubles... I could file a formal PR for each, I 
> suppose, but, maybe, this way will get the right people's attention sooner.
> 
> In no particular order:
> 
>    1.
>       A picture, that one of the systems was displaying at boot (and
>       then used as a screen-saver),  stopped showing properly. The
>       colors are right, but the picture is distorted beyond recognition.
>       The relevant part of loader.conf is:
> 
>           splash_pcx_load="YES"
>           vesa_load="YES"
>           bitmap_load="YES"
>           bitmap_name="/boot/187426-9-quokka-dreaming.pcx"
> 
>       the picture file is identified as:
> 
>           PCX 772x551 772x551+0+0 8-bit PseudoClass 256c 454KB 0.039u
>           0:00.093
> 
>    2.
>       FREEBSD_COMPAT7 kernel option is, apparently, a requirement (and
>       thus not an "option") -- the kernel-config files, that worked with
>       7.x, break without this option in them (in addition to all the
>       nuisance, that's documented in UPDATING -- which, somehow, makes
>       the breakage acceptable). config(8) would not warn about this, but
>       kernel build fails.

FREEBSD_COMPAT7 is certainly an option. I build without it just fine. But
"the kernel-config files, that worked with 7.x, break without this
option in them" I think points to your real problem.

>    3.
>       Likewise, having "device ugen" breaks config(8) -- another
>       undocumented incompatibility.

It certainly does. ugen is no longer a valid device with the new USB
stack in 8. (It is essentially built into the base USB driver.) 

It seems that you expect to be able to build a kernel for V8 using a V7
configuration file. THIS WILL NOT WORK! You must always re-do
customizations when performing a major version upgrade. You should always
start with GENERIC for a major version and make the required changes to
it. 

I believe the current recommendation is to "include GENERIC" in your
custom kernel configuration and then add or delete options and devices
as desired. (This probably works best if your config file is close to
GENERIC.) 

>    4.
>       The sio(4) is described in UPDATING as "removed", but rouses no
>       complaint from config(8) either. It just breaks the kernel
>       build... It should be an alias for uart, IMHO -- all I want is for
>       my serial ports to be usable, whether their driver is called
>       "Serial Input/Output" or "Universal Asynchronous Receiver and
>       Transmitter".
>       (BTW, about the /dev-entries -- do we /really/ have to change the
>       names of the serial port-devices every couple of years? It is
>       rather painful to reconfigure the fax- and ppp-software, etc.) How
>       does the Microsoft world manage to stay with the COM1, COM2 for
>       decades?)

This would be nice, but the sio and uart drivers have co-existed for
quite a while. They could not have the same name. Of course, a it would
have been possible to rename the uart driver to sio when sio was
removed or make it an alias, but that was not done. I suspect primarily
to not break things when people discovered that sio and uart are NOT the
same in the way they work. Not an issue for most, since they are close.

>    5.
>       One of the upgraded systems would repeatedly hang at boot, until I
>       disabled the on-board firewire-device through the BIOS... It was
>       not a problem under 7.x, although I don't know, whether the device
>       actually worked.

Odd. Sounds like a bug. I don't have a firewire port, so I have no idea
about this.

>    6.
>       Despite the reported improvements in the USB area, my USB keyboard
>       /still/ does not work during boot. It during POST and then after
>       the booting is complete. But in single-user mode -- no... Had to
>       fish-out the PS2 keyboard...

All I can say is that it works fine for me. It may be tied to your
building a V8 kernel with a V7 config. It may also be tied to having
libusb from ports installed. Since libusb is now part of the base
system, having the ports version around can break lots of USB stuff.

>    7.
>       All my "dangerously dedicated" disks lost the "s1" in the
>       subdevice-names after the upgrade: /dev/da1s1d became /dev/da1d,
>       etc. I like the shorter names (and there are, indeed, no "slices"
>       there), but having to fix them manually upon reboot was unpleasant
>       and uncalled for. As with uart/sio, backward-compatibility aliases
>       are a fine idea and really improves user's experience...

No, this one is due to a major re-structuring of how disks work in
V8. As has been oft noted, "dangerously dedicated" is called that
because it IS dangerous. While commonly used, it does not play nicely
with standards and is prone to some fairly serious potential issues on
upgrade. "dangerously dedicated" has been marked as "use it at your own
risk", so you are likely to see issues (in this case a fairly minor one).

>    8.
>       I tried to do an install on one of the systems via netbooting
>       (pxeload) the disk1-image. It booted, but the sysinstall had to be
>       started manually and, once started, did not act the same as when
>       booted off of CD-ROM. Seems like a simple bit to correct so that
>       setting "init" to /usr/sbin/sysinstall/manually on every boot/ is
>       not necessary...

Have not tried this.
>    9.
>       The k8temp utility (installed by sysutils/k8temp
>       <http://www.freshports.org/sysutils/k8temp>), which worked fine on
>       both of my AMD-machines, no longer works on the Athlon one (still
>       works on the Opteron-based server). I reinstalled the port, but
>       that did not help -- the utility runs, but does not say anything.
>       Requeting debug-info is of little help:
> 
>           *root*@quokka:~ (101) k8temp
>           *root*@quokka:~ (102) k8temp -d
>           CPUID: Vendor: AuthenticAMD, 0x6a0: Model=0a Family=6+0 Stepping=0
>           Advanced Power Management=0x1
>               Temperature sensor: Yes
>             Frequency ID control: No
>               Voltage ID control: No
>                THERMTRIP support: No
>               HW Thermal control: No
>               SW Thermal control: No
>               100MHz multipliers: No
>               HW P-State control: No
>                    TSC Invariant: No

k8temp is for older AMD system running K8 cores. It has been mostly
replaced with amdtemp which works on newer cores. I'm not sure if
amdtemp will work on K8 cores, though.

> If any of the above can be corrected or, at least, documented, before 
> release, we stand a little bit better chance of getting the praise 
> otherwise well-deserved by FreeBSD... Thanks. Yours,

Documentation in FreeBSD seems quite a bit better than that of other
open source projects, but it is not perfect and the handbook, in
particular, will always lag a bit. Feel free to contribute suggested
changes to the documentation team (doc@). I hope to spend a bit of time
in this area after I retire.
-- 
R. Kevin Oberman, Network Engineer
Energy Sciences Network (ESnet)
Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab)
E-mail: oberman at es.net			Phone: +1 510 486-8634
Key fingerprint:059B 2DDF 031C 9BA3 14A4  EADA 927D EBB3 987B 3751