Re: PowerMac G5 fans run out of control with kernel 4.17.0-3-powerpc64 but not with 4.16.0-1-powerpc64
> On Aug 27, 2018, at 9:44 PM, Rick Thomas wrote: > > >> On Aug 27, 2018, at 6:54 PM, John Paul Adrian Glaubitz >> wrote: >> >> On 8/25/18 10:54 AM, John Paul Adrian Glaubitz wrote: 2) Firefox segfaults when I start it, either from command line or from the system menu. Is this a known bug? Are there any other graphical (i.e., non-text-mode) browsers I can use instead? I can use elinks for most things, but it’s a lot harder to configure cups printers when you don’t have a graphical browser! >>> >>> This is a known bug which has reported upstream. I don’t have the bug >>> number at hand at the moment. I have been trying to debug it but I was >>> unsuccessful so far. >> >> See: >> >>> https://bugzilla.mozilla.org/show_bug.cgi?id=1405062 >>> https://bugzilla.mozilla.org/show_bug.cgi?id=1466567 > > Thanks, that will make it a bit easier to follow. Let me know if I can do > anything to help get it resolved… In the mean time, has anybody got a suggestion for a graphical browser to use instead? elinks is nice, but it has it’s limitations.
Re: PowerMac G5 fans run out of control with kernel 4.17.0-3-powerpc64 but not with 4.16.0-1-powerpc64
> On Aug 27, 2018, at 6:54 PM, John Paul Adrian Glaubitz > wrote: > > On 8/25/18 10:54 AM, John Paul Adrian Glaubitz wrote: >>> 2) Firefox segfaults when I start it, either from command line or from the >>> system menu. Is this a known bug? Are there any other graphical (i.e., >>> non-text-mode) browsers I can use instead? I can use elinks for most >>> things, but it’s a lot harder to configure cups printers when you don’t >>> have a graphical browser! >> >> This is a known bug which has reported upstream. I don’t have the bug number >> at hand at the moment. I have been trying to debug it but I was unsuccessful >> so far. > > See: > >> https://bugzilla.mozilla.org/show_bug.cgi?id=1405062 >> https://bugzilla.mozilla.org/show_bug.cgi?id=1466567 Thanks, that will make it a bit easier to follow. Let me know if I can do anything to help get it resolved… Rick
Re: Firefox segfaults when I start it
On 08/27/2018 11:09 PM, John Paul Adrian Glaubitz wrote: On 8/28/18 5:08 AM, John Paul Adrian Glaubitz wrote: Guess not. Explanation here: https://lists.debian.org/debian-sparc/2017/12/msg00060.html Oh, FWIW, you need to install the version from experimental. # apt install firefox -t=experimental Adrian Get to it later ... kernel building with that patch from Linus and this time I will use "make INSTALL_MOD_STRIP=1 modules_install" to trim the bulk. dc
Re: Firefox segfaults when I start it
On 8/28/18 5:08 AM, John Paul Adrian Glaubitz wrote: >> Guess not. > > Explanation here: https://lists.debian.org/debian-sparc/2017/12/msg00060.html Oh, FWIW, you need to install the version from experimental. # apt install firefox -t=experimental Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: Firefox segfaults when I start it
On 8/28/18 4:35 AM, Dennis Clarke wrote: > root@nix:~# apt-get install firefox > Reading package lists... Done > Building dependency tree > Reading state information... Done > Some packages could not be installed. This may mean that you have > requested an impossible situation or if you are using the unstable > distribution that some required packages have not yet been created > or been moved out of Incoming. > The following information may help to resolve the situation: > > The following packages have unmet dependencies: > firefox : Depends: libevent-2.0-5 (>= 2.0.10-stable) but it is not > installable > Depends: libhunspell-1.4-0 but it is not installable > Depends: libvpx4 (>= 1.6.0) but it is not installable > E: Unable to correct problems, you have held broken packages. > root@nix:~# > > Guess not. Explanation here: https://lists.debian.org/debian-sparc/2017/12/msg00060.html Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: Firefox segfaults when I start it
On 08/27/2018 09:54 PM, John Paul Adrian Glaubitz wrote: On 8/25/18 10:54 AM, John Paul Adrian Glaubitz wrote: 2) Firefox segfaults when I start it, either from command line or from the system menu. Is this a known bug? Are there any other graphical (i.e., non-text-mode) browsers I can use instead? I can use elinks for most things, but it’s a lot harder to configure cups printers when you don’t have a graphical browser! This is a known bug which has reported upstream. I don’t have the bug number at hand at the moment. I have been trying to debug it but I was unsuccessful so far. See: https://bugzilla.mozilla.org/show_bug.cgi?id=1405062 https://bugzilla.mozilla.org/show_bug.cgi?id=1466567 Adrian bugid : 1405062 An interesting thing: the only architecture where we see this has pagesize of 64k (may be just a coincidence though). I have pagesize 4096 bytes here so I could see what happens. nix$ uname -a Linux nix 4.18.5-genunix #1 SMP Sat Aug 25 16:18:55 GMT 2018 ppc64 GNU/Linux nix$ getconf PAGESIZE 4096 nix$ su - Password: root@nix:~# apt-get install firefox Reading package lists... Done Building dependency tree Reading state information... Done Some packages could not be installed. This may mean that you have requested an impossible situation or if you are using the unstable distribution that some required packages have not yet been created or been moved out of Incoming. The following information may help to resolve the situation: The following packages have unmet dependencies: firefox : Depends: libevent-2.0-5 (>= 2.0.10-stable) but it is not installable Depends: libhunspell-1.4-0 but it is not installable Depends: libvpx4 (>= 1.6.0) but it is not installable E: Unable to correct problems, you have held broken packages. root@nix:~# Guess not. Subject line "G5 fans run out of control" didn't seem reasonable for a browser problem. Anyways .. I'll poke at that patch from Linus .. for fun. Dennis
Re: PowerMac G5 fans run out of control with kernel 4.17.0-3-powerpc64 but not with 4.16.0-1-powerpc64
On 8/25/18 10:54 AM, John Paul Adrian Glaubitz wrote: >> 2) Firefox segfaults when I start it, either from command line or from the >> system menu. Is this a known bug? Are there any other graphical (i.e., >> non-text-mode) browsers I can use instead? I can use elinks for most >> things, but it’s a lot harder to configure cups printers when you don’t have >> a graphical browser! > > This is a known bug which has reported upstream. I don’t have the bug number > at hand at the moment. I have been trying to debug it but I was unsuccessful > so far. See: > https://bugzilla.mozilla.org/show_bug.cgi?id=1405062 > https://bugzilla.mozilla.org/show_bug.cgi?id=1466567 Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: PowerMac G5 fans run out of control with kernel4.17.0-3-powerpc64but not with 4.16.0-1-powerpc64
I can try just about anything on my G5. It exists strictly for testing, right now. If you can point me to a .deb with the patch that I can install, I’ll be happy to test it. Rick > On Aug 27, 2018, at 6:41 PM, John Paul Adrian Glaubitz > wrote: > > On 8/28/18 3:36 AM, John Paul Adrian Glaubitz wrote: >> You can try to figure out what the actual change was. So, for example, if you >> find out what in the windfarm module configuration has changed, I can open a >> merge request for the linux kernel package on salsa.debian.org which is >> actually >> something everyone can do. > > It seems that recently something was changed in the probing code [1]. > Can someone try a kernel with the patch included? > > Adrian > >> [1] >> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/drivers/macintosh?id=3e7bed52719de4b5b5fb900869e293eae0bc3f3e > > -- > .''`. John Paul Adrian Glaubitz > : :' : Debian Developer - glaub...@debian.org > `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de > `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: PowerMac G5 fans run out of control with kernel4.17.0-3-powerpc64but not with 4.16.0-1-powerpc64
On 8/28/18 3:36 AM, John Paul Adrian Glaubitz wrote: > You can try to figure out what the actual change was. So, for example, if you > find out what in the windfarm module configuration has changed, I can open a > merge request for the linux kernel package on salsa.debian.org which is > actually > something everyone can do. It seems that recently something was changed in the probing code [1]. Can someone try a kernel with the patch included? Adrian > [1] > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/drivers/macintosh?id=3e7bed52719de4b5b5fb900869e293eae0bc3f3e -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: PowerMac G5 fans run out of control with kernel4.17.0-3-powerpc64but not with 4.16.0-1-powerpc64
On 8/28/18 3:28 AM, Rick Thomas wrote: > Thanks for the explanation. Can I assume that you will be following up on > this? If not, I’ll understand — bandwidth is in short supply for all of us. > Should I file a bug report — if so, to what package? Sadly, I don’t have the > expertise to follow up on it myself, so I have to rely on friendly experts > such as yourself. You can try to figure out what the actual change was. So, for example, if you find out what in the windfarm module configuration has changed, I can open a merge request for the linux kernel package on salsa.debian.org which is actually something everyone can do. You might start poking around here [1]. Adrian > [1] > https://salsa.debian.org/kernel-team/linux/blob/master/debian/config/kernelarch-powerpc/config-arch-64-be#L63 -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: PowerMac G5 fans run out of control with kernel4.17.0-3-powerpc64but not with 4.16.0-1-powerpc64
> On Aug 27, 2018, at 1:34 AM, John Paul Adrian Glaubitz > wrote: > >> >> If it is a bug, it’s a minor one, and it’s easily worked around by the >> addition to /etc/modules. But I’m curious to know what changed? If it is a >> name change, as Adrian suggests, I’m curious to know what changed and why it >> was changed… > > Changes like these happen in the kernel all the time. Usually for refactoring > of code or updates due to internal API changes in the kernel. > > Adrian Hi Adrian, Thanks for the explanation. Can I assume that you will be following up on this? If not, I’ll understand — bandwidth is in short supply for all of us. Should I file a bug report — if so, to what package? Sadly, I don’t have the expertise to follow up on it myself, so I have to rely on friendly experts such as yourself. Thanks again, for all the good work you do! Rick
Re: Processing of yaboot-installer_1.1.40_source.changes
On 8/27/18 8:49 PM, Holger Wansing wrote: > I was aware of that package being for powerpc, which is not a release-arch. > The upload is just for completeness - as for many other d-i packages, to > update > the alioth URLs in debian/control to Salsa: Odd, to my surprise it did actually work. According to what Aurelien had said in the past, such uploads aren't possible which is why things like sparc-utils are living in unreleased. Interesting, maybe I should update yaboot-installer for ppc64 support. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Removing the LDC compiler from ppc64el / IEEE quad ABI support?
[ Please keep me in CC, I am not subscribed to this list ] Hi! I was investigating issue #907239 (LDC ftbfs on ppc64el), filing an upstream issue for it[1]. Upstream now suggests to drop support for the powerpc/ppc64el architecture entirely, due to the maintenance cost and the fact the issue won't likely be solved soon. However, they might support ppc64el again it in case the architecture switched to IEEE quad ABI. Is that likely to happen anytime soon in Debian by default? Cheers, Matthias [1]: https://github.com/ldc-developers/ldc/issues/2824 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=907239 -- I welcome VSRE emails. See http://vsre.info/
Re: Processing of yaboot-installer_1.1.40_source.changes
Hi,
John Paul Adrian Glaubitz wrote:
> On 8/27/18 7:55 PM, Debian FTP Masters wrote:
> > yaboot-installer_1.1.40_source.changes uploaded successfully to localhost
> > along with the files:
> > yaboot-installer_1.1.40.dsc
> > yaboot-installer_1.1.40.tar.xz
> > yaboot-installer_1.1.40_powerpc.buildinfo
>
> This is not going to work. yaboot-installer does not build any binaries
> on any release architecture which is why DAK will refuse the package.
Hmm, ok.
I was aware of that package being for powerpc, which is not a release-arch.
The upload is just for completeness - as for many other d-i packages, to update
the alioth URLs in debian/control to Salsa:
yaboot-installer (1.1.40) unstable; urgency=medium
* Team upload
[ Cyril Brulebois ]
* Update Vcs-{Browser,Git} to point to salsa (alioth's replacement).
-- Holger Wansing Mon, 27 Aug 2018 19:37:28 +0200
Which looked to me as a change of no harm.
But, no problem then, if that will be refused.
Thanks for noticing
Holger
--
Created with Sylpheed 3.5.1 under
D E B I A N L I N U X 9 " S T R E T C H " .
Registered Linux User #311290 - https://linuxcounter.net/
Re: Processing of yaboot-installer_1.1.40_source.changes
On 8/27/18 7:55 PM, Debian FTP Masters wrote: > yaboot-installer_1.1.40_source.changes uploaded successfully to localhost > along with the files: > yaboot-installer_1.1.40.dsc > yaboot-installer_1.1.40.tar.xz > yaboot-installer_1.1.40_powerpc.buildinfo This is not going to work. yaboot-installer does not build any binaries on any release architecture which is why DAK will refuse the package. We're in the process of completely replacing Yaboot with GRUB for powerpc and ppc64. It's already working for IBM-based machines, PPC Macs need some more work though. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: PowerMac G5 fans run out of control with kernel 4.17.0-3-powerpc64 but not with 4.16.0-1-powerpc64
On 08/27/2018 05:18 AM, Bas Vermeulen wrote: Hi Dennis, Your modules aren't stripped, which is what causes the huge initrd. Try: make INSTALL_MOD_STRIP=1 modules_install instead of make modules_install to fix this. A switch to just the required "dep" modules resulted in a small enough initrd to get moving again. However I will try INSTALL_MOD_STRIP=1 also to see what the result is. I should let you know that cleaning out the modules from many many build revisions also lightens the disk load under /lib/modules. Dennis
Re: Problem with gem network card
On 27/08/18 10:39, Mathieu Malaterre wrote: > Christian, > > On Mon, Oct 17, 2016 at 9:32 AM Mathieu Malaterre wrote: >> >> Hi, >> >> On Fri, Oct 14, 2016 at 4:45 PM, Thadeu Lima de Souza Cascardo >> wrote: >>> There is certainly a way to automate this, but my question on whether >>> that sequence would fix the problem was intended to more easily fix a >>> real bug in the driver. >>> >>> I can try to help fix the driver on my free time as a volunteer. >>> Christian, would you be willing to test patches to the driver? That >>> would require some back and forth between us and some patience of yours, >>> as I would be doing it on my spare time, considering I have family and >>> other projects I would like to attend to as well. >>> >>> I don't have a PPC Macbook of my own, but I used to fix Linux drivers on >>> PPC64 for a living not too long ago. >> >> That's a good news ! Feel free to use the bug report #841044 to send >> your patch (and/or updates). > > Any update on the patch ? > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=841044#30 FWIW QEMU now has sungem emulation which may help when trying to track down overflow errors such as this. ATB, Mark.
Re: Problem with gem network card
Christian, On Mon, Oct 17, 2016 at 9:32 AM Mathieu Malaterre wrote: > > Hi, > > On Fri, Oct 14, 2016 at 4:45 PM, Thadeu Lima de Souza Cascardo > wrote: > > There is certainly a way to automate this, but my question on whether > > that sequence would fix the problem was intended to more easily fix a > > real bug in the driver. > > > > I can try to help fix the driver on my free time as a volunteer. > > Christian, would you be willing to test patches to the driver? That > > would require some back and forth between us and some patience of yours, > > as I would be doing it on my spare time, considering I have family and > > other projects I would like to attend to as well. > > > > I don't have a PPC Macbook of my own, but I used to fix Linux drivers on > > PPC64 for a living not too long ago. > > That's a good news ! Feel free to use the bug report #841044 to send > your patch (and/or updates). Any update on the patch ? https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=841044#30
Re: PowerMac G5 fans run out of control with kernel4.17.0-3-powerpc64 but not with 4.16.0-1-powerpc64
On Sun, Aug 26, 2018 at 2:15 PM Linux User #330250 wrote: > > Am 26.08.18 um 14:07 schrieb Frank Scheiner: > > On 08/26/2018 01:35 PM, Linux User #330250 wrote: > >> Am 26.08.18 um 12:48 schrieb John Paul Adrian Glaubitz: > >>> One of the most pressing problems on Debian powerpc/ppc64 is > >>> the deprecation of Yaboot. Yaboot is completely unmaintained these > >>> days and should > >>> have been replaced with GRUB long time ago. If you install Debian > >>> powerpc/ppc64 on > >>> an IBM-based system (CHRP-IBM or whatever it's called), the > >>> installer will actually > >>> install GRUB. On Mac systems (NewWorld), it will install Yaboot with > >>> the various > >>> problems that people are experiencing. > >>> > >>> Getting GRUB work on PPC Macs requires an extra utility which is > >>> currently part > >>> of the Yaboot package so this needs some extra work. But we have > >>> worked on this > >>> in the past and we hope to get this finished soon. Then we have one > >>> annoyance > >>> less to worry about. > >> > >> > >> What is this tool that is missing? > > > > A working device-to-ofpath translator. > > > > AFAIR during testing in late 2017 the only tool that worked reliably > > on most NewWorld PowerMac and Xserve machines was `ofpath` which is > > part of the yaboot package as Adrian already mentioned. So not > > maintained (because part of yaboot) and missing when yaboot is dropped. > > > > The other available tool `ofpathname` is meant for IBM machines and > > gives wrong results on Apple machines (and also on IBM machines). The > > tool `grub-ofpathname` from GRUB didn't work as expected during my > > testing. > > > > See e.g. [1] for some background. > > > > [1]: https://lists.debian.org/debian-powerpc/2017/11/msg00086.html > > > > Thanks, but why use ofpath when GRUB2 core.elf can figure that out all > by itself without the use of open firmware stuff? Just use the UUID of > the partition where the second main GRUB2 is installed, and use the > first GRUB2 only as the first stage core.elf. The actual bug was reported here: https://bugs.debian.org/882076 The other grub-related powerpc issues can be found from: https://udd.debian.org/cgi-bin/bts-usertags.cgi?tag=powerpc=debian-powerpc%40lists.debian.org > Example: your /boot UUID is 12345678-abcd-ef01-1234-abcdef012345, > grub.cfg on the HFS partition together with core.elf from GRUB2, blessed > (:tbxi) using hattrib: > > search --no-floppy --fs-uuid --set=root > 12345678-abcd-ef01-1234-abcdef012345 > > set prefix=($root)/boot/grub > > configfile /boot/grub/grub.cfg > > This will load grub.cfg from the real /boot partition and continue from > there, no need to get the ofpath. > > At least that was how I did it on a Power Mac G4. > > > Linux User #330250 >
Re: PowerMac G5 fans run out of control with kernel 4.17.0-3-powerpc64 but not with 4.16.0-1-powerpc64
Hi Dennis, Your modules aren't stripped, which is what causes the huge initrd. Try: make INSTALL_MOD_STRIP=1 modules_install instead of make modules_install to fix this. Bas Vermeulen
Re: PowerMac G5 fans run out of control with kernel4.17.0-3-powerpc64but not with 4.16.0-1-powerpc64
> On Aug 27, 2018, at 10:11 AM, Rick Thomas wrote: > > >> On Aug 26, 2018, at 1:25 AM, Mark G.B. wrote: >> >> Hi Rick and everyone, >> >> It’s a bug (IMHO). Feel free to correct me if I’m wrong, though. >> >> Attached here are two images of the Debian-powerpc64 specific kernel-config >> extracted from the .deb package of the Linux-image package off of >> packages.debian.org, .de server. >> >> Debian powerpc64 kernel 4.17 (port) has no mention of windfarm_core being >> compiled in EITHER AS internal-functionally or as a module (nocore.png). Not >> trying to be whistleblower on the porters! Actually, IMHO, it’s just a minor >> bug to me and can easily be fixed with a modprobe . The “tornado” was >> probably from all the other windfarm modules being included/started W/O the >> core. >> >> For reference, i2c_powermac is compiled in with respect to this kernel >> revision for powerpc64, as shown in i2cyes.png. >> >> Cheers, >> Mark > > Hi All, > > I observe that the windfarm configuration in /boot/config-4.17.0-3-powerpc64 > and /boot/config-4.16.0-1-powerpc64 are identical: Not surprising. The configuration is defined by the Debian packaging of the Linux kernel. And since we didn’t change anything, it’s not unusual for the configs to match. > Adrian hinted that it has something to do with a name change, but I’m unable > to figure out what that change could be??? It could be that a module in the kernel got split into two and hence the Debian kernel configuration needs to be updated. Again, if upstream makes some changes, it’s our duty in Debian to adapt these changes by updating our configuration. It can also be a bug, of course. > If it is a bug, it’s a minor one, and it’s easily worked around by the > addition to /etc/modules. But I’m curious to know what changed? If it is a > name change, as Adrian suggests, I’m curious to know what changed and why it > was changed… Changes like these happen in the kernel all the time. Usually for refactoring of code or updates due to internal API changes in the kernel. Adrian
Re: PowerMac G5 fans run out of control with kernel4.17.0-3-powerpc64but not with 4.16.0-1-powerpc64
On Aug 26, 2018, at 1:25 AM, Mark G.B. wrote: > Hi Rick and everyone, > > It’s a bug (IMHO). Feel free to correct me if I’m wrong, though. > > Attached here are two images of the Debian-powerpc64 specific kernel-config > extracted from the .deb package of the Linux-image package off of > packages.debian.org, .de server. > > Debian powerpc64 kernel 4.17 (port) has no mention of windfarm_core being > compiled in EITHER AS internal-functionally or as a module (nocore.png). Not > trying to be whistleblower on the porters! Actually, IMHO, it’s just a minor > bug to me and can easily be fixed with a modprobe . The “tornado” was > probably from all the other windfarm modules being included/started W/O the > core. > > For reference, i2c_powermac is compiled in with respect to this kernel > revision for powerpc64, as shown in i2cyes.png. > > Cheers, > Mark Hi All, I observe that the windfarm configuration in /boot/config-4.17.0-3-powerpc64 and /boot/config-4.16.0-1-powerpc64 are identical: > rbthomas@kmac:~$ grep -i windfarm /boot/config-4.17.0-3-powerpc64 > CONFIG_WINDFARM=m > CONFIG_WINDFARM_PM81=m > CONFIG_WINDFARM_PM72=m > CONFIG_WINDFARM_RM31=m > CONFIG_WINDFARM_PM91=m > CONFIG_WINDFARM_PM112=m > CONFIG_WINDFARM_PM121=m > > rbthomas@kmac:~$ grep -i windfarm /boot/config-4.16.0-1-powerpc64 > CONFIG_WINDFARM=m > CONFIG_WINDFARM_PM81=m > CONFIG_WINDFARM_PM72=m > CONFIG_WINDFARM_RM31=m > CONFIG_WINDFARM_PM91=m > CONFIG_WINDFARM_PM112=m > CONFIG_WINDFARM_PM121=m I also observe that the generated module names are identical: > rbthomas@kmac:~$ find /lib/modules/4.16.0-1-powerpc64/ -name '*windfarm*' > -print > /lib/modules/4.16.0-1-powerpc64/kernel/drivers/macintosh/windfarm_ad7417_sensor.ko > /lib/modules/4.16.0-1-powerpc64/kernel/drivers/macintosh/windfarm_pm91.ko > /lib/modules/4.16.0-1-powerpc64/kernel/drivers/macintosh/windfarm_lm87_sensor.ko > /lib/modules/4.16.0-1-powerpc64/kernel/drivers/macintosh/windfarm_rm31.ko > /lib/modules/4.16.0-1-powerpc64/kernel/drivers/macintosh/windfarm_core.ko > /lib/modules/4.16.0-1-powerpc64/kernel/drivers/macintosh/windfarm_pm121.ko > /lib/modules/4.16.0-1-powerpc64/kernel/drivers/macintosh/windfarm_smu_sat.ko > /lib/modules/4.16.0-1-powerpc64/kernel/drivers/macintosh/windfarm_smu_sensors.ko > /lib/modules/4.16.0-1-powerpc64/kernel/drivers/macintosh/windfarm_fcu_controls.ko > /lib/modules/4.16.0-1-powerpc64/kernel/drivers/macintosh/windfarm_pm112.ko > /lib/modules/4.16.0-1-powerpc64/kernel/drivers/macintosh/windfarm_smu_controls.ko > /lib/modules/4.16.0-1-powerpc64/kernel/drivers/macintosh/windfarm_max6690_sensor.ko > /lib/modules/4.16.0-1-powerpc64/kernel/drivers/macintosh/windfarm_cpufreq_clamp.ko > /lib/modules/4.16.0-1-powerpc64/kernel/drivers/macintosh/windfarm_lm75_sensor.ko > /lib/modules/4.16.0-1-powerpc64/kernel/drivers/macintosh/windfarm_pid.ko > /lib/modules/4.16.0-1-powerpc64/kernel/drivers/macintosh/windfarm_pm81.ko > /lib/modules/4.16.0-1-powerpc64/kernel/drivers/macintosh/windfarm_pm72.ko > > rbthomas@kmac:~$ find /lib/modules/4.17.0-3-powerpc64/ -name '*windfarm*' > -print > /lib/modules/4.17.0-3-powerpc64/kernel/drivers/macintosh/windfarm_ad7417_sensor.ko > /lib/modules/4.17.0-3-powerpc64/kernel/drivers/macintosh/windfarm_pm91.ko > /lib/modules/4.17.0-3-powerpc64/kernel/drivers/macintosh/windfarm_lm87_sensor.ko > /lib/modules/4.17.0-3-powerpc64/kernel/drivers/macintosh/windfarm_rm31.ko > /lib/modules/4.17.0-3-powerpc64/kernel/drivers/macintosh/windfarm_core.ko > /lib/modules/4.17.0-3-powerpc64/kernel/drivers/macintosh/windfarm_pm121.ko > /lib/modules/4.17.0-3-powerpc64/kernel/drivers/macintosh/windfarm_smu_sat.ko > /lib/modules/4.17.0-3-powerpc64/kernel/drivers/macintosh/windfarm_smu_sensors.ko > /lib/modules/4.17.0-3-powerpc64/kernel/drivers/macintosh/windfarm_fcu_controls.ko > /lib/modules/4.17.0-3-powerpc64/kernel/drivers/macintosh/windfarm_pm112.ko > /lib/modules/4.17.0-3-powerpc64/kernel/drivers/macintosh/windfarm_smu_controls.ko > /lib/modules/4.17.0-3-powerpc64/kernel/drivers/macintosh/windfarm_max6690_sensor.ko > /lib/modules/4.17.0-3-powerpc64/kernel/drivers/macintosh/windfarm_cpufreq_clamp.ko > /lib/modules/4.17.0-3-powerpc64/kernel/drivers/macintosh/windfarm_lm75_sensor.ko > /lib/modules/4.17.0-3-powerpc64/kernel/drivers/macintosh/windfarm_pid.ko > /lib/modules/4.17.0-3-powerpc64/kernel/drivers/macintosh/windfarm_pm81.ko > /lib/modules/4.17.0-3-powerpc64/kernel/drivers/macintosh/windfarm_pm72.ko However, without adding “windfarm_core” to /etc/modules, the 4.16 kernel loads those modules automatically, while the 4.17 kernel does not. So… Why? Adrian hinted that it has something to do with a name change, but I’m unable to figure out what that change could be??? If it is a bug, it’s a minor one, and it’s easily worked around by the addition to /etc/modules. But I’m curious to know what changed? If it is a name change, as Adrian suggests, I’m curious to know what changed and why it was changed…
