ron minnich wrote:
Ah,the A5 BSOD, the bane of my life.
This is an ACPI issue.
That last paramter, 494e495f, is a *CLUE*. It is ASCII. It is _INI. No idea if that helps.
There is more info available ... just google Windows A5 Stop.
thanks
ron
Excerpt from KB 314830 [1]:
(0x00000003, Parameter2, Parameter3, Parameter4):
This error is defined as "ACPI failed must succeed method." This error occurs if ACPI cannot build a control method to reference the ACPI namespace. Other arguments for this error reference the ACPI object that was being run and the name of the control method. One greatly simplified explanation (which might not be completely accurate) is that the system cannot find a way to get to the ACPI tables that define the Plug and Play and Power Management capabilities of the system.
[1] http://support.microsoft.com/kb/314830/en-us
Sebastian
Hi,
It looks I've found the root of the problem This piece of code in pciinit.c may cause overlap of RAM and pci64 resource window.
pcimem64_start = (RamSizeOver4G + pcimem64_size) & ~(pcimem64_size-1);
Here is a part of the log showing the problem
..................
Find memory size Ram Size=0xe0000000 (0x0000000120000000 high)
..........................
Found 9 PCI devices (max PCI bus is 00) === PCI new allocation pass #1 === PCI: check devices === PCI new allocation pass #2 === RAM OVER 4GB: 0x120000000 pcimem64 size: 0x100000000 pcimem64_start 0x200000000 pcimem64_end: 0x300000000 PCI: map device bdf=00:04.0 bar 2, addr 200000000, size 10000000 [prefmem] PCI: map device bdf=00:05.0 bar 2, addr 210000000, size 10000000 [prefmem] PCI: map device bdf=00:01.2 bar 4, addr 0000c000, size 00000020 [io]
I guess it would be proper if pcimem64_start will be set in this way: pcimem64_start = ALIGN(0x100000000LL + RamSizeOver4G, pcimem64_size);
The patch 6/6 with the fix is attached...
P/S : While debugging of this issue I've noticed yet another possible problem. I've added a debug output of P(S|L|E)32 and P(S|L|E)64 registers to acpi-dsdt.dsl file In case of static allocation of _CRS method (an old way) we have: PS32: 0xE0000000 PE32: 0xFEBFFFFF PL32: 0x1EC00000 PS64: 0x00,0x00,0x00,0x00,0x80,0x00,0x00,0x00 PE64: 0xFF,0xFF,0xFF,0xFF,0xFF,0x00,0x00,0x00 PL64: 0x00,0x00,0x00,0x00,0x80,0x00,0x00,0x00
In case of dynamic allocation of _CRS method (a new way) we have:
PS32: 0xE0000000 PE32: 0xFEBFFFFF PL32: 0x1EBFFFFF PS64: 0x00,0x00,0x00,0x00,0x02,0x00,0x00,0x00 PE64: 0xFF,0xFF,0xFF,0xFF,0x02,0x00,0x00,0x00 PL64: 0xFF,0xFF,0xFF,0xFF,0x00,0x00,0x00,0x00
Probably the correct value of the length of the PCI resource window should be set as len = pcimem_end - pcimem_start?
In new implementation it is:
+ pcimem[0] = pcimem_start; + pcimem[1] = pcimem_end - 1; + pcimem[2] = pcimem_end - pcimem_start - 1; + pcimem[3] = pcimem64_start; + pcimem[4] = pcimem64_end - 1; + pcimem[5] = pcimem64_end - pcimem64_start - 1;
Hi,
pcimem64_start = (RamSizeOver4G + pcimem64_size) & ~(pcimem64_size-1);
I guess it would be proper if pcimem64_start will be set in this way: pcimem64_start = ALIGN(0x100000000LL + RamSizeOver4G, pcimem64_size);
Indeed.
Probably the correct value of the length of the PCI resource window should be set as len = pcimem_end - pcimem_start?
Yes.
Updated patches pushed to git://git.kraxel.org/seabios pci64
cheers, Gerd
On 29/05/12 19:14, Gerd Hoffmann wrote:
Hi,
pcimem64_start = (RamSizeOver4G + pcimem64_size) & ~(pcimem64_size-1); I guess it would be proper if pcimem64_start will be set in this way: pcimem64_start = ALIGN(0x100000000LL + RamSizeOver4G, pcimem64_size);
Indeed.
Probably the correct value of the length of the PCI resource window should be set as len = pcimem_end - pcimem_start?
Yes.
Updated patches pushed to git://git.kraxel.org/seabios pci64
Thanks, the new version works fine.
Alexey
-
Alexey Korolev -
Gerd Hoffmann -
Sebastian Herbszt