Linux-Development-Sys Digest #269, Volume #6 Wed, 13 Jan 99 07:13:59 EST
Contents:
Re: 2.2.0pre6 booting errors (Nathan Myers)
Re: LILO and 10 GB drives ("Johan F. Gerlofs")
Re: Linux should not support non-free modules (Mark Tranchant)
Re: 2.2p6 SMP System Hang When Running Sox (Nathan Myers)
Re: Why I'm dumping Linux, going back to Windblows ("Russell L. Rader")
Re: Why I'm dumping Linux, going back to Windblows ("Russell L. Rader")
What's going on here? ("Dr. Unk")
Re: Linux Sound Engine (Ross Vandegrift)
Re: Linux Sound Engine (Ross Vandegrift)
Re: superformat and 2.2.0pre6 (Harald Arnesen)
Re: Dosemu breaks in 2.2.0-pre6? (Harald Arnesen)
Re: virtualizing i386-linux (Michael Brunnbauer)
Re: Linux Sound Engine (Ross Vandegrift)
Re: What's going on here? (Paul Flinders)
Re: silly question (Steve Carter)
Re: How to share memory between device driver and user space app. (Arun Sharma)
Re: What's going on here? (Mark Tranchant)
Re: silly question (Peter Samuelson)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Nathan Myers)
Subject: Re: 2.2.0pre6 booting errors
Date: 12 Jan 1999 13:22:53 -0800
Mumit Khan<[EMAIL PROTECTED]> wrote:
>Nathan Myers <[EMAIL PROTECTED]> wrote:
>>
>>Strange, I installed vanilla 5.2 on my brother's Libretto (P75/16M)
>>and then 2.2.0-pre6, and everything (except parport modules) worked.
>>With static parport everything worked. Is the only difference the
>>compiler? I built the kernel, modules, and pcmcia stuff with
>>Egcs-1.1.1.
>
>Why me??? The problem started when I installed an updated RPM for
>modutils, and then it just went downhill from there. Now my machine
>is a mess, and currently running Solaris until I can figure out
>a clean way to do this. I did have 2.0.36-3 running well in SMP
>except for one *very* annoying thing -- no matter what I tried
>(everything from RTC, xntpd, running ntpdate and rdate via cron,
>etc) the time drift was simply too far out to be usable. This is
>supposedly known problem with 2.0.x series, so I was hoping 2.2.0
>will fix it.
>
>Can you load modules using insmod w/out any trouble? If so, I'm
>going to start from scratch yet again and try that.
Yes, no problem. Note, this was an upgrade to *vanilla* 5.2,
not the patches or whatever RH calls them.
If you're willing to start over, why not install Debian Slink
instead?
--
Nathan Myers
[EMAIL PROTECTED] http://www.cantrip.org/
------------------------------
From: "Johan F. Gerlofs" <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.hardware
Subject: Re: LILO and 10 GB drives
Date: 13 Jan 1999 08:34:22 +0100
Hi,
I had a similar problem (9.1 GB disk), same error message, however LILO
stopped after "L". I found that the problem was the specification of
'linear' in lilo.conf. After removal of 'linear' and reinstallation, it
worked fine.
cheers,
-Johan.
PS.: I did not specify the disk geometry either. You may want to specify
as little as possible...
[EMAIL PROTECTED] wrote in article
<[EMAIL PROTECTED]>...
> Hello, I just got a new 10 GB drive and I can't seem to get LILO to boot
> from it. If someone knows something about LILO and large disk drives I
> would really appreciate some help. Below is the relavent info from my
> BIOS, fdisk, lilo and LILO.
>
<<snip>>
------------------------------
From: Mark Tranchant <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.misc,comp.os.linux.advocacy
Subject: Re: Linux should not support non-free modules
Date: Wed, 13 Jan 1999 08:27:43 +0000
Reply-To: [EMAIL PROTECTED]
Rex Riley wrote:
>
> MalkContent wrote:
>
> > :
> > : It's the power of a hardware giant like Intel behind UDI that provides
> > : the chance that MS will run into problems when trying to ignore it.
> > :
> >
> > [snip observations]
>
> > Are any of us willing to give up our personal tinkered systems for what may
> > one
> > day become another windoze?
> >
> > Just a thought.
> >
> > Malkcontent.
>
> It's refreshing to find a willing challenger to the MS grip on mindshare. You
> have obviously chosen to educate your mind and decide for yourself what windoze
> are right for you.
>
> And if you further the day when Linux becomes another windoze, you'll have
> participated in at least one more choice than existed.
>
> Malkcontents, afterall, founded a new nation 200+ years ago...
>
And look where it got them... ;-)
Mark.
------------------------------
From: [EMAIL PROTECTED] (Nathan Myers)
Subject: Re: 2.2p6 SMP System Hang When Running Sox
Date: 12 Jan 1999 13:35:54 -0800
Jay Munsterman <[EMAIL PROTECTED]> wrote:
>I have experienced frequent system hangs when running sox to play au
>files. I first experienced this in 2.1.131 and it still occurs with
>2.2pre6.
>
>In testing, I found that the sound card doesn't seem to make a
>difference. I recompiled the kernel with Opti card support, installed
>the Opti and had the same results. There are no IRQ, DMA or IO mem
>address conflicts with either card. Last night I recompiled without SMP
>enabled, and it was stable. I can freely recreate this problem with the
>SMP kernel, so if anyone can help, I would be happy to provide any
>details requested.
There are some known deadlocks in SMP with large mmap'd files and
swapping. See the kernel list archive,
http://www.linuxhq.com/lnxlists/linux-kernel/.
Expect a fix in pre7, maybe. There are some patches there that
you could help test out....
--
Nathan Myers
[EMAIL PROTECTED] http://www.cantrip.org/
------------------------------
From: "Russell L. Rader" <[EMAIL PROTECTED]>
Crossposted-To: alt.os.linux,comp.os.linux.development.apps,comp.os.linux.setup
Subject: Re: Why I'm dumping Linux, going back to Windblows
Date: Tue, 12 Jan 1999 17:13:59 -0500
Castelnuovo L. wrote:
> <snip>
> > : This business of congratulating yourself on having overcome a steep
> > : learning curve, just tells many us us that you are waste a lot of time
> > : (or might be a masocist). Why not just insist on sensible tools that
> > : do the best work for the job at hand.
> >
>
<snip>
> the difference is in the attitude to explore new realities.
> You can take the phone and call your vendor when you have trouble , instead
> of taking the responsability of your system, you can , we don't!
No, the difference is that some people are users and some people are
programmers/administrators/hackers. There is nothing wrong with either
viewpoint: for the user, they just want a tool to make their *real* job
easier, while for the programmer the tool *is* their job. Why should a
businessman become a programmer; it's not his job. It's my job; that's
what I get paid for. :-)
Or to use another poster's analogy: The guy who wants a new kind of
wrench to work on a car doesn't want to go to the Cincinnati Millacron
milling machine to make it, he just wants a wrench for crisakes! He's a
mechanic, not a machinist. He'd only use the milling machine once in a
blue moon, so why bother to learn it? But the machinist loves his
milling machine, and wouldn't live without it. He uses it everyday, and
in the long run learning how to use it makes his life much easier.
So if Linux doesn't make your life easier; fine, don't use it. If
Windows makes your life harder, don't use it. This thread is like
arguing over which is better: a hammer or a screwdriver. Gee, it
depends.
Russ
------------------------------
From: "Russell L. Rader" <[EMAIL PROTECTED]>
Crossposted-To: alt.os.linux,comp.os.linux.development.apps,comp.os.linux.setup
Subject: Re: Why I'm dumping Linux, going back to Windblows
Date: Tue, 12 Jan 1999 17:25:34 -0500
Roger Rabbit wrote:
>
> I agree completely, UNIX and LINUX do not have the ease of config.
> that WINXX does. <snip>
Unix and Linux ARE hard to configure correctly, it's true. I don't care
what anyone else says, I use/program/administer computers every day,
hack on 'em for a hobby, etc., and I still get confused and frustrated
sometimes. But the nice thing about Linux is it's flexibility. You can
make it do anything you want it to do, no matter how bizarre, if you
jump through the hoops. But there is no spoon-feeding. With Windows,
you can only do it if you have a spoon-feeder (read: install) program do
it for you. And God forbid if there are any conflicts or problems
during the install. With Linux, everything is hard. With Windows, the
easy things are easy, the hard things are impossible. I'd much rather
deal with Linux than try to delve into the Windows 95 registry.
Russ
------------------------------
From: "Dr. Unk" <[EMAIL PROTECTED]>
Subject: What's going on here?
Date: Wed, 13 Jan 1999 01:19:15 -0800
What's the deal here? 2.0.36 in the Stable corner, 2.1.132 in the
Development corner. Now 2.2.0 in the Development corner. Supposedly the
even number after the 1st number means it's stable. Does this mean that
2.2.0 is stable, or will it be the new stable after a million patches? As
you can see, I am totally clueless about this situation. Can I have someone
get me a drink to clear things up?
Thanks.
------------------------------
From: Ross Vandegrift <[EMAIL PROTECTED]>
Subject: Re: Linux Sound Engine
Date: Tue, 12 Jan 1999 18:27:10 -0500
Reply-To: [EMAIL PROTECTED]
Peter Steiner wrote:
>
> In article <[EMAIL PROTECTED]>, Ross Vandegrift wrote:
>
> >/dev/dsp is relinked to /dev/leaf (Linux Enhanced Audio Filter, if you
> >care).
>
> How can I create a device like that? Multiple processes are supposed to
> write to /dev/leaf at the same time while internally the audio mixer
> must handle all connections separately.
This was my big question; I wasn't sure if I could create a device file
that could be opened by multiple processes at once. Would that be
possible? Would it require ridiculous kernel modifications?
> It looks like a kind of named
> socket to me, but can this be made compatible with the original
> /dev/dsp behaviour? I'd prefer a userspace solution here.
That's what I originally thought, but my goal was to keep the exact same
interface for compatibility reasons. esd is really cool, but its
proprietary. Someone mentioned OSS supports exactly what I'm talking
about, and I'll look into that on the OSS page before I go reinventing
the wheel.
--
Ross Vandegrift | Eric J. Fenderson
alt.binaries.punk: for those of us too
punk to pay money for the music.
------------------------------
From: Ross Vandegrift <[EMAIL PROTECTED]>
Subject: Re: Linux Sound Engine
Date: Tue, 12 Jan 1999 18:28:22 -0500
Reply-To: [EMAIL PROTECTED]
Nathan Harris wrote:
>
> Are you going to have a web site dedicated to this? I might be
> interested in helping out. I would like to write a multitrack audio
> editing program, but BeOS has the coolest audio API right now.
> Something similar for Linux would be great, since I would rather do an
> open source type project under Linux.
Sure, I can put aup a web page about this, after I get some more
concrete ideas about whether it's possible as I envision it. And I
would love some help.
--
Ross Vandegrift | Eric J. Fenderson
alt.binaries.punk: for those of us too
punk to pay money for the music.
------------------------------
From: Harald Arnesen <[EMAIL PROTECTED]>
Subject: Re: superformat and 2.2.0pre6
Date: 12 Jan 1999 17:46:21 +0100
[EMAIL PROTECTED] (bill davidsen) writes:
> Note to kernel developers: superformat won't format 1680k floppies under
> 2.2.0pre6, will if I boot the 2.1.132 kernel on the same hardware. Tried
> twice (each kernel) on the same floppies.
It will, if you use /dev/fd0H1680 instead of specifying
tracks/sectors/heads.
--
Harald Arnesen, Apall�kkveien 23 A, N-0956 Oslo, Norway
------------------------------
From: Harald Arnesen <[EMAIL PROTECTED]>
Subject: Re: Dosemu breaks in 2.2.0-pre6?
Date: 12 Jan 1999 17:52:44 +0100
[EMAIL PROTECTED] (Peter S. Fales) writes:
> Anyone else having trouble with dosemu in 2.2.0-pre6? I'm using
> dosemu-0.66.7 and I pretty sure it was working up through pre5. Now
> it just hangs during the boot process with no error messages.
Try a newer dosemu. 0.99.6 works, at least.
--
Harald Arnesen, Apall�kkveien 23 A, N-0956 Oslo, Norway
------------------------------
From: Michael Brunnbauer <[EMAIL PROTECTED]>
Subject: Re: virtualizing i386-linux
Date: 12 Jan 1999 21:36:34 GMT
Steven Hand <[EMAIL PROTECTED]> wrote:
: While you may well wish to implement this from scratch, you might like
: to take a look at L4-Linux (http://os.inf.tu-dresden.de/L4/LinuxOnL4/)
thanks for the tip. this concept is similar to mine - the abstraction layer
is quite as low as in my design (i would call this a nanokernel :). But
L4-Linux is based on the older L4-microkernel and a design goal was not to
change the L4-kernel. this made initial implementation and adaption of newer
linux-kernels quite complex. L4 cannot be distributed freely any more and was
replaced by fiasco (http://os.inf.tu-dresden.de/fiasco/). fiasco can run
L4-Linux too but is alpha and slow at this time.
my concept has a very specific purpose (several kernels on a machine) and is
designed specifically for linux/i386. if it works, implementation should be
easier: search for operations that are not allowed in CPU-mode 1 on a
486 and convert them to system calls of the microkernel. this has much less
overhead (better performance) and can be adapted easier to newer kernel
versions.
anyway - L4-linux seems to be a very little step away from running multiple
kernels on one machine. perhaps other operating systems will be ported soon.
i don't know yet if i should join L4-Linux or stick to my idea.
cu,
brunni
------------------------------
From: Ross Vandegrift <[EMAIL PROTECTED]>
Subject: Re: Linux Sound Engine
Date: Tue, 12 Jan 1999 18:36:40 -0500
Reply-To: [EMAIL PROTECTED]
> on the user level side, there are a few sound daemons that already exist, that
> do some of this already. esd and nas come to mind. i took a look at writing a
> device driver that would mix incoming streams to /dev/audio to allow multiple
> program support, one of the things that stumped me was what to do with
> the existing programs that mmap /dev/audio. quake is an example of one of
> these annoying programs. I also was in a quandary as whether to move the
> sound mixing code straight into the kernel, or whether to do a /dev/audioreal
> which was the real device and have a stub of a device driver that would
> redirect input to /dev/audio to a user level program such as a slightly
> modified esd which would do the mixing itself and use /dev/audioreal. i
> mentioned doing sound mixing in the kernel to alan cox when he was at a
> localish lug meeting, and he reckoned it would be an incredible resource pig,
> but that was just an off the cuff thing, so i dont know for sure.
What happenes when you mmap() an audio device? I have never heard of
this, and can't imagine what would happen - especially since /dev/dsp is
such a neat interface. (It's almost too easy to be true) I think that
the sound mixing code should be out of the kernel - Alan is certainly
right when he says it could be a resource pig - especially if I try and
implement my "Alpha" sound idea. Not to mention, it would add a lot of
stuff that really doesn't belong in a kernel. That way, /dev/leaf would
just be an interface to the userspace mixer process, that would actually
access /dev/dsp.
> i think that the redirect to a userlevel process might be the way to go,
> maybe mmapping the device could be allowed as a special case, where the
> userlevel mixer gets suspended while another program mmaps /dev/audio, and
> only resumes when the mmaping process quits, hardly elegent but it would get
> the ball rolling anyway.
Maybe I could make a better suggestion upon knowing the effects of
mmap()ing audio devices, but why not have the userspace part of
/dev/leaf handle mmap()ing it, in the same virtual way we're talking
about faking out the rest of the programs? Would something like this be
inordinately difficult? I would think that we could mix all of the data
gotten through write() and get a single waveform. Then derive data from
mmap()ed memory. The userspace driver could keep a linked list of all
processes that have mmap()ed it, and iterate through each one and build
a second wave; then just mix that one and the write()ed one together.
At any rate, I do agree that the device file should be an interface to a
userspace program.
--
Ross Vandegrift | Eric J. Fenderson
alt.binaries.punk: for those of us too
punk to pay money for the music.
------------------------------
From: Paul Flinders <[EMAIL PROTECTED]>
Subject: Re: What's going on here?
Date: 13 Jan 1999 10:16:50 +0000
"Dr. Unk" <[EMAIL PROTECTED]> writes:
> What's the deal here? 2.0.36 in the Stable corner, 2.1.132 in the
> Development corner. Now 2.2.0 in the Development corner. Supposedly the
> even number after the 1st number means it's stable. Does this mean that
> 2.2.0 is stable, or will it be the new stable after a million patches? As
> you can see, I am totally clueless about this situation. Can I have someone
> get me a drink to clear things up?
It's probably more accurate to say that 2.<even number>.x is the "release"
version and 2.<odd number>.x is the development version. 2.2 is in a
pre-release phase at the moment, not quite development, but not quite full
release either.
After release bugs get fixed (no program is perfect and it's likely 2.2.0
will have quite a few bugs left) and a few "conservative" features get
added (such as new device drivers) - hence the incrementing minor number on
the "stable" version. 2.2.0 won't be as stable as 2.0.36 because more time
has been spent fixing the bugs in the latter and the former hasn't been run
on nearly as many systems but for the majority of people it should work
without problems.
You should note that _all_ operating system vendors release bug fixes
although some choose not to reflect it in an official version number
change. For example I could quite easily claim to be running NT 4.4 (NT 4
with service pack 4) at the moment. Linux, in being more responsive to
problems, tends to run up the minor number a little faster but that's all.
The other thing that happens when a version is released is that a new
development thread is started with a new odd number. The incrementing minor
number here just reflects how often Linus decides to package up the current
state of his version and offer it to the world. There's no guarentee that
one of these _compiles_ much less works as an OS kernel.
------------------------------
From: Steve Carter <[EMAIL PROTECTED]>
Subject: Re: silly question
Date: 13 Jan 1999 11:29:37 GMT
Evan Pedro Greenberg <[EMAIL PROTECTED]> wrote:
: Bob Taylor wrote:
:> Read some history of Unix ...
Like what? References please :) I'd be interested to get up to speed on
this.
: I believe the problem is that 2 and 3 letter mnemonics are MUCH
: faster to type than long descriptive phrases...and kernel hackers
: love speed =). But you have a good point - there's no reason the
: popular distributions shouldn't automatically add some useful
: aliases to the more common operations.
IMHO this should exist in a layer above the hacky layer. A modern
distro of linux should put you into a GUI that does everything you want
it to, and should have a big 'HELP' button that allows you to man and
apropos and tkinfo or whatever that is (still can't work that properly)
and allow the user to educate h??self about the lower levels of the OS.
The kernel insulates the Hardware from the system s/w. the system s/w
insulates the kernel from the shell and apps, the apps ... etc. So if
we have newbies they should be given their own level where you can't
break it. Give them KDE or something similar. Then you have a windoze
straight from the box, but with the advantage the windows will _never_
have :- open source! As a user gets more confident ?he can start to
hack about, first with the settings in KDE, then with the choice of wm,
then eff about with scripts, then finally pull the whole thing apart and
break the kernel!
Steve-o
--
Steve Carter [EMAIL PROTECTED] See also http://chocfest.york.ac.uk/
The opinions expressed here are not necessarily
my own, let alone those of the University of York.
------------------------------
Subject: Re: How to share memory between device driver and user space app.
From: Arun Sharma <[EMAIL PROTECTED]>
Date: Wed, 13 Jan 1999 00:26:59 GMT
"jian.zhang" <[EMAIL PROTECTED]> writes:
> Help!
> Hi, currently I am developing a device driver and one application,
> The device driver and application always exchange some data, so I want
> to share memory between driver and application? How to do this? I only
> know how to share application between two user space applications.
The application passes pointers to the shared area to the device
driver through read/write/ioctl interfaces.
-Arun
------------------------------
From: Mark Tranchant <[EMAIL PROTECTED]>
Subject: Re: What's going on here?
Date: Wed, 13 Jan 1999 11:34:48 +0000
Reply-To: [EMAIL PROTECTED]
It's not 2.2.0, it's 2.2.0-pre. 2.2.0 will be "stable".
Mark.
Dr. Unk wrote:
>
> What's the deal here? 2.0.36 in the Stable corner, 2.1.132 in the
> Development corner. Now 2.2.0 in the Development corner. Supposedly the
> even number after the 1st number means it's stable. Does this mean that
> 2.2.0 is stable, or will it be the new stable after a million patches? As
> you can see, I am totally clueless about this situation. Can I have someone
> get me a drink to clear things up?
>
> Thanks.
------------------------------
From: [EMAIL PROTECTED] (Peter Samuelson)
Subject: Re: silly question
Date: 12 Jan 1999 18:42:18 -0600
Reply-To: Peter Samuelson <[EMAIL PROTECTED]>
[Steve Carter <[EMAIL PROTECTED]>]
> It got me thinking about a graphical pipe constructor, so you can
> type in your command line at the bottom, and the shell parses it and
> draws a block diagram in another window. This prevents commands
> being issued when the quoting is wrong, for instance.
Doesn't strike me as being all that useful. I can tell by typing a
command how it will parse and what it will do. I just can't imagine
any GUI "syntax" being any clearer than what is already at the command
line.
If you *really* want to cut down on quoting mistakes, add a
font-lock-mode to your favorite shell's input facility. (For the
Emacs-impaired, this means what you type gets color-coded by context.)
Actually if I do say so myself that doesn't sound like such a bad idea
... though it would most certainly be non-trivial, since it would
involve adding an incremental parser to your input function. (Probably
for bash at least, the parser function would be implemented via a
callback from libreadline, to keep shell-specific code out of the lib.)
> You could also put in a click-and-drag interface for connecting
> pipelines, for beginner users...
IMHO, there are certain things that are easier to do with a straight
command line than with any sort of GUI. Typing command lines would
definitely be one of them. I do not see how an "equation editor", as
it were, could be either quicker, easier or less confusing than the
real thing.
--
Peter Samuelson
<sampo.creighton.edu!psamuels>
------------------------------
** 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 PROTECTED]
You can send mail to the entire list (and comp.os.linux.development.system) via:
Internet: [EMAIL PROTECTED]
Linux may be obtained via one of these FTP sites:
ftp.funet.fi pub/Linux
tsx-11.mit.edu pub/linux
sunsite.unc.edu pub/Linux
End of Linux-Development-System Digest
******************************
