Subject: Re: printing dont try this!
To: Adrian P. Ireland <aireland@indigo.ie>
From: Robert Black <r.black@ic.ac.uk>
List: port-arm32
Date: 09/09/1997 18:41:11
On Sep 9,  6:04pm, Adrian P. Ireland wrote:
> Subject: printing dont try this!
> Hi there,
>
> I did not get any replies regarding my printing problem
> 	RPC600 38MB SA RO3.7
> 	Kernel voy/5328
> 	HPLJ6L on the parallel printer port
>
> I noticed that on boot up the kernel reported lpt0 at .....
>
> Big mistake but, I tried to get printing working by editing
> my /etc/printcap file
>
> .... [ /etc/printcap ] .....start
> #	$NetBSD: printcap,v 1.3 1996/05/08 17:19:45 thorpej Exp $
> #	@(#)printcap	5.3 (Berkeley) 6/30/90
>
> # The original
> #lp|local line printer:\
> #	:lp=/dev/lp:sd=/var/spool/lpd:lf=/var/log/lpd-errs:
>
> # Adrian's hacked bit
> lp|local line printer:\
> 	:lp=/dev/lpt0:sd=/var/spool/lpd:lf=/var/log/lpd-errs:
> 	           ^^
> .... [ /etc/printcap ] .....end
>
> I started up the printer demon (I think)
> myname# lpd
> I tried to print a text file (I think)
> myname# lpr xplot.save
> At this point things looked good because the printer light flashed
> I expected perhaps junk to come out as I had not done anything to
> tell my system that I wanted text as for the HPLJ, ?PCL.
>
> I then tried to see if there was a queue
> myname# lpq
> Process = f155ab00 pid = 89 comm = csh
> CPSR = 6000009b Trackback info (frame = f2d02fb0)
> fp -> lr = f0106278 fp -> pc = f011546C
> Trapframe PC = f011d358
> Trapframe SPSR = 4000009b
> Branch through zero
> The system whould now be considered very unstable :-)
> panic: Yikes! in cpu_switch() but not in SVC mode (0000009b)
> Stopped at 0xf011e808: ldmdb r11,{r11,r13,r15}
> db>
>
> Well that was that I tried halt, reboot etc but eventually managed to
> lock things up with until.
> Now when I try to reboot I get back to the db> promt each time.
>
> Terrible !!!!!
> Suppose I will have to reinstall again, where is that floppy gone?

At a guess power-cycling should be good enough. Something is probably wedged in
a strange state. RiscBSD can't reset the entire hardware state to something
known at boot time because of the way the RiscPC is designed so it does make
assumptions about hardware state.

Cheers

Rob