>From owner-9fans Mon Dec 1 23:08:10 1997 Received: (from majordom@localhost) by cse.psu.edu (8.8.7/8.7.3) id XAA18239 for 9fans-outgoing; Mon, 1 Dec 1997 23:08:09 -0500 (EST) X-Authentication-Warning: claven.cse.psu.edu: majordom set sender to owner-9fans using -f Received: from plan9.aichi-u.ac.jp (plan9.aichi-u.ac.jp [202.250.160.122]) by cse.psu.edu (8.8.7/8.7.3) with SMTP id XAA18232 for <9fans@cse.psu.edu>; Mon, 1 Dec 1997 23:08:03 -0500 (EST) From: arisawa@plan9.aichi-u.ac.jp Message-Id: <199712020408.XAA18232@cse.psu.edu> To: 9fans@cse.psu.edu Date: Tue, 2 Dec 1997 13:09:11 +0900 Subject: [9fans] Re: Updated mothra don't show images. Sender: owner-9fans@cse.psu.edu Precedence: bulk Reply-To: 9fans Hello 9fans! I said: > Mothra shows an error message "error in picopen_r" when it accesses > image file. David Hogan say: >You'll have to install the boddles for libfb and fb to make >this work. Be sure to install the new colo(u)r map files, >or you may get stung by the ``black screen of death''... This comment was a great help to me. My problem was in fact due to /lib/cmap. Thank you! Kenji Arisawa E-mail: arisawa@aichi-u.ac.jp >From owner-9fans Tue Dec 2 03:34:45 1997 Received: (from majordom@localhost) by cse.psu.edu (8.8.7/8.7.3) id DAA21413 for 9fans-outgoing; Tue, 2 Dec 1997 03:34:45 -0500 (EST) X-Authentication-Warning: claven.cse.psu.edu: majordom set sender to owner-9fans using -f Received: from symbionics.co.uk (symsun3.symbionics.co.uk [194.32.100.60]) by cse.psu.edu (8.8.7/8.7.3) with SMTP id DAA21409 for <9fans@cse.psu.edu>; Tue, 2 Dec 1997 03:34:40 -0500 (EST) Received: from symnt3.symbionics.co.uk by symbionics.co.uk (4.1/SMI-4.1) id AA21852; Tue, 2 Dec 97 08:34:09 GMT Received: by symnt3.symbionics.co.uk with SMTP (Microsoft Exchange Server Internet Mail Connector Version 4.0.995.52) id <01BCFEFD.0DF7DCE0@symnt3.symbionics.co.uk>; Tue, 2 Dec 1997 08:34:07 -0000 Message-Id: From: Nigel Roles To: "'9fans@cse.psu.edu'" <9fans@cse.psu.edu> Subject: [9fans] Irony Date: Tue, 2 Dec 1997 08:34:05 -0000 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.995.52 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-9fans@cse.psu.edu Precedence: bulk Reply-To: 9fans I recently swapped my P133 256K COAST motherboard (i.e. what everyone was buying this time last year) for a shiny new 440LX + P-II MMX 233 motherboard (i.e. what everyone was buying last month). What happened? Windows 95 took one look at all these new PCI chips and went into a dead faint. When I bemoaned this at work and commented "what do we have BIOSes for if they don't set up the chips and present a consistent behaviour to the OS", I was told by the Microsoft acolytes here that I shouldn't expect an OS to support all future hardware. OK - perhaps. By dint of various nasty contortions I installed the latest version which, while being entirely happy playing with the new chips, rendered my Diamond Stealth 64 VRAM incapable of operating out of VGA mode. Plan 9 as to be expected, works fine, including the S3 driver. I'm down to compiling the kernel (served through the ether) in 70 seconds. So, in summary, I have to buy a new video card to support Windows 95. This seems to be a bit of an inversion on the "why doesn't Plan 9 support my '4D semtex disambiguator IV PCI' game playing card" questions we get in this list! Anyone know where I can buy a Virge-VX 4mb video card to support legacy operating systems? >From owner-9fans Tue Dec 2 04:34:03 1997 Received: (from majordom@localhost) by cse.psu.edu (8.8.7/8.7.3) id EAA21789 for 9fans-outgoing; Tue, 2 Dec 1997 04:34:03 -0500 (EST) X-Authentication-Warning: claven.cse.psu.edu: majordom set sender to owner-9fans using -f Received: from totenkopf.france3.fr ([195.171.62.2]) by cse.psu.edu (8.8.7/8.7.3) with ESMTP id EAA21785 for <9fans@cse.psu.edu>; Tue, 2 Dec 1997 04:33:35 -0500 (EST) Received: from shlakensaft.mdrf.france3.fr (boyd@shlakensaft.mdrf.france3.fr [10.175.0.11]) by totenkopf.france3.fr (8.8.7/8.8.5) with ESMTP id KAA29768 for <9fans@cse.psu.edu>; Tue, 2 Dec 1997 10:31:35 +0100 Received: from system.mdrf.france3.fr (system.mdrf.france3.fr [10.175.0.53]) by shlakensaft.mdrf.france3.fr (8.8.5/8.8.5) id KAA26445; Tue, 2 Dec 1997 10:43:32 +0100 From: Boyd Roberts Date: Tue, 2 Dec 1997 10:30:56 +0100 To: 9fans@cse.psu.edu Subject: Re: [9fans] Irony In-Reply-To: Message-ID: <199712021030.18734.9.bayip@france3.fr> X-UTM: N 31 447109 5411310 La Maison de Radio France, France 3, Direction Informatique, Systemes & Reseaux X-Face: #"03$i1:"_[Hbg~GCPw}`+d4_R`}RaDfYixB`n-mCB0E8m#tNd>uyd[d)`nEix7Bys(:o#o2y7$(=,&BTXdH7)Hm5jP}H5:y]}0GT4?uTT(Y0(Cu7tWBXj\|q\@jZ8 Y_qn8)NV0*$uO][i7p"K2>Kg( Sender: owner-9fans@cse.psu.edu Precedence: bulk Reply-To: 9fans From: Nigel Roles So, in summary, I have to buy a new video card to support Windows 95. just think how many droids they must have employed to get it to work on that plethora of dingbat hardware. on the other hand, they would have probably paid microsoft for such an honour. >From owner-9fans Thu Dec 4 04:19:27 1997 Received: (from majordom@localhost) by cse.psu.edu (8.8.7/8.7.3) id EAA26529 for 9fans-outgoing; Thu, 4 Dec 1997 04:19:26 -0500 (EST) X-Authentication-Warning: claven.cse.psu.edu: majordom set sender to owner-9fans using -f Received: from plan9.aichi-u.ac.jp (plan9.aichi-u.ac.jp [202.250.160.122]) by cse.psu.edu (8.8.7/8.7.3) with SMTP id EAA26524 for <9fans@cse.psu.edu>; Thu, 4 Dec 1997 04:19:20 -0500 (EST) From: arisawa@plan9.aichi-u.ac.jp Message-Id: <199712040919.EAA26524@cse.psu.edu> To: 9fans@cse.psu.edu Date: Thu, 4 Dec 1997 18:21:17 +0900 Subject: [9fans] A patch for boddle Sender: owner-9fans@cse.psu.edu Precedence: bulk Reply-To: 9fans Hello 9fans! This is a patch for boddle. Original boddle fails to modify for write-protected source file. We should execute chmod in prior to enter ed. Old code: echo 'cp $srcdir/'$1 $target echo 'ed' $target '>/dev/null >[2=1] <<''//GO.SYSIN DD VADIM '$1'''' New code: echo 'cp $srcdir/'$1 $target echo 'chmod +w' $target echo 'ed' $target '>/dev/null >[2=1] <<''//GO.SYSIN DD VADIM '$1'''' Kenji Arisawa E-mail: arisawa@aichi-u.ac.jp >From owner-9fans Thu Dec 4 20:56:44 1997 Received: (from majordom@localhost) by cse.psu.edu (8.8.7/8.7.3) id UAA21885 for 9fans-outgoing; Thu, 4 Dec 1997 20:56:43 -0500 (EST) X-Authentication-Warning: claven.cse.psu.edu: majordom set sender to owner-9fans using -f Received: from vega.aichi-u.ac.jp ([202.250.160.119]) by cse.psu.edu (8.8.7/8.7.3) with SMTP id UAA21880 for <9fans@cse.psu.edu>; Thu, 4 Dec 1997 20:56:34 -0500 (EST) From: arisawa@vega.aichi-u.ac.jp Message-Id: <199712050156.UAA21880@cse.psu.edu> To: 9fans@cse.psu.edu Date: Fri, 5 Dec 1997 10:57:52 +0900 Subject: [9fans] A patch for ftp Sender: owner-9fans@cse.psu.edu Precedence: bulk Reply-To: 9fans Hello 9fans This is a patch to /sys/src/cmd/service/ftp.c The patch includes: 1. bug fix to: tcp!port messgae This problem is already spoken elsewhere. 2. bug fix to: ls -l I announced previously. 3. support size command New patch 4. put "/" after directory names New patch Change the source to work it: term% diff ftp.c.orig ftp.c 62a63 > int sizecmd(char*); 102a104 > { "size", sizecmd, }, 673c675 < sprint(buf, "tcp!%d", port); --- > sprint(buf, "tcp!*!%d", port); 753c755,756 < n += sprint(buf+n, "%s", name); --- > if(d->mode & CHDIR) n += sprint(buf+n, "%s/", name); > else n += sprint(buf+n, "%s", name); 898,899c901,902 < if(Cflag) < lflag = 0; --- > if(lflag) > Cflag = 0; 1532a1536,1545 > } > > int > sizecmd(char *file) > { Dir edir; > if(stat(file,(char*)&edir)) > return reply("550 %s: No such file or directory.",file); > if(edir.mode & CHDIR) /* directory */ > return reply("550 %s: not a plain file.",file); > return reply("213 %lld",edir.vlength); You can get this boddle from: ftp://plan9.aichi-u.ac.jp/netlib/patchs/ftp.bod Kenji Arisawa E-mail: arisawa@aichi-u.ac.jp >From owner-9fans Fri Dec 5 00:10:06 1997 Received: (from majordom@localhost) by cse.psu.edu (8.8.7/8.7.3) id AAA26558 for 9fans-outgoing; Fri, 5 Dec 1997 00:10:05 -0500 (EST) X-Authentication-Warning: claven.cse.psu.edu: majordom set sender to owner-9fans using -f Received: from vega.aichi-u.ac.jp ([202.250.160.119]) by cse.psu.edu (8.8.7/8.7.3) with SMTP id AAA26530 for <9fans@cse.psu.edu>; Fri, 5 Dec 1997 00:09:04 -0500 (EST) From: arisawa@vega.aichi-u.ac.jp Message-Id: <199712050509.AAA26530@cse.psu.edu> To: 9fans@cse.psu.edu Date: Fri, 5 Dec 1997 14:11:15 +0900 Subject: [9fans] Re: A patch for ftp.c Sender: owner-9fans@cse.psu.edu Precedence: bulk Reply-To: 9fans Hello 9fans. Although I have posted a patch for ftp.c : >The patch includes: >1. bug fix to: > tcp!port messgae > This problem is already spoken elsewhere. >2. bug fix to: > ls -l > I announced previously. >3. support size command >4. put "/" after directory names there is some problems in 4. (inconsistency with ftpfs from plan9) Please discard the patch. I will post another patch for ftp.c. Sorry... Kenji Arisawa E-mail: arisawa@aichi-u.ac.jp >From owner-9fans Fri Dec 5 13:57:31 1997 Received: (from majordom@localhost) by cse.psu.edu (8.8.7/8.7.3) id NAA09764 for 9fans-outgoing; Fri, 5 Dec 1997 13:57:31 -0500 (EST) X-Authentication-Warning: claven.cse.psu.edu: majordom set sender to owner-9fans using -f Received: from mtigwc03.worldnet.att.net (mtigwc03.worldnet.att.net [204.127.131.34]) by cse.psu.edu (8.8.7/8.7.3) with ESMTP id NAA09759 for <9fans@cse.psu.edu>; Fri, 5 Dec 1997 13:57:24 -0500 (EST) Received: from LOCALNAME ([12.68.163.252]) by mtigwc03.worldnet.att.net (post.office MTA v2.0 0613 ) with SMTP id AAA12609 for <9fans@cse.psu.edu>; Fri, 5 Dec 1997 18:56:51 +0000 X-Sender: west9@postoffice.worldnet.att.net X-Mailer: Windows Eudora Light Version 1.5.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 05 Dec 1997 14:45:26 +0000 To: 9fans@cse.psu.edu From: Thomas West Subject: [9fans] Installation,Step 3b Message-ID: <19971205185647.AAA12609@LOCALNAME> Sender: owner-9fans@cse.psu.edu Precedence: bulk Reply-To: 9fans After the file server comes up, but before the authentication server is created I understand: 1. "none" is the only user the file server will recognize 2. An indy r4400 cannot be booted from the file server using bootp because bootp functionality resides only in the auth server. In the statement in 'Documents' saying r 4000 (how about r4400?) is supported as a terminal, 'supported' means with the aid of two other machines, a file server and an cpu&authentication server. Comments/suggestions on these understandings much appreciated Tom west >From owner-9fans Sat Dec 6 01:36:39 1997 Received: (from majordom@localhost) by cse.psu.edu (8.8.7/8.7.3) id BAA23815 for 9fans-outgoing; Sat, 6 Dec 1997 01:36:38 -0500 (EST) X-Authentication-Warning: claven.cse.psu.edu: majordom set sender to owner-9fans using -f Received: from vega2.aichi-u.ac.jp (vega2.aichi-u.ac.jp [202.16.124.7]) by cse.psu.edu (8.8.7/8.7.3) with SMTP id BAA23811 for <9fans@cse.psu.edu>; Sat, 6 Dec 1997 01:36:29 -0500 (EST) Received: by vega2.aichi-u.ac.jp (8.6.9+2.4W/3.3Wb) id PAA08374; Sat, 6 Dec 1997 15:27:19 +0900 Date: Sat, 6 Dec 1997 15:27:19 +0900 From: Kenji Arisawa Message-Id: <199712060627.PAA08374@vega2.aichi-u.ac.jp> To: 9fans@cse.psu.edu Subject: [9fans] Re: Plan 9 from Bell Labs - Frequently Asked Sender: owner-9fans@cse.psu.edu Precedence: bulk Reply-To: 9fans Hello 9fans! FAQ says in comp.os.plan9: >Ethernet Adapters > 3Com 3C509, 3C509B are recommended. The EISA 3C579 works, but > isn't worth the extra cost. The PCMCIA 3C589, PCI 3C590 and PCI >! 3C595 (fast ethernet) also work. AMD 79C970 based adapters seem to > work fine. SMC (WD) series up to the Elite (and the Elite Ultra), > some NE2000 compatibles (including an NE4100 PCMCIA card) and one > Eagle NE3210 EISA card. The 3Com 3C503 does not work at all under >! load. The 3Com 3C595 is not supported. Does 3C595 work or not? According to 3COME Home Page the Fast EtherLink that 3COM currentlly sails are: PCI: 3C905-TX, 3C905-T4 EISA: 3C597-TX ISA: 3C515-TX Misprint is not ? Kenji Arisawa E-mail: arisawa@aichi-u.ac.jp >From owner-9fans Sat Dec 6 09:23:54 1997 Received: (from majordom@localhost) by cse.psu.edu (8.8.7/8.7.3) id JAA26639 for 9fans-outgoing; Sat, 6 Dec 1997 09:23:54 -0500 (EST) X-Authentication-Warning: claven.cse.psu.edu: majordom set sender to owner-9fans using -f Received: from caldo.demon.co.uk (none@caldo.demon.co.uk [194.222.207.148]) by cse.psu.edu (8.8.7/8.7.3) with SMTP id JAA26635 for <9fans@cse.psu.edu>; Sat, 6 Dec 1997 09:23:46 -0500 (EST) From: forsyth@caldo.demon.co.uk Message-Id: <199712061423.JAA26635@cse.psu.edu> To: 9fans@cse.psu.edu Date: Sat, 6 Dec 1997 12:59:27 GMT Subject: Re: [9fans] Installation,Step 3b Sender: owner-9fans@cse.psu.edu Precedence: bulk Reply-To: 9fans >> 2. An indy r4400 cannot be booted from the file server using bootp because >>bootp functionality resides only in the auth server. Indys aren't supported by the CD in any form, only the older Indigo R3k and R4k (most models). someone significant wrt the Indy at SGI agreed to get the information to me (legitimately) so i could do a cpu/terminal kernel port, but he was moved within the company, and his successors were unhelpful. steve kotsopoulis has made some changes (in boddle form somewhere) to allow some model of Indy with secondary cache to work as a CPU server, based on the /sys/src/9/chm (challenge M) kernel. i made a few more changes to get my R4600 Indy (no secondary cache) to work, and i use it as a cpu server. i also looked at reverse engineering the operation of the Indy graphics chip, to complete a usable terminal port, but had other things to do. it didn't look very hard to do basic support along the lines of /sys/src/9/indigo4k, provided there weren't any hidden bits to twiddle to enable things. on the other hand, i thought i might not be able to get the Indy audio and video subsystems going and those were the ones that most interested me at the time. eventually it was easier to switch to the Intel architecture -- ugly, certainly clunkier, and with a stupid processor architecture -- but where at least some of the companies publish data books or data sheets some of the time. one still runs up against register-level secrecy on the PC platform for some cards, but there is usually at least one usable card for which programming data is available. >From owner-9fans Sat Dec 6 09:30:19 1997 Received: (from majordom@localhost) by cse.psu.edu (8.8.7/8.7.3) id JAA26909 for 9fans-outgoing; Sat, 6 Dec 1997 09:30:19 -0500 (EST) X-Authentication-Warning: claven.cse.psu.edu: majordom set sender to owner-9fans using -f Received: from caldo.demon.co.uk (none@caldo.demon.co.uk [194.222.207.148]) by cse.psu.edu (8.8.7/8.7.3) with SMTP id JAA26905 for <9fans@cse.psu.edu>; Sat, 6 Dec 1997 09:30:09 -0500 (EST) From: forsyth@caldo.demon.co.uk Message-Id: <199712061430.JAA26905@cse.psu.edu> To: 9fans@cse.psu.edu Date: Sat, 6 Dec 1997 13:06:15 GMT Subject: Re: [9fans] Installation,Step 3b Sender: owner-9fans@cse.psu.edu Precedence: bulk Reply-To: 9fans >> 1. "none" is the only user the file server will recognize `users default' adds a few more users, and in `allow' mode you can attach from a terminal without an auth server and set things up as you like. >>bootp functionality resides only in the auth server. any machine can run it, although it's normally run by a cpu server. that needn't be an auth server as well, but probably would be for small installations. at home, i boot my Indigo cpu/auth server from its local disc, using /sys/src/boot/indigo; at work, i boot an Indy cpu server using the Indy's normal boot support, from a file /9indycpu on the Indy's EFS root partition. they prompt for the IP data. both machines then run the bootp and tftp services to boot my (our) PC terminals. >From owner-9fans Sat Dec 6 09:34:20 1997 Received: (from majordom@localhost) by cse.psu.edu (8.8.7/8.7.3) id JAA27157 for 9fans-outgoing; Sat, 6 Dec 1997 09:34:20 -0500 (EST) X-Authentication-Warning: claven.cse.psu.edu: majordom set sender to owner-9fans using -f Received: from tor.securecomputing.com (tor.securecomputing.com [199.71.190.98]) by cse.psu.edu (8.8.7/8.7.3) with ESMTP id JAA27150 for <9fans@cse.psu.edu>; Sat, 6 Dec 1997 09:34:15 -0500 (EST) Received: by janus.tor.securecomputing.com id <11649>; Sat, 6 Dec 1997 09:34:23 -0500 Message-Id: <97Dec6.093423est.11649@janus.tor.securecomputing.com> To: 9fans@cse.psu.edu Subject: Re: [9fans] Installation,Step 3b In-reply-to: Your message of "Sat, 06 Dec 1997 07:59:27 EST." <199712061423.JAA26635@cse.psu.edu> Date: Sat, 6 Dec 1997 09:34:00 -0500 From: Steve Kotsopoulos Sender: owner-9fans@cse.psu.edu Precedence: bulk Reply-To: 9fans The boddle is at ftp://ftp.ecf.toronto.edu/pub/plan9/steve/indy.bod It works on the SGI Indy R4000 SC. forsyth@caldo.demon.co.uk wrote: > steve kotsopoulos has made some changes (in boddle form somewhere) > to allow some model of Indy with secondary cache > to work as a CPU server, based on the /sys/src/9/chm > (challenge M) kernel. i made a few more changes to get my > R4600 Indy (no secondary cache) to work, and i use it as a cpu server. >From owner-9fans Sat Dec 6 12:04:39 1997 Received: (from majordom@localhost) by cse.psu.edu (8.8.7/8.7.3) id MAA28732 for 9fans-outgoing; Sat, 6 Dec 1997 12:04:39 -0500 (EST) X-Authentication-Warning: claven.cse.psu.edu: majordom set sender to owner-9fans using -f Received: from plan9.bell-labs.com (plan9.bell-labs.com [204.178.31.2]) by cse.psu.edu (8.8.7/8.7.3) with SMTP id MAA28728 for <9fans@cse.psu.edu>; Sat, 6 Dec 1997 12:04:35 -0500 (EST) Message-Id: <199712061704.MAA28728@cse.psu.edu> To: 9fans@cse.psu.edu Date: Sat, 6 Dec 1997 11:58:31 -0500 From: "jim mckie" Subject: re: [9fans] Re: Plan 9 from Bell Labs - Frequently Asked Sender: owner-9fans@cse.psu.edu Precedence: bulk Reply-To: 9fans > Does 3C595 work or not? the 3c595 works if all the updates are applied. of course, it's an old and discontinued card, replaced by the 3c905. however, you should be able to find one without too much difficulty. the 3c905 is a full busmastering card and has some backwards compatibility with the older 3c5xx series, e.g. it will boot with the current drivers, but the performance is abysmal because it's really designed to be used as a busmaster. i have a driver but the there are problems under load which i can't seem to resolve and i can't get the problems to happen in a test environment. --jim >From owner-9fans Mon Dec 8 12:02:10 1997 Received: (from majordom@localhost) by cse.psu.edu (8.8.7/8.7.3) id MAA06894 for 9fans-outgoing; Mon, 8 Dec 1997 12:02:09 -0500 (EST) X-Authentication-Warning: claven.cse.psu.edu: majordom set sender to owner-9fans using -f Received: from ns.dbSystems.com (root@ns.dbsystems.com [204.178.76.1]) by cse.psu.edu (8.8.7/8.7.3) with SMTP id MAA06886 for <9fans@cse.psu.edu>; Mon, 8 Dec 1997 12:02:03 -0500 (EST) Received: (from gdb@localhost) by ns.dbSystems.com (8.6.11/8.6.9) id KAA01992 for 9fans@cse.psu.edu; Mon, 8 Dec 1997 10:48:19 -0600 Date: Mon, 8 Dec 1997 10:48:19 -0600 From: "G. David Butler" Message-Id: <199712081648.KAA01992@ns.dbSystems.com> To: 9fans@cse.psu.edu Subject: Re: [9fans] Re: Plan 9 from Bell Labs - Frequently Asked Sender: owner-9fans@cse.psu.edu Precedence: bulk Reply-To: 9fans It is interesting that you bring this up... >Hello 9fans! > >FAQ says in comp.os.plan9: >>Ethernet Adapters >> 3Com 3C509, 3C509B are recommended. The EISA 3C579 works, but >> isn't worth the extra cost. The PCMCIA 3C589, PCI 3C590 and PCI >>! 3C595 (fast ethernet) also work. AMD 79C970 based adapters seem to >> work fine. SMC (WD) series up to the Elite (and the Elite Ultra), >> some NE2000 compatibles (including an NE4100 PCMCIA card) and one >> Eagle NE3210 EISA card. The 3Com 3C503 does not work at all under >>! load. The 3Com 3C595 is not supported. >Does 3C595 work or not? > >According to 3COME Home Page >the Fast EtherLink that 3COM currentlly sails are: >PCI: 3C905-TX, 3C905-T4 >EISA: 3C597-TX >ISA: 3C515-TX I have a 3c509, 3c579, 3c597 and 3c905. The ISA card works, except under heavy receive load with an adaptec 1542 bus-master the small receive FIFO will drive you crazy! But the 32bit cards don't work worth a sh*t! After spending too much time going through Plan9 and Net/FreeBSD source I have determined these cards go into stupid mode on transmit when presented with bursts of receive data. In other words, if you rip a lot of data off the card or force a lot into the card, it works great. But just try a single compile session, which does full 8k reads and writes, and the cards go stupid. A cp of a ~large file in a directory will do it to. They will not accept any more data into the transmit FIFO, will not transmit what is in the FIFO and will not give you a TxAvail interrupt when the FIFO finally does drain! I don't have any documentation to the cards, so I'm in the dark. Any body want to help? David Butler gdb@dbSystems.com >From owner-9fans Mon Dec 8 13:09:00 1997 Received: (from majordom@localhost) by cse.psu.edu (8.8.7/8.7.3) id NAA08286 for 9fans-outgoing; Mon, 8 Dec 1997 13:09:00 -0500 (EST) X-Authentication-Warning: claven.cse.psu.edu: majordom set sender to owner-9fans using -f Received: from plan9.bell-labs.com (plan9.bell-labs.com [204.178.31.2]) by cse.psu.edu (8.8.7/8.7.3) with SMTP id NAA08280 for <9fans@cse.psu.edu>; Mon, 8 Dec 1997 13:08:55 -0500 (EST) Message-Id: <199712081808.NAA08280@cse.psu.edu> To: 9fans@cse.psu.edu Date: Mon, 8 Dec 1997 13:08:42 -0500 From: "jim mckie" Subject: Re: [9fans] Re: Plan 9 from Bell Labs - Frequently Asked Sender: owner-9fans@cse.psu.edu Precedence: bulk Reply-To: 9fans >It is interesting that you bring this up... > >>Hello 9fans! >> >>FAQ says in comp.os.plan9: >>>Ethernet Adapters >>> 3Com 3C509, 3C509B are recommended. The EISA 3C579 works, but >>> isn't worth the extra cost. The PCMCIA 3C589, PCI 3C590 and PCI >>>! 3C595 (fast ethernet) also work. AMD 79C970 based adapters seem to >>> work fine. SMC (WD) series up to the Elite (and the Elite Ultra), >>> some NE2000 compatibles (including an NE4100 PCMCIA card) and one >>> Eagle NE3210 EISA card. The 3Com 3C503 does not work at all under >>>! load. The 3Com 3C595 is not supported. >>Does 3C595 work or not? >> >>According to 3COME Home Page >>the Fast EtherLink that 3COM currentlly sails are: >>PCI: 3C905-TX, 3C905-T4 >>EISA: 3C597-TX >>ISA: 3C515-TX > >I have a 3c509, 3c579, 3c597 and 3c905. The ISA card works, except >under heavy receive load with an adaptec 1542 bus-master the small >receive FIFO will drive you crazy! > >But the 32bit cards don't work worth a sh*t! After spending too >much time going through Plan9 and Net/FreeBSD source I have determined >these cards go into stupid mode on transmit when presented with >bursts of receive data. In other words, if you rip a lot of data >off the card or force a lot into the card, it works great. But just >try a single compile session, which does full 8k reads and writes, >and the cards go stupid. A cp of a ~large file in a directory will >do it to. > >They will not accept any more data into the transmit FIFO, will not >transmit what is in the FIFO and will not give you a TxAvail interrupt >when the FIFO finally does drain! > >I don't have any documentation to the cards, so I'm in the dark. >Any body want to help? > >David Butler >gdb@dbSystems.com which of the above cards are you classifying as 32-bit? the 579 and 597 are 32-bit (eisa). we have 579s and they work fine. the 597 probably won't work without dealing with various chip errata. the 905 is problematic: although it has compatibility with the older cards the fifos are tiny and the card really has to be run in busmastering mode or it gums up a lot (it works well enough in fifo mode to boot a kernel with b.com though). in busmastering mode there are chip errata which have to be dealt with or it can hang up too. as i mentioned in a previous message i still have problems with the 905 so i'm interested in any other experiences with it. --jim >From owner-9fans Mon Dec 8 17:23:05 1997 Received: (from majordom@localhost) by cse.psu.edu (8.8.7/8.7.3) id RAA15733 for 9fans-outgoing; Mon, 8 Dec 1997 17:23:05 -0500 (EST) X-Authentication-Warning: claven.cse.psu.edu: majordom set sender to owner-9fans using -f Received: from caldo.demon.co.uk (none@caldo.demon.co.uk [194.222.207.148]) by cse.psu.edu (8.8.7/8.7.3) with SMTP id RAA15718 for <9fans@cse.psu.edu>; Mon, 8 Dec 1997 17:22:59 -0500 (EST) From: forsyth@caldo.demon.co.uk Message-Id: <199712082222.RAA15718@cse.psu.edu> To: 9fans@cse.psu.edu Date: Mon, 8 Dec 1997 21:02:04 GMT Subject: Re: [9fans] Re: Plan 9 from Bell Labs - Frequently Asked Sender: owner-9fans@cse.psu.edu Precedence: bulk Reply-To: 9fans oh. when i said that my 3com XL `works fine', i forgot to add that it's in dull, antique 10m/bit mode, not 100 m/bit mode (we've only just got the 100m/bit equipment, and i'm not yet connected to it). i won't even think about g/bit. >From owner-9fans Mon Dec 8 19:38:01 1997 Received: (from majordom@localhost) by cse.psu.edu (8.8.7/8.7.3) id TAA18911 for 9fans-outgoing; Mon, 8 Dec 1997 19:38:00 -0500 (EST) X-Authentication-Warning: claven.cse.psu.edu: majordom set sender to owner-9fans using -f Received: from caldo.demon.co.uk (none@caldo.demon.co.uk [194.222.207.148]) by cse.psu.edu (8.8.7/8.7.3) with SMTP id TAA18907 for <9fans@cs.psu.edu>; Mon, 8 Dec 1997 19:37:55 -0500 (EST) From: forsyth@caldo.demon.co.uk Message-Id: <199712090037.TAA18907@cse.psu.edu> To: 9fans@cse.psu.edu Date: Mon, 8 Dec 1997 20:57:18 GMT Subject: Re: [9fans] Re: Plan 9 from Bell Labs - Frequently Asked Sender: owner-9fans@cse.psu.edu Precedence: bulk Reply-To: 9fans i've been using a 3com XL quite happily for months now. it will hang up if you haven't got the txashift change posted here some time ago. the newer card has got a bigger fifo, and the representation of the TxAvailable value differs (it's in words, not bytes, or some such thing). b.com needs a similar change. i wasn't sure whether the plan9.bell-labs.com updates had the change, but i thought they had. i haven't had a chance to fetch the boddles to check. i've a feeling that the kernel's driver has got the change but b.com's hasn't. >From owner-9fans Mon Dec 8 20:12:22 1997 Received: (from majordom@localhost) by cse.psu.edu (8.8.7/8.7.3) id UAA20156 for 9fans-outgoing; Mon, 8 Dec 1997 20:12:22 -0500 (EST) X-Authentication-Warning: claven.cse.psu.edu: majordom set sender to owner-9fans using -f Received: from caldo.demon.co.uk (none@caldo.demon.co.uk [194.222.207.148]) by cse.psu.edu (8.8.7/8.7.3) with SMTP id UAA20152 for <9fans@cse.psu.edu>; Mon, 8 Dec 1997 20:12:17 -0500 (EST) From: forsyth@caldo.demon.co.uk Message-Id: <199712090112.UAA20152@cse.psu.edu> To: 9fans@cse.psu.edu Date: Mon, 8 Dec 1997 23:51:25 GMT Subject: Re: [9fans] Re: Plan 9 from Bell Labs - Frequently Asked Sender: owner-9fans@cse.psu.edu Precedence: bulk Reply-To: 9fans >>to fetch the boddles to check. i've a feeling that the kernel's >>driver has got the change but b.com's hasn't. unless i picked the wrong boddles, neither ether509 driver has got the txashift change. >From owner-9fans Mon Dec 8 20:14:59 1997 Received: (from majordom@localhost) by cse.psu.edu (8.8.7/8.7.3) id UAA20353 for 9fans-outgoing; Mon, 8 Dec 1997 20:14:58 -0500 (EST) X-Authentication-Warning: claven.cse.psu.edu: majordom set sender to owner-9fans using -f Received: from caldo.demon.co.uk (none@caldo.demon.co.uk [194.222.207.148]) by cse.psu.edu (8.8.7/8.7.3) with SMTP id UAA20341 for <9fans@cs.psu.edu>; Mon, 8 Dec 1997 20:14:46 -0500 (EST) From: forsyth@caldo.demon.co.uk Message-Id: <199712090114.UAA20341@cse.psu.edu> To: 9fans@cse.psu.edu Date: Mon, 8 Dec 1997 23:54:01 GMT Subject: [9fans] re: 3c509 driver and XL Sender: owner-9fans@cse.psu.edu Precedence: bulk Reply-To: 9fans here's the conversation from one year ago ... >From cse.psu.edu!owner-9fans Mon Oct 7 14:55:39 BST 1996 From: jmk@plan9.bell-labs.com To: 9fans@cse.psu.edu Subject: Re: Installing & IP Sender: owner-9fans@cse.psu.edu Reply-To: 9fans@cse.psu.edu Precedence: bulk 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 >From owner-9fans Wed Dec 10 12:04:54 1997 Received: (from majordom@localhost) by cse.psu.edu (8.8.7/8.7.3) id MAA28977 for 9fans-outgoing; Wed, 10 Dec 1997 12:04:53 -0500 (EST) X-Authentication-Warning: claven.cse.psu.edu: majordom set sender to owner-9fans using -f Received: from ns.dbSystems.com (root@ns.dbsystems.com [204.178.76.1]) by cse.psu.edu (8.8.7/8.7.3) with SMTP id MAA28973 for <9fans@cse.psu.edu>; Wed, 10 Dec 1997 12:04:42 -0500 (EST) Received: (from gdb@localhost) by ns.dbSystems.com (8.6.11/8.6.9) id KAA06015 for 9fans@cse.psu.edu; Wed, 10 Dec 1997 10:50:48 -0600 Date: Wed, 10 Dec 1997 10:50:48 -0600 From: "G. David Butler" Message-Id: <199712101650.KAA06015@ns.dbSystems.com> To: 9fans@cse.psu.edu Subject: Re: [9fans] Re: Plan 9 from Bell Labs - Frequently Asked Sender: owner-9fans@cse.psu.edu Precedence: bulk Reply-To: 9fans >which of the above cards are you classifying as 32-bit? >the 579 and 597 are 32-bit (eisa). we have 579s and they work fine. >the 597 probably won't work without dealing with various chip errata. I didn't have the piece of information that "Large packet support affects bit-field widths in the following registers: RxStatus, MasterStatus, TxStartThresh, TxAvailableThresh and RxEarlyThresh". My 579s now work fine, too. >the 905 is problematic: although it has compatibility with the older >cards the fifos are tiny and the card really has to be run in >busmastering mode or it gums up a lot (it works well enough in fifo >mode to boot a kernel with b.com though). Mine seems to work in PIO mode. I don't see any receive overruns when pushed and I can easily keep the transmit FIFO full. > in busmastering mode there >are chip errata which have to be dealt with or it can hang up too. You mean like you have to set the latency timer to 0xFF? >as i mentioned in a previous message i still have problems with the >905 so i'm interested in any other experiences with it. I'm trying to get it to work reliably too. I don't have the right documentation for PCI to know how to set the busmaster bit or to set the latency timer as specified by the errata. Can you help here? >From owner-9fans Wed Dec 10 15:13:03 1997 Received: (from majordom@localhost) by cse.psu.edu (8.8.7/8.7.3) id PAA04006 for 9fans-outgoing; Wed, 10 Dec 1997 15:13:03 -0500 (EST) X-Authentication-Warning: claven.cse.psu.edu: majordom set sender to owner-9fans using -f Received: from ns.dbSystems.com (root@ns.dbsystems.com [204.178.76.1]) by cse.psu.edu (8.8.7/8.7.3) with SMTP id PAA04000 for <9fans@cse.psu.edu>; Wed, 10 Dec 1997 15:12:58 -0500 (EST) Received: (from gdb@localhost) by ns.dbSystems.com (8.6.11/8.6.9) id NAA06132 for 9fans@cse.psu.edu; Wed, 10 Dec 1997 13:58:59 -0600 Date: Wed, 10 Dec 1997 13:58:59 -0600 From: "G. David Butler" Message-Id: <199712101958.NAA06132@ns.dbSystems.com> To: 9fans@cse.psu.edu Subject: Re: [9fans] Re: Plan 9 from Bell Labs - Frequently Asked Sender: owner-9fans@cse.psu.edu Precedence: bulk Reply-To: 9fans >>as i mentioned in a previous message i still have problems with the >>905 so i'm interested in any other experiences with it. > >I'm trying to get it to work reliably too. I don't have the >right documentation for PCI to know how to set the busmaster bit >or to set the latency timer as specified by the errata. >Can you help here? I think I have that part down now. After GlobalReset I do a pcicfgr, set busMaster in command, set latency to 0xff and do pcicfgw to 0x04 for a length of 12. Now I get MasterStatus flag masterAbort at every transfer. For the fun of it, I tried to use the DMA at transmit as well as receive. First I PIOd enough data to keep the transmitter from underrunning then turned on the DMA. Next, to make sure the DMA code was sane, I memmoved the packet to a local buffer with the preamble in front and DMAd the whole thing. I always get masterAbort! I think I would only use the DMA on transmit for gigabit ethernet though. Is it possible to get underflow with PIO at 100mb with current hardware? So, any ideas about the abort? David Butler gdb@dbSystems.com >From owner-9fans Wed Dec 10 16:15:35 1997 Received: (from majordom@localhost) by cse.psu.edu (8.8.7/8.7.3) id QAA06095 for 9fans-outgoing; Wed, 10 Dec 1997 16:15:34 -0500 (EST) X-Authentication-Warning: claven.cse.psu.edu: majordom set sender to owner-9fans using -f Received: from plan9.bell-labs.com (plan9.bell-labs.com [204.178.31.2]) by cse.psu.edu (8.8.7/8.7.3) with SMTP id QAA06091 for <9fans@cse.psu.edu>; Wed, 10 Dec 1997 16:15:30 -0500 (EST) Message-Id: <199712102115.QAA06091@cse.psu.edu> To: 9fans@cse.psu.edu Date: Wed, 10 Dec 1997 15:54:56 -0500 From: "jim mckie" Subject: Re: [9fans] Re: Plan 9 from Bell Labs - Frequently Asked Sender: owner-9fans@cse.psu.edu Precedence: bulk Reply-To: 9fans > in busmastering mode there >are chip errata which have to be dealt with or it can hang up too. You mean like you have to set the latency timer to 0xFF? no, that's an errata for the 3c59x cards. the important erratum for the 3c905 concerns it hanging if you do busmaster receives at 10Mb. you do not need to set anything in the pci config space for the 3c905, the card and bios should have set it correctly (they do on every system i've tried). if there's interest and a volunteer i can give them the current brazil driver provided they promise to give back a plan9 version for inclusion in the website updates. it will be a bit of work: % ls -l /sys/lib/pcdist/src/9/pc/ether509.c /sys/src/brazil/pc/etherelnk3.c --rw-rw-r-- M 4 jmk sys 16762 Feb 27 1996 /sys/lib/pcdist/src/9/pc/ether509.c --rw-rw-r-- M 4 jmk sys 41136 Dec 7 00:22 /sys/src/brazil/pc/etherelnk3.c % --jim >From owner-9fans Wed Dec 10 17:32:02 1997 Received: (from majordom@localhost) by cse.psu.edu (8.8.7/8.7.3) id RAA08522 for 9fans-outgoing; Wed, 10 Dec 1997 17:32:02 -0500 (EST) X-Authentication-Warning: claven.cse.psu.edu: majordom set sender to owner-9fans using -f Received: from ns.dbSystems.com (root@ns.dbsystems.com [204.178.76.1]) by cse.psu.edu (8.8.7/8.7.3) with SMTP id RAA08518 for <9fans@cse.psu.edu>; Wed, 10 Dec 1997 17:31:53 -0500 (EST) Received: (from gdb@localhost) by ns.dbSystems.com (8.6.11/8.6.9) id QAA06223 for 9fans@cse.psu.edu; Wed, 10 Dec 1997 16:18:01 -0600 Date: Wed, 10 Dec 1997 16:18:01 -0600 From: "G. David Butler" Message-Id: <199712102218.QAA06223@ns.dbSystems.com> To: 9fans@cse.psu.edu Subject: Re: [9fans] Re: Plan 9 from Bell Labs - Frequently Asked Sender: owner-9fans@cse.psu.edu Precedence: bulk Reply-To: 9fans >no, that's an errata for the 3c59x cards. the important erratum for the >3c905 concerns it hanging if you do busmaster receives at 10Mb. I'm using 10Mb. humm... >you do not need to set anything in the pci config space for the 3c905, >the card and bios should have set it correctly (they do on every system >i've tried). Good to know. >if there's interest and a volunteer i can give them the current brazil >driver provided they promise to give back a plan9 version for inclusion >in the website updates. it will be a bit of work: > % ls -l /sys/lib/pcdist/src/9/pc/ether509.c /sys/src/brazil/pc/etherelnk3.c > --rw-rw-r-- M 4 jmk sys 16762 Feb 27 1996 /sys/lib/pcdist/src/9/pc/ether509.c > --rw-rw-r-- M 4 jmk sys 41136 Dec 7 00:22 /sys/src/brazil/pc/etherelnk3.c > % I'm game! My first priority is the fileserver kernel, but the cpu/terminal kernel will be close behind... David >From owner-9fans Wed Dec 10 21:22:00 1997 Received: (from majordom@localhost) by cse.psu.edu (8.8.7/8.7.3) id VAA13228 for 9fans-outgoing; Wed, 10 Dec 1997 21:21:59 -0500 (EST) X-Authentication-Warning: claven.cse.psu.edu: majordom set sender to owner-9fans using -f Received: from vega.aichi-u.ac.jp (vega.aichi-u.ac.jp [202.16.124.3]) by cse.psu.edu (8.8.7/8.7.3) with ESMTP id VAA13205 for <9fans@cse.psu.edu>; Wed, 10 Dec 1997 21:21:30 -0500 (EST) Received: by vega.aichi-u.ac.jp (8.8.5+2.7Wbeta5/3.6W) id LAA16621; Thu, 11 Dec 1997 11:26:25 +0900 (JST) Received: by nx.aichi-u.ac.jp (NX5.67f/NX3.0S) id AA00835; Thu, 11 Dec 97 11:10:22 +0900 Message-Id: <9712110210.AA00835@nx.aichi-u.ac.jp> Content-Type: text/plain Mime-Version: 1.0 (NeXT Mail 3.3J v130.3) Received: by NeXT.Mailer (1.130.3) From: Kenji Arisawa Date: Thu, 11 Dec 97 11:10:21 +0900 To: 9fans@cse.psu.edu Subject: [9fans] Kfs file server Reply-To: Kenji Arisawa Sender: owner-9fans@cse.psu.edu Precedence: bulk Reply-To: 9fans Hello! Kfs file server of plan9 looks too slow. The followings are the times I observed coping files of same size(5.66MB). Experiments are done on i486DX2/66MHz machines. cpu% time cp x y # copy on kfs (ids disk). Block size is set 4096. 0.01u 2.11s 63.88r cp x y cpu% time cp x y # copy on 9fs 0.03u 4.51s 24.64r cp x y ar$ time cp x y # copy on unix system (4.3BSD) ide disk 5.3 real 0.0 user 1.4 sys C> copy x y # copy on DOS ide disk 10 sec (observed using my watch) Coping on 9fs involves bi-directional transmission through 10 base ethernet using 9P protocol. The value is reasonable and may be efficient. If we apply 100 base ethernet, this time will largely improved. However why the result of kfs is so bad? Caching problem? Algorithm? Can I improve this value? I did this experiment in the hope that I can improve file access time on plan9 using only kfs adding some security mechanism. Kenji Arisawa E-mail: arisawa@aichi-u.ac.jp >From owner-9fans Wed Dec 10 21:44:11 1997 Received: (from majordom@localhost) by cse.psu.edu (8.8.7/8.7.3) id VAA13737 for 9fans-outgoing; Wed, 10 Dec 1997 21:44:10 -0500 (EST) X-Authentication-Warning: claven.cse.psu.edu: majordom set sender to owner-9fans using -f Received: from plan9.bell-labs.com (plan9.bell-labs.com [204.178.31.2]) by cse.psu.edu (8.8.7/8.7.3) with SMTP id VAA13733 for <9fans@cse.psu.edu>; Wed, 10 Dec 1997 21:44:06 -0500 (EST) Message-Id: <199712110244.VAA13733@cse.psu.edu> To: 9fans@cse.psu.edu Date: Wed, 10 Dec 1997 21:37:16 -0500 From: "jim mckie" Subject: Re: [9fans] Re: Plan 9 from Bell Labs - Frequently Asked Sender: owner-9fans@cse.psu.edu Precedence: bulk Reply-To: 9fans since everyone else stepped back leaving him in front, i've given "G. David Butler" the current driver for retrofitting to plan9. --jim >From owner-9fans Thu Dec 11 09:24:14 1997 Received: (from majordom@localhost) by cse.psu.edu (8.8.7/8.7.3) id JAA23171 for 9fans-outgoing; Thu, 11 Dec 1997 09:24:13 -0500 (EST) X-Authentication-Warning: claven.cse.psu.edu: majordom set sender to owner-9fans using -f Received: from ns.dbSystems.com (root@ns.dbsystems.com [204.178.76.1]) by cse.psu.edu (8.8.7/8.7.3) with SMTP id JAA23167 for <9fans@cse.psu.edu>; Thu, 11 Dec 1997 09:24:08 -0500 (EST) Received: (from gdb@localhost) by ns.dbSystems.com (8.6.11/8.6.9) id IAA07925 for 9fans@cse.psu.edu; Thu, 11 Dec 1997 08:10:16 -0600 Date: Thu, 11 Dec 1997 08:10:16 -0600 From: "G. David Butler" Message-Id: <199712111410.IAA07925@ns.dbSystems.com> To: 9fans@cse.psu.edu Subject: [9fans] Re: Kfs file server Sender: owner-9fans@cse.psu.edu Precedence: bulk Reply-To: 9fans From: Kenji Arisawa >Kfs file server of plan9 looks too slow. [snip] >Coping on 9fs involves bi-directional transmission >through 10 base ethernet using 9P protocol. >The value is reasonable and may be efficient. >If we apply 100 base ethernet, this time will largely improved. What are you using as a file server? A plan9 fileserver works very well. >However why the result of kfs is so bad? >Caching problem? This is the main reason. The kfs system does no caching of the hard drive. There have been other discussions of this topic and the best idea forwarded so far is to integrate the mount driver with the memory system to use "unused" memory for a cache. This would improve both kfs and 9p. Using the QID of the file to flush old contents keeps the cache in sync with the fileserver. This implies that each block transfered from the cache should wait for a walk from the fileserver to verify the QID. Doing it just on the open is not good enough. Of course, the cache has to be write-through. >Algorithm? It is the same one in the fileserver. It is simple and fast. >Can I improve this value? Easily. David Butler gdb@dbSystems.com >From owner-9fans Thu Dec 11 19:17:04 1997 Received: (from majordom@localhost) by cse.psu.edu (8.8.7/8.7.3) id TAA07197 for 9fans-outgoing; Thu, 11 Dec 1997 19:17:04 -0500 (EST) X-Authentication-Warning: claven.cse.psu.edu: majordom set sender to owner-9fans using -f Received: from ns.dbSystems.com (root@ns.dbsystems.com [204.178.76.1]) by cse.psu.edu (8.8.7/8.7.3) with SMTP id TAA07189 for <9fans@cse.psu.edu>; Thu, 11 Dec 1997 19:16:57 -0500 (EST) Received: (from gdb@localhost) by ns.dbSystems.com (8.6.11/8.6.9) id SAA08260; Thu, 11 Dec 1997 18:02:55 -0600 Date: Thu, 11 Dec 1997 18:02:55 -0600 From: "G. David Butler" Message-Id: <199712120002.SAA08260@ns.dbSystems.com> To: ed@cs.unr.edu Subject: [9fans] Re: fcall in your kernel Cc: 9fans@cse.psu.edu Sender: owner-9fans@cse.psu.edu Precedence: bulk Reply-To: 9fans From: Ed Wishart >Help. I installed your PC distribution on my home PC and tried >9fs to campus unix systems and get the error: >srv: push fcall illegal line discipline Yeah, I know... I need to put fcall in the terminal kernel on the floppies. Here I use the cpu servers to talk 9p/tcp. I have put a new set up that has fcall included. Get it from ftp://ftp.dbSystems.com/pub/PLAN9/pcdist. [snip] > Got the 4 diskette >set from bell-labs with sept 97 date, and find that disk 2 will not >unpack. It kept hanging with ``Unpacking archive'' or equivalent >on the screen. Someone at bell labs, err, lucent want to fix this? David Butler gdb@dbSystems.com >From owner-9fans Thu Dec 11 19:49:20 1997 Received: (from majordom@localhost) by cse.psu.edu (8.8.7/8.7.3) id TAA07784 for 9fans-outgoing; Thu, 11 Dec 1997 19:49:20 -0500 (EST) X-Authentication-Warning: claven.cse.psu.edu: majordom set sender to owner-9fans using -f Received: from plan9.bell-labs.com (plan9.bell-labs.com [204.178.31.2]) by cse.psu.edu (8.8.7/8.7.3) with SMTP id TAA07780 for <9fans@cse.psu.edu>; Thu, 11 Dec 1997 19:49:15 -0500 (EST) Message-Id: <199712120049.TAA07780@cse.psu.edu> To: 9fans@cse.psu.edu Date: Thu, 11 Dec 1997 19:45:06 -0500 From: "jim mckie" Subject: re: [9fans] Re: fcall in your kernel Sender: owner-9fans@cse.psu.edu Precedence: bulk Reply-To: 9fans > Got the 4 diskette >set from bell-labs with sept 97 date, and find that disk 2 will not >unpack. It kept hanging with ``Unpacking archive'' or equivalent >on the screen. The disk[234].vd files on plan9.bell-labs.com are dated Feb-02-97 and have not changed since Nov-14-95. The disk1 image was updated on Oct-16-97. Where did the Sep-27 date come from? It's possible the changes to disk1 have introduced a problem, what's the hardware configuration? >From owner-9fans Fri Dec 12 00:00:20 1997 Received: (from majordom@localhost) by cse.psu.edu (8.8.7/8.7.3) id AAA12785 for 9fans-outgoing; Fri, 12 Dec 1997 00:00:19 -0500 (EST) X-Authentication-Warning: claven.cse.psu.edu: majordom set sender to owner-9fans using -f Received: from washoe.cs.unr.edu (washoe.cs.unr.edu [134.197.42.61]) by cse.psu.edu (8.8.7/8.7.3) with SMTP id AAA12767 for <9fans@cse.psu.edu>; Fri, 12 Dec 1997 00:00:06 -0500 (EST) Date: Thu, 11 Dec PST 20:08:48 -0500 (EST) From: ed@washoe.cs.unr.edu Message-Id: <199712120500.AAA12767@cse.psu.edu> Subject: [9fans] installing plan9 woes Sender: owner-9fans@cse.psu.edu Precedence: bulk Reply-To: 9fans Jim, since you raised the question here is my story. I picked up copies of the 4 diskette set in September and these were used by my students to install plan9 on their own computers as part of a course in distributed operating systems. The same diskette set installed several plan9 systems with no problems. I have been running a plan9 system at home based on the 95 CDROM distribution. The kernel I was running was from the diskettes distributed with the 95 CDROM. I rebuilt the kernel, 9pcdisk, based on the update archive/boddle from bell-labs as best I could. Copied to the dos partition, I tried to reboot and typed the wrong incantation to get a boot and root file system to a kernel coming from the dos partition. When the kernel did boot it crashed and then no kernel would boot correctly. Even the original kernel in the boot parition would not boot. I assume that I had corrupted the disk layout, so I decided to upgrade some hardware and reinstall the newer kernel. That's when the 4 diskette set would not install on my system. Obvisouly I did not have disk 1 with the 16 Oct date. Disk1 would unpack and install fine, disk2 would not. I made additional copies of disk2, but to no avail. I even swapped the floppy in the chance it was bad. (It may still be, as I had bizarre behavior with a 9pcfs boot floppy written today.) There are now 2 disk1 copies at bell-labs ftp archive. I am unsure if I tried the one with the 16 OCT date. What is the difference? There is no indication that I could find as to which one is the ``best'' one to use. The kernel from G. David Butler at dbsystems.com installed and booted fine and I am using it to send this mail to you. Hardware: VL/ISA 486SV2 system board Intel 486DX2-33 cache 256K memory 32 MB NE2000 ethernet look alike, addr 300, IRQ 9 Adaptec 1542 C , addr 330, IRQ 11, VL VESA local bus IDE disk controller Toshiba SCSI cdrom at id 2 Cirrus GD 5426, 1 MB, video adapter Main disk, Fujitsu MPA3017AT IDE, secondary MAXTOR 7345 AT IDE Ed wishart, ed@cs.unr.edu >From owner-9fans Fri Dec 12 00:14:26 1997 Received: (from majordom@localhost) by cse.psu.edu (8.8.7/8.7.3) id AAA13162 for 9fans-outgoing; Fri, 12 Dec 1997 00:14:26 -0500 (EST) X-Authentication-Warning: claven.cse.psu.edu: majordom set sender to owner-9fans using -f Received: from plan9.bell-labs.com (plan9.bell-labs.com [204.178.31.2]) by cse.psu.edu (8.8.7/8.7.3) with SMTP id AAA13157 for <9fans@cse.psu.edu>; Fri, 12 Dec 1997 00:14:22 -0500 (EST) Message-Id: <199712120514.AAA13157@cse.psu.edu> To: 9fans@cse.psu.edu Date: Fri, 12 Dec 1997 00:13:40 -0500 From: "jim mckie" Subject: re: [9fans] installing plan9 woes Sender: owner-9fans@cse.psu.edu Precedence: bulk Reply-To: 9fans sounds like i broke something in the new disk1. a copy of the previous disk1 is in the disk1.nvd file in the pcdist directory on the ftp site. if you could try that it would let me know if i blew it (but not where). i'm about to leave on a trip and won't be able to try this myself until i return on the 22nd. --jim >From owner-9fans Fri Dec 12 04:15:39 1997 Received: (from majordom@localhost) by cse.psu.edu (8.8.7/8.7.3) id EAA16125 for 9fans-outgoing; Fri, 12 Dec 1997 04:15:38 -0500 (EST) X-Authentication-Warning: claven.cse.psu.edu: majordom set sender to owner-9fans using -f Received: from totenkopf.france3.fr ([195.171.62.2]) by cse.psu.edu (8.8.7/8.7.3) with ESMTP id EAA16121 for <9fans@cse.psu.edu>; Fri, 12 Dec 1997 04:15:32 -0500 (EST) Received: from shlakensaft.mdrf.france3.fr (boyd@shlakensaft.mdrf.france3.fr [10.175.0.11]) by totenkopf.france3.fr (8.8.7/8.8.5) with ESMTP id KAA18476 for <9fans@cse.psu.edu>; Fri, 12 Dec 1997 10:13:36 +0100 Received: from system.mdrf.france3.fr (system.mdrf.france3.fr [10.175.0.53]) by shlakensaft.mdrf.france3.fr (8.8.5/8.8.5) id KAA16093; Fri, 12 Dec 1997 10:21:02 +0100 From: Boyd Roberts Date: Fri, 12 Dec 1997 10:10:19 +0100 To: 9fans@cse.psu.edu Subject: Re: [9fans] Re: fcall in your kernel In-Reply-To: <199712120002.SAA08260@ns.dbSystems.com> Message-ID: <199712121010.4102.9.bayun@france3.fr> X-UTM: N 31 447109 5411310 La Maison de Radio France, France 3, Direction Informatique, Systemes & Reseaux X-Face: #"03$i1:"_[Hbg~GCPw}`+d4_R`}RaDfYixB`n-mCB0E8m#tNd>uyd[d)`nEix7Bys(:o#o2y7$(=,&BTXdH7)Hm5jP}H5:y]}0GT4?uTT(Y0(Cu7tWBXj\|q\@jZ8 Y_qn8)NV0*$uO][i7p"K2>Kg( Sender: owner-9fans@cse.psu.edu Precedence: bulk Reply-To: 9fans > Got the 4 diskette >set from bell-labs with sept 97 date, and find that disk 2 will not >unpack. It kept hanging with ``Unpacking archive'' or equivalent >on the screen. isn't that symptomatic of the vdexpand pipeline eating all the ram? it bit me when i had some marginal configuration. i pulled the script apart and ran it by hand using temporary files. not pretty, but it worked. >From owner-9fans Fri Dec 12 06:26:38 1997 Received: (from majordom@localhost) by cse.psu.edu (8.8.7/8.7.3) id GAA17701 for 9fans-outgoing; Fri, 12 Dec 1997 06:26:38 -0500 (EST) X-Authentication-Warning: claven.cse.psu.edu: majordom set sender to owner-9fans using -f Received: from caldo.demon.co.uk (none@caldo.demon.co.uk [194.222.207.148]) by cse.psu.edu (8.8.7/8.7.3) with SMTP id GAA17697 for <9fans@cse.psu.edu>; Fri, 12 Dec 1997 06:26:32 -0500 (EST) From: forsyth@caldo.demon.co.uk Message-Id: <199712121126.GAA17697@cse.psu.edu> To: 9fans@cse.psu.edu Date: Fri, 12 Dec 1997 09:52:25 GMT Subject: Re: [9fans] Re: Kfs file server Sender: owner-9fans@cse.psu.edu Precedence: bulk Reply-To: 9fans disk/kfs does cache the hard disc, but if you've got heaps of physical memory (and why not) it might not be using as much of it as you'd like. i think it caps the cache at 2Mbytes. the 4.3bsd figure is possibly misleading since it's quite likely to be reflecting the time taken to copy from one part of memory to another, with nothing much done with the disc. i'd try a file that's much bigger than physical memory. >From owner-9fans Fri Dec 12 13:01:12 1997 Received: (from majordom@localhost) by cse.psu.edu (8.8.7/8.7.3) id NAA05099 for 9fans-outgoing; Fri, 12 Dec 1997 13:01:12 -0500 (EST) X-Authentication-Warning: claven.cse.psu.edu: majordom set sender to owner-9fans using -f Received: from plan9.bell-labs.com (plan9.bell-labs.com [204.178.31.2]) by cse.psu.edu (8.8.7/8.7.3) with SMTP id NAA05095 for <9fans@cse.psu.edu>; Fri, 12 Dec 1997 13:01:08 -0500 (EST) Message-Id: <199712121801.NAA05095@cse.psu.edu> From: "Rob Pike" To: 9fans@cse.psu.edu Date: Fri, 12 Dec 1997 13:00:53 -0500 Sender: owner-9fans@cse.psu.edu Precedence: bulk Reply-To: 9fans A draft of the chapter discussing low-level graphics using the Draw module is now available in HTML under http://inferno.bell-labs.com/inferno/book Rob Pike Howard Trickey >From owner-9fans Sat Dec 13 13:18:58 1997 Received: (from majordom@localhost) by cse.psu.edu (8.8.7/8.7.3) id NAA27802 for 9fans-outgoing; Sat, 13 Dec 1997 13:18:58 -0500 (EST) X-Authentication-Warning: claven.cse.psu.edu: majordom set sender to owner-9fans using -f Received: from ns.dbSystems.com (root@ns.dbsystems.com [204.178.76.1]) by cse.psu.edu (8.8.7/8.7.3) with SMTP id NAA27798 for <9fans@cse.psu.edu>; Sat, 13 Dec 1997 13:18:50 -0500 (EST) Received: (from gdb@localhost) by ns.dbSystems.com (8.6.11/8.6.9) id MAA12149 for 9fans@cse.psu.edu; Sat, 13 Dec 1997 12:04:26 -0600 Date: Sat, 13 Dec 1997 12:04:26 -0600 From: "G. David Butler" Message-Id: <199712131804.MAA12149@ns.dbSystems.com> To: 9fans@cse.psu.edu Subject: [9fans] Re: etherelnk3.c Sender: owner-9fans@cse.psu.edu Precedence: bulk Reply-To: 9fans Hello All! I've just started the process of back porting the brazil etherelnk3 driver to Plan9. I would like some feedback from this list (9fans) about some of the porting issues. The primary goal of this effort is to get the support of the newer 3com cards into Plan9. I don't want to change the way it is used though. In other words, you still use ether0=type=3C509 in plan9.ini. It professes to support: /* * Etherlink III and Fast EtherLink adapters. * Product ID: * 9150 ISA 3C509[B] * 9050 ISA 3C509[B]-TP * 9450 ISA 3C509[B]-COMBO * 9550 ISA 3C509[B]-TPO * * 9350 EISA 3C579 * 9250 EISA 3C579-TP * * 5920 EISA 3C592-[TP|COMBO|TPO] * 5970 EISA 3C597-TX Fast Etherlink 10BASE-T/100BASE-TX * 5971 EISA 3C597-T4 Fast Etherlink 10BASE-T/100BASE-T4 * 5972 EISA 3C597-MII Fast Etherlink 10BASE-T/MII * * 5900 PCI 3C590-[TP|COMBO|TPO] * 5950 PCI 3C595-TX Fast Etherlink Shared 10BASE-T/100BASE-TX * 5951 PCI 3C595-T4 Fast Etherlink Shared 10BASE-T/100BASE-T4 * 5952 PCI 3C595-MII Fast Etherlink 10BASE-T/MII * * 9000 PCI 3C900-TPO Etherlink III XL PCI 10BASE-T * 9001 PCI 3C900-COMBO Etherlink III XL PCI 10BASE-T/10BASE-2/AUI * 9050 PCI 3C905-TX Fast Etherlink XL Shared 10BASE-T/100BASE-TX * 9051 PCI 3C905-T4 Fast Etherlink Shared 10BASE-T/100BASE-T4 * * 9058 PCMCIA 3C589[B]-[TP|COMBO] * * 627C MCA 3C529 * 627D MCA 3C529-TP */ After a quick perusal of the code, we have a big decision to make. This brazil driver does not use RingBuf, it uses Blocks. It also moves the Ctlr structure out of ether.h and into the driver .c file. The former change allows more data to be buffered and the latter allows driver specific data to be localized. These are both "good" things. Devether.c is not compatible with either of these changes, so we have to either update the entire ethernet subsystem to use Blocks, or make this driver use RingBufs and dirty the ether.h Card and Ctlr structures with the overhead of this driver. To limit the scope of this effort I vote for changing this driver to RingBufs and creating a structure in the driver that I will hang off Ctlr.Card.dp8390 since that is not used in the 3com stuff. By doing this I will also provide the changes I have done to support multiple ethernet cards. This affects other parts of the system, but at least we will get more functionality than we have now. Since this effort is for the Plan9 community, I didn't want remove functionality from this driver without a discussion. If it is decided that we update the ethernet subsystem, perhaps we can get Jim to provide further details to make future backports easier :-) In addition, we need someone to coordinate the overall structure and own devether.c and ether.h. Then we need volunteers to work on all of the current drivers to bring them into the fold. Are we ready to build a team to do Plan9 enhancement/development? We could use the FreeBSD model. Or do we want to leave the system as it is with Lucent as keeper of the updates? Comments? David Butler gdb@dbSystems.com >From owner-9fans Sun Dec 14 13:11:28 1997 Received: (from majordom@localhost) by cse.psu.edu (8.8.7/8.7.3) id NAA06397 for 9fans-outgoing; Sun, 14 Dec 1997 13:11:28 -0500 (EST) X-Authentication-Warning: claven.cse.psu.edu: majordom set sender to owner-9fans using -f Received: from ns.dbSystems.com (root@ns.dbsystems.com [204.178.76.1]) by cse.psu.edu (8.8.7/8.7.3) with SMTP id NAA06393 for <9fans@cse.psu.edu>; Sun, 14 Dec 1997 13:11:23 -0500 (EST) Received: (from gdb@localhost) by ns.dbSystems.com (8.6.11/8.6.9) id KAA14023 for 9fans@cse.psu.edu; Sun, 14 Dec 1997 10:37:38 -0600 Date: Sun, 14 Dec 1997 10:37:38 -0600 From: "G. David Butler" Message-Id: <199712141637.KAA14023@ns.dbSystems.com> To: 9fans@cse.psu.edu Subject: Re: [9fans] Re: etherelnk3.c Sender: owner-9fans@cse.psu.edu Precedence: bulk Reply-To: 9fans I just got a correction from jmk@plan9.bell-labs.com: >the list at the beginning of etherelnk3 is not meant to be >a list of cards supported, just a convenient all-in-one-place >list of product ids, they are spread around in the manuals. >i.e. there's no microchannel support and i've never seen a >t4 card. >From owner-9fans Sun Dec 14 19:14:22 1997 Received: (from majordom@localhost) by cse.psu.edu (8.8.7/8.7.3) id TAA09604 for 9fans-outgoing; Sun, 14 Dec 1997 19:14:22 -0500 (EST) X-Authentication-Warning: claven.cse.psu.edu: majordom set sender to owner-9fans using -f Received: from mtigwc04.worldnet.att.net (mtigwc04.worldnet.att.net [204.127.131.33]) by cse.psu.edu (8.8.7/8.7.3) with ESMTP id TAA09598 for <9fans@cse.psu.edu>; Sun, 14 Dec 1997 19:14:10 -0500 (EST) Received: from LOCALNAME ([12.68.162.208]) by mtigwc04.worldnet.att.net (post.office MTA v2.0 0613 ) with SMTP id AAA29905 for <9fans@cse.psu.edu>; Mon, 15 Dec 1997 00:13:38 +0000 X-Sender: west9@postoffice.worldnet.att.net X-Mailer: Windows Eudora Light Version 1.5.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 15 Dec 1997 19:13:25 +0000 To: 9fans@cse.psu.edu From: Thomas West Subject: [9fans] need help with u9fs Message-ID: <19971215001336.AAA29905@LOCALNAME> Sender: owner-9fans@cse.psu.edu Precedence: bulk Reply-To: 9fans I'm having at least one problem setting up u9fs on an indy. The source was copied to the indy and compiled and the /etc/inetd.conf and /etc/setvices files were amended according to the man page. A bonifide executable file exists in /bin/u9fs. (Some lines of .h files were removed because the compiler complained of multiple declarations; I will not elaborate unless it's important) As the man page anticipates: srv tcp!i!u9fs fails: can't translate address but srv tcp!i!564 succeeds (i guess) with: session.. post.. and there is an entry in the indy /tmp/u9fs.log file When i invoke disk/kfscmd allow , then mount, I get mount -c /srv/tcp!i!564 /n/i permission denied also, mount -c /srv/tcp!i!564 /n/kremvax permission denied What's wrong/missing ? >From owner-9fans Sun Dec 14 19:24:12 1997 Received: (from majordom@localhost) by cse.psu.edu (8.8.7/8.7.3) id TAA09813 for 9fans-outgoing; Sun, 14 Dec 1997 19:24:12 -0500 (EST) X-Authentication-Warning: claven.cse.psu.edu: majordom set sender to owner-9fans using -f Received: from plan9.bell-labs.com (plan9.bell-labs.com [204.178.31.2]) by cse.psu.edu (8.8.7/8.7.3) with SMTP id TAA09809 for <9fans@cse.psu.edu>; Sun, 14 Dec 1997 19:24:08 -0500 (EST) From: philw@plan9.bell-labs.com Message-Id: <199712150024.TAA09809@cse.psu.edu> To: 9fans@cse.psu.edu Date: Sun, 14 Dec 1997 19:22:56 -0500 Subject: re: [9fans] need help with u9fs Sender: owner-9fans@cse.psu.edu Precedence: bulk Reply-To: 9fans > mount -c /srv/tcp!i!564 /n/i permission denied >also, > mount -c /srv/tcp!i!564 /n/kremvax permission denied check the plan9 machine is in hosts.equiv check the u9fs is setuid root >From owner-9fans Sun Dec 14 22:02:19 1997 Received: (from majordom@localhost) by cse.psu.edu (8.8.7/8.7.3) id WAA11187 for 9fans-outgoing; Sun, 14 Dec 1997 22:02:19 -0500 (EST) X-Authentication-Warning: claven.cse.psu.edu: majordom set sender to owner-9fans using -f Received: from mtigwc04.worldnet.att.net (mtigwc04.worldnet.att.net [204.127.131.33]) by cse.psu.edu (8.8.7/8.7.3) with ESMTP id WAA11183 for <9fans@cse.psu.edu>; Sun, 14 Dec 1997 22:02:15 -0500 (EST) Received: from LOCALNAME ([12.69.1.44]) by mtigwc04.worldnet.att.net (post.office MTA v2.0 0613 ) with SMTP id AAA14526 for <9fans@cse.psu.edu>; Mon, 15 Dec 1997 03:01:40 +0000 X-Sender: west9@postoffice.worldnet.att.net X-Mailer: Windows Eudora Light Version 1.5.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 15 Dec 1997 22:01:29 +0000 To: 9fans@cse.psu.edu From: Thomas West Subject: re: [9fans] need help with u9fs Message-ID: <19971215030138.AAA14526@LOCALNAME> Sender: owner-9fans@cse.psu.edu Precedence: bulk Reply-To: 9fans At 12:22 AM 12/15/97 +0000, you wrote: >> mount -c /srv/tcp!i!564 /n/i permission denied >>also, >> mount -c /srv/tcp!i!564 /n/kremvax permission denied >check the plan9 machine is in hosts.equiv >check the u9fs is setuid root > added plan9 machine and user to /etc/usr/hosts.equiv still: mount : permission denied ls -l /bin/u9fs gives: -rwxr-xr-x 1 root sys 61368 /bin/u9fs When u9fs was compiled on the indy, the CFLAG "-DNEEDPROTO" in the makefile was deleted; with original makefile, the compiler found these incompatible types: p9 libc.h indy /usr/include/sys/stat.h int chmod(const char *,int) int external chmod(const char *,mode_t) int fchmod(const char *,int) int fchmod(const char *,mode_t) int mkdir(const char *,int) int external mkdir(const char *,mode_t) I don't know how to resolve this. >From owner-9fans Mon Dec 15 00:01:19 1997 Received: (from majordom@localhost) by cse.psu.edu (8.8.7/8.7.3) id AAA12656 for 9fans-outgoing; Mon, 15 Dec 1997 00:01:19 -0500 (EST) X-Authentication-Warning: claven.cse.psu.edu: majordom set sender to owner-9fans using -f Received: from tor.securecomputing.com (tor.securecomputing.com [199.71.190.98]) by cse.psu.edu (8.8.7/8.7.3) with ESMTP id AAA12652 for <9fans@cse.psu.edu>; Mon, 15 Dec 1997 00:01:15 -0500 (EST) Received: by janus.tor.securecomputing.com id <11649>; Mon, 15 Dec 1997 00:01:52 -0500 Date: Mon, 15 Dec 1997 00:01:01 -0500 From: steve@tor.securecomputing.com (Steve Kotsopoulos) Message-Id: <97Dec15.000152est.11649@janus.tor.securecomputing.com> To: <9fans@cse.psu.edu> Subject: [9fans] [reminder] pointer to Plan 9 FAQ Content-Type: text Apparently-To: 9fans@cse.psu.edu Sender: owner-9fans@cse.psu.edu Precedence: bulk Reply-To: 9fans The Plan 9 faq is posted to comp.os.plan9 at the beginning of each month. It is also at news.answers archive sites, look for comp-os/plan9-faq The hypertext version of the faq is always available at url http://www.ecf.toronto.edu/plan9/plan9faq.html >From owner-9fans Mon Dec 15 01:00:42 1997 Received: (from majordom@localhost) by cse.psu.edu (8.8.7/8.7.3) id BAA13451 for 9fans-outgoing; Mon, 15 Dec 1997 01:00:42 -0500 (EST) X-Authentication-Warning: claven.cse.psu.edu: majordom set sender to owner-9fans using -f Received: from chillyclay.gds.fnx.com (qmailr@gds.fnx.com [38.220.93.20]) by cse.psu.edu (8.8.7/8.7.3) with SMTP id BAA13435 for <9fans@cse.psu.edu>; Mon, 15 Dec 1997 01:00:35 -0500 (EST) From: kvanhees@fnx.com Received: (qmail 3371 invoked by uid 103); 15 Dec 1997 06:00:32 -0000 Message-ID: <19971215060032.3370.qmail@chillyclay.gds.fnx.com> Subject: Re: [9fans] need help with u9fs To: 9fans@cse.psu.edu Date: Mon, 15 Dec 1997 01:00:32 -0500 (EST) In-Reply-To: <19971215030138.AAA14526@LOCALNAME> from "Thomas West" at Dec 15, 97 10:01:29 pm X-Mailer: ELM [version 2.4 PL24 PGP6] Content-Type: text Sender: owner-9fans@cse.psu.edu Precedence: bulk Reply-To: 9fans Thomas West wrote: > > At 12:22 AM 12/15/97 +0000, you wrote: > >> mount -c /srv/tcp!i!564 /n/i permission denied > >>also, > >> mount -c /srv/tcp!i!564 /n/kremvax permission denied > >check the plan9 machine is in hosts.equiv > >check the u9fs is setuid root > > ls -l /bin/u9fs gives: > -rwxr-xr-x 1 root sys 61368 /bin/u9fs ^ +--- this would be 's' if the executable were setuid owner (root). That could be the core of the problem. I can't check though since I do not have the configuration to try it right now. Good luck, Kris >From owner-9fans Mon Dec 15 06:03:01 1997 Received: (from majordom@localhost) by cse.psu.edu (8.8.7/8.7.3) id GAA15462 for 9fans-outgoing; Mon, 15 Dec 1997 06:03:00 -0500 (EST) X-Authentication-Warning: claven.cse.psu.edu: majordom set sender to owner-9fans using -f Received: from caldo.demon.co.uk (none@caldo.demon.co.uk [194.222.207.148]) by cse.psu.edu (8.8.7/8.7.3) with SMTP id GAA15457 for <9fans@cse.psu.edu>; Mon, 15 Dec 1997 06:02:54 -0500 (EST) From: forsyth@caldo.demon.co.uk Message-Id: <199712151102.GAA15457@cse.psu.edu> To: 9fans@cse.psu.edu Date: Mon, 15 Dec 1997 09:31:31 GMT Subject: re: [9fans] need help with u9fs Sender: owner-9fans@cse.psu.edu Precedence: bulk Reply-To: 9fans >>I don't know how to resolve this. it will nearly always be something to do with hosts.equiv, as philw said. (i thought there was a peculiar interpretation of `host user' in /etc/hosts.equiv as compared to the same in $home/hosts.equiv, but i haven't got the BSD code to check. try putting just the host name.) rattach in u9fs will generate the same diagnostic if the attaching user name maps to user ID 0 on Unix, but that seems less likely. there are some changes to u9fs that improve performance, by switching off the silly delay code in various tcp/ip implementations. i'll see if i can produce a boddle or diff set. i've fixed a memory leak bug in it as well. >From owner-9fans Mon Dec 15 06:12:41 1997 Received: (from majordom@localhost) by cse.psu.edu (8.8.7/8.7.3) id GAA15640 for 9fans-outgoing; Mon, 15 Dec 1997 06:12:40 -0500 (EST) X-Authentication-Warning: claven.cse.psu.edu: majordom set sender to owner-9fans using -f Received: from plan9.bell-labs.com (plan9.bell-labs.com [204.178.31.2]) by cse.psu.edu (8.8.7/8.7.3) with SMTP id GAA15634 for <9fans@cse.psu.edu>; Mon, 15 Dec 1997 06:12:36 -0500 (EST) Message-Id: <199712151112.GAA15634@cse.psu.edu> To: 9fans@cse.psu.edu Date: Mon, 15 Dec 1997 06:11:32 -0500 From: "Russ Cox" Subject: re: [9fans] need help with u9fs Sender: owner-9fans@cse.psu.edu Precedence: bulk Reply-To: 9fans If u9fs is in fact running, looking at /tmp/u9fs.log is usually helpful. The most common problem I have is that the particular name that u9fs ends up looking for is not in hosts.equiv -- only some alias of the machine is, but that ends up not being good enough. See what u9fs.log says. >From owner-9fans Mon Dec 15 06:22:42 1997 Received: (from majordom@localhost) by cse.psu.edu (8.8.7/8.7.3) id GAA15817 for 9fans-outgoing; Mon, 15 Dec 1997 06:22:41 -0500 (EST) X-Authentication-Warning: claven.cse.psu.edu: majordom set sender to owner-9fans using -f Received: from mail.ch.genedata.com (mentolat-e0.ch.genedata.com [157.161.173.16]) by cse.psu.edu (8.8.7/8.7.3) with ESMTP id GAA15813 for <9fans@cse.psu.edu>; Mon, 15 Dec 1997 06:22:36 -0500 (EST) Received: from genedata.com (pinatubo.ch.genedata.com [157.161.173.32]) by mail.ch.genedata.com (8.8.8/8.8.8) with ESMTP id MAA03825 for <9fans@cse.psu.edu>; Mon, 15 Dec 1997 12:21:57 +0100 Message-ID: <349512D5.2F687B2D@genedata.com> Date: Mon, 15 Dec 1997 12:21:57 +0100 From: elliott Organization: GeneData AG X-Mailer: Mozilla 4.04 [en] (X11; I; IRIX64 6.2 IP19) MIME-Version: 1.0 To: 9fans@cse.psu.edu Subject: Keepers of the flame (was Re: [9fans] Re: etherelnk3.c) References: <199712131804.MAA12149@ns.dbSystems.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-9fans@cse.psu.edu Precedence: bulk Reply-To: 9fans G. David Butler wrote: > Are we ready to build a team to do Plan9 enhancement/development? > We could use the FreeBSD model. Or do we want to leave the > system as it is with Lucent as keeper of the updates? Is Lucent really keeper of the updates anyway? It seems to me that every time a problem is mentioned someone (often forsyth) says "oh yeah, I fixed that ages ago; I'll look out the patch". I don't think it's true that when I finally get me, my CD and sufficient computers all together and all in the same country, I'll be able to pop over to Lucent and ftp all the patches I need. I'm not sure what you mean by the FreeBSD model. To me that means "stick the source tree on an FTP site and let all and sundry play". That doesn't seem to fit with the idea of us all having handed over cash to AT&T and (presumably, I haven't read it yet) having agreed not to pass anything on. It certainly would be nice if we could guarantee that people don't have to keep fixing things independently of one another. It might be interesting to know what everyone's doing with Plan 9, too. Where people's interests lie. -- Elliott Hughes - GeneData AG, Postfach 254, CH-4016 Basel, Switzerland mailto:elliott.hughes@genedata.com http://users.ch.genedata.com/~enh/ >From owner-9fans Mon Dec 15 07:09:33 1997 Received: (from majordom@localhost) by cse.psu.edu (8.8.7/8.7.3) id HAA16237 for 9fans-outgoing; Mon, 15 Dec 1997 07:09:32 -0500 (EST) X-Authentication-Warning: claven.cse.psu.edu: majordom set sender to owner-9fans using -f Received: from totenkopf.france3.fr ([195.171.62.2]) by cse.psu.edu (8.8.7/8.7.3) with ESMTP id HAA16233 for <9fans@cse.psu.edu>; Mon, 15 Dec 1997 07:09:22 -0500 (EST) Received: from shlakensaft.mdrf.france3.fr (boyd@shlakensaft.mdrf.france3.fr [10.175.0.11]) by totenkopf.france3.fr (8.8.7/8.8.5) with ESMTP id MAA22323 for <9fans@cse.psu.edu>; Mon, 15 Dec 1997 12:47:00 +0100 Received: from system.mdrf.france3.fr (system.mdrf.france3.fr [10.175.0.53]) by shlakensaft.mdrf.france3.fr (8.8.5/8.8.5) id MAA01737; Mon, 15 Dec 1997 12:55:30 +0100 From: Boyd Roberts Date: Mon, 15 Dec 1997 12:46:11 +0100 To: 9fans@cse.psu.edu Subject: re: [9fans] need help with u9fs In-Reply-To: <199712151102.GAA15457@cse.psu.edu> Message-ID: <199712151246.15761.9.bazal@france3.fr> X-UTM: N 31 447109 5411310 La Maison de Radio France, France 3, Direction Informatique, Systemes & Reseaux X-Face: #"03$i1:"_[Hbg~GCPw}`+d4_R`}RaDfYixB`n-mCB0E8m#tNd>uyd[d)`nEix7Bys(:o#o2y7$(=,&BTXdH7)Hm5jP}H5:y]}0GT4?uTT(Y0(Cu7tWBXj\|q\@jZ8 Y_qn8)NV0*$uO][i7p"K2>Kg( Sender: owner-9fans@cse.psu.edu Precedence: bulk Reply-To: 9fans From: forsyth@caldo.demon.co.uk it will nearly always be something to do with hosts.equiv, as philw said. (i thought there was a peculiar interpretation of `host user' in /etc/hosts.equiv no, it's just a list of hostnames. you can specify both in $home/^{.rhosts,.netrc}, but that's another story. >From owner-9fans Mon Dec 15 07:15:18 1997 Received: (from majordom@localhost) by cse.psu.edu (8.8.7/8.7.3) id HAA16375 for 9fans-outgoing; Mon, 15 Dec 1997 07:15:17 -0500 (EST) X-Authentication-Warning: claven.cse.psu.edu: majordom set sender to owner-9fans using -f Received: from caldo.demon.co.uk (none@caldo.demon.co.uk [194.222.207.148]) by cse.psu.edu (8.8.7/8.7.3) with SMTP id HAA16370 for <9fans@cse.psu.edu>; Mon, 15 Dec 1997 07:15:12 -0500 (EST) From: forsyth@caldo.demon.co.uk Message-Id: <199712151215.HAA16370@cse.psu.edu> To: 9fans@cse.psu.edu Date: Mon, 15 Dec 1997 10:43:58 GMT Subject: Re: Keepers of the flame (was Re: [9fans] Re: etherelnk3.c) Sender: owner-9fans@cse.psu.edu Precedence: bulk Reply-To: 9fans >>Is Lucent really keeper of the updates anyway? It seems to me that every >>time a problem is mentioned someone (often forsyth) says "oh yeah, I >>fixed that ages ago; I'll look out the patch". I don't think it's true >>that when I finally get me, my CD and sufficient computers all together >>and all in the same country, I'll be able to pop over to Lucent and ftp >>all the patches I need. if so, it's our (my) fault for not having fed changes back consistently. most of the changes and extensions generally available thus far really have come from people at Bell Labs, particularly jmk. once the updates from plan9.bell-labs.com have been applied, your system should be in reasonably good shape. >From owner-9fans Mon Dec 15 07:47:46 1997 Received: (from majordom@localhost) by cse.psu.edu (8.8.7/8.7.3) id HAA16776 for 9fans-outgoing; Mon, 15 Dec 1997 07:47:46 -0500 (EST) X-Authentication-Warning: claven.cse.psu.edu: majordom set sender to owner-9fans using -f Received: from hst1us.satlink.com (root@hst1us.satlink.com [206.67.134.2]) by cse.psu.edu (8.8.7/8.7.3) with ESMTP id HAA16770 for <9fans@cse.psu.edu>; Mon, 15 Dec 1997 07:47:42 -0500 (EST) From: Women@male.com Received: from hst1us.satlink.com (il219.idsonline.com [207.152.119.219]) by hst1us.satlink.com (8.8.2/8.8.2) with SMTP id HAA23850; Mon, 15 Dec 1997 07:48:03 -0500 Message-Id: <199712151248.HAA23850@hst1us.satlink.com> To: men@male.com Date: Mon, 15 Dec 97 04:56:56 EST Subject: [9fans] For men only Reply-To: women@over21.com Sender: owner-9fans@cse.psu.edu Precedence: bulk Reply-To: 9fans Dear Adult This message is intended for mature adults. If it has reached you in error, We apologize. Are you (or someone you know) affected by any of the following conditions: € Impotency € Incomplete or inadequate erections € Deteriorating sexual function (erections) due to: 1. Age 2. Medical Condition 3. Medication 4. Life Style € Premature ejaculation If you are, the Performance Technique can reduce or eliminate the adverse affects these conditions are having on your intimate relations. If not you, maybe a friend, parent or grandparent could benefit. To immediately read about this revolutionary sex technique Visit the Performance Technique Home Page: Click Here Or go to: http://www.sitehost.com/sexallnite/default1.htm Good luck - Have fun. President Performance Technique >From owner-9fans Mon Dec 15 12:48:29 1997 Received: (from majordom@localhost) by cse.psu.edu (8.8.7/8.7.3) id MAA21778 for 9fans-outgoing; Mon, 15 Dec 1997 12:48:29 -0500 (EST) X-Authentication-Warning: claven.cse.psu.edu: majordom set sender to owner-9fans using -f Received: from mailbox2.ucsd.edu (mailbox2.ucsd.edu [132.239.1.54]) by cse.psu.edu (8.8.7/8.7.3) with ESMTP id MAA21773 for <9fans@cse.psu.edu>; Mon, 15 Dec 1997 12:48:24 -0500 (EST) Received: from jewel.ucsd.edu (jewel.ucsd.edu [132.239.121.100]) by mailbox2.ucsd.edu (8.8.5/8.6.9) with SMTP id JAA20132 for <9fans@cse.psu.edu>; Mon, 15 Dec 1997 09:48:23 -0800 (PST) Received: by jewel.ucsd.edu (SMI-8.6/SMI-SVR4) id JAA06582; Mon, 15 Dec 1997 09:43:11 -0800 Date: Mon, 15 Dec 1997 09:43:11 -0800 From: eld@jewel.ucsd.edu (Eric Dorman) Message-Id: <199712151743.JAA06582@jewel.ucsd.edu> To: 9fans@cse.psu.edu Subject: Re: [9fans] Re: etherelnk3.c X-Sun-Charset: US-ASCII Sender: owner-9fans@cse.psu.edu Precedence: bulk Reply-To: 9fans > From: "G. David Butler" > To: 9fans@cse.psu.edu > Subject: [9fans] Re: etherelnk3.c > > Hello All! > > I've just started the process of back porting the brazil > etherelnk3 driver to Plan9. I would like some feedback > from this list (9fans) about some of the porting issues. [xxx] > After a quick perusal of the code, we have a big decision > to make. This brazil driver does not use RingBuf, it uses > Blocks. It also moves the Ctlr structure out of ether.h > and into the driver .c file. The former change allows > more data to be buffered and the latter allows driver > specific data to be localized. These are both "good" things. > Devether.c is not compatible with either of these changes, > so we have to either update the entire ethernet subsystem to > use Blocks, or make this driver use RingBufs and dirty the > ether.h Card and Ctlr structures with the overhead of this > driver. Another thing to consider is how these changes would affect the integration of ether drivers between the fs and terminal code. Integrating these two trees first allieviates a whole mess of existing problems and ensures that this type of effort won't have to be done again (perhaps differently, even) for fs. > David Butler > gdb@dbSystems.com Regards, Eric L. Dorman University of California at San Diego edorman@ucsd.edu >From owner-9fans Mon Dec 15 13:29:19 1997 Received: (from majordom@localhost) by cse.psu.edu (8.8.7/8.7.3) id NAA22677 for 9fans-outgoing; Mon, 15 Dec 1997 13:29:19 -0500 (EST) X-Authentication-Warning: claven.cse.psu.edu: majordom set sender to owner-9fans using -f Received: from ns.dbSystems.com (root@ns.dbsystems.com [204.178.76.1]) by cse.psu.edu (8.8.7/8.7.3) with SMTP id NAA22673 for <9fans@cse.psu.edu>; Mon, 15 Dec 1997 13:29:13 -0500 (EST) Received: (from gdb@localhost) by ns.dbSystems.com (8.6.11/8.6.9) id MAA16085 for 9fans@cse.psu.edu; Mon, 15 Dec 1997 12:14:33 -0600 Date: Mon, 15 Dec 1997 12:14:33 -0600 From: "G. David Butler" Message-Id: <199712151814.MAA16085@ns.dbSystems.com> To: 9fans@cse.psu.edu Subject: Re: [9fans] Re: etherelnk3.c Sender: owner-9fans@cse.psu.edu Precedence: bulk Reply-To: 9fans >From: eld@jewel.ucsd.edu (Eric Dorman) >> From: "G. David Butler" >> To: 9fans@cse.psu.edu >> Subject: [9fans] Re: etherelnk3.c >> > Another thing to consider is how these changes would affect >the integration of ether drivers between the fs and terminal code. >Integrating these two trees first allieviates a whole mess of >existing problems and ensures that this type of effort won't >have to be done again (perhaps differently, even) for fs. In fact the problem becomes worse since Blocks don't exist in the fs. There we would have to use Msgbufs. >From owner-9fans Mon Dec 15 16:44:08 1997 Received: (from majordom@localhost) by cse.psu.edu (8.8.7/8.7.3) id QAA27246 for 9fans-outgoing; Mon, 15 Dec 1997 16:44:08 -0500 (EST) X-Authentication-Warning: claven.cse.psu.edu: majordom set sender to owner-9fans using -f Received: from mtigwc03.worldnet.att.net (mtigwc03.worldnet.att.net [204.127.131.34]) by cse.psu.edu (8.8.7/8.7.3) with ESMTP id QAA27232 for <9fans@cse.psu.edu>; Mon, 15 Dec 1997 16:43:38 -0500 (EST) Received: from LOCALNAME ([12.68.162.89]) by mtigwc03.worldnet.att.net (post.office MTA v2.0 0613 ) with SMTP id AAA11897 for <9fans@cse.psu.edu>; Mon, 15 Dec 1997 21:43:03 +0000 X-Sender: west9@postoffice.worldnet.att.net X-Mailer: Windows Eudora Light Version 1.5.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 16 Dec 1997 16:42:49 +0000 To: 9fans@cse.psu.edu From: Thomas West Subject: [9fans] need help with u9fs Message-ID: <19971215214259.AAA11897@LOCALNAME> Sender: owner-9fans@cse.psu.edu Precedence: bulk Reply-To: 9fans Several 9fans have pointed to the need to list the 9machine in the indy file '/etc/hosts.equiv' - Thanks - I have done and still 'permission denied' Philw and Kris Vanhees have identified another problem: the 9nfs binary is rwx, not rws, as required. Is this permission set by the compiler, or is there some chmod like command that will do the trick? >From owner-9fans Mon Dec 15 16:47:24 1997 Received: (from majordom@localhost) by cse.psu.edu (8.8.7/8.7.3) id QAA27375 for 9fans-outgoing; Mon, 15 Dec 1997 16:47:24 -0500 (EST) X-Authentication-Warning: claven.cse.psu.edu: majordom set sender to owner-9fans using -f Received: from pixar.com (pixar.pixar.com [138.72.10.20]) by cse.psu.edu (8.8.7/8.7.3) with ESMTP id QAA27367 for <9fans@cse.psu.edu>; Mon, 15 Dec 1997 16:47:17 -0500 (EST) Received: from marvin.pixar.com (marvin.pixar.com [138.72.30.83]) by pixar.com (8.8.6/8.8.6) with SMTP id NAA01313 for <9fans@cse.psu.edu>; Mon, 15 Dec 1997 13:46:46 -0800 (PST) Received: by marvin.pixar.com (Smail3.1.29.1 #2) id m0xhiLc-00Ia30C; Mon, 15 Dec 97 13:46 PST From: "Tom Duff" Message-Id: <9712151346.ZM25918@marvin> Date: Mon, 15 Dec 1997 13:46:44 -0800 In-Reply-To: Thomas West "[9fans] need help with u9fs" (Dec 16, 4:42pm) References: <19971215214259.AAA11897@LOCALNAME> Reply-To: td@pixar.com X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail) To: 9fans@cse.psu.edu Subject: Re: [9fans] need help with u9fs Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-9fans@cse.psu.edu Precedence: bulk Reply-To: 9fans -- Tom Duff, KF6LWB. Gort! Klaatu barada ... uhh ... uhh ... >From owner-9fans Mon Dec 15 16:51:23 1997 Received: (from majordom@localhost) by cse.psu.edu (8.8.7/8.7.3) id QAA27539 for 9fans-outgoing; Mon, 15 Dec 1997 16:51:22 -0500 (EST) X-Authentication-Warning: claven.cse.psu.edu: majordom set sender to owner-9fans using -f Received: from pixar.com (pixar.pixar.com [138.72.10.20]) by cse.psu.edu (8.8.7/8.7.3) with ESMTP id QAA27531 for <9fans@cse.psu.edu>; Mon, 15 Dec 1997 16:51:02 -0500 (EST) Received: from marvin.pixar.com (marvin.pixar.com [138.72.30.83]) by pixar.com (8.8.6/8.8.6) with SMTP id NAA01510 for <9fans@cse.psu.edu>; Mon, 15 Dec 1997 13:50:32 -0800 (PST) Received: by marvin.pixar.com (Smail3.1.29.1 #2) id m0xhiPG-00Ia30C; Mon, 15 Dec 97 13:50 PST From: "Tom Duff" Message-Id: <9712151350.ZM25953@marvin> Date: Mon, 15 Dec 1997 13:50:30 -0800 In-Reply-To: Thomas West "[9fans] need help with u9fs" (Dec 16, 4:42pm) References: <19971215214259.AAA11897@LOCALNAME> Reply-To: td@pixar.com X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail) To: 9fans@cse.psu.edu Subject: Re: [9fans] need help with u9fs Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-9fans@cse.psu.edu Precedence: bulk Reply-To: 9fans On Dec 16, 4:42pm, Thomas West wrote: > the 9nfs binary is rwx, not rws, as required. > > Is this permission set by the compiler, or is there some chmod like command > that will do the trick? The command is exactly like chmod. ``chmod 4755 9nfs'' or ``chmod u+s 9nfs'' should do the job. -- Tom Duff, KF6LWB. Gort! Klaatu barada ... uhh ... uhh ... >From owner-9fans Mon Dec 15 17:06:37 1997 Received: (from majordom@localhost) by cse.psu.edu (8.8.7/8.7.3) id RAA27957 for 9fans-outgoing; Mon, 15 Dec 1997 17:06:37 -0500 (EST) X-Authentication-Warning: claven.cse.psu.edu: majordom set sender to owner-9fans using -f Received: from network.ucsd.edu (network.ucsd.edu [132.239.1.195]) by cse.psu.edu (8.8.7/8.7.3) with ESMTP id RAA27953 for <9fans@cse.psu.edu>; Mon, 15 Dec 1997 17:06:33 -0500 (EST) Received: from Tanya (tanya.ucsd.edu [132.239.141.90]) by network.ucsd.edu (8.8.5/8.6.9) with SMTP id OAA01158; Mon, 15 Dec 1997 14:06:29 -0800 (PST) Received: by Tanya (950413.SGI.8.6.12/940406.SGI.AUTO) id OAA01851; Mon, 15 Dec 1997 14:03:46 -0800 Date: Mon, 15 Dec 1997 14:03:46 -0800 From: edorman@Tanya.ucsd.edu (Eric Dorman) Message-Id: <199712152203.OAA01851@Tanya> To: 9fans@cse.psu.edu, td@pixar.com Subject: Re: [9fans] need help with u9fs References: <19971215214259.AAA11897@LOCALNAME> Sender: owner-9fans@cse.psu.edu Precedence: bulk Reply-To: 9fans >-- >Tom Duff, KF6LWB. Gort! Klaatu barada ... uhh ... uhh ... "Nickle! Necktie! ... it's definately an N-word... " eric >From owner-9fans Tue Dec 16 05:52:38 1997 Received: (from majordom@localhost) by cse.psu.edu (8.8.7/8.7.3) id FAA04809 for 9fans-outgoing; Tue, 16 Dec 1997 05:52:37 -0500 (EST) X-Authentication-Warning: claven.cse.psu.edu: majordom set sender to owner-9fans using -f Received: from vega.aichi-u.ac.jp (vega.aichi-u.ac.jp [202.16.124.3]) by cse.psu.edu (8.8.7/8.7.3) with ESMTP id FAA04805 for <9fans@cse.psu.edu>; Tue, 16 Dec 1997 05:52:26 -0500 (EST) Received: by vega.aichi-u.ac.jp (8.8.5+2.7Wbeta5/3.6W) id TAA26361; Tue, 16 Dec 1997 19:57:26 +0900 (JST) Received: by ar.aichi-u.ac.jp (NX5.67f/NX3.0S) id AA01971; Tue, 16 Dec 97 19:54:18 +0900 Message-Id: <9712161054.AA01971@ar.aichi-u.ac.jp> Content-Type: text/plain Mime-Version: 1.0 (NeXT Mail 3.3J v130.3) X-Nextstep-Mailer: Mail 3.3J (Enhance 2.0b6) Received: by NeXT.Mailer (1.130.3) From: Kenji Arisawa Date: Tue, 16 Dec 97 19:54:16 +0900 To: 9fans@cse.psu.edu Subject: re: [9fans] need help with u9fs Reply-To: arisawa@aichi-u.ac.jp Sender: owner-9fans@cse.psu.edu Precedence: bulk Reply-To: 9fans The below is my setting for u9fs. I mount whole unix file system on plan9 for simplicity. Kenji Arisawa E-mail: arisawa@aichi-u.ac.jp # # unix side # ar$ cat /etc/inetd.conf ... u9fs stream tcp nowait root /usr/local/etc/u9fs u9fs / ... ar$ car /etc/service ... u9fs 564/tcp u9fs ... ar$ pwd /usr/local/etc ar$ ls -l ... -rwxrwxr-x 1 root 32768 Oct 24 14:13 u9fs* ... ar$ cd ar$ cat .rhosts 9pc arisawa plan9 arisawa ... # # plan9 side # cpu% cat /lib/ndb/local ... tcp=9fs port=564 ... cpu% ls -l $home/n d-rwxr-xr-x M 4 arisawa arisawa 0 Nov 10 18:37 ar cpu% cat $home/lib/profile ... bind -ac $home/n /n ... >From owner-9fans Tue Dec 16 07:14:26 1997 Received: (from majordom@localhost) by cse.psu.edu (8.8.7/8.7.3) id HAA05459 for 9fans-outgoing; Tue, 16 Dec 1997 07:14:26 -0500 (EST) X-Authentication-Warning: claven.cse.psu.edu: majordom set sender to owner-9fans using -f Received: from cegelecproj.co.uk (ganymede.cegelecproj.co.uk [159.245.72.6]) by cse.psu.edu (8.8.7/8.7.3) with SMTP id HAA05455 for <9fans@cse.psu.edu>; Tue, 16 Dec 1997 07:14:19 -0500 (EST) Received: from vampire.cegelecproj.co.uk (cerberus.cegelecproj.co.uk) by cegelecproj.co.uk (4.1/SMI-4.1) id AA28453; Tue, 16 Dec 97 12:13:43 GMT Received: by vampire.cegelecproj.co.uk (SMI-8.6/SMI-SVR4) id MAA21914; Tue, 16 Dec 1997 12:13:31 GMT Date: Tue, 16 Dec 1997 12:13:31 GMT From: Steve_Kilbane@cegelecproj.co.uk Message-Id: <199712161213.MAA21914@vampire.cegelecproj.co.uk> X-Planation: X-Faces images can be viewed with the XFaces program To: 9fans@cse.psu.edu Subject: re: [9fans] need help with u9fs X-Face: Iqsa(US9p?)Y^W+6Ff[Z]rM"uFE) lFDjag1e]\/#2 Sender: owner-9fans@cse.psu.edu Precedence: bulk Reply-To: 9fans Waaay back why I was setting up u9fs on my Solaris box, according to the logs, the connecting machine wasn't considered valid (I think the getpeername() was failing, though memory's vague). I do know that I just cheated, hardwiring the domainname of the remote machine into u9fs.c, with the result that any connecting machine appeared to be the one that was allowed in. Of course, not everyone's environment will allow this. >From owner-9fans Tue Dec 16 07:26:47 1997 Received: (from majordom@localhost) by cse.psu.edu (8.8.7/8.7.3) id HAA05735 for 9fans-outgoing; Tue, 16 Dec 1997 07:26:47 -0500 (EST) X-Authentication-Warning: claven.cse.psu.edu: majordom set sender to owner-9fans using -f Received: from totenkopf.france3.fr ([195.171.62.2]) by cse.psu.edu (8.8.7/8.7.3) with ESMTP id HAA05714 for <9fans@cse.psu.edu>; Tue, 16 Dec 1997 07:25:42 -0500 (EST) Received: from shlakensaft.mdrf.france3.fr (boyd@shlakensaft.mdrf.france3.fr [10.175.0.11]) by totenkopf.france3.fr (8.8.7/8.8.5) with ESMTP id NAA23599 for <9fans@cse.psu.edu>; Tue, 16 Dec 1997 13:23:58 +0100 Received: from system.mdrf.france3.fr (system.mdrf.france3.fr [10.175.0.53]) by shlakensaft.mdrf.france3.fr (8.8.5/8.8.5) id NAA14146; Tue, 16 Dec 1997 13:32:48 +0100 From: Boyd Roberts Date: Tue, 16 Dec 1997 13:21:48 +0100 To: 9fans@cse.psu.edu Subject: re: [9fans] need help with u9fs In-Reply-To: <199712161213.MAA21914@vampire.cegelecproj.co.uk> Message-ID: <199712161321.6723.9.bazed@france3.fr> X-UTM: N 31 447109 5411310 La Maison de Radio France, France 3, Direction Informatique, Systemes & Reseaux X-Face: #"03$i1:"_[Hbg~GCPw}`+d4_R`}RaDfYixB`n-mCB0E8m#tNd>uyd[d)`nEix7Bys(:o#o2y7$(=,&BTXdH7)Hm5jP}H5:y]}0GT4?uTT(Y0(Cu7tWBXj\|q\@jZ8 Y_qn8)NV0*$uO][i7p"K2>Kg( Sender: owner-9fans@cse.psu.edu Precedence: bulk Reply-To: 9fans From: Steve_Kilbane@cegelecproj.co.uk Waaay back why I was setting up u9fs on my Solaris box, according to the logs, the connecting machine wasn't considered valid (I think the getpeername() was failing, though memory's vague). don't you mean gethostbyaddr()? the reverse dns lookup after getpeername(). it's unlikely getpeername() is going to fail, unless the code is bust :-) >From owner-9fans Tue Dec 16 08:37:13 1997 Received: (from majordom@localhost) by cse.psu.edu (8.8.7/8.7.3) id IAA06464 for 9fans-outgoing; Tue, 16 Dec 1997 08:37:12 -0500 (EST) X-Authentication-Warning: claven.cse.psu.edu: majordom set sender to owner-9fans using -f Received: from mtigwc04.worldnet.att.net (mtigwc04.worldnet.att.net [204.127.131.33]) by cse.psu.edu (8.8.7/8.7.3) with ESMTP id IAA06460 for <9fans@cse.psu.edu>; Tue, 16 Dec 1997 08:37:08 -0500 (EST) Received: from LOCALNAME ([12.68.162.116]) by mtigwc04.worldnet.att.net (post.office MTA v2.0 0613 ) with SMTP id AAA23369; Tue, 16 Dec 1997 13:36:36 +0000 X-Sender: west9@postoffice.worldnet.att.net X-Mailer: Windows Eudora Light Version 1.5.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 17 Dec 1997 08:36:21 +0000 To: td@pixar.com, 9fans@cse.psu.edu From: Thomas West Subject: Re: [9fans] need help with u9fs Message-ID: <19971216133632.AAA23369@LOCALNAME> Sender: owner-9fans@cse.psu.edu Precedence: bulk Reply-To: 9fans At 09:46 PM 12/15/97 +0000, you wrote: > >-- >Tom Duff, KF6LWB. Gort! Klaatu barada ... uhh ... uhh ... Nice to hear from you. Pls repeat. >From owner-9fans Tue Dec 16 09:07:12 1997 Received: (from majordom@localhost) by cse.psu.edu (8.8.7/8.7.3) id JAA06933 for 9fans-outgoing; Tue, 16 Dec 1997 09:07:12 -0500 (EST) X-Authentication-Warning: claven.cse.psu.edu: majordom set sender to owner-9fans using -f Received: from cegelecproj.co.uk (ganymede.cegelecproj.co.uk [159.245.72.6]) by cse.psu.edu (8.8.7/8.7.3) with SMTP id JAA06929 for <9fans@cse.psu.edu>; Tue, 16 Dec 1997 09:07:03 -0500 (EST) Received: from vampire.cegelecproj.co.uk (cerberus.cegelecproj.co.uk) by cegelecproj.co.uk (4.1/SMI-4.1) id AA29174; Tue, 16 Dec 97 14:06:27 GMT Received: by vampire.cegelecproj.co.uk (SMI-8.6/SMI-SVR4) id OAA22581; Tue, 16 Dec 1997 14:06:12 GMT Date: Tue, 16 Dec 1997 14:06:12 GMT From: Steve_Kilbane@cegelecproj.co.uk Message-Id: <199712161406.OAA22581@vampire.cegelecproj.co.uk> X-Planation: X-Faces images can be viewed with the XFaces program To: 9fans@cse.psu.edu Subject: re: [9fans] need help with u9fs X-Face: Iqsa(US9p?)Y^W+6Ff[Z]rM"uFE) lFDjag1e]\/#2 Sender: owner-9fans@cse.psu.edu Precedence: bulk Reply-To: 9fans > don't you mean gethostbyaddr()? the reverse dns lookup after getpeername(). > it's unlikely getpeername() is going to fail, unless the code is bust :-) I did say it was a Solaris box... I don't know. 'Twas a local client, and there was no reason why gethostbyaddr() should have been failing to necessitate such a hack, and there was some reason why I couldn't fix it properly. Anyway, the point is, if things get desperate, u9fs.c's own protection need not be a significant problem. >From owner-9fans Wed Dec 17 13:15:48 1997 Received: (from majordom@localhost) by cse.psu.edu (8.8.8/8.7.3) id NAA01576 for 9fans-outgoing; Wed, 17 Dec 1997 13:15:48 -0500 (EST) X-Authentication-Warning: claven.cse.psu.edu: majordom set sender to owner-9fans using -f Received: from echo.cs.unr.edu (echo.cs.unr.edu [134.197.40.60]) by cse.psu.edu (8.8.8/8.7.3) with ESMTP id NAA01572 for <9fans@cse.psu.edu>; Wed, 17 Dec 1997 13:15:43 -0500 (EST) Received: (from ed@localhost) by echo.cs.unr.edu (8.8.5/8.8.5) id KAA02267 for 9fans@cse.psu.edu; Wed, 17 Dec 1997 10:15:41 -0800 Date: Wed, 17 Dec 1997 10:15:41 -0800 From: Ed Wishart Message-Id: <199712171815.KAA02267@echo.cs.unr.edu> To: 9fans@cse.psu.edu Subject: [9fans] u9fs problems Sender: owner-9fans@cse.psu.edu Precedence: bulk Reply-To: 9fans We use u9fs on 2 environments here at Nevada. Solaris and DEC Ultrix. Ultrix always allows connections, Solaris sometimes refuses, but if I reboot my terminal Solaris allows me to connect. Don't know why this is. It happened this morning. My account name is the same on both unix and plan 9, of course. U9fs in both environments is not running SUIDed to root and it is started via inetd with out TCP wrappers. Presently we have 4 plan 9 terminals and 1 plan 9 file server. ------------------------------------------------------------------------ Ed Wishart The only constant in life is change. Computer Science Department/171 University of Nevada Reno, NV 89557 USA Internet: ed@cs.unr.edu ------------------------------------------------------------------------- >From owner-9fans Tue Dec 23 04:59:41 1997 Received: (from majordom@localhost) by cse.psu.edu (8.8.8/8.7.3) id EAA09570 for 9fans-outgoing; Tue, 23 Dec 1997 04:59:40 -0500 (EST) X-Authentication-Warning: claven.cse.psu.edu: majordom set sender to owner-9fans using -f Received: from vega.aichi-u.ac.jp (vega.aichi-u.ac.jp [202.16.124.3]) by cse.psu.edu (8.8.8/8.7.3) with ESMTP id EAA09566 for <9fans@cse.psu.edu>; Tue, 23 Dec 1997 04:59:31 -0500 (EST) Received: by vega.aichi-u.ac.jp (8.8.5+2.7Wbeta5/3.6W) id TAA06846; Tue, 23 Dec 1997 19:04:54 +0900 (JST) Received: by ar.aichi-u.ac.jp (NX5.67f/NX3.0S) id AA03877; Tue, 23 Dec 97 19:01:38 +0900 Date: Tue, 23 Dec 97 19:01:38 +0900 From: Kenji Arisawa Message-Id: <9712231001.AA03877@ar.aichi-u.ac.jp> To: 9fans@cse.psu.edu Subject: [9fans] trio64v+ Cc: arisawa@vega.aichi-u.ac.jp Sender: owner-9fans@cse.psu.edu Precedence: bulk Reply-To: 9fans Hello 9fans! Recently I bought a motherboard. Now I am trying to install plan9. My hardwares are: CPU: pentium MMX 166MHz motherboard: MiTAC PH5400TX The specification is: Intel 430TX chipset Award BIOS 4 PCI, 3 ISA 2 DIMM sockets EIDE 3.2GB SCSI: Adaptec 1542CF vga card: trio64v+ Plan9 works on these hardwares except vga card. Plan9 initially shows a message to add a data into vgadb. I added a line: 0xC0044="Phoenix S3 TRIO64V+ Enhanced VGA BIOS. Version 1.0" # Trio64V+ after the following lines in /lib/vgadb of updated version. 0xC0044="Phoenix S3 TRIO32 Enhanced VGA BIOS. Version 1.3-08-12-57MHz" 0xC0044="Phoenix S3 TRIO64 Enhanced VGA BIOS. Version 1.3-08" 0xC0044="Phoenix S3 TRIO64 Enhanced VGA BIOS. Version 1.00-06" 0xC0044="Phoenix S3 TRIO64 Enhanced VGA BIOS. Version 1.2-07" After adding the line, Plan9 does not complain the lack of data. However my display does not show any graphic data. My configuration must be in fail. I have expected trio64v+ is upward compatible to trio64, but I don't know if it is really so or not. Does someone know about this card and how to configure? Kenji Arisawa E-mail: arisawa@aichi-u.ac.jp >From owner-9fans Tue Dec 23 05:53:59 1997 Received: (from majordom@localhost) by cse.psu.edu (8.8.8/8.7.3) id FAA09936 for 9fans-outgoing; Tue, 23 Dec 1997 05:53:59 -0500 (EST) X-Authentication-Warning: claven.cse.psu.edu: majordom set sender to owner-9fans using -f Received: from symbionics.co.uk (symsun3.symbionics.co.uk [194.32.100.60]) by cse.psu.edu (8.8.8/8.7.3) with SMTP id FAA09932 for <9fans@cse.psu.edu>; Tue, 23 Dec 1997 05:53:53 -0500 (EST) Received: from symnt3.symbionics.co.uk by symbionics.co.uk (4.1/SMI-4.1) id AA27999; Tue, 23 Dec 97 10:53:25 GMT Received: by symnt3.symbionics.co.uk with SMTP (Microsoft Exchange Server Internet Mail Connector Version 4.0.995.52) id <01BD0F90.FBD8F950@symnt3.symbionics.co.uk>; Tue, 23 Dec 1997 10:53:21 -0000 Message-Id: From: Nigel Roles To: "'9fans@cse.psu.edu'" <9fans@cse.psu.edu> Subject: [9fans] Iomega Zip driver - at last Date: Tue, 23 Dec 1997 10:53:19 -0000 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.995.52 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-9fans@cse.psu.edu Precedence: bulk Reply-To: 9fans I have a horrible feeling it was a year ago that I first suggested I had an Iomega Zip driver for Plan 9. I did, but it had a bug I couldn't find. So, I started again. Here it is ... http://www.cotswold.demon.co.uk/dist/ppa >From owner-9fans Tue Dec 23 16:31:37 1997 Received: (from majordom@localhost) by cse.psu.edu (8.8.8/8.7.3) id QAA16821 for 9fans-outgoing; Tue, 23 Dec 1997 16:31:37 -0500 (EST) X-Authentication-Warning: claven.cse.psu.edu: majordom set sender to owner-9fans using -f Received: from unx1.shsu.edu (unx1.shsu.edu [158.135.1.10]) by cse.psu.edu (8.8.8/8.7.3) with SMTP id QAA16811 for <9fans@cse.psu.edu>; Tue, 23 Dec 1997 16:31:28 -0500 (EST) Received: by unx1.shsu.edu (8.6.10/SMI-4.1) id PAA24816; Tue, 23 Dec 1997 15:12:16 -0600 Date: Tue, 23 Dec 1997 15:12:16 -0600 (CST) From: Brandon Black To: 9fans@cse.psu.edu Subject: [9fans] Plan9 on NeXT In-Reply-To: <199712121801.NAA05095@cse.psu.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-9fans@cse.psu.edu Precedence: bulk Reply-To: 9fans Well, I haven't been running plan 9 for the past several months, because I no longer wanted to use up 3 PC's for it at the house... However, my company is now ditching some old NeXT hardware, so I'm looking at using that...... They're all 040's.... some plain 68040-25 "NeXTstations" mainly, and one "Color", one "Turbo", and one "Color Turbo". I'm pretty sure the Turbos mean 68040-33Mhz. >From what I understand from "The Various Ports", any of these should work for terminals.. (I would probably take home the Color and Color Turbo for terminals and get monitors for them... I've found the NeXT hardware faqs and some NeXT resale shops to help with that)... Question is, can I use a NeXTstation Turbo as a CPU server? If I remember right, the cpu server kernel and terminal kernel are only slightly different.. so I would think yes... but nowhere in the manuals is there mention of a "9nextstationcpu" kernel. Brandon >From owner-9fans Tue Dec 23 19:04:34 1997 Received: (from majordom@localhost) by cse.psu.edu (8.8.8/8.7.3) id TAA18316 for 9fans-outgoing; Tue, 23 Dec 1997 19:04:34 -0500 (EST) X-Authentication-Warning: claven.cse.psu.edu: majordom set sender to owner-9fans using -f Received: from plan9.bell-labs.com (plan9.bell-labs.com [204.178.31.2]) by cse.psu.edu (8.8.8/8.7.3) with SMTP id TAA18312 for <9fans@cse.psu.edu>; Tue, 23 Dec 1997 19:04:30 -0500 (EST) Message-Id: <199712240004.TAA18312@cse.psu.edu> To: 9fans@cse.psu.edu Date: Tue, 23 Dec 1997 19:04:05 -0500 From: "Rob Pike" Subject: Re: [9fans] Plan9 on NeXT Sender: owner-9fans@cse.psu.edu Precedence: bulk Reply-To: 9fans We never tried Plan 9 on any Next machine other than the plain Nextstation. I doubt you'll have much luck on the other systems, although it's probably not too much work, given a sure-to-be-scarce manual, to port it. -rob >From owner-9fans Tue Dec 23 23:40:37 1997 Received: (from majordom@localhost) by cse.psu.edu (8.8.8/8.7.3) id XAA20471 for 9fans-outgoing; Tue, 23 Dec 1997 23:40:37 -0500 (EST) X-Authentication-Warning: claven.cse.psu.edu: majordom set sender to owner-9fans using -f Received: from plan9.bell-labs.com (plan9.bell-labs.com [204.178.31.2]) by cse.psu.edu (8.8.8/8.7.3) with SMTP id XAA20467 for <9fans@cse.psu.edu>; Tue, 23 Dec 1997 23:40:33 -0500 (EST) Message-Id: <199712240440.XAA20467@cse.psu.edu> To: 9fans@cse.psu.edu Date: Tue, 23 Dec 1997 23:30:28 -0500 From: "jim mckie" Subject: Re: [9fans] Re: etherelnk3.c Sender: owner-9fans@cse.psu.edu Precedence: bulk Reply-To: 9fans actually, it's easier. you can turn a Block-based driver into a filesystem driver with a handful of #defines, two trivial functions and a couple of #ifdefs (i know, we don't actually approve of that). #ifdefs are only necessary because Blocks use read and write pointers and Msgbufs use a base and count. --jim ------ forwarded message follows ------ >From cse.psu.edu!owner-9fans Mon Dec 15 13:30:30 EST 1997 Received: from cse.psu.edu ([130.203.3.50]) by plan9; Mon Dec 15 13:30:30 EST 1997 Received: from localhost (majordom@localhost) by cse.psu.edu (8.8.7/8.7.3) with SMTP id NAA22716; Mon, 15 Dec 1997 13:29:56 -0500 (EST) Received: by claven.cse.psu.edu (bulk_mailer v1.5); Mon, 15 Dec 1997 13:29:24 -0500 Received: (from majordom@localhost) by cse.psu.edu (8.8.7/8.7.3) id NAA22677 for 9fans-outgoing; Mon, 15 Dec 1997 13:29:19 -0500 (EST) X-Authentication-Warning: claven.cse.psu.edu: majordom set sender to owner-9fans using -f Received: from ns.dbSystems.com (root@ns.dbsystems.com [204.178.76.1]) by cse.psu.edu (8.8.7/8.7.3) with SMTP id NAA22673 for <9fans@cse.psu.edu>; Mon, 15 Dec 1997 13:29:13 -0500 (EST) Received: (from gdb@localhost) by ns.dbSystems.com (8.6.11/8.6.9) id MAA16085 for 9fans@cse.psu.edu; Mon, 15 Dec 1997 12:14:33 -0600 Date: Mon, 15 Dec 1997 12:14:33 -0600 From: "G. David Butler" Message-Id: <199712151814.MAA16085@ns.dbSystems.com> To: cse.psu.edu!9fans Subject: Re: [9fans] Re: etherelnk3.c Sender: cse.psu.edu!owner-9fans Reply-To: cse.psu.edu!9fans Precedence: bulk >From: eld@jewel.ucsd.edu (Eric Dorman) >> From: "G. David Butler" >> To: 9fans@cse.psu.edu >> Subject: [9fans] Re: etherelnk3.c >> > Another thing to consider is how these changes would affect >the integration of ether drivers between the fs and terminal code. >Integrating these two trees first allieviates a whole mess of >existing problems and ensures that this type of effort won't >have to be done again (perhaps differently, even) for fs. In fact the problem becomes worse since Blocks don't exist in the fs. There we would have to use Msgbufs. >From owner-9fans Wed Dec 24 16:56:17 1997 Received: (from majordom@localhost) by cse.psu.edu (8.8.8/8.7.3) id QAA26808 for 9fans-outgoing; Wed, 24 Dec 1997 16:56:17 -0500 (EST) X-Authentication-Warning: claven.cse.psu.edu: majordom set sender to owner-9fans using -f Received: from plan9.bell-labs.com (plan9.bell-labs.com [204.178.31.2]) by cse.psu.edu (8.8.8/8.7.3) with SMTP id QAA26804 for <9fans@cse.psu.edu>; Wed, 24 Dec 1997 16:56:13 -0500 (EST) Message-Id: <199712242156.QAA26804@cse.psu.edu> To: 9fans@cse.psu.edu Date: Wed, 24 Dec 1997 16:50:55 -0500 From: "jim mckie" Subject: re: [9fans] trio64v+ Sender: owner-9fans@cse.psu.edu Precedence: bulk Reply-To: 9fans there are a number of bugs in the trio64v+, none of which are covered by the plan9 code. since i don't have a card with the trio64v+ i can't verify if any of them need to be worked on for correct plan9 operation. one thing to try is to bring the system up in cga mode then try different resolutions by hand. i don't know which resolutions you've tried, but sometimes the x8 resolutions will work when the x1 won't. --jim >From owner-9fans Mon Dec 29 15:32:39 1997 Received: (from majordom@localhost) by cse.psu.edu (8.8.8/8.7.3) id PAA01227 for 9fans-outgoing; Mon, 29 Dec 1997 15:32:38 -0500 (EST) X-Authentication-Warning: claven.cse.psu.edu: majordom set sender to owner-9fans using -f Received: from mailbox1.ucsd.edu (mailbox1.ucsd.edu [132.239.1.53]) by cse.psu.edu (8.8.8/8.7.3) with ESMTP id PAA01223 for <9fans@cse.psu.edu>; Mon, 29 Dec 1997 15:32:34 -0500 (EST) Received: from jewel.ucsd.edu (jewel.ucsd.edu [132.239.121.100]) by mailbox1.ucsd.edu (8.8.5/8.6.9) with SMTP id MAA16980 for <9fans@cse.psu.edu>; Mon, 29 Dec 1997 12:31:12 -0800 (PST) Received: by jewel.ucsd.edu (SMI-8.6/SMI-SVR4) id MAA00646; Mon, 29 Dec 1997 12:25:45 -0800 Date: Mon, 29 Dec 1997 12:25:45 -0800 From: eld@jewel.ucsd.edu (Eric Dorman) Message-Id: <199712292025.MAA00646@jewel.ucsd.edu> To: 9fans@cse.psu.edu Subject: Re: [9fans] Re: etherelnk3.c X-Sun-Charset: US-ASCII Sender: owner-9fans@cse.psu.edu Precedence: bulk Reply-To: 9fans > >From: eld@jewel.ucsd.edu (Eric Dorman) > >> From: "G. David Butler" > >> To: 9fans@cse.psu.edu > >> Subject: [9fans] Re: etherelnk3.c > >> > > Another thing to consider is how these changes would affect > >the integration of ether drivers between the fs and terminal code. > >Integrating these two trees first allieviates a whole mess of > >existing problems and ensures that this type of effort won't > >have to be done again (perhaps differently, even) for fs. > > In fact the problem becomes worse since Blocks don't exist > in the fs. There we would have to use Msgbufs. > > From: "jim mckie" > Subject: Re: [9fans] Re: etherelnk3.c > > actually, it's easier. you can turn a Block-based driver into > a filesystem driver with a handful of #defines, two trivial functions > and a couple of #ifdefs (i know, we don't actually approve of that). > #ifdefs are only necessary because Blocks use read and write pointers > and Msgbufs use a base and count. > --jim Definately worth a look; I've got a 9pcfs that allows the use of IDE disks for filesystems and have found that the network is far and away the limiting factor (10Mbit/sec 10BaseT on NE2000s) and 100BaseT is practically free these days; I'd love to use 100BaseT. I have some BayNetworks DEC21140 100bT PCI cards (plus the chipset docs) but haven't got around to scribbling out a driver with the holidays and all :) The IDE interface is pretty crufty and sits on top of the primitive hardread/hardwrite interface in hard.c. I have just one more nasty bug to stomp before exposing it to the outside world (screwy IND1 block tag problem?). It really deserves a better driver to take advantage of LBA, multiple read/write commands, and etc; maybe next week. Might even be able to interleave across primary and secondary IDEs (if the braindead chipsets will support it..). So far I've had to scramble around in the fs code changing 'long's to 'ulong's in bytewise size computations and changing the type of disk block addresses to ulongs; the matched-pair of 3.5G disks breaks 'long's. I'm worrying though that this may have caused my block tag bug. I'm pretty sure I've got all the dots connected but still get bitten by this tag bug. It crops up when writing a big file into the fs (typically ~19Mb), then writing another big file; the first file, when reread, causes errors like 'tag 5 -- expected 3 -- flushed' when reading IND1 blocks and a read error on the terminal. How I read this is that the fs reads a block, expecting it to have tag 3 (IND1 block) but instead got a file data block (tag 5, err DFile); I'm pretty sure the block in question *should* have been an IND1 block but I haven't actually seen the fs scribble on that particular block any time after it gets flushed for the first time. (Grr) It appears the right physical sectors are being read/written, but I haven't fully internalized the byte-offset/length weirdness in hard.c enough yet to be fully convinced everything works under all conditions. I would like some comments on changing the way the fs knows about available physical disks. As it stands the fs knows about 'Devwren', 'Devworm' and etc. which is fine. The choices for adding an IDE interface were to utilize a new dev type (Devide) and codeletter (h) for IDE disks, (requires rewiring stuff in fs/port/sub.c) or somehow patching into the scsi stuff below the Devwren level. I chose the former as an easier solution but it's, well, icky; changing stuff in fs/port is evil since I'd have to stub out 'ideread/idewrite' in all other architectures. Seems to me a better solution would be to have the hardware-specific initialization stuff build a table describing the disks connected to the box (complete with codeletters, size, traps into the hardware driver, etc) and have fs/port/sub.c go indirect through the table to the hardware. Sincerely, Eric Dorman edorman@ucsd.edu >From owner-9fans Mon Dec 29 20:37:25 1997 Received: (from majordom@localhost) by cse.psu.edu (8.8.8/8.7.3) id UAA03930 for 9fans-outgoing; Mon, 29 Dec 1997 20:37:25 -0500 (EST) X-Authentication-Warning: claven.cse.psu.edu: majordom set sender to owner-9fans using -f Received: from ns.dbSystems.com (root@ns.dbsystems.com [204.178.76.1]) by cse.psu.edu (8.8.8/8.7.3) with SMTP id UAA03921 for <9fans@cse.psu.edu>; Mon, 29 Dec 1997 20:37:13 -0500 (EST) Received: (from gdb@localhost) by ns.dbSystems.com (8.6.11/8.6.9) id TAA18884 for 9fans@cse.psu.edu; Mon, 29 Dec 1997 19:20:46 -0600 Date: Mon, 29 Dec 1997 19:20:46 -0600 From: "G. David Butler" Message-Id: <199712300120.TAA18884@ns.dbSystems.com> To: 9fans@cse.psu.edu Subject: Re: [9fans] Re: etherelnk3.c Sender: owner-9fans@cse.psu.edu Precedence: bulk Reply-To: 9fans From: eld@jewel.ucsd.edu (Eric Dorman) >Definately worth a look; I've got a 9pcfs that allows the use >of IDE disks for filesystems Why? I agree IDE disks are very attractive from a $$/MB point of view, but you can't get enough of them on a machine. The overall $$/MB is less with SCSI since you can aggregate the cost of the CPU/RAM over more disks. Also, IDE is PIO and that is a bad place to waste CPU resources. > and have found that the network >is far and away the limiting factor (10Mbit/sec 10BaseT on NE2000s) If you use two transmit buffers, sending one and filling the other, you will find much more "network" in your NE2000. [I don't use the NE2000 anymore now that I have the 3c515 working! Not for the 100bT, but for the 64k of RAM and busmaster transfers!] >and 100BaseT is practically free these days; I'd love to use 100BaseT. Not when you look at the price/performance of 10bT full duplex switches and 100bT hubs. 100bT full duplex switches are nice, and expensive. (I'm looking at many nodes on the network, all *very* busy.) If you follow the thread a while ago about the 3Com cards and the big packet problem, you will see it's pretty easy to get the 3C509 PCI 10/100 card up and running (in PIO mode). I still haven't ported the Brazil driver because of the ongoing discussion about ringbufs/blocks/msgbufs. (I'm still leaning towards using the ringbufs.) But, once that is done, you'll have that option. > Might even be able to interleave across primary and >secondary IDEs (if the braindead chipsets will support it..). No need, filsys main [h0h1] will interleave for you. >So far I've had to scramble around in the fs code changing 'long's >to 'ulong's in bytewise size computations and changing the type >of disk block addresses to ulongs; the matched-pair of 3.5G disks >breaks 'long's. I'm worrying though that this may have caused >my block tag bug. Very possible. I looked at doing a global long to ulong change but found some places that weren't easy to fix (I don't remeber where now), so I left it alone. I was thinking of reducing the block size and needed more blocks. If you leave the block size at 4K, and handle the multiplier like devwren does, then you shouldn't need to make that change. [snip] >reads a block, expecting it to have tag 3 (IND1 block) but instead >got a file data block (tag 5, err DFile); I'm pretty sure the block What is the path set to? Is it the first file or the second? If it is the second, then you are overwriting the block. >in question *should* have been an IND1 block but I haven't actually >seen the fs scribble on that particular block any time after it >gets flushed for the first time. (Grr) It appears the right Was it in memory correctly before being flushed? >I would like some comments on changing the way the fs knows >about available physical disks. As it stands the fs knows >about 'Devwren', 'Devworm' and etc. which is fine. The choices >for adding an IDE interface were to utilize a new dev type >(Devide) and codeletter (h) for IDE disks, (requires rewiring >stuff in fs/port/sub.c) Yes! > or somehow patching into the scsi >stuff below the Devwren level. No! > I chose the former as an >easier solution but it's, well, icky; changing stuff in >fs/port is evil since I'd have to stub out 'ideread/idewrite' >in all other architectures. Why? Use different names. You need to handle the translation of RBUFSIZE blocks to real sectors somewhere. >Seems to me a better solution would be to have the hardware-specific >initialization stuff build a table describing the disks connected >to the box (complete with codeletters, size, traps into the >hardware driver, etc) and have fs/port/sub.c go indirect >through the table to the hardware. Maybe. I like the way it is now because my mirror code likes to know that a disk is missing (for whatever reason) and then know that it is available again later (a reboot cleared the error, or the drive was replaced.) The config block is written to a mirror set with "config {w0.0w1.0}" and it tells you what the system is suppose to look like even if it doesn't look like that now. I have caused drive and controller failures and the system just takes the drive (or all the drives on a failed controller) off line and keeps running. When the system is fixed and rebooted, it finds the mirrors needing recovery and does it. Even if it is booted with the drives sick, it does the right thing. When I added log support to the system, I thought about going directly to scsiio so I could write less data to the log, (you have to go down to that level before 512 byte blocks are visible). But I also wanted to use the striping [] and mirror {} capabilities so I created another special file system "log". (Special in the way that "main" is special.) This decision made many other things easier, e.g. I can use the buffer cache for recovery (getbuf/putbuf) and bypass it otherwise (devwrite). I would recommend using what is there, it works pretty well. David Butler gdb@dbSystems.com >From owner-9fans Tue Dec 30 09:29:51 1997 Received: (from majordom@localhost) by cse.psu.edu (8.8.8/8.7.3) id JAA09636 for 9fans-outgoing; Tue, 30 Dec 1997 09:29:50 -0500 (EST) 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.8.8/8.7.3) with SMTP id JAA09630 for <9fans@cse.psu.edu>; Tue, 30 Dec 1997 09:29:45 -0500 (EST) From: miller@hamnavoe.demon.co.uk Message-Id: <199712301429.JAA09630@cse.psu.edu> To: 9fans@cse.psu.edu Date: Tue, 30 Dec 1997 13:20:52 GMT Subject: re: [9fans] trio64v+ Sender: owner-9fans@cse.psu.edu Precedence: bulk Reply-To: 9fans jmk@plan9.bell-labs.com says: > there are a number of bugs in the trio64v+, none of which are covered by > the plan9 code. since i don't have a card with the trio64v+ i can't verify > if any of them need to be worked on for correct plan9 operation. I have used a Trio64V+ card with no problems (using aux/vga as updated by 871963795.rc). With monitor=multisync135, it is possible to use all the 8-bit resolutions in /lib/vgadb, and all the 1-bit resolutions up to 1024x768. -- Richard Miller >From owner-9fans Tue Dec 30 14:10:52 1997 Received: (from majordom@localhost) by cse.psu.edu (8.8.8/8.7.3) id OAA12210 for 9fans-outgoing; Tue, 30 Dec 1997 14:10:52 -0500 (EST) X-Authentication-Warning: claven.cse.psu.edu: majordom set sender to owner-9fans using -f Received: from mailbox1.ucsd.edu (mailbox1.ucsd.edu [132.239.1.53]) by cse.psu.edu (8.8.8/8.7.3) with ESMTP id OAA12206 for <9fans@cse.psu.edu>; Tue, 30 Dec 1997 14:10:47 -0500 (EST) Received: from jewel.ucsd.edu (jewel.ucsd.edu [132.239.121.100]) by mailbox1.ucsd.edu (8.8.5/8.6.9) with SMTP id LAA03625 for <9fans@cse.psu.edu>; Tue, 30 Dec 1997 11:10:45 -0800 (PST) Received: by jewel.ucsd.edu (SMI-8.6/SMI-SVR4) id LAA01931; Tue, 30 Dec 1997 11:05:22 -0800 Date: Tue, 30 Dec 1997 11:05:22 -0800 From: eld@jewel.ucsd.edu (Eric Dorman) Message-Id: <199712301905.LAA01931@jewel.ucsd.edu> To: 9fans@cse.psu.edu Subject: Re: [9fans] Re: etherelnk3.c X-Sun-Charset: US-ASCII Sender: owner-9fans@cse.psu.edu Precedence: bulk Reply-To: 9fans > From gdb@dbSystems.com Mon Dec 29 17:36:38 1997 > Date: Mon, 29 Dec 1997 19:20:46 -0600 > From: eld@jewel.ucsd.edu (Eric Dorman) > >Definately worth a look; I've got a 9pcfs that allows the use > >of IDE disks for filesystems > Why? I agree IDE disks are very attractive from a $$/MB point > of view, but you can't get enough of them on a machine. The > overall $$/MB is less with SCSI since you can aggregate the cost > of the CPU/RAM over more disks. Also, IDE is PIO and that > is a bad place to waste CPU resources. Well, one doesn't *have* to use PIO mode on IDEs, one can use the supposed-DMA modes :) Consider as well that it's unlikely that CPU is a premium in the fs; more likely it's bounded by network or disk bandwidth (offhand). Besides, CPU is cheap on PCs, and fs's aren't doing anything else. With 8-9G EIDEs readily available, 32-36G is a goodly-sized magnetic level, and considerably cheaper than SCSI for the size range. Around here SCSIs are ~2x-2.5x per G for ultrawide, and 1.5-2x for fast. For the scope that I'm working in, 32G is fine for primary storage even. Certainly the long-run cost amortization for SCSI is better, but that's only relevant if it's going to be realized... Of course the current support in the fs is for pretty slow scsi controllers, from what I've seen. One could stick a PCI controller that looks like an AHA1542 in there but the driver wouldn't utilize 32-bit addressing, forcing the use of bounce buffers... hmm, didn't some of the VLB cards have a larger address space? > > and have found that the network > >is far and away the limiting factor (10Mbit/sec 10BaseT on NE2000s) > If you use two transmit buffers, sending one and filling the other, > you will find much more "network" in your NE2000. [I don't use > the NE2000 anymore now that I have the 3c515 working! Not for the > 100bT, but for the 64k of RAM and busmaster transfers!] Well, whatever NE2000 mode being used in the cdrom for fs is what I'm using. I haven't dredged into it to see how it's running the wire. I don't recall offhand seeing 3C515 support in the code; is there a boddle for it? > >and 100BaseT is practically free these days; I'd love to use 100BaseT. > Not when you look at the price/performance of 10bT full duplex switches > and 100bT hubs. 100bT full duplex switches are nice, and expensive. Sure, if you're building your own WAN network from the ground-up. We have much switched 10bT infrastructure already in place and some switched 100bT sections (fiber backbone) so it doesn't cost me anything :) (at least at work) .. 100bT dumb hubs are plenty cheap ($50-70), fine for local runs and (hidden behind routers) tightly-coupled fileservers and workstations. [xx] > > Might even be able to interleave across primary and > >secondary IDEs (if the braindead chipsets will support it..). > No need, filsys main [h0h1] will interleave for you. If h0 and h1 are on the same IDE controller you won't get overlapping operations (unlike SCSI) since a single IDE controller can't do more than one thing at a time. W/o overlapping the operations [h0h1] isin't a big win over (h0h1) (though better use of the on-disk caches is a help). On the other hand, lets say you have controllers h0 and h1, each with disks 0 and 1. Then you can say [h0.0h1.0] and get two operations running at the same time (one on controller 0 and another on controller 1). The question, however, whether the chipsets will do it. I suspect that the win from [h0.0h1.0] over [h0h1] will be less than [h0h1] is over (h0h1) because of the on-disk caches... > >So far I've had to scramble around in the fs code changing 'long's > >to 'ulong's in bytewise size computations and changing the type > >of disk block addresses to ulongs; the matched-pair of 3.5G disks > >breaks 'long's. I'm worrying though that this may have caused > >my block tag bug. > Very possible. I looked at doing a global long to ulong change > but found some places that weren't easy to fix (I don't remeber > where now), so I left it alone. I was thinking of reducing the > block size and needed more blocks. If you leave the block size > at 4K, and handle the multiplier like devwren does, then you > shouldn't need to make that change. Well, I found out what the problem was; stupidity on my part =:) I forgot that the fs was basically multithreaded and ended up reusing a buffer at the driver-level before the fs-level got to it... ick. Eliminated an intermediate copy too. Now everything seems to work (for h0); big files, root fs, etc. with ulong block addresses and file sizes. Several builds and boots so far and no trouble. It's off to h0.1 and h1.? land :) I have to kick it in the butt with big files before I'm happy with it though. > > I chose the former as an [h typecode in port/sub.c] > >easier solution but it's, well, icky; changing stuff in > >fs/port is evil since I'd have to stub out 'ideread/idewrite' > >in all other architectures. > Why? Use different names. [xx] What do you mean by 'use different names'? Seems to me that if port/sub.c references ideread/idewrite for type Devide you'll have to have a ideread/idewrite stub in every set of architecture-specific drivers (not just pc) since you have to satisfy that reference somewhere. Unless, of course, you compile port/sub.c (with #ifdefs or something, more yuk) differently for, say, sparcs, than for pcs. Am I missing something? > >Seems to me a better solution would be to have the hardware-specific > >initialization stuff build a table describing the disks connected > >to the box (complete with codeletters, size, traps into the > >hardware driver, etc) and have fs/port/sub.c go indirect > >through the table to the hardware. > > Maybe. I like the way it is now because my mirror code likes > to know that a disk is missing (for whatever reason) and then > know that it is available again later (a reboot cleared the error, > or the drive was replaced.) The config block is written to a > mirror set with "config {w0.0w1.0}" and it tells you what the system > is suppose to look like even if it doesn't look like that now. > I have caused drive and controller failures and the system > just takes the drive (or all the drives on a failed controller) > off line and keeps running. When the system is fixed and rebooted, > it finds the mirrors needing recovery and does it. Even if it > is booted with the drives sick, it does the right thing. Yeah; If OTOH the table indexed controllers (which is the real problem part anyway) rather than disks themselves, the only time the fs would have trouble is if it booted with a broken controller. > David Butler > gdb@dbSystems.com Regards, Eric Dorman edorman@ucsd.edu >From owner-9fans Tue Dec 30 21:44:57 1997 Received: (from majordom@localhost) by cse.psu.edu (8.8.8/8.7.3) id VAA15584 for 9fans-outgoing; Tue, 30 Dec 1997 21:44:57 -0500 (EST) X-Authentication-Warning: claven.cse.psu.edu: majordom set sender to owner-9fans using -f Received: from plan9.bell-labs.com (plan9.bell-labs.com [204.178.31.2]) by cse.psu.edu (8.8.8/8.7.3) with SMTP id VAA15580 for <9fans@cse.psu.edu>; Tue, 30 Dec 1997 21:44:53 -0500 (EST) Message-Id: <199712310244.VAA15580@cse.psu.edu> To: 9fans@cse.psu.edu Date: Tue, 30 Dec 1997 21:41:15 -0500 From: "jim mckie" Subject: Re: [9fans] Re: etherelnk3.c Sender: owner-9fans@cse.psu.edu Precedence: bulk Reply-To: 9fans >Of course the current support in the fs is for pretty slow >scsi controllers, from what I've seen. One could stick a >PCI controller that looks like an AHA1542 in there but the >driver wouldn't utilize 32-bit addressing, forcing the use of >bounce buffers... hmm, didn't some of the VLB cards have >a larger address space? this has been gone over before on the list. given the buslogic eisa controller driver in the fs kernel (which is no slouch), it's trivial to make a buslogic pci controller work in 32-bit mode; that's what we use. --jim >From owner-9fans Tue Dec 30 23:08:27 1997 Received: (from majordom@localhost) by cse.psu.edu (8.8.8/8.7.3) id XAA16236 for 9fans-outgoing; Tue, 30 Dec 1997 23:08:27 -0500 (EST) X-Authentication-Warning: claven.cse.psu.edu: majordom set sender to owner-9fans using -f Received: from ns.dbSystems.com (root@ns.dbsystems.com [204.178.76.1]) by cse.psu.edu (8.8.8/8.7.3) with SMTP id XAA16232 for <9fans@cse.psu.edu>; Tue, 30 Dec 1997 23:08:21 -0500 (EST) Received: (from gdb@localhost) by ns.dbSystems.com (8.6.11/8.6.9) id VAA20991 for 9fans@cse.psu.edu; Tue, 30 Dec 1997 21:51:43 -0600 Date: Tue, 30 Dec 1997 21:51:43 -0600 From: "G. David Butler" Message-Id: <199712310351.VAA20991@ns.dbSystems.com> To: 9fans@cse.psu.edu Subject: Re: [9fans] Re: etherelnk3.c Sender: owner-9fans@cse.psu.edu Precedence: bulk Reply-To: 9fans >>Of course the current support in the fs is for pretty slow >>scsi controllers, from what I've seen. One could stick a >>PCI controller that looks like an AHA1542 in there but the >>driver wouldn't utilize 32-bit addressing, forcing the use of >>bounce buffers... hmm, didn't some of the VLB cards have >>a larger address space? > >this has been gone over before on the list. given the buslogic eisa controller >driver in the fs kernel (which is no slouch), it's trivial to make a buslogic pci >controller work in 32-bit mode; that's what we use. Well, a little work on the 154x, with multiple outstanding requests per target, scatter/gather to 32k of queued operations, buson time of 15 and busoff time of 0, is no slouch either; especially with 4 controllers in a system with 4-6 targets each. [This is why I need a 3c515 busmaster ethernet card with 64k of RAM. :-)] I also did a 1740x enhanced driver on the EISA bus to determine how bad the ISA bus is. I have the 154x on the ISA bus writing a little less than 2MB/sec to the drives. The 174x can do almost 4MB/sec. (The 174x in standard mode also does about 4MB/sec, bounce buffers notwithstanding.) I've seen a 294x (on *NIX) do 5MB/sec. [Of course you really pay for it with the 2940. During that 5MB test 47% of a P5/133 was eaten up! A test on the same system with a 154x got 1MB/sec but used only 4% of the CPU. The 154x is a very sweet design.] In any case, random I/O cuts the rate per target to *much* less, perhaps a couple hundred K/sec. In this case allowing outstanding commands, scatter/gather and disconnect make all the difference. When PCI finally settles down and gets as reliable as 154x's on the ISA bus, I'll move. Of course a good SCSI adapter design would be nice. I hate the 294x. Does anybody have any experience with the Qlogic board? (http://www.qlc.com) It looks like a good alternative. One note, the code in the 154x driver says that the card does not guarantee the order of SCSI operations which is why the driver allows only one RBUFSIZE scsi command at a time. This is so true. If you allow the SCSI subsystem to be more asynchronous, expect the writes to be out of order and you have to do something to keep a crash and running "check" from eating your lunch. Remember, fsck on *NIX only works if the freelist and inode updates are well ordered. Plan9 is not any different. David Butler gdb@dbSystems.com >From owner-9fans Wed Dec 31 00:26:16 1997 Received: (from majordom@localhost) by cse.psu.edu (8.8.8/8.7.3) id AAA17923 for 9fans-outgoing; Wed, 31 Dec 1997 00:26:16 -0500 (EST) X-Authentication-Warning: claven.cse.psu.edu: majordom set sender to owner-9fans using -f Received: from plan9.bell-labs.com (plan9.bell-labs.com [204.178.31.2]) by cse.psu.edu (8.8.8/8.7.3) with SMTP id AAA17919 for <9fans@cse.psu.edu>; Wed, 31 Dec 1997 00:26:12 -0500 (EST) Message-Id: <199712310526.AAA17919@cse.psu.edu> To: 9fans@cse.psu.edu Date: Wed, 31 Dec 1997 00:16:05 -0500 From: "jim mckie" Subject: Re: [9fans] Re: etherelnk3.c Sender: owner-9fans@cse.psu.edu Precedence: bulk Reply-To: 9fans >When PCI finally settles down and gets as reliable as 154x's on >the ISA bus, I'll move. Of course a good SCSI adapter design >would be nice. I hate the 294x. Does anybody have any experience >with the Qlogic board? (http://www.qlc.com) It looks like >a good alternative. i know of drivers available for 3 other controllers: buslogic (mylex) dpt ncr (symbios) 53c8xx series >From owner-9fans Wed Dec 31 02:05:50 1997 Received: (from majordom@localhost) by cse.psu.edu (8.8.8/8.7.3) id CAA18653 for 9fans-outgoing; Wed, 31 Dec 1997 02:05:50 -0500 (EST) X-Authentication-Warning: claven.cse.psu.edu: majordom set sender to owner-9fans using -f Received: from ns.dbSystems.com (root@ns.dbsystems.com [204.178.76.1]) by cse.psu.edu (8.8.8/8.7.3) with SMTP id CAA18649 for <9fans@cse.psu.edu>; Wed, 31 Dec 1997 02:05:45 -0500 (EST) Received: (from gdb@localhost) by ns.dbSystems.com (8.6.11/8.6.9) id AAA21094 for 9fans@cse.psu.edu; Wed, 31 Dec 1997 00:49:08 -0600 Date: Wed, 31 Dec 1997 00:49:08 -0600 From: "G. David Butler" Message-Id: <199712310649.AAA21094@ns.dbSystems.com> To: 9fans@cse.psu.edu Subject: Re: [9fans] Re: etherelnk3.c Sender: owner-9fans@cse.psu.edu Precedence: bulk Reply-To: 9fans >>When PCI finally settles down and gets as reliable as 154x's on >>the ISA bus, I'll move. Of course a good SCSI adapter design >>would be nice. I hate the 294x. Does anybody have any experience >>with the Qlogic board? (http://www.qlc.com) It looks like >>a good alternative. > >i know of drivers available for 3 other controllers: > buslogic (mylex) > dpt > ncr (symbios) 53c8xx series Thanks for the info. But how do those controllers compare to the Qlogic board or the Adaptec 294x? The QLogic board has two processors like the 154x and you only get one interrupt per SCSI command. (like the 174x. you can get many completed per interrupt on the 154x.) The 2940 gives interrupts as targets disconnect/reconnect! The host processor has to almost manage the SCSI bus directly. A 154x will even retry a command to a BUSY LUN for you without issuing another interrupt. On my systems I like to have as many SCSI busses as I can so I can have a reasonable number of targets per bus. So having many cards that need to be patted on the butt every time a target blinks is not good for getting any other work done, like servicing ethernet clients. I can put 4 154x's in a system with a P5/133 and have plenty of CPU to keep the ethernet lit. How many 2940's can you run with a P5/133 with targets disconnecting/reconnecting like crazy because of all the random I/O? >From owner-9fans Wed Dec 31 03:55:07 1997 Received: (from majordom@localhost) by cse.psu.edu (8.8.8/8.7.3) id DAA19374 for 9fans-outgoing; Wed, 31 Dec 1997 03:55:07 -0500 (EST) X-Authentication-Warning: claven.cse.psu.edu: majordom set sender to owner-9fans using -f Received: from symbionics.co.uk (symsun3.symbionics.co.uk [194.32.100.60]) by cse.psu.edu (8.8.8/8.7.3) with SMTP id DAA19369 for <9fans@cse.psu.edu>; Wed, 31 Dec 1997 03:55:02 -0500 (EST) Received: from symnt3.symbionics.co.uk by symbionics.co.uk (4.1/SMI-4.1) id AA17665; Wed, 31 Dec 97 08:54:39 GMT Received: by symnt3.symbionics.co.uk with SMTP (Microsoft Exchange Server Internet Mail Connector Version 4.0.995.52) id <01BD15C9.B71EA2D0@symnt3.symbionics.co.uk>; Wed, 31 Dec 1997 08:54:34 -0000 Message-Id: From: Nigel Roles To: "'9fans@cse.psu.edu'" <9fans@cse.psu.edu> Subject: RE: [9fans] Re: etherelnk3.c Date: Wed, 31 Dec 1997 08:54:32 -0000 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.995.52 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-9fans@cse.psu.edu Precedence: bulk Reply-To: 9fans >But how do those controllers compare to the Qlogic board or >the Adaptec 294x? > The Symbios (i.e. NCR as was) 8751SP controller out-performs the Adaptec 294x series. Also, it has full on-board auto termination, allowing any two busses (wide/narrow, internal/ external) to be connected without mucking around. Adaptec's major attraction in the marketplace has been the availability of ASPI drivers under Win95. This has now been fixed for Symbios as well (in OSR 2.1), to the extent that the Adaptec tools work with the Symbios controller. As for availability of fileserver drivers, the Symbios/NCR driver on my website (http://www.cotswold.demon.co.uk/plan9/dist/ncr/src) is #ifdef'ed for use as either a CPU or an FS driver. Indeed, it is used by myself, forsyth, and perhaps others (who knows) as a file server driver. I think forsyth used a word like 'brisk' or 'snappy' to describe the performance. You can use any controller from an original NCR810 right through to a Symbios 875 without change. As for an Adaptec 294x driver, I'm still working on it periodically. May be even today. >From owner-9fans Wed Dec 31 10:21:42 1997 Received: (from majordom@localhost) by cse.psu.edu (8.8.8/8.7.3) id KAA21683 for 9fans-outgoing; Wed, 31 Dec 1997 10:21:42 -0500 (EST) X-Authentication-Warning: claven.cse.psu.edu: majordom set sender to owner-9fans using -f Received: from plan9.bell-labs.com (plan9.bell-labs.com [204.178.31.2]) by cse.psu.edu (8.8.8/8.7.3) with SMTP id KAA21679 for <9fans@cse.psu.edu>; Wed, 31 Dec 1997 10:21:38 -0500 (EST) Message-Id: <199712311521.KAA21679@cse.psu.edu> To: 9fans@cse.psu.edu Date: Wed, 31 Dec 1997 10:10:51 -0500 From: "jim mckie" Subject: Re: [9fans] Re: etherelnk3.c Sender: owner-9fans@cse.psu.edu Precedence: bulk Reply-To: 9fans >But how do those controllers compare to the Qlogic board or >the Adaptec 294x? The QLogic board has two processors like >the 154x and you only get one interrupt per SCSI command. >(like the 174x. you can get many completed per interrupt on the >154x.) The 2940 gives interrupts as targets disconnect/reconnect! >The host processor has to almost manage the SCSI bus directly. >A 154x will even retry a command to a BUSY LUN for you without >issuing another interrupt. the buslogic, ncr and dpt controllers do everything the 154x does, and more. ngr has answered about the ncr controllers, and i've used them without problem. the buslogic controllers are available in isa, eisa and pci, narrow/wide/differential. they are software compatible with the 154x but the eisa and pci have a 32-bit extended mode. we use one driver for all 154x and buslogic cards, the only thing it has to deal with differently on configuration is if it's a 1542c/cf which has the mbox-lockout 'feature'. >From owner-9fans Wed Dec 31 12:20:09 1997 Received: (from majordom@localhost) by cse.psu.edu (8.8.8/8.7.3) id MAA22979 for 9fans-outgoing; Wed, 31 Dec 1997 12:20:09 -0500 (EST) X-Authentication-Warning: claven.cse.psu.edu: majordom set sender to owner-9fans using -f Received: from mailbox1.ucsd.edu (mailbox1.ucsd.edu [132.239.1.53]) by cse.psu.edu (8.8.8/8.7.3) with ESMTP id MAA22970 for <9fans@cse.psu.edu>; Wed, 31 Dec 1997 12:20:03 -0500 (EST) Received: from jewel.ucsd.edu (jewel.ucsd.edu [132.239.121.100]) by mailbox1.ucsd.edu (8.8.5/8.6.9) with SMTP id JAA22142 for <9fans@cse.psu.edu>; Wed, 31 Dec 1997 09:20:01 -0800 (PST) Received: by jewel.ucsd.edu (SMI-8.6/SMI-SVR4) id JAA03110; Wed, 31 Dec 1997 09:14:36 -0800 Date: Wed, 31 Dec 1997 09:14:36 -0800 From: eld@jewel.ucsd.edu (Eric Dorman) Message-Id: <199712311714.JAA03110@jewel.ucsd.edu> To: 9fans@cse.psu.edu Subject: Re: [9fans] Re: etherelnk3.c X-Sun-Charset: US-ASCII Sender: owner-9fans@cse.psu.edu Precedence: bulk Reply-To: 9fans > To: 9fans@cse.psu.edu > Date: Tue, 30 Dec 1997 21:41:15 -0500 > From: "jim mckie" > Subject: Re: [9fans] Re: etherelnk3.c > > >Of course the current support in the fs is for pretty slow > >scsi controllers, from what I've seen. One could stick a > >PCI controller that looks like an AHA1542 in there but the > >driver wouldn't utilize 32-bit addressing, forcing the use of > >bounce buffers... hmm, didn't some of the VLB cards have > >a larger address space? > > this has been gone over before on the list. given the buslogic eisa controller > driver in the fs kernel (which is no slouch), it's trivial to make a buslogic > pci > controller work in 32-bit mode; that's what we use. > --jim Yep; I did it with mine before it died due to an internal defect ( :< ). Regards, eric