Linux-Development-Sys Digest #69, Volume #7      Wed, 18 Aug 99 21:14:11 EDT

Contents:
  Importance of TX errors? (pcmcia) (Allin Cottrell)
  Re: Mice and Computer Switch? (Grant Edwards)
  Re: Troll (was: why not C++?) (Rainer Joswig)
  Re: Adding a non-standard Parallel Port (Daniel Robert Franklin)
  Re: threads (Emile van bergen)
  Re: GUI apps core dumping on printf's (Kaz Kylheku)
  Re: Why so inefficient source RPM's ?? (Johan Kullstam)
  Re: most efficient way to zero out a partition? (Kaz Kylheku)
  Re: More kind words from M$. (Paul Gallagher)
  Re: naive newbie wants to call add_timer() (ellis)
  Re: Troll (was: why not C++?) (Rainer Joswig)
  Re: Mice and Computer Switch? ("Jason")
  Re: most efficient way to zero out a partition? (Eric Hegstrom)
  Re: most efficient way to zero out a partition? (Doug DeJulio)

----------------------------------------------------------------------------

From: Allin Cottrell <[EMAIL PROTECTED]>
Subject: Importance of TX errors? (pcmcia)
Date: Wed, 18 Aug 1999 17:40:00 -0400

I have a ThinkPad 390e with IBM EtherJet CardBus Adapter
card, which I understand is really a Xircom card.  I'm using
the driver from pcmcia-cs 3.0.14 and things seem OK, except
that ifconfig is showing a lot of TX errors:

eth0   Link encap:Ethernet  HWaddr 00:06:29:90:43:11  
       inet addr:152.17.150.10  Bcast:152.17.255.255 
Mask:255.255.0.0
       UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
       RX packets:37176 errors:4 dropped:0 overruns:0 frame:0
       TX packets:7 errors:6137 dropped:0 overruns:0 carrier:6137
       collisions:0 txqueuelen:100 
       Interrupt:3 Base address:0x200 

Any advice appreciated.

This is with kernel 2.2.11.  The CardBus adapter fires up thus

Aug 18 16:42:18 pc10 cardmgr[916]: executing: 'insmod
/lib/modules/2.2.11/pcmcia/tulip_cb.o'
Aug 18 16:42:18 pc10 kernel: cs: cb_config(bus 32): vendor 0x115d,
device 0x0003 
Aug 18 16:42:18 pc10 kernel:   fn 0 bar 1: io 0x200-0x27f 
Aug 18 16:42:18 pc10 kernel:   fn 0 bar 2: mem 0x6000b000-0x6000b7ff 
Aug 18 16:42:18 pc10 kernel:   fn 0 bar 3: mem 0x6000a000-0x6000a7ff 
Aug 18 16:42:18 pc10 kernel:   fn 0 rom: mem 0x60006000-0x60009fff 
Aug 18 16:42:18 pc10 kernel: tulip_attach(bus 32, function 0) 
Aug 18 16:42:18 pc10 kernel: tulip.c:v0.91 4/14/99
[EMAIL PROTECTED] (modified by [EMAIL PROTECTED]
for XIRCOM CBE, fixed by Doug Ledford) 
Aug 18 16:42:18 pc10 kernel: eth0: Xircom Cardbus Adapter (DEC 21143
compatible mode) rev 3 at 0x200, 00:06:29:90:43:11, IRQ 3. 
Aug 18 16:42:18 pc10 kernel: eth0:  MII transceiver #0 config 3100
status 7809 advertising 01e1. 

-- 
Allin Cottrell
Department of Economics
Wake Forest University, NC

------------------------------

From: grant@nowhere. (Grant Edwards)
Subject: Re: Mice and Computer Switch?
Date: Wed, 18 Aug 1999 20:52:06 GMT

In article <gStu3.153$[EMAIL PROTECTED]>, Jason wrote:

>I was wondering if anyone has run into the following problem:
>
>I have a bunch of Linux boxes all connected to a Belkin Omni View Switch (An
>electronic switch for Mouse, Keyboard, and Monitor).  The problem I'm having
>is when I leave one of my Linux boxes running X and I switch to another
>machine and then back to the first one I get nothing but erratic mouse
>movement in X on that box.

The problem is caused by the fact that some mice have internal
"state" information.  They have different modes and resolutions
that may need to be initialized to a particular state for a
given system (Xfree86, for example) to be happy.

