Opened 8 years ago

Last modified 4 months ago

#8012 new bug

Boot Fails 2nd time Macbook 2,1

Reported by: kvdman Owned by: nobody
Priority: normal Milestone: R1
Component: - General Version: R1/alpha3
Keywords: boot-failure Cc:
Blocked By: Blocking:
Has a Patch: no Platform: All

Description

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...

Attachments (6)

syslog.zip (16.9 KB) - added by kvdman 8 years ago.
syslog_first_start_MacBookPro_5,4.txt (104.8 KB) - added by taos 8 years ago.
Syslog of first (and only) successful booting of Haiku.
syslog-1st-boot.txt (512.0 KB) - added by kvdman 8 years ago.
syslog-2nd-boot.txt (90.2 KB) - added by kvdman 8 years ago.
syslog-cdboot.txt (382.3 KB) - added by kvdman 8 years ago.
syslog-3rd-boot.txt (211.6 KB) - added by kvdman 8 years ago.

Download all attachments as: .zip

Change History (27)

Changed 8 years ago by kvdman

Attachment: syslog.zip added

comment:1 Changed 8 years ago by 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.

Changed 8 years ago by taos

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

comment:2 Changed 8 years ago by 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

Last edited 8 years ago by kvdman (previous) (diff)

comment:3 Changed 8 years ago by 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.

comment:4 Changed 8 years ago by 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!

Last edited 8 years ago by kvdman (previous) (diff)

comment:5 in reply to:  4 Changed 8 years ago by 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 ;-)

comment:6 Changed 8 years ago by 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.

Changed 8 years ago by kvdman

Attachment: syslog-1st-boot.txt added

Changed 8 years ago by kvdman

Attachment: syslog-2nd-boot.txt added

Changed 8 years ago by kvdman

Attachment: syslog-cdboot.txt added

comment:7 Changed 8 years ago by 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.

comment:8 Changed 8 years ago by 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.

Changed 8 years ago by kvdman

Attachment: syslog-3rd-boot.txt added

comment:9 in reply to:  7 Changed 8 years ago by 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).

comment:10 Changed 7 years ago by 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/

comment:11 Changed 7 years ago by 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.

comment:12 Changed 7 years ago by Don Quixote

Keywords: MacBook2_1 MacBookPro1_1 added

comment:13 Changed 7 years ago by 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.

Last edited 7 years ago by kvdman (previous) (diff)

comment:14 in reply to:  1 Changed 7 years ago by 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?

comment:15 Changed 7 years ago by kvdman

Hi Matt,

I did try hrev42522. Same problem as originally described unfortunately. I did, by the way, come to Begeistert last summer and brought the same laptop. Michael Lotz looked at it and did get it to boot. He said he would add the workaround info to the ticket, but that never happened. I think it had more to do with the app server and setting the resolution than graphics driver.

Last edited 7 years ago by kvdman (previous) (diff)

comment:16 Changed 7 years ago by 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!

comment:17 Changed 7 years ago by diver

Blocking: 7665 added

comment:18 Changed 9 months ago by waddlesplash

Keywords: boot-failure added; MacBook2_1 MacBookPro1_1 removed

comment:19 Changed 9 months ago by waddlesplash

Blocking: 7665 removed

comment:20 Changed 4 months ago by waddlesplash

Still an issue?

comment:21 Changed 4 months ago by 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.

Note: See TracTickets for help on using tickets.