Subject: Linux-Development Digest #534 From: Digestifier To: Linux-Development@senator-bedfellow.MIT.EDU Reply-To: Linux-Development@senator-bedfellow.MIT.EDU Date: Thu, 10 Mar 94 03:13:07 EST Linux-Development Digest #534, Volume #1 Thu, 10 Mar 94 03:13:07 EST Contents: Re: Memory Allocation (was Re: AMD 486DX problem (with Linux?)) (Nick Holloway) Re: select (Matthias Urlichs) Re: Linux/Windows (Gonzalo Diethelm) Re: Small pre-1.0 problem (Achim Oppelt) Re: AMD 486DX problem (with Linux?) (Robert Ebe) ** Bug in hp.c HPLAN driver ** (Laurent JULLIARD LAB GND 1267) Re: GOD SPEAKS ON LINUX! (Arthur Tateishi) Re: UDP report card (Mark Evans) Re: select (Mark Evans) Re: AMD 486DX problem (with Linux?) (Robert Ebe) Re: GOD SPEAKS ON LINUX! (Grant Taylor) gcc internal compiler error - SIGSE[2~EGV (Christopher Andrew Smith) Re: AMD 486DX problem (with Linux?) (Ralf Messerer) ---------------------------------------------------------------------------- From: alfie@dcs.warwick.ac.uk (Nick Holloway) Subject: Re: Memory Allocation (was Re: AMD 486DX problem (with Linux?)) Date: Wed, 9 Mar 1994 16:18:10 GMT In <2lknvi$b5f@serra.unipi.it> romano@pimac2.iet.unipi.it (Romano Giannetti) writes: > [enquire.c] > But _before_ comment out the following lines around line#450: > > while (size!=0) { > while (malloc(size)!=(char *)NULL) > total+=(size/2); > size/=2; > } > > that drive my Linux box to a quiet dead :-) after a lot of swapping. > BTW: is this normal? I cannot afford test it on another Unix. My conf > is Linux pre-1.0, 8M ram, 16M swap. The box don't crash nor panic, > only get more and more slow if I don't ctrl-c the program. This program defeats Linux's ``don't grab all the memory'' heuristic. Linus did say that it would be possible to defeat, and this does it. The good news is that it doesn't actually die -- eventually (have a coffee :-) the process gets killed by the system. -- Nick Holloway | `O O' | alfie@dcs.warwick.ac.uk, alfie@warwick.UUCP, [aka `Alfie'] | // ^ \\ | ..!uunet!mcsun!uknet!warwick!alfie ------------------------------ From: urlichs@smurf.noris.de (Matthias Urlichs) Subject: Re: select Date: 9 Mar 1994 17:30:25 +0100 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. > According to the specification, if select is given a non-zero timeout then > the system call is supposed to wait for the appropriate interval before > terminating. > > Well it doesnt! If you give a non-zero timeout the nit comes back immediately. > > I know that this is not my problem, because the same (i.e. identical) program > behaves as expected on a sun sparc under suno 4.1.13. > > Are there any known fixes for this? > Yes. Read the documentation. You're reusing your timeout values. The first time you call select(), it zeroes the variable because no more time is remaining. The next time you're calling select(), the variable is still zero. This is mentioned in both the SunOS and Linux manpages for select(). -- "The raytracer of justices recurses slowly, but it renders exceedingly fine." -- Larry Phillips (lphillips@lpami.wimsey.bc.ca) -- Matthias Urlichs \ XLink-POP N|rnberg | EMail: urlichs@smurf.noris.de Schleiermacherstra_e 12 \ Unix+Linux+Mac | Phone: ...please use email. 90491 N|rnberg (Germany) \ Consulting+Networking+Programming+etc'ing 42 Click here. ------------------------------ From: gonzo@malloco.ing.puc.cl (Gonzalo Diethelm) Subject: Re: Linux/Windows Date: Wed, 9 Mar 1994 05:24:52 GMT a920101@zipi.fi.upm.es wrote: > I heard something about a MS-Windows emulator under Linux. Can anybody > tell me about it? (E-mail, please). > THANKS! > Juanje. I want to know about such a beast too, please! Gonzalo ------------------------------ From: aoppelt@scr.siemens.com (Achim Oppelt) Subject: Re: Small pre-1.0 problem Date: Tue, 8 Mar 1994 17:05:05 GMT kevinl@bruce.cs.monash.edu.au (Kevin Lentin) writes: >I have just compiled pre-1.0 and have a strange problem. I've never seen it >before. >My /proc/version contains: >Linux version pre-1.0 (root@krayzee) #87 Tue Mar 8 21:01:21 EST 1994 >[87 rebuilds, that's sick!] >My /etc/issue contains (generated from /proc/version in rc.local): >Linux version pre-1.0 (root@krayzee) #87 Tue Mar 8 21:01:21 EST 1994 >BUT muy virtual consoles say this above the login prompt: >Linux version pre-1.0 (rootrayzee) #87 Tue Mar 8 21:01:21 EST 1994 >Note the contents of the brackets. Where did those 2 characters disappear >to? >[486/dx50, 32 meg ram, 2xide, 1xSCSI, T130B controller, cluster patches] >-- >[==================================================================] >[ Kevin Lentin |___/~\__/~\___/~~~~\__/~\__/~\_| ] >[ kevinl@bruce.cs.monash.edu.au |___/~\/~\_____/~\______/~\/~\__| ] >[ Macintrash: 'Just say NO!' |___/~\__/~\___/~~~~\____/~~\___| ] >[==================================================================] I assume you are using getty_ps, which interprets certain @-character sequences and replaces them with things like hostname, number of users logged in etc. @k is probably not defined, so it is simply stripped. (I cannot check this out since I currently do not have acces to my Linux box, which is at home in Germany :-( ) So this has nothing to do with pre-1.0. Achim ------------------------------ From: robert@agharta.rt.schwaben.de (Robert Ebe) Subject: Re: AMD 486DX problem (with Linux?) Date: Tue, 8 Mar 1994 11:31:21 GMT In article , Gregory McKesey wrote: > Anyways, I was hoping that someone else with an AMD 486DX >could verify that this is an AMD problem (or whether it is just >limited to me :( ). If someone also had another OS/Compiler >combination to ensure that this is not just a AMD486DX/GCC/Linux >problem. Greg, thank you for the detailed information. I also had the Ghostscript initialization problem with an AMD 486DX2-66, datecode 9342FPW / Malaysia. It didn't matter which operating system I used. Same behaviour under ISC 3.0 and Linux 0.99.14i. The OS/2 version of ghostscript gets initialized, but the output is sometimes nonsense. It looks like rounding errors, as you pointed out in your test program. Swapping to an Intel CPU fixed all the problems. Hope AMD will change all the buggy CPUs. Robert -- =========== Bar Keeper, geben Sie mir bitte einen Synthohol! ========== Email: Phone: +49 7121 83335 Home: Robert Ebe, Immanuel-Kant-Str. 31, D-72800 Eningen u.A., Germany ------------------------------ From: Laurent JULLIARD LAB GND 1267 Date: Tue, 8 Mar 1994 12:01:43 GMT Subject: ** Bug in hp.c HPLAN driver ** Hi Donald, Yesterday I installed the slackware 1.1.2 distribution of Linux ( Patrick your setup is marvellous !!) on my 486/33T machine (this is an HP EISA machine). Everything went smoothly except that my HP27247A ethertwist machine was not recognized. So I went through hp.c (0.99.15c) and discovered a few things : ======== hp_probe ======== Here is the beginning of the function: int hp_probe(struct device *dev) { int *port, ports[] = {0x300, 0x320, 0x340, 0x280, 0x2C0, 0x200, 0x240, 0 short ioaddr = dev->base_addr; if (ioaddr > 0x1ff) /* Check a single specified loca return hpprobe1(dev, ioaddr); else if (ioaddr > 0) /* Don't probe at all. * return ENXIO; [lines deleted] } The second test on ioaddr is wrong ! It's exactly the opposite (ioaddr < 0) that must be done. ========= hp_probe1 ========= PROBLEM #1 ========== Before I start using the machine mention aboved (EISA machine) I had no problem with the autoirq code but it looks like on EISA architecture the way you twinkle the interrupts doesn't work : /* Twinkle the interrupt, and check if it's seen....*/ outb_p(irqmap[irq] | HP_RUN, ioaddr + HP_CONFIGURE); outb_p( 0x00 | HP_RUN, ioaddr + HP_CONFIGURE); I don't know why but that is how it goes. So what I did is that I added a piece of code to get an IRQ with request_irq() like that: do { [lines deleted] } while (*++irqp); if (*irqp == 0) { int *irqp = irq_8list; do { int irq = *irqp; if (request_irq (irq, &ei_interrupt) == 0) { printk(" (non auto) selecting IRQ %d.\n" dev->irq = *irqp; break; } } while (*++irqp); if (*irqp == 0) { printk(" no free IRQ lines.\n"); return EBUSY; } } Of course this is not ideal but it works. The drivers grabs the first free IRQ (7 on my machine because I don't have LPT2) and that's it. The ideal solution would be to find a way to twinkle the IT that would work on any platform. Any idea ? If you want me to test a new method of yours, feel free to send your hp.c to me. PROBLEM #2 ========== The second problem is about the irq_16list you use when the driver detects an HP27247A board. int irq_16list[] = { 11, 10, 5, 3, 4, 7, 9, 0}; int irq_8list[] = { 7, 5, 3, 4, 9, 0}; I have the Hardware reference guide of this board at hand and IRQ 11 and IRQ 10 (map into option register value 2 and 12) are mentioned as "Not used". So is there a reason why you use this 16 bit list ? may be my doc' is not up to date. On top of that if I remember well, when I was using my old 386 ISA machine with the same HP27247A board, the auto detection of the interrupt lead the driver to select IRQ 5 meaning that IRQ 11 and 10 never worked. It was my $0.01 contribution to Linux. Have a nice day. Cheers. Laurent ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~ Laurent JULLIARD (Box 26) | HPDesk: Laurent Julliard /HP6300/UM ~ ~ GND/High Speed Networking Lab | Unix: Laurent_Julliard@grenoble.hp.com~ ~ HEWLETT-PACKARD FRANCE | Phone: (33) 76 62 12 67 ~ ~ 5, avenue Raymond Chanas - EYBENS | Telnet: 779 12 67 ~ ~ 38053 GRENOBLE CEDEX 9 | Fax: (33) 76 62 12 86 ~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ------------------------------ From: ruhtra@turing.toronto.edu (Arthur Tateishi) Crossposted-To: comp.os.linux,comp.os.linux.admin,comp.os.linux.help,comp.os.linux.misc Subject: Re: GOD SPEAKS ON LINUX! Date: 9 Mar 94 02:45:38 GMT In article , Grant Taylor wrote: >I'll have you know I'm sitting right here in front of god, and god is >running Linux. As for that stuff about why people get ill and wars occur, God must be reading too much usenet. arthur -- THEOREM: VI is perfect. PROOF: VI in roman numerals is 6. The natural numbers < 6 which divide 6 are 1, 2, and 3. 1+2+3 = 6. So 6 is a perfect number. Therefore, VI is perfect. QED Arthur Tateishi ruhtra@turing.utoronto.ca ------------------------------ From: evansmp@mb48025.aston.ac.uk (Mark Evans) Subject: Re: UDP report card Date: Wed, 9 Mar 1994 17:41:32 GMT 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" ------------------------------ From: evansmp@mb48025.aston.ac.uk (Mark Evans) Subject: Re: select Date: Wed, 9 Mar 1994 17:44:45 GMT Frank McCabe (fgm@doc.ic.ac.uk) wrote: : I have come across an apparent problem with the select system call. : According to the specification, if select is given a non-zero timeout then : the system call is supposed to wait for the appropriate interval before : terminating. : Well it doesnt! If you give a non-zero timeout the nit comes back immediately. I suspect it actually only does this the SECOND time you call select. What Linux does is to write to the variable used. So if you need to use select inside any kind of loop you need a variable specifically for the timeout, which you set to the appropriate value before calling select. i.e. use in exactly the same way as the fd_set values. : I know that this is not my problem, because the same (i.e. identical) program : behaves as expected on a sun sparc under suno 4.1.13. Some people would say that the sun is broken :-) ------------------------------ From: robert@agharta.rt.schwaben.de (Robert Ebe) Subject: Re: AMD 486DX problem (with Linux?) Date: Tue, 8 Mar 1994 23:27:43 GMT In article , Gregory McKesey wrote: > > I have found an annoying problem with the AMD 486DX chip and >Linux that is leading me to believe that there may be a compatibility >problem with this chips math functions. >This is the output that I obtained on my system: > >% ./amdtest >1.312500 * 7.999900 =10.499990 >1.312500 * 7.999900 =10.499869 >Test Failed, this must be an AMD 486DX chip! >% Here the same rusults. And also the ghostscript initialization death. :-( Furtunately my dealer is willing to change my CPU to an Intel. AMD 486DX2-66 Datecode 9342FPW Malaysia Linux 0.99.14 GCC 2.4.5 Robert -- =========== Bar Keeper, geben Sie mir bitte einen Synthohol! ========== Email: Phone: +49 7121 83335 Home: Robert Ebe, Immanuel-Kant-Str. 31, D-72800 Eningen u.A., Germany ------------------------------ Crossposted-To: comp.os.linux,comp.os.linux.admin,comp.os.linux.help,comp.os.linux.misc From: gtaylor@god.ext.tufts.edu (Grant Taylor) Subject: Re: GOD SPEAKS ON LINUX! Date: Tue, 8 Mar 1994 23:12:37 GMT Reply-To: gtaylor@cs.tufts.edu I'll have you know I'm sitting right here in front of god, and god is running Linux. -grant -- Grant Taylor gtaylor@cs.tufts.edu Read the linux Printing-HOWTO -- get it from sunsite or mail server: To: listserv@god.ext.tufts.edu with message body: ------------------------------ From: z1g192@rick.cs.ubc.ca (Christopher Andrew Smith) Subject: gcc internal compiler error - SIGSE[2~EGV Date: 8 Mar 1994 17:38:42 -0800 I'm getting an error that I've never seen before when compiling a certain appliction. What happens is that after I've compiled all the object files for the application and start linking the application with the library I made, gcc reports an internal error which I've never encountered before. Here is what happens when I type `make': gcc -g -D`arch` -ansi -c app.c -o app.o gcc -g -D`arch` -ansi -c startup.c -o startup.o /lib/cpp -D`arch` -P context.s > _context.s cc -g -c -o context.o _context.s rm _context.s gcc -g -D`arch` -ansi -c queue.c -o queue.o gcc -g -D`arch` -ansi -c procMgmt.c -o procMgmt.o gcc -g -D`arch` -ansi -c ipc.c -o ipc.o gcc -g -D`arch` -ansi -c time.c -o time.o gcc -g -D`arch` -ansi -c scheduling.c -o scheduling.o gcc -g -D`arch` -ansi -c synch.c -o synch.o gcc -g -D`arch` -ansi -c mem.c -o mem.o ar -r pthreads.a startup.o context.o queue.o procMgmt.o ipc.o time.o \ scheduling.o synch.o mem.o Creating archive file `/home/hell/src/pthreads/pthreads.a' gcc -g -D`arch` -ansi app.o pthreads.a -o app gcc: Internal compiler error: program ld got fatal signal 11 make: *** [app] Error 1 What could cause ld to receive signal 11 (ie SIGSEGV )? Is the compiler trying to access a symbol name outside of the library's text segment? If this was due to an error in my code, I would expect the error to show up during compilation of the module, or during run-time of the app. I am using these versions of compiler, linker, etc.: gcc 2.5.8 libc 4.5.21 ld 1.9l.3 Has anyone else ever had this problem? I'd like to know if it is a common problem. A listing of my makefile follows. Thanks in advance, Chris Smith aka z1g192@ugrad.cs.ubc.ca =========================================================================== Makefile: ^^^^^^^^^ CC = gcc # use gcc otherwise ARCH = `arch` CFLAGS = -g -D`arch` -ansi -D_LINUX #defines for linux #CFLAGS = -g -D`arch` -Aa -D_HPUX_SOURCE #defines for hpux #CFLAGS = -g -D`arch` # defines otherwise app: app.o pthreads.a $(CC) $(CFLAGS) app.o pthreads.a -o app pthreads.a: startup.o context.o queue.o procMgmt.o ipc.o time.o scheduling.o \ synch.o mem.o ar -r pthreads.a startup.o context.o queue.o procMgmt.o ipc.o time.o \ scheduling.o synch.o mem.o kernel.h: standards.h os.h kernelTypes.h ipc.h time.h procMgmt.h mem.h\ synch.h scheduling.h queue.h kernelConfig.h # touch kernel.h app.o: app.c os.h standards.h synchronization.o: synch.c kernel.h $(CC) $(CFLAGS) -c synch.c -o synch.o scheduling.o: scheduling.c kernel.h $(CC) $(CFLAGS) -c scheduling.c -o scheduling.o procMgmt.o: procMgmt.c kernel.h $(CC) $(CFLAGS) -c procMgmt.c -o procMgmt.o queue.o: queue.c kernel.h $(CC) $(CFLAGS) -c queue.c -o queue.o ipc.o: ipc.c kernel.h $(CC) $(CFLAGS) -c ipc.c -o ipc.o time.o: time.c kernel.h $(CC) $(CFLAGS) -c time.c -o time.o mem.o: mem.c kernel.h $(CC) $(CFLAGS) -c mem.c -o mem.o startup.o: startup.c kernel.h $(CC) $(CFLAGS) -c startup.c -o startup.o context.o: context.s /lib/cpp -D$(ARCH) -P context.s > _context.s cc -g -c -o context.o _context.s rm _context.s -- ======================================================================== |Christopher Smith | With a rubber duck, one's never alone. | |aka z1g192@ugrad.cs.ubc.ca |-- "The Hitchhiker's Guide to the Galaxy"| ======================================================================== ------------------------------ From: rm@eacpc4.tuwien.ac.at (Ralf Messerer) Subject: Re: AMD 486DX problem (with Linux?) Date: 10 Mar 1994 07:39:30 GMT If you change all printf("%f...) to printf ("%3.8f...") you will see: 1.31250000 * 7.99989986 =10.49986839 1.31250000 * 7.99990000 =10.49986875 Test Failed, this must be an AMD 486DX chip! There is no CPU bug. The only thing is that the number 7.9999 can not be stored in the float format without loosing precision. -- -Ralf [rm@eacpc4.tuwien.ac.at] ------------------------------ ** 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 ******************************