From: Digestifier To: Linux-Development@senator-bedfellow.mit.edu Reply-To: Linux-Development@senator-bedfellow.mit.edu Date: Sat, 2 Apr 94 15:13:09 EST Subject: Linux-Development Digest #597 Linux-Development Digest #597, Volume #1 Sat, 2 Apr 94 15:13:09 EST Contents: Re: IDE Performance Package (Superuser) dblspace for umsdos using dosemu (Ron Jones) LINUX port to a trnasputer systemIn article GEp@si.hhs.nl, Antoni.Ba (v922215@si.hhs.nl) Could someone uuencode and post kernel.tgz from diskd4 of slackware (Phillips, James Glenn, IV) Re: Kernel compile dying w/SIGSEGV (macleod@adoc.xerox.com) Re: Async I/O (dave@valhalla.ee.rochester.edu) Re: unsupported keys (scancode (xx) not in range 00 - 5f) (gt8134b@prism.gatech.edu) Re: Specialix Driver Round 2 (From specialix) (bof@wg.saar.de) Re: LINUX port to a transputer system (Arthur) Re: Specialix Driver Round 2 (From specialix) (iiitac@uk.ac.swan.pyr) Re: IPX compliancy? (iiitac@uk.ac.swan.pyr) Bug in TIOCCONS ioctl ? (braun@physik.uni-kl.de) Re: Slackware as a tar.gz file? (cdent@yod.honors.indiana.edu) Re: LINUX port to a transputer system (arnold@sienna.dstc.edu.au) Re: Kernel compile dying w/SIGSEGV (mitchell@mdd.comm.mot.com) Re: Linux <--> DOS PLIP??? (pbauer@rnivh.rni.sub.org) ISDN driver sought (leitner@inf.fu-berlin.de) Linux CD Rom with Wearnes (scornd7@solomon.technet.sg) ---------------------------------------------------------------------------- From: root@fusion.cuc.ab.ca (Superuser) Subject: Re: IDE Performance Package Date: Fri, 1 Apr 1994 02:14:56 GMT mlord@bnr.ca (Mark Lord) writes: > In article <2ndj10$8gb@levelland.cs.utexas.edu> danielsi@cs.utexas.edu writes: > > > >I've installed the ide performance package upon linux 1.0 and have found > >the following: Whenever I have disk activity, the mouse jumps around under X. > > The *only* possible way that the performance patches could cause this > is if you are using multiple mode *without* allowing the driver to > unmask interrupts. I installed the first IDE performance patch, and seeing that the default was to unmask interrupts, I thought that perhaps the problems associated with unmasking the interrupts had been solved, so I left the setting as is.. Unfortunately, unmasking interrupts caused my disks to be seriously trashed. And although e2fsck seemed to repair the damage, there were many files I had to re-install and many others that I had to re-create... I'm still not 100% confident that the file system is "back to normal", even though it's been several weeks now without incident. I think it's a bad idea for the default to be unmasked interrupts. In any patch/package where there is a significant risk of data loss, all the settings should be such that the it will not cause problems for the majority of systems, even at the expense of lost performance. If you want to take a chance, you can enable these risky features, but they definitely should not be on by default. > > On my system and on many others, the exact opposite behaviour is observed > when the patches are applied and interrupt unmasking is enabled.. the mouse > goes from very unresponsive to more responsive. > -- > mlord@bnr.ca Mark Lord BNR Ottawa,Canada 613-763-7482 c4 -- Christopher Lau- "Mr. Unix" | / Fusion: Playing With Fire! StarBright Research | / / H + H -> He + 24 MeV -- | /_/_/_ "Bring back Trudeau!" root,lauc@fusion.cuc.ab.ca |____________ "This space for rent" ------------------------------ From: ron@pedi.ama.ttu.edu (Ron Jones) Subject: dblspace for umsdos using dosemu Date: 2 Apr 1994 04:26:44 -0600 To umsdos and dosemu hackers: I have been using the ALPHA 0.2 umsdos fs version of Slackware 99.15 and have enjoyed having Linux co-existing my MS-DOS formated HD, without re-partitioning. My only wish for umsdos is that it would support dblspaced (compressed) harddrives; however, I have an idea for a solution: Besides experimenting with Linux and it's umsdos fs variant, I also have messed with dosemu. It seems to me that dosemu could be modified/merged into umsdos to provide the necessary linkage to a doublespaced or stacker logical hd. This would avoid entirely the problem of trying to come up with dblspace or stacker compatible routines. If I understood the docs correctly, umsdos fs was mostly a hack of the dos fs code. It seems natural that the dosemu code be cannibalized (strip out every- thing except what is necessary for MS-DOS to boot and load the dblspace.bin to mount the compressed-volume-file harddisk) so as to add dblspace compression to umsdos. Some additional interface code may or may not be necessary at this point. Basically, the emudos (using it's dos fs code) should now talk to the hacked dosemu (who is running MS-DOS & dblspace) for it's disk accesses instead of talking to the hd device driver or dos parition directly. Regards, Ron Jones ron@pedi.ama.ttu.edu ------------------------------ From: v922215@si.hhs.nl (v922215@si.hhs.nl) Date: 29 Mar 94 07:40:26 +0000 Subject: LINUX port to a trnasputer systemIn article GEp@si.hhs.nl, Antoni.Ba From: v922215@si.hhs.nl (Baranski, A.S.) Date: Tue, 29 Mar 1994 07:40:26 GMT FIRST OF ALL SORRY FOR THE TOOOO LONNNNG LINEESSSSSSS. Hi world, So far I have received many reactions from GREAT to shut this guy up in a lunny bin. But I think that most people didn't really understand my first message. I said I wanted to have the 486 do all the I/O work and thus working as a server with the transputer as client. Well I've been searching high and low in articels concering transputer hardware. And found some advertisments about SCSI 1/2 controllers as a T-RAM module. So the need for ans AFS (Alien file server) might not be so great, or maybe it would because I would need a way to boot the transputer (it would be possible to boot from a EPROM).. And now let me try to explain the idea again, so simple as possible: The idea was that it would be possible to open a window under LINUX with X11 and have the Transputer running in there. Doing some number crunching in parallel with the 486. And there for a part of the LINUX code would be needed to run on the Transputer. The port wouldn't be written in OCCAM 2 because that would give me a HUGE pain in the BUM!!!! Because of the way how OCCAM 2 is written. But in C and compiled with a 3L-C Compiler. Which I am planning on buying soon. If I can get it for a nice price. And not for 600 pounds which is around 1800 Guilders and that's a bit much, for a student that has to live of something around 300 guilders a month. So I'll be looking at 3L if they don't have a studente version or a student price, for their compiler. Or if someone out there in internet land would like to part with his 3L compiler, I am interested.!!! I hope this makes life easyer for you folks out there. SU ================ Baranski, A. S. | Haagse HogeSchool e-Mail: | Sector Informtica Antoni.Baranski@si.hhs.nl | Student Software Engineering P.S. Sorry to all of you who couldn't read the first posting ........ Keywords: ------------------------------ From: JP8659@CONRAD.APPSTATE.EDU (Phillips, James Glenn, IV ) Subject: Could someone uuencode and post kernel.tgz from diskd4 of slackware Date: 2 Apr 1994 04:24:52 GMT I'm in the process of installing Linux via FTP. But I don't have any kind of direct connection to the internet so I have to ftp everything to my vax account and then sz it to my box.. But I've got a 2000block limit on my account.. Which means that all the files bigger than about 950k are too big.. thus I can't get kernel.tgz from diskd4 of the slackware distribution.. could someone uuencode it and post? Thanx in advance.. Jim Phillips(jp8659@appstate.edu) ------------------------------ From: macleod@adoc.xerox.com (macleod@adoc.xerox.com) Date: 29 Mar 94 02:21:24 +0000 Subject: Re: Kernel compile dying w/SIGSEGV From: macleod@adoc.xerox.com (Peter MacLeod) Date: 29 Mar 1994 02:21:24 GMT Douglas Donahue (odoncaoa@panix.com) wrote: : Greetings, : Over the course of the weekend, I attempted to recompile the kernel. The first : attempt was sucessful. However, subsequent attempts failed with what would : appear to have been segmentation violations. A representative error message : follows. The strange part of it though, is that the compile failed at a very : early point in the remake on one attempt, but breazed right through the same : point in the compile on a subsequent attempt. It's obvious to me that there : are not any errors in the source that are generating such problems. e.g. : dividing by zero. Has anyone else had such experiences? How about one of the : compiler and/or kernel experts speaking up? What would cause the compiler to : fail with a segmentation violation when one doesn't actually exist? What : would cause the kernel to generate such a signal and kill the compiler? [etc] I used to get this all the time. Then I changed the timing on my motherboard, and it went away completely--I haven't had a problem since, and I've rebuilt the kernel many times. This has been discussed before, and the culprits blamed were ISA<->memory transfers, motherboard memory itself, and the phases of the moon. It would appear that simple tests, especially DOS- or Windows-based tests, don't pound the machine hard enough, so rebuilding the Linux kernel is a pretty good test. In any case, you can imagine that if gcc started paging, and one of the paging transfers had an error in it, thus changing the code, you could get a seg. violation. One problem with the kernel, at least the last time I looked, is that a lot of the hardware traps are mapped to one signal, segmentation violation. I'm not sure if that's a POSIX thing or what, but it does make figuring out what's going on a bit of a hassle. Anyway, if your motherboard has lots of settings like mine does, start changing things like ISA bus speed, DRAM wait states, ISA bus wait states, etc. If it doesn't, you might be SOL. I think the thing I did that made the most dramatic difference was slowing the ISA bus down to 8 Mhz. A lot of motherboards have a 12Mhz setting, and many ISA bus cards are unreliable at 12Mhz. Others have found that replacing SIMMs cured their problems. Also, if you have a 50Mhz DX motherboard, like I do, you might just want to replace it with a 66Mhz DX2...Oh, another thing I've remembered--when I first got my motherboard, it crashed a lot, and the problem turned out to be that I had a 50Mhz motherboard with cache RAM for a 33Mhz motherboard, so make sure that your cache SRAMs are fast enough. -- Peter ------------------------------ From: dave@valhalla.ee.rochester.edu (dave@valhalla.ee.rochester.edu) Date: 28 Mar 94 17:52:03 +0000 Subject: Re: Async I/O From: dave@valhalla.ee.rochester.edu (David F. Carlson) Date: 28 Mar 1994 12:52:03 -0500 May I suggest rather than using MVS as a model for your async I/O support, get a recent draft of the IEEE POSIX1003.4 (nee' 1b) standard. This was recently ratified by the IEEE real-time POSIX committee and although not perfect contains much insight into the problems you discuss. The hassle is that the IEEE has decided to make money on their standards so the documents are not ftp'able. Since Linux is already 1003.1 compliant, getting the pieces to 1003.4 in place seems like the "Portable" thing to do. dave ------------------------------ From: gt8134b@prism.gatech.edu (gt8134b@prism.gatech.edu) Date: 27 Mar 94 17:45:58 +0000 Subject: Re: unsupported keys (scancode (xx) not in range 00 - 5f) From: gt8134b@prism.gatech.edu (Robert Sanders) Date: 27 Mar 1994 12:45:58 -0500 kaz@lilia.iijnet.or.jp (Kaz Sasayama) writes: >My keyboard generates scancodes not in range 00 - 5f for some keys. >How can I use them? >press any key (program terminates after 10s of last keypress)... >0x9c >0x7b >0xfb >0x79 >0xf9 >0x70 >0xf0 >0x7d >0xfd Are you using one of the newer "programmable" keyboards, such as the Northgage Omnikey or the Focus 9001? I'm using the latter, and get similar messages when I press the PF keys. I just got the keyboard, but I'll look into it when I get the time. -- _g, '96 --->>>>>>>>>> gt8134b@prism.gatech.edu <<<<<<<<<--- CompSci ,g_ W@@@W__ |-\ ^ | disclaimer: <---> "Bow before ZOD!" __W@@@W W@@@@**~~~' ro|-Is there any problem in givin "Souce" consisting of some sequence of >"Define_Byte ##" >statements in an "xyz.S" - File ?? Speculations about how to circumvent the GPL should go to gnu.misc.discuss only. Followup-To: is set. The GPL says: The source code for a work means the preferred form of the work for making modifications to it. I think this explicitly forbids your proposal, and rightly so, because what you propose is the same as an .o file - I can trivially convert the .o file to an .s file that will recreate the .o after assembly, so the two forms are the same. IMO binary-only driver distributions would clearly violate the GPL, and it is up to Linus to allow them explicitly. I also think it would be a Good Thing to do that. regards Patrick ------------------------------ From: Arthur%2476-451-99@logo.ka.sub.org (Arthur) Date: 24 Mar 94 05:05:22 +0000 Subject: Re: LINUX port to a transputer system From: Arthur Raiskio (arthur@dpi.qld.gov.au) Date: Thu, 24 Mar 1994 05:05:22 GMT In article Antoni.Baranski@si.hhs.nl writes: > I must say that I am new to LINUX and have never ported any software that realy >worked after the porting. > I am currently doing a port of gcc2.5.8 to a t8000 transputer as part of my Master of Computer Science requirements and I can tell you that that is hard enough without having to worry about that weird transputer architecture for other things. My suggestion is try if you want to but prehaps your first port should be something smaller unless you are really aware of the subtle details of the compiler, filesystems etc. > I under stand that big portions of the LINUX kernel are written in assembly, and >that is a point I fear I migth get into a lot of trouble because my knowlegde of >assembly isn't that great. And programming the transputer is assembly well, no >thank you. So I would have to translate all the assembly into C/C++. The kernel code I have changed has been mostly C anyway. There is possibly some assembler still but it is a fairly small amount. > > SO, if my idea is crazy please let me know. From my experience with just gcc so far I would say "commit him he must be insane!!!" Regards Arthur Raiskio (arthur@dpi.qld.gov.au) ------------------------------ From: iiitac@uk.ac.swan.pyr (iiitac@uk.ac.swan.pyr) Date: 28 Mar 94 11:45:46 +0000 Subject: Re: Specialix Driver Round 2 (From specialix) From: iiitac@uk.ac.swan.pyr (Alan Cox) Date: Mon, 28 Mar 1994 11:45:46 GMT In article <1994Mar23.182432.20120@kbbs.kiel.sub.org> hp@kbbs.kiel.sub.org (Holger Petersen) writes: >rogers@drax.isi.edu (Craig Milo Rogers) writes: > >> Revealing that part of the host-side driver, as by publishing >>its source code, would reveal details of the host-side interface which >>(at least one) vendor wishes to keep a trade secret. That's their problem. You can always reverse engineer it. > >Is ther any part in the Gnu-licence that says: > > "You have to use 'C' as _the_ language " ?? > No but you are required to give the source in its 'preferred form' so you can't scramble it up and shield it. Alan ------------------------------ From: iiitac@uk.ac.swan.pyr (iiitac@uk.ac.swan.pyr) Date: 28 Mar 94 11:50:49 +0000 Subject: Re: IPX compliancy? From: iiitac@uk.ac.swan.pyr (Alan Cox) Date: Mon, 28 Mar 1994 11:50:49 GMT In article tierney@rintintin.Colorado.EDU (Craig Tierney) writes: >Someone has already done the reverse-engineering. In Dr. Dobbs Journal a >few months back, the NCP (Netware Core Protocol) was documented. The NCP >is how the Shell(Netx) communicates with the server, on top of IPX. >There is also a book that is being released about Netware that covers >many of the undocumented aspects. If you've tried playing with this you'll find that its not accurate and it doesn't cover a lot of the 'hard' stuff like mapping a drive. I got a server hack as far as login then got too busy. Alan ------------------------------ From: braun@physik.uni-kl.de (braun@physik.uni-kl.de) Date: 29 Mar 94 15:33:59 +0000 Subject: Bug in TIOCCONS ioctl ? From: braun@physik.uni-kl.de (Martin Braun) Date: Tue, 29 Mar 1994 15:33:59 GMT Hello all, Yesterday I tried to make xconsole work for normal users and found that it is not sufficient to set proper permissions for /dev/console. The method used by xconsole to catch console output is as follows (xconsole.c:OpenConsole): . . . struct stat sbuf; /* must be owner and have read/write permission */ if (!stat("/dev/console", &sbuf) && (sbuf.st_uid == getuid()) && !access("/dev/console", R_OK|W_OK)) { . . . #if defined(USE_PTY) && !defined(SOLX86) int on = 1; if (get_pty (&pty_fd, &tty_fd, ttydev, ptydev) == 0 && ioctl (tty_fd, TIOCCONS, (char *) &on) != -1) { input = fdopen (pty_fd, "r"); } #endif . . . Even though the permissions for /dev/console are set properly this fails in the TIOCCONS ioctl (output of strace): ... stat("/dev/console", {dev 3 2 ino 42 mode 020622 nlink 1 uid 1418 gid 1400 size 0 ...}) = 0 getuid() = 1418 access("/dev/console", 06) = 0 open("/dev/ptyp0", RDWR) = -1 (Try again) open("/dev/ptyp1", RDWR) = 4 open("/dev/ttyp1", RDWR) = 5 ioctl(5, TIOCCONS, 0xbffffb04) = -1 (Operation not permitted) ... This happens because under linux this ioctl may only be used by root (from linux/drivers/char/tty_ioctl.c:tty_ioctl): . . case TIOCCONS: if (IS_A_CONSOLE(dev)) { if (!suser()) return -EPERM; redirect = NULL; return 0; } if (redirect) return -EBUSY; if (!suser()) return -EPERM; if (IS_A_PTY_MASTER(dev)) redirect = other_tty; else if (IS_A_PTY_SLAVE(dev)) redirect = tty; else return -ENOTTY; return 0; case FIONBIO: . . IMHO this is a bug which breaks xconsole. I am not a kernel hacker and can't provide a fix for it. Suggestions and comments are appreciated. Best regards, Martin Braun (braun@physik.uni-kl.de) PS: Configuration: Linux-1.0.4, libc-4.5.21, Xfree86-2.1, gcc-2.5.8 ------------------------------ From: cdent@yod.honors.indiana.edu (cdent@yod.honors.indiana.edu) Date: 30 Mar 94 02:32:43 +0000 Subject: Re: Slackware as a tar.gz file? From: cdent@yod.honors.indiana.edu (NetDog) Date: Wed, 30 Mar 1994 02:32:43 GMT >>>>> "Jerome" == Jerome Kaidor writes: Jerome> I dreamt of a script that would activate FTP, tell it Jerome> to get slackware.tar, and pipe its output straight up to Jerome> tar on my machine, which would then spew out files and Jerome> directories. Probably an impossible dream...... One possibility is to use mirror, the package that some archive sites use to keep up their mirrors. I can be set up to get an entire director and subdirectories. This is what the config file would look like for slackware: package=slackware comment=The Linux Slackware Distribution site=ftp.cdrom.com remote_dir=pub/linux/slackware local_dir=/foo/bar/slackware mail_to=foofoo The mirror package is available at: src.doc.ic.ac.uk [146.169.2.1] directory: computing/archiving/mirror (shortcut packages/mirror) Although it was originally intended to be used for continuous upkeep of a collectin it works great for getting files just once. One thing you have to watch out for (especially if you are doing the ftpping from a linux box): check the logs when the program has finished for the files that it timed out on. You will have to go back and get those; either by hand or just run mirror again (it only gets files it doesn't already have). Chris -- cdent@indiana.edu|"if you're so special why aren't you dead?"-TheBreeders ------------------------------ From: arnold@sienna.dstc.edu.au (arnold@sienna.dstc.edu.au) Date: 28 Mar 94 23:52:08 +0000 Subject: Re: LINUX port to a transputer system From: arnold@sienna.dstc.edu.au (David Arnold) Date: 28 Mar 1994 23:52:08 GMT In article 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 :-) While I wouldn't like to discourage your creative efforts, there's a few things you should know before you start. From my limited understanding of the internal structure of the Linux kernel and also based on what it provides to the programmer, I don't think that it will be possible to port the kernel to the T4/8 series transputer architecture. The T4/8 series transputers do not have the hardware to support virtual memory. Nor do they have the ability to protect areas of memory from other processes. Since these are the fundamental assumptions made in the Linux kernel, I think this is where you luck out ... 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. Yes, it is possible to send signals to the Intel CPU, depending on what protocol you use between the T80x and the x86. However, assuming that you are going to be using standard transputer boards, the major problem is the bandwidth available between the two CPUs. However, it might be possible to come up with a reasonable way to pass system calls back to the x86. The difficulty will be that the kernel will not have access to the memory of the processes. Memory mapping is not possible with standard hardware. Not much of the Linux kernel is written in assembler, check with the header files in /usr/include/asm. Non-assembler versions of the string routines as found in /usr/include/linux/strings.h are found in the GNU C-Library for example. But you may have to learn about your Transputer's assembly to get things rolling. Yep - I'd think so too. And once you've done that, you might want to reconsider. Transputer assembly reflectes the CPU architecture, and it's a long way from that of the x86 ! Overall, the best approach may be to look at Minix instead. For one thing, there is already someone working on a port to the T4/8 CPUs which is always a good thing. The major advantage though is that Minix does not (in the base 1.6 version) provide virtual memory. It allocates fixed size memory areas to processes - which should suit the transputer very well. You could then allocate a guard area at the end of the stack, and check it sometimes to make sure that the stack hasn't overflowed. The kernel structure of Minix is also suitable for transputers. It is composed of a number of independant processes that communicate using small messages. I would think that with some hacking you should be able to put a memory manager and scheduler on each processor, and get them to cooperate in executing processes. The filesystem could run either on the x86 or the root transputer. Another thing that might be fun - I think that the original Minix filesystem is single threaded. It would make sense to rewrite this as a multi-threaded server. In my opinion, this project would provide a similar amount of 'fun' but with a much lower frustration potential that attempting to port Linux. Who knows, it might even be working by the end of your holidays ? davida -- David Arnold ================================================================== CRC for Distributed Systems Technology arnold@dstc.edu.au University of Queensland voice +617 3654367 Australia fax +617 3654311 -- David Arnold ================================================================== CRC for Distributed Systems Technology arnold@dstc.edu.au University of Queensland voice +617 3654367 Australia fax +617 3654311 ------------------------------ From: mitchell@mdd.comm.mot.com (mitchell@mdd.comm.mot.com) Date: 28 Mar 94 22:52:21 +0000 Subject: Re: Kernel compile dying w/SIGSEGV From: mitchell@mdd.comm.mot.com (Bill Mitchell) Date: 28 Mar 1994 14:52:21 -0800 in comp.os.linux.development, odoncaoa@panix.com (Douglas Donahue) said: >[...] >A representative failure message: >. >. >gcc -D__KERNEL__ -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -pipe \ > -m386 -c -o init/main.o init/main.c >gcc: Internal compiler error: program cc1 got fatal signal 11 >make: ***[init/main.o] Error 1 >cpp: output pipe has been closed Just a followup to say that at least one other has similar woes. I started at 0.99pl8, and kernel rebuilds were rock solid for a while. Somewhere around pl12, I started seeing just exactly what is reported above. I'm still seeing it with pl15h. I've commented about it a couple of times in comp.os.linix.whatever, and responses indicated that it had to be a hardware error. That's reinforced by rock-solid rebuilds on other linux installations. However, I don't recall seeing anything like this with anything but cc, and can't localize it to a hardware problems. Exercising the disks by copying massive amounts of data works OK, and standalone memory-test programs run overnight report no problems. For now, I'm just living with it. I restart "make zImage" as needed, and reboot if that doesn't work (the problem appears less frequently on a recently booted system). -- mitchell@mdd.comm.mot.com (Bill Mitchell) ------------------------------ From: pbauer@rnivh.rni.sub.org (pbauer@rnivh.rni.sub.org) Date: 28 Mar 94 00:00:53 +0000 Subject: Re: Linux <--> DOS PLIP??? From: pbauer@rnivh.rni.sub.org (Peter Bauer) Date: Mon, 28 Mar 1994 00:00:53 GMT I have currently a plip-connection running between a linux-box and msdos running crynwr plip.com and ncsa-telnet or pcip_pkt. The changes I made are: - strobe bit-levels need to be inverted - throw out plip_type logic: send as ethernet would do - length byte order inverted - there was a "bug" in the send_byte: To allow the data-bits to settle first before they are strobed, they were put without the strobe bit first, but without masking off the high nibble of the data, so sometimes (if data's 0x10 bit was set, this settle-logic failed, and this resulted in receive-errors in dos-plip.com, because there is only a single asm-in, which is not repeated after the strobe is seen ... If someone wants the diffs, send mail ... Gruss PB ------------------------------ From: leitner@inf.fu-berlin.de (leitner@inf.fu-berlin.de) Date: 25 Mar 94 18:55:30 +0000 Subject: ISDN driver sought From: leitner@inf.fu-berlin.de (Felix von Leitner) Date: Fri, 25 Mar 1994 18:55:30 GMT Hi ! I Am am looking for ISDN drivers for ILinux. Please mail me where to find one ! Thanks, Felix -- (----------------------------------------------------------------) Felix von Leitner, Gervinusstrasse 22, 10629 Berlin, +49-30-3242987 President of the Council of Ultimate Wisdom High Druid of the Circle of the Ancient Shrub ------------------------------ From: scornd7@solomon.technet.sg (scornd7@solomon.technet.sg) Date: 28 Mar 94 08:22:06 +0000 Subject: Linux CD Rom with Wearnes From: scornd7@solomon.technet.sg (Tang Chang Thai) Date: 28 Mar 1994 08:22:06 GMT I am looking for a version of Linux CD Rom that can work with the Wearnes CD Rom package. Any suggestions? ------------------------------ ** 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 ******************************