Bug 183679 - gnome-power-manager does not properly detect charge on Logitech MX-1000 cordless mouse
gnome-power-manager does not properly detect charge on Logitech MX-1000 cordl...
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: hal (Show other bugs)
rawhide
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: David Zeuthen
:
Depends On: 184431
Blocks:
  Show dependency treegraph
 
Reported: 2006-03-02 14:31 EST by Bernard Johnson
Modified: 2013-03-05 22:45 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-04-02 19:35:25 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
notification (34.37 KB, image/png)
2006-03-02 14:32 EST, Bernard Johnson
no flags Details
gnome-power-manager verbose output (5.81 KB, text/plain)
2006-03-02 14:33 EST, Bernard Johnson
no flags Details
haldaemon verbose output as requested (130.72 KB, text/plain)
2006-03-03 05:29 EST, Bernard Johnson
no flags Details
gnome-power-manager verbose output (permissive mode) (9.12 KB, text/plain)
2006-03-08 14:38 EST, Bernard Johnson
no flags Details

  None (edit)
Description Bernard Johnson 2006-03-02 14:31:32 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.1) Gecko/20060223 Fedora/1.5.0.1-5 Firefox/1.5.0.1

Description of problem:
gnome-power-manager thinks my MX-1000 cordless mouse is not charged, but it is.  Detecting a 0% charge seems to have helped lead to the crash in bug #183127 (see Richard Hughes' comment #4).

Version-Release number of selected component (if applicable):
gnome-power-manager-2.13.92-3

How reproducible:
Always

Steps to Reproduce:
1. note charge level reported by gnome-power-manager
2.
3.
  

Actual Results:  0% charge reported

Expected Results:  correct charge level should be reported

Additional info:

This version of gnome-power-manager is from bug #183127, comment #8.
Comment 1 Bernard Johnson 2006-03-02 14:32:39 EST
Created attachment 125558 [details]
notification

Notification that the battery is at 0%
Comment 2 Bernard Johnson 2006-03-02 14:33:16 EST
Created attachment 125559 [details]
gnome-power-manager verbose output
Comment 3 Ray Strode [halfline] 2006-03-02 15:42:36 EST
"Error: No property battery.charge_level.percentage on device with id
/org/freedesktop/Hal/devices/usb_device_46d_c50e_noserial"

Looks like HAL isn't setting the right properties.

Reassigning to HAL componenet...
Comment 4 Richard Hughes 2006-03-03 04:27:26 EST
>Looks like HAL isn't setting the right properties.

Not really, battery.charge_level.percentage is optional.

What does lshal |grep battery report?
Comment 5 Bernard Johnson 2006-03-03 04:35:20 EST
[bjohnson@localhost ~]$ lshal | grep battery
  info.capabilities = {'battery'} (string list)
  battery.command_interface = 'csr'  (string)
  info.category = 'battery'  (string)
  battery.charge_level.last_full = 7  (0x7)  (int)
  battery.charge_level.design = 7  (0x7)  (int)
  battery.present = true  (bool)
  battery.csr.is_dual = false  (bool)
  battery.csr.has_sms = false  (bool)
  battery.csr.has_res = false  (bool)
  battery.is_rechargeable = true  (bool)
  battery.type = 'mouse'  (string)
Comment 6 Richard Hughes 2006-03-03 04:53:39 EST
So its fully charged... hmm. Give me 5 minutes.
Comment 7 Richard Hughes 2006-03-03 05:15:19 EST
I get this:

  info.capabilities = {'battery'} (string list)
  battery.charge_level.percentage = 42  (0x2a)  (int)
  battery.charge_level.current = 3  (0x3)  (int)
  battery.command_interface = 'csr'  (string)
  info.category = 'battery'  (string)
  battery.charge_level.last_full = 7  (0x7)  (int)
  battery.charge_level.design = 7  (0x7)  (int)
  battery.present = true  (bool)
  battery.csr.is_dual = false  (bool)
  battery.csr.has_sms = false  (bool)
  battery.csr.has_res = false  (bool)
  battery.is_rechargeable = true  (bool)
  battery.type = 'mouse'  (string)

