Backlight brightness level not restored after reboot

Bug #1686268 reported by Domizio Demichelis
12
This bug affects 2 people
Affects Status Importance Assigned to Milestone
linux (Ubuntu)
Confirmed
Medium
Unassigned

Bug Description

I am not sure if this is the right place to report this, so feel free to move it elsewhere.

It looks like the systemd-backlight service (/lib/systemd/system/systemd-backlight@.service) does not restore the brightness level (although it saves it before shut-down).

However the following command does restore the saved brightness:

sudo /lib/systemd/systemd-backlight load backlight:intel_backlight

As a temporary solution to automate it at boot I am using the following line added to the root cron:

@reboot /lib/systemd/systemd-backlight load backlight:intel_backlight

- Ubuntu 4.10.0-20.22-generic 4.10.8
- Gnome 3.24

Please, let me know if you need more info. Thanks.
---
ApportVersion: 2.20.4-0ubuntu4
Architecture: amd64
AudioDevicesInUse:
 USER PID ACCESS COMMAND
 /dev/snd/controlC0: dd 1540 F.... pulseaudio
CurrentDesktop: GNOME
DistroRelease: Ubuntu 17.04
InstallationDate: Installed on 2017-04-12 (13 days ago)
InstallationMedia: Ubuntu-GNOME 17.04 "Zesty Zapus" - Release amd64 (20170411)
Lsusb:
 Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
 Bus 001 Device 002: ID 8087:0a2b Intel Corp.
 Bus 001 Device 003: ID 1bcf:2b95 Sunplus Innovation Technology Inc.
 Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
MachineType: Dell Inc. Precision 5520
Package: linux (not installed)
ProcFB: 0 inteldrmfb
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.10.0-20-generic.efi.signed root=/dev/mapper/nvme-ubuntu_gnome ro systemd.restore_state=1 quiet splash vt.handoff=7
ProcVersionSignature: Ubuntu 4.10.0-20.22-generic 4.10.8
RelatedPackageVersions:
 linux-restricted-modules-4.10.0-20-generic N/A
 linux-backports-modules-4.10.0-20-generic N/A
 linux-firmware 1.164
Tags: zesty
Uname: Linux 4.10.0-20-generic x86_64
UpgradeStatus: No upgrade log present (probably fresh install)
UserGroups: adm cdrom dip input lpadmin plugdev sambashare sudo
_MarkForUpload: True
dmi.bios.date: 03/29/2017
dmi.bios.vendor: Dell Inc.
dmi.bios.version: 1.2.4
dmi.board.name: 06X96V
dmi.board.vendor: Dell Inc.
dmi.board.version: A00
dmi.chassis.type: 10
dmi.chassis.vendor: Dell Inc.
dmi.modalias: dmi:bvnDellInc.:bvr1.2.4:bd03/29/2017:svnDellInc.:pnPrecision5520:pvr:rvnDellInc.:rn06X96V:rvrA00:cvnDellInc.:ct10:cvr:
dmi.product.name: Precision 5520
dmi.sys.vendor: Dell Inc.

Revision history for this message
Brad Figg (brad-figg) wrote : Missing required logs.

This bug is missing log files that will aid in diagnosing the problem. From a terminal window please run:

apport-collect 1686268

and then change the status of the bug to 'Confirmed'.

If, due to the nature of the issue you have encountered, you are unable to run this command, please add a comment stating that fact and change the bug status to 'Confirmed'.

This change has been made by an automated script, maintained by the Ubuntu Kernel Team.

Changed in linux (Ubuntu):
status: New → Incomplete
Revision history for this message
Domizio Demichelis (domizio) wrote : AlsaInfo.txt

apport information

tags: added: apport-collected zesty
description: updated
Revision history for this message
Domizio Demichelis (domizio) wrote : CRDA.txt

apport information

Revision history for this message
Domizio Demichelis (domizio) wrote : CurrentDmesg.txt

apport information

Revision history for this message
Domizio Demichelis (domizio) wrote : IwConfig.txt

apport information

