Re: [bugreport 5.9-rc8] general protection fault in __bfq_deactivate_entity

On Sun, Mar 7, 2021 at 11:09 AM Hillf Danton wrote: > > On Sun, 7 Mar 2021 08:46:19 +0100 Dmitry Vyukov wrote: > > On Sun, Mar 7, 2021 at 3:15 AM Hillf Danton wrote: > > > > > > Dmitry can you shed some light on the tricks to config kasan to print > > > Call Trace as the reports with the

Re: [bugreport 5.9-rc8] general protection fault in __bfq_deactivate_entity

On Sun, Mar 7, 2021 at 3:15 AM Hillf Danton wrote: > > On Fri, 5 Mar 2021 18:01:04 +0800 Ming Lei wrote: > > On Fri, Mar 05, 2021 at 10:32:04AM +0100, Paolo Valente wrote: > > > I'm thinking of a way to debug this too. The symptom may hint at a > > > use-after-free. Could you enable KASAN in

Re: [bugreport 5.9-rc8] general protection fault, probably for non-canonical address 0x46b1b0f0d8856e4a: 0000 [#1] SMP NOPTI

On Fri, Mar 05, 2021 at 10:32:04AM +0100, Paolo Valente wrote: > I'm thinking of a way to debug this too. The symptom may hint at a > use-after-free. Could you enable KASAN in your tests? (On the flip > side, I know this might change timings, thereby making the fault > disappear). I have asked

Re: [bugreport 5.9-rc8] general protection fault, probably for non-canonical address 0x46b1b0f0d8856e4a: 0000 [#1] SMP NOPTI

I'm thinking of a way to debug this too. The symptom may hint at a use-after-free. Could you enable KASAN in your tests? (On the flip side, I know this might change timings, thereby making the fault disappear). Thanks, Paolo > Il giorno 5 mar 2021, alle ore 10:27, Ming Lei ha > scritto: >

Re: [bugreport 5.9-rc8] general protection fault, probably for non-canonical address 0x46b1b0f0d8856e4a: 0000 [#1] SMP NOPTI

Hello Hillf, Thanks for the debug patch. On Fri, Mar 5, 2021 at 5:00 PM Hillf Danton wrote: > > On Thu, 4 Mar 2021 16:42:30 +0800 Ming Lei wrote: > > On Sat, Oct 10, 2020 at 1:40 PM Mikhail Gavrilov > > wrote: > > > > > > Paolo, Jens I am sorry for the noise. > > > But today I hit the kernel

Re: [bugreport 5.9-rc8] general protection fault, probably for non-canonical address 0x46b1b0f0d8856e4a: 0000 [#1] SMP NOPTI

On Sat, Oct 10, 2020 at 1:40 PM Mikhail Gavrilov wrote: > > Paolo, Jens I am sorry for the noise. > But today I hit the kernel panic and git blame said that you have > created the file in which happened panic (this I saw from trace) > > $ /usr/src/kernels/`uname -r`/scripts/faddr2line >

Re: [bugreport] [5.10-rc1] Oops: 0000 [#1] SMP NOPTI bug which always starts as page allocation failure

On Tue, Nov 3, 2020 at 4:05 PM Mikhail Gavrilov wrote: > > Hi folks. > I observed hard reproductible the set of bugs. > It always started as > 1) kworker/u64:2: page allocation failure: order:5, > mode:0x40dc0(GFP_KERNEL|__GFP_COMP|__GFP_ZERO), > nodemask=(null),cpuset=/,mems_allowed=0 >

[bugreport] [5.10-rc1] Oops: 0000 [#1] SMP NOPTI bug which always starts as page allocation failure

Hi folks. I observed hard reproductible the set of bugs. It always started as 1) kworker/u64:2: page allocation failure: order:5, mode:0x40dc0(GFP_KERNEL|__GFP_COMP|__GFP_ZERO), nodemask=(null),cpuset=/,mems_allowed=0 Continious as: 2) WARNING: CPU: 21 PID: 806649 at

[bugreport] [5.10] DEBUG_LOCKS_WARN_ON(ww_ctx->contending_lock != ww) We 'forgot' to unlock everything else first?

Hi folks. I observed this issue since 5.3 and it still happens with 5.10 git. This warning has reproductivity 100% reliable when I launch "Wolfenstein: Youngblood" version of Mesa doesn't matter. [73690.883948] [ cut here ] [73690.883953]

Re: [bugreport] [5.10] warning at net/netfilter/nf_tables_api.c:622

On Fri, 16 Oct 2020 at 12:11, Mikhail Gavrilov wrote: > > Hi folks, > today I joined to testing Kernel 5.10 and see that every boot happens > this warning: > > [ 22.180180] [ cut here ] > [ 22.180193] WARNING: CPU: 28 PID: 1205 at > net/netfilter/nf_tables_api.c:622

[bugreport] [5.10] warning at net/netfilter/nf_tables_api.c:622

Hi folks, today I joined to testing Kernel 5.10 and see that every boot happens this warning: [ 22.180180] [ cut here ] [ 22.180193] WARNING: CPU: 28 PID: 1205 at net/netfilter/nf_tables_api.c:622 nft_chain_parse_hook+0x224/0x330 [nf_tables] [ 22.180194] Modules

[bugreport 5.9-rc8] general protection fault, probably for non-canonical address 0x46b1b0f0d8856e4a: 0000 [#1] SMP NOPTI

Paolo, Jens I am sorry for the noise. But today I hit the kernel panic and git blame said that you have created the file in which happened panic (this I saw from trace) $ /usr/src/kernels/`uname -r`/scripts/faddr2line /lib/debug/lib/modules/`uname -r`/vmlinux __bfq_deactivate_entity+0x15a

Re: [Kgdb-bugreport] [PATCH] serial: qcom_geni_serial: Fix recent kdb hang

On Tue, Aug 11, 2020 at 09:21:22AM -0700, Doug Anderson wrote: > Hi, > > On Tue, Aug 11, 2020 at 4:54 AM Akash Asthana wrote: > > > > > > On 8/11/2020 2:56 AM, Doug Anderson wrote: > > > Hi, > > > > > > On Mon, Aug 10, 2020 at 5:32 AM Akash Asthana > > > wrote: > > >> Hi Doug, > > >> > > >> On

Re: [5.8RC4][bugreport]WARNING: CPU: 28 PID: 211236 at fs/fuse/file.c:1684 tree_insert+0xaf/0xc0 [fuse]

On 7/13/20 11:02 AM, Mikhail Gavrilov wrote: > On Mon, 13 Jul 2020 at 12:11, Mikhail Gavrilov > wrote: >> >> On Mon, 13 Jul 2020 at 03:28, Mikhail Gavrilov >> wrote: >>> >>> Hi folks. >>> While testing 5.8 RCs I founded that kernel log flooded by the message >>> "WARNING: CPU: 28 PID: 211236 at

Re: [5.8RC4][bugreport]WARNING: CPU: 28 PID: 211236 at fs/fuse/file.c:1684 tree_insert+0xaf/0xc0 [fuse]

On Mon, 13 Jul 2020 at 12:11, Mikhail Gavrilov wrote: > > On Mon, 13 Jul 2020 at 03:28, Mikhail Gavrilov > wrote: > > > > Hi folks. > > While testing 5.8 RCs I founded that kernel log flooded by the message > > "WARNING: CPU: 28 PID: 211236 at fs/fuse/file.c:1684 tree > > insert+0xaf/0xc0

Re: [5.8RC4][bugreport]WARNING: CPU: 28 PID: 211236 at fs/fuse/file.c:1684 tree_insert+0xaf/0xc0 [fuse]

On Mon, 13 Jul 2020 at 03:28, Mikhail Gavrilov wrote: > > Hi folks. > While testing 5.8 RCs I founded that kernel log flooded by the message > "WARNING: CPU: 28 PID: 211236 at fs/fuse/file.c:1684 tree > insert+0xaf/0xc0 [fuse]" when I start podman container. > In kernel 5.7 not has such a

[5.8RC4][bugreport]WARNING: CPU: 28 PID: 211236 at fs/fuse/file.c:1684 tree_insert+0xaf/0xc0 [fuse]

Hi folks. While testing 5.8 RCs I founded that kernel log flooded by the message "WARNING: CPU: 28 PID: 211236 at fs/fuse/file.c:1684 tree insert+0xaf/0xc0 [fuse]" when I start podman container. In kernel 5.7 not has such a problem. [92414.864536] [ cut here ]

Re: [Kgdb-bugreport] [PATCH v3] kdb: Remove the misfeature 'KDBFLAGS'

BFLAGS=0x%x\n", kdb_flags); > + kdb_printf("KDBDEBUG=0x%x\n", > + (kdb_flags & KDB_DEBUG(MASK)) >> KDB_DEBUG_FLAG_SHIFT); > > return 0; > } > -- > 2.17.1 > > > > ___ > Kgdb-bugreport mailing list > kgdb-bugrep...@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/kgdb-bugreport

Re: [Kgdb-bugreport] [PATCH v3] kdb: Remove the misfeature 'KDBFLAGS'

On Thu, May 21, 2020 at 03:21:25PM +0800, Wei Li wrote: > Currently, 'KDBFLAGS' is an internal variable of kdb, it is combined > by 'KDBDEBUG' and state flags. It will be shown only when 'KDBDEBUG' > is set, and the user can define an environment variable named 'KDBFLAGS' > too. These are puzzling

Re: [Kgdb-bugreport] [PATCH v3 04/11] kgdb: Delay "kgdbwait" to dbg_late_init() by default

On Thu, Apr 30, 2020 at 09:35:30AM -0700, Doug Anderson wrote: > Hi, > > On Thu, Apr 30, 2020 at 8:49 AM Daniel Thompson > wrote: > > > > On Tue, Apr 28, 2020 at 02:13:44PM -0700, Douglas Anderson wrote: > > > Using kgdb requires at least some level of architecture-level > > > initialization.

Re: [bugreport] kernel 5.2 pblk bad header/extent: invalid extent entries

On Tue, May 28, 2019 at 10:58:03AM +0500, Mikhail Gavrilov wrote: > On Mon, 27 May 2019 at 21:16, Mikhail Gavrilov > wrote: > > > > I am bisected issue. I hope it help understand what is happened on my > > computer. > > > > Why no one answers? > Even if the problem is known and already fixed, I

Re: [bugreport] kernel 5.2 pblk bad header/extent: invalid extent entries

On Mon, 27 May 2019 at 21:16, Mikhail Gavrilov wrote: > > I am bisected issue. I hope it help understand what is happened on my > computer. > > $ git bisect log > git bisect start > # good: [e93c9c99a629c61837d5a7fc2120cd2b6c70dbdd] Linux 5.1 > git bisect good

Re: [bugreport] kernel 5.2 pblk bad header/extent: invalid extent entries

On Sat, 18 May 2019 at 16:07, Mikhail Gavrilov wrote: > > It happens today again. > > [18018.969636] EXT4-fs error (device nvme0n1p2): ext4_find_extent:908: > inode #8: comm jbd2/nvme0n1p2-: pblk 23101439 bad header/extent: > invalid extent entries - magic f30a, entries 8, max 340(340), depth >

Re: [bugreport] kernel 5.2 pblk bad header/extent: invalid extent entries

Excerpts from Mikhail Gavrilov's message of May 18, 2019 7:07 am: > On Sat, 18 May 2019 at 11:44, Mikhail Gavrilov > wrote: >> [28616.429757] EXT4-fs error (device nvme0n1p2): ext4_find_extent:908: >> inode #8: comm jbd2/nvme0n1p2-: pblk 23101439 bad header/extent: >> invalid extent entries -

[bugreport] kernel 5.2 pblk bad header/extent: invalid extent entries

Hi folks. Yesterday I updated kernel to 5.2 (git commit 7e9890a3500d) I always leave computer working at night. Today at morning I am found that computer are hanged. I was connect via ssh and look at kernel log. There I had seen strange records which I never seen before: [28616.429757] EXT4-fs

Re: [Kgdb-bugreport] [PATCH] MAINTAINERS: kgdb: Replace Jason with Daniel

On 12/05/2017 10:42 AM, Randy Dunlap wrote: On 12/05/2017 06:55 AM, Daniel Thompson wrote: On 05/12/17 14:37, Jason Wessel wrote: I have a series of 50+ patches for kgdb/kdb/usb which have never been published.  I am not saying that we actually need any of those patches, but it would be nice

Re: [Kgdb-bugreport] [PATCH] MAINTAINERS: kgdb: Replace Jason with Daniel

On 12/05/2017 10:42 AM, Randy Dunlap wrote: On 12/05/2017 06:55 AM, Daniel Thompson wrote: On 05/12/17 14:37, Jason Wessel wrote: I have a series of 50+ patches for kgdb/kdb/usb which have never been published.  I am not saying that we actually need any of those patches, but it would be nice

Re: [Kgdb-bugreport] [PATCH] MAINTAINERS: kgdb: Replace Jason with Daniel

On 12/05/2017 06:55 AM, Daniel Thompson wrote: > On 05/12/17 14:37, Jason Wessel wrote: >> On 12/05/2017 08:09 AM, Lee Jones wrote: >>> On Tue, 05 Dec 2017, Daniel Thompson wrote: >>> ... with many, many thanks for Jason for all his hard work. Cc: Jason Wessel

Re: [Kgdb-bugreport] [PATCH] MAINTAINERS: kgdb: Replace Jason with Daniel

On 12/05/2017 06:55 AM, Daniel Thompson wrote: > On 05/12/17 14:37, Jason Wessel wrote: >> On 12/05/2017 08:09 AM, Lee Jones wrote: >>> On Tue, 05 Dec 2017, Daniel Thompson wrote: >>> ... with many, many thanks for Jason for all his hard work. Cc: Jason Wessel Signed-off-by:

Re: [Kgdb-bugreport] [PATCH] MAINTAINERS: kgdb: Replace Jason with Daniel

On 05/12/17 14:37, Jason Wessel wrote: On 12/05/2017 08:09 AM, Lee Jones wrote: On Tue, 05 Dec 2017, Daniel Thompson wrote: ... with many, many thanks for Jason for all his hard work. Cc: Jason Wessel Signed-off-by: Daniel Thompson

Re: [Kgdb-bugreport] [PATCH] MAINTAINERS: kgdb: Replace Jason with Daniel

On 05/12/17 14:37, Jason Wessel wrote: On 12/05/2017 08:09 AM, Lee Jones wrote: On Tue, 05 Dec 2017, Daniel Thompson wrote: ... with many, many thanks for Jason for all his hard work. Cc: Jason Wessel Signed-off-by: Daniel Thompson --- Notes: Over the years Jason has become

Re: [Kgdb-bugreport] [PATCH] MAINTAINERS: kgdb: Replace Jason with Daniel

On Tue, 05 Dec 2017, Jason Wessel wrote: > On 12/05/2017 08:09 AM, Lee Jones wrote: > > On Tue, 05 Dec 2017, Daniel Thompson wrote: > > > > > ... with many, many thanks for Jason for all his hard work. > > > > > > Cc: Jason Wessel > > > Signed-off-by: Daniel

Re: [Kgdb-bugreport] [PATCH] MAINTAINERS: kgdb: Replace Jason with Daniel

On Tue, 05 Dec 2017, Jason Wessel wrote: > On 12/05/2017 08:09 AM, Lee Jones wrote: > > On Tue, 05 Dec 2017, Daniel Thompson wrote: > > > > > ... with many, many thanks for Jason for all his hard work. > > > > > > Cc: Jason Wessel > > > Signed-off-by: Daniel Thompson > > > --- > > > > > >

Re: [Kgdb-bugreport] [PATCH] MAINTAINERS: kgdb: Replace Jason with Daniel

On 12/05/2017 08:09 AM, Lee Jones wrote: On Tue, 05 Dec 2017, Daniel Thompson wrote: ... with many, many thanks for Jason for all his hard work. Cc: Jason Wessel Signed-off-by: Daniel Thompson --- Notes: Over the years Jason has

Re: [Kgdb-bugreport] [PATCH] MAINTAINERS: kgdb: Replace Jason with Daniel

On 12/05/2017 08:09 AM, Lee Jones wrote: On Tue, 05 Dec 2017, Daniel Thompson wrote: ... with many, many thanks for Jason for all his hard work. Cc: Jason Wessel Signed-off-by: Daniel Thompson --- Notes: Over the years Jason has become increasingly hard to get hold off and I

Re: [PATCH] [BUGREPORT] media: v4l: omap_vout: vrfb: initialize DMA flags

Arnd, sorry for the delayed response, I was away w/o internet connection for the past weeks. On 2017-07-10 14:18, Arnd Bergmann wrote: > Passing uninitialized flags into device_prep_interleaved_dma is clearly > a bad idea, and we get a compiler warning for it: > >

Re: [PATCH] [BUGREPORT] media: v4l: omap_vout: vrfb: initialize DMA flags

Arnd, sorry for the delayed response, I was away w/o internet connection for the past weeks. On 2017-07-10 14:18, Arnd Bergmann wrote: > Passing uninitialized flags into device_prep_interleaved_dma is clearly > a bad idea, and we get a compiler warning for it: > >

[PATCH] [BUGREPORT] media: v4l: omap_vout: vrfb: initialize DMA flags

Passing uninitialized flags into device_prep_interleaved_dma is clearly a bad idea, and we get a compiler warning for it: drivers/media/platform/omap/omap_vout_vrfb.c: In function 'omap_vout_prepare_vrfb': drivers/media/platform/omap/omap_vout_vrfb.c:273:5: error: 'flags' may be used

[PATCH] [BUGREPORT] media: v4l: omap_vout: vrfb: initialize DMA flags

Passing uninitialized flags into device_prep_interleaved_dma is clearly a bad idea, and we get a compiler warning for it: drivers/media/platform/omap/omap_vout_vrfb.c: In function 'omap_vout_prepare_vrfb': drivers/media/platform/omap/omap_vout_vrfb.c:273:5: error: 'flags' may be used

Re: [4.1 backport trouble] Re: BUGreport: fix minor infoleak in get_user_ex()

On Thu, Oct 27, 2016 at 10:02:10PM -0400, Al Viro wrote: > ... and frankly, backporting 548acf19234d would be my preference. It's a bit > more intrusive than needed (_ASM_EXTABLE_FAULT is used only in > memcpy_mcsafe(), > which is used only by pmem and it's the only reason for passing the trap >

Re: [4.1 backport trouble] Re: BUGreport: fix minor infoleak in get_user_ex()

On Thu, Oct 27, 2016 at 10:02:10PM -0400, Al Viro wrote: > ... and frankly, backporting 548acf19234d would be my preference. It's a bit > more intrusive than needed (_ASM_EXTABLE_FAULT is used only in > memcpy_mcsafe(), > which is used only by pmem and it's the only reason for passing the trap >

Re: [4.1 backport trouble] Re: BUGreport: fix minor infoleak in get_user_ex()

On Fri, Oct 28, 2016 at 08:49:58PM +0100, Al Viro wrote: > On Fri, Oct 28, 2016 at 11:21:24AM -0700, Linus Torvalds wrote: > > > End result: either commit 1c109fabbd51 shouldn't be backported (it's > > really not that important - if people properly check the exception > > error results it

Re: [4.1 backport trouble] Re: BUGreport: fix minor infoleak in get_user_ex()

On Fri, Oct 28, 2016 at 08:49:58PM +0100, Al Viro wrote: > On Fri, Oct 28, 2016 at 11:21:24AM -0700, Linus Torvalds wrote: > > > End result: either commit 1c109fabbd51 shouldn't be backported (it's > > really not that important - if people properly check the exception > > error results it

Re: [4.1 backport trouble] Re: BUGreport: fix minor infoleak in get_user_ex()

On Fri, Oct 28, 2016 at 11:21:24AM -0700, Linus Torvalds wrote: > End result: either commit 1c109fabbd51 shouldn't be backported (it's > really not that important - if people properly check the exception > error results it shouldn't matter), or you need to also backport > 548acf19234d as Al

Re: [4.1 backport trouble] Re: BUGreport: fix minor infoleak in get_user_ex()

On Fri, Oct 28, 2016 at 11:21:24AM -0700, Linus Torvalds wrote: > End result: either commit 1c109fabbd51 shouldn't be backported (it's > really not that important - if people properly check the exception > error results it shouldn't matter), or you need to also backport > 548acf19234d as Al

Re: [4.1 backport trouble] Re: BUGreport: fix minor infoleak in get_user_ex()

On Fri, Oct 28, 2016 at 12:40:33PM -0400, Joe Korty wrote: > Backporting 548acf19234d to 4.1.35 does indeed fix the > issue. However, it is not clear to my _why_ it works, > so it might be better that someone else push the backport > to stable. Because the trick used in fixup_exception() prior

Re: [4.1 backport trouble] Re: BUGreport: fix minor infoleak in get_user_ex()

On Fri, Oct 28, 2016 at 12:40:33PM -0400, Joe Korty wrote: > Backporting 548acf19234d to 4.1.35 does indeed fix the > issue. However, it is not clear to my _why_ it works, > so it might be better that someone else push the backport > to stable. Because the trick used in fixup_exception() prior

Re: [4.1 backport trouble] Re: BUGreport: fix minor infoleak in get_user_ex()

rea On Fri, Oct 28, 2016 at 9:40 AM, Joe Korty wrote: > > Backporting 548acf19234d to 4.1.35 does indeed fix the > issue. However, it is not clear to my _why_ it works, > so it might be better that someone else push the backport > to stable. The problem is that the

Re: [4.1 backport trouble] Re: BUGreport: fix minor infoleak in get_user_ex()

rea On Fri, Oct 28, 2016 at 9:40 AM, Joe Korty wrote: > > Backporting 548acf19234d to 4.1.35 does indeed fix the > issue. However, it is not clear to my _why_ it works, > so it might be better that someone else push the backport > to stable. The problem is that the old _ASM_EXTABLE_EXT

[4.1 backport trouble] Re: BUGreport: fix minor infoleak in get_user_ex()

On Fri, Oct 28, 2016 at 01:03:55AM +0100, Al Viro wrote: > On Thu, Oct 27, 2016 at 03:32:10PM -0400, Joe Korty wrote: [oops in 4.1.35, bisected to 319fe1151940] > > The following test program can be used to trigger the problem: > > > > /* gcc -m32 c.c -o c */ > > #define _GNU_SOURCE > > #include

[4.1 backport trouble] Re: BUGreport: fix minor infoleak in get_user_ex()

On Fri, Oct 28, 2016 at 01:03:55AM +0100, Al Viro wrote: > On Thu, Oct 27, 2016 at 03:32:10PM -0400, Joe Korty wrote: [oops in 4.1.35, bisected to 319fe1151940] > > The following test program can be used to trigger the problem: > > > > /* gcc -m32 c.c -o c */ > > #define _GNU_SOURCE > > #include

Re: BUGreport: fix minor infoleak in get_user_ex()

On Thu, Oct 27, 2016 at 03:32:10PM -0400, Joe Korty wrote: > Hi Al, > I don't know if this is worth fixing or not, but I thought > I would mention it in case it was. > > A git bisect search shows that the commit: > > commit 319fe11519401e8a5db191a0a93aa2c1d7bb59f4 > Author: Al Viro

Re: BUGreport: fix minor infoleak in get_user_ex()

On Thu, Oct 27, 2016 at 03:32:10PM -0400, Joe Korty wrote: > Hi Al, > I don't know if this is worth fixing or not, but I thought > I would mention it in case it was. > > A git bisect search shows that the commit: > > commit 319fe11519401e8a5db191a0a93aa2c1d7bb59f4 > Author: Al Viro >

Re: Official bugreport 4.1 kernel (audio gadget and ChipIdea)

On Tuesday, June 30, 2015 at 04:23:01 AM, Peter Chen wrote: > On Fri, Jun 26, 2015 at 07:15:18PM +0200, Sébastien Pruvost wrote: > > Hello, > > > > I'm sending this mail to report a bug concerning the latest kernel 4.1. > > > > Here is the problem (and the test I've done): > > I

Re: Official bugreport 4.1 kernel (audio gadget and ChipIdea)

On Tuesday, June 30, 2015 at 04:23:01 AM, Peter Chen wrote: On Fri, Jun 26, 2015 at 07:15:18PM +0200, Sébastien Pruvost wrote: Hello, I'm sending this mail to report a bug concerning the latest kernel 4.1. Here is the problem (and the test I've done): I have firstly

Re: Official bugreport 4.1 kernel (audio gadget and ChipIdea)

On Fri, Jun 26, 2015 at 07:15:18PM +0200, Sébastien Pruvost wrote: > Hello, > > I'm sending this mail to report a bug concerning the latest kernel 4.1. > > Here is the problem (and the test I've done): > > I have firstly used the 3.10.53 kernel for my two sabrelites > in >

Re: Official bugreport 4.1 kernel (audio gadget and ChipIdea)

On Fri, Jun 26, 2015 at 07:15:18PM +0200, Sébastien Pruvost wrote: Hello, I'm sending this mail to report a bug concerning the latest kernel 4.1. Here is the problem (and the test I've done): I have firstly used the 3.10.53 kernel for my two sabrelites in order to use

