On Mon, Jun 23, 2025 at 02:51:46PM +0200, Igor Mammedov wrote:
> On Fri, 20 Jun 2025 12:53:06 -0400
> Peter Xu <pet...@redhat.com> wrote:
>
> > On Fri, Jun 20, 2025 at 05:14:16PM +0200, Igor Mammedov wrote:
> > > This patch brings back Jan's idea [1] of BQL-free IO access,
> > > with a twist that whitelist read access only.
> > >
> > > (as BQL-free write access in [1] used to cause issues [2]
> > > and still does (Windows crash) if write path is not lock protected)
> >
> > Can we add some explanation on why it would fail on lockless writes?
> >
> > I saw that acpi_pm_tmr_write() is no-op, so I don't yet understand what
> > raced, and also why guest writes to it at all..
>
> root cause wasn't diagnosed back then, and I haven't able to
> reproduce that as well. So I erred on side of caution and
> implemented RO only.
Ah OK, I think I got that feeling it can be reproduced as above mentioned
"still does (Windows crash) if write ...".
>
> Theoretically write should be fine too, but I don't have
> an idea how to test that.
Then the question is how do we justify it will work this time..
If nobody can reproduce it anymore, there's indeed one way to go if we
strongly want to have the optimization, which is to apply it again and wait
for the reproducer to pop up once more. Just like to double check is this
the case, and we have no way to reproduce?
I also wonder whether it's still a bit late because such experiment might
be better done at the start of release cycle. Now we have roughly 3 weeks
to soft-freeze (July 15). I had a look, last time it was pretty late when
reverting the change:
975eb6a547 (tag: v2.6.0-rc4) Update version for v2.6.0-rc4 release
1beb99f787 Revert "acpi: mark PMTIMER as unlocked"
So there's also the question of whether we should land this for this
release or next when open.
Gerd mentioned this in the relevant bz:
Note: root cause for the initrd issue noted in comment 5 is seabios
running into problems with ehci -> io errors -> corrupted initrd.
Sometimes it doesn't boot at all, probably in case the io errors
happen to hit the kernel not the initrd.
This seems to be the last piece of information we have had that is closest
to the root cause. I sincerely wished there's still some way to move
forward, as it looks really close, but it might be that it was just too
late for 2.6 so we didn't got time to keep looking back then.
Thanks,
--
Peter Xu
