Linux-Development-Sys Digest #336, Volume #8 Mon, 11 Dec 00 00:13:12 EST
Contents:
Re: Help! Hosed XMMS trying to upgrade (michael james obrien)
Re: Zombie processes? ("S.L. Heggood")
Is there a TWAIN driver in development for Linux? (jtnews)
gdb problem (john connolly)
Re: Is there a TWAIN driver in development for Linux? (Philip Armstrong)
Test suites for Linux (Ravi)
Re: Time stamp counter - what's this ??? (Paul Fulghum)
Re: A faster memcpy and bzero for x86 (Robert Redelmeier)
beta version of Borland's Kylix anywhere for download? (Alexander Grotzsch)
testing read permission on an already open device ([EMAIL PROTECTED])
Re: crt1.o (Nix)
Re: Is there a TWAIN driver in development for Linux? (jtnews)
Re: are the header file and compiler problems fixed yet in RedHat 7.0? (Nix)
Re: changing BASH's path searching (Nix)
how to create install diskettes? ("Marty Ross")
Re: A faster memcpy and bzero for x86 (Robert Krawitz)
What is the command to . . . ? ([EMAIL PROTECTED])
Re: A faster memcpy and bzero for x86 (Robert Redelmeier)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (michael james obrien)
Crossposted-To: alt.os.linux,alt.uu.comp.os.linux.questions,linux.redhat.install
Subject: Re: Help! Hosed XMMS trying to upgrade
Date: 10 Dec 2000 07:19:54 GMT
Matt ([EMAIL PROTECTED]) wrote:
: I just tried to upgrade XMMS from 1.2.2 to 1.2.4 and now it doesn't work.
: How can I uninstall these RPMs?
first rpm -qa|grep xmms
note the name , then use rpm -e
: I'm running Gnome on RH 7 on a clean install done 2 days ago.
: I was trying to upgrade so I could use a plugin... now I just want it back
: the way it was. :-P
: I appreciate any help you might give.
------------------------------
From: "S.L. Heggood" <[EMAIL PROTECTED]>
Subject: Re: Zombie processes?
Date: Sun, 10 Dec 2000 03:49:36 -0500
If you condition for SIGCLD (death of a child) you can
do the wait after the fact. No wait actually takes place
in terms of a signficant amount of time, but it does clear the process slot
thereby eliminating the zombie.
main()
{
..
..
child=fork(); /* .etc */
..
if(child>0) /* not error, not child, but parent */
signal(SIGCLD,clearProcSlot);
..
..
}
void
clearProcSlot()
{
int rc, stuff;
rc=wait(&stuff);
}
aoth rc and stuff will contain useful info; explore the
man page for details.
-steve-
"Daniel Lenski" <m [EMAIL PROTECTED]> wrote in message
news:90rjps$mj8$[EMAIL PROTECTED]...
> Hi,
> I have this little server daemon program that does something like this:
>
> if (!fork()) {
> handle_incoming_connection(socket);
> close(socket);
> exit(0)
> }
>
> But it seems to leave me with a zombie process every time it forks and
> then exits. How can I get rid of these zombie processes? I don't want
> to have to do a wait() for the child processes to exit, since that would
> destroy the whole point of handling multiply client connections ...
>
> Any help will be appreciated.
>
> --
> Daniel Lenski
> [EMAIL PROTECTED]
>
> "If we couldn't laugh at things that didn't make sense,
> we couldn't react to a lot of the world around us."
> --Calvin and Hobbes
------------------------------
Date: Sun, 10 Dec 2000 10:37:37 -0500
From: jtnews <[EMAIL PROTECTED]>
Subject: Is there a TWAIN driver in development for Linux?
Is there a TWAIN driver in development for Linux?
------------------------------
From: john connolly <[EMAIL PROTECTED]>
Subject: gdb problem
Date: Sun, 10 Dec 2000 16:49:16 GMT
I have not been able to get gdb or the graphical versions xxgdb or ddd
to show source code. In gdb when I type 'list' I get the message that it
can't find init.c. I have gdb 5.0, slackware7.0 and kde2.0. Any help
would be appreciated.
Thanks, JWC
------------------------------
From: [EMAIL PROTECTED] (Philip Armstrong)
Subject: Re: Is there a TWAIN driver in development for Linux?
Date: 10 Dec 2000 16:39:04 -0000
In article <[EMAIL PROTECTED]>,
jtnews <[EMAIL PROTECTED]> wrote:
>Is there a TWAIN driver in development for Linux?
No. TWAIN is probably not what you think it is anyway. Scanners do not
expose a TWAIN API, rather their specific drivers expose a TWAIN API
to other apps on a windows box. This makes implementing TWAIN drivers
for linux a waste of time, except possibly if you want to run windows
apps under WINE.
On the other hand, if you want to access your scanner under linux /
other unix then investigate the SANE project. (A google search should
find the URL easily enough, and I don't have it to hand right now...)
Phil
--
http://www.kantaka.co.uk/ .oOo. public key: http://www.kantaka.co.uk/gpg.txt
------------------------------
From: Ravi <[EMAIL PROTECTED]>
Subject: Test suites for Linux
Date: Mon, 27 Nov 2000 22:58:32 +0530
Hi all,
Is there a set of tests that I can run on Linux to validate
the system? If I am playing around with the kernel, I would
like to ensure I didn't break anything. Any hints on this will
be helpful.
-Thanks,
Ravi.
------------------------------
From: Paul Fulghum <[EMAIL PROTECTED]>
Subject: Re: Time stamp counter - what's this ???
Date: Sun, 10 Dec 2000 19:03:45 GMT
David Kalita wrote:
> Hi
>
> I have problem - I build a new kernel (2.4.0-test11) and now some
> programs tell me that my procesor dosn't support TSC (time stamp
> counter). But in the /proc/cpuinfo I have this feature ( Celeron ).
> Maybe I forgot something to compile.
> Could anyone tell me where I made mistake or point to any documentation.
>
> Thanks
The kernel must be configured for Pentium class (under 'Processor type
and features' menu - Processor Type option) or higher to
enable the CONFIG_X86_TSC option.
------------------------------
Date: Sun, 10 Dec 2000 13:38:59 -0600
From: Robert Redelmeier <[EMAIL PROTECTED]>
Subject: Re: A faster memcpy and bzero for x86
Linus Torvalds wrote in part:
>
> Note that even in user space memcpy() using MMX registers is NOT
> necessarily a good idea at all.
<snip>
> But it tends to have horrible side-effects. Like the fact that when
> multiple processes (or threads) are running, it means that the FP state
> has to be switched all the time. Normally we can avoid this overhead,
> because most programs do not actually tend to use the FP unit very much,
> so with some simple lazy FP switching we can make thread and process
> switches much faster.
Furthermore, optimizations tend to be very processor-specific.
Block moves are a hot topic among us asm-heads.
The original poster was benchmarking a plain Pentium where the
FILD/FISTP instructions give ~20% better performance than anything
else. (The FP integer instructions are necessary to avoid the
FP exceptions that some data patterns (NaN, denormals) produce.)
But this advantage is much less on more modern processors. The
very popular intel P6 (PPro, PentII, Celeron, Pent///) has special
hardware assisted REP MOSVD that is usually the fastest block move
on these chips. For AMD chips MMX moves are faster, but on my
K6-2ctx, its only ~10% faster. These times are to main memory,
and moves only to L1 or L2 tend to amplify any differences.
AMD still recommends REP MOSVD for blended code that runs well
on many CPUs. It then qualifies as a broad optimum, and I
certainly hope that libc and the kernel use it.
It matters in the kernel because of the "copy-on-write" virtual
memory policy. When a fresh page is written for the first time,
it gets remapped from the zeroeth page to real memory, and this
real memory cleared before the write. For the bzero, REP STOSD
is optimum in the same way as REP MOVSD.
Much as I agree with Linus that FP context switches should be
avoided, still I can't help wondering if MMX movq wouldn't be
faster for 4kB page-size operations. Maybe there's some quick
"mini-context-switch" that would just free-up one MMX register.
Of course, it would have to be safe if that reg was used for FP.
-- Robert author `cpuburn` http://users.ev1.net/~redelm
------------------------------
Date: Sun, 10 Dec 2000 21:29:00 +0100
From: Alexander Grotzsch <[EMAIL PROTECTED]>
Subject: beta version of Borland's Kylix anywhere for download?
Hi!
Does anyone know where I can get a beta (or alpha) version of Borland's
Kylix for Linux?
------------------------------
From: [EMAIL PROTECTED]
Subject: testing read permission on an already open device
Date: Sun, 10 Dec 2000 22:36:45 -0000
I'm looking for a function in the kernel that can be called for an ioctl
to test to see if the current process has read permission on the device
which is obviously already open, but may have been opened for write, not
for read.
This ioctl will inject a string into the input of a virtual console as
if typed on the keyboard. Since it is customary to allow other users
to have write permission to a tty device (e.g. to permit sending messages
such as with the "write" command, or talk), the permission to inject
input needs to be tighter than just being able to open the device. It
looks to me like the read permission is the way to go. I could code up
a test for owner, group, and supplementary group checks, but it would
seem to me that such a test is likely to already be coded. I did look
around in the open code, but there, the test is done in a different
context (the file isn't yet open). In the ioctl context, the file is
already open, so the information available is different. Grepping for
"obvious" keywords through the kernel code is quite a noisy experience
and isn't turning up anything. But then, I've found things with names
I would not have anticipated, and this could be likewise.
I just don't want to be accused of "re-inventing the wheel" (since in
this case I won't be making a wheel any more round than I suspect is
already made).
And to try to head off a few more private emails from people who get the
suddenly bright idea that since GPM can paste into the input, that I
should just do what GPM does and not bother with my own ioctl, I'll let
you know that I've already looked at that long ago, and no, it does not
work that way. Go read it yourself. Hint: cut and paste data stays in
the kernel; it is not transferred from process space.
--
=================================================================
| Phil Howard - KA9WGN | Dallas | http://linuxhomepage.com/ |
| [EMAIL PROTECTED] | Texas, USA | http://phil.ipal.org/ |
=================================================================
------------------------------
From: Nix <$}xinix{[email protected]>
Subject: Re: crt1.o
Date: 10 Dec 2000 23:05:09 +0000
On Wed, 06 Dec 2000, Damon Jacobsen gibbered:
> Has anyone else noticed serious degradation in
> preformance in the latest builds of crt1.o? I am using
> Red Hat 7 and noticed that crt1.o is causing my code
> to come to a crawl unless I bring over a version of it
> from SUSE 6.1.
That's rather hard to believe; crt1.o is only used at program startup.
> I noticed some compilers are coming
> with thier own verision of it
crt0.o is part of GCC on a few platforms; crt1.o is part of the GNU C
Library (and of other C libraries on other unices). See
glibc-2.[12]*/csu/ and trace through the makefile in that directory.
> and was wondering if
> anyone had the source code for this file and knew why
> we were seeing performance degradation.
The sources are generated from files in the csu/ subdirectory of glibc.
Since they're only executed at startup it is highly unlikely that they
alone are causing performance degradation; but startup is a complex
time, with the C library, GCC, and the OS dancing an intricate gavotte
(and GCC has extra code to handle other OSes with different C libraries,
and so on, so the GCC-provided app startup code is really rather
intricate and hard to disentangle).
Profile your program with gprof while degraded and while not degraded
and see where the time's being spent.
--
`Get your acts together, guys. Stop blathering and frothing
at the mouth.' --- Linus Torvalds
------------------------------
Date: Sun, 10 Dec 2000 18:11:55 -0500
From: jtnews <[EMAIL PROTECTED]>
Subject: Re: Is there a TWAIN driver in development for Linux?
twain isn't just for scanners it's for a lot of different
digital devices. see www.twain.org
Philip Armstrong wrote:
>
> In article <[EMAIL PROTECTED]>,
> jtnews <[EMAIL PROTECTED]> wrote:
> >Is there a TWAIN driver in development for Linux?
>
> No. TWAIN is probably not what you think it is anyway. Scanners do not
> expose a TWAIN API, rather their specific drivers expose a TWAIN API
> to other apps on a windows box. This makes implementing TWAIN drivers
> for linux a waste of time, except possibly if you want to run windows
> apps under WINE.
>
> On the other hand, if you want to access your scanner under linux /
> other unix then investigate the SANE project. (A google search should
> find the URL easily enough, and I don't have it to hand right now...)
>
> Phil
> --
> http://www.kantaka.co.uk/ .oOo. public key: http://www.kantaka.co.uk/gpg.txt
------------------------------
From: Nix <$}xinix{[email protected]>
Subject: Re: are the header file and compiler problems fixed yet in RedHat 7.0?
Date: 10 Dec 2000 23:14:01 +0000
On Sat, 09 Dec 2000, [EMAIL PROTECTED] gibbered:
> I heard that the C header files and compiler were somehow inconsistent
> in redhat 7.0.
You heard wrong. The C library and compiler are both unstable
development versions, but they should work with each other (for certain
values of `work'.)
--
`Get your acts together, guys. Stop blathering and frothing
at the mouth.' --- Linus Torvalds
------------------------------
From: Nix <$}xinix{[email protected]>
Subject: Re: changing BASH's path searching
Date: 10 Dec 2000 23:16:07 +0000
On Sun, 10 Dec 2000, [EMAIL PROTECTED] stipulated:
> Well, I wouldn't want apt or RPM to generate them. The sysadmin
> should be the only one to do so. I would view those symlinks NOT as
> part of the package installed, but as part of the system
> configuration. Consider that you may even need multiple versions of a
> package for some reason. The symlink would be your way of configuring
> which to use.
>
> That, and a script which scans for dangling symlinks to be cleaned up,
> would be a better way, IMHO.
GNU stow, epkg/encap, opt-depot, and STORE can all do this sort of
thing, in increasing order of complexity. STORE can do just about
anything including handle multi-architecture network-shared trees
neatly, but it's fearfully complex.
--
`Get your acts together, guys. Stop blathering and frothing
at the mouth.' --- Linus Torvalds
------------------------------
From: "Marty Ross" <[EMAIL PROTECTED]>
Subject: how to create install diskettes?
Date: Sun, 10 Dec 2000 16:47:48 +0200
I'm continuing to try to get my installation diskettes to work, and after
much experimentation, I'm pretty sure that I've got something terribly wrong
in my rootdisk/bootdisk configuration. I'm building from a 2.2.14-5 kernel,
from RedHat 6.2, according to the reccommendations of the "Bootdisk HOWTO".
One thing I'm still not real clear on: my "boot disk" has the kernel image,
and LILO is run on it. When I boot it, it asks me to insert the "root
disk"--which I do. But the "root disk" contains no kernel image--should it?
Is the kernel completely loaded from the boot disk and then locked into
memory, or does it need to get at it also on the "root" filesystem?
Where should I begin to check for problems on a boot/root diskette pair that
boots always with no problems, but then always dies (complete lockup) when I
go to format the hard drive (again, as I've written before, I have tried
this software on about half a dozen platforms and the results are identical;
I'm convinced its a software problem, not hardware as I thought before).
Is there anything special I need to do for disk geometry (or other hardware
setup)? All the platforms are PCI, and the hard disks are from 1.2GB to
6GB. I guess most are using LBA, but some not. Does it matter? BIOS
interactions (now my kernel is compiled "direct", but I've tried all
interactions).
Any help appreciated.
------------------------------
From: Robert Krawitz <[EMAIL PROTECTED]>
Subject: Re: A faster memcpy and bzero for x86
Date: 10 Dec 2000 21:36:43 -0500
Robert Redelmeier <[EMAIL PROTECTED]> writes:
> The original poster was benchmarking a plain Pentium where the
> FILD/FISTP instructions give ~20% better performance than anything
> else. (The FP integer instructions are necessary to avoid the
> FP exceptions that some data patterns (NaN, denormals) produce.)
Actually, my experience was that by using a somewhat funky pattern of
loads, the performance improvement was substantially more --
throughput went from 21 MB/sec to 37 MB/sec or so. Without the funky
load pattern, it was more like 28 MB/sec. Cache effects and all that.
> It matters in the kernel because of the "copy-on-write" virtual
> memory policy. When a fresh page is written for the first time,
> it gets remapped from the zeroeth page to real memory, and this
> real memory cleared before the write. For the bzero, REP STOSD
> is optimum in the same way as REP MOVSD.
Except, of course, when it isn't. Even on a Pentium II, the FPU gives
a slight performance boost.
> Much as I agree with Linus that FP context switches should be
> avoided, still I can't help wondering if MMX movq wouldn't be
> faster for 4kB page-size operations. Maybe there's some quick
> "mini-context-switch" that would just free-up one MMX register.
> Of course, it would have to be safe if that reg was used for FP.
It probably isn't worth doing unless you use a lot of registers. At
least on the Pentium, I consistently got an overall win using the FPU
block copy for page size chunks, testing with the Byte UNIX
benchmarks.
--
Robert Krawitz <[EMAIL PROTECTED]> http://www.tiac.net/users/rlk/
Tall Clubs International -- http://www.tall.org/ or 1-888-IM-TALL-2
Member of the League for Programming Freedom -- mail [EMAIL PROTECTED]
Project lead for The Gimp Print -- http://gimp-print.sourceforge.net
"Linux doesn't dictate how I work, I dictate how Linux works."
--Eric Crampton
------------------------------
From: [EMAIL PROTECTED]
Crossposted-To:
alt.os.linux.mandrake,alt.os.linux.slackware,alt.uu.comp.os.linux.questions,comp.os.linux.misc,comp.os.linux.networking,comp.os.linux.hardware,comp.os.linux.setup
Subject: What is the command to . . . ?
Date: Mon, 11 Dec 2000 04:30:09 GMT
Reply-To: [EMAIL PROTECTED]
I am looking for the command that will help me compare two directory
structures.
I just did a file copy to an NFS drive and I want to make sure that I
got everything.
I used
cp -axv /dev /mnt/vol00
cp -axv /bin /mnt/vol00
cp -axv/usr /mnt/vol00
etc . . .
Doing some sampling, it appears that everything copied okay.
What I am looking for is the equivalent to this
dos command: dir *.* /s
i.e. I am looking for file counts and directory counts as well as
total sizes.
thanks in advance,
charles
p.s.
linux 8)
------------------------------
Date: Sun, 10 Dec 2000 22:38:48 -0600
From: Robert Redelmeier <[EMAIL PROTECTED]>
Subject: Re: A faster memcpy and bzero for x86
Robert Krawitz wrote:
>
> Actually, my experience was that by using a somewhat funky pattern of
> loads, the performance improvement was substantially more --
> throughput went from 21 MB/sec to 37 MB/sec or so. Without the funky
> load pattern, it was more like 28 MB/sec. Cache effects and all that.
These are low numbers even to main memory on a P5 (EDO RAM) system.
Usually REP MOVSD will get ~36 MB/s, and FILD/FISTP ~42. Of course,
straight 32-bit integer moves are slower, especially on these CPUs.
Are you sure you weren't using these rather than repeat-string moves?
> Except, of course, when it isn't. Even on a Pentium II, the FPU gives
> a slight performance boost.
Not that I've been able to measure compared to REP MOVSD. But
quite FP is quite likely better than ordinary 32 bit MOV's.
> It probably isn't worth doing unless you use a lot of registers. At
> least on the Pentium, I consistently got an overall win using the FPU
> block copy for page size chunks, testing with the Byte UNIX
> benchmarks.
No disagreement on the plain or MMX Pentium.
-- Robert author `cpuburn` http://users.ev1.net/~redelm
------------------------------
** 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 by posting to the
comp.os.linux.development.system newsgroup.
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
******************************
