From: Digestifier To: Linux-Development@senator-bedfellow.mit.edu Reply-To: Linux-Development@senator-bedfellow.mit.edu Date: Wed, 28 Sep 94 07:13:11 EDT Subject: Linux-Development Digest #237 Linux-Development Digest #237, Volume #2 Wed, 28 Sep 94 07:13:11 EDT Contents: Mixer for PAS Cards? (Zureal) Re: Don't use Linux?! (David Holland) Re: pseudo ftp mirrors (Pete Kruckenberg) Sound Galaxy Soundcard Initialisation (Alan Knowles) problems compiling kernel 1.1.45+ for scsi (Srini Seetharam) >1GB SCSI disks & Buslogic Adapters (Andrew Walker) Mitsumi and Multisession CD's (Horst Zoelzer) Is clock() broken in gcc 2.5.8? (Scott McCaskill) Re: Compiler benchmarking. was Survey: who wants f77,cc,c++,hpf for linux? (richard) Re: Trouble using "execl" (Ronald.Geens) A umount bug? (Breakdown) Re: elf benchmarks (getting closer) (fuzzy) Special Sale On QNX! HELP: Mounting Hitachi CD-ROM drive under LINUX!!!! (michaelb@earlham.edu) ---------------------------------------------------------------------------- From: zureal@infinet.com (Zureal) Subject: Mixer for PAS Cards? Date: 27 Sep 1994 18:34:03 GMT Has anyone made/created a mixer for the PAS? I've got the PAS 16 and no way to set volume, bass, treble, etc... for my card. I've gone through the linux/drivers/sound directory with no luck. I'd like such a thing if possible. Pointers, ftp sites, etc.... -- *----===========================================================------* * zureal@infinet.com | 74431.3011@compuserve.com * * sysop@f560.n226.z1.fidonet.org | jeffoxen@freenet.columbus.oh.us * * BBS # (614) 235-5942 * * Fnord All hail Eris! Fnord * * finger zureal@infinet.com or FREQ PGPKEY from 1:226/560 for PGP key * *---=============================================================-----* ------------------------------ Subject: Re: Don't use Linux?! From: dholland@husc7.harvard.edu (David Holland) Date: 25 Sep 94 13:45:15 aschoorl@uglz.UVic.CA's message of Fri, 23 Sep 94 21:25:42 GMT said: > >Updating the kernel takes maybe half an hour to unpack and configure, > >and maybe another half hour (on a decently fast machine) unattended to > >compile. > > Yikes! Answering all the questions to make config and doing a make dep > takes maybe 10 min, and my machine takes 12 min to compile the kernel. > I only have a DX2 66. I wonder how the Pentium fairs. I was giving a worst-case estimate - and allowing plenty of time for "man patch" and slow network connections. And, btw, a DX2-66 isn't so "only". :-) -- - David A. Holland | -- "Do you have a moment?" -- "Yes. dholland@husc.harvard.edu | Unfortunately, it's a moment of inertia." ------------------------------ From: kruckenb@sal.cs.utah.edu (Pete Kruckenberg) Crossposted-To: utah.linux Subject: Re: pseudo ftp mirrors Date: 26 Sep 1994 05:00:12 GMT Brad Midgley (bmidgley@lal.cs.utah.edu) wrote: : In article <361uj3$aku@magus.cs.utah.edu> kruckenb writes: : >Brad Midgley (bmidgley@lal.cs.utah.edu) wrote: : The single-access is a limitation in ftpfs itself. Basically the : author was tring to simplify things by assuming no two users will want : to look around or transfer from the same site. Queuing requests to a : single connection isn't good because one user could initiate a huge : transfer and then until it's finished, no one could even list directories. Agreed. You could have some intelligent queueing, though, with a "large file" queue and a "small file" one, to make things run pretty quickly (on the small file/ls side) without completely loading down the remote site, or using up several of the limited anonymous logins at the remote site. : >- Automatic mirroring of directories (and maybe index files) at : >specified sites. That way, you can see the directory immediately (and : >the index file, too), and it is always kept up to date (say, once per : >day). When you try to access any of the files, then it is dnloaded via : >ftp. This would also provide a mechanism to mark entries in the cache : >as 'dirty' based on the new directory info. : This really sounds more like a full-blown mirror than a cache. If you : have enough space and enough transfer bandwidth, mirroring would be a : better idea anyway. I should have been more clear. By saying "mirroring of directories", I meant the directory *entries*, not the files themselves. So, if I do an "ls", I see the directory entries that have been cached locally, rather than having to wait for ftpfs to open the connection, read the directory, and show it. However, if I attempt to access a file that hasn't been cached already, I have to wait for it to be ftp'd. Clearer? As part of this, certain files in each directory could be automatically cached along with the directory entries, such as the 00Index.txt, etc, to save time (and bandwidth) in accessing them locally. I dont' know: can this be done? I mean, showing just directory entries even if the files themselves aren't there (well, some of them may be there if they've been cached)? : Ftpfs uses the ftp connection to check timestamps on files there. It : uses the timestamp to decide when cache entries are invalid. ("dirty" : implies that you're caching writes which probably isn't what you : meant.) The problem is that each time a file is accessed, it has to be checked. Why not automatically check a bunch of files at once, by having a periodic "dirty daemon" that checks the files in often-changing directories to see if they've been changed. Sure then there's a chance that the user would get an old file, but that's no worse than accessing an old version at a mirror ftp site. : >- ftpfs should understand the concept of mirrors, and allow (at the : >minimum) the ability to define redundant sites. If it can't get on at : >one, it tries the others, until one is open. A priority should be : >assigned to let you pick the fastest, or closest, one first. ftpfs : >could also dynamically re-assign this priority based on how well the : >sites work, so that it will eventually pick the best one by itself. : Now this is an interesting idea. You'd have to hide the fact that the : mirror may be mirroring in a subdirectory somewhere. so perhaps : mkdir /ftpfs/sunsite.unc.edu : if sunsite were down (couldn't happen :) would open a mirror "blah" : and point sunsite to the appropriate subdirectory: : /ftpfs > ls -l : drwxrwxrwx 1 anonymous 10 Jul 23 1993 blah : lrwxrwxrwx 1 anonymous 10 Jul 23 1993 sunsite.unc.edu->blah/mirrors/sunsite : But then the user should be aware of this so he doesn't try to upload : to the mirror (unless mirrors know how to handle uploads to their : mirror hierarchy) You could have some way of specifying (maybe in an /etc file) that uploads can't be done to linked directories, only to the "real" directory. Have a daemon running that moves uploaded files to the ftp site as the ftp site becomes available. Pete. ------------------------------------------------------------------------ Pete Kruckenberg School: kruckenb@sal.cs.utah.edu University of Utah Work: pete@dswi.com Computer Engineering For even more addresses, "finger pete@dswi.com" ------------------------------ From: aek@cs.man.ac.uk (Alan Knowles) Crossposted-To: comp.os.linux.help Subject: Sound Galaxy Soundcard Initialisation Date: 27 Sep 1994 14:16:04 GMT Linux works well on my system (486DX33 - 8MB - S3 video - Sound Galaxy Pro16 - Panasonic CD) ***BUT*** Sound and CD work fine under Linux only if, after powering up the system, MSDOS is booted (at least as far as the point in CONFIG.SYS which loads a driver (EEPROM.SYS) supplied with the sound card). If this is not done, the sound card is not initialised properly, sounds do not play for mre than about one second (interrupt problem??) and the CDROM drive is not recognised. I guess that EEPROM.SYS causes information contained in the EEPROM on the sound card to be used to initialise its registers. (This fits in with comments in the latest Voxware distribution about the need to boot MSDOS before Linux when using software configured soundcards (not jumpers)). What I need is information on how to copy the EEPROM data into the registers. Even better would be code already written. This could then, I hope, be relatively easily incorporated into my copy of init.c (??) in /usr/src/linux/drivers/sound. It should not be too big (EEPROM.SYS is only 3K, 2K of which is full of zeroes). Any input would be welcome. Alan Knowles ------------------------------ From: srini@igt.com (Srini Seetharam) Subject: problems compiling kernel 1.1.45+ for scsi Date: 27 Sep 1994 18:44:26 GMT I am running Slackware 1.2 with kernel 1.1.13. I presently have only ide drives and they work just fine. I ahev some (little) experience compiling kernels. I compiled 1.1.13, 1.1.35 many times with varying options. I need to compile a kernel higher than 1.1.45 to support my new scsi NCR 53c810 chip. I downloaded 1.1.45 sources and the patches from 46 to 50. I first patched all the way up to 50 and tried, but it bombed out, same with 49. So I tried patching up to 46 and it bombed out too. the error messages are all very similar. this one was 1.1.46 =============cut here========================== gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -pipe -m486 -c hd.c rm -f block.a ar rcs block.a ll_rw_blk.o floppy.o ramdisk.o genhd.o hd.o sync make[2]: Leaving directory `/usr/src/linux/drivers/block' make[2]: Entering directory `/usr/src/linux/drivers/char' gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -pipe -m486 -c tty_io.c gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -pipe -m486 -c n_tty.c gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -pipe -m486 -c console.c gcc: Internal compiler error: program cc1 got fatal signal 4 make[2]: *** [console.o] Error 1 make[2]: Leaving directory `/usr/src/linux/drivers/char' cpp: output pipe has been closed make[1]: *** [driversubdirs] Error 1 make[1]: Leaving directory `/usr/src/linux/drivers' make: *** [linuxsubdirs] Error 1 runabout:/usr/src/linux# ==========================cut here ============================ this one is 1.1.49 =========================cut here============================ gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -pipe -m486 -c sd_ioctl.c -o sd_ioctl.o gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -pipe -m486 -c g_NCR5380.c -o g_NCR5380.o NCR5380.c: In function `NCR5380_information_transfer': In file included from g_NCR5380.c:171: NCR5380.c:1915: warning: unused variable `transfersize' ln 53c7,8xx.scr fake.c gcc -D__KERNEL__ -I/usr/src/linux/include -E -DCHIP=810 fake.c | grep -v ^# | perl script_asm.pl fake.c:55: unterminated character constant fake.c:70: unterminated character constant fake.c:192: unterminated character constant fake.c:238: unterminated character constant fake.c:368: unterminated character constant fake.c:545: unterminated character constant fake.c:570: unterminated character constant fake.c:587: unterminated character constant fake.c:794: unterminated character constant fake.c:837: unterminated character constant fake.c:906: unterminated character constant fake.c:995: unterminated character constant fake.c:996: unterminated character constant sh: perl: command not found cpp: output pipe has been closed make[2]: *** [53c8xx_d.h] Error 127 make[2]: Leaving directory `/usr/src/linux/drivers/scsi' make[1]: *** [driversubdirs] Error 1 make[1]: Leaving directory `/usr/src/linux/drivers' make: *** [linuxsubdirs] Error 1 runabout:/usr/src/linux# ========cut here======================================== Any help is appreciated. thanks, srini srini@igt.com ------------------------------ From: andy@eng.kvaerner.no (Andrew Walker) Subject: >1GB SCSI disks & Buslogic Adapters Date: 28 Sep 1994 04:30:33 -0400 Reply-To: andy@eng.kvaerner.no (Andrew Walker) Hi, There seems to be a lot of confusion around the use of large (> 1GB) SCSI disks with Buslogic host adapters (e.g. BT-445S/BT-545S etc..) I thought I'd try and clear things up a bit. The Buslogic adapters have an option to translate drive parameters so that DOS can deal with disks larger than 1GB. The translation tables are as follows: <=1GB Heads 64, Sectors 32, Cyls X >1GB <=2GB Heads 128, Sectors 32, Cyls X >> 1 >2GB <=4GB Heads 256, Sectors 32, Cyls X >> 2 >4GB <=8GB Heads 256, Sectors 64, Cyls X >> 3 Without the translation option, the drive geometry will always be reported as (same as <=1GB): Heads 64, Sectors 32, Cyls X Unfortunately, the Linux Buslogic driver has no way of finding out if this option is turned on (since it doesn't, and can't, use the Buslogic BIOS). On the assumption that people owning >1GB drives probably want them to be useable from DOS, the driver assumes that the translation is on, and thus tries to mirror the translation for disks >1GB. In this way DOS and Linux can agree on, and share, the partition table for the disk. So, if you access your >1GB disk from DOS you need to turn the translation on. Linux will then happily co-exist with, and agree with, DOS's picture of your disk. If you only access your >1GB disk from Linux, it really doesn't matter whether the translation is on or off. The driver will do the translation anyway, but nobody will get hurt. Right! Hope that helped somebody. Now a question. - does anybody know how we can find out if translation is enable on a Buslogic adapter (undocumented functions????) -Andy -- Andy Walker Kvaerner Engineering a.s. Andrew.Walker@eng.kvaerner.no P.O. Box 222, N-1324 Lysaker, Norway ......if the answer isn't violence, neither is it silence...... ------------------------------ From: zoelzer@informatik.uni-wuerzburg.de (Horst Zoelzer) Subject: Mitsumi and Multisession CD's Date: 26 Sep 1994 09:13:06 GMT Hallo ! I have recently bought a Mitsumi FX001D CD-ROM drive and I have no problems under DOS or Windows or Linux. But when I try to mount a multisession CD under Linux the system prompts an error like this one: can't find superblock Because I can read this CD under DOS and Windows I think it is a problem with the dirver for Mitsumi CD-ROM's. Is there any possibility to mount multisession CD-ROM's under Linux with a Mitsumi FX001D ? Is somebody updating the mitsumi driver for multisession CD's ? Best regards, Horst ------------------------------ From: jmccaski@Leda.CS.Trinity.Edu (Scott McCaskill) Subject: Is clock() broken in gcc 2.5.8? Date: 27 Sep 1994 05:41:09 GMT Does anyone know of any problems with clock() in gcc 2.5.8? I recently downloaded and installed the slackware release of linux (about 3 or 4 weeks ago) and this function does not appear to work as advertised. The code is extremely simple: #include #include int main() { cout << "\n\nclock() = " << clock() << endl; cin.get(); // wait a few seconds, then hit return cout << "clock() = " << clock() << endl; return 0; } CLK_TCK is reported as being 100, so 100 ticks per second. The output from the above code always indicates that clock() is returning the same value the second time it is called as the first time (usually 2 or 3), even when I wait several seconds before pressing return. Any ideas? Thanks, Scott =-=-=-=-=-=-=-=-=-=-=-= Scott McCaskill jmccaski@cs.trinity.edu. ------------------------------ Crossposted-To: comp.lang.fortran From: richard@radar.demon.co.uk (richard) Subject: Re: Compiler benchmarking. was Survey: who wants f77,cc,c++,hpf for linux? Date: Tue, 27 Sep 1994 00:10:09 +0000 Robert Lipe (robertl@arnet.com) wrote: [stuff deleted] : With that specific test, it's entirely attributable to the hot : optimization. The math libraries are mostly for floating point type : stuff, and dhrystone uses none of that. I would expect this. You are comparing an intel optimised compiler to a compiler that is supposed to be portable first, and optimising next. The model that GNU uses in the compiler seems to like having lots of general purpose registers to reference, which the x86 does not have. -- Richard Hodson | richard@radar.demon.co.uk :1,$s/DOS/anal secretion from hell/g | rhodson@cix.compulink.co.uk ------------------------------ From: rgeens@uia.ac.be (Ronald.Geens) Subject: Re: Trouble using "execl" Reply-To: rgeens@uia.ac.be Date: Mon, 26 Sep 1994 09:16:05 GMT >In article <35s10k$bge@hopper.acm.org>, ian_vogt@ACM.ORG writes: >|> >|> >|> I am trying to get a task to transform into another program >|> using the "execl" function call. The task appears to die >|> with the following displayed on the screen: >|> >|> libc.so.4 (DLL Jump 4.5pl26) => /lib/libc.so.4.5.26 >|> >|> Can anyone tell me what this means, what I'm doing wrong, and/or >|> how to fix it? >|> >|> A trace line just before the "execl" prints but I don't get tracing >|> from after the "execl" or from the beginning of the target program. > >Use the correct arguments to execl() and it will work as doccumented/expected. > No way it won't. What args are wrong here ? This program works perfectly allright on SunOS 4.3 and Solaris, but not on Slackware ... #include #include main() { char *args[1]; args[0]=NULL; printf("pid = %d, pgrp = %d\n",getpid(),getpgrp()); if (execl("a.out",NULL)<0) perror("What the fuck\n"); /* or if (execve("a.out",args,args)<0) perror("What the fuck\n"); */ printf("What is this\n"); return 0; } >Mitch ------------------------------ From: root@beast.oau.org (Breakdown) Subject: A umount bug? Date: Mon, 26 Sep 1994 02:15:18 GMT I mounted a floppy on /mnt with mount -t ext2 /dev/fd0 /mnt and then after copying and removing stuff off and on, when I try to umount it with umount /mnt it gave me this crap: beast:~# umount /mnt Oops: 0000 EIP: 0010:0016f13c EFLAGS: 00010246 eax: 00160000 ebx: 00000000 ecx: 00000000 edx: 00160000 esi: 00bfeed4 edi: 00bfeed4 ebp: 00000000 esp: 00bfeea8 ds: 0018 es: 0018 fs: 002b gs: 002b ss: 0018 Process umount (pid: 468, process nr: 20, stackpage=00bfe000) Stack: 001c0200 001c0002 001260df 00bfeed4 00000000 Code: f6 01 02 74 0d 0f b7 46 10 50 e8 fd 2d fb ff 83 c4 04 be 48 Segmentation fault beast:~# I dont really know what the hell happened so if someone would please explain if they knew what was going on. It seems it's a bug, but I am not sure neither I had the guts to explore it. Thanks Genie ------------------------------ From: tjimenez@site.gmu.edu (fuzzy) Subject: Re: elf benchmarks (getting closer) Date: 27 Sep 1994 05:47:46 GMT forgive me if my ignorance is showing, but what exactly is ELF and how does it differ from using dll's? -- -fuZZy ------------------------------ Crossposted-To: comp.os.linux.development From: scheidel@gate.net () Subject: Special Sale On QNX! Date: Sun, 25 Sep 1994 09:34:56 GMT Why settle for slow and obselete Unix such as UnixWare, Sun Solaris, SCO, Linux or BSD when you can have POWER & RELIABILITY with QNX 4.21! Stop playing games with these inferior o/s's and switch to QNX today. QNX 4.21 represents the culmination of over a decade of research and experience with an installed base of over 250,000 microkernel, message- passing QNX operating systems world-wide. QNX combines the function- ality and flexibility of a research-calibre OS with the robustness and performance of a commercial OS! And, it's fast! Florida Datamation has been a QNX distributor for 10 years! We are nice, knowledgable and go the extra mile for the sale. And, we promise to BEAT ANYONE'S PRICE! A complete QNX developer's package starts at just $195! Michael S. Scheidell email: scheidel@gate.net Florida Datamation, Inc. US-CAN Sales: (800) 642-5938 6405 Congress Ave Suite 140 Internl Sales: (407) 241-2377 Boca Raton, FL. 33487-2844 Tech Support: (407) 241-2966 Fax: (407) 241-3108 Distributer of these other fine QNX products: Tilcon Graphics, Watcom SQL, Comdale, Klondike, Equinox Megaports. Scsi Tape/Disk and Raid Systems. ------------------------------ Crossposted-To: comp.os.linux.help Subject: HELP: Mounting Hitachi CD-ROM drive under LINUX!!!! From: michaelb@earlham.edu Date: Sun, 25 Sep 94 09:55:25 -500 Has anyone mounted an Hitachi CD-ROM drive under Linux? Would you be willing to share your driver or mounting instructions? Michael ---_________________________________________________________________________--- Michael L. Bowden | Voice: (317) 983-1355 Technology/Reference Librarian | Fax: (317) 983-1304 Drawer 198 | Internet: MichaelB@Earlham.Edu Earlham College | Internet: MichaelB@Tian.Earlham.Edu Richmond, Indiana 47374-4095 | ListOwner: LIBMASTR@UOTTAWA ------------------------------ ** 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 ******************************