Subject: Kernel for local disk stuff

From: Mike Shaver <[email-masked]>
Date: Fri, 5 Sep 1997 00:58:04 -0400 (EDT)

ftp://ftp.linux.sgi.com/pub/test/vmlinux-950905.gz works for me for
mounting local disk as root.

Getting a local disk set up is still a minor nightmare, because
there's no simple boot image yet (though Alex is working on it), and
because heavy ethernet traffic occasionally generates bus errors that
lock up the box.  I'm going to take a look at what causes those
tomorrow, hopefully.

(I'm also going to reinstall IRIX on the primary disk.  mke2fs
can really wreck IRIX's day. =) )

Mike

-- 
#> Mike Shaver ([email-masked]) Ingenia Communications Corporation 
#>              Linux: because every cycle counts.
#>
#> "I don't know what you do for a living[...]" -- [email-masked]
#>        "I change the world." -- [email-masked]

---

From: Mark Salter <[email-masked]>
Date: Fri, 5 Sep 1997 17:30:59 -0500

> lock up the box.  I'm going to take a look at what causes those

These finally annoyed me to the point I started looking at it today. I
was able to hack the buserr irq handler to set up a gdb frame so that
gdb gets control at the instruction that was interrupted. The problem
appears to be in sgiseeq.c which is no great surprise since it occurs
during times of heavy network traffic. The bus error irqs always occur
when interrupts are reenabled in the ret_from_sys_call after a sgiseeq
irq. The hpc_ethregs tx_ctrl value is 0x1 indicating that transmit was
inactive, but there was an underflow. The tx_ndptr value is 0xffffffff.
The latter I think leads to the bus error. Look at kick_tx() being
called from sgiseeq_tx() during the handling of the interrupt. With
that value of tx_ndptr, kick_tx would end up writing to 0xbffffff0
which is not we want to do. I don't have the HPC docs, so I'm probably
not going to be able to come up with a proper fix...

--Mark