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
On Wed, Jul 7, 2010 at 11:22 AM, Mikhail T. <mi+thun@aldan.algebra.com> wrote:> ?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...This shouldn't be the case. IIRC, nothing has changed that would cause this. More info on your environment please?
On Wed, 07 Jul 2010 14:22:22 -0400 "Mikhail T." <mi+thun@aldan.algebra.com> wrote:> 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).In case you are not aware of it: amdtemp(4) performs the same function (more or less) as k8temp. HTH -- Torfinn
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: NoTry 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 |
> Date: Wed, 07 Jul 2010 14:22:22 -0400 > From: "Mikhail T." <mi+thun@aldan.algebra.com> > 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 > <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: Nok8temp 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
On 2010-Jul-07 14:22:22 -0400, "Mikhail T." <mi+thun@aldan.algebra.com> wrote:>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"It's a bit difficult to provide any useful input without some idea of what the picture should and does look like. Can you please post the actual bitmap as well as a picture of your screen showing the problem.> 3. > Likewise, having "device ugen" breaks config(8) -- another > undocumented incompatibility.Can you please advise where it is documented that "device ugen" is valid in a FreeBSD-8 config file?> 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.I haven't seen this on any of my systems. Can you please provide details of your motherboard, BIOS and the output from a verbose boot up to the hang. Is there a BIOS update available and have you tried installing it?> 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...I have had similar problems on one of my USB-only desktops. In my case, moving the keyboard to a different USB port solved the problem. All I can suggest is to work your way through all the USB ports you have available and see if they all behavee the same. -- Peter Jeremy -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 196 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20100708/5acc9a28/attachment.pgp
31.07.2010 01:17, Peter Jeremy ???????(??):> kenv(1) (in the base) should as well. >Cool! Here it is: smbios.bios.reldate="08/13/2003" smbios.bios.vendor="American Megatrends Inc." smbios.bios.version="3.13 " smbios.chassis.maker="Chassis Manufacture" smbios.chassis.serial="Chassis Serial Number" smbios.chassis.tag="Asset-1234567890" smbios.chassis.version="Chassis Version" smbios.memory.enabled="1048576" smbios.planar.maker="ASUSTeK Computer INC." smbios.planar.product="A7N8X-LA" smbios.planar.serial="X312345678" smbios.planar.version="Rev 1.xx" smbios.socket.enabled="1" smbios.socket.populated="1" smbios.system.maker=" " smbios.system.product=" " smbios.system.serial=" " smbios.system.uuid="00020003-0004-0005-0006-000700080009" smbios.system.version=" " smbios.version="2.3" Yours, -mi