Date: Mon, 27 Apr 92 10:14:15 EST From: Dwight D. McKay (The Moderator) Reply-To: Suns-at-Home@orchestra.ecn.purdue.edu Subject: Suns-at-Home Digest V5 #18 To: Suns-at-Home-List Suns-at-Home Digest Mon, 27 Apr 92 Volume 5 : Issue 18 Today's Topics: pseudo Sun-3 saga [ed. --ddm] Suns-at-Home Digest V5 #17 +--------------------------------------------------------------------+ | Submissions: suns-at-home \ @orchestra.ecn.purdue.edu | | Requests: suns-at-home-request > -- or -- | | Archives: suns-at-home-archives / ...rutgers!pur-ee!... | +--------------------------------------------------------------------+ ---------------------------------------------------------------------- Date: Thu, 23 Apr 92 13:02:59 -0500 From: att!bromo!wtr Subject: pseudo Sun-3 saga [ed. --ddm] To: att!orchestra.ecn.purdue.edu!Suns-at-Home The next installment in the continuing saga of getting my pseudo Sun-3 working... When we last left our hero, he had his Sun-2/50 chassis fitted with a Sun-3 motherboard and was attempting to get the Sun monitor working. I have installed an ID PROM, which I was lacking. We have installed SunOS 4.1.1 on the SCSI drive and have booted the machine up. (and there was much rejoycing!) However, during the boot, right after the disk controllers are located, we get the following message: "No default frame buffer found" and the monitor remains blank, without even a white background. Both monitors that I currently have work with my 2/50 motherboard, and are model # 540-1062-01 which are supposed to work with a Sun-3 (one of them supposedly came off of a 3/160. The EEPROM settings seem to be correct. When I try to read/write to /dev/fb or /dev/bwtwo0, I get "device or address not found" If I write to /dev/bwone0, or any other display driver, I just get "device not found" So it looks like the kernel cannot find the address of the frame buffer. Note that this prevents me from reseting the FBVIDEO_ON bit with an ioctl() call. The motherboard is part number 501-1164 which is a 4-Meg CPU from a 3/100. According to the Sun people at their 800 number, the 501-1164 was replaced by the 501-1208, which I believe is the 3/75-160 motherboard. So they should be compatable, right? So what am I doing wrong? OS version? EEPROM settings? What? Could it be the kernel driver implementation? If anyone out there has a working 3/100, could you send me a copy of your kernel configuration file? I want to see the bwtwo0 setup. Alternately, could someone who has an older SunOS verion (3.5?) tell me if the 3/100 is mentioned in the GENERIC configuration file? Everything else seems to work great, and I don't want to have to go and purchase a new board just to get the monitor functioning. Hmm,... I wounder if Sun would allow me to trade them a 3/100 board for a 3/160? 1/2 :-)'s here, I'm partially serious! Any and all help is greatly apreciated. ------------------------------ Date: Mon, 20 Apr 1992 18:49:47 -0400 From: mcr@Sandelman.OCUnix.On.Ca (Michael Richardson) Subject: Suns-at-Home Digest V5 #17 To: Suns-at-Home@ecn.purdue.edu, kevinc@mimaster.pen.tek.com In article <9204201823.AA22250@orchestra.ecn.purdue.edu> you write: >From: Kevin Cosgrove 627-3259 >Subject: Dial-in/dial-out ALMOST working on Sun-3/50 (4.1.1_U1) >To: Suns-at-Home@orchestra.ecn.purdue.edu > >I'm trying to get one port on my Sun-3/50 (SunOS 4.1.1_U1) to serve for >dial-in/dial-out and UUCP. The best I've been able to do is to get one >dialing direction and UUCP. I can't seem to get all three functions >working in turn with the same port configuration. If dial-in works, then UUCP dial-in works. There are only two functions, not three. I run SunOS 4.1.0 on a 3/60 and have no problems (except for DTR problems which one patch fixed by killing BSD and SYSV stuff. see my other message) >The biggest clue I have is that anytime I run a getty on /dev/ttyd0 I run getty on /dev/tty[ab], but same device, difference name. I tell UUCP to dial out using /dev/cua1 (ttya is a hardwired SLIP connection to an Amiga 2000). > UUCP-out /dev/ttya > dial-in /dev/ttyd0 > tip-out /dev/cua0 Wrong. UUCP dials out on /dev/cua0. > cua0 "/usr/etc/getty D2400" unknown off local > cua1 "/usr/etc/getty D2400" unknown off local These probably shouldn't even be there, but they are 'off' so it doesn't matter much. >5. Try /usr/etc/ttysoftcar -a. This seems to break all uucp outbound > connections. I commented this out of /etc/rc and don't run it by > hand anymore. I have software carrier disabled for both. >Date: Wed, 15 Apr 92 01:03:41 -0400 >From: Bob Sutterfield >Subject: PPP and SLIP - supported implementation available >To: suns-at-home@orchestra.ecn.purdue.edu > >This brief commercial announcement will be of interest to lots of >remote UNIX users, including people (like me) with Suns at home: >Morning Star Technologies sells an implementation of PPP and SLIP. >When compared to the free SLIPs and CSLIPs and PPPs that you have >battled before, our product is easier to install, transparent to use, >tracks (sometimes leads :-) the latest IETF PPP standards, and has >more features, fewer bugs, useful documentation, and amazing customer >support. So that people know that this isn't the only option: I have hacked sliplogin (from the utai collection) to optionally drop carrier when the packet rate drops below a settable value. I use a hacked up version of Taylor UUCP to dialout. (I think that my mods are unnecessary with 1.03 now). Except for kicking gated into exchanging routes to the remote network(s), it works really well. The difficulties are with setting up everything *else* that you need to get SLIP working nicely. Of course, I don't dial on demand (yet). -- :!mcr!: | The postmaster never | So much mail, Michael Richardson | resolves twice. | so little time. HOME: mcr@sandelman.ocunix.on.ca Bell: (613) 237-5629 SCHOOL: 192228@physics.carleton.ca ------------------------------ End of Suns-at-Home Digest ******************************