Date: Wed, 7 Jul 2010 11:59:28 -0700 From: Jeremy Chadwick <freebsd@jdc.parodius.com> To: "Mikhail T." <mi+thun@aldan.algebra.com> Cc: re@freebsd.org, tom@hur.st, freebsd-stable@freebsd.org, freebsd-usb@freebsd.org Subject: Re: 8.x grudges Message-ID: <20100707185928.GA16180@icarus.home.lan> In-Reply-To: <4C34C5DE.7040007@aldan.algebra.com> References: <4C34C5DE.7040007@aldan.algebra.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Jul 07, 2010 at 02:22:22PM -0400, Mikhail T. wrote: > 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. > > 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. We don't use this option (meaning it's removed from our kernels). It's definitely not required. All it does is ensure your kernel can comprehend executables/binaries built on 7.x. > 3. > Likewise, having "device ugen" breaks config(8) -- another > undocumented incompatibility. This sounds like you not including all of the necessary USB/device framework in your kernel configuration. You're not providing enough output for us to help diagnose the problem, though. Be aware that config(8) changed during recent days and requires a rebuild, although the build infrastructure normally instructs you to do this (otherwise kernel won't build). I noticed it when upgrading from an "early" version of RELENG_8 to a more recent version, and it was kind enough to tell me to rebuild it. > 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". I disagree (re: "it should be an alias"). sio(4) is deprecated (meaning it's not used by default any more), and it's left in the driver tree solely as a fall-back method if someone runs into uart(4) problems. I'm sure it'll eventually be removed, but for now, it remains. The point I'm going to make here is this: sio(4) is different than uart(4). "Aliasing" one to the other will do nothing but confuse folks. If we're going to do that, why not rename all of our Ethernet interfaces "ethX" and so on? ;-) I'll take a moment to point out that your complaints about the kernel configuration file, so far, seem to stem from you not "migrating" your kernel configuration from 7.x to 8.x. Things change -- that's the reality of the situation. The way I do this is, when upgrading major releases (7.x->8.x), to "start fresh" using GENERIC as my base template and then adding/adjusting while comparing against the older kernels' config. Others do it differently, this is just how I do it. > (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?) Like I said: things change. > 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. This is a commonly-reported problem, assuming "at boot" you mean "while the kernel is starting". Or unless you're using a certain model of Shuttle box, but that turned out to be literally a BIOS bug: http://koitsu.wordpress.com/2009/05/22/shuttle-sg45h7-firewire-bug-in-bios-sg45u10o/ > 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... This is also a commonly-reported problem (and one I've harped on as well). When you say "during boot": does it work during loader (the screen with the "FreeBSD" logo on it)? If the keyboard works during loader but not once the kernel + kernel USB stack loads (e.g. when booting into single-user), then look at the very bottom of this page for a couple things to try: http://wiki.freebsd.org/BugBusting/Commonly_reported_issues If the keyboard DOES NOT work during loader, then it sounds like your BIOS isn't setting the system up so that USB keyboards get emulated as PS/2 (this setup gets stomped by the kernel later, obviously). Usually BIOSes offer an option like "USB Legacy Enable" or "USB Keyboard Enable" which provides this functionality. It's important to remember that there is no USB stack loaded via the bootstraps, which focus on your system/BIOS. Linux and Solaris have the same problem, as I understand it. Welcome to PC architecture "evolution", if you can call it that. :-) Regardless, this is one of the reasons I still have not made the move to USB keyboards and stick with PS/2 keyboards on FreeBSD. > 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... Again: things change. "Dangerously dedicated" disks are commonly deprecated at this point (as I understand it folks are trying to get away from them). GEOM takes care of this situation better than it used to. You'll probably find some other situations (using bsdlabel, etc. vs. using gpart (don't confuse this with GPT)) where things may get a little hairy based on your setup. I would have formatted the disk and gone from a clean slate. Re: aliases: see above. > 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... Can't reproduce: http://jdc.parodius.com/freebsd/pxeboot_serial_install.html > 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 Try loading the kernel module amdtemp and see if things improve. Be sure to read the man page. Hardware monitoring/thermal monitoring at this point is often implemented into the sysctl tree (Intel CPUs are done this way with coretemp(4), and ACPI thermal zones too). HTH. -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB |
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20100707185928.GA16180>