If you switch back-and-forth between two systems that expect
the mouse to be in two different modes, then you're going to
have problems, because the systems have no way of knowing when
they need to re-initialize the mouse to get it to the
configuration they want.

You need to find a nice dumb mouse that only has 1
mode/resolution and doesn't require any initialization (and
your all your systems need to get along with that one
mode/resolution).  Finding out that type of information about
mice before you buy them is probably not too easy.

-- 
Grant Edwards                   grante             Yow!  Eisenhower!! Your
                                  at               mimeograph machine upsets
                               visi.com            my stomach!!

------------------------------

From: [EMAIL PROTECTED] (Rainer Joswig)
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.misc
Subject: Re: Troll (was: why not C++?)
Date: Thu, 19 Aug 1999 00:27:58 +0200

In article <[EMAIL PROTECTED]>, Stephan Houben <[EMAIL PROTECTED]> 
wrote:

> IIRC there was a C compiler for some Lisp machines. It implemented
> pointers with "cons"-cells.

Sure? The Lisp system had pointers (called Locatives) as a
primitive.

> A greater abstraction inversion the world
> has never seen.

Not really. Cons cells are in principle pointers. Two pointers
in one row. Actually on the Lisp machine they had tagged
data with CDR-coding for lists (-> cons cells).
This means a new list of, say, ten items is internally stored
as a consecutive array of ten pointers to items.

> Note that Linux is not a C OS. It is a general-purpose OS whose kernel
> happens to be written in C.

That's to bad.

> If they hadn't told me this, I would never know.
> I still don''t care. As long as the StephanTalk compiler does its job,
> I don't care in which language the OS is written.

A Lisp users says: I don't care what language the kernel
is written in, as long as it is Lisp.
The difference between a Lisp machine and a Linux
system is huge. The Lisp Machine has an open, incrementally
changeable and dynamic OS. The OS is written in a
pure OOP style. That means that things like
IP-Packets or Processes are objects. And operations
on them are implemented as methods.

------------------------------

From: [EMAIL PROTECTED] (Daniel Robert Franklin)
Subject: Re: Adding a non-standard Parallel Port
Date: 18 Aug 99 22:45:07 GMT

"Norm Dresner" <[EMAIL PROTECTED]> writes:

>I need to add to a Linux box a parallel port that has been hacked-up to be
>at a non-standard address.  Where in the kernel source code do I go to add
>this address to the list of possible parallel ports?

You shouldn't need to recompile. Assuming you are using 2.2.x with parport
compiled into the kernel, then add this to /etc/lilo.conf and re-run lilo:

append="parport=0xYYY,Z"

where YYY is the I/O address in hex and Z is the IRQ. If you use loadlin
add the bit between the quotes to your loadlin command line.

Cheers,

- Daniel
--
******************************************************************************
*       Daniel Franklin - Postgraduate student in Electrical Engineering
*       [EMAIL PROTECTED]
******************************************************************************

------------------------------

From: Emile van bergen <[EMAIL PROTECTED]>
Subject: Re: threads
Date: Wed, 18 Aug 1999 23:27:09 +0000

On Tue, 17 Aug 1999, Bill Burris wrote:

[SNIP]

>> Hmm... does a real-time and i/o-intensive application imply that it should
>> be built using threads? I don't follow.
>
>I have multiple devices which I need to respond to regularly.  Instead of
>going around polling them I have a thread dedicated to servicing each
>device.  When there is no I/O happening the thread sleeps.

Why not use select() on all your I/O streams (including user input
perhaps) at once? It will return a fd_set containing all ready
descriptors that you could subsequently pass on to the handlers for the
different streams. No need to poll them one by one!

See the thread about Unix vs. NT applications programming and async I/O
a while back at www.deja.com if you're interested.

[SNIP]

>To do this with separate processes means you have the extra overhead
>associated with maintaining separate address spaces.  There is also the
>overhead associated with synchronization and communications between
>processes.  Threads are essentially a light weight form of multitasking.

Yes, but linux's processes aren't that much more heavyweight than
threads (on VMS or NT, processes are indeed relatively high overhead).

>This is most likely why NT & IIS was able to serve up web pages more quickly
>then Linux & Apache in recent tests.  My guess is that Windows programmers
>tend to think in terms of threads and Unix programmers tend to think in
>terms of processes.  Possibly one reason why Linux is more stable, threads
>can be difficult to debug.

