lm0 at isa reboot (was: nouveau reboot)

[Patrick Welche <prlw1%cam.ac.uk@localhost>]

On Fri, Jul 21, 2017 at 10:59:51PM +0100, Patrick Welche wrote:
> On Fri, Jul 21, 2017 at 08:17:44AM +0100, Patrick Welche wrote:
> > On Fri, Jul 21, 2017 at 07:53:09AM +0100, Patrick Welche wrote:
> > > On Thu, Jul 20, 2017 at 09:06:16PM +0000, coypu%sdf.org@localhost wrote:
> > > > On Thu, Jul 13, 2017 at 09:49:32AM +0100, Patrick Welche wrote:
> > > > > or "new" reboot: just updated a working 3rd July amd64
> > > > > kernel with this morning's source, and the computer reboots after
> > > > > printing nouveau, but before drm. Haven't had a chance to dig (won't
> > > > > until tonight) - any first guesses?
> > > > 
> > > > Must be unrelated to nouveau. no changes in sys/external/bsd/drm2 since
> > > > June 1.
> > > 
> > > In the meantime it is getting even more confusing: I bisected to
> > > 
> > > http://mail-index.netbsd.org/source-changes/2017/07/11/msg086253.html
> > > 
> > >     lm(4): Add suport for NCT5174D, NCT6775F, NCT6779D and NCT679[1235]D.
> > >     wbsio(4): Add support for NCT6795D.
> > > 
> > > but then rebooting with disable wbsio (which didn't switch anything off)
> > > and disable lm still failed. Now moving the modules which I haven't kept
> > > in synch during the bisection away.
> > 
> > Moving the modules out of the way now gets consistent results:
> > - unsuccessful boot with the above patch
> > - successful boot with the above patch and "disable lm"
> > 
> > I have no idea what chip is in this box(!)

End conclusion: if I comment out

  #lm0    at isa? port 0x290 flags 0x0    # other common ports: 0x280, 0x310

i.e., have it the way it is in GENERIC, the kernel boots. (With it in, I
get a reboot with nothing printed on the serial console.)

Leaving

  lm*    at wbsio?

is fine.

Adding DEBUG, DIAGNOSTIC, LOCKDEBUG, and leaving lm0 at isa? also appears
to be fine (?!) (and the locking I had in earlier posts also doesn't seem
to tie up with lm, but I did have to have it uncommented.)

Turns out that on 0x290, this Ryzen box has an ITE IT8665E.

Why the bisection hit that commit remains a mystery, as that chip
won't have attached to the driver.


Cheers,

Patrick