On Sun, Apr 15, 2018 at 10:04:13PM -0700, Mike Larkin wrote:
> On Sun, Apr 15, 2018 at 11:47:45PM -0500, Juan Morado wrote:
> > System: OpenBSD 6.3
> > Details: OpenBSD 6.3 (GENERIC.MP) #107: Sat Mar 24 14:21:59 MDT 2018
> > [email protected]:/usr/src/sys/arch/amd64/compile/
> > GENERIC.MP
> >
> > Architecture: OpenBSD.amd64
> > Machine: amd64
> >
> > Description: Touching the track pad of this ASUS X541SA laptop during boot
> > causes a kernel panic when running 6.3. Touching/using the trackpad after X
> > starts causes the system to become unresponsive (hang).
> >
> > How to repeat: Reboot the system, swipe a finger on the track pad while
> > booting. Or use the track pad after the machine has booted and X has
> > started.
> >
> > Fix: no known work around or fix
> >
> > "show panic", trace, ps, and "show registers" output attached in
> > ddb_trace.txt
> >
> > dmesg.txt contains the dmesg.
>
> > addr 1: xHCI root hub, Intel
> > addr 2: USB Flash Disk, General
>
>
> jsg, kettenis? Thoughts?
>
> -ml
>
>
>
>
>
> > Domain /dev/pci0:
> > 0:0:0: Intel Braswell Host
> > 0:2:0: Intel HD Graphics
> > 0:11:0: Intel Braswell Power
> > 0:19:0: Intel Braswell AHCI
> > 0:20:0: Intel Braswell xHCI
> > 0:26:0: Intel Braswell TXE
> > 0:27:0: Intel Braswell HD Audio
> > 0:28:0: Intel Braswell PCIE
> > 0:28:2: Intel Braswell PCIE
> > 0:28:3: Intel Braswell PCIE
> > 0:31:0: Intel Braswell PCU LPC
> > 0:31:3: Intel Braswell SMBus
> > 2:0:0: Realtek 8101E
> > 3:0:0: Realtek 8191SE
>
> > System: OpenBSD 6.3
> > Details: OpenBSD 6.3 (GENERIC.MP) #107: Sat Mar 24 14:21:59 MDT 2018
> >
> > [email protected]:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> >
> > Architecture: OpenBSD.amd64
> > Machine: amd64
> >
> > Description: Touching the track pad of this ASUS X541SA laptop during boot
> > causes a kernel panic. Touching/using the trackpad after X starts causes
> > the system to become unresponsive (hang).
> >
> > How to repeat: Reboot the system, swip a finger on the track pad while
> > booting. Or use the track pad after the machine has booted and X has
> > started.
> >
> > Fix: no known work around or fix
> >
> >
> > ddb{0}> show panic
> > kernel page fault
> > uvm_fault(0xffffffff81afca80, 0xffff8000006f8000, 0, 1) -> e
> > ihidev_intr(ffff8000000d9300) at ihidev_intr+0x18a
> > end trace frame: 0xffff8000314a3ac8, count: 0
> >
> > ddb{0}> trace
> > ihidev_intr(ffff8000000d9300) at ihidev_intr+0x18a
> > intr_handler(0,ffff800000127280) at intr_handler+0x57
> > Xintr_ioapic_level17_untramp() at Xintr_ioapic_level17_untramp+0x12c
> > --- interrupt ---
> > acpicpu_idle() at acpicpu_idle+0x1d9
> > cpu_idle_cycle(0,0,ffffffff81abbff0,ffffffff817e4290,ffffffff817e44b5,fffffff181c1f0)
> > at cpu_idle_cycle+0x10
> > end trace frame: 0x0, count: -5
I'm curious if disestablishing the interrupt handler in attach in the
early returns before sc_ibuf has been allocated changes anything.
Index: ihidev.c
===================================================================
RCS file: /cvs/src/sys/dev/i2c/ihidev.c,v
retrieving revision 1.16
diff -u -p -r1.16 ihidev.c
--- ihidev.c 12 Jan 2018 08:11:47 -0000 1.16
+++ ihidev.c 16 Apr 2018 06:17:48 -0000
@@ -139,8 +139,14 @@ ihidev_attach(struct device *parent, str
(char *)ia->ia_cookie);
sc->sc_nrepid = ihidev_maxrepid(sc->sc_report, sc->sc_reportlen);
- if (sc->sc_nrepid < 0)
+ if (sc->sc_nrepid < 0) {
+ printf("%s: nrepid %d\n", sc->sc_dev.dv_xname, sc->sc_nrepid);
+ if (sc->sc_ih) {
+ intr_disestablish(sc->sc_ih);
+ sc->sc_ih = NULL;
+ }
return;
+ }
printf("%s: %d report id%s\n", sc->sc_dev.dv_xname, sc->sc_nrepid,
sc->sc_nrepid > 1 ? "s" : "");
@@ -150,6 +156,10 @@ ihidev_attach(struct device *parent, str
M_DEVBUF, M_NOWAIT | M_ZERO);
if (sc->sc_subdevs == NULL) {
printf("%s: failed allocating memory\n", sc->sc_dev.dv_xname);
+ if (sc->sc_ih) {
+ intr_disestablish(sc->sc_ih);
+ sc->sc_ih = NULL;
+ }
return;
}
