Subject: linus accessible from within SGI

From: [email-masked] (Ariel Faigon)
Date: Wed, 13 Aug 1997 13:22:59 -0700 (PDT)

Good news:

Looks like the routing problem that prevented many outside .engr
to access linus is now fixed.

guest@sgigate 3% traceroute linus.linux.sgi.com
traceroute to linus.linux.sgi.com (192.48.153.197), 30 hops max, 40 byte packets
 1  purgatory.SGI.COM (204.94.209.2)  2 ms  5 ms  3 ms
 2  forbidden (204.94.211.38)  4 ms  14 ms  7 ms
 3  paloalto-cr6.bbnplanet.net (131.119.26.57)  90 ms  105 ms  63 ms
 4  paloalto-cr4.bbnplanet.net (131.119.0.148)  684 ms  113 ms  75 ms
 5  paloalto-cr34.bbnplanet.net (131.119.0.109)  11 ms  15 ms  22 ms
 6  sgi.bbnplanet.net (131.119.16.6)  27 ms  16 ms  24 ms
 7  linus.linux.sgi.com (192.48.153.197)  16 ms  18 ms  18 ms

Roundabout, but working.

-- 
Peace, Ariel

---

From: Eric Kimminau <[email-masked]>
Date: Wed, 13 Aug 1997 16:44:34 -0400

>  7  linus.linux.sgi.com (192.48.153.197)  16 ms  18 ms  18 ms

Ive been able to rftp to it, and Ive now surf'ed to it but Im still
having a hard time getting mirror to work to it.

Has anyone been able to get "mirror" work via socks through our
firewall?

I would like to mirror linus.linux on an internal SGI, linux.detroit,
which is currntly up and running.

-- 
Eric Kimminau                           System Engineer/RSA
[email-masked]                     Silicon Graphics, Inc
Voice: (248) 848-4455                   39001 West 12 Mile Rd.
Fax:   (248) 848-5600                   Farmington, MI 48331-2903

                 VNet Extension - 6-327-4455
              "I speak my mind and no one else's."
       http://www.dcs.ex.ac.uk/~aba/rsa/perl-rsa-sig.html

    When confronted by a difficult problem, solve it by reducing 
    it to the question, "How would the Lone Ranger handle this?"

Windows 95: n.
    32 bit extensions and a graphical shell for a 16 bit patch to an
    8 bit operating system originally coded for a 4 bit microprocessor,
    written by a 2 bit company that can't stand 1 bit of competition.

    Author unknown.

---

From: Mark Salter <[email-masked]>
Date: Wed, 13 Aug 1997 17:09:32 -0500

I've been taking a look at the problem with frequent ethernet
transmit timeouts. In addition to the timeouts, I've also seen
an occasional duplicate packet being sent in response to pings
coming from another machine. I'm debugging somewhat in the dark
because I don't have documentation on the indy's DMA controller
although the sgihpc.h file has been helpful.

I also noticed that the linux time of day clock falls behind
real time whenever these timeouts occur. I decided to take a
look at this side of the problem and discovered that interrupts
are being turned off for extended periods of time. I modified
the timer interrupt handler to print a message if it detects
a missed system tick. Sure enough, every ethernet timeout is
accompanied by a message coming from the timer interrupt. The
message indicates that the timer interrupt was held off for
as much as 45ms!

Here's the change I made to indy_timer_interrupt() in indy_timers.c:

	/* Ack timer and compute new compare. */
#if 0
	r4k_cur = (read_32bit_cp0_register(CP0_COUNT) + r4k_offset);
#else
	count = read_32bit_cp0_register(CP0_COUNT);
	if ((count - r4k_cur) >= r4k_offset) {
		printk("missed heartbeat: r4k_cur[0x%x] count[0x%x]\n",
		       r4k_cur, count);
		r4k_cur = count + r4k_offset;
	}
	else
	    r4k_cur += r4k_offset;
#endif

The original code which calculates the next value for the CP0_COMPARE
register introduces skew by basing it on the current value of the 
CP0_COUNT register rather than the previous CP0_COMPARE value. But as
it turns out, that little bit of skew is preferable to the large 
skew that would result whenever the timer interrupt is held off too
long.

