[PARPORT] pd.o module with delay=0 && mode=5 options

From: Miroslav BENES (mbenes@tenez.cz)
Date: Mon Jan 13 2003 - 11:16:50 EST

  • Next message: David Hugh-Jones: "[PARPORT] CDRW400 and pg driver"

    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^Pp^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