Date: Thu, 23 Apr 2009 09:34:09 +0200 From: Bartlomiej Sieka <tur@semihalf.com> To: Andreas Tobler <andreast-list@fgznet.ch> Cc: freebsd-ppc@freebsd.org Subject: Re: Fatal kernel trap during boot 8.0-CURRENT Message-ID: <259915AE-12EF-4887-BB81-D955DDD970B3@semihalf.com> In-Reply-To: <49EFD957.2010605@freebsd.org> References: <D350790D-5AC3-4AD5-821E-6431ADAA0A2A@fahrners.de> <49E76291.4000002@fgznet.ch> <49EFD957.2010605@freebsd.org>
index | next in thread | previous in thread | raw e-mail
[-- Attachment #1 --] 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 [-- Attachment #2 --] diff --git a/sys/powerpc/aim/machdep.c b/sys/powerpc/aim/machdep.c index 01b4db2..aab3e3e 100644 --- a/sys/powerpc/aim/machdep.c +++ b/sys/powerpc/aim/machdep.c @@ -486,6 +486,7 @@ powerpc_init(u_int startkernel, u_int endkernel, u_int basekernel, void *mdp) thread0.td_pcb = (struct pcb *) ((thread0.td_kstack + thread0.td_kstack_pages * PAGE_SIZE - sizeof(struct pcb)) & ~15); + bzero((void *)thread0.td_pcb, sizeof(struct pcb)); pc->pc_curpcb = thread0.td_pcb; /* Initialise the message buffer. */ [-- Attachment #3 --]home | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?259915AE-12EF-4887-BB81-D955DDD970B3>