VoodooSMBus / VoodooRMI

Synaptic Trackpad driver over SMBus/I2C for macOS
GNU General Public License v2.0
233 stars 19 forks source link

"SYNA2B42" Randomly Resets #64

Closed kuramaju closed 3 years ago

kuramaju commented 3 years ago

Describe the bug I look at IORegistryExplorer, the device name shows up as <"SYNA2B42">. Not a bug/issue as much as my attempt to use VoodooRMI on a device that's not on your list. Catalina 10.15.6, OpenCore 0.6.1, Lenovo laptop i7-8550U, VoodooI2C.kext.

The trackpad works for a minute or two freshly after boot, and then it stops responding.

Once the trackpad stops working, Console keeps on repeating these two lines:

kernel: (RMII2C) VRMI - Error: RMII2C::TPD0 RMI_READ_DATA_REPORT_ID mismatch 1 kernel: (VoodooRMI) VRMI - Error: Unable to read IRQ

To Reproduce Steps to reproduce the behavior: I believe the relevant kexts are VoodooI2C.kext and VoodooRMI.kext. Boot. Watch trackpad work. Play around for a minute or two. Watch it stop working. Go to Console at review log.

Expected behavior Not sure what to expect, since the device name isn't on the list yet.

Log I might have to use the debug version of VoodooRMI and capture a better log, if that's going to be part of the effort to get this working. Let me know what to do here.

1Revenger1 commented 3 years ago

Hrm, in a stroke if brilliance, I made the device reset status message only appear in the Debug version of the kext! I'd appreciate if you can get a log for me using log show --last boot | grep -i VRMI with the debug version. You can redirect it to a file with > ~/Desktop/log.txt appended on the end of the above command. Thanks

kuramaju commented 3 years ago

Thanks for the interest in my hardware. I had to play around for a while until the trackpad stopped working (I almost thought it was one of those problems that magically evaporate as soon as you try to document it), so the log is 6 MB of boring when unzipped. log.txt.zip

1Revenger1 commented 3 years ago

Mind giving the above PR a try? Should be able to click the green check mark next to the commits below the description of the PR. That'll take you to Github actions, where built artifacts are on the right as a ZIP download.

zhen-zen commented 3 years ago

Can you monitor it with log stream --predicate 'processID=0 && (senderImagePath contains "RMI" and message contains "Error")

zhen-zen commented 3 years ago

I'm not sure if it's just a one time event. It seems like the touchpad itself encountered some error and reseted itself. And I suppose it will still happen periodically.

muhamad-rizki commented 3 years ago

Mind giving the above PR a try? Should be able to click the green check mark next to the commits below the description of the PR. That'll take you to Github actions, where built artifacts are on the right as a ZIP download.

hey I have same issue, I have tried this PR build and issue fixed 👍

zhen-zen commented 3 years ago

@muhamad-rizki This build is only a temporary fix. And there is an additional log feature to capture some details, which may help understanding what's going wrong. Could you try the latest debug build in that branch and upload the log?

muhamad-rizki commented 3 years ago

_> @muhamad-rizki This build is only a temporary fix. And there is an additional log feature to capture some details, which may help understanding what's going wrong. Could you try the latest debug build in that branch and upload the log?

what log I need to capture? here I put boot log and log when touchpad used log_rmi.zip btw my touchpad is

zhen-zen commented 3 years ago

_> @muhamad-rizki This build is only a temporary fix. And there is an additional log feature to capture some details, which may help understanding what's going wrong. Could you try the latest debug build in that branch and upload the log?

what log I need to capture? here I put boot log and log when touchpad used log_rmi.zip btw my touchpad is

It's quite weird, since the anticipated error (RMI_READ_DATA_REPORT_ID mismatch) doesn't exist in the log, then this fix is not applied. Do you have the exact same error log described above with old kext? Or maybe that's another issue fixed before.

muhamad-rizki commented 3 years ago

_> @muhamad-rizki This build is only a temporary fix. And there is an additional log feature to capture some details, which may help understanding what's going wrong. Could you try the latest debug build in that branch and upload the log? what log I need to capture? here I put boot log and log when touchpad used log_rmi.zip btw my touchpad is

It's quite weird, since the anticipated error (RMI_READ_DATA_REPORT_ID mismatch) doesn't exist in the log, then this fix is not applied. Do you have the exact same error log described above with old kext? Or maybe that's another issue fixed before.

yep before trying the patch I got this error kernel: (RMII2C) VRMI - Error: RMII2C::TPD0 RMI_READ_DATA_REPORT_ID mismatch 1 kernel: (VoodooRMI) VRMI - Error: Unable to read IRQ then error is gone after I tried your patch, i'll try the latest release, then report to you again later, cause it's happened occasionally. I thought it's not the problem from voodoormi, maybe something wrong with irq acpi patching, well I'll let you know if it's error coming from latest build

muhamad-rizki commented 3 years ago

@zhen-zen here I attached log from build latest release (v1.1.0) and log from latest patched build log_rmi2.zip

zhen-zen commented 3 years ago

@zhen-zen here I attached log from build latest release (v1.1.0) and log from latest patched build log_rmi2.zip

Thank you! According to the last log, connection lost only happened once and didn't occurred after reset. Maybe it's just a firmware issue and just a simple reset will work.

@kuramaju Can you try whether it could fix yours?

zhen-zen commented 3 years ago

It seems that the trackpad itself stuck when probing IRQ during the 0.1s and by default enter mouse mode after reboot. Is it necessary to re-initialize again or just resume is enough? @1Revenger1

