On (04/10/19 13:17), Alastair D'Silva wrote:
> With the wider display format, it can become hard to identify how many
> bytes into the line you are looking at.
>
> The patch adds new flags to hex_dump_to_buffer() and print_hex_dump() to
> print vertical lines to separate every N groups of bytes.
>
On (04/02/18 13:14), wen.yan...@zte.com.cn wrote:
>
>> It's true that this print for the same device is useless. But it's
>> useful for different devices. Is it possible to limit the print only
>> for the same device?
>
>In our scene, it's just for the same device (q->queuedata),
Hello,
On (04/02/18 09:58), Wen Yang wrote:
> There would be so many same lines printed by frequent printk if one
> disk went wrong, like,
> [ 546.185242] sd 0:1:0:0: rejecting I/O to offline device
> [ 546.185258] sd 0:1:0:0: rejecting I/O to offline device
> [ 546.185280] sd 0:1:0:0: rejecti
On (03/28/18 10:29), wen.yan...@zte.com.cn wrote:
>Hello Bart,
>
>We have a detailed discussion of the problem.
>Sergey Senozhatsky, Petr and many people have made a lot of efforts about
>it.
>Please see this link:
>https://bugzilla.kernel.org/s
I'll Cc blockdev
On (03/27/18 08:36), bugzilla-dae...@bugzilla.kernel.org wrote:
> > --- Comment #17 from sergey.senozhatsky.w...@gmail.com ---
> > On (03/26/18 13:05), bugzilla-dae...@bugzilla.kernel.org wrote:
> > > Therefore the serial console is actually pretty fast. It seems that the
> > > de
Hello Peter,
On (08/30/17 10:47), Peter Zijlstra wrote:
[..]
> On Wed, Aug 30, 2017 at 10:42:07AM +0200, Peter Zijlstra wrote:
> >
> > So the overhead looks to be spread out over all sorts, which makes it
> > harder to find and fix.
> >
> > stack unwinding is done lots and is fairly expensive, I
Hi,
On (08/30/17 14:43), Byungchul Park wrote:
[..]
> > notably slower than earlier 4.13 linux-next. (e.g. scrolling in vim
> > is irritatingly slow)
>
> To Ingo,
>
> I cannot decide if we have to roll back CONFIG_LOCKDEP_CROSSRELEASE
> dependency on CONFIG_PROVE_LOCKING in Kconfig. With them en
On (08/23/17 09:03), Byungchul Park wrote:
[..]
> > Byungchul, did you add the crosslock checks to lockdep? Can you have a look
> > at
> > the above report? That report namely doesn't make sense to me.
>
> The report is talking about the following lockup:
>
> A work in a worker
Hi,
On (08/24/17 12:39), Boqun Feng wrote:
> On Wed, Aug 23, 2017 at 02:55:17PM +0900, Sergey Senozhatsky wrote:
> > On (08/23/17 13:35), Boqun Feng wrote:
> > > > KERN_CONT and "\n" should not be together. "\n" flushes the cont
> > > > buff
On (08/23/17 13:35), Boqun Feng wrote:
> > KERN_CONT and "\n" should not be together. "\n" flushes the cont
> > buffer immediately.
> >
>
> Hmm.. Not quite familiar with printk() stuffs, but I could see several
> usages of printk(KERN_CONT "...\n") in kernel.
>
> Did a bit research myself, and I
On (08/23/17 13:35), Boqun Feng wrote:
[..]
> > > printk(KERN_CONT ");\n");
> >
> > KERN_CONT and "\n" should not be together. "\n" flushes the cont
> > buffer immediately.
> >
>
> Hmm.. Not quite familiar with printk() stuffs, but I could see several
> usages of printk(KERN_CONT "...\
On (08/23/17 12:38), Boqun Feng wrote:
[..]
> diff --git a/kernel/locking/lockdep.c b/kernel/locking/lockdep.c
> index 642fb5362507..a3709e15f609 100644
> --- a/kernel/locking/lockdep.c
> +++ b/kernel/locking/lockdep.c
> @@ -1156,6 +1156,23 @@ print_circular_lock_scenario(struct held_lock *src,
>
On (08/23/17 09:03), Byungchul Park wrote:
[..]
aha, ok
> The report is talking about the following lockup:
>
> A work in a worker A task work on exit to user
> -- ---
> mutex_lock(&bdev->bd_mutex)
>
Hello,
==
WARNING: possible circular locking dependency detected
4.13.0-rc6-next-20170822-dbg-00020-g39758ed8aae0-dirty #1746 Not tainted
--
fsck.ext4/148 is trying to acquire lock:
(&bdev->bd_
operation case, which is what
> everyone else is running into, we will try to remove a running target
> when it has no more scsi devices left on it. So the correct patch
> should be to make the BUG_ON see this:
works for me.
Reported-and-tested-by: Sergey Senozhatsky
-ss
> Jam
Hi,
On (04/13/16 10:41), Johannes Thumshirn wrote:
> Hi Sergey, Xiong,
>
> Can you try below patch?
it panics my system.
first it warn_on-s in lib/kobject.c:244
then NULL dereferences
do_scan_async
__scsi_remove_device
scsi_target_reap
device_del
dpm_sysfs_remove
sysfs_unmerge_g
Hello,
commit 7b106f2de6938c31ce5e9c86bc70ad3904666b96
Author: Johannes Thumshirn
Date: Tue Apr 5 11:50:44 2016 +0200
scsi: Add intermediate STARGET_REMOVE state to scsi_target_state
BUG_ON()s (next-20160411) each time I remove a usb flash
[ 49.561600] [] scsi_target_destroy+0x5a/0xc
On (06/24/15 08:10), Greg KH
(gre...@linuxfoundation.org) wrote:
> On Wed, Jun 24, 2015 at 03:25:57PM +0900, Sergey Senozhatsky wrote:
> > On (06/24/15 06:10), Seymour, Shane M wrote:
> > [..]
> > >
> > > /* The sysfs driver interface. Read-only at th
On (06/24/15 06:10), Seymour, Shane M wrote:
[..]
>
> /* The sysfs driver interface. Read-only at the moment */
> -static ssize_t st_try_direct_io_show(struct device_driver *ddp, char *buf)
> +static ssize_t try_direct_io_show(struct device_driver *ddp, char *buf)
> {
> - return snprintf(bu
On (03/27/14 07:29), James Bottomley wrote:
> On Thu, 2014-03-27 at 13:19 +0300, Sergey Senozhatsky wrote:
> > Hello,
> >
> > [1.971778] [ cut here ]
> > [1.971960] WARNING: CPU: 1 PID: 6 at mm/page_alloc.c:2497
> > _
On (03/27/14 07:29), James Bottomley wrote:
> On Thu, 2014-03-27 at 13:19 +0300, Sergey Senozhatsky wrote:
> > Hello,
> >
> > [1.971778] [ cut here ]
> > [1.971960] WARNING: CPU: 1 PID: 6 at mm/page_alloc.c:2497
> > _
Hello,
[1.971778] [ cut here ]
[1.971960] WARNING: CPU: 1 PID: 6 at mm/page_alloc.c:2497
__alloc_pages_nodemask+0x1b9/0x693()
[1.972246] Modules linked in: sd_mod ahci
[1.972604] CPU: 1 PID: 6 Comm: kworker/u8:0 Not tainted
3.14.0-rc8-next-20140327-dbg-dir
22 matches
Mail list logo