Subject: Linux-Development Digest #543 From: Digestifier To: Linux-Development@senator-bedfellow.MIT.EDU Reply-To: Linux-Development@senator-bedfellow.MIT.EDU Date: Sat, 12 Mar 94 18:13:08 EST Linux-Development Digest #543, Volume #1 Sat, 12 Mar 94 18:13:08 EST Contents: Re: Adaptec 1542C SCSI with New ROM (komatsu@trl.ibm.co.jp) Re: UDP report card (Mark Evans) NCR 53c700 drivers available? (Marius Heuler) Re: select (Mark Evans) Support for ACCTON EtherPocket pocket ethernet adaptor? (Hui-Hui Hu) Re: UDP report card (gans) Re: YP or NIS for linux? (John F. Haugh II) Re: YP or NIS for linux? (John F. Haugh II) Wine Question (Elan Feingold) Changes in TCP retry code? (David Sisson) Re: Serious 80386 bug (Michael Will) Little problem: ftp-data eth-ernal CLOSEing with pre-1.0 (Romano Giannetti) tcpspray hangs up pl15j + pre-1.0, but not pl15i (Helge Schulz) ACCTON EtherPocket support for Linux? (Hui-Hui Hu) ---------------------------------------------------------------------------- From: komatsu@trl.ibm.co.jp Subject: Re: Adaptec 1542C SCSI with New ROM Date: 11 Mar 94 16:27:44 I have successfully installed on almost the same configlation by changing I/O address to 334. ==================================================================== komatsu@trl.ibm.com Tokyo Research LAB. Advanced Compiler Hideaki Komatsu ==================================================================== -- 小松 秀昭 (Hideaki Komatsu) Internet: komatsu@trl.vnet.ibm.com Advanced Compiler, CSI Junet: komatsu@trl.ibm.co.jp IBM Research, Tokyo Research Laboratory IBM VNET: KOMATSU at TRLVM ------------------------------ From: evansmp@mb48026.aston.ac.uk (Mark Evans) Subject: Re: UDP report card Date: Thu, 10 Mar 1994 17:48:28 GMT gans (gans@acf2.nyu.edu) wrote: : We've got a situation at NYU where a number of hostile entities : regularly broadcast 127.0.0.1 over the local net... And some : linux boxes, including mine, respond (which I do not think is : correct behavior). It is a common problem, 127.0.0.2 can be even more dangerous, quite a few machines only have 127.0.0.1 rather than 127.0.0.0 as a route to loopback. Thus such an address can end up going through serveral machines, simply being forwarded to default routes until it gets to a machine which accepts it. In some instances telnet 127.0.0.2 will connect you to a (psudo-random) machine somewhere on the internet. ------------------------------ From: heuler@cip.informatik.uni-wuerzburg.de (Marius Heuler) Subject: NCR 53c700 drivers available? Date: 10 Mar 1994 18:16:38 GMT Hello! Is there a driver for scsi cards with NCR 53C700-66 available or is someone working on one? Cards with this chip (e.g. TMC SP-382 or Forex FR600AF) seem to be really fast and pretty cheap (at least VLB version). Is the NCR 53C700 similar to the 53C810 for PCI bus? Will the same drivers work for both? Please excuse that many questions, but I'm looking for a fast and cheap VLB scsi adapter. That seems to difficult because some are fast but not cheap (e.g. Ultrastor 34F) and others are cheap but only fast enough for CD-ROMS. I hope someone could help Marius Marius Heuler # Friedenstrasse 11 - 97534 Theilheim Computer Science #------------------------------------------------------- Uni Wuerzburg # email : heuler@cip.informatik.uni-wuerzburg.de Germany # phone : + (49) 9384 - 1045 | + (49) 931 - 81412 ------------------------------ From: evansmp@mb48026.aston.ac.uk (Mark Evans) Subject: Re: select Date: Thu, 10 Mar 1994 17:54:09 GMT Matthias Urlichs (urlichs@smurf.noris.de) wrote: : In comp.os.linux.development, article , : fgm@doc.ic.ac.uk (Frank McCabe) writes: : > I have come across an apparent problem with the select system call. : > : Wrong. You've come across a bug in your program. This is the second example I have spotted of someone doing this.... : Yes. Read the documentation. You're reusing your timeout values. : The first time you call select(), it zeroes the variable because no more I thought it actually set the value to the time remaining of the original timout. Thus it zeros if the select ends due to a timeount. But it may not end up as zero if it is due to any fd's being ready. : time is remaining. The next time you're calling select(), the variable is : still zero. It could be that you will get unpridictable behaviour on timeout, before getting to the state of no timout. : This is mentioned in both the SunOS and Linux manpages for select(). What happens is that quite a few versions of select(), including on Suns, never write to the timeout. So what is actually broken code runs ok on them. ------------------------------ From: hdesiato@cs.umd.edu (Hui-Hui Hu) Subject: Support for ACCTON EtherPocket pocket ethernet adaptor? Date: 12 Mar 1994 12:23:17 -0500 [I'm cc'ing this to support at ACCTON. So to explain a bit of background, I'm trying to use an EtherPocket for Linux, a free UNIX clone for the i386+ architecture. This post is going out on the Linux development newsgroup.] I've recently purchased a EtherPocket 10baseT adaptor for a new notebook. There doesn't seem to be any driver written for this so far.. Anyone else got this out there? (model=EN2201.. "manual" (hehe :) gives this "technical information" : irq 5, 7; 8k buffer, 256-bit eprom) Oh well. ACCTON does include a packet driver for DOS as well as NDIS, ODI, and IPX stuff.. if I need to write a driver for this, where should I start? I am amazingly bad at coding :) would appreciate any pointers.. I can't find any Crynwr drivers .. just a *very* obscure 1 line statement in a PCNFS readme file: "When asked to identify the type of network interface card you are using, select "WD8003" [with IRQ 3 and IO 0x300]" I tried that with the Linux wd.c, but understandably got nothing. (I guess that refers to the emulation the PCNFS driver uses) Oh well. Any easy way out? I can send the packet driver to any interested skilled victims/experts out there :) OK, GPL question. The packet driver is based on "Packet driver skeleton copyright 1988-90, Russell Nelson." with the standard GPL disclaimer. I'm not sure if GPL says that the source code should be available from ACCTON ("Portions Copyright 1990-1992, ACCTON CO.,LTD.") From COPYING: -You must make sure that they, too, receive or can get the -source code. [snip] --3. You may copy and distribute the Program (or a portion or derivative of --it, under Paragraph 2) in object code or executable form under the terms of --Paragraphs 1 and 2 above provided that you also do one of the following: [a: accompany it with source code] [b: accompany it with an offer to distribute source code at nominal charge] [c: not applicable since this is a commercial distribution] Thanks for your help! -Hui-Hui Hu hdesiato@cs.umd.edu Oh, yea, another random question. Ever since I upgraded somewhere along the line in the pl15/prealpha kernels w gives "-" as the process no matter what. I recompiled procps-0.92 but no difference. Can someone point me to the latest version of w that works? Thnx again.. [Bad sign. ACCTON support host is unreachable :( ] ------------------------------ From: gans@acf2.nyu.edu (gans) Subject: Re: UDP report card Date: 10 Mar 1994 01:00:13 GMT evansmp@mb48025.aston.ac.uk (Mark Evans) writes: >Alan Cox (iiitac@swan.pyr) wrote: >: In article <2lj8f2$gis@access1.digex.net> christop@access1.digex.net (Chris Anderson) writes: >: >Three things seem kinda odd: >: > >: >1. A sendto INADDR_ANY as a destination gives me a ENETUNREACH. This errno is >: > new for me, in other environments the local process bound to either the >: > loopback or one of the machine's inet addresses gets the message. >: INADDR_ANY is counted as a broadcast address in Linux. Which is where this >: is coming from. Earlier pl15 systems also mistakenly return ENETUNREACH >Looking at the RFC's I think it should actually be invalid, as should anything not >a class A, B, C or D address. (Currently any invalid addresses including class >E ones are likely to get sent to the default router, which is probably not >a good idea). This check also applies to the destination of any received datagrams >(as well as an additional check that 127.X.X.X only came from the loop back device) >and any source routes. >Theoretically these should not be necessary, but they do conform to the guide line >of "Assume that the network is full of hostile entities" We've got a situation at NYU where a number of hostile entities regularly broadcast 127.0.0.1 over the local net... And some linux boxes, including mine, respond (which I do not think is correct behavior). ---- Paul J. Gans [gans@acf2.nyu.edu] ------------------------------ 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: Thu, 10 Mar 1994 04:31:49 GMT In article <2li09g$6il@celsius.ifm.liu.se> peter@ifm.liu.se (Peter Eriksson) writes: >You're really funny, did you know that? Why do I get the feeling your >feelings are hurt because I don't use your shadow stuff in NYS? You'd be wrong if that what's you thought. >(The major reason was that at the time when I wrote that stuff JFH's >shadow library wasn't LGPL'd. Another big reason was that I wanted >a set of *clean* functions and header files without all the compatibility >stuff for 4711 different unixes that pollutes JFH's shadow library). But Peter, you've made your code so clean it is no longer compatible with the largest base of systems supporting those functions -- SVR4 boxes. What has made Shadow so popular (at least it was popular enough to be stuffed into Linux ...) is that Shadow on one system is just like Shadow every where else. On my old SCO Xenix box I could say "group foo" and get a complete list of the groups "foo" belonged to. Even though Xenix doesn't support concurrent groups. When you start saying "I know better -- I'm going to do it right" you confront the very real possibility that 1). You don't know better. 2). Fewer people will use it because they can't afford to be incompatible with whatever else they must use. Why would I write anything for Linux that requires the use of getspnam() if I can't trust it to return "NULL" when there is no entry in /etc/shadow? If you'd follow the SVR4 semantics at least an application which cares can PORTABLY determine the existence of shadowed entries. >Btw, what's stopping you from writing your own NYS library with your >shadow stuff if you think my stuff is so bogus, wrong and totally useless? Given that your code is under the GPL this is a very real possibility. This is also one of the reasons I've never (and never will) place all of Shadow under the GPL. And I did get the note about the GDBM hooks being added. Putting NDBM support into NYS is a pretty likely occurance. Why limit myself to GDBM when NDBM is more widely available (given that every system which supports GDBM also supports NDBM). -- 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: Thu, 10 Mar 1994 04:35:13 GMT In article <2li66b$f62@gauss.ifm.liu.se> peter@ifm.liu.se (Peter Eriksson) writes: >If one is using NYS and ypserv or ypbind dies/hangs then one simply >logs in as root (since the root passwd and things are in >/etc/passwd+/etc/shadow and one keeps "files" ahead of "yp" >in "/etc/nsswitch.conf" line for "passwd") and then restarts >ypserv and/or ypbind if needed. Ah, the old assumption about just being able to login as root and make everything OK. What do you do when this happens and the only person with the root password is in Nebraska and you're in another state? RELIABILITY is something to be designed in. YP is a good way to start designing it out. Complexity and reliability are opposites. -- 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: elan@tasha.cheme.cornell.edu (Elan Feingold) Subject: Wine Question Date: 10 Mar 1994 20:46:55 GMT Reply-To: elan@tasha.cheme.cornell.edu (Elan Feingold) This may be a silly question, but when it is done, should it run most Windows programs, or only those that run in standard mode? I assume it could never run programs like Windows Mathematica, correct, because it fiddles with the processor mode? Of course, if it goes through the Win API or DMPI it has a chance, I guess? -elan -- =========================================================================== | Elan Feingold | | | CS/EE Depts. | | | Cornell University | ( .sig currently under construction ) | | Ithaca NY 14850 | | =========================================================================== ------------------------------ From: daves@megavolt.cc.vt.edu (David Sisson) Subject: Changes in TCP retry code? Date: 12 Mar 1994 18:16:28 GMT I'm using the pre-1.0 release version of the kernel that I patched up incrementally over time from 0.99pl15. Somewhere about 15h or so I noticed some momentary freezes when using a TCP connection to a site far away (18 hops). The strange thing is that the freezes are only of outgoing packets, never incoming packets. So I still can get output until my packet gets retried. 'netstat -c' shows my command is still trying to go out. Even closes of the socket don't appear to work normally. They *do* finish, but it usually takes a couple minutes to do so. I haven't seen any problems locally which is why I suspect a retry problem. I'm going to try backing up until I find a version that works. -- daves@vt.edu ------------------------------ From: michaelw@desaster.sunflower.sub.org (Michael Will) Subject: Re: Serious 80386 bug Date: Tue, 1 Mar 1994 03:23:11 GMT Tom@racing.demon.co.uk (Tom Raggett) writes: >I ran the attached code, on my two year old AMD 386sx25 with .99pl12. >It simply gave a Segmentation Fault and exited... >Sorry to disappoint you, but there was no nasty crash. It crashed as I run it as user "guest" on my AMD386dx33 with 0.99pl15h. I guess I will make a password to that account :-) The machine stopped completely, no reaction to the "three-finger-salute". I had to press the red button, the rootfs was a bit out of sync afterwards. :-) I bought this board in 1991... Cheers, Michael Will -- Michael Will Linux - share and enjoy :-) Life is not there if you can't share it... Hazel'O'Connor Breaking Glass Happily using Linux 0.99p15e with X11R5, ¥LaTeX, cnews/nn/uucp/TERM and: PGP! Analysis ist "kleiner Epsilon". ------------------------------ Subject: Little problem: ftp-data eth-ernal CLOSEing with pre-1.0 From: romano@sensores2.fis.ucm.es (Romano Giannetti) Date: 10 Mar 94 12:29:52 GMT Reply-To: romano@iet.unipi.it Hi all, I have a little problem that showed up in the long upgrading run from pl15 to pre1-0 (sorry I don't remember when). The problem shows up with ftp (I know, I know, this is not the right group for a ftp bug report, but wait...). While transferring, frequently pop-up the message "cannot open data connection" and I have to retry it. The problem is that, after, netstat -t shows: Proto Recv-Q Send-Q Local Address Foreign Address (State) ... tcp 1 0 sensores2.fis.ucm:1074 phoenix.doc.i:ftp-data CLOSE tcp 1 0 sensores2.fis.ucm:1309 arcfos1.arclc:ftp-data CLOSE ... and _no_ in.ftpd daemons or similars still run. Note that this CLOSEing are eternal, probably because there is something in the receiving queue. Now, shouldn't the kernel take care cleaning up this things if the processer (mis)using them die? In the (very) long run this could lead to problems to the network (or I am missing something important). BTW, there is a way of cleaning up this w/o reboot or ifconfig eth0 down and starting again all the network daemons? Thank you, Romano. -- ******************************************************************************* Romano Giannetti * DII-EIT, University of Pisa(E stands for Electronics) romano@iet.unipi.it * Dpto Electr. y Electronica, Facultad de Fisica * Universidad Complutense de Madrid ******************************************************************************* ------------------------------ From: helge@marvin.pc-labor.uni-bremen.de (Helge Schulz) Subject: tcpspray hangs up pl15j + pre-1.0, but not pl15i Date: 10 Mar 1994 14:13:22 GMT The command "tcpspray -e -n 10000 localhost" hangs up the pl15j and pre-1.0 Linux kernel. The tcpspray receiver process stops with a segmentation fault and the shell prompt returns but the system hangs up (no error message, no kernel panic, no VC switching, no reaction on Ctrl+Alt+Del, only Ctrl+Scroll-Lock and Shift+Scroll-Lock are still working but without writing to syslog). With pl15i and older (I have tested pl15, pl15a, pl15b, pl15d, pl15f, pl15h and pl15i) this doesn't happen ! But tcpspray stops with segmentation fault, too. Gdb says, that the fault happens inside read on the receiver socket. Calls with less blocks (without "-n 10000") works normaly fine. Only sometimes they stops with a segmentation fault, too. I used tcpspray.1.1a.tar.z from sunsite (‾linux/system/Network) without any modifications. configuration: Cyrix 486DLC 40 MHz, 16 MB RAM, 340 MB AT-Bus harddisc libc-4.5.21, ld.so-1.4.3, gcc-2.5.8, net-2 inetd Helge ||| / Helge Schulz ¥ (o.o) | University of Bremen, Germany | v ¥ helge@marvin.pc-labor.uni-bremen.de / ------------------------------ From: hdesiato@cs.umd.edu (Hui-Hui Hu) Subject: ACCTON EtherPocket support for Linux? Date: 12 Mar 1994 13:20:06 -0500 [makes gurgling sound] [Looks like my post didn't get thru. *sigh*] I recently bought an ACCTON EtherPocket parallel 10BaseT adaptor for my notebook. Was wondering if there is anyone else out there that either has a driver, has a clue where to find one, would give me help in writing one, etc. ["technical information" :) from the manual - irq 5,7; 8k buffer, 256-bit EPROM) I can't find anything helpful on the disk that's included except for a packet driver I can use for DOS - interestingly the skeleton is based on the GPL: "Packet driver skeleton copyright 1988-90, Russell Nelson." "This program is free software; see the file COPYING for details." (etc) Does the GPL says that ACCTON should offer/release the source code? From COPYING: 3. You may copy and distribute the Program (or a portion or derivative of it, under Paragraph 2) in object code or executable form under the terms of Paragraphs 1 and 2 above provided that you also do one of the following: [a: include complete source code] [b: accompany executable with offer to distribute source code for nominal fee] [c: not applicable because this is a commercial product] I haven't been able to contact ACCTON yet, I'll try later today. Meanwhile, has this already been done, or could anyone point me in the right direction for writing such a driver? (keep in mind I am a clueless computer freak :) Thanks.. -Hui-Hui Hu hdesiato@cs.umd.edu another q: "w" doesn't display the processes right since I've upgraded to pre-alpha from pl15 stock.. the names are "-". I've recompiled procps-0.92 but to no avail. Does anyone have a newer version? apologies if you see this message twice. ------------------------------ ** 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 ******************************