kmod-maint May 2021

kmod-maint@lists.fedoraproject.org

1 participants
6 discussions

[Bug 1893631] New: Siig JJ-E01211-S1 MosChip MCS9900 parallel port card not recognized
by bugzilla＠redhat.com 13 Dec '22

13 Dec '22

https://bugzilla.redhat.com/show_bug.cgi?id=1893631 Bug ID: 1893631 Summary: Siig JJ-E01211-S1 MosChip MCS9900 parallel port card not recognized Product: Fedora Version: 33 Hardware: x86_64 OS: Linux Status: NEW Component: kmod Severity: high Assignee: kmod-maint(a)lists.fedoraproject.org Reporter: ToddAndMargo(a)zoho.com QA Contact: extras-qa(a)fedoraproject.org CC: jonathan(a)jonmasters.org, kmod-maint(a)lists.fedoraproject.org, skozina(a)redhat.com, ykaliuta(a)redhat.com Target Milestone: --- Classification: Fedora This is reproducible under both Fedora 32 and 33. Please fix on both. Siig JJ-E01211-S1 Single Parallel Port PCIe Card https://stage.siig.com/products/it-products/serial-parallel/parallel/pcie/s… System Requirements: ... Linux kernel 2.6 and later version Works with Linux but not supported Both Printer Admin (system-config-printer.py) and CUPS (https://127.0.0.1:631) do not find the card. Troubleshooting: 1) connected a USB to Parallel converter card. Printer work fine 2) boot off of Fedora-Xfce-Live-x86_64-33-1.2.iso. Printer admin still can't find the card. 3) With # modprobe -r lp # modprobe -r parport_pc # modprobe parport_pc io=0x378 irq=11 # modprobe lp the card does show up and you can print to it (lp0), but the jobs instantly disappear and nothing shows on the printer's status screen 4) tried a different parallel port cable with and without #3 above. No symptom change 5) tested with a uboobo live usb: xubuntu-20.10-desktop-amd64.iso with and without #3 above. No symptom change Here is some data on the card # udevadm info --attribute-walk /dev/lp0 Unknown device "/dev/lp0": No such device # lspci -nn | grep -i moschip 01:00.0 Parallel controller [0701]: MosChip Semiconductor Technology Ltd. MCS9900 Multi-I/O Controller [9710:9900] # lspci -vv -s 01:00.0 01:00.0 Parallel controller: MosChip Semiconductor Technology Ltd. MCS9900 Multi-I/O Controller (prog-if 03 [IEEE1284]) Subsystem: Device a000:2000 Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- Interrupt: pin A routed to IRQ 11 Region 0: I/O ports at e010 [disabled] [size=8] Region 1: I/O ports at e000 [disabled] [size=8] Region 2: Memory at ac001000 (32-bit, non-prefetchable) [disabled] [size=4K] Region 5: Memory at ac000000 (32-bit, non-prefetchable) [disabled] [size=4K] Capabilities: [50] MSI: Enable- Count=1/1 Maskable- 64bit+ Address: 0000000000000000 Data: 0000 Capabilities: [78] Power Management version 3 Flags: PMEClk- DSI- D1- D2- AuxCurrent=375mA PME(D0-,D1-,D2-,D3hot+,D3cold+) Status: D0 NoSoftRst+ PME-Enable- DSel=0 DScale=0 PME- Capabilities: [80] Express (v1) Legacy Endpoint, MSI 00 DevCap: MaxPayload 512 bytes, PhantFunc 0, Latency L0s <1us, L1 <2us ExtTag- AttnBtn- AttnInd- PwrInd- RBE+ FLReset- DevCtl: CorrErr- NonFatalErr- FatalErr- UnsupReq- RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop+ MaxPayload 128 bytes, MaxReadReq 512 bytes DevSta: CorrErr+ NonFatalErr- FatalErr- UnsupReq+ AuxPwr- TransPend- LnkCap: Port #1, Speed 2.5GT/s, Width x1, ASPM L0s L1, Exit Latency L0s <64ns, L1 <1us ClockPM+ Surprise- LLActRep- BwNot- ASPMOptComp- LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- CommClk- ExtSynch- ClockPM+ AutWidDis- BWInt- AutBWInt- LnkSta: Speed 2.5GT/s (ok), Width x1 (ok) TrErr- Train- SlotClk- DLActive- BWMgmt- ABWMgmt- Capabilities: [100 v1] Virtual Channel Caps: LPEVC=0 RefClk=100ns PATEntryBits=1 Arb: Fixed- WRR32- WRR64- WRR128- Ctrl: ArbSelect=Fixed Status: InProgress- VC0: Caps: PATOffset=00 MaxTimeSlots=1 RejSnoopTrans- Arb: Fixed- WRR32- WRR64- WRR128- TWRR128- WRR256- Ctrl: Enable+ ID=0 ArbSelect=Fixed TC/VC=ff Status: NegoPending- InProgress- VC1: Caps: PATOffset=00 MaxTimeSlots=1 RejSnoopTrans- Arb: Fixed- WRR32- WRR64- WRR128- TWRR128- WRR256- Ctrl: Enable- ID=0 ArbSelect=Fixed TC/VC=00 Status: NegoPending- InProgress- Capabilities: [800 v1] Advanced Error Reporting UESta: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol- UEMsk: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol- UESvrt: DLP+ SDES+ TLP- FCP+ CmpltTO- CmpltAbrt- UnxCmplt- RxOF+ MalfTLP+ ECRC- UnsupReq- ACSViol- CESta: RxErr- BadTLP- BadDLLP- Rollover- Timeout- AdvNonFatalErr+ CEMsk: RxErr- BadTLP- BadDLLP- Rollover- Timeout- AdvNonFatalErr+ AERCap: First Error Pointer: 00, ECRCGenCap- ECRCGenEn- ECRCChkCap- ECRCChkEn- MultHdrRecCap- MultHdrRecEn- TLPPfxPres- HdrLogCap- HeaderLog: 00000000 00000000 00000000 00000000 -- You are receiving this mail because: You are on the CC list for the bug. You are the assignee for the bug.

