Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
ACPI question - can I overcome Windows-only support? *SOLVED
View unanswered posts
View posts from last 24 hours

Goto page Previous  1, 2  
Reply to topic    Gentoo Forums Forum Index Kernel & Hardware
View previous topic :: View next topic  
Author Message
jetblack
Guru
Guru


Joined: 15 Jan 2003
Posts: 340
Location: Evanston, IL, USA

PostPosted: Fri Dec 26, 2003 6:17 pm    Post subject: Reply with quote

Wow, that's a long post :) Could you possibly make a link to the file instead? If you don't have anywhere to put it, I'd be happy to post it somewhere.

I just have a minute to glance at it (off to the vet), but a quick search for "THRM" didn't turn anything up in your DSDT, so that may be the problem. Also, there seem to be a bunch of checks for whether the OS is some version of Windows (search it on WIndows, you'll see them). I'm not sure how I feel about that. For reference, you can compare against my DSDT here.
Back to top
View user's profile Send private message
jo_vermeulen
n00b
n00b


Joined: 21 Aug 2003
Posts: 64

PostPosted: Fri Dec 26, 2003 6:28 pm    Post subject: Reply with quote

jetblack wrote:
Wow, that's a long post :) Could you possibly make a link to the file instead? If you don't have anywhere to put it, I'd be happy to post it somewhere.

I just have a minute to glance at it (off to the vet), but a quick search for "THRM" didn't turn anything up in your DSDT, so that may be the problem. Also, there seem to be a bunch of checks for whether the OS is some version of Windows (search it on WIndows, you'll see them). I'm not sure how I feel about that. For reference, you can compare against my DSDT here.


Ok, I put it on my homepage.

I already feared it to be Windows only... :(

Damn "Designed for Windows XP" logo... Anything I can do about it?

Thanks again!
_________________
Jo Vermeulen
Student Computer Science at the tUL
email: jo@lumumba.luc.ac.be
www: http://lumumba.luc.ac.be/jo
Back to top
View user's profile Send private message
jetblack
Guru
Guru


Joined: 15 Jan 2003
Posts: 340
Location: Evanston, IL, USA

PostPosted: Fri Dec 26, 2003 8:13 pm    Post subject: Reply with quote

I'm not sure exactly what you can do about it. I am staring at that same logo, but I do slowly seem to be getting support (still scratching my head over all of those Windows references in your DSDT).

I still haven't found anything in you DSDT that corresponds to the thermal functions in mine (search on "Scope _TZ_" in my DSDT if you'd like to see my thermal zone section), so perhaps you are just dealing with a buggy/incomplete DSDT. They have been fixing these over at acpi.sourceforge.net, so that may be a good place to look. Or, you could submit a bug to bugzilla.kernel.org. They've been very responsive for me.

I have found this patch for the 2.6 kernels that appears to provide support for omnibooks (including the ACER Aspire series, you can search on "Aspire" in the patch). It looks like it has functions for thermal support and such, so it may be worth giving it a shot.

I'll let you know if I come across anything else.
Back to top
View user's profile Send private message
jo_vermeulen
n00b
n00b


Joined: 21 Aug 2003
Posts: 64

PostPosted: Fri Dec 26, 2003 11:42 pm    Post subject: Reply with quote

jetblack wrote:
I'm not sure exactly what you can do about it. I am staring at that same logo, but I do slowly seem to be getting support (still scratching my head over all of those Windows references in your DSDT).

I still haven't found anything in you DSDT that corresponds to the thermal functions in mine (search on "Scope _TZ_" in my DSDT if you'd like to see my thermal zone section), so perhaps you are just dealing with a buggy/incomplete DSDT. They have been fixing these over at acpi.sourceforge.net, so that may be a good place to look. Or, you could submit a bug to bugzilla.kernel.org. They've been very responsive for me.

I have found this patch for the 2.6 kernels that appears to provide support for omnibooks (including the ACER Aspire series, you can search on "Aspire" in the patch). It looks like it has functions for thermal support and such, so it may be worth giving it a shot.

I'll let you know if I come across anything else.


Thanks a lot, I really appreciate it!