Revision history for this message
Domizio Demichelis (domizio) wrote : JournalErrors.txt

apport information

Revision history for this message
Domizio Demichelis (domizio) wrote : Lspci.txt

apport information

Revision history for this message
Domizio Demichelis (domizio) wrote : ProcCpuinfo.txt

apport information

Revision history for this message
Domizio Demichelis (domizio) wrote : ProcCpuinfoMinimal.txt

apport information

Changed in linux (Ubuntu):
status: Incomplete → Confirmed
Revision history for this message
Joseph Salisbury (jsalisbury) wrote :

Did this issue start happening after an update/upgrade? Was there a prior kernel version where you were not having this particular problem?

Would it be possible for you to test the latest upstream kernel? Refer to https://wiki.ubuntu.com/KernelMainlineBuilds . Please test the latest v4.11 kernel[0].

If this bug is fixed in the mainline kernel, please add the following tag 'kernel-fixed-upstream'.

If the mainline kernel does not fix this bug, please add the tag: 'kernel-bug-exists-upstream'.

Once testing of the upstream kernel is complete, please mark this bug as "Confirmed".

Thanks in advance.

[0] http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.11-rc8

Changed in linux (Ubuntu):
importance: Undecided → Medium
status: Confirmed → Incomplete
Revision history for this message
Domizio Demichelis (domizio) wrote :

Apparently, it was working with 16.10 (4.8.0-46), although I had a different setup (GNOME desktop added on an official UBUNTU installation from DELL).

The problem started with Ubuntu Gnome 17.04 (4.10.0-19) and persisted with 4.10.0-20.

About testing the upstream kernel, I am willing to try. I just need a few info/confirmations:

- Should I install the "all" image? (http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.11-rc8/linux-headers-4.11.0-041100rc8_4.11.0-041100rc8.201704232131_all.deb)

- I suppose that the best way to test it and restore the original setup would be using a LVM snapshot, merging it back when finished, right?

- What about grub? Will the new kernel be available as an entry in the grub menu, or should I do anything manually?

Thanks

Revision history for this message
Kai-Heng Feng (kaihengfeng) wrote :

What's the output of `systemctl status systemd-backlight@intel_backlight.service`?

Revision history for this message
Domizio Demichelis (domizio) wrote :

The exact command you wrote:

$ systemctl status systemd-backlight@intel_backlight.service
systemd-backlight@intel_backlight.service - Load/Save Screen Backlight Brightness of intel_backlight
   Loaded: loaded (/lib/systemd/system/systemd-backlight@.service; static; vendor preset: enabled)
   Active: inactive (dead)
     Docs: man:systemd-backlight@.service(8)

However the following one (with an added "backlight:") gives a different answer:

$ systemctl status systemd-backlight@backlight:intel_backlight.service
systemd-backlight@backlight:intel_backlight.service - Load/Save Screen Backlight Brightness of backlight:intel_backlight
   Loaded: loaded (/lib/systemd/system/systemd-backlight@.service; static; vendor preset: enabled)
   Active: active (exited) since Mon 2017-05-01 09:50:53 +07; 9min ago
     Docs: man:systemd-backlight@.service(8)
 Main PID: 446 (code=exited, status=0/SUCCESS)

May 01 09:50:52 x1 systemd[1]: Starting Load/Save Screen Backlight Brightness of backlight:intel_backlight...
May 01 09:50:53 x1 systemd[1]: Started Load/Save Screen Backlight Brightness of backlight:intel_backlight.

Revision history for this message
Domizio Demichelis (domizio) wrote :

I forgot to say that the above output comes after commenting out the @reboot cron entry workaround and restarting, so it is exactly what it does without any workaround.

Revision history for this message
Kai-Heng Feng (kaihengfeng) wrote :

So is the value of '/sys/class/backlight/intel_backlight/brightness' the stored/restored value?

Revision history for this message
Domizio Demichelis (domizio) wrote :

Yes, that value is saved as soon as I change the brightness. After reboot the brightness value is not restored (indeed the back-light is actually full brightness), although the value in that file is still the saved one.

