On 5/16/16, Jeff Merkey wrote:
> On 5/15/16, OenHan wrote:
>> Maybe you should install kexec-tools or uncheck kdump options in .config:
>>
>> rpm -qf /lib/kdump/kdump-lib.sh
>> kexec-tools-2.0.7-38.el7_2.1.x86_64
>>
The problem here is that Centos 7 has the sc
On 5/15/16, OenHan wrote:
> Maybe you should install kexec-tools or uncheck kdump options in .config:
>
> rpm -qf /lib/kdump/kdump-lib.sh
> kexec-tools-2.0.7-38.el7_2.1.x86_64
>
>
> Thanks
>
> Oen Han
>
Updated the package and it fixed the kdump problem. The other problem
with firmware was reso
A lot of breakage for Building v4.6 on Centos 7.
The following error occurs after booting Linux v4.6 on Centos 7 with a
Radeon Adapter:
R600_cp: Failed to load Firmware "Radeon/R600_rlc.bin
FATAL Error during GPU init.
Linux v4.5 works fine. Also of note, someone moved some scripts
around resu
Interesting read.
http://www.ece.ubc.ca/~sasha/papers/eurosys16-final29.pdf
"... The Linux kernel scheduler has deficiencies that prevent a
multicore system from making proper use of all cores for heavily
multithreaded loads, according to a lecture and paper delivered
earlier this month at the Eu
On 4/11/16, Sasha Levin wrote:
> On 04/11/2016 02:34 PM, Jeff Merkey wrote:
>> On 4/11/16, Sasha Levin wrote:
>>> Hi all,
>>>
>>>
>>> I'd like to announce the linux-stable security tree project. The purpose
>>> is to create a derivati
On 4/11/16, Sasha Levin wrote:
> Hi all,
>
>
> I'd like to announce the linux-stable security tree project. The purpose
> is to create a derivative tree from the regular stable tree that would
> contain only commits that fix security vulnerabilities.
>
> Quite a few users of the stable trees point
On 4/11/16, Sasha Levin wrote:
> Hi all,
>
>
> I'd like to announce the linux-stable security tree project. The purpose
> is to create a derivative tree from the regular stable tree that would
> contain only commits that fix security vulnerabilities.
>
> Quite a few users of the stable trees point
Hi Joe,
Ran across a false positive case on asm volatile single line
statements. If you
use asm volatile it assumes its a complex statement fires off an error:
# ./scripts/checkpatch.pl --strict test.patch
ERROR: Macros with complex values should be enclosed in parentheses
#9: FILE: arch/x86/in
Is camel case discouraged in linux code? I noticed a check for it in
checkpatch.pl but it is not one of the default options form scanning.
Jeff
On 2/20/16, Jeff Merkey wrote:
> Is camel case discouraged in linux code? I noticed a check for it in
> checkpatch.pl but it is not one of the default options form scanning.
>
> Jeff
>
Found a great writeup from Greg on the subject. question answered.
Do not use it if possib
On 2/11/16, Theodore Ts'o wrote:
> On Thu, Feb 11, 2016 at 11:12:12AM -0700, Jeff Merkey wrote:
>>
>> That's good to know, they could be false positives, but it was kind of
>> wierd behavior caused by that macro.
>
> If it is true, it sounds more like a compil
On 2/11/16, Jeff Merkey wrote:
>> In your case, for example, I looked through several dozen warnings,
>> and they were ***all*** bogus. Keep in mind that this might make me
>> less inclined to pay attention to complaints from you in the future.
>> The story of the buy
> In your case, for example, I looked through several dozen warnings,
> and they were ***all*** bogus. Keep in mind that this might make me
> less inclined to pay attention to complaints from you in the future.
> The story of the buy who cried wolf too often comes to mind.
>
> Perhaps you could ac
On 2/11/16, Theodore Ts'o wrote:
> On Thu, Feb 11, 2016 at 11:12:12AM -0700, Jeff Merkey wrote:
>>
>> That's good to know, they could be false positives, but it was kind of
>> wierd behavior caused by that macro.
>
> If it is true, it sounds more like a compil
On 2/11/16, Theodore Ts'o wrote:
> On Wed, Feb 10, 2016 at 08:13:09PM -0700, Jeff Merkey wrote:
>> Here are the sources of several bugs I have seen recently in ext4 I am
>> pretty sure with a null bh. One good check is to set the BUG() macro
>> NOT TO call unreachable()
Hi,
I noticed that the use of the function -- unreachable() -- inside of
the BUG() macro in arch/x86/include/asm/bug.h causes compiler output
to be suspect based on review of assembly output for quite a few
areas.
if as a test, you remove the call to unreachable() in the BUG() macro,
it seems to
On 2/1/16, Vineet Gupta wrote:
> On Friday 29 January 2016 01:16 AM, Jeffrey Merkey wrote:
>> This patch series adds an export which can be set by system debuggers to
>> direct the hard lockup and soft lockup detector to trigger a breakpoint
>> exception and enter a debugger if one is active. It
On 2/1/16, Maciej W. Rozycki wrote:
> On Thu, 28 Jan 2016, Jeffrey Merkey wrote:
>
>> This patch series adds an export which can be set by system debuggers to
>> direct the hard lockup and soft lockup detector to trigger a breakpoint
>> exception and enter a debugger if one is active. It is assum
>
> Just so you know, I have no intention of supporting this use case. In
> fact, I'm planning to eventually stop using IST for #DB entirely, at
> which point the kernel will crash terribly if this code is
> single-stepped (except when using a hypervisor to do this single
> stepping, which is a mu
This lockless memory based synchronization in csd_lock_wait just
doesn't work on all smp systems because not all of them properly
implement these fancy memory fencing instructions. I've run into this
before trying to do lockless queueing on a range of SMP systems.
About the only thing guaranteed t
On 1/30/16, Andy Lutomirski wrote:
> On Sat, Jan 30, 2016 at 9:53 AM, Jeff Merkey wrote:
>> On 1/30/16, Andy Lutomirski wrote:
>>> On Sat, Jan 30, 2016 at 12:41 AM, Jeff Merkey
>>> wrote:
>>>> Here is an MDB debugger trace of the code in question.
On 1/30/16, Andy Lutomirski wrote:
> On Sat, Jan 30, 2016 at 12:41 AM, Jeff Merkey wrote:
>> Here is an MDB debugger trace of the code in question. please note
>> that the flags being compared don't match what's in r11 and the
>> comparison bits are w
Here is an MDB debugger trace of the code in question. please note
that the flags being compared don't match what's in r11 and the
comparison bits are wrong.
(3)>
Break at 0x81680022 due to - Proceed (single step)
RAX: 0080 RBX: 0002 RCX: 7FC9877F2A30
RDX: 000
On 1/25/16, Jeff Merkey wrote:
> On 1/25/16, Jeff Merkey wrote:
>> On 1/24/16, Jeff Merkey wrote:
>>> On 1/24/16, Jeff Merkey wrote:
>>>> If I single step with either kgdb, kgdb, or mdb kernel debuggers over
>>>> a sysret instruction any
On 1/27/16, Joe Perches wrote:
> On Wed, 2016-01-27 at 10:52 -0700, Jeff Merkey wrote:
>> So while putting together a patch series that adds some include files
>> in the arch/ I ran across the checkpatch WARNING that says MAINTAINERS
>> needs updating for new files with c
So while putting together a patch series that adds some include files
in the arch/ I ran across the checkpatch WARNING that says MAINTAINERS
needs updating for new files with create mode.
Is the best way to do this to submit MAINTAINERS as a separate patch
or in its own patch with the series, or c
On 1/26/16, kbuild test robot wrote:
> Hi Jeff,
>
> [auto build test ERROR on v4.5-rc1]
> [also build test ERROR on next-20160125]
> [if your patch is applied to the wrong git tree, please drop us a note to
> help improving the system]
>
> url:
> https://github.com
On 1/26/16, Chris Metcalf wrote:
> On 01/26/2016 12:04 PM, Jeff Merkey wrote:
>> This patch adds an export which can be set by system debuggers to direct
>> the hard lockup and soft lockup detector to trigger a breakpoint
>> exception
>> and enter a debugger if one is
loaded or registered via the notify die handler chain.
This addition is extremely useful for debugging hard and soft lockups
real time and quickly from a console debugger.
Signed-off-by: Jeff Merkey
---
kernel/watchdog.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/kernel
On 1/25/16, kbuild test robot wrote:
> Hi Jeff,
>
> [auto build test ERROR on v4.5-rc1]
> [also build test ERROR on next-20160125]
> [if your patch is applied to the wrong git tree, please drop us a note to
> help improving the system]
>
> url:
> https://github.com
On 1/25/16, Jeff Merkey wrote:
> On 1/24/16, Jeff Merkey wrote:
>> On 1/24/16, Jeff Merkey wrote:
>>> If I single step with either kgdb, kgdb, or mdb kernel debuggers over
>>> a sysret instruction anywhere in the OS, the system hard hangs in
>>> smp_cal
On 1/25/16, Chris Metcalf wrote:
> On 1/25/2016 9:36 PM, Jeff Merkey wrote:
>> This patch adds an export which can be set by system debuggers to direct
>> the hard lockup and soft lockup detector to trigger an INT3 exception
>> and enter a debugger if one is active. It is as
registered via the notify die handler chain.
This addition is extremely useful for debugging hard and soft lockups
real time and quickly from a console debugger.
Signed-off-by: Jeff Merkey
---
kernel/watchdog.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/kernel/watchdog.c b/kernel
On 1/24/16, Jeff Merkey wrote:
> On 1/24/16, Jeff Merkey wrote:
>> If I single step with either kgdb, kgdb, or mdb kernel debuggers over
>> a sysret instruction anywhere in the OS, the system hard hangs in
>> smp_call_function_single after the debugger releases the sys
On 1/25/16, Jan Kara wrote:
> On Sat 23-01-16 09:42:52, Jeff Merkey wrote:
>> If I leave the system in the debugger console overnight with all the
>> processors suspended for about 8 hours, then type go, the following
>> bug shows up during file I/O. This particular bug sho
On 1/24/16, Jeff Merkey wrote:
> If I single step with either kgdb, kgdb, or mdb kernel debuggers over
> a sysret instruction anywhere in the OS, the system hard hangs in
> smp_call_function_single after the debugger releases the system and it
> resumes normal operation.The sp
If I single step with either kgdb, kgdb, or mdb kernel debuggers over
a sysret instruction anywhere in the OS, the system hard hangs in
smp_call_function_single after the debugger releases the system and it
resumes normal operation.The specific place the kernel hangs is in
the loop below. Th
On 1/23/16, Greg KH wrote:
> I'm announcing the release of the 4.3.4 kernel.
>
> All users of the 4.3 kernel series must upgrade.
>
> The updated 4.3.y git tree can be found at:
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
> linux-4.3.y
> and can be browsed at the
On 1/23/16, Jeff Merkey wrote:
> If I leave the system in the debugger console overnight with all the
> processors suspended for about 8 hours, then type go, the following
> bug shows up during file I/O. This particular bug showed up while
> using git to update some branches.
>
If I leave the system in the debugger console overnight with all the
processors suspended for about 8 hours, then type go, the following
bug shows up during file I/O. This particular bug showed up while
using git to update some branches.
I have only seen this bug once and I attempted to reproduce
Based on recent bugs I have seen in Linux, I recommend to those
involved in regression testing of linux build tree to add a debugger
test to regression for kgdb, kdb, and mdb as a part of your standard
tests to flush out bugs in various drivers and subsystems.
The test is simple. Load one of the
Hi Thomas,
I figured out where the top-posting is coming from -- gmail web client
does it automatically. Switching email clients. I will still use
gmail for smtp forwarding but their busted piece of crap web email
client automatically top posts when you use the "reply" window and
it's gone.
I a
I am switching email clients from gmail. This stupid email client of
theirs constantly top posts and sends multiple emails replies when you
try to send a reply. I apologize yet again for the top posting. It's
gmail doing it. Unless I delete the entire previous message it will
always top post.
ls to systemd when that rax
value wraps.
Jeff.
On 1/21/16, Jeff Merkey wrote:
> Hi Thomas
>
> That patch works and so does the patch currently in linux-next. Yeah !
>
> The code on your machine is apparently from the linux-next tree. In
> 4.4 is busted and that was the build I
linux revs, so I have to retro apply
this patch back to v3.6 in the MDB patch series. This bug was
introduced in the late linux 3.6 kernels and exists in all of them up
to v4.4.
Jeff
On 1/21/16, Thomas Gleixner wrote:
> Jeff,
>
> On Thu, 21 Jan 2016, Jeff Merkey wrote:
>>
This bug has been fixed as of linux-next-20160121. I just checked so
looks like its handled.
delta = timekeeping_get_delta(tkr);
nsec = (delta * tkr->mult + tkr->xtime_nsec) >> tkr->shift;
251: 8b 15 00 00 00 00 mov0x0(%rip),%edx# 257
257:
On 1/21/16, Jeff Merkey wrote:
> Ok, here's what I found after several hours of debugging and reviewing
> this subsystem:
>
> This subsystem plays is pretty loose in doing its math on 64 bit
> registers. I traced through ktime_get_ts64 hundreds of times and
> sampled data
Ok, here's what I found after several hours of debugging and reviewing
this subsystem:
This subsystem plays is pretty loose in doing its math on 64 bit
registers. I traced through ktime_get_ts64 hundreds of times and
sampled data running through it and from what I saw, just normal
operations come
On 1/20/16, Thomas Gleixner wrote:
> Jeff,
>
> On Wed, 20 Jan 2016, Jeff Merkey wrote:
>> Thomas, so far the only thing I've gotten from you are whining
>> diatribes about email ettiquette and today is the FIRST time you have
>> responded to me with any argumen
On 1/20/16, John Stultz wrote:
> On Wed, Jan 20, 2016 at 9:42 AM, Thomas Gleixner
> wrote:
>> On Wed, 20 Jan 2016, John Stultz wrote:
>>> Ehrm. A more productive route in solving this might be to cap the
>>> cycle delta we return from timekeeping_get_delta().
>>>
>>> We already do this in the CO
On 1/20/16, John Stultz wrote:
> On Wed, Jan 20, 2016 at 9:16 AM, Jeff Merkey wrote:
>> On 1/20/16, Jeff Merkey wrote:
>>> On 1/20/16, Thomas Gleixner wrote:
>>>> On Tue, 19 Jan 2016, Jeff Merkey wrote:
>>>>> Nasty bug but trivial fix for this. Wh
On 1/20/16, Thomas Gleixner wrote:
> On Wed, 20 Jan 2016, Jeff Merkey wrote:
>> On 1/20/16, Thomas Gleixner wrote:
>> > On Tue, 19 Jan 2016, Jeff Merkey wrote:
>> >> Nasty bug but trivial fix for this. What happens here is RAX (nsecs)
>> >> gets set
On 1/20/16, Jeff Merkey wrote:
> On 1/20/16, Thomas Gleixner wrote:
>> On Tue, 19 Jan 2016, Jeff Merkey wrote:
>>> Nasty bug but trivial fix for this. What happens here is RAX (nsecs)
>>> gets set to a huge value (RAX = 0x17AE7F57C671EA7D) and passed through
>
On 1/20/16, Thomas Gleixner wrote:
> On Tue, 19 Jan 2016, Jeff Merkey wrote:
>> Nasty bug but trivial fix for this. What happens here is RAX (nsecs)
>> gets set to a huge value (RAX = 0x17AE7F57C671EA7D) and passed through
>
> And how exactly does that happen?
>
> 0x
On 1/20/16, Thomas Gleixner wrote:
> Jeff,
>
> On Wed, 20 Jan 2016, Thomas Gleixner wrote:
>> On Tue, 19 Jan 2016, Jeff Merkey wrote:
>> > Nasty bug but trivial fix for this. What happens here is RAX (nsecs)
>> > gets set to a huge value (RAX = 0x17AE7F57C671E
On 1/6/16, Albert Cahalan wrote:
> This bug was introduced with SE Linux, 18 years ago. People have been
> adding hacks to work around it as the bug bites them, but really the
> bug ought to be fixed. Signals related to a tty are supposed to come
> from the kernel. This got broken for pty devices.
On 1/3/16, Andrey Utkin wrote:
> After "Send this email? ([y]es|[n]o|[q]uit|[a]ll): y" prompt and
> before "Password for 'smtp://x...@gmail.com@smtp.gmail.com:587':"
> prompt I always have a delay of 2-3 minutes. It is weird! "Unsafe
> clients" are allowed in Gmail settings.
> I experience this bo
Let me know if I need to do anything else with this patch. I am using
git/mutt to send patches from now on and I have my smtp gateway with
gmail properly setup and tested so there won't be any more fritzed
patches.It looks like this is relatively easy to do if you ge the
tools setup correctly.
itching" to function
correctly.
Signed-off-by: Jeff Merkey
---
arch/x86/include/uapi/asm/debugreg.h | 1 +
arch/x86/kernel/hw_breakpoint.c | 25 +++--
2 files changed, 24 insertions(+), 2 deletions(-)
diff --git a/arch/x86/include/uapi/asm/debugreg.h
b/arch/x86
> /*
> + * Check if we got an execute breakpoint, if so
> + * set the resume flag to avoid int1 recursion.
> + */
> + if ((dr7 & (DR_RW_MASK << ((i * DR_CONTROL_SIZE) +
> + DR_CONTROL_SHIFT))) == DR_RW_EXECUTE)
> +
itching" to function
correctly.
Signed-off-by: Jeff Merkey
---
arch/x86/include/uapi/asm/debugreg.h | 1 +
arch/x86/kernel/hw_breakpoint.c | 25 +++--
2 files changed, 24 insertions(+), 2 deletions(-)
diff --git a/arch/x86/include/uapi/asm/debugreg.h
b/arch/x86
On 12/19/15, Jeff Merkey wrote:
> On 12/19/15, Jeff Merkey wrote:
>> On 12/19/15, Mike Galbraith wrote:
>>> On Sat, 2015-12-19 at 19:13 -0700, Jeff Merkey wrote:
>>>
>>>> @@ -519,6 +528,18 @@ static int hw_breakpoint_handler(struct die_args
>&g
On 12/19/15, Jeff Merkey wrote:
> On 12/19/15, Mike Galbraith wrote:
>> On Sat, 2015-12-19 at 19:13 -0700, Jeff Merkey wrote:
>>
>>> @@ -519,6 +528,18 @@ static int hw_breakpoint_handler(struct die_args
>>> *args)
>>> (dr6 & (~DR
On 12/19/15, Mike Galbraith wrote:
> On Sat, 2015-12-19 at 19:13 -0700, Jeff Merkey wrote:
>
>> @@ -519,6 +528,18 @@ static int hw_breakpoint_handler(struct die_args
>> *args)
>> (dr6 & (~DR_TRAP_BITS)))
>> rc = NOTIFY_DONE;
>>
>&g
itching" to function
correctly.
Signed-off-by: Jeff Merkey
---
arch/x86/include/uapi/asm/debugreg.h | 1 +
arch/x86/kernel/hw_breakpoint.c | 25 +++--
2 files changed, 24 insertions(+), 2 deletions(-)
diff --git a/arch/x86/include/uapi/asm/debugreg.h
b/arch/x86
I cleaned up the areas you identified and I am building and testing
the the patch
with the debugger test harness. As soon as it passes the build completes and
it passes the test harness I will submit v4 of the patch.
Jeff
On 12/19/15, Thomas Gleixner wrote:
> On Mon, 14 Dec 2015, Jeff Mer
On 12/19/15, Thomas Gleixner wrote:
> On Mon, 14 Dec 2015, Jeff Merkey wrote:
>> +/*
>> +* check if we got an execute breakpoint
>> +* from the dr7 register. if we did, set
>> +* the resume flag to avoid int1 recursion.
On 12/17/15, Jeff Merkey wrote:
> On 12/16/15, Jeff Merkey wrote:
>> On 12/16/15, Andy Lutomirski wrote:
>>> On Wed, Dec 16, 2015 at 4:31 PM, Jeff Merkey
>>> wrote:
>>>> On 12/16/15, Andy Lutomirski wrote:
>>>>> On Dec 16, 2015 3:12 PM,
Propose complete review of Linux architecture and use of swapgs
instruction to enable kgdb, kdb, mdb, kprobes, and other debugging
tools to operate correctly.
Linux currently does not support the above listed tools due to an
architectural limitation in the way Linux deals with
userspace/kernelspac
On 12/16/15, Jeff Merkey wrote:
> On 12/16/15, Andy Lutomirski wrote:
>> On Wed, Dec 16, 2015 at 4:31 PM, Jeff Merkey wrote:
>>> On 12/16/15, Andy Lutomirski wrote:
>>>> On Dec 16, 2015 3:12 PM, "Jeff Merkey" wrote:
>>>>>
>>>
On 12/16/15, Jeff Merkey wrote:
> Setting the (trap flag | resume flag) inside of an nmi handler results
> in a hard lockup while setting the resume flag works fine.
>
> The watchdog detector fails to detect the lockup. I am currently
> examining the trap gate and interrupt gate
On 12/16/15, Andy Lutomirski wrote:
> On Wed, Dec 16, 2015 at 4:31 PM, Jeff Merkey wrote:
>> On 12/16/15, Andy Lutomirski wrote:
>>> On Dec 16, 2015 3:12 PM, "Jeff Merkey" wrote:
>>>>
>>>> Setting a hardware breakpoint at the
>&g
On 12/16/15, Jeff Merkey wrote:
> On 12/16/15, Andy Lutomirski wrote:
>> On Dec 16, 2015 3:12 PM, "Jeff Merkey" wrote:
>>>
>>> Setting a hardware breakpoint at the
>>>
>>> rex64 sysret
>>>
>>> instruction at the end of i
On 12/16/15, Andy Lutomirski wrote:
> On Dec 16, 2015 3:12 PM, "Jeff Merkey" wrote:
>>
>> Setting a hardware breakpoint at the
>>
>> rex64 sysret
>>
>> instruction at the end of int_ret_from_sys_call causes the system to
>> triple fault
>
Setting a hardware breakpoint at the
rex64 sysret
instruction at the end of int_ret_from_sys_call causes the system to
triple fault
and reboot when the breakpoint is triggered. Appears to be related
the same problem
as the lockup.
This function can be stepped over and traced through with the TR
On 12/16/15, Jeff Merkey wrote:
> On 12/16/15, Jeff Merkey wrote:
>> Setting the (trap flag | resume flag) inside of an nmi handler results
>> in a hard lockup while setting the resume flag works fine.
>>
>> The watchdog detector fails to detect the lockup. I am curr
triggered with an NMI, then someone reloads the
processor with the trap flag set then returns to a hlt instruction.
Wow, this fucking cool .. I can debug Linus' "I halt when idle" core
function in the linux scheduler.
On 12/16/15, Jeff Merkey wrote:
> On 12/16/15,
On 12/16/15, Jeff Merkey wrote:
> Setting the (trap flag | resume flag) inside of an nmi handler results
> in a hard lockup while setting the resume flag works fine.
>
> The watchdog detector fails to detect the lockup. I am currently
> examining the trap gate and interrupt gate
Setting the (trap flag | resume flag) inside of an nmi handler results
in a hard lockup while setting the resume flag works fine.
The watchdog detector fails to detect the lockup. I am currently
examining the trap gate and interrupt gate setup on Linux and if
anyone has any ideas it would be nice
On 12/16/15, Jeff Merkey wrote:
> On 12/14/15, Jeff Merkey wrote:
>> The current touch_nmi_watchdog() function in /kernel/watchdog.c does
>> not always catch all cases when a processor is spinning in the nmi
>> handler inside either KGDB, KDB, or MDB, in particular, the case
On 12/14/15, Jeff Merkey wrote:
> The current touch_nmi_watchdog() function in /kernel/watchdog.c does
> not always catch all cases when a processor is spinning in the nmi
> handler inside either KGDB, KDB, or MDB, in particular, the case where
> a processor is being held by a debugg
On 12/14/15, Jeff Merkey wrote:
> The current touch_nmi_watchdog() function in /kernel/watchdog.c does
> not always catch all cases when a processor is spinning in the nmi
> handler inside either KGDB, KDB, or MDB, in particular, the case where
> a processor is being held by a debugg
;lazy debug register
switching" with null bp handlers to test the
robustness of the handlers.
3. Clearing and setting breakpoints across multiple processors then
triggering concurrent exceptions in both interrupt and process
contexts.
Signed-off-by: Jeff Merkey
---
arch/x86/kernel/hw_breakpoint.
Please let me know if there is anything else that needs to be added to
this patch.
--
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://vger.kernel.org/majordomo-info.html
Please read the FAQ
> kgdb/kdb and the perf event system both present garbage status in dr6
> then subsequently write this status into the thread.debugreg6 variable,
> then in some cases call hw_breakpoint_restore() which writes this
> status back into the dr6 hardware register.
>
I wanted to note here that this is t
itching" to function
correctly.
Signed-off-by: Jeff Merkey
---
arch/x86/kernel/hw_breakpoint.c | 25 +++--
1 file changed, 23 insertions(+), 2 deletions(-)
diff --git a/arch/x86/kernel/hw_breakpoint.c b/arch/x86/kernel/hw_breakpoint.c
index 50a3fad..ca13db0 100644
--- a/ar
On 12/14/15, H. Peter Anvin wrote:
> On December 14, 2015 4:49:51 PM PST, Jeff Merkey
> wrote:
>>On 12/14/15, Jeff Merkey wrote:
>>> Please consider the attached patch.
>>>
>>> SUMMARY
>>>
>>> This patch corrects a hard lockup failure of
issues since the function is widely used by drivers and
modules.
I have tested this patch and it fixes the problem for kernel debuggers
stopping errant hard lockup events when processors are spinning inside
the debugger.
Signed-off-by: Jeff Merkey
---
kernel/watchdog.c | 7 +++
1 file changed
On 12/14/15, Jeff Merkey wrote:
> On 12/14/15, Don Zickus wrote:
>> On Sat, Dec 12, 2015 at 02:08:13PM -0700, Jeff Merkey wrote:
>>> The current touch_nmi_watchdog() function in /kernel/watchdog.c does
>>> not always catch all cases when a processor is spinning in
On 12/14/15, Don Zickus wrote:
> On Sat, Dec 12, 2015 at 02:08:13PM -0700, Jeff Merkey wrote:
>> The current touch_nmi_watchdog() function in /kernel/watchdog.c does
>> not always catch all cases when a processor is spinning in the nmi
>> handler inside either KG
On 12/14/15, Jeff Merkey wrote:
> Please consider the attached patch.
>
> SUMMARY
>
> This patch corrects a hard lockup failure of the system kernel if the
> operating system receives a breakpoint exception at a code execution
> address which was not registered with the o
iables.
3. Actually allows "lazy debug register switching" to function
correctly.
Signed-off-by: Jeff Merkey
---
arch/x86/kernel/hw_breakpoint.c | 25 +++--
1 file changed, 23 insertions(+), 2 deletions(-)
diff --git a/arch/x86/kernel/hw_breakpoint.c b/arch/x86/kernel/h
On 12/14/15, H. Peter Anvin wrote:
> On 12/14/15 13:03, Jeff Merkey wrote:
>> Please consider the attached patch.
>>
>> I have reviewed all the code that touches this patch and have
>> determined it will function and support all of the software that
>> depends
n the int1 source from its own state and
variables.
3. Actually allows "lazy debug register switching" to function, which
until recently has apparently never been actually seen on live
hardware or actually tested.
Signed-off-by: Jeff Merkey
---
arch/x86/kernel/
n the int1 source from its own state and
variables.
3. Actually allows "lazy debug register switching" to function, which
until recently has apparently never been actually seen on live
hardware or actually tested.
Signed-off-by: Jeff Merkey
---
arch/x86/kernel/
On 12/14/15, Andy Lutomirski wrote:
> On Mon, Dec 14, 2015 at 9:52 AM, Jeff Merkey wrote:
>> On 12/14/15, Ingo Molnar wrote:
>>>
>>> * Jeff Merkey wrote:
>>>
>>>> On 12/14/15, Ingo Molnar wrote:
>>>> >
>>>> > A: Be
On 12/14/15, Andy Lutomirski wrote:
> On Mon, Dec 14, 2015 at 9:52 AM, Jeff Merkey wrote:
>> On 12/14/15, Ingo Molnar wrote:
>>>
>>> * Jeff Merkey wrote:
>>>
>>>> On 12/14/15, Ingo Molnar wrote:
>>>> >
>>>> > A: Be
On 12/14/15, Ingo Molnar wrote:
>
> * Jeff Merkey wrote:
>
>> On 12/14/15, Ingo Molnar wrote:
>> >
>> > A: Because it messes up the order in which people normally read text.
>> > Q: Why is top-posting such a bad thing?
>> > A: Top-posting
Passed all tests. Stable, looks good, runs fast. No warn messages.
All Debugging and file system tests passed.
--
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://vger.kernel.org/majordomo-
On 12/14/15, Jeff Merkey wrote:
> On 12/14/15, Ingo Molnar wrote:
>>
>> A: Because it messes up the order in which people normally read text.
>> Q: Why is top-posting such a bad thing?
>> A: Top-posting.
>> Q: What is the most annoying thing in e-mail?
>
1 - 100 of 123 matches
Mail list logo
