Re: Problems with registers save/restore on context switch?

[Donald Lee <MacPPC2%c.icompute.com@localhost>]

At 7:06 AM -0500 1/28/14, Michael wrote:
>On Mon, 30 Dec 2013 00:18:46 -0600
>Donald Lee <MacPPC2%c.icompute.com@localhost> wrote:
>
>> I am building kernels now. I'll start with a GENERIC 6.0.3 kernel on both the
>> failing and the working CPU, jsut to make sure I'm not chasing ghosts. Then 
>> I'll
>> run the modified kernel on both.  Results in a day or two or three.....
>> 
>> -dgl-
>> 
>> Just for documentation's sake - this is the log excerpt from the machine I
>> found that fails.  It's a 7455 CPU.
>> 
>> Dec 29 22:54:43 charm /netbsd: cpu0 at mainbus0: 7455 (Revision 2.1), ID 0 
>> (primary)
>> Dec 29 22:54:43 charm /netbsd: cpu0: HID0 
>> 0x84d0c1bc<EMCP,TBEN,HIGH_BAT_EN,NAP,DPM,ICE,DCE,XBSEN,SGE,BTIC,LRSTK,FOLD,BHT>,
>>  powersave: 1
>> Dec 29 22:54:43 charm /netbsd: cpu0: 866.67 MHz, 256KB L2 cache no parity 
>> parity enabled
>
>For the record, my iBook G4 has that kind of CPU and I can't make it
>fail ( so far at least, on -current ).
>
>have fun
>Michael

If you follow that thread, you will see that my experiments seemed to point
to the failure caused not by the CPU, but the USERLAND difference(s) between
5.2 and 6.0. That makes little sense, but is what my experiments seemed to show.

My simplest test case - the one with the gmtime_r() calls - fails
in reasonable time, and would be a good candidate to test on a wider variety of
system versions and CPUs to see what the H*** is going on. ;->

A tarball with the test can be found here: 
http://www.icompute.com/pub/gmtime.tgz

I think this is a serious problem, and is well worth an effort to fix it.

-dgl-