Notice that your `lshal | grep battery` does not include
battery.charge_level.current which is why g-p-m cannot compute a percentage from
the device.

This smells like a HAL problem, i.e. a problem with the CSR addon -- is it
running, i.e. what does:

ps -fA |grep csr

return?
Comment 8 Bernard Johnson 2006-03-03 05:20:18 EST
[bjohnson@localhost ~]$ ps -fA | grep csr
root      3785  2090  0 03:22 ?        00:00:00 /usr/libexec/hald-addon-usb-csr
bjohnson  3825  3804  0 03:23 pts/1    00:00:00 grep csr
Comment 9 Richard Hughes 2006-03-03 05:22:57 EST
what about if you do (as root):

/sbin/service haldaemon stop
/usr/sbin/hald --daemon=no --verbose=yes &> /tmp/hald.txt
/sbin/service haldaemon start

and then attach /tmp/hald.txt

Thanks, Richard.
Comment 10 Bernard Johnson 2006-03-03 05:29:47 EST
Created attachment 125587 [details]
haldaemon verbose output as requested
Comment 11 Richard Hughes 2006-03-03 05:38:43 EST
So it gets it wrong first,

3934: 03:32:34.859: addon-usb-csr.c:149: Charge level: 0->5

And gets it right a few moments after.

3934: 03:33:04.871: addon-usb-csr.c:149: Charge level: 5->5

Please disconnect your mouse, and restart haldaemon.

then run "lshal -m" in one open window

then plug it in and wait a few moments.

What does that give?

Thanks.

Richard.
Comment 12 Bernard Johnson 2006-03-03 05:45:46 EST
[root@localhost ~]# service haldaemon restart
Stopping HAL daemon:                                       [  OK  ]
Starting HAL daemon:                                       [  OK  ]
[root@localhost ~]# lshal -m

Start monitoring devicelist:
-------------------------------------------------
usb_device_46d_c50e_noserial added
usb_device_46d_c50e_noserial property battery.present = true (new)
usb_device_46d_c50e_noserial property battery.charge_level.design = 7 (0x7) (new)
usb_device_46d_c50e_noserial property battery.charge_level.last_full = 7 (0x7) (new)
usb_device_46d_c50e_noserial property info.category = 'battery' (new)
usb_device_46d_c50e_noserial property battery.command_interface = 'csr' (new)
usb_device_46d_c50e_noserial property info.capabilities = {'battery'} (new)
usb_device_46d_c50e_noserial capability battery added
usb_device_46d_c50e_noserial_if0 added
usb_device_46d_c50e_noserial_usbraw added
usb_device_46d_c50e_noserial_if0_logicaldev_input added
Comment 13 Richard Hughes 2006-03-03 05:51:32 EST
That is very odd. Are you running dbus 0.61 by any chance? Could you try
downgrading to 0.60 and see if that fixes the lshal -m output to include
battery.charge_level.current.

I have a hunch this might work.

Richard.
Comment 14 Bernard Johnson 2006-03-03 06:08:39 EST
Since this was a fully updated rawhide system, the dbus version was dbus-0.61-3.
 I downgraded dbus (and dependencies) to dbus-0.60-7.2.  The results appear to
be the same:

[root@localhost ~]# service haldaemon restart
Stopping HAL daemon:                                       [  OK  ]
Starting HAL daemon:                                       [  OK  ]
[root@localhost ~]# lshal -m

Start monitoring devicelist:
-------------------------------------------------
usb_device_46d_c50e_noserial added
usb_device_46d_c50e_noserial property battery.present = true (new)
usb_device_46d_c50e_noserial property battery.charge_level.design = 7 (0x7) (new)
usb_device_46d_c50e_noserial property battery.charge_level.last_full = 7 (0x7) (new)
usb_device_46d_c50e_noserial property info.category = 'battery' (new)
usb_device_46d_c50e_noserial property battery.command_interface = 'csr' (new)
usb_device_46d_c50e_noserial property info.capabilities = {'battery'} (new)
usb_device_46d_c50e_noserial capability battery added
usb_device_46d_c50e_noserial_if0 added
usb_device_46d_c50e_noserial_if0_logicaldev_input added
usb_device_46d_c50e_noserial_usbraw added

