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.