Boot Fails 2nd time Macbook 2,1

[kvdman]

This problem has been persistent since this MacBook could boot Haiku.

The livecd runs fine, I then install Haiku to a partition. It boots fine, then on the second boot it hangs, and can't boot again. It locks completely, with a white line about 1" long at the top of the screen (blue the rest), keyboard and mouse are unresponsive.

No combination of disabled boot options allows me to boot it again.

Attached is the syslog...

[taos]

This also happens with a MacBook Pro 5,4. I've attached a syslog file from the only successful boot (syslog_first_start_MacBookPro_5,4.txt). Tested some time ago with hrev42726 installed on a SD card.

[taos]

Syslog of first (and only) successful booting of Haiku.

[kvdman]

Seems this happens under Ubuntu 11.04 on Macbooks too.

"MTRR setup doesn't work/happen. I assume this is due to the MacBook using EFI (well, an Apple variant of it) with a BIOS emulation. I manually set the two areas marked as prefetchable in lspci to write-combining in /proc/mtrr. This seems to help a bit against some of the really slow framebuffer updates."

​http://ubuntuforums.org/showthread.php?t=115104

​http://www.nvnews.net/vbulletin/showthread.php?t=164092

[mmlr]

I would honestly have looked at this ticket earlier if the syslog wasn't zipped. Never attach logs zipped if not absolutely necessary, as it kills the ability to preview it inline, making it so much less convenient. In either case the zipped syslog is useless as it doesn't actually contain the system boot info, just the error and wireless output of the running system (there is obviously an interrupt problem at least with USB).

The MTRR issue sounds like a pretty long shot and according to the quote (and link) it doesn't actually solve the problem either. I don't really see how it could be the problem either, because the MTRR setup doesn't usually differ between boots. Without having the hardware (or a syslog of such a failed second boot) it's really difficult to tell.

To narrow it down I would go for identifying everything that is created/changed on first boot that could affect subsequent boots. The swap file comes to mind, though it should be active already in the first boot. Maybe the resolution config of the workspaces causing graphics card init failure the second time around (though one would need to run the Screen prefs on first boot for that to happen)? Booting from USB and comparing the filesystem before booting the first time and after would certainly give a hint. Something like this should work to sum up everything:

find /theVolume -type f | xargs -l1 -Ix md5sum "x" > theLog.log

And then the pre-boot and post-boot logs could be compared.

[kvdman]

Thanks for replying. I don't seem to be alone with the problem at least. The log I did attach was of the failed second boot. Where are the settings for MTRR stored?? Is there a log file stored when running from LiveCD (CD boots every time)?

I did start the screen prefs app, but didn't change or adjust the resolution on any workspace.

I'll try the suggestion you gave me and reply back.

The log was 475kb uncompressed, so I thought it'd be more convenient to zip it. Now I know, thanks!

[mmlr]

Replying to kvdman:

The log I did attach was of the failed second boot.

I see. So it might not actually be interrupt issues but actual timeouts due to something hogging the system (interrupt storm, or actual delays caused by invalid MTRRs, or something else yet to be found).

Where are the settings for MTRR stored??

Those aren't settings, they are runtime configurations constructed depending on the memory types the kernel and drivers register. As mentioned I don't see why they would differ from one boot to another unless the hardware changes. Maybe something's up though that causes some driver to behave differently on first boot, causing the MTRR setup to be different. A long shot though.

Is there a log file stored when running from LiveCD (CD boots every time)?

At the usual place. The write_overlay makes the CD appear as writeable, so the syslog is written normally.

I did start the screen prefs app, but didn't change or adjust the resolution on any workspace.

You could try not doing that once just to make sure, I wouldn't know off hand if the Screen prefs writes any settings if you only start it (I guess it doesn't).

The log was 475kb uncompressed, so I thought it'd be more convenient to zip it. Now I know, thanks!

Also, please don't add any vital information to your comments by editing them, because when reading the comments via the bug mails, which only contain the original comment, your info might just get lost... Just as another fun fact about ticket convenience ;-)

[kvdman]

Hello,

I ran the LiveCD again, pulled the syslog, and attached it.

Unfortunately, the symptom I experienced before occurred at the 1st boot this time, and second and subsequent boots. So I guess I can't use that comparison you suggested, but perhaps you could compare the CD bootlog to the hard drive as it boots fine from CD. I've attached those logs as well.

[kvdman]

