I have no idea if this is the cause, but this happened in that timeframe:

commit 73077c85458739169cdaf893a375b8bb3939d35a
Author: Ivo van Doorn <ivdoorn@gmail.com>
Date:   Mon Aug 17 18:53:24 2009 +0200

    rt2x00: Fix RFKILL polling
    
    The rfkill_poll callback function in the drivers check a bit
    to see if the RFKILL key has been pressed. However when the
    bit is set it means the radio is active and the device can be
    used.
    
    The wiphy_rfkill_set_hw_state() function expects the inversed,
    so '1' must be send when the radio must be disabled.
    
    Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>

And also this:

commit e47a5cddf893815e7da16e3226b959af785d8aaf
Author: Ivo van Doorn <ivdoorn@gmail.com>
Date:   Wed Jul 1 15:17:35 2009 +0200

    rt2x00: use wiphy rfkill interface
    
    Remove the input_polldev from rt2x00 and replace it with
    the rfkill interface offered by the wiphy structure. This
    simplifies the entire rfkill handling in rt2x00 and allows
    us to remove the CONFIG_RT2X00_LIB_RFKILL option and always
    enables rfkill capabilities.
    
    Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>

Can you try reverting those (in that order) to see if the problem gets resolved for you?

(In reply to comment #1)
> I have no idea if this is the cause, but this happened in that timeframe:
> 
> commit 73077c85458739169cdaf893a375b8bb3939d35a
...
> And also this:
> 
> commit e47a5cddf893815e7da16e3226b959af785d8aaf
...
> Can you try reverting those (in that order) to see if the problem gets
> resolved
> for you?
Thanks

I would be happy if I could do that. But I am not a programmer and so I hope you or someone from ubuntuusers.de(where I will ask for that) could provide a prepared kernel(source) or declare the process in detail.

If you are in a position to extract and build a kernel from git then the "git revert" command is relatively simple on top of that.  Otherwise, you might consider seeking front line support at Launchpad. :-)

Would git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git the preferred repository like described on the Ubuntu webpages or would you suggest a other one?

Yes, that sounds like a good repository to use. :-)

After reverting the first commit the Bluetooth and Wireless LAN are both Soft and Hard unblocked. But this leads to a other problem(by getting the IP address I think):

from dmesg:
[    8.648036] phy0: device now idle
[    8.666597] phy0 -> rt2x00mac_conf_tx: Info - Configured TX queue 0 - CWmin: 3, CWmax: 4, Aifs: 2, TXop: 102.
[    8.666606] phy0 -> rt2x00mac_conf_tx: Info - Configured TX queue 1 - CWmin: 4, CWmax: 5, Aifs: 2, TXop: 188.
[    8.666897] ADDRCONF(NETDEV_UP): wlan0: link is not ready
... 
[    9.788268] phy0: device no longer idle - scanning
[   11.025769] phy0: device now idle
[   11.038289] wlan0: deauthenticating from 00:18:39:bc:89:6f by local choice (reason=3)
[   11.038407] phy0: device no longer idle - working
[   11.041390] wlan0: authenticate with 00:18:39:bc:89:6f (try 1)
[   11.043018] wlan0: authenticated
[   11.043030] phy0: device now idle
[   11.045769] wlan0: associate with 00:18:39:bc:89:6f (try 1)
[   11.045781] phy0: device no longer idle - working
[   11.048763] wlan0: RX AssocResp from 00:18:39:bc:89:6f (capab=0x411 status=0 aid=1)
[   11.048766] wlan0: associated
[   11.048774] phy0: Allocated STA 00:18:39:bc:89:6f
[   11.049107] phy0: Inserted STA 00:18:39:bc:89:6f
[   11.049112] phy0 -> rt2x00mac_conf_tx: Info - Configured TX queue 0 - CWmin: 2, CWmax: 3, Aifs: 2, TXop: 47.
[   11.049116] phy0 -> rt2x00mac_conf_tx: Info - Configured TX queue 1 - CWmin: 3, CWmax: 4, Aifs: 2, TXop: 94.
[   11.052763] ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready
...
[   21.856006] wlan0: no IPv6 routers present
...
[   55.079130] phy0 -> rt2x00mac_conf_tx: Info - Configured TX queue 0 - CWmin: 2, CWmax: 3, Aifs: 2, TXop: 47.
[   55.079136] phy0 -> rt2x00mac_conf_tx: Info - Configured TX queue 1 - CWmin: 3, CWmax: 4, Aifs: 2, TXop: 94.
[   55.093475] phy0: Removed STA 00:18:39:bc:89:6f
[   55.093522] phy0: Destroyed STA 00:18:39:bc:89:6f
[   55.093526] wlan0: deauthenticating from 00:18:39:bc:89:6f by local choice (reason=3)
[   55.093561] phy0: device now idle
[   55.145081] cfg80211: All devices are disconnected, going to restore regulatory settings
[   55.145090] cfg80211: Restoring regulatory settings
[   55.145096] cfg80211: Calling CRDA to update world regulatory domain

