Date: Thu, 28 Jan 1999 10:00:58 +0000 (GMT) From: Doug Rabson <dfr@nlsystems.com> To: Simon Shapiro <shimon@simon-shapiro.org> Cc: freebsd-alpha@FreeBSD.ORG, Mark Salyzyn <salyzyn_mark@dpt.com> Subject: Re: Alpha/PCI Help Request Message-ID: <Pine.BSF.4.01.9901280955480.95594-100000@herring.nlsystems.com> In-Reply-To: <XFMail.990127005218.shimon@simon-shapiro.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 27 Jan 1999, Simon Shapiro wrote: > Hi Y'll > > As promissed, I am here again seeking free advise and cheap thrills (well, > free advise for sure :-). > > I can now talk to the DPT card, but there are some problems: > > * The PCI code has changed quite a bit since I wrote the driver. the > existing PCI code was written by the CAM team, so I am not up to speed > yet :-( > > * 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. > > * The driver, in the initialization routine (dpt_init), around line 1370 > makes a call to bus_dma_tag_create(). > > * I have not studied this function yet, but the arguments passed to it are: > > parent_dma_tag = 0xfffffe0001120a80 > alignment = 0 /* hard-coded in the call */ > boundry = 0 /* Hard-coded */ > lowaddr = 0xffffffff /* BUS_SPACE_MAXADDR */ > highaddr = 0xffffffff /* BUS_SPACE_MAXADDR */ > filter = NULL /* hard-coded */ > filterarg = NULL /* Hard-coded */ > maxsize = 0x10000 /* MAXBSIZE */ > nsegments = 1 /* dpt->sgsize setup above */ > maxsegsz = 0x20 /* BUS_SPACE_MAXSIZE_32BIT */ > flags = 2 /* BUS_DMA_ALLOCNOW */ > buffer_dma_tag = 0xfffffe0001126010 /* dpt->buffer_dmat */ > > * The system abort booting at this point, dropping back to the SRM which > says: > > 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. -- Doug Rabson Mail: dfr@nlsystems.com Nonlinear Systems Ltd. Phone: +44 181 442 9037 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.01.9901280955480.95594-100000>