mp_machdep.c (was Re: [Fwd: Re: Bug reports requested - acpi])

John Baldwin jhb at FreeBSD.org
Tue Sep 21 12:01:35 PDT 2004


On Tuesday 21 September 2004 01:10 pm, Nate Lawson wrote:
> Roman Kurakin wrote:
> > My solution works for current so I am going to commit it and MFC after
> > a while. To be sure that I am not on the wrong way I need some
> > reviewed/approved signs ;-) I also hope to get one (or more) tested
> > signs.
> >
> > Patch I plan to commit following patch:
> >
> > Index: mp_machdep.c
> > ===================================================================
> > RCS file: /home/ncvs/src/sys/i386/i386/mp_machdep.c,v
> > retrieving revision 1.238
> > diff -u -r1.238 mp_machdep.c
> > --- mp_machdep.c        1 Sep 2004 06:42:01 -0000       1.238
> > +++ mp_machdep.c        21 Sep 2004 15:54:41 -0000
> > @@ -743,10 +743,11 @@
> >        u_int8_t *dst8;
> >        u_int16_t *dst16;
> >        u_int32_t *dst32;
> > +       vm_offset_t va = (vm_offset_t) dst;
> >
> >        POSTCODE(INSTALL_AP_TRAMP_POST);
> >
> > -       pmap_kenter(boot_address + KERNBASE, boot_address);
> > +       pmap_map(&va, boot_address, boot_address + size, 0);
> >        for (x = 0; x < size; ++x)
> >                *dst++ = *src++;
> >
> > Any signs for(or against)?
> >
> > Thanks!
>
> A quick "no" vote from me until this is really understood.  I think the
> real problem is an interference between the pmap for the AP trampoline
> and the acpi wake code (sys/i386/acpica/acpi_wakeup.c).  The address you
> gave (0x9f000) is right before the base address we use for the wakeup
> code (0xa0000).  As I woke up this morning, I was wondering if this
> could be the issue.  An easy way to test is to disable the call to
> acpi_install_wakeup_handler() in sys/i386/acpica/acpi_machdep.c and see
> if this alone fixes the problem.
>
> If I'm wrong, feel free to commit your patch.
>
> P.S. Spaces instead of tabs in your diff.

Umm, 0xa0000 is the start of Video RAM, so I sure hope the ACPI wake code 
doesn't try to write code into Video memory.  The pmap_invalidate_page is 
certainly needed.

-- 
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 freebsd-current mailing list