Voodooi2c: readRegister/writeRegister at offset 0xXX failed since mamory was not mapped

[marianopela]

Strange behaviour sometimes (most of them) with 2.4
Seems like VoodooI2CHID is not loaded

Could It be related to https://github.com/alexandred/VoodooI2C/pull/258 ?
@Hasodikis is experiencing this too

log.txt

[ben9923]

@lvs1974 Please take a look :)

[lvs1974]

@ben9923, there is nothing to worry about here. To avoid crashes memory is unmapped before sleep an mapped again after sleep. But interrupt is occurred a bit earlier than memory was mapped again. It tries to read an interrupt status, read Register returns 0, and it as considered as interrupts are disabled.
Probably interrupts should be disabled before sleep and enabled after wake and memory mapping.

[marianopela]

Probably interrupts should be disabled before sleep and enabled after wake and memory mapping.

It happens at boot
Anyway it is somehow related to my DSDT patches, but I still haven't figured out why

[lvs1974]

@marianopela, could you collect all these messages from your log (with offsets), please?
I will try to find out places from where they are called and fix it.
But anyway, we can consider it just as a warnings.

[marianopela]

@marianopela, could you collect all these messages from your log (with offsets), please?
I will try to find out places from where they are called and fix it.
But anyway, we can consider it just as a warnings.

They are collected from my log. I just cut some of them when they repeated many times
Here is the complete one
kernel_log.txt

[lvs1974]

@marianopela, actually something is totally wrong:
(IOHIDFamily) VoodooI2CHIDDevice:0x10000031a stop
IOHIDFamily stopped VoodooI2CHIDDevice.
readRegister & writeRegister failed after, and with previous versions it would be a kernel panic.

[kprinssu]

@lvs1974 @marianopela any updates on the underlying issue?

[lvs1974]

@kprinssu: something is totally wrong in configuration, without protection in readRegister/writeRegister I think we would get a kernel panic.

[marianopela]

@lvs1974 @marianopela any updates on the underlying issue?

I only experienced this issue some times, while trying to make my trackpad work with interrupts (without any luck)

Trackpad is still not working with interrupts (apart from a small movement immediately after login, which I can't explain), but the logs are clean now, as you can see here

[marianopela]

@Goshin hope not to bother you. Do you think that me not being able to run with GPIO interrupts is depending on Voodoo I2C/GPIO implementation? I can't find anything strange from the logs (eg. the one attached in the message above this). If there's any way to debug this, please let me know. Also, @dreamwhite and I have different hardware but the same MSFT0001 device

[Goshin]

In my view, it mostly depends on whether you choose the right pin number and the interrupt type or not. VoodooGPIO checks the pin number with the incoming interrupt from the GPIO controller, then it will call the handler of VoodooI2CHID if the pin matches.

I can give you a debug kext. It doesn't work properly but just to log all the unregistered pins that are generating interrupts, so maybe one of them is the correct pin for your touchpad.
Archive.zip

[dreamwhite]

Uhm. My available pins (due to the SunrisePointLP I2C controller) are 0x1B and 0x7B. My interrupt pin is 0x33 so you may try giving it a look

[marianopela]

I can give you a debug kext. It doesn't work properly but just to log all the unregistered pins that are generating interrupts, so maybe one of them is the correct pin for your touchpad.
Archive.zip

Thanks, I really really appreciate it. Should I configure my device in any special way? Because I can't seem to find any added information from the logs

[Goshin]

I can give you a debug kext. It doesn't work properly but just to log all the unregistered pins that are generating interrupts, so maybe one of them is the correct pin for your touchpad.
Archive.zip

Thanks, I really really appreciate it. Should I configure my device in any special way? Because I can't seem to find any added information from the logs

Try to use it in GPIO mode.

[marianopela]

@Goshin I don't know how but something has changed after a few reboots

Here is the log. 0x108.txt
It seems to output only the chosen pin 0x108 though

[Goshin]

@Goshin I don't know how but something has changed after a few reboots

Here is the log. 0x108.txt
It seems to output only the chosen pin 0x108 though

Sorry, forget about it. I forgot the pin lines need to be set to enable the interrupts, and it seems infeasible to enable all the pins in my testing; I got a kernel panic immediately. So you may need to find another way out, maybe it is not related to the pin choice since it does generate interrupts when you touch the touchpad.

[kprinssu]

Additionally, there are issues setting up pin numbers higher than a certain value. It is due to way the macOS architecture and design choices. @coolstar or @ben9923 know more on the issue than myself.

[edd1024]

@Goshin Actually the idea is pretty cool, I imagine there is a tool for monitoring the I2C bus for debugging purposes.

[Goshin]

The "readRegister/writeRegister failed" error should be fixed in v2.4.2, in which I2C bus manipulation is disabled when the registers are unmapped.

[kprinssu]

@Goshin closing this then. @marianopela please reopen if issue persists.

[Goshin]

@kprinssu there is still a minor miss in VoodooI2CControllerDriver::stop(), though it is unrelated to this issue according to the log. I can open a PR later.

[kprinssu]

@Goshin please do.