Last statement is true, but I think one of the main reason why windows
programmers use threads througout is that the difference in overhead is
bigger. Also, many UI things tend to block at unwanted points, so if
you want to continue doing other things while the application is in
Windows' event dispatch loop, you need another thread, <rant> or have
your application cut to pieces by heavy use of callback functions.
</rant>.

-- 

M.vr.gr. / Best regards,

Emile van Bergen (e-mail address: [EMAIL PROTECTED])

This e-mail message is 100% electronically degradeable and produced
on a GNU/Linux system.
~
~
:wq



------------------------------

From: [EMAIL PROTECTED] (Kaz Kylheku)
Crossposted-To: comp.windows.x.kde,linux.dev.c-programming,comp.os.linux.x
Subject: Re: GUI apps core dumping on printf's
Date: Wed, 18 Aug 1999 21:12:00 GMT

On Wed, 18 Aug 1999 11:29:12 -0700, Dimi Shahbaz <[EMAIL PROTECTED]>
wrote:
>Hello,
>When developing GUI apps (using KDE &qt) I like to put printf's and
>cout's in the code for debugging purposes.  This use to work fine, and I
>saw the printf's in the app's parent terminal.  Now, however, the GUI
>program core dumps if it printf's more than 1 newline to the parent
>terminal.  Ie, if I printf("debug message\n something else\n");  I see
>the "debug  message" printed ok, but the second line doesn't show up,
>and the program seg faults.

You do realize that the first argument to printf is actually a format
string that is scanned for conversion specifiers? Check that there
are no conversion specifiers in the text you are trying to print.
If it cannot be determined at compile time that there are no conversion
specifiers, maybe you should use some other function, like fputs().

Show the exact message you are trying to print.

------------------------------

Crossposted-To: linux.redhat.misc,linux.redhat.rpm
Subject: Re: Why so inefficient source RPM's ??
From: Johan Kullstam <[EMAIL PROTECTED]>
Date: 18 Aug 1999 17:44:42 -0400

Bill Anderson <[EMAIL PROTECTED]> writes:

> Johan Kullstam wrote:
> > 
> > [EMAIL PROTECTED] (Suchandra Thapa) writes:
> > 
> > > Peter Mutsaers <[EMAIL PROTECTED]> wrote:
> > > >With source RPM's, it seems you have to re-download the whole thing
> > > >(sometimes huge RPM's such as gcc) for every minor tweak.
> > > >
> > > >Am I missing something? Is there a place where Redhat (or contrib)
> > > >source RPM's are located in unpacked form so that I can update without
> > > >downloading the whole original source over and over again?
> 
> When you download and install foo-1.0.i386.rpm, you are not installing
> source (unless the builder totally messed up :).
> When foo-1.1 comes out, and you get and install foo-1-1.i386.rpm, again,
> no source is downloaded, just whatever is needed to run soo (along with
> documentation usually).

read the subject.  we are talking *source* RPMs here.

> > >
> > >       If you do a rpm -Uvh or rpm -ivh to the source rpm then you
> > > should get the tar.gz'ed source in the /usr/src/redhat/SOURCE directory
> > > and the spec in /usr/src/redhat/SPEC directory.
> > 
> > this presupposes that you already have the old source rpm.  if you do
> > not, you have to 1) download the new source 2) download the old
> > src-rpm.  note that step 2) contains the old sources which are 1)
> > superceded by the new source and hence superflous and 2) often large.
> 
> If the builder distributes patches, you only need to download the
> original src.rpm, and apply patches.
> Either way, if you do not have the source, you either download a binary,
> or you download the source.
> As seen below, this is precisely what the previous poster indicated. 

what if the builder doesn't offer a patch.  you want to roll up a new
rpm from the newer sources and wish to borrow from past rpm spec
files.  you have to download the source twice.  it's annoying.

> > > Just download the patch
> > > and place it in the SOURCE directory and add the proper lines to the spec
> > > files (Patch[n]: patch.tar.gz where n is some integer at the top of the
> > > spec file and a corresponding %patch[n] -your_options_to_patch before the
> > > %build). Then after a rpm -bb your.spec or rpm -ba your.spec the binary
> > > rpm should appear in /usr/src/redhat/RPM  hierarchy and the source rpm in
> > > /usr/src/redhat/SRPMS.
> > 
> > sometimes hacking the spec file is a lot of trouble.  i spent a few
> > hours hacking the egcs-1.1.2 rpm-spec file to make it do gcc-2.95.
> > 
> > really, it'd be very nice to have no-source rpms with just the spec
> > file and patches.
> 
> Complain to the maintainer of the app. 
> RPM is fully capable of these.

