Matthew Garrett wrote:
On Tue, May 06, 2008 at 05:40:39PM +0900, Tejun Heo wrote:
On Mo 05. Mai - 23:33:57, Matthew Garrett wrote:
48feb3c419508487becfb9ea3afcc54c3eac6d80 appears to flag a device as
That should be 233f112042d0b50170212dbff99c3b34b8773cd3, right?
Yeah, my mistake.
The original change was from Holder Macht and IIRC it was to avoid
machine hard lock up on certain laptops which happens when libata EH
goes out to find out what happened when it receives bus/device check
after removal. Maybe what should be done instead is that eject request
doesn't do anything but tells acpid to unmount and delete the block
device by echoing 1 to sysfs delete node.
From my point of view that's fine, but I'd be more interested to know
about the case Holger was having trouble with. For internal bays, at
least, we can't guarantee that we'll get an eject request before the
device is removed - if that leads to hangs, we probably need to work out
a way of being more robust here.
Hmmm... It would be perfect if we can tell whether DEVICE/BUS CHECK is
in which direction (device coming or going away).
Yeah, but I can't see an easy way of doing that. It's not enough to keep
track of the current state and assume that it's either an insertion or
removal as a result - some machines fire bus checks on resume, even if
the bay device hasn't been changed.
All we need is separate out the ejection case out. For suspend, resume,
attach or whatever can be handled the same way. The problem occurs
because some controllers get very unhappy when certain registers are
accessed when there's no device attached to it.
Thanks.
--
tejun
--
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
