Re: [REGRESSION] panic with Wacom One Tablet on 4.4.x kernel

On Wed, 16 Mar 2016, Ping Cheng wrote:

Yes, please provide a bisect report so we get a clue.

I do not have a "Wacom One". I have a Wacom Bamboo Pen, which goes 
through the same code base as "Wacom One". I tested kernel 4.4.4. I 
don't see the issue.

Laura, do we have any result from the bisect please?

Thanks,

-- 
Jiri Kosina
SUSE Labs

On Thu, 24 Mar 2016, Jiri Kosina wrote:

quoted

Yes, please provide a bisect report so we get a clue.

I do not have a "Wacom One". I have a Wacom Bamboo Pen, which goes 
through the same code base as "Wacom One". I tested kernel 4.4.4. I 
don't see the issue.

Laura, do we have any result from the bisect please?

BTW seems like wacom_get_report() got EPIPE and bailed out.

We used to retry on EPIPE before aef3156d72. Would it make sense to retest 
with that commit reverted?

Could be that the device is for some reason causing only temporary EPIPE 
that eventually gets fixed over time.

I still don't exactly see how that'd cause the null pointer dereference 
later, but retval handling wacom_get_report() might possibly need some 
loving care as well, looking quickly at the code. But that still needs to 
be investigated.

Thanks,

-- 
Jiri Kosina
SUSE Labs

On Mar 24 2016 or thereabouts, Jiri Kosina wrote:

On Wed, 16 Mar 2016, Ping Cheng wrote:

quoted

Yes, please provide a bisect report so we get a clue.

I do not have a "Wacom One". I have a Wacom Bamboo Pen, which goes 
through the same code base as "Wacom One". I tested kernel 4.4.4. I 
don't see the issue.

Laura, do we have any result from the bisect please?

Well, there are two users with the problem, one on Arch (reported
through linuxwacom[1]) and one on Fedora[2] that Laura mentioned. If you look
at the Fedora bug, you'll see that I found an issue in the wacom driver
that fixes the crash, and seems to make the Fedora user happy. However,
the same patch is not sufficient for the Arch user, and we are trying to
get to it in the meantime.
I think I can safely send the fix for the oops now, but we need some
clarifications on the linuxwacom issues we are seeing.

[1] https://sourceforge.net/p/linuxwacom/bugs/311/
[2] https://bugzilla.redhat.com/show_bug.cgi?id=1317116

Cheers,
Benjamin

On Thu, Mar 24, 2016 at 3:37 PM, Jiri Kosina [off-list ref] wrote:

On Thu, 24 Mar 2016, Jiri Kosina wrote:

quoted

quoted

Yes, please provide a bisect report so we get a clue.

I do not have a "Wacom One". I have a Wacom Bamboo Pen, which goes
through the same code base as "Wacom One". I tested kernel 4.4.4. I
don't see the issue.

Laura, do we have any result from the bisect please?

BTW seems like wacom_get_report() got EPIPE and bailed out.

We used to retry on EPIPE before aef3156d72. Would it make sense to retest
with that commit reverted?

Well, the problem is the device exposes a useless interface that
behaves like it should be working, but there are no sensors connected
to it. I wouldn't be surprised if the device just complains when we
are pocking at it when we should not.

Could be that the device is for some reason causing only temporary EPIPE
that eventually gets fixed over time.

I still don't exactly see how that'd cause the null pointer dereference
later, but retval handling wacom_get_report() might possibly need some
loving care as well, looking quickly at the code. But that still needs to
be investigated.

See the patch I just sent. The difference from a HID point of view
between a Bamboo Pen+Touch and a Bamboo ONE is null. However, the
Bamboo ONE has no sensors connected to the Pad and Touch interface,
and generates some spurious events. Given that all the protocol is
hardcoded in the driver, wacom.ko tries to access the pad input node
but there was none because the device is marked as "Pen only".

The solution is to actually detect the Pen only devices and check that
the HID report descriptor matches a Pen only (or detect touch+pad
interface, like I did). This was, we just don't care about the events
on the not-used interface and everybody lives happily ever after.

Cheers,
Benjamin