Skip to contentSkip to conversation

PaceBlade broken acpi/memory map

DISCUSSION Pavel Machek 4 participants 10 messages Feb 20, 2003 – Feb 26, 2003 ACPI

lore
Share & tools
lore

Pavel Machek

author
#0 lore raw

Hi!

I have PaceBlade here, and its memory map is wrong, which leads to ACPI refusing to load. [It does not mention "ACPI data" in the memory map at all!]

And when I work around that, it crashes in processing _STA/_INI methods. [Anyone from PaceBlade listening?]

Pavel

Signature · 2 lines
When do you have a heart between your knees?
[Johanka's followup: and *two* hearts?]
#1 lore raw
Quoted 5 lines · Pavel Machek

Hi!

I have PaceBlade here, and its memory map is wrong, which leads to ACPI refusing to load. [It does not mention "ACPI data" in the memory map at all!]

I have made those patches to workaround that. I have no time to rediff it though (sorry), but it is easy to get it. I also CC to Robert Woerle because he has already send a PR to the bios mainteners.

Quoted 3 lines

And when I work around that, it crashes in processing _STA/_INI methods. [Anyone from PaceBlade listening?]

Don't know what happens: I have no paceblade and it sound like it is OK for Robert ?

this one is bad. Only here in order to get the second diff apply cleanly.

arch/i386/kernel/setup.c +6 -0
@@ -546,6 +546,12 @@
 	if (*pnr_map < 2)
 		return -1;
 
+	biosmap[(int) *pnr_map].addr = 0x0eef0000;
+	biosmap[(int) *pnr_map].size = 53248;
+	biosmap[(int) *pnr_map].type = E820_ACPI;
+	(*pnr_map)++;
+
+	
 	old_nr = *pnr_map;
 
 	/* bail out if we find any unreasonable addresses in bios map */

This one is the good one. Need to be rediffed correctly, or to be changed for 2.5.

arch/i386/kernel/setup.c +37 -0
@@ -546,10 +546,47 @@
 	if (*pnr_map < 2)
 		return -1;
 
+	/*
+	 * For broken BIOS which do not declare an ACPI DATA properly,
+	 * even though ACPI NVS are here, we try to declare the 64ko as
+	 * ACPI DATA (and hope it will work).
+	 */
+	do {
+		int i;
+		int seen = 0;
+		struct e820entry new_entry;
+
+		old_nr = *pnr_map;
+		memset(&new_entry, 0, sizeof (new_entry));
+
+		for (i = 0; i < old_nr; i++) {
+			switch (biosmap[i].type) {
+			case E820_ACPI:
+				seen = 1;
+				break;
+			case E820_NVS:
+				new_entry.addr = biosmap[i].addr - 0x10000;
+				new_entry.size = 0x10000;
+				new_entry.type = E820_ACPI;
+				break;
+			default:
+				break;
+			}
+		}
+		if (!seen && new_entry.type == E820_ACPI) {
+			printk(KERN_WARNING "setup: found a ACPI NV region, but no ACPI DATA.  Trying to mark\n");
+			printk(KERN_WARNING "setup: %016Lx of size %016Lx as ACPI DATA.\n", new_entry.addr, new_entry.size);
+			memcpy(&biosmap[(int) *pnr_map], &new_entry, sizeof(new_entry));
+			(*pnr_map)++;
+		}
+	} while (0);
+
+#if 0
 	biosmap[(int) *pnr_map].addr = 0x0eef0000;
 	biosmap[(int) *pnr_map].size = 53248;
 	biosmap[(int) *pnr_map].type = E820_ACPI;
 	(*pnr_map)++;
+#endif
 
 	
 	old_nr = *pnr_map;

It is much better to kill the lines in #if 0 ... #endif of course.

Cheers,

Signature · 4 lines
Ducrot Bruno

--  Which is worse:  ignorance or apathy?
--  Don't know.  Don't care.
author
#2 lore raw

Hi!

Quoted 5 lines
Quoted 3 lines

I have PaceBlade here, and its memory map is wrong, which leads to ACPI refusing to load. [It does not mention "ACPI data" in the memory map at all!]

I have made those patches to workaround that. I have no time

Yes, I have seen those... I also made a patch that enables you to do that workaround from mem= options at kernel command line.

Pavel

Signature · 2 lines
Horseback riding is like software...
...vgf orggre jura vgf serr.
#3 lore raw
Quoted 11 lines · Pavel Machek

Hi!

Quoted 5 lines
Quoted 3 lines

I have PaceBlade here, and its memory map is wrong, which leads to ACPI refusing to load. [It does not mention "ACPI data" in the memory map at all!]

I have made those patches to workaround that. I have no time

Yes, I have seen those... I also made a patch that enables you to do that workaround from mem= options at kernel command line.

I doubt you received the latest one, since I have not make it public unless this day.

Signature · 4 lines
Ducrot Bruno

--  Which is worse:  ignorance or apathy?
--  Don't know.  Don't care.
#4 lore raw
Quoted 15 lines · Ducrot Bruno
Quoted 12 lines · Pavel Machek

Hi!

Quoted 8 lines
Quoted 5 lines

I have PaceBlade here, and its memory map is wrong, which leads to ACPI refusing to load. [It does not mention "ACPI data" in the memory map at all!]

I have made those patches to workaround that. I have no time

Quoted 10 lines
Quoted 5 lines

Yes, I have seen those... I also made a patch that enables you to do that workaround from mem= options at kernel command line.

I doubt you received the latest one, since I have not make it public unless this day.

i did sent it to him since he recieved our machine from Suse Nuernberg

Quoted 2 lines
#5 lore raw
Quoted 25 lines · Robert
Quoted 21 lines · Ducrot Bruno
Quoted 17 lines · Pavel Machek

Hi!

Quoted 8 lines
Quoted 5 lines

I have PaceBlade here, and its memory map is wrong, which leads to ACPI refusing to load. [It does not mention "ACPI data" in the memory map at all!]

I have made those patches to workaround that. I have no time

Yes, I have seen those... I also made a patch that enables you to do that workaround from mem= options at kernel command line.

Quoted 6 lines
Quoted 4 lines

I doubt you received the latest one, since I have not make it public unless this day.

i did sent it to him since he recieved our machine from Suse Nuernberg

Ah, OK. Wasn't aware of that. But why then making a mem= opitons in that case. I have take care to *not* use any mem= at all because that can make things worse.

Signature · 4 lines
Ducrot Bruno

--  Which is worse:  ignorance or apathy?
--  Don't know.  Don't care.
#6 lore raw

Hi!

Quoted 18 lines
Quoted 18 lines
Quoted 18 lines
Quoted 5 lines
Quoted 5 lines
Quoted 5 lines

I have PaceBlade here, and its memory map is wrong, which leads to ACPI refusing to load. [It does not mention "ACPI data" in the memory map at all!]

Quoted 8 lines
Quoted 3 lines

I have made those patches to workaround that. I have no time

Yes, I have seen those... I also made a patch that enables you to do that workaround from mem= options at kernel command line.

I doubt you received the latest one, since I have not make it public unless this day.

Quoted 6 lines
Quoted 2 lines

i did sent it to him since he recieved our machine from Suse Nuernberg

Ah, OK. Wasn't aware of that. But why then making a mem= opitons in that case. I have take care to *not* use any mem= at all because that can make things worse.

I've received it after I made my patch, and I think that more machine with broken tables will be created in future...

Pavel

Signature · 2 lines
Horseback riding is like software...
...vgf orggre jura vgf serr.
#7 lore raw

Hi Pavel,

Quoted 4 lines · Pavel Machek

I've received it after I made my patch, and I think that more machine with broken tables will be created in future...

That it not the answer I expected. To be more clear: you report errors on _STA and _INI. I don't know why. But with my previous patch, it seems that there is no such errors (but it is with 2.4).
And one of the suspect(s) for what I know is your mem= option patch.

Signature · 4 lines
Ducrot Bruno

--  Which is worse:  ignorance or apathy?
--  Don't know.  Don't care.
#8 lore raw
Quoted 4 lines · Ducrot Bruno

Hi Pavel,

Quoted 1 line · Pavel Machek
Quoted 8 lines
Quoted 3 lines

I've received it after I made my patch, and I think that more machine with broken tables will be created in future...

That it not the answer I expected. To be more clear: you report errors on _STA and _INI. I don't know why. But with my previous patch, it seems that there is no such errors (but it is with 2.4).
And one of the suspect(s) for what I know is your mem= option patch.

Ok. Found your patch in LKML. Soon like to be OK. Will see then what hapens, but I need your dmesg.

Cheers,

Signature · 4 lines
Ducrot Bruno

--  Which is worse:  ignorance or apathy?
--  Don't know.  Don't care.
#9 lore raw

Hi!

Quoted 11 lines
Quoted 8 lines
Quoted 3 lines

I've received it after I made my patch, and I think that more machine with broken tables will be created in future...

That it not the answer I expected. To be more clear: you report errors on _STA and _INI. I don't know why. But with my previous patch, it seems that there is no such errors (but it is with 2.4).
And one of the suspect(s) for what I know is your mem= option patch.

Ok. Found your patch in LKML. Soon like to be OK. Will see then what hapens, but I need your dmesg.

Sorry, I no longer have access to that machine :-(.
Pavel

Signature · 2 lines
Horseback riding is like software...
...vgf orggre jura vgf serr.