From owner-freebsd-stable@FreeBSD.ORG Wed Jul 7 19:35:11 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D852F1065676; Wed, 7 Jul 2010 19:35:11 +0000 (UTC) (envelope-from oberman@es.net) Received: from mailgw.es.net (mail1.es.net [IPv6:2001:400:201:1::2]) by mx1.freebsd.org (Postfix) with ESMTP id 844CC8FC16; Wed, 7 Jul 2010 19:35:11 +0000 (UTC) Received: from ptavv.es.net (ptavv.es.net [IPv6:2001:400:910::29]) by mailgw.es.net (8.14.3/8.14.3) with ESMTP id o67JYtRG008224 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 7 Jul 2010 12:34:55 -0700 Received: from ptavv.es.net (localhost [127.0.0.1]) by ptavv.es.net (Tachyon Server) with ESMTP id 786CD1CC0D; Wed, 7 Jul 2010 12:34:55 -0700 (PDT) To: "Mikhail T." In-reply-to: Your message of "Wed, 07 Jul 2010 14:22:22 EDT." <4C34C5DE.7040007@aldan.algebra.com> Date: Wed, 07 Jul 2010 12:34:55 -0700 From: "Kevin Oberman" Message-Id: <20100707193455.786CD1CC0D@ptavv.es.net> X-Proofpoint-Virus-Version: vendor=fsecure engine=1.12.8161:2.4.5, 1.2.40, 4.0.166 definitions=2010-07-07_03:2010-02-06, 2010-07-07, 2010-07-07 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=5.0.0-1005130000 definitions=main-1007070089 Cc: re@freebsd.org, tom@hur.st, freebsd-stable@freebsd.org, freebsd-usb@freebsd.org Subject: Re: 8.x grudges X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jul 2010 19:35:11 -0000 > Date: Wed, 07 Jul 2010 14:22:22 -0400 > From: "Mikhail T." > Sender: owner-freebsd-stable@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 > ), 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@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751