EeePC Volume and Wireless Hotkeys Do Not Function Out-Of-The-Box with Ubuntu (8.04 Hardy LTS, Intrepid Alpha 1)

Bug #232170 reported by Matt Austin on 2008-05-20
This bug affects 13 people
Affects Status Importance Assigned to Milestone
Fix Released
Fix Released
Fix Released
acpi-support (Debian)
Fix Released
acpi-support (Ubuntu)
Declined for Hardy by Brian Murray
Declined for Intrepid by Steve Langasek
Nominated for Jaunty by Luis Silva
linux (Ubuntu)
Andy Whitcroft
Declined for Hardy by Brian Murray
Declined for Intrepid by Steve Langasek
Nominated for Jaunty by Luis Silva

Bug Description

The Asus EeePC is a popular subnotebook computer.

With a fresh install of Ubuntu 8.04 LTS (Hardy Heron) the wireless (fn+f2) and volume hotkeys (fn+f7/f8/f9) do not function.

Expected function:
fn+f2: Toggle wireless
fn+f7: Mute/Unmute
fn+f8: Volume up
fn+f9: Volume down

Workarounds are documented here:
Wireless Hotkey:
Volume Hotkeys:
Although I have not had much success at getting these working myself.

It would be great if these would work out-of-the-box with 8.04.1 or Intrepid.

merc (escalated) wrote :

I can confirm that the wireless and volume hotkeys do not work(although I upgraded from 7.10 to 8.04, I made no configuration changes before upgrading)

Changed in linux:
status: New → Confirmed

I can also confirm this.

77 comments hidden view all 119 comments

This should be done in the kernel, with the module handling the Eeepc using the
input layer to push the events to user-space.

