OK, as per your request and also Ross's, here is the dmesg output from
my 164SX system.   If either of you need anything else, let me know as I 
am more than glad to do what I can do to help..

alpha1$ dmesg
[ preserving 253472 bytes of netbsd ELF symbol table ]
Copyright (c) 1996, 1997, 1998, 1999
    The NetBSD Foundation, Inc.  All rights reserved.
Copyright (c) 1982, 1986, 1989, 1991, 1993
    The Regents of the University of California.  All rights reserved.

NetBSD 1.4.1 (ALPHA1) #1: Tue Aug 31 12:07:22 EDT 1999
    howardl@alpha1:/usr/src/sys/arch/alpha/compile/ALPHA1
Digital AlphaPC 164SX 533 MHz
8192 byte page size, 1 processor.
real mem = 268435456 (1957888 reserved for PROM, 266477568 used by NetBSD)
avail mem = 230703104
using 3252 buffers containing 26640384 bytes of memory
mainbus0 (root)
cpu0 at mainbus0: ID 0 (primary), PCA56-2 (unknown minor type 2)
cia0 at mainbus0: DECchip 2117x Core Logic Chipset (Pyxis), pass 1
cia0: extended capabilities: 1<BWEN>
cia0: using BWX for PCI config access
pci0 at cia0 bus 0
pci0: i/o enabled, memory enabled
sio0 at pci0 dev 8 function 0: Contaq Microsystems 82C693 PCI-ISA Bridge (rev. 0x00)
pciide0 at pci0 dev 8 function 1: Contaq Microsystems CY82C693 IDE Controller
pciide0: bus-master DMA support present
pciide0: primary channel wired to compatibility mode
wd0 at pciide0 channel 0 drive 0: <Maxtor 90320D2>
wd0: drive supports 16-sector pio transfers, lba addressing
wd0: 3079MB, 6256 cyl, 16 head, 63 sec, 512 bytes/sect x 6306048 sectors
wd0: 32-bits data port
wd0: drive supports PIO mode 4, DMA mode 2, Ultra-DMA mode 2
wd0(pciide0:0:0): using PIO mode 4, DMA mode 2 (using DMA data transfers)
pciide1 at pci0 dev 8 function 2: Contaq Microsystems CY82C693 IDE Controller
pciide1: hardware does not support DMA
pciide1: primary channel wired to compatibility mode
pciide1: disabling primary channel (no drives)
ohci0 at pci0 dev 8 function 3: Contaq Microsystems 82C693 PCI-ISA Bridge (rev. 0x00)
ohci0: couldn't map interrupt
de0 at pci0 dev 9 function 0
de0: interrupting at eb164 irq 8
de0: 21140A [10-100Mb/s] pass 2.2
de0: address 00:c0:f0:30:03:c0
de0: enabling 100baseTX port
isa0 at sio0
com0 at isa0 port 0x3f8-0x3ff irq 4: ns16550a, working fifo
com0: console
com1 at isa0 port 0x2f8-0x2ff irq 3: ns16550a, working fifo
lpt0 at isa0 port 0x3bc-0x3bf irq 7
pckbc0 at isa0 port 0x60-0x64
pcppi0 at isa0 port 0x61
spkr0 at pcppi0
isabeep0 at pcppi0
fdc0 at isa0 port 0x3f0-0x3f7 irq 6 drq 2
fd0 at fdc0 drive 0: 1.44MB, 80 cyl, 2 head, 18 sec
mcclock0 at isa0 port 0x70-0x71: mc146818 or compatible
WARNING: can't figure what device matches "IDE 0 108 0 0 0 0 0"
root on wd0a dumps on wd0b
de0: enabling 100baseTX port
de0: abnormal interrupt: transmit underflow (raising TX threshold to 96|256)
de0: abnormal interrupt: transmit underflow (raising TX threshold to 128|512)
alpha1$ 


On a side note, I take it the de0 messges are normal, as I have even seen
the same thing on an Intel/FreeBSD machine in the past...

-Howard


> On Tue Aug 31 19:29:14 1999, Ross Harvey wrote:
> > > From: Howard Leadmon <howardl@abs.net>
> [..]
> > > First, when I boot from SRM to the hard-drive, everything seems like it's 
> > > going great.  I see the primary loader run, then the secondary, and it
> > > initializes all the devices.  Finally it goes to mount the root filesystem
> > > and I get a message like telling me it can't. here is the msg from the 
> > > logs:
> > >
> > > WARNING: can't figure what device matches "IDE 0 108 0 0 0 0 0"
> > 
> > Sigh, SRM has gone back and forth on how it identifies IDE boot devices
> > for that board. Some SRM versions call them SCSI, some IDE, and now it
> > looks like sometimes the device is in the 100s digit and sometimes in the
> > 1000s digit. Maybe the SCSI-happy SRM uses the 4-digit and the IDE-
> > happy SRM uses the 3? Or maybe my quick guess is just wrong...
> 
> A SRM before v5.3 use that on my 164LX:
> 
> SCSI 0 11 0 0 0 0 0
> 
> v5.3 or higher use:
> 
> IDE 0 11 0 0 0 0 0
> 
> > Either way, this is an easy kernel fix, except that it looks like the
> > obvious fix will break platforms it presently works fine on. So, either
> > say "root on wd0" in your kernel config, or hack (if the board is system
> > type 26, "eb164", I'm not sure) dec_eb164_device_register() in
> > /sys/arch/alpha/alpha/dec_eb164.c to recognize the `108' properly.
> 
> We don't look for the number, we just check for BOOTP, SCSI or IDE.
> 
> > Actually, one of us (Veego?!) can do that for you, if you will send me or
> > post your dmesg. And it would be really cool if you could s/#if 0/#if 1/
> > around the printf's in that above module first, and then use _that_ kernel
> > for the dmesg you send us.
> 
> Yup, I can help when I get the dmesg output.
> 
> Maybe I can put an current kernel this weekend on an ftp server which contains
> the debug code.
> 
> Bernd
> 


---
Howard Leadmon - howardl@abs.net - http://www.abs.net
ABSnet Internet Services - Phone: 410-361-8160 - FAX: 410-361-8162