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

2021-03-07 Thread Dmitry Vyukov
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 leading

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

2021-03-06 Thread Dmitry Vyukov
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 yo

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

2021-03-05 Thread Ming Lei
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

2021-03-05 Thread Paolo Valente
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

2021-03-05 Thread Ming Lei
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 p

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

2021-03-04 Thread Ming Lei
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 > /lib/debug

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

2020-11-04 Thread Alex Deucher
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 > Continiou

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

2020-10-16 Thread Mikhail Gavrilov
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 nft

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

2019-05-28 Thread Theodore Ts'o
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

2019-05-27 Thread Mikhail Gavrilov
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 e93c9c99a629c61837d5a7fc2120cd2b6c70

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

2019-05-27 Thread Mikhail Gavrilov
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 > 0(

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

2019-05-18 Thread Alex Xu (Hello71)
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 - magi

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

2016-10-30 Thread Levin, Alexander
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()

2016-10-28 Thread Greg KH
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 shouldn'

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

2016-10-28 Thread Al Viro
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 sugges

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

2016-10-28 Thread Al Viro
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 t

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

2016-10-28 Thread Linus Torvalds
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 hackery

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

2016-10-27 Thread Al Viro
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()

2016-10-27 Thread Al Viro
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 > Date:

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

2014-03-31 Thread Yijing Wang
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 usbcor

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

2014-03-31 Thread Yijing Wang
>> 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 ta

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

2014-03-31 Thread Thomas Gleixner
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 offi

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

2014-03-31 Thread Sebastian Andrzej Siewior
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

2014-03-28 Thread Yijing Wang
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 Molna

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

2014-03-28 Thread Sebastian Andrzej Siewior
* 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] Linux USB 3.0

2014-02-11 Thread Markus Rechberger
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

2014-02-11 Thread Greg KH
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

2014-02-11 Thread Bjørn Mork
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 ker

Re: [BUGREPORT] Linux USB 3.0

2014-02-11 Thread Markus Rechberger
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 Tr

Re: [BUGREPORT] Linux USB 3.0

2014-02-09 Thread Robert Hancock
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 fix

Re: [BUGREPORT] Linux USB 3.0

2014-02-08 Thread Markus Rechberger
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 i

Re: [BUGREPORT] Linux USB 3.0

2014-02-08 Thread Markus Rechberger
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 Poi

RE: [BUGREPORT] Linux USB 3.0

2014-02-04 Thread David Laight
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 > > ad808

Re: [BUGREPORT] Linux USB 3.0

2014-02-03 Thread Markus Rechberger
Hi Sarah, On Mon, Jan 20, 2014 at 8:35 PM, Sarah Sharp wrote: > Hi Markus, > > I'm the xHCI driver maintainer, and it helps to Cc me on USB 3.0 bug > reports. > > On Sat, Dec 28, 2013 at 07:24:20AM +0100, Markus Rechberger wrote: >> just received following log snippset: > > Please state which ker

Re: [BUGREPORT] Linux USB 3.0

2014-01-20 Thread Sarah Sharp
Hi Markus, I'm the xHCI driver maintainer, and it helps to Cc me on USB 3.0 bug reports. On Sat, Dec 28, 2013 at 07:24:20AM +0100, Markus Rechberger wrote: > just received following log snippset: Please state which kernel version you (or your customer) is running. You've reported issues with sev

Re: [BUGREPORT] Linux USB 3.0

2013-12-27 Thread Markus Rechberger
just received following log snippset: Dec 27 23:23:50 solist kernel: [ 36.118245] xhci_hcd :00:14.0: ERROR Transfer event TRB DMA ptr Dec 27 23:23:50 solist kernel: [ 36.177695] xhci_hcd :00:14.0: ERROR Transfer event TRB DMA ptr Dec 27 23:23:50 solist kernel: [ 36.217966] xhci_hcd 0

Re: [BUGREPORT] Linux USB 3.0

2013-12-27 Thread Markus Rechberger
Seems like DH87RL was working with 3.2.0-55-generic-pae unfortunately we don't have such a board for testing and customer patience is limited to bisect the kernel. Does anyone have a clue what modification could have killed USB 3.0 support within those releases? It does not seem to be SG support.

Re: [BUGREPORT] Linux USB 3.0

2013-12-27 Thread Markus Rechberger
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 to

Re: bugreport kernel panic on early stage, with HIGHMEM4G:

