Re: Bisects that are neither good nor bad

Hi!

With the resume failure I'm seeing, we don't get back to userspace
to run anything like this. It goes bang long before that.

The SATA fix Mark proposed also didn't improve the situation for me :-/

If setserial -a is needed.. it means that someone really needs to fix
suspend/resume support for serial... do it on working machine to
enable debugging of broken ones...

I've explained why this occurs in bugzilla - but for the sake of
repeating repeating repeating myself at great length, let's repeat
it again here.

The serial layer does _not_ have access to the "current" termios
settings due to the layering by the tty subsystem. If the serial
port being used by serial console has been opened once by the user,
but is closed at the moment when a suspend/resume cycle occurs,
the serial layer and lower level drivers do not have access to the
baud rate.

Could serial layer just cache "last baud rate" in some kind of
software shadow register? Yes, it is slightly ugly, but should do the trick.

Hence, it is impossible for the serial layer to do a proper resume
in this scenario. Either always suspend with the console port open
or never open the console port before suspend. Alternatively, we
need the tty layer to mature, so that there is some way for drivers
to get the termios structures for the console from the upper layer.
Or maybe we need the tty layer to be responsible for implementing
suspend/resume support for tty devices.

Pavel

--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
-
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

  • Re: Bisects that are neither good nor bad
    ... >> Serial console was useless. ... but is closed at the moment when a suspend/resume cycle occurs, ... it is impossible for the serial layer to do a proper resume ... Or maybe we need the tty layer to be responsible for implementing ...
    (Linux-Kernel)
  • Re: Deadlock in serial driver 2.6.x
    ... like the tty structure staying around during the interrupt processing. ... We call into the tty layer, and the tty layer calls us back via the ... into serial drivers when they supply read characters from their interrupt ...
    (Linux-Kernel)
  • Re: [PATCH V2 0/4] introduce device async actions mechanism
    ... device suspend/resume are split into several stages. ... callbacks of every device should be put into one of these stage. ... or else we need to use the async cookies to handle the device ... executed in parallel and where the PM callbacks from layer 1 should be executed ...
    (Linux-Kernel)
  • Re: [Bug #14388] keyboard under X with 2.6.31
    ... TTY layer seems like a good place to look (OK, a horrible place, but a ... layer for me - notably characters "bleeding" across console switches. ... start firing off as if I pressed the arrow up key and held it, ...
    (Linux-Kernel)
  • Re: [Bug #14388] keyboard under X with 2.6.31
    ... TTY layer seems like a good place to look (OK, a horrible place, but a ... layer for me - notably characters "bleeding" across console switches. ... X doesn't touch the pty layer. ... That isn't to say tty isn't the cause but look for input layer ...
    (Linux-Kernel)