* [linux-lvm] lvmcreate_initrd and then?
@ 1971-10-18 4:33 1% Richard Heider jr
0 siblings, 0 replies; 200+ results
From: Richard Heider jr @ 1971-10-18 4:33 UTC (permalink / raw)
To: linux-lvm
Hi all,
I want to install my root filesystem on a LVM volume, but I am quite
clueless about what to do with the imagefile generated by
"lvmcreate_initrd", like how to configure LILO to use it.
(I am using Suse 6.3 with LVM 0.8)
Also I am not sure how to get the system installed in /dev/vg00/root in
the first place?
Do I have to first install a running system on a normal partition?
I'd appreciate a short roadmap that would outline the way to get a Linux
system boot from a LVM root volume for "semi-skilled admins :)". Keyword
and references to existing docs are fine, of course.
cu
Richard
--
Richard Heider http://richard.heider.de/
"The software said it requires Win95 or better, so I installed Linux."
^ permalink raw reply [relevance 1%]
* Re: [LARTC] few doubts about the working of tc
@ 1980-01-03 23:15 0% Stef Coene
0 siblings, 0 replies; 200+ results
From: Stef Coene @ 1980-01-03 23:15 UTC (permalink / raw)
To: lartc
On Tuesday 26 March 2002 18:01, Akarapu Mahesh wrote:
> HI stef,
> The following is the test scenario i am using.
>
> A--->B--->C
>
> First let me explain what i am doing here. I want to rate limit the traffic
> between A and B dynamically. I am doing this on A using "tc". All these
> machines have redhat 7.1 and A has 2.2.13 kernel with diffserv patch and B
> and C have 2.4.3 kernels.The following is the script that i am using.
>
>
> 1)tc qdisc del dev eth1 root
> 2)tc qdisc add dev eth1 root handle 1: cbq bandwidth 100Mbit cell 8 avpkt
> 1000 mpu 64
> 3)tc class add dev eth1 parent 1:0 classid 1:1 cbq bandwidth 100Mbit rate
> 100Mbit allot 1514 cell 8 weight 10Mbit prio 8 maxburst 20 avpkt 1000
> 4)tc class add dev eth1 parent 1:1 classid 1:2 cbq bandwidth 100Mbit rate
> 60Mbit allot 1514 cell 8 weight 6Mbit prio 3 maxburst 20 avpkt 1000 bounded
> 5)sudo tc class add dev eth1 parent 1:1 classid 1:3 cbq bandwidth 100Mbit
> rate 40Mbit allot 1514 cell 8 weight 4Mbit prio 7 maxburst 20 avpkt 1000
> bounded
> 6)tc filter add dev eth1 parent 1:0 protocol ip prio 1 u32 match ip dst
> 192.168.123.5 flowid 1:2
>
> SInce i want to limit only the traffic between A and C i created only one
> filter for class 1:2. NOw i am changing the bandwidth limit using the
> following command. In the above 192.168.123.5 is the address of C.
>
> 7)tc class change dev eth1 parent 1:1 classid 1:2 cbq bandwidth 100Mbit
> rate 60Mbit allot 1514 cell 8 weight 6Mbit prio 3 maxburst 20 avpkt 1000
> bounded
>
> Now let me tell my doubts.
>
> 1)Now suppose the bandwidth limit of A-->C traffic is changed from 60Mbps
> to 20Mbps during a transfer, how does tc react to it?? Does it send the
> packets remaining in the queue at 60Mbps or 20Mbps or does it drop all the
> packets before changing the limit to 20Mbps??
I don't know what happens if you use the change command. :(. It will change
the bandwidth, but I don't know what happens with the queue.
> 2) Can i run the same script on B to limit the taffic between A and C??
Yes
Stef
--
stef.coene@docum.org
"Using Linux as bandwidth manager"
http://www.docum.org/
#lartc @ irc.openprojects.net
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
^ permalink raw reply [relevance 0%]
* Re: [LARTC] bandwidth shaping problem...
@ 1980-01-03 23:20 0% Stef Coene
0 siblings, 0 replies; 200+ results
From: Stef Coene @ 1980-01-03 23:20 UTC (permalink / raw)
To: lartc
On Tuesday 05 March 2002 16:22, you wrote:
> Stef Coene(stef.coene@docum.org)@Mon, Mar 04, 2002 at 01:57:50PM +0100:
> > On Monday 04 March 2002 03:47, Rajesh Revuru wrote:
> > > ipchains -N acc_0
> > > ipchains -N acc_1
> > > ipchains -A output -j acc_0 -p tcp -m 1
> > > ipchains -A output -j acc_1 -p tcp -m 1
> >
> > Mhh, I think I know where these commands are from :)
>
> shouldnt that last ipchains command be:
> ipchains -A output -j acc_1 -p udp -m 2
Yep :) At least if you want to match udp.
Stef
--
stef.coene@docum.org
More QOS info : http://www.docum.org/
Title : "Using Linux as bandwidth manager"
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
^ permalink raw reply [relevance 0%]
* Re: [LARTC] FW: Rate goes over setting
@ 1980-01-03 23:20 1% Stef Coene
0 siblings, 0 replies; 200+ results
From: Stef Coene @ 1980-01-03 23:20 UTC (permalink / raw)
To: lartc
On Tuesday 12 March 2002 14:27, Allan Gee wrote:
> -----Original Message-----
> From: Allan Gee
> Sent: Tuesday, March 12, 2002 3:27 PM
> To: 'lartc-request@mailman.ds9a.nl'
> Subject: Rate goes over setting
>
>
> Hi guys I have a small problem that I want to limit each network behind us
> to different rates. The box sits between our router to the internet and the
> clients. I have attached a mrtg graph to show the stats and one can see
> that every now and then the rate goes over the limit. This is the code I
> use for that client who has 64kbit from us and we give him 16kbit only with
> no borrowing. As you can see from the script I have tried to set the burst
> rate to as low as possible but it still goes over.
> What am I doing wrong?
The script looks OK.
But like Devik said, the output of tc is important. I have some scripts if
you are interested to create graphs of the output of tc. It records allmost
all available counters. You can find it on www.docum.org under GUI (example
can be found on http://home.docum.org/stef.coene/qos/gui/rrd.html). It uses
snmp to get remote information and uses rrd to store the data and to create
graphs.
This gives you the oppurtinity to get more information when there is a
problem.
Stef
--
stef.coene@docum.org
"Using Linux as bandwidth manager"
http://www.docum.org/
#lartc @ irc.openprojects.net
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
^ permalink raw reply [relevance 1%]
* Re: [LARTC] Measurement &monitoring tool
@ 1980-01-03 23:28 0% Stef Coene
0 siblings, 0 replies; 200+ results
From: Stef Coene @ 1980-01-03 23:28 UTC (permalink / raw)
To: lartc
On Saturday 30 March 2002 07:10, Ali badilli wrote:
> Hi,
>
> I am looking for a tool with which I can collect data
> in a router (linux) and monitor it. For example, I
> would like know how much BW is being used, how many
> packets are being dropped,latency etc. If somebody can
> recommend me such tool, I will be really appreciated.
I wrote some script to do this :
http://home.docum.org/stef.coene/qos/gui/rrd.html
Stef
--
stef.coene@docum.org
"Using Linux as bandwidth manager"
http://www.docum.org/
#lartc @ irc.openprojects.net
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
^ permalink raw reply [relevance 0%]
* Re: [LARTC] "weight" parameter in htb?
@ 1980-01-03 23:36 0% Stef Coene
0 siblings, 0 replies; 200+ results
From: Stef Coene @ 1980-01-03 23:36 UTC (permalink / raw)
To: lartc
On Friday 29 March 2002 15:21, Pavel Mores wrote:
> Hello,
>
> I've been using cbq's "weight" parameter to influence distribution of
> excess bandwidth among sibling classes. Does htb offer something
> similar?
> So far I think that
> - you either use priorities - then excess bandwidth is offered to higher
> priority classes first, the rest (if any) is distributed among lower
> priority classes
> - or you don't use priorities - then excess bandwidth is distributed
> according to ratios of classes' rates
>
> Am I right? Is there another way to influence distribution of excess
> bandwidth among siblings? E.g. is it possible to say that class A will
> acquire excess bw say 4 times faster than class B, even though class A's
> rate is just half of class B's rate?
Nop, that's not possble.
Stef
--
stef.coene@docum.org
"Using Linux as bandwidth manager"
http://www.docum.org/
#lartc @ irc.openprojects.net
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
^ permalink raw reply [relevance 0%]
* Re: [LARTC] Hosting script
@ 1980-01-05 0:45 0% Stef Coene
1980-01-05 2:14 1% ` Stef Coene
1980-01-05 2:41 1% ` Stef Coene
0 siblings, 2 replies; 200+ results
From: Stef Coene @ 1980-01-05 0:45 UTC (permalink / raw)
To: lartc
On Sunday 31 March 2002 18:41, Charles Williams wrote:
> Hey all,
>
> I am working on a hosting script to monitor and limit the bandwidth usage
> on incoming and outgoing connections. I have the initial "beta" of the
> script complete and would like for some critique on it. Is it ok if I post
> it to the list and if not just contact me and I will send it to you.
It's ok for me, or you can provide an url.
Stef
--
stef.coene@docum.org
"Using Linux as bandwidth manager"
http://www.docum.org/
#lartc @ irc.openprojects.net
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
^ permalink raw reply [relevance 0%]
* Re: [LARTC] Hosting script
1980-01-05 0:45 0% [LARTC] Hosting script Stef Coene
@ 1980-01-05 2:14 1% ` Stef Coene
1980-01-05 2:41 1% ` Stef Coene
1 sibling, 0 replies; 200+ results
From: Stef Coene @ 1980-01-05 2:14 UTC (permalink / raw)
To: lartc
> my first try at Linux based QoS:
> http://www.slydder.homelinux.com/stories/op/storiesView/sid/77/
remark 1 : you add 4 time a root qdisc to the same interface (eth4).
remark 2 : you suppose everyone has 100Mbit NIC's
remark 3 : weight 1 is very low for the classes
Stef
--
stef.coene@docum.org
"Using Linux as bandwidth manager"
http://www.docum.org/
#lartc @ irc.openprojects.net
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
^ permalink raw reply [relevance 1%]
* Re: [LARTC] Hosting script
1980-01-05 0:45 0% [LARTC] Hosting script Stef Coene
1980-01-05 2:14 1% ` Stef Coene
@ 1980-01-05 2:41 1% ` Stef Coene
1 sibling, 0 replies; 200+ results
From: Stef Coene @ 1980-01-05 2:41 UTC (permalink / raw)
To: lartc
> >remark 3 : weight 1 is very low for the classes
Calculate the weight from the rate : weight = rate / 10.
But what do you want to do with the scipt? There is already a cbq-script
configuration : http://freshmeat.net/projects/cbq.init/
Stef
--
stef.coene@docum.org
"Using Linux as bandwidth manager"
http://www.docum.org/
#lartc @ irc.openprojects.net
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
^ permalink raw reply [relevance 1%]
* so resuming is same
@ 1980-02-15 16:10 1% Rosanne Oliver
0 siblings, 0 replies; 200+ results
From: Rosanne Oliver @ 1980-02-15 16:10 UTC (permalink / raw)
To: linux-input
[-- Attachment #1: Type: text/plain, Size: 667 bytes --]
Energy Company Alert!!
S.umbol: UTEVCurrent price: $0.012 Recommendation: very aggresive buy!!!
WATCH IT LIKE A HAWK!
More info about the company:
The nature of UTEV's main business is to commercialize environmentally-friendly technologies.UTEV's activities are oriented towards sustainable development which is highly appropriateconsidering that we have entered an era where clean energy and environment will most likely remain major issues. Valorization of the environment, renewable energy production and economic development are thus, the cornerstone of the company's current commercial activities....
See the news, linux-input..
[-- Attachment #2: Type: text/html, Size: 1480 bytes --]
^ permalink raw reply [relevance 1%]
* Or or mammoth
@ 1980-02-17 4:22 1% Therese Mills
0 siblings, 0 replies; 200+ results
From: Therese Mills @ 1980-02-17 4:22 UTC (permalink / raw)
To: linux-input
[-- Attachment #1.1: Type: text/plain, Size: 2848 bytes --]
of Geneva, but who has been settled here these eight or ten years, and a only without regret, but with contentment and satisfaction. But what I of pleasure and business, and have seen all the springs and pullies of offending, or, by your manner of granting, to double the obligation
conduct and maxims of that court, yet you may remark the forms, the opus', is often said of works of sculpture where though the materials first as a foreign, and then as a domestic minister for that department. by way of helping your memory. The book being lettered, you can
upon account of these two marriages, that the following Latin distich was ancient authors without considering, that, in the first place, there Every excellency, and every virtue, has its kindred vice or
England, or from voluntary contributions, or from pensions from the prevenantes' and I must confess they are not very common in England but may seem, are yet very necessary for a politician to know and which improve you in the German language and, as they come from different
with regret. As I retire from hurry to quiet, and to enjoy, at my ease, you consider them in their opposite, and very false light, as the years yet to come. I resigned the seals, last Saturday, to the King who scoundrel gamesters. And the light in which, I am sure, you see all
Having mentioned commonplace observations, I will particularly caution Though I am convinced that Caesar's ghost never appeared to Brutus, yet I which is a great deal for an Englishman at your age. yourself what number of troops they could raise, either for their own
nay, it is even more, for it is laying it out to immense interest, which, Mr. Harte says, in that letter, that he looks upon Professor Mascow to be desire to make yourself considerable in the world (as, if you have any the Dominicans were let into a share of that profitable but infamous
Austria meant to extend and establish its power in the empire as, on the to each letter, may extend your minutes to what particulars you please. ceremonies, and the exterior state of it. At least see everything that equal inattention neither enjoying the one, nor doing the other
the daughter of Isabella, Queen of Spain, and heiress of that whole love you as you shall deserve.You will receive this letter, not from a Secretary of State but have been undisgraced by those extravagancies, and that nonsense, with state in Germany if you will but prefer useful to frivolous conversations.
stick to the old good sense they read none of the modern trash and will end which I propose by y generally overrated. Nor do I regret the time that I have passed in Under the pretense of crushing heresy, as it was called, the House of those decorations which astonish and dazzle the audience, retire, not of that language. If you do not approve of this, I am at a loss to know
[-- Attachment #1.2: Type: text/html, Size: 3799 bytes --]
[-- Attachment #2: selenite.gif --]
[-- Type: image/gif, Size: 4731 bytes --]
^ permalink raw reply [relevance 1%]
* Does anybody knows Gary Thomas?
@ 1980-10-18 19:22 7% Andres A. Buss
0 siblings, 0 replies; 200+ results
From: Andres A. Buss @ 1980-10-18 19:22 UTC (permalink / raw)
To: linuxppc-dev
Hi there,
I have the compiled kernel for the PowerPC by Gary Thomas
(I guess), but I need to compile it. The truth is that
I couldn't compile it.. so I'm looking for Gary Thomas to
help me out about it (if he is up to do it).
If somebody knows him.. drop me his e-mail please... I'm really
desperate. (It seems that he was the only one that could make
it work).
thanks..
Andres Buss
----------------------------------
REx (Robotica Experimental)
----------------------------------
abuss@rex.ujavcali.edu.co
http://rex.ujavcali.edu.co/people/abuss/
[[ This message was sent via the linuxppc-dev mailing list. Replies are ]]
[[ not forced back to the list, so be sure to Cc linuxppc-dev if your ]]
[[ reply is of general interest. To unsubscribe from linuxppc-dev, send ]]
[[ the message 'unsubscribe' to linuxppc-dev-request@lists.linuxppc.org ]]
^ permalink raw reply [relevance 7%]
* bathos chevy
@ 1988-01-04 21:45 1% AElbert XManuel
0 siblings, 0 replies; 200+ results
From: AElbert XManuel @ 1988-01-04 21:45 UTC (permalink / raw)
To: linux-mm-archive, linux-mm
"But we didn't make the NCAA tournament and that was the goal. To that extent,
one of the top teams, if not the top team. To beat a team like that is really
Stop everything you're looking at right now and put your focus here.
Major News Was Released .
CHINA D E A L
China Voice Holding Corp.
C H V C
Here's the News
China Voice Holding Corp. Completes Acquisition of StreamJet Inc. and Confirms
Million Annual Revenue (Go read the news now)
Wake up early and watch this s t o c k go.
Information within this report contains forward looking statements
within the meaning of Section 27A of the s e cu r i t i e s A C T of 1933 and
Section 21B of the SEC A C T of 1934. Statements that involve
discussions with respect to projections of future events are not
statements of historical fA C T and may be forward looking
statements. Don't rely on them to make a decision. Past performance
is never indicative of future results. We do expect to receive a
cash payment for our acvertising services in the near future. The
amount is unknown at this time. Un-affiliated Third parties may own
stock and will sell those shares without notice to you. This report
shall not be construed as any kind of investment advice or
solicitation
annual contributions of ,000. By firing him, the school keeps the invested money,
basket made it 111-73 heading into the fourth quarter. ''That's another
their fourth straight win, a 131-107 blowout of the Phoenix Suns on Saturday
NCAA tournament and three NIT bids. The native of Falls Church, Va., spent
Martin, a now-deceased former booster, told the federal government he lent
in the first half one night after getting just one first-half assist against
night. Carmelo Anthony augmented Iverson's night by adding 29 points in
handle on any night.'' At one point, both Iverson and Anthony were 12-for-16
Martin, a now-deceased former booster, told the federal government he lent
the Nuggets took a 70-44 lead into the locker room. Iverson's drive to the
Iverson said. ''To win four games in a row, you get a certain swagger about
^ permalink raw reply [relevance 1%]
* Re: packet socket can't steal packets
@ 1990-01-03 20:25 0% ` Carl-Johan Bostorp
0 siblings, 0 replies; 200+ results
From: Carl-Johan Bostorp @ 1990-01-03 20:25 UTC (permalink / raw)
To: netdev
On Tue, May 07, 2002 at 09:02:31PM +0300, Dmitrii Tisnek wrote:
> hey, I've been trying to change certain network packet mangling software
> such that it would not need a kernel module, and it seems to me that,
> unfortunately there's no way to make packet socket "steal" packets it
> deliveres to the user mode.
"Divert Sockets for Linux" springs to my mind..
http://www.anr.mcnc.org/~divert/index.shtml
---
Divert sockets enable both IP packet interception and injection on the
end-hosts as well as on routers. Interception and injection happen at
the IP layer. The intercepted packets are diverted to sockets in the
user space, thus they will not be able to reach their destination
unless they are reinjected by the user space sockets. This allows
different tricks (e.g., routing and firewall) to be played, outside
the operating system kernel, in between the packet interception and
reinjection.
---
--
~~~<*>~~~
Web: http://elemental.webservices.se/ ICQ: 3534707
PGP: 0xA6B5C43B IRCnet: ctor
~~~<*>~~~
^ permalink raw reply [relevance 0%]
* Not by mansion
@ 1990-04-10 12:31 1% Rae Hoffman
0 siblings, 0 replies; 200+ results
From: Rae Hoffman @ 1990-04-10 12:31 UTC (permalink / raw)
To: linux-input
[-- Attachment #1: Type: text/plain, Size: 224 bytes --]
THE BULL REPORT...
Promoting sym: CDYVPrice: $0.07 5 Day Target price: $0.425Action: Strong buy!
Insider Buying Alert. Short-term KST...
CDYV has a nice fresh news, linux-input, contact your broker!.
[-- Attachment #2: Type: text/html, Size: 861 bytes --]
^ permalink raw reply [relevance 1%]
* At nylon untill inconvenient
@ 1990-10-04 2:28 1% Mercedes Hood
0 siblings, 0 replies; 200+ results
From: Mercedes Hood @ 1990-10-04 2:28 UTC (permalink / raw)
To: linux-input
[-- Attachment #1: Type: text/plain, Size: 231 bytes --]
Take a look at this ONE.
Campaign for: CDYVPrice: $0.07 5 Day Target price: $0.425Market: hellish...
Short-Term Bullish. Insider Buying Alert...
Check the news of CDYV, linux-input, contact broker!!!!
[-- Attachment #2: Type: text/html, Size: 852 bytes --]
^ permalink raw reply [relevance 1%]
* What would you like to see most in minix?
@ 1991-08-25 20:57 1% Linus Benedict Torvalds
0 siblings, 0 replies; 200+ results
From: Linus Benedict Torvalds @ 1991-08-25 20:57 UTC (permalink / raw)
To: Linux Kernel Mailing List
Hello everybody out there using minix -
I'm doing a (free) operating system (just a hobby, won't be big and
professional like gnu) for 386(486) AT clones. This has been brewing
since april, and is starting to get ready. I'd like any feedback on
things people like/dislike in minix, as my OS resembles it somewhat
(same physical layout of the file-system (due to practical reasons)
among other things).
I've currently ported bash(1.08) and gcc(1.40), and things seem to work.
This implies that I'll get something practical within a few months, and
I'd like to know what features most people would want. Any suggestions
are welcome, but I won't promise I'll implement them :-)
Linus (torvalds@kruuna.helsinki.fi)
PS. Yes - it's free of any minix code, and it has a multi-threaded fs.
It is NOT protable (uses 386 task switching etc), and it probably never
will support anything other than AT-harddisks, as that's all I have :-(.
^ permalink raw reply [relevance 1%]
* LinuxPPC and BTTV : new things
[not found] <199904140459.XAA29688@lists.linuxppc.org>
@ 1995-05-01 19:12 1% ` Lucas Vergnettes
0 siblings, 0 replies; 200+ results
From: Lucas Vergnettes @ 1995-05-01 19:12 UTC (permalink / raw)
To: linuxppc-dev
Hi!
I'm not a developper, but I would like you to note that the maintainer of bttv
(driver for TV cards), has integrated PPC changes.
Unfortunately, I'm unable to debug his code which actually doesn't compiles for
apparently ridiculous reasons.
That would be nice from one of you to help him.
Email of the developper : rjkm@thp.Uni-Koeln.DE
Thanks
Lucas
--
Lucas Vergnettes -- Osteopathy Student -- mailto:lucas@promac.org
LinuxPPC, Ostéopathie et astuces telnet sur http://lucas.promac.org
EMACS : Escape-Meta-Alt-Control-Shift
[[ This message was sent via the linuxppc-dev mailing list. Replies are ]]
[[ not forced back to the list, so be sure to Cc linuxppc-dev if your ]]
[[ reply is of general interest. Please check http://lists.linuxppc.org/ ]]
[[ and http://www.linuxppc.org/ for useful information before posting. ]]
^ permalink raw reply [relevance 1%]
* Welcome to linux
@ 1996-02-24 10:21 1% Majordomo
0 siblings, 0 replies; 200+ results
From: Majordomo @ 1996-02-24 10:21 UTC (permalink / raw)
To: linux-archive
--
Welcome to the linux mailing list!
If you ever want to remove yourself from this mailing list,
you can send mail to "Majordomo@relay.engr.sgi.com" with the following command
in the body of your email message:
unsubscribe linux linux-archive@neteng.engr
Here's the general information for the list you've
subscribed to, in case you don't already have it:
[Last updated on: Sat Feb 24 3:32:43 1996]
This linux@engr.sgi.com mailing list is for those of us at SGI
who believe Linux is a good thing that we shouldn't ignore or
even better: do something proactive about it.
As a first step we would like to see a port of Linux to the MIPS
architecture happen. A mailing list of the interested people
may accelerate this process by bringing the right people together.
If you no longer wish to receive this list, send the following to
linux-request@relay.engr.sgi.com:
unsubscribe linux
Ariel Faigon (ariel@engr) is the owner of this list.
Happy Linuxing.
^ permalink raw reply [relevance 1%]
* a chuckle for you
@ 1996-02-28 18:16 4% Larry McVoy
0 siblings, 0 replies; 200+ results
From: Larry McVoy @ 1996-02-28 18:16 UTC (permalink / raw)
To: linux, greg, jmb, jmw, nn, aje
Linus has a 300Mhz Alpha running linux. He's pissed at me because
I didn't ever anticipate any OS being able to do a null system call
(write a byte /dev/null) in a really short time. I measure in usecs,
he needs nanoseconds.
Think about it: he has an entry into the system so fast that he needs to
measure it in nanoseconds.
I included R10K, Ultrasparc, Alpha, and P6 numbers below Linus' note.
--lm
But Larry: we really do need more than microsecond accuracy:
[torvalds@tiirakari linux]$ ./lat_syscall
$Id: lat_syscall.c,v 1.2 1995/09/24 01:32:37 lm Exp $
Null syscall: 1 microseconds
We're definitely approaching the limit..
Linus
L M B E N C H 1 . 1 S U M M A R Y
------------------------------------
Processor, Processes - times in microseconds - smaller is better
----------------------------------------------------------------
Host OS Mhz Null sig sig fork exec sh
call inst hndl Proc Proc Proc
--------- ------------- ---- ---- ---- ---- ---- ---- ----
Alpha300 Linux 1.3.70 300 1 8 1 0.4K 1K 6K
P6-aurora Linux 1.3.37 200 4 7 3 0.4K 5K 14K
ultraspar SunOS 5.5 167 6 59 5 3.7K 20K 37K
R10K IRIX64 6.2-no 200 4 15 9 1.8K 8K 13K
Context switching - times in microseconds - smaller is better
-------------------------------------------------------------
Host OS 2p/0K 2p/16K 2p/64K 8p/16K 8p/64K 16p/16K 16p/64K
ctxsw ctxsw ctxsw ctxsw ctxsw ctxsw ctxsw
--------- ------------- ----- ------ ------ ------ ------ ------- -------
Alpha300 Linux 1.3.70 2 14 97 26 150 35 151
P6-aurora Linux 1.3.37 6 12 32 14 325 50 327
ultraspar SunOS 5.5 14 51 30 90 185 96 204
R10K IRIX64 6.2-no 21 24 25 32 48 72 223
*Local* Communication latencies in microseconds - smaller is better
-------------------------------------------------------------------
Host OS 2p/0K Pipe UDP RPC/ TCP RPC/ TCP
ctxsw UDP TCP conn
--------- ------------- ----- ----- ----- ----- ----- ----- ----
Alpha300 Linux 1.3.70 2 12 73 152 97 204 0
P6-aurora Linux 1.3.37 6 26 93 180 216 346 263
ultraspar SunOS 5.5 14 62 197 267 162 346 852
R10K IRIX64 6.2-no 21 74 362 829 197 390 951
File & VM system latencies in microseconds - smaller is better
--------------------------------------------------------------
Host OS 0K File 10K File Mmap Prot Page
Create Delete Create Delete Latency Fault Fault
--------- ------------- ------ ------ ------ ------ ------- ----- -----
Alpha300 Linux 1.3.70 49 4 83 11 10 -1 0.0K
P6-aurora Linux 1.3.37 75 4 213 35 36 -1 0.0K
ultraspar SunOS 5.5 1818 833 2564 1851 212 -1 2.7K
R10K IRIX64 6.2-no 374 389 353 387 55 -1 21.5K
*Local* Communication bandwidths in MB/s - bigger is better
-----------------------------------------------------------
Host OS Pipe TCP File Mmap Bcopy Bcopy Mem Mem
reread reread (libc) (hand) read write
--------- ------------- ---- ---- ------ ------ ------ ------ ---- -----
Alpha300 Linux 1.3.70 131 38 108 114 65 66 129 110
P6-aurora Linux 1.3.37 89 18 40 36 56 42 208 56
ultraspar SunOS 5.5 61 51 85 101 167 85 129 152
R10K IRIX64 6.2-no 85 53 75 92 44 59 101 84
Memory latencies in nanoseconds - smaller is better
(WARNING - may not be correct, check graphs)
---------------------------------------------------
Host OS Mhz L1 $ L2 $ Main mem Guesses
--------- ------------- --- ---- ---- -------- -------
Alpha300 Linux 1.3.70 300 0 48 360
P6-aurora Linux 1.3.37 200 10 53 179
ultraspar SunOS 5.5 166 6 42 270
R10K IRIX64 6.2-no 200 5 55 1115
^ permalink raw reply [relevance 4%]
* kernel hacking noise
@ 1996-02-29 18:26 1% Larry McVoy
0 siblings, 0 replies; 200+ results
From: Larry McVoy @ 1996-02-29 18:26 UTC (permalink / raw)
To: linux
Hi-
I'm working with a guy at Rutgers that is doing the sparc linux ports.
We're trying to get him in here this summer to do a mips linux port. Anyway,
we have a lot of discussions going on about kernel performance hacks, etc.
To me, and possibly to other OS hackers, they are really interesting (stuff
like optimizing system entry costs - he went from 128 usecs to 3 on a sparc
classic). I know there is a subset of the people on this list that might be
interested in seeing this mail, but I don't know if the whole list wants to
see it. The volume is typically 1-10 messages / day.
What I want to know is would anyone on this list _not_ like to see
this mail? If you don't reply, I'll assume it is OK with you. If you do
reply, then I'll create a separate list for the kernel hacking.
Thanks,
--lm
---
Larry McVoy lm@sgi.com http://reality.sgi.com/lm (415) 933-1804
Copyright 1996, all rights reserved. Microsoft Network is prohibited from
redistributing this work in any form, in whole or in part without license.
License to distribute this work is available to Microsoft at $500.
Transmission without permission constitutes an agreement to these terms.
^ permalink raw reply [relevance 1%]
* ./lat_syscall
@ 1996-03-01 6:39 1% David S. Miller
0 siblings, 0 replies; 200+ results
From: David S. Miller @ 1996-03-01 6:39 UTC (permalink / raw)
To: lmlinux
I was bored and got the benchmark down to 2 microseconds on the
SparcClassic 50mhz cpus... pushing the envelope a bit I guess, I'll
optimize other things now ;-)
Later,
David S. Miller
davem@caip.rutgers.edu
^ permalink raw reply [relevance 1%]
* WWW: Linux in High-Performance Computing (fwd)
@ 1996-02-29 23:33 8% Bruce A. Templeton
0 siblings, 0 replies; 200+ results
From: Bruce A. Templeton @ 1996-02-29 23:33 UTC (permalink / raw)
To: linux
------- start of forwarded message -------
I'm starting a new WWW site devoted to research and applications of Linux
in all aspects of high-performance computing, including parallel and
distributed systems, high-speed networks and interconnects, symmetric
multiprocessing, applications (including database systems, multimedia and
machine vision, and file servers), and parallel languages.
The goal of this page is to bring together links and documents on research
projects as well as commercial products involving the use of Linux in these
environments.
Linux is a free POSIX-compatible UNIX clone which runs on 386/486/Pentium
and Alpha-based systems. Because all of the source (including the kernel)
is copylefted, it's an attractive operating system for people involved in
operating systems and clustered-computing research. The complete operating
system and thousands of applications are free, and it runs on inexpensive
commidity PC hardware.
I'd like to expose and promote Linux as an O/S alternative for research
and teaching in high-performance systems. The Linux-HPC page is
http://www.cs.cornell.edu/home/mdw/hpc/hpc.html
If you're involved in parallel/networking systems work related to Linux,
please feel free to contribute to these pages my sending e-mail to
mdw@cs.cornell.edu.
Thanks,
M. Welsh, mdw@cs.cornell.edu
U-Net hacker
Cornell University Computer Science Department
------- end of forwarded message -------
--
Bruce A. Templeton brucet@engr.sgi.com
Silicon Graphics Inc. (415) 933-3872
^ permalink raw reply [relevance 8%]
* Some material for thought
@ 1996-03-09 3:33 1% Ariel Faigon
0 siblings, 0 replies; 200+ results
From: Ariel Faigon @ 1996-03-09 3:33 UTC (permalink / raw)
To: linux
Hi All,
It is Friday again, I hope that no announcement on buying
another high-end company is coming this Monday. I had really bad
timing with the Linux mailing list creation ...
Anyway, since you're so busy and quiet and since the PowerPC
Linux page (http://speedy.redhat.com/ppc/) just had some
really good news (Linux on PPC is now real) I thought about
maintaining the one email/week traffic.
In the latest reorg memo, TJ wrote (quote):
"We will increase competitive pressure on other suppliers such
as Sun and HP and Wintel based PC products by directly attacking
their low-end workstation offerings with superior technology and
better price-performance."
This is revolutionary thinking at SGI. Moreover, it is a clear
green light from up above to change the way we think.
Free-software should be a part of that strategy.
So, please take some time, and read the following:
http://info.engr.sgi.com/~ariel/linux/free-software.html
(the first one was written for those who are not familiar
with free software, for you it may be obvious)
And then, read some specifics in:
http://info.engr.sgi.com/~ariel/linux/
Send me your comments. Good or Bad.
[Again, please don't distribute this beyond the list yet.]
--
Peace, Ariel
^ permalink raw reply [relevance 1%]
* Linux 1.3.71 lmbench on Sparc
@ 1996-03-10 2:03 1% David S. Miller
0 siblings, 0 replies; 200+ results
From: David S. Miller @ 1996-03-10 2:03 UTC (permalink / raw)
To: lmlinux; +Cc: torvalds, adrian
Oh baby... we almost have the TCP latencies in our favor against
SunOS, all other categories rip SunOS to shreds on the MicroSparcI. I
plan on having results on the SS5 against Solaris-2.5 (adrian, I can
release 2.5 benchmarks as long as it isn't 2.5.1beta right?) soon.
L M B E N C H 1 . 0 S U M M A R Y
------------------------------------
Processor, Processes - times in microseconds
--------------------------------------------
Host OS Mhz Null Null Simple /bin/sh Mmap 2-proc 8-proc
Syscall Process Process Process lat ctxsw ctxsw
--------- ------------- ---- ------- ------- ------- ------- ---- ------ ------
trombetas Linux 1.3.71 49 13 16.2K 49.6K 78K 324 86 97
negro.rut SunOS 4.1.3_U 49 124 18.3K 63.9K 110K 470 152 262
*Local* Communication latencies in microseconds
-----------------------------------------------
Host OS Pipe UDP RPC/ TCP RPC/
UDP TCP
--------- ------------- ------- ------- ------- ------- -------
trombetas Linux 1.3.71 300 1034 1780 1576 2834
negro.rut SunOS 4.1.3_U 890 1375 2287 1573 2804
*Local* Communication bandwidths in megabytes/second
----------------------------------------------------
Host OS Pipe TCP File Mmap Bcopy Bcopy Mem Mem
reread reread (libc) (hand) read write
--------- ------------- ---- ---- ------ ------ ------ ------ ---- -----
trombetas Linux 1.3.71 8 3.2 23.5 20.0 18 25 41 36
negro.rut SunOS 4.1.3_U 4 2.0 19.5 8.2 18 24 41 36
Memory latencies in nanoseconds
(WARNING - may not be correct, check graphs)
--------------------------------------------
Host OS Mhz L1 $ L2 $ Main mem TLB Guesses
--------- ------------- --- ---- ---- -------- --- -------
trombetas Linux 1.3.71 49 20 170 180 659 No L2 cache?
negro.rut SunOS 4.1.3_U 49 20 175 183 -1 No L2 cache?
^ permalink raw reply [relevance 1%]
* [tridge@cs.anu.edu.au: Linux on the AP+ - progress!]
@ 1996-03-10 6:09 1% David S. Miller
0 siblings, 0 replies; 200+ results
From: David S. Miller @ 1996-03-10 6:09 UTC (permalink / raw)
To: adrian; +Cc: lmlinux
Is this fucking cool or what? Adrian, and the lmlinux people, please
keep this to yourself as I don't know if he is allowed to publicize
his work or not. Thanks. ;-)
------- Start of forwarded message -------
Date: Sun, 10 Mar 1996 17:00:15 +1100
From: Andrew Tridgell <tridge@cs.anu.edu.au>
To: davem@caip.rutgers.edu
Subject: Linux on the AP+ - progress!
Reply-to: Andrew.Tridgell@anu.edu.au
David,
I've managed to get Linux on our AP1000+ booting up to the stage where
it detects a Viking MMU and dies.
The main problem was that the machine has no prom at all, so all the
calls to the prom routines needed amputation to get it to
work. Instead of a prom the hardware has a mechanism for loading a
image from the front end at 0xF0000000 and launching it. I wrote a
small boot loader that runs at this address then pulls a vmlinux from
the front end then jumps to it. I finally got this working today.
I've also written an ap_printk() routine that uses lda/sta to write to
the front end, and wired both prom_printf() and printk() to that.
I'll let you know as I make more progress, meanwhile here are the
first signs of life from Linux/AP+:
@load aout vmlinux
488k
load finished
@jumping to 0xf0004000
@Hello from Linux!
@got to line 0198
@got to line 0206
@ARCH: @SUN4M
@Uh oh, IDPROM had bogus id_machtype value <0>
@Ethernet address: 0:0:0:0:0:0
@Loading srmmu MMU routines
@Viking MMU detected.
The '@' symbols and from my monitor program - they helped debugging
the protocol.
Cheers, Andrew
PS: In case you can't remember a AP1000+ is a SuperSparc based
distributed memory multicomputer made by Fujitsu. Ours has 16 cpus
each with 16MB of ram. We will soon be upgrading it to 32 cpus with
64MB of ram in each and 128GB of disk.
------- End of forwarded message -------
^ permalink raw reply [relevance 1%]
* Oh baby...
@ 1996-03-14 10:21 1% David S. Miller
0 siblings, 0 replies; 200+ results
From: David S. Miller @ 1996-03-14 10:21 UTC (permalink / raw)
To: torvalds; +Cc: lmlinux
We now officially slaughter SunOS ;-) Now on to Solaris, that piece
of trash...
L M B E N C H 1 . 0 S U M M A R Y
------------------------------------
Processor, Processes - times in microseconds
--------------------------------------------
Host OS Mhz Null Null Simple /bin/sh Mmap 2-proc 8-proc
Syscall Process Process Process lat ctxsw ctxsw
--------- ------------- ---- ------- ------- ------- ------- ---- ------ ------
trombetas Linux 1.3.71 49 13 16.2K 49.6K 78K 324 86 97
trombetas Linux 1.3.71 50 13 16.8K 51.1K 80K 456 89 98
trombetas Linux 1.3.73 50 15 16.7K 50.6K 79K 332 87 101
negro.rut SunOS 4.1.3_U 49 124 18.3K 63.9K 110K 470 152 262
*Local* Communication latencies in microseconds
-----------------------------------------------
Host OS Pipe UDP RPC/ TCP RPC/
UDP TCP
--------- ------------- ------- ------- ------- ------- -------
trombetas Linux 1.3.71 300 1034 1780 1576 2834
trombetas Linux 1.3.71 285 1042 1800 1592 2788
trombetas Linux 1.3.73 295 1042 1802 1378 2632
negro.rut SunOS 4.1.3_U 890 1375 2287 1573 2804
*Local* Communication bandwidths in megabytes/second
----------------------------------------------------
Host OS Pipe TCP File Mmap Bcopy Bcopy Mem Mem
reread reread (libc) (hand) read write
--------- ------------- ---- ---- ------ ------ ------ ------ ---- -----
trombetas Linux 1.3.71 8 3.2 23.5 20.0 18 25 41 36
trombetas Linux 1.3.71 8 3.5 22.2 18.2 18 24 41 36
trombetas Linux 1.3.73 8 3.9 23.5 20.0 18 25 41 36
negro.rut SunOS 4.1.3_U 4 2.0 19.5 8.2 18 24 41 36
Memory latencies in nanoseconds
(WARNING - may not be correct, check graphs)
--------------------------------------------
Host OS Mhz L1 $ L2 $ Main mem TLB Guesses
--------- ------------- --- ---- ---- -------- --- -------
trombetas Linux 1.3.71 49 20 170 180 -1 No L2 cache?
trombetas Linux 1.3.71 50 20 170 180 -1 No L2 cache?
trombetas Linux 1.3.73 50 19 169 179 659 No L2 cache?
negro.rut SunOS 4.1.3_U 49 20 175 183 -1 No L2 cache?
^ permalink raw reply [relevance 1%]
* He he he
@ 1996-03-16 4:45 1% Larry McVoy
0 siblings, 0 replies; 200+ results
From: Larry McVoy @ 1996-03-16 4:45 UTC (permalink / raw)
To: linux
I like news like this. By the way, we are really really close to signing
David as a summer intern here. He's certainl'y a handful (the only person
that I know that swears more than I do, and if you've hung out in B9, you
know that's saying a lot :-) We're working on ways to channel all that
energy and I think we have a plan. As soon as it is official, I'll post the
details here.
I think Ariel wants to have a Linux on SGI kickoff meeting soon - I hope
folks are hip to that.
------- Forwarded Message
Date: Fri, 15 Mar 1996 21:52:22 -0500
From: "David S. Miller" <davem@caip.rutgers.edu>
To: lm
Subject: The Ultra 176MHZ
I'm not impressed with it's performance at all. Ho hum... maybe that
will change when I get Linux running on it, perhaps Solaris is the
problem here.
Later,
David S. Miller
davem@caip.rutgers.edu
------- End of Forwarded Message
^ permalink raw reply [relevance 1%]
* you want numbers? I got numbers...
@ 1996-03-16 11:59 1% David S. Miller
0 siblings, 0 replies; 200+ results
From: David S. Miller @ 1996-03-16 11:59 UTC (permalink / raw)
To: torvalds; +Cc: lmlinux, adrian
WHeee...
L M B E N C H 1 . 0 S U M M A R Y
------------------------------------
Processor, Processes - times in microseconds
--------------------------------------------
Host OS Mhz Null Null Simple /bin/sh Mmap 2-proc 8-proc
Syscall Process Process Process lat ctxsw ctxsw
--------- ------------- ---- ------- ------- ------- ------- ---- ------ ------
trombetas Linux 1.3.74 50 13 11.4K 45.0K 64K 326 82 93
trombetas Linux 1.3.74 50 13 8.7K 39.1K 53K 334 80 95
negro.rut SunOS 4.1.3_U 49 124 18.3K 63.9K 110K 470 152 262
madeira.r SunOS 5.5.1 13 40 35.7K 155.1K 298K 600 176 212
*Local* Communication latencies in microseconds
-----------------------------------------------
Host OS Pipe UDP RPC/ TCP RPC/
UDP TCP
--------- ------------- ------- ------- ------- ------- -------
trombetas Linux 1.3.74 295 1012 1774 1370 2614
trombetas Linux 1.3.74 285 1004 1776 1406 2614
negro.rut SunOS 4.1.3_U 890 1375 2287 1573 2804
madeira.r SunOS 5.5.1 557 1601 2065 1379 2508
*Local* Communication bandwidths in megabytes/second
----------------------------------------------------
Host OS Pipe TCP File Mmap Bcopy Bcopy Mem Mem
reread reread (libc) (hand) read write
--------- ------------- ---- ---- ------ ------ ------ ------ ---- -----
trombetas Linux 1.3.74 8 3.9 23.5 21.1 18 25 41 36
trombetas Linux 1.3.74 9 3.8 25.0 21.1 18 25 41 36
negro.rut SunOS 4.1.3_U 4 2.0 19.5 8.2 18 24 41 36
madeira.r SunOS 5.5.1 8 6.9 13.9 19.5 18 18 40 36
Memory latencies in nanoseconds
(WARNING - may not be correct, check graphs)
--------------------------------------------
Host OS Mhz L1 $ L2 $ Main mem TLB Guesses
--------- ------------- --- ---- ---- -------- --- -------
trombetas Linux 1.3.74 50 20 170 180 -1 No L2 cache?
trombetas Linux 1.3.74 50 19 169 179 659 No L2 cache?
negro.rut SunOS 4.1.3_U 49 20 175 183 -1 No L2 cache?
madeira.r SunOS 5.5.1 12 - - - - Bad mhz?
^ permalink raw reply [relevance 1%]
* whee...
@ 1996-03-17 13:00 1% David S. Miller
1996-03-17 21:07 1% ` whee David C. Niemi
0 siblings, 1 reply; 200+ results
From: David S. Miller @ 1996-03-17 13:00 UTC (permalink / raw)
To: linux-kernel; +Cc: sparclinux, lmlinux
"No worries." -Andrew Tridgell
All on the same exact hardware folks.
L M B E N C H 1 . 0 S U M M A R Y
------------------------------------
Processor, Processes - times in microseconds
--------------------------------------------
Host OS Mhz Null Null Simple /bin/sh Mmap 2-proc 8-proc
Syscall Process Process Process lat ctxsw ctxsw
--------- ------------- ---- ------- ------- ------- ------- ---- ------ ------
trombetas Linux 1.3.74 50 13 8.7K 39.1K 53K 334 80 95
negro.rut SunOS 4.1.3_U 49 124 18.3K 63.9K 110K 470 152 262
geneva.ru SunOS 5.5 50 31 33.7K 148.2K 274K 596 174 205
*Local* Communication latencies in microseconds
-----------------------------------------------
Host OS Pipe UDP RPC/ TCP RPC/
UDP TCP
--------- ------------- ------- ------- ------- ------- -------
trombetas Linux 1.3.74 285 1004 1776 1406 2614
negro.rut SunOS 4.1.3_U 890 1375 2287 1573 2804
geneva.ru SunOS 5.5 530 1563 2080 1354 2398
*Local* Communication bandwidths in megabytes/second
----------------------------------------------------
Host OS Pipe TCP File Mmap Bcopy Bcopy Mem Mem
reread reread (libc) (hand) read write
--------- ------------- ---- ---- ------ ------ ------ ------ ---- -----
trombetas Linux 1.3.74 9 3.8 25.0 21.1 18 25 41 36
negro.rut SunOS 4.1.3_U 4 2.0 19.5 8.2 18 24 41 36
geneva.ru SunOS 5.5 8 7.0 12.6 19.5 18 18 40 36
Memory latencies in nanoseconds
(WARNING - may not be correct, check graphs)
--------------------------------------------
Host OS Mhz L1 $ L2 $ Main mem TLB Guesses
--------- ------------- --- ---- ---- -------- --- -------
trombetas Linux 1.3.74 50 19 169 179 659 No L2 cache?
negro.rut SunOS 4.1.3_U 49 20 175 183 -1 No L2 cache?
geneva.ru SunOS 5.5 49 - - - - Bad mhz?
^ permalink raw reply [relevance 1%]
* Re: whee...
1996-03-17 13:00 1% whee David S. Miller
@ 1996-03-17 21:07 1% ` David C. Niemi
0 siblings, 0 replies; 200+ results
From: David C. Niemi @ 1996-03-17 21:07 UTC (permalink / raw)
To: David S. Miller; +Cc: lmlinux
On Sun, 17 Mar 1996, David S. Miller wrote:
>
> "No worries." -Andrew Tridgell
>
> All on the same exact hardware folks.
>
>
> L M B E N C H 1 . 0 S U M M A R Y
> ------------------------------------
Interesting results. Looks like a little more work is needed on TCP
before Total Domination.
Would you mind trying out the "fixed" Byte UNIX benchmarks?
They are on wauug.erols.com in /pub/bench/unixbench-4.0-DELTA.tgz
niemi@wauug.erols.com David.Niemi@mail.li.org 703-810-5538 Reston, VA USA
A bear won't treat you so! You're satisfied to know
When he chews you up he still respects you. -- Al Stewart
^ permalink raw reply [relevance 1%]
* 1.3.75 is a little better...
@ 1996-03-18 11:14 5% David S. Miller
0 siblings, 0 replies; 200+ results
From: David S. Miller @ 1996-03-18 11:14 UTC (permalink / raw)
To: torvalds; +Cc: lmlinux
0.2MB improvement in TCP bandwidth...
L M B E N C H 1 . 0 S U M M A R Y
------------------------------------
Processor, Processes - times in microseconds
--------------------------------------------
Host OS Mhz Null Null Simple /bin/sh Mmap 2-proc 8-proc
Syscall Process Process Process lat ctxsw ctxsw
--------- ------------- ---- ------- ------- ------- ------- ---- ------ ------
trombetas Linux 1.3.74 50 15 9.2K 40.2K 54K 342 89 99
trombetas Linux 1.3.75 50 13 8.6K 34.0K 57K 338 81 105
negro.rut SunOS 4.1.3_U 49 124 18.3K 63.9K 110K 470 152 262
geneva.ru SunOS 5.5 50 31 33.7K 148.2K 274K 596 174 205
*Local* Communication latencies in microseconds
-----------------------------------------------
Host OS Pipe UDP RPC/ TCP RPC/
UDP TCP
--------- ------------- ------- ------- ------- ------- -------
trombetas Linux 1.3.74 285 1026 1754 1384 2582
trombetas Linux 1.3.75 295 1040 1798 1380 2606
negro.rut SunOS 4.1.3_U 890 1375 2287 1573 2804
geneva.ru SunOS 5.5 530 1563 2080 1354 2398
*Local* Communication bandwidths in megabytes/second
----------------------------------------------------
Host OS Pipe TCP File Mmap Bcopy Bcopy Mem Mem
reread reread (libc) (hand) read write
--------- ------------- ---- ---- ------ ------ ------ ------ ---- -----
trombetas Linux 1.3.74 8 3.8 23.5 21.1 18 24 41 36
trombetas Linux 1.3.75 8 4.0 25.0 20.0 18 25 41 36
negro.rut SunOS 4.1.3_U 4 2.0 19.5 8.2 18 24 41 36
geneva.ru SunOS 5.5 8 7.0 12.6 19.5 18 18 40 36
Memory latencies in nanoseconds
(WARNING - may not be correct, check graphs)
--------------------------------------------
Host OS Mhz L1 $ L2 $ Main mem TLB Guesses
--------- ------------- --- ---- ---- -------- --- -------
trombetas Linux 1.3.74 50 20 170 180 -1 No L2 cache?
trombetas Linux 1.3.75 50 20 170 180 659 No L2 cache?
negro.rut SunOS 4.1.3_U 49 20 175 183 -1 No L2 cache?
geneva.ru SunOS 5.5 49 - - - - Bad mhz?
^ permalink raw reply [relevance 5%]
* ccpenguin
@ 1996-03-18 14:08 1% David S. Miller
0 siblings, 0 replies; 200+ results
From: David S. Miller @ 1996-03-18 14:08 UTC (permalink / raw)
To: torvalds; +Cc: lmlinux, adrian
Not too bad at all. Pretty spiffy machine I guess. Although no match
for Linus's ev5 running Linux. But when I get the port done on this
thing I'll have comparable numbers ;-)
Remember, no forwarding of this stuff.
L M B E N C H 1 . 0 S U M M A R Y
------------------------------------
Processor, Processes - times in microseconds
--------------------------------------------
Host OS Mhz Null Null Simple /bin/sh Mmap 2-proc 8-proc
Syscall Process Process Process lat ctxsw ctxsw
--------- ------------- ---- ------- ------- ------- ------- ---- ------ ------
ccpenguin SunOS 5.5.1 167 5 3.4K 19.5K 37K 184 13 19
*Local* Communication latencies in microseconds
-----------------------------------------------
Host OS Pipe UDP RPC/ TCP RPC/
UDP TCP
--------- ------------- ------- ------- ------- ------- -------
ccpenguin SunOS 5.5.1 54 197 273 163 330
*Local* Communication bandwidths in megabytes/second
----------------------------------------------------
Host OS Pipe TCP File Mmap Bcopy Bcopy Mem Mem
reread reread (libc) (hand) read write
--------- ------------- ---- ---- ------ ------ ------ ------ ---- -----
ccpenguin SunOS 5.5.1 61 50.8 138.6 96.1 171 66 115 156
Memory latencies in nanoseconds
(WARNING - may not be correct, check graphs)
--------------------------------------------
Host OS Mhz L1 $ L2 $ Main mem TLB Guesses
--------- ------------- --- ---- ---- -------- --- -------
ccpenguin SunOS 5.5.1 167 6 41 265 492
^ permalink raw reply [relevance 1%]
* holy shit
@ 1996-03-19 21:22 1% David S. Miller
0 siblings, 0 replies; 200+ results
From: David S. Miller @ 1996-03-19 21:22 UTC (permalink / raw)
To: torvalds; +Cc: lmlinux
I just found a major bug which could have been massively affecting
performance on the sun4m. New bench numbers soon hopefully.
Later,
David S. Miller
davem@caip.rutgers.edu
^ permalink raw reply [relevance 1%]
* it keeps going and going and...
@ 1996-03-27 2:58 1% David S. Miller
0 siblings, 0 replies; 200+ results
From: David S. Miller @ 1996-03-27 2:58 UTC (permalink / raw)
To: lmlinux; +Cc: torvalds, user, adrian
I should yank this 'davem' guys account, he's such a fucking abusive
user. Grrr...
? uname -a
Linux trombetas 1.3.77 #2 Tue Mar 26 19:47:52 EST 1996 sparc
? uptime
2:56am up 1:55, 3 users, load average: 28.65, 28.21, 24.86
? ps -auxwww
USER PID %CPU %MEM SIZE RSS TTY STAT START TIME COMMAND
davem 38 0.0 0.0 584 0 p0 SW 01:01 0:00 (bash)
davem 1067 0.0 0.5 588 116 p1 S 01:39 0:00 -bash
davem 1107 5.5 1.0 312 228 p1 R 01:39 4:01 top
davem 1117 0.0 1.8 592 412 p2 S 01:40 0:01 -bash
davem 1142 0.0 1.0 596 236 p3 S 01:40 0:00 -bash
davem 1147 0.0 0.4 588 96 p4 S 01:40 0:00 -bash
davem 1148 0.0 0.5 588 120 p6 S 01:40 0:00 -bash
davem 1149 0.0 0.3 588 88 p7 S 01:40 0:00 -bash
davem 1150 0.0 0.5 588 132 p5 S 01:40 0:00 -bash
davem 1152 0.0 0.3 588 84 p8 S 01:40 0:00 -bash
davem 1229 5.1 0.7 416 176 p7 R 01:40 3:42 find .
davem 1230 5.1 0.7 416 176 p5 R 01:40 3:42 find .
davem 1231 5.1 0.7 416 176 p8 R 01:40 3:41 find .
davem 1232 5.1 0.7 416 176 p6 S 01:40 3:41 find .
davem 1233 5.0 11.1 4452 2492 p4 R 01:40 3:37 emacs19 -i
davem 1242 0.0 0.2 572 64 p9 S 01:43 0:00 /bin/bash -i
davem 1261 3.4 3.1 1872 704 p9 R 01:44 2:22 xgas
davem 1262 2.6 3.1 1872 708 p9 S 01:44 1:48 xgas
davem 1263 0.3 3.0 1872 692 p9 S 01:44 0:12 xgas
davem 1264 0.5 3.2 1872 716 p9 S 01:44 0:23 xgas
davem 1269 0.0 0.2 148 64 p3 S 01:46 0:00 ./crashme +2000.80 666 100 1:10:30 2
davem 1286 5.0 0.2 152 64 p3 R 01:46 3:19 ./crashme +2000.80 681 100 16 2 subprocess
davem 1422 4.6 0.2 156 64 p3 R 01:54 2:41 ./crashme +2000.80 782 100 117 2 subprocess
davem 1484 4.3 0.2 156 56 p3 R 01:59 2:20 ./crashme +2000.80 839 100 174 2 subprocess
davem 1489 4.3 0.2 156 56 p3 R 01:59 2:19 ./crashme +2000.80 844 100 179 2 subprocess
davem 1505 4.3 0.2 156 52 p3 R 02:01 2:14 ./crashme +2000.80 860 100 195 2 subprocess
davem 1516 4.3 0.2 152 56 p3 R 02:02 2:11 ./crashme +2000.80 871 100 206 2 subprocess
davem 1525 4.2 0.2 156 52 p3 R 02:02 2:08 ./crashme +2000.80 880 100 215 2 subprocess
davem 1652 4.0 0.3 152 68 p3 R 02:12 1:38 ./crashme +2000.80 999 100 334 2 subprocess
davem 1767 3.8 0.3 156 68 p3 R 02:21 1:12 ./crashme +2000.80 1102 100 437 2 subprocess
davem 1769 3.8 0.2 148 56 p3 R 02:21 1:11 ./crashme +2000.80 1104 100 439 2 subprocess
davem 1885 3.5 0.2 152 64 p3 R 02:29 0:49 ./crashme +2000.80 1200 100 535 2 subprocess
davem 1886 3.5 0.3 148 68 p3 R 02:29 0:49 ./crashme +2000.80 1201 100 536 2 subprocess
davem 1901 3.5 0.2 152 52 p3 R 02:30 0:47 ./crashme +2000.80 1212 100 547 2 subprocess
davem 1929 3.4 0.5 160 112 p3 R 02:32 0:41 ./crashme +2000.80 1240 100 575 2 subprocess
davem 1981 3.3 0.5 160 116 p3 R 02:36 0:32 ./crashme +2000.80 1288 100 623 2 subprocess
davem 2007 3.3 0.3 152 72 p3 R 02:38 0:28 ./crashme +2000.80 1310 100 645 2 subprocess
davem 2021 3.3 0.3 148 72 p3 R 02:39 0:26 ./crashme +2000.80 1324 100 659 2 subprocess
davem 2027 3.3 0.3 156 76 p3 R 02:40 0:24 ./crashme +2000.80 1330 100 665 2 subprocess
davem 2076 3.3 0.3 148 72 p3 R 02:44 0:17 ./crashme +2000.80 1376 100 711 2 subprocess
davem 2132 3.3 0.3 156 80 p3 R 02:47 0:09 ./crashme +2000.80 1421 100 756 2 subprocess
davem 2155 3.4 0.3 148 72 p3 R 02:49 0:06 ./crashme +2000.80 1440 100 775 2 subprocess
davem 2200 0.0 0.8 272 196 p2 R 02:52 0:00 ps -auxwww
root 1 0.0 0.0 188 0 ? SW 01:01 0:04 (init)
root 2 0.0 0.0 0 0 ? SW 01:01 0:01 (kflushd)
root 3 0.0 0.0 0 0 ? SW< 01:01 0:01 (kswapd)
root 7 0.0 0.1 116 28 ? S 01:01 0:01 update (bdfluHOME=/
root 23 0.0 0.1 628 24 ? S 01:01 0:00 (inetd)
root 25 0.0 0.0 636 12 ? S 01:01 0:00 (portmap)
root 36 0.1 0.2 668 48 ? S 01:01 0:07 /usr/etc/in.telnetd
root 39 0.0 0.0 152 0 1 SW 01:02 0:00 (getty)
root 40 0.0 0.0 152 0 2 SW 01:02 0:00 (getty)
root 41 0.0 0.0 152 0 3 SW 01:02 0:00 (getty)
root 42 0.0 0.0 152 0 4 SW 01:02 0:00 (getty)
root 43 0.0 0.0 152 0 5 SW 01:02 0:00 (getty)
root 44 0.0 0.0 152 0 6 SW 01:02 0:00 (getty)
root 68 0.0 0.0 900 0 p0 SW 01:02 0:02 (bash)
root 120 0.0 0.0 584 0 p0 SW 01:04 0:00 (bash)
root 134 0.0 0.0 584 0 p0 SW 01:04 0:00 (bash)
root 148 0.0 0.0 584 0 p0 SW 01:04 0:00 (bash)
root 162 0.0 0.0 584 0 p0 SW 01:04 0:00 (bash)
root 176 0.0 0.0 584 0 p0 SW 01:04 0:00 (bash)
root 190 0.0 0.0 584 0 p0 SW 01:04 0:00 (bash)
root 205 0.0 0.0 584 0 p0 SW 01:05 0:00 (bash)
root 219 0.0 0.0 584 0 p0 SW 01:05 0:00 (bash)
root 233 0.0 0.0 584 0 p0 SW 01:05 0:00 (bash)
root 247 0.0 0.0 584 0 p0 SW 01:05 0:00 (bash)
root 261 0.0 0.0 584 0 p0 SW 01:05 0:00 (bash)
root 275 0.0 0.0 584 0 p0 SW 01:05 0:00 (bash)
root 290 0.0 0.0 584 0 p0 SW 01:05 0:00 (bash)
root 304 0.0 0.0 584 0 p0 SW 01:05 0:00 (bash)
root 318 0.0 0.0 584 0 p0 SW 01:05 0:00 (bash)
root 332 0.0 0.0 584 0 p0 SW 01:05 0:00 (bash)
root 346 0.0 0.0 584 0 p0 SW 01:05 0:00 (bash)
root 360 0.0 0.0 584 0 p0 SW 01:05 0:00 (bash)
root 401 0.0 0.0 584 0 p0 SW 01:06 0:00 (bash)
root 415 0.0 0.0 584 0 p0 SW 01:06 0:00 (bash)
root 429 0.0 0.0 584 0 p0 SW 01:06 0:00 (bash)
root 443 0.0 0.0 584 0 p0 SW 01:06 0:00 (bash)
root 457 0.0 0.0 584 0 p0 SW 01:06 0:00 (bash)
root 471 0.0 0.0 584 0 p0 SW 01:06 0:00 (bash)
root 485 0.0 0.0 584 0 p0 SW 01:06 0:00 (bash)
root 501 0.0 0.0 108 0 p0 SW 01:07 0:00 (sh)
root 502 0.0 0.0 108 0 p0 SW 01:07 0:00 (sh)
root 503 0.0 0.0 112 0 p0 SW 01:07 0:00 (sh)
root 504 0.0 0.0 584 0 p0 SW 01:07 0:00 (bash)
root 518 0.0 0.0 584 0 p0 SW 01:07 0:00 (bash)
root 532 0.0 0.0 584 0 p0 SW 01:07 0:00 (bash)
root 546 0.0 0.0 584 0 p0 SW 01:07 0:00 (bash)
root 560 0.0 0.0 584 0 p0 SW 01:07 0:00 (bash)
root 574 0.0 0.0 592 0 p0 SW 01:07 0:00 (bash)
root 721 0.0 0.5 888 116 p0 S 01:12 0:01 (make)
root 757 0.0 0.9 552 204 p0 S 01:15 0:00 /bin/bash -c set -e; for i in kernel drivers mm fs net ipc lib arch/sparc/kernel arch/sparc/lib arch/sparc/mm arch/sparc/prom; do make -C $i; done
root 1064 0.2 3.8 1976 856 ? S 01:39 0:09 xterm -T trombetas
root 1085 0.0 0.5 604 124 p1 T 01:39 0:00 /bin/bash
root 1116 0.0 0.8 668 180 ? S 01:40 0:01 /usr/etc/in.telnetd
root 1138 0.5 3.7 1976 848 p2 S 01:40 0:23 xterm
root 1139 4.0 2.9 1960 668 p2 S 01:40 2:55 xterm
root 1140 4.0 2.9 1960 652 p2 S 01:40 2:54 xterm
root 1141 0.0 2.8 1960 644 p2 S 01:40 0:00 xterm
root 1143 4.0 2.9 1960 656 p2 S 01:40 2:56 xterm
root 1144 4.0 2.9 1960 648 p2 S 01:40 2:55 xterm
root 1293 0.0 1.0 588 228 p3 S 01:46 0:00 /bin/bash
root 1481 0.0 0.6 612 148 p3 S 01:59 0:00 (tail)
root 2102 0.2 2.5 888 560 p0 S 02:46 0:01 make -C fs
root 2112 0.0 0.4 112 100 p0 S 02:46 0:00 /bin/sh -c set -e; for i in ext2 proc nfs; do make -C $i; done
root 2113 0.2 2.4 868 544 p0 S 02:46 0:01 make -C ext2
root 2123 0.3 2.4 876 548 p0 S 02:47 0:01 make all_targets
root 2173 0.1 1.1 660 268 p0 S 02:50 0:00 gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -fno-strength-reduce -g -pipe -c -o balloc.o balloc.c
root 2174 1.1 3.8 1332 856 p0 S 02:51 0:01 /usr/local/gnu/lib/gcc-lib/sparc-sun-sunos4.1.4/2.6.3/cpp -lang-c -I/usr/src/linux/include -undef -D__GNUC__=2 -D__GNUC_MINOR__=6 -Dsparc -Dsun -Dunix -D__GCC_NEW_VARARGS__ -D__sparc__ -D__sun__ -D__unix__ -D__GCC_NEW_VARARGS__ -D__sparc -D__sun -D__unix
root 2175 2.9 10.9 3396 2452 p0 R 02:51 0:03 /usr/local/gnu/lib/gcc-lib/sparc-sun-sunos4.1.4/2.6.3/cc1 -quiet -dumpbase balloc.c -g -O2 -Wall -Wstrict-prototypes -fomit-frame-pointer -fno-strength-reduce -o -
root 2176 0.2 3.0 1204 680 p0 S 02:51 0:00 /usr/local/gnu/sparc-sun-sunos4.1.4/bin/as - -o balloc.o
? top
2:53am up 1:51, 3 users, load average: 28.51, 27.67, 23.85
112 processes: 83 sleeping, 28 running, 0 zombie, 1 stopped
CPU states: 43.7% user, 54.4% system, 95.8% nice, 4.2% idle
Mem: 22344K av, 21976K used, 368K free, 12056K shrd, 5308K buf 328K ca
Swap: 65516K av, 6648K used, 58868K free
PID USER PRI NI SIZE RES SHRD STAT %CPU %MEM TIME COMMAND
1767 davem 16 15 156 56 36 R 3.2 0.2 1:13 ./crashme +2000.80 1
1652 davem 17 15 152 60 40 R 3.1 0.2 1:39 ./crashme +2000.80 9
1107 davem 15 15 312 228 104 R 3.1 1.0 4:02 top
1886 davem 13 15 148 64 44 R 3.1 0.2 0:50 ./crashme +2000.80 1
1286 davem 19 15 152 64 44 R 3.1 0.2 3:20 ./crashme +2000.80 6
1233 davem 16 15 4452 2456 1308 R 3.0 10.9 3:38 emacs19 -i
1229 davem 18 15 416 176 80 R 2.9 0.7 3:43 find .
1422 davem 12 15 156 56 36 R 2.9 0.2 2:42 ./crashme +2000.80 7
1505 davem 11 15 156 52 32 R 2.9 0.2 2:15 ./crashme +2000.80 8
1516 davem 11 15 152 52 32 R 2.9 0.2 2:12 ./crashme +2000.80 8
1981 davem 10 15 160 112 76 R 2.9 0.5 0:33 ./crashme +2000.80 1
2076 davem 19 15 148 68 44 R 2.9 0.3 0:18 ./crashme +2000.80 1
1769 davem 20 15 148 56 36 R 2.9 0.2 1:12 ./crashme +2000.80 1
1929 davem 17 15 160 108 76 R 2.9 0.4 0:42 ./crashme +2000.80 1
2132 davem 17 15 156 76 44 R 2.9 0.3 0:10 ./crashme +2000.80 1
2027 davem 15 15 156 68 40 R 2.9 0.3 0:26 ./crashme +2000.80 1
2155 davem 14 15 148 64 40 R 2.9 0.2 0:08 ./crashme +2000.80 1
^ permalink raw reply [relevance 1%]
* SYMMMMETRRRRIC MULTI PENGUINNNNNNN!!!!!!
@ 1996-04-01 12:42 1% David S. Miller
1996-04-02 2:01 0% ` John Vozza
0 siblings, 1 reply; 200+ results
From: David S. Miller @ 1996-04-01 12:42 UTC (permalink / raw)
To: sparclinux; +Cc: linux-kernel, linux-smp, lmlinux, user
(yeah, it runs shell and basic programs, I can telnet out etc.
but it hard-locks now and then, working on it...)
Any questions? And remember kids, Linux is just a "toy operating
system."
PROMLIB: Sun Boot Prom Version 3 Revision 2
ARCH: SUN4M
TYPE: Sun4m SparcStation10
Ethernet address: 8:0:20:12:53:32
Found 4 CPU prom device tree node(s).
IOMMU: impl 0 vers 1 page table at f03c0000 of size 65536 bytes
sbus0: Clock 20.0 MHz
dma0: Revision 2
dma1: Revision 2
cgsix0 at 0x20000000
Console: 16 point font, 864 scans
Console: colour SUN 128x54, 1 virtual console (max 63)
Calibrating delay loop.. ok - 115.51 BogoMIPS
Memory: 175720k available (948k kernel code, 2988k data)
Swansea University Computer Society NET3.033 for Linux 1.3.50
NET3: Unix domain sockets 0.12 for Linux NET3.033.
Swansea University Computer Society TCP/IP for NET3.033
IP Protocols: ICMP, UDP, TCP
Linux version 1.3.77 (davem@huahaga.rutgers.edu) (gcc version 2.6.3) #15 Mon Apr 1 07:02:51 EST 1996
Entering SparclinuxMultiPenguin(SMP) Mode...
Starting CPU 1 at f002a9b8
Calibrating delay loop.. ok - 115.92 BogoMIPS
Starting CPU 2 at f002a9d0
Calibrating delay loop.. ok - 104.86 BogoMIPS
Starting CPU 3 at f002a9e8
Calibrating delay loop.. ok - 104.86 BogoMIPS
Total of 4 Penguins activated (441.14 PenguinMIPS).
Sparc Zilog8530 serial driver version 1.00
tty00 at 0xffede004 (irq = 44) is a Zilog8530
tty01 at 0xffede000 (irq = 44) is a Zilog8530
tty02 at 0xffedb004 (irq = 44) is a Zilog8530
tty03 at 0xffedb000 (irq = 44) is a Zilog8530
Sun TYPE 4 keyboard detected without keyclick
Sun Mouse-Systems mouse driver version 1.00
esp0: IRQ 36 SCSI ID 7 Clock 20 MHz Period 99 NCR53C9x(esp236) detected
scsi0 : Sparc ESP236
scsi : 1 host.
Started kswapd v 1.5
Vendor: SEAGATE Model: ST32430N SUN2.1G Rev: 0444
Type: Direct-Access ANSI SCSI revision: 02
Detected scsi disk sda at scsi0, channel 0, id 3, lun 0
scsi : detected 1 SCSI disk total.
SCSI Hardware sector size is 512 bytes on device sda
sunlance.c:v1.5 21/Mar/96 Miguel de Icaza (miguel@nuclecu.unam.mx)
eth0: LANCE 08:00:20:12:53:32
Partition check:
sda: sda1 sda2 sda3 sda4 sda5 sda6 sda7 sda8
Sending BOOTP and RARP requests.....OK
Root-NFS: Got RARP answer from 128.6.155.101, my address is 128.6.155.53
Root-NFS: Got file handle for /caip/u119/davem/SparcLinux/machines/jenolan via RPC
VFS: Mounted root (nfs filesystem).
# mount -n -t proc none /proc
# cat /proc/cpuinfo
cpu : ROSS HyperSparc RT625
fpu : ROSS HyperSparc combined IU/FPU
promlib : Version 3 Revision 2
type : sun4m
Elf Support : yes
Cpu0Bogo : 115.50
Cpu1Bogo : 115.91
Cpu2Bogo : 104.85
Cpu3Bogo : 104.85
MMU type : ROSS HyperSparc
invall : 4020
invmm : 0
invrnge : 0
invpg : 0
contexts : 4096
big_chunks : 0
little_chunks : 0
CPU0 CPU1 CPU2 CPU3
State: online online online akp
Lock: 2 2 2 2
klock: ff
block: 0
alock: 0
^ permalink raw reply [relevance 1%]
* Re: SYMMMMETRRRRIC MULTI PENGUINNNNNNN!!!!!!
1996-04-01 12:42 1% SYMMMMETRRRRIC MULTI PENGUINNNNNNN!!!!!! David S. Miller
@ 1996-04-02 2:01 0% ` John Vozza
0 siblings, 0 replies; 200+ results
From: John Vozza @ 1996-04-02 2:01 UTC (permalink / raw)
To: David S. Miller; +Cc: sparclinux, linux-kernel, linux-smp, lmlinux, user
Can you say jealous!!!! Just had to reply... plz no flames!
Sure beats my 486dx100 =(
On Mon, 1 Apr 1996, David S. Miller wrote:
>
> (yeah, it runs shell and basic programs, I can telnet out etc.
> but it hard-locks now and then, working on it...)
>
> Any questions? And remember kids, Linux is just a "toy operating
> system."
>
> PROMLIB: Sun Boot Prom Version 3 Revision 2
> ARCH: SUN4M
> TYPE: Sun4m SparcStation10
> Ethernet address: 8:0:20:12:53:32
> Found 4 CPU prom device tree node(s).
> IOMMU: impl 0 vers 1 page table at f03c0000 of size 65536 bytes
> sbus0: Clock 20.0 MHz
> dma0: Revision 2
> dma1: Revision 2
> cgsix0 at 0x20000000
> Console: 16 point font, 864 scans
> Console: colour SUN 128x54, 1 virtual console (max 63)
> Calibrating delay loop.. ok - 115.51 BogoMIPS
> Memory: 175720k available (948k kernel code, 2988k data)
> Swansea University Computer Society NET3.033 for Linux 1.3.50
> NET3: Unix domain sockets 0.12 for Linux NET3.033.
> Swansea University Computer Society TCP/IP for NET3.033
> IP Protocols: ICMP, UDP, TCP
> Linux version 1.3.77 (davem@huahaga.rutgers.edu) (gcc version 2.6.3) #15 Mon Apr 1 07:02:51 EST 1996
> Entering SparclinuxMultiPenguin(SMP) Mode...
> Starting CPU 1 at f002a9b8
> Calibrating delay loop.. ok - 115.92 BogoMIPS
> Starting CPU 2 at f002a9d0
> Calibrating delay loop.. ok - 104.86 BogoMIPS
> Starting CPU 3 at f002a9e8
> Calibrating delay loop.. ok - 104.86 BogoMIPS
> Total of 4 Penguins activated (441.14 PenguinMIPS).
> Sparc Zilog8530 serial driver version 1.00
> tty00 at 0xffede004 (irq = 44) is a Zilog8530
> tty01 at 0xffede000 (irq = 44) is a Zilog8530
> tty02 at 0xffedb004 (irq = 44) is a Zilog8530
> tty03 at 0xffedb000 (irq = 44) is a Zilog8530
> Sun TYPE 4 keyboard detected without keyclick
> Sun Mouse-Systems mouse driver version 1.00
> esp0: IRQ 36 SCSI ID 7 Clock 20 MHz Period 99 NCR53C9x(esp236) detected
> scsi0 : Sparc ESP236
> scsi : 1 host.
> Started kswapd v 1.5
> Vendor: SEAGATE Model: ST32430N SUN2.1G Rev: 0444
> Type: Direct-Access ANSI SCSI revision: 02
> Detected scsi disk sda at scsi0, channel 0, id 3, lun 0
> scsi : detected 1 SCSI disk total.
> SCSI Hardware sector size is 512 bytes on device sda
> sunlance.c:v1.5 21/Mar/96 Miguel de Icaza (miguel@nuclecu.unam.mx)
> eth0: LANCE 08:00:20:12:53:32
> Partition check:
> sda: sda1 sda2 sda3 sda4 sda5 sda6 sda7 sda8
> Sending BOOTP and RARP requests.....OK
> Root-NFS: Got RARP answer from 128.6.155.101, my address is 128.6.155.53
> Root-NFS: Got file handle for /caip/u119/davem/SparcLinux/machines/jenolan via RPC
> VFS: Mounted root (nfs filesystem).
> # mount -n -t proc none /proc
> # cat /proc/cpuinfo
> cpu : ROSS HyperSparc RT625
> fpu : ROSS HyperSparc combined IU/FPU
> promlib : Version 3 Revision 2
> type : sun4m
> Elf Support : yes
> Cpu0Bogo : 115.50
> Cpu1Bogo : 115.91
> Cpu2Bogo : 104.85
> Cpu3Bogo : 104.85
> MMU type : ROSS HyperSparc
> invall : 4020
> invmm : 0
> invrnge : 0
> invpg : 0
> contexts : 4096
> big_chunks : 0
> little_chunks : 0
> CPU0 CPU1 CPU2 CPU3
> State: online online online akp
> Lock: 2 2 2 2
>
> klock: ff
> block: 0
> alock: 0
>
^ permalink raw reply [relevance 0%]
* ho hum...
@ 1996-04-07 5:36 1% David S. Miller
0 siblings, 0 replies; 200+ results
From: David S. Miller @ 1996-04-07 5:36 UTC (permalink / raw)
To: sparclinux; +Cc: lmlinux, user
Can your multi-national, client server, multi-threaded, customer ready
bloat OS with enhanced interoperability do this?
? ps -auxwww | grep crashme
davem 5869 0.0 0.0 148 68 p4 S 05:02 0:00 ./crashme +2000.80 666 100 1:10:30 2
davem 5885 10.0 0.0 152 76 p4 R 05:02 2:47 ./crashme +2000.80 681 100 16 2 subprocess
davem 5888 0.0 0.0 148 68 p4 S 05:02 0:00 ./crashme +2000 666 100 1:10:30 2
davem 5915 9.6 0.1 348 268 p4 R 05:03 2:39 ./crashme +2000 686 100 21 2 subprocess
davem 5997 7.8 0.0 232 152 p4 R 05:06 1:55 ./crashme +2000 721 100 56 2 subprocess
davem 6041 7.0 0.1 348 268 p4 R 05:07 1:36 ./crashme +2000 741 100 76 2 subprocess
davem 6062 6.3 0.1 348 268 p4 R 05:08 1:25 ./crashme +2000 750 100 85 2 subprocess
davem 6082 6.0 0.0 176 96 p4 R 05:09 1:17 ./crashme +2000 759 100 94 2 subprocess
davem 6116 5.4 0.1 256 176 p4 R 05:10 1:05 ./crashme +2000 775 100 110 2 subprocess
davem 6130 5.1 0.0 160 84 p4 R 05:11 1:00 ./crashme +2000.80 782 100 117 2 subprocess
davem 6137 5.1 0.1 252 176 p4 R 05:11 0:59 ./crashme +2000 784 100 119 2 subprocess
davem 6140 5.2 0.1 284 204 p4 R 05:11 1:00 ./crashme +2000 785 100 120 2 subprocess
davem 6161 5.0 0.0 196 116 p4 R 05:12 0:56 ./crashme +2000 792 100 127 2 subprocess
davem 6276 4.5 0.0 220 144 p4 R 05:15 0:41 ./crashme +2000 833 100 168 2 subprocess
davem 6288 4.5 0.0 156 80 p4 R 05:15 0:40 ./crashme +2000.80 839 100 174 2 subprocess
davem 6298 4.3 0.0 156 80 p4 R 05:16 0:37 ./crashme +2000.80 844 100 179 2 subprocess
davem 6343 4.2 0.0 160 84 p4 R 05:17 0:32 ./crashme +2000.80 860 100 195 2 subprocess
davem 6370 4.1 0.0 152 76 p4 R 05:18 0:29 ./crashme +2000.80 871 100 206 2 subprocess
davem 6372 4.1 0.1 312 236 p4 R 05:18 0:30 ./crashme +2000 871 100 206 2 subprocess
davem 6389 4.0 0.0 160 84 p4 R 05:19 0:27 ./crashme +2000.80 880 100 215 2 subprocess
davem 6406 4.0 0.1 256 176 p4 R 05:19 0:26 ./crashme +2000 887 100 222 2 subprocess
davem 6481 3.8 0.1 2248 260 p4 R 05:22 0:18 ./crashme +2000 920 100 255 2 subprocess
davem 6487 3.8 0.0 228 152 p4 R 05:22 0:17 ./crashme +2000 923 100 258 2 subprocess
davem 6519 3.7 0.0 208 128 p4 R 05:24 0:14 ./crashme +2000 939 100 274 2 subprocess
davem 6520 3.7 0.0 156 76 p4 R 05:24 0:14 ./crashme +2000.80 940 100 275 2 subprocess
davem 6525 3.7 0.1 348 268 p4 R 05:24 0:13 ./crashme +2000 942 100 277 2 subprocess
davem 6633 4.1 0.0 232 152 p4 R 05:28 0:05 ./crashme +2000 992 100 327 2 subprocess
davem 6646 4.3 0.0 156 76 p4 R 05:29 0:03 ./crashme +2000.80 999 100 334 2 subprocess
davem 6661 5.0 0.1 348 268 p4 R 05:29 0:02 ./crashme +2000 1006 100 341 2 subprocess
davem 6679 18.8 0.1 332 256 p4 R 05:30 0:01 ./crashme +2000 1015 100 350 2 subprocess
davem 6684 0.0 0.1 604 200 p4 S 05:30 0:00 grep crashme
? uname -a
Linux huahaga 1.3.83 #5 Sat Apr 6 21:46:09 EST 1996 sparc
? cat /proc/meminfo
Mem: 179937280 175955968 3981312 11505664 66658304 93188096
Swap: 67088384 16384 67072000
MemTotal: 175720 kB
MemFree: 3888 kB
MemShared: 11236 kB
Buffers: 65096 kB
Cached: 91004 kB
SwapTotal: 65516 kB
SwapFree: 65500 kB
cpuinfo
? cat /proc/cpuinfo
cpu : ROSS HyperSparc RT625
fpu : ROSS HyperSparc combined IU/FPU
promlib : Version 3 Revision 2
type : sun4m
Elf Support : yes
BogoMips : 115.91
MMU type : ROSS HyperSparc
invall : 197856
invmm : 17135
invrnge : 338517
invpg : 12818739
contexts : 4096
big_chunks : 0
little_chunks : 0
? uptime
5:34am up 1:54, 3 users, load average: 30.60, 27.64, 19.27
?
I didn't think so... but I get a few of these every once in a while:
<4>WARNING: FPU exception from kernel mode. at pc=f00116cc
<4> \|/ ____ \|/
<4> "@'/ ,. \`@"
<4> /_| \__/ |_\
<4> \__U_/
<4>crashme(6723): Too many Penguin-FPU traps from kernel mode
<4>PSR: 1e8010c2 PC: f00116d0 NPC: f00116d4 Y: 9e63031f
<4>%g0: f0bc8000 %g1: ffffffef %g2: 00000020 %g3: 000221c4
<4>%g4: f0bc8000 %g5: 00000000 %g6: 00000000 %g7: 00001100
<4>%o0: f0c0f460 %o1: f0c0f560 %o2: f0c0f568 %o3: f0c0f564
<4>%o4: f00fec00 %o5: 0000000f %sp: f0daff08 %ret_pc: f0012a90
<4>Instruction DUMP:
It doesn't stop the machine, it's just annoying. But I'll fix that.
Later,
David S. Miller
davem@caip.rutgers.edu
^ permalink raw reply [relevance 1%]
* HyperSparc UP numbers
@ 1996-04-16 0:02 1% David S. Miller
0 siblings, 0 replies; 200+ results
From: David S. Miller @ 1996-04-16 0:02 UTC (permalink / raw)
To: lmlinux; +Cc: torvalds
The MMap lat. looks bogus but the rest is ok.
Larry, if you make another set of results publicly available on your
web page for the next release like you do now I'd like this to be in
there if thats ok.
L M B E N C H 1 . 0 S U M M A R Y
------------------------------------
Processor, Processes - times in microseconds
--------------------------------------------
Host OS Mhz Null Null Simple /bin/sh Mmap 2-proc 8-proc
Syscall Process Process Process lat ctxsw ctxsw
--------- ------------- ---- ------- ------- ------- ------- ---- ------ ------
huahaga Linux 1.3.83 118 3 12.8K 36.4K 52K 1060 25 43
*Local* Communication latencies in microseconds
-----------------------------------------------
Host OS Pipe UDP RPC/ TCP RPC/
UDP TCP
--------- ------------- ------- ------- ------- ------- -------
huahaga Linux 1.3.83 75 188 628 404 916
*Local* Communication bandwidths in megabytes/second
----------------------------------------------------
Host OS Pipe TCP File Mmap Bcopy Bcopy Mem Mem
reread reread (libc) (hand) read write
--------- ------------- ---- ---- ------ ------ ------ ------ ---- -----
huahaga Linux 1.3.83 54 9.7 36.4 30.8 21 22 49 37
Memory latencies in nanoseconds
(WARNING - may not be correct, check graphs)
--------------------------------------------
Host OS Mhz L1 $ L2 $ Main mem TLB Guesses
--------- ------------- --- ---- ---- -------- --- -------
huahaga Linux 1.3.83 118 11 11 511 0 No L1 cache?
^ permalink raw reply [relevance 1%]
* (fwd) USELINUX: Linux Applications Development and Deployment Conference
@ 1996-04-17 22:05 1% Larry McVoy
0 siblings, 0 replies; 200+ results
From: Larry McVoy @ 1996-04-17 22:05 UTC (permalink / raw)
To: lmlinux
Path: fido.asd.sgi.com!sgigate.sgi.com!news.msfc.nasa.gov!newsfeed.internetmci.com!newsxfer2.itd.umich.edu!agate!darkstar.UCSC.EDU!osr
From: toni@usenix.org (Toni Veglia)
Newsgroups: comp.os.research
Subject: USELINUX: Linux Applications Development and Deployment Conference
Date: 17 Apr 1996 04:07:09 GMT
Organization: USENIX Association
Lines: 236
Approved: comp-os-research@ftp.cse.ucsc.edu
Message-ID: <4l1qpd$ivd@darkstar.UCSC.EDU>
NNTP-Posting-Host: ftp.cse.ucsc.edu
Originator: osr@cse.ucsc.edu
USELINUX: Linux Applications Development and Deployment Conference
Co-located with the USENIX Annual Technical Conference
Co-sponsored by Linux International and the USENIX Association
January 6-10, 1997 - Anaheim Marriott Hotel, Anaheim, California
Tutorials: January 6-7, 1997
Technical Sessions: January 8-9, 1997
Business Sessions: January 10, 1997
Keynote: Wednesday, January 8, 1997
Birds-of-a-Feather Sessions: January 7-9, 1997
Vendor Exhibits: January 8-9, 1997
Reception: January 8, 1997
Conference Chair Michael K. Johnson, Linux Journal
TECHNICAL TRACK COMMITTEE:
Michael K. Johnson, Chair, Linux Journal
Mark Bolzern, WorkGroup Solutions
Alan Cox, 3Com Remote Access Products
Jon `maddog' Hall, Esq., Digital Equipment Corporation
Lorrie LeJeune, O'Reilly and Associates
Dr. Tom Miller, North Carolina State University
Erik Troan, Red Hat Software
Dr. Greg Wettstein, Roger Maris Cancer Center
BUSINESS TRACK COMMITTEE:
Jon `maddog' Hall, Esq., Chair, Digital Equipment Corporation
Jonathan Eunice, President, Founder, Research Director of lluminata, Inc.
Michael K. Johnson, Editor, Linux Journal
Lorrie LeJeune, Product Manager of Internet and Linux, O'Reilly and Assoc.
Bryan Sparks, President , Caldera, Inc.
Paul Winbauer, Director of Technical Programs, Avnet Computing
Bob Young, President, Red Hat Software, Inc.
Suggestions for Topics: June 1, 1996
Submissions Due : Date: July 1, 1996
Materials Due Date: November 13, 1996
OVERVIEW:
The Linux Applications Development and Deployment Conference
(USELINUX) is aimed at three primary audiences: application
developers porting or developing Linux applications, systems
administrators charged with maintaining Linux systems, and business
people who wish to bring Linux applications to market. Two
technical tracks on January 8th and 9th will include separate
components for developers and systems administrators. A business
track devoted to explaining the dynamics of the Linux marketplace
and how to partake of it will take place on January 10.
In addition to the three days of presentations and discussions,
there will be two days of tutorials, Birds-of-a-Feather sessions,
and Vendor Exhibits.
TUTORIALS--Monday and Tuesday, January 6-7, 1997
We are actively seeking proposals for half or full day tutorials on
practical, technical aspects of using Linux. If you would like to
present a tutorial, please contact the USENIX tutorial co-ordinator,
Daniel V. Klein.
Phone: 412.421.0285
Fax: 412.421.2332
Email: <dvk@usenix.org>
TECHNICAL TRACK TOPICS - Wednesday and Thursday, January 8-9, 1997
The technical track will have three components:
- an application developers component focusing on topics helpful
in porting and developing Linux applications. These include things
like APIs, including both Linux's levels of compliance with
industry standard APIs and Linux-specific APIs, and capabilities
that give extra functionality and/or convenience.
- a system administrators component to help sysadmins apply their
skills to Linux administration, and also demonstrate some of the
unique and useful features that can make their lives easier.
- a component for enthusiasts involved in developing the Linux
operating system and environment.
BUSINESS TRACK TOPICS - Friday, January 10, 1997
The business track program will focus on obstacles and challenges
in integrating Linux into a business. The target audience are
software application developers, hardware vendors, service
providers, large in-house application developers, and others who
would like to know how to make their business more successful using
Linux. This track will concentrate on business issues such as:
--The Linux Market: Who, What, Where, When and Why?
--Application Portfolios: What is available, what can be done?
--Marketing to the Linux Marketplace
--Channels: Retail, Resellers, Distributors, Integrators, OEMs, Service
--Licenses and Licensing: I don't want to give away my application!!!
In addition to the meetings, there will be a compendium of
information on CD-ROM for conference attendees. This will include
copies of the slides, pointers to resources, white papers, lists of
current resellers, user groups, etc.
HOW TO SUBMIT A PROPOSAL
Suggestions for additional topics and areas where the topics can be
expanded are welcome by June 1, 1996. The program committee will
then prioritize the topics and create the final list of topics by
July 1st. The program committee will solicit volunteers to work on
the program, and will balance volunteers with program needs by that
time.
An expanded electronic version of this announcement with greater
detail, as well as the Call for Papers for the USENIX Annual
Technical Conference, is available at the USENIX Web site:
http://www.usenix.org.
Proposals for invited talks and panels should be received by July
1, 1996. We welcome submissions of a full paper or an extended
abstract. Panel proposals should contain a list of names of
potential panelists. Please send submissions to the conference
program chairs via one of the following methods. All submissions
will be acknowledged.
Please send comments, suggestions, and volunteering of time for a
particular area of expertise (including a small bio of your
experience) to the conference program chair via one of the
following methods. Email is greatly preferred.
PREFERRED METHOD
If you are submitting an idea for the technical track, send email
to: <michael@usenix.org> .
For the business program, send your ideas via email to
<maddog@usenix.org> with the subject line:
MADDOG, ANOTHER GREAT IDEA FOR THE *FABULOUS* USELINUX BUSINESS TRACK
ALTERNATE METHOD:
Via postal address or fax to:
Michael Johnson or Jon "maddog" Hall, Esq.
USENIX Association
2560 Ninth Street, Suite 215
Berkeley CA 94710
Fax: 510-548-5738
VENDOR EXHIBITS
Vendors will demonstrate their products in a relaxed environment
where attendees can discuss product features and services.
Vendors are invited to participate in the Vendor Exhibits. This is
an excellent opportunity to receive feedback from our technically
astute audience. If your company would like to display its
products or services, please contact Cynthia Deno:
Phone: 408-335-9445
Email: <display@usenix.org>
BIRDS-OF-A-FEATHER SESSIONS (BOFs)
BOFs are very informal, attendee-organized sessions held in the
evenings by attendees interested in a particular topic. They may
be scheduled on-site or in advance by contacting the USENIX
Conference Office. Send email to <conference@usenix.org> or
phone 714-588-8649.
ABOUT THE USENIX ASSOCIATION
USENIX is the UNIX and Advanced Computing Systems Technical and
Professional Association. Since 1975 the USENIX Association has
brought together the community of engineers, system administrators,
scientists, and technicians working on the cutting edge of the
computing world.
The USENIX Conferences have become the essential meeting grounds for
the presentation and discussion of the most advanced information on
new developments in all aspects of advanced computing systems.
The USENIX Association and its members are dedicated to:
--problem-solving with a practical bias,
--fostering innovation and research that works,
--communicating rapidly the results of both research and innovation,
--providing a neutral forum for the exercise of critical thought and
the airing of technical issues.
SAGE, a Special Technical Group within the USENIX Association, is
dedicated to the recognition and advancement of system administration
as a profession. To join SAGE, you must be a member of USENIX.
ABOUT LINUX INTERNATIONAL
Linux International (LI) is a new organization dedicated to
promoting the development and use of the Linux operating system
worldwide. LI promotes Linux in various ways:
* LI has established a "Development Grant Fund" which is
used to help Linux developers afford hardware and software that
they need to continue development. The money in the fund is
primarily given by Linux users eager to contribute to Linux
development.
* LI facilitates Linux activities at conferences and trade shows.
* LI's Vendor Assistance Program offers vendors various kinds
of assistance in porting their products to Linux.
* LI's Linux Promotion Project disseminates promotional
materials, including press releases, all over the world. What's
the point of a world-class operating system if people don't know
it exists?
See the LI home page at http://www.li.org/linux-int/" or send email
to <info@li.org> for more information.
REGISTRATION INFORMATION
The complete program will be available in September 1996. To
receive a registration package, please contact:
USENIX Conference Office
22672 Lambert Street, Suite 215
Lake Forest, CA 92630
Phone: 714.588.5738
Fax: 714.588.9706
URL: http://www.usenix.org
Email: conference@usenix.org
Or you can send email to our mailserver at <info@usenix.org>. Your
message should contain the line: "send linux conferences" and
the program will be sent to you.
--
---
Larry McVoy lm@sgi.com http://reality.sgi.com/lm (415) 933-1804
Copyright 1996, all rights reserved. Microsoft Network is prohibited from
redistributing this work in any form, in whole or in part without license.
License to distribute this work is available to Microsoft at $500.
Transmission without permission constitutes an agreement to these terms.
^ permalink raw reply [relevance 1%]
* SMP wheee...
@ 1996-04-18 7:28 1% David S. Miller
0 siblings, 0 replies; 200+ results
From: David S. Miller @ 1996-04-18 7:28 UTC (permalink / raw)
To: sparclinux; +Cc: lmlinux, alan
SparcLinuxMP just built itself on two processors without a
hitch over nfsroot!
YIEEE!!!
Later,
David S. Miller
davem@caip.rutgers.edu
^ permalink raw reply [relevance 1%]
* SMP, yeah it works dude...
@ 1996-04-18 10:03 1% David S. Miller
0 siblings, 0 replies; 200+ results
From: David S. Miller @ 1996-04-18 10:03 UTC (permalink / raw)
To: sparclinux; +Cc: linux-smp, linux-kernel, lmlinux, user
make -j vmlinux in 3 minutes 45 seconds, second time was a little
faster because it was all in the cache... and... of course
? ps -auxwww
USER PID %CPU %MEM SIZE RSS TTY STAT START TIME COMMAND
davem 41 0.0 0.2 588 436 1 S 08:52 0:01 -bash
davem 1689 0.0 0.0 112 100 1 S 09:08 0:00 sh
/usr/local/X11R5/bin/startx
davem 1690 0.0 0.2 1140 452 1 S 09:08 0:00 xinit
/usr/home/davem/.xinitrc --
davem 1691 1.7 0.8 3760 1476 1 S 09:08 0:56 X :0
davem 1692 0.1 0.4 1292 736 1 S 09:08 0:03 fvwm
davem 1714 0.0 0.2 1092 520 1 S 09:08 0:00
/usr/local/X11R5/lib/X11/fvwm/FvwmPager 7 4 /usr/home/davem/.fvwmrc 0
8 0 3
davem 2061 0.0 0.2 596 464 p3 S 09:11 0:01 -bash
davem 4336 0.0 0.2 600 468 p0 S 09:50 0:00 -bash
davem 4361 0.1 0.0 148 68 p0 S 09:53 0:00 ./crashme
+2000 666 100 1:10:30 2
davem 4383 74.4 0.1 348 268 p0 R 09:53 6:12 ./crashme
+2000 686 100 21 2 subprocess
davem 4430 59.8 0.0 228 148 p0 R 09:56 3:15 ./crashme
+2000 721 100 56 2 subprocess
davem 4468 43.6 0.0 252 172 p0 R 09:58 1:39 ./crashme
+2000 741 100 76 2 subprocess
davem 4478 38.1 0.1 344 264 p0 R 09:59 1:09 ./crashme
+2000 750 100 85 2 subprocess
davem 4488 34.8 0.0 176 96 p0 R 09:59 0:47 ./crashme
+2000 759 100 94 2 subprocess
davem 4507 31.6 0.0 252 172 p0 R 10:01 0:17 ./crashme
+2000 775 100 110 2 subprocess
davem 4515 0.2 0.2 696 392 p3 S 10:01 0:00 telnet caip
davem 4520 2.0 0.2 588 436 p1 S 10:02 0:00 -bash
davem 4526 29.3 0.1 252 176 p0 R 10:02 0:02 ./crashme
+2000 784 100 119 2 subprocess
davem 4537 0.0 0.0 232 156 p1 R 10:02 0:00 ps -auxwww
root 1 0.3 0.0 188 144 ? S 08:51 0:14 init [2]
root 2 0.0 0.0 0 0 ? SW 08:51 0:00 (kflushd)
root 3 0.0 0.0 0 0 ? SW< 08:51 0:00 (kswapd)
root 4 0.0 0.0 0 0 ? SW 08:52 0:00 (nfsiod)
root 5 0.0 0.0 0 0 ? SW 08:52 0:00 (nfsiod)
root 6 0.0 0.0 0 0 ? SW 08:52 0:00 (nfsiod)
root 7 0.0 0.0 0 0 ? SW 08:52 0:00 (nfsiod)
root 11 0.2 0.0 116 44 ? S 08:52 0:09 update
(bdfluHOME=/
root 27 0.0 0.1 628 268 ? S 08:52 0:00
/usr/etc/inetd
root 29 0.0 0.1 636 248 ? S 08:52 0:00
/usr/etc/portmap
root 42 0.0 0.0 152 100 2 S 08:52 0:00 /sbin/getty
9600 tty2
root 43 0.0 0.0 152 100 3 S 08:52 0:00 /sbin/getty
9600 tty3
root 44 0.0 0.0 152 100 4 S 08:52 0:00 /sbin/getty
9600 tty4
root 45 0.0 0.0 152 100 5 S 08:52 0:00 /sbin/getty
9600 tty5
root 46 0.0 0.0 152 100 6 S 08:52 0:00 /sbin/getty
9600 tty6
root 2060 0.0 0.6 1996 1220 1 S 09:11 0:01 xterm
root 4335 0.0 0.6 1980 1180 1 S 09:50 0:00 xterm
root 4519 2.4 0.6 1980 1180 1 S 10:02 0:00 xterm
? uname -a
Linux huahaga 1.3.90 #10 Thu Apr 18 04:44:32 EDT 1996 sparc
? cat /proc/cpuinfo
cpu : ROSS HyperSparc RT625
fpu : ROSS HyperSparc combined IU/FPU
promlib : Version 3 Revision 2
type : sun4m
Elf Support : yes
Cpu0Bogo : 116.73
Cpu1Bogo : 116.73
Cpu2Bogo : 0.00
Cpu3Bogo : 0.00
MMU type : ROSS HyperSparc
invall : 102
invmm : 10509
invrnge : 155469
invpg : 2305064
contexts : 4096
big_chunks : 0
little_chunks : 0
CPU0 CPU1 CPU2 CPU3
State: online akp offline offline
Lock: 00000002 00000002 00000000
00000000
klock: ff
block: 0
alock: 0
? uptime
10:04am up 1:12, 2 users, load average: 7.39, 5.20, 3.63
?
It keeps going and going and going....
Later,
David S. Miller
davem@caip.rutgers.edu
^ permalink raw reply [relevance 1%]
* Linux/MIPS port resources
@ 1996-04-19 18:47 1% Ariel Faigon
0 siblings, 0 replies; 200+ results
From: Ariel Faigon @ 1996-04-19 18:47 UTC (permalink / raw)
To: linux
I was thinking about what should we do to make David Miller come
up to speed as fast as possible when he comes for the summer.
After all, he may not be familiar with MIPS assembly, IRIX etc.
So I set up a *preliminary* Web page with a list of resources
for the Linux/MIPS port. Most of the pointers are from Bill Earl,
thanks Bill.
Please send me suggestions for improvement, what's missing, etc.
This is just a quick first shot so you get the idea. The 6.2
freeware gcc is not yet configured to work with GNU-as (so it uses
stabs and supports debugging) and our linker. I'll be working
on this next week.
We also need to make sure that all the equipment, the office, etc.
is ready when David lands here. I assume someone is taking care of
all this (?). And that someone with intimate knowledge of our low
level stuff is really available to assist him on call.
I'll leave it to Larry or Greg to announce the details on David
Miller's accepting SGI's offer. p l e a s e :-)
6 weeks to go...
--
Peace, Ariel
^ permalink raw reply [relevance 1%]
* Good news
@ 1996-04-19 21:52 1% Larry McVoy
0 siblings, 0 replies; 200+ results
From: Larry McVoy @ 1996-04-19 21:52 UTC (permalink / raw)
To: linux
Hi-
as some of you know, we've been negociating to get David Miller,
the Sparc/Linux guy, to come out and work on a MIPS/Linux port. He has
accepted, he starts on May 25th, and will be here until August 25th.
We had to do a lot of work with the laywers, but we have agreement that
all of the work that he does here will be
a) owned by SGI (we paid for it), and b) distributed under the
terms of the GPL.
No exceptions. SGI owns the code so we can choose to use anything that
turns out to be interesting inside IRIX without the constraints of the
GPL (you may or may not be aware that the owner of the code can choose
to distribute the code under multiple copyrights - so we can use stuff
in IRIX without "polluting" the IRIX kernel with the GPL).
I'd like to thank everyone that has been pulling for this, and especially
Greg Chesson who did the hard work of getting the contract hammered out
to the satisfaction of SGI & David.
We are currently in the process of figuring out what code we can use to
help with the port; there may be parts of the setup OS that are both
appropriate and useful.
Ariel and others are working to get a development machine set up in
the engr domain. It will be linux.engr.sgi.com, and should be up and
running on Monday or Tuesday.
I'll keep you posted on new news as it happens.
--lm
---
Larry McVoy lm@sgi.com http://reality.sgi.com/lm (415) 933-1804
Copyright 1996, all rights reserved. Microsoft Network is prohibited from
redistributing this work in any form, in whole or in part without license.
License to distribute this work is available to Microsoft at $500.
Transmission without permission constitutes an agreement to these terms.
^ permalink raw reply [relevance 1%]
* MIPS port kickoff meeting
@ 1996-04-20 0:22 1% Ariel Faigon
1996-04-23 14:15 1% ` Alistair Lambie
0 siblings, 1 reply; 200+ results
From: Ariel Faigon @ 1996-04-20 0:22 UTC (permalink / raw)
To: linux
Hi LinuxMIPSies,
This is becoming real. Please mark your calendars.
We have Jamaica in B10U, which holds 12 people, from 4-5pm
on Wednesday April 24th.
I know it may conflict with someone's schedule but p l e a s e
try your best to show up.
THE MEETING HAS ONE MAIN GOAL:
To ensure that when David Miller lands at SGI he wastes
zero time on ramping up. We can do a lot until he comes.
The idea Jim Barton, Larry and I had is:
1) Office + two Indys (connected via a serial line to support
gdb remote protocol) already waiting, phone, email etc.
2) Development tools installed
3) The latest linux sources on the machine. After trying to
compile them and see how smoothly this goes.
4) This may require the most work:
A 99% stripped down IRIX or set-top box thing that is
basically only the device drivers to boot and do:
"hello console"
"hello network"
"hello disk"
"hello keyboard"
"hello console graphics"
Given all this, David can boot Linux in a few days I guess :-)
Agenda:
1) Quick round table: introduce everyone
2) Sort out some details:
Are we going for a 64-bit kernel?
What MIPS instruction set should we support
[e.g. 3K is important for the embedded market]
What dev tools should we use?
elf/coff stabs/dwarf gcc/cc etc. etc.
4) Suggest more ways to accelerate David Miller's ramp up
5) List action items
6) Get volunteers for help on the above
Lastly, since David's Acceptance is final. I think it is time
to put David himself on this mailing list too, he certainly has
some ideas on how to help us help him.
--
Peace, Ariel
^ permalink raw reply [relevance 1%]
* SparcLinux humorous comments..
@ 1996-04-20 8:16 1% David S. Miller
0 siblings, 0 replies; 200+ results
From: David S. Miller @ 1996-04-20 8:16 UTC (permalink / raw)
To: lm; +Cc: torvalds, humor, user, lmlinux, adrian
Check it out:
/* There was a great cache from TI
* with comfort as much as vi,
* 4 pages to flush,
* 4 pages, no rush,
* since anything else makes him die.
*/
;-)
Later,
David S. Miller
davem@caip.rutgers.edu
^ permalink raw reply [relevance 1%]
* Re: David Miller is on the list
[not found] <199604230116.SAA28514@yon.engr.sgi.com>
@ 1996-04-23 1:40 1% ` David S. Miller
1996-04-23 2:16 1% ` Ariel Faigon
` (2 more replies)
0 siblings, 3 replies; 200+ results
From: David S. Miller @ 1996-04-23 1:40 UTC (permalink / raw)
To: ariel; +Cc: linux
From: ariel@yon.engr.sgi.com (Ariel Faigon)
Date: Mon, 22 Apr 1996 18:16:30 -0700 (PDT)
Great, now you can tell the list what do you need :-)
Oh boy.
Seriously, we've been thinking about how we could make you most
productive and not waste your time when you arrive here.
Here's a recent posting of mine, so you get the idea just in case
Simon or Bob or Larry didn't tell you about all this yet...
Feel free to bombard us with requests/questions.
There are about 20 people on the linux list at SGI
(you can query majordomo@engr.sgi.com for the details)
Already did that an hour ago ;)
(note: I looked back over this mail after composing it and I want to
warn people who are not familiar with me yet that I am very
sarcastic and am full of ridicule even when discussing
important topics. Please don't take it that I lack tact
or am not being serious, because that simply isn't the case.)
Here is what I need:
The following utilities I need for development.
1) CVS/RCS, latest on prep.ai.mit.edu is fine
2) Emacs-19.31 (rms should release within 2 weeks)
3) All GNU smidgen-type utilies as the default binaries
(this include fileutils/sh-utils/sharutils/diffutils/
findutils/...)
Actually, Let me just stop short and say, if there is a
source tarball for it on prep.ai.mit.edu:/pub/gnu I would
like the latest installed on the machine I develop on.
4) xfishtank (don't laugh)
5) fvwm
6) teco (Must support full teco command set as described
in original DEC manuals! TECO is _the_ renaissance editor!)
The following would be nice, but if it will give people
bladder problems to do these then don't go out of your
way:
1) MIPS 4[40]00 manual is some online format (not postscript,
something I can cut and paste out of an emacs buffer etc.
so maybe info or pure ascii text would be fine, I could
care less about the formatting, I just want the words
there)
2) Docs on the ethernet/scsi interfaces and I/O bus
architecture for the first machine I will be getting
this to work on, again text/info format would be nice.
Of course I will probably just stuff in the ready
drivers you might be getting to me into Linux but I want
to write my own from scratch in the near future after
that.
3) I know as much as a bum on the street about SGI machines
and the various lines, a nice "roadmap to sgi workstations
and servers, plus the hardware gook thats inside" type
thing would be very useful to me.
I will feel more comfortable if:
1) I became very familiar with who the heavy low level MIPS
assembly level hackers are who I will be dealing with while
I am there. Please tell me who they are, introduce, make
us say hello to each other, you get the idea.
2) I know the policy on loud music in the office I'll be in
;-)
I've thought it over and to me the best plan for things this summer to
me is:
a) R4400 32-bit "proof of concept, yeah we can pull it off"
port happens first, side effect is that I become intimate
enough with the chip that I can do things more efficiently.
b) From here we look into the 64-bit stuff and whether that is
is even desirable on 64-bit. (this would be my first
64-bit port outside of my initial UltraSparc hacks)
c) Also think about the work needed to turn that code into
r3000 friendly code. Should not be too much as I've done
the "write it on recent architecture design then backport
it to older design which had some limitations" already and
this didn't end up being so bad.
Expect more as I think it up... this should keep you guys busy for
now.
(Any dead-head tape traders at SGI engineering? Just wondering, may
want to start talking to them now ;-)
Later,
David S. Miller
davem@caip.rutgers.edu
^ permalink raw reply [relevance 1%]
* Re: MIPS port kickoff meeting
1996-04-20 0:22 1% MIPS port kickoff meeting Ariel Faigon
@ 1996-04-23 14:15 1% ` Alistair Lambie
0 siblings, 0 replies; 200+ results
From: Alistair Lambie @ 1996-04-23 14:15 UTC (permalink / raw)
To: linux
On Apr 19, 5:22pm, Ariel Faigon wrote:
> Subject: MIPS port kickoff meeting
> Hi LinuxMIPSies,
>
> This is becoming real. Please mark your calendars.
>
> We have Jamaica in B10U, which holds 12 people, from 4-5pm
> on Wednesday April 24th.
>
> I know it may conflict with someone's schedule but p l e a s e
> try your best to show up.
>
Umm...could be a problem. It's a holiday here in New Zealand, otherwise :-)
>
> Agenda:
> 1) Quick round table: introduce everyone
> 2) Sort out some details:
> Are we going for a 64-bit kernel?
> What MIPS instruction set should we support
> [e.g. 3K is important for the embedded market]
> What dev tools should we use?
> elf/coff stabs/dwarf gcc/cc etc. etc.
My 2c worth:
1. We should definitely do 32bit, probably 64bit as well. There is a
big base of R3k machines out there that are going to start getting
left behind soon.
2. We need to go for lowest common denominator (MIPS I) and then add
conditionals (in the low level bits) later. The c code can of course be
compiled as the user wants it.
3. We need to support machines that don't have a graphics head (servers).
This requires serial drivers.
4. We should really tie this project in with what is happening at
http://lena.fnet.fr/. Their goal has been to get Linux on ARCS systems
running little endian, but there is a need for a MIPS port for MIPS (the
company) R3k machines which needs to be big endian.
5. Should we use the 'milo' bootloader?
6.
> 4) Suggest more ways to accelerate David Miller's ramp up
> 5) List action items
> 6) Get volunteers for help on the above
>
Probably not much I can do from here. Maybe some Beta testing a bit further
down the track (test for bit inversion in the southern hemisphere :-) ).
I still have an interest in getting Linux on to the old MIPS boxes, so maybe
with a few quick hacks after David has worked his magic I can get this to
happen. I suspect that this would also help CSD out as I know they still get
support calls from people who have these machines and are falling all over the
place with the development environment (svr3, bsd43, svr4). Often they are
little more than people playing and having a Linux offering may be the best way
to get them out of our hair. Also, RISC/os is getting a bit long in the tooth
now and there are still some nasty little bugs in it, often comms related which
more often than not is what the person wanted it for!
One thing that would be nice is for someone to minute the meeting to the list
so that those of us who can't attend can see what's happening. I guess it is
also a good way of documenting the progress as things move along!
Cheers, Alistair
--
Alistair Lambie alambie@wellington.sgi.com
Silicon Graphics New Zealand SGI Voicemail: 56791
Level 5, Walsh Wrightson Tower, Ph: +64-4-802 1455
94-96 Dixon St, Wellington, NZ Fax: +64-4-802 1459
^ permalink raw reply [relevance 1%]
* Re: David Miller is on the list
1996-04-23 1:40 1% ` David Miller is on the list David S. Miller
@ 1996-04-23 2:16 1% ` Ariel Faigon
1996-04-23 2:27 1% ` David S. Miller
` (2 more replies)
1996-04-23 16:35 1% ` William J. Earl
1996-04-23 16:56 1% ` Bob Mende Pie
2 siblings, 3 replies; 200+ results
From: Ariel Faigon @ 1996-04-23 2:16 UTC (permalink / raw)
To: linux
>
>(note: I looked back over this mail after composing it and I want to
> warn people who are not familiar with me yet that I am very
> sarcastic and am full of ridicule even when discussing
> important topics. Please don't take it that I lack tact
> or am not being serious, because that simply isn't the case.)
>
Feel free to express yourself, my english (colloquial and otherwsie)
is bad anyway, and I guess the others don't care :-)
>Here is what I need:
>
> The following utilities I need for development.
> 1) CVS/RCS, latest on prep.ai.mit.edu is fine
>
RCS comes default with IRIX today. But I know it is not
the latest. OK, and I'll add cvs.
> 2) Emacs-19.31 (rms should release within 2 weeks)
> 3) All GNU smidgen-type utilies as the default binaries
> (this include fileutils/sh-utils/sharutils/diffutils/
> findutils/...)
> Actually, Let me just stop short and say, if there is a
> source tarball for it on prep.ai.mit.edu:/pub/gnu I would
> like the latest installed on the machine I develop on.
>
Many of these are in our freeware project. Ready to install with
the click of a mouse. (Yes, one of the cool things about SGI is
a joe-user software installer infinitely better than RPM/glint.)
(yon) 84 /var/tmp> which find
/usr/freeware/bin/find
(yon) 85 /var/tmp> which tar
/usr/freeware/bin/tar
(yon) 86 /var/tmp> which grep
/usr/freeware/bin/grep
(yon) 87 /var/tmp> which chmod
/usr/freeware/bin/chmod
I'll add the missing ones. That's easy.
BTW, we called it '/usr/freeware' rather than '/usr/gnu' because
many packages are from other sources and because some of our
customers asked us to stay away from their /usr/local.
> 4) xfishtank (don't laugh)
>
Bingo. Larry runs this too. You weird people. Is this a conspiracy? :-)
> 5) fvwm
>
> 6) teco (Must support full teco command set as described
> in original DEC manuals! TECO is _the_ renaissance editor!)
>
I'll try to build these too.
> The following would be nice, but if it will give people
> bladder problems to do these then don't go out of your
> way:
> 1) MIPS 4[40]00 manual is some online format (not postscript,
> something I can cut and paste out of an emacs buffer etc.
> so maybe info or pure ascii text would be fine, I could
> care less about the formatting, I just want the words
> there)
For MIPS ABI stuff: try the following web site,
http://www.mipsabi.org/
Especially:
http://www.mipsabi.org/Tech/Technical.html
Tell us what's missing there.
As for the MIPS programmer's Assembly manual. There is an excellent one
internally on the Web... I'll try to get you a copy soon.
> 2) Docs on the ethernet/scsi interfaces and I/O bus
> architecture for the first machine I will be getting
> this to work on, again text/info format would be nice.
> Of course I will probably just stuff in the ready
> drivers you might be getting to me into Linux but I want
> to write my own from scratch in the near future after
> that.
> 3) I know as much as a bum on the street about SGI machines
> and the various lines, a nice "roadmap to sgi workstations
> and servers, plus the hardware gook thats inside" type
> thing would be very useful to me.
>
I'll leave these to some other folks on the list.
> I will feel more comfortable if:
> 1) I became very familiar with who the heavy low level MIPS
> assembly level hackers are who I will be dealing with while
> I am there. Please tell me who they are, introduce, make
> us say hello to each other, you get the idea.
>
I believe the most knowledgable low-level gurus on the list are
Bill Earl and Jim Barton, I'm sure there are more, I just don't
know everyone on the list personally ...
> 2) I know the policy on loud music in the office I'll be in
> ;-)
>
I'm trying to get you an office right by mine :-)
>I've thought it over and to me the best plan for things this summer to
>me is:
> a) R4400 32-bit "proof of concept, yeah we can pull it off"
> port happens first, side effect is that I become intimate
> enough with the chip that I can do things more efficiently.
> b) From here we look into the 64-bit stuff and whether that is
> is even desirable on 64-bit. (this would be my first
> 64-bit port outside of my initial UltraSparc hacks)
> c) Also think about the work needed to turn that code into
> r3000 friendly code. Should not be too much as I've done
> the "write it on recent architecture design then backport
> it to older design which had some limitations" already and
> this didn't end up being so bad.
>
Cool.
>Expect more as I think it up... this should keep you guys busy for
>now.
>
>(Any dead-head tape traders at SGI engineering? Just wondering, may
> want to start talking to them now ;-)
>
You'll find lots of them here ;-)
--
Peace, Ariel
^ permalink raw reply [relevance 1%]
* Re: David Miller is on the list
1996-04-23 2:16 1% ` Ariel Faigon
@ 1996-04-23 2:27 1% ` David S. Miller
1996-04-23 2:55 1% ` jon madison
1996-04-23 17:06 1% ` Jim Barton
2 siblings, 0 replies; 200+ results
From: David S. Miller @ 1996-04-23 2:27 UTC (permalink / raw)
To: ariel; +Cc: linux
From: ariel@yon.engr.sgi.com (Ariel Faigon)
Date: Mon, 22 Apr 1996 19:16:30 -0700 (PDT)
>
>(note: I looked back over this mail after composing it and I want to
> warn people who are not familiar with me yet that I am very
> sarcastic and am full of ridicule even when discussing
> important topics. Please don't take it that I lack tact
> or am not being serious, because that simply isn't the case.)
>
Feel free to express yourself, my english (colloquial and otherwsie)
is bad anyway, and I guess the others don't care :-)
Cool, I feel much more comfortable now ;)
> 4) xfishtank (don't laugh)
>
Bingo. Larry runs this too. You weird people. Is this a conspiracy? :-)
Nope, not a conspiracy. Grab a copy of:
caip.rutgers.edu:/pub/davem/penguin.gif
Then run 'xfishtank -p penguin.gif' after hacking endlessly on down
and dirty kernel code for 20 hours straight with no sleep and direct
intraveinus coffee keeping you going, and tell me that isn't the damn
most funniest thing you've ever seen in your life. (note said
description is the state I am in right now, whee... oh yeah, and the
penguin picture was found in Linus's home directory on
linux.cs.helsinki.fi one late night I was hacking on there :)
For MIPS ABI stuff: try the following web site,
http://www.mipsabi.org/
Especially:
http://www.mipsabi.org/Tech/Technical.html
Tell us what's missing there.
As for the MIPS programmer's Assembly manual. There is an excellent one
internally on the Web... I'll try to get you a copy soon.
Noted, I'll check some of that out. Thanks.
>(Any dead-head tape traders at SGI engineering? Just wondering, may
> want to start talking to them now ;-)
>
You'll find lots of them here ;-)
Oh, yummy, heaven on earth.
Later,
David S. Miller
davem@caip.rutgers.edu
^ permalink raw reply [relevance 1%]
* Re: David Miller is on the list
@ 1996-04-23 2:35 1% Larry McVoy
1996-04-23 16:35 0% ` Bob Mende Pie
0 siblings, 1 reply; 200+ results
From: Larry McVoy @ 1996-04-23 2:35 UTC (permalink / raw)
To: David S. Miller; +Cc: ariel, linux
: > 4) xfishtank (don't laugh)
: >
: Bingo. Larry runs this too. You weird people. Is this a conspiracy? :-)
:
: Nope, not a conspiracy. Grab a copy of:
:
: caip.rutgers.edu:/pub/davem/penguin.gif
:
: Then run 'xfishtank -p penguin.gif' after hacking endlessly on down
Nah, try this:
xearth &
xfishtank -d
Fish in spaaaaaaaaaaaaaaace!
^ permalink raw reply [relevance 1%]
* Re: David Miller is on the list
1996-04-23 2:16 1% ` Ariel Faigon
1996-04-23 2:27 1% ` David S. Miller
@ 1996-04-23 2:55 1% ` jon madison
1996-04-23 17:06 1% ` Jim Barton
2 siblings, 0 replies; 200+ results
From: jon madison @ 1996-04-23 2:55 UTC (permalink / raw)
To: ariel; +Cc: linux
Ariel Faigon quoted, a little while back,
#> 5) fvwm
ariel, if you can't i'll swing it (i run bowman here...(bowman's
a 'better' fvwm (looks like NeXTStep...the GoodStuff is like NeXT's
dock)
j.
--
jon madison, silicon graphics, inc.
us: <URL: http://www.sgi.com/>
mailto:jm@sgi.com
me: <URL: http://klingon.iupucs.iupui.edu/~jmadison/>
^ permalink raw reply [relevance 1%]
* Re: David Miller is on the list
1996-04-23 2:35 1% Larry McVoy
@ 1996-04-23 16:35 0% ` Bob Mende Pie
0 siblings, 0 replies; 200+ results
From: Bob Mende Pie @ 1996-04-23 16:35 UTC (permalink / raw)
To: Larry McVoy, David S. Miller; +Cc: ariel, linux
On Apr 22, 7:35pm, Larry McVoy wrote:
> Subject: Re: David Miller is on the list
> : > 4) xfishtank (don't laugh)
> : >
> : Bingo. Larry runs this too. You weird people. Is this a conspiracy? :-)
> :
> : Nope, not a conspiracy. Grab a copy of:
> :
> : caip.rutgers.edu:/pub/davem/penguin.gif
> :
> : Then run 'xfishtank -p penguin.gif' after hacking endlessly on down
>
> Nah, try this:
>
> xearth &
> xfishtank -d
>
> Fish in spaaaaaaaaaaaaaaace!
And all of the fish are bubbling the same thing ... "cpu ... more cpu ..."
:-)
--
/Bob... mende@sgi.com
http://reality.sgi.com/mende/
^ permalink raw reply [relevance 0%]
* Re: David Miller is on the list
@ 1996-04-23 16:35 0% ` Bob Mende Pie
0 siblings, 0 replies; 200+ results
From: Bob Mende Pie @ 1996-04-23 16:35 UTC (permalink / raw)
To: Larry McVoy, David S. Miller; +Cc: ariel, linux
On Apr 22, 7:35pm, Larry McVoy wrote:
> Subject: Re: David Miller is on the list
> : > 4) xfishtank (don't laugh)
> : >
> : Bingo. Larry runs this too. You weird people. Is this a conspiracy? :-)
> :
> : Nope, not a conspiracy. Grab a copy of:
> :
> : caip.rutgers.edu:/pub/davem/penguin.gif
> :
> : Then run 'xfishtank -p penguin.gif' after hacking endlessly on down
>
> Nah, try this:
>
> xearth &
> xfishtank -d
>
> Fish in spaaaaaaaaaaaaaaace!
And all of the fish are bubbling the same thing ... "cpu ... more cpu ..."
:-)
--
/Bob... mende@sgi.com
http://reality.sgi.com/mende/
^ permalink raw reply [relevance 0%]
* Re: David Miller is on the list
1996-04-23 1:40 1% ` David Miller is on the list David S. Miller
1996-04-23 2:16 1% ` Ariel Faigon
@ 1996-04-23 16:35 1% ` William J. Earl
1996-04-23 16:56 1% ` Bob Mende Pie
2 siblings, 0 replies; 200+ results
From: William J. Earl @ 1996-04-23 16:35 UTC (permalink / raw)
To: David S. Miller; +Cc: ariel, linux
David S. Miller writes:
> From: ariel@yon.engr.sgi.com (Ariel Faigon)
> Date: Mon, 22 Apr 1996 18:16:30 -0700 (PDT)
...
> 1) MIPS 4[40]00 manual is some online format (not postscript,
> something I can cut and paste out of an emacs buffer etc.
> so maybe info or pure ascii text would be fine, I could
> care less about the formatting, I just want the words
> there)
The manuals are online, generally at www,mips.com. For example,
http://www.mips.com/r4400/UMan/R4400_UM_cv.html
is the latest R4400 manual.
Our newer processors for low-end systems are the R4600 and now the
R5000. Most Indy systems now ship with R5000 processors, and the Indy should
be the target for the initial port, since it is in current production and
widely available.
The R4600 and R5000 are generally similar, except that the R4600
has 16 KB primary caches and is MIPS III, whereas the R5000 has 32 KB
primary caches and is MIPS IV. Both are fairly similar to the R4000PC
and R4400PC, in the sense that they do not have a secondary cache
which enforces primary cache virtual index coherency. (Many Indy
R4600 and R5000 systems do have secondary caches, but they do not
supply virtual coherency exceptions.) The R4600 and R5000 are good
targets for an initial port, because they have the fewest errata, and
hence require the fewest kernel workarounds. The R4000 workarounds,
in particular, are pretty messy.
The R4600 and R5000 data sheets may be found via
http://www.idt.com/risc/Welcome.html
(under the 64-bit RISC microprocessors category). The manuals are not online
on public servers, but I can track down copies. There is some more
R4600 and R5000 information under
http://www.qedinc.com/
There is a comparison of the R4400 and the R4600 at
http://www.mips.com/r4400/Des_Com/Des_Com_cv.html
The MIPS IV architecture document is
http://www.mips.com/arch/MIPS4_cv.html
This is of relatively minor importance for a basic port, but can be used
to good effect to improve graphics and application performance. There are
a few minor kernel support issues.
Once the basic port is done, extending it to the other common processors,
such as the R3000, R4000, R4400, and R10000, will be fairly simple. The R6000
(not common and obsolete for some years now) and the R8000 would be somewhat
more work to support, since they differ more from the other processors in
the kernel interface.
> 2) Docs on the ethernet/scsi interfaces and I/O bus
> architecture for the first machine I will be getting
> this to work on, again text/info format would be nice.
> Of course I will probably just stuff in the ready
> drivers you might be getting to me into Linux but I want
> to write my own from scratch in the near future after
> that.
I have the documents for the memory controller for Indy, and I think
I can locate most of the others. They are only on paper, however, but I can
get copies.
> 3) I know as much as a bum on the street about SGI machines
> and the various lines, a nice "roadmap to sgi workstations
> and servers, plus the hardware gook thats inside" type
> thing would be very useful to me.
There are tables of the systems under
http://ssales.corp.sgi.com/products/html/periodic_table.html
Unfortunately, these are inside the firewall.
> I will feel more comfortable if:
> 1) I became very familiar with who the heavy low level MIPS
> assembly level hackers are who I will be dealing with while
> I am there. Please tell me who they are, introduce, make
> us say hello to each other, you get the idea.
I am probably the best initial contact for Indy issues, and I can
introduce you to people familiar with the various drivers and so on.
...
> I've thought it over and to me the best plan for things this summer to
> me is:
> a) R4400 32-bit "proof of concept, yeah we can pull it off"
> port happens first, side effect is that I become intimate
> enough with the chip that I can do things more efficiently.
As I mentioned above, the R4600 and R5000 processors are a simpler
initial target, and the Indy R4600 is the most common configuration.
> b) From here we look into the 64-bit stuff and whether that is
> is even desirable on 64-bit. (this would be my first
> 64-bit port outside of my initial UltraSparc hacks)
This is mainly interesting on the larger systems. 64-bit kernels
do take more space and time (due to extra cache misses, if nothing else),
and most applications don't need more than 32-bit addresses. The 32-bit
kernel should, however, support using 64-bit arithmetic (MIPS III and IV)
even in 32-bit programs, since there are substantial performance gains
available for certain applications. The kernel itself can use 64-bit
arithmetic to good effect as well. (This is how IRIX works.)
> c) Also think about the work needed to turn that code into
> r3000 friendly code. Should not be too much as I've done
> the "write it on recent architecture design then backport
> it to older design which had some limitations" already and
> this didn't end up being so bad.
The R3000 is not drastically different from the R4600. The main
differences are somewhat different TLB and cache control routines, and, of
course, the MIPS I instruction set.
^ permalink raw reply [relevance 1%]
* Re: David Miller is on the list
1996-04-23 1:40 1% ` David Miller is on the list David S. Miller
1996-04-23 2:16 1% ` Ariel Faigon
1996-04-23 16:35 1% ` William J. Earl
@ 1996-04-23 16:56 1% ` Bob Mende Pie
1996-04-24 1:58 1% ` David S. Miller
2 siblings, 1 reply; 200+ results
From: Bob Mende Pie @ 1996-04-23 16:56 UTC (permalink / raw)
To: David S. Miller, ariel; +Cc: linux
On Apr 22, 9:40pm, David S. Miller wrote:
> 5) fvwm
I've got 2.0.42 compiled and running ... But if dave wants to live in the dark
ages of fvwm 1.x thats fine with me.
> 6) teco (Must support full teco command set as described
> in original DEC manuals! TECO is _the_ renaissance editor!)
I've got it compiled, but beats the hell out of me if it works :-) Ill make
you a deal, if I see you edit a file with it I bring you my honest to god DEC
PDP-11 teco manual.
--
/Bob... mende@sgi.com
http://reality.sgi.com/mende/
^ permalink raw reply [relevance 1%]
* Re: David Miller is on the list
1996-04-23 2:16 1% ` Ariel Faigon
1996-04-23 2:27 1% ` David S. Miller
1996-04-23 2:55 1% ` jon madison
@ 1996-04-23 17:06 1% ` Jim Barton
2 siblings, 0 replies; 200+ results
From: Jim Barton @ 1996-04-23 17:06 UTC (permalink / raw)
To: ariel, linux
The purpose for basing the port on R3000 is *not* to support obsolete
workstations and servers; our time and effort need to be directed to the
future, not the past. If the guys in OZ want to port it, fine.
Basing on an R3000 is important because of it's exploding use as an
embedded processor; it's showing up in your laser printers, phone
switches, robots, airplanes, satellite receivers, and so on. One thing
Larry and I are interested in is seeing if Linux is really suitable
as an embedded OS to support these (and more) applications.
What you typically find is an r3k core surrounded by various application-
specific peripherals, e.g, MPEG decoders, sound chips, DMA controllers,
serial controllers. The OS is usually in ROM, and the device manufacturer
adds special drivers to the mix. Real-time constraints come into play;
in particular, it would be interesting to consider what additions to Linux
make it work well for real-time applications. Posix 1003.4 is pretty
heavy-weight, but perhaps we can have a light-weight implementation.
In the workstation/server world, the R4000 is the processor to aim at.
It is significantly different than the r3k in TLB layout, but little
else in 32-bit mode, so the same code should basically work both places.
I believe different binaries should be built for the r4k and r3k - certain
pieces of MIPS II ISA can accelerate performance, and the compilers take
advantage of that.
Given that the workstation/server world is moving to 64 bit, I believe we
need a 64-bit version of Linux as well. The design of the MIPS III ISA
is actually pretty clean for keeping the same source between 32-bit and
64-bit kernels, as long as you are careful about your types.
The r4k is also interesting because it is at the heart of the Nintendo
Ultra-64 game, and the R4300i processor it uses is starting to show up
in various Japanese computer products. The volumes of this device are
projected in the 10s of millions of units, so it is significant. Linux
in your Ultra-64 box? Hmmmm. Might actually be interesting ...
So, we need to be able to build three versions from the same source.
I think the R10K can be ignored for now, and it *only* runs in 64-bit
kernel mode. 64-bit user mode can also be ignored for now - there are
few applications for 64-bit programs except in the high-end scientific
markets. The R8K is obsolete.
-- jmb
^ permalink raw reply [relevance 1%]
* Re: MIPS port kickoff meeting
@ 1996-04-23 17:22 1% Larry McVoy
0 siblings, 0 replies; 200+ results
From: Larry McVoy @ 1996-04-23 17:22 UTC (permalink / raw)
To: Greg Chesson; +Cc: Alistair Lambie, linux
Greg said:
: There are US Gov't customers for Linux on SGI boxes who require
: 64-bit OS. So, let's support tho 32-bit ARCS boxes without compromising
: opportunities to sell new boxes (with 64-bit Linux).
We definitely want to do this. And I don't want to do anything to derail
this because I want this badly. And what I'm about to say does not imply
that we don't do 64bit - I want both. And it should be easy to do both.
One reason for thinking small, however, is that we could finesse the whole
Linux vs IRIX issue by raising awareness that Linux on MIPs could be a
really nice solution for the embedded market. I personally would love
to see a full page in IEEE times in which MIPS announces the availablity
of embedded Linux for MIPs chips. This may be the quickest path to getting
Linux embraced internally. I'm pretty sure that Cygnus would be interested
in signing up for support for such a platform - that is a big part of their
business. And I think that R3K is still the volume chip in the embedded
market, so we want that to work.
Thoughts?
^ permalink raw reply [relevance 1%]
* Re: David Miller is on the list
@ 1996-04-23 19:51 1% Mike McDonald
1996-04-23 20:20 1% ` William J. Earl
1996-04-23 20:26 1% ` What target (was David ...) Ariel Faigon
0 siblings, 2 replies; 200+ results
From: Mike McDonald @ 1996-04-23 19:51 UTC (permalink / raw)
To: David S. Miller; +Cc: linux
A dumb question, what exactly is the purpose of porting Linux to
SGI/Mips boxes? At one time, it was proposed as a way that all of the
people how just got dropped from support to maintain there machine's
usefull life. Now, people are talking about embedding linux in
printers and Nintendo boxes! Or as an alternative to Irix on our
current machines. Personally, I think the port should concentrate on
R3K boxes with/without graphics. (It'd be nice if we could release the
info so that X11R6 could be built on the old boxes.) The port should
be a 32 bit port. (Does gcc even support 64 bit MIPS 27 ISA?) It also
be nice if the R3K port would also work on the R4K machines that are
fading away, ie. Indy's, Indigo2's.
Mike McDonald
mikemac@engr.sgi.com
^ permalink raw reply [relevance 1%]
* Re: David Miller is on the list
1996-04-23 19:51 1% David Miller is on the list Mike McDonald
@ 1996-04-23 20:20 1% ` William J. Earl
1996-04-23 20:26 1% ` What target (was David ...) Ariel Faigon
1 sibling, 0 replies; 200+ results
From: William J. Earl @ 1996-04-23 20:20 UTC (permalink / raw)
To: Mike McDonald; +Cc: linux
Mike McDonald writes:
>
>
> A dumb question, what exactly is the purpose of porting Linux to
> SGI/Mips boxes? At one time, it was proposed as a way that all of the
> people how just got dropped from support to maintain there machine's
> usefull life. Now, people are talking about embedding linux in
> printers and Nintendo boxes! Or as an alternative to Irix on our
> current machines. Personally, I think the port should concentrate on
> R3K boxes with/without graphics. (It'd be nice if we could release the
> info so that X11R6 could be built on the old boxes.) The port should
> be a 32 bit port. (Does gcc even support 64 bit MIPS 27 ISA?) It also
> be nice if the R3K port would also work on the R4K machines that are
> fading away, ie. Indy's, Indigo2's.
Different people have different motivations, and you have heard
some of them. My main interest is in two parts. First, on
current-production low-end workstations, I would like to compare linux
performance to IRIX performance. If linux is much better on most
measures, in ways which matter to end users, then we would need to
consider it as a choice for low-end systems. If it is better only in
some dimensions, then we can use it as an existence proof that there
are ways to improve IRIX in those dimensions. It is hard to compare
software running on different hardware, but software running on
identical hardware is directly comparable.
Second, I believe that UNIX-based systems are gratuitously incompatible,
compared to NT, and that this is an impediment to competing against NT in
low-end servers and workstations. Since most efforts to standardize
interfaces and administration for UNIX systems have been very slow and
incomplete, due to conflicting interests of the vendors involved, I would
like to try using linux as a vehicle for creating a de facto standard.
Where appropriate, we should give away some enabling technology, such
as Web-based administration scripts. We really compete on application
performance. Trying compete in areas such as administrative commands,
which are peripheral to the user's main interests, is, on balance, almost
certainly counterproductive. This will be even more the case as we begin
selling into larger installations (with a large number of units, not the
odd one or two systems we often sell at present).
linux for older boxes is a fine thing, and not unduly difficult
to do, at least on the workstations, but there are a lot more
R4000-and-better boxes out there now. As for embedded systems, there
are actually pretty decent real time systems, some with POSIX
compliance, which support MIPS processors. I doubt that the success
of MIPS processors in embedded systems is much limited by software
availability.
^ permalink raw reply [relevance 1%]
* What target (was David ...)
1996-04-23 19:51 1% David Miller is on the list Mike McDonald
1996-04-23 20:20 1% ` William J. Earl
@ 1996-04-23 20:26 1% ` Ariel Faigon
1996-04-23 20:54 1% ` Mike McDonald
1996-04-23 22:39 1% ` Greg Chesson
1 sibling, 2 replies; 200+ results
From: Ariel Faigon @ 1996-04-23 20:26 UTC (permalink / raw)
To: linux
Mike asked (not a dumb Q, BTW):
>
> A dumb question, what exactly is the purpose of porting Linux to
>SGI/Mips boxes?
>
Looks like there are many opinions. I don't care as long as we
manage to do this port. Whatever we port it to (and the wider the
port is) SGI is going to benefit tremendously. You may read
my Linux pages (http://info.engr/~ariel/linux) to understand why
my personal conviction (and others) is so strong.
Some of the nice things about Linux are:
1) It can work from RAM (virtual disk),
So it follows that it is easily ROMable and
embeddable (much more so than IRIX)
I have developed embedded apps for several years in my past
and I can tell you that my life would have been infinitely
easier had I been able to develop in a Linux env.
Only the thought of having the same env on the host
and the target is revolutionary by itself (and possible!)
2) It has a small footprint so naturally it is a good candidate
for embedded market.
3) It has a common single source code for 32-bit and 64-bit
machines (Alpha). So we shouldn't think of this as an "either/or"
proposition.
P.S.
gcc doesn't have support for 64 bit MIPS 27 ISA, I guess, but
nobody is stopping us from using our compilers (as well as gcc
at our convenience).
--
Peace, Ariel
^ permalink raw reply [relevance 1%]
* Re: What target (was David ...)
1996-04-23 20:26 1% ` What target (was David ...) Ariel Faigon
@ 1996-04-23 20:54 1% ` Mike McDonald
1996-04-23 22:27 1% ` Ariel Faigon
1996-04-23 22:39 1% ` Greg Chesson
1 sibling, 1 reply; 200+ results
From: Mike McDonald @ 1996-04-23 20:54 UTC (permalink / raw)
To: ariel; +Cc: linux
>From: ariel@yon (Ariel Faigon)
>Subject: What target (was David ...)
>To: linux@yon
>Date: Tue, 23 Apr 1996 13:26:53 -0700 (PDT)
>P.S.
>gcc doesn't have support for 64 bit MIPS 27 ISA, I guess, but
>nobody is stopping us from using our compilers (as well as gcc
>at our convenience).
>--
>Peace, Ariel
I strongly believe that using our compilers would be a "bad" thing
for the initial port. Requiring someone to buy IDO inorder to compile
a free OS seems like the "wrong" thing to me. Now, if we (SGI) decide
to ship a Linux version, then yes, using our compilers is OK. Let's
just make sure that the port is dependant on our compilers in any way
at this point. (I doubt that's what you were suggesting. I just want
to make it clear before we get started.)
Mike McDonald
mikemac@engr.sgi.com
^ permalink raw reply [relevance 1%]
* Re: What target (was David ...)
1996-04-23 20:54 1% ` Mike McDonald
@ 1996-04-23 22:27 1% ` Ariel Faigon
0 siblings, 0 replies; 200+ results
From: Ariel Faigon @ 1996-04-23 22:27 UTC (permalink / raw)
To: Mike McDonald; +Cc: ariel, linux
>Mike dijo:
>>yo dijo:
>>
>>P.S.
>>gcc doesn't have support for 64 bit MIPS 27 ISA, I guess, but
>>nobody is stopping us from using our compilers (as well as gcc
>>at our convenience).
>
> I strongly believe that using our compilers would be a "bad" thing
>for the initial port. Requiring someone to buy IDO inorder to compile
>a free OS seems like the "wrong" thing to me. Now, if we (SGI) decide
>to ship a Linux version, then yes, using our compilers is OK. Let's
>just make sure that the port is dependant on our compilers in any way
>at this point. (I doubt that's what you were suggesting. I just want
>to make it clear before we get started.)
>
>
Bob and I are working separately on making our compilers (actually only
the C one, not Ada :-) be bundled with Irix (and possibly licence enabled
for a nominal fee, which can be done automatically without human
intervention -- surprisingly this may increase revenues because
the cost of handling goes to zero and the potential upside due to
lowering barriers is large). I think we have a very good chance of
acheiving this as soon as our upcoming big software release.
Also, I agree, we should make sure that whatever we do is buildable
by gcc. And we should also be paying Cygnus to do a real supported
full port (including ld), but this is harder to achieve (need $$$
from management) at this point. However, after we have Linux and it
takes off, everything related to free software would be possible :-)
--
Peace, Ariel
^ permalink raw reply [relevance 1%]
* Re: What target (was David ...)
@ 1996-04-23 22:27 1% ` Ariel Faigon
0 siblings, 0 replies; 200+ results
From: Ariel Faigon @ 1996-04-23 22:27 UTC (permalink / raw)
To: Mike McDonald; +Cc: ariel, linux
>Mike dijo:
>>yo dijo:
>>
>>P.S.
>>gcc doesn't have support for 64 bit MIPS 27 ISA, I guess, but
>>nobody is stopping us from using our compilers (as well as gcc
>>at our convenience).
>
> I strongly believe that using our compilers would be a "bad" thing
>for the initial port. Requiring someone to buy IDO inorder to compile
>a free OS seems like the "wrong" thing to me. Now, if we (SGI) decide
>to ship a Linux version, then yes, using our compilers is OK. Let's
>just make sure that the port is dependant on our compilers in any way
>at this point. (I doubt that's what you were suggesting. I just want
>to make it clear before we get started.)
>
>
Bob and I are working separately on making our compilers (actually only
the C one, not Ada :-) be bundled with Irix (and possibly licence enabled
for a nominal fee, which can be done automatically without human
intervention -- surprisingly this may increase revenues because
the cost of handling goes to zero and the potential upside due to
lowering barriers is large). I think we have a very good chance of
acheiving this as soon as our upcoming big software release.
Also, I agree, we should make sure that whatever we do is buildable
by gcc. And we should also be paying Cygnus to do a real supported
full port (including ld), but this is harder to achieve (need $$$
from management) at this point. However, after we have Linux and it
takes off, everything related to free software would be possible :-)
--
Peace, Ariel
^ permalink raw reply [relevance 1%]
* Re: What target (was David ...)
1996-04-23 20:26 1% ` What target (was David ...) Ariel Faigon
1996-04-23 20:54 1% ` Mike McDonald
@ 1996-04-23 22:39 1% ` Greg Chesson
1 sibling, 0 replies; 200+ results
From: Greg Chesson @ 1996-04-23 22:39 UTC (permalink / raw)
To: ariel, linux
I'm pleased that we are getting a Linux port started and that there
is an incredible degree of interest and enthusiasm. This is independent
of which hardware configurations will or should be supported.
I see good reasons for doing all of them.
I hope that the
self-selected "steering committee" will generate some consensus tomorrow
as to priorities. If there is no consensus, then Larry McVoy and I will
make an "executive decision" based on available hardware resources
and a shortest-path approach to getting a first port.
greg
^ permalink raw reply [relevance 1%]
* Re: What target (was David ...)
1996-04-23 22:27 1% ` Ariel Faigon
@ 1996-04-23 22:43 1% ` Greg Chesson
-1 siblings, 0 replies; 200+ results
From: Greg Chesson @ 1996-04-23 22:43 UTC (permalink / raw)
To: ariel, Mike McDonald; +Cc: linux
Right.
The objective with bringing David in has been to get something started....
a first port as an "enabling technology". I believe that many good things
will happen as a result.
greg
^ permalink raw reply [relevance 1%]
* Re: What target (was David ...)
@ 1996-04-23 22:43 1% ` Greg Chesson
0 siblings, 0 replies; 200+ results
From: Greg Chesson @ 1996-04-23 22:43 UTC (permalink / raw)
To: ariel, Mike McDonald; +Cc: linux
Right.
The objective with bringing David in has been to get something started....
a first port as an "enabling technology". I believe that many good things
will happen as a result.
greg
^ permalink raw reply [relevance 1%]
* Re: David Miller is on the list
1996-04-23 16:56 1% ` Bob Mende Pie
@ 1996-04-24 1:58 1% ` David S. Miller
0 siblings, 0 replies; 200+ results
From: David S. Miller @ 1996-04-24 1:58 UTC (permalink / raw)
To: mende; +Cc: ariel, linux
From: "Bob Mende Pie" <mende@piecomputer.corp.sgi.com>
Date: Tue, 23 Apr 1996 09:56:42 -0700
On Apr 22, 9:40pm, David S. Miller wrote:
> 5) fvwm
I've got 2.0.42 compiled and running ... But if dave wants to live in the dark
ages of fvwm 1.x thats fine with me.
Someone else is building 1.24l for me right now methinks... better
check this out before bucking heads ;)
> 6) teco (Must support full teco command set as described
> in original DEC manuals! TECO is _the_ renaissance editor!)
I've got it compiled, but beats the hell out of me if it works :-) Ill make
you a deal, if I see you edit a file with it I bring you my honest to god DEC
PDP-11 teco manual.
[1 J^P$L$$
J <.-Z; .,(S,$ -D .)FX1 @F^B $K :L I $ G1 L>$$
Later,
David S. Miller
davem@caip.rutgers.edu
^ permalink raw reply [relevance 1%]
* Re: MIPS port kickoff meeting
@ 1996-04-24 2:05 1% ` David S. Miller
1996-04-24 4:31 1% ` Greg Chesson
0 siblings, 1 reply; 200+ results
From: David S. Miller @ 1996-04-24 2:05 UTC (permalink / raw)
To: greg; +Cc: alambie, linux
From: "Greg Chesson" <greg@xtp.engr.sgi.com>
Date: Tue, 23 Apr 1996 09:39:29 -0700
There are US Gov't customers for Linux on SGI boxes who require
64-bit OS. So, let's support tho 32-bit ARCS boxes without
compromising opportunities to sell new boxes (with 64-bit Linux).
Like I said I'll do the 32-bit port and work from there based upon how
I feel after that.
Remember I've got one kernel here which works on every 32-bit CPU type
Sun has every put into a box with almost no performance loss. I can
do it too for MIPS and I will. The goal being that some day I will be
able to slap the same kernel image into an INDY as I can for an ONYX
and a LEGO.
And also, I will design it such that, as in the traditional Linux
kernel model, you can config all this shit out and get the streamlined
minimal kernel which only works with a certain configuation. (MM code,
config it out because this is for an embedded system)
Later,
David S. Miller
davem@caip.rutgers.edu
^ permalink raw reply [relevance 1%]
* Re: Naming your machines
[not found] <199604230609.XAA28946@yon.engr.sgi.com>
@ 1996-04-24 2:11 1% ` David S. Miller
0 siblings, 0 replies; 200+ results
From: David S. Miller @ 1996-04-24 2:11 UTC (permalink / raw)
To: ariel; +Cc: linux
From: ariel@yon.engr.sgi.com (Ariel Faigon)
Date: Mon, 22 Apr 1996 23:09:23 -0700 (PDT)
>Actually, here's an important issue. I get to name my machines right?
>
Sure. Do you have some names to ask for?
Unless they are taken (in the engr.sgi.com domain), you got them.
Actually I've been thinking, it's a toss up between five sets of
names right now:
1) "Jarry" and "Garcia"
2) "ccpenguin" and "feathers_mcgraw"
3) "tanya" and "stacy"
4) "filmore-east" and "filmore-west"
5) "ru-east" and "ru-west" bwahahahaha
If anyone likes one in particular, say so. Hey thats it, I'll let
everyone vote on the pair they like and thats the one I'll use ;-)
Later,
David S. Miller
davem@caip.rutgers.edu
^ permalink raw reply [relevance 1%]
* Re: MIPS port kickoff meeting
1996-04-24 2:05 1% ` David S. Miller
@ 1996-04-24 4:31 1% ` Greg Chesson
0 siblings, 0 replies; 200+ results
From: Greg Chesson @ 1996-04-24 4:31 UTC (permalink / raw)
To: David S. Miller; +Cc: alambie, linux
agreed.
we should begin with the version of Linux that is the most natural
port for you. The other versions can come later. Note however that
Lego may prefer a 64-bit kernel.
g
^ permalink raw reply [relevance 1%]
* Reminder: meeting in 2 hours
@ 1996-04-24 21:05 1% Ariel Faigon
0 siblings, 0 replies; 200+ results
From: Ariel Faigon @ 1996-04-24 21:05 UTC (permalink / raw)
To: linux
Just a reminder:
MIPS-Linux kickoff Meeting today at 16:00
Jamaica conf. room
Buliding 10 Upper
See you there.
--
Peace, Ariel
^ permalink raw reply [relevance 1%]
* Linux allocated machines
@ 1996-04-25 1:17 1% Ariel Faigon
0 siblings, 0 replies; 200+ results
From: Ariel Faigon @ 1996-04-25 1:17 UTC (permalink / raw)
To: linux
Some announcements:
1) The two Indy's allocated for David are in Jeff Thomas old
office in Building 9 Upper, across from the Matisse conf room.
One is 6.2 MR and one 5.3 and they're both on the network.
They both have empty root passwords in order to help you be
as productive as possible.
(info) 522 ~> rlogin root@co-op-test.engr
IRIX Release 5.3 IP22 co-op
Copyright 1987-1994 Silicon Graphics, Inc. All Rights Reserved.
Last login: Wed Apr 24 17:50:23 PDT 1996 by UNKNOWN@unhinged.engr.sgi.com
co-op 1#
(info) 523 ~> rlogin root@divot.engr
IRIX Release 6.2 IP22 divot
Copyright 1987-1996 Silicon Graphics, Inc. All Rights Reserved.
Last login: Wed Apr 24 17:45:36 PDT 1996 by ariel@co-op.engr.sgi.com
divot 1#
We plan to upgrade both to 200MHz CPUs so they won't slow us down
(Thanks Bill).
The names are historic. We are waiting for David to come up with
the names he likes best (or whatever you vote for from his list)
2) I marked the room and the machines with big signs so no one
comes to take these apart. I mailed 'sa@engr' regarding these
being on a loan from John Loveall to Greg Chesson.
3) I'll be flying to Israel tomorrow, but I'l try to stay in touch
via email, I'll be back on May 10th. Please do lots of good things
while I'm gone.
A summary of today's meeting will follow.
--
Peace, Ariel
^ permalink raw reply [relevance 1%]
* Kickoff meeting minutes
@ 1996-04-25 1:35 1% Ariel Faigon
0 siblings, 0 replies; 200+ results
From: Ariel Faigon @ 1996-04-25 1:35 UTC (permalink / raw)
To: linux
To make a long story short.
Here are our Action Items + volunteers:
Skeletal Kernel / sash boot:
Jim Barton, Simon Cooper, Bob Mende
Sandeep Cariapa expressed his wish to learn and help here.
Drivers, VM questions, low-level focal point:
Bill Earl
200MHz CPU upgrades
Bill Earl
Graphics drivers, MIT-stuff->Newport, check other options
Jim, Simon
Setup, serial cable, add disk space
Larry
gcc, binutils, gdb
Ariel
Office coordination
Greg <-> John Loveall
Simon is going back to England for a while, but he'll be with us
virtually.
Some interesting developments: Alan Cox, Linus (Oops...can we really
talk about this?)
Request: please keep this low key. Don't talk too much with your friends
about all this at this point.
Boy, are we excited yet :-)
--
Peace, Ariel
^ permalink raw reply [relevance 1%]
* Linux/MIPS status on non-SGI boxes
@ 1996-04-26 21:59 1% Larry McVoy
0 siblings, 0 replies; 200+ results
From: Larry McVoy @ 1996-04-26 21:59 UTC (permalink / raw)
To: linux
Looks like we may have help...
------- Forwarded Message
Date: Fri, 26 Apr 1996 20:14:24 +0200
From: Ralf Baechle <ralf@Julia.DE>
To: lm, davem@caip.rutgers.edu, linux-mips@fnet.fr
Subject: Re: Linux/SGI coming
Hi all,
> So, can someone provide a quick summary of the current status? All the
> usual stuff, like what compilers are used, what linker, what are you
> doing for userland, etc.
OK. There is a bootloader available for ARC conformant systems. This
implies little endian byte order. Some time ago we redesigned the interface
to pass bootinformation to the kernel. The new interface uses a tagged list
and can also be used to pass big information like ramdisks or fonts from the
bootloader to the kernel. Due to the byteorder Milo isn't really of interest.
Furthermore the Milo distribution is crippled due to (C) problems. Since
you, Larry, probably have signed an NDA with SGI ;-) you can however get the
complete sources, it you wish. Otherwise the crippled distribution is
available via ftp.fnet.fr. What is missing are the lowlevel interfaces
between the pseudo libc implementation that Milo uses and the ARC BIOS.
This was required due to M$ holding the (C) for the information Milo is based
on.
The crosscompiler environment is based on GCC 2.7.2 and Binutils 2.6. The
required patches that fix lots of bugs and add Linux/MIPS support for
a.out, ELF little/big endian byte order are available on ftp.fnet.fr.
Their installation isn't easy but Dave shouldn't have to much trouble
with this.
There are some binary packages on ftp.fnet.fr for Linux/i386 host. I'd like
to have packages for more hosts, so if someone sends me binaries we'll put
the online. (I could create packages for Stun's OSes if someone wants them)
The libc implementation is based on the GNU libc which is available only
as ELF. My home sources are based on snapshot 960210; upgrading to the
newest libc will be the next thing for me to do when I sent my kernel
patches to Linus. There is an older Linux libc port available - don't
use it! I changed the low level kernel interfaces for 1.3 so that they
should now look much more like IRIX 5.3 / RISC/os 5.01 which breaks this
old (a.out ...) port completly. The distribution is still available via
ftp to help building the a.out crosscompiler.
The quality of the libc port to Linux is good enough to build most user stuff.
GNU libc is however very aggresive to bad code; quite some packages need
to be patched to compile. I'll put patches online as soon as I can.
Most of the userland stuff available via ftp is based on the GNU or Debian
source distributions.
The kernel itself runs pretty solid for me. It currently supports the PC
versions of R4000 and R4400 CPUs but probably doesn't work for SC and MC
versions. I tried to support R2000/R3000/R6000/R8000/R10000 as good as
possible without having hardware, so a port shouldn't be too hard. For
R4000 and better many of the lowlevel functions have been written to be
SMP proof but again without SMP hardware and at this point of the project
SMP is nothing really invest my time in.
One of the kernel features that are still missing is the special kernel
code to handle denormalized numbers - not of interest for you -
FPU emulation, branch delay emulation. Also there is no support for
ptrace(2), therefore no debugger.
The supported machines are the Mips Magnum 4000, Olivetti M700-10 (a OEM
Magnum version) and Acer Pica 61, which is a kind of a successor type for
the Magnum built by Acer. All these machines have a similar DMA engine,
Floppy, NCR53C94 SCSI and Sonic Ethernet onboard. This SCSI/Ethernet
hardware is currently not supported. I thought it would be better to
use (E)ISA hardware where drivers are very easy to port and to put my
time on the other parts of the system.
Paul Antoine is working on DECstation/R3000 support.
> Also, the handhold on information has loosened quite a bit. If there is
> specific information you are looking for, let me know. In particular,
> I have access to all the chip errata, something that our internal people
> use a lot.
I think it would be great to have all this stuff on our ftp server as it
could especially help peoples with ancient CPUs. Andy's R4000 2.2 was
driving me crazy ...
This should answer many of your questions but probably not all, so feel
free to mail me.
Ralf
------- End of Forwarded Message
^ permalink raw reply [relevance 1%]
* machine resource?
@ 1996-04-26 22:24 1% Larry McVoy
0 siblings, 0 replies; 200+ results
From: Larry McVoy @ 1996-04-26 22:24 UTC (permalink / raw)
To: linux
Hi-
I've been talking to one of the Linux/MIPs guys in Europe and a
couple of things came up:
1. We should get a box up outside the firewall to act as a
source repository. We have space (a small amount) and a
drop in my lab here in B9.
2. This guy offered to get a cross development environment
set up if we gave him a login on a machine.
I'd like to kill two birds here and stick something like a challenge/s
or an indy or whatever the new R5000 is called out there.
Does anyone have access to some hardware that we could use for this?
If you come up with the hardware, I'll get it installed on the net
(linux.sgi.com?), and help maintain it.
Any ideas?
Thanks,
--lm
---
Larry McVoy lm@sgi.com http://reality.sgi.com/lm (415) 933-1804
Copyright 1996, all rights reserved. Microsoft Network is prohibited from
redistributing this work in any form, in whole or in part without license.
License to distribute this work is available to Microsoft at $500.
Transmission without permission constitutes an agreement to these terms.
^ permalink raw reply [relevance 1%]
* scope of this mailing list
@ 1996-04-29 23:27 1% Larry McVoy
1996-04-30 0:06 1% ` Erik Troan
0 siblings, 1 reply; 200+ results
From: Larry McVoy @ 1996-04-29 23:27 UTC (permalink / raw)
To: linux
Hi SGIers,
There are people from the outside that are interested in the
progress of the Linux/MIPs effort. So I'm adding them to the list if
they look like reasonable sorts. For example, a guy from Red Hat, the
company that produces a distribution for DEC Alphas and for Intel,
is now on the list. I suspect that we might be able to work with them
to get a Linux/MIPs distribution. Furthermore, givem that Linux/MIPs
will run IRIX elf binaries, we might be able to merge the Freeware and
Linux/MIPs efforts - they have a lot of overlap. Something to think
about.
--lm
---
Larry McVoy lm@sgi.com http://reality.sgi.com/lm (415) 933-1804
Copyright 1996, all rights reserved. Microsoft Network is prohibited from
redistributing this work in any form, in whole or in part without license.
License to distribute this work is available to Microsoft at $500.
Transmission without permission constitutes an agreement to these terms.
^ permalink raw reply [relevance 1%]
* Re: scope of this mailing list
1996-04-29 23:27 1% scope of this mailing list Larry McVoy
@ 1996-04-30 0:06 1% ` Erik Troan
1996-05-01 2:30 1% ` Ralf Baechle
0 siblings, 1 reply; 200+ results
From: Erik Troan @ 1996-04-30 0:06 UTC (permalink / raw)
To: Larry McVoy; +Cc: linux
On Mon, 29 Apr 1996, Larry McVoy wrote:
> to get a Linux/MIPs distribution. Furthermore, givem that Linux/MIPs
> will run IRIX elf binaries, we might be able to merge the Freeware and
> Linux/MIPs efforts - they have a lot of overlap. Something to think
> about.
This raises a good question - what is the relationship between the SGI port,
a port to Digital MIPS/TurboChannel machines, and the MIPS/PC port (that
works on MIPS machines with PCI/EISA buses)? Will they all be the same
endian? Should binarises be comaptible? What about sources such as libc
and the kernel syscall interface?
Erik
-------------------------------------------------------------------------------
Always hoped that I'd be an apostle. Knew that I would make it if I tried.
Then when we retire we can write the gospels so they'll all talk about
us when we die. - "The Last Supper" from Jesus Christ Superstar
| Erik Troan = http://sunsite.unc.edu/ewt/ = ewt@sunsite.unc.edu |
^ permalink raw reply [relevance 1%]
* Let's talk platforms...
@ 1996-04-30 23:08 1% Mike Shaver
1996-04-30 23:11 1% ` William J. Earl
0 siblings, 1 reply; 200+ results
From: Mike Shaver @ 1996-04-30 23:08 UTC (permalink / raw)
To: linux
We're getting a whole pile of SGI hardware in to `kick the tires' over
the next 6 months, and I'm wondering which of them I should claim as
my test box.
I can likely choose an Indy, an Indigo, possibly one of the Webforce
boxes (I assume it's similar hardware to the Indigo) and, if I beg and
plead and offer beer, a Challenge-S.
Has an initial port target been designated?
Mike
(having trouble changing the address subscribed to the list, sice
majordomo@cthulhu.engr doesn't seem to want to talk to me...)
--
#> Mike Shaver (shaver@ingenia.com) <#
#> Technical specialist, pedant, packetsmith <#
#> Ingenia Communications Corporations <#
#> Research, Development, Support and Sleep Deprivation <#
#> Packets crafted, bugs found, rebellions quelled <#
^ permalink raw reply [relevance 1%]
* Re: Let's talk platforms...
1996-04-30 23:08 1% Let's talk platforms Mike Shaver
@ 1996-04-30 23:11 1% ` William J. Earl
1996-05-01 13:56 1% ` Mike Shaver
0 siblings, 1 reply; 200+ results
From: William J. Earl @ 1996-04-30 23:11 UTC (permalink / raw)
To: Mike Shaver; +Cc: linux
Mike Shaver writes:
> We're getting a whole pile of SGI hardware in to `kick the tires' over
> the next 6 months, and I'm wondering which of them I should claim as
> my test box.
>
> I can likely choose an Indy, an Indigo, possibly one of the Webforce
> boxes (I assume it's similar hardware to the Indigo) and, if I beg and
> plead and offer beer, a Challenge-S.
>
> Has an initial port target been designated?
...
We expect to do the initial port to an Indy with an R4600 or R5000 processor,
following up with other processors and platforms. A Challenge S is essentially
the same as an Indy without a graphics board.
^ permalink raw reply [relevance 1%]
* whee
@ 1996-05-01 1:31 1% David S. Miller
0 siblings, 0 replies; 200+ results
From: David S. Miller @ 1996-05-01 1:31 UTC (permalink / raw)
To: lmlinux
Syscalls are a bit faster, just started optimizing again
L M B E N C H 1 . 0 S U M M A R Y
------------------------------------
Processor, Processes - times in microseconds
--------------------------------------------
Host OS Mhz Null Null Simple /bin/sh Mmap 2-proc 8-proc
Syscall Process Process Process lat ctxsw ctxsw
--------- ------------- ---- ------- ------- ------- ------- ---- ------ ------
trombetas Linux 1.3.90 50 17 9.3K 38.6K 58K 370 88 109
trombetas Linux 1.3.97 50 14 8.9K 38.3K 56K 354 86 101
negro.rut SunOS 4.1.3_U 49 124 18.3K 63.9K 110K 470 152 262
geneva.ru SunOS 5.5 50 31 33.7K 148.2K 274K 596 174 205
*Local* Communication latencies in microseconds
-----------------------------------------------
Host OS Pipe UDP RPC/ TCP RPC/
UDP TCP
--------- ------------- ------- ------- ------- ------- -------
trombetas Linux 1.3.90 285 1028 1754 1368 2610
trombetas Linux 1.3.97 300 1016 1752 1376 2598
negro.rut SunOS 4.1.3_U 890 1375 2287 1573 2804
geneva.ru SunOS 5.5 530 1563 2080 1354 2398
*Local* Communication bandwidths in megabytes/second
----------------------------------------------------
Host OS Pipe TCP File Mmap Bcopy Bcopy Mem Mem
reread reread (libc) (hand) read write
--------- ------------- ---- ---- ------ ------ ------ ------ ---- -----
trombetas Linux 1.3.90 8 4.0 23.5 17.4 18 25 42 37
trombetas Linux 1.3.97 8 4.0 23.5 17.4 18 25 41 37
negro.rut SunOS 4.1.3_U 4 2.0 19.5 8.2 18 24 41 36
geneva.ru SunOS 5.5 8 7.0 12.6 19.5 18 18 40 36
Memory latencies in nanoseconds
(WARNING - may not be correct, check graphs)
--------------------------------------------
Host OS Mhz L1 $ L2 $ Main mem TLB Guesses
--------- ------------- --- ---- ---- -------- --- -------
trombetas Linux 1.3.90 50 20 170 180 -1 No L2 cache?
trombetas Linux 1.3.97 50 20 170 180 659 No L2 cache?
negro.rut SunOS 4.1.3_U 49 20 175 183 -1 No L2 cache?
geneva.ru SunOS 5.5 49 - - - - Bad mhz?
^ permalink raw reply [relevance 1%]
* Re: scope of this mailing list
1996-04-30 0:06 1% ` Erik Troan
@ 1996-05-01 2:30 1% ` Ralf Baechle
0 siblings, 0 replies; 200+ results
From: Ralf Baechle @ 1996-05-01 2:30 UTC (permalink / raw)
To: Erik Troan; +Cc: linux
Hi,
> > to get a Linux/MIPs distribution. Furthermore, givem that Linux/MIPs
> > will run IRIX elf binaries, we might be able to merge the Freeware and
> > Linux/MIPs efforts - they have a lot of overlap. Something to think
> > about.
>
> This raises a good question - what is the relationship between the SGI port,
> a port to Digital MIPS/TurboChannel machines, and the MIPS/PC port (that
> works on MIPS machines with PCI/EISA buses)? Will they all be the same
> endian? Should binarises be comaptible? What about sources such as libc
> and the kernel syscall interface?
The main issue in achieving binary compatibility accross all Linux/MIPS
targets is the byte order. For some machines (Mips Magnum 4000, Olivetti
M700-10, SNI RM series and others more) the byte order for the kernel is
configurable. For other it is fixed. This is often the case for machines
that were built with NT in mind.
The MIPS architecture offers us the nice feature of switchable byteorder
for usermode. Thus we have a way to run software from other systems with
differing native byte order. In other words: it's technological possible
but it's not implemented yet.
The MIPS ABI which to support is one design goal for Linux/MIPS supports
only big endian systems while current Linux/MIPS implementations are all
little endian. This single fact shows Linux/MIPS doesn't currently
conform to the ABI but it will be relativly easy to do so in the future.
The ABI explicitly forbids direct syscalls from the usercode into the
kernel. Instead every program is supposed to be linked with the shared
library libc.so.1 which contains the actual interface to the kernel.
Linux/MIPS currently uses the GNU libc which is far being compliant
to the ABI.
Nevertheless Linux/MIPS contains an (currently on partial implemented)
syscall interface that provides not only the syscalls known from the
Linux/i386 implementation - it also features the same syscall conventions,
numbers and more as implemented in IRIX and other MIPS UNIX systems.
Call it a kludge but it can make things easier.
Ralf
^ permalink raw reply [relevance 1%]
* Re: scope of this mailing list
@ 1996-05-01 2:30 1% ` Ralf Baechle
0 siblings, 0 replies; 200+ results
From: Ralf Baechle @ 1996-05-01 2:30 UTC (permalink / raw)
To: Erik Troan; +Cc: linux
Hi,
> > to get a Linux/MIPs distribution. Furthermore, givem that Linux/MIPs
> > will run IRIX elf binaries, we might be able to merge the Freeware and
> > Linux/MIPs efforts - they have a lot of overlap. Something to think
> > about.
>
> This raises a good question - what is the relationship between the SGI port,
> a port to Digital MIPS/TurboChannel machines, and the MIPS/PC port (that
> works on MIPS machines with PCI/EISA buses)? Will they all be the same
> endian? Should binarises be comaptible? What about sources such as libc
> and the kernel syscall interface?
The main issue in achieving binary compatibility accross all Linux/MIPS
targets is the byte order. For some machines (Mips Magnum 4000, Olivetti
M700-10, SNI RM series and others more) the byte order for the kernel is
configurable. For other it is fixed. This is often the case for machines
that were built with NT in mind.
The MIPS architecture offers us the nice feature of switchable byteorder
for usermode. Thus we have a way to run software from other systems with
differing native byte order. In other words: it's technological possible
but it's not implemented yet.
The MIPS ABI which to support is one design goal for Linux/MIPS supports
only big endian systems while current Linux/MIPS implementations are all
little endian. This single fact shows Linux/MIPS doesn't currently
conform to the ABI but it will be relativly easy to do so in the future.
The ABI explicitly forbids direct syscalls from the usercode into the
kernel. Instead every program is supposed to be linked with the shared
library libc.so.1 which contains the actual interface to the kernel.
Linux/MIPS currently uses the GNU libc which is far being compliant
to the ABI.
Nevertheless Linux/MIPS contains an (currently on partial implemented)
syscall interface that provides not only the syscalls known from the
Linux/i386 implementation - it also features the same syscall conventions,
numbers and more as implemented in IRIX and other MIPS UNIX systems.
Call it a kludge but it can make things easier.
Ralf
^ permalink raw reply [relevance 1%]
* Re: Let's talk platforms...
@ 1996-05-01 13:56 1% ` Mike Shaver
0 siblings, 0 replies; 200+ results
From: Mike Shaver @ 1996-05-01 13:56 UTC (permalink / raw)
To: William J. Earl; +Cc: linux
William J. Earl wrote:
> We expect to do the initial port to an Indy with an R4600 or
> R5000 processor, following up with other processors and platforms.
> A Challenge S is essentially the same as an Indy without a graphics
> board.
Cool.
That's been passed on to the salescritter as a desirable item, because
of the Linux project.
We'll see how it goes.
Mike
--
#> Mike Shaver (shaver@ingenia.com) <#
#> Technical specialist, pedant, packetsmith <#
#> Ingenia Communications Corporations <#
#> Research, Development, Support and Sleep Deprivation <#
#> Packets crafted, bugs found, rebellions quelled <#
^ permalink raw reply [relevance 1%]
* Re: Let's talk platforms...
@ 1996-05-01 13:56 1% ` Mike Shaver
0 siblings, 0 replies; 200+ results
From: Mike Shaver @ 1996-05-01 13:56 UTC (permalink / raw)
To: William J. Earl; +Cc: linux
William J. Earl wrote:
> We expect to do the initial port to an Indy with an R4600 or
> R5000 processor, following up with other processors and platforms.
> A Challenge S is essentially the same as an Indy without a graphics
> board.
Cool.
That's been passed on to the salescritter as a desirable item, because
of the Linux project.
We'll see how it goes.
Mike
--
#> Mike Shaver (shaver@ingenia.com) <#
#> Technical specialist, pedant, packetsmith <#
#> Ingenia Communications Corporations <#
#> Research, Development, Support and Sleep Deprivation <#
#> Packets crafted, bugs found, rebellions quelled <#
^ permalink raw reply [relevance 1%]
* Re: scope of this mailing list
1996-05-01 2:30 1% ` Ralf Baechle
@ 1996-05-01 15:44 1% ` William J. Earl
-1 siblings, 0 replies; 200+ results
From: William J. Earl @ 1996-05-01 15:44 UTC (permalink / raw)
To: Ralf Baechle; +Cc: Erik Troan, linux
Ralf Baechle writes:
...
> The main issue in achieving binary compatibility accross all Linux/MIPS
> targets is the byte order. For some machines (Mips Magnum 4000, Olivetti
> M700-10, SNI RM series and others more) the byte order for the kernel is
> configurable. For other it is fixed. This is often the case for machines
> that were built with NT in mind.
>
> The MIPS architecture offers us the nice feature of switchable byteorder
> for usermode. Thus we have a way to run software from other systems with
> differing native byte order. In other words: it's technological possible
> but it's not implemented yet.
...
I once worked on this problem on another OS base. The basic system
calls are easy. ioctls, especially for streams, were much harder. Within
the limits of the published ABI, as opposed to the universe of working programs,
the task is not too difficult.
^ permalink raw reply [relevance 1%]
* Re: scope of this mailing list
@ 1996-05-01 15:44 1% ` William J. Earl
0 siblings, 0 replies; 200+ results
From: William J. Earl @ 1996-05-01 15:44 UTC (permalink / raw)
To: Ralf Baechle; +Cc: Erik Troan, linux
Ralf Baechle writes:
...
> The main issue in achieving binary compatibility accross all Linux/MIPS
> targets is the byte order. For some machines (Mips Magnum 4000, Olivetti
> M700-10, SNI RM series and others more) the byte order for the kernel is
> configurable. For other it is fixed. This is often the case for machines
> that were built with NT in mind.
>
> The MIPS architecture offers us the nice feature of switchable byteorder
> for usermode. Thus we have a way to run software from other systems with
> differing native byte order. In other words: it's technological possible
> but it's not implemented yet.
...
I once worked on this problem on another OS base. The basic system
calls are easy. ioctls, especially for streams, were much harder. Within
the limits of the published ABI, as opposed to the universe of working programs,
the task is not too difficult.
^ permalink raw reply [relevance 1%]
* add a 'make -j vmlinux' for flavor...
@ 1996-05-03 3:29 2% David S. Miller
0 siblings, 0 replies; 200+ results
From: David S. Miller @ 1996-05-03 3:29 UTC (permalink / raw)
To: lmlinux
SparcClassic, 24mb of ram, swapping ferociously...
Can anyone say "quality assurance"?
USER PID %CPU %MEM SIZE RSS TTY STAT START TIME COMMAND
davem 202 0.0 0.2 148 64 ? S 02:45 0:00 ./crashme +2000 666 100 1:10:30 2
davem 203 0.0 0.2 148 64 ? S 02:45 0:00 ./crashme +2000 666 100 1:10:30 2
davem 206 0.0 0.2 148 64 ? S 02:45 0:00 ./crashme +2000 666 100 1:10:30 2
davem 210 0.0 0.2 148 64 ? S 02:45 0:00 ./crashme +2000 666 100 1:10:30 2
davem 279 3.0 0.2 344 56 ? R 02:46 1:09 ./crashme +2000 686 100 21 2 subprocess
davem 281 3.0 0.2 344 56 ? R 02:46 1:09 ./crashme +2000 686 100 21 2 subprocess
davem 288 3.0 0.2 344 52 ? R 02:46 1:08 ./crashme +2000 686 100 21 2 subprocess
davem 291 3.0 0.2 344 52 ? R 02:46 1:08 ./crashme +2000 686 100 21 2 subprocess
davem 428 1.9 0.2 232 56 ? R 02:49 0:40 ./crashme +2000 721 100 56 2 subprocess
davem 429 1.9 0.2 228 56 ? R 02:49 0:40 ./crashme +2000 721 100 56 2 subprocess
davem 430 1.9 0.2 232 56 ? R 02:49 0:40 ./crashme +2000 721 100 56 2 subprocess
davem 431 1.9 0.2 232 56 ? R 02:49 0:40 ./crashme +2000 721 100 56 2 subprocess
davem 508 1.6 0.2 256 52 ? R 02:50 0:32 ./crashme +2000 741 100 76 2 subprocess
davem 509 1.6 0.2 252 52 ? R 02:50 0:32 ./crashme +2000 741 100 76 2 subprocess
davem 510 1.6 0.2 252 52 ? R 02:50 0:32 ./crashme +2000 741 100 76 2 subprocess
davem 511 1.6 0.2 256 52 ? R 02:50 0:32 ./crashme +2000 741 100 76 2 subprocess
davem 544 1.5 0.2 348 52 ? R 02:51 0:30 ./crashme +2000 750 100 85 2 subprocess
davem 545 1.5 0.2 348 52 ? R 02:51 0:30 ./crashme +2000 750 100 85 2 subprocess
davem 546 1.5 0.2 348 52 ? R 02:51 0:30 ./crashme +2000 750 100 85 2 subprocess
davem 547 1.5 0.2 344 52 ? R 02:51 0:30 ./crashme +2000 750 100 85 2 subprocess
davem 580 1.4 0.2 172 52 ? R 02:52 0:28 ./crashme +2000 759 100 94 2 subprocess
davem 581 1.4 0.2 176 52 ? R 02:52 0:28 ./crashme +2000 759 100 94 2 subprocess
davem 582 1.4 0.2 176 52 ? R 02:52 0:28 ./crashme +2000 759 100 94 2 subprocess
davem 583 1.4 0.2 172 52 ? R 02:52 0:28 ./crashme +2000 759 100 94 2 subprocess
davem 644 1.3 0.2 256 52 ? R 02:53 0:24 ./crashme +2000 775 100 110 2 subprocess
davem 645 1.3 0.2 256 52 ? R 02:53 0:24 ./crashme +2000 775 100 110 2 subprocess
davem 646 1.3 0.2 256 52 ? R 02:53 0:24 ./crashme +2000 775 100 110 2 subprocess
davem 647 1.3 0.2 256 52 ? R 02:53 0:24 ./crashme +2000 775 100 110 2 subprocess
davem 680 1.3 0.2 252 52 ? R 02:54 0:23 ./crashme +2000 784 100 119 2 subprocess
davem 681 1.3 0.2 252 52 ? R 02:54 0:23 ./crashme +2000 784 100 119 2 subprocess
davem 682 1.3 0.2 252 52 ? R 02:54 0:23 ./crashme +2000 784 100 119 2 subprocess
davem 683 1.3 0.2 252 52 ? R 02:54 0:23 ./crashme +2000 784 100 119 2 subprocess
davem 684 1.3 0.2 284 52 ? R 02:54 0:23 ./crashme +2000 785 100 120 2 subprocess
davem 685 1.3 0.2 284 52 ? R 02:54 0:23 ./crashme +2000 785 100 120 2 subprocess
davem 686 1.3 0.2 284 52 ? R 02:54 0:23 ./crashme +2000 785 100 120 2 subprocess
davem 687 1.3 0.2 284 52 ? R 02:54 0:23 ./crashme +2000 785 100 120 2 subprocess
davem 712 1.3 0.2 192 52 ? R 02:55 0:22 ./crashme +2000 792 100 127 2 subprocess
davem 713 1.3 0.2 196 52 ? R 02:55 0:22 ./crashme +2000 792 100 127 2 subprocess
davem 714 1.3 0.2 192 52 ? R 02:55 0:22 ./crashme +2000 792 100 127 2 subprocess
davem 716 1.3 0.2 192 52 ? R 02:55 0:22 ./crashme +2000 792 100 127 2 subprocess
davem 821 1.2 0.2 348 52 ? R 02:57 0:19 ./crashme +2000 819 100 154 2 subprocess
davem 822 1.2 0.2 348 52 ? R 02:57 0:19 ./crashme +2000 819 100 154 2 subprocess
davem 876 1.2 0.2 220 56 ? R 02:59 0:18 ./crashme +2000 833 100 168 2 subprocess
davem 877 1.2 0.2 220 56 ? R 02:59 0:18 ./crashme +2000 833 100 168 2 subprocess
davem 878 1.2 0.2 220 56 ? R 02:59 0:18 ./crashme +2000 833 100 168 2 subprocess
davem 880 1.2 0.2 216 56 ? R 02:59 0:18 ./crashme +2000 833 100 168 2 subprocess
davem 1029 1.1 0.2 308 52 ? R 03:02 0:15 ./crashme +2000 871 100 206 2 subprocess
davem 1030 1.1 0.2 316 52 ? R 03:02 0:15 ./crashme +2000 871 100 206 2 subprocess
davem 1092 1.1 0.2 256 52 ? R 03:03 0:13 ./crashme +2000 887 100 222 2 subprocess
davem 1094 1.1 0.2 256 52 ? R 03:03 0:13 ./crashme +2000 887 100 222 2 subprocess
davem 1095 1.1 0.2 256 52 ? R 03:03 0:13 ./crashme +2000 887 100 222 2 subprocess
davem 1096 1.1 0.2 256 52 ? R 03:03 0:13 ./crashme +2000 887 100 222 2 subprocess
davem 1104 1.1 0.2 348 52 ? R 03:04 0:13 ./crashme +2000 889 100 224 2 subprocess
davem 1131 1.1 0.1 344 36 ? R 03:04 0:13 ./crashme +2000 896 100 231 2 subprocess
davem 1239 1.1 0.1 228 40 ? R 03:07 0:11 ./crashme +2000 923 100 258 2 subprocess
davem 1240 1.1 0.2 224 52 ? R 03:07 0:11 ./crashme +2000 923 100 258 2 subprocess
davem 1300 1.1 0.1 208 36 ? R 03:09 0:10 ./crashme +2000 939 100 274 2 subprocess
davem 1302 1.1 0.1 204 36 ? R 03:09 0:10 ./crashme +2000 939 100 274 2 subprocess
davem 1303 1.1 0.2 208 52 ? R 03:09 0:10 ./crashme +2000 939 100 274 2 subprocess
davem 1306 1.1 0.2 204 52 ? R 03:09 0:10 ./crashme +2000 939 100 274 2 subprocess
davem 1312 1.1 0.1 348 44 ? R 03:09 0:10 ./crashme +2000 942 100 277 2 subprocess
davem 1316 1.1 0.2 348 52 ? R 03:09 0:10 ./crashme +2000 942 100 277 2 subprocess
davem 1406 1.1 0.2 240 52 ? R 03:11 0:08 ./crashme +2000 965 100 300 2 subprocess
davem 1450 1.1 0.1 344 40 ? R 03:12 0:07 ./crashme +2000 975 100 310 2 subprocess
davem 1487 1.1 0.1 348 40 ? R 03:13 0:07 ./crashme +2000 985 100 320 2 subprocess
davem 1513 1.1 0.1 228 40 ? R 03:13 0:06 ./crashme +2000 992 100 327 2 subprocess
davem 1514 1.1 0.1 232 40 ? R 03:13 0:06 ./crashme +2000 992 100 327 2 subprocess
davem 1568 1.1 0.2 348 52 ? R 03:15 0:06 ./crashme +2000 1006 100 341 2 subprocess
davem 1571 1.1 0.2 348 52 ? R 03:15 0:06 ./crashme +2000 1006 100 341 2 subprocess
davem 1597 1.1 0.2 328 52 ? R 03:15 0:05 ./crashme +2000 1012 100 347 2 subprocess
davem 1608 1.1 0.2 332 52 ? R 03:15 0:05 ./crashme +2000 1015 100 350 2 subprocess
davem 1649 1.0 0.2 3960 52 ? R 03:16 0:04 ./crashme +2000 1026 100 361 2 subprocess
davem 1683 1.1 0.2 204 56 ? R 03:17 0:04 ./crashme +2000 1035 100 370 2 subprocess
davem 1685 1.2 0.2 200 52 ? R 03:17 0:04 ./crashme +2000 1035 100 370 2 subprocess
davem 1687 1.1 0.2 200 52 ? R 03:17 0:04 ./crashme +2000 1035 100 370 2 subprocess
davem 1690 1.1 0.2 204 64 ? R 03:17 0:04 ./crashme +2000 1035 100 370 2 subprocess
davem 1816 0.2 1.5 584 344 p0 S 03:20 0:00 -bash
davem 1834 1.2 0.1 192 44 ? R 03:20 0:02 ./crashme +2000 1072 100 407 2 subprocess
davem 1835 1.1 0.2 192 52 ? R 03:20 0:02 ./crashme +2000 1072 100 407 2 subprocess
davem 1838 1.3 0.2 192 52 ? R 03:20 0:02 ./crashme +2000 1072 100 407 2 subprocess
davem 1840 1.1 0.3 192 68 ? R 03:20 0:02 ./crashme +2000 1072 100 407 2 subprocess
davem 1844 1.3 0.3 344 72 ? R 03:20 0:02 ./crashme +2000 1073 100 408 2 subprocess
davem 1858 1.2 0.2 256 60 ? R 03:21 0:02 ./crashme +2000 1077 100 412 2 subprocess
davem 1917 1.7 0.7 348 176 ? R 03:22 0:01 ./crashme +2000 1089 100 424 2 subprocess
davem 1958 1.9 1.0 312 240 p0 R 03:22 0:01 ps -auxwww
davem 1977 24.1 1.0 344 240 ? R 03:23 0:01 ./crashme +2000 1103 100 438 2 subprocess
davem 2023 99.9 1.0 312 228 ? R 03:24 0:00 ./crashme +2000 1115 100 450 2 subprocess
davem 2028 99.9 1.0 2248 224 ? R 03:24 0:00 ./crashme +2000 1117 100 452 2 subprocess
davem 2039 99.9 0.6 220 140 ? R 03:25 0:00 ./crashme +2000 1119 100 454 2 subprocess
davem 2040 99.9 1.0 308 228 ? R 03:25 0:00 ./crashme +2000 1120 100 455 2 subprocess
davem 2041 99.9 1.0 320 240 ? R 03:25 0:00 ./crashme +2000 1120 100 455 2 subprocess
davem 2042 99.9 1.1 332 248 ? R 03:25 0:00 ./crashme +2000 1119 100 454 2 subprocess
davem 2043 99.9 0.7 240 156 ? R 03:25 0:00 ./crashme +2000 1120 100 455 2 subprocess
davem 2046 99.9 0.9 296 216 ? R 03:25 0:00 ./crashme +2000 1120 100 455 2 subprocess
davem 2049 99.9 1.0 308 224 ? R 03:25 0:00 ./crashme +2000 1122 100 457 2 subprocess
davem 2051 99.9 0.9 300 220 ? R 03:25 0:00 ./crashme +2000 1122 100 457 2 subprocess
davem 2053 99.9 1.0 308 224 ? R 03:25 0:00 ./crashme +2000 1123 100 458 2 subprocess
davem 2055 99.9 1.0 308 232 ? R 03:25 0:00 ./crashme +2000 1123 100 458 2 subprocess
davem 2058 99.9 0.9 304 220 ? R 03:25 0:00 ./crashme +2000 1123 100 458 2 subprocess
davem 2061 99.9 1.0 304 224 ? R 03:25 0:00 ./crashme +2000 1125 100 460 2 subprocess
davem 2063 0.0 0.2 148 60 ? R 03:25 0:00 ./crashme +2000 666 100 1:10:30 2
davem 2064 0.0 0.2 148 56 ? R 03:25 0:00 ./crashme +2000 666 100 1:10:30 2
davem 2065 0.0 0.2 148 56 ? R 03:25 0:00 ./crashme +2000 1125 100 460 2 subprocess
davem 2066 99.9 0.6 220 144 ? R 03:25 0:00 ./crashme +2000 1126 100 461 2 subprocess
davem 2067 99.9 0.6 224 144 ? R 03:25 0:00 ./crashme +2000 1126 100 461 2 subprocess
davem 2068 99.9 0.6 224 144 ? R 03:25 0:00 ./crashme +2000 1127 100 462 2 subprocess
davem 2069 99.9 0.6 224 144 ? R 03:25 0:00 ./crashme +2000 1127 100 462 2 subprocess
davem 2070 99.9 0.6 220 140 ? R 03:25 0:00 ./crashme +2000 1126 100 461 2 subprocess
davem 2071 99.9 0.6 220 144 ? R 03:25 0:00 ./crashme +2000 1127 100 462 2 subprocess
davem 2074 99.9 0.6 216 140 ? R 03:25 0:00 ./crashme +2000 1127 100 462 2 subprocess
davem 2086 0.0 0.2 148 64 ? R 03:26 0:00 ./crashme +2000 666 100 1:10:30 2
davem 2087 0.0 0.2 148 64 ? R 03:26 0:00 ./crashme +2000 666 100 1:10:30 2
davem 2088 0.0 0.2 148 64 ? R 03:26 0:00 ./crashme +2000 666 100 1:10:30 2
davem 2089 0.0 0.2 148 64 ? R 03:26 0:00 ./crashme +2000 666 100 1:10:30 2
davem 2090 0.0 0.2 148 64 ? R 03:26 0:00 ./crashme +2000 666 100 1:10:30 2
root 1 0.0 0.0 188 0 ? SW 02:43 0:00 (init)
root 2 0.0 0.0 0 0 ? SW 02:43 0:00 (kflushd)
root 3 0.0 0.0 0 0 ? SW< 02:43 0:01 (kswapd)
root 4 0.0 0.0 0 0 ? SW 02:43 0:00 (nfsiod)
root 5 0.0 0.0 0 0 ? SW 02:43 0:00 (nfsiod)
root 6 0.0 0.0 0 0 ? SW 02:43 0:00 (nfsiod)
root 7 0.0 0.0 0 0 ? SW 02:43 0:00 (nfsiod)
root 11 0.0 0.1 116 28 ? S 02:43 0:00 update (bdfluHOME=/
root 27 0.0 0.0 628 4 ? S 02:44 0:00 (inetd)
root 29 0.0 0.0 636 0 ? SW 02:44 0:00 (portmap)
root 32 0.0 0.3 272 72 ? S 02:44 0:00 /usr/sbin/syslogd
root 34 0.0 0.0 308 0 ? SW 02:44 0:00 (klogd)
root 47 0.0 0.0 152 0 1 SW 02:44 0:00 (getty)
root 48 0.0 0.0 152 0 2 SW 02:44 0:00 (getty)
root 49 0.0 0.0 152 0 3 SW 02:44 0:00 (getty)
root 50 0.0 0.0 152 0 4 SW 02:44 0:00 (getty)
root 51 0.0 0.0 152 0 5 SW 02:44 0:00 (getty)
root 52 0.0 0.0 152 0 6 SW 02:44 0:00 (getty)
root 84 0.0 0.0 540 0 ? SWN 02:44 0:00 (punish.sh)
root 99 0.0 0.0 892 0 ? SWN 02:44 0:01 (make)
root 105 0.0 0.0 660 0 ? SWN 02:44 0:00 (gcc)
root 107 0.0 0.0 552 0 ? SWN 02:44 0:00 (bash)
root 109 0.0 0.0 864 0 ? SWN 02:44 0:00 (make)
root 119 0.0 0.0 1416 0 ? SWN 02:44 0:01 (cpp)
root 120 0.0 2.8 2776 620 ? R N 02:44 0:01 /usr/local/gnu/lib/gcc-lib/sparc-sun-sunos4.1.4/2.6.3/cc1 -quiet -dumpbase main.c -O2 -Wall -Wstrict-prototypes -fomit-frame-pointer -fno-strength-reduce -o -
root 121 0.0 0.0 1128 0 ? SWN 02:44 0:00 (as)
root 124 0.0 0.0 952 0 ? SWN 02:44 0:01 (make)
root 137 0.0 0.0 660 0 ? SWN 02:44 0:00 (gcc)
root 138 0.0 0.0 660 0 ? SWN 02:44 0:00 (gcc)
root 139 0.0 0.0 660 0 ? SWN 02:44 0:00 (gcc)
root 140 0.0 0.0 1288 0 ? SWN 02:44 0:01 (cpp)
root 141 0.0 1.8 3088 408 ? R N 02:44 0:02 /usr/local/gnu/lib/gcc-lib/sparc-sun-sunos4.1.4/2.6.3/cc1 -quiet -dumpbase sched.c -O2 -Wall -Wstrict-prototypes -fomit-frame-pointer -fno-strength-reduce -fno-omit-frame-pointer -o -
root 142 0.0 0.0 1128 0 ? SWN 02:44 0:00 (as)
root 144 0.0 1.9 2612 440 ? R N 02:44 0:00 /usr/local/gnu/lib/gcc-lib/sparc-sun-sunos4.1.4/2.6.3/cc1 -quiet -dumpbase dma.c -O2 -Wall -Wstrict-prototypes -fomit-frame-pointer -fno-strength-reduce -o -
root 145 0.0 0.0 660 0 ? SWN 02:44 0:00 (gcc)
root 146 0.0 0.0 1128 0 ? SWN 02:44 0:00 (as)
root 147 0.0 0.0 660 0 ? SWN 02:44 0:00 (gcc)
root 149 0.0 0.0 1216 0 ? SWN 02:44 0:01 (cpp)
root 150 0.0 0.0 660 0 ? SWN 02:44 0:00 (gcc)
root 151 0.0 0.4 3188 92 ? R N 02:44 0:02 (cc1)
root 152 0.0 0.0 1128 0 ? SWN 02:44 0:00 (as)
root 153 0.0 0.0 1232 0 ? SWN 02:44 0:00 (cpp)
root 154 0.0 0.9 3216 208 ? R N 02:44 0:02 /usr/local/gnu/lib/gcc-lib/sparc-sun-sunos4.1.4/2.6.3/cc1 -quiet -dumpbase exec_domain.c -O2 -Wall -Wstrict-prototypes -fomit-frame-pointer -fno-strength-reduce -o -
root 155 0.0 0.0 1236 0 ? SWN 02:44 0:00 (cpp)
root 156 0.0 0.1 3212 40 ? R N 02:44 0:02 (cc1)
root 157 0.0 0.0 1128 0 ? SWN 02:44 0:00 (as)
root 158 0.0 0.0 660 0 ? SWN 02:44 0:00 (gcc)
root 159 0.0 0.0 1128 0 ? SWN 02:44 0:00 (as)
root 160 0.0 0.0 1144 0 ? SWN 02:44 0:00 (cpp)
root 161 0.0 0.0 660 0 ? SWN 02:44 0:00 (gcc)
root 162 0.1 0.4 3264 108 ? R N 02:44 0:02 (cc1)
root 163 0.0 0.0 1128 0 ? SWN 02:44 0:00 (as)
root 164 0.0 0.0 660 0 ? SWN 02:44 0:00 (gcc)
root 165 0.0 0.0 660 0 ? SWN 02:44 0:00 (gcc)
root 166 0.0 0.0 1420 0 ? SWN 02:44 0:01 (cpp)
root 167 0.0 3.6 3100 796 ? R N 02:44 0:01 /usr/local/gnu/lib/gcc-lib/sparc-sun-sunos4.1.4/2.6.3/cc1 -quiet -dumpbase sys.c -O2 -Wall -Wstrict-prototypes -fomit-frame-pointer -fno-strength-reduce -o -
root 168 0.0 0.0 1128 0 ? SWN 02:44 0:00 (as)
root 169 0.0 0.0 660 0 ? SWN 02:44 0:00 (gcc)
root 170 0.0 0.0 660 0 ? SWN 02:44 0:00 (gcc)
root 171 0.0 0.0 1368 0 ? SWN 02:44 0:01 (cpp)
root 172 0.0 0.4 3088 100 ? R N 02:44 0:01 (cc1)
root 173 0.0 0.0 1128 0 ? SWN 02:44 0:00 (as)
root 174 0.0 0.0 1260 0 ? SWN 02:44 0:00 (cpp)
root 175 0.0 0.0 1196 0 ? SWN 02:44 0:01 (cpp)
root 176 0.0 0.0 660 0 ? SWN 02:44 0:00 (gcc)
root 177 0.1 1.7 3260 396 ? R N 02:44 0:02 /usr/local/gnu/lib/gcc-lib/sparc-sun-sunos4.1.4/2.6.3/cc1 -quiet -dumpbase exit.c -O2 -Wall -Wstrict-prototypes -fomit-frame-pointer -fno-strength-reduce -o -
root 178 0.0 0.0 1128 0 ? SWN 02:44 0:00 (as)
root 179 0.0 0.0 1252 0 ? SWN 02:44 0:00 (cpp)
root 180 0.1 1.3 3264 292 ? R N 02:44 0:02 /usr/local/gnu/lib/gcc-lib/sparc-sun-sunos4.1.4/2.6.3/cc1 -quiet -dumpbase signal.c -O2 -Wall -Wstrict-prototypes -fomit-frame-pointer -fno-strength-reduce -o -
root 181 0.0 0.0 1128 0 ? SWN 02:44 0:00 (as)
root 182 0.1 0.7 3272 172 ? R N 02:44 0:02 (cc1)
root 183 0.0 0.0 1128 0 ? SWN 02:44 0:00 (as)
root 184 0.0 0.0 660 0 ? SWN 02:44 0:00 (gcc)
root 185 0.0 0.0 1236 0 ? SWN 02:44 0:01 (cpp)
root 186 0.0 0.8 3212 180 ? R N 02:44 0:02 /usr/local/gnu/lib/gcc-lib/sparc-sun-sunos4.1.4/2.6.3/cc1 -quiet -dumpbase info.c -O2 -Wall -Wstrict-prototypes -fomit-frame-pointer -fno-strength-reduce -o -
root 187 0.0 0.0 1128 0 ? SWN 02:44 0:00 (as)
root 188 0.0 0.0 660 0 ? SWN 02:44 0:00 (gcc)
root 189 0.0 0.0 1316 0 ? SWN 02:44 0:01 (cpp)
root 190 0.0 0.9 3144 204 ? R N 02:44 0:02 (cc1)
root 191 0.0 0.0 1128 0 ? SWN 02:44 0:00 (as)
root 192 0.0 0.0 660 0 ? SWN 02:44 0:00 (gcc)
root 193 0.0 0.0 1188 0 ? SWN 02:44 0:00 (cpp)
root 194 0.0 0.0 1104 0 ? SWN 02:44 0:00 (cpp)
root 195 0.0 3.7 3072 824 ? R N 02:44 0:01 /usr/local/gnu/lib/gcc-lib/sparc-sun-sunos4.1.4/2.6.3/cc1 -quiet -dumpbase resource.c -O2 -Wall -Wstrict-prototypes -fomit-frame-pointer -fno-strength-reduce -o -
root 196 0.0 0.0 1128 0 ? SWN 02:44 0:00 (as)
root 197 0.0 3.3 3104 740 ? R N 02:44 0:02 /usr/local/gnu/lib/gcc-lib/sparc-sun-sunos4.1.4/2.6.3/cc1 -quiet -dumpbase softirq.c -O2 -Wall -Wstrict-prototypes -fomit-frame-pointer -fno-strength-reduce -o -
root 198 0.0 0.0 1128 0 ? SWN 02:44 0:00 (as)
root 199 0.0 0.0 1356 0 ? SWN 02:44 0:01 (cpp)
root 200 0.0 2.5 2512 568 ? R N 02:44 0:00 /usr/local/gnu/lib/gcc-lib/sparc-sun-sunos4.1.4/2.6.3/cc1 -quiet -dumpbase sysctl.c -O2 -Wall -Wstrict-prototypes -fomit-frame-pointer -fno-strength-reduce -o -
root 201 0.0 0.0 1128 0 ? SWN 02:44 0:00 (as)
root 1811 0.1 1.0 668 236 ? S 03:20 0:00 /usr/etc/in.telnetd
^ permalink raw reply [relevance 2%]
* check this out...
@ 1996-05-10 11:19 1% David S. Miller
0 siblings, 0 replies; 200+ results
From: David S. Miller @ 1996-05-10 11:19 UTC (permalink / raw)
To: lnz; +Cc: sparclinux, lmlinux
(Leonard, I thought you'd get a kick out of this...)
I stress tested my new Sparc SCSI driver with the following bus
configuration:
ID 3: SCSI2 Seagate disk
ID 4: pre-CCS SCSI1 disk of unknown vendor type ;-)
ID 5: FAST SCSI2 Conner drive
I ran three instances of a program which just did random seeks
forever, one on each drive. (thank god for lmbench programs which have
dual role as stress/stability testers ;-)
I was getting bus lockups now and then, and happily my abort/reset
code completely recovered the bus back into a working state and things
proceeded. After about 30 minutes of analyzing state dumps from my
driver when this would happen I figure out what was going on. My
driver now fixes this problem and does not reset anymore no matter how
hard I smash all the drives on this chain.
Anyways, to get to the point, for your edification Leonard, here is
the comment above my fix for the problem. Enjoy ;-)
/* A fix for broken SCSI1 targets, when they disconnect
* they lock up the bus and confuse ESP. So disallow
* disconnects for SCSI1 targets for now until we
* find a better fix.
*
* Addendum: This is funny, I figured out what was going
* on. The blotzed SCSI1 target would disconnect,
* one of the other SCSI2 targets or both would be
* disconnected as well. The SCSI1 target would
* stay disconnected long enough that we start
* up a command on one of the SCSI2 targets. As
* the ESP is arbitrating for the bus the SCSI1
* target begins to arbitrate as well to reselect
* the ESP. The SCSI1 target refuses to drop it's
* ID bit on the data bus even though the ESP is
* at ID 7 and is the obvious winner for any
* arbitration. The ESP is a poor sport and refuses
* to lose arbitration, it will continue indefinately
* trying to arbitrate for the bus and can only be
* stopped via a chip reset or SCSI bus reset.
* Therefore _no_ disconnects for SCSI1 targets
* thank you very much. ;-)
*/
Later,
David S. Miller
davem@caip.rutgers.edu
^ permalink raw reply [relevance 1%]
* wicked checksum optimization...
@ 1996-05-13 4:05 1% David S. Miller
0 siblings, 0 replies; 200+ results
From: David S. Miller @ 1996-05-13 4:05 UTC (permalink / raw)
To: tridge; +Cc: lmlinux, torvalds
I think I figured out how to do it all "the right way(tm)"
The big problem is alignment, but %97 of the time the buffer is
aligned how we like. I've decided it is ok to take the hit of an
unaligned access trap for the %3 cases, but not that much of a hit.
The implementation looks like this:
All loads and stores in the ip checksum routines will look the same,
the only time we do stores is for the csum/copy routines. Anyways the
eight instruction codes recognized will be for:
ld [%o0 + offset], %o4
ld [%o0 + offset], %o5
lduh [%o0 + offset], %o4
lduh [%o0 + offset], %o5
st %o4, [%g3 + offset]
st %o5, [%g3 + offset]
sth %o4, [%g3 + offset]
sth %o5, [%g3 + offset]
The unaligned trap handler (before it even tries to save any state)
will look something like:
mna_trap:
andcc %l0, PSR_PS, %g0
be,a mna_fromuser
ld [%l1], %l5
sethi %hi(LOAD_O4), %l4
and %l5, %l4, %l6
cmp %l6, %l4
bne 1f
sethi %hi(LOAD_O5), %l4
mov %l1, %g6 ! %pc
sethi %hi(C_LABEL(csum_ldo4_fixup)), %l1
or %l1, %lo(C_LABEL(csum_ldo4_fixup)), %l1
wr %l0, 0x0, %psr ! fix cond-codes
and %l5, LOAD_IMMEDIATE_FIELD, %g7
srl %g7, LOAD_IMMEDIATE_SHIFT, %g7 ! offset
jmp %l1
rett %l1 + 0x4
1:
/* etc. for other instructions recognized */
mna_fromuser:
SAVE_ALL
/* From user mode or something we don't handle for the
* kernel.
*/
call C_LABEL(do_mna)
nop
RESTORE_ALL
Ok, now the fixup routines just look like:
csum_ldo4_fixup:
ldub [%o0 + %g7], %g4
add %g7, 1, %g7
ldub [%o0 + %g7], %g5
sll %g4, 24, %g4
add %g7, 1, %g7
sll %g5, 16, %g5
or %g4, %g5, %o4
ldub [%o0 + %g7], %g4
add %g7, 1, %g7
ldub [%o0 + %g7], %g5
sll %g4, 8, %g4
or %g5, %g4, %g4
jmp %g6 ! wheee...
or %o4, %g4, %o4
and so on... then csum_parial and friends can just blaze through
assuming proper alignment for all pointers to the packet contents
etc. Nifty eh? Sparc is fun...
Later,
David S. Miller
davem@caip.rutgers.edu
^ permalink raw reply [relevance 1%]
* Uselinux and the Linux/SPARC port (forwarded)
@ 1996-05-14 1:22 1% Larry McVoy
0 siblings, 0 replies; 200+ results
From: Larry McVoy @ 1996-05-14 1:22 UTC (permalink / raw)
To: lmlinux
------- Forwarded Message
Date: Sat, 11 May 1996 10:52:53 -0500
From: Miguel de Icaza <miguel@roxanne.nuclecu.unam.mx>
To: sparclinux-cvs@caipfs.rutgers.edu
cc: davem@caip.rutgers.edu, tridge@cs.anu.edu.au
Subject: Uselinux and the Linux/SPARC port
Hello guys,
On Jannuary the Uselinux conference will be help together with the
Usenix technical conference (http://www.usenix.org). David and I had
plans to make a technical presentation on the Linux/SPARC port. I
think Linux/SPARC is not just another port, but a port that has some
unique features not found on other ports.
The idea is to co-author this paper with those of you wanting to
help/contribute to the article.
I have assembled a list of things I think are interesting on
Linux/SPARC, I guess that before we can make a presentation on why we
find Linux/SPARC to be a unique port we will have to massage this
quite a bit. I have already mailed this one to Michael Johnson (He is
the technical session chair I think), if you want to co-author this
with David and I please, contact me (and CC the sparclinux-cvs list.
David will be very busy before leaving to SGI, so I'm doing the
coordination for this).
Best wishes,
Miguel.
* MMU/cache
Sparc have 3 types of MMU -- this is easy to plug into Linux.
Sparc have Virtual Addressed Caches (VAC) and Physical caches --
these require changes to Linux kernel. With the VACs, one must be
careful to not complete flush the caches as it was being done
initially, because they damage performace quite a bit.
As an extra challenge, some MMU are buggy, MMUs are accessed in
different ways.
Linux/SPARC uses pointer functions for most MMU/cache manipulation
* SunOS compatibility.
We use the model that Linus used to get OSF/1 compatibility.
(we use same constants, and same structures for the kernel,
thus no need to translate anything).
This model lets us have a userland ready early during the port and
the code is written when something fails to run properly.
Compare this to NetBSD, 4114 lines of code for Sparc code plus 2753
lines of generic emulation "libraries"; compare this to Linux: 1140
lines. We think this is the right way to future ports.
Linux emulation code is mostly related to features not found
usually in Linux (like assumption from SunOS applications on the
OS), while NetBSD's emulation code is spent on doing conversions
in/from each OS constants and data structures, so Linux does not
have a runtime performance penalty for running SunOS applications.
Sparc drivers have to support the Linux interface and the SunOS
interface to make some programs happy (X-Window), the mouse driver,
keyboard driver and frame buffer drivers provide SunOS interfaces.
The mouse and keyboard driver provide the same interface to Linux
applications as it is found on original i386 port.
* Drivers for undocumented hardware.
Getting information out of Sun is not very easy. Documentation for
some hardware came from the vendor that makes the chips (scsi and
lance drivers), sources for the NetBSD, Sprite and the Xinu
operating system were used as references at the beginning of the
port to understand the architecture.
bwtwo, cg3 and cg6 drivers were based on existing NetBSD drivers
and a generic frame buffer interface for Linux/SPARC was coded. A
driver for the cg14 has been written using only Solaris include
file for the video card and some poking at the rom letting us
emulate a lowend graphics card on it.
* Stability and performance.
During the port the use of crashme has been constantly used to avoid
the same mistakes on Sun operating system.
lmbench has been used to test the performance of the operating
system. It was not just used as a benchmarking tool, but also to
pinpoint weaknesses in the port. After a couple of weeks tunning
the port, Linux/SPARC was able to keep up against SunOS and Solaris
on the same hardware and in some cases outperforming them.
The lmbench results are more interesting than they may appear at
first sight: They do not only reflect that Linux is a great
operating system, but most sadly it reflects the fact that
corporate operating systems are sometimes bloated and slow. The
reason for bloated operating systemd may come from different
sources, as documented in the 4.3BSD book, there were 13 memory
allocators on the BSD kernel in 1986, at that point they were aware
of the problem: code is being rewritten over and over. This in my
opinion means that most kernel programmers lack a deep knowledge on
the operating system and may be writting thing that are not
completely clean
(anecdote: over the past two weeks I made one remark and one
suggestion to the kernel to Linus, and even when they looked fine
to me and many people agree they are Linus quickly pointed me out
where the design flaws were in; it was related rfork, btw).
* SMP
Problems encountered when porting Linux to the Sparc. Not all SMP
machines are born the same, there are some hacks required to get
SMP working on the Sparc.
[Ufinished section I will complete this section later]
* Portability and the AP+
The Linux/SPARC port is itself a relatively easy to port to non Sun
hardware. Andrew Tridgell and his hackers team in Canberra have
ported Linux/SPARC to the AP+ multiprocessor.
[ This section is still not finished ]
* Bootstraping the SPARC.
Booting the SPARC required: a) cleaning up the ext2fs to make it
aware of the endianess of the SPARC; b) the merging into the
kernel of the nfsroot allowed one of the developers to work without
a hard disk, and let people test drive Linux kernel without needing
to reformat their disks.
Jay Eastabrook's Alpha console code split was used as the second
attempt at the Linux console code. Once we had this one, we got
the same functionality of Linux/i386 on the sparc.
* SILO.
SILO is unique in one aspect: It is the first Linux boot loader
that uses the ext2fs library from the ext2fs tool suite by Remy
Card and Ted Tso. This is a good thing because it let us write the
boot loader in a very short time frame.
The SILO bootloader fully understands the ext2fs and thus does not
require a special boot loader installer for each kernel image that
is made available. There is still work in progress on LILO to make
it work with iso9660 cdroms and boot loading.
* The port
David Miller setup an account for the developers on vger to have
access to his CVS tree so that we could make changes directly to
the source tree without taking time from him. Simple rules were
set: test before you commit your code.
Another idea that was pushed since the beginning was to keep track
of current kernel developement. Even if this would imply that we
had to spend some time merging and fixing sparc stuff on our
kernels, it helped us to merge our tree faster and easier than the
other ports. Letting versions slip proved to be not a very good
idea, and the MkLinux people will suffer with it as did the m68k
guys some months ago.
* Userland
The first attempt at a Libc port was done by porting Linux's a.out
Libc4 to the SPARC. Later a GNU libc port was attempted, but
because of the adapting nature of the kernel to the host OS for
binary compatibility, the GNU libc port was found to not be
possible at the time, we may try again as soon as some issues are
hashed out on glibc.
Currently the Linux Libc 5 is in use and ELF loading has been fixed
into the kernel. Eric Youngdale is making the elf loader less
i386-centric, and thus our patches will go in easier.
The libc5 supports shared executables and Eric's ld.so linker has
been ported to the SPARC, as well as adapting it to Linux
(originally it was written and tested on Solaris). What is amazing
is that this linker is quite portable nowadays.
RedHat and Debian are both working on Linux distributions for the
SPARC. The goal is to have the same interface on all different
architectures and in the future encourage commercial software
companies to compile with a cross compiler versions of their
software for all the available platforms of Linux.
------- End of Forwarded Message
^ permalink raw reply [relevance 1%]
* Linux/AP+ technical report (forwarded)
@ 1996-05-14 1:23 1% Larry McVoy
0 siblings, 0 replies; 200+ results
From: Larry McVoy @ 1996-05-14 1:23 UTC (permalink / raw)
To: lmlinux
------- Forwarded Message
Date: Sat, 11 May 1996 22:51:12 +1000
From: Andrew Tridgell <tridge@cs.anu.edu.au>
To: Multiple recipients of list <linux-mc@arvidsjaur.anu.edu.au>
Subject: Linux/AP+ technical report
Hi,
We've written a short tech report on what we've done so far to port
Linux to the AP1000+ multicomputer.
Its available on our home page at
http://cap.anu.edu.au/cap/projects/linux
We'd be very interested to hear comments on what you think of our
approach.
Obviously our port is still pretty simple, and a lot more needs to be
done to make a really multicomputer OS, but at least its a start :-)
Andrew
PS: I'm also hoping this might start some discussion on this list!
------- End of Forwarded Message
^ permalink raw reply [relevance 1%]
* numbers...
@ 1996-05-15 3:28 1% David S. Miller
0 siblings, 0 replies; 200+ results
From: David S. Miller @ 1996-05-15 3:28 UTC (permalink / raw)
To: lm; +Cc: lmlinux, torvalds, sparclinux-cvs
Two nights of coding, not bad...
This has to be the fastest csum and csum_copy humanly codable on the
Sparc. Here are some initial results. On each run the cache was
purposely forced to be cold on each iteration:
sun4m SS10 115mhz hypersparc, 256k cache
measure_csum_partial
csum_partial: sz[1024] 10000 iterations takes 17009430 microseconds
csum_partial: sz[1024] 1 iteration takes <1700 microseconds>==<332 nanoseconds>
csum_partial: sz[2048] 10000 iterations takes 32609649 microseconds
csum_partial: sz[2048] 1 iteration takes <3260 microseconds>==<636 nanoseconds>
csum_partial: sz[3072] 10000 iterations takes 48152422 microseconds
csum_partial: sz[3072] 1 iteration takes <4815 microseconds>==<940 nanoseconds>
csum_partial: sz[4096] 10000 iterations takes 63708679 microseconds
csum_partial: sz[4096] 1 iteration takes <6370 microseconds>==<1244 nanoseconds>
measure_csum_partial_copy
csum_partial_copy: sz[1024] 10000 iterations takes 30865212 microseconds
csum_partial_copy: sz[1024] 1 iteration takes <3086 microseconds>==<602 nanoseconds>
I'm estimating the function call overhead is around 29 nanoseconds to
get into the damn routine, and around 3 or 4 nanoseconds overhead from
the loop constructs etc. in the benchmark. It seems to scale very
nicely, on this chip you tend eat around 8ns for byte end aligned
buffers and around 5ns for an extraneous halfword at the end of the
buffer. 0.4us/Kbyte for csum, and 0.6us/Kbyte for csum_copy, _really_
impressive.
Here are some figures for small buffers on the same cpu:
csum_partial: sz[20] 200000 iterations takes 55822206 microseconds
csum_partial: sz[20] 1 iteration takes <279 microseconds>==<54 nanoseconds>
csum_partial: sz[21] 200000 iterations takes 64016336 microseconds
csum_partial: sz[21] 1 iteration takes <320 microseconds>==<62 nanoseconds>
csum_partial: sz[22] 200000 iterations takes 61093525 microseconds
csum_partial: sz[22] 1 iteration takes <305 microseconds>==<59 nanoseconds>
csum_partial: sz[23] 200000 iterations takes 65481187 microseconds
csum_partial: sz[23] 1 iteration takes <327 microseconds>==<63 nanoseconds>
csum_partial: sz[24] 200000 iterations takes 61168735 microseconds
csum_partial: sz[24] 1 iteration takes <305 microseconds>==<59 nanoseconds>
csum_partial: sz[25] 200000 iterations takes 69001025 microseconds
csum_partial: sz[25] 1 iteration takes <345 microseconds>==<67 nanoseconds>
csum_partial: sz[26] 200000 iterations takes 66418949 microseconds
csum_partial: sz[26] 1 iteration takes <332 microseconds>==<64 nanoseconds>
csum_partial: sz[27] 200000 iterations takes 71029491 microseconds
csum_partial: sz[27] 1 iteration takes <355 microseconds>==<69 nanoseconds>
csum_partial: sz[28] 200000 iterations takes 66360048 microseconds
csum_partial: sz[28] 1 iteration takes <331 microseconds>==<64 nanoseconds>
csum_partial: sz[29] 200000 iterations takes 74353705 microseconds
csum_partial: sz[29] 1 iteration takes <371 microseconds>==<72 nanoseconds>
csum_partial: sz[30] 200000 iterations takes 71737147 microseconds
csum_partial: sz[30] 1 iteration takes <358 microseconds>==<69 nanoseconds>
csum_partial: sz[31] 200000 iterations takes 76436420 microseconds
csum_partial: sz[31] 1 iteration takes <382 microseconds>==<74 nanoseconds>
csum_partial: sz[32] 200000 iterations takes 40741293 microseconds
csum_partial: sz[32] 1 iteration takes <203 microseconds>==<39 nanoseconds>
csum_partial: sz[33] 200000 iterations takes 48651585 microseconds
csum_partial: sz[33] 1 iteration takes <243 microseconds>==<47 nanoseconds>
csum_partial: sz[34] 200000 iterations takes 46065031 microseconds
csum_partial: sz[34] 1 iteration takes <230 microseconds>==<44 nanoseconds>
csum_partial: sz[35] 200000 iterations takes 50451529 microseconds
csum_partial: sz[35] 1 iteration takes <252 microseconds>==<49 nanoseconds>
csum_partial: sz[36] 200000 iterations takes 45143096 microseconds
csum_partial: sz[36] 1 iteration takes <225 microseconds>==<43 nanoseconds>
csum_partial: sz[37] 200000 iterations takes 53111738 microseconds
csum_partial: sz[37] 1 iteration takes <265 microseconds>==<51 nanoseconds>
csum_partial: sz[38] 200000 iterations takes 50421138 microseconds
csum_partial: sz[38] 1 iteration takes <252 microseconds>==<49 nanoseconds>
csum_partial: sz[39] 200000 iterations takes 54893618 microseconds
csum_partial: sz[39] 1 iteration takes <274 microseconds>==<53 nanoseconds>
csum_partial: sz[40] 200000 iterations takes 50453690 microseconds
csum_partial: sz[40] 1 iteration takes <252 microseconds>==<49 nanoseconds>
csum_partial: sz[41] 200000 iterations takes 58411664 microseconds
csum_partial: sz[41] 1 iteration takes <292 microseconds>==<57 nanoseconds>
csum_partial: sz[42] 200000 iterations takes 55732943 microseconds
csum_partial: sz[42] 1 iteration takes <278 microseconds>==<54 nanoseconds>
csum_partial: sz[43] 200000 iterations takes 60187768 microseconds
csum_partial: sz[43] 1 iteration takes <300 microseconds>==<58 nanoseconds>
csum_partial: sz[44] 200000 iterations takes 55766810 microseconds
csum_partial: sz[44] 1 iteration takes <278 microseconds>==<54 nanoseconds>
csum_partial: sz[45] 200000 iterations takes 63732553 microseconds
csum_partial: sz[45] 1 iteration takes <318 microseconds>==<62 nanoseconds>
Now, some other CPU types.
sun4m MicroSparcI, 40mhz, 16k icache 20k dcache (can't remember if
thats right or not...):
measure_csum_partial
csum_partial: sz[1024] 10000 iterations takes 62380730 microseconds
csum_partial: sz[1024] 1 iteration takes <6238 microseconds>==<1218 nanoseconds>
csum_partial: sz[2048] 10000 iterations takes 127199716 microseconds
csum_partial: sz[2048] 1 iteration takes <12719 microseconds>==<2484 nanoseconds>
measure_csum_partial_copy
csum_partial_copy: sz[1024] 10000 iterations takes 180276825 microseconds
csum_partial_copy: sz[1024] 1 iteration takes <18027 microseconds>==<3520 nanoseconds>
Thats around 2.5us/Kbyte for csum, 3.6us/Kbyte for csum_copy, not bad
and could be a bit better with some reworking of the scheduling tuned
for the msI instruction cache to get less stalls. Probably not worth
it though (I come to this conclusion notably because when Gordon Irlam
reworked the SunOS/Solaris window trap handlers to do an extra window
for each trap for cache reasons it turned out to make no difference
performance wise in the "real world" although the code was indeed more
efficient on the msI).
sun4m SS10 Viking/MXCC, 50Mhz, 1mb physical cache, 16k icache
20k dcache (again, correct me here if I am wrong on the i/d sizes):
measure_csum_partial
csum_partial: sz[1024] 10000 iterations takes 31893405 microseconds
csum_partial: sz[1024] 1 iteration takes <3189 microseconds>==<622 nanoseconds>
csum_partial: sz[2048] 10000 iterations takes 60608539 microseconds
csum_partial: sz[2048] 1 iteration takes <6060 microseconds>==<1183 nanoseconds>
csum_partial: sz[3072] 10000 iterations takes 89327514 microseconds
csum_partial: sz[3072] 1 iteration takes <8932 microseconds>==<1744 nanoseconds>
csum_partial: sz[4096] 10000 iterations takes 118067205 microseconds
csum_partial: sz[4096] 1 iteration takes <11806 microseconds>==<2305 nanoseconds>
measure_csum_partial_copy
csum_partial_copy: sz[1024] 10000 iterations takes 45946764 microseconds
csum_partial_copy: sz[1024] 1 iteration takes <4594 microseconds>==<897 nanoseconds>
csum_partial_copy: sz[2048] 10000 iterations takes 88614537 microseconds
csum_partial_copy: sz[2048] 1 iteration takes <8861 microseconds>==<1730 nanoseconds>
csum_partial_copy: sz[3072] 10000 iterations takes 131338863 microseconds
csum_partial_copy: sz[3072] 1 iteration takes <13133 microseconds>==<2565 nanoseconds>
The huge physical cache certainly seems to make a difference, although
I think it is also noticable that the on-chip insn cache would do
better with my algorithm if it were just a tad bigger. Ho hum...
Note also how it doesn't scale as linearly as on the Hyper and the
msI, again this puzzles me bacaus the icache is smaller on msI.
sun4c SLC, 20MHZ, 64k I/D combined L2 virtual cache:
measure_csum_partial
csum_partial: sz[1024] 10000 iterations takes 227199286 microseconds
csum_partial: sz[1024] 1 iteration takes <22719 microseconds>==<4437 nanoseconds>
measure_csum_partial_copy
csum_partial_copy: sz[1024] 10000 iterations takes 539569714 microseconds
csum_partial_copy: sz[1024] 1 iteration takes <53956 microseconds>==<10538 nanoseconds>
Not too bad for this piece of garbage, the pure virtual 64k cache is
probably the real helper here. I see no other factor that can get
numbers like this on such a shit cpu. 4.5ms/Kbyte for csum, and
10.6ms/Kbyte for csum/copy... shit Jacobsons m68k algorithm only gets
134us/Kbyte on a 20MHZ 68020.
sun4c IPX, 40MHZ, 64k I/D combined L2 virtual cache:
measure_csum_partial
csum_partial: sz[1024] 10000 iterations takes 112377730 microseconds
csum_partial: sz[1024] 1 iteration takes <11237 microseconds>==<2194 nanoseconds>
csum_partial: sz[2048] 10000 iterations takes 223668577 microseconds
csum_partial: sz[2048] 1 iteration takes <22366 microseconds>==<4368 nanoseconds>
measure_csum_partial_copy
csum_partial_copy: sz[1024] 10000 iterations takes 345064536 microseconds
csum_partial_copy: sz[1024] 1 iteration takes <34506 microseconds>==<6739 nanoseconds>
A little more than twice as fast as the SLC, again the 64k virtual
cache is the performance factor even here and it seems the cache can
keep up with this cpu when it's hot. 2.2us/Kbyte for csum, and
6.8us/Kbyte for csum_copy, not bad at all.
I've verified all of my new code with a very extensive "cksum_helper"
program I wrote which also ran the above benchmarks after the
verification suite completed successfully. Now I just have to stick
this shit into the kernel and see if it goes ok. If all goes well we
might end up being able to beat Solaris on those TCP lmbench bandwidth
numbers, no promises.
Later,
David S. Miller
davem@caip.rutgers.edu
^ permalink raw reply [relevance 1%]
* Re: numbers...
@ 1996-05-15 16:40 1% Neal Nuckolls
1996-05-16 6:21 1% ` numbers David S. Miller
0 siblings, 1 reply; 200+ results
From: Neal Nuckolls @ 1996-05-15 16:40 UTC (permalink / raw)
To: davem; +Cc: sparclinux-cvs, torvalds, lmlinux
> sun4m SS10 115mhz hypersparc, 256k cache
> measure_csum_partial
> csum_partial: sz[1024] 10000 iterations takes 17009430 microseconds
> csum_partial: sz[1024] 1 iteration takes <1700 microseconds>==<332 nanoseconds>
Maybe I'm dense this morning but I don't understand the numbers.
You measure the realtime to do a sequential IP checksum on a 1K
buffer and you always invalidate the processor cache (I$, D$, and
Secondary$ or just some subset of these?) and don't include the
cost of doing the cache invalidate in the time above. 10000 of
these costs a hair over 17s, divide by 10000 gives 1.7ms per
iteration. This seems way high so must include the cost of the
cache invalidate or something?
What does the 332ns refer to?
My back of the envelope:
If I recall, the cacheline on a sun4m is 32bytes. Assuming
something in the 300-600ns/secondarycachemiss range and a single
pending cachemiss at a time would put most any "touch the data"
operation on 1K of data in the 9.6-19.2us ballpark or 9-18ns/byte
range.
Does the hypersparc processor support multiple concurrent cache
misses? Or does it have a Viking-like sequential reference
detector and automatic cache prefetch logic?
> sun4m MicroSparcI, 40mhz, 16k icache 20k dcache
> ...
> Thats around 2.5us/Kbyte for csum,
This must be hot$ that you're talking about? Exactly when do you
invalidate the caches?
thanks.
neal
^ permalink raw reply [relevance 1%]
* Re: mpp kernel interface
@ 1996-05-15 22:43 1% Larry McVoy
1996-05-16 9:09 1% ` Alan Cox
1996-05-16 14:20 1% ` Andrew Tridgell
0 siblings, 2 replies; 200+ results
From: Larry McVoy @ 1996-05-15 22:43 UTC (permalink / raw)
To: tridge; +Cc: linux-mc, Linus.Torvalds, linux, alan
: With 30 people now on this list there must be someone else who wants
: to say something ...
I'm going to try. I'm probably going to do a half assed job, as I am
feeling a bit sick today. But I'll give it a go.
: It really depends on how we end up using this stuff. Does anyone out
: there have any experience with implementing things like remote fork,
: remote paging, remote files/sockets etc? What sorts of interfaces are
: useful for doing stuff like that?
I have a few ideas. Lots of them are stolen from the UCAL Locus project,
Jim Bob says check it out.
First, this is mostly a naming problem. Wrap your brain around that. We
need to have clear in our heads exactly how everything is named. Once
you can draw that picture, the implementation becomes straight forward.
After you read through this, you may or may not be in basic agreement.
If we ever converge, I will volunteer to write "man pages" for each of
the chunks of work so that we have a well documented TODO list. It is
as close as I've ever gotten to a spec.
Things we need to name
hosts
cluster
processes
devices
files
sockets
other things
cluster {join,leave}
SMP vs cluster?
The hard one is sockets. I've never seen a good solution to that.
I'll come back to that. First, I want to go through the other ones and
offer suggestions.
Hosts are just hosts, nothing changes there.
Clusters are a mapping of "cluster_name" -> "list of hosts". Think
of getclustbyname(). I did this for SparcClusters, it worked pretty
well. The cluster is the name that you use to get to your cluster.
This implies that you wack rlogin/telnet and/or you wack DNS to
to translate from the cluster name to the hostname to the IP address
of that host. DNS is the easiest place.
Processes have two major chunks of work, the PID name space and how you
do remote processes. For the PID name space, make pid_t a 32 bit int,
make the top 16 bits the host part, and the bottom 16 bits the pid part.
(We need to come back to the host part when we discuss process migration.)
A host part of "0" means "this host". So a "kill -HUP 1" will always
restart init.
Remote processes. This part gets fun, fun, fun. Think of how we have
files as objects in the kernel, in C++ terms, an inode is a class with all
virtual methods - each instance of the class implments its own methods.
We need to do that for processes. For every operation we currently
do on a process, we need to make that a function call. You want this
layer to be very thin, it can't be a performance hit for local processes
or we blew it. The intances of the process class I imagine are at
least "local", "remote", "local debugged", "remote debugged". I can
also image using this to implement "local or remote, gang scheduled".
See how that works? I'm hand waving like crazy here. I'm not positive
the debugging stuff works in this layer, but I would love it if all the
System V /proc crap was buried in an optional instance of the process
class. I believe that you can make the non debugged instance faster.
Devices I sort of punt on. For device access, I would just use the
remote mag tape protocol (or something very, very similar) so that all
of the locking, etc., still works - since you ship all the requests to
the system w/ the device, that kernel can implement the locks. Any
issues here?
Files. I have also punted on this. I have never gotten that excited about
a cache coherent distributed file system, though others certainly do. It's
not because I don't think it is useful. I believe it can be done and that
we have the talent right here on this list to do it. So I'll bow out of
commenting on it, other than to say make sure mmap works right.
Sockets. This is a hard problem. Some people think that a socket
should stick around after the CPU that created the socket has crashed.
I don't know how to do that efficiently, so I punt. The only thing I
would suggest in the socket domain is (a) make gethostbyname("cluster")
be translated into a getclustbyname("cluster") so that you can think of
the cluster as one host (DNS or someone is round robining the host you
actually get), and (b) manage the routing tables within the cluster far
more dynamically that routing tables are corrently managed. The latter
means that you notice immediately when a CPU leaves the cluster and
update your routing tables to route around that dead CPU.
Cluster {join,leave} This turns out to be a thorny area. You gotta get it
right, too. You want the cluster to keep working in the face of a crashed
node. You also want nodes to be taken out and added back into the cluster
for whatever reasons. There's a whole set of protocol issues here that I'm
too sick to describe, trust me that we have a lot of work in this area.
SMP vs cluster. Lots of people wonder about this - do you do one, both,
neither? The smartest people I know, have all concluded the same thing:
you do 4 way SMP nodes, and cluster those to scale beyond the 4 CPUs.
The reasoning is as follows: when you are creating processes, you
are striping them across the cluster (if you have a coherent distributed
mmap, rfork() is not that hard, seems worse than it is, but as a first
pass, just do rexec(), that will scale parallel make which is a great
test case). It turns out from cache affinity studies that you really
want to avoid moving processes from one CPU/cache/memory to another.
It screws up your performance. On the other hand, if you get unlucky
with your striping alg and land a couple of long running processes on
the same node, it is nice to have more than one CPU there to handle the
load. Another way to state this: you need to balance your load. If
you try and statically balance it at fork and/or exec time, you will
make mistakes because you don't have enough info at that point to do
perfect scheduling job. If you are sending jobs to SMPs instead of
uniprocessers, the SMPs can do a reasonable job of dynamically scheduling
the load. And a 4 way SMP is a good first order approximation of an
infinitely large SMP, it is rare that you'll screw up so badly that
you need more than 4 processors to smooth out the load.
So why am I beating on this issue so hard? Because I don't want a
fine grained threaded SMP kernel. Threading the kernel that much introduces
way too much of a performance penalty for the simple case of "run this
one job". Also consider that the SMP kernel may well form the basis for
a fully preemptable uniprocessor kernel. I do not want to sacrafice more
than 1% performance on the uniprocessor to get preemption. Solaris and
IRIX both suck at this - you pay big time for that checklist item.
If you walk into the SMP arena with the model that you "fork" your system
every 4 processors, then you don't have to work so hard to get scaling.
Coarse grained, non intrusive locking will work just fine for 4 processors
and you leave the rest to the cluster. Cool?
Finally - when doing all of this stuff, please do a 100Mbit ethernet based
version as well as the AP version. If you come at it from a network point
of view, a whole bunch of problems will _not_ happen in the AP version.
When you have all that nice hardware, you tend to use it and it can
screw up the architecture such that a network based cluster won't work.
On the other hand, if you do a network based cluster, you are guarenteed
that you have a partioned solution. As you try and make all of those
kernels work on that one big shared memory, you'll find that partitioning
is a big performance win. Coming from a network cluster, you'll get that
without having to work for it - the other way frequently is harder.
That's enough for now, how about some comments?
--lm
^ permalink raw reply [relevance 1%]
* Re: numbers...
1996-05-15 16:40 1% numbers Neal Nuckolls
@ 1996-05-16 6:21 1% ` David S. Miller
0 siblings, 0 replies; 200+ results
From: David S. Miller @ 1996-05-16 6:21 UTC (permalink / raw)
To: nn; +Cc: sparclinux-cvs, torvalds, lmlinux
Date: Wed, 15 May 1996 09:40:53 -0700
From: nn@lanta.engr.sgi.com (Neal Nuckolls)
> sun4m SS10 115mhz hypersparc, 256k cache
> measure_csum_partial
> csum_partial: sz[1024] 10000 iterations takes 17009430 microseconds
> csum_partial: sz[1024] 1 iteration takes <1700 microseconds>==<332 nanoseconds>
Maybe I'm dense this morning but I don't understand the numbers.
[NOTE: real lmbench results with the new checksum code in a bit, it's
not as much of an improvement as I wanted and Solaris still
gets better TCP bandwidth on localhost.]
The benchmark looks like:
for(iter=0; iter < 10000; iter++) {
for(inner=0; inner < 512; inner++) {
csum(foo, bar, baz);
flush_caches();
}
}
The 512 number is just imperical because for small buffers (less than
1k) doing just one iteration caused it impossible to measure anything
significant.
I am factoring in the time the cache flush takes. I calculate how
long it takes to do the flush before the loop runs, then subtract that
value multiplied by (iter * inner) from the final time.
So the 17009430 microseconds is the time it takes to run the entire
loop structure minus the flushing overhead.
1700 microseconds is the time each run of the inner for loop took
again minus the flush overhead, 332 nanoseconds is the absolute time
each instance of the csum() took to run on the buffer once again this
is after subtracting the flush overhead.
Later,
David S. Miller
davem@caip.rutgers.edu
^ permalink raw reply [relevance 1%]
* References for MIPS hacking
@ 1996-05-16 7:02 1% Michael Beach
0 siblings, 0 replies; 200+ results
From: Michael Beach @ 1996-05-16 7:02 UTC (permalink / raw)
To: linux
Hello all.
Is anything much happening on this list? I haven't seen any activity for
quite a while? A few real questions too...
Does this port target the R4000 and up, or is it meant to run on R3000s as
well? Also, can anyone point me at the 'canonical reference' for the MIPS
processors? Do MIPS publish programmers reference manuals, or do I have to
hassle their 'technology partners' ie LSI, IDT etc.
Thanks in advance!
Regards
M.Beach
^ permalink raw reply [relevance 1%]
* lmbench with new checksum code...
@ 1996-05-16 6:53 1% David S. Miller
1996-05-16 9:35 1% ` Alan Cox
0 siblings, 1 reply; 200+ results
From: David S. Miller @ 1996-05-16 6:53 UTC (permalink / raw)
To: lmlinux; +Cc: torvalds, sparclinux-cvs, alan
It's not as hot as I wanted it to be, ho hum... Just for flavor I've
included numbers for my 115MHZ hypersparc running SunOS so no none
forgets that this is all running on a shitty SparcClassic. ;-)
I'm probably stalling the chip stupidly in my code or not touching the
cache lines in the correct order, ugh this is pissing me off, I'll
check it out some more tomorrow when my head doesn't hurt so much...
I doubt I can get 2mb/s more out of my code to beat solaris, sigh,
where the heck could all this overhead possibly be???
L M B E N C H 1 . 0 S U M M A R Y
------------------------------------
Processor, Processes - times in microseconds
--------------------------------------------
Host OS Mhz Null Null Simple /bin/sh Mmap 2-proc 8-proc
Syscall Process Process Process lat ctxsw ctxsw
--------- ------------- ---- ------- ------- ------- ------- ---- ------ ------
trombetas Linux 1.99.3 50 15 8.8K 40.9K 75K 350 83 100
geneva.ru SunOS 5.5 50 31 33.7K 148.2K 274K 596 174 205
negro.rut SunOS 4.1.3_U 49 124 18.3K 63.9K 110K 470 152 262
huahaga.r SunOS 4.1.4 115 32 10.4K 34.3K 59K 169 96 104
*Local* Communication latencies in microseconds
-----------------------------------------------
Host OS Pipe UDP RPC/ TCP RPC/
UDP TCP
--------- ------------- ------- ------- ------- ------- -------
trombetas Linux 1.99.3 295 1016 1756 1408 2564
geneva.ru SunOS 5.5 530 1563 2080 1354 2398
negro.rut SunOS 4.1.3_U 890 1375 2287 1573 2804
huahaga.r SunOS 4.1.4 306 616 956 667 1161
*Local* Communication bandwidths in megabytes/second
----------------------------------------------------
Host OS Pipe TCP File Mmap Bcopy Bcopy Mem Mem
reread reread (libc) (hand) read write
--------- ------------- ---- ---- ------ ------ ------ ------ ---- -----
trombetas Linux 1.99.3 8 4.8 25.0 17.4 18 24 41 36
geneva.ru SunOS 5.5 8 7.0 12.6 19.5 18 18 40 36
negro.rut SunOS 4.1.3_U 4 2.0 19.5 8.2 18 24 41 36
huahaga.r SunOS 4.1.4 14 5.3 30.2 19.9 20 22 48 37
Memory latencies in nanoseconds
(WARNING - may not be correct, check graphs)
--------------------------------------------
Host OS Mhz L1 $ L2 $ Main mem TLB Guesses
--------- ------------- --- ---- ---- -------- --- -------
trombetas Linux 1.99.3 50 20 170 180 600 No L2 cache?
geneva.ru SunOS 5.5 49 - - - - Bad mhz?
negro.rut SunOS 4.1.3_U 49 20 175 183 659 No L2 cache?
huahaga.r SunOS 4.1.4 115 17 17 510 842 No L1 cache?
^ permalink raw reply [relevance 1%]
* Re: mpp kernel interface
1996-05-15 22:43 1% mpp kernel interface Larry McVoy
@ 1996-05-16 9:09 1% ` Alan Cox
1996-05-16 14:20 1% ` Andrew Tridgell
1 sibling, 0 replies; 200+ results
From: Alan Cox @ 1996-05-16 9:09 UTC (permalink / raw)
To: Larry McVoy; +Cc: tridge, linux-mc, Linus.Torvalds, linux, alan
> : With 30 people now on this list there must be someone else who wants
> : to say something ...
I've not actually seen anything from the list (should be going to ukuu)
> SMP vs cluster?
Why vs, why not AND. An SMP box is just a couple of well connected nodes.
> The hard one is sockets. I've never seen a good solution to that.
> I'll come back to that. First, I want to go through the other ones and
> offer suggestions.
There are several approaches to this. One is to treat it like a device so
you open a socket on a given machine and it like the device doesnt walk. The
other is to bend IP mobile to the needs. That would probably want something
like an old 486 as a network FEP.
> do remote processes. For the PID name space, make pid_t a 32 bit int,
> make the top 16 bits the host part, and the bottom 16 bits the pid part.
> (We need to come back to the host part when we discuss process migration.)
> A host part of "0" means "this host". So a "kill -HUP 1" will always
> restart init.
We can also do this for devices so you can mknod a printer on a different
node.
> Devices I sort of punt on. For device access, I would just use the
> remote mag tape protocol (or something very, very similar) so that all
> of the locking, etc., still works - since you ship all the requests to
> the system w/ the device, that kernel can implement the locks. Any
> issues here?
The vfs issues fairly controlled requests to the FS layer, and the device
layer also is fairly clean. The MOSIX project intercepted stuff at this
level --- so a remote device turns the request into a message. The system
also accounted messages so a process like a find would migrate across cpus
as it changed the disk it was searching.
> we have the talent right here on this list to do it. So I'll bow out of
> commenting on it, other than to say make sure mmap works right.
mmap is foul. SYS5 shared memory is just as bad too.
> Sockets. This is a hard problem. Some people think that a socket
> should stick around after the CPU that created the socket has crashed.
If you are having a single apparent IP address this is true for TCP, you can
on spotting a down host just send an RST and go into TIME_WAIT to preserve
the corruption protection properties of TCP.
> is a big performance win. Coming from a network cluster, you'll get that
> without having to work for it - the other way frequently is harder.
It also means more people can play
^ permalink raw reply [relevance 1%]
* Re: mpp kernel interface
@ 1996-05-16 9:09 1% ` Alan Cox
0 siblings, 0 replies; 200+ results
From: Alan Cox @ 1996-05-16 9:09 UTC (permalink / raw)
To: Larry McVoy; +Cc: tridge, linux-mc, Linus.Torvalds, linux, alan
> : With 30 people now on this list there must be someone else who wants
> : to say something ...
I've not actually seen anything from the list (should be going to ukuu)
> SMP vs cluster?
Why vs, why not AND. An SMP box is just a couple of well connected nodes.
> The hard one is sockets. I've never seen a good solution to that.
> I'll come back to that. First, I want to go through the other ones and
> offer suggestions.
There are several approaches to this. One is to treat it like a device so
you open a socket on a given machine and it like the device doesnt walk. The
other is to bend IP mobile to the needs. That would probably want something
like an old 486 as a network FEP.
> do remote processes. For the PID name space, make pid_t a 32 bit int,
> make the top 16 bits the host part, and the bottom 16 bits the pid part.
> (We need to come back to the host part when we discuss process migration.)
> A host part of "0" means "this host". So a "kill -HUP 1" will always
> restart init.
We can also do this for devices so you can mknod a printer on a different
node.
> Devices I sort of punt on. For device access, I would just use the
> remote mag tape protocol (or something very, very similar) so that all
> of the locking, etc., still works - since you ship all the requests to
> the system w/ the device, that kernel can implement the locks. Any
> issues here?
The vfs issues fairly controlled requests to the FS layer, and the device
layer also is fairly clean. The MOSIX project intercepted stuff at this
level --- so a remote device turns the request into a message. The system
also accounted messages so a process like a find would migrate across cpus
as it changed the disk it was searching.
> we have the talent right here on this list to do it. So I'll bow out of
> commenting on it, other than to say make sure mmap works right.
mmap is foul. SYS5 shared memory is just as bad too.
> Sockets. This is a hard problem. Some people think that a socket
> should stick around after the CPU that created the socket has crashed.
If you are having a single apparent IP address this is true for TCP, you can
on spotting a down host just send an RST and go into TIME_WAIT to preserve
the corruption protection properties of TCP.
> is a big performance win. Coming from a network cluster, you'll get that
> without having to work for it - the other way frequently is harder.
It also means more people can play
^ permalink raw reply [relevance 1%]
* Re: lmbench with new checksum code...
1996-05-16 6:53 1% lmbench with new checksum code David S. Miller
@ 1996-05-16 9:35 1% ` Alan Cox
0 siblings, 0 replies; 200+ results
From: Alan Cox @ 1996-05-16 9:35 UTC (permalink / raw)
To: David S. Miller; +Cc: lmlinux, torvalds, sparclinux-cvs, alan
> I doubt I can get 2mb/s more out of my code to beat solaris, sigh,
> where the heck could all this overhead possibly be???
What makes you think the Solaris loopback is even doing checksums or a memcpy
via kernel space ? They only way you'll beat solaris at the loopback network
game is to cheat as they do. Make tcp_connect spot a localhost connection
change the socket method to something akin to af_unix but streamlined a bit
(only special case is urgent data).
Alan
^ permalink raw reply [relevance 1%]
* Re: lmbench with new checksum code...
@ 1996-05-16 9:35 1% ` Alan Cox
0 siblings, 0 replies; 200+ results
From: Alan Cox @ 1996-05-16 9:35 UTC (permalink / raw)
To: David S. Miller; +Cc: lmlinux, torvalds, sparclinux-cvs, alan
> I doubt I can get 2mb/s more out of my code to beat solaris, sigh,
> where the heck could all this overhead possibly be???
What makes you think the Solaris loopback is even doing checksums or a memcpy
via kernel space ? They only way you'll beat solaris at the loopback network
game is to cheat as they do. Make tcp_connect spot a localhost connection
change the socket method to something akin to af_unix but streamlined a bit
(only special case is urgent data).
Alan
^ permalink raw reply [relevance 1%]
* Re: lmbench with new checksum code...
1996-05-16 9:35 1% ` Alan Cox
(?)
@ 1996-05-16 10:08 1% ` Linus Torvalds
-1 siblings, 0 replies; 200+ results
From: Linus Torvalds @ 1996-05-16 10:08 UTC (permalink / raw)
To: Alan Cox; +Cc: David S. Miller, lmlinux, sparclinux-cvs
On Thu, 16 May 1996, Alan Cox wrote:
>
> What makes you think the Solaris loopback is even doing checksums or a memcpy
> via kernel space ? They only way you'll beat solaris at the loopback network
> game is to cheat as they do. Make tcp_connect spot a localhost connection
> change the socket method to something akin to af_unix but streamlined a bit
> (only special case is urgent data).
One day we might actually want to do something like that. No, I'm not
suggesting special-casing loopback (we don't need it any more, we're getting
good enough performance as-is), but I would suggest that at some point we
integrate the networking code a bit tighter in the VFS model of open/close.
One problem with the networking code right now is that we can't short-circuit
some of the decisions, so we're doing unnecessary run-time checks. This is
not really much of a performance problem, I consider it more of a beaty wart
right now.
For example, when we open a normal pipe (be it unnamed or named), we
never go through the filesystem code for that pipe any more - we just
make the file operations point directly to the pipe code, and when we
read/write to that pipe we don't have any filesystem overhead.
In contrast, when we open a network connection, we always go through the
network layer, even at run-time. Admittedly there are some reasons for
this, but most of them aren't really valid any more.
For example, sockets used to really be totally separate entities from
inodes, so we couldn't consider sockets to be part of the VFS layer. But
that isn't true any more (and hasn't been for a long whole): sockets
really _are_ implemented as a part of the inode these days. So a "socket"
is really just the network-specific part of an inode (the same way the
"normal" filesystems have their own private parts - look at the inode "u"
union to see what I mean.
However, due to historical reasons, the internal socket routines do not
use the VFS "inode" abstraction, but instead they use only the socket
sub-part. Sometime in the future I would really like to get rid of that,
and make the low-level socket code use the "inode" the same way everybody
else does.
This is _definitely_ not a huge issue - as I said it's more cleanlyness
and encapsulation than performance. It will require making the
socket-specific IO operations (recvmsg etc) be first-class members in the
VFS layer etc, and in general it requires a lot of minor modifications.
Nothing terribly hard (and some things get cleaner thanks to it), but
it's a lot of code that has to be worked out.
Merging the sockets more tightly into the VFS layer gets rid of the current
"struct socket" that we don't really need (as opposed to the "struct sock",
which is a different beast altogether) and at least partly the "struct
proto_ops" (which would just be part of the "struct file_operations"). We'd
get rid of one (slightly confusing) layer of abstraction, and some cases
could be streamlined a bit.
Finally, let me say again that I don't think we should short-circuit loopback
TCP like Solaris does. I used to think it was a nifty feature, but I got
better. When I talk about streamlining above, I'm thinking of similar
short-circuiting, but on a much smaller scale (getting rid of run-time checks
that can be done when the state of the thing changes instead).
For an example of what I'm talking about, look at how the tty layer uses the
operations pointers to handle hangup etc. It just changes the file operations
pointer, which automagically means that the files start behaving differently
once they've been hung up (without having the actual routines do any extra
"am I hung up" checking). That's the kind of thing that the network layer
could do too if it was better integrated with the VFS layer.
[ Alan has heard some of this before - I've been talking about these changes
for a long time. I've never felt they have been important enough to really
do something radical about it, but I still think it's the right thing to do
eventually ]
Linus
^ permalink raw reply [relevance 1%]
* Re: mpp kernel interface
1996-05-15 22:43 1% mpp kernel interface Larry McVoy
1996-05-16 9:09 1% ` Alan Cox
@ 1996-05-16 14:20 1% ` Andrew Tridgell
1996-05-16 17:19 1% ` Alan Cox
1 sibling, 1 reply; 200+ results
From: Andrew Tridgell @ 1996-05-16 14:20 UTC (permalink / raw)
To: lm; +Cc: linux-mc, Linus.Torvalds, linux, alan
Larry,
I think what you describe is really a blueprint for a "throughput"
machine, a machine that gets its parallelism mostly from the fact that
you will be running lots of independent jobs on it at once. The
alternative is a "parallel" machine, which aims to get optimal
performance even when just running one or two programs.
For example, a throughput machine is an ideal departmental
server. Lots of people doing edits/compiles with some heavy computation
thrown in now and then. Its the sort of thing that clusters of
workstations normally do.
A "parallel" machine is what supercomputer centres often have. They
run just one or two jobs at once, but they are big jobs, like climate
modelling or fluid dynamics simulations. They use huge amounts of ram
(many GB) for the one process and require very tight communications
using specialised parallel libraries.
Our research group is really centered around parallel systems, with
algorithms that scale to thousands of cpus. Unfortunately our budget
only stretches to 16 cpus on the AP+ at the moment, but we can also
run on much larger systems like we did this week by connecting to the
"Parallel Computing Research Facility" at Fujitsu in Japan.
This approach has a number of implications:
- we're not as worried about the ability to dynamically enter/leave a
"cluster". This makes algorithms simpler and faster as they can use
data structures that assume that the number of cpus and their layout
stays static.
- we're not as worried about recovering/continuing if a cpu
crashes. If all user jobs are running on all cpus then it doesn't make
much sense to try to recover when one goes down, as it kills all user
jobs anyway, so you might as well shutdown (crash), replace the part
and startup again. Its not as though this is a common experience for
us anyway. I don't think we've had a hardware fault on our 128 cpu
ap1000 yet, after several years of operation.
- we're worried about getting the very best bandwidth/latency out of
the communications network, while still providing all the lovely
operating system services that Linux provides.
- we're worried about providing efficient parallel filesystem, memory
and networking abstractions, scalable to lots of processors.
> Processes have two major chunks of work, the PID name space and how you
> do remote processes. For the PID name space, make pid_t a 32 bit int,
> make the top 16 bits the host part, and the bottom 16 bits the pid part.
> (We need to come back to the host part when we discuss process migration.)
> A host part of "0" means "this host". So a "kill -HUP 1" will always
> restart init.
ok, this makes sense with what we've done so far, which is really just
a tightly integrated network of workstations. I'm not at all sure its
what we want in the long term however. It assumes that things like
init will be running on every cpu, so that you have to distinguish
which copy of init you mean when you send it a signal.
I'm hoping that we will eventually have a really "single system image"
machine, where only one copy of init is actually running. Most cpus
would not be running any system daemons at all, just the necessary
kernel threads.
Right now we do in fact have one copy of init on each cpu, along with
lots of other daemons. We can get away with them all having the same
pid because the system isn't really parallel yet, there is no notion
of a remote syscall. (we have in fact done a remote signal send
operation for parallel programs, but its not as general as a remote
kill)
> Devices I sort of punt on. For device access, I would just use the
> remote mag tape protocol (or something very, very similar) so that all
> of the locking, etc., still works - since you ship all the requests to
> the system w/ the device, that kernel can implement the locks. Any
> issues here?
mostly speed issues. Could using something like rmt really scale to
lots of processors with reasonable performance?
> Files. I have also punted on this. I have never gotten that excited about
> a cache coherent distributed file system, though others certainly do. It's
> not because I don't think it is useful. I believe it can be done and that
> we have the talent right here on this list to do it. So I'll bow out of
> commenting on it, other than to say make sure mmap works right.
The big problems are indeed cache coherency and things like mmap(). We
implemented a parallel filesystem called HiDIOS on the 128 node ap1000
which worked by putting the buffer cache for a block on the cell that
owns the block. We didn't support mmap() as the machine had no mmu,
and the only cache local to each cpu is an optional one controlled by
the user in much the same way as stdio, but applied to file
descriptors in the C library.
We were able to get away with this because the remote memory access
bandwidth was very high (slightly higher in fact than local memory),
and latencies were low. We also used a really simple meta data
structure that completely elimated indirect blocks to find data on the
disk. We got 60MB/sec through the filesystem (the hardware limit is
64MB/sec).
We've seen attempts to put standard unix filesystem structures on
parallel machines and they are just not efficient enough. The cost of
manipulating all that meta data is huge when the disks (in parallel)
are capable of higher thoughputs than a local memory copy.
We are planning on doing a similar parallel filesystem for
Linux/AP+. We'll use a more sophisticated meta data scheme than was
used in the AP1000 HiDIOS, but still much simpler than that used in
ext2. It will be tuned for big io tasks, like loading 2GB of data
before the start of a heavy computing task. It will probably be
pathetic for loading your .cshrc, but we aren't going to be
encouraging people to use this system to run shell scripts on :-)
I still don't know how we are going to handle mmap. We think mmap is
very important in a parallel filesystem, but we just don't know how to
implement it in a really fast and coherent way yet.
> Sockets. This is a hard problem. Some people think that a socket
> should stick around after the CPU that created the socket has crashed.
yep, sockets are probably hard. We've already met problems with
them and we haven't even tried to make them parallel yet :-)
We use sockets to implement the stdin/stdout/stderr of parallel
processes. The paralleld that launches parallel programs on each cell
first creates 3 sockets back to the launching program, setting them up
as file desciptors 0, 1 and 2. When it then does a fork()/exec() the
parallel program inherits them.
The problem is that on a 64 cell machine we end up having 192 sockets
connected to the one process on the front end that launched the
parallel program. This is madness! It also won't work well if we have
1024 cpus :-)
I'm hoping this problem will go away when we revamp the way we launch
parallel programs. If we had a remote fork() and/or remote exec()
and also had a way for the file descriptors of remote forked processes
to feed back into the parent cpu then it would be much better.
We'd probably also need to use a tree structure to feed the file
descriptors (and paging for that matter) back up into the parent
process. 1000 children all writing to one parent would not be pretty.
> Cluster {join,leave} This turns out to be a thorny area. You gotta get it
> right, too. You want the cluster to keep working in the face of a crashed
> node. You also want nodes to be taken out and added back into the cluster
> for whatever reasons. There's a whole set of protocol issues here that I'm
> too sick to describe, trust me that we have a lot of work in this area.
This is a really interesting area to work on, but its probably not
something our group will be looking at soon, for the reasons described
earlier. We've got to focus our attentions a bit :-)
> Finally - when doing all of this stuff, please do a 100Mbit ethernet based
> version as well as the AP version. If you come at it from a network point
> of view, a whole bunch of problems will _not_ happen in the AP version.
> When you have all that nice hardware, you tend to use it and it can
> screw up the architecture such that a network based cluster won't work.
> On the other hand, if you do a network based cluster, you are guarenteed
> that you have a partioned solution. As you try and make all of those
> kernels work on that one big shared memory, you'll find that partitioning
> is a big performance win. Coming from a network cluster, you'll get that
> without having to work for it - the other way frequently is harder.
We probably won't do a 100Mbit version ourselves, we just don't have
the time. We'd love to cooperate with people that are doing it,
however, and I hope that a lot of what we do will be relevant for
systems like that.
The problem is really latency. Ethernet type systems have latencies
which aren't much lower than the system clock tick interval. This
means it often makes sense to do things is quite different ways to
what we have to do.
Cheers, Andrew
^ permalink raw reply [relevance 1%]
* Re: lmbench with new checksum code...
@ 1996-05-16 16:03 1% Larry McVoy
1996-05-16 17:32 1% ` Alan Cox
1996-05-17 4:01 1% ` David S. Miller
0 siblings, 2 replies; 200+ results
From: Larry McVoy @ 1996-05-16 16:03 UTC (permalink / raw)
To: David S. Miller; +Cc: lmlinux, torvalds, sparclinux-cvs, alan
: *Local* Communication bandwidths in megabytes/second
: ----------------------------------------------------
: Host OS Pipe TCP File Mmap Bcopy Bcopy Mem Mem
: reread reread (libc) (hand) read write
: --------- ------------- ---- ---- ------ ------ ------ ------ ---- -----
: trombetas Linux 1.99.3 8 4.8 25.0 17.4 18 24 41 36
: geneva.ru SunOS 5.5 8 7.0 12.6 19.5 18 18 40 36
: negro.rut SunOS 4.1.3_U 4 2.0 19.5 8.2 18 24 41 36
THis is sorta weird - why is it that mmap reread is slower than file reread?
Do you have a kernel bcopy that is faster than memory read?
I think your 4.8MB/sec number is pretty studly. That means you are
checksumming 9MB/sec as well as the protocol stack on a system that
bcopies at ~20MB/sec. You're already better than 2x the SunOS code.
Call it a day, you won.
^ permalink raw reply [relevance 1%]
* Re: lmbench with new checksum code...
1996-05-16 16:03 1% lmbench with new checksum code Larry McVoy
@ 1996-05-16 17:32 1% ` Alan Cox
1996-05-17 4:01 1% ` David S. Miller
1 sibling, 0 replies; 200+ results
From: Alan Cox @ 1996-05-16 17:32 UTC (permalink / raw)
To: Larry McVoy; +Cc: davem, lmlinux, torvalds, sparclinux-cvs, alan
> I think your 4.8MB/sec number is pretty studly. That means you are
> checksumming 9MB/sec as well as the protocol stack on a system that
Actually the Linux kernel cheats on the receive side of loopback and doesnt
checksum. Its too expensive to fiddle around on the send side for that short
of doing the whole job and shorting the tcp layer as Solaris seems to.
> bcopies at ~20MB/sec. You're already better than 2x the SunOS code.
> Call it a day, you won.
Na.. We can cut all the checksums, do raw copies with no protocol overhead
and possibly later on do user->user copying (with page flips to keep larry
happy ;)). I can't see any reason we cannot do about 8-9MB/sec with a bit
of extra code and some sneaky tricks.
CONFIG_TCP_BENCHMARK_TRICKS
anyone ?
^ permalink raw reply [relevance 1%]
* Re: lmbench with new checksum code...
@ 1996-05-16 19:03 1% Neal Nuckolls
0 siblings, 0 replies; 200+ results
From: Neal Nuckolls @ 1996-05-16 19:03 UTC (permalink / raw)
To: Alan Cox; +Cc: sparclinux-cvs, torvalds, lmlinux
Alan is right, the Solaris tcp/ip implementation has a special case
for loopback which skims just the top of the IP module, no checksum,
no copy at that level, large mtu.
neal
^ permalink raw reply [relevance 1%]
* Re: lmbench with new checksum code...
@ 1996-05-16 17:32 1% ` Alan Cox
0 siblings, 0 replies; 200+ results
From: Alan Cox @ 1996-05-16 17:32 UTC (permalink / raw)
To: Larry McVoy; +Cc: davem, lmlinux, torvalds, sparclinux-cvs, alan
> I think your 4.8MB/sec number is pretty studly. That means you are
> checksumming 9MB/sec as well as the protocol stack on a system that
Actually the Linux kernel cheats on the receive side of loopback and doesnt
checksum. Its too expensive to fiddle around on the send side for that short
of doing the whole job and shorting the tcp layer as Solaris seems to.
> bcopies at ~20MB/sec. You're already better than 2x the SunOS code.
> Call it a day, you won.
Na.. We can cut all the checksums, do raw copies with no protocol overhead
and possibly later on do user->user copying (with page flips to keep larry
happy ;)). I can't see any reason we cannot do about 8-9MB/sec with a bit
of extra code and some sneaky tricks.
CONFIG_TCP_BENCHMARK_TRICKS
anyone ?
^ permalink raw reply [relevance 1%]
* Re: mpp kernel interface
1996-05-16 14:20 1% ` Andrew Tridgell
@ 1996-05-16 17:19 1% ` Alan Cox
0 siblings, 0 replies; 200+ results
From: Alan Cox @ 1996-05-16 17:19 UTC (permalink / raw)
To: Andrew.Tridgell; +Cc: lm, linux-mc, Linus.Torvalds, linux, alan
> We use sockets to implement the stdin/stdout/stderr of parallel
> processes. The paralleld that launches parallel programs on each cell
> first creates 3 sockets back to the launching program, setting them up
> as file desciptors 0, 1 and 2. When it then does a fork()/exec() the
> parallel program inherits them.
Two things strike me here. Firstly if you are doing that kind of output
redirection across 192 cells you are going to need 192 logical connections
however you do it. Secondly you really want your node end library to be
a bit smarter and pass a tty check across the link so you can use tty/pty
pairs if the real descriptor is a tty.
> parallel programs. If we had a remote fork() and/or remote exec()
> and also had a way for the file descriptors of remote forked processes
> to feed back into the parent cpu then it would be much better.
MOSIX does this by trapping them at the VFS layer. Effectively each inode
and file handle has a host field and if the operation is remote you RPC.
> We'd probably also need to use a tree structure to feed the file
> descriptors (and paging for that matter) back up into the parent
> process. 1000 children all writing to one parent would not be pretty.
It would be an interesting application of multicast groups to allow the parent
to roam as well. With 1000 children thats an even bigger scaling problem, and
for sending stuff to a large number of nodes (eg a loosely synchronized SIMD
job) its going to be needed.
> The problem is really latency. Ethernet type systems have latencies
> which aren't much lower than the system clock tick interval. This
> means it often makes sense to do things is quite different ways to
> what we have to do.
Yes. The latency also means that attacking from two other angles is interesting
Firstly 10Mbit ethernet - latency is no worse really just we have to be more
reluctant to bulk copy data, and also combining it with something like the
TTL PAPERS device for the fast sync stuff (its a $60 to build parallel port
synchronization system with about a 3uS overhead). Very limited but might
solve some of our problems on ethernet linked boxes.
Alan
^ permalink raw reply [relevance 1%]
* Re: lmbench with new checksum code...
1996-05-16 16:03 1% lmbench with new checksum code Larry McVoy
1996-05-16 17:32 1% ` Alan Cox
@ 1996-05-17 4:01 1% ` David S. Miller
1 sibling, 0 replies; 200+ results
From: David S. Miller @ 1996-05-17 4:01 UTC (permalink / raw)
To: lm; +Cc: lmlinux, torvalds, sparclinux-cvs, alan
From: lm@gate1-neteng.engr.sgi.com (Larry McVoy)
Date: Thu, 16 May 1996 09:03:36 -0700
I think your 4.8MB/sec number is pretty studly. That means you are
checksumming 9MB/sec as well as the protocol stack on a system that
bcopies at ~20MB/sec. You're already better than 2x the SunOS code.
Call it a day, you won.
I did not win, this is unacceptable. I am completely convinced based
upon the edge I have over Solaris for context switching and general
process/trap operations I should be able to match it even with
everything going through real networking.
Linux + full networking overhead == Solaris memcpy/cow-page overhead
I cannot accept this piss poor performance I'm getting, it must be
made faster.
(Yes, I'm rediculious, Larry will tell you others how I feel that if
I am presented with a "next generation" cpu and I cannot get from
trap entry to kernel c-code in 12 completely pipelined non-stalling
instructions then some hardware engineer has completely wasted his
precious time ;-)
Later,
David S. Miller
davem@caip.rutgers.edu
^ permalink raw reply [relevance 1%]
* idea for csum_partial_copy on Viking/MXCC
@ 1996-05-19 5:45 1% David S. Miller
0 siblings, 0 replies; 200+ results
From: David S. Miller @ 1996-05-19 5:45 UTC (permalink / raw)
To: ecd; +Cc: lmlinux, sparclinux-cvs, alan, torvalds
(Note: This is just another one of my crazy ideas, consider this
something to do possibly in the future when someone has tons of
copious free time. For now I'm going to get the software version
working as fast as it can.)
(Some background for some of you, Viking/MXCC Sparc has a hardware
block copy facility which can copy cache sub-block aligned chunks of
ram very quickly.)
This is silly, but it would get disgustingly fast numbers. (btw,
eddie, still waiting for the memcpy.s of yours so that I can do some
testing tonight...)
You use the MXCC stream copy stuff if you have a buffer bigger than
256 bytes and you can align it to 32 bytes. The unrolled loops right
now look like:
ldd [%src + offset + 0x18], %t0; ! multi-cycle cache stall
ldd [%src + offset + 0x10], %t2; ! 1 cycle, cache hit
ldd [%src + offset + 0x08], %t4; ! 1 cycle, cache hit
st %t0, [%dest + offset + 0x18]; ! multi-cycle cache stall
addxcc %t0, %accum, %accum; ! 1 cycle, does not pair
st %t1, [%dest + offset + 0x1c];
addxcc %t1, %accum, %accum; ! 1 cycle, cache hit
st %t2, [%dest + offset + 0x10];
addxcc %t2, %accum, %accum; ! 1 cycle, cache hit
ldd [%src + offset + 0x00], %t0; ! 1 cycle, cache hit
st %t3, [%dest + offset + 0x14]; ! 1 cycle, cache hit, cannot pair
addxcc %t3, %accum, %accum;
st %t4, [%dest + offset + 0x08]; ! 1 cycle, cache hit
addxcc %t4, %accum, %accum;
st %t5, [%dest + offset + 0x0c]; ! 1 cycle, cache hit
addxcc %t5, %accum, %accum;
st %t0, [%dest + offset + 0x00]; ! 1 cycle, cache hit
addxcc %t0, %accum, %accum;
st %t1, [%dest + offset + 0x04]; ! 1 cycle, cache hit
addxcc %t1, %accum, %accum;
! around 19 clock cycles
Bite me, those stores make this stuff impossible to schedule without
grabbing a register window which I refuse to do.
Ok, on the MXCC you eat some cycles so that you have the registers
setup for the source (for the checksum calculations) and the page
numbers etc. for the stream operation for the entire chunk being
csum/copied. Then it looks like this:
st %stream_addr1, [%stream_addr2] ASI_MXCC
/* Processor stalls 3 or 4 clocks to get stream operation going. */
ldd [%src + offset + 0x18], %t0; ! cache hit
addxcc %t0, %accum, %accum; ! 1 cycle, does pair
addxcc %t1, %accum, %accum; ! 1 cycle, no pair
ldd [%src + offset + 0x10], %t2; ! cache hit
addxcc %t2, %accum, %accum; ! 1 cycle, does pair
addxcc %t3, %accum, %accum; ! 1 cycle, no pair
ldd [%src + offset + 0x08], %t4; ! cache hit
addxcc %t4, %accum, %accum; ! 1 cycle, cache hit
addxcc %t5, %accum, %accum; ! 1 cycle, no pair
ldd [%src + offset + 0x00], %t0; ! 1 cycle
addxcc %t0, %accum, %accum; ! 1 cycle, cache hit
addxcc %t1, %accum, %accum; ! 1 cycle, no pair
! around 12 clock cycles
MXCC does all those ugly and hard to schedule stores for us ;-) Note
that I could probably schedule that new sequence even better.
Saving of 7 clock cycles for _every_ 32 byte aligned block we csum,
the overhead of setting up for the stream operation is fuzzed away by
the fact that we usually run this thing many times in a row (thus the
"only do optimization if len >= 256" rule above).
Let's assume in such an implementation that we eat around 13 or 14
cycles getting the registers ready for the stream operation. Fine,
then after two straight iterations of the above code sequence we are
breaking even, we commonly run it many times in a row.
Common case for full ethernet frame is that we do 128 bytes at a shot,
11 times. This works out to:
(7 clocks saved per iteration * (128 / 32) * 11) -
(14 stream-op setup cycles * 11 iterations)
== 308 saved cycles - 154 lost cycles
== 154 clocks less per csum on ethernet sized packet frame
Old code == 846 total cycles for ethernet sized packet frame
New code == 692 "" ""
We go ~20% faster ;-) A possible issue is overhead of function
ptr dereference for the call, but based upon the performance of our
dynamic mmu code I doubt it would matter and it would give gcc some
dead cycles to fill in the networking code anyways.
As noted previously, this would be a "research" venture to see what
kind of numbers it would really get. Now that I think about it I
would be very leery about putting this into the tree so that we don't
hit the sun4d XBUS IOCACHE hardware bug (it is only triggered by MXCC
hardware block copy operations and certain types of dma activity with
a certain set of bit patterns in the data, nasty bug).
For now I'm re-scheduling the software csum/copy code to work as it
should (I was hitting the cache in the wrong way I've found from
Andy's numbers, fixing this right now).
Later,
David S. Miller
davem@caip.rutgers.edu
^ permalink raw reply [relevance 1%]
* Meeting wednesday
@ 1996-05-21 0:16 1% Ariel Faigon
1996-05-21 5:42 1% ` William J. Earl
0 siblings, 1 reply; 200+ results
From: Ariel Faigon @ 1996-05-21 0:16 UTC (permalink / raw)
To: linux
Hi Linuxies
As you may know, David Miller's arival is really close now.
Larry says this Friday...
We reserved Matisse in 9U, for this Wednesday for a one
hour meeting.
The goal is to try and see what we have ready for David
and see how can we improve our preparedness in the last
days that remain.
David: do you have names for the two hosts by now?
Bill: do you have 200MHz CPUs?
I understand we were short on our promises to pre-prepare
stuff since people were really busy, any good news would be nice.
--
Peace, Ariel
^ permalink raw reply [relevance 1%]
* Re: Meeting wednesday
1996-05-21 0:16 1% Meeting wednesday Ariel Faigon
@ 1996-05-21 5:42 1% ` William J. Earl
0 siblings, 0 replies; 200+ results
From: William J. Earl @ 1996-05-21 5:42 UTC (permalink / raw)
To: ariel; +Cc: linux
Ariel Faigon writes:
...
> Bill: do you have 200MHz CPUs?
...
I don't have the two modules I ordered, because we have a
large backlog. I will probably supply something reasonable
for the host machine and a 150 MHZ R5000 to put on the
target machine, until the modules I ordered show up.
^ permalink raw reply [relevance 1%]
* some projections...
@ 1996-05-21 6:25 1% David S. Miller
1996-05-21 6:49 1% ` William J. Earl
0 siblings, 1 reply; 200+ results
From: David S. Miller @ 1996-05-21 6:25 UTC (permalink / raw)
To: linux
Iris SCSI driver: Mildly amusing, once I get the dma stuff straight
should be a 3 or 4 day affair to get going in an
initial working state.
Iris Ethernet driver: Cake walk, 3 nights tops.
It seems the HPC drives both of these devices in a similar manner, it
also seems that it has little state machines which do things like
retransmit collision packets on the SEEQ and various SCSI sequences as
well. I need to get it straight in my head where the software driver
actually comes into play. I like the HPC dma architecture btw.
Console driver: I assume the keyboard/mouse is driven off the Zilog
uarts, if so this should be relatively simple as I can
adapt most of the code from my Sparc stuff and how I
layed that code out. As for the screen I just need
to figure out where the frame buffer lives and how to
play with the palette registers and I'm set. Also
should be cakewalk to do serial console as well. This
might be a 4 or 5 day job depending upon how things
go initially.
So in less than two weeks I could have drivers for all the major
devices going already.
A large section of my work will be carefully going over the existing
code the linux-mips people have and putting together the initial
foundation so that I can at least start compiling kernels, then things
can run smoothly.
Yawn, stretch, more to come...
Later,
David S. Miller
davem@caip.rutgers.edu
^ permalink raw reply [relevance 1%]
* Re: some projections...
1996-05-21 6:25 1% some projections David S. Miller
@ 1996-05-21 6:49 1% ` William J. Earl
1996-05-21 6:52 1% ` David S. Miller
0 siblings, 1 reply; 200+ results
From: William J. Earl @ 1996-05-21 6:49 UTC (permalink / raw)
To: David S. Miller; +Cc: linux
David S. Miller writes:
...
> Console driver: I assume the keyboard/mouse is driven off the Zilog
> uarts, if so this should be relatively simple as I can
> adapt most of the code from my Sparc stuff and how I
> layed that code out. As for the screen I just need
> to figure out where the frame buffer lives and how to
> play with the palette registers and I'm set. Also
> should be cakewalk to do serial console as well. This
> might be a 4 or 5 day job depending upon how things
> go initially.
...
The keyboard and mouse, on the Indy and Indigo2, are driven by
a PS2-style keyboard and mouse controller. Aside from the different
way of addressing the registers, the driver should pretty much be the
same as the Linux PS2 keyboard and mouse controller.
The frame buffer is not directly addressable. Most operations
are performed via commands written to the pixel pipeline, although
one can DMA pixels from main memory to the frame buffer. I will
arrange for you to talk with the people who do IRIX X and GL
for Newport.
It will probably be a good idea to boot up on a serial console
first, since the graphics interface is a bit more complex than a dumb
frame buffer. That is how we usually port IRIX to a new system.
Since there are two serial ports, one can run the console on the first
port and the remote debugger on the second port, with very little
working beside the serial driver and bsaic exception handling
(assuming you start by booting using bootp() and the standard PROM).
^ permalink raw reply [relevance 1%]
* Re: some projections...
1996-05-21 6:49 1% ` William J. Earl
@ 1996-05-21 6:52 1% ` David S. Miller
0 siblings, 0 replies; 200+ results
From: David S. Miller @ 1996-05-21 6:52 UTC (permalink / raw)
To: wje; +Cc: linux
Date: Mon, 20 May 1996 23:49:51 -0700
From: wje@fir.esd.sgi.com (William J. Earl)
The keyboard and mouse, on the Indy and Indigo2, are driven by
a PS2-style keyboard and mouse controller.
Good, thanks.
It will probably be a good idea to boot up on a serial console
first, since the graphics interface is a bit more complex than a dumb
frame buffer. That is how we usually port IRIX to a new system.
Good idea, this will be the direction I go in then. Although, I can't
wait to have Linux virtual consoles available on an SGI workstation ;-)
Later,
David S. Miller
davem@caip.rutgers.edu
^ permalink raw reply [relevance 1%]
* linux needs bsd networking stack
@ 1996-05-29 21:59 1% Neal Nuckolls
1996-05-29 22:50 1% ` David S. Miller
` (2 more replies)
0 siblings, 3 replies; 200+ results
From: Neal Nuckolls @ 1996-05-29 21:59 UTC (permalink / raw)
To: torvalds, alan; +Cc: sparclinux-cvs, lmlinux
Silicon Valley is bubbling with networking startups.
Many of these new small companies are designing products
based on PC motherboards and doing some sw and/or hw
customization to turn them into networking switches,
routers, firewalls, etc. Rather than embedding a RTOS,
they are choosing a free unix and usually this is FreeBSD
since Linux networking is not the de facto BSD stack.
The "unique" tcp/ip implementation is a liability to linux.
Is anyone working to replace the standard linux stack
with port derived from the 4.4BSD code?
thanks.
neal nuckolls
nn@engr.sgi.com
^ permalink raw reply [relevance 1%]
* Re: linux needs bsd networking stack
1996-05-29 21:59 1% linux needs bsd networking stack Neal Nuckolls
@ 1996-05-29 22:50 1% ` David S. Miller
1996-05-30 9:46 1% ` Alan Cox
1996-05-30 5:21 1% ` Linus Torvalds
1996-05-30 9:43 1% ` Alan Cox
2 siblings, 1 reply; 200+ results
From: David S. Miller @ 1996-05-29 22:50 UTC (permalink / raw)
To: nn; +Cc: torvalds, alan, sparclinux-cvs, lmlinux
Date: Wed, 29 May 1996 14:59:58 -0700
From: nn@lanta (Neal Nuckolls)
The "unique" tcp/ip implementation is a liability to linux.
It could also be one of it's greatest assets, and I think this will
turn out to be the case.
Is anyone working to replace the standard linux stack
with port derived from the 4.4BSD code?
I will for now only briefly mention why I think this is not very
desirable.
A couple of weeks ago, Larry was babbling to me "oh the stack is
sloowww, I can't push nearly as much over 100mb/s ether as freebsd
can, etc." I said, "thats peculiar" so I did some investigation and
told Linus about it. Turned out to be a driver bug and after that was
fixed the over the wire numbers are unparalleled.
The Berkeley stack is dead, but it has one redeeming quality which
Linux's stack does desperately need.
It has a well defined architecture, I will agree with lm when he
mentions that it is a jungle of code to sift through in certain
respects. It need a mallet to smooth certain aspects and interfaces
out.
In the end I think it is best to work on hacking the existing (and
upcoming) Linux networking code to have these qualities instead of
stuffing the bsd stack into linux (this has been done before a long
long time ago btw, before linux had any networking, a man by the name
of Charles Hedrick back at Rutgers did it in a few nights).
I think the feeling that the linux stack is "hard to follow" or "has
very little architecture" has a lot to do with the fact that we don't
have 20 books analyzing the code c-statement by c-statement like the
bsd stuff does. If we had that, I think this desire to use the
berkeley stack would not be as strong.
I dislike the berkeley stack, but I am biased in my opinion. I am
biased because of the attitude expressed by the people actively
working on that code set in the free software world these days, I am
also biased because I tend to hack Linux almost exlusively. But, even
barring that I believe that some of the elements of the bsd stack will
end up being completely flawed when plugged into linux, obvious things
like mbufs and other things come to mind right now. It would require
a bit of engineering and greatly upset a large community who has put
their entire heart and soul into the Linux networking code. I believe
at the very least that the Linux networking stack is superior
performance wise without any question, and as everyone knows I have
numbers to prove it ;-)
Later,
David S. Miller
dm@sgi.com
^ permalink raw reply [relevance 1%]
* Re: linux needs bsd networking stack
@ 1996-05-29 23:04 1% Larry McVoy
1996-05-30 10:06 1% ` Alan Cox
0 siblings, 1 reply; 200+ results
From: Larry McVoy @ 1996-05-29 23:04 UTC (permalink / raw)
To: dm; +Cc: nn, torvalds, alan, sparclinux-cvs, lmlinux
: The "unique" tcp/ip implementation is a liability to linux.
:
: It could also be one of it's greatest assets, and I think this will
: turn out to be the case.
:
: Is anyone working to replace the standard linux stack
: with port derived from the 4.4BSD code?
:
: A couple of weeks ago, Larry was babbling to me "oh the stack is
: sloowww, I can't push nearly as much over 100mb/s ether as freebsd
: can, etc." I said, "thats peculiar" so I did some investigation and
: told Linus about it. Turned out to be a driver bug and after that was
: fixed the over the wire numbers are unparalleled.
That's not quite true, I think the BSD numbers are still better, I'll
have full lmbench apples to apples runs on the same hardware at the
end of this week.
: It [bsd] has a well defined architecture, I will agree with lm when he
: mentions that it is a jungle of code to sift through in certain
: respects.
This is one of my complaints. The BSD stack has a defined set of "objects"
for dealing with networking; an incomplete list:
protocol structure for different address families
interface structure for different media types
socket structure that cleanly handles different protocols
Another big plus of the BSD stack is tcp_input.c and tcp_output.c. These
are what most people mean when they say "BSD networking".
Downsides of BSD:
. I don't particlularly like mbufs; I agree with Linus & Alan that
they are overkill.
. There are layering "invariants" that affect performance: you really
should allocate your send buffers from the interface driver, because
it could do some interesting things that would minimize cache flushing.
I think Van's prototype did this for witless cards.
. Single processor design. This is the biggest drawback, IMO.
Proposal/suggestion:
. Come up with a strawman proposal for the set of "objects" we think
we need in Linux. Do this as part of the work Linus suggested to
merge the socket ops with the vfs ops.
. Steal the TCP code outright. Nuke the mbuf stuff, use the skbufs
or a slightly modified version thereof.
. Design in SMP support from the start. This means thinking about
thousands of connections running in parallel.
: I think the feeling that the linux stack is "hard to follow" or "has
: very little architecture" has a lot to do with the fact that we don't
: have 20 books analyzing the code c-statement by c-statement like the
: bsd stuff does. If we had that, I think this desire to use the
: berkeley stack would not be as strong.
Yeah, but a very reasonable point is "we don't have that". BSD does.
This is a big deal. Documentation is useful.
^ permalink raw reply [relevance 1%]
* Re: linux needs bsd networking stack
@ 1996-05-30 0:36 1% Neal Nuckolls
1996-05-30 3:02 1% ` David S. Miller
1996-05-30 10:12 1% ` Alan Cox
0 siblings, 2 replies; 200+ results
From: Neal Nuckolls @ 1996-05-30 0:36 UTC (permalink / raw)
To: dm; +Cc: lmlinux, sparclinux-cvs, alan, torvalds
>> The "unique" tcp/ip implementation is a liability to linux.
>
> It could also be one of it's greatest assets, and I think this will
> turn out to be the case.
Whether the linux kernel networking implementation is better or
worse than the BSD code isn't my point. The fact that it's not
clearly superior, only very different, from the standard is.
Most unix and internet R&D community protocol development has
been and continues to be within a BSD environment which means that
BSD-based kernel networking code is prevalent. If I'm doing some
work in this area I can readily grab many free BSD-based protocol
pieceparts off the net. New routing protocols, ATM signalling, TCP
conjestion improvements, realtime protocol stacks, etc. are all
developed in a BSD kernel networking environment. Have been for
years. That's not likely to change. There are hundreds of people
out there that really know BSD networking. This availability of
people and code makes it the standard.
Actually, for the startups that I mentioned - those interested in
shipping a commercial product - there is no choice, it's FreeBSD,
because it comes without the GPL kiss of death.
> In the end I think it is best to work on hacking the existing (and
> upcoming) Linux networking code to have these qualities instead of
> stuffing the bsd stack into linux
I think that basing any improvements on a 4.4BSD-based linux stack
would result in something more usable. Also, as a side effect, it
would encourage more talented networking people to participate and
isn't this what freeware is all about?
neal
^ permalink raw reply [relevance 1%]
* Re: linux needs bsd networking stack
1996-05-30 0:36 1% Neal Nuckolls
@ 1996-05-30 3:02 1% ` David S. Miller
1996-05-30 10:12 1% ` Alan Cox
1 sibling, 0 replies; 200+ results
From: David S. Miller @ 1996-05-30 3:02 UTC (permalink / raw)
To: nn; +Cc: lmlinux, sparclinux-cvs, alan, torvalds
Date: Wed, 29 May 1996 17:36:19 -0700
From: nn@lanta (Neal Nuckolls)
>> The "unique" tcp/ip implementation is a liability to linux.
>
> It could also be one of it's greatest assets, and I think this will
> turn out to be the case.
Most unix and internet R&D community protocol development has
been and continues to be within a BSD environment which means that
BSD-based kernel networking code is prevalent. If I'm doing some
work in this area I can readily grab many free BSD-based protocol
pieceparts off the net. New routing protocols, ATM signalling, TCP
conjestion improvements, realtime protocol stacks, etc. are all
developed in a BSD kernel networking environment. Have been for
years. That's not likely to change. There are hundreds of people
out there that really know BSD networking. This availability of
people and code makes it the standard.
Actually, whats funny is that this is exactly what the people doing
work on the linux stack have in fact done. Check out the ideas people
have put into various berkeley based ventures and research, place our
own implementation of the idea into the linux stack, and then improve
upon it. The idea behind publicly available standards (at least I
believe) was to promote no single entity to have this "defacto" thing
which controlled the protocol or what have you, the berkeley
phenomenon is not encouraging this idea and is in fact against it.
Here the berkeley interpretation and implementation is being
considered "the" interpretation and "the" implementation. The Linux
code in general moves at an advanced rate, it is constantly evolving
and changing for the purposes of improvement. One could argue that
this is what makes it so hard to pin down and become very acquainted
with it and not just the fact that it's objects and interfaces are not
as well defined (as lm mentions, of which I whole heartedly agree, I
would some day like to see the Linux networking be as intuitive and
seamless as the vm/mm Linux layers, Linus has mentioned moves in this
direction via fully integrating the socks more completely into the
inode among other things).
Actually, for the startups that I mentioned - those interested in
shipping a commercial product - there is no choice, it's FreeBSD,
because it comes without the GPL kiss of death.
I wish it wouldn't come down to a discussion about "what license is
better for who and why", I'd rather this be about technical merit.
But, I am beginning to realize that this may not be possible. I want
Linux to strive and always be on the bleeding edge, as it has been,
personally I believe that the "GPL kiss of death" is what makes that
possible and will guarentee that this capability cannot be taken
away.
I think that basing any improvements on a 4.4BSD-based linux stack
would result in something more usable. Also, as a side effect, it
would encourage more talented networking people to participate and
isn't this what freeware is all about?
You are correct, this is what "free software" (there is a distinction)
is all about. However what it is not about, and what could kill free
software is if the "BSD kiss of death" allowed someone to make
significant improvements to the Linux code and due to the berkeley
license allowed that entity to keep those improvements to themselves
so that the free software community loses out. This is precisely what
the GPL tries to avoid... Very frequently, Linus himself mentions
that the GPL is what has made Linux as powerful as it now is, and he
also frequently mentions that GPL'ing the Linux code is the best
decision he has ever made. I tend to agree with him.
But like I said, I'd rather such a decision be made based upon a
technical decision not a "who has the viable licensing terms"
decision.
It was mentioned that you are more familiar with the berkeley code and
many people are. I am more familiar with the Linux code and the
work/research which has gone into it, do I have an argument as well?
I would not present it this way or drive an argument in that fashion I
think. There exists a significant group of people who are in my
position and as well there are many in the position you speak of.
However, I have been making a significant effort over the past year or
so to become familiar with the berkeley code so that I possess the
ability to tackle decisions like this based on technical merit, and
not turn it into a GPL vs. BSD discussion. Are people supportive of
the berkeley side of this argument willing to do the same? I know a
few such as lm etc., I would not say they exist within the majority
though.
Later,
David S. Miller
dm@sgi.com
^ permalink raw reply [relevance 1%]
* Re: linux needs bsd networking stack
1996-05-29 21:59 1% linux needs bsd networking stack Neal Nuckolls
1996-05-29 22:50 1% ` David S. Miller
@ 1996-05-30 5:21 1% ` Linus Torvalds
1996-05-30 9:43 1% ` Alan Cox
2 siblings, 0 replies; 200+ results
From: Linus Torvalds @ 1996-05-30 5:21 UTC (permalink / raw)
To: Neal Nuckolls; +Cc: alan, sparclinux-cvs, lmlinux
On Wed, 29 May 1996, Neal Nuckolls wrote:
>
> Silicon Valley is bubbling with networking startups.
> Many of these new small companies are designing products
> based on PC motherboards and doing some sw and/or hw
> customization to turn them into networking switches,
> routers, firewalls, etc. Rather than embedding a RTOS,
> they are choosing a free unix and usually this is FreeBSD
> since Linux networking is not the de facto BSD stack.
> The "unique" tcp/ip implementation is a liability to linux.
> Is anyone working to replace the standard linux stack
> with port derived from the 4.4BSD code?
Simple answer: it won't happen.
The _only_ advantage of the BSD stack is the de-facto standard thing, and
quite frankly that one doesn't make much of a difference - Linux _will_
be the facto standard in one or two more years if everything goes right.
Trying to port the BSD stack would be a major mistake, imho.
I used to think the BSD stack was an option that we might want to take some
day, but I don't think so any more. My main concerns were performance and
compatibility, and we've got them both. The problems we still have in
networking are not worth worrying about in this context - we'd have a lot
more problems if we tried to switch and they wouldn't be any easier to solve.
Note that this doesn't mean we shouldn't look at parts of the BSD stack
for interesting things (and the BSD stack has obviously been there as a
reference). But a whole-sale BSD stack port is not going to happen.
Linus
^ permalink raw reply [relevance 1%]
* Re: linux needs bsd networking stack
1996-05-29 21:59 1% linux needs bsd networking stack Neal Nuckolls
@ 1996-05-30 9:43 1% ` Alan Cox
1996-05-30 5:21 1% ` Linus Torvalds
1996-05-30 9:43 1% ` Alan Cox
2 siblings, 0 replies; 200+ results
From: Alan Cox @ 1996-05-30 9:43 UTC (permalink / raw)
To: Neal Nuckolls; +Cc: torvalds, alan, sparclinux-cvs, lmlinux
> customization to turn them into networking switches,
> routers, firewalls, etc. Rather than embedding a RTOS,
> they are choosing a free unix and usually this is FreeBSD
> since Linux networking is not the de facto BSD stack.
So we should use a defacto BSD stack because its a defacto stack. Ok there is this
great OS called windows3. See you later
> The "unique" tcp/ip implementation is a liability to linux.
I'm not convinced it is. A whole load of SGI people (LM notably) seem intent on "BSD
stack, BSD stack, BSD stack". Everyone else I hear is saying "How fast can it go",
"How stable can we make it", "Will you please make sure its as solid in 2.0 as in 1.2"
> Is anyone working to replace the standard linux stack
> with port derived from the 4.4BSD code?
No -
o The BSD stack doesnt do IPX, AX25, NetROM, Appletalk
o There will be no defacto IPv6 for BSD, there are several species
o The licensing doesnt permit the two to meet easily
o You can't do 400Mbits/second with mbufs so you'd have to break the BSD code
anyway
Im not convinced about the rest of the argument either. I know one big vendor using
the BSD stack for a project. I know several using Linux (Things like the firewall
from Mazama). We are seeing primary rate ISDN support for Linux starting to appear,
and already have the heavy provider end multiple serial cards.
For routers, anyone using a PC style architecture is bounding themselves to small
routers anyway. No matter how good the code is you will soon need fancy hardware to
handle BGP4, 50,000 routes and fast 100baseT speed switching. And there is no
defacto BSD IPv6
Alan
^ permalink raw reply [relevance 1%]
* Re: linux needs bsd networking stack
1996-05-29 22:50 1% ` David S. Miller
@ 1996-05-30 9:46 1% ` Alan Cox
0 siblings, 0 replies; 200+ results
From: Alan Cox @ 1996-05-30 9:46 UTC (permalink / raw)
To: David S. Miller; +Cc: nn, torvalds, alan, sparclinux-cvs, lmlinux
> It has a well defined architecture, I will agree with lm when he
> mentions that it is a jungle of code to sift through in certain
> respects. It need a mallet to smooth certain aspects and interfaces
> out.
I hope to be working full time on this eventually (like when people are paying me
for it). I've also started documentation at the driver and skbuff level and will
work over it bit by bit - see forthcoming Linux Journal articles then going into the
KHG.
> their entire heart and soul into the Linux networking code. I believe
> at the very least that the Linux networking stack is superior
> performance wise without any question, and as everyone knows I have
> numbers to prove it ;-)
Before you admire the performance numbers get the pre2.1 code off Pedro Roque. Now he
has added really neat header prediction code it kicks pre2.0's butt even though its
doing a surplus memory alloc we need to tidy up
Alan
^ permalink raw reply [relevance 1%]
* Re: linux needs bsd networking stack
@ 1996-05-30 9:43 1% ` Alan Cox
0 siblings, 0 replies; 200+ results
From: Alan Cox @ 1996-05-30 9:43 UTC (permalink / raw)
To: Neal Nuckolls; +Cc: torvalds, alan, sparclinux-cvs, lmlinux
> customization to turn them into networking switches,
> routers, firewalls, etc. Rather than embedding a RTOS,
> they are choosing a free unix and usually this is FreeBSD
> since Linux networking is not the de facto BSD stack.
So we should use a defacto BSD stack because its a defacto stack. Ok there is this
great OS called windows3. See you later
> The "unique" tcp/ip implementation is a liability to linux.
I'm not convinced it is. A whole load of SGI people (LM notably) seem intent on "BSD
stack, BSD stack, BSD stack". Everyone else I hear is saying "How fast can it go",
"How stable can we make it", "Will you please make sure its as solid in 2.0 as in 1.2"
> Is anyone working to replace the standard linux stack
> with port derived from the 4.4BSD code?
No -
o The BSD stack doesnt do IPX, AX25, NetROM, Appletalk
o There will be no defacto IPv6 for BSD, there are several species
o The licensing doesnt permit the two to meet easily
o You can't do 400Mbits/second with mbufs so you'd have to break the BSD code
anyway
Im not convinced about the rest of the argument either. I know one big vendor using
the BSD stack for a project. I know several using Linux (Things like the firewall
from Mazama). We are seeing primary rate ISDN support for Linux starting to appear,
and already have the heavy provider end multiple serial cards.
For routers, anyone using a PC style architecture is bounding themselves to small
routers anyway. No matter how good the code is you will soon need fancy hardware to
handle BGP4, 50,000 routes and fast 100baseT speed switching. And there is no
defacto BSD IPv6
Alan
^ permalink raw reply [relevance 1%]
* Re: linux needs bsd networking stack
@ 1996-05-30 9:46 1% ` Alan Cox
0 siblings, 0 replies; 200+ results
From: Alan Cox @ 1996-05-30 9:46 UTC (permalink / raw)
To: David S. Miller; +Cc: nn, torvalds, alan, sparclinux-cvs, lmlinux
> It has a well defined architecture, I will agree with lm when he
> mentions that it is a jungle of code to sift through in certain
> respects. It need a mallet to smooth certain aspects and interfaces
> out.
I hope to be working full time on this eventually (like when people are paying me
for it). I've also started documentation at the driver and skbuff level and will
work over it bit by bit - see forthcoming Linux Journal articles then going into the
KHG.
> their entire heart and soul into the Linux networking code. I believe
> at the very least that the Linux networking stack is superior
> performance wise without any question, and as everyone knows I have
> numbers to prove it ;-)
Before you admire the performance numbers get the pre2.1 code off Pedro Roque. Now he
has added really neat header prediction code it kicks pre2.0's butt even though its
doing a surplus memory alloc we need to tidy up
Alan
^ permalink raw reply [relevance 1%]
* Re: linux needs bsd networking stack
1996-05-29 23:04 1% Larry McVoy
@ 1996-05-30 10:06 1% ` Alan Cox
0 siblings, 0 replies; 200+ results
From: Alan Cox @ 1996-05-30 10:06 UTC (permalink / raw)
To: Larry McVoy; +Cc: dm, nn, torvalds, alan, sparclinux-cvs, lmlinux
> This is one of my complaints. The BSD stack has a defined set of "objects"
> for dealing with networking; an incomplete list:
>
> protocol structure for different address families
We have these.
> interface structure for different media types
We have these
> socket structure that cleanly handles different protocols
We have most of this.
> Another big plus of the BSD stack is tcp_input.c and tcp_output.c. These
> are what most people mean when they say "BSD networking".
Yep. For 2.0 we have all the core stuff. For pre 2.1 we have stuff going beyond
what BSD is doing - Vegas flow control. If you want to work on stealing and working
stuff in talk with Pedro Roque, get pre 2.1 and take a good look.
> . There are layering "invariants" that affect performance: you really
> should allocate your send buffers from the interface driver, because
> it could do some interesting things that would minimize cache flushing.
> I think Van's prototype did this for witless cards.
We could certainly add the allocate via device at very little cost. We just start
using dev->kmalloc(). Note that you can't always win on this a packet may change
route.
> . Single processor design. This is the biggest drawback, IMO.
The Linux one is semi designed for MP work. A given socket can do its own locking,
and there are only a small number of areas of overlap at the moment. Notably
Demultiplex table needs locks
Multiple processor writes in parallel/reads in parallel on datagram requires about
10 lines of lock code.
We dont run the net_bh() in parallel although most of it we can do very easily.
> Proposal/suggestion:
> . Come up with a strawman proposal for the set of "objects" we think
> we need in Linux. Do this as part of the work Linus suggested to
> merge the socket ops with the vfs ops.
That certainly cant be counter-productive.
> . Steal the TCP code outright. Nuke the mbuf stuff, use the skbufs
> or a slightly modified version thereof.
We can't steal it outright. 4.4BSD has abominable problems as is. The FreeBSD people
have the worst of them fixed but don't have stuff like Vegas and have all the
horrible spoofing problems caused by bad timers.
> . Design in SMP support from the start. This means thinking about
> thousands of connections running in parallel.
So long as it still runs very fast for the 99.99% of people with a single CPU 486 PC.
Thats the primary target by market volume.
> : have 20 books analyzing the code c-statement by c-statement like the
> : bsd stuff does. If we had that, I think this desire to use the
> : berkeley stack would not be as strong.
> Yeah, but a very reasonable point is "we don't have that". BSD does.
> This is a big deal. Documentation is useful.
Its coming. In fact AW should now have released an English language version of the
1.2 kernel programming book.
Alan
^ permalink raw reply [relevance 1%]
* Re: linux needs bsd networking stack
1996-05-30 0:36 1% Neal Nuckolls
@ 1996-05-30 10:12 1% ` Alan Cox
1996-05-30 10:12 1% ` Alan Cox
1 sibling, 0 replies; 200+ results
From: Alan Cox @ 1996-05-30 10:12 UTC (permalink / raw)
To: Neal Nuckolls; +Cc: dm, lmlinux, sparclinux-cvs, alan, torvalds
> Whether the linux kernel networking implementation is better or
> worse than the BSD code isn't my point. The fact that it's not
> clearly superior, only very different, from the standard is.
Chuckle. The BSD stack doesn't even match the RFC's [ie THE STANDARD]
> work in this area I can readily grab many free BSD-based protocol
> pieceparts off the net. New routing protocols, ATM signalling, TCP
> conjestion improvements, realtime protocol stacks, etc. are all
Let me see: Routing protocols is userspace. ATM signalling we have (going in
2.1), Vegas we have in the pre 2.1 stuff. realtime - if you mean low latency
then take a look at unet.
> Actually, for the startups that I mentioned - those interested in
> shipping a commercial product - there is no choice, it's FreeBSD,
> because it comes without the GPL kiss of death.
So "We should change it for the startups" was message 1. "The startups wont
use it was message two". Do you have bullet holes in your shoes by any
chance ?
> I think that basing any improvements on a 4.4BSD-based linux stack
> would result in something more usable. Also, as a side effect, it
> would encourage more talented networking people to participate and
> isn't this what freeware is all about?
We can't use the 4.4BSD stack so that issue is moot. Free software is also about high
technical quality. If I wanted to get paid lots of money for hacking kernels I'd go
and work for mirkosoft
^ permalink raw reply [relevance 1%]
* Re: linux needs bsd networking stack
@ 1996-05-30 10:12 1% ` Alan Cox
0 siblings, 0 replies; 200+ results
From: Alan Cox @ 1996-05-30 10:12 UTC (permalink / raw)
To: Neal Nuckolls; +Cc: dm, lmlinux, sparclinux-cvs, alan, torvalds
> Whether the linux kernel networking implementation is better or
> worse than the BSD code isn't my point. The fact that it's not
> clearly superior, only very different, from the standard is.
Chuckle. The BSD stack doesn't even match the RFC's [ie THE STANDARD]
> work in this area I can readily grab many free BSD-based protocol
> pieceparts off the net. New routing protocols, ATM signalling, TCP
> conjestion improvements, realtime protocol stacks, etc. are all
Let me see: Routing protocols is userspace. ATM signalling we have (going in
2.1), Vegas we have in the pre 2.1 stuff. realtime - if you mean low latency
then take a look at unet.
> Actually, for the startups that I mentioned - those interested in
> shipping a commercial product - there is no choice, it's FreeBSD,
> because it comes without the GPL kiss of death.
So "We should change it for the startups" was message 1. "The startups wont
use it was message two". Do you have bullet holes in your shoes by any
chance ?
> I think that basing any improvements on a 4.4BSD-based linux stack
> would result in something more usable. Also, as a side effect, it
> would encourage more talented networking people to participate and
> isn't this what freeware is all about?
We can't use the 4.4BSD stack so that issue is moot. Free software is also about high
technical quality. If I wanted to get paid lots of money for hacking kernels I'd go
and work for mirkosoft
^ permalink raw reply [relevance 1%]
* Re: linux needs bsd networking stack
@ 1996-05-30 10:06 1% ` Alan Cox
0 siblings, 0 replies; 200+ results
From: Alan Cox @ 1996-05-30 10:06 UTC (permalink / raw)
To: Larry McVoy; +Cc: dm, nn, torvalds, alan, sparclinux-cvs, lmlinux
> This is one of my complaints. The BSD stack has a defined set of "objects"
> for dealing with networking; an incomplete list:
>
> protocol structure for different address families
We have these.
> interface structure for different media types
We have these
> socket structure that cleanly handles different protocols
We have most of this.
> Another big plus of the BSD stack is tcp_input.c and tcp_output.c. These
> are what most people mean when they say "BSD networking".
Yep. For 2.0 we have all the core stuff. For pre 2.1 we have stuff going beyond
what BSD is doing - Vegas flow control. If you want to work on stealing and working
stuff in talk with Pedro Roque, get pre 2.1 and take a good look.
> . There are layering "invariants" that affect performance: you really
> should allocate your send buffers from the interface driver, because
> it could do some interesting things that would minimize cache flushing.
> I think Van's prototype did this for witless cards.
We could certainly add the allocate via device at very little cost. We just start
using dev->kmalloc(). Note that you can't always win on this a packet may change
route.
> . Single processor design. This is the biggest drawback, IMO.
The Linux one is semi designed for MP work. A given socket can do its own locking,
and there are only a small number of areas of overlap at the moment. Notably
Demultiplex table needs locks
Multiple processor writes in parallel/reads in parallel on datagram requires about
10 lines of lock code.
We dont run the net_bh() in parallel although most of it we can do very easily.
> Proposal/suggestion:
> . Come up with a strawman proposal for the set of "objects" we think
> we need in Linux. Do this as part of the work Linus suggested to
> merge the socket ops with the vfs ops.
That certainly cant be counter-productive.
> . Steal the TCP code outright. Nuke the mbuf stuff, use the skbufs
> or a slightly modified version thereof.
We can't steal it outright. 4.4BSD has abominable problems as is. The FreeBSD people
have the worst of them fixed but don't have stuff like Vegas and have all the
horrible spoofing problems caused by bad timers.
> . Design in SMP support from the start. This means thinking about
> thousands of connections running in parallel.
So long as it still runs very fast for the 99.99% of people with a single CPU 486 PC.
Thats the primary target by market volume.
> : have 20 books analyzing the code c-statement by c-statement like the
> : bsd stuff does. If we had that, I think this desire to use the
> : berkeley stack would not be as strong.
> Yeah, but a very reasonable point is "we don't have that". BSD does.
> This is a big deal. Documentation is useful.
Its coming. In fact AW should now have released an English language version of the
1.2 kernel programming book.
Alan
^ permalink raw reply [relevance 1%]
* Re: linux needs bsd networking stack
@ 1996-05-30 18:17 1% ` Steve Alexander
0 siblings, 0 replies; 200+ results
From: Steve Alexander @ 1996-05-30 18:17 UTC (permalink / raw)
To: Alan Cox; +Cc: Larry McVoy, dm, nn, torvalds, sparclinux-cvs, lmlinux
Alan Cox <alan@cymru.net> writes:
>We can't steal it outright. 4.4BSD has abominable problems as is. The FreeBSD
>people
>have the worst of them fixed but don't have stuff like Vegas and have all the
>horrible spoofing problems caused by bad timers.
I'm not sure I understand what that means, but I'm pretty sure that Vegas is
not universally agreed to be a good idea, unless I've missed a meeting.
Just to set the record straight, there are people at SGI who don't like either
the BSD or Linux stacks ;->.
The one thing that I will say about the Linux stack is that it is evolving much
more rapidly than any of the public BSD versions are (I spent some time porting
aliases forward from one version to another for a friend, and the improvements
between versions were amazing), so at some point it will probably win on
functionality.
-- Steve
^ permalink raw reply [relevance 1%]
* Re: linux needs bsd networking stack
@ 1996-05-30 18:17 1% ` Steve Alexander
0 siblings, 0 replies; 200+ results
From: Steve Alexander @ 1996-05-30 18:17 UTC (permalink / raw)
To: Alan Cox; +Cc: Larry McVoy, dm, nn, torvalds, sparclinux-cvs, lmlinux
Alan Cox <alan@cymru.net> writes:
>We can't steal it outright. 4.4BSD has abominable problems as is. The FreeBSD
>people
>have the worst of them fixed but don't have stuff like Vegas and have all the
>horrible spoofing problems caused by bad timers.
I'm not sure I understand what that means, but I'm pretty sure that Vegas is
not universally agreed to be a good idea, unless I've missed a meeting.
Just to set the record straight, there are people at SGI who don't like either
the BSD or Linux stacks ;->.
The one thing that I will say about the Linux stack is that it is evolving much
more rapidly than any of the public BSD versions are (I spent some time porting
aliases forward from one version to another for a friend, and the improvements
between versions were amazing), so at some point it will probably win on
functionality.
-- Steve
^ permalink raw reply [relevance 1%]
* progress, finally...
@ 1996-06-02 2:12 1% David S. Miller
1996-06-02 3:35 1% ` Ariel Faigon
0 siblings, 1 reply; 200+ results
From: David S. Miller @ 1996-06-02 2:12 UTC (permalink / raw)
To: linux
Ok, I have a complete compilation environment that seems to work quite
well.
All the tools are GNU, I have gcc/ld/as/etc. setups which can create
either big or little endian kernels in either ELF or ECOFF format.
The target format is that used by the existing Linux/MIPS people.
These tools have been linking kernels for two days, I finally got a
big endian kernel that sash would eat and it went fine until it tried
to look for DECstation devices as that is one of the only machine
types the existing Linux/MIPS kernels support (splat!). ;-)
For now I'm going to hack the ARC prom code and the SCSI driver in
parallel and see how far I can get it booting, more to come.
Later,
David S. Miller
dm@sgi.com
^ permalink raw reply [relevance 1%]
* Re: progress, finally...
1996-06-02 2:12 1% progress, finally David S. Miller
@ 1996-06-02 3:35 1% ` Ariel Faigon
0 siblings, 0 replies; 200+ results
From: Ariel Faigon @ 1996-06-02 3:35 UTC (permalink / raw)
To: David S. Miller; +Cc: linux
David,
This is very impressive progress. Thanks for the update!
I understand you have the prom pointers. A few that _may_
be relevant are in:
http://info.engr.sgi.com/~ariel/linux/port.html
This doc was put together in a rush, any suggestions, requests
for additions etc. would be welcome.
>
>
>Ok, I have a complete compilation environment that seems to work quite
>well.
>
>All the tools are GNU, I have gcc/ld/as/etc. setups which can create
>either big or little endian kernels in either ELF or ECOFF format.
>The target format is that used by the existing Linux/MIPS people.
>
>These tools have been linking kernels for two days, I finally got a
>big endian kernel that sash would eat and it went fine until it tried
>to look for DECstation devices as that is one of the only machine
>types the existing Linux/MIPS kernels support (splat!). ;-)
>
>For now I'm going to hack the ARC prom code and the SCSI driver in
>parallel and see how far I can get it booting, more to come.
>
>Later,
>David S. Miller
>dm@sgi.com
>
--
Peace, Ariel
^ permalink raw reply [relevance 1%]
* Re: progress, finally...
@ 1996-06-02 3:35 1% ` Ariel Faigon
0 siblings, 0 replies; 200+ results
From: Ariel Faigon @ 1996-06-02 3:35 UTC (permalink / raw)
To: David S. Miller; +Cc: linux
David,
This is very impressive progress. Thanks for the update!
I understand you have the prom pointers. A few that _may_
be relevant are in:
http://info.engr.sgi.com/~ariel/linux/port.html
This doc was put together in a rush, any suggestions, requests
for additions etc. would be welcome.
>
>
>Ok, I have a complete compilation environment that seems to work quite
>well.
>
>All the tools are GNU, I have gcc/ld/as/etc. setups which can create
>either big or little endian kernels in either ELF or ECOFF format.
>The target format is that used by the existing Linux/MIPS people.
>
>These tools have been linking kernels for two days, I finally got a
>big endian kernel that sash would eat and it went fine until it tried
>to look for DECstation devices as that is one of the only machine
>types the existing Linux/MIPS kernels support (splat!). ;-)
>
>For now I'm going to hack the ARC prom code and the SCSI driver in
>parallel and see how far I can get it booting, more to come.
>
>Later,
>David S. Miller
>dm@sgi.com
>
--
Peace, Ariel
^ permalink raw reply [relevance 1%]
* mtc0/eret hazard for the R4600, R4700, and R5000
@ 1996-06-03 17:12 1% William J. Earl
0 siblings, 0 replies; 200+ results
From: William J. Earl @ 1996-06-03 17:12 UTC (permalink / raw)
To: linux
We recently noticed an error in the CP0 hazard table for the above
processors. Specifically, the eret row in the table in Appendix F is
incorrect. There must be two instructions between an mtc0 which changes
a register read by eret and an eret, not just one. This is not normally
a problem, but it does mean that one must keep the mtc0 which restores $epc
far enough away from the eret.
^ permalink raw reply [relevance 1%]
* CVS commit mailing list?
@ 1996-06-04 5:03 1% David S. Miller
0 siblings, 0 replies; 200+ results
From: David S. Miller @ 1996-06-04 5:03 UTC (permalink / raw)
To: linux
If anyone wants to keep close track of my progress I could point the
CVS commit messages at a generic mailing list so that everyone on this
who wants to could see them. Would someone like to set this up?
Later,
David S. Miller
dm@engr.sgi.com
^ permalink raw reply [relevance 1%]
* Re: CVS commit mailing list?
@ 1996-06-04 7:46 1% Ariel Faigon
1996-06-04 12:15 1% ` Kwesi Ames
1996-06-04 16:18 1% ` William J. Earl
0 siblings, 2 replies; 200+ results
From: Ariel Faigon @ 1996-06-04 7:46 UTC (permalink / raw)
To: linux
If anyone on the linux@engr list is _not_ interested in these
CVS commit auto reports, let me know and I'll ask majordomo-owner
to create a separate:
linux-progress@engr
majordomo list.
Until we see objections/too-much-traffic, I think Dave can
go ahead and auto-mail the reports to linux@engr
Personally, I think I'll find these interesting.
Anyone?
>
>I wouldn't mind if you just pointed it at linux@engr (i.e., this list).
>Anyone else?
>
>--lm
>---
>Larry McVoy lm@sgi.com http://reality.sgi.com/lm (415) 933-1804
>Copyright 1996, all rights reserved. Microsoft Network is prohibited from
>redistributing this work in any form, in whole or in part without license.
>License to distribute this work is available to Microsoft at $500.
>Transmission without permission constitutes an agreement to these terms.
>
--
Peace, Ariel
^ permalink raw reply [relevance 1%]
* Re: CVS commit mailing list?
1996-06-04 7:46 1% Ariel Faigon
@ 1996-06-04 12:15 1% ` Kwesi Ames
1996-06-04 16:18 1% ` William J. Earl
1 sibling, 0 replies; 200+ results
From: Kwesi Ames @ 1996-06-04 12:15 UTC (permalink / raw)
To: ariel, linux
[snip]
>
> Until we see objections/too-much-traffic, I think Dave can
> go ahead and auto-mail the reports to linux@engr
>
> Personally, I think I'll find these interesting.
I too find them interesting.
-Kwesi
>
> Anyone?
>
> >
> >I wouldn't mind if you just pointed it at linux@engr (i.e., this list).
> >Anyone else?
> >
[chomp]
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Kwesi O. Ames
Systems Engineering Support
Silicon Graphics Inc.
koa@sgi.com
"I was one in a MILLON"
corp voicemail (800) 326-1020 ext. 5-8713
phone (301) 572-3255
fax (301) 572-3280
http://reality.sgi.com/koa
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
^ permalink raw reply [relevance 1%]
* Re: CVS commit mailing list?
1996-06-04 7:46 1% Ariel Faigon
1996-06-04 12:15 1% ` Kwesi Ames
@ 1996-06-04 16:18 1% ` William J. Earl
1996-06-04 17:16 0% ` Ariel Faigon
1 sibling, 1 reply; 200+ results
From: William J. Earl @ 1996-06-04 16:18 UTC (permalink / raw)
To: ariel; +Cc: linux
Ariel Faigon writes:
>
> If anyone on the linux@engr list is _not_ interested in these
> CVS commit auto reports, let me know and I'll ask majordomo-owner
> to create a separate:
>
> linux-progress@engr
>
> majordomo list.
>
> Until we see objections/too-much-traffic, I think Dave can
> go ahead and auto-mail the reports to linux@engr
>
> Personally, I think I'll find these interesting.
...
I am interested too, but I would rather have two lists, just as
we normally do for regular development (sgi.bugs.xxx for bug reports and
checkins about xxx, sgi.engr.xxx for general discussion about xxx).
Why don't you set up linux-progress as a clone of linux to start, and
people who tire of the reports can unsubscribe from the linux-progress.
Having a separate list will also make a little easier to search the
archives later on.
^ permalink raw reply [relevance 1%]
* Re: more progress
@ 1996-06-04 15:51 1% ` William J. Earl
0 siblings, 0 replies; 200+ results
From: William J. Earl @ 1996-06-04 15:51 UTC (permalink / raw)
To: David S. Miller; +Cc: linux, mani
David S. Miller writes:
...
> Next I will look into getting the kgdb code functioning. And after
> that I will most likely try to get the generic kernel init'ing such
> that all the generic data structures and non-device code are setup and
> the kernel attempts to mount root (which it will not be able to). ;)
...
Please check with Mani Varadarajan (mani@esd.sgi.com) about kgdb.
He has used it with the DMS Moosehead system simulator, although in
that case the simulator acts as the target system monitor, instead of
having a program resident in memory with the kernel. I don't know if
he had to fix anything for the MIPS architecture; if he did, that
might save you some startup time.
^ permalink raw reply [relevance 1%]
* Re: CVS commit mailing list?
1996-06-04 16:18 1% ` William J. Earl
@ 1996-06-04 17:16 0% ` Ariel Faigon
0 siblings, 0 replies; 200+ results
From: Ariel Faigon @ 1996-06-04 17:16 UTC (permalink / raw)
To: William J. Earl; +Cc: ariel, linux
OK, I requested
linux-progress
to be created on majordomo@engr.
I guess it'll take some time till someone gets time to set this up,
I'll let you know when it is ready.
>
>Ariel Faigon writes:
> >
> > If anyone on the linux@engr list is _not_ interested in these
> > CVS commit auto reports, let me know and I'll ask majordomo-owner
> > to create a separate:
> >
> > linux-progress@engr
> >
> > majordomo list.
> >
> > Until we see objections/too-much-traffic, I think Dave can
> > go ahead and auto-mail the reports to linux@engr
> >
> > Personally, I think I'll find these interesting.
>...
>
> I am interested too, but I would rather have two lists, just as
>we normally do for regular development (sgi.bugs.xxx for bug reports and
>checkins about xxx, sgi.engr.xxx for general discussion about xxx).
>Why don't you set up linux-progress as a clone of linux to start, and
>people who tire of the reports can unsubscribe from the linux-progress.
>Having a separate list will also make a little easier to search the
>archives later on.
>
--
Peace, Ariel
^ permalink raw reply [relevance 0%]
* Re: CVS commit mailing list?
@ 1996-06-04 17:16 0% ` Ariel Faigon
0 siblings, 0 replies; 200+ results
From: Ariel Faigon @ 1996-06-04 17:16 UTC (permalink / raw)
To: William J. Earl; +Cc: ariel, linux
OK, I requested
linux-progress
to be created on majordomo@engr.
I guess it'll take some time till someone gets time to set this up,
I'll let you know when it is ready.
>
>Ariel Faigon writes:
> >
> > If anyone on the linux@engr list is _not_ interested in these
> > CVS commit auto reports, let me know and I'll ask majordomo-owner
> > to create a separate:
> >
> > linux-progress@engr
> >
> > majordomo list.
> >
> > Until we see objections/too-much-traffic, I think Dave can
> > go ahead and auto-mail the reports to linux@engr
> >
> > Personally, I think I'll find these interesting.
>...
>
> I am interested too, but I would rather have two lists, just as
>we normally do for regular development (sgi.bugs.xxx for bug reports and
>checkins about xxx, sgi.engr.xxx for general discussion about xxx).
>Why don't you set up linux-progress as a clone of linux to start, and
>people who tire of the reports can unsubscribe from the linux-progress.
>Having a separate list will also make a little easier to search the
>archives later on.
>
--
Peace, Ariel
^ permalink raw reply [relevance 0%]
* netbooting
@ 1996-06-05 7:12 1% David S. Miller
1996-06-05 18:35 1% ` netbooting William J. Earl
0 siblings, 1 reply; 200+ results
From: David S. Miller @ 1996-06-05 7:12 UTC (permalink / raw)
To: linux
How much pain is involved in netbooting a kernel from an INDY? Can I
just setup a /tftpboot area with the appropriate files and setup a
place to place the kernels for the bootloader to find and it'll work?
If so, can someone tell me what the necessary magic is that needs to
be done?
This would speed up my development tremendously ;)
Later,
David S. Miller
dm@engr.sgi.com
^ permalink raw reply [relevance 1%]
* Re: netbooting
1996-06-05 7:12 1% netbooting David S. Miller
@ 1996-06-05 18:35 1% ` William J. Earl
0 siblings, 0 replies; 200+ results
From: William J. Earl @ 1996-06-05 18:35 UTC (permalink / raw)
To: David S. Miller; +Cc: linux
David S. Miller writes:
>
> How much pain is involved in netbooting a kernel from an INDY? Can I
> just setup a /tftpboot area with the appropriate files and setup a
> place to place the kernels for the bootloader to find and it'll work?
> If so, can someone tell me what the necessary magic is that needs to
> be done?
It is easy. On your host system, either put the kernel you want
to boot in /usr/local/boot/., or, in /etc/inetd.conf on your host
system, add a "-f" to the end of the line and "killall -HUP inetd" (to get
inetd to re-read /etc/inetd.conf). Then, on the target system, first
set the "netaddr" PROM environment variable. It should be set to the
IP address (dotted notation) of the target system. Check it with the
"printenv" PROM command. Set it with
setenv -p netaddr 1.2.3.4
(replacing "1.2.3.4" with the IP address of the target system). Then,
do
boot -f bootp()hostsystem:xyx
where "hostsystem" is the name of the host system and "xyz" is the
name of the kernel you want to boot. If you add "-f" to the bootp
line, you can use a full path name on the target system in place of
"xyz". Any additional words on the command line are passed to the booted
program as a UNIX-style argument list, and the environment variable list
is passed as well. That is, on entry, the program will see argc in $a0,
argv in $a1, and environ in $a2.
On an Indy, the booted kernel (or other program) must be
in MIPS ECOFF format. On Moosehead, the kernel must be in ELF format.
The "-coff" option to the IRIX ld will cause it to create an ECOFF binary
instead of an ELF binary in the final link, even if all the input binaries
are in ELF format. If you want to boot an ELF kernel on Indy, you have
to boot an indirect loader. You can use the IRIX sash. Put sash in the
volume header on the Indy, or in a bootp-able place on the host system.
Then do
boot -f bootp()hostsystem:sash
or
boot -f sash
and then, in either case
boot -f bootp()hostsystem:xyx
where the last command is to the sash prompt, not the PROM prompt. sash
knows how to load both ELF and ECOFF.
On an Indy, the PROM would like you to link the kernel at or above
0x88002000, with the highest address in the linked binary being below
0x88400000 (4 MB).
^ permalink raw reply [relevance 1%]
* well it is about time...
@ 1996-06-08 12:19 1% David S. Miller
1996-06-10 16:59 1% ` William J. Earl
0 siblings, 1 reply; 200+ results
From: David S. Miller @ 1996-06-08 12:19 UTC (permalink / raw)
To: linux
This port is going like a funeral procession, I apologize.
Ok, quick report:
1) Interrupts work, with a little more coding it will handle the
setup and registering of all interrupts and handlers on the
INDY for whatever driver requests them.
2) Timers work, I am using the r4k counter/compare register timer
mechanism because of the bug in the i8254 Intel timer chips
on certain INDY's. The calibration of the compare offsets
needs some work but the working framework is there and needs
a little tweaking, basically my algorithm is:
a) setup i8254 counter 0 and counter 2 such that the period
of counter 0 is the desired HZ value
b) poll counter 0 waiting for a value of 1
c) quickly set CP0_COUNTER to zero
d) poll counter 0 for value of 1
e) quickly read CP0_COUNTER value
This seems to approximate the value I want in it's current form
pretty well. I have to add some fuzz factors into it and possibly
write the calibration code in assembly to get the accuracy I
want/need.
3) The kernel boots decently far. It init's all of memory management,
sets up the buffer cache, sets up the inode table, inits the
networking stack, prints the linux banner and is about to fork
off the init kernel thread.
At this point my task list looks like:
1) Clean up and finish all the krufty code I wrote tonight ;-)
2) Write console/keyboard/mouse/serial drivers as these will need to
be done anyways.
3) Do some verification on what works at that point.
4) Look into getting kgdb working.
5) Write ethernet/scsi drivers.
6) (fingers crossed) shell prompt... we hope...
As far as I'm concerned I am severely behind schedule. I will try to
get the pace going more quickly soon, I promise. Sorry. God, I'm
so slow, two weeks to get the thing to half boot, sheesh!
Later,
David S. Miller
dm@sgi.com
^ permalink raw reply [relevance 1%]
* Re: Are you satisfied now Mr. McVoy? ;-)
@ 1996-06-08 18:22 1% ` Ariel Faigon
1996-06-10 16:56 1% ` William J. Earl
1 sibling, 0 replies; 200+ results
From: Ariel Faigon @ 1996-06-08 18:22 UTC (permalink / raw)
To: David S. Miller; +Cc: linux
>
>
>Calibrating delay loop.. ok - 91.96 BogoMIPS
>
Will a Triton CPU (R5000) make this better ? :-)
For those who are not familiar with bogomips, my Pentium-100
at home does 39.94 bogomips. And the best number I've seen
for a desktop is almost 300 bogomips for an Alpha 21064
overclocked to 300MHz. The 91.96 number for a 150MHz Indy
sounds pretty good.
Still, I would like to know, David:
What clock factor are you using? The DEC Alphas do one
clock pre instruction, so their factor is 1, why is
the Indy at less than two-thirds of its clock rate?
Fr more details:
http://sunsite.unc.edu/linux/HOWTO/mini/BogoMips
It would be nice to send them the new data...
--
Peace, Ariel
^ permalink raw reply [relevance 1%]
* Re: Are you satisfied now Mr. McVoy? ;-)
@ 1996-06-08 18:22 1% ` Ariel Faigon
0 siblings, 0 replies; 200+ results
From: Ariel Faigon @ 1996-06-08 18:22 UTC (permalink / raw)
To: David S. Miller; +Cc: linux
>
>
>Calibrating delay loop.. ok - 91.96 BogoMIPS
>
Will a Triton CPU (R5000) make this better ? :-)
For those who are not familiar with bogomips, my Pentium-100
at home does 39.94 bogomips. And the best number I've seen
for a desktop is almost 300 bogomips for an Alpha 21064
overclocked to 300MHz. The 91.96 number for a 150MHz Indy
sounds pretty good.
Still, I would like to know, David:
What clock factor are you using? The DEC Alphas do one
clock pre instruction, so their factor is 1, why is
the Indy at less than two-thirds of its clock rate?
Fr more details:
http://sunsite.unc.edu/linux/HOWTO/mini/BogoMips
It would be nice to send them the new data...
--
Peace, Ariel
^ permalink raw reply [relevance 1%]
* Re: Are you satisfied now Mr. McVoy? ;-)
1996-06-08 18:22 1% ` Ariel Faigon
@ 1996-06-10 16:56 1% ` William J. Earl
1996-06-10 16:59 1% ` David S. Miller
1 sibling, 1 reply; 200+ results
From: William J. Earl @ 1996-06-10 16:56 UTC (permalink / raw)
To: David S. Miller; +Cc: linux
David S. Miller writes:
>
> Calibrating delay loop.. ok - 91.96 BogoMIPS
I assume this is on the target system, which should be a 133 MHZ R4600SC.
^ permalink raw reply [relevance 1%]
* Re: well it is about time...
1996-06-08 12:19 1% well it is about time David S. Miller
@ 1996-06-10 16:59 1% ` William J. Earl
0 siblings, 0 replies; 200+ results
From: William J. Earl @ 1996-06-10 16:59 UTC (permalink / raw)
To: David S. Miller; +Cc: linux
David S. Miller writes:
>
> This port is going like a funeral procession, I apologize.
Not at all--nice work. Considering some of the messy stuff
you have to deal with, it is going quite well.
..
> 2) Timers work, I am using the r4k counter/compare register timer
> mechanism because of the bug in the i8254 Intel timer chips
> on certain INDY's. The calibration of the compare offsets
> needs some work but the working framework is there and needs
> a little tweaking, basically my algorithm is:
>
> a) setup i8254 counter 0 and counter 2 such that the period
> of counter 0 is the desired HZ value
> b) poll counter 0 waiting for a value of 1
> c) quickly set CP0_COUNTER to zero
> d) poll counter 0 for value of 1
> e) quickly read CP0_COUNTER value
>
> This seems to approximate the value I want in it's current form
> pretty well. I have to add some fuzz factors into it and possibly
> write the calibration code in assembly to get the accuracy I
> want/need.
When it is time to do R4000 support, I can show you how to work
around the R4000 count/compare bug. (This does not apply to other processors,
such as the R4600, R5000, or R10000.)
^ permalink raw reply [relevance 1%]
* Re: Are you satisfied now Mr. McVoy? ;-)
1996-06-10 16:56 1% ` William J. Earl
@ 1996-06-10 16:59 1% ` David S. Miller
0 siblings, 0 replies; 200+ results
From: David S. Miller @ 1996-06-10 16:59 UTC (permalink / raw)
To: wje; +Cc: linux
Date: Mon, 10 Jun 1996 09:56:22 -0700
From: wje@fir.esd.sgi.com (William J. Earl)
David S. Miller writes:
> Calibrating delay loop.. ok - 91.96 BogoMIPS
I assume this is on the target system, which should be a 133
MHZ R4600SC.
Yes, but beware my r4k compare register calibration still needs some
work, this value could be off a bit...
Later,
David S. Miller
dm@sgi.com
^ permalink raw reply [relevance 1%]
* Re: Are you satisfied now Mr. McVoy? ;-)
1996-06-08 18:22 1% ` Ariel Faigon
@ 1996-06-10 17:02 1% ` William J. Earl
-1 siblings, 0 replies; 200+ results
From: William J. Earl @ 1996-06-10 17:02 UTC (permalink / raw)
To: ariel; +Cc: David S. Miller, linux
Ariel Faigon writes:
> >
> >
> >Calibrating delay loop.. ok - 91.96 BogoMIPS
> >
> Will a Triton CPU (R5000) make this better ? :-)
An R5000 should scale with clock rate, relative to the 133 MHZ R4600
David is using. The 180 MHZ R5000 would then be 124.46.
> For those who are not familiar with bogomips, my Pentium-100
> at home does 39.94 bogomips. And the best number I've seen
> for a desktop is almost 300 bogomips for an Alpha 21064
> overclocked to 300MHz. The 91.96 number for a 150MHz Indy
> sounds pretty good.
I think the 150 MHZ R4400 is in David's host machine, with the
133 MHZ R4600 in his target machine, so the 91.96 should be for the latter.
^ permalink raw reply [relevance 1%]
* Re: Are you satisfied now Mr. McVoy? ;-)
@ 1996-06-10 17:02 1% ` William J. Earl
0 siblings, 0 replies; 200+ results
From: William J. Earl @ 1996-06-10 17:02 UTC (permalink / raw)
To: ariel; +Cc: David S. Miller, linux
Ariel Faigon writes:
> >
> >
> >Calibrating delay loop.. ok - 91.96 BogoMIPS
> >
> Will a Triton CPU (R5000) make this better ? :-)
An R5000 should scale with clock rate, relative to the 133 MHZ R4600
David is using. The 180 MHZ R5000 would then be 124.46.
> For those who are not familiar with bogomips, my Pentium-100
> at home does 39.94 bogomips. And the best number I've seen
> for a desktop is almost 300 bogomips for an Alpha 21064
> overclocked to 300MHz. The 91.96 number for a 150MHz Indy
> sounds pretty good.
I think the 150 MHZ R4400 is in David's host machine, with the
133 MHZ R4600 in his target machine, so the 91.96 should be for the latter.
^ permalink raw reply [relevance 1%]
* Is this a silly idea?
@ 1996-06-11 0:13 5% Alistair Lambie
1996-06-11 17:38 5% ` David S. Miller
0 siblings, 1 reply; 200+ results
From: Alistair Lambie @ 1996-06-11 0:13 UTC (permalink / raw)
To: linux
Folks,
I guess a lot of people will have both Linux and that other operating system
on there machines for various reasons. One thing that I know I would find
useful is to be able to have a filesystem that could be accessed from
whichever OS you had loaded (eg. for putting mail and other common things on).
I'm not sure what the best way to attack this would be, but my guess is that
we need to put the common filesystem in Irix, as I would pick that it would
be difficult to get the buyin to port one of our filesystems to Linux.
Several questions:
1. Is this sensible (or is there already a way of doing this)?
2. If it is sensible, what should we do (type of fs etc)?
3. Does anyone know how easy this is (I'm not sure whether I'm brave enough!)?
Just a thought....
Alistair
PS - I get 61.64 Bogomips on a 100MHz R4600PC
^ permalink raw reply [relevance 5%]
* my CVS tree
@ 1996-06-11 17:36 1% David S. Miller
0 siblings, 0 replies; 200+ results
From: David S. Miller @ 1996-06-11 17:36 UTC (permalink / raw)
To: linux
I want to have my CVS tree moved into a place which is backed up often
and is stable + globally accessible with ease by others. And after
seeing my home directory get spammed not two days after I get here,
neteng is currently _not_ the place as of now, I feel more confident
having it stay on my workstation as it does indeed right now.
It would be a shame to lose all the work I have done, so I'd like to
take care of this soon.
Later,
David S. Miller
dm@sgi.com
^ permalink raw reply [relevance 1%]
* Re: Is this a silly idea?
1996-06-11 0:13 5% Is this a silly idea? Alistair Lambie
@ 1996-06-11 17:38 5% ` David S. Miller
0 siblings, 0 replies; 200+ results
From: David S. Miller @ 1996-06-11 17:38 UTC (permalink / raw)
To: alambie; +Cc: linux
From: alambie@wellington.sgi.com (Alistair Lambie)
Date: Tue, 11 Jun 1996 12:13:36 +1200 (NZT)
I'm not sure what the best way to attack this would be, but my
guess is that we need to put the common filesystem in Irix, as I
would pick that it would be difficult to get the buyin to port one
of our filesystems to Linux.
I planned on hacking xfs _and_ efs implementations into Linux.
Several questions:
1. Is this sensible (or is there already a way of doing this)?
2. If it is sensible, what should we do (type of fs etc)?
3. Does anyone know how easy this is (I'm not sure whether I'm
brave enough!)?
Also, I wouldn't mind seeing an ext2 implementation in IRIX, I could
probably hack up an initial read-only kernel module implementation in
a very short amount of time.
This is all only a matter of someone sitting behind the screen and
whacking away at the code for 2 or 3 days, nothing more. I'd rather
concentrate on getting bootstrapped at this point, but after that I'll
probably hack on something like xfs/efs or whatever.
Later,
David S. Miller
dm@sgi.com
^ permalink raw reply [relevance 5%]
* Re: Is this a silly idea?
@ 1996-06-11 17:47 5% Larry McVoy
1996-06-11 18:44 4% ` Donna Yobs
0 siblings, 1 reply; 200+ results
From: Larry McVoy @ 1996-06-11 17:47 UTC (permalink / raw)
To: linux; +Cc: jmy
: I planned on hacking xfs _and_ efs implementations into Linux.
We will shoot that plan in the head right away. EFS is dead technology
and XFS is family jewels. If we start putting XFS into Linux, there will
be hell to pay. Besides, XFS is 45K lines of code (probably more now)
and it is really non trivial. Porting that to Linux would take quite
a while.
I would like to have an XFS port eventually, but we need to figure out a
way to keep it SGI source. Last I checked, there was noise that doing
stuff as a loadable module was not enough. Any news on that?
I think porting ext2fs to IRIX is a much better idea.
: Also, I wouldn't mind seeing an ext2 implementation in IRIX, I could
: probably hack up an initial read-only kernel module implementation in
: a very short amount of time.
Please. I have some file system notes somewhere that talk about the
data structures needed to do this. James is a good resource, he did
cachefs. He's a busy, but nice, guy and he sits near you.
--lm
^ permalink raw reply [relevance 5%]
* Re: Is this a silly idea?
1996-06-11 17:47 5% Is this a silly idea? Larry McVoy
@ 1996-06-11 18:44 4% ` Donna Yobs
1996-06-11 22:34 5% ` Ariel Faigon
0 siblings, 1 reply; 200+ results
From: Donna Yobs @ 1996-06-11 18:44 UTC (permalink / raw)
To: linux
lm is right, we don't want to let the xfs source out;
but if we could do just the loadable modules it would
show an advantage of mips technology on linux (or is
that counter culture, sigh).
-d
--
-------------------------------------------------------------------------
Donna Derby Yobs Silicon Graphics - NSD yobs@engr.sgi.com
Product Marketing
^ permalink raw reply [relevance 4%]
* Re: Is this a silly idea?
@ 1996-06-11 19:48 4% Larry McVoy
0 siblings, 0 replies; 200+ results
From: Larry McVoy @ 1996-06-11 19:48 UTC (permalink / raw)
To: Donna Yobs; +Cc: linux
: lm is right, we don't want to let the xfs source out;
: but if we could do just the loadable modules it would
: show an advantage of mips technology on linux (or is
: that counter culture, sigh).
We will need to do this eventually.
^ permalink raw reply [relevance 4%]
* Re: Is this a silly idea?
1996-06-11 18:44 4% ` Donna Yobs
@ 1996-06-11 22:34 5% ` Ariel Faigon
0 siblings, 0 replies; 200+ results
From: Ariel Faigon @ 1996-06-11 22:34 UTC (permalink / raw)
To: Donna Yobs; +Cc: linux
>
>lm is right, we don't want to let the xfs source out;
>but if we could do just the loadable modules it would
>show an advantage of mips technology on linux (or is
>that counter culture, sigh).
>
Donna,
I think this is a good realistic compromise that can be accepted
both by SGI and the Linux community.
On the way to "world domination now" (as Linus puts it), Linux
enthusiasts must learn how to realistically compromise here and there.
Think of it: a much more significant "compromise" is to support
the Windows API via WINE etc. rather than trying to force the Unix
APIs upon the rest of the software-developers-world and lose.
With clever compromises that the commercial world can accept
and by keeping the vast majority of the value under the GPL,
Linux will gradually get where Linus (and some of the rest of us :-)
want it to be.
--
Peace, Ariel
^ permalink raw reply [relevance 5%]
* Re: Is this a silly idea?
@ 1996-06-11 22:34 5% ` Ariel Faigon
0 siblings, 0 replies; 200+ results
From: Ariel Faigon @ 1996-06-11 22:34 UTC (permalink / raw)
To: Donna Yobs; +Cc: linux
>
>lm is right, we don't want to let the xfs source out;
>but if we could do just the loadable modules it would
>show an advantage of mips technology on linux (or is
>that counter culture, sigh).
>
Donna,
I think this is a good realistic compromise that can be accepted
both by SGI and the Linux community.
On the way to "world domination now" (as Linus puts it), Linux
enthusiasts must learn how to realistically compromise here and there.
Think of it: a much more significant "compromise" is to support
the Windows API via WINE etc. rather than trying to force the Unix
APIs upon the rest of the software-developers-world and lose.
With clever compromises that the commercial world can accept
and by keeping the vast majority of the value under the GPL,
Linux will gradually get where Linus (and some of the rest of us :-)
want it to be.
--
Peace, Ariel
^ permalink raw reply [relevance 5%]
* nt...
@ 1996-06-11 22:53 1% Donna Yobs
0 siblings, 0 replies; 200+ results
From: Donna Yobs @ 1996-06-11 22:53 UTC (permalink / raw)
To: linux
Hate to muddy the waters, but a customer has asked
about getting some basic tools onto NT so that we
can interop better. Hoping someone in this group
may have some insight, I'm including the email. Let
me know if you have any ideas. I'm trying to iron
out a list of what we should do to have a better
PC friendly view of the world, without going to NT.
thanks
-- included text --
The type of NT tools that I would be looking for is as follows:
Our company writes glue to tie many of the entertainment type
applications together. We have translaters, display tools,
programs that scan disk directories and verify that all the
frames of a shot are present, etc. For example, we have a small
program that sircheck (for Solitair Image Recorder Check) that
opens each frame of a shot and reads the header to make sure
that all the frames are of the same resolution. If you have
been doing a shot at video res and rerender at 2k resolution,
It is possible that all of the frames are present, but that
one of them is still the old version. The most common mistake
is to copy frames 1-99 and then 101-199 skipping frame 100.
Customers now have NT workstations -- whether for 3Dstudio,
lightwave, Softimage, or whatever. We are being asked for
the ability to execute sircheck from an NT workstation so that
the files can be verified by the animator before he turns the
tape over to the guy who will be shooting the shot on an SGI
workstation. This utility is part of what makes our film
recorder package more attractive than the competition. Failure
to respond to this kind of request would make our company
appear less responsive in a business that borders on the edge
of custom consultation. We have been exclusively SGI based
since 1984, and have very little NT experience. Most of our
utilities have some kind of GL or OpenGL based GUI. I am
looking for any help to run this kind of program on NT. There
is no high performance graphics involved. Nor do I wish to
redesign the interface to match NT style. I think I can do
some of what I want with the software GL emulator that was
presented for Windows 95. I need some no cost software like
that GL package.
In addition, I need low level stuff like what is in the
developers toolbox. Readers and writers and low level chunks.
For example, we need the ability to read SGI .rgb format files
on NT. The net abounds with utilities for Unix type things on
NT, such as tar. I spoke with the toolbox janitors about
collecting these type of utilities and seeing which ones support
the IRIX versions. For example, finding or adapting a public
domain NT tar package such that it will easily recognize and
handle the default SGI tar block sizes and byte order. Our
customers are artists and animators, not computer programmers.
They need the ability to read tapes, translate files, and in
general, go back and forth between tools and packages without
typing a 60 character command line. They need more than an
NFS mounted partition shared between the SGI and NT. What good
is an NFS mounted partition if you can't read the file format?
The developers toolbox is a wouderful, useful, and esential
effort. It contains much public stuff cleansed for use with
SGI machines. I believe that if the effort is expanded to
include tools for NT that would enable SGI machines to better
fit into a mixed environment, our ability to sell SGI into
these accounts would be greatly enhanced. Right now, I am
under a lot of pressure to port our whole film recorder to
NT. This would be a big project, and one I am not wild about.
If I can not make it easier for SGI's and NT to co-exist, we
will have to give it serious thought.
I hope this answers some of your questions. I see that my
sticky keyboard has played havok with my spelling. I can not
seem to find a decent mail package that can work between my
PC and the SGI mailhost that we have at RFX. Another example
of problems working with NT and SGI. It is agravating not being
able to spellcheck or to edit.
Ray Feeney
-------------------------------------------------------------------------
Donna Derby Yobs Silicon Graphics - NSD yobs@engr.sgi.com
Product Marketing http://storm.engr
^ permalink raw reply [relevance 1%]
* Re: I fixed the r4ktimer code...
@ 1996-06-12 1:11 1% ` William J. Earl
1996-06-12 1:19 1% ` David S. Miller
0 siblings, 1 reply; 200+ results
From: William J. Earl @ 1996-06-12 1:11 UTC (permalink / raw)
To: David S. Miller; +Cc: linux
David S. Miller writes:
>
> Calibrating delay loop.. ok - 138.04 BogoMIPS
>
> Much better ;-)
Yes, except that it should really be 133.33 on the 133 MHZ R4600SC.
I don't have any idea where the 4% error would be coming from, unless there
is something wrong with the external timer. One way of checking the timer
might be to measure a tick of the Dallas clock/calendar chip. I believe
the one we use in Indy counts 0.01 second units, so noticing the
$count change over, say, a 0.5 second interval, as measured by the
Dallas part, would be a way of validating the timer configuration.
^ permalink raw reply [relevance 1%]
* Re: I fixed the r4ktimer code...
1996-06-12 1:11 1% ` William J. Earl
@ 1996-06-12 1:19 1% ` David S. Miller
0 siblings, 0 replies; 200+ results
From: David S. Miller @ 1996-06-12 1:19 UTC (permalink / raw)
To: wje; +Cc: linux
Date: Tue, 11 Jun 1996 18:11:05 -0700
From: wje@fir.esd.sgi.com (William J. Earl)
David S. Miller writes:
>
> Calibrating delay loop.. ok - 138.04 BogoMIPS
>
> Much better ;-)
Yes, except that it should really be 133.33 on the 133 MHZ R4600SC.
I don't have any idea where the 4% error would be coming from, unless there
is something wrong with the external timer. One way of checking the timer
might be to measure a tick of the Dallas clock/calendar chip. I believe
the one we use in Indy counts 0.01 second units, so noticing the
$count change over, say, a 0.5 second interval, as measured by the
Dallas part, would be a way of validating the timer configuration.
Peculiar... but I believe if you look at the calibrate_delay()
function I sent you earlier you will see that the way it performs the
calculation implies a certain error fuzz all in the name of efficiency
(some time back calibrate_delay() was much more accurate but took 3 or
4 seconds to run at boot time, ugh, the lesser of two evils)
The new way I calculate the r4k compare register offset is that I set
the rate generation of the Intel counter at 1HZ. I then make 4
samples of how far the r4k counter goes every time the Intel counter
makes a full 1 HZ iteration. I then average these 4 samples and
multiply by HZ (which == 100 for the Mips port of Linux) to find the
final r4k offset value that I use.
Anyways, BogoMIPS is by definition "bogus" ;-) It is only used by
the kernel to do quick microsecond delays in various places of the
kernel.
Later,
David S. Miller
dm@sgi.com
^ permalink raw reply [relevance 1%]
* off topic question
@ 1996-06-12 23:14 1% David S. Miller
1996-06-12 23:44 1% ` Kwesi Ames
0 siblings, 1 reply; 200+ results
From: David S. Miller @ 1996-06-12 23:14 UTC (permalink / raw)
To: linux
What is a good program under IRIX for creating figures and slides?
Later,
David S. Miller
dm@sgi.com
^ permalink raw reply [relevance 1%]
* Re: off topic question
1996-06-12 23:14 1% off topic question David S. Miller
@ 1996-06-12 23:44 1% ` Kwesi Ames
0 siblings, 0 replies; 200+ results
From: Kwesi Ames @ 1996-06-12 23:44 UTC (permalink / raw)
To: David S. Miller, linux
On Jun 12, 4:14pm, David S. Miller wrote:
> Subject: off topic question
>
> What is a good program under IRIX for creating figures and slides?
>
> Later,
> David S. Miller
> dm@sgi.com
>-- End of excerpt from David S. Miller
You mean other than Showcase??
Kwesi
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Kwesi O. Ames
Systems Engineering Support
Silicon Graphics Inc.
koa@sgi.com
"I was one in a MILLON"
corp voicemail (800) 326-1020 ext. 5-8713
phone (301) 572-3255
fax (301) 572-3280
http://reality.sgi.com/koa
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
^ permalink raw reply [relevance 1%]
* Re: strace project
@ 1996-06-17 20:58 1% ` William J. Earl
0 siblings, 0 replies; 200+ results
From: William J. Earl @ 1996-06-17 20:58 UTC (permalink / raw)
To: dm; +Cc: linux
David S. Miller writes:
>
> I'm just curious how strace support for IRIX 6.2 is coming along?
>
> It would be _extremely_ useful and make me _extremely_ happy to have
> so that I can write all of the IRIX system call compatability code
> when I return from my talks in the U.K. on Thursday.
If by strace you mean tracing system call arguments and results,
try using par(1). (It does not help if you want to decode argument structures,
however.) Here is a sample:
<fir:5> par -s -SS date
Mon Jun 17 13:56:39 PDT 1996
0mS was sent signal SIGUSR1
0mS END-pause() errno = 4 (Interrupted system call)
0mS received signal SIGUSR1
0mS sigreturn(0x7fff2a00) OK
1mS execve(/usr/bsd/date, 0x7fff2ea8, 0x7fff2eb0) errno = 2 (No such file or directory)
1mS execve(/usr/new/date, 0x7fff2ea8, 0x7fff2eb0) errno = 2 (No such file or directory)
1mS execve(/usr/people/wje/abi-bin/date, 0x7fff2ea8, 0x7fff2eb0) errno = 2 (No such file or directory)
2mS execve(/usr/people/wje/irix-bin/date, 0x7fff2ea8, 0x7fff2eb0) errno = 2 (No such file or directory)
2mS execve(/usr/bin/date, 0x7fff2ea8, 0x7fff2eb0) OK
74mS open(/lib/rld, O_RDONLY, 04) = 3
74mS read(3, <7f 45 4c 46 01 02 01 00 00 00 00 00 00 00 00 00>..., 52) = 52
74mS lseek(3, 52, SEEK_SET) = 52
74mS read(3, <70 00 00 00 00 00 00 a0 0f b6 00 a0 0f b6 00 a0>..., 96) = 96
74mS elfmap(3, 0x7fff21bc, 2) = 0xfb60000
75mS close(3) OK
76mS getpagesize() = 4096
77mS getpid() = 10390 ppid=10389
78mS syssgi(SGI_TOSSTSAVE) OK
78mS getpagesize() = 4096
78mS brk(0x10002000) OK
80mS time() = 835044999
80mS ioctl(1, TCGETA, 0x7fff2cd8) = 0
81mS write(1, "Mon Jun 17 13:56:39 PDT 1996\n", 29) = 29
81mS prctl(PR_GETNSHARE) = 0
81mS exit(0)
exit : 1 times
read : 2 times
write : 1 times
open : 1 times
close : 1 times
time : 1 times
brk : 1 times
lseek : 1 times
getpid : 1 times
syssgi : 2 times
ioctl : 1 times
sysmp : 2 times
execve : 5 times
sigreturn : 1 times
prctl : 1 times
^ permalink raw reply [relevance 1%]
* native Linux/MIPS binaries
@ 1996-06-17 21:20 1% David S. Miller
0 siblings, 0 replies; 200+ results
From: David S. Miller @ 1996-06-17 21:20 UTC (permalink / raw)
To: linux
I'm going to be away giving talks in the U.K. until Thursday
afternoon. With that in mind I'm going to show people how they can
begin to become acquainted with the work that is already done, and
how to setup a cross-compilation environment both for the kernel and
for userland binaries.
If you want to checkout and build your own SGILinux kernels, Larry and
myself have set things up so that this is possible on neteng. Just
ask Larry to put you into group 'hackers' on neteng and you'll be able
to check out a CVS kernel source tree.
Step 1: Get added to group 'hackers' on neteng.
Step 2: Make sure the following are close to the beginning of your
PATH:
/usr/local/gnu-cross-seb/bin
These are the cross gcc/binutils utilities necessary
to build a SGI Linux kernel.
/hosts/neteng/usr/people/dm/install/bin
These are miscellaneous GNU utilities such as CVS,
GNU make, and GNU awk, which are required for the
build process.
Step 3: Set CVSROOT environment variable to /hosts/tanya/cvs and
checkout your very own kernel.
$ export CVSROOT=/hosts/tanya/cvs
$ mkdir src
$ cd src
$ cvs checkout linux
If you've had a tree for a while, or see some updates on
linux-progress you would like integrated into your tree
do this.
$ cd src
$ cvs update linux
If you want to make changes to the source, and feel overly
free to, specify the file to be 'committed' back into the
CVS repository like this.
$ cd src/linux/drivers/net
$ cvs commit -m "My cool checkin message." sgiseeq.c sgiseeq.h
CVS has a lot of other powerful features such as revision
diffs, automatic commit conflict detection etc.
Step 4: Configure and build.
$ cd linux
$ make oldconfig
$ make dep; make clean
$ make vmlinux
Or if you like parallel builds (neteng can build Linux
kernels in around 2 1/2 minutes flat) replace the last
command with.
$ make -j
Step 5: If you want, boot the thing.
$ cp vmlinux /usr/local/boot
Go into the ARCS boot monitor prompt on the other machine
and say something like
>> bootp()server:vmlinux
And it should at least do something interesting ;-)
For userland, unfortunately, I can only point you at where the current
Linux/MIPS information is located. I will be doing some detective
work on native userland binaries myself when I return, but people can
check it out for now if they would like to.
The current main distribution site is:
ftp.fnet.fr:/linux-mips/
The current library the other MIPS are using as a basis cannot be
obtained from the above site, it is a pre-test release of GNU libc,
you can obtain snapshots of these prereleases from:
alpha.gnu.ai.mit.edu:/roland/
These are developer snapshots, so don't be surprised if it doesn't
work without applying a hammer to the code/makefiles. ;-)
I believe that the cross-development tools provided on ftp.fnet.fr can
be used to compile the GNU libc and subsequently the userlevel
binaries linked with GNU libc.
The Linux/MIPS web site hasn't been talking to me lately, seems like a
configuration on their end, but for reference it is:
http://www.fnet.fr/linux-mips/
The documation provided there can be found at the Linux/MIPS ftp site
as well I believe.
Later,
David S. Miller
dm@sgi.com
^ permalink raw reply [relevance 1%]
* Re: strace project
@ 1996-06-17 22:27 1% ` Larry McVoy
0 siblings, 0 replies; 200+ results
From: Larry McVoy @ 1996-06-17 22:27 UTC (permalink / raw)
To: William J. Earl; +Cc: linux
: If by strace you mean tracing system call arguments and results,
: try using par(1). (It does not help if you want to decode argument structures,
: however.) Here is a sample:
He needs to decode args. The idea was that strace groks most of the ioctls
in most OS's. If we ever want to run little endian binaries on a big
endian kernel (which would be kinda cool) we need the arg decode. David
wanted it for something else too.
--lm
^ permalink raw reply [relevance 1%]
* Re: strace project
@ 1996-06-17 22:27 1% ` Larry McVoy
0 siblings, 0 replies; 200+ results
From: Larry McVoy @ 1996-06-17 22:27 UTC (permalink / raw)
To: William J. Earl; +Cc: linux
: If by strace you mean tracing system call arguments and results,
: try using par(1). (It does not help if you want to decode argument structures,
: however.) Here is a sample:
He needs to decode args. The idea was that strace groks most of the ioctls
in most OS's. If we ever want to run little endian binaries on a big
endian kernel (which would be kinda cool) we need the arg decode. David
wanted it for something else too.
--lm
^ permalink raw reply [relevance 1%]
* anyone know if this is true?
@ 1996-06-18 16:41 1% Larry McVoy
1996-06-18 17:10 1% ` Ariel Faigon
0 siblings, 1 reply; 200+ results
From: Larry McVoy @ 1996-06-18 16:41 UTC (permalink / raw)
To: linux; +Cc: olson
If it isn't true, can someone send mail to Tiemann and tell him the
facts. Sounds like we're getting bad press.
------- Forwarded Message
Date: Tue, 18 Jun 1996 05:22:52 -0700
From: Michael Tiemann <tiemann@cygnus.com>
To: lm@sgi.com
Subject: [comp.sys.sgi.apps] gcc part II
Is this not fixed in 6.2? I upgraded my machine at home yesterday, and
it looked suspiciously like SGI was providing headers and libraries as
part of the std 6.2 release.
From: jon@vcnet.com (Jon Rust)
Subject: gcc part II
Newsgroups: comp.sys.sgi.apps
Date: Mon, 17 Jun 1996 22:25:34 -0700
Organization: IAVC
Path: cygnus.com!kithrup.com!news.Stanford.EDU!agate!howland.reston.ans.net
!newsfeed.internetmci.com!in1.uu.net!news.vcnet.com!jon.vc.net!user
Lines: 21
Message-ID: <jon-1706962225340001@jon.vc.net>
NNTP-Posting-Host: jon.vc.net
X-Newsreader: Yet Another NewsWatcher 2.2.0b4
Before I fly off the handle, I wanna make sure this is true.
You can't build ***anything*** unless you fork over a huge wad of cash to
SGI for their compiler and dev enviro?
**If** this is true, it's horseshit. No wonder SGI is so far down the food
chain in the land of UNIX. Buying SGI could be one of the biggest mistakes
I've made since openning my business over 15 months ago. I wonder if my 30
days are up. Maybe I can ship it back. I only wish I'd bought [insert any
other UNIX platform here].
If it's not true, could someone plz point me in the right direction to get
gcc working so I can compile BIND, RADIUS, wuftpd, etc...
pissed off with no build capability,
jon
--------------------------------------------------------
Jon Rust
Internet Access of Ventura County
jon@vc.net http://www.vc.net 805.383.3500
I know that gcc is not yet 6.2-friendly, but that's much more easily
fixed than the library/header problem.
Michael
------- End of Forwarded Message
^ permalink raw reply [relevance 1%]
* Re: anyone know if this is true?
1996-06-18 16:41 1% anyone know if this is true? Larry McVoy
@ 1996-06-18 17:10 1% ` Ariel Faigon
0 siblings, 0 replies; 200+ results
From: Ariel Faigon @ 1996-06-18 17:10 UTC (permalink / raw)
To: Larry McVoy; +Cc: linux, gcc, tiemann
Sadly, it *is* true. I guess many more 6.2 pissed off customers
are waiting down the pipeline.
We can solve it by getting David Miller's development environment
packaged as freeware, (it includes a GNU linker that works)
and put it (really quick) outside the firewall for whoever
is interested.
1) Someone with a couple of days of time needs to take this
and just do it. I was planning on it, but I need
another week or so to start.
2) I'm afraid we'll need to add crt[1n].o as binaries
as these are *not* shipped with the headers and libraries
of 6.2
Any comments, objections from anyone (especially for step 2) ?
>
>If it isn't true, can someone send mail to Tiemann and tell him the
>facts. Sounds like we're getting bad press.
>
>------- Forwarded Message
>
>Date: Tue, 18 Jun 1996 05:22:52 -0700
>From: Michael Tiemann <tiemann@cygnus.com>
>To: lm@sgi.com
>Subject: [comp.sys.sgi.apps] gcc part II
>
>Is this not fixed in 6.2? I upgraded my machine at home yesterday, and
>it looked suspiciously like SGI was providing headers and libraries as
>part of the std 6.2 release.
>
> From: jon@vcnet.com (Jon Rust)
> Subject: gcc part II
> Newsgroups: comp.sys.sgi.apps
> Date: Mon, 17 Jun 1996 22:25:34 -0700
> Organization: IAVC
> Path: cygnus.com!kithrup.com!news.Stanford.EDU!agate!howland.reston.ans.net
>!newsfeed.internetmci.com!in1.uu.net!news.vcnet.com!jon.vc.net!user
>Lines: 21
>Message-ID: <jon-1706962225340001@jon.vc.net>
>NNTP-Posting-Host: jon.vc.net
>X-Newsreader: Yet Another NewsWatcher 2.2.0b4
>
> Before I fly off the handle, I wanna make sure this is true.
>
> You can't build ***anything*** unless you fork over a huge wad of cash to
> SGI for their compiler and dev enviro?
>
> **If** this is true, it's horseshit. No wonder SGI is so far down the food
> chain in the land of UNIX. Buying SGI could be one of the biggest mistakes
> I've made since openning my business over 15 months ago. I wonder if my 30
> days are up. Maybe I can ship it back. I only wish I'd bought [insert any
> other UNIX platform here].
>
> If it's not true, could someone plz point me in the right direction to get
> gcc working so I can compile BIND, RADIUS, wuftpd, etc...
>
> pissed off with no build capability,
> jon
>
> --------------------------------------------------------
> Jon Rust
> Internet Access of Ventura County
> jon@vc.net http://www.vc.net 805.383.3500
>
>I know that gcc is not yet 6.2-friendly, but that's much more easily
>fixed than the library/header problem.
>
>Michael
>
>------- End of Forwarded Message
>
--
Peace, Ariel
^ permalink raw reply [relevance 1%]
* Re: anyone know if this is true?
@ 1996-06-18 17:10 1% ` Ariel Faigon
0 siblings, 0 replies; 200+ results
From: Ariel Faigon @ 1996-06-18 17:10 UTC (permalink / raw)
To: Larry McVoy; +Cc: linux, gcc, tiemann
Sadly, it *is* true. I guess many more 6.2 pissed off customers
are waiting down the pipeline.
We can solve it by getting David Miller's development environment
packaged as freeware, (it includes a GNU linker that works)
and put it (really quick) outside the firewall for whoever
is interested.
1) Someone with a couple of days of time needs to take this
and just do it. I was planning on it, but I need
another week or so to start.
2) I'm afraid we'll need to add crt[1n].o as binaries
as these are *not* shipped with the headers and libraries
of 6.2
Any comments, objections from anyone (especially for step 2) ?
>
>If it isn't true, can someone send mail to Tiemann and tell him the
>facts. Sounds like we're getting bad press.
>
>------- Forwarded Message
>
>Date: Tue, 18 Jun 1996 05:22:52 -0700
>From: Michael Tiemann <tiemann@cygnus.com>
>To: lm@sgi.com
>Subject: [comp.sys.sgi.apps] gcc part II
>
>Is this not fixed in 6.2? I upgraded my machine at home yesterday, and
>it looked suspiciously like SGI was providing headers and libraries as
>part of the std 6.2 release.
>
> From: jon@vcnet.com (Jon Rust)
> Subject: gcc part II
> Newsgroups: comp.sys.sgi.apps
> Date: Mon, 17 Jun 1996 22:25:34 -0700
> Organization: IAVC
> Path: cygnus.com!kithrup.com!news.Stanford.EDU!agate!howland.reston.ans.net
>!newsfeed.internetmci.com!in1.uu.net!news.vcnet.com!jon.vc.net!user
>Lines: 21
>Message-ID: <jon-1706962225340001@jon.vc.net>
>NNTP-Posting-Host: jon.vc.net
>X-Newsreader: Yet Another NewsWatcher 2.2.0b4
>
> Before I fly off the handle, I wanna make sure this is true.
>
> You can't build ***anything*** unless you fork over a huge wad of cash to
> SGI for their compiler and dev enviro?
>
> **If** this is true, it's horseshit. No wonder SGI is so far down the food
> chain in the land of UNIX. Buying SGI could be one of the biggest mistakes
> I've made since openning my business over 15 months ago. I wonder if my 30
> days are up. Maybe I can ship it back. I only wish I'd bought [insert any
> other UNIX platform here].
>
> If it's not true, could someone plz point me in the right direction to get
> gcc working so I can compile BIND, RADIUS, wuftpd, etc...
>
> pissed off with no build capability,
> jon
>
> --------------------------------------------------------
> Jon Rust
> Internet Access of Ventura County
> jon@vc.net http://www.vc.net 805.383.3500
>
>I know that gcc is not yet 6.2-friendly, but that's much more easily
>fixed than the library/header problem.
>
>Michael
>
>------- End of Forwarded Message
>
--
Peace, Ariel
^ permalink raw reply [relevance 1%]
* Re: anyone know if this is true?
@ 1996-06-18 17:21 1% ` Ariel Faigon
0 siblings, 0 replies; 200+ results
From: Ariel Faigon @ 1996-06-18 17:21 UTC (permalink / raw)
To: Dave Olson; +Cc: linux
>
>It's not true. All he has to do is install eoe.hdrs and compiler_eoe.hdrs.
>
Dave, I'm afraid you're misinformed. The problem is real.
Customers cannot build anything on 6.2 even if the install the above
subsystems, unless they buy our IDO.
I said it many times, to be able to build anything on 6.2
they still miss a linker (the GNU linker is not supported in
any official GNU or Cygnus releases on any SGI and we don't include
/usr/lib/crt[1n].o with our headers and libraries)
David Miller has a heavily patched working GNU linker that creates
Linux elf-32 binaries. He told me that it should be easy to
make it produce native IRIX binaries. As for the crt[1n].o files
I really hope they are not a problem to give away.
>That's just the *BASE* header files.
>
This is correct. From the point of view of the original complaint
Is not enough.
--
Peace, Ariel
^ permalink raw reply [relevance 1%]
* Re: anyone know if this is true?
@ 1996-06-18 17:21 1% ` Ariel Faigon
0 siblings, 0 replies; 200+ results
From: Ariel Faigon @ 1996-06-18 17:21 UTC (permalink / raw)
To: Dave Olson; +Cc: linux
>
>It's not true. All he has to do is install eoe.hdrs and compiler_eoe.hdrs.
>
Dave, I'm afraid you're misinformed. The problem is real.
Customers cannot build anything on 6.2 even if the install the above
subsystems, unless they buy our IDO.
I said it many times, to be able to build anything on 6.2
they still miss a linker (the GNU linker is not supported in
any official GNU or Cygnus releases on any SGI and we don't include
/usr/lib/crt[1n].o with our headers and libraries)
David Miller has a heavily patched working GNU linker that creates
Linux elf-32 binaries. He told me that it should be easy to
make it produce native IRIX binaries. As for the crt[1n].o files
I really hope they are not a problem to give away.
>That's just the *BASE* header files.
>
This is correct. From the point of view of the original complaint
Is not enough.
--
Peace, Ariel
^ permalink raw reply [relevance 1%]
* Re: anyone know if this is true?
1996-06-18 17:10 1% ` Ariel Faigon
@ 1996-06-18 17:35 1% ` Michael Tiemann
-1 siblings, 0 replies; 200+ results
From: Michael Tiemann @ 1996-06-18 17:35 UTC (permalink / raw)
To: ariel; +Cc: Larry McVoy, linux, gcc, tiemann
Hey Ariel, good to hear from you!
It sounds to me like (1) SGI intended to make GCC a viable freeware
option for Irix 6.2, (2) the support in 6.2 is not quite right, due to
slight technical problems. If I understand this correctly, then I think
it won't be too hard to fix the PR-related issues, and I'll be happy to
chime in our support for the intended solution (whatever it may be).
If SGI isn't committing to supplying a reasonable foundation to GNU (w/o
ProDev or IDO), then that's another story.
Michael
^ permalink raw reply [relevance 1%]
* Re: anyone know if this is true?
@ 1996-06-18 17:35 1% ` Michael Tiemann
0 siblings, 0 replies; 200+ results
From: Michael Tiemann @ 1996-06-18 17:35 UTC (permalink / raw)
To: ariel; +Cc: Larry McVoy, linux, gcc, tiemann
Hey Ariel, good to hear from you!
It sounds to me like (1) SGI intended to make GCC a viable freeware
option for Irix 6.2, (2) the support in 6.2 is not quite right, due to
slight technical problems. If I understand this correctly, then I think
it won't be too hard to fix the PR-related issues, and I'll be happy to
chime in our support for the intended solution (whatever it may be).
If SGI isn't committing to supplying a reasonable foundation to GNU (w/o
ProDev or IDO), then that's another story.
Michael
^ permalink raw reply [relevance 1%]
* Re: anyone know if this is true?
1996-06-18 17:21 1% ` Ariel Faigon
@ 1996-06-18 18:39 1% ` William J. Earl
-1 siblings, 0 replies; 200+ results
From: William J. Earl @ 1996-06-18 18:39 UTC (permalink / raw)
To: ariel; +Cc: Dave Olson, linux
Ariel Faigon writes:
> >
> >It's not true. All he has to do is install eoe.hdrs and compiler_eoe.hdrs.
> >
> Dave, I'm afraid you're misinformed. The problem is real.
> Customers cannot build anything on 6.2 even if the install the above
> subsystems, unless they buy our IDO.
>
> I said it many times, to be able to build anything on 6.2
> they still miss a linker (the GNU linker is not supported in
> any official GNU or Cygnus releases on any SGI and we don't include
> /usr/lib/crt[1n].o with our headers and libraries)
Those files are included only in dev.sw.lib, not in irix.sw.irix_lib.
I agree that they should be in the latter.
ld is shipped in compiler_eoe.sw.lboot, but it is located under
/usr/cpu/sysgen/root/usr/bin/.
^ permalink raw reply [relevance 1%]
* Re: anyone know if this is true?
@ 1996-06-18 18:39 1% ` William J. Earl
0 siblings, 0 replies; 200+ results
From: William J. Earl @ 1996-06-18 18:39 UTC (permalink / raw)
To: ariel; +Cc: Dave Olson, linux
Ariel Faigon writes:
> >
> >It's not true. All he has to do is install eoe.hdrs and compiler_eoe.hdrs.
> >
> Dave, I'm afraid you're misinformed. The problem is real.
> Customers cannot build anything on 6.2 even if the install the above
> subsystems, unless they buy our IDO.
>
> I said it many times, to be able to build anything on 6.2
> they still miss a linker (the GNU linker is not supported in
> any official GNU or Cygnus releases on any SGI and we don't include
> /usr/lib/crt[1n].o with our headers and libraries)
Those files are included only in dev.sw.lib, not in irix.sw.irix_lib.
I agree that they should be in the latter.
ld is shipped in compiler_eoe.sw.lboot, but it is located under
/usr/cpu/sysgen/root/usr/bin/.
^ permalink raw reply [relevance 1%]
* gcc solution looks plausible (was: anyone know if this is true?)
[not found] <199606182106.OAA15730@anchor.engr.sgi.com>
@ 1996-06-18 23:23 1% ` Ariel Faigon
0 siblings, 0 replies; 200+ results
From: Ariel Faigon @ 1996-06-18 23:23 UTC (permalink / raw)
To: Dave Olson; +Cc: gcc, linux
[I'm Ccing gcc@corp and linux@engr, some more people may be happy to hear this]
Dave Olson wrote to me about 'ld':
>
>The one in /var/sysgen/root is the same one that driverwrap invokes.
>
>There are two ld's, the one in usr/lib, and the one in usr/bin. They
>are different. There is a one to one match between /usr/bin/ld and
>/var/sysgen/root/usr/bin/ld, and similarly for /usr/lib/ld and
>/var/sysgen/root/ld
>
>(assuming a 32 bit system)
>
Thanks! that's encouraging.
I assume this means that I should install two symlinks:
/usr/freeware/bin/ld -> /var/sysgen/root/usr/bin/ld
/usr/freeware/lib/gcc-lib/mips-sgi-irixX.Y/2.7.2/ld -> /var/sysgen/root/ld
Or something close to this.
This plus building gcc -with-gnu-as, using -32 -old_ld in the specs file
and Bean's permission to package crt[1n].o should solve all the problems
I'm aware of and make many customers happy.
That was very helpful. Looks like a solution is close. Thanks again.
--
Peace, Ariel
^ permalink raw reply [relevance 1%]
* gcc solution looks plausible (was: anyone know if this is true?)
@ 1996-06-18 23:23 1% ` Ariel Faigon
0 siblings, 0 replies; 200+ results
From: Ariel Faigon @ 1996-06-18 23:23 UTC (permalink / raw)
To: Dave Olson; +Cc: gcc, linux
[I'm Ccing gcc@corp and linux@engr, some more people may be happy to hear this]
Dave Olson wrote to me about 'ld':
>
>The one in /var/sysgen/root is the same one that driverwrap invokes.
>
>There are two ld's, the one in usr/lib, and the one in usr/bin. They
>are different. There is a one to one match between /usr/bin/ld and
>/var/sysgen/root/usr/bin/ld, and similarly for /usr/lib/ld and
>/var/sysgen/root/ld
>
>(assuming a 32 bit system)
>
Thanks! that's encouraging.
I assume this means that I should install two symlinks:
/usr/freeware/bin/ld -> /var/sysgen/root/usr/bin/ld
/usr/freeware/lib/gcc-lib/mips-sgi-irixX.Y/2.7.2/ld -> /var/sysgen/root/ld
Or something close to this.
This plus building gcc -with-gnu-as, using -32 -old_ld in the specs file
and Bean's permission to package crt[1n].o should solve all the problems
I'm aware of and make many customers happy.
That was very helpful. Looks like a solution is close. Thanks again.
--
Peace, Ariel
^ permalink raw reply [relevance 1%]
* Kernel doesn't work on 200MHz Indy
@ 1996-06-20 11:02 1% Alistair Lambie
1996-06-20 18:12 1% ` William J. Earl
0 siblings, 1 reply; 200+ results
From: Alistair Lambie @ 1996-06-20 11:02 UTC (permalink / raw)
To: linux
Just incase anyone is interested:
I was able to boot Davids kernel on my Indy when I only had a 100MHz R4600PC,
but know I've upgraded to a 200MHz R4400SC it dies! Looks like something
to do with the memory controller...
Here goes a bit of what comes out:
Bad pmd in pte_alloc_kernel: 00000000
Double fault caused by invalid entries in pgd:
Double fault address : ffffffffe4000000
c0_epc : ffffffff88093ebc
Of course there was heaps more, but I couldn't get cut and paste to work :-)
I haven't had time to have a look at what's going on yet.
Cheers, Alistair
PS - It only gives a BogoMIPS reading of 103.63, which is around what I got
when it was a 100MHz chip.
^ permalink raw reply [relevance 1%]
* Re: Kernel doesn't work on 200MHz Indy
1996-06-20 11:02 1% Kernel doesn't work on 200MHz Indy Alistair Lambie
@ 1996-06-20 18:12 1% ` William J. Earl
0 siblings, 0 replies; 200+ results
From: William J. Earl @ 1996-06-20 18:12 UTC (permalink / raw)
To: Alistair Lambie; +Cc: linux
Alistair Lambie writes:
> Just incase anyone is interested:
>
> I was able to boot Davids kernel on my Indy when I only had a 100MHz R4600PC,
> but know I've upgraded to a 200MHz R4400SC it dies! Looks like something
> to do with the memory controller...
There is no way the kernel could work on an R4000 or R4400 without
changes to the cache routines, as well as the addition of certain workarounds
for processor errata. Stick to R4600 and R5000 processors for the time being.
I asked David to start with the R4600, because the workarounds for the errata
are far simpler, and because it and the R5000 are the volume processors for
Indy. It will not be all that hard to add R4000 and R4400 support, but there
are several messy workarounds to implement, so it is more interesting to get
a complete system working on an R4600 or R5000.
...
> PS - It only gives a BogoMIPS reading of 103.63, which is around what I got
> when it was a 100MHz chip.
That is to be expected. BogoMIPS is essentiall 2 times the number of
times one can execute a loop like this:
la a0,0x7FFFFFFF
1: bltz a0,1b
addu a0,-1
On an R3000, R4600, or R5000, the branch executes in two cycles (counting one
for the branch delay slot), so BogoMIPS equals the processor clock rate.
On an R4000 or R4400, the branch executes in four cycles (counting one for
the branch delay slot), so BogoMIPS equals one half the processor clock rate.
There appears to be a small error in the current logic for calibrating
the processor clock rate, which accounts for the BogoMIPS being 103.63 instead
of 100.00.
^ permalink raw reply [relevance 1%]
* Re: Kernel doesn't work on 200MHz Indy
@ 1996-06-20 18:12 1% ` William J. Earl
0 siblings, 0 replies; 200+ results
From: William J. Earl @ 1996-06-20 18:12 UTC (permalink / raw)
To: Alistair Lambie; +Cc: linux
Alistair Lambie writes:
> Just incase anyone is interested:
>
> I was able to boot Davids kernel on my Indy when I only had a 100MHz R4600PC,
> but know I've upgraded to a 200MHz R4400SC it dies! Looks like something
> to do with the memory controller...
There is no way the kernel could work on an R4000 or R4400 without
changes to the cache routines, as well as the addition of certain workarounds
for processor errata. Stick to R4600 and R5000 processors for the time being.
I asked David to start with the R4600, because the workarounds for the errata
are far simpler, and because it and the R5000 are the volume processors for
Indy. It will not be all that hard to add R4000 and R4400 support, but there
are several messy workarounds to implement, so it is more interesting to get
a complete system working on an R4600 or R5000.
...
> PS - It only gives a BogoMIPS reading of 103.63, which is around what I got
> when it was a 100MHz chip.
That is to be expected. BogoMIPS is essentiall 2 times the number of
times one can execute a loop like this:
la a0,0x7FFFFFFF
1: bltz a0,1b
addu a0,-1
On an R3000, R4600, or R5000, the branch executes in two cycles (counting one
for the branch delay slot), so BogoMIPS equals the processor clock rate.
On an R4000 or R4400, the branch executes in four cycles (counting one for
the branch delay slot), so BogoMIPS equals one half the processor clock rate.
There appears to be a small error in the current logic for calibrating
the processor clock rate, which accounts for the BogoMIPS being 103.63 instead
of 100.00.
^ permalink raw reply [relevance 1%]
* Re: Kernel doesn't work on 200MHz Indy
1996-06-20 18:12 1% ` William J. Earl
(?)
@ 1996-06-21 7:48 1% ` David S. Miller
-1 siblings, 0 replies; 200+ results
From: David S. Miller @ 1996-06-21 7:48 UTC (permalink / raw)
To: wje; +Cc: alambie, linux
Date: Thu, 20 Jun 1996 11:12:17 -0700
From: wje@fir.esd.sgi.com (William J. Earl)
There is no way the kernel could work on an R4000 or R4400
without changes to the cache routines, as well as the addition of
certain workarounds for processor errata. Stick to R4600 and R5000
processors for the time being. I asked David to start with the
R4600, because the workarounds for the errata are far simpler, and
because it and the R5000 are the volume processors for Indy. It
will not be all that hard to add R4000 and R4400 support, but there
are several messy workarounds to implement, so it is more
interesting to get a complete system working on an R4600 or R5000.
Heh, I go the the UK and people are trying my kernel out all over the
place. This is good.
I will work on the issues necessary for R4[40]00 processor support
certainly. Take note that I worked to get a shell prompt on my target
machine "by all means necessary" as quickly as possible so that I
could have an early proof of concept to show everyone. With this
there are some hard coded items in the tree that need to be attended
to, but I should be able to get it all to work. One notable thing is
that machines not equipped with NEWPORT graphics cards, and instead
possess an INDY with the older EXPRESS graphics card, will not be able
to get things working until I get the serial console up or I write a
driver for the EXPRESS. Both will happen in due time.
As you can see I am back from the UK, and will try to get back on
track this weekend.
Later,
David S. Miller
dm@sgi.com
^ permalink raw reply [relevance 1%]
* what I am up to...
@ 1996-06-23 3:19 1% David S. Miller
0 siblings, 0 replies; 200+ results
From: David S. Miller @ 1996-06-23 3:19 UTC (permalink / raw)
To: linux
I've just checked in last night an initial serial driver for the
INDY. Since this machine (as do some other SGI's) have the Zilog85C30
on board, I just took my Sparc driver and hacked it a little.
Currently it works well as the console, and some initial tests with
KGDB show that it is ok for the KGDB packets as well. KGDB needs some
work on the host end of things before I can use it very much.
I'm cleaning up the source tree. The end result will hopefully be a
single kernel which can work flawlessly on any Mips CPU variant. I
know what need to be done for this to work. In the end the goal is to
be able to fire up the same Linux kernel on _any_ SGI piece of
hardware and it just works, just like the Sparc kernel does.
More to come...
Later,
David S. Miller
dm@sgi.com
^ permalink raw reply [relevance 1%]
* External Linux/MIPS list
@ 1996-06-24 22:43 1% ` Ariel Faigon
0 siblings, 0 replies; 200+ results
From: Ariel Faigon @ 1996-06-24 22:43 UTC (permalink / raw)
To: linux
In order to prevent confidential data leaks (like random mentions
of Speedracer or Lego), and in order to build critical-mass support
to the Linux port outside SGI. I have created a separate linux mailing list
for non-SGI interested parties. It seems that there is a lot of interest
outside SGI from people who may be important assets for the Linux/MIPS
effort in the future. People who sell Linux CDROMs, talented developers,
etc.
I enclose the welcome message for your reference.
if you feel you know someone nice outside who you think should be
on this list (and they agree) just subscribe them by mailing to:
external-majordomo@postofc.corp.sgi.com
with body:
subscribe linuxmips their@email.address
Once we have enough people on that list, I will send a short summary
of the current status to them.
Please:
1) Don't mix between
linux@engr (our internal list)
and
linuxmips@corp (free for all)
[The list-names are different on purpose.]
2) Feel free to Cc linuxmips@corp on any message that doesn't
contain SGI confidential data.
--
Peace, Ariel
----- Forwarded message from MAILMAN@palladium.corp.sgi.com -----
From owner-linuxmips-outgoing@palladium.corp.sgi.com Mon Jun 24 15:25:28 1996
Date: Mon, 24 Jun 1996 15:26:21 -0700
Message-Id: <199606242226.PAA11036@palladium.corp.sgi.com>
To: linuxmips@palladium.corp.sgi.com
Subject: Welcome to linuxmips
From: MAILMAN@palladium.corp.sgi.com
Sender: owner-linuxmips@palladium.corp.sgi.com
Precedence: bulk
Reply-To: MAILMAN@palladium.corp.sgi.com
Welcome to the linuxmips mailing list!
To unsubscribe from this list send email to:
external-majordomo@postofc.corp.sgi.com
with the following line in the _body_ of the message:
unsubscribe linuxmips _your_email_address_here_
To post a message to this mailing list use this address:
linuxmips@postofc.corp.sgi.com
Here's some general information for the linuxmips mailing list:
Welcome to the linuxmips mailing list !
linuxmips@corp.sgi.com
linuxmips will be used to update interested parties
not affiliated with SGI on the status of the ongoing
Linux/MIPS port within SGI.
Thanks to the Linux/MIPS effort going on in Germany
(thanks guys!) and to David Miller's summer's internship at SGI
we expect Linux soon to be running on many SGI platforms and be
able to run IRIX binaries.
We intend to release the port under the GPL as a part
of mainstream Linux and hope that other Linux/MIPS
enthusiasts will join the effort once the first step
is done and released to the net.
Feel free to tell your friends about this list.
-- Ariel (ariel@sgi.com)
----- End of forwarded message from MAILMAN@palladium.corp.sgi.com -----
^ permalink raw reply [relevance 1%]
* External Linux/MIPS list
@ 1996-06-24 22:43 1% ` Ariel Faigon
0 siblings, 0 replies; 200+ results
From: Ariel Faigon @ 1996-06-24 22:43 UTC (permalink / raw)
To: linux
In order to prevent confidential data leaks (like random mentions
of Speedracer or Lego), and in order to build critical-mass support
to the Linux port outside SGI. I have created a separate linux mailing list
for non-SGI interested parties. It seems that there is a lot of interest
outside SGI from people who may be important assets for the Linux/MIPS
effort in the future. People who sell Linux CDROMs, talented developers,
etc.
I enclose the welcome message for your reference.
if you feel you know someone nice outside who you think should be
on this list (and they agree) just subscribe them by mailing to:
external-majordomo@postofc.corp.sgi.com
with body:
subscribe linuxmips their@email.address
Once we have enough people on that list, I will send a short summary
of the current status to them.
Please:
1) Don't mix between
linux@engr (our internal list)
and
linuxmips@corp (free for all)
[The list-names are different on purpose.]
2) Feel free to Cc linuxmips@corp on any message that doesn't
contain SGI confidential data.
--
Peace, Ariel
----- Forwarded message from MAILMAN@palladium.corp.sgi.com -----
>From owner-linuxmips-outgoing@palladium.corp.sgi.com Mon Jun 24 15:25:28 1996
Date: Mon, 24 Jun 1996 15:26:21 -0700
Message-Id: <199606242226.PAA11036@palladium.corp.sgi.com>
To: linuxmips@palladium.corp.sgi.com
Subject: Welcome to linuxmips
From: MAILMAN@palladium.corp.sgi.com
Sender: owner-linuxmips@palladium.corp.sgi.com
Precedence: bulk
Reply-To: MAILMAN@palladium.corp.sgi.com
Welcome to the linuxmips mailing list!
To unsubscribe from this list send email to:
external-majordomo@postofc.corp.sgi.com
with the following line in the _body_ of the message:
unsubscribe linuxmips _your_email_address_here_
To post a message to this mailing list use this address:
linuxmips@postofc.corp.sgi.com
Here's some general information for the linuxmips mailing list:
Welcome to the linuxmips mailing list !
linuxmips@corp.sgi.com
linuxmips will be used to update interested parties
not affiliated with SGI on the status of the ongoing
Linux/MIPS port within SGI.
Thanks to the Linux/MIPS effort going on in Germany
(thanks guys!) and to David Miller's summer's internship at SGI
we expect Linux soon to be running on many SGI platforms and be
able to run IRIX binaries.
We intend to release the port under the GPL as a part
of mainstream Linux and hope that other Linux/MIPS
enthusiasts will join the effort once the first step
is done and released to the net.
Feel free to tell your friends about this list.
-- Ariel (ariel@sgi.com)
----- End of forwarded message from MAILMAN@palladium.corp.sgi.com -----
^ permalink raw reply [relevance 1%]
* Userland binaries
@ 1996-06-25 13:35 1% Alistair Lambie
1996-06-25 13:44 1% ` David S. Miller
0 siblings, 1 reply; 200+ results
From: Alistair Lambie @ 1996-06-25 13:35 UTC (permalink / raw)
To: linux
Being miles away in New Zealand it is kind of hard to know who is doing what!
I have been playing around with cross compiling userland binaries. But before
I get carried away here are some questions:
1. Is anyone already doing this?
2. Should we set up a repository so we don't all spend our time doing the same
thing?
3. I have used the the cross compiler from ftp.fnet.fr. The libc I have used
is
the gnu one that has just appeared on ftp.fnet.fr in the last week. Are
these the right ones to be using (they only allow static linking)?
4. If several people are doing this maybe we should coordinate the effort so
we don't all do the same packages.
That should be enough questions for this week :-)
Cheers, Alistair
--
Alistair Lambie alambie@wellington.sgi.com
Silicon Graphics New Zealand SGI Voicemail: 56791
Level 5, Walsh Wrightson Tower, Ph: +64-4-802 1455
94-96 Dixon St, Wellington, NZ Fax: +64-4-802 1459
^ permalink raw reply [relevance 1%]
* Re: Userland binaries
1996-06-25 13:35 1% Userland binaries Alistair Lambie
@ 1996-06-25 13:44 1% ` David S. Miller
[not found] ` <dm@neteng.engr.sgi.com>
0 siblings, 1 reply; 200+ results
From: David S. Miller @ 1996-06-25 13:44 UTC (permalink / raw)
To: alambie; +Cc: linux
From: "Alistair Lambie" <alambie@wellington.sgi.com>
Date: Tue, 25 Jun 1996 13:35:33 +0000
Being miles away in New Zealand it is kind of hard to know who is
doing what!
I wasn't far from there last week ;-) (for those who do not know I
gave two talks in Manchester England last week)
I have been playing around with cross compiling userland binaries.
But before I get carried away here are some questions:
1. Is anyone already doing this?
Not that I know of.
2. Should we set up a repository so we don't all spend our time
doing the same
thing?
Good idea.
3. I have used the the cross compiler from ftp.fnet.fr. The libc I
have used is
the gnu one that has just appeared on ftp.fnet.fr in the last
week. Are these the right ones to be using (they only allow
static linking)?
This should be correct. That libc snapshot probably only does static
binaries, the developers have initial 'hello world' type shared
binaries working from what I hear so expect some more about this
soon. I'll update the list on any progress on shared libraries I hear
about myself.
4. If several people are doing this maybe we should coordinate the
effort so
we don't all do the same packages.
Another good idea. ;-)
Later,
David S. Miller
dm@sgi.com
^ permalink raw reply [relevance 1%]
* Re: Userland binaries
[not found] ` <dm@neteng.engr.sgi.com>
@ 1996-06-28 10:47 1% ` Alistair Lambie
0 siblings, 0 replies; 200+ results
From: Alistair Lambie @ 1996-06-28 10:47 UTC (permalink / raw)
To: dm, alambie; +Cc: linux
On Jun 26, 1:44am, David S. Miller wrote:
> Subject: Re: Userland binaries
> From: "Alistair Lambie" <alambie@wellington.sgi.com>
> Date: Tue, 25 Jun 1996 13:35:33 +0000
>
> Being miles away in New Zealand it is kind of hard to know who is
> doing what!
>
> I wasn't far from there last week ;-) (for those who do not know I
> gave two talks in Manchester England last week)
>
Yeah...only another 24 hours flying and you too could have been here.
> I have been playing around with cross compiling userland binaries.
> But before I get carried away here are some questions:
>
> 1. Is anyone already doing this?
>
> Not that I know of.
>
Judging by the resounding silence I guess you are correct!
> 2. Should we set up a repository so we don't all spend our time
> doing the same
> thing?
>
> Good idea.
>
Can someone point me at a place (I could host here, but it seems crazy for
everyone to try suck everything up a 64k pipe...of course this assumes that
people are actually interested!!).
> 4. If several people are doing this maybe we should coordinate the
> effort so
> we don't all do the same packages.
>
> Another good idea. ;-)
So far I've done sh-utils and file-utils. Next I'm planning on SYSVinit and
whatever packages have getty/login/security. Then some more shells and an
editor. I guess after that the next thing might be some of the networking
stuff.
I'm using the RedHat SRPMS for this, and applying their patches unless they are
platform specific. Does anyone have any wild objections to this?
Also, what format would people prefer for packages...just tar.gz or RPM?
(guess this also raises the point that I need to do some binaries to deal with
however we package things!)
Cheers, Alistair
--
Alistair Lambie alambie@wellington.sgi.com
Silicon Graphics New Zealand SGI Voicemail: 56791
Level 5, Walsh Wrightson Tower, Ph: +64-4-802 1455
94-96 Dixon St, Wellington, NZ Fax: +64-4-802 1459
^ permalink raw reply [relevance 1%]
* NIS rarpd entries
@ 1996-06-29 7:07 1% David S. Miller
0 siblings, 0 replies; 200+ results
From: David S. Miller @ 1996-06-29 7:07 UTC (permalink / raw)
To: linux
When I'm booting my test box I have to run a bogus hacked up copy of
rarpd because the NIS maps in my domain don't have an ethers entry for
stacey.engr
What is a better way of dealing with this?
Later,
David S. Miller
dm@sgi.com
^ permalink raw reply [relevance 1%]
* NIS rarpd entries (fwd)
@ 1996-06-30 1:26 1% ` Ariel Faigon
0 siblings, 0 replies; 200+ results
From: Ariel Faigon @ 1996-06-30 1:26 UTC (permalink / raw)
To: Demetrio Pinto; +Cc: linux
Demetrio,
Will it be possible to add an ethers entry for stacey.engr
to our ypmaps ? Thanks!
If yes, David, could you send Demetrio the ethernet address ?
----- Forwarded message from David S. Miller -----
From owner-linux@cthulhu Sat Jun 29 00:07:01 1996
Date: Sat, 29 Jun 1996 00:07:52 -0700
Message-Id: <199606290707.AAA17304@neteng.engr.sgi.com>
From: "David S. Miller" <dm@neteng>
To: linux@neteng
Subject: NIS rarpd entries
Reply-to: dm@sgi.com
Sender: owner-linux@cthulhu
Precedence: bulk
When I'm booting my test box I have to run a bogus hacked up copy of
rarpd because the NIS maps in my domain don't have an ethers entry for
stacey.engr
What is a better way of dealing with this?
Later,
David S. Miller
dm@sgi.com
----- End of forwarded message from David S. Miller -----
--
Peace, Ariel
^ permalink raw reply [relevance 1%]
* NIS rarpd entries (fwd)
@ 1996-06-30 1:26 1% ` Ariel Faigon
0 siblings, 0 replies; 200+ results
From: Ariel Faigon @ 1996-06-30 1:26 UTC (permalink / raw)
To: Demetrio Pinto; +Cc: linux
Demetrio,
Will it be possible to add an ethers entry for stacey.engr
to our ypmaps ? Thanks!
If yes, David, could you send Demetrio the ethernet address ?
----- Forwarded message from David S. Miller -----
>From owner-linux@cthulhu Sat Jun 29 00:07:01 1996
Date: Sat, 29 Jun 1996 00:07:52 -0700
Message-Id: <199606290707.AAA17304@neteng.engr.sgi.com>
From: "David S. Miller" <dm@neteng>
To: linux@neteng
Subject: NIS rarpd entries
Reply-to: dm@sgi.com
Sender: owner-linux@cthulhu
Precedence: bulk
When I'm booting my test box I have to run a bogus hacked up copy of
rarpd because the NIS maps in my domain don't have an ethers entry for
stacey.engr
What is a better way of dealing with this?
Later,
David S. Miller
dm@sgi.com
----- End of forwarded message from David S. Miller -----
--
Peace, Ariel
^ permalink raw reply [relevance 1%]
* wheee, irix binaries...
@ 1996-07-01 12:28 1% David S. Miller
0 siblings, 0 replies; 200+ results
From: David S. Miller @ 1996-07-01 12:28 UTC (permalink / raw)
To: linux
Well, it at least appears that I have a stock IRIX 'sed' binary
working. The initial framework for IRIX syscall compatability is in
the tree now and I will just whack away at this until most
'reasonable' binaries work.
For those who are wondering, sproc() shouldn't even be that hard
believe it or not, in fact I am told someone out there in linux land
has already written the kernel code for preliminary support.
Later,
David S. Miller
dm@sgi.com
^ permalink raw reply [relevance 1%]
* Re: NIS rarpd entries (fwd)
1996-06-30 1:26 1% ` Ariel Faigon
@ 1996-07-01 18:26 0% ` Demetrio Pinto
-1 siblings, 0 replies; 200+ results
From: Demetrio Pinto @ 1996-07-01 18:26 UTC (permalink / raw)
To: ariel; +Cc: Demetrio Pinto, linux
Ariel,
David,
On Jun 29, 6:26pm, Ariel Faigon wrote:
> Subject: NIS rarpd entries (fwd)
> Demetrio,
>
> Will it be possible to add an ethers entry for stacey.engr
> to our ypmaps ?
stacey is ALREADY in the YP hosts maps
demi 39# ypmatch stacey.engr hosts
150.166.75.5 stacey.engr.sgi.com
demi 40#
(BTW, 150.166.75 is one of the NetWork Group nets.)
> Thanks!
>
> If yes, David, could you send Demetrio the ethernet address ?
>
>
> ----- Forwarded message from David S. Miller -----
>
> >From owner-linux@cthulhu Sat Jun 29 00:07:01 1996
> Date: Sat, 29 Jun 1996 00:07:52 -0700
> Message-Id: <199606290707.AAA17304@neteng.engr.sgi.com>
> From: "David S. Miller" <dm@neteng>
> To: linux@neteng
> Subject: NIS rarpd entries
> Reply-to: dm@sgi.com
> Sender: owner-linux@cthulhu
> Precedence: bulk
>
>
> When I'm booting my test box I have to run a bogus hacked up copy of
> rarpd because the NIS maps in my domain don't have an ethers entry for
> stacey.engr
This is from your system
tanya 2% ypmatch stacey hosts
150.166.75.5 stacey.engr.sgi.com stacey
tanya 3%
Demetrio
>
> What is a better way of dealing with this?
>
> Later,
> David S. Miller
> dm@sgi.com
>
> ----- End of forwarded message from David S. Miller -----
>
> --
> Peace, Ariel
>-- End of excerpt from Ariel Faigon
^ permalink raw reply [relevance 0%]
* Re: NIS rarpd entries (fwd)
@ 1996-07-01 18:26 0% ` Demetrio Pinto
0 siblings, 0 replies; 200+ results
From: Demetrio Pinto @ 1996-07-01 18:26 UTC (permalink / raw)
To: ariel; +Cc: Demetrio Pinto, linux
Ariel,
David,
On Jun 29, 6:26pm, Ariel Faigon wrote:
> Subject: NIS rarpd entries (fwd)
> Demetrio,
>
> Will it be possible to add an ethers entry for stacey.engr
> to our ypmaps ?
stacey is ALREADY in the YP hosts maps
demi 39# ypmatch stacey.engr hosts
150.166.75.5 stacey.engr.sgi.com
demi 40#
(BTW, 150.166.75 is one of the NetWork Group nets.)
> Thanks!
>
> If yes, David, could you send Demetrio the ethernet address ?
>
>
> ----- Forwarded message from David S. Miller -----
>
> >From owner-linux@cthulhu Sat Jun 29 00:07:01 1996
> Date: Sat, 29 Jun 1996 00:07:52 -0700
> Message-Id: <199606290707.AAA17304@neteng.engr.sgi.com>
> From: "David S. Miller" <dm@neteng>
> To: linux@neteng
> Subject: NIS rarpd entries
> Reply-to: dm@sgi.com
> Sender: owner-linux@cthulhu
> Precedence: bulk
>
>
> When I'm booting my test box I have to run a bogus hacked up copy of
> rarpd because the NIS maps in my domain don't have an ethers entry for
> stacey.engr
This is from your system
tanya 2% ypmatch stacey hosts
150.166.75.5 stacey.engr.sgi.com stacey
tanya 3%
Demetrio
>
> What is a better way of dealing with this?
>
> Later,
> David S. Miller
> dm@sgi.com
>
> ----- End of forwarded message from David S. Miller -----
>
> --
> Peace, Ariel
>-- End of excerpt from Ariel Faigon
^ permalink raw reply [relevance 0%]
* (Fwd) Re: SGI/MIPS Linux port status
@ 1996-07-02 10:13 1% Alistair Lambie
0 siblings, 0 replies; 200+ results
From: Alistair Lambie @ 1996-07-02 10:13 UTC (permalink / raw)
To: linux
Folks,
I ping'ed Ralf about shared GNU libc for big endian machines. At the end of
his reply he asks for some info to help him. I'm not sure if he is on the
list of blessed people or not, and I suspect there are some others who would
be far more able to answer his question than myself.
Can someone follow this up.....(Ariel, Larry, Bill ???)
Cheers, Alistair
--- Forwarded mail from Ralf Baechle <ralf@Julia.DE>
From: Ralf Baechle <ralf@Julia.DE>
Subject: Re: SGI/MIPS Linux port status
To: alambie@wellington.sgi.com (Alistair Lambie)
Date: Mon, 1 Jul 1996 23:54:00 +0200 (MET DST)
Hi,
> > The even better news is that I've started to rebuild my entire system
> > using ELF shared libraries. I'll try to make first alpha release of
> > shared library binaries tomorrow for little endian binaries (the above
> > mentioned machines are all little endian); I'll try to generate big
> > endian libs as soon as possible.
> >
> I have been building up a core set of binaries for us to use on the SGI
boxes.
> These are of course big endian, and naturally HUGE because they are
statically
> linked!
I know how big your binaries are - after all I'm still using a mostly
static linked system also. So I assume that your /bin/ls is also about
15 times the size of the i486-linux shared /bin/ls ...
Can you let me know when you have big endian shared libs so I can
have
> something a little more sane to deal with.
I'm rebulding my entire toolchain for big endian. This night I should find
the time to rebuild the libs, also.
> BTW, I assume that you are using GNU libc?
Yes, I'm using GNU libc snapshot 960619. Linux libc is lacking tons of code
required for MIPS fp support. The problem is simply that MIPS only has the
capabilities to add, subtract, multiply and divide in hardware, some FPUs
can do sqrt() while Intel/68881/68882 can do many complex computations in
hardware. Also HJ's way to maintain the code and the code itself made it
a bit of a pain to use Linux libc ...
On which libc is your SGI stuff based? Also I'm trying to make my work
as SGI-ish as possible. I don't have access to a SGI or documentation but
have some questions about IRIX regarding the shared lib stuff, PIC code
and more. Can you help me?
Happy hacking,
Ralf
---End of forwarded mail from Ralf Baechle <ralf@Julia.DE>
--
Alistair Lambie alambie@wellington.sgi.com
Silicon Graphics New Zealand SGI Voicemail: 56791
Level 5, Walsh Wrightson Tower, Ph: +64-4-802 1455
94-96 Dixon St, Wellington, NZ Fax: +64-4-802 1459
^ permalink raw reply [relevance 1%]
* (Fwd) Libraries uploaded
@ 1996-07-04 12:26 1% Alistair Lambie
1996-07-04 0:29 1% ` David S. Miller
0 siblings, 1 reply; 200+ results
From: Alistair Lambie @ 1996-07-04 12:26 UTC (permalink / raw)
To: linux
David,
Looks like the new GNU libc stuff needs a newer kernel. Do you have any plans
to roll to a later one in the near future?
Cheers, Alistair
--- Forwarded mail from Systemkennung Linux <linux@mailhost.uni-koblenz.de>
From: Systemkennung Linux <linux@mailhost.uni-koblenz.de>
Subject: Libraries uploaded
To: linux-mips@fnet.fr, linuxmips@palladium.corp.sgi.com
Date: Wed, 3 Jul 1996 15:45:53 +0200 (MET DST)
Reply-To: Systemkennung Linux <linux@mailhost.uni-koblenz.de>
-----BEGIN PGP SIGNED MESSAGE-----
Hi all,
I've uploaded the first shared library binaries for Linux/MIPS to ftp.fnet.fr
where they'll appear in /linux-mips/ as soon as someone has moved them online.
The binaries are based on GNU libc snapshot 960619.
In order to use these libraries you also have to:
- Run Linux/MIPS kernel version 2.0.1 or newer. I'll upload this one rsn.
- Install new binutils and GCC. These are yet unreleased; I'll release the
patches rsn. This is necessary even if you link your programs static only
because on MIPS even the static archives contain PIC code which the current
binutils can't handle.
The dynamic linker clearly still has alpha status; expect to see all sorts of
bugs. The little endian binaries are those that I use on my system. I
provide the big endian binaries untested and in the hope that they'll be
usefull.
Ralf
e015d5d14cd2d9d38c30a01eafc6628f mips-linuxelf/libc-960619-2.tar.gz
c23155bfbb0a62a119cc2ffae9d54b50 mipsel-linuxelf/libc-960619-2.tar.gz
-----BEGIN PGP SIGNATURE-----
Version: 2.6.2
iQCVAgUBMdp5jUckbl6vezDBAQFqQgP/Vla+a6jK9D5A6xReNq2jTwI0HZdaAI1U
qKQIfq2Q7sSOau4liKpxSTsIg92MG5nmKy4k1lJNAWW0sUwsWFs+JBN1/h7kggcb
2CufsNMju0K5le257ykGe5BmVK27tNzC/SibAU8LVfV2+AehBN+VTdZAAbxWxsnn
7vvgro2IXCg=
=uDU6
-----END PGP SIGNATURE-----
---End of forwarded mail from Systemkennung Linux
<linux@mailhost.uni-koblenz.de>
--
Alistair Lambie alambie@wellington.sgi.com
Silicon Graphics New Zealand SGI Voicemail: 56791
Level 5, Walsh Wrightson Tower, Ph: +64-4-802 1455
94-96 Dixon St, Wellington, NZ Fax: +64-4-802 1459
^ permalink raw reply [relevance 1%]
* Re: (Fwd) Libraries uploaded
1996-07-04 12:26 1% (Fwd) Libraries uploaded Alistair Lambie
@ 1996-07-04 0:29 1% ` David S. Miller
0 siblings, 0 replies; 200+ results
From: David S. Miller @ 1996-07-04 0:29 UTC (permalink / raw)
To: alambie; +Cc: linux
From: "Alistair Lambie" <alambie@wellington.sgi.com>
Date: Thu, 4 Jul 1996 12:26:56 +0000
Looks like the new GNU libc stuff needs a newer kernel. Do you
have any plans to roll to a later one in the near future?
I'll perform a full merge this evening, will certainly be more fun
than IRIX syscall compatability stuff I am working on now ;-)
Later,
David S. Miller
dm@sgi.com
^ permalink raw reply [relevance 1%]
Results 1-200 of ~16000000 next (newer) | reverse | options above
-- pct% links below jump to the message on this page, permalinks otherwise --
1971-10-18 4:33 1% [linux-lvm] lvmcreate_initrd and then? Richard Heider jr
1980-01-03 23:15 0% [LARTC] few doubts about the working of tc Stef Coene
1980-01-03 23:20 0% [LARTC] bandwidth shaping problem Stef Coene
1980-01-03 23:20 1% [LARTC] FW: Rate goes over setting Stef Coene
1980-01-03 23:28 0% [LARTC] Measurement &monitoring tool Stef Coene
1980-01-03 23:36 0% [LARTC] "weight" parameter in htb? Stef Coene
1980-01-05 0:45 0% [LARTC] Hosting script Stef Coene
1980-01-05 2:14 1% ` Stef Coene
1980-01-05 2:41 1% ` Stef Coene
1980-02-15 16:10 1% so resuming is same Rosanne Oliver
1980-02-17 4:22 1% Or or mammoth Therese Mills
1980-10-18 19:22 7% Does anybody knows Gary Thomas? Andres A. Buss
1988-01-04 21:45 1% bathos chevy AElbert XManuel
1990-04-10 12:31 1% Not by mansion Rae Hoffman
1990-10-04 2:28 1% At nylon untill inconvenient Mercedes Hood
1991-08-25 20:57 1% What would you like to see most in minix? Linus Benedict Torvalds
[not found] <199904140459.XAA29688@lists.linuxppc.org>
1995-05-01 19:12 1% ` LinuxPPC and BTTV : new things Lucas Vergnettes
1996-02-24 10:21 1% Welcome to linux Majordomo
1996-02-28 18:16 4% a chuckle for you Larry McVoy
1996-02-29 18:26 1% kernel hacking noise Larry McVoy
1996-02-29 23:33 8% WWW: Linux in High-Performance Computing (fwd) Bruce A. Templeton
1996-03-01 6:39 1% ./lat_syscall David S. Miller
1996-03-09 3:33 1% Some material for thought Ariel Faigon
1996-03-10 2:03 1% Linux 1.3.71 lmbench on Sparc David S. Miller
1996-03-10 6:09 1% [tridge@cs.anu.edu.au: Linux on the AP+ - progress!] David S. Miller
1996-03-14 10:21 1% Oh baby David S. Miller
1996-03-16 4:45 1% He he he Larry McVoy
1996-03-16 11:59 1% you want numbers? I got numbers David S. Miller
1996-03-17 13:00 1% whee David S. Miller
1996-03-17 21:07 1% ` whee David C. Niemi
1996-03-18 11:14 5% 1.3.75 is a little better David S. Miller
1996-03-18 14:08 1% ccpenguin David S. Miller
1996-03-19 21:22 1% holy shit David S. Miller
1996-03-27 2:58 1% it keeps going and going and David S. Miller
1996-04-01 12:42 1% SYMMMMETRRRRIC MULTI PENGUINNNNNNN!!!!!! David S. Miller
1996-04-02 2:01 0% ` John Vozza
1996-04-07 5:36 1% ho hum David S. Miller
1996-04-16 0:02 1% HyperSparc UP numbers David S. Miller
1996-04-17 22:05 1% (fwd) USELINUX: Linux Applications Development and Deployment Conference Larry McVoy
1996-04-18 7:28 1% SMP wheee David S. Miller
1996-04-18 10:03 1% SMP, yeah it works dude David S. Miller
1996-04-19 18:47 1% Linux/MIPS port resources Ariel Faigon
1996-04-19 21:52 1% Good news Larry McVoy
1996-04-20 0:22 1% MIPS port kickoff meeting Ariel Faigon
1996-04-23 14:15 1% ` Alistair Lambie
1996-04-20 8:16 1% SparcLinux humorous comments David S. Miller
[not found] <199604230116.SAA28514@yon.engr.sgi.com>
1996-04-23 1:40 1% ` David Miller is on the list David S. Miller
1996-04-23 2:16 1% ` Ariel Faigon
1996-04-23 2:27 1% ` David S. Miller
1996-04-23 2:55 1% ` jon madison
1996-04-23 17:06 1% ` Jim Barton
1996-04-23 16:35 1% ` William J. Earl
1996-04-23 16:56 1% ` Bob Mende Pie
1996-04-24 1:58 1% ` David S. Miller
1996-04-23 2:35 1% Larry McVoy
1996-04-23 16:35 ` Bob Mende Pie
1996-04-23 16:35 0% ` Bob Mende Pie
1996-04-23 16:35 0% ` Bob Mende Pie
1996-04-23 16:39 MIPS port kickoff meeting Greg Chesson
1996-04-24 2:05 1% ` David S. Miller
1996-04-24 4:31 1% ` Greg Chesson
1996-04-23 17:22 1% Larry McVoy
1996-04-23 19:51 1% David Miller is on the list Mike McDonald
1996-04-23 20:20 1% ` William J. Earl
1996-04-23 20:26 1% ` What target (was David ...) Ariel Faigon
1996-04-23 20:54 1% ` Mike McDonald
1996-04-23 22:27 ` Ariel Faigon
1996-04-23 22:27 1% ` Ariel Faigon
1996-04-23 22:27 1% ` Ariel Faigon
1996-04-23 22:43 ` Greg Chesson
1996-04-23 22:43 1% ` Greg Chesson
1996-04-23 22:43 1% ` Greg Chesson
1996-04-23 22:39 1% ` Greg Chesson
[not found] <199604230609.XAA28946@yon.engr.sgi.com>
1996-04-24 2:11 1% ` Naming your machines David S. Miller
1996-04-24 21:05 1% Reminder: meeting in 2 hours Ariel Faigon
1996-04-25 1:17 1% Linux allocated machines Ariel Faigon
1996-04-25 1:35 1% Kickoff meeting minutes Ariel Faigon
1996-04-26 21:59 1% Linux/MIPS status on non-SGI boxes Larry McVoy
1996-04-26 22:24 1% machine resource? Larry McVoy
1996-04-29 23:27 1% scope of this mailing list Larry McVoy
1996-04-30 0:06 1% ` Erik Troan
1996-05-01 2:30 ` Ralf Baechle
1996-05-01 2:30 1% ` Ralf Baechle
1996-05-01 2:30 1% ` Ralf Baechle
1996-05-01 15:44 ` William J. Earl
1996-05-01 15:44 1% ` William J. Earl
1996-05-01 15:44 1% ` William J. Earl
1996-04-30 23:08 1% Let's talk platforms Mike Shaver
1996-04-30 23:11 1% ` William J. Earl
1996-05-01 13:56 1% ` Mike Shaver
1996-05-01 13:56 1% ` Mike Shaver
1996-05-01 1:31 1% whee David S. Miller
1996-05-03 3:29 2% add a 'make -j vmlinux' for flavor David S. Miller
1996-05-10 11:19 1% check this out David S. Miller
1996-05-13 4:05 1% wicked checksum optimization David S. Miller
1996-05-14 1:22 1% Uselinux and the Linux/SPARC port (forwarded) Larry McVoy
1996-05-14 1:23 1% Linux/AP+ technical report (forwarded) Larry McVoy
1996-05-15 3:28 1% numbers David S. Miller
1996-05-15 16:40 1% numbers Neal Nuckolls
1996-05-16 6:21 1% ` numbers David S. Miller
1996-05-15 22:43 1% mpp kernel interface Larry McVoy
1996-05-16 9:09 ` Alan Cox
1996-05-16 9:09 1% ` Alan Cox
1996-05-16 9:09 1% ` Alan Cox
1996-05-16 14:20 1% ` Andrew Tridgell
1996-05-16 17:19 1% ` Alan Cox
1996-05-16 6:53 1% lmbench with new checksum code David S. Miller
1996-05-16 9:35 ` Alan Cox
1996-05-16 9:35 1% ` Alan Cox
1996-05-16 9:35 1% ` Alan Cox
1996-05-16 10:08 1% ` Linus Torvalds
1996-05-16 7:02 1% References for MIPS hacking Michael Beach
1996-05-16 16:03 1% lmbench with new checksum code Larry McVoy
1996-05-16 17:32 ` Alan Cox
1996-05-16 17:32 1% ` Alan Cox
1996-05-16 17:32 1% ` Alan Cox
1996-05-17 4:01 1% ` David S. Miller
1996-05-16 19:03 1% Neal Nuckolls
1996-05-19 5:45 1% idea for csum_partial_copy on Viking/MXCC David S. Miller
1996-05-21 0:16 1% Meeting wednesday Ariel Faigon
1996-05-21 5:42 1% ` William J. Earl
1996-05-21 6:25 1% some projections David S. Miller
1996-05-21 6:49 1% ` William J. Earl
1996-05-21 6:52 1% ` David S. Miller
1996-05-29 21:59 1% linux needs bsd networking stack Neal Nuckolls
1996-05-29 22:50 1% ` David S. Miller
1996-05-30 9:46 ` Alan Cox
1996-05-30 9:46 1% ` Alan Cox
1996-05-30 9:46 1% ` Alan Cox
1996-05-30 5:21 1% ` Linus Torvalds
1996-05-30 9:43 ` Alan Cox
1996-05-30 9:43 1% ` Alan Cox
1996-05-30 9:43 1% ` Alan Cox
1996-05-29 23:04 1% Larry McVoy
1996-05-30 10:06 ` Alan Cox
1996-05-30 10:06 1% ` Alan Cox
1996-05-30 10:06 1% ` Alan Cox
1996-05-30 0:36 1% Neal Nuckolls
1996-05-30 3:02 1% ` David S. Miller
1996-05-30 10:12 ` Alan Cox
1996-05-30 10:12 1% ` Alan Cox
1996-05-30 10:12 1% ` Alan Cox
1996-05-30 18:17 Steve Alexander
1996-05-30 18:17 1% ` Steve Alexander
1996-05-30 18:17 1% ` Steve Alexander
1996-06-02 2:12 1% progress, finally David S. Miller
1996-06-02 3:35 ` Ariel Faigon
1996-06-02 3:35 1% ` Ariel Faigon
1996-06-02 3:35 1% ` Ariel Faigon
1996-06-03 17:12 1% mtc0/eret hazard for the R4600, R4700, and R5000 William J. Earl
1996-06-04 1:02 more progress David S. Miller
1996-06-04 15:51 1% ` William J. Earl
1996-06-04 5:03 1% CVS commit mailing list? David S. Miller
1996-06-04 7:46 1% Ariel Faigon
1996-06-04 12:15 1% ` Kwesi Ames
1996-06-04 16:18 1% ` William J. Earl
1996-06-04 17:16 ` Ariel Faigon
1996-06-04 17:16 0% ` Ariel Faigon
1996-06-04 17:16 0% ` Ariel Faigon
1996-06-05 7:12 1% netbooting David S. Miller
1996-06-05 18:35 1% ` netbooting William J. Earl
1996-06-08 11:23 Are you satisfied now Mr. McVoy? ;-) David S. Miller
1996-06-08 18:22 ` Ariel Faigon
1996-06-08 18:22 1% ` Ariel Faigon
1996-06-08 18:22 1% ` Ariel Faigon
1996-06-10 17:02 ` William J. Earl
1996-06-10 17:02 1% ` William J. Earl
1996-06-10 17:02 1% ` William J. Earl
1996-06-10 16:56 1% ` William J. Earl
1996-06-10 16:59 1% ` David S. Miller
1996-06-08 12:19 1% well it is about time David S. Miller
1996-06-10 16:59 1% ` William J. Earl
1996-06-11 0:13 5% Is this a silly idea? Alistair Lambie
1996-06-11 17:38 5% ` David S. Miller
1996-06-11 17:36 1% my CVS tree David S. Miller
1996-06-11 17:47 5% Is this a silly idea? Larry McVoy
1996-06-11 18:44 4% ` Donna Yobs
1996-06-11 22:34 ` Ariel Faigon
1996-06-11 22:34 5% ` Ariel Faigon
1996-06-11 22:34 5% ` Ariel Faigon
1996-06-11 19:48 4% Larry McVoy
1996-06-11 22:53 1% nt Donna Yobs
1996-06-12 0:04 I fixed the r4ktimer code David S. Miller
1996-06-12 1:11 1% ` William J. Earl
1996-06-12 1:19 1% ` David S. Miller
1996-06-12 23:14 1% off topic question David S. Miller
1996-06-12 23:44 1% ` Kwesi Ames
1996-06-17 20:51 strace project David S. Miller
1996-06-17 20:58 1% ` William J. Earl
1996-06-17 21:20 1% native Linux/MIPS binaries David S. Miller
1996-06-17 22:27 strace project Larry McVoy
1996-06-17 22:27 1% ` Larry McVoy
1996-06-17 22:27 1% ` Larry McVoy
1996-06-18 16:41 1% anyone know if this is true? Larry McVoy
1996-06-18 17:10 ` Ariel Faigon
1996-06-18 17:10 1% ` Ariel Faigon
1996-06-18 17:10 1% ` Ariel Faigon
1996-06-18 17:35 ` Michael Tiemann
1996-06-18 17:35 1% ` Michael Tiemann
1996-06-18 17:35 1% ` Michael Tiemann
1996-06-18 17:11 Dave Olson
1996-06-18 17:21 ` Ariel Faigon
1996-06-18 17:21 1% ` Ariel Faigon
1996-06-18 17:21 1% ` Ariel Faigon
1996-06-18 18:39 ` William J. Earl
1996-06-18 18:39 1% ` William J. Earl
1996-06-18 18:39 1% ` William J. Earl
[not found] <199606182106.OAA15730@anchor.engr.sgi.com>
1996-06-18 23:23 ` gcc solution looks plausible (was: anyone know if this is true?) Ariel Faigon
1996-06-18 23:23 1% ` Ariel Faigon
1996-06-18 23:23 1% ` Ariel Faigon
1996-06-20 11:02 1% Kernel doesn't work on 200MHz Indy Alistair Lambie
1996-06-20 18:12 ` William J. Earl
1996-06-20 18:12 1% ` William J. Earl
1996-06-20 18:12 1% ` William J. Earl
1996-06-21 7:48 1% ` David S. Miller
1996-06-23 3:19 1% what I am up to David S. Miller
1996-06-24 22:43 External Linux/MIPS list Ariel Faigon
1996-06-24 22:43 1% ` Ariel Faigon
1996-06-24 22:43 1% ` Ariel Faigon
1996-06-25 13:35 1% Userland binaries Alistair Lambie
1996-06-25 13:44 1% ` David S. Miller
[not found] ` <dm@neteng.engr.sgi.com>
1996-06-28 10:47 1% ` Alistair Lambie
1996-06-29 7:07 1% NIS rarpd entries David S. Miller
1996-06-30 1:26 NIS rarpd entries (fwd) Ariel Faigon
1996-06-30 1:26 1% ` Ariel Faigon
1996-06-30 1:26 1% ` Ariel Faigon
1996-07-01 18:26 ` Demetrio Pinto
1996-07-01 18:26 0% ` Demetrio Pinto
1996-07-01 18:26 0% ` Demetrio Pinto
1996-07-01 12:28 1% wheee, irix binaries David S. Miller
1996-07-02 10:13 1% (Fwd) Re: SGI/MIPS Linux port status Alistair Lambie
1996-07-04 12:26 1% (Fwd) Libraries uploaded Alistair Lambie
1996-07-04 0:29 1% ` David S. Miller
2002-05-07 18:02 packet socket can't steal packets Dmitrii Tisnek
1990-01-03 20:25 0% ` Carl-Johan Bostorp
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.