Overheating would make sense because I rarely get the problem at home, but very often at school. At home, I usually work on my laptop in the basement, where it's cool, and the laptop doesn't overheat that soon.
The fan does work now and then though.

It's a pity all those laptops use Windows-only ACPI code... :(

I haven't tried the 2.6 kernel yet, but I guess I have to to update in order to solve this problem.

I hope to fix it soon. You sure helped me a lot today!

Kind regards,
_________________
Jo Vermeulen
Student Computer Science at the tUL
email: jo@lumumba.luc.ac.be
www: http://lumumba.luc.ac.be/jo
Back to top
View user's profile Send private message
zwimmy
n00b
n00b


Joined: 20 Dec 2003
Posts: 4

PostPosted: Sat Dec 27, 2003 8:55 am    Post subject: Reply with quote

I have the exact same laptop as Jo and the exact same problems.

BUT everything worked great and solid as a rock under Red Hat 9.0 .... what is so different about RH than?
Back to top
View user's profile Send private message
jo_vermeulen
n00b
n00b


Joined: 21 Aug 2003
Posts: 64

PostPosted: Sat Dec 27, 2003 2:32 pm    Post subject: Reply with quote

zwimmy wrote:
I have the exact same laptop as Jo and the exact same problems.

BUT everything worked great and solid as a rock under Red Hat 9.0 .... what is so different about RH than?


