Haiku stops booting at allocate_commpage_entry(4, 34)

[euan]

Only started happening in the last week or so. Harddisk light remains on.

Hardware AMD Athlon X2 3800+ ASUS A8R-MVP AMD / ALI chipset 2GB RAM PowerColor Radeon HD 2600XD

Last lines of syslog:

KDiskSystem::Unload(): file_systems/iso9660/v1 -> 0 KDiskSystem::Load(): file_systems/nfs/v1 -> 1

trying: file_systems/nfs/v1 returned: -1000/1000

KDiskSystem::Unload(): file_systems/nfs/v1 -> 0 allocate_commpage_entry(4, 34) -> 0xffff0118

[euan]

Euan's X2 Syslog file (several boots with various boot options set)

[bonefish]

It would be nice to know where exactly the kernel hangs. If you can enter the kernel debugger (F12, PS/2 keyboard needed), please print a stack trace of the "main2" thread. You can look up it's ID in the listing produced by the command "threads" (probably 7) and pass it as argument to "sc".

[euan]

Hi,

Unfortunately the debugger is initialised on what would be the next line, so isn't ready (or doesn't work).

When I first booted with the PS2 keyboard connected, it past the line at fault with no problem, next line reads: "kernel debugger extention "debugger/hangman/v1": loaded". However it then locked up on the line after "starting EHCI Host Controller", again, the debugger could not be invoked. Disconnecting the usb devices still results in same hang. Trying other combinations as we speak.

Perhaps we can move the debugger init earlier just to test?

[euan]

Update: Disabling USB in the bios, allows the OS to boot.

[bonefish]

Replying to euan:

Unfortunately the debugger is initialised on what would be the next line, so isn't ready (or doesn't work).

[...]

Perhaps we can move the debugger init earlier just to test?

Not sure what you mean by that. The kernel debugger is fully initialized shortly after the VM. The output "allocate_commpage_entry(4, 34)..." originates from a call from cpu_init_post_modules() which rather late in the boot process. There are only a few more initializations before the kernel is fully initialized and the boot script is started.

Replying to euan:

Update: Disabling USB in the bios, allows the OS to boot.

That suggests it is USB related. Assigning to mmlr. Maybe he has an idea.

[euan]

I added some addtional logging:

Adding this to the syslog:

INIT: CPU init

allocate_commpage_entry(4, 34) -> 0xffff0118

INIT: VM init

INIT: debug init

register kernel daemon locking

register kernel daemon locked

register kernel daemon unlocking

register kernel daemon unlocked

syslog init post threads

syslog init post threads create sem

syslog init post threads create sem ok

syslog init post threads spawn thread

syslog init post threads spawn thread ok

open module list

The last line is from /kernel/debug.cpp:

