Date: Mon, 1 May 2006 11:24:07 -0400 From: John Baldwin <jhb@freebsd.org> To: Maxim Sobolev <sobomax@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: <200605011124.09330.jhb@freebsd.org> In-Reply-To: <44528789.8020302@FreeBSD.org> References: <200604280317.k3S3Hb3L017882@repoman.freebsd.org> <200604281709.02585.jhb@freebsd.org> <44528789.8020302@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Friday 28 April 2006 17:22, Maxim Sobolev wrote: > 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 None of the APIC-related changes affect us. We always access APIC registers using 32-bit loads and stores for example. -- John Baldwin <jhb@FreeBSD.org> <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200605011124.09330.jhb>