Haiku x86_64 built in Haiku x86_64 boots/crashes

[Luposian]

I am able to Jam Haiku x86_64 from within Haiku x86_64 and install the resulting Haiku.image file to my second partition. However, upon booting into that partition, the progress gets all the way to the rocket and then, a couple seconds later, crashes to the debugger or something. The image shows the end result. Something to do with the Vesa Accelerant seems to be involved, I think. But... why?

[Luposian]

Haiku x86_64 boot crash

[xyzzy]

Can you post the syslog?

[Luposian]

How? After the error appears, when I press [Enter], I get a "Debugger" prompt. I can't get out of the Debugger, no matter what I've tried (I end up just pulling the power cord to start over), but not sure about the commands to do what, in Debugger. So, if you could tell me how to get around inside the Debugger, I'd be more than glad to help give you what assistance I can.

[xyzzy]

If you reset the machine the bootloader should be able to give you it, or if that doesn't work press Alt+SysRq+d to bring up the kernel debugger, type "syslog" there and take a photo of it (the last page of output will probably do).

[Luposian]

Ok, there is no reset button on the computer (Dell Inspiron 570) and... no PS/2 ports. While I CAN type at the Debugger prompt (it likes USB keyboards), as soon as I get to the Kernel Debugger prompt (as how you mentioned), I can no longer type ANYTHING (no USB keyboard support?).

Ctrl-Alt-Del, does NOT work in Debugger, so no way of "rebooting" that way. So... how do I get the Syslog output ye be looking for?

[umccullough]

Pretty sure in gdb you can still execute shell commands with something like "shell <command>"

So you should for example be able to "shell shutdown -r" or similar.

or even cat the syslog to the display.

I'm not sitting at a Haiku box to test that theory, though... sorry.

[Luposian]

How do I cat the syslog to the display? Can I type "help" at the Debugger? Funny, I couldn't think of anything but "reboot" and "restart", neither of which worked. Forgot about the command "shutdown". That's a unix-style command and one I rarely use, except in tinkering in Minix or other.

[Luposian]

I typed "save-report" at the Debugger prompt and it saved a file to the Desktop of that partition, but the file is a "Zero Byte Nothing" (ZBN) file... I copied it to my working partition, but upon attempting to upload it to this ticket, it just sits there and never progresses.

So, unless the filename can help you, I think it will be rather difficult to get it to you, to even look at, provided there is anything IN the file, which I suspect there isn't.

The filename is: app_server-77-debug-25-03-2013-15-20-06.report

Hope that helps, unless you know of a way to get more useful information to you.

Erm... a thought just occured to me... what if you have to dump some information BEFORE you "save-report"? Is that why the file is a ZBN? Slap me with a trout now, if that is/was the case. :-D Tell me what to do before typing "save-report", if that needs to be done.

[Luposian]

I tried all the commands, listed in help. Several commands (all two letter; ds, dl, dw, etc.) seems to all do the same thing. Typing them simply makes Debugger want information on address(es) and stuff I have no idea about. Other commands (that "print" stuff), simply caused the Debugger to stop showing any prompt and typing stuff after that, did nothing. Pull the plug... yet again!

And... "shell shutdown -r" does NOT work. Debugger hasn't gotta a clue what I'm talking about. Apparently, if it's not in the help list, it's not in Debugger's vocabulary.

However, I got to looking around and, while the other partition doesn't even have a syslog in the common/var directory, I did notice that one of the items listed in the crash (vesa.accelerant) is a different size than the one in this partition. Now, shouldn't that be the same size? Nothing was changed in vesa.accelerant recently, was there? If not, then that may be a clue to our problem. The files showing up in the crash are possibly bonked (corrupted)?

BTW, what is this "Picasso" in Team/Thread 77, anyways? Wasn't that some drawing routine or something (if I recall correctly)? Is it related to vesa.accelerant and the other files listed in the crash?

[umccullough]

Is this problem likely fixed with hrev45409 ?

To test, you'd have to recompile the image again...

[Luposian]

Unfortunately, nope. Just git pull'd, ./configure'd, jam'd, and installed. Still the same ol' crash. Rats! Was hoping it would be as quick a fix as the last ticket. :-D