Anyway, I'm going to be away from the office until 19 August, so I'll
pick it up then unless someone else finds it first. It seems likely
that the enet timeouts are the result of interrupts being turned off
too long, but if that's not the case, can someone point me to some
documentation for the indy's dma controller? I have some suspicions
of race conditions when setting up new DMA buffers, but I'd like to
have a document before I try various fixes.

--
Mark Salter
[email-masked]

---

From: [email-masked] (Michael O'Connor)
Date: Thu, 14 Aug 1997 09:15:30 -0400 (EDT)

|Has anyone been able to get "mirror" work via socks through our
|firewall?

By 'mirror', I take it you mean the perl mirror program.  :)

The more general question is:  How do you get perl TCP/IP programs
to work over SOCKS?  It appears that Simon Cooper, [email-masked], is
working on a perl module to do that.  Suggest you talk with him, or
use something else to mirror -- some of the nouveau FTP clients
do this, and could probably be easily SOCKSified.  

-- 
 Michael J. O'Connor   |  Phone:    +1 (248) 848-4481  |    "Do, or do not.
 39001 W. 12 Mile Rd   |  Fax:      +1 (248) 848-5600  |  There is no try."
 Farmington Hills, MI  |  Internet:       [email-masked]  |
 48331-2903  DMR-225   |  http://reality.sgi.com/mjo/  |              -Yoda

---

From: Eric Kimminau <[email-masked]>
Date: Thu, 14 Aug 1997 11:38:30 -0400

Wolfgang Szoecs wrote:
> 
> Hi,
> 
> ...that's not true.
> even today i got routed from the office in Munich to nirvana:
> 
> $ /usr/etc/traceroute linus.linux.sgi.com
>  1  gate-wanmunich.munich.sgi.com (144.253.193.1)  2 ms  1 ms  2 ms
>  2  169.238.216.2 (169.238.216.2)  267 ms  286 ms  275 ms
>  3  b20wanring.corp.sgi.com (155.11.108.2)  265 ms  266 ms  266 ms
>  4  b1wanring.corp.sgi.com (155.11.108.1)  263 ms (ttl=253!)  264 ms (ttl=253!)
>  268 ms (ttl=253!)
>  5  b1dco-cisco1-141.corp.sgi.com (150.166.141.40)  287 ms (ttl=252!)  268 ms
> (ttl=252!)  266 ms (ttl=252!)
>  6  gate2-dumpty.corp.sgi.com (150.166.100.61)  336 ms (ttl=251!)  272 ms
> (ttl=251!)  262 ms (ttl=251!)
>  7  gate2-dumpty.corp.sgi.com (150.166.100.61)  265 ms (ttl=251!) !H  280 ms
> (ttl=251!) !H  292 ms (ttl=251!) !H
> 
> That's it.
> 
> BTW, i'm searching for a kernel image for booting a linux-NFS-root.
> Does anybody have one, and could give me that ?
> (a root-fs i already have)
> 
> Regards Wolfgang

You can't traceroute to it. Its outside the firewall. rftp or ssh to it
works.

Windows 95: n.

    Author unknown.

---

From: Mike Shaver <[email-masked]>
Date: Thu, 14 Aug 1997 13:21:27 -0400 (EDT)

> (a root-fs i already have)

Oh yeah, I forgot to tell the list about this:

