Subject: Linux-Development Digest #557 From: Digestifier To: Linux-Development@senator-bedfellow.MIT.EDU Reply-To: Linux-Development@senator-bedfellow.MIT.EDU Date: Wed, 16 Mar 94 08:13:06 EST Linux-Development Digest #557, Volume #1 Wed, 16 Mar 94 08:13:06 EST Contents: Adaptec 2742T anyone? (David Rapchun) Re: TTY overruns cost money. (Nemosoft Unv.) Re: Amiga File System, once again (Hamish Macdonald) Re: Amiga FileSystem, Anyone? (David Holland) Re: YP or NIS for linux? (John F. Haugh II) Re: YP or NIS for linux? (John F. Haugh II) Re: A truely non-debugging Kernel? (John F. Haugh II) Re: YP or NIS for linux? (John F. Haugh II) Re: Amiga FileSystem, Anyone? (Kai Henningsen) Re: DIP: tty: getc: I/O error (Christian Henry) Re: Andrew 6.1 for Linux: who did it? (Doug DeJulio) Re: TTY overruns cost money. (Kevin Lentin) Fooling with the timer interrupt (Milind Paranjpe) Fonts, keyboards, mice - a proposal (Jamie Honan) [Q] Adaptec 2842 SCSI driver yet? (Mark Biegler) ---------------------------------------------------------------------------- From: rapchun@suicide.sdsu.edu (David Rapchun) Subject: Adaptec 2742T anyone? Date: 15 Mar 1994 01:24:07 GMT Hello, I understand there are some people working on writing a driver for the Adaptec 7770 series chip. IE, the 2742 and 2842 both use this new chip. I was just wondering how the work is coming along since I would really like to run Linux soon. Thanx. Dave. -- ******************************************************************************* * rapchun@mintaka.SDSU.edu Dave Rapchun * ******************************************************************************* ------------------------------ From: nemosoft@void.tdcnet.nl (Nemosoft Unv.) Subject: Re: TTY overruns cost money. Date: Tue, 15 Mar 1994 02:56:03 GMT In article tgm@netcom.com (Thomas G. McWilliams) writes: >Kai Petzke (wpp@marie.physik.tu-berlin.de) wrote: >: However, if overruns happen on every single move with the mouse, >: there should be something wrong with the kernel. > >The more likely problem is that the mouse was given a higher >priority interrupt than the modem. The modem should always be >given interrupt 3 if possible--this is naturally the case if you >use /dev/cua1 for your modem. Pardon ?? All interrupts are handled at the same priority... There's no such thing as a precedence for modems on certain serial ports... I'm afraid your confusing interrupts with i386 microcode priviledge levels, or something. Anyway, my questions still stand: why is now all this attention payed to some vague bit that tells me something is overrunning, while I obviously loose no data, and why am I even bothered by them at 2400 baud ? That's ridiculous. I've never seen any MS-DOS comm-program bitch about overruns, not even at extreme high speeds like 115200 baud on an 8088 XT. And then I didn't loose a single byte ! Why is it that the Linux serial drivers suddenly seem to be so broken down, in comparison with this ? Maybe we should turn back to some good-ol' assembler code ? However, I credit you in 1 thing: support to share COMports on IRQs. But even there things are weird. For example: my mouse for X is on ttyS6 (1200 buad) (COM7 *cheer*), using IRQ3. So is my modem at ttyS3 (2400 baud). Now these combinations work or don't: kermit on /dev/cua3, 2400 baud, 8N1 : mouse hangs. uucico dial out on /dev/cua3, 2400 baud, 8N1 : mouse rolls happily DIP on /dev/cua3, 2400 baud, 8N1 : DIP input gets eaten a bit uugetty on /dev/cua3, 2400 baud, 8N1 : mouse hangs. Now you find the differences, and tell me what's wrong. Note that the only point where mouse & modem "meet" is in /linux/drivers/char/serial.c where the interrupt handlers are. Even something simple as opening the device from kermit will hang the mouse, then I'm not even 'c'onnected to it.... *seriously considers of throwing out this cereal.c and start from scratch* - Nemosoft ------------------------------ From: Hamish.Macdonald@bnr.ca (Hamish Macdonald) Subject: Re: Amiga File System, once again Date: 15 Mar 1994 04:18:11 GMT >>>>> On 14 Mar 1994 05:07:37 EST, >>>>> In message , >>>>> armb@setanta.demon.co.uk (Alan Braggins) wrote: Alan> Are you saying both the Linux and AmigaDOS versions of the Amiga file Alan> system will already work on PC-formatted floppies Yes. Most PC-format support programs on the Amiga (MultiDOS and MSH at least; I'm not sure about cross-dos) allow the use of the Amiga Fast Filesystem on a 720K floppy. The Linux "affs" support should allow you to read the filesystem from a 720K floppy, if you give "mount" the right options (size/root block). ------------------------------ Subject: Re: Amiga FileSystem, Anyone? From: dholland@husc7.harvard.edu (David Holland) Date: 15 Mar 94 15:54:06 kai@khms.westfalen.de's message of 14 Mar 1994 23:54:00 +0100 said: > > True. But it's not real workable as an easy general solution - > > That's because > 1. DOS is single-tasking single-address-space > 2. 640K is not a lot of memory for today's programs. > > There *is* no simple solution to these problems. Yup... > > Well, that's broken, and makes it impossible for DOS to really use > > most other filesystems. :-) > > Hmm. Now, why have I seen DOS "use" lots of file systems that weren't 8+3? > Of course, using various work-arounds, like only seeing some files, or > inventing new names on the fly. Not nice - but for a CP/M-clone, it's > quite impressive. Note I said *really* use. :-) Ending up with filenames like EMAC~BIN.T~Z, or worse, just isn't my idea of really working... I agree it's quite impressive that it can be done at all. Saying that was what triggered this entire thread... > > So when is the ext2fs for DOS going to be ready? :-] > > Hmm. Now, how large would that be? Could we do something useful with it > without using a DOS-extender? :-) Doubtful... -- - David A. Holland | "The right to be heard does not automatically dholland@husc.harvard.edu | include the right to be taken seriously." - - - - - - - - - - This message shall NOT be quoted or copied out of the electronic medium in which it originated without explicit permission from the author. ------------------------------ From: jfh@rpp386 (John F. Haugh II) Subject: Re: YP or NIS for linux? Reply-To: jfh@rpp386.cactus.org (John F. Haugh II) Date: Tue, 15 Mar 1994 04:09:17 GMT In article <2lv16t$7nk@celsius.ifm.liu.se> peter@ifm.liu.se (Peter Eriksson) writes: >And what do you do if the DBM databases are corrupt and causes >/bin/login to core dump? (Atleast one version of GDBM had the >nasty habit of calling abort() if it detected something wrong >with its database files). > >One can always find situations where there will be problems >and no way of doing things (DBM, YP, NIS+, DNS/Hesiod) will >ever be perfect. Problems such as this are readily solvable in the permanent sense. When a YP server goes down, you can't reboot it and expect it to stay up forever. I don't use YP on any system were availablity is an issue. I don't even rely on AFS or NFS on critical systems. There is no substitute for having the data right here, right now. -- John F. Haugh II [ NRA-ILA ] [ Kill Barney ] !'s: ...!cs.utexas.edu!rpp386!jfh Ma Bell: (512) 251-2151 [GOP][DoF #17][PADI][ENTJ] @'s: jfh@rpp386.cactus.org There are three documents that run my life: The King James Bible, the United States Constitution, and the UNIX System V Release 4 Programmer's Reference. ------------------------------ From: jfh@rpp386 (John F. Haugh II) Subject: Re: YP or NIS for linux? Reply-To: jfh@rpp386.cactus.org (John F. Haugh II) Date: Tue, 15 Mar 1994 04:12:45 GMT In article <2lvm8p$2hu@finnegan.iol.ie> barryf@iol.ie (Barry Flanagan) writes: >jfh@rpp386 (John F. Haugh II) wrote: >>I have spoken with people who use DBM files to support >>/etc/passwd files with upward of 30,000 users. I'm >>not aware of any scalability problems with DBM files. >>I am aware of problems pushing YP maps that are that >>size. >>-- > >I would really appreciate some pointers to more information on >this. It appears that NIS (at least on SCO) becomes very flakey >with upwards of 100 users, which seems to me to defeat the >purpose of NIS. > >I need to share passwd/shadow files between different types of >Unix (currently SCO, Solaris and Linux) and need to be able to >add many users. I don't know of specific problems, but the most common is that some systems don't know how to incrementally update a map. One of the big advantages that Shadow has had over the commercial vendors is that chfn, chsh and passwd -- all the heaviest I&A file updates -- have long supported incremental file updates for the DBM files. The problem, as it relates to NIS, is that the maps either take forever to recreate, copy, or whatever, or they stay out of date for long periods of time. As for SCO, toss it out and get something real. SCO UNIX isn't UNIX. -- John F. Haugh II [ NRA-ILA ] [ Kill Barney ] !'s: ...!cs.utexas.edu!rpp386!jfh Ma Bell: (512) 251-2151 [GOP][DoF #17][PADI][ENTJ] @'s: jfh@rpp386.cactus.org There are three documents that run my life: The King James Bible, the United States Constitution, and the UNIX System V Release 4 Programmer's Reference. ------------------------------ From: jfh@rpp386 (John F. Haugh II) Subject: Re: A truely non-debugging Kernel? Reply-To: jfh@rpp386.cactus.org (John F. Haugh II) Date: Tue, 15 Mar 1994 04:14:50 GMT In article <1994Mar13.205037.24215@unlv.edu> ftlofaro@unlv.edu (Frank Lofaro) writes: >Well what do you do then if the kernel suddenly goes bonkers one day, >and clobbers you /usr partition or something awful like that?! >Commerical un*xes have sanity checks, etc, why shouldn't Linux? Plus, if >you have a very intermittent problem, the debug stuff might make it >possible to find out what it is, else you'll never know. You'd have to >recompile with debugging after the fact and wait for it to happen again. >That might be an uncomfortable wait for those with mission-critical or >security related problems. When I was a developer on AIX v3.1 a few years back, we reached a point where they turned off a lot of the macros controller those sanity checks. The idea isn't that you install "new and buggy" kernel today with the #ifdef's all turned off. The idea is that you prove to yourself that "new and buggy" is really "old and reliable" THEN you turn off the #ifdef's. -- John F. Haugh II [ NRA-ILA ] [ Kill Barney ] !'s: ...!cs.utexas.edu!rpp386!jfh Ma Bell: (512) 251-2151 [GOP][DoF #17][PADI][ENTJ] @'s: jfh@rpp386.cactus.org There are three documents that run my life: The King James Bible, the United States Constitution, and the UNIX System V Release 4 Programmer's Reference. ------------------------------ From: jfh@rpp386 (John F. Haugh II) Subject: Re: YP or NIS for linux? Reply-To: jfh@rpp386.cactus.org (John F. Haugh II) Date: Tue, 15 Mar 1994 04:25:54 GMT In article <2lv0tp$7m3@celsius.ifm.liu.se> peter@ifm.liu.se (Peter Eriksson) writes: >In NYS I've made one extension and that is to use /etc/passwd as a >source for Shadow information if the file /etc/shadow doesn't exist >so one can have _one_ /bin/login binary that works with or without >the file "/etc/shadow". Peter -- KNOCK, KNOCK -- Peter, you can do that with Shadow RIGHT NOW. TODAY. You can even do it with SVR4's /bin/login. TODAY. You've made up an extension and if that is the justification, there is no reason for it. I'm telling you -- and I've been doing this particular collection of bizarre software for several years longer than you so you really should pay attention here -- what you are doing is just a bad idea. There is value in knowing if there is an /etc/shadow entry, even if the entry came from /etc/shadow on some other machine. There is value in being able to use getspnam() on every machine that supports /etc/shadow, even if that /etc/shadow can be on some other machine. Your change REMOVES that value. >Even if I hadn't made that extension then one still would have to >find out from which source the data comes if one wants to modify it >and send it back. So what's the big deal with my addition to the >functionality? I've not checked, but my guess is that you provide no means for determining if the YP entry came from over the wire or locally. Am I correct? >NDBM has a very big limitation. Namely the 4096 bytes / key-value pair >limit. One thing I've tried to avoid in NYS is stupid builtin limitations >like that. As much as I hate to say this, Shadow using NDBM does not have the 4096 byte key/value pair limitation for /etc/group (which is about the only place anyone runs into it). -- John F. Haugh II [ NRA-ILA ] [ Kill Barney ] !'s: ...!cs.utexas.edu!rpp386!jfh Ma Bell: (512) 251-2151 [GOP][DoF #17][PADI][ENTJ] @'s: jfh@rpp386.cactus.org There are three documents that run my life: The King James Bible, the United States Constitution, and the UNIX System V Release 4 Programmer's Reference. ------------------------------ Date: 14 Mar 1994 23:54:00 +0100 From: kai@khms.westfalen.de (Kai Henningsen) Subject: Re: Amiga FileSystem, Anyone? dholland@husc7.harvard.edu wrote on 13.03.94 in : > True. But it's not real workable as an easy general solution - That's because 1. DOS is single-tasking single-address-space 2. 640K is not a lot of memory for today's programs. There *is* no simple solution to these problems. > I mean that Microsoft won't support it. Microsoft has been known to > intentionally change these things to try to break somebody else's > program. Maybe the existence of Novell DOS will stop them now, maybe > not; who knows? They have even done this with normal DOS. That's Microsoft to you. :-( > > 3. *Of course* you are limited to 8+3 - that's DOS's *concept* of a > > filesystem. > > Well, that's broken, and makes it impossible for DOS to really use > most other filesystems. :-) Hmm. Now, why have I seen DOS "use" lots of file systems that weren't 8+3? Of course, using various work-arounds, like only seeing some files, or inventing new names on the fly. Not nice - but for a CP/M-clone, it's quite impressive. > > 4. Various programs are either not suitable for working with anything but > > a FAT file system, because they know too much about it, or else have > > stupid bugs. It's the same with, say, Unix & NFS. > > True... > > > NETX is simply stone-age code. > > That's obviously the case. It seems the state of the art has managed > to improve a bit since I last really paid attention to the DOS world > (which wasn't all that long ago, before everybody jumps down my throat.) A bit, yes. > Evidently. Isn't it amazing how much easier it when people explain > instead of just saying "you're an idiot"? Definitely. > So when is the ext2fs for DOS going to be ready? :-] Hmm. Now, how large would that be? Could we do something useful with it without using a DOS-extender? :-) Kai -- Internet: kh@ms.maus.de, kai@khms.westfalen.de Bang: major_backbone!{ms.maus.de!kh,khms.westfalen.de!kai} ## CrossPoint v2.93 ## ------------------------------ From: henryc@reality.UUCP (Christian Henry) Subject: Re: DIP: tty: getc: I/O error Reply-To: henryc%reality%ionews@io.org Date: Mon, 14 Mar 1994 14:59:50 GMT In article <1994Mar13.140017.293@ijssel.hacktic.nl>, Arnoud Martens wrote: >> When I first boot my machine, I can run kermit as much as I want with no >> problems. My first DIP script runs fine, but when I kill DIP >> via kill -9 pid, > >Sys admins who complain about a system failure when they kill a >system program with -9 signal should be forced to read a goood >Unix book. Ever heard of proper clean up? Read the man-page: Dip >provides the -k option which lets dip to do it's own clean up >(even hangup the line). It's too bad that the man pages for even some of the most up to date versions of dip do _not_ describe what the `-k' option does. -- | Christian Henry | e-mail: henryc%reality%ionews@io.org (preferred) | | | or: henryc@io.org (if above address bounces) | | ``Blind - Product of pride. F*cker, you don't speak for me...'' - CoC | ------------------------------ From: ddj+@cs.cmu.edu (Doug DeJulio) Subject: Re: Andrew 6.1 for Linux: who did it? Date: Wed, 16 Mar 1994 04:33:36 GMT In article <1994Mar15.195914.326@hisplace.rhein-main.de>, Marko Schuetz wrote: >I grabbed a copy of the Andrew Toolkit for Linux version 6.1 and I must say >that this port definitely causes more problems than it solves. >Most of all it seems incomplete. >For example the .overview files are missing, templates are missing and >much much more. >Yet it's amazing to see what already does run, so I was wondering >if anyone has solved all these problems and tailored a running Andrew >= 6.1. It's all there, nothing is missing. The thing is, there are *two* files you need to install. One of them is labeled as the "programmer stuff", libraries and include files and the like. That's where the overviews, templates, and so on are kept. You have to install *all* of it in order to get *any* of it to work properly. I'm just waiting for X11R6, so I can get the ATK 6.1 source and compile it up myself. -- Doug DeJulio ddj+@cmu.edu ------------------------------ From: kevinl@bruce.cs.monash.edu.au (Kevin Lentin) Subject: Re: TTY overruns cost money. Date: 15 Mar 1994 06:07:36 GMT On Tue, 15 Mar 1994 02:56:03 GMT, Nemosoft Unv. wrote: > Anyway, my questions still stand: why is now all this attention payed to > some vague bit that tells me something is overrunning, while I obviously > loose no data, and why am I even bothered by them at 2400 baud ? That's > ridiculous. I've never seen any MS-DOS comm-program bitch about overruns, > not even at extreme high speeds like 115200 baud on an 8088 XT. And then I > didn't loose a single byte ! Well, the questions is, how do you know? I'd be surprised if you'd never lost a character at 115Kbaud. And another thing, DOS is not linux. DOS is a single task hogging the entire machine. You don't have disk access, sound playing and serial comms all at the same time (at least not during normal MSDOS style operations). You don't get a situation where the computer is doing something else when the serial port decides now is a good time for the computer to receive some data. > Why is it that the Linux serial drivers suddenly seem to be so broken down, > in comparison with this ? Maybe we should turn back to some good-ol' > assembler code ? Actually, they're not suddenly broken down. A decision was made to report the input overrun errors. They were happening before. You just weren't being told about it! -- [==================================================================] [ Kevin Lentin |___/~\__/~\___/~~~~\__/~\__/~\_| ] [ kevinl@bruce.cs.monash.edu.au |___/~\/~\_____/~\______/~\/~\__| ] [ Macintrash: 'Just say NO!' |___/~\__/~\___/~~~~\____/~~\___| ] [==================================================================] ------------------------------ From: mparanj@eis.calstate.edu (Milind Paranjpe) Subject: Fooling with the timer interrupt Date: 14 Mar 1994 22:35:08 -0800 Hello Linuxers, I've been thinking of writing a Linux driver for an A/D card. The card doesn't have any kind of buffer or clocking mechanism to do continuous conversions. This means that I'll have to speed up the timer. Can someone please comment on whether this is recommended/possible? Under dos it was easy--just write a value smaller than 0xffff to io address 0x40, and call the original timer routine once in a while. I took a brief look at the kernel source yesterday, and noticed that the timer interrupt rate is 100Hz by default (at least in 0.99.15d). I wouldn't know what's involved in making this around 4000Hz. Any comments much appreciated. Milind ------------------------------ From: jhonan@lsupoz.apana.org.au (Jamie Honan) Subject: Fonts, keyboards, mice - a proposal Date: 15 Mar 1994 16:33:58 +1000 This article contains a proposal as to how emulation, national keyboard and font support might be taken out of the kernal and placed in a user process. This proposal also has the advantage that it lends itself to implementation of mouse and svga server processes. Please note my preferred email address at the end. Preamble: The line of thought... =============================== Recently, I was looking at the 'selection' package, with a view to using the mouse code. My idea was to integrate character mode mouse handling with the dialog package. The initial problem was that there is only one /dev/mouse device, and 'selection' must 'fight' over reading this device with any other program that wants to use the mouse. Contention with, say, X windows, is achieved by 'selection' backing off and stopping reading the mouse device when the current virtual console is in graphics mode. This contention could be further developed, by changing selection so that it also backed off if a certain file existed (e.g. /USG/local/etc/STOPSELECTION) How would multiple copies of such 'mouse reading programs' cooperate? They could detect when virtual consoles switched, and not read the mouse device whilst another virtual console had control. Detecting when virtual consoles switch could be problematical. One way is to use signals. The virtual console driver in Linux allows one to nominate a single process id which will receive specific signals on switching out of / into a virtual console. An example of how this is done can be seen in the svga library package. The problem with this approach is that it would require a library routine (this is how one would like a mouse handler to be done) that reserves use of two signals, takes control and disables a process when the virtual console is switched. This is precisely what happens in the svga library, and such mouse library code would obviously conflict. Another way of detecting virtual console switch is to extend the ioctl call VT_WAITACTIVE. This takes as an argument the virtual console number that we are waiting to become active. If this were to be extended, such that the argument could also be zero, meaning 'release the ioctl when any new virtual console was switched to', this could be more useful. Being an ioctl, this would require an entire process waiting. The best thing would be a select call on some magic fd, that released when any virtual console switched. Further thinking about mice lead to this thought: What about doing mouse tracking with a graphics type mouse cursor in text mode? This is done in such packages as Norton's Utilities in DOS. This is done by redefining the fonts of four rarely used characters, and re-mapping them with a graphics cursor overlaid. There is some example code from Dave Kirsch, for the DOS world. This requires fiddling with the RAM based fonts in VGA/EGA. Since one only wants to change four characters, there are two options for doing this: 1. Change io permission level (requires setuid root) to re-program VGA registers and write the font RAM. or 2. Put support in the kernel to allow this with either an ioctl or special VT type escape sequence. Option two is what the 'national' package does to load national fonts. This consists of kernel patches to allow an entire font to be loaded. There are some limitations with this. When the console is switched from character mode to graphics mode (or is it the other way round?), the default character set is reloaded by the VGA controller. This is a current problem for 'national'. All this is turning into a classic 'do it in the kernel' versus 'do it by user process' clash. Should the kernel keep a copy of the current font? Should the kernel do the mouse tracking? Objectives: What would be nice... ================================= Then there are other things that one would like to do. It would be nice to improve / modify / replace the VT100 emulation in the kernel with another type, without modifying the kernel. It would be nice to have a mouse 'server' - only one place where the type of mouse was defined, and everybody else read a standard sort of mouse code. In addition, the mouse server could keep the number of 'mickeys' defined for the current virtual console, any boundaries on how far the mouse could move, and only feed those processes that were interested for a virtual console. The mouse server would also handle visual feedback. It would be nice to have a super vga server program, only one program that was setuid root. Other programs could use it to do graphics. It would be nice to implement a mouse emulator with keyboard keystrokes (c.f. pcvct - a virtual console package recently posted to comp.sources for BSD) And it would be nice to do all this without modifying the kernel. In fact if the kernel could be made smaller, all the better. Proposal: ========== Here is a proposal that might allow us to do all of the above, but requires changing the kernel. The proposal is, that under /proc there is a subdirectory /proc/vc, where n is the virtual console number. Under this directory, there is kbd and screen. When either of these is opened for read access, they return packets of information for the relevant virtual console. /proc/vc/kbd would return information about key presses, ioctl calls, and other relevant raw information. This would be fairly undigested. /proc/vc/kbd, when written to, would pass information on up to the relevant tty associated with the virtual console. In this way, a process could handle keyboard emulation. In addition, it could handle national character set mapping. All this would be done without the involvement of the kernel. This process could also do keyboard mouse emulation. /proc/vc/screen, when read, would return packets of information about user writes, ioctls, etc. It would also return information about virtual console switches, mode changes .... In this way, the process reading /proc/vc/screen would also control the font displayed. The process reading /proc/vc/screen would write directly to the vga ram and control the vga registers. Some refinements to the above ideas include a /proc/vc directory. If there is no /proc/vc/kbd opened for read for a particular virtual console, and /proc/vc/kbd was, then the packets would go there. If neither was opened, then the keystrokes would be mapped rather simply and crudely, and passed to the appropriate tty. Similarly, if there was no /proc/vc/screen opened for read, and /proc/vc/screen was, then the packets would go there. If neither was opened, then the screen would be written to in a crude way. With this, the entire national font, national keyboard, specialised keyboards, special VGA characteristics could be taken OUT of the kernel. In addition, you could take the VT100 emulation out! You could place the VT100 emulation in a process that was controlling /proc/vc. Then if you wanted a VT220 emulation on VC 2, you could place that process on /proc/vc2. If you wanted an IBM-PC emulation, this could go in it's own process. Another refinement is that the select call should be supported, as well as open NONBLOCK. In addition, like fifos, the writes should be atomic if less than the buffer size. One other thing which would be useful for a mouse server, would be /proc/vc/current. When read, this would always return the current vc, and perhaps mode information. A select on this would only be released when there was a status change, e.g. mode, or virtual console switch. Objections to this scheme. =========================== Obviously this requires extra process switching. The good thing is that this is being done on slow devices - keyboards, mice, screen writes (it would not be done on individual character screen writes, these would be buffered) - so this doesn't matter that much. Obviously this puts a fair degree of burden on a user level process. The kernel could conceivably be operating quite correctly, whilst the emulation has crashed or locked up. The user would be unable to do anything. Just some thoughts.... Jamie (please note for email jhonan@jolt.mpx.com.au ) ------------------------------ From: biegler@aristotle.cs.uregina.ca (Mark Biegler) Subject: [Q] Adaptec 2842 SCSI driver yet? Date: Tue, 15 Mar 1994 05:33:50 GMT Hello, Is the Adaptec 2842 SCSI driver available yet? The Hardware-HOWTO doesn't mention it, and the SCSI-HOWTO states that's it's being worked on, but both are a bit out of date. As well, the Slackware SCSI bootdisk doesn't seem to have it as an option. We will be making a few computer acquisitions and would like to use this adaptor with Linux, but I need information ASAP. I'd hate to have to buy something else if it's only a month away. Thanks muchly, Mark Biegler ===== Mark Biegler (VE5MPB) biegler@cs.uregina.ca Department of Computer Science W: (306) 585-4110 University of Regina H: (306) 522-1770 Regina, Saskatchewan Canada S4S 0A2 Office: CW 307.12 ------------------------------ ** 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 ******************************