From: Eryk Rybak
[ Upstream commit 347b5650cd158d1d953487cc2bec567af5c5bf96 ]
Fix the reason of kernel oops when i40e driver removed VFs.
Added new __I40E_VFS_RELEASING state to signalize releasing
process by PF, that it makes possible to exit of reset VF procedure.
Without this patch
From: Eryk Rybak
[ Upstream commit 347b5650cd158d1d953487cc2bec567af5c5bf96 ]
Fix the reason of kernel oops when i40e driver removed VFs.
Added new __I40E_VFS_RELEASING state to signalize releasing
process by PF, that it makes possible to exit of reset VF procedure.
Without this patch
From: Eryk Rybak
[ Upstream commit 347b5650cd158d1d953487cc2bec567af5c5bf96 ]
Fix the reason of kernel oops when i40e driver removed VFs.
Added new __I40E_VFS_RELEASING state to signalize releasing
process by PF, that it makes possible to exit of reset VF procedure.
Without this patch
From: Eryk Rybak
[ Upstream commit 347b5650cd158d1d953487cc2bec567af5c5bf96 ]
Fix the reason of kernel oops when i40e driver removed VFs.
Added new __I40E_VFS_RELEASING state to signalize releasing
process by PF, that it makes possible to exit of reset VF procedure.
Without this patch
From: Alain Michaud
commit a2ec905d1e160a33b2e210e45ad30445ef26ce0e upstream.
Fix kernel oops observed when an ext adv data is larger than 31 bytes.
This can be reproduced by setting up an advertiser with advertisement
larger than 31 bytes. The issue is not sensitive to the advertisement
From: Alain Michaud
commit a2ec905d1e160a33b2e210e45ad30445ef26ce0e upstream.
Fix kernel oops observed when an ext adv data is larger than 31 bytes.
This can be reproduced by setting up an advertiser with advertisement
larger than 31 bytes. The issue is not sensitive to the advertisement
From: Alain Michaud
commit a2ec905d1e160a33b2e210e45ad30445ef26ce0e upstream.
Fix kernel oops observed when an ext adv data is larger than 31 bytes.
This can be reproduced by setting up an advertiser with advertisement
larger than 31 bytes. The issue is not sensitive to the advertisement
Hello!
The following git patch 044d0d6de9f50192f9697583504a382347ee95ca
(linux git master branch) introduced the following kernel OOPS upon
kernel boot on my sparc64 T5-2 ldom (VM):
$ uname -a
Linux ttip 5.9.0-rc2-00011-g044d0d6de9f5 #59 SMP Thu Sep 10 13:07:45
MSK 2020 sparc64 GNU/Linux
(OOPS
On Thu, Sep 10, 2020 at 4:40 PM wrote:
>
> On Thu, Sep 10, 2020 at 02:43:13PM +0300, Anatoly Pugachev wrote:
> > Hello!
> >
> > The following git patch 044d0d6de9f50192f9697583504a382347ee95ca
> > (linux git master branch) introduced the following kernel OOPS upon
&g
On Thu, Sep 10, 2020 at 02:43:13PM +0300, Anatoly Pugachev wrote:
> Hello!
>
> The following git patch 044d0d6de9f50192f9697583504a382347ee95ca
> (linux git master branch) introduced the following kernel OOPS upon
> kernel boot on my sparc64 T5-2 ldom (VM):
https://lk
From: Marc Zyngier
[ Upstream commit 63ef91f24f9bfc70b6446319f6cabfd094481372 ]
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
From: Marc Zyngier
commit 63ef91f24f9bfc70b6446319f6cabfd094481372 upstream.
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
From: Marc Zyngier
commit 63ef91f24f9bfc70b6446319f6cabfd094481372 upstream.
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
From: Alain Michaud
[ Upstream commit a2ec905d1e160a33b2e210e45ad30445ef26ce0e ]
Fix kernel oops observed when an ext adv data is larger than 31 bytes.
This can be reproduced by setting up an advertiser with advertisement
larger than 31 bytes. The issue is not sensitive to the advertisement
From: Alain Michaud
[ Upstream commit a2ec905d1e160a33b2e210e45ad30445ef26ce0e ]
Fix kernel oops observed when an ext adv data is larger than 31 bytes.
This can be reproduced by setting up an advertiser with advertisement
larger than 31 bytes. The issue is not sensitive to the advertisement
From: Alain Michaud
[ Upstream commit a2ec905d1e160a33b2e210e45ad30445ef26ce0e ]
Fix kernel oops observed when an ext adv data is larger than 31 bytes.
This can be reproduced by setting up an advertiser with advertisement
larger than 31 bytes. The issue is not sensitive to the advertisement
From: Pierre-Louis Bossart
commit 6f0307df83f2aa6bdf656c2219c89ce96502d20e upstream.
When errors happens while loading graph components, the kernel oopses
while trying to remove all topology components. This can be
root-caused to a list pointing to memory that was already freed on
error.
From: Pierre-Louis Bossart
commit 6f0307df83f2aa6bdf656c2219c89ce96502d20e upstream.
When errors happens while loading graph components, the kernel oopses
while trying to remove all topology components. This can be
root-caused to a list pointing to memory that was already freed on
error.
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:
...
> > > It works (no more oops)
> >
>
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:
> > 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
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:
> > > On Thu, Jul 16, 2020 at 11:17:03AM +0300, Maxim Levitsky wrote:
> > > > Hi!
> > > >
> > > > Few days ago
On Thu, 2020-07-16 at 18:47 +0300, Andy Shevchenko 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)
> > started
; git bisect bad 2cd38fd15e4ebcfe917a443734820269f8b5ba2b
> > # good: [c82c83c330654c5639960ebc3dabbae53c43f79e] driver core: platform:
> > Fix spelling errors in platform.c
> > git bisect good c82c83c330654c5639960ebc3dabbae53c43f79e
> > # bad: [114dbb4fa7c4053a51964d112e2851e
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 fix this oops.
>
> My
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:
I'm looking at this, but I have questions:
- any pointers
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
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?
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:
[ +0.43] CPU: 19 PID: 31281 Comm: kworker/19:1 Tainted: PW O
5.8.0-rc3.stable #133
[ +0.45] Hardware name:
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
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 trigger
rote:
> >
> > 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.
&
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
> an *undocumented*
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" and veri
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 trigger
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
Reviewed-by
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
. 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 personally find the backtrace useful as it allows people wi
ace 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 the patch description as following or others simply?
>>
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.kernel.org' to Cc list for applying it
>
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 stable branch.
>>
>> Looks good to me.
>>
[...]
>>>>>
>>>>>> 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 pan
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 kernel on a rk
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
regmap_pmu, RK3399_PMUGRF_OS_REG2, );
> @@ -399,6 +402,7 @@ static int rk3399_dmcfreq_probe(struct platform_device
> *pdev)
> goto err_edev;
> };
>
> +no_pmu:
> arm_smccc_smc(ROCKCHIP_SIP_DRAM_FREQ, 0, 0,
> ROCKCHIP_SIP_CO
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";
Am Montag, 22. Juni 2020, 17:07:52 CEST schrieb Marc Zyngier:
> Hi Heiko,
>
> On 2020-06-22 14:54, Heiko Stübner wrote:
> > Hi Marc,
> >
> > Am Montag, 22. Juni 2020, 15:31:55 CEST schrieb Marc Zyngier:
> >> On Sat, 13 Jun 2020 11:24:35 +0100
> >> Marc Zyngier wrote:
> >>
> >> > Booting a
Booting a recent kernel on a rk3399-based system (nanopc-t4),
equipped with a recent u-boot and ATF results in the following:
[5.607431] Unable to handle kernel NULL pointer dereference at virtual
address 01e4
[5.608219] Mem abort info:
[5.608469] ESR = 0x9604
[
Hi Heiko,
On 2020-06-22 14:54, Heiko Stübner wrote:
Hi Marc,
Am Montag, 22. Juni 2020, 15:31:55 CEST schrieb Marc Zyngier:
On Sat, 13 Jun 2020 11:24:35 +0100
Marc Zyngier wrote:
> Booting a recent kernel on a rk3399-based system (nanopc-t4),
> equipped with a recent u-boot and ATF results
Hi Marc,
Am Montag, 22. Juni 2020, 15:31:55 CEST schrieb Marc Zyngier:
> On Sat, 13 Jun 2020 11:24:35 +0100
> Marc Zyngier wrote:
>
> > Booting a recent kernel on a rk3399-based system (nanopc-t4),
> > equipped with a recent u-boot and ATF results in the following:
> >
> > [5.607431]
Hi Heiko,
On Sat, 13 Jun 2020 11:24:35 +0100
Marc Zyngier wrote:
> Booting a recent kernel on a rk3399-based system (nanopc-t4),
> equipped with a recent u-boot and ATF results in the following:
>
> [5.607431] Unable to handle kernel NULL pointer dereference at virtual
> address
Booting a recent kernel on a rk3399-based system (nanopc-t4),
equipped with a recent u-boot and ATF results in the following:
[5.607431] Unable to handle kernel NULL pointer dereference at virtual
address 01e4
[5.608219] Mem abort info:
[5.608469] ESR = 0x9604
[
From: Zhenyu Wang
[ Upstream commit 72a7a9925e2beea09b109dffb3384c9bf920d9da ]
As i915 won't allocate extra PDP for current default PML4 table,
so for 3-level ppgtt guest, we would hit kernel pointer access
failure on extra PDP pointers. So this trys to bypass that now.
It won't impact real
From: Zhenyu Wang
[ Upstream commit 72a7a9925e2beea09b109dffb3384c9bf920d9da ]
As i915 won't allocate extra PDP for current default PML4 table,
so for 3-level ppgtt guest, we would hit kernel pointer access
failure on extra PDP pointers. So this trys to bypass that now.
It won't impact real
From: Felix Kuehling
[ Upstream commit dcafbd50f2e4d5cc964aae409fb5691b743fba23 ]
Hawaii needs to flush caches explicitly, submitting an IB in a user
VMID from kernel mode. There is no s_fence in this case.
Fixes: eb3961a57424 ("drm/amdgpu: remove fence context from the job")
Signed-off-by:
From: Felix Kuehling
[ Upstream commit dcafbd50f2e4d5cc964aae409fb5691b743fba23 ]
Hawaii needs to flush caches explicitly, submitting an IB in a user
VMID from kernel mode. There is no s_fence in this case.
Fixes: eb3961a57424 ("drm/amdgpu: remove fence context from the job")
Signed-off-by:
The patch
spi: stm32-qspi: Fix kernel oops when unbinding driver
has been applied to the spi tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git for-5.4
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24
From: Patrice Chotard
spi_master_put() must only be called in .probe() in case of error.
As devm_spi_register_master() is used during probe, spi_master_put()
mustn't be called in .remove() callback.
It fixes the following kernel WARNING/Oops when executing
echo "58003000.spi" >
with a positive value, we currently
return that via ERR_PTR. However, because the value is positive,
it's not a ERR_VALUE proper, and is therefore treated as a
valid struct devfreq_governor pointer, leading to a kernel oops.
Fix this by returning -EINVAL if request_module returns a positive
value.
Fixes
with a positive value, we currently
return that via ERR_PTR. However, because the value is positive,
it's not a ERR_VALUE proper, and is therefore treated as a
valid struct devfreq_governor pointer, leading to a kernel oops.
Fix this by returning -EINVAL if request_module returns a positive
value.
Fixes
From: Felix Kuehling
[ Upstream commit dcafbd50f2e4d5cc964aae409fb5691b743fba23 ]
Hawaii needs to flush caches explicitly, submitting an IB in a user
VMID from kernel mode. There is no s_fence in this case.
Fixes: eb3961a57424 ("drm/amdgpu: remove fence context from the job")
Signed-off-by:
From: Felix Kuehling
[ Upstream commit dcafbd50f2e4d5cc964aae409fb5691b743fba23 ]
Hawaii needs to flush caches explicitly, submitting an IB in a user
VMID from kernel mode. There is no s_fence in this case.
Fixes: eb3961a57424 ("drm/amdgpu: remove fence context from the job")
Signed-off-by:
with a positive value, we currently
return that via ERR_PTR. However, because the value is positive,
it's not a ERR_VALUE proper, and is therefore treated as a
valid struct devfreq_governor pointer, leading to a kernel oops.
Fix this by returning -EINVAL if request_module returns a positive
value.
Fixes
with a positive value, we currently
return that via ERR_PTR. However, because the value is positive,
it's not a ERR_VALUE proper, and is therefore treated as a
valid struct devfreq_governor pointer, leading to a kernel oops.
Fix this by returning -EINVAL if request_module returns a positive
value.
Fixes
[ Upstream commit ee9d66182392695535cc9fccfcb40c16f72de2a9 ]
Fix kernel oops when mounting a encryptData CIFS share with
CONFIG_DEBUG_VIRTUAL
Signed-off-by: Sebastien Tisserant
Reviewed-by: Pavel Shilovsky
Signed-off-by: Steve French
Signed-off-by: Sasha Levin
---
fs/cifs/smb2ops.c | 10
[ Upstream commit ee9d66182392695535cc9fccfcb40c16f72de2a9 ]
Fix kernel oops when mounting a encryptData CIFS share with
CONFIG_DEBUG_VIRTUAL
Signed-off-by: Sebastien Tisserant
Reviewed-by: Pavel Shilovsky
Signed-off-by: Steve French
Signed-off-by: Sasha Levin
---
fs/cifs/smb2ops.c | 10
[ Upstream commit ee9d66182392695535cc9fccfcb40c16f72de2a9 ]
Fix kernel oops when mounting a encryptData CIFS share with
CONFIG_DEBUG_VIRTUAL
Signed-off-by: Sebastien Tisserant
Reviewed-by: Pavel Shilovsky
Signed-off-by: Steve French
Signed-off-by: Sasha Levin
---
fs/cifs/smb2ops.c | 10
From: Sebastien Tisserant
[ Upstream commit ee9d66182392695535cc9fccfcb40c16f72de2a9 ]
Fix kernel oops when mounting a encryptData CIFS share with
CONFIG_DEBUG_VIRTUAL
Signed-off-by: Sebastien Tisserant
Reviewed-by: Pavel Shilovsky
Signed-off-by: Steve French
Signed-off-by: Sasha Levin
From: Sebastien Tisserant
[ Upstream commit ee9d66182392695535cc9fccfcb40c16f72de2a9 ]
Fix kernel oops when mounting a encryptData CIFS share with
CONFIG_DEBUG_VIRTUAL
Signed-off-by: Sebastien Tisserant
Reviewed-by: Pavel Shilovsky
Signed-off-by: Steve French
Signed-off-by: Sasha Levin
From: Sebastien Tisserant
[ Upstream commit ee9d66182392695535cc9fccfcb40c16f72de2a9 ]
Fix kernel oops when mounting a encryptData CIFS share with
CONFIG_DEBUG_VIRTUAL
Signed-off-by: Sebastien Tisserant
Reviewed-by: Pavel Shilovsky
Signed-off-by: Steve French
Signed-off-by: Sasha Levin
[ Upstream commit 096701e8131425044d2054a0c210d6ea24ee7386 ]
The platform override code uses devm_ functions to allocate memory for
the new name but the card device is not initialized. Fix by moving the
init earlier.
Fixes: 4506db8043341 ("ASoC: Intel: cht_bsw_nau8824: platform name fixup
[ Upstream commit fb54555134b9b17835545e4d096b5550c27eed64 ]
The platform override code uses devm_ functions to allocate memory for
the new name but the card device is not initialized. Fix by moving the
init earlier.
Fixes: 7e7e24d7c7ff0 ("ASoC: Intel: cht_bsw_max98090_ti: platform name fixup
[ Upstream commit 9bbc799318a34061703f2a980e2b6df7fc6760f0 ]
The platform override code uses devm_ functions to allocate memory for
the new name but the card device is not initialized. Fix by moving the
init earlier.
Fixes: f403906da05cd ("ASoC: Intel: cht_bsw_rt5672: platform name fixup
[ Upstream commit 79136a016add1acb690fe8d96be50dd22a143d26 ]
The platform override code uses devm_ functions to allocate memory for
the new name but the card device is not initialized. Fix by moving the
init earlier.
Fixes: e4bc6b1195f64 ("ASoC: Intel: bytcht_es8316: platform name fixup
From: Pierre-Louis Bossart
[ Upstream commit 9bbc799318a34061703f2a980e2b6df7fc6760f0 ]
The platform override code uses devm_ functions to allocate memory for
the new name but the card device is not initialized. Fix by moving the
init earlier.
Fixes: f403906da05cd ("ASoC: Intel:
From: Pierre-Louis Bossart
[ Upstream commit fb54555134b9b17835545e4d096b5550c27eed64 ]
The platform override code uses devm_ functions to allocate memory for
the new name but the card device is not initialized. Fix by moving the
init earlier.
Fixes: 7e7e24d7c7ff0 ("ASoC: Intel:
From: Pierre-Louis Bossart
[ Upstream commit 79136a016add1acb690fe8d96be50dd22a143d26 ]
The platform override code uses devm_ functions to allocate memory for
the new name but the card device is not initialized. Fix by moving the
init earlier.
Fixes: e4bc6b1195f64 ("ASoC: Intel: bytcht_es8316:
From: Pierre-Louis Bossart
[ Upstream commit 096701e8131425044d2054a0c210d6ea24ee7386 ]
The platform override code uses devm_ functions to allocate memory for
the new name but the card device is not initialized. Fix by moving the
init earlier.
Fixes: 4506db8043341 ("ASoC: Intel:
while running kernel selftest bpf: test_btf the following kernel oops
detected on beaglebone x15 board.
Linux version 5.2.0-rc3-next-20190604
Full test log link can be found below [1]
bpf: test_btf_ #
# BTF GET_INFO test[3] (Large bpf_btf_info) OK
GET_INFO: test[3]_(Large #
# BTF GET_INFO test
On 5/20/19 8:25 PM, Nicholas Piggin wrote:
Bharata B Rao's on May 21, 2019 12:29 am:
On Mon, May 20, 2019 at 01:50:35PM +0530, Bharata B Rao wrote:
On Mon, May 20, 2019 at 05:00:21PM +1000, Nicholas Piggin wrote:
Bharata B Rao's on May 20, 2019 3:56 pm:
On Mon, May 20, 2019 at 02:48:35PM
On Tue, May 21, 2019 at 12:55:49AM +1000, Nicholas Piggin wrote:
> Bharata B Rao's on May 21, 2019 12:29 am:
> > On Mon, May 20, 2019 at 01:50:35PM +0530, Bharata B Rao wrote:
> >> On Mon, May 20, 2019 at 05:00:21PM +1000, Nicholas Piggin wrote:
> >> > Bharata B Rao's on May 20, 2019 3:56 pm:
> >>
Bharata B Rao's on May 21, 2019 12:29 am:
> On Mon, May 20, 2019 at 01:50:35PM +0530, Bharata B Rao wrote:
>> On Mon, May 20, 2019 at 05:00:21PM +1000, Nicholas Piggin wrote:
>> > Bharata B Rao's on May 20, 2019 3:56 pm:
>> > > On Mon, May 20, 2019 at 02:48:35PM +1000, Nicholas Piggin wrote:
>> >
On Mon, May 20, 2019 at 01:50:35PM +0530, Bharata B Rao wrote:
> On Mon, May 20, 2019 at 05:00:21PM +1000, Nicholas Piggin wrote:
> > Bharata B Rao's on May 20, 2019 3:56 pm:
> > > On Mon, May 20, 2019 at 02:48:35PM +1000, Nicholas Piggin wrote:
> > >> >> > git bisect points to
> > >> >> >
> > >>
On Mon, May 20, 2019 at 05:00:21PM +1000, Nicholas Piggin wrote:
> Bharata B Rao's on May 20, 2019 3:56 pm:
> > On Mon, May 20, 2019 at 02:48:35PM +1000, Nicholas Piggin wrote:
> >> >> > git bisect points to
> >> >> >
> >> >> > commit 4231aba000f5a4583dd9f67057aadb68c3eca99d
> >> >> > Author:
Bharata B Rao's on May 20, 2019 3:56 pm:
> On Mon, May 20, 2019 at 02:48:35PM +1000, Nicholas Piggin wrote:
>> >> > git bisect points to
>> >> >
>> >> > commit 4231aba000f5a4583dd9f67057aadb68c3eca99d
>> >> > Author: Nicholas Piggin
>> >> > Date: Fri Jul 27 21:48:17 2018 +1000
>> >> >
>> >> >
On Mon, May 20, 2019 at 02:48:35PM +1000, Nicholas Piggin wrote:
> >> > git bisect points to
> >> >
> >> > commit 4231aba000f5a4583dd9f67057aadb68c3eca99d
> >> > Author: Nicholas Piggin
> >> > Date: Fri Jul 27 21:48:17 2018 +1000
> >> >
> >> > powerpc/64s: Fix page table fragment refcount
performing memory hotunplug from ppc64le guest results in
>> >> kernel oops.
>> >>
>> >> Kernel used : https://github.com/torvalds/linux/tree/v5.1 built using
>> >> ppc64le_defconfig for host and ppc64le_guest_defconfig for guest.
>> >>
&
On Mon, May 20, 2019 at 12:02:23PM +1000, Michael Ellerman wrote:
> Bharata B Rao writes:
> > On Thu, May 16, 2019 at 07:44:20PM +0530, srikanth wrote:
> >> Hello,
> >>
> >> On power9 host, performing memory hotunplug from ppc64le guest results in
> >>
Bharata B Rao writes:
> On Thu, May 16, 2019 at 07:44:20PM +0530, srikanth wrote:
>> Hello,
>>
>> On power9 host, performing memory hotunplug from ppc64le guest results in
>> kernel oops.
>>
>> Kernel used : https://github.com/torvalds/linux/tree/v5.1 bu
On Thu, May 16, 2019 at 07:44:20PM +0530, srikanth wrote:
> Hello,
>
> On power9 host, performing memory hotunplug from ppc64le guest results in
> kernel oops.
>
> Kernel used : https://github.com/torvalds/linux/tree/v5.1 built using
> ppc64le_defconfig for host and pp
srikanth writes:
> Hello,
>
> On power9 host, performing memory hotunplug from ppc64le guest results
> in kernel oops.
Thanks for the report.
Did this used to work in the past? If so what is the last version that
worked?
> Kernel used : https://github.com/torvalds/linux/tree/v
Hello,
On power9 host, performing memory hotunplug from ppc64le guest results
in kernel oops.
Kernel used : https://github.com/torvalds/linux/tree/v5.1 built using
ppc64le_defconfig for host and ppc64le_guest_defconfig for guest.
Recreation steps:
1. Boot a guest with below mem
3.16.66-rc1 review patch. If anyone has any objections, please let me know.
--
From: b-ak
commit 667e9334fa64da2273e36ce131b05ac9e47c5769 upstream.
During the bootup of the kernel, the DAPM bias level is in the OFF
state. As soon as the DAPM framework kicks in it pushes the
[ Upstream commit abf7b30d7f61d981bfcca65d1e8331b27021b475 ]
In the Cirrus driver, the regular clean-up code also performs the clean-up
of a failed initialization. If the fbdev's framebuffer was not initialized,
the clean-up will fail within drm_framebuffer_unregister_private. Booting
with
4.19-stable review patch. If anyone has any objections, please let me know.
--
From: b-ak
commit 667e9334fa64da2273e36ce131b05ac9e47c5769 upstream.
During the bootup of the kernel, the DAPM bias level is in the OFF
state. As soon as the DAPM framework kicks in it pushes the
4.20-stable review patch. If anyone has any objections, please let me know.
--
From: b-ak
commit 667e9334fa64da2273e36ce131b05ac9e47c5769 upstream.
During the bootup of the kernel, the DAPM bias level is in the OFF
state. As soon as the DAPM framework kicks in it pushes the
During the bootup of the kernel, the DAPM bias level is in the OFF
state. As soon as the DAPM framework kicks in it pushes the codec
into STANDBY state.
The probe function doesn't prepare the clock, and STANDBY state
does a clk_disable_unprepare() without checking the previous state.
This leads
On Mon, Jan 07, 2019 at 12:59:07PM +, Mark Brown wrote:
> On Sat, Jan 05, 2019 at 10:16:22AM +0530, b-ak wrote:
>
> >
> > Hi Mark,
> >
> > Fixed the build error.
> >
> > Thanks,
> > Bhargav
> >
>
> Please submit patches following the process covered in
> submitting-patches.rst, don't
During the bootup of the kernel, the DAPM bias level is in the OFF
state. As soon as the DAPM framework kicks in it pushes the codec
into STANDBY state.
The probe function doesn't prepare the clock, and STANDBY state
does a clk_disable_unprepare() without checking the previous state.
This leads
On Sat, Jan 05, 2019 at 10:16:22AM +0530, b-ak wrote:
>
> Hi Mark,
>
> Fixed the build error.
>
> Thanks,
> Bhargav
>
Please submit patches following the process covered in
submitting-patches.rst, don't send them as attachments to replies in the
middle of threads. Doing that confuses all
1 - 100 of 1531 matches
Mail list logo
