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
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
drivers/gpu/drm/amd/amdgpu/../d
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] DEBUG_LOCKS_WARN_ON(ww_ctx->contend
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
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 linke
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
__bfq_de
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
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 f
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 [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 problem.
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 ]
[92414.864648
rgv)
> }
>
> if (KDB_DEBUG(MASK))
> - kdb_printf("KDBFLAGS=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
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
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. If
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
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 err
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
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: Da
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 increasing
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
> > > ---
> > >
> > > Not
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 think
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:
>
> drivers/media/platform/omap/oma
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
uninitializ
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:
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 h
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
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
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 exc
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
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
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
ces 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:
>> >
remain under the EHCI 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
> >
ed USB 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
pport.
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 eve
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
A customer using a device with USBDEVFS is reporting following
backtrace (it seems to be a rather generic issue related to linux usb
3.0 in general):
According to him this problem is reproducible as soon as he starts the
data transfer, is there anything known about that?
He is using 3.12.0-031200-
Perf doesn't properly clean up /tmp/perf-vdso.so-XX on exit. So
these files keep accumulating in /tmp every time perf is run.
--
Markus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http
Sergei Shtylyov wrote:
>>> You left powerpc-lite.patch broken with this change as it has
>>> multiple calls to kgdb8250_add_port()...
>
>> I see. But I wonder if there ever was a real need for these hooks (in
>> 2.4 times?): If I look at bamboo_early_serial_map() e.g., I find it
>> calling into
Hello.
Jan Kiszka wrote:
Sorry, previous version was missing some __init[data] attributes which
were dropped in an intermediate stage. Here comes an updated patch:
<---snip--->
This major refactoring of the quite complex kgdb8250 configuration does
the following:
- ensures that static
Jan Kiszka wrote:
> Just a beautification of using debugger_active for checking the debugger
> state.
>
> Signed-off-by: Jan Kiszka <[EMAIL PROTECTED]>
>
> ---
> arch/x86/kernel/kgdb.c |6 +++---
> include/linux/kgdb.h |7 ++-
> kernel/kgdb.c |8
> kernel/sched.
Sergei Shtylyov wrote:
> Hello.
>
> Jan Kiszka wrote:
>
>> Sorry, previous version was missing some __init[data] attributes which
>> were dropped in an intermediate stage. Here comes an updated patch:
>
>> <---snip--->
>
>> This major refactoring of the quite complex kgdb8250 configuration does
Hello.
Jan Kiszka wrote:
Sorry, previous version was missing some __init[data] attributes which
were dropped in an intermediate stage. Here comes an updated patch:
<---snip--->
This major refactoring of the quite complex kgdb8250 configuration does
the following:
- ensures that static
Jan Kiszka wrote:
> George Anzinger wrote:
>> On 01/31/2008 01:36 AM, Jan Kiszka was caught saying:
>>> BTW, do you know if EXCEPTION_STACK_READY fails for other archs in
>>> parse_early_param as well? It should, because my under standing of
>>> trap_init is that it's the functions to arm things l
George Anzinger wrote:
> On 01/31/2008 01:36 AM, Jan Kiszka was caught saying:
>> Jan Kiszka wrote:
>>> George Anzinger wrote:
On 01/30/2008 04:08 PM, Jan Kiszka was caught saying:
> [Here comes a rebased version against latest x86/mm]
>
> In case "kgdbwait" is passed as kernel p
On 01/31/2008 01:36 AM, Jan Kiszka was caught saying:
> Jan Kiszka wrote:
>> George Anzinger wrote:
>>> On 01/30/2008 04:08 PM, Jan Kiszka was caught saying:
[Here comes a rebased version against latest x86/mm]
In case "kgdbwait" is passed as kernel parameter, KGDB tries to set up
Jan Kiszka wrote:
> Hi Jason,
>
> so far I ignored this because it worked, but I know my customer will
> complain later anyway: What is the deeper meaning of this warning which
> shows up once per registered UART port on my (x86) boxes?
>
> void kgdb8250_add_port(int i, struct uart_port *serial_r
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
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 highmem, no highmem, or highmem4G with limited
memory by mem=3G. All d
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
Kgdb-bugreport mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/kgdb-bugreport
Pete/Piet Delaney wrote:
We are getting a problem with VMware where kernel text is the schedler
is getting wacked with four null bytes into the code. Thought I'd use
the current linux-2.6-kgdb.git tree and possible the CONFIG_DEBUG_RODATA
patch to make kernel text readonly:
https://www.x86-64.o
Pete/Piet Delaney wrote:
Why am I getting this when I do:
git clone
http://master.kernel.org/pub/scm/linux/kernel/git/jwessel/linux-2.6-kgdb.git
I have only ever used:
git clone
git://git.kernel.org/pub/scm/linux/kernel/git/jwessel/linux-2.6-kgdb.git
Jason.
-
To unsubscribe from this l
On Wed, 29 Aug 2007 18:19:29 -0700 Pete/Piet Delaney wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Pete/Piet Delaney wrote:
> > Jason Wessel wrote:
> >> Andrew Morton wrote:
> >>> On Wed, 22 Aug 2007 17:44:12 -0500
> >>> Jason Wessel <[EMAIL PROTECTED]> wrote:
> >>>
> >>>
>
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Pete/Piet Delaney wrote:
> Jason Wessel wrote:
>> Andrew Morton wrote:
>>> On Wed, 22 Aug 2007 17:44:12 -0500
>>> Jason Wessel <[EMAIL PROTECTED]> wrote:
>>>
>>>
+while (!atomic_read(&debugger_active));
>>> eek. We're in the proce
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Pete/Piet Delaney wrote:
> Jason Wessel wrote:
>> Andrew Morton wrote:
>>> On Wed, 22 Aug 2007 17:44:12 -0500
>>> Jason Wessel <[EMAIL PROTECTED]> wrote:
>>>
>>>
+while (!atomic_read(&debugger_active));
>>> eek. We're in the proce
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Jason Wessel wrote:
> Andrew Morton wrote:
>> On Wed, 22 Aug 2007 17:44:12 -0500
>> Jason Wessel <[EMAIL PROTECTED]> wrote:
>>
>>
>>> +while (!atomic_read(&debugger_active));
>>>
>>
>> eek. We're in the process of hunting down and eliminati
Andrew Morton wrote:
On Wed, 22 Aug 2007 17:44:12 -0500
Jason Wessel <[EMAIL PROTECTED]> wrote:
+ while (!atomic_read(&debugger_active));
eek. We're in the process of hunting down and eliminating exactly this
construct. There have been cases where the compiler cached the
atomi
On Wed, 22 Aug 2007 17:44:12 -0500
Jason Wessel <[EMAIL PROTECTED]> wrote:
> Perhaps there is a cleaner way to do the same thing and avoid the
> cmpxchg all together. I used the attached patch to eliminate the
> cmpxchg operation.
>
>
> Jason.
>
>
> [kgdb_enter_atomic.patch text/plain (2.0
Andrew Morton wrote:
On Wed, 22 Aug 2007 21:04:28 +0200
Mariusz Kozlowski <[EMAIL PROTECTED]> wrote:
Hello,
Got that on imac g3.
CC kernel/kgdb.o
kernel/kgdb.c: In function 'kgdb_handle_exception':
kernel/kgdb.c:940: error: invalid lvalue in unary '&'
kernel/kgdb.c:940: warn
Hello there!
Here my first bugreport on the linux kernel:
[1.] One line summary of the problem:
SATA Problem: port is slow to respond
[2.] Full description of the problem/report:
The following messages appear while booting/in dmesg [1]:
[...]
ata2: port is slow to respond, please be patient
* 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.
Hey,
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.10 though. Is there any changes made that ca
Hi,
Every once in a while, my system gets unbelievable slow. So slow that I
almost can't do anything anymore. This happens only once in a few months.
I think it has to do with sound, because when I start using sound, it happens.
"top" gives me then about 90% idle time, and "top" is using this 10%
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
[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 after 10n ms on average. Poll() timeouts between 10n-9 and 10n ms,
on the other hand, time o
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
1. Kernel crash w/out error message or logfile entry
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
exotic hardware. Another possibility might be Reiserfs, which I use for all
partitions except /
1 - 100 of 103 matches
Mail list logo
