parport does not work in diection "in"

grandixximo wrote:

this is what lspci -vv give me

Region 0: I/O ports at 1030
Region 1: I/O ports at 1028
Region 2: I/O ports at 1020
Region 3: I/O ports at 1018
Region 4: I/O ports at 1010

Do the ports work in output mode? You should check which of these addresses
is connected to which port. Usually, the mode control register will be ABOVE
the port address. So, if the base address of one of the ports is 1030, there
is nothing above it for the mode control. I might take a guess that the
base registers for the two ports might be 1010 and 1020, or 1018 and 1028.
That would leave a register group above each of the port registers for the
mode control registers. (There are generally 3 mode control registers in
a group for each port.)

Jon

Kernel driver in use: parport_pc
Kernel modules: parport_pc

Just noticed this in your lspci output.

See the previous link re parports, driver is normally blocked from being loaded automatically.

I'll leave Jon to follow that if relevant, he has forgotten more than I know about these ports.

regards

All the ports work in output mode with the address i have wrote, only port 1020 work both ways in and out.

i'll try to see if i can prevent the parport driver to load.

if i try to use numbers 1018 and 1028 i get error

insmod: error inserting '/..../hal_parport.ko':
-1 Device or resource busy

The parport_pc does not load anymore, so now when i do lspci -vv

Kernel driver in use: parport_pc

is not there anymore, all the rest is same as it was BUT

Still nothing has changed i can use address 1020 as in or out, but address 1030 and 378 only as out.

I don't get any error with all the address now, and i have try loading all from 1000 to 1030 including 1018 and 1028, none of them work when my pendant is connected to the PCI hardwired parport (wich work as out on 0x1030)

Same goes for the 0x378 parport, it does not work as in, even after changing BIOS settings to SPP.

@jmelson

The ports both work as "out" on address 1020 for the flyer and 1030 for the hardwired.

It maybe that the hardwired port does not have mode control register, or maybe they are NOT ABOVE the port address?

Hi again

I had a huge lot of problems with one of these cards some years back, tried looking back over things I did to get it working and came up with these snippets. I seem to remember the 9815 was notorious.
Might assist, are not a solution per se.

Data sheet for the card
www.asix.com.tw/FrootAttach/datasheet/MC...5_Datasheet_v200.pdf

Another bit I seem to recall was that the card is supposed to be PnP which causes some problems on its own.
It may not be initialised properly under linux running EMC.
This manifests itself with registers shown as disabled, but I seem to recall that the below actually assisted when I was trying to force it into a mode which allowed running as input on pins 2-9

/sbin/insmod /lib/modules/CORRECT_KERNEL_HERE-rtai/kernel/drivers/parport/parport_pc.ko
/sbin/rmmod ppdev
/sbin/rmmod lp
/sbin/rmmod parport_pc

Thirdly, this C program was written by Jeff or Jon or possibly Chris, whilst it should not be necessary to force the card into EPP mode to get it to work in input mode, I seem to recall that only after I had compiled and used the program, did I get the card to work.

Finally, try moving the card to another slot, preferably swapping it with another card.
The computer allocates the port addresses and interrupts dynamically and sometimes something as simple as this works.
I can't figure out why your addresses are all so close to each other, I have always had at least a 0x200 separation between port addresses in the cards I have tried in the past.

Just some thoughts, one of them might do something.

grandixximo wrote:

Same goes for the 0x378 parport, it does not work as in, even after changing BIOS settings to SPP.

Now, that is expected. SPP is the original output-only printer port, so it would be expected that
input won't work. PS/2 or Bidir is the lowest mode that supports input on the data lines.

The ports both work as "out" on address 1020 for the flyer and 1030 for the hardwired.

It maybe that the hardwired port does not have mode control register, or maybe they are NOT ABOVE the port address?

Well, your tests confirm the data register addresses. But, the mode control registers could
be anywhere. Apparently they could be below the data port addr, or maybe the mode
control regs are BOTH in the same range of 8 addresses.

Jon

ArcEye wrote:

Thirdly, this C program was written by Jeff or Jon or possibly Chris, whilst it should not be necessary to force the card into EPP mode to get it to work in input mode, I seem to recall that only after I had compiled and used the program, did I get the card to work.

//cause standard PCI parallel port card to go to EPP mode

That code is effectively equivalent to my pcisetup program, which is on my web site.
It is not the version written by me, however. But, it assumes the ECR register is at
base address + 0x402, which we have pretty well established is not the case for
your board. I think we need to make up a new version of this program which
allows you to type in the ECR address directly, and maybe gives some diagnostic
results afterward.

Finally, try moving the card to another slot, preferably swapping it with another card.
The computer allocates the port addresses and interrupts dynamically and sometimes something as simple as this works.
I can't figure out why your addresses are all so close to each other, I have always had at least a 0x200 separation between port addresses in the cards I have tried in the past.

That may help, especially if it causes the parport board to be enumerated before/after some
other PCI card. If there is no other PCI card in the system, it is less likely to help.

