From owner-freebsd-alpha Thu Jul 20 13: 4: 0 2000 Delivered-To: freebsd-alpha@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id DD85037B5C7 for ; Thu, 20 Jul 2000 13:03:57 -0700 (PDT) (envelope-from mjacob@feral.com) Received: from beppo.feral.com (beppo [192.67.166.79]) by feral.com (8.9.3/8.9.3) with ESMTP id NAA09587; Thu, 20 Jul 2000 13:03:45 -0700 Date: Thu, 20 Jul 2000 13:03:48 -0700 (PDT) From: Matthew Jacob Reply-To: mjacob@feral.com To: =?ISO-8859-1?Q?G=E9rard_Roudier?= Cc: freebsd-alpha@FreeBSD.ORG Subject: Re: more on- Re: fxp0 hangs on a PC164 using STABLE In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > Hmmm... I meant, first revert the patch, then add the barriers. > Damn... I know I am idiot but I thought nobody else discovered it. ;) :-) > > There's every reason to assume that they would be useful in i386 too, no? > > They may well be so, for example, in the situation of the PCI device and > its software driver sharing a completion queue in memory. Then a > serialization instruction may be needed after having picked the completion > thing from the completion queue and before checking the associated status > data. This is due to the PII/PIII also reodering LOADs/STOREs in some way. > > > It sounds to me that this would be a good argument for a simple inline or asm > > for both i386 && alpha ports. > > Agreed. > > > Now, the sparc port will be more interesting because a plain 'memory barrier' > > is not what's there - instead you have to do explicit address based flushing > > and/or invalidation (depending on the platform). > > Seems Linux does cope of that without too much complexity. Ooh, I those kind of arguments are tough to answer....:-) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message