However running the `sudo /lib/systemd/systemd-backlight load backlight:intel_backlight` restores the brightness to the exact value in the file.

Revision history for this message
Kai-Heng Feng (kaihengfeng) wrote :

Ok, I think I should ask more explicitly:

1. What's the value of '/sys/class/backlight/intel_backlight/brightness' before reboot?
2. What's the value after reboot?
3. What do you mean "that value is saved as soon as I change the brightness"?

Revision history for this message
Domizio Demichelis (domizio) wrote :

1. The real value of the current brightness (e.g. 75)
2. As I said: after the reboot that value is the same (e.g. 75)
3. As soon as I move the slicer in the Gnome Shell Panel, the new value gets saved into the file (e.g. 150)

To explain you better: it looks like the value in that file is kept in sync with the actual brightness on the screen, i.e. as soon you change the brightness with the slider or with the hardware key its value gets stored in the file. A reboot doesn't change the value in the file (i.e. it still is the same as before the reboot), but it looks like the service doesn't restore the brightness by using the value (i.e. the brightness of the screen is full brightness) and you have to restore it manually or with an @reboot entry.

Revision history for this message
Kai-Heng Feng (kaihengfeng) wrote :

Hmm, I think I am still not pretty sure I fully understand the situation here.

So, right after reboot,

What's the value of `cat /sys/class/backlight/intel_backlight/brightness`?

And the output of `grep . /var/lib/systemd/backlight/*`?

Revision history for this message
Domizio Demichelis (domizio) wrote :

$ cat /sys/class/backlight/intel_backlight/brightness
451

