On 3/26/25 13:25, David Binderman wrote:
Hello there,
Static analyser cppcheck says:
linux-6.14/tools/testing/selftests/mm/pagemap_ioctl.c:1061:11: style: int
result is assigned to long long variable. If the variable is long long to avoid
loss of information, then you have loss of informatio
On 10/21/24 2:33 AM, David Hildenbrand wrote:
Am 21.10.24 um 08:48 schrieb Muhammad Usama Anjum:
...
But now comes the tricky part: an architecture defines whether it wants to
(a) Use the asm-generic unistd.h
(b) Use a custom one
E.g.,
$ cat include/uapi/linux/unistd.h
/* SPDX-License-Identi
Am 21.10.24 um 08:48 schrieb Muhammad Usama Anjum:
Hi,
The asm-generic/unistd.h file has wrong __NR_userfaultfd syscall number which
doesn't even depend on the architecture. This has caused failure of a selftest
which was fixed recently [1].
grep -rnIF "#define __NR_userfaultfd"
tools/includ
Hi,
On 2024/7/13 8:44, Jakub Kicinski wrote:
> On Fri, 12 Jul 2024 17:43:21 -0700 Jakub Kicinski wrote:
>> CC: virtio_net maintainers and Jiri who added BQL
>
> Oh, sounds like the fix may be already posted:
> https://lore.kernel.org/all/20240712080329.197605-2-jean-phili...@linaro.org/
Thanks,
On Fri, 12 Jul 2024 17:43:21 -0700 Jakub Kicinski wrote:
> CC: virtio_net maintainers and Jiri who added BQL
Oh, sounds like the fix may be already posted:
https://lore.kernel.org/all/20240712080329.197605-2-jean-phili...@linaro.org/
CC: virtio_net maintainers and Jiri who added BQL
On Fri, 12 Jul 2024 10:12:42 +0800 xiujianfeng wrote:
> On 2024/7/12 10:08, xiujianfeng wrote:
> > I found a problem with my QEMU environment, and the log is as follows.
> >
> > After I did the bisect to locate the issue, I found
> > 8490dd0592e85
On 06/04/2021 17:40, Rafael J. Wysocki wrote:
On Tue, Apr 6, 2021 at 5:51 PM John Garry wrote:
Hi guys,
On next-20210406, I enabled CONFIG_DEBUG_KMEMLEAK and
CONFIG_DEBUG_TEST_DRIVER_REMOVE for my arm64 system, and see this:
Hi Rafael,
Why exactly do you think that acpi_ev_install_space
On Tue, Apr 6, 2021 at 5:51 PM John Garry wrote:
>
> Hi guys,
>
> On next-20210406, I enabled CONFIG_DEBUG_KMEMLEAK and
> CONFIG_DEBUG_TEST_DRIVER_REMOVE for my arm64 system, and see this:
Why exactly do you think that acpi_ev_install_space_handler() leaks memory?
> root@debian:/home/john# more
On Thu, Apr 01, 2021 at 12:00:39PM +0300, Dan Carpenter wrote:
> Hi Keith,
>
> I've been trying to figure out ways Smatch can check for device managed
> resources. Like adding rules that if we call dev_set_name(&foo->bar)
> then it's device managaged and if there is a kfree(foo) without calling
>
On Thu, Apr 01, 2021 at 08:25:11AM -0300, Jason Gunthorpe wrote:
> On Thu, Apr 01, 2021 at 12:00:39PM +0300, Dan Carpenter wrote:
> > Hi Keith,
> >
> > I've been trying to figure out ways Smatch can check for device managed
> > resources. Like adding rules that if we call dev_set_name(&foo->bar)
On Thu, Apr 01, 2021 at 05:06:52PM +0300, Dan Carpenter wrote:
> > diff --git a/drivers/base/node.c b/drivers/base/node.c
> > index f449dbb2c74666..89c28952863977 100644
> > +++ b/drivers/base/node.c
> > @@ -319,25 +319,24 @@ void node_add_cache(unsigned int nid, struct
> > node_cache_attrs *cach
On Thu, Apr 01, 2021 at 12:00:39PM +0300, Dan Carpenter wrote:
> Hi Keith,
>
> I've been trying to figure out ways Smatch can check for device managed
> resources. Like adding rules that if we call dev_set_name(&foo->bar)
> then it's device managaged and if there is a kfree(foo) without calling
>
Am Montag, dem 15.02.2021 um 10:54 -0500 schrieb Sven Van Asbroeck:
> Hi Lucas,
>
> On Mon, Feb 15, 2021 at 5:15 AM Lucas Stach wrote:
> >
> > The straight forward way to fix this would be to just disable the PRE
> > when the stride is getting too large, which might not work well with
> > all us
Hi Lucas,
On Mon, Feb 15, 2021 at 5:15 AM Lucas Stach wrote:
>
> The straight forward way to fix this would be to just disable the PRE
> when the stride is getting too large, which might not work well with
> all userspace requirements, as it effectively disables the ability to
> scan GPU tiled su
Hi Sven,
Am Freitag, dem 12.02.2021 um 18:52 -0500 schrieb Sven Van Asbroeck:
> Philipp, Fabio,
>
> I was able to verify that the PREs do indeed overrun their allocated ocram
> area.
>
> Section 38.5.1 of the iMX6QuadPlus manual indicates the ocram size
> required: width(pixels) x 8 lines x 4 b
Philipp, Fabio,
I was able to verify that the PREs do indeed overrun their allocated ocram area.
Section 38.5.1 of the iMX6QuadPlus manual indicates the ocram size
required: width(pixels) x 8 lines x 4 bytes. For 2048 pixels max, this
comes to 64K. This is what the PRE driver allocates. So far, s
Hi Philipp, thank you so much for looking into this, I really appreciate it !
On Thu, Feb 11, 2021 at 9:32 AM Philipp Zabel wrote:
>
> Another thing that might help to identify who is writing where might be to
> clear the whole OCRAM region and dump it after running only decode or only
> PRE/PRG
Hi Sven,
On Wed, Feb 10, 2021 at 01:29:29PM -0500, Sven Van Asbroeck wrote:
> Found it!
>
> The i.MX6QuadPlus has two pairs of PREs, which use the extended
> section of the iRAM. The Classic does not have any PREs or extended
> iRAM:
>
> pre1: pre@21c8000 {
>compatible = "fsl,imx6qp-pre";
>
Found it!
The i.MX6QuadPlus has two pairs of PREs, which use the extended
section of the iRAM. The Classic does not have any PREs or extended
iRAM:
pre1: pre@21c8000 {
compatible = "fsl,imx6qp-pre";
fsl,iram = <&ocram2>;
};
pre3: pre@21ca000 {
compatible = "fsl,imx6qp-pre";
Bonjour Nicolas,
On Wed, Feb 10, 2021 at 11:11 AM Nicolas Dufresne wrote:
>
> Are you sure you aren't just running out of CMA ? This is the only things that
> comes to mind at the moment, sorry if it's not that useful.
Thanks for the suggestion! No worries, this is such a strange/weird
problem,
Hi Sven,
Le mercredi 03 février 2021 à 11:33 -0500, Sven Van Asbroeck a écrit :
> From: Sven Van Asbroeck
>
> We have observed that under certain repeatable circumstances, the CODA
> mem2mem device consistently generates corrupted frames. This happens only
> on an i.MX6qp (Plus) - the classic im
On Fri, Nov 13, 2020 at 09:56:37AM +0100, Vincent Guittot wrote:
> Hi Dan,
>
> Le vendredi 13 nov. 2020 à 11:46:57 (+0300), Dan Carpenter a écrit :
> > Hello Vincent Guittot,
> >
> > The patch b4c9c9f15649: "sched/fair: Prefer prev cpu in asymmetric
> > wakeup path" from Oct 29, 2020, leads to th
Hi Dan,
Le vendredi 13 nov. 2020 à 11:46:57 (+0300), Dan Carpenter a écrit :
> Hello Vincent Guittot,
>
> The patch b4c9c9f15649: "sched/fair: Prefer prev cpu in asymmetric
> wakeup path" from Oct 29, 2020, leads to the following static checker
> warning:
>
> kernel/sched/fair.c:6249 selec
On Mon, 2 Nov 2020 10:45:24 +0300
Dan Carpenter wrote:
> Hello Steven Rostedt (VMware),
>
> The patch 761a8c58db6b: "tracing, synthetic events: Replace buggy
> strcat() with seq_buf operations" from Oct 23, 2020, leads to the
> following static checker warning:
>
> kernel/trace/trace_even
Hi
Oki i find the problem is come from nf_conntrack_core
I isolate problem in this part :
queue_delayed_work(system_power_efficient_wq, &conntrack_gc_work.dwork, HZ);
When package go to queue delayed in one moment if connection track is to big
process to delayed go to lock and start high cp
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?
A: No.
Q: Should I include quotations after my reply?
http://daringfireball.net/2007/07/on_top
On Wed, Jul 08, 2020 at 11:3
Yes i search but not find any information.
And write hear to help if any have same problem or any of you have
idea from where is comme this problem.
If need more debug i will only write how to get more information.
Martin
На ср, 8.07.2020 г. в 10:09 Greg KH написа:
>
> On Wed, Jul 08, 2020 at
On Wed, Jul 08, 2020 at 09:50:49AM +0300, Martin Zaharinov wrote:
> Add Greg , Florian, Eric to this bug
>
> > On 7 Jul 2020, at 22:54, Martin Zaharinov wrote:
> >
> > And this is log from /sys/kernel/debug/tracing/trace
> >
> >
> > # entries-in-buffer/entries-written: 32410/32410 #P:64
> >
Add Greg , Florian, Eric to this bug
> On 7 Jul 2020, at 22:54, Martin Zaharinov wrote:
>
> And this is log from /sys/kernel/debug/tracing/trace
>
>
> # entries-in-buffer/entries-written: 32410/32410 #P:64
> #
> # _-=> irqs-off
> #
And this is log from /sys/kernel/debug/tracing/trace
# entries-in-buffer/entries-written: 32410/32410 #P:64
#
# _-=> irqs-off
# / _=> need-resched
#| / _---=> hardirq/softirq
#
the problem is hear with kernel 5.7.7
last work kernel without this problem is 5.6.7
hear is more info:
cat /proc/57259/stack
root@megacableamarilis:~# cat /proc/57259/stack
[<0>] gc_worker+0x1be/0x380 [nf_conntrack]
[<0>] process_one_work+0x1bc/0x3b0
[<0>] worker_thread+0x4d/0x460
[<0>] kthrea
On Fri, Aug 30, 2019 at 4:05 PM Colin Ian King wrote:
>
> Hi,
>
> Static analysis with Coverity has picked up an issue with commit:
>
> commit 205ee1187a671c3b067d7f1e974903b44036f270
> Author: Ilya Dryomov
> Date: Mon Jan 27 17:40:20 2014 +0200
>
> libceph: follow redirect replies from osd
Confirmed the following 3 upstream commits can resolve this issue:
d2a68c4effd8 x86/ftrace: Do not call function graph from dynamic trampolines
3c0dab44e227 x86/ftrace: Set trampoline pages as executable
7298e24f9042 x86/kprobes: Set instruction page as executable
And they are all included in stab
On Sun, Jun 09, 2019 at 09:10:45PM +0800, Joseph Qi wrote:
> Hi Nadav,
> Thanks for the comments.
> I'll test the 3 patches in the mentioned thread.
This should all be fixed in the latest release that happened today. If
not, please let us know.
thanks,
greg k-h
Hi Nadav,
Thanks for the comments.
I'll test the 3 patches in the mentioned thread.
Thanks,
Joseph
On 19/6/8 00:38, Nadav Amit wrote:
>> On Jun 7, 2019, at 3:24 AM, Joseph Qi wrote:
>>
>> Hi all,
>> Any idea on this regression?
>
> Sorry for the late response (I assumed, for some reason, that
> On Jun 7, 2019, at 3:24 AM, Joseph Qi wrote:
>
> Hi all,
> Any idea on this regression?
Sorry for the late response (I assumed, for some reason, that you also follow
the second thread about this issue).
Anyhow, it should be fixed by backporting some patches which were mistakenly
missed.
Se
Hi all,
Any idea on this regression?
Thanks,
Joseph
On 19/6/5 18:23, Joseph Qi wrote:
> Hi,
>
> I have encountered a kernel BUG when running ltp ftrace-stress-test
> on 4.19.48.
>
> [ 209.704855] LTP: starting ftrace-stress-test (ftrace_stress_test.sh 90)
> [ 209.739412] Scheduler tracepoint
On 4/23/19 2:48 PM, John Ogness wrote:
On 2019-04-22, Hongzhi, Song wrote:
Anyone notice this issue?
Yes, I am aware of the issue. It is actually a feature, not a bug. ;-)
Individual LOG_CONT messages, when classified as emergency messages, are
printed immediately to the console.
Yes, this
On 2019-04-22, Hongzhi, Song wrote:
> Anyone notice this issue?
Yes, I am aware of the issue. It is actually a feature, not a bug. ;-)
Individual LOG_CONT messages, when classified as emergency messages, are
printed immediately to the console. This makes them appear
"disorderly". It is not yet c
Hi all,
Anyone notice this issue?
--Hongzhi
On 4/19/19 10:24 AM, Hongzhi, Song wrote:
1. Issue description:
Boot kernel( >= linux-rt-devel-v5.0.3 ) with qemu.
Then qemu will print following disorderly messages.
At the beginning, the messages are disorderly. But then it becomes
normally fr
Hi Ken,
On Wed, Apr 03, 2019 at 05:50:09PM +, Ken Sloat wrote:
> Hello Dmitry,
>
> I may have found a potential bug in the "gpio_keys" driver. FYI, I am
> running the 4.14 LTS kernel on my system, but from my understanding of
> the issue, it seems that this would still occur in the latest ver
On 21/03/19 12:10 PM, Greg KH wrote:
> On Thu, Feb 28, 2019 at 09:19:08AM +0200, Adrian Hunter wrote:
>> On 28/02/19 4:07 AM, Joseph Qi wrote:
>>> Hi Adrian,
>>>
>>> On 19/2/27 20:39, Adrian Hunter wrote:
Seems to be fixed by this:
From: Adrian Hunter
Date: Wed, 27 Feb 2019 05:
On Thu, Feb 28, 2019 at 09:19:08AM +0200, Adrian Hunter wrote:
> On 28/02/19 4:07 AM, Joseph Qi wrote:
> > Hi Adrian,
> >
> > On 19/2/27 20:39, Adrian Hunter wrote:
> >> Seems to be fixed by this:
> >>
> >> From: Adrian Hunter
> >> Date: Wed, 27 Feb 2019 05:35:25 +0200
> >> Subject: [PATCH] perf
Hi Adrian,
On 19/2/28 15:19, Adrian Hunter wrote:
> On 28/02/19 4:07 AM, Joseph Qi wrote:
>> Hi Adrian,
>>
>> On 19/2/27 20:39, Adrian Hunter wrote:
>>> Seems to be fixed by this:
>>>
>>> From: Adrian Hunter
>>> Date: Wed, 27 Feb 2019 05:35:25 +0200
>>> Subject: [PATCH] perf probe: Fix getting th
On 28/02/19 4:07 AM, Joseph Qi wrote:
> Hi Adrian,
>
> On 19/2/27 20:39, Adrian Hunter wrote:
>> Seems to be fixed by this:
>>
>> From: Adrian Hunter
>> Date: Wed, 27 Feb 2019 05:35:25 +0200
>> Subject: [PATCH] perf probe: Fix getting the kernel map
>>
>> Since commit 4d99e4136580 ("perf machine:
Hi Adrian,
On 19/2/27 20:39, Adrian Hunter wrote:
> Seems to be fixed by this:
>
> From: Adrian Hunter
> Date: Wed, 27 Feb 2019 05:35:25 +0200
> Subject: [PATCH] perf probe: Fix getting the kernel map
>
> Since commit 4d99e4136580 ("perf machine: Workaround missing maps for x86
> PTI entry tram
On 26/02/19 4:20 PM, Arnaldo Carvalho de Melo wrote:
> Em Tue, Feb 26, 2019 at 02:08:02PM +0100, Greg KH escreveu:
>> On Tue, Feb 26, 2019 at 08:32:34PM +0800, Joseph Qi wrote:
>>>
>>>
>>> On 19/2/26 17:05, Greg KH wrote:
On Tue, Feb 26, 2019 at 03:31:14PM +0800, Joseph Qi wrote:
> Hi,
>>>
On 19/2/26 21:08, Greg KH wrote:
> On Tue, Feb 26, 2019 at 08:32:34PM +0800, Joseph Qi wrote:
>>
>>
>> On 19/2/26 17:05, Greg KH wrote:
>>> On Tue, Feb 26, 2019 at 03:31:14PM +0800, Joseph Qi wrote:
Hi,
I'm using kernel v4.19.24 and have found that there is an issue when
usin
Em Tue, Feb 26, 2019 at 02:08:02PM +0100, Greg KH escreveu:
> On Tue, Feb 26, 2019 at 08:32:34PM +0800, Joseph Qi wrote:
> >
> >
> > On 19/2/26 17:05, Greg KH wrote:
> > > On Tue, Feb 26, 2019 at 03:31:14PM +0800, Joseph Qi wrote:
> > >> Hi,
> > >>
> > >> I'm using kernel v4.19.24 and have found
On Tue, Feb 26, 2019 at 08:32:34PM +0800, Joseph Qi wrote:
>
>
> On 19/2/26 17:05, Greg KH wrote:
> > On Tue, Feb 26, 2019 at 03:31:14PM +0800, Joseph Qi wrote:
> >> Hi,
> >>
> >> I'm using kernel v4.19.24 and have found that there is an issue when
> >> using perf probe to define a new dynamic tr
On 19/2/26 17:05, Greg KH wrote:
> On Tue, Feb 26, 2019 at 03:31:14PM +0800, Joseph Qi wrote:
>> Hi,
>>
>> I'm using kernel v4.19.24 and have found that there is an issue when
>> using perf probe to define a new dynamic tracepoint.
>>
>> $ perf probe -a handle_mm_fault
>> Failed to write event:
On Tue, Feb 26, 2019 at 03:31:14PM +0800, Joseph Qi wrote:
> Hi,
>
> I'm using kernel v4.19.24 and have found that there is an issue when
> using perf probe to define a new dynamic tracepoint.
>
> $ perf probe -a handle_mm_fault
> Failed to write event: Numerical result out of range
> Error: Fa
On Wed, 2019-02-20 at 14:40 +, Colin Ian King wrote:
>
> ..when the used_hw_queues initialization was removed:
>
> @@ -360,8 +300,6 @@ int iwl_mvm_mac_ctxt_init(struct iwl_mvm *mvm,
> struct ieee80211_vif *vif)
> mvm->hw, IEEE80211_IFACE_ITER_RESUME_ALL,
> iwl_
Hi all,
I prefer to fix it. I guess people used their own correction.
I will send you a fix asap.
Best Regards
Gabriel
On 1/27/19 2:20 AM, Ken Sloat wrote:
> On Sat, Jan 26, 2019 at 5:15 PM Dmitry Torokhov
> wrote:
>> On Sat, Jan 26, 2019 at 1:25 PM Ken Sloat
>> wrote:
>>> On Tue, Jan 22
On Sat, Jan 26, 2019 at 5:15 PM Dmitry Torokhov
wrote:
>
> On Sat, Jan 26, 2019 at 1:25 PM Ken Sloat
> wrote:
> >
> > On Tue, Jan 22, 2019 at 1:53 PM Dan Carpenter
> > wrote:
> > >
> > > Hello Gabriel FERNANDEZ,
> >
> > Hello Dan,
> >
> > I have added CCs for the maintainers as well as Gabriel
On Sat, Jan 26, 2019 at 1:25 PM Ken Sloat
wrote:
>
> On Tue, Jan 22, 2019 at 1:53 PM Dan Carpenter
> wrote:
> >
> > Hello Gabriel FERNANDEZ,
>
> Hello Dan,
>
> I have added CCs for the maintainers as well as Gabriel Fernandez as
> currently you just have the linux-input mailing list
>
> > The pa
On Tue, Jan 22, 2019 at 1:53 PM Dan Carpenter wrote:
>
> Hello Gabriel FERNANDEZ,
Hello Dan,
I have added CCs for the maintainers as well as Gabriel Fernandez as
currently you just have the linux-input mailing list
> The patch 062589b13991: "Input: add st-keyscan driver" from Apr 12,
> 2014, le
Hi,
On Thu, Jan 10, 2019 at 03:01:14PM -0800, Eric Biggers wrote:
> On Fri, Jan 11, 2019 at 12:29:28AM +0200, Aaro Koskinen wrote:
> > Hi,
> >
> > On Fri, Jan 04, 2019 at 05:28:02PM +, David Howells wrote:
> > > Eric Biggers wrote:
> > > > Hi Aaro, thanks for the bug report! I think you're
On Fri, Jan 11, 2019 at 12:29:28AM +0200, Aaro Koskinen wrote:
> Hi,
>
> On Fri, Jan 04, 2019 at 05:28:02PM +, David Howells wrote:
> > Eric Biggers wrote:
> > > Hi Aaro, thanks for the bug report! I think you're on the right track;
> > > it makes
> > > much more sense to have the keyrings
Hi,
On Fri, Jan 04, 2019 at 05:28:02PM +, David Howells wrote:
> Eric Biggers wrote:
> > Hi Aaro, thanks for the bug report! I think you're on the right track; it
> > makes
> > much more sense to have the keyrings subsystem store the payload with better
> > alignment, than to work around th
Eric Biggers wrote:
> Hi Aaro, thanks for the bug report! I think you're on the right track; it
> makes
> much more sense to have the keyrings subsystem store the payload with better
> alignment, than to work around the 2-byte alignment in fscrypt.
>
> But how about '__aligned(__alignof__(u64)
On Sun, Dec 30, 2018 at 06:29:06PM +0200, Aaro Koskinen wrote:
> Hi,
>
> When using ext4 encryption on SPARC, there's plenty of dmesg noise about
> unaligned access:
>
> [ 167.269526] Kernel unaligned access at TPC[5497a0]
> find_and_lock_process_key+0x80/0x120
> [ 167.270152] Kernel unaligned
On 12/27/18 6:45 PM, Andrew Morton wrote:
> On Thu, 27 Dec 2018 11:24:31 -0800 Mike Kravetz
> wrote:
>> It would be better to make an explicit check for mapping != null before
>> calling i_mmap_lock_write/try_to_unmap. In this way, unrelated changes to
>> code above will not potentially lead to
On Thu, 27 Dec 2018 11:24:31 -0800 Mike Kravetz wrote:
> On 12/27/18 3:44 AM, Colin Ian King wrote:
> > Hi,
> >
> > Static analysis with CoverityScan on linux-next detected a potential
> > null pointer dereference with the following commit:
> >
> > From d8a1051ed4ba55679ef24e838a1942c9c40f0a14
On 12/27/18 3:44 AM, Colin Ian King wrote:
> Hi,
>
> Static analysis with CoverityScan on linux-next detected a potential
> null pointer dereference with the following commit:
>
> From d8a1051ed4ba55679ef24e838a1942c9c40f0a14 Mon Sep 17 00:00:00 2001
> From: Mike Kravetz
> Date: Sat, 22 Dec 2018
On Wed, 17 Oct 2018 at 16:50, Aaro Koskinen wrote:
>
> Hi,
>
> On Wed, Oct 17, 2018 at 03:38:07PM +0200, Mathieu Malaterre wrote:
> > Since CONFIG_PREEMPT has been 'y' since at least commit 0752f92934292
> > could you confirm that the original mmc driver (kernel from imgtech
> > people) did work o
Hi Sergey, Gregory,
Sergey Matyukevich writes:
> MacchiatoBin board fails to boot v4.20-rc1 kernel built using arm64
> defconfig. According to quick bisection of the board dts file, the
> root cause is in dts patch enabling CPU deep idle states:
> see 8ed46368776b3bc. Is there any pending fix othe
On Fri, Nov 09, 2018 at 03:11:12PM +0300, Sergey Matyukevich wrote:
> Hello Gregory,
>
> MacchiatoBin board fails to boot v4.20-rc1 kernel built using arm64
> defconfig. According to quick bisection of the board dts file, the
> root cause is in dts patch enabling CPU deep idle states:
> see 8ed463
Hi,
On Wed, Oct 17, 2018 at 03:38:07PM +0200, Mathieu Malaterre wrote:
> Since CONFIG_PREEMPT has been 'y' since at least commit 0752f92934292
> could you confirm that the original mmc driver (kernel from imgtech
> people) did work ok with PREEMPT_NONE (sorry I did not do my homework)
> ?
Sorry,
On Sun, 2018-10-14 at 20:04 +0300, Aaro Koskinen wrote:
> Hi,
>
> There is something wrong with jz4740-mmc in current mainline kernel
> (tested v4.18 and 4.19-rc, the MMC support for CI20 does not exist
> prior those), as the DMA support does not work properly if I disable
> kernel pre-emption. Th
Hi,
On Sun, Oct 14, 2018 at 7:04 PM Aaro Koskinen wrote:
>
> Hi,
>
> There is something wrong with jz4740-mmc in current mainline kernel
> (tested v4.18 and 4.19-rc, the MMC support for CI20 does not exist
> prior those), as the DMA support does not work properly if I disable
> kernel pre-emption
Quoting John Garry (2018-09-21 09:11:19)
> On 21/09/2018 06:49, Liuxinliang (Matthew Liu) wrote:
> > Hi John,
> > Thank you for reporting bug.
> > I am now using 4.18.7. I haven't found this issue yet.
> > I will try linux-next and figure out what's wrong with it.
> >
> > Thanks,
> > Xinliang
> >
>
On Tue 17-07-18 09:51:20, Baoquan He wrote:
> On 07/16/18 at 05:24pm, Michal Hocko wrote:
> > On Mon 16-07-18 21:02:02, Baoquan He wrote:
> > > On 07/16/18 at 01:38pm, Michal Hocko wrote:
> > > > On Fri 13-07-18 07:52:40, Baoquan He wrote:
> > > > > Hi Michal,
> > > > >
> > > > > On 07/12/18 at 02
On 07/16/18 at 05:24pm, Michal Hocko wrote:
> On Mon 16-07-18 21:02:02, Baoquan He wrote:
> > On 07/16/18 at 01:38pm, Michal Hocko wrote:
> > > On Fri 13-07-18 07:52:40, Baoquan He wrote:
> > > > Hi Michal,
> > > >
> > > > On 07/12/18 at 02:32pm, Michal Hocko wrote:
> > > [...]
> > > > > I am not
On Mon 16-07-18 21:02:02, Baoquan He wrote:
> On 07/16/18 at 01:38pm, Michal Hocko wrote:
> > On Fri 13-07-18 07:52:40, Baoquan He wrote:
> > > Hi Michal,
> > >
> > > On 07/12/18 at 02:32pm, Michal Hocko wrote:
> > [...]
> > > > I am not able to find the beginning of the email thread right now. Co
On 07/16/18 at 01:38pm, Michal Hocko wrote:
> On Fri 13-07-18 07:52:40, Baoquan He wrote:
> > Hi Michal,
> >
> > On 07/12/18 at 02:32pm, Michal Hocko wrote:
> [...]
> > > I am not able to find the beginning of the email thread right now. Could
> > > you summarize what is the actual problem please?
On Fri 13-07-18 07:52:40, Baoquan He wrote:
> Hi Michal,
>
> On 07/12/18 at 02:32pm, Michal Hocko wrote:
[...]
> > I am not able to find the beginning of the email thread right now. Could
> > you summarize what is the actual problem please?
>
> The bug is found on x86 now.
>
> When added "kerne
On Fri, Jul 13, 2018 at 07:52:40AM +0800, Baoquan He wrote:
>Hi Michal,
>
>On 07/12/18 at 02:32pm, Michal Hocko wrote:
>> On Thu 12-07-18 14:01:15, Chao Fan wrote:
>> > On Thu, Jul 12, 2018 at 01:49:49PM +0800, Dou Liyang wrote:
>> > >Hi Baoquan,
>> > >
>> > >At 07/11/2018 08:40 PM, Baoquan He wrot
Hi Michal,
On 07/12/18 at 02:32pm, Michal Hocko wrote:
> On Thu 12-07-18 14:01:15, Chao Fan wrote:
> > On Thu, Jul 12, 2018 at 01:49:49PM +0800, Dou Liyang wrote:
> > >Hi Baoquan,
> > >
> > >At 07/11/2018 08:40 PM, Baoquan He wrote:
> > >> Please try this v3 patch:
> > >> >>From 9850d3de9c02e570dc
On Thu 12-07-18 14:01:15, Chao Fan wrote:
> On Thu, Jul 12, 2018 at 01:49:49PM +0800, Dou Liyang wrote:
> >Hi Baoquan,
> >
> >At 07/11/2018 08:40 PM, Baoquan He wrote:
> >> Please try this v3 patch:
> >> >>From 9850d3de9c02e570dc7572069a9749a8add4c4c7 Mon Sep 17 00:00:00 2001
> >> From: Baoquan He
On 07/12/18 at 09:19am, Chao Fan wrote:
> On Wed, Jul 11, 2018 at 08:40:08PM +0800, Baoquan He wrote:
> >Please try this v3 patch:
> >
> >From 9850d3de9c02e570dc7572069a9749a8add4c4c7 Mon Sep 17 00:00:00 2001
> >From: Baoquan He
> >Date: Wed, 11 Jul 2018 20:31:51 +0800
> >Subject: [PATCH v3] mm, p
On Thu, Jul 12, 2018 at 01:49:49PM +0800, Dou Liyang wrote:
>Hi Baoquan,
>
>At 07/11/2018 08:40 PM, Baoquan He wrote:
>> Please try this v3 patch:
>> >>From 9850d3de9c02e570dc7572069a9749a8add4c4c7 Mon Sep 17 00:00:00 2001
>> From: Baoquan He
>> Date: Wed, 11 Jul 2018 20:31:51 +0800
>> Subject: [P
Hi Baoquan,
At 07/11/2018 08:40 PM, Baoquan He wrote:
Please try this v3 patch:
>>From 9850d3de9c02e570dc7572069a9749a8add4c4c7 Mon Sep 17 00:00:00 2001
From: Baoquan He
Date: Wed, 11 Jul 2018 20:31:51 +0800
Subject: [PATCH v3] mm, page_alloc: find movable zone after kernel text
In find_zone_m
On Wed, Jul 11, 2018 at 08:40:08PM +0800, Baoquan He wrote:
>Please try this v3 patch:
>
>From 9850d3de9c02e570dc7572069a9749a8add4c4c7 Mon Sep 17 00:00:00 2001
>From: Baoquan He
>Date: Wed, 11 Jul 2018 20:31:51 +0800
>Subject: [PATCH v3] mm, page_alloc: find movable zone after kernel text
>
>In f
On 07/11/18 at 06:49pm, Baoquan He wrote:
> On 07/11/18 at 06:41pm, Baoquan He wrote:
> > diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> > index 1521100..fe346b4 100644
> > --- a/mm/page_alloc.c
> > +++ b/mm/page_alloc.c
> > @@ -6678,6 +6678,8 @@ static void __init
> > find_zone_movable_pfns_for
Please try this v3 patch:
>From 9850d3de9c02e570dc7572069a9749a8add4c4c7 Mon Sep 17 00:00:00 2001
From: Baoquan He
Date: Wed, 11 Jul 2018 20:31:51 +0800
Subject: [PATCH v3] mm, page_alloc: find movable zone after kernel text
In find_zone_movable_pfns_for_nodes(), when try to find the starting
PF
On 07/11/18 at 06:41pm, Baoquan He wrote:
> Hmm, it's an issue, worth fixing it. Otherwise the size of
> movable area will be smaller than we expect when add "kernel_core="
> or "movable_core=".
>
> Add a check in find_zone_movable_pfns_for_nodes(), and use min() to get
> the starting address of
On 07/11/18 at 05:42pm, Chao Fan wrote:
> Hi all,
>
> I found there is a BUG about KASLR and ZONE_MOVABLE.
>
> When users use 'kernelcore=' parameter without 'movable_node',
> movable memory is evenly distributed to all nodes. The size of
> ZONE_MOVABLE depends on the kernel parameter 'kernelcore
More explanation:
If there is a machine with 10 nodes, and memory size in each node is
20G. Then 'kernelcore=100G' will set last 10G memory in each node as
ZONE_MOVABLE.
But if KASLR put kernel to 19G position of first node, the regions
can not be offlined. So we should set the last 1G of first ke
On Wed, Jul 11, 2018 at 05:42:44PM +0800, Chao Fan wrote:
>Hi all,
>
>I found there is a BUG about KASLR and ZONE_MOVABLE.
>
>When users use 'kernelcore=' parameter without 'movable_node',
>movable memory is evenly distributed to all nodes. The size of
>ZONE_MOVABLE depends on the kernel parameter
On Mon, Oct 23, 2017 at 3:08 PM, Bart Van Assche wrote:
> On Mon, 2017-10-23 at 09:41 -0600, dann frazier wrote:
>> (gdb) list *(sg_io+0x120)
>> 0x084e71a8 is in sg_io (./include/linux/uaccess.h:113).
>> 108 static inline unsigned long
>> 109 _copy_from_user(void *to, const void __user
On Mon, 2017-10-23 at 09:41 -0600, dann frazier wrote:
> (gdb) list *(sg_io+0x120)
> 0x084e71a8 is in sg_io (./include/linux/uaccess.h:113).
> 108 static inline unsigned long
> 109 _copy_from_user(void *to, const void __user *from, unsigned long n)
> 110 {
> 111 unsigned lon
On Fri, Oct 20, 2017 at 11:30:55PM +, Bart Van Assche wrote:
> On Fri, 2017-10-20 at 16:54 -0600, dann frazier wrote:
> > hey,
> > I'm seeing a regression when executing 'dmraid -r -c' in an arm64
> > QEMU guest, which I've bisected to the following commit:
> >
> > ca18d6f7 "block: Make mo
On Fri, 2017-10-20 at 16:54 -0600, dann frazier wrote:
> hey,
> I'm seeing a regression when executing 'dmraid -r -c' in an arm64
> QEMU guest, which I've bisected to the following commit:
>
> ca18d6f7 "block: Make most scsi_req_init() calls implicit"
>
> I haven't yet had time to try and deb
Hi Will,
On 2017/10/17 21:19, Yisheng Xie wrote:
> Hi Will,
>
> On 2017/10/17 17:23, Will Deacon wrote:
>> On Tue, Oct 17, 2017 at 10:58:53AM +0800, Tan Xiaojun wrote:
>>> I'm not sure if this is the problem on arm64 numa. What do you think ?
>>> By the way, this testcase can be successful in any
Hi Will,
On 2017/10/17 17:23, Will Deacon wrote:
> On Tue, Oct 17, 2017 at 10:58:53AM +0800, Tan Xiaojun wrote:
>> I'm not sure if this is the problem on arm64 numa. What do you think ?
>> By the way, this testcase can be successful in any case on x86.
>
> To be honest, this isn't a particularly
On 2017/10/17 17:23, Will Deacon wrote:
> On Tue, Oct 17, 2017 at 10:58:53AM +0800, Tan Xiaojun wrote:
>> I'm not sure if this is the problem on arm64 numa. What do you think ?
>> By the way, this testcase can be successful in any case on x86.
>
> To be honest, this isn't a particularly helpful bu
On Tue, Oct 17, 2017 at 10:58:53AM +0800, Tan Xiaojun wrote:
> I'm not sure if this is the problem on arm64 numa. What do you think ?
> By the way, this testcase can be successful in any case on x86.
To be honest, this isn't a particularly helpful bug report. I appreciate
that a test is reporting
Hi all,
I'm not sure if this is the problem on arm64 numa. What do you think ?
By the way, this testcase can be successful in any case on x86.
Thanks.
Xiaojun.
On 2017/10/16 19:42, Tan Xiaojun wrote:
> Hi all,
>
> I test ltp in Hisilicon D05 board and get a failed result about the testcase
> "
On Thu, Oct 12, 2017 at 01:38:24PM -0700, Paul E. McKenney wrote:
> [ Adding LKML on CC so that others can find this. ]
>
> On Wed, Oct 11, 2017 at 12:21:39PM +0800, Wang YanQing wrote:
> > Hi, Paul McKenney.
> >
> > I have received many machine-stopped-respone reports, after reboot and
> > inspe
1 - 100 of 365 matches
Mail list logo
