> Date: Wed, 11 Feb 2015 09:05:23 +1000 > From: Philip Guenther <[email protected]> > > On Tue, 10 Feb 2015, enuhtac wrote: > ... > > But unfortunately this does not affect the "ehci_sync_hc: tsleep() = 35" > > error. > > Strangely it seams that "35" means that the code has been compiled without > > the macro "_KERNEL" being defined (in this case "tsleep" is a macro that > > expands to "35"). > > Hmm? That message is from this code: > ... > do { > /* ask for doorbell */ > EOWRITE4(sc, EHCI_USBCMD, EOREAD4(sc, EHCI_USBCMD) | > EHCI_CMD_IAAD); > DPRINTFN(1,("ehci_sync_hc: cmd=0x%08x sts=0x%08x\n", > EOREAD4(sc, EHCI_USBCMD), EOREAD4(sc, EHCI_USBSTS))); > /* bell wait */ > error = tsleep(&sc->sc_async_head, PZERO, "ehcidi", hz / 2); > DPRINTFN(1,("ehci_sync_hc: cmd=0x%08x sts=0x%08x\n", > EOREAD4(sc, EHCI_USBCMD), EOREAD4(sc, EHCI_USBSTS))); > } while (error && ++tries < 10); > splx(s); > /* release doorbell */ > rw_exit_write(&sc->sc_doorbell_lock); > #ifdef DIAGNOSTIC > if (error) > printf("ehci_sync_hc: tsleep() = %d\n", error); > #endif > ... > > 35 == EWOULDBLOCK, which according to tsleep(9) manpage means the tsleep > timed out. So, this function is repeatedly setting some hardware > registers to get a "doorbell" interrupt, then waiting .5 second for it. If > it doesn't get that after 10 tries, it gives up and prints that message > showing the actual failure of "sleep until woken up" call. > > So, is the interrupt not happening? Does, but the interrupt handler > doesn't think it should do a wakeup? etc...
Yeah, this is fairly typical when interrupts aren't mapped properly. Given the random garbage in some of the ACPI tables, I'm not confident the BIOS contains more lies. A new dmesg would be appreciated.