2008-01-17 Thread Denys Fedoryshchenko
Patch fixes the problem. Here is dmesg (i cut it, probably remaining part of it not required). 0] Movable zone: 0 pages used for memmap [0.00] DMI 2.4 present. [0.00] ACPI: RSDP 000FE020, 0014 (r0 INTEL ) [0.00] ACPI: RSDT CFEFD038, 0050 (r1 INTEL DG965SS 6B7

Re: bugreport kernel panic on early stage, with HIGHMEM4G:

2008-01-17 Thread Mel Gorman
On (15/01/08 14:13), Ingo Molnar didst pronounce: > > * Ingo Molnar <[EMAIL PROTECTED]> wrote: > > > thanks for the detailed report, i think i know what's going on. Could > > you try the patch below, does it fix your problem? > > find below the fix with a more complete changelog and with no deb

Re: bugreport kernel panic on early stage, with HIGHMEM4G:

2008-01-15 Thread Ingo Molnar
* Ingo Molnar <[EMAIL PROTECTED]> wrote: > thanks for the detailed report, i think i know what's going on. Could > you try the patch below, does it fix your problem? find below the fix with a more complete changelog and with no debugging printouts. Ingo --> Subject: x86:

Re: bugreport kernel panic on early stage, with HIGHMEM4G:

2008-01-15 Thread Ingo Molnar
* Denys Fedoryshchenko <[EMAIL PROTECTED]> wrote: > Hi > > After physical memory upgrade from 3GB to 4GB (also it happens on 5GB) > got kernel panic. > > Because it is happening on early stage and my machine doesn't contain > serial port, i had to take photo. Kernel boots fine with 64GB highm

Re: Bugreport

2005-04-12 Thread Chris Wright
* Amelia Nilsson ([EMAIL PROTECTED]) wrote: > I've found a bug in 2.6.11.6. I have a Toshiba laptop and when i did > run 2.6.11.6 my touchpad flipped out, it clicked everywhere when it > wasn't supposed to click. I couldn't even move my mouse without it was > clicking all over. It works fine i 2.6.

Re: bugreport: poll() timeout always takes 10ms too long

2001-06-22 Thread raf
Tachino Nobuhiro wrote: > > Hello, > > At Fri, 22 Jun 2001 11:52:12 +1000, > [EMAIL PROTECTED] wrote: > > > > [1.] One line summary of the problem: > > > > poll() timeout always takes 10ms too long > > > > [2.] Full description of the problem/report: > > > > Select() timeouts work fine

Re: bugreport: poll() timeout always takes 10ms too long

2001-06-21 Thread Tachino Nobuhiro
Hello, At Fri, 22 Jun 2001 11:52:12 +1000, [EMAIL PROTECTED] wrote: > > [1.] One line summary of the problem: > > poll() timeout always takes 10ms too long > > [2.] Full description of the problem/report: > > Select() timeouts work fine. A timeout between 10n-9 and 10n ms times > out af

Re: Bugreport: Kernel 2.4.x crash

2001-04-18 Thread Jörn Engel
Hi! > > I have no experience with kernel debugging, but so far, I have found > > no log entry giving me a hint and the screen is blank after the crash > > Could you disable console blanking (setterm -blank 0). > > We really need a hint where it crashed. Over the easter weekend I took some time

Re: Bugreport: Kernel 2.4.x crash

2001-04-03 Thread Mark Hahn
> 2. A Fileserver with an ABIT Hotrod 66 (htp366) controller will crash within > 5-60 minutes after boot with a 2.4.x kernel. 2.2.x works fine. No other no problem with ext2 on hpt366 here. > Gnu C 2.95.3 hmm. - To unsubscribe from this list: send the line "unsubscribe linux-k

Re: Bugreport: Kernel 2.4.x crash

2001-04-03 Thread John Jasen
On Tue, 3 Apr 2001, [iso-8859-1] Jörn Engel wrote: I don't necessarily believe its the hpt366, as you do. See below: (note: I've also had it running on a stock 2.4.2 kernel for a while) > 00:08.0 Unknown mass storage controller: Triones Technologies, Inc. HPT366 > (rev 01) > Control: I/O

Re: Bugreport kernel 2.4.0-test8

2000-09-19 Thread Steven Cole
On 2000-09-19 8:33:49 Michael Zieger wrote: >I just found a big bug in kernel 2.4.0-test8 that leads to a major >crash because PID 4 [kupdate] dies. >I could reproduce the problem by doing this: >- Open StarOffice under KDE >- Create new textfile >- Try to save it under a via NFS mounted directo