Hi all !
Some times ago (Mar 2001) I asked in this conference about lpt
performance - transfering data from/to external hdd with Shuttle
Epat chip.
I got answer from Stephen Mollett :
"You could try setting the port delay to 0 - I found that this
improved my throughput substantially.
Try:
options pd drive0=0x378,,,5,,,0,0 drive1=0x378,,,5,,,0,1"
This option worked on 2.4.2 kernel.
But When I can use the same options it on 2.4.18-19.8.0 kernel
(from RH), I get ALWAYS this message :
krnl: paride: version 1.06 installed (parport)
krnl: paride: epat registered as protocol 0
krnl: pd: pd version 1.05, major 45, cluster 64, nice 0
krnl: epat_init_proto<6>parport0: PC-style at 0x378, irq 7
[PCSPP,TRISTATE,EPP]
krnl: pda: Sharing parport0 at 0x378
krnl: pda: epat 1.02, Shuttle EPAT chip c5 at 0x378, mode 5 (EPP-
32), delay 0
krnl: pda: ^Pÿ^P?^Pû\204t^G, master, 871411712 blocks [425494M],
(4096/63/20021), fixed media
krnl: epat_init_protopdb: Sharing parport0 at 0x378
krnl: pdb: epat 1.02, Shuttle EPAT chip c5 at 0x378, mode 5 (EPP-
32), delay 0
krnl: pdb: ^O$Ì5^Pû¨p^G, slave, 145006592 blocks [70804M],
(4096/63/17206), fixed media
krnl: pda:pda: do_pd_read_drq: status = 0x10050 = SEEK READY
TMO
krnl: pda: do_pd_read_drq: status = 0x10050 = SEEK READY TMO
krnl: pda: do_pd_read_drq: status = 0x10050 = SEEK READY TMO
krnl: unknown partition table
krnl: pdb:pdb: do_pd_read_drq: status = 0x10050 = SEEK READY
TMO
krnl: pdb: do_pd_read_drq: status = 0x10050 = SEEK READY TMO
krnl: pdb: do_pd_read_drq: status = 0x10050 = SEEK READY TMO
krnl: unknown partition table
.. and disks are not recognized.
When I now reload pd module with options :
insmod pd drive0=0x378,,,4,,,1,0 drive1=0x378,,,4,,,1,1
(mode = 0 [4-bit], delay=1), both disks are responding well :
krnl: pd: pd version 1.05, major 45, cluster 64, nice 0
krnl: epat_init_protopda: Sharing parport0 at 0x378
krnl: pda: epat 1.02, Shuttle EPAT chip c5 at 0x378, mode 4 (EPP-
16), delay 0
krnl: pda: ST313032A, master, 25434228 blocks [12419M],
(16383/16/63), fixed media
krnl: epat_init_protopdb: Sharing parport0 at 0x378
krnl: pdb: epat 1.02, Shuttle EPAT chip c5 at 0x378, mode 4 (EPP-
16), delay 0
krnl: pdb: ST340016A, slave, 78165360 blocks [38166M],
(16383/16/63), fixed media
krnl: pda: pda1 pda2 pda3
krnl: pdb: pdb1 pdb2 < pdb5 pdb6 pdb7 >
And when I now again reload pd.o module with (original) fastest
options, it will be SOMETIMES working well :
krnl: pd: pd version 1.05, major 45, cluster 64, nice 0
krnl: epat_init_protopda: Sharing parport0 at 0x378
krnl: pda: epat 1.02, Shuttle EPAT chip c5 at 0x378, mode 5 (EPP-
32), delay 0
krnl: pda: ST313032A, master, 25434228 blocks [12419M],
(16383/16/63), fixed media
krnl: epat_init_protopdb: Sharing parport0 at 0x378
krnl: pdb: epat 1.02, Shuttle EPAT chip c5 at 0x378, mode 5 (EPP-
32), delay 0
krnl: pdb: ST340016A, slave, 78165360 blocks [38166M],
(16383/16/63), fixed media
krnl: pda: pda1 pda2 pda3
krnl: pdb: pdb1 pdb2 < pdb5 pdb6 pdb7 >
This behaviour I observe on all machines with on-board lpt port
(Pentium / PII / P4).
Q:
Why the parport/paride/epat/pd modules before using nedds to be
"reinitialized" in slower mode ?
Why this behavior was not appeared od 2.4.2 kernel - was in
mentioned modules some changes ?
Thank you for any answer.
Miroslav BENES
IT manager
TENEZ a.s.
Chotebor
Czech Rebublic
www.tenez.cz
-- To unsubscribe, send mail to: linux-parport-request@torque.net --
-- with the single word "unsubscribe" in the body of the message. --
This archive was generated by hypermail 2b29 : Mon Jan 13 2003 - 11:21:58 EST