[Bug 209733] Starting new KVM virtual machines on PPC64 starts to hang after box is up for a while

2020-10-18 Thread bugzilla-daemon
https://bugzilla.kernel.org/show_bug.cgi?id=209733

Cameron (c...@neo-zeon.de) changed:

   What|Removed |Added

  Component|PPC-64  |kvm
Version|2.5 |unspecified
Product|Platform Specific/Hardware  |Virtualization

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 209733] New: Starting new KVM virtual machines on PPC64 starts to hang after box is up for a while

2020-10-18 Thread bugzilla-daemon
https://bugzilla.kernel.org/show_bug.cgi?id=209733

Bug ID: 209733
   Summary: Starting new KVM virtual machines on PPC64 starts to
hang after box is up for a while
   Product: Platform Specific/Hardware
   Version: 2.5
Kernel Version: >=5.8
  Hardware: PPC-64
OS: Linux
  Tree: Mainline
Status: NEW
  Severity: high
  Priority: P1
 Component: PPC-64
  Assignee: platform_ppc...@kernel-bugs.osdl.org
  Reporter: c...@neo-zeon.de
Regression: No

Issue occurs with 5.8.14, 5.8.16, and 5.9.1.  Does NOT occur with 5.7.x. I
suspect it occurs with all of 5.8, but I haven't confirmed this yet.

After the box has been up for a "while", starting new VM's fails. Completely
shutting down existing VM's and then starting them back up will also fail in
the same way.

What is a while? Could be 2 days, might be 9. I'll update as the pattern
becomes more clear.

libvirt is generally used, but when running kvm manually with strace, kvm
always gets stuck here:
ioctl(11, KVM_PPC_ALLOCATE_HTAB, 0x7fffea0bade4

Maybe the kernel is trying to find the memory needed to allocate the Hashed
Page Table but is unable to do so? Maybe there's a memory leak?

Before this issue starts occurring, I have confirmed I am able to run the exact
same kvm command manually:
sudo -u libvirt-qemu qemu-system-ppc64 -enable-kvm -m 8192 -nographic -vga none
-drive file=/var/lib/libvirt/images/test.qcow2,format=qcow2 -mem-prealloc -smp
4

Nothing in dmesg, nothing useful in the logs.

This box's configuration:
Debian 10 stable
2x 18 core POWER9 (144 threads)
512g physical memory
Raptor Talos II motherboard
radix MMU disabled

Unfortunately, I cannot test the affected box with the Radix MMU enabled
because I have some important VM's that won't run unless it is disabled.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 195755] rcu_sched detected stalls on CPUs/tasks: (detected by 0, t=6302 jiffies, g=11405, c=11404, q=1880), ppc64, G5

2020-10-15 Thread bugzilla-daemon
https://bugzilla.kernel.org/show_bug.cgi?id=195755

Marco Descher (ma...@descher.at) changed:

   What|Removed |Added

 CC||ma...@descher.at

--- Comment #30 from Marco Descher (ma...@descher.at) ---
I experienced this problem today, a freeze on an 

processor   : 3
vendor_id   : AuthenticAMD
cpu family  : 22
model   : 48
model name  : AMD GX-412TC SOC

on Debian 10  4.19.0-11-amd64 #1 SMP Debian 4.19.146-1 (2020-09-17) x86_64
GNU/Linux

with more and more sysrq messages coming up resulting in the following syslog
entry

Oct 15 11:43:45 gate kernel: [1545118.045973] rcu: INFO: rcu_sched detected
stalls on CPUs/tasks:

leading to the system becoming unreachable. Only after a reboot this works
again.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 195755] rcu_sched detected stalls on CPUs/tasks: (detected by 0, t=6302 jiffies, g=11405, c=11404, q=1880), ppc64, G5

2020-09-24 Thread bugzilla-daemon
https://bugzilla.kernel.org/show_bug.cgi?id=195755

Nigel Reed (ni...@nigelreed.net) changed:

   What|Removed |Added

 CC||ni...@nigelreed.net

--- Comment #29 from Nigel Reed (ni...@nigelreed.net) ---
I know this is old but I have been having some issues for a while, I was
finally able to get something useful:

[165716.089703] rcu: INFO: rcu_sched detected stalls on CPUs/tasks:
[165716.095949] rcu:1-...!: (0 ticks this GP) idle=354/0/0x0
softirq=2154363/2154363 fqs=0
[165716.104512] rcu:3-...!: (0 ticks this GP) idle=29c/0/0x0
softirq=883832/883832 fqs=0
[165716.112873] rcu:4-...!: (8 GPs behind) idle=ad8/0/0x0
softirq=2165586/2165586 fqs=0
[165716.121179] rcu:9-...!: (9 GPs behind) idle=acc/0/0x0
softirq=1340600/1340600 fqs=0
[165716.129467] rcu:11-...!: (2 GPs behind) idle=a18/0/0x0
softirq=4538536/4538537 fqs=0
[165716.137828] rcu:12-...!: (0 ticks this GP) idle=870/0/0x0
softirq=2158040/2158040 fqs=0
[165775.697763] rcu: rcu_sched kthread starved for 29898 jiffies! g36134941
f0x0 RCU_GP_WAIT_FQS(5) ->state=0x402 ->cpu=3
[165775.709013] rcu: RCU grace-period kthread stack dump:
[165837.494623] watchdog: BUG: soft lockup - CPU#6 stuck for 23s!
[(resolved):52315]
[165865.494840] watchdog: BUG: soft lockup - CPU#6 stuck for 23s!
[(resolved):52315]

This happened just after freshclam ran but I don't know if it's related.

This is with a Ryzen 7 1800X CPU.
5.4.0-48-generic #52-Ubuntu

I thought I had sysrq configured but it seems not so I can't really provide any
more information, other than this is driving me crazy.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 209297] New: powerpc: MPC10X_BRIDGE violates Kconfig dependency of PPC_INDIRECT_PCI on PCI

2020-09-17 Thread bugzilla-daemon
https://bugzilla.kernel.org/show_bug.cgi?id=209297

Bug ID: 209297
   Summary: powerpc: MPC10X_BRIDGE violates Kconfig dependency of
PPC_INDIRECT_PCI on PCI
   Product: Platform Specific/Hardware
   Version: 2.5
Kernel Version: 5.9-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: fazilyildi...@gmail.com
CC: m...@ellerman.id.au, pau...@samba.org
Regression: No

The commit 25635c71e441 ("ppc: Use the indirect_pci.c from
arch/powerpc/sysdev")
introduced PPC_INDIRECT_PCI as a non-visible config that depends on PCI. 

Since it is non-visible, the dependency on PCI has no implications other
than leading to Kbuild build warnings if !PCI. For example, disabling PCI
and enabling LINKSTATION leads to the following Kbuild warning since
PPC_INDIRECT_PCI is selected by MPC10X_BRIDGE, which is selected by
LINKSTATION:

WARNING: unmet direct dependencies detected for PPC_INDIRECT_PCI
  Depends on [n]: PCI [=n]
  Selected by [y]:
  - MPC10X_BRIDGE [=y]

There are many other configs that select PPC_INDIRECT_PCI but they seem
to enable PCI one way or another, e.g., enabling FORCE_PCI or selecting
PPC_INDIRECT_PCI if PCI. Among them, only MPC10X_BRIDGE and MV64X60 seem
to not account for the dependency on PCI, and MV64X60 seem to be obsolete:
https://bugzilla.kernel.org/show_bug.cgi?id=209277

I am not sure about the internals of the user subsystem. However, two fix
options I see are: 1) --select FORCE_PCI-- by MPC10X_BRIDGE, 2) select
PPC_INDIRECT_PCI --if PCI-- by MPC10X_BRIDGE.

Thanks,
Necip

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 209277] powerpc: obsolete driver: Marvell MV64X60 MPSC

2020-09-15 Thread bugzilla-daemon
https://bugzilla.kernel.org/show_bug.cgi?id=209277

--- Comment #1 from Necip Fazil Yildiran (fazilyildi...@gmail.com) ---
The config MV64X60 in arch/powerpc/platforms/embedded6xx/Kconfig is 
non-prompt selected nowhere -- thus, cannot be enabled.

In addition, a few other configs cannot be enabled due to their dependency
on MV64X60, e.g., EDAC_MV64X60.

The last to use this driver was by PrPMC 280/2800, for which the support
was ended with the commit 3c8464a9b12b 
("powerpc: Delete old PrPMC 280/2800 support").

This looks like the related configs (e.g., MV64X60, EDAC_MV64X60) and the
code (e.g., drivers/edac/mv64x60_edac.c) for Marvell MV64X60 MPSC are now
obsolete.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 209277] New: Dead code :q

2020-09-15 Thread bugzilla-daemon
https://bugzilla.kernel.org/show_bug.cgi?id=209277

Bug ID: 209277
   Summary: Dead code :q
   Product: Platform Specific/Hardware
   Version: 2.5
Kernel Version: 5.9-rc4
  Hardware: All
OS: Linux
  Tree: Mainline
Status: NEW
  Severity: enhancement
  Priority: P1
 Component: PPC-32
  Assignee: platform_ppc...@kernel-bugs.osdl.org
  Reporter: fazilyildi...@gmail.com
Regression: No

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 209029] kernel 5.9-rc2 fails to boot on a PowerMac G5 11,2 - BUG: Kernel NULL pointer dereference on read at 0x00000020

2020-09-07 Thread bugzilla-daemon
https://bugzilla.kernel.org/show_bug.cgi?id=209029

Zorro Lang (zl...@redhat.com) changed:

   What|Removed |Added

 CC||zl...@redhat.com

--- Comment #5 from Zorro Lang (zl...@redhat.com) ---
*** Bug 209181 has been marked as a duplicate of this bug. ***

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 209181] kernel BUG at arch/powerpc/mm/pgtable.c:304!

2020-09-07 Thread bugzilla-daemon
https://bugzilla.kernel.org/show_bug.cgi?id=209181

Zorro Lang (zl...@redhat.com) changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #3 from Zorro Lang (zl...@redhat.com) ---


*** This bug has been marked as a duplicate of bug 209029 ***

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug 209181] kernel BUG at arch/powerpc/mm/pgtable.c:304!

2020-09-07 Thread bugzilla-daemon
https://bugzilla.kernel.org/show_bug.cgi?id=209181

--- Comment #2 from Zorro Lang (zl...@redhat.com) ---
(In reply to Christophe Leroy from comment #1)
> See https://bugzilla.kernel.org/show_bug.cgi?id=209029
> 
> Patch at
> https://patchwork.ozlabs.org/project/linuxppc-dev/patch/20200902040122.
> 136414-1-aneesh.ku...@linux.ibm.com/ to deactivate CONFIG_DEBUG_VM_PGTABLE
> on powerpc until the issue is fixes.

Thanks for this info

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug 209181] kernel BUG at arch/powerpc/mm/pgtable.c:304!

2020-09-06 Thread bugzilla-daemon
https://bugzilla.kernel.org/show_bug.cgi?id=209181

Christophe Leroy (christophe.le...@csgroup.eu) changed:

   What|Removed |Added

 CC||christophe.le...@csgroup.eu

--- Comment #1 from Christophe Leroy (christophe.le...@csgroup.eu) ---
See https://bugzilla.kernel.org/show_bug.cgi?id=209029

