Dear Gary Jennejohn,
In message 20080915105924.3249d5db@peedub.jennejohn.org you wrote:
The first call to scc_init() executes all the code. Only subsequent calls are short-circuited.
I am aware of that. But after the first call, eth_halt() might have been run, deactivating the interface; then for example interfaces might have been switched to another port, and finally switched back to the old port. In this case, a full initialization sequence will be necessary.
OK, just think about it a little.
Indeed, please do.
When nc is active as a console it is often invoked for every byte.
Ah! That's the origin of your concern. But I think you're trying to attack it at the wrong place. Your modification will most probably break some (or many) boards.
The network stack code calls eth_init() prior to sending the byte and eth_halt() after sending the byte.
scc_init() happily tries to reallocate dpram at every call when CFG_ALLOC_DPRAM is defined, as it was in my case. Eventually dpram is exhausted which evidently results in a machine check.
-> grep -l CONFIG_NETCONSOLE include/configs/* | xargs egrep CFG_ALLOC_DPRAM | wc -l 0 ->
You are right. None of the boards that use netconsole so far (and that have been tested with that feature, obviously) is using CFG_ALLOC_DPRAM. So a fix is necessary not to re-allocate DPRAM here.
It would be great if you could submit a patch that fixes this problem.
I doubt that nc is used very often, otherwise this problem would have reared its ugly head a lot sooner. The general use case is also to merely invoke tftp to load the kernel and maybe fdt. This succeeds because it takes numerous (in this case about 14) calls to the init routine before the machine check happens.
In fact I think the problem never showed before because nodody used CFG_ALLOC_DPRAM with netconsole. I agree that this should be fixed.
Best regards,
Wolfgang Denk