Michael Buesch wrote:
> On Sunday 11 February 2007 15:02, Rafael J. Wysocki wrote:
>> PM: Removing info for No Bus:0000:30:00.0
>> bcm43xx: IRQ_READY timeout
>> bcm43xx: core_up for active 802.11 core failed (-19)
>
> I never tried suspend to disk with the driver.
This implies that suspend to RAM works. Is that true?
> Larry, an idea why the microcode doesn't respond?
Is this code snippet supposed to keep the firmware loaded when the system is
suspended?
bcm->firmware_norelease = 1;
bcm43xx_free_board(bcm);
bcm->firmware_norelease = 0;
If so, that may be the problem. What would force it to be reloaded when
resuming after a suspend to
disk and subsequent power off? That would certainly explain why a reload is
successful. Is there a
volatile location that would safely indicate that the firmware is not good?
Perhaps, we need to bite
the bullet and reload the firmware after every resume. The patch below should
do that.
I am also working on a case where the user has troubles with a suspend to disk
from Windows followed
by a reboot to Linux, and warm reboots from Windows to Linux. In these cases,
he gets a firmware
file-format error; however, his firmware is fine from a cold boot.
Larry
Index: linux-2.6/drivers/net/wireless/bcm43xx/bcm43xx_main.c
===================================================================
--- linux-2.6.orig/drivers/net/wireless/bcm43xx/bcm43xx_main.c
+++ linux-2.6/drivers/net/wireless/bcm43xx/bcm43xx_main.c
@@ -4296,6 +4297,7 @@ static int bcm43xx_resume(struct pci_dev
printk(KERN_ERR PFX "Resume failed!\n");
return err;
}
+ bcm43xx_request_firmware(bcm);
netif_device_attach(net_dev);
dprintk(KERN_INFO PFX "Device resumed.\n");
_______________________________________________
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
