Pagefault calling parsersdptr about harvey

[rminnich]

This is not enough information unfortunately.
What you need to do is get to a full boot and then
cp /dev/kmesg /usr/harvey
and then you'll have the kmesg file on your server (whatever system is running centre IOW) and can post it here.

But it's crashing! How can you boot?
Disable ACPI :-)

diff --git a/sys/src/9/amd64/devacpi.c b/sys/src/9/amd64/devacpi.c
index 0bffbca36..702fdad99 100644
--- a/sys/src/9/amd64/devacpi.c
+++ b/sys/src/9/amd64/devacpi.c
@@ -1631,6 +1631,7 @@ parsersdptr(void)
         * Search for the data structure signature:
         * 1) in the BIOS ROM between 0xE0000 and 0xFFFFF.
         */
+       return;
        rsd = rsdsearch(KADDR(0xE0000), 0x20000);
        if(rsd == nil){
                print("NO RSDP\n");

Let us know what you see then. I need to add a debug option so we can disable ACPI on boot.

[gmacd]

Hah, how did I not think of that :)

[gmacd]

Having run through by hand, we should end up with

0x0000000000000000-0x0000000000080000 (1:MEMORY)
0x0000000000080000-0x00000000000a0000 (10:KRDWR)
0x00000000000a0000-0x00000000000c0000 (6:DEV)
0x00000000000c0000-0x0000000000100000 (6:KRDONLY)
0x0000000000100000-0x0000000000101000 (1:MEMORY)
0x0000000000101000-0x0000000000200000 (10:KRDWR)
0x0000000000200000-0x0000000000400000 (8:KTEXT)
0x0000000000400000-0x0000000000600000 (6:KRDONLY)
0x0000000000600000-0x0000000012400000 (10:KRDWR)
0x0000000012400000-0x000000007ec6d000 (1:MEMORY)  (<--- 0x50000000 more than we get with current code)
0x000000007ecb8000-0x000000007ecf9000 (1:MEMORY)
0x000000007f382000-0x0000000085885000 (1:MEMORY)
0x0000000087fff000-0x0000000088000000 (1:MEMORY)
0x0000000100000000-0x0000000476800000 (1:MEMORY)

But we don't. We seem to have lost 0x50000000 probably when merging nodes.

This happens in the last pamapinsert, which:

• frees up space in a memory node
• merges with the previous node, since it's contiguous and of the same type

[gmacd]

Here's the test that didn't replicate the bug:

int main(int argc, char const *argv[])
{
	printf("testing pamap\n");

	pamapinsert(0x0000000000000000, 0x9C800, PamMEMORY);
	pamapinsert(0x0000000000100000, 0x7EB6D000, PamMEMORY);
	pamapinsert(0x000000007ecb8000, 0x41000, PamMEMORY);
	pamapinsert(0x000000007f382000, 0x6503000, PamMEMORY);
	pamapinsert(0x0000000087FFF000, 0x1000, PamMEMORY);
	pamapinsert(0x0000000100000000, 0x376800000, PamMEMORY);

	printf("before merge\n");
	pamapdump();

	// merge
	pamapinsert(0x0000000000080000, 0x20000, PamKRDWR);
	pamapinsert(0x00000000000a0000, 0x20000, PamDEV);
	pamapinsert(0x00000000000c0000, 0x30000, PamKRDONLY);
	pamapinsert(0x00000000000f0000, 0x10000, PamKRDONLY);
	pamapinsert(0x0000000000101000, 0xFF000, PamKRDWR);
	pamapinsert(0x0000000000200000, 0x200000, PamKTEXT);
	pamapinsert(0x0000000000400000, 0x200000, PamKRDONLY);
	pamapinsert(0x0000000000600000, 0x6B3018, PamKRDWR);
	pamapinsert(0x0000000000cb3018, 0x1174CFE8, PamKRDWR);

	printf("after merge\n");
	pamapdump();

	printf("done testing pamap\n");
	return 0;
}

[dancrossnyc]

It's kind of weird that it is being treated as type "memory". I'd expected KRDONLY or something. I wonder if it's actually being mapped, but is being zeroed or something before the ACPI data is actually read.

We should, perhaps, read the ACPI data and squirrel it away before tearing down the original memory map.

[gmacd]

So it's an indirect problem. Closing.

(Here's the story)

I've been having problems netbooting the machine I'm trying to test with. It worked in the past (several months ago), by changing to legacy mode, but not now.

So I copied ipxe to a USB stick and was able to boot with that. It was a big annoying though - it would only try to boot after the bios tried to netboot for about a minute or two and timed out. No fiddling with bios settings to get around this. I don't remember it being a problem last time.

(I'm using centre btw)

Looking in wireshark, I saw a ProxyDHCP packet and a message on my client PC saying 'ProxyDHCP did not reply to request on port 4011'.Googling that, I see 'This problem can occur when the DHCP Class Identifier Option 60 is set on the DHCP server, but there is no proxyDHCP service running on port 4011 on the same machine.'

I remembered @fhs had made a change to centre recently, saying that a change I'd made had stopped it booting on his thinkpad. The change I'd made was to specify option 60 as 'PXEClient'.

Updating centre, it now netboots immediately, without needing ipxe on the USB stick.So that's that problem solved, but it also seems to have solved the pamap problem....

Harvey now boots up fully, with a much larger set of physical memory regions (including acpi regions) picked up by multiboot.

So somehow netbooting this machine via ipxe on a stick means multiboot doesn't pick up most of the regions.

So the root cause for the page fault when trying to setup acpi, was a misconfiguration in the DHCP settings in centre.