Received: from SOUTH-STATION-ANNEX.MIT.EDU by po7.MIT.EDU (5.61/4.7) id AA28148; Thu, 14 Dec 95 17:23:51 EST Received: from SENATOR-BEDFELLOW.MIT.EDU by MIT.EDU with SMTP id AA26590; Thu, 14 Dec 95 17:23:53 EST Received: (from root@localhost) by senator-bedfellow.MIT.EDU (8.6.12/2.3JIK) id RAA26688 for Linux-Development-System-Dist@senator-bedfellow.mit.edu; Thu, 14 Dec 1995 17:14:11 -0500 Message-Id: <199512142214.RAA26688@senator-bedfellow.MIT.EDU> From: Digestifier To: Linux-Development-System@senator-bedfellow.MIT.EDU Reply-To: Linux-Development-System@senator-bedfellow.MIT.EDU Date: Thu, 14 Dec 95 17:14:07 EST Subject: Linux-Development-System Digest #118 Linux-Development-System Digest #118, Volume #2 Thu, 14 Dec 95 17:14:07 EST Contents: Re: What shared libs are loaded? (Andrew Mileski) Re: Strip.. Why NOT use it? (Andrew Mileski) 3Com 3c595 patch (Tammy Preston Boyd) Re: Serial overrun on 16550A @ 38.4K DX4/100 1.2.13: driver problem ? (Aurel Balmosan) Re: [Q] Any source available for memory management? (Aurel Balmosan) Re: Thread Packages for Linux? (William S. Gribble) who is upgrading dble to 1.3.X? (Paul Richter) Re: `Unable to handle kernel paging request...' (Rolf M. Nilsen) Re: Linux has poor memory management? (Albert Cahalan) unresolved symbols in 1.3.46 (ingo.hoffmann@mch.sni.de) ELF Copy-On-Write (Studnitzky Boaz) Re: Direct access to memory-mapped device? (Stefan Virsik) ld cannot find rgb1.o error (Kurt Fitzner (Kurt Fitzner)) 1.3.45 kernel memory usage ("Stephen Davies") Sockets library? Re: Serial overrun on 16550A @ 38.4K DX4/100 1.2.13: driver problem ? ("Theodore Ts'o") Re: HELP! denary to Hex?... (Matthias Ernst) Linux V1.3.47 Error (James Pogras) ---------------------------------------------------------------------------- From: dmtech@magi.com (Andrew Mileski) Subject: Re: What shared libs are loaded? Date: 14 Dec 1995 17:05:46 GMT Ingo Molnar (mingo@news.siemens.co.at) wrote: > Dunno if it's related, but it segmentation faults if you "fuser /proc/*" That's likely because you can't seek on /proc. Chances are that /proc will be changed to contain named pipes (not files) "real soon now". -- Andrew E. Mileski -- ======================================================= Dark Matter Technologies Inc. - Ottawa Ontario, Canada! mailto:dmtech@magi.com http://www.magi.com/~dmtech/ ------------------------------ From: dmtech@magi.com (Andrew Mileski) Subject: Re: Strip.. Why NOT use it? Date: 14 Dec 1995 17:08:10 GMT Phillip G Ezolt (pe28+@andrew.cmu.edu) wrote: > I have a whole bunch of programs that I have compiled, and they are > considered "unstripped". When I use the strip command on them, they get > SIGNIFICANTLY smaller.. Why would I NOT want to use that command? 'strip' removes debugging info. The debugger isn't very useful on stripped objects. Personally I strip all proven objects. -- Andrew E. Mileski -- ======================================================= Dark Matter Technologies Inc. - Ottawa Ontario, Canada! mailto:dmtech@magi.com http://www.magi.com/~dmtech/ ------------------------------ From: Tammy Preston Boyd Crossposted-To: comp.os.linux.networking,comp.os.linux.setup,comp.os.linux.misc Subject: 3Com 3c595 patch Date: Thu, 14 Dec 1995 09:31:28 -0700 Has anyone used the vortex.patch for 1.2.13 for the 3COM 3C595 ethernet card successfully? I'm using Caldera preview II & the patch didn't patch. Perhaps someone has already figured this out. -- =============================================================================== Tammy Preston Boyd | CS System Support Group | Email: boyd@cs.unm.edu The University of New Mexico | URL: http://www.cs.unm.edu/~boyd Computer Science Dept., Rm. FEC 307| Phone: 505/277-3016 Albuquerque, NM 87131 USA | FAX: 505/277-6927 =============================================================================== ------------------------------ Crossposted-To: comp.os.linux.hardware From: aurel@xylo.owl.de (Aurel Balmosan) Subject: Re: Serial overrun on 16550A @ 38.4K DX4/100 1.2.13: driver problem ? Date: Thu, 14 Dec 1995 16:40:35 GMT Alain FAUCONNET (af@biomath.jussieu.fr) wrote: : I've been bothered for a long time by "frame with bad fcs" and "frame : tossed, reason = 4" messages on my TI Travelmate 4000M when there is : high incoming traffic on the 38.4 kb/s PPP link (causing poor overall : transfer rates because of retries). After triple-checking PPP and : modem configuration, I have put a RS-232 testing box between the PC : and the modem, and saw that the RTS and CTS lines never seemed to : show any transition. The tty modes do include 'crtscts', and so does : the PPP config file. The modem is configured for hardware flow control : and the cable is OK. Hi, I think that this problem has nothing to do with the serial driver. Want about your harddisks or other interrupt driven hardware? If you are using multi-sector io with block interrupts linux can not catch every character from the serial line even with 16 bytes fifo. I am using 1.2.13 with 2 IDE harddisk both with 16 sector multi-io but I had to disable the irq blocking using the hdparm -u command. -- ================================================================ Aurel Balmosan aurel@xylo.owl.de ------------------------------ From: aurel@xylo.owl.de (Aurel Balmosan) Subject: Re: [Q] Any source available for memory management? Date: Thu, 14 Dec 1995 16:57:17 GMT Chung-Kie Tung (tung@garfield.ee.ncku.edu.tw) wrote: : I am trying to using share memory to solve large data transfer between 2 : process. Cause there is a limit of total segments of share memory, I plan : to allocate one large share memory segment and do my own memory management. You problem would be solved if there is no limit in shared memory segments. So my question to this group is why does this limit exists (4M limit) and can it be removed? To your question look into the gnu malloc source. I think there is a way to let the gnu malloc use shared memory for allocation. But you must also think about the possible different address space of 2 process. -- ================================================================ Aurel Balmosan aurel@xylo.owl.de ------------------------------ From: grib@cs.utexas.edu (William S. Gribble) Subject: Re: Thread Packages for Linux? Date: 14 Dec 1995 07:56:20 -0600 kphung@hkuxa.hku.hk (Starry Hung) writes: > A question to ask - "Is there any thread packages, e.g. Cthreads, available > on linux system that I could ftp?" I know of at least two implementations of the POSIX thread API: Chris Provenzano's pthreads (http://www.mit.edu:8001/people/proven/pthreads) and PCThreads (I'm not sure where to find it). I know that Pthreads comes with a multithreaded stdio that allows blocking thread i/o which doesn't block the process. I use pthreads in my research and have been using it for I guess almost 2 years now. Bill Gribble ------------------------------ From: militia@sierra.net (Paul Richter) Subject: who is upgrading dble to 1.3.X? Date: 14 Dec 1995 05:45:59 GMT Can anyone tell me who might be modularizing double to work with the new kernels? If no one is working on it, can any one tell me what needs to be done? ------------------------------ From: rolf@PROBLEM_WITH_INEWS_GATEWAY_FILE (Rolf M. Nilsen) Subject: Re: `Unable to handle kernel paging request...' Date: 5 Dec 1995 13:41:44 GMT Dr. Chris Nicol (nicolc@cs.uregina.ca) wrote: : Hi. I am running Linux kernel version 1.3.25 on a Pentium 100 with 32M : of memory and an ASUS P55TP4XE motherboard. This system has been : Nov 28 21:32:22 dora kernel: <1>Unable to handle kernel paging request at virtual address e066492c : Nov 28 21:32:22 dora kernel: <1>current->tss.cr3 = 01763000, ^Or3 = 01763000 : Nov 28 21:32:22 dora kernel: <1>*pde = 00000000 : Nov 28 21:32:22 dora kernel: <6>Oops: 0000 : Nov 28 21:32:22 dora kernel: <6>EIP: 0010:00122f78 : Nov 28 21:32:22 dora kernel: <6>EFLAGS: 00010202 : Nov 28 21:32:22 dora kernel: <6>eax: 00000003 ebx: 0000c37b ecx: 00000301 edx: 20664920 : Nov 28 21:32:22 dora kernel: <6>esi: 00000001 edi: 00000400 ebp: 00000400 esp: 016b9db8 : Nov 28 21:32:22 dora kernel: <6>ds: 0018 es: 0018 fs: 002b gs: 002b ss: 0018 : Nov 28 21:32:22 dora kernel: <6>Process latex (pid: 17556, process nr: 20, stackpage=016b9000) : Nov 28 21:32:22 dora kernel: <6>Stack: 012b0674 00000001 00000400 00125de4 00000301 0000c37b 00000400 00000004 : Nov 28 21:32:22 dora kernel: <6> 003a72d0 0000c37a 00000000 00000301 012b0670 00000301 00163c70 00000301 : Nov 28 21:32:22 dora kernel: <6> 012b0670 00000400 016b9e44 0000009c 014fe7e0 00000 : Nov 28 21:32:22 dora kernel: <6>Call Trace: 00125de4 00163c70 0016403c 001615a9 00124b0e 00160301 00163689 : Nov 28 21:32:22 dora kernel: <6> 0010ba56 0011a3b2 0011a4a2 0011a5b7 0012130c 0010a769 : Nov 28 21:32:22 dora kernel: <6>Code: 66 39 4a 0c 75 32 39 5a 08 75 2d 39 7a 04 75 08 89 d0 5b 5e Ok, what you are experiencing here is nothing more than you can expect with the 1.3 series of kernels. The kernel is not able to adress the memory properly. And kills the process associated with this memory page. The dump above describes the contents of registers, stack, data segments and the instruction executed when the error occured. The best advice for fixing this, is simple. Downgrade your system to a 1.2.13 kernel. Until the 1.4.1 kernel comes. As the 1.3.xx series are an development series of kernels. good luck with compiling a new kernel :) rolf ============================================================================ Joda jeg skal faa laget meg en fancy signatur naar jeg faar tid... :-| rolf@himolde.no ============================================================================ ------------------------------ From: albert@krakatoa.ccs.neu.edu (Albert Cahalan) Subject: Re: Linux has poor memory management? Date: 14 Dec 1995 19:20:44 GMT Daniel Yee (danny@cs.su.oz.au) wrote: > Does anyone have any comments on the following? I thought > this problem had been fixed in more recent kernels, but > haven't been : able to confirm it. Can someone who > understands the kernel memory : management system clarify? Someone else (tossed in the bit bucket by @%#*$%^&& emacs) wrote: > The Linux kernel is optimised to maximise its use of memory. > If the demand for memory does not exceed that available, > the performance of the system is quite impressive and certainly > cost effective. Once demand requires swapping of processes > to disk, the performance degrades precipitously. In the context > of a single user environment, this can either be accepted, > or the user can terminate or suspend some processes. In a > multiuser environment, this behaviour can be disastrous, > and positively feeds back. Someone else (tossed in the bit bucket by @%#*$%^&& emacs) wrote: > It says that RAM is a lot faster than the hard drive. > If you want better performance, add more RAM. No no no! This really is a problem specific to Linux. You missed the part about 'positively feeds back'. The complaint is not that swap space is slow (of course it is) but that a swapped process can never leave swap under the right conditions. No joke. To demonstrate: write a program that mallocs most of your RAM, say 6 MB on an 8MB machine. The program must (randomly?) touch all the pages over and over again. Just touch them, to keep the program fast. Now run this program in the background. Wait a bit, then run a second copy. When one process needs a page, the other one gets to run. The running process dirties its pages, so they will not get swapped (ok, paged) out. The process that needed a page gets one, but also loses a page. This causes the needy process to take another page fault, letting the pig run again and dirty more pages. The kswap patches added to 1.3.xx indirectly helped, but they did not solve the real problem. They did reduce the symptoms a bit though. -- Albert Cahalan albert@ccs.neu.edu ------------------------------ From: ingo.hoffmann@mch.sni.de Subject: unresolved symbols in 1.3.46 Date: Wed, 13 Dec 1995 10:31:33 +0000 Does anybody know about that one? depmod -a *** Unresolved symbols in module /lib/modules/1.3.46/misc/msbusmouse.o *** Unresolved symbols in module /lib/modules/1.3.46/misc/psaux.o *** Unresolved symbols in module /lib/modules/1.3.46/net/bsd_comp.o Ingo -- ***************************************************************** * Ingo M. Hoffmann Tel.: +49/89/636-41171 * * Fax: +49/89/636-48976 * * Siemens Nixdorf Informationssysteme * * MR PD 243 81730 Muenchen * * Germany * * email: ingo.hoffmann@mch.sni.de * ***************************************************************** ------------------------------ From: s3176015@techst02.technion.ac.il (Studnitzky Boaz ) Subject: ELF Copy-On-Write Date: Thu, 14 Dec 1995 19:16:37 GMT Someone posted a question about elf libraries. The question was- is it right that elf libraries are actually loaded more than once into memory (at least parts of them), because when the linker resolves library calls after the library has loaded, it actually writes that information the the library's dataspace. that causes a copy -on-write which duplicates the pages. Isn't it possible to have the dynamic loader mark the pages where it stores dynamic link pointers as non-copy-on-write? There's is infact, no reason why the linker should even resolve the symbol table again after a library has already loaded. There is no chance that it suddenlt decided to use other libraries, so why resolve all the symbol table again? Am I making sense? Boaz. ------------------------------ From: Stefan Virsik Subject: Re: Direct access to memory-mapped device? Date: Tue, 12 Dec 1995 10:37:14 +0100 Following-up my own mail: I had a little success with opening /dev/mem (open) and mapping it into another part of the memory (mmap). To be exact: The mapping didn't succeed yet. I got the code fragments out of the source of svgalib. Still some answers or experience are welcome! ========================================================================= Stefan Virsik German National Research Center for GMD-SET Information Technology email: virsik@set.gmd.de Institute for System Design Technology http://borneo.gmd.de/EIA Schloss Birlinghoven, D-53754 St. Augustin ------------------------------ From: Kurt Fitzner (Kurt Fitzner) Subject: ld cannot find rgb1.o error Date: 11 Dec 1995 22:37:11 GMT I'm rather novice so please excuse any blatant non-understandings or whatnot. I have recently installed slackware 3.0 and am still using 1.2.13. I installed the a.out libraries as well. I have downloaded several program sources that give me an error during the make saying: ld cannot find rgb1.o I cannot find rgb1.o anywhere on my filesystem, I have no idea what it does, and it is nowhere in the makefile. I got this error both when trying to compile the joystick kernel patch, and when trying to compile the single-player version of empire (found on sunsite.unc.edu/pub/Linux/games/strategy/empire.tar.gz). If anyone has some advice I would appreciate it. I can be mailed at kfitzner@compusmart.ab.ca or kfitzner@gpu.srv.ualberta.ca Thanks. ------------------------------ From: "Stephen Davies" Subject: 1.3.45 kernel memory usage Date: Wed, 13 Dec 95 22:30:00 +0930 Last night I upgraded to 1.3.45 and when I booted it, I got the folowing messages: "Uncompressing Linux... large kernel, low 1MB tight... done." How significant is this? Can/should I do something about it? Cheers and thanks, Stephen. ======================================================================== Stephen Davies Consulting scldad@sdc.com.au Adelaide, South Australia. Voice: 61-8-2728863 Computing & Network solutions. Fax : 61-8-2741015 ------------------------------ From: bkoen@bill.anet-stl.com () Subject: Sockets library? Date: 14 Dec 1995 18:14:07 GMT I am looking for libsocket.a. Does such a beast exist for Linux? Thanks, BRyan KOen bkoen@anet-stl.com ------------------------------ From: "Theodore Ts'o" Subject: Re: Serial overrun on 16550A @ 38.4K DX4/100 1.2.13: driver problem ? Date: 14 Dec 1995 16:23:14 -0500 Reply-To: tytso@MIT.EDU Date: Thu, 14 Dec 1995 14:28:00 +0100 (GMT+0100) From: "Alain FAUCONNET" > I've been bothered for a long time by "frame with bad fcs" and "frame > tossed, reason = 4" messages on my TI Travelmate 4000M when there is > high incoming traffic on the 38.4 kb/s PPP link (causing poor overall > transfer rates because of retries). After triple-checking PPP and > modem configuration, I have put a RS-232 testing box between the PC > and the modem, and saw that the RTS and CTS lines never seemed to > show any transition. The tty modes do include 'crtscts', and so does > the PPP config file. The modem is configured for hardware flow control > and the cable is OK. > I have recompiled drivers/char/serial.c with SERIAL_DEBUG_FLOW and > SERIAL_DEBUG_THROTTLE on and saw no sign of those routines being > called during an incoming ftp transfer, although the messages > mentioned above did appear. Could it be the tty upper layers or the > PPP code not calling them on input buffer overflow ? Probably not. I > tried doing transfers with kermit instead of PPP. Same symptoms: > retried packets, bad CRCs and "cua0: input overrun" messages. *But* > when I abort the transfer by ^C, I *do* see CTS going low (and the > kernel debug messages due to the settings mentioned above) because > the buffer fills up. This mechanism does work, then. > My conclusion is: the driver doesn't pick up characters fast enough > from the UART and the chip gives input overrun status. Strange. The > chip on this machine supposedly is the best one (16550A) and according > to the driver sources, the only one which has an useable internal > character FIFO. On an otherwise idle 486 DX4/100, I would expect the > driver to handle an incoming data flow at 38.4 kb/s. I'm baffled. Well, at home, I'm using a 386/40 running at 38.4, talking to a 28.8 modem doing PPP, and I'm not having any problems at all. So yes, a 486 DX4/100 certainly will have the computing oomph to keep up with things. If you're getting "cua0: input overrun" messages, the problem is not with the RTS/CTS flow control --- in the first place, PPP doesn't need any flow control mechanism because as soon as an incoming packet comes in, memory is allocated and shoved to the network layer, just as it would be an ethernet card. Any sort of flow control vis-a-vis TCP connections is done at the TCP layer. In the second place, if there was some sort of bottleneck at that level --- suppose that the kernel lowered CTS, but characters kept on coming in --- in the N_TTY line discpline layer, characters would just be silently dropped. The fact that you're getting the "cua0: input overrun" message does mean that for whatever reason, by the time the serial driver was able to get control after a serial interrupt and try to read characters from the UART, the UART was forced to drop some characters on the floor. This can be caused by trying to run too many serial ports at 115200 on a slow computer, but that's clearly not your problem. Other potential causes is that some other device driver (the IDE disk driver is a really bad this way) keeps interrupts off too long, and by the time the serial driver can get control, it's too late. If you can correlate the input overrun messages to disk activity, then you should take a look at man page for the "hdparm" program. In particular, take a look the "-u" option, which is documented for solving the input overrun message, but which causes SEVERE DISK CORRUPTION for some IDE interfaces. Read the man page, including the part of backing up your hard disk first, and decide for yourself if you're willing to risk it. Another possibility is that the laptop is just not delivering all interrupts from the UART for one reason or another. Perhaps some other device is conflicting --- you might want to check your setup screen and see if some other built-in device, like the Serial Infrared Port (SIR) device, is using the same interrupt as the UART. That's also definitely worth checking. > Jim Trocki reported similar problems on his > (desktop) machine which have been solved by replacing the > 16550A-based async controller by a 16550(not-A)-based one ! Could it > be a problem in the way drivers/char/serial.c handles that former > chip ? I doubt it; I'm using a 16550A at home, with no problems. So are lots of other people. I suspect what happened here was that the 16550A UART, or the controller board if he replaced the whole one, was defective. Has he tried replacing his serial board with another 16550A based serial board, or tried replacing the 16550 UART on that board with another (known to be good) 16550A UART? I'm pretty sure that would work for him. > I don't have the data book for that chip at hand, > but I imagine that there could be a setting to have the chip bring > CTS low by itself when its internal receive FIFO is about to overrun. > Am I completely lost here ? No, the UART doesn't have a feature like that. It's possible (with some fancy support circuitry) to do something like that, but it's not at all clear it's worth it. (I believe the USENET Serial Board II has this feature, for example.) In the first place, the serial driver is designed to be able to handle a 16550 UART running at 115200 on a 386/40, so in general it shouldn't be needed at all. If your computer is having problems keeping up, it's symptomatic of some other hardware problems. (Especially since you're seeing a 16550A UART, with a FIFO, with input overruns. That should never happen.) Also, there's generally some varying amount of delay (sometimes quite a bit) between when you turn off CTS, and when the remote side stops sending you characters. This has two effects --- first of all, it means that you may overrun your FIFO anyway. Secondly, it significantly slows down your transfer speed, since the delay before the remote end starts sending data again will really hurt your performance. Good luck! I hope this message gives you a starting point in looking for what's going wrong. I have a TI 5000 laptop as well, and I haven't had any problems at all. (Except that I can't get my SIR port to talk to other people's laptops, but that's another story.) - Ted ------------------------------ From: mernst@x4u2.desy.de (Matthias Ernst) Subject: Re: HELP! denary to Hex?... Date: 13 Dec 1995 08:04:23 GMT Max Lock (csd3cr@sirius) wrote: : Hi All, : OK I need to convert a denary number to Hex, I know how to do this (The : really long way) but does anyone know of a library with these conversions : in it?.. (oh yeah, I'm using plain 'ol C none of this C++ stuff) Suppose the result ends up in a string !? Look at stdio: int the_num; char hex_buf[SOME_BUFSIZE]; sprintf(hex_buf, "%x", the_num); -- Matthias : Cheers Max... : -- : Internet: M.T.Lock@herts.ac.uk /__/__/ University Of Hertfordshire /---/\ : Packet: G7UOZ@GB7MSW (AX.25) / /| / Amateur Radio Society /___/__\ : Ham Radio: G7UOZ 44.131.166.25 |_______________________________|___|__| : Microsoft Network is prohibited from redistributing this work in any form. ------------------------------ From: popo@radioman.hernix.org (James Pogras) Subject: Linux V1.3.47 Error Date: Thu, 14 Dec 1995 04:00:21 GMT In drivers/scsi/constants.c there is a statement: void print_hostbyte(int scsiresult) { printk("Hostbyte=0x%02x ",hostbyte(scsiresult)); } It errors because there is no routine hostbyte(). I've changed it to printk("Hostbyte=0x%02x ", scsiresult); This causese it to compile but I don't belive it's right. -- =============================================================================== James Pogras popo@radioman.hernix.org =============================================================================== ------------------------------ ** 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-System-Request@NEWS-DIGESTS.MIT.EDU You can send mail to the entire list (and comp.os.linux.development.system) via: Internet: Linux-Development-System@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-System Digest ******************************