From: Digestifier To: Linux-Development@senator-bedfellow.mit.edu Reply-To: Linux-Development@senator-bedfellow.mit.edu Date: Sun, 31 Oct 93 02:13:08 EST Subject: Linux-Development Digest #200 Linux-Development Digest #200, Volume #1 Sun, 31 Oct 93 02:13:08 EST Contents: Re: ugly name for core dumps (core.imagename) -> patch for "img.core" (Matthias Urlichs) Re: *PATCH* AMI BIOS Super VGA 132x43 132x25 video support (Matthias Urlichs) GCC crashing Linux: kernel bug (Drinks All The Water) Does Linux support fixed priority tasks/processes ? (George Wu) Re: GCC crashing Linux: kernel bug (Robert Moser) Re: Yet another core dumps name suggestion (Chris Mattingly) Re: GCC crashing Linux: kernel bug (Louis-D. Dubeau) Re: GCC crashing Linux: kernel bug (Ronald Watkins) Re: GCC crashing Linux: kernel bug (Ronald Watkins) MCA Support > Please (Maurice De Vidts NE3S) Re: ugly name for core dumps (core.imagename) -> patch for "img.core" (Risto Kankkunen) Re: *PATCH* AMI BIOS Super VGA 132x43 132x25 video support (Daniel L. Marks) ---------------------------------------------------------------------------- From: urlichs@smurf.sub.org (Matthias Urlichs) Subject: Re: ugly name for core dumps (core.imagename) -> patch for "img.core" Date: 30 Oct 1993 11:17:46 +0100 [ Please don't use "Distribution: inet". ] In comp.os.linux.development, article , jem@snakemail.hut.fi (Johan Myreen) writes: > In article <2aiqvd$1n1@smurf.sub.org> urlichs@smurf.sub.org (Matthias Urlichs) writes: > > >True. I haven't seen any objection to naming the corefile of "foo" > >"foo.core". > > Quite a lot of people are still using the Minix file system, with a > maximum file name length of 14. So you drop back to just "core" if the name is too long. Ten-character program names are too bothersome to type anyway. ;-) -- Metaphysics is the science of proving what we don't understand. -- Josh Billings (Henry Wheeler Shaw) -- Matthias Urlichs \ XLink-POP Nürnberg | EMail: urlichs@smurf.sub.org Schleiermacherstraße 12 \ Unix+Linux+Mac | Phone: ...please use email. 90491 Nürnberg (Germany) \ Consulting+Networking+Programming+etc'ing 42 ------------------------------ From: urlichs@smurf.sub.org (Matthias Urlichs) Subject: Re: *PATCH* AMI BIOS Super VGA 132x43 132x25 video support Date: 30 Oct 1993 11:30:08 +0100 In comp.os.linux.development, article <2ank73$foh@vixen.cso.uiuc.edu>, dlm40629@uxa.cso.uiuc.edu (Daniel L. Marks) writes: > This is a patch that is for video cards with an AMI BIOS to do > 132x43 and 132x25 resolutions. [...] > *** setup.S Wed Oct 27 23:46:59 1993 > --- setup.S.old Wed Oct 27 23:55:56 1993 Please use "diff" correctly, i.e. % cd /usr/src/linux % diff -c boot/setup.S.old boot/setup.S though personally I find diff -u more readable. > mof1280: .byte 0x04, 0x54, 0x55 > + moamibios: .byte 0x04, 0x54, 0x55 > dscf1280: .word 0x5032, 0x501c, 0x842b, 0x8419 > + dscamibios: .word 0x5032, 0x501c, 0x842b, 0x8419 Why are you creating extra tables for "amibios" instead of using the existing stuff for "f1280"? -- It is proof of a base and low mind for one to wish to think with the masses or majority, merely because the majority is the majority. Truth does not change because it is, or is not, believed by a majority of the people. -- Giordano Bruno (1548?-1600) -- Matthias Urlichs \ XLink-POP Nürnberg | EMail: urlichs@smurf.sub.org Schleiermacherstraße 12 \ Unix+Linux+Mac | Phone: ...please use email. 90491 Nürnberg (Germany) \ Consulting+Networking+Programming+etc'ing 42 ------------------------------ From: boutell@netcom.com (Drinks All The Water) Subject: GCC crashing Linux: kernel bug Date: Sat, 30 Oct 1993 22:40:40 GMT WHY IS THIS IN THE DEVELOPMENT GROUP? After much discussion in the .help and .misc groups, and after hearing from other users with this problem, I am convinced to the best of my ability to determine that this is a Real Linux Kernel Bug. As such only the developers of Linux, who properly understand the kernel, have a snowball's chance in hell of resolving it, and resolving it is important if we are to create a stable 1.0 release. ABOUT THE PROBLEM For those just tuning in: gcc, and no other program I have found, sometimes crashes my linux system. Other executing programs then fail as soon as they try to do anything involving access to pages not in memory, as far as I can tell. THE FAQS, MA'AM Yes I have swap space. Yes it is turned on. yes I have run top. Yes I see swap being used, in large quantities even. No it doesn't crash every time. No I'm not talking about thrashing- there is NO disk activity once the crash sets in. My machine does thrash with other memory- hungry programs, but they *don't* crash the system. When I had 4 megs this was a daily occurrence. When I went to 8 megs it *almost* went away, but it still occurs, infrequently. More memory = less often, not never. File system damage is a frequent result (files here and there get mislinked and munged, and fsck finds this after I reboot). Another user contacted me and informed me that he has experienced the problem too. I am running .99pl10, which includes gcc 2.4.5. I don't have any humungous static arrays being initialized. I used to think that using -pipe stopped the problem, but I just caught it happening with -pipe a minute or two ago. ISN'T THIS A PROBLEM FOR THE GCC DEVELOPERS? Nope. A bad user program in a proper virtual memory operating system like Linux should never crash the system, no matter how stupidly it behaves. Also, I use the same release of gcc regularly on other OSes and never experience this problem. SHOULDN'T YOU SHUT UP AND BUY MORE RAM? I already have bought more RAM, and it does indeed help (enough that my Linux system is now stable enough to develop software on). But that's not the point. Consider that other users may be put off by the bug and not be willing to take the leap of faith of throwing extra silicon wafers ($$) in their grey boxes. Consider also that a bug like this simply doesn't have a right to live. SO WHAT DO YOU WANT US TO DO ABOUT IT? The user who contacted me tells me that Linus acknowledges it but considers it very hard to nail down and debug. I beg, humbly, but ON MY LOUD ROCKING KNEES PRETTY PLEASE, for somebody who understands the kernel to knock their machine back to 4 megs and do a series of gcc compiles of various files until they catch it happening. With 4 megs it shouldn't take long at all. Seems more common if you're running X (but still happens without it- there doesn't seem to be any absolute requirement that there be a certain amount of resources called upon). In the same vein, I would like users with 4 megs, or who are willing to physically reduce their RAM to 4 megs for the experiment, to try the test even if they aren't kernel gurus, to answer the question as to whether it occurs only on a few machines or on all machines at least when knocked back to 4 megs. BOY ARE YOU GOING TO LOOK SILLY WHEN WE DEMONSTRATE THIS IS JUST DUE TO SOMETHING YOU DID WRONG IN YOUR CONFIGURATION. No, I'm going to be very happy if you can demonstrate that. I want to fix the problem, not score ego points. I have posted to comp.os.linux.development as a last resort after exhausting other avenues, and also because, if I'm right about the kernel bug, it is indeed a development issue. -T -- i'll be under the floorboards with my face in the sun ------------------------------ Crossposted-To: comp.os.linux.misc From: grw@oahu.cs.ucla.edu (George Wu) Subject: Does Linux support fixed priority tasks/processes ? Date: Sat, 30 Oct 93 17:08:10 GMT Does the Linux scheduler support fixed priority for "realtime" applications ? I read the INFO-SHEET and some of the FAQ's and did not find anything. Any comment is greatly appreciated. George ------------------------------ From: araw@elm.circa.ufl.edu (Robert Moser) Subject: Re: GCC crashing Linux: kernel bug Date: 31 Oct 1993 02:19:35 GMT In response to the guy with the GCC crashes, I am running the alpha-f release, and still having the problem (instead of a hard crash, gcc announces a "fatal sig-11"). You didn't mention what disk hardware you are using. I'm using an ultrastor 34F, and Linus has indicated that things are still being worked out in the scsi code. I would suggest to the developers at large that it IS a low-level disk problem since it only seems to happen when the system begins paging. Most of the time I get the sig-11 message, but occasionally I get a hard crash. Also this only happens with GCC. Any GCC folks out there think of any system call GCC may use that would be uncommon in other software? I have also had a few crashes when using xv-3.00 when loading in too many images. A further note: GCC typically will compile a full kernel if it is the first task after a fresh boot. Let the system work awhile, though, and give it up. Indeed, the longer it sits, the shorter the time it takes to get the "sig-11". Sounds like something is "unwinding" inside. Hope someone finds it. ARAW ------------------------------ From: ozzy@stimpy.catt.ncsu.edu (Chris Mattingly) Subject: Re: Yet another core dumps name suggestion Date: Sun, 31 Oct 1993 00:02:18 GMT uknf@rzstud1.rz.uni-karlsruhe.de (Olaf Titz) writes: >> huge and buggy (todays core file can easily much bigger than the >> executable file whose execution produced them). Perhaps each process Agreed! There are much better ways to debug code now days too. >Just a story about what can go wrong with core files. The situation: >take an HP/UX system with an ancient elm and buggy emacs, configure >elm to use emacs for text editing, when the second call of emacs by >elm dumps core (so far nobody knows why) have the core file fill up >your quota. Now elm tries to exit and re-write the mailbox file, but >since the quota is already exceeded by the emacs core, this write >fails and the mailbox is lost. >At least a system should ensure that core files don't fill the quota >of innocent users. Well, that's why there is supposed to be such a thing as 'limit coredumpsize 0' which doesn't work at all...it seems that almost every program ignores it anyways... :( Later -- Chris Mattingly | No nifty sig yet ... creativity is still on vacation. 414-C Wood Hall | PO Box 21553 | Home computer: A1200 - crazytrain.catt.ncsu.edu NCSU | 020/2Chip/2Fast/'881-14MHz Raleigh, NC 27607 | Email: Chris_Mattingly@ncsu.edu OR (919) 512-3230 | cmatting@nyx.cs.du.edu ------------------------------ From: hallu@info.polymtl.ca (Louis-D. Dubeau) Subject: Re: GCC crashing Linux: kernel bug Date: Sun, 31 Oct 1993 02:51:22 GMT Drinks All The Water (boutell@netcom.com) wrote: : I am running .99pl10, which includes gcc 2.4.5. Do you know if anybody had that problem with 0.99pl13??? : The user who contacted me tells me that Linus acknowledges it but considers : it very hard to nail down and debug. I beg, humbly, but ON MY : LOUD ROCKING KNEES PRETTY PLEASE, for somebody who understands the : kernel to knock their machine back to 4 megs and do a series : of gcc compiles of various files until they catch it happening. : With 4 megs it shouldn't take long at all. Seems more common if : you're running X (but still happens without it- there doesn't : seem to be any absolute requirement that there be a certain : amount of resources called upon). Sorry, I don't have time to do so. These days, I'm trying to build the Mach 3.0 mk under Linux and config keeps dumping core at me. Now, that problem could be related to yours. I've checked, rechecked, rerererererechecked the damn code. I've build the executable with odemake. I've also build it by hand with diverse combinasion of compiler and liker options. I've added some code to print the program activity on screen. I don't understant why it keeps crashing on a simple malloc call. I thought it might use too much RAM and added a swap file to be sure, but it still crash. I also checked to be sure the program didn't try do dereference NULL pointers. If the problem isn't in the code, then it must come up with a precise sequence of malloc and free calls. I'll still check the code. I don't like to say that a program doesn't work because of the compiler or the OS. (Well, sometimes it happens.) If I find the problem is with the kernel (which I strongly doubt), I will let you know. -- =========================================================================== | Hallu (Louis-Dominique Dubeau) | | Membre du Comite Micro de l'AEP | | Departement de Genie Informatique | | Ecole Polytechnique de Montreal (Montreal, Quebec) | ====================== This sentence is false !!! ======================== ------------------------------ From: rwatkins@crl.com (Ronald Watkins) Subject: Re: GCC crashing Linux: kernel bug Date: 30 Oct 1993 20:40:08 -0700 Drinks All The Water (boutell@netcom.com) wrote: I believe I can confirm this bug. I was recently trying to use Linux on a four-meg system, and it seemed to work well. However, I was totally unable to compile any sort of large application, even though I had defined 12MB of swap space. Gcc would inevitably crash when trying to compile the kernel, though how long it would take is questionable. The error I got was SIG 11, Segmentation Violation. About half the time, Linux would become unstable afterward and I had to shutdown immediately. I never, though, lost files because of it. I upgraded to 8MB and *most* of the problems went away. I've narrowed the problem to swapping; gcc will *only* crash when it sucks enough RAM to cause Linux to start swapping to disk. If I use swapoff before I run gcc, I can compile the kernel perfectly. I'm on a 386-40 with 8MB (now), using a 200MB Conner IDE. It's a localbus system, but the HD controller isn't yet VLB. I'm unsure of the brand name of the motherboard, but it does use the AMI BIOS. I'd be willing to do any experiments the Linux authors think would be useful to help isolate this; it rendered Linux totally unusable to me in 4M, and compromises system integrity on occasion even now. :( -- Ron Watkins ------------------------------ From: rwatkins@crl.com (Ronald Watkins) Subject: Re: GCC crashing Linux: kernel bug Date: 30 Oct 1993 20:44:33 -0700 Robert Moser (araw@elm.circa.ufl.edu) wrote: : In response to the guy with the GCC crashes, I am running : the alpha-f release, and still having the problem (instead of a hard : crash, gcc announces a "fatal sig-11"). You didn't mention : what disk hardware you are using. I'm using an ultrastor 34F, and : Linus has indicated that things are still being worked out in the : scsi code. I would suggest to the developers at large that it IS a : low-level disk problem since it only seems to happen when the system : begins paging. Most of the time I get the sig-11 message, but occasionally Dingding! Use swapoff (in 8MB) and the problem Goes Away. It's not SCSI, because I'm on your basic IDE and it dies when swapping. Swapoff in 4M doesn't work, unfortunately. :( Gcc needs more memory than that. : A further note: GCC typically will compile a full kernel if it is the first : task after a fresh boot. Let the system work awhile, though, and give : it up. Indeed, the longer it sits, the shorter the time it takes to get : the "sig-11". Sounds like something is "unwinding" inside. I found that it worked *longer* on a fresh boot, but I never once got a full kernel compile in one pass. I was able to nurse it through by rebooting about ten times, but that's not the best of solutions. : Hope someone finds it. Me too! I was cursing something fierce, and very discouraged. I even tried buying Coherent.... which, after Linux, was like playing with Tinkertoys. :) -- Ron Watkins, aka <> | "In times of crisis, it is of utmost All opinions are my own: | importance to keep one's head." imbibe with sodium chloride! :) | -- M. Anoinette ------------------------------ From: ceham@w3eax.umd.edu (Maurice De Vidts NE3S) Subject: MCA Support > Please Date: 31 Oct 1993 04:19:13 GMT Hi, I have been following the linux newsgroups for some time now, and despite postings to other groups, I have not been able to determine what work is being done about the IBM PS/2 kernel support. I would greatly appreciate if someone would POST an "official" update about the subject, since many of us linux-less PS/2 users are stranded. In addition, I would not mind working on it myself if someone would give me some pointers on what specifically needs to be fixed. -- Dont get me wrong, I think the Linux people have done a great job. I just want to have linux on my IBM -- :) Thanks Maurice De Vidts NE3S ceham@w3eax.umd.edu ------------------------------ From: kankkune@cs.Helsinki.FI (Risto Kankkunen) Subject: Re: ugly name for core dumps (core.imagename) -> patch for "img.core" Date: 30 Oct 1993 17:41:36 GMT >Quite a lot of people are still using the Minix file system, with a >maximum file name length of 14. Yep. Fortunately it's quite easy to upgrade to the Minix file system with a maximum file name length of 30 characters. No need to compile in new filesystems, same reliability etc. .core adds only 5 characters to the executable name. There can't be a lot of programs with names longer than 9 characters, so you might be able to live even with the 14 char limit. -- It's that time of the year again ------------------------------ From: dlm40629@uxa.cso.uiuc.edu (Daniel L. Marks) Subject: Re: *PATCH* AMI BIOS Super VGA 132x43 132x25 video support Date: 31 Oct 1993 06:52:49 GMT urlichs@smurf.sub.org (Matthias Urlichs) writes: >> *** setup.S Wed Oct 27 23:46:59 1993 >> --- setup.S.old Wed Oct 27 23:55:56 1993 >Please use "diff" correctly, i.e. >% cd /usr/src/linux >% diff -c boot/setup.S.old boot/setup.S >though personally I find diff -u more readable. I didn't think it was a big deal which form was used for a kernel patch so tiny, but in the future I will take tastes into account. >> mof1280: .byte 0x04, 0x54, 0x55 >> + moamibios: .byte 0x04, 0x54, 0x55 >> dscf1280: .word 0x5032, 0x501c, 0x842b, 0x8419 >> + dscamibios: .word 0x5032, 0x501c, 0x842b, 0x8419 >Why are you creating extra tables for "amibios" instead of using the existing >stuff for "f1280"? I added the redundant lines because I wanted to avoid headaches for the kernel maintainers, because if for some reason there was a change for the Orchid Farienheit 1280 drivers, they would also affect the modes for the AMI BIOS. It is misleading to use the Farienheit 1280 line because any changes to it would break the AMI BIOS support, creating another fix patch for the kernel maintainers. If you'll notice, there's a similar line, except with the 0x55 and 0x54 modes switched that would work equally as well. I don't think the setup code is memory resident after the kernel loads, so its really not that big of a deal anyways. >-- >Matthias Urlichs \ XLink-POP N|rnberg | EMail: urlichs@smurf.sub.org >Schleiermacherstra_e 12 \ Unix+Linux+Mac | Phone: ...please use email. >90491 N|rnberg (Germany) \ Consulting+Networking+Programming+etc'ing 42 Daniel Marks dlm40629@uxa.cso.uiuc.edu ------------------------------ ** 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 ******************************