From owner-freebsd-hackers  Mon Sep 23 17:48:53 1996
Return-Path: owner-hackers
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.5/8.7.3) id RAA00713
          for hackers-outgoing; Mon, 23 Sep 1996 17:48:53 -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 RAA00689
          for <freebsd-hackers@FreeBSD.org>; Mon, 23 Sep 1996 17:48:49 -0700 (PDT)
Received: from pluto.plutotech.com by agora.rdrop.com with smtp
	(Smail3.1.29.1 #17) id m0v5Lg4-0008xmC; Mon, 23 Sep 96 17:48 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 SAA13351 for <freebsd-hackers@FreeBSD.org>; Mon, 23 Sep 1996 18:44:59 -0600 (MDT)
Message-Id: <199609240044.SAA13351@pluto.plutotech.com>
From: "Mike Durian" <durian@plutotech.com>
To: freebsd-hackers@FreeBSD.org
Subject: Re: Special Cycles on the PCI bus 
Date: Mon, 23 Sep 1996 18:44:58 -0600
Sender: owner-hackers@FreeBSD.org
X-Loop: FreeBSD.org
Precedence: bulk


  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