On 14/08/17 01:40, Christian Weisgerber wrote:
Jonathan Matthew:

Better version that actually preserves the port command register state across
resets, rather than throwing it away and replacing it with garbage:

This appears to break ahci on the OverDrive 1000:

...
ahci0 at simplebus0: AHCI 1.3
scsibus0 at ahci0: 32 targets
ahci0: stopping the port, softreset slot 31 was still active.
ahci0: failed to reset port during timeout handling, disabling it
...
bootfile: sd0a:/bsd
boot device: lookup sd0a:/bsd failed
root device:

(There's still a long pause after the "ahci0 at simplebus0" line, too.)

The problem here is that the portreset process is reentrant in some cases, and when the first portreset finishes, it sets the command register to 0 since the second one cleared ap->ap_saved_cmd when it finished. Not clearing ap_saved_cmd makes it work again, but that's a bit nasty. I'll see if I can figure out how to untangle this so it doesn't have to be reentrant. I'm sure this has caused problems before.

The delay there is happening because one of the port multiplier probe commands is timing out. I'm not sure whose fault this is yet.

Reply via email to