Date: Wed, 7 Jul 2010 13:34:35 -0700 From: Randi Harper <randi@freebsd.org> To: "Mikhail T." <mi+thun@aldan.algebra.com> Cc: tom@hur.st, freebsd-stable@freebsd.org, freebsd-usb@freebsd.org, Jeremy Chadwick <freebsd@jdc.parodius.com> Subject: Re: 8.x grudges Message-ID: <AANLkTimdSWkgOYaSp-sWVd2fHtjv65zEVCJIT6mHlNC5@mail.gmail.com> In-Reply-To: <4C34E0E6.9070801@aldan.algebra.com> References: <4C34C5DE.7040007@aldan.algebra.com> <20100707185928.GA16180@icarus.home.lan> <4C34E0E6.9070801@aldan.algebra.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Jul 7, 2010 at 1:17 PM, Mikhail T. <mi+thun@aldan.algebra.com> wrot= e: > 07.07.2010 14:59, Jeremy Chadwick ???????(??): >>> >>> =A0 =A0 =A0FREEBSD_COMPAT7 kernel option is, apparently, a requirement = (and >>> =A0 =A0 =A0thus not an "option") -- the kernel-config files, that worke= d with >>> =A0 =A0 =A07.x, break without this option in them (in addition to all t= he >>> =A0 =A0 =A0nuisance, that's documented in UPDATING -- which, somehow, m= akes >>> =A0 =A0 =A0the breakage acceptable). config(8) would not warn about thi= s, but >>> =A0 =A0 =A0kernel build fails. >>> >> >> We don't use this option (meaning it's removed from our kernels). =A0It'= s >> definitely not required. =A0All 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. Th= e > kernel-compile will break (some *freebsd7* structs undefined), without th= e > COMPAT_FREEBSD7 option. Try it for yourself... Don't use a kernel config from 7. We've already told you this. >>> >>> =A0 3. Likewise, having "device ugen" breaks config(8) -- another >>> =A0 =A0 =A0undocumented incompatibility. >>> >> >> This sounds like you not including all of the necessary USB/device >> framework in your kernel configuration. =A0You'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 confi= g's > error yourself. >>> >>> =A0 4. The sio(4) is described in UPDATING as "removed", but rouses no >>> =A0 =A0 =A0complaint from config(8) either. It just breaks the kernel >>> =A0 =A0 =A0build... It should be an alias for uart, IMHO -- all I want = is for >>> =A0 =A0 =A0my serial ports to be usable, whether their driver is called >>> =A0 =A0 =A0"Serial Input/Output" or "Universal Asynchronous Receiver an= d >>> =A0 =A0 =A0Transmitter". >>> >> >> I disagree (re: "it should be an alias"). =A0sio(4) is deprecated (meani= ng >> 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 -- p= ut > "device sio" into the attached kernel-config and try building -- you'll g= et > the compile-error. Whether deliberately or through bit-rot, uart /replace= d/ > 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. =A0Things 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 expe= ct > my method to work just as well -- the 7->8 is not revolutionary, but simp= ly > the next step. I read the "UPDATING" file and, though annoyed a little, t= ook > care of things mentioned in there... The remaining things are enumerated > here... Your way clearly isn't fine, as it doesn't work. >>> >>> =A0 =A0 =A0(BTW, about the /dev-entries -- do we /really/ have to chang= e the >>> =A0 =A0 =A0names of the serial port-devices every couple of years? It i= s >>> =A0 =A0 =A0rather painful to reconfigure the fax- and ppp-software, etc= .) How >>> =A0 =A0 =A0does the Microsoft world manage to stay with the COM1, COM2 = for >>> =A0 =A0 =A0decades?) >>> >> >> Like I said: things change. >> > > Well, pardon the political pun, but I don't believe in change for the sak= e > 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. >>> >>> =A0 5. One of the upgraded systems would repeatedly hang at boot, until= I >>> =A0 =A0 =A0disabled the on-board firewire-device through the BIOS... It= was >>> =A0 =A0 =A0not a problem under 7.x, although I don't know, whether the = device >>> =A0 =A0 =A0actually worked. >>> >> >> This is a commonly-reported problem, assuming "at boot" you mean "while >> the kernel is starting". =A0Or 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-bi= os-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 w= ith > 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). =A0When 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 insulate= d > behind closed door. PS/2 cables can't run the same length, it turns out..= . >>> >>> =A0 7. All my "dangerously dedicated" disks lost the "s1" in the >>> =A0 =A0 =A0subdevice-names after the upgrade: /dev/da1s1d became /dev/d= a1d, >>> =A0 =A0 =A0etc. I like the shorter names (and there are, indeed, no "sl= ices" >>> =A0 =A0 =A0there), but having to fix them manually upon reboot was unpl= easant >>> =A0 =A0 =A0and uncalled for. As with uart/sio, backward-compatibility a= liases >>> =A0 =A0 =A0are 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). =A0GEOM 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... >>> >>> =A0 8. I tried to do an install on one of the systems via netbooting >>> =A0 =A0 =A0(pxeload) the disk1-image. It booted, but the sysinstall had= to >>> beclaimed >>> =A0 =A0 =A0started manually and, once started, did not act the same as = when >>> =A0 =A0 =A0booted off of CD-ROM. Seems like a simple bit to correct so = that >>> =A0 =A0 =A0setting "init" to /usr/sbin/sysinstall/manually on every boo= t/ is >>> =A0 =A0 =A0not 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>. Th= at > modification should not be necessary -- the thing ought to figure the > situation out automatically. That it does not (not quite), was my complai= nt, > 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. =A0Be >> 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 sen= sor 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?AANLkTimdSWkgOYaSp-sWVd2fHtjv65zEVCJIT6mHlNC5>