status_t debug_init_post_modules(struct kernel_args *args) {

void *cookie;

// check for dupped lines every 10/10 second register_kernel_daemon(check_pending_repeats, NULL, 10);

dprintf("syslog init post threads\n"); syslog_init_post_threads();

// load kernel debugger addons dprintf("open module list\n"); cookie = open_module_list("debugger");

[euan]

hopefully fixed in #1723 will know tomorrow.

[euan]

no change tested with mmlr's patches up to today's [23742] :(

[mmlr]

You can easily tell whether it's SMP related by disabling SMP from the boot menu and test if it works then. The open_module_list() function looks pretty uneventful to me, so I wouldn't know what should go wrong there, especially in relation to USB. You could also try to enter the debugger again (with F12) maybe it works now with SMP enabled after the changes in r23751. Then you can do a backtrace to find the exact location.

[euan]

disabling SMP makes no difference. Still to try the new changes. If they don't work. I'll try reverting back to older versions. I suspect it was just around BeGeistert when it stopped functioning.

[euan]

I tried revisions all the way back to December, and still not found the cause yet. Even if I delete the USB input drivers, all the USB bus manager and busses files it still won't start. Yet if I disable USB in the Bios it boots just fine.

[mmlr]

Then it is most probably related to USB legacy emulation. In case you remove all USB files, the stack and host controller driver obviously will not get loaded. In this case the controllers will stay in legacy emulation mode. Maybe the PS/2 bus manager has a problem in that case? You could try removing the PS/2 bus manager too and see if this makes any difference.

[korli]

Reproduced on a Core2Duo 3GB.

[korli]

It actually fails in vm_init_post_modules(), just after a call to x86_set_mtrr().

set_memory_type called with : id = -1, base = 0, length = bfee0000, type = 0x50000000 allocate MTRR slot 0, base = 0, length = 100000000

on Linux : cat /proc/mtrr reg00: base=0x00000000 ( 0MB), size=2048MB: write-back, count=1 reg01: base=0x80000000 (2048MB), size=1024MB: write-back, count=1 reg02: base=0xbff00000 (3071MB), size= 1MB: uncachable, count=1 reg03: base=0xd0000000 (3328MB), size= 256MB: write-combining, count=1

[korli]

This could be fixed in r24244.

[euan]

Here's my linux mtrrs for what it's worth.

reg00: base=0x00000000 ( 0MB), size=2048MB: write-back, count=1 reg01: base=0x80000000 (2048MB), size= 512MB: write-back, count=1

Doing a build at the moment will update in 15 mins.

[euan]

Sorry no change for me. :( Will try to get an updated syslog.

[euan]

Hmm seems that it now hangs in a part of the boot loading filesystems stuff. Can't be sure if it's another issue, or the same one...

[dustin howett]

Haiku fails to boot when i have 3GB of RAM in my system (128 is shared video ram), but works with 1 or 2 GB. Linux MTRRs:

reg00: base=0x00000000 (   0MB), size=2048MB: write-back, count=1
reg01: base=0x80000000 (2048MB), size= 512MB: write-back, count=1
reg02: base=0xa0000000 (2560MB), size= 128MB: write-back, count=1
reg03: base=0xc0000000 (3072MB), size= 128MB: write-combining, count=1

Haiku MTRRs:

0: base=0x00000000, size = 2048 MB.
1: base=0x80000000, size = 1024 MB.
2: base=0xc0000000, size = 1 MB.

(08:41:35 PM) DHowett: geist: Haiku's adds up to 3gb.. linux up to less than that but i take that to be related to my 128 mb shared video ram
(08:43:33 PM) geist: could be
(08:43:45 PM) geist: yeah, bet haiku is marking over the video ram as regular mem

[euan]

Ok so I managed to hook up my laptop and get a debug trace. Unfortunately the only difference is that it hangs one line before the original log. So the allocate_comm_page_entry line is never printed now.

So not fixed as yet. :(

[korli]

I would need additional information if it's possible : on Linux, you should find something about "BIOS-provided physical RAM map" in /var/log/messages, especially lines beginning with "BIOS-e820". Thanks.

[euan]

Darn I had that saved off to a file too for uploading. I won't be back home until Wednesday sorry.

[dustin howett]

At least for me, with 3 GB RAM -- assuming i'm having the same class of issue as euan...

BIOS-provided physical RAM map:
 BIOS-e820: 0000000000000000 - 000000000009dc00 (usable)
 BIOS-e820: 000000000009dc00 - 00000000000a0000 (reserved)
 BIOS-e820: 00000000000d2000 - 0000000000100000 (reserved)
 BIOS-e820: 0000000000100000 - 00000000a7f00000 (usable)
 BIOS-e820: 00000000a7f00000 - 00000000a7f15000 (ACPI data)
 BIOS-e820: 00000000a7f15000 - 00000000a7f80000 (ACPI NVS)
 BIOS-e820: 00000000a7f80000 - 00000000b0000000 (reserved)
 BIOS-e820: 00000000e0000000 - 00000000f0000000 (reserved)
 BIOS-e820: 00000000fec00000 - 00000000fec10000 (reserved)
 BIOS-e820: 00000000fee00000 - 00000000fee01000 (reserved)
 BIOS-e820: 00000000fff80000 - 0000000100000000 (reserved)
 BIOS-e820: 0000000100000000 - 0000000110000000 (usable)

[euan]

BIOS-provided physical RAM map:

BIOS-e820: 0000000000000000 - 000000000009fc00 (usable) BIOS-e820: 000000000009fc00 - 00000000000a0000 (reserved) BIOS-e820: 00000000000e0000 - 0000000000100000 (reserved) BIOS-e820: 0000000000100000 - 000000009ffb0000 (usable) BIOS-e820: 000000009ffb0000 - 000000009ffbe000 (ACPI data) BIOS-e820: 000000009ffbe000 - 000000009ffe0000 (ACPI NVS) BIOS-e820: 000000009ffe0000 - 00000000a0000000 (reserved) BIOS-e820: 00000000ff780000 - 0000000100000000 (reserved)

[ddew]

I also have that issue with 5GB RAM. Posting my MTRR and RAM map:

Mar 14 17:17:53 workstation kernel: [    0.000000] BIOS-provided physical RAM map:
Mar 14 17:17:53 workstation kernel: [    0.000000]  BIOS-e820: 0000000000000000 - 000000000009e800 (usable)
Mar 14 17:17:53 workstation kernel: [    0.000000]  BIOS-e820: 000000000009f800 - 00000000000a0000 (reserved)
Mar 14 17:17:53 workstation kernel: [    0.000000]  BIOS-e820: 00000000000f0000 - 0000000000100000 (reserved)
Mar 14 17:17:53 workstation kernel: [    0.000000]  BIOS-e820: 0000000000100000 - 00000000dfee0000 (usable)
Mar 14 17:17:53 workstation kernel: [    0.000000]  BIOS-e820: 00000000dfee0000 - 00000000dfee3000 (ACPI NVS)
Mar 14 17:17:53 workstation kernel: [    0.000000]  BIOS-e820: 00000000dfee3000 - 00000000dfef0000 (ACPI data)
Mar 14 17:17:53 workstation kernel: [    0.000000]  BIOS-e820: 00000000dfef0000 - 00000000dff00000 (reserved)
Mar 14 17:17:53 workstation kernel: [    0.000000]  BIOS-e820: 00000000f0000000 - 00000000f4000000 (reserved)
Mar 14 17:17:53 workstation kernel: [    0.000000]  BIOS-e820: 00000000fec00000 - 0000000100000000 (reserved)
Mar 14 17:17:53 workstation kernel: [    0.000000]  BIOS-e820: 0000000100000000 - 0000000160000000 (usable)

reg00: base=0x00000000 (   0MB), size=4096MB: write-back, count=1
reg01: base=0xe0000000 (3584MB), size= 512MB: uncachable, count=1
reg02: base=0x100000000 (4096MB), size=2048MB: write-back, count=1
reg03: base=0x160000000 (5632MB), size= 512MB: uncachable, count=1
reg04: base=0xdff00000 (3583MB), size=   1MB: uncachable, count=1

[dustin howett]

r24424 fixed it for me.

[euan]

Still no change for me (as of r24424)

[euan]

no hold that thought I see differences between the build on my laptop and desktop, even though they are at the same revision. Something must be wrong with my desktop svn repos. I'll wipe it and rebuild from scratch tomorrow...

[euan]

Everything works now. It was probably fixed for me on the first mtrr change. Sadly my svn repos was a bit knackered. I only noticed when the new boot splash logos didn't appear...

Thanks very much for the fix.

[korli]

Thank both of you for your feedback. Fixed in r24424.

[ddew]

Sadly the fix didn't work for me on 5GB, it gets further in the boot process but still refuses to boot properly.

[ddew]

Here are the relevant lines from the debug log, i had to type it in manually from a photo taken off the screen so I've omitted the lines showing what's being loaded. Last loaded debugger extension is hangman. .

set_memory_write_back base 0 length dfee0000
find_nearest dfee0000 0
find_nearest 5fee0000 1
find_nearest 1fee0000 2
find_nearest fee0000 3
find_nearest 7ee000 4
find_nearest 120000 4
find_nearest 120000 3
find_nearest 20120000 2
find_nearest 120000 3
find_nearest 1fee0000 3
find_nearest 20120000 1
find_nearest 120000 2
find_nearest 1fee0000 2
sols: 0xffffffff00000000 0x20000000 0x100000
allocate MTRR slot 0, base = 0, length = 1000
allocate MTRR slot 1, base = e00000000, length = 20000000
allocate MTRR slot 2, base = dff00000, length = 100000
allocate MTRR slot 3, base = e0000000, length = 800000
ahci: ExecuteAtaRequest port 0: device transfer timeout
ahci: sata_request::abort called for command 0x25

The last two lines just keeps on repeating until, after a few minutes, the screen goes black and it hangs when the desktop is normally drawn.

[jackburton]

Replying to ddew:

ahci: ExecuteAtaRequest port 0: device transfer timeout ahci: sata_request::abort called for command 0x25 }}}

This isn't related at all, looks like a problem with the IDE stack/SATA driver. This shows that the original bug is fixed, though, since the boot process goes on.

[korli]

Replying to jackburton:

ahci: ExecuteAtaRequest port 0: device transfer timeout ahci: sata_request::abort called for command 0x25 }}}

