On Sun, 2012-06-03 at 23:32 +0300, Arik Nemtsov wrote:
sta_info_cleanup locks the sta_list using rcu_read_lock however
the delete operation isn't rcu safe. A race between sta_info_cleanup
timer being called and a STA being removed can occur which leads
to a panic while traversing sta_list. Fix
Empirical evidence suggests that we need to: On at least one ivb
machine when running the hangman i-g-t test, the rings don't properly
initialize properly - the RING_START registers seems to be stuck at
all zeros.
Holding forcewake around this register init sequences makes chip reset
reliable
When system software decides to power down the xHC with the intent of
resuming operation at a later time, it will ask xHC to save the internal
state and restore it when resume to correctly recover from a power event.
Two bits are used to enable this operation: Save State and Restore State.
xHCI
Hi Daniel, please find a couple of comments inline.
BR,
Jani.
On Mon, 04 Jun 2012, Daniel Vetter daniel.vet...@ffwll.ch wrote:
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 238a521..a0c76aa 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++
On Mon, Jun 04, 2012 at 12:04:41PM +0300, Jani Nikula wrote:
Hi Daniel, please find a couple of comments inline.
Oops, a clear case of -ENOTENOUGHCOFFEE. Thanks for catching these, I'll
follow up with a v2 shortly.
-Daniel
--
Daniel Vetter
Mail: dan...@ffwll.ch
Mobile: +41 (0)79 365 57 48
--
Empirical evidence suggests that we need to: On at least one ivb
machine when running the hangman i-g-t test, the rings don't properly
initialize properly - the RING_START registers seems to be stuck at
all zeros.
Holding forcewake around this register init sequences makes chip reset
reliable
On Mon, 4 Jun 2012 11:16:04 +0200, Daniel Vetter dan...@ffwll.ch wrote:
On Mon, Jun 04, 2012 at 12:04:41PM +0300, Jani Nikula wrote:
Hi Daniel, please find a couple of comments inline.
Oops, a clear case of -ENOTENOUGHCOFFEE. Thanks for catching these, I'll
follow up with a v2 shortly.
On Mon, Jun 04, 2012 at 11:18:15AM +0200, Daniel Vetter wrote:
Empirical evidence suggests that we need to: On at least one ivb
machine when running the hangman i-g-t test, the rings don't properly
initialize properly - the RING_START registers seems to be stuck at
all zeros.
Holding
Hi!
VVMHyper-V admins need _worked_ Linux v3.4.X / v3.3.X / v3.2.X
VVM
VVMPlease, _fix_ errors related use hv_storvsc instead of ata_piix to
VVMhandle the IDE disks devices ( but not for the CD-ROM)
K.Y.S. {
Clearly I cannot tell you anything about this that you don't know!
On 06/04/2012 06:18 AM, Daniel Vetter wrote:
Empirical evidence suggests that we need to: On at least one ivb
machine when running the hangman i-g-t test, the rings don't properly
initialize properly - the RING_START registers seems to be stuck at
all zeros.
Holding forcewake around this
The patch below does not apply to the 3.4-stable tree.
If someone wants it applied there, or to any other stable or longterm
tree, then please email the backport, including the original git commit
id to stable@vger.kernel.org.
thanks,
greg k-h
-- original commit
MX53_DPLL4_BASE accidently returned the base address of PLL3.
Fix this.
Signed-off-by: Sascha Hauer s.ha...@pengutronix.de
Cc: stable@vger.kernel.org
---
arch/arm/mach-imx/crm-regs-imx5.h |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/mach-imx/crm-regs-imx5.h
-Original Message-
From: Victor Miasnikov [mailto:v...@tut.by]
Sent: Monday, June 04, 2012 8:33 AM
To: Greg KH; KY Srinivasan
Cc: stable@vger.kernel.org; Jonathan Nieder; linux-ker...@vger.kernel.org;
Mike Sterling
Subject: Re: Linux on Hyper-V 1) cd006086fa5d ata_piix: defer
Hi!
VVMHyper-V admins need _worked_ Linux v3.4.X / v3.3.X / v3.2.X
I can help you with the ata patch on specific set of distros of interest.
If the system that you are interested loads the ata_piix module,
we can solve the issue on hand using modprobe rules rather than a patch against the
-Original Message-
From: Victor Miasnikov [mailto:v...@tut.by]
Sent: Monday, June 04, 2012 10:15 AM
To: KY Srinivasan; Greg KH
Cc: stable@vger.kernel.org; Jonathan Nieder; linux-ker...@vger.kernel.org;
Mike Sterling
Subject: Re: Linux on Hyper-V 1) cd006086fa5d ata_piix: defer
Other components may also require an unplug callback, so move this
function from md/raid to block generic layer.
Signed-off-by: Tao Guo tao@emc.com
Cc: Neil Brown ne...@suse.de
Cc: Jens Axboe ax...@kernel.dk
Cc: stable@vger.kernel.org
Cc: Andrew Morton a...@linux-foundation.org
Cc:
This patch is to fix a regression introduced by 7eaceaccab5f40
(block: remove per-queueplugging).
-Tao
On Mon, Jun 4, 2012 at 10:41 PM, Tao Guo glorious...@gmail.com wrote:
In that patch, Jens removed the whole mm_unplug_device()
function, which used to be the trigger to make umem start to
Hi!
VVMHyper-V admins need _worked_ Linux v3.4.X / v3.3.X / v3.2.X
I can help you with the ata patch on specific set of distros of interest.
If the system that you are interested loads the ata_piix module,
we can solve the issue on hand using modprobe rules rather than a patch
against the
This is based on info released by AMD, should allow using audio in much
more cases.
Signed-off-by: Rafał Miłecki zaj...@gmail.com
Cc: stable@vger.kernel.org
---
drivers/gpu/drm/radeon/r600_audio.c |5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git
On Mon, Jun 4, 2012 at 12:36 PM, Rafał Miłecki zaj...@gmail.com wrote:
This is based on info released by AMD, should allow using audio in much
more cases.
Signed-off-by: Rafał Miłecki zaj...@gmail.com
Cc: stable@vger.kernel.org
Reviewed-by: Alex Deucher alexander.deuc...@amd.com
---
I'm announcing the release of the 3.0.33 kernel.
All users of the 3.0 kernel series must upgrade.
The updated 3.0.y git tree can be found at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
linux-3.0.y
and can be browsed at the normal kernel.org git web browser:
I'm announcing the release of the 3.3.8 kernel.
Note, this is the LAST 3.3.y kernel release, it is now end-of-life.
Please move to the 3.4.y kernel tree as soon as possible.
All users of the 3.3 kernel series must upgrade.
The updated 3.3.y git tree can be found at:
I'm announcing the release of the 3.4.1 kernel.
All users of the 3.4 kernel series must upgrade.
The updated 3.4.y git tree can be found at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
linux-3.4.y
and can be browsed at the normal kernel.org git web browser:
I'm announcing the release of the 3.2.19 kernel.
All users of the 3.2 kernel series should upgrade.
The updated 3.2.y git tree can be found at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
linux-3.2.y
and can be browsed at the normal kernel.org git web browser:
On Mon, Jun 04, 2012 at 10:41:50AM -0400, Tao Guo wrote:
Other components may also require an unplug callback, so move this
function from md/raid to block generic layer.
I saw no point this should be generic code, for example, why blk_plug_cb only
handles only one request_queue? If umem needs
If you ever tried to implement unplug function in umem, you would find the code
was almost identical as in dm/raid driver.
For other components which also need such unplug mechanism, it will much more
convenient to have such facilities.
PS: What's your specific concern about blk_plug_cb handles
On Mon, 2012-06-04 at 22:27 -0400, Steven Rostedt wrote:
As I was adding code that affects all archs, I started testing function
tracer against PPC64 and found that it currently locks up with 3.4
kernel. I figured it was due to tracing a function that shouldn't be, so
I went through the
Hi,
Victor Miasnikov wrote:
+ see tranlate from Russian language issue described by Maksim Kramarenko:
http://lists.debian.org/debian-russian/2012/01/msg00324.html
Correct, that is loaded without error, sleep and wake, for a small exception:
At the conclusion of the system through the halt
28 matches
Mail list logo
