Subject: Linux-Development Digest #561 From: Digestifier To: Linux-Development@senator-bedfellow.MIT.EDU Reply-To: Linux-Development@senator-bedfellow.MIT.EDU Date: Fri, 18 Mar 94 06:13:07 EST Linux-Development Digest #561, Volume #1 Fri, 18 Mar 94 06:13:07 EST Contents: Re: select (Chris Anderson) Andrew 6.1 for Linux: who did it? (Marko Schuetz) Re: select (Alan Cox) Re: 127.x.x.x (was Re: UDP report card) (Nick Hilliard) 486DLC support anyone? (Chris Thomas) Re: 127.x.x.x (was Re: UDP report card) (Mark Evans) Re: Real-Time Linux and a/d device drivers (Greg McGary) PRINTK from device driver not working?? (Robert Weir2) Re: kernel problem in 1.0 (Scott D. Heavner) Re: Real-Time Linux and a/d device drivers (Kwun Han) Re: 127.x.x.x (was Re: UDP report card) (Paul J. Gans) Re: 486DLC support anyone? (Superuser) Re: Little problem: ftp-data eth-ernal CLOSEing with pre-1.0 (Steve Kann) doesitwork w/ Conner CP-30540? (Ivan Soleimanipour) Printer Problems (Ken Kopilevich) ---------------------------------------------------------------------------- From: christop@access2.digex.net (Chris Anderson) Subject: Re: select Date: 16 Mar 1994 11:24:29 -0500 In article , Frank McCabe wrote: >A while ago I posted a request/comment about the select system call -- that >it doesnt properly timeout. > >The behaviour that is exhibited is that the select returns immediately, with a >value of 1 (i.e., one FD ready). >A subsequent recvfrom system call on the `ready' FD returns the error >ECONNREFUSED (which is a TCP -level error message on a UDP system call). > I noticed this too and posted it a while back. me>2. A sentto destination of my local address when there isn't a process bound me> to it, returns a ECONNREFUSED. I've never encountered this behavior before. Here is Alan's response: Alan>BSD only does this for 'fatal' errors. The internet RFC's are fairly specific Alan>that _all_ ICMP errors ought to be reported to the end user process. I'm still Alan>open to comments on this one, but security considerations certain favour Alan>following the RFC not BSD code. Alan>If you want BSD behaviour then change inet/udp.c:udp_err() so the line Alan>sk->err = icmp_error_convert[err & 0xff].errno; Alan> has Alan>if(icmp_error_convert[err&0xff].fatal) Alan>before it. I'm not sure of the utility of errors reported like this, since a common use of datagrams is programs with a lot of peers and determining which destination is invalid doesn't seem to be possible with the socket interface. Anyway, I just ignored them and did something like you are doing with EINTR. i.e.: switch(select(...)) { case -1: if (errno == EINTR || errno == ECONNREFUSED) goto again; } >Frank McCabe >------------------- >My opinions are mine - no-one else is allowed to have them > Chris ------------------------------ From: marko@hisplace.rhein-main.de (Marko Schuetz) Subject: Andrew 6.1 for Linux: who did it? Date: Tue, 15 Mar 1994 19:59:14 GMT I grabbed a copy of the Andrew Toolkit for Linux version 6.1 and I must say that this port definitely causes more problems than it solves. Most of all it seems incomplete. For example the .overview files are missing, templates are missing and much much more. Yet it's amazing to see what already does run, so I was wondering if anyone has solved all these problems and tailored a running Andrew >= 6.1. If so, I'd surely like to know where I can grab a copy. Marko -- --- Marko Sch"utz / Koselstr. 7 / D 60318 Frankfurt / Germany marko@hisplace.rhein-main.de / Tel: +49 69 5971621 ------------------------------ From: iiitac@uk.ac.swan.pyr (Alan Cox) Subject: Re: select Date: Thu, 17 Mar 1994 10:41:13 GMT In article chm@vlsivie.tuwien.ac.at (Christian Mautner) writes: > >: The behaviour that is exhibited is that the select returns immediately, with a >: value of 1 (i.e., one FD ready). >: A subsequent recvfrom system call on the `ready' FD returns the error >: ECONNREFUSED (which is a TCP -level error message on a UDP system call). > >I had the same problem once, I tried to select(2) a SOCK_DGRAM-Socket, >and, well, it showed exactly the same behavior: select returns 'yes' ;), >and when I recvfrom(2)ed, I got 'connection refused.' > >This was with Slackware 1.1.1 (99.14) and I didn't try it again with a >newer kernel. The same program worked on a sun without any problems and >as expected. It was surely not a problem of writing to the timeout-variable. > It work you up to receive the error report. You had previousely done a sendto() that had been rejectd and an ICMP_PORT_UNREACH message had been returned. Alan iiitac@pyr.swan.ac.uk ------------------------------ Crossposted-To: comp.protocols.tcp-ip From: nick@quay.ie (Nick Hilliard) Subject: Re: 127.x.x.x (was Re: UDP report card) Date: Thu, 17 Mar 1994 15:24:45 GMT Warner Losh (imp@boulder.parcplace.com) spoke thus: [...] : No. 127.* is a special network. It was born special. IP : implementations should ***ALWAYS*** ignore everything they get from : this address if it comes in over the wire and should ***NEVER*** send : packets to this address out over the wire. And it should do this be : default. Robust implementations should enforce this compeletely and : leave no room for the user to configure this. 127.* ARP requests as : well should never be on the wire, and completely ignored if they are : seen by a host on the wire. ICMP messages should likewise be treated. I've actually seen a network whose admin (in his infinite wisdom) uses the 127.* network for normal IP numbers. I.e. his machines are 127.0.0.2, 127.0.0.3, etc. Strangely enough, it actually works. Can't see why, though. Suffice it to say that there are only IBM implementations of TCP/IP on this network. Nick -- | Nick Hilliard | e-mail: nick@quay.ie | | Quay Financial Software, | Phone: [+353] 1 6612377 | | 48-53, Lower Mount St, | The opinions expressed above do not | | Dublin 2, Ireland | necessarily reflect those of my employers | ------------------------------ From: cjthomas@metronet.com (Chris Thomas) Subject: 486DLC support anyone? Date: Thu, 17 Mar 1994 03:26:39 GMT Hi, I just popped a TI486DLC cpu into my system only to discover that there is a DOS program that enables the internal cache on the chip. It works great for DOS, but linux is still kind of slow. Has anyone tried to add DLC support to the kernel? For that matter, does anyone know how to enable the internal cache of the CPU? ------------------------------ Crossposted-To: comp.protocols.tcp-ip From: evansmp@mb48026.aston.ac.uk (Mark Evans) Subject: Re: 127.x.x.x (was Re: UDP report card) Date: Thu, 17 Mar 1994 18:36:00 GMT Alan Cox (iiitac@uk.ac.swan.pyr) wrote: : In article imp@boulder.parcplace.com (Warner Losh) writes: : >I know of at least two commercial versions of IP that have had bug : >fixes applied to them that stop them from spitting out 127.* to the : >wire. I'm not aware of anything that supplants this requirement in : >RFC 1122. : > : >Any system that does spits 127.* to the wire is broken. : Any system which when supposedly 'correctly configured' spits 127.* to the : wire is broken. On that basis Linux is ok. On the other basis nothign is OK : because as route I can force the issue anyway. The problem with 'idiot proofing' a system is that 'idiots' can be highly resorceful :-) ------------------------------ From: gkm@tmn.com (Greg McGary) Subject: Re: Real-Time Linux and a/d device drivers Date: 17 Mar 1994 18:17:25 -0500 Reply-To: gkm@tmn.com (Greg McGary) | OK, so, when do we get started? :-) Seriously, thought, how hard would | a RT scheduling class be to implement? (Actually, I guess SVR4 has 3 | classes: RT, system, and TS. ... | How difficult would it be to write a bounded latency | real time scheduler, like Solaris 2 has? There are probably a lot of | problems that I haven't even considered, but I assume many parts of the | kernel would need to be rewritten.(?) Would every I/O call need to be | asynchronous for this to work? I haven't been following the UN*X industry for a few years now, so I can't answer any questions about what SVR4 or Solaris or any other random system XYZ do... But, I have mucked around the innards of realtime UN*Xes before, so I can offer some spiritual guidance. There are two important pieces of a realtime scheduler, one is easy to implement, and the other is hard. The easy part is having fixed scheduling priorities. So-called "timesharing" schedulers have mutable priorities--the OS raises the prority of sleeping procs so they have a better chance of getting the CPU when they awaken. This helps interactive jobs get better response time, and keeps them from getting swamped by CPU-bound jobs. By contrast, a realtime OS has no business mucking with the priorities of critical realtime jobs, they stay fixed at what the application programmers/administrators set them to. If more than one process has the same fixed priority, they are scheduled round-robin within their priority level. The scheduler I worked on had the priority space divided into two, with priorities from 0-127 being fixed realtime priorities, and 128-255 being lowly UN*X timesharing priorities. Ok, now that you have a scheduling algorithm that allows fixed priorities, how are you going to guarantee a small lower-bound on scheduling latency? Linux and traditional UN*Xes have single-threaded kernels, meaning that once a process is executing in kernel-mode, it keeps the CPU until it finishes the system-call, or explicitly gives up the CPU by sleeping. When a realtime OS gets an interrupt on a device of interest to a realtime process, it doesn't want to wait until some lower priority process finishes its system call or decides to sleep--IT WANTS THE CPU NOW! That means the kernel must be preemtable, and that's the hard part. A preemptable kernel needs fine-grain locking of individual data-structures (e.g., file-table, inode-table, mount-table, individual inodes, device-descriptors, etc.). By contrast, a non-preemptable kernel essentially has the ultimate coarse-grained locking policy; there's only one lock and it's system-wide: if a process has the CPU in kernel mode, it keeps it 'til it's done. My opinion is that it's too much work for too little benefit to make Linux preemptable. 99% of Linux users don't care about realtime, and those that do probably don't consider most PC I/O architectures up to the task (I'm not speaking with authority here, but I suspect this might be the case). It should be noted that preemptability is also a prerequisite for symmetric multiprocessing, which is potentially more interesting to Linux users, but not that much more interesting, since commodity Intel computer systems are uni-processors. If it ever happens that multiprocessors become cheap and widely available, then I think you'll see Linux evolve in this direction, but not otherwise. -- Greg McGary (703) 729-6217 gkm@tmn.com 525K East Market Street, #110, Leesburg, Virginia, 22075 ------------------------------ From: rob@pct2.farnborough.tt.slb.com (Robert Weir2) Subject: PRINTK from device driver not working?? Date: 16 Mar 1994 09:11:36 GMT I have developed a character device driver and to debug it I was using printk() function calls. This worked fine on Linux V0.99.13 & 0.99.14. I am currently using V0.19.15 with X-Windows being run at startup, by xadm in rc.local. When the PC boots up the prink's that show the dd has been installed work ok. But once the system has gone muli-user I looks like no printk's come out on any consoles. Can anyone help me?????? Thanks in advance. Robert Weir e-mail : weir@sif.sinet.slb.com ------------------------------ From: sdh@fishmonger.nouucp (Scott D. Heavner) Subject: Re: kernel problem in 1.0 Date: Wed, 16 Mar 1994 19:07:02 GMT Reply-To: sdh@po.cwru.edu matthew 'beautiful hair' mead (mmead@csugrad.cs.vt.edu) wrote: > I'm using the netstat from net 0.32, and I've experienced this with > a program that tried to select() a file descriptor that should have been > treated as a connection refused, but didn't for some reason. Here's what I get > dumped by the kernel upon the segmentation fault the program(s) receive: I've seen this problem too, under what might be similar circumstances. The kernel's finger is pointing at crond, but the last command crond tried to exec was to check if term was still connected, so I think it dumped from trsh which was trying to access an un-established unix socket. I've only seen it once and that was within two minutes of installing Linux 1.0 :( I can't reproduce it anywhere? crond spawns term_check every 15 mins and it hasn't died since, trsh on its own just reports "Connect: Invalid argument" which is normal behavior. Mar 16 01:15:00 fishmonger /ETC/CROND[104]: (root) CMD (/term/lib/term_check) Mar 16 01:15:00 fishmonger kernel: <6>Unable to handle kernel NULL pointer dereference at address 00000080 Mar 16 01:15:00 fishmonger kernel: <6>Oops: 0000 Mar 16 01:15:00 fishmonger kernel: <6>EIP: 0010:0012a720 Mar 16 01:15:00 fishmonger kernel: <6>EFLAGS: 00010246 Mar 16 01:15:00 fishmonger kernel: <6>eax: 0019e0e8 ebx: 00000000 ecx: 00193280 edx: 00187df0 Mar 16 01:15:00 fishmonger kernel: <6>esi: 00193280 edi: 00ef5380 ebp: 00000000 esp: 007d9f64 Mar 16 01:15:00 fishmonger kernel: <6>ds: 0018 es: 0018 fs: 002b gs: 002b ss: 0018 Mar 16 01:15:00 fishmonger kernel: <6>Pid: 105, process nr: 25 (crond) Mar 16 01:15:00 fishmonger kernel: <6>Stack: 00ff4840 bffff200 00ef5380 bffff200 007da000 Mar 16 01:15:00 fishmonger kernel: <6>Code: 8b 85 80 00 00 00 2b 85 84 00 00 00 25 ff 0f 00 00 ba ff 0f zSystem.map: 0012a648 t _unix_proto_write Scott ------------------------------ From: kwh@cs.brown.edu (Kwun Han) Subject: Re: Real-Time Linux and a/d device drivers Date: Thu, 17 Mar 1994 19:16:45 GMT In article <2ma2rj$22a@genesis.ait.psu.edu> donadio@mxd120.rh.psu.edu (Matthew Donadio) writes: Seriously, what I would like to see is kernel level threads. Pthreads exists right now, but only on the user level. Does anybody out there know anythings about how hard this would be to implement? I don't know much about kernel stuff (just a little about drivers), so I'm not one to begin work on it... Is pthreads available in Linux? If so, where? thanks! Kwun -- ********************************************************************* kwh@cs.brown.edu Box #2392, Brown University, ST002255@brownvm.brown.edu Providence, RI 02912 GE/CS d? p c++(+++) l(++)+++ u e+ m++@ s+/- n+@ h* f(+) g+ w+ t r- y? ********************************************************************* ------------------------------ From: gans@scholar.chem.nyu.edu (Paul J. Gans) Subject: Re: 127.x.x.x (was Re: UDP report card) Date: 17 Mar 1994 19:02:04 GMT Reply-To: gans@scholar.chem.nyu.edu Matthias Urlichs (urlichs@smurf.noris.de) wrote: [included stuff deleted] : Given that I've not heard of anybody who gets hurt by seeing spurious : 127.anything_but_0_0_1 IP or ARP packets on the wire, I don't think special : code in the kernel to catch that case is all that necessary. Not if it can : be caught by a simple routint table entry. Not so. There can be hurt. This behavior couples with the known bug that allows network connections to hang around for a while. The result is that *your* machine becomes unreachable until the bogus connections (eventually) time out. If we didn't have the "hanging around" bug, 127.0.0.1 on a network wouldn't be much of a problem, but since we do have the bug, it *is* a problem. Luckily it only shows up on crowded nets with misbehaving machines that do put 127.0.0.1 out on the net. To my sorrow, we have that problem here... To change the subject slightly, we seem to have reached some agreement in this thread. (1) 127.0.0.1 should never be put out on the network (although how that is to be done is still being argued about) and (2) no machine should respond to an external address of 127.0.0.1. At the moment (1) is taken care of in a properly configured linux machine, but (2) is still broken... ----- Paul J. Gans [gans@scholar.chem.nyu.edu] ------------------------------ From: root@fusion.cuc.ab.ca (Superuser) Subject: Re: 486DLC support anyone? Date: Fri, 18 Mar 1994 02:54:19 GMT cjthomas@metronet.com (Chris Thomas) writes: > Hi, > > I just popped a TI486DLC cpu into my system only to discover that there is a > DOS program that enables the internal cache on the chip. It works great > for DOS, but linux is still kind of slow. > > Has anyone tried to add DLC support to the kernel? For that matter, does > anyone know how to enable the internal cache of the CPU? > Grab CxPatch.tar.gz from sunsite.unc.edu in /pub/Linux/kernel/misc-patches (or thereabouts). 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: stevek@panix.com (Steve Kann) Subject: Re: Little problem: ftp-data eth-ernal CLOSEing with pre-1.0 Date: 17 Mar 1994 02:21:12 -0500 Romano Giannetti (romano@sensores2.fis.ucm.es) wrote: : 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 : ... I have had the same problems, and they are NOT ftp related. I don't even have a real ethernet - I only use loopback and term hacks, but when a process opens up a port, and then dies with something in the recv queue, the port never gets closed.. But I get CLOSE_WAIT and not Close in the state. I am pretty sure this is an old bug - but I am using pre-1.0 kernel now (and loopback only networking). - Steve : -- : ******************************************************************************* : 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 : ******************************************************************************* -- - Steve stevek@panix.com stevek@magnum.cooper.edu ------------------------------ From: ivan@djomolungma.Eng.Sun.COM (Ivan Soleimanipour) Subject: doesitwork w/ Conner CP-30540? Date: 17 Mar 1994 22:20:24 GMT Reply-To: ivan@djomolungma.Eng.Sun.COM I"m starting to get started with Linux, and was just about to by an extra hard disk (I already have another Conner that I"m happy with), when I saw the hardware FAQ and this hard drive wasn't on it. I'll be driving the disk through an Ultrastor SCSI Off off AMD bios. The question is, has anybody worked with this disk before, or should I be safe and get something off the recommended list? ------------------------------ From: kirill@crl.com (Ken Kopilevich) Subject: Printer Problems Date: 17 Mar 1994 23:42:08 -0800 Hi, everybody. I have linux installed on my computer very recently and now I have a proble with printing. My printer is HP DeskJet 500. And here is the problem : When I am trying to print file linux doesn't send CR to the printer. So All I get are linefeeds at the end of lines. Hence all I can print out are the first three lines on any file and they would look like this: Line one Line two Line three And so on. If someone has a solution please answer by mail to kirill@crl.com I will post the solution. Thank you, Ken. ------------------------------ ** 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 ******************************