>From woods@building.weird.com Tue Jan 25 18:11:41 2005
>Date: Tue, 25 Jan 2005 21:11:03 -0500 (EST)
>MIME-Version: 1.0
>Content-Type: text/plain; charset=us-ascii
>...
>From: "Greg A. Woods" <woods@weird.com>
>To: List Mail User <track@Plectere.com>
>Cc: NetBSD/alpha Discussion List <port-alpha@NetBSD.ORG>,
>        NetBSD Kernel Technical Discussion List <tech-kern@NetBSD.ORG>
>Subject: Re: Should Alpha PCI code manage latency timers?
>In-Reply-To: <200501242348.j0ONmnlj005037@Plectere.com>
>References: <200501242348.j0ONmnlj005037@Plectere.com>
>...
>
>[ On Monday, January 24, 2005 at 15:48:49 (-0800), List Mail User wrote: ]
>> Subject: Re: Should Alpha PCI code manage latency timers?
>>
>> 	Could someone else check some other non-x86 machines, both old and
>> relatively current to see the behavior (I thinking of Suns and/or SGI boxes).
>
>Here's the AlphaServer ES40 I've been working on.  First the SRM output
>to show what devices the firmware recognizes:
>
>probe I/O subsystem
>probing hose 1, PCI
>bus 0, slot 4 -- pka -- NCR 53C895
>bus 0, slot 5 -- ewa -- DE500-BA Network Controller
>bus 0, slot 6 -- ega -- DEGXA-TA Gigabit Ethernet
>probing hose 0, PCI
>probing PCI-to-ISA bridge, bus 1
>bus 0, slot 2, function 0 -- pkb -- Adaptec AIC-7899
>bus 0, slot 2, function 1 -- pkc -- Adaptec AIC-7899
>bus 0, slot 4 -- ewb -- DE500-BA Network Controller
>bus 0, slot 15 -- dqa -- Acer Labs M1543C IDE
>bus 0, slot 15 -- dqb -- Acer Labs M1543C IDE
>
>
>It's currently running a test -current kernel:
>
>
>[console]<@> # uname -srm
>NetBSD 2.99.11 alpha
>
>
>[console]<@> # pcictl /dev/pci0 list
>000:01:0: ATI Technologies 3D Rage II+ (VGA display, revision 0x9a)
>000:02:0: Adaptec (2nd PCI Vendor ID) AIC-7899A U160 (SCSI mass storage, revision 0x01)
>000:02:1: Adaptec (2nd PCI Vendor ID) AIC-7899A U160 (SCSI mass storage, revision 0x01)
>000:03:0: Q Logic product 0x2312 (Fiber Channel serial bus, revision 0x02)
>000:04:0: Digital Equipment DECchip 21142/21143 10/100 Ethernet (ethernet network, revision 0x30)
>000:07:0: Acer Labs M1543 PCI-ISA Bridge (ISA bridge, revision 0xc3)
>000:15:0: Acer Labs M5229 UDMA IDE Controller (IDE mass storage, interface 0xfa, revision 0xc1)
>000:19:0: Acer Labs M5237 USB Host Controller (USB serial bus, interface 0x10, revision 0x03)
>[console]<@> # pcictl /dev/pci0 dump -d 1 | fgrep -i latency
>    Latency Timer: 0xff
>    Maximum Latency: 0x00
>[console]<@> # pcictl /dev/pci0 dump -d 2 | fgrep -i latency
>    Latency Timer: 0xfc
>    Maximum Latency: 0x19
>[console]<@> # pcictl /dev/pci0 dump -d 2 -f 1 | fgrep -i latency
>    Latency Timer: 0xfc
>    Maximum Latency: 0x19
>[console]<@> # pcictl /dev/pci0 dump -d 3 | fgrep -i latency
>    Latency Timer: 0x40
>    Maximum Latency: 0x00
>[console]<@> # pcictl /dev/pci0 dump -d 4 | fgrep -i latency
>    Latency Timer: 0xff
>    Maximum Latency: 0x28
>[console]<@> # pcictl /dev/pci0 dump -d 7 | fgrep -i latency
>    Latency Timer: 0x00
>    Maximum Latency: 0x00
>[console]<@> # pcictl /dev/pci0 dump -d 15 | fgrep -i latency
>    Latency Timer: 0xff
>    Maximum Latency: 0x04
>[console]<@> # pcictl /dev/pci0 dump -d 19 | fgrep -i latency
>    Latency Timer: 0xf8
>    Maximum Latency: 0x50
>
>
>(that first intel card below is an i82546GB dual-port 1000baseSX fibre card)
>
>[console]<@> # pcictl /dev/pci1 list                        
>000:01:0: Intel product 0x107a (ethernet network, revision 0x03)
>000:01:1: Intel product 0x107a (ethernet network, revision 0x03)
>000:02:0: Q Logic product 0x2312 (Fiber Channel serial bus, revision 0x02)
>000:03:0: Intel i82544EI Gigabit Ethernet (1000BASE-T) (ethernet network, revision 0x02)
>000:04:0: Symbios Logic 53c895 (SCSI mass storage, revision 0x02)
>000:05:0: Digital Equipment DECchip 21142/21143 10/100 Ethernet (ethernet network, revision 0x30)
>000:06:0: Broadcom Corporation BCM5703X 10/100/1000 Ethernet (ethernet network, revision 0x02)
>[console]<@> # pcictl /dev/pci1 dump -d 1 | fgrep -i latency 
>    Latency Timer: 0xfc
>    Maximum Latency: 0x00
>[console]<@> # pcictl /dev/pci1 dump -d 1 -f 1 | fgrep -i latency
>    Latency Timer: 0xfc
>    Maximum Latency: 0x00
>[console]<@> # pcictl /dev/pci1 dump -d 2 | fgrep -i latency     
>    Latency Timer: 0x40
>    Maximum Latency: 0x00
>[console]<@> # pcictl /dev/pci1 dump -d 3 | fgrep -i latency
>    Latency Timer: 0xfc
>    Maximum Latency: 0x00
>[console]<@> # pcictl /dev/pci1 dump -d 4 | fgrep -i latency
>    Latency Timer: 0xff
>    Maximum Latency: 0x40
>[console]<@> # pcictl /dev/pci1 dump -d 5 | fgrep -i latency
>    Latency Timer: 0xff
>    Maximum Latency: 0x28
>[console]<@> # pcictl /dev/pci1 dump -d 6 | fgrep -i latency
>    Latency Timer: 0xf8
>    Maximum Latency: 0x00
>
>
>
>I wonder if setting pci0:07:00 to have a non-zero latency timer would
>fix some of the problems with the "interrrupt conflicts" seen whenver
>the NetBSD kernel trys to use the IDE CDROM....
>
>-- 
>						Greg A. Woods
>
>H:+1 416 218-0098  W:+1 416 489-5852 x122  VE3TCP  RoboHack <woods@robohack.ca>
>Planix, Inc. <woods@planix.com>          Secrets of the Weird <woods@weird.com>
>

	Greg,

	Here, unlike the Sun Ultra 10 reported before, both of the values for
