On 03/26/2015 12:29 PM, John Stultz wrote:
> On Thu, Mar 26, 2015 at 4:31 AM, Prarit Bhargava wrote:
>> On 03/25/2015 07:44 PM, John Stultz wrote:
>>> + printf("%-22s %s missing CAP_WAKE_ALARM?:
>>> [UNSUPPORTED]\n",
>>> +
lf.
>
> Before: 11m48.629s
> After:6m47.723s
>
> Cc: Shuah Khan
> Cc: Prarit Bhargava
> Cc: Thomas Gleixner
> Cc: Richard Cochran
> Signed-off-by: John Stultz
> Signed-off-by: John Stultz
> ---
> tools/testing/selftests/timers/inconsistency-check.c
re clearly and continue rather then reporting a failure.
>
> Cc: Shuah Khan
> Cc: Prarit Bhargava
> Cc: Thomas Gleixner
> Cc: Richard Cochran
> Signed-off-by: John Stultz
> Signed-off-by: John Stultz
> ---
> tools/testing/selftests/timers/set-timer-lat.c | 7 +++
file is that the location of the rtctest.c file has changed.
Signed-off-by: Prarit Bhargava
Cc: cor...@lwn.net
Cc: rtc-li...@googlegroups.com
Cc: linux-...@vger.kernel.org
Cc: a.zu...@towertech.it
Cc: pra...@redhat.com
Cc: john.stu...@linaro.org
Cc: shua...@osg.samsung.com
[v2]: rebase
[v3]: rebase
On 03/19/2015 05:36 PM, Shuah Khan wrote:
> On 03/19/2015 02:27 PM, Shuah Khan wrote:
>> On 03/19/2015 02:25 PM, Jonathan Corbet wrote:
>>> On Thu, 19 Mar 2015 12:24:41 -0600
>>> Shuah Khan wrote:
>>>
Hi Jon,
Would you like to review the change and Ack it, so I can
take the c
than expected.
This patch introduces a simple check to verify if the time passed is
less than 10% of what was programmed into the RTC.
Signed-off-by: Prarit Bhargava
Cc: cor...@lwn.net
Cc: rtc-li...@googlegroups.com
Cc: linux-...@vger.kernel.org
Cc: a.zu...@towertech.it
Cc: pra...@redhat.com
Cc
patchset was built on
git://git.kernel.org/pub/scm/linux/kernel/git/shuah/linux-kselftest.git next
in order to get jstultz' latest tools/testing/selftests/timers/ changes.
Signed-off-by: Prarit Bhargava
Cc: cor...@lwn.net
Cc: rtc-li...@googlegroups.com
Cc: linux-...@vger.kernel.org
Cc:
file is that the location of the rtctest.c file has changed.
Signed-off-by: Prarit Bhargava
Cc: cor...@lwn.net
Cc: rtc-li...@googlegroups.com
Cc: linux-...@vger.kernel.org
Cc: a.zu...@towertech.it
Cc: pra...@redhat.com
Cc: john.stu...@linaro.org
Cc: shua...@osg.samsung.com
---
Documentation/rtc.txt
On 03/16/2015 01:10 PM, Jonathan Corbet wrote:
> On Mon, 16 Mar 2015 11:58:53 -0400
> Prarit Bhargava wrote:
>
>> Documentation/rtc.txt is a combination of two files, a real documentation
>> file and a test program. Splitting these up into two files is a good idea
>
Add a Documentation/rtc directory and split rtc.txt into two separate
files, one for the documentation itself, and the other for the rtctest.c
file.
Signed-off-by: Prarit Bhargava
---
Documentation/rtc.txt | 469 ---
Documentation/rtc/rtc.txt
-by: Prarit Bhargava
Prarit Bhargava (2):
Documentation, add rtc directory and split up rtc.txt
Documentation, update rtctest.c to verify passage of time
Documentation/rtc.txt | 469 ---
Documentation/rtc/rtc.txt | 207
than expected.
This patch introduces a simple check to verify if the time passed is
less than 10% of what was programmed into the RTC.
Also make a simple one line change to rtc.txt to point to the right test
program.
Signed-off-by: Prarit Bhargava
---
Documentation/rtc/rtc.txt |2
e machine).
> The destructive tests are run (as root, or with proper
> privledge) via:
> # make run_destructive_tests
I ran these across several systems including s390, powerpc, and x86 (64 bit
only). I didn't see anything weird and AFAICT the tests work.
Tested-by: Prarit Bh
On 03/02/2015 11:32 AM, Borislav Petkov wrote:
> On Mon, Mar 02, 2015 at 11:33:33PM +0900, Naoya Horiguchi wrote:
>> Yes, CPU offlining is one option to keep other CPUs quiet. I'm not sure why
>> current kexec implementation doesn't offline the other CPUs but just doing
>> cpu_relax() loop, but m
On 02/27/2015 07:46 AM, Naoya Horiguchi wrote:
> Hi Prarit,
>
> On Fri, Feb 27, 2015 at 06:09:52AM -0500, Prarit Bhargava wrote:
> ...
>> > @@ -157,6 +160,11 @@ void native_machine_crash_shutdown(struct pt_regs
>> > *regs)
>> > /* The
On 02/26/2015 11:58 PM, Naoya Horiguchi wrote:
> kexec disables (or "shoots down") all CPUs other than a crashing CPU before
> entering the 2nd kernel. But the MCE handler is still enabled after that, so
> if MCE happens and broadcasts around CPUs after the main thread starts the
> 2nd kernel (wh
On 02/19/2015 12:00 PM, Jiri Bohac wrote:
> Hi,
>
> I'm trying to understand what exactly is going on here...
>
> On Thu, Feb 12, 2015 at 08:58:19AM -0500, Prarit Bhargava wrote:
>> The test did the following in userspace:
>>
>> tx.modes = ADJ_
On 02/17/2015 06:16 PM, John Stultz wrote:
> On Thu, Feb 12, 2015 at 5:58 AM, Prarit Bhargava wrote:
>>
>> which was intended to mimic the insertion of a leap second. A
>> successful run of the test would result in the time_state transitioning
>> from TIME_OK to
rogress) do not
allow an external update to time_state in process_adj_status(). This will
prevent external adjtimex() calls from breaking the leap second state
machine.
[v2]: Only block time_state change when TIME_OOP
[v3]: Write a much more detailed explanation of the bug.
Signed-off-by: Prarit Bhargav
On 02/10/2015 06:47 PM, John Stultz wrote:
> On Sun, Feb 8, 2015 at 2:29 AM, Prarit Bhargava wrote:
>> During leap second insertion testing it was noticed that a small window
>> exists where the time_state could be reset such that
>> time_state = TIME_OK, which then caus
: Prarit Bhargava
Cc: John Stultz
Cc: Thomas Gleixner
Cc: Miroslav Lichvar
---
kernel/time/ntp.c |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/kernel/time/ntp.c b/kernel/time/ntp.c
index 28bf91c..6ff5cd5 100644
--- a/kernel/time/ntp.c
+++ b/kernel/time/ntp.c
@@ -535,7 +535,8
On 02/06/2015 05:38 AM, Miroslav Lichvar wrote:
> On Thu, Feb 05, 2015 at 08:20:08AM -0500, Prarit Bhargava wrote:
>> On 02/04/2015 11:30 AM, Miroslav Lichvar wrote:
>>> If after that, adjtimex() will return with TIME_ERROR as expected, or
>>> not?
>>
>>
On 02/04/2015 11:30 AM, Miroslav Lichvar wrote:
> Prarit Bhargava wrote:
>> While this is highly unlikely to ever happen in the real world it is
>> still something we should protect against, as breaking the state machine
>> is obviously bad.
>
> I'm not sure what
is highly unlikely to ever happen in the real world it is
still something we should protect against, as breaking the state machine
is obviously bad.
If the time_state == TIME_OOP (ie, the leap second is in progress) do not
allow an external update to time_state.
Signed-off-by: Prarit Bhargava
in the real world it is
still something we should protect against, as breaking the state machine
is obviously bad.
If the time_state == TIME_OOP (ie, the leap second is in progress) do not
allow an external update to time_state.
Signed-off-by: Prarit Bhargava
---
kernel/time/ntp.c |3 ++-
1
On 01/21/2015 07:51 PM, John Stultz wrote:
> On Fri, Jan 9, 2015 at 6:02 PM, Stephen Boyd wrote:
>> On 01/09/2015 04:34 PM, John Stultz wrote:
>>> diff --git a/kernel/time/clocksource.c b/kernel/time/clocksource.c
>>> index 9a0b951..c641aa7 100644
>>> --- a/kernel/time/clocksource.c
>>> +++ b/ke
On 01/20/2015 01:05 PM, Oleg Nesterov wrote:
> On 01/20, Prarit Bhargava wrote:
>>
>> On 01/19/2015 08:05 PM, Rusty Russell wrote:
>>> Oleg Nesterov writes:
>>>>
>>>> If we want to optimize this... I am wondering if we can change
>>&
On 01/19/2015 08:05 PM, Rusty Russell wrote:
> Oleg Nesterov writes:
>> On 01/17, Rasmus Villemoes wrote:
>>>
>>> Using kasprintf to get the function name makes us look up the name
>>> twice, along with all the vsnprintf overhead of parsing the format
>>> string etc. It also means there is an al
f sha1>
> ("")'
> and if the git commit sha1 is unique, show
> the right sha1 to use with the actual title
>
> Signed-off-by: Joe Perches
> Original-patch-by: Prarit Bhargava
> ---
Acked-by: Prarit Bhargava
P.
--
To unsubscribe from this list: send th
On 01/08/2015 09:16 AM, Nicholas Mc Guire wrote:
> wait_for_completion_timeout reaching timeout was being ignored,
> fail the self-test if timeout condition occurs.
>
> v2: fixup of coding style issues.
>
> Signed-off-by: Nicholas Mc Guire
Reviewed-by: Prarit Bhargava
P.
On 01/06/2015 10:38 AM, Jiang, Dave wrote:
- if (dma->device_tx_status(dma_chan, cookie, NULL) != DMA_COMPLETE) {
+ if (tmo == 0 || dma->device_tx_status(dma_chan, cookie, NULL)
+ != DMA_COMPLETE) {
>>>
>>> Can you please do:
>>> + if (tmo == 0 ||
>>> +
> x86_64_defconfig + CONFIG_DMA_ENGINE=y + CONFIG_INTEL_IOATDMA=y
>
> patch is against linux-next 3.19.0-rc1 -next-20141226
>
Seems straightforward to me, although I don't think I've ever seen a failure in
this code.
Acked-by: Prarit Bhargava
P.
> Signed-off-by: Nicholas M
On 12/23/2014 12:52 PM, Nicholas Mc Guire wrote:
> The successive init_completion calls should be reinit_completion here.
>
Hi Nicholas,
I know enough about this code to break it ;) ... what condition did you hit that
led you to this patch?
P.
> patch is against 3.18.0 linux-next
>
> Signed
27;bout that Thomas. I should have caught that the the first time.
Cc: Thomas Renninger
Cc: Rafael J. Wysocki
Signed-off-by: Prarit Bhargava
Prarit Bhargava (2):
Revert "tools: cpupower: fix return checks for
sysfs_get_idlestate_count()"
Fix no idle state information return va
er
Cc: Rafael J. Wysocki
Signed-off-by: Prarit Bhargava
---
tools/power/cpupower/utils/cpuidle-info.c |8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/tools/power/cpupower/utils/cpuidle-info.c
b/tools/power/cpupower/utils/cpuidle-info.c
index 458d69b..75e66de 100644
-
sysfs_get_idlestate_count() returns an unsigned int. Returning -ENODEV
is not the right thing to do here, and in any case is handled the same
way as if there are no states found.
Cc: Thomas Renninger
Cc: Rafael J. Wysocki
Signed-off-by: Prarit Bhargava
---
tools/power/cpupower/utils/helpers
). The function can return -ENODEV (-19) as
above. This patch fixes callers to sysfs_get_idlestate_count() to check
the right return values.
Cc: Thomas Renninger
Cc: linux...@vger.kernel.org
Signed-off-by: Prarit Bhargava
---
tools/power/cpupower/utils/cpuidle-info.c |8
1 fi
On 11/17/2014 06:42 PM, Bjorn Helgaas wrote:
> On Mon, Nov 10, 2014 at 8:59 PM, Bjorn Helgaas wrote:
>> [+cc lkml, linux-arch, Linus]
>>
>> On Sat, Nov 01, 2014 at 02:11:19PM -0400, Prarit Bhargava wrote:
>>> The kernel should boot PCI without the use of kernel par
On 11/12/2014 04:43 AM, Vinod Koul wrote:
> On Thu, Oct 23, 2014 at 06:36:58AM -0700, Dan Williams wrote:
>> On Thu, Oct 23, 2014 at 4:38 AM, Prarit Bhargava wrote:
>>> No response from anyone the first time ...
>>>
>>
>> Sorry about that, thanks for r
.@redhat.com
Cc: isimatu.yasu...@jp.fujitsu.com
Cc: jba...@akamai.com
Cc: linux-...@vger.kernel.org
Cc: ke...@lists.infradead.org
Cc: linux-...@vger.kernel.org
Signed-off-by: Prarit Bhargava
[v2]: add /proc/sys/kernel/panic_on_warn, additional documentation, modify
!slowpath
On 11/10/2014 11:23 PM, Viresh Kumar wrote:
> On 5 November 2014 20:23, Prarit Bhargava wrote:
>> diff --git a/drivers/cpufreq/cpufreq_governor.c
>> b/drivers/cpufreq/cpufreq_governor.c
>> index b1ee597..f158882 100644
>> --- a/drivers/cpufreq/cpufreq_governor
On 11/10/2014 10:37 PM, Viresh Kumar wrote:
> On 10 November 2014 17:56, Prarit Bhargava wrote:
>
>>> I still fail to understand why ? What will the _trylock() change ?
>>
>> viresh, afaict read_trylock will return 0 when busy with write:
>
> Yes..
>
>
On 11/10/2014 05:44 AM, Viresh Kumar wrote:
> On 5 November 2014 20:23, Prarit Bhargava wrote:
>> commit 955ef4833574636819cd269cfbae12f79cbde63a (" cpufreq: Drop rwsem
>> lock around CPUFREQ_GOV_POLICY_EXIT") opens up a hole in the locking
>> scheme for cpuf
On 11/08/2014 04:46 PM, Rafael J. Wysocki wrote:
> On Saturday, November 08, 2014 08:33:35 AM Prarit Bhargava wrote:
>>
>> On 11/07/2014 09:00 PM, Rafael J. Wysocki wrote:
>>> On Wednesday, November 05, 2014 09:53:59 AM Prarit Bhargava wrote:
>>>> Add some add
On 11/07/2014 09:00 PM, Rafael J. Wysocki wrote:
> On Wednesday, November 05, 2014 09:53:59 AM Prarit Bhargava wrote:
>> Add some additional debug to capture failures in the locking scheme for
>> cpufreq. Instead of just a NULL pointer, these warnings will capture failure
&
On 11/07/2014 04:09 PM, David Rientjes wrote:
> On Fri, 7 Nov 2014, Prarit Bhargava wrote:
>
>> There very much is. Consider a thread that hits a WARN() and then panics.
>> Then
>> somewhere in the panic code the thread hits another WARN() ... and then
>> pan
On 11/07/2014 05:15 AM, David Rientjes wrote:
> On Thu, 6 Nov 2014, Vivek Goyal wrote:
>
>> On Thu, Nov 06, 2014 at 01:57:36PM -0800, David Rientjes wrote:
>>
>> [..]
>>> You see that doing
>>>
>>> if (panic_on_warn) {
>>> panic_on_warn = 0;
>>> panic(...);
>>> }
On 11/06/2014 04:57 PM, David Rientjes wrote:
> On Thu, 6 Nov 2014, Prarit Bhargava wrote:
>
>>>> diff --git a/Documentation/kdump/kdump.txt b/Documentation/kdump/kdump.txt
>>>> index 6c0b9f2..bc4bd5a 100644
>>>> --- a/Documentation/kdump/kdump.tx
On 11/06/2014 05:07 PM, Vivek Goyal wrote:
> On Thu, Nov 06, 2014 at 01:57:36PM -0800, David Rientjes wrote:
>
> [..]
>> You see that doing
>>
>> if (panic_on_warn) {
>> panic_on_warn = 0;
>> panic(...);
>> }
>>
>> is racy, I hope. If two threads WARN() at th
On 11/05/2014 04:59 PM, David Rientjes wrote:
> On Wed, 5 Nov 2014, Prarit Bhargava wrote:
>
>> diff --git a/Documentation/kdump/kdump.txt b/Documentation/kdump/kdump.txt
>> index 6c0b9f2..bc4bd5a 100644
>> --- a/Documentation/kdump/kdump.txt
>> +++ b/Documentatio
socki"
Cc: Viresh Kumar
Cc: linux...@vger.kernel.org
Signed-off-by: Prarit Bhargava
---
drivers/cpufreq/cpufreq.c |4
include/linux/cpufreq.h |4
2 files changed, 8 deletions(-)
diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
index 3f09ca9..e33
Add some additional debug to capture failures in the locking scheme for
cpufreq. Instead of just a NULL pointer, these warnings will capture failure
points if the locking scheme for cpufreq is broken.
Cc: "Rafael J. Wysocki"
Cc: Viresh Kumar
Cc: linux...@vger.kernel.org
Signed-off-
mutex to
make sure that future read/writes obtain the correct data.
Cc: "Rafael J. Wysocki"
Cc: Viresh Kumar
Cc: linux...@vger.kernel.org
Signed-off-by: Prarit Bhargava
---
drivers/cpufreq/cpufreq.c | 12 +---
drivers/cpufreq/cpufreq_governor.c |4 ++--
include
that future read/writes obtain the correct data.
Cc: "Rafael J. Wysocki"
Cc: Viresh Kumar
Cc: linux...@vger.kernel.org
Signed-off-by: Prarit Bhargava
---
drivers/cpufreq/cpufreq_governor.c | 16
drivers/cpufreq/cpufreq_governor.h |3 ++-
2 files changed, 14
USY when the governor is being written.
Changing the down_read(&policy->rwsem) to a trylock fixes this stale data
issue.
Cc: "Rafael J. Wysocki"
Cc: Viresh Kumar
Cc: linux...@vger.kernel.org
Signed-off-by: Prarit Bhargava
---
drivers/cpufreq/cpufreq.c |3 ++-
1 file changed
of the bugs I'm
exposing. I'm chasing what appears to be a "new" bug with Robert's test.
Additionally, with my changes in place it takes much longer to hit panics
in the code so I'm going to move forward and push these five patches.
Prarit Bhargava (5):
cpufreq,
.@redhat.com
Cc: isimatu.yasu...@jp.fujitsu.com
Cc: jba...@akamai.com
Cc: linux-...@vger.kernel.org
Cc: ke...@lists.infradead.org
Cc: linux-...@vger.kernel.org
Signed-off-by: Prarit Bhargava
[v2]: add /proc/sys/kernel/panic_on_warn, additional documentation, modify
!slowpath
.@redhat.com
Cc: isimatu.yasu...@jp.fujitsu.com
Cc: jba...@akamai.com
Cc: linux-...@vger.kernel.org
Cc: ke...@lists.infradead.org
Cc: linux-...@vger.kernel.org
Signed-off-by: Prarit Bhargava
[v2]: add /proc/sys/kernel/panic_on_warn, additional documentation, modify
!slowpath
.@redhat.com
Cc: isimatu.yasu...@jp.fujitsu.com
Cc: jba...@akamai.com
Cc: h...@sgi.com
Cc: linux-...@vger.kernel.org
Cc: ke...@lists.infradead.org
Cc: linux-...@vger.kernel.org
Signed-off-by: Prarit Bhargava
[v2]: add /proc/sys/kernel/panic_on_warn, additional documentation, modify
!slowpath
On 10/30/2014 08:25 PM, Rusty Russell wrote:
> Prarit Bhargava writes:
>> On 10/22/2014 12:27 AM, Rusty Russell wrote:
>>> Prarit Bhargava writes:
>>>> There have been several times where I have had to rebuild a kernel to
>>>> cause a panic when hitt
On 10/30/2014 09:58 PM, Hedi Berriche wrote:
> On Thu, Oct 30, 2014 at 17:06 Prarit Bhargava wrote:
> | There have been several times where I have had to rebuild a kernel to
> | cause a panic when hitting a WARN() in the code in order to get a crash
> | dump from a system. Somet
.@redhat.com
Cc: isimatu.yasu...@jp.fujitsu.com
Cc: jba...@akamai.com
Cc: linux-...@vger.kernel.org
Cc: ke...@lists.infradead.org
Cc: linux-...@vger.kernel.org
Signed-off-by: Prarit Bhargava
[v2]: add /proc/sys/kernel/panic_on_warn, additional documentation, modify
!slowpath
On 10/28/2014 08:56 AM, Andi Kleen wrote:
>>> If you have a command line option to execute kdb commands you still
>>> would only have a command line option, just a slightly longer one.
>>>
>>> kdb="on, bp warn_slowpath_common sr c, go"
>>
>> KDB is not on all kernels. This would require me to g
On 10/28/2014 08:44 AM, Andi Kleen wrote:
>>> I suppose ... but that would mean I would have to explain to an end user the
>>> elaborate process of enabling kdb, inserting a break point, etc. The whole
>>> purpose of this is to let an end user panic on WARN() easily.
>>>
>>> Asking an end user t
.@redhat.com
Cc: isimatu.yasu...@jp.fujitsu.com
Cc: jba...@akamai.com
Cc: linux-...@vger.kernel.org
Cc: ke...@lists.infradead.org
Cc: linux-...@vger.kernel.org
Signed-off-by: Prarit Bhargava
[v2]: add /proc/sys/kernel/panic_on_warn, additional documentation, modify
!slowpath
On 10/28/2014 08:16 AM, Andi Kleen wrote:
> On Fri, Oct 24, 2014 at 08:53:27AM -0400, Prarit Bhargava wrote:
>> There have been several times where I have had to rebuild a kernel to
>> cause a panic when hitting a WARN() in the code in order to get a crash
>> dump from a sy
On 10/27/2014 02:05 PM, Jason Baron wrote:
> Hi Prarit,
>
> On 10/24/2014 08:53 AM, Prarit Bhargava wrote:
>> There have been several times where I have had to rebuild a kernel to
>> cause a panic when hitting a WARN() in the code in order to get a crash
>> dump fro
x-...@vger.kernel.org
Signed-off-by: Prarit Bhargava
[v2]: add /proc/sys/kernel/bug_on_warn, additional documentation, modify
!slowpath cases
[v3]: use proc_dointvec_minmax() in sysctl handler
[v4]: remove !slowpath cases, and add __read_mostly
---
Documentation/kdump/kdump.txt |7 +
On 10/23/2014 03:40 PM, Andrew Morton wrote:
> On Thu, 23 Oct 2014 08:53:14 -0400 Prarit Bhargava wrote:
>
>> There have been several times where I have had to rebuild a kernel to
>> cause a panic when hitting a WARN() in the code in order to get a crash
>> dump from a
c: Jonathan Corbet
Cc: Andrew Morton
Cc: Rusty Russell
Cc: "H. Peter Anvin"
Cc: Andi Kleen
Cc: Masami Hiramatsu
Cc: Fabian Frederick
Cc: vgo...@redhat.com
Cc: isimatu.yasu...@jp.fujitsu.com
Cc: linux-...@vger.kernel.org
Cc: ke...@lists.infradead.org
Cc: linux-...@vger.kernel.org
ializing the dma_srcs[] array and checking
the returns with dma_mapping_error().
Cc: Dan Williams
Cc: Vinod Koul
Cc: Dave Jiang
Cc: Bartlomiej Zolnierkiewicz
Cc: Kyungmin Park
Cc: dmaeng...@vger.kernel.org
Signed-off-by: Prarit Bhargava
---
drivers/dma/ioat/dma_v3.
On 10/22/2014 08:15 AM, Prarit Bhargava wrote:
>
>
> On 10/10/2014 07:47 PM, Shuah Khan wrote:
>> On Fri, Oct 10, 2014 at 4:55 PM, Prarit Bhargava wrote:
>>> When doing git-status there are two untracked files:
>>>
>>> \# Untracked files:
>>>
On 10/10/2014 07:47 PM, Shuah Khan wrote:
> On Fri, Oct 10, 2014 at 4:55 PM, Prarit Bhargava wrote:
>> When doing git-status there are two untracked files:
>>
>> \# Untracked files:
>> \# (use "git add ..." to include in what will be committed)
>&
On 10/22/2014 12:27 AM, Rusty Russell wrote:
> Prarit Bhargava writes:
>> There have been several times where I have had to rebuild a kernel to
>> cause a panic when hitting a WARN() in the code in order to get a crash
>> dump from a system. Sometimes this is easy to do,
c: Jonathan Corbet
Cc: Andrew Morton
Cc: Rusty Russell
Cc: "H. Peter Anvin"
Cc: Andi Kleen
Cc: Masami Hiramatsu
Cc: Fabian Frederick
Cc: vgo...@redhat.com
Cc: isimatu.yasu...@jp.fujitsu.com
Cc: linux-...@vger.kernel.org
Cc: ke...@lists.infradead.org
Cc: linux-...@vger.kernel.org
nfusing and should
be separated into two warnings, one for the git commit ID length, and the other
for the format.
Cc: Andy Whitcroft
Cc: Joe Perches
Signed-off-by: Prarit Bhargava
[v2]: Add separate messages for warnings instead of one global format
warning.
[v3]: Add check for improperly forma
On 10/20/2014 10:11 PM, Joe Perches wrote:
> On Mon, 2014-10-20 at 20:46 -0400, Prarit Bhargava wrote:
>>
>> On 10/20/2014 07:11 PM, Joe Perches wrote:
>>> On Mon, 2014-10-20 at 18:49 -0400, Prarit Bhargava wrote:
>>>> I tested this using both lower and uppe
On 10/20/2014 06:24 PM, Andrew Morton wrote:
> On Mon, 20 Oct 2014 08:00:20 -0400 Prarit Bhargava wrote:
>
>> There have been several times where I have had to rebuild a kernel to
>> cause a panic when hitting a WARN() in the code in order to get a crash
>> dump from a
On 10/20/2014 07:11 PM, Joe Perches wrote:
> On Mon, 2014-10-20 at 18:49 -0400, Prarit Bhargava wrote:
>> I tested this using both lower and upper case 'c' with the following commit
>> text:
> []
>
> I think the patch subject be something like:
>
> &qu
Move cycle_last validation to core code")'
Commit 09ec54429c6d10f87d1f084de53ae2c1c3a81108, clocksource: Move
As can be seen by the output the commit ID length is accurate, and it is the
formatting that is generating an error. The message is confusing and should
be separated into two wa
ned-off-by: Prarit Bhargava
---
Documentation/kernel-parameters.txt |2 ++
kernel/panic.c | 16 +++-
2 files changed, 17 insertions(+), 1 deletion(-)
diff --git a/Documentation/kernel-parameters.txt
b/Documentation/kernel-parameters.txt
index 7dbe5ec..2967
On 10/17/2014 02:27 PM, John Stultz wrote:
> On Fri, Oct 17, 2014 at 11:23 AM, Prarit Bhargava wrote:
>>
>>
>> On 10/17/2014 02:17 PM, John Stultz wrote:
>>> On Fri, Oct 17, 2014 at 6:57 AM, Prarit Bhargava wrote:
>>>> A bug report came in against a
On 10/17/2014 02:17 PM, John Stultz wrote:
> On Fri, Oct 17, 2014 at 6:57 AM, Prarit Bhargava wrote:
>> A bug report came in against an older kernel which output "backward time"
>> messages and the report noted that the upstream kernel worked. After some
>> inves
On 10/17/2014 09:57 AM, Prarit Bhargava wrote:
> A bug report came in against an older kernel which output "backward time"
> messages and the report noted that the upstream kernel worked. After some
> investigation it turned out that one of the sockets was bad on the system
084de53ae2c1c3a81108, clocksource: Move
The message is confusing. Change it to request that the author use the
example commit ID format.
Cc: Andy Whitcroft
Cc: Joe Perches
Signed-off-by: Prarit Bhargava
---
scripts/checkpatch.pl |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
e evaluated.
I tested this by booting on the broken hardware and left the system idle
until a negative clocksource_delta() event occurred.
Cc: John Stultz
Cc: Thomas Gleixner
Signed-off-by: Prarit Bhargava
---
kernel/time/timekeeping_internal.h |7 ++-
1 file changed, 6 insertions(+), 1 de
On 10/17/2014 07:38 AM, Viresh Kumar wrote:
> On 13 October 2014 18:41, Prarit Bhargava wrote:
>> There are several issues with the current locking design of cpufreq. Most
>> notably is the panic reported here:
>>
>> http://marc.info/?l=linux-kernel&m=1406
On 10/16/2014 07:23 AM, Viresh Kumar wrote:
> On 14 October 2014 23:54, Prarit Bhargava wrote:
>> Here's what I think we should do. Taking a step back, the purpose of the
>> cpufreq sysfs files is to allow userspace to read current cpu frequency
>> settings, and to al
On 10/16/2014 03:45 PM, Myron Stowe wrote:
> On Thu, 2014-10-16 at 08:32 -0400, Prarit Bhargava wrote:
>>
>> On 10/15/2014 05:20 PM, Bjorn Helgaas wrote:
>>> On Wed, Oct 15, 2014 at 1:47 PM, Prarit Bhargava wrote:
>>>> On 10/15/2014 03:23 PM, Bjorn Helgaas wr
On 10/16/2014 10:44 AM, Alexander Duyck wrote:
>
> On 10/16/2014 05:32 AM, Prarit Bhargava wrote:
>> On 10/15/2014 05:20 PM, Bjorn Helgaas wrote:
>>> On Wed, Oct 15, 2014 at 1:47 PM, Prarit Bhargava wrote:
>>>> On 10/15/2014 03:23 PM, Bjorn Helgaas wrote:
>>
On 10/15/2014 05:20 PM, Bjorn Helgaas wrote:
> On Wed, Oct 15, 2014 at 1:47 PM, Prarit Bhargava wrote:
>> On 10/15/2014 03:23 PM, Bjorn Helgaas wrote:
>>> Hi Prarit,
>>>
>>> On Wed, Oct 15, 2014 at 1:05 PM, Prarit Bhargava wrote:
>>>> Consid
On 10/15/2014 03:47 PM, Prarit Bhargava wrote:
> On 10/15/2014 03:23 PM, Bjorn Helgaas wrote:
>> Hi Prarit,
>>
>> On Wed, Oct 15, 2014 at 1:05 PM, Prarit Bhargava wrote:
>>> Consider a multi-node, multiple pci root bridge system which can be
>>> configured
On 10/15/2014 03:23 PM, Bjorn Helgaas wrote:
> Hi Prarit,
>
> On Wed, Oct 15, 2014 at 1:05 PM, Prarit Bhargava wrote:
>> Consider a multi-node, multiple pci root bridge system which can be
>> configured into one large node or one node/socket. When configuring the
>>
as
Cc: linux-...@vger.kernel.org
Signed-off-by: Prarit Bhargava
---
drivers/pci/pci-sysfs.c | 23 ++-
1 file changed, 22 insertions(+), 1 deletion(-)
diff --git a/drivers/pci/pci-sysfs.c b/drivers/pci/pci-sysfs.c
index 92b6d9a..c05ed30 100644
--- a/drivers/pci/pci-sysfs.c
+++
On 10/15/2014 11:57 AM, H. Peter Anvin wrote:
> On 10/09/2014 08:35 AM, Prarit Bhargava wrote:
>>
>> Non-fatal warning seen with latest kernel tree during kernel boot.
>>
>> WARNING: CPU: 64 PID: 0 at kernel/locking/lockdep.c:2744
>> lockdep_trace_alloc+0x
On 10/14/2014 03:10 AM, Viresh Kumar wrote:
> On 13 October 2014 18:41, Prarit Bhargava wrote:
>>
>> The locking is insufficient here, Viresh. I no longer believe that fixes
>> to this locking scheme are the right way to move forward here. I'm wondering
>> if w
On 10/13/2014 09:11 AM, Prarit Bhargava wrote:
> There are several issues with the current locking design of cpufreq. Most
> notably is the panic reported here:
>
> http://marc.info/?l=linux-kernel&m=140622451625236&w=2
>
> whic
There are several issues with the current locking design of cpufreq. Most
notably is the panic reported here:
http://marc.info/?l=linux-kernel&m=140622451625236&w=2
which was introduced by commit 955ef4833574636819cd269cfbae12f79cbde63a,
cpufreq: Drop rwsem lock around CPUFREQ_GOV_POLICY_EXIT, w
On 10/13/2014 06:43 AM, Viresh Kumar wrote:
> On 1 August 2014 22:48, Stephen Boyd wrote:
>> On 08/01/14 03:27, Prarit Bhargava wrote:
>>>
>>> Can you send me the test and the trace of the deadlock? I'm not creating
>>> it with:
>>>
&g
On 10/10/2014 07:47 PM, Shuah Khan wrote:
> On Fri, Oct 10, 2014 at 4:55 PM, Prarit Bhargava wrote:
>> When doing git-status there are two untracked files:
>>
>> \# Untracked files:
>> \# (use "git add ..." to include in what will be committed)
>&
601 - 700 of 1067 matches
Mail list logo
