Opened 12 years ago

Closed 5 years ago

Last modified 4 years ago

#8012 closed bug (not reproducible)

Boot Fails 2nd time Macbook 2,1

Reported by: kvdman Owned by: nobody
Priority: normal Milestone:
Component: - General Version: R1/alpha3
Keywords: boot-failure Cc:
Blocked By: Blocking:
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 12 years ago.
syslog_first_start_MacBookPro_5,4.txt (104.8 KB ) - added by taos 12 years ago.
Syslog of first (and only) successful booting of Haiku.
syslog-1st-boot.txt (512.0 KB ) - added by kvdman 12 years ago.
syslog-2nd-boot.txt (90.2 KB ) - added by kvdman 12 years ago.
syslog-cdboot.txt (382.3 KB ) - added by kvdman 12 years ago.
syslog-3rd-boot.txt (211.6 KB ) - added by kvdman 12 years ago.

Download all attachments as: .zip

Change History (29)

by kvdman, 12 years ago

Attachment: syslog.zip added

comment:1 by taos, 12 years ago

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.

by taos, 12 years ago

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

comment:2 by kvdman, 12 years ago

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 12 years ago by kvdman (previous) (diff)

comment:3 by mmlr, 12 years ago

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 by kvdman, 12 years ago

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 12 years ago by kvdman (previous) (diff)

in reply to:  4 comment:5 by mmlr, 12 years ago

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 by kvdman, 12 years ago

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.

by kvdman, 12 years ago

Attachment: syslog-1st-boot.txt added

by kvdman, 12 years ago

Attachment: syslog-2nd-boot.txt added

by kvdman, 12 years ago

Attachment: syslog-cdboot.txt added

comment:7 by kvdman, 12 years ago

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 by kvdman, 12 years ago

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.

by kvdman, 12 years ago

Attachment: syslog-3rd-boot.txt added

in reply to:  7 comment:9 by taos, 12 years ago

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 by kvdman, 12 years ago

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 by Don Quixote, 12 years ago

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 by Don Quixote, 12 years ago

Keywords: MacBook2_1 MacBookPro1_1 added

comment:13 by kvdman, 12 years ago

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 12 years ago by kvdman (previous) (diff)

in reply to:  1 comment:14 by mmadia, 12 years ago

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 by kvdman, 12 years ago

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 12 years ago by kvdman (previous) (diff)

comment:16 by JoeStrout, 12 years ago

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 by diver, 12 years ago

Blocking: 7665 added

comment:18 by waddlesplash, 6 years ago

Keywords: boot-failure added; MacBook2_1 MacBookPro1_1 removed

comment:19 by waddlesplash, 6 years ago

Blocking: 7665 removed

comment:20 by waddlesplash, 5 years ago

Still an issue?

comment:21 by taos, 5 years ago

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.

comment:22 by waddlesplash, 5 years ago

Resolution: not reproducible
Status: newclosed

comment:23 by nielx, 4 years ago

Milestone: R1

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

Note: See TracTickets for help on using tickets.