Linux-Development-Sys Digest #815, Volume #6 Fri, 11 Jun 99 01:15:12 EDT
Contents:
Segmentation fault in file execution (Kong Tae Young)
Re: Any Journaling FS development? (Frank Sweetser)
Re: new kernel: LILO "kernel too big" error ([EMAIL PROTECTED])
Re: MMX & SMP HOWTO? ("F.J. Lingen")
Re: /etc/inittab suggestion for all distributions (Abdullah Ramazanoglu)
Can I upgrade a RedHat 4.x box to a 2.2.9 kernel - problem free? (Troy A. Parvatton)
Re: RedHat and trends (Christopher B. Browne)
Re: Configuration Manager for Linux (Christopher B. Browne)
Re: Video 4 Linux API info? ([EMAIL PROTECTED])
Re: pThreads and STL in RedHat 6.0 (Allen Curtis)
Re: Configuration Manager for Linux (Leslie Mikesell)
Problems with Soundblaster 64 PCI (ES1370) (Andres Heinloo)
----------------------------------------------------------------------------
From: Kong Tae Young <[EMAIL PROTECTED]>
Subject: Segmentation fault in file execution
Date: Fri, 11 Jun 1999 10:48:00 +0900
==============D4490DCDEAEC620A1663AFDC
Content-Type: text/plain; charset=EUC-KR
Content-Transfer-Encoding: 7bit
I just installed RedHat 6.0 Korean distribution, and compiled my
project.
The code that generated segmantation fault and core dump doesn't do that
anymore.
At that code my program stops with controlling terminal.
I tried this three line program only for test
... main...
{
char *name = "";
printf("test is %s", name[5]);
}
Above code didn't cause segmentation fault , it just stopped with
controlling terminal(when executed as a foreground job)
0 byte core file was generated after killing cotrolling terminal.
Is it just installation problem or normal situation which
need some configuration?
I don't have any idea what went wrong?
My kernel version is 2.2.9
--
===========================
Kong Tae Young
Dep of Computer Engineering
Dong-A Univ, South Korea
[EMAIL PROTECTED]
============================
==============D4490DCDEAEC620A1663AFDC
Content-Type: text/html; charset=EUC-KR
Content-Transfer-Encoding: 7bit
<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
I just installed RedHat 6.0 Korean distribution, and compiled my project.
<p>The code that generated segmantation fault and core dump doesn't do
that anymore.
<br>At that code my program stops with controlling terminal.
<p>I tried this three line program only for test
<br>... main...
<br>{
<br>char *name = "";
<br>printf("test is %s", name[5]);
<br>}
<p>Above code didn't cause segmentation fault , it just stopped with controlling
terminal(when executed as a foreground job)
<p>0 byte core file was generated after killing cotrolling terminal.
<pre>Is it just installation problem or normal situation which</pre>
<pre>need some configuration?</pre>
<pre>I don't have any idea what went wrong?</pre>
<pre>My kernel version is 2.2.9</pre>
<pre>--</pre>
<pre>
===========================
Kong Tae Young
Dep of Computer Engineering
Dong-A Univ, South Korea
[EMAIL PROTECTED]
============================</pre>
</html>
==============D4490DCDEAEC620A1663AFDC==
------------------------------
From: Frank Sweetser <[EMAIL PROTECTED]>
Subject: Re: Any Journaling FS development?
Date: 10 Jun 1999 22:46:11 -0400
[EMAIL PROTECTED] writes:
> In article <[EMAIL PROTECTED]>,
> Frank Sweetser <[EMAIL PROTECTED]> wrote:
> >[EMAIL PROTECTED] writes:
>
> >no idea... you'd have to ask him.
>
> That's intimidating... If we had to ask linus for kernel
> code or alan for network code, or becker for ethernet code,
> where would we be? My point in asking the question is that
well, when i was having trouble with my 3c509, i *did* ask don becker for
some help - he replyed the next day, saying "okay, i think i see the
problem, check this configuration bit, try this patch, and let me know if
it helps." likewise, the few times i've had reason to email other such
people, i've gotten a response reasonably quickly - ie, within a day or
two.
> searching for information on this project, other than
> this redhat employee is "working on it", has turned up little.
> Saying that somebody is working on something, even though that
> somebody has many other responsibilities, might cause someone
> else not to work on a similar project. It's been this way for
> quite a while, to the contrary of "release early, release often."
> Of course you will probably tell me again, ask Stephen...
yup =)
> >they need to make sure that they don't release any bits of code they're not
> >allowed to.
>
> Okay. So all the solutions are tba at some unspecified future time,
> if at all. We have several rock-solid kernels (I'm thinking DU, BSD, and
> Linux), but we just don't have the good tuned filesystems yet. The
> people who may or may not be working on such a thing are not giving
> the community much to work with here. If Stephen has anything at all,
> he should let the world in on it. If he has nothing, he should work
> to dispel the myth that there will be anything like a jfs coming anything
> like soon, and maybe more people will take an interest in something like
> dtfs, which at least isn't vaporware.
>
> Excuse me for ranting, but I think it was about this time last year,
> same story, Tweedie is working on it...
if you ask him nicely, i'm sure he'll let you look at what he's got. i
know that he held off on submitting it 'cause he didn't even want to start
thinking about integrating it until 2.3 was underway.
developing a good journaling filesystem is indeed hard, takes time, and i
doubt too many people have the knowledge and experience to do it, which
probably is slowing things down even more.
--
Frank Sweetser rasmusin at wpi.edu fsweetser at blee.net | PGP key available
paramount.ind.wpi.edu RedHat 5.2 kernel 2.2.5 i586 | at public servers
I figure if i can't make a difference, I can at least make a mess!
- joeski
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: new kernel: LILO "kernel too big" error
Date: Thu, 10 Jun 1999 14:32:53 GMT
steve davidson <[EMAIL PROTECTED]> wrote:
: Saved lilo.conf, ran lilo -v: Still get the error "kernel /boot/newkernelz
: is too big".
Run "make bzImage"
Jeff
------------------------------
From: "F.J. Lingen" <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.app
Subject: Re: MMX & SMP HOWTO?
Date: Thu, 10 Jun 1999 15:44:41 +0200
Allen Curtis wrote:
> Hello there, I am in the process of implementing an imaging library in
> Linux. Can anyone point me to a HOWTO or something which explains what
> needs to be done to support MMX properly in Linux. Are there any special
> considerations for SMP and MMX?
Linux Journal #61, May 1999, has an article about MMX programming
in Linux: "An Overview of Intel's MMX Technology" by Ariel Ortiz Ramirez.
Erik Jan Lingen
------------------------------
From: Abdullah Ramazanoglu <[EMAIL PROTECTED]>
Subject: Re: /etc/inittab suggestion for all distributions
Date: Thu, 10 Jun 1999 20:42:07 +0300
Alan Curry wrote:
>
> Here's a better suggestion. Don't run X in continuous-respawn mode.
>
> Use xdm without any servers in the Xservers file. Then start the server with
> X -indirect localhost. If it goes bad you can ctrl-alt-backspace it and it
> doesn't come back.
>
It may be trivial for you. But new users are using the system as it is
shipped. If a solution doesn't come with the distribution, newcomers are
most likely affected.
Regards,
--
Abdullah Ramazanoglu ( aramazanoglu AT demirbank DOT com DOT tr )
------------------------------
From: [EMAIL PROTECTED] (Troy A. Parvatton)
Subject: Can I upgrade a RedHat 4.x box to a 2.2.9 kernel - problem free?
Date: Thu, 10 Jun 1999 14:56:30 GMT
Can RedHat 4.x boxes running 2.0.x kernels be upgraded to 2.2.9 - just
like that - with no problems? I already upgraded the kernel on one
box and nothing, as yet, as broken. I doubt it's really as easy as
that.
Well, after scanning the posts in this group I came across some URLs
that point to some upgrade guides. You don't have to tell me twice
that those should be read. I'm on it now, but having said that if any
of you can answer my, above, question I would appreciate it.
Regards,
Troy.
------------------------------
From: [EMAIL PROTECTED] (Christopher B. Browne)
Crossposted-To: comp.os.linux.advocacy
Subject: Re: RedHat and trends
Reply-To: [EMAIL PROTECTED]
Date: Fri, 11 Jun 1999 03:46:05 GMT
On 10 Jun 1999 17:33:51 GMT, Donovan Rebbechi <[EMAIL PROTECTED]>
posted:
>On Thu, 10 Jun 1999 05:58:06 GMT, Christopher Browne wrote:
>
>>It is "morally questionable" if they push *themselves* as the
>>standard, as opposed to pushing the use of normative standards.
>
>Yes, but they don't appear to be resisting "normative standards" such as
>LSB. AFAICT, LSB is dying, not due to Redhat's resistance to it, but
>of neglect.
Yes, but it's obviously more exciting to come up with X-Files-style
conspiracy theories. Far better for starting flame wars :-).
My suspicion is that the *real* work of this must really be associated
with the relevant components.
- If LIBC actively follows the relevant standards for C9X,
UNIX-whatever-year, and whatever POSIX committees are sitting,
THAT is what gets LIBC to converge towards a form of standardness.
- Ditto for the Linux kernel, and UNIX 99, and appropriate POSIX
standards.
- If the Debian folk establish utilities to verify that packages
conform to FSSND/FSD/whatever-today's-initials are, that can be
followed by others to help convergence in that area.
- If work goes on to get COAS and Linuxconf to be more useful with
various distributions, that helps the respective distributions to
converge in functionality.
- Who knows? The TOG group that has had involvement with LSB may come out
with suitable scripts to allow some degree of LSB validation to be done.
It seems to me that the only way to get LSB to happen is to establish
automated tools to help validate correctness. Nobody wants to go and
verify by hand that Red Hat 6.1 conforms, and then have to start all
over again as soon as they find the first security bug and have to update
6 packages.
--
Those who do not understand Unix are condemned to reinvent it, poorly.
-- Henry Spencer <http://www.hex.net/~cbbrowne/lsf.html>
[EMAIL PROTECTED] - "What have you contributed to free software today?..."
------------------------------
From: [EMAIL PROTECTED] (Christopher B. Browne)
Subject: Re: Configuration Manager for Linux
Reply-To: [EMAIL PROTECTED]
Date: Fri, 11 Jun 1999 04:25:54 GMT
On 10 Jun 1999 21:24:37 -0500, Jonathan Abbey <[EMAIL PROTECTED]> posted:
>In article <NBY73.3912$[EMAIL PROTECTED]>,
>Christopher Browne <[EMAIL PROTECTED]> wrote:
>|
>| Agreed.
>|
>| I keep wondering why everyone has the need to continually recreate these
>| wheels.
>|
>| - I am aware of about 40 distinct SQL DBMS implementations that are
>| claimed to run on Linux.
>|
>| - There are about 5 DBM variants.
>|
>| - Nearly a dozen CORBA implementations.
>|
>| - Probably half a dozen LDAP access schemes.
>
>Eep. Just got through reading through Christopher Browne's excellent
>database guide pages. Given all the stuff listed, I can understand
>why the decision to produce software using YADB would raise eyebrows.
Eep is right.
>Nonetheless, the reasons I listed for not using an SQL/LDAP directory
>database still hold, especially given the time frame (i.e., before
>JDBC) in which Ganymede implementation began. Ditto the decision to
>use RMI rather than CORBA.
It's obviously easy to criticize based on today's situation rather
than on looking at what was available at the time.
It would nonetheless be a sly idea to add in some CORBA hooks,
perhaps publishing the IDL equivalent to whatever RMI is providing.
(I must confess unfamiliarity with RMI.)
>Were I to start implementing Ganymede today I guess I might try to
>take advantage of some existing database (PostgreSQL?), but even then
>making software of this type dependent on someone else's product does
>introduce significant risks.
Every piece of GNOME seems to be dependent on every other piece, which
means a mad race towards some semblance of stability, not always with
perfect success. If they succeed in building anything anywhere near
as ambitious as the plans originally intended, it may be regarded
as an impressive accomplishment against fairly significant odds.
>The only other software that I'm familiar with that has attempted to
>fill the same ecological niche as Ganymede, UNameIt! by ESM, was built
>using UniSQL. Unfortunately, the company that produced UniSQL dropped
>the product, and ESM was left with the responsibility of maintaining
>the UniSQL code base for the working life of their product.
>
>They chose instead to drop the product and leave the software business
>entirely in favor of consulting.
Fair enough; I certainly agree that establishing dependancies on
outside parties that can't *forcibly* be trusted represents a
significant danger.
I was the last programmer working at MCI some years ago who know anything
about the (obscure, only ever understood by ~20 people) "NAG" application
framework; happily, it had a *severe* Y2K problem, and thus users of
applications were actively moving to new platforms when I changed jobs
and countries... (From Toronto to Fort Worth.)
>Ganymede's database won't compare to a whole lot of the databases on
>cbbrowne's database survey pages, but it does compare favorably to
>many of them, and the ways in which it is strong or weak in comparison
>to the others fits with the ways in which Ganymede will be used,
>hopefully. I would also plead that Ganymede is as much a distributed
>application as it is a database per se, and that the programmability
>of the server is where its value really comes from.
I wouldn't forcibly propose that Ganymede *HAS* to use an SQL DBMS;
not every application needs that.
It is somewhat appalling when similar things are gratuitously duplicated.
Just for contrast, I *don't* regard GNOME and KDE as being gratuitous
duplications. They have quite different architectures, take different
approaches, and there is value in having multiple projects as this permits
the respective developers to take greater risks without risking complete
disaster for "all Linux users." Supposing either project "crashes and
burns," there can still be useful reusable results.
The thought I *would* suggest is to consider whether it would be
practical to reverse-engineer an ORB or some such thing in to provide
an alternative interface to RMI. This means that if RMI should prove
to become a dead end, there's still a way for the system to remain
reusable.
Contrast that with recent discussions about "XBasic," a system looking
a lot like a "Visual BASIC." It has the fairly serious defect at this
point that it is extremely processor-specific; it generates IA-32 code,
and transforming that to support other architectures is liable to prove
challenging. If IA-64 "takes off," and other 64 bit architectures help
crowd out IA-32 over the next 5 years, XBasic may very well wind up on
the scrap pile due to inadequate flexibility.
--
Those who do not understand Unix are condemned to reinvent it, poorly.
-- Henry Spencer <http://www.hex.net/~cbbrowne/lsf.html>
[EMAIL PROTECTED] - "What have you contributed to free software today?..."
------------------------------
From: [EMAIL PROTECTED]
Crossposted-To: comp.os.linux.development.app
Subject: Re: Video 4 Linux API info?
Date: Thu, 10 Jun 1999 12:29:23 GMT
Check out the link below.. Bill Dirks maintains a very good site on V4L.
http://millennium.diads.com/bdirks/
jeff akgul-
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> Where can I find the development information pertaining to
Video2Linux?
>
>
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: Allen Curtis <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Crossposted-To: comp.os.linux.development.app
Subject: Re: pThreads and STL in RedHat 6.0
Date: Thu, 10 Jun 1999 21:24:50 -0700
This is a multi-part message in MIME format.
==============51B1098564E65B4B7BAF80F5
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
I get the following message when I try to build the program. I have also
attached the files for your viewing pleasure.
cc -D_REENTRANT qtest.cc -o qtest -lpthread
/tmp/cchIKQsj.o: In function `__malloc_alloc_template<0>::oom_malloc(unsigned
int)':
/tmp/cchIKQsj.o(.__malloc_alloc_template<0>::gnu.linkonce.t.oom_malloc(unsigned
int)+0x17): undefined reference to `endl(ostream &)'
/tmp/cchIKQsj.o(.__malloc_alloc_template<0>::gnu.linkonce.t.oom_malloc(unsigned
int)+0x21): undefined reference to `cerr'
/tmp/cchIKQsj.o(.__malloc_alloc_template<0>::gnu.linkonce.t.oom_malloc(unsigned
int)+0x26): undefined reference to `ostream::operator<<(char const *)'
/tmp/cchIKQsj.o(.__malloc_alloc_template<0>::gnu.linkonce.t.oom_malloc(unsigned
int)+0x31): undefined reference to `ostream::operator<<(ostream &(*)(ostream
&))
collect2: ld returned 1 exit status
make: *** [qtest] Error 1
Juergen Heinzl wrote:
> In article <[EMAIL PROTECTED]>, Allen Curtis wrote:
> >I have glibc version 2.1.1-6 and do not seem to be able to link a
> >program that uses both pThreads and STL. I know that has worked before.
> >Can anyone tell me what the secret is to doing this?
>
> g++ -pthread source.C does it fine here ... what is it complaining about (no
> RH or other distribution but 2.1.1 too).
>
> Ta'
> Juergen
>
> --
> \ Real name : J�rgen Heinzl \ no flames /
> \ EMail Private : [EMAIL PROTECTED] \ send money instead /
==============51B1098564E65B4B7BAF80F5
Content-Type: text/plain; charset=us-ascii;
name="qtest.cc"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
filename="qtest.cc"
#include <queue>
#include <iostream.h>
#include <pthread.h>
queue<int> Q;
pthread_t c_thread;
pthread_t p_thread;
void*
consumer(void* arg)
{
}
void*
producer(void* arg)
{
}
int main() {
Q.push(8);
Q.push(7);
Q.push(6);
Q.push(2);
assert(Q.size() == 4);
assert(Q.back() == 2);
assert(Q.front() == 8);
Q.pop();
assert(Q.front() == 7);
Q.pop();
assert(Q.front() == 6);
Q.pop();
assert(Q.front() == 2);
Q.pop();
assert(Q.empty());
pthread_create(&c_thread, NULL, consumer, 0);
pthread_create(&p_thread, NULL, producer, 0);
void* retval;
// pthread_join(c_thread, &retval);
// pthread_join(p_thread, &retval);
}
==============51B1098564E65B4B7BAF80F5
Content-Type: text/plain; charset=us-ascii;
name="makefile"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
filename="makefile"
#
# -D_REENTRANT is required for pThreads
#
all: test1 test2 examples threadqueue qtest
test1: test1.cc
test2: test2.cc
qtest: qtest.cc
$(CC) $(CFLAGS) -D_REENTRANT qtest.cc -o qtest -lpthread
examples: examples.cc
threadqueue: threadqueue.cc
$(CC) $(CFLAGS) -D_REENTRANT threadqueue.cc -o threadqueue -lpthread
==============51B1098564E65B4B7BAF80F5==
------------------------------
From: [EMAIL PROTECTED] (Leslie Mikesell)
Subject: Re: Configuration Manager for Linux
Date: 10 Jun 1999 23:09:56 -0500
In article <7jps15$[EMAIL PROTECTED]>,
Jonathan Abbey <[EMAIL PROTECTED]> wrote:
>Were I to start implementing Ganymede today I guess I might try to
>take advantage of some existing database (PostgreSQL?), but even then
>making software of this type dependent on someone else's product does
>introduce significant risks.
That is somewhat understandable, but if you look at exactly this
issue from anyone else's perspective but your own you will understand
why we are leary of trusting our system management to some product
that has much less real-world use than (say) PostgreSQL. My
experience is that all complex software packages have subtle bugs
that are not uncovered until it is used in a large number of
different settings. I already know what to expect from PostgreSQL
and it has a fairly large regression test that is part of the
distribution and run on many platforms after all revisions.
>The only other software that I'm familiar with that has attempted to
>fill the same ecological niche as Ganymede, UNameIt! by ESM, was built
>using UniSQL. Unfortunately, the company that produced UniSQL dropped
>the product, and ESM was left with the responsibility of maintaining
>the UniSQL code base for the working life of their product.
Postgresql was designed to be extensible and was originally an
object-oriented design that later had the sql interface imposed.
It originally kept a complete history of all records and you
could do 'time travel' to query against the state of the database
at some earlier time. That is not the native mode any more but
you can still emulate it if you want. If it has a weakness, it
is that it doesn't replicate itself across multiple servers and
doesn't keep its traction log on an alternate drive, but it does
at least have a transaction-safe dump for backup.
>Ganymede's database won't compare to a whole lot of the databases on
>cbbrowne's database survey pages, but it does compare favorably to
>many of them, and the ways in which it is strong or weak in comparison
>to the others fits with the ways in which Ganymede will be used,
>hopefully. I would also plead that Ganymede is as much a distributed
>application as it is a database per se, and that the programmability
>of the server is where its value really comes from.
Sure, but that is the case with all databases. I agree that there
are some special needs with regard to security that might have
required some modifications to postgresql or other existing
databases, but the added value would be that the programmability
of the database fits into the scheme of other things you are
likely to already be doing instead of being something else to
learn.
Oh well... If the database has to be a new entity, I'd feel a lot
better about it if it could perform at least one of the jobs
natively, and I'm least happy with LDAP at the moment. Is there
any chance that the Ganymede backend could be taught to answer
LDAP queries? Or more ambitiously, graft in the samba NT domain
controller emulation also so password changes from Win95 can
take effect and propagate into the other places they need to be known.
Les Mikesell
[EMAIL PROTECTED]
------------------------------
From: Andres Heinloo <[EMAIL PROTECTED]>
Crossposted-To: linux.dev.sound
Subject: Problems with Soundblaster 64 PCI (ES1370)
Date: Thu, 10 Jun 1999 18:12:01 +0300
Hi!
I just bought a soundcard and spent whole night trying to add sound
support to Linux. Unfortunately without much success.
First I compiled kernel 2.2.9 with a driver for "Ensoniq ES1370 based PCI
sound cards". The driver successfully recognizes the device, but no devices
show up in /dev/sndstat (all sections are empty). I had a quick look at the
driver source and it seemed to me that only drivers originated from OSS
supported that device, so I didn't consider it a problem. Moreover, I was
able to play CD through soundcard and control the volume with mixer, and I
was able to play xboing with sound.
When I tried to do "cat /dev/audio", my problems started. First time I got
kernel oops, subsequent tries just made the whole system hang. It was the
same with "cat /dev/dsp". When I tried to play an mp3 file with x11amp, the
system hanged also.
Next I tried kernel 2.2.1, but the results were exactly the same. I
compiled the sound drivers both into kernel and as modules. No difference.
Then I downloaded ALSA 0.3.1 drivers. ALSA has a module for Ensoniq
AudioPCI ES1370/1371 PCI soundcards, which specifically claims to support
SoundBlaster PCI 64 and SoundBlaster PCI 128. Unfortunately I wasn't able
to get the driver to recognize the device. The driver didn't gave any
messages even when configured with "--with-debug=full" (lsmod showed that
all modules were successfully loaded). I thought that maybe ALSA driver has
to be explicitly enabled with a user-lever utility. I compiled ALSA
user-level library and utilities, and I tried the "alsasound" shell script
included in the package without any success. I tested ALSA both under the
kernel 2.0.36 and 2.1.9. No difference.
Now I'm completely without any clue.
If someone of you have succeeded to get the above card working under Linux
or have any idea how to fix the problem, I'd very appreciate your
suggestions.
Thanks in advance!
Andres.
------------------------------
** 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
******************************
