Subject: Linux-Development Digest #577 From: Digestifier To: Linux-Development@senator-bedfellow.MIT.EDU Reply-To: Linux-Development@senator-bedfellow.MIT.EDU Date: Fri, 25 Mar 94 09:13:05 EST Linux-Development Digest #577, Volume #1 Fri, 25 Mar 94 09:13:05 EST Contents: Re: LINUX port to a transputer system (Baranski, A.S.) Re: Specialix Driver Round 2 (From specialix) (David Wright) Re: WORD status (Niels Skov Olsen) Linux <--> DOS PLIP??? (Alexandra Griffin) Re: 486DLC support anyone? (lcvanveen@et.tudelft.nl) Re: Scsi host time outs -- help (Eric Youngdale) PAS16 Mixer for XFree? Re: Genoa Phantom ET4000/w32i + XFree86 anyone? ---------------------------------------------------------------------------- From: v922215@si.hhs.nl (Baranski, A.S.) Subject: Re: LINUX port to a transputer system Reply-To: v922215@si.hhs.nl Date: Fri, 25 Mar 1994 07:40:27 GMT In article 15762@leeds.ac.uk, een6njb@sun.leeds.ac.uk (N J Bailey) writes: >In article 764502256@marie, wpp@marie.physik.tu-berlin.de (Kai Petzke) writes: >> Antoni.Baranski@si.hhs.nl (Baranski, A.S.) writes: >> >> >Hi World, >> >> > I am a student at the Haagse HogeSchool Sector Informatica in the Hague, Holland. >> >During my summer holliday I am planning on making a port of LINUX onto a T800 >> >transputer subsystem which plugs into my PC. >> >> Well, I want to encourage you to do it. It will stop all these >> people, who say: "But linux does not run on a multiprocessor", if >> it runs on your plug in transputer :-) >> >I agree! > >> My idea was to do as minimal work as possible in the beginning. Is >> it possible, that a process on the transputer sends a signal to the >> Intel chip? Furthermore, is it possible to map transputer memory >> into the Intel address space? In that case, all the system calls >> could be processed by the standard Linux kernel, and all you had to >> programme was a small transputer kernel, which transfers the system >> calls to the Intel. > >Watch out here. Transputers do not have a memory manager, and their >whole raison d'etre (as we say in England) is to support CSP-based >programming as embodied in the Occam programming language. If you >want to use the (very efficient) task scheduling hardware provided >by a Transputer chip, you will have to use links for comms (not shared >memory) or else get your hands very dirty indeed hacking around at the >lowest level. Also since there is no memory management, stopping >one process corrupting another is next to impossible. Unless you impose >a one-prcessor, one-process limit. > >Transputers aren't really meant for this sort of thing -- they are >good for embedded systems and highly parallel machines, but not really >for complex OSs. Unless you have T9000s (rumoured to exist, years overdue, >never seen one myself). You may be better off implementing the iserver >in a more efficient way. Transputers are also very slow, compared with >486s, 68040s etc. (again, excepting T9000s). > Here I must interupt because the T800-25MHz 8Mb RAM board I have burns rubber where as my 486DX-50MHz 8Mb is not even near to the number crunching powers of the transputer. >But don't let me stop you being creative! > >Nick. >--- >------------------------------------------------------------------------------- >Nick Bailey Telephone: +44 532 332057 >Lecturer in Electronic Engineering Facsimile: +44 532 332032 >University of Leeds >Woodhouse Lane >Leeds LS2 9JT >United Kingdom >=============================================================================== > SU L8R ================ Baranski, A. S. | Haagse HogeSchool e-Mail: | Sector Informtica Antoni.Baranski@si.hhs.nl | Student Software Engineering > ------------------------------ From: dmw@prism1.prism1.com (David Wright) Subject: Re: Specialix Driver Round 2 (From specialix) Date: Wed, 23 Mar 1994 13:04:37 GMT >>>>> "CMR" == Craig Milo Rogers writes: CMR> In the following reply, I may appear a little condescending, CMR> even sarcastic. I apologize in advance. I don't really wish to CMR> offend, I simply wish to make my point obvious. Also, this is a CMR> long post, and I apologize for that, too. I won't take it personally... CMR> 1) The intelligent board connects to the host system by the CMR> system I/O bus, right? This would seem obvious. :-) CMR> 4) Since the intelligent board contain a running software program CMR> of its own, the format of the registers, and their meanings, may CMR> be time-varying in very complex, arbitrary, obscure, arcane, CMR> and wonderful ways. This is true, but irrelevant if the host (unix) side of the driver provides a standard API for vendor-specific driver code to talk to. The person writing such Unix "glue" code could release the API as a public standard, and there would be no problem with vendors shipping binary-only versions of their code that "knew" how to use this API. This is especially true in the case of loadable "modules" under Unix. CMR> Here we reach the nut of the problem. Each :intelligent CMR> serial board" vendor may use a completely and arbitrarily *different* CMR> allocation (spatial and temporal) of bits on the host side of the CMR> interface, to do that vendor's various and wonderful things. There is CMR> no common convention or standard (of which I'm aware) for the hardware CMR> design, meaning of bits, temporal dependencies, etc. in these boards. CMR> Nada. Zip. I agree, but I feel this is irrelevant. It's not like there are different standards out there for us to work with. If the driver that is being worked on for the Specialix boards is released, the whole Unix-interface side is likely to be under the GPL, and will be there to serve as an example for other manufacturers. As the people from Specialix have said, they consider the code that runs ON the board to be their "jewels", not the code to talk to the board. Short of companies like Diamond or Matrox, I would expect this to be the "norm". CMR> Conclusion: the host-side interface is vendor-specific, CMR> in-and-of itself. No, only portions that relate to talking to the *host adapter* are vendor specific. The portion that talks to Linux / Unix COULD be the same for every board, technically. The vendor-specific portions of code could fairly easily be hidden behind an API, or even as a loadable "module". CMR> For competitive reasons, at least one "intelligent serial CMR> board" vendor wishes to keep various aspects of their host-side CMR> interface a trade secret. This also happens in the video card & ethernet card markets. Big deal. Buy someone elses board who isn't as anal. Personally, we only use Specialix boards here anyway, after years of using DigiBoard products, and I would love to have a DigiBoard driver for Linux. CMR> There is no "generic" intelligent host adaptor "glue" code, CMR> because there is no "generic intelligent host adaptor" (of which I am CMR> aware). No standard has been established, not even a partial CMR> standard, as is found in video adaptors, sound adaptors, SCSI disk CMR> adaptors/drives, etc. Lacking adherence to a common standard, nothing CMR> is generic. Lacking adherence to a common standard, functioning CMR> (complete in itself) "generic" driver code for intelligent serial CMR> boards is not possible. Whether the hardware itself has a generic interface is irrelevant. I was not suggesting that the same driver would work for all boards at all. Only that a vendor could take large portions (and possibly all) of existing driver "glue" code and save development time. I don't what would be stopping someone from writing their own "intelligent serial interface" for Linux, providing a standard API, that allowed vendors to write to this API instead of directly to Linux. The code provided by the API could be supplied in the standard kernel, and all the vendor would have to supply is the code that talked via it in some form that could be linked with the kernel (or as a loadable module). For instance, The API could provide a board "initialization" hook that got called at boot time, so the board could do what it needed, load it's local OS, whatever. The same call could provide in a standard, agreed-upon structure, the desired IRQ, DMA channel, port address, and board address. Cards that didn't make use of it (set by jumpers or whatever) could just ignore it. The is no need for the rest of the Linux system to "know" what the card does when it starts up, so I don't see how vendor-specific "features" would be an issue here. Similarly, the Linux "glue" code could supply board read/write functions to Linux, so the OS talked to all boards via the same IOCTLS, etc. The glue code would then make use of a "standard" function call to read or write data from/to the board. You could also provide similar functionality for things like checking for data to be read from the board, etc. It would seem to make sense to me to have a structure returned by the board init routine that would indicate what the vendor-supplied code supported. IE: Should the Linux-code work in polled-mode, interupt-driven, etc. In terms of just the API I can't see this would take someone more than a few days to sketch out on paper, maybe a week (or part-time work) at most. I would even do it myself, but I do not know enough about the Linux-side of the interface to do the actual programming on my own. CMR> The details for loading the on-board processor code is, quite CMR> probably, one of the major functions that the vendor(s) wish to remain CMR> a trade secret. Why do they care about who knows how the code is *loaded*? What the code that get's loaded DOES is the important part. Most of the embedded OS's on the cards I have seen are quite small, and it would not suprise me to learn they just load them into main memory and then DMA them onto the card, but even stuffing it through an I/O buffer is reasonable since it only gets done once per boot. CMR> The OS-specific part of the driver could be considered the API CMR> you described above, except that the API *wouldn't* know "how to CMR> write to the intelligent card on the other side", as doing so is CMR> specific to each vendor's device, in-and-of itself. Writing to the CMR> intelligent card would be the responsibility of the non-GPLed, CMR> object-only portion of the device driver. That is my point. The API would NOT know about the specifics of the card it was talking to. It would only know to call specific functions (supplied by the vendor) which did the communication on their own. CMR> On the OS-dependent side, you could establish a API, such as a CMR> set of IOCTLs, to be used by user-level programs to reset the intelligent CMR> serial board's on-board processor, load a new program into the board, CMR> and other functions that are not present in a standard "dumb" serial CMR> board, but which may be reasonably expected to be common to intelligent CMR> serial boards. However, the implementation of resetting, loading, etc., CMR> the on-board processor would be part of the hardware-device-specific, CMR> non-GPLed code in the two-part driver I refer to above. Exactly what I have always been talking about doing. Dave -- ____________________________________________________________________________ | /\ / | Prism Computer Applications | David Wright | | -/--\-- | 14650 Detroit Ave, Suite LL40 | dmw@Prism1.COM | | /____\ | Lakewood, OH 44107 USA | 216-228-1400 | -- ____________________________________________________________________________ | /\ / | Prism Computer Applications | David Wright | | -/--\-- | 14650 Detroit Ave, Suite LL40 | dmw@Prism1.COM | | /____\ | Lakewood, OH 44107 USA | 216-228-1400 | ------------------------------ From: dingbat@diku.dk (Niels Skov Olsen) Subject: Re: WORD status Date: Thu, 24 Mar 1994 22:57:00 GMT seiferth@bandelier.cs.unm.edu (Justin Seiferth) writes: >Whatever happened to the project dedicated to developing a word >processor/ desktop publishing application? If this is under >active development I'm interested in participating. When Wine is finished and stable you'll have access to a whole line of advanced word processors and dtp systems. >I did subscribe to the WORD channel, but have not received any >traffic from there. Niels -- "here is a man who *would* not take it any more -- here is a man who stood up" -Travis Bickle ------------------------------ From: acg@kzin.cen.ufl.edu (Alexandra Griffin) Subject: Linux <--> DOS PLIP??? Date: 24 Mar 1994 23:31:55 GMT I've been trying to do this same thing. The only apparent change seems to have been that a new "protocol byte" has been added to the packet; this byte is either 0xFD or 0xFC depending on whether the packet is an original "Type I" packet (the type the Crynwr plip.com driver uses), or a new Linux Type II packet. The difference seems to be that a Type II packet has reduced header information, and is generated if enough of the header matches up between the two ends of the connection... I attempted to modify my (kernel 1.0) copy of plip.c to dispense with the protocol byte and always use/expect type I packets. In the receive_packet() function I removed the get_byte() call to read in the protocol byte, setting it to a constant 0xFD at this point. Similarly, I remoed the corresponding send_byte() call from the send_packet() function and fixed the header-similarity test to never generate a type-II packet. Unfortunately, this still doesn't work-- there must be somet other protocol incompatiblity (or perhaps I accidentally messed something up in the driver). This has resulted in a bit of improvement-- the Linux machine doesn't just lock up solid when it receives packets from the DOS system (from plip.com) but instead just ignores them, hanging for a couple of seconds every time one comes in. Has anyone had better luck with this, either modifying Linux to dispense with type-II packets and the extra byte, or modifying plip.com to handle the new PLIP protocol? I could definitely benefit from having DOS <--> Linux communications capablity under PLIP, so I'm kind of eager to get this going. Thanks in advance, -- ______ \ / ////////////////////////////////////////////// \ / / Alexandra Griffin /// acg@kzin.cen.ufl.edu / \/ ////////////////////////////////////////////// ------------------------------ From: lcvanveen@et.tudelft.nl Subject: Re: 486DLC support anyone? Date: 25 Mar 94 10:08:53 +0100 Stuff deleted Applying the alt diff's does not allways do the job, when your setup file gets bigger then 512 byte your running into trouble and that's just what happend even after applying then alt diffs to the kernel. That's why I had to rip some video stuff out. Martijn ------------------------------ Crossposted-To: comp.os.linux.admin,comp.os.linux.misc From: eric@tantalus.nrl.navy.mil (Eric Youngdale) Subject: Re: Scsi host time outs -- help Date: Thu, 24 Mar 1994 16:01:14 GMT Sorry about the crosspost, but I need to reach a wide audience with this. In article <2mmvem$74s@panix.com> dcv@panix.com (Dimitri Vlahakis) writes: > >I keep getting error messages while running linux on my system, if I leave it >on for over an hour or so. Basically they come randomly, and the message is >scsi host 0 time out, and I can no longer access my scsi hard drives, or >the partitions they contain. The drives work fine until then. This problem >has happened to me with both linux 99pl13 and with 1.0 as well. I have a patch that one person is reporting success with. I am posting it to see if it helps anyone else (this is the same patch that was posted to the SCSI channel a day or two ago). This patch is only for the 1542 driver, although the wd7000 driver is similar enough that the patch could be used there as well - don't know about any of the others. From what I can tell, this patch will help in cases where you have multiple devices (or multiple drives) that are being used simultanously. Usually the problem is most severe with machines that have more than one disk drive since you tend to send a lot more commands to a disk than to a tape drive or cdrom - expiring news on a 2-disk system can be a pretty good way of triggering this. Anyway, there was a race condition in the code where we send commands to the device that this patch corrects, and as I mentioned before, there is someone with a 1542C that no longer gets timeouts with these patches installed. Although I do not expect any problems, I would like people to try this, because I want to make sure that there are no bad side effects. This patch will be incorporated into 1.0 if no one reports any problems. -Eric begin 644 aha1542.diff M*BHJ(&%H83$U-#(N8RY^,7X)4W5N($UAPHK("`@("!C;&DH*3L*("`@("`@=VAI;&4@*&QE;BTM*0H@("`@("`@('L* M("`)("!704E4*%-405154RAB87-E*2P@1$8L($1&+"`P*3L*("`)("`J8VUD M<"LK(#T@:6YB*$1!5$$H8F%S92DI.PH@("`@("`@('T**R`@("`@