Subject: Re: Should Alpha PCI code manage latency timers?
To: None <bouyer@antioche.eu.org, tls@rek.tjls.com>
From: List Mail User <track@Plectere.com>
List: tech-kern
Date: 01/24/2005 15:48:49
>From bounces-tech-kern-owner-track=Plectere.com@NetBSD.org Mon Jan 24 14:11:58 2005
>X-Original-To: tech-kern@NetBSD.org
>Delivered-To: tech-kern@NetBSD.org
>Date: Mon, 24 Jan 2005 23:10:58 +0100
>From: Manuel Bouyer <bouyer@antioche.eu.org>
>To: Thor Lancelot Simon <tls@rek.tjls.com>
>Cc: port-alpha@NetBSD.org, tech-kern@NetBSD.org
>Subject: Re: Should Alpha PCI code manage latency timers?
>...
>
>On Mon, Jan 24, 2005 at 08:10:07AM -0500, Thor Lancelot Simon wrote:
>> The upshot of a rather strange recent thread in netbsd-help (titled
>> "got drivers?") was that, at least on some PCI alphas, neither SRM
>> nor our MD PCI code set devices' latency timers at all.  A user had
>> a machine with two tulips, a pciide, and a QL1040 -- only the 1040
>> worked reliably, because the isp driver explicitly whacks the latency
>> timer value to 0x40 if it finds it at 0x00.
>> 
>> The user adjusted the pciide driver to set the latency timer to 0x40
>> and all of a sudden he could use the disk and talk on the network at
>> the same time without losing packets.
>> 
>> If SRM isn't going to set the latency timer it seems to me we ought to;
>> and not in every device driver, either!
>
>As a data point, I have a Alpha DS20 server with:
>disco:/dev#pcictl pci0 list
>...
>
>All SCSI adapters and the 21140 have their latency timers set to 0xff.
>The GA620 and the PCI-PCI bridge have 0xf8. All functions of the 82C693 have 0.
>
>-- 
>Manuel Bouyer <bouyer@antioche.eu.org>
>     NetBSD: 26 ans d'experience feront toujours la difference
>--
>
	It just looks like DEC did something very weird on the Alphas in
general.

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

	It definitely seem like the issue requires someone to get access to
the current PCI-SIG documentation.

	Paul Shupak