:It doesn't panic anymore, but it says `Device on port is bricked'.
:Increasing the timeout in ahci_poll() command on line 145 doesn't help
:(same console message).
The actual source of the error is from ahci_port_hardreset() in ahci.c.
I would like you to maintain the applied patch, adjust the timeout
in the ahci_pm.c code back to what it was, and then modify the
ahci_port_hardreset() code as follows:
/*
* We got something that definitely looks like a device. Give
* the device time to send us its first D2H FIS. Waiting for
* BSY to clear accomplishes this.
*
* NOTE that a port multiplier may or may not clear BSY here,
* depending on what is sitting in target 0 behind it.
*/
ahci_os_sleep(100); <<<<<<<<<<<<<<<< ADD
ahci_flush_tfd(ap);
CHANGE TIMEOUT
vvvv
if (ahci_pwait_clr_to(ap, 7000, AHCI_PREG_TFD,
AHCI_PREG_TFD_STS_BSY | AHCI_PREG_TFD_STS_DRQ)) {
error = EBUSY;
} else {
If that works please try going back to the 3000 timeout that was there,
but leaving the ahci_os_sleep() added in. You can also try increasing
the timeout value in the ahci_os_sleep() from 100 to 1000.
Either the PHY is cycling during the hardreset, which is the device's
fault (not the chipset), or the HCA is not masking status changes during
the phy DETect phase, or the device is taking exra-long to come out
of reset.
:By the way the controller is JMB360 from JMicron, and I found a very
:old patch against linux kernel:
: http://lkml.org/lkml/2006/1/29/2
:
:but the driver has been quite reorganized since then, so I have no idea
:how this patch fits in our ahci driver.
Hmm. It doesn't look applicable but you could always try it. We
already do the Intel mod. We don't do that device-specific mod
and I would be a bit leery of adding it.
-Matt
Matthew Dillon
<dillon@backplane.com>