Linux-Development-Sys Digest #722, Volume #7 Fri, 31 Mar 00 12:13:18 EST
Contents:
Re: System.map location (Moritz Franosch)
Re: Blocking I/O with ioctl() to network driver do not work !!! (Fausto)
Re: How to make a function memeber to be a sig. handler (Mario Klebsch)
incosistent view of threads depending on tid of same process (Patrick McManus)
Re: How to make a function memeber to be a sig. handler (Julien.Soula)
Re: RedHat 6.1 and 3Com HomeConnect PC Digital Camera (USB), anyone? (Leonard Evens)
Re: Large File Support (bill davidsen)
Re: keyboard mapping (bill davidsen)
Re: 2.3.99: what's next step? (Toby Haynes)
Re: incosistent view of threads depending on tid of same process (Kaz Kylheku)
Re: incosistent view of threads depending on tid of same process (Patrick McManus)
----------------------------------------------------------------------------
From: Moritz Franosch <[EMAIL PROTECTED]>
Subject: Re: System.map location
Date: 30 Mar 2000 18:34:24 +0200
"D. Stimits" <[EMAIL PROTECTED]> writes:
> I'm trying to find out where in the kernel it decides that it must
> read /boot/System.map, so I can create alternate locations and names.
> I'd like to boot multiple kernels without having to repoint sym links
> first.
You can call the file System.map-`uname -r` (e.g. System.map-2.2.14).
Moritz
------------------------------
From: [EMAIL PROTECTED] (Fausto)
Subject: Re: Blocking I/O with ioctl() to network driver do not work !!!
Date: Fri, 31 Mar 2000 11:55:26 GMT
On Wed, 29 Mar 2000 19:49:47 GMT, "Beno�t Cousson"
<[EMAIL PROTECTED]> wrote:
>Hi,
>
>Is it possible to implement the blocking I/O mechanism (sleep_on() &
> ... [CUT]
>Is it poosible to implement that or not???
Read the book:
"Unix Network Programming" by W.R. Stevens, Prentice Hall Editions.
Is very good.
( Dans ce libre il y a les solutions de ton probl�me ;-) )
Ciao
Fausto
------------------------------
From: [EMAIL PROTECTED] (Mario Klebsch)
Crossposted-To: comp.os.linux.development.apps
Subject: Re: How to make a function memeber to be a sig. handler
Date: Fri, 31 Mar 2000 14:47:45 +0200
"Boris Pran" <[EMAIL PROTECTED]> writes:
>I installed signal handler with sigaction and I put in sgact.sa_handler = &
>commport::get_data
>Program compiles with the warning : converting void (commport::*)(int) to
>void (*)(int) - if I do casting nothing changes...
Try to make your signal handler a static function. Or better, make it
external "C".
>If I start it everything seems OK until signal arrives when it does jump to
>my sig. handler and when it tries to assess the flag it crashes with
>Segmentation fault.
Because an argument is missing. Every C++ method (except static
methods) get the instance (this) as their first argument. I guess,
your flag is a member variable, so the access to the member is done
using the instance. The signal handler is called with the signal as
its argument, so your program uses a probably low value (most signal
number are below 32) as a pointer to the instance. This almost always
will fail with a segmentation fault.
>If I call the method from main() it does it's job and returns.
If you look at the assembler soure, your compiler produces on this
call, you will see, the instance is passed to the function.
>When I use an ordinary function as a signal handler everything works well.
Because it does not require the instance as its first argument.
73, Mario
--
Mario Klebsch [EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED] (Patrick McManus)
Subject: incosistent view of threads depending on tid of same process
Reply-To: [EMAIL PROTECTED]
Date: Fri, 31 Mar 2000 13:30:46 GMT
[I've reposted this from linux.dev.c-programming to widen it's
exposure. Apologies if you see it twice.]
I don't really know how to reconcile this.. I've got a program that
creates and kills lots of threads.. periodically one thread stays
alive that shouldn't and deadlock ensues.. so far, pretty typical. But
here's the wacky part: gdb attaching to different pid numbers sees
different sets of threads associated with the same process.. here's
the example:
> ps x | grep pts/9 | grep sampl
5856 pts/9 S 0:00 ./sample
4204 pts/9 S 0:00 ./sample
4206 pts/9 S 0:00 ./sample
4207 pts/9 S 0:00 ./sample
4208 pts/9 S 0:00 ./sample
4209 pts/9 S 0:00 ./sample
4210 pts/9 S 0:00 ./sample
4211 pts/9 S 0:00 ./sample
4212 pts/9 S 0:00 ./sample
4205 pts/9 S 0:00 ./sample
::: 5856 is the thread that should have cleaned up and gone away.. the
other 9 are persistent..
>gdb sample 5856
GNU gdb 4.17.0.11 with Linux support Copyright 1998
Free Software Foundation, Inc. GDB is free software, covered by the
GNU General Public License, and you are welcome to change it and/or
distribute copies of it under certain conditions. Type "show copying"
to see the conditions. There is absolutely no warranty for GDB. Type
"show warranty" for details. This GDB was configured as
"i386-redhat-linux"...
/dat0/deltacache/5856: No such file or directory.
Attaching to program `/dat0/deltacache/sample', Pid 5856
Reading symbols from /lib/libpthread.so.0...done.
Error while reading shared library symbols:
ptrace in stop_thread: No such process.
Reading symbols from /lib/libm.so.6...done.
Reading symbols from /lib/libc.so.6...info done.
Reading symbols from /lib/ld-linux.so.2...tdone.
Reading symbols from /lib/libnss_files.so.2...done.
0x400e9574 in __libc_write ()
(gdb) info thread
10 Thread 4212 0x400ef9ee in __select ()
9 Thread 4211 0x400651bb in __sigsuspend (set=0xbedffc88)
at ../sysdeps/unix/sysv/linux/sigsuspend.c:48
8 Thread 4210 0x400651bb in __sigsuspend (set=0xbefffc84)
at ../sysdeps/unix/sysv/linux/sigsuspend.c:48
7 Thread 4209 0x400651bb in __sigsuspend (set=0xbf1ffc80)
at ../sysdeps/unix/sysv/linux/sigsuspend.c:48
6 Thread 4208 0x400651bb in __sigsuspend (set=0xbf3ffc88)
at ../sysdeps/unix/sysv/linux/sigsuspend.c:48
5 Thread 4207 0x400d5861 in __libc_nanosleep ()
4 Thread 4206 0x400f4cf2 in __libc_accept ()
3 Thread 4204 0x400651bb in __sigsuspend (set=0xbffff514)
at ../sysdeps/unix/sysv/linux/sigsuspend.c:48
* 2 Thread 5856 0x400e9574 in __libc_write ()
1 Thread 4205 0x400ee7d0 in __poll (fds=0x80cfc90, nfds=1,
timeout=2000)
at ../sysdeps/unix/sysv/linux/poll.c:45
::: which is what you'd expect to see.. 10 threads but if we connect
gdb to a tid that wasn't supposed to die.. we see a different set of
threads.
>gdb sample 4206
GNU gdb 4.17.0.11 with Linux support
Copyright 1998 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and
you are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for
details.
This GDB was configured as "i386-redhat-linux"...
/dat0/deltacache/4206: No such file or directory.
Attaching to program `/dat0/deltacache/sample', Pid 4206
Reading symbols from /lib/libpthread.so.0...done.
Error while reading shared library symbols:
ptrace in stop_thread: No such process.
Reading symbols from /lib/libm.so.6...done.
Reading symbols from /lib/libc.so.6...info thdone.
Reading symbols from /lib/ld-linux.so.2...rdone.
Reading symbols from /lib/libnss_files.so.2...done.
0x400f4cf2 in __libc_accept ()
(gdb) info thread
9 Thread 4212 0x400ef9ee in __select ()
8 Thread 4211 0x400651bb in __sigsuspend (set=0xbedffc88)
at ../sysdeps/unix/sysv/linux/sigsuspend.c:48
7 Thread 4210 0x400651bb in __sigsuspend (set=0xbefffc84)
at ../sysdeps/unix/sysv/linux/sigsuspend.c:48
6 Thread 4209 0x400651bb in __sigsuspend (set=0xbf1ffc80)
at ../sysdeps/unix/sysv/linux/sigsuspend.c:48
5 Thread 4208 0x400651bb in __sigsuspend (set=0xbf3ffc88)
at ../sysdeps/unix/sysv/linux/sigsuspend.c:48
4 Thread 4207 0x400d5861 in __libc_nanosleep ()
3 Thread 4204 0x400651bb in __sigsuspend (set=0xbffff514)
at ../sysdeps/unix/sysv/linux/sigsuspend.c:48
* 2 Thread 4206 0x400f4cf2 in __libc_accept ()
1 Thread 4205 0x400ee7d0 in __poll (fds=0x80cfc90, nfds=1,
timeout=2000)
at ../sysdeps/unix/sysv/linux/poll.c:45
:: only 9 threads listed, it's missing the one that's supposed to
die.. but it's still there! (ps verifies..) and attaching to it
directly shows all 10..
any insights?
-P
--
Patrick R. McManus - AppliedTheory Corporation - Software Engineering
http://pat.appliedtheory.com/patrick/ Lead Developer
[EMAIL PROTECTED] 'Prince of Pollywood' Standards, today!
*** - You Kill Nostalgia, Xenophobic Fears. It's Now or Neverland. - ***
------------------------------
From: [EMAIL PROTECTED] (Julien.Soula)
Crossposted-To: comp.os.linux.development.apps
Subject: Re: How to make a function memeber to be a sig. handler
Date: 31 Mar 2000 15:42:43 +0200
"Boris Pran" <[EMAIL PROTECTED]> writes:
> I was writing a simple program in C++ to talk to serial port and everything
> was OK until I wanted to make a function member to be a signal handler for
> SIGIO.
> I installed signal handler with sigaction and I put in sgact.sa_handler = &
> commport::get_data
> Program compiles with the warning : converting void (commport::*)(int) to
> void (*)(int) - if I do casting nothing changes...
The warning make me think that the function "commport::get_data(int)"
is NOT a static member.
So the failure is normal because a member function must always be
associated with a object (it's not a stand-alone pointer function and,
in fact, the function has a implicit parameter which is the object).
I suggest you to make a real C function (or at least a static member
function) for handler which call the member function.
-- Julien
------------------------------
From: Leonard Evens <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.misc
Subject: Re: RedHat 6.1 and 3Com HomeConnect PC Digital Camera (USB), anyone?
Date: Fri, 31 Mar 2000 09:03:35 -0600
Ronald Cole wrote:
>
> Ok, on an impulse I bought the 3Com USB PC camera. I've looked for
> documentation and/or HOWTOs for connecting it to my pc running RH6.1,
> but have been unsuccessful.
>
> About the only thing I've been able to figure out is that RH6.1
> doesn't appear to support USB "out of the box".
>
> I refuse to believe that I'm going to have to wait until RedHat
> releases a linux-2.4 distribution (RH7.x?), or that I'm going to have
> to resort to Win98 and Netmeeting to get some use out of it.
>
> Can anyone who's connected a USB camera to their PC and gotten it
> working with RH6.1 offer me some pointers? Thanks!
>
> --
> Forte International, P.O. Box 1412, Ridgecrest, CA 93556-1412
> Ronald Cole <[EMAIL PROTECTED]> Phone: (760) 499-9142
> President, CEO Fax: (760) 499-9152
> My GPG fingerprint: C3AF 4BE9 BEA6 F1C2 B084 4A88 8851 E6C8 69E3 B00B
The current stable Linux kernels (2.2.X) don't support USB devices.
The latest development kernels do and the next stable kernels
(2.4.X)---which will probably be out later this year---will.
At that point the software, e.g., gphoto, for uploading from
a digital camera will have to be rewritten. I don't know how
long that will take. I also don't know if that software handles
your camera. If the camera is at all popular, someone will
undoubtedly write code for it at some point.
--
Leonard Evens [EMAIL PROTECTED] 847-491-5537
Dept. of Mathematics, Northwestern Univ., Evanston, IL 60208
------------------------------
From: [EMAIL PROTECTED] (bill davidsen)
Crossposted-To: nwu.comp.unix.linux,comp.os.linux.misc
Subject: Re: Large File Support
Date: 31 Mar 2000 15:51:16 GMT
In article <8c1mjp$bmq$[EMAIL PROTECTED]>,
Marc SCHAEFER <[EMAIL PROTECTED]> wrote:
| In comp.os.linux.development.system David E Allen <[EMAIL PROTECTED]> wrote:
| : I am also interested in large file support. Actually, I don't need the support
| : for ext2 itself, but for writing to a raw device (9Gb scsi disk). The open(2)
| : and, more importantly, lseek(2) commands do not seem to support offsets
| : larger than 31 bits (2Gb). Any ideas? Thanks.
|
| llseek() exists, it allows to do very large seeks on raw devices. Now,
| on the filesystem side, until 2.3.x you won't be able to do it, and you
| also need a recent libc.
Let me try to clarify this is bit. The problem appears not to be with
ext2, but with the VM model of the kernel over which it lies. In other
words, the kernel can't treat >2GB as memory. Friends are running ext2
on ALPHA and say that large files are not a problem.
In 2.3 the VM has been changed, and also the physical memory support.
In any case large files seem to be okay in 2.3, or at least as okay as
small files.
There are also a slew of new filesystems. This is their status AFAIK,
don't take it as gospel, because I'm NOT on the mailing lists.
Reiser beta
ext3 beta
xfs devel (SGI)
jfs devel (IBM)
Other than jfs, I can't say a lot about these, but there is one thing
you must know about journaling f/s in general, as the number of inode
changes goes up, performance goes down. That's file creates and deletes,
and permission changes. On some f/s access time changes are also put in
the journal, which can really hurt performance. See -noatime...
When I was running news in traditional storage mode on AIX (JFS f/s),
I had my journal on solid state disk, and got 2-3x improvement in
performance of certain operations.
Feel free to correct or clarify if I'm behind the times or over
simplified something.
--
bill davidsen <[EMAIL PROTECTED]> CTO, TMR Associates, Inc
"Doing interesting things with little computers since 1979"(tm)
The hardest test of maturity is knowing the difference between
resisting temptation and missing a once-in-a-lifetime opportunity.
------------------------------
From: [EMAIL PROTECTED] (bill davidsen)
Subject: Re: keyboard mapping
Date: 31 Mar 2000 15:56:16 GMT
In article <8c1nf5$1blg$[EMAIL PROTECTED]>,
Franck Yu <[EMAIL PROTECTED]> wrote:
| I am having a problem with an Informix application running on RedHat Linux
| V6.1. The program written in Informix 4GL is expected to convert each strike
| of the key "." at keypad into an ",", because I use French locale for which
| the numeric decimal separator is "," instead of ".". I put questions in
| Informix newsgroups without right answers, finally I think to change the
| keyboard mapping at the operating system level, but I don't know where I
| should start, what I should do. I have to recompile some keyboard files,
| right? Any idea is greatly appreciated!
Sure, see "loadkeys" man page. That is how you load the keymap. The
"see also" section points to the command which saves the current keymap.
There's a program which returns scan codes when you press a key, so you
know which one to hack, although you can just look for the "." in this
case.
I highly suggest remapping the "." on the numeric keypad rather than
the main keyboard. I'm sure you thought of that already, not being able
to end a sentence would be inconvenient ;-)
--
bill davidsen <[EMAIL PROTECTED]> CTO, TMR Associates, Inc
"Doing interesting things with little computers since 1979"(tm)
The hardest test of maturity is knowing the difference between
resisting temptation and missing a once-in-a-lifetime opportunity.
------------------------------
From: Toby Haynes <[EMAIL PROTECTED]>
Subject: Re: 2.3.99: what's next step?
Date: 31 Mar 2000 11:19:21 -0500
!! "bill" == bill davidsen <[EMAIL PROTECTED]> writes:
bill> Linux has perhaps the best development team around, but but
bill> they do code stuff without doing design first, and they not
bill> only don't do QA before letting out code, they rejected an
bill> offer to have a group do it when a new release was ready. I
bill> tried, not going to try again.
Well - if this is an itch you wish to scratch, set up a site which
does QA on the latest available kernel and posts the latest set of
known problems, conflicts, things which work well, things which work
badly. Without having an ear to the door of the kernel releases, much
of the Bazaar philosophy relies on getting code releases out in the
open to flush out problems, rather than holding back each kernel
release till every last problem is fixed. This is particularly true on
the 2.<odd number>.x kernel releases - they may not even compile on
every system.
However, just because the code is available for all to see does not
invalidate the QA process. Because the Linux kernels are developed out
in the open, QA is a continual process rather than one that happens
(mainly) late in the development cycle. That said, I think that as the
wind-up to the 2.4.x kernel series begins, you can expect some fairly
careful examination of the latest known problems in the 2.3.99+
kernels before we see 2.4.0. So, to recap, just because the code is in
the open doesn't mean that any attempts to do QA on the released code
is necessarily a bad thing - in fact if you make a good QA site for
the latest releases it would probably prove to be a popular site with
people chasing the latest kernel revisions.
Cheers,
Toby Haynes
--
Toby Haynes
The views and opinions expressed in this message are my own, and do
not necessarily reflect those of IBM Canada.
------------------------------
From: [EMAIL PROTECTED] (Kaz Kylheku)
Subject: Re: incosistent view of threads depending on tid of same process
Reply-To: [EMAIL PROTECTED]
Date: Fri, 31 Mar 2000 16:29:47 GMT
On Fri, 31 Mar 2000 13:30:46 GMT, Patrick McManus <[EMAIL PROTECTED]>
wrote:
>[I've reposted this from linux.dev.c-programming to widen it's
>exposure. Apologies if you see it twice.]
If you absolutely must post the same thing to multiple groups, you should
consider crossposting instead. That way people with smart newsreaders won't see
it twice; furthermore, the article is reduced to a single instance.
>:: only 9 threads listed, it's missing the one that's supposed to
>die.. but it's still there! (ps verifies..) and attaching to it
>directly shows all 10..
>
>any insights?
Maybe that thread which is supposed to die has already been
removed from the thread manager's list.
------------------------------
From: [EMAIL PROTECTED] (Patrick McManus)
Subject: Re: incosistent view of threads depending on tid of same process
Reply-To: [EMAIL PROTECTED]
Date: Fri, 31 Mar 2000 16:59:35 GMT
On Fri, 31 Mar 2000 16:29:47 GMT, Kaz Kylheku wrote:
>On Fri, 31 Mar 2000 13:30:46 GMT, Patrick McManus <[EMAIL PROTECTED]>
>wrote:
>>[I've reposted this from linux.dev.c-programming to widen it's
>>exposure. Apologies if you see it twice.]
>
>If you absolutely must post the same thing to multiple groups, you should
>consider crossposting instead. That way people with smart newsreaders won't see
>it twice; furthermore, the article is reduced to a single instance.
ahem, while I appreciate the attitude, the action in question was one
of 'appending' the newsgroups after a time lapse.. not one of not
knowing how news protocols work. (i.e. deciding at a *later time* to
broaden the scope after a narrow start didn't spread it far
enough).. optimal implementation of that would be to be able to modify
an existing message-id to include more newsgroups so only folks who
haven't yet seen it now do (and the universe is broadened), but you
can't do that.. there are a couple of options available (cancelling
the first, crossposting the second or just adding a second in a new
group) they've both got their pros and cons.
>
>>:: only 9 threads listed, it's missing the one that's supposed to
>>die.. but it's still there! (ps verifies..) and attaching to it
>>directly shows all 10..
>>
>>any insights?
>
>Maybe that thread which is supposed to die has already been
>removed from the thread manager's list.
the problem is difficult to articulate.. let me try it this way:
I can attach to two different process numbers (which are all different
threads of the same process) with gdb and say "info thread" and I get
two different views of what threads comprise the process.. indeed the
threads missing from some views of the threads-in-the-process are ones
I would expect to be dead.. but they aren't zombied (and indeed are
detached threads)..
--
Patrick R. McManus - AppliedTheory Corporation - Software Engineering
http://pat.appliedtheory.com/patrick/ Lead Developer
[EMAIL PROTECTED] 'Prince of Pollywood' Standards, today!
*** - You Kill Nostalgia, Xenophobic Fears. It's Now or Neverland. - ***
------------------------------
** 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
******************************
