8:35 p.m.
Hi All,
Fedora32 x64
I just installed a
https://lavaports.com/serial-parallel-cards/products-pcie-bus-io-cards/pa...
CUPS tells me the priner is not attqched.
I did a
# modprobe -r lp
# modprobe -r parport_pc
# modprobe parport_pc io=0x378,0xee00 irq=7,11
# modprobe lp
Cups shows the printer idle
Now jobs disappears as if it if printing,
but the printer shows nothing.
I am not sure that this card is being
seen as /dev/lp0. How do I
check that.
And how do I check which lp my printer is attached to?
Many thanks,
-T
10:25 p.m.
On 10/16/20 6:35 PM, ToddAndMargo via users wrote:
Hi All,
Fedora32 x64
I just installed a
https://lavaports.com/serial-parallel-cards/products-pcie-bus-io-cards/pa...
CUPS tells me the priner is not attqched.
I did a
# modprobe -r lp
# modprobe -r parport_pc
# modprobe parport_pc io=0x378,0xee00 irq=7,11
# modprobe lp
Cups shows the printer idle
Now jobs disappears as if it if printing,
but the printer shows nothing.
I am not sure that this card is being
seen as /dev/lp0. How do I
check that.
And how do I check which lp my printer is attached to?
Many thanks,
-T
After a fresh boot:
$ udevadm info -a /dev/lp0
Unknown device "/dev/lp0": No such device
Same with lp1 and lp2 and lp3
After the above modprobes:
# udevadm info -a /dev/lp0
Udevadm info starts with the device specified by the devpath and then
walks up the chain of parent devices. It prints for every device
found, all possible attributes in the udev rules key format.
A rule to match, can be composed by the attributes of the device
and the attributes from one single parent device.
looking at device '/devices/platform/parport_pc.888/printer/lp0':
KERNEL=="lp0"
SUBSYSTEM=="printer"
DRIVER==""
looking at parent device '/devices/platform/parport_pc.888':
KERNELS=="parport_pc.888"
SUBSYSTEMS=="platform"
DRIVERS=="parport_pc"
ATTRS{driver_override}=="(null)"
looking at parent device '/devices/platform':
KERNELS=="platform"
SUBSYSTEMS==""
DRIVERS==""
7:18 a.m.
Post a dmesg.
In general you only very rarely need to modprobe anything, it happens
automatically.
also post a "lspci -nn"
On Fri, Oct 16, 2020 at 10:26 PM ToddAndMargo via users
<users(a)lists.fedoraproject.org> wrote:
>
> On 10/16/20 6:35 PM, ToddAndMargo via users wrote:
> > Hi All,
> >
> > Fedora32 x64
> >
> > I just installed a
> >
> >
https://lavaports.com/serial-parallel-cards/products-pcie-bus-io-cards/pa...
> >
> >
> >
> > CUPS tells me the priner is not attqched.
> >
> > I did a
> >
> > # modprobe -r lp
> > # modprobe -r parport_pc
> > # modprobe parport_pc io=0x378,0xee00 irq=7,11
> > # modprobe lp
> >
> > Cups shows the printer idle
> >
> > Now jobs disappears as if it if printing,
> > but the printer shows nothing.
> >
> > I am not sure that this card is being
> > seen as /dev/lp0. How do I
> > check that.
> >
> > And how do I check which lp my printer is attached to?
> >
> >
> > Many thanks,
> > -T
>
>
> After a fresh boot:
>
> $ udevadm info -a /dev/lp0
> Unknown device "/dev/lp0": No such device
>
> Same with lp1 and lp2 and lp3
>
>
> After the above modprobes:
>
> # udevadm info -a /dev/lp0
>
> Udevadm info starts with the device specified by the devpath and then
> walks up the chain of parent devices. It prints for every device
> found, all possible attributes in the udev rules key format.
> A rule to match, can be composed by the attributes of the device
> and the attributes from one single parent device.
>
> looking at device '/devices/platform/parport_pc.888/printer/lp0':
> KERNEL=="lp0"
> SUBSYSTEM=="printer"
> DRIVER==""
>
> looking at parent device '/devices/platform/parport_pc.888':
> KERNELS=="parport_pc.888"
> SUBSYSTEMS=="platform"
> DRIVERS=="parport_pc"
> ATTRS{driver_override}=="(null)"
>
> looking at parent device '/devices/platform':
> KERNELS=="platform"
> SUBSYSTEMS==""
> DRIVERS==""
>
> _______________________________________________
> users mailing list -- users(a)lists.fedoraproject.org
> To unsubscribe send an email to users-leave(a)lists.fedoraproject.org
> Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
1:43 p.m.
On Fri, Oct 16, 2020 at 10:26 PM ToddAndMargo via users
<users(a)lists.fedoraproject.org> wrote:
>
> On 10/16/20 6:35 PM, ToddAndMargo via users wrote:
>> Hi All,
>>
>> Fedora32 x64
>>
>> I just installed a
>>
>>
https://lavaports.com/serial-parallel-cards/products-pcie-bus-io-cards/pa...
>>
>>
>>
>> CUPS tells me the priner is not attqched.
>>
>> I did a
>>
>> # modprobe -r lp
>> # modprobe -r parport_pc
>> # modprobe parport_pc io=0x378,0xee00 irq=7,11
>> # modprobe lp
>>
>> Cups shows the printer idle
>>
>> Now jobs disappears as if it if printing,
>> but the printer shows nothing.
>>
>> I am not sure that this card is being
>> seen as /dev/lp0. How do I
>> check that.
>>
>> And how do I check which lp my printer is attached to?
>>
>>
>> Many thanks,
>> -T
>
>
> After a fresh boot:
>
> $ udevadm info -a /dev/lp0
> Unknown device "/dev/lp0": No such device
>
> Same with lp1 and lp2 and lp3
>
>
> After the above modprobes:
>
> # udevadm info -a /dev/lp0
>
> Udevadm info starts with the device specified by the devpath and then
> walks up the chain of parent devices. It prints for every device
> found, all possible attributes in the udev rules key format.
> A rule to match, can be composed by the attributes of the device
> and the attributes from one single parent device.
>
> looking at device '/devices/platform/parport_pc.888/printer/lp0':
> KERNEL=="lp0"
> SUBSYSTEM=="printer"
> DRIVER==""
>
> looking at parent device '/devices/platform/parport_pc.888':
> KERNELS=="parport_pc.888"
> SUBSYSTEMS=="platform"
> DRIVERS=="parport_pc"
> ATTRS{driver_override}=="(null)"
>
> looking at parent device '/devices/platform':
> KERNELS=="platform"
> SUBSYSTEMS==""
> DRIVERS==""
On 10/17/20 5:18 AM, Roger Heflin wrote:
Post a dmesg.
In general you only very rarely need to modprobe anything, it happens
automatically.
also post a "lspci -nn"
01:00.2 Parallel controller [0701]: Lava Computer mfg Inc Device [1407:a000]
# lspci -nn
00:00.0 Host bridge [0600]: Intel Corporation Xeon E3-1200 v6/7th Gen
Core Processor Host Bridge/DRAM Registers [8086:5918] (rev 05)
00:02.0 VGA compatible controller [0300]: Intel Corporation HD Graphics
P630 [8086:591d] (rev 04)
00:14.0 USB controller [0c03]: Intel Corporation 100 Series/C230 Series
Chipset Family USB 3.0 xHCI Controller [8086:a12f] (rev 31)
00:14.2 Signal processing controller [1180]: Intel Corporation 100
Series/C230 Series Chipset Family Thermal Subsystem [8086:a131] (rev 31)
00:15.0 Signal processing controller [1180]: Intel Corporation 100
Series/C230 Series Chipset Family Serial IO I2C Controller #0
[8086:a160] (rev 31)
00:15.1 Signal processing controller [1180]: Intel Corporation 100
Series/C230 Series Chipset Family Serial IO I2C Controller #1
[8086:a161] (rev 31)
00:16.0 Communication controller [0780]: Intel Corporation 100
Series/C230 Series Chipset Family MEI Controller #1 [8086:a13a] (rev 31)
00:16.3 Serial controller [0700]: Intel Corporation 100 Series/C230
Series Chipset Family KT Redirection [8086:a13d] (rev 31)
00:17.0 SATA controller [0106]: Intel Corporation
Q170/Q150/B150/H170/H110/Z170/CM236 Chipset SATA Controller [AHCI Mode]
[8086:a102] (rev 31)
00:1c.0 PCI bridge [0604]: Intel Corporation 100 Series/C230 Series
Chipset Family PCI Express Root Port #1 [8086:a110] (rev f1)
00:1c.5 PCI bridge [0604]: Intel Corporation 100 Series/C230 Series
Chipset Family PCI Express Root Port #6 [8086:a115] (rev f1)
00:1c.6 PCI bridge [0604]: Intel Corporation 100 Series/C230 Series
Chipset Family PCI Express Root Port #7 [8086:a116] (rev f1)
00:1c.7 PCI bridge [0604]: Intel Corporation 100 Series/C230 Series
Chipset Family PCI Express Root Port #8 [8086:a117] (rev f1)
00:1d.0 PCI bridge [0604]: Intel Corporation 100 Series/C230 Series
Chipset Family PCI Express Root Port #9 [8086:a118] (rev f1)
00:1f.0 ISA bridge [0601]: Intel Corporation C236 Chipset LPC/eSPI
Controller [8086:a149] (rev 31)
00:1f.2 Memory controller [0580]: Intel Corporation 100 Series/C230
Series Chipset Family Power Management Controller [8086:a121] (rev 31)
00:1f.3 Audio device [0403]: Intel Corporation 100 Series/C230 Series
Chipset Family HD Audio Controller [8086:a170] (rev 31)
00:1f.4 SMBus [0c05]: Intel Corporation 100 Series/C230 Series Chipset
Family SMBus [8086:a123] (rev 31)
00:1f.6 Ethernet controller [0200]: Intel Corporation Ethernet
Connection (2) I219-LM [8086:15b7] (rev 31)
01:00.0 Serial controller [0700]: Lava Computer mfg Inc Device [1407:dead]
01:00.2 Parallel controller [0701]: Lava Computer mfg Inc Device [1407:a000]
6c:00.0 Ethernet controller [0200]: Intel Corporation I210 Gigabit
Network Connection [8086:1533] (rev 03)
6d:00.0 PCI bridge [0604]: Tundra Semiconductor Corp. Device [10e3:8113]
(rev 01)
6f:00.0 USB controller [0c03]: ASMedia Technology Inc. ASM1142 USB 3.1
Host Controller [1b21:1242]
70:00.0 Non-Volatile memory controller [0108]: Samsung Electronics Co
Ltd NVMe SSD Controller SM961/PM961 [144d:a804]
1:47 p.m.
On 10/17/20 11:43 AM, ToddAndMargo via users wrote:
On 10/17/20 5:18 AM, Roger Heflin wrote:
> Post a dmesg.
> also post a "lspci -nn"
>
$ lspci -nn | grep -i lava
01:00.0 Serial controller [0700]: Lava Computer mfg Inc Device [1407:dead]
01:00.2 Parallel controller [0701]: Lava Computer mfg Inc Device [1407:a000]
2:19 p.m.
On 10/17/20 12:13 PM, ToddAndMargo via users wrote:
On 10/17/20 5:18 AM, Roger Heflin wrote:
> Post a dmesg.
It is 1178 lines long. I did post it, but it
got bounced.
Can you give me a grep to shorten it?
Does this help? (1407 from the lspci)
Does "[1407:dead]" mean anything?
[ 5.490370] pci 0000:01:00.0: [1407:dead] type 00 class 0x070002
[ 5.490395] pci 0000:01:00.0: reg 0x10: [io 0xe020-0xe027]
[ 5.490404] pci 0000:01:00.0: reg 0x14: [mem 0xac003000-0xac003fff]
[ 5.490435] pci 0000:01:00.0: reg 0x24: [mem 0xac002000-0xac002fff]
[ 5.490518] pci 0000:01:00.0: PME# supported from D3hot D3cold
[ 5.490675] pci 0000:01:00.2: [1407:a000] type 00 class 0x070103
[ 5.490699] pci 0000:01:00.2: reg 0x10: [io 0xe010-0xe017]
[ 5.490708] pci 0000:01:00.2: reg 0x14: [io 0xe000-0xe007]
[ 5.490716] pci 0000:01:00.2: reg 0x18: [mem 0xac001000-0xac001fff]
[ 5.490740] pci 0000:01:00.2: reg 0x24: [mem 0xac000000-0xac000fff]
[ 5.490814] pci 0000:01:00.2: PME# supported from D3hot D3cold
2:14 p.m.
On Fri, 16 Oct 2020 at 22:35, ToddAndMargo via users <
users(a)lists.fedoraproject.org> wrote:
Hi All,
Fedora32 x64
I just installed a
https://lavaports.com/serial-parallel-cards/products-pcie-bus-io-cards/pa...
https://www.lavaports.com/wp-content/uploads/pdf/Operating_system_support...
Doesn't look like linux is supported.
CUPS tells me the priner is not attqched.
I did a
# modprobe -r lp
# modprobe -r parport_pc
# modprobe parport_pc io=0x378,0xee00 irq=7,11
# modprobe lp
Cups shows the printer idle
Now jobs disappears as if it if printing,
but the printer shows nothing.
I am not sure that this card is being
seen as /dev/lp0. How do I
check that.
And how do I check which lp my printer is attached to?
Many thanks,
-T
_______________________________________________
users mailing list -- users(a)lists.fedoraproject.org
To unsubscribe send an email to users-leave(a)lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
--
George N. White III
2:23 p.m.
On 10/17/20 12:14 PM, George N. White III wrote:
Doesn't look like linux is supported.
Hi George,
I asked them about it. This is what they responded
(He misspelled that last modprobe):
Sorry for the delay, Linux isn't exactly my expertise, so it took
a little long to verify the Parallel-PCIe in Fedora 32 (Workstation Edition) 64-bit.
I didn't do the full installation, so my testing is limited to the Live version which
I ran off OS off a USB Flash Drive.
That being said, the Parallel PCIe card does appear to work in the OS. It doesn't
detect automatically like our PCI cards do, however I was able to reconfigure the port, as
substitute user, with the following commands:
> modprobe -r lp
> modprobe -r parport_pc
> modprobe parport_pc io=0x378,0xee00 irq=7,11
> modprode lp
Once configured I was able to detect both a HP Laser Jet and an old Epson dot matrix
printer and was able to dump a print job to the Epson.
The Laser Jet appears to have given up the ghost long ago, so I couldn't use it to
test the port in Fedora, but I don't believe that was an issue with our card.
Hopefully that helps,
-T
2:29 p.m.
On Sat, 17 Oct 2020 at 16:23, ToddAndMargo via users <
users(a)lists.fedoraproject.org> wrote:
On 10/17/20 12:14 PM, George N. White III wrote:
> Doesn't look like linux is supported.
Hi George,
I asked them about it. This is what they responded
(He misspelled that last modprobe):
> Sorry for the delay, Linux isn't exactly my expertise, so it took a
little long to verify the Parallel-PCIe in Fedora 32 (Workstation Edition)
64-bit.
>
> I didn't do the full installation, so my testing is limited to the Live
version which I ran off OS off a USB Flash Drive.
>
> That being said, the Parallel PCIe card does appear to work in the OS.
It doesn't detect automatically like our PCI cards do, however I was able
to reconfigure the port, as substitute user, with the following commands:
>
>> modprobe -r lp
>> modprobe -r parport_pc
>> modprobe parport_pc io=0x378,0xee00 irq=7,11
>> modprode lp
>
> Once configured I was able to detect both a HP Laser Jet and an old
Epson dot matrix printer and was able to dump a print job to the Epson.
>
> The Laser Jet appears to have given up the ghost long ago, so I couldn't
use it to test the port in Fedora, but I don't believe that was an issue
with our card.
>
> Hopefully that helps,
You might get better help from linuxcnc.org:
https://forum.linuxcnc.org/27-driver-boards/34393-pcie-parallel-cards-wha...
You might be able to get the chipset by looking at the label of the big IC's
-T
_______________________________________________
users mailing list -- users(a)lists.fedoraproject.org
To unsubscribe send an email to users-leave(a)lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
--
George N. White III
3:05 p.m.
On 10/17/20 12:29 PM, George N. White III wrote:
On Sat, 17 Oct 2020 at 16:23, ToddAndMargo via users
<users(a)lists.fedoraproject.org <mailto:users@lists.fedoraproject.org>>
wrote:
On 10/17/20 12:14 PM, George N. White III wrote:
> Doesn't look like linux is supported.
Hi George,
I asked them about it. This is what they responded
(He misspelled that last modprobe):
> Sorry for the delay, Linux isn't exactly my expertise, so it took
a little long to verify the Parallel-PCIe in Fedora 32 (Workstation
Edition) 64-bit.
>
> I didn't do the full installation, so my testing is limited to
the Live version which I ran off OS off a USB Flash Drive.
>
> That being said, the Parallel PCIe card does appear to work in
the OS. It doesn't detect automatically like our PCI cards do,
however I was able to reconfigure the port, as substitute user, with
the following commands:
>
>> modprobe -r lp
>> modprobe -r parport_pc
>> modprobe parport_pc io=0x378,0xee00 irq=7,11
>> modprode lp
>
> Once configured I was able to detect both a HP Laser Jet and an
old Epson dot matrix printer and was able to dump a print job to the
Epson.
>
> The Laser Jet appears to have given up the ghost long ago, so I
couldn't use it to test the port in Fedora, but I don't believe that
was an issue with our card.
>
> Hopefully that helps,
You might get better help from linuxcnc.org <http://linuxcnc.org>;:
https://forum.linuxcnc.org/27-driver-boards/34393-pcie-parallel-cards-wha...
<https://forum.linuxcnc.org/27-driver-boards/34393-pcie-parallel-cards-wha...
You might be able to get the chipset by looking at the label of the big IC's
It is a "VIA VT8231"
$ modinfo parport_pc
filename:
/lib/modules/5.8.14-200.fc32.x86_64/kernel/drivers/parport/parport_pc.ko.xz
license: GPL
description: PC-style parallel port driver
author: Phil Blundell, Tim Waugh, others
alias: pci:v00001C00d00003050sv00001C00sd00003050bc*sc*i*
alias: pci:v0000135Cd00000278sv*sd*bc*sc*i*
alias: pci:v00009710d00009865sv0000A000sd00002000bc*sc*i*
alias: pci:v00009710d00009865sv0000A000sd00001000bc*sc*i*
alias: pci:v00009710d00009901sv0000A000sd00002000bc*sc*i*
alias: pci:v00009710d00009815sv*sd*bc*sc*i*
alias: pci:v00009710d00009805sv*sd*bc*sc*i*
alias: pci:v00009710d00009755sv*sd*bc*sc*i*
alias: pci:v00009710d00009715sv*sd*bc*sc*i*
alias: pci:v00009710d00009705sv*sd*bc*sc*i*
alias: pci:v000014F2d00000121sv*sd*bc*sc*i*
alias: pci:v0000416Cd00000100sv*sd*bc*sc*i*
alias: pci:v00001415d0000C11Csv*sd*bc*sc*i*
alias: pci:v00001415d0000C118sv*sd*bc*sc*i*
alias: pci:v00001415d0000C114sv*sd*bc*sc*i*
alias: pci:v00001415d0000C110sv*sd*bc*sc*i*
alias: pci:v00001415d0000C104sv*sd*bc*sc*i*
alias: pci:v00001415d0000C100sv*sd*bc*sc*i*
alias: pci:v00001415d0000C004sv*sd*bc*sc*i*
alias: pci:v00001415d0000C000sv*sd*bc*sc*i*
alias: pci:v00001415d00008403sv*sd*bc*sc*i*
alias: pci:v00001415d00009513sv*sd*bc*sc*i*
alias: pci:v00001415d00009523sv*sd*bc*sc*i*
alias: pci:v000014DBd00002121sv*sd*bc*sc*i*
alias: pci:v000014DBd00002120sv*sd*bc*sc*i*
alias: pci:v000014D2d00008001sv*sd*bc*sc*i*
alias: pci:v00001592d00000783sv*sd*bc*sc*i*
alias: pci:v00001592d00000782sv*sd*bc*sc*i*
alias: pci:v00001409d00007268sv00001409sd00009018bc*sc*i*
alias: pci:v00001409d00007268sv00001409sd00000104bc*sc*i*
alias: pci:v00001409d00007268sv00001409sd00000103bc*sc*i*
alias: pci:v00001409d00007268sv00001409sd00000102bc*sc*i*
alias: pci:v00001409d00007268sv00001409sd00000101bc*sc*i*
alias: pci:v000010B5d00009050sv0000D84Dsd00004014bc*sc*i*
alias: pci:v00001407d00008800sv*sd*bc*sc*i*
alias: pci:v00001407d00008003sv*sd*bc*sc*i*
alias: pci:v00001407d00008002sv*sd*bc*sc*i*
alias: pci:v00001407d00008000sv*sd*bc*sc*i*
alias: pci:v0000131Fd00002021sv*sd*bc*sc*i*
alias: pci:v0000131Fd00002020sv*sd*bc*sc*i*
alias: pci:v0000131Fd00001021sv*sd*bc*sc*i*
alias: pci:v0000131Fd00001020sv*sd*bc*sc*i*
alias: pci:v00001283d00008872sv*sd*bc*sc*i*
alias: pci:v00001106d00008231sv*sd*bc*sc*i*
alias: pci:v00001106d00000686sv*sd*bc*sc*i*
alias: acpi*:PNP0401:*
alias: pnp:dPNP0401*
alias: acpi*:PNP0400:*
alias: pnp:dPNP0400*
depends: parport
retpoline: Y
intree: Y
name: parport_pc
vermagic: 5.8.14-200.fc32.x86_64 SMP mod_unload
sig_id: PKCS#7
signer: Fedora kernel signing key
sig_key: 0A:6A:E4:E2:1E:79:E9:40:5D:85:8F:4E:0F:1B:60:36:F4:E9:EE:E4
sig_hashalgo: sha256
signature: 79:81:CA:D6:FB:DF:F4:6D:C0:AE:46:F8:C8:97:19:A6:9D:B2:F6:F6:
AB:0B:1C:96:67:44:CD:BE:C6:8F:8A:FF:06:8D:A0:84:EE:0F:1B:9C:
A8:7A:7A:AA:D1:C8:4F:02:4D:58:AC:3E:41:58:CC:67:3C:E4:C2:F9:
62:C8:CD:E7:89:8E:C3:B6:8D:AD:A9:86:43:DA:01:39:A7:AB:9D:4F:
E0:14:12:C6:93:51:0A:9F:F7:12:82:B8:04:43:CF:0E:AF:F5:44:2E:
36:0D:70:BA:80:65:13:0C:E1:29:E0:7E:13:D4:5D:12:54:BF:56:4F:
B4:57:8D:6C:EA:9B:F1:CB:30:16:07:3E:C9:9E:65:73:21:CC:DA:66:
02:53:23:8A:AE:38:DB:7C:43:CE:E3:0C:17:84:1F:E3:AB:C7:18:4E:
EF:0A:99:21:80:29:DA:72:3B:5D:4A:FF:51:71:5E:A1:1C:DF:88:AE:
43:58:A2:99:FF:28:E1:3E:39:3C:89:59:1E:97:05:2F:0D:74:71:84:
9F:EB:39:46:7A:27:66:A2:C1:54:C1:DC:43:5F:B0:E7:B0:C1:EF:CD:
18:F9:0C:2B:8B:84:D3:4D:C8:0E:AF:72:FC:B7:54:CD:BF:CF:3C:61:
0D:62:8B:22:3F:24:67:EF:7E:05:8F:73:0D:82:75:40:75:35:37:7A:
3C:41:FC:3E:1F:AF:37:72:8E:93:DC:EC:12:A3:8D:F3:F1:E8:55:71:
6F:C7:B1:D0:0A:D7:33:57:D6:30:CA:CE:59:CE:02:D6:22:DA:C8:AB:
D0:78:36:03:A9:66:EE:B9:40:92:89:38:B1:08:69:29:53:89:36:7F:
42:7C:43:D4:D0:A6:EC:14:E0:10:FF:90:D5:16:D3:20:08:88:89:F8:
37:87:14:77:79:7C:EC:7B:53:F1:A0:59:68:5C:63:66:DB:38:36:DD:
26:16:69:E5:E9:FB:2C:FD:FD:79:93:C4:86:94:50:49:29:AB:D7:70:
FC:DC:56:E9:61:18:38:6B:01:E3:40:5B:22:34:5F:F5:21:98:4C:44:
02:DB:AB:CF:5D:1F:CC:E0:46:DC:57:E4:41:A7:24:06:C8:89:67:05:
09:B3:42:33:E6:89:77:85:F7:1E:F6:35:6B:55:47:B4:EE:19:53:9E:
7C:55:A6:B9:57:F0:96:54:B8:D1:4C:F8:02:70:1D:7D:FE:56:7C:4A:
55:83:99:59:F4:0D:BF:8E:5A:29:55:0B:24:41:21:91:3C:00:48:39:
BF:28:ED:1F:96:DE:3C:69:DD:6B:EB:ED:1E:B2:A9:21:DA:59:15:15:
36:2C:41:C5:53:61:FB:38:8B:0C:8E:3D
parm: io:Base I/O address (SPP regs) (array of int)
parm: io_hi:Base I/O address (ECR) (array of int)
parm: irq:IRQ line (array of charp)
parm: dma:DMA channel (array of charp)
parm: init_mode:Initialise mode for VIA VT8231 port (spp, ps2,
epp, ecp or ecpepp) (charp)
4:47 p.m.
On Sat, 17 Oct 2020 at 17:05, ToddAndMargo via users <
users(a)lists.fedoraproject.org> wrote:
On 10/17/20 12:29 PM, George N. White III wrote:
> On Sat, 17 Oct 2020 at 16:23, ToddAndMargo via users
> <users(a)lists.fedoraproject.org <mailto:users@lists.fedoraproject.org>>
> wrote:
>
>[...]
> You might be able to get the chipset by looking at the label of the big
IC's
It is a "VIA VT8231"
$ modinfo parport_pc
filename:
/lib/modules/5.8.14-200.fc32.x86_64/kernel/drivers/parport/parport_pc.ko.xz
license: GPL
description: PC-style parallel port driver
author: Phil Blundell, Tim Waugh, others
[...]
parm: io:Base I/O address (SPP regs) (array of int)
parm: io_hi:Base I/O address (ECR) (array of int)
parm: irq:IRQ line (array of charp)
parm: dma:DMA channel (array of charp)
parm: init_mode:Initialise mode for VIA VT8231 port (spp, ps2,
epp, ecp or ecpepp) (charp)
Init_mode looks like something you should investigate.
You might also try booting a Fedora Live USB to duplicate the vendor's
setup.
--
George N. White III
6:22 p.m.
1407:A000 is not listed in the driver. That is what the driver uses
to load and determine it can handle the device.
If it is not in that list the driver believes it is not able to
operate it. Vendor will change the pciid if they change the device in
some way (or they can change it if the want to at random).
you can find a "new_id" in /sys under a parport_pc directory and echo
the id you have for this board assuming the driver can drive it (it
probably can). I am not sure of the format of the ID to be echo'ed
but google should be able answer. A modprobe + the echo will have to
be done on each reboot.
On Sat, Oct 17, 2020 at 4:55 PM ToddAndMargo via users
<users(a)lists.fedoraproject.org> wrote:
>
> On 2020-10-17 14:47, George N. White III wrote:
> > You might also try booting a Fedora Live USB to duplicate the vendor's
> > setup.
>
>
> That is a great idea. I have been waiting on it till
> I see what folks had to say here first
>
> If it works, what data should I collect?
> _______________________________________________
> users mailing list -- users(a)lists.fedoraproject.org
> To unsubscribe send an email to users-leave(a)lists.fedoraproject.org
> Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
7:55 p.m.
On 2020-10-17 16:22, Roger Heflin wrote:
1407:A000 is not listed in the driver. That is what the driver
uses
to load and determine it can handle the device.
If it is not in that list the driver believes it is not able to
operate it. Vendor will change the pciid if they change the device in
some way (or they can change it if the want to at random).
you can find a "new_id" in /sys under a parport_pc directory and echo
the id you have for this board assuming the driver can drive it (it
probably can). I am not sure of the format of the ID to be echo'ed
but google should be able answer. A modprobe + the echo will have to
be done on each reboot.
It went over my head.
:'(
1:23 a.m.
On 10/17/20 5:55 PM, ToddAndMargo via users wrote:
On 2020-10-17 16:22, Roger Heflin wrote:
> you can find a "new_id" in /sys under a parport_pc directory and echo
> the id you have for this board assuming the driver can drive it (it
> probably can). I am not sure of the format of the ID to be echo'ed
> but google should be able answer. A modprobe + the echo will have to
> be done on each reboot.
It went over my head.
echo "1407 A000" > /sys/bus/pci/drivers/parport_pc/new_id
Run "journalctl -fa" in another terminal while you do that to see if it
finds anything.
2:08 a.m.
On 2020-10-17 23:23, Samuel Sieb wrote:
On 10/17/20 5:55 PM, ToddAndMargo via users wrote:
> On 2020-10-17 16:22, Roger Heflin wrote:
>> you can find a "new_id" in /sys under a parport_pc directory and echo
>> the id you have for this board assuming the driver can drive it (it
>> probably can). I am not sure of the format of the ID to be echo'ed
>> but google should be able answer. A modprobe + the echo will have to
>> be done on each reboot.
>
> It went over my head.
echo "1407 A000" > /sys/bus/pci/drivers/parport_pc/new_id
Run "journalctl -fa" in another terminal while you do that to see if it
finds anything.
Only thing that showed up was some DHCP stuff
RATS!!
6:53 a.m.
This might also work:
echo 0000:01:00.2 > /sys/bus/pci/drivers/parport_pc/bind
I don't know that I (or any of us) know the exact process for adding a
new_id as it is not done often. I found the original design commit
and its process was echo to new_id and then echo 1 > probe_it (does
not exist) so there may be some way to rescan that is not obvious.
Maybe the echo "1407 a000" > new_id first and then the echo to the
bind. Or only the bind may be needed. There seems to be limited
documentation on all of this.
lspci -vvv -s 01:00.0
will show if there is a kernel driver in use and/or a kernel module
for the device.
On Sun, Oct 18, 2020 at 2:09 AM ToddAndMargo via users
<users(a)lists.fedoraproject.org> wrote:
>
> On 2020-10-17 23:23, Samuel Sieb wrote:
> > On 10/17/20 5:55 PM, ToddAndMargo via users wrote:
> >> On 2020-10-17 16:22, Roger Heflin wrote:
> >>> you can find a "new_id" in /sys under a parport_pc directory
and echo
> >>> the id you have for this board assuming the driver can drive it (it
> >>> probably can). I am not sure of the format of the ID to be echo'ed
> >>> but google should be able answer. A modprobe + the echo will have to
> >>> be done on each reboot.
> >>
> >> It went over my head.
> >
> > echo "1407 A000" > /sys/bus/pci/drivers/parport_pc/new_id
> >
> > Run "journalctl -fa" in another terminal while you do that to see if
it
> > finds anything.
>
> Only thing that showed up was some DHCP stuff
>
> RATS!!
> _______________________________________________
> users mailing list -- users(a)lists.fedoraproject.org
> To unsubscribe send an email to users-leave(a)lists.fedoraproject.org
> Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
5:32 a.m.
On Sun, 18 Oct 2020 at 04:09, ToddAndMargo via users <
users(a)lists.fedoraproject.org> wrote:
On 2020-10-17 23:23, Samuel Sieb wrote:
> On 10/17/20 5:55 PM, ToddAndMargo via users wrote:
>> On 2020-10-17 16:22, Roger Heflin wrote:
>>> you can find a "new_id" in /sys under a parport_pc directory and
echo
>>> the id you have for this board assuming the driver can drive it (it
>>> probably can). I am not sure of the format of the ID to be echo'ed
>>> but google should be able answer. A modprobe + the echo will have to
>>> be done on each reboot.
>>
>> It went over my head.
>
> echo "1407 A000" > /sys/bus/pci/drivers/parport_pc/new_id
>
> Run "journalctl -fa" in another terminal while you do that to see if it
> finds anything.
Only thing that showed up was some DHCP stuff
Since the card worked for the vendor, it is worth trying to
figure out why yours doesn't. There have been devices that
needed to be enabled by booting DOS or Windows, then booting
linux without cycling the power.
Does your BIOS have parallel port configuration?
Some vendors (Dell, HP) have EUFI diagnostic ssoftware that
may check parallel ports.
--
George N. White III
7:34 a.m.
On Tue, 20 Oct 2020 at 17:52, ToddAndMargo via users <
users(a)lists.fedoraproject.org> wrote:
On 2020-10-20 03:32, George N. White III wrote:
> Does your BIOS have parallel port configuration?
No
You may need something to "wake-up" the VT8231 (hopefully in a way that
enables the parallel
port). Try "sudo sensors-detect" to see if your system detects the VIA
VT8231 Integrated Sensors.
You should probably add your device to the The PCI ID Repository (ucw.cz)
<https://pci-ids.ucw.cz/> (There is a web-based
mechanism to add a device).
--
George N. White III
8:09 p.m.
On 2020-10-21 05:34, George N. White III wrote:
On Tue, 20 Oct 2020 at 17:52, ToddAndMargo via users
<users(a)lists.fedoraproject.org <mailto:users@lists.fedoraproject.org>>
wrote:
On 2020-10-20 03:32, George N. White III wrote:
> Does your BIOS have parallel port configuration?
No
You may need something to "wake-up" the VT8231 (hopefully in a way that
enables the parallel
port). Try "sudo sensors-detect" to see if your system detects theVIA
VT8231 Integrated Sensors.
You should probably add your device to the The PCI ID Repository
(ucw.cz) <https://pci-ids.ucw.cz/> (There is a web-based
mechanism to add a device).
--
George N. White III
it did not find it.
I just ordered another (different) card
7:05 a.m.
That pci-id that the underlying pci chip had (0xdead) is a magic
number often is used to signal something being wrong.
On Thu, Oct 22, 2020 at 8:10 PM ToddAndMargo via users
<users(a)lists.fedoraproject.org> wrote:
>
> On 2020-10-21 05:34, George N. White III wrote:
> > On Tue, 20 Oct 2020 at 17:52, ToddAndMargo via users
> > <users(a)lists.fedoraproject.org
<mailto:users@lists.fedoraproject.org>>
> > wrote:
> >
> > On 2020-10-20 03:32, George N. White III wrote:
> > > Does your BIOS have parallel port configuration?
> >
> > No
> >
> >
> > You may need something to "wake-up" the VT8231 (hopefully in a way
that
> > enables the parallel
> > port). Try "sudo sensors-detect" to see if your system detects
theVIA
> > VT8231 Integrated Sensors.
> >
> > You should probably add your device to the The PCI ID Repository
> > (ucw.cz) <https://pci-ids.ucw.cz/> (There is a web-based
> > mechanism to add a device).
> >
> > --
> > George N. White III
>
> it did not find it.
>
> I just ordered another (different) card
> _______________________________________________
> users mailing list -- users(a)lists.fedoraproject.org
> To unsubscribe send an email to users-leave(a)lists.fedoraproject.org
> Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
2:10 p.m.
On 2020-10-23 05:05, Roger Heflin wrote:
That pci-id that the underlying pci chip had (0xdead) is a magic
number often is used to signal something being wrong.
I wonder if the card itself is bad. It uses
a VIA chipset and VIA is kind-of-sort-of
known for being screw ups.
Anyway, I wrote the developer/maintainer of
parport_pc and offered to send both cards
to him for his testing, but have not heard
back yet. (I have another card that floods
Core 2 after the first print.)
4:55 p.m.
If both cards are flooding interrupts after printing that would seem
to indicate some sort of driver issue were it may not be handling and
acking an interrupt at the end so the card keeps sending it.
And yes, my experience with VIA is they seem to screw things up more
often than other vendors.
On Fri, Oct 23, 2020 at 2:10 PM ToddAndMargo via users
<users(a)lists.fedoraproject.org> wrote:
>
> On 2020-10-23 05:05, Roger Heflin wrote:
> > That pci-id that the underlying pci chip had (0xdead) is a magic
> > number often is used to signal something being wrong.
>
> I wonder if the card itself is bad. It uses
> a VIA chipset and VIA is kind-of-sort-of
> known for being screw ups.
>
> Anyway, I wrote the developer/maintainer of
> parport_pc and offered to send both cards
> to him for his testing, but have not heard
> back yet. (I have another card that floods
> Core 2 after the first print.)
> _______________________________________________
> users mailing list -- users(a)lists.fedoraproject.org
> To unsubscribe send an email to users-leave(a)lists.fedoraproject.org
> Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
5:56 p.m.
On Fri, 23 Oct 2020 at 16:10, ToddAndMargo via users <
users(a)lists.fedoraproject.org> wrote:
On 2020-10-23 05:05, Roger Heflin wrote:
> That pci-id that the underlying pci chip had (0xdead) is a magic
> number often is used to signal something being wrong.
I wonder if the card itself is bad. It uses
a VIA chipset and VIA is kind-of-sort-of
known for being screw ups.
That would explain why the vendor's card worked but
yours failed. It might be worth reaching out to local
CNC or Windows groups to see if someone could
check it out on a more widely used platform.
Anyway, I wrote the developer/maintainer of
parport_pc and offered to send both cards
to him for his testing, but have not heard
back yet. (I have another card that floods
Core 2 after the first print.)
Like many device modules, parport_pc is full of device-specific
code contributed by outsiders, so or device support, it can be
faster to contact someone familiar with your device:
linux/parport_pc.c at master · torvalds/linux · GitHub
<https://github.com/torvalds/linux/blob/master/drivers/parport/parport_pc....
has:
/* VIA 8231 support by Pavel Fedin <sonic_amiga(a)rambler.ru>
based on VIA 686a support code by Jeff Garzik <jgarzik(a)pobox.com> */
--
George N. White III
8:53 p.m.
On 2020-10-23 15:56, George N. White III wrote:
On Fri, 23 Oct 2020 at 16:10, ToddAndMargo via users
<users(a)lists.fedoraproject.org <mailto:users@lists.fedoraproject.org>>
wrote:
On 2020-10-23 05:05, Roger Heflin wrote:
> That pci-id that the underlying pci chip had (0xdead) is a magic
> number often is used to signal something being wrong.
I wonder if the card itself is bad. It uses
a VIA chipset and VIA is kind-of-sort-of
known for being screw ups.
That would explain why the vendor's card worked but
yours failed. It might be worth reaching out to local
CNC or Windows groups to see if someone could
check it out on a more widely used platform.
Anyway, I wrote the developer/maintainer of
parport_pc and offered to send both cards
to him for his testing, but have not heard
back yet. (I have another card that floods
Core 2 after the first print.)
Like many device modules, parport_pc is full of device-specific
code contributed by outsiders, so or device support, it can be
faster to contact someone familiar with your device:
linux/parport_pc.c at master · torvalds/linux · GitHub
<https://github.com/torvalds/linux/blob/master/drivers/parport/parport_pc....:
/* VIA 8231 support by Pavel Fedin <sonic_amiga(a)rambler.ru
<mailto:sonic_amiga@rambler.ru>>
based on VIA 686a support code by Jeff Garzik <jgarzik(a)pobox.com
<mailto:jgarzik@pobox.com>> */
--
George N. White III
The vendor did not tell me about th4e GUI problem till
much later.
I contacted Tim Waugh to maintainer of the parport_pc.
Have not heard back from him yet.
This from the link you gave me:
* Authors: Phil Blundell <philb(a)gnu.org>
* Tim Waugh <tim(a)cyberelk.demon.co.uk>
* Jose Renau <renau(a)acm.org>
* David Campbell
* Andrea Arcangeli
If Tim does not respond, I could always approach Phil
or Jose
I ordered a SIIG card out yesterday.
Thank you for all the help with this! I owe you one!
-T
8:17 p.m.
On Sat, 17 Oct 2020 at 20:22, Roger Heflin <rogerheflin(a)gmail.com> wrote:
To avoid the manual "echo XXX XXX > .../new_id":
<
https://askubuntu.com/questions/1195959/how-to-add-the-id-of-a-known-comp...
> you can find a "new_id" in /sys under a
parport_pc directory and echo
> the id you have for this board assuming the driver can drive it (it
> probably can).
> I am not sure of the format of the ID to be echo'ed
> but google should be able answer. A modprobe + the echo will have to
> be done on each reboot.
> On Sat, Oct 17, 2020 at 4:55 PM ToddAndMargo via users
> <users(a)lists.fedoraproject.org> wrote:
> > > On 2020-10-17 14:47, George N. White III wrote:
> > > You might also try booting a Fedora Live USB to duplicate the vendor's
> > > setup.
> > > > That is a great idea. I
have been waiting on it till
> > I see what folks had to say here first
> > > If it works, what data should I collect?
> > _______________________________________________
> > users mailing list -- users(a)lists.fedoraproject.org
> > To unsubscribe send an email to users-leave(a)lists.fedoraproject.org
> > Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> > List Archives:
> https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
> _______________________________________________
> users mailing list -- users(a)lists.fedoraproject.org
> To unsubscribe send an email to users-leave(a)lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
--
George N. White III
1407:A000 is not listed in the driver. That is what the driver
uses
to load and determine it can handle the device.
The "VIA VT8231" is a South Bridge with support for a bunch of
"legacy" ports per:
parm: init_mode:Initialise mode for VIA VT8231 port (spp, ps2,
epp, ecp or ecpepp) (charp)
Some sound cards use a VT8231.
I wonder if init_mode changes the device ID.
If it is not in that list the driver believes it is not able to
operate it. Vendor will change the pciid if they change the device in
some way (or they can change it if the want to at random).
If the driver in Fedora Live works either the vendor tested a different
card, used different driver options, or the driver has changed. It is
easy
to compare lsmod lists and the pciid. As usual, ArchLinux has good
documentation: <https://wiki.archlinux.org/index.php/Kernel_module
10:49 p.m.
On 2020-10-17 14:47, George N. White III wrote:
You might also try booting a Fedora Live USB to duplicate the
vendor's
setup.
Did not work with
https://download.fedoraproject.org/pub/fedora/linux/releases/32/Spins/x86...
either
1273
days inactive
1281
days old
30 comments
4 participants
participants (4)
-
George N. White III -
Roger Heflin -
Samuel Sieb -
ToddAndMargo