I think I've found the problem. The graphics driver. If I delete the intel graphics driver and accelerant from the hard disk, the system will boot no problem (please confirm taos).

It boots at a resolution of 1024x768 with VESA though, and the native resolution is 1280x800.

I then try to force this resolution with a VESA kernel settings file (1280 800 32), and I will get the same boot crash... Which is weird because the CD can boot this resolution.

[kvdman]

I think I'll stay quiet now, and let one of the devs try to figure this out :)

Because, I just rebooted again, at least 5x with VESA, and it keeps locking the system as originally described.

I'm attaching the last syslog (3) then.

[taos]

Replying to kvdman:

I think I've found the problem. The graphics driver. If I delete the intel graphics driver and accelerant from the hard disk, the system will boot no problem (please confirm taos).

Yes, after renaming intel_extreme and intel_extreme.accelerant the MacBook Pro 5,4 boots fine.

It boots at a resolution of 1024x768 with VESA though, and the native resolution is 1280x800.

I get the native resolution of 1440x900 automatically.

After rebooting, the system is again locked. I can sucessfully boot if I first shutdown the MacBook Pro 5,4 and then remove and insert the SD card with my Haiku installation (hrev42835).

[kvdman]

So this also happens on the 1,1 Macbook according to #8044.

Affected are Macbooks: 1,1, 2,1, 5,4 (confirmed).

Apple sold ~3 million Macbooks in 2010... ​http://www.tuaw.com/2011/03/07/analyst-apple-sold-1-1-million-macbook-airs-in-2010/

[Don Quixote]

This also happens on my MacBookPro1,1 (Early 2006). I had the hope that waiting a little while then building from the latest Subversion would help, but I suppose now it won't.

It has ATI Radeon X1600 video. This is not yet supported by the driver, so when I was able to boot I could not get the native resolution of 1440x900. I will try removing the Radeon driver and accellerant while booted under VirtualBox to see if that gets me running again.

[kvdman]

1" white line at the top of the screen also happens on my MacPro, it has a:

NVIDIA GeForce 8800 GT

I just updated Haiku to a recent build, Haiku was working perfectly before (Haiku also used to load fine on my MacBook). I briefly glanced at the version, and it was somewhere along hrev40111 (the last revision tested that worked without the white line on my MacPro).

So, there's now three different vendors > ATI, Intel, & Nvidia where the exact same problem occurs, and Haiku previously loaded fine (on or before hrev40111). So, it doesn't seem to be a graphics driver or accelerant problem.

[mmadia]

Replying to taos:

This also happens with a MacBook Pro 5,4. I've attached a syslog file from the only successful boot (syslog_first_start_MacBookPro_5,4.txt). Tested some time ago with hrev42726 installed on a SD card.

Karl (or anyone else with an affected MacBook Pro),

After looking at ​http://cgit.haiku-os.org/haiku/log/src/add-ons/kernel/drivers/graphics/intel_extreme and ​http://cgit.haiku-os.org/haiku/log/src/add-ons/accelerants/intel_extreme , it looks like hrev42523 could be the culprit, as that appears to be the first changeset since R1a3. On haiku-files.org, there's hrev42522 (which if i'm correct will work) and hrev42593 (which shouldn't). Could you test this?

[kvdman]

Hi Matt,

I did try hrev42522. Same problem as originally described unfortunately.

[JoeStrout]

Brand new tester here -- just read the IEEE Spectrum article, and had to try it. Unfortunately, build r1alpha3, on a CD burned from the ISO, isn't working on either my MacBook Pro, nor on my Mac Mini. Both produce the result described above (1-inch white bar at top of screen, extending from left to *almost* the right side, pointy-hand in middle of screen, and totally unresponsive to keyboard and mouse).

In case it helps: the MacBook Pro has a 2.53 GHz Intel Core 2 Duo, 4 GB RAM, and NVIDIA GeForce 94000M 256MB video. The Mini has a 2.4 GHz Intel Core 2 Duo, 8 GB RAM, and NVIDIA GeForce 320M video.

I hope someone can get to the bottom of this... Haiku looks awesome, and I can't wait to try it out!

[waddlesplash]

Still an issue?

[taos]

No idea. As far as I've heard, the company MacBook Pro 5,4 had an "unfortunate accident" happen to it some five years ago, was trashed and replaced by non-Apple hardware.

[nielx]

Remove milestone for tickets with status = closed and resolution != fixed