Hi Stephen,
On 21/07/20 11:19, Stephen Boyd wrote:
> Quoting Adam Ford (2020-07-16 05:26:20)
>> When getting the names of the child nodes, kasprintf is used to
>> allocate memory which is used to create the string for the node
>> name. Unfortunately, there is no memory check to determine
>> if th
On Tue, Jul 21, 2020 at 10:32 AM Naresh Kamboju
wrote:
>
> Kernel Internal oops while booting stable-rc 4.14 kernel on qcom db410c device
> this problem happened only once on this specific platform.
> and rcu_preempt detected stalls on CPUs/tasks detected after this and
Quoting Adam Ford (2020-07-16 05:26:20)
> When getting the names of the child nodes, kasprintf is used to
> allocate memory which is used to create the string for the node
> name. Unfortunately, there is no memory check to determine
> if this allocation fails, it may cause an error when trying
> t
Kernel Internal oops while booting stable-rc 4.14 kernel on qcom db410c device
this problem happened only once on this specific platform.
and rcu_preempt detected stalls on CPUs/tasks detected after this and
board hung.
metadata:
git branch: linux-4.14.y
git repo:
https://git.kernel.org/pub
466521] Data abort info:
> > >> [5.469971] ISV = 0, ISS = 0x0004
> > >> [5.472768] CM = 0, WnR = 0
> > >> [5.476172] user pgtable: 4k pages, 48-bit VAs, pgdp=0000bacba000
> > >> [5.479349] [0018] pgd=
From: Wei Li
[ Upstream commit 8523c006264df65aac7d77284cc69aac46a6f842 ]
After entering kdb due to breakpoint, when we execute 'ss' or 'go' (will
delay installing breakpoints, do single-step first), it won't work
correctly, and it will enter kdb due to oops.
It'
On Mon, Jul 20, 2020 at 4:28 AM Robin Murphy wrote:
>
> On 2020-07-20 08:17, Arnd Bergmann wrote:
> > On Mon, Jul 20, 2020 at 8:36 AM Naresh Kamboju
> > wrote:
> >>
> >> This kernel oops while boot linux mainline kernel on arm64 db410c device.
> >&
From: Wei Li
[ Upstream commit 8523c006264df65aac7d77284cc69aac46a6f842 ]
After entering kdb due to breakpoint, when we execute 'ss' or 'go' (will
delay installing breakpoints, do single-step first), it won't work
correctly, and it will enter kdb due to oops.
It'
From: Wei Li
[ Upstream commit 8523c006264df65aac7d77284cc69aac46a6f842 ]
After entering kdb due to breakpoint, when we execute 'ss' or 'go' (will
delay installing breakpoints, do single-step first), it won't work
correctly, and it will enter kdb due to oops.
It'
On 2020-07-20 08:17, Arnd Bergmann wrote:
On Mon, Jul 20, 2020 at 8:36 AM Naresh Kamboju
wrote:
This kernel oops while boot linux mainline kernel on arm64 db410c device.
metadata:
git branch: master
git repo: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
git
On Mon, Jul 20, 2020 at 8:36 AM Naresh Kamboju
wrote:
>
> This kernel oops while boot linux mainline kernel on arm64 db410c device.
>
> metadata:
> git branch: master
> git repo: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.
This kernel oops while boot linux mainline kernel on arm64 db410c device.
metadata:
git branch: master
git repo: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
git commit: f8456690ba8eb18ea4714e68554e242a04f65cff
git describe: v5.8-rc5-48-gf8456690ba8e
On Sun, Jul 19, 2020 at 5:47 PM Bhaskar Chowdhury wrote:
>
>CLEAN arch/x86/entry/vdso
>make[3]: *** arch/x86/platform/sfi/Makefile: Input/output error.
>Stop.
That _sounds_ like filesystem corruption on your end. EIO isn't
exactly the usual "it won't compile" problem.
bytes into the next page would oops when
the second page is unmapped. It's trivial to reproduce - all
it takes is
main()
{
int fd = open("/dev/zero", O_RDONLY);
char *p = mmap(NULL, 16384, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_ANON, -1, 0);
Goldstein (7):
ovl: relax WARN_ON() when decoding lower directory file handle
ovl: fix oops in ovl_indexdir_cleanup() with nfs_export=on
ovl: fix regression with re-formatted lower squashfs
ovl: force read-only sb on failure to create index dir
ovl: fix mount option checks for nf
On Thu, Jul 16, 2020 at 09:22:11PM +0300, Maxim Levitsky wrote:
> On Thu, 2020-07-16 at 21:21 +0300, Andy Shevchenko wrote:
> > On Thu, Jul 16, 2020 at 09:00:00PM +0300, Maxim Levitsky wrote:
> > > On Thu, 2020-07-16 at 18:47 +0300, Andy Shevchenko wrote:
...
> >
rnel:
> > >
> > > I have nvidia rtx 2070s and its USB type C port driver (which is open
> > > source)
> > > started to crash on load:
> >
> > ...
> >
> > > Reverting the commit helped fix this oops.
> > >
> > >
> > > >
> > > > Few days ago I bisected a regression on 5.8 kernel:
> > > >
> > > > I have nvidia rtx 2070s and its USB type C port driver (which is open
> > > > source)
> > > > started to crash on load:
> > >
>
is open
> > source)
> > started to crash on load:
>
> ...
>
> > Reverting the commit helped fix this oops.
> >
> > My .config attached.
> > If any more info is needed I'll be happy to provide it,
> > and of course test patches.
>
>
c1ad1e8c2160608eb9a960d69ff
> > # bad: [c2c076166b5880eabe068ce1cab30bf6edeeea1a] firmware_loader: change
> > enum fw_opt to u32
> > git bisect bad c2c076166b5880eabe068ce1cab30bf6edeeea1a
> > # bad: [2cd38fd15e4ebcfe917a443734820269f8b5ba2b] driver core: Remove
> > unne
On Thu, Jul 16, 2020 at 11:17:03AM +0300, Maxim Levitsky wrote:
> Hi!
>
> Few days ago I bisected a regression on 5.8 kernel:
>
> I have nvidia rtx 2070s and its USB type C port driver (which is open source)
> started to crash on load:
...
> Reverting the commit helped f
it bisect bad 2cd38fd15e4ebcfe917a443734820269f8b5ba2b
> # good: [c82c83c330654c5639960ebc3dabbae53c43f79e] driver core: platform: Fix
> spelling errors in platform.c
> git bisect good c82c83c330654c5639960ebc3dabbae53c43f79e
> # bad: [114dbb4fa7c4053a51964d112e2851e818e085c6] drivers property: When no
> chil
When getting the names of the child nodes, kasprintf is used to
allocate memory which is used to create the string for the node
name. Unfortunately, there is no memory check to determine
if this allocation fails, it may cause an error when trying
to get child node name.
This patch will check if t
On Thu, 2020-07-16 at 10:28 +0200, Greg KH wrote:
> On Thu, Jul 16, 2020 at 11:17:03AM +0300, Maxim Levitsky wrote:
> > Hi!
> >
> > Few days ago I bisected a regression on 5.8 kernel:
> >
> > I have nvidia rtx 2070s and its USB type C port driver (which is open
> > source)
>
> Is that driver me
On Thu, Jul 16, 2020 at 11:17:03AM +0300, Maxim Levitsky wrote:
> Hi!
>
> Few days ago I bisected a regression on 5.8 kernel:
>
> I have nvidia rtx 2070s and its USB type C port driver (which is open source)
Is that driver merged into the tree? If not, do you have a pointer to
it somewhere?
th
git bisect bad 114dbb4fa7c4053a51964d112e2851e818e085c6
# first bad commit: [114dbb4fa7c4053a51964d112e2851e818e085c6] drivers
property: When no children in primary, try secondary
Reverting the commit helped fix this oops.
My .config attached.
If any more info is needed I'll be happy to provide it,
and of course test patch
From: Wei Li
[ Upstream commit 8523c006264df65aac7d77284cc69aac46a6f842 ]
After entering kdb due to breakpoint, when we execute 'ss' or 'go' (will
delay installing breakpoints, do single-step first), it won't work
correctly, and it will enter kdb due to oops.
It'
From: Wei Li
[ Upstream commit 8523c006264df65aac7d77284cc69aac46a6f842 ]
After entering kdb due to breakpoint, when we execute 'ss' or 'go' (will
delay installing breakpoints, do single-step first), it won't work
correctly, and it will enter kdb due to oops.
It'
From: Wei Li
[ Upstream commit 8523c006264df65aac7d77284cc69aac46a6f842 ]
After entering kdb due to breakpoint, when we execute 'ss' or 'go' (will
delay installing breakpoints, do single-step first), it won't work
correctly, and it will enter kdb due to oops.
It'
On Tue 2020-07-07 17:38:46, Marcel Holtmann wrote:
> Hi Miao-chen,
>
> > This fixes the kernel oops by removing unnecessary background scan
> > update from hci_adv_monitors_clear() which shouldn't invoke any work
> > queue.
> >
> > The following test w
] Oops: 0002 [#1] PREEMPT SMP PTI
[12366.990424] CPU: 0 PID: 3016 Comm: Xorg Not tainted 5.8.0-rc4-next-20200710+
#129
[12366.990427] Hardware name: LENOVO 17097HU/17097HU, BIOS 7BETD8WW (2.19 )
03/31/2011
[12366.990436] EIP: eb_relocate_vma+0xdee/0xf50
[12366.990441] Code: 85 c0 fd ff ff ed ff ff ff
Hi Adam,
On 06/07/20 22:37, Adam Ford wrote:
> When getting the names of the child nodes, kasprintf is used to
> allocate memory which is used to create the string for the node
> name. Unfortunately, there is no memory check to determine
> if this allocation fails, it may cause an error when tryi
Hi Miao-chen,
> This fixes the kernel oops by removing unnecessary background scan
> update from hci_adv_monitors_clear() which shouldn't invoke any work
> queue.
>
> The following test was performed.
> - Run "rmmod btusb" and verify that no kernel oops is tr
wrote:
> >
> > Hi Miao-chen,
> >
> > > This fixes the kernel oops by removing unnecessary background scan
> > > update from hci_adv_monitors_clear() which shouldn't invoke any work
> > > queue.
> > >
> > > The following test was pe
When getting the names of the child nodes, kasprintf is used to
allocate memory which is used to create the string for the node
name. Unfortunately, there is no memory check to determine
if this allocation fails, it may cause an error when trying
to get child node name.
This patch will check if t
[Cc Andrew - the patch is
http://lkml.kernel.org/r/1593641660-13254-2-git-send-email-bhsha...@redhat.com]
On Thu 02-07-20 08:00:27, Michal Hocko wrote:
> On Thu 02-07-20 03:44:19, Bhupesh Sharma wrote:
> > Prabhakar reported an OOPS inside mem_cgroup_get_nr_swap_pages()
> > funct
Hi Michal,
On Thu, Jul 2, 2020 at 11:30 AM Michal Hocko wrote:
>
> On Thu 02-07-20 03:44:19, Bhupesh Sharma wrote:
> > Prabhakar reported an OOPS inside mem_cgroup_get_nr_swap_pages()
> > function in a corner case seen on some arm64 boards when kdump kernel
> > runs wit
Hi Adam,
Thank you for the patch! Perhaps something to improve:
url:
https://github.com/0day-ci/linux/commits/Adam-Ford/clk-vc5-Add-memory-check-to-prevent-oops/20200701-050451
base: https://git.kernel.org/pub/scm/linux/kernel/git/clk/linux.git clk-next
config: i386-randconfig-m021
On Thu 02-07-20 03:44:19, Bhupesh Sharma wrote:
> Prabhakar reported an OOPS inside mem_cgroup_get_nr_swap_pages()
> function in a corner case seen on some arm64 boards when kdump kernel
> runs with "cgroup_disable=memory" passed to the kdump kernel via
> bootargs.
>
&g
Prabhakar reported an OOPS inside mem_cgroup_get_nr_swap_pages()
function in a corner case seen on some arm64 boards when kdump kernel
runs with "cgroup_disable=memory" passed to the kdump kernel via
bootargs.
The root-cause behind the same is that currently mem_cgroup_swap_init()
f
the kdump kernel (via bootargs) and the crashkernel was originally
allocated from either a ZONE_DMA32 memory or mixture of memory chunks
belonging to both ZONE_DMA and ZONE_DMA32 regions.
While [PATCH 1/2] fixes the OOPS inside mem_cgroup_get_nr_swap_pages()
function, [PATCH 2/2] fixes the OOM seen
documented in
https://git-scm.com/docs/git-format-patch]
url:
https://github.com/0day-ci/linux/commits/Adam-Ford/clk-vc5-Add-memory-check-to-prevent-oops/20200701-050451
base: https://git.kernel.org/pub/scm/linux/kernel/git/clk/linux.git clk-next
config: x86_64-allyesconfig (attached as
Hi Marc,
On 6/30/20 7:05 PM, Marc Zyngier wrote:
> Booting a recent kernel on a rk3399-based system (nanopc-t4),
> equipped with a recent u-boot and ATF results in an Oops due
> to a NULL pointer dereference.
>
> This turns out to be due to the rk3399-dmc driver looking for
>
gt;
> Hi Miao-chen,
>
> > This fixes the kernel oops by removing unnecessary background scan
> > update from hci_adv_monitors_clear() which shouldn't invoke any work
> > queue.
> >
> > The following test was performed.
> > - Run "rmmod btusb" a
When getting the names of the child nodes, kasprintf is used to
allocate memory which is used to create the string for the node
name. Unfortunately, there is no memory check to determine
if this allocation fails, it may cause an error when trying
to get child node name.
This patch will check if t
Booting a recent kernel on a rk3399-based system (nanopc-t4),
equipped with a recent u-boot and ATF results in an Oops due
to a NULL pointer dereference.
This turns out to be due to the rk3399-dmc driver looking for
an *undocumented* property (rockchip,pmu), and happily using
a NULL pointer when
Hi Miao-chen,
> This fixes the kernel oops by removing unnecessary background scan
> update from hci_adv_monitors_clear() which shouldn't invoke any work
> queue.
>
> The following test was performed.
> - Run "rmmod btusb" and verify that no kernel oops is tr
This fixes the kernel oops by removing unnecessary background scan
update from hci_adv_monitors_clear() which shouldn't invoke any work
queue.
The following test was performed.
- Run "rmmod btusb" and verify that no kernel oops is triggered.
Signed-off-by: Miao-chen Chou
Review
Hi Marc,
Hi Marc,
On 6/29/20 10:22 PM, Marc Zyngier wrote:
> On 2020-06-29 12:29, Chanwoo Choi wrote:
>> Hi Enric and Mark,
>>
>> On 6/29/20 8:05 PM, Enric Balletbo i Serra wrote:
>>> Hi Chanwoo and Marc,
>>>
>>> On 29/6/20 13:09, Chanwoo Choi wrote:
Hi Enric,
Could you check this i
From: Dan Carpenter
[ Upstream commit e55f3c37cb8d31c7e301f46396b2ac6a19eb3a7c ]
If this is in "transceiver" mode the the ->qwork isn't required and is
a NULL pointer. This can lead to a NULL dereference when we call
destroy_workqueue(udc->qwork).
Fixes: 3517c31a8ece ("usb: gadget: mv_udc: use
>>
>>>>> It looks good to me. But, I think that it is not necessary
>>>>> fully kernel panic log about NULL pointer. It is enoughspsp
>>>>> just mentioning the NULL pointer issue without full kernel panic log.
>>>>
>>>> I persona
From: Dan Carpenter
[ Upstream commit e55f3c37cb8d31c7e301f46396b2ac6a19eb3a7c ]
If this is in "transceiver" mode the the ->qwork isn't required and is
a NULL pointer. This can lead to a NULL dereference when we call
destroy_workqueue(udc->qwork).
Fixes: 3517c31a8ece ("usb: gadget: mv_udc: use
From: Dan Carpenter
[ Upstream commit e55f3c37cb8d31c7e301f46396b2ac6a19eb3a7c ]
If this is in "transceiver" mode the the ->qwork isn't required and is
a NULL pointer. This can lead to a NULL dereference when we call
destroy_workqueue(udc->qwork).
Fixes: 3517c31a8ece ("usb: gadget: mv_udc: use
From: Dan Carpenter
[ Upstream commit e55f3c37cb8d31c7e301f46396b2ac6a19eb3a7c ]
If this is in "transceiver" mode the the ->qwork isn't required and is
a NULL pointer. This can lead to a NULL dereference when we call
destroy_workqueue(udc->qwork).
Fixes: 3517c31a8ece ("usb: gadget: mv_udc: use
From: Dan Carpenter
[ Upstream commit e55f3c37cb8d31c7e301f46396b2ac6a19eb3a7c ]
If this is in "transceiver" mode the the ->qwork isn't required and is
a NULL pointer. This can lead to a NULL dereference when we call
destroy_workqueue(udc->qwork).
Fixes: 3517c31a8ece ("usb: gadget: mv_udc: use
>>
>>> I personally find the backtrace useful as it allows people with the
>>> same issue to trawl the kernel log and find whether it has already be
>>> fixed upstream. But it's only me, and I'm not attached to it.
>>>
>>>> So, how about editing
e with the
> same issue to trawl the kernel log and find whether it has already be
> fixed upstream. But it's only me, and I'm not attached to it.
>
>> So, how about editing the patch description as following or others simply?
>> and we need to add 'sta...@vger.ker
ady be
>> fixed upstream. But it's only me, and I'm not attached to it.
>>
>>> So, how about editing the patch description as following or others simply?
>>> and we need to add 'sta...@vger.kernel.org' to Cc list for applying it
>>> to stab
yngier wrote:
>>>>>
>>>>> [...]
>>>>>
>>>>>> It looks good to me. But, I think that it is not necessary
>>>>>> fully kernel panic log about NULL pointer. It is enoughspsp
>>>>>> just me
From: Dan Carpenter
[ Upstream commit e55f3c37cb8d31c7e301f46396b2ac6a19eb3a7c ]
If this is in "transceiver" mode the the ->qwork isn't required and is
a NULL pointer. This can lead to a NULL dereference when we call
destroy_workqueue(udc->qwork).
Fixes: 3517c31a8ece ("usb: gadget: mv_udc: use
patch description as following or others simply?
> and we need to add 'sta...@vger.kernel.org' to Cc list for applying it
> to stable branch.
Looks good to me.
>
>
> PM / devfreq: rk3399_dmc: Fix kernel oops when rockchip,pmu is absent
>
> Booting a recent k
On 2020-06-29 12:29, Chanwoo Choi wrote:
Hi Enric and Mark,
On 6/29/20 8:05 PM, Enric Balletbo i Serra wrote:
Hi Chanwoo and Marc,
On 29/6/20 13:09, Chanwoo Choi wrote:
Hi Enric,
Could you check this issue? Your patch[1] causes this issue.
As Marc mentioned, although rk3399-dmc.c handled 'ro
0x0004
> [5.610489] CM = 0, WnR = 0
> [5.610757] user pgtable: 4k pages, 48-bit VAs, pgdp=e62fb000
> [5.611326] [01e4] pgd=, p4d=0000
> [5.611931] Internal error: Oops: 9604 [#1] SMP
> [5.612363] M
gt; Hi Pavel,
>
> > I'm getting this at boot:
> >
> > [7.984584] *pdpt = 33a31001 *pde =
> > [7.984584] Oops: [#1] PREEMPT SMP PTI
> > [7.984584] CPU: 1 PID: 2532 Comm: systemd-udevd Not tainted
> > 5.8.0-rc2-ne
Hi Pavel,
> I'm getting this at boot:
>
> [7.984584] *pdpt = 33a31001 *pde =
> [ 7.984584] Oops: [#1] PREEMPT SMP PTI
> [7.984584] CPU: 1 PID: 2532 Comm: systemd-udevd Not tainted
> 5.8.0-rc2-next-20200623+ #126
> [7.998
Hi!
I'm getting this at boot:
[7.984584] *pdpt = 33a31001 *pde =
[7.984584] Oops: [#1] PREEMPT SMP PTI
[7.984584] CPU: 1 PID: 2532 Comm: systemd-udevd Not tainted
5.8.0-rc2-next-20200623+ #126
[7.998580] Hardware name: LENOVO 17097HU/17097HU,
On 2020-06-23 09:55, Heiko Stübner wrote:
Am Montag, 22. Juni 2020, 17:07:52 CEST schrieb Marc Zyngier:
[...]
maz@fine-girl:~$ sudo dtc -I dtb /sys/firmware/fdt 2>/dev/null | grep
-A
5 dmc
dmc {
u-boot,dm-pre-reloc;
compatible = "rockchip,rk3399-dmc";
;> > [5.609600] EA = 0, S1PTW = 0
> >> > [5.609891] Data abort info:
> >> > [5.610149] ISV = 0, ISS = 0x0004
> >> > [5.610489] CM = 0, WnR = 0
> >> > [5.610757] user pgtable: 4k pages, 48-bit VAs, pgdp=
=e62fb000
[5.611326] [01e4] pgd=, p4d=
[5.611931] Internal error: Oops: 9604 [#1] SMP
[5.612363] Modules linked in: rockchip_thermal(E+) rk3399_dmc(E+)
soundcore(E) dw_wdt(E) rockchip_dfi(E) nvmem_rockchip_efuse(E) pwm_rockchip(E)
cfg80211(E
pgd=, p4d=
> [5.611931] Internal error: Oops: 9604 [#1] SMP
> [5.612363] Modules linked in: rockchip_thermal(E+) rk3399_dmc(E+)
soundcore(E) dw_wdt(E) rockchip_dfi(E) nvmem_rockchip_efuse(E) pwm_rockchip(E)
cfg80211(E+) rockchip_saradc(E) industrialio(E)
> [5.611326] [01e4] pgd=, p4d=
> > [5.611931] Internal error: Oops: 9604 [#1] SMP
> > [5.612363] Modules linked in: rockchip_thermal(E+) rk3399_dmc(E+)
> > soundcore(E) dw_wdt(E) rockchip_dfi(E) nvmem_rockchip_efuse(E)
>
.610149] ISV = 0, ISS = 0x0004
> [5.610489] CM = 0, WnR = 0
> [5.610757] user pgtable: 4k pages, 48-bit VAs, pgdp=e62fb000
> [5.611326] [01e4] pgd=, p4d=0000
> [5.611931] Internal error: Oops: 9604 [#1] SMP
> [
on the stack and uses only "suspend"
> and "resume" fields. So these newly added "get_intermediate" and
> "target_intermediate" pointers are uninitialized and contain arbitrary
> non-null values, causing all kinds of trouble.
>
> For instan
are uninitialized and contain arbitrary
> > non-null values, causing all kinds of trouble.
> >
> > For instance, here is an oops on espressobin after an attempt to change
> > the cpefreq governor:
> >
> > [ 29.174554] Unable to handle kernel execute fro
truct (pdata) located on the stack and uses only "suspend"
> and "resume" fields. So these newly added "get_intermediate" and
> "target_intermediate" pointers are uninitialized and contain arbitrary
> non-null values, causing all kinds of trouble.
>
ume" fields. So these newly added "get_intermediate" and
"target_intermediate" pointers are uninitialized and contain arbitrary
non-null values, causing all kinds of trouble.
For instance, here is an oops on espressobin after an attempt to change
the cpefreq governor:
[ 29
26:20 ...
kernel:[ 82.154129] Internal error: Oops: 9604 [#1] SMP
This patch aims to fix this problem, avoid that reading file
triggers the kernel sementfault.
Signed-off-by: limingyu
Signed-off-by: zhoubinbin
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/amd/a
26:20 ...
kernel:[ 82.154129] Internal error: Oops: 9604 [#1] SMP
This patch aims to fix this problem, avoid that reading file
triggers the kernel sementfault.
Signed-off-by: limingyu
Signed-off-by: zhoubinbin
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/amd/a
18 23:16:28 amd kernel: #PF: error_code(0x0002) - not-present page
Jun 18 23:16:28 amd kernel: *pdpt = 319d7001 *pde =
Jun 18 23:16:28 amd kernel: Oops: 0002 [#1] PREEMPT SMP PTI
Jun 18 23:16:28 amd kernel: CPU: 0 PID: 2951 Comm: Xorg Not tainted
5.8.0-rc1-next-20200618
On Wed, Jun 17, 2020 at 2:03 AM Stafford Horne wrote:
> Since v5.8-rc1 OpenRISC Linux fails to boot when DEBUG_VM is enabled.
> This has been bisected to commit 42fc541404f2 ("mmap locking API: add
> mmap_assert_locked() and mmap_assert_write_locked()").
>
> The added locking checks exposed the is
On Wed, Jun 17, 2020 at 06:07:01PM +0900, Stafford Horne wrote:
> When dumping a stack siwth 'cat /proc/1/stack' the kernel would oops.
I will fix this typo, s/siwth/with/.
-Stafford
When dumping a stack siwth 'cat /proc/1/stack' the kernel would oops.
For example:
# cat /proc/690/stack
Unable to handle kernel access
at virtual address 0x7fc60f58
Oops#:
CPU #: 0
PC: c00097fcSR: 807fSP: d6f09b9c
GPR00: GPR01
Since v5.8-rc1 OpenRISC Linux fails to boot when DEBUG_VM is enabled.
This has been bisected to commit 42fc541404f2 ("mmap locking API: add
mmap_assert_locked() and mmap_assert_write_locked()").
The added locking checks exposed the issue that OpenRISC was not taking
this mmap lock when during page
: Peter Zijlstra
CommitterDate: Mon, 15 Jun 2020 14:09:50 +02:00
perf/x86/intel/uncore: Fix oops when counting IMC uncore events on some TGL
When counting IMC uncore events on some TGL machines, an oops will be
triggered.
[ 393.101262] BUG: unable to handle page fault for address
=e62fb000
[5.611326] [01e4] pgd=, p4d=
[5.611931] Internal error: Oops: 9604 [#1] SMP
[5.612363] Modules linked in: rockchip_thermal(E+) rk3399_dmc(E+)
soundcore(E) dw_wdt(E) rockchip_dfi(E) nvmem_rockchip_efuse(E) pwm_rockchip(E)
cfg80211(E
26:20 ...
kernel:[ 82.154129] Internal error: Oops: 9604 [#1] SMP
This patch aims to fix this problem, avoid that reading file
triggers the kernel sementfault.
Signed-off-by: limingyu
Signed-off-by: zhoubinbin
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/amd/a
26:20 ...
kernel:[ 82.154129] Internal error: Oops: 9604 [#1] SMP
This patch aims to fix this problem, avoid that reading file
triggers the kernel sementfault.
Signed-off-by: limingyu
Signed-off-by: zhoubinbin
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/amd/a
Thanks!
S1PTW = 0
[0.00] Data abort info:
[0.00] ISV = 0, ISS = 0x0004
[0.00] CM = 0, WnR = 0
[0.00] [fffe8000] address between user and kernel address ranges
[0.00] Internal error: Oops: 9604 [#1] PREEMPT SMP
[0.00] Modules linked in:
[
On Wed, 03 Jun 2020, Dan Carpenter wrote:
> The callers are expecting NULL on error so if we return an error pointer
> it eventually results in an Oops.
>
> Fixes: 8ea4484d0c2b ("mailbox: Add generic mechanism for testing Mailbox
> Controllers")
> Signed-off-by: Dan
On Wed, 2020-06-03 at 15:32 +0200, Joerg Roedel wrote:
> On Wed, Jun 03, 2020 at 04:20:57PM +0530, Abdul Haleem wrote:
> > @Joerg, Could you please have a look?
>
> Can you please try the attached patch?
Thanks Joerg, The given patch fixes the boot problem.
Please add Reported-by in fix commit.
ruction address: 0xc0382304
[ 0.035074] Oops: Kernel access of bad area, sig: 11 [#1]
[0.035097] LE PAGE_SIZE=64K MMU=Radix SMP NR_CPUS=2048 NUMA PowerNV
[0.035113] Modules linked in:
[0.035136] CPU: 24 PID: 0 Comm: swapper/24 Not tainted 5.7.0-gd6f9469a0 #1
[
On Wed, Jun 03, 2020 at 04:20:57PM +0530, Abdul Haleem wrote:
> @Joerg, Could you please have a look?
Can you please try the attached patch?
diff --git a/include/asm-generic/5level-fixup.h
b/include/asm-generic/5level-fixup.h
index 58046ddc08d0..afbab31fbd7e 100644
--- a/include/asm-generic/5lev
hi Abdul,
On Wed, Jun 03, 2020 at 04:20:57PM +0530, Abdul Haleem wrote:
> Greeting's
>
> Today's mainline kernel panics when booting on my powerpc lpar
Thanks for the report, I am looking into it with my limited powerpc
knowledge. But I have an idea and will send you something to test later
toda
The callers are expecting NULL on error so if we return an error pointer
it eventually results in an Oops.
Fixes: 8ea4484d0c2b ("mailbox: Add generic mechanism for testing Mailbox
Controllers")
Signed-off-by: Dan Carpenter
---
drivers/mailbox/mailbox-test.c | 2 +-
1 file changed, 1
re not removed when the link
netns is removed. This causes later this oops when thoses interfaces are
removed.
Let's add a handler to remove all interfaces related to a netns when this
netns is removed.
Fixes: f203b76d7809 ("xfrm: Add virtual xfrm interfaces")
Reported-by: Christophe G
re not removed when the link
netns is removed. This causes later this oops when thoses interfaces are
removed.
Let's add a handler to remove all interfaces related to a netns when this
netns is removed.
Fixes: f203b76d7809 ("xfrm: Add virtual xfrm interfaces")
Reported-by: Christophe G
re not removed when the link
netns is removed. This causes later this oops when thoses interfaces are
removed.
Let's add a handler to remove all interfaces related to a netns when this
netns is removed.
Fixes: f203b76d7809 ("xfrm: Add virtual xfrm interfaces")
Reported-by: Christophe G
gt; > > >
> > > > > > Hi Roberto,
> > > > > >
> > > > > > it seems that the recent changes in IMA in linux-next caused a
> > > > > > regression: namely it triggers an Oops when booting with the options
> > > > > >
stage->args->delay_frames array could point to NULL frames.
What's weird is that we didn't notice this behavior with the
Intel Aero Yocto code.
Handle it, while adding a notice at the code, as this could
be due to some broken pipeline setup.
Signed-off-by: Mauro Carvalho Chehab
---
.../pci/isp
301 - 400 of 8581 matches
Mail list logo
