[Bug 215389] pagealloc: memory corruption at building glibc-2.33 and running its' testsuite

2022-05-12 Thread bugzilla-daemon
https://bugzilla.kernel.org/show_bug.cgi?id=215389

--- Comment #19 from Christophe Leroy (christophe.le...@csgroup.eu) ---
Yes KASAN can bring some additional inputs.
Maybe start with CONFIG_KFENCE, it is lighter than KASAN.


For the above problem, maybe CONFIG_DEBUG_STACKOVERFLOW can help.

-- 
You may reply to this email to add a comment.

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

[Bug 215389] pagealloc: memory corruption at building glibc-2.33 and running its' testsuite

2022-05-11 Thread bugzilla-daemon
https://bugzilla.kernel.org/show_bug.cgi?id=215389

--- Comment #18 from Erhard F. (erhar...@mailbox.org) ---
Ok, and another problem during building via distcc on the G4, still
LOWMEM_SIZE=0x2800 (kernel v5.17.6).

[...]
Oops: Kernel stack overflow, sig: 11 [#1]
BE PAGE_SIZE=4K MMU=Hash SMP NR_CPUS=2 PowerMac
Modules linked in: auth_rpcgss nfsv4 dns_resolver nfs lockd grace sunrpc
ghash_generic gf128mul gcm ccm algif_aead des_generic libdes ctr cbc ecb
algif_skcipher aes_generic libaes cmac sha512_generic sha1_generic sha1_powerpc
md5 md5_ppc md4 hid_generic b43legacy usbhid mac80211 hid libarc4 cfg80211
snd_aoa_codec_tas rfkill snd_aoa_fabric_layout snd_aoa evdev mac_hid
therm_windtunnel firewire_ohci firewire_core crc_itu_t sr_mod cdrom ohci_pci
8250_pci radeon snd_aoa_i2sbus ohci_hcd snd_aoa_soundbus ssb snd_pcm ehci_pci
snd_timer pcmcia snd soundcore pcmcia_core hwmon 8250 ehci_hcd i2c_algo_bit
8250_base drm_ttm_helper serial_mctrl_gpio ttm drm_kms_helper usbcore
syscopyarea sysfillrect sysimgblt usb_common fb_sys_fops pkcs8_key_parser fuse
drm drm_panel_orientation_quirks configfs
CPU: 0 PID: 24122 Comm: sh Not tainted 5.17.6-gentoo-PMacG4 #1
NIP:  c0018614 LR:  CTR: c103cbe0
REGS: e7fe9f50 TRAP:    Not tainted  (5.17.6-gentoo-PMacG4)
MSR:  1030   CR: 0001  XER: c000e234

GPR00: a78bfe90 80002288  d6a5e1a0 e991de60 0068c6c4 a7a3ff98 c1099000 
GPR08:  e991dec0 d6a5e1a0 80002288 005900d0 0068fff4  0007 
GPR16: 0029 0007 00bc44b0 a7ddafe8 a78bfe90 f000   
GPR24: 005900d0 0068c6c4 c0dcc7a0 c1402b48 caa899c0 c103cbe0 c4ce9400 c08fe234 
NIP [c0018614] interrupt_return+0x17c/0x190
LR [] 0x0
Call Trace:
Instruction dump:
40860018 7ccff120 80c10028 80010010 80210014 4c64 7ccff120 7d3043a6 
392100c0 80c10028 80010010 80210014 <9121> 7d3042a6 4c64 7c000828 
---[ end trace  ]---


@Christophe: Would it be helpful for these issues to try a KASAN build?

-- 
You may reply to this email to add a comment.

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

[Bug 215389] pagealloc: memory corruption at building glibc-2.33 and running its' testsuite

2022-05-11 Thread bugzilla-daemon
https://bugzilla.kernel.org/show_bug.cgi?id=215389

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

   What|Removed |Added

 Attachment #300775|0   |1
is obsolete||

--- Comment #17 from Erhard F. (erhar...@mailbox.org) ---
Created attachment 300930
  --> https://bugzilla.kernel.org/attachment.cgi?id=300930=edit
kernel .config (5.18-rc6, CONFIG_LOWMEM_SIZE=0x2800, PowerMac G4 DP)

-- 
You may reply to this email to add a comment.

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

[Bug 215389] pagealloc: memory corruption at building glibc-2.33 and running its' testsuite

2022-05-11 Thread bugzilla-daemon
https://bugzilla.kernel.org/show_bug.cgi?id=215389

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

   What|Removed |Added

 Attachment #300774|0   |1
is obsolete||

--- Comment #16 from Erhard F. (erhar...@mailbox.org) ---
Created attachment 300929
  --> https://bugzilla.kernel.org/attachment.cgi?id=300929=edit
dmesg (5.18-rc6, CONFIG_LOWMEM_SIZE=0x2800, PowerMac G4 DP)

(In reply to Christophe Leroy from comment #14)
> Do you mean it still happens with the default values, or it also happens
> with the reduced CONFIG_LOWMEM_SIZE ?
Turns out the memory corruption also happens with the reduced
CONFIG_LOWMEM_SIZE=0x2800.

Tested again on v5.18-rc6, both with CONFIG_LOWMEM_SIZE=0x2800 and without.

-- 
You may reply to this email to add a comment.

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

[Bug 215389] pagealloc: memory corruption at building glibc-2.33 and running its' testsuite

2022-05-02 Thread bugzilla-daemon
https://bugzilla.kernel.org/show_bug.cgi?id=215389

--- Comment #15 from Erhard F. (erhar...@mailbox.org) ---
It definitively still happens with the default values. Can test with the
reduced CONFIG_LOWMEM_SIZE next week and report back.

-- 
You may reply to this email to add a comment.

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

[Bug 215389] pagealloc: memory corruption at building glibc-2.33 and running its' testsuite

2022-05-02 Thread bugzilla-daemon
https://bugzilla.kernel.org/show_bug.cgi?id=215389

--- Comment #14 from Christophe Leroy (christophe.le...@csgroup.eu) ---
Do you mean it still happens with the default values, or it also happens with
the reduced CONFIG_LOWMEM_SIZE ?

-- 
You may reply to this email to add a comment.

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

[Bug 215862] New: clang-14 fails 5.18-rc3 ppc64 BE kernel build - :0: error: expected relocatable expression

2022-04-18 Thread bugzilla-daemon
https://bugzilla.kernel.org/show_bug.cgi?id=215862

Bug ID: 215862
   Summary: clang-14 fails 5.18-rc3 ppc64 BE kernel build -
:0: error: expected relocatable expression
   Product: Platform Specific/Hardware
   Version: 2.5
Kernel Version: 5.18-rc3
  Hardware: PPC-64
OS: Linux
  Tree: Mainline
Status: NEW
  Severity: normal
  Priority: P1
 Component: PPC-64
  Assignee: platform_ppc...@kernel-bugs.osdl.org
  Reporter: erhar...@mailbox.org
Regression: No

Created attachment 300776
  --> https://bugzilla.kernel.org/attachment.cgi?id=300776=edit
kernel .config (kernel 5.18-rc3, Talos II)

# make LLVM=1
[...]
  AR  usr/built-in.a
  CC  arch/powerpc/kernel/ptrace/ptrace.o
  CC  arch/powerpc/kernel/ptrace/ptrace-view.o
  CC  arch/powerpc/kernel/ptrace/ptrace-fpu.o
  CC  arch/powerpc/kernel/ptrace/ptrace32.o
  CC  arch/powerpc/kernel/ptrace/ptrace-vsx.o
  CC  arch/powerpc/kernel/ptrace/ptrace-altivec.o
  CC  arch/powerpc/kernel/ptrace/ptrace-tm.o
  CC  arch/powerpc/kernel/ptrace/ptrace-noadv.o
  AR  arch/powerpc/kernel/ptrace/built-in.a
  AR  arch/powerpc/kernel/trace/built-in.a
  AS  arch/powerpc/kernel/head_64.o
:0: error: expected relocatable expression
make[2]: *** [scripts/Makefile.build:389: arch/powerpc/kernel/head_64.o] Fehler
1
make[1]: *** [scripts/Makefile.build:550: arch/powerpc/kernel] Fehler 2
make: *** [Makefile:1834: arch/powerpc] Fehler 2

Toolchain used was llvm/clang/lld-14.0.1. Same kernel builds fine with
gcc-11.2, binutils-2.37.

-- 
You may reply to this email to add a comment.

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

[Bug 215389] pagealloc: memory corruption at building glibc-2.33 and running its' testsuite

2022-04-18 Thread bugzilla-daemon
https://bugzilla.kernel.org/show_bug.cgi?id=215389

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

-- 
You may reply to this email to add a comment.

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

[Bug 215389] pagealloc: memory corruption at building glibc-2.33 and running its' testsuite

2022-04-18 Thread bugzilla-daemon
https://bugzilla.kernel.org/show_bug.cgi?id=215389

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

Another try with running glibc-2.34 testsuite on kernel 5.18-rc3. Looks like
it's still a problem.

[...]
pagealloc: memory corruption
fffdfff0: 00 00 00 00  
CPU: 0 PID: 21222 Comm: install Not tainted 5.18.0-rc3-PMacG4 #5
Call Trace:
[f8085a70] [c06e8820] dump_stack_lvl+0x80/0xc0 (unreliable)
[f8085a90] [c02c0b2c] __kernel_unpoison_pages+0x1c0/0x204
[f8085ae0] [c02a4cb0] get_page_from_freelist+0xcb4/0xeb0
[f8085ba0] [c02a5754] __alloc_pages+0x184/0x11b4
[f8085c70] [c0230d50] __filemap_get_folio+0x224/0x598
[f8085cf0] [c0240ebc] pagecache_get_page+0x20/0x88
[f8085d10] [c04e2600] prepare_pages+0xf8/0x358
[f8085d60] [c04e4e54] btrfs_buffered_write+0x334/0x850
[f8085e20] [c04ea598] btrfs_do_write_iter+0x3a8/0x768
[f8085e80] [c02ee25c] vfs_write+0x364/0x488
[f8085f00] [c02ee52c] ksys_write+0x78/0x128
[f8085f30] [c001e1a8] ret_from_syscall+0x0/0x2c
--- interrupt: c00 at 0x5c5d08
NIP:  005c5d08 LR: 005c5ce0 CTR: c0289c9c
REGS: f8085f40 TRAP: 0c00   Not tainted  (5.18.0-rc3-PMacG4)
MSR:  f932   CR: 28022464  XER: 2000

GPR00: 0004 af820720 a7ced760 0006 a77aa000 0002   
GPR08: 0012 a77a9000 0008 403d77ca 403d7497 0077fff4  0002 
GPR16:  af8208c8 0002   af821d2b a77aa000 0002 
GPR24:  0006 7ff0 0006 a77aa000 0002 006c7ff4 0002 
NIP [005c5d08] 0x5c5d08
LR [005c5ce0] 0x5c5ce0
--- interrupt: c00
page:ef4c4ec4 refcount:1 mapcount:0 mapping: index:0x1 pfn:0x31069
flags: 0x8000(zone=2)
raw: 8000 0100 0122  0001   0001
raw: 
page dumped because: pagealloc: corrupted page detail

-- 
You may reply to this email to add a comment.

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

[Bug 215781] Highmem support broken on kernels greater 5.15.x on ppc32?

2022-04-18 Thread bugzilla-daemon
https://bugzilla.kernel.org/show_bug.cgi?id=215781

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

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |CODE_FIX

-- 
You may reply to this email to add a comment.

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

[Bug 215781] Highmem support broken on kernels greater 5.15.x on ppc32?

2022-04-18 Thread bugzilla-daemon
https://bugzilla.kernel.org/show_bug.cgi?id=215781

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

Meanwhile the fixes landed in 5.16.x, 5.17.x and 5.18-rc3 is also ok. Thanks!

-- 
You may reply to this email to add a comment.

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

[Bug 215803] ppc64le(P9): BUG: Kernel NULL pointer dereference on read at 0x00000060 NIP: do_remove_conflicting_framebuffers+0x184/0x1d0

2022-04-12 Thread bugzilla-daemon
https://bugzilla.kernel.org/show_bug.cgi?id=215803

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

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||mich...@ellerman.id.au
 Resolution|--- |CODE_FIX

--- Comment #5 from Michael Ellerman (mich...@ellerman.id.au) ---
This was reported to the patch author here:

  https://lore.kernel.org/all/YkHXO6LGHAN0p1pq@debian/

And there is a fix here:

  https://patchwork.freedesktop.org/patch/480648/

-- 
You may reply to this email to add a comment.

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

[Bug 215803] ppc64le(P9): BUG: Kernel NULL pointer dereference on read at 0x00000060 NIP: do_remove_conflicting_framebuffers+0x184/0x1d0

2022-04-10 Thread bugzilla-daemon
https://bugzilla.kernel.org/show_bug.cgi?id=215803

--- Comment #4 from Daniel Kolesa (li...@octaforge.org) ---
Also, just to be clear, reverting the commit I linked above does fix the
problem for me. Here is a patch you can quickly test:
https://gist.github.com/q66/da01b4baecfdc24cd8fa3253d4e7f05a

-- 
You may reply to this email to add a comment.

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

[Bug 215803] ppc64le(P9): BUG: Kernel NULL pointer dereference on read at 0x00000060 NIP: do_remove_conflicting_framebuffers+0x184/0x1d0

2022-04-10 Thread bugzilla-daemon
https://bugzilla.kernel.org/show_bug.cgi?id=215803

--- Comment #3 from Daniel Kolesa (li...@octaforge.org) ---
It does not panic in my case though; I merely get stuck with the offb
framebuffer console instead of it switching modes to the right thing

-- 
You may reply to this email to add a comment.

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

[Bug 215803] ppc64le(P9): BUG: Kernel NULL pointer dereference on read at 0x00000060 NIP: do_remove_conflicting_framebuffers+0x184/0x1d0

2022-04-10 Thread bugzilla-daemon
https://bugzilla.kernel.org/show_bug.cgi?id=215803

Daniel Kolesa (li...@octaforge.org) changed:

   What|Removed |Added

 CC||li...@octaforge.org

--- Comment #2 from Daniel Kolesa (li...@octaforge.org) ---
This now hits 5.15.33. I noticed this when virtio-gpu failed to come up.

Commit:
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/drivers/video/fbdev/core?h=linux-5.15.y=c894ac44786cfed383a6c6b20c1bfb12eb96018a

More detailed backtrace:
https://gist.github.com/q66/6ffc1bd18cf241e6ad894dc4409a2f72

This is also on a ppc64le system. However, I think this bug may not be ppc64
specific...

-- 
You may reply to this email to add a comment.

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

[Bug 215803] ppc64le(P9): BUG: Kernel NULL pointer dereference on read at 0x00000060 NIP: do_remove_conflicting_framebuffers+0x184/0x1d0

2022-04-04 Thread bugzilla-daemon
https://bugzilla.kernel.org/show_bug.cgi?id=215803

--- Comment #1 from Zorro Lang (zl...@redhat.com) ---
Created attachment 300697
  --> https://bugzilla.kernel.org/attachment.cgi?id=300697=edit
kernel .config file

-- 
You may reply to this email to add a comment.

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

[Bug 215803] New: ppc64le(P9): BUG: Kernel NULL pointer dereference on read at 0x00000060 NIP: do_remove_conflicting_framebuffers+0x184/0x1d0

2022-04-04 Thread bugzilla-daemon
https://bugzilla.kernel.org/show_bug.cgi?id=215803

Bug ID: 215803
   Summary: ppc64le(P9):  BUG: Kernel NULL pointer dereference on
read at 0x0060  NIP:
do_remove_conflicting_framebuffers+0x184/0x1d0
   Product: Platform Specific/Hardware
   Version: 2.5
Kernel Version: 5.18-rc1
  Hardware: All
OS: Linux
  Tree: Mainline
Status: NEW
  Severity: normal
  Priority: P1
 Component: PPC-64
  Assignee: platform_ppc...@kernel-bugs.osdl.org
  Reporter: zl...@redhat.com
Regression: No

When I test latest linux kernel, it panic[1] directly when I  just tried to
boot it on ppc64le. I hit it several times on different ppc64le machines, same
call trace. Due to I only hit this panic on ppc64le, so I report this bug to
ppc64 to get more review.

The linux kernel HEAD is (nearly 5.18-rc1):

commit be2d3ecedd9911fbfd7e55cc9ceac5f8b79ae4cf
Author: Linus Torvalds 
Date:   Sat Apr 2 12:57:17 2022 -0700

Merge tag 'perf-tools-for-v5.18-2022-04-02' of
git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux


[1]
[   18.785170] RPC: Registered named UNIX socket transport module. 
[   18.785214] RPC: Registered udp transport module. 
[   18.785235] RPC: Registered tcp transport module. 
[   18.785256] RPC: Registered tcp NFSv4.1 backchannel transport module. 
[  
  OK 
] Mounted 
RPC Pipe File System   
. 
[  
  OK 
] Reached target 
rpc_pipefs.target   
. 
[   18.830598] fb0: switching to ast from OFfb vga 
[   18.830646] BUG: Kernel NULL pointer dereference on read at 0x0060 
[   18.830669] Faulting instruction address: 0xc09fd974 
[   18.830692] Oops: Kernel access of bad area, sig: 7 [#1] 
[   18.830712] LE PAGE_SIZE=64K MMU=Radix SMP NR_CPUS=2048 NUMA PowerNV 
[   18.830734] Modules linked in: ast(+) i2c_algo_bit sunrpc drm_vram_helper
drm_ttm_helper ttm drm_kms_helper fb_sys_fops syscopyarea sysfillrect ofpart
sysimgblt ses enclosure powernv_flash ipmi_powernv at24 ipmi_devintf ext4
opal_prd mtd scsi_transport_sas ibmpowernv regmap_i2c ipmi_msghandler mbcache
jbd2 drm fuse drm_panel_orientation_quirks xfs libcrc32c sd_mod t10_pi
crc64_rocksoft_generic crc64_rocksoft crc64 sg i40e vmx_crypto aacraid 
[   18.830875] CPU: 0 PID: 963 Comm: kworker/0:2 Not tainted 5.17.0+ #1 
[   18.830906] Workqueue: events work_for_cpu_fn 
[   18.830930] NIP:  c09fd974 LR: c09fd96c CTR:
 
[   18.830961] REGS: c001156db740 TRAP: 0300   Not tainted  (5.17.0+) 
[   18.830981] MSR:  90009033   CR: 48028222 
XER:  
[   18.831022] CFAR: c022a9ec DAR: 0060 DSISR: 0008
IRQMASK: 0  
[   18.831022] GPR00: c09fd96c c001156db9e0 c2d06200
0023  
[   18.831022] GPR04:  c001156db730 c001156db728
  
[   18.831022] GPR08: 0027 c2be6200 c00115751000
0001  
[   18.831022] GPR12: 001ff190 c512 c0194608
c00020001119b000  
[   18.831022] GPR16:   
  
[   18.831022] GPR20:   c144c560
c144c588  
[   18.831022] GPR24: 0001 000a c008166c1200
c0010f0dbf60  
[   18.831022] GPR28: c2d65038 c00020001ecc0380 
c2d64f40  
[   18.831234] NIP [c09fd974]
do_remove_conflicting_framebuffers+0x184/0x1d0 
[   18.831267] LR [c09fd96c]
do_remove_conflicting_framebuffers+0x17c/0x1d0 
[   18.831299] Call Trace: 
[   18.831314] [c001156db9e0] [c09fd96c]
do_remove_conflicting_framebuffers+0x17c/0x1d0 (unreliable) 
[   18.831351] [c001156dbab0] [c09fdf34]
remove_conflicting_framebuffers+0x64/0x160 
[   18.831385] [c001156dbb00] [c00814ed05a8]
drm_aperture_remove_conflicting_framebuffers+0x80/0xf0 [drm] 
[   18.831439] [c001156dbb50] [c008166b0238] ast_pci_probe+0x60/0x130
[ast] 
[   18.831474] [c001156dbb90] [c09b39c8] local_pci_probe+0x68/0x110 
[   18.831508] [c001156dbc10] [c017f038] work_for_cpu_fn+0x38/0x60 
[   18.831540] [c001156dbc40] [c0185608]
process_one_work+0x348/0x850 
[   18.831574] [c001156dbd30] [c0185d70] worker_thread+0x260/0x500 
[   18.831605] [c001156dbdc0] [c0194748] kthread+0x148/0x150 
[   18.831627] [c001156dbe10] [c000cbf4]
ret_from_kernel_thread+0x5c/0x64 
[   18.831661] Instruction dump: 
[   18.831679] 7d710120 7d708120 4e800020 e8df 7fc407b4 7f45d378 7ec3b378
f8810068  
[   18.831716] 38c601f0 4b82d03d 6000 3d22ffee  3929ee90 e8810068
7c2a4800  
[   18.831755] ---[ end trace  ]--- 
[   18.958634]  
[   18.958701] kworker/0:2 (963) used greatest stack depth: 7056 bytes left 
[  
  OK 
] Started   

[Bug 215781] Highmem support broken on kernels greater 5.15.x on ppc32?

2022-03-31 Thread bugzilla-daemon
https://bugzilla.kernel.org/show_bug.cgi?id=215781

--- Comment #4 from Christophe Leroy (christophe.le...@csgroup.eu) ---
This problem was introduced in 5.15 by commit 602946ec2f90 ("powerpc: Set
max_mapnr correctly")

A similar issue has been opened at
https://github.com/linuxppc/issues/issues/399

Following series should fix it:
https://patchwork.ozlabs.org/project/linuxppc-dev/list/?state=*=286464

-- 
You may reply to this email to add a comment.

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

[Bug 215781] Highmem support broken on kernels greater 5.15.x on ppc32?

2022-03-30 Thread bugzilla-daemon
https://bugzilla.kernel.org/show_bug.cgi?id=215781

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

-- 
You may reply to this email to add a comment.

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

[Bug 215781] Highmem support broken on kernels greater 5.15.x on ppc32?

2022-03-30 Thread bugzilla-daemon
https://bugzilla.kernel.org/show_bug.cgi?id=215781

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

-- 
You may reply to this email to add a comment.

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

[Bug 215781] Highmem support broken on kernels greater 5.15.x on ppc32?

2022-03-30 Thread bugzilla-daemon
https://bugzilla.kernel.org/show_bug.cgi?id=215781

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

-- 
You may reply to this email to add a comment.

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

[Bug 215781] New: Highmem support broken on kernels greater 5.15.x on ppc32?

2022-03-30 Thread bugzilla-daemon
https://bugzilla.kernel.org/show_bug.cgi?id=215781

Bug ID: 215781
   Summary: Highmem support broken on kernels greater 5.15.x on
ppc32?
   Product: Platform Specific/Hardware
   Version: 2.5
Kernel Version: 5.16.18
  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 300664
  --> https://bugzilla.kernel.org/attachment.cgi?id=300664=edit
dmesg (5.16.18, PowerMac G4 DP)

Noticed my G4 DP ran a bit sluggish... Turned out it uses only 614664K of
2097152K RAM. Happens on both kernel 5.16.18 and 5.17.1. Kernels 5.15 and
before work as expected.

It seems to be a problem with highmem as 5.16.18 and 5.1.7.1 show 0K highmem.
CONFIG_HIGHMEM=y is of course set.

Kernel 5.16.18 says:
[...]
Top of RAM: 0x8000, Total RAM: 0x8000
Memory hole size: 0MB
Zone ranges:
  DMA  [mem 0x-0x27ff]
  Normal   empty
  HighMem  [mem 0x2800-0x7fff]
Movable zone start for each node
Early memory node ranges
  node   0: [mem 0x-0x7fff]
Initmem setup node 0 [mem 0x-0x7fff]
percpu: Embedded 12 pages/cpu s19404 r8192 d21556 u49152
pcpu-alloc: s19404 r8192 d21556 u49152 alloc=12*4096
pcpu-alloc: [0] 0 [0] 1 
Built 1 zonelists, mobility grouping on.  Total pages: 522848
Kernel command line: ro root=/dev/sda5 zswap.max_pool_percent=16
zswap.zpool=z3fold slub_debug=FZP page_poison=1
netconsole=@192.168.2.5/eth0,@192.168.2.2/70:85:C2:30:EC:01 
Dentry cache hash table entries: 131072 (order: 7, 524288 bytes, linear)
Inode-cache hash table entries: 65536 (order: 6, 262144 bytes, linear)
mem auto-init: stack:__user(zero), heap alloc:off, heap free:off
Kernel virtual memory layout:
  * 0xffbbf000..0xf000  : fixmap
  * 0xff40..0xff80  : highmem PTEs
  * 0xff115000..0xff40  : early ioremap
  * 0xe900..0xff115000  : vmalloc & ioremap
  * 0xb000..0xc000  : modules
Memory: 614664K/2097152K available (8828K kernel code, 488K rwdata, 1664K
rodata, 1316K init, 381K bss, 1482488K reserved, 0K cma-reserved, 0K highmem)
[...]

On kernel 5.15.23 I got highmem as expected:
[...]
Top of RAM: 0x8000, Total RAM: 0x8000
Memory hole size: 0MB
Zone ranges:
  DMA  [mem 0x-0x27ff]
  Normal   empty
  HighMem  [mem 0x2800-0x7fff]
Movable zone start for each node
Early memory node ranges
  node   0: [mem 0x-0x7fff]
Initmem setup node 0 [mem 0x-0x7fff]
percpu: Embedded 12 pages/cpu s19404 r8192 d21556 u49152
pcpu-alloc: s19404 r8192 d21556 u49152 alloc=12*4096
pcpu-alloc: [0] 0 [0] 1 
Built 1 zonelists, mobility grouping on.  Total pages: 522848
Kernel command line: ro root=/dev/sda5 zswap.max_pool_percent=16
zswap.zpool=z3fold slub_debug=FZP page_poison=1
netconsole=@192.168.2.5/eth0,@192.168.2.2/70:85:C2:30:EC:01 
Dentry cache hash table entries: 131072 (order: 7, 524288 bytes, linear)
Inode-cache hash table entries: 65536 (order: 6, 262144 bytes, linear)
mem auto-init: stack:__user(zero), heap alloc:off, heap free:off
Kernel virtual memory layout:
  * 0xffbbf000..0xf000  : fixmap
  * 0xff40..0xff80  : highmem PTEs
  * 0xff115000..0xff40  : early ioremap
  * 0xe900..0xff115000  : vmalloc & ioremap
  * 0xb000..0xc000  : modules
Memory: 2056460K/2097152K available (8688K kernel code, 488K rwdata, 1644K
rodata, 1316K init, 377K bss, 40692K reserved, 0K cma-reserved, 1441792K
highmem)
[...]

For testing I used the kernel .config from 5.15.32 for 5.16.18 via make
oldconfig and selecting =n for all questions.

-- 
You may reply to this email to add a comment.

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

[Bug 215652] kernel 5.17-rc fail to load radeon DRM "modprobe: ERROR: could not insert 'radeon': Unknown symbol in module, or unknown parameter (see dmesg)"

2022-03-17 Thread bugzilla-daemon
https://bugzilla.kernel.org/show_bug.cgi?id=215652

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

   What|Removed |Added

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

--- Comment #10 from Erhard F. (erhar...@mailbox.org) ---
I did not get out a meaningful result out of my reverse bisect... But
v5.17.0-rc7 abd v5.17.0-rc8 do not show this issue.

So closing here.

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching someone on the CC list of the bug.

[Bug 213837] [bisected] "Kernel panic - not syncing: corrupted stack end detected inside scheduler" at building via distcc on a G5

2022-03-13 Thread bugzilla-daemon
https://bugzilla.kernel.org/show_bug.cgi?id=213837

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

   What|Removed |Added

 Attachment #298919|0   |1
is obsolete||
 Attachment #298963|0   |1
is obsolete||

--- Comment #20 from Erhard F. (erhar...@mailbox.org) ---
Created attachment 300563
  --> https://bugzilla.kernel.org/attachment.cgi?id=300563=edit
dmesg (5.17-rc7 + patch, PowerMac G5 11,2)

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.

[Bug 213837] [bisected] "Kernel panic - not syncing: corrupted stack end detected inside scheduler" at building via distcc on a G5

2022-03-13 Thread bugzilla-daemon
https://bugzilla.kernel.org/show_bug.cgi?id=213837

--- Comment #19 from Erhard F. (erhar...@mailbox.org) ---
Created attachment 300562
  --> https://bugzilla.kernel.org/attachment.cgi?id=300562=edit
kernel .config (5.17-rc7, PowerMac G5 11,2)

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.

[Bug 213837] [bisected] "Kernel panic - not syncing: corrupted stack end detected inside scheduler" at building via distcc on a G5

2022-03-13 Thread bugzilla-daemon
https://bugzilla.kernel.org/show_bug.cgi?id=213837

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

   What|Removed |Added

 Attachment #298933|0   |1
is obsolete||
 Attachment #298961|0   |1
is obsolete||

--- Comment #18 from Erhard F. (erhar...@mailbox.org) ---
Created attachment 300561
  --> https://bugzilla.kernel.org/attachment.cgi?id=300561=edit
System.map (5.17-rc7 + patch, PowerMac G5 11,2)

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.

[Bug 200055] [Bisected][Regression] WARNING: CPU: 0 PID: 1 at kernel/locking/lockdep.c:3214 .__lockdep_init_map+0x260/0x270

2022-03-12 Thread bugzilla-daemon
https://bugzilla.kernel.org/show_bug.cgi?id=200055

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

   What|Removed |Added

 Status|NEEDINFO|CLOSED
 Resolution|--- |OBSOLETE

--- Comment #26 from Erhard F. (erhar...@mailbox.org) ---
Have not seen this for some time.

Current v5.17-rc7 and stable kernels are fine, so closing.

-- 
You may reply to this email to add a comment.

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

[Bug 200055] [Bisected][Regression] WARNING: CPU: 0 PID: 1 at kernel/locking/lockdep.c:3214 .__lockdep_init_map+0x260/0x270

2022-03-12 Thread bugzilla-daemon
https://bugzilla.kernel.org/show_bug.cgi?id=200055

--- Comment #25 from Erhard F. (erhar...@mailbox.org) ---
Created attachment 300559
  --> https://bugzilla.kernel.org/attachment.cgi?id=300559=edit
dmesg (kernel 5.17-rc7, PowerMac G5 11,2)

-- 
You may reply to this email to add a comment.

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

[Bug 200055] [Bisected][Regression] WARNING: CPU: 0 PID: 1 at kernel/locking/lockdep.c:3214 .__lockdep_init_map+0x260/0x270

2022-03-12 Thread bugzilla-daemon
https://bugzilla.kernel.org/show_bug.cgi?id=200055

--- Comment #24 from Erhard F. (erhar...@mailbox.org) ---
Created attachment 300558
  --> https://bugzilla.kernel.org/attachment.cgi?id=300558=edit
kernel .config (kernel 5.17-rc7, PowerMac G5 11,2)

-- 
You may reply to this email to add a comment.

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

[Bug 215567] build failure when PPC_64S_HASH_MMU=n is selected in kernel .config

2022-03-12 Thread bugzilla-daemon
https://bugzilla.kernel.org/show_bug.cgi?id=215567

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

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |CODE_FIX

--- Comment #6 from Erhard F. (erhar...@mailbox.org) ---
5.17-rc7 builds fine again as the patch got included meanwhile.

Closing.

-- 
You may reply to this email to add a comment.

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

[Bug 215652] kernel 5.17-rc fail to load radeon DRM "modprobe: ERROR: could not insert 'radeon': Unknown symbol in module, or unknown parameter (see dmesg)"

2022-03-10 Thread bugzilla-daemon
https://bugzilla.kernel.org/show_bug.cgi?id=215652

--- Comment #9 from Alex Deucher (alexdeuc...@gmail.com) ---
Only the person that filed the bug can close it.  If it's fixed for you, please
close it.  Thanks!

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching someone on the CC list of the bug.

[Bug 215658] arch/powerpc/mm/mmu_context.o Assembler messages: Error: unrecognized opcode: `dssall' (PowerMac G4)

2022-03-10 Thread bugzilla-daemon
https://bugzilla.kernel.org/show_bug.cgi?id=215658

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

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |INVALID

--- Comment #2 from Erhard F. (erhar...@mailbox.org) ---
This was Gentoo Sources v5.16.12 not upstream sources. But now I am not able to
reproduce it which is even more strange... Also Gentoos' v5.16.13 builds ok.

What I did in the meantime was downgrading to binutils 2.37 (had 2.38 before)
and rebuilding the toolchain afterwards.

So this probably was never a bug but an issue with my setup. ;) Closing here.

-- 
You may reply to this email to add a comment.

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

[Bug 215652] kernel 5.17-rc fail to load radeon DRM "modprobe: ERROR: could not insert 'radeon': Unknown symbol in module, or unknown parameter (see dmesg)"

2022-03-10 Thread bugzilla-daemon
https://bugzilla.kernel.org/show_bug.cgi?id=215652

--- Comment #8 from Erhard F. (erhar...@mailbox.org) ---
Created attachment 300550
  --> https://bugzilla.kernel.org/attachment.cgi?id=300550=edit
kernel dmesg (kernel 5.17-rc7, CONFIG_DRM_RADEON=m, Talos II)

Seems this is issue already fixed in -rc7.

v5.17-rc7 boots on the Talos II again with radeon drm loaded from disk without
an initrd or firmware being built in.

Out of curiosity I'll do a bisect next week anyhow to check out which commit
fixed the issue.

But feel free to close here if it is not appropriate to hold this bug open any
longer.

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching someone on the CC list of the bug.

[Bug 215658] arch/powerpc/mm/mmu_context.o Assembler messages: Error: unrecognized opcode: `dssall' (PowerMac G4)

2022-03-10 Thread bugzilla-daemon
https://bugzilla.kernel.org/show_bug.cgi?id=215658

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

   What|Removed |Added

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

--- Comment #1 from Christophe Leroy (christophe.le...@csgroup.eu) ---
This description is puzzling.

Commit d51f86cfd8e3 ("powerpc/mm: Switch obsolete dssall to .long") is not in
v5.16.12

For me, applying that commit to v5.16.12 should fix your problem, not the
reverse.

-- 
You may reply to this email to add a comment.

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

[Bug 215658] New: arch/powerpc/mm/mmu_context.o Assembler messages: Error: unrecognized opcode: `dssall' (PowerMac G4)

2022-03-04 Thread bugzilla-daemon
https://bugzilla.kernel.org/show_bug.cgi?id=215658

Bug ID: 215658
   Summary: arch/powerpc/mm/mmu_context.o Assembler messages:
Error: unrecognized opcode: `dssall' (PowerMac G4)
   Product: Platform Specific/Hardware
   Version: 2.5
Kernel Version: 5.16.12
  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 300528
  --> https://bugzilla.kernel.org/attachment.cgi?id=300528=edit
kernel .config (5.16.12, PowerMac G4 DP)

5.16.12 kernel build for my G4 DP on my Talos II fails with:

[...]
  CC  arch/powerpc/mm/init_32.o
  CC  arch/powerpc/mm/pgtable_32.o
  CC  arch/powerpc/mm/pgtable-frag.o
  CC  arch/powerpc/mm/ioremap.o
  CC  arch/powerpc/mm/ioremap_32.o
  CC  arch/powerpc/mm/init-common.o
  CC  arch/powerpc/mm/mmu_context.o
{standard input}: Assembler messages:
{standard input}:30: Error: unrecognized opcode: `dssall'
make[2]: *** [scripts/Makefile.build:287: arch/powerpc/mm/mmu_context.o] Fehler
1
make[1]: *** [scripts/Makefile.build:549: arch/powerpc/mm] Fehler 2
make: *** [Makefile:1846: arch/powerpc] Error 2


This seems to have been introduced by commit
d51f86cfd8e378d4907958db77da3074f6dce3ba "powerpc/mm: Switch obsolete dssall to
.long"

Reverting this commit fixes the build for my G4.

-- 
You may reply to this email to add a comment.

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

[Bug 215652] kernel 5.17-rc fail to load radeon DRM "modprobe: ERROR: could not insert 'radeon': Unknown symbol in module, or unknown parameter (see dmesg)"

2022-03-03 Thread bugzilla-daemon
https://bugzilla.kernel.org/show_bug.cgi?id=215652

--- Comment #7 from Erhard F. (erhar...@mailbox.org) ---
(In reply to Alex Deucher from comment #6)
> You need to make sure the firmware is in your initrd.  When the kernel
> loads, it loads from the initrd.  There is no filesystem mounted yet when
> the radeon driver is loaded so the firmwares need to be in the initrd.
As I said I am not using an initrd and this config worked on <5.17-rc. So
something must have changed that I now get "modprobe: ERROR: could not insert
'radeon': Unknown symbol in module, or unknown parameter (see dmesg)". I'll try
a bisect and see if I can dig out more.

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching someone on the CC list of the bug.

[Bug 215652] kernel 5.17-rc fail to load radeon DRM "modprobe: ERROR: could not insert 'radeon': Unknown symbol in module, or unknown parameter (see dmesg)"

2022-03-03 Thread bugzilla-daemon
https://bugzilla.kernel.org/show_bug.cgi?id=215652

--- Comment #6 from Alex Deucher (alexdeuc...@gmail.com) ---
(In reply to Erhard F. from comment #5)
> 
> With CONFIG_DRM_RADEON=m radeon does not load and I still get "modprobe:
> ERROR: could not insert 'radeon': Unknown symbol in module, or unknown
> parameter (see dmesg)" trying to load it manually via modprobe -v radeon.

You need to make sure the firmware is in your initrd.  When the kernel loads,
it loads from the initrd.  There is no filesystem mounted yet when the radeon
driver is loaded so the firmwares need to be in the initrd.

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching someone on the CC list of the bug.

[Bug 215652] kernel 5.17-rc fail to load radeon DRM "modprobe: ERROR: could not insert 'radeon': Unknown symbol in module, or unknown parameter (see dmesg)"

2022-03-03 Thread bugzilla-daemon
https://bugzilla.kernel.org/show_bug.cgi?id=215652

--- Comment #5 from Erhard F. (erhar...@mailbox.org) ---
Ok, changed my config to include the firmware via
CONFIG_EXTRA_FIRMWARE="radeon/R520_cp.bin"
CONFIG_EXTRA_FIRMWARE_DIR="/lib/firmware"

With CONFIG_DRM_RADEON=y the machine boots now as expected with no radeon error
messages.

With CONFIG_DRM_RADEON=m radeon does not load and I still get "modprobe: ERROR:
could not insert 'radeon': Unknown symbol in module, or unknown parameter (see
dmesg)" trying to load it manually via modprobe -v radeon.

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching someone on the CC list of the bug.

[Bug 215652] kernel 5.17-rc fail to load radeon DRM "modprobe: ERROR: could not insert 'radeon': Unknown symbol in module, or unknown parameter (see dmesg)"

2022-03-03 Thread bugzilla-daemon
https://bugzilla.kernel.org/show_bug.cgi?id=215652

--- Comment #4 from Erhard F. (erhar...@mailbox.org) ---
No I don't use an initrd. The kernel to boot the Talos is on a boot partition,
modules are loaded from root partition. Which worked in 5.16 and before. Now I
am getting this "could not insert 'radeon': Unknown symbol in module".

Though this may explain the 2nd error I got when building radeon statically
into the kernel. I'll add the firmware in-kernel and see if the error message
changes and whether it actually works then.

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching someone on the CC list of the bug.

[Bug 215652] kernel 5.17-rc fail to load radeon DRM "modprobe: ERROR: could not insert 'radeon': Unknown symbol in module, or unknown parameter (see dmesg)"

2022-03-02 Thread bugzilla-daemon
https://bugzilla.kernel.org/show_bug.cgi?id=215652

Alex Deucher (alexdeuc...@gmail.com) changed:

   What|Removed |Added

 CC||alexdeuc...@gmail.com

--- Comment #3 from Alex Deucher (alexdeuc...@gmail.com) ---
If you are using an initrd, the firmware must be present on the initrd for the
driver to find it when it loads.  Please make sure the firmware is available in
your initrd.

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching someone on the CC list of the bug.

[Bug 215652] kernel 5.17-rc fail to load radeon DRM "modprobe: ERROR: could not insert 'radeon': Unknown symbol in module, or unknown parameter (see dmesg)"

2022-03-02 Thread bugzilla-daemon
https://bugzilla.kernel.org/show_bug.cgi?id=215652

--- Comment #2 from Erhard F. (erhar...@mailbox.org) ---
Created attachment 300522
  --> https://bugzilla.kernel.org/attachment.cgi?id=300522=edit
kernel .config (kernel 5.17-rc5, CONFIG_DRM_RADEON=m, Talos II)

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching someone on the CC list of the bug.

[Bug 215652] kernel 5.17-rc fail to load radeon DRM "modprobe: ERROR: could not insert 'radeon': Unknown symbol in module, or unknown parameter (see dmesg)"

2022-03-02 Thread bugzilla-daemon
https://bugzilla.kernel.org/show_bug.cgi?id=215652

--- Comment #1 from Erhard F. (erhar...@mailbox.org) ---
Created attachment 300521
  --> https://bugzilla.kernel.org/attachment.cgi?id=300521=edit
kernel dmesg (kernel 5.17-rc5, CONFIG_DRM_RADEON=y, Talos II)

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching someone on the CC list of the bug.

[Bug 215652] New: kernel 5.17-rc fail to load radeon DRM "modprobe: ERROR: could not insert 'radeon': Unknown symbol in module, or unknown parameter (see dmesg)"

2022-03-02 Thread bugzilla-daemon
https://bugzilla.kernel.org/show_bug.cgi?id=215652

Bug ID: 215652
   Summary: kernel 5.17-rc fail to load radeon DRM "modprobe:
ERROR: could not insert 'radeon': Unknown symbol in
module, or unknown parameter (see dmesg)"
   Product: Drivers
   Version: 2.5
Kernel Version: 5.17-rc5
  Hardware: PPC-64
OS: Linux
  Tree: Mainline
Status: NEW
  Severity: normal
  Priority: P1
 Component: Video(DRI - non Intel)
  Assignee: drivers_video-...@kernel-bugs.osdl.org
  Reporter: erhar...@mailbox.org
CC: platform_ppc...@kernel-bugs.osdl.org
Regression: No

Created attachment 300520
  --> https://bugzilla.kernel.org/attachment.cgi?id=300520=edit
kernel dmesg (kernel 5.17-rc5, CONFIG_DRM_RADEON=m, Talos II)

Kernel 5.17-rc5 has problems loading the radeon KMS module on my Talos II:

 # modprobe -v radeon
insmod /lib/modules/5.17.0-rc5-P9+/kernel/drivers/gpu/drm/drm_kms_helper.ko 
modprobe: ERROR: could not insert 'radeon': Unknown symbol in module, or
unknown parameter (see dmesg)

dmesg show no further output then.

When I build a kernel with CONFIG_DRM_RADEON=y I get this in dmesg:
[...]
ATOM BIOS: X1550
[drm] Generation 2 PCI interface, using max accessible memory
radeon :01:00.0: VRAM: 512M 0x - 0x1FFF (512M
used)
radeon :01:00.0: GTT: 512M 0x2000 - 0x3FFF
[drm] Detected VRAM RAM=512M, BAR=256M
[drm] RAM width 128bits DDR
radeon :01:00.0: dma_iommu_get_required_mask: returning bypass mask
0xfff
[drm] radeon: 512M of VRAM memory ready
[drm] radeon: 512M of GTT memory ready.
[drm] GART: num cpu pages 131072, num gpu pages 131072
[drm] radeon: 1 quad pipes, 1 z pipes initialized.
[drm] PCIE GART of 512M enabled (table at 0x0004).
radeon :01:00.0: WB enabled
radeon :01:00.0: fence driver on ring 0 use gpu addr 0x2000
radeon :01:00.0: radeon: MSI limited to 32-bit
[drm] radeon: irq initialized.
[drm] Loading R500 Microcode
radeon :01:00.0: Direct firmware load for radeon/R520_cp.bin failed with
error -2
radeon_cp: Failed to load firmware "radeon/R520_cp.bin"
[drm:.r100_cp_init] *ERROR* Failed to load firmware!
radeon :01:00.0: failed initializing CP (-2).
radeon :01:00.0: Disabling GPU acceleration

So it complains about not finding the relevant firmware. But the firmware being
located in everything should be ok. This used to work on kernels 5.16.x and
before.

 # ls -al /lib/firmware/radeon/R520_cp.bin
-rw-r--r-- 1 root root 2048  2. Mär 20:43 /lib/firmware/radeon/R520_cp.bin


Some data about the machine:
 # lspci 
:00:00.0 PCI bridge: IBM POWER9 Host Bridge (PHB4)
:01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI]
RV516 [Radeon X1300/X1550 Series]
:01:00.1 Display controller: Advanced Micro Devices, Inc. [AMD/ATI] RV516
[Radeon X1300/X1550 Series] (Secondary)
0001:00:00.0 PCI bridge: IBM POWER9 Host Bridge (PHB4)
0001:01:00.0 Non-Volatile memory controller: Phison Electronics Corporation
Device 5008 (rev 01)
0002:00:00.0 PCI bridge: IBM POWER9 Host Bridge (PHB4)
0003:00:00.0 PCI bridge: IBM POWER9 Host Bridge (PHB4)
0003:01:00.0 USB controller: Texas Instruments TUSB73x0 SuperSpeed USB 3.0 xHCI
Host Controller (rev 02)
0004:00:00.0 PCI bridge: IBM POWER9 Host Bridge (PHB4)
0004:01:00.0 Ethernet controller: Broadcom Inc. and subsidiaries NetXtreme
BCM5719 Gigabit Ethernet PCIe (rev 01)
0004:01:00.1 Ethernet controller: Broadcom Inc. and subsidiaries NetXtreme
BCM5719 Gigabit Ethernet PCIe (rev 01)
0005:00:00.0 PCI bridge: IBM POWER9 Host Bridge (PHB4)
0005:01:00.0 PCI bridge: ASPEED Technology, Inc. AST1150 PCI-to-PCI Bridge (rev
04)
0005:02:00.0 VGA compatible controller: ASPEED Technology, Inc. ASPEED Graphics
Family (rev 41)
0030:00:00.0 PCI bridge: IBM POWER9 Host Bridge (PHB4)
0031:00:00.0 PCI bridge: IBM POWER9 Host Bridge (PHB4)
0032:00:00.0 PCI bridge: IBM POWER9 Host Bridge (PHB4)
0033:00:00.0 PCI bridge: IBM POWER9 Host Bridge (PHB4)

 # lspci -s :01:00.0 -vv
:01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI]
RV516 [Radeon X1300/X1550 Series] (prog-if 00 [VGA controller])
Subsystem: PC Partner Limited / Sapphire Technology RV516 [Radeon
X1300/X1550 Series]
Device tree node:
/sys/firmware/devicetree/base/pciex@600c3c000/pci@0/vga@0
Control: I/O- Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr+
Stepping- SERR+ FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR-  [disabled]
Expansion ROM at 600c0 [disabled] [size=128K]
Capabilities: [50] Power Management version 2
Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA
PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-

[Bug 215567] build failure when PPC_64S_HASH_MMU=n is selected in kernel .config

2022-03-01 Thread bugzilla-daemon
https://bugzilla.kernel.org/show_bug.cgi?id=215567

--- Comment #5 from Erhard F. (erhar...@mailbox.org) ---
Your 2nd patch solved the issue. Thanks Murilo!

Build completes and the Talos boots fine into the patched 5.17-rc5.

-- 
You may reply to this email to add a comment.

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

[Bug 215567] build failure when PPC_64S_HASH_MMU=n is selected in kernel .config

2022-03-01 Thread bugzilla-daemon
https://bugzilla.kernel.org/show_bug.cgi?id=215567

--- Comment #4 from Murilo Opsfelder Araújo (mopsfel...@gmail.com) ---
Erhard, would you mind trying the v2?

https://lists.ozlabs.org/pipermail/linuxppc-dev/2022-March/240715.html

Christophe, thanks for the suggestion.  That's exactly what I did in the v2.

-- 
You may reply to this email to add a comment.

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

[Bug 215567] build failure when PPC_64S_HASH_MMU=n is selected in kernel .config

2022-03-01 Thread bugzilla-daemon
https://bugzilla.kernel.org/show_bug.cgi?id=215567

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

   What|Removed |Added

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

--- Comment #3 from Christophe Leroy (christophe.le...@csgroup.eu) ---
For this linking error, in arch/powerpc/include/asm/kexec_ranges.h change the
#ifdef to CONFIG_PPC_64S_HASH_MMU instead of CONFIG_PPC_BOOK3S_64 and it should
build.

-- 
You may reply to this email to add a comment.

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

[Bug 215567] build failure when PPC_64S_HASH_MMU=n is selected in kernel .config

2022-03-01 Thread bugzilla-daemon
https://bugzilla.kernel.org/show_bug.cgi?id=215567

--- Comment #2 from Erhard F. (erhar...@mailbox.org) ---
I just tested your patch top of 5.17-rc5. It applies and build continues but
fails later with:

[...]
  CC  lib/asn1_decoder.o
  GEN lib/oid_registry_data.c
  CC  lib/oid_registry.o
  CC  lib/ubsan.o
  CC  lib/sbitmap.o
  AR  lib/built-in.a
  CC [M]  lib/crc-ccitt.o
  CC [M]  lib/crc-itu-t.o
  GEN .version
  CHK include/generated/compile.h
  LD  vmlinux.o
  MODPOST vmlinux.symvers
  MODINFO modules.builtin.modinfo
  GEN modules.builtin
  LD  .tmp_vmlinux.kallsyms1
ld: arch/powerpc/kexec/file_load_64.o: in function
`.arch_kexec_kernel_image_probe':
file_load_64.c:(.text+0x1be8): undefined reference to `.add_htab_mem_range'
make: *** [Makefile:1155: vmlinux] Error 1

-- 
You may reply to this email to add a comment.

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

[Bug 215567] build failure when PPC_64S_HASH_MMU=n is selected in kernel .config

2022-03-01 Thread bugzilla-daemon
https://bugzilla.kernel.org/show_bug.cgi?id=215567

Murilo Opsfelder Araújo (mopsfel...@gmail.com) changed:

   What|Removed |Added

 CC||mopsfel...@gmail.com

--- Comment #1 from Murilo Opsfelder Araújo (mopsfel...@gmail.com) ---
Hi, Erhard.

Thanks for reporting the issue.
I've sent a fix proposal for this:

https://lists.ozlabs.org/pipermail/linuxppc-dev/2022-March/240698.html

Please let me know if the proposed fix worked for you.
You can reply here on Bugzilla or to the list with your 'Tested-by:' tag.

Thank you!
Murilo

-- 
You may reply to this email to add a comment.

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

[Bug 215621] Warning: Unable to mark rodata read only on this CPU. (PPC970MP)

2022-02-20 Thread bugzilla-daemon
https://bugzilla.kernel.org/show_bug.cgi?id=215621

--- Comment #4 from Christophe Leroy (christophe.le...@csgroup.eu) ---
It is up to you to unselect CONFIG_STRICT_KERNEL_RWX.

The kernel is usually built to boot on any PPC64 processors, so we can't forbid
the selection of CONFIG_STRICT_KERNEL_RWX.

-- 
You may reply to this email to add a comment.

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

[Bug 215621] Warning: Unable to mark rodata read only on this CPU. (PPC970MP)

2022-02-20 Thread bugzilla-daemon
https://bugzilla.kernel.org/show_bug.cgi?id=215621

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

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |INVALID

--- Comment #3 from Erhard F. (erhar...@mailbox.org) ---
Erm ok, so it seems I did not check this thoroughly...

If MMU_FTRS_PPC970 doesn't provide MMU_FTR_KERNEL_RO then perhaps
CONFIG_STRICT_KERNEL_RWX can be skipped in the .config so it can't be wrongly
selected?

Anyhow you are correct that this is not a bug. Thanks for the background!

-- 
You may reply to this email to add a comment.

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

[Bug 215621] Warning: Unable to mark rodata read only on this CPU. (PPC970MP)

2022-02-20 Thread bugzilla-daemon
https://bugzilla.kernel.org/show_bug.cgi?id=215621

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

   What|Removed |Added

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

--- Comment #2 from Christophe Leroy (christophe.le...@csgroup.eu) ---
Look at
https://elixir.bootlin.com/linux/v5.17-rc4/source/arch/powerpc/kernel/cputable.c#L196
at you'll see that your processor has .mmu_features = MMU_FTRS_PPC970

Then you see at
https://elixir.bootlin.com/linux/v5.17-rc4/source/arch/powerpc/include/asm/mmu.h#L135
that MMU_FTRS_PPC970 doesn't include MMU_FTR_KERNEL_RO.

MMU_FTR_KERNEL_RO is in POWER6.

In commit 984d7a1ec67c ("powerpc/mm: Fixup kernel read only mapping") you see
that this feature appears in ISA 2.04.

Previous version of ISA only has PP bits which only provides RW for kernel
pages.

So this bug is not a bug, it's a limitation of PPC970MP, and the warning in
dmesg is there to warn you that allthough you have select
CONFIG_STRICT_KERNEL_RWX, this CPU doesn't support it.

And for the same reason, CONFIG_STRICT_MODULE_RWX doesn't work either.

-- 
You may reply to this email to add a comment.

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

[Bug 213837] [bisected] "Kernel panic - not syncing: corrupted stack end detected inside scheduler" at building via distcc on a G5

2022-02-19 Thread bugzilla-daemon
https://bugzilla.kernel.org/show_bug.cgi?id=213837

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

   What|Removed |Added

 Attachment #298393|0   |1
is obsolete||
 Attachment #299755|0   |1
is obsolete||

--- Comment #17 from Erhard F. (erhar...@mailbox.org) ---
Created attachment 300487
  --> https://bugzilla.kernel.org/attachment.cgi?id=300487=edit
dmesg (5.17-rc4 + patch, PowerMac G5 11,2)

Still an issue on 5.17-rc4.

Stacktrace looks a bit more interesting this time.

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.

[Bug 213837] [bisected] "Kernel panic - not syncing: corrupted stack end detected inside scheduler" at building via distcc on a G5

2022-02-19 Thread bugzilla-daemon
https://bugzilla.kernel.org/show_bug.cgi?id=213837

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

   What|Removed |Added

 Attachment #298019|0   |1
is obsolete||
 Attachment #298671|0   |1
is obsolete||
 Attachment #298959|0   |1
is obsolete||

--- Comment #16 from Erhard F. (erhar...@mailbox.org) ---
Created attachment 300486
  --> https://bugzilla.kernel.org/attachment.cgi?id=300486=edit
kernel .config (5.17-rc4, PowerMac G5 11,2)

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.

[Bug 215622] WARNING: possible irq lock inversion dependency detected

2022-02-18 Thread bugzilla-daemon
https://bugzilla.kernel.org/show_bug.cgi?id=215622

--- Comment #1 from Erhard F. (erhar...@mailbox.org) ---
Created attachment 300485
  --> https://bugzilla.kernel.org/attachment.cgi?id=300485=edit
kernel .config (5.17-rc4, PowerMac G5 11,2)

-- 
You may reply to this email to add a comment.

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

[Bug 215622] New: WARNING: possible irq lock inversion dependency detected

2022-02-18 Thread bugzilla-daemon
https://bugzilla.kernel.org/show_bug.cgi?id=215622

Bug ID: 215622
   Summary: WARNING: possible irq lock inversion dependency
detected
   Product: Platform Specific/Hardware
   Version: 2.5
Kernel Version: 5.17-rc4
  Hardware: PPC-64
OS: Linux
  Tree: Mainline
Status: NEW
  Severity: normal
  Priority: P1
 Component: PPC-64
  Assignee: platform_ppc...@kernel-bugs.osdl.org
  Reporter: erhar...@mailbox.org
Regression: No

Created attachment 300484
  --> https://bugzilla.kernel.org/attachment.cgi?id=300484=edit
dmesg (5.17-rc4, PowerMac G5 11,2)

Don't know whether this has something to do or in common with a netconsole
issue I unearthed on other hardware (bug #212509)...

But as the trace looks different I'll post this as a seperate bug:

[...]

WARNING: possible irq lock inversion dependency detected
5.17.0-rc4-PowerMacG5+ #2 Not tainted

swapper/0/1 just changed the state of lock:
c13e4490 (native_tlbie_lock){+.-.}-{2:2}, at: .tlbie+0x70/0x10c
but this lock was taken by another, HARDIRQ-safe lock in the past:
 (console_owner){-...}-{0:0}


and interrupts could create inverse lock ordering between them.


other info that might help us debug this:
Chain exists of:
  console_owner --> target_list_lock --> native_tlbie_lock

 Possible interrupt unsafe locking scenario:

   CPU0CPU1
   
  lock(native_tlbie_lock);
   local_irq_disable();
   lock(console_owner);
   lock(target_list_lock);
  
lock(console_owner);

 *** DEADLOCK ***

no locks held by swapper/0/1.

the shortest dependencies between 2nd lock and 1st lock:
  -> (console_owner){-...}-{0:0} ops: 994 {
 IN-HARDIRQ-W at:
.lock_acquire+0x290/0x2e8
.console_unlock+0x2fc/0x628
.vprintk_emit+0x270/0x280
.vprintk+0x8c/0x94
._printk+0x30/0x44
.crng_fast_load+0x128/0x17c
.add_interrupt_randomness+0x330/0x488
.handle_irq_event_percpu+0x28/0x54
.handle_irq_event+0x44/0x70
.handle_fasteoi_irq+0xac/0x158
.handle_irq_desc+0x34/0x54
.__do_irq+0x174/0x250
.__do_IRQ+0xac/0xb4
init_stack+0x3820/0x4000
.do_IRQ+0xd0/0x124
hardware_interrupt_common_virt+0x208/0x210
.power4_idle+0x3c/0x70
.arch_cpu_idle+0x8c/0x114
.default_idle_call+0x7c/0xd4
.do_idle+0x118/0x12c
.cpu_startup_entry+0x28/0x2c
.rest_init+0x1bc/0x1c8
.start_kernel+0xba8/0xca0
start_here_common+0x1c/0x44
 INITIAL USE at:
   .lock_acquire+0x290/0x2e8
   .console_unlock+0x2fc/0x628
   .vprintk_emit+0x270/0x280
   .vprintk+0x8c/0x94
   ._printk+0x30/0x44
   .start_kernel+0xc4/0xca0
   start_here_common+0x1c/0x44
   }
   ... key  at: [] console_owner_dep_map+0x0/0x28
   ... acquired at:
   ._raw_spin_lock_irqsave+0x6c/0x98
   .write_msg+0x64/0x10c
   .console_unlock+0x53c/0x628
   .register_console+0x250/0x330
   .init_netconsole+0x538/0x610
   .do_one_initcall+0x100/0x2dc
   .kernel_init_freeable+0x644/0x748
   .kernel_init+0x20/0x178
   .ret_from_kernel_thread+0x58/0x60

 -> (target_list_lock){}-{2:2} ops: 461 {
INITIAL USE at:
 .lock_acquire+0x290/0x2e8
 ._raw_spin_lock_irqsave+0x6c/0x98
 .init_netconsole+0x40c/0x610
 .do_one_initcall+0x100/0x2dc
 .kernel_init_freeable+0x644/0x748
 .kernel_init+0x20/0x178
 .ret_from_kernel_thread+0x58/0x60
  }
  ... key  at: [] target_list_lock+0x18/0x40
  ... acquired at:
   ._raw_spin_lock+0x44/0x68
   .tlbie+0x70/0x10c
   .native_hpte_invalidate+0xcc/0x114
   .hash__kernel_map_pages+0x270/0x280
   .debug_pagealloc_unmap_pages+0x34/0x40
   .free_unref_page_prepare+0x2c8/0x314
   .free_unref_page+0x38/0xdc
   .__free_slab+0xc4/0x158
   .kfree_skbmem+0x5c/0x7c
   .zap_completion_queue+0x128/0x130
   .netpoll_send_skb+0x2e0/0x348
   .write_msg+0xfc/0x10c
   .console_unlock+0x53c/0x628
   .vprintk_emit+0x270/0x280
   .vprintk+0x8c/0x94
   ._printk+0x30/0x44
   .register_console+0x288/0x330
   

[Bug 215621] Warning: Unable to mark rodata read only on this CPU. (PPC970MP)

2022-02-18 Thread bugzilla-daemon
https://bugzilla.kernel.org/show_bug.cgi?id=215621

--- Comment #1 from Erhard F. (erhar...@mailbox.org) ---
Created attachment 300483
  --> https://bugzilla.kernel.org/attachment.cgi?id=300483=edit
kernel .config (5.17-rc4, PowerMac G5 11,2)

-- 
You may reply to this email to add a comment.

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

[Bug 215621] New: Warning: Unable to mark rodata read only on this CPU. (PPC970MP)

2022-02-18 Thread bugzilla-daemon
https://bugzilla.kernel.org/show_bug.cgi?id=215621

Bug ID: 215621
   Summary: Warning: Unable to mark rodata read only on this CPU.
(PPC970MP)
   Product: Platform Specific/Hardware
   Version: 2.5
Kernel Version: 5.17-rc4
  Hardware: PPC-64
OS: Linux
  Tree: Mainline
Status: NEW
  Severity: normal
  Priority: P1
 Component: PPC-64
  Assignee: platform_ppc...@kernel-bugs.osdl.org
  Reporter: erhar...@mailbox.org
Regression: No

Created attachment 300482
  --> https://bugzilla.kernel.org/attachment.cgi?id=300482=edit
dmesg (5.17-rc4, PowerMac G5 11,2)

STRICT_MODULE_RWX is enabled in kernel but it does not seem to work on my
PowerMac G5 11,2.

Kernel dmesg says:
[...]
Freeing unused kernel image (initmem) memory: 3968K
Warning: Unable to mark rodata read only on this CPU.
rodata_test: test data was not read only
[...]


 # lscpu 
Architecture:  ppc64
  CPU op-mode(s):  32-bit, 64-bit
  Byte Order:  Big Endian
CPU(s):2
  On-line CPU(s) list: 0,1
Model name:PPC970MP, altivec supported
  Model:   1.1 (pvr 0044 0101)
  Thread(s) per core:  1
  Core(s) per socket:  2
  Socket(s):   1
  CPU max MHz: 2300.
  CPU min MHz: 1150.
Caches (sum of all):   
  L1d: 64 KiB (2 instances)
  L1i: 128 KiB (2 instances)
  L2:  2 MiB (2 instances)
NUMA:  
  NUMA node(s):1
  NUMA node0 CPU(s):   0,1
Vulnerabilities:   
  Itlb multihit:   Not affected
  L1tf:Vulnerable
  Mds: Not affected
  Meltdown:Vulnerable
  Spec store bypass:   Vulnerable
  Spectre v1:  Mitigation; __user pointer sanitization
  Spectre v2:  Vulnerable
  Srbds:   Not affected
  Tsx async abort: Not affected

-- 
You may reply to this email to add a comment.

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

[Bug 215169] UBSAN: shift-out-of-bounds in arch/powerpc/mm/kasan/book3s_32.c:22:23

2022-02-04 Thread bugzilla-daemon
https://bugzilla.kernel.org/show_bug.cgi?id=215169

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

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |CODE_FIX

--- Comment #2 from Erhard F. (erhar...@mailbox.org) ---
Fix landed in 5.16.3 and LTS-kernels. Thanks!

-- 
You may reply to this email to add a comment.

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

[Bug 214867] UBSAN: shift-out-of-bounds in drivers/of/unittest.c:1933:36

2022-02-04 Thread bugzilla-daemon
https://bugzilla.kernel.org/show_bug.cgi?id=214867

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

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |CODE_FIX

--- Comment #4 from Erhard F. (erhar...@mailbox.org) ---
Fix landed in mainline meanwhile. At least I can replicate this no longer on
v5.17-rc2.

Thanks!

-- 
You may reply to this email to add a comment.

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

[Bug 215567] New: build failure when PPC_64S_HASH_MMU=n is selected in kernel .config

2022-02-04 Thread bugzilla-daemon
https://bugzilla.kernel.org/show_bug.cgi?id=215567

Bug ID: 215567
   Summary: build failure when PPC_64S_HASH_MMU=n is selected in
kernel .config
   Product: Platform Specific/Hardware
   Version: 2.5
Kernel Version: 5.17-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 300391
  --> https://bugzilla.kernel.org/attachment.cgi?id=300391=edit
kernel .config (kernel 5.17-rc2, Talos II)

[...]
  CC  arch/powerpc/kernel/stacktrace.o
  CC  arch/powerpc/kernel/setup_64.o
arch/powerpc/kernel/setup_64.c: In function 'setup_per_cpu_areas':
arch/powerpc/kernel/setup_64.c:811:21: error: 'mmu_linear_psize' undeclared
(first use in this function); did you mean 'mmu_virtual_psize'?
  811 | if (mmu_linear_psize == MMU_PAGE_4K)
  | ^~~~
  | mmu_virtual_psize
arch/powerpc/kernel/setup_64.c:811:21: note: each undeclared identifier is
reported only once for each function it appears in
make[2]: *** [scripts/Makefile.build:288: arch/powerpc/kernel/setup_64.o]
Fehler 1

Got this with PPC_64S_HASH_MMU=n on my Talos II. When PPC_64S_HASH_MMU is
enabled the kernel builds ok.

-- 
You may reply to this email to add a comment.

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

[Bug 210749] sysfs: cannot create duplicate filename '/bus/nvmem/devices/module-vpd'

2022-02-03 Thread bugzilla-daemon
https://bugzilla.kernel.org/show_bug.cgi?id=210749

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

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |OBSOLETE

--- Comment #11 from Erhard F. (erhar...@mailbox.org) ---
Have not seen this on kernels 5.15.x and 5.16.x.

Closing as obsolete.

-- 
You may reply to this email to add a comment.

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

[Bug 215217] Kernel fails to boot at an early stage when built with GCC_PLUGIN_LATENT_ENTROPY=y (PowerMac G4 3,6)

2022-02-03 Thread bugzilla-daemon
https://bugzilla.kernel.org/show_bug.cgi?id=215217

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

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |CODE_FIX

--- Comment #15 from Erhard F. (erhar...@mailbox.org) ---
Fix landed in kernel 5.16.5. Thanks!

-- 
You may reply to this email to add a comment.

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

[Bug 215389] pagealloc: memory corruption at building glibc-2.33 and running its' testsuite

2022-01-31 Thread bugzilla-daemon
https://bugzilla.kernel.org/show_bug.cgi?id=215389

--- Comment #11 from Erhard F. (erhar...@mailbox.org) ---
(In reply to Christophe Leroy from comment #10)
> I'm wondering whether you could be running out of vmalloc space. I initially
> thought you were using KASAN, but it seems not according to your .config.
Correct, I was not using KASAN. I use it only for testing -rc kernels or when I
am particularly wary. This memory corruption I noticed during regular usage.
Seems running the kernel with slub_debug=FZP page_poison=1 is a good thing. ;)

> Could you try reducing CONFIG_LOWMEM_SIZE to 0x2800 for instance and see
> if the memory corruption still happens ?
Thanks, that did the trick! With CONFIG_LOWMEM_SIZE=0x2800 the memory
corruption is gone on VMAP_STACK enabled kernels. Tested it additionally on
current 5.16.4 where this works too.

-- 
You may reply to this email to add a comment.

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

[Bug 206669] Little-endian kernel crashing on POWER8 on heavy big-endian PowerKVM load

2022-01-31 Thread bugzilla-daemon
https://bugzilla.kernel.org/show_bug.cgi?id=206669

--- Comment #19 from John Paul Adrian Glaubitz (glaub...@physik.fu-berlin.de) 
---
In case any runs into this issue, a workaround is disabling "dynamic_mt_modes":

# echo 0 > /sys/module/kvm_hv/parameters/dynamic_mt_modes

This fixes the crashes for me with a 5.15.x kernel.

-- 
You may reply to this email to add a comment.

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

[Bug 215389] pagealloc: memory corruption at building glibc-2.33 and running its' testsuite

2022-01-30 Thread bugzilla-daemon
https://bugzilla.kernel.org/show_bug.cgi?id=215389

--- Comment #10 from Christophe Leroy (christophe.le...@csgroup.eu) ---
Thanks for the tests.

I'm not surprised that the system doesn't poweroff or reboot without ADB_PMU
because the PMU manages power.

The "neverending build" is maybe because the PMU also manages RTC clock and
without it you get inconsistent time ?

Anyway, it looks like there is indeed something linked to VMAP_STACK.

I'm wondering whether you could be running out of vmalloc space. I initially
thought you were using KASAN, but it seems not according to your .config.

Could you try reducing CONFIG_LOWMEM_SIZE to 0x2800 for instance and see if
the memory corruption still happens ?

To do this you'll need CONFIG_ADVANCED_OPTIONS and CONFIG_LOWMEM_SIZE_BOOL.

-- 
You may reply to this email to add a comment.

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

[Bug 215389] pagealloc: memory corruption at building glibc-2.33 and running its' testsuite

2022-01-30 Thread bugzilla-daemon
https://bugzilla.kernel.org/show_bug.cgi?id=215389

--- Comment #9 from Erhard F. (erhar...@mailbox.org) ---
Created attachment 300354
  --> https://bugzilla.kernel.org/attachment.cgi?id=300354=edit
dmesg (5.10-rc2 with ADB_PMU disabled, PowerMac G4 DP)

Took a little time but I double checked the results (one time using distcc '-j8
-l2', one time native '-j3') to be sure:

ADB_PMU disabled, VMAP_STACK disabled  ...  "neverending build"
ADB_PMU enabled,  VMAP_STACK disabled  ...  works ok
ADB_PMU disabled, VMAP_STACK enabled   ...  "neverending build"
ADB_PMU enabled,  VMAP_STACK enabled   ...  memory corruption

Version used was git db972a3787d12b1ce9ba7a31ec376d8a79e04c47, which is the one
before a last 'git bisect bad' ends the git bisect.

The "neverending builds" happen when I run this kernel with ADB_PMU disabled.
The G4 runs for several hours building (?) without reaching the glibc test
stage. With ADB_PMU enabled I get a pass or memory corruption much earlier.

Also without ADB_PMU I get a kernel panic when rebooting or shutting down the
G4. Also the G4 does not reboot/poweroff in this case, I need to switch it off
manually.

-- 
You may reply to this email to add a comment.

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

[Bug 215389] pagealloc: memory corruption at building glibc-2.33 and running its' testsuite

2022-01-25 Thread bugzilla-daemon
https://bugzilla.kernel.org/show_bug.cgi?id=215389

--- Comment #8 from Christophe Leroy (christophe.le...@csgroup.eu) ---
Looking closer, in fact that might be a false positive.

The huge difference with that bad commit is that:
- Before the commit, the kernel is built _without_ CONFIG_VMAP_STACK
- After the commit, the kernel is built _with_ CONFIG_VMAP_STACK

Would you be able to perform following tests:
- Disable VMAP_STACK and see if the problem still occurs.
- Disable ADB_PMU and see it the problem still occurs.

With the version which preceeds the bad commit, can you disable ADB_PMU and
enable VMAP_STACK and see what happens ?

-- 
You may reply to this email to add a comment.

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

[Bug 215389] pagealloc: memory corruption at building glibc-2.33 and running its' testsuite

2022-01-25 Thread bugzilla-daemon
https://bugzilla.kernel.org/show_bug.cgi?id=215389

--- Comment #7 from Christophe Leroy (christophe.le...@csgroup.eu) ---
Interesting ... Though confusing.

-- 
You may reply to this email to add a comment.

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

[Bug 215389] pagealloc: memory corruption at building glibc-2.33 and running its' testsuite

2022-01-25 Thread bugzilla-daemon
https://bugzilla.kernel.org/show_bug.cgi?id=215389

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

Ok, finally got it. Interesting find:

 # git bisect bad
db972a3787d12b1ce9ba7a31ec376d8a79e04c47 is the first bad commit
commit db972a3787d12b1ce9ba7a31ec376d8a79e04c47
Author: Christophe Leroy 
Date:   Tue Dec 8 05:24:19 2020 +

powerpc/powermac: Fix low_sleep_handler with CONFIG_VMAP_STACK

low_sleep_handler() can't restore the context from standard
stack because the stack can hardly be accessed with MMU OFF.

Store everything in a global storage area instead of storing
a pointer to the stack in that global storage area.

To avoid a complete churn of the function, still use r1 as
the pointer to the storage area during restore.

Fixes: cd08f109e262 ("powerpc/32s: Enable CONFIG_VMAP_STACK")
Reported-by: Giuseppe Sacco 
Signed-off-by: Christophe Leroy 
Tested-by: Giuseppe Sacco 
Signed-off-by: Michael Ellerman 
Link:
https://lore.kernel.org/r/e3e0d8042a3ba75cb4a9546c19c408b5b5b28994.1607404931.git.christophe.le...@csgroup.eu

 arch/powerpc/platforms/Kconfig.cputype  |   2 +-
 arch/powerpc/platforms/powermac/sleep.S | 132 ++--
 2 files changed, 60 insertions(+), 74 deletions(-)

-- 
You may reply to this email to add a comment.

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

[Bug 213837] [bisected] "Kernel panic - not syncing: corrupted stack end detected inside scheduler" at building via distcc on a G5

2022-01-21 Thread bugzilla-daemon
https://bugzilla.kernel.org/show_bug.cgi?id=213837

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

   What|Removed |Added

Summary|"Kernel panic - not |[bisected] "Kernel panic -
   |syncing: corrupted stack|not syncing: corrupted
   |end detected inside |stack end detected inside
   |scheduler" at building via  |scheduler" at building via
   |distcc on a G5  |distcc on a G5

--- Comment #15 from Erhard F. (erhar...@mailbox.org) ---
This may look a bit odd at first to cause memory corruption while building
stuff, but as I do the builds via distcc on another host (sources are fetched
via nfs from this host too) it seems possible.

Problem is the 'bad' commit is a merge and reverting it on v5.16.2 for a test
via git revert -m1 c2c11289021dfacec1658b2019faab10e12f383a  gets me some merge
conflicts which I don't know to resolve properly..

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.

[Bug 213837] "Kernel panic - not syncing: corrupted stack end detected inside scheduler" at building via distcc on a G5

2022-01-21 Thread bugzilla-daemon
https://bugzilla.kernel.org/show_bug.cgi?id=213837

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

Finally did a bisect which revealed the following commit:

 # git bisect good
c2c11289021dfacec1658b2019faab10e12f383a is the first bad commit
commit c2c11289021dfacec1658b2019faab10e12f383a
Merge: 63bef48fd6c9 ef516e8625dd
Author: David S. Miller 
Date:   Tue Apr 7 18:08:06 2020 -0700

Merge git://git.kernel.org/pub/scm/linux/kernel/git/pablo/nf

Pablo Neira Ayuso says:


Netfilter fixes for net

The following patchset contains Netfilter fixes for net, they are:

1) Fix spurious overlap condition in the rbtree tree, from Stefano Brivio.

2) Fix possible uninitialized pointer dereference in nft_lookup.

3) IDLETIMER v1 target matches the Android layout, from
   Maciej Zenczykowski.

4) Dangling pointer in nf_tables_set_alloc_name, from Eric Dumazet.

5) Fix RCU warning splat in ipset find_set_type(), from Amol Grover.

6) Report EOPNOTSUPP on unsupported set flags and object types in sets.

7) Add NFT_SET_CONCAT flag to provide consistent error reporting
   when users defines set with ranges in concatenations in old kernels.


Signed-off-by: David S. Miller 

 include/net/netfilter/nf_tables.h   |  2 +-
 include/uapi/linux/netfilter/nf_tables.h|  2 ++
 include/uapi/linux/netfilter/xt_IDLETIMER.h |  1 +
 net/netfilter/ipset/ip_set_core.c   |  3 ++-
 net/netfilter/nf_tables_api.c   |  7 ---
 net/netfilter/nft_lookup.c  | 12 +++-
 net/netfilter/nft_set_bitmap.c  |  1 -
 net/netfilter/nft_set_rbtree.c  | 23 +++
 net/netfilter/xt_IDLETIMER.c|  3 +++
 9 files changed, 31 insertions(+), 23 deletions(-)

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.

[Bug 215470] New: Unable to boot NXP P2020 processor (freeze before any print to stdout)

2022-01-09 Thread bugzilla-daemon
https://bugzilla.kernel.org/show_bug.cgi?id=215470

Bug ID: 215470
   Summary: Unable to boot NXP P2020 processor (freeze before any
print to stdout)
   Product: Platform Specific/Hardware
   Version: 2.5
Kernel Version: >=v5.15-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: paweldembi...@gmail.com
Regression: No

Created attachment 300248
  --> https://bugzilla.kernel.org/attachment.cgi?id=300248=edit
my .config file

Hello,

I'm unable to boot kernel on NXP P2020 powerpc processor, image built from
mainline tree after commit:
https://lore.kernel.org/all/1fc81f07cabebb875b963e295408cc3dd38c8d85.1614674882.git.christophe.le...@csgroup.eu/

Workaround:
After revert 1fc81f07cabe, it's start work again. 

My compiler: powerpc-openwrt-linux-gcc (OpenWrt GCC 11.2.0 r18180-95697901c8)
11.2.0, GNU ld (GNU Binutils) 2.37

-- 
You may reply to this email to add a comment.

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

[Bug 215389] pagealloc: memory corruption at building glibc-2.33 and running its' testsuite

2022-01-08 Thread bugzilla-daemon
https://bugzilla.kernel.org/show_bug.cgi?id=215389

--- Comment #5 from Erhard F. (erhar...@mailbox.org) ---
Ok, with zswap lzo/zbud I also get this memory corruption on 5.15.13. So most
probably it's not lzo/z3pool but something else. I'll start a bisect then...

-- 
You may reply to this email to add a comment.

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

[Bug 215389] pagealloc: memory corruption at building glibc-2.33 and running its' testsuite

2022-01-07 Thread bugzilla-daemon
https://bugzilla.kernel.org/show_bug.cgi?id=215389

--- Comment #4 from Erhard F. (erhar...@mailbox.org) ---
I was able to easily reproduce this on 5.15.13, however not on 5.16-rc8.

But on 5.16-rc8 I got this the 3rd time I ran the glibc testsuite:

[...]
watchdog: BUG: soft lockup - CPU#1 stuck for 26s! [kworker/u4:7:32566]
Modules linked in: auth_rpcgss nfsv4 dns_resolver nfs lockd grace sunrpc
ghash_generic gf128mul gcm ccm algif_aead des_generic libdes ctr cbc ecb
algif_skcipher aes_generic libaes cmac sha512_generic sha1_generic sha1_powerpc
md5 md5_ppc md4 b43legacy mac80211 libarc4 snd_aoa_codec_tas
snd_aoa_fabric_layout snd_aoa cfg80211 rfkill evdev mac_hid therm_windtunnel
firewire_ohci firewire_core crc_itu_t sr_mod cdrom snd_aoa_i2sbus
snd_aoa_soundbus snd_pcm snd_timer snd ohci_pci soundcore radeon ohci_hcd
ehci_pci ehci_hcd hwmon i2c_algo_bit drm_ttm_helper ttm ssb drm_kms_helper
pcmcia pcmcia_core usbcore 8250_pci syscopyarea sysfillrect sysimgblt
usb_common 8250 8250_base serial_mctrl_gpio fb_sys_fops pkcs8_key_parser fuse
drm drm_panel_orientation_quirks configfs
CPU: 1 PID: 32566 Comm: kworker/u4:7 Not tainted 5.16.0-rc8-PowerMacG4 #1
Workqueue: zswap1 compact_page_work
NIP:  c0078730 LR: c0078724 CTR: 
REGS: f698dd40 TRAP: 0900   Not tainted  (5.16.0-rc8-PowerMacG4)
MSR:  9032   CR: 44008242  XER: 2000

GPR00: c01856c8 f698de00 ca20b540 0001 d4c73ffc  de0bd0bc  
GPR08:    0004 84002242  c00553fc 0001 
GPR16: 0002 d4c73fc0 c098 002ec02c 0040 d4c7300c d4c7302e c19c4bc0 
GPR24: c19c4bc0 c0185d74 ef0d0040 d4c73008 d4c74a4c 007f de0bd000 d4c74a54 
NIP [c0078730] arch_write_lock+0x28/0x3c
LR [c0078724] arch_write_lock+0x1c/0x3c
Call Trace:
[f698de00] [c0185d74] release_z3fold_page_locked+0x0/0x44 (unreliable)
[f698de20] [c01856c8] do_compact_page+0x334/0x508
[f698de80] [c004f354] process_one_work+0x1d4/0x288
[f698dec0] [c004f814] worker_thread+0x1b8/0x260
[f698df00] [c0055514] kthread+0x118/0x11c
[f698df30] [c0016268] ret_from_kernel_thread+0x5c/0x64
Instruction dump:
39610020 4bfa7668 9421ffe0 7c0802a6 90010024 93e1001c 7c7f1b78 7fe3fb78 
4b0d 2c03 41a20014 813f <2c09> 4182ffe8 4bf4 39610020 
Kernel panic - not syncing: softlockup: hung tasks
CPU: 1 PID: 32566 Comm: kworker/u4:7 Tainted: G L   
5.16.0-rc8-PowerMacG4 #1
Workqueue: zswap1 compact_page_work
Call Trace:
[f698dbb0] [c03e7f04] dump_stack_lvl+0x60/0x80 (unreliable)
[f698dbd0] [c0037734] panic+0x128/0x30c
[f698dc30] [c00c6334] watchdog_nmi_enable+0x0/0x10
[f698dc70] [c0097fc8] __hrtimer_run_queues+0xf0/0x154
[f698dcb0] [c0098b7c] hrtimer_interrupt+0xf8/0x25c
[f698dcf0] [c000d70c] timer_interrupt+0x20c/0x294
[f698dd30] [c0004a50] Decrementer_virt+0x100/0x104
--- interrupt: 900 at arch_write_lock+0x28/0x3c
NIP:  c0078730 LR: c0078724 CTR: 
REGS: f698dd40 TRAP: 0900   Tainted: G L
(5.16.0-rc8-PowerMacG4)
MSR:  9032   CR: 44008242  XER: 2000

GPR00: c01856c8 f698de00 ca20b540 0001 d4c73ffc  de0bd0bc  
GPR08:    0004 84002242  c00553fc 0001 
GPR16: 0002 d4c73fc0 c098 002ec02c 0040 d4c7300c d4c7302e c19c4bc0 
GPR24: c19c4bc0 c0185d74 ef0d0040 d4c73008 d4c74a4c 007f de0bd000 d4c74a54 
NIP [c0078730] arch_write_lock+0x28/0x3c
LR [c0078724] arch_write_lock+0x1c/0x3c
--- interrupt: 900
[f698de00] [c0185d74] release_z3fold_page_locked+0x0/0x44 (unreliable)
[f698de20] [c01856c8] do_compact_page+0x334/0x508
[f698de80] [c004f354] process_one_work+0x1d4/0x288
[f698dec0] [c004f814] worker_thread+0x1b8/0x260
[f698df00] [c0055514] kthread+0x118/0x11c
[f698df30] [c0016268] ret_from_kernel_thread+0x5c/0x64
Rebooting in 40 seconds..


Which is interesting because on bug #213837 my not yet finished bisect is also
giving hints z3fold may be the problem...

I'll check out next whether the issue is reproduceable on 5.15.x when I use
zbud or zmalloc for zswap instead of z3fold.

-- 
You may reply to this email to add a comment.

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

[Bug 215443] [radeon] BUG: Unable to handle kernel data access on read at 0xc007ffffffff9130, Oops: Kernel access of bad area, sig: 11 [#1]

2022-01-03 Thread bugzilla-daemon
https://bugzilla.kernel.org/show_bug.cgi?id=215443

--- Comment #3 from Erhard F. (erhar...@mailbox.org) ---
(In reply to Alex Deucher from comment #2)
> does appending amdgpu.runpm=0 on the kernel command line help?
I doubt it as amdgpu is not even built (# CONFIG_DRM_AMDGPU is not set, see
attached .config).

The card in question is a Radeon HD 6670 using the radeon drm module. Sorry I
forgot to mention that!

-- 
You may reply to this email to add a comment.

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

[Bug 215443] [radeon] BUG: Unable to handle kernel data access on read at 0xc007ffffffff9130, Oops: Kernel access of bad area, sig: 11 [#1]

2022-01-03 Thread bugzilla-daemon
https://bugzilla.kernel.org/show_bug.cgi?id=215443

Alex Deucher (alexdeuc...@gmail.com) changed:

   What|Removed |Added

 CC||alexdeuc...@gmail.com

--- Comment #2 from Alex Deucher (alexdeuc...@gmail.com) ---
does appending amdgpu.runpm=0 on the kernel command line help?

-- 
You may reply to this email to add a comment.

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

[Bug 215443] [radeon] BUG: Unable to handle kernel data access on read at 0xc007ffffffff9130, Oops: Kernel access of bad area, sig: 11 [#1]

2022-01-01 Thread bugzilla-daemon
https://bugzilla.kernel.org/show_bug.cgi?id=215443

--- Comment #1 from Erhard F. (erhar...@mailbox.org) ---
Created attachment 300197
  --> https://bugzilla.kernel.org/attachment.cgi?id=300197=edit
kernel .config (kernel 5.16-rc7, Talos II)

-- 
You may reply to this email to add a comment.

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

[Bug 215443] New: [radeon] BUG: Unable to handle kernel data access on read at 0xc007ffffffff9130, Oops: Kernel access of bad area, sig: 11 [#1]

2022-01-01 Thread bugzilla-daemon
https://bugzilla.kernel.org/show_bug.cgi?id=215443

Bug ID: 215443
   Summary: [radeon] BUG: Unable to handle kernel data access on
read at 0xc0079130, Oops: Kernel access of bad
area, sig: 11 [#1]
   Product: Platform Specific/Hardware
   Version: 2.5
Kernel Version: 5.16-rc7
  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
CC: dri-de...@lists.freedesktop.org
Regression: No

Created attachment 300196
  --> https://bugzilla.kernel.org/attachment.cgi?id=300196=edit
kernel dmesg (kernel 5.16-rc7, Talos II)

[...]
BUG: Unable to handle kernel data access on read at 0xc0079130
Faulting instruction address: 0xc008076a1bb4
Oops: Kernel access of bad area, sig: 11 [#1]
BE PAGE_SIZE=4K MMU=Radix SMP NR_CPUS=192 DEBUG_PAGEALLOC NUMA PowerNV
Modules linked in: rfkill evdev ecb radeon(+) snd_hda_codec_hdmi xts
drm_ttm_helper ttm snd_hda_intel snd_intel_dspcfg ctr i2c_algo_bit
snd_hda_codec snd_hwdep xhci_pci cbc ofpart snd_hda_core powernv_flash
aes_generic xhci_hcd libaes mtd ibmpowernv snd_pcm vmx_crypto gf128mul opal_prd
hwmon snd_timer drm_kms_helper usbcore at24 regmap_i2c sysimgblt usb_common
syscopyarea snd sysfillrect fb_sys_fops soundcore lz4 lz4_compress
lz4_decompress zram zsmalloc powernv_cpufreq drm fuse
drm_panel_orientation_quirks backlight configfs
CPU: 0 PID: 281 Comm: kworker/0:3 Not tainted 5.16.0-rc7-TalosII+ #1
Workqueue: events .work_for_cpu_fn
NIP:  c008076a1bb4 LR: c00808994dd8 CTR: c008076a1b80
REGS: c00011ede950 TRAP: 0300   Not tainted  (5.16.0-rc7-TalosII+)
MSR:  90009032   CR: 84048242  XER: 0006
CFAR: c008089bffe8 DAR: c0079130 DSISR: 4000 IRQMASK: 0 
GPR00: c00808994dd8 c00011edebf0 c008 0001 
GPR04: c008076dfe28 0038 0002 00024414 
GPR08: 0001 c008 c0002f3e9878 c008089bffd0 
GPR12: c008076a1b80 c33e1000 c0132940  
GPR16:  c0002f406918 c0081d9968e0  
GPR20: 0043  0001 c0002f406800 
GPR24: 0001 cefac000 c00021a6f2c0 cefac848 
GPR28: c00021a6f980  0001 c000167a9050 
NIP [c008076a1bb4] .drm_mode_object_get+0x34/0xc0 [drm]
LR [c00808994dd8] .drm_crtc_helper_set_config+0x378/0xc00 [drm_kms_helper]
Call Trace:
[c00011edebf0] [0898] 0x898 (unreliable)
[c00011edec70] [c00808994dd8] .drm_crtc_helper_set_config+0x378/0xc00
[drm_kms_helper]
[c00011ededb0] [c0081d7d29c8] .radeon_crtc_set_config+0x68/0x220
[radeon]
[c00011edee60] [c00807680ee0]
.__drm_mode_set_config_internal+0xc0/0x190 [drm]
[c00011edef00] [c008076ba1f8]
.drm_client_modeset_commit_locked+0x178/0x270 [drm]
[c00011edefa0] [c008076ba328] .drm_client_modeset_commit+0x38/0x80
[drm]
[c00011edf020] [c008089bb344]
.__drm_fb_helper_restore_fbdev_mode_unlocked+0x114/0x1c0 [drm_kms_helper]
[c00011edf0c0] [c008089bb484] .drm_fb_helper_set_par+0x44/0x90
[drm_kms_helper]
[c00011edf140] [c09ac4a4] .fbcon_init+0x594/0x800
[c00011edf230] [c09eecb8] .visual_init+0x108/0x1c0
[c00011edf2d0] [c09f25f4] .do_bind_con_driver.isra.0+0x2c4/0x550
[c00011edf3a0] [c09f2a50] .do_take_over_console+0x1d0/0x300
[c00011edf480] [c09a8ac4] .do_fbcon_takeover+0xb4/0x1b0
[c00011edf530] [c099fd9c] .register_framebuffer+0x2ac/0x480
[c00011edf630] [c008089babd4]
.__drm_fb_helper_initial_config_and_unlock+0x444/0x830 [drm_kms_helper]
[c00011edf740] [c0081d7e0278] .radeon_fbdev_init+0xf8/0x180 [radeon]
[c00011edf7d0] [c0081d7d6560] .radeon_modeset_init+0x8b0/0xe20 [radeon]
[c00011edf8b0] [c0081d79cce4] .radeon_driver_load_kms+0xc4/0x230
[radeon]
[c00011edf950] [c0080767c308] .drm_dev_register+0x128/0x2d0 [drm]
[c00011edf9f0] [c0081d798644] .radeon_pci_probe+0x124/0x1a0 [radeon]
[c00011edfa80] [c09732e0] .local_pci_probe+0x60/0x100
[c00011edfb10] [c011e260] .work_for_cpu_fn+0x30/0x50
[c00011edfb90] [c01240b0] .process_one_work+0x2f0/0x830
[c00011edfc70] [c0124840] .worker_thread+0x250/0x4f0
[c00011edfd50] [c0132b00] .kthread+0x1c0/0x1d0
[c00011edfe10] [c000cdf0] .ret_from_kernel_thread+0x58/0x60
Instruction dump:
2c29 4d820020 7c0802a6 fbe1fff8 3be30010 f8010010 f821ff81 80c30010 
3d22 80a3 78c60020 3861  48008429 6000 3921 
---[ end trace 1bbd44c839d96aca ]---

BUG: workqueue lockup - pool cpus=0 node=0 

[Bug 215389] pagealloc: memory corruption at building glibc-2.33 and running its' testsuite

2021-12-26 Thread bugzilla-daemon
https://bugzilla.kernel.org/show_bug.cgi?id=215389

--- Comment #3 from Erhard F. (erhar...@mailbox.org) ---
Bisecting will take some time. I'll report back as soon as I have any findings.

-- 
You may reply to this email to add a comment.

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

[Bug 215389] pagealloc: memory corruption at building glibc-2.33 and running its' testsuite

2021-12-24 Thread bugzilla-daemon
https://bugzilla.kernel.org/show_bug.cgi?id=215389

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

   What|Removed |Added

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

--- Comment #2 from Christophe Leroy (christophe.le...@csgroup.eu) ---
Probably hard to track.

Any chance to bisect the issue ?

-- 
You may reply to this email to add a comment.

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

[Bug 215389] pagealloc: memory corruption at building glibc-2.33 and running its' testsuite

2021-12-22 Thread bugzilla-daemon
https://bugzilla.kernel.org/show_bug.cgi?id=215389

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

-- 
You may reply to this email to add a comment.

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

[Bug 215389] New: pagealloc: memory corruption at building glibc-2.33 and running its' testsuite

2021-12-22 Thread bugzilla-daemon
https://bugzilla.kernel.org/show_bug.cgi?id=215389

Bug ID: 215389
   Summary: pagealloc: memory corruption at building glibc-2.33
and running its' testsuite
   Product: Platform Specific/Hardware
   Version: 2.5
Kernel Version: 5.15.10
  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 300113
  --> https://bugzilla.kernel.org/attachment.cgi?id=300113=edit
dmesg (5.15.10, PowerMac G4 DP)

Happens at running the glibc-2.33 testsuite on my G4 DP.

[...]
[ 5503.973022] pagealloc: memory corruption
[ 5503.973226] fffdfff0: 00 00 00 00  
[ 5503.973469] CPU: 0 PID: 15826 Comm: ld.so.1 Tainted: GW
5.15.10-gentoo-PowerMacG4 #3
[ 5503.973791] Call Trace:
[ 5503.973849] [f61edc20] [c03e8644] dump_stack_lvl+0x60/0x80 (unreliable)
[ 5503.974096] [f61edc40] [c016ece8] __kernel_unpoison_pages+0x13c/0x174
[ 5503.974320] [f61edc90] [c015aa64] post_alloc_hook+0x60/0xb4
[ 5503.974511] [f61edcb0] [c015aadc] prep_new_page+0x24/0x5c
[ 5503.974687] [f61edcd0] [c015be14] get_page_from_freelist+0x26c/0x548
[ 5503.974898] [f61edd50] [c015c5d8] __alloc_pages+0xc8/0x7a4
[ 5503.975080] [f61eddf0] [c0146470]
alloc_zeroed_user_highpage_movable.constprop.0+0x18/0x48
[ 5503.975358] [f61ede10] [c01467a8] wp_page_copy+0x58/0x4a4
[ 5503.975534] [f61ede80] [c0149df4] handle_mm_fault+0x72c/0x864
[ 5503.975725] [f61edf00] [c001a9dc] do_page_fault+0x578/0x6c8
[ 5503.975919] [f61edf30] [c000424c] DataAccess_virt+0xd4/0xe4
[ 5503.976102] --- interrupt: 300 at 0x6ffc5eb0
[ 5503.976228] NIP:  6ffc5eb0 LR: 6ffc5e84 CTR: c0335cb0
[ 5503.976383] REGS: f61edf40 TRAP: 0300   Tainted: GW 
(5.15.10-gentoo-PowerMacG4)
[ 5503.976684] MSR:  d032   CR: 840022c8  XER: 2000
[ 5503.976929] DAR: a78032e4 DSISR: 0a00 
   GPR00: 6ffc60bc af9a9650 a7a15550 0064c9ac 00896b60 0009
bcecbe5c 001282d4 
   GPR08: 00899280 a78032e4 a7809068 f61edf30 240022c2 6ffece34
008a1a90 0001 
   GPR16:  0064c9ac 0064c9e8 0064c980 008a1830 0064b8f4
000f 0009 
   GPR24: 00896b60 bcecbe5c 02c6 a7828774 a76db010 83a7
6fff4cdc 0064c9ac 
[ 5504.008476] NIP [6ffc5eb0] 0x6ffc5eb0
[ 5504.018630] LR [6ffc5e84] 0x6ffc5e84
[ 5504.028738] --- interrupt: 300
[ 5504.038956] page:ef4c8e34 refcount:1 mapcount:0 mapping: index:0x1
pfn:0x31065
[ 5504.049340] flags: 0x8000(zone=2)
[ 5504.059763] raw: 8000 0100 0122  0001 
 0001
[ 5504.070297] raw: 
[ 5504.080511] page dumped because: pagealloc: corrupted page details

The machine stays usable afterwards. Happened also a 2nd time after a reboot,
again at building glibc-2.33 and running  testsuite:

[...]
[ 2946.948834] pagealloc: memory corruption
[ 2946.949078] fffcfff0: 00 00 00 00  
[ 2946.949419] CPU: 1 PID: 31318 Comm: ld.so.1 Tainted: GW
5.15.10-gentoo-PowerMacG4 #3
[ 2946.949753] Call Trace:
[ 2946.949814] [f5c21b00] [c03e8644] dump_stack_lvl+0x60/0x80 (unreliable)
[ 2946.950054] [f5c21b20] [c016ece8] __kernel_unpoison_pages+0x13c/0x174
[ 2946.950281] [f5c21b70] [c015aa64] post_alloc_hook+0x60/0xb4
[ 2946.950476] [f5c21b90] [c015aadc] prep_new_page+0x24/0x5c
[ 2946.950651] [f5c21bb0] [c015be14] get_page_from_freelist+0x26c/0x548
[ 2946.950865] [f5c21c30] [c015c5d8] __alloc_pages+0xc8/0x7a4
[ 2946.951053] [f5c21cd0] [c011f6d4] pagecache_get_page+0x184/0x1fc
[ 2946.951259] [f5c21d30] [c029fd34] prepare_pages+0x80/0x14c
[ 2946.951442] [f5c21d80] [c02a28dc] btrfs_buffered_write+0x2b8/0x54c
[ 2946.951653] [f5c21e20] [c02a4700] btrfs_file_write_iter+0x340/0x368
[ 2946.951876] [f5c21e70] [c01892fc] vfs_write+0x18c/0x1dc
[ 2946.952057] [f5c21ef0] [c0189484] ksys_write+0x74/0xb8
[ 2946.952231] [f5c21f30] [c0015098] ret_from_syscall+0x0/0x28
[ 2946.952420] --- interrupt: c00 at 0x6fecc128
[ 2946.952547] NIP:  6fecc128 LR: 6fecc100 CTR: 0001
[ 2946.952704] REGS: f5c21f40 TRAP: 0c00   Tainted: GW 
(5.15.10-gentoo-PowerMacG4)
[ 2946.953008] MSR:  d032   CR: 24022448  XER: 
[ 2946.953267] 
   GPR00: 0004 afad5d90 a7b83550 0009 afad5e9c 2000
 6fecbfe8 
   GPR08: d032 402c551a 402c5409 f5c21f30 84022448 6ffeee28
007889b0 afad8070 
   GPR16: afad7fa0 afad8008   8000 0008
00976000 001c5bcc 
   GPR24:  afad5e9c 2000 0009 afad7e9c 
6ffbaff4 afad5e9c 
[ 2946.975430] NIP [6fecc128] 0x6fecc128
[ 2946.985730] LR [6fecc100] 0x6fecc100
[ 2946.995992] --- interrupt: c00
[ 2947.006198] page:ef4c8e34 refcount:1 

[Bug 215381] BUG: Unable to handle kernel data access on read at 0x6600cc00000004

2021-12-21 Thread bugzilla-daemon
https://bugzilla.kernel.org/show_bug.cgi?id=215381

--- Comment #1 from Erhard F. (erhar...@mailbox.org) ---
Created attachment 300107
  --> https://bugzilla.kernel.org/attachment.cgi?id=300107=edit
kernel .config (kernel 5.15.10, Talos II)

-- 
You may reply to this email to add a comment.

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

[Bug 215381] New: BUG: Unable to handle kernel data access on read at 0x6600cc00000004

2021-12-21 Thread bugzilla-daemon
https://bugzilla.kernel.org/show_bug.cgi?id=215381

Bug ID: 215381
   Summary: BUG: Unable to handle kernel data access on read at
0x6600cc0004
   Product: Platform Specific/Hardware
   Version: 2.5
Kernel Version: 5.15.10
  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 300105
  --> https://bugzilla.kernel.org/attachment.cgi?id=300105=edit
dmesg (kernel 5.15.10, Talos II)

Happened not during boot but shortly afterwards compiling some stuff via ssh.

[...]
BUG: Unable to handle kernel data access on read at 0x6600cc0004
Faulting instruction address: 0xc01398c4
Oops: Kernel access of bad area, sig: 11 [#1]
BE PAGE_SIZE=4K MMU=Radix SMP NR_CPUS=192 NUMA PowerNV
Modules linked in: auth_rpcgss nfsv4 dns_resolver nfs lockd grace sunrpc rfkill
evdev ecb xts snd_hda_codec_hdmi radeon xhci_pci snd_hda_intel ctr
snd_intel_dspcfg xhci_hcd snd_hda_codec snd_hwdep ofpart cbc snd_hda_core
drm_ttm_helper ttm snd_pcm powernv_flash i2c_algo_bit aes_generic ibmpowernv
libaes usbcore drm_kms_helper mtd at24 vmx_crypto snd_timer gf128mul opal_prd
hwmon regmap_i2c snd sysimgblt syscopyarea sysfillrect fb_sys_fops usb_common
soundcore lz4 lz4_compress lz4_decompress zram zsmalloc powernv_cpufreq drm
fuse drm_panel_orientation_quirks backlight configfs
CPU: 22 PID: 55708 Comm: clang Not tainted 5.15.10-gentoo-TalosII #1
NIP:  c01398c4 LR: c0a9b6c0 CTR: 
REGS: c00029dcef10 TRAP: 0380   Not tainted  (5.15.10-gentoo-TalosII)
MSR:  90009032   CR: 28228244  XER: 00ae
CFAR: c0a9b6bc IRQMASK: 0 
GPR00: c0315d88 c00029dcf1b0 c1256d00 006600cc 
GPR04: cd966370 3fff8dc0   
GPR08: 0009 dead4ead c00c  
GPR12: 88228244 c0002007ff7f6500 c00029dcf710 c0002595e660 
GPR16: c12a5bc0 3fff8dc3e000 c00025436080 3fff8dc5e000 
GPR20: 4000  c000297de4a0 006600cc 
GPR24: c1260985  c12a5b28  
GPR28: c00029dcf710 c12a5bc0 cd966370 006600cc 
NIP [c01398c4] .do_raw_spin_lock+0x14/0x1d0
LR [c0a9b6c0] ._raw_spin_lock+0x10/0x30
Call Trace:
[c00029dcf1b0] [00c8] 0xc8 (unreliable)
[c00029dcf230] [c029d9d4] .finish_fault+0x3e4/0x4f0
[c00029dcf2a0] [c0315d88] .__split_huge_pmd+0xe8/0x1190
[c00029dcf430] [c029a5bc] .unmap_page_range+0x43c/0xfe0
[c00029dcf5c0] [c029b618] .unmap_vmas+0xd8/0x200
[c00029dcf6a0] [c02a8324] .unmap_region+0xc4/0x160
[c00029dcf7c0] [c02ab5fc] .__do_munmap+0x1fc/0x5f0
[c00029dcf880] [c02aba70] .__vm_munmap+0x80/0x110
[c00029dcf940] [c03ef160] .elf_map+0xa0/0x120
[c00029dcf9d0] [c03f1168] .load_elf_binary+0xbf8/0x1fa0
[c00029dcfb40] [c034ecc8] .bprm_execve+0x2a8/0x700
[c00029dcfc10] [c034fcc8] .do_execveat_common.isra.0+0x188/0x230
[c00029dcfcd0] [c0350dfc] .__se_sys_execve+0x3c/0x50
[c00029dcfd40] [c002de48] .system_call_exception+0x1c8/0x530
[c00029dcfe10] [c000c068] system_call_vectored_common+0xe8/0x278
--- interrupt: 3000 at 0x3fffbd817c0c
NIP:  3fffbd817c0c LR:  CTR: 
REGS: c00029dcfe80 TRAP: 3000   Not tainted  (5.15.10-gentoo-TalosII)
MSR:  9000f032   CR: 42220442  XER:

IRQMASK: 0 
GPR00: 000b 3fffbd12dd20 3fffbd935300 2cbe3700 
GPR04: 2cc377e0 2cbe2cc0 0008 0001 
GPR08: 0001    
GPR12:  3fffbda03810  0020 
GPR16: 100514a0 005c  100348d4 
GPR20:  3fffbd125000 3fffea78ba68  
GPR24: 3fffbd12de10  3fffea78b638 3fffea78ba18 
GPR28: 2cc182c0 3fffea78ba68 0001 0010 
NIP [3fffbd817c0c] 0x3fffbd817c0c
LR [] 0x0
--- interrupt: 3000
Instruction dump:
f9430010 792907c6 6529 6129 f9230004 4e800020 6000 fbe1fff8 
f821ff81 3d20dead 7c7f1b78 61294ead <81430004> 7c0a4800 408200d4 e95f0010 
---[ end trace 063d70c8fce39c11 ]---

# inxi -bZ
System:Host: T1000 Kernel: 5.15.10-TalosII ppc64 bits: 64 Console: tty 2
Distro: Gentoo Base System release 2.7 
Machine:   Type: PowerPC Device System: T2P9D01 REV 1.01 details: PowerNV
T2P9D01 REV 1.01 rev: 2.2 (pvr 004e 1202) 
CPU: 

[Bug 215217] Kernel fails to boot at an early stage when built with GCC_PLUGIN_LATENT_ENTROPY=y (PowerMac G4 3,6)

2021-12-17 Thread bugzilla-daemon
https://bugzilla.kernel.org/show_bug.cgi?id=215217

--- Comment #14 from Erhard F. (erhar...@mailbox.org) ---
(In reply to Christophe Leroy from comment #13)
> arch/powerpc/lib/feature-fixups.o also need DISABLE_LATENT_ENTROPY_PLUGIN,
> see extract from you vmlinux below
I can confirm this works, thanks!

I need

arch/powerpc/kernel/Makefile: 
CFLAGS_early_32.o += $(DISABLE_LATENT_ENTROPY_PLUGIN)
arch/powerpc/lib/Makefile:
CFLAGS_feature-fixups.o += $(DISABLE_LATENT_ENTROPY_PLUGIN)

to make it going on my G4 with GCC_PLUGIN_LATENT_ENTROPY=y. Modifying
setup_32.o is not needed.

-- 
You may reply to this email to add a comment.

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

[Bug 215217] Kernel fails to boot at an early stage when built with GCC_PLUGIN_LATENT_ENTROPY=y (PowerMac G4 3,6)

2021-12-16 Thread bugzilla-daemon
https://bugzilla.kernel.org/show_bug.cgi?id=215217

--- Comment #13 from Christophe Leroy (christophe.le...@csgroup.eu) ---
arch/powerpc/lib/feature-fixups.o also need DISABLE_LATENT_ENTROPY_PLUGIN, see
extract from you vmlinux below


c0c0ad20 :
c0c0ad20:   94 21 ff e0 stwur1,-32(r1)
c0c0ad24:   3c 60 c0 db lis r3,-16165
c0c0ad28:   7c 08 02 a6 mflrr0
c0c0ad2c:   38 63 55 50 addir3,r3,21840
c0c0ad30:   bf 41 00 08 stmwr26,8(r1)
c0c0ad34:   7c 3f 0b 78 mr  r31,r1
c0c0ad38:   3f 60 c0 da lis r27,-16166 <== latent_entropy@h
c0c0ad3c:   90 01 00 24 stw r0,36(r1)
c0c0ad40:   3f 80 c0 d4 lis r28,-16172
c0c0ad44:   83 db 5b 50 lwz r30,23376(r27) <== latent_entropy@l
c0c0ad48:   4b 40 60 35 bl  c0010d7c 

-- 
You may reply to this email to add a comment.

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

[Bug 215285] power9 le: amdgpu: *ERROR* hw_init of IP block failed -22

2021-12-15 Thread bugzilla-daemon
https://bugzilla.kernel.org/show_bug.cgi?id=215285

--- Comment #1 from R0b0t1 (s...@aeam.us) ---
Probable cause: missing dependencies (https://bugs.gentoo.org/736994).
For PPC64, unsure of fix, see https://bugs.gentoo.org/829209 -- is there really
a hard dependency on X86_64 and ACPI?

-- 
You may reply to this email to add a comment.

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

[Bug 215217] Kernel fails to boot at an early stage when built with GCC_PLUGIN_LATENT_ENTROPY=y (PowerMac G4 3,6)

2021-12-14 Thread bugzilla-daemon
https://bugzilla.kernel.org/show_bug.cgi?id=215217

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

   What|Removed |Added

 Attachment #300015|0   |1
is obsolete||

--- Comment #12 from Erhard F. (erhar...@mailbox.org) ---
Created attachment 300027
  --> https://bugzilla.kernel.org/attachment.cgi?id=300027=edit
kernel vmlinux.xz (5.16-rc5 + CFLAGS_setup_32.o/early_32.o +=... , PowerMac G4
DP)

Ok. I .xz-compressed it afterwards as it would be too big otherwise.

-- 
You may reply to this email to add a comment.

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

[Bug 215217] Kernel fails to boot at an early stage when built with GCC_PLUGIN_LATENT_ENTROPY=y (PowerMac G4 3,6)

2021-12-13 Thread bugzilla-daemon
https://bugzilla.kernel.org/show_bug.cgi?id=215217

--- Comment #11 from Christophe Leroy (christophe.le...@csgroup.eu) ---
Ok, so that's not enough, must be something else.

I guess you are right next step should be analysis of the image.

zImage however can hardly be used for that.

Could you provide vmlinux file ?

-- 
You may reply to this email to add a comment.

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

[Bug 215217] Kernel fails to boot at an early stage when built with GCC_PLUGIN_LATENT_ENTROPY=y (PowerMac G4 3,6)

2021-12-13 Thread bugzilla-daemon
https://bugzilla.kernel.org/show_bug.cgi?id=215217

--- Comment #10 from Erhard F. (erhar...@mailbox.org) ---
Created attachment 300015
  --> https://bugzilla.kernel.org/attachment.cgi?id=300015=edit
kernel zImage (5.16-rc5 + CFLAGS_setup_32.o/early_32.o +=... , PowerMac G4 DP)

Unfortunately still no success.

Relevant section in the Makefile now looks like this:
CFLAGS_early_32.o += $(DISABLE_LATENT_ENTROPY_PLUGIN)
CFLAGS_setup_32.o += $(DISABLE_LATENT_ENTROPY_PLUGIN)
CFLAGS_cputable.o += $(DISABLE_LATENT_ENTROPY_PLUGIN)
CFLAGS_prom_init.o += $(DISABLE_LATENT_ENTROPY_PLUGIN)
CFLAGS_btext.o += $(DISABLE_LATENT_ENTROPY_PLUGIN)
CFLAGS_prom.o += $(DISABLE_LATENT_ENTROPY_PLUGIN)

I'll attach the generated zImage, maybe you can make something out of it.

-- 
You may reply to this email to add a comment.

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

[Bug 215217] Kernel fails to boot at an early stage when built with GCC_PLUGIN_LATENT_ENTROPY=y (PowerMac G4 3,6)

2021-12-13 Thread bugzilla-daemon
https://bugzilla.kernel.org/show_bug.cgi?id=215217

--- Comment #9 from Christophe Leroy (christophe.le...@csgroup.eu) ---
Erhard, were you able to redo the test with DISABLE_LATENT_ENTROPY_PLUGIN also
disabled for early_32.o  ?

If you can try with it disabled for both early_32.o and setup_32.o
Then if it works, retry with it disabled only for early_32.o

-- 
You may reply to this email to add a comment.

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

[Bug 215285] New: power9 le: amdgpu: *ERROR* hw_init of IP block failed -22

2021-12-09 Thread bugzilla-daemon
https://bugzilla.kernel.org/show_bug.cgi?id=215285

Bug ID: 215285
   Summary: power9 le: amdgpu: *ERROR* hw_init of IP block 
failed -22
   Product: Platform Specific/Hardware
   Version: 2.5
Kernel Version: 5.15.6
  Hardware: PPC-64
OS: Linux
  Tree: Mainline
Status: NEW
  Severity: high
  Priority: P1
 Component: PPC-64
  Assignee: platform_ppc...@kernel-bugs.osdl.org
  Reporter: s...@aeam.us
Regression: No

POWER9 blackbird system from Talos. GPU is 6600XT. This seems to be a flip flop
regression: https://gitlab.freedesktop.org/drm/amd/-/issues/1519

[   54.313046] [drm] Found VCN firmware Version ENC: 1.16 DEC: 2 VEP: 0
Revision: 1
[   54.313054] amdgpu :03:00.0: amdgpu: Will use PSP to load VCN firmware
[   54.314153] amdgpu :03:00.0: enabling bus mastering
[   54.570938] [drm:psp_hw_start [amdgpu]] *ERROR* PSP create ring failed!
[   54.571061] [drm:psp_hw_init [amdgpu]] *ERROR* PSP firmware loading failed
[   54.571175] [drm:amdgpu_device_fw_loading [amdgpu]] *ERROR* hw_init of IP
block  failed -22
[   54.571277] amdgpu :03:00.0: amdgpu: amdgpu_device_ip_init failed
[   54.571279] amdgpu :03:00.0: amdgpu: Fatal error during GPU init
[   54.571282] amdgpu :03:00.0: amdgpu: amdgpu: finishing device.
[   54.572789] amdgpu: probe of :03:00.0 failed with error -22

-- 
You may reply to this email to add a comment.

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

[Bug 214913] [xfstests generic/051] BUG: Kernel NULL pointer dereference on read at 0x00000108 NIP [c0000000000372e4] tm_cgpr_active+0x14/0x40

2021-12-09 Thread bugzilla-daemon
https://bugzilla.kernel.org/show_bug.cgi?id=214913

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

   What|Removed |Added

 Status|ASSIGNED|NEEDINFO

--- Comment #5 from Michael Ellerman (mich...@ellerman.id.au) ---
Sorry I don't have any idea which commit could have fixed this.

The process that crashed was "fsstress", do you know if it uses io_uring?

-- 
You may reply to this email to add a comment.

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

[Bug 215217] Kernel fails to boot at an early stage when built with GCC_PLUGIN_LATENT_ENTROPY=y (PowerMac G4 3,6)

2021-12-09 Thread bugzilla-daemon
https://bugzilla.kernel.org/show_bug.cgi?id=215217

--- Comment #8 from Christophe Leroy (christophe.le...@csgroup.eu) ---
early_32.o should likely also have DISABLE_LATENT_ENTROPY_PLUGIN, maybe even
more important that for setup_32.o

-- 
You may reply to this email to add a comment.

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

[Bug 215217] Kernel fails to boot at an early stage when built with GCC_PLUGIN_LATENT_ENTROPY=y (PowerMac G4 3,6)

2021-12-09 Thread bugzilla-daemon
https://bugzilla.kernel.org/show_bug.cgi?id=215217

--- Comment #7 from Erhard F. (erhar...@mailbox.org) ---
Created attachment 299967
  --> https://bugzilla.kernel.org/attachment.cgi?id=299967=edit
kernel .config (5.16-rc4 + CFLAGS_setup_32.o +=... , PowerMac G4 DP)

-- 
You may reply to this email to add a comment.

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

[Bug 215217] Kernel fails to boot at an early stage when built with GCC_PLUGIN_LATENT_ENTROPY=y (PowerMac G4 3,6)

2021-12-09 Thread bugzilla-daemon
https://bugzilla.kernel.org/show_bug.cgi?id=215217

--- Comment #6 from Erhard F. (erhar...@mailbox.org) ---
Ok I cheked that out. There are already some in the Makefile:

CFLAGS_cputable.o += $(DISABLE_LATENT_ENTROPY_PLUGIN)
CFLAGS_prom_init.o += $(DISABLE_LATENT_ENTROPY_PLUGIN)
CFLAGS_btext.o += $(DISABLE_LATENT_ENTROPY_PLUGIN)
CFLAGS_prom.o += $(DISABLE_LATENT_ENTROPY_PLUGIN)

I added CFLAGS_setup_32.o += $(DISABLE_LATENT_ENTROPY_PLUGIN) on top of that,
rebuilt the kernel after a make clean. No success so far, the kernel still does
not boot.

-- 
You may reply to this email to add a comment.

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

[Bug 215217] Kernel fails to boot at an early stage when built with GCC_PLUGIN_LATENT_ENTROPY=y (PowerMac G4 3,6)

2021-12-08 Thread bugzilla-daemon
https://bugzilla.kernel.org/show_bug.cgi?id=215217

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

   What|Removed |Added

 CC||mich...@ellerman.id.au

--- Comment #5 from Michael Ellerman (mich...@ellerman.id.au) ---
It's likely there's some 32-bit boot code that is being instrumented in a way
that causes it to crash.

We probably need to add some more uses of DISABLE_LATENT_ENTROPY_PLUGIN in
arch/powerpc/kernel/Makefile.

To start with you could try adding:

  CFLAGS_setup_32.o += $(DISABLE_LATENT_ENTROPY_PLUGIN)

-- 
You may reply to this email to add a comment.

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

[Bug 215217] Kernel fails to boot at an early stage when built with GCC_PLUGIN_LATENT_ENTROPY=y (PowerMac G4 3,6)

2021-12-08 Thread bugzilla-daemon
https://bugzilla.kernel.org/show_bug.cgi?id=215217

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

Hmm, strange...

I tried to bisect but found out that this issue goes back to kernel v4.18.20 at
least. This one is the earliest I am able to build with
GCC_PLUGIN_LATENT_ENTROPY=y, kernels before error out with:

make: ngcc: No such file or directory
Cannot use CONFIG_GCC_PLUGINS: plugin support on gcc <= 5.1 is buggy on
powerpc, please upgrade to gcc 5.2 or newer

I used gcc 9.4.0 and reduced the kernel .config a lot but it's still the same.
v4.18.20 with GCC_PLUGIN_LATENT_ENTROPY=y freezes at this early boot stage,
without GCC_PLUGIN_LATENT_ENTROPY booting continues.

Also GCC_PLUGIN_LATENT_ENTROPY=y makes no problem on my G5 either. So it's only
the G4 which is affected. Wildly guessing this may be a 32bit PowerPC gcc
specific thing?

-- 
You may reply to this email to add a comment.

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

[Bug 215217] Kernel fails to boot at an early stage when built with GCC_PLUGIN_LATENT_ENTROPY=y (PowerMac G4 3,6)

2021-12-05 Thread bugzilla-daemon
https://bugzilla.kernel.org/show_bug.cgi?id=215217

--- Comment #3 from Christophe Leroy (christophe.le...@csgroup.eu) ---
I tried your config under QEMU and it works. So I don't know how I could help.

>> =
>> OpenBIOS 1.1 [Jul 22 2021 22:33]
>> Configuration device id QEMU version 1 machine id 1
>> CPUs: 1
>> Memory: 2048M
>> UUID: ----
>> CPU type PowerPC,G4
milliseconds isn't unique.
Welcome to OpenBIOS v1.1 built on Jul 22 2021 22:33
>> [ppc] Kernel already loaded (0x0100 + 0x00f39460) (initrd 0x0203a000 +
>> 0x001d1a3b)
>> [ppc] Kernel command line: noreboot
>> switching to new context:
OF stdout device is: /pci@f200/mac-io@c/escc@13000/ch-a@13020
Preparing to boot Linux version 5.16.0-rc3-PowerMacG4+
(chle...@po20335.idsi0.si.c-s.fr) (powerpc64-linux-gcc (GCC) 11.1.0, GNU ld
(GNU Binutils) 2.36.1) #669 SMP Sun Dec 5 18:41:30 CET 2021
Detected machine type: 0400
command line:  
memory layout at init:
  memory_limit :  (16 MB aligned)
  alloc_bottom : 01f3e000
  alloc_top: 3000
  alloc_top_hi : 8000
  rmo_top  : 3000
  ram_top  : 8000
found display   : /pci@f200/QEMU,VGA@e, opening... done
copying OF device tree...
Building dt strings...
Building dt structure...
Device tree strings 0x01f3f000 -> 0x01f3e0a4
Device tree struct  0x01f4 -> 0x7fde7ef8
Quiescing Open Firmware ...
Booting Linux via __start() @ 0x0100 ...
Hello World !
Total memory = 2048MB; using 4096kB for hash table
Activating Kernel Userspace Execution Prevention
Activating Kernel Userspace Access Protection
Linux version 5.16.0-rc3-PowerMacG4+ (chle...@po20335.idsi0.si.c-s.fr)
(powerpc64-linux-gcc (GCC) 11.1.0, GNU ld (GNU Binutils) 2.36.1) #669 SMP Sun
Dec 5 18:41:30 CET 2021
KASAN init done
ioremap() called early from pmac_feature_init+0x248/0xfe4. Use early_ioremap()
instead
Found UniNorth memory controller & host bridge @ 0xf800 revision: 0x07
Mapped at 0xf53bf000
ioremap() called early from probe_one_macio+0x228/0x414. Use early_ioremap()
instead
Found a Keylargo mac-io controller, rev: 0, mapped at 0x(ptrval)
PowerMac motherboard: PowerMac G4 AGP Graphics
ioremap() called early from udbg_scc_init+0x1dc/0x380. Use early_ioremap()
instead
boot stdout isn't a display !
Using PowerMac machine description
printk: bootconsole [udbg0] enabled
CPU maps initialized for 1 thread per core

-- 
You may reply to this email to add a comment.

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

[Bug 215217] Kernel fails to boot at an early stage when built with GCC_PLUGIN_LATENT_ENTROPY=y (PowerMac G4 3,6)

2021-12-05 Thread bugzilla-daemon
https://bugzilla.kernel.org/show_bug.cgi?id=215217

--- Comment #2 from Erhard F. (erhar...@mailbox.org) ---
Just rebuilt the kernel without KASAN but I still hit this bug.

-- 
You may reply to this email to add a comment.

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

<    1   2   3   4   5   6   7   8   9   10   >