DragonFly submit List (threaded) for 2007-03
DragonFly BSD
DragonFly submit List (threaded) for 2007-03
[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]

Re: DragonFly on Intel Mac?


From: Matthew Dillon <dillon@xxxxxxxxxxxxxxxxxxxx>
Date: Tue, 6 Mar 2007 08:08:31 -0800 (PST)

:Hi.
:Although it runs fine on Parallels Desktop(an emulator), it doesn't
:with BootCamp.  LiveCD stops twirling the baton prematurely.
:There's been some good efforts in FreeBSD to install and boot on
:MacBook Pro via BootCamp last year, and I confirmed that 6.2-RELEASE
:installs and runs almost fine.  I searched through their commit log, and
:ported the relavant parts (patch attached).  MacBook Pro is a legacy-free
:hardware and has no keyboard controller, and the patch puts upper limit
:on the amount of time to wait for the controller to be ready (or give up),
:according to their commitlog.
:
: With this patch, it does boot past the boot loader, but it ends up
:in double fault after many lines of 'sched_ithd: stray interrupt 7'.
:Also I need to disable acpi driver because it fills the screen with
:garbage and I can't see anything in the boot log.  I tested cdboot
:and the kernel on other PCs and had no problem.  So it's probably
:safe to commit.
:
:I'm currently playing with it installed in a spare partition of
:FreeBSD 6.2-RELEASE installation.  The hardest part is that even
:on FreeBSD, the keyboard rarely work until the OS boots up (and I saw
:this with SuSE too).  In fact it's easier edit /boot.config and
:/boot/loader.conf from FreeBSD installation than keep punching the
:power button :) This may or may not be BootCamp's fault.  I hope to post
:a few more positive news/patch soon.
:
:Cheers.

    There's something going on with the stray irq printf() itself
    possibly being the cause of the double fault.  I think the printf()
    in that situation (interrupting random kernel code without MP lock
    controls) is not safe.

    Except for the interrupt disablement and reenablement bits, I like
    the patch.  I don't think those bits are necessary.  

    It may also be a good idea to put a DELAY() in the C code loop instead
    of relying on ISA bus timing (which won't actually be ISA bus timing
    because the ISA bus is faked these days).  I'm not sure what 
    the best solution would be for the assembly.  It might not be a big 
    deal but it could save us headaches later on.

						-Matt



[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]