Subject: Linux-Development Digest #102
From: Digestifier <[email-masked]>
To: [email-masked]
Date: Thu, 1 Sep 94 16:13:18 EDT

Linux-Development Digest #102, Volume #2          Thu, 1 Sep 94 16:13:18 EDT

Contents:
  Re: Future of Linux (Pekka J Taipale)
  Re: What is happening with MGETTY 0.2 (Tiger II)
  Re: Future of Linux (Bao Chau Ha)
  LIL- appearing sometimes and sometimes not? Why? (Yves Arrouye)
  Ed pb (Yves Arrouye)
  NFS max timeout reached with 1.1.42 (Christian Kranz)
  Re: Any interest for DCF77 clock code? (Rob Janssen)
  Re: <patch> updating system clock w/o APM ([email-masked])
  Re: Japanese, Arabic, Greek, etc. & Unicode (Matthias Urlichs)
  Re: TR for Linux ALPHA version 2 (Jim Brain)
  Re: how to do shared C libraries (was Re: nvi 1.34, curses and the new Linux C library) (David Barr)
  Future of linux -- the sequel (Peter.Leyssens)
  Re: Homemade Terminal Server cheap (Jamie Guinan)
  Got the bastard! [was re:fs corruption] (Christopher Cason)

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

From: [email-masked] (Pekka J Taipale)
Subject: Re: Future of Linux
Date: 01 Sep 1994 08:03:55 GMT

In article <[email-masked]> [email-masked] (Marty Connor) writes:
>What I think Linux needs to start to spread past the academic and hobbyist
>community is a few simple applications for regular folks. For example:
>...
>1.  You folks who tolerate_ Mac users could learn a lot from being forced to
>    _use_ a Mac for a while. [...]
>2.  People buy boxes that do what they need done.  People buy Microsoft Word 
>    boxes, Lotus 1-2-3 boxes, PageMaker boxes, etc.    [...]
>3.  Linux has many attractive features, its technical innovations and politics
>    chief among them.  What it needs now is MacWrite and MacDraw and MacPaint.
>    (or LinWrite, LinDraw, and LinPaint). [...]

Sorry about the long quote, but I can't resist saying: Amen. 

Martin Connor put it out so well. He can see what the future of Linux
needs, and what users expect to get if we want them to use Linux.

Linux's power is in its techical capability and political approach.
It's current weakness is the failure to respond to mass market demands
in applications. Sure, there's no one to blame; we must be happy to
have this environment in the first place. But Linux deserves all
attention it can get, also among those who are not academics or
hobbyists. That means, it deserves good applications. Developing these
is a priority task. (As is making existing PC applications run under
Linux; Dosemu and Wine are also very important).

>And to all a good night...

Same to you all.
--
[email-masked]

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

From: [email-masked] (Tiger II)
Subject: Re: What is happening with MGETTY 0.2
Date: 1 Sep 1994 16:38:10 GMT

In article <[email-masked]>, [email-masked] (Tiger II) says:
>
>What is happening to MGETTY 0.2? I have gone to several sites to pick
>it up and can't.

Never Mind:) The "+" was throwing off my FSP and FTP clients. There was a
way around the problem. WS_FTP allows the capability to view a file of 
which it creates a temporary file. Just rename the temporary file....

   ____________                      _   _ | Address: [email-masked]
       _/     /                      /   / | Descript: SDA, spelunker
      _/                            /   /  |           Banjo, Guitar            
     _/   /  /--/ /--| /---|       /   /   |           Mandolin, Dobro,
    _/   /  /  / /--/ /           /   /    |           three kids,  
   _/  _/  /__/ /__  /          _/  _/     |           OS/2 & Linux Fan
             /
           _/   "My opinion is expressed as: I'm Mister Cellophane Man."

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

From: [email-masked] (Bao Chau Ha)
Subject: Re: Future of Linux
Date: Thu, 1 Sep 1994 13:07:38 GMT

