Re: [PATCH] mtd: mtdoops: Fix kmsgdump parameter renaming.
- Ursprüngliche Mail -
> Betreff: [PATCH] mtd: mtdoops: Fix kmsgdump parameter renaming.
> When the kmsg_dumper callback parameter changed, the reason variable
> in mtdoops_do_dump() was not updated accordingly.
> This breaks the build with mtdoops.
>
> Fixes: e1a261ba599e ("printk: Add a short description string to kmsg_dump()")
> Reported-by: Knop Ryszard
> Signed-off-by: Jocelyn Falempe
> ---
>
> The offended commit is in the drm-misc tree, because it was needed
> by drm_panic. So I will push the fix there too.
>
> drivers/mtd/mtdoops.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/mtd/mtdoops.c b/drivers/mtd/mtdoops.c
> index 86d49db9196d..7bf3777e1f13 100644
> --- a/drivers/mtd/mtdoops.c
> +++ b/drivers/mtd/mtdoops.c
> @@ -305,7 +305,7 @@ static void mtdoops_do_dump(struct kmsg_dumper *dumper,
> struct kmsg_dump_iter iter;
>
> /* Only dump oopses if dump_oops is set */
> - if (reason == KMSG_DUMP_OOPS && !dump_oops)
> + if (detail->reason == KMSG_DUMP_OOPS && !dump_oops)
> return;
>
> kmsg_dump_rewind();
> @@ -317,7 +317,7 @@ static void mtdoops_do_dump(struct kmsg_dumper *dumper,
>record_size - sizeof(struct mtdoops_hdr), NULL);
> clear_bit(0, >oops_buf_busy);
>
> - if (reason != KMSG_DUMP_OOPS) {
> + if (detail->reason != KMSG_DUMP_OOPS) {
Acked-by: Richard Weinberger
Thanks,
//richard
Re: [PATCH 00/11] JZ4740 SoC cleanup
- Ursprüngliche Mail - >> Was this series tested with the Ben Nanonote device? >> I have one of these and from time to time I upgrade the kernel on it. > > Yes! Artur (Cc'd) tested it. > > You can test it yourself, after merging this patchset with: > https://git.kernel.org/pub/scm/linux/kernel/git/vkoul/slave-dma.git > branch next, > git://git.freedesktop.org/git/drm-misc branch drm-misc-next. > > These will be in 5.4-rc1. Awesome! Thanks a lot for cleaning this up. Thanks, //richard
Re: [PATCH 00/11] JZ4740 SoC cleanup
On Fri, Jul 26, 2019 at 12:02 AM Paul Cercueil wrote: > > Hi, > > This patchset converts the Qi LB60 MIPS board to devicetree and makes it > use all the shiny new drivers that have been developed or updated > recently. > > All the crappy old drivers and custom code can be dropped since they > have been replaced by better alternatives. > > Some of these alternatives are not yet in 5.3-rc1 but have already been > accepted by their respective maintainer for inclusion in 5.4-rc1. > > To upstream this patchset, I think that as soon as MIPS maintainers > agree to take patches 01-03/11 and 11/11, the other patches can go > through their respective maintainer's tree. Was this series tested with the Ben Nanonote device? I have one of these and from time to time I upgrade the kernel on it. -- Thanks, //richard
block_all_signals() usage in DRM
Am 25.05.2015 um 18:50 schrieb Oleg Nesterov: > On 05/25, Richard Weinberger wrote: >> >> Is this functionality still in use/needed? > > All I can say it doesn't work. > >> Otherwise we could get rid of block_all_signals() and unpuzzle the signaling >> code a bit. :-) > > Yes. I do not even remember when I reported this the first time. Perhaps > more than 10 years ago. > > See the last attempt in 2011: https://lkml.org/lkml/2011/7/12/263 > I copied this email below. Thank you Oleg, this makes sense. I was actually wondering WTF this function is good for. Thanks, //richard
block_all_signals() usage in DRM
Hi!
drivers/gpu/drm/drm_lock.c is the only remaining user of block_all_signals():
/* don't set the block all signals on the master process for now
* really probably not the correct answer but lets us debug xkb
* xserver for now */
if (!file_priv->is_master) {
sigemptyset(>sigmask);
sigaddset(>sigmask, SIGSTOP);
sigaddset(>sigmask, SIGTSTP);
sigaddset(>sigmask, SIGTTIN);
sigaddset(>sigmask, SIGTTOU);
dev->sigdata.context = lock->context;
dev->sigdata.lock = master->lock.hw_lock;
block_all_signals(drm_notifier, dev, >sigmask);
}
Is this functionality still in use/needed?
Otherwise we could get rid of block_all_signals() and unpuzzle the signaling
code a bit. :-)
Thanks,
//richard
Video screen corruption after resume from suspend2ram
Hi! I'm facing a strange issue on my Laptop (Lenovo T430, UEFI boot). Sometimes after resuming from suspend2ram the system freezes after 0 to 2 minutes and my screen corrupts as shown on this photo: http://git.infradead.org/~rw/crash_suspend.jpg The screen corruption always shows the same pattern, little read dots forming more or less squares all across the screen. Facts I know so far: a) It happens with all kernels (tested with any kernel between 3.7 and Linus' as of today) b) It happens only sometimes, every one or two weeks, I suspend my laptop about 2-10 times a day c) It happens after I've upgraded my Laptop's memory from 4GiB to 16GiB. The ram is fine, so far it passed all tests and I've never had any kind of crash/corruption except the suspend thing. And I actually use all of it because I run many KVM guests on my Laptop, etc... d) /var/log/messages contains a lot of 0x00 exactly at the time of the crash. Maybe the page cache faces also an corruption, i.e. ---cut--- 32 30 31 35 2d 30 31 2d 33 31 54 31 36 3a 34 32 |2015-01-31T16:42| 0010 3a 34 37 2e 38 31 30 31 35 30 2b 30 31 3a 30 30 |:47.810150+01:00| 0020 20 73 61 6e 64 70 75 70 70 79 20 63 6f 6c 6c 65 | sandpuppy colle| 0030 63 74 64 5b 31 37 30 32 5d 3a 20 72 72 64 74 6f |ctd[1702]: rrdto| 0040 6f 6c 20 70 6c 75 67 69 6e 3a 20 72 72 64 5f 75 |ol plugin: rrd_u| 0050 70 64 61 74 65 5f 72 20 28 73 61 6e 64 70 75 70 |pdate_r (sandpup| 0060 70 79 2f 69 72 71 2f 69 72 71 2d 54 48 52 2e 72 |py/irq/irq-THR.r| 0070 72 64 29 20 66 61 69 6c 65 64 3a 20 73 61 6e 64 |rd) failed: sand| 0080 70 75 70 70 79 2f 69 72 71 2f 69 72 71 2d 54 48 |puppy/irq/irq-TH| 0090 52 2e 72 72 64 3a 20 69 6c 6c 65 67 61 6c 20 61 |R.rrd: illegal a| 00a0 74 74 65 6d 70 74 20 74 6f 20 75 70 64 61 74 65 |ttempt to update| 00b0 20 75 73 69 6e 67 20 74 69 6d 65 20 31 34 32 32 | using time 1422| 00c0 37 31 38 39 36 37 20 77 68 65 6e 20 6c 61 73 74 |718967 when last| 00d0 20 75 70 64 61 74 65 20 74 69 6d 65 20 69 73 20 | update time is | 00e0 31 34 32 32 37 31 38 39 36 37 20 28 6d 69 6e 69 |1422718967 (mini| 00f0 6d 75 6d 20 6f 6e 65 20 73 65 63 6f 6e 64 20 73 |mum one second s| 0100 74 65 70 29 0a 00 00 00 00 00 00 00 00 00 00 00 |tep)| 0110 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 || * 0410 00 00 00 00 32 30 31 35 2d 30 31 2d 33 31 54 31 |2015-01-31T1| 0420 36 3a 34 35 3a 35 31 2e 38 31 32 30 35 30 2b 30 |6:45:51.812050+0| 0430 31 3a 30 30 20 73 61 6e 64 70 75 70 70 79 20 72 |1:00 sandpuppy r| 0440 73 79 73 6c 6f 67 64 3a 20 5b 6f 72 69 67 69 6e |syslogd: [origin| 0450 20 73 6f 66 74 77 61 72 65 3d 22 72 73 79 73 6c | software="rsysl| 0460 6f 67 64 22 20 73 77 56 65 72 73 69 6f 6e 3d 22 |ogd" swVersion="| 0470 38 2e 34 2e 32 22 20 78 2d 70 69 64 3d 22 31 35 |8.4.2" x-pid="15| 0480 36 38 22 20 78 2d 69 6e 66 6f 3d 22 68 74 74 70 |68" x-info="http| 0490 3a 2f 2f 77 77 77 2e 72 73 79 73 6c 6f 67 2e 63 |://www.rsyslog.c| 04a0 6f 6d 22 5d 20 73 74 61 72 74 0a |om"] start.| 04ab ---cut--- The laptop crashed at 16:42 after resume, I had to power cycle it, at 16:45 it was up again and rsyslog began logging. Between this log lines are 0x00s. Can it be that something like that is hitting us again? commit 3fa016a0b5c5237e9c387fc3249592b2cb5391c6 Author: Dave Airlie Date: Wed Mar 28 10:48:49 2012 +0100 drm/i915: suspend fbdev device around suspend/hibernate Looking at hibernate overwriting I though it looked like a cursor, so I tracked down this missing piece to stop the cursor blink timer. I've no idea if this is sufficient to fix the hibernate problems people are seeing, but please test it. Both radeon and nouveau have done this for a long time. I've run this personally all night hib/resume cycles with no fails. dmesg and lspci output are attached. Attached suspend.log is the content of /var/log/messages between suspend -> resume and crash. Thanks, //richard -- next part -- [0.00] CPU0 microcode updated early to revision 0x1b, date = 2014-05-29 [0.00] Initializing cgroup subsys cpuset [0.00] Initializing cgroup subsys cpu [0.00] Initializing cgroup subsys cpuacct [0.00] Linux version 3.16.7-7-vanilla (geeko at buildhost) (gcc version 4.8.3 20140627 [gcc-4_8-branch revision 212064] (SUSE Linux) ) #1 SMP Wed Dec 17 18:00:44 UTC 2014 (762f27a) [0.00] Command line: initrd=\initrd-3.16.7-7-vanilla root=/dev/mapper/system-root splash=verbose resume=/dev/mapper/system-swap [0.00] e820: BIOS-provided physical RAM map: [0.00] BIOS-e820: [mem 0x-0x0008] usable [0.00] BIOS-e820: [mem 0x0009-0x000b] reserved [0.00] BIOS-e820: [mem
[PATCH] i915, debugfs: Fix uninitialized warning
On Thu, Nov 21, 2013 at 4:49 PM, Borislav Petkov wrote:
> From: Borislav Petkov
>
> gcc complains that:
>
> drivers/gpu/drm/i915/i915_debugfs.c: In function ?display_crc_ctl_write?:
> drivers/gpu/drm/i915/i915_debugfs.c:2393:2: warning: ?val? may be used
> uninitialized in this function [-Wuninitialized]
> drivers/gpu/drm/i915/i915_debugfs.c:2350:6: note: ?val? was declared here
>
> but it can't see that we're going to use val only in the success case.
> So shut it up.
>
> Cc: Daniel Vetter
> Cc: David Airlie
> Cc: intel-gfx at lists.freedesktop.org
> Cc: dri-devel at lists.freedesktop.org
> Signed-off-by: Borislav Petkov
> ---
> drivers/gpu/drm/i915/i915_debugfs.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
> b/drivers/gpu/drm/i915/i915_debugfs.c
> index 6ed45a984230..1191aa47adc9 100644
> --- a/drivers/gpu/drm/i915/i915_debugfs.c
> +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> @@ -2347,7 +2347,7 @@ static int pipe_crc_set_source(struct drm_device *dev,
> enum pipe pipe,
> {
> struct drm_i915_private *dev_priv = dev->dev_private;
> struct intel_pipe_crc *pipe_crc = _priv->pipe_crc[pipe];
> - u32 val;
> + u32 val = 0; /* shut up gcc */
Wouldn't it be better to use uninitialized_var() here?
> int ret;
>
> if (pipe_crc->source == source)
> --
> 1.8.4
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
Thanks,
//richard
