On 2025-05-07 06:03, Sergey Senozhatsky wrote:
Hi,
On (25/05/06 11:09), Misbah Anjum N wrote:
I am facing this issue even with the latest kernel:
6.15.0-rc4-g5721cf0b9352
The suspecting commit is: 44f76413496ec343da0d8292ceecdcabe3e6ec16.
The
commit introduces zs_obj_write() function.
Link:
Hi,
On (25/05/06 11:09), Misbah Anjum N wrote:
> I am facing this issue even with the latest kernel: 6.15.0-rc4-g5721cf0b9352
> The suspecting commit is: 44f76413496ec343da0d8292ceecdcabe3e6ec16. The
> commit introduces zs_obj_write() function.
> Link:
> https://github.com/torvalds/linux/commit/4
Hi,
I am facing this issue even with the latest kernel:
6.15.0-rc4-g5721cf0b9352
The suspecting commit is: 44f76413496ec343da0d8292ceecdcabe3e6ec16. The
commit introduces zs_obj_write() function.
Link:
https://github.com/torvalds/linux/commit/44f76413496ec343da0d8292ceecdcabe3e6ec16
I was no
On 2025-04-21 09:19, Ritesh Harjani wrote:
Looks like the issue is happening on 6.15-rc2. Did git bisect revealed
a
faulty commit?
Looks like zsmalloc new object mapping API being called, which was
merged in rc1? But let's first confirm from git bisect, unless someone
from linux-mm who knows
OINT
> /dev/zram0 lzo-rle 8G 64K 222B 128K [SWAP]
> # swapon --show
> NAME TYPE SIZE USED PRIO
> /dev/zram0 partition 8G 0B 100
>
>
> Call Trace:
> [180060.602200] BUG: Unable to handle kernel data access on re
USED PRIO
/dev/zram0 partition 8G 0B 100
Call Trace:
[180060.602200] BUG: Unable to handle kernel data access on read at
0xc0080a1b
[180060.602219] Faulting instruction address: 0xc0175670
[180060.602224] Oops: Kernel access of bad area, sig: 11 [#1]
[180060.
https://bugzilla.kernel.org/show_bug.cgi?id=215443
Erhard F. (erhar...@mailbox.org) changed:
What|Removed |Added
Status|NEW |RESOLVED
Resol
https://bugzilla.kernel.org/show_bug.cgi?id=213733
Erhard F. (erhar...@mailbox.org) changed:
What|Removed |Added
Status|NEW |RESOLVED
Resol
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
attach
https://bugzilla.kernel.org/show_bug.cgi?id=215443
Alex Deucher (alexdeuc...@gmail.com) changed:
What|Removed |Added
CC||alexdeuc...@gmail.c
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&action=edit
kernel .config (kernel 5.16-rc7, Talos II)
--
You may reply to this email to add a comment.
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
https://bugzilla.kernel.org/show_bug.cgi?id=213733
--- Comment #1 from Erhard F. (erhar...@mailbox.org) ---
Created attachment 297859
--> https://bugzilla.kernel.org/attachment.cgi?id=297859&action=edit
kernel .config (kernel 5.14-rc1, Talos II)
--
You may reply to this email to add a comment.
https://bugzilla.kernel.org/show_bug.cgi?id=213733
Bug ID: 213733
Summary: Kernel NULL pointer dereference on read (Oops: Kernel
access of bad area, sig: 7 [#1]) at systemctl poweroff
Product: Platform Specific/Hardware
Version: 2.5
gt; > > > Machine: Power9 ZZ (PowerVM)
> > > > Test: Stress-ng
> > > >
> > > > Attached is .config file
> > > >
> > > > Traces:
> > > >
> > > > [12251.245209] Oops: Kernel access of bad area, sig: 11 [#1]
> >
t; > Kernel: 4.18.0-rc4
> > > > > Machine: Power9 ZZ (PowerVM)
> > > > > Test: Stress-ng
> > > > >
> > > > > Attached is .config file
> > > > >
> > > > > Traces:
> > > > >
> > > &g
(PowerVM)
Test: Stress-ng
Attached is .config file
Traces:
[12251.245209] Oops: Kernel access of bad area, sig: 11 [#1]
Can you post the lines above this? Otherwise we don't know what
address
it tried to access (without decoding the instructions and
reconstructing
it from registers at
;>
>>>
>>> Kernel: 4.18.0-rc4
>>> Machine: Power9 ZZ (PowerVM)
>>> Test: Stress-ng
>>>
>>> Attached is .config file
>>>
>>> Traces:
>>>
>>> [12251.245209] Oops: Kernel access of bad ar
:
[12251.245209] Oops: Kernel access of bad area, sig: 11 [#1]
Can you post the lines above this? Otherwise we don't know what address
it tried to access (without decoding the instructions and
reconstructing
it from registers at least, which the XFS devs wouldn't be inclined to
do).
> Traces:
>
> [12251.245209] Oops: Kernel access of bad area, sig: 11 [#1]
Can you post the lines above this? Otherwise we don't know what address
it tried to access (without decoding the instructions and reconstructing
it from registers at least, which the XFS devs wouldn't
On Thu, 20 Dec 2007, Nathan Lynch wrote:
> Better to include the full stack trace in such reports,
Hm, I did not want to clutter the mail with all this stuff, but you're
right, in this case it would've made sense...
> So it looks like the kernel oopsed while firefox was dumping core,
> yuck. It'
le to handle kernel paging request for data at address
> 0x4815d000
> [84983.751046] Faulting instruction address: 0xc0012090
> [84983.751157] Oops: Kernel access of bad area, sig: 11 [#1]
> [84983.751178] PREEMPT PowerMac
> [84983.751214] Modules linked in: nls_iso8859_15 nls_cp850 vf
046] Faulting instruction address: 0xc0012090
[84983.751157] Oops: Kernel access of bad area, sig: 11 [#1]
[84983.751178] PREEMPT PowerMac
[84983.751214] Modules linked in: nls_iso8859_15 nls_cp850 vfat fat isofs
nls_base zlib_inflate radeon drm snd_powermac snd_pcm snd_timer snd soundcore
snd_pa
23 matches
Mail list logo
