Bug 13195
|
Description
Brad Landis
2009-04-27 13:48:04 UTC
Will you please attach the output of acpidump? Will you please also try the following boot option and see whether the box can be booted? a. processor.max_cstate=1 b. idle=poll Thanks. so it can boot successfully with acpi enabled occasionally in 2.6.29, right? please attach the dmesg output after a successful boot. I removed acpi, and it does the same for all processor.max_cstate=1, idle=poll, both on. In fact, without the acpi argument, it ends at the same spot. No, I have not been able to boot it with acpi at all except for "ht". These are the last messages without acpi=off: ACPI: BIOS _OSI(Linux) query ignored ACPI: EC: non-query interrupt received, switching to interrupt mode I don't know if it's related, but I also get a pnpbios error message as well telling me to upgrade my bios, but booting continues after a few seconds. And there are no updates to the bios. Created attachment 21149 [details]
acpidump with acpi=off (Can't boot without that).
Do you mean that the box still hangs when adding the boot option of "idle=poll" or "processor.max_cstate=1"? Right? Will you please add the boot option of "initcall_debug" and capture the screenshot when it hangs? Thanks. can you get the boot log via the serial console, or get the screenshot when linux hangs and attach it here? Created attachment 21157 [details]
Screenshot with initcall_debug
I can use a serial cable if you'd like more info, but I don't have my other laptop with me.
Created attachment 21165 [details]
patch: enable EC debug
please try the latest git kernel, apply this patch and attach the screenshot when it hangs.
Created attachment 21166 [details]
ec debug
I didn't see a difference in it, but I may have compiled the kernel wrong. I just used "make defconfig", is that fine? I might should have copied over ubuntu's default configuration, but this was actually my first kernel compile, so I just did what the README said.
Created attachment 21167 [details]
ec debug with initcall_debug flag
Created attachment 21187 [details]
debug with acpi=ht
I'm not sure if this will help or not, but it shows some information about acpi, even though it is set to ht. (See line 51).
I tried taking out the acpi option, and I added acpi_sci=low, and it said something to the effect of "EC: Missing confirmations: Switch off interrupt mode." I don't know if that has anything to do with the issue or not. I tried playing around with all of the acpi options, but none of them seem to make it bootable. acpi_os_name I don't think did anything, because it still had the message about "_OSI(Linux) ignored". it seems that this is a regression, can you please make sure that CF-52 works well with ACPI enabled, on some earlier kernel releases? I have never been able to boot with acpi, except for acpi=ht, so I don't see how it is a regression. I noticed the user on the previous bug was able to get it to boot on occasion, so I was actually going to sit down one weekend and try to get it to boot with ACPI, but I just haven't been able to put in the time. If I could get it to boot, then I could just make a custom dsdt file (I think that's what it was called), but I haven't been able to do that. Is there any manual way to create a dsdt when it's not able to boot using ACPI at all? Created attachment 22228 [details]
try the custom DSDT
Hi, Brad
Will you please try the custom DSDT and see whether the box can be booted?
How to use the custom DSDT can be found in:
http://www.lesswatts.org/projects/acpi/faq.php
(The first four steps can be skipped.)
In the custom DSDT the call of EC01 is deleted in the _REG method.
Thanks.
Created attachment 22294 [details]
Screenshot
I'm not 100% sure I'm compiling correctly, but I followed the instructions, then did a make clean and a make. I copied arch/x86/boot/bzImage to /boot/vmlinux-custom, and made an entry for it.
I don't need a custom initrd or anything, do I?
Created attachment 22345 [details]
EC GPE is enabled after installing EC space handler
Will you please try the debug patch on the latest kernel(2.6.31-rc2/3) and see whether the box can be booted?
In the debug patch the EC GPE is enabled after installing EC space handler.
Thanks.
ping Brad, will you please try the debug patch attached in comment #18? Yeah, I will, probably this weekend. I've just had a lot of things going on. Sorry about being so slow about this, but I'm finally getting this started again. I'm in the process of getting this compiled, so I'll let you know how it turns out. Created attachment 23040 [details] Screenshot with Attachment 22345 [details] Still a no go. Created attachment 23064 [details]
Screen shot of boot with kernel source patch and init debug
Hi,
Finally managed to create an account on Bugzilla after 3 days of waiting for the email! :)
I'm experiencing the same issue on a Panasonic CF-52.
I can only boot with ACPI=off or ACPI=ht
I use Ubuntu on this laptop.
I created a custom kernel with ec_debug.patch based on 2.6.31-rc9
Screen shot of boot with initcall_debug attached.
If I can provide any further info or any testing, please let me know.
Cheers,
jcat
Created attachment 23065 [details]
Boot with ec_debug.patch and initcall_debug
..Apologies, wrong screen shot before. This one is easier to read..
Hi, Jcat
Sorry for the late response.
Please double check whether the patch in comment #18 is applied.
From the screenshot it seems that it doesn't print the following info:
>ACPI: Look up EC in DSDT
Thanks.
Hi, I'll double check and try this tomorrow. Cheers, jcat Can't seem to get this patch to apply properly. Unfortunately I'm using Ubuntu on this laptop, and I'm trying to hook into their kernel build system, which seems to be vastly over complicated. I just want to configure, make then install, but things in Ubuntu land are much more complicated, err, I mean simple! :) So I haven't forgotten, as soon as I get it patched and built I'll post back. Cheers, jcat Hi,
Not sure what's happening here.
Even manually compiled kernel fails to show "ACPI: Look up EC in DSDT"
I know the patch is applying ok, I have manually checked the file (several times).
My /usr/src/linux link is correct
I'm patching against 2.6.31.1
I'm using an initrd image (if that makes any difference)
@ Brad:
I see you're running Ubuntu.
Can you list the steps you used compile with the debug patch?
Here is what I'm doing...
Ubuntu way:
make oldconfig
make menuconfig
apply patch
make-kpkg clean
fakeroot make-kpkg --initrd --append-to-version=acpi-patch kernel-image kernel-headers
dpkg -i {the deb package files that are created)
Manual:
apply patch
make oldconfig
make menuconfig
make bzImage
make modules
make modules_install
cp arch/x86/boot/bzImage /boot/vmlinuz-2.6.31.1
cp System.map /boot/System.map-2.6.31.1
mkinitramfs -o /boot/initrd.img-2.6.31.1
Thanks in advance
Cheers,
jcat
I'm doing it the manual way (I think). There was a lot of documentation, and I've never been an expert compiler, so I could have been doing it wrong. I think I patched the files by hand though, since it wasn't a big changeset. Created attachment 23360 [details]
Screenshot - boot with patched acpi ec debug patch
Created attachment 23361 [details] patched ec.c (hopefully...) Well, I've tried several things, and I whenever I boot, I _don't_ get the "ACPI: Look up EC in DSDT" output as expected from the patch. At first I just doubted that the patch was being applied, but nearly 99% sure it is being applied. Just to make absolutely sure nothing distro related was catching me out, I ditched the Ubuntu way and went completely vanilla. I downloaded http://www.kernel.org/pub/linux/kernel/v2.6/linux-2.6.31.3.tar.bz2 #untarred in /usr/src/ #created link in /usr/src/ ( linux -> linux-2.6.31.3 ) cd /usr/src/linux cp arch/x86/configs/i386_defconfig .config make oldconfig make menuconfig #(updated process type) make bzImage cp arch/x86/boot/bzImage /boot/vmlinuz-2.6.31-custom #update grub2 config accordingly: menuentry "Ubuntu, Linux - 2.6.31 - custom" { recordfail=1 save_env recordfail set quiet=1 insmod ext2 set root=(hd0,0) search --no-floppy --fs-uuid --set 166e3962-4b1f-442d-8bc7-509fffe1fe69 linux /vmlinuz-2.6.31-custom root=UUID=b5f710cc-11e5-4fa9-9cf2-a9246d5c3f97 ro pnpbios=off crashkernel=384M-2G:64M,2G-:128M } Rebooted. No dice. I have attached the screenshot AND the drivers/acpi/ec.c after kernel is compiled (so you can check it was patched correctly). So why doesn't the output look correct? Any ideas Devs? Am I missing a kernel option maybe? I really want to help get this bug fixed if I can :) BTW I also tried 2.6.32-RC4, as I see it's had some ACPI changes, but still no go. Cheers, jcat Hi ykzhao or Zhang Rui, Can you comment on the above please? I need you to confirm that the "ec.c" I attached is definitely patched, and also to help explain if it is patched, why it could have not produced the desired output after compiling. I would like to help get this regression fix. Cheers, jcat Created attachment 23819 [details] try the custom DSDT Will you please try the custom DSDT and see whether the box still hangs? How to use the custom DSDT can be found in: http://www.lesswatts.org/projects/acpi/faq.php Note: I already attach the custom DSDT.hex and you can skip the first four steps. Thanks. After I re-look at the log in bug9915, it seems that the bug is related with the broken BIOS. In bug9915 the box can be booted with ACPI enabled after using the custom DSDT(http://bugzilla.kernel.org/show_bug.cgi?id=9915#C20). Will you please also try the custom DSDT and see whether the issue still exists? Thanks. Ok, that boots! :) However, there are a couple of issues. Similar to the other bug, the backlight doesn't quite work properly. When it first booted, I could tell it had made it past the initial ACPI section because the hard disk light was flashing, but the screen had gone blank. the laptop then shut itself down (and powered off properly, another hint that ACPI was working). I realised that the screen was not blank, it was just not lit. I tried booting again, and hit the brightness key on the laptop, and I saw the screen :) The brightness button has lost it's "steps", it seems it's just on/off now. Now that I could see the screen, I saw why it was powering off shortly after initial boot. It's shutting down because of: "critical temperature reached 255*C, shutting down." However, I know the laptop is not that hot ;-) Thank again for your help. Where do we go from here? Cheers, jcat Ok, building without CONFIG_ACPI_THERMAL set stops the automatic thermal shutdown. The laptop boots normally. I have installed lm-sensors, and the core temperatures are 41*C ~ 44*C, so temperatures are definitely normal (not that I ever thought they were 255*C ;-) ) Question: Given that temps are ok, and I can still here the laptop fans speeding up when the cpu is under load. Is it safe to run without CONFIG_ACPI_THERMAL ? ..and.. What is the main purpose of this option? Cheers, jcat How did you compile it jcat? I am still getting errors, but maybe it's just me. I found this site: http://blog.avirtualhome.com/2009/09/08/how-to-compile-a-kernel-for-ubuntu-jaunty-revised/ . Should I follow those instructions to make it for ubuntu? Thanks. Created attachment 23930 [details]
Helper script to compile kernel using the Ubuntu method with custom DSDT - Use at your own risk :)
Hi Brad,
I've attached a fairly dumb helper script, which was created to automate the ubuntu steps. Have a look, and alter it to reflect your system.
Install the linux-source package from the ubuntu repo.
Unpack the Linux source (found in /usr/src/), and link to it with /usr/src/linux
Then run the script (after modifying) with something like:
./make-new-kernel.sh -c -s custom-dsdt
..in menu config, un-select the option:
"Device Drivers/Generic Driver Options/Select only drivers that don't need compile-time external firmware"
..then enter the name of the DSDT file (DSDT.hex) in option:
"Power management and ACPI options/ACPI (Advanced Configuration and Power Interface) Support/Custom DSDT Table file to include"
..then un-select "Power management and ACPI options/ACPI (Advanced Configuration and Power Interface) Support/Thermal Zone"
..then when you exit menuconfig, select to save it when it promts you.
You should end up with a kernel package, and a linux-headers package in /usr/src/. Install both packages with dpkg.
If you use the default ubuntu config, it will take a couple of hours to compile the kernel, as it contains nearly every option under the sun. You can reduce the time by removing at least all the drivers you don't need :)
You can of course just test the DSDT by getting the source from kernel.org and putting the DSDT in the source include directory, copy the defualt x86 config to .config, "make oldconfig", "make menuconfig" configuring as above, the doing:
make clean
make bzImage
make modules
make modules_install
Then copy the kernel image to /boot/ and set-up grub accordingly.
Using Ubutnu, it's probably better to use the Ubuntu way, as it uses their source patch set and ties in with their package management, and will allow the boot to look pretty etc :)
Cheers,
jcat
Hi, Jcat
Thanks for the info.
The good news is that the system can be booted when using the custom DSDT. Now it is confirmed that this issue is related with the broken BIOS.
When the thermal module is loaded, it will report that it reaches the critical shutdown threshold and then the box is shutdown. And from the acpidump it seems that this is related with the incorrect reporting of thermal temperatur. And this is also caused by the broken BIOS.
Will you please try the boot option of "thermal.nocrt=1" and see whether the box can be booted when using the thermal module?(The thermal module had better be compiled as built-in kernel module. The "CONFIG_ACPI_THERMAL" is selected as Y in kernel configuration).
Thanks.
Hi ykzhao, Yes, it boots ok with acpi thermal in the kernel if I boot with "thermal.nocrt=1". What I'm finding puzzling now, is that the laptop doesn't boot 100% of the time with the custom DSDT. Any idea why that would be? Cheers, jcat How about when you add the boot option of "thermal.nocrt=1" after using the custom DSDT? Thanks. Apologies, that was with the custom DSDT and "thermal.nocrt=1". In comment#39, did you mean try without a custom DSDT and "thermal.nocrt=1" ? Cheers, jcat Created attachment 24137 [details]
Screenshot
My Custom DSDT build was not successful...
There were some errors on the post-install when I went to install linux-image-2.6.28.10custom-20091209_2.6.28.10custom-20091209-10.00.Custom_i386.deb, but I didn't know how to check what they are, and I'm not sure they matter.
I am getting this error in /var/log/messages when acpi=ht, if it helps any:
kernel: [ 8.916008] pci 0000:00:1d.7: EHCI: BIOS handoff failed (BIOS bug?) 01010001
(In reply to comment #42) > Apologies, that was with the custom DSDT and "thermal.nocrt=1". > In comment#39, did you mean try without a custom DSDT and "thermal.nocrt=1" ? > Cheers, > jcat Sorry for the late response. What I mean is that you add the boot option of "thermal.nocrt=1" after using the custom DSDT.(The two are used together). Since you already try this, I have no idea why it can't be booted 100% of time. Maybe the BIOS still has some other issues we don't know. thanks. (In reply to comment #44) > Maybe the BIOS still has some other issues we don't know. I think that is an understatement! :) Thanks for all your help. I appreciate it :) Cheers, jcat Created attachment 25919 [details]
No sleep until running
Please check if this patch helps.
Created attachment 25920 [details]
properly documented last patch
Well, I'm not sure if this is not too optimistic: + if (system_state == SYSTEM_RUNNING) + schedule_timeout_interruptible(msecs_to_jiffies(ms)); It changes the behavior in all system states other than RUNNING and on all systems, while as far as I can say the problem only happens during boot on one system. So, it seems like this would be a bit safer: + if (system_state == SYSTEM_BOOTING) + acpi_os_stall(ms * 1000); + else + schedule_timeout_interruptible(msecs_to_jiffies(ms)); Hi Alexey, I tried this patch on 2.6.33 x86, but it still hangs (as before) when I leave ACPI enabled. If you want any further info, please let me know. Cheers, jcat Created attachment 25961 [details]
debug patch
Please apply this patch and post dmesg here.
Created attachment 26052 [details]
Boot messages with patch 25961
Hi Alexey,
Apologies for the late response.
It doesn't boot fully using 2.6.33 x86. I've attached a screenshot of the point it reaches with init_call.debug
However it is worth noting that the booting these laptops doesn't seem to be 100% consistent. When I boot with ACPI enabled, and the custom DSDT, it boots about 60% of the time.
Anything else I can do to help debug, please let me now :)
Cheers,
jcat
Created attachment 26124 [details]
Add constraints to ACPI Sleep
Hi, please check if this patch works for you.
Created attachment 26173 [details]
dmesg - boot 2.6.33 with no_sleep_until_running patch (id=26124)
It works :)
The screen brightness is the only thing I've found that's not completely working, but even that is much improved. It now fades from dim to bright in 0% - 50%, and 50%+ is ignored, but this is not a problem for me.
Are you able to tell anything useful from the dmesg output?
Does it give you any clues as to why the standard kernel doesn't boot with ACPI?
Cheers,
Just
Created attachment 26174 [details]
dmesg - boot 2.6.33 with no_sleep_until_running patch (id=26124)
Uploaded and set correct mime type
Comment on attachment 26173 [details]
dmesg - boot 2.6.33 with no_sleep_until_running patch (id=26124)
wrong mime type
Just, read the header of the patch, it explains the problem. I'll mark bug as resolved, so that patch can go upstream... Thanks for testing. Got it, I missed the header initially as it's only in the first of your patches. Thanks for your time on this, I really appreciate it. One last question.. What's the best way to track this patches inclusion into the kernel, and the release it will appear in? Cheers, Just Created attachment 26263 [details]
Do IGD OpRegion setup early
Please check if this patch works for you without previous patch
Created attachment 26366 [details]
Screen shot of boot with patch id=26263 using init_call.debug
Booting with patch "Do IGD OpRegion setup early" fails.
It pauses indefinitely as per the screen shot.
Cheers,
Just
patch failed - bug re-opened Hi Len, Please expand :) The patch is still working fine for me on 2.6.35 Are you using this one? Add constraints to ACPI Sleep https://bugzilla.kernel.org/attachment.cgi?id=26124 Cheers, Just Patch already available. Len, please consider the patch in comment #52. should be fixed by ACPICA patch that shipped in 2.6.35. Let me know/re-open if 2.6.35 or later doesn't work properly. #define ACPI_MAX_SLEEP 20000 /* Two seconds */ commit 9cbfa18e8a7b34a32eddbd914a07f085962f50a8 Author: Bob Moore <robert.moore@intel.com> Date: Wed May 26 11:22:41 2010 +0800 ACPICA: Limit maximum time for Sleep() operator To prevent accidental deep sleeps, limit the maximum time that Sleep() will sleep. Configurable, default maximum is two seconds. ACPICA bugzilla 854. http://www.acpica.org/bugzilla/show_bug.cgi?id=854 Signed-off-by: Bob Moore <robert.moore@intel.com> Signed-off-by: Lin Ming <ming.m.lin@intel.com> Signed-off-by: Len Brown <len.brown@intel.com> Hi Len, This commit: commit 9cbfa18e8a7b34a32eddbd914a07f085962f50a8 Author: Bob Moore <robert.moore@intel.com> Date: Wed May 26 11:22:41 2010 +0800 ...doesn't fix the issue for me on a Panasonic CF-52 Only the this patch gets me past initial boot sequence successfully: Add constraints to ACPI Sleep https://bugzilla.kernel.org/attachment.cgi?id=26124 I'm because I tend to use a binary distro at work, I'm having to re-compile the kernel with the working patch every time the distro upgrades :) I just tried 3.0.1 without any patches, and the boot still fails. Can we just get the patch that works committed upstream?? Cheers, Just Created attachment 70842 [details]
patch vs 3.1
please apply this patch to 2.6.35 or later and report
if the panasonic boots in a reasonable amount of time.
Hi Len, That works for me patching 3.0.4 :) So it should have been fixed from 2.6.35 except for a type :) Please can you link to your upstream commit when it's accepted, just so I can track it into my distro (and maybe get them to back port the patch) Thanks! Cheers, Just A patch referencing this bug report has been merged in Linux v3.1-rc10: commit b33c25d6a62ac253caabda2b5f43258abff451c0 Author: Len Brown <len.brown@intel.com> Date: Mon Aug 29 23:01:58 2011 -0400 acpica: ACPI_MAX_SLEEP should be 2 sec, not 20 It's great that kernel bugzilla is back. what's the current status of the bug? Brad and jcat, can you please verify if the problem still exists in the latest upstream kernel? Well, as it happens I no longer have this laptop. But the latest patch definitely worked for me, so as far as I'm concerned the bug is closed. Thanks to all :) Cheers, Just |