From cse.psu.edu!9fans-outgoing-owner Tue Oct 31 19:40:01 1995 Received: from colossus.cse.psu.edu ([130.203.1.2]) by cannon.ecf.toronto.edu with SMTP id <10098>; Tue, 31 Oct 1995 19:39:57 -0500 Received: by colossus.cse.psu.edu id <78684>; Tue, 31 Oct 1995 19:23:16 -0500 Received: from postman.ncube.com ([134.242.8.47]) by colossus.cse.psu.edu with SMTP id <78666>; Tue, 31 Oct 1995 19:20:03 -0500 Received: from garcon.ncube.com by postman.ncube.com (4.1/SMI-4.1) id AA06398; Tue, 31 Oct 95 15:06:23 PST Received: from pejs.ncube.com by garcon.ncube.com (5.x/SMI-SVR4) id AA19750; Tue, 31 Oct 1995 15:06:21 -0800 Date: Tue, 31 Oct 1995 18:06:21 -0500 From: sch@postman.ncube.com (Steve Hemminger) Message-Id: <9510312306.AA19750@garcon.ncube.com> Received: by pejs.ncube.com (4.1/SMI-4.1) id AA02751; Tue, 31 Oct 95 15:06:53 PST To: 9fans@cse.psu.edu Subject: UART FIFO not working Sender: owner-9fans@cse.psu.edu Precedence: bulk Reply-To: 9fans@cse.psu.edu Status: RO When running on Pentium systems the checks for 16550 FIFO do not work (registers don't respond fast enough). Here is better code that checks for FIFO's at system startup time and sets FIFO depth based on baudrate. Also, it detects certain chipsets that are known to have non working FIFO's. diff devuart.c devuart.c.orig 29,35c29 < Frrst= (1<<1), /* receiver reset */ < Fxrst= (1<<2), /* transmit reset */ < Fdma= (1<<3), < Ftrig1= 0x00, /* trigger after 1 input character */ < Ftrig4= 0x40, /* trigger after 4 input characters */ < Ftrig8= 0x80, /* trigger after 8 input characters */ < Ftrig14= 0xc0, /* trigger after 14 characters */ --- > Ftrig= (1<<6), /* trigger after 4 input characters */ 83c77,81 < int fifo; /* fifo control */ --- > > /* fifo control */ > int fifoon; > int nofifo; > int istat; 136,141d133 < < /* Set the FIFO threshold based on the baudrate */ < if (up->fifo) < uartwrreg(up, Fifoctl, Fenab|Fxrst|Frrst| < ((rate <= 1200) ? Ftrig1 : < (rate > 9600) ? Ftrig14 : Ftrig8)); 235a228,255 > void > uartfifoon(Uart *p) > { > ulong i, x; > > if(p->nofifo) > return; > > x = splhi(); > > /* empty buffer */ > for(i = 0; i < 16; i++) > uartrdreg(p, Data); > uartintr(0, p); > > /* turn on fifo */ > p->fifoon = 1; > uartwrreg(p, Fifoctl, Fenab|Ftrig); > > uartintr(0, p); > if((p->istat & Fenabd) == 0){ > /* didn't work, must be an earlier chip type */ > p->nofifo = 1; > } > > splx(x); > } > 246a267,268 > /* turn on fifo's */ > uartfifoon(up); 250a273,278 > > /* turn off fifo's */ > if(up->fifoon){ > up->fifoon = 0; > uartwrreg(up, Fifoctl, 0); > } 314d341 < print("uart:"); 317,335d343 < < /* Check for NS16550 fifo */ < up->fifo = 0; < uartwrreg(up, Fifoctl, Fenab|Frrst|Fxrst|Ftrig14); < < delay(100); < < print(" %d: ", up - uart); < if ((uartrdreg(up, Istat) & 0xc0) == 0xc0) < if ((uartrdreg(up, Fifoctl) & Ftrig14) == Ftrig14) { < up->fifo = 1; < print("ns16550a fifo", up - uart); < } < else < print("ns82550/16550, broken fifo"); < else < print("ns82450/16450, no fifo"); < uartwrreg(up, Fifoctl, 0); < 348d355 < print("\n"); From cse.psu.edu!9fans-outgoing-owner Sun Nov 5 11:31:47 1995 Received: from psuvax1.cse.psu.edu ([130.203.1.6]) by cannon.ecf.toronto.edu with SMTP id <887>; Sun, 5 Nov 1995 11:31:41 -0500 Received: by psuvax1.cse.psu.edu id <34034>; Sun, 5 Nov 1995 11:05:41 -0500 Received: from plan9.cs.york.ac.uk ([144.32.33.120]) by psuvax1.cse.psu.edu with SMTP id <34027>; Sun, 5 Nov 1995 11:04:33 -0500 From: forsyth@plan9.cs.york.ac.uk To: 9fans@cse.psu.edu Date: Sun, 5 Nov 1995 10:56:36 -0500 subject: change to /sys/src/9/pc/bbmalloc.c Message-Id: <95Nov5.110433est.34027@psuvax1.cse.psu.edu> Sender: owner-9fans@cse.psu.edu Precedence: bulk Reply-To: 9fans@cse.psu.edu Status: RO vortex% diff $home/cd/9/pc/bbmalloc.c . 82c82 < return 0; --- > return u!=0; 88d87 < USED(len, onstack); 89a89,90 > if(!onstack) > bbfree(memstart, len); the key part is the bbfree; the onstack changes simply make use when possible of an array that's allocated on the stack anyhow. mind you, that also helps to avoid the underlying problem. which is: without the bbfree, bbmalloc returns blocks of Progmax bytes from each of two 16k arenas in a strictly circular fashion. the problem arises when a process doing a bitblt is suspended during the bitblt, and another process (or an interrupt, on the pc) also does one or more bitblts before the original bitblt is resumed. i added some counters here and there to find that in practice there were only ever 2 processes active in the bbmalloc arena[0] at any one time, but that was enough, since one of them did enough bitblts (and thus bbmallocs) to cause the 3k allocation to cycle round the arena, eventually overwriting the first process's bitblt code. Weinberl: Well, a little forward. Mrs Fischer: A little? You're in danger of meeting yourself coming back. ``On the Razzle'', Tom Stoppard. on the PC, because mousescreenupdate() enables interrupts during vgaupdate, it's possible for cursor movements to be done using bbmalloc allocations out of arena[0], which explains why messing about with the cursor in a scroll bar was the easiest way to crash the system. From cse.psu.edu!9fans-outgoing-owner Sun Apr 28 15:48:55 1996 Received: from colossus.cse.psu.edu ([130.203.1.2]) by cannon.ecf.toronto.edu with SMTP id <2151>; Sun, 28 Apr 1996 15:48:46 -0400 Received: by colossus.cse.psu.edu id <78362>; Sun, 28 Apr 1996 15:39:14 -0400 Received: from hamnavoe.demon.co.uk ([192.76.32.1]) by colossus.cse.psu.edu with SMTP id <78363>; Sun, 28 Apr 1996 15:38:56 -0400 From: miller@hamnavoe.demon.co.uk To: 9fans@cse.psu.edu Date: Sun, 28 Apr 1996 14:35:57 -0400 Subject: mistake in update to 9/pc/devvga.c Message-Id: <96Apr28.153856edt.78363@colossus.cse.psu.edu> Sender: owner-9fans@cse.psu.edu Precedence: bulk Reply-To: 9fans@cse.psu.edu Status: RO The 16-Feb-96 update 9/pc/824494421.rc introduced a change in devvga.c to allow bitreset() to preallocate screen bitmap space. But there's a small mistake in the code which causes a miscalculation of the amount of space to allocate. A simple correction is given by the following diff (against 9/pc/devvga.c after the application of 824494421.rc): 700,701c700 < for(; (1< gscreen.ldepth = z; -- Richard Miller From paulda@cat.COM Fri Aug 16 16:28:45 EDT 1996 Article: 1758 of comp.os.plan9 Xref: info.ecf comp.os.plan9:1758 Newsgroups: comp.os.plan9 Path: info.ecf!utcsri!newsflash.concordia.ca!newsfeed.pitt.edu!godot.cc.duq.edu!newsgate.duke.edu!news.mathworks.com!news-res.gsl.net!news.gsl.net!usenet.eel.ufl.edu!warwick!niss!bath.ac.uk!ccsis From: paulda@cat.COM (David A. Paul) Subject: Re: booting over network Approved: plan9mod@bath.ac.uk Sender: ccsis@bath.ac.uk (Icarus Sparry) Organization: CATERPILLAR INC. Message-ID: <3210A703.BB9@cat.com> References: <31FBF8AF.2409@cat.com> Date: Wed, 14 Aug 1996 11:51:22 GMT Lines: 22 Status: RO With many thanks to Charles Forsyth, my latest problem is solved. I really think I can play now! Mr. Forsyth recommended updating 9/pc and 9/port directories with the latest boddles AND adding two lines of code to function ataclose() in /sys/src/9/pc/devata.c void ataclose(Chan *c) { ... ... dp =atadrive[DRIVE(c->qid.path)]; if(dp == 0) // these two return; // lines.. ... ... } Now I can boot over the net using 9pcdisk with out an IDE drive on the terminal station. From 9fans@cse.psu.edu Thu Oct 24 15:34:24 EDT 1996 Article: 1883 of comp.os.plan9 Xref: info.ecf comp.os.plan9:1883 Newsgroups: comp.os.plan9 Path: info.ecf!utcsri!newsflash.concordia.ca!news.nstn.ca!ott.istar!istar.net!winternet.com!www.nntp.primenet.com!nntp.primenet.com!news.mathworks.com!usenet.eel.ufl.edu!warwick!niss!bath.ac.uk!ccsis From: forsyth@plan9.CS.york.ac.UK Subject: keyboard map Approved: plan9mod@bath.ac.uk Reply-To: 9fans@cse.psu.edu Sender: ccsis@bath.ac.uk (Icarus Sparry) Organization: Plan 9 mailing list Message-ID: <199609241045.GAA03912@cse.psu.edu> Date: Tue, 24 Sep 1996 10:46:56 GMT Lines: 13 there is a package in ftp://ftp.cs.york.ac.uk/plan9/kbmap.tgz that provides an initial version of small changes to /sys/src/9/pc/kbd.c and a new /sys/src/9/port/devkbmap.c to allow the keyboard maps to be set for non US keyboards. there are instructions in the README in the package. contents: term% pub/gzip -f -d Date: Mon, 7 Oct 1996 13:48:07 GMT Lines: 81 You're right and I'd forgotten about that fix in the current driver we have, the 590 and 595 (and the eisa variants whose numbers I've forgotten) require the thresholds to be in longwords. You can decide whether the shift is necessary at the end of the reset routine by either just requiring it if a pci card is detected or by the following, courtesy of Tom Killian (tom@research.att.com) COMMAND(port, SetTxAvailable, 1800); COMMAND(port, SelectWindow, 5); i = ins(port+0x02); COMMAND(port, SelectWindow, 1); switch(i){ case 1800: ctlr->card.txashift = 0; break; case 7200: ctlr->card.txashift = 1; print("ether509: SetTxAvailable shifted\n"); break; default: panic("ether509: SetTxAvailable %d", i); break; } along with adding an element to the Card structure in ether.h uchar txashift; and using the variable when setting the threshold in the transmit routine if(ctlr->card.txashift) COMMAND(port, SetTxAvailable, len/4); else COMMAND(port, SetTxAvailable, len); ------ forwarded message follows ------ >From cse.psu.edu!owner-9fans Mon Oct 7 09:22:31 EDT 1996 Received: from cse.psu.edu by plan9; Mon Oct 7 09:22:31 EDT 1996 Received: from localhost (majordom@localhost) by cse.psu.edu (8.7.5/8.7.3) with SMTP id IAA15122; Mon, 7 Oct 1996 08:59:58 -0400 (EDT) Received: by claven.cse.psu.edu (bulk_mailer v1.5); Mon, 7 Oct 1996 08:58:41 -0400 Received: (from majordom@localhost) by cse.psu.edu (8.7.5/8.7.3) id IAA15085 for 9fans-outgoing; Mon, 7 Oct 1996 08:58:34 -0400 (EDT) X-Authentication-Warning: claven.cse.psu.edu: majordom set sender to owner-9fans using -f Received: from hamnavoe.demon.co.uk (miller@hamnavoe.demon.co.uk [158.152.225.204]) by cse.psu.edu (8.7.5/8.7.3) with SMTP id IAA15081 for <9fans@cse.psu.edu>; Mon, 7 Oct 1996 08:58:22 -0400 (EDT) From: hamnavoe.demon.co.uk!miller Message-Id: <199610071258.IAA15081@cse.psu.edu> To: cse.psu.edu!9fans Date: Mon, 7 Oct 1996 13:52:26 GMT Subject: Re: Installing & IP Sender: cse.psu.edu!owner-9fans Reply-To: cse.psu.edu!9fans Precedence: bulk Jim McKie says: > ... the 3C590 is a 10Mbps card only and should work I found problems with the 3C590: particularly under the IL protocol, transmission was very slow and often hung up completely. Some investigation showed that the TxAvailable interrupt (which signals that the adapter's transmit FIFO has space for the next packet) wasn't being received. (Presumably only the IL protocol is efficient enough to overrun the adapter's transmission speed and allow the FIFO to fill up ...) I believe the problem is that the TxAvailable threshold needs to be set in units of longwords rather than bytes (could someone with access to hardware documentation for the 3C590 please confirm this?). If this is right, in ether509.c the line COMMAND(port, SetTxAvailable, len); ought to be COMMAND(port, SetTxAvailable, len>>2); After this change on my system, TxAvailable interrupts occur as expected and IL transmission runs without a problem. -- Richard Miller