Date: Wed, 27 Jan 1999 15:52:35 -0500 (EST) From: Simon Shapiro <shimon@simon-shapiro.org> To: Doug Rabson <dfr@nlsystems.com> Cc: freebsd-alpha@FreeBSD.ORG, Mark Salyzyn <salyzyn_mark@dpt.com> Subject: Re: Alpha/PCI Help Request Message-ID: <XFMail.990127155235.shimon@simon-shapiro.org> In-Reply-To: <Pine.BSF.4.01.9901280955480.95594-100000@herring.nlsystems.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Doug Rabson, On 28-Jan-99 you wrote: ... > > * The PCI probe banner announces that the card is on int a, irq 0. > > this > > does not look good to me. I have no idea how to set the IRQ, other > > than > > what is done already in the driver (sys/pci/dpt_pci.c, and > > sys/dev/dpt/dpt_scsi.c) > > This is quite normal for a 164LX based system. Good. One potential source of headache gone... ... > > > > halted CPU 0 > > > > halt code = 7 > > machine check while in PAL mode > > PC = 18400 > > boot failure > > >>> > > > > * Obviously the driver works under IA (i386), or I could not type this > > message :-) > > > > If this rings a bell, please let me know. I will try, in the meantime > > to > > isolate the exact line of code that blows up (1C resolution), and post > > some > > more information. > > This kind of error sometimes happens when accesses are made to i/o > memory > which isn't backed by a real device. The way I usually debug this is to > single step the code until I find exactly what the bogus address was. > The > answer is often obvious at that point. Are you using kernel-gdb for > this? > It makes this stuff a *lot* easier. This is the game plan... thanx! Simon 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?XFMail.990127155235.shimon>