Date: Wed, 25 Sep 1996 13:20:36 -0600 From: "Mike Durian" <durian@plutotech.com> To: Stefan Esser <se@zpr.uni-koeln.de> Cc: Bruce Evans <bde@zeta.org.au>, freebsd-hackers@freebsd.org Subject: Re: Special Cycles on the PCI bus Message-ID: <199609251920.NAA22022@pluto.plutotech.com> In-Reply-To: Your message of "Wed, 25 Sep 1996 20:06:25 %2B0200."
next in thread | raw e-mail | index | archive | help
On Wed, 25 Sep 1996 20:06:25 +0200, Stefan Esser <se@zpr.uni-koeln.de> wrote: > >Well, but those are only used for config space accesses, >and config space is normally not touched at all, after >the PCI probe and attach are complete. I tracked down those accesses to 0xfca0. They are completely normal. That is just where the ahc's I/O space got mapped. The accesses were caused by the code in aic7xxx.c:ahc_scsi_cmd(). The line is numbered 3187 for me, but we've made a number of modifications to that code and it is probably different in the stock 2.1.5 source. It is right in the middle of pausing the sequencer and unpausing it. However, since we see the special cycles on machines without SCSI, I don't think it is related. So the trace I sent shows an interrupt occurring, DELAY() code being called, code in ahc_scsi_cmd running, DELAY() again a memory read from 0x002dbb58 (which varies depending on code changes) and then the special cycle. It looks pretty harmless. One thing that I didn't report, but have noticed is the special cycles are followed by an interrupt. Someone has taken my bus analyzer, but I think the special cycle was followed about 8us later by an interrupt. I'm not sure if that is close enough time-wise to be relevant. I might be wrong, but I can't remember ever seeing a special cycle without an interrupt as the next bus activity. >I'd need to know more about the system configuration (boot >messages and the driver that causes the special cycles) >and will then try to understand what's going on ... Well that's the trick, finding the driver that causes the special cycles. Using the debugger, I was able to narrow the first one down to the VOP_OPEN call, but wasn't able to pin it down any further. It stopped happening when I got too close. I tried looking for unique transactions on the bus around the special cycle and then using an ICE to get the address of the instruction. But this didn't turn up anything too interesting in the example I posted. The i/o accesses to fca0 were perfectly normal. I'll try tracking down the memory access immediately before the special cycle and see if that turns up anything. mike
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199609251920.NAA22022>