Linux-Development-Sys Digest #51, Volume #8 Fri, 28 Jul 00 14:13:13 EDT
Contents:
Re: Async IO in Linux... ([EMAIL PROTECTED])
Re: Setting Serial-Port Status lines (Peter Pointner)
Re: Reproducable crashing linux-2.2.16 (Martin Kahlert)
Re: Reproducable crashing linux-2.2.16 (Kaz Kylheku)
Re: Tracing fork system calls. (Mario Klebsch)
Re: device names ([EMAIL PROTECTED])
Re: 2.4.0-test5pre4 module problems? (Chiara Trentalancia)
Re: 2.4.0-test5pre4 module problems? (Chiara Trentalancia)
Checking Memory Usage (Tony Thompson)
Re: Reproducable crashing linux-2.2.16 (Martin Kahlert)
Re: test (Johan Kullstam)
Re: Intel OR840 Hang (Tor Arntsen)
Raw device question ([EMAIL PROTECTED])
Re: Tracing fork system calls. (Kaz Kylheku)
exec*() and argv[0] (Andrew Kuchling)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Async IO in Linux...
Date: Fri, 28 Jul 2000 03:38:25 GMT
Although I use KAIO(SGI implementation of posix AIO on linux), I got the
same SIGSEGV(11) from using lio_listio with NULL segevent pointer.
However, even after I used following two lines to give a real segvent
pointer, the program still got SIGSEGV.
aiocb_t *myaiocb[max_num_aios];
for (k = 0; k < max_num_aios; k++)
{
myaiocb[k] = (aiocb_t* const)malloc(sizeof(aiocb_t));
...
}
struct sigevent dummy;
dummy.sigev_notify=SIGEV_NONE;
if (lio_listio(LIO_WAIT, myaiocb, max_num_aios, &dummy) < 0)
any suggestion?
Ming Lei
In article <[EMAIL PROTECTED]>,
Andreas Jaeger <[EMAIL PROTECTED]> wrote:
> >>>>> Kevin Beard writes:
>
> > The glibc version is 2.1.3. Here's there complete program as an
attachment.
> > Ignore the AIX stuff in it.
>
> I've forwarded the program with a comment to the other glibc
> developers and CC'ed you. This looks like a bug in glibc, the sig
> argument is NULL in your case and therefore glibc segfaults. As a
> quick hack, add a proper sig argument to lio_listio.
>
> Andreas
> --
> Andreas Jaeger
> SuSE Labs [EMAIL PROTECTED]
> private [EMAIL PROTECTED]
>
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Peter Pointner <[EMAIL PROTECTED]>
Subject: Re: Setting Serial-Port Status lines
Date: 28 Jul 2000 07:10:10 +0200
Robert Resch <[EMAIL PROTECTED]> wrote:
> Hi!
> I'm searching for a way to set the Status-Lines on the Linux
> Serial-Ports. for example DTR from Low to High or from High to Low to
> drive a LED which is showing me a status of the machine.
There is a nice little utility called setserialbits. On my SuSE 6.3
it is part of sysvinit and located in sbin. It seems to be intended
to help how to communicate with simple UPSs. No man page, just call
it without parameters to get help.
I'm sure somebody else will tell you how to do it from C code.
Greetings from Neuperlach S�d
Peter
------------------------------
From: [EMAIL PROTECTED] (Martin Kahlert)
Subject: Re: Reproducable crashing linux-2.2.16
Date: 28 Jul 2000 06:03:23 GMT
Reply-To: [EMAIL PROTECTED]
In article <8lpv43$jaf$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (bill davidsen) writes:
> Sounds as if you have played with the stack size limit, alloca should
> happily fail unless you do. And you need to be root to up the limit, and
> you need memory overcommit on I believe, etc. In other words, it
> shouldn't do much on a properly configured machine, and it shouldn't
> crash in any case, but it will get really slow as it pages.
>
> Should be able to just ^C out.
Thanks for your reply.
I fully agree with you, but
1. I use tcsh on a SuSE system. no limits set for stack size in /etc/csh.*
- i changed that after the crash. Now i only get a SegFault.
2. I think that overcommitment is evil! C says, that if malloc and
friends give you a valid pointer, you can happily use the memory
chunk. That's not true with overcommitment, since you can produce
a segfault by just using the correctly malloced area.
When the system isn't able to give you 1G of memory it should
tell you exactly that by giving you 0
and it should not hope that you are darn enough to not use it fully.
If i write malloc(1G) i will use 1G, and not only its first k.
It's C, not Fortran 77, where this behaviour was quite common!
Bye,
Martin.
--
The early bird gets the worm. If you want something else for
breakfast, get up later.
------------------------------
From: [EMAIL PROTECTED] (Kaz Kylheku)
Subject: Re: Reproducable crashing linux-2.2.16
Reply-To: [EMAIL PROTECTED]
Date: Fri, 28 Jul 2000 07:23:14 GMT
On 28 Jul 2000 06:03:23 GMT, Martin Kahlert
<[EMAIL PROTECTED]> wrote:
>In article <8lpv43$jaf$[EMAIL PROTECTED]>,
> [EMAIL PROTECTED] (bill davidsen) writes:
>> Sounds as if you have played with the stack size limit, alloca should
>> happily fail unless you do. And you need to be root to up the limit, and
>> you need memory overcommit on I believe, etc. In other words, it
>> shouldn't do much on a properly configured machine, and it shouldn't
>> crash in any case, but it will get really slow as it pages.
>>
>> Should be able to just ^C out.
>Thanks for your reply.
>I fully agree with you, but
>1. I use tcsh on a SuSE system. no limits set for stack size in /etc/csh.*
> - i changed that after the crash. Now i only get a SegFault.
>2. I think that overcommitment is evil! C says, that if malloc and
> friends give you a valid pointer, you can happily use the memory
> chunk. That's not true with overcommitment, since you can produce
> a segfault by just using the correctly malloced area.
In Linux you are okay if you initialize the memory. It won't give you more
memory in a single allocation than what can be backed by the remaining amount
of virtual memory. But because it won't commit it, if you leave it
uninitialized, you can get into debt with multiple such requests.
I agree with you about overcommitment; in general, it's ridiculous nonsense
that violates the semantics of the standard allocator functions.
> When the system isn't able to give you 1G of memory it should
> tell you exactly that by giving you 0
It will yied 0, if you attempt a single request for 1G. However if you do, say
eight requests of 128 megs, and you have at least 128 megs of VM left, it will
grant you all eight, provided you don't initialize the memory. Or so I have
determined experimentally on 2.2 kernels.
It's not hard to write a wrapper around malloc which touches a byte of every
page, forcing a fault. Still, that is not a 100% solution by any measure since
it is open to a race against other processes.
--
Any hyperlinks appearing in this article were inserted by the unscrupulous
operators of a Usenet-to-web gateway, without obtaining the proper permission
of the author, who does not endorse any of the linked-to products or services.
------------------------------
From: [EMAIL PROTECTED] (Mario Klebsch)
Crossposted-To: alt.os.linux
Subject: Re: Tracing fork system calls.
Date: Fri, 28 Jul 2000 11:15:43 +0200
Tim Muir <[EMAIL PROTECTED]> writes:
I am sorry, I have no help for you. strace is suffering the same
problem as you have.
>Does anyone know how I can cause all children of an attached process to be
>automatically attached ( I know this would break things like strace
IMHO, it would fix strace()s -f option. :-)
73, Mario
--
Mario Klebsch [EMAIL PROTECTED]
PGP-Key available at http://www.klebsch.de/public.key
Fingerprint DSS: EE7C DBCC D9C8 5DC1 D4DB 1483 30CE 9FB2 A047 9CE0
Diffie-Hellman: D447 4ED6 8A10 2C65 C5E5 8B98 9464 53FF 9382 F518
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: device names
Date: Fri, 28 Jul 2000 10:20:16 GMT
In article <8l9bm6$6ej$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> I am trying to relate the disk I/O in /proc/stat with a device name.
> How can I match that data with the devices?
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.
>
I have the following information:
df -k
outputs the device names /dev/sda1 and filesystem /
/dev/sda5 and filesystem /usr
/dev/sdb1 and filesystem /home
/proc/stat
outputs:
disk 31000 900 51000 0
disk_rio 16000 800 51000 0
disk_wio 15000 15 0 0
disk_rblk 32000 1784 103728 0
disk_wblk 30000 90 0 0
How can I tell what the information for 'disk' is pointing to?
Thanks in advance,
bborn
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Chiara Trentalancia <[EMAIL PROTECTED]>
Subject: Re: 2.4.0-test5pre4 module problems?
Date: Fri, 28 Jul 2000 03:49:39 +0200
Robert Lynch ha scritto:
> Guido Trentalancia wrote:
> >
> > Steve Udell wrote:
> > >
> > > Hiya, I compiled 2.4.0-test5 yesterday only to have to go
> > > back to 2.4.0-test2 because of a bunch of modules failing.
> > > With example:
> > >
> > > depmod: *** Unresolved symbols in /lib/modules/2.4.0-test5/block/loop.o
> > > depmod: fget
> > > depmod: *** Unresolved symbols in /lib/modules/2.4.0-test5/misc/bttv.o
> > > depmod: remove_wait_queue
> > > depmod: add_wait_queue
> > > depmod: *** Unresolved symbols in /lib/modules/2.4.0-test5/misc/tdfx.o
> > > depmod: remove_wait_queue
> > > depmod: add_wait_queue
> > > depmod: *** Unresolved symbols in /lib/modules/2.4.0-test5/usb/audio.o
> > > depmod: remove_wait_queue
> > > depmod: add_wait_queue
> > >
> > > a bunch of em, but not all my modules has that problem,
> > > I didn't do anything different that I know of building
> > > my kernel than I usually do, anyone seen this? or know
> > > how to correct?
> > >
> > > --
> > > GNU/Linux Debian
> > > Steve Udell <[EMAIL PROTECTED]>
> > >
> >
> > all test5 prereleases are giving the same problem to me...
> > i'm using modutils-2.3.12...
>
> I tried test5-pre4 and found this module problem, but test5-pre1 is
> running OK for me (with plenty of modules in use.)
>
> HTH. Bob L.
> --
> Robert Lynch-Berkeley CA [EMAIL PROTECTED]
also test5-pre6 is causing the same problems to me...
------------------------------
From: Chiara Trentalancia <[EMAIL PROTECTED]>
Subject: Re: 2.4.0-test5pre4 module problems?
Date: Fri, 28 Jul 2000 03:50:36 +0200
Robert Lynch ha scritto:
> Guido Trentalancia wrote:
> >
> > Steve Udell wrote:
> > >
> > > Hiya, I compiled 2.4.0-test5 yesterday only to have to go
> > > back to 2.4.0-test2 because of a bunch of modules failing.
> > > With example:
> > >
> > > depmod: *** Unresolved symbols in /lib/modules/2.4.0-test5/block/loop.o
> > > depmod: fget
> > > depmod: *** Unresolved symbols in /lib/modules/2.4.0-test5/misc/bttv.o
> > > depmod: remove_wait_queue
> > > depmod: add_wait_queue
> > > depmod: *** Unresolved symbols in /lib/modules/2.4.0-test5/misc/tdfx.o
> > > depmod: remove_wait_queue
> > > depmod: add_wait_queue
> > > depmod: *** Unresolved symbols in /lib/modules/2.4.0-test5/usb/audio.o
> > > depmod: remove_wait_queue
> > > depmod: add_wait_queue
> > >
> > > a bunch of em, but not all my modules has that problem,
> > > I didn't do anything different that I know of building
> > > my kernel than I usually do, anyone seen this? or know
> > > how to correct?
> > >
> > > --
> > > GNU/Linux Debian
> > > Steve Udell <[EMAIL PROTECTED]>
> > >
> >
> > all test5 prereleases are giving the same problem to me...
> > i'm using modutils-2.3.12...
>
> I tried test5-pre4 and found this module problem, but test5-pre1 is
> running OK for me (with plenty of modules in use.)
>
> HTH. Bob L.
> --
> Robert Lynch-Berkeley CA [EMAIL PROTECTED]
also test5-pre6 is causing the same problems to me...
------------------------------
From: Tony Thompson <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps
Subject: Checking Memory Usage
Date: Fri, 28 Jul 2000 07:07:48 -0600
Hello -
I need to monitor the memory usage on a certain function for an app I'm
working on. I've tried using the getrusage function but it returns all
0's.
Any idea what the best way to do this would be?
Thanks in advance,
Tony Thompson
------------------------------
From: [EMAIL PROTECTED] (Martin Kahlert)
Subject: Re: Reproducable crashing linux-2.2.16
Date: 28 Jul 2000 13:33:22 GMT
Reply-To: [EMAIL PROTECTED]
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Kaz Kylheku) writes:
> In Linux you are okay if you initialize the memory. It won't give you more
> memory in a single allocation than what can be backed by the remaining amount
> of virtual memory. But because it won't commit it, if you leave it
> uninitialized, you can get into debt with multiple such requests.
Thanks for this clarification - i didn't know that!
I will ever touch my memory from now on to protect me against this
misfeature.
Bye,
Martin.
--
The early bird gets the worm. If you want something else for
breakfast, get up later.
------------------------------
From: Johan Kullstam <[EMAIL PROTECTED]>
Subject: Re: test
Date: 28 Jul 2000 09:34:26 -0400
[EMAIL PROTECTED] (phil hunt) writes:
> On 27 Jul 2000 13:30:29 -0400, Johan Kullstam <[EMAIL PROTECTED]> wrote:
> >
> >please ignore. i don't have alt.test and my nntp server has been
> >giving grief.
>
> Try comp.test instead. Or uk.test. Or many other *.test newsgroups.
i did try comp.test. unfortunately i don't have access to that
either. sigh. your indulgence is appreciated.
i am posting through a company newsserver. they don't have much and
they don't maintain it well. it's a low priority for the IT staff.
--
J o h a n K u l l s t a m
[[EMAIL PROTECTED]]
sysengr
------------------------------
From: [EMAIL PROTECTED] (Tor Arntsen)
Subject: Re: Intel OR840 Hang
Date: Fri, 28 Jul 2000 14:20:43 GMT
Eric Kasten <[EMAIL PROTECTED]> writes:
>Hi,
>
>Has anyone managed to get linux to boot on an Intel OR840 motherboard.
>This is a dual processor (PIII) with dual bus RDRAM. More info
>can be found at: http://developer.intel.com/design/wrkstn/OR840/index.htm
>
>Using either a 2.2.16 kernel or a 2.4.0-test4 kernel, the boot will
>hang while "Probing PCI hardware". If you disable PCI support
>entirely in the linux kernel build, than it doesn't hang.
>(not very useful without the PCI bus, but it doesn't hang). I've also
>tried direct vs BIOS access using the 2.2.16 kernel -- still no go
>either way. Compiled the kernels both with and without SMP support
>-- didn't help.
[...]
I have a motherboard like that (128MB RDRAM, 2x800MHz PIII).
I do not see the PCI problems you describe. I've booted Debian
kernels 2.0.36, 2.0.38, 2.2.x plus self-compiled 2.2.17pre13 and
none of them had any problems with the PCI bus.
However, I have other problems with it. It either hangs or dies
shortly after I access the disk. I have an Adaptec 29160 PCI SCSI
controller with a 18GB Quantum Atlas SCSI disk and an IDE CDROM plus
Matrox G400 dual-head graphics board.
If the SCSI controller is configured to acess the Quantum disk in
synch mode (80MB/sec) then it just hangs as soon as it acesses it,
if asynch mode it kind of works but dies after a short while (it
even powered itself down once). The controller worked fine in a
Dell machine so I'm a bit stuck at the moment.
-Tor
------------------------------
From: [EMAIL PROTECTED]
Subject: Raw device question
Date: Fri, 28 Jul 2000 16:53:44 GMT
Hi all
I am attempting to integrate support for raw devices into our
application, and have a question.
I executed the following steps on my RH 6.1 system:
mknod /dev/raw c 162 0
mknod /dev/raw1 c 162 1
raw /dev/raw1 /dev/sdb1
raw -q /dev/raw1
/dev/raw1: bound to major 8, minor 17
I determined the raw major number from the /proc/devices file.
Indeed, I have been able to read data from /dev/raw1. Now the
question...
How can I programatically do what the 'raw' program does..namely
to determine to which block device a raw device is mapped?
I wrote a program that stats /dev/raw1. But the stat struct reports that
st_dev is 8,7 and the st_rdev is 162,1. I would have thought the st_dev
should indicate 8,17.
I did an strace of the raw -q /dev/raw1 and saw:
open("/dev/raw", O_RDWR) = 3
stat("/dev/raw1", {st_mode=S_IFCHR|0664, st_rdev=makedev(162, 1), ...})
= 0
ioctl(3, 0xac01, 0xbfffe88c) = 0
SYS_197(0x1, 0xbfffe0c4, 0x4010cd60, 0x4010a980, 0x1) = -1 ENOSYS
(Function not implemented)
fstat(1, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 0), ...}) = 0
mmap(0, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x40015000
ioctl(1, TCGETS, {B38400 opost isig icanon echo ...}) = 0
write(1, "/dev/raw1:\tbound to major 8, min"..., 38/dev/raw1: bound to
major 8, minor 17
The ioctl(3,0xac01...) looks suggestive to me. But I can't determine
what that ioctl function is.
Any input is welcome
Ed Friedman
Sybase
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (Kaz Kylheku)
Crossposted-To: alt.os.linux
Subject: Re: Tracing fork system calls.
Reply-To: [EMAIL PROTECTED]
Date: Fri, 28 Jul 2000 17:28:41 GMT
On Fri, 28 Jul 2000 11:15:43 +0200, Mario Klebsch <[EMAIL PROTECTED]> wrote:
>Tim Muir <[EMAIL PROTECTED]> writes:
>
>I am sorry, I have no help for you. strace is suffering the same
>problem as you have.
>
>>Does anyone know how I can cause all children of an attached process to be
>>automatically attached ( I know this would break things like strace
>
>IMHO, it would fix strace()s -f option. :-)
For tracing Linux threads, however, there is a workaround thanks to the
debugging support in LinuxThreads. When a threaded process-collection is being
debugged, a global flag is set in it which causes new threads to synchronize
with the debugger, so that no part of their execution is missed. The debugger
walks the thread-related data structures in the process to find the threads.
I'm thinking of adding support for this to strace if it's not in a late version
already; it's frustrating not being able to use it to trace the execution of
threads.
--
Any hyperlinks appearing in this article were inserted by the unscrupulous
operators of a Usenet-to-web gateway, without obtaining the proper permission
of the author, who does not endorse any of the linked-to products or services.
------------------------------
Subject: exec*() and argv[0]
From: Andrew Kuchling <[EMAIL PROTECTED]>
Date: 28 Jul 2000 13:36:39 -0400
Someone I work with just noticed a minor oddity in the exec()
function's treatment of argv[0] in the 2.2 kernel. When you run a
script starting with #!, argv[0] is set to only the program name, not
the full path. For example, if you have #!/www/python/bin/python,
argv[0] is set to just "python", which we found caused Python to fall
back to looking along the path for its libraries, and finding the
wrong version (we have Python installed in a non-standard place).
I'll pursue fixing Python to handle this.
But... why does Linux do this? Tracing through fs/binfmt_script.c,
the code goes out of its way to do this, finding the last / in the
interpreter path and using the remainder as argv[0].
The Linux man page for execve(2) says POSIX does not document the #!
behaviour, and says nothing about the value of argv[0]. The
corresponding Solaris man page says "The pathname specified in the
interpreter file is passed as arg0 to the interpreter," which is at
least clear; no mention of an applicable standard is made. FreeBSD,
at least judging by the man page, does something else entirely,
leaving argv[0] as the path of the original script.
The patch to change this behaviour is simple; it takes one line. But
is this a bug that should be fixed?
--amk
------------------------------
** 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
******************************