(In reply to comment #1)
> This should be done in the kernel, with the module handling the Eeepc using the
> input layer to push the events to user-space.

I've replaced the preliminary eeepc driver in F9 with the final eeepc-laptop
driver from rawhide/2.6.26. If that one doesn't work by using the input layer
to push the events then you are asking for a rewrite of the driver.

(In reply to comment #0)
> Description of problem: FN keys in eeePC don't work out of the box, there is the
> need to write down some scripts to handle these events
> Actual results:
> we got working wireless on/off, display to external monitor, volume controls,
> with these scripts (just workarounds):

Is there any way you can test rawhide to see if it works any better out of the box?

1-rawnhide kernel
2-F9 upgraded to rawhide
3-Rawhide fresh install

which one?

Tried kernel-2.6.26-0.67.rc6.git1 (rawihide)
reverted tweaks, acpid, etc. So stock fedora setup.

Fn+F1 (suspend) WORKS...also backlight resume (yeah!! very nice)

Fn+F2 (WIFI TOGGLE) NOT WORK... :-( (this is very useful...)


Fn+F5 (LCD/EXTERNAL MONITOR SWITCH) I don't know if works..because I can't test
it out... My ext monitor is broken

Fn+F6 (originally was for opening terminal in xandros) OBVIOUSLY doesn't
work..This fn is unuseful with stock linux distributions.... I used it in
scripts, to toggle webcam (as mandriva and other distributions do) it
should be an idea to let this key toggle webcam....

Fn+F7 (Toggle MUTE) NOT WORK

Thanks for attention :)

(In reply to comment #5)
> Tried kernel-2.6.26-0.67.rc6.git1 (rawihide)
> reverted tweaks, acpid, etc. So stock fedora setup.
> Fn+F1 (suspend) WORKS...also backlight resume (yeah!! very nice)
> Fn+F7 (Toggle MUTE) NOT WORK

The backlight and suspend keys working is good (I guess this gets through ACPI,
and is captured by hal and passed onto gnome-power-manager). Do the backlight
keys show a popup when in GNOME?

The other keys not working is a bit of a problem, but they're not expected to
work out-of-the-box for the most part.

I checked out the eeepc-laptop driver in the linux-next git tree, and it doesn't
pass those extra keys through the input layer (so the keys aren't visible in

Could you check whether you see any error messages in dmesg when using the keys,
or whether the keys work using "xev" while running X?

No...I think backlight keys are bios handled...they work also in grub, kernel
booting, etc....
No popup.....

no xev output for Fn keys and no dmesg ....

because of this, we used acpid and some scripts to handle these events....I
don't remember what we used to read the keyevents.

So... the "lamer" scripts + acpid must continue to exist.... I don't think
someone will handle this events in kernel or with an official rpm.....

(In reply to comment #7)
> No...I think backlight keys are bios handled...they work also in grub, kernel
> booting, etc....
> No popup.....
> no xev output for Fn keys and no dmesg ....
> because of this, we used acpid and some scripts to handle these events....I
> don't remember what we used to read the keyevents.
> So... the "lamer" scripts + acpid must continue to exist.... I don't think
> someone will handle this events in kernel or with an official rpm.....

The kernel module will need some work then. I copied Matthew and Richard that
could help. It would certainly be easier if they had access to an EeePC ;)

Created attachment 309396
Add input support to eeepc hotkey driver

Would be helpful if someone could give this a go - I don't have an eee. The
radio handling is going to be suboptimal until either madwifi gains rfkill
support or ath5k works on this hardware.

Though, looking at it, it should be possible to implement rfkill in the eee
driver itself. That would almost certainly be preferable.

The wifi handling code is, it turns out, insane. I'll do a new patch now.

Created attachment 309502
Updated patch

This cleans up the rfkill handling. An rfkill device is registered (and so the
wlan entry is removed from sysfs) and the wireless button generates KEY_WLAN.
If rfkill-input is loaded (which really ought to be the default, but doesn't
seem to be yet?) then the default behaviour will be for the state to be toggled
on button presses. Again, entirely untested beyond building. Could someone try
this on real hardware?

Can you build this patch in a kernel build on koji? madwifi isn't compiling in
2.6.26....I'm searching a solution for you have all the time you want :)

(In reply to comment #12)
> Created an attachment (id=309502) [edit]
> Updated patch

Are you submitting this upstream too?

Once I've got some confirmation that it works, sure :) I don't have an eee.

I managed to install madwifi in 2.6.26, and now I'm using only the 2.6.26 git2
kernel..... I can't patch and compile the kernel myself, because my home pc is
broken (sigh) and the celeron cpu in my eeepc will burn in compiling it....

Can anyone build a testing kernel rpm for me? so I can test out your changes...

thankyou all for the great work you are doing in eeepc support...I'm sure this
will be helpful for us!

91 comments hidden view all 119 comments
elmurato (elmurato87) wrote :

Installing this package fixes it also:
Works with Xubuntu and Ubuntu. Kubuntu not tested...

Jeff Sereno (jsereno) wrote :

I note that for some reason, even with the eee-osd fix to get the hotkeys going, Ubuntu Hardy on my EeePC 701 does not save the volume level upon a reboot, and starts up again with the volume at 100%. This is probably unrelated to the hotkeys themselves, however.

Matt Austin (mattaustin) wrote :

Confirming that this is still an issue in Intrepid Ibex Alpha 1.

Changed in acpi-support:
status: Unknown → Fix Released
90 comments hidden view all 119 comments

Added to Rawhide kernel, should hit the archive later today. Verified to work on a 900, but should be fine on the 700 series as well. Wifi now handled by rfkill (make sure that the rfkill-input module is loaded). Keys are sent via the input layer.

Should this patch be backported to F9 as well?

90 comments hidden view all 119 comments
Matt Austin (mattaustin) wrote :

All hotkeys (sleep, wireless, brightness, volume) are not working in Intrepid Ibex Alpha 4 (with latest updates, 2.6.27-1-generic).

The Ubuntu Kernel Team is planning to move to the 2.6.27 kernel for the upcoming Intrepid Ibex 8.10 release. As a result, the kernel team would appreciate it if you could please test this newer 2.6.27 Ubuntu kernel. There are one of two ways you should be able to test:

1) If you are comfortable installing packages on your own, the linux-image-2.6.27-* package is currently available for you to install and test.


2) The upcoming Alpha5 for Intrepid Ibex 8.10 will contain this newer 2.6.27 Ubuntu kernel. Alpha5 is set to be released Thursday Sept 4. Please watch for Alpha5 to be announced. You should then be able to test via a LiveCD.

Please let us know immediately if this newer 2.6.27 kernel resolves the bug reported here or if the issue remains. More importantly, please open a new bug report for each new bug/regression introduced by the 2.6.27 kernel and tag the bug report with 'linux-2.6.27'. Also, please specifically note if the issue does or does not appear in the 2.6.26 kernel. Thanks again, we really appreicate your help and feedback.

Tested my EeePC 701 (4G) with Intrepid Alpha 5. The function keys are still not working as expected:

Fn+F1 Standby Works
Fn+F2 WiFi-enable Does not work
Fn+F3/F4 Brightness control Works but with a lot of lag, not as responsive as usual
Fn+F5 VGA-toggle Does Volume up?!
Fn+F6 Task-Manager Does not work
Fn+F7 Mute/Unmute Does not work
Fn+F8 Volume down Does not work
Fn+F9 Volume up Does not work

Lapppi (k-jenkins) wrote :

Tested on EeePC 701 4G using the latest daily build of Intrepid.

Confirm findings as indicated by Paulo Albuquerque in his report.

I can confirm that this bug still exists on Intrepid fully updated to 15 September 2008 on an EEE PC 701 4G.

Adam McDaniel (adamrmcd) wrote :

Confirming what bedfojo results on my EeePC 900.

Also, another oddity experienced in Hardy still exists in Intrepid related to ACPI hotkeys: Plugging in the AC adapter still triggers an ACPI event similar to an 'E-Mail' hotkey; Evolution launches.

Indeed, in addition to Adam Mc Daniel's comment, I note a regression in Intrepid from Hardy/Gutsy in that none of the scripts on the internet (see now function to make the hotkeys work.

rayhaque (rayhaque) wrote :

I have a 701 4G Surf. I'm running the latest "daily" of Intrepid - updated this morning. Confirming that hot-keys do not work.

F1 (Suspend) disables networking momentarily, and then restores it. Here is what I catch in /var/log/messages ...

Sep 17 10:12:24 ray-laptop gnome-power-manager: (ray) Hibernating computer. Reason: The suspend button has been pressed.
Sep 17 10:12:29 ray-laptop kernel: [ 208.652012] ADDRCONF(NETDEV_UP): eth0: link is not ready
Sep 17 10:12:29 ray-laptop kernel: [ 208.826229] ADDRCONF(NETDEV_UP): wlan0: link is not ready
Sep 17 10:12:29 ray-laptop kernel: [ 208.826448] ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready
Sep 17 10:12:29 ray-laptop gnome-power-manager: (ray) Resuming computer

F2 (Wireless Toggle) - Pressing has no effect, no logged output.

F3/F4 (Brightness) - Work fine!

F5 (External display toggle), F6 (application button) - No desired effect, no fault found.

F7 (mute), F8 (Volume up), F9 (Volume down) - No effect, no logged output.

Should these hotkeys be controlled with the eeepc_laptop driver? I cannot find an answer on this anywhere. It seems that eeepc-acpi has been deprecated in favor of this new module. If that is the case, is there a better place to report eeepc_laptop bugs? I will do whatever I can to help this effort. :-)

rayhaque(at) Gmail(dot) com.

rayhaque (rayhaque) wrote :

I meant to include that running the latest Intrepid, I am also running the newest Kernel release ....

ray@ray-laptop:~$ uname -a
Linux ray-laptop 2.6.27-3-generic #1 SMP Wed Sep 10 16:02:00 UTC 2008 i686 GNU/Linux

Changed in linux:
assignee: nobody → ubuntu-kernel-team
importance: Undecided → Medium
status: Confirmed → Triaged
83 comments hidden view all 119 comments

Chuck: possibly although the wifi patch changes the nature of how things worked a bit so that my be an unwanted surprise (it is no longer possible to disable wifi before shutdown and expect it to be off when you next boot the machine as it will be toggled back on during boot).

On a related note, if you do decide to use this patch make sure you boot the kernel with the pciehp.pciehp_force=1 kernel parameter (at least on an Eee 900). Failure to do so will result in the inability to start the wifi after it has been stopped once (e.g. by hitting the wifi toggle hotkey while the wifi is on).

(I forgot to mention that the pciehp information was found over on )

83 comments hidden view all 119 comments
Sitsofe Wheeler (sitsofe) wrote :

Fedora have a fix for the volume keys that works for my upstream kernel too - . It also enables support for the wifi hotkey too (with the caveat that wifi will always been enabled on boot and that you have to use the pciehp.pciehp_force=1 boot parameter). Very elegant too.

Adam McDaniel (adamrmcd) wrote :

Any idea when/if Matthew Garrett's patch (re: Redhat bug 451182) will make it in Intrepid's base kernel?

I'm in the midst of compiling it for my 900 now. I'll post a summary with the results.

Sitsofe Wheeler (sitsofe) wrote :

I don't know what the Ubuntu policy is to kernel patches is at the moment - it apparently isn't frozen yet... - . Matthew's patch works well for me except every now and then the wifi hotkey will not work (but the sound ones will).

Following Sitsofe suggestion, I tried Matthew's patch on my eeepc 701.

At least, I get the volume keys working.

I still have issues with the wireless and display one; that needs some investigations.

I also noticed that this patch activates the wifi card when loaded.

Sitsofe Wheeler (sitsofe) wrote :

The display one is going to be problematic. These days you are expected to switch displays when X is running by using xrandr rather than poking the BIOS behind X's back (so really the key should be passed to a running program that then does the switch). You could argue that not having a means to do that is a separate bug from this though.

Re wifi always activated on boot, yes I noticed that too. You're absolutely right. It's not hard to toggle off again though.

What other issues were you having with the Wireless hotkey though? You are using pciehp_force too?

Current problems (still need further investigations):
- Display button make the volume to go up. Maybe a bad key configuration somewhere.
- Wireless button does not do anything; wireless is turned on when the module is loaded but nothing happens when I press the toggle off button. And yes, I'm using pciehp_force=1.

Adam McDaniel (adamrmcd) wrote :

BTW, I've added bluetooth control (a very minor change) to eeepc-laptop.ko, based upon more recent (and deprecated) eeepc-acpi.ko code to my local clone of ubuntu-intrepid.git:

commit e3c8316f0a41fdea91ee1e087578119000f24a9f
Author: Adam McDaniel <>
Date: Mon Sep 22 16:53:06 2008 -0600

    EEEPC: Added bluetooth attribute to /sys/devices/platform/eeepc/bt
    accessible through eeepc-laptop module, just like deprecated eeepc-acpi module.

Eventually this can be used to switch the built-in bluetooth radio on/off in this eeepc-laptop module, too, without the need of user-space ACPI scripts. Unfortunately, I cannot test this patch directly as I don't have an EeePC 901/1000/1000h.

If someone with one could apply it and verify if "/sys/devices/platform/eeepc/bt" is created, and writing 0 or 1 will disable/enable it. (Devices that lack on-board bluetooth should not see this file.)

Sitsofe Wheeler (sitsofe) wrote :

Hmm. Does using
echo 0 > /sys/class/rfkill/rfkill0/state
with the patch applied also fail to turn the wifi off?

Echoing 0/1 to /sys/class/rfkill/rfkill0/state works. Not the key itself.
Any advice if I should look in the eeepc-laptop module or in some keyboard configuration stuff ?

That said it's fun to see that without the eeepc-laptop module loaded, the FN+F2 key works out of the box. Other keys do not work, but that's another problem.

Sitsofe Wheeler (sitsofe) wrote :

Do you have another module loaded which is also trying to do hotkeys (e.g. a hacked up asus-apci)?

I found the problem; but from latest xorg developments, it does not seem to be easily solved:

In fact the wireless hotkey is working well when used in console mode, but when xorg with evdev is launched, it prevents rfkill_input to grab KEW_WLAN events and everything stops working.

It seems there are may be some ways to get hal doing the job:

After some more tests, the display button works well, and emits XF86Display event which is OK (except that if you do not bind this key to some desktop events, it is used a volume up).

So, Mattew's patch is working well on a eeepc 701, given that you tweak a little bit you modules:
- load pciehp with pciehp_force=1
- load rfkill_input (although that one only works if you switch to the console)

Seems this patch has been submitted upstream:

Bryce Harrington (bryce) wrote :

This has a task open against acpi-support, however are there actually any changes needed to this package for this? Sounds like this problem may be entirely a kernel issue?

Sitsofe Wheeler (sitsofe) wrote :

The unpatched eeepc module sends volume keys ass acpi events (which are currently mismapped in Ubuntu). You can work around this by changing acpi scripts. Matthew's patch send keys through the input layer doing away with ACPI altogether. Two approaches to solving the problem but I'd say Matthew's is cleaner and likely to go upstream at some point.

As regards the Fedora patch, the "the caveat that wifi will always be enabled on boot" would be a major regression for me.

I use my eeepc a lot on aircraft and in order to comply with the law, it should not use wifi at all in the air. I should be able to ensure that the machine will boot with wireless switched off.

options rfkill default_state=0

Should disable the wifi transmitter at boot time (in fact when the rfkill module loads).

69 comments hidden view all 119 comments

In testing against linux-tip this patch breaks the resume part of suspend to RAM on my EeePC 900...

68 comments hidden view all 119 comments
Sitsofe Wheeler (sitsofe) wrote :

A quick note, in testing against linux-tip the Red Hat bugzilla patch breaks the resume part of suspend to RAM on my EeePC 900...

69 comments hidden view all 119 comments

If you remove the rfkill registration, does it work?

Yes, if I remove rfkill registration then it works.

Ok. Can you readd the rfkill registration and then edit net/rfkill/rfkill.c and remove the

        .suspend = rfkill_suspend,
        .resume = rfkill_resume,

lines and see if that works?

Readding the registration and commenting out the above lines allows suspend and resume to work but trying to toggle the wifi power via the hotkey no longer works (even before suspending).

Created attachment 319477
Add bluetooth support to eeepc-laptop

The following patch adds bluetooth toggle support to eeepc-laptop.ko, through /sys/devices/platform/eeepc/bt (the same way that the deprecated eeepc-acpi module did.)

This patch is based upon the original import of the eeepc-laptop driver, committed e59f87966adef2cb03d419530e3ade5159487d6d by Eric Cooper at 2008-03-13 for v2.6.26-rc1.

It straddles code modified by the latest patch attached to this bug (add rfkill wlan support), but there's only one chunk which adds just two lines. Very easy to apply by hand :)

No, this needs to be done via rfkill. Hang on, let me try to generate a patch.

Wait, I already added code to control bluetooth via rfkill. Can you check whether it works? It should be in /sys/class/rfkill, with the type set to bluetooth.

74 comments hidden view all 119 comments
Sitsofe Wheeler (sitsofe) wrote :

Turns out there is a kernel bug that stops rfkill hotkeys working for the first five minutes after boot (!) so that may explain why the wifi hotkey was failing for you. See for details.

75 comments hidden view all 119 comments

Can do. However shouldn't there be an equivalent line like: "rfkill_allocate( &device->dev, RFKILL_TYPE_BLUETOOTH )" somewhere in eeepc-laptop.c, too?

For example, the 1000 has 4 special hotkeys (acpi codes 0x1a..0x1d) which some users have customized to provide bluetooth enable/disable.

Shouldn't applying something like that be handled by eeepc-laptop?

Regardless if the answer is yes or no, I'll retract my patch ;)

Comment on attachment 319477
Add bluetooth support to eeepc-laptop

Obsollete, already handled by rfkill

        if (get_acpi(CM_ASL_BLUETOOTH) != -1) {
                ehotk->eeepc_bluetooth_rfkill =
                        rfkill_allocate(&device->dev, RFKILL_TYPE_BLUETOOTH);

is already in there in the Rawhide kernel?

You'd know better than I. I'm coming from the ubuntu side, I'm just checking in because I'm interested in the rfkill/wlan patch you developed.

Incidentally, I had the same problem described in comment #21 last night, and the fix from #24 did appear to solve it. However, Sitsofe's comment #25 is still a problem (Fn-F2 wifi key doesn't toggle wifi). BUT, wifi does correctly respond if I manually inject 0 or 1 to "/sys/class/rfkill/.../state" type wlan.

There appears to be a disconnect, possibly with nothing actually using NOTIFY_WLAN_ON, or KEY_WLAN in 'static struct key_entry eeepc_keymap[]'

> is already in there in the Rawhide kernel?

That's a very good question. Google and I couldn't find a git repo for rawhide's kernel. If you can direct me where to grab it, I can probably find the answers to my problem myself ;)

Fedora kernel is kept in CVS - patches are at . The key will do nothing unless you have the rfkill-input module loaded. We've tracked down the issue with it failing to work on boot - I'm getting a fix into rfkill upstream now.

The "broken" wifi toggling hotkey turned out to be due to rfkill hotkeys not working until five minutes after the system has booted. Matthew has already posted a patch to fix this on .

That's odd. I'm probably OTL but I left my EeePC 900 online for a few hours last night. Even with the 5-minute known issue, Fn-F2 still never triggered wireless. (I was trying roughly every 30 min.)

I saw [PATCH v3] on the LKML, I'll give it a shot next, plus the unique bits still in fedora's linux-2.6-eeepc-laptop-update.patch and linux-2.6-wireless-pending.patch.

I assume that if a patch is committed to Fedora's CVS server, it's been signed-off and tested by Fedora's team and they're promoting it for linux-tip?

Thx :)


You have rfkill-input loaded, right?

Sorry, I forgot to mention that I did. However it didn't autoprobe on bootup like rfkill did c/o the eeepc-laptop dependency.

Shouldn't eeepc-laptop also depend on rfkill-input?

I believe someone posted a patch for the rfkill dependency on . I wouldn't have seen module issues as I don't build modules for my kernel...

84 comments hidden view all 119 comments

I also noticed some strange behavior just after boot; and the patch for rfkill_input may solve it.

But there is another problem coming from the way key events are processed: xorg evdev driver catch all input events and rfkill_input do not see them anymore when under X.

If I switch in console mode, everything works fine.

85 comments hidden view all 119 comments

I'm testing out the kernel ...

rfkill-input and ath5k need manual modprobe. So I hope they will be automagically modprobed soon...

They SEEM to work... network manager doesn't like's unable to reload wifi...

maybe I'll try a rawhide network manager release... I'm with the fedora 9 stable one.

84 comments hidden view all 119 comments
Christopher (chriruud) wrote :

Adam: on the 1000, doing "echo 0 |sudo tee /sys/devices/platform/eeepc/bt" doesn't seem to do anything.
Doing a cat eeepc/bt returns -19 every time, so it seems like it either is a permissions problem or something else.
So far, with all the patches I've yet to see, wlan, bluetooth and volume up/down/mute won't work, neither with acpi - scripts or via modules. No evidence in any log to sugest they were ever pressed either.

elmurato (elmurato87) wrote :

I can confirm the BT bug with my 901. A "cat /sys/devices/platform/eeepc/bt" gives me "-19" and I can`t change it to 0 or 1.

And I have anpther problem: Everytime I use the command with rfkill to toggle my wifi card the whole machine just freezes. That is very annoying...

Camera toggle works...

Robin Sheat (eythian) wrote :

On an install of Intrepid, the volume keys are still invisible to X. There is a package 'eeepc-acpi-scripts' that looks like it has potential, but it conflicts with acpi-support, which is required by ubuntu-desktop, and so it's uninstallable. This is with an eee 701. The keys worked in Hardy with the addition of eeepc-acpi-source or whatever it was.

Robin Sheat (eythian) wrote :

I plan to do some experimenting with this, but in /etc/acpi/events/asus-eee-volume-up there is the line:
robin@gulik:~$ /etc/acpi/
bash: /etc/acpi/ No such file or directory

Robin Sheat (eythian) wrote :

So, my experimentation bears fruit. I created a file (for test purposes, it's clearly not a global solution):
robin@gulik:/etc/acpi$ cat
`dirname $0`/$1

which doesn't really test to see if it is an eeepc, it just runs the command anyway. Now my volume (mute, vol up, vol dn) work just fine. Wireless doesn't (sleep and brightness always have.)

Robin Sheat (eythian) wrote :

Clarification: the wireless button doesn't work, wireless itself appears to.

Is there a way to see what signals hotkeys raise? It might just be that it needs its own event file with a particular event= definition. I just have no idea how to find out what that should be.

Sitsofe Wheeler (sitsofe) wrote :

You aren't going to be able to get the wireless hotkey working without support within the kernel itself (support that is not in the released Intrepid kernel) or some pretty nasty hacks (assuming it emits an ACPI event). You can try monitoring the acpi log file to see whether this is the case.

Steve Langasek (vorlon) on 2009-02-17
Changed in acpi-support:
status: New → Invalid
Andy Whitcroft (apw) on 2009-03-04
Changed in linux:
assignee: nobody → apw
status: Triaged → In Progress
Andy Whitcroft (apw) on 2009-03-04
Changed in linux:
status: In Progress → Incomplete
Andy Whitcroft (apw) on 2009-04-28
Changed in linux (Ubuntu):
status: Incomplete → Fix Released
Changed in mandriva:
importance: Unknown → High
Changed in centos:
importance: Unknown → Low
Changed in fedora:
importance: Unknown → Low
Displaying first 40 and last 40 comments. View all 119 comments or add a comment.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.