* Re: [PATCH v7 00/27] x86, boot, 64bit: Add support for loading ramdisk and bzImage above 4G
From: Borislav Petkov @ 2012-12-25 11:52 UTC (permalink / raw)
To: H. Peter Anvin
Cc: Konrad Rzeszutek Wilk, Yinghai Lu, Thomas Gleixner, Ingo Molnar,
Eric W. Biederman, Andrew Morton, linux-kernel
In-Reply-To: <50D8FBF9.6050509@zytor.com>
On Mon, Dec 24, 2012 at 05:06:01PM -0800, H. Peter Anvin wrote:
> Could this be the ljmpq problem that Borislav reported
> (Intel implemented ljmpq, AMD didn't, and I was tempted by a
> micro-optimization which broke AMD which made it into the patchset)?
It has to be. Just booted Yinghai's -v8 in kvm on an AMD host and it
worked fine.
With the change below it keeps rebooting like I reported earlier. I'd go
out on a limb here and guess that the guest is triple-faulting due to an
unhandled #GP caused by an invalid opcode or similar.
---
diff --git a/arch/x86/kernel/head_64.S b/arch/x86/kernel/head_64.S
index d94f6d68be2a..1842d30c96a2 100644
--- a/arch/x86/kernel/head_64.S
+++ b/arch/x86/kernel/head_64.S
@@ -279,11 +279,8 @@ ENTRY(secondary_startup_64)
* REX.W + FF /5 JMP m16:64 Jump far, absolute indirect,
* address given in m16:64.
*/
- movq initial_code(%rip),%rax
pushq $0 # fake return address to stop unwinder
- pushq $__KERNEL_CS # set correct cs
- pushq %rax # target address in negative space
- lretq
+ rex64 ljmp *initial_code(%rip)
#ifdef CONFIG_HOTPLUG_CPU
/*
--
Regards/Gruss,
Boris.
Sent from a fat crate under my desk. Formatting is fine.
--
^ permalink raw reply related
* Re: [PATCH v7 3/3] x86, apicv: add virtual x2apic support
From: Gleb Natapov @ 2012-12-25 11:58 UTC (permalink / raw)
To: Zhang, Yang Z; +Cc: kvm@vger.kernel.org, Shan, Haitao, Tian, Kevin
In-Reply-To: <A9667DDFB95DB7438FA9D7D576C3D87E2E99AA@SHSMSX101.ccr.corp.intel.com>
On Tue, Dec 25, 2012 at 08:24:43AM +0000, Zhang, Yang Z wrote:
> Gleb Natapov wrote on 2012-12-25:
> > On Tue, Dec 25, 2012 at 07:46:53AM +0000, Zhang, Yang Z wrote:
> >> Gleb Natapov wrote on 2012-12-25:
> >>> On Tue, Dec 25, 2012 at 07:25:15AM +0000, Zhang, Yang Z wrote:
> >>>> Gleb Natapov wrote on 2012-12-25:
> >>>>> On Tue, Dec 25, 2012 at 06:42:59AM +0000, Zhang, Yang Z wrote:
> >>>>>> Gleb Natapov wrote on 2012-12-25:
> >>>>>>> On Mon, Dec 24, 2012 at 11:53:37PM +0000, Zhang, Yang Z wrote:
> >>>>>>>> Gleb Natapov wrote on 2012-12-24:
> >>>>>>>>> On Mon, Dec 24, 2012 at 02:35:35AM +0000, Zhang, Yang Z wrote:
> >>>>>>>>>> Zhang, Yang Z wrote on 2012-12-24:
> >>>>>>>>>>> Gleb Natapov wrote on 2012-12-20:
> >>>>>>>>>>>> On Mon, Dec 17, 2012 at 01:30:50PM +0800, Yang Zhang wrote:
> >>>>>>>>>>>>> basically to benefit from apicv, we need clear MSR bitmap for
> >>>>>>>>>>>>> corresponding x2apic MSRs:
> >>>>>>>>>>>>> 0x800 - 0x8ff: no read intercept for apicv register
> >>>>>>>>>>>>> virtualization TPR,EOI,SELF-IPI: no write intercept for
> >>>>>>>>>>>>> virtual interrupt
> >>> delivery
> >>>>>>>>>>>> We do not set "Virtualize x2APIC mode" bit in secondary
> >>>>>>>>>>>> execution control. If I read the spec correctly without that
> >>>>>>>>>>>> those MSR read/writes will go straight to physical local APIC.
> >>>>>>>>>>> Right. Now it cannot get benefit, but we may enable it in
> >>>>>>>>>>> future and then we can benefit from it.
> >>>>>>>>> Without enabling it you cannot disable MSR intercept for x2apic
> >>>>>>>>> MSRs.
> >>>>>>>>>
> >>>>>>>>>> how about to add the following check:
> >>>>>>>>>> if (apicv_enabled && virtual_x2apic_enabled)
> >>>>>>>>>> clear_msr();
> >>>>>>>>>>
> >>>>>>>>> I do not understand what do you mean here.
> >>>>>>>> In this patch, it will clear MSR bitmap(0x800 -0x8ff) when apicv
> > enabled.
> >>> As
> >>>>> you
> >>>>>>> said, since kvm doesn't set "virtualize x2apic mode", APIC register
> >>>>>>> virtualization never take effect. So we need to clear MSR bitmap only
> >>>>>>> when apicv enabled and virtualize x2apic mode set.
> >>>>>>>>
> >>>>>>> But currently it is never set.
> >>>>>> So you think the third patch is not necessary currently? Unless we
> >>>>>> enabled "virtualize x2apic mode".
> >>>>>>
> >>>>> Without third patch vid will not work properly if a guest is in x2apic
> >>>>> mode. Actually second and third patches need to be reordered to not have
> >>>>> a windows where x2apic is broken. The problem is that this patch itself
> >>>>> is buggy since it does not set "virtualize x2apic mode" flag. It should
> >>>>> set the flag if vid is enabled and if the flag cannot be set vid should
> >>>>> be forced off.
> >>>> In what conditions this flag cannot be set? I think the only case is that KVM
> >>> doesn't expose the x2apic capability to guest, if this is true, the
> >>> guest will never use x2apic and we still can use vid.
> >>>>
> >>> We can indeed set "virtualize x2apic mode" unconditionally since it does
> >>> not take any effect if x2apic MSRs are intercepted.
> >> No. Since "Virtual APIC access" must be cleared if "virtualize x2apic mode" is set,
> > and if guest still use xAPIC, then there should be lots of ept violations for apic
> > access emulation. This will hurt performance.
> > Stupid HW, why this pointless limitation? Can you point me where SDM says that?
> Vol 3, 26.2.1.1
>
Thanks.
> >> We should only set "virtualize x2apic mode" when guest really uses
> >> x2apic(guest set bit 11 of APIC_BASE_MSR).
> >>
> > Looks like SDM force us to.
> >
And we can disable x2apic MSR interception only after "virtualize x2apic
mode" is set i.e when guest sets bit 11 of APIC_BASE_MSR.
--
Gleb.
^ permalink raw reply
* Re: Does init start with any open files?
From: Borislav Petkov @ 2012-12-25 11:58 UTC (permalink / raw)
To: bbi5291; +Cc: linux-kernel
In-Reply-To: <CAMmfjbNmN0pPXr-HY7qzK52YpwoSU76q1Puog951X7h099XHBA@mail.gmail.com>
First of all,
please do not top-post. You can search the net for why top-posting is
discouraged.
On Tue, Dec 25, 2012 at 06:25:11AM -0500, bbi5291 wrote:
> Well, that can't be right---I grepped the kernel source for "initctl"
> and got no results.
That's because it is a named pipe.
> Besides, if you're running a shell, then init has already had time
> to open and close whatever file descriptors it wants to. What I want
> to know is whether init has any open file descriptors, at, say, the
> moment its main() starts executing.
You probably want to stare at init/main.c:kernel_init() and what it
calls, and then download the sources of the init executable which is run
on your distro, whip up a text editor and start staring at them.
HTH.
--
Regards/Gruss,
Boris.
Sent from a fat crate under my desk. Formatting is fine.
--
^ permalink raw reply
* Re: kernel BUG at mm/huge_memory.c:1798!
From: Hillf Danton @ 2012-12-25 12:05 UTC (permalink / raw)
To: Zhouping Liu
Cc: linux-mm, linux-kernel, Ingo Molnar, Johannes Weiner, mgorman,
hughd, Andrea Arcangeli
In-Reply-To: <535932623.34838584.1356410331076.JavaMail.root@redhat.com>
On Tue, Dec 25, 2012 at 12:38 PM, Zhouping Liu <zliu@redhat.com> wrote:
> Hello all,
>
> I found the below kernel bug using latest mainline(637704cbc95),
> my hardware has 2 numa nodes, and it's easy to reproduce the issue
> using LTP test case: "# ./mmap10 -a -s -c 200":
Can you test with 5a505085f0 and 4fc3f1d66b1 reverted?
Hillf
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: kernel BUG at mm/huge_memory.c:1798!
From: Hillf Danton @ 2012-12-25 12:05 UTC (permalink / raw)
To: Zhouping Liu
Cc: linux-mm, linux-kernel, Ingo Molnar, Johannes Weiner, mgorman,
hughd, Andrea Arcangeli
In-Reply-To: <535932623.34838584.1356410331076.JavaMail.root@redhat.com>
On Tue, Dec 25, 2012 at 12:38 PM, Zhouping Liu <zliu@redhat.com> wrote:
> Hello all,
>
> I found the below kernel bug using latest mainline(637704cbc95),
> my hardware has 2 numa nodes, and it's easy to reproduce the issue
> using LTP test case: "# ./mmap10 -a -s -c 200":
Can you test with 5a505085f0 and 4fc3f1d66b1 reverted?
Hillf
^ permalink raw reply
* [PATCH v2 1/2] ARM: dts: imx27-3ds: Rename it to imx27-pdk
From: Shawn Guo @ 2012-12-25 12:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1356433852-3028-1-git-send-email-festevam@gmail.com>
On Tue, Dec 25, 2012 at 09:10:51AM -0200, Fabio Estevam wrote:
> From: Fabio Estevam <fabio.estevam@freescale.com>
>
> imx27-pdk is the name found on Freescale website, so use it instead of 3ds.
>
> Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
> ---
> Changes since v1:
> - Use 'fsl' instead of 'freescale' in the compatible field.
I assume Sascha will pick them up, so for both:
Acked-by: Shawn Guo <shawn.guo@linaro.org>
^ permalink raw reply
* [PATCH] ARM: imx_v6_v7_defconfig: Select IPUV3 driver
From: Fabio Estevam @ 2012-12-25 12:07 UTC (permalink / raw)
To: linux-arm-kernel
From: Fabio Estevam <fabio.estevam@freescale.com>
Let IPUV3 driver be built by default.
Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
---
arch/arm/configs/imx_v6_v7_defconfig | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/arch/arm/configs/imx_v6_v7_defconfig b/arch/arm/configs/imx_v6_v7_defconfig
index 6966713..a613eb7 100644
--- a/arch/arm/configs/imx_v6_v7_defconfig
+++ b/arch/arm/configs/imx_v6_v7_defconfig
@@ -159,6 +159,7 @@ CONFIG_V4L_PLATFORM_DRIVERS=y
CONFIG_MEDIA_CAMERA_SUPPORT=y
CONFIG_SOC_CAMERA=y
CONFIG_SOC_CAMERA_OV2640=y
+CONFIG_DRM=y
CONFIG_VIDEO_MX3=y
CONFIG_FB=y
CONFIG_LCD_PLATFORM=y
@@ -200,6 +201,10 @@ CONFIG_RTC_DRV_MXC=y
CONFIG_DMADEVICES=y
CONFIG_IMX_SDMA=y
CONFIG_MXS_DMA=y
+CONFIG_STAGING=y
+CONFIG_DRM_IMX=y
+CONFIG_DRM_IMX_IPUV3_CORE=y
+CONFIG_DRM_IMX_IPUV3=y
CONFIG_COMMON_CLK_DEBUG=y
# CONFIG_IOMMU_SUPPORT is not set
CONFIG_EXT2_FS=y
--
1.7.9.5
^ permalink raw reply related
* Re: [PATCH 1/2] IB/rds: Correct ib_api use with gs_dma_address/sg_dma_len
From: Bart Van Assche @ 2012-12-25 12:10 UTC (permalink / raw)
To: Mike Marciniszyn
Cc: venkat.x.venkatsubra-QHcLZuEGTsvQT0dZR+AlfA,
linux-rdma-u79uwXL29TY76Z2rM5mHXA, roland-DgEjT+Ai2ygdnm+yROfE0A,
rds-devel-N0ozoZBvEnrZJqsBc5GL+g, davem-fT/PcQaiUtIeIZ0/mPfg9Q,
netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20121221180149.23716.54707.stgit-K+u1se/DcYrLESAwzcoQNrvm/XP+8Wra@public.gmane.org>
On 12/21/12 19:01, Mike Marciniszyn wrote:
> 0b088e00 ("RDS: Use page_remainder_alloc() for recv bufs")
> added uses of sg_dma_len() and sg_dma_address(). This makes
> RDS DOA with the qib driver.
>
> IB ulps should use ib_sg_dma_len() and ib_sg_dma_address
> respectively since some HCAs overload ib_sg_dma* operations.
>
> Signed-off-by: Mike Marciniszyn <mike.marciniszyn-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
> ---
> net/rds/ib_recv.c | 9 ++++++---
> 1 files changed, 6 insertions(+), 3 deletions(-)
>
> diff --git a/net/rds/ib_recv.c b/net/rds/ib_recv.c
> index 8c5bc85..8eb9501 100644
> --- a/net/rds/ib_recv.c
> +++ b/net/rds/ib_recv.c
> @@ -339,8 +339,8 @@ static int rds_ib_recv_refill_one(struct rds_connection *conn,
> sge->length = sizeof(struct rds_header);
>
> sge = &recv->r_sge[1];
> - sge->addr = sg_dma_address(&recv->r_frag->f_sg);
> - sge->length = sg_dma_len(&recv->r_frag->f_sg);
> + sge->addr = ib_sg_dma_address(ic->i_cm_id->device, &recv->r_frag->f_sg);
> + sge->length = ib_sg_dma_len(ic->i_cm_id->device, &recv->r_frag->f_sg);
>
> ret = 0;
> out:
> @@ -381,7 +381,10 @@ void rds_ib_recv_refill(struct rds_connection *conn, int prefill)
> ret = ib_post_recv(ic->i_cm_id->qp, &recv->r_wr, &failed_wr);
> rdsdebug("recv %p ibinc %p page %p addr %lu ret %d\n", recv,
> recv->r_ibinc, sg_page(&recv->r_frag->f_sg),
> - (long) sg_dma_address(&recv->r_frag->f_sg), ret);
> + (long) ib_sg_dma_address(
> + ic->i_cm_id->device,
> + &recv->r_frag->f_sg),
> + ret);
> if (ret) {
> rds_ib_conn_error(conn, "recv post on "
> "%pI4 returned %d, disconnecting and "
The above patch will slow down RDS for anyone who is not using QLogic
HCA's, isn' it ? How about replacing the above patch with the
(untested) patch below ?
diff --git a/drivers/infiniband/hw/ehca/ehca_mrmw.c b/drivers/infiniband/hw/ehca/ehca_mrmw.c
index 8784486..ec9adf8 100644
--- a/drivers/infiniband/hw/ehca/ehca_mrmw.c
+++ b/drivers/infiniband/hw/ehca/ehca_mrmw.c
@@ -2588,16 +2588,6 @@ static void ehca_dma_unmap_sg(struct ib_device *dev, struct scatterlist *sg,
/* This is only a stub; nothing to be done here */
}
-static u64 ehca_dma_address(struct ib_device *dev, struct scatterlist *sg)
-{
- return sg->dma_address;
-}
-
-static unsigned int ehca_dma_len(struct ib_device *dev, struct scatterlist *sg)
-{
- return sg->length;
-}
-
static void ehca_dma_sync_single_for_cpu(struct ib_device *dev, u64 addr,
size_t size,
enum dma_data_direction dir)
@@ -2650,8 +2640,6 @@ struct ib_dma_mapping_ops ehca_dma_mapping_ops = {
.unmap_page = ehca_dma_unmap_page,
.map_sg = ehca_dma_map_sg,
.unmap_sg = ehca_dma_unmap_sg,
- .dma_address = ehca_dma_address,
- .dma_len = ehca_dma_len,
.sync_single_for_cpu = ehca_dma_sync_single_for_cpu,
.sync_single_for_device = ehca_dma_sync_single_for_device,
.alloc_coherent = ehca_dma_alloc_coherent,
diff --git a/drivers/infiniband/hw/qib/qib_dma.c b/drivers/infiniband/hw/qib/qib_dma.c
index 2920bb3..3620c6c 100644
--- a/drivers/infiniband/hw/qib/qib_dma.c
+++ b/drivers/infiniband/hw/qib/qib_dma.c
@@ -104,7 +104,12 @@ static int qib_map_sg(struct ib_device *dev, struct scatterlist *sgl,
for_each_sg(sgl, sg, nents, i) {
addr = (u64) page_address(sg_page(sg));
/* TODO: handle highmem pages */
- if (!addr) {
+ if (addr) {
+ sg->dma_address = addr + sg->offset;
+#ifdef CONFIG_NEED_SG_DMA_LENGTH
+ sg->dma_length = sg->length;
+#endif
+ } else {
ret = 0;
break;
}
@@ -119,21 +124,6 @@ static void qib_unmap_sg(struct ib_device *dev,
BUG_ON(!valid_dma_direction(direction));
}
-static u64 qib_sg_dma_address(struct ib_device *dev, struct scatterlist *sg)
-{
- u64 addr = (u64) page_address(sg_page(sg));
-
- if (addr)
- addr += sg->offset;
- return addr;
-}
-
-static unsigned int qib_sg_dma_len(struct ib_device *dev,
- struct scatterlist *sg)
-{
- return sg->length;
-}
-
static void qib_sync_single_for_cpu(struct ib_device *dev, u64 addr,
size_t size, enum dma_data_direction dir)
{
@@ -173,8 +163,6 @@ struct ib_dma_mapping_ops qib_dma_mapping_ops = {
.unmap_page = qib_dma_unmap_page,
.map_sg = qib_map_sg,
.unmap_sg = qib_unmap_sg,
- .dma_address = qib_sg_dma_address,
- .dma_len = qib_sg_dma_len,
.sync_single_for_cpu = qib_sync_single_for_cpu,
.sync_single_for_device = qib_sync_single_for_device,
.alloc_coherent = qib_dma_alloc_coherent,
diff --git a/include/rdma/ib_verbs.h b/include/rdma/ib_verbs.h
index 46bc045..54a0689 100644
--- a/include/rdma/ib_verbs.h
+++ b/include/rdma/ib_verbs.h
@@ -1049,10 +1049,6 @@ struct ib_dma_mapping_ops {
void (*unmap_sg)(struct ib_device *dev,
struct scatterlist *sg, int nents,
enum dma_data_direction direction);
- u64 (*dma_address)(struct ib_device *dev,
- struct scatterlist *sg);
- unsigned int (*dma_len)(struct ib_device *dev,
- struct scatterlist *sg);
void (*sync_single_for_cpu)(struct ib_device *dev,
u64 dma_handle,
size_t size,
@@ -1863,12 +1859,13 @@ static inline void ib_dma_unmap_sg_attrs(struct ib_device *dev,
* ib_sg_dma_address - Return the DMA address from a scatter/gather entry
* @dev: The device for which the DMA addresses were created
* @sg: The scatter/gather entry
+ *
+ * Note: this function is obsolete. To do: change all occurrences of
+ * ib_sg_dma_address() into sg_dma_address().
*/
static inline u64 ib_sg_dma_address(struct ib_device *dev,
struct scatterlist *sg)
{
- if (dev->dma_ops)
- return dev->dma_ops->dma_address(dev, sg);
return sg_dma_address(sg);
}
@@ -1876,12 +1873,13 @@ static inline u64 ib_sg_dma_address(struct ib_device *dev,
* ib_sg_dma_len - Return the DMA length from a scatter/gather entry
* @dev: The device for which the DMA addresses were created
* @sg: The scatter/gather entry
+ *
+ * Note: this function is obsolete. To do: change all occurrences of
+ * ib_sg_dma_len() into sg_dma_len().
*/
static inline unsigned int ib_sg_dma_len(struct ib_device *dev,
struct scatterlist *sg)
{
- if (dev->dma_ops)
- return dev->dma_ops->dma_len(dev, sg);
return sg_dma_len(sg);
}
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [B.A.T.M.A.N.] [PATCHv2] batman-adv: a delayed_work has to be initialised once
From: Antonio Quartulli @ 2012-12-25 12:14 UTC (permalink / raw)
To: b.a.t.m.a.n
In-Reply-To: <1355577056-28833-1-git-send-email-ordex@autistici.org>
A delayed_work struct does not need to be initialized each
every time before being enqueued. Therefore the
INIT_DELAYED_WORK() macro should be used during the
initialization process only.
Signed-off-by: Antonio Quartulli <ordex@autistici.org>
---
v2:
* add defines for workier period lengths
bridge_loop_avoidance.c | 18 ++++++------------
main.h | 2 ++
originator.c | 17 ++++++++---------
send.c | 5 +++--
translation-table.c | 14 +++++---------
vis.c | 20 ++++++++------------
6 files changed, 32 insertions(+), 44 deletions(-)
diff --git a/bridge_loop_avoidance.c b/bridge_loop_avoidance.c
index 5e834c1..bb5fbd6 100644
--- a/bridge_loop_avoidance.c
+++ b/bridge_loop_avoidance.c
@@ -1100,16 +1100,6 @@ void batadv_bla_update_orig_address(struct batadv_priv *bat_priv,
}
}
-
-
-/* (re)start the timer */
-static void batadv_bla_start_timer(struct batadv_priv *bat_priv)
-{
- INIT_DELAYED_WORK(&bat_priv->bla.work, batadv_bla_periodic_work);
- queue_delayed_work(batadv_event_workqueue, &bat_priv->bla.work,
- msecs_to_jiffies(BATADV_BLA_PERIOD_LENGTH));
-}
-
/* periodic work to do:
* * purge structures when they are too old
* * send announcements
@@ -1180,7 +1170,8 @@ out:
if (primary_if)
batadv_hardif_free_ref(primary_if);
- batadv_bla_start_timer(bat_priv);
+ queue_delayed_work(batadv_event_workqueue, &bat_priv->bla.work,
+ msecs_to_jiffies(BATADV_BLA_PERIOD_LENGTH));
}
/* The hash for claim and backbone hash receive the same key because they
@@ -1238,7 +1229,10 @@ int batadv_bla_init(struct batadv_priv *bat_priv)
batadv_dbg(BATADV_DBG_BLA, bat_priv, "bla hashes initialized\n");
- batadv_bla_start_timer(bat_priv);
+ INIT_DELAYED_WORK(&bat_priv->bla.work, batadv_bla_periodic_work);
+
+ queue_delayed_work(batadv_event_workqueue, &bat_priv->bla.work,
+ msecs_to_jiffies(BATADV_BLA_PERIOD_LENGTH));
return 0;
}
diff --git a/main.h b/main.h
index 2032de2..866a1f0 100644
--- a/main.h
+++ b/main.h
@@ -44,6 +44,8 @@
#define BATADV_TT_LOCAL_TIMEOUT 600000 /* in milliseconds */
#define BATADV_TT_CLIENT_ROAM_TIMEOUT 600000 /* in milliseconds */
#define BATADV_TT_CLIENT_TEMP_TIMEOUT 600000 /* in milliseconds */
+#define BATADV_TT_WORK_PERIOD 5000 /* 5 seconds */
+#define BATADV_ORIG_WORK_PERIOD 1000 /* 1 second */
#define BATADV_DAT_ENTRY_TIMEOUT (5*60000) /* 5 mins in milliseconds */
/* sliding packet range of received originator messages in sequence numbers
* (should be a multiple of our word size)
diff --git a/originator.c b/originator.c
index fa88b2b..92a55fd 100644
--- a/originator.c
+++ b/originator.c
@@ -34,13 +34,6 @@ static struct lock_class_key batadv_orig_hash_lock_class_key;
static void batadv_purge_orig(struct work_struct *work);
-static void batadv_start_purge_timer(struct batadv_priv *bat_priv)
-{
- INIT_DELAYED_WORK(&bat_priv->orig_work, batadv_purge_orig);
- queue_delayed_work(batadv_event_workqueue,
- &bat_priv->orig_work, msecs_to_jiffies(1000));
-}
-
/* returns 1 if they are the same originator */
static int batadv_compare_orig(const struct hlist_node *node, const void *data2)
{
@@ -63,7 +56,11 @@ int batadv_originator_init(struct batadv_priv *bat_priv)
batadv_hash_set_lock_class(bat_priv->orig_hash,
&batadv_orig_hash_lock_class_key);
- batadv_start_purge_timer(bat_priv);
+ INIT_DELAYED_WORK(&bat_priv->orig_work, batadv_purge_orig);
+ queue_delayed_work(batadv_event_workqueue,
+ &bat_priv->orig_work,
+ msecs_to_jiffies(BATADV_ORIG_WORK_PERIOD));
+
return 0;
err:
@@ -396,7 +393,9 @@ static void batadv_purge_orig(struct work_struct *work)
delayed_work = container_of(work, struct delayed_work, work);
bat_priv = container_of(delayed_work, struct batadv_priv, orig_work);
_batadv_purge_orig(bat_priv);
- batadv_start_purge_timer(bat_priv);
+ queue_delayed_work(batadv_event_workqueue,
+ &bat_priv->orig_work,
+ msecs_to_jiffies(BATADV_ORIG_WORK_PERIOD));
}
void batadv_purge_orig_ref(struct batadv_priv *bat_priv)
diff --git a/send.c b/send.c
index 89810ce..0b6f65b 100644
--- a/send.c
+++ b/send.c
@@ -155,8 +155,6 @@ _batadv_add_bcast_packet_to_list(struct batadv_priv *bat_priv,
spin_unlock_bh(&bat_priv->forw_bcast_list_lock);
/* start timer for this packet */
- INIT_DELAYED_WORK(&forw_packet->delayed_work,
- batadv_send_outstanding_bcast_packet);
queue_delayed_work(batadv_event_workqueue, &forw_packet->delayed_work,
send_time);
}
@@ -210,6 +208,9 @@ int batadv_add_bcast_packet_to_list(struct batadv_priv *bat_priv,
/* how often did we send the bcast packet ? */
forw_packet->num_packets = 0;
+ INIT_DELAYED_WORK(&forw_packet->delayed_work,
+ batadv_send_outstanding_bcast_packet);
+
_batadv_add_bcast_packet_to_list(bat_priv, forw_packet, delay);
return NETDEV_TX_OK;
diff --git a/translation-table.c b/translation-table.c
index d4b27b6..877acd1 100644
--- a/translation-table.c
+++ b/translation-table.c
@@ -52,13 +52,6 @@ static int batadv_compare_tt(const struct hlist_node *node, const void *data2)
return (memcmp(data1, data2, ETH_ALEN) == 0 ? 1 : 0);
}
-static void batadv_tt_start_timer(struct batadv_priv *bat_priv)
-{
- INIT_DELAYED_WORK(&bat_priv->tt.work, batadv_tt_purge);
- queue_delayed_work(batadv_event_workqueue, &bat_priv->tt.work,
- msecs_to_jiffies(5000));
-}
-
static struct batadv_tt_common_entry *
batadv_tt_hash_find(struct batadv_hashtable *hash, const void *data)
{
@@ -2136,7 +2129,9 @@ int batadv_tt_init(struct batadv_priv *bat_priv)
if (ret < 0)
return ret;
- batadv_tt_start_timer(bat_priv);
+ INIT_DELAYED_WORK(&bat_priv->tt.work, batadv_tt_purge);
+ queue_delayed_work(batadv_event_workqueue, &bat_priv->tt.work,
+ msecs_to_jiffies(BATADV_TT_WORK_PERIOD));
return 1;
}
@@ -2286,7 +2281,8 @@ static void batadv_tt_purge(struct work_struct *work)
batadv_tt_req_purge(bat_priv);
batadv_tt_roam_purge(bat_priv);
- batadv_tt_start_timer(bat_priv);
+ queue_delayed_work(batadv_event_workqueue, &bat_priv->tt.work,
+ msecs_to_jiffies(BATADV_TT_WORK_PERIOD));
}
void batadv_tt_free(struct batadv_priv *bat_priv)
diff --git a/vis.c b/vis.c
index 60eb9b7..51e2bf0 100644
--- a/vis.c
+++ b/vis.c
@@ -31,8 +31,6 @@
/* hash class keys */
static struct lock_class_key batadv_vis_hash_lock_class_key;
-static void batadv_start_vis_timer(struct batadv_priv *bat_priv);
-
/* free the info */
static void batadv_free_info(struct kref *ref)
{
@@ -830,7 +828,9 @@ static void batadv_send_vis_packets(struct work_struct *work)
kref_put(&info->refcount, batadv_free_info);
}
spin_unlock_bh(&bat_priv->vis.hash_lock);
- batadv_start_vis_timer(bat_priv);
+
+ queue_delayed_work(batadv_event_workqueue, &bat_priv->vis.work,
+ msecs_to_jiffies(BATADV_VIS_INTERVAL));
}
/* init the vis server. this may only be called when if_list is already
@@ -900,7 +900,11 @@ int batadv_vis_init(struct batadv_priv *bat_priv)
}
spin_unlock_bh(&bat_priv->vis.hash_lock);
- batadv_start_vis_timer(bat_priv);
+
+ INIT_DELAYED_WORK(&bat_priv->vis.work, batadv_send_vis_packets);
+ queue_delayed_work(batadv_event_workqueue, &bat_priv->vis.work,
+ msecs_to_jiffies(BATADV_VIS_INTERVAL));
+
return 0;
free_info:
@@ -937,11 +941,3 @@ void batadv_vis_quit(struct batadv_priv *bat_priv)
bat_priv->vis.my_info = NULL;
spin_unlock_bh(&bat_priv->vis.hash_lock);
}
-
-/* schedule packets for (re)transmission */
-static void batadv_start_vis_timer(struct batadv_priv *bat_priv)
-{
- INIT_DELAYED_WORK(&bat_priv->vis.work, batadv_send_vis_packets);
- queue_delayed_work(batadv_event_workqueue, &bat_priv->vis.work,
- msecs_to_jiffies(BATADV_VIS_INTERVAL));
-}
--
1.8.0.2
^ permalink raw reply related
* Re: [Qemu-devel] [PATCH] pcie: Fix bug in pcie_ext_cap_set_next
From: Michael S. Tsirkin @ 2012-12-25 12:18 UTC (permalink / raw)
To: Knut Omang; +Cc: qemu-devel
In-Reply-To: <1355866589.8438.6.camel@ori.omang.mine.nu>
On Tue, Dec 18, 2012 at 10:36:29PM +0100, Knut Omang wrote:
> Upper 16 bits of the PCIe Extended Capability Header was truncated during update,
> also breaking pcie_add_capability.
>
> Signed-off-by: Knut Omang <knut.omang@oracle.com>
Applied, thanks.
> ---
> hw/pcie.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/hw/pcie.c b/hw/pcie.c
> index 7c92f19..fa260af 100644
> --- a/hw/pcie.c
> +++ b/hw/pcie.c
> @@ -494,7 +494,7 @@ uint16_t pcie_find_capability(PCIDevice *dev, uint16_t cap_id)
>
> static void pcie_ext_cap_set_next(PCIDevice *dev, uint16_t pos, uint16_t next)
> {
> - uint16_t header = pci_get_long(dev->config + pos);
> + uint32_t header = pci_get_long(dev->config + pos);
> assert(!(next & (PCI_EXT_CAP_ALIGN - 1)));
> header = (header & ~PCI_EXT_CAP_NEXT_MASK) |
> ((next << PCI_EXT_CAP_NEXT_SHIFT) & PCI_EXT_CAP_NEXT_MASK);
> --
> 1.7.11.7
>
^ permalink raw reply
* Re: [dm-crypt] force luksClose
From: Benjamin Eberhardt @ 2012-12-25 12:17 UTC (permalink / raw)
To: Milan Broz; +Cc: dm-crypt, Matthias Schniedermeyer
In-Reply-To: <50B776CF.60501@gmail.com>
Hi,
thank you very much for your replies. I tried to reproduce the problem
which I had once in order to supply more details, but so far the
procedure you described works very well (identifying the culprit and
luksClose). Ill get back to you if the problem should occur again.
Merry Christmas :)
Benjamin
On 29 November 2012 15:53, Milan Broz <gmazyland@gmail.com> wrote:
> On 11/29/2012 02:43 PM, Matthias Schniedermeyer wrote:
>
>> IOW. It's a problem of finding the culprit who holds the mountpoint
>> open.
>
> Exactly. You cannot remove open (in-use) device-mapper device.
>
> You can it replace with "error" target though (this will detach
> underlying device from mapping.).
>
> Just run "dmsetup remove -f <name>"
> instead of cryptsetup remove/luksClose <name>"
>
> But the dead DM device will still be in system. I can easily add such
> force option to cryptsetup as well but it will not help much.
>
> The correct way is to force unmout fs (or whatever use this device)
> and then remove crypt mapping (see lsblk, lsof etc).
>
> Milan
>
> p.s.
> There is a request to add "auto" removal flag for device-mapper devices
> (automatic remove after last close, similar to loop auto removal).
>
> Once this option will be in kernel cryptsetup will support it too.
> But this will not help with your situation anyway.
^ permalink raw reply
* [Bug 50121] [Regression] Since kernel v3.5 several cards fail to resume, introduced by: 'convert to exec engine, and improve channel sync'
From: bugzilla-daemon-CC+yJ3UmIYqDUpFQwHEjaQ @ 2012-12-25 12:24 UTC (permalink / raw)
To: nouveau-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW
In-Reply-To: <bug-50121-8800-V0hAGp6uBxMKqLRl/0Ahz6D7qz1kEfGD2LY78lusg7I@public.gmane.org/>
[-- Attachment #1.1: Type: text/plain, Size: 547 bytes --]
https://bugs.freedesktop.org/show_bug.cgi?id=50121
--- Comment #34 from Ronald <ronald645-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> ---
Just tested v3.8rc1+nouveau+patch on an NV4E. Suspend and resume works! Though
it takes about 1 minute before it shuts down (hangs somewhere). And maybe 1 or
2 minutes to resume (before screen is restored).
Restarting is faster, but this looks promising. At least it works.
Anyways, no regressions, just improvements.
Thanks Santa!
--
You are receiving this mail because:
You are the assignee for the bug.
[-- Attachment #1.2: Type: text/html, Size: 1439 bytes --]
[-- Attachment #2: Type: text/plain, Size: 181 bytes --]
_______________________________________________
Nouveau mailing list
Nouveau-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org
http://lists.freedesktop.org/mailman/listinfo/nouveau
^ permalink raw reply
* [PATCH] KVM: mmu: remove unused trace event
From: Gleb Natapov @ 2012-12-25 12:34 UTC (permalink / raw)
To: kvm; +Cc: mtosatti
trace_kvm_mmu_delay_free_pages() is no longer used.
Signed-off-by: Gleb Natapov <gleb@redhat.com>
diff --git a/arch/x86/kvm/mmutrace.h b/arch/x86/kvm/mmutrace.h
index cd6e983..b8f6172 100644
--- a/arch/x86/kvm/mmutrace.h
+++ b/arch/x86/kvm/mmutrace.h
@@ -195,12 +195,6 @@ DEFINE_EVENT(kvm_mmu_page_class, kvm_mmu_prepare_zap_page,
TP_ARGS(sp)
);
-DEFINE_EVENT(kvm_mmu_page_class, kvm_mmu_delay_free_pages,
- TP_PROTO(struct kvm_mmu_page *sp),
-
- TP_ARGS(sp)
-);
-
TRACE_EVENT(
mark_mmio_spte,
TP_PROTO(u64 *sptep, gfn_t gfn, unsigned access),
--
Gleb.
^ permalink raw reply related
* Re: [PATCH v3] qemu-kvm/pci-assign: 64 bits bar emulation
From: Gleb Natapov @ 2012-12-25 12:38 UTC (permalink / raw)
To: Xudong Hao; +Cc: alex.williamson, mtosatti, qemu-devel, kvm
In-Reply-To: <1355972844-30235-1-git-send-email-xudong.hao@intel.com>
On Thu, Dec 20, 2012 at 11:07:23AM +0800, Xudong Hao wrote:
> Enable 64 bits bar emulation.
>
> v3 changes from v2:
> - Leave original error string and drop the leading 016.
>
> v2 changes from v1:
> - Change 0lx% to 0x%016 when print a 64 bit variable.
>
> Test pass with the current seabios which already support 64bit pci bars.
>
> Signed-off-by: Xudong Hao <xudong.hao@intel.com>
Thanks, applied to uq/master.
> ---
> hw/kvm/pci-assign.c | 14 ++++++++++----
> 1 files changed, 10 insertions(+), 4 deletions(-)
>
> diff --git a/hw/kvm/pci-assign.c b/hw/kvm/pci-assign.c
> index 7a0998c..2271a2e 100644
> --- a/hw/kvm/pci-assign.c
> +++ b/hw/kvm/pci-assign.c
> @@ -46,6 +46,7 @@
> #define IORESOURCE_IRQ 0x00000400
> #define IORESOURCE_DMA 0x00000800
> #define IORESOURCE_PREFETCH 0x00002000 /* No side effects */
> +#define IORESOURCE_MEM_64 0x00100000
>
> //#define DEVICE_ASSIGNMENT_DEBUG
>
> @@ -442,9 +443,13 @@ static int assigned_dev_register_regions(PCIRegion *io_regions,
>
> /* handle memory io regions */
> if (cur_region->type & IORESOURCE_MEM) {
> - int t = cur_region->type & IORESOURCE_PREFETCH
> - ? PCI_BASE_ADDRESS_MEM_PREFETCH
> - : PCI_BASE_ADDRESS_SPACE_MEMORY;
> + int t = PCI_BASE_ADDRESS_SPACE_MEMORY;
> + if (cur_region->type & IORESOURCE_PREFETCH) {
> + t |= PCI_BASE_ADDRESS_MEM_PREFETCH;
> + }
> + if (cur_region->type & IORESOURCE_MEM_64) {
> + t |= PCI_BASE_ADDRESS_MEM_TYPE_64;
> + }
>
> /* map physical memory */
> pci_dev->v_addrs[i].u.r_virtbase = mmap(NULL, cur_region->size,
> @@ -632,7 +637,8 @@ again:
> rp->valid = 0;
> rp->resource_fd = -1;
> size = end - start + 1;
> - flags &= IORESOURCE_IO | IORESOURCE_MEM | IORESOURCE_PREFETCH;
> + flags &= IORESOURCE_IO | IORESOURCE_MEM | IORESOURCE_PREFETCH
> + | IORESOURCE_MEM_64;
> if (size == 0 || (flags & ~IORESOURCE_PREFETCH) == 0) {
> continue;
> }
> --
> 1.5.5
--
Gleb.
^ permalink raw reply
* Re: [Qemu-devel] [PATCH v3] qemu-kvm/pci-assign: 64 bits bar emulation
From: Gleb Natapov @ 2012-12-25 12:38 UTC (permalink / raw)
To: Xudong Hao; +Cc: alex.williamson, mtosatti, qemu-devel, kvm
In-Reply-To: <1355972844-30235-1-git-send-email-xudong.hao@intel.com>
On Thu, Dec 20, 2012 at 11:07:23AM +0800, Xudong Hao wrote:
> Enable 64 bits bar emulation.
>
> v3 changes from v2:
> - Leave original error string and drop the leading 016.
>
> v2 changes from v1:
> - Change 0lx% to 0x%016 when print a 64 bit variable.
>
> Test pass with the current seabios which already support 64bit pci bars.
>
> Signed-off-by: Xudong Hao <xudong.hao@intel.com>
Thanks, applied to uq/master.
> ---
> hw/kvm/pci-assign.c | 14 ++++++++++----
> 1 files changed, 10 insertions(+), 4 deletions(-)
>
> diff --git a/hw/kvm/pci-assign.c b/hw/kvm/pci-assign.c
> index 7a0998c..2271a2e 100644
> --- a/hw/kvm/pci-assign.c
> +++ b/hw/kvm/pci-assign.c
> @@ -46,6 +46,7 @@
> #define IORESOURCE_IRQ 0x00000400
> #define IORESOURCE_DMA 0x00000800
> #define IORESOURCE_PREFETCH 0x00002000 /* No side effects */
> +#define IORESOURCE_MEM_64 0x00100000
>
> //#define DEVICE_ASSIGNMENT_DEBUG
>
> @@ -442,9 +443,13 @@ static int assigned_dev_register_regions(PCIRegion *io_regions,
>
> /* handle memory io regions */
> if (cur_region->type & IORESOURCE_MEM) {
> - int t = cur_region->type & IORESOURCE_PREFETCH
> - ? PCI_BASE_ADDRESS_MEM_PREFETCH
> - : PCI_BASE_ADDRESS_SPACE_MEMORY;
> + int t = PCI_BASE_ADDRESS_SPACE_MEMORY;
> + if (cur_region->type & IORESOURCE_PREFETCH) {
> + t |= PCI_BASE_ADDRESS_MEM_PREFETCH;
> + }
> + if (cur_region->type & IORESOURCE_MEM_64) {
> + t |= PCI_BASE_ADDRESS_MEM_TYPE_64;
> + }
>
> /* map physical memory */
> pci_dev->v_addrs[i].u.r_virtbase = mmap(NULL, cur_region->size,
> @@ -632,7 +637,8 @@ again:
> rp->valid = 0;
> rp->resource_fd = -1;
> size = end - start + 1;
> - flags &= IORESOURCE_IO | IORESOURCE_MEM | IORESOURCE_PREFETCH;
> + flags &= IORESOURCE_IO | IORESOURCE_MEM | IORESOURCE_PREFETCH
> + | IORESOURCE_MEM_64;
> if (size == 0 || (flags & ~IORESOURCE_PREFETCH) == 0) {
> continue;
> }
> --
> 1.5.5
--
Gleb.
^ permalink raw reply
* Re: [PATCH v2 5/5] virtio-scsi: introduce multiqueue support
From: Wanlong Gao @ 2012-12-25 12:41 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: Paolo Bonzini, linux-kernel, kvm, hutao, linux-scsi,
virtualization, rusty, asias, stefanha, nab
In-Reply-To: <20121218160226.GA28445@redhat.com>
On 12/19/2012 12:02 AM, Michael S. Tsirkin wrote:
> On Tue, Dec 18, 2012 at 04:51:28PM +0100, Paolo Bonzini wrote:
>> Il 18/12/2012 16:03, Michael S. Tsirkin ha scritto:
>>> On Tue, Dec 18, 2012 at 03:08:08PM +0100, Paolo Bonzini wrote:
>>>> Il 18/12/2012 14:57, Michael S. Tsirkin ha scritto:
>>>>>> -static int virtscsi_queuecommand(struct Scsi_Host *sh, struct scsi_cmnd *sc)
>>>>>> +static int virtscsi_queuecommand(struct virtio_scsi *vscsi,
>>>>>> + struct virtio_scsi_target_state *tgt,
>>>>>> + struct scsi_cmnd *sc)
>>>>>> {
>>>>>> - struct virtio_scsi *vscsi = shost_priv(sh);
>>>>>> - struct virtio_scsi_target_state *tgt = &vscsi->tgt[sc->device->id];
>>>>>> struct virtio_scsi_cmd *cmd;
>>>>>> + struct virtio_scsi_vq *req_vq;
>>>>>> int ret;
>>>>>>
>>>>>> struct Scsi_Host *shost = virtio_scsi_host(vscsi->vdev);
>>>>>> @@ -461,7 +533,8 @@ static int virtscsi_queuecommand(struct Scsi_Host *sh, struct scsi_cmnd *sc)
>>>>>> BUG_ON(sc->cmd_len > VIRTIO_SCSI_CDB_SIZE);
>>>>>> memcpy(cmd->req.cmd.cdb, sc->cmnd, sc->cmd_len);
>>>>>>
>>>>>> - if (virtscsi_kick_cmd(tgt, &vscsi->req_vq, cmd,
>>>>>> + req_vq = ACCESS_ONCE(tgt->req_vq);
>>>>>
>>>>> This ACCESS_ONCE without a barrier looks strange to me.
>>>>> Can req_vq change? Needs a comment.
>>>>
>>>> Barriers are needed to order two things. Here I don't have the second thing
>>>> to order against, hence no barrier.
>>>>
>>>> Accessing req_vq lockless is safe, and there's a comment about it, but you
>>>> still want ACCESS_ONCE to ensure the compiler doesn't play tricks.
>>>
>>> That's just it.
>>> Why don't you want compiler to play tricks?
>>
>> Because I want the lockless access to occur exactly when I write it.
>
> It doesn't occur when you write it. CPU can still move accesses
> around. That's why you either need both ACCESS_ONCE and a barrier
> or none.
>
>> Otherwise I have one more thing to think about, i.e. what a crazy
>> compiler writer could do with my code. And having been on the other
>> side of the trench, compiler writers can have *really* crazy ideas.
>>
>> Anyhow, I'll reorganize the code to move the ACCESS_ONCE closer to the
>> write and make it clearer.
>>
>>>>>> + if (virtscsi_kick_cmd(tgt, req_vq, cmd,
>>>>>> sizeof cmd->req.cmd, sizeof cmd->resp.cmd,
>>>>>> GFP_ATOMIC) == 0)
>>>>>> ret = 0;
>>>>>> @@ -472,6 +545,48 @@ out:
>>>>>> return ret;
>>>>>> }
>>>>>>
>>>>>> +static int virtscsi_queuecommand_single(struct Scsi_Host *sh,
>>>>>> + struct scsi_cmnd *sc)
>>>>>> +{
>>>>>> + struct virtio_scsi *vscsi = shost_priv(sh);
>>>>>> + struct virtio_scsi_target_state *tgt = &vscsi->tgt[sc->device->id];
>>>>>> +
>>>>>> + atomic_inc(&tgt->reqs);
>>>>>
>>>>> And here we don't have barrier after atomic? Why? Needs a comment.
>>>>
>>>> Because we don't write req_vq, so there's no two writes to order. Barrier
>>>> against what?
>>>
>>> Between atomic update and command. Once you queue command it
>>> can complete and decrement reqs, if this happens before
>>> increment reqs can become negative even.
>>
>> This is not a problem. Please read Documentation/memory-barrier.txt:
>>
>> The following also do _not_ imply memory barriers, and so may
>> require explicit memory barriers under some circumstances
>> (smp_mb__before_atomic_dec() for instance):
>>
>> atomic_add();
>> atomic_sub();
>> atomic_inc();
>> atomic_dec();
>>
>> If they're used for statistics generation, then they probably don't
>> need memory barriers, unless there's a coupling between statistical
>> data.
>>
>> This is the single-queue case, so it falls under this case.
>
> Aha I missed it's single queue. Correct but please add a comment.
>
>>>>>> /* Discover virtqueues and write information to configuration. */
>>>>>> - err = vdev->config->find_vqs(vdev, 3, vqs, callbacks, names);
>>>>>> + err = vdev->config->find_vqs(vdev, num_vqs, vqs, callbacks, names);
>>>>>> if (err)
>>>>>> return err;
>>>>>>
>>>>>> - virtscsi_init_vq(&vscsi->ctrl_vq, vqs[0]);
>>>>>> - virtscsi_init_vq(&vscsi->event_vq, vqs[1]);
>>>>>> - virtscsi_init_vq(&vscsi->req_vq, vqs[2]);
>>>>>> + virtscsi_init_vq(&vscsi->ctrl_vq, vqs[0], false);
>>>>>> + virtscsi_init_vq(&vscsi->event_vq, vqs[1], false);
>>>>>> + for (i = VIRTIO_SCSI_VQ_BASE; i < num_vqs; i++)
>>>>>> + virtscsi_init_vq(&vscsi->req_vqs[i - VIRTIO_SCSI_VQ_BASE],
>>>>>> + vqs[i], vscsi->num_queues > 1);
>>>>>
>>>>> So affinity is true if >1 vq? I am guessing this is not
>>>>> going to do the right thing unless you have at least
>>>>> as many vqs as CPUs.
>>>>
>>>> Yes, and then you're not setting up the thing correctly.
>>>
>>> Why not just check instead of doing the wrong thing?
>>
>> The right thing could be to set the affinity with a stride, e.g. CPUs
>> 0-4 for virtqueue 0 and so on until CPUs 3-7 for virtqueue 3.
>>
>> Paolo
>
> I think a simple #vqs == #cpus check would be kind of OK for
> starters, otherwise let userspace set affinity.
> Again need to think what happens with CPU hotplug.
How about dynamicly setting affinity this way?
========================================================================
Subject: [PATCH] virtio-scsi: set virtqueue affinity under cpu hotplug
We set virtqueue affinity when the num_queues equals to the number
of VCPUs. Register a hotcpu notifier to notifier whether the
VCPU number is changed. If the VCPU number is changed, we
force to set virtqueue affinity again.
Signed-off-by: Wanlong Gao <gaowanlong@cn.fujitsu.com>
---
drivers/scsi/virtio_scsi.c | 72 ++++++++++++++++++++++++++++++++++++++++++----
1 file changed, 66 insertions(+), 6 deletions(-)
diff --git a/drivers/scsi/virtio_scsi.c b/drivers/scsi/virtio_scsi.c
index 3641d5f..1b28e03 100644
--- a/drivers/scsi/virtio_scsi.c
+++ b/drivers/scsi/virtio_scsi.c
@@ -20,6 +20,7 @@
#include <linux/virtio_ids.h>
#include <linux/virtio_config.h>
#include <linux/virtio_scsi.h>
+#include <linux/cpu.h>
#include <scsi/scsi_host.h>
#include <scsi/scsi_device.h>
#include <scsi/scsi_cmnd.h>
@@ -106,6 +107,9 @@ struct virtio_scsi {
u32 num_queues;
+ /* Does the affinity hint is set for virtqueues? */
+ bool affinity_hint_set;
+
struct virtio_scsi_vq ctrl_vq;
struct virtio_scsi_vq event_vq;
struct virtio_scsi_vq req_vqs[];
@@ -113,6 +117,7 @@ struct virtio_scsi {
static struct kmem_cache *virtscsi_cmd_cache;
static mempool_t *virtscsi_cmd_pool;
+static bool cpu_hotplug = false;
static inline struct Scsi_Host *virtio_scsi_host(struct virtio_device *vdev)
{
@@ -555,6 +560,52 @@ static int virtscsi_queuecommand_single(struct Scsi_Host *sh,
return virtscsi_queuecommand(vscsi, tgt, sc);
}
+static void virtscsi_set_affinity(struct virtio_scsi *vscsi,
+ bool affinity)
+{
+ int i;
+
+ /* In multiqueue mode, when the number of cpu is equal to the number of
+ * request queues , we let the queues to be private to one cpu by
+ * setting the affinity hint to eliminate the contention.
+ */
+ if ((vscsi->num_queues == 1 ||
+ vscsi->num_queues != num_online_cpus()) && affinity) {
+ if (vscsi->affinity_hint_set)
+ affinity = false;
+ else
+ return;
+ }
+
+ for (i = 0; i < vscsi->num_queues - VIRTIO_SCSI_VQ_BASE; i++) {
+ int cpu = affinity ? i : -1;
+ virtqueue_set_affinity(vscsi->req_vqs[i].vq, cpu);
+ }
+
+ if (affinity)
+ vscsi->affinity_hint_set = true;
+ else
+ vscsi->affinity_hint_set = false;
+}
+
+static int __cpuinit virtscsi_cpu_callback(struct notifier_block *nfb,
+ unsigned long action, void *hcpu)
+{
+ switch (action) {
+ case CPU_ONLINE:
+ case CPU_ONLINE_FROZEN:
+ case CPU_DEAD:
+ case CPU_DEAD_FROZEN:
+ cpu_hotplug = true;
+ }
+ return NOTIFY_OK;
+}
+
+static struct notifier_block __cpuinitdata virtscsi_cpu_notifier =
+{
+ .notifier_call = virtscsi_cpu_callback,
+};
+
static int virtscsi_queuecommand_multi(struct Scsi_Host *sh,
struct scsi_cmnd *sc)
{
@@ -563,6 +614,11 @@ static int virtscsi_queuecommand_multi(struct Scsi_Host *sh,
unsigned long flags;
u32 queue_num;
+ if (unlikely(cpu_hotplug == true)) {
+ virtscsi_set_affinity(vscsi, true);
+ cpu_hotplug = false;
+ }
+
/*
* Using an atomic_t for tgt->reqs lets the virtqueue handler
* decrement it without taking the spinlock.
@@ -703,12 +759,10 @@ static struct scsi_host_template virtscsi_host_template_multi = {
static void virtscsi_init_vq(struct virtio_scsi_vq *virtscsi_vq,
- struct virtqueue *vq, bool affinity)
+ struct virtqueue *vq)
{
spin_lock_init(&virtscsi_vq->vq_lock);
virtscsi_vq->vq = vq;
- if (affinity)
- virtqueue_set_affinity(vq, vq->index - VIRTIO_SCSI_VQ_BASE);
}
static void virtscsi_init_tgt(struct virtio_scsi *vscsi, int i)
@@ -736,6 +790,8 @@ static void virtscsi_remove_vqs(struct virtio_device *vdev)
struct Scsi_Host *sh = virtio_scsi_host(vdev);
struct virtio_scsi *vscsi = shost_priv(sh);
+ virtscsi_set_affinity(vscsi, false);
+
/* Stop all the virtqueues. */
vdev->config->reset(vdev);
@@ -779,11 +835,14 @@ static int virtscsi_init(struct virtio_device *vdev,
if (err)
return err;
- virtscsi_init_vq(&vscsi->ctrl_vq, vqs[0], false);
- virtscsi_init_vq(&vscsi->event_vq, vqs[1], false);
+ virtscsi_init_vq(&vscsi->ctrl_vq, vqs[0]);
+ virtscsi_init_vq(&vscsi->event_vq, vqs[1]);
for (i = VIRTIO_SCSI_VQ_BASE; i < num_vqs; i++)
virtscsi_init_vq(&vscsi->req_vqs[i - VIRTIO_SCSI_VQ_BASE],
- vqs[i], vscsi->num_queues > 1);
+ vqs[i]);
+
+ virtscsi_set_affinity(vscsi, true);
+ register_hotcpu_notifier(&virtscsi_cpu_notifier);
virtscsi_config_set(vdev, cdb_size, VIRTIO_SCSI_CDB_SIZE);
virtscsi_config_set(vdev, sense_size, VIRTIO_SCSI_SENSE_SIZE);
@@ -882,6 +941,7 @@ static void __devexit virtscsi_remove(struct virtio_device *vdev)
struct Scsi_Host *shost = virtio_scsi_host(vdev);
struct virtio_scsi *vscsi = shost_priv(shost);
+ unregister_hotcpu_notifier(&virtscsi_cpu_notifier);
if (virtio_has_feature(vdev, VIRTIO_SCSI_F_HOTPLUG))
virtscsi_cancel_event_work(vscsi);
--
1.8.0
Thanks,
Wanlong Gao
>
>>>> Isn't the same thing true for virtio-net mq?
>>>>
>>>> Paolo
>>>
>>> Last I looked it checked vi->max_queue_pairs == num_online_cpus().
>>> This is even too aggressive I think, max_queue_pairs >=
>>> num_online_cpus() should be enough.
>>>
>
^ permalink raw reply related
* Re: [PATCH v2 5/5] virtio-scsi: introduce multiqueue support
From: Wanlong Gao @ 2012-12-25 12:41 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: kvm, linux-scsi, hutao, linux-kernel, virtualization, stefanha,
Paolo Bonzini
In-Reply-To: <20121218160226.GA28445@redhat.com>
On 12/19/2012 12:02 AM, Michael S. Tsirkin wrote:
> On Tue, Dec 18, 2012 at 04:51:28PM +0100, Paolo Bonzini wrote:
>> Il 18/12/2012 16:03, Michael S. Tsirkin ha scritto:
>>> On Tue, Dec 18, 2012 at 03:08:08PM +0100, Paolo Bonzini wrote:
>>>> Il 18/12/2012 14:57, Michael S. Tsirkin ha scritto:
>>>>>> -static int virtscsi_queuecommand(struct Scsi_Host *sh, struct scsi_cmnd *sc)
>>>>>> +static int virtscsi_queuecommand(struct virtio_scsi *vscsi,
>>>>>> + struct virtio_scsi_target_state *tgt,
>>>>>> + struct scsi_cmnd *sc)
>>>>>> {
>>>>>> - struct virtio_scsi *vscsi = shost_priv(sh);
>>>>>> - struct virtio_scsi_target_state *tgt = &vscsi->tgt[sc->device->id];
>>>>>> struct virtio_scsi_cmd *cmd;
>>>>>> + struct virtio_scsi_vq *req_vq;
>>>>>> int ret;
>>>>>>
>>>>>> struct Scsi_Host *shost = virtio_scsi_host(vscsi->vdev);
>>>>>> @@ -461,7 +533,8 @@ static int virtscsi_queuecommand(struct Scsi_Host *sh, struct scsi_cmnd *sc)
>>>>>> BUG_ON(sc->cmd_len > VIRTIO_SCSI_CDB_SIZE);
>>>>>> memcpy(cmd->req.cmd.cdb, sc->cmnd, sc->cmd_len);
>>>>>>
>>>>>> - if (virtscsi_kick_cmd(tgt, &vscsi->req_vq, cmd,
>>>>>> + req_vq = ACCESS_ONCE(tgt->req_vq);
>>>>>
>>>>> This ACCESS_ONCE without a barrier looks strange to me.
>>>>> Can req_vq change? Needs a comment.
>>>>
>>>> Barriers are needed to order two things. Here I don't have the second thing
>>>> to order against, hence no barrier.
>>>>
>>>> Accessing req_vq lockless is safe, and there's a comment about it, but you
>>>> still want ACCESS_ONCE to ensure the compiler doesn't play tricks.
>>>
>>> That's just it.
>>> Why don't you want compiler to play tricks?
>>
>> Because I want the lockless access to occur exactly when I write it.
>
> It doesn't occur when you write it. CPU can still move accesses
> around. That's why you either need both ACCESS_ONCE and a barrier
> or none.
>
>> Otherwise I have one more thing to think about, i.e. what a crazy
>> compiler writer could do with my code. And having been on the other
>> side of the trench, compiler writers can have *really* crazy ideas.
>>
>> Anyhow, I'll reorganize the code to move the ACCESS_ONCE closer to the
>> write and make it clearer.
>>
>>>>>> + if (virtscsi_kick_cmd(tgt, req_vq, cmd,
>>>>>> sizeof cmd->req.cmd, sizeof cmd->resp.cmd,
>>>>>> GFP_ATOMIC) == 0)
>>>>>> ret = 0;
>>>>>> @@ -472,6 +545,48 @@ out:
>>>>>> return ret;
>>>>>> }
>>>>>>
>>>>>> +static int virtscsi_queuecommand_single(struct Scsi_Host *sh,
>>>>>> + struct scsi_cmnd *sc)
>>>>>> +{
>>>>>> + struct virtio_scsi *vscsi = shost_priv(sh);
>>>>>> + struct virtio_scsi_target_state *tgt = &vscsi->tgt[sc->device->id];
>>>>>> +
>>>>>> + atomic_inc(&tgt->reqs);
>>>>>
>>>>> And here we don't have barrier after atomic? Why? Needs a comment.
>>>>
>>>> Because we don't write req_vq, so there's no two writes to order. Barrier
>>>> against what?
>>>
>>> Between atomic update and command. Once you queue command it
>>> can complete and decrement reqs, if this happens before
>>> increment reqs can become negative even.
>>
>> This is not a problem. Please read Documentation/memory-barrier.txt:
>>
>> The following also do _not_ imply memory barriers, and so may
>> require explicit memory barriers under some circumstances
>> (smp_mb__before_atomic_dec() for instance):
>>
>> atomic_add();
>> atomic_sub();
>> atomic_inc();
>> atomic_dec();
>>
>> If they're used for statistics generation, then they probably don't
>> need memory barriers, unless there's a coupling between statistical
>> data.
>>
>> This is the single-queue case, so it falls under this case.
>
> Aha I missed it's single queue. Correct but please add a comment.
>
>>>>>> /* Discover virtqueues and write information to configuration. */
>>>>>> - err = vdev->config->find_vqs(vdev, 3, vqs, callbacks, names);
>>>>>> + err = vdev->config->find_vqs(vdev, num_vqs, vqs, callbacks, names);
>>>>>> if (err)
>>>>>> return err;
>>>>>>
>>>>>> - virtscsi_init_vq(&vscsi->ctrl_vq, vqs[0]);
>>>>>> - virtscsi_init_vq(&vscsi->event_vq, vqs[1]);
>>>>>> - virtscsi_init_vq(&vscsi->req_vq, vqs[2]);
>>>>>> + virtscsi_init_vq(&vscsi->ctrl_vq, vqs[0], false);
>>>>>> + virtscsi_init_vq(&vscsi->event_vq, vqs[1], false);
>>>>>> + for (i = VIRTIO_SCSI_VQ_BASE; i < num_vqs; i++)
>>>>>> + virtscsi_init_vq(&vscsi->req_vqs[i - VIRTIO_SCSI_VQ_BASE],
>>>>>> + vqs[i], vscsi->num_queues > 1);
>>>>>
>>>>> So affinity is true if >1 vq? I am guessing this is not
>>>>> going to do the right thing unless you have at least
>>>>> as many vqs as CPUs.
>>>>
>>>> Yes, and then you're not setting up the thing correctly.
>>>
>>> Why not just check instead of doing the wrong thing?
>>
>> The right thing could be to set the affinity with a stride, e.g. CPUs
>> 0-4 for virtqueue 0 and so on until CPUs 3-7 for virtqueue 3.
>>
>> Paolo
>
> I think a simple #vqs == #cpus check would be kind of OK for
> starters, otherwise let userspace set affinity.
> Again need to think what happens with CPU hotplug.
How about dynamicly setting affinity this way?
========================================================================
Subject: [PATCH] virtio-scsi: set virtqueue affinity under cpu hotplug
We set virtqueue affinity when the num_queues equals to the number
of VCPUs. Register a hotcpu notifier to notifier whether the
VCPU number is changed. If the VCPU number is changed, we
force to set virtqueue affinity again.
Signed-off-by: Wanlong Gao <gaowanlong@cn.fujitsu.com>
---
drivers/scsi/virtio_scsi.c | 72 ++++++++++++++++++++++++++++++++++++++++++----
1 file changed, 66 insertions(+), 6 deletions(-)
diff --git a/drivers/scsi/virtio_scsi.c b/drivers/scsi/virtio_scsi.c
index 3641d5f..1b28e03 100644
--- a/drivers/scsi/virtio_scsi.c
+++ b/drivers/scsi/virtio_scsi.c
@@ -20,6 +20,7 @@
#include <linux/virtio_ids.h>
#include <linux/virtio_config.h>
#include <linux/virtio_scsi.h>
+#include <linux/cpu.h>
#include <scsi/scsi_host.h>
#include <scsi/scsi_device.h>
#include <scsi/scsi_cmnd.h>
@@ -106,6 +107,9 @@ struct virtio_scsi {
u32 num_queues;
+ /* Does the affinity hint is set for virtqueues? */
+ bool affinity_hint_set;
+
struct virtio_scsi_vq ctrl_vq;
struct virtio_scsi_vq event_vq;
struct virtio_scsi_vq req_vqs[];
@@ -113,6 +117,7 @@ struct virtio_scsi {
static struct kmem_cache *virtscsi_cmd_cache;
static mempool_t *virtscsi_cmd_pool;
+static bool cpu_hotplug = false;
static inline struct Scsi_Host *virtio_scsi_host(struct virtio_device *vdev)
{
@@ -555,6 +560,52 @@ static int virtscsi_queuecommand_single(struct Scsi_Host *sh,
return virtscsi_queuecommand(vscsi, tgt, sc);
}
+static void virtscsi_set_affinity(struct virtio_scsi *vscsi,
+ bool affinity)
+{
+ int i;
+
+ /* In multiqueue mode, when the number of cpu is equal to the number of
+ * request queues , we let the queues to be private to one cpu by
+ * setting the affinity hint to eliminate the contention.
+ */
+ if ((vscsi->num_queues == 1 ||
+ vscsi->num_queues != num_online_cpus()) && affinity) {
+ if (vscsi->affinity_hint_set)
+ affinity = false;
+ else
+ return;
+ }
+
+ for (i = 0; i < vscsi->num_queues - VIRTIO_SCSI_VQ_BASE; i++) {
+ int cpu = affinity ? i : -1;
+ virtqueue_set_affinity(vscsi->req_vqs[i].vq, cpu);
+ }
+
+ if (affinity)
+ vscsi->affinity_hint_set = true;
+ else
+ vscsi->affinity_hint_set = false;
+}
+
+static int __cpuinit virtscsi_cpu_callback(struct notifier_block *nfb,
+ unsigned long action, void *hcpu)
+{
+ switch (action) {
+ case CPU_ONLINE:
+ case CPU_ONLINE_FROZEN:
+ case CPU_DEAD:
+ case CPU_DEAD_FROZEN:
+ cpu_hotplug = true;
+ }
+ return NOTIFY_OK;
+}
+
+static struct notifier_block __cpuinitdata virtscsi_cpu_notifier =
+{
+ .notifier_call = virtscsi_cpu_callback,
+};
+
static int virtscsi_queuecommand_multi(struct Scsi_Host *sh,
struct scsi_cmnd *sc)
{
@@ -563,6 +614,11 @@ static int virtscsi_queuecommand_multi(struct Scsi_Host *sh,
unsigned long flags;
u32 queue_num;
+ if (unlikely(cpu_hotplug == true)) {
+ virtscsi_set_affinity(vscsi, true);
+ cpu_hotplug = false;
+ }
+
/*
* Using an atomic_t for tgt->reqs lets the virtqueue handler
* decrement it without taking the spinlock.
@@ -703,12 +759,10 @@ static struct scsi_host_template virtscsi_host_template_multi = {
static void virtscsi_init_vq(struct virtio_scsi_vq *virtscsi_vq,
- struct virtqueue *vq, bool affinity)
+ struct virtqueue *vq)
{
spin_lock_init(&virtscsi_vq->vq_lock);
virtscsi_vq->vq = vq;
- if (affinity)
- virtqueue_set_affinity(vq, vq->index - VIRTIO_SCSI_VQ_BASE);
}
static void virtscsi_init_tgt(struct virtio_scsi *vscsi, int i)
@@ -736,6 +790,8 @@ static void virtscsi_remove_vqs(struct virtio_device *vdev)
struct Scsi_Host *sh = virtio_scsi_host(vdev);
struct virtio_scsi *vscsi = shost_priv(sh);
+ virtscsi_set_affinity(vscsi, false);
+
/* Stop all the virtqueues. */
vdev->config->reset(vdev);
@@ -779,11 +835,14 @@ static int virtscsi_init(struct virtio_device *vdev,
if (err)
return err;
- virtscsi_init_vq(&vscsi->ctrl_vq, vqs[0], false);
- virtscsi_init_vq(&vscsi->event_vq, vqs[1], false);
+ virtscsi_init_vq(&vscsi->ctrl_vq, vqs[0]);
+ virtscsi_init_vq(&vscsi->event_vq, vqs[1]);
for (i = VIRTIO_SCSI_VQ_BASE; i < num_vqs; i++)
virtscsi_init_vq(&vscsi->req_vqs[i - VIRTIO_SCSI_VQ_BASE],
- vqs[i], vscsi->num_queues > 1);
+ vqs[i]);
+
+ virtscsi_set_affinity(vscsi, true);
+ register_hotcpu_notifier(&virtscsi_cpu_notifier);
virtscsi_config_set(vdev, cdb_size, VIRTIO_SCSI_CDB_SIZE);
virtscsi_config_set(vdev, sense_size, VIRTIO_SCSI_SENSE_SIZE);
@@ -882,6 +941,7 @@ static void __devexit virtscsi_remove(struct virtio_device *vdev)
struct Scsi_Host *shost = virtio_scsi_host(vdev);
struct virtio_scsi *vscsi = shost_priv(shost);
+ unregister_hotcpu_notifier(&virtscsi_cpu_notifier);
if (virtio_has_feature(vdev, VIRTIO_SCSI_F_HOTPLUG))
virtscsi_cancel_event_work(vscsi);
--
1.8.0
Thanks,
Wanlong Gao
>
>>>> Isn't the same thing true for virtio-net mq?
>>>>
>>>> Paolo
>>>
>>> Last I looked it checked vi->max_queue_pairs == num_online_cpus().
>>> This is even too aggressive I think, max_queue_pairs >=
>>> num_online_cpus() should be enough.
>>>
>
^ permalink raw reply related
* Re: KVM: VMX: fix incorrect cached cpl value with real/v8086 modes
From: Gleb Natapov @ 2012-12-25 12:48 UTC (permalink / raw)
To: Avi Kivity; +Cc: Marcelo Tosatti, kvm
In-Reply-To: <CAEbWair0awmpB9QXFGXJmooSsHg3B6P3uZrmLcyzs=T70TS7VA@mail.gmail.com>
On Sat, Dec 22, 2012 at 02:31:10PM +0200, Avi Kivity wrote:
> On Wed, Dec 19, 2012 at 3:29 PM, Marcelo Tosatti <mtosatti@redhat.com>wrote:
>
> >
> >
> > CPL is always 0 when in real mode, and always 3 when virtual 8086 mode.
> >
> > Using values other than those can cause failures on operations that check
> > CPL.
> >
> > Signed-off-by: Marcelo Tosatti <mtosatti@redhat.com>
> >
> > diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
> > index a4ecf7c..3abe433 100644
> > --- a/arch/x86/kvm/vmx.c
> > +++ b/arch/x86/kvm/vmx.c
> > @@ -3215,13 +3215,6 @@ static u64 vmx_get_segment_base(struct kvm_vcpu
> > *vcpu, int seg)
> >
> > static int __vmx_get_cpl(struct kvm_vcpu *vcpu)
> > {
> > - if (!is_protmode(vcpu))
> > - return 0;
> > -
> > - if (!is_long_mode(vcpu)
> > - && (kvm_get_rflags(vcpu) & X86_EFLAGS_VM)) /* if virtual 8086
> > */
> > - return 3;
> > -
> > return vmx_read_guest_seg_selector(to_vmx(vcpu), VCPU_SREG_CS) & 3;
> > }
> >
> > @@ -3229,6 +3222,13 @@ static int vmx_get_cpl(struct kvm_vcpu *vcpu)
> > {
> > struct vcpu_vmx *vmx = to_vmx(vcpu);
> >
> > + if (!is_protmode(vcpu))
> > + return 0;
> > +
> > + if (!is_long_mode(vcpu)
> > + && (kvm_get_rflags(vcpu) & X86_EFLAGS_VM)) /* if virtual 8086
> > */
> > + return 3;
> > +
> > /*
> > * If we enter real mode with cs.sel & 3 != 0, the normal CPL
> > calculations
> > * fail; use the cache instead.
> >
>
>
> This undoes the cache, now every vmx_get_cpl() in protected mode has to
> VMREAD(GUEST_RFLAGS).
True. Marcelo what failure do you see without the patch?
--
Gleb.
^ permalink raw reply
* [Bug 51881] HighPoint RocketRAID 2720 fail to detect some SATA hdd
From: bugzilla-daemon @ 2012-12-25 12:50 UTC (permalink / raw)
To: linux-scsi
In-Reply-To: <bug-51881-11613@https.bugzilla.kernel.org/>
https://bugzilla.kernel.org/show_bug.cgi?id=51881
--- Comment #6 from Kouichi ONO <kou1.ono@gmail.com> 2012-12-25 12:50:53 ---
3.7.1 with attached patch works fine, all hdds found.
Thanks!
--
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
^ permalink raw reply
* [PATCH 2/3] mmc: esdhc i.MX: Fix version register read
From: Shawn Guo @ 2012-12-25 13:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1348471345-30785-3-git-send-email-s.hauer@pengutronix.de>
Hi Sascha,
On Mon, Sep 24, 2012 at 09:22:24AM +0200, Sascha Hauer wrote:
> The i.MX ESDHC controller version register is a mess:
>
> - i.MX25 has a v1 controller which identifies itself as v2
> - i.MX6Q has a v3 controller which identifies itself as v4
> - i.MX35,51,53 have v2 controllers which identify themselves correctly
When looking at these a second time, I start doubting the statement
about i.MX25. Since i.MX25 is actually a newer SoC than i.MX35, it
sounds unreasonable that i.MX35 runs a v2 controller while i.MX25 runs
a v1.
The confirmation from designer tells that i.MX25 runs a v2 controller
too. This also matches the statement of "SD Host Controller Standard
Specification Version 2.0" listed in IMX25RM 23.1.1 Features chapter.
You probably got the impression that i.MX25 has a v1 controller by
reading the HOSTVER_SVN bit description. While it says 0x00 - SD Host
Specification Version 1.0, the register value is actually 0x01.
So the esdhc host version register indeed encodes the correct value
for all i.MX SoCs except imx6q. Thus, I prefer to replace the patch
with the one below.
Also I'm working on a big series to make esdhc driver more feature
complete for imx6q, including 8bit support, so I would like to pick
up your work from here.
Shawn
---8<------
[PATCH] mmc: sdhci-esdhc-imx: fix host version read
When commit 95a2482 (mmc: sdhci-esdhc-imx: add basic imx6q usdhc
support) works around host version issue on imx6q, it gets the
register address fixup "reg ^= 2" lost for imx25/35/51/53 esdhc.
Thus, the controller version on these SoCs is wrongly identified
as v1 while it's actually v2.
Add the address fixup back and take a different approach to correct
imx6q host version, so that the host version read gets back to work
for all SoCs.
Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
Cc: <stable@vger.kernel.org>
---
drivers/mmc/host/sdhci-esdhc-imx.c | 19 +++++++++++--------
1 file changed, 11 insertions(+), 8 deletions(-)
diff --git a/drivers/mmc/host/sdhci-esdhc-imx.c b/drivers/mmc/host/sdhci-esdhc-imx.c
index e07df81..b503113 100644
--- a/drivers/mmc/host/sdhci-esdhc-imx.c
+++ b/drivers/mmc/host/sdhci-esdhc-imx.c
@@ -237,15 +237,18 @@ static void esdhc_writel_le(struct sdhci_host *host, u32 val, int reg)
static u16 esdhc_readw_le(struct sdhci_host *host, int reg)
{
+ struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
+ struct pltfm_imx_data *imx_data = pltfm_host->priv;
+
if (unlikely(reg == SDHCI_HOST_VERSION)) {
- u16 val = readw(host->ioaddr + (reg ^ 2));
- /*
- * uSDHC supports SDHCI v3.0, but it's encoded as value
- * 0x3 in host controller version register, which violates
- * SDHCI_SPEC_300 definition. Work it around here.
- */
- if ((val & SDHCI_SPEC_VER_MASK) == 3)
- return --val;
+ reg ^= 2;
+ if (is_imx6q_usdhc(imx_data)) {
+ /*
+ * The usdhc register returns a wrong host version.
+ * Correct it here.
+ */
+ return SDHCI_SPEC_300;
+ }
}
return readw(host->ioaddr + reg);
--
1.7.9.5
^ permalink raw reply related
* Re: [PATCH 2/3] mmc: esdhc i.MX: Fix version register read
From: Shawn Guo @ 2012-12-25 13:00 UTC (permalink / raw)
To: Sascha Hauer
Cc: linux-mmc, linux-arm-kernel, Chris Ball, Eric Bénard, kernel
In-Reply-To: <1348471345-30785-3-git-send-email-s.hauer@pengutronix.de>
Hi Sascha,
On Mon, Sep 24, 2012 at 09:22:24AM +0200, Sascha Hauer wrote:
> The i.MX ESDHC controller version register is a mess:
>
> - i.MX25 has a v1 controller which identifies itself as v2
> - i.MX6Q has a v3 controller which identifies itself as v4
> - i.MX35,51,53 have v2 controllers which identify themselves correctly
When looking at these a second time, I start doubting the statement
about i.MX25. Since i.MX25 is actually a newer SoC than i.MX35, it
sounds unreasonable that i.MX35 runs a v2 controller while i.MX25 runs
a v1.
The confirmation from designer tells that i.MX25 runs a v2 controller
too. This also matches the statement of "SD Host Controller Standard
Specification Version 2.0" listed in IMX25RM 23.1.1 Features chapter.
You probably got the impression that i.MX25 has a v1 controller by
reading the HOSTVER_SVN bit description. While it says 0x00 - SD Host
Specification Version 1.0, the register value is actually 0x01.
So the esdhc host version register indeed encodes the correct value
for all i.MX SoCs except imx6q. Thus, I prefer to replace the patch
with the one below.
Also I'm working on a big series to make esdhc driver more feature
complete for imx6q, including 8bit support, so I would like to pick
up your work from here.
Shawn
---8<------
[PATCH] mmc: sdhci-esdhc-imx: fix host version read
When commit 95a2482 (mmc: sdhci-esdhc-imx: add basic imx6q usdhc
support) works around host version issue on imx6q, it gets the
register address fixup "reg ^= 2" lost for imx25/35/51/53 esdhc.
Thus, the controller version on these SoCs is wrongly identified
as v1 while it's actually v2.
Add the address fixup back and take a different approach to correct
imx6q host version, so that the host version read gets back to work
for all SoCs.
Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
Cc: <stable@vger.kernel.org>
---
drivers/mmc/host/sdhci-esdhc-imx.c | 19 +++++++++++--------
1 file changed, 11 insertions(+), 8 deletions(-)
diff --git a/drivers/mmc/host/sdhci-esdhc-imx.c b/drivers/mmc/host/sdhci-esdhc-imx.c
index e07df81..b503113 100644
--- a/drivers/mmc/host/sdhci-esdhc-imx.c
+++ b/drivers/mmc/host/sdhci-esdhc-imx.c
@@ -237,15 +237,18 @@ static void esdhc_writel_le(struct sdhci_host *host, u32 val, int reg)
static u16 esdhc_readw_le(struct sdhci_host *host, int reg)
{
+ struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
+ struct pltfm_imx_data *imx_data = pltfm_host->priv;
+
if (unlikely(reg == SDHCI_HOST_VERSION)) {
- u16 val = readw(host->ioaddr + (reg ^ 2));
- /*
- * uSDHC supports SDHCI v3.0, but it's encoded as value
- * 0x3 in host controller version register, which violates
- * SDHCI_SPEC_300 definition. Work it around here.
- */
- if ((val & SDHCI_SPEC_VER_MASK) == 3)
- return --val;
+ reg ^= 2;
+ if (is_imx6q_usdhc(imx_data)) {
+ /*
+ * The usdhc register returns a wrong host version.
+ * Correct it here.
+ */
+ return SDHCI_SPEC_300;
+ }
}
return readw(host->ioaddr + reg);
--
1.7.9.5
^ permalink raw reply related
* [ANNOUNCE] iptables 1.4.17 release
From: Pablo Neira Ayuso @ 2012-12-25 13:09 UTC (permalink / raw)
To: netfilter-devel; +Cc: netdev, netfilter, netfilter-announce, lwn
[-- Attachment #1: Type: text/plain, Size: 429 bytes --]
Hi!
The Netfilter project proudly presents:
iptables 1.4.17
More relevantly, this release includes the IPv6 NAT extensions from
Patrick McHardy, the ignore day transition from Florian Westphal and
a couple of fixes.
See ChangeLog that comes attached to this email for more details.
You can download it from:
http://www.netfilter.org/projects/iptables/downloads.html
ftp://ftp.netfilter.org/pub/iptables/
Have fun!
[-- Attachment #2: changes-iptables-1.4.17.txt --]
[-- Type: text/plain, Size: 744 bytes --]
Florian Westphal (1):
libxt_time: add support to ignore day transition
Jozsef Kadlecsik (1):
Manpage update: matches are evaluated in the order they are specified.
Pablo Neira Ayuso (2):
Merge branch 'next' branch that contains new features scheduled for Linux kernel 3.7
bump version to 1.4.17
Patrick McHardy (7):
Convert the NAT targets to use the kernel supplied nf_nat.h header
extensions: add IPv6 MASQUERADE extension
extensions: add IPv6 SNAT extension
extensions: add IPv6 DNAT target
extensions: add IPv6 REDIRECT extension
extensions: add IPv6 NETMAP extension
extensions: add NPT extension
Tom Eastep (1):
extensions: libxt_statistic: Fix save output
^ permalink raw reply
* [Bug 58747] New: [RS780] Backtrace if firmware is not available on kernel-3.7
From: bugzilla-daemon @ 2012-12-25 13:17 UTC (permalink / raw)
To: dri-devel
[-- Attachment #1.1: Type: text/plain, Size: 866 bytes --]
https://bugs.freedesktop.org/show_bug.cgi?id=58747
Priority: medium
Bug ID: 58747
Assignee: dri-devel@lists.freedesktop.org
Summary: [RS780] Backtrace if firmware is not available on
kernel-3.7
Severity: normal
Classification: Unclassified
OS: All
Reporter: ojab@ojab.ru
Hardware: Other
Status: NEW
Version: DRI CVS
Component: DRM/Radeon
Product: DRI
Created attachment 72109
--> https://bugs.freedesktop.org/attachment.cgi?id=72109&action=edit
Related dmesg output
After updating to kernel 3.7 I get backtrace if booting without firmware
available (related dmesg part in the attached file).
Also reproducible with kernel 3.7.1.
--
You are receiving this mail because:
You are the assignee for the bug.
[-- Attachment #1.2: Type: text/html, Size: 2293 bytes --]
[-- Attachment #2: Type: text/plain, Size: 159 bytes --]
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* where does one send patches for auxiliary stuff like kern tools?
From: Robert P. J. Day @ 2012-12-25 13:17 UTC (permalink / raw)
To: Yocto discussion list
as i celebrate christmas by clawing my way thru the code, i run
across pedantic nitpickery like this:
diff --git a/tools/updateme b/tools/updateme
index 5998820..56c034a 100755
--- a/tools/updateme
+++ b/tools/updateme
@@ -199,7 +199,7 @@ migrate_cfg() {
scc_files=`find $meta_dir/cfg/scratch/obj/$dirname -maxdepth 1 -type f -name *.scc`
b=`basename $c`
- # check to see if a .scc file already includes the fragement
+ # check to see if a .scc file already includes the fragment
gen_feature=
if [ -n "$scc_files" ]; then
grep $b $scc_files -q
where does one send patches to things like kern tools? i can
collect more before bundling it all together as a single submission.
rday
--
========================================================================
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca
Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
========================================================================
^ permalink raw reply related
* [PATCH] arm: mxs: Update mxs_defconfig
From: Shawn Guo @ 2012-12-25 13:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1356055651-27145-1-git-send-email-marex@denx.de>
On Fri, Dec 21, 2012 at 03:07:31AM +0100, Marek Vasut wrote:
> Regenerate the mxs_defconfig to match recent kernel using the following
> commands:
>
> make mxs_defconfig
> make savedefconfig
> cp defconfig arch/arm/configs/mxs_defconfig
>
> Then enable these features:
> - MTD block access
> - UBI and UBIFS
> - JFFS2
> - EXT2 and EXT4
> - AT24 EEPROM support
> - Support for most of the SPI flashes
> - Support for ethernet PHYs that are usually used on mxs designs
>
> Signed-off-by: Marek Vasut <marex@denx.de>
> Cc: Fabio Estevam <fabio.estevam@freescale.com>
> Cc: Shawn Guo <shawn.guo@linaro.org>
Applied with one comment below to Fabio.
> ---
> arch/arm/configs/mxs_defconfig | 63 +++++++++++++++++++---------------------
> 1 file changed, 30 insertions(+), 33 deletions(-)
>
> NOTE: The SGTL5000 is enabled by default, it's not enabled by hand thus not
> listed above
>
> diff --git a/arch/arm/configs/mxs_defconfig b/arch/arm/configs/mxs_defconfig
> index 048aaca..9d30a6b 100644
> --- a/arch/arm/configs/mxs_defconfig
> +++ b/arch/arm/configs/mxs_defconfig
> @@ -1,5 +1,7 @@
> CONFIG_EXPERIMENTAL=y
> CONFIG_SYSVIPC=y
> +CONFIG_NO_HZ=y
> +CONFIG_HIGH_RES_TIMERS=y
> CONFIG_TASKSTATS=y
> CONFIG_TASK_DELAY_ACCT=y
> CONFIG_TASK_XACCT=y
> @@ -8,7 +10,6 @@ CONFIG_IKCONFIG=y
> CONFIG_IKCONFIG_PROC=y
> # CONFIG_UTS_NS is not set
> # CONFIG_IPC_NS is not set
> -# CONFIG_USER_NS is not set
> # CONFIG_PID_NS is not set
> # CONFIG_NET_NS is not set
> CONFIG_PERF_EVENTS=y
> @@ -24,8 +25,6 @@ CONFIG_BLK_DEV_INTEGRITY=y
> CONFIG_ARCH_MXS=y
> CONFIG_MACH_MXS_DT=y
> # CONFIG_ARM_THUMB is not set
> -CONFIG_NO_HZ=y
> -CONFIG_HIGH_RES_TIMERS=y
> CONFIG_PREEMPT_VOLUNTARY=y
> CONFIG_AEABI=y
> CONFIG_AUTO_ZRELADDR=y
> @@ -46,23 +45,31 @@ CONFIG_SYN_COOKIES=y
> CONFIG_CAN=m
> CONFIG_CAN_RAW=m
> CONFIG_CAN_BCM=m
> -CONFIG_CAN_DEV=m
> CONFIG_CAN_FLEXCAN=m
> # CONFIG_WIRELESS is not set
> CONFIG_DEVTMPFS=y
> # CONFIG_FIRMWARE_IN_KERNEL is not set
> -# CONFIG_BLK_DEV is not set
> CONFIG_MTD=y
> +CONFIG_MTD_CMDLINE_PARTS=y
> CONFIG_MTD_CHAR=y
> +CONFIG_MTD_BLOCK=y
> CONFIG_MTD_DATAFLASH=y
> -CONFIG_MTD_M25P80
> +CONFIG_MTD_M25P80=y
Fabio,
I do not think it's reasonable to ask Marek to drop this change from
his patch, as the change is probably included here because of
savedefconfig. So I will have to drop your patch below. Sorry.
[PATCH] ARM: mxs_defconfig: Fix MTD_M25P80 selection
http://article.gmane.org/gmane.linux.ports.arm.kernel/203788
Shawn
> +# CONFIG_M25PXX_USE_FAST_READ is not set
> +CONFIG_MTD_SST25L=y
> CONFIG_MTD_NAND=y
> CONFIG_MTD_NAND_GPMI_NAND=y
> +CONFIG_MTD_UBI=y
> +# CONFIG_BLK_DEV is not set
> +CONFIG_EEPROM_AT24=y
> +CONFIG_SCSI=y
> +CONFIG_BLK_DEV_SD=y
> CONFIG_NETDEVICES=y
> -CONFIG_NET_ETHERNET=y
> CONFIG_ENC28J60=y
> -# CONFIG_NETDEV_1000 is not set
> -# CONFIG_NETDEV_10000 is not set
> +CONFIG_SMSC_PHY=y
> +CONFIG_ICPLUS_PHY=y
> +CONFIG_REALTEK_PHY=y
> +CONFIG_MICREL_PHY=y
> # CONFIG_WLAN is not set
> # CONFIG_INPUT_MOUSEDEV_PSAUX is not set
> CONFIG_INPUT_EVDEV=m
> @@ -89,21 +96,6 @@ CONFIG_SPI_MXS=y
> CONFIG_DEBUG_GPIO=y
> CONFIG_GPIO_SYSFS=y
> # CONFIG_HWMON is not set
> -# CONFIG_MFD_SUPPORT is not set
> -CONFIG_DISPLAY_SUPPORT=m
> -# CONFIG_HID_SUPPORT is not set
> -CONFIG_SOUND=y
> -CONFIG_SND=y
> -CONFIG_SND_TIMER=y
> -CONFIG_SND_PCM=y
> -CONFIG_SND_JACK=y
> -CONFIG_SND_DRIVERS=y
> -CONFIG_SND_ARM=y
> -CONFIG_SND_SOC=y
> -CONFIG_SND_MXS_SOC=y
> -CONFIG_SND_SOC_MXS_SGTL5000=y
> -CONFIG_SND_SOC_I2C_AND_SPI=y
> -CONFIG_SND_SOC_SGTL5000=y
> CONFIG_REGULATOR=y
> CONFIG_REGULATOR_FIXED_VOLTAGE=y
> CONFIG_FB=y
> @@ -115,13 +107,16 @@ CONFIG_BACKLIGHT_PWM=y
> CONFIG_FRAMEBUFFER_CONSOLE=y
> CONFIG_FONTS=y
> CONFIG_LOGO=y
> +CONFIG_SOUND=y
> +CONFIG_SND=y
> +CONFIG_SND_SOC=y
> +CONFIG_SND_MXS_SOC=y
> +CONFIG_SND_SOC_MXS_SGTL5000=y
> CONFIG_USB=y
> CONFIG_USB_CHIPIDEA=y
> CONFIG_USB_CHIPIDEA_HOST=y
> CONFIG_USB_STORAGE=y
> CONFIG_USB_MXS_PHY=y
> -CONFIG_SCSI=y
> -CONFIG_BLK_DEV_SD=y
> CONFIG_MMC=y
> CONFIG_MMC_MXS=y
> CONFIG_NEW_LEDS=y
> @@ -145,16 +140,23 @@ CONFIG_COMMON_CLK_DEBUG=y
> CONFIG_IIO=y
> CONFIG_PWM=y
> CONFIG_PWM_MXS=y
> +CONFIG_EXT2_FS=y
> +CONFIG_EXT2_FS_XATTR=y
> CONFIG_EXT3_FS=y
> +CONFIG_EXT4_FS=y
> # CONFIG_DNOTIFY is not set
> CONFIG_FSCACHE=m
> CONFIG_FSCACHE_STATS=y
> CONFIG_CACHEFILES=m
> CONFIG_TMPFS=y
> CONFIG_TMPFS_POSIX_ACL=y
> -# CONFIG_MISC_FILESYSTEMS is not set
> +CONFIG_JFFS2_FS=y
> +CONFIG_JFFS2_COMPRESSION_OPTIONS=y
> +CONFIG_JFFS2_LZO=y
> +CONFIG_JFFS2_RUBIN=y
> +CONFIG_UBIFS_FS=y
> +CONFIG_UBIFS_FS_ADVANCED_COMPR=y
> CONFIG_NFS_FS=y
> -CONFIG_NFS_V3=y
> CONFIG_NFS_V3_ACL=y
> CONFIG_NFS_V4=y
> CONFIG_ROOT_NFS=y
> @@ -164,17 +166,12 @@ CONFIG_MAGIC_SYSRQ=y
> CONFIG_UNUSED_SYMBOLS=y
> CONFIG_DEBUG_KERNEL=y
> CONFIG_LOCKUP_DETECTOR=y
> -CONFIG_DETECT_HUNG_TASK=y
> CONFIG_TIMER_STATS=y
> CONFIG_PROVE_LOCKING=y
> -CONFIG_DEBUG_SPINLOCK_SLEEP=y
> CONFIG_DEBUG_INFO=y
> -CONFIG_SYSCTL_SYSCALL_CHECK=y
> CONFIG_BLK_DEV_IO_TRACE=y
> CONFIG_STRICT_DEVMEM=y
> CONFIG_DEBUG_USER=y
> -CONFIG_CRYPTO=y
> -CONFIG_CRYPTO_CRC32C=m
> # CONFIG_CRYPTO_ANSI_CPRNG is not set
> # CONFIG_CRYPTO_HW is not set
> CONFIG_CRC_ITU_T=m
> --
> 1.7.10.4
>
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.