>*** Sorry to rearrange this message -- but post.gmane.org was
>*** complaining about top-posting. My contribution to this thread is at
>*** the bottom ...
>> -----Original Message-----
>> From: ndiswrapper-general-admin <at> lists.sourceforge.net
>> [mailto:ndiswrapper-general-admin <at> lists.sourceforge.net] On Behalf Of
>> Olivier Fourdan
>> Sent: Monday, March 14, 2005 15:57
>> To: ndiswrapper-general <at> lists.sourceforge.net
>> Subject: [Ndiswrapper-general] ndiswrapper/broadcom/amd64/nforce =
>> kernel panic?
>> I've been fighting with this for a while (a couple of months), and just
>> found the correct log.
>> I'm using ndiswrapper-1.1 with a Broadcom Wireless built-in an 64 bit
>> AMD64 laptop. Most of the time, when I "modprobe ndiswrapper", the whole
>> system freeze with a kernel panic.
>> The log gives:
>> modprobe ndiswrapper
>> ACPI: PCI Interrupt Link [LNK3] enabled at IRQ 11
>> CPU 0: Machine Check Exception: 4 bank 4: b200000000070f0f
>> TSC ba428433ac
>> Kernel panic - not syncing: Machine check
>> At first, I thought it might be an issue with apic and nforce so I
>> disabled apic (with "noapic" and also "acpi=noirq" at boot) but that
>> makes no difference. I thought of a hardware issue, but everything seems
>> fine under Windows XP. No freeze, and wireless works fine.
>> This is on a Compaq R3480 AMD64 3400+ laptop, using a vanilla 22.214.171.124
>> kernel (but that was the same with older Fedora kernels)
>> What is really odd is that it sometimes (rarely) works, and when that
>> happen I'm able to used wifi w/out any problem. Maybe it's a IRQ
>> conflict, but how can I fix this?
>> I'm using the netbc564 driver (64bit version).
>> 02:02.0 Network controller: Broadcom Corporation BCM4306 802.11b/g
>> Wireless LAN Controller (rev 03)
>> Subsystem: Hewlett-Packard Company: Unknown device 12fa
>> Flags: bus master, fast devsel, latency 64, IRQ 11
>> Memory at e0104000 (32-bit, non-prefetchable) [size=8K]
>> ndiswrapper -l gives :
>> Installed ndis drivers:
>> netbc564 driver present, hardware present
>> cat /proc/interrupts
>> 0: 1018089 XT-PIC timer
>> 1: 349 XT-PIC i8042
>> 2: 0 XT-PIC cascade
>> 7: 2 XT-PIC parport0
>> 8: 0 XT-PIC rtc
>> 9: 23 XT-PIC acpi
>> 10: 1997 XT-PIC eth0, NVidia nForce3 Modem, ehci_hcd,
>> ohci_hcd, yenta
>> 11: 16449 XT-PIC NVidia nForce3, ohci_hcd, yenta,
>> ohci1394, nvidia
>> 12: 127 XT-PIC i8042
>> 14: 18016 XT-PIC ide0
>> 15: 7364 XT-PIC ide1
>> NMI: 154
>> LOC: 1017659
>> ERR: 0
>> MIS: 0
>> Please mail me directly as I'm not subscribed to any of the ndiswrapper
>> Thanks in advance,
Benzinger, Michael <Michael.Benzinger <at> sabre-holdings.com> writes:
> There are the same symptoms I have been having. I found that with the
> stock 2.6.11 kernel I could get the driver to load but the events/0
> process would be using 90-95% of the CPU making the system almost
> entirely unusable. I also found that when loading the driver, if it
> locked up I could turn off the antenna and the system would come back to
> life and I was able to rmmod the driver. What is real weird, like you,
> is sometimes it would work great and I was able to use wireless until I
> rebooted again. Since ACPI suspend doesn't work this is at least once a
> day. It would be nice to pinpoint the exact cause of this but I have not
> had any luck.
> Mike Benzinger
This is also EXACTLY the same symptoms that I have been experiencing.
I also have an AMD64 Compaq 3000Z but I have never tried anything but
stock FC3 kernels. However, I still have had the same experience with
events/0 process hogging the processor, and if I turn off the antenna
the system returns to normal (and I can then rmmod the driver). It
also worked OK for me a couple of times, but that was only 2 of about
HOWEVER - I recently have had consistent success. I have found that
with the latest nvidia driver (1.0-7167), I can reliably get the
wireless card working by performing the following steps:
1) don't load ndiswrapper at boot (clear modprobe.conf of ndiswrapper entries,
2) boot up with wireless on
3) login to X session, allow X session to fully initialize desktop
4) modprobe -v ndiswrapper if_name=eth1
I can't explain it, but if I don't do step 3 it won't work.
I initially thought that there is some weird interaction with the
nvidia driver and ndiswrapper, and I tried the following 'clever'
options ndiswrapper if_name=eth1
alias eth1 ndiswrapper
install ndiswrapper /sbin/modprobe nvidia ; \
/sbin/modprobe --ignore-install ndiswrapper
[the above snippet is 4 lines - a comment and 3 modprobe.conf commands]
The point of that last line was to ensure that the nvidia driver loads
before ndiswrapper. Unfortunately, this didn't work, and the machine
appeared to hang during the "initializing hardware" part of the boot
process (actually, it didn't hang, if I left it alone it would just
continue booting agonizingly slowly). Once I punched the wireless
power button, the system sprang to life and booted at normal speed.
So, I am still leaning towards some mysterious interaction with the
nvidia driver. I guess it could also be that X causes something else
to load that clears up the problem, but I'm not sure how to pursue
that line of reasoning.
It would be interesting to hear if this procedure worked for the
others that have been experiencing this problem.