Patch at
https://patchwork.ozlabs.org/project/linuxppc-dev/patch/20200902040122.136414-1-aneesh.ku...@linux.ibm.com/
to deactivate CONFIG_DEBUG_VM_PGTABLE on powerpc until the issue is fixes.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug 209181] New: kernel BUG at arch/powerpc/mm/pgtable.c:304!

2020-09-06 Thread bugzilla-daemon
https://bugzilla.kernel.org/show_bug.cgi?id=209181

Bug ID: 209181
   Summary: kernel BUG at arch/powerpc/mm/pgtable.c:304!
   Product: Memory Management
   Version: 2.5
Kernel Version: Linux 5.9-rc4
  Hardware: All
OS: Linux
  Tree: Mainline
Status: NEW
  Severity: normal
  Priority: P1
 Component: Page Allocator
  Assignee: a...@linux-foundation.org
  Reporter: zl...@redhat.com
CC: linuxppc-dev@lists.ozlabs.org
Regression: No

Description of problem:
The latest upstream mainline kernel always panic on ppc64le machine (P9) as
below:

[1.406462] Loading compiled-in X.509 certificates 
[1.436966] Loaded X.509 cert 'Build time autogenerated kernel key:
834a47793f474746e698c2f3a32aa53ffded35db' 
[1.437154] zswap: loaded using pool lzo/zbud 
[1.437509] debug_vm_pgtable: [debug_vm_pgtable ]: Validating
architecture page table helpers 
[1.437571] [ cut here ] 
[1.437584] WARNING: CPU: 0 PID: 1 at arch/powerpc/mm/pgtable.c:185
set_pte_at+0xd8/0x1c0 
[1.437589] Modules linked in: 
[1.437596] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.9.0-rc4 #1 
[1.437602] NIP:  c009bb28 LR: c152e1c0 CTR:
 
[1.437608] REGS: c001fb6eb7b0 TRAP: 0700   Not tainted  (5.9.0-rc4) 
[1.437613] MSR:  82029033   CR: 24002824 
XER: 000a 
[1.437624] CFAR: c009ba74 IRQMASK: 0  
[1.437624] GPR00: c152e1c0 c001fb6eba40 c2138900
c000120f4100  
[1.437624] GPR04: 000b70171815 c000122400a8 05014e010080
  
[1.437624] GPR08: 0080 07c0 05c0
0001  
[1.437624] GPR12: 2000 c405 
c1569d38  
[1.437624] GPR16: c0001221 f0ff c001fb52f8a0
c2231cb8  
[1.437624] GPR20: c10d8de0 c100 c0001220b2e8
c000122f8000  
[1.437624] GPR24: 0100 014e c000122f8028
8105  
[1.437624] GPR28: 000b70171815 c000122118c0 c000120f4100
c000122400a8  
[1.437668] NIP [c009bb28] set_pte_at+0xd8/0x1c0 
[1.437674] LR [c152e1c0] debug_vm_pgtable+0x8f4/0x1e14 
[1.437679] Call Trace: 
[1.437685] [c001fb6eba40] [c1082f48] _raw_spin_lock+0x88/0x100
(unreliable) 
[1.437693] [c001fb6eba80] [c152dfd4]
debug_vm_pgtable+0x708/0x1e14 
[1.437700] [c001fb6ebb90] [c001208c] do_one_initcall+0xbc/0x5f0 
[1.437707] [c001fb6ebc80] [c14e4d04]
kernel_init_freeable+0x4bc/0x58c 
[1.437714] [c001fb6ebdb0] [c0012de8] kernel_init+0x2c/0x164 
[1.437721] [c001fb6ebe20] [c000d5d0]
ret_from_kernel_thread+0x5c/0x6c 
[1.437726] Instruction dump: 
[1.437731] 41820068 e8010050 ebc10030 7c0803a6 4b8c 4b88 3d200700
792907c6  
[1.437741] 612900c0 7d4a4838 2faa00c0 419eff54 <0fe0> 4b4c 3fe0bfef
63ff  
[1.437751] irq event stamp: 275292 
[1.437757] hardirqs last  enabled at (275291): []
inc_zone_page_state+0xa0/0xd0 
[1.437764] hardirqs last disabled at (275292): []
program_check_common_virt+0x2bc/0x310 
[1.437771] softirqs last  enabled at (273036): []
inet6_register_protosw+0x154/0x2a0 
[1.437778] softirqs last disabled at (273034): []
inet6_register_protosw+0x44/0x2a0 
[1.437784] ---[ end trace 39aeb34808a575d2 ]--- 
[1.437790] [ cut here ] 
[1.437795] kernel BUG at arch/powerpc/mm/pgtable.c:304! 
[1.437801] Oops: Exception in kernel mode, sig: 5 [#1] 
[1.437805] LE PAGE_SIZE=64K MMU=Hash SMP NR_CPUS=2048 NUMA pSeries 
[1.437807] Modules linked in: 
[1.437811] CPU: 0 PID: 1 Comm: swapper/0 Tainted: GW
5.9.0-rc4 #1 
[1.437815] NIP:  c009c1a8 LR: c05f9de0 CTR:
 
[1.437819] REGS: c001fb6eb720 TRAP: 0700   Tainted: GW 
(5.9.0-rc4) 
[1.437822] MSR:  82029033   CR: 24002828 
XER: 000a 
[1.437829] CFAR: c009c148 IRQMASK: 0  
[1.437829] GPR00: c05f9de0 c001fb6eb9b0 c2138900
c000120f4100  
[1.437829] GPR04: 000b70171815 c000122400a8 122f8000
00802f12  
[1.437829] GPR08:  0001 0028
0001  
[1.437829] GPR12: 2000 c405 
c1569d38  
[1.437829] GPR16: c0001221 f0ff c001fb52f8a0
c2231cb8  
[1.437829] GPR20: c10d8de0 c100 c0001220b2e8
c000122f8000  
[1.437829] GPR24: 0100 0008 c2231ca8
000a  
[1.437829] GPR28: c2231cb8 c2231cb0 000b70171815

[Bug 208181] BUG: KASAN: stack-out-of-bounds in strcmp+0x58/0xd8

2020-09-04 Thread bugzilla-daemon
https://bugzilla.kernel.org/show_bug.cgi?id=208181

Erhard F. (erhar...@mailbox.org) changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |OBSOLETE

--- Comment #19 from Erhard F. (erhar...@mailbox.org) ---
I noticed that I covered the "do_IRQ: stack overflow: " problem already in
bug #207129 so closing this one as suggested before.

-- 
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

2020-09-04 Thread bugzilla-daemon
https://bugzilla.kernel.org/show_bug.cgi?id=205099

Erhard F. (erhar...@mailbox.org) changed:

   What|Removed |Added

 Attachment #288413|0   |1
is obsolete||

--- Comment #31 from Erhard F. (erhar...@mailbox.org) ---
Created attachment 292347
  --> https://bugzilla.kernel.org/attachment.cgi?id=292347=edit
kernel .config (5.9-rc3, OUTLINE KASAN, PowerMac G4 DP)

Does happen even if RAID support is not actively selected in the config as
btrfs pulls in RAID6_PQ on its own.

# CONFIG_DM_RAID is not set
CONFIG_RAID6_PQ=m

-- 
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

2020-09-04 Thread bugzilla-daemon
https://bugzilla.kernel.org/show_bug.cgi?id=205099

Erhard F. (erhar...@mailbox.org) changed:

   What|Removed |Added

 Attachment #287625|0   |1
is obsolete||
 Attachment #288411|0   |1
is obsolete||

--- Comment #30 from Erhard F. (erhar...@mailbox.org) ---
Created attachment 292345
  --> https://bugzilla.kernel.org/attachment.cgi?id=292345=edit
dmesg (5.9-rc3, OUTLINE KASAN, PowerMac G4 DP)

Re-tested with v5.9-rc3 out of curiosity. Not much change here, the bug shows
up with OUTLINE KASAN but not with INLINE KASAN, everything else being equal:

==
BUG: KASAN: user-memory-access in raid6_altivec8_gen_syndrome_real+0x2b0/0x480
[raid6_pq]
Read of size 4 at addr 5764b118 by task modprobe/126

CPU: 1 PID: 126 Comm: modprobe Tainted: GW 5.9.0-rc3-PowerMacG4
#2
Call Trace:
[e32cb7b8] [c0517aac] dump_stack+0xc4/0xf8 (unreliable)
[e32cb7e8] [c026e73c] kasan_report+0x16c/0x170
[e32cb828] [b02004e0] raid6_altivec8_gen_syndrome_real+0x2b0/0x480 [raid6_pq]
[e32cba18] [b02006fc] raid6_altivec8_gen_syndrome+0x4c/0x88 [raid6_pq]
[e32cba38] [b021a42c] init_module+0x42c/0x590 [raid6_pq]
[e32cbb08] [c00058a0] do_one_initcall+0xb8/0x3dc
[e32cbbd8] [c011c0fc] do_init_module+0xa8/0x2c4
[e32cbc08] [c011f02c] load_module+0x2b98/0x2d4c
[e32cbe18] [c011f448] sys_finit_module+0x100/0x138
[e32cbf38] [c001a1cc] ret_from_syscall+0x0/0x34
--- interrupt: c01 at 0x3d2068
LR = 0x506104
==
BUG: Unable to handle kernel data access on read at 0x5764b118
Faulting instruction address: 0xb02004e0
Oops: Kernel access of bad area, sig: 11 [#1]

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 208181] BUG: KASAN: stack-out-of-bounds in strcmp+0x58/0xd8

2020-09-04 Thread bugzilla-daemon
https://bugzilla.kernel.org/show_bug.cgi?id=208181

--- Comment #18 from Erhard F. (erhar...@mailbox.org) ---
Created attachment 292339
  --> https://bugzilla.kernel.org/attachment.cgi?id=292339=edit
kernel .config (5.9-rc3, PowerMac G4 DP)

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 208181] BUG: KASAN: stack-out-of-bounds in strcmp+0x58/0xd8

2020-09-04 Thread bugzilla-daemon
https://bugzilla.kernel.org/show_bug.cgi?id=208181

--- Comment #17 from Erhard F. (erhar...@mailbox.org) ---
Created attachment 292337
  --> https://bugzilla.kernel.org/attachment.cgi?id=292337=edit
dmesg (5.9-rc3, INLINE KASAN, PowerMac G4 DP)

Re-tried with 5.9-rc3 (inline KASAN). The original problem (stack-out-of-bounds
in strcmp+0x58/0xd8) is gone, but still problems with stack usage when doing
larger build jobs:

[...]
[ 1929.683510] do_IRQ: stack overflow: 1696
[ 1929.690727] CPU: 1 PID: 735 Comm: mount.nfs Tainted: GW
5.9.0-rc3-PowerMacG4 #1
[ 1929.697847] Call Trace:
[ 1929.704633] [d0ca4670] [c0a75518] dump_stack+0xfc/0x130 (unreliable)
[ 1929.711507] [d0ca46a0] [c000b094] do_IRQ+0x128/0x180
[ 1929.717998] [d0ca46d0] [c002e560] ret_from_except+0x0/0x14
[ 1929.724652] --- interrupt: 501 at _raw_spin_unlock_irqrestore+0x3c/0xa4
   LR = _raw_spin_unlock_irqrestore+0x38/0xa4
[ 1929.738722] [d0ca47b8] [c0a6dc90] stack_depot_save+0x20c/0x390
[ 1929.746132] [d0ca4818] [c04d4b70] kasan_save_stack+0x40/0x48
[ 1929.753675] [d0ca4928] [c04d4b9c] kasan_set_track+0x24/0x30
[ 1929.761298] [d0ca4938] [c04d710c] kasan_set_free_info+0x28/0x3c
[ 1929.769073] [d0ca4948] [c04d4f74] __kasan_slab_free+0x104/0x118
[ 1929.776983] [d0ca4968] [c04ce800] slab_free_freelist_hook+0xec/0x17c
[ 1929.785111] [d0ca49a8] [c04d3468] kmem_cache_free+0x58/0x2a0
[ 1929.793391] [d0ca49f8] [c11b251c] packet_rcv+0xb9c/0xbb4
[ 1929.801797] [d0ca4a48] [c0dbfd98] dev_queue_xmit_nit+0x6e4/0x748
[ 1929.810434] [d0ca4ab8] [c0dcaf80] dev_hard_start_xmit+0xec/0x880
[ 1929.819207] [d0ca4b18] [c0ea4814] sch_direct_xmit+0x1f8/0x818
[ 1929.828111] [d0ca4bf8] [c0dcc884] __dev_queue_xmit+0xed4/0x136c
[ 1929.837202] [d0ca4d28] [c0f256dc] ip_finish_output2+0xfcc/0x1028
[ 1929.846472] [d0ca4d88] [c0f2d848] __ip_queue_xmit+0xde0/0x1018
[ 1929.855892] [d0ca4df8] [c0f929d8] __tcp_transmit_skb+0x2550/0x2cb8
[ 1929.865486] [d0ca4ee8] [c0f98470] tcp_write_xmit+0x1d28/0x3498
[ 1929.875216] [d0ca4f78] [c0f99c8c] __tcp_push_pending_frames+0xac/0x1c4
[ 1929.885189] [d0ca4f98] [c0f5a970] tcp_sendmsg_locked+0x1c50/0x2294
[ 1929.895338] [d0ca5098] [c0f5afe4] tcp_sendmsg+0x30/0x48
[ 1929.905564] [d0ca50b8] [c0d598b0] sock_sendmsg_nosec+0xf4/0x10c
[ 1929.916463] [d0ca50d8] [b0a31840] xprt_sock_sendmsg+0x2c0/0x6e8 [sunrpc]
[ 1929.927494] [d0ca51b8] [b0a34ce8] xs_tcp_send_request+0x360/0x580 [sunrpc]
[ 1929.938699] [d0ca52e8] [b0a2eae8] xprt_transmit+0x4f8/0xe30 [sunrpc]
[ 1929.950044] [d0ca5368] [b0a1dcd8] call_transmit+0x238/0x25c [sunrpc]
[ 1929.961450] [d0ca5388] [b0a6641c] __rpc_execute+0x35c/0xbf8 [sunrpc]
[ 1929.972996] [d0ca5448] [b0a21d18] rpc_run_task+0x790/0x79c [sunrpc]
[ 1929.984850] [d0ca5498] [b1282e50] nfs4_call_sync_custom+0x14/0x80 [nfsv4]
[ 1929.996821] [d0ca54b8] [b128302c] nfs4_do_call_sync+0x170/0x1a8 [nfsv4]
[ 1930.008922] [d0ca55a8] [b12b3570] nfs4_proc_lookup_common+0x314/0xc54
[nfsv4]
[ 1930.020820] [d0ca5758] [b12b4244] nfs4_proc_lookup+0x158/0x2f0 [nfsv4]
[ 1930.032753] [d0ca57f8] [b0b49544] nfs_lookup+0x2ac/0x9ac [nfs]
[ 1930.044062] [d0ca5838] [c052c984] __lookup_slow+0x278/0x2a8
[ 1930.055461] [d0ca5958] [c05340a0] walk_component+0x288/0x30c
[ 1930.066816] [d0ca5a08] [c0534e5c] path_lookupat.isra.0+0x1b8/0x438
[ 1930.078282] [d0ca5a48] [c05372a0] filename_lookup+0x144/0x1c4
[ 1930.089834] [d0ca5b98] [c05373fc] vfs_path_lookup+0x94/0xc0
[ 1930.101389] [d0ca5c18] [c05714b8] mount_subtree+0x1c4/0x250
[ 1930.113267] [d0ca5ca8] [b12e1b2c] do_nfs4_mount+0x570/0x7fc [nfsv4]
[ 1930.125298] [d0ca5d68] [b12e202c] nfs4_try_get_tree+0xfc/0x16c [nfsv4]
[ 1930.137200] [d0ca5d88] [c050e434] vfs_get_tree+0xf8/0x398
[ 1930.149133] [d0ca5db8] [c056f968] path_mount+0x1074/0x113c
[ 1930.161107] [d0ca5e78] [c056fad8] do_mount+0xa8/0xe4
[ 1930.173109] [d0ca5f08] [c0570054] sys_mount+0xa8/0xb8
[ 1930.185160] [d0ca5f38] [c002e1cc] ret_from_syscall+0x0/0x34
[ 1930.197313] --- interrupt: c01 at 0x8b5754
   LR = 0xac0be0
[ 1930.222896] Kernel panic - not syncing: corrupted stack end detected inside
scheduler


But feel free to close this bug if appropriate as the original issue is solved.

-- 
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

2020-09-02 Thread bugzilla-daemon
https://bugzilla.kernel.org/show_bug.cgi?id=206203

Erhard F. (erhar...@mailbox.org) changed:

   What|Removed |Added

 Attachment #288187|0   |1
is obsolete||

--- Comment #20 from Erhard F. (erhar...@mailbox.org) ---
Created attachment 292289
  --> https://bugzilla.kernel.org/attachment.cgi?id=292289=edit
kernel .config (kernel 5.9-rc3, 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

2020-09-02 Thread bugzilla-daemon
https://bugzilla.kernel.org/show_bug.cgi?id=206203

Erhard F. (erhar...@mailbox.org) changed:

   What|Removed |Added

 Attachment #288189|0   |1
is obsolete||

--- Comment #19 from Erhard F. (erhar...@mailbox.org) ---
Created attachment 292287
  --> https://bugzilla.kernel.org/attachment.cgi?id=292287=edit
kmemleak output (kernel 5.9-rc3, 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

2020-09-02 Thread bugzilla-daemon
https://bugzilla.kernel.org/show_bug.cgi?id=206203

Erhard F. (erhar...@mailbox.org) changed:

   What|Removed |Added

 Attachment #288185|0   |1
is obsolete||

--- Comment #18 from Erhard F. (erhar...@mailbox.org) ---
Created attachment 292285
  --> https://bugzilla.kernel.org/attachment.cgi?id=292285=edit
dmesg (kernel 5.9-rc3, Talos II)

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 209029] kernel 5.9-rc2 fails to boot on a PowerMac G5 11,2 - BUG: Kernel NULL pointer dereference on read at 0x00000020

2020-09-02 Thread bugzilla-daemon
https://bugzilla.kernel.org/show_bug.cgi?id=209029

--- Comment #4 from Erhard F. (erhar...@mailbox.org) ---
(In reply to Christophe Leroy from comment #3)
> Did you try without CONFIG_DEBUG_VM_PGTABLE ?
Without CONFIG_DEBUG_VM_PGTABLE the G5 boots fine. Thanks!

> If you want CONFIG_DEBUG_VM_PGTABLE, the following series aims at fixing it
> for PPC64:
> https://patchwork.ozlabs.org/project/linuxppc-dev/list/?series=197961
Did not check the series as current ozlabs patches indicate that the
CONFIG_DEBUG_VM_PGTABLE option is removed for the time being.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 209029] kernel 5.9-rc2 fails to boot on a PowerMac G5 11,2 - BUG: Kernel NULL pointer dereference on read at 0x00000020

2020-08-31 Thread bugzilla-daemon
https://bugzilla.kernel.org/show_bug.cgi?id=209029

Christophe Leroy (christophe.le...@csgroup.eu) changed:

   What|Removed |Added

 CC||christophe.le...@csgroup.eu

--- Comment #3 from Christophe Leroy (christophe.le...@csgroup.eu) ---
Did you try without CONFIG_DEBUG_VM_PGTABLE ?

If you want CONFIG_DEBUG_VM_PGTABLE, the following series aims at fixing it for
PPC64: https://patchwork.ozlabs.org/project/linuxppc-dev/list/?series=197961

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 209029] kernel 5.9-rc2 fails to boot on a PowerMac G5 11,2 - BUG: Kernel NULL pointer dereference on read at 0x00000020

2020-08-31 Thread bugzilla-daemon
https://bugzilla.kernel.org/show_bug.cgi?id=209029

--- Comment #2 from Erhard F. (erhar...@mailbox.org) ---
No change with 5.9-rc3.

-- 
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

2020-08-31 Thread bugzilla-daemon
https://bugzilla.kernel.org/show_bug.cgi?id=205183

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 208957] 5.9-rc1 fails to build for a PowerMac G5: .../book3s64/hash_utils.c:1119:21: error: ‘default_uamor’ undeclared (first use in this function) 1119 | mtspr(SPRN_UAMOR, default_uamor);

2020-08-26 Thread bugzilla-daemon
https://bugzilla.kernel.org/show_bug.cgi?id=208957

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 208957] 5.9-rc1 fails to build for a PowerMac G5: .../book3s64/hash_utils.c:1119:21: error: ‘default_uamor’ undeclared (first use in this function) 1119 | mtspr(SPRN_UAMOR, default_uamor);

2020-08-26 Thread bugzilla-daemon
https://bugzilla.kernel.org/show_bug.cgi?id=208957

Michael Ellerman (mich...@ellerman.id.au) changed:

   What|Removed |Added

 CC||mich...@ellerman.id.au
 Resolution|OBSOLETE|CODE_FIX

--- Comment #2 from Michael Ellerman (mich...@ellerman.id.au) ---
Fixed in 1e4e4bcaf70e ("powerpc/pkeys: Fix build error with PPC_MEM_KEYS
disabled")

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 209029] kernel 5.9-rc2 fails to boot on a PowerMac G5 11,2 - BUG: Kernel NULL pointer dereference on read at 0x00000020

2020-08-24 Thread bugzilla-daemon
https://bugzilla.kernel.org/show_bug.cgi?id=209029

--- Comment #1 from Erhard F. (erhar...@mailbox.org) ---
Created attachment 292155
  --> https://bugzilla.kernel.org/attachment.cgi?id=292155=edit
dmesg screenshot

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 209029] New: kernel 5.9-rc2 fails to boot on a PowerMac G5 11, 2 - BUG: Kernel NULL pointer dereference on read at 0x00000020

2020-08-24 Thread bugzilla-daemon
https://bugzilla.kernel.org/show_bug.cgi?id=209029

Bug ID: 209029
   Summary: kernel 5.9-rc2 fails to boot on a PowerMac G5 11,2 -
BUG: Kernel NULL pointer dereference on read at
0x0020
   Product: Platform Specific/Hardware
   Version: 2.5
Kernel Version: 5.9-rc2
  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 292153
  --> https://bugzilla.kernel.org/attachment.cgi?id=292153=edit
kernel .config (kernel 5.9-rc2, PowerMac G5 11,2)

Transcribed the stacktrace from a screenshot with my camera:

[...]
REGS: c0047d0d7850 TRAP:   0700 Tainted: GW 
(5.9.0-rc2-PowerMacG5)
MSR:  90029032   CR: 44000448  XER: 200f
IRQMASK: 0
GPR00: c0af853c c0047d0d7ae0 c0d17300 0001
GPR04: 1f255000 c0047b5c92a8 0001 
GPR08: c000 0001 3fff 4000
GPR12: 24000448 cc80 c000fd78 
GPR16:    
GPR20: 00c3e000 c0c3e307 c0d83b90 c00030030f80
GPR24: c0d83c28 0c00 c0047b5c74b0 8105
GPR28: ee1fffbf c0047d64f800 1f255000 1f255000
NIP [c0af8568] .debug_um_pgtable+0x884/0xa20
LR [c0af853c] .debug_vm_pgtable+0x858/0xa20
Call Trace:
[c0047d0d7ae0] [c0af853c] .debug_vm_pgtable++0x858/0xa20
(unreliable)
[c0047d0d7be0] [c000f62c] .do_one_initcall+0x60/0x344
[c0047d0d7cc0] [c0ad8d64] .kerne]_init_freeable+0x3c0/0x3f4
[c0047d0d7db0] [c000fd88] .kernel_init+0x10/0x130
[c0047d0d7e20] [c000b9d8] .ret_from_kerne!_thread+0x58/0x60
Instruction dump:
4b53b145 6000 e8df 7f863278 3f80ee1f 639c 7b9c07c6 679c
639cffbf 7cc6e038 3146 7cca3110 <0b06> 3900 38e0 38c0
irg event stamp: 369
hardirgs last  enabled at (369): []
.console_unlock+0x650/0x664
hardirgs last disabled at (366): []
.console_unlock+0x170/0x664
softirgs last  enabled at (0): [] .copy_process+0x69c/0x1510
softirgs last disabled at (0): [<>] 0x0
---[ end trace 0561544ca9dc6c57 ]---
BUG: Kernel NULL pointer dereference on read at 0x0020
ata2: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
Faulting instruction address: 0xc0033924
Oops: Kernel access of bad area, sig: 11 [#1]
BE PAGE_SIZE=4K MMU=Hash SMP NR_CPUS=4 NUMA PowerMac
Modules linked in:
CPU: 1 PID: 1 Comm: swapper/0 Tainted: GW 5.9.0-rc2-PowerMacG5
#2
NIP:  c0033924 LR: c00338e4 CTR: 
REGS: c0047d0d77a0 TRAP: 0380 Tainted: GW 
(5.9.0-rc2-PowerMacG5)
MSR:  90009032  CR: 44000448 XER: 200f
IRQMASK: 0
GPR00: c00338e4 c0047d0d7a30 c0d17300 c0047d0d7aa8
GPR04: 80c3e387 0001 80c3e387 0001
GPR08: c000  c0d83d48 
GPR12: 24000448 cc80 c000fd78 
GPR16:    
GPR20: 00c3e000 c0c3e307 c0d83b90 c00030030f80
GPR24: c0d83c28 0c00 c0047b5c74b0 8105
GPR28: c0047b5c74b0 0001 80c3e387 c0047b5c92a8
NIP [c0033924] .huge_ptep_set_access_flags+0x70/0x114
LR [c00338e4] .huge_ptep_set_access_flags+0x30/0x114
Call Trace:
[c0047d0d7a30] [c00338e4] .huge_ptep_set_access_flags+0x30/0x114
(unreliable)
[c0047d0d7ae0] [c0af86b4] .debug_vm_pgtable++0x9d0/0xa20
[c0047d0d7be0] [c000f62c] .do_one_initcall+0x60/0x344
[c0047d0d7cc0] [c0ad8d64] .kerne]_init_freeable+0x3c0/0x3f4
[c0047d0d7db0] [c000fd88] .kernel_init+0x10/0x130
[c0047d0d7e20] [c000b9d8] .ret_from_kerne!_thread+0x58/0x60
Instruction dump:
794a07c6 654a 7fc94a78 614affbf 7d295038 2c29 33a9 7fbd4910
4182008c e93c00a0 3d420007 394aca48  810a0268 e9290028 e9290648
---[ end trace 0561544ca9dc6c58 ]---

note: swapper/0[1] exited with preempt_count 1
ata2.00: ATA-8: WDC WD5000BPKX-22HPJT0, 01.01A01, max UDMA/133
Kernel panic - not syncing: Attempted to kill init! exitcode=0x000b
ata2.00: 976773168 sectors, multi 0: LBA48 NCQ (depth 0/32)
Rebooting in 120 seconds..

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 208957] 5.9-rc1 fails to build for a PowerMac G5: .../book3s64/hash_utils.c:1119:21: error: ‘default_uamor’ undeclared (first use in this function) 1119 | mtspr(SPRN_UAMOR, default_uamor);

2020-08-24 Thread bugzilla-daemon
https://bugzilla.kernel.org/show_bug.cgi?id=208957

Erhard F. (erhar...@mailbox.org) changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |OBSOLETE

--- Comment #1 from Erhard F. (erhar...@mailbox.org) ---
5.9-rc2 builds again with the same config.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 208957] New: 5.9-rc1 fails to build for a PowerMac G5: .../book3s64/hash_utils.c:1119:21: error: ‘default_uamor’ undeclared (first use in this function) 1119 | mtspr(SPRN_UAMOR, default_uamor)

2020-08-18 Thread bugzilla-daemon
https://bugzilla.kernel.org/show_bug.cgi?id=208957

Bug ID: 208957
   Summary: 5.9-rc1 fails to build for a PowerMac G5:
.../book3s64/hash_utils.c:1119:21: error:
‘default_uamor’ undeclared (first use in this
function)  1119 |   mtspr(SPRN_UAMOR, default_uamor);
   Product: Platform Specific/Hardware
   Version: 2.5
Kernel Version: 5.9-rc1
  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 292021
  --> https://bugzilla.kernel.org/attachment.cgi?id=292021=edit
kernel .config (kernel 5.9-rc1, PowerMac G5 11,2)

[...]
  CALLscripts/checksyscalls.sh
  CALLscripts/atomic/check-atomics.sh
  CHK include/generated/compile.h
  CC  arch/powerpc/mm/book3s64/hash_utils.o
In file included from ./arch/powerpc/include/asm/processor.h:9,
 from ./arch/powerpc/include/asm/thread_info.h:40,
 from ./include/linux/thread_info.h:38,
 from ./include/asm-generic/preempt.h:5,
 from ./arch/powerpc/include/generated/asm/preempt.h:1,
 from ./include/linux/preempt.h:78,
 from ./include/linux/spinlock.h:51,
 from arch/powerpc/mm/book3s64/hash_utils.c:21:
arch/powerpc/mm/book3s64/hash_utils.c: In function
‘hash__early_init_mmu_secondary’:
arch/powerpc/mm/book3s64/hash_utils.c:1119:21: error: ‘default_uamor’
undeclared (first use in this function)
 1119 |   mtspr(SPRN_UAMOR, default_uamor);
  | ^
./arch/powerpc/include/asm/reg.h:1396:33: note: in definition of macro ‘mtspr’
 1396 |  : "r" ((unsigned long)(v)) \
  | ^
arch/powerpc/mm/book3s64/hash_utils.c:1119:21: note: each undeclared identifier
is reported only once for each function it appears in
 1119 |   mtspr(SPRN_UAMOR, default_uamor);
  | ^
./arch/powerpc/include/asm/reg.h:1396:33: note: in definition of macro ‘mtspr’
 1396 |  : "r" ((unsigned long)(v)) \
  | ^
make[3]: *** [scripts/Makefile.build:283:
arch/powerpc/mm/book3s64/hash_utils.o] Error 1
make[2]: *** [scripts/Makefile.build:500: arch/powerpc/mm/book3s64] Error 2
make[1]: *** [scripts/Makefile.build:500: arch/powerpc/mm] Error 2
make: *** [Makefile:1789: arch/powerpc] Error 2

-- 
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

2020-08-10 Thread bugzilla-daemon
https://bugzilla.kernel.org/show_bug.cgi?id=205183

--- Comment #6 from Michael Ellerman (mich...@ellerman.id.au) ---
Fixed in 63dee5df43a3 ("powerpc: Allow 4224 bytes of stack expansion for the
signal frame")

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 207359] MegaRAID SAS 9361 controller hang/reset

2020-08-06 Thread bugzilla-daemon
https://bugzilla.kernel.org/show_bug.cgi?id=207359

--- Comment #4 from Cameron (c...@neo-zeon.de) ---
I converted the box's filesystems from BTRFS to XFS, and switched the page size
from 4k to 64k. The problem appears to be entirely gone now. I am able to
conclusively run 5.7.13 without issue, which I verified as having the
megaraid_sas controller hang problem while still running my previous BTRFS+4k
page configuration.

Unfortunately, it took a great deal of time to perform this conversion, and I
wasn't able to keep the box down even longer to test if converting to XFS and
64k pages individually resolved the issue. All I can say for certain is that
either switching to XFS, to a 64k page size, or both has fixed the problem for
me.

The backup volume is a single SATA disk that is still using BTRFS (for
snapshotting), and is not giving me any trouble. But if this has any relation
to https://bugzilla.kernel.org/show_bug.cgi?id=206123, then this may not be
conclusive due to being that SATA disks potentially may not trigger the issue.
The single disk also can't push as much IO as the RAID10 volume so that may be
another reason.

My quasi educated non-kernel-dev guess is that this is probably a bug relating
to the 4k page size. Whether or not the regular behavior of BTRFS exacerbates
this (making it easier to reproduce), is possible, but unknown.

Hopefully someone else encountering this issue will find this helpful.

-- 
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

2020-07-28 Thread bugzilla-daemon
https://bugzilla.kernel.org/show_bug.cgi?id=206203

--- Comment #17 from Erhard F. (erhar...@mailbox.org) ---
Created attachment 290641
  --> https://bugzilla.kernel.org/attachment.cgi?id=290641=edit
kmemleak output (kernel 5.8-rc7, PowerMac G4 3,6)

Also happens on my 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

2020-07-28 Thread bugzilla-daemon
https://bugzilla.kernel.org/show_bug.cgi?id=206203

--- Comment #16 from Erhard F. (erhar...@mailbox.org) ---
Created attachment 290639
  --> https://bugzilla.kernel.org/attachment.cgi?id=290639=edit
dmesg (kernel 5.8-rc7, PowerMac G4 3,6)

-- 
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

2020-07-27 Thread bugzilla-daemon
https://bugzilla.kernel.org/show_bug.cgi?id=205183

Michael Ellerman (mich...@ellerman.id.au) changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |CODE_FIX

-- 
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

2020-07-27 Thread bugzilla-daemon
https://bugzilla.kernel.org/show_bug.cgi?id=205183

Michael Ellerman (mich...@ellerman.id.au) changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 CC||mich...@ellerman.id.au

--- Comment #5 from Michael Ellerman (mich...@ellerman.id.au) ---
Patches posted:

https://patchwork.ozlabs.org/project/linuxppc-dev/list/?series=192046

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 208181] BUG: KASAN: stack-out-of-bounds in strcmp+0x58/0xd8

2020-07-14 Thread bugzilla-daemon
https://bugzilla.kernel.org/show_bug.cgi?id=208181

Erhard F. (erhar...@mailbox.org) changed:

   What|Removed |Added

 Attachment #289937|0   |1
is obsolete||

--- Comment #16 from Erhard F. (erhar...@mailbox.org) ---
Created attachment 290285
  --> https://bugzilla.kernel.org/attachment.cgi?id=290285=edit
kernel .config (5.8-rc5, PowerMac G4 DP)

Did some additional test-runs, seems there are still problems with stack usage
when running (inline) KASAN:

5.8-rc3 + the 2 patches applied:
Instruction dump:
usercopy: Kernel memory overwrite attemp detected to kernel text (offset 5432,
size 4)!
[ cut here ]
kernel BUG at mm/usercopy.c:99!
Oops: Exeption in kernel mode, sig:5 [#6]
BE PAGE_SIZE=4K MMU=Hash SMP NR_CPUS=2 PowerMac
Modules linked in: auth_rpcgss nfsv4 dns_resolver nfs lockd grace sunrpc
b43legacy input_leds joydev mac80211 hid_generic g4_windtunnel sungem
sungem_phy btrfs ohci_pci xor lzo_compress lzo_decompress zlib_deflate raid6_pq
zlib_inflate firewire_ohci hcd soundcore ssb pcmcia usbcore uninorth_agp
pcmcia_core agpart usb_common
CPU: 1 PID: 5250 Comm: mount.nfs Tainted: G   W   
5.8.0-rc3-PowerMacG4+ #8
NIP: c04d654c LR: c04d654c CTR: 
REGS: c0001198 TRAP: 0700  Tainted: G   W(5.8.0-rc3-PowerMacG4+)
MSR:  00021031  CR: 24028822 XER: 

GPR00: c04d654c c0001498 e719b980 0058 c01899f4  0027 e8dc4e0c
GPR08: 0023   c0001498 44028822 0061bff4 f80002s9 0003
GPR16: c115a340 f80002d7 c00016b8 c00016c8 c04d654c c115a260 c04d651c f80002d5
GPR24: c00016ac 180002d5 e8dda024 c000 c000153c  0004 c0001538
NIP [c04d654c] usercopy_abort+0x68/0x78
LR [c04d654c] usercopy_abort+0x68/0x78
Call Trace:
Instruction dump:
usercopy: Kernel memory overwrite attemp detected to kernel text (offset 4848,
size 4)!
[ cut here ]
kernel BUG at mm/usercopy.c:99!
Oops: Exeption in kernel mode, sig:5 [#7]
BE PAGE_SIZE=4K MMU=Hash SMP NR_CPUS=2 PowerMac
Modules linked in: auth_rpcgss nfsv4 dns_resolver nfs lockd grace sunrpc
b43legacy input_leds joydev mac80211 hid_generic g4_windtunnel sungem
sungem_phy btrfs ohci_pci xor lzo_compress lzo_decompress zlib_deflate raid6_pq
zlib_inflate firewire_ohci hcd soundcore ssb pcmcia usbcore uninorth_agp
pcmcia_core agpart usb_common
CPU: 1 PID: 5250 Comm: mount.nfs Tainted: G   W   
5.8.0-rc3-PowerMacG4+ #8
NIP: c04d654c LR: c04d654c CTR: 
REGS: c0001198 TRAP: 0700  Tainted: G   W(5.8.0-rc3-PowerMacG4+)
MSR:  00021031  CR: 24028822 XER: 

GPR00: c04d654c c0001250 e719b980 0058 c01899f4  0027 e8dc4e0c
GPR08: 0023   c0001250 44028822 0061bff4 f8000290 0003
GPR16: c115a340 f800028e c0001470 c0001480 c04d654c c115a260 c04d651c f800028c
GPR24: c0001464 1800028c e8dda024 c000 c00012f4  0004 c00012f0
NIP [c04d654c] usercopy_abort+0x68/0x78
Unrecoverable FP Unavailable Exception 801 at 908
LR [c04d654c] usercopy_abort+0x68/0x78
Call Trace:


5.8-rc5 + the 2 patches applied:
do_IRQ: stack overflow: 1984
CPU: 1 PID: 347 Comm: gzip Tainted: G   W5.8.0-rc5-PowerMacG4+ #1
Call Trace:

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 208197] OF: /pci@f2000000/mac-io@17/gpio@50/...: could not find phandle

2020-07-09 Thread bugzilla-daemon
https://bugzilla.kernel.org/show_bug.cgi?id=208197

--- Comment #9 from Erhard F. (erhar...@mailbox.org) ---
(In reply to Michael Ellerman from comment #7)
> I couldn't really make sense of your bisect log, it doesn't have any
> good/bad commits in it.
> 
> Can you attach the output of "git bisect log".
Yea sorry, my fault... I thought e.g. with "git bisect bad | tee -a
~/bisect.log" bisect.log generated via tee would have the same output as with
"git bisect log" but I was wrong. 

Please find the correct one attached now. I had to restart the bisect as I
already resetted the original one.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 208197] OF: /pci@f2000000/mac-io@17/gpio@50/...: could not find phandle

2020-07-09 Thread bugzilla-daemon
https://bugzilla.kernel.org/show_bug.cgi?id=208197

Erhard F. (erhar...@mailbox.org) changed:

   What|Removed |Added

 Attachment #290097|0   |1
is obsolete||

--- Comment #8 from Erhard F. (erhar...@mailbox.org) ---
Created attachment 290191
  --> https://bugzilla.kernel.org/attachment.cgi?id=290191=edit
bisect.log

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 208197] OF: /pci@f2000000/mac-io@17/gpio@50/...: could not find phandle

2020-07-07 Thread bugzilla-daemon
https://bugzilla.kernel.org/show_bug.cgi?id=208197

--- Comment #7 from Michael Ellerman (mich...@ellerman.id.au) ---
I couldn't really make sense of your bisect log, it doesn't have any good/bad
commits in it.

And I don't see how reverting a merge of v5.7-rc7 can be helping, because you
said v5.7 is good, and that contains v5.7-rc7.

Can you attach the output of "git bisect log".

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 208197] OF: /pci@f2000000/mac-io@17/gpio@50/...: could not find phandle

2020-07-07 Thread bugzilla-daemon
https://bugzilla.kernel.org/show_bug.cgi?id=208197

--- Comment #6 from Erhard F. (erhar...@mailbox.org) ---
Also I took some time to revert individual commits from the bisect.log:

388bcc6ecc609fca1b4920de7dc3806c98ec535e drivers: base: Fix NULL pointer
exception in __platform_driver_probe() if a driver developer is foolish
48ebea5026d692c5ab0a7d303f0fe1f8ba046e0f firmware_loader: move
fw_fallback_config to a private kernel symbol namespace
c78c31b374a68be79cb4a03ef5b6c187f034e903 Revert "Revert "driver core: Set
fw_devlink to "permissive" behavior by default""
c8be6af9ef16cf44d690fc227a0d2dd7a526ef05 Merge v5.7-rc5 into driver-core-next
eb7fbc9fb1185a7f89adeb2de724c2c96ff608e9 driver core: Add missing '\n' in log
messages
42926ac3cd50937346c23c0005817264af4357a7 driver core: Move code to the right
part of the file
baf1d9c182935e88aab08701b0a0b22871117fe0 driver/base/soc: Use kobj_to_dev() API
5f5377eaddfc24e5d7562e588d0ff84f9264d7c1 driver core: Look for waiting
consumers only for a fwnode's primary device
96fa72ffb2155dba9ba8c5d282a1ff19ed32f177 Merge 5.7-rc3 into driver-core-next
716a7a25969003d82ab738179c3f1068a120ed11 driver core: fw_devlink: Add support
for batching fwnode parsing
fbc35b45f9f6a971341b9462c6e94c257e779fb5 Add documentation on meaning of
-EPROBE_DEFER
45bb08de65b418959313593f527c619e102c2d57 driver core: platform: remove
redundant assignment to variable ret
93d2e4322aa74c1ad1e8c2160608eb9a960d69ff of: platform: Batch fwnode parsing
when adding all top level devices
69b07ee33eb12a505d55e3e716fc7452496b9041 debugfs: Use the correct style for
SPDX License Identifier
fefcfc968723caf93318613a08e1f3ad07a6154f driver core: Remove check in
driver_deferred_probe_force_trigger()
0f605db5bdd42edfbfcac36acaf8f72cfe9ce774 kernfs: Change kernfs_node lockdep
name to "kn->active"
c82c83c330654c5639960ebc3dabbae53c43f79e driver core: platform: Fix spelling
errors in platform.c
114dbb4fa7c4053a51964d112e2851e818e085c6 drivers property: When no children in
primary, try secondary
55623260bb33e2ab849af76edf2253bc04cb241f test_firmware: remove unnecessary
test_fw_mutex in test_dev_config_show_xxx
2cd38fd15e4ebcfe917a443734820269f8b5ba2b driver core: Remove unnecessary
is_fwnode_dev variable in device_add()
ab7c1e163b525316a870a494dd4ea196e7a6c455 firmware: Drop unused pages field from
struct firmware
f7d8f3f092d001f8d91552d2697643e727694942 Merge 5.7-rc7 into driver-core-next


Reverting Merge 5.7-rc7 into driver-core-next via:
git revert f7d8f3f092d001f8d91552d2697643e727694942 -m2

while leaving the other commits still in made the "could not find phandle"
disappear. I guess the relevant commit is somewhere in this merge.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 208197] OF: /pci@f2000000/mac-io@17/gpio@50/...: could not find phandle

2020-07-07 Thread bugzilla-daemon
https://bugzilla.kernel.org/show_bug.cgi?id=208197

--- Comment #5 from Erhard F. (erhar...@mailbox.org) ---
(In reply to Michael Ellerman from comment #3)
> Try this?
See new dmesg.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 208197] OF: /pci@f2000000/mac-io@17/gpio@50/...: could not find phandle

2020-07-07 Thread bugzilla-daemon
https://bugzilla.kernel.org/show_bug.cgi?id=208197

--- Comment #4 from Erhard F. (erhar...@mailbox.org) ---
Created attachment 290157
  --> https://bugzilla.kernel.org/attachment.cgi?id=290157=edit
dmesg (5.8-rc4 + WARN_ON patch, PowerMac G4 DP)

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 208197] OF: /pci@f2000000/mac-io@17/gpio@50/...: could not find phandle

2020-07-07 Thread bugzilla-daemon
https://bugzilla.kernel.org/show_bug.cgi?id=208197

Michael Ellerman (mich...@ellerman.id.au) changed:

   What|Removed |Added

 Status|NEW |NEEDINFO
 CC||mich...@ellerman.id.au

--- Comment #3 from Michael Ellerman (mich...@ellerman.id.au) ---
Try this?

diff --git a/drivers/of/base.c b/drivers/of/base.c
index ae03b1218b06..b2961bec57d9 100644
--- a/drivers/of/base.c
+++ b/drivers/of/base.c
@@ -1299,6 +1299,7 @@ int of_phandle_iterator_next(struct of_phandle_iterator
*it)
if (!it->node) {
pr_err("%pOF: could not find phandle\n",
   it->parent);
+   WARN_ON(1);
goto err;
}

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 208197] OF: /pci@f2000000/mac-io@17/gpio@50/...: could not find phandle

2020-07-05 Thread bugzilla-daemon
https://bugzilla.kernel.org/show_bug.cgi?id=208197

--- Comment #2 from Erhard F. (erhar...@mailbox.org) ---
Created attachment 290097
  --> https://bugzilla.kernel.org/attachment.cgi?id=290097=edit
bisect.log

Did a bisect but got quite some skips due to the system not finishing booting.

 # git bisect skip | tee -a ~/bisect02.log
There are only 'skip'ped commits left to test.
The first bad commit could be any of:
388bcc6ecc609fca1b4920de7dc3806c98ec535e
48ebea5026d692c5ab0a7d303f0fe1f8ba046e0f
c78c31b374a68be79cb4a03ef5b6c187f034e903
c8be6af9ef16cf44d690fc227a0d2dd7a526ef05
eb7fbc9fb1185a7f89adeb2de724c2c96ff608e9
42926ac3cd50937346c23c0005817264af4357a7
baf1d9c182935e88aab08701b0a0b22871117fe0
5f5377eaddfc24e5d7562e588d0ff84f9264d7c1
96fa72ffb2155dba9ba8c5d282a1ff19ed32f177
716a7a25969003d82ab738179c3f1068a120ed11
fbc35b45f9f6a971341b9462c6e94c257e779fb5
45bb08de65b418959313593f527c619e102c2d57
93d2e4322aa74c1ad1e8c2160608eb9a960d69ff
69b07ee33eb12a505d55e3e716fc7452496b9041
fefcfc968723caf93318613a08e1f3ad07a6154f
0f605db5bdd42edfbfcac36acaf8f72cfe9ce774
c82c83c330654c5639960ebc3dabbae53c43f79e
114dbb4fa7c4053a51964d112e2851e818e085c6
55623260bb33e2ab849af76edf2253bc04cb241f
2cd38fd15e4ebcfe917a443734820269f8b5ba2b
ab7c1e163b525316a870a494dd4ea196e7a6c455
f7d8f3f092d001f8d91552d2697643e727694942
Keine binäre Suche mehr möglich!

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 208181] BUG: KASAN: stack-out-of-bounds in strcmp+0x58/0xd8

2020-07-02 Thread bugzilla-daemon
https://bugzilla.kernel.org/show_bug.cgi?id=208181

--- Comment #15 from Christophe Leroy (christophe.le...@csgroup.eu) ---
Ah yes, having init_text above the 24 bits limit might be a problem for
function calls. I'm surprised that the linker doesn't complain.

Anyway, it is not a problem in itself, and it's unrelated to this bug.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 208181] BUG: KASAN: stack-out-of-bounds in strcmp+0x58/0xd8

2020-07-02 Thread bugzilla-daemon
https://bugzilla.kernel.org/show_bug.cgi?id=208181

--- Comment #14 from Erhard F. (erhar...@mailbox.org) ---
Ah, I've overlooked that...

To set CONFIG_DATA_SHIFT=25 I needed to set ADVANCED_OPTIONS=y,
DATA_SHIFT_BOOL=y first.

But with CONFIG_DATA_SHIFT=25 this kernel won't boot at all. OpenFirmware shows
for a brief moment that the kernel gets loaded and then I get dropped back to
OF console.

OpenFirmware tells me:
Invalid memory access at %SRR0: a000  %SRR1: 

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 208181] BUG: KASAN: stack-out-of-bounds in strcmp+0x58/0xd8

2020-07-02 Thread bugzilla-daemon
https://bugzilla.kernel.org/show_bug.cgi?id=208181

--- Comment #13 from Christophe Leroy (christophe.le...@csgroup.eu) ---
Thanks for testing.

Regarding the two BATs, I suggest you increase CONFIG_DATA_SHIFT as explained
in a previous comment.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 208181] BUG: KASAN: stack-out-of-bounds in strcmp+0x58/0xd8

2020-07-02 Thread bugzilla-daemon
https://bugzilla.kernel.org/show_bug.cgi?id=208181

--- Comment #12 from Erhard F. (erhar...@mailbox.org) ---
Successfully applied your 2 patches. The kernel still complains about these 2
BATs, but the KASAN hit at early boot is gone with the patches. Thanks!

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 208181] BUG: KASAN: stack-out-of-bounds in strcmp+0x58/0xd8

2020-07-02 Thread bugzilla-daemon
https://bugzilla.kernel.org/show_bug.cgi?id=208181

--- Comment #11 from Christophe Leroy (christophe.le...@csgroup.eu) ---
The issue is that that commit moved more code than described into kasan_init():

Kasan Pages allocation have to be moved into kasan_init() but page tables
allocation must remain before the switch to the final hash table.

Problem only occurs on book3s/32 having hash MMU.

See proposed fix at
https://patchwork.ozlabs.org/project/linuxppc-dev/list/?series=187165 (2
patches).

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 208181] BUG: KASAN: stack-out-of-bounds in strcmp+0x58/0xd8

2020-07-02 Thread bugzilla-daemon
https://bugzilla.kernel.org/show_bug.cgi?id=208181

--- Comment #10 from Christophe Leroy (christophe.le...@csgroup.eu) ---
I reproduced the problem and bisected it to commit
https://github.com/torvalds/linux/commit/d2a91cef9bbdeb87b7449fdab1a6be6000930210

I'll investigate the issue

Can you confirm this commit is also the curprit from your side ?

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 208181] BUG: KASAN: stack-out-of-bounds in strcmp+0x58/0xd8

2020-06-30 Thread bugzilla-daemon
https://bugzilla.kernel.org/show_bug.cgi?id=208181

--- Comment #9 from Erhard F. (erhar...@mailbox.org) ---
Ok, thanks for the clarification! So if KASAN works properly something else
must cause this hit. I will start a bisect the next few days and see how that
turns out...

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 208181] BUG: KASAN: stack-out-of-bounds in strcmp+0x58/0xd8

2020-06-30 Thread bugzilla-daemon
https://bugzilla.kernel.org/show_bug.cgi?id=208181

--- Comment #8 from Christophe Leroy (christophe.le...@csgroup.eu) ---
block_address_translation contains funny sizes. But the adresses seems ok.
So it shows you have a 24 Mb text+rodata area. 8 BATs are used
(16+8+8+32+64+128+256+256)
By increasing CONFIG_DATA_SHIFT to 25, you'll get a 32Mb alignment
So you will have only 6 bats used (32+32+64+128+256+256), so two additional
data BATs will be available for KASAN.

But regardless of the BAT stuff, KASAN should work properly.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 208181] BUG: KASAN: stack-out-of-bounds in strcmp+0x58/0xd8

2020-06-29 Thread bugzilla-daemon
https://bugzilla.kernel.org/show_bug.cgi?id=208181

--- Comment #7 from Erhard F. (erhar...@mailbox.org) ---
Created attachment 289947
  --> https://bugzilla.kernel.org/attachment.cgi?id=289947=edit
segment_registers

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 208181] BUG: KASAN: stack-out-of-bounds in strcmp+0x58/0xd8

2020-06-29 Thread bugzilla-daemon
https://bugzilla.kernel.org/show_bug.cgi?id=208181

--- Comment #6 from Erhard F. (erhar...@mailbox.org) ---
Created attachment 289945
  --> https://bugzilla.kernel.org/attachment.cgi?id=289945=edit
block_address_translation

Sure.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 208181] BUG: KASAN: stack-out-of-bounds in strcmp+0x58/0xd8

2020-06-29 Thread bugzilla-daemon
https://bugzilla.kernel.org/show_bug.cgi?id=208181

--- Comment #5 from Christophe Leroy (christophe.le...@csgroup.eu) ---
Can we get a dump of /sys/kernel/debug/powerpc/block_address_translation

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 208181] BUG: KASAN: stack-out-of-bounds in strcmp+0x58/0xd8

2020-06-29 Thread bugzilla-daemon
https://bugzilla.kernel.org/show_bug.cgi?id=208181

--- Comment #4 from Erhard F. (erhar...@mailbox.org) ---
Erm wait... there is some change.

In 5.8-rc1 stacktrace was:
BUG: KASAN: stack-out-of-bounds in strcmp+0x58/0xd8
Read of size 1 at addr c11c1a80 by task swapper/0

CPU: 0 PID: 0 Comm: swapper Not tainted 5.8.0-rc1-PowerMacG4 #2
Call Trace:
[c1ae97d0] [c0a2069c] dump_stack+0xfc/0x158 (unreliable)
[c1ae9800] [c04ac5cc] print_address_description.isra.0+0x30/0x3fc
[c1ae9870] [c04acb28] kasan_report+0x110/0x170
[c1ae98b0] [c0a44c00] strcmp+0x58/0xd8
[c1ae98d0] [c0170790] register_lock_class+0xfa4/0x10a0
[c1ae9990] [c0170a34] __lock_acquire+0x1a8/0x382c
[c1ae9b40] [c016f398] lock_acquire+0x5e0/0x854
[c1ae9c00] [c1144014] _raw_spin_lock_irqsave+0x48/0x70
[c1ae9c20] [c0ccbe84] of_find_property+0x2c/0x5c
[c1ae9c50] [c0ccbec8] of_get_property+0x14/0x6c
[c1ae9c70] [c0cdbcd8] unflatten_dt_nodes+0xc4c/0xcdc
[c1ae9ec0] [c0cdbe90] __unflatten_device_tree+0x114/0x1e0
[c1ae9ef0] [c184a294] unflatten_device_tree+0x38/0x54
[c1ae9f10] [c1808600] setup_arch+0xc8/0x630
[c1ae9f50] [c1803268] start_kernel+0xcc/0x4cc
[c1ae9ff0] [38a0] 0x38a0


In 5.8-rc3 stacktrace is:
BUG: KASAN: stack-out-of-bounds in vprintk_func+0x100/0x4b4
Read of size 4 at addr c1919e14 by task swapper/0

CPU: 0 PID: 0 Comm: swapper Not tainted 5.8.0-rc3-PowerMacG4 #2
Call Trace:
[c1ae9c00] [c0a304dc] dump_stack+0xfc/0x158 (unreliable)
[c1ae9c30] [c04ac990] print_address_description.isra.0+0x30/0x3fc
[c1ae9ca0] [c04aceec] kasan_report+0x110/0x170
[c1ae9ce0] [c018c204] vprintk_func+0x100/0x4b4
[c1ae9d10] [c018afd4] printk+0xa8/0xd4
[c1ae9db0] [c003c8c4] __ioremap_caller+0x1c4/0x27c
[c1ae9df0] [c003c394] ioremap+0x20/0x30
[c1ae9e00] [c1813fe4] pmac_feature_init+0x288/0xd90
[c1ae9ed0] [c1812cb0] pmac_probe+0x13c/0x190
[c1ae9ef0] [c001d938] probe_machine+0xe8/0x13c
[c1ae9f10] [c1808614] setup_arch+0xdc/0x630
[c1ae9f50] [c1803268] start_kernel+0xcc/0x4cc
[c1ae9ff0] [38a0] 0x38a0


What stays the same are the two "setbat: no BAT available" messages in both
cases.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 208181] BUG: KASAN: stack-out-of-bounds in strcmp+0x58/0xd8

2020-06-29 Thread bugzilla-daemon
https://bugzilla.kernel.org/show_bug.cgi?id=208181

Erhard F. (erhar...@mailbox.org) changed:

   What|Removed |Added

 Attachment #289661|0   |1
is obsolete||

--- Comment #3 from Erhard F. (erhar...@mailbox.org) ---
Created attachment 289937
  --> https://bugzilla.kernel.org/attachment.cgi?id=289937=edit
kernel .config (5.8-rc3, PowerMac G4 DP)

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 208181] BUG: KASAN: stack-out-of-bounds in strcmp+0x58/0xd8

2020-06-29 Thread bugzilla-daemon
https://bugzilla.kernel.org/show_bug.cgi?id=208181

Erhard F. (erhar...@mailbox.org) changed:

   What|Removed |Added

 Attachment #289659|0   |1
is obsolete||

--- Comment #2 from Erhard F. (erhar...@mailbox.org) ---
Created attachment 289935
  --> https://bugzilla.kernel.org/attachment.cgi?id=289935=edit
dmesg (5.8-rc3, INLINE KASAN, PowerMac G4 DP

No change with 5.8-rc3.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 208197] OF: /pci@f2000000/mac-io@17/gpio@50/...: could not find phandle

2020-06-15 Thread bugzilla-daemon
https://bugzilla.kernel.org/show_bug.cgi?id=208197

--- Comment #1 from Erhard F. (erhar...@mailbox.org) ---
Created attachment 289687
  --> https://bugzilla.kernel.org/attachment.cgi?id=289687=edit
kernel .config (5.8-rc1, PowerMac G4 DP)

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 208197] New: OF: /pci@f2000000/mac-io@17/gpio@50/...: could not find phandle

2020-06-15 Thread bugzilla-daemon
https://bugzilla.kernel.org/show_bug.cgi?id=208197

Bug ID: 208197
   Summary: OF: /pci@f200/mac-io@17/gpio@50/...: could not
find phandle
   Product: Platform Specific/Hardware
   Version: 2.5
Kernel Version: 5.8-rc1
  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: Yes

Created attachment 289685
  --> https://bugzilla.kernel.org/attachment.cgi?id=289685=edit
dmesg (5.8-rc1, PowerMac G4 DP)

Since 5.8-rc1 I get these OF errors on my PowerMac G4 DP:

[...]
T600 kernel: OF: /pci@f200/mac-io@17/gpio@50/gpio5@6f: could not find
phandle
T600 kernel: OF: /pci@f200/mac-io@17/gpio@50/extint-gpio15@67: could not
find phandle
T600 kernel: OF: /pci@f200/mac-io@17/gpio@50/gpio6@70: could not find
phandle
T600 kernel: OF: /pci@f200/mac-io@17/gpio@50/extint-gpio16@68: could not
find phandle
T600 kernel: OF: /pci@f200/mac-io@17/gpio@50/extint-gpio14@66: could not
find phandle
T600 kernel: OF: /pci@f200/mac-io@17/gpio@50/gpio12@76: could not find
phandle
T600 kernel: OF: /pci@f200/mac-io@17/gpio@50/gpio11@75: could not find
phandle
T600 kernel: OF: /pci@f200/mac-io@17/gpio@50/gpio5@6f: could not find
phandle
T600 kernel: OF: /pci@f200/mac-io@17/gpio@50/gpio6@70: could not find
phandle
T600 kernel: OF: /pci@f200/mac-io@17/gpio@50/extint-gpio4@5c: could not
find phandle
T600 kernel: OF: /pci@f200/mac-io@17/gpio@50/gpio11@75: could not find
phandle
T600 kernel: OF: /pci@f200/mac-io@17/gpio@50/extint-gpio15@67: could not
find phandle[...]

This has not been the case in kernel 5.7 or earlier.

-- 
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

2020-06-15 Thread bugzilla-daemon
https://bugzilla.kernel.org/show_bug.cgi?id=206203

Erhard F. (erhar...@mailbox.org) changed:

   What|Removed |Added

 Attachment #287675|0   |1
is obsolete||

--- Comment #15 from Erhard F. (erhar...@mailbox.org) ---
Created attachment 289679
  --> https://bugzilla.kernel.org/attachment.cgi?id=289679=edit
kernel .config (kernel 5.8-rc1, 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

2020-06-15 Thread bugzilla-daemon
https://bugzilla.kernel.org/show_bug.cgi?id=206203

Erhard F. (erhar...@mailbox.org) changed:

   What|Removed |Added

 Attachment #287673|0   |1
is obsolete||
 Attachment #288567|0   |1
is obsolete||

--- Comment #14 from Erhard F. (erhar...@mailbox.org) ---
Created attachment 289677
  --> https://bugzilla.kernel.org/attachment.cgi?id=289677=edit
dmesg (kernel 5.8-rc1, 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

2020-06-15 Thread bugzilla-daemon
https://bugzilla.kernel.org/show_bug.cgi?id=206203

Erhard F. (erhar...@mailbox.org) changed:

   What|Removed |Added

 Attachment #287671|0   |1
is obsolete||
 Attachment #288565|0   |1
is obsolete||

--- Comment #13 from Erhard F. (erhar...@mailbox.org) ---
Created attachment 289675
  --> https://bugzilla.kernel.org/attachment.cgi?id=289675=edit
kmemleak output (kernel 5.8-rc1, PowerMac G5 11,2)

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 208181] BUG: KASAN: stack-out-of-bounds in strcmp+0x58/0xd8

2020-06-15 Thread bugzilla-daemon
https://bugzilla.kernel.org/show_bug.cgi?id=208181

--- Comment #1 from Erhard F. (erhar...@mailbox.org) ---
Created attachment 289661
  --> https://bugzilla.kernel.org/attachment.cgi?id=289661=edit
kernel .config (5.8-rc1, PowerMac G4 DP)

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 208181] New: BUG: KASAN: stack-out-of-bounds in strcmp+0x58/0xd8

2020-06-15 Thread bugzilla-daemon
https://bugzilla.kernel.org/show_bug.cgi?id=208181

Bug ID: 208181
   Summary: BUG: KASAN: stack-out-of-bounds in strcmp+0x58/0xd8
   Product: Platform Specific/Hardware
   Version: 2.5
Kernel Version: 5.8-rc1
  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 289659
  --> https://bugzilla.kernel.org/attachment.cgi?id=289659=edit
dmesg (5.8-rc1, INLINE KASAN, PowerMac G4 DP)

The G4 DP boots up and is useable, though I get this at early boot:

[...]
Jun 15 11:41:11 T600 kernel: setbat: no BAT available for mapping 0x2a00
Jun 15 11:41:11 T600 kernel: setbat: no BAT available for mapping 0x2c00
Jun 15 11:41:11 T600 kernel: KASAN init done
Jun 15 11:41:11 T600 kernel:
==
Jun 15 11:41:11 T600 kernel: BUG: KASAN: stack-out-of-bounds in
strcmp+0x58/0xd8
Jun 15 11:41:11 T600 kernel: Read of size 1 at addr c11c1a80 by task swapper/0
Jun 15 11:41:11 T600 kernel: 
Jun 15 11:41:11 T600 kernel: CPU: 0 PID: 0 Comm: swapper Not tainted
5.8.0-rc1-PowerMacG4 #2
Jun 15 11:41:11 T600 kernel: Call Trace:
Jun 15 11:41:11 T600 kernel: [c1ae97d0] [c0a2069c] dump_stack+0xfc/0x158
(unreliable)
Jun 15 11:41:11 T600 kernel: [c1ae9800] [c04ac5cc]
print_address_description.isra.0+0x30/0x3fc
Jun 15 11:41:11 T600 kernel: [c1ae9870] [c04acb28] kasan_report+0x110/0x170
Jun 15 11:41:11 T600 kernel: [c1ae98b0] [c0a44c00] strcmp+0x58/0xd8
Jun 15 11:41:11 T600 kernel: [c1ae98d0] [c0170790]
register_lock_class+0xfa4/0x10a0
Jun 15 11:41:11 T600 kernel: [c1ae9990] [c0170a34] __lock_acquire+0x1a8/0x382c
Jun 15 11:41:11 T600 kernel: [c1ae9b40] [c016f398] lock_acquire+0x5e0/0x854
Jun 15 11:41:11 T600 kernel: [c1ae9c00] [c1144014]
_raw_spin_lock_irqsave+0x48/0x70
Jun 15 11:41:11 T600 kernel: [c1ae9c20] [c0ccbe84] of_find_property+0x2c/0x5c
Jun 15 11:41:11 T600 kernel: [c1ae9c50] [c0ccbec8] of_get_property+0x14/0x6c
Jun 15 11:41:11 T600 kernel: [c1ae9c70] [c0cdbcd8]
unflatten_dt_nodes+0xc4c/0xcdc
Jun 15 11:41:11 T600 kernel: [c1ae9ec0] [c0cdbe90]
__unflatten_device_tree+0x114/0x1e0
Jun 15 11:41:11 T600 kernel: [c1ae9ef0] [c184a294]
unflatten_device_tree+0x38/0x54
Jun 15 11:41:11 T600 kernel: [c1ae9f10] [c1808600] setup_arch+0xc8/0x630
Jun 15 11:41:11 T600 kernel: [c1ae9f50] [c1803268] start_kernel+0xcc/0x4cc
Jun 15 11:41:11 T600 kernel: [c1ae9ff0] [38a0] 0x38a0
Jun 15 11:41:11 T600 kernel: 
Jun 15 11:41:11 T600 kernel: The buggy address belongs to the variable:
Jun 15 11:41:11 T600 kernel:  __func__.22122+0x80/0x320
Jun 15 11:41:11 T600 kernel: 
Jun 15 11:41:11 T600 kernel: Memory state around the buggy address:
Jun 15 11:41:11 T600 kernel:  c11c1980: 00 00 00 00 00 00 00 00 00 00 f1 f1 f1
f1 f1 f1
Jun 15 11:41:11 T600 kernel:  c11c1a00: 04 f2 04 f2 04 f2 04 f2 04 f2 00 00 00
04 f2 f2
Jun 15 11:41:11 T600 kernel: >c11c1a80: f2 f2 00 00 00 04 f3 f3 f3 f3 00 00 00
00 00 00
Jun 15 11:41:11 T600 kernel:^
Jun 15 11:41:11 T600 kernel:  c11c1b00: 00 00 00 00 00 00 00 00 00 00 f1 f1 f1
f1 00 00
Jun 15 11:41:11 T600 kernel:  c11c1b80: 00 00 f3 f3 f3 f3 00 00 00 00 00 00 00
00 00 00
Jun 15 11:41:11 T600 kernel:
==
Jun 15 11:41:11 T600 kernel: Disabling lock debugging due to kernel taint
[...]

-- 
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

2020-06-11 Thread bugzilla-daemon
https://bugzilla.kernel.org/show_bug.cgi?id=205183

--- Comment #4 from Daniel Black (dan...@linux.ibm.com) ---
Still broken.

danielgb@talos2:~$ gcc -g -Wall -O stacktest.c
danielgb@talos2:~$  ./a.out 124 &
[1] 494618
danielgb@talos2:~$ cat /proc/$(pidof a.out)/maps | grep stack
7fffcde8-7fffcdfb rw-p  00:00 0 
[stack]
danielgb@talos2:~$ kill -USR1 %1
danielgb@talos2:~$ signal delivered, stack base 0x7fffcdfb top
0x7fffcde81427 (1240025 used)

[1]+  Done./a.out 124
danielgb@talos2:~$ ./a.out 1241000 &
[1] 494677
danielgb@talos2:~$ kill -USR1 %1
danielgb@talos2:~$ 
[1]+  Segmentation fault  ./a.out 1241000
danielgb@talos2:~$ 
danielgb@talos2:~$ dmesg | grep a.out
[10617.616145] a.out[494587]: bad frame in setup_rt_frame: 7fffdea30010 nip
00011a0a09fc lr 7fffa1c404c8
[10865.752876] a.out[494677]: bad frame in setup_rt_frame: 7fffcc420030 nip
000135a70a3c lr 7fff952604c8
danielgb@talos2:~$ uname -a
Linux talos2 5.7.0-rc5-77151-gfea086b627a0 #1 SMP Mon May 11 16:00:00 AEST 2020
ppc64le ppc64le ppc64le GNU/Linux

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 207873] BUG at swapops + rcu stall + soft lockup at running btrfs test suite (TEST=013\* ./misc-tests.sh)

2020-05-24 Thread bugzilla-daemon
https://bugzilla.kernel.org/show_bug.cgi?id=207873

Erhard F. (erhar...@mailbox.org) changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |PATCH_ALREADY_AVAILABLE

--- Comment #6 from Erhard F. (erhar...@mailbox.org) ---
(In reply to Christophe Leroy from comment #5)
> Try
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/
> ?id=40bb0e904212cf7d6f041a98c58c8341b2016670
Thanks for the hint! That patch did the trick. The btrfs test suite completes
fine now and building larger projects works unremarkably. 

Will close here as the fix seems to be going into -rc7.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 207873] BUG at swapops + rcu stall + soft lockup at running btrfs test suite (TEST=013\* ./misc-tests.sh)

2020-05-24 Thread bugzilla-daemon
https://bugzilla.kernel.org/show_bug.cgi?id=207873

Christophe Leroy (christophe.le...@c-s.fr) changed:

   What|Removed |Added

 CC||christophe.le...@c-s.fr

--- Comment #5 from Christophe Leroy (christophe.le...@c-s.fr) ---
Try
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=40bb0e904212cf7d6f041a98c58c8341b2016670

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 207873] BUG at swapops + rcu stall + soft lockup at running btrfs test suite (TEST=013\* ./misc-tests.sh)

2020-05-23 Thread bugzilla-daemon
https://bugzilla.kernel.org/show_bug.cgi?id=207873

--- Comment #4 from Erhard F. (erhar...@mailbox.org) ---
Created attachment 289261
  --> https://bugzilla.kernel.org/attachment.cgi?id=289261=edit
transcript of both screenshots

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 207873] BUG at swapops + rcu stall + soft lockup at running btrfs test suite (TEST=013\* ./misc-tests.sh)

2020-05-23 Thread bugzilla-daemon
https://bugzilla.kernel.org/show_bug.cgi?id=207873

--- Comment #3 from Erhard F. (erhar...@mailbox.org) ---
Created attachment 289259
  --> https://bugzilla.kernel.org/attachment.cgi?id=289259=edit
screenshot 02

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 207873] BUG at swapops + rcu stall + soft lockup at running btrfs test suite (TEST=013\* ./misc-tests.sh)

2020-05-23 Thread bugzilla-daemon
https://bugzilla.kernel.org/show_bug.cgi?id=207873

--- Comment #2 from Erhard F. (erhar...@mailbox.org) ---
Created attachment 289257
  --> https://bugzilla.kernel.org/attachment.cgi?id=289257=edit
screenshot 01

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 207873] BUG at swapops + rcu stall + soft lockup at running btrfs test suite (TEST=013\* ./misc-tests.sh)

2020-05-23 Thread bugzilla-daemon
https://bugzilla.kernel.org/show_bug.cgi?id=207873

--- Comment #1 from Erhard F. (erhar...@mailbox.org) ---
Created attachment 289255
  --> https://bugzilla.kernel.org/attachment.cgi?id=289255=edit
kernel dmesg (5.7-rc6, PowerMac G4 DP)

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 207873] New: BUG at swapops + rcu stall + soft lockup at running btrfs test suite (TEST=013\* ./misc-tests.sh)

2020-05-23 Thread bugzilla-daemon
https://bugzilla.kernel.org/show_bug.cgi?id=207873

Bug ID: 207873
   Summary: BUG at swapops + rcu stall + soft lockup at running
btrfs test suite (TEST=013\* ./misc-tests.sh)
   Product: Platform Specific/Hardware
   Version: 2.5
Kernel Version: 5.7-rc6
  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: fs_bt...@kernel-bugs.osdl.org
Regression: No

Created attachment 289253
  --> https://bugzilla.kernel.org/attachment.cgi?id=289253=edit
kernel .config (5.7-rc6, PowerMac G4 DP)

The bug is triggered by running "TEST=013\* ./misc-tests.sh" of btrfs-progs
test suite, built from git master:

 # git clone https://github.com/kdave/btrfs-progs && cd btrfs-progs/
 # ./autogen.sh && ./configure --disable-documentation
 # make && make fssum
 # cd tests/
 # TEST=013\* ./misc-tests.sh

The G4 crashes and the reboot timer kicks in. Before it shows a series of stack
traces, starting with the "kernel BUG at include/linux/swapops.h:197!"-part
from bug #207221. After that I get an rcu stall and a soft lockup. For the full
stacktrace have a look at the transcript of both screenshots.

[...]
rcu: INFO: rcu_sched self-detected stall on CPU
rcu: o1-: (7799 ticks this GP) idle=a06/1/0x4002 soft irq=11075/11075
fqs=2599
o(t=7804 jiffies g=21629 q=59)
Task dump for CPU 1:
dd  R  running task0  2200394 0x000c
Call Trace:
[f49fb458] [c00fcddc] sched_show_task+0x3bc/Ox3fe (unreliable)
[f49fb498] [c01c650c] rcu_dump_cpu_stacks+0x228/0x23c
[f49fb4e8] [c01c2e18] rcu_sched_clock_irq+0x81c/0x1360
[f49fb568] [c01d8940] update_process_times+0x2c/0x98
[f49fb588] [c02027d4] tick_sched_timer+0x128/0x1d8
[f49fb5a8] [c01dc49c] __hrtimer_run_queues+0x490/Oxae8
[f49fb698] [c01dd788] hrtimer_interrupt+0x278/0x520
[f49fb6f8] [c001710c] timer_interrupt+0x374/0xb4c
[f49fb738] [c002c5e4] ret_from_except+0x0/0x14
--- interrupt: 901 at do_raw_spin_lock+0x1c8/0x2cc
LR = do_raw_spin_lock+0x1a4/0x2cc
[f49fb800] [c0180e0c] do_raw_spin_lock+0x188/0x2cc (unrelable)
[f49fb830] [c0428890] unmap_page_range+0x244/0xb08
[f49fb910] [c0429610] unmap_vmas+0x94/0xdc
[f49fb930] [c043c25c] exit_mmap+0x340/0x46c
[f49fba20] [c0078260] __mmput+0x78/0x360
[f49fba50] [c0090514] do_exit+0x9c4/0x21fc
[f49fbb20] [c0019d38] user_single_step_report+0x0/0x74
[f49fbb70] [c002c5e0] ret_from_except+0x0/0x4
--- interrupt: 700 at __migration_entry_wait+0x13c/0x198
LR = __migration_entry_wait+0xf0/0x198
[f49fbc58] [c042c0f0] do_swap_page+0x1f0/0x198
[f49fbd28] [c042e7e4] handle_mm_fault+0x794/0x16f4
[f49fbe48] [c0039868] do_page_fault+0xf50/0x12f8
[f49fbf38] [c002c468] handle_page_fault+0x10/0x3c
--- interrupt: 301 at 0x87e378
LR = 0x87e33c
[...]

I don't know wether this is a btrfs bug, or a bug only triggered by this
specific test. So I am filing this as platform specific as I have not seen it
on x86 yet.

Unlike bug #207221 KASAN is enabled here, so the stack trace looks slightly
different.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 207359] MegaRAID SAS 9361 controller hang/reset

2020-05-09 Thread bugzilla-daemon
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=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 104871] bcl+8 in arch/powerpc/kernel/vdso64/datapage.S causes branch prediction issues

2020-04-27 Thread bugzilla-daemon
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 104871] bcl+8 in arch/powerpc/kernel/vdso64/datapage.S causes branch prediction issues

2020-04-27 Thread bugzilla-daemon
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 199471] [Bisected][Regression] windfarm_pm* no longer gets automatically loaded when CONFIG_I2C_POWERMAC=y is set

2020-04-27 Thread bugzilla-daemon
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 199471] [Bisected][Regression] windfarm_pm* no longer gets automatically loaded when CONFIG_I2C_POWERMAC=y is set

2020-04-27 Thread bugzilla-daemon
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 206695] kmemleak reports leaks in drivers/macintosh/windfarm

2020-04-26 Thread bugzilla-daemon
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

2020-04-24 Thread bugzilla-daemon
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 199471] [Bisected][Regression] windfarm_pm* no longer gets automatically loaded when CONFIG_I2C_POWERMAC=y is set

2020-04-24 Thread bugzilla-daemon
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

2020-04-23 Thread bugzilla-daemon
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 206695] kmemleak reports leaks in drivers/macintosh/windfarm

2020-04-23 Thread bugzilla-daemon
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 206695] kmemleak reports leaks in drivers/macintosh/windfarm

2020-04-23 Thread bugzilla-daemon
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

2020-04-23 Thread bugzilla-daemon
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 199471] [Bisected][Regression] windfarm_pm* no longer gets automatically loaded when CONFIG_I2C_POWERMAC=y is set

2020-04-23 Thread bugzilla-daemon
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 199471] [Bisected][Regression] windfarm_pm* no longer gets automatically loaded when CONFIG_I2C_POWERMAC=y is set

2020-04-22 Thread bugzilla-daemon
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

2020-04-22 Thread bugzilla-daemon
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>] 

[Bug 207359] MegaRAID SAS 9361 controller hang/reset

2020-04-19 Thread bugzilla-daemon
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 207359] MegaRAID SAS 9361 controller hang/reset

2020-04-19 Thread bugzilla-daemon
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] New: MegaRAID SAS 9361 controller hang/reset

2020-04-19 Thread bugzilla-daemon
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=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 206203] kmemleak reports various leaks in drivers/of/unittest.c

2020-04-17 Thread bugzilla-daemon
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=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 206203] kmemleak reports various leaks in drivers/of/unittest.c

2020-04-17 Thread bugzilla-daemon
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=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 205099] KASAN hit at raid6_pq: BUG: Unable to handle kernel data access at 0x00f0fd0d

2020-04-13 Thread bugzilla-daemon
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=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 205099] KASAN hit at raid6_pq: BUG: Unable to handle kernel data access at 0x00f0fd0d

2020-04-13 Thread bugzilla-daemon
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=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 207129] PowerMac G4 DP (5.6.2 debug kernel + inline KASAN) freezes shortly after booting with "do_IRQ: stack overflow: 1760"

2020-04-08 Thread bugzilla-daemon
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 207129] PowerMac G4 DP (5.6.2 debug kernel + inline KASAN) freezes shortly after booting with "do_IRQ: stack overflow: 1760"

2020-04-08 Thread bugzilla-daemon
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"

2020-04-06 Thread bugzilla-daemon
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"

2020-04-06 Thread bugzilla-daemon
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=edit
screenshot02.jpg

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

  1   2   3   4   5   >