The following reply was made to PR port-alpha/36628; it has been noted by GNATS.

From: Izumi Tsutsui <tsutsui@ceres.dti.ne.jp>
To: ChristophFranzen@gmx.net
Cc: gnats-bugs@NetBSD.org, tsutsui@ceres.dti.ne.jp
Subject: Re: port-alpha/36628: cdhdtape image panics with memory management
	 trap on Jensen
Date: Sun, 29 Jul 2007 13:06:28 +0900

 ChristophFranzen@gmx.net wrote:
 
 > It reaches init, but hangs after complaining about the clock.
 
 As you can see sys/arch/alpha/alpha/clock.c, inittodr(9)
 compares its system clock and timestamp in root filesystem,
 and then it shows a warning message if there is a certain
 difference. The mdroot image was created on July 22 so
 "clock gained 6 days" indicates that the system clock is
 read properly.
 
 > db> ps /w
 >  PID          COMMAND     EMUL  PRI UTIME STIME WAIT-MSG    WAIT-
 > CHANNEL
 >  6           aiodoned   netbsd    4   0.0   0.0 aiodoned    netbsd:uvm+0x2c
 >  5            ioflush   netbsd   40   0.0   0.0 syncer      netbsd:rushjob
 >  4         pagedaemon   netbsd    4   0.0   0.0 pgdaemon    netbsd:uvm+0x1c
 >  3          cryptoret   netbsd   36   0.0   0.0 crypto_wait netbsd:crp_ret_q
 >  2               pms0   netbsd   32   0.0   0.0 pmsreset    0xfffffe0000071e74
 > >1               init   netbsd   71  78.6   0.0
 >  0            swapper   netbsd    4   0.0   0.0 scheduler   netbsd:proc0
 
 This shows that most tasks in sys/kern/init_main.c:main()
 are done and looks system trying to fork /bin/sh.
 On my AlphaPC 164 that image just works (system boots and
 sysinst starts) so I'm afraid it's difficult to track
 what's wrong on jensen specific part...
 
 > evcnt type 1: soft net = 1
 > evcnt type 1: cpu0 clock = 79654
 > evcnt type 1: cpu0 device = 2
 > evcnt type 1: eisa irq 6 = 1
 > evcnt type 1: vector 0x900 = 1
 
 At least one fdc(4) interrupt is handled, it seems.
 Could you try "boot -flags n" on SRM console and
 see what happens if you specify "we1" for root device?
 
 You would get "cannot mount root, error = xx" error
 if you don't have NFS root settings on your network,
 but you could see if interrupts from we1 are handled
 or not after the error on the ddb "show event" command.
 ---
 Izumi Tsutsui