Re: [Kgdb-bugreport] [RFC v5 - RESEND] debug: prevent entering debug mode on panic/exception.

On 28/01/15 10:39, Kiran Raparthy wrote: > From: Colin Cross > > debug: prevent entering debug mode on panic/exception. > > On non-developer devices, kgdb prevents the device from rebooting > after a panic. > > Incase of panics and exceptions, to allow the device to reboot, prevent > entering

Re: [Kgdb-bugreport] [RFC v5 - RESEND] debug: prevent entering debug mode on panic/exception.

On 28 January 2015 at 16:25, Daniel Thompson wrote: > On 28/01/15 10:39, Kiran Raparthy wrote: >> From: Colin Cross >> >> debug: prevent entering debug mode on panic/exception. >> >> On non-developer devices, kgdb prevents the device from rebooting >> after a panic. >> >> Incase of panics and

Re: [Kgdb-bugreport] [RFC v5 - RESEND] debug: prevent entering debug mode on panic/exception.

On 28 January 2015 at 16:25, Daniel Thompson daniel.thomp...@linaro.org wrote: On 28/01/15 10:39, Kiran Raparthy wrote: From: Colin Cross ccr...@android.com debug: prevent entering debug mode on panic/exception. On non-developer devices, kgdb prevents the device from rebooting after a

