cvs commit: src/sys/dev/sk if_sk.c if_skreg.h
John Baldwin
jhb at freebsd.org
Fri Apr 28 21:09:42 UTC 2006
On Friday 28 April 2006 15:27, Maxim Sobolev wrote:
> Nate Lawson wrote:
> > Maxim Sobolev wrote:
> >>> BTW, thanks for your work on the reboot issue. Oh, and are you using
> >>
> >> Don't mention it. The other big and still unresolved issue is getting
> >> SMP working. I have tried to debug it and as long as I can tell second
> >> core for some reason doesn't start at all. I have even attempted to
> >> borrow second CPU kick in magic from xnu (Darwin kernel), but the
> >> result is the same. My current guess is that since it's mobile
> >> processor, the 2nd core may be turned off for power saving purposes
> >> and needs some (ACPI?) hohomagic to power it up. Unfortunately I can't
> >> find any documentation on the processor to check. It is interesting
> >> that both Linux and Windows don't have any problems with getting it
> >> working OOB.
> >
> > I don't think there's any special ACPI thing to do. If you have acpi
> > loaded, the MADT (apic table) probe should just work. Are you sure you
> > have the latest -current since cperciva@ fixed the Core Duo limitation
> > we had?
>
> Yes, I do have the latest kernel (circa this morning). Do you have any
> other ideas about what can be wrong?
>
> BTW, in the following lapic_ipi_raw call, is the last argument expected
> to be 0 or maybe it's typo and it should be apic_id instead?
>
> /* do an INIT IPI: deassert RESET */
> lapic_ipi_raw(APIC_DEST_ALLESELF | APIC_TRIGMOD_LEVEL |
> APIC_LEVEL_DEASSERT | APIC_DESTMODE_PHY | APIC_DELMODE_INIT, 0);
No, it's using ALLESELF for the destination to send it to everyone but
the current CPU. Try enabling the CHECK_POINTS code in mp_machdep.c
and mpboot.s to see if you can figure out how far the AP gets before
it goes belly up.
--
John Baldwin <jhb at FreeBSD.org> <>< http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve" = http://www.FreeBSD.org
More information about the cvs-all
mailing list