cvs commit: src/sys/dev/sk if_sk.c if_skreg.h

[John Baldwin]

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 at FreeBSD.org>  <><  http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve"  =  http://www.FreeBSD.org