Thread (36 messages) 36 messages, 8 authors, 2010-11-29

Re: PROBLEM: memory corrupting bug, bisected to 6dda9d55

From: <hidden>
Date: 2010-10-20 18:33:38
Also in: lkml

Benjamin Herrenschmidt writes:
On Tue, 2010-10-19 at 22:23 -0500, pacman@kosh.dhis.org wrote:
quoted
The diff fragment above applied inside prom_close_stdin, but there are
some
prom_printf calls after prom_close_stdin. Calling prom_printf after
closing
stdout sounds like it could be bad. If I moved it down below all the
prom_printf's, it would be after the "quiesce" call. Would that be
acceptable
(or even interesting as an experiment)? Does a close need a quiesce
after it?
Just try :-) "quiesce" is something that afaik only apple ever
implemented anyways. It uses hooks inside their OF to shut down all
drivers that do bus master (among other HW sanitization tasks).
I booted a version with a prom_close_stdout after the last prom_debug. It
didn't have any effect. That 1000Hz clock was still ticking.

-- 
Alan Curry
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help