Date: Fri, 28 Apr 2006 14:22:17 -0700 From: Maxim Sobolev <sobomax@FreeBSD.org> To: John Baldwin <jhb@FreeBSD.org> Cc: cvs-src@FreeBSD.org, src-committers@FreeBSD.org, cvs-all@FreeBSD.org, Nate Lawson <nate@root.org> Subject: Re: cvs commit: src/sys/dev/sk if_sk.c if_skreg.h Message-ID: <44528789.8020302@FreeBSD.org> In-Reply-To: <200604281709.02585.jhb@freebsd.org> References: <200604280317.k3S3Hb3L017882@repoman.freebsd.org> <44525D16.3070005@root.org> <44526C95.3000708@FreeBSD.org> <200604281709.02585.jhb@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
John Baldwin wrote: > 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. It gets nowhere, unfortunately. I see 99 99 99 99 99 as a trace. :( BTW, can you check the following URL, it's the changes intel has maiden to ia32 manual after releasing Core Duo. Maybe you can spot something there. There are some lapic-related changes. http://download.intel.com/design/Pentium4/specupdt/25204616.pdf -Maxim
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?44528789.8020302>