Haiku refuses to boot. on Gateway NV55S09u

[Luposian]

The NV55S09u uses a 1.4GHz AMD A6-3400M 4-core processor with built-in Radeon HD 6520G graphics. Not sure if the architecture is so different, Haiku just doesn't know what to do with it.

I put Haiku on a 2Gb USB Thumb Drive and, when I set the system BIOS to boot from USB, it blinks for a couple seconds and then Windows 7 boots. Nothing from Haiku at all.

Any ideas?

[SeanCollins]

Have you tried booting from a cd ? Also try a linux thumb drive. See if the problem is the bios or the haiku bootloader code.

[starsseed]

1. Make sure your USB drive MBR is correct. (you can install the default one with this tool: ​http://starsseed.free.fr/fixmbr.zip)
2. Make sure the bootable haiku partition is flagged active. (DriveSetup shows this flag in the "Parameters" column)
3. try a recent nightly build. Some improvements have been made since Alpha3.

Does the problem persists ?

[Luposian]

I have been able to boot the USB drive on my Asus EeePC 1001PXD just fine. But on this system, nothing... I hit [Space] as soon as the USB drive starts blinking and all I get is the Windows 7 boot menu. That's it. I will give the CD drive option a try. But I don't think it will work any better... I sense this system (AMD A6-3400M processor) is too different for Haiku's boot loader to recognize. Anyone have a similar system (AMD A4/A6/A8 processor) that Haiku works on?

I'm using the image file from R42804 (which I built in Lubuntu) on my 2Gb USB thumb drive. Surely that's recent enough, no? Like I said, it works perfectly on my Asus EeePC 1001PXD.

Also, my 8Gb USB thumb drive, with Lubuntu on it, boots fine. Lubuntu doesn't get all the hardware quite right (not surprising, as the AMD Fusion (A-series) chips are quite new), but it boots and works fine. I created the R42804 image, on the EeePC 1001PXD, not this system, so I know it's not this system's conflict with Lubuntu (if any, during the build) causing the problem (like a corrupted image or something).

[SeanCollins]

Go into the Bios and remove the hard drive from the boot list. If it still boots to Windows7, call the manufacturer. I have run into this with three laptops I tested.Might need to get them to swap you out for a laptop that does not have a preinstalled os.

[Luposian]

I could, alternately, just pull out the hard drive entirely. It's an upgradable lappy (RAM/hard drive... maybe even wireless), so if there is no way to disable the drive in the BIOS, I'll just pull the drive and see what happens. Think setting the BIOS to defaults might also clarify the issue (clear up any problems), if the BIOS is causing the problem?

[Luposian]

I just discovered the Gateway NV55S09u uses an InsydeH2O BIOS. Yup... I've never heard of it either, but I think that is what is causing the problem. Weird thing is, it will boot Lubuntu just fine off of an 8Gb USB thumb drive, but won't boot that same OS off of a 16Gb SDHC card. Even when it's set to the first thing to boot. But Haiku won't boot at all. I sense it may be something to do with the fact Haiku is not Windows, Linux, or Unix, which are the OS's that InSydeH2O BIOS claims to support.

I still have yet to try to create a CD-ROM copy of Haiku. I'll have to try that next. I have a vague feeling it won't boot either... I think the BIOS is munging things up.

[SeanCollins]

You will likely need to contact them, IIRC when I ran into this I found out that some boot signatures or some such nonsense were not supported. You could try with a grub bootloader however. See if that gets you anywhere.

[Luposian]

iPhone 4S picture of the KDL

[Luposian]

Replying to SeanCollins:

You will likely need to contact them, IIRC when I ran into this I found out that some boot signatures or some such nonsense were not supported. You could try with a grub bootloader however. See if that gets you anywhere.

I was able to get Haiku to boot by creating a CD using the latest Anyboot image last night. It gets as far as the drive w/ leaf icon and then, about 20 seconds later, crashes to KDL. I've included an image of the crash. Hope this helps.

[Luposian]

Went into the Haiku boot menu, and after fiddling with a bunch of the safety mode options, discovered I only have to check one: "Disable Local APIC". Then it boots to the desktop and works.

However, an interesting thing happens... it only sees one core (CPU). And, while it knows it's a 1.4GHz AMD processor, it doesn't know what type of processor it is, nor how many cores it has, etc.

It also doesn't get the graphics resolution quite right, either... the native resolution is 1366x768, but Haiku defaults to 1024x768.

Reboot also seems munged up... the system never fully reboots.

Ethernet/wireless doesn't work either. Haven't explored more...

Since I'm booting from a CD, how do I get a syslog to submit? Is it in the debug options of the Haiku boot menu?

[mmlr]

Replying to Luposian:

Went into the Haiku boot menu, and after fiddling with a bunch of the safety mode options, discovered I only have to check one: "Disable Local APIC". Then it boots to the desktop and works. However, an interesting thing happens... it only sees one core (CPU). And, while it knows it's a 1.4GHz AMD processor, it doesn't know what type of processor it is, nor how many cores it has, etc.

Not really "interesting" at all. As it already says in the help text of "Disable local APIC" in the boot menu, disabling the local APIC also disables SMP. Since it also is the basis for IO-APICs, those are disabled as well, which leads to interrupt routing having to use legacy functions that are more and more untested/broken the newer the hardware gets. So it's not really surprising that interrupts don't work, causing all sorts of non working components (networking as you mention, possibly that's why ACPI fails as well).

So while it might "work" when disabling the local APICs, it'll probably never really work due to the things mentioned above (which aren't really Haikus fault). That means we need to figure out what's causing the problem with local APICs on, which most probably are Haikus fault (either due to lack of support for something or plain simply due to bugs) so that it can be fixed.

It also doesn't get the graphics resolution quite right, either... the native resolution is 1366x768, but Haiku defaults to 1024x768.

Since it's a Radeon HD, that'll be supported in the new radeon_hd driver that kallisti is working on. I'm not exactly sure if your model is already supposed to work, but I guess it isn't.

Since I'm booting from a CD, how do I get a syslog to submit? Is it in the debug options of the Haiku boot menu?

There are debug options, but since the CD is mounted with a write_overlay (making it writeable) you can just get the syslog at its normal place (at /boot/common/var/log/syslog).

[Luposian]

Do I activate syslog with local APIC disabled (which will allow it to get to the desktop) or with nothing disabled, which will cause Haiku to KDL? I'm assuming the former, because it won't retain the syslog otherwise, right?

Now, if you activate syslog, with nothing disabled, and it crashes, but retains the syslog information, then you would reboot and then disable local APIC, to get to the desktop and acquire the syslog, but... somehow I don't think that would work...

... would it?

[mmlr]

Replying to Luposian:

Do I activate syslog ...

The syslog is always enabled, the on-screen debug output isn't though.

Now, if you activate syslog, with nothing disabled, and it crashes, but retains the syslog information, then you would reboot and then disable local APIC, to get to the desktop and acquire the syslog, but... somehow I don't think that would work...

Indeed it wouldn't. As it fails to find/mount the boot partition it would have no place to write it back to.

There are two options.

1. You try storing the syslog to a FAT32 USB stick via the bootloader. See the ReportingBugs wiki page and the second paragraph under 'Syslog' on how to do that. Note that you can reset the machine via the "reboot" KDL command once KDL is entered on the failed boot attempt.

2. Alternatively you can simply enable on-screen debug output and take a picture of all the pages up to the KDL. If you do this, feel free to resize the resutling pictures before attaching them here (half the size should still be easily readable and wouldn't waste as much space).

[Luposian]

But you didn't answer the first option...

What if I disable local APIC, so Haiku CAN get to the desktop (and function)... will the syslog have all the information you (or whomever) need or does Haiku HAVE to crash, in order to have the information you need?

[mmlr]

Replying to Luposian:

But you didn't answer the first option...

What if I disable local APIC, so Haiku CAN get to the desktop (and function)... will the syslog have all the information you (or whomever) need or does Haiku HAVE to crash, in order to have the information you need?

I thought that was obvious by only explaining how to get the relevant syslog... As mentioned in the comments above, the operation mode when not using APICs is quite different, and it only works because it doesn't try to use any of the more recent features. As such it also doesn't tell much about the problem at hand (as the problematic features aren't even touched), so a syslog from a "working" system is rather uninteresting.

[Luposian]

Syslog pics

[Luposian]

Ok, here are the pictures of the Syslog (Zipped to save space), from the crash. Nothing disabled. By the way... anyone able to tell me what a TAR filesystem is? That's one I've NEVER heard of! FAT, FAT16, FAT32, NTFS, HFS, HFS+, BFS, Minix, etc. THOSE I've heard of... but TAR? Nope! :-D

[mmlr]

Replying to Luposian:

Ok, here are the pictures of the Syslog (Zipped to save space), from the crash.

First, please don't zip stuff up, it doesn't really save any space (the jpegs are already compressed) but makes it far less convenient for someone looking at the report (as one can't just take a look at the pictures in the preview).

Then that isn't the log I'm looking for. Either enable the debug syslog, boot up to the KDL, reboot and then grab the previous syslog from the bootloader via the menu, or (easier) take pictures of the on-screen debug output while booting (up to the KDL). What you attached now is just the log of the bootloader starting up, which isn't revealing anything. Again: Enable on-screen debug output and take a picture of each page of output until you land in KDL. The font size of the on-screen debug output is far smaller, so it won't be as many pictures.

anyone able to tell me what a TAR filesystem is? That's one I've NEVER heard of! FAT, FAT16, FAT32, NTFS, HFS, HFS+, BFS, Minix, etc. THOSE I've heard of... but TAR? Nope! :-D

It's a filesystem based on the TAR format (tape archive, .tar, .tar.gz ...) and is used because the netboot archive for booting via PXE is a TAR file.

[Luposian]

Ok, the Debug Syslog option was checked (by default, as you said). The only option (after reboot), in the menu, were the screens I just sent you. There is no option for save to USB, at least there wasn't with the device I tried (an SDHC card in the SDHC slot). It never gets any further than the disk w/ leaf icon (visually), so isn't what you're seeing the bootloader failing after it gets as far as it can?

I will try doing the onscreen output debug next. Hope that gives you what you're seeking. Can I delete the other enclosures I sent (since they're useless) or does someone else have to do that?

[Luposian]

Aw, crud! I snapped the pictures, using my iPhone, and then Emailed them to myself... problem is, they're of such a low resolution ("JPEG'd to death", as I call it) they're utterly worthless (you zoom in even 2x and everything pixelates to worthlessness)! The only way to insure they'd be visibly usable is to send each image to myself, individually... that's about 13 pictures... this is gonna take awhile. Grrrrrr!

Now, once I have them on my system, ready to upload here, how do I get all of the images in one enclosure... or do they have to be separate?

[Luposian]

1st Image

[Luposian]

2nd Image

[Luposian]

3rd Image

[Luposian]

4th Image

[Luposian]

5th Image

[Luposian]

6th Image

[Luposian]

7th Image

[Luposian]

8th Image

[Luposian]

10th Image

[Luposian]

11th Image

[Luposian]

12th Image

[Luposian]

13th Image

[Luposian]

Ok, here are all 13 images. I sent them at full size, because I want to be sure whomever views them has the best possible chance to be able to see what I snapped. The images are not perfect, but they'll have to do.

Let me know what you find out... hopefully my efforts yield good progress. :-D

[mmlr]

Replying to Luposian:

Ok, here are all 13 images.

Now that's what I'm talking about, thanks a lot!

And it actually shows what's going on: In shot 9 the interrupt routing preparation fails due to an invalidly configured secondary bus. This causes the interrupt model to revert to legacy PIC (which has a relatively good chance of not working due to firmware being buggy (as noone really tests that anymore)). The shots further down then indicate the inevitable, namely USB and AHCI not getting any interrupts, therefore failing to work, leading to the boot volume not being available.

As mentioned above we really need the IO-APIC on a system like this, as the legacy PIC obviously isn't actually working, so I'll now try to figure out what happened to that secondary bus config.

[mmlr]

I've added stricter tests to the routing preparation in hrev43284 that might solve this problem. Can you please retry with that and see if it gets things going? If it doesn't we'll need some more debug output for which I'd need to prepare a small debug enabled ISO for you to test.

As mentioned in the added TODO we might skip this error return completely, but we shouldn't actually get this far. The PCI module at least properly detects the bridges and assigns the secondary bus numbers.

The only thing "strange" about the setup is that the header type flags of some functions of the multi-function devices where the bridge resides seem bogus. They don't have the mutli-function flag set but are part of a multi-function device. That shouldn't have caused any harm though, it's just curious (or maybe I just couldn't decipher the numbers properly).

[Luposian]

Could you create an Anyboot image of the above revision? I'm busy with my son's birthday party today and not quite sure how soon I'll be able to build my own copy from Lubuntu and the nightlies over at Haiku Files haven't caught up yet...

Might also want to create that debug-enabled version you mentioned, as well, just to make sure all bases are covered. I've got plenty of CD-R's. :-D

[Luposian]

I just did a build last night of the latest revision of Haiku and it still crashes at the hard drive with leaf symbol. But, this time, when I disabled local APIC, it never made it to the desktop either. I only tried once, so it might have been a fluke, but... the "full normal" mode crashes just like before.

Fire up that small debug enabled .ISO for me... guess we're gonna need it. :-D

Oh, in case it helps, I build GCC4-only (not GCC2 or either type of Hybrid) versions of Haiku for my own use/testing. Could that be a contributor to the problem? I don't see how, but...

[mmlr]

But the relevant info is: What does the debug output say? It's most certainly not running into the same error as before, as that should be fixed now. Hence it probably runs into another problem that leads to disabling the IO-APIC. Before going to any length with custom debug builds the updated debug output may already reveal the next problem.

[Luposian]

Replying to mmlr:

But the relevant info is: What does the debug output say? It's most certainly not running into the same error as before, as that should be fixed now. Hence it probably runs into another problem that leads to disabling the IO-APIC. Before going to any length with custom debug builds the updated debug output may already reveal the next problem.

So, you want me to take another 13+ pics again? Assuming so many pictures take up too much space on this Ticket, can you remove the previous ones? Unless you're the only one tackling this issue and don't care. :-D

[mmlr]

Replying to Luposian:

So, you want me to take another 13+ pics again?

No I want you to tell me if the same error happens or if a different one does and what it is. As described above in comment 21 shot 9 of the previous run of pics had the original error, so let it run through (with the debug output enabled) to that point and check if that output changed. Errors are marked as such, so reading the output does tell you if another problem happens. If it does, then take a picture of that.

[Luposian]

Shot 9 on 12/5/11

[Luposian]

Ignore attachment 9.2.JPG. No longer current. All future shots will be called 9.JPG (with date of shot taken, noted), to reduce redundancy.

[Luposian]

One week later (Dec. 12, 2011)... shot 9... same issue? Crashes at the same point.

[Luposian]

I did the most recent build today (Dec. 12, 2011) and took another picture of "page 9" of the on-screen debug output. Hopefully, whatever tickets you're working on, are also getting closer to a solution for my issue in the process. :-D

I will continue posting pictures of "page 9" of said output about once a week. I'll just overwrite the previous "page 9" each time, so this ticket doesn't get overloaded with a billion copies of the same shot, if they all say the same thing.

[mmlr]

Replying to Luposian:

I will continue posting pictures of "page 9" of said output about once a week.

This really isn't necessary. The bug won't just disappear on it's own and if I'm actually working on it I'd also update the ticket accordingly so you could retest. We're at 30 comments here now, which is rather unhandy already, so adding more stuff to this ticket that doesn't actually add any info doesn't make much sense.

[yongcong]

Hi Luposian,

IMHO, the root cause is APIC timer issue when AMD C1E is enabled. Either the attached patch or disabling C1E in BIOS will workaround the bug.

would you please try the patch?

Thanks

[mmadia]

To note, #3999 and #7562 may be related and fixed by this patch.

[yongcong]

thanks mmadia.

and #8060, #7940

[Luposian]

I don't know how to disable "C1E" (what is that, anyways?) in the BIOS. Is it called that or does it go by a different name? Remember, my BIOS is not a standard type, it's some weird variation, called "InsydeH2O BIOS", that I've never heard of before!

If it can't be disabled in the BIOS, how do I install the patch from a Live CD image of Haiku that won't boot, unless I disable local APIC? Actually, problem is... even when I disable local APIC, it won't boot either, on the last build or two I did, a month or two ago.

Do you have an .ISO of a build with the patch installed? That could probably work, if it does at all.

[Luposian]

Sure enough, I just looked and there is nothing in the InsydeH2O BIOS, that allows me to enable/disable anything called C1E. I can configure/enable/disable very basic things (hard drive, time/date, passwords, etc.), but nothing more.

How else do I install this .patch ye speak of? Is it part of a recent build of Haiku I can download? I sure hope so!

[SeanCollins]

I tested this patch on my hardware, which without c1e being disabled would not boot. So far so good after 2 hours of uptime. No noticeable regression to speak of and it appears to solve the c1e boot problem.

syslog boot 1 c1e disabled boot 2 c1e enabled.

[tqh]

Slightly modified 0001-x86-AMD-C1E-with-no-ARAT-Always-Running-APIC-Timer-i.patch pushed in hrev44025:

• Added tabs in header
• Moved defines to top of c-file.
• Changed if .. else if else to return the boolean expression directly.

[tqh]

#5982 might also be a dupe of this.

[tqh]

#6022 as well.

[Luposian]

This bug is not fixed, on my Gateway NV55S09u laptop. As of rev 44025, it still locks/crashes at the 4th icon for me. I can get it to come up to a semi-functional state (much as before) by disabling local APIC, disabling I/O APIC, turning on Safe Mode and Safe Mode Graphics and not calling the BIOS. But it's so dysfunctional, in that state, it really can't do anything useful. Almost nothing works right.

NOTE: The rev44025 build of Haiku I did was GCC4, using Lubuntu, if that has any bearing.

[yongcong]

Hi,

That's a bad news. The patch fix #3999 etc. which is related with AMD C1E. I guess this ticket needs other quirks which needs more effort.

Thanks

[Luposian]

I think you mean "tweaks" (adjustments), not "quirks" (oddities/problems/issues). My Gateway NV55S09u laptop already has enough quirks, with it's weird "InsydeH2O" BIOS! :-D

[Luposian]

Just a little note: I created a 2Gb USB of hrev 44330 and... it BOOTED! It crashed at the same place (4th icon; disk with leaf), as it does when I use a CD-R of the same version, but at least now it boots.

In other news, when I disabled everything (in the options menu), it came up to the desktop. Not terribly useful in this state (one core, no networking, etc.), but Haiku DOES see the CPU as an AMD A-series 1.4GHz processor!

So, I definitely think progress is being made (deliberately or not), for which I am quite excited.

[Luposian]

I no longer own this laptop, so I don't think keeping this ticket open has any value, unless someone else has reason to keep pursuing, because they own one. My current Acer Aspire 5560-7414 laptop (Acer owns Gateway) has a similar chipset in it (A6-3420M), which "Haiku 64" works perfectly with. Boot issue was with AHCI. Perhaps that should be looked into with the Gateway (for someone else). If "Haiku 32" has similar boot issues my Acer Aspire 5560 laptop, I will open another ticket, which is more appropriate than keeping this ticket open for a system I no longer own.

Unless someone sees viable reason to keep this ticket open, please CLOSE it.

[leavengood]

Closing as per Luposian's request. If someone else comes along with this hardware we can always reopen.