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