Created attachment 324536 [details] dmesg If I change the Backlight Brightness via echo 3 > /sys/class/backlight/acpi_video0/brightness The complete System reboots immediate. I know that this function was working with a 2.6 Kernel, may be 39 but I'am not sure if the revision nr is correct. I appended everything I could collect. It would be amazing if this feature would work again.
Created attachment 324538 [details] DSDT
Created attachment 324540 [details] emerge --info
Created attachment 324542 [details] installed_nvidia_drivers
Created attachment 324544 [details] installed_gentoo-sources
Created attachment 324546 [details] kernel .config
Created attachment 324548 [details] lsmod
Created attachment 324550 [details] sys_class_backlight
Created attachment 324552 [details] uname -a
What happens when you do: cat /sys/class/backlight/acpi_video0/brightness Do you get "Invalid Argument' error?
Hello gokturk No I don't get an invalid argument error. The display brightness level is displayed correctly: ####### CODE ######## rechner1 thomas # cat /sys/class/backlight/acpi_video0/brightness 7 ####### END ########
(In reply to comment #10) > Hello gokturk > > No I don't get an invalid argument error. > The display brightness level is displayed correctly: > > ####### CODE ######## > rechner1 thomas # cat /sys/class/backlight/acpi_video0/brightness > 7 > ####### END ######## Strange, I was hoping for a simple kernel panic caused by deferencing a NULL pointer, which causes the instant reboot behaviour, coupled with the fact that you have this in dmesg: [Firmware Bug]: ACPI: No _BQC method, cannot determine initial brightness
Hi, thank you for your relay. No I haven't seen any kernel panic. My be a panic occures, if I write to this "device" but then the System reboots. At a panic, the Keboard leds would flash and the system freezes or?
Should I do a Kernel upgrade or how do we go on to fix this Bug?
Yes, it is surely handy to see if this still occurs on the latest 3.6.1 test kernel which will ensure it hasn't been fixed in the last month; this is also a necessity if we decide to go upstream with the bug. Since this was working with older kernels you might also want to figure out the last kernel in which this worked as that could help us find the offending patch(set) that introduced this bug. For instance, try some of the older stable versions and see which one works. Finding the last version where this worked and first version where this didn't work are handy to figure out whether it's feasible to do a bisect to identify where this regression got introduced, if needed... --- --- --- While searching upstream, I also found a similar bug: https://bugzilla.kernel.org/show_bug.cgi?id=15895 This was referred to from Ubuntu as hanging the system: https://bugzilla.kernel.org/show_bug.cgi?id=15895#c28 What did you exactly mean with "reboot immediate"? What do you see happening on the screen? Does that correlate with the above bug? Does anything else correlate with the above bug? If you are running xorg-server, what version are you using?
Hello Thom, okay I will to a kernel upgrade and give you feedback as soon as I tested the Kernel. I will take the latest official Kernel. * sys-kernel/gentoo-sources Latest version available: 3.6.1 <<< This Version Latest version installed: 3.5.4 Size of files: 80,408 kB Homepage: http://dev.gentoo.org/~mpagano/genpatches Description: Full sources including the Gentoo patchset for the 3.6 kernel tree License: GPL-2 !deblob? ( freedist ) I'll think the last working kernel is hard to find, because it was a very early kernel. As I remember the first wich vanilla sources witch supported sky2 driver for my Netzwork card. I'll think the xorg-server has not mutch influence bcause the System reboots even without a started X if I write to the device. * x11-base/xorg-server Latest version available: 1.13.0 Latest version installed: 1.12.3 Size of files: 5,340 kB Homepage: http://xorg.freedesktop.org/ Description: X.Org X servers License: MIT The reboot occurs as it follows - I write a value with echo to the device. - The system's display is getting Black - The Bios is shown and the System is resetted -> doing a normal Boot.
Hi, today I had a bit time to test the linux-3.6.2-gentoo kernel. (Without X and nvidia Drivers). But the same behaviour occurs :-(
Okay, so this has been present for quite a while then. You might try another (few) time(s) with kernels from 3.0, 3.3 and 3.4. If you get to figure out the two consequent versions where this worked and where this became broke then that would be very good news as this would then be a regression and we could find the offending patch using a git bisect. It might otherwise be the case that it's no longer present in the portage tree or this has always been a bug, this is the case when 3.0.17-r2 is also broken for you. But BEFORE we do that, let's look in a different way at the problem. I've not thought about the other part of the equation previous time which is that this could also be a problem in the nvidia-drivers. So, please first try various older versions of the nvidia drivers to see whether this is present in older versions of the nvidia-drivers, as it might be that the problem lies there and not in the kernel. If you are convinced that none of the kernel or nvidia-drivers fix this I'll let some more experienced user look at this before elevating this, because as it currently stands I feel like there is insufficient information to attempt to fix this. Furthermore, since the kernel is tainted by the nvidia drivers we can't elevate this to the Linux kernel developers; but rather would have to elevate this to NVIDIA for them to take a look using the NVIDIA bug reporting tool, which might provide them more insight although a crash usually doesn't leave much debugging information behind...
Hi, Sorry for my late answer, but I was at a education center for a view weeks, so I hadn't the time to take care for this Bug :-( I played a bit around with nvidia drivers and kernles, but I couln't find a bugfree combination. I only know that it worked with a vanilla-source kernel with one of the first sky2 drivers. But I couln't find the correct one :-(
Hi, I've played a bit with Grub options and noticed the following. 1. Try Decrease Brightness via FN+BrightnesDown Key in Bios --> Works Booting to Gentoo --> While Kernel is starting the Brightens is increased from the Kernel. Writing to the Device to control the Backlight --> Reboot 2. Try Setting acpi=off --> Brightness level from Bios is taken without any modification. Device Node to control backlight is missing. Pressing FN+Brightness down --> Causes reboot only after the Kernel is loaded Currently I'am testing with Kernel 3.6.6 I'll think Nvidia driver doesn't have any influence because this causes also without the loaded nvidia module. Do you have any hints what I could try to resolve this annoying problem?
I've decided to look in your DSDT (emerge iasl && iasl -d DSDTFILE) to see what it tells us. >Method (_BCM, 1, NotSerialized) // _BCM: Brightness Control Method >{ > If (LGreaterEqual (OSYS, 0x07D6)) > { > Store (Arg0, BRTL) > SECS (0xA6) > } >} Heh, your brightness control method only works for operating systems >= 0x07D6. >If (_OSI ("Linux")) >{ > Store (0x03E8, \OSYS) > Store (0x03E8, OSYS) >} Linux appears to not suffice for that requirement, let's see what does. >If (_OSI ("Windows 2006")) >{ > Store (0x07D6, \OSYS) > Store (0x07D6, OSYS) >} If we look at the possible kernel parameters, we find two relevant parameters. >acpi_os_name= [HW,ACPI] Tell ACPI BIOS the name of the OS > Format: To spoof as Windows 98: ="Microsoft Windows" > >acpi_osi= [HW,ACPI] Modify list of supported OS interface strings > acpi_osi="string1" # add string1 -- only one string > acpi_osi="!string2" # remove built-in string2 > acpi_osi= # disable all strings So, to fix this, you'll want to disable Linux and let it spoof Windows 2006. Add acpi_osi="!Linux" acpi_os_name="Windows 2006" to your kernel parameters, which will not give Linux as a supported string anymore and will let it match Windows 2006 instead; which enables the ACPI code that allows you to brightness control. Of course, to make this ACPI work at all, you'll have to remove acpi=off again such that ACPI works and your brightness device will be present. If this does not work as a solution I can try to compile an altered DSDT instead for inclusion in your kernel.
Hello Mr. Wijsman thank you for your quick reply. I've tested this at first morning. Here is what I've noticed: - Edited Grub2 Bootline to acpi_osi="!Linux" acpi_os_name="Windows 2006" --> F10 (boot) - The Devices for controlling brightness are existing. - cat brightness --> Works gives 7 - echo 5 > brightness --> Immediate Reboot but the brightness was changed as I've seen in BIOS. So I booted again with the acpi options. At the boot the Kernel restored the old brightness. --> Confusing for me, why can the Kernel do this without a reboot? - I've checked then the FN+brightness Keys and noticed that the aren't working with this Parameters, but this wouldn't be a problem for me, if I could control then brightness via the device files. I've also checked the dmesg log and I've seen a view FIRMWARE Bug Messages. So I decided to attach this log. PS: Maybe it's useful that you know witch BIOS is working on this system. It is a Phoenix Bios.
Created attachment 329814 [details] Dmesg with ACPI Linux and Windows 2006
> - echo 5 > brightness --> Immediate Reboot but the brightness was changed as I've seen in BIOS. Correct, this means that it is using the DSDT code now and no longer doing nothing. > [ 0.008952] ACPI: Overriding _OS definition to 'Windows 2006' This is fine. > [ 0.058299] [Firmware Bug]: ACPI: BIOS _OSI(Linux) query ignored via cmdline This is also fine, as you made it ignore queries for the Linux OS such that you get the full ACPI functionality it provides to Windows. > [ 0.083048] [Firmware Bug]: ACPI: No _BQC method, cannot determine initial brightness This might be the cause as that is what could explain why the kernel changes the brightness back and you might not be able to change it without a reboot, there are two ways to fix this: 1. Recompiling the DSDT and attaching it to the kernel. 2. Patching the kernel to use an initial brightness. I'll see next week what I can do...
Created attachment 331134 [details] dsdt.diff Gone through it and applied changes to the DSDT, these can be seen in the attached diff. 1. Fixed invalid lengths to get the DSDT to compile again. 2. Added the initial brightness (_BQC) to the DSDT. 3. Removed check for right operating system in _BCM. 4. Made sure that it reports everywhere that you are using 0x07D6 (Last Windows). See my next comment for the compiled DSDT and how to apply it to the kernel.
Created attachment 331136 [details] out.hex Please put the attached file in "/usr/src/linux/include/". Then, enable the following options in your kernel config: > CONFIG_ACPI_CUSTOM_DSDT_FILE="out.hex" > CONFIG_ACPI_CUSTOM_DSDT=y Recompiling and rebooting should load the new DSDT file. Please let us know whether this fixes it for you. Note that this file taints your kernel, so if you ever experience another bug you will need to disable CONFIG_ACPI_CUSTOM_DSDT and then try to reproduce the bug before you report it. This gives the same effect as using a proprietary blob. This should serve as a temporary solution, I would suggest you to report this bug upstream as well to see whether a kernel fix could possibly be applied. When you do report it upstream, please leave us a link to that bug here.
Hello Thom, I've applied your out.hex to my kernel (newest one 3.6.8) and gave it a try. Unforunately the result is not as expected. ... The System is rebooting to. I made a short video to give you an impression. Is there a possibility to block the reboot, to get furher information form the System?
Created attachment 331218 [details] Video of the reboot
Hi Thom, now I had a look at the Samsung Update tool. But there where no updates. So I moved a bit deeper and searched for a BIOS Update for my Bios an I found one. My BIOS Version until now was: 08LA I found a update with this Name: WIN_R560_09LA.exe I've applied this Update to my BIOS and gave the Kernel a new try without any DSDT. And now I'am very happy. The backlight is controllable without any reboot. May be we should leave a hint on the Gentoo Page for Users witch have the same Problem. I would like to thank you for your help and for your time, witch you are invested in this Problem. If I had known that there was an Update, I had tried this first. But the Samsung Upgrade tool told my that there are no updates for my Hardware, so I didn't came across this thought to look explicit for a Bios Upgrade. So I'am happy and I'd like to say "Thank you" to everyone witch was involved to solve this Bug.
(In reply to comment #28) > Hi Thom, > > now I had a look at the Samsung Update tool. But there where no updates. > > So I moved a bit deeper and searched for a BIOS Update for my Bios an I > found one. > > My BIOS Version until now was: 08LA > I found a update with this Name: WIN_R560_09LA.exe > > I've applied this Update to my BIOS and gave the Kernel a new try without > any DSDT. And now I'am very happy. The backlight is controllable without any > reboot. > > May be we should leave a hint on the Gentoo Page for Users witch have the > same Problem. > > I would like to thank you for your help and for your time, witch you are > invested in this Problem. > > If I had known that there was an Update, I had tried this first. But the > Samsung Upgrade tool told my that there are no updates for my Hardware, so I > didn't came across this thought to look explicit for a Bios Upgrade. > > So I'am happy and I'd like to say "Thank you" to everyone witch was involved > to solve this Bug. Could you please provide me with the DSDT of the new BIOS? Perhaps do diff in advance to see whether the files differ. I just would like to see what changed between them to learn from it...
Created attachment 331244 [details] DSDT after BIOS Upgrade
Created attachment 331254 [details] DSDT_BIOS.diff Just a name change apparently, nothing special; weird, so it's probably not in the DSDT but instead at some deeper inaccessible level; thanks for reporting so others know how to upgrade their BIOS too... Glad you have found how to resolve it!