1 15

[Bug 1943856] New: kmod-nvidia fails with unknown symbols and no such file
by bugzilla＠redhat.com 08 Jun '22

08 Jun '22

https://bugzilla.redhat.com/show_bug.cgi?id=1943856 Bug ID: 1943856 Summary: kmod-nvidia fails with unknown symbols and no such file Product: Fedora Version: 34 Status: NEW Component: kmod Assignee: kmod-maint(a)lists.fedoraproject.org Reporter: plarsen(a)redhat.com QA Contact: extras-qa(a)fedoraproject.org CC: jonathan(a)jonmasters.org, kmod-maint(a)lists.fedoraproject.org, skozina(a)redhat.com, ykaliuta(a)redhat.com Target Milestone: --- Classification: Fedora Description of problem: When running an update that includes kmod-nvidia (version 5.11.6-300.fc34 in this case) I get a long list of errors: Running scriptlet: kmod-nvidia-5.11.6-300.fc34.x86_64-3:460.56-1.fc34.x86_64 63/79 depmod: ERROR: fstatat(5, nvidia-modeset.ko): No such file or directory depmod: ERROR: fstatat(5, nvidia.ko): No such file or directory depmod: ERROR: fstatat(5, nvidia-uvm.ko): No such file or directory depmod: ERROR: fstatat(5, nvidia-drm.ko): No such file or directory depmod: ERROR: fstatat(7, ds2490.ko.xz): No such file or directory depmod: ERROR: fstatat(7, ds2482.ko.xz): No such file or directory depmod: ERROR: fstatat(7, w1_ds2408.ko.xz): No such file or directory depmod: ERROR: fstatat(7, w1_ds2433.ko.xz): No such file or directory depmod: ERROR: fstatat(7, w1_ds28e04.ko.xz): No such file or directory depmod: ERROR: fstatat(7, w1_ds2781.ko.xz): No such file or directory depmod: ERROR: fstatat(7, w1_ds2423.ko.xz): No such file or directory depmod: ERROR: fstatat(7, w1_ds2760.ko.xz): No such file or directory depmod: ERROR: fstatat(7, w1_ds2780.ko.xz): No such file or directory depmod: ERROR: fstatat(7, w1_ds2431.ko.xz): No such file or directory depmod: ERROR: fstatat(7, w1_smem.ko.xz): No such file or directory depmod: ERROR: fstatat(7, w1_therm.ko.xz): No such file or directory depmod: ERROR: fstatat(7, slip.ko.xz): No such file or directory depmod: ERROR: fstatat(7, slcan.ko.xz): No such file or directory depmod: ERROR: fstatat(8, ems_pci.ko.xz): No such file or directory depmod: ERROR: fstatat(8, plx_pci.ko.xz): No such file or directory depmod: ERROR: fstatat(8, kvaser_pci.ko.xz): No such file or directory depmod: ERROR: fstatat(8, ems_usb.ko.xz): No such file or directory depmod: ERROR: fstatat(8, esd_usb2.ko.xz): No such file or directory depmod: ERROR: fstatat(8, c_can_platform.ko.xz): No such file or directory depmod: ERROR: fstatat(7, trancevibrator.ko.xz): No such file or directory depmod: ERROR: fstatat(7, stinger.ko.xz): No such file or directory depmod: ERROR: fstatat(7, turbografx.ko.xz): No such file or directory depmod: ERROR: fstatat(7, spaceball.ko.xz): No such file or directory depmod: ERROR: fstatat(7, db9.ko.xz): No such file or directory depmod: ERROR: fstatat(7, zhenhua.ko.xz): No such file or directory depmod: ERROR: fstatat(7, walkera0701.ko.xz): No such file or directory depmod: ERROR: fstatat(8, iforce.ko.xz): No such file or directory depmod: ERROR: fstatat(7, magellan.ko.xz): No such file or directory depmod: ERROR: fstatat(7, spaceorb.ko.xz): No such file or directory depmod: ERROR: fstatat(7, twidjoy.ko.xz): No such file or directory depmod: ERROR: fstatat(7, warrior.ko.xz): No such file or directory depmod: ERROR: fstatat(6, tcp_vegas.ko.xz): No such file or directory depmod: ERROR: fstatat(6, tcp_yeah.ko.xz): No such file or directory depmod: ERROR: fstatat(6, tcp_lp.ko.xz): No such file or directory depmod: ERROR: fstatat(6, tcp_westwood.ko.xz): No such file or directory depmod: ERROR: fstatat(6, tcp_bic.ko.xz): No such file or directory depmod: ERROR: fstatat(6, tcp_htcp.ko.xz): No such file or directory depmod: ERROR: fstatat(6, tcp_veno.ko.xz): No such file or directory depmod: ERROR: fstatat(6, tcp_hybla.ko.xz): No such file or directory depmod: ERROR: fstatat(6, tcp_scalable.ko.xz): No such file or directory depmod: ERROR: fstatat(6, tcp_illinois.ko.xz): No such file or directory depmod: ERROR: fstatat(6, tcp_highspeed.ko.xz): No such file or directory depmod: WARNING: /lib/modules/5.11.6-300.fc34.x86_64/extra/v4l2loopback.ko.xz needs unknown symbol video_ioctl2 depmod: WARNING: /lib/modules/5.11.6-300.fc34.x86_64/extra/v4l2loopback.ko.xz needs unknown symbol v4l2_ctrl_handler_init_class depmod: WARNING: /lib/modules/5.11.6-300.fc34.x86_64/extra/v4l2loopback.ko.xz needs unknown symbol video_devdata depmod: WARNING: /lib/modules/5.11.6-300.fc34.x86_64/extra/v4l2loopback.ko.xz needs unknown symbol v4l2_ctrl_new_custom depmod: WARNING: /lib/modules/5.11.6-300.fc34.x86_64/extra/v4l2loopback.ko.xz needs unknown symbol video_unregister_device depmod: WARNING: /lib/modules/5.11.6-300.fc34.x86_64/extra/v4l2loopback.ko.xz needs unknown symbol video_device_alloc depmod: WARNING: /lib/modules/5.11.6-300.fc34.x86_64/extra/v4l2loopback.ko.xz needs unknown symbol v4l2_device_register depmod: WARNING: /lib/modules/5.11.6-300.fc34.x86_64/extra/v4l2loopback.ko.xz needs unknown symbol __video_register_device depmod: WARNING: /lib/modules/5.11.6-300.fc34.x86_64/extra/v4l2loopback.ko.xz needs unknown symbol v4l2_ctrl_handler_free depmod: WARNING: /lib/modules/5.11.6-300.fc34.x86_64/extra/v4l2loopback.ko.xz needs unknown symbol v4l2_device_unregister depmod: WARNING: /lib/modules/5.11.6-300.fc34.x86_64/extra/v4l2loopback.ko.xz needs unknown symbol video_device_release The errors seems to happen regardless of what module is being built. Version-Release number of selected component (if applicable): fc34-preview/beta How reproducible: Every update of kmod modules. -- You are receiving this mail because: You are on the CC list for the bug. You are the assignee for the bug.

