Date: Mon, 23 Sep 1996 18:44:58 -0600 From: "Mike Durian" <durian@plutotech.com> To: freebsd-hackers@FreeBSD.org Subject: Re: Special Cycles on the PCI bus Message-ID: <199609240044.SAA13351@pluto.plutotech.com>
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/O WRITE ADR=00000021 D32=xxxx01xx I/O READ ADR=00000084 D32=xxxxxx00 I/O WRITE ADR=00000020 D32=xxxxxx20 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/O READ ADR=00000084 D32=xxxxxx00 I/O WRITE ADR=00000021 D32=xxxx00xx 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). 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 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. Any more ideas, anyone? mike
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199609240044.SAA13351>