kernel: (RMII2C) VRMI - Error: RMII2C::TPD0 RMI_READ_DATA_REPORT_ID mismatch 0
kernel: (RMII2C) VRMI - Debug:  0 0 0 0 0
kernel: (VoodooRMI) VRMI - Error: Unable to read IRQ
kernel: (RMII2C) VRMI - Error: RMII2C::TPD0 RMI_READ_DATA_REPORT_ID mismatch 0
kernel: (RMII2C) VRMI - Debug:  0 0 0 0 0
kernel: (VoodooRMI) VRMI - Error: Unable to read IRQ
kernel: (RMII2C) VRMI - Error: RMII2C::TPD0 RMI_READ_DATA_REPORT_ID mismatch 0
kernel: (RMII2C) VRMI - Debug:  0 0 0 0 0
kernel: (VoodooRMI) VRMI - Error: Unable to read IRQ
kernel: (RMII2C) VRMI - Error: RMII2C::TPD0 RMI_READ_DATA_REPORT_ID mismatch 0
kernel: (RMII2C) VRMI - Debug:  0 0 0 0 0
kernel: (VoodooRMI) VRMI - Error: Unable to read IRQ
kernel: (RMII2C) VRMI - Error: RMII2C::TPD0 RMI_READ_DATA_REPORT_ID mismatch 0
kernel: (RMII2C) VRMI - Debug:  0 0 0 0 0
kernel: (VoodooRMI) VRMI - Error: Unable to read IRQ
kernel: (RMII2C) VRMI - Error: RMII2C::TPD0 RMI_READ_DATA_REPORT_ID mismatch 0
kernel: (RMII2C) VRMI - Debug:  0 0 0 0 0
kernel: (VoodooRMI) VRMI - Error: Unable to read IRQ
kernel: (RMII2C) VRMI - Error: RMII2C::TPD0 RMI_READ_DATA_REPORT_ID mismatch 0
kernel: (RMII2C) VRMI - Debug:  0 0 0 0 0
kernel: (VoodooRMI) VRMI - Error: Unable to read IRQ
kernel: (RMII2C) VRMI - Error: RMII2C::TPD0 RMI_READ_DATA_REPORT_ID mismatch 0
kernel: (RMII2C) VRMI - Debug:  0 0 0 0 0
kernel: (VoodooRMI) VRMI - Error: Unable to read IRQ
kernel: (RMII2C) VRMI - Error: RMII2C::TPD0 RMI_READ_DATA_REPORT_ID mismatch 0
kernel: (RMII2C) VRMI - Debug:  0 0 0 0 0
kernel: (VoodooRMI) VRMI - Error: Unable to read IRQ
kernel: (RMII2C) VRMI - Error: RMII2C::TPD0 RMI_READ_DATA_REPORT_ID mismatch 0
kernel: (RMII2C) VRMI - Debug:  0 0 0 0 0
kernel: (VoodooRMI) VRMI - Error: Unable to read IRQ
kernel: (RMII2C) VRMI - Error: RMII2C::TPD0 RMI_READ_DATA_REPORT_ID mismatch 0
kernel: (RMII2C) VRMI - Debug:  0 0 0 0 0
kernel: (VoodooRMI) VRMI - Error: Unable to read IRQ
kernel: (RMII2C) VRMI - Error: RMII2C::TPD0 RMI_READ_DATA_REPORT_ID mismatch 0
kernel: (RMII2C) VRMI - Debug:  0 0 0 0 0
kernel: (VoodooRMI) VRMI - Error: Unable to read IRQ
kernel: (RMII2C) VRMI - Error: RMII2C::TPD0 RMI_READ_DATA_REPORT_ID mismatch 0
kernel: (RMII2C) VRMI - Debug:  0 0 0 0 0
kernel: (VoodooRMI) VRMI - Error: Unable to read IRQ
kernel: (RMII2C) VRMI - Error: RMII2C::TPD0 RMI_READ_DATA_REPORT_ID mismatch 0
kernel: (RMII2C) VRMI - Debug:  0 0 0 0 0
kernel: (VoodooRMI) VRMI - Error: Unable to read IRQ
kernel: (RMII2C) VRMI - Error: RMII2C::TPD0 RMI_READ_DATA_REPORT_ID mismatch 0
kernel: (RMII2C) VRMI - Debug:  0 0 0 0 0
kernel: (VoodooRMI) VRMI - Error: Unable to read IRQ
kernel: (RMII2C) VRMI - Error: RMII2C::TPD0 RMI_READ_DATA_REPORT_ID mismatch 0
kernel: (RMII2C) VRMI - Debug:  0 0 0 0 0
kernel: (VoodooRMI) VRMI - Error: Unable to read IRQ
kernel: (RMII2C) VRMI - Error: RMII2C::TPD0 RMI_READ_DATA_REPORT_ID mismatch 1
kernel: (RMII2C) VRMI - Debug:  6 0 1 0 0
kernel: (RMII2C) VRMI - Info: RMII2C::TPD0 reset completed
kernel: (VoodooRMI) VRMI - Error: Unable to read IRQ
1Revenger1 commented 3 years ago

Likely the minimum amount of code that's needed to run is the resume code under setPowerState in RMIBus.cpp, as that'll scan the PDT again (don't know why it needs this) and rewrite all the IRQ data. That is if it's still erroring out after the reset is done in RMII2C

Edit: Oh, some of the functions do write to the config registers in start, that likely should be done as well, but isn't needed to run.

zhen-zen commented 3 years ago

Could we assume the IRQ doesn't change for the same model? How about call setPowerState directly?

@kuramaju @muhamad-rizki can you try the latest build of #65 ?

1Revenger1 commented 3 years ago

IRQ is based off of the order of discovery for the different functions, and how they are ordered in the registers. If it changes, something is very wrong. So yeah it shouldn't change.