Received: from PACIFIC-CARRIER-ANNEX.MIT.EDU by po7.MIT.EDU (5.61/4.7) id AA17841; Wed, 20 Dec 95 19:21:33 EST Received: from SENATOR-BEDFELLOW.MIT.EDU by MIT.EDU with SMTP id AA08006; Wed, 20 Dec 95 19:21:31 EST Received: (from root@localhost) by senator-bedfellow.MIT.EDU (8.6.12/2.3JIK) id TAA01951 for Linux-Development-System-Dist@senator-bedfellow.mit.edu; Wed, 20 Dec 1995 19:13:53 -0500 Message-Id: <199512210013.TAA01951@senator-bedfellow.MIT.EDU> From: Digestifier To: Linux-Development-System@senator-bedfellow.MIT.EDU Reply-To: Linux-Development-System@senator-bedfellow.MIT.EDU Date: Wed, 20 Dec 95 19:13:50 EST Subject: Linux-Development-System Digest #140 Linux-Development-System Digest #140, Volume #2 Wed, 20 Dec 95 19:13:50 EST Contents: no audio in from Dell vibra 16 (Tom Dunigan) Re: Linux has poor memory management? (Robert Nation 885-9815) UMSDOS Problem with 1.3.45 (Michael Leodolter) Re: Directory: just a file? (Joerg Pommnitz) Re: Nakamichi CD changer support (Kevyn Ford soft) Re: LINUX on Cyrix 486-33/66 Clock Doubler (Bruce W. Bigby (963081)) Cyrix 486-33/66 Clock Doubler Cache/Linux (Bruce W. Bigby) Error compiling 1.3.48 (Greg Myers) [STATUS-UPDATE]: PD DCE On Linux Is Working. Questions Remain ("Michael T. Peterson") Re: Linux ISO 7816 emulator (was: New Voyager) (Markus Kuhn) Re: Error compiling 1.3.48 (William Drieling) Kernel upgrade [1.2.13 ==> 1.3.45] breaks PPP (Kevin Esler) Kernel upgrade [1.2.13 ==> 1.3.45] breaks PPP (Kevin Esler) Re: Are libc functions MT-safe? (Joe Buck) ---------------------------------------------------------------------------- From: dunigan@thdsun.epm.ornl.gov (Tom Dunigan) Subject: no audio in from Dell vibra 16 Date: 20 Dec 1995 14:06:16 GMT I am unable to get audio from the microphone from a Dell vibra 16 under Linux 1.2.13. Neither vat nor dd if=/dev/audio of=dsp.out bs=8000 count=3 work. Speakers (audio out) work fine, and microphone and speakers work under DOS/Windows. int vec, dma, and irq match that under dos. (audio on various laptops under linux works for us). suggestions? thanks -- Tom Dunigan ____ _____ ____ __ ___ MS 6367, Bldg. 6012 /___/ \ /____/ \ /___/\ /_ /| /_ /| Oak Ridge National Lab / __ \ /|| __ \ /| | \ \| | | | | | Oak Ridge, TN 37831 / / \ |/ | |__) |/\ | |\ \ | | | | | |__ Tel: (423) 576-2522 \ \__/ / | ___ \ || | \ \| | | | |/__ /| Fax: (423) 574-0680 \____/ |_|/ \_\/ |_|/ \___|/ |_____|/ e-mail: thd@ornl.gov http://www.epm.ornl.gov/~dunigan PGP key fingerprint: 77 ED A5 60 18 36 90 32 F6 EB 71 A8 6D FD 98 55 ------------------------------ From: rnation@porgy (Robert Nation 885-9815) Subject: Re: Linux has poor memory management? Date: 19 Dec 1995 14:19:19 GMT >: Sheduler: Choose a process in core to run. >: Swapper: Steal page not recently/often used. > >How would u suggest changing one or both to fix this problem? >Do FreeBSD/NetBSD/OpenBSD have the same problem? If not, how do they do it? >These three BSD systems are free, and we can thus look to see how they did You could try to balance the percentage of memory that each process gets. For example, if you have 20 MB of memory in use, but only 10 MB of physical memory, you could try to maintain each process with 50% of its pages in physical memory at once. Alternately, you could give a penalty to pages from big programs, when selecting a page to swap out. ------------------------------ From: Michael Leodolter Subject: UMSDOS Problem with 1.3.45 Date: Tue, 19 Dec 1995 16:02:40 +0100 We have the following problem: Renaming a file on a umsdos-partition temporary sets MSDOS-attributes for this file (until the next sync). For example: "ls -l tempfile" -r--r--r-- michael user tempfile "mv tempfile newfile" "ls -l newfile" -r-xr-xr-x root root newfile "sync or wait some time" "ls -l newfile" -r--r--r-- michael user newfile Could somone check this out, if this is a real problem, or specific to our system/installation ? Many thanks, michael -- ======================================================== - Michael Leodolter Brain Research Lab (BRL) - - Inst. of Psychologie Univ. of Vienna - - EMail: - - or - - Tel: <+43-222-40103-2436> Fax: <+43-222-406 64 22> - ======================================================== ------------------------------ From: pommnitz@heidelbg.ibm.com (Joerg Pommnitz) Crossposted-To: comp.os.linux.development.apps Subject: Re: Directory: just a file? Date: 20 Dec 1995 11:21:15 GMT Reply-To: pommnitz@heidelbg.ibm.com (Joerg Pommnitz) In , bnelson@netcom.com (Bob Nelson) writes: > >After several years of programming in C and about 3 years of working >with Linux, I'm surprised that only now I pose this query: > >K&R2 (p. 179) state "...a UNIX directory is just a file...". As most of >you know, the remainder of section 8.6 deals with an implementation of >opendir, readdir and closedir. (They do allow that there are some >system specific issues "left as an exercise"). > >What strikes me as interesting is using open() followed by read() to >access the contents of the directory "file". Trying the code shown on >p. 184 yields EISDIR on the read() call (just like in MS-DOS! :)). > >I've always used the POSIX functions to access the contents of a >directory in the past (and naturally, will continue to do so in the >future). So...the question...what are some of the UNIX variants where a >directory entry is simply a file -- since that appears to not be the >case in Linux? > >-- >============================================================================= > Bob Nelson: Dallas, Texas, U.S.A. - bnelson@netcom.com > Linux for fun, M$ for $$$...and the NFL for what really counts! >============================================================================= > This used to be true for Linux, too. It changed with the introduction of the VFS layer a long time ago (0.96 days ???). In Unix the directory semantics changed with the introduction of UFS, I think, but I'm not sure about this, because I'm not long enough with Unix to know about the old days. In common Unix file systems, a directory is still an ordinary file, but the layout of this file is different from file system to file system. In order to hide these differences, the kernel provides the directory access system calls. Best Regards Joerg ================================================================================ Joerg Pommnitz, IBM Scientific Center Heidelberg Mail1: pommnitz@heidelbg.ibm.com Mail2: jpo@vnet.ibm.com ------------------------------ From: kbf@success.raster.kodak.com (Kevyn Ford soft) Subject: Re: Nakamichi CD changer support Date: 20 Dec 1995 15:31:22 GMT In article <4b7cu2$fok@bocanews.bocaraton.ibm.com>, uri@vnet.ibm.com () writes: > > > -- > Does anyone know of any driver support for the Makamichi MBR-7 > 7 CDROM changer? These are SCSI-2 2X CDROM drives, The one I have got > is sold for less then $130. The changer appears as 7 CD drives with > the DOS driver but can be used only as a single drive with the existing SCSI > CDROM support with Linux 1.3.42 . I'm sure by now you've gotten correct responses, but just in case you haven't: Simply build the kernel to probe SCSI physical devices for logical devices. I've got one and it works like a champ! -- =============================================================================== Kevyn B. Ford Eastman Kodak Company Voice : (716)253-0149 Software Developer 901 Elmgrove Road Email : kevyn@kodak.com Rochester, NY 14653-5810 kbf@raster.kodak.com ------------------------------ From: bigby@ess.mc.xerox.com (Bruce W. Bigby (963081)) Subject: Re: LINUX on Cyrix 486-33/66 Clock Doubler Reply-To: bigby@ess.mc.xerox.com Date: Wed, 20 Dec 1995 19:11:45 GMT In article <1995Dec19.214351.14185@news.wrc.xerox.com>, bigby@ess.mc.xerox.com (Bruce W. Bigby) writes: > >I have a 386-DX/25 and recently purchased a Cyrix 486-33/66 clock doubler. The box says that I need to use the Cyrix 486-25/50 clock doubled chip and, also, goes on to state that the Cyrix 486-33/66 is compatible with the 386-DX/16, 20, 25, and 33. Is this true and has anyone had any problems running, what I think is, the most recent version of the Cyrix 486-33/66 with any version of Linux? I am running the Fall 94 version of Yggdrasil Linux. By the way, is there an Linux that is entirely based o That's "entirely based on ELF"... >and that has the pthreads library, PPP, X, XEmacs, GCC/G++, etc, on it? I want to build shared libraries, not standard executables. I also need a tape driver that will work with my Conner 850 MB drive. Is there a driver available? > >Bruce > ------------------------------ From: bigby@ess.mc.xerox.com (Bruce W. Bigby) Subject: Cyrix 486-33/66 Clock Doubler Cache/Linux Reply-To: bigby@ess.mc.xerox.com, BruceBigby@Aol.com Date: Wed, 20 Dec 1995 20:01:04 GMT The Cyrix 486-33/66 Clock doublder for the 386 comes with DOS, Windows, and Windows, NT software that turns on the Cyrix 486's internal 1K cache. Has anyone written software that would turn on the cache under Linux? Should I turn it on at all? Does Linux operate properly with it on? Bruce ------------------------------ From: Greg Myers Subject: Error compiling 1.3.48 Date: Mon, 18 Dec 1995 02:01:24 -0600 While compiling kernel 1.3.48 I ran into the follow error... ld -qmagic -Ttext 0xfffe0 arch/i386/kernel/head.o init/main.o init/version.o \ arch/i386/kernel/kernel.o arch/i386/mm/mm.o kernel/kernel.o mm/mm.o fs/fs.o ipc/ipc.o net/network.a \ fs/filesystems.a \ drivers/block/block.a drivers/char/char.a drivers/net/net.a drivers/cdrom/cdrom.a drivers/sound/sound.a drivers/pci/pci.a \ /usr/src/linux-1.3.34/arch/i386/lib/lib.a /usr/src/linux-1.3.34/lib/lib.a /usr/src/linux-1.3.34/arch/i386/lib/lib.a -o vmlinux init/main.o(.text+0x4f3): undefined reference to `rd_image_start' init/main.o(.text+0x502): undefined reference to `rd_doload' init/main.o(.text+0x512): undefined reference to `rd_prompt' arch/i386/kernel/kernel.o(.text+0x6029): undefined reference to `rd_image_start'arch/i386/kernel/kernel.o(.text+0x603e): undefined reference to `rd_prompt' arch/i386/kernel/kernel.o(.text+0x6053): undefined reference to `rd_doload' fs/fs.o(.text+0x6ec3): undefined reference to `rd_loading' ll_rw_blk.o(.text+0x1168): undefined reference to `rd_init' genhd.o(.text+0x891): undefined reference to `rd_load' make: *** [vmlinux] Error 1 ------------------------------ From: "Michael T. Peterson" Crossposted-To: comp.soft-sys.dce,comp.os.linux.development.apps Subject: [STATUS-UPDATE]: PD DCE On Linux Is Working. Questions Remain Date: 20 Dec 1995 21:26:34 GMT This is a multi-part message in MIME format. =================================244671736213810 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii -- # +--------------------------------------------------------------+ # | Michael T. Peterson | For the latest on the progress of the | # | mtp@zso.dec.com | port of DCE to Linux and POSIX .1c for | # | Bellevue, WA. | Linux, see http://www.aa.net/~mtp/ | # +--------------------------------------------------------------+ =================================244671736213810 Content-Transfer-Encoding: 7bit Content-Type: text/plain I would like report that I have been able to get the PD DCE RPC running on Linux v1.3.45 using the local loopback device. In this case, success means that the system is able to compile, build, and execute the perf test suite (1) distributed with the PD Source Kit. However, I had to do some rude hacking (2) to the mechanism by which the RPC runtime selects for active file descriptors. This posting is a request for an explanation of the RPC runtime internals that will help me better understand what is going on, and why my hack worked. In comnlsn.c, the listener thread calls select with a NULL timeout parameter. Of course, this blocks the thread until a file descriptor becomes ready (or the call is interrupted). Since my thread package supports thread-blocking I/O (I wrote select() as wrapper around the SYS_select() kernel entry point), I was surprised to find that the call to select() never, ever returned! In otherwords, the thread that was looping on SYS_select() never saw a descriptor become ready, although the server was certainly receiving the RPC requests as evidenced by the traces generated during the course of a run. The source comments explaining the rationale behind DCE's use of select(), however, indicate that the thread blocked in select() must be periodically cancelled. Here's a portion of the comment block followed by the call to select(): In comnlsn.c: /* * Block waiting for packets. We occasionally need to see * changes in the readfds and listener state even if we aren't * receiving pkts. At such times, we cancel this thread to * get it to see the updates. . . */ n_found = select( listener_nfds, (int *) &readfds_copy, NULL, NULL, NULL); . . . Evidently, my threads package was failing to deliver the cancels to the calling thread. More interestingly, the kernel was not detecting detecting any of the file descriptors becoming ready. For both reasons, the thread never returned and the runtime just looped waiting for something to happen (3). Well, I do not believe I fully understand the algorithm used by the runtime to "see" active file descriptors. To that end, I would appreciate some insight before I go charging off trying to fix something I don't fully understand. If the thread in select() *doesn't* see a descriptor become active (i.e., ready), what does? In otherwords, what agent changes the readfds and listener state referenced in the source comments above, and what condition(s) cause this agent to change the descriptors' state? Finally, if anyone can suggest additional tests and/or approaches I might use, please feel free to send them to me at mtp@big.aa.net (Home ISP -- preferred) mtp@zso.dec.com (Day job) Cheers, /mtp 1) I lied. Occasionally, perf fails to export the perfb binding and hangs (as evidenced by no packet activity my the system monitor, and a lack of progress). But as those of you who have used the perf test suite, you know that 95% of the perf suite has completed. I suspect this another symptom of an underlying problem with my thread package. 2) I changed the select() timeout parameter from NULL to {0,N} where 10 ms < N < 100 ms. Thus, the thread returns every N milliseconds. When I did this, everything works. 3) Not properly receiving cancels is most likely a bug in my threads package. =================================244671736213810== ------------------------------ From: mskuhn@unrza3.dialin.rrze.uni-erlangen.de (Markus Kuhn) Crossposted-To: alt.satellite.tv.crypt Subject: Re: Linux ISO 7816 emulator (was: New Voyager) Date: 14 Dec 1995 22:39:42 +0100 Reply-To: mskuhn@cip.informatik.uni-erlangen.de koenig@tat.physik.uni-tuebingen.de (Harald Koenig) writes: >In <4ak81e$1e1@cortex.dialin.rrze.uni-erlangen.de> mskuhn@unrza3.dialin.rrze.uni-erlangen.de (Markus Kuhn) writes: >> I find your CMOS clock tick generator idea much more attractive at the >> moment. The MC14818A data sheet says that among other interrupt >> frequencies, the CMOS clock can generate also 128 Hz (write 1001 into >> the RS bits), which is close to 100 Hz and will simplify even some of >> the adjtimex code, because now HZ is a power of two. >no bad idea if this really works for *ALL* CMOS clock versions and the >interrupt line isn't used for other hardware (which IRQ line is the >CMOS clock connected to ? couldn't find anything in my PC docs). According to c't 12/1988, page 200 (a very good article about the CMOS clock chip) and a few other references which I have checked, in every IBM AT compatible machine, the CMOS interrupt is connected to IRQ 8. The IBM AT BIOS uses this interrupt even in order to implement its alarm function. So there should not be any real compatibility problems, at least not as long as we do not try this on 8086 machines. Does anyone know, how commercial PC real-time operating systems like QNX use the various hardware timers? Do they generally have a higher tick rate for the periodic timer interrupt (less efficient), or do they also use the CMOS clock for periodic ticks and the normal timer chip for precision events like we have discussed it? For the ISO 7816 smartcard serial protocol software, may be the loopback dummy character transmission is the most practical solution if this really works, however for many other things, precision timers would still be very nice. Markus -- Markus Kuhn, Computer Science student -- University of Erlangen, Internet Mail: - Germany WWW Home: ------------------------------ From: master@gvi.net (William Drieling) Subject: Re: Error compiling 1.3.48 Date: 20 Dec 1995 05:02:44 GMT I got errors like that when I was trying to compile real simple programs. I think it was because I didn't have a library installed like libXaw.a or some other *.a file, but I did have the header file that specified the function that was supposed to be in the library, like this: extern void _lib_funct_(var,var,var) so it got all the way to the linker "ld ------" then bailed with the error "undefined reference _lib_funct_" or whatever function it was trying to find in one the "a" library files. I don't know if this is exactly the problem, I have found the missing library files but haven't got around to putting them in place and trying to recompile the simple xhello.c program. -- ************************************************************* of course windowz multi-t\$#%a$%^s*!@#$$@$#%)!*#@&)k{_-_+ ]M- I XIEUo_ D+|_d WVov oF &tZDF &G< tQj \& o0le|_ PhG oF PV\< le|_ P\G RPle|_ P\ le|_ P\__ b- kFnW\+ oFn_ Ijoj j j j j j j \5 ++^_MMo_ #$%@#\@#@#@A#\%$ky%%^&jE\*&(T*^*gI\&!*@(B\##&e[]r\{}{}}\$#%$% NO CARRIER ------------------------------ From: esler@ultranet.com (Kevin Esler) Subject: Kernel upgrade [1.2.13 ==> 1.3.45] breaks PPP Date: 20 Dec 1995 15:16:39 -0600 Reply-To: Kevin Esler I recently built and installed kernel 1.3.45, but found that PPP doesn't work. Is there something I'm supposed to adjust to make this work ? -- Kevin Esler Boston, MA, USA. ------------------------------ From: esler@ultranet.com (Kevin Esler) Subject: Kernel upgrade [1.2.13 ==> 1.3.45] breaks PPP Date: 20 Dec 1995 15:17:22 -0600 Reply-To: Kevin Esler I recently built and installed kernel 1.3.45, but found that PPP doesn't work. Is there something I'm supposed to adjust to make this work ? -- Kevin Esler Boston, MA, USA. ------------------------------ From: jbuck@synopsys.com (Joe Buck) Subject: Re: Are libc functions MT-safe? Date: 20 Dec 1995 20:43:39 GMT Peter Hofmann (peter@I_should_put_my_domain_in_etc_NNTP_INEWS_DOMAIN) wrote: : as of libc version 5.2.16 threads are supported in the linux libc. : You have to compile the shared pthreads library yourself because : it is not included in the binary distribution of libc-5.2.16. Please : read the file release.libc-5.2.16 for details. pgf@american.com (Paul G. Fox) writes: >i'll bet you don't really mean "threads are supported in the linux libc", >do you? is all of libc (malloc, printf, ctime etc) thread-safe? adding >thread creation calls (ala pthreads) does not make the rest safe. Yes, that is in fact what he means; there are the required hooks in the newer libc versions to support thread-safeness. The details are in the release notes that Mr. Hofmann with the bad address referred you to. -- -- Joe Buck (not speaking for Synopsys, Inc) ------------------------------ ** 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 ******************************