Re: 8.x grudges
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
[panic] Race in IEEE802.11 layer towards device drivers
Hi, When supplying wpa_supplicant.conf with incorrect passwords, but a valid SSID, I have seen kernel panics several times when using USB based WLAN dongles. When only supplying a valid password, no panic has been seen. How to reproduce: 1) configure invalid password 2) wpa_cli: reconfigure 3) configure valid password 4) wpa_cli: reconfigure 5) goto 1 The USB commands which are executed inside the newstate callback usually take very little time, but still not as little time as PCI read/writes. I've forced slower operation in the newstate callback, and can reproduce warning printouts from the IEEE802.11 layer in FreeBSD. Try to apply the following patch to your USB code: http://p4web.freebsd.org/@@180604?ac=10 In my opinion the deferring of all states to a single task is wrong. There should be at least one task per possible state, and the queuing mechanism should follow the last-queued is last executed rule. This is not the case with the task-queue mechanism in the kernel. See the USB code's task-queue replacement which I think the IEEE802.11 stack in FreeBSD could take advantage of. src/sys/dev/usb/usb_process.c Description of panics. I didn't have core dump enabled on this box, so please bear over with the following hand-written notes: 1) A vap-iv_bss == NULL, inside ratectl task in RUM driver. 2) A memcpy() fails inside the iee80211...newstate_cb() 3) This and similar printouts are seen: wlan0: ieee80211_new_state_locked: pending AUTH - ASSOC transition lost --HPS ___ 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
8.x grudges
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: *ro...@quokka:~ (101) k8temp *ro...@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 ___ 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
Re: 8.x grudges
Date: Wed, 07 Jul 2010 14:22:22 -0400 From: Mikhail T. mi+t...@aldan.algebra.com Sender: owner-freebsd-sta...@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
Re: 8.x grudges
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... 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... (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?.. 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... 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
Re: 8.x grudges
07.07.2010 16:34, Randi Harper ???(??): 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. Your telling me this is just as valid as warning me against using computer-cases of a particular color. It is a silly requirement. My expecting things, that worked for 7, to work in 8 is reasonable. There may be (documented!) exceptions, but it ought to just work. 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. That's an obviously flawed argument -- this line of thinking can be used against ANY ONE reporting ANY BUG -- if one has a problem, then one's way of doing things clearly isn't fine. These changes aren't gratuitous. Did you read the commit messages behind each of the changes? I'm guessing that you haven't. No, and I'm not going to. A commercial OS would've been the laughing stock, if one hand to change C: to 1: between releases, for example... Again: this particular change seems gratuitous. It's not. You didn't bother researching before complaining. I bothered to type up my list. Presumably, problem-reports are welcome. I've been a Unix-user since 1990, a FreeBSD user since 1993 (or 94?), and a project-member for a decade. If *I* have a problem, then newer users certainly will too. And, guess what, they'll simply go with something, that does not give as much grief... 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. If this is a known problem, it is even more of an outrage, that some shim was not introduced to keep the users from hitting this particular bump. The modification should be necessary. Why? Why should a netboot act differently from a local boot from CD? Just because you don't want to make the modification doesn't mean it was made that way by accident. No, I never claimed this to have been an 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. You don't. But there is very little, that needs to be added there for it to just work over both netboot and local CD, and you should do it, instead of arguing with me here... No, I don't know, what it is exactly, but I'm quite certain, it can't be very much. 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? Yes, exactly. I didn't like process -- it is needlessly complicated. The same CD-image, /should/ also be usable out of the box for netbooting. Funny. It works just fine in 8.0 on my Athlon. Have you tried updating the port? Yes, I have -- and I said so in my very first e-mail on this subject. For someone, who expects people to research mailing lists, you do a terrible job of following a one-day-old thread... Also, even if it didn't work, this is an issue you should take up with the author of the port. Tom -- the maintainer -- is still in CC... 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 know nothing about the driver. But a utility I regularly used stopped working after upgrade, so I added that to my list of upgrade-related grudges. -mi ___ 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
Re: 8.x grudges
On Wed, Jul 7, 2010 at 1:52 PM, Mikhail T. mi+t...@aldan.algebra.com wrote: 07.07.2010 16:34, Randi Harper ???(??): 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. Your telling me this is just as valid as warning me against using computer-cases of a particular color. It is a silly requirement. My expecting things, that worked for 7, to work in 8 is reasonable. There may be (documented!) exceptions, but it ought to just work. 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. That's an obviously flawed argument -- this line of thinking can be used against ANY ONE reporting ANY BUG -- if one has a problem, then one's way of doing things clearly isn't fine. These changes aren't gratuitous. Did you read the commit messages behind each of the changes? I'm guessing that you haven't. No, and I'm not going to. A commercial OS would've been the laughing stock, if one hand to change C: to 1: between releases, for example... Again: this particular change seems gratuitous. It's not. You didn't bother researching before complaining. I bothered to type up my list. Presumably, problem-reports are welcome. I've been a Unix-user since 1990, a FreeBSD user since 1993 (or 94?), and a project-member for a decade. If *I* have a problem, then newer users certainly will too. And, guess what, they'll simply go with something, that does not give as much grief... 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. If this is a known problem, it is even more of an outrage, that some shim was not introduced to keep the users from hitting this particular bump. The modification should be necessary. Why? Why should a netboot act differently from a local boot from CD? There's a lot of secret sauce done for detecting whether or not you're booting from CD vs pxebooting in a release image, as well as within the sysinstall application as to what environment its dealing with, as well as what you get after things are done with a vanilla build and a sysinstall install (as I've discovered on my own). Unfortunately assuming both methods to produce the same result is flawed :(... Thanks, -Garrett ___ 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
Re: 8.x grudges
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/ Looking at this link, it doesn't match the described issue. Mikhail's machine would not boot *until* he disabled the firewire controller in the BIOS. The referenced issue on that Shuttle based machine talks about disabling the firewire controller and *then* it still being alive when the system powers on and crashing the system. I interpret this as a bug. Sean Also, I suck at reply-to. sean ___ 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
Re: 8.x grudges
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/ Looking at this link, it doesn't match the described issue. Mikhail's machine would not boot *until* he disabled the firewire controller in the BIOS. The referenced issue on that Shuttle based machine talks about disabling the firewire controller and *then* it still being alive when the system powers on and crashing the system. I interpret this as a bug. Sean ___ 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
Re: 8.x grudges
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...
options SYSVSHM # SYSV-style shared memory
options SYSVMSG # SYSV-style message queues
options SYSVSEM # SYSV-style semaphores
Those require COMPAT_FREEBSD7. This does seem like a bug:
static struct syscall_helper_data shm_syscalls[] = {
SYSCALL_INIT_HELPER(shmat),
SYSCALL_INIT_HELPER(shmctl),
SYSCALL_INIT_HELPER(shmdt),
SYSCALL_INIT_HELPER(shmget),
#if defined(COMPAT_FREEBSD4) || defined(COMPAT_FREEBSD5) || \
defined(COMPAT_FREEBSD6) || defined(COMPAT_FREEBSD7)
SYSCALL_INIT_HELPER(freebsd7_shmctl),
#endif
The check should be for COMPAT_FREEBSD7 only I would think.
Apart from that, everything else should work without it I would think.
Thanks,
-Garrett
___
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
Re: 8.x grudges
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 7/7/10 4:17 PM, Mikhail T. 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... Jeremy is correct. COMPAT_FREEBSD7 means, despite this being FreeBSD 8, set things that have changed up to work in a way that is compatible with FreeBSD 7 *wherever* *possible*. Since you are trying to use a FreeBSD 7 based kernel config file you need that option, but people not trying to hold on to the FreeBSD 7 ways of doing things do not need that option. I'm not quite sure why you find that surprising, though it may have to do with a mis-conception on your part described below. 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... Actually it's not perfectly reasonable to *expect* your method to work just as well given the general goals of the FreeBSD Project as a whole. Your method *may* work but it's by no means guaranteed, or even a major priority I'm afraid. Your method *may* work. But you can't *expect* it. We like many similar Projects have a wide variety of people involved (both developers and end-users) and an equally wide variety of needs those people have. On the one extreme we have developers who feel their hands are tied by not being able to make user-visible changes to stuff - they feel they could make the system better faster if they could change things in incompatible ways faster. On the other extreme we have people who hate change for reasons similar to what you are expressing here - it's a pain in the butt to need to change config files, it sucks if all the old executable files suddenly stop working, etc. So, there has been a long-standing compromise in place. For bumps in *minor* version numbers you can expect to be able to use your old config files, old executables continue to work, etc. This is, for example, moving from 7.2 to 7.3. However for bumps in *major* version numbers there can and likely will be changes made that cause exactly what you are seeing here. A 7.X kernel config file *might* work OK on 8.X but we do not guarantee that. If it does happen to work great, if not sorry. What you call simply the next step is a bump in minor version number. Depending on how active the developers have been and what they've focused on major version number bumps *can* qualify as what you call revolutionary. This general mode of operation has been in place for a very long time (it pre-dates my involvement on the Release Engineering Team). - -- Ken Smith - - From there to here, from here to | kensm...@buffalo.edu there, funny things are everywhere. | - Theodore Geisel | -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkw1Oc0ACgkQ/G14VSmup/bEiQCfdtr8UkPp/QRcwUpGTlpRtJ2f RNsAn3+cV4jDuyQ38Wvm5eTiVObJ4DLy =4Bm7 -END PGP SIGNATURE- ___ 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
Re: [panic] Race in IEEE802.11 layer towards device drivers
On 8 July 2010 07:13, Hans Petter Selasky hsela...@c2i.net wrote: Hi, When supplying wpa_supplicant.conf with incorrect passwords, but a valid SSID, I have seen kernel panics several times when using USB based WLAN dongles. When only supplying a valid password, no panic has been seen. How to reproduce: 1) configure invalid password 2) wpa_cli: reconfigure 3) configure valid password 4) wpa_cli: reconfigure 5) goto 1 The USB commands which are executed inside the newstate callback usually take very little time, but still not as little time as PCI read/writes. I've forced slower operation in the newstate callback, and can reproduce warning printouts from the IEEE802.11 layer in FreeBSD. Try to apply the following patch to your USB code: http://p4web.freebsd.org/@@180604?ac=10 In my opinion the deferring of all states to a single task is wrong. There should be at least one task per possible state, and the queuing mechanism should follow the last-queued is last executed rule. This is not the case with the task-queue mechanism in the kernel. You dont say why it should be this way, do you have an example of a problem this fixes? I think the single state thread is correct. The whole thing works on state transitions, you dont just set a state. Description of panics. I didn't have core dump enabled on this box, so please bear over with the following hand-written notes: 1) A vap-iv_bss == NULL, inside ratectl task in RUM driver. 2) A memcpy() fails inside the iee80211...newstate_cb() 3) This and similar printouts are seen: wlan0: ieee80211_new_state_locked: pending AUTH - ASSOC transition lost Can you see if you can get a core dump, or at least a DDB trace and the output from `show vap addr` Andrew ___ 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