Re: [Kgdb-bugreport] [RFC v5 - RESEND] debug: prevent entering debug mode on panic/exception.

On 28/01/15 10:39, Kiran Raparthy wrote: From: Colin Cross ccr...@android.com debug: prevent entering debug mode on panic/exception. On non-developer devices, kgdb prevents the device from rebooting after a panic. Incase of panics and exceptions, to allow the device to reboot, prevent

Re: [BUGREPORT] Tasklet scheduled issue in Linux 3.4.x-rt

Hi Thomas, Thanks for your reply! >> nf_defrag_ipv4 xt_state nf_conntrack usr_cache(O) acpi_cpufreq mperf >> processor thermal_sys sg hwmon iptable_filter ip_tables x_tables ixgbe(O) >> igb(O) bonding(O) tg(O) netmgmt(O) drvinstall(PO) dal(PO) dca usb_storage(O) >> uhci_hcd ehci_hcd

Re: [BUGREPORT] Tasklet scheduled issue in Linux 3.4.x-rt

>> Because this patch does not exist in the latest Linus kernel, so I >> have not reported this issue to kernel bugzilla. > > This patch exists in all -RT releases up to 3.12. If there is an issue > with it, it should be solved. > > If the sched bit set is and you can't get lock later then the

Re: [BUGREPORT] Tasklet scheduled issue in Linux 3.4.x-rt

