[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