Trying again with a few likely-looking cc's from the MAINTAINERS file: Summary:
The PMACZILOG serial driver last worked in 2.6.28. It was broken by commit f751928e0ddf54ea4fe5546f35e99efc5b5d9938 by Alan Cox making bits of the tty layer dynamically allocated. The PMACZILOG driver wasn't properly converted, it works with interrupts disabled (for boot messages), but as soon as interrupts are enabled (PID 1 spawns) the next write to the serial console panics the kernel. Up through 2.6.31 I could fix it by reverting that patch (which isn't a proper fix but it made it work). In 2.6.32 the patch no longer cleanly reverts. I reported the issue here (with a cut and paste of the panic trace): http://lists.ozlabs.org/pipermail/linuxppc-dev/2009-October/076727.html And reported the results of bisecting the issue here: http://lists.ozlabs.org/pipermail/linuxppc-dev/2009-October/077059.html I noted that 2.6.32-pre had broken my workaround here: http://lists.ozlabs.org/pipermail/linuxppc-dev/2009-December/078498.html Background: I have a project that builds the same native Linux development environment for multiple hardware targets. It aims to support all the targets QEMU system emulation can boot Linux under, although I'm still a few short. It creates a cross compiler and uses it to build a root filesystem from uClibc and busybox, adds a native toolchain, and packages it up into a system image (squashfs, ext2, or initramfs depending on the config you selected). Anyone can then boot the resulting system image under qemu and use it to wet source and compile stuff natively. (If the cross compiler is in the $PATH on the host, it will even configure distcc to call out to that cross compiler to speed up the builds to merely "painfully slow", with some pretense of SMP scalability). Prebuilt binaries of all the targets I had working last release are at http://impactlinux.com/fwl/downloads/binaries (with obligatory screenshots at http://impactlinux.com/fwl/screenshots/ even). They use the 2.6.31 kernel. It supports powerpc. If you look at system-image-powerpc.tar.bz2 you'll see that the run-emulator.sh script has been using qemu's "g3beige" target board emulation, which provides all the hardware I need for a development environment (hard drive, network card, at least 256 megs of memory, working clock chip, and of course a serial console). Userspace doesn't care what I use, it's the same processor instruction set and same C library either way, the board emulation's just something to boot it on, only the kernel .config really cares as long as the appropriate resources are there. Unfortunately, g3beige seems to have bit-rotted, and thus the serial console is now panicing. This is a regression, and thus blocking a release of my project using the 2.6.32 kernel. Is this of interest to anyone other than me? Rob -- Latency is more important than throughput. It's that simple. - Linus Torvalds _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
