On 11/03/16(Fri) 18:26, Stefan Sperling wrote:
> On Fri, Mar 11, 2016 at 02:58:12PM +0100, Stefan Sperling wrote:
> > Here's another suggestion which doesn't impact the code path for
> > other interrupts. Fixes the problem just as well.
>
> This also helps -- all ideas in here from deraadt@.
>
> It's better than my other diffs, but we're not entirely sure if this
> is the best possible fix.
This looks weird. I don't think you want to write anything if you did
not handle any condition.
But taking a step back, why is the SMBALERT firing constantly on your
system, what does that mean? If it is always on when you have a USB
interrupt then this really smells like the symptom of something else.
But if we're always ignoring this condition then why don't we mask it
in hardware?
> Index: ichiic.c
> ===================================================================
> RCS file: /cvs/src/sys/dev/pci/ichiic.c,v
> retrieving revision 1.37
> diff -u -p -r1.37 ichiic.c
> --- ichiic.c 7 Dec 2015 02:56:36 -0000 1.37
> +++ ichiic.c 11 Mar 2016 17:22:10 -0000
> @@ -340,17 +340,18 @@ ichiic_intr(void *arg)
>
> /* Read status */
> st = bus_space_read_1(sc->sc_iot, sc->sc_ioh, ICH_SMB_HS);
> +
> + /* Clear status bits */
> + bus_space_write_1(sc->sc_iot, sc->sc_ioh, ICH_SMB_HS, st);
> +
> if ((st & ICH_SMB_HS_BUSY) != 0 || (st & (ICH_SMB_HS_INTR |
> ICH_SMB_HS_DEVERR | ICH_SMB_HS_BUSERR | ICH_SMB_HS_FAILED |
> - ICH_SMB_HS_SMBAL | ICH_SMB_HS_BDONE)) == 0)
> + ICH_SMB_HS_BDONE)) == 0)
> /* Interrupt was not for us */
> return (0);
>
> DPRINTF(("%s: intr st 0x%b\n", sc->sc_dev.dv_xname, st,
> ICH_SMB_HS_BITS));
> -
> - /* Clear status bits */
> - bus_space_write_1(sc->sc_iot, sc->sc_ioh, ICH_SMB_HS, st);
>
> /* Check for errors */
> if (st & (ICH_SMB_HS_DEVERR | ICH_SMB_HS_BUSERR | ICH_SMB_HS_FAILED)) {
>