Comment 15 Richard Hughes 2006-03-06 13:43:04 EST
Have you tried turning off selinux? Do you get any avc denied messages in your logs?
Comment 16 Bernard Johnson 2006-03-06 14:50:57 EST
I have tried putting selinux in permissive mode with the same result as
enforcing mode.  I do get a couple of avc: denied messages in both cases.  Would
there be any reason to turn off selinux rather than just use permissive mode??

Audit messages produced by plugging in the mouse:
type=AVC msg=audit(1141674754.524:41): avc:  denied  { read write } for 
pid=2584 comm="hald-addon-usb-" name="003" dev=tmpfs ino=3791
scontext=system_u:system_r:hald_t:s0 tcontext=system_u:object_r:usb_device_t:s0
tclass=chr_file
type=SYSCALL msg=audit(1141674754.524:41): arch=40000003 syscall=5 success=no
exit=-13 a0=bfaac93e a1=2 a2=1 a3=bfaac93e items=1 pid=2584 auid=4294967295
uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 comm="hald-addon-usb-"
exe="/usr/libexec/hald-addon-usb-csr"
type=CWD msg=audit(1141674754.524:41):  cwd="/usr/libexec"
type=PATH msg=audit(1141674754.524:41): item=0 name="/dev/bus/usb/001/003"
flags=101  inode=3791 dev=00:0f mode=020644 ouid=0 ogid=0 rdev=bd:02
type=AVC msg=audit(1141674754.524:42): avc:  denied  { read } for  pid=2584
comm="hald-addon-usb-" name="003" dev=tmpfs ino=3791
scontext=system_u:system_r:hald_t:s0 tcontext=system_u:object_r:usb_device_t:s0
tclass=chr_file
type=SYSCALL msg=audit(1141674754.524:42): arch=40000003 syscall=5 success=no
exit=-13 a0=bfaac93e a1=0 a2=1 a3=bfaac93e items=1 pid=2584 auid=4294967295
uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 comm="hald-addon-usb-"
exe="/usr/libexec/hald-addon-usb-csr"
type=CWD msg=audit(1141674754.524:42):  cwd="/usr/libexec"
type=PATH msg=audit(1141674754.524:42): item=0 name="/dev/bus/usb/001/003"
flags=101  inode=3791 dev=00:0f mode=020644 ouid=0 ogid=0 rdev=bd:02
type=AVC msg=audit(1141674754.524:43): avc:  denied  { read write } for 
pid=2584 comm="hald-addon-usb-" name="002" dev=tmpfs ino=3504
scontext=system_u:system_r:hald_t:s0 tcontext=system_u:object_r:usb_device_t:s0
tclass=chr_file
type=SYSCALL msg=audit(1141674754.524:43): arch=40000003 syscall=5 success=no
exit=-13 a0=bfaac93e a1=2 a2=1 a3=bfaac93e items=1 pid=2584 auid=4294967295
uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 comm="hald-addon-usb-"
exe="/usr/libexec/hald-addon-usb-csr"
type=CWD msg=audit(1141674754.524:43):  cwd="/usr/libexec"
type=PATH msg=audit(1141674754.524:43): item=0 name="/dev/bus/usb/001/002"
flags=101  inode=3504 dev=00:0f mode=020644 ouid=0 ogid=0 rdev=bd:01
type=AVC msg=audit(1141674754.524:44): avc:  denied  { read } for  pid=2584
comm="hald-addon-usb-" name="002" dev=tmpfs ino=3504
scontext=system_u:system_r:hald_t:s0 tcontext=system_u:object_r:usb_device_t:s0
tclass=chr_file
type=SYSCALL msg=audit(1141674754.524:44): arch=40000003 syscall=5 success=no
exit=-13 a0=bfaac93e a1=0 a2=1 a3=bfaac93e items=1 pid=2584 auid=4294967295
uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 comm="hald-addon-usb-"
exe="/usr/libexec/hald-addon-usb-csr"
type=CWD msg=audit(1141674754.524:44):  cwd="/usr/libexec"
type=PATH msg=audit(1141674754.524:44): item=0 name="/dev/bus/usb/001/002"
flags=101  inode=3504 dev=00:0f mode=020644 ouid=0 ogid=0 rdev=bd:01
type=AVC msg=audit(1141674754.528:45): avc:  denied  { read write } for 
pid=2584 comm="hald-addon-usb-" name="001" dev=tmpfs ino=3474
scontext=system_u:system_r:hald_t:s0 tcontext=system_u:object_r:usb_device_t:s0
tclass=chr_file
type=SYSCALL msg=audit(1141674754.528:45): arch=40000003 syscall=5 success=no
exit=-13 a0=bfaac93e a1=2 a2=1 a3=bfaac93e items=1 pid=2584 auid=4294967295
uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 comm="hald-addon-usb-"
exe="/usr/libexec/hald-addon-usb-csr"
type=CWD msg=audit(1141674754.528:45):  cwd="/usr/libexec"
type=PATH msg=audit(1141674754.528:45): item=0 name="/dev/bus/usb/001/001"
flags=101  inode=3474 dev=00:0f mode=020644 ouid=0 ogid=0 rdev=bd:00
type=AVC msg=audit(1141674754.528:46): avc:  denied  { read } for  pid=2584
comm="hald-addon-usb-" name="001" dev=tmpfs ino=3474
scontext=system_u:system_r:hald_t:s0 tcontext=system_u:object_r:usb_device_t:s0
tclass=chr_file
type=SYSCALL msg=audit(1141674754.528:46): arch=40000003 syscall=5 success=no
exit=-13 a0=bfaac93e a1=0 a2=1 a3=bfaac93e items=1 pid=2584 auid=4294967295
uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 comm="hald-addon-usb-"
exe="/usr/libexec/hald-addon-usb-csr"
type=CWD msg=audit(1141674754.528:46):  cwd="/usr/libexec"
type=PATH msg=audit(1141674754.528:46): item=0 name="/dev/bus/usb/001/001"
flags=101  inode=3474 dev=00:0f mode=020644 ouid=0 ogid=0 rdev=bd:00
type=AVC msg=audit(1141674754.528:47): avc:  denied  { read write } for 
pid=2584 comm="hald-addon-usb-" name="001" dev=tmpfs ino=3418
scontext=system_u:system_r:hald_t:s0 tcontext=system_u:object_r:usb_device_t:s0
tclass=chr_file
type=SYSCALL msg=audit(1141674754.528:47): arch=40000003 syscall=5 success=no
exit=-13 a0=bfaac93e a1=2 a2=1 a3=bfaac93e items=1 pid=2584 auid=4294967295
uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 comm="hald-addon-usb-"
exe="/usr/libexec/hald-addon-usb-csr"
type=CWD msg=audit(1141674754.528:47):  cwd="/usr/libexec"
type=PATH msg=audit(1141674754.528:47): item=0 name="/dev/bus/usb/002/001"
flags=101  inode=3418 dev=00:0f mode=020644 ouid=0 ogid=0 rdev=bd:80
type=AVC msg=audit(1141674754.528:48): avc:  denied  { read } for  pid=2584
comm="hald-addon-usb-" name="001" dev=tmpfs ino=3418
scontext=system_u:system_r:hald_t:s0 tcontext=system_u:object_r:usb_device_t:s0
tclass=chr_file
type=SYSCALL msg=audit(1141674754.528:48): arch=40000003 syscall=5 success=no
exit=-13 a0=bfaac93e a1=0 a2=1 a3=bfaac93e items=1 pid=2584 auid=4294967295
uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 comm="hald-addon-usb-"
exe="/usr/libexec/hald-addon-usb-csr"
type=CWD msg=audit(1141674754.528:48):  cwd="/usr/libexec"
type=PATH msg=audit(1141674754.528:48): item=0 name="/dev/bus/usb/002/001"
flags=101  inode=3418 dev=00:0f mode=020644 ouid=0 ogid=0 rdev=bd:80
Comment 17 Richard Hughes 2006-03-06 14:53:02 EST
Might be worth disabling it completely and seeing if that does the trick.
Comment 18 John (J5) Palmieri 2006-03-06 15:31:26 EST
permissive mode `setenforce 0` should turn off se-linux but still get you log
messages so if it doesn't work with permissive mode it won't work even if you
shut se-linux off.  That being said the logs do show some issues with usb.
Comment 19 Bernard Johnson 2006-03-06 16:30:08 EST
I just noticed that if I boot with selinux=0 or permissive mode, the
gnome-power-manager applet does not appear until after I unplug the mouse and
plug it back in.  In enforcing mode, it appears right away.  I don't know if
that's helpful or not.
Comment 20 Thomas J. Baker 2006-03-08 09:38:34 EST
I'm seeing the same problems; same mouse with the same selinux errors. Setting
permissive mode, restarting hal, restarting gnome-power-manager, and replugging
the mouse don't seem to fix anything. I'm running current rawhide.
Comment 21 Thomas J. Baker 2006-03-08 09:39:26 EST
I should add:

zero> lshal | grep battery
  battery.charge_level.percentage = 100  (0x64)  (int)
  battery.charge_level.current = 7  (0x7)  (int)
  info.capabilities = {'battery'} (string list)
  battery.command_interface = 'csr'  (string)
  info.category = 'battery'  (string)
  battery.charge_level.last_full = 7  (0x7)  (int)
  battery.charge_level.design = 7  (0x7)  (int)
  battery.present = true  (bool)
  battery.csr.is_dual = false  (bool)
  battery.csr.has_sms = false  (bool)
  battery.csr.has_res = false  (bool)
  battery.is_rechargeable = true  (bool)
  battery.type = 'mouse'  (string)
zero>
Comment 22 Bernard Johnson 2006-03-08 13:35:06 EST
I went ahead and filed bug #184431 against selinux-policy-targeted.  It doesn't
appear to specifically cause this problem, but once this is resolved, it likely
won't work without a policy update either.
Comment 23 Bernard Johnson 2006-03-08 14:35:50 EST
I was just noticing in comment #21 that Thomas has
battery.charge_level.percentage, so I decided to investigate further.  As it
turns out, there is definately a selinux problem when in enforcing mode.  Here
is the output differences from lshal in enforcing and permissive mode:

[bjohnson@localhost ~]$ diff -u enforcing permissive
--- enforcing   2006-03-08 12:22:11.000000000 -0700
+++ permissive  2006-03-08 12:23:45.000000000 -0700
@@ -1,4 +1,6 @@
   info.capabilities = {'battery'} (string list)
