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

[Rin Okuyama <rokuyama.rk%gmail.com@localhost>]

On 2022/08/28 20:28, Izumi Tsutsui wrote:
> > 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..

I've checked that -current kernel as of today with DIAGNOSTIC boots
successfully into multiuser on Jornada 690. (Older) dmesg is:

https://dmesgd.nycbug.org/index.cgi?do=view&id=6287

> > 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.

Thanks for explanation. It would be useful to have some comments in
the source code.

Thanks,
rin