it's not.

when you build from a spec, rpm makes binarary rpms and source rpms.
it does not make a package containing spec file and patches *without*
the main source tarball.

> It is up to whomever maintains the rpms (not always the same as whomever
> maintains the app) to distribute these.

i want a no-source rpm.  i want the source-less rpms to be found on
ftp sites.  the application maintainer cannot change this situation
one way or another.  (unless you are talking about the maintainer of
the rpm application only.)

i really like sources who are kind enough to include an
rpm spec file within the tarball.  this, an application maintainer,
can do.

-- 
J o h a n  K u l l s t a m
[[EMAIL PROTECTED]]
Don't Fear the Penguin!

------------------------------

From: [EMAIL PROTECTED] (Kaz Kylheku)
Subject: Re: most efficient way to zero out a partition?
Date: Wed, 18 Aug 1999 23:32:31 GMT

On 18 Aug 1999 12:44:14 -0700, Ronald Cole <[EMAIL PROTECTED]> wrote:
>I feel the need to zero out my /dev/sda10.  It's a bit over 1-gig
>and so:
>
>       dd if=/dev/zero of=/dev/sda10
>
>takes a *long* time.  How would I figure out the optimal block size
>to get the job done in the shortest amount of time without resorting
>to trial-and-error?

The block size doesn't matter, because it's a block device.  If you use a large
block size, it will do fewer system calls. 

Note that dd opens the output file with the O_SYNC flag (and for some reason
the input file as well, but that's irrelevant). This means that it will wait
for syncing in between writes. So it probably makes sense to pump at least
track-sized chunks that can be written in a single rotation of the disk.

------------------------------

Crossposted-To: comp.os.linux.misc
Subject: Re: More kind words from M$.
From: Paul Gallagher <[EMAIL PROTECTED]>
Date: 18 Aug 1999 19:34:23 -0400

Brett Hall <[EMAIL PROTECTED]> writes:

> Mindspring News wrote:
> 
> > Charles Sullivan wrote in message <7o8bp9$n9g$[EMAIL PROTECTED]>...
> > >

[snipped]

> > >On Page 6, "Editor's Notes", is found the following:
> > >
> > >  "What starts off hot, gets unpleasantly sticky after
> > >   awhile, starts to stink like a minty goat soon after
> > >   that, and ends up making you wish you never experienced
> > >   it?  No, we're not talking about the experience of
> > >   getting Linux actually working on your machine.  It's
> > >   summer in New York City! ...".
> > >
> >
> > He's just an AOL employee posing as a microsoft developer to further AOL's
> > insidious purposes. He used the words "unpleasantly" and "experienced". A
> > real microsoft programmer can't use words more than 8 letters in length  ;)
> 
> Well as long as you don't count all the gobbledy-gook the prepend to every
> word to tell you what kind of word it actually is ;)

Actually, I sort of like the phrase "stink like a minty goat." I
wonder where he found that?

P

------------------------------

From: [EMAIL PROTECTED] (ellis)
Subject: Re: naive newbie wants to call add_timer()
Date: 18 Aug 1999 23:38:16 GMT

In article <7pcfgf$hbe$[EMAIL PROTECTED]>,  <[EMAIL PROTECTED]> wrote:
>I'm trying to get some rudimentary understanding of calling a system
>function.
>
>// itimetest.c
>#include <linux/timer.h>
>int main()
>{
>    timer_list tl;  // (todo: initialize tl properly!)
>    add_timer( &tl);
>
>}
>
>[jclonts@deathstar cpp]$ g++ itimetest.c
>/tmp/ccNO5zm3.o: In function `main':
>/tmp/ccNO5zm3.o(.text+0xb): undefined reference to
>`add_timer(timer_list *)'
>
>So I'm trying to figure out, how do I tell the linker about the
>function add_timer?

You don't because add_timer is a kernel function.  You use it in a
kernel module not a userspace program.

--
http://www.fnet.net/~ellis/photo/linux.html