1 3

[Bug 1828455] New: depmod running for a long time when installing F33 kernel
by bugzilla＠redhat.com 15 Mar '22

15 Mar '22

https://bugzilla.redhat.com/show_bug.cgi?id=1828455 Bug ID: 1828455 Summary: depmod running for a long time when installing F33 kernel Product: Fedora Version: 31 Status: NEW Component: kmod Assignee: kmod-maint(a)lists.fedoraproject.org Reporter: m8r-sx4s741(a)veryrealemail.com QA Contact: extras-qa(a)fedoraproject.org CC: jonathan(a)jonmasters.org, kmod-maint(a)lists.fedoraproject.org, skozina(a)redhat.com, ykaliuta(a)redhat.com Target Milestone: --- Classification: Fedora Description of problem: In an F31 VM, when installing an F33 kernel, depmod runs for a very long time and consumes nearly 100% CPU. Version-Release number of selected component (if applicable): kmod-26-4.fc31.x86_64 kernel-0:5.7.0-0.rc2.20200422git18bf34080c4c.1.fc33.x86_64 How reproducible: Tested once. Steps to Reproduce: # dnf update --nogpg kernel-0:5.7.0-0.rc2.20200422git18bf34080c4c.1.fc33.x86_64 --releasever=33 Actual results: Top shows CPU usage by depmod approaching 100% at times: $ top -bc -n 1 -u root | head -9 top - 10:31:33 up 28 min, 1 user, load average: 1.20, 1.11, 0.99 Tasks: 186 total, 2 running, 184 sleeping, 0 stopped, 0 zombie %Cpu(s): 94.1 us, 5.9 sy, 0.0 ni, 0.0 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st MiB Mem : 3928.0 total, 2000.5 free, 734.9 used, 1192.6 buff/cache MiB Swap: 512.0 total, 512.0 free, 0.0 used. 2942.6 avail Mem PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 38906 root 20 0 41960 39528 4220 R 81.2 1.0 0:03.82 /sbin/depmod -C /tmp/weak-modules.Os10HS/depmod.conf + 1 root 20 0 172764 16432 9752 S 0.0 0.4 0:02.78 /usr/lib/systemd/systemd --switched-root --system --d+ Expected results: Kernel install completes in a normal time. Additional info: This bug appears to be reporting the same issue: Bug 1825940 - kernel-core-5.7.0-0.rc1.20200416git9786cab67457.1 took very long time to install -- You are receiving this mail because: You are on the CC list for the bug. You are the assignee for the bug.