+  battery.charge_level.percentage = 100  (0x64)  (int)
+  battery.charge_level.current = 7  (0x7)  (int)
   battery.command_interface = 'csr'  (string)
   info.category = 'battery'  (string)
   battery.charge_level.last_full = 7  (0x7)  (int)

So I went ahead and checked 'lshal -m' as I plugged in the mouse.  It is
different in enforcing mode.  In permissive mode, the last two lines appear
about 10-15 seconds after the device is plugged in.

[bjohnson@localhost ~]$ lshal -m

Start monitoring devicelist:
-------------------------------------------------
usb_device_46d_c50e_noserial added
usb_device_46d_c50e_noserial property battery.present = true (new)
usb_device_46d_c50e_noserial property battery.charge_level.design = 7 (0x7) (new)
usb_device_46d_c50e_noserial property battery.charge_level.last_full = 7 (0x7) (new)
usb_device_46d_c50e_noserial property info.category = 'battery' (new)
usb_device_46d_c50e_noserial property battery.command_interface = 'csr' (new)
usb_device_46d_c50e_noserial property info.capabilities = {'battery'} (new)
usb_device_46d_c50e_noserial capability battery added
usb_device_46d_c50e_noserial_if0 added
usb_device_46d_c50e_noserial_usbraw added
usb_device_46d_c50e_noserial_if0_logicaldev_input added
usb_device_46d_c50e_noserial property battery.charge_level.current = 7 (0x7) (new)
usb_device_46d_c50e_noserial property battery.charge_level.percentage = 100
(0x64) (new)

