[ I'm forwarding this email to the list, sans the kdump output
which I already mailed privately. ]
2017-09-20 07:47:37, Martin Pieuchot <m...@openbsd.org> wrote:
> On 20/09/17(Wed) 01:02, Anthony J. Bentley wrote:
> >
> > Once it's frozen ktrace seems to show no output. Here's the last few
> > lines if I run ktrace from the start:
> > [...]
> > 90169 gambatte_sdl CALL read(5,0x18f94585a804,0x4)
>
> So it seems that the sleeping thread isn't awaken. Bryan Linton
> provided some additional information, he said that emulators/mednafen
> still work for him.
>
> Do you know if the games are multi-threaded? Could you run "top -H" and
> "kdump -H"?
>
Running top gives the following:
PID TID PRI NICE SIZE RES STATE WAIT TIME CPU COMMAND
62482 253828 0 0 97M 25M sleep/0 uhidrea 0:08 12.40% dgen
62482 448260 2 0 97M 25M sleep/2 poll 0:00 2.54% dgen
PID TID PRI NICE SIZE RES STATE WAIT TIME CPU COMMAND
31892 243344 0 0 34M 24M sleep/3 uhidrea 0:01 0.49% mgba
The entire "kdump -H" output was mailed privately.
> Could you also run a kernel compiled with the following diff and see if
> something is printed in the dmesg when the program "freeze"?
>
When I run dgen (the one with two threads) I get the entire dmesg
buffer filled with "uhidread" over and over again. After I "pkill -9"
it, I get the following two lines at the end:
uhidclose: sc=0xffff80000057be00
xhci0: NULL xfer pointer
Running mgba (the single threaded one), I get the same output of
"uhidread" over and over again, with only the following printed
after pkilling it.
uhidclose: sc=0xffff80000057be00
The following dmesg output was from multiple runs followed by
"pkill -9" of dgen and mgba. It looks like some other diagnostics
are getting printed in between the "uhidread" messages as well.
% wc -l dmesg-uhid.txt
7215 dmesg-uhid.txt
% uniq -c dmesg-uhid.txt
1 d
3593 uhidread
1 uhidclose: sc=0xffff80000057be00
1 xhci0: NULL xfer pointer
1 uhidopen: sc=0xffff80000057be00
1 uhidioctl: cmd=44045515
1 uhidioctl: cmd=40045519
1 uhidioctl: cmd=8004667e
1 uhidioctl: cmd=8004667d
1 uhidioctl: cmd=8004667e
1 uhidclose: sc=0xffff80000057be00
1 uhidopen: sc=0xffff80000057be00
1 uhidioctl: cmd=44045515
1 uhidioctl: cmd=40045519
1 uhidioctl: cmd=8004667e
1 uhidioctl: cmd=8004667d
1 uhidioctl: cmd=8004667e
1777 uhidread
1 uhidclose: sc=0xffff80000057be00
1 xhci0: NULL xfer pointer
1 uhidopen: sc=0xffff80000057be00
1 uhidioctl: cmd=44045515
1 uhidioctl: cmd=40045519
1 uhidioctl: cmd=8004667e
%
Also, for the archives, when I went back and bisected snapshots from
https://ftp.hostserver.de/archive/, I ended up with the following
in my notes:
2017-07-30 NOT WORKING!
2017-07-25 NOT WORKING!
2017-07-22 NOT WORKING!
2017-07-21 Works!
2017-07-20 Works!
2017-07-15 Works!
2017-07-10 Works!
So the 07-21 snapshot was the last one that worked for me. I
figured it would probably be worth mentioning just in case.
I already said this privately, but I'd like state again my
thanks to mpi@ for taking the time to look into this issue.
Thank you! :)
--
Bryan