[Luposian]

Well, maybe I'm learning something about this "Picasso" thing... which seems to be part of the app_server. But, apparently, replacing it with a known working copy (which I tried) doesn't seem to solve the problem. Weird.

​http://www.haiku-os.org/legacy-docs/benewsletter/Issue1-13.html

"Thread messages use the simple API of send_data and receive_data. This is perhaps the most basic messaging mechanism in the system. These messages aren't buffered, so a call to send_data will block until it's read by the target thread. This mechanism is used in several places in the system, including the initial bootstrapping of applications with the app_server. When an application launches, it uses send_data to send a message to the app_server's 'picasso' thread. This message contains the IDs of a couple of ports; further messaging between the application and the app_server will use these ports."

Does the app_server in Haiku x86_64 function exactly the same, or has it been changed over the years? Is this problem all contained within the app_server or is it a more diverse problem, spread across all the files listed in the crash?

[anevilyak]

Replying to Luposian:

Does the app_server in Haiku x86_64 function exactly the same, or has it been changed over the years? Is this problem all contained within the app_server or is it a more diverse problem, spread across all the files listed in the crash?

Currently it's pretty much impossible to say without further information. Unfortunately if you can't do anything useful from KDL because of your keyboard, and can't retrieve the syslog any other way, that's going to be difficult without someone else being able to reproduce the same problem (I thought you had 2 partitions? If the other one still boots, what prevents you from booting that one and grabbing the syslog from the crashing partition that way?). The fact that it crashes within the app_server doesn't necessarily mean the app_server's at fault, given all the components it interacts with and loads within its address space. In any event, you can pretty much forget what the Be newsletters say about the OS architecture since that's almost guaranteed not to be the same on the Haiku side. The APIs are the same, but their implementation and that of the servers are completely different.

As far as the debugger's report saving command, it doesn't need any prior intervention, it's completely auto-generated regardless of what commands you previously typed. The fact that a 0 byte file gets written hints that there's a problem somewhere, and it could be related to why the app_server crashes to begin with. I can safely tell you that it works properly on 32-bit Haiku over here in any event.

[Luposian]

KDL syslog output

[Luposian]

I just posted a picture of the Syslog, from KDL via Debugger. How? Had to swap the drive over to a system that HAD a PS/2 keyboard port! *sigh*

[Luposian]

Here's a question... a nightly build (which works) can't create a working build. But, what if I created a working build from within Lubuntu? Do you think THAT copy might be able to produce a working build within itself? Is this something to do with Haiku x86_64 not being able to correctly build it's own kind, regardless of how you create the host build, or something else?

The syslog error mentions something to do with vm (virtual memory). Why?

Is the build environment in x86_64 just messed up and CAN'T product a working build? Or is the code in some part that it's trying to compile (as x86_64) not compatible or...?

[xyzzy]

I can't reproduce this. The only thing I can suggest to try is completely rebuild from scratch (i.e. remove the generated directory and start again).

[Luposian]

I guess, if nothing else works, I'll try building a copy from Lubuntu and see if that version will build itself successfully. What are you creating (hosting) your builds from? And those x86_64 builds are building their own kind (self-hosting) perfectly fine?

Would that then mean, the nightlies I'm getting are possibly corrupted and CAN'T self-host successfully? Are they possibly missing a couple components necessary for completely functional self hosting? There has to be a logical answer to this. I'm hoping an answer can be found without me having to try every avenue myself.

[xyzzy]

I built Haiku on my main system, installed that to my test machine, then built Haiku again from there, installed it to another partition, and it booted fine. I used the nightly targets for both builds, so they should be the same as the nightlies from haiku-files.org. I'll download and test one of those in case something's going wrong with them.

[phoudoin]

Could also been some kernel driver that is not yet x86_64 safe, as IIRC only a short-mandatory list of these where ported yet during x86_64 GSoC.

In particular, only the VESA driver was ported so far, as the port was done under VM environnement, not a native one:

Only the vesa graphics driver is included at the moment. 

