You might try booting with with the noacpi optoin. or acpi=off. I can't
remember what the 2.4.x syntax is. Also, noapic might help. It sounds
like it might be some power management badness. I've noticed that the
windows intel drivers and windows atheros drivers would do this from
time to time on a few of the laptops I've worked on. I think it may be
due to the fact that the ndiswrapper can't pass power management events
to the wireless card properly. Although running without ACPI on a laptop
is far from optimal, you might give it a go.

Michael Joy
HEP - University of Mississippi


On Fri, 2004-10-29 at 12:37, Alan J. Flavell wrote:
> Folks,
>
> I'm still trying to get ndiswrapper working properly in SL, as
> previously mentioned to the list.  Sometimes it's worked fine,
> sometimes not. There seem to be definite indications that some
> hot-plugger routines are getting in behind my back and moving scenery
> around while I'm trying to do things by hand...
>
> Several times when I have been trying something, the laptop froze
> comprehensively, and I noticed the CAPSLOCK L.E.D seemed to be
> flashing in a distinctive pattern.
>
> As I watched it, I finally realised that the LED was flashing Morse
> Code, and I worked out that it is flashing out the words FATAL
> EXCEPTION.  Whose little joke was that, I wonder...?  Any clues on
> whether this is a kernel thing, a BIOS thing, or what?  Not that it
> seems to convey much information - but maybe knowing what area the
> "message" might be coming from, would help to understand what's going
> wrong.  A google search for the symptoms has been quite uninformative,
> so I thought I'd risk asking the list.
>
> Anyway, at the instant of writing this to the list, I actually do have
> the laptop working on the wireless network using ndiswrapper (version
> 0.11).  The trouble is, I'm still not sure how to get there reliably
> without it hanging or crashing the OS.  At least it's some kind of
> "existence proof".  And as I said before - with so many different
> kinds of wireless card around, and even the "same" model turning out
> to contain different chipsets, the idea of a generic wrapper that can
> run lots of different vendor-supplied Win32 drivers does seem to have
> appeal, don't you agree?
>
> cheers