On Tue, Mar 31, 2009 at 5:26 PM, Gary Thomas <g...@mlbassoc.com> wrote: > > The fact that you get the ttyS1 line printed is interesting. At > this point, the kernel is switching from raw console I/O (only > suitable for bring-up messages) to the general serial driver > (interrupt driven, etc). I'm curious about what the ttyS1 driver > is causing to break... > > A couple of things you could try: > * Disable ttyS1 (take it out of your device tree)
I tried taking ttyS1 out - the results are no different (other than the fact that "console handover" is now the last line that prints). My debug printk()s at the end of 8250_init() show up, which would seem to imply that ttyS0 was initialized correctly, so I'm not sure what else could be stomping on it. > * Look at the console log when this happens. Look in your system > map for the symbol '__log_buf', e.g. > c031ca54 b __log_buf > This will get stored at physical location '0x31ca54' and will > often contain data that didn't get a chance to print, for example > if you have stuck interrupts that prevent the console from working. > I'd just run it to this point and then examine the memory - either > using a BDI if one is attached, or press RESET (I hope you have one!) > and then look using your boot loader (uBoot, RedBoot, ...) > I think I can get my hands on a BDI tomorrow, so I'll give this a try then. Thanks for the reply -- Matthew L. Creech _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
