[ On Tuesday, January 25, 2005 at 21:26:52 (-0800), List Mail User wrote: ]
> Subject: Re: Should Alpha PCI code manage latency timers?
>
> 	Here, unlike the Sun Ultra 10 reported before, both of the values for
> your "Q Logic" cards look incorrect.

Hmmm.... they're the few things on this machine that actually seem to
work exactly as expected.  (unlike any GigE card I've tried!)

Though I haven't yet tried to pull data off the FC arrays while pushing
it out the network at the same time.....

> PCI 0:7 falls into the special case of
> an PCI-ISA bridge likely always fitting the "two-cycle" exception
> rule.

Hmmm...  I wondered about that just after I posted -- not that I really
understand any of the low-level details of these latency timers, but it
was my guess that there might be something special for a bridge,
especially an ISA bridge, despite it claiming "bus mastering" ability.


> 	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).

The ES40 is approximately the second most recent Alpha design in the low
mid-range systems using the "Third-Generation Alpha Chip" (21264A - four
at 833MHz each in this machine).  According to the "technical summary"
document it is definitely a from-the-ground-up PCI design with its own
custom interface chips, one per bus, as part of its custom 21272 chipset.

It's claimed to be "Fully compliant with the PCI Version 2.1
Specification" and each bus is 33 MHz and a full 64-bits A & D wide.


> 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).

No, don't assume anything from that ATI card -- it was just what was
handy when I painted myself into a corner with the wrong SRM settings
and couldn't get at the serial console any more.  :-)

The "technical summary" document was published, or at least is
copyright, 2001, and the 21272 chipset hardware reference manual I have
(rev. 4.0) is dated 21 October 1999.


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

Not that I can tell, at least not from NetBSD's point of view:

[console]<@> # dmesg | fgrep irq
ahc0: interrupting at dec 6600 irq 12
ahc1: interrupting at dec 6600 irq 13
isp0: interrupting at dec 6600 irq 16
tlp0: interrupting at dec 6600 irq 20
com0 at isa0 port 0x3f8-0x3ff irq 4: ns16550a, working fifo
com1 at isa0 port 0x2f8-0x2ff irq 3: ns16550a, working fifo
fdc0 at isa0 port 0x3f0-0x3f7 irq 6 drq 2
wm0: interrupting at dec 6600 irq 24
wm1: interrupting at dec 6600 irq 25
isp1: interrupting at dec 6600 irq 28
wm2: interrupting at dec 6600 irq 32
esiop0: interrupting at dec 6600 irq 36
tlp1: interrupting at dec 6600 irq 40
bge0: interrupting at dec 6600 irq 44


I haven't had much luck yet figuring out the interrupt routing from
Tru64's point of view.

Note that I've specifically turned off the ohci driver which caused the
most problems (and not just on the es40).

If I'm not mistaken the "Interrupt line:" values from pcictl all match
the "irq" values shown from dmesg, with the exception that the ISA
interrupts are encoded into a special range as per this comment in the
code in my slightly modified copy of sys/arch/alpha/pci/pci_6600.c:

/*
 * Tsunami models have a PCI device (the combined ATA & USB controller) with
 * interrupts tied to ISA IRQ lines.  The IRQ is encoded as:
 *
 *      line = 0xe0 | isa_irq;
 */
#define ISA_INTR_LOW            0xe0    /* XXX ISA_INTR_FLAG */
#define ISA_INTR_HIGH           0xef

#define DEC_6600_LINE_IS_ISA(line)      ((line) >= ISA_INTR_LOW &&      \
                                         (line) <= ISA_INTR_HIGH)
#define DEC_6600_LINE_ISA_IRQ(line)     ((line) & 0x0f)


[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 'Interrupt line'
    Interrupt line: 0x00
[console]<@> # pcictl /dev/pci0 dump -d 2 | fgrep 'Interrupt line'
    Interrupt line: 0x0c
[console]<@> # pcictl /dev/pci0 dump -d 2 -f 1 | fgrep 'Interrupt line'
    Interrupt line: 0x0d
[console]<@> # pcictl /dev/pci0 dump -d 3 | fgrep 'Interrupt line'
    Interrupt line: 0x10
[console]<@> # pcictl /dev/pci0 dump -d 4 | fgrep 'Interrupt line'
    Interrupt line: 0x14
[console]<@> # pcictl /dev/pci0 dump -d 7 | fgrep 'Interrupt line'     
    Interrupt line: 0x00
[console]<@> # pcictl /dev/pci0 dump -d 15 | fgrep 'Interrupt line'
    Interrupt line: 0xee
[console]<@> # pcictl /dev/pci0 dump -d 19 | fgrep 'Interrupt line'
    Interrupt line: 0xea

[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 'Interrupt line' 
    Interrupt line: 0x18
[console]<@> # pcictl /dev/pci1 dump -d 1 -f 1 | fgrep 'Interrupt line'
    Interrupt line: 0x19
[console]<@> # pcictl /dev/pci1 dump -d 2 | fgrep 'Interrupt line'     
    Interrupt line: 0x1c
[console]<@> # pcictl /dev/pci1 dump -d 3 | fgrep 'Interrupt line'
    Interrupt line: 0x20
[console]<@> # pcictl /dev/pci1 dump -d 4 | fgrep 'Interrupt line'
    Interrupt line: 0x24
[console]<@> # pcictl /dev/pci1 dump -d 5 | fgrep 'Interrupt line'
    Interrupt line: 0x28
[console]<@> # pcictl /dev/pci1 dump -d 6 | fgrep 'Interrupt line'
    Interrupt line: 0x2c



-- 
						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>