Subject: Linux-Development Digest #237
From: Digestifier <[email-masked]>
To: [email-masked]
Date: Wed, 28 Sep 94 07:13:11 EDT

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!!!! ([email-masked])

----------------------------------------------------------------------------

From: [email-masked] (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....
--
*----===========================================================------*
*           [email-masked]   |   [email-masked]        *
* [email-masked] | [email-masked]    *
*                      BBS # (614) 235-5942                           *
* Fnord                   All hail Eris!                      Fnord   *
* finger [email-masked] or FREQ PGPKEY from 1:226/560 for PGP key *
*---=============================================================-----*

------------------------------

Subject: Re: Don't use Linux?!
From: [email-masked] (David Holland)
Date: 25 Sep 94 13:45:15

[email-masked]'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.
     [email-masked] | Unfortunately, it's a moment of inertia."

------------------------------

From: [email-masked] (Pete Kruckenberg)
Crossposted-To: utah.linux
Subject: Re: pseudo ftp mirrors
Date: 26 Sep 1994 05:00:12 GMT

Brad Midgley ([email-masked]) wrote:
: In article <[email-masked]> kruckenb writes:
: >Brad Midgley ([email-masked]) 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: [email-masked]
  University of Utah                       Work: [email-masked]
  Computer Engineering    For even more addresses, "finger [email-masked]"

------------------------------

From: [email-masked] (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: [email-masked] (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
[email-masked]

------------------------------

From: [email-masked] (Andrew Walker)
Subject: >1GB SCSI disks & Buslogic Adapters
Date: 28 Sep 1994 04:30:33 -0400
Reply-To: [email-masked] (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.
[email-masked]            P.O. Box 222, N-1324 Lysaker, Norway

   ......if the answer isn't violence, neither is it silence......

------------------------------

From: [email-masked] (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: [email-masked] (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 <time.h>
#include <iostream.h>

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
[email-masked].

------------------------------

Crossposted-To: comp.lang.fortran
From: [email-masked] (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 ([email-masked]) 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                          |  [email-masked]
:1,$s/DOS/anal secretion from hell/g    |  [email-masked]

------------------------------

From: [email-masked] (Ronald.Geens)
Subject: Re: Trouble using "execl"
Reply-To: [email-masked]
Date: Mon, 26 Sep 1994 09:16:05 GMT

>In article <[email-masked]>, [email-masked] 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 <stdio.h>
#include <unistd.h>
 
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: [email-masked] (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: [email-masked] (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

        <did they buy it?>
        <I don't think they bought it.>
        <of course they bought it.>
        <shush, they're looking this way, remember to keep a straight face...> 

------------------------------

Crossposted-To: comp.os.linux.development
From: [email-masked] ()
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: [email-masked]
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: [email-masked]
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:  [email-masked]
   Earlham College                  |   Internet:  [email-masked]
   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: [email-masked]

You can send mail to the entire list (and comp.os.linux.development) via:

    Internet: [email-masked]

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
******************************