Re: 2.6.25 semantic change in bay handling?

[Holger Macht <hmacht@suse.de>]

On Di 06. Mai - 09:46:25, 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.

Right, so you never can rely on receiving a BAY_EVENT. Why not just
disregard this case and looking for a common solution?

Regards,
	Holger

> > 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.