1 34

[Bug 1962841] New: kmod should not ship /usr/sbin/weak-modules because it is useless and dangerous for DKMS modules
by bugzilla＠redhat.com 10 Jun '21

10 Jun '21

https://bugzilla.redhat.com/show_bug.cgi?id=1962841 Bug ID: 1962841 Summary: kmod should not ship /usr/sbin/weak-modules because it is useless and dangerous for DKMS modules Product: Fedora Version: 33 Status: NEW Component: kmod Assignee: kmod-maint(a)lists.fedoraproject.org Reporter: cks-rhbugzilla(a)cs.toronto.edu QA Contact: extras-qa(a)fedoraproject.org CC: jonathan(a)jonmasters.org, kmod-maint(a)lists.fedoraproject.org, skozina(a)redhat.com, ykaliuta(a)redhat.com Target Milestone: --- Classification: Fedora Description of problem: Fedora specifically adds the /usr/sbin/weak-modules script to the kmod RPM; it's not part of the upstream version. However, weak-modules does not work properly on Fedora, as it believes that a module built for one kernel version can be compatible with another kernel version, and will create /lib/modules/*/weak-updates symlinks reflecting this under at least some circumstances. After these symlinks exist, modprobe of the relevant module(s) will fail with eg: version magic '5.11.15-200.fc33.x86_64 SMP mod_unload ' should be '5.10.23-200.fc33.x86_64 SMP mod_unload ' Fedora does not set CONFIG_MODVERSIONS in its kernel configurations, so I believe this will always fail and as a result /usr/sbin/weak-modules's checks are irrelevant and evidently incorrect. This failure is sufficiently well known that the upstream DKMS manpage contains a warning that everyone writing a dkms.conf must specifically disable running /usr/sbin/weak-modules on Fedora (the 'NO_WEAK_MODULES' setting and the discussion of it in the manpage). It should come as no surprise that not all dkms.conf files contain this setting. This issue is especially dangerous because it seems to primarily affects people when they are reverting to a previous kernel, where some of their modules may not load. Version-Release number of selected component (if applicable): kmod-27-3.fc33.x86_64 How reproducible: Completely. Steps to Reproduce: 1. Install a DKMS module with a dkms.conf that doesn't specify NO_WEAK_MODULES=yes. It will modprobe on your current kernel. 2. Install a kernel upgrade. 3. Reboot into the current kernel (not the new upgraded kernel) and observe that your DKMS module no longer modprobes, failing with a version magic error. 4. see that /lib/modules/$(uname -r)/weak-modules contains a symlink for your DKMS module that points to /lib/modules/<new-kernel>/.../<dkms-module>.ko.xz. -- You are receiving this mail because: You are on the CC list for the bug. You are the assignee for the bug.

