Description of problem:
On Asus EeePC (1002HA model) with kernels 2.6.27.12-170.2.5.fc10 or 2.6.27.15-170.2.22.fc10 (the later one from koji) there are rfkill0 and rfkill1 in /sys/class/rfkill/ and 'cat /sys/class/rfkill/rfkill*/uevent' gives:
RFKILL_NAME=eeepc-wlan
RFKILL_TYPE=wlan
RFKILL_STATE=1
RFKILL_NAME=eeepc-bluetooth
RFKILL_TYPE=bluetooth
RFKILL_STATE=-19
There is indeed a bluetooth icon in a notification area but doing things
like 'echo -n 0 >/sys/class/rfkill/rfkill1/state' gets
"echo: write error: No such device". If bluetooth really does work I do not know, as I do not have any such device handy, but it is at least recognized.
Writing 0 or 1 to 'state' in 'rfkill0' directory does turn off or on wireless but a wifi control light is all the time on as it goes off only if both wifi and bluetooth are off.
That is different with 2.6.29-0.22.rc4.git1.fc10 (from koji again) which sports updated eeepc-laptop module. This shows rfkill0, rfkill1 and rfkill2 directories and 'cat /sys/class/rfkill/rfkill*/uevent' now gets:
RFKILL_NAME=eeepc-wlan
RFKILL_TYPE=wlan
RFKILL_STATE=1
RFKILL_NAME=eeepc-bluetooth
RFKILL_TYPE=bluetooth
RFKILL_STATE=1
RFKILL_NAME=ath9k-phy0:rfkill
RFKILL_TYPE=wlan
RFKILL_STATE=1
'rfkill2/state' does not seem to be really writeable but writing 0's and 1's into 'rfkill0/state' and 'rfkill1/state' does turn off and on both wifi and bluetooth and with both off wifi LED goes dark.
Rebooting to one of 2.6.27-... kernels with bluetooth off makes its icon to vanish from a notification area, with no way to turn that back on within that boot, on toggling wlan state toggles also wifi LED.
It seems that reusing new eeepc-laptop.c code in older kernels would be quite straighforward if f10 stays with 2.6.27. I did not check that this is all what would be needed but it appears that way.
With all of the above it does not seem to be a way to change rfkill state other than by directly writing to /sys/class/rfkill/rfkill[01]/state files. 1002HA does sport "wifi control key" Fn+F2. It is recognized on a desktop as XF86WLAN key but that key does not seem to be doing anything at all and I was unable to find a way to tie it to some user defined actions. "Keyboard Shortcuts" seem to have a predefined list and if not on it you are apparently SOL. A reasonable action would be to cycle through all four possible rfkill states for wireless.
Version-Release number of selected component (if applicable):
kernel-2.6.27.12-170.2.5.fc10

Further experiments with 2.6.27 and with 2.6.29-0.53.rc7.fc10.i686 show that after rfkill-input module is loaded the WLAN (Fn-F2) key starts to react. Only:
- nothing inserts rfkill-input unless explicitely loaded
- Fn-F2, with an anntena picture on it, toggles only /sys/class/rfkill/rfkill0/state and does nothing to bluetooth
- a controll light goes off only if both /sys/class/rfkill/rfkill{0,1}/state, i.e eeepc-wlan and eeepc-bluetooth are set to 0
- you cannot change bluetooth state with 2.6.27 kernels anyway
- bluetooth marker in a notification area correctly reflects changes in /sys/class/rfkill/rfkill1/state

The last kernel from this series on koji is currently 2.6.29.1-30.fc10
which has rfkill and rfkill-input as modules.
Conveniently enough for me the key in question on my keyboard generates
"hotkey ATKD 00000010" ACPI event which allows to handle both WiFi and bluetooth with a help of a script in /etc/acpi/events.
To emulate 2.6.29.1-34.fc10 I inserted rfkill-input and disabled my event script. That left me with unswitchable bluetooth and after few hits on switch key on a keyboard I got for my troubles the following:
irq 18: nobody cared (try booting with the "irqpoll" option)
Pid: 0, comm: swapper Not tainted 2.6.29.1-30.fc10.i686 #1
Call Trace:
[<c0468e22>] __report_bad_irq+0x2e/0x6f
[<c0468f53>] note_interrupt+0xf0/0x149
[<c0469489>] handle_fasteoi_irq+0x8f/0xb5
[<c04693fa>] ? handle_fasteoi_irq+0x0/0xb5
<IRQ> [<c040442c>] ? common_interrupt+0x2c/0x34
[<c044a7c8>] ? tick_nohz_stop_sched_tick+0x33d/0x34d
[<c0402ddb>] ? cpu_idle+0x26/0x8b
[<c06c4a8b>] ? rest_init+0x53/0x55
handlers:
[<c05f250d>] (usb_hcd_irq+0x0/0xa3)
[<f7ed4a58>] (ath_isr+0x0/0x13a [ath9k])
Disabling IRQ #18
Still turning on wifi back makes it to work again. No idea how repeatable
that can be. Apparently this is not easy but I never got that when using my script in /etc/acpi/events/.
My attempts to follow what is written on
http://people.freedesktop.org/~hughsient/quirk/quirk-keymap-index.html
in order to make hal to handle these keyboard events came to naught.

