On Wed, 11 May 2005, John Klos wrote:

> Hi,
>
> I haven't had the time to test out a new kernel on one of my colocated 
> servers (partly because I'd have needed the time to be able to go down to the 
> colo place - now I have a serial console again).
>
> Today, here is what I got:
>
> trap: pid 11.1 (pagedaemon): kernel MCHK trap @ 0x2dbf84 (SRR1=0x149030)
> panic: trap
> Begin traceback...
> 0xd5e32d50: at trap+0xec
> 0xd5e32dd0: kernel MCHK trap by pool_reclaim+0xa8: srr1=0x149030
>            r1=0xd5e32e90 cr=0x84000048 xer=0 ctr=0x2dd03c
> 0xd5e32e90: at pool_reclaim+0x7c
> 0xd5e32ef0: at pool_drain+0x60
> 0xd5e32f10: at uvm_pageout+0x14c
> 0xd5e32f40: at cpu_switchto+0x44
> 0xd5e32f50: at ADBDevTable+0x4790ccf4
> End traceback...
> syncing disks... 16 15 15 15 15 15 14 14 14 14 12 12 12 12 12 12 12 12 12 12 
> 12
> 12 12 giving up
> dumpsys: TBD
> wd1: flush cache command didn't complete
> rebooting
>
> So forgive me for not remembering, but basically this problem will go away if 
> I compile without options ALTIVEC, or if I try a current kernel with some of 
> the fixes, right?
>
> Thanks,
> John Klos

hi john,

it goes away as soon as you optimize your kernel (add -O3, -mabi=altivec, 
or -maltivec to mk.conf) -- have a look at gcc.gnu.org's docu.

i tested this stuff a while, O3 is sufficient to get the kernel running, 
alas it's not required to use /all/ optimization flags -- a single one or 
(i guess) any combination will do.

>
> (I will have more time to pay attention to NetBSD stuff soon! Really, I 
> will!)

me either :)

cheers,

timo