On Mon, 3 Mar 2014, Yijing Wang wrote: > Hi list, >I found a tasklet related issue in linux-stable-rt 3.4. > > And after I revert following commit, the test result seems ok(test lasted > 40hours). > > commit 0d9f73fc1e7270a3f8709c59c913408153d9d9f8 This commit id does not exist in the

Re: [BUGREPORT] Tasklet scheduled issue in Linux 3.4.x-rt

On 03/29/2014 07:35 AM, Yijing Wang wrote: > Hi Sebastian, Hi Yijing, >Thanks for your reply and help to look at it, thanks! > > I also check the tasklet state machine changes, and didn't find > clue for this issue. So I Temporarily reverted Ingo's patch, without > this patch, my test is

Re: [BUGREPORT] Tasklet scheduled issue in Linux 3.4.x-rt

On 03/29/2014 07:35 AM, Yijing Wang wrote: Hi Sebastian, Hi Yijing, Thanks for your reply and help to look at it, thanks! I also check the tasklet state machine changes, and didn't find clue for this issue. So I Temporarily reverted Ingo's patch, without this patch, my test is ok.

Re: [BUGREPORT] Tasklet scheduled issue in Linux 3.4.x-rt

On Mon, 3 Mar 2014, Yijing Wang wrote: Hi list, I found a tasklet related issue in linux-stable-rt 3.4. And after I revert following commit, the test result seems ok(test lasted 40hours). commit 0d9f73fc1e7270a3f8709c59c913408153d9d9f8 This commit id does not exist in the official

