8.x grudges

[Mikhail T.]

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.
   3.
      Likewise, having "device ugen" breaks config(8) -- another
      undocumented incompatibility.
   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?)
   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.
   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...
   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...
   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...
   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

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,

    -mi