Re: [PARPORT] vmware 3.0 parport0 not working

From: Tim Waugh (twaugh@redhat.com)
Date: Mon Oct 29 2001 - 04:08:32 EST

  • Next message: Gian Ghodrat: "Re: [PARPORT] vmware 3.0 parport0 not working"

    On Mon, Oct 29, 2001 at 01:31:04AM +0100, Gian Ghodrat wrote:

    > > modprobe ppdev
    > >
    > > The /dev/parport0 node is driven by the ppdev module, and a bug in the
    > > kernel you are running (since fixed) means that it doesn't get
    > > automatically loaded when it should.
    >
    > unfortunately not working my lsmod now:
    > lsmod
    > Module Size Used by
    > parport_pc 14280 1 (autoclean)
    > lp 5408 0 (autoclean)
    > ppdev 8068 0 (unused)
    > parport 24288 1 [parport_pc lp ppdev]
    > sr_mod 11672 0 (autoclean) (unused)
    > scsi_mod 49244 1 (autoclean) [sr_mod]
    > soundcore 3364 0 (autoclean)
    > vmnet 17920 6
    > vmmon 18388 0
    > nls_iso8859-1 2848 3 (autoclean)
    > nls_cp437 4384 3 (autoclean)
    > vfat 9436 3 (autoclean)
    > fat 29368 0 (autoclean) [vfat]
    > serial 43936 0 (autoclean)
    > 3c59x 24776 1
    >
    > still the same vmware message.
    >
    > btw, my kernel version is 2.4.13

    I will assume then that the lsmod output you showed before was
    incomplete and that ppdev probably was there after all (2.4.13 has the
    ppdev-doesn't-load bug fixed already).

    There is a VMware bug that has been identified that might be catching
    you out here: although it doesn't use the kernel for parallel port
    access (it just writes to the ports directly), it _does_ use it for
    detecting ports in the first place. However, it makes the mistake of
    asking the kernel what hardware transfer modes it will use, rather
    than doing its own probing to find out what hardware transfer modes
    are available (regardless of whether or not the kernel will use
    them).

    A bug in kernels before 2.4.13 meant that the kernel would advertise
    more hardware modes than it would actually use (for example, ECP when
    there is no interrupt configured; the parport_pc implementation relies
    on interrupts to use hardware ECP support at the moment).
    Unfortunately, in fixing this bug IRQ probing got broken. I have sent
    a patch to Linus to fix it, and it is in 2.4.13-ac2 onwards.

    A workaround should be to specify the base address and IRQ line to
    parport_pc. See Documentation/parport.txt for how to do that.

    Tim.
    */



    -- 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 Oct 29 2001 - 04:16:34 EST