Re: [BUGREPORT] Tasklet scheduled issue in Linux 3.4.x-rt

Because this patch does not exist in the latest Linus kernel, so I have not reported this issue to kernel bugzilla. This patch exists in all -RT releases up to 3.12. If there is an issue with it, it should be solved. If the sched bit set is and you can't get lock later then the tasklet

Re: [BUGREPORT] Tasklet scheduled issue in Linux 3.4.x-rt

Hi Thomas, Thanks for your reply! nf_defrag_ipv4 xt_state nf_conntrack usr_cache(O) acpi_cpufreq mperf processor thermal_sys sg hwmon iptable_filter ip_tables x_tables ixgbe(O) igb(O) bonding(O) tg(O) netmgmt(O) drvinstall(PO) dal(PO) dca usb_storage(O) uhci_hcd ehci_hcd usbcore(O)

Re: [BUGREPORT] Tasklet scheduled issue in Linux 3.4.x-rt

Hi Sebastian, Thanks for your reply and help to look at it, thanks! I also check the tasklet state machine changes, and didn't find clue for this issue. So I Temporarily reverted Ingo's patch, without this patch, my test is ok. commit 0d9f73fc1e7270a3f8709c59c913408153d9d9f8 Author: Ingo

Re: [BUGREPORT] Tasklet scheduled issue in Linux 3.4.x-rt

