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

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/

Relevant Pages