On Thu, Dec 13, 2001 at 10:55:54AM +0100, [EMAIL PROTECTED] wrote: > it seems my explanation was too short. > > Firstly, let me clarify that the problem is with _reloading_ firmware > due to resumption from power management. > > During resumption from power save, our ability to allocate memory is > severly constrained. We may allocate memory only with GFP_NOIO or > GFP_ATOMIC. This is because anything else might lead the kernel to > paging out a page to a device which has not yet resumed operations or > even the device whose firmware we want to reload. This is independent of > where the actual firmware files are located. The memory consumption itself > causes the deadlock. This affects storage devices and thanks to nfs all > network devices. > > Therefore no user space task can be running during resumption, unless it > is totally mlocked. > Managing firmwarereload in user space when you can neither open() nor > fork() nor read() doesn't look so attractive, does it ? > > To summarise, we can either have firmware handling in user space or power > management, but not both. > More philosophically speaking, IMHO we have a classical layering violation > caused by wishful thinking. > To quote Dave: "There are many good reasons to have device handling in > kernel space." I might add: They are sometimes less than obvious.
We still could delay initializing all devices that need firmware re-load (or any other user space helper) until all those who don't need it are initalized. Anyway, as said before - recovery from a suspend is a dependency tree. And then we can happily page out or read in any page or data we need during the firmware reload. As said before, it's up to the user not to create cycles in the dependency tree for example by putting the firmware on the firmware needing drive itself. -- Vojtech Pavlik SuSE Labs _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
