Richard Earnshaw <rearnsha@arm.com> writes:
> mark@causality.com said:
> > > 2) Will it print? ( I can't get 1.3.2 or 1.2 to work ) 
> > hmm as I am sure users hate me saying "works for me" ;-) 
> 
> I haven't tried for a while, so this may be out of date info (and I'm also 
> guilty of not reporting it).  But I've had problems in the past with 
> printing on the RISC PC's interrupt-driven parallel port interface.  
> Things work fine on the polled interface (though it takes more machine 
> cycles, I guess); but when interrupt driven the machine can freeze 
> entirely, so I suspect that somehow the IRQs aren't (weren't?) being 
> cleared.

So, I'm not familiar with riscpc's, but it looks from the config file
like its parallel port is provided by a x86 pc-ish super-io chip.

The behaviour you describe reminds me of a long-standing problem on
some NetBSD/i386 systems.  In a nut shell, try to use the interrupt
driven lpt interface on some machines, and they'd hang or reboot
without so much as a panic.  (There's a PR on it, 2558.  It was fixed
relatively recently.)

The problem ended up being missing delay/DELAY calls in the lpt
driver, which have now been added.  (There was also a little problem
with the delay() implementation on the i386, in that it just returned
when presented with values <(=?) 5, but that was easy enough to
fix... 8-)


Anyway, since you folks also use a PC-ish lpt controller on a PC-ish
super-io chip, it could well be that the problem was also fixed for you.


cgd
-- 
Chris Demetriou - cgd@netbsd.org - http://www.netbsd.org/People/Pages/cgd.html
Disclaimer: Not speaking for NetBSD, just expressing my own opinion.