Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Fri, 18 Jan 2002 18:10:39 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Fri, 18 Jan 2002 18:10:30 -0500 Received: from lightning.swansea.linux.org.uk ([194.168.151.1]:33803 "EHLO the-village.bc.nu") by vger.kernel.org with ESMTP id ; Fri, 18 Jan 2002 18:10:21 -0500 Subject: Re: [PATCH] IBM Lanstreamer bugfixes To: yoder1@us.ibm.com (Kent E Yoder) Date: Fri, 18 Jan 2002 23:19:08 +0000 (GMT) Cc: alan@lxorguk.ukuu.org.uk (Alan Cox), jgarzik@mandrakesoft.com (Jeff Garzik), linux-kernel@vger.kernel.org In-Reply-To: from "Kent E Yoder" at Jan 18, 2002 05:02:57 PM X-Mailer: ELM [version 2.5 PL6] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: From: Alan Cox Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org > BTW, I don't know what PCI posting effects are... Ok given writel(foo, dev->reg); udelay(5); writel(bar, dev->reg); The pci bridge is at liberty to delay the first write until the second or a read from that device comes along (and wants to do so to merge bursts). It tends to bite people - When they do a write to clear the IRQ status and don't do a read so they keep handling lots of phantom level triggered interrupts. - When there is a delay (reset is common) that has to be observed - At the end of a DMA transfer when people unmap stuff early and the "stop the DMA" command got delayed Alan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/