Linux-Development-Sys Digest #660, Volume #8 Sat, 21 Apr 01 08:13:12 EDT
Contents:
Re: 82559 Intel Network Chip Driver
2001 USENIX Annual Technical Conference (Becca Sibrack)
Re: type of hard disk ("Cameron Kerr")
lspcmcia
Thoughts on printing best practices?? recommendations?? (David Sims)
Re: Thoughts on printing best practices?? recommendations?? ("Cameron Kerr")
Re: Can Linux kernel ported on supercomputer (using 16 processor) ("Steven J.
Hathaway")
Re: howto properly access serial devices in Perl or C (Jonadab the Unsightly One)
Re: Can Linux kernel ported on supercomputer (using 16 processor) (Lew Pitcher)
Re: Can Linux kernel ported on supercomputer (using 16 processor) ([EMAIL PROTECTED])
Re: A Linux emulator for Linux, does this exist? (Jonadab the Unsightly One)
Re: lspcmcia (Trevor Hemsley)
Re: IO system throughput ([EMAIL PROTECTED])
Re: IO system throughput ([EMAIL PROTECTED])
Re: Can Linux kernel ported on supercomputer (using 16 processor)
([EMAIL PROTECTED])
Re: Can Linux kernel ported on supercomputer (using 16 processor)
([EMAIL PROTECTED])
Re: IO system throughput (Alexander Viro)
----------------------------------------------------------------------------
From: <[EMAIL PROTECTED]>
Subject: Re: 82559 Intel Network Chip Driver
Date: Fri, 20 Apr 2001 17:13:17 -0700
I'll add a little spice to the broth. I have a situation where eepro100.c
(the driver for the 82559) prints out a KERN_ALERT of "eepro100:
wait_for_cmd_done timeout!" and I go thru the source and find that
wait_for_cmd_timeout is waiting on the port it was called with, which is
always called with the argument ioaddr + SCBCmd where SMCCmd is 2 which
maps to the command register in the 82559. There is a status register in the
82559 (SBCStatus at 0), but it is *never* checked to see if the command unit
status is idle (meaning the command is executed). I further see that this
driver works *most* of the time and only fails when transferring a large
file across a 100baseT local LAN. This means, I think that the
non-functional wait_for_cmd_done is timing out (with its hard coded count
down from 1000) is loosing it with a fast processor and a fast network.
So..Gentlemen, my question is "Am I diagnosing the problem correctly with
the eepro100.c driver?".
------------------------------
From: Becca Sibrack <[EMAIL PROTECTED]>
Subject: 2001 USENIX Annual Technical Conference
Date: Fri, 20 Apr 2001 17:15:07 -0700
2001 USENIX Annual Technical Conference
June 25-30, 2001
Marriott Copley Place Hotel
Boston, Massachusetts, USA
http://www.usenix.org/events/usenix01/
==============================================
REGISTER BY May 25, 2001 and Save up to $200!
==============================================
The USENIX Annual Technical Conference has always been the gathering
place for like minds in the computer industry. USENIX �01 provides
tutorials that help master new and important skills and opportunities,
and is a place to meet peers and experts to share solutions to common
problems.
USENIX �01 offers professional-level tutorials, three technical tracks,
an AFS workshop, a GNOME developers conference, an information-laden
vendor exhibition, Birds-of-a-Feather Sessions, Work-in-Progress
Reports, parties and get-togethers for sys admins, programmers, systems
engineers and researchers.
DON�T MISS OUT! Thirty tutorials in all, seventeen brand-new. Here�s a
sampling:
-Network Programming with Perl
-Solaris Administration
-Building Linux Applications
-Large Heterogeneous Networks
-Practice Wireless IP Security
-Running Secure Web Servers
-Network Security
-Advanced Solaris Administration
-Unix Network Programming
-LDAP
Keynote address by Daniel D. Frye, Director of IBM Linux Technology
Center.
Invited Talks on WAP, IP Wireless Networking, Security Aspects of
Napster and Gnutella, Security For E-voting in Public Elections, Virtual
Machines, Online Privacy, Active Content and Secure DNS.
The USENIX Annual Technical Conference Exhibition features ~100
companies, products and services. For more information, please contact
Dana Geffner at [EMAIL PROTECTED]
=====================================================================
------------------------------
From: "Cameron Kerr" <[EMAIL PROTECTED]>
Subject: Re: type of hard disk
Date: Sat, 21 Apr 2001 14:21:13 +1200
You know, its funny, in a lot of linux programs (in my
case libpcap, I think), a lot of this information is
found/set by reading/writing values in the /proc filesystem.
(fscanf is really useful for this, so is popen)
You will probably want to look in /proc/devices,
or check the existence of /proc/ide and /proc/scsi, but
beware that (on my system anyway) that /proc/scsi will
not exist until I load my zip drive module, even though I
have a CD-Writer, which uses the scsi-generic module.
(This may well be because the sg module is autoloading.)
--
Cameron Kerr -- cameron.kerr @ paradise.net.nz
Praise Slackware, our baud and saviour!
--
------------------------------
From: <[EMAIL PROTECTED]>
Subject: lspcmcia
Date: Fri, 20 Apr 2001 19:29:06 -0700
Is there an lspcmcia analogous to lspci and lsusb that someone can point me
at?
------------------------------
From: [EMAIL PROTECTED] (David Sims)
Subject: Thoughts on printing best practices?? recommendations??
Date: Sat, 21 Apr 2001 03:09:51 GMT
Hi folks,
If there's a better place to ask these questions please don't hesitate to
let me know :) .... I am wondering what the future of printing is under
Linux?? Is there any concensus on 'best practices' or any active projects
that are looking
at creating a best practice?? I have used Slackware for years now and
always 'made do' with LPR/LPD included in Slackware.... but recently, I
have been ever more frustrated with the shortcomings of the venerable
LPR/LPD.... Heck, the latest problem is that the MS implementation of LPR
doesn't seem to work with the Linux LPD... Some issue about control
characters....
Do you guys have any thoughts about 'best practices' for printing through
Linux servers with standard unix protocols?? Are there any active projects
working on printing via port 515 (a la lpr/lpd) in a more modern way?? I
know that there are other ways to skin my particular cat (Samba, etc.) but
the basic mechanism (lpr/lpd) shouldn't be so contrary.... I mean, why
can't we have a Unix printing mechanism that works as well in a cross
platform way via the network as any off-the-shelf HP printer does??
TIA for your patience with my tirade...
Any advice as to:
a) proper venue for this type of question (i.e., lpr/lpd)
b) active development efforts currently underway for printing daemons
c) current best practices in the linux community
d) how to make the M$ lpr port print to a Linux lpd queue...
Would be more than welcome at this point.
TIA
Dave Sims
------------------------------
From: "Cameron Kerr" <[EMAIL PROTECTED]>
Subject: Re: Thoughts on printing best practices?? recommendations??
Date: Sat, 21 Apr 2001 16:12:53 +1200
Look to CUPS. It seems to be promising and suited to
todays printers (where drivers are often required for
inkjet printers etc).
--
Cameron Kerr -- cameron.kerr @ paradise.net.nz
Praise Slackware, our baud and saviour!
--
------------------------------
Date: Fri, 20 Apr 2001 21:18:55 -0700
From: "Steven J. Hathaway" <[EMAIL PROTECTED]>
Subject: Re: Can Linux kernel ported on supercomputer (using 16 processor)
Boeing Corporation has resently announced the procurement of a 128 cluster
of Linux computers in a Beowolf supercomputer arrangement. Now That's BIG.
Steve Hathaway
------------------------------
From: [EMAIL PROTECTED] (Jonadab the Unsightly One)
Crossposted-To:
comp.os.linux.hardware,comp.os.linux.development.apps,de.alt.comm.isdn4linux
Subject: Re: howto properly access serial devices in Perl or C
Date: Sat, 21 Apr 2001 05:31:17 GMT
"Bob Parnass, AJ9S" <[EMAIL PROTECTED]> wrote:
> Have you considered using Expect instead of
> Perl or C? It's easier.
A language easier than Perl?
[Adds Expect to languages-to-investigate list.]
- jonadab
------------------------------
From: Lew Pitcher <[EMAIL PROTECTED]>
Subject: Re: Can Linux kernel ported on supercomputer (using 16 processor)
Date: Fri, 20 Apr 2001 22:24:27 -0400
[EMAIL PROTECTED] wrote:
>
> hi,
> Is it possible to port the linux kernel (2.4) to supercomputer consisting
> of 16 processor or more ??
Yes. As of kernel 2.2, SMP with 16 processors was supported. IIRC,
kernel 2.4 extends this to something like 64 processors
> Also can existing kernel is suited for the High Performace Computing ??
Yes.
> My concern is that originally kernel was written for the single processor
> only so will it work nicely with SMP (16 processor) ??
The original kernel was written for a single processor 80386 with no
floatingpoint support and a very limited set of hardware. Since then,
the kernel has been enhanced to support uniprocessor, symmetrical
multiprocessor and networked multiprocessor (via clustering software) on
at least nine different processor architectures (including x86, mips,
power pc, sparc64, and S/390). Your concern is as misplaced as a concern
that you might have to hand crank a Mac truck because the original
automobile didn't support an electric starter.
> Or we need to change the design of kernel ??
Not likely for a while, and certainly not because of the concerns you've
expressed :-)
The linux kernel is good enough for almost any use you might have, and
if you run into problems, you can always join the kernel development
team.
> waiting for answer...
> Deepak.
--
Lew Pitcher
Master Codewright and JOAT-in-training
Registered Linux User #112576
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Can Linux kernel ported on supercomputer (using 16 processor)
Date: Sat, 21 Apr 2001 05:56:39 GMT
"Steven J. Hathaway" <[EMAIL PROTECTED]> writes:
> Boeing Corporation has resently announced the procurement of a 128
> cluster of Linux computers in a Beowolf supercomputer arrangement.
> Now That's BIG.
Maybe. Sun sells Sparc systems that do SMP to the tune of a pretty
significant fraction of that number of CPUs; 64, I think. Two
tricked-out E10Ks might be as big as that "supercomputer."
If it's a cluster of Alphas, _that's_ something; if it's just an array
of 128 high end PCs, with somewhat better networking, that's not.
The point of Beowulfs was to provide a way of getting a lot of
parallelism out of pretty mundane hardware...
--
(reverse (concatenate 'string "gro.gultn@" "enworbbc"))
http://vip.hex.net/~cbbrowne/resume.html
Why are there interstate highways in Hawaii?
------------------------------
From: [EMAIL PROTECTED] (Jonadab the Unsightly One)
Crossposted-To: comp.os.linux.hardware,comp.os.linux.misc
Subject: Re: A Linux emulator for Linux, does this exist?
Date: Sat, 21 Apr 2001 05:31:10 GMT
[EMAIL PROTECTED] (Mario Klebsch) wrote:
> What about hot-swappable programs?
That leads me to a feature I've been thinking about that I'd
like to have...
At some kind of signal from the user, the kernel writes
the entire contents of RAM, plus the CPU registers and
any other relevant data, to a big file on disk, saves
a pointer to this so that it'll see it at boot time,
and then just powers down.
Next boot time, it sees that flag file, loads the big
file off the disk to RAM, restores everything, and
picks up right where it left off, in the middle of
whatever it was doing.
A few things wouldn't work properly when restored,
most notably apps that rely on the outside world
(like internet stuff), printing that's in progress,
and anything that earns its living paying very close
attention to the time of day. Some kinds of external
devices might also have issues.
But most things should be just fine. And it would
be an *extremely* handy feature. You could get to
the other OS for a while, or turn the computer off
and unplug it for an electrical storm, or move
across state lines, or whatever, without having
to finish up all your open tasks.
Okay, I know it would be a lot of work to implement,
so I'm going to go hide now...
- jonadab
------------------------------
From: [EMAIL PROTECTED] (Trevor Hemsley)
Subject: Re: lspcmcia
Date: 21 Apr 2001 08:32:40 GMT
On Sat, 21 Apr 2001 02:29:06, <[EMAIL PROTECTED]> wrote:
> Is there an lspcmcia analogous to lspci and lsusb that someone can point me
> at?
man cardctl
--
Trevor Hemsley, Brighton, UK.
[EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: IO system throughput
Date: Sat, 21 Apr 2001 08:50:16 +0200
Greg Copeland <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] writes:
>> Greg Copeland <[EMAIL PROTECTED]> wrote:
> [snip]
>>
>> > Very cool stuff. NT supports asynchronous file and network I/O. Linux
>> > does not.
>>
>> I was suspecting buzzwords in this terminology, and you are explaining us
>> that it is no more than buzzwords. Suppose that instead of a write, it is a
> Same concept applies. That is, no buzzwords are needed or used. I think it's
> safe to say you don't understand. Saying something is a buzzword just because
> you don't understand isn't fair. At any rate, a read would work like this.
> You issue a read of blah offset with x amount of data. You again, get a tagged
> ID back. Again, you have a signal handler or a callback which is called when
> data is available. Likewise, when the tagged id you desire is available, you
> now know what data it is and how to process it. Nothing odd. Nothing
> vapor ware here. I would like to remind you that this same concept is one of
> the main reasons that SCSI tends to be fast. It supports command tag queueing
> which is the same concept. Again, no buzzwords needed, just simple facts.
> Again, this type of implementation is excellent for heavily data driven
> applications like databases because it's easy for them to defer the read and
> write results until the operation has completed.
OK. I now understand what you mean. You are displacing the work usually
done by the OS on the user space program, assuming the OS provides some
tools, namely the notification of completion of IO.
Indeed data bases programs like to do everything themselves, use raw
disk devices and so on, you say they want also to schedule themselves
their work.
It seems to me that Unix systems provide such features to the general user
who does not want to concern himself with these details. For example
deferring the disk writes as much as possible without loosing too
much on security --> softupdates. Wether the data base writer is able to
do much better i don't know. I have been told that Oracle is not so
fast compared to things like mysql (has more features of course).
--
Michel Talon
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: IO system throughput
Date: Sat, 21 Apr 2001 08:58:13 +0200
Paul Repacholi <[EMAIL PROTECTED]> wrote:
> I can't think of one system that had 'one big lock' on an SMP machine for
> decades. And even in them, interupts and system level threads still could
> run inside the locks in many cases.
I think Linux (first version of SMP) and FreeBSD qualify as systems
with a basic giant lock which have been used to
some degree :)
Of course interrupts can occur if they are not blocked. On all systems
even with giant locks interrupts are blocked only very shortly.
BSDI used a scheme trying to never block interrupts and use locks
instead. This is now ported to FreeBSD.
Solaris is a good performing example of a system with all sorts of
locks, both at a very small granularity, and of larger scope, because
both can be needed for efficiency.
--
Michel Talon
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Can Linux kernel ported on supercomputer (using 16 processor)
Date: Sat, 21 Apr 2001 09:08:33 +0200
[EMAIL PROTECTED] wrote:
> "Steven J. Hathaway" <[EMAIL PROTECTED]> writes:
>> Boeing Corporation has resently announced the procurement of a 128
>> cluster of Linux computers in a Beowolf supercomputer arrangement.
>> Now That's BIG.
> Maybe. Sun sells Sparc systems that do SMP to the tune of a pretty
> significant fraction of that number of CPUs; 64, I think. Two
> tricked-out E10Ks might be as big as that "supercomputer."
And Silicon Graphics sells boxes with 256 processors. Not many
i assume!
> If it's a cluster of Alphas, _that's_ something; if it's just an array
> of 128 high end PCs, with somewhat better networking, that's not.
--
Michel Talon
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Can Linux kernel ported on supercomputer (using 16 processor)
Date: Sat, 21 Apr 2001 09:16:23 +0200
Lew Pitcher <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] wrote:
>>
>> hi,
>> Is it possible to port the linux kernel (2.4) to supercomputer consisting
>> of 16 processor or more ??
> Yes. As of kernel 2.2, SMP with 16 processors was supported. IIRC,
> kernel 2.4 extends this to something like 64 processors
>> Also can existing kernel is suited for the High Performace Computing ??
The question is not if 16 processors were supported, but if the result
was good. From what almost everybody says, the answer is no.
Biprocs were fine, quadriprocs were poor, and the rest disastrous.
With the new version in 2.4 i would like have an appreciation of
the present status. I have been told that SMP support is still far
behind Solaris, but i don't know.
For computing, if you need to run just one multithreaded computation
on a SMP machine, then good SMP is important. If however you have
to run several computations on a SMP machine -and this is frequent-
then even the poorest SMP implementation causes no problem because
there is little kernel activity involved.
--
Michel Talon
------------------------------
From: [EMAIL PROTECTED] (Alexander Viro)
Subject: Re: IO system throughput
Date: 21 Apr 2001 07:48:33 -0400
In article <[EMAIL PROTECTED]>,
Paul Repacholi <[EMAIL PROTECTED]> wrote:
>The problem Linux, and unix in general has is that async IO is at zero
>level in the user code. Chicken and egg to a large degree...
fork() is cheap. _If_ you want async IO let a separate process to do
normal IO to/from shared segment. And "if" above is a pretty serious one -
99% programmers _can't_ write safe asynchronous code. And I mean algorithm
level - like "you should not let two threads of execution add elements
into the same double-linked list unless you protect the critical area".
If that requires considerable amount of thinking, poking around with
debugger, etc. - sorry, but it means that one should stay the fsck out
of any asynchronous code. And for absolute majority of programmers that's
exactly the case. Worse than buffer overflows, worse than inability to
live without garbage collector - most of multithreaded programs are
choke-full of races that should have shown up on the first code review done
by anybody even remotely competent. And yes, I'm talking about code that
had been reviewed and intended for real use. So thank you very much, I'd
rather see async stuff of any kind used only when it's absolutely necessary.
It's bad enough on the kernel side where that stuff _is_ necessary (and
people still manage to fuck up in the mind-boggling ways - destructors
called before removing references from shared data structures, etc.).
In the applications code... <shudder> Been there. seen that, nearly vomited
my guts out while reviewing the crap.
Sigh... Sorry about the rant - just spent an hour dealing with a "Threads!
Are! Wonderful!" duhveloper. Most of that time went on showing him why
this, this and that is _not_ going to work. And yes, the list included
manipulation of the shared data structures without any exclusion, use
of global variables by async code in a way that was completely bogus
_and_ not needed, memory management stuff done in signal handlers and broken
beyond belief. deadlocks "dealt with" by sending SIGKILL if potential
victims made no progress for too long, etc., etc. Finally gave up and
sent him to hell... If Dave Null feels like continuing attempts to educate
this idiot - more power to him.
--
"You're one of those condescending Unix computer users!"
"Here's a nickel, kid. Get yourself a better computer" - Dilbert.
------------------------------
** 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
******************************
