rc6+ regression - backlight reset to 0 on boot after 7c0ea45be4f114d85ee35caeead8e1660699c46f

rc6+ regression - backlight reset to 0 on boot after 7c0ea45be4f114d85ee35caeead8e1660699c46f

[Andrey Borzenkov]

[-- Attachment #1: Type: text/plain, Size: 702 bytes --]

Commit 7c0ea45be4f114d85ee35caeead8e1660699c46f registers ACPI backlight
even if _BQC method (query current backlight level) is missing. The effect is:

during initialization video.c:acpi_video_device_find_cap() calls backlight_update_status(). It tries to fetch actual level via acpi_video_get_brightness() - but as _BQC is missing it just returns current value
as stored in memory - i.e. zero, because it was never set. So effectively
backlight_update_status() reset brightness to minimal value == 0.

This happens on Toshiba Portege 4000. Verified by reverting commit on top of
rc8.

On a side note, it would be nice to fit backlight device into actual ACPI
device tree instead of /devices/virtual.

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: rc6+ regression - backlight reset to 0 on boot after 7c0ea45be4f114d85ee35caeead8e1660699c46f

[Zhao Yakui]

On Wed, 2008-04-02 at 22:53 +0400, Andrey Borzenkov wrote:
> Commit 7c0ea45be4f114d85ee35caeead8e1660699c46f registers ACPI backlight
> even if _BQC method (query current backlight level) is missing. The effect is:
> 
> during initialization video.c:acpi_video_device_find_cap() calls backlight_update_status(). It tries to fetch actual level via acpi_video_get_brightness() - but as _BQC is missing it just returns current value
> as stored in memory - i.e. zero, because it was never set. So effectively
> backlight_update_status() reset brightness to minimal value == 0.
> 
> This happens on Toshiba Portege 4000. Verified by reverting commit on top of
> rc8.
It seems that _BQC object is missing on the Toshiba Portege 4000. And
acpi video driver will continue to update the status of backlight even
when _BQC object is missing, which is inappropriate. 
Maybe it is more appropriate that OS doesn't update the status of
backlight in boot phase when _BQC object is missing.

Of course please attach the output of acpidump in kernel bugzilla.
http://bugzilla.kernel.org/show_bug.cgi?id=10387
> On a side note, it would be nice to fit backlight device into actual ACPI
> device tree instead of /devices/virtual.

Re: rc6+ regression - backlight reset to 0 on boot after 7c0ea45be4f114d85ee35caeead8e1660699c46f

[Andrey Borzenkov]

[-- Attachment #1: Type: text/plain, Size: 2683 bytes --]

On Thursday 03 April 2008, Zhao Yakui wrote:
> On Wed, 2008-04-02 at 22:53 +0400, Andrey Borzenkov wrote:
> > Commit 7c0ea45be4f114d85ee35caeead8e1660699c46f registers ACPI backlight
> > even if _BQC method (query current backlight level) is missing. The effect is:
> > 
> > during initialization video.c:acpi_video_device_find_cap() calls backlight_update_status(). It tries to fetch actual level via acpi_video_get_brightness() - but as _BQC is missing it just returns current value
> > as stored in memory - i.e. zero, because it was never set. So effectively
> > backlight_update_status() reset brightness to minimal value == 0.
> > 
> > This happens on Toshiba Portege 4000. Verified by reverting commit on top of
> > rc8.
> It seems that _BQC object is missing on the Toshiba Portege 4000. And
> acpi video driver will continue to update the status of backlight even
> when _BQC object is missing, which is inappropriate. 
> Maybe it is more appropriate that OS doesn't update the status of
> backlight in boot phase when _BQC object is missing.
> 
> Of course please attach the output of acpidump in kernel bugzilla.
> http://bugzilla.kernel.org/show_bug.cgi?id=10387

While patch in this bugzilla fixes this immediate regression, I still think
this commit should be reverted for 2.6.25 to discuss design a bit more.
Rationale:

- on systems without _BQC it makes sysfs attribute actual_brightness useless.
Semantic of this is to return *real* brightness as reported by hardware; but
this is noop without _BQC. So currently ACPI simply lies about its value.
If we are going support hardware without _BQC we probably should not define
->get_brightness at all allowing read of actual_brightness to fail.

- on at least some Toshibas we already have brightness control via HCI
(toshiba_acpi):

{pts/0}% ll /sys/class/backlight
итого 0
lrwxrwxrwx 1 root root 0 2008-04-03 22:20 acpi_video0 -> ../../devices/virtual/backlight/acpi_video0/
lrwxrwxrwx 1 root root 0 2008-04-03 22:19 toshiba -> ../../devices/virtual/backlight/toshiba/

both of them refer to exactly the same hardware which is rather confusing.
Something has to be done about it. This is even more confusing because ...

- ... on those old Toshibas ACPI brightness control is far inferior. It
effectively supports only three level of brightness while tochiba_acpi
supports seven of them. So there is no need to keep inferior implementation
if more advanced already exists and works just fine.

This has strong chances of confusing user space about which control is real.
So I think we really have to refrain from pushing this unless the issues above
are settled.

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: rc6+ regression - backlight reset to 0 on boot after 7c0ea45be4f114d85ee35caeead8e1660699c46f

[Thomas Renninger]

Hi,

On Thu, 2008-04-03 at 22:34 +0400, Andrey Borzenkov wrote:
> On Thursday 03 April 2008, Zhao Yakui wrote:
> > On Wed, 2008-04-02 at 22:53 +0400, Andrey Borzenkov wrote:
> > > Commit 7c0ea45be4f114d85ee35caeead8e1660699c46f registers ACPI backlight
> > > even if _BQC method (query current backlight level) is missing. The effect is:
> > > 
> > > during initialization video.c:acpi_video_device_find_cap() calls backlight_update_status(). It tries to fetch actual level via acpi_video_get_brightness() - but as _BQC is missing it just returns current value
> > > as stored in memory - i.e. zero, because it was never set. So effectively
> > > backlight_update_status() reset brightness to minimal value == 0.
> > > 
> > > This happens on Toshiba Portege 4000. Verified by reverting commit on top of
> > > rc8.
> > It seems that _BQC object is missing on the Toshiba Portege 4000. And
> > acpi video driver will continue to update the status of backlight even
> > when _BQC object is missing, which is inappropriate. 
> > Maybe it is more appropriate that OS doesn't update the status of
> > backlight in boot phase when _BQC object is missing.
> > 
> > Of course please attach the output of acpidump in kernel bugzilla.
> > http://bugzilla.kernel.org/show_bug.cgi?id=10387
> 
> While patch in this bugzilla fixes this immediate regression, I still think
> this commit should be reverted for 2.6.25 to discuss design a bit more.
> Rationale:
> 
> - on systems without _BQC it makes sysfs attribute actual_brightness useless.
> Semantic of this is to return *real* brightness as reported by hardware; but
> this is noop without _BQC. So currently ACPI simply lies about its value.
> If we are going support hardware without _BQC we probably should not define
> ->get_brightness at all allowing read of actual_brightness to fail.
> 
> - on at least some Toshibas we already have brightness control via HCI
> (toshiba_acpi):
> 
> {pts/0}% ll /sys/class/backlight
> итого 0
> lrwxrwxrwx 1 root root 0 2008-04-03 22:20 acpi_video0 -> ../../devices/virtual/backlight/acpi_video0/
> lrwxrwxrwx 1 root root 0 2008-04-03 22:19 toshiba -> ../../devices/virtual/backlight/toshiba/
> 
> both of them refer to exactly the same hardware which is rather confusing.
> Something has to be done about it. This is even more confusing because ...
> 
> - ... on those old Toshibas ACPI brightness control is far inferior. It
> effectively supports only three level of brightness while tochiba_acpi
> supports seven of them. So there is no need to keep inferior implementation
> if more advanced already exists and works just fine.
In general video acpi should be preferred because:
  - It's generic
  - It follows a definition/specification
  - It's the way current laptops will implement it -> Vista goes for it

Still it might be better, for some machines to use the vendor specific
way for several reasons, e.g.:
  - Bugs in the video driver (or elsewhere)
  - Linux misses some capabilities, which Vista already has
    e.g. ACPI communication with graphics drivers and more

> This has strong chances of confusing user space about which control is real.
> So I think we really have to refrain from pushing this unless the issues above
> are settled.

The way the backlight interface exposes data to userspace should be
generic for all backlight drivers? Only the values might change, but
userspace must be able to handle this gracefully.

Much more important is the confusion inside the kernel drivers.
Currently the driver which is loaded first, toshiba or video registers
for backlight control. This is more or less random when autoloading for
ACPI devices is active.

I try to come up with a solution to be able to tell the vendor specific
drivers whether they should register for backlight or display output
switching or when all necessary functions for the video driver are
available, then video should take control. The user should still be able
to override this via boot parameters and be able to force vendor
specific driver control.
It will be based on my first approach (posted on linux-acpi some time
ago):
Subject: "Untested proposal patch: Store video capabilities of BIOS
globally at ACPI parse time and export it"
I wanted to finish this up and post it yesterday, but it got a bit more
complex now as expected... It will still take some days until I find the
time for it and can show something, I just want to let you know that
work is done here.

Does above make sense?
Goal is a smooth transition from the vendor specific drivers (concerning
display and brightness switching) to the generic video driver with an
escape route for ACPI implementations which make trouble.

   Thomas

2.6.25-rc8-git2: Reported regressions from 2.6.24

[Rafael J. Wysocki]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 10809 bytes --]

[This time I'm going to do something new: I'll send a series of messages with
individual regression entries CCed to the people involved in handling them in
replies to this message.  Let's see how this works, fingers crossed.  Thx. R.]

This message contains a list of some regressions from 2.6.24, for which there
are no fixes in the mainline I know of.  If any of them have been fixed already,
please let me know.

If you know of any other unresolved regressions from 2.6.24, please let me know
either and I'll add them to the list.  Also, please let me know if any of the
entries below are invalid.


Listed regressions statistics:

  Date          Total  Pending  Unresolved
  ----------------------------------------
  2008-04-04      183       32          28
  2008-03-31      177       34          31
  2008-03-27      171       38          30
  2008-03-22      159       35          31
  2008-03-17      148       38          30
  2008-03-16      146       42          35
  2008-03-14      145       45          39
  2008-03-12      143       51          41
  2008-03-11      141       58          43
  2008-03-10      138       66          47
  2008-03-03      115       65          49
  2008-02-25       90       51          39
  2008-02-17       61       45          37


Unresolved regressions
----------------------

Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=10391
Subject		: 2.6.25-rc7/8: Another resume regression
Submitter	: Mark Lord <lkml@rtr.ca>
Date		: 2008-04-03 15:06 (1 days old)
References	: http://lkml.org/lkml/2008/4/3/283


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=10390
Subject		: Oops while reading /proc/ioports or /proc/iomem
Submitter	: Jan Kara <jack@suse.cz>
Date		: 2008-04-03 15:25 (1 days old)
References	: http://lkml.org/lkml/2008/4/3/149


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=10387
Subject		: rc6+ regression - backlight reset to 0 on boot after 7c0ea45be4f114d85ee35caeead8e1660699c46f
Submitter	: Andrey Borzenkov <arvidjaar@mail.ru>
Date		: 2008-04-02 22:53 (2 days old)
References	: http://lkml.org/lkml/2008/4/2/366


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=10384
Subject		: 2.6.25-rc6-git2: warn_on_slowpath for tcp_simple_retransmit
Submitter	: Alessandro Suardi <alessandro.suardi@gmail.com>
Date		: 2008-04-02 00:28 (2 days old)
References	: http://lkml.org/lkml/2008/4/1/408
Handled-By	: Ilpo Järvinen <ilpo.jarvinen@helsinki.fi>


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=10382
Subject		: 2.6.25-rc5.git4 regression PS/2 mouse not detected/working
Submitter	: Yanko Kaneti <yaneti@declera.com>
Date		: 2008-04-02 10:59 (2 days old)
References	: http://lkml.org/lkml/2008/4/2/210
Handled-By	: Dmitry Torokhov <dmitry.torokhov@gmail.com>
		  Balaji Rao <balajirrao@gmail.com>


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=10377
Subject		: Kernel freezes during boot when AC is unplugged
Submitter	: Roman Jarosz <kedgedev@centrum.cz>
Date		: 2008-04-01 16:23 (3 days old)


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=10369
Subject		: The never ending BEEEEP/__smp_call_function_mask with 2.6.25-rc7
Submitter	: Chr <chunkeey@web.de>
Date		: 2008-03-30 21:09 (5 days old)
References	: http://lkml.org/lkml/2008/3/30/87


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=10365
Subject		: usb-storage, error reading the last 8 sectors, regression in 2.6.25-rc7
Submitter	: Sergey Dolgov <solkaa@gmail.com>
Date		: 2008-03-30 11:49 (5 days old)
References	: http://lkml.org/lkml/2008/3/30/11


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=10349
Subject		: regression: am-utils stopped working in 2.6.25-rc*
Submitter	: Meelis Roos <mroos@linux.ee>
Date		: 2008-03-28 15:20 (7 days old)
References	: http://lkml.org/lkml/2008/3/28/174


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=10346
Subject		: Linux 2.6.25-rc6: WARNING: at net/ipv4/tcp_input.c:2510
Submitter	: Georgi Chorbadzhiyski <gf@unixsol.org>
Date		: 2008-03-27 17:29 (8 days old)
References	: http://lkml.org/lkml/2008/3/27/246


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=10344
Subject		: [2.6.25-rc6] possible regression: X server dying
Submitter	: Tilman Schmidt <tilman@imap.cc>
Date		: 2008-03-24 23:38 (11 days old)
References	: http://lkml.org/lkml/2008/3/24/260
Handled-By	: Dave Airlie <airlied@gmail.com>


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=10324
Subject		: kernel panic ip_route_input
Submitter	: Denys Fedoryshchenko <nuclearcat@nuclearcat.com>
Date		: 2008-03-25 12:48 (10 days old)


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=10323
Subject		: panic using bridging on linus kernel 2.6.25-rc6
Submitter	: Andy Gospodarek <andy@greyhouse.net>
Date		: 2008-03-25 11:40 (10 days old)


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=10320
Subject		: rt2x00 does not associate or give scan results
Submitter	: Marcus Better <marcus@better.se>
Date		: 2008-03-25 06:04 (10 days old)


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=10319
Subject		: 2.6.25-rc6 regression - hang on resume
Submitter	: Soeren Sonnenburg <kernel@nn7.de>
Date		: 2008-03-25 04:44 (10 days old)


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=10302
Subject		: 2.6.25-git regression with snd-hda-intel on Dell XPS M1330, no analog sound
Submitter	: Andre Tomt <andre@tomt.net>
Date		: 2008-03-21 20:03 (14 days old)
References	: http://lkml.org/lkml/2008/3/21/295
Handled-By	: Matthew Ranostay <mranostay@embeddedalley.com>


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=10300
Subject		: volume wheel does not work in 2.6.25-rc6
Submitter	: Romano Giannetti <romano.giannetti@gmail.com>
Date		: 2008-03-21 11:42 (14 days old)


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=10290
Subject		: [BUG] Linux 2.6.25-rc6 - kernel BUG at fs/mpage.c:476! on powerpc
Submitter	: Kamalesh Babulal <kamalesh@linux.vnet.ibm.com>
Date		: 2008-03-20 13:13 (15 days old)
References	: http://lkml.org/lkml/2008/3/20/39


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=10235
Subject		: 2.6.25-rc5: Blank Screen with Intel 945
Submitter	: Rafael J. Wysocki <rjw@sisk.pl>
Date		: 2008-03-12 12:02 (23 days old)
References	: http://lkml.org/lkml/2008/3/12/290
Handled-By	: Jesse Barnes <jbarnes@virtuousgeek.org>


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=10172
Subject		: kvm: INFO: inconsistent lock state
Submitter	: Zdenek Kabelac <zdenek.kabelac@gmail.com>
Date		: 2008-03-05 03:26 (30 days old)


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=10156
Subject		: KVM &amp; Qemu crashed with infinite recursive kernel loop in the guest
Submitter	: Zdenek Kabelac <zdenek.kabelac@gmail.com>
Date		: 2008-02-28 11:25 (36 days old)
References	: http://lkml.org/lkml/2008/2/28/106


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=10133
Subject		: INFO: possible circular locking in the resume
Submitter	: Zdenek Kabelac <zdenek.kabelac@gmail.com>
Date		: 2008-02-27 (37 days old)
References	: http://lkml.org/lkml/2008/2/26/479
Handled-By	: Gautham R Shenoy <ego@in.ibm.com>


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=10117
Subject		: 2.6.25-current-git hangs on boot (pci=nommconf helps)
Submitter	: Soeren Sonnenburg <kernel@nn7.de>
Date		: 2008-02-23 18:55 (41 days old)
References	: http://lkml.org/lkml/2008/2/23/263


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=10093
Subject		: 2.6.25-current-git hangs on boot unless CONFIG_CPU_IDLE=n - Apple
Submitter	: Soeren Sonnenburg <kernel@nn7.de>
Date		: 2008-02-23 18:55 (41 days old)
References	: http://lkml.org/lkml/2008/2/23/263
		  http://marc.info/?l=linux-acpi&amp;m=120387537018467&amp;w=4
Handled-By	: Pallipadi, Venkatesh <venkatesh.pallipadi@intel.com>


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=10082
Subject		: 2.6.25-rc2-git4 - Kernel oops while running kernbench and tbench on powerpc
Submitter	: Kamalesh Babulal <kamalesh@linux.vnet.ibm.com>
Date		: 2008-02-20 16:01 (44 days old)
References	: http://lkml.org/lkml/2008/2/20/218
		  http://lkml.org/lkml/2008/1/18/71


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=10067
Subject		: TUNER_TDA8290=y, VIDEO_DEV=n build error
Submitter	: Toralf Förster <toralf.foerster@gmx.de>
Date		: 2008-02-22 10:36 (42 days old)
References	: http://lkml.org/lkml/2008/2/19/262


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=9980
Subject		: 2.6.25-rc1 on Sun Ultra 40- HPET clocksource which causes it to hang
Submitter	: Jasper Bryant-Greene <jasper@unix.geek.nz>
Date		: 2008-02-13 12:25 (51 days old)
References	: http://lkml.org/lkml/2008/2/13/181


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=9978
Subject		: 2.6.25-rc1: volanoMark regression
Submitter	: Zhang, Yanmin <yanmin_zhang@linux.intel.com>
Date		: 2008-02-13 10:30 (51 days old)
References	: http://lkml.org/lkml/2008/2/13/128
Handled-By	: Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>


Regressionn with patches
------------------------

Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=10373
Subject		: slub compile error
Submitter	: Toralf Förster <toralf.foerster@gmx.de>
Date		: 2008-03-31 14:46 (4 days old)
References	: http://lkml.org/lkml/2008/3/31/120
Handled-By	: Christoph Lameter <clameter@sgi.com>
Patch		: http://lkml.org/lkml/2008/3/31/261


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=10366
Subject		: 2.6.25-rc7: warn_on_slowpath triggered
Submitter	: Bob Tracy <rct@frus.com>
Date		: 2008-03-29 17:29 (6 days old)
References	: http://lkml.org/lkml/2008/3/29/125
Handled-By	: Björn Steinbrink <B.Steinbrink@gmx.de>
Patch		: http://lkml.org/lkml/2008/3/30/245


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=10326
Subject		: inconsistent lock state in net_rx_action
Submitter	: Marcus Better <marcus@better.se>
Date		: 2008-03-25 13:21 (10 days old)
Patch		: http://bugzilla.kernel.org/show_bug.cgi?id=10326#c20


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=10153
Subject		: (regression) kernel/timeconst.h bugs with HZ=128
Submitter	: David Brownell <david-b@pacbell.net>
Date		: 2008-02-26 19:32 (38 days old)
References	: http://lkml.org/lkml/2008/2/26/294
Handled-By	: H. Peter Anvin <hpa@zytor.com>
Patch		: http://bugzilla.kernel.org/attachment.cgi?id=15114&amp;action=view
		  http://bugzilla.kernel.org/attachment.cgi?id=15115&amp;action=view


For details, please visit the bug entries and follow the links given in
references.

As you can see, there is a Bugzilla entry for each of the listed regressions.
There also is a Bugzilla entry used for tracking the regressions from 2.6.24,
unresolved as well as resolved, at:

http://bugzilla.kernel.org/show_bug.cgi?id=9832

Please let me know if there are any Bugzilla entries that should be added to
the list in there.

Thanks,
Rafael

rc6+ regression - backlight reset to 0 on boot after 7c0ea45be4f114d85ee35caeead8e1660699c46f

[Rafael J. Wysocki]

The following report is on the current list of known regressions
from 2.6.24.  Please verify if the issue is still present in the
mainline.


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=10387
Subject		: rc6+ regression - backlight reset to 0 on boot after 7c0ea45be4f114d85ee35caeead8e1660699c46f
Submitter	: Andrey Borzenkov <arvidjaar@mail.ru>
Date		: 2008-04-02 22:53 (2 days old)
References	: http://lkml.org/lkml/2008/4/2/366