Subject: Re: IBM DCAS & esp => panic
To: port-mac68k <port-mac68k@NetBSD.ORG>
From: Frederick Bruckman <fredb@fb.sa.enteract.com>
List: port-mac68k
Date: 03/18/1998 13:05:19
On Tue, 17 Mar 1998, Hauke Fath wrote:

> Hi,
> 
> has anyone out there gotten a '040 machine (esp SCSI driver) to work with
> an IBM DCAS? I'm sitting in front of a brand new shining 4GB disk, and all
> I get on the first disk access from NetBSD ('disklabel', 'newfs', 'tar',
> whatever) is
> 
> # disklabel sd1
> # /dev/rsd1c:
> type: SCSI
> disk: SCSI disk
> label: fictitious
> flags:
> bytes/sector: 512
> sectors/track: 171
> tracks/cylinder: 6
> sectors/cylinder: 1026
> cylinders: 8205
> total sectors: 8467200
> rpm: 3600
> interleave: 1
> trackskew: 0
> cylinderskew: 0
> headswitch: 0           # milliseconds
> track-to-track seek: 0  # milliseconds
> drivedata: 0
> 
> 8 partitions:
> #        size   offset    fstype   [fsize bsize   cpg]
>   a:   830884       96      4.2BSD        0     0     0   # (Cyl.    0*- 809*)
>   b:   307200  2888406        swap                        # (Cyl. 2815*- 3114*)
>   c:  8467200        0      unused        0     0         # (Cyl.    0 - 8252*)
>   d:   356093  7073064         HFS                        # (Cyl. 6893*- 7240*)
>   e:   435224  2453182      4.2BSD        0     0     0   # (Cyl. 2391*- 2815*)
>   f:  1226543  3195606      4.2BSD        0     0     0   # (Cyl. 3114*- 4310*)
>   g:  1622202   830980      4.2BSD        0     0     0   # (Cyl.  809*- 2391*)
>   h:   672620  4422149      4.2BSD        0     0     0   # (Cyl. 4310*-
> 4Kernel
>  Illegal Instruction trap.
> trap: type 0x2, code 0x0, v 0x0
> kernel: Illegal instruction trap
> pid = 3, pc = 00000028, ps = 2708, sfc = 1, dfc = 1
> Registers:
>              0        1        2        3        4        5        6        7
> dreg: 000000FF 0000000C 00000000 00002004 00000100 00000120 00000000 00000040
> areg: 0074A040 0074A000 000ECCC8 004F6000 0074CF80 004F6000 0074CEEC FFFFCBC8
> 
> Kernel stack (0074CE30):
> 74CE30: 000C6556 0074CE7C 00000080 00000000 00002004 00000100 00000120 00000000
> 74CE50: 00000040 000ECCC8 004F6000 0074CF80 004F6000 00000000 0074CEEC 00003080
> 74CE70: 00000002 00000000 00000000 000000FF 0000000C 00000000 00002004 00000100
> 74CE90: 00000120 00000000 00000040 0074A040 0074A000 000ECCC8 004F6000 0074CF80
> 74CEB0: 004F6000 0074CEEC FFFFCBC8 00000000 27080000 00280010 00000000 00000000
> 74CED0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
> 74CEF0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
> 74CF10: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
> 74CF30: 00000000 00000000 00000000 00000000 00000000 504D0000 0000000B 00000060
> 74CF50: 000CADA4 412F5558 20526F6F 74000000 00000000 00000000 00000000 00000000
> 74CF70: 00000000 0050504C 455F554E 49585F53 56523200 00000000 00000000 00000000
> 74CF90: 00000000 00000000 000CADA4 00000037 00000000 00000000 00000000 00000000
> 74CFB0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 ABADBABE
> 74CFD0: 00010001 C0000000 00000000 00000000 00000000 00000000 00000000 00000000
> 74CFF0: 00000000 00000000 00000000 00000000
> panic: Illegal instruction
> Stopped at      _Debugger+0x6:  unlk    a6
> db> t
> _Debugger(0,74ce7c,74ce68,c6574,c6236) + 6
> _panic(c6236,0,2004,100,120) + 50
> _trap(2,0,0) + 1e6
> fault() + c
> db>
> 
> or similar -- fairly reproducible. Now, the first disk access has always
> and with all drivers been critical for MacBSD, but it has never hit me that
> hard. Seems to me the kernel gets hit by an interrupt it isn't prepared
> for. This is in single user, btw.
> 
> If noone tells me this is already fixed  (kernel sources are 1.3B from
> mid-January, but it happens with an 1.3Beta kernel, too), I shall send-pr.
> Sigh...
> 

This looks very familiar. I have a 3.2G Arriva (Quantum) that does the
same thing. I just tried it again with 1.3E and it's NOT fixed. This
problem started sometime after GENERIC-46. Until recently, it would fault
before it printed the disklabel/dump/etc., now at least you can see that
the disklabels are correct.  Problem report 4333 gives fewer details than
you do, but it looks like the same problem again with still another drive.