Could you assist me further on this problem ans should I send you further logs or could you suggest other points to ask for assistence? On Launchpad the bug report about rfkill stays unanswered. :-(

Sorry for the delayed response.  I wonder if the rt2x00 guys can comment?  Ivo & Gertjan?

Ok, the orginal code from ralink is:

        // Read Hardware controlled Radio state enable bit
        if (Antenna.field.HardwareRadioControl == 1)
        {
                pAdapter->PortCfg.bHardwareRadio = TRUE;
                RTUSBWriteMACRegister(pAdapter, MAC_CSR19, 0);

                // Read GPIO pin0 as Hardware controlled radio state
                RTUSBReadMACRegister(pAdapter, MAC_CSR19, &value);
                if ((value & 0x80) == 0)
                {
                        pAdapter->PortCfg.bHwRadio = FALSE;
                        pAdapter->PortCfg.bRadio = FALSE;
                        RTUSBWriteMACRegister(pAdapter, MAC_CSR13, 0);
                        RTUSBWriteMACRegister(pAdapter, MAC_CSR14, 0);
                        RTMP_SET_FLAG(pAdapter, fRTMP_ADAPTER_RADIO_OFF);
                DBGPRINT(RT_DEBUG_ERROR, "2Set fRTMP_ADAPTER_RADIO_OFF ");
                        if (pAdapter->PortCfg.LedMode == LED_MODE_ASUS)
                        {
                                // Turn bit 17 for Radio OFF
                                RTUSBWriteMACRegister(pAdapter, MAC_CSR20, 1);
                        }
                }
        }
        else
                pAdapter->PortCfg.bHardwareRadio = FALSE;

The "Antenna.field.HardwareRadioControl" field is a value from EEPROM which states that the RFKILL button exists. in rt2x00 we check this field as well, and we don't enable polling unless this field is true.

When reading MAC_CSR19, it clearly checks that the register must have bit 0x80 _disabled_ to disable the radio. This corresponds with the code from rt2x00:

        void rt2x00mac_rfkill_poll(struct ieee80211_hw *hw)
        {
                struct rt2x00_dev *rt2x00dev = hw->priv;
                bool active = !!rt2x00dev->ops->lib->rfkill_poll(rt2x00dev);
 
                wiphy_rfkill_set_hw_state(hw->wiphy, blocked);
                wiphy_rfkill_set_hw_state(hw->wiphy, !active);
        }

If rfkill_poll returns 1 from the driver, then bit 0x80 in MAC_CSR19 is set. So for wiphy_rfkill_set_hw_state it has to be inverted (wiphy_rfkill_set_hw_state wants the value true to disable the radio).

So as far as I can see the patch is correct. The bug seems to be the device which has the HardwareRadioControl enabled while the device hasn't got a button.

So the solution as far as I can see is:
a) Disable RFKILL in your kernel (not sure if mac80211 allows this though)
b) Reintroduce the CONFIG_RT2X00_RFKILL option to disable RFKILL for rt2x00
c) Have a module parameter to force the HardwareRadioControl setting to false

Been a while...does this problem persist with 2.6.37 or later kernels?

Closing due to lack of response...

Can this bug STATUS be changed to open again? Although it maybe a bug in the hardware itself mentioned by Ivo van Doorn. I have exactly the same desktop PC model from Medion with the same ralink rt2500usb rfkill soft>hard blocked wifi problem, but some new/extra info:

The 2.6.31.x kernel from ubuntu 9.10 uses the module "input_polldev" together with rfkill to handle the on/off switching of the hardware. In newer versions of ubuntu with the newer kernel up to Ubuntu 12.04 LTS 3.2.0-23 this module does not load with the rt2x00lib module (as by design?) but maybe this input_polldev module handled a specific parameter for this usb wifi card so it did work? Right now I don't know how to get the device working at all and don't now which specific kernel package has the clue.

I haven't tested a mainline kernel yet only the 3.2.0-23 from ubuntu 12.04 lts, so what kind of system/clean install do you recommend to "easily" detect the problem? I have most experience with debian based distro but not enough with kernel compiling, chroot, debugging and keeping an overview on kernel module level.

FWIW, I think it would be best for you to open a new bug for the current situation.  Even if it really is the same, it just causes confusion trying to combine such an old report with something new.

But it's the same machine with exact the same wifi adapter, is opening such a old bug really a problem? Otherwise I will be testing the same solutions that might not work already posted earlier in this bugreport, now its all in one place.

Ndiswrapper affects rfkill state:
When the Ndiswrapper with the Ralink proprietary Windows Driver is used, after removing the active module rt2500usb, the device works fine (ofcourse using NDIS).

Module rt2500usb working:
Eventually when the device works with active ndiswrapper module, disable ndiswrapper, unload the module and modprobe rt2500usb, this time "rfkill" will show "soft" and "hard" unblocked which leads to a working device even in the network-manager:

sudo ifconfig wlan0 up
sudo service network-manager stop/start

Which part/package of the kernel code needs to be reverted to find the problem?