On Tue, Aug 21, 2018 at 3:40 PM Mikulas Patocka <mpatocka@xxxxxxxxxx> wrote:
> On Tue, 21 Aug 2018, Arnd Bergmann wrote:
> > On Mon, Aug 20, 2018 at 11:42 PM Mikulas Patocka <mpatocka@xxxxxxxxxx> wrote:
> > > On Mon, 20 Aug 2018, Arnd Bergmann wrote:
> > > > On Mon, Aug 20, 2018 at 4:17 PM Mikulas Patocka <mpatocka@xxxxxxxxxx> wrote:
> > > > > On Sun, 19 Aug 2018, okaya@xxxxxxxxxxxxxx wrote:
> >
> > Ok, this does strongly suggest that it is the outb() operation that I
> > suspected after all, I just sent you a wrong patch to test, failing
> > to realize that alpha has two implementations of outb, and that the
> > extern one is the one that gets used in a defconfig build.
> >
> > Could you try again with this patch added in? (Sorry for the whitespace
> > damage, you'll have to apply it by hand). Presumably a wmb()
> > is sufficient here, but I'm trying to play safe here by restoring the
> > barrier that was part of outb() before it broke.
> >
> > Arnd
>
> This patch fixes both hangs.
Ok, thanks for confirming. Now the question is whether this is only needed
for I/O space writes to ensure that an outb() etc completes before we start
the next instruction as in my first theory above, or if the readl()
getting moved
ahead of a prior writel() as Maciej suggested could also happen for
memory space.
My guess would be that even on something as weakly ordered as Alpha,
the PCI semantics are kept that a load from a non-prefetchable PCI MMIO
space can not get moved ahead of a preceding store to the same PCI
device from the same CPU, but I don't really know enough about alpha.
Arnd