$ grep . /var/lib/systemd/backlight/*
75

Revision history for this message
Kai-Heng Feng (kaihengfeng) wrote :

Seems like there are two possibility:
1. systemd-backlight didn't restore the value successfully.
2. It did, but something else changed the value.

Let's try this:
$ sudo systemctl set-default multi-user.target

Reboot and check if this happens.
Use
$ sudo systemctl set-default graphical.target
To change target back to normal desktop environment.

Revision history for this message
Domizio Demichelis (domizio) wrote :

Setting the multi-user.target causes a timeout error at boot, complaining that it cannot connet lumetad (?).

BTW, as another possibly useful detail. After reboot the cat /sys/class/backlight/intel_backlight/brightness and the grep . /var/lib/systemd/backlight/* give both 1500 (the maximum). AS soon s I change the brightness slider the cat /sys/class/backlight/intel_backlight/brightness reflects the new value (e.g. 450), while the grep . /var/lib/systemd/backlight/* still shows 1500.

HTH

Revision history for this message
Domizio Demichelis (domizio) wrote :

Just discovered that the value returned by grep . /var/lib/systemd/backlight/* is ALWAYS the value of cat /sys/class/backlight/intel_backlight/brightness BEFORE reboot.

So to summarize:

1. the grep . /var/lib/systemd/backlight/* shows the value of the brightness that was right before the last reboot. That doesn't change real-time when I change the brightness with the slider. The value appear to get stored right before the reboot.

2. the cat /sys/class/backlight/intel_backlight/brightness shows whatever is the current value of the brigtness and is stored/updated real-time, as soon as I change it with the slider or the hardware key

=== example ===

# brigtness at maxixmum level (1500)

<reboot>

$ cat /sys/class/backlight/intel_backlight/brightness
1500
$ grep . /var/lib/systemd/backlight/*
1500

<reducing brightness with the slider>

$ cat /sys/class/backlight/intel_backlight/brightness
450
$ grep . /var/lib/systemd/backlight/*
1500

<reboot>

$ cat /sys/class/backlight/intel_backlight/brightness
1500
$ grep . /var/lib/systemd/backlight/*
450

<reducing brightness with the slider>
$ cat /sys/class/backlight/intel_backlight/brightness
300
$ grep . /var/lib/systemd/backlight/*
450

<reboot>

$ cat /sys/class/backlight/intel_backlight/brightness
1500
$ grep . /var/lib/systemd/backlight/*
300

<reducing brightness with the slider>
$ cat /sys/class/backlight/intel_backlight/brightness
600
$ grep . /var/lib/systemd/backlight/*
300

Revision history for this message
Kai-Heng Feng (kaihengfeng) wrote :

> 1. the grep . /var/lib/systemd/backlight/* shows the value of the brightness that was right before the last reboot. That doesn't change real-time when I change the brightness with the slider. The value appear to get stored right before the reboot.

Yes, the service will restore brightness value at boot, and store brightness value at shutdown stage. It does not save the brightness at realtime.

> 2. the cat /sys/class/backlight/intel_backlight/brightness shows whatever is the current value of the brigtness and is stored/updated real-time, as soon as I change it with the slider or the hardware key

Yes. that's correct.

Systemd saves the brightness before shutdown, then restore it after boot.
It doesn't save brightness in real-time.

So, wrt comment #20, did you change brightness in anyway?

Revision history for this message
Domizio Demichelis (domizio) wrote :

About the reading in #20, it was the situation at that given time, not after a reboot. Since the /sys/class/backlight/intel_backlight/brightness was not 1500 (full brightness after reboot) I obviously changed it.

The dynamic of what happens is shown in the "example" section of #23. After every reboot, the brightness is always 1500, regardless what it is stored in /sys/class/backlight/intel_backlight/brightness, and I have to manually change it every time.

It looks like the command /lib/systemd/systemd-backlight load backlight:intel_backlight works, but it is just not called automatically at reboot.

Revision history for this message
Kai-Heng Feng (kaihengfeng) wrote :

I now have Precision 5520 and I can reproduce the issue. I'll take a deeper look on this issue.

Changed in linux (Ubuntu):
assignee: nobody → Kai-Heng Feng (kaihengfeng)
status: Incomplete → In Progress
Revision history for this message
Kai-Heng Feng (kaihengfeng) wrote :

The issue's gone after I changed brightness in BIOS video tab.
So I cannot dig this anymore =(

But try if this solves your issue.

Changed in linux (Ubuntu):
status: In Progress → Confirmed
Revision history for this message
Kai-Heng Feng (kaihengfeng) wrote :

Also, try to upgrade to the latest BIOS, that may help:
$ sudo fwupdmgr refresh
$ sudo fwupdmgr update
$ sudo reboot

Revision history for this message
Domizio Demichelis (domizio) wrote :

Changing the brightness in the BIOS video tab got rid of the problem! Great!!!

I am glad that you stumble upon that only AFTER you could confirm that the problem existed. :)

Thank you for your time and assistance!

Revision history for this message
Kai-Heng Feng (kaihengfeng) wrote :

Mario, can you take a look?

A quick summary:
1. Boot the system.
2. The value systemd-backlight read from intel backlight is 0.
3. systemd-backlight restore the value it from /var/lib/systemd/backlight.
4. Brightness value being overwritten to maximum value, 1500.

After I changed the brightness slider in BIOS:
1. Boot the system.
2. The value systemd-backlight read from intel backlight is a sane value, not 0 anymore.
3. systemd-backlight restore the value it from /var/lib/systemd/backlight.
4. profit.

Restore defaults in BIOS cannot revert the behavior back to the bad one.

Revision history for this message
Mario Limonciello (superm1) wrote : Re: [Bug 1686268] Re: Backlight brightness level not restored after reboot

That sounds a little crazy that it can't reproduce in my opinion. When it
"did" reproduce was the brightness at one of the extremes? Eg full high on
shutdown or full low on shutdown?

On Thu, May 25, 2017, 03:21 Kai-Heng Feng <email address hidden>
wrote:

> Mario, can you take a look?
>
> A quick summary:
> 1. Boot the system.
> 2. The value systemd-backlight read from intel backlight is 0.
> 3. systemd-backlight restore the value it from /var/lib/systemd/backlight.
> 4. Brightness value being overwritten to maximum value, 1500.
>
> After I changed the brightness slider in BIOS:
> 1. Boot the system.
> 2. The value systemd-backlight read from intel backlight is a sane value,
> not 0 anymore.
> 3. systemd-backlight restore the value it from /var/lib/systemd/backlight.
> 4. profit.
>
> Restore defaults in BIOS cannot revert the behavior back to the bad one.
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1686268
>
> Title:
> Backlight brightness level not restored after reboot
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1686268/+subscriptions
>

Revision history for this message
Domizio Demichelis (domizio) wrote :
Download full text (4.3 KiB)

Mine was about half in the battery slider and 0 in the AC slider.

On Fri, May 26, 2017, 12:11 PM Mario Limonciello <email address hidden> wrote:

> That sounds a little crazy that it can't reproduce in my opinion. When it
> "did" reproduce was the brightness at one of the extremes? Eg full high on
> shutdown or full low on shutdown?
>
> On Thu, May 25, 2017, 03:21 Kai-Heng Feng <email address hidden>
> wrote:
>
> > Mario, can you take a look?
> >
> > A quick summary:
> > 1. Boot the system.
> > 2. The value systemd-backlight read from intel backlight is 0.
> > 3. systemd-backlight restore the value it from
> /var/lib/systemd/backlight.
> > 4. Brightness value being overwritten to maximum value, 1500.
> >
> > After I changed the brightness slider in BIOS:
> > 1. Boot the system.
> > 2. The value systemd-backlight read from intel backlight is a sane value,
> > not 0 anymore.
> > 3. systemd-backlight restore the value it from
> /var/lib/systemd/backlight.
> > 4. profit.
> >
> > Restore defaults in BIOS cannot revert the behavior back to the bad one.
> >
> > --
> > You received this bug notification because you are subscribed to the bug
> > report.
> > https://bugs.launchpad.net/bugs/1686268
> >
> > Title:
> > Backlight brightness level not restored after reboot
> >
> > To manage notifications about this bug go to:
> >
> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1686268/+subscriptions
> >
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1686268
>
> Title:
> Backlight brightness level not restored after reboot
>
> Status in linux package in Ubuntu:
> Confirmed
>
> Bug description:
> I am not sure if this is the right place to report this, so feel free
> to move it elsewhere.
>
> It looks like the systemd-backlight service (/lib/systemd/system
> /systemd-backlight@.service) does not restore the brightness level
> (although it saves it before shut-down).
>
> However the following command does restore the saved brightness:
>
> sudo /lib/systemd/systemd-backlight load backlight:intel_backlight
>
> As a temporary solution to automate it at boot I am using the
> following line added to the root cron:
>
> @reboot /lib/systemd/systemd-backlight load backlight:intel_backlight
>
> - Ubuntu 4.10.0-20.22-generic 4.10.8
> - Gnome 3.24
>
> Please, let me know if you need more info. Thanks.
> ---
> ApportVersion: 2.20.4-0ubuntu4
> Architecture: amd64
> AudioDevicesInUse:
> USER PID ACCESS COMMAND
> /dev/snd/controlC0: dd 1540 F.... pulseaudio
> CurrentDesktop: GNOME
> DistroRelease: Ubuntu 17.04
> InstallationDate: Installed on 2017-04-12 (13 days ago)
> InstallationMedia: Ubuntu-GNOME 17.04 "Zesty Zapus" - Release amd64
> (20170411)
> Lsusb:
> Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
> Bus 001 Device 002: ID 8087:0a2b Intel Corp.
> Bus 001 Device 003: ID 1bcf:2b95 Sunplus Innovation Technology Inc.
> Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
> MachineType: Dell Inc. Precision 5520
> Package: linux (not installed)
> ProcFB: 0 inteldrmfb
> ...

Read more...

Revision history for this message
Kai-Heng Feng (kaihengfeng) wrote :

It can't be reproduced once you changed the brightness via slider in BIOS.

It should be reproduceable if the brightness was *never* touched in BIOS.

Once the brightness is changed in BIOS, the issue can no longer be reproduced regardless the brightness value.

Revision history for this message
Mario Limonciello (superm1) wrote :

But so we're talking about the slider in the bios that adjusts keyboard
backlight right? That's not tied to display backlight.

On Fri, May 26, 2017, 00:31 Kai-Heng Feng <email address hidden>
wrote:

> It can't be reproduced once you changed the brightness via slider in
> BIOS.
>
> It should be reproduceable if the brightness was *never* touched in
> BIOS.
>
> Once the brightness is changed in BIOS, the issue can no longer be
> reproduced regardless the brightness value.
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1686268
>
> Title:
> Backlight brightness level not restored after reboot
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1686268/+subscriptions
>

Revision history for this message
Kai-Heng Feng (kaihengfeng) wrote :
Download full text (3.9 KiB)

On Fri, May 26, 2017 at 19:55 Mario Limonciello <email address hidden> wrote:

> But so we're talking about the slider in the bios that adjusts keyboard
> backlight right? That's not tied to display backlight.

> No, the "Video" tab in BIOS has two sliders, one is for AC and another one
is for battery. Both of them are for display brightness.

> On Fri, May 26, 2017, 00:31 Kai-Heng Feng <email address hidden>
> wrote:
>
> > It can't be reproduced once you changed the brightness via slider in
> > BIOS.
> >
> > It should be reproduceable if the brightness was *never* touched in
> > BIOS.
> >
> > Once the brightness is changed in BIOS, the issue can no longer be
> > reproduced regardless the brightness value.
> >
> > --
> > You received this bug notification because you are subscribed to the bug
> > report.
> > https://bugs.launchpad.net/bugs/1686268
> >
> > Title:
> > Backlight brightness level not restored after reboot
> >
> > To manage notifications about this bug go to:
> >
> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1686268/+subscriptions
> >
>
> --
> You received this bug notification because you are a bug assignee.
> https://bugs.launchpad.net/bugs/1686268
>
> Title:
> Backlight brightness level not restored after reboot
>
> Status in linux package in Ubuntu:
> Confirmed
>
> Bug description:
> I am not sure if this is the right place to report this, so feel free
> to move it elsewhere.
>
> It looks like the systemd-backlight service (/lib/systemd/system
> /systemd-backlight@.service) does not restore the brightness level
> (although it saves it before shut-down).
>
> However the following command does restore the saved brightness:
>
> sudo /lib/systemd/systemd-backlight load backlight:intel_backlight
>
> As a temporary solution to automate it at boot I am using the
> following line added to the root cron:
>
> @reboot /lib/systemd/systemd-backlight load backlight:intel_backlight
>
> - Ubuntu 4.10.0-20.22-generic 4.10.8
> - Gnome 3.24
>
> Please, let me know if you need more info. Thanks.
> ---
> ApportVersion: 2.20.4-0ubuntu4
> Architecture: amd64
> AudioDevicesInUse:
> USER PID ACCESS COMMAND
> /dev/snd/controlC0: dd 1540 F.... pulseaudio
> CurrentDesktop: GNOME
> DistroRelease: Ubuntu 17.04
> InstallationDate: Installed on 2017-04-12 (13 days ago)
> InstallationMedia: Ubuntu-GNOME 17.04 "Zesty Zapus" - Release amd64
> (20170411)
> Lsusb:
> Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
> Bus 001 Device 002: ID 8087:0a2b Intel Corp.
> Bus 001 Device 003: ID 1bcf:2b95 Sunplus Innovation Technology Inc.
> Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
> MachineType: Dell Inc. Precision 5520
> Package: linux (not installed)
> ProcFB: 0 inteldrmfb
> ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.10.0-20-generic.efi.signed
> root=/dev/mapper/nvme-ubuntu_gnome ro systemd.restore_state=1 quiet splash
> vt.handoff=7
> ProcVersionSignature: Ubuntu 4.10.0-20.22-generic 4.10.8
> RelatedPackageVersions:
> linux-restricted-modules-4.10.0-20-generic N/A
> linux-backports-modules-4.10.0-20-generic N/A
>...

Read more...

Changed in linux (Ubuntu):
assignee: Kai-Heng Feng (kaihengfeng) → nobody
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

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