Tejun!
Here are my comments on our previous conversation
Well, I partially agree. Surely, EMI problems should not break the link
forever but I do not agree with the algorithm. When the drive is being
removed it gets out during millisectonds. I mean the time between loss
of link and detection that port is not populated. So, I can imagine that
driver could be going to retry reset one but it had to abort this action
once it got the drive is removed at all. Not in 15 second and even not
in 5 seconds but in 0.01 second. So,
Heh... that will fail any EMI test. There simply isn't anything to be
earned by shortening the period. The only thing that can go wrong
with longer delay is if the user unplugs the drive, plugs it in
another host modifies the content and replug it before the detach
happens. If the user does that, well, he/she deserves a corrupt
filesystem.
I think you are not right here. If we are talking about EMI problems I
can say that the strategy of many retries is worse than one read of port
present status. EMI noise occurs at the time while software tries to
re-establish connection with empty link because there is no link
terminatiion. It's just like a car engine that has lost its muffler. It
produces lots of noise. It is better to turn the link off as soon as we
know there is no device on the port. That's why retries should last only
until that state is reported by hardware. And I think hardware reports
that state much faster than in 15 or even 5 seconds. In ICH9 it reports
this just immediately.
That's SCSI sd driver shutting down. As hot unplugging is
surprise-removal, sd's shutdown sequence arrives after the device is
actually gone and failed immediately.
Ok. So, this is notmal. We just need to inform SCSI driver first, isn't it?
If you hot unplug, how do you notify SCSI driver first?
Well, there are some strange comments in FAQs that older ICH chips (5 to
8) do not fully support hot plug, while the newer ones have better
support for this. Then there is an explanation of what is proper hotplug
support. That explanation says of surprise-removal support. However, I
do not mind of notifying system before a actually remove the drive. Just
because it may take a long time to shut down drive activity and it will
be better to indicate this explicitly to user.
Well, some drives store their firmware on disk, so they cannot work with
host until fully spinned up. I heard that drive started to spin up in
two or more seconds after being inserted. So, what is the indended
driver behavior? It simply performs soft resets until drive answer ot
this, isn't it? If the drive gets ready faster it will be fewer failed
soft resets in log, right?
The goal is being robust. With numerous hardware combinations, that's
about the only way to keep things manageable. Things don't always
work as described in the spec. Again, the only down side is one or
more failed attempts and log about those. Why do you care?
It's just because one of my jobs is writing high performance embedded
real-time software were logs are almost the only way to know what
happens in hardware. After several years of such practice there is a
habit of suspecting side effects of each stralge log line. That's whay I
do care :-)
I just want to understand that this softreset failure is a normal
behavior for that particular case.
ahci doesn't use PCS to detect dummy ports. It uses PORT_IMPL ahci
register. If PORT_IMPL changes according to which ports are occupied
that's a BIOS bug. Can you post the output of "dmidecode"?
Yes, you were right, it was a BIOS bug. I have downloaded latest BIOS
from the vendor's web site and now PI register allways reports all six
ports implemented.
echo 1 > /sys/block/sdX/device/delete
Can I be sure this will stop the drive sefely (without of cached data
loss)?
Yes.
Ok. So, one more question. How can I know exactly when device deletion
has completed after sending this command? For example, consider that
there some data in cache that needs 3 seconds to be sync-ed to disk. How
can I know that I must wait for 3 seconds before a can actually remove
the drive? Should I check the presence of some other filename in
/sys/block/sdX/ or do something else?
Thank you!
With best regards, Vladimir Dashevsky
--
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
