Comments

50 Comments

Hmm, if /sys/fs/cgroup/memory/user.slice/memory.* sounds like a cgroupv1 path. I didn't think that Fedora supports that at this point. Or am I missing something?

Test is appreciated as there might be regressions that have not yet been found by other distros.

Sorry, I forgot to add a comment here.

The summary of the issue is, that libusb upstream improved the logging. This caused an invalid pointer to be dereferenced in some situations. Unfortunately, my fix to address this broke the synchronous libusb API.

This update has been unpushed.

OK, my last regression fix was broken …

Thanks, that should be helpful!

I am at a total loss right now. libfprint also has issues. So, I am hoping this is some odd corner case which makes things break both in the sync API and when using threads (sane is sync, libfprint uses libgusb which has a separate thread to handle events).

wrt. to sane, it looks like it uses the blocking libusb API all over the place. Maybe there is a regression in that way of using libusb.

OK, so, I think the problem that @plumlis is seeing may be solved by the update. But, if not, please re-grab the log and first step fprintd manually or modify the systemd service, see https://gitlab.freedesktop.org/libfprint/fprintd/-/blob/master/README. Adding LIBUSB_DEBUG=4 is still important.

But, the "[ 0.002220] [000175d0] libusb: debug [handle_event_trigger] hotplug message received" message, means that it may very well be the linked issue.

As for the problem that @tinigriffy is seeing, still no idea. I suppose that is a "sane" scanner, but I don't really know anything about how sane uses libusb.

Oh, fingerprint reader. Could you try to also pulling in https://bodhi.fedoraproject.org/updates/FEDORA-2022-000a6480b4

I need to check some stuff, but it might be an interesting data point. That sounds like https://gitlab.freedesktop.org/libfprint/fprintd/-/issues/119 which should have been fixed by the update.

It is a race, and there were some changes in libfprint that might be related.

@tinigriffy which version is not working and which one is working? Could you double check the exact versions that are not working and open an issue. In the issue, can you provide: * A backtrace, if it is crashing * The debug output setting LIBUSB_DEBUG=4 in the environment

It would not make any sense for libusb1-1.0.25-2.fc35 to work while libusb1-1.0.25-3.fc35 is not working. Note that both libusb1-1.0.25-1.fc35 and libusb1-1.0.25-2.fc35 had issues that caused crashes in various circumstances. I am kind of hoping you accidentally tested libusb1-1.0.25-2.fc35 and that is crashing.

Turns out there was a second regression in 1.0.24. https://github.com/libusb/libusb/pull/1073

Turns out there was a second regression in 1.0.24. https://github.com/libusb/libusb/pull/1073

This update has been unpushed.

It is breaking liquidctl. Cancelling until that we know what is going on there.

https://bugzilla.redhat.com/show_bug.cgi?id=2050638

This update has been unpushed.

It is breaking liquidctl. Cancelling until that we know what is going on there.

https://bugzilla.redhat.com/show_bug.cgi?id=2050638

Right, of course, I'll bump the version in F35 and F36.