Miguel gave me his kernel, since I couldn't build one with either my
tools or the ones on linus, and I put it up for Jan at
ftp://ftp.linux.sgi.com/pub/testing/vmlinux-970813-jwr.gz
(You'll need to gunzip it for use.)

Mike

-- 
#> Mike Shaver ([email-masked]) Ingenia Communications Corporation 
#>           Resident Linux bigot and kernel hacker. (OOPS!)           
#> `If you get bitten by a bug, tough luck...the one thing I won't do  
#> is feel sorry for you.  In fact, I might ask you to do it all over  
#> again, just to get more information.  I'm a heartless bastard.'     
#>                       -- Linus Torvalds (on development kernels)

---

From: Alex deVries <[email-masked]>
Date: Thu, 14 Aug 1997 13:36:24 -0400 (EDT)

> (You'll need to gunzip it for use.)

Thank you!  I've had a seemingly endless stream of problems with cross
compiling a kernel.  I will try this out tonight.

- Alex

---

From: [email-masked] (Ariel Faigon)
Date: Thu, 14 Aug 1997 11:32:41 -0700 (PDT)

:
:
:|Has anyone been able to get "mirror" work via socks through our
:|firewall?
:
:By 'mirror', I take it you mean the perl mirror program.  :)
:
:The more general question is:  How do you get perl TCP/IP programs
:to work over SOCKS?  It appears that Simon Cooper, [email-masked], is
:working on a perl module to do that.  Suggest you talk with him, or
:use something else to mirror -- some of the nouveau FTP clients
:do this, and could probably be easily SOCKSified.  
:
In the case of perl it is easy to cross the firewall by simply
using a proxy. i.e. you don't need to SOCSify you perl since
the proxy (which is SOCKsified) does the job for you.

Enclosed below is a (http) 'GET' script that uses one possible
SGI proxy when given the -e option. The method uses is the name
of the script so you may symlink it to 'HEAD' for example.

-- 
Peace, Ariel

#!/usr/bin/perl5
#
# perl5+LWP script to fetch a URL
#
# Usage:
#	Get [-e] [-t<timeout>] <URL>
#
# Author:
#	[email-masked], 1996
#
use HTTP::Status;
use LWP::UserAgent;
use LWP::Protocol;

{
	#
	# Override these methods. Their default behavior is bad for us.
	#
	package LWP::Protocol; sub use_alarm { shift->_elem('use_alarm', 0); }
	package LWP::UserAgent; sub redirect_ok { 0; }
}

require 'getopts.pl';
&Getopts('t:m:e');

$0 =~ s,.*/,,;

unless ($ARGV[0]) {
    die "Usage: $0 [-e -tTIMEOUT -mMETHOD] URL
	-e	Use a proxy for [e]xternal accesses
	default METHOD is program name
	default TIMEOUT is 7 sec for internal, 14 for external\n";
}

if ($opt_t =~ /^\d+$/) {
    $get_timeout = $opt_t;
} else {
    $get_timeout = 7;
    $get_timeout *= 2 if ($opt_e);
}
($method = $opt_m) || ($method = $0);
$method =~ tr,a-z,A-Z,;

# print "get started\n";
&get($method, $ARGV[0], $get_timeout);

# get($method, $from_url, $timeout)
#       Fetches $url into a $get_contents. Gives up after $timeout sec.
#       returns the HTTP get code (200 for OK etc.)
#
sub get {
    my($method, $url, $timeout) = @_;
    my ($ua, $request, $response);    
    my ($key, $get_rc, $lf);

    $ua = new LWP::UserAgent;
    $ua->use_alarm(1);
    $ua->timeout($timeout);
    $ua->agent("Get-perl5/v1.0");
    if ($opt_e) {
	$ua->proxy([ 'http' ], 'http://www-dms.esd.sgi.com:8080/');
    }

    if ($url =~ m,^/,) {
	$url = 'localhost' . $url;
    }
    unless ($url =~ /^[a-z]+:/) {
	$url = 'http://' . $url;
    }
    $get_content = '';
    $Content_length = '';

    $request = new HTTP::Request($method, $url);
    # $request->push_header('If-Modified-Since' => 'Thu, 01-Jan-70 00:00:00 GMT');

    print STDERR $method, ' ', $url, ': ';

    $response = $ua->request($request);

    $get_rc = $response->code;
    $get_content = $response->content if $response->is_success;
    $error_msg = status_message($get_rc);

    if ($get_rc == 200) {                       # 200: OK
	$Content_length = $response->header('Content-length');
    }
    # Some servers do not send the content length...
    if ($Content_length eq '' &&  $get_content) {
	$Content_length = length($get_content);
    }

    print STDERR $error_msg,
        ($Content_length ? " ($Content_length)" : ''), "\n";

    print STDERR $response->headers_as_string;
    print $get_content;

    $get_rc;
}

__END__

---

From: Ralf Baechle <[email-masked]>
Date: Fri, 15 Aug 1997 01:15:22 +0200 (MET DST)

> message indicates that the timer interrupt was held off for

I've never seen these problems in my configurations.  However I've fixed
a couple of interrupt realted things which I'll commit into the CVS
as soon as I'm in Mountain View.  One of these, a console bug might
actually have been the cause of the extreme long interrupt disable time
you have seen.

There are more thing which need to be reworked with resprect to interrupts.
For example cache flushing turns interrupts off for sometimes several
thousand cycles even though this is only required for certain buggy CPUs
like the R4600 v1.x.  And even there are better workarounds.  General
rule about cli():  Think about it if you really need it.  Then think again
about it.  If you're finished wnd still think cli() might be a good solution,
then think once again about it ...

For me the "most wanted - fix on sight" bug is currently a memory corruption
problem.  Other than that I was able to compile >92mb RPM binaries several
times in a row.  It's just that that memory corruption problem corrupts
disk data structures in memory which might be written back later ...

  Ralf

---

From: "Wolfgang Szoecs" <[email-masked]>
Date: Thu, 14 Aug 1997 17:31:49 -0600

Hi,

...that's not true.

traceroute to linus.linux.sgi.com (192.48.153.197), 30 hops max, 40 byte
packets

That's it.

Regards Wolfgang

-- 
\------------------------------------------------\        _         ______ |
 \  Wolfgang Szoecs   Software Support Engineer   \     /SGI\____-=0`/|0`/__|
  \  Silicon Graphics GmbH, Munich / Germany       \____\Munich     / | /    )
  /         SMTP: [email-masked]             /     `/-==_____/__|/__=-|
 / Phone: 0130/112550     | Fax: 089/46108 190    /      *             \ | |
/------------------------------------------------/                     (o)
Redistribution of this message via the Microsoft Network is prohibited

---

From: "David S. de Beer" <[email-masked]>
Date: Fri, 15 Aug 1997 15:46:51 +0300

> of the script so you may symlink it to 'HEAD' for example.

Ariel,

Wow, great :) Do you perhaps have a perl script for ftp as well?

Also, I've looked around for a xftp client that works with socks and can also copy
recursive directories. Is there something like this available?

Thank you kindly.

David

--
      ,   ,
     { \w/ }
      `>!<`
      (/^\)
      '   '

---

From: Eric Kimminau <[email-masked]>
Date: Fri, 15 Aug 1997 09:13:56 -0400

Has anyone completed a HOWTO for booting from a second local disk yet?

Thanks!
                Eric.

Windows 95: n.

    Author unknown.

---

From: Eric Kimminau <[email-masked]>
Date: Fri, 15 Aug 1997 09:17:25 -0400

> recursive directories. Is there something like this available?

ncftp will do this David. You need the latest version though. The dist
on dist.engr:/sgi/hacks is NOT up to date and has problems going through
a SOCKS proxy.

Windows 95: n.

    Author unknown.

---

From: Mike Shaver <[email-masked]>
Date: Fri, 15 Aug 1997 09:22:40 -0400 (EDT)

> Has anyone completed a HOWTO for booting from a second local disk yet?

Do you have a root-mountable filesystem on the second disk?
If so:
- put vmlinux on the IRIX /
- boot into sash
boot /vmlinux root=/dev/sdb1

(This is from memory, but it was pretty simple.  Once Miguel told me
how simple it was, of course. =) )

Mike

-- 
#> Mike Shaver ([email-masked]) Ingenia Communications Corporation 
#>       Chief System Architect -- Head geek -- System exorcist        
#>                                                                     
#>   "Have you considered a life?  I hear they're quite affordable     
#>          these days." --- [email-masked]

---

From: Mike Shaver <[email-masked]>
Date: Fri, 15 Aug 1997 09:37:25 -0400 (EDT)

Thus spake Eric Kimminau:
> OK, this IS simple enough. Does anyone have a tar of a functional Linux
> installation I can snag and uncompress on my second disk?

ftp://ftp.linux.sgi.com/pub/mips-linux/root-be-0.00.cpio.gz
should work fine.

(20MB, BTW)

> My assumption would be I would then just modify
> /dev/sdb1/etc/hosts,hostname, etc. for networking and then reboot into
> Linux? 

Something like that.
You can edit them after you reboot, though.

Mike

-- 
#> Mike Shaver ([email-masked]) Ingenia Communications Corporation 
#>                 UNIX medicine man -- dark magick, cheap!            
#>                                                                     
#>  When the going gets tough, the tough give cryptic error messages.  
#>          "We believe in rough consensus and running code."

---

From: Eric Kimminau <[email-masked]>
Date: Fri, 15 Aug 1997 09:38:04 -0400

If someone can throw up a tar somewhere Ill come get it and
linux.detroit will be online today.

Windows 95: n.

    Author unknown.

---

From: "Greg Chesson" <[email-masked]>
Date: Fri, 15 Aug 1997 09:58:08 -0700

On Aug 15,  9:38am, Eric Kimminau wrote:
> Subject: Re: Local disk boot HOWTO

> > boot /vmlinux root=/dev/sdb1

seems to me you'd have to also patch vmlinux to get the device ID
correct for the root disk.  On Irix you'd have to move /dev/root.
I'm not sure what the equivalent might be on linux.... but I'd like
to know what the recipe is.  I too would like to bring linux up on
a secondary disk.

g

---

From: Mike Shaver <[email-masked]>
Date: Fri, 15 Aug 1997 13:09:36 -0400 (EDT)

Thus spake Greg Chesson:
> correct for the root disk.

The root= parameter tells it where its root device is.
(It magically parses the [hs]d[ab][0-8] part into major/minor.)

Mike

-- 
#> Mike Shaver ([email-masked])      Information Warfare Division  
#> Chief Tactical and Strategic Officer         "Saepe fidelis"        
#>                                                                     
#> "I like your game, but we have to change the rules." -- Anon        
#>

---

From: Ralf Baechle <[email-masked]>
Date: Fri, 15 Aug 1997 19:17:56 +0200 (MET DST)

> > > boot /vmlinux root=/dev/sdb1

The receipe is correct.

> to know what the recipe is.  I too would like to bring linux up on

My suggestion is to attack the ext2fs disk to a Linux/i386 machine,
build the root filesystem etc. on it, then back on the Indy use it
for booting.  Linux is so smart that it handles the MSDOG partitions
on the disk created that way correctly and I store my kernel on the
IRIX / anyway.

  Ralf

---

From: Miguel de Icaza <[email-masked]>
Date: Fri, 15 Aug 1997 13:45:06 -0500

> Has anyone completed a HOWTO for booting from a second local disk yet?

No, but if you put your Linux kernel on EFS or XFS, you just need to
go to the sash boot prompt and from there type:

	boot /vmlinux

Miguel.

---

From: Eric Kimminau <[email-masked]>
Date: Fri, 15 Aug 1997 14:54:22 -0400

> go to the sash boot prompt and from there type:

This is incorrect. It will not boot off of a second disk with everything
on an XFS partition. We ar ejust about to finish the restore to an efs
partition and try it that way.

Windows 95: n.

    Author unknown.

---

From: [email-masked] (Alan Cox)
Date: Fri, 15 Aug 1997 20:35:04 +0100 (BST)

> on the disk created that way correctly and I store my kernel on the

Another approach is to create a linux fs the right size for your root
on another ext2fs supporting host (ie linux,os/2, win95,macos ;))
and gzip the actual file system, then people can bootstrap it quite
easily under irix by just gunzipping to the _right_ ;) raw device

Alan

---

From: "William J. Earl" <[email-masked]>
Date: Mon, 18 Aug 1997 16:34:36 -0700

Ralf Baechle writes:
...
 > then think once again about it ...
...

     In IRIX, I had the cache flushing code, when doing writebacks on
the R4600 and the like, reenable interrupts every page, to limit the
wait time (to about 50 us. on an Indy).  I patched out the extra instructions
to disable and reenable interrupts on processors which did not require them.
Assuming that the code uses index invalidate or index writeback invalidate
when the buffer is larger than the cache, the invalidate-only case (without
writeback) is short enough (5 us. or less) that reenabling interrupts is
not needed.  The writeback case takes much longer, in the worst case,
because each cache line must be written to memory, taking about 400 ns.
each on the Indy.