Re: [Ndiswrapper-general] ndiswrapper freezes system

[David K. <dmk...@uc...>]

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