Re: [PATCH 0/2] suspend-to-ram debugging patches

[Benjamin Herrenschmidt <benh@kernel.crashing.org>]

> 	Some people may hate this, but what it does is to suspend the 
> 	console handling _properly_, so that if there are messages that 
> 	happen while the machine is suspending or resuming, they can 
> 	actually be printed out over a netconsole window, even if the 
> 	network device was part of the devices going down.

Nice to do that generically for all consoles ! I did something fbdev
specific a while ago for ppc macs (since their video chips goes D2 or D3
which is completely inaccessible and we don't do legacy VGA on those)
where the low level driver can instruct the fbdev layer that it's now
offline. Your stuff will probably make things even more reliable for me
too though.

> 	The reason people may hate it is that it actually means that we 
> 	don't print the messages at all when the machine is going down. We 
> 	really can't. Even VGA may be behind a bridge or something, and 
> 	trying to access it is just totally random luck. So the suspend 
> 	and resume actually gets a lot more quiet - but in the process it 
> 	actually gets more reliable.

But that's the only sane way to do it, I agree. One thing I did for mac
to help debugging is based on the knowledge that the Mac laptops / mini
video chip is always on the toplevel AGP bus (can be resumed without any
ordering constraint vs. another device except AGP), I've added a pair of
special platform hooks that the fbdev's can use to get resumed very very
early. I bit hackish but that has proven invaluable. Basically, radeon
registers a callback with the arch, which will then call it on resume
before anything else. (There are also similar callbacks registered so
that the video driver can properly suspend/resume the AGP bridge in the
right order since that isn't possible with the "normal" AGP
suspend/resume hooks, as the AGP bridge isn't physically in a location
that ensure proper dependency with the video chip).

> 	This makes netconsole usable over a suspend/resume, for example, 
> 	instead of just oopsing or doing really bad things because we're 
> 	trying to use the network device at the same time that it's going 
> 	down.
> 
> 	When the resume is done, the normal printk() buffering will have 
> 	kept all the messages, so they are then printed when the devices 
> 	actually work again.
> 
> 	I suspect that we might want to have a "debug mode" that basically 
> 	doesn't stop the console at all, because sometimes the extra 
> 	messages are very useful, even if they sometimes also just help 
> 	break the suspend/resume further. That might make some of the 
> 	people who otherwise hate this happier.
> 
> Actual patches in the next two mails as replies to this one.
> 
> [ And note: I'm not on the linux-pm list, so please cc me with any useful 
>   commentary ]
> 
> 			Linus
> _______________________________________________
> linux-pm mailing list
> linux-pm@lists.osdl.org
> https://lists.osdl.org/mailman/listinfo/linux-pm