Re: kern/57063: Kernel panic in -current in iic_attach

[Brad Spencer <brad%anduin.eldar.org@localhost>]

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

From: Brad Spencer <brad%anduin.eldar.org@localhost>
To: Paul Goyette <paul%whooppee.com@localhost>
Cc: gnats-bugs%netbsd.org@localhost, kern-bug-people%netbsd.org@localhost, gnats-admin%netbsd.org@localhost,
        netbsd-bugs%netbsd.org@localhost
Subject: Re: kern/57063: Kernel panic in -current in iic_attach
Date: Tue, 18 Oct 2022 14:17:01 -0400

 Paul Goyette <paul%whooppee.com@localhost> writes:
 
 > On Tue, 18 Oct 2022, Brad Spencer wrote:
 >
 > <big snip>
 >
 >> o If you comment out the type check in dwiic_init and and try to use the
 >> device I have anyway you do not appear to get a panic anywhere, but the
 >> driver reports fails in other ways indicating that the device I have
 >> really won't work with the driver:
 >>
 >> [     1.000003] dwiic0 at pci0 dev 21 function 0: I2C controller instance 0
 >> [     1.000003] dwiic0: interrupting at ioapic0 pin 16
 >> [     1.000003] dwiic0: failed to disable
 >> [     1.000003] dwiic0: failed to disable
 >> [     1.000003] iic0 at dwiic0: I2C bus
 >> [     1.000003] dwiic1 at pci0 dev 21 function 1autoconfiguration error: : can't map register space
 >
 > Sounds to me like maybe the dwiic driver should make this ``type
 > check'' during dwiic_match() and fail there.
 >
 >
 > +--------------------+--------------------------+----------------------+
 > | Paul Goyette       | PGP Key fingerprint:     | E-mail addresses:    |
 > | (Retired)          | FA29 0E3B 35AF E8AE 6651 | paul%whooppee.com@localhost    |
 > | Software Developer | 0786 F758 55DE 53BA 7731 | pgoyette%netbsd.org@localhost  |
 > | & Network Engineer |                          | pgoyette99%gmail.com@localhost |
 > +--------------------+--------------------------+----------------------+
 
 
 What Jason said..  match routines probably should not do that.
 
 I can't work on this again right now, but looking at the driver code
 suggests that return values are ignored in a number of places where they
 probably should not be and this is true for all attachment types, as best
 as I can tell.
 
 I also suspect that someone else, someday, will run into this same thing
 again unless I got REALLY lucky in picking a motherboard with that
 particular chip variant in it (this isn't impossible, the motherboard
 was designed some time ago and it may be the case that the chip I have
 is older than what the driver was meant for).  There is nothing at all
 that suggests that this is limited to a Xen DOM0 kernel and probably
 will panic in the same way with GENERIC.
 
 
 
 
 -- 
 Brad Spencer - brad%anduin.eldar.org@localhost - KC8VKS - http://anduin.eldar.org