Jason Wood wrote: >> From: Larry Finger <[EMAIL PROTECTED]> >> >> Analysis of the two dmesg outputs cannot be completed as your kernel >> is compiled with a very small log buffer and it is wrapping around; >> however, I see enough to suspect some kind of race condition in the >> bus setup. I see a device with different IRQ's between the good/bad >> boots. That shouldn't happen. I do not think you are having hardware >> problems, and I'm pretty sure it is not a bcm43xx problem. >> >> Is it possible for you to upgrade to a 2.6.22 or 2.6.23-rc2 kernel? If >> so, please do. Whatever bug we are chasing may have already been fixed. >> >> If it is not possible to upgrade, I would like you to add the option >> 'log_buf_len=262144' when you boot. That will increase the size of the >> log buffer so that we see everything. Then send me the dmesg output >> from a good and a bad boot. >> >> Another thing to try is the boot option 'maxcpus=0'. That will run it >> as a unit processor system and eliminate a lot of potential problems >> with SMP. I'm particularly interested in knowing if it always works >> with this option, or if it also fails sometimes. >> >> What is the make/model of your laptop? I probably have that info >> somewhere, but I'm lazy. In addition, are your running a 32- or 64-bit >> system? >> >> Thanks, >> >> Larry >> > > I'm using a HP Pavilion dv6000. I'm currently trying to solve a > separate issue that leads me to believe this may be a bios or hardware > issue. I intermittently get bios beep codes for the video on startup, > forcing a power cycle. And of course HP support is unwilling to work > with me because of my OS choice. > > Anyway, I have working and non-working dmesg output attached with the > increased buffer limit set for kernel 2.6.22.1. I also attempted > booting with 'maxcpus=0' set, however the system hard locked at random > points each time. Line 278 of the dmesg.2.6.22.1.works file is where > the device first gets detected (0000:03:00.0), and does not show up in > the failed boot dmesg. With this kernel, I'm having some SELinux errors > I believe, but I don't think it affects the bcm43xx module.
The crucial difference between the two dmesg outputs is in the following difference, where the + indicates "good" and "-" means bad: @@ -275,6 +275,7 @@ PM: Adding info for pci:0000:00:18.0 PM: Adding info for pci:0000:00:18.1 PM: Adding info for pci:0000:00:18.2 PM: Adding info for pci:0000:00:18.3 +PM: Adding info for pci:0000:03:00.0 PM: Adding info for pci:0000:05:00.0 PM: Adding info for pci:0000:07:05.0 PM: Adding info for pci:0000:07:05.1 In the bad case, the pci adapter with the wireless device is not being recognized. No bus == no adapter. The dmesg output says 'ACPI: Please test with "acpi_osi=!Linux"'. Have you tried that? The next line says 'Please send dmidecode to [EMAIL PROTECTED]'. That is the output of a dmidecode command, which has to be run as root. Larry _______________________________________________ Bcm43xx-dev mailing list [email protected] https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
