Received: from SOUTH-STATION-ANNEX.MIT.EDU by po7.MIT.EDU (5.61/4.7) id AA29247; Wed, 20 Dec 95 14:40:18 EST Received: from SENATOR-BEDFELLOW.MIT.EDU by MIT.EDU with SMTP id AA13248; Wed, 20 Dec 95 14:40:17 EST Received: (from root@localhost) by senator-bedfellow.MIT.EDU (8.6.12/2.3JIK) id OAA26394 for Linux-Development-System-Dist@senator-bedfellow.mit.edu; Wed, 20 Dec 1995 14:13:48 -0500 Message-Id: <199512201913.OAA26394@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 14:13:45 EST Subject: Linux-Development-System Digest #139 Linux-Development-System Digest #139, Volume #2 Wed, 20 Dec 95 14:13:45 EST Contents: Re: Error compiling 1.3.48 (Marcus Sundberg) kernel panic: eata_dma (Alex Harin) Re: gcc 2.7.2 and 1.2.13 kernel (Paul Schmidt) Re: Linux Security - C2 and beyond (Rogier Wolff) Re: dosemu capable of running Windows 3.11 !? (William Drieling) Re: Linux has poor memory management? (Laco Rusnak) Re: dosemu capable of running Windows 3.11 !? (jack kahn) Re: Will Linux work with the P6 ??? (Rogier Wolff) Re: Nakamichi CD changer support ("Leonard N. Zubkoff") Re: `Unable to handle kernel paging request...' (Rogier Wolff) Re: cpp: output pipe has been closed error (Rogier Wolff) Re: Directory: just a file? (Jeremy Fitzhardinge) Re: Linux Security - C2 and beyond (Ingo Molnar) Help ! Adaptec AHA-2940 SCSI Controller (wolf) Re: AMD DX-40/Kernel Timing. (Peter Dalgaard BSA) ---------------------------------------------------------------------------- From: Marcus Sundberg Subject: Re: Error compiling 1.3.48 Date: Wed, 20 Dec 1995 15:12:20 +0100 Nikolai Schupbach wrote: > > I am also having problems compiling 1.3.48.... > > In file included from /usr/include/netinet/ip_tcp.h:1, > from /usr/include/netinet/ip_tcp.h:1, > from /usr/include/netinet/ip_tcp.h:1, > from /usr/include/netinet/ip_tcp.h:1, > > [SNIP] (Continues for 100's of lines!) > > from /usr/include/netinet/ip_tcp.h:1, > from /usr/include/netinet/ip_tcp.h:1, > from /usr/include/netinet/tcp.h:1, > from ppp.c:125: > /usr/include/netinet/ip_tcp.h:1: macro or `#include' recursion too deep > In file included from ppp.c:127: > slhc.h:128: field `cs_tcp' has incomplete type > make[2]: *** [ppp.o] Error 1 > make[1]: *** [sub_dirs] Error 2 > make: *** [linuxsubdirs] Error 2 Just change the file /usr/include/netinet/ip_tcp.h to: #include That should do it. //Marcus -- ===============================+===================================== Marcus Sundberg | WWW: http://www2.e.kth.se/~e94_msu/ Royal Institute of Technology | This line for rent... Stockholm/Sweden | E-Mail: e94_msu@e.kth.se ------------------------------ From: Alex Harin Subject: kernel panic: eata_dma Date: 20 Dec 1995 10:29:59 GMT Has anybody got an idea of what can be the cause of the following: kernel panic: data:eata_dma: run out of queue slots cmdno: 10243882 intrno: 10243790 In swapper task - not syncing This is with the kernel 1.2.13, slackware 2.3. The system is Pentium EISA-PCI Acer Altos 7000V, with onboard Adaptec 294x disabled. We use an EISA DPT PM2122A instead with four 1G hard drives, an HP DAT tape and a CD-ROM. The crash apparently occured in the night, while the tape backup has been running. Also now and then kernel reports something like this kernel: scsi : aborting command due to timeout : pid 8961869, scsi0, id 2, lun 0 Read (6) 06 2f 3a 10 00 kernel: eata_abort called pid: 8961869 target: 2 lun: 0 reason 3 kernel: Returning: SCSI_ABORT_BUSY kernel: scsi : aborting command due to timeout : pid 8961870, scsi0, id 2, lun 0 Read (6) 06 2f 4c 2e 00 kernel: eata_abort called pid: 8961870 target: 2 lun: 0 reason 3 kernel: Returning: SCSI_ABORT_BUSY I would appreciate if somebody could explain me what does that mean. Regars, Alex Harin (alex@ucsisa.co.za) Universal Computer Services, Johannesburg, South Africa ------------------------------ From: Paul Schmidt Subject: Re: gcc 2.7.2 and 1.2.13 kernel Date: Wed, 20 Dec 1995 11:00:28 -0500 (EST) Reply-To: Paul.Schmidt@ssa-mail.nwscc.sea06.navy.mil Mark Nordberg (Mark Nordberg (mark@quickening.catt.ncsu.edu)) wrote: > Has anyone else had problems with gcc 2.7.2 and kernel 1.2.13 elf. > > I seem to think that gcc-2.7.2 has a problem. I am using the > precompiled version released to the public. Has anyone else seen this > problem? We're running a dozen or so systems here with various ages and flavors of linux (Yggdrasil and Slackware), and are planning a coordinated upgrade to Slackware 3.0 -- I tried re-building 1.2.13 elf this morning and also failed. On the test system, I've installed Slackware 3.0 and upgraded gcc to 2.7.1 and 2.7.2, installed binutils 2.6.0.2, libc-5.2.18 and libg++-2.7.1.3. I edited the Makefile for elf 1.2.13 to add a -V2.7.1 (to use gcc 2.7.1 instead of 2.7.2), and got the same failures. I edited again to drop it back to 2.7.0 and it is now compiling -- I presume it will finish, since it's past the previous failure. This seems to clear the new libraries and include files (and makes a fairly easy short-term work-around). Anyone else have similar observations? Snail-Mail: Paul Schmidt (Code 7027, Bldg 2036) NAVSURFWARCENDIV CRANE 300 Highway 361 Crane, Indiana, 47522-5001 Phone (voice): (812)854-1106 Phone (fax): (812)854-3437 E-Mail: Paul.Schmidt@SSA-Mail.nwscc.sea06.navy.mil WPO E-Mail: PLS383 Home: PSchmidt@viaduct.custom.net ------------------------------ From: wolff@socrates.et.tudelft.nl (Rogier Wolff) Subject: Re: Linux Security - C2 and beyond Date: 20 Dec 1995 10:39:20 GMT Reply-To: r.e.wolff@et.tudelft.nl root (root@cheney.net) wrote: : Lock the machine in a closet and access it via the net if you want : real security in a multi-user environment. and learn security. : and upgrade the os. Very little, if any, OS's have been officially approved for security with networking installed..... Roger. -- *** War doesn't determine who's right ****** War determines who's left. *** ** EMail: R.E.Wolff@et.tudelft.nl * Tel +31-15-2783643 or +31-15-2137459 ** *** my own homepage *** ------------------------------ From: master@gvi.net (William Drieling) Crossposted-To: comp.os.linux.x,com.os.linux.development.apps Subject: Re: dosemu capable of running Windows 3.11 !? Date: 20 Dec 1995 04:36:20 GMT : BTW, I installed dosemu-60.4 three days ago, and : it seems it doesn't even able to run the games : which earlier versions did.. : Something like "failing to set video mode". : I somehow cannot imagine MSDOS failing : to set a video mode, even at the expense of your monitor :) I get the same thing when I try to start anything that isn't text. I get a blank screen, the game starts making noise like it is supposed to so it's like the game is going. I've only tried a couple games, and can succ essfully (blindly)exit the games and then everything works fine when back in text mode. It gives some error: int10,0:set_video_mode failed which I think just means that it is entering a non-text video mode, then it doesn't get any other errors, other than blank screen. I think I need to set up some stuff in the dosemu.conf file, I have video { vga console graphics } in my dosemu.conf file, it mentions something about "turn off video bios shadowing before enabling graphics", I haven't found where I can control it yet as I am just getting started with setting up dosemu things. Another thing I have noticed is that the mouse driver doesn't always kick in and work. I try "edit" or "xtgold" to start off with and it (mouse) doesn't work, but I tried running "msd" and that seemed to jolt the mouse driver into working order, after spitting out a few errors. fyi, I am using ps2 type of mouse. I'm not so sure this is the right news group for this so I'll hold off with the details. Right now I'm searching for more example entries for the dosemu.conf file. maybe theres some in the same dir as the dosemu souce, so I'll check there, otherwise, has anybody found any other info not in the FAQ or HOWTO? thanks and good luck -- ************************************************************* 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: laco@Viktoria.drp.fmph.uniba.sk (Laco Rusnak) Subject: Re: Linux has poor memory management? Date: Wed, 20 Dec 1995 11:08:23 GMT Larry Daffner (ldaffner@convex.com) wrote: : >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. : This, IMHO, is a patently bad idea... Suppose I have 2 processes : running, one which takes up a large chunk of VM but spends 99% of it's : computing time on 1 page, and the other a small program which touches : most of it's VM on a short cycle. Are you suggesting that these : programs should both have equal proportions of VM? That sounds You have discovered working set page replacement policy. I'm not expert, but principe is the following: System defines set of pages for each process which must be present in the memory needed for successful execution. Working set (WS) consist of pages which have been accessed in the last time interval. When there are many or big processes, WS of each process gets smaller. And finally process can be run only when all it's WS is loaded from swap to memory. Good idea, isn't it? LAco ------------------------------ From: jack kahn Crossposted-To: comp.os.linux.x,com.os.linux.development.apps Subject: Re: dosemu capable of running Windows 3.11 !? Date: 20 Dec 1995 11:44:28 GMT WFWG311 brings up the opening logo (what else?) and then quits because it won't run under Linux protective mode. How has this been dealt with by those who run successfully? Thanks. Jack Prefer Email answer but others may be interested too. ------------------------------ From: wolff@socrates.et.tudelft.nl (Rogier Wolff) Subject: Re: Will Linux work with the P6 ??? Date: 20 Dec 1995 11:41:13 GMT Reply-To: r.e.wolff@et.tudelft.nl Yan-Song Chen (phys6k@menudo.uh.edu) wrote: : Harald Milz (hm@seneca.han.de) wrote: : : Eric Kahler (ekahler@mars.superlink.net) wrote: : : > but I was curious about wether or not Linux will run : : > on a P6 processor. : : I had a short hands-on a device Escom sells over here in Germany, and I can : : say Linux boots happily with a P6. The SSBA benchmark suite, however, : : stopped at one point we couldn't track down. It appears that unter Linux a : : P6 is about 1.5 times as fast as a P5 at the same clock speed - no big step : : for mankind. Buy P133's and you're fine for the next year or so. : I bet the P6 will run better, at least twice as fast as P5 at the same : clock speed, if linux will be tuned very well for P6. Maybe we should : wait until the gcc supports P6 optimization, at that time the P6 will become : very cheap, I think. The P5 requires optimizations from the compiler. The P6 dynamically does the same optimizations in hardware. My guess is that the performance gain from a good compiler is less for P6 than for the P5. Roger. -- *** War doesn't determine who's right ****** War determines who's left. *** ** EMail: R.E.Wolff@et.tudelft.nl * Tel +31-15-2783643 or +31-15-2137459 ** *** my own homepage *** ------------------------------ From: "Leonard N. Zubkoff" Subject: Re: Nakamichi CD changer support Date: 20 Dec 1995 01:44:07 -0800 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 . Please let me know if there is any support for a CDROM changer. Seems like creating a custom driver may be worth the effort. Thanks Uri No special driver support is needed. You just need to either reconfigure your kernel and answer yes to the "Probe all LUNs on each SCSI device" question or boot with command line option "max_scsi_luns=8". Leonard ------------------------------ From: wolff@socrates.et.tudelft.nl (Rogier Wolff) Subject: Re: `Unable to handle kernel paging request...' Date: 20 Dec 1995 12:16:18 GMT Reply-To: r.e.wolff@et.tudelft.nl Rolf M. Nilsen (rolf@PROBLEM_WITH_INEWS_GATEWAY_FILE) wrote: : 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 : 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 Not always true. We've seen similar things happening on the same motherboard because of bad SIMMs. Read " http://einstein.et.tudelft.nl/~wolff/sig11/ " for more information on how to diagnose this..... Roger. -- *** War doesn't determine who's right ****** War determines who's left. *** ** EMail: R.E.Wolff@et.tudelft.nl * Tel +31-15-2783643 or +31-15-2137459 ** *** my own homepage *** ------------------------------ From: wolff@socrates.et.tudelft.nl (Rogier Wolff) Subject: Re: cpp: output pipe has been closed error Date: 20 Dec 1995 12:20:42 GMT Reply-To: r.e.wolff@et.tudelft.nl Naresh Sharma - aio fac L en R (sharma@IS.TWI.TUDelft.NL) wrote: : Hi Folks, : gcc: internal compiler error: program cc1 got fatal signal 11 : cpp: output pipe has been closed Read " http://einstein.et.tudelft.nl/~wolff/sig11/ ". Roger. -- *** War doesn't determine who's right ****** War determines who's left. *** ** EMail: R.E.Wolff@et.tudelft.nl * Tel +31-15-2783643 or +31-15-2137459 ** *** my own homepage *** ------------------------------ From: jeremy@suede.sw.oz.au (Jeremy Fitzhardinge) Crossposted-To: comp.os.linux.development.apps Subject: Re: Directory: just a file? Date: 20 Dec 1995 12:31:19 GMT In article , bnelson@netcom.com (Bob Nelson) writes: >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? Well, its a historical thing. When Unix only had 1 filesystem type, it allowed 14 characters for a filename, and used 2 bytes for an inode number, which meant a directory was a file of 16 byte directory entry records. The normal way to read a directory was to open it and read each entry into a buffer, and pick out the bits you wanted. That all changed because of two things: FFS and NFS. FFS has a much more complex directory layout which would just be a pain to deal with. Not impossible, but a pain (ext2fs's directory layout is similarly complex). NFS, on the other hand, made it pretty much impossible to implement directory reading using the same mechanism as file reading. Therefore BSD introduced some new system calls for reading directory entries, and some new library functions which made them easy enough to use. Well, several people did it in slightly different ways, so there was a time when a portable program needed to know how to use one of several directory reading techniques[1]. Fortunately Posix settled on a sane enough mechanism for doing it, (though I could use an opendirfd()), and you can use it with confidence that it exists most places. As for explcitly prohibiting read(): well that's not really necessary for an ext2 filesystem, but it makes it consistent with an NFS filesystem. Many systems still allow it on disk filesystems but not for NFS ones. For exmaple, a Solaris 2.4 box: : suede:6; cat . | od -x 0000000 0008 b2a2 000c 0001 2e00 0000 0001 1361 0000020 000c 0002 2e2e 0000 0008 c21c 0010 0007 0000040 7072 6563 6f6e 6600 0008 b2a3 0014 0008 [...] : suede:6; cat /n/suite cat: input error on /n/suite: Is a directory No version of Unix has ever allowed write()s directly to directory files. J [1] the past tense is optimistic - Perl and suchlikestill need to cope with all the different varieties, probably until SCO goes out of business... ------------------------------ From: mingo@news.siemens.co.at (Ingo Molnar) Subject: Re: Linux Security - C2 and beyond Date: 20 Dec 1995 13:21:08 GMT Joe Buck (jbuck@synopsys.com) wrote: : You're completely missing the point. Someone thousands of kilometers away Doh, this happens when posting late at night ... sorry : All I'm saying is that people who think that Linux is immune from viruses : and trojans may be fooling themselves. It's not immune to trojans (can a system be immune to trojans, once it allows to execute arbitary code?), but it's surely immune to the classic type of viruses: "run and infect other files, finally destroy the system". -- -- Copyright 1995. Ingo Molnar, mingo@hercules.elte.hu, Microsoft Network is prohibited from redistributing this work in any form, in whole or in part without license. License to distribute this work is available to Microsoft at $500. Transmission without permission constitutes an agreement to these terms. ------------------------------ From: wolf Subject: Help ! Adaptec AHA-2940 SCSI Controller Date: 20 Dec 1995 13:43:52 GMT Help!, I'm trying to install Linux on a Pentium 120MHZ and it does not appear to recognize the Adaptec AHA-2940/AHA-2940W controller, the system is using a Conner CFG1060s SCSI HD and a Matshita CD-ROM CR-504, The CD has a ID of 0 and the HD has an ID of 3. The Host Adapter is on ID #7. During Install procedure I use the scsi boot kernal then the color144 for the root image. This appears to go ok. Then when I try to use the Linux fdisk to /dev/sda or /dev/sdb I get a not found message. Any help here would be much appreciated ! Todd Mashore wolf@midstates.com ------------------------------ From: pd@kubism.ku.dk (Peter Dalgaard BSA) Subject: Re: AMD DX-40/Kernel Timing. Date: 20 Dec 1995 14:47:23 +0100 In article <4b7q4j$ck4@easy2.mediacity.com> marcio@easy1.mediacity.com (Marcio of Cyclades) writes: Hello: About this AMD DX4-120 problem: [...] One symptom that shows that your system is affected is the "BogoMips". A DX4-120 should have a BogoMips 60 or so. With internal cache in "write back" mode, this index is something like 2.5 or some other bogus value. So, my interpretation is that it is not an AMD or Cyrix or Intel problem, but a Kernel problem. [...] I've posted some messages reporting this problem, but nobody seems to be willing to look at it. Maybe if more problems (like the ones reported in this thread) are connected to the udelay() problem, someone will take the time to fix it. Well, looking at it is one thing, fixing it another. I don't really think additional motivation is needed to get kernel hackers to want it fixed. We can't have a buggy udelay(), so you have no reason to feel marginalized. The basic problem seems to be the low frequency of buggy systems making it difficult to test fixes. As I wrote you privately before, I did take a look and found several suggestions: a) Crude but efective fix: Bypass calibration and effectively SET BogoMips to 59.95 or somesuch. Gives you kernels that will only work on one kind of system, but few individual users should really care, only distribution maintainers. b) Probable cause: External events (to the kernel, that is) stalling CPU during calibration. Note that calibrate_delay() runs with interrupts enabled (it needs to count jiffies). Note that non-digital electronics may be involved in deciding exactly when these external events occur, which might explain a lot of the folklore about the phenomenon. c) Possible fix I: Identify cause and remove it... ( ;^) ) d) Possible fix II: Mask everything except timer interrupts. Only works if problem related to maskable interrupts, of course. (Might actually be possible to do very fast calibration by wedging into the timer interrupt and using stack-snooping to read the loop counter in the interrupt routine. Whatever happened to BozoMips, by the way?) e) Possible fix III: Sanity check the calibration. It already runs the loop several times with increasing repeat counts, shouldn't be too difficult to see if corresponding jiffy counts are consistent. -- O_ ---- Peter Dalgaard c/ /' --- Dept. of Biostatistics ( ) \( ) -- University of Copenhagen ~~~~~~~~~~ - (pd@kubism.ku.dk) ------------------------------ ** 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 ******************************