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
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
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
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:
>
>
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
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
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
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
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
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
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(
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
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
>
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'
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
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
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
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
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:
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
>> 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
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
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.
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
* 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
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
>> >>
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
> >>
> >>
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
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
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
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
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
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
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
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
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
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.
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
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
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
* 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:
* 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
* 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.
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
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
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
> 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
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
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
49 matches
Mail list logo