> Richard Earnshaw <rearnsha@arm.com> writes:
> > 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.

So I tried this again last night (having remembered to unmount all my slow 
disks first :-).  It still stiffs the machine entirely after printing a 
few lines.  The only info I have is that shortly prior to crashing, systat 
is showing around 32k parallel port interrupts in the preceding 5 second 
interval, which seems pretty high;  my best guess is that there is some 
race condition when the printer is sucking data out as fast as it can be 
sent.

I'll file a PR on it when I get home, but I won't be able to add much more 
detail than I've supplied above.

Richard.