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

Reply via email to