Hi Sebastian, Thanks for your reply and help to look at it, thanks! I also check the tasklet state machine changes, and didn't find clue for this issue. So I Temporarily reverted Ingo's patch, without this patch, my test is ok. commit 0d9f73fc1e7270a3f8709c59c913408153d9d9f8 Author: Ingo

Re: [BUGREPORT] Tasklet scheduled issue in Linux 3.4.x-rt

* Yijing Wang | 2014-03-03 17:24:39 [+0800]: >[2012-03-26 18:55:43][ 929.252312] WARNING: at kernel/softirq.c:773 >__tasklet_action+0x51/0x1a0() >[2012-03-27 03:41:06][ 3647.886005] WARNING: at kernel/softirq.c:773 >__tasklet_action+0x51/0x1a0() >[2012-03-27 03:42:04][ 3705.434418] WARNING: at

Re: [BUGREPORT] Tasklet scheduled issue in Linux 3.4.x-rt

* Yijing Wang | 2014-03-03 17:24:39 [+0800]: [2012-03-26 18:55:43][ 929.252312] WARNING: at kernel/softirq.c:773 __tasklet_action+0x51/0x1a0() [2012-03-27 03:41:06][ 3647.886005] WARNING: at kernel/softirq.c:773 __tasklet_action+0x51/0x1a0() [2012-03-27 03:42:04][ 3705.434418] WARNING: at