In article <[email-masked]> [email-masked] (Alan Cox) writes:
>In article <[email-masked]> [email-masked] (Mike Suzio) writes:
>>This thread is (potentially) important, if people would get off the emacs
>>proselytizing and get savvy to the real issues.  No one is trying to turn
>>Linux into a Mac clone, because Macs are dumb.  No one who knows the power
>>of Unix is going to dispute the usefulness of a CLI.  The real issue is
>>integrating in the power (and advantages) of a GUI, too.
>
>Or at the very least providing a plug and play environment for novices. It
>doesn't matter if smart users hate it - they can install a smart environment
>of which their are no shortages. MAC's drive me up the wall but for some
>people its great. Unix/X has the power to have both at once according to
>user preference.. Thats good
>
Now, the real questions!  Has anybody thought about customizing the
Linux's X environment to be as user friendly as a Mac or Windows?  Or
is this idea even warranted a serious consideration?  The people who
prefer the Mac environment would definitely not be able to learn
enough to know their ways around X, or should I say not having enough
patient.  My feeling is that somebody will have to preset X first for
these people.  We could certainly follow the suggestions of the Apple's
human interface design guidelines.  It may be dumb, but Apple certainly
has made billions of dollars out of it.

I personnaly think it is doable, and maybe a good thing to have.  I also
feel that a consistent GUI may provide a fertile ground to develop
"consumer" software and help to popularize Linux into the mass.

My $0.02 worth.
Bao

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

From: [email-masked] (Yves Arrouye)
Subject: LIL- appearing sometimes and sometimes not? Why?
Date: Thu, 1 Sep 1994 09:13:18 GMT

Hello,

Using LILO on my machine (1.1.48, two IDE drives one of which has LILO on the  
MBR, and an SCSI drive controlled by an AHA1542C with INT19H disabled), I have  
some problems which did not appear before: sometimes, without any reasons,  
LILO hangs and prints LIL-, which means, according to the documentation, that  
there is a geometry mismatch. If I then boot from floppy, reinstall LILO and  
reboots, it works... until after some reboots the same problem happens.

Do you have an idea about the cause of this? It is extremely annoying and I  
*really* do not know why it happens so irregularly...

Thanks,
Yves.
--
Advocates for the C++ school claim that a well designed           Yves Arrouye
    program does not need the extra flexibility (a lie),  [email-masked]
while advocates for the Objective-C school claim that         (33) 76 57 48 64
    the errors are no problem in practice (another lie).             NeXT Mail

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

Crossposted-To: comp.os.linux.help
From: [email-masked] (Yves Arrouye)
Subject: Ed pb
Date: Thu, 1 Sep 1994 09:15:58 GMT

Hello,

I just wanted to tell that ed does not accept invokations like

        % ed - some-file-name

and yields:

        ed: no such filename            (or something like that)
        %

which are heavily used in shell scripts. Sorry to post that here, but as I  
cannot find ed's author email, I cannot directly tell her (him). I hope this  
post will be read by the right people, and the pb corrected.

Thanks,
Yves.

--
Advocates for the C++ school claim that a well designed           Yves Arrouye
    program does not need the extra flexibility (a lie),  [email-masked]
while advocates for the Objective-C school claim that         (33) 76 57 48 64
    the errors are no problem in practice (another lie).             NeXT Mail

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

From: [email-masked] (Christian Kranz)
Subject: NFS max timeout reached with 1.1.42
Date: 1 Sep 1994 08:29:32 GMT

We have done the jump from kernel 1.1.0 to 1.1.42 before
some days and are bothered now with the kernel error message

<6>NFS max timeout reached on sent5
[...]

after some days uptime. The system

Linux sent9 1.1.42 #4 Wed Aug 10 15:08:49 MET DST 1994 i386
9:17am  up 7 days, 8 min,  1 user,  load average: 1.39, 1.22, 1.10

If this problem is solved in newer kernel releases,
i would like to know it.

  Ch. Kranz ([email-masked])

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

From: [email-masked] (Rob Janssen)
Subject: Re: Any interest for DCF77 clock code?
Reply-To: [email-masked]
Date: Wed, 31 Aug 1994 22:10:20 GMT

In <[email-masked]> [email-masked] (David Kastrup) writes:

>Trying to get a head count...
>How many people would be interested in a small program which gets the current
>time from the radio clock DCF77 (receivable about 900km around Frankfurt,
>Deutschland, official time base for Germany) and sets the system time?
>Comes with man page, and has
>options making it secure to use, say, daily in your crontab, while updating
>the CMOS clock as well.

I would prefer it to be a daemon that watches the transmissions all the time,
and uses adjtime to steer the system clock to track the transmissions.
Programs that run once a day tend to be "read the data and abrubtly set the
time" type of thing, which is not optimal under UNIX....

>It sets UTC directly, so is timezone independent. You need a small radio
>clock device tied up to a serial port.

That is great

