Re: 2.6.25-rc2 System no longer powers off after suspend-to-disk.Screen becomes green.

[Greg KH]

On Thu, Feb 21, 2008 at 05:05:32PM +1100, Nigel Cunningham wrote:
> Hi Greg.
>
> Greg KH wrote:
>> On Thu, Feb 21, 2008 at 12:17:06PM +1100, Nigel Cunningham wrote:
>>> Hi.
>>>
>>> Greg KH wrote:
>>>> On Thu, Feb 21, 2008 at 11:40:06AM +1100, Nigel Cunningham wrote:
>>>>> Hi.
>>>>>
>>>>> Matthew Garrett wrote:
>>>>>> On Thu, Feb 21, 2008 at 09:45:02AM +1100, Nigel Cunningham wrote:
>>>>>>> - people keep talking about hibernating to an ext3 fs mounted on fuse 
>>>>>>> as a limitation of the freezer. To do that with kexec, you're still 
>>>>>>> going to have to bmap the ext3 fs and pass the block list (in which 
>>>>>>> case we can also do it without kexec) or umount all the ext3/fuse 
>>>>>>> part and remount in the kexec'd kernel. Sort of defeats the purpose, 
>>>>>>> doesn't it?
>>>>>> No, with a freezer-based model you can basically *never* suspend to 
>>>>>> anything related to FUSE or a userspace USB device or anything 
>>>>>> involving userspace iSCSI initiators or whatever. Sure, there are 
>>>>>> cases where moving away from the current model doesn't buy you 
>>>>>> anything, but that doesn't mean that the current model is a good 
>>>>>> thing. It's not. The freezer is a fundamentally broken concept.
>>>>> Putting drivers and filesystems in userspace is the fundamentally 
>>>>> broken concept. Not just when it comes to the freezer. The whole idea 
>>>>> is inherently racy.
>>>> Racy with regards to other things becides trying to suspend a machine?
>>>> If so, what?
>>> That depends on what sort of tangled web you want to weave.
>> Lots of them :)
>> We have tanks running Linux using userspace USB drivers for vision
>> control systems (scary, I know...)  They seem to be successfully running
>> for many years now, and I'm interested in making sure those kinds of
>> things keep working.
>> We also have laser welding robots with userspace PCI drivers in car
>> manufacturing plants.  And other laser cutting robots slicing wood in
>> patterns moving at a rate of over 3 meters a second.  Again, with
>> userspace drivers and Linux.
>> Those users would also love to know of any potential problems you know
>> of for this situation.
>>> Low memory situations is one other situation that occurs to me
>>> quickly, especially (though not only) if your ability to swap were to
>>> depend upon a userspace driver and/or filesystem.
>> Sure, swap over a userspace filesystem or driver isn't a sane idea.  And
>> neither is swaping over NFS over a PPP connection attached to a USB to
>> serial device.  Yes, it's possible, and all in the kernel, but not a
>> wise decision.
>> Other than foolish configurations, if you come up with other issues
>> surrounding userspace drivers that could cause problems, please let me
>> know.
>
> A simple OOM condition isn't an issue? Surely a driver stalling because 
> some of its memory gets swapped out just before it goes to use it would be 
> a problem if it resulted in getting the length of a cut wrong or caused 
> some distorted vision or a late turn :>
>
> Am I missing something? Maybe these drivers mlock memory to avoid those 
> issues or something like that?

I think the mlock their memory to prevent this from happening, it's not
hard when you control all the applications on the box :)

thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/