Fatal kernel trap during boot 8.0-CURRENT

[Nathan Whitehorn]

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...
-Nathan