It does not, however, change the problem with the charge level being properly
displayed in gnome-power-manager.
Comment 24 Bernard Johnson 2006-03-08 14:38:13 EST
Created attachment 125831 [details]
gnome-power-manager verbose output (permissive mode)
Comment 25 Bernard Johnson 2006-03-08 17:57:18 EST
Now that my device is showing charge percentage, I did try to go back and try
the old version of dbus as suggested in comment #13 again.  Last time I tried
it, I basically got the same results as with 0.61.  Now I can't run it at all:

gnome-power-manager: symbol lookup error: gnome-power-manager: undefined symbol:
dbus_g_type_get_struct
Comment 26 John (J5) Palmieri 2006-03-08 18:41:08 EST
Yes, there was an issue with dbus-0.61 and g-p-m in the glib bindings since now
the glib bindings have a struct type.  The newwer g-p-m was patched to use the
new struct type and in only compatable with 0.61.  We should up the Requires
line for the new dbus verion in the g-p-m spec.  If you upgrade to the latest
stuff it might fix the battery issue or may not.  Try it out.   
Comment 27 Thomas J. Baker 2006-03-09 08:52:01 EST
After todays updates, avc messages are gone but so is the gnome-power-manager
icon. It's running but doesn't report about the mouse at all.
Comment 28 Bernard Johnson 2006-03-12 13:37:50 EST
Thomas

Once your desktop is loaded, try unplugging your mouse and plugging it back in.
 On my system, that brings up gnome-power-manager.
Comment 29 Thomas J. Baker 2006-03-13 08:27:55 EST
That does indeed make it show up but it still incorrectly reports the mouse
status. I'm guessing it should also come up on its own too.
Comment 30 Bernard Johnson 2006-03-27 12:41:28 EST
FYI Richard, I was looking at the Ubuntu 5.10 live CD and it has the exact same
behaviour (ie. requires unplugging and the plugging back in to get g-p-m to
display, and then once displayed, it can't detect the mouse charge).
Comment 31 Richard Hughes 2006-04-03 05:12:36 EDT
I've just added this to CVS HEAD:

2006-04-03  Richard Hughes  <richard@hughsie.com>
 * src/gpm-hal-monitor.c (watch_device_properties_modified): Don't switch round
the removed and added booleans, the order is "added" then "removed".
 * src/gpm-hal-monitor.c (watch_device_property_modified): Emit the signal for
modified *or* new keys, not just modified keys. This fixes the problem where HAL
is slow creating the keys, which can happen with the CSR mouse and keyboard
addon. This is a HAL bug, but there's no reason we can't make the mice work
after a little delay.

As the problem has just happened to me. I'll work on a HAL fix, but this patch
should mean that you get a few seconds of the "low mouse icon" and when HAL
sorts itself out, then the proper values can be processed.

Richard.
Comment 32 Bernard Johnson 2006-04-08 11:29:37 EDT
Will this patch (gpm) be pushed into FC5-updates or FC5-updates-testing soon?
Comment 33 Richard Hughes 2006-04-09 08:30:46 EDT
It will be part of 2.14.1, so when that is released (today or tomorrow) then yes.
Comment 34 Bernard Johnson 2006-04-12 10:55:03 EDT
Richard-

Is there a bugzilla id associated with the HAL bug referenced in Comment #31?
Comment 35 Richard Hughes 2006-04-15 05:21:54 EDT
Bernard, no, not yet. The issue is the Logitech mouse saying it's "busy" when we
do the initial "fillup" of values, and then we have to wait for the next polled
refresh. I'm really busy at the moment, but it's still on my TODO list.
Comment 36 Bernard Johnson 2006-11-18 16:18:34 EST
This appears to be resolved in FC6.
Comment 37 David Zeuthen 2007-04-02 19:35:25 EDT
Closing as this is fixed.

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