Fatal kernel trap during boot 8.0-CURRENT

[Bartlomiej Sieka]

On 2009-04-23, at 04:58, Nathan Whitehorn wrote:

> Andreas Tobler wrote:
>> Jochen Fahrner wrote:
>>> Hi,
>>> after a fews days of power off I wanted to boot the 8.0 kernel I  
>>> installed last week on my iMac G3.
>>> I got a kernel trap after starting sc0 driver:
>>>
>>> =======================
>>> sc0: Unknown <16 virtual consoles, flags=0x300>
>>> Timecounter "decrementer" frequency 24960000 Hz quality 0
>>> Timecounters tick every 10.000 msec
>>>
>>> fatal kernel trap:
>>> exception = 0x7 (program)
>>> srr0      = 0x509168
>>> srr1      = 0x83032
>>> lr        = 0x4f9788
>>> curthread = 0x633a30
>>> pid = 0, comm=swapper
>>> thread pid 0 tid 100000
>>> Stopped at 0x509168
>>> illegal instruction 7c0049ce
>>> ==========================
>>>
>>> I could repeat this several times.
>>> Then I booted my old 7.1 kernel without problems.
>>> After that I also could boot 8.0 again.
>>
>> Fyi, I experience the same on my imac G3. And I use the same  
>> procedure to get back to -CURRENT.
> This is related to Altivec support. 7c0049ce is stvx    v0,r0,r9,  
> which is the first executed Altivec instruction in save_vec(), and  
> the faulting address is close to where to save_vec() ends up in my  
> kernel. save_vec() can only be called if the process is marked with  
> PCB_VEC. I have no idea how that ends up happening, and I can't  
> duplicate the problem on my G3. One option would be to insert a  
> panic() or a kdb_backtrace() into enable_vec(), which might at least  
> tell us where it is getting called from...
>
> The only thing I can think of is that the 750 is taking a  
> performance monitor exception and falling through to the EXC_VEC  
> handler, which will try to turn on Altivec. The way Altivec support  
> works is that only Altivec-aware processors should ever fault to  
> EXC_VEC, in which case we should be fine setting PCB_VEC on the  
> process. Very confusing...

Hello,

Perhaps the problem is related to an issue we came across while  
working on Efika support. The issue was that the Altivec-specific code  
was executed, due to PCB_VEC being set when it shouldn't (Efika has  
the MPC5200B SoC, which is e300-based). PCB_VEC turned out the be set  
because thread0.td_pcb contained garbage, and our problem went away  
after zeroing the thread0.td_pcb in powerpc_init(), similarly to what  
booke/machdep.c implementation does.

Please try the attached patch and see if it fixes the problem seen on  
iMac G3.

Regards,
Bartlomiej Sieka

-------------- next part --------------
A non-text attachment was scrubbed...
Name: zero-td_pcb.diff
Type: application/octet-stream
Size: 521 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-ppc/attachments/20090423/612e65b9/zero-td_pcb.obj
-------------- next part --------------