On 2/10/20 9:49 PM, Boris ARZUR wrote:
Hello Guenter,
In the meantime, can you by any chance test the attached patch ? It _might_
fix the problem, but it is a bit of a wild shot.
I tried your patch, but the machine does not finish booting.
Weird. Can you enable pstore ? That should work on this system. Then you would
have the log from the previous boot in /sys/fs/pstore/.
I would like to give you a dump, but the screen scrolls fast, and what's
left when paused is not interesting. How do I get it to dump on disk?
My journalctl doesn't show anything. I have no kmesg.log anywhere.
The first time around I was 0/ changing fonts 1/ trimming the dump message
in the kernel 2/ filming my screen. That's not practical at all...
I have been looking a bit at things. I believe that part of the issue
is the need to re-align the buffer we get in the URB. I'm wondering if asking
for a specific alignment when creating the URB could be doable.
As a stop-gap, maybe doing things like in tegra ehci could fix our bug:
https://github.com/torvalds/linux/blob/master/drivers/usb/host/ehci-tegra.c#L288
i.e. having the old pointer before the new buffer instead of at the end of
it.
Yes, that was the original solution. Unfortunately it didn't really DMA-align
buffers, so the temporary pointer was moved to the end. It still doesn't guarantee
DMA alignment, though, so I am working on fixing that and moving the old pointer
back to the beginning.
Now if something is overwriting the buffer end, that would also be hiding the
issue... but if the bug is related to lengths that don't match between
allocation and free, that could work. In this case, that would also be
hiding the issue :)
Yes, that is why moving the old pointer to the beginning won't be sufficient.
Either case, if the current patch causes a boot loop there is obviously something
wrong with it, or the fix is incomplete. I'll keep trying to get equipment
that lets me reproduce the problem.
Thanks for trying!
Guenter