[BUGREPORT] Tasklet scheduled issue in Linux 3.4.x-rt

Hi list, I found a tasklet related issue in linux-stable-rt 3.4. And after I revert following commit, the test result seems ok(test lasted 40hours). commit 0d9f73fc1e7270a3f8709c59c913408153d9d9f8 Author: Ingo Molnar Date: Tue Nov 29 20:18:22 2011 -0500 tasklet: Prevent tasklets from

[BUGREPORT] Tasklet scheduled issue in Linux 3.4.x-rt

Hi list, I found a tasklet related issue in linux-stable-rt 3.4. And after I revert following commit, the test result seems ok(test lasted 40hours). commit 0d9f73fc1e7270a3f8709c59c913408153d9d9f8 Author: Ingo Molnar mi...@elte.hu Date: Tue Nov 29 20:18:22 2011 -0500 tasklet: Prevent

Re: [BUGREPORT] Linux USB 3.0

On Tue, Feb 11, 2014 at 7:45 PM, Greg KH wrote: > On Tue, Feb 11, 2014 at 07:29:47PM +0100, Markus Rechberger wrote: >> On Mon, Feb 10, 2014 at 12:15 AM, Robert Hancock >> wrote: >> > On 08/02/14 03:00 AM, Markus Rechberger wrote: >> >> >> >> On Tue, Feb 4, 2014 at 10:31 AM, David Laight >> >>

Re: [BUGREPORT] Linux USB 3.0

On Tue, Feb 11, 2014 at 07:29:47PM +0100, Markus Rechberger wrote: > On Mon, Feb 10, 2014 at 12:15 AM, Robert Hancock wrote: > > On 08/02/14 03:00 AM, Markus Rechberger wrote: > >> > >> On Tue, Feb 4, 2014 at 10:31 AM, David Laight > >> wrote: > >>> > >>> From: Markus Rechberger > >> >

Re: [BUGREPORT] Linux USB 3.0

Markus Rechberger writes: > Next kernel crash report, this time a Synology NAS System: > http://support.sundtek.com/index.php/topic,1511.0.html There is no etxhci_hcd driver in the mainline kernel... Feb 11 18:50:41 DiskStation kernel: [103740.405521] Backtrace: Feb 11 18:50:41 DiskStation

Re: [BUGREPORT] Linux USB 3.0

On Mon, Feb 10, 2014 at 12:15 AM, Robert Hancock wrote: > On 08/02/14 03:00 AM, Markus Rechberger wrote: >> >> On Tue, Feb 4, 2014 at 10:31 AM, David Laight >> wrote: >>> >>> From: Markus Rechberger >> >> Dec 27 23:23:50 solist kernel: [ 36.118245] xhci_hcd :00:14.0: >> ERROR

Re: [BUGREPORT] Linux USB 3.0

On Mon, Feb 10, 2014 at 12:15 AM, Robert Hancock hancock...@gmail.com wrote: On 08/02/14 03:00 AM, Markus Rechberger wrote: On Tue, Feb 4, 2014 at 10:31 AM, David Laight david.lai...@aculab.com wrote: From: Markus Rechberger Dec 27 23:23:50 solist kernel: [ 36.118245] xhci_hcd

Re: [BUGREPORT] Linux USB 3.0

Markus Rechberger mrechber...@gmail.com writes: Next kernel crash report, this time a Synology NAS System: http://support.sundtek.com/index.php/topic,1511.0.html There is no etxhci_hcd driver in the mainline kernel... Feb 11 18:50:41 DiskStation kernel: [103740.405521] Backtrace: Feb 11

Re: [BUGREPORT] Linux USB 3.0

On Tue, Feb 11, 2014 at 07:29:47PM +0100, Markus Rechberger wrote: On Mon, Feb 10, 2014 at 12:15 AM, Robert Hancock hancock...@gmail.com wrote: On 08/02/14 03:00 AM, Markus Rechberger wrote: On Tue, Feb 4, 2014 at 10:31 AM, David Laight david.lai...@aculab.com wrote: From: Markus

Re: [BUGREPORT] Linux USB 3.0

On Tue, Feb 11, 2014 at 7:45 PM, Greg KH gre...@linuxfoundation.org wrote: On Tue, Feb 11, 2014 at 07:29:47PM +0100, Markus Rechberger wrote: On Mon, Feb 10, 2014 at 12:15 AM, Robert Hancock hancock...@gmail.com wrote: On 08/02/14 03:00 AM, Markus Rechberger wrote: On Tue, Feb 4, 2014 at

Re: [BUGREPORT] Linux USB 3.0

On 08/02/14 03:00 AM, Markus Rechberger wrote: On Tue, Feb 4, 2014 at 10:31 AM, David Laight wrote: From: Markus Rechberger Dec 27 23:23:50 solist kernel: [ 36.118245] xhci_hcd :00:14.0: ERROR Transfer event TRB DMA ptr These messages might be harmless. The 3.0 kernel contains a

Re: [BUGREPORT] Linux USB 3.0

