Created attachment 101341 [details] lspci -vvv output The backlight controls worked fine with kernel version 3.8.12, and don't work with 3.9.2. /sys/class/backlight is now empty. I had this problem with 3.4.x too, and the "still use ACPI backlight control if _DOS doesn't exist" patch in bug 43168 fixed it for me then. In syslog, this line is there when I boot with 3.8.12, but not 3.9.2: nouveau [ DRM] ACPI backlight interface available, not registering our own
Created attachment 101351 [details] syslog excerpt showing 3.8.12 booting
Created attachment 101361 [details] syslog excerpt showing 3.9.2 booting
Created attachment 101371 [details] config for 3.8.12
Created attachment 101381 [details] config for 3.9.2
What's the output of $ ls /sys/class/backlight under v3.8? Please attach acpidump output. Thanks.
$ ls /sys/class/backlight/ acpi_video0
Created attachment 101391 [details] acpidump output, while running 3.8.12
Please run the following script and attach the output file at /tmp/acpi_devtree_dump.out. #!/bin/bash dumpfile=/tmp/acpi_devtree_dump.out rm -f $dumpfile touch $dumpfile for i in `find /sys/devices/LNXSYSTM:00 -name path`; do echo "$i -> `cat $i`" >> $dumpfile; done BTW, is the video module loaded? Thanks.
Yes, the video module is loaded.
Created attachment 101591 [details] acpi_devtree_dump.out
There are only 2 cleanup commits to the video driver in v3.9, so there must be something wrong elsewhere... Are kernel compiling an option to you? I can prepare a verbose debug patch, let's see where it bailed out, thanks.
Yeah, let's do that.
Which version of the kernel tree do you have? I can prepare a patch for that, 3.9+ is required.
I have 3.9.2, but I noticed that 3.9.3 is out now and I can get that one easily if you think it'd be better to debug that one.
No need, I think there is no change in this regard. I'll prepare a debug patch on top of v3.9.2, thanks.
Created attachment 102031 [details] Debug patch to see where video module bails out Apply on top of v3.9.2. Please also add acpi.debug_layer=0x10000000 acpi.debug_level=0x4 to kernel command line.
Created attachment 102121 [details] 3.9.2 booting with acpi_video_debug.patch Here's the result of the debug patch.
Created attachment 102451 [details] Clevo_P150HMx_Gentoo~amd64 data I experience the same issue with missing /sys/class/backlight/acpi_video0 symlink on my Sager-branded Clevo P150HMx notebook. All the data collected using dmegs, lspci and patched kernel sources is attached. I have completed git-bisect v3.9 v3.8.13 routine and found that the symlink is missing since commit 00c43b9682507dc622c03172fde1032e2a216e9d. The bisect log is also in attached archive. The distributive used is Gentoo testing ~amd64 branch, but I use proprietary Nvidia X11 driver. If I can help in any other way to solve this problem, please feel free to contact.
Thanks a lot for the bisection, Dmitry!
May 20 14:37:34 piedra kernel: [ 6.585307] video PNP0A08:00: acpi_video_bus_add: status=0x0 This is weird, it means the acpi device for PCI root bridge is driven by video module. I don't see how this can happen.
Can not reproduce this issue on a HP notebook, which has a dedicated graphics card under a PCI bridge.
Created attachment 102931 [details] Add debug message to see what's the problem Let's dig this further. Please apply this patch on top of v3.9.x and attach dmesg here, thanks.
Created attachment 102951 [details] dmesg from 3.9.2 booting with acpi_pci_root_debug.patch
Created attachment 102981 [details] dmesg booting v3.9.2 jn Clevo with acpi_pci_root_debug patch
Thanks for the information. The problem is root caused: there is a _ROM ACPI control method defined under the PCI root bridge, which made Linux think the PCI root bridge is a graphics card, since according to ACPI spec, only graphics controller device is supposed to expose a _ROM method. And the result is, the PCI root bridge device's private data is emptied by video module, making the acpi_get_pci_dev fail for the real graphics controller device. Previously, there is a acpi pci root bridge driver, it will take the acpi root bridge device so that when acpi video module is loaded, the acpi pci root node will not be tried to match against video module. Since the bisected commit, the acpi pci root bridge driver is removed, so the pci root bridge will now be tried to match against video module and as it has _ROM method, it will successfully matched and then the probe will fail, making subsequent acpi_get_pci_dev call fail. It's not clear to me what the clean fix is right now, stay tuned.
Created attachment 103041 [details] Do not probe acpi devices that already have driver_data Hi, Please give this patch a test, apply on top of v3.9.y, thanks.
(In reply to comment #26) > Created an attachment (id=103041) [details] > Do not probe acpi devices that already have driver_data > > Hi, > > Please give this patch a test, apply on top of v3.9.y, thanks. That fixes it for me, and I haven't noticed it causing any regressions yet. Yay! Thank you.
Yes, that fixes backlight regulation for me too, both on vanilla-3.9.2 and gentoo-sources-3.9.4. Thank you very much.
Hi, I just sent a patch to ACPI mailing list, there is a small change to address a comment from the maintainer, but I think it shouldn't affect the result. Anyway, if possible, please test it again, thanks. I should have added you to the cc list but I forgot when submitting, sorry for this, the submitted patch is here: https://patchwork.kernel.org/patch/2656921/
Created attachment 103431 [details] dmesg on gentoo-sources-3.9.4 with ACPI-do-not-match-devices-that-have-scan-handler.patch Now I observe a quite long set of kernel messages at boot after applying the ACPI-do-not-match-devices-that-have-scan-handler.patch over gentoo-sources-3.9.4.
Backlight regulation is fully functional with ACPI-do-not-match-devices-that-have-scan-handler.patch Sorry for not mentioning that in the comment #30.
Thanks. Do you use the binary NVidia graphics driver by chance? The warnings in comment #30 look like they are coming from it. I think we'll need to remove the WARN_ON() for now ...
Created attachment 103441 [details] ACPI / scan: do not match drivers against objects having scan handlers Can you please test this one just to be sure?
Created attachment 103481 [details] dmesg from 3.9.4 booting with the patch with the WARN_ON I use nouveau and I have pretty much the same warnings. And my backlight control works too. I'll try the new patch.
I tried the new patch. The warnings are gone.
(In reply to comment #35) > I tried the new patch. The warnings are gone. Thanks for the test!
(In reply to comment #32) > Thanks. > > Do you use the binary NVidia graphics driver by chance? > > The warnings in comment #30 look like they are coming from it. > > I think we'll need to remove the WARN_ON() for now ... Right... I misunderstand the match callback, I thought only devices that do not have driver yet will be attempted for a match, but obviously it's all the devices owned by the bus will be attempted for a match. It's the probe phase that will only probe for devices that do not have ->driver field set yet. So we'll have to remove the WARN_ON for now till we do not have any ACPI driver left, or there will be a lot of warnings generated by every ACPI device that already has a driver bound during the match phase on a new acpi driver load. BTW, does it make sense to match for devices that already have driver bound? It doesn't seem to be necessary to me.
(In reply to comment #37) > BTW, does it make sense to match for devices that already have driver bound? > It > doesn't seem to be necessary to me. I mean, in the driver core.
Yes, I do use binary nvidia driver. And yes, with WARN_ON removed messages at boot are gone too. Backlight is also functioning properly.
Unfortunately, the patch from comment #33 caused a boot regression to happen on an IA-64 machine and will have to be reverted.
(In reply to comment #25) > Thanks for the information. > > The problem is root caused: there is a _ROM ACPI control method defined under > the PCI root bridge, which made Linux think the PCI root bridge is a graphics > card, since according to ACPI spec, only graphics controller device is > supposed > to expose a _ROM method. And the result is, the PCI root bridge device's > private data is emptied by video module, making the acpi_get_pci_dev fail for > the real graphics controller device. I think we can fix this just by modifying the video driver.
Created attachment 103861 [details] ACPI / video: Do not bind to device objects with drivers or scan handlers I wonder if this patch fixes the problem?
Created attachment 103871 [details] ACPI / video: Do not bind to device objects with drivers or scan handlers Sorry, the previous version was broken (a typo). Please test this one instead.
(In reply to comment #41) > (In reply to comment #25) > > Thanks for the information. > > > > The problem is root caused: there is a _ROM ACPI control method defined > under > > the PCI root bridge, which made Linux think the PCI root bridge is a > graphics > > card, since according to ACPI spec, only graphics controller device is > supposed > > to expose a _ROM method. And the result is, the PCI root bridge device's > > private data is emptied by video module, making the acpi_get_pci_dev fail > for > > the real graphics controller device. > > I think we can fix this just by modifying the video driver. The ACPI bus' probe callback will empty the driver_data filed for any matched ACPI device if the driver's add callback failed, so solving it in video driver is too late. We will need to think about how to avoid adding the PNP id for video to the PCI root device.
Created attachment 103881 [details] ACPI / video: Do not bind to device objects with drivers or scan handlers Well, why don't we do this instead? I don't really think acpi_bus_driver_init() has to clear driver and driver_data, since they haven't been assigned yet.
(In reply to comment #45) > Created an attachment (id=103881) [details] > ACPI / video: Do not bind to device objects with drivers or scan handlers > > Well, why don't we do this instead? > > I don't really think acpi_bus_driver_init() has to clear driver and > driver_data, since they haven't been assigned yet. I agree. I think the patch is good, let's do that and wait for reporter's test. Thanks.
(In reply to comment #46) > (In reply to comment #45) > > Created an attachment (id=103881) [details] [details] > > ACPI / video: Do not bind to device objects with drivers or scan handlers > > > > Well, why don't we do this instead? > > > > I don't really think acpi_bus_driver_init() has to clear driver and > > driver_data, since they haven't been assigned yet. > > I agree. I think the patch is good, let's do that and wait for reporter's > test. > Thanks. Except that some ACPI driver assign driver_data early in their add callback, and when some error happened, they simply return without clearing that field. I'll need to take a look at the existing drivers, see if someone does that.
Oh crap, at least drivers/acpi/ac.c doesn't clear driver_data on error...
Well, I agree, but I'd say that would be a bug and it would be easy to fix. But please do check the existing drivers (although there's a number of them). Jason, Dmitry, can you please test the patch from comment #45 in the meantime?
Yes, looks like there are a number of them don't clear driver_data on error, but as you say, it's easy to fix :-)
(In reply to comment #48) > Oh crap, at least drivers/acpi/ac.c doesn't clear driver_data on error... Even so, I'm not sure what problems that may lead to, practically. Yes, that's a bug, yes it needs to be fixed, but will it actually cause things to break?
That may need to be checked on a per-driver basis, I'm not sure at the moment.
Honestly, I don't remember any ACPI driver checking if driver_data is NULL before attempting to overwrite it. Sadly. Which means that the change from comment #45 should be totally safe, but if it turns out to cause problems to happen, they should be easy to address. Let's check if it helps with the original issue first, though. :-)
(In reply to comment #53) > Honestly, I don't remember any ACPI driver checking if driver_data is NULL > before attempting to overwrite it. Sadly. No they don't :-) I can only see the notify handler would need to use driver_data, but since the notify is only installed after a successful add, so it wouldn't cause problem. > > Which means that the change from comment #45 should be totally safe, but if > it > turns out to cause problems to happen, they should be easy to address. > > Let's check if it helps with the original issue first, though. :-) Yes I agree.
I'm running 3.9.4 with the patch from comment #45. The backlight control works, and there are no obvious problems so far.
Thanks for the confirmation!
Created attachment 104051 [details] ACPI / video: Do not bind to device objects with a scan handler Jason, can you please verify if this slightly modified patch from comment #45 still works for you?
I have good news and bad news. The good news is the patch from comment #57 appears to work just as well as the one from comment #45. The bad news is that they both make this happen: [ 6.309685] video: probe of PNP0A08:00 failed with error -22
Created attachment 104121 [details] dmesg from 3.9.4 booting with the patch from comment #57 Here's my whole dmesg output in case I missed anything else.
Created attachment 104151 [details] dmesg on gentoo-sources-3.9.5 with acpi-video-fix.patch Tested patch from comment #45 on gentoo-3.9.4 - backlight control worked, but didn't look into dmesg. Tested patch from comment #47 on gentoo-3.9.5 - backlight control works, have same message in dmesg as Jason: [ 6.665498] video: probe of PNP0A08:00 failed with error -22 [ 6.665512] [Firmware Bug]: ACPI(MXM3) defines _DOD but not _DOS [ 6.665580] [Firmware Bug]: ACPI: No _BQC method, cannot determine initial brightness
(In reply to comment #58) > I have good news and bad news. The good news is the patch from comment #57 > appears to work just as well as the one from comment #45. The bad news is > that > they both make this happen: > > [ 6.309685] video: probe of PNP0A08:00 failed with error -22 That is a consequence of the way those patches work and is totally harmless (it actually is useful, because it shows that something weird is going on due to a BIOS bug). Thanks for testing!
Fixed by: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=8c9b7a7b2fc2750af418ddc28e707c42e78aa0bf