Re: kern/56982: mutex error (locking against myself) in wdc(4) NOIRQcase?

[Izumi Tsutsui <tsutsui%ceres.dti.ne.jp@localhost>]

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

From: Izumi Tsutsui <tsutsui%ceres.dti.ne.jp@localhost>
To: rokuyama.rk%gmail.com@localhost
Cc: gnats-bugs%netbsd.org@localhost, riastradh%NetBSD.org@localhost, tsutsui%ceres.dti.ne.jp@localhost
Subject: Re: kern/56982: mutex error (locking against myself) in wdc(4) NOIRQcase?
Date: Sun, 28 Aug 2022 20:28:46 +0900

 > wdc(4) with NOIRQ worked on DIGNOSTIC kernel for hpcsh/current a while ago.
 
 Hmm. Maybe I should also check HEAD instead of patched 9.3..
 
 > My guess is: This is because wdc(4) for mac68k is too hackish. As tsutsui@
 > pointed out in port-mac68k/56973, this driver registers interrupt
 > handler, *AND* it also enables polling mode (ATAC_CAP_NOIRQ).
 > 
 > I don't know what exactly goes on, but I *imagine* that sometime interrupt
 > is raised, and sometimes isn't, c.f.:
 
 I don't think it's likely. AFAICT the IDE interrupt has never been
 triggered at least on my LC630, and Linux/m68k also removed these
 interrupt register checks:
  https://lore.kernel.org/linux-ide/11a56b3317df3bb2ddc15fd29b40b6820e9c7444.1623287706.git.fthain%linux-m68k.org@localhost/
  >> This was tested on my Quadra 630. I haven't tested it on my PowerBook 150
  >> because I don't have a RAM adapter board for it. It appears that the
  >> hardware I tested doesn't need macide_clear_irq() or macide_test_irq().
  >> If it did, the generic driver would not have worked. It's possible that
  >> those routines are needed for the PowerBook 150 but we can cross that
  >> bridge if and when we come to it.
 
 ---
 Izumi Tsutsui