Linux-Development-Sys Digest #699, Volume #6 Mon, 10 May 99 21:14:09 EDT
Contents:
Re: Reliable (!) nic for 2.2 kernel? (bryan)
Re: Reliable (!) nic for 2.2 kernel? (bryan)
Re: Destructive Erase? (Adrian 'Dagurashibanipal' von Bidder)
Re: Reliable (!) nic for 2.2 kernel? (Johan Kullstam)
Couple of questions (Kal Kolberg)
Re: what means cli() and sti()? (Frank v Waveren)
Re: why top give false results? (Robert Nichols)
flash driver and source code for AMD AM29F800B (Tsu-Wang Chen)
Re: Reliable (!) nic for 2.2 kernel? (bryan)
Re: Reliable (!) nic for 2.2 kernel? (bryan)
Re: Glibc rant (Jan Vroonhof)
RH 6.0/2.2.5 kernel and problems with sendmsg/recvmsg (Kenneth & Susan)
Re: tulip driver woes (was Re: Reliable (!) nic for 2.2 kernel?) (bryan)
Re: Translation of linux to minor languages (Jonathan A. Buzzard)
----------------------------------------------------------------------------
From: bryan <[EMAIL PROTECTED]>
Subject: Re: Reliable (!) nic for 2.2 kernel?
Crossposted-To: comp.os.linux.networking
Date: Mon, 10 May 1999 18:18:42 GMT
In comp.os.linux.networking Etienne Lorrain <[EMAIL PROTECTED]> wrote:
: bryan wrote:
: > my tulip card is totally unreliable. I can bring it down with an ftp
: > xfer (local lan) at 10 or 100, in a minute or less. network hangs and
: > will NOT be reset by software.
: I am probably completely wrong, but would your test work
: with a 2.2 kernel compiled as UP, not SMP - or even better
: SMP without support of the improved IRQ hardware management ?
I tried disabling SMP and that didn't help much. it was my first thought ;-)
--
Bryan
------------------------------
From: bryan <[EMAIL PROTECTED]>
Subject: Re: Reliable (!) nic for 2.2 kernel?
Date: Mon, 10 May 1999 18:33:40 GMT
Don Baccus <[EMAIL PROTECTED]> wrote:
: In article <[EMAIL PROTECTED]>,
: Greg White <[EMAIL PROTECTED]> wrote:
: >Gonna have to agree with Leslie on this one. Could you please, if it is
: >not too much of a pain, scan the aforementioned box's cover and mail the
: >resulting image to me?
: Actually, despite my recent note swearing it said 3c509,
: I looked at it again and it DOES say 3c905 on the outside.
: After opening the box and seeing it was a 3c905, I checked
: the box again and I was transposing after all.
: To my knowledge, I'm not dyslexic.
worse: you are NOT dyslexic but you auto-correct yourself as if you
were, thus creating the problem ;-) ;-)
[couldn't resist]
--
Bryan
------------------------------
From: [EMAIL PROTECTED] (Adrian 'Dagurashibanipal' von Bidder)
Subject: Re: Destructive Erase?
Date: Mon, 10 May 1999 18:25:28 GMT
On Fri, 07 May 1999 16:47:15 GMT, matthew gauthier
<[EMAIL PROTECTED]> wrote:
>I'm trying to implement a destructive file erase, however, I'm at a
>loss as to the best way to insure that the same blocks are overwritten.
>If I use stdio and overwrite a file with an equal amount of data and
>close it, will the kernel put it on the same disk realestate at the
>next sync? Or am I going to need to work at a much lower level here?
Yo there!
In e2fs there is an attribute (man chattr) 'erase on unlink' or
sumthing similar. IIRC it's even implemented.
--
Greets from over there
Dagurashibanipal
[EMAIL PROTECTED]
'What with our wounded who can't walk? We don't leave our own!'
'You're right, Captain. We'll take them. They're field rations'
-- Mary Gentle, 'Grunts!'
------------------------------
Crossposted-To: comp.os.linux.networking
Subject: Re: Reliable (!) nic for 2.2 kernel?
From: Johan Kullstam <[EMAIL PROTECTED]>
Date: 10 May 1999 18:05:41 -0400
bryan <[EMAIL PROTECTED]> writes:
> In comp.os.linux.networking Johan Kullstam <[EMAIL PROTECTED]> wrote:
> : bryan <[EMAIL PROTECTED]> writes:
>
> : > its totally repeatable. I wonder if its my SMP that is throwing a
> : > monkey wrench into the works? is anyone happy with their tulip in
> : > 2.2.7 AND smp??
>
> : i am happy. i have a dec tulip 21140 card in a quad ppro box and it
> : seems fine. i use tulip driver v89h (what comes with linux 2.[12].x
> : kernels) and have tried v90 as well. i have run big ftp jobs (100's
> : of Mb) to move data back and forth between it and my other machine. i
> : have a 100Mbps setup through a little 4 port hub. i've got two more
> : dec tulips in my uniprocessor box. one 10Mbps 21041 and one 21140.
>
> : i can't recall the minor rev letter/numbers at this time.
>
> : what tests would you have me perform to inflict maximum punishment
> : upon these ethercard?
>
> connect two systems with same driver/kernel and a crossover-cable (NO
> hub - we want wire-speed (as close as possible) with no delays or
> buffering).
hmm all i have is this crappy hub. i have no cross-over cable.
> ping-flood the system:
>
> # ping -s 1000 -f <target>
>
> 1000-byte frames flooded (back-to-back). you should see "." chars and
> backspaces as the packet goes out and is acked.
ok.
this is from the uniprocessor machine, sophia, to the quad box, euler.
sophia(~)# time ping -s 1000 -f euler
PING euler.axel.nom (172.16.0.2): 1000 data bytes
....
--- euler.axel.nom ping statistics ---
1650247 packets transmitted, 1650243 packets received, 0% packet loss
round-trip min/avg/max = 0.4/1.1/352.7 ms
real 8m32.294s
user 0m37.730s
sys 4m6.190s
8 minutes of ping flooding. i got about 4 dots going across before i
hit control c.
sophia talks over eth1 to euler's eth0.
sophia(jk)$ cat /proc/interrupts
CPU0
0: 51141704 XT-PIC timer
1: 120383 XT-PIC keyboard
2: 0 XT-PIC cascade
4: 336914 XT-PIC serial
5: 9 XT-PIC soundblaster
9: 461181 XT-PIC eth0
10: 3863876 XT-PIC eth1
13: 1 XT-PIC fpu
14: 247877 XT-PIC ide0
NMI: 0
euler(Tmp)$ cat /proc/interrupts
CPU0 CPU1 CPU2 CPU3
0: 19176748 19427342 19493112 20077321 IO-APIC-edge timer
1: 2 2 0 0 IO-APIC-edge keyboard
2: 0 0 0 0 XT-PIC cascade
10: 26171 26154 25901 25784 IO-APIC-level aic7xxx
11: 335860 335798 335769 335885 IO-APIC-level eth0
13: 1 0 0 0 XT-PIC fpu
NMI: 0
ERR: 0
euler(Tmp)$ cat /proc/interrupts
CPU0 CPU1 CPU2 CPU3
0: 19186382 19436901 19502999 20087073 IO-APIC-edge timer
1: 2 2 0 0 IO-APIC-edge keyboard
2: 0 0 0 0 XT-PIC cascade
10: 26181 26166 25914 25791 IO-APIC-level aic7xxx
11: 950984 950917 950887 951009 IO-APIC-level eth0
13: 1 0 0 0 XT-PIC fpu
NMI: 0
ERR: 0
you can see the ethercards took lots of interrupts.
> under ideal conditions, each dot will get a backspace, so the line
> should not grow across the screen. on my system, it takes a few
> seconds for the dots to outnumber the backspaces, meaning packet loss.
> then, give it another minute or so and the xmitter or receiver will
> lock up and not even a single slow ping will go thru.
here is an excerpt from sophia's /proc/pci
Bus 0, device 19, function 0:
Ethernet controller: DEC DC21140 (rev 34).
Medium devsel. Fast back-to-back capable. IRQ 10. Master Capable.
Latency=64. Min Gnt=20.Max Lat=40.
I/O at 0xec80 [0xec81].
Non-prefetchable 32 bit memory at 0xfebfbf80 [0xfebfbf80].
here is an excerpt from euler's /proc/pci
Bus 0, device 13, function 0:
Ethernet controller: DEC DC21140 (rev 18).
Medium devsel. Fast back-to-back capable. IRQ 11. Master Capable.
Latency=64.
I/O at 0xfc00 [0xfc01].
Non-prefetchable 32 bit memory at 0xfdffec00 [0xfdffec00].
i am using the stock tulip.c which comes with linux-2.2.7
aka tulip.c:v0.89H 5/23/98
everything still seems rock solid. i was even able to do stuff over
the telnet session i have going from sophia to euler.
--
J o h a n K u l l s t a m
[[EMAIL PROTECTED]]
Don't Fear the Penguin!
------------------------------
From: Kal Kolberg <[EMAIL PROTECTED]>
Subject: Couple of questions
Date: Mon, 10 May 1999 17:46:47 -0400
First,
I am familiar with the iostat command under HP-UX and Solaris, is
there a similar command under Linux, I need to check the performance of
a couple of SCSI drives.
Second,
Have and error in dmesg, kernel: stuck on TLB IPI wait (CPU#0) any
ideas?
Third,
I have an oops in the log file, how do I track this down.
Kal
[EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED] (Frank v Waveren)
Subject: Re: what means cli() and sti()?
Date: Mon, 10 May 1999 23:17:34 GMT
I assume they're the same as in x86 assembler, where they mean:
sti means set interrupt, which allows interrupts to be processed.
cli means clear interrupt, which... Well, you can guess that I suppose :-)
In article <[EMAIL PROTECTED]>,
lckun <[EMAIL PROTECTED]> writes:
> Hello!
>
> What means the functions cli() and sti() in the source sched.c of
> kernel?
>
> Please tell me what it means and where can i find the more infomation
> for this functions...
>
>
> Thanks
>
>
> lckun
>
--
Frank v Waveren
[EMAIL PROTECTED]
ICQ# 10074100
------------------------------
From: [EMAIL PROTECTED] (Robert Nichols)
Subject: Re: why top give false results?
Date: Mon, 10 May 1999 17:12:17 GMT
In article <[EMAIL PROTECTED]>,
Jacek Pop�awski <[EMAIL PROTECTED]> wrote:
: I am not sure if it isn't offopic here... sorry anyway...
: Why 'top' shows false results? For example when I run mpg123 to play
:mp3 on my Cyrix 166+ - it shows 40% cpu usage. When I run x11amp
:to play the same mp3 on the same processor - it shows 20-30% !!! But
:x11amp uses mpg123 to play (!). And why if 50% cpu resources is free
:- sometime when I will do a lot with graphics or even text (!) - music
:breaks for a moment?
: What is good way to know how much cpu is in use at the moment?
"At the moment" the CPU is being used 100% by the program that is
reporting that fact to you. Of course that is not particularly useful
information.
All of the data reported by 'top' and similar programs is simply
statistics gathered by the kernel. That data can be very inaccurate
when there is a lot of I/O activity since properly accounting for time
spent in an interrupt handler is an almost impossible task. Your
choices are pretty much limited to charging that time to whatever
process happened to be running at the time the interrupt came in (which
will most likely be the "idle" process if the system is heavily I/O
bound) or ignoring it. Either way leads to distortions in the reported
CPU usage for individual processes.
--
Bob Nichols [EMAIL PROTECTED]
PGP public key 1024/9A9C7955
Key fingerprint = 2F E5 82 F8 5D 06 A2 59 20 65 44 68 87 EC A7 D7
------------------------------
From: Tsu-Wang Chen <[EMAIL PROTECTED]>
Subject: flash driver and source code for AMD AM29F800B
Date: Mon, 10 May 1999 13:12:46 -0500
Reply-To: [EMAIL PROTECTED]
Does anyone know where I can find the driver binary and source code for
AMD AM29F800B flash memory? If there is no exact match, binary and
source code for similar chips are welcome, too. Thank you for your
attention.
------------------------------
From: bryan <[EMAIL PROTECTED]>
Subject: Re: Reliable (!) nic for 2.2 kernel?
Crossposted-To: comp.os.linux.networking
Date: Mon, 10 May 1999 18:17:21 GMT
In comp.os.linux.networking David Murray <[EMAIL PROTECTED]> wrote:
: Me too.. I have a tulip card and I think it is very, very nice.. I think
: this person's problem is not the card itself but something else in the
: system.
the card is FINE FINE FINE. I repeat ;-)
its the DRIVER under 2.2 that is the killer.
: > That's weird. One of the servers I administer has a tulip card and the
: > server has been up now for 178 days without any problems. Here's some
: > numbers:
: >
: > RX packets:104749300 errors:0 dropped:13 overruns:0
: > TX packets:71530160 errors:4 dropped:0 overruns:4
: >
--
Bryan
------------------------------
From: bryan <[EMAIL PROTECTED]>
Subject: Re: Reliable (!) nic for 2.2 kernel?
Crossposted-To: comp.os.linux.networking
Date: Mon, 10 May 1999 23:26:23 GMT
In comp.os.linux.networking Johan Kullstam <[EMAIL PROTECTED]> wrote:
: hmm all i have is this crappy hub. i have no cross-over cable.
it would be a good test if you could locate one. sometimes its a
'timing thing' and bugs show up with direct connections that buffering
or delaying devices (hubs/routers) might hide.
: sophia(~)# time ping -s 1000 -f euler
: PING euler.axel.nom (172.16.0.2): 1000 data bytes
: ....
if all you got were those dots, over 8 minutes, I'd say that was 'solid' ;-)
: everything still seems rock solid. i was even able to do stuff over
: the telnet session i have going from sophia to euler.
sounds like your system is stable. with that hub in the middle, at
any rate. is that a TRUE hub (repeater) or is it a bridge/switch? if
the latter, then it could buffer and make life easier on the nics.
--
Bryan
------------------------------
Subject: Re: Glibc rant
From: Jan Vroonhof <[EMAIL PROTECTED]>
Date: 10 May 1999 22:06:42 +0200
[EMAIL PROTECTED] (Theodore Y. Ts'o) writes:
> It's not just about open source versus closed source. Even if all the
> software involved was pure open source, users aren't necessarily going
> to want to compile everything themselves, nor will they necessarily want
> to get all of their software from their distribution.
Moreover, recompiling is not always the easy solution. For instance if
you compile any current release of XEmacs under glibc 2.1 the
synchronous subprocesses break in a subtle way (they are no longer
interruptable).
The problem is that glibc's headers define ISETSIG which consfuses
XEmacs into thinking that this is a sysv based SIGPOLL implementation
and it should use iotcl(I_SETSIG) instead of the fcntl way (which
comes from BSD I believe). This is a bug in XEmacs of course, but it
just illustrates the subtle stuff that can happen if you change your
build environment.
Jan
------------------------------
From: Kenneth & Susan <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.networking,linux.redhat.development
Subject: RH 6.0/2.2.5 kernel and problems with sendmsg/recvmsg
Date: Mon, 10 May 1999 18:44:49 -0400
This is a multi-part message in MIME format.
==============6ADF78FB9019DDB657613563
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Hi all,
I've got some code that I used on various UNIX OSs (AIX, 390, HPUX)
and which was working on RedHat 5.2, which uses sendmsg and recvmsg to
pass data over a socketpair between two processes. Problem is, this
code is no longer working on RedHat 6.0; I get an errno of EINVAL when
the sendmsg executes. Has anyone else seen this, and does anyone know
if there might have been an API change (highly unlikely since is UNIX
standard API) or a major rewrite of the socket layer between the RedHat
5.2 release (using the 2.0.36 kernel) and RedHat 6.0 (using the 2.2.5
kernel) which could account for this? At present, it seems to me that
these methods are broken - especially since this code works fine on AIX
4.3.x, HPUX 11.0, OS390, and RedHat 5.2. Any help you can give me would
be greatly appreciated (at present, I'm diving into the 2.2.5 kernel
source looking for answers as well as writing up a test case to
illustrate the bug). Since these groups get so much activity, please cc
any replys to my email (work or home is fine).
Thanks!
Kenneth Brunsen
[EMAIL PROTECTED] (hm)
[EMAIL PROTECTED] (wk)
==============6ADF78FB9019DDB657613563
Content-Type: text/x-vcard; charset=us-ascii; name="vcard.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Kenneth & Susan
Content-Disposition: attachment; filename="vcard.vcf"
begin: vcard
fn: Kenneth & Susan
n: ;Kenneth & Susan
org: Us
email;internet: [EMAIL PROTECTED]
x-mozilla-cpt: ;0
x-mozilla-html: TRUE
version: 2.1
end: vcard
==============6ADF78FB9019DDB657613563==
------------------------------
From: bryan <[EMAIL PROTECTED]>
Subject: Re: tulip driver woes (was Re: Reliable (!) nic for 2.2 kernel?)
Crossposted-To: comp.os.linux.networking
Date: Tue, 11 May 1999 00:32:07 GMT
In comp.os.linux.networking Ronald Cole <[EMAIL PROTECTED]> wrote:
: bryan <[EMAIL PROTECTED]> writes:
: > yes, I always try to have the latest installed. the one that comes
: > with the kernel (.89, I think) is also unsatisfactory.
: Try telling that to the kernel maintainers... It took a bit of
: bitching to get the 0.83 in the 2.1.1xx upgraded to 0.89H (although I
: asked specifically for 0.90 at the time).
I don't necessarily need the -latest- driver, just the most stable in
the 2.2 world. in 2.0.36, things were great. now they're not so
great. what happened in-between?
: Does anyone know if the 0.91 on Becker's site contains support for
: 2.2.x fastroute and hardware flowcontrol?
hw flowcontrol? over 10/100 ethernet? howsat? ;-)
is the fastroute like a hardware cache or something? sounds like some
kind of hw acceleration (?) tell me more..
--
Bryan
------------------------------
From: [EMAIL PROTECTED] (Jonathan A. Buzzard)
Subject: Re: Translation of linux to minor languages
Date: Mon, 10 May 1999 23:34:15 +0000
In article <7h7g91$[EMAIL PROTECTED]>,
"J�rgen Exner" <[EMAIL PROTECTED]> writes:
[SNIP]
>
> Just a few examples:
> - dialog resizing is required and takes over 60% of the actual work,
> provided you have a good WYSIWYG tool to help you. (the suggestion to use
> strings, which are no longer then the EN string doesn't work, don't even
> consider it).
Use the layout manager widgets, they are you friend. If you used layout
manager widget's then length of you text strings is not important anymore.
> - text pieces, which are combined at runtime are a nightmare: "The xxxx
> could not be xxxx, because xxxx" can not be translated, because you are
> combining e.g. Russian text fragments using English grammar.
This is usually bad practice anyway
> - How do you translate directory and file names? You don't? Well, what if
> they appear in the UI?
Why should they appear in the UI?
> - does passwd accepts Japanese or cyrillic characters (or simply say latin
> characters, which are not used in English) as password and/or login name?
> Ooops, that means cyrillic and Japanese directory names in /home. Can "ls"
> deal with them? And can they be found by e.g. a "find -name"?
>
As your user name does not have to represent your real name this is not
important. Why should passwd need to accept Japanese or cyrillic characters?
> And for UNIX you have the additional problem that the output of command line
> commands is often used as the input for the next command in a pipe. So if
> you translate the output of let's say "ls", then you have to re-engineer all
> programs, which possibly read the output of ls and take it as their input.
>
I can see that a user might want to use non latin characters in a file name,
but I don't think that ext2 supports Unicode file names, so this is a
moot point currently. It will however take a massive effort to get
working.
JAB.
--
Jonathan A. Buzzard Email: [EMAIL PROTECTED]
Northumberland, United Kingdom. Tel: +44(0)1661-832195
------------------------------
** 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
******************************
