On Sun, 9 Aug 2015, Greg Andrzejewski wrote: > > I've had good luck with [__log_buf] remaining intact as long as you drop > into MacsBug right away.
Was it really intact? I didn't see any backtrace. > Only downside is earlyprintk != printk, as I've come to find out, so > those oh so valuable early messages won't be present. No, the "earlyprintk" argument enables the early0 console, which makes printk and __log_buf useful well before tty0 or ttyS0 become available. CONFIG_EARLYPRINTK=y enables the SERIAL_DEBUG and CONSOLE_DEBUG macros in head.S, so that the "ABCFGHIJK" gets printed even before early0 or printk or __log_buf become available. That's why I asked about "ABCFGHIJK" in my previous email; these letters are "valuable" because, if they don't show up, it means the crash comes before "A". So if you were to boot both 4.1.4 and 2.6.29 with no kernel arguments, and with SCC IOP in "compatible" mode, and if you see "ABCFGHIJK" on the framebuffer in both cases, it would mean conclusively that the crash (with SCC IOP "faster" mode) happens before "A". It would mean that there is no problem the the framebuffer debug console and it would mean that "scheduling while atomic" is a red herring (CPU running off into the weeds). My hypothesis here is that, when I fixed the broken SCC initialization in v3.14, with commit 56931d73697c, it became mandatory to have the SCC IOP in bypass/compatible mode when using CONFIG_EARLYPRINTK=y, otherwise you get an IOP interrupt that isn't handled properly. -- -- To UNSUBSCRIBE, email to debian-68k-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/alpine.LNX.2.00.1508111710570.1687@nippy.intranet
