> ok. Is it more of a "gets flushed due to timing out", or a > specified-for-sure POST flushing property of all out 0x80 cycles going > to the PCI bridge? I thought PCI posting policy is up to the CPU, it can > delay PCI space writes arbitrarily (within reasonable timeouts) as long > as no read is done from the _same_ IO space address. Note that the port > 0x80 cycle is neither a read, nor for the same address.
Its what appears to happen reliably on real computers. > i'm wondering, how safe would it be to just dumbly replace outb_p() > with: > > out(port); > in(port); Catastrophic I imagine. If the delay is for timing access then you've just broken the timing, if the port has side effects you've just broken the driver. > in these drivers. Side-effects of inb() would not be unheard of for the > ancient IO ports, but for even relatively old SCSI hardware, would that > really be a problem? The specific drivers need reviewing. There are very few uses in PCI space so it's a minor job. > ah, i understand. So i guess a stupid udelay_serialized() which takes a > global spinlock would solve these sort of races? But i guess making them > more likely to trigger would lead to a better kernel in the end ... Better to just fix the drivers. I don't think that will take too many days after everyone is back working. > doing it - but we'll do the plunge in v2.6.25 and make io_delay=udelay > the default, hm? Thomas has a real 386DX system, if that doesnt break For processors with TSC I think we should aim for 2.6.25 to do this and to have the major other _p fixups done. I pity whoever does stuff like the scc drivers but most of the rest isn't too bad. Alan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
