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
Disable interrupts in the iwl4965 before calling request_irq() for the case that the previous OS or the BIOS left a pending interrupt in the chip. This behavior has been observed on some laptops such as T61 Thinkpads and Toshiba Portege R500 Signed-off-by: Jes Sorensen <jes@xxxxxxx> --- linux/drivers/net/wireless/iwlwifi/iwl4965-base.c~ 2007-10-26 06:49:02.000000000 +0200 +++ linux/drivers/net/wireless/iwlwifi/iwl4965-base.c 2007-10-26 16:03:40.387241088 +0200 @@ -9090,6 +9090,8 @@ priv->power_mode = IWL_POWER_AC; priv->user_txpower_limit = IWL_DEFAULT_TX_POWER; + iwl_disable_interrupts(priv); + pci_enable_msi(pdev); err = request_irq(pdev->irq, iwl_isr, IRQF_SHARED, DRV_NAME, priv);