Maybe the patched Redhat kernel has some ACPI updates to fix this problem?Would be nice to get those :(

Kind regards,
_________________
Jo Vermeulen
Student Computer Science at the tUL
email: jo@lumumba.luc.ac.be
www: http://lumumba.luc.ac.be/jo
Back to top
View user's profile Send private message
jetblack
Guru
Guru


Joined: 15 Jan 2003
Posts: 340
Location: Evanston, IL, USA

PostPosted: Wed Dec 31, 2003 12:30 am    Post subject: Reply with quote

jo_vermeulen wrote:
zwimmy wrote:
I have the exact same laptop as Jo and the exact same problems.

BUT everything worked great and solid as a rock under Red Hat 9.0 .... what is so different about RH than?


Maybe the patched Redhat kernel has some ACPI updates to fix this problem?Would be nice to get those :(

Kind regards,


*slaps self on head*

Gentoo does have a redhat-sources ebuild, so I guess you could emerge them and try it out...
Back to top
View user's profile Send private message
jetblack
Guru
Guru


Joined: 15 Jan 2003
Posts: 340
Location: Evanston, IL, USA

PostPosted: Wed Dec 31, 2003 12:32 am    Post subject: Reply with quote

Well, I now have AC Adapter and battery information! Check the update at bugzilla for details:

http://bugzilla.kernel.org/show_bug.cgi?id=1744

It's not completely fixed yet - I'll post the full information when/if I get the battery capacity information. Thanks again to Luming!
Back to top
View user's profile Send private message
jana
n00b
n00b


Joined: 23 Oct 2002
Posts: 24
Location: Blacksburg, VA

PostPosted: Fri Jan 02, 2004 9:40 pm    Post subject: dell x200 Reply with quote

hi all...

I've got a Dell Latitude x200, which (as of 2002) was nearly identical to the Gateway 200x. Jetblack, what year is your machine? I wonder if Dell and Gateway use the same bioses... Oh, and I love my little laptop, too! :D

I've been running with APM, but I'm interested to try getting ACPI going. Which kernel + patch do you recommend starting with? It looks like the first patch was on a 2.6 kernel and then second was on 2.4. I'm not sure from your last post which one you're running now.

As far as the redhat-sources idea, would it be useful to grep through those kernels for keywords in the patches Luming developed? I've compiled my share of kernels, but I've never poked inside of one...

Thanks, and happy new year!
- j
_________________
"That does not make sense to me. But, you are very small."
Back to top
View user's profile Send private message
jetblack
Guru
Guru


Joined: 15 Jan 2003
Posts: 340
Location: Evanston, IL, USA

PostPosted: Sat Jan 03, 2004 12:45 am    Post subject: Reply with quote

I got mine about 3 months ago, at the end of 2003. I'm not sure what the BIOS version is off the top of my head.

As far as the patches and all go, I'm currently doing most of my testing with the following configuration:

1. kernel 2.4.23
2. latest ACPI patch from acpi.sourceforge.net
3. Luming's bit width patch from bugzilla.kernel.org (converts bit witdh problems from errors to warnings)
4. Luming's Embedded Control initialization patch from bugzilla.kernel.org.This reattempts the Embedded Control initialization after it has been parsed from the DSDT.

I have also tried this with 2.6.0 and 2.6.0-mm1. Everything is okay up until the Embedded Control patch, which wouldn't apply to the 2.6 sources.

Let me know if that helps any. I'm digging around my DSDT to see if I can figure out why I'm not seeing all of my battery info yet. If I work it out (or if Luming beats me to the punch with another patch) I'll post back here.

As far as the redhat-sources go, I suppose that you could do that, but I doubt that they'd be in any of the more official branches yet (at least, not the patches that I've been using). They're at most a week old, they've only ever been used by me as far as I can tell, and the bug still isn't resolved at bugzilla. I imagine that they'd at least wait until the problem had a proper solution, or was determined to be insoluble.
Back to top
View user's profile Send private message
jana
n00b
n00b


Joined: 23 Oct 2002
Posts: 24
Location: Blacksburg, VA

PostPosted: Mon Jan 05, 2004 4:04 am    Post subject: quick update... Reply with quote

Well, this probably isn't surprising, but... SUCCESS! using the 2.4.23 kernel with patches. You're right that this functionality doesn't appear to be in the newest redhat-sources, although that's based on grepping (and if Luming developed original code there's no reason to think that this would be a good way to find common functionality).

Anyway, I haven't had much time to play with things, but I definitely have battery, ac, button, and thermal events. I'll post more when I've had more time to work with the system...

Great job, jetblack! :)

- j
_________________
"That does not make sense to me. But, you are very small."
Back to top
View user's profile Send private message
jetblack
Guru
Guru


Joined: 15 Jan 2003
Posts: 340
Location: Evanston, IL, USA

PostPosted: Mon Jan 05, 2004 11:36 am    Post subject: Reply with quote

Glad to hear it, jana! When you get a chance, could you tell me if all of your battery information is reported correctly? As you may have seen in the comments in bug 1744, my battery isn't reporting all of its capacity info correctly quite yet. Still trying to work it out.

Glad those patches helped you!
Back to top
View user's profile Send private message
jana
n00b
n00b


Joined: 23 Oct 2002
Posts: 24
Location: Blacksburg, VA

PostPosted: Tue Jan 06, 2004 4:34 am    Post subject: battery info Reply with quote

Hmmmn.

My BAT1/info file gives me "design capacity" and "last full capacity" numbers... who knows if they're right, but it's reporting something. In fact, the info file is full with the exception of the model and serial numbers.

The BAT1/state file gives me a "capacity state" (ok) and a value for the "remaining capacity." This number correlates well with the numbers in the info file, so that's encouraging. The only line that appears to be broken in the state file is the "charging state," which knows when it's discharging but lists as "unknown" when the ac adapter is plugged in. I get both charge and discharge rates reported, though.

Other differences, based on that kernel bugzilla: my lid button works, but power and sleep don't.

And for what it's worth, I've also got duplicate directories in the embedded_controller path.

- j
_________________
"That does not make sense to me. But, you are very small."
Back to top
View user's profile Send private message
jetblack
Guru
Guru


Joined: 15 Jan 2003
Posts: 340
Location: Evanston, IL, USA

PostPosted: Tue Jan 06, 2004 1:42 pm    Post subject: Reply with quote

Ok, thanks. I guess I've got some goofy issue with my battery then.

I'm pretty sure that the duplicate Embedded Control entry is just because of the reinitialization that the second patch does. It's probably not a big deal, but it is a little interesting.

I'm going to go ahead and update that bug with your results, since it may be that my battery issue is a different problem. We'll see what they think. It looks like some other folks are having a similar issue.
Back to top
View user's profile Send private message
jana
n00b
n00b


Joined: 23 Oct 2002
Posts: 24
Location: Blacksburg, VA

PostPosted: Tue Jan 06, 2004 2:27 pm    Post subject: Reply with quote

Sounds good.

One minor change from what I noted last night: the battery now knows when it's charging. I guess last night it was so close to full that it wasn't really pulling current, but this morning after the walk in to campus it's low enough to be actively pulling, so acpi knows what's going on.

- j
_________________
"That does not make sense to me. But, you are very small."
Back to top
View user's profile Send private message
Stu L Tissimus
Veteran
Veteran


Joined: 08 Jun 2003
Posts: 1339
Location: NJ, 5 minutes from NYC

PostPosted: Tue Jan 06, 2004 3:47 pm    Post subject: Reply with quote

Hmmm... Interesting topic. I never knew there was such a thing as drivers for ACPI... Well, since ACPI doesnt work for my lappy either, *mark*

P.S. Hi Jetblack! (...You do know me, right?)
_________________
old outdated sig
Back to top
View user's profile Send private message
jetblack
Guru
Guru


Joined: 15 Jan 2003
Posts: 340
Location: Evanston, IL, USA

PostPosted: Wed Jan 07, 2004 6:57 pm    Post subject: Reply with quote

I love the smell of ACPI in the morning. Smells like.... VICTORY!

Yes! Finally, I have full ACPI support for the laptop (well - heh - except suspend ;)) . Here's the latest (WARNING - this is a long post):