------------------------------

From: [EMAIL PROTECTED] (Rainer Joswig)
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.misc
Subject: Re: Troll (was: why not C++?)
Date: Thu, 19 Aug 1999 00:31:43 +0200

In article <conu3.10933$[EMAIL PROTECTED]>, [EMAIL PROTECTED] wrote:

> The founding of Symbolics and Lisp Machines has a great deal to do
> with the founding of the Free Software Foundation...  I do not recall
> offhand which company of the two RMS considered the "bad guys," but
> there was much bad blood at the time...

It was Symbolics.

------------------------------

From: "Jason" <[EMAIL PROTECTED]>
Subject: Re: Mice and Computer Switch?
Date: Wed, 18 Aug 1999 18:34:50 -0500

That makes a lot of sense.  But that still doesn't explain that fact why NT
has the problem fixed....  I guess I'm really curious about weather the
problem is somewhere in the kernel or X.

Unless MS has decided to use the same mode/res for the mouse across all
platforms that would explain the fix.  But the mouse is RADICALLY different
in NT vs Win98 and I'm using the same Intellimouse Software and driver
across both platforms, the settings in control panel are even identical.
The mouse requires much more physical desktop area to move the mouse the
same distance on the screen as it does versus Win98....

Jason

Grant Edwards <grant@nowhere.> wrote in message
news:[EMAIL PROTECTED]...
> In article <gStu3.153$[EMAIL PROTECTED]>, Jason wrote:
>
> >I was wondering if anyone has run into the following problem:
> >
> >I have a bunch of Linux boxes all connected to a Belkin Omni View Switch
(An
> >electronic switch for Mouse, Keyboard, and Monitor).  The problem I'm
having
> >is when I leave one of my Linux boxes running X and I switch to another
> >machine and then back to the first one I get nothing but erratic mouse
> >movement in X on that box.
>
> The problem is caused by the fact that some mice have internal
> "state" information.  They have different modes and resolutions
> that may need to be initialized to a particular state for a
> given system (Xfree86, for example) to be happy.
>
> If you switch back-and-forth between two systems that expect
> the mouse to be in two different modes, then you're going to
> have problems, because the systems have no way of knowing when
> they need to re-initialize the mouse to get it to the
> configuration they want.
>
> You need to find a nice dumb mouse that only has 1
> mode/resolution and doesn't require any initialization (and
> your all your systems need to get along with that one
> mode/resolution).  Finding out that type of information about
> mice before you buy them is probably not too easy.
>
> --
> Grant Edwards                   grante             Yow!  Eisenhower!! Your
>                                   at               mimeograph machine
upsets
>                                visi.com            my stomach!!
>



------------------------------

From: Eric Hegstrom <[EMAIL PROTECTED]>
Subject: Re: most efficient way to zero out a partition?
Date: Wed, 18 Aug 1999 16:41:47 -0700

Speaking of wasting bandwith ....

Ronald Cole wrote:

> If you don't know the answer, then please don't waste everybody's time
> and bandwidth.


Ok, so now I'm guilty to. 

-- 
Eric Hegstrom                          .~.
Senior Software Engineer               /V\  
Sonoran Scanners, Inc.                // \\          L I N U X
[EMAIL PROTECTED]        /(   )\  >don't fear the penguin<
520-617-0072 x402                     ^^-^^

------------------------------

From: [EMAIL PROTECTED] (Doug DeJulio)
Subject: Re: most efficient way to zero out a partition?
Date: 18 Aug 1999 20:01:52 -0400

In article <[EMAIL PROTECTED]>,
Ronald Cole  <[EMAIL PROTECTED]> wrote:
>I feel the need to zero out my /dev/sda10.  It's a bit over 1-gig
>and so:
>
>       dd if=/dev/zero of=/dev/sda10
>
>takes a *long* time.  How would I figure out the optimal block size
>to get the job done in the shortest amount of time without resorting
>to trial-and-error?

I find that using a block size that's too big doesn't cause any
trouble.  For example, when I write disk images to floppies I always
set the block size to the full length of the data.  So, use a
relatively huge block size, like 10 megabytes, and things should be
quick.
-- 
Doug DeJulio      | mailto:[EMAIL PROTECTED]
HKS, Incorporated | http://www.hks.net/~ddj/

------------------------------


** 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
******************************

Reply via email to