| View previous topic :: View next topic |
| Author |
Message |
sundialsvc4
Guru
Joined: 10 Nov 2005
Posts: 436
|
 Posted: Wed Feb 22, 2006 8:23 pm Post subject: ACPI issue with Sony Viao PCG-FX140 |
 |
|
This machine is a Sony Viao laptop PCG-FX140. When booting with "ACPI=yes" or "ACPI=force," the system hangs on boot with the following messages (excerpt) | Code: | ACPI: setting ELCR to 0200 (from 0e20)
ACPI: bus type PCI registered
PCI: PCI BIOS revision 2.10 entry at 0xfd9b0, last bus=1
PCI: using configuration type 1
ACPI: subsystem revision 20050902
(hangs) |
It appears that this BIOS may well be old enough to have buggy "DSDT tables" ... which maybe could be replaced (http://acpi.sourceforge.net) but here's the catch-22... it seems that you have to be able to boot with ACPI support enabled in order to get far enough to replace those tables! And no one seems to have already done this for this particular model.
Browsing the source-tree, it looks like it's hanging up in the firmware_register() call in "drivers/acpi/bus.c" because the subsequent messages generated in that module do not appear. |
|
| Back to top |
|
 |
sundialsvc4
Guru
Joined: 10 Nov 2005
Posts: 436
|
| Posted: Wed Feb 22, 2006 9:43 pm Post subject: |
|
|
Followup: with ACPI debugging messages enabled in the kernel, the boot gets a little farther (still hangs). Excerpted messages follow: | Code: | evgpeblk-0988 [06] ev_create_gpe_block : GPE 00 to 0F (_GPE) 2 regs on int 0x09
evgpeblk-0996 [06] ev_create_gpe_blk : Found 5 Wake, Enabled 0 Runtime GPEs in this block.
.. same msg .. GPE 10 to 1F (_GPE) 2 regs on int 0x09
.. same msg .. Found 1 Wake, Enabled 0 Runtime GPEs
Completing Region/Field/Buffer/Package Initialization (about 70 dots)...
Initialized 18/18 Regions, 5/5 Fields, 23/23 Buffers,19/28 Packages (555 Nodes)
Executing all device _STA and_INI methods (14 dots)
(hang) |
So I conclude that it's falling into an endless-loop at this point. I presume it's the fifteenth entry encountered while walking a namespace ... whatever that is!
Once again, I can easily "grok" that this could be a problem with the information table -- but if the driver completely dies while parsing it, how can I possibly get far enough along to be able to replace it?
All I really want to do ... all that I want to do ... is to boot this computer with ACPI running, even if it is not running perfectly. Until I can do that, apparently I have no way to extract the errant bit of software and supersede it. |
|
| Back to top |
|
|
sundialsvc4
Guru
Joined: 10 Nov 2005
Posts: 436
|
| Posted: Fri Feb 24, 2006 6:57 pm Post subject: |
|
|
Well, I found one of the various variants of the acpdump command (interestingly, I did not find that in Gentoo .. did I miss it?) which seems to be able to extract and disassemble the RSDT table. And I found Intel's iasl tool, which seems to be able to understand it and to compile it. And... the compiler found one error in what it produced ...
To be continued ... |
|
| Back to top |
|
|
sundialsvc4
Guru
Joined: 10 Nov 2005
Posts: 436
|
| Posted: Sat Feb 25, 2006 3:10 am Post subject: Help, anyone? |
|
|
With much slogging, I have been able to determine that the game seems to grind to a halt in ...
SB_.PCI0.HUB_.CRD0._INI
In that bit of code I see ...
Method(_INI) {
Store(Zero, CDE0)
Store(Zero, CD04)
Store(Zero, CD3E)
Store(Zero, CD46)
Store(One, CD44)
If(LEqual(CKOS(), 0x0)) {
Store(Zero, CDE1)
}
... and it seems to me that "Store(Zero, CD04)" is specifically where it dies. It goes to "pci_config_space_handler" and never comes home.
What's really wierd about this is that, for some time thereafter, I see flickers of hard-disk-drive activity. As though some part of the system was continuing to run. But I have no idea what is really going on here.
I cleaned-up one small bug in the DSDT table (once I finally extracted it) and what I got seems to be sensible. I then put it into the kernel and I think that it's being used. (It's rather hard to be 100% sure, because all that I have to go by is "whatever's left on the terminal-mode screen when the whole thing freezes.")
Can anyone step forward and assist? |
|
| Back to top |
|
|
sundialsvc4
Guru
Joined: 10 Nov 2005
Posts: 436
|
| Posted: Mon Feb 27, 2006 4:20 pm Post subject: Closer.. coming closer.. nearly there... |
|
|
Here's the latest ...
Through various and sundry twiddlings of the acpi_dbg_level kernel parameter (with appropriate debugging support enabled in the kernel-config), I have narrowed the problem down to a single statement in _SB_.PCI0.HUB_.CRD0_.INI ... and that statement seems to be Move Zeroes,CD04.
The situation appears to be something that is known ... the LCD screen freezes and the computer continues to boot (which is why the disk-drive activity, and why Ctrl+Alt+Del caused a reboot). If I had the means to build a new flash ROM image for the machine, apparently I could fix it, but I have neither Windows nor a floppy-disk drive. (Nor do I miss them... but if anyone knows another way to flash the ROM ...) 
So, I said to myself, what the heck ... what would happen if I commented that statement out?
I tried it. Commented out the statement in the DSDT-table image, rebuilt the kernel, and ... it booted. With ACPI! And furthermore, ACPI appears to work. I put in the wireless-card and the cardmgr recognized that something had been inserted. A lot of the power-management features that did not work before, now do so.
If I manage to pull this thing out, I'll be sure to write a nice HOWTO. |
|
| Back to top |
|
|
sundialsvc4
Guru
Joined: 10 Nov 2005
Posts: 436
|
| Posted: Mon Feb 27, 2006 8:46 pm Post subject: |
|
|
Okay, it's time for me to write that HOWTO. 
To summarize ...
(1) What I am encountering is a known problem with early BIOSes on this model ... but I have no way to re-flash the BIOS because I have neither Windows nor a floppy-drive.
(2) The problem manifests where the machine display would freeze-up during initialization. The system would actually continue to boot ... uselessly.
(3) Since I could not boot up far enough to get access to /proc/acpi, I managed to find the pacpidump utility which could, as root, extract the "DSDT" information. And I found the Intel iasl compiler, which could rebuild it. (afaik, Gentoo didn't have an "emerge" for either of these things.) Also note that not all "acpidump" utilities are the same ... you need to find one that can generate DSDT source-code.
(4) Although iasl found one small error in the DSDT, that didn't fix the problem. After compiling Linux with the replacement DSDT table information, I also compiled-in the DSDT debugging facilities and became very familiar with the acpi_dbg_level parameter. All of my debugging had to rely upon what could be seen on the character mode display!
(5) I was able to trace it down to "_SB_PCI0.HUB_.CRD0._INI" and, with more debugging, to the instruction "Store Zeroes,CD04." Not having anything else to try, I commented-out that statement. Magically, the machine now booted successfully with ACPI.
===
(6) As others already know, the card itself (D-Link DWL-G650, hardware version B5, firmware version 2.54) worked just fine with the "madwifi" drivers. I've been running it all day with nary a hiccup. (From the card, that is...  ... I am celebrating a bit. ) |
|
| Back to top |
|
|
sundialsvc4
Guru
Joined: 10 Nov 2005
Posts: 436
|
| Posted: Thu Sep 11, 2008 4:32 am Post subject: |
|
|
Someone inquired about this "blast from my past." I have no recollection now of whatever bit-twiddling magic I obviously did remember "back then."
I guess that is why I am not a hardware engineer . . .
I do see that the Linux configuration for this (still going...) laptop has the following parameters included:
| Code: | CONFIG_ACPI_CUSTOM_DSDT=y
CONFIG_ACPI_CUSTOM_DSDT_FILE="/usr/local/src/linux-blah/dsdt_table.h"
|
So, obviously, I must have figured out a way to capture the information from the ROM, decompile it, tweak it, and rebuild it for inclusion in the kernel ... which uses this version of the information in preference to the (flaky...) version in ROM.
It's coming back to me now ... this file is "a description of the hardware of this computer," and this was a case where the standard was being devised, and was summarily disobeyed by Microsoft, at the same time companies like Sony were trying to sell laptops to people like me. Linux's interpretation of the data is "strict and accurate," and so it falls-down where Windows OSes (of the same hardware era...) did not.
But it's "Ol' Dobbin," and it's still going. . . ("Psst! Wanna buy a laptop? 'Slightly' used...") |
|
| Back to top |
|
|
|
|
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
|
|
Kernel & Hardware
