Date: Tue, 24 Sep 1996 17:42:46 +1000 From: Bruce Evans <bde@zeta.org.au> To: durian@plutotech.com, freebsd-hackers@FreeBSD.org Subject: Re: Special Cycles on the PCI bus Message-ID: <199609240742.RAA22722@godzilla.zeta.org.au>
next in thread | raw e-mail | index | archive | help
> I have some more information on the special cycles problem we've >been seeing. Using a PCI bus analyzer, I've see a few patterns >of bus activity leading up to an illegal special cycle. The >very first one that occurs on a system just booted is very consistent. >It looks like: > Interrupt ACK Cycle > D32=xxxxxx20 (intr 8 I beleive) > I/O READ ADR=00000084 > D32=xxxxxx00 I forget which version you are running. -current hasn't accessed port 0x84 except in rtcin() since 1995/12/13 (except from 1996/01/19 to 1996/03/31). Try deleting these accesses (and the ones in rtcin() by configuring with option DUMMY_NOPS). > I/O WRITE ADR=00000021 > D32=xxxx01xx This masks further IRQ8's. > I/O READ ADR=00000084 > D32=xxxxxx00 > I/O WRITE ADR=00000020 > D32=xxxxxx20 This acks the IRQ8 (EOI). > I/O READ ADR=00000084 > D32=xxxxxx00 > I/O WRITE ADR=00000021 > D32=xxxx01xx > I/O READ ADR=00000084 > D32=xxxxxx00 > I/O WRITE ADR=00000020 > D32=xxxxxx20 I don't understand this repetition. > I/O READ ADR=00000084 > D32=xxxxxx00 > I/O WRITE ADR=00000021 > D32=xxxx00xx This prepares to return from the IRQ8 handler. It unmasks further IRQ8's. > I/O WRITE ADR=00000043 > D32=00xxxxxx > I/O READ ADR=00000040 > D32=xxxxxxF1 > I/O READ ADR=00000040 > D32=xxxxxx2B > I/O WRITE ADR=00000043 > D32=00xxxxxx > I/O READ ADR=00000040 > D32=xxxxxxDD > I/O READ ADR=00000040 > D32=xxxxxx2B > I/O WRITE ADR=00000043 > D32=00xxxxxx > I/O READ ADR=00000040 > D32=xxxxxxCA > I/O READ ADR=00000040 > D32=xxxxxx2B > >The above code makes a bit of sense. We get an interrupt and the >manipulate the PIC. Then it calls DELAY to spin a bit (and reads >the timer). Right. >Now's the interresting bit - notice the high bits (0xFC) >in the write/read address. They can't be intentional. I also find >it interesting that the accesses to FCA0 are full 32 bit writes. > > I/O WRITE ADR=0000FC87 > D32=06xxxxxx > I/O READ ADR=0000FC87 > D32=06xxxxxx > I/O WRITE ADR=0000FC90 > D32=xxxxxx00 > I/O READ ADR=0000FC90 > D32=xxxxxx00 > I/O WRITE ADR=0000FC9A > D32=xx80xxxx > I/O WRITE ADR=0000FCA0 > D32=00000040 > I/O WRITE ADR=0000FCA0 > D32=00000000 > repeat last write 3 times > I/O WRITE ADR=0000FCA0 > D32=002DBB58 > I/O WRITE ADR=0000FCA0 > D32=00000006 > I/O WRITE ADR=0000FC9A > D32=xx00xxxx > I/O WRITE ADR=0000FC90 > D32=xxxxxx00 > I/O WRITE ADR=0000FC9B > D32=00xxxxxx > I/O WRITE ADR=0000FC87 > D32=02xxxxxx No, this seems reasonable. isa/pcibus.c does 32-bit accesses to port 0xc000 | (device << 8ul). >Now we're back to the DELAY() function (or at least getit()) > I/O WRITE ADR=00000043 > D32=00xxxxxx > I/O READ ADR=00000040 > D32=xxxxxx2B > I/O READ ADR=00000040 > D32=xxxxxx2A > MEMRD LINE ADR=002DBB58 > D32=00000000 > D32=xxxx0000 > SPECIAL CYCLE > >This is always the first special cycle. Another bit of bus activity >that results in a special cycle is a bit shorter. It starts the >same: > An interrupt cycle (I didn't write down which) > I/O RD 0x84 > I/O WR 0x21, 0x01 > I/O RD 0x84 > I/O WR 0x20, 0x20 > I/O RD 0x84 > I/O WR 0x21, 0x00 > Special Cycle > >In yet another case, which I have seen only once, there were hundreds >of I/O accesses to 0x320. 0x320 is a valid I/O address, but I have >it listed as a Hard Disk (XT), so that doesn't sound like something >we'd be doing on purpose. >David Greenman suggested that the inb(0x84)'s might be the cause. >I originally thought not since there are used much earlier in >the boot process, but perhaps they do effect things when used >in the ISR code. Auto-EOI might cause problems with buggy hardware, but it isn't enabled by default and you're not using it. Try enabling it. This would at least reduce the amount of output from the bus analyzer :-). Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199609240742.RAA22722>