Linux-Development-Sys Digest #199, Volume #7 Wed, 15 Sep 99 20:14:11 EDT
Contents:
Re: Linux for SGI (Bryan)
Re: cross compile under linux (Vie^.t Nha^n)
HELP & Q : Ethernet device driver (joh jae chul)
Re: UDMA vs IDE: performance comparison wanted (Joseph H Allen)
sendmail trouble: NOQUEUE: SYSERR(root): getrequests: accept: Connection reset by
peer ("Ted Pavlic")
Re: Problem with pcmcia 3.09 source code: MISSING FILE? (Paul J Collins)
Re: unix98 pty's problems (Juergen Heinzl)
Re: Booting Linux on Sparc Classic using Null-Modem Connection for Console. (David
Wragg)
Re: threads (Leslie Mikesell)
Re: Kernel Install Applet (Peter T. Breuer)
skb_queue_head(skb,list,pri) (Fernando Ortega Bellosta)
----------------------------------------------------------------------------
From: Bryan <Bryan@[EMAIL PROTECTED]>
Subject: Re: Linux for SGI
Date: Wed, 15 Sep 1999 21:20:36 GMT
I think the kernel can run reasonably well on most of their r3k r4k
and r5k systems (but not the newer UMA arch like the O2, etc).
the video is the tricky bit, of course. but for command line and
network use, I knew they had it running on indy's and I thought they
had it on indigos, too - maybe just not in so many words on their
page.
not really sure why anyone cares, though ;-) linux on a modern pc is
more supportable, faster and easier to upgrade. and cheaper, too, overall.
Petter Reinholdtsen <[EMAIL PROTECTED]> wrote:
: [Hong Hu]
: > Does anyone know if it is possible to install linux on a old
: > SGI machine? (Say SGI Indigo)--
: [Bryan]
: > www.linux.sgi.com
: >
: > yes, its that obvious ;-)
: Well, actually, they only support Indy at the time. I tried to find
: substitute OS for our Indigo, but failed. :-(
: --
: ##> Petter Reinholdtsen <## | [EMAIL PROTECTED]
--
Bryan, http://www.Grateful.Net - Linux/Web-based Network Management
->->-> to email me, you must hunt the WUMPUS and kill it.
------------------------------
From: Vie^.t Nha^n <[EMAIL PROTECTED]>
Crossposted-To: alt.unix.wizards,comp.os.linux.development.apps
Subject: Re: cross compile under linux
Date: Wed, 15 Sep 1999 21:15:33 GMT
yes, you can use gcc in linux, it must be on the architecture that you
want to run your prog on (e.g alpha/linux; sparc/linux; intel/linux...).
In article <01bee1f6$c1053160$994c05c3@mordor>,
"Antonio" <[EMAIL PROTECTED]> wrote:
> hi, i am a linux user and i'd like to compile a source for a alpha
machine
> running OSF1, Is it possible with gcc, cc or any linux's compiler?
>
> hundred thanks in advance, a.
>
--
Nga`y qua nga`y, sa^`u sa^`u cho^`ng cha^'t.
Sa^`u vi`, ca?nh da^'t nu*o*'c na't tan.
Sa^`u vi`, ca?nh la^`m than da^n kho^?.
O^i! tha^.t kho^?
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: joh jae chul <[EMAIL PROTECTED]>
Subject: HELP & Q : Ethernet device driver
Date: Wed, 15 Sep 1999 16:57:17 -0500
Hi, all. Writing device driver without enough knowledge made my life
miserable... Please enlighten me basic things I am missing :-)
I have been writing a customized device driver for 3c905B ethernet card on
2.0.36. Cards are installed like this:
3c905B (on board) w/ IRQ 11, my driver
Intel EtherPro100 w/ IRQ 11, generic TCP/IP traffic
3c905B (on slot) w/ IRQ 14, my driver
or
3c905B (on board) w/ IRQ 11, my driver
Intel EtherPro100 w/ IRQ 10, generic TCP/IP traffic
3c905B (on slot) w/ IRQ 11, my driver
My driver uses fast interrupt (SA_INTERRUPT), and generic driver uses slow
interrupt of course. Do I have to move the slots so that all the devices
that share an interrupt use either fast interrupt or slow interrupt? What
if I add more cards, and that cards (using my driver) use IRQ that is
already used by other devices with slow interrupt?
Hmm... Is it okey to fix IRQ (using dip switch or jumper, if there is) in
order to share interrupts for all 3c905Bs?
Another question: I heard, in fast interrupt, interrupt is automatically
disabled when entering interrupt handler. Does it mean that I may lose
incoming interrupt from 3c905B(II) if it takes too long processing
interrupt from 3c905B(I)?
There are so many questions, but the only references I have are "Linux
Kernel Internal" and "O'Reilly Device drivers". Are there any other good
references I can find, or web sites?
Thank you.
=============================================================
I didn't know the worst 4-letter-word was "Aiee"
--Jae.
------------------------------
From: [EMAIL PROTECTED] (Joseph H Allen)
Subject: Re: UDMA vs IDE: performance comparison wanted
Date: Wed, 15 Sep 1999 22:00:18 GMT
In article <[EMAIL PROTECTED]>,
Dave Platt <[EMAIL PROTECTED]> wrote:
>In article <[EMAIL PROTECTED]>,
>Philip Brown <[EMAIL PROTECTED]> wrote:
>
>>So, once again: Does anyone have any actual data under linux?
>
>I tested out a Quantum Bigfoot drive on my ASUS P5A motherboard at
>home, running 2.2.10, with and without the busmaster/UDMA kernel patch
>for this motherboard.
>
>The test was a simple one:
>
> dd if=/dev/hda of=/dev/null bs=$((1024*1024)) count=$SOMEBIGNUMBER
>
>The transfer was large enough to greatly exceed the size of physical
>memory, thus minimizing the effect of the Linux buffer cache.
>
>When running in PIO mode, the data transfer darned near flatlined the
>CPU (a K6-2-300 at the time).
>
>When I switched to DMA mode, the CPU usage dropped to about 5-10%, and
>the throughput (bytes per second) almost doubled.
Did you change any 'hdparm' settings before you did this test?
Try: hdparm -m 16 -c 1 -A 1 -W 1 /dev/hda
This makes sure that it's actually reading multiple sectors at a time, that
read ahead is enabled, that 32-bit mode is enabled, and that write caching
is enabled. This usually makes a huge difference if it had not been set,
since Linux makes pessimistic settings by default.
I'm very surprised that the throughput would have doubled- even the simple
programmed interface should be way faster than the actual data rate of the
media (average bytes per track * disk RPM / 60).
--
/* [EMAIL PROTECTED] (192.74.137.5) */ /* Joseph H. Allen */
int a[1817];main(z,p,q,r){for(p=80;q+p-80;p-=2*a[p])for(z=9;z--;)q=3&(r=time(0)
+r*57)/7,q=q?q-1?q-2?1-p%79?-1:0:p%79-77?1:0:p<1659?79:0:p>158?-79:0,q?!a[p+q*2
]?a[p+=a[p+=q]=q]=q:0:0;for(;q++-1817;)printf(q%79?"%c":"%c\n"," #"[!a[q-1]]);}
------------------------------
From: "Ted Pavlic" <[EMAIL PROTECTED]>
Subject: sendmail trouble: NOQUEUE: SYSERR(root): getrequests: accept: Connection
reset by peer
Date: Wed, 15 Sep 1999 18:18:20 -0400
I posted this in comp.mail.sendmail, but didn't receive any responses.
Anyone here have any ideas?
=====
On a machine of mine, frequently I will receive this message in my maillog
regarding an incoming sendmail connection:
Sep 15 12:57:57 ctmail sendmail[265]: NOQUEUE: SYSERR(root): getrequests:
accept: Connection reset by peer
It happens every often, but doesn't happen all the time. A person will
connect to send their mail and will be disconnected from the mail server
immediately and that message will end up in the log file.
sendmail was working fine on an old mail server running RedHat 4.2 with the
sendmail that came with it. Once we converted completely to NAT, (so that
mail server's address became a 10.130.x.x address rather than a normal
Internet address) we started to have this problem. We tried upgrading to the
latest version of sendmail, but that didn't help the problem. So we tried
moving mail server to a COMPLETELY different machine running a completely
different RedHat release with completely different hardware on a completely
different network on a completely different switch... Things worked fine in
the beginnning. Then, after a while, one or two of these messages would
occur. After a longer while, the old problem came back to haunt us on the
COMPLETELY different server. (The only thing alike between the two servers
are the clients that connect to them -- everything dealing with the server
has changed)
A tcpdump from the old system shows a good connection starting out like
this:
(mail.customer.arl.calltech is the mail server -- callweb is a client
machine)
14:34:10.707243 callweb.4131 > mail.customer.arl.calltech.smtp: S
1451122715:145
1122715(0) win 32120 <mss 1460,sackOK,timestamp 110154711[|tcp]> (DF)
14:34:10.719242 mail.customer.arl.calltech.smtp > callweb.4131: S
90875368:90875
368(0) ack 1451122716 win 32736 <mss 1460>
14:34:10.719304 callweb.4131 > mail.customer.arl.calltech.smtp: . ack 1 win
3212
0 (DF)
A tcpdump from the old system shows a bad connection (one that produces the
sendmail error) starting out like this:
14:34:42.806926 callweb.4133 > mail.customer.arl.calltech.smtp: S
1481528582:148
1528582(0) win 32120 <mss 1460,sackOK,timestamp 110157921[|tcp]> (DF)
14:34:42.822687 mail.customer.arl.calltech.smtp > callweb.4133: R 0:0(0) ack
148
1528583 win 0
Any ideas what might be causing this problem?
All the best --
Ted
------------------------------
From: Paul J Collins <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.misc
Subject: Re: Problem with pcmcia 3.09 source code: MISSING FILE?
Date: 15 Sep 1999 23:25:30 +0100
>>>>> "Kenny" == Kenny McCormack <[EMAIL PROTECTED]> writes:
--snip--
Kenny> Note: If you followup on Usenet, be sure to include
Kenny> c.o.l.misc, as that is the only group (to which this has
Kenny> been posted) that I read.
--snip--
This is what the Followup-To: header was invented for.
Paul.
--
Paul Collins <[EMAIL PROTECTED]> Public Key On Keyserver.
Fingerprint: 88BA 2393 8E3C CECF E43A 44B4 0766 DD71 04E5 962C
"I am a stranger in a strange land,
distracted by bright and shiny objects."
------------------------------
From: [EMAIL PROTECTED] (Juergen Heinzl)
Subject: Re: unix98 pty's problems
Date: Wed, 15 Sep 1999 21:17:58 GMT
In article <[EMAIL PROTECTED]>,
Remco van den Berg wrote:
>On Tue, 14 Sep 1999 22:52:12 GMT, Juergen Heinzl wrote:
>>In article <[EMAIL PROTECTED]>,
>>Remco van den Berg wrote:
>>>On Tue, 14 Sep 1999 20:14:51 GMT, Juergen Heinzl wrote:
>>>>
>>>>Now telnet (the client) does not care so the daemon will do. Still stay
>>>>tuned regarding the official versions, mine is just a tiny hack.
>>>>
>>>
>>>Somebody showed me this site:
>>>
>>>ftp://ftp.uk.linux.org/pub/linux/Networking/netkit-devel/
>>>
>>>.. and the telnet daemon there is working out of the box :-)
>
>Just found out that it coredumps on exit. :-(
>.. but it _does_ use the unix98 pty's.
>
>>As I am here already, some other programme that can cause trouble
>>is ddd and here again, the latest version supports Unix98 PTY's.
>
>Guess what: I'm using that tool also. So have to compile that one
>too.
Voila, the right chance to use the latest ddd to debug the latest
telnet daemon 8)
>Any more programs?
Yes. Mind I am not holding back; I've just no list either, so
script for instance (util-linux). Try your talk and screen
binaries too, if in use.
Ta',
Juergen
--
\ Real name : J�rgen Heinzl \ no flames /
\ EMail Private : [EMAIL PROTECTED] \ send money instead /
------------------------------
From: David Wragg <[EMAIL PROTECTED]>
Subject: Re: Booting Linux on Sparc Classic using Null-Modem Connection for Console.
Date: 15 Sep 1999 14:13:22 +0000
[EMAIL PROTECTED] (Nicholas Dronen) writes:
> I've just installed Debian Linux (kernel 2.0.35) on a Sparc Classic.
> A null-modem connection and minicom have provided the console so
> far. The installation seems to have went well.
>
> The problem is that -- from the perspective of the console -- the
> system appears to hang at the following:
>
> VFS: Mounted root (ext2 filesystem) readonly.
> Freeing unused kernel memory: 40k code, 4k data
>
> However, when the last line is printed, the internal scsi disk starts
> to churn, which I take to mean that the system is booting. I imagine
> that the problem is that the console is switching from the serial port
> to some other device, but I don't know that for sure. Is there a
> parameter I can pass to the kernel to work around this? Should I do
> something in the openprom? Anyone know off hand what's happening here?
Yes, I've seen this before. I think 2.0 kernels didn't support a
proper serial console; you get kernel boot messages on the serial port
but nothing else. Perhaps you can telnet into it, but since a telnet
login won't accept root you are stuck.
I recommend installing a distribution with a 2.2 kernel (do Debian
have one yet?). They support a serial console, so that a kernel
command line parameter can set /dev/console to be effectively
equivalent to any of the serial pots. Even better, if you boot a SPARC
machine with the PROM console on a serial port, the kernel will reuse
this as its console, so no kernel parameters are needed, and all boot
message will go to the serial console.
To get a login prompt on the serial console, you need to edit
/etc/inittab. To do this, first boot Linux in single user mode by
doing "boot linux single" at the PROM prompt, so that you get a shell
on /dev/console. In /etc/inittab go to the getty lines, which look
something like
1:2345:respawn:/sbin/mingetty tty1
Comment those out. (When you use a serial console, mingetty seems to
fail on /dev/tty1 etc, causing init to warn warn you that
"/sbin/mingetty respawning too fast").
Then to get a login prompt on the serial line add a line
S0:2345:respawn:/sbin/getty ttyS0 DT9600 vt220
(That's right for RedHat. Perhaps there are slight differences for
other distributions. Check the man page for the getty included, and
read the relevant sections of the Text-Terminal-HOWTO.)
Next, add the line
ttyS0
to /etc/securetty so that it will let you log in as root on the serial
console. Then shutdown and restart, and you should get a login prompt
on the serial console.
You could get a login prompt on the serial line in the same way with
2.0 kernels, but it's a matter of when you can add those lines to
/etc/inittab and /etc/securetty. Maybe you can get a shell towards the
end of the installation process, and then append the lines using
cat. You would still have the disadvantage of not getting all of the
boot messages, so a 2.2 kernel is a better option.
David Wragg
------------------------------
From: [EMAIL PROTECTED] (Leslie Mikesell)
Subject: Re: threads
Date: 15 Sep 1999 13:08:06 -0500
In article <[EMAIL PROTECTED]>,
David Schwartz <[EMAIL PROTECTED]> wrote:
>
> If the system is loaded by other programs, I had better do as much work
>as possible in my timeslice. Otherwise, I'm going to slow those other
>programs down. Or, to put it another way, the more loaded the system is,
>the more work there is to do at any one time.
And the more important it is to let the kernel scheduler wake
up the right task at the right time.
> A single-process model means that you can do more work when there is
>more work to do. A process-per-connection model means that when you have
>more work to do, you incur extra penalties and context switches.
>
> It really is that simple.
I still don't see this in the case where many different programs
are running, each with separate i/o streams, each with inputs
that become ready separately, which is the way I am used to
seeing unix machines run. If a bunch of programs written
to select()/read() each are getting one read()'s worth of
input in round-robin fashion, it has to be more work than
if they just did a blocking read().
> It is. Really. I'm afraid I can't do better than present argumentation
>for why this should be so (fewer blocks, fewer stacks, fewer context
>switches) and point to years of experience that demonstrates that it is.
I can see this might be true for single-purpose machines where
everything is fed to the same program, but I generally don't
do that.
> If another program needs those CPU cycles, then it can have them. And
>while it's using them, a few more packets will arrive. That will allow
>me to do the work of ten connections with fewer expensive system calls
>and fewer context switches. That will make that other program happier.
But you keep ignoring the case where only one other packet arrives
for you and now you have to do another system call to get it, taking
time away from another program whose packet just arrived.
>> > 200 is nothing. Try 5,000. Or 16,000.
>>
>> The nature of the http protocol is such that you don't need to
>> run that many at once unless you are responding slowly and
>> apache has some awkward things happening in accept() that would
>> be a problem long before you see any difference from the
>> rest of the process model.
> I disagree entirely. Suppose you are serving out a 50Mb file to people
>over 33.6 modem connections. Each connection will remain for as long as
>it takes it to get that whole file.
OK, each T1 can usefully feed 60 or so of those slow clients, so
you might want 60 times the number of T1's you have of httpd's
sending at once. I only have 4 so that's still not a big
number.
But, is it a good idea to allow 16,000 TCP connections to a
single box in any case? What is the memory footprint of
the tcp window for all those? What happens when a major
internet router glitch causes a window of packets to
be lost or delayed to the point where you have a complete
window buffered for most of those connections and you
start retransmitting?
Les Mikesell
[EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED] (Peter T. Breuer)
Subject: Re: Kernel Install Applet
Date: 15 Sep 1999 18:24:38 GMT
Reply-To: [EMAIL PROTECTED]
Cocheese ([EMAIL PROTECTED]) wrote:
: After teaching a few crash courses to the other service techs I work with
: about Linux and the programs, I got to thinking about a few "Suggestions".
: Nobody I know personally has ever installed the kernel and lived to
: tell about it. In fact, a friend of mine and I spent an entire week trying
Hmmm .. I assure you that I have installed close on a thousand kernels
and all work (I mean that I followed development from 1.1.something and
have patched kernels up to the eyeballs, and run labs with 200 machines
...)
: and to no such luck. Although I am now using the RPM version to install
: the newest kernels (AND THE DAMN THING STILL DOESN'T TELL THE CORRECT
: VERSION!) I began to think that obviously there is a strong need for a
: program/applet for us "not-so-learned" users.
Uh. Don't use redhat, and don't use rpm. Then you won't have any
problems.
: automatically install a zipped kernel (ex. zip,tar,etc...) through a
: simple command that would run the executable program and compile it?
Sure: rm /usr/src/linux; tar xzvfC linux-foo.tgz /usr/src; ln -s
linux-foo /usr/src/linux; cd /usr/src/linux; cp ../*/linux*/.config .;
make oldconfig; make zImage; make zlilo; make modules; make modules-install;
Hic. That'll be $10.
Werrsa problem?
: If anyone is up to the challenge I assure you many of the
: distribution's would eat that program right up (since they are really
: going all out to make Linux a little more user friendly- thus getting your
: name in the "Program Hall Of Fame" -LOL
: **********************************************************************
: P.S. A good example of something i was thinking would be to type something
: under the console like this:
: KERNEL "/location/kernel_name-2.x.x.tgz"
: **********************************************************************
Eh?
--
Peter
------------------------------
From: Fernando Ortega Bellosta <[EMAIL PROTECTED]>
Subject: skb_queue_head(skb,list,pri)
Date: Fri, 10 Sep 1999 10:53:46 +0200
I am working on a networking module, I want to simulate traffic,
modifying, the devices buffers queues, but when I try to add new packets
to them the whole system goes down.
I am only adding new "sk_buffs", to see what happens with them, but
something is wrong.
Any idea , what am I doing wrong?
Thanks in advance.
--
Fernando Ortega Bellosta
[EMAIL PROTECTED]
------------------------------
** 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
******************************
