[lug] Printer problem with vmware

D. Stimits stimits at idcomm.com
Mon Dec 3 17:25:33 MST 2001


John Karns wrote:
> 
> On Sun, 2 Dec 2001, Dhruva B. Reddy said:
> 
> > I just installed vmware on my 2.4.14 machine, and now I can't seem to
> > print from Linux.  The vmware install script created four devices,
> >
> >       /dev/parport0
> >       /dev/parport16
> >       /dev/parport32
> >       /dev/parport48
> >
> > Which, according to the documentation, are some sort of bidirectional
> > ports (as opposed to the unidirectional port, lp0).
> >
> > Now when I try to print from Linux, I get no indication that anything is
> > wrong, either from lpr or lpd.  When I run lpq, I can see the jobs there.  It
> > just doesn't print.
> >
> > Any ideas?
> 
> This kind of thing can be tricky to troubleshoot, and difficult to
> describe verbally, as there are so many variables, including the type of
> printer that you're using (bi-directional or uni-directional), not to
> mention your kernel config.  1st I would ask if your kernel has lp support
> integrated or as a module.  If it's integrated then it could be
> conflicting with the modules that are being loaded.
> 
> Beyond that, My short answer would be to restore the old device to
> point at your printer.
> 
> - "/etc/rc.d/vmware stop"
> 
> - use rmmod to unload any vmware modules such as vm
> 
> - load the old lp module (it would make sense to modularize all you
> parallel port driver stuff, so that you can load & unload specific modules
> as desired.
> 
> ----------------------------------------------------------------
> John Karns                                        jkarns at csd.net
> 
> _______________________________________________
> Web Page:  http://lug.boulder.co.us
> Mailing List: http://lists.lug.boulder.co.us/mailman/listinfo/lug

One minor possibility, I wonder if the parport requires some other
support, which is in module form, and which is failing to load? Any time
you create your major number support via built-in kernel functionality
(versus a module), then autoloading of all subsequent modules will
break, they must go in by hand after that. The kernel module autoloading
is triggered by a request for a missing device major number
functionality. Supply it as a non-module, all the minor number support
that is triggered upon major number loading will no longer happen. And
as I recall, something about parport requires a chain of support.

D. Stimits, stimits at idcomm.com



More information about the LUG mailing list