On 11/13/2009 03:02 PM, Oncaphillis wrote: > On 11/13/2009 09:43 PM, Michael Buesch wrote: >> On Friday 13 November 2009 21:36:31 Oncaphillis wrote: >>> On 11/13/2009 08:20 PM, Larry Finger wrote: >>> > On 11/13/2009 11:46 AM, Oncaphillis wrote: >>> > >>> >> Thanks for the tip. But it still hangs >>> > >>> > We still need to know where it hangs. If you boot to console mode >>> (type a 3 on >>> > the option line in GRUB), does it boot? If it does not, what is the >>> last line >>> > shown on the console? If your distro shows a splash screen while >>> booting, get >>> > rid of it by typing an ESC after booting starts, or eliminate the >>> > "splash=silent" option on the boot line. >>> > >>> > If the previous boot works, log into your usual account. That should >>> still work. >>> > Next you should type the command startx and immediately press the keys >>> > CRTL-ALT-F10. That is hold the CTRL and ALT keys while pressing the >>> F10 key. The >>> > display should shift to the log console. When the computer freezes, >>> report what >>> > you see on the screen. It will not scroll, nor can you save it. Write >>> it down by >>> > hand or take a picture. >>> >>> Sorry for not giving the details. I'm using Fedora 11 with 2.6.32-rc7 >>> kernel. I've turned of the splash screen and boot into runlevel 3. The >>> last line I see is that the distro tries to start up udev -- No oops or >>> such thing. >>> >>> I also did the following -- (1) removed the whole /lib/modules/XXX/ tree >>> and booted into the kernel. (2) Made "make modules_install;depmod -a". >>> If I do a "modprobe b43" it still freezes without any further message. >>> Surprisingly if I only remove b43.ko from the module tree it still hangs >>> on reboot. Looks like a "inter module" problem to me. The only other >> >> Looks like not related to b43, to me. > > Yes -- but if I leave the kernel config like it is and > only leave out b43 it boots fine. > >> >> You could try to enable most of the kernel debugging options in the "kernel >> hacking" menu. >> Memory corruption, lock debugging and softlockup detection options are the >> most interesting. >> > > I'll give that a try.
PLease look at the files in /etc/udev/rules.d. Any of those involved? Certainly the "persistent network" rules will be involved. I'm not sure of the name. On my system, it is 70-persistent-network.rules. Larry _______________________________________________ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
