Re: lm0 at isa reboot

[Masanobu SAITOH <msaitoh%execsw.org@localhost>]

Hi, Patrick

On 2017/07/27 18:28, Patrick Welche wrote:
> 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.


 Driver for ITE's super I/O is itesio(4)


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

 Default I/O port of ITE's super I/O and Winbond(Nuvoton)'s super I/O
the same. Only one or two byte ID of super I/O makes hard to identify.
For our Winbond support, it checks only 8 bits instead of real 12 bits,
so it can be improved. Another problem is that nslm7x.c's xxx_match()
is not match function but attach function, so it also should be improved.

 Until above problems will be solved, don't enable "lm* at wbsio?" on
your machine.


> Cheers,
>
> Patrick


--
-----------------------------------------------
                SAITOH Masanobu (msaitoh%execsw.org@localhost
                                 msaitoh%netbsd.org@localhost)