Hello Steven Rostedt (Google),
Commit 5f3b6e839f3c ("ring-buffer: Validate boot range memory
events") from Jun 12, 2024 (linux-next), leads to the following
Smatch static checker warning:
kernel/trace/ring_buffer.c:1824 rb_meta_validate_events()
error: uninitialized symbol
On Wed, 20 Mar 2024 12:44:23 +0900
Masami Hiramatsu (Google) wrote:
> > > kernel/trace/trace_probe.c
> > > 846 return;
> > > 847
> > > 848 for (i = 0; i < earg->size; i++) {
> > > 849 struct fetch_insn *code = >code[i];
> > > 850
> >
On Tue, 19 Mar 2024 10:10:00 -0400
Steven Rostedt wrote:
> On Tue, 19 Mar 2024 10:19:09 +0300
> Dan Carpenter wrote:
>
> > Hello Masami Hiramatsu (Google),
> >
> > Commit 25f00e40ce79 ("tracing/probes: Support $argN in return probe
> > (kprobe and fprobe)") from Mar 4, 2024 (linux-next),
On Tue, Mar 19, 2024 at 10:10:00AM -0400, Steven Rostedt wrote:
> On Tue, 19 Mar 2024 10:19:09 +0300
> Dan Carpenter wrote:
>
> > Hello Masami Hiramatsu (Google),
> >
> > Commit 25f00e40ce79 ("tracing/probes: Support $argN in return probe
> > (kprobe and fprobe)") from Mar 4, 2024 (linux-next),
On Tue, 19 Mar 2024 10:19:09 +0300
Dan Carpenter wrote:
> Hello Masami Hiramatsu (Google),
>
> Commit 25f00e40ce79 ("tracing/probes: Support $argN in return probe
> (kprobe and fprobe)") from Mar 4, 2024 (linux-next), leads to the
> following Smatch static checker warning:
>
>
Hello Masami Hiramatsu (Google),
Commit 25f00e40ce79 ("tracing/probes: Support $argN in return probe
(kprobe and fprobe)") from Mar 4, 2024 (linux-next), leads to the
following Smatch static checker warning:
kernel/trace/trace_probe.c:856 store_trace_entry_data()
error:
Hello Steven Rostedt (Google),
The patch 704f960dbee2: "eventfs: Read ei->entries before
ei->children in eventfs_iterate()" from Jan 4, 2024 (linux-next),
leads to the following Smatch static checker warning:
fs/tracefs/event_inode.c:775 eventfs_iterate()
warn: missing error code
Hello Steven Rostedt (Google),
The patch 5790b1fb3d67: "eventfs: Remove eventfs_file and just use
eventfs_inode" from Oct 4, 2023 (linux-next), leads to the following
Smatch static checker warning:
fs/tracefs/event_inode.c:782 eventfs_create_events_dir()
error: potential null
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
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
Hi guys,
On next-20210406, I enabled CONFIG_DEBUG_KMEMLEAK and
CONFIG_DEBUG_TEST_DRIVER_REMOVE for my arm64 system, and see this:
root@debian:/home/john# more /sys/kernel/debug/kmemleak
unreferenced object 0x202803c11f00 (size 128):
comm "swapper/0", pid 1, jiffies 4294894325 (age 337.524s)
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(>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(>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
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(>bar)
> then it's device managaged and if there is a kfree(foo) without calling
>
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(>bar)
then it's device managaged and if there is a kfree(foo) without calling
device_put(>bar) then that's a resource leak.
Of course one of the rules is
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
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
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
bbaraya Sundeep Bhatta; David S. Miller;
>Jakub >Kicinski
>Cc: net...@vger.kernel.org; linux-kernel@vger.kernel.org; Gustavo A. R. Silva
>Subject: [EXT] [bug report] octeontx2-af: cn10k: Uninitialized variables
>External Email
-
Bhatta; David S. Miller;
>Jakub >Kicinski
>Cc: net...@vger.kernel.org; linux-kernel@vger.kernel.org; Gustavo A. R. Silva
>Subject: [EXT] [bug report] octeontx2-af: cn10k: Identical code for different
>branches
>External Email
---
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,
Hi,
In file drivers/net/ethernet/marvell/octeontx2/af/rvu_debugfs.c, function
rvu_dbg_init()
the same code is executed for both branches:
2431 if (is_rvu_otx2(rvu))
2432 debugfs_create_file("rvu_pf_cgx_map", 0444,
rvu->rvu_dbg.root,
2433
Hi,
Variables cgx_id and lmac_id are being used uninitialized at lines 731
and 733 in the following function:
723 static int rvu_cgx_config_intlbk(struct rvu *rvu, u16 pcifunc, bool en)
724 {
725 struct mac_ops *mac_ops;
726 u8 cgx_id, lmac_id;
727
728 if
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 = <>;
};
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
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 imx6q is not affected.
This happens when the virtual X screen is wider than 0x900 pixels
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
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
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 select_idle_sibling()
error: uninitialized symbol 'task_util'.
kernel/sched/fair.c
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:
>
>
Hello folks,
We observed that Arm VM instance (Centos 8) runs into timeout at boot time when
it is launched by Qemu/KVM on an Arm server host that enabled hugepages
(2MB/1GB).
We also noticed that Will has a workaround that applies to the guest kernel
Hi,
Static analysis with Coverity has detected an issue with the following
commit:
commit 2a6c0b82e65128c73b5102e00e031c5e58bb3504
Author: 周琰杰 (Zhou Yanjie)
Date: Thu Jul 23 14:13:00 2020 +0800
USB: PHY: JZ4770: Add support for new Ingenic SoCs.
The analysis from Coverity is as follows:
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, _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 cpu load.
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
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
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>]
From: Alan Stern
[ Upstream commit ac854131d9844f79e2fdcef67a7707227538d78a ]
The syzbot fuzzer found a race between URB submission to endpoint 0
and device reset. Namely, during the reset we call usb_ep0_reinit()
because the characteristics of ep0 may have changed (if the reset
follows a
From: Alan Stern
[ Upstream commit ac854131d9844f79e2fdcef67a7707227538d78a ]
The syzbot fuzzer found a race between URB submission to endpoint 0
and device reset. Namely, during the reset we call usb_ep0_reinit()
because the characteristics of ep0 may have changed (if the reset
follows a
From: Alan Stern
[ Upstream commit ac854131d9844f79e2fdcef67a7707227538d78a ]
The syzbot fuzzer found a race between URB submission to endpoint 0
and device reset. Namely, during the reset we call usb_ep0_reinit()
because the characteristics of ep0 may have changed (if the reset
follows a
From: Alan Stern
[ Upstream commit ac854131d9844f79e2fdcef67a7707227538d78a ]
The syzbot fuzzer found a race between URB submission to endpoint 0
and device reset. Namely, during the reset we call usb_ep0_reinit()
because the characteristics of ep0 may have changed (if the reset
follows a
From: Alan Stern
[ Upstream commit ac854131d9844f79e2fdcef67a7707227538d78a ]
The syzbot fuzzer found a race between URB submission to endpoint 0
and device reset. Namely, during the reset we call usb_ep0_reinit()
because the characteristics of ep0 may have changed (if the reset
follows a
From: Alan Stern
[ Upstream commit ac854131d9844f79e2fdcef67a7707227538d78a ]
The syzbot fuzzer found a race between URB submission to endpoint 0
and device reset. Namely, during the reset we call usb_ep0_reinit()
because the characteristics of ep0 may have changed (if the reset
follows a
From: Alan Stern
[ Upstream commit ac854131d9844f79e2fdcef67a7707227538d78a ]
The syzbot fuzzer found a race between URB submission to endpoint 0
and device reset. Namely, during the reset we call usb_ep0_reinit()
because the characteristics of ep0 may have changed (if the reset
follows a
From: Alan Stern
[ Upstream commit ac854131d9844f79e2fdcef67a7707227538d78a ]
The syzbot fuzzer found a race between URB submission to endpoint 0
and device reset. Namely, during the reset we call usb_ep0_reinit()
because the characteristics of ep0 may have changed (if the reset
follows a
From: Alan Stern
[ Upstream commit ac854131d9844f79e2fdcef67a7707227538d78a ]
The syzbot fuzzer found a race between URB submission to endpoint 0
and device reset. Namely, during the reset we call usb_ep0_reinit()
because the characteristics of ep0 may have changed (if the reset
follows a
From: Alan Stern
[ Upstream commit ac854131d9844f79e2fdcef67a7707227538d78a ]
The syzbot fuzzer found a race between URB submission to endpoint 0
and device reset. Namely, during the reset we call usb_ep0_reinit()
because the characteristics of ep0 may have changed (if the reset
follows a
From: Alan Stern
[ Upstream commit ac854131d9844f79e2fdcef67a7707227538d78a ]
The syzbot fuzzer found a race between URB submission to endpoint 0
and device reset. Namely, during the reset we call usb_ep0_reinit()
because the characteristics of ep0 may have changed (if the reset
follows a
From: Alan Stern
[ Upstream commit ac854131d9844f79e2fdcef67a7707227538d78a ]
The syzbot fuzzer found a race between URB submission to endpoint 0
and device reset. Namely, during the reset we call usb_ep0_reinit()
because the characteristics of ep0 may have changed (if the reset
follows a
From: Alan Stern
[ Upstream commit ac854131d9844f79e2fdcef67a7707227538d78a ]
The syzbot fuzzer found a race between URB submission to endpoint 0
and device reset. Namely, during the reset we call usb_ep0_reinit()
because the characteristics of ep0 may have changed (if the reset
follows a
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
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 osds
Specifically in function ceph_redirect_decode in
Hi,
Static analysis with Coverity Scan on linux-next has found an issue with
the following commit:
commit 20cac6d02815edcc0b1c87bc3e8858b3d1fda3fa
Author: Stephen Boyd
Date: Wed Jul 31 12:35:09 2019 -0700
clk: actions: Don't reference clk_init_data after registration
The analysis is as
On 8/15/19 12:21 PM, Colin Ian King wrote:
> Hi,
>
> Static analysis with Coverity Scan has detected a potential assignment
> bug in ad5380.c:
>
> 217case IIO_CHAN_INFO_CALIBBIAS:
> 218ret = regmap_read(st->regmap,
> AD5380_REG_OFFSET(chan->address),
> 219
Hi,
Static analysis with Coverity Scan has detected a potential assignment
bug in ad5380.c:
217case IIO_CHAN_INFO_CALIBBIAS:
218ret = regmap_read(st->regmap,
AD5380_REG_OFFSET(chan->address),
219val);
220if (ret)
221
On Tue, Aug 13, 2019 at 01:34:02PM +0100, Colin Ian King wrote:
> Hi,
>
> Static analysis on linux-next today found an issue in the following commit:
>
> commit 1afc4b18724f8f7b7a21fdf66cd43cc4a932812d
> Author: Paul E. McKenney
> Date: Tue Jul 2 16:03:33 2019 -0700
>
> rcu/nocb: Add
Hi,
Static analysis on linux-next today found an issue in the following commit:
commit 1afc4b18724f8f7b7a21fdf66cd43cc4a932812d
Author: Paul E. McKenney
Date: Tue Jul 2 16:03:33 2019 -0700
rcu/nocb: Add bypass callback queueing
The coverity report is as follows:
1783// If we
Hi,
On 2019-07-05 18:09, Colin Ian King wrote:
> Static analysis on today's linux-next has found a potential error in the
> following commit:
>
> commit 280e54c9f614c88292685383cf2d65057586e9fb
> Author: Andrzej Pietrasiewicz
> Date: Thu Jun 7 13:06:08 2018 +0200
>
> drm/exynos: scaler:
Hi,
Static analysis on today's linux-next has found a potential error in the
following commit:
commit 280e54c9f614c88292685383cf2d65057586e9fb
Author: Andrzej Pietrasiewicz
Date: Thu Jun 7 13:06:08 2018 +0200
drm/exynos: scaler: Reset hardware before starting the operation
In the
On Thu, 27 Jun 2019 16:01:40 +0200,
Colin Ian King wrote:
>
> Hi there,
>
> Static analysis with Coverity has picked up two potential issues with
> the call to function snd_seq_oss_fill_addr. The prototype of
> snd_seq_oss_fill_addr is as follows:
>
> static inline void
>
Hi there,
Static analysis with Coverity has picked up two potential issues with
the call to function snd_seq_oss_fill_addr. The prototype of
snd_seq_oss_fill_addr is as follows:
static inline void
snd_seq_oss_fill_addr(struct seq_oss_devinfo *dp, struct snd_seq_event
*ev,int dest_client, int
Thanks for catching,
On 6/26/19 11:27 AM, Colin Ian King wrote:
Hi,
Static analysis with Coverity on Linux next has found a potential issue
with the following commit:
commit 3ef46bc97ca2c918b7657a08220c7340a9bb07a2
Author: Steve Longerbeam
Date: Fri May 10 17:50:11 2019 -0400
media:
Hi,
Static analysis with Coverity on Linux next has found a potential issue
with the following commit:
commit 3ef46bc97ca2c918b7657a08220c7340a9bb07a2
Author: Steve Longerbeam
Date: Fri May 10 17:50:11 2019 -0400
media: staging/imx: Improve pipeline searching
The issue is in
When try the file readahead by posix_fadvise(), I find it can't work properly.
For example, posix_fadvise(POSIX_FADV_WILLNEED) a 10MB file, the kernel
actually readahead only 512KB data to the page cache, even if there are enough
free memory in the machine.
When trace to kernel, I find the
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
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.
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
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 tracepoints stat_sleep, stat_iowait, stat_blocked and
stat_runtime require the kernel parameter
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,
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
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
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
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 version of the kernel.
The problem:
In the 4.14 LTS kernel, both key press
Hi Thomas:
Thanks for your review.
On Tue, Mar 26, 2019 at 6:39 AM Thomas Gleixner wrote:
>
> On Mon, 25 Mar 2019, Thomas Gleixner wrote:
> > That has nothing to do with 'nosmt'. It's a general bug in the rollback
> > code when HOTPLUG_CPU=n. 'nosmt' is using the rollback mechanism
On Mon, 25 Mar 2019, Thomas Gleixner wrote:
> That has nothing to do with 'nosmt'. It's a general bug in the rollback
> code when HOTPLUG_CPU=n. 'nosmt' is using the rollback mechanism and is
> just a reliable way to trigger the problem. This happens in the same way
> when the bringup of a CPU
On Mon, Mar 25, 2019 at 09:51:23PM +0800, lantianyu1...@gmail.com wrote:
> From: Lan Tianyu
>
> When add "nosmt" parameter, kernel still boots up all logical cpus once
> and set CR4.MCE on each CPU. This is to avoid shutting down machine
> when a broadacasted MCE is observed CR4.MCE=0b. (Detail
Tianyu,
On Mon, 25 Mar 2019, lantianyu1...@gmail.com wrote:
thanks for tracking this down.
A few nit picks vs. the subject first:
> Subject: [Fix PATCH] cpu/hotplug: Fix bug report when add "nosmt" parameter
> with CONFIG_HOTPLUG_CPU=N
[PATCH] is sufficient. The extra 'Fix' h
From: Lan Tianyu
When add "nosmt" parameter, kernel still boots up all logical cpus once
and set CR4.MCE on each CPU. This is to avoid shutting down machine
when a broadacasted MCE is observed CR4.MCE=0b. (Detail please see comment
in the cpu_smt_allowed()). Smt cpus will bring up and bring down
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
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
On Mon, Mar 18, 2019 at 11:20:51AM +, Colin Ian King wrote:
> Hi,
>
> Static analysis with cppcheck found a couple of interesting issues with
> memcpy'ing of an uninitialized variable. Two occurrences of the same
> issue are found in drivers/staging/rtl8712/rtl8712_cmd.c in functions
>
Hi,
static analysis with cppcheck has detected use of an uninitialized array
tmp_ssid in drivers/staging/rtl8192u/ieee80211/ieee80211_softmac.c in
function ieee80211_softmac_new_net()
Array tmp_ssid is only initialized when ssidbroad is non-null, however
it is being copied and the copy of this
Hi,
Static analysis with cppcheck found a couple of interesting issues with
memcpy'ing of an uninitialized variable. Two occurrences of the same
issue are found in drivers/staging/rtl8712/rtl8712_cmd.c in functions
read_bbreg_hdl and read_rfreg_hdl.
For example:
static u8 read_bbreg_hdl(struct
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
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
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
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
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
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:
1 - 100 of 1121 matches
Mail list logo
