Received: from PACIFIC-CARRIER-ANNEX.MIT.EDU by po7.MIT.EDU (5.61/4.7) id AA26544; Thu, 14 Dec 95 12:41:56 EST Received: from SENATOR-BEDFELLOW.MIT.EDU by MIT.EDU with SMTP id AA14614; Thu, 14 Dec 95 12:41:58 EST Received: (from root@localhost) by senator-bedfellow.MIT.EDU (8.6.12/2.3JIK) id MAA20294 for Linux-Development-System-Dist@senator-bedfellow.mit.edu; Thu, 14 Dec 1995 12:13:49 -0500 Message-Id: <199512141713.MAA20294@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 12:13:40 EST Subject: Linux-Development-System Digest #117 Linux-Development-System Digest #117, Volume #2 Thu, 14 Dec 95 12:13:40 EST Contents: Re: Converting dynamic to static ? (BOFH) Re: Linux and Java (Steve Dunham) Re: [1.3.47] Undefined reference to `hostbyte' (sp@questor.org) Re: Strange behaviour of kernel 1.3.45 (Matthias Urlichs) problem compiling 1.3.46 (DUPRE Christophe) Re: Standardized Printing for Linux (David E A Wilson) Re: Kernel protection against device drivers! (Alain Knaff) Re: Linux ISO 7816 emulator (was: New Voyager) (Rob Janssen) Re: SuperMount w/ SCSI CD-Rom (Andrew R. Tefft) Re: Linux ISO 7816 emulator (was: New Voyager) (Rob Janssen) Re: Linux on BeBox? (Arnt Gulbrandsen) Re: libc 5.2.16 incompatible with libc.5.0.9? (Matthew Cummings) ---------------------------------------------------------------------------- From: BOFH Crossposted-To: comp.os.linux.networking Subject: Re: Converting dynamic to static ? Date: Wed, 13 Dec 1995 09:08:12 +1300 If you're wanting to run a system off a single floppy I would advise MTRoute, PCRoute, or KA9Q. archie for a site near you :) BOFH On Thu, 7 Dec 1995, Peter Choynowski wrote: > I am looking into setting up a floppy based router, and would like to > use Linux and gated. The idea is to have just a minimum system with > 2 network cards and a floppy. A ramdisk would be used, so the floppy > is only needed for booting - no mechanical parts to fail :) After > getting some idea of the space needed I have reached a conclusion that > I will need a static version of gated and few other programs for all of > this to fit on a single floppy. ------------------------------ From: dunham@cl-next4.cl.msu.edu (Steve Dunham) Crossposted-To: comp.lang.java,comp.os.linux.misc Subject: Re: Linux and Java Date: 14 Dec 1995 06:02:07 GMT Generic Account 0717 (masc0717@rohan.sdsu.edu) wrote: : I have been trying to get the Linux JDK to work on my machine for 4 days : now and I'm about to give up on it. Has ANYONE else gotten it to work? : I've had several people take a look at it for me and they couldn't figure : it out either. Both appletviewer and javac run and then exit. No output, : no errors, nothing. An strace on it shows it loading a ton of classes and : then cheerfully exiting having accomplished nothing. Strace available : upon request. I am running the latest libc, gcc, libdl, binutils, : everything mentioned in the docs. Anyone else had this problem? The error messages are probably in ~/.hotjava/weblog If you're using a 16-bit display, make sure you have the new binary from the incoming directory. The older binaries didn't support 16-bit. I have the beta JDK working fine on my RedHat-2.0 machine (with the new libc, binutils, and ld.so-1.7.9). There is a HOWTO in the works, and the mailing list is currently being reorginized into multiple lists, so if you wait a little (maybe a week?) more help should be available. The linux Java does work well (except that Sun hasn't ported HotJava to the beta API), now that things are getting settled, maybe someone will put together a RedHat or Debian package for it... Steve dunham@gdl.msu.edu ------------------------------ From: sp@questor.org Subject: Re: [1.3.47] Undefined reference to `hostbyte' Date: 13 Dec 1995 23:20:32 -0800 In article <4anfsq$7hl@isis.fiu.edu>, wrote: >Hi Linuxers, > >I just downloaded a copy of Linux kernel 1.3.47 and compiled to no avail. >The problem is due to "undefined reference to `hostbyte'" in constants.o. >The following shows where the error is: > > : > : > >make[1]: Leaving directory `/home/local/linux/arch/i386/lib' >ld -m elf_i386 -Ttext 0x100000 -e stext 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/scsi/scsi.a drivers/pci/pci.a \ > /home/local/linux/arch/i386/lib/lib.a /home/local/linux/lib/lib.a /home/local/linux/arch/i386/lib/lib.a -o vmlinux >constants.o(.text+0x386): undefined reference to `hostbyte' >make: *** [vmlinux] Error 1 > >I am wondering if this happens to any of you. Yup... same thing here: make[1]: Leaving directory /usr/src/linux/arch/i386/lib' 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/scsi/scsi.a \ /usr/src/linux/arch/i386/lib/lib.a /usr/src/linux/lib/lib.a /usr/src/linux/arch/i386/lib/lib.a -o vmlinux constants.o(.text+0x496): undefined reference to `hostbyte' make: *** [vmlinux] Error 1 -- Steve Pershing ---------------------------------------------------------------------- FREE ACCESS TO E-MAIL & NEWS at +1 604 681 0670. INFO on Environment, Science, Medicine, AIDS, Native (Indigenous) Issues and more. We sell ZyXEL, Penril, Telebit and more world-wide to support this Free Public Community Service. :::> Info from: mail-server@questor.org <::: ---------------------------------------------------------------------- ------------------------------ From: smurf@work.smurf.noris.de (Matthias Urlichs) Subject: Re: Strange behaviour of kernel 1.3.45 Date: 7 Dec 1995 11:10:39 +0100 In comp.os.linux.development.system, article <4a0b1a$fr2@holodeck.iss.nus.sg>, tiakjung@iss.nus.sg (Chng Tiak-Jung) writes: > > outperformed Sun SPARC 20. However, in term of elapsed time, it is only > closed to Sun SPARC 20's performance. Looking at other statistics, it > shows that the process generated a lots of page faults (3000+ for a > single run that last a few minutes). > As a first guess, I'd say you don't have enough RAM. -- 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 PGP: 1B 89 E2 1C 43 EA 80 44 15 D2 29 CF C6 C7 E0 DE Click here. ------------------------------ From: duprec@JSP.UMontreal.CA (DUPRE Christophe) Subject: problem compiling 1.3.46 Date: 13 Dec 1995 07:25:26 GMT Hi, I just got linux-1.3.46, and gave it a try, and it failed miserably while compiling... First of all, the system: linux 1.3.37 in ELF gcc 2.7.0, libc 5.0.9 processor is i486/33, 16 megs RAM I have an EIDE VLb controller, with EIDE hard drive and EIDE CD-ROM. If I try to make zImage with support for the IDE CD-ROM, I et so much errors I can't scroll back to the first, all in ide-cd.c If I don't include support for the CD, the kernel is made with no warning, and seems to be running perfectly (although 20 minutes is not enough to tell for sure). Any idea ? -- Christophe Dupre Universite de Montreal Internet: duprec@jsp.umontreal.ca Qc, Canada Montreal, Qc, Canada "Nous ne sommes pas libres de ne pas etre libres, nous sommes obliges de l'etre" - Fernando Savater -- Geek Code 2.1 -- GCS d-- H+ s:++ g+ !p au-* a19 w+ v+ C++(+++) UIL++>+++ P+>++ L++ 3- E---- N++ K W- M- V-- Y+ t++ 5++ !j R+ G- tv b++ D+ e+ u** h->++ f+ r++ n---(----) y+ #include ------------------------------ From: david@wyvern.cc.uow.edu.au (David E A Wilson) Subject: Re: Standardized Printing for Linux Date: 13 Dec 1995 18:33:00 +1100 sl14@crux1.cit.cornell.edu (S. Lee) writes: >Albert Cahalan wrote: >>OK, here is the request: print a man page on an inkjet printer. >>You could print it as ASCII, but you lose the bold, underline, etc. >>(or whatever, I think troff has structure...) It looks poor. >I think it wouldn't be too hard to write a filter that takes the nroff >output and convert the bold/underline to your printer's code. It wouldn't >look as good as postscript, but less can do it, xman can do it, and the >result is better than nothing. I did this at work a few years ago. I basically interpret backspace and carriage return style overstriking and build up an array of pairs of characters. If a normal character and an underline appear in the same column I use the printer's built-in underline mode (if it has one). If the two characters in the same column are identical then I use bold. If they are different I over- strike them (using CR line overprinting rather than BS character overprinting as watching the printhead bounce backwards and forwards while printing man pages was the original inspiration). The next step is to put the printer description into the terminfo database and pass the printer filter the type of printer you have. If there is interest I will clean this up (removing the cruft that accumulated over the years as I handled strange connections etc) and release it for Linux use (probably after Christmas). -- David Wilson Dept CompSci Uni Wollongong Australia david@cs.uow.edu.au ------------------------------ From: knaff@imag.fr (Alain Knaff) Subject: Re: Kernel protection against device drivers! Date: 13 Dec 1995 08:05:23 GMT Reply-To: Alain.Knaff@imag.fr Joe Nardone (joe@access4.digex.net) wrote: : Aurel Balmosan (aurel@xylo.owl.de) wrote: : : Hello, : : Is there a project which developes a kernel protection against devices drivers. : : : [snip] : : : : Aurel Balmosan : Yeah, they're called the 1.2 kernels. : Seriously, how would you implement such a thing? I think VMS did this by using three protection rings: one for the user, one for the kernel, and one for the device driver. The INTEL processors have 4 protection rings, so this should be possible. : It would be : very difficult to impose those kinds of restrictions on device : drivers, since they must run at a kernel-level and have that : open access to the system and its hardware. That's kind of : the point. Decive drivers only need to access their own hardware and the memory containing the requests and buffers that they are serving. The subroutines that they use could be viewed as some kind of system calls from the device driver to the kernel. On Intel processors, it is possible to grant access to a limited set of I/O ports to a task, and the driver-to-kernel system calls could be implemented using call gates. Of course, all this would be lots of work, and probably not worth the effort. I am just pointing out that it could _theoretically_ be implemented. : If a driver misbehaves, it means it's probably still being developed, : which means it's probably in a 1.3 kernel, which means you are on : your own. : Joe Alain -- Linux - Where do you want to fly today ? Windows 95 - Makes a grown man cry Alain ------------------------------ Crossposted-To: alt.satellite.tv.crypt From: rob@pe1chl.ampr.org (Rob Janssen) Subject: Re: Linux ISO 7816 emulator (was: New Voyager) Reply-To: pe1chl@wab-tis.rabobank.nl Date: Wed, 13 Dec 1995 11:08:46 GMT In <4ak81e$1e1@cortex.dialin.rrze.uni-erlangen.de> mskuhn@unrza3.dialin.rrze.uni-erlangen.de (Markus Kuhn) writes: >rob@pe1chl.ampr.org (Rob Janssen) writes: >>I suggested one in the posting: use the timer in the UART to generate >>an interrupt after some time. It can be done by changing the baudrate >>and then sending characters, using the txempty interrupt for timing. >>The problem is that the characters get sent to the interface, so something >>needs to be done to prevent that. My solution would be to gate the data >>signal using one of the handshake lines (DTR, RTS). >What about sending the dummy wait character to a second COM port? Of course that can be done, but it requires yet another COM port :-( (I could do that on my system but many users will have no spare port...) >>>The best solution I can think of so far is to use an individually >>>programmed timer interrupt. A PC has three timers and AFAIK, one of >>>them is still unused (the NetBSD folks use it for kernel profiling, >>>I'd prefer to spend it for real-time timing functions). >>The problem is that only one of the three PC timers can generate >>an interrupt. This is the timer currently used for the 10ms ticks. >Sure? I had assumed that the NetBSD folks get a periodic interrupt for >their kernel profiling routine from the third timer. Well, I'll have >to check the hardware specs again ... Maybe NetBSD already uses the CMOS RTC interrupt as the tick timer? In that case there is a timer channel available. Of the 3 timers, one is traditionally used for the DRAM refresh (its output is tied to DMA0). On modern boards the refresh is done differently, but this timer cannot generate interrupts. I'm not sure if the timer could be used for something else in freerunning mode (the DMA channel can) Another timer generates the speaker beep frequency. The third timer is connected to IRQ0 and is used as the system timer. >If you are right, then just let's use the 10 ms tick timer. It is >normally programmed to produce HZ=100 ticks per second. The scheduler >keeps an ordered list of itimer events. When the scheduler is about to >give control over to a process (which could run up to 10 ms without >any interrupt), and there is an itimer of another process with a >higher static real-time priority expiring in less then 10 ms (say 1.5 >ms), then we quickly reprogram the timer to give us an interrupt in >1.5 seconds, so that the higher priority process has a chance to >preempt exactly when required. After this 1.5 ms interrupt, the >scheduler sets the timer back to the old 10 ms cycle unless another >itimer expires sooner. Reprogramming the timer in order to generate an >individual interrupt for one single itimer expiration time should not >affect overall performance very much, because we only do this for >real-time processes and if they use the Posix itimers. The problem with fiddling with the timer is that it is quite slow to access. Its ports are usually accessed at ISA BUS rate (although there probably no longer is a good reason for that), and according to spec it requires delays even at that speed. The Linux kernel provides these by inserting dummy operations between the accesses. The action of reading the current timer value and setting it to some other value requires quite some operations... the device is 8 bit and the registers are 16 bit, which requires 2-step accesses and special actions to prevent changing of the count between those accesses. When all this is done at a high rate, the performance hit will probably be noticable. >This change will of course have serious effects on the kernel >precision timekeeping code, because reprogramming the timer causes >small phase offsets in the clock code. The kernel clock code could be >modified however, in order to avoid this problem. Currently, the >kernel keeps a delta-t value and adds this value every 10 ms to the >current time variable. gettimeofday() in addition polls a hardware >counter in order to interpolate the time variable between two 10 ms >ticks. If we drop the delta-t addition and move completely to a >counter polling approach (using one of the other timers which can not >produce interrupts for implementing the kernel clock), the timer phase >wander problem disappears. The performance effects: at every system >call and interrupt, the kernel would have to read out this counter >value in order to give the following kernel code access to the precise >time. This should have no serious performance effects on Pentium >systems, which have a nice 64-bit bus clock counter in a special >processor register, but it might affect the performance of 386/486 >systems which have no such luxury hardware and have to access the >external counter chip. On the other side, the clock update code would >vanish from the 10 ms tick routine which is a small performance gain. >Which effect dominates on which architecture must be tested. Of course you will have to make sure the counter is polled at least before it rolls over. When using a freerunning timer, the maximum time allowed between polls is 55ms. (the wellknown timer rate under DOS, where the timer is programmed at its slowest possible rate, 18.2 ticks per second) So, it is required you have a RTC timer interrupt that occurs at a higher rate than that, maybe 128/second. Polling a timer at that rate is not going to perform better than what we have now. I don't think it is required to poll at each interrupt or system call, that would destroy the performance of the system. It can be done when gettimeofday() is called, as it is done now. >>There is another timer in the PC: it is located in the CMOS realtime >>clock, and it can generate periodic interrupts on IRQ8. As far as >>I know, they are not yet used in Linux. >>One idea would be to use this interrupt to provide the system ticks >>(the 10ms tickrate would probably have to be changed...), and use >>the existing timer for more flexible timing. It can then be reprogrammed >>at will. >Interesting idea!!! >>Unfortunately the CMOS clock does not provide resolution beyond the >>selected interrupt rate, which means we would lose the high resolution >>gettimeofday() return value :-( >On 386/486 systems: Perhaps yes, but can't be poll the third timer >here? On Pentiums, you can use the on-chip 64-bit CPU bus clock timer >register which gives you depending on the CPU speed e.g. 150 MHz clock >rate = 7 ns resolution. More precision than you'll ever want to have, >every machine instruction is guaranteed to have its own individual >time stamp. Yes this can be done (as described above) Of course, with the Pentium counter you first need to calibrate the thing, because the clock speed is unknown. Also note that the exact rate of all these clocks is independent... The CMOS RTC is driven by a 32768Hz resonator that could be somewhat accurate (although not many motherboard manufacturers seem to care). The system timer is driven from a 14.318 MHz crystal that usually is way off. It was the original timebase for the entire PC (14.318/3 = 4.77) and the base for the NTSC color subcarrier on the CGA card. I think current systems only use it for the timer. The Pentium counter is driven by the system clock, which probably is yet another crystal (maybe some of the synthesized clock motherboards use the 14.318 crystal as the reference for this clock, I don't know). So what you will find is that changing to another timing base is going to affect the clock accuracy (on systems not locked to some reference). Some people will report improved accuracy, others will report a decreased accuracy. This depends on the error of the 2 or 3 different crystals in their system... (e.g. when they now say "after running a few days my clock is way off, but when I reboot the system it is ok", the situation will improve when you switch to using the CMOS RTC as the time reference...) >>An alternative is to provide kernel support for changing the tick rate. >>A function could be provided to increase the tickrate (e.g. in a 2^n >>fashion) by reprogramming the timer and correction of the timekeeping >>values that depend on the tickrate. >This would be a global decision, i.e. the whole system whould change >for a long time to the less efficient higher tick rate. If you switch >tick rate too often, you'll have again the clock phase wander problem. Yes, the tick rate change is only attractive when it is done at initialization of a realtime process, not for every delay it requests. (this assumes a realtime process is usually some control daemon that is rather long-lived, as opposed to some program that you start and stop at will) >>For efficiency, there could be a "fast tick" that executes at the >>requested rate, and a "normal tick" that is divided down from this >>and provides a fixed 100Hz rate to be used by all the existing stuff. >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. >Common tick interrupts used today: > Linux 1.2 and SunOS: 100 Hz > Ultrix: 256 Hz > OSF/1. 1024 Hz >What do you think, how much effort would it be to make the CMOS chip >the tick generator and to change HZ from 100 to 128? Changing HZ is going to break some things, but they were in the need of fixing anyway. Lately a lot of kernel patches have modified delays to be expressed in "HZ" units, but there are still fixed values around. Probably these are being repaired by the Alpha and other processor people. However, a change from 100 to 128 would not be too catastrophic. The timeouts are often so long that probably nobody will even notice... A somewhat nastier problem lies in loadable modules: as HZ is a #define, a loadable module cannot know what the runtime value is. So a module has to be recompiled when HZ changes. The same holds for user processes that somehow depend on HZ. All in all, it will probably break fewer things than going to ELF :-) Rob -- +------------------------------------+--------------------------------------+ | Rob Janssen rob@knoware.nl | BBS: +31-302870036 (2300-0730 local) | | AMPRnet: rob@pe1chl.ampr.org | AX.25 BBS: PE1CHL@PI8WNO.#UTR.NLD.EU | +------------------------------------+--------------------------------------+ ------------------------------ From: teffta@erie.ge.com (Andrew R. Tefft) Subject: Re: SuperMount w/ SCSI CD-Rom Date: Mon, 11 Dec 1995 19:42:34 GMT In article <30C6F4F6.2705C595@drealm.org>, Peter Jones writes: >Bagh and humbug :-) > >I have the drive mounted via SuperMount. With the Mitsumi, I could >manually pop the drive open, change disks, wait a little and continue. >With the Sony, THE DRIVE REFUSES TO OPEN after the disk is first >accessed. > >Now, do I just go in and hack the SCSI driver not to lock the drive? Or >does someone have a better idea? Wait for the next supermount release. sct said he was going to implement a timeout feature that would take care of this problem. In the meantime if you want you could comment out the door locking function (that's what I did). -- Andy Tefft - new, expanded .sig - teffta@erie.ge.com ------------------------------ From: rob@pe1chl.ampr.org (Rob Janssen) Subject: Re: Linux ISO 7816 emulator (was: New Voyager) Reply-To: pe1chl@wab-tis.rabobank.nl Date: Wed, 13 Dec 1995 11:13:02 GMT In Arnt Gulbrandsen writes: >rob@pe1chl.ampr.org (Rob Janssen) >> The problem is that only one of the three PC timers can generate >> an interrupt. This is the timer currently used for the 10ms ticks. >It's possible to reprogram that on every interrupt; I've done it. It >was tricky and I didn't get a solid solution. PC hardware hits again. Yes, it can be done... did you get reliability problems? or just the accuracy problem? >All a little bit tricky, because by the time the interrupt routine >starts, the counter is at N-5 or N-11 or something. The number 11 >comes to mind, but that was 1992, on a 386sx16, P90s are probably >faster. Icky. The number of extra ticks depends on the interrupt latency at that moment. When another interrupt handler is active and has not re-enabled interrupts, there may be quite some extra delay. This means you will have to read the current count each time, and take it into account. Even then, you will probably destroy the accuracy because some counts slip by every time you touch the timer... Not a problem for timer events, but unfortunately the thing also drives the real time clock... Rob -- +------------------------------------+--------------------------------------+ | Rob Janssen rob@knoware.nl | BBS: +31-302870036 (2300-0730 local) | | AMPRnet: rob@pe1chl.ampr.org | AX.25 BBS: PE1CHL@PI8WNO.#UTR.NLD.EU | +------------------------------------+--------------------------------------+ ------------------------------ From: Arnt Gulbrandsen Subject: Re: Linux on BeBox? Date: 14 Dec 1995 13:48:30 +0100 mfrisch@saturn.tlug.org (Mike Frisch) > Unfortunately, I'd have to guess that at least 50% of Linux uses > are university students who can't even afford to pay attention. From what > I've heard of this machine, it can't be low cost. Maybe it can - remember, Be appears to consciously ride on the wave of cheap PC peripherals, from keyboards up. --Arnt ------------------------------ From: cummings@stingray.net (Matthew Cummings) Subject: Re: libc 5.2.16 incompatible with libc.5.0.9? Date: 6 Dec 1995 23:28:56 GMT In article <4a0cvb$k9j@charm.magnus.acs.ohio-state.edu>, sviznyuk@magnus.acs.ohio-state.edu (Sergei Viznyuk) writes: >As soon as I installed binary distribution >of libc5.2.16 as many things stopped working, >most grave case being "make". Under libc.5.0.9 Well, you need to read the release document for this libc version. It contains the patches necessary to get make running correctly again, and it also details many other changes that need to be made so everything works right. -- Internet: cummings@stingray.net ------------------------------ ** 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 ******************************