Debian SID kernel doesn't boot on PowerBook 3400c

[Stan Johnson]

On 8/6/21 10:08 PM, Finn Thain wrote:
> 
> On Fri, 6 Aug 2021, Stan Johnson wrote:
> 
>> $ egrep '(CONFIG_PPC_KUAP|CONFIG_VMAP_STACK)' .config
>> CONFIG_PPC_KUAP=y
>> CONFIG_PPC_KUAP_DEBUG=y
>> CONFIG_VMAP_STACK=y
>> $ strings vmlinux | fgrep "Linux version"
>> Linux version 5.13.0-pmac-00004-g63e3756d1bd ...
>> $ cp vmlinux ../vmlinux-5.13.0-pmac-00004-g63e3756d1bd-1
>>
>> 1) PB 3400c
>> vmlinux-5.13.0-pmac-00004-g63e3756d1bd-1
>> Boots, no errors logging in at (text) fb console. Logging in via ssh and
>> running "ls -Rail /usr/include" generated errors (and a hung ssh
>> session). Once errors started, they repeated for almost every command.
>> See pb3400c-63e3756d1bdf-1.txt.
>>
>> 2) Wallstreet
>> vmlinux-5.13.0-pmac-00004-g63e3756d1bd-1
>> X login failed, there were errors ("Oops: Kernel access of bad area",
>> "Oops: Exception in kernel mode"). Logging in via SSH, there were no
>> additional errors after running "ls -Rail /usr/include" -- the errors
>> did not escalate as they did on the PB 3400.
>> See Wallstreet-63e3756d1bdf-1.txt.
>>
> ...
>> $ egrep '(CONFIG_PPC_KUAP|CONFIG_VMAP_STACK)' .config
>> CONFIG_PPC_KUAP=y
>> CONFIG_PPC_KUAP_DEBUG=y
>> # CONFIG_VMAP_STACK is not set
>> $ strings vmlinux | fgrep "Linux version"
>> Linux version 5.13.0-pmac-00004-g63e3756d1bd ...
>> $ cp vmlinux ../vmlinux-5.13.0-pmac-00004-g63e3756d1bd-2
>>
>> 3) PB 3400c
>> vmlinux-5.13.0-pmac-00004-g63e3756d1bd-2
>> Filesystem was corrupt from the previous test (probably from all the
>> errors during shutdown). After fixing the filesystem:
>> Boots, no errors logging in at (text) fb console. Logging in via ssh and
>> running "ls -Rail /usr/include" generated a few errors. There didn't
>> seem to be as many errors as in the previous test, there were a few
>> errors during shutdown but the shutdown was otherwise normal.
>> See pb3400c-63e3756d1bdf-2.txt.
>>
>> 4) Wallstreet
>> vmlinux-5.13.0-pmac-00004-g63e3756d1bd-2
>> X login worked, and there were no errors. There were no errors during
>> ssh access.
>> See Wallstreet-63e3756d1bdf-2.txt.
>>
> 
> Thanks for collecting these results, Stan. Do you think that the 
> successful result from test 4) could have been just chance?

No. I repeated Test 4 above two more times on the Wallstreet. After
stomping on it as hard as I could, I didn't see any errors. I ran the
following tests simultaneously, with no errors:

a) Ping flood the Wallstreet
862132 packets transmitted, 862117 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 0.316/0.418/12.163/0.143 ms

b) "ls -Rail /usr" in an ssh window.

c) "find /usr/include -type f -exec sha1sum {} \;" in a second ssh window.

d) With a, b and c running, I logged in at the X console (slow but it
worked). Load average was 7.0 as reported by uptime.

So the success seems to be repeatable (or at least the errors are so
unlikely to happen that I'm not seeing anything).

> 
> It appears that the bug affecting the Powerbook 3400 is unaffected by 
> CONFIG_VMAP_STACK.
> 
> Whereas the bug affecting the Powerbook G3 disappears when 
> CONFIG_VMAP_STACK is disabled (assuming the result from 4 is reliable).
> 
> Either way, these results reiterate that "Oops: Kernel access of bad area, 
> sig: 11" was not entirely resolved by "powerpc/32s: Fix napping restore in 
> data storage interrupt (DSI)".
> 

That sounds right. Thanks for investigating this.