From: Digestifier To: Linux-Development@senator-bedfellow.mit.edu Reply-To: Linux-Development@senator-bedfellow.mit.edu Date: Sat, 18 Sep 93 16:26:17 EDT Subject: Linux-Development Digest #108 Linux-Development Digest #108, Volume #1 Sat, 18 Sep 93 16:26:17 EDT Contents: SCSI command linking (Eric Youngdale) Re: SCSI command linking (Bill Mitchell) Re: SCSI Timeouts (Bill Mitchell) Re: SCSI command linking (Eric Youngdale) Re: Let's have a prog to restore screen state! (David E. Wexelblat) Re: What do people think about /config? (Peter Mutsaers) Mouseless X for Linux notebook (Howard Gayle) Re: [Q] biff and comsat and sendmail? (Rafal Maszkowski) Re: Mouseless X for Linux notebook (John Verzani) ---------------------------------------------------------------------------- From: eric@tantalus.nrl.navy.mil (Eric Youngdale) Subject: SCSI command linking Date: Sat, 18 Sep 1993 13:54:46 GMT I have come up with some test patches that implement command linking for the Adaptec 1542 SCSI adapter. The advantage of command linking is that in principle we can get increased throughput, and we have the potential of much higher datarates. So far I have only patched the 1542 driver and the mid level code. I added an ioctl so that I could test this much, and I have found that while it works fine on my cdrom, any attempt to use command linking with my disk drive results in a scsi bus hang. Both the disk and the cdrom report that they are capable of using command linking. When I try this with the disk, the first segment completes normally, and that is the last I hear from the scsi adapter. Right now I am not sure if it would be a good idea to continue development or not. If my disk is just an isolated case, then obviously it would be worth it, but if there are a lot of disks out there that screw up with command linking it would be a whole lot simpler to chuck it and leave this feature out. Anyway, the test patches are on tsx-11 in pub/linux/ALPHA/scsi/cmd-link.txt. There are kernel patches and there is a test program that makes use of the ioctl that I added to test this. I would like some other people to try this out so I could see whether the problem comes up on other drives or now. I would also like to know the firmware revision level on the Adaptec that you are using (in theory the problem could be in there). -Eric -- "When Gregor Samsa woke up one morning from unsettling dreams, he found himself changed in his bed into a lawyer." ------------------------------ From: mitchell@mdd.comm.mot.com (Bill Mitchell) Subject: Re: SCSI command linking Date: Sat, 18 Sep 1993 15:06:16 GMT in comp.os.linux.development, eric@tantalus.nrl.navy.mil said: > > I have come up with some test patches that implement command linking >for the Adaptec 1542 SCSI adapter. The advantage of command linking is that in >principle we can get increased throughput, and we have the potential of much >higher datarates. > > So far I have only patched the 1542 driver and the mid level code. I >added an ioctl so that I could test this much, and I have found that while it >works fine on my cdrom, any attempt to use command linking with my disk drive >results in a scsi bus hang. Both the disk and the cdrom report that they are >capable of using command linking. When I try this with the disk, the first >segment completes normally, and that is the last I hear from the scsi adapter. >[...] I've been having a problem which may be similar/related to this. linux 0.99pl12 IDE on motherboard plus Adaptec 1542C, 17 Mb RAM, swapping not enabled Connor 170 Mb IDE, /dev/hda1 is msdos, /dev/hda2 is linux boot/root Quantum 100 Mb SCSI, /sev/sda1,2,3 are mounted ext2 filesystems Seagate 330 Mb SCSI, /dev/sdb1,2 are currently uncommitted ext2 filesystems Tandberg SCSI tape, /dev/rmt0 added recently I had been operating without the tape and not noticing problems. After adding the tape, I saw SCSI timeouts during simultaneous SCSI disk and tape activity. After the timeout my 1542C would not recognize SCSI devices, even after reset-switch reboot. Powerdown, powerup was needed to get the the 1542C to recognize devices again. After seeing this, I tried some tests. I found that if I made some big disk files, and then started several processes doing something like "cat big_scsi_file >/dev/null", I'd sometimes (rarely) see the same thing happen even without any tape activity. I'm unable to cause the problem under MDSOS with or without tape activity, but then I haven't tried very hard. I've recently replaced my 1542C with a 1540B, and find this problem much dimished. I have seen SCSI timeouts, but have not yet had to powerdown and powerup to restore functionality. I haven't done any heavy testing to really compare operation with 1542C against 1540B, but I'm confident that my general impression that 1542C operation has problems on my system which are much reduced using a 1540B instead is valid. I'm also confident that my observation that the SCSI timeouts are seen with both controllers during routine operations under linux, and not seen with either controller during routine operations under MSDOS is valid. -- mitchell@mdd.comm.mot.com (Bill Mitchell) ------------------------------ Crossposted-To: comp.os.linux.misc From: mitchell@mdd.comm.mot.com (Bill Mitchell) Subject: Re: SCSI Timeouts Reply-To: mitchell@mdd.comm.mot.com (Bill Mitchell) Date: Sat, 18 Sep 1993 15:17:28 GMT in comp.os.linux.misc, c@royle.org (Chris Royle) said: >I have had a 280 MB SCSI II Seagate Hard Disc Drive running off my >Adaptek 1540B SCSI controller under Linux for ages with no problems at >all so far. > >I have now added a Sankyo CP150SE Tape streamer to the chain, and this >seems to be causing timeouts during my backing up with tar. (That is, >the timeouts are from the card, and are seemingly nothing to do with >the HDD). > >During a tar to /dev/rmt0, I get > >SCSI host 0 timed out - aborting command > >Now, sometimes the tar carries on (but I haven't been able to check the >integrity of the archives it produces yet), and *once*, it has just >sent the tar completely ker-put! > >The SCSI cable is all internal (hence I don't think it's a length problem). > >Anyone got any ideas ? > Apologies for requoting the entire article, but I've crossposted to c.o.l.development, and wanted it seen there. I've been having similar problems since I added a Tandberg SCSI tape to my system, have posted about them previously, and just posted about them again in c.o.l.development in reaction to a related posting I saw there. Consensus up until now has been that this resulted from something specific to my system. Your description of the problems you're having, however, sounds like the same thing I'm seeing. By the way, I replaced my internal SCSI cables and saw no change in the problem. I did see the problems dimish (but not disappear) when I replaced my Adaptec 1542C with a 1540B. -- mitchell@mdd.comm.mot.com (Bill Mitchell) ------------------------------ From: eric@tantalus.nrl.navy.mil (Eric Youngdale) Subject: Re: SCSI command linking Date: Sat, 18 Sep 1993 16:48:34 GMT In article <1993Sep18.150616.7417@mdd.comm.mot.com> mitchell@mdd.comm.mot.com (Bill Mitchell) writes: >linux 0.99pl12 >IDE on motherboard plus Adaptec 1542C, 17 Mb RAM, swapping not enabled >Connor 170 Mb IDE, /dev/hda1 is msdos, /dev/hda2 is linux boot/root >Quantum 100 Mb SCSI, /sev/sda1,2,3 are mounted ext2 filesystems >Seagate 330 Mb SCSI, /dev/sdb1,2 are currently uncommitted ext2 filesystems >Tandberg SCSI tape, /dev/rmt0 added recently > >I had been operating without the tape and not noticing problems. After >adding the tape, I saw SCSI timeouts during simultaneous SCSI disk and >tape activity. After the timeout my 1542C would not recognize SCSI >devices, even after reset-switch reboot. Powerdown, powerup was needed >to get the the 1542C to recognize devices again. My guess is that you have the bus improperly terminated. If all of your devices are internal, then the last one on the cable should be terminated, and none of the others should have termination enabled. There is also termination on the 154x board which should be left in if all of the devices are internal. If you have both internal and external devices, then you need to make sure that the last device on both the internal and external cables is terminated. You must also remove the termination from the Adaptec in this case. I have tried operating scsi busses in the past that were not properly terminated. I would get read errors, medium errors, timeouts, the whole nine yards. Fixing the termination makes the bus rock solid, at least in terms of the distribution kernel. The message I posted before related to a feature that I was trying to implement. Apparently the disk drive that I have has a firmware bug that causes it to lock up if you attempt to use command linking. This has the effect of locking the entire scsi bus. -Eric -- "When Gregor Samsa woke up one morning from unsettling dreams, he found himself changed in his bed into a lawyer." ------------------------------ From: dwex@mtgzfs3.att.com (David E. Wexelblat) Subject: Re: Let's have a prog to restore screen state! Date: Sat, 18 Sep 1993 16:57:29 GMT In article <27dauq$osn@klaava.Helsinki.FI> kankkune@klaava.Helsinki.FI (Risto Kankkunen) writes: > >>I think every program should absolutely switch through kernel, even if > >>via a really low-level ioctl that takes an array of port/value pairs or > >>something general enough like that. This would make it possible for the > > > >And you would have even the X server do this? I surely wouldn't. > > I'd at least want to try that out. If the performance is unacceptable, > maybe one has then come up with some kludges to fix that up. I wouldn't > like linux to become another DOS where every program bypasses the OS and > then you get all those coordination problems of sharing devices between > multiple programs. The OS is there just to prevent this. The performance will be completely unacceptable. Working on the S3 stuff, we made a change to put a signal block/restore around each critical section of graphics operations. This cost us 15% of the server's performance (we have since found a much better way to deal with the critical sections). When you figure that the S3-class hardware requires dozens and dozens of I/O operations to do its work, I estimate that you would lose 50-75% of the server's performance by going through the kernel. Context switches are expensive, by definition. > > >Remember that bank switching is something that would affect screen > >"normality," yet I wouldn't want the X server having to do a bunch > >of ioctl()s every time my mouse crossed a bank boundary. > > There aren't so many banks on a screen, and it would probably be one > ioctl with an array. It might not be too bad, I don't know (and it can > heavily depend on the screen mode). You don't have any idea how this stuff works, do you? Bank switchs occur often during graphics operations. It doesn't have anything to do with mouse behavior, it has to do with where things are drawn on the screen. > > But one of those speed hacks might be that programs handling VC switches > on their own might have the responsibility to save their screen state > before switching out and restore that when they get the control again. > While they have the screen, they can access it directly. If the program > dies, the kernel could reprogram the screen to the state it was before > this program started. Gee, now why didn't we think of this? Guess what. This is how it works NOW. The problem is that the state either isn't saved or isn't restored correctly in all cases. In other words: the bugs that keep the X server from restoring the screen correctly are just as likely to occur if someone tries to put this code into the kernel. More likely to occur in the kernel, in fact, because we have a hell of a lot more experience at doing this stuff, and someone putting it in the kernel will make the same mistakes we made. > > >>kernel to maintain the current state of the card, allow programs to > >>query some write-only registers from the kernel's (or driver's) copy of > > > >VGA shouldn't have any write-only registers. EGA/CGA/MDA do, of course, > > This is what I recollected, and was refering to EGA/... One of the > driver's functions would be abstracting all those cards enough that > kernel proper or user programs wouldn't normally need to know too many > details about the installed hardware. Thing like blanking a positive > screen etc. belong to the driver. But VGA, EGA, CGA, MDA, HGA are all trivial to do in a console driver. It's the myriad of SVGA and other esoteric hardware that has problems. The only way to do things "right" is to use the BIOS. > > >I think it's just too costly to go with this scheme. On my localbus > >ET4000 (on a 486/33), X is tolerably fast. I wouldn't want it any > >slower. I can run Castle Wolfenstein 3-D under dosemu at a very > >comfortable speed; with the overhead of trapping all port accesses > >and translating them into ioctl()s and context switching, etc., you > >could count the pixels as they changed. > > Do you have any numbers? It would sure be interesting to see some > best/worst case figures (some modes are really pain in the ass in regard > of access), but I'm too lazy to calculate them myself. Yes, we have some numbers. Suffice it to say that EVERY X server that I am aware of on Intel hardware does things the way XFree86 does them. > > > 3) If a console switch away from a console in GRAPHICS mode occurs, > > the kernel driver restores the screen state to the default text > > mode. > > That would mean the driver had to know the adapter pretty intimately for > it to know when the screen is in graphics mode. This wouldn't, however, > help you much if you switch to a non-default text mode. You really don't know what you're talking about, do you? There is basically one bit in one register that says whether or not a VGA-class board is in text or graphics mode. > > Wouldn't my scheme work better? To repeat, let's say that normally the > screen is handled through ioctl's. A program can issue a KD_EXCLUSIVE > ioctl to get direct access to the screen. This would add the registers > the card has to the process's iobitmap. When a switch occurs, the kernel > can set the state of the screen from the saved copy of that process. > Before switching the KD_EXCLUSIVE process is notified, so it can save > its state. When you switch back to the process with KD_EXCLUSIVE would > get a signal or something to let it restore the screen to its liking > before continuing. > > A minimal driver to implement just KD_EXCLUSIVE for a wide variety of > cards would only need a list of port values each card uses and the > simple ioctl. Are the ports usually documented at all for noname svga > cards? If not, it shouldn't be impossible to track the ports the cards > BIOS uses. If it is, you could guess a bit liberally the range of ports > used. Or guess conservetively and keep increasing until you get no more > port access violations. Give it a shot. Maybe you'll learn something. What you'll learn is (a) this stuff is really hard, (b) we do it this way for a reason, and (c) what you hope to accomplish is impossible without using the BIOS. > > >Performance should *not* suffer. > > Compared to what? Drop the OS and you get more performance. Many people > still like the notion of a proper OS that gives them some protection and > otherwise increases usability, even if it means paying a small > performace hit. I think the issue here is to balance the performace loss > with the added robustness. > > > Also, sometimes having it done at all is more important that doing it > > right (see *BSD and shared libraries). > > Ah, this is the new Linux motto! Drawing a parallel from the shared > libray case, we should be implementing the drivers already, not debating > what works, what not, and what might be the optimal solution. But I > don't like analogies too much, you can usually get any conclusions you > want from a reasonable-sounding analogy. I assume that you think the XFree86 developers are idiots, becasue we haven't gotten it all right yet. All I can say is "put up or shut up". Otherwise you're no better than Jesus Monroy, blathering on about drivers that can do this and that, while other people do the real work. > -- > It's that time of the year again -- David Wexelblat (908) 957-5871 Fax: (908) 957-5305 AT&T Bell Laboratories, 200 Laurel Ave - 3F-428, Middletown, NJ 07748 XFree86 requests should be addressed to "Shining, flying, purple wolfhound, show me where you are." Yes, "Yours Is No Disgrace" ------------------------------ From: muts@compi.hobby.nl (Peter Mutsaers) Subject: Re: What do people think about /config? Date: Fri, 17 Sep 1993 08:44:11 GMT >> On Wed, 15 Sep 93 13:36:50 GMT, nelson@crynwr.com (Russell Nelson) said: RN> We create a standard configuration file format, and a set of programs RN> that "compile" the standard format into each idiosyncratic file. And RN> optionally, we can have a program that edits these files, just to RN> add some gloss to the system. RN> And, all these files go in /config. Only configuration files go in RN> /config. This would be a horrible mutilation of Unix, and make Linux so different from the rest of the world that it becomes unusable and unappealing. Also, all the different files have reasons for their formats, you cannot change all programs that use them. People who are familiar with them would hate this, new users who do not know about them and don't want to learn, should use special tools to change the system configuration which then modify the various system files. -- _______________________________________________________________ Peter Mutsaers, Bunnik (Ut), the Netherlands. ------------------------------ From: howard@hal.com (Howard Gayle) Crossposted-To: comp.windows.x.i386unix,comp.sys.laptops Subject: Mouseless X for Linux notebook Date: 18 Sep 1993 18:33:24 GMT Reply-To: howard@hal.com (Howard Gayle) I hacked the XFree86 1.3 monochrome X server to start up and run even if there's no pointing device. The cursor just stays in its initial position in the center of the screen. This may sound like a really dumb thing to do, but it's useful for me. I run Linux on a notebook computer with a clip-on trackball. In many situations, it's not convenient to carry around the trackball, plug it in, and clip it on, but it's still nice to have X windows. Running emacs under X windows gives me more lines and multiple fonts. I can also run xdvi. The X server hacks are only for Linux. I'll mail diffs to anyone who asks. Eventually I'd like to add mouse simulation using cursor keys and function keys, but I don't really need it. -- Howard Gayle HAL Computer Systems, Inc. 1315 Dell Avenue Campbell, California 95008 USA howard@hal.com Phone: +1 408 379 7000 extension 1080 FAX : +1 408 379 5022 ------------------------------ From: rzm@oden.oso.chalmers.se (Rafal Maszkowski) Subject: Re: [Q] biff and comsat and sendmail? Date: Sat, 18 Sep 1993 19:29:19 GMT Michael O'Reilly (oreillym@tartarus.uwa.edu.au) wrote: : Johannes Grosen (grosen@argv.cs.ndsu.nodak.edu) wrote: : : In article <1993Sep16.141819.23697@nrao.edu> rzm@oden.oso.chalmers.se (Rafal Maszkowski) writes: : : >Have anybody ported biff and comsat (are these 2 enough to get : : >messages about new mail?). If so - under which name can they be : You also need your sendmail agent to be comsat aware (smail by default : isn't... ). I'm using 5.65c/IDA-1.4.4 Sendmail from sunsite. It doesn't look like knowing about inetd listening on port 512. Do I need to define comsat as one of the mailers or this version just doesn't support it or ...? R. -- Rafal Maszkowski rzm@oso.chalmers.se rzm@mat.torun.edu.pl <-finger for public snail: Omgangen 464-82, 412-80 Goteborg, Sweden; tel: +46-31-7780831 key Opinia publiczna powinna byc zaalarmowana swoim nieistnieniem - S.J.Lec ------------------------------ From: verzani@bunuel.math.washington.edu (John Verzani) Subject: Re: Mouseless X for Linux notebook Date: 18 Sep 1993 19:47:30 GMT There is a window manager FWM which says it can be run under Linux wothout a mouse. There is a combination of keystrokes which can move you about. John Verzani ------------------------------ ** 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 ******************************