Subject: Hanging.

From: Alex deVries <[email-masked]>
Date: Fri, 1 May 1998 14:20:22 -0400 (EDT)

This is a bit weird.   Once every 30 minutes or so, my Indy just sits
there and hangs.  Num lock will work, it'll ping, but there'll be no error
messages, and the system's useless.  After about 10 minutes of this, it'll
wake up as if nothing had happened.

This is with 2.1.91.

Ideas? My initial suspicion is my SCSI bus, although I'm getting no kernel
errors at all. 

- Alex

-- 
Alex deVries
"romantic engsoc guy who runs marathons" - [email-masked]
http://www.engsoc.carleton.ca/~adevries/ .

---

From: "William J. Earl" <[email-masked]>
Date: Fri, 1 May 1998 12:29:04 -0700

> Ideas? My initial suspicion is my SCSI bus, although I'm getting no kernel

     Is this an R4000?  If so, it might be the count/compare erratum, if
the linux kernel does not have the workaround for it yet.  (I haven't
checked the linux sources.)

---

From: Alex deVries <[email-masked]>
Date: Fri, 1 May 1998 15:37:09 -0400 (EDT)

> checked the linux sources.)

This is an R4600.  How would I check if there were that patch applied?

- Alex

---

From: "William J. Earl" <[email-masked]>
Date: Fri, 1 May 1998 12:45:48 -0700

> This is an R4600.  How would I check if there were that patch applied?

     The problem I have in mind cannot occur on an R4600.  The modification
is to the routine which fetches $count.  On the R4000, if you are depending
on the $compare match interrupt, you have to check for the possibility
that $count equalled $compare when you fetched it, since that causes
the interrupt to not happen.  In that case, you have to fake the
interrupt in some way, or have to wait for $count to wrap (about 84 seconds
at 100 MHZ).  IRIX just checks to see if the fetched copy of $count
is close to a shadow copy $compare.  If it is, and if the clock interrupt
request bit is off (this being done with interrupts disabled), we
set $compare a little head of the current $count and spin until the
interrupt bit goes on (with some care to avoid getting stuck if we
lose the race in terms of setting $compare ahead of $count).  Again,
all this only applies to the R4000, not to the R4400, R4600, or R5000.

---

From: [email-masked]
Date: Sat, 2 May 1998 12:52:34 +0200

> wake up as if nothing had happened.

Is it possibly about 64 seconds and not 10 minutes?  If so, we're loosing
timer interrupts.  This doesn't happen for me and in current kernels we
should actually be safe from this with the exception of 100MHz R4000.

If they keyboard is still working, try pressing <ALT>+<Scroll Lock>.  This
should print a register dump.  That dump might end up in the syslog
depending from your setup.  Does the keyboard still work (try toggling
the caps lock led with caps lock)?  If you get such a register dump, could
you please send it to me?

> Ideas? My initial suspicion is my SCSI bus, although I'm getting no kernel

The Indy driver should be pretty stable as it's based on another stone age
driver for various Amiga hostadapters.

There are actually a couple of funny ones in the generic .91 code which
fried that kernel several times for me; on configurations that are
supported the bugs in the portable Linux code are beginning to be the
limit ...

  Ralf

---

From: Alex deVries <[email-masked]>
Date: Sat, 2 May 1998 21:26:22 -0400 (EDT)

> Is it possibly about 64 seconds and not 10 minutes?  If so, we're loosing

Hm.  It's definitely more than 64 seconds.  It's happening right now, and
we're at 5 minutes by my watch.  It could be multiple 64 second hangs back
to back, though.  And I have a 134Mhz, I believe.

> you please send it to me?

Yes, I will.  This will have to wait until I am at the console, though,
which can't be until tomorrow.  

- Alex

---

From: Alex deVries <[email-masked]>
Date: Sun, 3 May 1998 14:22:27 -0400 (EDT)

> you please send it to me?

Alright.  My machine had been hung since last night at 9pm, so this is 17
hours later.  Here's what's on my console, hand typed because I'm not
bright enough to have a serial console:

