[PATCH] drm/i915: hold forcewake around ring hw init
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 again. Note that this is not the first such issue:
commit f01db988ef6f6c70a6cc36ee71e4a98a68901229
Author: Sean Paul
Date: Fri Mar 16 12:43:22 2012 -0400
drm/i915: Add wait_for in init_ring_common
added delay loops to make RING_START and RING_CTL initialization
reliable on the blt ring at boot-up. So I guess it won't hurt if we do
this unconditionally for all force_wake needing gpus.
To avoid copy&pasting of the HAS_FORCE_WAKE check I've added a new
intel_info bit for that.
Cc: stable@vger.kernel.org
Reported-by: Yang Guang
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=50522
Signed-Off-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_drv.c | 13 +
drivers/gpu/drm/i915/i915_drv.h |3 +++
drivers/gpu/drm/i915/intel_ringbuffer.c |9 -
3 files changed, 20 insertions(+), 5 deletions(-)
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
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -233,6 +233,7 @@ static const struct intel_device_info
intel_sandybridge_d_info = {
.has_blt_ring = 1,
.has_llc = 1,
.has_pch_split = 1,
+ .has_force_wake = 1
};
static const struct intel_device_info intel_sandybridge_m_info = {
@@ -243,6 +244,7 @@ static const struct intel_device_info
intel_sandybridge_m_info = {
.has_blt_ring = 1,
.has_llc = 1,
.has_pch_split = 1,
+ .has_force_wake = 1
};
static const struct intel_device_info intel_ivybridge_d_info = {
@@ -252,6 +254,7 @@ static const struct intel_device_info
intel_ivybridge_d_info = {
.has_blt_ring = 1,
.has_llc = 1,
.has_pch_split = 1,
+ .has_force_wake = 1
};
static const struct intel_device_info intel_ivybridge_m_info = {
@@ -262,6 +265,7 @@ static const struct intel_device_info
intel_ivybridge_m_info = {
.has_blt_ring = 1,
.has_llc = 1,
.has_pch_split = 1,
+ .has_force_wake = 1
};
static const struct intel_device_info intel_valleyview_m_info = {
@@ -289,6 +293,7 @@ static const struct intel_device_info intel_haswell_d_info
= {
.has_blt_ring = 1,
.has_llc = 1,
.has_pch_split = 1,
+ .has_force_wake = 1
};
static const struct intel_device_info intel_haswell_m_info = {
@@ -298,6 +303,7 @@ static const struct intel_device_info intel_haswell_m_info
= {
.has_blt_ring = 1,
.has_llc = 1,
.has_pch_split = 1,
+ .has_force_wake = 1
};
static const struct pci_device_id pciidlist[] = { /* aka */
@@ -1139,10 +1145,9 @@ MODULE_LICENSE("GPL and additional rights");
/* We give fast paths for the really cool registers */
#define NEEDS_FORCE_WAKE(dev_priv, reg) \
- (((dev_priv)->info->gen >= 6) && \
-((reg) < 0x4) &&\
-((reg) != FORCEWAKE)) && \
- (!IS_VALLEYVIEW((dev_priv)->dev))
+ ((HAS_FORCE_WAKE((dev_priv)->dev)) && \
+((reg) < 0x4) &&\
+((reg) != FORCEWAKE))
#define __i915_read(x, y) \
u##x i915_read##x(struct drm_i915_private *dev_priv, u32 reg) { \
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index ccabadd..7cc36db 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -285,6 +285,7 @@ struct intel_device_info {
u8 is_ivybridge:1;
u8 is_valleyview:1;
u8 has_pch_split:1;
+ u8 has_force_wake:1;
u8 is_haswell:1;
u8 has_fbc:1;
u8 has_pipe_cxsr:1;
@@ -1105,6 +1106,8 @@ struct drm_i915_file_private {
#define HAS_PCH_CPT(dev) (INTEL_PCH_TYPE(dev) == PCH_CPT)
#define HAS_PCH_IBX(dev) (INTEL_PCH_TYPE(dev) == PCH_IBX)
+#define HAS_FORCE_WAKE(dev) (INTEL_INFO(dev)->has_force_wake)
+
#include "i915_trace.h"
/**
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c
b/drivers/gpu/drm/i915/intel_ringbuffer.c
index 89a5e7f..bdb37f2 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
@@ -266,10 +266,14 @@ u32 intel_ring_get_active_head(struct intel_ring_buffer
*ring)
static int init_ring_common(struct intel_ring_buffer *ring)
{
- drm_i915_private_t *dev_priv = ring->dev->dev_private;
+ struct drm_device *dev = ring->dev;
+ drm_i915_private_t *dev_priv = dev->dev_private;
struct drm_i915_gem_object *obj = ring->obj;
u32 head;
+ if (HAS_FORCE_WAKE(dev))
+ gen6_gt_force_wake_get(dev_priv);
+
/* Stop the ring if it's running. */
I915_WRITE_CTL(ring, 0);
I915_WRITE_HEAD(ring, 0);
@@ -328,6 +332,9 @@ stat
[PATCH] xHCI: Increase the timeout for controller save state operation
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 spec 4.23.2 says software should "Set the Controller Save State(CSS)
flag in the USBCMD register and wait for the Save State Status(SSS) flag
in the USBSTS register to transition to '0'". However, it does not define
how long software should wait for the SSS bit to transition to 0.
Currently the timeout is set to 1ms. There is bug report
(https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1002697)
indicates that the timeout is too short for ASMedia ASM1042 host controller
to save the state successfully. Increase the timeout to 10ms helps to
resolve the issue.
Signed-off-by: Andiry Xu
Cc: Ming Lei
Cc:
---
drivers/usb/host/xhci.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
index afdc73e..8d446af 100644
--- a/drivers/usb/host/xhci.c
+++ b/drivers/usb/host/xhci.c
@@ -795,7 +795,7 @@ int xhci_suspend(struct xhci_hcd *xhci)
command = xhci_readl(xhci, &xhci->op_regs->command);
command |= CMD_CSS;
xhci_writel(xhci, command, &xhci->op_regs->command);
- if (handshake(xhci, &xhci->op_regs->status, STS_SAVE, 0, 10*100)) {
+ if (handshake(xhci, &xhci->op_regs->status, STS_SAVE, 0, 100*100)) {
xhci_warn(xhci, "WARN: xHC CMD_CSS timeout\n");
spin_unlock_irq(&xhci->lock);
return -ETIMEDOUT;
--
1.7.4.1
--
To unsubscribe from this list: send the line "unsubscribe stable" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Intel-gfx] [PATCH] drm/i915: hold forcewake around ring hw init
Hi Daniel, please find a couple of comments inline.
BR,
Jani.
On Mon, 04 Jun 2012, Daniel Vetter 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
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@ -233,6 +233,7 @@ static const struct intel_device_info
> intel_sandybridge_d_info = {
> .has_blt_ring = 1,
> .has_llc = 1,
> .has_pch_split = 1,
> + .has_force_wake = 1
> };
Don't know if you care, but sticking a comma at the would avoid touching
the line the next time you need to add a field. Ditto below.
>
> static const struct intel_device_info intel_sandybridge_m_info = {
> @@ -243,6 +244,7 @@ static const struct intel_device_info
> intel_sandybridge_m_info = {
> .has_blt_ring = 1,
> .has_llc = 1,
> .has_pch_split = 1,
> + .has_force_wake = 1
> };
>
> static const struct intel_device_info intel_ivybridge_d_info = {
> @@ -252,6 +254,7 @@ static const struct intel_device_info
> intel_ivybridge_d_info = {
> .has_blt_ring = 1,
> .has_llc = 1,
> .has_pch_split = 1,
> + .has_force_wake = 1
> };
>
> static const struct intel_device_info intel_ivybridge_m_info = {
> @@ -262,6 +265,7 @@ static const struct intel_device_info
> intel_ivybridge_m_info = {
> .has_blt_ring = 1,
> .has_llc = 1,
> .has_pch_split = 1,
> + .has_force_wake = 1
> };
>
> static const struct intel_device_info intel_valleyview_m_info = {
> @@ -289,6 +293,7 @@ static const struct intel_device_info
> intel_haswell_d_info = {
> .has_blt_ring = 1,
> .has_llc = 1,
> .has_pch_split = 1,
> + .has_force_wake = 1
> };
>
> static const struct intel_device_info intel_haswell_m_info = {
> @@ -298,6 +303,7 @@ static const struct intel_device_info
> intel_haswell_m_info = {
> .has_blt_ring = 1,
> .has_llc = 1,
> .has_pch_split = 1,
> + .has_force_wake = 1
> };
>
[snip]
> diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c
> b/drivers/gpu/drm/i915/intel_ringbuffer.c
> index 89a5e7f..bdb37f2 100644
> --- a/drivers/gpu/drm/i915/intel_ringbuffer.c
> +++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
> @@ -266,10 +266,14 @@ u32 intel_ring_get_active_head(struct intel_ring_buffer
> *ring)
>
> static int init_ring_common(struct intel_ring_buffer *ring)
> {
> - drm_i915_private_t *dev_priv = ring->dev->dev_private;
> + struct drm_device *dev = ring->dev;
> + drm_i915_private_t *dev_priv = dev->dev_private;
> struct drm_i915_gem_object *obj = ring->obj;
> u32 head;
>
> + if (HAS_FORCE_WAKE(dev))
> + gen6_gt_force_wake_get(dev_priv);
> +
> /* Stop the ring if it's running. */
> I915_WRITE_CTL(ring, 0);
> I915_WRITE_HEAD(ring, 0);
> @@ -328,6 +332,9 @@ static int init_ring_common(struct intel_ring_buffer
> *ring)
> ring->space = ring_space(ring);
> }
>
Above, outside of patch context, there's an error code path with return
-EIO, which I think would leak dev_priv->forcewake_count.
> + if (HAS_FORCE_WAKE(dev))
> + gen6_gt_force_wake_put(dev_priv);
> +
> return 0;
> }
--
To unsubscribe from this list: send the line "unsubscribe stable" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Intel-gfx] [PATCH] drm/i915: hold forcewake around ring hw init
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 -- To unsubscribe from this list: send the line "unsubscribe stable" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] drm/i915: hold forcewake around ring hw init
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 again. Note that this is not the first such issue:
commit f01db988ef6f6c70a6cc36ee71e4a98a68901229
Author: Sean Paul
Date: Fri Mar 16 12:43:22 2012 -0400
drm/i915: Add wait_for in init_ring_common
added delay loops to make RING_START and RING_CTL initialization
reliable on the blt ring at boot-up. So I guess it won't hurt if we do
this unconditionally for all force_wake needing gpus.
To avoid copy&pasting of the HAS_FORCE_WAKE check I've added a new
intel_info bit for that.
v2: Fixup missing commas in static struct and properly handling the
error case in init_ring_common, both noticed by Jani Nikula.
Cc: stable@vger.kernel.org
Reported-by: Yang Guang
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=50522
Signed-Off-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_drv.c | 13 +
drivers/gpu/drm/i915/i915_drv.h |3 +++
drivers/gpu/drm/i915/intel_ringbuffer.c | 16 +---
3 files changed, 25 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 238a521..9fe9ebe 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -233,6 +233,7 @@ static const struct intel_device_info
intel_sandybridge_d_info = {
.has_blt_ring = 1,
.has_llc = 1,
.has_pch_split = 1,
+ .has_force_wake = 1,
};
static const struct intel_device_info intel_sandybridge_m_info = {
@@ -243,6 +244,7 @@ static const struct intel_device_info
intel_sandybridge_m_info = {
.has_blt_ring = 1,
.has_llc = 1,
.has_pch_split = 1,
+ .has_force_wake = 1,
};
static const struct intel_device_info intel_ivybridge_d_info = {
@@ -252,6 +254,7 @@ static const struct intel_device_info
intel_ivybridge_d_info = {
.has_blt_ring = 1,
.has_llc = 1,
.has_pch_split = 1,
+ .has_force_wake = 1,
};
static const struct intel_device_info intel_ivybridge_m_info = {
@@ -262,6 +265,7 @@ static const struct intel_device_info
intel_ivybridge_m_info = {
.has_blt_ring = 1,
.has_llc = 1,
.has_pch_split = 1,
+ .has_force_wake = 1,
};
static const struct intel_device_info intel_valleyview_m_info = {
@@ -289,6 +293,7 @@ static const struct intel_device_info intel_haswell_d_info
= {
.has_blt_ring = 1,
.has_llc = 1,
.has_pch_split = 1,
+ .has_force_wake = 1,
};
static const struct intel_device_info intel_haswell_m_info = {
@@ -298,6 +303,7 @@ static const struct intel_device_info intel_haswell_m_info
= {
.has_blt_ring = 1,
.has_llc = 1,
.has_pch_split = 1,
+ .has_force_wake = 1,
};
static const struct pci_device_id pciidlist[] = { /* aka */
@@ -1139,10 +1145,9 @@ MODULE_LICENSE("GPL and additional rights");
/* We give fast paths for the really cool registers */
#define NEEDS_FORCE_WAKE(dev_priv, reg) \
- (((dev_priv)->info->gen >= 6) && \
-((reg) < 0x4) &&\
-((reg) != FORCEWAKE)) && \
- (!IS_VALLEYVIEW((dev_priv)->dev))
+ ((HAS_FORCE_WAKE((dev_priv)->dev)) && \
+((reg) < 0x4) &&\
+((reg) != FORCEWAKE))
#define __i915_read(x, y) \
u##x i915_read##x(struct drm_i915_private *dev_priv, u32 reg) { \
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index ccabadd..7cc36db 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -285,6 +285,7 @@ struct intel_device_info {
u8 is_ivybridge:1;
u8 is_valleyview:1;
u8 has_pch_split:1;
+ u8 has_force_wake:1;
u8 is_haswell:1;
u8 has_fbc:1;
u8 has_pipe_cxsr:1;
@@ -1105,6 +1106,8 @@ struct drm_i915_file_private {
#define HAS_PCH_CPT(dev) (INTEL_PCH_TYPE(dev) == PCH_CPT)
#define HAS_PCH_IBX(dev) (INTEL_PCH_TYPE(dev) == PCH_IBX)
+#define HAS_FORCE_WAKE(dev) (INTEL_INFO(dev)->has_force_wake)
+
#include "i915_trace.h"
/**
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c
b/drivers/gpu/drm/i915/intel_ringbuffer.c
index 89a5e7f..0b172ee 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
@@ -266,10 +266,15 @@ u32 intel_ring_get_active_head(struct intel_ring_buffer
*ring)
static int init_ring_common(struct intel_ring_buffer *ring)
{
- drm_i915_private_t *dev_priv = ring->dev->dev_private;
+ struct drm_device *dev = ring->dev;
+ drm_i915_private_t *dev_priv = dev->dev_private;
struct drm_i915_gem_object *obj = ring->obj;
+ int ret = 0;
u32 head;
+ if (HAS_FORCE_WAKE(dev))
+ gen6_gt_
Re: [Intel-gfx] [PATCH] drm/i915: hold forcewake around ring hw init
On Mon, 4 Jun 2012 11:16:04 +0200, Daniel Vetter 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. Fwiw, the w/a looks harmless and is indeed advisable in cases where we do a lot of writes (which does not really seem to apply here!) Acked-by: Chris Wilson -Chris -- Chris Wilson, Intel Open Source Technology Centre -- To unsubscribe from this list: send the line "unsubscribe stable" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] drm/i915: hold forcewake around ring hw init
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 forcewake around this register init sequences makes chip reset
> reliable again. Note that this is not the first such issue:
>
> commit f01db988ef6f6c70a6cc36ee71e4a98a68901229
> Author: Sean Paul
> Date: Fri Mar 16 12:43:22 2012 -0400
>
> drm/i915: Add wait_for in init_ring_common
>
> added delay loops to make RING_START and RING_CTL initialization
> reliable on the blt ring at boot-up. So I guess it won't hurt if we do
> this unconditionally for all force_wake needing gpus.
>
> To avoid copy&pasting of the HAS_FORCE_WAKE check I've added a new
> intel_info bit for that.
>
> v2: Fixup missing commas in static struct and properly handling the
> error case in init_ring_common, both noticed by Jani Nikula.
>
> Cc: stable@vger.kernel.org
> Reported-by: Yang Guang
Now also tested-by, Yang confirmed that the new patch still works.
-Daniel
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=50522
> Signed-Off-by: Daniel Vetter
> ---
> drivers/gpu/drm/i915/i915_drv.c | 13 +
> drivers/gpu/drm/i915/i915_drv.h |3 +++
> drivers/gpu/drm/i915/intel_ringbuffer.c | 16 +---
> 3 files changed, 25 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
> index 238a521..9fe9ebe 100644
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@ -233,6 +233,7 @@ static const struct intel_device_info
> intel_sandybridge_d_info = {
> .has_blt_ring = 1,
> .has_llc = 1,
> .has_pch_split = 1,
> + .has_force_wake = 1,
> };
>
> static const struct intel_device_info intel_sandybridge_m_info = {
> @@ -243,6 +244,7 @@ static const struct intel_device_info
> intel_sandybridge_m_info = {
> .has_blt_ring = 1,
> .has_llc = 1,
> .has_pch_split = 1,
> + .has_force_wake = 1,
> };
>
> static const struct intel_device_info intel_ivybridge_d_info = {
> @@ -252,6 +254,7 @@ static const struct intel_device_info
> intel_ivybridge_d_info = {
> .has_blt_ring = 1,
> .has_llc = 1,
> .has_pch_split = 1,
> + .has_force_wake = 1,
> };
>
> static const struct intel_device_info intel_ivybridge_m_info = {
> @@ -262,6 +265,7 @@ static const struct intel_device_info
> intel_ivybridge_m_info = {
> .has_blt_ring = 1,
> .has_llc = 1,
> .has_pch_split = 1,
> + .has_force_wake = 1,
> };
>
> static const struct intel_device_info intel_valleyview_m_info = {
> @@ -289,6 +293,7 @@ static const struct intel_device_info
> intel_haswell_d_info = {
> .has_blt_ring = 1,
> .has_llc = 1,
> .has_pch_split = 1,
> + .has_force_wake = 1,
> };
>
> static const struct intel_device_info intel_haswell_m_info = {
> @@ -298,6 +303,7 @@ static const struct intel_device_info
> intel_haswell_m_info = {
> .has_blt_ring = 1,
> .has_llc = 1,
> .has_pch_split = 1,
> + .has_force_wake = 1,
> };
>
> static const struct pci_device_id pciidlist[] = {/* aka */
> @@ -1139,10 +1145,9 @@ MODULE_LICENSE("GPL and additional rights");
>
> /* We give fast paths for the really cool registers */
> #define NEEDS_FORCE_WAKE(dev_priv, reg) \
> - (((dev_priv)->info->gen >= 6) && \
> -((reg) < 0x4) &&\
> -((reg) != FORCEWAKE)) && \
> - (!IS_VALLEYVIEW((dev_priv)->dev))
> + ((HAS_FORCE_WAKE((dev_priv)->dev)) && \
> + ((reg) < 0x4) &&\
> + ((reg) != FORCEWAKE))
>
> #define __i915_read(x, y) \
> u##x i915_read##x(struct drm_i915_private *dev_priv, u32 reg) { \
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index ccabadd..7cc36db 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -285,6 +285,7 @@ struct intel_device_info {
> u8 is_ivybridge:1;
> u8 is_valleyview:1;
> u8 has_pch_split:1;
> + u8 has_force_wake:1;
> u8 is_haswell:1;
> u8 has_fbc:1;
> u8 has_pipe_cxsr:1;
> @@ -1105,6 +1106,8 @@ struct drm_i915_file_private {
> #define HAS_PCH_CPT(dev) (INTEL_PCH_TYPE(dev) == PCH_CPT)
> #define HAS_PCH_IBX(dev) (INTEL_PCH_TYPE(dev) == PCH_IBX)
>
> +#define HAS_FORCE_WAKE(dev) (INTEL_INFO(dev)->has_force_wake)
> +
> #include "i915_trace.h"
>
> /**
> diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c
> b/drivers/gpu/drm/i915/intel_ringbuffer.c
> index 89a5e7f..0b172ee 100644
> --- a/drivers/gpu/drm/i915/intel_ringbuffer.c
> +++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
> @@ -266,10 +266,15 @@ u32 intel_ring_get_active_head(struct intel_ring_buffer
> *ring)
>
> static int init_ring_common(struct i
Re: Linux on Hyper-V 1) cd006086fa5d ata_piix: defer disks to the Hyper-V drivers by default 2) db63a4c8115a libata: add a host flag to ignore detected ATA device FW: use hv_storvsc instead of ata_pii
Hi!
VVM > > > Hyper-V admins need _worked_ Linux v3.4.X / v3.3.X / v3.2.X
VVM > > >
VVM > > > Please, _fix_ errors related "use hv_storvsc instead of ata_piix to
VVM > > > handle 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!
Looking at the rules for stable tree patches,
this patch does not satisfy the requirement that the patch fix a bug
since we are changing the behavior here of the ata driver to accommodate
Hyper-V.
I don't know how much flexibility you have here for taking patches that improve
the general usability of Linux in different environments.
All I can say is that It will be nice to have this patch in previous stable
releases.
}
This is _real_ bug
{ P.S.
Dear K.Y., please read _again_ my letter
Sent: Monday, April 02, 2012 1:46 PM
}
Lots of things would be "nice",
but as this doesn't meet the stable_kernel_rules.txt rules, sorry, I can't take
them.
IMHO, patches "does meet the stable_kernel_rules.txt rules" by _all_ criterias
. . .
See info correlated with rules:
==
Rules on what kind of patches are accepted, and which ones are not, into the
"-stable" tree:
{
- It must be obviously correct and tested.
Tested ( but, in early implementaition): Ubuntu 12.04 + OpenSUSE
}
{
- It cannot be bigger than 100 lines, with context.
79 lines
+
47 lines
}
{
- It must fix only one thing.
Yes
}
{
- It must fix a real bug that bothers people (not a, "This could be a
problem..." type thing).
Is real bug: see URLs in my e-mails about problem
+ see tranlate from Russian language issue described by Maksim Kramarenko:
http://lists.debian.org/debian-russian/2012/01/msg00324.html
==
. . .
At the conclusion of the system through the halt or when sending a signal
shutdown by ACPI to power down the console
fell errors:
http://www.k-max.name/wp-content/uploads/2012/01/hyper-v.png
Errors do not interfere with work, but sneaking suspicion about future problems
with the hard drive ...
. . .
in general, the source of the problem as follows:
After [VVM: turn On in kernel source] Hyper-V modules [compile and start use], a hard disk was determined as 2 with the
same UUID.
. . .
Here are screenshots of what is happening:
connected to a drive:
http://www.k-max.name/wp-content/uploads/2012/01/hdd-e1327750214479.png
it is defined as a 2:
http://www.k-max.name/wp-content/uploads/2012/01/2hdd.png
Naturally, the same UUID:
http://www.k-max.name/wp-content/uploads/2012/01/blkid.png
That's what tells us the directory / dev:
http://www.k-max.name/wp-content/uploads/2012/01/uuid.png
==
}
{
- It must fix a problem that causes a build error (but not for things
marked CONFIG_BROKEN), an oops, a hang, data corruption, a real
security issue, or some "oh, that's not good" issue. In short, something
critical.
- New device IDs and quirks are also accepted.
not related this patch
}
{
- No "theoretical race condition" issues, unless an explanation of how the
race can be exploited is also provided.
- It cannot contain any "trivial" fixes in it (spelling changes,
whitespace cleanups, etc).
No "theoretical" , no "trivial"
}
- It must follow the Documentation/SubmittingPatches rules.
Prepare patches -- this job duty of Microsoft employee
- It or an equivalent fix must already exist in Linus' tree (upstream).
Yes
==
Best regards, Victor Miasnikov
Blog: http://vvm.blog.tut.by/
--
To unsubscribe from this list: send the line "unsubscribe stable" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Intel-gfx] [PATCH] drm/i915: hold forcewake around ring hw init
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 register init sequences makes chip reset
reliable again. Note that this is not the first such issue:
commit f01db988ef6f6c70a6cc36ee71e4a98a68901229
Author: Sean Paul
Date: Fri Mar 16 12:43:22 2012 -0400
drm/i915: Add wait_for in init_ring_common
added delay loops to make RING_START and RING_CTL initialization
reliable on the blt ring at boot-up. So I guess it won't hurt if we do
this unconditionally for all force_wake needing gpus.
To avoid copy&pasting of the HAS_FORCE_WAKE check I've added a new
intel_info bit for that.
v2: Fixup missing commas in static struct and properly handling the
error case in init_ring_common, both noticed by Jani Nikula.
Cc: stable@vger.kernel.org
Reported-by: Yang Guang
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=50522
Signed-Off-by: Daniel Vetter
The new .has_forcewake looks nice! Just one very tiny bikeshed below :).
Reviewed-by: Eugeni Dodonov
@@ -285,6 +285,7 @@ struct intel_device_info {
u8 is_ivybridge:1;
u8 is_valleyview:1;
u8 has_pch_split:1;
+ u8 has_force_wake:1;
u8 is_haswell:1;
u8 has_fbc:1;
u8 has_pipe_cxsr:1;
While you are on it, maybe it would make sense to move is_haswell up, so
all the 'is_*' and 'has_*' flags would stay together?
It is partly may fault though, due to the has_pch_split which ended up
in wrong place, but as you are touching those fields anyway, perhaps we
could rectify it for the future? :)
Eugeni
--
To unsubscribe from this list: send the line "unsubscribe stable" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: FAILED: patch "[PATCH] iwlwifi: fix the Transmit Frame Descriptor rings" failed to apply to 3.4-stable tree
> > > 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 . > > thanks, > > greg k-h > > -- original commit in Linus's tree -- > > From ebed633c61c023e5d1aa4ed159cd67406e9e37c2 Mon Sep 17 00:00:00 2001 > From: Emmanuel Grumbach > Date: Wed, 16 May 2012 22:35:58 +0200 > Subject: [PATCH] iwlwifi: fix the Transmit Frame Descriptor rings > > The logic that allows to have a short TFD queue was completely wrong. > We do maintain 256 Transmit Frame Descriptors, but they point to > recycled buffers. We used to attach and de-attach different TFDs for > the same buffer and it worked since they pointed to the same buffer. > > Also zero the number of BDs after unmapping a TFD. This seems not > necessary since we don't reclaim the same TFD twice, but I like > housekeeping. > I will rebase this patch on top of Linux-3.4.y as soon as it will compile for 32 bits. I am hitting this one: http://markmail.org/thread/ji2vcula6ikyifv3#query:+page:1+mid:ji2vcula6ikyifv3+state:results I have ld 2.20.51 which is ... ancient I know. - Intel Israel (74) Limited This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. -- To unsubscribe from this list: send the line "unsubscribe stable" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/3] ARM i.MX53: Fix PLL4 base address
MX53_DPLL4_BASE accidently returned the base address of PLL3. Fix this. Signed-off-by: Sascha Hauer 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 b/arch/arm/mach-imx/crm-regs-imx5.h index 5e11ba7..5e3f1f0 100644 --- a/arch/arm/mach-imx/crm-regs-imx5.h +++ b/arch/arm/mach-imx/crm-regs-imx5.h @@ -23,7 +23,7 @@ #define MX53_DPLL1_BASEMX53_IO_ADDRESS(MX53_PLL1_BASE_ADDR) #define MX53_DPLL2_BASEMX53_IO_ADDRESS(MX53_PLL2_BASE_ADDR) #define MX53_DPLL3_BASEMX53_IO_ADDRESS(MX53_PLL3_BASE_ADDR) -#define MX53_DPLL4_BASEMX53_IO_ADDRESS(MX53_PLL3_BASE_ADDR) +#define MX53_DPLL4_BASEMX53_IO_ADDRESS(MX53_PLL4_BASE_ADDR) /* PLL Register Offsets */ #define MXC_PLL_DP_CTL 0x00 -- 1.7.10 -- To unsubscribe from this list: send the line "unsubscribe stable" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: Linux on Hyper-V 1) cd006086fa5d ata_piix: defer disks to the Hyper-V drivers by default 2) db63a4c8115a libata: add a host flag to ignore detected ATA device FW: use hv_storvsc instead of ata_pii
> -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 disks to the > Hyper- > V drivers by default 2) db63a4c8115a libata: add a host flag to ignore > detected > ATA device FW: use hv_storvsc instead of ata_piix to handle the IDE disks > devices > ( but not for the ... > > Hi! > > VVM > > > Hyper-V admins need _worked_ Linux v3.4.X / v3.3.X / v3.2.X Victor, what distro are you using. 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 ata driver. Let me know. Regards, K. Y > -- To unsubscribe from this list: send the line "unsubscribe stable" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Linux on Hyper-V 1) cd006086fa5d ata_piix: defer disks to the Hyper-V drivers by default 2) db63a4c8115a libata: add a host flag to ignore detected ATA device FW: use hv_storvsc instead of ata_pii
Hi! VVM > > > Hyper-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 ata driver. K.Y.: Youre _theory_ ( about "can solve the issue on hand using modprobe rules") is wrong for: -- OpenSUSE -- Ubuntu -- Debian Why You think, what theory can solve problem in other case? How about LiveCD ? But "patch against the ata driver" -- solve problem 100% / 100% Best regards, Victor Miasnikov Blog: http://vvm.blog.tut.by/ P.S. Victor, what distro are you using. Let me know. But Hyper-V admins need "result" -- if You can fix _all_ what need by "modprobe rules" -- fix issue in: Kernel: 3.5 -- done 3.4.latest 3.3.latest 3.2.latest Distro: -- Arch Linux -- Chacra -- _all_ LiveCD -- Gentoo -- Debian -- Fedora -- To unsubscribe from this list: send the line "unsubscribe stable" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: Linux on Hyper-V 1) cd006086fa5d ata_piix: defer disks to the Hyper-V drivers by default 2) db63a4c8115a libata: add a host flag to ignore detected ATA device FW: use hv_storvsc instead of ata_pii
> -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 disks to the > Hyper- > V drivers by default 2) db63a4c8115a libata: add a host flag to ignore > detected > ATA device FW: use hv_storvsc instead of ata_piix to handle the IDE disks > devices > ( but not for the ... > > Hi! > > > VVM > > > Hyper-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 ata driver. > > K.Y.: Youre _theory_ ( about "can solve the issue on hand using modprobe > rules") is wrong for: As I said, if the ata_piix driver is a loadable module, we can solve the issue with modprobe rules. If it is not a loadable module we cannot obviously solve the problem with modprobe rules and we will need the ata patch. Regards, K. Y -- To unsubscribe from this list: send the line "unsubscribe stable" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] block: Move general unplug callback function from md/raid to blk-core
Other components may also require an unplug callback, so move this
function from md/raid to block generic layer.
Signed-off-by: Tao Guo
Cc: Neil Brown
Cc: Jens Axboe
Cc:
Cc: Andrew Morton
Cc:
---
block/blk-core.c | 36 -
block/blk-settings.c |1 +
block/blk.h|1 -
drivers/md/md.c| 51 ---
drivers/md/md.h|3 --
drivers/md/raid1.c |2 +-
drivers/md/raid5.c |4 +-
include/linux/blkdev.h |8 ++-
8 files changed, 51 insertions(+), 55 deletions(-)
diff --git a/block/blk-core.c b/block/blk-core.c
index 3c923a7..5639a3d 100644
--- a/block/blk-core.c
+++ b/block/blk-core.c
@@ -2840,6 +2840,39 @@ void blk_start_plug(struct blk_plug *plug)
}
EXPORT_SYMBOL(blk_start_plug);
+/* Check that an unplug wakeup will come shortly.
+ */
+bool blk_check_plugged(struct request_queue *q, plug_cb_fn cb_fn)
+{
+ struct blk_plug *plug = current->plug;
+ struct blk_plug_cb *cb;
+
+ if (!plug)
+ return false;
+
+ list_for_each_entry(cb, &plug->cb_list, list) {
+ if (cb->cb_fn == cb_fn && cb->q == q) {
+ /* Already on the list, move to top */
+ if (cb != list_first_entry(&plug->cb_list,
+ struct blk_plug_cb,
+ list))
+ list_move(&cb->list, &plug->cb_list);
+ return true;
+ }
+ }
+ /* Not currently on the callback list */
+ cb = kmalloc(sizeof(*cb), GFP_ATOMIC);
+ if (!cb)
+ return false;
+
+ cb->q = q;
+ cb->cb_fn = cb_fn;
+ atomic_inc(&q->plug_cnt);
+ list_add(&cb->list, &plug->cb_list);
+ return true;
+}
+EXPORT_SYMBOL(blk_check_plugged);
+
static int plug_rq_cmp(void *priv, struct list_head *a, struct list_head *b)
{
struct request *rqa = container_of(a, struct request, queuelist);
@@ -2897,7 +2930,8 @@ static void flush_plug_callbacks(struct blk_plug *plug)
struct blk_plug_cb,
list);
list_del(&cb->list);
- cb->callback(cb);
+ cb->cb_fn(cb);
+ kfree(cb);
}
}
diff --git a/block/blk-settings.c b/block/blk-settings.c
index d3234fc..c54d603 100644
--- a/block/blk-settings.c
+++ b/block/blk-settings.c
@@ -181,6 +181,7 @@ void blk_queue_make_request(struct request_queue *q,
make_request_fn *mfn)
blk_queue_dma_alignment(q, 511);
blk_queue_congestion_threshold(q);
q->nr_batching = BLK_BATCH_REQ;
+ atomic_set(&q->plug_cnt, 0);
blk_set_default_limits(&q->limits);
diff --git a/block/blk.h b/block/blk.h
index 85f6ae4..a62195b 100644
--- a/block/blk.h
+++ b/block/blk.h
@@ -33,7 +33,6 @@ bool __blk_end_bidi_request(struct request *rq, int error,
void blk_rq_timed_out_timer(unsigned long data);
void blk_delete_timer(struct request *);
void blk_add_timer(struct request *);
-void __generic_unplug_device(struct request_queue *);
/*
* Internal atomic flags for request handling
diff --git a/drivers/md/md.c b/drivers/md/md.c
index 1c2f904..08b64ef 100644
--- a/drivers/md/md.c
+++ b/drivers/md/md.c
@@ -498,25 +498,11 @@ void md_flush_request(struct mddev *mddev, struct bio
*bio)
}
EXPORT_SYMBOL(md_flush_request);
-/* Support for plugging.
- * This mirrors the plugging support in request_queue, but does not
- * require having a whole queue or request structures.
- * We allocate an md_plug_cb for each md device and each thread it gets
- * plugged on. This links tot the private plug_handle structure in the
- * personality data where we keep a count of the number of outstanding
- * plugs so other code can see if a plug is active.
- */
-struct md_plug_cb {
- struct blk_plug_cb cb;
- struct mddev *mddev;
-};
-
-static void plugger_unplug(struct blk_plug_cb *cb)
+static void mddev_unplug(struct blk_plug_cb *cb)
{
- struct md_plug_cb *mdcb = container_of(cb, struct md_plug_cb, cb);
- if (atomic_dec_and_test(&mdcb->mddev->plug_cnt))
- md_wakeup_thread(mdcb->mddev->thread);
- kfree(mdcb);
+ struct mddev *mddev = cb->q->queuedata;
+ if (atomic_dec_and_test(&cb->q->plug_cnt))
+ md_wakeup_thread(mddev->thread);
}
/* Check that an unplug wakeup will come shortly.
@@ -524,33 +510,7 @@ static void plugger_unplug(struct blk_plug_cb *cb)
*/
int mddev_check_plugged(struct mddev *mddev)
{
- struct blk_plug *plug = current->plug;
- struct md_plug_cb *mdcb;
-
- if (!plug)
- return 0;
-
- list_for_each_entry(mdcb, &plug->cb_list, cb.list) {
- if (mdcb->cb.callback == plugger_unplug &&
- mdcb->mddev
[PATCH 2/2] umem: fix up unplugging
In that patch, Jens removed the whole mm_unplug_device()
function, which used to be the trigger to make umem start to work.
We need to implement unplugging to make umem start to work, or I/O
will never be triggered.
Signed-off-by: Tao Guo
Cc: Neil Brown
Cc: Jens Axboe
Cc:
Cc: Andrew Morton
Cc:
---
drivers/block/umem.c | 11 +++
1 files changed, 11 insertions(+), 0 deletions(-)
diff --git a/drivers/block/umem.c b/drivers/block/umem.c
index aa27120..89cc9a6 100644
--- a/drivers/block/umem.c
+++ b/drivers/block/umem.c
@@ -513,6 +513,15 @@ static void process_page(unsigned long data)
}
}
+static void mm_unplug(struct blk_plug_cb *cb)
+{
+ struct cardinfo *card = cb->q->queuedata;
+
+ spin_lock_irq(&card->lock);
+ activate(card);
+ spin_unlock_irq(&card->lock);
+}
+
static void mm_make_request(struct request_queue *q, struct bio *bio)
{
struct cardinfo *card = q->queuedata;
@@ -523,6 +532,8 @@ static void mm_make_request(struct request_queue *q, struct
bio *bio)
*card->biotail = bio;
bio->bi_next = NULL;
card->biotail = &bio->bi_next;
+ if (bio->bi_rw & REQ_SYNC || !blk_check_plugged(q, mm_unplug))
+ activate(card);
spin_unlock_irq(&card->lock);
return;
--
1.7.7.6
--
To unsubscribe from this list: send the line "unsubscribe stable" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] umem: fix up unplugging
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 wrote:
> In that patch, Jens removed the whole mm_unplug_device()
> function, which used to be the trigger to make umem start to work.
>
> We need to implement unplugging to make umem start to work, or I/O
> will never be triggered.
>
> Signed-off-by: Tao Guo
> Cc: Neil Brown
> Cc: Jens Axboe
> Cc:
> Cc: Andrew Morton
> Cc:
> ---
> drivers/block/umem.c | 11 +++
> 1 files changed, 11 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/block/umem.c b/drivers/block/umem.c
> index aa27120..89cc9a6 100644
> --- a/drivers/block/umem.c
> +++ b/drivers/block/umem.c
> @@ -513,6 +513,15 @@ static void process_page(unsigned long data)
> }
> }
>
> +static void mm_unplug(struct blk_plug_cb *cb)
> +{
> + struct cardinfo *card = cb->q->queuedata;
> +
> + spin_lock_irq(&card->lock);
> + activate(card);
> + spin_unlock_irq(&card->lock);
> +}
> +
> static void mm_make_request(struct request_queue *q, struct bio *bio)
> {
> struct cardinfo *card = q->queuedata;
> @@ -523,6 +532,8 @@ static void mm_make_request(struct request_queue *q,
> struct bio *bio)
> *card->biotail = bio;
> bio->bi_next = NULL;
> card->biotail = &bio->bi_next;
> + if (bio->bi_rw & REQ_SYNC || !blk_check_plugged(q, mm_unplug))
> + activate(card);
> spin_unlock_irq(&card->lock);
>
> return;
> --
> 1.7.7.6
>
--
To unsubscribe from this list: send the line "unsubscribe stable" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ath9k: Fix a WARNING in suspend/resume with IBSS
Hi Johannes,
You could just remove the entire check since the interface combinations
you advertise don't allow it, I think? Or just fix those
combinations :-)
i did not check this before, thanks a lot for your inputs. will send a
proper v2 after checking this out.
If this is needed for stable, you might want to keep this patch& send
another one to remove it.
thanks Johannes.
i was looking at how to fix this properly in iface combination
advertised to mac80211. got few doubts regarding this
*if an interface type is not all advertised in the
ieee80211_iface_combination then it cannot it be co-existing with any
other interfaces ?
please let me know is there some other way do that.
if we advertise something like this
static const struct ieee80211_iface_limit if_limits[] = {
{set1
},
{set 2
},
};
then interface types in set1 and set2 co-exist as per the logic in
cfg80211_can_change_interface. is there already a way we can make
set1 and set2 interface types mutually exclusive ? thanks!
The sets are mutually exclusive, and there are implied sets of each
interface with a max number of 1. So for example, in iwlwifi we don't
advertise IBSS in the combinations at all, because it's not compatible
with anything. In your case, I think the same applies, since you said
if the first interface is ADHOC we cannot have any other
interface. we cannot add an ADHOC interface if there is already
an interface is present
Thus, if you leave IBSS out of the combinations you should get the
desired behaviour of not being able to combine IBSS with any other
types.
ath9k and also iwlwifi seems to have IBSS check not included in any of
the interface combinations, but still i am able to IBSS interface
atleast in ath9k with the checks removed in drv_add_interface.
it seems we are allowing any interface type to be added even if
its not added in the ieee80211_iface_combination structure.
i am sending an RFC to add this check in cfg80211 based on my
understanding. please review my understanding and any corrections
needed. thanks for your thoughts!
--
thanks,
shafi
--
To unsubscribe from this list: send the line "unsubscribe stable" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Linux on Hyper-V 1) cd006086fa5d ata_piix: defer disks to the Hyper-V drivers by default 2) db63a4c8115a libata: add a host flag to ignore detected ATA device FW: use hv_storvsc instead of ata_pii
Hi!
> VVM > > > Hyper-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 ata driver.
K.Y.: Youre _theory_ ( about "can solve the issue on hand using modprobe
rules") is wrong for:
As I said, if the ata_piix driver is a loadable module,
we can solve the issue with modprobe rules.
If it is not a loadable module we cannot obviously
solve the problem with modprobe rules
and we will need the ata patch.
Nothing new:
-- "the ata patch" is need, if we want worked 100% / 100% Linux on Hyper-V
-- "solve the problem with modprobe rules" very often not worked solution (
i.e. if the ata_piix driver . . . )
Total:
{
cd006086fa5d ata_piix: defer disks to the Hyper-V drivers by default
and its prerequisite
db63a4c8115a libata: add a host flag to ignore detected ATA devices
}
need be backported from
3.5
to
3.4.latest
3.3.latest
3.2.latest
Best regards, Victor Miasnikov
Blog: http://vvm.blog.tut.by/
P.S.
As I said, if the ata_piix driver is a loadable module,
we can solve the issue with modprobe rules.
We can test Youre theory:
- Original Message -
From: "Victor Miasnikov"
To: "KY Srinivasan"
Sent: Monday, June 04, 2012 6:50 PM
. . .
with use only "modprobe rules" prepare binary patch ( .xDelta) for
. . .
Goal: work in Hyper-V guest as ( ( Linux_Distib__Kernel_3.1_.iso ) + worked
mouse ) ) in LiveCD and after install
--
--
To unsubscribe from this list: send the line "unsubscribe stable" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[FIX][STABLE 3.3+][PATCH] drm/radeon/audio: don't hardcode CRTC id
This is based on info released by AMD, should allow using audio in much
more cases.
Signed-off-by: Rafał Miłecki
Cc:
---
drivers/gpu/drm/radeon/r600_audio.c |5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/radeon/r600_audio.c
b/drivers/gpu/drm/radeon/r600_audio.c
index 7c4fa77..7479a5c 100644
--- a/drivers/gpu/drm/radeon/r600_audio.c
+++ b/drivers/gpu/drm/radeon/r600_audio.c
@@ -192,6 +192,7 @@ void r600_audio_set_clock(struct drm_encoder *encoder, int
clock)
struct radeon_device *rdev = dev->dev_private;
struct radeon_encoder *radeon_encoder = to_radeon_encoder(encoder);
struct radeon_encoder_atom_dig *dig = radeon_encoder->enc_priv;
+ struct radeon_crtc *radeon_crtc = to_radeon_crtc(encoder->crtc);
int base_rate = 48000;
switch (radeon_encoder->encoder_id) {
@@ -217,8 +218,8 @@ void r600_audio_set_clock(struct drm_encoder *encoder, int
clock)
WREG32(EVERGREEN_AUDIO_PLL1_DIV, clock * 10);
WREG32(EVERGREEN_AUDIO_PLL1_UNK, 0x0071);
- /* Some magic trigger or src sel? */
- WREG32_P(0x5ac, 0x01, ~0x77);
+ /* Select DTO source */
+ WREG32(0x5ac, radeon_crtc->crtc_id);
} else {
switch (dig->dig_encoder) {
case 0:
--
1.7.7
--
To unsubscribe from this list: send the line "unsubscribe stable" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [FIX][STABLE 3.3+][PATCH] drm/radeon/audio: don't hardcode CRTC id
On Mon, Jun 4, 2012 at 12:36 PM, Rafał Miłecki wrote:
> This is based on info released by AMD, should allow using audio in much
> more cases.
>
> Signed-off-by: Rafał Miłecki
> Cc:
Reviewed-by: Alex Deucher
> ---
> drivers/gpu/drm/radeon/r600_audio.c | 5 +++--
> 1 files changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/r600_audio.c
> b/drivers/gpu/drm/radeon/r600_audio.c
> index 7c4fa77..7479a5c 100644
> --- a/drivers/gpu/drm/radeon/r600_audio.c
> +++ b/drivers/gpu/drm/radeon/r600_audio.c
> @@ -192,6 +192,7 @@ void r600_audio_set_clock(struct drm_encoder *encoder,
> int clock)
> struct radeon_device *rdev = dev->dev_private;
> struct radeon_encoder *radeon_encoder = to_radeon_encoder(encoder);
> struct radeon_encoder_atom_dig *dig = radeon_encoder->enc_priv;
> + struct radeon_crtc *radeon_crtc = to_radeon_crtc(encoder->crtc);
> int base_rate = 48000;
>
> switch (radeon_encoder->encoder_id) {
> @@ -217,8 +218,8 @@ void r600_audio_set_clock(struct drm_encoder *encoder,
> int clock)
> WREG32(EVERGREEN_AUDIO_PLL1_DIV, clock * 10);
> WREG32(EVERGREEN_AUDIO_PLL1_UNK, 0x0071);
>
> - /* Some magic trigger or src sel? */
> - WREG32_P(0x5ac, 0x01, ~0x77);
> + /* Select DTO source */
> + WREG32(0x5ac, radeon_crtc->crtc_id);
> } else {
> switch (dig->dig_encoder) {
> case 0:
> --
> 1.7.7
>
--
To unsubscribe from this list: send the line "unsubscribe stable" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Intel-gfx] [PATCH] drm/i915: hold forcewake around ring hw init
On Mon, Jun 04, 2012 at 09:47:54AM -0300, Eugeni Dodonov wrote: > 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 register init sequences makes chip reset > >reliable again. Note that this is not the first such issue: > > > >commit f01db988ef6f6c70a6cc36ee71e4a98a68901229 > >Author: Sean Paul > >Date: Fri Mar 16 12:43:22 2012 -0400 > > > > drm/i915: Add wait_for in init_ring_common > > > >added delay loops to make RING_START and RING_CTL initialization > >reliable on the blt ring at boot-up. So I guess it won't hurt if we do > >this unconditionally for all force_wake needing gpus. > > > >To avoid copy&pasting of the HAS_FORCE_WAKE check I've added a new > >intel_info bit for that. > > > >v2: Fixup missing commas in static struct and properly handling the > >error case in init_ring_common, both noticed by Jani Nikula. > > > >Cc: stable@vger.kernel.org > >Reported-by: Yang Guang > >Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=50522 > >Signed-Off-by: Daniel Vetter > > The new .has_forcewake looks nice! Just one very tiny bikeshed below :). > > Reviewed-by: Eugeni Dodonov Picked up for -fixes, thanks for the review. -Daniel -- Daniel Vetter Mail: dan...@ffwll.ch Mobile: +41 (0)79 365 57 48 -- To unsubscribe from this list: send the line "unsubscribe stable" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Linux 3.0.33
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: http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary thanks, greg k-h Documentation/HOWTO | 32 +++ Makefile |2 - arch/arm/include/asm/cacheflush.h |2 - arch/arm/kernel/traps.c |4 ++ arch/parisc/include/asm/prefetch.h|7 - arch/parisc/kernel/entry.S|4 ++ arch/parisc/kernel/pacache.S | 38 ++- arch/s390/mm/fault.c | 14 -- arch/sparc/Kconfig|3 ++ arch/sparc/kernel/systbls_64.S|2 - arch/tile/Kconfig |1 arch/tile/include/asm/bitops.h| 12 arch/um/include/asm/pgtable.h | 10 +-- arch/x86/kernel/cpu/mcheck/mce-severity.c | 16 +++ arch/x86/kernel/cpu/perf_event_amd.c | 11 +++- block/genhd.c | 10 --- drivers/ata/ahci.c|2 + drivers/gpu/drm/i915/i915_irq.c |9 ++ drivers/gpu/drm/i915/i915_reg.h | 15 ++ drivers/gpu/drm/i915/intel_display.c | 19 - drivers/gpu/drm/nouveau/nouveau_bo.c |2 - drivers/i2c/busses/i2c-davinci.c |2 - drivers/infiniband/hw/cxgb4/cm.c |6 drivers/isdn/gigaset/capi.c | 22 ++-- drivers/md/md.c |2 - drivers/media/dvb/siano/smsusb.c |2 + drivers/media/video/uvc/uvc_v4l2.c|2 - drivers/mmc/core/sdio.c |2 - drivers/mmc/core/sdio_irq.c | 11 +--- drivers/mtd/sm_ftl.c |2 - drivers/rtc/rtc-pl031.c | 18 + drivers/scsi/hpsa.c | 34 ++-- drivers/scsi/isci/init.c |2 - drivers/scsi/mpt2sas/mpt2sas_base.c |6 ++-- drivers/staging/comedi/comedi_fops.c |2 - drivers/tty/serial/mxs-auart.c|2 + drivers/tty/serial/serial_core.c |1 drivers/usb/class/cdc-wdm.c |2 - drivers/usb/core/devio.c | 33 ++-- drivers/usb/core/quirks.c |3 ++ drivers/usb/gadget/fsl_udc_core.c |2 + drivers/usb/host/ehci-pci.c |4 ++ drivers/usb/host/pci-quirks.c | 18 - drivers/usb/host/xhci-mem.c |1 drivers/usb/host/xhci-pci.c |1 drivers/usb/host/xhci-ring.c | 21 +-- drivers/usb/host/xhci.h |1 drivers/usb/misc/usbtest.c| 17 drivers/usb/serial/ftdi_sio.c |1 drivers/usb/serial/ftdi_sio_ids.h |8 + drivers/usb/serial/ti_usb_3410_5052.c |6 ++-- drivers/usb/serial/ti_usb_3410_5052.h |1 drivers/usb/storage/unusual_devs.h|7 + fs/aio.c | 30 ++--- fs/block_dev.c|6 ++-- fs/buffer.c |4 ++ include/linux/fs.h|1 include/linux/genhd.h |6 include/linux/mmc/host.h |2 + init/main.c |7 ++--- kernel/workqueue.c|9 +- mm/mempolicy.c| 41 -- net/wireless/reg.c| 10 +++ security/selinux/selinuxfs.c |1 tools/usb/ffs-test.c |2 - 65 files changed, 384 insertions(+), 192 deletions(-) Alan Cox (1): tty: Allow uart_register/unregister/register Alan Stern (1): usb-storage: unusual_devs entry for Yarvik PMP400 MP4 player Ben Widawsky (1): drm/i915: [GEN7] Use HW scheduler for fixed function shaders Bjørn Mork (1): USB: cdc-wdm: poll must return POLLHUP if device is gone Chris Metcalf (2): tilegx: enable SYSCALL_WRAPPERS support tile: fix bug where fls(0) was not returning 0 Chris Wilson (1): drm/i915: Avoid a double-read of PCH_IIR during interrupt handling Dan Williams (1): isci: fix oem parameter validation on single controller skus Daniel Vetter (1): drm/i915: don't clobber the pipe param in sanitize_modesetting Darren Hart (1): USB: serial: ti_usb_3410_5052: Add support for the FRI2 serial console Dave Airlie (1): no
Linux 3.3.8
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: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git linux-3.3.y and can be browsed at the normal kernel.org git web browser: http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary thanks, greg k-h Documentation/HOWTO | 32 - Makefile| 11 arch/arm/include/asm/cacheflush.h |2 arch/arm/kernel/traps.c |4 arch/parisc/include/asm/prefetch.h |7 arch/parisc/kernel/entry.S |4 arch/parisc/kernel/pacache.S| 38 - arch/powerpc/kernel/idle.c | 14 arch/s390/mm/fault.c| 14 arch/sparc/Kconfig |3 arch/sparc/kernel/systbls_64.S |2 arch/tile/Kconfig |1 arch/tile/include/asm/bitops.h | 12 arch/um/include/asm/pgtable.h | 10 arch/x86/Makefile |4 arch/x86/boot/compressed/Makefile |9 arch/x86/boot/compressed/relocs.c | 680 --- arch/x86/kernel/cpu/mcheck/mce-severity.c | 16 arch/x86/kernel/cpu/mcheck/mce.c|8 arch/x86/kernel/cpu/perf_event_amd.c| 11 arch/x86/pci/xen.c |4 arch/x86/tools/.gitignore |1 arch/x86/tools/Makefile |4 arch/x86/tools/relocs.c | 818 block/genhd.c | 10 drivers/ata/ahci.c |2 drivers/ata/libata-transport.c |1 drivers/gpio/gpio-mpc8xxx.c |3 drivers/gpu/drm/gma500/psb_device.c |6 drivers/gpu/drm/i915/i915_irq.c |9 drivers/gpu/drm/i915/i915_reg.h | 15 drivers/gpu/drm/i915/intel_display.c| 19 drivers/gpu/drm/nouveau/nouveau_bo.c|2 drivers/hid/hid-logitech-dj.c |5 drivers/hid/hid-wiimote-core.c | 16 drivers/hid/usbhid/hid-core.c | 61 +- drivers/i2c/busses/i2c-davinci.c|2 drivers/i2c/busses/i2c-tegra.c | 13 drivers/infiniband/core/umem.c |2 drivers/infiniband/hw/cxgb4/cm.c| 13 drivers/iommu/dmar.c|4 drivers/iommu/intel-iommu.c | 17 drivers/isdn/gigaset/capi.c | 22 drivers/md/md.c |2 drivers/md/raid0.c | 18 drivers/media/dvb/siano/smsusb.c|2 drivers/media/video/uvc/uvc_v4l2.c |2 drivers/mmc/core/cd-gpio.c |3 drivers/mmc/core/sdio.c |2 drivers/mmc/core/sdio_irq.c | 11 drivers/mmc/host/omap_hsmmc.c |2 drivers/mtd/sm_ftl.c|2 drivers/net/wireless/b43legacy/main.c |2 drivers/net/wireless/rtlwifi/pci.c | 17 drivers/net/wireless/rtlwifi/rtl8192de/sw.c |6 drivers/net/wireless/rtlwifi/usb.c | 12 drivers/regulator/core.c|2 drivers/rtc/rtc-pl031.c | 18 drivers/scsi/hpsa.c | 34 - drivers/scsi/isci/init.c|2 drivers/scsi/mpt2sas/mpt2sas_base.c |6 drivers/spi/spi-fsl-spi.c |6 drivers/staging/comedi/comedi_fops.c|2 drivers/tty/serial/8250/8250_pci.c | 18 drivers/tty/serial/mxs-auart.c |2 drivers/tty/serial/serial_core.c|1 drivers/usb/class/cdc-wdm.c |4 drivers/usb/core/devio.c| 33 - drivers/usb/core/hub.c |4 drivers/usb/core/quirks.c |3 drivers/usb/core/urb.c | 21 drivers/usb/gadget/fsl_udc_core.c |2 drivers/usb/host/ehci-pci.c |4 drivers/usb/host/ohci-at91.c| 11 drivers/usb/host/pci-quirks.c | 32 + drivers/usb/host/xhci-mem.c | 27 drivers/usb/host/xhci-pci.c |1 drivers/usb/host/xhci-ring.c| 21 drivers/usb/host/xhci.h |1 drivers/usb/misc/usbtest.c | 17 drivers/usb/serial/ftdi_sio.c |1 drivers/usb/serial/ftdi_sio_ids.h |8 drivers/usb/serial/ti_usb_3410_5052.c |6
Linux 3.4.1
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: http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary thanks, greg k-h Documentation/HOWTO | 32 +++ Makefile |2 arch/arm/boot/dts/tegra-cardhu.dts|2 arch/arm/include/asm/cacheflush.h |2 arch/arm/kernel/traps.c |4 + arch/powerpc/kernel/idle.c| 14 ++ arch/s390/mm/fault.c | 14 +- arch/sparc/Kconfig|3 + arch/sparc/kernel/systbls_64.S|2 arch/tile/include/asm/bitops.h| 12 ++--- arch/um/include/asm/pgtable.h | 10 +++- arch/x86/Makefile |1 arch/x86/kernel/cpu/mcheck/mce-severity.c | 16 --- arch/x86/kernel/cpu/mcheck/mce.c |8 +++ arch/x86/kernel/cpu/perf_event_amd.c | 11 - arch/x86/pci/xen.c|4 + arch/x86/tools/relocs.c | 12 + drivers/gpio/gpio-mpc8xxx.c |3 - drivers/gpu/drm/gma500/psb_device.c |6 +- drivers/gpu/drm/i915/i915_irq.c |9 +--- drivers/gpu/drm/i915/i915_reg.h | 15 +++ drivers/gpu/drm/i915/intel_display.c | 19 - drivers/gpu/drm/nouveau/nouveau_bo.c |2 drivers/hid/hid-logitech-dj.c |5 +- drivers/hid/hid-wiimote-core.c| 16 ++- drivers/hid/usbhid/hid-core.c | 61 +++--- drivers/i2c/busses/i2c-davinci.c |2 drivers/i2c/busses/i2c-tegra.c| 13 ++ drivers/infiniband/core/umem.c|2 drivers/infiniband/hw/cxgb4/cm.c | 13 +++--- drivers/iommu/dmar.c |4 - drivers/iommu/intel-iommu.c | 17 +--- drivers/isdn/gigaset/capi.c | 26 ++-- drivers/isdn/gigaset/ev-layer.c |4 + drivers/md/md.c |2 drivers/media/dvb/siano/smsusb.c |2 drivers/media/video/uvc/uvc_v4l2.c|2 drivers/mmc/core/cd-gpio.c|3 + drivers/mmc/core/sdio.c |2 drivers/mmc/core/sdio_irq.c | 11 +++-- drivers/mmc/host/omap_hsmmc.c |2 drivers/net/wireless/b43legacy/main.c |2 drivers/regulator/core.c |2 drivers/scsi/isci/init.c |2 drivers/scsi/mpt2sas/mpt2sas_base.c |6 +- drivers/spi/spi-fsl-spi.c |2 drivers/staging/android/persistent_ram.c | 19 - drivers/staging/comedi/comedi_fops.c |2 drivers/tty/hvc/hvc_xen.c |4 - drivers/tty/serial/8250/8250.c|9 ++-- drivers/tty/serial/8250/8250_pci.c| 18 drivers/tty/serial/mxs-auart.c|2 drivers/tty/serial/serial_core.c |1 drivers/usb/class/cdc-wdm.c | 31 ++- drivers/usb/core/devio.c | 33 drivers/usb/core/hub.c|4 + drivers/usb/core/quirks.c |3 + drivers/usb/core/urb.c| 21 ++ drivers/usb/gadget/fsl_udc_core.c |2 drivers/usb/host/ehci-omap.c | 18 drivers/usb/host/ehci-pci.c |4 + drivers/usb/host/ehci-platform.c |2 drivers/usb/host/ohci-at91.c | 11 - drivers/usb/host/pci-quirks.c | 32 +++ drivers/usb/host/xhci-hub.c | 22 +- drivers/usb/host/xhci-mem.c | 27 + drivers/usb/host/xhci-pci.c |1 drivers/usb/host/xhci-ring.c | 22 +- drivers/usb/host/xhci.c | 12 - drivers/usb/host/xhci.h |3 + drivers/usb/misc/usbtest.c| 17 +--- drivers/usb/otg/gpio_vbus.c |8 +-- drivers/usb/serial/ftdi_sio.c |1 drivers/usb/serial/ftdi_sio_ids.h |8 +++ drivers/usb/serial/ti_usb_3410_5052.c |6 +- drivers/usb/serial/ti_usb_3410_5052.h |1 drivers/usb/serial/usb-serial.c |9 +++- drivers/usb/storage/unusual_devs.h|7 +++ drivers/video/sh_mobile_lcdcfb.c |5 +- drivers/video/sh_mobile_lcdcfb.h |1 drivers/xen/events.c |5 +- fs/aio.c | 30 ++ include/linux/mmc/host.h |2 include/linux
Linux 3.2.19
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: http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git Ben. Documentation/HOWTO| 32 +- Makefile | 11 +- arch/arm/include/asm/cacheflush.h |2 +- arch/arm/kernel/traps.c|4 +- arch/ia64/kvm/kvm-ia64.c |5 + arch/parisc/include/asm/prefetch.h |7 +- arch/parisc/kernel/entry.S |4 + arch/parisc/kernel/pacache.S | 38 +- arch/s390/kvm/intercept.c | 20 +- arch/s390/kvm/kvm-s390.c |2 +- arch/s390/mm/fault.c | 14 +- arch/sparc/Kconfig |3 + arch/sparc/kernel/systbls_64.S |2 +- arch/tile/Kconfig |3 +- arch/tile/include/asm/bitops.h | 12 +- arch/um/include/asm/pgtable.h | 10 +- arch/x86/Makefile |4 + arch/x86/boot/compressed/Makefile |9 +- arch/x86/boot/compressed/relocs.c | 680 arch/x86/kernel/cpu/mcheck/mce-severity.c | 16 +- arch/x86/kernel/cpu/mcheck/mce.c |8 + arch/x86/kernel/cpu/perf_event_amd.c | 11 +- arch/x86/kvm/vmx.c |4 +- arch/x86/kvm/x86.c |8 + arch/x86/pci/xen.c |4 + arch/x86/tools/.gitignore |1 + arch/x86/tools/Makefile|3 + arch/x86/tools/relocs.c| 820 block/genhd.c | 10 +- drivers/acpi/sleep.c |8 + drivers/ata/ahci.c |2 + drivers/gpio/gpio-mpc8xxx.c|3 +- drivers/gpu/drm/i915/i915_irq.c|9 +- drivers/gpu/drm/i915/i915_reg.h| 15 + drivers/gpu/drm/i915/intel_display.c | 19 +- drivers/gpu/drm/nouveau/nouveau_bo.c |2 +- drivers/hid/hid-logitech-dj.c |5 +- drivers/hid/hid-wiimote.c | 16 +- drivers/i2c/busses/i2c-davinci.c |2 +- drivers/i2c/busses/i2c-eg20t.c |2 +- drivers/i2c/busses/i2c-tegra.c | 13 +- drivers/infiniband/core/umem.c |2 +- drivers/infiniband/hw/cxgb4/cm.c | 11 +- drivers/input/tablet/wacom_wac.c |7 +- drivers/iommu/dmar.c |4 +- drivers/iommu/intel-iommu.c| 17 +- drivers/isdn/gigaset/capi.c| 26 +- drivers/isdn/gigaset/ev-layer.c|4 +- drivers/md/md.c|2 +- drivers/media/dvb/siano/smsusb.c |2 + drivers/media/video/uvc/uvc_v4l2.c |2 +- drivers/mmc/core/sdio.c|2 +- drivers/mmc/core/sdio_irq.c| 11 +- drivers/mtd/sm_ftl.c |2 +- drivers/net/ethernet/dlink/dl2k.c | 52 +- drivers/net/ethernet/dlink/dl2k.h |7 - drivers/net/ethernet/emulex/benet/be_ethtool.c |6 +- drivers/net/wireless/b43legacy/main.c |2 - drivers/net/wireless/rtlwifi/usb.c | 34 +- drivers/net/wireless/rtlwifi/wifi.h|6 +- drivers/platform/x86/sony-laptop.c |2 +- drivers/regulator/core.c |2 + drivers/rtc/rtc-pl031.c| 18 + drivers/scsi/hpsa.c| 38 +- drivers/scsi/isci/init.c |2 +- drivers/scsi/mpt2sas/mpt2sas_base.c|6 +- drivers/spi/spi-fsl-spi.c |2 +- drivers/staging/comedi/comedi_fops.c |2 +- drivers/tty/serial/8250.c |9 +- drivers/tty/serial/8250_pci.c | 18 + drivers/tty/serial/mxs-auart.c |2 + drivers/tty/serial/serial_core.c |1 + drivers/usb/class/cdc-wdm.c| 21 +- drivers/usb/core/devio.c | 33 +- drivers/usb/core/hub.c |4 + drivers/usb/core/quirks.c |3 + drivers/usb/core/usb.h | 14 - drivers/usb/gadget/fsl_udc_core.c |2 + drivers/usb/host/ehci-pci.c|4 +- drivers
Re: [PATCH 1/2] block: Move general unplug callback function from md/raid to blk-core
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 unplug, just do in it. -- To unsubscribe from this list: send the line "unsubscribe stable" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 1/2] block: Move general unplug callback function from md/raid to blk-core
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 each request_queue? Thanks, -Tao > -Original Message- > From: Shaohua Li [mailto:shliker...@gmail.com] On Behalf Of Shaohua Li > Sent: Tuesday, June 05, 2012 9:21 AM > To: Tao Guo > Cc: linux-ker...@vger.kernel.org; Guo, Tao; Neil Brown; Jens Axboe; > stable@vger.kernel.org; Andrew Morton > Subject: Re: [PATCH 1/2] block: Move general unplug callback function > from md/raid to blk-core > > 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 unplug, just do in it. -- To unsubscribe from this list: send the line "unsubscribe stable" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] powerpc/ftrace: Do not trace restore_interrupts()
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 following process to bisect to find the culprit:
>
> cat /debug/tracing/available_filter_functions > t
> num=`wc -l t`
> sed -ne "1,${num}p" t > t1
> let num=num+1
> sed -ne "${num},$p" t > t2
> cat t1 > /debug/tracing/set_ftrace_filter
> echo function /debug/tracing/current_tracer
>
>
> It finally came down to this function: restore_interrupts()
>
> I'm not sure why this locks up the system. It just seems to prevent
> scheduling from occurring. Interrupts seem to still work, as I can ping
> the box. But all user processes freeze.
>
> When restore_interrupts() is not traced, function tracing works fine.
>
> Cc: sta...@kernel.org
This is what I get for cut-and-pasting from a random git commit. That
should be:
Cc: stable@vger.kernel.org
-- Steve
> Signed-off-by: Steven Rostedt
>
> diff --git a/arch/powerpc/kernel/irq.c b/arch/powerpc/kernel/irq.c
> index 641da9e..64eec59 100644
> --- a/arch/powerpc/kernel/irq.c
> +++ b/arch/powerpc/kernel/irq.c
> @@ -277,7 +277,7 @@ EXPORT_SYMBOL(arch_local_irq_restore);
> * NOTE: This is called with interrupts hard disabled but not marked
> * as such in paca->irq_happened, so we need to resync this.
> */
> -void restore_interrupts(void)
> +void notrace restore_interrupts(void)
> {
> if (irqs_disabled()) {
> local_paca->irq_happened |= PACA_IRQ_HARD_DIS;
>
--
To unsubscribe from this list: send the line "unsubscribe stable" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] ata_piix: defer disks to the Hyper-V drivers by default
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 or when sending a >> signal shutdown by ACPI to power down the console fell errors: >> http://www.k-max.name/wp-content/uploads/2012/01/hyper-v.png [That image shows the message exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0 ata1.00: failed command: STANDBY IMMEDIATE ] >> Errors do not interfere with work, but sneaking suspicion about >> future problems with the hard drive ... [...] >> in general, the source of the problem as follows: >> After [VVM: turn On in kernel source] Hyper-V modules [compile and >> start use], a hard disk was determined as 2 with the same UUID. [...] >> connected to a drive: >> http://www.k-max.name/wp-content/uploads/2012/01/hdd-e1327750214479.png >> it is defined as a 2: >> http://www.k-max.name/wp-content/uploads/2012/01/2hdd.png >> Naturally, the same UUID: >> http://www.k-max.name/wp-content/uploads/2012/01/blkid.png >> That's what tells us the directory / dev: >> http://www.k-max.name/wp-content/uploads/2012/01/uuid.png Thanks --- I think this is what Greg was asking for. If I understand correctly, the problem is that ata_piix and hv_storvsc both claim the (virtual) hard disk. That sounds worth fixing. The patch works by making ata_piix skip the disk during enumeration if hv_storvsc is enabled as a built-in driver or module. A workaround is to blacklist the ata_piix module. However, that means losing access to CD and DVD drives which are exposed by ata_piix and not hv_storvsc. Hoping that clarifies, Jonathan -- To unsubscribe from this list: send the line "unsubscribe stable" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Patch "ext4: add missing save_error_info() to ext4_error()" has been added to the 3.0-stable tree
This is a note to let you know that I've just added the patch titled ext4: add missing save_error_info() to ext4_error() to the 3.0-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary The filename of the patch is: ext4-add-missing-save_error_info-to-ext4_error.patch and it can be found in the queue-3.0 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let know about it. >From f3fc0210c0fc91900766c995f089c39170e68305 Mon Sep 17 00:00:00 2001 From: Theodore Ts'o Date: Wed, 30 May 2012 23:00:16 -0400 Subject: ext4: add missing save_error_info() to ext4_error() From: Theodore Ts'o commit f3fc0210c0fc91900766c995f089c39170e68305 upstream. The ext4_error() function is missing a call to save_error_info(). Since this is the function which marks the file system as containing an error, this oversight (which was introduced in 2.6.36) is quite significant, and should be backported to older stable kernels with high urgency. Reported-by: Ken Sumrall Signed-off-by: "Theodore Ts'o" Cc: ksumr...@google.com Signed-off-by: Greg Kroah-Hartman --- fs/ext4/super.c |1 + 1 file changed, 1 insertion(+) --- a/fs/ext4/super.c +++ b/fs/ext4/super.c @@ -433,6 +433,7 @@ void __ext4_error(struct super_block *sb printk(KERN_CRIT "EXT4-fs error (device %s): %s:%d: comm %s: %pV\n", sb->s_id, function, line, current->comm, &vaf); va_end(args); + save_error_info(sb, function, line); ext4_handle_error(sb); } Patches currently in stable-queue which might be from ty...@mit.edu are queue-3.0/ext4-add-ext4_mb_unload_buddy-in-the-error-path.patch queue-3.0/ext4-force-ro-mount-if-ext4_setup_super-fails.patch queue-3.0/ext4-remove-mb_groups-before-tearing-down-the-buddy_cache.patch queue-3.0/ext4-add-missing-save_error_info-to-ext4_error.patch queue-3.0/ext4-don-t-trash-state-flags-in-ext4_ioc_setflags.patch -- To unsubscribe from this list: send the line "unsubscribe stable" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Patch "ext4: add ext4_mb_unload_buddy in the error path" has been added to the 3.0-stable tree
This is a note to let you know that I've just added the patch titled
ext4: add ext4_mb_unload_buddy in the error path
to the 3.0-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
ext4-add-ext4_mb_unload_buddy-in-the-error-path.patch
and it can be found in the queue-3.0 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let know about it.
>From 02b7831019ea4e7994968c84b5826fa8b248ffc8 Mon Sep 17 00:00:00 2001
From: Salman Qazi
Date: Thu, 31 May 2012 23:51:27 -0400
Subject: ext4: add ext4_mb_unload_buddy in the error path
From: Salman Qazi
commit 02b7831019ea4e7994968c84b5826fa8b248ffc8 upstream.
ext4_free_blocks fails to pair an ext4_mb_load_buddy with a matching
ext4_mb_unload_buddy when it fails a memory allocation.
Signed-off-by: Salman Qazi
Signed-off-by: "Theodore Ts'o"
Signed-off-by: Greg Kroah-Hartman
---
fs/ext4/mballoc.c |1 +
1 file changed, 1 insertion(+)
--- a/fs/ext4/mballoc.c
+++ b/fs/ext4/mballoc.c
@@ -4583,6 +4583,7 @@ do_more:
*/
new_entry = kmem_cache_alloc(ext4_free_ext_cachep, GFP_NOFS);
if (!new_entry) {
+ ext4_mb_unload_buddy(&e4b);
err = -ENOMEM;
goto error_return;
}
Patches currently in stable-queue which might be from sq...@google.com are
queue-3.0/ext4-add-ext4_mb_unload_buddy-in-the-error-path.patch
queue-3.0/ext4-remove-mb_groups-before-tearing-down-the-buddy_cache.patch
--
To unsubscribe from this list: send the line "unsubscribe stable" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Patch "ext4: don't trash state flags in EXT4_IOC_SETFLAGS" has been added to the 3.0-stable tree
This is a note to let you know that I've just added the patch titled
ext4: don't trash state flags in EXT4_IOC_SETFLAGS
to the 3.0-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
ext4-don-t-trash-state-flags-in-ext4_ioc_setflags.patch
and it can be found in the queue-3.0 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let know about it.
>From 79906964a187c405db72a3abc60eb9b50d804fbc Mon Sep 17 00:00:00 2001
From: Theodore Ts'o
Date: Thu, 31 May 2012 23:46:01 -0400
Subject: ext4: don't trash state flags in EXT4_IOC_SETFLAGS
From: Theodore Ts'o
commit 79906964a187c405db72a3abc60eb9b50d804fbc upstream.
In commit 353eb83c we removed i_state_flags with 64-bit longs, But
when handling the EXT4_IOC_SETFLAGS ioctl, we replace i_flags
directly, which trashes the state flags which are stored in the high
32-bits of i_flags on 64-bit platforms. So use the the
ext4_{set,clear}_inode_flags() functions which use atomic bit
manipulation functions instead.
Reported-by: Tao Ma
Signed-off-by: "Theodore Ts'o"
Signed-off-by: Greg Kroah-Hartman
---
fs/ext4/ioctl.c | 12 +---
1 file changed, 9 insertions(+), 3 deletions(-)
--- a/fs/ext4/ioctl.c
+++ b/fs/ext4/ioctl.c
@@ -35,7 +35,7 @@ long ext4_ioctl(struct file *filp, unsig
handle_t *handle = NULL;
int err, migrate = 0;
struct ext4_iloc iloc;
- unsigned int oldflags;
+ unsigned int oldflags, mask, i;
unsigned int jflag;
if (!inode_owner_or_capable(inode))
@@ -112,8 +112,14 @@ long ext4_ioctl(struct file *filp, unsig
if (err)
goto flags_err;
- flags = flags & EXT4_FL_USER_MODIFIABLE;
- flags |= oldflags & ~EXT4_FL_USER_MODIFIABLE;
+ for (i = 0, mask = 1; i < 32; i++, mask <<= 1) {
+ if (!(mask & EXT4_FL_USER_MODIFIABLE))
+ continue;
+ if (mask & flags)
+ ext4_set_inode_flag(inode, i);
+ else
+ ext4_clear_inode_flag(inode, i);
+ }
ei->i_flags = flags;
ext4_set_inode_flags(inode);
Patches currently in stable-queue which might be from ty...@mit.edu are
queue-3.0/ext4-add-ext4_mb_unload_buddy-in-the-error-path.patch
queue-3.0/ext4-force-ro-mount-if-ext4_setup_super-fails.patch
queue-3.0/ext4-remove-mb_groups-before-tearing-down-the-buddy_cache.patch
queue-3.0/ext4-add-missing-save_error_info-to-ext4_error.patch
queue-3.0/ext4-don-t-trash-state-flags-in-ext4_ioc_setflags.patch
--
To unsubscribe from this list: send the line "unsubscribe stable" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Patch "ext4: force ro mount if ext4_setup_super() fails" has been added to the 3.0-stable tree
This is a note to let you know that I've just added the patch titled
ext4: force ro mount if ext4_setup_super() fails
to the 3.0-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
ext4-force-ro-mount-if-ext4_setup_super-fails.patch
and it can be found in the queue-3.0 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let know about it.
>From 7e84b6216467b84cd332c8e567bf5aa113fd2f38 Mon Sep 17 00:00:00 2001
From: Eric Sandeen
Date: Mon, 28 May 2012 14:17:25 -0400
Subject: ext4: force ro mount if ext4_setup_super() fails
From: Eric Sandeen
commit 7e84b6216467b84cd332c8e567bf5aa113fd2f38 upstream.
If ext4_setup_super() fails i.e. due to a too-high revision,
the error is logged in dmesg but the fs is not mounted RO as
indicated.
Tested by:
# mkfs.ext4 -r 4 /dev/sdb6
# mount /dev/sdb6 /mnt/test
# dmesg | grep "too high"
[164919.759248] EXT4-fs (sdb6): revision level too high, forcing read-only mode
# grep sdb6 /proc/mounts
/dev/sdb6 /mnt/test2 ext4 rw,seclabel,relatime,data=ordered 0 0
Reviewed-by: Andreas Dilger
Signed-off-by: Eric Sandeen
Signed-off-by: "Theodore Ts'o"
Signed-off-by: Greg Kroah-Hartman
---
fs/ext4/super.c |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- a/fs/ext4/super.c
+++ b/fs/ext4/super.c
@@ -3618,7 +3618,8 @@ no_journal:
goto failed_mount4;
}
- ext4_setup_super(sb, es, sb->s_flags & MS_RDONLY);
+ if (ext4_setup_super(sb, es, sb->s_flags & MS_RDONLY))
+ sb->s_flags |= MS_RDONLY;
/* determine the minimum size of new large inodes, if present */
if (sbi->s_inode_size > EXT4_GOOD_OLD_INODE_SIZE) {
Patches currently in stable-queue which might be from sand...@redhat.com are
queue-3.0/ext4-force-ro-mount-if-ext4_setup_super-fails.patch
--
To unsubscribe from this list: send the line "unsubscribe stable" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Patch "ext4: remove mb_groups before tearing down the buddy_cache" has been added to the 3.0-stable tree
This is a note to let you know that I've just added the patch titled
ext4: remove mb_groups before tearing down the buddy_cache
to the 3.0-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
ext4-remove-mb_groups-before-tearing-down-the-buddy_cache.patch
and it can be found in the queue-3.0 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let know about it.
>From 95599968d19db175829fb580baa6b68939b320fb Mon Sep 17 00:00:00 2001
From: Salman Qazi
Date: Thu, 31 May 2012 23:52:14 -0400
Subject: ext4: remove mb_groups before tearing down the buddy_cache
From: Salman Qazi
commit 95599968d19db175829fb580baa6b68939b320fb upstream.
We can't have references held on pages in the s_buddy_cache while we are
trying to truncate its pages and put the inode. All the pages must be
gone before we reach clear_inode. This can only be gauranteed if we
can prevent new users from grabbing references to s_buddy_cache's pages.
The original bug can be reproduced and the bug fix can be verified by:
while true; do mount -t ext4 /dev/ram0 /export/hda3/ram0; \
umount /export/hda3/ram0; done &
while true; do cat /proc/fs/ext4/ram0/mb_groups; done
Signed-off-by: Salman Qazi
Signed-off-by: "Theodore Ts'o"
Signed-off-by: Greg Kroah-Hartman
---
fs/ext4/mballoc.c |5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
--- a/fs/ext4/mballoc.c
+++ b/fs/ext4/mballoc.c
@@ -2528,6 +2528,9 @@ int ext4_mb_release(struct super_block *
struct ext4_sb_info *sbi = EXT4_SB(sb);
struct kmem_cache *cachep = get_groupinfo_cache(sb->s_blocksize_bits);
+ if (sbi->s_proc)
+ remove_proc_entry("mb_groups", sbi->s_proc);
+
if (sbi->s_group_info) {
for (i = 0; i < ngroups; i++) {
grinfo = ext4_get_group_info(sb, i);
@@ -2575,8 +2578,6 @@ int ext4_mb_release(struct super_block *
}
free_percpu(sbi->s_locality_groups);
- if (sbi->s_proc)
- remove_proc_entry("mb_groups", sbi->s_proc);
return 0;
}
Patches currently in stable-queue which might be from sq...@google.com are
queue-3.0/ext4-add-ext4_mb_unload_buddy-in-the-error-path.patch
queue-3.0/ext4-remove-mb_groups-before-tearing-down-the-buddy_cache.patch
--
To unsubscribe from this list: send the line "unsubscribe stable" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Patch "ext4: add ext4_mb_unload_buddy in the error path" has been added to the 3.4-stable tree
This is a note to let you know that I've just added the patch titled
ext4: add ext4_mb_unload_buddy in the error path
to the 3.4-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
ext4-add-ext4_mb_unload_buddy-in-the-error-path.patch
and it can be found in the queue-3.4 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let know about it.
>From 02b7831019ea4e7994968c84b5826fa8b248ffc8 Mon Sep 17 00:00:00 2001
From: Salman Qazi
Date: Thu, 31 May 2012 23:51:27 -0400
Subject: ext4: add ext4_mb_unload_buddy in the error path
From: Salman Qazi
commit 02b7831019ea4e7994968c84b5826fa8b248ffc8 upstream.
ext4_free_blocks fails to pair an ext4_mb_load_buddy with a matching
ext4_mb_unload_buddy when it fails a memory allocation.
Signed-off-by: Salman Qazi
Signed-off-by: "Theodore Ts'o"
Signed-off-by: Greg Kroah-Hartman
---
fs/ext4/mballoc.c |1 +
1 file changed, 1 insertion(+)
--- a/fs/ext4/mballoc.c
+++ b/fs/ext4/mballoc.c
@@ -4636,6 +4636,7 @@ do_more:
*/
new_entry = kmem_cache_alloc(ext4_free_data_cachep, GFP_NOFS);
if (!new_entry) {
+ ext4_mb_unload_buddy(&e4b);
err = -ENOMEM;
goto error_return;
}
Patches currently in stable-queue which might be from sq...@google.com are
queue-3.4/ext4-add-ext4_mb_unload_buddy-in-the-error-path.patch
queue-3.4/ext4-remove-mb_groups-before-tearing-down-the-buddy_cache.patch
--
To unsubscribe from this list: send the line "unsubscribe stable" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Patch "ext4: disallow hard-linked directory in ext4_lookup" has been added to the 3.4-stable tree
This is a note to let you know that I've just added the patch titled
ext4: disallow hard-linked directory in ext4_lookup
to the 3.4-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
ext4-disallow-hard-linked-directory-in-ext4_lookup.patch
and it can be found in the queue-3.4 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let know about it.
>From 7e936b737211e6b54e34b71a827e56b872e958d8 Mon Sep 17 00:00:00 2001
From: Andreas Dilger
Date: Mon, 28 May 2012 17:02:25 -0400
Subject: ext4: disallow hard-linked directory in ext4_lookup
From: Andreas Dilger
commit 7e936b737211e6b54e34b71a827e56b872e958d8 upstream.
A hard-linked directory to its parent can cause the VFS to deadlock,
and is a sign of a corrupted file system. So detect this case in
ext4_lookup(), before the rmdir() lockup scenario can take place.
Signed-off-by: Andreas Dilger
Signed-off-by: "Theodore Ts'o"
Signed-off-by: Greg Kroah-Hartman
---
fs/ext4/namei.c |6 ++
1 file changed, 6 insertions(+)
--- a/fs/ext4/namei.c
+++ b/fs/ext4/namei.c
@@ -1037,6 +1037,12 @@ static struct dentry *ext4_lookup(struct
EXT4_ERROR_INODE(dir, "bad inode number: %u", ino);
return ERR_PTR(-EIO);
}
+ if (unlikely(ino == dir->i_ino)) {
+ EXT4_ERROR_INODE(dir, "'%.*s' linked to parent dir",
+dentry->d_name.len,
+dentry->d_name.name);
+ return ERR_PTR(-EIO);
+ }
inode = ext4_iget(dir->i_sb, ino);
if (inode == ERR_PTR(-ESTALE)) {
EXT4_ERROR_INODE(dir,
Patches currently in stable-queue which might be from adil...@dilger.ca are
queue-3.4/ext4-disallow-hard-linked-directory-in-ext4_lookup.patch
--
To unsubscribe from this list: send the line "unsubscribe stable" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Patch "ext4: add missing save_error_info() to ext4_error()" has been added to the 3.4-stable tree
This is a note to let you know that I've just added the patch titled ext4: add missing save_error_info() to ext4_error() to the 3.4-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary The filename of the patch is: ext4-add-missing-save_error_info-to-ext4_error.patch and it can be found in the queue-3.4 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let know about it. >From f3fc0210c0fc91900766c995f089c39170e68305 Mon Sep 17 00:00:00 2001 From: Theodore Ts'o Date: Wed, 30 May 2012 23:00:16 -0400 Subject: ext4: add missing save_error_info() to ext4_error() From: Theodore Ts'o commit f3fc0210c0fc91900766c995f089c39170e68305 upstream. The ext4_error() function is missing a call to save_error_info(). Since this is the function which marks the file system as containing an error, this oversight (which was introduced in 2.6.36) is quite significant, and should be backported to older stable kernels with high urgency. Reported-by: Ken Sumrall Signed-off-by: "Theodore Ts'o" Cc: ksumr...@google.com Signed-off-by: Greg Kroah-Hartman --- fs/ext4/super.c |1 + 1 file changed, 1 insertion(+) --- a/fs/ext4/super.c +++ b/fs/ext4/super.c @@ -497,6 +497,7 @@ void __ext4_error(struct super_block *sb printk(KERN_CRIT "EXT4-fs error (device %s): %s:%d: comm %s: %pV\n", sb->s_id, function, line, current->comm, &vaf); va_end(args); + save_error_info(sb, function, line); ext4_handle_error(sb); } Patches currently in stable-queue which might be from ty...@mit.edu are queue-3.4/ext4-fix-potential-null-dereference-in-ext4_free_inodes_counts.patch queue-3.4/ext4-fix-potential-integer-overflow-in-alloc_flex_gd.patch queue-3.4/ext4-add-ext4_mb_unload_buddy-in-the-error-path.patch queue-3.4/ext4-force-ro-mount-if-ext4_setup_super-fails.patch queue-3.4/ext4-remove-mb_groups-before-tearing-down-the-buddy_cache.patch queue-3.4/ext4-add-missing-save_error_info-to-ext4_error.patch queue-3.4/ext4-don-t-trash-state-flags-in-ext4_ioc_setflags.patch queue-3.4/ext4-disallow-hard-linked-directory-in-ext4_lookup.patch -- To unsubscribe from this list: send the line "unsubscribe stable" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Patch "ext4: don't trash state flags in EXT4_IOC_SETFLAGS" has been added to the 3.4-stable tree
This is a note to let you know that I've just added the patch titled
ext4: don't trash state flags in EXT4_IOC_SETFLAGS
to the 3.4-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
ext4-don-t-trash-state-flags-in-ext4_ioc_setflags.patch
and it can be found in the queue-3.4 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let know about it.
>From 79906964a187c405db72a3abc60eb9b50d804fbc Mon Sep 17 00:00:00 2001
From: Theodore Ts'o
Date: Thu, 31 May 2012 23:46:01 -0400
Subject: ext4: don't trash state flags in EXT4_IOC_SETFLAGS
From: Theodore Ts'o
commit 79906964a187c405db72a3abc60eb9b50d804fbc upstream.
In commit 353eb83c we removed i_state_flags with 64-bit longs, But
when handling the EXT4_IOC_SETFLAGS ioctl, we replace i_flags
directly, which trashes the state flags which are stored in the high
32-bits of i_flags on 64-bit platforms. So use the the
ext4_{set,clear}_inode_flags() functions which use atomic bit
manipulation functions instead.
Reported-by: Tao Ma
Signed-off-by: "Theodore Ts'o"
Signed-off-by: Greg Kroah-Hartman
---
fs/ext4/ioctl.c | 12 +---
1 file changed, 9 insertions(+), 3 deletions(-)
--- a/fs/ext4/ioctl.c
+++ b/fs/ext4/ioctl.c
@@ -38,7 +38,7 @@ long ext4_ioctl(struct file *filp, unsig
handle_t *handle = NULL;
int err, migrate = 0;
struct ext4_iloc iloc;
- unsigned int oldflags;
+ unsigned int oldflags, mask, i;
unsigned int jflag;
if (!inode_owner_or_capable(inode))
@@ -115,8 +115,14 @@ long ext4_ioctl(struct file *filp, unsig
if (err)
goto flags_err;
- flags = flags & EXT4_FL_USER_MODIFIABLE;
- flags |= oldflags & ~EXT4_FL_USER_MODIFIABLE;
+ for (i = 0, mask = 1; i < 32; i++, mask <<= 1) {
+ if (!(mask & EXT4_FL_USER_MODIFIABLE))
+ continue;
+ if (mask & flags)
+ ext4_set_inode_flag(inode, i);
+ else
+ ext4_clear_inode_flag(inode, i);
+ }
ei->i_flags = flags;
ext4_set_inode_flags(inode);
Patches currently in stable-queue which might be from ty...@mit.edu are
queue-3.4/ext4-fix-potential-null-dereference-in-ext4_free_inodes_counts.patch
queue-3.4/ext4-fix-potential-integer-overflow-in-alloc_flex_gd.patch
queue-3.4/ext4-add-ext4_mb_unload_buddy-in-the-error-path.patch
queue-3.4/ext4-force-ro-mount-if-ext4_setup_super-fails.patch
queue-3.4/ext4-remove-mb_groups-before-tearing-down-the-buddy_cache.patch
queue-3.4/ext4-add-missing-save_error_info-to-ext4_error.patch
queue-3.4/ext4-don-t-trash-state-flags-in-ext4_ioc_setflags.patch
queue-3.4/ext4-disallow-hard-linked-directory-in-ext4_lookup.patch
--
To unsubscribe from this list: send the line "unsubscribe stable" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Patch "ext4: fix potential integer overflow in alloc_flex_gd()" has been added to the 3.4-stable tree
This is a note to let you know that I've just added the patch titled ext4: fix potential integer overflow in alloc_flex_gd() to the 3.4-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary The filename of the patch is: ext4-fix-potential-integer-overflow-in-alloc_flex_gd.patch and it can be found in the queue-3.4 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let know about it. >From 967ac8af4475ce45474800709b12137aa7634c77 Mon Sep 17 00:00:00 2001 From: Haogang Chen Date: Mon, 28 May 2012 14:21:55 -0400 Subject: ext4: fix potential integer overflow in alloc_flex_gd() From: Haogang Chen commit 967ac8af4475ce45474800709b12137aa7634c77 upstream. In alloc_flex_gd(), when flexbg_size is large, kmalloc size would overflow and flex_gd->groups would point to a buffer smaller than expected, causing OOB accesses when it is used. Note that in ext4_resize_fs(), flexbg_size is calculated using sbi->s_log_groups_per_flex, which is read from the disk and only bounded to [1, 31]. The patch returns NULL for too large flexbg_size. Reviewed-by: Eric Sandeen Signed-off-by: Haogang Chen Signed-off-by: "Theodore Ts'o" Signed-off-by: Greg Kroah-Hartman --- fs/ext4/resize.c |2 ++ 1 file changed, 2 insertions(+) --- a/fs/ext4/resize.c +++ b/fs/ext4/resize.c @@ -161,6 +161,8 @@ static struct ext4_new_flex_group_data * if (flex_gd == NULL) goto out3; + if (flexbg_size >= UINT_MAX / sizeof(struct ext4_new_flex_group_data)) + goto out2; flex_gd->count = flexbg_size; flex_gd->groups = kmalloc(sizeof(struct ext4_new_group_data) * Patches currently in stable-queue which might be from haogangc...@gmail.com are queue-3.4/ext4-fix-potential-integer-overflow-in-alloc_flex_gd.patch -- To unsubscribe from this list: send the line "unsubscribe stable" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Patch "ext4: fix potential NULL dereference in ext4_free_inodes_counts()" has been added to the 3.4-stable tree
This is a note to let you know that I've just added the patch titled
ext4: fix potential NULL dereference in ext4_free_inodes_counts()
to the 3.4-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
ext4-fix-potential-null-dereference-in-ext4_free_inodes_counts.patch
and it can be found in the queue-3.4 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let know about it.
>From bb3d132a24cd8bf5e7773b2d9f9baa58b07a7dae Mon Sep 17 00:00:00 2001
From: Dan Carpenter
Date: Mon, 28 May 2012 14:16:57 -0400
Subject: ext4: fix potential NULL dereference in ext4_free_inodes_counts()
From: Dan Carpenter
commit bb3d132a24cd8bf5e7773b2d9f9baa58b07a7dae upstream.
The ext4_get_group_desc() function returns NULL on error, and
ext4_free_inodes_count() function dereferences it without checking.
There is a check on the next line, but it's too late.
Reviewed-by: Jan Kara
Signed-off-by: Dan Carpenter
Signed-off-by: "Theodore Ts'o"
Signed-off-by: Greg Kroah-Hartman
---
fs/ext4/ialloc.c | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
--- a/fs/ext4/ialloc.c
+++ b/fs/ext4/ialloc.c
@@ -488,10 +488,12 @@ fallback_retry:
for (i = 0; i < ngroups; i++) {
grp = (parent_group + i) % ngroups;
desc = ext4_get_group_desc(sb, grp, NULL);
- grp_free = ext4_free_inodes_count(sb, desc);
- if (desc && grp_free && grp_free >= avefreei) {
- *group = grp;
- return 0;
+ if (desc) {
+ grp_free = ext4_free_inodes_count(sb, desc);
+ if (grp_free && grp_free >= avefreei) {
+ *group = grp;
+ return 0;
+ }
}
}
Patches currently in stable-queue which might be from dan.carpen...@oracle.com
are
queue-3.4/ext4-fix-potential-null-dereference-in-ext4_free_inodes_counts.patch
queue-3.4/nfs-kmalloc-doesn-t-return-an-err_ptr.patch
--
To unsubscribe from this list: send the line "unsubscribe stable" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Patch "ext4: remove mb_groups before tearing down the buddy_cache" has been added to the 3.4-stable tree
This is a note to let you know that I've just added the patch titled
ext4: remove mb_groups before tearing down the buddy_cache
to the 3.4-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
ext4-remove-mb_groups-before-tearing-down-the-buddy_cache.patch
and it can be found in the queue-3.4 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let know about it.
>From 95599968d19db175829fb580baa6b68939b320fb Mon Sep 17 00:00:00 2001
From: Salman Qazi
Date: Thu, 31 May 2012 23:52:14 -0400
Subject: ext4: remove mb_groups before tearing down the buddy_cache
From: Salman Qazi
commit 95599968d19db175829fb580baa6b68939b320fb upstream.
We can't have references held on pages in the s_buddy_cache while we are
trying to truncate its pages and put the inode. All the pages must be
gone before we reach clear_inode. This can only be gauranteed if we
can prevent new users from grabbing references to s_buddy_cache's pages.
The original bug can be reproduced and the bug fix can be verified by:
while true; do mount -t ext4 /dev/ram0 /export/hda3/ram0; \
umount /export/hda3/ram0; done &
while true; do cat /proc/fs/ext4/ram0/mb_groups; done
Signed-off-by: Salman Qazi
Signed-off-by: "Theodore Ts'o"
Signed-off-by: Greg Kroah-Hartman
---
fs/ext4/mballoc.c |5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
--- a/fs/ext4/mballoc.c
+++ b/fs/ext4/mballoc.c
@@ -2517,6 +2517,9 @@ int ext4_mb_release(struct super_block *
struct ext4_sb_info *sbi = EXT4_SB(sb);
struct kmem_cache *cachep = get_groupinfo_cache(sb->s_blocksize_bits);
+ if (sbi->s_proc)
+ remove_proc_entry("mb_groups", sbi->s_proc);
+
if (sbi->s_group_info) {
for (i = 0; i < ngroups; i++) {
grinfo = ext4_get_group_info(sb, i);
@@ -2564,8 +2567,6 @@ int ext4_mb_release(struct super_block *
}
free_percpu(sbi->s_locality_groups);
- if (sbi->s_proc)
- remove_proc_entry("mb_groups", sbi->s_proc);
return 0;
}
Patches currently in stable-queue which might be from sq...@google.com are
queue-3.4/ext4-add-ext4_mb_unload_buddy-in-the-error-path.patch
queue-3.4/ext4-remove-mb_groups-before-tearing-down-the-buddy_cache.patch
--
To unsubscribe from this list: send the line "unsubscribe stable" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Patch "ext4: force ro mount if ext4_setup_super() fails" has been added to the 3.4-stable tree
This is a note to let you know that I've just added the patch titled
ext4: force ro mount if ext4_setup_super() fails
to the 3.4-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
ext4-force-ro-mount-if-ext4_setup_super-fails.patch
and it can be found in the queue-3.4 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let know about it.
>From 7e84b6216467b84cd332c8e567bf5aa113fd2f38 Mon Sep 17 00:00:00 2001
From: Eric Sandeen
Date: Mon, 28 May 2012 14:17:25 -0400
Subject: ext4: force ro mount if ext4_setup_super() fails
From: Eric Sandeen
commit 7e84b6216467b84cd332c8e567bf5aa113fd2f38 upstream.
If ext4_setup_super() fails i.e. due to a too-high revision,
the error is logged in dmesg but the fs is not mounted RO as
indicated.
Tested by:
# mkfs.ext4 -r 4 /dev/sdb6
# mount /dev/sdb6 /mnt/test
# dmesg | grep "too high"
[164919.759248] EXT4-fs (sdb6): revision level too high, forcing read-only mode
# grep sdb6 /proc/mounts
/dev/sdb6 /mnt/test2 ext4 rw,seclabel,relatime,data=ordered 0 0
Reviewed-by: Andreas Dilger
Signed-off-by: Eric Sandeen
Signed-off-by: "Theodore Ts'o"
Signed-off-by: Greg Kroah-Hartman
---
fs/ext4/super.c |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- a/fs/ext4/super.c
+++ b/fs/ext4/super.c
@@ -3592,7 +3592,8 @@ no_journal:
goto failed_mount4;
}
- ext4_setup_super(sb, es, sb->s_flags & MS_RDONLY);
+ if (ext4_setup_super(sb, es, sb->s_flags & MS_RDONLY))
+ sb->s_flags |= MS_RDONLY;
/* determine the minimum size of new large inodes, if present */
if (sbi->s_inode_size > EXT4_GOOD_OLD_INODE_SIZE) {
Patches currently in stable-queue which might be from sand...@redhat.com are
queue-3.4/ext4-fix-potential-integer-overflow-in-alloc_flex_gd.patch
queue-3.4/ext4-force-ro-mount-if-ext4_setup_super-fails.patch
--
To unsubscribe from this list: send the line "unsubscribe stable" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
ToDo: backport to v3.4 , v3.3 , v3.2 patches 1b) db63a4c8115a libata 1) cd006086fa5d ata_piix: defer disks to the Hyper-V drivers by default Fw: use hv_storvsc instead of ata_piix for IDE disks ( but
Hi!
use hv_storvsc instead of ata_piix to handle the IDE disks devices ( but not
for the CD-ROM)
J.N.> the problem is that ata_piix and hv_storvscboth claim the (virtual) hard disk.
Yes:
{ About bug fixed by patches:
see tranlate from Russian language issue described by Maksim Kramarenko:
http://lists.debian.org/debian-russian/2012/01/msg00324.html
After [VVM: turn On in kernel source] Hyper-V modules [compile and
start use], a hard disk was determined as 2 with the same UUID.
}
J.N.> {
A workaround is to blacklist the ata_piix module.
However, that means losing access to CD and DVD drives
which are exposed by ata_piix and not hv_storvsc.
}
Yes: work without CD-ROM is not super-fine,
{
best backport patches from v3.5 ( de-facto reincarnation _tested_(!) patches
from Ubuntu v12.04 and/or OpenSUSE ) :
J.N.> {
The patch works by making ata_piix skip the disk during enumeration
if hv_storvsc is enabled as a built-in driver or module.
}
> VVM > > > Hyper-V admins need _worked_ Linux v3.4.X / v3.3.X / v3.2.X
i.e. need backport to all actual version after 3.1
cd006086fa5d ata_piix: defer disks to the Hyper-V drivers by default
and its prerequisite
db63a4c8115a libata: add a host flag to ignore detected ATA devices
}
--- I think this is what Greg was asking for.
I supose . . .
Thanks,
Best regards, Victor Miasnikov
Blog: http://vvm.blog.tut.by/
P.S.
Thanks
No problem :-)
Hoping that clarifies,
Yes: very good description of problem and possible solution
Big thanks!
--
- Original Message -
From: "Jonathan Nieder"
To: . . . Cc: . . .
Sent: Tuesday, June 05, 2012 7:59 AM
Subject: Re: [PATCH 2/2] ata_piix: defer disks to the Hyper-V drivers by default
. . .
If I understand correctly,
the problem is that ata_piix and hv_storvscboth claim the (virtual) hard disk.
That sounds worth fixing.
The patch works by making ata_piix skip the disk during enumeration
if hv_storvsc is enabled as a built-in driver or module.
A workaround is to blacklist the ata_piix module.
However, that means losing access to CD and DVD drives
which are exposed by ata_piix and not hv_storvsc.
--
--
To unsubscribe from this list: send the line "unsubscribe stable" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
