* Sasha Levin wrote:
> Use a constructor in the library instead of making the user manually
> call liblockdep_init().
>
> Signed-off-by: Sasha Levin
> ---
> tools/lib/lockdep/common.c| 2 +-
> tools/lib/lockdep/include/liblockdep/common.h | 1 -
>
Junio C Hamano writes:
> +At Git 2.0 (not *this* one), we
> +plan to change these commands without pathspec to operate on the
> +entire tree, and training your fingers to type "." will protect you
> +against the future change.
My understanding of the plan was more to forbid argumentless git
On Monday 18 February 2013 09:49:16, Greg KH wrote:
> > Invalid argument - /sys/devices/virtual/net/lo/speed
> > Invalid argument - /sys/devices/virtual/net/lo/duplex
This is even true for ethernet devices which do not have a link currently or
non-ethernet devices (e.g. CAN).
> LANG=C cat
On Mon, Feb 18, 2013 at 10:24:00PM -0700, Alex Williamson wrote:
> On Mon, 2013-02-18 at 17:15 +1100, Alexey Kardashevskiy wrote:
> > On 13/02/13 04:15, Alex Williamson wrote:
> > > On Wed, 2013-02-13 at 01:42 +1100, Alexey Kardashevskiy wrote:
> > >> On 12/02/13 16:07, Alex Williamson wrote:
> >
On 02/19/2013 12:13 PM, Rakib Mullick wrote:
> On Mon, Feb 18, 2013 at 9:25 PM, Steven Rostedt wrote:
>> On Mon, 2013-02-18 at 13:43 +0530, Srikar Dronamraju wrote:
The cache misses dropped by ~23% and migrations dropped by ~28%. I
really believe that the idle_balance() hurts
On Mon, 2013-02-18 at 20:13 -0800, Simon Glass wrote:
> On Sat, Feb 16, 2013 at 12:49 PM, Dmitry Torokhov
> > On Fri, Feb 15, 2013 at 08:16:12PM -0800, Simon Glass wrote:
> >> + for (row = 0; row < ckdev->rows; row++) {
> >> + if (cros_ec_keyb_row_has_ghosting(ckdev, buf, row))
>
Commit-ID: 77852fea6e2442a0e654a9292060489895de18c7
Gitweb: http://git.kernel.org/tip/77852fea6e2442a0e654a9292060489895de18c7
Author: Ingo Molnar
AuthorDate: Sat, 16 Feb 2013 09:46:48 +0100
Committer: Ingo Molnar
CommitDate: Tue, 19 Feb 2013 08:06:01 +0100
sched/rt: Add header to
Hello Linus,
Here is a battery/power_supply queue for v3.9. There are two tags:
for-v3.9 and for-v3.9-merged. The second one is exactly the same as the
first one, except that in the -merged tag I merged v3.8 back into battery
tree to fix some conflicts so that you wouldn't need to do it.
2013/02/19 15:43, Yasuaki Ishimatsu wrote:
Hi Rafael,
I have comments. Please see below.
2013/02/18 0:21, Rafael J. Wysocki wrote:
From: Rafael J. Wysocki
Multiple drivers handling hotplug-capable ACPI device nodes install
notify handlers covering the same types of events in a very similar
On Tue, Feb 19, 2013 at 12:43:06AM +0100, Jiri Slaby wrote:
> On 02/19/2013 12:23 AM, Marcin Slusarz wrote:
> > On Mon, Feb 18, 2013 at 11:27:43AM +0100, Jiri Slaby wrote:
> >> Hi,
> >>
> >> we have a report of WARNING from 3.7.6 in nouveau at
> >> drivers/gpu/drm/nouveau/core/core/mm.c:242 here:
quilt eat original header, here is the former, sorry
for incovenience.
---
From: Alexander Kartashov
Subject: arm: Wire up kcmp syscall
Signed-off-by: Alexander Kartashov
Cc: Russell King
---
arch/arm/include/uapi/asm/unistd.h |2 +-
arch/arm/kernel/calls.S|2 +-
2 files
Hello.
Strange, but I not received an original answer from Arnd, have only this mail.
...
> >> diff --git a/drivers/mfd/syscon.c b/drivers/mfd/syscon.c
> >> index 4a7ed5a..3c0abcb 100644
> >> --- a/drivers/mfd/syscon.c
> >> +++ b/drivers/mfd/syscon.c
> >
> > Hi Alexander,
> >
> >> struct regmap
2013/2/19 Will Huck :
> On 02/19/2013 10:04 AM, Li Haifeng wrote:
>>
>> 2013/2/19 Hugh Dickins
>>>
>>> On Mon, 18 Feb 2013, Li Haifeng wrote:
>>>
For explain my question, the two points should be displayed as below.
1. If an anonymous page is swapped out, this page will be deleted
Since kcmp syscall has been implemented (initially on
x86 architecture) a number of other archs wire it up
as well: xtensa, sparc, sh, s390, mips, microblaze,
m68k (not taking into account those who uses
for syscall numbers
definitions).
But the Makefile, which turns kcmp.o generation on
still
Signed-off-by: Alexander Kartashov
Cc: Russell King
---
arch/arm/include/uapi/asm/unistd.h |2 +-
arch/arm/kernel/calls.S|2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
Index: linux-2.6.git/arch/arm/include/uapi/asm/unistd.h
Hi guys, kcmp syscall (according to git log) is being wired up for a number
of architectures other than x86 (where it was developed initially). But the
main Makefile which controling its compilation is still x86 dependant.
Thus I think kcmp may deserve own config entry unrelated to arch type it
2013/02/18 0:20, Rafael J. Wysocki wrote:
From: Rafael J. Wysocki
Introduce helper routine acpi_scan_match_handler() that will find the
ACPI scan handler matching a given device ID, if there is one, and
rework acpi_scan_attach_handler() to use the new routine (that
routine will also be useful
HI All,
I am working on Sd Card/Block driver
I am registering it as both
1. register_blkdev()- BLOCK Regsiter
2. mmc_register_driver -- MMC regsiter
and filling the mmc_driver structure.
I am not able to see the probe of MMC, But i see the return value of
mmc_register
Hi Rafael,
I have comments. Please see below.
2013/02/18 0:21, Rafael J. Wysocki wrote:
From: Rafael J. Wysocki
Multiple drivers handling hotplug-capable ACPI device nodes install
notify handlers covering the same types of events in a very similar
way. Moreover, those handlers are installed
2013/2/19 Soham Chakraborty :
> Hey dude,
>
> Apologies for this kind of approach but I was not sure whether I can
> directly mail the list with such a noobish question. I have been poking
> around in mm subsystem for around 2 years now and I have never got a fine,
> bullet proof answer to this
Steven Rostedt wrote:
> If only you, or a few people are using it (ie. distros don't see a
> need), then it will be up to you to make the changes.
I believe that this functionality is of a general nature and is needed
by many, not only by myself and by the CRIU group, but by all user-level
On Mon, 2013-02-18 at 23:06 -0500, Steven Rostedt wrote:
> On Tue, 2013-02-19 at 09:56 +0800, Li Zefan wrote:
>
> > Oh ignore me. Just saw the patchset for 3.4-rt.
>
> Note, I already have part of the 3.4-feature (softirq backport) tested
> and ready. What I'm waiting on is trying to figure out
1. Currently mxser_probe() and mxser_module_init() ignore errors
that can happen in tty_port_register_device().
2. mxser_module_init() does not deallocate resources allocated in
mxser_get_ISA_conf()
if mxser_initbrd() failed.
The patch adds proper error handling in all the cases.
Also it moves
Use the generic PHY framework API to get the PHY. The usb_phy_set_suspend
and usb_phy_set_resume is replaced with phy_suspend and phy_resume to
align with the new PHY framework.
musb->xceiv can't be removed as of now because musb core uses xceiv.state and
xceiv.otg. Once there is a separate state
Added a generic PHY framework that provides a set of APIs for the PHY drivers
to create/destroy a PHY and APIs for the PHY users to obtain a reference to
the PHY with or without using phandle. To obtain a reference to the PHY
without using phandle, the platform specfic intialization code (say from
Used the generic PHY framework API to create the PHY. omap_usb2_suspend
is split into omap_usb_suspend and omap_usb_resume in order to align
with the new framework.
However using the old USB PHY library cannot be completely removed
because OTG is intertwined with PHY and moving to the new
The PHY framework provides a set of APIs for the PHY drivers to
create/destroy a PHY and APIs for the PHY users to obtain a reference to the
PHY with or without using phandle. To obtain a reference to the PHY without
using phandle, the platform specfic intialization code (say from board file)
In order for controllers to get PHY in case of non dt boot, the phy
binding information should be added in the platform specific
initialization code using phy_bind. The previously added usb_bind_phy
can't be removed yet because the musb controller continues to use the
old PHY library which has OTG
Used the generic PHY framework API to create the PHY. twl4030_usb_suspend
and twl4030_usb_resume is added to phy_ops in order to align
with the new framework.
However using the old USB PHY library cannot be completely removed
because OTG is intertwined with PHY and moving to the new
framework
From: Andrew Jones
Date: Mon, 18 Feb 2013 21:29:20 +0100
> netbk_fatal_tx_err() calls xenvif_carrier_off(), which does
> a xenvif_put(). As callers of netbk_fatal_tx_err should only
> have one reference to the vif at this time, then the xenvif_put
> in netbk_fatal_tx_err is one too many.
>
>
Dear RT Folks,
This is the RT stable review cycle of patch 3.0.65-rt92-rc1.
Please scream at me if I messed something up. Please test the patches too.
The -rc release will be uploaded to kernel.org and will be deleted when
the final release is out. This is just a review release (or release
On 19 February 2013 00:02, Arnd Bergmann wrote:
> On Monday 18 February 2013, Alexander Shiyan wrote:
>> diff --git a/drivers/mfd/syscon.c b/drivers/mfd/syscon.c
>> index 4a7ed5a..3c0abcb 100644
>> --- a/drivers/mfd/syscon.c
>> +++ b/drivers/mfd/syscon.c
>
> Hi Alexander,
>
>> struct regmap
On 19/02/13 16:24, Alex Williamson wrote:
On Mon, 2013-02-18 at 17:15 +1100, Alexey Kardashevskiy wrote:
On 13/02/13 04:15, Alex Williamson wrote:
On Wed, 2013-02-13 at 01:42 +1100, Alexey Kardashevskiy wrote:
On 12/02/13 16:07, Alex Williamson wrote:
On Tue, 2013-02-12 at 15:06 +1100,
Oops! I used the wrong script to send. It used my "Ingo Pull" script
instead of my "stable RT review". Subject is missing "[PATCH RT]" and it
went to the wrong people.
Sorry for the noise, I'm in a hurry to get finished packing for ELC.
-- Steve
On Tue, 2013-02-19 at 00:30 -0500, Steven
From: Thomas Gleixner
Even with CONFIG_HIGHMEM=n we need to take care of the "atomic"
mappings which are installed via iomap_atomic.
Signed-off-by: Thomas Gleixner
Cc: stable...@vger.kernel.org
Signed-off-by: Steven Rostedt
---
arch/x86/kernel/process_32.c |2 +-
include/linux/sched.h
From: Steven Rostedt
We hit the following bug with 3.6-rt:
[5.898990] BUG: scheduling while atomic: swapper/3/0/0x0002
[5.898991] no locks held by swapper/3/0.
[5.898993] Modules linked in:
[5.898996] Pid: 0, comm: swapper/3 Not tainted
3.6.11-rt28.19.el6rt.x86_64.debug #1
From: Thomas Gleixner
Simple waitqueues can be handled from interrupt disabled contexts.
Signed-off-by: Thomas Gleixner
Signed-off-by: Steven Rostedt
---
kernel/rcutiny_plugin.h |9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/kernel/rcutiny_plugin.h
From: Steven Rostedt
---
localversion-rt |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/localversion-rt b/localversion-rt
index e95e338..dc0be96 100644
--- a/localversion-rt
+++ b/localversion-rt
@@ -1 +1 @@
--rt91
+-rt92-rc1
--
1.7.10.4
--
To unsubscribe from this
From: Thomas Gleixner
Even with CONFIG_HIGHMEM=n we need to take care of the "atomic"
mappings which are installed via iomap_atomic.
Signed-off-by: Thomas Gleixner
Cc: stable...@vger.kernel.org
Signed-off-by: Steven Rostedt
---
arch/x86/kernel/process_32.c |2 +-
include/linux/sched.h
From: Thomas Gleixner
Simple waitqueues can be handled from interrupt disabled contexts.
Signed-off-by: Thomas Gleixner
Signed-off-by: Steven Rostedt
---
kernel/rcutiny_plugin.h |9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/kernel/rcutiny_plugin.h
On Thu, Feb 14, 2013 at 10:54:28AM -0700, Stephen Warren wrote:
> On 02/13/2013 11:38 PM, Hiroshi Doyu wrote:
> > To replace magic number in "clocks = <_car 28>;"
>
> I like the concept here; I was thinking about doing this today, but you
> beat me to it:-) Feel free to create the Tegra30 header
Dear RT Folks,
This is the RT stable review cycle of patch 3.0.65-rt92-rc1.
Please scream at me if I messed something up. Please test the patches too.
The -rc release will be uploaded to kernel.org and will be deleted when
the final release is out. This is just a review release (or release
From: Steven Rostedt
---
localversion-rt |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/localversion-rt b/localversion-rt
index e95e338..dc0be96 100644
--- a/localversion-rt
+++ b/localversion-rt
@@ -1 +1 @@
--rt91
+-rt92-rc1
--
1.7.10.4
signature.asc
Description:
From: Steven Rostedt
We hit the following bug with 3.6-rt:
[5.898990] BUG: scheduling while atomic: swapper/3/0/0x0002
[5.898991] no locks held by swapper/3/0.
[5.898993] Modules linked in:
[5.898996] Pid: 0, comm: swapper/3 Not tainted
3.6.11-rt28.19.el6rt.x86_64.debug #1
Hi Andrew,
Today's linux-next merge of the akpm tree got a conflict in
net/mac80211/mesh_pathtbl.c between commit bf7cd94dcc71 ("mac80211: clean
up mesh code") from the wireless-next tree and commit "hlist: drop the
node parameter from iterators" from the akpm tree.
I fixed it up (see below) and
On Mon, 2013-02-18 at 17:15 +1100, Alexey Kardashevskiy wrote:
> On 13/02/13 04:15, Alex Williamson wrote:
> > On Wed, 2013-02-13 at 01:42 +1100, Alexey Kardashevskiy wrote:
> >> On 12/02/13 16:07, Alex Williamson wrote:
> >>> On Tue, 2013-02-12 at 15:06 +1100, Alexey Kardashevskiy wrote:
>
On Sat, Feb 16, 2013 at 11:46 AM, Oleg Nesterov wrote:
> On 02/16, Oleg Nesterov wrote:
>>
>> On 02/16, Mandeep Singh Baines wrote:
>> >
>> > +static int sigkill_pending(struct task_struct *tsk)
>> > +{
>> > + return signal_pending(tsk) &&
>> > + (sigismember(>pending.signal,
LP5562 can drive up to 4 channels, RGB and White.
LEDs can be controlled directly via the led class control interface.
LP55xx common driver
LP5562 is one of LP55xx family device, so LP55xx common code are used.
On the other hand, chip specific configuration is defined in the structure
On Mon, Feb 18, 2013 at 11:11:30PM -0500, Nicolas Pitre wrote:
> On Tue, 19 Feb 2013, Shawn Guo wrote:
>
> > On Mon, Feb 18, 2013 at 12:06:32PM -0500, Nicolas Pitre wrote:
> > > Try the following instead. It makes the code simpler and easier to
> > > debug.
> > >
> > It works now. Thanks,
Signed-off-by: Milo(Woogyom) Kim
---
drivers/leds/leds-lp55xx-common.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/leds/leds-lp55xx-common.c
b/drivers/leds/leds-lp55xx-common.c
index d9eb841..8a388a4 100644
--- a/drivers/leds/leds-lp55xx-common.c
+++
On Monday, February 18, 2013 19:59:28 Andrey Smirnov wrote:
> This is a fourth version of the patchset originaly posted here:
> https://lkml.org/lkml/2012/9/13/590
>
> Second version of the patch was posted here:
> https://lkml.org/lkml/2012/10/5/598
>
> Third version of the patch was posted
On 02/17/2013 01:42 PM, Sasha Levin wrote:
> Hi all,
>
> I was fuzzing with trinity inside a KVM tools guest, with today's -next kernel
> when I've hit the following spew.
>
> I suspect it's the result of adding the new rcu_oom_notify, but that happened
> about half a year ago so I'm not sure
On Fri, 2013-01-18 at 12:28 -0800, Bing Zhao wrote:
> Hi Lubomir,
>
> > It actually times out on a 8688 present in GuruPlug with sd8688.bin
> > (md5=7233401e9687f8c880da547beed4324e) firmware (that's present in
> > linux-firmware tree), but the adapter works fine.
> >
> > For that firmware times
With this patch userland applications that want to maintain the
interactivity/memory allocation cost can use the pressure level
notifications. The levels are defined like this:
The "low" level means that the system is reclaiming memory for new
allocations. Monitoring this reclaiming activity
On Mon, 2013-02-18 at 20:39 -0800, H. Peter Anvin wrote:
> > static void switch_to_trace_idt(void *arg)
> > {
> > load_idt(_idt_descr);
> > }
> >
> > static void restore_original_idt(void *arg)
> > {
> > load_idt(this_cpu_ptr(_descr));
> > }
> >
>
> Yes. If there needs to be
On 02/18/2013 08:24 PM, Steven Rostedt wrote:
> On Mon, 2013-02-18 at 15:49 -0800, H. Peter Anvin wrote:
>
>> What about the following:
>>
>>> The base address of the IDT doesn't generally change... the one
>>> exception is when we do the funny NMI workaround.
>>>
>>> For that reason, I would be
Sasha Levin writes:
> On 02/17/2013 07:17 PM, ebied...@xmission.com wrote:
>> The bad pointer value is 0xfff0. Hmm.
>>
>> If you have the failure location correct it looks like a corrupted hash
>> entry was found while following the hash chain.
>>
>> It looks like the memory has
On Mon, 2013-02-18 at 15:49 -0800, H. Peter Anvin wrote:
> What about the following:
>
> > The base address of the IDT doesn't generally change... the one
> > exception is when we do the funny NMI workaround.
> >
> > For that reason, I would be happier if we just restored the standard
> > value
From: Steven Rostedt
The tracing of ia32 compat system calls has been a bit of a pain as they
use different system call numbers than the 64bit equivalents.
I wrote a simple 'lls' program that lists files. I compiled it as a i686
ELF binary and ran it under a x86_64 box. This is the result:
From: "Steven Rostedt (Red Hat)"
Commit: c1bf08ac "ftrace: Be first to run code modification on modules"
changed ftrace module notifier's priority to INT_MAX in order to
process the ftrace nops before anything else could touch them
(namely kprobes). This was the correct thing to do.
Ingo,
Please pull the latest tip/perf/core tree, which can be found at:
git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace.git
tip/perf/core
Head SHA1: 8c189ea64eea01ca20d102ddb74d6936dd16c579
Steven Rostedt (1):
tracing/syscalls: Allow archs to ignore tracing compat
smatch complains about a possible buffer overflow
slicoss.c:3651 slic_card_locate() error: buffer overflow
'physcard->adapter' 4 <= 4
If the for loop is not exited prematurely i++ is executed after the last
iteration and thus i can be 4, which is out of bounds for
physcard->adapter.
-> Add check
gcc complains about an undefined operation:
slicoss.c:1417:19: warning: operation on 'rspq->pageindex' may be
undefined [-Wsequence-point]
The intended operation was (probably) to retrieve the pageindex + 1 and let
it wrap around if it reaches the num_pages.
Signed-off-by: Peter Huewe
---
Instead of performing the hash calculation for the mac address by ourself, we
can simply reuse ether_crc and shift only the result according to our
needs.
The code was tested against the previous implementation by verifying both
implementations against each other in userspace for 162
skbtype is assigned once to NORMAL_ETHFRAME and then checked if it is
NORMAL_ETHFRAME -> remove the checks.
This also gets rid of the (false positive) smatch warning:
slicoss.c:2829 slic_xmit_start() error: potential NULL dereference
'hcmd'.
Signed-off-by: Peter Huewe
---
Hi Dmitry,
On Sat, Feb 16, 2013 at 12:49 PM, Dmitry Torokhov
wrote:
> Hi Simon,
>
> On Fri, Feb 15, 2013 at 08:16:12PM -0800, Simon Glass wrote:
>> + for (row = 0; row < ckdev->rows; row++) {
>> + if (cros_ec_keyb_row_has_ghosting(ckdev, buf, row))
>> + return
On Mon, Feb 18, 2013 at 9:25 PM, Steven Rostedt wrote:
> On Mon, 2013-02-18 at 13:43 +0530, Srikar Dronamraju wrote:
>> > The cache misses dropped by ~23% and migrations dropped by ~28%. I
>> > really believe that the idle_balance() hurts performance, and not just
>> > for something like
On Tue, 19 Feb 2013, Shawn Guo wrote:
> On Mon, Feb 18, 2013 at 12:06:32PM -0500, Nicolas Pitre wrote:
> > Try the following instead. It makes the code simpler and easier to
> > debug.
> >
> It works now. Thanks, Nico. Care to send a patch for it? I'd like
> to apply it.
- >8
FRom:
Smatch complains that the variable adapter is dereferenced before it is
checked:
slicoss.c:906 slic_timer_load_check() warn: variable dereferenced before
check 'adapter' (see line 904)
-> move the assignment after the check.
Signed-off-by: Peter Huewe
---
drivers/staging/slicoss/slicoss.c |
On tue, 19 Feb 2013 09:22:40 +0800, Li Zefan wrote:
> There's a long long-standing bug...As long as I don't know when it dates
> from.
>
> I've written and attached a simple program to reproduce this bug, and it can
> immediately trigger the bug in my box. It uses two threads, one keeps calling
>
On Tue, 2013-02-19 at 09:56 +0800, Li Zefan wrote:
> Oh ignore me. Just saw the patchset for 3.4-rt.
Note, I already have part of the 3.4-feature (softirq backport) tested
and ready. What I'm waiting on is trying to figure out the best way to
process it.
I already know I'll have a v3.4-features
From: Andrey Smirnov
This patch adds code related to manipulation of the properties of
SI476X chips.
Signed-off-by: Andrey Smirnov
---
drivers/mfd/si476x-prop.c | 234 +
1 file changed, 234 insertions(+)
create mode 100644
From: Andrey Smirnov
This patch adds all the functions used for exchanging commands with
the chip.
Signed-off-by: Andrey Smirnov
---
drivers/mfd/si476x-cmd.c | 1553 ++
1 file changed, 1553 insertions(+)
create mode 100644 drivers/mfd/si476x-cmd.c
From: Andrey Smirnov
This patch adds main part(out of three) of the I2C driver for the
"core" of MFD device.
Signed-off-by: Andrey Smirnov
---
drivers/mfd/si476x-i2c.c | 878 ++
1 file changed, 878 insertions(+)
create mode 100644
- Add appropriate license header
- Change email address in MODULE_AUTHOR
- Remove trailing whitespaces
Signed-off-by: Andrey Smirnov
---
sound/soc/codecs/si476x.c | 25 ++---
1 file changed, 22 insertions(+), 3 deletions(-)
diff --git a/sound/soc/codecs/si476x.c
From: Andrey Smirnov
The latest radio and MFD drivers for SI476X radio chips use regmap API
to provide access to the registers and allow for caching of their
values when the actual chip is powered off. Convert the codec driver
to do the same, so it would not loose the settings when the radio
From: Andrey Smirnov
This patch adds all necessary header files and Kbuild plumbing for the
core driver for Silicon Laboratories Si476x series of AM/FM tuner
chips.
The driver as a whole is implemented as an MFD device and this patch
adds a core portion of it that provides all the necessary
This is a fourth version of the patchset originaly posted here:
https://lkml.org/lkml/2012/9/13/590
Second version of the patch was posted here:
https://lkml.org/lkml/2012/10/5/598
Third version of the patch was posted here:
https://lkml.org/lkml/2012/10/23/510
To save everyone's time I'll
From: Thomas Gleixner
commit 9ec1882df2 (tty: serial: imx: console write routing is unsafe
on SMP) introduced a recursive locking bug in imx_console_write().
The callchain is:
imx_rxint()
spin_lock_irqsave(>port.lock,flags);
...
uart_handle_sysrq_char();
sysrq_function();
From: "Bu, Yitian"
commit 07354eb1a74d1 ("locking printk: Annotate logbuf_lock as raw")
reintroduced a lock inversion problem which was fixed in commit
0b5e1c5255 ("printk: Release console_sem after logbuf_lock"). This
happened probably when fixing up patch rejects.
Restore the ordering and
From: Thomas Gleixner
Simple waitqueues can be handled from interrupt disabled contexts.
Signed-off-by: Thomas Gleixner
Signed-off-by: Steven Rostedt
---
kernel/rcutiny_plugin.h | 17 +
1 file changed, 9 insertions(+), 8 deletions(-)
diff --git a/kernel/rcutiny_plugin.h
From: Thomas Gleixner
Even with CONFIG_HIGHMEM=n we need to take care of the "atomic"
mappings which are installed via iomap_atomic.
Signed-off-by: Thomas Gleixner
Cc: stable...@vger.kernel.org
Signed-off-by: Steven Rostedt
---
arch/x86/kernel/process_32.c |2 +-
include/linux/sched.h
From: Steven Rostedt
We hit the following bug with 3.6-rt:
[5.898990] BUG: scheduling while atomic: swapper/3/0/0x0002
[5.898991] no locks held by swapper/3/0.
[5.898993] Modules linked in:
[5.898996] Pid: 0, comm: swapper/3 Not tainted
3.6.11-rt28.19.el6rt.x86_64.debug #1
Dear RT Folks,
This is the RT stable review cycle of patch 3.2.38-rt58-rc1.
Please scream at me if I messed something up. Please test the patches too.
The -rc release will be uploaded to kernel.org and will be deleted when
the final release is out. This is just a review release (or release
From: Steven Rostedt
---
localversion-rt |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/localversion-rt b/localversion-rt
index c06cc435..1fdcd49 100644
--- a/localversion-rt
+++ b/localversion-rt
@@ -1 +1 @@
--rt57
+-rt58-rc1
--
1.7.10.4
--
To unsubscribe from this
Dear RT Folks,
This is the RT stable review cycle of patch 3.4.32-rt46-rc1.
Please scream at me if I messed something up. Please test the patches too.
The -rc release will be uploaded to kernel.org and will be deleted when
the final release is out. This is just a review release (or release
From: Thomas Gleixner
wait_queue is a swiss army knife and in most of the cases the
complexity is not needed. For RT waitqueues are a constant source of
trouble as we can't convert the head lock to a raw spinlock due to
fancy and long lasting callbacks.
Provide a slim version, which allows RT
From: Thomas Gleixner
commit 9ec1882df2 (tty: serial: imx: console write routing is unsafe
on SMP) introduced a recursive locking bug in imx_console_write().
The callchain is:
imx_rxint()
spin_lock_irqsave(>port.lock,flags);
...
uart_handle_sysrq_char();
sysrq_function();
From: "Bu, Yitian"
commit 07354eb1a74d1 ("locking printk: Annotate logbuf_lock as raw")
reintroduced a lock inversion problem which was fixed in commit
0b5e1c5255 ("printk: Release console_sem after logbuf_lock"). This
happened probably when fixing up patch rejects.
Restore the ordering and
From: Thomas Gleixner
wait_queue is a swiss army knife and in most of the cases the
complexity is not needed. For RT waitqueues are a constant source of
trouble as we can't convert the head lock to a raw spinlock due to
fancy and long lasting callbacks.
Provide a slim version, which allows RT
From: Steven Rostedt
---
localversion-rt |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/localversion-rt b/localversion-rt
index 38c40b2..2a08cf6 100644
--- a/localversion-rt
+++ b/localversion-rt
@@ -1 +1 @@
--rt45
+-rt46-rc1
--
1.7.10.4
--
To unsubscribe from this
From: Thomas Gleixner
Simple waitqueues can be handled from interrupt disabled contexts.
Signed-off-by: Thomas Gleixner
Signed-off-by: Steven Rostedt
---
kernel/rcutiny_plugin.h | 17 +
1 file changed, 9 insertions(+), 8 deletions(-)
diff --git a/kernel/rcutiny_plugin.h
From: Thomas Gleixner
Even with CONFIG_HIGHMEM=n we need to take care of the "atomic"
mappings which are installed via iomap_atomic.
Signed-off-by: Thomas Gleixner
Cc: stable...@vger.kernel.org
Signed-off-by: Steven Rostedt
---
arch/x86/kernel/process_32.c |2 +-
include/linux/sched.h
From: Steven Rostedt
We hit the following bug with 3.6-rt:
[5.898990] BUG: scheduling while atomic: swapper/3/0/0x0002
[5.898991] no locks held by swapper/3/0.
[5.898993] Modules linked in:
[5.898996] Pid: 0, comm: swapper/3 Not tainted
3.6.11-rt28.19.el6rt.x86_64.debug #1
Dear RT Folks,
I'm pleased to announce the 3.0.65-rt91 stable release.
This release is just an update to the new stable 3.0.65 version
and no RT specific changes have been made.
You can get this release via the git tree at:
Dear RT Folks,
I'm pleased to announce the 3.4.32-rt45 stable release.
This release is just an update to the new stable 3.4.32 version
and no RT specific changes have been made.
You can get this release via the git tree at:
Hi Daniel,
On Tue, Feb 19, 2013 at 12:55:52AM +0100, Daniel Mack wrote:
> ref25: ref25M {
> compatible = "fixed-clock";
> #clock-cells = <0>;
> clock-frequency = <2500>;
> };
>
> clock-generator@0 {
>
On Sun, Feb 17, 2013 at 05:25:43PM -0800, Eric W. Biederman wrote:
> Dave Chinner writes:
>
> > On Wed, Feb 13, 2013 at 10:13:16AM -0800, Eric W. Biederman wrote:
> >
> >> The crazy thing is that is that xfs appears to
> >> directly write their incore inode structure into their journal.
> >
> >
On 02/19/2013 11:07 AM, Shaohua Li wrote:
This patch in linux-next breaks numa detection. numa_init() will zero
numa_meminfo. If acpi_numa_init() does not call early_parse_srat(), we will
have no memory numa info.
Hum, yes, I missed this one. :)
Briefly seeing the code, I think moving the
Thanks!
Acked-by: Javier Muñoz
On 02/19/2013 12:12 AM, Peter Huewe wrote:
> Instead of assigning the pm_ops fields individually we can simply use
> SIMPLE_DEV_PM_OPS.
>
> Signed-off-by: Peter Huewe
> ---
> drivers/staging/sm7xxfb/sm7xxfb.c | 10 +-
> 1 files changed, 1
1 - 100 of 1098 matches
Mail list logo
