Merging 64 bit changes to -HEAD

[Jayachandran C.]

On Mon, Jun 28, 2010 at 9:42 PM, Luiz Otavio O Souza <lists.br at gmail.com> wrote:
> On Jun 28, 2010, at 7:14 AM, Jayachandran C. wrote:
>
>> On Sun, Jun 27, 2010 at 8:20 PM, Jayachandran C.
>> <c.jayachandran at gmail.com> wrote:
>>> On Sun, Jun 27, 2010 at 4:00 PM, Luiz Otavio O Souza <lists.br at gmail.com> wrote:
>>>> On Jun 15, 2010, at 10:36 AM, Jayachandran C. wrote:
>>>>
>>>> ( ... )
>>>>>
>>>>> I've tested this on XLR, but there is a chance that this might break
>>>>> other platforms. So please let me know your comments on both the
>>>>> patches and the merge process.
>>>>>
>>>>> The future patches (if everything goes well), will do the PTE_ flag to
>>>>> PG_ flag renaming in Juli's tree, then the actual n32/n64 changes.
>>>>>
>>>>> Thanks,
>>>>> JC.
>>>>
>>>> JC,
>>>>
>>>> I can't boot the ar71xx kernel after r209243:
>>>>
>>>> http://mips.pastebin.com/CBhe6hzR
>>>> http://pastebin.com/nrRdm1UF
>>>>
>>>> Everything works fine with the previous revision (r209048).
>>>>
>>>> If you need anything else, just let me know.
>>>
>>> Let me have a look at this, thanks for the report.
>>
>> Can you enable 'TRAP_DEBUG' in sys/mips/mips/trap.c and see if you can
>> get the trap information printed.  Adding a line
>> #define TRAP_DEBUG
>> after all the #includes in trap.c should do it.  This should print the
>> pc, ra, and badvaddr which would help a lot in debugging.
>>
>> In the meantime I will look at the code again and see if I can find
>> anything obviously wrong.
>>
>> Thanks,
>> JC.
>
> JC,
>
> The TRAP_DEBUG option doesn't help, but during the tests i found a weird symptom...
>
> After a cold reset the kernel always hang at same place (after the WITNESS notice), but if i boot from an old kernel and issue a 'reboot' the board boots just fine.
>
> I've add a few printfs all around to find where it hangs and this happen at the first call of pmap_map() at vm_page_startup().
>
> Here is a dmesg from a failed boot: http://mips.pastebin.com/QnUu56hD
>
> And here is a successful one: http://mips.pastebin.com/bsJ4Ac3z
>
> I hope this can give you some clue about what's is going on...

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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: try.diff
Type: application/octet-stream
Size: 7528 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-mips/attachments/20100628/b81b8067/try.obj