Linux-Development-Sys Digest #84, Volume #8 Thu, 17 Aug 00 16:13:11 EDT
Contents:
Re: far pointers in g++ (Johan Kullstam)
Re: Deep TCP / RAW IP socket questions (Andi Kleen)
Re: soft-realtime system with standard linux (not RT-Linux)? ("Dmitriy A.
Fedorov")
write() and atomicity ([EMAIL PROTECTED])
Re: soft-realtime system with standard linux (not RT-Linux)? ("Dmitriy A.
Fedorov")
How can I know kernel has received interrupt from ISA card and execute interrupt
service routine? ("Chun Seong Ng")
Re: Adding a system call dynamically (Marco van de Voort)
Re: Circumventing TIME_WAIT...howto? (Rick Ellis)
colour map (Gee)
Re: Circumventing TIME_WAIT...howto? (Robert Colbert)
Re: Pb with function msgrcv() (Bruno Rivara)
Re: How can I know kernel has received interrupt from ISA card and execute interrupt
service routine? (Kaz Kylheku)
Re: Circumventing TIME_WAIT...howto? (Kaz Kylheku)
Re: write() and atomicity (Kaz Kylheku)
Re: debugging/profiling multithreaded (pthread) applications on RedHat 6.x?
(Szabolcs Csetey)
Re: debugging/profiling multithreaded (pthread) applications on RedHat 6.x? (Kaz
Kylheku)
Re: Kernel 2.4.0-test6 Compile and install module problem? (John Gluck)
----------------------------------------------------------------------------
Subject: Re: far pointers in g++
From: Johan Kullstam <[EMAIL PROTECTED]>
Date: 17 Aug 2000 08:26:01 -0400
David Lamparter <[EMAIL PROTECTED]> writes:
> Hi!
>
> Does anybody know how to code far pointers in g++ / c++ / another c++ under
> Linux? I tried many variants but it don't want to go...
far pointers suck. buy a real 64 bit cpu.
> I don't want to use
> assembler. It's too _low_ for me.
if you only need a couple of these type pointers, then doing a little
assembly hacking seems perfectly ok. just make a couple of
subroutines to talk to this beast.
--
J o h a n K u l l s t a m
[[EMAIL PROTECTED]]
sysengr
------------------------------
From: Andi Kleen <[EMAIL PROTECTED]>
Subject: Re: Deep TCP / RAW IP socket questions
Date: 17 Aug 2000 15:43:39 +0200
"Dave Rhodes" <[EMAIL PROTECTED]> writes:
> Hi folks-
>
> I have done my best to try to find this information, but couldn't. Here are
> two socket programming questions that I have:
>
> 1) I can't seem to get a SOCK_RAW socket with IPPROTO_TCP to connect with a
> SOCK_STREAM socket, even though I am prepared to do the TCP handshake
> manually on the raw side. What might be preventing this from working?
The problem is that kernel TCP sees the packets going to your raw socket too,
and will usually interfere, sending RSTs or creating its own connections.
One way to prevent this is to use a packet socket (not raw socket) and
create a firewall rule for the port/address pair of the connection on the fly.
This works because the packet sockets sits below the IP firewall machinery,
and TCP sits above it.
>
> 2) Is there anyway to get the SEQ and ACK_SEQ numbers from the TCP level? I
> would have thought that this would be a getsockopt() type thing but only
> found MAXSEG, NODELAY and CORK settings (in the include files). Would
> another way to do this be to Divert the IP level and inspect the packet?
Only sniffing.
In theory it would be possible to fish it out of /dev/kmem, but that is fraught
with many unsolvable race conditions and would be very kernel version specific
too (don't do it)
-Andi
------------------------------
From: "Dmitriy A. Fedorov" <[EMAIL PROTECTED]>
Subject: Re: soft-realtime system with standard linux (not RT-Linux)?
Date: Thu, 17 Aug 2000 14:06:09 +0000
wolfgang guldner wrote:
> I have got a question concerning how to realize a soft-realtime system
> with standard linux (not RT-Linux).
> While normally the delay time (time between sending of message to a FIFO and
> receiving it) is short enough (about 5 msecs) accidentally it goes ** up to
> 200msecs ** which is too long.
man sched_setscheduler,
use SCHED_RR or SCHED_FIFO [soft] real time scheduling policies,
use mlockall(MCL_FUTURE)
------------------------------
From: [EMAIL PROTECTED]
Subject: write() and atomicity
Date: Thu, 17 Aug 2000 14:11:55 GMT
For a long time I was under the impression that the posix write()
function is ensured to be atomic no matter what the descriptor
represents ( regular file, socket, pipe etc. ).
Recently I came across the limit _POSIX_PIPE_BUF whose definition is
the maximum buffer size for a wtite() to a pipe so that atomicity is
assured.
Now my question is, are there similar limits for sockets, fifo s unix
domain sockets etc. If yes does this limit vary depending on the
protocol used for a socket.
Any help will be greatly appreciated.
Thanks a lot for reading.
Sony
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: "Dmitriy A. Fedorov" <[EMAIL PROTECTED]>
Subject: Re: soft-realtime system with standard linux (not RT-Linux)?
Date: Thu, 17 Aug 2000 14:22:06 +0000
Dmitriy A. Fedorov wrote:
>
> wolfgang guldner wrote:
>
> > I have got a question concerning how to realize a soft-realtime system
> > with standard linux (not RT-Linux).
>
> > While normally the delay time (time between sending of message to a FIFO and
> > receiving it) is short enough (about 5 msecs) accidentally it goes ** up to
> > 200msecs ** which is too long.
>
> man sched_setscheduler,
> use SCHED_RR or SCHED_FIFO [soft] real time scheduling policies,
> use mlockall(MCL_FUTURE)
mlockall( MCL_FUTURE | MCL_CURRENT )
------------------------------
From: "Chun Seong Ng" <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps,linux.dev.kernel
Subject: How can I know kernel has received interrupt from ISA card and execute
interrupt service routine?
Date: Thu, 17 Aug 2000 15:54:32 +0100
Hi, everybody. I've problem to execute interrupt service routine when
interrupt occurred. I've installed interrupt in kernel by using int_module
function and /proc/interrupts shown the interrupt was installed.
I've also developed a user program to read and write CAN (Controller Area
Network) ISA card registers. The registers on the card shown it did receive
signal from external device and sent interrupt to PC. But my module do not
execute the service routine when interrupt occurred.
My questions are:
1) How to activate the interupt function? Do I need to use enable_irq() to
enable the interrupt? How can I know the kernel has received interrupt from
the card?
2) How to call up user program from interrupt service routine? The user
program just doing read and write function to registers on the ISA card.
The module is simple, it just install and uninstall the interrupt and carry
out interrupt service routine when interrupt come in. When installing and
uninstalling the module, the screen do display the statement set in the
module. That means print_string function properly.
The following is program codes for interrupt module:
#define __KERNEL__
#define MODULE
/* The necessary header files */
/* Standard in kernel modules */
#include <linux/kernel.h> /* We're doing kernel work */
#include <linux/sched.h>
#include <linux/module.h> /* Specifically, a module */
/* Necessary here */
#include <linux/tty.h> /* For the tty declarations */
#define INTRPT 10 /* Set IRQ 10 */
/* Print the string to the appropriate tty (console terminal), the one
* the current task uses */
void print_string(char *str)
{
struct tty_struct *my_tty;
/* The tty for the current task */
my_tty = current->tty;
/* If my_tty is NULL, it means that the current task
* has no tty you can print to (this is possible, for
* example, if it's a daemon). In this case, there's
* nothing we can do. */
if (my_tty != NULL) {
(*(my_tty->driver).write)(
my_tty, /* The tty itself */
0, /* We don't take the string from user space */
str, /* String */
strlen(str)); /* Length */
(*(my_tty->driver).write)(
my_tty,
0,
"\015\012",
2);
}
}
/* CAN_handler interrupt service routine */
void CAN_handler(int irq, void *dev_id, struct pt_regs *regs)
{
print_string(" CAN_handler has been successfully executed!!\n ");
}
/* Initialize the module */
int init_module()
{
free_irq(INTRPT, NULL);
request_irq(INTRPT, CAN_handler, SA_INTERRUPT, "CANB_ISA", NULL);
print_string("CAN IRQ 10 has been assigned by Linux kernel\n");
/* If we return a non zero value, it means that
* init_module failed and the kernel module
* can't be loaded */
return 0;
}
/* Cleanup - undid whatever init_module did */
void cleanup_module()
{
free_irq(INTRPT, NULL);
print_string("Unassigned IRQ successfully\n");
print_string("Good bye to CanLab\n");
}
------------------------------
From: [EMAIL PROTECTED] (Marco van de Voort)
Subject: Re: Adding a system call dynamically
Date: 17 Aug 2000 15:50:34 GMT
In article <8ng73v$gc2$[EMAIL PROTECTED]>, Marc SCHAEFER wrote:
>Kasper Dupont <[EMAIL PROTECTED]> wrote:
>: posibility to have. For some purposes a /proc interface might
>: be ineffective or even imposible.
>
>Another way is to register a new dynamic misc module (with a minor
>in the reserved range), and to add a few ioctl()s.
>
>This will be even portable between kernel revisions (I have such
>modules running in 2.0.x and 2.2.x, with just a minor differences
>in e.g. release()).
Interesting technique. Do you happen to have some code for download
somewhere?
thanks in advance.
------------------------------
From: [EMAIL PROTECTED] (Rick Ellis)
Subject: Re: Circumventing TIME_WAIT...howto?
Date: 17 Aug 2000 16:21:06 GMT
In article <[EMAIL PROTECTED]>,
Robert Colbert <[EMAIL PROTECTED]> wrote:
>In essence, is there any "proper" way to get around this TIME_WAIT state
>in a socket without a kernel hack? This is not for an application that
>is for public distribution. We're working on a very specific, in-house
>test tool and I need to be able to get sockets available again fast.
>Waiting for them to die out of the TIME_WAIT state severely limits our
>ability to do what we're trying to do.
Sounds like you should be using UDP if you think your network is so
reliable.
--
http://www.fnet.net/~ellis/photo/linux.html
------------------------------
From: Gee <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps
Subject: colour map
Date: Thu, 17 Aug 2000 12:42:39 -0400
Hi, I'm trying to allocate some custom colours into the colour map,
using the BX command XParseColor() but it's not letting me.
does anyone know if linux allows you to insert custom colours??
thanks
Gee
------------------------------
From: Robert Colbert <[EMAIL PROTECTED]>
Subject: Re: Circumventing TIME_WAIT...howto?
Date: Thu, 17 Aug 2000 09:58:43 -0700
Rick:
I do use UDP, for control traffic to control this testbed of 96 PCs. UDP,
however, does not test what we need tested (S/SA/A/P/A/P/A/FA/FA/A
sequences) at 200,000 sessions per second. So, at this point, I've got a
rack of 96 PCs running Red Hat 6.2 that burst out 3,000 sessions per second
each then sleep for nearly two minutes while the "client" machines are
waiting to be able to create another socket...having their entire socket
table filled with TIME_WAIT dead weight. I don't care about the memory
considerations...each PC has 256MB of physical RAM with a 4GB hard drive.
Memory is not the issue. Sustained session rates are the issue.
So, given that our full-duplex, switched, routed dual-VLAN internal,
isolated 12 Gigabit network of 96 PCs and a few controller PCs does not drop
packets and no packet takes longer than about 2ms to reach its destination,
yep, I'm very positive that I don't need a two-minute TIME_WAIT clog in this
environment. And, UDP doesn't do "session" traffic (or even use the right
protocol for what we're testing).
I do have a packet-level socket test written to generate the basic
TCP session by hand by generating what appear to be TCP frames at a rate of
about 80,000 frames per second; but I wanted to use actual OS sockets to
provide a more robust TCP stack than the one I pieced together by hand on
top of said packet-level socket to test basic session setup and teardown.
I intend to use the hand-rolled code that puts frames on the wire manually
at the NIC level for negative testing (broken CRCs, malformed TCP options,
etc.). But, I need Linux's industry-standard stack for other tests and I
need it to sustain around 3,000 sessions per second per PC over a long
(days) period of time.
Thanks,
Rob Colbert ([EMAIL PROTECTED])
Rick Ellis wrote:
> In article <[EMAIL PROTECTED]>,
> Robert Colbert <[EMAIL PROTECTED]> wrote:
>
> >In essence, is there any "proper" way to get around this TIME_WAIT state
> >in a socket without a kernel hack? This is not for an application that
> >is for public distribution. We're working on a very specific, in-house
> >test tool and I need to be able to get sockets available again fast.
> >Waiting for them to die out of the TIME_WAIT state severely limits our
> >ability to do what we're trying to do.
>
> Sounds like you should be using UDP if you think your network is so
> reliable.
>
> --
> http://www.fnet.net/~ellis/photo/linux.html
------------------------------
From: Bruno Rivara <[EMAIL PROTECTED]>
Subject: Re: Pb with function msgrcv()
Date: Thu, 17 Aug 2000 19:10:35 +0200
Christophe Leroy wrote:
>
> Hi,
>
> I've got a problem with msgrcv() function:
> sometimes it returns -1, but errno=0
> Does anybody have an idea about what can happen to get such a result ?
Signal handlers that do not save/restore errno?
Ciao
Bruno
------------------------------
From: [EMAIL PROTECTED] (Kaz Kylheku)
Crossposted-To: comp.os.linux.development.apps,linux.dev.kernel
Subject: Re: How can I know kernel has received interrupt from ISA card and execute
interrupt service routine?
Reply-To: [EMAIL PROTECTED]
Date: Thu, 17 Aug 2000 17:26:48 GMT
On Thu, 17 Aug 2000 15:54:32 +0100, Chun Seong Ng <[EMAIL PROTECTED]> wrote:
>Hi, everybody. I've problem to execute interrupt service routine when
>interrupt occurred. I've installed interrupt in kernel by using int_module
>function and /proc/interrupts shown the interrupt was installed.
>
>I've also developed a user program to read and write CAN (Controller Area
>Network) ISA card registers. The registers on the card shown it did receive
>signal from external device and sent interrupt to PC. But my module do not
>execute the service routine when interrupt occurred.
>
>My questions are:
>1) How to activate the interupt function? Do I need to use enable_irq() to
>enable the interrupt? How can I know the kernel has received interrupt from
>the card?
>2) How to call up user program from interrupt service routine? The user
>program just doing read and write function to registers on the ISA card.
You can't execute user code in the context of an interrupt routine. The best
you can do int the service routine is record that the event happened, and
unblock any processes that may be waiting for that event.
>/* Print the string to the appropriate tty (console terminal), the one
>* the current task uses */
>void print_string(char *str)
You should probably just be using printk() to send messages to the logging
subsystem. The printk() function can be safely used for printing debug messages
at interrupt time. Do not reinvent your own debug logging function.
>/* CAN_handler interrupt service routine */
>void CAN_handler(int irq, void *dev_id, struct pt_regs *regs)
>{
> print_string(" CAN_handler has been successfully executed!!\n ");
>}
What about telling the hardware?
--
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] (Kaz Kylheku)
Subject: Re: Circumventing TIME_WAIT...howto?
Reply-To: [EMAIL PROTECTED]
Date: Thu, 17 Aug 2000 18:05:07 GMT
On Thu, 17 Aug 2000 02:43:22 -0700, Robert Colbert <[EMAIL PROTECTED]> wrote:
>In essence, is there any "proper" way to get around this TIME_WAIT state
>in a socket without a kernel hack?
One way is to have the clients disconnect gracefully from the server.
The TIME_WAIT occurs on the side which initiates the closure.
You find that if you are testing a client server application, the
TIME_WAIT problem occurs when you abruptly terminate the server without
disconnecting the clients first.
Take a look at the TCP state transition diagram. Note that if you leage
the ESTABLISHED state by receiving a FIN (the other end is closing), the
connection goes straight to the state CLOSE_WAIT, in which it waits
for the application to complete the close. Then it sends a FIN and waits
for the last ACK in the LAST_ACK state. This scenario is called passive
close, and does not involve the TIME_WAIT state.
See if you can design your application to take advantage of passive close
in order to avoid the TIME_WAIT.
The SO_REUSEADDR option can also be used to circumvent TIME_WAIT in some TCP
implementations. This allows a process to bind to the local port that is in the
TIME_WAIT state.
--
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] (Kaz Kylheku)
Subject: Re: write() and atomicity
Reply-To: [EMAIL PROTECTED]
Date: Thu, 17 Aug 2000 18:12:30 GMT
On Thu, 17 Aug 2000 14:11:55 GMT, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>For a long time I was under the impression that the posix write()
>function is ensured to be atomic no matter what the descriptor
>represents ( regular file, socket, pipe etc. ).
No!
>Now my question is, are there similar limits for sockets, fifo s unix
>domain sockets etc. If yes does this limit vary depending on the
>protocol used for a socket.
Data sent to a stream socket is chopped up into packets. When multiple threads
send data to the same socket, these packets will be interleaved arbitrarily.
Moreover, you never know where a packet boundary will land. Even if you make a
write() that is smaller than the datagram size, it may be divided into two,
because part of it will be coalesced with previously queued data and part of it
will go to a new packet because the previous one is full. Thus you can never
rely on the other end being able to gather the data in one read()
operation---except perhaps for the very first message that is sent on the
socket, provided it is smaller than the device MTU minus protocol overhead.
But even that would be considered a kludge.
--
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: Szabolcs Csetey <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps
Subject: Re: debugging/profiling multithreaded (pthread) applications on RedHat 6.x?
Date: Thu, 17 Aug 2000 19:19:08 GMT
In article <8n7t18$v6a$[EMAIL PROTECTED]>,
"Marty Fouts" <[EMAIL PROTECTED]> wrote:
> We seem to have a lot of tool related problems, such as the version of
gdb
> 4.18 we build with gcc 2.95.2 core dumping in ways that the 4.18
that's
> included in the RH distribution don't.
RH distributed gdb has extra patches. You can take a look at/apply them
after doing rpm -i gdb-*.src.rpm. The files will be in the
/usr/src/redhat/SOURCES directory.
> Also, what about tools for profiling multithreaded aps? We've found
Tau and
> are trying to use it. Is there anything else?
AFAIK gprof doesn't support multithreaded apps profiling, but you can
workaround it if you call getitimer() in the main thread for ITIMER_PROF
then using that value in a call to setitimer() in every thread you
spawn. Other alternative is using the open source cprof by Corel [I
never had the chance to try it out yet]:
http://opensource.corel.com/cprof.html
Please also note coredumping multithreaded apps in 2.2 kernels aren't
reliable [should be ok in 2.4] - the kernel dumps just one thread and
usually not the one that really crashed. Workaround is if you run it
from gdb or apply this one-liner patch:
http://www.cs.helsinki.fi/linux/linux-kernel/2000-11/0896.html
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (Kaz Kylheku)
Crossposted-To: comp.os.linux.development.apps
Subject: Re: debugging/profiling multithreaded (pthread) applications on RedHat 6.x?
Reply-To: [EMAIL PROTECTED]
Date: Thu, 17 Aug 2000 19:56:57 GMT
On Thu, 17 Aug 2000 19:19:08 GMT, Szabolcs Csetey <[EMAIL PROTECTED]> wrote:
>> Also, what about tools for profiling multithreaded aps? We've found
>Tau and
>> are trying to use it. Is there anything else?
>
>AFAIK gprof doesn't support multithreaded apps profiling, but you can
>workaround it if you call getitimer() in the main thread for ITIMER_PROF
>then using that value in a call to setitimer() in every thread you
>spawn. Other alternative is using the open source cprof by Corel [I
>never had the chance to try it out yet]:
Profiling in Linux is not based on the profiling alarm timer. It is based on
a special profiling system call. You give it a buffer which represents a scaled
histogram over an area of your virtual address space. The kernel then racks up
counters within that histogram. When your process is interrupted by a clock
tick, the kernel notes what address it was executing and maps it into that
histogram and then bumps a counter. Or something like that!
(Of course, profiling also depends on the generation of the call graph
information and counting the number of times functions are executed. That
is done in user space.)
Now in glibc 2.0 it was possible to call moncontrol(1) from a thread to turn
on profiling for that thread. Due to a mistake in a glibc 2.1 Version,
the moncontrol is unfortunately unavailable for linkage. I believe that
this is fixed in 2.2 so it should be possible to do multithreaded profiling.
To be one the safe side, I would only turn it on in one thread of interest
at a time.
The mcount function is not exactly thread safe. Last time I looked at the code,
it appeared to be written in such a way that it will sacrifice counts for the
sake of avoiding impacting the performance of the program. That is to say, it
appears to use an atomic operation which detects that some other thread is
already executing the critical region, in which case the calling thread just
bails without recording the count. So it won't bomb, but it will drop data.
>http://opensource.corel.com/cprof.html
>
>Please also note coredumping multithreaded apps in 2.2 kernels aren't
>reliable [should be ok in 2.4] - the kernel dumps just one thread and
>usually not the one that really crashed. Workaround is if you run it
>from gdb or apply this one-liner patch:
>http://www.cs.helsinki.fi/linux/linux-kernel/2000-11/0896.html
I use a two liner patch which causes each thread (other than the
thread manager, which terminates via _exit(0)) to generate a core file.
Each core file is named "core.<pid>".
To do this, I increase the size of the corefile[] local array in
the elf_core_dump function fs/binfmt_elf.c.
sprintf(corefile, "core.%d", (int) current->pid);
Then I just nuke the atomic_read(¤t->mm->count) != 1 test.
--
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: John Gluck <[EMAIL PROTECTED]>
Subject: Re: Kernel 2.4.0-test6 Compile and install module problem?
Date: Thu, 17 Aug 2000 15:51:10 -0400
Paul Kimoto wrote:
> In article <[EMAIL PROTECTED]>, John Gluck wrote:
> > I noticed that the structure of the /lib/modules/ 2.4.0-test6 is changed from
> > the way it was in eariler kernels.
> > I suspect "make modules_install" is screwed up...
>
> No, but it's been changed. There have been newer modutils releases to
> take care of that.
>
That's wonderful information... It would be useful if you also said what versions
of modutils and where to find them.
>
> --
> Paul Kimoto
> Disclaimer: Other than explicit citations of URLs, hyperlinks appearing
> in this article have been inserted without the permission of the author.
--
John Gluck (Passport Kernel Design Group)
(613) 765-8392 ESN 395-8392
Unless otherwise stated, any opinions expressed here are strictly my own
and do not reflect any official position of Nortel Networks.
------------------------------
** 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
******************************
