Bug 8504

Summary: regression 2.6.21 boot hang - Redion EmbeddedControl(3) has no handler - Asus M6700NE
Product: ACPI Reporter: Matthias Bläsing (matthias.blaesing)
Component: ECAssignee: Alexey Starikovskiy (astarikovskiy)
Severity: normal CC: acpi-bugzilla
Priority: P2    
Hardware: i386   
OS: Linux   
Kernel Version: 2.6.22-rc2 Subsystem:
Regression: --- Bisected commit-id:
Attachments: ACPI Dump of M6700NE
Result of compilation with defconfig
dmesg from 2.6.20
dmesg from 2.6.21

Description Matthias Bläsing 2007-05-19 03:25:40 UTC
Most recent kernel where this bug did *NOT* occur: 2.6.21
Distribution: Debian unstable
Hardware Environment: Asus M6700NE
Software Environment: ?
Problem Description:

On Kernel 2.6.21 my internal notebook battery was not recogniced anymore, so I
wanted to try, whether it's still the case. After I compiled the kernel 

(see http://www.doppel-helix.eu/acpi_hang.config) 

I tried to boot it and got this:


The notebook did not boot further. That means, that I'm currently pinned to
kernel 2.6.20 (the last more or less fully working kernel).

Steps to reproduce:

comile kernel and boot notebook with it
Comment 1 Len Brown 2007-05-23 18:20:27 UTC
So 2.6.20 worked, and 2.6.21 and later fail?

how about with CONFIG_ACPI_BATTERY=n

Comment 2 Alexey Starikovskiy 2007-05-23 23:27:12 UTC
Could you please attach the output of acpidump utility?
Comment 3 Matthias Bläsing 2007-05-24 12:36:37 UTC
Created attachment 11591 [details]
ACPI Dump of M6700NE
Comment 4 Matthias Bläsing 2007-05-24 13:50:53 UTC
2.6.21: "worked" as in: booted, but battery is not recognised
2.6.22: does not boot

The battery problem is another bug. But I tried to recompile with the changes
Len mentioned - these didn't change anythink - same message on boot.

I expected that, as the hang happens directly after acpi is initialised. The
rest of the acpi parts are compiled as modules and loaded after the system got
up. I'll try again with every part compiled in.
Comment 5 Alexey Starikovskiy 2007-05-24 23:30:21 UTC
Could you please check if replacing current "drivers/acpi/ec.c" with file from
2.6.21 removes the problem? 
Comment 6 Matthias Bläsing 2007-05-26 14:28:58 UTC
No that does not help - I replaced the 2.6.22 ec.c with the 2.6.21 one and
adjusted the headers accordingly (one functions call signature was changed). The
2.6.21 bootet fine, but the 2.6.22 boot ended with the message from the first entry.
Comment 7 Alexey Starikovskiy 2007-05-28 00:58:31 UTC
Could you please attach dmesg output from 2.6.20, 2.6.21?
Do you have anything under /proc/acpi/embedded_controller if booted 2.6.21?
Could you try to compile 2.6.22 with defconfig and run it?
Comment 8 Matthias Bläsing 2007-05-28 05:20:19 UTC
Created attachment 11607 [details]
Result of compilation with defconfig

This was the tree with the replaces ec.c from 2.6.21 - I did a make defconfig
and after that build the package the debian way and tried to boot it.
Comment 9 Matthias Bläsing 2007-05-28 05:36:28 UTC
Created attachment 11608 [details]
dmesg from 2.6.20

There is also an embedded controller visible there:
mblaesing@prometheus:~$ cat /proc/acpi/embedded_controller/EC0/info 
gpe:		     0x1c
ports:			 0x66, 0x62
use global lock:	 no
Comment 10 Matthias Bläsing 2007-05-28 07:33:14 UTC
Created attachment 11610 [details]
dmesg from 2.6.21

There is also an embedded controller visible there:

mblaesing@prometheus:~$ cat /proc/acpi/embedded_controller/EC0/info
gpe:		     0x1c
ports:			 0x66, 0x62
use global lock:	 no
mblaesing@prometheus:~$ uname -a
Linux prometheus #1 Sat May 26 18:48:39 CEST 2007 i686 GNU/Linux
Comment 11 Matthias Bläsing 2007-06-09 18:11:45 UTC
I checked again with kernel 2.6.22-rc4-git3 - the bug is still there
Comment 12 Alexey Starikovskiy 2007-06-10 07:27:03 UTC
Please try patch from #8598.

*** This bug has been marked as a duplicate of 8598 ***