On Wed, Jul 7, 2010 at 1:17 PM, Mikhail T. <mi+t...@aldan.algebra.com> wrote: > 07.07.2010 14:59, Jeremy Chadwick ???????(??): >>> >>> 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. >> > > Attached is the kernel config-file (i386), that worked fine under 7.x. The > kernel-compile will break (some *freebsd7* structs undefined), without the > COMPAT_FREEBSD7 option. Try it for yourself...
Don't use a kernel config from 7. We've already told you this. >>> >>> 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. >> > > Put "device ugen" back into the attached kernel-config file and see config's > error yourself. >>> >>> 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. > > If it were merely "deprecated" it would've still worked. It does not -- put > "device sio" into the attached kernel-config and try building -- you'll get > the compile-error. Whether deliberately or through bit-rot, uart /replaced/ > sio... >> >> 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. >> > > Yes, your way is fine. But so is mine. It is perfectly reasonable to expect > my method to work just as well -- the 7->8 is not revolutionary, but simply > the next step. I read the "UPDATING" file and, though annoyed a little, took > care of things mentioned in there... The remaining things are enumerated > here... Your way clearly isn't fine, as it doesn't work. >>> >>> (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. >> > > Well, pardon the political pun, but I don't believe in change for the sake > of change. These particular changes are gratuitous. If sio is no longer > available -- and replaced by uart, why change the /dev-entries?.. These changes aren't gratuitous. Did you read the commit messages behind each of the changes? I'm guessing that you haven't. >>> >>> 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/ >> > > No, this is not it /at all/. The link above describes a crash in the BIOS > (and no POST), if firewire circuitry is disabled in BIOS. My problem is with > FreeBSD kernel hanging on boot, if the firewire circuitry is enabled in > BIOS. The boot was fine under 7.x, so this can not be due to a BIOS-bug -- > the only thing, that changed, is the OS... Yes. Sometimes there are bugs that exist that aren't triggered until an external influence makes them apparent. >> >> 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)? >> > > Yes. >> >> 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 >> > > Will do, thanks! Still, I was hoping, things will "just work" with 8.1... >> >> 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. >> > > While renovating the house, I ran USB-, audio-, and video-cables through the > walls from "server room" to the office, so I can sit in front of the > monitors and keyboard/mouse, while the actual computers are well insulated > behind closed door. PS/2 cables can't run the same length, it turns out... >>> >>> 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. >> > > Again: this particular change seems gratuitous. It's not. You didn't bother researching before complaining. To put it in simple terms, there were changes made to geom, and the way that sysinstall writes out dedicated disks wasn't compatible. Search the mailing list archives. >> >> "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. > > Yes, the "taking care" part is fine -- the filesystems all work. But the > renaming is unwelcome. >> >> Re: aliases: see above. >> > > The only talk of aliases "above" was regarding sio/uart -- you said, sio is > deprecated, but could exist alongside uart. That argument (however flawed it > was, in my above-expressed opinion) does not apply here... >>> >>> 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 >>> beclaimed >>> 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 >> > > Yes, you can -- you extract the CD-image there > <http://jdc.parodius.com/freebsd/pxeboot_serial_install_8.html#step4> > (doubling the storage requirements), and then modify the loader.conf > <http://jdc.parodius.com/freebsd/pxeboot_serial_install_8.html#step6>. That > modification should not be necessary -- the thing ought to figure the > situation out automatically. That it does not (not quite), was my complaint, > although I was following a different recipe > <http://www.freebsdwiki.net/index.php/Installing_FreeBSD_with_netboot>. The modification should be necessary. Just because you don't want to make the modification doesn't mean it was made that way by accident. That variable can be set to any number of things. We don't advertise the iso image just working out of the box for pxe booting. In fact, the article about PXE booting on the official freebsd website says nothing about using the ISO. You just found some article that said it was possible (and it is) and complained because you didn't like the process? >> >> Try loading the kernel module amdtemp and see if things improve. Be >> sure to read the man page. >> > > Loading amdtemp was not necessary on the Opteron system, where the k8temp > utility "just works" even after the upgrade. Doing it did not help the > Athlon system, where k8temp continues to not work... Funny. It works just fine in 8.0 on my Athlon. Have you tried updating the port? Also, even if it didn't work, this is an issue you should take up with the author of the port. If you had read the commit logs, you would have seen that the device was renamed because k8temp didn't make sense anymore. >From the man page: The amdtemp driver provides support for the on-die digital thermal sensor present in AMD K8, K10 and K11 processors. I am removing re@ from this thread. You might think about emailing the appropriate mailing lists with questions first before doing the equivalent of stomping your feet and asking to speak to the manager of the candy store, especially since many of your complaints are uninformed and bogus. -- randi _______________________________________________ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"
