Then it iterates over /sys/module/wl/drivers/*, and for each actual driver (like 1-1.5.4.2:1.0), echoes their name first into "unbind" and second into "bind", so that the kernel "reloads" the device for that driver. This causes firmware to be loaded, and wl to work without a reboot. According to the syslog, the driver oopsed on either unbinding or rebinding. Perhaps you could do the steps manually on your machine in the live session and record precisely what happens?
This unbinding/rebinding has worked fine for several cycles, so I guess either the kernel or (more likely) the bcmwl package broke something there recently. If there is a different way, or perhaps a different order of these commands that work, we can certainly change the jockey handler.
The jockey handler essentially does this when enabling the wl driver:
rmmod b43
rmmod b43legacy
rmmod bcm43xx
rmmod ssb
modprobe wl
Then it iterates over /sys/module/ wl/drivers/ *, and for each actual driver (like 1-1.5.4.2:1.0), echoes their name first into "unbind" and second into "bind", so that the kernel "reloads" the device for that driver. This causes firmware to be loaded, and wl to work without a reboot. According to the syslog, the driver oopsed on either unbinding or rebinding. Perhaps you could do the steps manually on your machine in the live session and record precisely what happens?
This unbinding/rebinding has worked fine for several cycles, so I guess either the kernel or (more likely) the bcmwl package broke something there recently. If there is a different way, or perhaps a different order of these commands that work, we can certainly change the jockey handler.