466 lines
21 KiB
Plaintext
466 lines
21 KiB
Plaintext
Subject: Linux-Development Digest #577
|
|
From: Digestifier <Linux-Development-Request@senator-bedfellow.MIT.EDU>
|
|
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 <rogers@drax.isi.edu> 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($UA<B`Q,R`Q.#HU,SHS,"`Q.3DT"BTM
|
|
M+2!A:&$Q-30R+F,)5'5E($UA<B`R,B`R,#HQ.#HT."`Q.3DT"BHJ*BHJ*BHJ
|
|
M*BHJ*BHJ*@HJ*BH@.3<L,3`Y("HJ*BH*+2TM(#DW+#$Q,B`M+2TM"B`@"B`@
|
|
M<W1A=&EC(&EN="!A:&$Q-30R7V]U="AU;G-I9VYE9"!I;G0@8F%S92P@=6YC
|
|
M:&%R("IC;61P+"!I;G0@;&5N*0H@('L**R`@("`@8VQI*"D["B`@("`@('=H
|
|
M:6QE("AL96XM+2D*("`@("`@("!["B`@"2`@5T%)5"A35$%455,H8F%S92DL
|
|
M($-$1BP@,"P@0T1&*3L*("`)("!O=71B*"IC;61P*RLL($1!5$$H8F%S92DI
|
|
M.PH@("`@("`@('T**R`@("`@<W1I*"D["B`@("`@(')E='5R;B`P.PH@("`@
|
|
M9F%I;#H**R`@("`@<W1I*"D["B`@("`@('!R:6YT:R@B86AA,34T,E]O=70@
|
|
M9F%I;&5D*"5D*3H@(BP@;&5N*S$I.R!A:&$Q-30R7W-T870H*3L*("`@("`@
|
|
M<F5T=7)N(#$["B`@?0HJ*BHJ*BHJ*BHJ*BHJ*BH**BHJ(#$Q,"PQ,C(@*BHJ
|
|
M*@HM+2T@,3$S+#$R."`M+2TM"B`@"B`@<W1A=&EC(&EN="!A:&$Q-30R7VEN
|
|
M*'5N<VEG;F5D(&EN="!B87-E+"!U;F-H87(@*F-M9'`L(&EN="!L96XI"B`@
|
|
M>PHK("`@("!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`@("`@<W1I*"D[
|
|
M"B`@("`@(')E='5R;B`P.PH@("`@9F%I;#H**R`@("`@<W1I*"D["B`@("`@
|
|
M('!R:6YT:R@B86AA,34T,E]I;B!F86EL960H)60I.B`B+"!L96XK,2D[(&%H
|
|
B83$U-#)?<W1A="@I.PH@("`@("!R971U<FX@,3L*("!]"B!L
|
|
`
|
|
end
|
|
|
|
|
|
--
|
|
"The woods are lovely, dark and deep. But I have promises to keep,
|
|
And lines to code before I sleep, And lines to code before I sleep."
|
|
|
|
------------------------------
|
|
|
|
From: itusul@dale.ucdavis.edu ()
|
|
Subject: PAS16 Mixer for XFree?
|
|
Date: Fri, 25 Mar 1994 00:49:32 GMT
|
|
|
|
Is there a X based mixer for the PAS16 out there somewhere? I know there
|
|
is x-mix for the SB16...
|
|
|
|
--
|
|
+---------------------------+---------------------------------+
|
|
| Lance Kinley | email: lkinley@ucdavis.edu |
|
|
| Consultant | login: itusul@dale.ucdavis.edu |
|
|
| Information Technology +---------------------------------|
|
|
| Campus Access Point |Linux 1.0: It's out & bug free :)|
|
|
|---------------------------+---------------------------------+
|
|
| 1400 Surge II, University of California, Davis 95616 |
|
|
+-------------------------------------------------------------+
|
|
|
|
------------------------------
|
|
|
|
From: itusul@dale.ucdavis.edu ()
|
|
Subject: Re: Genoa Phantom ET4000/w32i + XFree86 anyone?
|
|
Date: Fri, 25 Mar 1994 00:53:20 GMT
|
|
|
|
M{kinen Sami J. (sjm@isosotka.cs.tut.fi) wrote:
|
|
|
|
|
|
: Has anyone tried the Genoa Phantom ET4000/W32i VLB
|
|
: display card with XFree86 ? I have 2MB of display
|
|
: memory installed, and I can only occassionally start
|
|
: up the XF86_Mono server in 800x600 mode. The other
|
|
: servers (XF86_SVGA, XF86_VGA16) will either cause
|
|
: the screen go all white and hang the whole system,
|
|
: or reboot instantly :(
|
|
|
|
That's strange...I tried one out for a day and got it to work under XFree
|
|
without any problems...
|
|
|
|
You have to set Chipset to "ET4000" since W32 is not supported (yet).
|
|
--
|
|
+---------------------------+---------------------------------+
|
|
| Lance Kinley | email: lkinley@ucdavis.edu |
|
|
| Consultant | login: itusul@dale.ucdavis.edu |
|
|
| Information Technology +---------------------------------|
|
|
| Campus Access Point |Linux 1.0: It's out & bug free :)|
|
|
|---------------------------+---------------------------------+
|
|
| 1400 Surge II, University of California, Davis 95616 |
|
|
+-------------------------------------------------------------+
|
|
|
|
------------------------------
|
|
|
|
|
|
** 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
|
|
******************************
|