Hi. On Fri, 2005-08-05 at 07:45, Pavel Machek wrote: > Hi! > > > > > > > Good question. I'm not certain if Pavel intended to add > > > > > > device_suspend(PMSG_FREEZE) to the reboot path. It was > > > > > > there in only one instance. Pavel comments talk only about > > > > > > the suspend path. > > > > > > > > > > Yes, I think we should do device_suspend(PMSG_FREEZE) in reboot path. > > > > > > > > Why? > > > > > > Many bioses are broken; if you leave hardware active during reboot, > > > they'll hang during reboot. It is so common problem that I think that > > > only sane solution is make hardware quiet before reboot. > > > > Sorry for my slow reply. > > > > If I remember correctly PMSG_FREEZE was intended solely for stopping > > activity when suspend to disk implementations are about to do their > > Well, I think that PMSG_FREEZE can be handy when we want to stop > activity for other reasons, too... > > > atomic copies. I thought that ide reacts to this message by putting a > > hold on queues, but doesn't otherwise do anything to prepare a drive for > > a restart. If that's true, using FREEZE here isn't going to stop drives > > from doing their emergency shutdown actions. Don't we need PMSG_SUSPEND > > instead? > > Spinning disk down is not neccessary for reboot. Users will be angry > if we do it before reboot...
Yes, but I understood (perhaps wrongly) that we were discussing the shutdown path. Nevertheless, for rebooting, you don't want to simply freeze the queue - you want to flush the queue and tell the drive to flush too. For freeze, you may well flush the queue, but you might not necessarily force the drive to flush its queue too. Regards, Nigel -- Evolution. Enumerate the requirements. Consider the interdependencies. Calculate the probabilities. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