kernel-2.6.29.1-42.fc10 has been pushed to the Fedora 10 testing repository. If problems still persist, please make note of it in this bug report.
If you want to test the update, you can install it with
su -c 'yum --enablerepo=updates-testing update kernel'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F10/FEDORA-2009-3999

Re comment #6 about "updates-testing".
Remarks from comment #4 apply in full. Without my acpi event handler script an "rfkill" key switches off and on wifi but does not seem to have any effect on bluetooth. Also I got after few toggles off and on as with 2.6.29.1-30.fc10:
irq 18: nobody cared (try booting with the "irqpoll" option)
Pid: 0, comm: swapper Not tainted 2.6.29.1-42.fc10.i686 #1
Call Trace:
[<c0467a0e>] __report_bad_irq+0x2e/0x6f
[<c0467b3f>] note_interrupt+0xf0/0x149
[<c0468075>] handle_fasteoi_irq+0x8f/0xb5
[<c0467fe6>] ? handle_fasteoi_irq+0x0/0xb5
<IRQ> [<c04043ac>] ? common_interrupt+0x2c/0x34
[<c044007b>] ? run_posix_cpu_timers+0x1c2/0x705
[<c04493b4>] ? tick_nohz_stop_sched_tick+0x33d/0x34d
[<c0402db7>] ? cpu_idle+0x26/0x8b
[<c06c675b>] ? rest_init+0x53/0x55
handlers:
[<c05f0ea5>] (usb_hcd_irq+0x0/0xa3)
[<f7eeba54>] (ath_isr+0x0/0x13a [ath9k])
Disabling IRQ #18
Also, close in time to the above, messages reported in bug 492699 (or something very similar) did show up but this may be just a time coincidence.

kernel-2.6.29.2-52.fc10 has been pushed to the Fedora 10 testing repository. If problems still persist, please make note of it in this bug report.
If you want to test the update, you can install it with
su -c 'yum --enablerepo=updates-testing update kernel'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F10/FEDORA-2009-4132

> kernel-2.6.29.2-52.fc10 has been pushed ...
A behaviour is the same as in comment 4 and comment 8. That includes
"irq 18: nobody cared" with a trace if no extra handling via acpid is configured. OTOH at least wifi can be toggled "out of the box".

kernel-2.6.29.3-60.fc10, hal-0.5.12-15.20081027git.fc10 has been pushed to the Fedora 10 testing repository. If problems still persist, please make note of it in this bug report.
If you want to test the update, you can install it with
su -c 'yum --enablerepo=updates-testing update kernel hal'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F10/FEDORA-2009-4818

kernel-2.6.29.4-75.fc10, hal-0.5.12-15.20081027git.fc10 has been pushed to the Fedora 10 testing repository. If problems still persist, please make note of it in this bug report.
If you want to test the update, you can install it with
su -c 'yum --enablerepo=updates-testing update kernel hal'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F10/FEDORA-2009-5527

> kernel-2.6.29.4-75.fc10, hal-0.5.12-15.20081027git.fc10 has been pushed ...
The netbook in question was "on the road" so I could try only now. I am not
sure what was supposed to happen but with kernel-2.6.29.4-75.fc10 and hal-0.5.12-15.20081027git.fc10 I can toggle from a keyboard wifi but that does
not have any effect on a state of bluetooth (unless I am using my own script
in /etc/acpi/actions/ which cyclyes through four states of Fn-F2 key).
I did not see "irq 18: nobody cared" with an associated trace though. That does
not happen always so maybe just lucky?

kernel-2.6.29.5-84.fc10, hal-0.5.12-15.20081027git.fc10 has been pushed to the Fedora 10 testing repository. If problems still persist, please make note of it in this bug report.
If you want to test the update, you can install it with
su -c 'yum --enablerepo=updates-testing update kernel hal'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F10/FEDORA-2009-6717

kernel-2.6.29.6-93.fc10, hal-0.5.12-15.20081027git.fc10 has been pushed to the Fedora 10 testing repository. If problems still persist, please make note of it in this bug report.
If you want to test the update, you can install it with
su -c 'yum --enablerepo=updates-testing update kernel hal'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F10/FEDORA-2009-7573

kernel-2.6.29.6-97.fc10 has been pushed to the Fedora 10 testing repository. If problems still persist, please make note of it in this bug report.
If you want to test the update, you can install it with
su -c 'yum --enablerepo=updates-testing update kernel'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F10/FEDORA-2009-8697

kernel-2.6.29.6-99.fc10 has been pushed to the Fedora 10 testing repository. If problems still persist, please make note of it in this bug report.
If you want to test the update, you can install it with
su -c 'yum --enablerepo=updates-testing update kernel'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F10/FEDORA-2009-8870

This message is a reminder that Fedora 10 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 10. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora
'version' of '10'.
Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version'
to a later Fedora version prior to Fedora 10's end of life.
Bug Reporter: Thank you for reporting this issue and we are sorry that
we may not be able to fix it before Fedora 10 is end of life. If you
would still like to see this bug fixed and are able to reproduce it
against a later version of Fedora please change the 'version' of this
bug to the applicable version. If you are unable to change the version,
please add a comment here and someone will do it for you.
Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.
The process we are following is described here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Fedora 10 changed to end-of-life (EOL) status on 2009-12-17. Fedora 10 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.
If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version.
Thank you for reporting this bug and we are sorry it could not be fixed.

Note

You need to
log in
before you can comment on or make changes to this bug.