Date: Sat, 14 Jul 2001 10:46:01 -0700 (PDT) From: Matthew Jacob <mjacob@feral.com> To: Peter Wemm <peter@wemm.org> Cc: alpha@FreeBSD.ORG Subject: Re: For those with persistant alpha trouble.... Message-ID: <Pine.BSF.4.21.0107141038250.87022-100000@beppo> In-Reply-To: <20010714173750.63A9F380B@overcee.netplex.com.au>
next in thread | previous in thread | raw e-mail | index | archive | help
Very cool. Thank you. I have seen none of these in quite a while. I've tried your change to the call to ithread_schedule on a 4100 and an 8200 (I just 8200s working again- I had to hack on the mbinit and MP startup code slightly) Very interesting. Basically, we're disabling ithread preemption with this change, right? That's really okay with me- I'm one of this who hold with THOTH and other systems that say that code threads should run to natural stopping points anyway. -matt On Sat, 14 Jul 2001, Peter Wemm wrote: > Matthew Jacob wrote: > > > > > > The other alpha I have access to right now (UP2000 - SMP 2x21264) doesn't > > > > seem to care either way - it seems to work ok. beast.freebsd.org (Miata > > > > MX5 - PWS500au) absolutely will not build world without it. > > > > What was the crash stack on the Miata? > > Hmm. I thought I had a firmware PC, but instead it appears to be in > kernel space... From the conserver log file: > > halted CPU 0 > > halt code = 2 > kernel stack not valid halt > PC = fffffc000056f2a0 > > CPU 0 booting > > I'm not sure if I have the kernel that corresponds to that crash. :-( > I *think* it is this one: > fffffc000056f1a0 T XentRestart > fffffc000056f238 T exception_return > fffffc000056f23c t Ler1 > fffffc000056f268 t Lkernelret > fffffc000056f268 t Lrestoreregs > fffffc000056f28c t Lnohae > fffffc000056f2a0 T exception_save_regs <<<< > fffffc000056f310 T exception_restore_regs > fffffc000056f380 t fp_add > fffffc000056f400 t fp_sub > > Actually, they are all at this PC. No ra or anything though. > > On the may 24th kernel, it died with this: > > fatal kernel trap: > > trap entry = 0x2 (memory management fault) > faulting va = 0x51 > type = access violation > cause = store instruction > pc = 0xfffffc0000521e4c > ra = 0xfffffc0000521e60 > sp = 0xfffffe000865d9f8 > curproc = 0xfffffe0007a33f80 > pid = 16, comm = swi3: cambio > > panic: trap > > fffffc0000521840 t initiate_write_inodeblock > fffffc0000521d00 t softdep_disk_write_complete <<<< in here > fffffc00005221a0 t handle_allocdirect_partdone > fffffc0000522300 t handle_allocindir_partdone > > Which I am not sure is useful... I think that was probably one of the > softupdates bugs. > > Cheers, > -Peter > -- > Peter Wemm - peter@FreeBSD.org; peter@yahoo-inc.com; peter@netplex.com.au > "All of this is for nothing if we don't go to the stars" - JMS/B5 > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.21.0107141038250.87022-100000>