Quoting Giridhar Pemmasani <pgiri@...>:
> --- Pavel Roskin <proski@...> wrote:
> > ndiswrapper caused kernel oops. I'm not sure I'll be able to debug it
> > soon (if at all), so I just want to post it as. Please feel free to ask
> > further questions.
> I believe Atmel driver at one time worked fine, so it must be regression.
If you give me the timeframe when it was working, I may be able to track down
the change that broke it.
> Unfortunately, I don't have Atmel based device to identify what causes it to
> fail initialization. The reason for crash is more understandable -
> ndiswrapper is not (yet) good at undoing in case of errors and terminate
I forgot to say that the device is first enabled, then the firmware is loaded
and then it's reenabled. It may be that the first stage ends with an error on
purpose to force the reload. But I'm just guessing here.
> > ndiswrapper (miniport_init:270): couldn't initialize device: C0000001
> > ndiswrapper (pnp_start_device:426): Windows driver couldn't initialize the
> > device (C0000001)
> If possible, can you send debug trace? The trace is likely too big to post on
> the mailing list, in which case, send the trace directly to me. To get the
> trace, run the following:
> cd ndiswrapper-1.28/driver
> make DEBUG=4 USB_DEBUG=1 EVENT_DEBUG=1
> insmod ./ndiswrapper.ko
> then get the debug trace in /var/log/messages (or wherever log messages are
> stored) from ndiswrapper.
OK, will do.