>This program will be freely available to whoever wants it.

>However, making it a package requires that there are specifications
>included concerning the hardware.

>Would you please answer me, and tell me if
>a) A logic description of the hardware would be ok for you.
>b) A circuit diagram would be ok for you (circuits about 20DM)
>c) You would rather buy a finished product for 50DM.

I already have the hardware, which is probably similar to what you will
propose.  It is currently wired to provide the raw (AM-detected 77.5KHz)
signal on both "received data" and "DCD" of the serial port, which
provides for two different techniques of decoding.  Writing a daemon for
this is still "on the (long) list"... :-(

I think it is a good idea to provide hardware and/or schematics, but
as you may know there are also commercial suppliers of those gizmos.
They are usually delivered with MSDOS software, so writing a good daemon
for Linux is the major part of the game.

Rob
-- 
=========================================================================
| Rob Janssen                | AMPRnet:   [email-masked]           |
| e-mail: [email-masked]     | AX.25 BBS: PE1CHL@PI8UTR.#UTR.NLD.EU     |
=========================================================================

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

From: [email-masked]
Subject: Re: <patch> updating system clock w/o APM
Date: 1 Sep 94 10:00:27 GMT

I use Linux 1.1.48 on T3400, which can supend and resume,
but does not have APM bios.
I made the following small patch to update system clock.
The interval of update is determined by the BogoMips.
It might be useful these machines with suspend/resume
but without APM.

There was minute/second mismach in warp_clock, kernel/time.c. 

Of course, you may redistribute this pach under the GPL.

Nozomi

_________________________________

--- kernel/sys.c.original       Sun Aug 28 12:21:37 1994
+++ kernel/sys.c        Sun Aug 28 12:35:56 1994
@@ -35,6 +35,11 @@
           return -EINVAL;
 }

+extern unsigned long refresh_system_time_each;
+extern unsigned long system_time_refresh;
+extern void warp_clock(void);
+extern void ask_RTC_time(void);
+
 asmlinkage int sys_idle(void)
 {
           int i;
@@ -51,6 +56,11 @@
           for (;;) {
                   if (hlt_works_ok && !need_resched)
                           __asm__("hlt");
+               if(0 == --system_time_refresh) {
+                 ask_RTC_time();
+                 warp_clock();
+                 system_time_refresh = refresh_system_time_each;
+               }
                   schedule();
           }
 }
--- kernel/time.c.original      Sun Aug 28 12:27:05 1994
+++ kernel/time.c       Sun Aug 28 12:35:12 1994
@@ -60,23 +60,9 @@
             )*60 + sec; /* finally seconds */
 }

