Re: built-in vs loadable modules and userconf
On Sat, 19 Oct 2019, John D. Baker wrote: > So, it seems the plan of action is to reboot the installed system > (8.1_STABLE) in single-user mode, turn off autoconfig on the RAID > and reboot the test kernel in single-user mode. Then I can observe > the ahcisata behavior with respect to the RAID component disks without > having it try to configure and fail if any disks are not detected. This has worked and I was able to test a -current kernel without interfering with the RAID. Alas, the disks on the siisata card are not detected and I've made an addendum to PR kern/54289. -- |/"\ John D. Baker, KN5UKS NetBSD Darwin/MacOS X |\ / jdbaker[snail]consolidated[flyspeck]net OpenBSDFreeBSD | X No HTML/proprietary data in email. BSD just sits there and works! |/ \ GPGkeyID: D703 4A7E 479F 63F8 D3F4 BD99 9572 8F23 E4AD 1645
Re: built-in vs loadable modules and userconf
On Sat, 19 Oct 2019, John D. Baker wrote: > I suppose also I can turn off autoconfig on the RAID before booting the > test kernel (the config file is renamed so it won't be found by the > 'rc' scripts). > > I have another machine with a local raidframe raid that I can test the > procedure with when current tasks are completed. Booting into userconf (boot -c) reveals no "raid*" anything of any kind, so userconf can't be used to affect anything related to raidframe or the raidN devices. It seems that disabling autoconf on the RAID is all that is needed to keep it from trying to do anything with any RAID component disks that may be found. Also booting single-user will be sufficient to observe the behavior. So, it seems the plan of action is to reboot the installed system (8.1_STABLE) in single-user mode, turn off autoconfig on the RAID and reboot the test kernel in single-user mode. Then I can observe the ahcisata behavior with respect to the RAID component disks without having it try to configure and fail if any disks are not detected. (The config file is renamed so the raidframe script won't find it, but I can manually configure and re-enable autoconf when I'm done testing. I've done this on the auxiliary system.) Just need to wait until I can quiesce the server for the experimental downtime. -- |/"\ John D. Baker, KN5UKS NetBSD Darwin/MacOS X |\ / jdbaker[snail]consolidated[flyspeck]net OpenBSDFreeBSD | X No HTML/proprietary data in email. BSD just sits there and works! |/ \ GPGkeyID: D703 4A7E 479F 63F8 D3F4 BD99 9572 8F23 E4AD 1645
Re: built-in vs loadable modules and userconf
Rhialto wrote: >On Sat 19 Oct 2019 at 08:16:02 -0700, Paul Goyette wrote: >> If the module is built-in, it will never be loaded from the *.kmod file. >> But as I pointed out above, disabling in userconf does NOT disable the >> module, and does not prevent the module's initialization code from >> executing. > >Side-thought: maybe userconf can benefit from a way to disable modules? Not quite what you are asking for but I have local patches to the bootloader to allow autoloading to be disabled from boot.conf.
Re: built-in vs loadable modules and userconf
On Sat, 19 Oct 2019, Rhialto wrote: On Sat 19 Oct 2019 at 08:16:02 -0700, Paul Goyette wrote: If the module is built-in, it will never be loaded from the *.kmod file. But as I pointed out above, disabling in userconf does NOT disable the module, and does not prevent the module's initialization code from executing. Side-thought: maybe userconf can benefit from a way to disable modules? Yeah, that might be nice to have... :) ++--+---+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com | | Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org | ++--+---+
Re: built-in vs loadable modules and userconf
On Sat 19 Oct 2019 at 08:16:02 -0700, Paul Goyette wrote: > If the module is built-in, it will never be loaded from the *.kmod file. > But as I pointed out above, disabling in userconf does NOT disable the > module, and does not prevent the module's initialization code from > executing. Side-thought: maybe userconf can benefit from a way to disable modules? -Olaf. -- Olaf 'Rhialto' Seibert -- rhialto at falu dot nl ___ Anyone who is capable of getting themselves made President should on \X/ no account be allowed to do the job. --Douglas Adams, "THGTTG" signature.asc Description: PGP signature
Re: built-in vs loadable modules and userconf
On Sat, 19 Oct 2019, John D. Baker wrote: On Sat, 19 Oct 2019, Paul Goyette wrote: I want to be sure that a disabled built-in module won't cause a loadable module to be loaded and defeat the disabling of the built-in "raid" device. Disabling the raid device in userconf doesn't disable the raidframe module. If the raidframe module is in your kernel, it can only be disabled after booting, using modunload(8). All raidframe support is built-in on my kernel (includes GENERIC and elides unnecessary/unwanted items). If I disable all the raid* stuff, won't that disable raidframe as well? From the module(9) perspective, no, the module is not disabled as a result of userconf activity. Using userconf to disable the device will prevent all accesses to the device. BUT, the module will still be active, and the module's initialization code will be called. Any code in the kernel that looks for auto-configured raid devices will still run. I would expect it to fail to create any actual raid instances, but the code should still execute. It's important that everything raidframe/raid related be disabled before the kernel boots, or my RAID will be hosed again and I don't need that level of stress. I was lucky to recover it the first time (have encountered a few damaged files since then). Given that you've had "issues" with raid's auto-configure before, I would be reluctant to try this with your current kernel. I would suggest that you build a new kernel with no raid config(1)ured. Also note that disabling a built-in module does not allow you to load a different instance of that module. modload(8) will find the built-in module, I think that means if I disable something via userconf, the on-disk loadable module won't be loaded. If the module is built-in, it will never be loaded from the *.kmod file. But as I pointed out above, disabling in userconf does NOT disable the module, and does not prevent the module's initialization code from executing. I suppose I could whip up a custom kernel without the raidframe/raid support in it, but it's crucial to keep the raidframe module from being loaded if any disk is found with RAID autoconf support. If you build a custom kernel without any raid support, then there will be no code to look for any auto-configured-raid-sets, and therefore no code to instantiate any raid devices, and therefore no reason to ever attempt to autoload the module. If you're really paranoid, you can also configure your custom kernel with MODULAR_DEFAULT_AUTOLOAD disabled (this is on by default). I suppose also I can turn off autoconfig on the RAID before booting the test kernel (the config file is renamed so it won't be found by the 'rc' scripts). I have another machine with a local raidframe raid that I can test the procedure with when current tasks are completed. Hope this helps! ++--+---+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com | | Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org | ++--+---+
Re: built-in vs loadable modules and userconf
On Sat, 19 Oct 2019, Paul Goyette wrote: > > I want to be sure that a disabled built-in module won't cause a loadable > > module to be loaded and defeat the disabling of the built-in "raid" device. > > Disabling the raid device in userconf doesn't disable the raidframe module. > If the raidframe module is in your kernel, it can only be disabled after > booting, using modunload(8). All raidframe support is built-in on my kernel (includes GENERIC and elides unnecessary/unwanted items). If I disable all the raid* stuff, won't that disable raidframe as well? It's important that everything raidframe/raid related be disabled before the kernel boots, or my RAID will be hosed again and I don't need that level of stress. I was lucky to recover it the first time (have encountered a few damaged files since then). > Also note that disabling a built-in module does not allow you to load a > different instance of that module. modload(8) will find the built-in module, I think that means if I disable something via userconf, the on-disk loadable module won't be loaded. > and if you specify the -f option for modload it will re-enable the built-in > module. (Without -f, modload will report an error.) I suppose I could whip up a custom kernel without the raidframe/raid support in it, but it's crucial to keep the raidframe module from being loaded if any disk is found with RAID autoconf support. I suppose also I can turn off autoconfig on the RAID before booting the test kernel (the config file is renamed so it won't be found by the 'rc' scripts). I have another machine with a local raidframe raid that I can test the procedure with when current tasks are completed. -- |/"\ John D. Baker, KN5UKS NetBSD Darwin/MacOS X |\ / jdbaker[snail]consolidated[flyspeck]net OpenBSDFreeBSD | X No HTML/proprietary data in email. BSD just sits there and works! |/ \ GPGkeyID: D703 4A7E 479F 63F8 D3F4 BD99 9572 8F23 E4AD 1645
Re: built-in vs loadable modules and userconf
On Sat, 19 Oct 2019, John D. Baker wrote: I'm curious to see if changes to ahci_sata code in -current fixes the problem in PR kern/54289. On the primary test machine I have it does not. The only other machine to exhibit the problem is my file server using RAIDframe. I nearly lost the RAID booting a netbsd-9 kernel when half of the disks failed to identify due the problem in the PR. If I boot a -current kernel in userconf mode (boot -c) and disable the built-in "raid" device, this should prevent the raid from trying to configure and failing if the problem is still present. I want to be sure that a disabled built-in module won't cause a loadable module to be loaded and defeat the disabling of the built-in "raid" device. Disabling the raid device in userconf doesn't disable the raidframe module. If the raidframe module is in your kernel, it can only be disabled after booting, using modunload(8). Also note that disabling a built-in module does not allow you to load a different instance of that module. modload(8) will find the built-in module, and if you specify the -f option for modload it will re-enable the built-in module. (Without -f, modload will report an error.) ++--+---+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com | | Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org | ++--+---+
built-in vs loadable modules and userconf
I'm curious to see if changes to ahci_sata code in -current fixes the problem in PR kern/54289. On the primary test machine I have it does not. The only other machine to exhibit the problem is my file server using RAIDframe. I nearly lost the RAID booting a netbsd-9 kernel when half of the disks failed to identify due the problem in the PR. If I boot a -current kernel in userconf mode (boot -c) and disable the built-in "raid" device, this should prevent the raid from trying to configure and failing if the problem is still present. I want to be sure that a disabled built-in module won't cause a loadable module to be loaded and defeat the disabling of the built-in "raid" device. -- |/"\ John D. Baker, KN5UKS NetBSD Darwin/MacOS X |\ / jdbaker[snail]consolidated[flyspeck]net OpenBSDFreeBSD | X No HTML/proprietary data in email. BSD just sits there and works! |/ \ GPGkeyID: D703 4A7E 479F 63F8 D3F4 BD99 9572 8F23 E4AD 1645
