Subject: failed installation debian-mipsel (Decstation 5000/150)

From: Florian Lohoff <[email-masked]>
Date: Mon, 26 Nov 2001 23:46:17 +0100

Hi,
i am just trying to install debian-mipsel on a Decstation 5000/150 
with the bootfloppies 3.0.15-2001-10-19.

I am working on serial console and dont have a framebuffer nor a
keyboard.

At first the installation misses a short "Howto boot a decstation over
the net" which is not that trivial.

At least this should be mentioned:

echo 4096 >/proc/sys/net/ipv4/neigh/eth0/retrans_time

and something along that you need to set a console as the kernel is not
able to autodetect the console.

The kernel hangs for me at the detection of the LK Keyboard (which
is not attached)

-------------------------------------------------
>>boot 3/tftp/boot/kn04tftpboot.img console=ttyS2

-tftp boot(3), bootp 195.71.97.238:/boot/kn04tftpboot.img
-tftp load 1679360+1970176+198224
This DECstation is a DS5000/1xx
Loading R4000 MMU routines.
CPU revision is: 00000430
Primary instruction cache 8kb, linesize 16 bytes.
Primary data cache 8kb, linesize 16 bytes.
Secondary cache sized at 1024K linesize 32 bytes.
Linux version 2.4.5-r4k-kn04 ([email-masked]) (gcc version
2.95.4 200101Determined physical RAM map:
memory: 04000000 @ 00000000 (usable)
Initial ramdisk at: 0x80203000 (1800109 bytes)
On node 0 totalpages: 16384                                                    
zone(0): 16384 pages.
zone(1): 0 pages.
zone(2): 0 pages.
Kernel command line: console=ttyS2
Console: colour dummy device 80x25
Calibrating delay loop... 49.75 BogoMIPS
Memory: 60392k/65536k available (1632k kernel code, 5144k reserved, 1847k data,)
Dentry-cache hash table entries: 8192 (order: 4, 65536 bytes)
Inode-cache hash table entries: 4096 (order: 3, 32768 bytes)
Buffer-cache hash table entries: 4096 (order: 2, 16384 bytes)
Page-cache hash table entries: 16384 (order: 4, 65536 bytes)
Checking for 'wait' instruction...  unavailable.
POSIX conformance testing by UNIFIX
TURBOchannel rev. 1 at 12.5 MHz (without parity)
slot 0: DEC      PMAZ-AA  V5.3d
slot 1: DEC      PMAZ-AA  V5.3b
slot 2: DEC      PMAF-FA  V1.1
Linux NET4.0 for Linux 2.4
Based upon Swansea University Computer Society NET3.039
Starting kswapd v1.8
pty: 256 Unix98 ptys configured
DECstation Z8530 serial driver version 0.05
DECstation LK keyboard driver v0.04... 
---------------------------------------------------------------

Flo
-- 
Florian Lohoff                  [email-masked]             +49-5201-669912
Nine nineth on september the 9th              Welcome to the new billenium

---

From: Florian Lohoff <[email-masked]>
Date: Mon, 26 Nov 2001 23:51:29 +0100

> with the bootfloppies 3.0.15-2001-10-19.

OOps - Write once memory - 3.0.14-2001-09-30 i meant.

Flo

---

From: "Maciej W. Rozycki" <[email-masked]>
Date: Tue, 27 Nov 2001 13:43:10 +0100 (MET)

> the net" which is not that trivial.

 It depends on how you are doing it...  For me MOP appears to be piece of
cake now that you can boot ELF directly. :-)  Nothing to configure, just
copy the kernel to the mopd home directory.  The drawback is MOP cannot
pass routers. 

> echo 4096 >/proc/sys/net/ipv4/neigh/eth0/retrans_time

 Is it needed for TFTP?  What for?

> able to autodetect the console.

 You mean the serial console?  Well, that's surely not detectable, but the
console on the VT seems to be detected fine.

> The kernel hangs for me at the detection of the LK Keyboard (which

 Yep, the timeouts are definitely too large even for the patient... ;-) 
If you waited for a few minutes, it should boot anyway.  I'll prepare a
fix. 

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: [email-masked], PGP key available        +

---

From: Florian Lohoff <[email-masked]>
Date: Tue, 27 Nov 2001 13:49:30 +0100

>  Is it needed for TFTP?  What for?

The decstation fails to answer ARP requests while downloading. From
kernel 2.2 on the arp entries expire faster which lets the tftp download
fail somewhere in the middle.

> console on the VT seems to be detected fine.

It might be detected from the prom env var "osconsole".

> If you waited for a few minutes, it should boot anyway.  I'll prepare a

It didnt - I at least let the machine wait for 15-20 Minutes while
digging the code...

Flo

---

From: Jan-Benedict Glaw <[email-masked]>
Date: Tue, 27 Nov 2001 14:56:42 +0100

On Tue, 2001-11-27 13:49:30 +0100, Florian Lohoff <[email-masked]>
> fail somewhere in the middle.

Provide a static ARP entry. Won't expire ever:-)

MfG, JBG

-- 
Jan-Benedict Glaw   .   [email-masked]   .   +49-172-7608481
	http://lug-owl.de/~jbglaw/software/snapshot2cvs/

---

From: "Maciej W. Rozycki" <[email-masked]>
Date: Tue, 27 Nov 2001 15:33:42 +0100 (MET)

> fail somewhere in the middle.

 I see.  I haven't used TFTP on the DECstation ever.  I think the default
timeout is too low anyway.  RFC826 does not specify any timeouts but
keeping them below 2 minutes is pointless IMO.  If an interface assigned
to an IP address changes its MAC address, it will start to use the new one
for ARP requests immetiately and all caches in the LAN will have a chance
to get updated.

> It didnt - I at least let the machine wait for 15-20 Minutes while

 Weird -- the read should time out after 10000 loops...  It definitely
needs to be checked.

---

From: Florian Lohoff <[email-masked]>
Date: Tue, 27 Nov 2001 16:38:54 +0100

> for ARP requests immetiately and all caches in the LAN will have a chance

IIRC the kernel refreshes the timeout on communication - But only on
TCP not UDP ...

>  Weird -- the read should time out after 10000 loops...  It definitely

Did this change lately - The kernel of the boot-floppies is a little
old.

Flo

---

From: "Maciej W. Rozycki" <[email-masked]>
Date: Tue, 27 Nov 2001 17:55:00 +0100 (MET)

> IIRC the kernel refreshes the timeout on communication - But only on

 Weird.

> Did this change lately - The kernel of the boot-floppies is a little

 I don't think so.