You are not logged in.
The offending call seems to be a read on "/sys/devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.3/1-1.3:1.0/media0/uevent"?
So what is that device?
Offline
Thanks! I believe I may have narrowed down the issue now, the device under "/sys/devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.3/1-1.3:1.0" is my built-in webcam.
interface:
ASUS USB2.0 Webcam
uevent:
DEVTYPE=usb_interface
PRODUCT=1bcf/2883/429
TYPE=239/2/1
INTERFACE=14/1/0
MODALIAS=usb:v1BCFp2883d0429dcEFdsc02dp01ic0Eisc01ip00in00
In retrospect, this may have been really stupid, but since I don't ever use my webcam, I tried unloading the module with modprobe.
sudo modprobe -r uvcvideo
No errors were reported, I didn't have to force anything, and everything seemed well.
Even though I spent a lot of time online to make sure there wouldn't be any harmful side effects, I probably shouldn't be touching kernel modules. For some reason, it doesn't seem to have been unloaded cleanly, and still thought it was loaded. This also explains the kernel stack dumps, since they showed up every time I tried accessing those files.
I've re-enabled the module with
sudo modprobe uvcvideo
but unfortunately, the errors don't go away. What is the recommended way to fix this? Reboot back in from my USB media, and regenerate mkinitcpio?
I usually never touch this sort of stuff, but after experiencing a bunch of odd showstopping bugs with Arch recently, that changed.
Offline
The mkinitcpio without the autodetect hook succeeded so would try rebooting, adding the hook back and seeing if the error reoccurs.
Edit:
It might be that removing the module was the issue in that the module does not clean up correctly or it may be the case that even if the module is never loaded something triggers the OOPS.
Last edited by loqs (2018-03-31 16:10:13)
Offline
But you can cat that file? Because then it's rather not the offender... :-(
Offline
But you can cat that file? Because then it's rather not the offender... :-(
The files directly under "/sys/devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.3/1-1.3:1.0/" are:
authorized bInterfaceSubClass iad_bFunctionProtocol media0 uevent
bAlternateSetting bNumEndpoints iad_bFunctionSubClass modalias
bInterfaceClass ep_87 iad_bInterfaceCount power
bInterfaceNumber iad_bFirstInterface input subsystem
bInterfaceProtocol iad_bFunctionClass interface supports_autosuspend
Almost all of these are "cat"able, but "media0/model" and "media0/uevent" return the Killed error.
The mkinitcpio without the autodetect hook succeeded so would try rebooting, adding the hook back and seeing if the error reoccurs.
Edit:
It might be that removing the module was the issue in that the module does not clean up correctly or it may be the case that even if the module is never loaded something triggers the OOPS.
So add the hook back through "arch-chroot" using the USB installation media? I have full system encryption, and the drive is specifed using its UUID, so I don't know if it can boot back in.
Last edited by arcdmp (2018-03-31 16:43:12)
Offline
So I bit the bullet, restarted into the USB media, and it worked!
The problem was that unloading the "uvcvideo" module, it doesn't unload cleanly.
After booting into the USB media, I mounted & chrooted into the system with:
$ cryptsetup open /dev/sda3 cryptroot
$ mount /dev/mapper/cryptroot /mnt
$ mount /dev/sda2 /mnt/boot
$ arch-chroot /mnt
Then, re-running
mkinitcpio -p linux-lts
successfully regenerated the image and the autodetect hook.
I'm not sure that this was the same problem as the original poster, but thanks so much @loqs & @seth, I would have never known that "/sys/devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.3/1-1.3:1.0/media0/uevent" was the offending line in strace.
Offline
The system's initrd did not work after you regenerated if without the autodetect hook? If you unload the uvcvideo module and cat /sys/devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.3/1-1.3:1.0/uevent is the issue repeatable?
Offline
The system's initrd did not work after you regenerated if without the autodetect hook?
It always appeared to generate successfully. If I removed the autodetect hook, the generation would run smoothly. If I added the hook back, the only indication that something was wrong was this line:
-> Running build hook: [autodetect]
find: ‘sort’ terminated by signal 9
modprobe: ERROR: missing parameters. See -h.
but the initrd continued to look like it generated perfectly fine.
If you unload the uvcvideo module and cat /sys/devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.3/1-1.3:1.0/uevent is the issue repeatable?
Yes it's repeatable. The file that's causing the problem is
/sys/devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.3/1-1.3:1.0/media0/uevent
For some reason, the "uevent" file in the directory above is fine, which is how I found out it was the webcam:
/sys/devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.3/1-1.3:1.0/uevent
I can only imagine is that maybe "media0/" is some sort of mountpoint or critical pointer for the webcam.
Edit: Not only is it reproducible, it causes a Kernel panic on shutdown, preventing the machine from fully shutting down. I can't find the stacktrace in journalctl, but the last few lines are:
Mar 31 16:45:00 arch systemd[1]: Deactivated swap /swapfile.
Mar 31 16:45:00 arch systemd[1]: Reached target Unmount All Filesystems.
Mar 31 16:45:00 arch systemd[1]: Stopped Remount Root and Kernel File Systems.
Mar 31 16:45:00 arch systemd[1]: Reached target Shutdown.
Mar 31 16:45:00 arch systemd[1]: Reached target Final Step.
Mar 31 16:45:00 arch systemd[1]: Starting Reboot...
Mar 31 16:45:00 arch systemd[1]: Shutting down.
Mar 31 16:45:00 arch systemd[1]: Hardware watchdog 'iTCO_wdt', version 0
Mar 31 16:45:00 arch systemd[1]: Set hardware watchdog to 10min.
Mar 31 16:45:00 arch kernel: watchdog: watchdog0: watchdog did not stop!
Mar 31 16:45:00 arch kernel: systemd-shutdow: 24 output lines suppressed due to ratelimiting
Mar 31 16:45:00 arch systemd-shutdown[1]: Syncing filesystems and block devices.
Mar 31 16:45:00 arch systemd-shutdown[1]: Sending SIGTERM to remaining processes...
Mar 31 16:45:00 arch systemd-journald[307]: Journal stopped
and just after that, large stacktrace errors about "init" are printed.
Last edited by arcdmp (2018-03-31 21:04:48)
Offline
Not seeing any fixes for 4.16 for the uvcvideo module which might be relevant to this issue. You could ask on https://sourceforge.net/p/linux-uvc/mai … uvc-devel/ if this is a bug or expected.
Edit:
To test if it is that module can you blacklist the uvcvideo module reboot and see if you can still trigger the issue?
Last edited by loqs (2018-03-31 21:34:28)
Offline
Not seeing any fixes for 4.16 for the uvcvideo module which might be relevant to this issue. You could ask on https://sourceforge.net/p/linux-uvc/mai … uvc-devel/ if this is a bug or expected.
Edit:
To test if it is that module can you blacklist the uvcvideo module reboot and see if you can still trigger the issue?
Blacklisting the module seems to work fine, it doesn't get loaded on boot, and the command doesn't trigger a kernel error. "lsmod | grep uvcvideo" doesn't return any results, so bootup worked fine with it unloaded.
Does this mean there's an error with unloading?
Offline
Yes looks like the issue is with the module unloading. With the module loaded no issue and if the module is never loaded no issue.
It needs to be loaded then unloaded to trigger the issue if I understand correctly. (You have checked for the issue with the module loaded?)
Offline
Yes, I can manually load the module successfully after restart (after blacklisting it). The only time the error occurs is on an unload.
Is the best way to contact the developers on the mailing list link you provided earlier?
Offline
Yes that list looks the most relevant there are two more general lists
perl scripts/get_maintainer.pl drivers/media/usb/uvc/uvc_driver.c
Laurent Pinchart <laurent.pinchart@ideasonboard.com> (maintainer:USB VIDEO CLASS)
Mauro Carvalho Chehab <mchehab@kernel.org> (maintainer:MEDIA INPUT INFRASTRUCTURE (V4L/DVB))
linux-media@vger.kernel.org (open list:USB VIDEO CLASS)
linux-kernel@vger.kernel.org (open list)
Offline