The bit_width kernel patch, while it restored some things, was really more of a band-aid to allow the system to skip over a bug in the EmbeddedControl region of the DSDT. The correct solution was to fix the DSDT. Here's how I did that, in case anyone else runs across a similar problem.

First, you need the iasl compiler from intel. Try the binary first. If that doesn't work for you (it worked for me), you can grab the source and compile it:
Binary iasl compiler
source for ACPI CA build environment

Extract the tarball to a directory somewhere. You will have a file called iasl in the resulting directory. That's the compiler.

Once you have iasl, you'll need your dsdt. You can get this most easily by issuing the following command as root:
Code:
cat /proc/acpi/dsdt > dsdt.dat

This will create a file called dsdt.dat in the current directory that contains the compiled DSDT.

Next, you need to disassemble the DSDT. You can do that with iasl. It will give you a much more legible result than the disassembler I linked to previously.

To disassemble your DSDT, just do the following (for simplicity, I'm assuming that everything is in the same directory)
Code:
./iasl -d dsdt.dat


This will create a file called dsdt.dsl, which contains the disassembled DSDT.

Now, to find out if your DSDT has any errors, just recompile it as follows:
Code:
./iasl -tc dsdt.dsl


This will create two files, DSDT.aml and dsdt.hex. Eventually, we will be interested in the .hex file. But for now, the important thing is that it will also spit out any errors and warnings that it encountered while compiling. In my case, I get the following:

Code:
Intel ACPI Component Architecture
ASL Optimizing Compiler / AML Disassembler version 20030228 [Feb 28 2003]
Copyright (C) 2000 - 2003 Intel Corporation
Supports ACPI Specification Revision 2.0b

dsdt.dsl   163:     Method (_WAK, 1, NotSerialized)
Warning  2026 -                ^ Reserved method must return a value (_WAK)

dsdt.dsl  2626:                     Field (ECR, DWordAcc, Lock, Preserve)
Error    1048 -                              ^ Host Operation Region requires ByteAcc access

dsdt.dsl  2672:                     Method (_GLK, 1, NotSerialized)
Warning  2024 -                                ^ Reserved method has too many arguments ( _GLK requires 0)

ASL Input:  dsdt.dsl - 3759 lines, 123154 bytes, 1862 keywords
Compilation complete. 1 Errors, 2 Warnings, 0 Remarks, 390 Optimizations


Two warnings, one error. And - aha! The error is the DWordAcc bit in the EmbeddedControl region. That's the source of my problems. Politely, the compiler even told me what I had to do to fix it. All you have to do now is open dsdt.dsl in your favorite text editor and modify it. In my case, it told me that I need ByteAcc access (instead of the DWordACC access). So, I just changed line 2626 from this:

Code:
Field (ECR, DWordAcc, Lock, Preserve)


to this:

Code:
Field (ECR, ByteAcc, Lock, Preserve)


Ok, let's see what happens when we compile it now.

Once again, compile with iasl

Code:
./iasl -tc dsdt.dsl


And we get:

Code:
Intel ACPI Component Architecture
ASL Optimizing Compiler / AML Disassembler version 20030228 [Feb 28 2003]
Copyright (C) 2000 - 2003 Intel Corporation
Supports ACPI Specification Revision 2.0b

dsdt.dsl   163:     Method (_WAK, 1, NotSerialized)
Warning  2026 -                ^ Reserved method must return a value (_WAK)

dsdt.dsl  2672:                     Method (_GLK, 1, NotSerialized)
Warning  2024 -                                ^ Reserved method has too many arguments ( _GLK requires 0)

ASL Input:  dsdt.dsl - 3759 lines, 123153 bytes, 1862 keywords
AML Output: DSDT.aml - 14600 bytes 499 named objects 1363 executable opcodes

Compilation complete. 0 Errors, 2 Warnings, 0 Remarks, 390 Optimizations


Well, the warnings are still there, but that error is gone. That appeared to be the root of my problem, so I decided this was okay for now.

So, now we have a "fixed" DSDT. We need to convince the kernel to use it instead of the broken one. Fortunately, the ACPI developers have put together a patch that allows you to do this. Unfortunately, it doesn't compile with 2.4.23. So, I modified it slightly to do that. You can get the modified DSDT override patch for 2.4.23 here.

Grab that patch and apply it to your kernel. That will allow you to include a custom DSDT. The patch expects it to be at /usr/src/linux-2.4.23/include/acpi/dsdt_table.h (substitute whatever you use for you kernel source directory for /usr/src/linux-2.4.23). So, copy the dsdt.hex that was generated from the successful compile to /usr/src/linux-2.4.23/include/acpi/dsdt_table.h.

Code:
cp dsdt.hex /usr/src/linux-2.4.23/include/acpi/dsdt_table.h


Now, just recompile your kernel as usual, and the new kernel should use the fixed DSDT.

In my case, this got me past my bit width problems. So, I was bascially back where I was when I had applied the bit width patch. I had buttons, fans and thermal zones. I had no battery or ac adapter. However, I was better off, because my lid was now reporting its status correctly, which it wasn't before.

So, to try to get the battery and ac adapter info back, I reapplied Luming's EmbeddedControl patch (I still think that that is an ECDT problem). Voila! The battery and ac adapter showed up, and now they give me all of the capacity and charging/discharging information.

So, that's pretty much everything that wasn't working under 2.4.23. In summary, here's what I ended up doing:

1. Install vanilla 2.4.23 kernel sources
2. Apply latest acpi patch from acpi.sourceforge.net
3. Apply DSDT override patch from bugzilla
4. Apply EmbeddedContol initialization patch from bugzilla.kernel.org
5. Get iasl compiler from Intel.
6. Fix my DSDT as follows:
Code:
su to root

cat /proc/acpi/dsdt > dsdt.dat  (extract current compiled DSDT)
./iasl -d dsdt.dat   (disassemble DSDT)
./iasl -tc dsdt.dsl  (recompile DSDT - check for errors)
vi dsdt.dsl (fix errors in DSDT)
./iasl -tc dsdt.dsl (recompile DSDT with no errors - hopefully)

7. Copy the fixed DSDT to the kernel source tree
Code:
cp dsdt.hex /usr/src/linux-2.4.23/include/acpi/dsdt_table.h

8. Recompile kernel and reboot!

I hope that some of that is helpful to someone. I think the EmbeddedControl stuff may be relatively exclusive to this laptop (and jana's). If you have DSDT errors, they probably aren't exactly the same as mine, but you should at least be able to diagnose them in this manner.

Finally, don't forget the acpi-devel and acpi-bugzilla mailing lists, or bugzilla.kernel.org.

Thanks to Luming, Ducrot, and the other acpi developers!

If you'd like, you can follow the course of this bug at buzilla here.

Now, I just have to see if I can get it going in 2.6 ;)
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Kernel & Hardware All times are GMT
Goto page Previous  1, 2
Page 2 of 2

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum