[Bug 206669] Little-endian kernel crashing on POWER8 on heavy big-endian PowerKVM load
https://bugzilla.kernel.org/show_bug.cgi?id=206669 --- Comment #7 from John Paul Adrian Glaubitz (glaub...@physik.fu-berlin.de) --- I have set /sys/kernel/debug/tracing/tracing_on to "0" and /sys/kernel/debug/tracing/free_buffer to "1" and it seems I can no longer reproduce the issue. I will have to do more testing to see if that's just an artifact or really related. -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 206203] kmemleak reports various leaks in drivers/of/unittest.c
https://bugzilla.kernel.org/show_bug.cgi?id=206203 --- Comment #3 from Erhard F. (erhar...@mailbox.org) --- Created attachment 287671 --> https://bugzilla.kernel.org/attachment.cgi?id=287671&action=edit kmemleak output (kernel 5.6-rc3, PowerMac G5 11,2) Same on a PowerMac G5 11,2 (kernel 5.6-rc3). -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 206203] kmemleak reports various leaks in drivers/of/unittest.c
https://bugzilla.kernel.org/show_bug.cgi?id=206203 --- Comment #4 from Erhard F. (erhar...@mailbox.org) --- Created attachment 287673 --> https://bugzilla.kernel.org/attachment.cgi?id=287673&action=edit dmesg (kernel 5.6-rc3, PowerMac G5 11,2) -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 206203] kmemleak reports various leaks in drivers/of/unittest.c
https://bugzilla.kernel.org/show_bug.cgi?id=206203 --- Comment #5 from Erhard F. (erhar...@mailbox.org) --- Created attachment 287675 --> https://bugzilla.kernel.org/attachment.cgi?id=287675&action=edit kernel .config (kernel 5.6-rc3, PowerMac G5 11,2) -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 206203] kmemleak reports various leaks in drivers/of/unittest.c
https://bugzilla.kernel.org/show_bug.cgi?id=206203 --- Comment #6 from m...@ellerman.id.au --- bugzilla-dae...@bugzilla.kernel.org writes: > https://bugzilla.kernel.org/show_bug.cgi?id=206203 > > --- Comment #3 from Erhard F. (erhar...@mailbox.org) --- > Created attachment 287671 > --> https://bugzilla.kernel.org/attachment.cgi?id=287671&action=edit > kmemleak output (kernel 5.6-rc3, PowerMac G5 11,2) > > Same on a PowerMac G5 11,2 (kernel 5.6-rc3). Can you attach the /sys/kernel/debug/kmemleak output please. cheers -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 206203] kmemleak reports various leaks in drivers/of/unittest.c
https://bugzilla.kernel.org/show_bug.cgi?id=206203 --- Comment #7 from Erhard F. (erhar...@mailbox.org) --- (In reply to mpe from comment #6) > Can you attach the /sys/kernel/debug/kmemleak output please. > > cheers I already did: "kmemleak output (kernel 5.6-rc3, PowerMac G5 11,2) (91.35 KB, text/plain)" -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 206695] New: kmemleak reports leaks in drivers/macintosh/windfarm
https://bugzilla.kernel.org/show_bug.cgi?id=206695 Bug ID: 206695 Summary: kmemleak reports leaks in drivers/macintosh/windfarm Product: Platform Specific/Hardware Version: 2.5 Kernel Version: 5.6-rc3 Hardware: PPC-64 OS: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: PPC-64 Assignee: platform_ppc...@kernel-bugs.osdl.org Reporter: erhar...@mailbox.org Regression: No Created attachment 287687 --> https://bugzilla.kernel.org/attachment.cgi?id=287687&action=edit kmemleak output (kernel 5.6-rc3, PowerMac G5 11,2) kmemleak reports leaks from the windfarm module of my PowerMac G5 11,2: [...] unreferenced object 0xc0047081f840 (size 32): comm "kwindfarm", pid 203, jiffies 4294880630 (age 5552.877s) hex dump (first 32 bytes): c8 06 02 7f ff 02 ff 01 fb bf 00 41 00 20 00 00 ...A. .. 00 07 89 37 00 a0 00 00 00 00 00 00 00 00 00 00 ...7 backtrace: [<83f0a65c>] .smu_sat_get_sdb_partition+0xc4/0x2d0 [windfarm_smu_sat] [<3010fcb7>] .pm112_wf_notify+0x104c/0x13bc [windfarm_pm112] [] .notifier_call_chain+0xa8/0x180 [<70490868>] .blocking_notifier_call_chain+0x64/0x90 [<131d8149>] .wf_thread_func+0x114/0x1a0 [<0d54838d>] .kthread+0x13c/0x190 [<669b72bc>] .ret_from_kernel_thread+0x58/0x64 unreferenced object 0xc004737089f0 (size 16): comm "kwindfarm", pid 203, jiffies 4294880879 (age 5552.050s) hex dump (first 16 bytes): c4 04 01 7f 22 11 e0 e6 ff 55 7b 12 ec 11 00 00 "U{. backtrace: [<83f0a65c>] .smu_sat_get_sdb_partition+0xc4/0x2d0 [windfarm_smu_sat] [ ] .pm112_wf_notify+0x1294/0x13bc [windfarm_pm112] [ ] .notifier_call_chain+0xa8/0x180 [<70490868>] .blocking_notifier_call_chain+0x64/0x90 [<131d8149>] .wf_thread_func+0x114/0x1a0 [<0d54838d>] .kthread+0x13c/0x190 [<669b72bc>] .ret_from_kernel_thread+0x58/0x64 unreferenced object 0xc0047081fdc0 (size 32): comm "kwindfarm", pid 203, jiffies 4294881067 (age 5551.427s) hex dump (first 32 bytes): c9 06 02 7f ff 02 ff 01 fb bf 00 41 00 20 00 00 ...A. .. 00 07 89 37 00 a0 00 00 00 00 00 00 00 00 00 00 ...7 backtrace: [<83f0a65c>] .smu_sat_get_sdb_partition+0xc4/0x2d0 [windfarm_smu_sat] [<3010fcb7>] .pm112_wf_notify+0x104c/0x13bc [windfarm_pm112] [ ] .notifier_call_chain+0xa8/0x180 [<70490868>] .blocking_notifier_call_chain+0x64/0x90 [<131d8149>] .wf_thread_func+0x114/0x1a0 [<0d54838d>] .kthread+0x13c/0x190 [<669b72bc>] .ret_from_kernel_thread+0x58/0x64 unreferenced object 0xc00473708b60 (size 16): comm "kwindfarm", pid 203, jiffies 4294881320 (age 5550.587s) hex dump (first 16 bytes): c5 04 01 7f 22 11 e0 e6 ff 55 7b 12 ec 11 00 00 "U{. backtrace: [<83f0a65c>] .smu_sat_get_sdb_partition+0xc4/0x2d0 [windfarm_smu_sat] [ ] .pm112_wf_notify+0x1294/0x13bc [windfarm_pm112] [ ] .notifier_call_chain+0xa8/0x180 [<70490868>] .blocking_notifier_call_chain+0x64/0x90 [<131d8149>] .wf_thread_func+0x114/0x1a0 [<0d54838d>] .kthread+0x13c/0x190 [<669b72bc>] .ret_from_kernel_thread+0x58/0x64 -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 206695] kmemleak reports leaks in drivers/macintosh/windfarm
https://bugzilla.kernel.org/show_bug.cgi?id=206695 --- Comment #1 from Erhard F. (erhar...@mailbox.org) --- Created attachment 287689 --> https://bugzilla.kernel.org/attachment.cgi?id=287689&action=edit dmesg (kernel 5.6-rc3, PowerMac G5 11,2) -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 206695] kmemleak reports leaks in drivers/macintosh/windfarm
https://bugzilla.kernel.org/show_bug.cgi?id=206695 --- Comment #2 from Erhard F. (erhar...@mailbox.org) --- Created attachment 287691 --> https://bugzilla.kernel.org/attachment.cgi?id=287691&action=edit kernel .config (kernel 5.6-rc3, PowerMac G5 11,2) -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 199471] windfarm_pm72 no longer gets automatically loaded when CONFIG_I2C_POWERMAC=y is set (regression)
https://bugzilla.kernel.org/show_bug.cgi?id=199471 Erhard F. (erhar...@mailbox.org) changed: What|Removed |Added Attachment #275503|0 |1 is obsolete|| Attachment #275505|0 |1 is obsolete|| --- Comment #9 from Erhard F. (erhar...@mailbox.org) --- Created attachment 287741 --> https://bugzilla.kernel.org/attachment.cgi?id=287741&action=edit kernel .config (kernel 4.16, PowerMac G5 11,2) With the attached kernel .config the G5 7,3 and the G5 11,2 automatically load the suitable windfarm module on kernel <4.17. Starting from kernel 4.17 windfarm core needs to be CONFIG_WINDFARM=y to automacitally load the suitable windfarm module, CONFIG_WINDFARM=m is no longer sufficient. Needed for 4.16.x to automatically load the suitable windfarm module: # grep -i wind .config 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 Needed for >=4.17.x to automatically load the suitable windfarm module: # grep -i wind .config CONFIG_WINDFARM=y CONFIG_WINDFARM_PM81=m CONFIG_WINDFARM_PM72=m CONFIG_WINDFARM_RM31=m CONFIG_WINDFARM_PM91=m CONFIG_WINDFARM_PM112=m CONFIG_WINDFARM_PM121=m -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 199471] windfarm_pm72 no longer gets automatically loaded when CONFIG_I2C_POWERMAC=y is set (regression)
https://bugzilla.kernel.org/show_bug.cgi?id=199471 --- Comment #10 from Erhard F. (erhar...@mailbox.org) --- Created attachment 287743 --> https://bugzilla.kernel.org/attachment.cgi?id=287743&action=edit bisect.log Finally checked on that bug again and bisected it. The offending commit is: # git bisect bad | tee -a ~/bisect02.log af503716ac1444db61d80cb6d17cfe62929c21df is the first bad commit commit af503716ac1444db61d80cb6d17cfe62929c21df Author: Javier Martinez Canillas Date: Sun Dec 3 22:40:50 2017 +0100 i2c: core: report OF style module alias for devices registered via OF The buses should honor the firmware interface used to register the device, but the I2C core reports a MODALIAS of the form i2c: even for I2C devices registered via OF. This means that user-space will never get an OF stype uevent MODALIAS even when the drivers modules contain aliases exported from both the I2C and OF device ID tables. For example, an Atmel maXTouch Touchscreen registered by a DT node with compatible "atmel,maxtouch" has the following module alias: $ cat /sys/class/i2c-adapter/i2c-8/8-004b/modalias i2c:maxtouch So udev won't be able to auto-load a module for an OF-only device driver. Many OF-only drivers duplicate the OF device ID table entries in an I2C ID table only has a workaround for how the I2C core reports the module alias. This patch changes the I2C core to report an OF related MODALIAS uevent if the device was registered via OF. So for the previous example, after this patch, the reported MODALIAS for the Atmel maXTouch will be the following: $ cat /sys/class/i2c-adapter/i2c-8/8-004b/modalias of:NtrackpadTCatmel,maxtouch NOTE: This patch may break out-of-tree drivers that were relying on this behavior, and only had an I2C device ID table even when the device was registered via OF. There are no remaining drivers in mainline that do this, but out-of-tree drivers have to be fixed and define a proper OF device ID table to have module auto-loading working. Signed-off-by: Javier Martinez Canillas Tested-by: Dmitry Mastykin Signed-off-by: Wolfram Sang drivers/i2c/i2c-core-base.c | 8 1 file changed, 8 insertions(+) -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 199471] [Bisected][Regression] windfarm_pm* no longer gets automatically loaded when CONFIG_I2C_POWERMAC=y is set
https://bugzilla.kernel.org/show_bug.cgi?id=199471 --- Comment #11 from Erhard F. (erhar...@mailbox.org) --- (In reply to Wolfram Sang from comment #8) > "This has been quite nice since 4.?.x up to 4.16.x as you only need > CONFIG_I2C_POWERMAC=y which selects the proper windfarm_pmXX at boot time." > > I can't find that in the code. Are you sure i2c-powermac requested that > module? I guess so 'cause if I build i2c_powermac as a module and manually modprobe it, all the relevant windfarm modules get pulled in. But not before. # modprobe -v i2c_powermac insmod /lib/modules/4.16.18-PowerMacG5+/kernel/drivers/i2c/busses/i2c-powermac.ko # dmesg | tail [ 150.181478] 11 [ 150.182851] 0 [ 150.184220] 0 [ 150.626685] windfarm: Backside control loop started. [ 150.690132] windfarm: Slots control loop started. [ 150.794843] i2c i2c-0: master_xfer[0] W, addr=0x50, len=1 [ 150.796467] i2c i2c-0: master_xfer[1] R, addr=0x50, len=8 [ 150.801851] i2c i2c-0: NAK from device addr 0x50 msg #0 [ 150.807758] windfarm: Drive bay control loop started. -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 199471] [Bisected][Regression] windfarm_pm* no longer gets automatically loaded when CONFIG_I2C_POWERMAC=y is set
https://bugzilla.kernel.org/show_bug.cgi?id=199471 Erhard F. (erhar...@mailbox.org) changed: What|Removed |Added Attachment #275507|0 |1 is obsolete|| --- Comment #12 from Erhard F. (erhar...@mailbox.org) --- Created attachment 287745 --> https://bugzilla.kernel.org/attachment.cgi?id=287745&action=edit dmesg (kernel 4.16.18, PowerMac G5 11,2) -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 199471] [Bisected][Regression] windfarm_pm* no longer gets automatically loaded when CONFIG_I2C_POWERMAC=y is set
https://bugzilla.kernel.org/show_bug.cgi?id=199471 --- Comment #13 from Erhard F. (erhar...@mailbox.org) --- Created attachment 287747 --> https://bugzilla.kernel.org/attachment.cgi?id=287747&action=edit kernel .config (kernel 4.17, PowerMac G5 11,2) -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 199471] [Bisected][Regression] windfarm_pm* no longer gets automatically loaded when CONFIG_I2C_POWERMAC=y is set
https://bugzilla.kernel.org/show_bug.cgi?id=199471 Erhard F. (erhar...@mailbox.org) changed: What|Removed |Added Attachment #275509|0 |1 is obsolete|| --- Comment #14 from Erhard F. (erhar...@mailbox.org) --- Created attachment 287749 --> https://bugzilla.kernel.org/attachment.cgi?id=287749&action=edit dmesg (kernel 4.17, PowerMac G5 11,2) -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 199471] [Bisected][Regression] windfarm_pm* no longer gets automatically loaded when CONFIG_I2C_POWERMAC=y is set
https://bugzilla.kernel.org/show_bug.cgi?id=199471 Wolfram Sang (w...@the-dreams.de) changed: What|Removed |Added Status|NEEDINFO|ASSIGNED Regression|No |Yes --- Comment #15 from Wolfram Sang (w...@the-dreams.de) --- "I guess so 'cause if I build i2c_powermac as a module and manually modprobe it, all the relevant windfarm modules get pulled in. But not before." Maybe there is a module dependency I overlooked so far, but at least there is no code loading the pm72 module from i2c-powermac. However, the bisect is very valuable and very likely the commit is the culprit. I was suspecting something changed the MODINFO, so loading fails, but I missed this commit, so far. Also, it took me two approaches until I understood all the behaviour involved. Macintosh drivers are still confusing. I will cook up a patch to test later today to see if I was right. -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 201723] [Bisected][Regression] THERM_WINDTUNNEL not working any longer in kernel 4.19.x (PowerMac G4 MDD)
https://bugzilla.kernel.org/show_bug.cgi?id=201723
Wolfram Sang (w...@the-dreams.de) changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|--- |CODE_FIX
--- Comment #7 from Wolfram Sang (w...@the-dreams.de) ---
Commited as 38b17afb0ebb ("macintosh: therm_windtunnel: fix regression when
instantiating devices") and available upstream since v5.6-rc4.
Thanks for everyone helping, especially Erhard, of course!
--
You are receiving this mail because:
You are watching the assignee of the bug.
[Bug 199471] [Bisected][Regression] windfarm_pm* no longer gets automatically loaded when CONFIG_I2C_POWERMAC=y is set
https://bugzilla.kernel.org/show_bug.cgi?id=199471 --- Comment #16 from Wolfram Sang (w...@the-dreams.de) --- Created attachment 287755 --> https://bugzilla.kernel.org/attachment.cgi?id=287755&action=edit proof-of-concept patch for testing Here is the promised patch. I converted all I2C MODULE tables. pm72 didn't have one, so we will see what pulls it in. A test with a machine needing the lm75 driver would be great. Because some code change was needed there. -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 199471] [Bisected][Regression] windfarm_pm* no longer gets automatically loaded when CONFIG_I2C_POWERMAC=y is set
https://bugzilla.kernel.org/show_bug.cgi?id=199471
--- Comment #17 from Erhard F. (erhar...@mailbox.org) ---
(In reply to Wolfram Sang from comment #16)
> Created attachment 287755 [details]
> proof-of-concept patch for testing
>
> Here is the promised patch. I converted all I2C MODULE tables. pm72 didn't
> have one, so we will see what pulls it in.
>
> A test with a machine needing the lm75 driver would be great. Because some
> code change was needed there.
Excellent! Applied your patch on 5.6-rc4 and it just works fine on my G5 11,2!
I can leave CONFIG_WINDFARM=m and the correct modules get pulled in just as it
was before kernel 4.17.
I can't test on the G5 7,3 from my original bug report 'cause I sold this one.
But from my understanding this "lm75" sensor is used in pretty any windfarm_pm*
module?
# grep -i lm75 drivers/macintosh/windfarm_pm*.c
drivers/macintosh/windfarm_pm112.c: request_module("windfarm_lm75_sensor");
drivers/macintosh/windfarm_pm121.c:
request_module("windfarm_lm75_sensor");
drivers/macintosh/windfarm_pm72.c: request_module("windfarm_lm75_sensor");
drivers/macintosh/windfarm_pm81.c:
request_module("windfarm_lm75_sensor");
drivers/macintosh/windfarm_pm91.c:
request_module("windfarm_lm75_sensor");
--
You are receiving this mail because:
You are watching the assignee of the bug.
[Bug 199471] [Bisected][Regression] windfarm_pm* no longer gets automatically loaded when CONFIG_I2C_POWERMAC=y is set
https://bugzilla.kernel.org/show_bug.cgi?id=199471 --- Comment #18 from Erhard F. (erhar...@mailbox.org) --- Created attachment 287757 --> https://bugzilla.kernel.org/attachment.cgi?id=287757&action=edit dmesg (kernel 5.6-rc4 + patch, PowerMac G5 11,2) -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 206733] New: i2c i2c-3: i2c-powermac: modalias failure on /uni-n@f8000000/i2c@f8001000/cereal@1c0
https://bugzilla.kernel.org/show_bug.cgi?id=206733 Bug ID: 206733 Summary: i2c i2c-3: i2c-powermac: modalias failure on /uni-n@f800/i2c@f8001000/cereal@1c0 Product: Platform Specific/Hardware Version: 2.5 Kernel Version: 5.6-rc4 Hardware: PPC-32 OS: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: PPC-32 Assignee: platform_ppc...@kernel-bugs.osdl.org Reporter: erhar...@mailbox.org Regression: No Created attachment 287759 --> https://bugzilla.kernel.org/attachment.cgi?id=287759&action=edit dmesg (5.6-rc4, PowerMac G4 DP) The G4 MDD/DP can't quite pick up this device, despite it shows up in the bootlog earlier. [...] Mär 02 17:23:45 T600 kernel: i2c-dev: adapter [uni-n 1] registered as minor 3 Mär 02 17:23:45 T600 kernel: i2c i2c-3: adapter [uni-n 1] registered Mär 02 17:23:45 T600 kernel: PowerMac i2c bus uni-n 1 registered Mär 02 17:23:45 T600 kernel: i2c i2c-3: i2c-powermac: register /uni-n@f800/i2c@f8001000/cereal@1c0 Mär 02 17:23:45 T600 kernel: i2c i2c-3: i2c-powermac: modalias failure on /uni-n@f800/i2c@f8001000/cereal@1c0 Mär 02 17:23:45 T600 kernel: i2c-dev: adapter [uni-n 0] registered as minor 4 [...] -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 206733] i2c i2c-3: i2c-powermac: modalias failure on /uni-n@f8000000/i2c@f8001000/cereal@1c0
https://bugzilla.kernel.org/show_bug.cgi?id=206733 --- Comment #1 from Erhard F. (erhar...@mailbox.org) --- Created attachment 287761 --> https://bugzilla.kernel.org/attachment.cgi?id=287761&action=edit kernel .config (5.6-rc4, PowerMac G4 DP) -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 206733] i2c i2c-3: i2c-powermac: modalias failure on /uni-n@f8000000/i2c@f8001000/cereal@1c0
https://bugzilla.kernel.org/show_bug.cgi?id=206733 --- Comment #2 from Mathieu Malaterre (mathieu.malate...@gmail.com) --- > i2c i2c-3: i2c-powermac: modalias failure on > /uni-n@f800/i2c@f8001000/cereal@1c0 Ben, Can you confirm this warning is harmless ? -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 199471] [Bisected][Regression] windfarm_pm* no longer gets automatically loaded when CONFIG_I2C_POWERMAC=y is set
https://bugzilla.kernel.org/show_bug.cgi?id=199471 --- Comment #19 from Wolfram Sang (w...@the-dreams.de) --- Well, yes, the lm75 code gets loaded yet it is not clear to me if the device is now created by DT or not. Well, we will see... Patch sent out: http://patchwork.ozlabs.org/patch/1248349/ Let's discuss this one. The proof-of-concept here had a missing line but worked enough. -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 206733] i2c i2c-3: i2c-powermac: modalias failure on /uni-n@f8000000/i2c@f8001000/cereal@1c0
https://bugzilla.kernel.org/show_bug.cgi?id=206733 --- Comment #3 from Benjamin Herrenschmidt (b...@kernel.crashing.org) --- Yes. I had a look (and had to swap in some historical brain cells from tape storage :-) But I think the warning should probably be turned into a dev_dbg. It's probably some gunk in the device-tree but those "cereal" nodes don't matter (I don't remember what they represent but it's not something we care about). -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 206695] kmemleak reports leaks in drivers/macintosh/windfarm
https://bugzilla.kernel.org/show_bug.cgi?id=206695
--- Comment #3 from m...@ellerman.id.au ---
Can you try this patch?
diff --git a/drivers/macintosh/windfarm_pm112.c
b/drivers/macintosh/windfarm_pm112.c
index 4150301a89a5..a16f43a1def9 100644
--- a/drivers/macintosh/windfarm_pm112.c
+++ b/drivers/macintosh/windfarm_pm112.c
@@ -125,7 +125,7 @@ static int create_cpu_loop(int cpu)
{
int chip = cpu / 2;
int core = cpu & 1;
- struct smu_sdbp_header *hdr;
+ struct smu_sdbp_header *hdr, *hdr2;
struct smu_sdbp_cpupiddata *piddata;
struct wf_cpu_pid_param pid;
struct wf_control *main_fan = cpu_fans[0];
@@ -141,9 +141,9 @@ static int create_cpu_loop(int cpu)
piddata = (struct smu_sdbp_cpupiddata *)&hdr[1];
/* Get FVT params to get Tmax; if not found, assume default */
- hdr = smu_sat_get_sdb_partition(chip, 0xC4 + core, NULL);
- if (hdr) {
- struct smu_sdbp_fvt *fvt = (struct smu_sdbp_fvt *)&hdr[1];
+ hdr2 = smu_sat_get_sdb_partition(chip, 0xC4 + core, NULL);
+ if (hdr2) {
+ struct smu_sdbp_fvt *fvt = (struct smu_sdbp_fvt *)&hdr2[1];
tmax = fvt->maxtemp << 16;
} else
tmax = 95 << 16;/* default to 95 degrees C */
@@ -174,6 +174,10 @@ static int create_cpu_loop(int cpu)
pid.min = fmin;
wf_cpu_pid_init(&cpu_pid[cpu], &pid);
+
+ kfree(hdr);
+ kfree(hdr2);
+
return 0;
}
--
You are receiving this mail because:
You are watching the assignee of the bug.
[Bug 206695] kmemleak reports leaks in drivers/macintosh/windfarm
https://bugzilla.kernel.org/show_bug.cgi?id=206695 --- Comment #4 from Erhard F. (erhar...@mailbox.org) --- (In reply to mpe from comment #3) > Can you try this patch? Applied your patch on top of 5.6-rc4 + https://patchwork.ozlabs.org/patch/1248350/ and let the G5 do a few hours compiling. Only getting those nice memleaks from bug #206203 but no windfarm_pm112 memleak any longer. So your patch works well it seems. Thanks! -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 206695] kmemleak reports leaks in drivers/macintosh/windfarm
https://bugzilla.kernel.org/show_bug.cgi?id=206695
--- Comment #5 from m...@ellerman.id.au ---
bugzilla-dae...@bugzilla.kernel.org writes:
> https://bugzilla.kernel.org/show_bug.cgi?id=206695
>
> --- Comment #4 from Erhard F. (erhar...@mailbox.org) ---
> (In reply to mpe from comment #3)
>> Can you try this patch?
>
> Applied your patch on top of 5.6-rc4 +
> https://patchwork.ozlabs.org/patch/1248350/ and let the G5 do a few hours
> compiling.
>
> Only getting those nice memleaks from bug #206203 but no windfarm_pm112
> memleak
> any longer. So your patch works well it seems. Thanks!
Thanks.
Can you try this one instead, it changes the order of operations to make
the code flow a bit nicer.
cheers
diff --git a/drivers/macintosh/windfarm_pm112.c
b/drivers/macintosh/windfarm_pm112.c
index 4150301a89a5..e8377ce0a95a 100644
--- a/drivers/macintosh/windfarm_pm112.c
+++ b/drivers/macintosh/windfarm_pm112.c
@@ -132,14 +132,6 @@ static int create_cpu_loop(int cpu)
s32 tmax;
int fmin;
- /* Get PID params from the appropriate SAT */
- hdr = smu_sat_get_sdb_partition(chip, 0xC8 + core, NULL);
- if (hdr == NULL) {
- printk(KERN_WARNING"windfarm: can't get CPU PID fan config\n");
- return -EINVAL;
- }
- piddata = (struct smu_sdbp_cpupiddata *)&hdr[1];
-
/* Get FVT params to get Tmax; if not found, assume default */
hdr = smu_sat_get_sdb_partition(chip, 0xC4 + core, NULL);
if (hdr) {
@@ -152,6 +144,16 @@ static int create_cpu_loop(int cpu)
if (tmax < cpu_all_tmax)
cpu_all_tmax = tmax;
+ kfree(hdr);
+
+ /* Get PID params from the appropriate SAT */
+ hdr = smu_sat_get_sdb_partition(chip, 0xC8 + core, NULL);
+ if (hdr == NULL) {
+ printk(KERN_WARNING"windfarm: can't get CPU PID fan config\n");
+ return -EINVAL;
+ }
+ piddata = (struct smu_sdbp_cpupiddata *)&hdr[1];
+
/*
* Darwin has a minimum fan speed of 1000 rpm for the 4-way and
* 515 for the 2-way. That appears to be overkill, so for now,
@@ -174,6 +176,9 @@ static int create_cpu_loop(int cpu)
pid.min = fmin;
wf_cpu_pid_init(&cpu_pid[cpu], &pid);
+
+ kfree(hdr);
+
return 0;
}
--
You are receiving this mail because:
You are watching the assignee of the bug.
[Bug 206695] kmemleak reports leaks in drivers/macintosh/windfarm
https://bugzilla.kernel.org/show_bug.cgi?id=206695 --- Comment #6 from Erhard F. (erhar...@mailbox.org) --- (In reply to mpe from comment #5) > Can you try this one instead, it changes the order of operations to make > the code flow a bit nicer. 2nd patch works equally well. -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 206669] Little-endian kernel crashing on POWER8 on heavy big-endian PowerKVM load
https://bugzilla.kernel.org/show_bug.cgi?id=206669 --- Comment #8 from John Paul Adrian Glaubitz (glaub...@physik.fu-berlin.de) --- Created attachment 287823 --> https://bugzilla.kernel.org/attachment.cgi?id=287823&action=edit kern.log containing some crash dumps I have another trace of the crash. Not sure whether this was with tracing disabled. Does that help? -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 206669] Little-endian kernel crashing on POWER8 on heavy big-endian PowerKVM load
https://bugzilla.kernel.org/show_bug.cgi?id=206669 Aneesh Kumar KV (aneesh.ku...@linux.ibm.com) changed: What|Removed |Added CC||aneesh.ku...@linux.ibm.com --- Comment #9 from Aneesh Kumar KV (aneesh.ku...@linux.ibm.com) --- Also, can you try disabling THP. echo "never" > /sys/kernel/mm/transparent_hugepage/enabled -aneesh -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 206669] Little-endian kernel crashing on POWER8 on heavy big-endian PowerKVM load
https://bugzilla.kernel.org/show_bug.cgi?id=206669 --- Comment #10 from John Paul Adrian Glaubitz (glaub...@physik.fu-berlin.de) --- (In reply to Aneesh Kumar KV from comment #9) > Also, can you try disabling THP. echo "never" > > /sys/kernel/mm/transparent_hugepage/enabled Yes. Just disabled. FWIW, the machine just crashed some minutes ago but I didn't have a serial console open to capture the trace. -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 206669] Little-endian kernel crashing on POWER8 on heavy big-endian PowerKVM load
https://bugzilla.kernel.org/show_bug.cgi?id=206669 --- Comment #11 from John Paul Adrian Glaubitz (glaub...@physik.fu-berlin.de) --- It seems I can provoke the crash by running the glibc testsuite in a big-endian guest VM. The machine just crashed with the IPMI console open but the only message the kernel printed was: "watson login: [ 1809.138398] KVM: couldn't grab cpu 115" I have not observed the kernel buffer though. But I will try to provoke the crash now while having the kernel log open. -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 206669] Little-endian kernel crashing on POWER8 on heavy big-endian PowerKVM load
https://bugzilla.kernel.org/show_bug.cgi?id=206669 --- Comment #12 from John Paul Adrian Glaubitz (glaub...@physik.fu-berlin.de) --- Another crash: watson login: [17667512263.751484] BUG: Unable to handle kernel data access at 0xc00ff06e4838 [17667512263.751507] Faulting instruction address: 0xc017a778 [17667512263.751513] BUG: Unable to handle kernel data access at 0xc007f9070c08 [17667512263.751517] Faulting instruction address: 0xc02659a0 [17667512263.751521] BUG: Unable to handle kernel data access at 0xc007f9070c08 [17667512263.751525] Faulting instruction address: 0xc02659a0 [17667512263.751529] BUG: Unable to handle kernel data access at 0xc007f9070c08 [17667512263.751533] Faulting instruction address: 0xc02659a0 [17667512263.751537] BUG: Unable to handle kernel data access at 0xc007f9070c08 [17667512263.751541] Faulting instruction address: 0xc02659a0 [17667512263.751545] BUG: Unable to handle kernel data access at 0xc007f9070c08 [17667512263.751548] Faulting instruction address: 0xc02659a0 [17667512263.751552] BUG: Unable to handle kernel data access at 0xc007f9070c08 [17667512263.751556] Faulting instruction address: 0xc02659a0 [17667512263.751560] BUG: Unable to handle kernel data access at 0xc007f9070c08 [17667512263.751564] Faulting instruction address: 0xc02659a0 [17667512263.751569] BUG: Unable to handle kernel data access at 0xc007f9070c08 [17667512263.751574] Faulting instruction address: 0xc02659a0 [17667512263.751578] BUG: Unable to handle kernel data access at 0xc007f9070c08 [17667512263.751583] Faulting instruction address: 0xc02659a0 [17667512263.751587] BUG: Unable to handle kernel data access at 0xc007f9070c08 [17667512263.751591] Faulting instruction address: 0xc02659a0 [17667512263.751596] BUG: Unable to handle kernel data access at 0xc007f9070c08 [17667512263.751600] Faulting instruction address: 0xc02659a0 [17667512263.751604] Thread overran stack, or stack corrupted [17667512263.751608] BUG: Unable to handle kernel data access at 0xc007f9070c08 [17667512263.751612] Faulting instruction address: 0xc02659a0 [17667512263.751615] Thread overran stack, or stack corrupted [17667512263.751618] BUG: Unable to handle kernel data access at 0xc007f9070c08 [ 1835.743178] BUG: Unable to handle unknown paging fault at 0xc0c4b363 [ 1835.743180] Faulting instruction address: 0x [17667512263.751633] Faulting instruction address: 0xc02659a0 [ 1835.743195] Oops: Kernel access of bad area, sig: 11 [#1] [ 1835.743198] LE PAGE_SIZE=64K MMU=Hash SMP NR_CPUS=2048 NUMA PowerNV [ 1835.743203] Modules linked in: [17667512263.751652] Thread overran stack, or stack corrupted [ 1835.743205] -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 206669] Little-endian kernel crashing on POWER8 on heavy big-endian PowerKVM load
https://bugzilla.kernel.org/show_bug.cgi?id=206669 --- Comment #13 from John Paul Adrian Glaubitz (glaub...@physik.fu-berlin.de) --- watson login: [30887.552539] KVM: CPU 4 seems to be stuck [30900.094713] watchdog: CPU 8 detected hard LOCKUP on other CPUs 0 [30900.094730] watchdog: CPU 8 TB:15863742878763, last SMP heartbeat TB:15855546563837 (16008ms ago) [30908.222926] watchdog: BUG: soft lockup - CPU#80 stuck for 22s! [CPU 4/KVM:2698] [30908.374929] watchdog: BUG: soft lockup - CPU#112 stuck for 22s! [CPU 23/KVM:2717] [30908.426934] watchdog: BUG: soft lockup - CPU#120 stuck for 22s! [CPU 16/KVM:2710] [30909.570962] rcu: INFO: rcu_sched self-detected stall on CPU [30909.570970] rcu: 120-: (5059 ticks this GP) idle=7d2/1/0x4002 softirq=421758/421758 fqs=2378 [30912.095025] watchdog: BUG: soft lockup - CPU#8 stuck for 23s! [CPU 18/KVM:2712] [30912.127027] watchdog: BUG: soft lockup - CPU#40 stuck for 23s! [CPU 22/KVM:2716] [30912.155026] watchdog: BUG: soft lockup - CPU#56 stuck for 23s! [CPU 27/KVM:2721] [30912.175028] watchdog: BUG: soft lockup - CPU#64 stuck for 23s! [CPU 26/KVM:2720] [30912.195028] watchdog: BUG: soft lockup - CPU#72 stuck for 23s! [CPU 19/KVM:2713] [30912.547038] watchdog: BUG: soft lockup - CPU#136 stuck for 22s! [CPU 8/KVM:2702] [30912.619040] watchdog: BUG: soft lockup - CPU#144 stuck for 22s! [CPU 5/KVM:2699] -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 206203] kmemleak reports various leaks in drivers/of/unittest.c
https://bugzilla.kernel.org/show_bug.cgi?id=206203 Erhard F. (erhar...@mailbox.org) changed: What|Removed |Added Attachment #286803|0 |1 is obsolete|| --- Comment #8 from Erhard F. (erhar...@mailbox.org) --- Created attachment 288185 --> https://bugzilla.kernel.org/attachment.cgi?id=288185&action=edit dmesg (kernel 5.6.2, Talos II) -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 206203] kmemleak reports various leaks in drivers/of/unittest.c
https://bugzilla.kernel.org/show_bug.cgi?id=206203 Erhard F. (erhar...@mailbox.org) changed: What|Removed |Added Attachment #286805|0 |1 is obsolete|| --- Comment #9 from Erhard F. (erhar...@mailbox.org) --- Created attachment 288187 --> https://bugzilla.kernel.org/attachment.cgi?id=288187&action=edit kernel .config (kernel 5.6.2, Talos II) -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 206203] kmemleak reports various leaks in drivers/of/unittest.c
https://bugzilla.kernel.org/show_bug.cgi?id=206203 Erhard F. (erhar...@mailbox.org) changed: What|Removed |Added Attachment #286801|0 |1 is obsolete|| --- Comment #10 from Erhard F. (erhar...@mailbox.org) --- Created attachment 288189 --> https://bugzilla.kernel.org/attachment.cgi?id=288189&action=edit kmemleak output (kernel 5.6.2, Talos II) -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 207129] New: PowerMac G4 DP (5.6.2 debug kernel + inline KASAN) freezes shortly after booting with "do_IRQ: stack overflow: 1760"
https://bugzilla.kernel.org/show_bug.cgi?id=207129 Bug ID: 207129 Summary: PowerMac G4 DP (5.6.2 debug kernel + inline KASAN) freezes shortly after booting with "do_IRQ: stack overflow: 1760" Product: Platform Specific/Hardware Version: 2.5 Kernel Version: 5.6.2 Hardware: PPC-32 OS: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: PPC-32 Assignee: platform_ppc...@kernel-bugs.osdl.org Reporter: erhar...@mailbox.org CC: christophe.le...@c-s.fr Regression: No Created attachment 288221 --> https://bugzilla.kernel.org/attachment.cgi?id=288221&action=edit kernel .config (5.6.2, INLINE KASAN, PowerMac G4 DP) Was trying to do some testing with the PowerMac G4 DP again, running a 5.6.2 debug kernel w. KASAN INLINE. The G4 boots fine, but crashes shortly afterwards when using it, leaving no stack trace, but only this message on the screen: do_IRQ: stack overflow: 1760 CPU: 0 PID: 209 Comm: rsync Tained: GW5.6.2-PowerMacG4+ #3 Call Trace: 120 seconds panic timer does not kick in. I have to manually switch off/switch on the G4. -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 199561] sungem: RX MAC fifo overflow smac[03910440]
https://bugzilla.kernel.org/show_bug.cgi?id=199561 Erhard F. (erhar...@mailbox.org) changed: What|Removed |Added Attachment #280931|0 |1 is obsolete|| --- Comment #5 from Erhard F. (erhar...@mailbox.org) --- Created attachment 288223 --> https://bugzilla.kernel.org/attachment.cgi?id=288223&action=edit dmesg (5.6.2, PowerMac G4 DP) Still in recent kernels (5.6.2). -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 199561] sungem: RX MAC fifo overflow smac[03910440]
https://bugzilla.kernel.org/show_bug.cgi?id=199561 --- Comment #6 from Erhard F. (erhar...@mailbox.org) --- Created attachment 288225 --> https://bugzilla.kernel.org/attachment.cgi?id=288225&action=edit kernel .config (5.6.2, PowerMac G4 DP) -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 207129] PowerMac G4 DP (5.6.2 debug kernel + inline KASAN) freezes shortly after booting with "do_IRQ: stack overflow: 1760"
https://bugzilla.kernel.org/show_bug.cgi?id=207129 --- Comment #1 from Christophe Leroy (christophe.le...@c-s.fr) --- So it hands in show_stack(). Does it also hang without CONFIG_DEBUG_STACKOVERFLOW ? If not, it means we have a problem with check_stack_overflow() Regardless of the result above, can you try increasing CONFIG_THREAD_SHIFT ? Can you maybe also do a test without CONFIG_VMAP_STACK ? -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 207129] PowerMac G4 DP (5.6.2 debug kernel + inline KASAN) freezes shortly after booting with "do_IRQ: stack overflow: 1760"
https://bugzilla.kernel.org/show_bug.cgi?id=207129 --- Comment #2 from Erhard F. (erhar...@mailbox.org) --- Created attachment 288229 --> https://bugzilla.kernel.org/attachment.cgi?id=288229&action=edit screenshot01.jpg Without CONFIG_DEBUG_STACKOVERFLOW things are better. The rsync completes, the G4 was building stuff for 2 hours or so until I got these errors and a hard freeze: [...] Oops: kernel stack overflow, sig: 11 [#1] BE PAGE_SIZE=4K MMU=Hash SMP NR_CPUS=2 PowerMac Modules linked in: ... CPU: 1 PID: 17105 Comm: kworker/u4:5 Tainted: GW 5.6.2-PowerMacG4+ #5 [ cut here ] kernel BUG at mm/usercopy.c:99! Oops: Exception in kernel mode, sig: 5 [#2] BE PAGE_SIZE=4K MMU=Hash SMP NR_CPUS=2 PowerMac Modules linked in: ... CPU: 1 PID: 17185 Comm: kworker/u4:5 Tainted: GW 5.6.2-PowerMacG4+ #5 usercopy: Kernel memory overwrite attempt detected to kernel text (offset 6336, size 4)! [ cut here ] kernel BUG at mm/usercopy.c:99! Oops: Exception in kernel mode, sig: 5 [#3] BE PAGE_SIZE=4K MMU=Hash SMP NR_CPUS=2 PowerMac Modules linked in: ... CPU: 1 PID: 17185 Comm: kworker/u4:5 Tainted: GW 5.6.2-PowerMacG4+ #5 usercopy: Kernel memory overwrite attempt detected to kernel text (offset 5336, size 4)! [ cut here ] kernel BUG at mm/usercopy.c:99! Oops: Exception in kernel mode, sig: 5 [#4] BE PAGE_SIZE=4K MMU=Hash SMP NR_CPUS=2 PowerMac Modules linked in: ... CPU: 1 PID: 17185 Comm: kworker/u4:5 Tainted: GW 5.6.2-PowerMacG4+ #5 usercopy: Kernel memory overwrite attempt detected to kernel text (offset 4336, size 4)! [ cut here ] kernel BUG at mm/usercopy.c:99! Oops: Exception in kernel mode, sig: 5 [#5] BE PAGE_SIZE=4K MMU=Hash SMP NR_CPUS=2 PowerMac Modules linked in: ... Unrecoverable FP Unavailable Exception 801 at 9b8 CPU: 1 PID: 17185 Comm: kworker/u4:5 Tainted: GW 5.6.2-PowerMacG4+ #5 usercopy: Kernel memory overwrite attempt detected to kernel text (offset 3336, size 4)! [ cut here ] Now running with CONFIG_THREAD_SHIFT=14 which runs fine so far... Did not try without CONFIG_VMAP_STACK yet. -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 207129] PowerMac G4 DP (5.6.2 debug kernel + inline KASAN) freezes shortly after booting with "do_IRQ: stack overflow: 1760"
https://bugzilla.kernel.org/show_bug.cgi?id=207129 --- Comment #3 from Erhard F. (erhar...@mailbox.org) --- Created attachment 288231 --> https://bugzilla.kernel.org/attachment.cgi?id=288231&action=edit screenshot02.jpg -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 199561] sungem: RX MAC fifo overflow smac[03910440]
https://bugzilla.kernel.org/show_bug.cgi?id=199561 Erhard F. (erhar...@mailbox.org) changed: What|Removed |Added CC||linuxppc-dev@lists.ozlabs.o ||rg Hardware|PPC-64 |PPC-32 Kernel Version|4.19.19 |5.4-rc4 --- Comment #4 from Erhard F. (erhar...@mailbox.org) --- On 5.4-rc4 I am getting now: [ 43.822417] sungem_phy: PHY ID: 2060e1, addr: 0 [ 43.831184] gem 0002:20:0f.0 enP2p32s15f0: Found BCM5421 PHY [ 47.502223] gem 0002:20:0f.0 enP2p32s15f0: Link is up at 1000 Mbps, full-duplex [ 47.502697] gem 0002:20:0f.0 enP2p32s15f0: Pause is enabled (rxfifo: 10240 off: 7168 on: 5632) [ 47.503173] IPv6: ADDRCONF(NETDEV_CHANGE): enP2p32s15f0: link becomes ready [...] [ 423.097905] gem 0002:20:0f.0 enP2p32s15f0: Memory squeeze, deferring packet [ 423.125951] gem 0002:20:0f.0 enP2p32s15f0: Memory squeeze, deferring packet [ 423.148828] gem 0002:20:0f.0 enP2p32s15f0: Memory squeeze, deferring packet [ 423.156830] gem 0002:20:0f.0 enP2p32s15f0: RX MAC fifo overflow smac[00910440] [ 423.243823] gem 0002:20:0f.0 enP2p32s15f0: Memory squeeze, deferring packet -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 205283] New: BUG: KASAN: global-out-of-bounds in _copy_to_iter+0x3d4/0x5a8
https://bugzilla.kernel.org/show_bug.cgi?id=205283 Bug ID: 205283 Summary: BUG: KASAN: global-out-of-bounds in _copy_to_iter+0x3d4/0x5a8 Product: File System Version: 2.5 Kernel Version: 5.4-rc4 Hardware: PPC-32 OS: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: btrfs Assignee: fs_bt...@kernel-bugs.kernel.org Reporter: erhar...@mailbox.org CC: platform_ppc...@kernel-bugs.osdl.org Regression: No Created attachment 285605 --> https://bugzilla.kernel.org/attachment.cgi?id=285605&action=edit dmesg (kernel 5.4.0-rc4, PowerMac G4 DP) First of all apologies 'cause I am not quite sure under what kernel subsystem tracker I should file this bug. It was triggered running btrfs filesystem tests (misc tests) on a PowerMac G4 DP and seems to touch some memcopy routine: [...] [ 601.897623] == [ 601.905117] BUG: KASAN: global-out-of-bounds in _copy_to_iter+0x3d4/0x5a8 [ 601.912512] Write of size 4096 at addr f18b8000 by task modprobe/10589 [ 601.927287] CPU: 1 PID: 10589 Comm: modprobe Tainted: GW 5.4.0-rc4-PowerMacG4+ #20 [ 601.934991] Call Trace: [ 601.942534] [eb9cf848] [c0769184] dump_stack+0xb0/0x10c (unreliable) [ 601.950307] [eb9cf878] [c023aea8] print_address_description.isra.5+0x3c/0x420 [ 601.958167] [eb9cf908] [c023b470] __kasan_report+0x140/0x188 [ 601.966030] [eb9cf948] [c023bea8] check_memory_region+0x28/0x184 [ 601.973925] [eb9cf958] [c0239f30] memcpy+0x48/0x74 [ 601.981792] [eb9cf978] [c044ab9c] _copy_to_iter+0x3d4/0x5a8 [ 601.989705] [eb9cfaa8] [c044af18] copy_page_to_iter+0x90/0x550 [ 601.997585] [eb9cfb08] [c01bcc60] generic_file_read_iter+0x5c8/0x7bc [ 602.005374] [eb9cfb78] [c0251e5c] __vfs_read+0x1b0/0x1f4 [ 602.013027] [eb9cfca8] [c0251f5c] vfs_read+0xbc/0x124 [ 602.020671] [eb9cfcd8] [c0252018] kernel_read+0x54/0x70 [ 602.028302] [eb9cfd08] [c025c7d8] kernel_read_file+0x240/0x358 [ 602.035930] [eb9cfdb8] [c025c9dc] kernel_read_file_from_fd+0x54/0x74 [ 602.043581] [eb9cfdf8] [c010c494] sys_finit_module+0xd8/0x140 [ 602.051183] [eb9cff38] [c001a274] ret_from_syscall+0x0/0x34 [ 602.058641] --- interrupt: c01 at 0x7062c4 LR = 0x88e7c4 [ 602.087858] Memory state around the buggy address: [ 602.095160] f18b7f00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 602.102601] f18b7f80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 602.109845] >f18b8000: 00 06 fa fa fa fa fa fa 00 00 03 fa fa fa fa fa [ 602.117150] ^ [ 602.124218] f18b8080: 00 00 04 fa fa fa fa fa 00 03 fa fa fa fa fa fa [ 602.131467] f18b8100: 00 07 fa fa fa fa fa fa 00 00 03 fa fa fa fa fa [ 602.138638] == -- You are receiving this mail because: You are watching someone on the CC list of the bug.
[Bug 205283] BUG: KASAN: global-out-of-bounds in _copy_to_iter+0x3d4/0x5a8
https://bugzilla.kernel.org/show_bug.cgi?id=205283 --- Comment #1 from Erhard F. (erhar...@mailbox.org) --- Created attachment 285607 --> https://bugzilla.kernel.org/attachment.cgi?id=285607&action=edit 5.4.0-rc4 kernel .config (PowerMac G4 DP) -- You are receiving this mail because: You are watching someone on the CC list of the bug.
[Bug 205303] New: Compilation for PPC64 fails on warning in watchdog.o
https://bugzilla.kernel.org/show_bug.cgi?id=205303 Bug ID: 205303 Summary: Compilation for PPC64 fails on warning in watchdog.o Product: Platform Specific/Hardware Version: 2.5 Kernel Version: 5.3.7 Hardware: PPC-64 OS: Linux Tree: Mainline Status: NEW Severity: blocking Priority: P1 Component: PPC-64 Assignee: platform_ppc...@kernel-bugs.osdl.org Reporter: payphon...@gmail.com Regression: No Kernel compilation of 5.3.7 on PowerPC 64bit fails with a compiler warning treated as an error. arch/powerpc/kernel/watchdog.c: In function *watchdog_smp_panic*: arch/powerpc/kernel/watchdog.c:175:4: error: implicit declaration of function *smp_send_nmi_ipi*: did you mean *smp_send_stop*? [-Werror=implicit-function-declaration] SMP and Watchdog Timer Support are both disabled in this kernel configuration. If additional information is necessary please ask. -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 205303] Compilation for PPC64 fails on warning in watchdog.o
https://bugzilla.kernel.org/show_bug.cgi?id=205303 --- Comment #1 from Edward Swiftwood (payphon...@gmail.com) --- I failed to mention, the machine is an Apple iMac G5 "PowerMac8,1", PPC970FX @ 1600MHz. (https://everymac.com/systems/apple/imac/specs/imac_g5_1.6_17.html) -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 205303] Compilation for PPC64 fails on warning in watchdog.o
https://bugzilla.kernel.org/show_bug.cgi?id=205303 A. Wilcox (awil...@adelielinux.org) changed: What|Removed |Added CC||awil...@adelielinux.org --- Comment #2 from A. Wilcox (awil...@adelielinux.org) --- This is because CONFIG_HARDLOCK_DETECTOR is on and CONFIG_NMI_IPI is off. CONFIG_HARDLOCK_DETECTOR pulls in CONFIG_PPC_WATCHDOG, which unconditionally uses smp_send_nmi_ipi (and I believe requires such to work properly). CONFIG_PPC_WATCHDOG doesn't depend on CONFIG_NMI_IPI which it probably should. And then CONFIG_HARDLOCK_DETECTOR_ARCH should probably depend on CONFIG_NMI_IPI or CONFIG_PPC_WATCHDOG. -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 205327] New: kmemleak reports various leaks in "swapper/0"
https://bugzilla.kernel.org/show_bug.cgi?id=205327 Bug ID: 205327 Summary: kmemleak reports various leaks in "swapper/0" Product: Platform Specific/Hardware Version: 2.5 Kernel Version: 5.4-rc4 Hardware: PPC-64 OS: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: PPC-64 Assignee: platform_ppc...@kernel-bugs.osdl.org Reporter: erhar...@mailbox.org Regression: No Created attachment 285655 --> https://bugzilla.kernel.org/attachment.cgi?id=285655&action=edit kmemleak output kmemleak reported various leaks in "swapper/0" while I was building some stuff via distcc: unreferenced object 0xc0027eea64e0 (size 32): comm "swapper/0", pid 1, jiffies 4294877673 (age 1568.254s) hex dump (first 32 bytes): 2f 5f 5f 6c 6f 63 61 6c 5f 66 69 78 75 70 73 5f /__local_fixups_ 5f 00 00 00 00 ca ad c8 00 00 00 00 00 00 00 00 _... backtrace: [] .kvasprintf+0x64/0xe0 [ ] .kasprintf+0x2c/0x50 [<00808425>] .attach_node_and_children+0x2c/0x270 [ ] .of_unittest+0x1f4/0x379c [ ] .do_one_initcall+0x7c/0x430 [ ] .kernel_init_freeable+0x2d0/0x3cc [<5adf1660>] .kernel_init+0x1c/0x138 [<6adcb060>] .ret_from_kernel_thread+0x58/0x64 [...] -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 205327] kmemleak reports various leaks in "swapper/0"
https://bugzilla.kernel.org/show_bug.cgi?id=205327 --- Comment #1 from Erhard F. (erhar...@mailbox.org) --- Created attachment 285659 --> https://bugzilla.kernel.org/attachment.cgi?id=285659&action=edit 5.4.0-rc4 kernel .config (PowerMac G5 7,3) -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 205327] kmemleak reports various leaks in "swapper/0"
https://bugzilla.kernel.org/show_bug.cgi?id=205327 --- Comment #2 from Erhard F. (erhar...@mailbox.org) --- Created attachment 285661 --> https://bugzilla.kernel.org/attachment.cgi?id=285661&action=edit dmesg (kernel 5.4.0-rc4, PowerMac G5 7,3) -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 205327] kmemleak reports various leaks in "swapper/0"
https://bugzilla.kernel.org/show_bug.cgi?id=205327
Michael Ellerman (mich...@ellerman.id.au) changed:
What|Removed |Added
Status|NEW |ASSIGNED
CC||mich...@ellerman.id.au
--- Comment #3 from Michael Ellerman (mich...@ellerman.id.au) ---
That looks like a pretty straight forward memory leak here:
static void attach_node_and_children(struct device_node *np)
{
struct device_node *next, *dup, *child;
unsigned long flags;
const char *full_name;
full_name = kasprintf(GFP_KERNEL, "%pOF", np);
if (!strcmp(full_name, "/__local_fixups__") ||
!strcmp(full_name, "/__fixups__"))
>> missing kfree(full_name);
return;
dup = of_find_node_by_path(full_name);
kfree(full_name);
if (dup) {
update_node_properties(np, dup);
return;
}
Do you want to send a patch?
--
You are receiving this mail because:
You are watching the assignee of the bug.
[Bug 205201] Booting halts if Dawicontrol DC-2976 UW SCSI board installed, unless RAM size limited to 3500M
https://bugzilla.kernel.org/show_bug.cgi?id=205201 --- Comment #2 from Christian Zigotzky (chzigot...@xenosoft.de) --- Error message without limitation to 3.5G RAM: [ 25.654852] bttv 1000:04:05.0: overflow 0xfe077000+4096 of DMA mask bus mask df00 The kernel configured the bttv card for DMA in the upper region of RAM but the device believes that it only supports 32-bit addressing. -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 205327] kmemleak reports various leaks in "swapper/0"
https://bugzilla.kernel.org/show_bug.cgi?id=205327 --- Comment #4 from Erhard F. (erhar...@mailbox.org) --- (In reply to Michael Ellerman from comment #3) > That looks like a pretty straight forward memory leak here: [...] > Do you want to send a patch? Thanks for pointing out! Yes, in this case writing a patch is within reach of my coding skills. ;) Have to check the procedure of how to submit a patch to the kernel first, as I have not done this yet. -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 205201] Booting halts if Dawicontrol DC-2976 UW SCSI board installed, unless RAM size limited to 3500M
https://bugzilla.kernel.org/show_bug.cgi?id=205201 Christophe Leroy (christophe.le...@c-s.fr) changed: What|Removed |Added CC||christophe.le...@c-s.fr --- Comment #3 from Christophe Leroy (christophe.le...@c-s.fr) --- Can you bisect to identify the faulting commit ? -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 205201] Booting halts if Dawicontrol DC-2976 UW SCSI board installed, unless RAM size limited to 3500M
https://bugzilla.kernel.org/show_bug.cgi?id=205201 --- Comment #4 from Christian Zigotzky (chzigot...@xenosoft.de) --- Yes, I can. Could you please post the correct commits for starting bisect? git bisect start git bisect good ? git bisect bad ? Thanks -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 205201] Booting halts if Dawicontrol DC-2976 UW SCSI board installed, unless RAM size limited to 3500M
https://bugzilla.kernel.org/show_bug.cgi?id=205201 --- Comment #5 from Christophe Leroy (christophe.le...@c-s.fr) --- I guess: git bisect bad 8d6973327 git bisect good v4.20 -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 205201] Booting halts if Dawicontrol DC-2976 UW SCSI board installed, unless RAM size limited to 3500M
https://bugzilla.kernel.org/show_bug.cgi?id=205201 --- Comment #6 from Christian Zigotzky (chzigot...@xenosoft.de) --- FYI because of the issue with some PCI cards (SCSI, TV cards etc): Christoph Hellwig wrote: Can you send me the .config and a dmesg? And in the meantime try the patch below? >From 4d659b7311bd4141fdd3eeeb80fa2d7602ea01d4 Mon Sep 17 00:00:00 2001 From: Nicolas Saenz Julienne Date: Fri, 18 Oct 2019 13:00:43 +0200 Subject: dma-direct: check for overflows on 32 bit DMA addresses As seen on the new Raspberry Pi 4 and sta2x11's DMA implementation it is possible for a device configured with 32 bit DMA addresses and a partial DMA mapping located at the end of the address space to overflow. It happens when a higher physical address, not DMAable, is translated to it's DMA counterpart. For example the Raspberry Pi 4, configurable up to 4 GB of memory, has an interconnect capable of addressing the lower 1 GB of physical memory with a DMA offset of 0xc000. It transpires that, any attempt to translate physical addresses higher than the first GB will result in an overflow which dma_capable() can't detect as it only checks for addresses bigger then the maximum allowed DMA address. Fix this by verifying in dma_capable() if the DMA address range provided is at any point lower than the minimum possible DMA address on the bus. Signed-off-by: Nicolas Saenz Julienne --- include/linux/dma-direct.h | 8 1 file changed, 8 insertions(+) diff --git a/include/linux/dma-direct.h b/include/linux/dma-direct.h index adf993a3bd58..6ad9e9ea7564 100644 --- a/include/linux/dma-direct.h +++ b/include/linux/dma-direct.h @@ -3,6 +3,7 @@ #define _LINUX_DMA_DIRECT_H 1 #include +#include /* for min_low_pfn */ #include #ifdef CONFIG_ARCH_HAS_PHYS_TO_DMA @@ -27,6 +28,13 @@ static inline bool dma_capable(struct device *dev, dma_addr_t addr, size_t size) if (!dev->dma_mask) return false; +#ifndef CONFIG_ARCH_DMA_ADDR_T_64BIT +/* Check if DMA address overflowed */ +if (min(addr, addr + size - 1) < +__phys_to_dma(dev, (phys_addr_t)(min_low_pfn << PAGE_SHIFT))) +return false; +#endif + return addr + size - 1 <= min_not_zero(*dev->dma_mask, dev->bus_dma_mask); } -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 205201] Booting halts if Dawicontrol DC-2976 UW SCSI board installed, unless RAM size limited to 3500M
https://bugzilla.kernel.org/show_bug.cgi?id=205201 --- Comment #7 from Christian Zigotzky (chzigot...@xenosoft.de) --- Unfortunately this patch doesn't solve the issue. Error message: [6.041163] bttv: driver version 0.9.19 loaded [6.041167] bttv: using 8 buffers with 2080k (520 pages) each for capture [6.041559] bttv: Bt8xx card found (0) [6.041609] bttv: 0: Bt878 (rev 17) at 1000:04:05.0, irq: 19, latency: 128, mmio: 0xc20001000 [6.041622] bttv: 0: using: Typhoon TView RDS + FM Stereo / KNC1 TV Station RDS [card=53,insmod option] [6.042216] bttv: 0: tuner type=5 [6.111994] bttv: 0: audio absent, no audio device found! [6.176425] bttv: 0: Setting PLL: 28636363 => 35468950 (needs up to 100ms) [6.25] bttv: PLL set ok [6.209351] bttv: 0: registered device video0 [6.211576] bttv: 0: registered device vbi0 [6.214897] bttv: 0: registered device radio0 [ 114.218806] bttv 1000:04:05.0: overflow 0xff507000+4096 of DMA mask bus mask df00 [ 114.218848] Modules linked in: rfcomm bnep tuner_simple tuner_types tea5767 tuner tda7432 tvaudio msp3400 bttv tea575x tveeprom videobuf_dma_sg videobuf_core rc_core videodev mc btusb btrtl btbcm btintel bluetooth uio_pdrv_genirq uio ecdh_generic ecc [ 114.219012] [c001ecddf720] [808ff6e8] .buffer_prepare+0x150/0x268 [bttv] [ 114.219029] [c001ecddf860] [808fff6c] .bttv_qbuf+0x50/0x64 [bttv] -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 205201] Booting halts if Dawicontrol DC-2976 UW SCSI board installed, unless RAM size limited to 3500M
https://bugzilla.kernel.org/show_bug.cgi?id=205201 --- Comment #8 from Christian Zigotzky (chzigot...@xenosoft.de) --- Trace: [ 462.783184] Call Trace: [ 462.783187] [c001c6c67420] [c00b3358] .report_addr+0xb8/0xc0 (unreliable) [ 462.783192] [c001c6c67490] [c00b351c] .dma_direct_map_page+0xf0/0x128 [ 462.783195] [c001c6c67530] [c00b35b0] .dma_direct_map_sg+0x5c/0xac [ 462.783205] [c001c6c675e0] [80862e88] .__videobuf_iolock+0x660/0x6d8 [videobuf_dma_sg] [ 462.783220] [c001c6c676b0] [80854274] .videobuf_iolock+0x98/0xb4 [videobuf_core] [ 462.783271] [c001c6c67720] [808686e8] .buffer_prepare+0x150/0x268 [bttv] [ 462.783276] [c001c6c677c0] [80854afc] .videobuf_qbuf+0x2b8/0x428 [videobuf_core] [ 462.783288] [c001c6c67860] [80868f6c] .bttv_qbuf+0x50/0x64 [bttv] [ 462.783383] [c001c6c678e0] [807bf208] .v4l_qbuf+0x54/0x60 [videodev] [ 462.783402] [c001c6c67970] [807c1eac] .__video_do_ioctl+0x30c/0x3f8 [videodev] [ 462.783421] [c001c6c67a80] [807c3c08] .video_usercopy+0x18c/0x3dc [videodev] [ 462.783440] [c001c6c67c00] [807bb14c] .v4l2_ioctl+0x60/0x78 [videodev] [ 462.783460] [c001c6c67c90] [807d3c48] .v4l2_compat_ioctl32+0x9b4/0x1850 [videodev] [ 462.783468] [c001c6c67d70] [c01ad9cc] .__se_compat_sys_ioctl+0x284/0x127c [ 462.783473] [c001c6c67e20] [c67c] system_call+0x60/0x6c [ 462.783475] Instruction dump: [ 462.783477] 40fe0044 6000 892255d0 2f89 40fe0020 3c82ffc5 3921 6000 [ 462.783483] 38842029 992255d0 485ad0d9 6000 <0fe0> 38210070 e8010010 7c0803a6 [ 462.783490] ---[ end trace b677d4a00458e277 ]--- -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 205201] Booting halts if Dawicontrol DC-2976 UW SCSI board installed, unless RAM size limited to 3500M
https://bugzilla.kernel.org/show_bug.cgi?id=205201 --- Comment #9 from Christian Zigotzky (chzigot...@xenosoft.de) --- Created attachment 285813 --> https://bugzilla.kernel.org/attachment.cgi?id=285813&action=edit dmesg fsl p5040 -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 205201] Booting halts if Dawicontrol DC-2976 UW SCSI board installed, unless RAM size limited to 3500M
https://bugzilla.kernel.org/show_bug.cgi?id=205201 --- Comment #10 from Christian Zigotzky (chzigot...@xenosoft.de) --- Created attachment 285815 --> https://bugzilla.kernel.org/attachment.cgi?id=285815&action=edit Kernel 5.4-rc6 config for the Cyrus+ board and for the QEMU ppce500 board (CPU: P5040 and P5020) -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 205201] Booting halts if Dawicontrol DC-2976 UW SCSI board installed, unless RAM size limited to 3500M
https://bugzilla.kernel.org/show_bug.cgi?id=205201 --- Comment #11 from Christian Zigotzky (chzigot...@xenosoft.de) --- Christoph, Do you have another patch for testing or shall I bisect? Thanks, Christian -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 205201] Booting halts if Dawicontrol DC-2976 UW SCSI board installed, unless RAM size limited to 3500M
https://bugzilla.kernel.org/show_bug.cgi?id=205201 --- Comment #12 from Christian Zigotzky (chzigot...@xenosoft.de) --- Hi Christoph, I have seen that I have activated the kernel config option CONFIG_ARCH_DMA_ADDR_T_64BIT. That means your code in your patch won't work if this kernel option is enabled. +#ifndef CONFIG_ARCH_DMA_ADDR_T_64BIT +/* Check if DMA address overflowed */ +if (min(addr, addr + size - 1) < +__phys_to_dma(dev, (phys_addr_t)(min_low_pfn << PAGE_SHIFT))) +return false; +#endif I will delete the lines with ifndef and endif and will try it again. Cheers, Christian -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 205201] Booting halts if Dawicontrol DC-2976 UW SCSI board installed, unless RAM size limited to 3500M
https://bugzilla.kernel.org/show_bug.cgi?id=205201 --- Comment #13 from Christian Zigotzky (chzigot...@xenosoft.de) --- Christoph, Now, I can definitely say that this patch does not solve the issue. Do you have another patch for testing or shall I bisect? Thanks, Christian -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 205201] Booting halts if Dawicontrol DC-2976 UW SCSI board installed, unless RAM size limited to 3500M
https://bugzilla.kernel.org/show_bug.cgi?id=205201 --- Comment #14 from Christian Zigotzky (chzigot...@xenosoft.de) --- Created attachment 285889 --> https://bugzilla.kernel.org/attachment.cgi?id=285889&action=edit Patch for renaming the GFP_DMA32 to GFP_DMA Hi All, The issue with the BT878 TV cards is solved. :-) GFP_DMA32 was renamed to GFP_DMA in the PowerPC updates 4.21-1 in December last year. Some PCI devices still use GFP_DMA32 (grep -r GFP_DMA32 *). I renamed GFP_DMA32 to GFP_DMA in the file "drivers/media/v4l2-core/videobuf-dma-sg.c". After compiling the RC7 of kernel 5.4, my BT878 TV card works again. I created a patch for renaming GFP_DMA32 to GFP_DMA. This patch doesn't solve the issue with the Dawicontrol DC-2976 UW SCSI board. Please help us to solve the issue with the SCSI board too. Cheers, Christian -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 205201] Booting halts if Dawicontrol DC-2976 UW SCSI board installed, unless RAM size limited to 3500M
https://bugzilla.kernel.org/show_bug.cgi?id=205201 --- Comment #15 from Christian Zigotzky (chzigot...@xenosoft.de) --- FYI: Souce files of the Dawicontrol DC 2976 UW SCSI board (PCI): https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/scsi/sym53c8xx_2?h=v5.4-rc7 /* * DMA addressing mode. * * 0 : 32 bit addressing for all chips. * 1 : 40 bit addressing when supported by chip. * 2 : 64 bit addressing when supported by chip, * limited to 16 segments of 4 GB -> 64 GB max. */ #define SYM_CONF_DMA_ADDRESSING_MODE CONFIG_SCSI_SYM53C8XX_DMA_ADDRESSING_MODE Cyrus config: CONFIG_SCSI_SYM53C8XX_DMA_ADDRESSING_MODE=1 I will configure “0 : 32 bit addressing for all chips” for the RC8. Maybe this is the solution. -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 205183] PPC64: Signal delivery fails with SIGSEGV if between about 1KB and 4KB bytes of stack remain
https://bugzilla.kernel.org/show_bug.cgi?id=205183 Daniel Black (dan...@linux.ibm.com) changed: What|Removed |Added CC||dan...@linux.ibm.com --- Comment #1 from Daniel Black (dan...@linux.ibm.com) --- Tom, Thanks for the bug report. Appreciate it. Feel free to use the linuxppc-dev@lists.ozlabs.org list. Reproduced in 5.4.0-rc8 danielgb@talos2:~$ uname -a Linux talos2 5.4.0-rc8 #5 SMP Mon Nov 18 13:27:11 AEDT 2019 ppc64le ppc64le ppc64le GNU/Linux danielgb@talos2:~$ gcc -g -Wall -O stacktest.c danielgb@talos2:~$ ./a.out 124 & [1] 2944 danielgb@talos2:~$ cat /proc/$(pidof a.out)/maps | grep stack 7fffc62f-7fffc642 rw-p 00:00 0 [stack] danielgb@talos2:~$ kill -USR1 %1 danielgb@talos2:~$ signal delivered, stack base 0x7fffc642 top 0x7fffc62f1427 (1240025 used) [1]+ Done./a.out 124 danielgb@talos2:~$ ./a.out 1241000 & [1] 2948 danielgb@talos2:~$ kill -USR1 %1 danielgb@talos2:~$ [1]+ Segmentation fault ./a.out 1241000 [ 6415.077590] a.out[2948]: bad frame in setup_rt_frame: 7fffe4fb0010 nip 06a185d909fc lr 77ecda3c04e8 I'll get someone to look at this soon. -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 205327] kmemleak reports various leaks in "swapper/0"
https://bugzilla.kernel.org/show_bug.cgi?id=205327 --- Comment #5 from Erhard F. (erhar...@mailbox.org) --- (In reply to Michael Ellerman from comment #3) > Do you want to send a patch? I already sent the patch to linuxppc-dev@lists.ozlabs.org (https://patchwork.ozlabs.org/patch/1195212/) but don't know how to proceed further to get this patch into stable, etc. -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 205327] kmemleak reports various leaks in "swapper/0"
https://bugzilla.kernel.org/show_bug.cgi?id=205327 --- Comment #6 from Michael Ellerman (mich...@ellerman.id.au) --- I replied with directions on what to do. -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 205201] Booting halts if Dawicontrol DC-2976 UW SCSI board installed, unless RAM size limited to 3500M
https://bugzilla.kernel.org/show_bug.cgi?id=205201 --- Comment #16 from Christian Zigotzky (chzigot...@xenosoft.de) --- Created attachment 286031 --> https://bugzilla.kernel.org/attachment.cgi?id=286031&action=edit dmesg of Christoph's Git kernel Christoph Hellwig wrote: I think we have two sorta overlapping issues here. One is that I think we need the bus_dma_limit, which should mostly help for something like a SCSI controller that doesn't need streaming mappings (btw, do we have more details on that somewhere?). And something weird with the videobuf things. Your change of the dma masks suggests that the driver doesn't do the right allocations and thus hits bounce buffering (swiotlb). We should fix that for real, but the fact that the bounce buffering itself also fails is even more interesting. Can you try this git branch: git://git.infradead.org/users/hch/misc.git fsl-dma-debugging Gitweb: http://git.infradead.org/users/hch/misc.git/shortlog/refs/heads/fsl-dma-debugging and send me the dmesg with that with your TV adapter? - Hello Christoph, Here is the dmesg of your Git kernel. Thanks, Christian -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 207129] PowerMac G4 DP (5.6.2 debug kernel + inline KASAN) freezes shortly after booting with "do_IRQ: stack overflow: 1760"
https://bugzilla.kernel.org/show_bug.cgi?id=207129 --- Comment #4 from Erhard F. (erhar...@mailbox.org) --- Without CONFIG_VMAP_STACK I had one crash after 2-3 hours of building but the panic timer kicked in and rebooted the machine. Now it has been building packages for hours again without any anomalies. -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 207129] PowerMac G4 DP (5.6.2 debug kernel + inline KASAN) freezes shortly after booting with "do_IRQ: stack overflow: 1760"
https://bugzilla.kernel.org/show_bug.cgi?id=207129 --- Comment #5 from Christophe Leroy (christophe.le...@c-s.fr) --- Ok, so as a summary: - With CONFIG_THREAD_SHIFT = 13 and CONFIG_DEBUG_STACKOVERFLOW, the system gets stuck - With CONFIG_THREAD_SHIFT = 13 and without CONFIG_DEBUG_STACKOVERFLOW, stack overflow is not really detected until it gets into kernel text !!! - With CONFIG_THREAD_SHIFT = 14 it runs fine - With CONFIG_VMAP_STACK, the automatic restart doesn't work - Without CONFIG_VMAP_STACK, the automatic restart works So I'll send a patch to set CONFIG_THREAD_SHIFT to 14 when CONFIG_KASAN is selected. x86 and arm64 already do that. And I'll try to investigate the other points when I have time. -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 207129] PowerMac G4 DP (5.6.2 debug kernel + inline KASAN) freezes shortly after booting with "do_IRQ: stack overflow: 1760"
https://bugzilla.kernel.org/show_bug.cgi?id=207129 --- Comment #6 from Erhard F. (erhar...@mailbox.org) --- Yes, precisely summarized! Thanks for your efforts! CONFIG_KASAN though only is x86_64 not x86 AFAIK. -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 205099] KASAN hit at raid6_pq: BUG: Unable to handle kernel data access at 0x00f0fd0d
https://bugzilla.kernel.org/show_bug.cgi?id=205099 Erhard F. (erhar...@mailbox.org) changed: What|Removed |Added Attachment #287621|0 |1 is obsolete|| --- Comment #28 from Erhard F. (erhar...@mailbox.org) --- Created attachment 288411 --> https://bugzilla.kernel.org/attachment.cgi?id=288411&action=edit dmesg (5.7-rc1, OUTLINE KASAN, PowerMac G4 DP) Re-tested with v5.7-rc1 out of curiosity. Not much change here, the bug shows up with OUTLINE KASAN but not with INLINE KASAN, everything else being equal. [...] Apr 13 16:01:11 T600 kernel: BUG: Unable to handle kernel data access on read at 0x0050a0f0 Apr 13 16:01:11 T600 kernel: Faulting instruction address: 0xf1aa1564 Apr 13 16:01:11 T600 kernel: Oops: Kernel access of bad area, sig: 11 [#1] Apr 13 16:01:11 T600 kernel: BE PAGE_SIZE=4K MMU=Hash SMP NR_CPUS=2 PowerMac Apr 13 16:01:11 T600 kernel: Modules linked in: raid6_pq(+) zlib_inflate firewire_ohci firewire_core ehci_pci(+) ohci_hcd crc_itu_t sr_mod cdrom ehci_hcd snd_aoa_i2sbus snd_aoa_soundbus snd_pcm snd_timer snd ss> Apr 13 16:01:11 T600 kernel: CPU: 0 PID: 149 Comm: modprobe Tainted: GW 5.7.0-rc1-PowerMacG4+ #1 Apr 13 16:01:11 T600 kernel: NIP: f1aa1564 LR: f1aa14e8 CTR: c0255b78 Apr 13 16:01:11 T600 kernel: REGS: f1963780 TRAP: 0300 Tainted: GW (5.7.0-rc1-PowerMacG4+) Apr 13 16:01:11 T600 kernel: MSR: 02009032 CR: 28228828 XER: Apr 13 16:01:11 T600 kernel: DAR: 0050a0f0 DSISR: 4000 GPR00: f19639d8 f1963838 ebd1de60 eb1dc070 1000 0003 f1aa14e8 GPR08: 0050a0f0 5d0dfdad fff0 c0255b78 00a48ff4 0060 0050 GPR16: eb1dc000 eb1df000 eb1de000 0070 0060 0050 0040 0030 GPR24: 0020 0010 0008 f1963a8c f1963a78 eb1df010 eb1de010 Apr 13 16:01:11 T600 kernel: NIP [f1aa1564] raid6_altivec8_gen_syndrome_real+0x3c4/0x480 [raid6_pq] Apr 13 16:01:11 T600 kernel: LR [f1aa14e8] raid6_altivec8_gen_syndrome_real+0x348/0x480 [raid6_pq] Apr 13 16:01:11 T600 kernel: Call Trace: Apr 13 16:01:11 T600 kernel: [f1963838] [000a] 0xa (unreliable) Apr 13 16:01:11 T600 kernel: [f1963a28] [f1aa1654] raid6_altivec8_gen_syndrome+0x34/0x58 [raid6_pq] Apr 13 16:01:11 T600 kernel: [f1963a48] [f12603cc] init_module+0x3cc/0x530 [raid6_pq] Apr 13 16:01:11 T600 kernel: [f1963b18] [c00058e4] do_one_initcall+0xb8/0x36c Apr 13 16:01:11 T600 kernel: [f1963be8] [c0117f64] do_init_module+0xa8/0x2c4 Apr 13 16:01:11 T600 kernel: [f1963c18] [c011ae38] load_module+0x2bd8/0x2d5c Apr 13 16:01:11 T600 kernel: [f1963e18] [c011b230] sys_finit_module+0x100/0x138 Apr 13 16:01:11 T600 kernel: [f1963f38] [c001a224] ret_from_syscall+0x0/0x34 Apr 13 16:01:11 T600 kernel: --- interrupt: c01 at 0x892988 LR = 0xa20a14 Apr 13 16:01:11 T600 kernel: Instruction dump: Apr 13 16:01:11 T600 kernel: 1304c4c4 7d2048ce 39210090 1325ccc4 7d6048ce 1346d4c4 81210088 1367dcc4 Apr 13 16:01:11 T600 kernel: 8141008c 11284cc4 115f5b06 116b5800 <7c0048ce> 392100a0 7d8048ce 392100b0 Apr 13 16:01:11 T600 kernel: ---[ end trace ebe3b589d509d4f6 ]--- [...] -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 205099] KASAN hit at raid6_pq: BUG: Unable to handle kernel data access at 0x00f0fd0d
https://bugzilla.kernel.org/show_bug.cgi?id=205099 Erhard F. (erhar...@mailbox.org) changed: What|Removed |Added Attachment #287623|0 |1 is obsolete|| --- Comment #29 from Erhard F. (erhar...@mailbox.org) --- Created attachment 288413 --> https://bugzilla.kernel.org/attachment.cgi?id=288413&action=edit kernel .config (5.7-rc1, OUTLINE KASAN, PowerMac G4 DP) -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 206203] kmemleak reports various leaks in drivers/of/unittest.c
https://bugzilla.kernel.org/show_bug.cgi?id=206203 --- Comment #11 from Erhard F. (erhar...@mailbox.org) --- Created attachment 288565 --> https://bugzilla.kernel.org/attachment.cgi?id=288565&action=edit kmemleak output (kernel 5.7-rc1, PowerMac G5 11,2) Applied Frank's patch set on top of 5.7-rc1. Though there are certainly less memory leaks now, there are still some OF ones reported. Frank Rowand (5): of: unittest: kmemleak on changeset destroy of: unittest: kmemleak in of_unittest_platform_populate() of: unittest: kmemleak in of_unittest_overlay_high_level() of: overlay: kmemleak in dup_and_fixup_symbol_prop() of: unittest: kmemleak in duplicate property update -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 206203] kmemleak reports various leaks in drivers/of/unittest.c
https://bugzilla.kernel.org/show_bug.cgi?id=206203 --- Comment #12 from Erhard F. (erhar...@mailbox.org) --- Created attachment 288567 --> https://bugzilla.kernel.org/attachment.cgi?id=288567&action=edit dmesg (kernel 5.7-rc1, PowerMac G5 11,2) -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 207359] New: MegaRAID SAS 9361 controller hang/reset
https://bugzilla.kernel.org/show_bug.cgi?id=207359 Bug ID: 207359 Summary: MegaRAID SAS 9361 controller hang/reset Product: Platform Specific/Hardware Version: 2.5 Kernel Version: >=v5.4 Hardware: PPC-64 OS: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: PPC-64 Assignee: platform_ppc...@kernel-bugs.osdl.org Reporter: c...@neo-zeon.de Regression: No Created attachment 288623 --> https://bugzilla.kernel.org/attachment.cgi?id=288623&action=edit dmesg output for controller hang On a Talos II 2x 36 core (144 thread) POWER9 box, MegaRAID SAS 9361-16i PCIE controller can be made to pretty consistently hang with "heavy IO" on kernel versions greater than 5.3.18. I am unable to reproduce this on a 16/32 core/thread amd64 box with a MegaRAID SAS 9361-16i PCIE with the exact same firmware revision. The box also has a Microsemi SAS HBA which seems unaffected by this. System details: Talos II motherboard 2x 36 core (144 thread) POWER9 processors 512GB memory 4k page size MegaRAID SAS 9361-16i PCIE controller (4 disk RAID10 volume, megaraid_sas driver) Microsemi HBA w/4x SSD's The relevant dmesg messages are attached. -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 207359] MegaRAID SAS 9361 controller hang/reset
https://bugzilla.kernel.org/show_bug.cgi?id=207359 gyakov...@gentoo.org changed: What|Removed |Added CC||gyakov...@gentoo.org --- Comment #1 from gyakov...@gentoo.org --- In my case I see similar problem on same motherboard but with aacraid driver (microsemi one) https://bugzilla.kernel.org/show_bug.cgi?id=206123 -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 207359] MegaRAID SAS 9361 controller hang/reset
https://bugzilla.kernel.org/show_bug.cgi?id=207359 --- Comment #2 from Cameron (c...@neo-zeon.de) --- Looking at bug 206123 above, it's worth noting that the amd64 box I'm using for comparison has SATA disks, though this is probably still a PPC specific issue. -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 199471] [Bisected][Regression] windfarm_pm* no longer gets automatically loaded when CONFIG_I2C_POWERMAC=y is set
https://bugzilla.kernel.org/show_bug.cgi?id=199471 --- Comment #20 from Dennis Clarke (dcla...@blastwave.org) --- Possibly unrelated but there appears to be a small memory leak within windfarm_* somewhere given that I see traffic in kmemleak : enceladus# enceladus# uname -a Linux enceladus 5.7.0-rc2 #1 SMP Tue Apr 21 23:32:43 UTC 2020 ppc64 GNU/Linux enceladus# lsmod | grep 'farm' windfarm_cpufreq_clamp 4640 1 windfarm_smu_sensors 9548 1 windfarm_smu_controls 9078 8 windfarm_pm112 15935 0 windfarm_pid4378 1 windfarm_pm112 windfarm_smu_sat9802 9 windfarm_pm112 windfarm_max6690_sensor 5434 1 windfarm_lm75_sensor 6148 1 windfarm_core 16619 7 windfarm_cpufreq_clamp,windfarm_smu_controls,windfarm_max6690_sensor,windfarm_smu_sat,windfarm_smu_sensors,windfarm_lm75_sensor,windfarm_pm112 enceladus# enceladus# cat /sys/kernel/debug/kmemleak unreferenced object 0xc867a6a0 (size 32): comm "kwindfarm", pid 175, jiffies 4294894706 (age 1843.540s) hex dump (first 32 bytes): c8 06 02 7f ff 02 ff 01 fb bf 00 59 00 20 00 00 ...Y. .. 00 07 89 37 00 a0 00 00 6b 6b 6b 6b 6b 6b 6b a5 ...7kkk. backtrace: [] .smu_sat_get_sdb_partition+0x150/0x2f0 [windfarm_smu_sat] [ ] .pm112_wf_notify+0x624/0x1460 [windfarm_pm112] [<8cdab940>] .notifier_call_chain+0x88/0xf0 [<8f026422>] .__blocking_notifier_call_chain+0x6c/0xc0 [<45480c67>] .wf_thread_func+0xe4/0x1e0 [windfarm_core] [<79c8bd6f>] .kthread+0x1b8/0x1d0 [<73e2b812>] .ret_from_kernel_thread+0x58/0x74 unreferenced object 0xc002612a15a0 (size 16): comm "kwindfarm", pid 175, jiffies 4294894926 (age 1842.660s) hex dump (first 16 bytes): c4 04 01 7f a0 12 20 5f ff 55 b8 14 7b 12 00 00 .. _.U..{... backtrace: [ ] .smu_sat_get_sdb_partition+0x150/0x2f0 [windfarm_smu_sat] [<50e586af>] .pm112_wf_notify+0x66c/0x1460 [windfarm_pm112] [<8cdab940>] .notifier_call_chain+0x88/0xf0 [<8f026422>] .__blocking_notifier_call_chain+0x6c/0xc0 [<45480c67>] .wf_thread_func+0xe4/0x1e0 [windfarm_core] [<79c8bd6f>] .kthread+0x1b8/0x1d0 [<73e2b812>] .ret_from_kernel_thread+0x58/0x74 unreferenced object 0xc867ba20 (size 32): comm "kwindfarm", pid 175, jiffies 4294895089 (age 1842.008s) hex dump (first 32 bytes): c9 06 02 7f ff 02 ff 01 fb bf 00 59 00 20 00 00 ...Y. .. 00 07 89 37 00 a0 00 00 6b 6b 6b 6b 6b 6b 6b a5 ...7kkk. backtrace: [ ] .smu_sat_get_sdb_partition+0x150/0x2f0 [windfarm_smu_sat] [ ] .pm112_wf_notify+0x624/0x1460 [windfarm_pm112] [<8cdab940>] .notifier_call_chain+0x88/0xf0 [<8f026422>] .__blocking_notifier_call_chain+0x6c/0xc0 [<45480c67>] .wf_thread_func+0xe4/0x1e0 [windfarm_core] [<79c8bd6f>] .kthread+0x1b8/0x1d0 [<73e2b812>] .ret_from_kernel_thread+0x58/0x74 unreferenced object 0xc61a8740 (size 16): comm "kwindfarm", pid 175, jiffies 4294895309 (age 1841.128s) hex dump (first 16 bytes): c5 04 01 7f a0 12 20 5f ff 55 29 14 7b 12 00 00 .. _.U).{... backtrace: [ ] .smu_sat_get_sdb_partition+0x150/0x2f0 [windfarm_smu_sat] [<50e586af>] .pm112_wf_notify+0x66c/0x1460 [windfarm_pm112] [<8cdab940>] .notifier_call_chain+0x88/0xf0 [<8f026422>] .__blocking_notifier_call_chain+0x6c/0xc0 [<45480c67>] .wf_thread_func+0xe4/0x1e0 [windfarm_core] [<79c8bd6f>] .kthread+0x1b8/0x1d0 [<73e2b812>] .ret_from_kernel_thread+0x58/0x74 unreferenced object 0xc61ab6e0 (size 32): comm "kwindfarm", pid 175, jiffies 4294895473 (age 1840.472s) hex dump (first 32 bytes): c8 06 02 7f ff 02 ff 01 fb bf 00 59 00 20 00 00 ...Y. .. 00 07 89 37 00 a0 00 00 6b 6b 6b 6b 6b 6b 6b a5 ...7kkk. backtrace: [ ] .smu_sat_get_sdb_partition+0x150/0x2f0 [windfarm_smu_sat] [ ] .pm112_wf_notify+0x624/0x1460 [windfarm_pm112] [<8cdab940>] .notifier_call_chain+0x88/0xf0 [<8f026422>] .__blocking_notifier_call_chain+0x6c/0xc0 [<45480c67>] .wf_thread_func+0xe4/0x1e0 [windfarm_core] [<79c8bd6f>] .kthread+0x1b8/0x1d0 [<73e2b812>] .ret_from_kernel_thread+0x58/0x74 unreferenced object 0xc61a8b90 (size 16): comm "kwindfarm", pid 175, jiffies 4294895693 (age 1839.600s) hex dump (first 16 bytes): c4 04 01 7f a0 12 20 5f ff 55 b8 14 7b 12 00 00 .. _.U..{... backtrace: [ ] .smu_sat_get_sdb_partition+0x150/0x2f0 [windfarm_smu_sat] [<50e586af>] .pm112_wf_notify+0x66c/0x1460 [windfarm_pm112] [<8cdab940>] .notifier_call_chain+0x88/0xf0 [<8f026422>] .__blocking_notifier_c
[Bug 199471] [Bisected][Regression] windfarm_pm* no longer gets automatically loaded when CONFIG_I2C_POWERMAC=y is set
https://bugzilla.kernel.org/show_bug.cgi?id=199471 --- Comment #21 from Erhard F. (erhar...@mailbox.org) --- (In reply to Dennis Clarke from comment #20) > > Possibly unrelated but there appears to be a small memory leak within > windfarm_* somewhere given that I see traffic in kmemleak : > > [...] > > I will take a look into it and see what I can see. Thanks, but probably there's no need to. ;) There is already a patch floating around in the bug where I reported the memleak originally: https://bugzilla.kernel.org/show_bug.cgi?id=206695 The patch just didn't went upstream yet. -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 199471] [Bisected][Regression] windfarm_pm* no longer gets automatically loaded when CONFIG_I2C_POWERMAC=y is set
https://bugzilla.kernel.org/show_bug.cgi?id=199471 Wolfram Sang (w...@the-dreams.de) changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |CODE_FIX --- Comment #22 from Wolfram Sang (w...@the-dreams.de) --- Fixed upstream with commit bcf3588d8ed3517e6ffaf083f034812aee9dc8e2. -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 206695] kmemleak reports leaks in drivers/macintosh/windfarm
https://bugzilla.kernel.org/show_bug.cgi?id=206695 Michael Ellerman (mich...@ellerman.id.au) changed: What|Removed |Added Status|NEW |ASSIGNED CC||mich...@ellerman.id.au -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 206695] kmemleak reports leaks in drivers/macintosh/windfarm
https://bugzilla.kernel.org/show_bug.cgi?id=206695 Michael Ellerman (mich...@ellerman.id.au) changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |CODE_FIX --- Comment #7 from Michael Ellerman (mich...@ellerman.id.au) --- Patch posted: https://patchwork.ozlabs.org/project/linuxppc-dev/patch/20200423060038.3308530-1-...@ellerman.id.au/ -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 206695] kmemleak reports leaks in drivers/macintosh/windfarm
https://bugzilla.kernel.org/show_bug.cgi?id=206695 Dennis Clarke (dcla...@blastwave.org) changed: What|Removed |Added CC||dcla...@blastwave.org --- Comment #8 from Dennis Clarke (dcla...@blastwave.org) --- 123456789+123456789+123456789+123456789+123456789+123456789+123456789+ I will apply the patch and try with Linux 5.7-rc2 and post any results seen. Also this does close off : https://bugzilla.kernel.org/show_bug.cgi?id=199471 I see Wolfram Sang has commented there. OKay ... good stuff. Dennis Clarke -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 199471] [Bisected][Regression] windfarm_pm* no longer gets automatically loaded when CONFIG_I2C_POWERMAC=y is set
https://bugzilla.kernel.org/show_bug.cgi?id=199471 --- Comment #23 from Michael Ellerman (mich...@ellerman.id.au) --- The memory leak is a separate issue, see bug #206695. Can anyone verify that bcf3588d8ed fixes the original issue? -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 199471] [Bisected][Regression] windfarm_pm* no longer gets automatically loaded when CONFIG_I2C_POWERMAC=y is set
https://bugzilla.kernel.org/show_bug.cgi?id=199471 --- Comment #24 from Wolfram Sang (w...@the-dreams.de) --- @Michael: commit bcf3588d8ed has the following tags: Reported-by: Erhard Furtner Tested-by: Erhard Furtner And Erhard is also the one who created this bug entry. -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 199471] [Bisected][Regression] windfarm_pm* no longer gets automatically loaded when CONFIG_I2C_POWERMAC=y is set
https://bugzilla.kernel.org/show_bug.cgi?id=199471 --- Comment #25 from Erhard F. (erhar...@mailbox.org) --- (In reply to Michael Ellerman from comment #23) > The memory leak is a separate issue, see bug #206695. > > Can anyone verify that bcf3588d8ed fixes the original issue? Yes, thanks to Wolframs patch the WINDFARM_PM112 is automatically loaded again when built as a module. So my original issue is fixed with that commit. -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 206695] kmemleak reports leaks in drivers/macintosh/windfarm
https://bugzilla.kernel.org/show_bug.cgi?id=206695 --- Comment #9 from Dennis Clarke (dcla...@blastwave.org) --- I see this has not gone upstream to 5.7-rc3 and thus I am applying it manually and building now. Shall report on the kmem leak shortly. I hope. Dennis -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 199471] [Bisected][Regression] windfarm_pm* no longer gets automatically loaded when CONFIG_I2C_POWERMAC=y is set
https://bugzilla.kernel.org/show_bug.cgi?id=199471 Michael Ellerman (mich...@ellerman.id.au) changed: What|Removed |Added Status|RESOLVED|VERIFIED --- Comment #26 from Michael Ellerman (mich...@ellerman.id.au) --- OK thanks all. -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 199471] [Bisected][Regression] windfarm_pm* no longer gets automatically loaded when CONFIG_I2C_POWERMAC=y is set
https://bugzilla.kernel.org/show_bug.cgi?id=199471 Michael Ellerman (mich...@ellerman.id.au) changed: What|Removed |Added Status|VERIFIED|CLOSED -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 104871] bcl+8 in arch/powerpc/kernel/vdso64/datapage.S causes branch prediction issues
https://bugzilla.kernel.org/show_bug.cgi?id=104871
Michael Ellerman (mich...@ellerman.id.au) changed:
What|Removed |Added
Status|NEW |RESOLVED
CC||mich...@ellerman.id.au
Resolution|--- |CODE_FIX
--- Comment #2 from Michael Ellerman (mich...@ellerman.id.au) ---
Fixed in:
c974809a26a1 ("powerpc/vdso: Avoid link stack corruption in __get_datapage()")
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=c974809a26a13e40254dbe3cf46f49aa32acca11
--
You are receiving this mail because:
You are watching the assignee of the bug.
[Bug 104871] bcl+8 in arch/powerpc/kernel/vdso64/datapage.S causes branch prediction issues
https://bugzilla.kernel.org/show_bug.cgi?id=104871 Michael Ellerman (mich...@ellerman.id.au) changed: What|Removed |Added Status|RESOLVED|CLOSED -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 207359] MegaRAID SAS 9361 controller hang/reset
https://bugzilla.kernel.org/show_bug.cgi?id=207359 --- Comment #3 from Cameron (c...@neo-zeon.de) --- Created attachment 289041 --> https://bugzilla.kernel.org/attachment.cgi?id=289041&action=edit 5.6.11 megaraid POWER hang Still happens with 5.6.11. There seems to be potentially a bit more output this time, and I've included output from shutting down too in case it's useful. -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 203839] Kernel 5.2-rc3 fails to boot on a PowerMac G4 3,6: systemd[1]: Failed to bump fs.file-max, ignoring: invalid argument
https://bugzilla.kernel.org/show_bug.cgi?id=203839 Erhard F. (erhar...@mailbox.org) changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |CODE_FIX --- Comment #10 from Erhard F. (erhar...@mailbox.org) --- The fix meanwhile found it's way in kernel 5.2-rc7 which boots just fine. Thanks! -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 203839] Kernel 5.2-rc3 fails to boot on a PowerMac G4 3,6: systemd[1]: Failed to bump fs.file-max, ignoring: invalid argument
https://bugzilla.kernel.org/show_bug.cgi?id=203839
Michael Ellerman (mich...@ellerman.id.au) changed:
What|Removed |Added
Status|RESOLVED|CLOSED
CC||mich...@ellerman.id.au
--- Comment #11 from Michael Ellerman (mich...@ellerman.id.au) ---
Fixed in b7f8b440f300 ("powerpc/32s: fix initial setup of segment registers on
secondary CPU")
--
You are receiving this mail because:
You are watching the assignee of the bug.
