UAPI module + iptsd hangs on SB1 #5
Comments
|
This is perhaps separate issue also resulting in touch hang. I figured I'll put it here in case they're connected. In this case, iptsd crashes with No logs from the driver. |
|
[ Sorry for not coming back to this earlier, was a bit busy irl ] Could you try this? I.e. instead of removing the check entirely, let it warn, but then return without an error. This is probably more useful, since an error returned by diff --git a/control.c b/control.c
index 857bcf4..c2754aa 100644
--- a/control.c
+++ b/control.c
@@ -24,11 +24,11 @@ int ipts_control_send(struct ipts_context *ipts,
if (ret >= 0)
return 0;
+ dev_err(ipts->dev, "MEI error while sending: 0x%X:%d\n", cmd, ret);
+
if (cmd == IPTS_CMD(FEEDBACK) && ret == -IPTS_ME_STATUS_NOT_READY)
return 0;
- dev_err(ipts->dev, "MEI error while sending: 0x%X:%d\n", cmd, ret);
-
return ret;
}This will most likely spam your dmesg the entire time while you are using it. What I am interested in is whether the spam will continue after touch started hanging (and what error code is returned). The iptsd error looks like it received an invalid data buffer, which is weird, but probably not related to touch hang. |
|
OK, got a hang with the new patch. Here's the journal log: There was only one hang, though. As such, it's not clear whether the last of these events actually has any relation to it, since the first 14 clearly don't. I'll combine that with printing doorbell to determine. |
|
I can confirm that there's NO |
|
I did some further investigation, but can you offer some clarifications: I added debug output to I also added doorbell prints in the main cycle in On the driver side, I added some debug outputs is the feedback functions as well. When IPTS hanged, I stopped iptsd without unloading the driver. After launching a new instance if iptsd (after stopping the running one), I get the following output from it: So no calls to On the other hand, in Showing that somehow on the driver side the feedback function gets called several times. This doesn't cause ipts to 'unhang'. I double-checked by adding an extra send feedback call before the iptsd main cycle: which returned from iptsd, and from dmesg. This extra call also didn't fix the hang. Do you have suggestions what else could be worth looking at? |
|
The feedback commands from your dmesg come from the flush that iptsd does on startup (it sends feedback for every buffer once to clear any old data). If you move your print from Since feedback gets through, but the doorbell doesn't increase, I think this is probably an issue in the ME firmware. It simply dies below our feet. Btw, does a module reload fix the issue? Or do you have to restart? |
|
Module reload fixes the issue. @kitakar5525 do you think whatever was causing the hang with the old driver could be related (though it's not very likely, since I didn't have problems with the old driver). |
|
Interestingly, I've never encountered any crashes (except suspend that fixed recently) on this ipts driver (that don't use guc submission) on my SB1. It's true that there are some not known differences between yours and mine. What's your firmware version now? |
|
@kitakar5525 Here's what I have - it's older. I'm skeptical that this is what causes the problem but perhaps it's time to update anyway. |
|
Hmm, the firmware version seems new enough... |
I would occasionally get hangs when using the uapi driver with iptsd. Nothing is outputted to journal when the hang happens.
When printing the doorbell to dmesg, it stops increasing when the hang happens.
When I comment out https://github.com/linux-surface/intel-precise-touch/blob/master/control.c#L27, the driver crashes very quickly. Here's the journal:
The text was updated successfully, but these errors were encountered: