Re: [PATCH] mac80211: fix non RCU-safe sta_list manipulation

[Johannes Berg]

On Sun, 2012-06-03 at 23:32 +0300, Arik Nemtsov wrote:
 sta_info_cleanup locks the sta_list using rcu_read_lock however
 the delete operation isn't rcu safe. A race between sta_info_cleanup
 timer being called and a STA being removed can occur which leads
 to a panic while traversing sta_list. Fix this by switching to the
 RCU-safe versions.

Good catch!

johannes


--
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

[Daniel Vetter]

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 seanp...@chromium.org
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 copypasting 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 guang.a.y...@intel.com
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=50522
Signed-Off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
 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);

[PATCH] xHCI: Increase the timeout for controller save state operation

[Andiry Xu]

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 andiry...@gmail.com
Cc: Ming Lei ming@canonical.com
Cc: stable@vger.kernel.org
---
 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

[Jani Nikula]

Hi Daniel, please find a couple of comments inline.

BR,
Jani.

On Mon, 04 Jun 2012, Daniel Vetter daniel.vet...@ffwll.ch wrote:
 diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
 index 238a521..a0c76aa 100644
 --- a/drivers/gpu/drm/i915/i915_drv.c
 +++ 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

[Daniel Vetter]

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

[Daniel Vetter]

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 seanp...@chromium.org
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 copypasting 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 guang.a.y...@intel.com
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=50522
Signed-Off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
 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 

Re: [Intel-gfx] [PATCH] drm/i915: hold forcewake around ring hw init

[Chris Wilson]

On Mon, 4 Jun 2012 11:16:04 +0200, Daniel Vetter dan...@ffwll.ch wrote:
 On Mon, Jun 04, 2012 at 12:04:41PM +0300, Jani Nikula wrote:
  
  Hi Daniel, please find a couple of comments inline.
 
 Oops, a clear case of -ENOTENOUGHCOFFEE. Thanks for catching these, I'll
 follow up with a v2 shortly.

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 ch...@chris-wilson.co.uk
-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

[Daniel Vetter]

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 seanp...@chromium.org
 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 copypasting 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 guang.a.y...@intel.com

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 daniel.vet...@ffwll.ch
 ---
  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;
 +

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

[Victor Miasnikov]

Hi!

VVMHyper-V admins need _worked_ Linux v3.4.X / v3.3.X / v3.2.X
VVM   
VVMPlease, _fix_ errors related use hv_storvsc instead of ata_piix to
VVMhandle the IDE disks devices ( but not for the CD-ROM)


K.Y.S.  {
Clearly I cannot tell you anything about this that you don't know!
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

[Eugeni Dodonov]

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 Paulseanp...@chromium.org
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 copypasting 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 Guangguang.a.y...@intel.com
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=50522
Signed-Off-by: Daniel Vetterdaniel.vet...@ffwll.ch


The new .has_forcewake looks nice! Just one very tiny bikeshed below :).

Reviewed-by: Eugeni Dodonov eugeni.dodo...@intel.com


@@ -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

[Grumbach, Emmanuel]

 
 
 The patch below does not apply to the 3.4-stable tree.
 If someone wants it applied there, or to any other stable or longterm
 tree, then please email the backport, including the original git commit
 id to stable@vger.kernel.org.
 
 thanks,
 
 greg k-h
 
 -- original commit in Linus's tree --
 
 From ebed633c61c023e5d1aa4ed159cd67406e9e37c2 Mon Sep 17 00:00:00 2001
 From: Emmanuel Grumbach emmanuel.grumb...@intel.com
 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

[Sascha Hauer]

MX53_DPLL4_BASE accidently returned the base address of PLL3.
Fix this.

Signed-off-by: Sascha Hauer s.ha...@pengutronix.de
Cc: stable@vger.kernel.org
---
 arch/arm/mach-imx/crm-regs-imx5.h |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/mach-imx/crm-regs-imx5.h 
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

[KY Srinivasan]

 -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!
 
 VVMHyper-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

[Victor Miasnikov]

Hi!


VVMHyper-V admins need _worked_ Linux v3.4.X / v3.3.X / v3.2.X
I can help you with the ata patch on specific set of distros of interest. 
If the system that you are interested loads the ata_piix module, 
we can solve the issue on hand using modprobe rules rather than a patch against the 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

[KY Srinivasan]

 -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!
 
  VVMHyper-V admins need _worked_ Linux v3.4.X / v3.3.X / v3.2.X
 I can help you with the ata patch on specific set of distros of interest.
 If the system that you are interested loads the ata_piix module,
 we can solve the issue on hand using modprobe rules rather than a patch
 against the 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

[Tao Guo]

Other components may also require an unplug callback, so move this
function from md/raid to block generic layer.

Signed-off-by: Tao Guo tao@emc.com
Cc: Neil Brown ne...@suse.de
Cc: Jens Axboe ax...@kernel.dk
Cc: stable@vger.kernel.org
Cc: Andrew Morton a...@linux-foundation.org
Cc: stable@vger.kernel.org
---
 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 

Re: [PATCH 2/2] umem: fix up unplugging

[Tao Guo]

This patch is to fix a regression introduced by 7eaceaccab5f40
(block: remove per-queueplugging).

-Tao

On Mon, Jun 4, 2012 at 10:41 PM, Tao Guo glorious...@gmail.com wrote:
 In that patch, Jens removed the whole mm_unplug_device()
 function, which used to be the trigger to make umem start to work.

 We need to implement unplugging to make umem start to work, or I/O
 will never be triggered.

 Signed-off-by: Tao Guo tao@emc.com
 Cc: Neil Brown ne...@suse.de
 Cc: Jens Axboe ax...@kernel.dk
 Cc: stable@vger.kernel.org
 Cc: Andrew Morton a...@linux-foundation.org
 Cc: stable@vger.kernel.org
 ---
  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: 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

[Victor Miasnikov]

Hi!


 VVMHyper-V admins need _worked_ Linux v3.4.X / v3.3.X / v3.2.X
I can help you with the ata patch on specific set of distros of interest.
If the system that you are interested loads the ata_piix module,
we can solve the issue on hand using modprobe rules rather than a patch
against the 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 
Linux_Distib__Kernel_3.2_

  . . .

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

[Rafał Miłecki]

This is based on info released by AMD, should allow using audio in much
more cases.

Signed-off-by: Rafał Miłecki zaj...@gmail.com
Cc: stable@vger.kernel.org
---
 drivers/gpu/drm/radeon/r600_audio.c |5 +++--
 1 files changed, 3 insertions(+), 2 deletions(-)

diff --git 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

[Alex Deucher]

On Mon, Jun 4, 2012 at 12:36 PM, Rafał Miłecki zaj...@gmail.com wrote:
 This is based on info released by AMD, should allow using audio in much
 more cases.

 Signed-off-by: Rafał Miłecki zaj...@gmail.com
 Cc: stable@vger.kernel.org

Reviewed-by: Alex Deucher alexander.deuc...@amd.com

 ---
  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

Linux 3.0.33

[Greg KH]

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):
  

Linux 3.3.8

[Greg KH]

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

[Greg KH]

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 
 

Linux 3.2.19

[Ben Hutchings]

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 +-
 

Re: [PATCH 1/2] block: Move general unplug callback function from md/raid to blk-core

[Shaohua Li]

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

[Tao.Guo]

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()

[Steven Rostedt]

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
  failed? bisect t1, if not bisect t2
 
 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 rost...@goodmis.org
 
 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

[Jonathan Nieder]

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