Bug 9915
Description
Sebastian Smolorz
2008-02-08 04:16:06 UTC
Created attachment 14749 [details]
acpidump output on Panasonic Toughbook CF-52
Multiple issues in the dmesg above beg several questions...
> Latest working kernel version: unknown
> Earliest failing kernel version: 2.6.23.12
Has any version of Linux ever booted on this laptop in ACPI mode?
If so, what is the latest version you know of?
Are the dmesg above from unmodified 2.6.24,
or from 2.6.24-git (pre 2.6.25-rc1)?
Kernel command line: root=/dev/sda6 vga=0x318 acpi_osi=Linux
Kernel command line: root=/dev/sda6 console=ttyS0,115200
Does this laptop really have a serial console?
if you boot with these parameters several times,
does it succeed/fail the same way each time?
Did acpi_osi=Linux make a difference (all by itself)?
Any difference with CONFIG_PREEMPT=n?
Reviewing the DSDT for use of OSI(Linux), I don't see that Panasonic has any specific support for Linux. Rather, OSI(Linux)'s main effect seems to be to run the DSDT as if Windows NT were running. In particular, there is a bunch of USB code that gets disabled because OSI(Linux) disables the Vista-validated path through the BIOS. However, I don't fully follow the save/restore to INFO mechanism -- it could possibly have some implications on SMM code. I'll be surprised if acpi_osi=Linux behaves differently from acpi_osi=!Linux WRT. the boot problems reported here. However, I wouldn't be surprised to see a differences in suspend/resume function, or USB function. Name (OSID, 0x00) # OSID is not referenced, except by the CKOS method itself Method (CKOS, 0, NotSerialized) { If (OSID) { Return (OSID) } If (CondRefOf (\_OSI, Local0)) { If (\_OSI ("Linux")) { Store (0x10, OSID) # OSI(Linux) sets OSID to x10 } Else { If (\_OSI ("Windows 2006")) { Store (0x83, OSID) } Else { Store (0x82, OSID) } } } Else { If (LEqual (SCMP (\_OS, "Microsoft Windows NT"), Zero)) { Store (0x81, OSID) } Else { If (LEqual (SCMP (\_OS, "Microsoft Windows"), Zero)) { Store (0x01, OSID) } Else { If (LEqual (SCMP (\_OS, "Microsoft WindowsME: Millennium Edition"), Zero)) { Store (0x02, OSID) } Else { Store (0xFF, OSID) } } } } Return (OSID) } ... Scope (\_SB) { Method (_INI, 0, NotSerialized) { If (DTSE) { \_SB.PSRV (0xC9, 0x04, 0x00, 0x00, 0x00) } Store (0x07D0, OSYS) If (CondRefOf (\_OSI, Local0)) { If (\_OSI ("Linux")) { Store (0x03E8, OSYS) } # OSYS is immediately over-written, so this OSI(Linux) is a NOP If (\_OSI ("Windows 2001")) { Store (0x07D1, OSYS) } If (\_OSI ("Windows 2001 SP1")) { Store (0x07D1, OSYS) } If (\_OSI ("Windows 2001 SP2")) { Store (0x07D2, OSYS) } If (\_OSI ("Windows 2006")) { Store (0x07D6, OSYS) } If (LAnd (MPEN, LEqual (OSYS, 0x07D1))) { \_SB.PSRV (0xC9, 0x03, One, One, 0x00) } } \_SB.PCI0.GFX0.INIG () } } # CKOS is used in several places Method (_WAK, 1, NotSerialized) { \_SB.PSRV (0x92, 0x03, 0x01, \CKOS (), 0x00) If (LEqual (Arg0, 0x03)) { \_SB.BAY3 () } ... Method (PSRV, 5, Serialized) { Acquire (PSMX, 0xFFFF) If (Arg2) { # Arg3 is the output from CKOS() Store (Arg3, INFO) } Store (Arg1, DID) Store (Arg0, BCMD) Store (0x00, SMIC) If (LEqual (Arg4, 0x00)) { Store (Zero, Local0) } Else { If (LEqual (Arg4, 0x01)) { Store (INF, Local0) } Else { If (LEqual (Arg4, 0x03)) { Store (INFD, Local0) } Else { If (LEqual (Arg4, 0x04)) { Store (INFP, Local0) } Else { Store (INFO, Local0) } } } } Release (PSMX) Return (Local0) } OperationRegion (SMI1, SystemMemory, 0x3F6D0D4D, 0x00000200) Field (SMI1, AnyAcc, NoLock, Preserve) { BCMD, 8, DID, 32, INFO, 4056 } # PSRV is widely called, and sometimes its return value is used. Device (PCI0) { Method (_INI, 0, NotSerialized) { \_SB.PSRV (0x92, 0x03, 0x01, \CKOS (), 0x00) GINI () AINI () \_SB.PSRV (0xB8, 0x01, 0x00, 0x00, 0x00) } # a bunch of USB code depends on CKOS == x83 (Vista) If (LEqual (\CKOS (), 0x83)) { Name (USP1, Zero) Name (USP2, Zero) Name (USPE, Zero) Name (\_SB.PCI0.USB1._PRW, Package (0x02) { 0x03, 0x03 }) Method (\_SB.PCI0.USB1._PSW, 1, NotSerialized) { Store (Arg0, USP1) \_SB.ECPF (0x021A, 0x03, LOr (USPE, USP1)) If (Arg0) { Store (0x03, \_SB.PCI0.USB1.RSEN) } Else { Store (Zero, \_SB.PCI0.USB1.RSEN) } } Name (\_SB.PCI0.USB2._PRW, Package (0x02) { 0x04, 0x03 }) Method (\_SB.PCI0.USB2._PSW, 1, NotSerialized) { Store (Arg0, USP2) \_SB.ECPF (0x021A, 0x0C, LOr (USPE, USP2)) If (Arg0) { Store (0x03, \_SB.PCI0.USB2.RSEN) } Else { Store (Zero, \_SB.PCI0.USB2.RSEN) } } Name (\_SB.PCI0.EHCI._PRW, Package (0x02) { 0x0D, 0x03 }) Method (\_SB.PCI0.EHCI._PSW, 1, NotSerialized) { Store (Arg0, USPE) \_SB.ECPF (0x021A, 0x03, LOr (USPE, USP1)) \_SB.ECPF (0x021A, 0x0C, LOr (USPE, USP2)) } Scope (\_GPE) { Method (_L03, 0, NotSerialized) { Notify (\_SB.PCI0.USB1, 0x02) } Method (_L04, 0, NotSerialized) { Notify (\_SB.PCI0.USB2, 0x02) } } } (In reply to comment #2) > Has any version of Linux ever booted on this laptop in ACPI mode? > If so, what is the latest version you know of? The first kernel I tried on this laptop was version 2.6.23.12. I am not aware of any kernel version that booted in ACPI mode successfully and reliably. If you have any assumptions that a particular version could work please let me know so I can try it out. > Are the dmesg above from unmodified 2.6.24, > or from 2.6.24-git (pre 2.6.25-rc1)? The first dmesg is from the linux-acpi-2.6 repository, test branch, last commit from February 2nd. The second dmesg is from vanilla 2.6.24. > Kernel command line: root=/dev/sda6 vga=0x318 acpi_osi=Linux > Kernel command line: root=/dev/sda6 console=ttyS0,115200 > > Does this laptop really have a serial console? I don't log in via serial console but I use the serial output to save the dmesg. > if you boot with these parameters several times, > does it succeed/fail the same way each time? > Did acpi_osi=Linux make a difference (all by itself)? Ok, I repeated the tests with a slightly more current linux-acpi-2.6 repository. It is the release branch, HEAD is commit a52500c917ead55dd78d9f37b8ca993f4f79f72a. I booted three times with acpi_osi=Linux and three times without it. It fails the same way each time. See attached boot logs (one with acpi_osi=Linux and one without). > Any difference with CONFIG_PREEMPT=n? No, not at all. (CONFIG_PREEMPT_NONE=y) Created attachment 14801 [details]
dmesg of unsuccessful boot
Created attachment 14802 [details]
dmesg of unsuccessful boot with acpi_osi=Linux
Hi, Sebastian Will you please try the early kernel (for example: 2.6.23.1) and attach the output of dmesg and lspci -vvxxx ? It will be great if you can boot the system with the acpi on? > Will you please try the early kernel (for example: 2.6.23.1) OK. > and attach the > output of dmesg and lspci -vvxxx ? dmesg output is from an unsuccessful boot attempt. lspci output was taken when the system was booted with acpi=off. > It will be great if you can boot the system > with the acpi on? I'm afraid we were not lucky today ... Created attachment 14841 [details]
dmesg output from a failed boot attempt on 2.6.23.1
Created attachment 14842 [details]
output from lspci -vvxxx on 2.6.23.1 booted with acpi=off
> PCI: Using MMCONFIG
please try booting with "pci=nommconf"
I tried booting 2.6.23.1 and linux-acpi-2.6 (checked out a few days ago) with pci=nommconf but it isn't better. dmesg output attached. Created attachment 14850 [details]
dmesg output from a failed boot attempt on 2.6.23.1 with pci=nommconf
Will you please try the boot option of "pci=nommconf acpi.debug_layer=0x010000 acpi.debug_level=0x17 " and attach the output? (Use the 2.6.23.1 kernel). Thanks. Created attachment 15016 [details]
output from a failed boot attempt on 2.6.23.1 with pci=nommconf acpi.debug_layer=0x010000
acpi.debug_level=0x17
Hi, Sebastian From the log it seems that the system hangs after parsing EC device and OS can't complete the acpi full initialization. Will you please try the debug patch in comment #28 of bug 9642 and add the boot option of "acpi.debug_layer=0x10004 acpi.debug_level=0x1f pci=nommconf"? Please attach the output of dmesg. Thanks. Created attachment 15031 [details] output from a failed boot attempt on 2.6.23.1 with pci=nommconf acpi.debug_layer=0x10004 acpi.debug_level=0x1f and modified with patch from comment 28 bug 9642 *** Bug 10119 has been marked as a duplicate of this bug. *** Created attachment 15044 [details] try the custom DSDT Will you please try the custom DSDT and boot the system with the option of "acpi.debug_layer=0x10004 acpi.debug_level=0x1f pci=nommconf"? Please attach the output of dmesg. How to use the custom DSDT can be found http://www.lesswatts.org/projects/acpi/faq.php. Thanks. Created attachment 15073 [details]
dmesg output from successful boot with replaced DSDT
Great! System boots successfully! But I have found out that the keys for the backlight do not work as they did with acpi=off. There are corresponding messages in dmesg which I have attached also.
Thanks!
Created attachment 15074 [details]
messages when pressing backlight keys
Thanks for the info. It is very great that the system can be booted very normally. The remained problem is that backlight can't work normally. Will you please do the following test based on the kerne in comment #20?( Custom DSDT table is required). a. boot the system with the option of "acpi.debug_layer=0x08010004 acpi.debug_level=0x1f pci=nommconf". b. press Fn keys for the backlight. After finishing the test, please attach the output of full dmesg. Will you please attach the output using the following command? acpidump --addr 0x3f6cec47 --length 0x100 -o mnvs Thanks. Created attachment 15083 [details] dmesg output as requested in comment 22 Created attachment 15084 [details] acpidump output as requested in comment 22 Hi, Sebastian From the log in comment #23 it seems that the acpi video driver isn't loaded. Will you please confirm whether CONFIG_ACPI_VIDEO is enabled in kernel configuration? If not, please enable it. It will be great if you can attach the output of dmesg and .config Thanks. Created attachment 15122 [details] dmesg output similar to comment 23 but with CONFIG_ACPI_VIDEO enabled Hi Yakui, you were right, CONFIG_ACPI_VIDEO was disabled. I enabled it and attached the dmesg output of the new compiled kernel, again after pressing the 'lower backlight' button three times. The following attachment is the used .config Is there a chance that the Linux kernel ACPI code is modified in a way that no custom DSDT is necessary? Thanks, Sebastian Created attachment 15123 [details]
config of 2.6.23.1 kernel
Hi, Sebastian Thanks for the log. From the log in comment #26 it seems that the VIDEO driver has done the right thing after pressing the 'lower backlight' button. ( Receiving the 0x87 notify and call the _BCM AML code to decrease the brightness). Will you please confirm whether the backlight can work well after ACPI_VIDEO is enabled? Please attach the output by using the following commands: acpidump --addr 0x3f6ced4d --length 0x2000 -o aslb Thanks. Created attachment 15131 [details] try the custom DSDT Will you please try the custom DSDT ? Please use the boot option required in comment #22. Thanks. Created attachment 15151 [details] dmesg output with DSDT from comment #29 and after pressing the backlight button several times Hi Yakui, I've found the reason why at first I thought that the backlight buttons don't work. Actually, they work but only with 10 brightness levels whereas with acpi=off there are 21. The 9 lowest levels seem to be right but at level 9 pressing the increase button lets the display get the maximum brightness. However, /sys/class/backlight/acpi_video0/actual_brightness shows the correct values. They are between 0 and 100, pressing the backlight keys dec-/increases the value of 5. So the wrong behaviour starts at a value of 45 where the backlight is set to the maximum. Created attachment 15152 [details] acpidump output as requested in comment 28 Linux failed to support the new Intel IGD Opregion BIOS. Sebastian, could you please verify if the backlight sys I/F can work in the latest kernel release, say 2.6.25-rc4? You don't need to use the hotkey, just poke /sys/class/backlight/acpi_video0/brightness and see if the backlight is actually changed. Hi, I tried 2.6.25-rc4 but the problem is the same. Only the numbers in /sys/class/backlight/acpi_video0/ changed e.g. max_brightness is now 20 while it was 100 in 2.6.23. Accordingly, the wrong maximum backlight starts with value 9 and not with 45 as it was before. (In reply to comment #33) > Hi, > I tried 2.6.25-rc4 but the problem is the same. Only the numbers in > /sys/class/backlight/acpi_video0/ changed e.g. max_brightness is now 20 while > it was 100 in 2.6.23. Yes, that's the right behaviour in 2.6.25-rc kernel. :p What I really care about is that if the brightness of your laptop can actually be changed when you echo a valid value (between 0 and the "max_brightness") to the "brightness" file. (In reply to comment #34) > Yes, that's the right behaviour in 2.6.25-rc kernel. :p I suspected that. :-) > What I really care about is that if the brightness of your laptop can > actually > be changed when you echo a valid value (between 0 and the "max_brightness") > to > the "brightness" file. Yes, it can be changed this way but also in that wrong fashion I described earlier. There are only 10 actual brightness levels, between 10 and 20 there is no difference in the brightness. (In reply to comment #35) > (In reply to comment #34) > > What I really care about is that if the brightness of your laptop can > actually > > be changed when you echo a valid value (between 0 and the "max_brightness") > to > > the "brightness" file. > Yes, it can be changed this way but also in that wrong fashion I described > earlier. There are only 10 actual brightness levels, between 10 and 20 there > is > no difference in the brightness. IMO, the max_brightness is 9, and you can successfully change the brightness from level 0 to 9, write any value larger than 9 will return errors, right? so what's the wrong fashion? Please reminder me if I miss something. :) *** Bug 10119 has been marked as a duplicate of this bug. *** (In reply to comment #36) > IMO, the max_brightness is 9, and you can successfully change the brightness > from level 0 to 9, write any value larger than 9 will return errors, right? > > so what's the wrong fashion? > Please reminder me if I miss something. :) If the notebook boots with acpi=off I can change the brightness in 21 levels (with the keys). I can actually see the brightness going up or down. So the notebook is really capable of changing the brightness in 21 levels. When it boots with ACPI enabled there are only 10 levels. The visual brightness difference between value 8 and 9 is noticeable larger than between smaller levels. Levels from 10 to 20 change nothing WRT the brightness - and no error is printed BTW. So my conclusion is: The maximum brightness "comes to early". The upper 10 brightness levels are skipped. Sebastian (In reply to comment #38) > (In reply to comment #36) > If the notebook boots with acpi=off I can change the brightness in 21 levels > (with the keys). I can actually see the brightness going up or down. So the > notebook is really capable of changing the brightness in 21 levels. When it > boots with ACPI enabled there are only 10 levels. > The visual brightness > difference between value 8 and 9 is noticeable larger than between smaller > levels. Levels from 10 to 20 change nothing WRT the brightness - and no error > is printed BTW. So there are only 10 levels that actually works, while you can get 20 from reading /sys/class/backlight/acpi_video0/max_brightness, right? > So my conclusion is: The maximum brightness "comes to early". The upper 10 > brightness levels are skipped. Yes, ACPI does support 21 levels on this laptop. Please attach the result of "cat /proc/acpi/video/GFX0/DD02/brightness". and the content of /proc/acpi/video/GFX0/DD02/brightness after set it to some value lager than 10. Created attachment 15221 [details]
custom DSDT
Please try this DSDT and boot with acpi.debug_level=0x0f.
Please try to set the brightness to level 5/10/15/20 each for one time and attach the full dmesg output.
(In reply to comment #39) > So there are only 10 levels that actually works, while you can get 20 from > reading /sys/class/backlight/acpi_video0/max_brightness, right? Right. > Yes, ACPI does support 21 levels on this laptop. > Please attach the result of "cat /proc/acpi/video/GFX0/DD02/brightness". levels: 100 0 0 5 10 15 20 25 30 35 40 45 50 55 60 65 70 75 80 85 90 95 100 current: 35 > and the content of /proc/acpi/video/GFX0/DD02/brightness after set it to some > value lager than 10. # echo 17 > /sys/class/backlight/acpi_video0/brightness # cat /proc/acpi/video/GFX0/DD02/brightness levels: 100 0 0 5 10 15 20 25 30 35 40 45 50 55 60 65 70 75 80 85 90 95 100 current: 85 Created attachment 15226 [details] dmesg output as requested in comment #40 Hi, sorry for the delay Please redo the test with boot option acpi_osi="!Windows2006". Created attachment 15975 [details] dmesg output similar to comment 42 but with acpi_osi="!Windows2006" backlight still does not work correctly. oops, sorry, it should be acpi-osi="!Windows 2006". sorry again for the mistake. Created attachment 15982 [details]
dmesg output with acpi_osi="!Windows_2006"
Regarding the settable brightness levels there is no difference. But there are other effects: During boot the brightness is set to the lowest level and the hot keys have no effect on the brightness any more.
At the ACPI video driver's point of view, there is no difference to set the brightness level to 1 or to 15. Both of them call into AML code and invoke Method (EC0B, 1, Serialized) { EC83 (0x0B, Arg0) Return (0x00) } I don;t know why it works when setting the brightness level to 0~9 and fails when setting it to 10~20. I don;t know how to debug further and IMO we should close it and mark it as WILL_NOT_FIX. What do you think, len? I have had this and other problems on the CF30 (mk2) and have just received a bios update from panasonic. Its taken a month! It fixes my problem - couldnt boot off a USB device (optic or mem-stick) and also the DSDT problems discussed here and in Bug 9915. The bios version is now at V14. hi, john, thanks for your info. :) |