from before:
zsh: Exception at [<8801800e4>] (80018234)

after my alt-scroll lock:
$0 : 00000000 88130000 00000000 8a7863f8
$4 : 8a786500 8bf5bf48 8a786500 00023ea1
$8 : 80000000 80000000 881702d0 00000001
$12: fffffffc 1000fc01 00000000 7ffff8f0
$16: 8836eaa0 00000b64 00005ebc 00000002
$20: 0000bf8b 00000001 00000000 9fc56394
$24: 00000000 0fb6710
$28: 8bf5a000 8bf5bf38 9fc4be88 8803be90
epc   : 88034d6c
Status: 1000fc03
Cause : 00000400

The kernel I'm running is 2.1.91, which I got from Ralf in
~ralf/vmlinuz.gz or similiar on linus.

- Alex

---

From: [email-masked]
Date: Sun, 3 May 1998 20:40:00 +0200

> zsh: Exception at [<8801800e4>] (80018234)

Which just means that zsh is buggy ...

> ~ralf/vmlinuz.gz or similiar on linus.

I think you got trapped by one of those generic mm bugs in .91.  Will
probably go away once we've upgraded to something newer.

  Ralf

---

From: Alex deVries <[email-masked]>
Date: Sun, 3 May 1998 22:15:27 -0400 (EDT)

> probably go away once we've upgraded to something newer.

Alright. I got it about once an hour today, which is tough to live with.
I think I'll go and compile RPMs on Zach's Qube instead...

- Alex

---

From: [email-masked]
Date: Mon, 4 May 1998 08:57:11 +0200

> I think I'll go and compile RPMs on Zach's Qube instead...

Cobalt Qube is little endian ...

  Ralf

---

From: Alex deVries <[email-masked]>
Date: Mon, 4 May 1998 13:14:21 -0400 (EDT)

> Cobalt Qube is little endian ...

I stand corrected, I'd misunderstood.

There'll be a pretty large problem with Qube users using the version of
RPM that ships with it, since those think they're 'mips', which is
actually 'mipseb' now. 

Anyone know anybody at Cobalt Micro who does their distribution
development? We need to sort this problem out somehow. Their machines
should ship with a later release of RPM, and their packages should ship
as mipsel.

Oh, and there'll be a huge batch of mipseb binary RPMs ported from the
contrib directory on ftp.redhat.com.  Details later. 

- Alex

---

From: [email-masked]
Date: Mon, 4 May 1998 21:32:05 +0200

> should ship with a later release of RPM, and their packages should ship

I cc this to Tim.  DaveM is also reading this list, so they'll know.
The problem isn't too bad.  One new rpm binaries have been installed those
will know about mipsel/mipseb.  And we _had_ to break compatibility,
remember the purpose was to make the two flavours and the old ``mips''
flavour different and distinguishable from each other.

If this ends up being a problem one can still add apropriate entries to
/usr/lib/rpmrc or using the --ignore-arch option.

> contrib directory on ftp.redhat.com.  Details later. 

Cool.

  Ralf

---

From: Alex deVries <[email-masked]>
Date: Mon, 4 May 1998 15:45:41 -0400 (EDT)

On Mon, 4 May 1998 [email-masked] wrote:
> The problem isn't too bad.  Once new rpm binaries have been installed
> those

Yes.  We had to break compatibility.  It's just disappointing that the
SGI-Linux, Cobalt Micro and RPM flks disn't come to a consensus on it.
And really, I'm not laying blame, I'm trying to find a solution to it.

Right now, Qube users will have the following problems:
- they will build RPMs that are tagged as arch 4, which isn't in line
  with the standard that RPM and SGI-Linux agreed to
- they will have to use --ignorearch when installing contribbed RPMs
- RPM will not complain when installing incompatible mipseb packages

Even if the Cobalt ships and update with RPM 2.4.109 or similiar:
- the binaries that Cobalt already ships with (and I assume they do) will
have to be regenerated

We really need some input from Cobalt on this issue.  Tim?

- Alex