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
--
When do you have a heart between your knees?
[Johanka's followup: and *two* hearts?]
On Thu, Feb 20, 2003 at 06:21:45PM +0100, Pavel Machek wrote:
> 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.
>
> 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.
--- linux-2.4.21-pre3-acpi-20030109-s4bios/arch/i386/kernel/setup.c 2003/01/22 12:37:35 1.1
+++ linux-2.4.21-pre3-acpi-20030109-s4bios/arch/i386/kernel/setup.c 2003/01/22 13:44:06
@@ -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.
--- linux-2.4.21-pre3-acpi-20030109-s4bios/arch/i386/kernel/setup.c 2003/01/27 13:46:37 1.2
+++ linux-2.4.21-pre3-acpi-20030109-s4bios/arch/i386/kernel/setup.c 2003/01/27 14:13:28
@@ -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,
--
Ducrot Bruno
-- Which is worse: ignorance or apathy?
-- Don't know. Don't care.
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
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
--
Horseback riding is like software...
...vgf orggre jura vgf serr.
On Mon, Feb 24, 2003 at 07:39:55PM +0100, Pavel Machek wrote:
> 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
>
> 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.
--
Ducrot Bruno
-- Which is worse: ignorance or apathy?
-- Don't know. Don't care.
Ducrot Bruno schrieb:
>On Mon, Feb 24, 2003 at 07:39:55PM +0100, Pavel Machek wrote:
>
>
>>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
>>>
>>>
>>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
>
>
On Tue, Feb 25, 2003 at 03:53:18PM +0100, Robert wrote:
>
>
> Ducrot Bruno schrieb:
>
> >On Mon, Feb 24, 2003 at 07:39:55PM +0100, Pavel Machek wrote:
> >
> >
> >>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
> >>>
> >>>
> >>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
>
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.
--
Ducrot Bruno
-- Which is worse: ignorance or apathy?
-- Don't know. Don't care.
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
> > >>>
> > >>>
> > >>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
> >
>
> 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
--
Horseback riding is like software...
...vgf orggre jura vgf serr.
Hi Pavel,
On Tue, Feb 25, 2003 at 06:44:49PM +0100, Pavel Machek wrote:
>
> 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.
--
Ducrot Bruno
-- Which is worse: ignorance or apathy?
-- Don't know. Don't care.
On Tue, Feb 25, 2003 at 09:09:07PM +0100, Ducrot Bruno wrote:
> Hi Pavel,
>
> On Tue, Feb 25, 2003 at 06:44:49PM +0100, Pavel Machek wrote:
> >
> > 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,
--
Ducrot Bruno
-- Which is worse: ignorance or apathy?
-- Don't know. Don't care.
Hi!
> > > 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
--
Horseback riding is like software...
...vgf orggre jura vgf serr.