your "Q Logic" cards look incorrect. PCI 0:7 falls into the special case of
an PCI-ISA bridge likely always fitting the "two-cycle" exception rule.  The
other differences (i.e. 0xfc and 0xf8 vs. 0xff) are explained by the "low-order
bit R/O as zero" exception.

	It seem odd that all these Alphas seem to generally use the maximum
possible value for each case, but I guess that would depend on how "far" away
from DEC's TurboChannel days, the designs were implemented (i.e. are they done
as hidden TurboChannel->PCI internal translations or first-class PCI designs).
I'm afraid that unlike VAXen, I don't recognize the various models and dates
for Alphas.  Though assuming the Rage II was original equipment that dates it
to be an about '97 or '98. design (maybe even late '95 if they were an early
design win).

	By any chance does your "Acer IDE" share an interrupt with one of the
"Q Logic" cards?

	I definitely spent *too* much time with TurboChannel support issues,
but most of it predated Alphas and was with the MIPS based Decstations (my
first experiences with Alphas were when consulting at the old WRL/WSL in Palo
Alto, before the Alphas were officially released - and I had very little to do
with them after that - WRL was upset that their own RISC design lost the
internal battle and the Alphas were a MA based design - besides my own work
at DEC was the porting of OpenGL to DEC platforms and the porting of PEX to
SGIs - which is how DEC became the first OpenGL licensee - they paid for their
license with the PEX implementation SGI wanted "just in case" - Interestingly I
actually reported to old DEC people who had been "stolen" by SGI (Phil Karlton
in particular), despite being paid by DEC and having an office there.  More OT:
This was immediately after a few years at SGI converting the GL from being
based on Sun's NEWS - which I had also worked on - to a window system agnostic
version which SGI based on X-Windows starting with IRIX 4.0 - actually, it was
entirely undocumented, but the Personal Iris, using "hidden" a set of hidden
command line flags would run without NEWS and using X Windows starting with the
Irix 3g release back in '93-'94 and using X11R3/4).

	Paul Shupak