Jon

Maybe i should have told you guys before, my PC it's not a normal PC, it's a Mini-ITX, i have only one PCI, maybe that is why the address are so near??

The 0x378 parport does not work as "in" even if set as bi-directional or EPP in the bios

after running parpot-pc.ko

on lspci-v i get

04:00.0 Class 9815: NetMos Technology PCI 9815 Multi-I/O Controller (rev 01)
Subsystem: LSI Logic / Symbios Logic Device 0020
Flags: medium devsel
I/O ports at 1870
I/O ports at 1000
I/O ports at 1460
I/O ports at 1468
I/O ports at 14d0
I/O ports at 90b00000
Kernel modules: parport_pc

04:00.1 Class 9815: NetMos Technology PCI 9815 Multi-I/O Controller (rev 01)
Subsystem: LSI Logic / Symbios Logic Device 0020
Flags: medium devsel
I/O ports at 1010
I/O ports at 1020
I/O ports at 1470
I/O ports at 1478
I/O ports at <ignored>
I/O ports at 1030
Kernel modules: parport_pc

04:00.2 Class 9815: NetMos Technology PCI 9815 Multi-I/O Controller (rev 01)
Subsystem: LSI Logic / Symbios Logic Device 0020
Flags: medium devsel
I/O ports at 1040
I/O ports at 1050
I/O ports at 1480
I/O ports at 1488
I/O ports at 1060
I/O ports at 90b00010
Kernel modules: parport_pc

04:00.3 Class 9815: NetMos Technology PCI 9815 Multi-I/O Controller (rev 01)
Subsystem: LSI Logic / Symbios Logic Device 0020
Flags: medium devsel
I/O ports at 1070
I/O ports at 1080
I/O ports at 1490
I/O ports at 1498
I/O ports at <ignored>
I/O ports at 1090
Kernel modules: parport_pc

04:00.4 Class 9815: NetMos Technology PCI 9815 Multi-I/O Controller (rev 01)
Subsystem: LSI Logic / Symbios Logic Device 0020
Flags: medium devsel
I/O ports at 10a0
I/O ports at 10b0
I/O ports at 14a0
I/O ports at 14a8
I/O ports at 10c0
I/O ports at 90b00020
Kernel modules: parport_pc

04:00.5 Class 9815: NetMos Technology PCI 9815 Multi-I/O Controller (rev 01)
Subsystem: LSI Logic / Symbios Logic Device 0020
Flags: medium devsel
I/O ports at 10d0
I/O ports at 10e0
I/O ports at 14b0
I/O ports at 14b8
I/O ports at <ignored>
I/O ports at 10f0
Kernel modules: parport_pc

04:00.6 Class 9815: NetMos Technology PCI 9815 Multi-I/O Controller (rev 01)
Subsystem: LSI Logic / Symbios Logic Device 0020
Flags: medium devsel
I/O ports at 1400
I/O ports at 1410
I/O ports at 14c0
I/O ports at 14c8
I/O ports at 1420
I/O ports at 90b00030
Kernel modules: parport_pc

04:00.7 Class 9815: NetMos Technology PCI 9815 Multi-I/O Controller (rev 01)
Subsystem: LSI Logic / Symbios Logic Device 0020
Flags: medium devsel
I/O ports at 1430
I/O ports at 1440
I/O ports at 14e0
I/O ports at 14e8
I/O ports at <ignored>
I/O ports at 1450
Kernel modules: parport_pc


and nothing works no more

grandixximo wrote:

Maybe i should have told you guys before, my PC it's not a normal PC, it's a Mini-ITX, i have only one PCI, maybe that is why the address are so near??

The 0x378 parport does not work as "in" even if set as bi-directional or EPP in the bios

after running parpot-pc.ko

on lspci-v i get

04:00.0 Class 9815: NetMos Technology PCI 9815 Multi-I/O Controller (rev 01)
. . . .


and nothing works no more

AIeeeeee, WAYY too many parallel ports, I lost count. One of the terrible curses of the PC architecture
is the very limited I/O space and the insanely limited number of interrupt vectors. I remember the days
of the PDP-11, where you had the entire memory space available for I/O devices, and room for
almost 1000 interrupt vectors, when you needed to do special systems with a lot of I/O.

Do you REALLY have that many ports, or has the BIOS gone crazy? You say only one PCI
port, so the BIOS was confused, or else the memory area where it writes this info
must have gotten scrambled by the parport-pc (or other) module. That is just a region in
very low memory where it leaves a snapshot of the PnP configuration before booting the
OS.

Jon

i wrote this as suggested that it may help

/sbin/insmod /lib/modules/CORRECT_KERNEL_HERE-rtai/kernel/drivers/parport/parport_pc.ko

and then i got that strange many ports in lspci -vv

but everything returned to normal once i restarted the PC.

normal meaning i cannot use port 378 nor 1030 as IN...

I cannot possibly have that many parport physically on my PC, as you say there are not enough I/O