Thread: [Ndiswrapper-general] ndiswrapper freezes system
Status: Beta
Brought to you by:
pgiri
From: Karol K. <kk...@gm...> - 2005-01-22 20:02:24
|
Hello, I have just compiled ndiswrapper-1.0rc3 and installed the 64-bit Broadcom drivers from linuxant's website (I have a Presarion R3000 running FC3). I followed the instructions from your website: [root@zorka ~]# ndiswrapper -i netbc564.inf Installing netbc564 Forcing parameter IBSSGMode|0 to IBSSGMode|2 Forcing parameter IBSSGMode|0 to IBSSGMode|2 Forcing parameter IBSSGMode|0 to IBSSGMode|2 Forcing parameter IBSSGMode|0 to IBSSGMode|2 Forcing parameter IBSSGMode|0 to IBSSGMode|2 Forcing parameter IBSSGMode|0 to IBSSGMode|2 Forcing parameter IBSSGMode|0 to IBSSGMode|2 [root@zorka ~]# ndiswrapper -l Installed ndis drivers: netbc564 driver present, hardware present But when I got the modprobe ndiswrapper, it just froze my system and I had to reboot. Searing your lists, I found a similiar problem and it said it is fixed in the CVS. So I installed CVS version of ndiswrapper, but no difference. Might it be that I have driverloader installed? I did stop it by /etc/init.d/driverloader stop before loading ndiswrapper. -- Cheers, Karol Krizka |
From: Jonathan B. <be...@gm...> - 2005-01-23 04:10:07
|
On Sat, 22 Jan 2005 12:02:17 -0800, Karol Krizka <kk...@gm...> wrote: > Hello, > I have just compiled ndiswrapper-1.0rc3 and installed the 64-bit > Broadcom drivers from linuxant's website (I have a Presarion R3000 > running FC3). I followed the instructions from your website: > [root@zorka ~]# ndiswrapper -i netbc564.inf > Installing netbc564 > Forcing parameter IBSSGMode|0 to IBSSGMode|2 > Forcing parameter IBSSGMode|0 to IBSSGMode|2 > Forcing parameter IBSSGMode|0 to IBSSGMode|2 > Forcing parameter IBSSGMode|0 to IBSSGMode|2 > Forcing parameter IBSSGMode|0 to IBSSGMode|2 > Forcing parameter IBSSGMode|0 to IBSSGMode|2 > Forcing parameter IBSSGMode|0 to IBSSGMode|2 > [root@zorka ~]# ndiswrapper -l > Installed ndis drivers: > netbc564 driver present, hardware present > > But when I got the modprobe ndiswrapper, it just froze my system and I > had to reboot. Searing your lists, I found a similiar problem and it > said it is fixed in the CVS. So I installed CVS version of > ndiswrapper, but no difference. > > Might it be that I have driverloader installed? I did stop it by > /etc/init.d/driverloader stop before loading ndiswrapper. > -- > Cheers, > Karol Krizka Hi Karol, You must have missed my earlier post to this list and the R3000 list. I get the same thing with FC3. The trick it to recompile the kernel *without* the CONFIG_DEBUG_SPINLOCK option. I opened up a Bugzilla entry about it: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=145549 asking that the option not be selected. As you can see, I got a response saying that they liked the option and that if something didn't work, it was ndiswrapper's problem. Obviously the workaround for the DEBUG_SPINLOCK isn't working too well, or maybe because this is on x86_64 platform. You guys at ndiswrapper have already done a great job with this, but any chance of getting this fixed? : ) I have recompiled the latest kernel (2.6.10-1.741_FC3, I think), only deselecting a few of the DEBUG kernel options, and it works great. I think I may go back and make a few more changes (like add NTFS support and change psmouse to a module, this was a test to see if it worked) and rebuild the rpm. You can grab the latest src.rpm and rebuild it yourself, or if you want, I can post mine for download once I get it cleaned up a bit. Jonathan |
From: Adrian Irving-B. <wis...@wi...> - 2005-01-23 04:36:32
|
On Sat, Jan 22, 2005 at 10:09:59PM -0600, Jonathan Berry wrote: > As you can see, I got a response saying that they liked the option > and that if something didn't work, it was ndiswrapper's problem. That seems kind of silly to me. If it's a debug option, it shouldn't be in a production kernel. If it's a production-level option, it shouldn't be called DEBUG. Right? |
From: David K. <dmk...@uc...> - 2005-01-24 20:13:47
|
The naming does seem strange, though the Dave Jones' comments made in the redhat bug report make sense - if something is triggering this, it is a bug in that software that should be fixed and continuing blindly sounds like a bad idea. One thing in ndiswrapper that has not been clear to me, is why ndiswrapper has problems with this. Is it that there is an incompatibility between the Windows and linux format for spinlocks when the CONFIG_DEBUG_SPINLOCK option is selected? This is my impression from the code. Is this a "bug" in ndiswrapper or a fundamental incompatibility? Also, from the comments made so far, it is not clear to me that people are still having CONFIG_DEBUG_SPINLOCK problems on non-64-bit machines. Is anyone using a 32bit machine having these problems? If it is a 64bit machine, it looks to me like 64 bit support is still a work in progress and I would suspect that is the source of the problem. Cheers, David On Sat, 2005-01-22 at 23:36 -0500, Adrian Irving-Beer wrote: > On Sat, Jan 22, 2005 at 10:09:59PM -0600, Jonathan Berry wrote: > > > As you can see, I got a response saying that they liked the option > > and that if something didn't work, it was ndiswrapper's problem. > > That seems kind of silly to me. If it's a debug option, it shouldn't > be in a production kernel. If it's a production-level option, it > shouldn't be called DEBUG. Right? |
From: Giridhar P. <gi...@lm...> - 2005-01-25 09:02:02
|
Windows uses 'unsigned long' for spinlock (defined as KSPIN_LOCK), which is same as spinlock_t in Linux if CONFIG_DEBUG_SPINLOCK is not enabled. So ndiswrapper can use KSPIN_LOCK as spinlock_t. However, when CONFIG_DEBUG_SPINLOCK is enabled, spinlock_t is defined as a structure with more fields. Obviously, then KSPIN_LOCK can't be used to store spinlock_t. The workaround in ndiswrapper for this is to use KSPIN_LOCK as a pointer to spinlock (pointer can be stored in 'unsigned long'). If a driver follows NDIS/Windows guidelines, which state that before using a spinlock, it should first be allocated, this should work. However, some buggy drivers don't call appropriate allocate function, so ndiswrapper won't have a chance to allocate a spinlock and store a pointer there. This is why some drivers work fine with CONFIG_DEBUG_SPINLOCK and others don't. This has nothing to do with 32bit or 64bit machines, but with the specific (Windows) driver. I think/hope there are no issues with this workaround in ndiswrapper. -- Giri |
From: Adrian Irving-B. <wis...@wi...> - 2005-01-25 14:18:06
|
On Tue, Jan 25, 2005 at 04:02:18AM -0500, Giridhar Pemmasani wrote: > > Windows uses 'unsigned long' for spinlock (defined as KSPIN_LOCK), > which is same as spinlock_t in Linux if CONFIG_DEBUG_SPINLOCK is not > enabled. So ndiswrapper can use KSPIN_LOCK as spinlock_t. However, > when CONFIG_DEBUG_SPINLOCK is enabled, spinlock_t is defined as a > structure with more fields. Obviously, then KSPIN_LOCK can't be used > to store spinlock_t. Cool, makes sense, thanks. I still fundamentally disagree with Fedora's keeping this option set in the kernel -- IMO, module developers should run with a debug- enabled kernel, and everyone else shouldn't need it. But I guess this is just a continuation of my fundamental disagreements with old RedHat policy, too. Guess I know now in retrospect why I was so eagar to dump them for Debian. ;) |
From: Giridhar P. <gi...@lm...> - 2005-01-26 08:32:47
|
Well, I figured another workaround for this problem and reimplemented spinlocks using this approach. Windows spinlock (KSPIN_LOCK) is now an index into an array of spinlocks that are allocated on-demand. With this scheme it is possible to check if a spinlock is valid or not etc. Right now spinlock implementation in ndiswrapper uses this approach irrespective of whether CONFIG_DEBUG_SPINLOCK is enabled or not. Of course, that means this implementation may break some drivers that worked earlier. So test latest nightly tarball (CVS is slow) and report if your driver used to work until yesterday but fails now or CONFIG_DEBUG_SPINLOCK caused problems until yesterday but works now. Until it is known to work without problems, the new implementation will be a bit verbose. Don't be alarmed if it complains about invalid spinlocks (unless you get kernel crash); the implementation should handle those "invalid" spinlocks. -- Giri |
From: David K. <dmk...@uc...> - 2005-01-27 20:09:30
Attachments:
ndiswrapper-buginfo
|
Hi, I guess I spoke too soon when I said that 1.0rc3 fixed the freezes. It appears that the freezes only occur after a reboot. Right after install, without rebooting, I can insert the module and try to bring up an interface (which fails, probably because I don't have access to the network - I am at the office where I use a wired interface, but I found a random wireless network and am trying to connect to that). After reboot, any attempt to bring up an interface freezes the system. I have tried this with 1.0rc2, same result. This is very strange as I am certain that I used one of the 1.0rc's with my home network at some point and it worked great. The only message in the logs indicating a problem is: Jan 27 11:39:15 localhost kernel: wlan0 (WE) : Wireless Event too big (277) That is the last log message before reboot. The only other possible sign of a problem is that, when I try "ifup wlan0", just before trying to determine the IP address and seconds before freezing, it spits out: Error for wireless request "Set Bit Rate" (8B26) Set failed on device wlan0: Operation not supported I am attaching the output of ndiswrapper-buginfo, but that didn't seem very informative. I am going to give it one more try and then I am going to revert to ndiswrapper v. 0.10, which I know works, and give it a try. More to come... Cheers, David On Wed, 2005-01-26 at 03:33 -0500, Giridhar Pemmasani wrote: > Well, I figured another workaround for this problem and reimplemented > spinlocks using this approach. Windows spinlock (KSPIN_LOCK) is now an > index into an array of spinlocks that are allocated on-demand. With > this scheme it is possible to check if a spinlock is valid or not > etc. Right now spinlock implementation in ndiswrapper uses this > approach irrespective of whether CONFIG_DEBUG_SPINLOCK is enabled or > not. Of course, that means this implementation may break some drivers > that worked earlier. So test latest nightly tarball (CVS is slow) and > report if your driver used to work until yesterday but fails now or > CONFIG_DEBUG_SPINLOCK caused problems until yesterday but works now. > > Until it is known to work without problems, the new implementation > will be a bit verbose. Don't be alarmed if it complains about invalid > spinlocks (unless you get kernel crash); the implementation should > handle those "invalid" spinlocks. > |
From: David K. <dmk...@uc...> - 2005-02-02 02:00:32
Attachments:
ndiswrapper.minor_spec_patch.2005-01-26.spec
|
Hi, I am attaching a very small patch to the spec file. I realized that when I tried to update that the package requirements for the kernel module were too specific and that you would have to delete all prior installations (even if for other kernels) in order to install a newer version. The attached patch fixes this - it only affects the spec file. Cheers, David P.S. Patch is against latest CVS. Generated with: cvs diff -u -r1.2 ndiswrapper.spec |
From: David K. <dmk...@uc...> - 2005-01-26 20:43:59
|
Hi, I tried the latest CVS and the 1.0rc4 tarball from sourceforge (downloaded today) on my FC3 system with latest redhat kernel and CONFIG_DEBUG_SPINLOCK enabled. Both caused freezes on my system. Reverting to 1.0rc3 (actually CVS from 2005-01-20), fixed the problem. My logs had the following regarding the crashes: Jan 26 12:03:39 localhost kernel: ndiswrapper version 1.0rc4 loaded (preempt=no,smp=no) Jan 26 12:03:39 localhost kernel: ndiswrapper: driver bcmwl5a (Broadcom,06/25/2004, 3.40.73.0) added Jan 26 12:03:39 localhost kernel: ACPI: PCI interrupt 0000:02:02.0[A] -> GSI 11 (level, low) -> IRQ 11 Jan 26 12:03:39 localhost kernel: ndiswrapper (KeInitializeSpinLock:133): spinlock: 0 Jan 26 12:03:39 localhost kernel: ndiswrapper (KeInitializeSpinLock:133): spinlock: 0 Jan 26 12:03:39 localhost kernel: ndiswrapper: using irq 11 Jan 26 12:03:40 localhost kernel: wlan0: ndiswrapper ethernet device 00:90:96:fc:8d:69 using driver bcmwl5a Jan 26 12:03:40 localhost kernel: wlan0: encryption modes supported: WEP, WPA with TKIP, WPA with AES/CCMP Jan 26 12:06:06 localhost kernel: wlan0 (WE) : Wireless Event too big (277) After which there was nothing until the forced reboot. Thanks, David On Wed, 2005-01-26 at 03:33 -0500, Giridhar Pemmasani wrote: > Well, I figured another workaround for this problem and reimplemented > spinlocks using this approach. Windows spinlock (KSPIN_LOCK) is now an > index into an array of spinlocks that are allocated on-demand. With > this scheme it is possible to check if a spinlock is valid or not > etc. Right now spinlock implementation in ndiswrapper uses this > approach irrespective of whether CONFIG_DEBUG_SPINLOCK is enabled or > not. Of course, that means this implementation may break some drivers > that worked earlier. So test latest nightly tarball (CVS is slow) and > report if your driver used to work until yesterday but fails now or > CONFIG_DEBUG_SPINLOCK caused problems until yesterday but works now. > > Until it is known to work without problems, the new implementation > will be a bit verbose. Don't be alarmed if it complains about invalid > spinlocks (unless you get kernel crash); the implementation should > handle those "invalid" spinlocks. > |
From: David K. <dmk...@uc...> - 2005-01-27 20:56:52
|
Hi, I went back to 0.12. That caused the same crashes as before, which was definitely unexpected. Then I went to 0.10, which is the version that has always worked well for me. Unfortunately, I had to revert to an older kernel to get it to work (I tried kernel-2.6.9-1.681_FC3.stk16). That version did not crash (though it didn't connect to the network, which I *think* it should be able to). At the moment I am confused as I am sure I have used 1.0rc? versions at some point without problems on stock redhat kernels. Perhaps it is the network I am trying to use. Cheers, David On Wed, 2005-01-26 at 12:43 -0800, David Kaplan wrote: > Hi, > > I tried the latest CVS and the 1.0rc4 tarball from sourceforge > (downloaded today) on my FC3 system with latest redhat kernel and > CONFIG_DEBUG_SPINLOCK enabled. Both caused freezes on my system. > Reverting to 1.0rc3 (actually CVS from 2005-01-20), fixed the problem. > > My logs had the following regarding the crashes: > > Jan 26 12:03:39 localhost kernel: ndiswrapper version 1.0rc4 loaded > (preempt=no,smp=no) > Jan 26 12:03:39 localhost kernel: ndiswrapper: driver bcmwl5a > (Broadcom,06/25/2004, 3.40.73.0) added > Jan 26 12:03:39 localhost kernel: ACPI: PCI interrupt 0000:02:02.0[A] -> > GSI 11 (level, low) -> IRQ 11 > Jan 26 12:03:39 localhost kernel: ndiswrapper > (KeInitializeSpinLock:133): spinlock: 0 > Jan 26 12:03:39 localhost kernel: ndiswrapper > (KeInitializeSpinLock:133): spinlock: 0 > Jan 26 12:03:39 localhost kernel: ndiswrapper: using irq 11 > Jan 26 12:03:40 localhost kernel: wlan0: ndiswrapper ethernet device > 00:90:96:fc:8d:69 using driver bcmwl5a > Jan 26 12:03:40 localhost kernel: wlan0: encryption modes supported: > WEP, WPA with TKIP, WPA with AES/CCMP > Jan 26 12:06:06 localhost kernel: wlan0 (WE) : Wireless Event too big > (277) > > After which there was nothing until the forced reboot. > > Thanks, > David > > > On Wed, 2005-01-26 at 03:33 -0500, Giridhar Pemmasani wrote: > > Well, I figured another workaround for this problem and reimplemented > > spinlocks using this approach. Windows spinlock (KSPIN_LOCK) is now an > > index into an array of spinlocks that are allocated on-demand. With > > this scheme it is possible to check if a spinlock is valid or not > > etc. Right now spinlock implementation in ndiswrapper uses this > > approach irrespective of whether CONFIG_DEBUG_SPINLOCK is enabled or > > not. Of course, that means this implementation may break some drivers > > that worked earlier. So test latest nightly tarball (CVS is slow) and > > report if your driver used to work until yesterday but fails now or > > CONFIG_DEBUG_SPINLOCK caused problems until yesterday but works now. > > > > Until it is known to work without problems, the new implementation > > will be a bit verbose. Don't be alarmed if it complains about invalid > > spinlocks (unless you get kernel crash); the implementation should > > handle those "invalid" spinlocks. > > > > > > ------------------------------------------------------- > This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting > Tool for open source databases. Create drag-&-drop reports. Save time > by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. > Download a FREE copy at http://www.intelliview.com/go/osdn_nl > _______________________________________________ > Ndiswrapper-general mailing list > Ndi...@li... > https://lists.sourceforge.net/lists/listinfo/ndiswrapper-general |
From: David K. <dmk...@uc...> - 2005-01-28 18:52:37
|
Hi, Well, I am now at home and 1.0rc4 appears to be working fine on Fedora with the latest redhat kernels. It must have been the network I was using that was causing the problem at work. I looked into what network I was trying to use and it was the campus wireless network, which I am allowed to use, but it has very low signal where I was attempting to use it. Somehow, that caused a kernel panic. The same driver in windows did not cause a problem, though it was also unable to connect due to low signal strength. So, rc4 does appear to work for me, but I might have stumbled upon an unrelated problem that crept in somewhere around 0.12 that is perhaps related to low signal strength. If someone has any suggestions on how to diagnose the problem, let me know and I will give it a try. Cheers, David On Thu, 2005-01-27 at 12:56 -0800, David Kaplan wrote: > Hi, > > I went back to 0.12. That caused the same crashes as before, which was > definitely unexpected. Then I went to 0.10, which is the version that > has always worked well for me. Unfortunately, I had to revert to an > older kernel to get it to work (I tried kernel-2.6.9-1.681_FC3.stk16). > That version did not crash (though it didn't connect to the network, > which I *think* it should be able to). > > At the moment I am confused as I am sure I have used 1.0rc? versions at > some point without problems on stock redhat kernels. Perhaps it is the > network I am trying to use. > > Cheers, > David > > > On Wed, 2005-01-26 at 12:43 -0800, David Kaplan wrote: > > Hi, > > > > I tried the latest CVS and the 1.0rc4 tarball from sourceforge > > (downloaded today) on my FC3 system with latest redhat kernel and > > CONFIG_DEBUG_SPINLOCK enabled. Both caused freezes on my system. > > Reverting to 1.0rc3 (actually CVS from 2005-01-20), fixed the problem. > > > > My logs had the following regarding the crashes: > > > > Jan 26 12:03:39 localhost kernel: ndiswrapper version 1.0rc4 loaded > > (preempt=no,smp=no) > > Jan 26 12:03:39 localhost kernel: ndiswrapper: driver bcmwl5a > > (Broadcom,06/25/2004, 3.40.73.0) added > > Jan 26 12:03:39 localhost kernel: ACPI: PCI interrupt 0000:02:02.0[A] -> > > GSI 11 (level, low) -> IRQ 11 > > Jan 26 12:03:39 localhost kernel: ndiswrapper > > (KeInitializeSpinLock:133): spinlock: 0 > > Jan 26 12:03:39 localhost kernel: ndiswrapper > > (KeInitializeSpinLock:133): spinlock: 0 > > Jan 26 12:03:39 localhost kernel: ndiswrapper: using irq 11 > > Jan 26 12:03:40 localhost kernel: wlan0: ndiswrapper ethernet device > > 00:90:96:fc:8d:69 using driver bcmwl5a > > Jan 26 12:03:40 localhost kernel: wlan0: encryption modes supported: > > WEP, WPA with TKIP, WPA with AES/CCMP > > Jan 26 12:06:06 localhost kernel: wlan0 (WE) : Wireless Event too big > > (277) > > > > After which there was nothing until the forced reboot. > > > > Thanks, > > David > > > > > > On Wed, 2005-01-26 at 03:33 -0500, Giridhar Pemmasani wrote: > > > Well, I figured another workaround for this problem and reimplemented > > > spinlocks using this approach. Windows spinlock (KSPIN_LOCK) is now an > > > index into an array of spinlocks that are allocated on-demand. With > > > this scheme it is possible to check if a spinlock is valid or not > > > etc. Right now spinlock implementation in ndiswrapper uses this > > > approach irrespective of whether CONFIG_DEBUG_SPINLOCK is enabled or > > > not. Of course, that means this implementation may break some drivers > > > that worked earlier. So test latest nightly tarball (CVS is slow) and > > > report if your driver used to work until yesterday but fails now or > > > CONFIG_DEBUG_SPINLOCK caused problems until yesterday but works now. > > > > > > Until it is known to work without problems, the new implementation > > > will be a bit verbose. Don't be alarmed if it complains about invalid > > > spinlocks (unless you get kernel crash); the implementation should > > > handle those "invalid" spinlocks. > > > > > > > > > > > ------------------------------------------------------- > > This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting > > Tool for open source databases. Create drag-&-drop reports. Save time > > by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. > > Download a FREE copy at http://www.intelliview.com/go/osdn_nl > > _______________________________________________ > > Ndiswrapper-general mailing list > > Ndi...@li... > > https://lists.sourceforge.net/lists/listinfo/ndiswrapper-general > > > > ------------------------------------------------------- > This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting > Tool for open source databases. Create drag-&-drop reports. Save time > by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. > Download a FREE copy at http://www.intelliview.com/go/osdn_nl > _______________________________________________ > Ndiswrapper-general mailing list > Ndi...@li... > https://lists.sourceforge.net/lists/listinfo/ndiswrapper-general |
From: Jonathan B. <be...@gm...> - 2005-01-28 05:10:46
|
On Wed, 26 Jan 2005 03:33:25 -0500, Giridhar Pemmasani <gi...@lm...> wrote: > Well, I figured another workaround for this problem and reimplemented > spinlocks using this approach. Windows spinlock (KSPIN_LOCK) is now an > index into an array of spinlocks that are allocated on-demand. With > this scheme it is possible to check if a spinlock is valid or not > etc. Right now spinlock implementation in ndiswrapper uses this > approach irrespective of whether CONFIG_DEBUG_SPINLOCK is enabled or > not. Of course, that means this implementation may break some drivers > that worked earlier. So test latest nightly tarball (CVS is slow) and > report if your driver used to work until yesterday but fails now or > CONFIG_DEBUG_SPINLOCK caused problems until yesterday but works now. > > Until it is known to work without problems, the new implementation > will be a bit verbose. Don't be alarmed if it complains about invalid > spinlocks (unless you get kernel crash); the implementation should > handle those "invalid" spinlocks. > > -- > Giri Hi Giri, Thanks for continuing to work on this. Unfortunately, the CVS from yesterday night (Jan 26) still freezes my system (with the DEBUG_SPINLOCK enabled, haven't tried without yet). (Just as an aside, why does CVS not add a version number to distinguish it from releases? It would be nice if it did.) This time I switched to a virtual console to do the modprobe and saw the kernel panic. Unfortunately, I couldn't see much usefull info still on the screen, and, well, my computer doesn't work too well with interrupts disabled (the one message I could see), hence the hard freeze. /var/log/messages does seem to have some of the oops in it, but there was definitely more on the screen. Is there any way to capture the screen output? Here is what I've got from messages (sorry about the wrapping): Jan 26 22:14:07 ClawHammer kernel: ndiswrapper version 1.0rc4 loaded (preempt=no,smp=no) Jan 26 22:14:07 ClawHammer kernel: ndiswrapper: driver netbc564 (,10/01/2002,3.70.17.5) added Jan 26 22:14:07 ClawHammer kernel: ACPI: PCI Interrupt Link [LNK3] enabled at IRQ 17 Jan 26 22:14:07 ClawHammer kernel: ACPI: PCI interrupt 0000:02:02.0[A] -> GSI 17 (level, low) -> IRQ 225 Jan 26 22:14:07 ClawHammer kernel: ndiswrapper: using irq 225 Jan 26 22:14:07 ClawHammer kernel: Unable to handle kernel NULL pointer dereference at 0000000000000030 RIP: Jan 26 22:14:07 ClawHammer kernel: <ffffffffa02160d5>{:ndiswrapper:KfAcquireSpinLock+16} Jan 26 22:14:07 ClawHammer kernel: PML4 13a24067 PGD 8c76067 PMD 0 Jan 26 22:14:07 ClawHammer kernel: Oops: 0002 [1] Jan 26 22:14:07 ClawHammer kernel: CPU 0 Jan 26 22:14:07 ClawHammer kernel: Modules linked in: ndiswrapper(U) nvidia(U) snd_intel8x0 nls_utf8 ntfs(U) parport_pc lp parport autofs4 sunrpc pcmcia ipt_REJECT ipt_state ip_conntrack iptable_filter ip_tables dm_mod video button battery ac usblp ohci1394 ieee1394 joydev yenta_socket pcmcia_core ohci_hcd ehci_hcd i2c_nforce2 i2c_core snd_intel8x0m snd_ac97_codec snd_pcm_oss snd_mixer_oss snd_pcm snd_timer snd soundcore snd_page_alloc 8139too mii ext3 jbd Jan 26 22:14:07 ClawHammer kernel: Pid: 4811, comm: loadndisdriver Tainted: P 2.6.10-1.741_FC3 Jan 26 22:14:07 ClawHammer kernel: RIP: 0010:[<ffffffffa02160d5>] <ffffffffa02160d5>{:ndiswrapper:KfAcquireSpinLock+16} Jan 26 22:14:07 ClawHammer kernel: RSP: 0018:0000010003fc5bb0 EFLAGS: 00010293 Jan 26 22:14:07 ClawHammer kernel: RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000 Jan 26 22:14:07 ClawHammer kernel: RDX: 0000000000000246 RSI: 0000000000000000 RDI: 0000010019bae458 Looks like a spin lock issue. Somewhere a NULL is getting passed in. Is KfAcquireSpinLock a driver function? Or perhaps a kernel function? A quick look through the code didn't find it defined anywhere. Let me know if there is any more info I can get you, or any tests I can do. Jonathan |
From: Michael B. <Mic...@sa...> - 2005-01-28 12:57:49
|
Hi all, I initially installed this driver with Fedora Core 3/64-bit on a Compaq R3000Z with the BroadComm BCM4306 wireless network device last Sunday after taking Jonathan Berry's advice by disabling all kernel hacking options in the kernel configuration. I was ecstatic to see that the driver worked perfectly with 1.0RC4. I declared victory and went on to other things. On returning home from work on Monday, I booted the laptop and modprobe'd the ndiswrapper and the kernel starting spinning. I was able to rmmod the driver and the system returned to normal. What I couldn't figure out was why it worked Sunday and quit on Monday. I have spent several hours trying different combinations of things to see if I could get this to work again. I have tried the CVS snapshot every evening since Sunday with no luck. I even built a kernel that I downloaded from kernel.org with the same effect. One person on this list suggested 1.0RC3 may work, no luck. As an aside, it works when I boot into Windows XP so I can reasonably assume it's not a hardware problem. At any rate, here's what I know so far. If I load the driver, the kernel will start to spin. With the CVS snapshot that had the ERROR messages going to the log I was getting a lot of kspinlocks with a value of zero. If I hit the button on the front of the laptop to turn off the antenna, the system returns to normal. I can iwconfig and see the wlan1 device. Obviously I cannot make a connection. Note that wlan0 was attributed to a PCMCIA card that I have installed to temporarily bridge the gap until I can resolve this. Here is what I see in /var/log/messages: Jan 27 17:38:52 bzinger kernel: ndiswrapper version 1.0rc4@050127 loaded (preempt=no,smp=no) Jan 27 17:39:21 bzinger kernel: ndiswrapper: driver netbc564 (,10/01/2002,3.70.17.5) added Jan 27 17:39:21 bzinger kernel: ACPI: PCI Interrupt Link [LNK3] enabled at IRQ 17 Jan 27 17:39:21 bzinger kernel: ACPI: PCI interrupt 0000:02:02.0[A] -> GSI 17 (level, low) -> IRQ 225 Jan 27 17:39:21 bzinger kernel: ndiswrapper: using irq 225 Jan 27 17:39:21 bzinger kernel: warning: many lost ticks. Jan 27 17:39:21 bzinger kernel: Your time source seems to be instable or some driver is hogging interupts Jan 27 17:39:21 bzinger kernel: rip NdisMSynchronizeWithInterrupt+0x4e/0x5b [ndiswrapper] Jan 27 17:39:21 bzinger kernel: wlan1: ndiswrapper ethernet device 00:90:4b:a3:1d:45 using driver netbc564 Jan 27 17:39:21 bzinger kernel: wlan1: encryption modes supported: WEP Jan 27 17:39:21 bzinger kernel: usb 3-2: USB disconnect, address 2 At 17:39:21 is when I hit the button to turn off the antenna. Any advice or things to try would be appreciated. Let me know if there is anything that I can do to help debug this problem. One last note, I also experienced the same kernel panic as Jonathan with a stock Fedora kernel. Regards, Mike Benzinger |
From: Giridhar P. <gi...@lm...> - 2005-01-28 07:02:28
|
On Thu, 27 Jan 2005 23:10:36 -0600, Jonathan Berry <be...@gm...> said: Jonathan> enabled, haven't tried without yet). (Just as an aside, Jonathan> why does CVS not add a version number to distinguish it Jonathan> from releases? It would be nice if it did.) This time This is why I said you should use nightly tarball, not CVS. If you used tarball, it would add the date to release. Moreover, as I said CVS is slow these days. The rest of your report is not useful as I don't know the state of code when you got the CVS. -- Giri |
From: Jonathan B. <be...@gm...> - 2005-01-29 06:46:01
|
On Fri, 28 Jan 2005 02:02:22 -0500, Giridhar Pemmasani <gi...@lm...> wrote: > On Thu, 27 Jan 2005 23:10:36 -0600, Jonathan Berry <be...@gm...> said: > > Jonathan> enabled, haven't tried without yet). (Just as an aside, > Jonathan> why does CVS not add a version number to distinguish it > Jonathan> from releases? It would be nice if it did.) This time > > This is why I said you should use nightly tarball, not CVS. If you > used tarball, it would add the date to release. Moreover, as I said > CVS is slow these days. The rest of your report is not useful as I > don't know the state of code when you got the CVS. > > -- > Giri I used CVS because it was easy. It took a while before I actually found the nightly tarball on the sourceforge site. A direct link would be nice. Also, is there a reason these aren't archived? I only saw one tarball available. CVS seemed plenty fast to me. A few seconds for a checkout, I've seen slower. Except for a few lines in the utils/ndiswrapper script (changes look insignificant), the CVS code I got is identical to the 050126 nightly tarball. I did include the date of when I checked out the CVS code. So what should I do to generate a useful report? Jonathan |
From: Giridhar P. <gi...@lm...> - 2005-01-29 07:22:01
|
On Sat, 29 Jan 2005 00:45:52 -0600, Jonathan Berry <be...@gm...> said: Jonathan> site. A direct link would be nice. Also, is there a Direct link? Jonathan> reason these aren't archived? I only saw one tarball Because there is not need to. If necessary one can get snapshot of a particular day with CVS date command. Jonathan> available. CVS seemed plenty fast to me. A few seconds That is not what I meant by slow; anonymous CVS takes at least a few hours for update and in the past one week, sourceforge site status showed that anonymous CVS would take lot longer than that for updates. During this time I used to generate tarball more than once a day in case someone wanted updates. Jonathan> insignificant), the CVS code I got is identical to the Jonathan> 050126 nightly tarball. I did include the date of when Where did you get 26th tarball on 28th? Use latest/current tarball. Jonathan> I checked out the CVS code. So what should I do to Jonathan> generate a useful report? Read FAQ/Bugs wiki. -- Giri |
From: Jonathan B. <be...@gm...> - 2005-01-29 07:55:13
|
On Sat, 29 Jan 2005 02:21:53 -0500, Giridhar Pemmasani <gi...@lm...> wrote: > On Sat, 29 Jan 2005 00:45:52 -0600, Jonathan Berry <be...@gm...> said: > > Jonathan> site. A direct link would be nice. Also, is there a > Direct link? Oh, yeah. I forgot that if you look closely at the Wiki there is actually a very direct link, sorry. It might be nice to have this on the main ndiswrapper page, though. One less step : ). > Jonathan> reason these aren't archived? I only saw one tarball > > Because there is not need to. If necessary one can get snapshot of a > particular day with CVS date command. I'm not that familiar with CVS; I know enough to follow the directions for how to check particular packages out. Guess I'll have to learn sometime. > Jonathan> available. CVS seemed plenty fast to me. A few seconds > > That is not what I meant by slow; anonymous CVS takes at least a few > hours for update and in the past one week, sourceforge site status > showed that anonymous CVS would take lot longer than that for > updates. During this time I used to generate tarball more than once a > day in case someone wanted updates. Ahh, okay. It makes sense now. Yes I have noticed this lagging behind before with ndiswrapper and other sourceforge projects. > Jonathan> insignificant), the CVS code I got is identical to the > Jonathan> 050126 nightly tarball. I did include the date of when > > Where did you get 26th tarball on 28th? Use latest/current tarball. Well, it was the 26th when I got the tarball : ). Will-do when I get the chance to test again. I still think CVS should add an extraversion or something to differentiate it : ). > Jonathan> I checked out the CVS code. So what should I do to > Jonathan> generate a useful report? > > Read FAQ/Bugs wiki. Okay, well it seems the buginfo script doesn't provide anything that you don't really already know (except maybe my gcc version). I'll compile with higher debug level next time. Anything else? > -- > Giri Thanks, Jonathan |