On 08/02/14 03:00 AM, Markus Rechberger wrote: On Tue, Feb 4, 2014 at 10:31 AM, David Laight david.lai...@aculab.com wrote: From: Markus Rechberger Dec 27 23:23:50 solist kernel: [ 36.118245] xhci_hcd :00:14.0: ERROR Transfer event TRB DMA ptr These messages might be harmless. The

Re: [BUGREPORT] Linux USB 3.0

The next one, just today (unfortunately it's in German): http://support.sundtek.com/index.php/topic,1505.msg11020.html#msg11020 This guy is using Ubuntu with Linux 3.13.0-8-generic The system seems to freeze completely after some time. Since the driver is using the usbdevfs interface the problem

Re: [BUGREPORT] Linux USB 3.0

On Tue, Feb 4, 2014 at 10:31 AM, David Laight wrote: > From: Markus Rechberger >> >> Dec 27 23:23:50 solist kernel: [ 36.118245] xhci_hcd :00:14.0: >> >> ERROR Transfer event TRB DMA >> ptr >> > >> > These messages might be harmless. The 3.0 kernel contains a fix for >> > Intel Panther

Re: [BUGREPORT] Linux USB 3.0

On Tue, Feb 4, 2014 at 10:31 AM, David Laight david.lai...@aculab.com wrote: From: Markus Rechberger Dec 27 23:23:50 solist kernel: [ 36.118245] xhci_hcd :00:14.0: ERROR Transfer event TRB DMA ptr These messages might be harmless. The 3.0 kernel contains a fix for Intel Panther

Re: [BUGREPORT] Linux USB 3.0

The next one, just today (unfortunately it's in German): http://support.sundtek.com/index.php/topic,1505.msg11020.html#msg11020 This guy is using Ubuntu with Linux 3.13.0-8-generic The system seems to freeze completely after some time. Since the driver is using the usbdevfs interface the problem

RE: [BUGREPORT] Linux USB 3.0

From: Markus Rechberger > >> Dec 27 23:23:50 solist kernel: [ 36.118245] xhci_hcd :00:14.0: ERROR > >> Transfer event TRB DMA > ptr > > > > These messages might be harmless. The 3.0 kernel contains a fix for > > Intel Panther Point xHCI hosts that suppresses those messages, commit > >

RE: [BUGREPORT] Linux USB 3.0

From: Markus Rechberger Dec 27 23:23:50 solist kernel: [ 36.118245] xhci_hcd :00:14.0: ERROR Transfer event TRB DMA ptr These messages might be harmless. The 3.0 kernel contains a fix for Intel Panther Point xHCI hosts that suppresses those messages, commit

Re: [BUGREPORT] Linux USB 3.0

2.0 speeds. I suspect the USB > device triggers an issue with the xHCI driver, and 3.2 only works > because the device is on an EHCI port without the switchover code. > >> > On Fri, Dec 27, 2013 at 6:18 PM, Markus Rechberger >> > wrote: >> >> I just go

Re: [BUGREPORT] Linux USB 3.0

...@gmail.com wrote: I just got another USB 3.0 bugreport, the entire system crashed. That particular customer already filed a bugreport in November 2013 that his system is in a bad state when using some USB 2.0 media devices which even have opensource drivers built into the kernel. USB 3.0

Re: [BUGREPORT] Linux USB 3.0

CI host, and USB 3.0 devices will work at USB 2.0 speeds. I suspect the USB device triggers an issue with the xHCI driver, and 3.2 only works because the device is on an EHCI port without the switchover code. > > On Fri, Dec 27, 2013 at 6:18 PM, Markus Rechberger > > wrote: > >>

Re: [BUGREPORT] Linux USB 3.0

an issue with the xHCI driver, and 3.2 only works because the device is on an EHCI port without the switchover code. On Fri, Dec 27, 2013 at 6:18 PM, Markus Rechberger mrechber...@gmail.com wrote: I just got another USB 3.0 bugreport, the entire system crashed. That particular customer

Re: [BUGREPORT] Linux USB 3.0

B 3.0 > support within those releases? > It does not seem to be SG support. > > On Fri, Dec 27, 2013 at 6:18 PM, Markus Rechberger > wrote: >> I just got another USB 3.0 bugreport, the entire system crashed. That >> particular customer already filed a bugreport in No

Re: [BUGREPORT] Linux USB 3.0

. On Fri, Dec 27, 2013 at 6:18 PM, Markus Rechberger wrote: > I just got another USB 3.0 bugreport, the entire system crashed. That > particular customer already filed a bugreport in November 2013 that > his system is in a bad state when using some USB 2.0 media devices > which even hav

Re: [BUGREPORT] Linux USB 3.0

I just got another USB 3.0 bugreport, the entire system crashed. That particular customer already filed a bugreport in November 2013 that his system is in a bad state when using some USB 2.0 media devices which even have opensource drivers built into the kernel. USB 3.0 support with Linux seems

Re: [BUGREPORT] Linux USB 3.0

I just got another USB 3.0 bugreport, the entire system crashed. That particular customer already filed a bugreport in November 2013 that his system is in a bad state when using some USB 2.0 media devices which even have opensource drivers built into the kernel. USB 3.0 support with Linux seems

Re: [BUGREPORT] Linux USB 3.0

. On Fri, Dec 27, 2013 at 6:18 PM, Markus Rechberger mrechber...@gmail.com wrote: I just got another USB 3.0 bugreport, the entire system crashed. That particular customer already filed a bugreport in November 2013 that his system is in a bad state when using some USB 2.0 media devices which

  1   2   >