More trapframe panics

[Warner Losh]

There are some ports that just trigger it built single threaded and only that port, which is why I was looking for a quick and dirty hack...   I fear that Juli is right, though, and a real fix is needed....

Warner

On Jan 26, 2014, at 7:49 PM, Joe Holden wrote:

> If one doesn't try to compile multiple ports at once, it seems to behave.. although I'm having trouble stess testing it at the moment since national grid seem to think supplying 0-270V to my house is acceptable (some fault or something) :P
> 
> On 27/01/2014 01:06, Warner Losh wrote:
>> Yea, I'm aware of the issues. I was hoping for a quick patch to make my Cavium machines better since I know this is an optional feature of the R4k spec. At the time I had my head wrapped around this, it seemed like a faster path, but there were snags in non-uniform page sizes and alias avoidance that make make this untenable anyway...
>> 
>> Warner
>> 
>> On Jan 26, 2014, at 4:30 PM, Juli Mallett wrote:
>> 
>>> Robert Watson and someone else (IIRC) discouraged going this route as some CPUs do not actually support every PageMask value specified for the R4K, so it would turn into an implementation/maintenance nightmare.  Being able to fill an arbitrary number of TLB entries with kernel stack seems just better, anyway, for, I dunno, the person who wants to run Python in the kernel or something :)
>>> 
>>> 
>>> On Sun, Jan 26, 2014 at 10:54 AM, Warner Losh <imp at bsdimp.com> wrote:
>>> 
>>> On Jan 26, 2014, at 9:04 AM, Juli Mallett wrote:
>>> 
>>>> On Sun, Jan 26, 2014 at 7:07 AM, Jan Bramkamp <crest at rlwinm.de> wrote:
>>>>> 
>>>>> Would increasing KSTACK_PAGES from two to three or four help? What are
>>>>> the trade-offs involved in choosing KSTACK_PAGES for something like the
>>>>> EdgeMax Lite?
>>>> 
>>>> 
>>>> That's exactly what needs to happen in all 64-bit MIPS kernels.  Unlike
>>>> some other architectures,  KSTACK_PAGES cannot simply be increased,
>>>> however.  All of the code which handles loading the kernel stack and
>>>> keeping it mapped, etc., assumes that it takes up exactly one TLB entry,
>>>> i.e. 2 pages.  One could simply double KSTACK_PAGES for 64-bit builds and
>>>> modify the code to support the case of 2 or 4 pages, which would keep the
>>>> code as gross as it is today and not buy much flexibility, but might be
>>>> worthwhile as a short-term fix.  Being able to support arbitrary values of
>>>> KSTACK_PAGES (or at least arbitrary multiples of 2 up to the maximum number
>>>> of wired TLB entries times 2) would be better.
>>> 
>>> I hacked together a kludge that quadrupled this by going to the next larger page size for stack pages in the TLB, but hit something ugly when I did that... But I've lost that code, so maybe I should try again to see if I'm more clever the second time.
>>> 
>>> This is one of the things that makes it hard to have a nice native build server on mips64...
>>> 
>>> Warner
>>> 
>>> 
>> 
>> _______________________________________________
>> freebsd-mips at freebsd.org mailing list
>> http://lists.freebsd.org/mailman/listinfo/freebsd-mips
>> To unsubscribe, send any mail to "freebsd-mips-unsubscribe at freebsd.org"
>> 
> 
> _______________________________________________
> freebsd-mips at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-mips
> To unsubscribe, send any mail to "freebsd-mips-unsubscribe at freebsd.org"