NetBSD-Bugs archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: kern/55154 (Running sysctl test on macppc in qemu triggers panic)

The following reply was made to PR kern/55154; it has been noted by GNATS.

From: Paul Goyette <>
To: Martin Husemann <>
Subject: Re: kern/55154 (Running sysctl test on macppc in qemu triggers panic)
Date: Thu, 9 Apr 2020 05:38:18 -0700 (PDT)

 On Thu, 9 Apr 2020, Martin Husemann wrote:
 > On Thu, Apr 09, 2020 at 06:19:12AM +0000, wrote:
 >> The panic no longer occurs.  Thanks.
 > I think Paul's commit is just hiding the symptoms for this simple test,
 > while it is easy to fix the various causes:
 > 1) fix the boot method used by Anita on macppc to properly pass symbols
 >    to the kernel (this is optional, but should be done long term)
 >    [and I don't know why Anita/qemu do it differently than real hardware,
 >     but there could be sub items that I am personally and as releng
 >     interested]
 >   (1a) fix the build to provide working bootable ISOs for all macppc builds
 >   (1b) fix sysinst to deal with ofwboot.xcf and an explicit boot partition
 >        on macppc [there has been preliminary work on this recently]
 I don't know enough about macppc or anita or qemu to consider this.
 > 2) fix the kernel modload support to reject any attempts of module loading
 >    when the symbol table is empty
 This could be done, but would not solve the problem we ran into in
 this PR.
 The PR was triggered because the previous changes _always_ executed
 the sysctl_setup code.  Prior to the change, it was executed only
 when the opencrypto init code was run.  And, for built-in opencrypto,
 the init code only ran when a "client" attached.
 As a result, the sysctl nodes were created, with helper functions
 that referenced unallocated data structures.
 > 3) fix the opencrypto code to properly deal with module load failure (or
 >    non-availability of modules) - maybe this is what Paul did and I
 >    misunderstood
 I didn't fix it, I just avoided the bug by returning to the previous
 ``call sysctl_setup only when a "client" attaches'' mechanism.
 Note that the module load was _not_ triggered by opencrypto, but by
 something else in /etc/rc.d stuff.  The bug/panic would have occurred
 even if we didn't try to load the client module.  In other words, the
 bug exists when there are no clients, whether or not we tried to load
 a client.
 So,the opencrypto init code needs some re-work, but not related to
 client module load failure.  Rather, the rework needs to properly
 initialize the opencrypto code whether or not it has any clients.
 (Note that it seems to work properly when opencrypto itself is a
 non-built-in module.)
 | Paul Goyette       | PGP Key fingerprint:     | E-mail addresses:     |
 | (Retired)          | FA29 0E3B 35AF E8AE 6651 |     |
 | Software Developer | 0786 F758 55DE 53BA 7731 |   |

Home | Main Index | Thread Index | Old Index