Date: Sat, 26 Sep 2009 16:04:05 -0500 From: Alan Cox <alc@cs.rice.edu> To: Daniel O'Connor <doconnor@gsoft.com.au> Cc: Attilio Rao <attilio@freebsd.org>, alc@freebsd.org, freebsd-stable@freebsd.org, John Baldwin <jhb@freebsd.org> Subject: Re: 8.0-RC1 panic attaching ppc Message-ID: <4ABE81C5.2010009@cs.rice.edu> In-Reply-To: <200909260824.39985.doconnor@gsoft.com.au> References: <200909232322.51060.doconnor@gsoft.com.au> <200909250957.06252.jhb@freebsd.org> <4ABD000F.5080007@cs.rice.edu> <200909260824.39985.doconnor@gsoft.com.au>
next in thread | previous in thread | raw e-mail | index | archive | help
This is a multi-part message in MIME format.
--------------010502000108070908030508
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Daniel O'Connor wrote:
> On Sat, 26 Sep 2009, Alan Cox wrote:
>
>> John Baldwin wrote:
>>
>>> On Friday 25 September 2009 3:20:05 am Daniel O'Connor wrote:
>>>
>>>> On Thu, 24 Sep 2009, John Baldwin wrote:
>>>>
>>>>> Can you try this patch perhaps:
>>>>>
>>>>> Index: sys/amd64/isa/isa_dma.c
>>>>> =================================================================
>>>>> == --- isa_dma.c (revision 197430)
>>>>> +++ isa_dma.c (working copy)
>>>>>
>>>> This patch fixes the panic for me.
>>>>
>>>> I haven't tried printing (don't have any device handy here).
>>>>
>>> I wonder if pmap_extract(kernel_pmap) doesn't work with direct map
>>> addresses for some reason? I kind of find that hard to believe
>>> actually. Alan, the original panic was in
>>> pmap_extract(kernel_pmap, ...) calls in the isa_dma code. My patch
>>> that "fixes" the panic just changes them to pmap_kextract().
>>>
>> Is this problem occurring on an AMD processor?
>>
>
> Yes,
> CPU: AMD Athlon(tm) II X2 240 Processor (2812.73-MHz K8-class CPU)
> Origin = "AuthenticAMD" Id = 0x100f62 Stepping = 2
> Features=0x178bfbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,MMX,FXSR,SSE,SSE2,HTT>
> Features2=0x802009<SSE3,MON,CX16,POPCNT>
> AMD Features=0xee500800<SYSCALL,NX,MMX+,FFXSR,Page1GB,RDTSCP,LM,3DNow!+,3DNow!>
> AMD Features2=0x37ff<LAHF,CMP,SVM,ExtAPIC,CR8,ABM,SSE4A,MAS,Prefetch,OSVW,IBS,SKINIT,WDT>
> TSC: P-state invariant
> real memory = 4294967296 (4096 MB)
> avail memory = 3974762496 (3790 MB)
>
>
Ok, now I can explain what is happening. The kernel is using 1GB pages
to implement the direct map. Unfortunately, pmap_extract() doesn't know
how to handle a 1GB page mapping. pmap_kextract() only works by an
"accident" of its different implementation. In other words, it should
not be relied upon to work either.
Please revert whatever patch John gave you and try the attached patch.
It simply disables the use of 1GB page mapping by the direct map.
Regards,
Alan
--------------010502000108070908030508
Content-Type: text/plain;
name="Page1GB.patch"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
filename="Page1GB.patch"
Index: amd64/amd64/pmap.c
===================================================================
--- amd64/amd64/pmap.c (revision 197425)
+++ amd64/amd64/pmap.c (working copy)
@@ -442,7 +442,7 @@
if (ndmpdp < 4) /* Minimum 4GB of dirmap */
ndmpdp = 4;
DMPDPphys = allocpages(firstaddr, NDMPML4E);
- if ((amd_feature & AMDID_PAGE1GB) == 0)
+ if (TRUE || (amd_feature & AMDID_PAGE1GB) == 0)
DMPDphys = allocpages(firstaddr, ndmpdp);
dmaplimit = (vm_paddr_t)ndmpdp << PDPSHIFT;
@@ -476,7 +476,7 @@
/* Now set up the direct map space using either 2MB or 1GB pages */
/* Preset PG_M and PG_A because demotion expects it */
- if ((amd_feature & AMDID_PAGE1GB) == 0) {
+ if (TRUE || (amd_feature & AMDID_PAGE1GB) == 0) {
for (i = 0; i < NPDEPG * ndmpdp; i++) {
((pd_entry_t *)DMPDphys)[i] = (vm_paddr_t)i << PDRSHIFT;
((pd_entry_t *)DMPDphys)[i] |= PG_RW | PG_V | PG_PS |
--------------010502000108070908030508--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4ABE81C5.2010009>