[Bug 1893631] New: Siig JJ-E01211-S1 MosChip MCS9900 parallel port
card not recognized
by bugzilla@redhat.com
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...
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 year, 4 months
[Bug 1828455] New: depmod running for a long time when installing
F33 kernel
by bugzilla@redhat.com
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.
2 years, 1 month
[Bug 1808430] New: depmod: tools/depmod.c:416: index_write:
Assertion `initial_offset >= 0' failed.
by bugzilla@redhat.com
https://bugzilla.redhat.com/show_bug.cgi?id=1808430
Bug ID: 1808430
Summary: depmod: tools/depmod.c:416: index_write: Assertion
`initial_offset >= 0' failed.
Product: Fedora
Version: rawhide
Status: NEW
Component: kmod
Assignee: kmod-maint(a)lists.fedoraproject.org
Reporter: yaneti(a)declera.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:
depmod -n 5.6.0-0.rc3.git2.2.fc33.x86_64
....
depmod: tools/depmod.c:416: index_write: Assertion `initial_offset >= 0'
failed.
Aborted (core dumped)
Version-Release number of selected component (if applicable):
kmod-27-1.fc33.x86_64
Additional info:
kmod-26-5.fc32 works fine
--
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.
3 years, 2 months
[Bug 1900596] livemedia-creator stuck after DNF postin scriptlet
error
by bugzilla@redhat.com
https://bugzilla.redhat.com/show_bug.cgi?id=1900596
Brian Lane <bcl(a)redhat.com> 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|lorax |kmod
Assignee|bcl(a)redhat.com |kmod-maint(a)lists.fedoraproj
| |ect.org
--- Comment #1 from Brian Lane <bcl(a)redhat.com> ---
There's nothing lmc can do about script errors. The package needs to fix their
script. Please check to see if there are any additional details in the various
logs, there may or may not be, debugging script errors can be tricky.
The "Connection refused" errors are unrelated, IIRC that comes from python-meh
trying to report the crash.
--
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.
3 years, 4 months
[Bug 1898849] New: Building rpms failed
akmods/wl/6.30.223.271-32-for-5.9.8-100.fc32.x86_64 failed
by bugzilla@redhat.com
https://bugzilla.redhat.com/show_bug.cgi?id=1898849
Bug ID: 1898849
Summary: Building rpms failed
akmods/wl/6.30.223.271-32-for-5.9.8-100.fc32.x86_64
failed
Product: Fedora
Version: 32
Status: NEW
Component: kmod
Assignee: kmod-maint(a)lists.fedoraproject.org
Reporter: paul59584(a)gmail.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
Created attachment 1730493
--> https://bugzilla.redhat.com/attachment.cgi?id=1730493&action=edit
6.30.223.271-32-for-5.9.8-100.fc32.x86_64.failed.log attached as
wl-6.30.223.271-32-for-5.9.8-100.fc32.x86_64.failed.log
Description of problem:
akmods: Building rpms failed; see
/var/cache/akmods/wl/6.30.223.271-32-for-5.9.8-100.fc32.x86_64.failed.log
Similar/same bug with proposed fix filed at:
https://github.com/NixOS/nixpkgs/issues/101040
Version-Release number of selected component (if applicable):
akmods/wl/6.30.223.271-32 for kernel5.9.8-100
How reproducible:
always
Steps to Reproduce:
1. Upgrade to kernel 5.9.8-100
2. no wifi
Actual results:
no wifi because building wl.ko (akmod) fails
Expected results:
wl.ko build by akmod should work as it does with previous kernels
Additional info:
Worked well with kernels prior to 5.9.8-100, 5.8.18-200.fc32.x86_64 is the last
kernel before upgrade to 5.9 that I've used.
As mentioned above github.com/NixOS/nixpkgs/issues/101040 may have a solution.
6.30.223.271-32-for-5.9.8-100.fc32.x86_64.failed.log attached
--
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.
3 years, 5 months