On Fri, Jul 13, 2001 at 12:01:05PM +0200, Manuel Bouyer wrote:
> [...]
> scsibus0: waiting 2 seconds for devices to settle...
> siop0: alloc newcdb at PHY addr 0xfe01a000
> sd0 at scsibus0 target 0 lun 0: <SEAGATE, ST318404LSUN18G, 4203> SCSI3 0/direct fixed
> sd0: 17274 MB, 7508 cyl, 19 head, 248 sec, 512 bytes/sect x 35378533 sectors
> sd0: sync (50.0ns offset 16), 16-bit (40.000MB/s) transfers, tagged queueing
> sd1 at scsibus0 target 1 lun 0: <SEAGATE, ST318404LSUN18G, 4203> SCSI3 0/direct fixed
> sd1: 17274 MB, 7508 cyl, 19 head, 248 sec, 512 bytes/sect x 35378533 sectors
> sd1: sync (50.0ns offset 16), 16-bit (40.000MB/s) transfers, tagged queueing
> cd0 at scsibus0 target 6 lun 0: <TOSHIBA, DVD-ROM SD-M1401, 1007> SCSI2 5/cdrom removable
> cd0: sync (50.0ns offset 16), 8-bit (20.000MB/s) transfers
> scsibus1: waiting 2 seconds for devices to settle...
> siop1: alloc newcdb at PHY addr 0xfe01c000
> raidattach: Asked for 4 units
> Kernelized RAIDframe activated
> root on hme0
> mountroot: trying msdos...
> mountroot: trying cd9660...
> mountroot: trying lfs...
> mountroot: trying nfs...
> nfs_boot: trying RARP (and RPC/bootparam)
> nfs_boot: client_addr=132.227.63.55 (RARP from 132.227.63.44)
> nfs_boot: server_addr=132.227.63.44
> nfs_boot: hostname=metal
> nfs_boot: gateway=132.227.63.7
> nfs_boot: my_mask=255.255.255.0
> root on jazz:/home/NetBSD/sparc64
> root time: 0x3b4ec586
> root file system type: nfs
> init: copying out flags `-s' 3
> init: copying out path `/sbin/init' 11
> 
> At this point the machine is locked up, it doesn't anserw to ping and
> I can't enter ddb
> 
> i don't understant why this kernel works while the same without 'options DEBUG'
> fails.

It's even worse than that: different boot of the same kernel don't give
the same result: sometimes it goes up to starting /sbin/init, sometimes
it fails to mount the root FS, sometimes RARP/bootparam fails to
find the network parameters, and one time it hung while probing devices on
scsibus0.

Maybe there's something wrong with how devices on the PCI bus are handled ?

--
Manuel Bouyer, LIP6, Universite Paris VI.           Manuel.Bouyer@lip6.fr
--