On Sat, Jul 9, 2016 at 6:08 AM, joshua stein <j...@openbsd.org> wrote: > On Fri, 08 Jul 2016 at 22:34:34 -0700, Philip Guenther wrote: >> On Fri, Jul 8, 2016 at 4:51 PM, joshua stein <j...@openbsd.org> wrote: >> > If the EC fails to go into burst mode for whatever reason, the Burst >> > Acknowledge byte will not be there to read, which means the status >> > won't have EC_STAT_OBF, which means acpiec_wait will spin forever, >> > hanging the machine. >> > >> > This at least gets us moving again, ignoring the failure to enter >> > burst mode. >> >> Is it truly failing to enter burst mode, or are we just not doing the >> dance to enter correctly? Looks like we should be waiting for an SCI >> and checking for a burst acknowledge byte? > > All subsequent status fetches show that burst is not on.
No newer bios for this thing? :-( ... >> So if it doesn't immediately set either the burst or OBF flag then >> we'll continue on without reading the data? That's going to break >> systems where EC isn't always fast to respond, no? > > That's why the diff also includes the change to acpiec_write_cmd to > wait until IBF is 0, so it won't get to that new status check until > the controller has processed the EC_CMD_BE fully. I don't think the spec guarantees that implication, though it may be true in practice. <shurg> Wonder what Windows and Linux do on this thing. Anyway, this diff would need to be tested broadly on *unaffected* hardware to gain confidence it doesn't hurt some box that doesn't have this brokeness. Philip Guenther
