Subject: Re: zero-divide during ffs_mountroot()
To: Mike Hibler <mike@cs.utah.edu>
From: John Brezak <brezak@apollo.hp.com>
List: port-hp300
Date: 09/14/1994 15:27:05
> > ...
> > NetBSD 1.0_BETA (HELIX) #1: Mon Sep  5 02:51:55 PDT 1994
> >     thorpej@santiam:/tmp_mnt/hurricane/NetBSD/src/sys/arch/hp300/compile/HE
LIX
> > HP9000/433 (33MHz MC68040 CPU+MMU+FPU, 4k on-chip physical I/D caches)
> > ...
> > scsi0: 32 bit dma, async, scsi id 7
> > scsi0 at sc14, ipl 4
> > sd9: TOSHIBA CD-ROM DRIVE:XM rev 3332
> > sd9 at scsi0, slave 0
> > sd0: HP 2213A rev C023, 1296512 512 byte blocks
> > sd0 at scsi0, slave 5
> > sd1: HP 2213A rev C023, 1296512 512 byte blocks
> > sd1 at scsi0, slave 6
> > ...
> > WARNING: using device at unit 0 of controller
> > Changing root device to sd9a
> > sd9: scsi sense class 7, code 2, key 2
> > sd9: WARNING: unformatted/missing media, defining `c' partition as entire d
isk
> > trap type 3, code = 0, v = 0
> > kernel: Zero divide trap
> > stopped at   ___qdivrem+0x2c:       movl   d1,-0x22(a6)
> > 
> 
> Finally took a look at this again.  Someone has changed the interpretation
> of "bootdev" in the standalone code but not the kernel.  The original
> fragment of stand/autoconf.c:msustobdev() is:
> 
>         bdev |= ((rp->msus >> 16) & 0xFF) << B_UNITSHIFT;
>         bdev |= (rp->msus & 0xFF) << B_CONTROLLERSHIFT;
>         bdev |= (int)hw->hw_pa << B_ADAPTORSHIFT;
> 
> while in netbsd it is:
> 
>         bdev |= ((rp->msus >> 16) & 0xFF) << B_ADAPTORSHIFT;
>         bdev |= (rp->msus & 0xFF) << B_UNITSHIFT;
>         bdev |= (int)hw->hw_pa << B_CONTROLLERSHIFT;
> 
> in other words, what used to be considered the "controller" (slave 6) is
> now considered the "unit" and hence the problems in the kernel's autoconf.
> 
> While there is a certain appeal to mapping the SCSI/HPIB slave to the "unit"
> rather than the "controller", it is technically wrong.  If any slave were
> to support more than one LUN, it would not work.

There was a reason for changing this, but I can't remember what it was. It
did have something to do with SCSI disks not mapping to the definitions of
what the HPIB disks wanted (or something like that). I'll try to have a look
at it again.


=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
 John Brezak                    UUCP:     uunet!apollo.hp!brezak
 Hewlett Packard/Apollo         Internet: brezak@ch.hp.com
 300 Apollo Drive               Phone:    (508) 436-4915
 Chelmsford, Massachusetts      Fax:      (508) 436-5140