Re: kern/56131: mount WAPBL SCSI disk causes panic

[David Holland <dholland-bugs%netbsd.org@localhost>]

The following reply was made to PR kern/56131; it has been noted by GNATS.

From: David Holland <dholland-bugs%netbsd.org@localhost>
To: gnats-bugs%netbsd.org@localhost
Cc: 
Subject: Re: kern/56131: mount WAPBL SCSI disk causes panic
Date: Wed, 9 Jun 2021 01:04:40 +0000

 On Mon, Apr 26, 2021 at 02:40:01PM +0000, rokuyama.rk%gmail.com@localhost wrote:
  > | panic: LIST_INSERT_HEAD 0x9f401c ../../../../kern/subr_pool.c:494
  > | [...]
  > | panic(337b6b,9f401c,38266f,1ee,1020) + c
  > | pool_put(418fa8,9f5910,9f5920,0,9c23e0) + 2e4
  > | scsipi_put_xs(9f5910,6,9f59a4,91e5ccc,91e5cd0) + e8
  > | scsipi_execute_xs(9f5910,9c23d8,9f59a4,91e5c42,6) + 2f2
  > | scsipi_command(c2ad04,91e5c42,6,91e5ccc,17) + 78
  > | scsipi_mode_sense(c2ad04,8,8,91e5ccc,17,20,4,1770) + 4c
  > | sd_mode_sense(c18dc0,8,91e5ccc,13,8,20,91e5cc8) + 80
  > | sdioctl(?)
  > | bdev_ioctl(0,408,40046474,c749e0,2,c50680) + 1a2
  > | spec_ioctl(91e5d40,38e684,c0a1e4,40046474,c749e0) + 10a
  > | VOP_IOCTL(c0a1e4,40046474,c749e0,2,fffffffe) + 38
  > | wapbl_start(c2703c,c27000,c0a1e4,0,f02e20,7440,200,0,180e5c,180f5e) + 2fc
  > | ffs_wapbl_start(c27000) + 296
  > | ffs_mount(?)
  > | VFS_MOUNT(c27000,ffff9200,9b26a0,91e5efc) + 402
  >
  > [...]
  > 
  > This is almost reproducible when fsck is not executed before mount
  > (even if file system is clean). Running fsck seems to reduce probability
  > of panic somehow, but not 100%. This panic does not take place if WAPBL
  > is disabled (``log'' is discarded from fstab/command line).
  > 
  > Also, other mac68k machine (Quadra 800) with other variant of esp(4),
  > panic does not occur even if WAPBL enabled.
 
 So it must be the driver (rather that wapbl) that's wrong. My guess is
 that there's some pattern of I/Os or maybe a timing issue that makes
 it blow up, and that because running fsck flushes the journal, it
 reduces the probability of seeing the pattern.
 
 It looks like the apparently missing step between wapbl_start and
 VOP_IOCTL is wapbl_dkcache_init() being inlined, in which case the
 ioctl is DIOCGCACHE. That might or might not be useful info though,
 since it looks like the problem is that the pool is corrupt...
 
 -- 
 David A. Holland
 dholland%netbsd.org@localhost