Hi, I recently took delivery of a bunch of HP BL25p blades to add to my collection. I am attempting to install Centos4 x86_64 using PXE - the initial PXE DHCP stuff works, and the kernel and initrd are downloaded, but the server then immediately clears the screen and displays: "1706-Smart Array Controller Extended BIOS Data Area Memory Corrupted Array Controller Interrupt 14h BIOS Cannot Continue System Halted"
It's pretty obvious what the problem probably is (the kernel nukes some bit of memory that it shouldn't, or that the smart array hasn't properly marked as reserved), but I don't know what to do to fix it. I have also tried: 1) The i386 kernel and initrd images 2) The RedHat AS4 kernel/initrd images 3) The Centos3 i386 kernel and initrd images 4) Downgrading the System ROM BIOS and Smart Array BIOS (as shipped it had the latest versions) to versions up to a year old. 5) Playing with memmap to exclude mem from 610-640K from being used by the kernel.
Booting from CD works, but is suboptimal (I have to type the kernel kickstart options, and I don't want to have to do that 16 times, plus I want easy repeatability in future).
Google has been fairly silent on the issue. Does anyone have any suggestions for what else I could try/prod/poke?
Thanks,
Craig Miskell, Technical Support, AgResearch Invermay 03 489-9279 "The two rules for success: 1. Don't tell people everything you know." - Anon. Please accept my abject apologies for the awful mess of a legal disclaimer which follows. Not my choice ;-( ======================================================================= Attention: The information contained in this message and/or attachments from AgResearch Limited is intended only for the persons or entities to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipients is prohibited by AgResearch Limited. If you have received this message in error, please notify the sender immediately. =======================================================================
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Fri, Jun 09, 2006 at 12:25:16PM +1200, Miskell, Craig wrote:
- Playing with memmap to exclude mem from 610-640K from being used by
the kernel.
How about these kernel options ?
memmap=exactmap [KNL,IA-32] Enable setting of an exact E820 memory map, as specified by the user. Such memmap=exactmap lines can be constructed based on BIOS output or other requirements. See the memmap=nn@ss option description.
memmap=nn[KMG]$ss[KMG] [KNL,ACPI] Mark specific memory as reserved. Region of memory to be used, from ss to ss+nn.
- -- Rodrigo Barbosa "Quid quid Latine dictum sit, altum viditur" "Be excellent to each other ..." - Bill & Ted (Wyld Stallyns)
On Fri, Jun 09, 2006 at 12:25:16PM +1200, Miskell, Craig wrote:
- Playing with memmap to exclude mem from 610-640K from
being used by
the kernel.
How about these kernel options ?
memmap=exactmap [KNL,IA-32] Enable setting of an exact E820 memory map, as specified by the user. Such memmap=exactmap lines can beconstructed based on BIOS output or other requirements. See the memmap=nn@ss option description.
memmap=nn[KMG]$ss[KMG] [KNL,ACPI] Mark specific memory as reserved. Region of memory to be used, from ss to ss+nn.
I used memmap=3K$637K to avoid the 3K segment just below 640K (which my BIOS diagnostics told me was reserved), with no luck. I bumped that up to memmap=30K$610K (lots of padding), also without luck.
Similarly, I have tried: memmap=240M@16M (no luck) And mem=240M@16M ( no luck)
as there seems to be some varying opinions on the 'net as to which of those is correct syntax.
Of course, I might be wrong about the base cause in which case none of this is relevant ;-)
Ta, Craig ======================================================================= Attention: The information contained in this message and/or attachments from AgResearch Limited is intended only for the persons or entities to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipients is prohibited by AgResearch Limited. If you have received this message in error, please notify the sender immediately. =======================================================================
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Fri, Jun 09, 2006 at 01:53:34PM +1200, Miskell, Craig wrote:
On Fri, Jun 09, 2006 at 12:25:16PM +1200, Miskell, Craig wrote:
- Playing with memmap to exclude mem from 610-640K from
being used by
the kernel.
How about these kernel options ?
memmap=exactmap [KNL,IA-32] Enable setting of an exact E820 memory map, as specified by the user. Such memmap=exactmap lines can beconstructed based on BIOS output or other requirements. See the memmap=nn@ss option description.
memmap=nn[KMG]$ss[KMG] [KNL,ACPI] Mark specific memory as reserved. Region of memory to be used, from ss to ss+nn.I used memmap=3K$637K to avoid the 3K segment just below 640K (which my BIOS diagnostics told me was reserved), with no luck. I bumped that up to memmap=30K$610K (lots of padding), also without luck.
Similarly, I have tried: memmap=240M@16M (no luck) And mem=240M@16M ( no luck)
as there seems to be some varying opinions on the 'net as to which of those is correct syntax.
There are not varying opinions. Using @ (instead of $) is a valid syntax if you want to _force_ the kernel to use that region :)
Of course, I might be wrong about the base cause in which case none of this is relevant ;-)
Can't help you there :)
- -- Rodrigo Barbosa "Quid quid Latine dictum sit, altum viditur" "Be excellent to each other ..." - Bill & Ted (Wyld Stallyns)
-----BEGIN PGP SIGNED MESSAGE-----> On Fri, Jun 09, 2006 at 01:53:34PM
+1200, Miskell, Craig wrote:
On Fri, Jun 09, 2006 at 12:25:16PM +1200, Miskell, Craig wrote:
- Playing with memmap to exclude mem from 610-640K from
being used by
the kernel.
How about these kernel options ?
memmap=exactmap [KNL,IA-32] Enable setting of an exact E820 memory map, as specified by the user. Such memmap=exactmap lines can beconstructed based on BIOS output or other requirements. See the memmap=nn@ss option description.
memmap=nn[KMG]$ss[KMG] [KNL,ACPI] Mark specific memoryas reserved.
Region of memory to be used, fromss to ss+nn.
I used memmap=3K$637K to avoid the 3K segment just below
640K (which my
BIOS diagnostics told me was reserved), with no luck. I
bumped that up
to memmap=30K$610K (lots of padding), also without luck.
Similarly, I have tried: memmap=240M@16M (no luck) And mem=240M@16M ( no luck)
as there seems to be some varying opinions on the 'net as
to which of
those is correct syntax.
There are not varying opinions. Using @ (instead of $) is a valid syntax if you want to _force_ the kernel to use that region :)
Sorry, I meant "mem" vs "mmmap".
I also thought that @ meant *only* use the specified region, but in hindsight that is not quite right. If I now understand correctly, @ forces the kernel to use memory it would not otherwise, and $ forces it to ignore memory that it would otherwise use. Is that correct?
Craig ======================================================================= Attention: The information contained in this message and/or attachments from AgResearch Limited is intended only for the persons or entities to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipients is prohibited by AgResearch Limited. If you have received this message in error, please notify the sender immediately. =======================================================================
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Fri, Jun 09, 2006 at 02:14:59PM +1200, Miskell, Craig wrote:
I also thought that @ meant *only* use the specified region, but in hindsight that is not quite right. If I now understand correctly, @ forces the kernel to use memory it would not otherwise, and $ forces it to ignore memory that it would otherwise use. Is that correct?
Thats what I understand from reading the docs:
memmap=exactmap [KNL,IA-32] Enable setting of an exact E820 memory map, as specified by the user. Such memmap=exactmap lines can be constructed based on BIOS output or other requirements. See the memmap=nn@ss option description.
memmap=nn[KMG]@ss[KMG] [KNL] Force usage of a specific region of memory Region of memory to be used, from ss to ss+nn.
memmap=nn[KMG]#ss[KMG] [KNL,ACPI] Mark specific memory as ACPI data. Region of memory to be used, from ss to ss+nn.
memmap=nn[KMG]$ss[KMG] [KNL,ACPI] Mark specific memory as reserved. Region of memory to be used, from ss to ss+nn.
- -- Rodrigo Barbosa "Quid quid Latine dictum sit, altum viditur" "Be excellent to each other ..." - Bill & Ted (Wyld Stallyns)
Miskell, Craig spake the following on 6/8/2006 5:25 PM:
Hi, I recently took delivery of a bunch of HP BL25p blades to add to my collection. I am attempting to install Centos4 x86_64 using PXE - the initial PXE DHCP stuff works, and the kernel and initrd are downloaded, but the server then immediately clears the screen and displays: "1706-Smart Array Controller Extended BIOS Data Area Memory Corrupted Array Controller Interrupt 14h BIOS Cannot Continue System Halted"
It's pretty obvious what the problem probably is (the kernel nukes some bit of memory that it shouldn't, or that the smart array hasn't properly marked as reserved), but I don't know what to do to fix it. I have also tried:
- The i386 kernel and initrd images
- The RedHat AS4 kernel/initrd images
- The Centos3 i386 kernel and initrd images
- Downgrading the System ROM BIOS and Smart Array BIOS (as shipped it
had the latest versions) to versions up to a year old. 5) Playing with memmap to exclude mem from 610-640K from being used by the kernel.
Booting from CD works, but is suboptimal (I have to type the kernel kickstart options, and I don't want to have to do that 16 times, plus I want easy repeatability in future).
If you can't resolve this, make a custom boot cd with your kickstart file and the proper kernel options in it. It will at least get your hardware in service.
Booting from CD works, but is suboptimal (I have to type the kernel kickstart options, and I don't want to have to do that 16
times, plus I
want easy repeatability in future).
If you can't resolve this, make a custom boot cd with your kickstart file and the proper kernel options in it. It will at least get your hardware in service.
Ahh, good idea. Being blades I can use the ILO card to mount an iso file on a web-server somewhere as a "virtual" CD, so I can probably script the whole thing,
Ta, Craig ======================================================================= Attention: The information contained in this message and/or attachments from AgResearch Limited is intended only for the persons or entities to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipients is prohibited by AgResearch Limited. If you have received this message in error, please notify the sender immediately. =======================================================================
-
Miskell, Craig -
Rodrigo Barbosa -
Scott Silva