1 7

[Bug 1962980] New: kmod-29 is available
by bugzilla＠redhat.com 21 May '21

21 May '21

https://bugzilla.redhat.com/show_bug.cgi?id=1962980 Bug ID: 1962980 Summary: kmod-29 is available Product: Fedora Version: rawhide Status: NEW Component: kmod Keywords: FutureFeature, Triaged Assignee: kmod-maint(a)lists.fedoraproject.org Reporter: upstream-release-monitoring(a)fedoraproject.org QA Contact: extras-qa(a)fedoraproject.org CC: jonathan(a)jonmasters.org, kmod-maint(a)lists.fedoraproject.org, skozina(a)redhat.com, ykaliuta(a)redhat.com Target Milestone: --- Classification: Fedora Latest upstream release: 29 Current version/release in rawhide: 28-2.fc34 URL: https://git.kernel.org/pub/scm/utils/kernel/kmod/kmod.git Please consult the package updates policy before you issue an update to a stable branch: https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/ More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring Please keep in mind that with any upstream change, there may also be packaging changes that need to be made. Specifically, please remember that it is your responsibility to review the new version to ensure that the licensing is still correct and that no non-free or legally problematic items have been added upstream. Based on the information from anitya: https://release-monitoring.org/project/1517/ -- You are receiving this mail because: You are on the CC list for the bug. You are the assignee for the bug.

1 4

[Bug 1951176] systemd-modules-load "Failed to find module 'msr'"
by bugzilla＠redhat.com 07 May '21

07 May '21

https://bugzilla.redhat.com/show_bug.cgi?id=1951176 Zbigniew Jędrzejewski-Szmek <zbyszek(a)in.waw.pl> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jonathan(a)jonmasters.org, | |kmod-maint(a)lists.fedoraproj | |ect.org, | |skozina(a)redhat.com, | |ykaliuta(a)redhat.com Component|systemd |kmod Assignee|systemd-maint(a)redhat.com |kmod-maint(a)lists.fedoraproj | |ect.org --- Comment #2 from Zbigniew Jędrzejewski-Szmek <zbyszek(a)in.waw.pl> --- Hmm, this is strange. When executed in the real system, we correctly detect that the module is built-in: $ systemd-modules-load /usr/lib/modules-load.d/fwupd-msr.conf Module 'msr' is built in But when executed in the initramfs, this doesn't work for some reason. $ chroot /var/tmp/initrd (chroot)# /usr/lib/systemd/systemd-modules-load /usr/lib/modules-load.d/fwupd-msr.conf Failed to find module 'msr' /usr/lib/modules/5.12.0-198.fc34.x86_64/modules.builtin in the initrafms does list kernel/arch/x86/kernel/msr.ko. But for some reason libkmod not not grok that. $ grep -w msr /usr/lib/modules/5.12.0-198.fc34.x86_64/* /usr/lib/modules/5.12.0-198.fc34.x86_64/modules.builtin:kernel/arch/x86/kernel/msr.ko grep: /usr/lib/modules/5.12.0-198.fc34.x86_64/modules.builtin.modinfo: binary file matches grep: /usr/lib/modules/5.12.0-198.fc34.x86_64/modules.symbols.bin: binary file matches grep: /usr/lib/modules/5.12.0-198.fc34.x86_64/vmlinuz: binary file matches $ grep -w msr /var/tmp/initrd/usr/lib/modules/5.12.0-198.fc34.x86_64/* /var/tmp/initrd/usr/lib/modules/5.12.0-198.fc34.x86_64/modules.builtin:kernel/arch/x86/kernel/msr.ko It seems that dracut is doing something wrong in constructing the module lists. kmod maintainers, any advice? -- You are receiving this mail because: You are on the CC list for the bug. You are the assignee for the bug.

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

kmod-maint May 2021