Jes Sorensen wrote:
> At least it's consistent here as opposed to sometimes.
> 
> One thing I noted is that rmmod often takes a few seconds, no idea
> if it has any value?

Ok,

I think I have an idea at whats going on - loading the module with debug
info revealed that it ended up straight in the interrupt handler the
moment the driver called request_irq(), but obviously before it was
ready to handle the interrupt in question. The net result was that it
didn't get to the loading of the ucode.

Unloading the module meant a call was made to iwl_disable_interrupts()
so on the next load, all pending interrupts in the chip had been cleared
and we didn't see this spurious interrupt.

I haven't had a chance to build the driver with this change, ie. it's
untested, but I have a suspicion that this patch might do the job.

Cheers,
Jes