BCMSMAC freezes system on trivial oeprations

[Cedric Sodhi]

I use an HP Touchsmart tm2 laptop which has an onboard BRCM 4727- I used to compile my kernel with BCMSMAC module.

At first, I got regular kernel panics that, according to the printed-out stack originated somewhere from the BRCM driver and for which I could not exactly tell the reason (I assume it had something to do with roaming between APs).

Also, the laptop has a dedicated button to activating/deactivating the WLAN device, besides it has a BIOS wired funtion key, that does the same - at least that what it does in Windows and what HP says it should do.

When pressing either of the buttons, the kernel would hard-lock without any further notice and the computer could only be brought down through a hard reset.

This was awful enough, so I though I could try enabling the rfkill kernel compoenent as it seems related (layman at work, as you can tell). Recompiling that way (linux-next, by the way, *not* on wireless-testing yet) and also modifiying another few minor settings resulted in a desaster:

Since then - *even after I have reerted all changes and gone back to the kernel which was known to have worked last!!!* - as soon as the BCMSMAC module is either ocmpiled in or loaded, trivial commands such as ifconfig, iwconfig or just exit (!!!) freeze in a State D (awaiting IO) and can not be killed by even kill -9 or -1.

Shutting the system down is equally impossible without the help of SysReqs. Pushing the WLAN-Button still hardfreezes the system.

You can safely assume that practically *any* operation that is remotely related to the device, such as echo'ing to the rfkill /sys device, too, plus many commands that appear not to be related at all, such as "exit" will freeze in state D and cannot be killed by any means possible.

Pressing aforementioned "WLAN Button" will make these commands resume, just for a split second, before the system hard-locks.

Most puzzling about that, I find, is that reverting to the known-as-having-worked setup (exactly the same) has not got the system back to working.

I have two theories: Either there is some evil, hidden hardware switch on the device that has been triggered and not been reset since and that is causing all this right now, or some very crucial part of the system has been damaged by the regular hard-reset (which I deem unlikely since it would not explain why all sorts of programs freeze for no apparent reason).

So far, the system is practically not usuable - at least not with the driver activated - I'm in desperate need for your help. I can reformat and resetup everything, but I need to know a solution to this in the long term and I really don't know what else to try.