-void time_init(void)
+void ask_RTC_time(void)
 {
           unsigned int year, mon, day, hour, min, sec;
-       int i;
-
-       /* checking for Update-In-Progress could be done more elegantly
-        * (using the "update finished"-interrupt for example), but that
-        * would require excessive testing. promise I'll do that when I find
-        * the time.                    - Torsten
-        */
-       /* read RTC exactly on falling edge of update flag */
-       for (i = 0 ; i < 1000000 ; i++) /* may take up to 1 second... */
-               if (CMOS_READ(RTC_FREQ_SELECT) & RTC_UIP)
-                       break;
-       for (i = 0 ; i < 1000000 ; i++) /* must try at least 2.228 ms*/
-               if (!(CMOS_READ(RTC_FREQ_SELECT) & RTC_UIP))
-                       break;
           do { /* Isn't this overkill ? UIP above should guarantee consistency */
                   sec = CMOS_READ(RTC_SECONDS);
                   min = CMOS_READ(RTC_MINUTES);
@@ -98,6 +84,25 @@
                   year += 100;
           xtime.tv_sec = mktime(year, mon, day, hour, min, sec);
 }
+
+void time_init(void)
+{
+       int i;
+
+       /* checking for Update-In-Progress could be done more elegantly
+        * (using the "update finished"-interrupt for example), but that
+        * would require excessive testing. promise I'll do that when I find
+        * the time.                    - Torsten
+        */
+       /* read RTC exactly on falling edge of update flag */
+       for (i = 0 ; i < 1000000 ; i++) /* may take up to 1 second... */
+               if (CMOS_READ(RTC_FREQ_SELECT) & RTC_UIP)
+                       break;
+       for (i = 0 ; i < 1000000 ; i++) /* must try at least 2.228 ms*/
+               if (!(CMOS_READ(RTC_FREQ_SELECT) & RTC_UIP))
+                       break;
+       ask_RTC_time();
+}
 /* 
  * The timezone where the local system is located.  Used as a default by some
  * programs who obtain this value by using gettimeofday.
@@ -250,7 +255,7 @@
 inline static void warp_clock(void)
 {
           cli();
-       xtime.tv_sec += sys_tz.tz_minuteswest * 60;
+       xtime.tv_sec += sys_tz.tz_minuteswest;
           sti();
 }

--- init/main.c.original        Sun Aug 28 12:18:38 1994
+++ init/main.c Sun Aug 28 12:37:58 1994
@@ -247,6 +247,9 @@

 unsigned long loops_per_sec = 1;

+unsigned long refresh_system_time_each;
+unsigned long system_time_refresh;
+
 static void calibrate_delay(void)
 {
           int ticks;
@@ -266,6 +269,8 @@
                           printk("ok - %lu.%02lu BogoMips\n",
                                   loops_per_sec/500000,
                                   (loops_per_sec/5000) % 100);
+                       system_time_refresh 
+                         = refresh_system_time_each = loops_per_sec/10000;
                           return;
                   }
           }
--
[email-masked]

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

From: [email-masked] (Matthias Urlichs)
Subject: Re: Japanese, Arabic, Greek, etc. & Unicode
Date: 1 Sep 1994 07:01:45 +0200

In comp.os.linux.development, article <[email-masked]>,
  [email-masked] writes:
> 
> I haven't sat down and figured it out, but I'd guess that if you tried
> to represent all letter forms in Arabic using separate keys, you'd
> quickly run out of keys.  The solution is either to use shift, control,
> and meta keys (not enough) or to use some sort of contextually determined
> change.  I'd guess that a simple finite-state automaton could be gen-
> erated from keyboard definitions that allowed before and after contexts,
> and could be loaded at run-time.  Backwards-compatible extensions to the
> keyboard configuration file would be required, specifically before and
> after contexts.
> 
I'd be more in favor of storing the text in a context-independent form and
doing the letter form modification when the text is printed or whatever.

This is what the Mac scripting system does. It seems to work well, and you
can edit the characters you want to edit without bothering to also change
the surrounding stuff.

> In languages like Hebrew, which also have contextually determined letter
> forms, the possibilities are far more limited.  And in fact the standard
> Israeli keyboard simply has them all bound to separate keys.  You can do
> this in Hebrew with just shifted and unshifted keystrokes, so it works
> just fine.  Hebrew would, therefore, be an easy place to begin support-
> ing non-western scripts at the keyboard.
> 
On the other hand, doing the more difficult scripting system first makes
sure that you don't program yourself into a corner.

I.e., you start with Hebrew, get it working, then try to do Arabic but
realize that you have to redo the whole thing if you want to get it
working. Oops.

-- 
To remember is to understand.
-- 
Matthias Urlichs        \ XLink-POP Nürnberg  | EMail: [email-masked]
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 <A HREF="http://smurf.noris.de/~urlichs/finger">here</A>.

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

From: [email-masked] (Jim Brain)
Subject: Re: TR for Linux ALPHA version 2
Date: 1 Sep 1994 10:47:01 -0400
Reply-To: [email-masked]

In article <[email-masked]>,
didier@Lorente ( dominique Duvivier ) wrote:
> Peter De Schrijver ([email-masked]) wrote:
> :>Hi,
> 
> :>I have put the second alpha version of my token ring driver for IBM boards on
> :>sunsite.unc.edu in /pub/Linux/Incoming. It should work on ISA boards too (the
> :>previous version had a bug in it). The patch contains also a new version of
> :>the PS/2 ESDI device driver. It should be more stable than the previous
> :>version.
> 
> :>Peter.
> 
> What should I place in rc.inet1 after ifconfig to avoid the message:
> "SCIOCSIFFLAGS: Try again" ? (I have a ISA board)
> 
> DoM
> 
> PS: Continue the job, I know quite a few people who will just worship
> you for this...

I know I will worship him.  I dloaded his stuff last night, but being
the newless cluebie I am, I had to ask him where I could grab the .47 source.
Patching the .45 source of his ealrier version left _ed_???? undefined. 

Oh well, I will work on it, since I am so ecstatic about finally being able
to put the box on the network.

Small plug for Linux from me.  I work at Compuware Corporation, who is a big
mainframe company now doing client-server as well.  They just launched 
a UNIX initiative.  Well, I started coding up prototypes on the Suns Sparc5
that they bought, but the compiler license ran out.  I had to get the
prototype finished, so I switched on my Linux box, coded the stuff up, 
demoed it, and received much praise.  I told everyone who would listen,"
You can say whatever you want about Linux, but remember that it got the job
done."

I know, small mindless, and childish, but I just couldn't resist after the 
10th rendition of "Linux is a toy, you can't do real work with it"

Ahem.

--              
Jim Brain, Embedded Systems Designer, Brain Innovations.
[email-masked]  
Dabbling in VR, Old Commodore Computers, and Good Times!
"The above views DO reflect my employer, since I am my employer" - Jim Brain

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

From: [email-masked] (David Barr)
Subject: Re: how to do shared C libraries (was Re: nvi 1.34, curses and the new Linux C library)
Date: 1 Sep 1994 13:44:45 -0400

In article <[email-masked]>,
Robert Sanders <[email-masked]> wrote:
>On 1 Sep 1994 10:38:46 -0400, [email-masked] (David Barr) said:
>> Sure, but the loader mechansim is significantly different than
>> Solaris', so it's not really the same.
>
>Could you be a bit less concise here?  Solaris uses ld.so to load the
>shared libraries; Linux uses ld.so to load the shared libraries.

Right.  However, as I said the loader (ld.so) is significantly
different between Linux and Solaris.  When I said loader I mean
loader.  What else shall I say?

Okay, I'll spell it out.  In Solaris, the filename of the shared
libraries to load are stored at compile-time.  There's also
run-time directory search list which is built from ld's -R flag and
LD_LIBRARY_PATH, if set.

In Linux, there is no distinction between run-time directory search
lists and compile-time directory search lists, except via LD_LIBRARY_PATH.
Linux uses SunOS 4.x's style library cache, plus an ldconfig which
does a symbolic link for you to the latest version of the shared library.
If you have programs compiled to use a previous version of the libarary,
you're stuck when you upgrade.  (witness all the stuff about seyon
regularly breaking with each C library upgrade)

If Linux did things in more of a Solaris style, then older programs
would continue working (as long as the old shared libarary was kept
around).  If you needed newer functionality or wanted to get rid
of the old library, simply recompile.  (or you could even try your
luck and symlink the old library to the new if it was partially
incompatible)

--Dave

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

From: [email-masked] (Peter.Leyssens)
Subject: Future of linux -- the sequel
Reply-To: [email-masked]
Date: Thu, 1 Sep 1994 14:34:32 GMT

Hi,

I think Linux used to be quite fine as it is, but now things are changing.
Linux is a free Unix-clone and there is no reason to choose it over another
U**x-version except that it's free.  If you want a more stable system or 
a better programming, you can choose something different.

Linux was THE choice when the only other choices were BSD/386 or OpenDesktop.
Now, there's Solaris, NextStep as well, and Windows NT.  OK, OK, WinDooze NT
isn't worth a dime, because it's MicroSoft, but here's my point :

It's time to make choice.  There's a lot ahead (Multi-Processing, Micro-kernels)
and Linux is NOT following.  This should be quite clear.  Everybody's constantly
asking : "Has Linux already been ported to system XXX or CPU YYY ?"  And
the usual answer is : nope, but they're working on it, wait a year or so.
Porting takes way too long.  Linux is stuck on one system, and that's the
Intel PC-series with ISA/VL-BUS.

And with multi-CPU-pc's knocking at your door (I mean, this is reality : 
dual Pentiums are becoming more and more common, there are Inmos T800 and
i-860 plug-in-boards, and the Acorn Risc-PC has the standard multi-CPU
system, that allows 2 completely different (1 ARM, 1 486) to work together),
it's time to jump on that boat.

The only way (as I see it) to get great multi-processing power is to find
a micro-kernel (or write one :), and see that the rest is portable enough.
Linux isn't portable.  And we all would like to plug in a Dec/Alpha board
into our PC and see performance triple, wouldn't we ?

I heard Linux/Mach is being worked on...  Well, Mach isn't quite multi-
processing either (or is it ?).  I'd like to have some information on that
please, I'll be compiling the Mach-kernel myself one of these days.  
Unfortunately, next year will be my last year at the university, so I'll
have plenty to do, and I don't know if I'll be having Internet access afterwards.
So I'm afraid I won't be of any use 'till I know for sure my future job
has Internet access...

Anyways, the other choice is to keep on the same track, making Linux an
application environment like WinDooze and we all know that's fun for
not more than half an hour, don't we ?

Peter Leyssens
[email-masked]

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

From: [email-masked] (Jamie Guinan)
Crossposted-To: comp.dcom.servers
Subject: Re: Homemade Terminal Server cheap
Date: 1 Sep 94 19:17:48 GMT

In article <[email-masked]>, [email-masked] (Stephen Balbach) says:
>Cyclade ([email-masked]) has released a 16-port 115k serial card (risc 
>based) with drivers for Linux.  Up to 2 cards can be put in one machine.  
>32 port cost $400 (!!).  Plus the cost of a PC and ethernet card 
>you have a 32 port SLIP,CSLIP,PPP terminal server for $1500.
>Is anyone working on this idea?  Linux has excellent TCP/IP support and 
>utilities.  Creating menus would be a snap for log in choose which 
>protocall to use.  For real perfomance use local bus and Pentium would 
>probably outperform traditional terminal servers.  For about half the cost.
>Stephen Balbach

Stephen,
I also read about Sealevel Systems, Inc. which has an 8-port board
with 16550 uarts.  I'm planning to implement dial-in services for
my department at Suffolk University.  I've tried a Practical Peripherals
modem on a GW/2000 486/66 and it works like a charm.  Getty (uugetty),
however, was a big pain-in-the-ass to set up, as it was compiled to
look for default files in different locations from what the documentation 
specifies.

Does anyone out there have any experience with either the Sealevel or 
the Cyclade products?  I'd prefer not to be the guinea pig on this, but I will
anyway if no-one else has.  Email me direct with any experiences,
people.

Later,
-Jamie

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

From: [email-masked] (Christopher Cason)
Subject: Got the bastard! [was re:fs corruption]
Date: 1 Sep 1994 14:15:29 GMT

'bout two weeks ago I posted regarding continuous file system corruption
problems I had been having on my SCSI-based system. several people replied
(thanks, all!) but this did not solve the problem. I had swapped everything
in my system except for two things - the video and ethernet cards.

The culprit ? A WD8013-based ethernet card. Why ? I have no idea. When the
card is in the machine, the corruption happens clearly every time. (My test
is to mkfs a clean FS, mount it, and copy a 30mB file then do a cmp). When
it's out, it doesn't. And the FS gets clobbered every time it happens.

Changing the base address and IRQ did not alter what was happening. Nor
did re-configuring the kernel not to use the card.

If anyone can shed any light on this I'd much appreciate it ! I'd like to
be able to use the card if possible. (BTW, whilst a 'noname' brand, it has
seemed to work more-or-less OK when in the machine.) Also, I have no
problems running this configuration under DOS without the data corruption
problems, so presumably it has something to do with protected mode or DMA
or whatever.

Hardware/Software.

The problems occurred on two totally separate machines.

486DX/50
20mB
Buslogic BT-545S SCSI controller, I/O 330, IRQ 11, DMA 5
Quantum 1080 SCSI drive.
Maxtor IDE drive (root).
SB 1.0 sound card (problem happened with it in or out.)
Trident 8900 w/512k.
WD8013 at 280 or 240, IRQ 15 or 7, either way. RAM at d0000.
Kernel 1.0.8 _or_ 1.1.18, either way. same problem.

486DX2/66
16mB
Adaptec 1542 SCSI controller, I/O 330, IRQ 15, DMA 5
Conner 1380 SCSI drive.
with or without Maxtor IDE drive mapped as root.
PAS16 clone sound card (problem happened with it in or out.)
Trident 8900 w/512k.
WD8013 at 280, IRQ 11. RAM at d0000.
Kernel 1.0.8 _or_ 1.1.18, either way. same problem.

regards,

-- Chris

==============================================================================
| Chris Cason via Univ. of Western Australia : [email-masked]  |
|  Disclaimer : I don't work for/study at UWA. This is a commercial account  |
==============================================================================
|  POV by EMAIL : mail [email-masked] with word HELP in body    |
|  POV by FTP   : FTP to ftp.uwa.edu.au and cd to pub/povray                 |
|  POV-Ray is a FREE raytracer for DOS, UNIX, VAX, Mac, Amiga, OS/2, etc.    |
|   - check out the images in our HALL_OF_FAME/ and Images_of_the_month/ ! - |
==============================================================================

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

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