From owner-freebsd-hackers Wed Sep 25 12:27:51 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id MAA08481 for hackers-outgoing; Wed, 25 Sep 1996 12:27:51 -0700 (PDT) Received: from agora.rdrop.com (root@agora.rdrop.com [199.2.210.241]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id MAA07676 for ; Wed, 25 Sep 1996 12:26:27 -0700 (PDT) Received: from pluto.plutotech.com by agora.rdrop.com with smtp (Smail3.1.29.1 #17) id m0v5zaC-00091xC; Wed, 25 Sep 96 12:25 PDT Received: from shane.plutotech.com (durian@shane.plutotech.com [206.168.67.21]) by pluto.plutotech.com (8.7.5/8.7.5) with ESMTP id NAA22022; Wed, 25 Sep 1996 13:20:36 -0600 (MDT) Message-Id: <199609251920.NAA22022@pluto.plutotech.com> From: "Mike Durian" To: Stefan Esser cc: Bruce Evans , freebsd-hackers@freebsd.org Subject: Re: Special Cycles on the PCI bus In-reply-to: Your message of "Wed, 25 Sep 1996 20:06:25 +0200." Date: Wed, 25 Sep 1996 13:20:36 -0600 Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Wed, 25 Sep 1996 20:06:25 +0200, Stefan Esser 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