Merging 64 bit changes to -HEAD

Jayachandran C. c.jayachandran at gmail.com
Thu Jul 1 20:04:41 UTC 2010


On Fri, Jul 2, 2010 at 12:17 AM, Jayachandran C.
<c.jayachandran at gmail.com> wrote:
> On Thu, Jul 1, 2010 at 10:25 PM, Luiz Otavio O Souza <lists.br at gmail.com> wrote:
>> On Jun 30, 2010, at 7:40 PM, Jayachandran C. wrote:
>>> On Wed, Jun 30, 2010 at 10:38 PM, Luiz Otavio O Souza
>>> <lists.br at gmail.com> wrote:
>>>> On Jun 30, 2010, at 9:57 AM, Jayachandran C. wrote:
>>>>
>>>>> On Tue, Jun 29, 2010 at 10:32 PM, Luiz Otavio O Souza
>>>>> <lists.br at gmail.com> wrote:
>>>>>>
>>>>>> On Jun 29, 2010, at 8:02 AM, Jayachandran C. wrote:
>>>>>>
>>>>>>> On Tue, Jun 29, 2010 at 2:28 AM, Luiz Otavio O Souza <lists.br at gmail.com> wrote:
>>>>>>>>> Thanks for the the update. Looks like pmap_map for kernel is failing,
>>>>>>>>> may be the new tlb_update code causes this.  Can you apply the
>>>>>>>>> attached patch and see if the problem still persists, it replaces the
>>>>>>>>> new tlb_update code with the older version.
>>>>>>>>>
>>>>>>>>> Obviously not a fix, but if we can narrow it down to this function,
>>>>>>>>> fixing will be easier.
>>>>>>>>>
>>>>>>>>> JC.
>>>>>>>>> <try.diff>
>>>>>>>>
>>>>>>>> JC,
>>>>>>>>
>>>>>>>> This fix the problem ! Thanks ! Now, at least, you know where to look :)
>>>>>>>
>>>>>>> The new tlb_update does not seem to update the tlb entry if the tlbp
>>>>>>> fails.  Here's a patch that should make the new function behave like
>>>>>>> the older one.  The patch is in attached file 'tlb-update.diff'.
>>>>>>>
>>>>>>> If that does not work, I'm not sure what the issue is.  You could also
>>>>>>> try try the nop-change.diff attached. It tries to switch the ssnop
>>>>>>> used for delay in the new code with 'nop' which was used by the old
>>>>>>> code.
>>>>>>>
>>>>>>> Thanks,
>>>>>>> JC.
>>>>>>> <tlb-update.diff><nop-change.diff>
>>>>>>
>>>>>> JC,
>>>>>>
>>>>>> The nop-change seems to have no effect at all and with the tlb-update patch the kernel apparently crash at bzero(), here is the dmesg with TRAP_DEBUG enabled:
>>>>>>
>>>>>> http://mips.pastebin.com/jydPvJ20
>>>>>>
>>>>>> So hopefully you are on the right track and this may be something obvious to you.
>>>>>
>>>>> Not yet :) I really hoped the earlier change would fix it.  The number
>>>>> of nop does not seem to be the issue as it is higher in the C code
>>>>> than the assembly.
>>>>>
>>>>> Can you try the attached patch (try.diff) - this re-implements the
>>>>> assembly code functionality almost in the same way in C.  This really
>>>>> should work, given that the patch which made it assembly worked...
>>>>>
>>>>> If that works can you see if the second attached patch works, this
>>>>> fixes a potential problem (ie, we should be masking 13bits for TLBHI).
>>>>>
>>>>> Both patches should apply directly to SVN (not dependent on each
>>>>> other, or on previous patches)
>>>>>
>>>>> Thanks again,
>>>>> JC.
>>>>> <try.diff><pte.h-fix.diff>
>>>>
>>>>
>>>> JC,
>>>>
>>>> The try.diff works with or without the pte.h change (at least for a simple boot) and the pte.h change does nothing without the try.diff.
>>>
>>> I've attached the final(final.diff) version I want to check-in, can
>>> you please quickly test it?
>>>
>>> If that does not work, can you tell me if the attached alt1.diff or
>>> alt2.diff works? The try.diff had three changes: handle case of
>>> index>0, remove pagemask operation, restore full entryhi instead of
>>> asid. So if the first does not work, this will help narrow down the
>>> rest of the cases.
>>>
>>> Hopefully this is the last iteration :)
>>>
>>> JC.
>>> <final.diff><alt1.diff><alt2.diff>
>>
>>
>> JC,
>>
>> The final.diff and alt1.diff crash (into debugger) like the first try.diff (here is the dmesg: http://pastebin.com/r2uunZPZ).
>>
>> The alt2.diff works, i'll try it a little more (buildworld).
>>
>> Feel free to send more tests if needed.
>
> Looks like I was on the wrong track, it now looks like the pagemask
> maybe the cause.  My suspicion is that the bootloader setups a
> pagemask and we never clear it because all the operations save and
> restore the mask. As far as I can see the TLB exception handler will
> not update pagemask.
>
> Juli - any comments on this? Do you need to save/restore pagemask for
> some reason, otherwise I will take out the part from tlb.c.  Will send
> out a patch a bit later.

Okay - here's hopefully the final patch. Let me know if it boots up.

Thanks,
JC.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: tlb.c-pagemask-remove.diff
Type: application/octet-stream
Size: 2778 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-mips/attachments/20100701/7b07a77e/tlb.c-pagemask-remove.obj


More information about the freebsd-mips mailing list