-
Notifications
You must be signed in to change notification settings - Fork 17
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Hard Crashes with TM 300RS #60
Comments
Hi, thanks for the report. I'll maybe try to replicate it with the demo, seems to be freely available. Does |
yes, 2 warnings:
ACPI BIOS Warning (bug): Optional FADT field Pm2ControlBlock has valid
Length but zero Address: 0x0000000000000000/0x1 (20210730/tbfadt-615)
Mär 22 20:05:34 albrecht-System-Product-Name kernel: ACPI BIOS Warning
(bug): 32/64X length mismatch in FADT/Gpe0Block: 64/32 (20210730/tbfadt-564)
Am Mi., 22. März 2023 um 17:29 Uhr schrieb Kimplul ***@***.***
…:
Hi, thanks for the report. I'll maybe try to replicate it with the demo,
seems to be freely available.
Does sudo journalctl --boot=-1 show any errors or warning?
—
Reply to this email directly, view it on GitHub
<#60 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/A4M3KT75MFTMAPDAIT2EYITW5MSIJANCNFSM6AAAAAAWEBDXNU>
.
You are receiving this because you authored the thread.Message ID:
***@***.***>
|
In the attachment there are more warnings and coloured messages out of the
journal.
Am Mi., 22. März 2023 um 22:34 Uhr schrieb Albrecht Kleinfeld <
***@***.***>:
… yes, 2 warnings:
ACPI BIOS Warning (bug): Optional FADT field Pm2ControlBlock has valid
Length but zero Address: 0x0000000000000000/0x1 (20210730/tbfadt-615)
Mär 22 20:05:34 albrecht-System-Product-Name kernel: ACPI BIOS Warning
(bug): 32/64X length mismatch in FADT/Gpe0Block: 64/32 (20210730/tbfadt-564)
Am Mi., 22. März 2023 um 17:29 Uhr schrieb Kimplul <
***@***.***>:
> Hi, thanks for the report. I'll maybe try to replicate it with the demo,
> seems to be freely available.
>
> Does sudo journalctl --boot=-1 show any errors or warning?
>
> —
> Reply to this email directly, view it on GitHub
> <#60 (comment)>,
> or unsubscribe
> <https://github.com/notifications/unsubscribe-auth/A4M3KT75MFTMAPDAIT2EYITW5MSIJANCNFSM6AAAAAAWEBDXNU>
> .
> You are receiving this because you authored the thread.Message ID:
> ***@***.***>
>
|
Am Mi., 22. März 2023 um 23:55 Uhr schrieb Albrecht Kleinfeld <
***@***.***>:
… In the attachment there are more warnings and coloured messages out of the
journal.
Am Mi., 22. März 2023 um 22:34 Uhr schrieb Albrecht Kleinfeld <
***@***.***>:
> yes, 2 warnings:
> ACPI BIOS Warning (bug): Optional FADT field Pm2ControlBlock has valid
> Length but zero Address: 0x0000000000000000/0x1 (20210730/tbfadt-615)
> Mär 22 20:05:34 albrecht-System-Product-Name kernel: ACPI BIOS Warning
> (bug): 32/64X length mismatch in FADT/Gpe0Block: 64/32 (20210730/tbfadt-564)
>
> Am Mi., 22. März 2023 um 17:29 Uhr schrieb Kimplul <
> ***@***.***>:
>
>> Hi, thanks for the report. I'll maybe try to replicate it with the demo,
>> seems to be freely available.
>>
>> Does sudo journalctl --boot=-1 show any errors or warning?
>>
>> —
>> Reply to this email directly, view it on GitHub
>> <#60 (comment)>,
>> or unsubscribe
>> <https://github.com/notifications/unsubscribe-auth/A4M3KT75MFTMAPDAIT2EYITW5MSIJANCNFSM6AAAAAAWEBDXNU>
>> .
>> You are receiving this because you authored the thread.Message ID:
>> ***@***.***>
>>
>
|
Tried downloading the demo, haven't exprienced a full system crash yet. The game itself has crashed a couple times and the text in game seems to be messed up. Could you specify under which situation you encountered the crash? I.e. are you running the game through Lutris, which Wine version are you using, which tracks and cars, etc? Sidenote, no attachment seems to have come through. Not sure if interacting with GitHub through email supports attachments. |
Sorry for the troubles I caused you. |
Not at all, a crash is a pretty serious thing and I appreciate the report.
Unfortunate, makes debugging that much more difficult. Out of curiosity, did you accidentally close the issue or are you implying the system crashes even when not using the wheel? Unpredictability doesn't necessarily mean that this driver isn't the culprit, I could just have some edge case in my concurrent code that only occasionally does something dumb. Thanks for the attachment, seems to have been included this time. Unfortunately doesn't seem to include anything too relevant to this situation. |
No, the system crashes occure only while driving GPL and using the TM 300RS with the ffb-driver. Driving GPL without ffb-driver I had and have no problems. |
Right, I'd prefer keeping this issue open in that case. I'll do some more digging with your tips and see what happens. |
Meanwhile I have tested the system for ca. 5 hours successfully without any crash. Actually I wanted to confirm you that everything is alright. But then it happens again! |
Seems to be pretty infrequent, interesting. Thanks for the log file. It seems like you've filtered it somehow, as I would expect there to be a couple messages from this driver after |
Too bad, the Login-journal from yesterday 17:41 isn't available any longer and the login from 19:29 no longer contains this error, see line 748. |
Here the complete Log-Journal from today with the error-massage again. |
Thanks for the full logs, I had a quick look through and noticed that it seems like
This would indicate that this driver isn't even being used for some reason. Did you uninstall the driver at some point, or did you maybe upgrade your kernel? If you installed the driver manually, you need to reinstall it after every kernel upgrade. If you installed the driver with The error message is 'fine', the wheel abruptly restarts itself and the kernel subsystem typically reports an error to the driver about it. The wheel seems to still be initialized, as otherwise it wouldn't be picked up by Here's the corresponding lines to the error: As you can probably imagine, returning an error on an 'ok' action is easily pretty confusing. EDIT: To clarify, after the |
For reference, here's what it looks like on my machine when this driver picks up the wheel:
Note the last two lines, with confirmation from this driver that it's being loaded. EDIT: I initially used |
If I understand you right, it seems the driver may not be properly loaded when Linux is starting. PS: I am afraid I haven't understand completely your remarks in the EDIT. How can I create a better journal? It's a bit awkward to mark, copy and paste the whole output of the terminal to put it in a simple txt. |
Sounds like it, yes. Although if I interpret your comment correctly, it seems like there is some possibility of the message simply being left out?
I understand, and I'm very sorry but so far I haven't been able to reproduce anything. The logs you've provided are greatly appreciated, but they haven't revealed anything to me, and I'm still not sure what the issue could be. I haven't done any long testing sessions yet, just short ones every now and then when I've had the time, but I might try and reserve some time to try a more continuous test. If the game crashes every five hours, it might be that I've just missed a crash by luck or something. So far, your logs have shown that the system has been shut down in a semi-controlled manner, without any obvious kernel error messages. This could be because a lot of different reasons, for example X crashing, but if the logs are only semi-complete, I wouldn't trust on it.
Alright, that's good.
Yes please, that could be useful.
One way could be to run |
I have got the driver now on three Linux installations. With one of them (PC1) a crash happened again.
|
I don't think having the wheel plugged in would cause a crash, I mainly included that to make sure the driver would get properly loaded. From the journals I can see that the driver is being loaded, which is good. I have to slightly correct one of my previous comments, I just realized that the sample
which is essentially what I can see from your logs. Although I still can't see any obvious error messages that would relate to a crash. Out of curiosity, are you able to switch to a virtual terminal after a crash?
I have to admit I don't understand why a specific processor model would cause such an issue, but the correlation looks like it might be there. Although if the processor is causing the crash, I'm not surprised it worked on Windows, as the code in Windows is completely different than Linux. Having to run apps through an emulation layer etc. probably doesn't help either. Still haven't sat down for a longer gaming session. Looking forward to seeing if we can replicate the crash on some other processor. |
Thank you so much. I hope this will be the solution to the riddle. Nevertheless I will continue to test the other computers (PC5 and PC9) and inform you about the result, even if no more crashes should happen.
Up till now I only tried the ctrl+alt+del combination to leave the desktop after a crash. But I had to switch off the PC with the power button every time. Although it seems that no keyboard input is accepted I will try to open a virtual terminal then. |
I have tested the driver now for many hours but with the FX-Prozessor no further crashes had happened. For me it seems to be clear that the outdated AMD-Prozessor Athlon II X2 280 and not the driver provided the cause. |
Hello,
with the hid-tmff2-driver most of the ffb-effects were implemented very well. But unfortunately when I race with Grand Prix Legends using this driver the whole system crashes after a while. Other racing simulations I haven't tested yet. For me, this means that serious online races with GPL cannot be contested. I would be very happy if this problem could be solved.
My System:
Linux Mint 21.1
Wine 6.0.3
Kernel 5.15.0-58
TM Firmware 34.0 (Package 2023)
Grand Prix Legends v.1.2 (F1 1967 and F1 1969)
The text was updated successfully, but these errors were encountered: