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

From: "Christoph Franzen" <ChristophFranzen@gmx.net>
To: Izumi Tsutsui <tsutsui@ceres.dti.ne.jp>
Cc: gnats-bugs@NetBSD.org
Subject: Re: port-alpha/36628: cdhdtape image panics with memory management trap on Jensen
Date: Mon, 06 Aug 2007 02:38:43 +0200

 > > According to the Mailinglist, older Netbsd versions have been 
 > > successfully run on the Jensen, and that would have been impossible
 > > without ahb(4), because the Jensen's SRM CANNOT boot from elsewhere.
 > > 
 > 
 > Is there any evidence that shows Jensen working with configured
 > ahb(4) SCSI?
 
 No, not really... I was trying to logically deduce this from the 
 postings.
 
 > I can only find Jason's post:
 >  http://mail-index.netbsd.org/port-alpha/2000/07/12/0002.html
 
 This is exactly the post I had in mind.
 
 > but in this dmesg "scsibus at ahb" was disabled (not configured)
 > so no interrupt from ahb(4) was handled. It was the same case
 > on our mdroot images without ahb(4).
 
 I obviously overlooked this line and the other one:
 WARNING: can't figure what device matches "SCSI 1 4 0 0 200 0 JENS-
 IO"
 I thought it must be running somehow, else it would not be possible 
 to actually install the system.
 Perhaps leaving it alone and using it only for booting form SRM would 
 work. After the first step one could possibly switch over to another, 
 supported disk controller...
 
 Would it help to have a look at the Linux driver for the AHA174x?
 
 > Others reported that their kernel hanged up after fd was probed
 > (i.e. interrupt was enabled).
 
 Well, this seems to be solved.
 
 > > The Alphaserver hardware is quite different from the Jensen
 > 
 > Well, I meant ahb(4) driver doesn't have any MI problem
 > even on LP64 platforms and probably our problems are around
 > interrupt code for Jensen.
 
 This is possible. Unfortunately I don't know much about these things. 
 There are some weird things, however. In the Hardware Reference PDF 
 file I mentioned they were referring to IRQ 9 as SCSI. This IRQ is 
 occupied by the graphics board (can only use this one or no IRQ at 
 all) and the ECU doesn't complain. The board is only recognized by 
 NetBSD as ISA with no IRQ even in EISA mode. I think the reason is 
 that it doesn't support reading the EISA id (I know for sure that it 
 doesn't support this).
 
 Regards, Christoph