My uneducated guess is that the nvidia driver and/or userland accelerant is not x86_64 ready yet. Could you try to boot in VESA mode instead to assert this guess?

[phoudoin]

Maybe the nforce kernel / userland VESA accelerant interface assume some implicit int or long size which break badly on 64-bit.

[xyzzy]

Anything other than the VESA drivers shouldn't be included in images built for x86_64, unless Luposian has changed something.

[xyzzy]

Also works for me when built off an official nightly build.

[phoudoin]

Just my raw speculations, but the nforce ethernet driver is there, at least. NForce chispet is also driving the gfx, which could potentially leads to state conflict between the chipset and the VESA accelerant.

Luposian, could you disable the nforce driver (mount the haiku_x86_64 boot volume from another haiku system and move the /boot/add-ons/kernel/drivers/bin/nforce file somewhere else - under a disabled subfolder will do it too), and retry again?

[Luposian]

The only change I make, when building from within the nightly, is to include WebPositive. Nothing more. Nothing less.

[umccullough]

Actually, that brings up an interesting question - what is the jam command you are using to build that image?

[Luposian]

What is your build environment? Ubuntu? Macos x? Haiku32? Haiku64? I am running Haiku x86_64 hrev45399 (nightly). Install that to a partition, then build haiku x86_64 as an image (jam -q haiku-image) and then run the installer and install from the image to another partition on the system and see if it boots.

If it STILL works fine, then I'm crazy or both my Dell Inspiron 570 and Acer Aspire X1200 are crazy computers unfit for Haiku. And how likely is that?

[Luposian]

Wait a second... Are the X86_64 nightlies including drivers that aren't supposed to be included? Could they be conflicting with something during the jam?

[xyzzy]

I have built from my host system running Mac OS X, using the @nightly-anyboot target. Installed that to one partition on my test machine, built from there using the @nightly-raw target, mounted the resulting image and copied the contents to a second partition and booted from that.

I've also installed an official nightly anyboot image and built/installed to the second partition from there, that also works.

And no, the nightlies will not include things that haven't been tested for x86_64.

[xyzzy]

Ok, can you do a complete rebuild from scratch, i.e. delete the whole generated directory, git pull, run ./configure and jam again, and install from that. This does look like the issue fixed in hrev45409, from what you said before it sounds like you may have not completely rebuilt everything - I'm not sure if jam will pick up changes in build flags and detect that it should rebuild.

[Luposian]

Ok, what I did before, was I was using hrev45399 (nightly) and downloaded the latest revision from within it (it was hrev45409 or later), to build that revision and install to my second partition. Should I have, instead, downloaded hrev45409 (or later), burned it to CD, installed that to my first partition and THEN proceeded with the self-host process?

In other words, if hrev45399 was "corrupted" and COULDN'T create a bootable install, then it probably would NEVER work, no matter what revision of code I downloaded/JAM'd with it, because it was munging up all it's builds... right?

I'm, therefore, assuming hrev45409 (or after) needs to be my "working environment" (1st partition) and that should solve the build issue?

[Luposian]

Just downloaded the latest x86_64 nightly and found this in the Readme file:

About this build

---

Haiku repository: hrev45433 <​git://git.haiku-os.org/haiku> Buildtools repository: btrev43050 <​git://git.haiku-os.org/buildtools> Configure command: ../haiku/configure --use-gcc-pipe --use-xattr --distro-compatibility default --cross-tools-prefix ../cross-tools-x86_64/cross-tools/bin/x86_64-unknown-haiku- Jam command: jam -q @nightly-cd Host machine: FreeBSD 9.0-RELEASE-p3 i386

---

If I still can't self-host a bootable build after installing this version on my main partition, could this individual's build environment be causing the problem? Just a thought. Anything look amiss in his information?

[umccullough]

This is our official build environment for all nightlies and alpha images currently.

As noted by xyzzy earlier, he downloaded an official nightly image:

Also works for me when built off an official nightly build.

So, if it works for him, I'm not sure why it doesn't work for you.

[Luposian]

I am please to report, that as of Haiku x86_64 (hrev45437), I am now able to successfully build bootable copies of Haiku x86_64! Thank you! This ticket can now be closed! Yea!