From owner-freebsd-current Mon Jul 12 10:43: 3 1999 Delivered-To: freebsd-current@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (Postfix) with ESMTP id 23527150E1 for ; Mon, 12 Jul 1999 10:42:56 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id KAA70526; Mon, 12 Jul 1999 10:42:38 -0700 (PDT) (envelope-from dillon) Date: Mon, 12 Jul 1999 10:42:38 -0700 (PDT) From: Matthew Dillon Message-Id: <199907121742.KAA70526@apollo.backplane.com> To: John-Mark Gurney Cc: Luoqi Chen , dfr@nlsystems.com, jeremyp@gsmx07.alcatel.com.au, freebsd-current@FreeBSD.ORG, mike@ducky.net Subject: Re: "objtrm" problem probably found (was Re: Stuck in "objtrm") References: <199907121032.GAA14268@lor.watermarkgroup.com> <199907121647.JAA70249@apollo.backplane.com> <19990712103845.39296@hydrogen.fircrest.net> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :actually, I'm not so sure, it guarantees that NO other bus operation :will succeed while this is happening... what happens if a pci bus :mastering card makes a modification to this value? sure, it normally :won't happen, but it can... and w/o the lock prefix, this CAN happen :from what I understand of the architecture... : :so, it does have to lock even the memory bus, simply the cache isn't :enough for the lock to do what it needs... : :-- : John-Mark Gurney Voice: +1 541 684 8449 : Cu Networking P.O. Box 5693, 97405 As I said, it depends what L1/L2 cache model intel is using. If they are being smart it does *NOT* prevent other bus operations from occuring, it simply locks the cache line containing the item for the duration of the instruction. The worst case should be an extra snoop on the bus. Hold on, I have some numbers. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message