lkml.org 
[lkml]   [2008]   [Feb]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: 2.6.25-rc2 System no longer powers off after suspend-to-disk. Screen becomes green.
    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?

    Regards,

    Nigel


    \
     
     \ /
      Last update: 2008-02-21 07:09    [W:4.282 / U:0.068 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site