From: Digestifier To: Linux-Development@senator-bedfellow.mit.edu Reply-To: Linux-Development@senator-bedfellow.mit.edu Date: Thu, 28 Oct 93 05:13:19 EDT Subject: Linux-Development Digest #194 Linux-Development Digest #194, Volume #1 Thu, 28 Oct 93 05:13:19 EDT Contents: Is RARP support in the Net code, yet ? (Alec Muffett) Re: 2.88MB support? (was Re: 1.72MB floppies) (David C. Niemi) PCMCIA Xircom Ethernet driver? (Kwun Han) Help on the Use of SyQuest with DOS/LINUX, Please!!! (Mr K G Zheng) Re: Slowness in scsi disk access (Brandon S. Allbery) Re: Linux Astronomy update? (Dierick Dominique) Re: Slowness in scsi disk access (Jonathan Stockley) Re: Bugs in Quota-Patches (SLS 1.03, 0.99pl12) (Kai Kretschmann) Re: ugly name for core dumps (core.imagename) -> patch for "img.core" (Rui Pedro Mendes Salgueiro) Re: Slowness in scsi disk access (Piercarlo Grandi) [Q] Comtrol "Smart Hostess" serial card under Linux? (Jon Scheer) Re: Andrew File System (Salvatore Valente) Re: ugly name for core dumps (core.imagename) -> patch for "img.core" (Brandon S. Allbery) [Q] microsoft bus mouse problems under linux (RLAW@DELPHI.COM) Pentium and PCL ---------------------------------------------------------------------------- From: alecm@uk-usenet.uk.sun.com (Alec Muffett) Subject: Is RARP support in the Net code, yet ? Date: 27 Oct 1993 14:41:06 GMT Reply-To: alecm@uk-usenet.uk.sun.com Simple question, in the subject line. - The thing is, what with my recent purchase of a decent 486, if RARP's working, I'll volunteer to hack rarpd & tftpd into working order... I happen to know this place I can get really cheap suns (8-), and the prospect of running xkernel on one or more old 3/80s around the house, is REALLY enticing. 8-) - alec ------------------------------ From: niemidc@oasis.gtefsd.com (David C. Niemi) Subject: Re: 2.88MB support? (was Re: 1.72MB floppies) Date: 27 Oct 1993 15:27:12 GMT Reply-To: niemidc@oasis.gtefsd.com In article 7761@minster.york.ac.uk, al-b@minster.york.ac.uk writes: [...] >What about support for 2.88MB drives? Is that in the kernel now, or is it a >patch? I am still using a 0.99.9 kernel with the 1.72MB patch, as I still >haven't decided on how to upgrade... Some aspects of 2.88MB support are in the pl13 kernel (and it hasn't changed much in a while). However, they do not work (failures when trying to read). In order to clean up the floppy driver sufficiently to support 2.88MB drives, and also to permit floppy tape support, Sam Chessman and I are completely rewriting the floppy driver. It is a big task, stay tuned... Anyone who wants to help, let me know by e-mail. --- David C. Niemi Life is just an unintended side effect of reproduction. David.Niemi@oasis.gtegsc.com ------------------------------ From: kwh@cs.brown.edu (Kwun Han) Subject: PCMCIA Xircom Ethernet driver? Date: Wed, 27 Oct 1993 16:52:33 GMT Hi Linux hackers, I am wondering if there are any drivers available for the Xircom PCMCIA ethernet card around? or does the current ethernet driver support that (I don't think it will, but I will ask anyways). If someone have any success using that card in their notebooks, I would like to know how.. thanks a lot!! Kwun ***************************************************************** |/\ /| ||\ | -0-0- |\ \/\/ |_|| \| \_/ kwh@cs.brown.edu Box #2392, Brown University, ST002255@brownvm.brown.edu Providence, RI 02912 Kwun_Han@brown.edu ***************************************************************** ------------------------------ From: esrqy@csv.warwick.ac.uk (Mr K G Zheng) Subject: Help on the Use of SyQuest with DOS/LINUX, Please!!! Date: 27 Oct 1993 16:23:04 -0000 Hello, SyQuest users! I have a Toshiba T1900C Laptop and I am attempting to connect a SyQuest drive for 105Mb 3.5in disks, supplied by Spin Peripherals Inc., to it. So far, I only have the SyQuest drive, and the Mac driver (which is useless for me!) I wonder if anyone has any advice on the following queries: a) Is there any way to format the SyQuest (105Mb) for DOS/LINUX? If so, where can I get the program? b) Can anyone recommend any PCMCIA SCSI adapters so that I can use the SyQuest with DOS/Linux? Thank you very much indeed in advance for your help. Please reply to: kz2@uk.ac.le or esrqy@uk.ac.warwick.csv George. ------------------------------ From: bsa@kf8nh.wariat.org (Brandon S. Allbery) Subject: Re: Slowness in scsi disk access Date: Wed, 27 Oct 1993 15:59:51 GMT In article <2akp4m$igh@uniwa.uwa.edu.au> oreillym@tartarus.uwa.edu.au (Michael O'Reilly) writes: >Piercarlo Grandi (pcg@aber.ac.uk) wrote: >: Flushing every 30 sec. or was OK on a PDP-11 with 64 buffers if one was >: lucky. With several thousand one should do like SVR[34], and have a >: flushing daemon that sweeps cyclically thru the buffers and cleans them >: incrementally. > >As other people have mentioned, this is a good idea. Implementation >anyone? :) Eric and I are talking it over in mail to come up with a decent algorithm. He'll probably send something to the KERNEL channel when we know what we're doing :-) ++Brandon -- Brandon S. Allbery kf8nh@kf8nh.ampr.org bsa@kf8nh.wariat.org "MSDOS didn't get as bad as it is overnight -- it took over ten years of careful development." ---dmeggins@aix1.uottawa.ca ------------------------------ Crossposted-To: comp.os.linux.help,comp.os.linux.misc From: dierick@brsux0.bro.dec.com (Dierick Dominique) Subject: Re: Linux Astronomy update? Reply-To: dierick@ketje.enet.dec.com Date: Wed, 27 Oct 1993 17:34:50 GMT In article <2adt91$1v7@organpipe.uug.arizona.edu>, ron@argus.lpl.Arizona.EDU (Ron Watkins) writes: >From: ron@argus.lpl.Arizona.EDU (Ron Watkins) >Newsgroups: comp.os.linux.help,comp.os.linux.misc,comp.os.linux.development >Subject: Linux Astronomy update? > >Im looking for the last mail message that went out the astronomy update for >Linux. I have recieved a request for information about IRAF and SAOimage >which I saw on the last astronomy update. I don't seem to have it in my mail >archive though. Could someone please forward that to me again. Thanks, > Ron - ron@argus.lpl.arizona.edu >-- >Ron Watkins [ron@argus.lpl.arizona.edu] / /~~~~) / >931 Gould-Simpson / /____/ / >University of Arizona / / / >Tucson AZ. 85721 -- (602) 621-8606 (____ unar & / lanetary (____ ab. > I'm looking for astronomy tools on Linux too. Please post here if you have ftp sites for star charting software and CCD camera image processing software ( *not* xv ). Thanks. Dominique Dierick ------------------------------ From: jvs@netcom.com (Jonathan Stockley) Subject: Re: Slowness in scsi disk access Date: Wed, 27 Oct 1993 20:23:14 GMT In article eric@tantalus.nrl.navy.mil (Eric Youngdale) writes: > Someone else suggested a builtin task in the kernel that does >this job. This would be relatively easy and doable, I suppose. I would >be curious how other people feel about builtin tasks in the kernel, >however. > I think this is what SVR3 called the "buffer dribbler" or bdflush. It is tunable in that you can configure how often it runs and what percentage of the buffer cache it scans for dirty buffers. If you set it to 30 seconds and 100% you get .... sync()! I played around with this quite a bit under Motorola's SYSV/88 SVR3 system. I will, if/when I get time, hack this into linux. I will let you know what comes out. Jo -- ======================================================================== Jo Stockley jvs@netcom.com jonathan@sybase.com Happy, Happy, Happy... Joy, Joy, Joy! ======================================================================== ------------------------------ From: kai@fix.kmk.rhein-main.de (Kai Kretschmann) Subject: Re: Bugs in Quota-Patches (SLS 1.03, 0.99pl12) Date: Wed, 27 Oct 1993 16:40:53 GMT =====BEGIN PGP SIGNED MESSAGE===== Marco van Wieringen (mvw@hacktic.nl) wrote: : Can you be more specific about what happens, I will take a look : but a bit more specific error makes life much easier. Not so easy to give an exact error msg when the system is totally down :-( I enabled user-quota, let my incoming uucp-call login, all working. When the uucp-commection is ended, the system locks up! This means I still can switch between various vc's, but if I try to login on one, the password prompt doesn't come. In logged in sessions I cannot type anything. Even the "AltGr-Roll" Key to get the register contents doesn't work, same with CAD. Big Red Switch Time. Without activated qouta, no problem at all. The uucp has a normal user id to logon, something above 400. So this isn't the source of error I first thought of. My Qouta-Patches were for pl12, which is what I'm using. I have some other patches incuded, too. Like the last IDE 8Sector read, the very short pl12+ patch from linus, another text resolution. All this stuff seems to work without any problem. BTW: The starting poster gave a patch to qouta which actually removed one bug here: Until now I couldn't umount some partitions, they claimed to be busy, even in single user mode! After the patch my shutdown works again! Thanks for these two tiny little lines. =====BEGIN PGP SIGNATURE===== Version: 2.3 iQCVAgUBLM6kjCav0VI73L8VAQHAjQP/dUYc2/isBqr/wsSMpyOrm5AYcVLhxElv kw6KGnG1Rly4eMClhTt33cc/vfIOaqlqPiiabYsToVPY/utZKtGeuRDT61FtULIS 9SROwFlIVymo2uTuRRlajP7lVEn0XvXZq3n4GypxlR7BXAnbaGsKbVDYaVv2rWcx CXsFxbmEKQ8= =DICW =====END PGP SIGNATURE===== -- Kai Kretschmann, >>> FidoNet: 2:248/312, 21:100/5729, 16:100/6006 <<< >>> Internet: kai@fix.kmk.rhein-main.de <<< >>> FAX/BBS: +49-6172-305379 <<< ------------------------------ From: rps@matuc2.mat.uc.pt (Rui Pedro Mendes Salgueiro) Crossposted-To: comp.os.386bsd.development,alt.os.bsdi Subject: Re: ugly name for core dumps (core.imagename) -> patch for "img.core" Date: 27 Oct 93 17:00:50 GMT This discussion has already taken place in the BSD/386 mailing list (some of the participants included ex-CSRG members). Conclusions (according to my recollection): 1 - 'name.core' is better than 'core.name', but now is a little late to change things. 2 - 'core.name.pid' is dangerous. The reason to use 'core.name' instead of 'core' is not to make it easier to discover which program has dumped core (use file(1) for that) but to prevent a core from some daemon to overwrite other cores. The problem with 'core.name.pid' is that a daemon launched from init or inetd that always dumped core could fill the root partition. And if you want to be sure that no core is overwritten the proper way would be something like 'core.name.time_in_us' (pids wrap around after ~30000). For BSD/386 someone has made a "commitee solution" patch. With this patch the behaviour is selectable when the kernel is configured. -- Rui Salgueiro | Dpt. de Matematica |"In my life / Why do I smile rps@mat.uc.pt | Universidade de Coimbra | at people who I'd much rather rps@inescc.pt | Portugal - Europe | kick in the eye" - Morrissey ------------------------------ From: pcg@aber.ac.uk (Piercarlo Grandi) Subject: Re: Slowness in scsi disk access Reply-To: pcg@aber.ac.uk (Piercarlo Grandi) Date: Wed, 27 Oct 1993 21:41:57 GMT >>> On 27 Oct 1993 03:15:34 GMT, oreillym@tartarus.uwa.edu.au (Michael >>> O'Reilly) said: Eric> The simulated I/O rates dropped from something in excess of Eric> 1Mb/sec to something close to 32Kb/sec. The cause in this Eric> particluar instance was quite simple - the first 2/3 of the Eric> buffers in the free list were dirty, and each time we call getblk Eric> we end up traversing all of these to locate a clean buffer. pcg> Use a free list. Michael> It IS using a free list. Have you looked at the kernel source?? Ah sure, it is a 'free list' that might have 15,000 non-free buffers: Eric> [ ... ] It takes something like 50ms to scan 15000 buffer headers Eric> like I have on my system, so this overhead can eat you alive. pcg> So don't do it. Michael> This is trite and stupid. it doesn't normally search all the Michael> buffers, thats just the worst case and there IS no way around Michael> it. Later on you have statistics that state that only in 15% of cases a request for a buffer is satisfied by looking at the first one in the inaptly named 'free list'. WHAT? It has to *scan* the free list for a buffer? Cannot it just take the first buffer and run scared? WHY? :-) :-) Searching the free list? Just Say No. Michael> A much-vaunted 'free list' doesn't help if it's empty. But at least one does not have to scan 15,000 entries (which costs 50ms) on the 'free list' just to discover it is empty. Also, scanning for a clean buffer is very, very bad -- this victimizes clean buffers in preference to dirty ones, and is a no-no. Ideally the free list, and indeed the whole buffer cache (and no 'free list' should exist, perhaps), should be sorted in some definite order, say LIFO, and the get-me-an-empty-buffer logic should choose the buffer to reuse solely on the basis of its expected reaccess profile. Easier said than done, perhaps, but given that people are willing to muck around with this, it would be nice that it were done "right". BTW, even with the current design, a suitable heuristic might be: if a suitable buffer is not say within the first N (N perhaps between 50 and 100) withing the free list, just allocate new space. But perhaps this is an expensive operation. ------------------------------ From: scheer@rtsg.mot.com (Jon Scheer) Crossposted-To: comp.os.linux.help,comp.os.linux.misc Subject: [Q] Comtrol "Smart Hostess" serial card under Linux? Date: 27 Oct 1993 21:28:57 GMT Greetings, I recently picked up a Comtrol "Smart Hostess" card (older rev A card) and am hoping to get it working under Linux. I've looked through the FAQ, HOWTO's, Device lists, etc and I see that the Smart Hostess isn't currently supported under Linux. My question is: is anyone working/planning on getting a Smart Hostess (or any other Comtrol serial card) up and running under Linux? There seems to be a fair amount of techie/programming information in the User's Guide so I would imagine that it's in the realm of possibility. (I've done a fair share of hardware & low level software development -- it's mostly a matter of finding the time to write the driver :-) Does anyone run a Smart Hostess card under any other operating systems? (Yes, I know this is a Linux newsgroup, but I'm looking for any/all info :-) I also have some Smart Hostess specific questions. I've talked with the folks at Comtrol (they were *very* nice and *very* helpful). They answered some questions, but most of the stuff they have is for the newer cards or newer versions of older cards (I think the "Smart Hostess" is up to revision F -- I have rev A circa 1985). They are going to try dig up some info about the rev A card and ship it off to me, however I am curious to know if anyone is running this older card, how it performs, etc... advTHANKSance. Jon 10/27/93 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Work: scheer@rtsg.mot.com Home: wombat@outback.chi.il.us "Have opinion; Will post." -- ------------------------------ From: svalente@ATHENA.MIT.EDU (Salvatore Valente) Subject: Re: Andrew File System Date: 28 Oct 1993 08:27:10 GMT Lots of random people have written: > AFS is the intellectual property of Transarc corp. A clone *might* be > possible, but lacking source, it might be hard to write without being > plagaristic; it's pretty sophisticated. AFS specs exist. The code would have to be written from scratch, based just on the specs. Sounds kind of like the kernel of a certain operating system kernel we all know and love. That is, it can be done. > AFS sucks anyways. Use NFS :-) Theoretically, AFS is more powerful than NFS. AFS has lots of cool design features. I would talk about the implementation, but I'm not really in a Transarc flaming mood right now. Maybe later. > AFS would be better than NFS, but I don't see what is the point of trying > to be compatible with AFS which isn't used anywhere AFS _is_ used. At my little college, almost all files are in AFSland. I want to be able to access those files from my Linux box. (Many of the public workstations are Solaris, so you can see how important my Linux box is to me. :-) > You can probably get by with the AFS to NFS translator. Now I'm in a Transarc flaming mood. The translator sucks! It erases random files, it crashes often, it's slow, it's truncated my RMAIL file to zero bytes several times... It's really quite bad. > And why are they locked out? AFS is available for a variety of > platforms. They are locked out because some people (like us nutty Linux users) want to put non-AFS supported systems on networks containing mostly AFS-supported systems (like my schools campus network). > a) AFS filesystems are not Unix filesystems > b) the implementation quality of AFS is poor" > Most users tend to be happy about all the features AFS promises when they > start using AFS, but a significant number of people are seriously hacked off > after some months of adminstering or using AFS. Fine, so it should be reimplemented. The point of this message is: I'd really like to see a freely distributable AFS client, and if anyone out there is working on one, I'd be more than happy to help test and (in my copious spare time) develop it. -- /* Sal Valente */ /* All opinions stated here are shared by my school, my employer, my */ /* friends, my family, a large group of people I've never met, the */ /* entire cast of "Taxi," President Clinton, the Pope, Elvis, and you. */ ------------------------------ Crossposted-To: comp.os.386bsd.development,alt.os.bsdi From: bsa@kf8nh.wariat.org (Brandon S. Allbery) Subject: Re: ugly name for core dumps (core.imagename) -> patch for "img.core" Date: Wed, 27 Oct 1993 23:40:25 GMT In article <1993Oct27.170050.1573@matuc2.mat.uc.pt> rps@matuc2.mat.uc.pt (Rui Pedro Mendes Salgueiro) writes: > 1 - 'name.core' is better than 'core.name', but now is a little > late to change things. If all you care about is BSD 4.4 compatibility, maybe. The Linux folks debating this don't necessarily need to be bound by that.... ++Brandon -- Brandon S. Allbery kf8nh@kf8nh.ampr.org bsa@kf8nh.wariat.org "MSDOS didn't get as bad as it is overnight -- it took over ten years of careful development." ---dmeggins@aix1.uottawa.ca ------------------------------ From: rlaw@news.delphi.com (RLAW@DELPHI.COM) Subject: [Q] microsoft bus mouse problems under linux Date: 27 Oct 1993 20:43:45 -0400 I recently installed linux version .99.6 with xfree86 1.2. I had problems getting my microsoft inport/bus mouse working. I checked the source code and noticed that the irq level was hardcoded to 5. I powered down my machine and configured the mouse at irq 5 and now the mouse works. The problem is that it is way to hypersenstive. I tried using xset m without sucess. I noticed that when linux would come up my machine would recongnized 4 different types of bus mice. So a re-built the kernel with make config with only the microsoft bus mouse enabled. My keyboard came upin danish, so I had to edit the Makefile to configure it to be a north american keyboard, recompile and reboot. Now my keyboard works fine, X comes up and the darn mouse is still hyper-sensitive. Now when I try to do a ctrl-alt-backspace my monitor goes crazy. Should I upgrade to another version of linux and xfree86 ? Someone else had the same problem with their mouse and recompiling the kernel fixed the problems. For those of you that have linux and X working properly with a microsoft bus mouse, what version of linux do you have and what version of xfree86 do you have ? I don't want to have to spend big bucks on a commerical unix/os for my pc at home. My mouse works fine under windows nt and dos. Reggie ------------------------------ Date: Wed, 27 Oct 1993 17:31:01 EDT From: Subject: Pentium and PCL Hello. Recently, the PCL machines have hit the market. The claim is that they are better than the VESA machines. I'd like to know if linux can be directly used on the PCL machines or that'll require some work? Pentium chip should be ok since it is still a x86 chip. Agreed? Thanks a lot. Sean. ------------------------------ ** FOR YOUR REFERENCE ** The service address, to which questions about the list itself and requests to be added to or deleted from it should be directed, is: Internet: Linux-Development-Request@NEWS-DIGESTS.MIT.EDU You can send mail to the entire list (and comp.os.linux.development) via: Internet: Linux-Development@NEWS-DIGESTS.MIT.EDU Linux may be obtained via one of these FTP sites: nic.funet.fi pub/OS/Linux tsx-11.mit.edu pub/linux sunsite.unc.edu pub/Linux End of Linux-Development Digest ******************************