This isn't related at all, looks like a problem with the IDE stack/SATA driver. This shows that the original bug is fixed, though, since the boot process goes on.

No, I had the same behavior when setting the memory to write back, I/O requests are then stalled because the PCI bus is not refreshed. Though I'm wondering if Haiku is supposed to work with 5GB.

[ddew]

Replying to korli:

Replying to jackburton:

ahci: ExecuteAtaRequest port 0: device transfer timeout ahci: sata_request::abort called for command 0x25 }}}

This isn't related at all, looks like a problem with the IDE stack/SATA driver. This shows that the original bug is fixed, though, since the boot process goes on.

No, I had the same behavior when setting the memory to write back, I/O requests are then stalled because the PCI bus is not refreshed. Though I'm wondering if Haiku is supposed to work with 5GB.

I'm not picky about having all the RAM being seen and used by the os, having only 3.5gb showing up is acceptable. Although PAE-support would be nice I just want to be able to boot into Haiku without pulling out RAM from the machine.:)

[axeld]

How do the MTRR look like when booting Linux with those 5GB?

[korli]

Replying to axeld:

How do the MTRR look like when booting Linux with those 5GB?

See the comment 25 dated from 03/14/08 11:38:13

[jackburton]

Replying to ddew:

Though I'm wondering if Haiku is supposed to work with 5GB.

Looks like it works with 4GB at least...

http://www.biffuz.it/misc/haiku4gb.jpg

[korli]

Replying to ddew:

allocate MTRR slot 0, base = 0, length = 1000 allocate MTRR slot 1, base = e00000000, length = 20000000 allocate MTRR slot 2, base = dff00000, length = 100000 allocate MTRR slot 3, base = e0000000, length = 800000

The first line should have a length 0x100000000. Are you sure about it ?

[korli]

Could you test again with r24476 please ?

[ddew]

Tried r24479 and it just reboots the box when it starts setting up the MTRRs.

[korli]

Maybe it's not a good idea to have a MTRR uncached covering a MTRR write combining (the fourth one) ?

[korli]

Could you please check again with r24494 ?

[ddew]

Still won't boot. Now it resets right after allocating slot 0 judging from what I had time to see. The system resets during the allocation making hard to catch a glimpse of exactly what's being done and I don't have serial access to the machine.

[korli]

is this bug still valid ? (just asking)

[euan]

as the original reporter I believe this bug is generally resolved for the majority of systems.