Re: [PATCH] [2.6] PPC64: log firmware errors during boot.

[Paul Mackerras]

linas@xxxxxxxxxxxxxx writes:

> Yes, but rtasd starts up late in the book process.  Most of the 
> "interesting" manipulations with firmware are old history by then,
> and thus, any firmware errors encountered during the boot were never 
> logged.

It all makes a lot more sense with the change to set ppc_md.log_error
to pSeries_log_error.  I do wonder why we need a ppc_md function
pointer for that though, given how pSeries-specific the error log
format is.

> If the parms aren't set up, then the rtas_error_log_max is zero,
> and, as a result, the message is never logged.  By initializing
> rtas_error_log_max to the correct non-zero value, the errors can 
> get logged.

This looks to me like the setting of rtas_error_log_max should be done
much earlier, in pSeries_init_early, say.  Shouldn't we be using the
rtas_error_log_max variable in __fetch_rtas_last_error, too, rather
than the constant RTAS_ERROR_LOG_MAX?

> -- So the decision was wisely made to move this all to user-space. 
> But what shall the communications link between user-space and kernel be? 
> Somebody, somewhere,  I know not who or why, decided that they should 
> go into syslog.  And so here we are.

Netlink is the usual solution to this sort of problem.  I think it
would be reasonable to printk RTAS error events with a severity of
fatal and maybe even of error.  Warnings and events should just get
sent to rtasd.

Oh, and it would be useful to have a comment in the code that calls
__fetch_rtas_last_error that says that we are only calling it if the
RTAS call could not perform its function due to a hardware error.  In
other words the -1 return isn't a generic "didn't work" code but more
specifically a "hardware error" code.

Paul.
-
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/