Re: 2.6.25 semantic change in bay handling?

[Matthew Garrett <mjg59@srcf.ucam.org>]

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.
-- 
Matthew Garrett | mjg59@srcf.ucam.org