>>> The zip drive works regardless of the presence of the printer.
>>> To use the printer, I have to unplug the Zip drive and plug in
>>> the printer to lpt. Everything is compiled into the kernel,
>>> parport, parallel printer/PC-hardware, etc.
>> If you plug the printer in, print with it, unplug it, plug the
>> Zip drive (freshly powered) in and plug the printer into that,
>> does printing work? If not, I'd suspect the Zip drive hardware.
> Well, I just tried it with a different Zip drive. I switched
> cables around, too. The zip drives both work fine. I can mount,
> read, write, whatever, zip disks. But the pass-through refuses
> to work. The printer seems like it's not connected. Then I
> unplug the Zip drive, and plug the printer in, and voila!, the
> print queue starts spewing forth in paper form.
Is this one of the printers that requires a bi-directional printer
line? If so, you may wish to play with the sub options under the
various printer port selections:
Q> General setup --->
Q> <*> Parallel port support
Q> <*> PC style hardware
Q> [ ] Support foreign hardware
Q> Plug and Play support --->
Q> [*] Plug and play support
Q> <M> Auto probe for parallel devices
Q> Block devices --->
Q> <M> Parallel port IDE device support
Q> <M> (Assorted ParIDE options)
Q> SCSI support --->
Q> SCSI low level drivers --->
Q> <M> IOMEGA parallel port (ppa - older drives)
Q> <M> IOMEGA parallel port (imm - newer drives)
Q> [ ] Use slow (but safe) EPP-16
Q> [ ] Assume slow parport control register
Q> Character devices --->
Q> <M> Parallel printer support
Q> [*] Support IEEE1284 status readback
To be honest, there's enough there for the parallel port to qualify as
a separate subsystem in its own right, with its own configuration
section. I'd assume the reason this isn't done is because of the
number of other subsystems that impact on it.
> It's definitely not a hardware problem. I tested both on my NT
> box, and printing, etc, works just fine through the passthrough.
> My only option left is to believe it's something messed up in
> the parport code.
A friend of mine has a zip drive with an old Epson FX80 printer that
works fine, but when she plugged her new Epson Stylus in the passthru
instead, that didn't work. I would therefore tend to suspect that the
more modern printers are doing something that the older ones aren't,
probably sending status info back to the computer and refusing to
continue until it's acknowledged...
> Has it changed since 2.1.x? This same setup worked in 2.1.x
> (well, the 90s, anyhow). I'll double-check the BIOS one more
> time to be sure the port is set up right. Hopefully I will find
> something I've missed in there.
I can't advise on that as I've not been in the position to try it
out myself recently, sorry.
> BTW, this happens on 2.2.6 - 2.2.9.
That's worrying...
Best wishes from Riley.
+----------------------------------------------------------------------+
| There is something frustrating about the quality and speed of Linux |
| development, ie., the quality is too high and the speed is too high, |
| in other words, I can implement this XXXX feature, but I bet someone |
| else has already done so and is just about to release their patch. |
+----------------------------------------------------------------------+
* ftp://ftp.MemAlpha.cx/pub/rhw/Linux
* http://www.MemAlpha.cx/kernel.versions.html
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/